[Live-devel] dump h264 video problem

[jacopo]

On 07/29/2010 10:14 PM, Ross Finlayson wrote:
>> ]I've found an h264 video stream that I'm able to dump and play
>> correctly
>> rtsp://media.lscube.org/tests/tc.mov
>>
>> This one suffers the problems I was talking about:
>>  rtsp://streaming1.osu.edu/media2/ufsap/ufsap.mov
>>
>> Both have been dumped with
>> ./openRTSP -t -d 20 -q
>> command line (no fps and w/h has to be specified for firts one, for
>> second none worked)
>
> The second stream's video has width 320 pixels, and height 240 pixels,
> so you should specify those if you're trying to record it using
> "openRTSP -q".  (I'm not sure about the frame rate.)
>
>
>> I'm not sure about one thing. H264VideoFileSink class that inserts 4
>> bytes long delimiter between NAL units, is used only when streaming not
>> when receiving a strem, right?
>
> Wrong.  Because it's a 'FileSink', it's used only when *receiving* a
> stream.  If "openRTSP" is used to receive a H.264/RTP stream normally
> - without using the "-q" or "-4"  options - then the
> "H264VideoFileSink" class is used for the output.  If, however,
> "openRTSP" is used with the "-q" or "-4" options, then a different
> 'FileSink' class - "QuickTimeFileSink" - is used.  Because you're
> using the "-q" option, this is what you are using.
>
>
>> If so, the problem must be container related (QuickTime or mp4 does't
>> matter for me) not codec related, since libraries are just dumping an
>> encoded stream that is not touched or modified when saved to a file (or
>> printed to stdout) inside the choosen container...
>> Am I totaly missing the point?
>
> I'm not sure.  But the basic problem here is that the ".mov" (or
> ".mp4") file format was very badly designed, and is especially
> ill-suited for what we are trying to do: Record incoming media streams
> into a file.  The "QuickTimeFileSink" class tries to do this as well
> as it can, but the basic flaws of the file format makes it difficult. 
> Nonethess, it's possible that the "QuickTimeFileSink" implementation
> can be improved, so feel free to take a look at it, and let us know if
> you have any suggestions for improvements/bug fixes.  Remember, You
> Have Complete Source Code.
Basically I've found that all streams that are not working are in some
way out of sync. All of them fail at line:

if (!ioState->syncOK(presentationTime)) 
at line 414 of QuickTimeFileSink.cpp (I hate posting code insed a mail...)

And if the -y switch is passed to openRTSP the resulting dumped video is
empty, sice all frames are discarded..
I've not really looked at the synkOK function, yet, but just wanted to
ask if I'm the only one suffering from that beahviour or something is
going wrong when determinating presentationTime or sync...
Mplayer is using live555 as rtsp library, but it does not act like this
(AFAIK) with h264, but often dumping mpeg4 videos result in  an empty
file... could that be related ?

Thanks again to everyone...
    j