do you really want to have warning log with the error statement inside? (root case of such MFXVideoVPP_Init behaviour is different topic and actually should be re-checked)
just looking at the initial issue on Windows: >I thought I had the entire pipeline (decode/scale-resize/encode) being performed by Quicksync it is not yet clear if exactly so and logs have to be checked, like CPU utilization can be high due to decode, as an example. Command line can be easier, if input codec format is supported by qsv, something like: ffmpeg.exe -hwaccel qsv -c:v h264_qsv -i "testvid.mp4" -vf "scale_qsv=640:360" -b:v 800k -c:v h264_qsv -c:a copy -y "testoutput.mp4" regards Maxym On Thu, Jul 5, 2018 at 3:20 PM Moritz Barsnick <barsn...@gmx.net> wrote: > On Thu, Jul 05, 2018 at 10:17:35 +0000, Li, Zhong wrote: > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Moritz Barsnick > [...] > > > Ideally, the returned mfxStatus would be evaluated and printed, but no > such > > > function is available (yet). %d perhaps? > > > > ff_qsv_print_error() can be used to print detailed error type. Is it > helpful? > > Basically yes, even in other places, but that function's in libavcodec, > and we're in libavutil. We would need to move the code around IIUC, but > I don't have any way of testing new code with this failing scenario > right now (I have this effect on a Windows machine, but can't actually > build on Windows), so that would be a blind modification from my side. > Better if the QSV maintainers (i.e. you ;-)) did this. > > This is the issue it would help to understand: > http://ffmpeg.org/pipermail/ffmpeg-user/2018-July/040438.html > > Thanks, > Moritz > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
