[vlc-devel] [PATCH] Add libvlc_media_take_snapshot

[Rafaël Carré]

Le 24/04/2013 12:11, Rémi Denis-Courmont a écrit :
> On Wed, 24 Apr 2013 11:04:52 +0200, Rafaël Carré <funman at videolan.org>
> wrote:
>> Le 24/04/2013 09:50, Rémi Denis-Courmont a écrit :
>>> On Wed, 24 Apr 2013 08:21:20 +0200, Rafaël Carré <funman at videolan.org>
>>> wrote:
>>>> This function returns a snapshot for a given libvlc_media_t
>>>> This ought to be much faster and convenient than using vmem output to
>>>> generate thumbnails
>>>
>>> This does not belong in the input decoder code.
>>
>> I don't see why?
> 
> This is bloating the interface of the ES output and the input decoder
> adaptor. It is already hard to follow as it stands (and has some
> "interesting" timing bugs). If you want to use decoder in a yet new way,
> you should write your own adaptor like transcode already. To make matters
> worse, I suspect you will need to bloat the interface even more to address
> timing and memory leaking.

I agree that es_out / input code is hard to follow but I would say
"bloating" is too strong, even if this patch adds a few parameters /
struct members.

As for timing I am a bit surprised that this code worked on the first
try. I will test it more and look at demux code to see if checking for
the position is enough to ensure the correct frame has arrived.

Also I need to check index-less files like transport streams.

>> Anyway I am open to suggestions but this way seems to be not too much
>> intrusive.
> 
> I would hazard that resurrecting the image vout, or adding a thumbnailin
> stream output would be easier and not require any change to the core. But
> for a start, you could probably simply expose one of the supposedly
> existing vmem wrapper into lib/; it wouldn't be the first time a set of
> libvlc functions is layered on another one.

Anything based on vout will suffer from poor performance as vout is
asynchronous of input, so it is out of the question (we will feel the
vout queue with several unnecessary decoded frames before we can return
with our snapshot picture).

The idea is to decode only the necessary frames and return as soon as
possible to not waste time and cpu.

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).