[vlc-devel] [PATCH] Add libvlc_media_take_snapshot

Rémi Denis-Courmont remi at remlab.net
Wed Apr 24 13:27:05 CEST 2013


On Wed, 24 Apr 2013 13:12:48 +0200, Rafaël Carré <funman at videolan.org>
wrote:
>> The input decoder is also asynchronous with regards to the input
thread.
>> It gets encoded blocks from the ES output and decodes them
>> asynchronously.
>> A custom adaptor is unavoidabable to decode synchronously (like
transcode
>> without threading).
> 
> demuxing is less CPU intensive than decoding,

Usually true, but I don't see the point. For thumbnailing you need to do
both of these anyway, plus converting the frame and compressing the image.

> thus I think plugging into
> the decoder is the right thing to do (tm).

Obviously you need to use the decoder plugins. I don't think bloating the
existing input decoder adaptor is a good way though.

>>> The idea is to decode only the necessary frames and return as soon as
>>> possible to not waste time and cpu.
>> 
>> Again, a for more specific/customized usage of decoder_t would be
>> required.
>> 
>>> stream_output might work but I am not sure if we can control input
from
>>> a stream_output (set position to middle of the file and stop input
when
>>> we received a frame).
>> 
>> input decoder, vout or sout are all equally inadequate. None of them
can
>> control the input.
> 
> Hm well decoder_owner_sys_t has a pointer to the input thread?

IIRC, it's just a hack to feed the statistics back into the input item
(and should be replaced with a pull mechanism). It cannot be used to
control the input as such. Access, stream and demux also have a similar
input pointer.

-- 
Rémi Denis-Courmont
Sent from my collocated server



More information about the vlc-devel mailing list