[vlc-devel] [Patch] Adding audio support to fake acces_demux
remi at remlab.net
Wed Sep 30 16:42:46 CEST 2009
Le mercredi 30 septembre 2009 17:27:52 Hugo Beauzee-Luyssen, vous avez écrit :
> > Why don't you just read the data from the access_demux? Why do you need
> > to bypass the codec phase as well? IMHO, the fake access_demux should be
> > killed.
> You mean removing both invmem and inamem, using the fake codec (just
> to do nothing) and implementing in*mem inside of the fake access_demux
A new access_demux plugin could inject coded blocks into the element stream
> Wouldn't this be kind of dirty ??
I think it's not as ugly as emitting dummy 1-byte blocks through the
elementary stream output. Besides, it would be much more generic, as it would
be independent of category and would enable injection of coded data as well.
> About the "why", it's just because we (VLMC team) started our process
> with the existant invmem codec, and it's associated demux.
invmem is a special case because our rawvideo codec plugin sucks and copies
entire pictures. picture buffers are pulled from the output by the decoder,
whereas codec data buffers are pushed from the demuxer to the decoder, so
rawvideo must copy entire pictures :( Fixing this architectural issue would be
difficult to say the least. To work around the problem, we could however apply
chroma conversion (or any other form of video filtering) directly in the
rawvideo codec. That would be ugly, but significantly boost speed.
The memory copy in the araw codec is not as big a deal. And if it were a
problem, the es_out_* API could easily be extended to support zero-copy audio,
since block_t and aout_buffer_t have been unified. So I do not see a strong
need for "inamem".
More information about the vlc-devel