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

[Michael Niedermayer]

On Tue, Jan 20, 2009 at 11:14:21AM +0100, Alexandre FERRIEUX - FT/RD/SIRP/ASF/SOFTL wrote:
> 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 ?

what?
you just have to use .h263 not .263 in the filename
or -f h263 or so


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

i have in the past renamed fps to tb, it seems this was not
enough, how can i make it more clear that this value is NOT the framerate?


[...]
> > Try moving finalize_packet() out of the else block and see if it fixes 
> > anything...
> 
> I did that, but it still detects 29.97.

H.263 allows exactly one timebase, and this timebase is 30000/1001, it does
allow different framerates but not different timebases.
H263+ allows different timebases

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090120/8ec01236/attachment.pgp>