Hi,
Maybe the codec libraries need some NLE extensions to support "sloppy"
decoding, at least for the most common aquisition codecs.
Probably not the codecs themselves, but the surrounding libraries (like
quicktime4linux).
For example, instead of asking the codec for a particular frame, one
asks for a range, and gets the frame that is fastest to retrieve within
that range.
Or make the library cache entire GOPs. When reading the lastest qt4l annoucement
at heroinewarrior.com:
"Frames are cached when reading the first frame after a seek.
This allows faster reverse playback."
Isn't that what we are talking about?
The codec also needs to cache frames, or use Cinelerra's frame cache
to avoid a lot of repeaded decoding. If the codec has to decode frame
2-4 to deliver frame 5, it should be able to reuse those for decoding
frame 1 or frame 6 later. (memory or disk footprint permitting)
Ok, regarding NLE I'm more a user and know little about the internals.
So my question is, how often are frames needed out of order? Certainly
for reverse playback, that's clear.
But during rendering, you'll have mostly many small pieces, which are,
however, decoded sequentially (and thus don't need caching). Not meaning,
that advanced mechanisms are unneccesary, but to what extent are "real life"
situations affected by that?
Burkhard
_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
