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.
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.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
