On 03/23/2011 10:15 PM, Alexander Strange wrote:
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
You mean TrueHD, not DTS-HD. But thanks for the sample. It doesn't
cause any issues for my app. We keep track of the next expected
timestamp and as long as the difference between it and the timestamp
that is delivered to us doesn't exceed some threshold, we use our
computed timestamp. When the threshold is exceeded, we assume a
discontinuity occurred and make adjustments necessary to maintain A/V sync.
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.
What do you mean by "exactness is achievable"? Do you have some idea
how correct the duration that libavformat is calculating and using to
guess the next pts? I haven't looked close enough yet at
compute_frame_duration to see if there is some error there or if it is
just making necessary guesses because there isn't enough information
available to it.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
