On Mar 23, 2011, at 10:10 PM, John Stebbins wrote: > On 03/23/2011 06:25 PM, Alexander Strange wrote: >> >> On Mar 23, 2011, at 9:09 PM, John Stebbins wrote: >> >>> >>> >>> On 03/23/2011 05:42 PM, Alexander Strange wrote: >>>> On Mar 23, 2011, at 6:00 AM, Luca Barbato wrote: >>>> >>>>> On 03/23/2011 08:20 AM, Alexander Strange wrote: >>>>>> On Tue, Mar 22, 2011 at 10:40 PM, Luca Barbato<[email protected]> >>>>>> wrote: >>>>>>> On 03/23/2011 03:31 AM, John Stebbins wrote: >>>>>>>> fwiw, I've verified that both patches solve the original problem I had. >>>>>>> I'd pick your since I expect to have 0 duration frames sooner or later. >>>>>> Expect to have them where? >>>>> The current specification states that Duration should be>0 (as already >>>>> discussed in the thread), so both patch are safe and correct now. >>>>> Setting the default in a more explicit way feels more futureproof. >>>>> >>>>> Adding a comment on the Aurel patch would make me happy as well. >>>>> >>>>> lu >>>> I forgot something I should've said first, which is the Duration field is >>>> useless and can be ignored. Except on the last frame it's the same as pts >>>> (timecodes), which is more reliable due to fewer muxer bugs. >>>> Perian's demuxer, the only one I'm familiar with, ignores the field. >>>> Duplicate timecodes in video are handled the way Aurel's patch does, which >>>> fixes several files I have: >>>> >>>> http://trac.perian.org/changeset/1364/trunk/MatroskaImportPrivate.cpp >>>> >>>> So that patch should be fine. >>>> >>> Maybe I'm misunderstanding your point. But the duration field is >>> definitely meant to be used when a SimpleBlock is laced. In this case the >>> block contains multiple frames and only one timestamp. The timestamp of >>> each subsequent laced frame after the first is calculated using the >>> duration. >> >> Yes, Perian ignores the Duration for that and figures it out from the next >> largest present timecode. Unfortunately I don't remember what files caused >> this to happen, so it's something to look at another time. >> >>> >>> Are you saying that duration is too unreliable to be useful and libav >>> should ignore it all together? If so, a completely different patch would >>> be necessary and some kind of fix for >>> libavformat/util.c:compute_frame_duration is needed. Because this function >>> is coming up with wildly inaccurate values in some cases. The generated >>> timestamps for the DTS-HD MA stream I was looking at were so bad that they >>> would drift far enough during a laced sequence that the timestamp for the >>> next block would appear to go backward. >> >> Sorry, I don't have much experience with audio here, but it's actually a >> different problem than video tracks. Pretty much all the durations in DTS-HD >> are expected to be 0, because the size of one audio frame is less than the >> difference between two MKV timecodes. I would suggest ignoring container >> times entirely, setting the timebase to the audio sample rate, and >> incrementing by the frame size of the audio. >> >> If you increment even by 1 in the rounded-off MKV timebase you might >> actually end up with packet durations much longer than the actual number of >> samples in the packet. Could you check that's not happening with ffprobe >> -show_packets or so? Any patch that looks OK there seems fine. > > Actually, the durations of the audio frames in my sample are around 10ms > which is well above the round-off threshold.
Who knew there were so many problems… anyway, here's a sample with that DTS-HD thing: http://astrange.ithinksw.net/ffmpeg/TrueHD_Sample_2.mkv > But that's not really important here. Our code allows for quite a lot of > slop in audio timestamps. And we deal fine with timestamps that are > AV_NOPTS_VALUE. The issue is that during this laced sequence of audio, libav > is delivering unreliable timestamps that are bad guesses and the difference > between where we think the next timestamp should be and what libav delivers > gets larger than the threshold we allow (70ms). At this point, we decide > that there must have been a significant discontinuity in the audio, so we > insert frames of silence in order to keep A/V in sync. Then when the next > block begins, we get a reliable timestamp that jumps backward in time by the > same 70+ms that the unreliable timestamps drifted and we have to drop several > frames to put A/V back in sync again. > > If we are going to assume that the duration supplied in the mkv file can't be > used because too many muxers set it incorrectly (and I do believe you when > you say this is the case). Then libav needs a way to signal to the app when > a timestamp is reliable and when it is just a wild guess. Then the app can > loosen it's constraints for keeping A/V sync when it sees that the timestamp > is just a guess. I'm tempted to say that libav shouldn't be setting pts or > dts at all in such cases and just pass AV_NOPTS_VALUE. If you want to > provide a convenience to the app, provide a public api for the app to obtain > libav's best guess (or add a pts_guess member to AVFrame to store the guess > in. Luckily I think exactness is achievable here.. In the meantime timestamps that go up are better than ones that go down, I guess. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
