Dear Dan , First of all thak you very much for responding for this. Indeed this helped, I can see transcoding speed has gone up. There is no way , I could ever have figured this out myself.
I did GET latest code and now I can see magic speed improvement . Does MLT work with QSV ?, indeed it works and works flawless. I only had to '--enable-libmfx' to build ffmpeg inside build-melt.sh You need to install Intel Media Server SDK ofcourse, I can send a writeup if it helps. Transcoding 30 second HD video now takes 16 seconds on i5 ,2GB RAM ,Ubuntu 14.04-64 bit box with following command time melt A_David_Beckham.mp4 -consumer avformat:output-stab-test.ts vcodec=h264_qsv b=5000k acodec=aac ab=128k mlt_image_format=yuv420p Thanks again. Regards, Abhijit On 23 October 2015 at 10:43, Dan Dennedy <d...@dennedy.org> wrote: > On Thu, Oct 22, 2015 at 4:07 AM Abhijit Pathak <abhi...@amagi.com> wrote: > >> Hi , >> >> I am having hard time in getting MLT Consumer transcode faster than >> real-time. >> >> Typically on a input file, I apply effects, overlay logo and then >> handover to AvFormat to transcode, but overall process takes as much time >> or more than time of input file. >> >> My Playback system plays transcoded Mpeg2TS file, I am not playing out >> directly. >> >> E.g. >> >> time melt A_David_Beckham_30_sec.mp4 -consumer >> avformat:output-stab-test.ts vcodec=h264_qsv b=5000k acodec=aac ab=128k >> tune=film >> >> > booo QuickSync is notorious for bad quality compared to x264, which at its > veryfast speed setting approaches QuickSync speed with better results. I do > not know if it works in MLT; never tried it, and I do not have hardware > that supports it. Is it really working for you? > > >> command takes more than 30 second, whereas if I use ffmpeg for >> transcoding directly it takes <10 seconds. >> >> > Maybe ffmpeg is automatically using hardware-accelerated decoding on your > system but not MLT? > > I made a test using libx264 for transcoding only - no explicit filters - > and yeah, melt is a _little_ slower: > > time ffmpeg -y -i ~/Videos/A06.avi -c:v libx264 -b:v 5000k -c:a aac > -strict experimental -b:a 128k test.mp4 > ... > real 0m21.908s > user 2m20.206s > sys 0m0.912s > > > time melt ~/Videos/A06.avi -consumer avformat:test.mp4 vcodec=libx264 > vb=5M acodec=aac ab=128k > ... > real 0m22.923s > user 2m16.615s > sys 0m1.460s > > This is due to some MLT internals to provide the convenience and > expression for the workloads for which it was designed. For example, it > applies normalization filters - whether active or not - that has a little > overhead to determine whether to do something. It also has more limited YUV > format support. Filters and transitions can only operate in yuv422p, rgb24, > rgba, or opengl. Thus, by default, there is a conversion yuv420p -> yuv422 > -> yuv420p. > > You can add mlt_image_format=yuv420p to the consumer to make it skip doing > those YUV conversions. However, if you do any sort of filters or > transitions; then, that will cause problems as yuv420p. However, in > special, controlled yuv420p -> yuv420p use cases you can use it. While that > property is working for the sdl consumer, I noticed while testing for this > response that it was broken for avformat. So, I just fixed it. Now, it is > very close to ffmpeg: > > time melt ~/Videos/A06.avi -consumer avformat:test.mp4 vcodec=libx264 > vb=5M acodec=aac ab=128k mlt_image_format=yuv420p > ... > real 0m22.094s > user 2m13.910s > sys 0m1.374s > > > -- <http://www.amagi.com>
------------------------------------------------------------------------------
_______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
