Re: [UCI-Devel] Re: Re: Project status

[nicolas <rud...@if...>]

al...@fo... wrote:

>>>Actually, my current plans are to represent seekability information with 
>>>two
>>>flags ("depends on other frames" (aka keyframe flag), and "other frames may
>>>depend on this one").  Technically this results in four possibilities:
>>>
>>>1. dependant, depended (intermediate frame)
>>>2. dependant, non-depended (typical "transient" frame)
>>>3. non-dependant, depended (typical "seekable" frame)
>>>4. non-dependant, non-depended (basically a "seekable transient" frame)
>>>
>>>      
>>>
>>I suggest you to use your bits in a different way :
>>    
>>
>
>Why?
>
Because if you output a non-dependant frame and if the next frame 
reference the frame just before this non-dependant frame, you can decode 
the non-dependant frame, but you can't decode the stream because the 
next frame depend on a frame you didn't decode.
That's what I call a non-dependant, non-seekable frame.
So you will say why a codec would like to do this ? Because when a scene 
change occur, sometimes you just go back to the scene you had before and 
then instead of outputing a new key frame, you can just reference the 
last frame of the scene (so the frame just before the last key frame). 
So your last key frame is no more seekable : you can decode it alone 
(and some frames after) but you can't start decoding the stream from 
this point.

I can ask you the same question : why do you think it is interesting to 
know if a frame depends on a the non-dependant frame or not ? I don't 
see what you can do with this information.

>> 1. dependant, depended (intermediate frame) (can't skip this frame)
>> 2. dependant, non-depended (typical "transient" frame) (skip possible)
>> 3. non-dependant, seekable (typical "seekable" frame) (you can start 
>> decoding here)
>> 4. non-dependant, non-seekable (A key frame with a reference over it) (you 
>> can decode the frame to fastly watch the file)
>>    
>>
>
>Umm, that last one doesn't make any sense..  a non-dependant frame is by
>definition also seekable.
>
>I don't really understand what you're trying to achieve by this suggested
>change..  perhaps if you could explain what your actual goal is?
>
>  
>
>>I think there is a way to do this (I will use the frame types I 
>>described just before) :
>>If the codec is sure, it will output the right type of frame. If there 
>>is a doubt for the frame type the codec will use a compatible frame 
>>type, for example if you are not sure the frame will be seekable you use 
>>a '4' type, if you are not sure if you are going to reference a frame 
>>you use a type '1' frame.
>>This way the stream can be decoded without problem. So you can send it 
>>through a network.
>>Now when the codec output a type '3' frame it will output the list of 
>>all frames you need to update (so type '4' become type '3' and type '1' 
>>become type '2') since the last type '3' frame. This way if you send the 
>>stream to a file format you can improve seekability and if the output 
>>doesn't support it or the output is not seekable, you can decode the 
>>stream anyway.
>>
>>What do you think about this ?
>>    
>>
>
>Well, I didn't say it wasn't possible to do something like this, I just said it
>wasn't worth the amount of extra hassle it would involve.  As I mentioned
>previously, the information for an app to do this itself will be presented in
>other ways anyway, most likely, so I don't really see the need to add another
>mechanism for it too (particularly since the real-world advantages of this sort
>of thing are dubious anyway)..
>
As I said it's an optional feature, even if you don't use it your stream 
will be valid. It's just to improve the stream seekability. How do you 
think the app can do this itself ? without knowing the reference of all 
frames it's impossible. And this way it's simpler as you don't have to 
say which frame reference which frame, you just say update the frames in 
the list. If you don't want to allow this in a first version of UCI as 
no codec or app will take advantage of this, it's OK. Just consider this 
idea as an option for the future.