[MPlayer-dev-eng] NUT cleanup
Loren Merritt
lorenm at u.washington.edu
Wed Sep 7 10:18:02 CEST 2005
On Tue, 6 Sep 2005, Rich Felker wrote:
> On Tue, Sep 06, 2005 at 06:22:24PM +0200, Michael Niedermayer wrote:
>> On Mon, Sep 05, 2005 at 09:39:12PM -0400, Rich Felker wrote:
>>
>>> Consider the example where we have (I know, very stupid, but he
>>> insists...) a subtitle codec with I/P/B frames, and the following
>>> timestamps:
>>>
>>> I0 P2 B1 [period with no subs] I100 P102 B101 P104 B103 ...
>>>
>>> Now, the dts sequence for these frames becomes:
>>>
>>> I0 P2 B1 [period with no subs] I100 P102 B101 P104 B103 ...
>>> -1 0 1 2 100 101 102 103
>>>
>>> i.e. the subtitle that's supposed to appear at pts of 100 gets muxed
>>> at dts of 2, and won't be seen when it's actually time to show it.
>>> Also it's not useful whatsoever to have the packet available at time
>>> 2, as far as I can tell.
>>>
>>> Granted this case is pathological and stupid, but do we need to treat
>>> it in some way?
>>
>> IMHO no
>> to decode some part you must start at the earliest
>> keyframe of the streams you care about, that was always the case and doesnt
>> need b frames or unrealistic timestamps
>
> The problem here is what happens if we seek to timestamp of 90 or so..
> We should be able to start decoding the keyframe with pts==100, but
> we'll have a very hard time finding it since it's stored way back at
> dts==2. :( In fact without an index there's no way to find it without
> essentially doing a linear search thru the whole file up to dts==100.
>
> Do you have a good solution?
>
> Rich
The only solution I know of (good or otherwise) is:
Don't require 1 coded frame -> 1 decoded frame. If you ever want to see
the last frame, the decoder must support outputting a frame without
inputting the next. So just do that whenever possible: it can output P2
at the right time even if I100 isn't stored at dts==2. Hmm, this is
sounding like AVI packed B-frames.
--Loren Merritt
More information about the MPlayer-dev-eng
mailing list