Burkhard Plaum wrote:
> Hi,
>
> Ichthyostega schrieb:
>>>> But, /assumed you do have theses capabilities/, the goal
>>>> is to write code able to deal with organizing all those video frames
>>>> efficiently -- and this is what the video player test app is aiming at.
>>
>> Roland schrieb:
>>> What do you mean by "efficiently"?
>> getting the right frame out to the right output, without "stepping on
>> your
>> own feet" ;-) detecting when you can take shortcuts and save cpu cycles
>> whithout messing anyting up...
>
> A zero-order chortcut is to get frames mostly sequentially out of the
> decoder. When scrubbing, this means to cache at frames at GOP-level.
>
> No matter what future codecs will be like (with more weird possible
> inter-frame dependencies than H.264) they will all be optimized for
> sequential decoding, since that's the normal case :)
Quite sure, but the question is when caching frames is cheaper than
re-decoding them. My guess (which has to be profiled) is that in many
cases the first frame (keyframe) of a GOP is the most easy to decode
frame anyways. Things would become more interesting when it is possible
to cache the state of the decoder for each GOP, incrementally. For
common codecs that would quite likely bring some performance benefit,
but is also the thing which is most intrusive to the codec and cant
applied easily (if even).
Another thing with the frame-accurate-seek API you introduced in
avdecoder, I didn't looked closely on the code yet, but you write
indices on disk. Would it be possible to add hooks for the index access
(like in_memory) instead, so that an application can manage the indices
on its own?
Christian
>
> Burkhard
>
> _______________________________________________
> Cinelerra mailing list
> Cinelerra@skolelinux.no
> https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
_______________________________________________
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
