Hardware encoding in Transmageddon

So thanks to the new GStreamer 1.x VAAPI package for Fedora I was able to do a hardware encode with Transmageddon for the first time today. This has been working in theory for a while, but due to me migrating Transmageddon from GStreamer 0.10.x to GStreamer 1.x at the wrong time compared to the gstreamer-vaapi development timeline I wasn’t able to test it before.

Bellow is the GStreamer pipeline that Transmageddon use now if you have the Intel hardware encoder packages installed. Click on the image for the full image.
libva-pipeline-extract

I am also close to being able to release the new version of Transmageddon now. Most recent bugs found have turned out to be in various GStreamer elements, so I am starting to feel confident about the current pipeline building code in Transmageddon. I think that during the GStreamer Hackfest in Munich next Month I will make the new release with the nice new features such as general support for multiple audio streams, DVD ripping support and language tag setting support.

transmageddon-git-master

11 thoughts on “Hardware encoding in Transmageddon

  1. It’s just a shame that mpeg2dec is chosen in preference to vaapidecode for your pipeline; if uridecodebin used vaapidecode, you could then have used vaapipostproc instead of ffmpegdeinterlace and videoconvert, and had the GPU do more of the work.

      • Having done it with a manual pipeline (just to test that vaapiencode_h264 and vaapiencode_mpeg2 didn’t segfault), I can tell you that it’s weird watching your system transcode from MPEG-2 to H.264 using barely any CPU :)

  2. Hi, just a small UI remark, I think you should use some margins to avoid your Cancel/Transcode buttons being too close from each other, so there’s less chances of clicking the wrong button…

Comments are closed.