[vlc-devel] [Patch] Adding audio support to fake acces_demux

[Hugo Beauzee-Luyssen]

2009/9/30 Rémi Denis-Courmont <remi at remlab.net>:
> 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
> output.
>
>> 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".
>

So in the end, the only solution we got is to create a new
access_demux that will handle both video and audio callbacks and
parameters, write the result inside a newly created block_t, and using
the fake codec, just to have a dummy codec ?

-- 
Hugo Beauzée-Luyssen