[FFmpeg-devel] [PATCH] do not let claculated dts jump back

[Rainer Hochecker]

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

Rainer