[FFmpeg-devel] libavformat/utils.c/compute_pkt_fields2: calculate dts from pts
Tue Oct 9 17:31:35 CEST 2007
On Tue, Oct 09, 2007 at 04:21:12PM +0200, Dirk Musfeldt wrote:
> Michael Niedermayer schrieb am 09.10.2007 14:14 Uhr:
> > On Tue, Oct 09, 2007 at 08:59:18AM +0200, Dirk Musfeldt wrote:
> >> Hi,
> >> I'm using libavformat to re-mux an MPEG TS to PS. When feeding the PES into
> >> av_write_frame() I'm getting log messages of "error, non monotone
> >> timestamps" .
> >> So I was thinking about compute_pkt_fields2(). Is the algorithm to compute
> >> dts from pts really working as expected?
> >> It will probably work fine if either no packet has a valid dts (i.e. every
> >> packet has dts value AV_NOPTS_VALUE) or every packet has a valid dts value
> >> (which is the trivial case).
> >> But what if the I-frames and P-frames have valid dts but the B-frames don't?
> >> In this case only the pts values from B-frames are stored into
> >> st->pts_buffer.
> >> Let's assume that the stream has packets P2 B0 B1 P5 B3 B4 where the digit
> >> indicates the PTS value. P5 has dts value 2 while the B-frames don't have
> >> dts values.
> >> When computing dts for B3 the table st->pts_buffer will have the pts values
> >> 1 and 3, so that dts value for B3 becomes 1.
> >> But we have already seen P2 so that st->cur_dts is already 2 which gives the
> >> error message while the stream itself is perfectly valid.
> >> What do you think?
> > i think this is the wrong mailinglist, this belongs to ffmpeg-user
> > and you need a valid timestamp to mux a frame
> > also, if you want to send us a bugreport see our bugreporting guide
> > but at minimum we need a command line for ffmpeg and a sample file which
> > show the problem
> > [...]
> Sorry, but this is not about using libavformat but about the question wether
> the implementation is correct or not. I had the feeling that this is
> 'development discussion' as stated in the list description.
> As you may have read in the mail the frames indeed have valid timestamps. It
> is not required for a frame to have a dts value, at least it isn't in MPEG
mpeg does require every frame which has a pts value also to have a dts value
actually you cannot even store one for which this is not true the mpeg syntax
doesnt support that
you apparently feed the muxer with frames which have a pts but you provide dts
only for a random subset, yes this confuses the muxer
you can send us a patch to make the muxer fill in the randomly missing dts
compared to just all or none
if you want us to do anything about it you first have to demonstrate how this
can happen with ffmpeg itself
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Opposition brings concord. Out of discord comes the fairest harmony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel