Michael Niedermayer <[EMAIL PROTECTED]> added the comment: On Sun, Feb 17, 2008 at 11:40:16AM -0000, Reimar Döffinger wrote: > > 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. Audio is problematic, it could be fixed but that would need some work. There are at least 2 issues with audio iam aware of, first is that due to the MDCT overlap the first output of the decoder (should) differ by the length of the MDCT after seeking vs. in case of continous decoding. The second issue is that due to the bit reservoir the difference between sequential decoding and seeking is further increased and not known currently. There are 2 solutions i can see. First is just adding a max_match_time to AVStream and seeking by that amount earlier if a previous point is targeted. The second option would be to have the exact match times stored in the index or the timestamps in the index offset by them, this of course would need the match times to be known, be it through a decoder or parser or some value from the container ... > > > 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? No, i mean constraint, that is if you want to seek so that you can display whatever is at time X to the user then you need to seek to a point prior to X so that you have a keyframe before X in every stream. In that sense a subtitle stream would not be a constraint, that is it would not force the position to a earlier one. That is for exact seeking ... > 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. yes, flag = EMPTY should mean "completely transparent(sub) or black(vid) or silent(audio)" It is not supposed to mean theres a hole in the stream here. > 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. I dont understand at all what you are trying to say here. [...] > 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. it seems you misunderstood what i intended EMPTY to be for [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is not what we do, but why we do it that matters. ______________________________________________________ FFmpeg issue tracker <[EMAIL PROTECTED]> <https://roundup.mplayerhq.hu/roundup/ffmpeg/issue356> ______________________________________________________
