Dear all, After some weeks I'm reporting back now concerning hardware accelerated encoding on my Intel Haswell machine with HD 4600 graphics.
Detailed testing shows that (at least on this little older CPU ( ~ 2013)): - hardware encoding with resizing is slower than software encoding, so I stay with software encoding for proxy clip generation - hardware encoding without resizing is faster than software encoding, but quality is significantly worse, so I stay with software encoding for the final rendering as well Results are in fact quite disappointing for me - maybe with newer integrated Intel graphics that would be different. And my results are in line with what is stated on the ffmpeg website: in general their software encoder produces better results, takes better advantage of multiple threads and is also much easier to control (especially image quality). I found also that ffmpeg produces much smaller files for a comparable image quality. For the record: I tested with different clips of 4k video, 20 - 35 seconds each; resizing was to 640x368. I tried different presets / qualities and number of threads. Best regards, Bernd On Freitag, 11. August 2017 11:57:29 CEST Vincent PINON wrote: > Hello, > > 'kdenlive_render' accepts the parameter: 'preargs="..."' to pass > arguments to melt before any other (profile, consumer etc). > you can also run trials with 'melt' command instead of > 'kdenlive_render', which is just a wrapper to send progress info & > controls to notifications, but is then a bit less flexible. > (see source code in "kdenlive.git/render" : kdenlive_render.cpp, > renderjob.cpp) > > Thanks for your investigations, very interesting if we can have it > working. Sorry for not being able to help more at the moment (no linux > machine nearby & quite in a hurry)... > > Vincent > > Le 08/11/2017 10:58 AM, B.M. a écrit : > > Well, eventually I'd like to create a new render profile, but in order to > > find out how it works (more precisely: why it didn't work), I looked at > > the render scripts kdenlive creates; I thought it might be easier to > > learn it like that. > > > > Whatever, it doesn't work as you proposed :-( > > > > I think without support from the developers I won't make better progress. > > > > Thank you Evert, > > best regards, > > Bernd > > > > On Freitag, 11. August 2017 07:24:57 CEST Evert Vorster wrote: > >> Hi there, Bernd. > >> > >> I am under the impression that you want to create a render profile in > >> Kdenlive. If that is the case start with the example from the bug report: > >> > >> -vaapi_device /dev/dri/renderD128 -hwaccel vaapi > >> -hwaccel_output_format vaapi -i -an -c:v dnxhd > >> > >> If you have a look at all the other rendering profiles, you will > >> notice that none have an input our output, > >> > >> these are added by Kdenlive itself. > >> > >> Kind regards, > >> > >> Evert > >> > >> On 10 August 2017 at 19:47, B.M. <b-m...@gmx.ch> wrote: > >>> 1) Proxy clips -- done > >>> > >>> Proxy clips creation with hardware acceleration is working fine now, for > >>> the > >>> record: > >>> I use x264 with these settings (in ~/.local/share/kdenlive/ > >>> encodingprofiles.rc): > >>> > >>> x264_vaapi=-vaapi_device /dev/dri/renderD128 -i -vf > >>> format=nv12,hwupload,scale_vaapi=w=1280:h=720 -vcodec h264_vaapi -b:v 5M > >>> -ab > >>> 128k -acodec libvorbis;mp4 > >>> > >>> > >>> 2) Project rendering -- open > >>> > >>> Still open - Evert, -i instead of $SOURCE_0 and $TARGET_0 cannot work > >>> because > >>> source and target contain the mlt script and the output file. > >>> Does this not work at all? Is it a mlt problem? > >>> > >>> Thank you so much for further input! > >>> Bernd > >>> > >>> On Donnerstag, 10. August 2017 14:41:38 CEST you wrote: > >>>> Hi there, Bernd > >>>> > >>>> Try again, but replace the "- $SOURCE_0 $TARGET_0" with "-i" > >>>> > >>>> Kind regards, > >>>> -Evert- > >>>> > >>>> On 10 August 2017 at 13:37, B.M. <b-m...@gmx.ch> wrote: > >>>>> PS: I'm trying something like (render script) > >>>>> > >>>>> PARAMETERS_0="-kuiserver -pid:8839 in=0 out=1139 $MELT uhd_2160p_25 > >>>>> 'avformat > >>>>> vaapi_device=/dev/dri/renderD128' - $SOURCE_0 $TARGET_0 > >>>>> properties=x264-medium > >>>>> f=mp4 vf='format=nv12,hwupload' vcodec=libx264_vaapi acodec=aac g=120 > >>>>> crf=23 > >>>>> ab=160k preset=faster threads=1 real_time=-1" > >>>>> > >>>>> but it doesn't work. > >>>>> > >>>>> Best, > >>>>> Bernd > >>>>> > >>>>> On Donnerstag, 10. August 2017 14:36:16 CEST you wrote: > >>>>>> Hi, > >>>>>> > >>>>>> Foreword: I just did the upgrade to the testing package (17.04.3) to > >>> > >>> get > >>> > >>>>>> this "bug fix". > >>>>>> > >>>>>> I'm really sorry, but I don't get it: > >>>>>> > >>>>>> What you've sent me is the rendering parameter, as set in the render > >>>>> > >>>>> dialog. > >>>>> > >>>>>> You changed is from vcodec=hevc to vcodec_nvenc to get hardware > >>> > >>> encoding > >>> > >>>>>> working with your nvidia card. > >>>>>> > >>>>>> What I want is just the same, but for vaapi because I've only the > >>>>> > >>>>> integrated > >>>>> > >>>>>> intel graphics. I can use libx264_vaapi as like with the ffmpeg > >>> > >>> command, > >>> > >>>>>> but there are more parameter required (vaapie_device, hwaccel, ...) > >>>>>> - > >>>>>> that's what Anton mentions in his bug report, and he asks for both > >>> > >>> proxy > >>> > >>>>>> clips and "encoding profile" which I take as rendering profile. > >>>>>> JBM's > >>>>>> answer and the commit are only talking about proxy clips and > >>>>>> transcoding, > >>>>>> not about rendering, so this leaves me unsure. > >>>>>> > >>>>>> From my understanding, I've the same problem as Anton: I need to > >>> > >>> inject > >>> > >>>>> the > >>>>> > >>>>>> additional parameters needed for vaapi (but not for nvenc) for the > >>>>> > >>>>> rendering > >>>>> > >>>>>> command, but so far I didn't find out how I have to do this. If I > >>>>> > >>>>> generate > >>>>> > >>>>>> a render script, I get something like > >>>>>> > >>>>>> PARAMETERS_0="-kuiserver -pid:8839 in=0 out=1139 $MELT uhd_2160p_25 > >>>>> > >>>>> avformat > >>>>> > >>>>>> - $SOURCE_0 $TARGET_0 properties=x264-medium f=mp4 vcodec=libx264 > >>>>>> acodec=aac g=120 crf=23 ab=160k preset=faster threads=1 > >>>>>> real_time=-1" > >>>>>> > >>>>>> Now, where do I have to insert these parameter (beside changing > >>> > >>> libx264 > >>> > >>>>> to > >>>>> > >>>>>> libx264_vaapi)? > >>>>>> > >>>>>> Unfortunately I don't have Anton's e-mail address, so I cannot ask > >>> > >>> him > >>> > >>>>>> directly ;-) > >>>>>> > >>>>>> Best, > >>>>>> Bernd > >>>>>> > >>>>>> On Donnerstag, 10. August 2017 07:54:18 CEST Evert Vorster wrote: > >>>>>>> Hi there, Bernd > >>>>>>> > >>>>>>> Have a look at this bug: > >>>>>>> https://bugs.kde.org/show_bug.cgi?id=378832 > >>>>>>> > >>>>>>> With the fixed bug there is also an example on how to make a vaapi > >>>>> > >>>>> profile > >>>>> > >>>>>>> from JBM > >>>>>>> > >>>>>>> Kind regards, > >>>>>>> -Evert- > >>>>>>> > >>>>>>> On 9 August 2017 at 20:55, B.M. <b-m...@gmx.ch> wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> Coming back regarding my attempts to get encoding using > >>>>> > >>>>> vaapi-hardware > >>>>> > >>>>>>>> acceleration to work... > >>>>>>>> > >>>>>>>> First, Vincent, concerning your point of ffmpeg not being > >>> > >>> compiled > >>> > >>>>> with > >>>>> > >>>>>>>> vaapi > >>>>>>>> enabled in Debian - well, that's correct and not correct > > > > somehow: > >>>>> it's > >>>>> > >>>>>>>> not > >>>>>>>> compiled with enable-vaapi, but vaapi is still working (at least > >>> > >>> in > >>> > >>>>>>>> stretch), > >>>>>>>> see this Debian bug > >>>>>>>> report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830880 > >>>>>>>> > >>>>>>>> For me, a command like > >>>>>>>> ffmpeg -vaapi_device /dev/dri/renderD128 -i infile.MP4 -vf > >>>>>>>> 'format=nv12,hwupload' -c:v h264_vaapi outfile.mp4 > >>>>>>>> works fine and encoding 4K video runs about 4x faster! > >>>>>>>> > >>>>>>>> What I struggle with is adding these options into the rendering > >>>>> > >>>>> profile > >>>>> > >>>>>>>> or > >>>>>>>> to > >>>>>>>> begin with into the rendering script. I created the rendering > >>> > >>> script > >>> > >>>>>>>> which > >>>>>>>> contains the line PARAMETERS_0. But how can I add these > >>>>>>>> vaapi-related > >>>>>>>> options? > >>>>>>>> Which one goes where? Any hints are very welcome ;-) > >>>>>>>> > >>>>>>>> Thanks a lot. > >>>>>>>> > >>>>>>>> Best, > >>>>>>>> Bernd > >>>>>>>> > >>>>>>>> On Dienstag, 8. August 2017 14:31:13 CEST Vincent Pinon wrote: > >>>>>>>>> Hello, > >>>>>>>>> > >>>>>>>>> Note that you need to have FFmpeg built with vaapi or nvenc > >>>>> > >>>>> support, > >>>>> > >>>>>>>> which > >>>>>>>> > >>>>>>>>> is not the case of Debian package. I don't know what's needed > >>> > >>> for > >>> > >>>>>>>>> Intel, > >>>>>>>>> but for NVidia you have to download a SDK linked to > >>> > >>> closed-source > >>> > >>>>>>>>> driver, > >>>>>>>>> providing personal information: showstopper for me (and many > >>>>>>>>> packagers) > >>>>>>>>> > >>>>>>>> :\ > >>>>>>>> : > >>>>>>>>> Please let us know of any progress on your side. > >>>>>>>>> > >>>>>>>>> Evert, did you try to share your custom profiles using > >>>>> > >>>>> "HotNewStuff" > >>>>> > >>>>>>>>> function in Kdenlive? ;) > >>>>>>>>> > >>>>>>>>> Vincent > >>>>>>>>> > >>>>>>>>> Le mardi 8 août 2017, 12:47:31 CEST Evert Vorster a écrit : > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Hi there, Bernd. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Kdenlive supports hardware encoding through custom encoding > >>>>> > >>>>> profiles. > >>>>> > >>>>>>>>> This is my profile for hardware hevc encoding with nvidia: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> properties=x265-medium f=matroska vcodec=hevc_nvenc acodec=aac > >>>>>>>> > >>>>>>>> crf=%quality > >>>>>>>> > >>>>>>>>> ab=%audiobitrate+'k' > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> It would have been awesome if mlt and ffmpeg used the same > >>> > >>> format > >>> > >>>>> in > >>>>> > >>>>>>>> command > >>>>>>>> > >>>>>>>>> lines, but this is not the case. At least they are close. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Unfortunately I only have intel cards, so I cannot test the > >>> > >>> intel > >>> > >>>>>>>>> vaapi > >>>>>>>>> acelleration for you. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Kind regards, > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 8 August 2017 at 10:35, B.M. <b-m...@gmx.ch[1]> wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Dear all, > >>>>>>>>> > >>>>>>>>> After some years without I'm getting back to video editing... > >>>>>>>>> I > >>>>>>>>> already > >>>>>>>>> searched quite a lot but it's really hard to find "realiable" > >>>>>>>> > >>>>>>>> information, > >>>>>>>> > >>>>>>>>> so I decided to ask here: > >>>>>>>>> > >>>>>>>>> - It seems that hw accel is not available in kdenlive > >>>>>>>>> > >>>>>>>>> - As far as I understand kdenlive uses mlt which uses ffmpeg. > >>>>> > >>>>> ffpmeg > >>>>> > >>>>>>>>> can > >>>>>>>> > >>>>>>>> use > >>>>>>>> > >>>>>>>>> hardware acceleration for de- and encoding. So is mlt to > >>> > >>> "blame" > >>> > >>>>> for > >>>>> > >>>>>>>>> missing hw accel. in kdenlive? > >>>>>>>>> > >>>>>>>>> - There has been a patch (bug 378832) "use of vaapi in > >>> > >>> transcoding > >>> > >>>>> and > >>>>> > >>>>>>>>> rendering" which seems to tackle my question. But what did it > >>>>> > >>>>> really > >>>>> > >>>>>>>> change > >>>>>>>> > >>>>>>>>> -/ what is it for? I didn't find more info on that and it's in > >>>>>>>>> kdenlive > >>>>>>>>> 17.04, while Debian is at 16.12. and before I compile myself > >>> > >>> I'd > >>> > >>>>> like > >>>>> > >>>>>>>>> to > >>>>>>>>> get more info. > >>>>>>>>> > >>>>>>>>> - Furthermore I found a thread on this list back in April > >>>>>>>>> "kdenlive > >>>>>>>>> and > >>>>>>>> > >>>>>>>> mlt > >>>>>>>> > >>>>>>>>> nvenc enabled" covering the same topic but for nvidia instead > >>> > >>> of > >>> > >>>>> Intel > >>>>> > >>>>>>>>> graphics; unfortunately nobody reported back if it really > >>> > >>> works. > >>> > >>>>> For > >>>>> > >>>>>>>>> me > >>>>>>>> > >>>>>>>> it > >>>>>>>> > >>>>>>>>> reads like the patch I mentioned above. > >>>>>>>>> > >>>>>>>>> So regarding the current state of hw accel in kdenlive I'm > >>> > >>> still > >>> > >>>>>>>> uncertain. > >>>>>>>> > >>>>>>>>> Thank you for your inputs. > >>>>>>>>> > >>>>>>>>> Kind regardsBernd > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Evert VorsterIsometrix Acquistion Superchief > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -------- > >>>>>>>>> [1] mailto:b-m...@gmx.ch
