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

Hong Aaron go.aa.hong at gmail.com
Wed Aug 1 16:24:11 CEST 2012

Hi Rémi,
Maybe I do not describe clearly previously, please refer my comment ( in red).


2012/8/1 Rémi Denis-Courmont <remi at remlab.net>

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

For some embedded SoC with HW decoder, the DR buffers are usually from
the dedicated system memory of decoder,
these memory was reserved when power on, so the size is limited, such as
allwinner A10's HW decoder.
If VLC don't display and return the buffer(to decoder) in time, the decoder
loop thread has no enough memory to continue decode next frame,
as decode output and display buffer to the screen (linux fb) share the same
buffer, So if the actual DR buffer number less than the required(20).
and VLC drop the DR buffer from decoder without calling the "Release"
callback sometimes, display output is viewed like drop frame, but I can not
find where to config the DR buffer to specific value and keep DR method
from VLC code.

> > 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 first VLC_TS_0 is OK, but "p_block->i_pts" and "p_block->i_dts" is
always 0 for some video files.
If using "--demux=ffmpeg" option, PTS/DTS is correct.

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

Libve library supplied by allwinner can compute the PTS, but it need
know the video container infomation,
but i don't know how to get the info in VLC without breaking coding

> 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
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120801/03f9ff1a/attachment.html>

More information about the vlc-devel mailing list