Hi,
Christian Thaeter schrieb:
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.
If the decoder didn't see any frames before, the first keyframe is faster
to decode than some subsequent non-keyframe, that's clear.
But when decoding sequentially, a P-frame with only a few macroblocks
changed since the last frame might be faster (fewer pixels to process)
than a complete I-frame. Of course it can be vice versa, if lots of
motion-compensation is used for coding the P-frame.
Without reimplementing all the codecs from scratch, making estimations
about decoding times is doomed to failure. And, no, I don't want to
reimplement any codec, which is already available.
Things would become more interesting when it is possible
to cache the state of the decoder for each GOP, incrementally.
That's the same as creating an extra decoder instance for each
GOP. Nothing has to be changed in avdecoder for that.
You can of course try that if you want, but I doubt it will make
sense :)
Also note, that the memory for the "decoder state" you mention
includes at least one decoded frame (2 if you have B-frames, even more for
H.264).
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?
In theory, it's possible. But these indices are completely useless for
the application. The meaning of some fields of the indices is different for
different formats, so the indices can only be used together with the
demuxer instance. It's not the fault of gmerlin-avdecoder, it's the different
fileformats which require different approaches to get sample accuracy.
The only generic method to use indices is through the already existing API which
is much less messy than the internals.
Burkhard
_______________________________________________
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
