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.

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.



#1 Simon Farnsworth on 02.10.14 at 17:26

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.

#2 uraeus on 02.10.14 at 17:46

Yeah, well maybe that is something that can be looked into during the GStreamer Hackfest in Munich :)

#3 Simon Farnsworth on 02.10.14 at 18:31

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 :)

#4 Olav Vitters on 02.10.14 at 20:20

FYI: The 2014 wordpress theme looks nicer on mobile devices. You can switch to it if you want.

#5 uraeus on 02.11.14 at 06:20

Hi Olav,
Hadn’t looked at the theming in a looong while, thanks for reminding me :)

#6 liberforce on 02.11.14 at 10:40

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…

#7 pothos on 02.11.14 at 19:23

Very impressive! Thanks for showing the pipeline – how was the image generated?

#8 Simon Farnsworth on 02.11.14 at 21:46

That looks like a standard GStreamer dot graph converted to PNG – look at GST_DEBUG_DUMP_DOT_DIR on http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gst-running.html

If you’re writing a GStreamer application, http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstInfo.html#gst-debug-bin-to-dot-file-with-ts is the function to call to dump out the dot files at sensible points – it’s a lifesaver when debugging.

#9 uraeus on 02.11.14 at 21:47

It is generated using graphviz from a dot file generated by GStreamer.

General instructions can be found under the Getting pipeline graphs headline:

Python example of the code in Transmageddon generating the dotfile:

#10 Arun Raghavan on 02.14.14 at 03:33

Nice! Are the gstreamer-vaapi packages easily available somewhere, btw?

#11 Arun Raghavan on 02.14.14 at 03:42

Found it at: https://bugzilla.redhat.com/show_bug.cgi?id=1062324