[FFmpeg-devel] Timestamp issues in live RTP->mpegts bridges

[Alexandre FERRIEUX - FT/RD/SIRP/ASF/SOFTL]

Hi Luca,

Luca Abeni wrote:
> 
> Looks like for some reason the H.263 stream is detected as 29.97 fps.
> Now, I do not know why this is happening: it can be due to the timestamp 
> issue you noticed, or to something else... Can you dump the H.263 
> bitstream to a file (with vcodec copy) and then do "ffmpeg -i" on that 
> file and post the result?

OK, I did that. But I cannot simply generate a flat stream with standard 
options (or maybe I'm missing one):

  ./ffmpeg -i /tmp/video/h263.sdp -vcodec copy - > a.263
  ./ffmpeg -i /tmp/video/h263.sdp -vcodec copy a.263

both these commands yield an error:

  Unable to find a suitable output format for 'pipe:'/'a.263'

I suspect one missing step is the notion that glueing together the H263 
packets yields a parseable bitstream. I don't have a concrete example, 
but I can imagine an RTP encapsulation scheme of some codec where the 
packet boundaries are crucial to the downstream parsing, or at least 
important for packet loss resilience, etc... does the code reflect that, 
and thus doesn't allow the flat output ?

However I worked around that by putting an 'fwrite()' (conditioned by an 
environment variable) in my H263-specific parse_packet function, as 
suggested by Michael last week.

The generated flat H263 bitstream is played by mplayer, but too fast.

The output of ffmpeg -i is:

  Input #0, h263, from 'a.263':
    Duration: N/A, bitrate: N/A
      Stream #0.0: Video: h263, yuv420p, 176x144 [PAR 12:11 DAR 4:3], 
29.97 tb(r)
  At least one output file must be specified

So it is wrongly guessing 29.97.
Maybe I could "force" the fps through some SDP parameter or command-line 
option ?

Also, I was wondering: instead of giving a fixed frame rate, is there a 
way of just inheriting the input timestamps ? I tried -copyts -- to no 
avail...


>> Wow !!! It seems that in rtpdec.c, as soon as we have a dynamic 
>> depayloader (same for h264), then the ->parse_packet is called but *not* 
>> finalize_packet ...
> 
> Uh... Looks like you found a bug ;-)
> Yes, the dynamic payload stuff looks broken...

Not sure I'm proud :-)

> Try moving finalize_packet() out of the else block and see if it fixes 
> anything...

I did that, but it still detects 29.97.


-Alex