Reimar Döffinger <[EMAIL PROTECTED]> added the comment: Hello, On Sun, Feb 17, 2008 at 11:02:07AM -0000, Michael Niedermayer wrote: > If they have durations not matching the PTS differences then there ARE > discontinuities. And they have to be handled as such. > It seems that the "intuitive" definition of duration you have does not > match a practically useable one, even less so the existing one in lavf.
I just use the _practically used_ definition of it in MKV and OGG for subtitles. Which (besides the half-assed, inconsistent approach of mov) are the only formats I am aware of that support and use embedded subtitles. > As another example try seeking, the natural way is to seek to the packet > into whichs pts-next_pts the request falls, your definition of duration > would need to be handled special. I do not completely agree with this conclusion, the search now already returns either a packet _before_ (and possibly including, but at least with audio you can not know that without actually decoding) or after the searched pts. > If you want to more efficiently handle the times at which no subs are > displayed, i assume thats what is between pts+"duration" and the next pts. > Then the demuxer has to generate packets with a "EMPTY" flag set (similar > to PKT_FLAG_KEY), and size 0. That way none of the existing code would break > nor would the duration be redefined, and even seeking would work better. That > is it just would need a > if(target_pkt.flag & EMPTY) > seek position isnt constraint by the subtitle stream constraint? You mean contained in? I doubt this is quite the right behaviour, since while there is no packet for this timestamp, the meaning sure is _not_ "no subtitle data available" but actually "there is no/an empty subtitle to be displayed" which I consider _completely_ different things. Though a possibility would be the way that OGG supports _in addition_: A 0-size subtitle package means clearing the subtitle. These could easily (?) be inserted by the demuxer. Though as a general solution this sucks as well, since it still means that a pts+duration < next_pts would either mean different things for audio and subtitles or the demuxer would have to know how to create an empty audio frame for the time in-between. Not that it would matter in practice though... > I much prefer a workaround in the matroska (de)muxer over one in EVERY > other (de)muxer, and adding special == SUBTITLE cases everywhere, even more > so as subtitles are NOT special. I did not intend to claim that they should be treated specially (though if you look at the average mkv file they ARE different, since only there the pts+duration < next_pts actually appears). The question is more how to handle demuxers where pts+duration < next_pts does _not_ mean a discontinuity. IMO in these cases it can mean "no data available" (for which you suggested the empty flag, though I am not too happy about that, flags are not usable for remuxing), or it can mean an specific kind of "idle data" (e.g. empty subtitle, no sound, black video). What remains to decide is how to handle it and fix the demuxers that need it (MKV at least for subtitles) to do that. ______________________________________________________ FFmpeg issue tracker <[EMAIL PROTECTED]> <https://roundup.mplayerhq.hu/roundup/ffmpeg/issue356> ______________________________________________________
