[FFmpeg-devel] [PATCH] do not let claculated dts jump back
michaelni at gmx.at
Sat Feb 22 15:07:28 CET 2014
On Sat, Feb 22, 2014 at 08:36:41AM +0000, Rainer Hochecker wrote:
> Michael Niedermayer <michaelni <at> gmx.at> writes:
> > ok, from a quick look, the problem seems to be that the
> > num_reorder_frames value from the SPS is "wrong" or rather the file
> > was muxed as if it had a different value.
> > this value is also in delay = st->codec->has_b_frames;
> > and used from there
> > can you confirm that setting this to 1 fixes the issue for this file?
> > ive only manually looked at a few dts and they looked ok
> > also if the hypothesis is correct and the "delay" value is wrong then
> > one solution would be to detect this and adjust the delay value
> > cliping the dts seems rather hackish to me
> > also i suspect reverting 4eb49fdde8f84d54a763cfb5d355527b525ee2bf /
> > 2ba68dd044ca8fc591139c05563840f546a9c0c0 /
> > might fix this as well
> > [...]
> Yes, reverting 2ba68dd044ca8fc591139c05563840f546a9c0c0 cures the issue.
> I don't see how calculation of dts from pts should work reliable with the
> value of num_reorder_frames. This value indicates the maximum number of
> frames in the reorder buffer (in this case 4). If we have a missing dts
> right after an idr frame, dts is set to a already passed pts.
> I am wondering if it's better to leave dts at AV_NOPTS_VALUE instead of
> trying to calculate it. XBMC's player would be happy with this approach.
dts are needed for remuxing to containers which need dts, like
mpeg-ts/ps, so setting them nowhere isnt a good solution
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel