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

[Hong Aaron]

Hi,
Thanks for great guide, I continue working for the task and find more
problems, could you help a hand ?
I am porting VLC on
http://rhombus-tech.net/allwinner_a10/hacking_the_mele_a1000/ ARM board
using Qt & Linux.

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.

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?

Many thanks.
Regards,
Aaron

>
>
>
2012/7/31 Rémi Denis-Courmont <remi at remlab.net>

> Le mardi 31 juillet 2012 17:06:52 Hong Aaron, vous avez écrit :
> > As i am using HW decoder, So I raise the decoder thread
> > priority to high priority( above input and gui thread, but below display
> > thread), and I tested for decoding time for each frame cost about 12ms,
> > btw, I set file cache to 5 second.
>
> Increasing cache may cause more problems than it solves. Depending on the
> frame rate, 12 picture buffers obviously, the cache should be less than
> half a
> second... Otherwise, the decoder will constantly run out of output buffers.
>
> I do not recall very well what the video output logic is, but basically:
> - either the decoder will wait for buffers, nullifying the long file cache,
> - or the decoder will allocate extra picture buffers in anonymous memory,
> increasing overhead for the video output rendering.
>
> > I want confirm with you guys, Is raising decoder thread priority for HW
> > decoder and and event flag for decoder to wait method reasonable ?
>
> I don't think it will have any meaningful effects. Your mileage may vary.
>
> In any case, it won't have any effect at all unless VLC has sufficient
> privileges to raise thread priority above SCHED_OTHER.
>
> > Is there any side effect ? Any hint to solve the drop frame problem ?
>
> In principle, it will favor video decoding over the rest. It might affect
> audio and UI negatively, and even the input and video output threads. Thus
> it
> might in fact be worse rather than better.
>
> There is no generic answer to solving frame drop. You'd need to find what
> is
> actually causing the drop, e.g. memory/bus congestion, CPU starvation, etc.
>
> --
> 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/3e7e031d/attachment.html>