[vlc-devel] RE : [PATCH] -- still image demux

[brezhoneg1]

> On Sun, Jan 04, 2009, brezhoneg1 wrote:
> > A more complex thing could be to cache the decoded image. Actually,
that
> > is the current implementation of fake divided into a fake
access_demux
> > and a fake decoder. This was certainly done on purpose for better
> > performance, but with the drawback of more complexity for end-users.
> 
> Couldn't we decode the picture in the demuxer (ok, that's ugly :)),
and
> just send the raw frame in the ES, instead of the encoded data?
> 
> I still think that it
> might be a good idea (for performance) to kind of bypass the demux vs
> decoder split and do the decoding in the demuxer.


I see your point.
I don't know about performance, because decoders usually have the
possibility to directly write into "direct buffers" allocated by vout
drivers. Decoding at an earlier stage means allocating large amount of
memory(malloc) then memcpy to buffers provided by vout.

Yet, why not give it a try. I suppose a dummy codec would still be
needed to convey the already decoded image from demux to vout ? 

Just what do you think of this other alternative:
At the demux level, we send a block (full image) only once (the first
time) even if we create a reference clock and regularly issue new PCRs.
For performance, that's the best (a one-off decoding work done at the
right place). Only thing is that we cheat a bit on the fake-fps thing.
As long as we use it for just displaying still images, or use simple
vout filters, it works great. For sout things, that may be more of a
problem.
 
That's why we could dedicate fake:// to state-of-the-art image handling
and this basic image demux as a simple,
yet-powerful-but-with-restriction image handling.

Erwan10