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

[Rémi Denis-Courmont]

Le mercredi 1 août 2012 17:24:11 Hong Aaron, vous avez écrit :
> 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.

No. VLC always pulls direct buffers from the video output to the decoder, 
never the other way around. Maybe you have changed VLC to accomodate direct 
buffers from the decoder, but then I cannot comment - only you know what you 
have done.

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

The Linux framebuffer output only exports one buffer. So then, VLC will never 
use direct rendering. The decoder is irrelevant.

> but I can not
> find where to config the DR buffer to specific value and keep DR method
> from VLC code.

Video buffers are manged in the core, mostly in src/video_output/. Again, I am 
not very familiar with that part of the code, nor the exact buffer 
constraints. However, to the best of my knowledge pushing buffers from decoder 
to video filters/output is not currently supported.

> > > 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 responsibility of PTS and DTS depends on the codec. Again, I do not really 
know how this works for H.264. Usually, it's set by the demuxer. It might also 
be set by the packetizer. I am not sure it is ever set by the decoder.

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

Normally, all useful informations are provided in fmt_in. The exact relevant 
parameters depend on the codec.

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