[FFmpeg-devel] Timestamp issues in live RTP->mpegts bridges
Tue Jan 20 14:23:53 CET 2009
On Tue, Jan 20, 2009 at 01:32:42PM +0100, Luca Abeni wrote:
> Hi Alexandre,
> > 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.
> I suspect the frame rate is stored in the bitstream, and the codec is
> reading such value, which turns out to be wrong... I do not know if this
> is a bug in the decoder, or in the enocoder...
> This looks like something for the codecs guys: can you open an issue on
> the bugtracker, or send an email in a new thread describing this problem?
> (you will have to upload the H.263 bitstream on upload.ffmpeg.org, as
> indicated in the bugreport page).
there is no fixed framerate value in h263
there are timestamps and a fixed 30000/1001 timebase
a few printf/av_log() that print what the spec calls "temporal reference"
and the AVFrame.pts as well as wat ffmpeg.c does with it should shed some
light on where things go wrong
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel