Michael Niedermayer <[EMAIL PROTECTED]> added the comment: On Sun, Feb 17, 2008 at 01:41:39PM -0000, wg wrote: [...] > >AVPacket.duration specifies the packet duration. If after reordering the pts > >+ > >duration doesnt match the next pts, that is a discontinuity and should be > >treated as such. If the duration isnt known then the discontinuity detection > >should likely be disabled. Subtitle streams are NOT a special case. Your > >patch > >intruduces bugs (that is ignore discontinuities in subtitle streams) > > This is not true -- there weren't any discontinuities to be ignored, > because AVPacket.duration currently _isn't used at all_. So > definitely no new bug introduced.
DVB/DVD does allow discontinuities, so i would suspect that such a discontinuity could also occur straight before a subtitle packet, maybe thats unlikely but i think it can happen. The current code should have identified such a discontinuity correctly, skiping subtitles in the check will not. [...] > > What i meant really is a pkt.duration check where the > > ist->next_pts != AV_NOPTS_VALUE check is. > > But that is the duration of the _current_ packet. You would really > need the duration of the previous packet at that place to decide > whether a discontinuity is possible (I assume you mean ffmpeg.c > l. 1977), no? Yes, and that is even previous in presentation order, so its maybe not really such a good solution either ... > > > An alternative might be a flag for the container indicating that it doesnt > > allow discontinuities. This still would be more correct than a check for > > subtitles. > > I don't see how that would help me, my input formats do allow > discontinuities so I couldn't disable such a flag. But then discontinuities should also be able to happen before subtitle packets. Unless the DVB&DVD specs require a video or audio packet before which would be a quite odd requirement so i doubt it. I think its more likely just luck and that video/audio packets are more common that simply ignoring subtitles in the detection does work for you. > > Can you please either: > > - reopen this issue The issue was about a patch that is rejected, the bug you descibe is certainly real and should be an open issue. How to fix this bug best i dont know for certain at the moment. Anyway, reopened and changed to bug [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle ---------- status: closed -> open substatus: reject -> open type: patch -> bug ______________________________________________________ FFmpeg issue tracker <[EMAIL PROTECTED]> <https://roundup.mplayerhq.hu/roundup/ffmpeg/issue356> ______________________________________________________
