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

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

Hi Luca,

>> Now, I still have a small issue with the timing of the produced output:
>>
>> If I instruct to transcode to mpeg2video encapsulated in mpegts, and 
>> save this to a flat ".ts" file, then when playing back the file (with 
>> mplayer or ffplay) I see it is playing at 30fps, regardless of the input 
>> fps which is 15fps.
> 
> Are you using the ffmpeg program or your own code? In the first case,
> can you post the output of ffmpeg? In the second case, how are you
> initialising the decoder and the encoder, and the TS muxer?
> (can you do "dump_format" on the input and on the output and post the
> result?)

The ffmpeg program:

Streaming:

  ./ffmpeg -i /tmp/video/h263.sdp -vcodec mpeg2video -an -f mpegts 
udp://localhost:9999\?pkt_size=1316

(as you can guess the udp pkt_size is here to clip on an integer number 
of TS packets (188 bytes) is case a PESpacket is larger than MTU).

To file:

  ./ffmpeg -i /tmp/video/h263.sdp -vcodec mpeg2video -an -f mpegts out.ts


where the h263.sdp contains (stolen from VLC):

	v=0
	o=- 0 0 IN IP4 127.0.0.1
	t=0 0
	s=NONE
	a=tool:vlc 0.8.6h
	c=IN IP4 127.0.0.1
	m=video 6000 RTP/AVP 96
	b=AS:54
	a=rtpmap:96 H263

The output of ffmpeg is:

Input #0, sdp, from '/tmp/video/h263.sdp':
   Duration: N/A, bitrate: N/A
     Stream #0.0: Video: h263, yuv420p, 176x144 [PAR 12:11 DAR 4:3], 
29.97 tb(r)
Output #0, mpegts, to 'udp://localhost:9999?pkt_size=1316':
     Stream #0.0: Video: mpeg2video, yuv420p, 176x144 [PAR 12:11 DAR 
4:3], q=2-31, 200 kb/s, 29.97 tb(c)
Stream mapping:
   Stream #0.0 -> #0.0

(notice this is after 91 frames of guessing game, as you know. But I 
observe the speed issue even long after that initial burst has been 
averaged away).


Also I'm getting lots of repeated errors like this:

  [mpegts @ 0x93a3c00]dts < pcr, TS is invalid


> 
> Also, the TS muxer has some problems... You should probably try an MPEG
> PS, or some other format, to check if results are better.
> 

OK thanks, will try that.

> I think the rtpdec.c code already reads the timestamps in the correct way
> (and I do not think timestamps need to be handled in a payload-specific way).
> Just ensure that after your H.263 modifications finalize_packet() is still
> called.


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 ...

Am I dreaming ?

     } else if (s->parse_packet) {
         rv = s->parse_packet(s->dynamic_protocol_context,
                              s->st, pkt, &timestamp, buf, len, flags);
     } else {


-Alex