[vlc-devel] [vlc thread priority] hardware decoder

[Rémi Denis-Courmont]

Le mercredi 1 août 2012 14:26:19 Hong Aaron, vous avez écrit :
> 1. VLC picture pool size problem.
>    VLC picture pool minimum size is 20 to keep DRI feature by default, if
> pool size below the value, VLC using memory copy instead of DRI, but
> hardware decoder can only provide 12 picture from system memory maximum for
> 1080p video, and I using the buffer direct set to fb to improve
> performance, How can I keep DRI feature and reduce the pool size less than
> 20? and I found VLC does not release picture pool and drop some frame
> before display sometime, so the buffer return to decoder is delayed, I
> think the root cause maybe the pool size problem.

I think the requirement is actually 7 buffers plus a maximum number of 
bipredictive frames depending on the given codec. I am not familiar enough 
with that code to even guess how to reduce this requirement.

In any case, I believe the restriction applies to the video output, not to the 
decoder. Indeed, the video output is responsible for providing the DR buffers.

> 2. VLC pts caculation
>     If I do not use ffmpeg, VLC native demux PTS always be zero for many
> video files, but ffmpeg demux PTS value output is right, even in seek. So
> which module has responsibility to calculate PTS ? If the module is
> decoder, such as A10 HW decoder plugin, it's need to know video container
> type such as AVI / MOV / MKV etc, How can I get container info decode
> module?

Starting at VLC_TS_0 is actually correct and expected of demuxers of most file 
formats. This is required to synchronize multiple files.

The demuxer is normally responsible for setting the PTS, but this may be 
codec-specific. I don't know the details for H.264 though. 

IIRC, the input clock will translate PTS from demuxer range to system time 
before it gets to the decoders and outputs.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis