wm4 wrote:
On Wed, 20 Jan 2016 00:42:18 +0000 Andy Furniss <adf.li...@gmail.com>
wrote:
Hendrik Leppkes wrote:
I do not agree that it should be a warning. As outlined in
the commit message and this thread, there are serious flaws
with frame threading and hwaccel.
I'm fine with it being an error, but since it is an API change,
it should follow the usual deprecation period to allow
downstream users time to fix it. Meanwhile it can be a warning
so that people notice the problem.
Its fundamentally broken, and making it a warning would
re-introduce known crashes. So no.
So are the flaws in ffmpeg or particular drivers?
It does seem a shame perf wise, I've been testing my AMD UVD
decode recently and for 500 UHD frames in a really high bitrate
h264 file it's like -
ffmpeg threaded = 16 sec.
ffmpeg single thread = 20 sec.
With or without hwaccel?
Both are with hwaccel. ffmpeg 2.8.4 cli
Admittedly a very concocted benchmark with a very high bitrate sample.
I know on normal x264 stuff my CPU could beat GPU anyway as the copy
back seems to hurt quite a lot/UVD is for playing.
For future GPUs that will do hevc I guess it could be more relevant.
gstreamer vaapi 14 sec.
gstreamer omx 10 sec.
the omx is a faster as the others do nv12 -> I420 on cpu (AFAICT)
Maybe -threads 1 hurts perf by limiting the format conversion as
well?
Is there a way to get whatever the h/w spits out (nv12) directly?
Trying to ask for nv12 seemed to get a double conversion.
Both vdpau and vaapi can retrieve image data as nv12.
With ffmpeg cli?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
