Transmageddon continued

Posted on by

Released a 0.6 version of Transmageddon today. The user noticeable new feature is support for outputting Quicktime, MPEG4 and 3GPP files. Internally that was actually a big hurdle with some major code reorganisation and me learning about multiple new concepts on the way. A big thanks goes to Sjoerd Simons and Tim-Philipp Müller, because I don’t think I would have managed to sort out the state change stuff in the code without their help and input.

Would also like to thank David Love for sending in the first patch for Transmageddon. It switches the UI over from using radioboxes to drop down lists instead. This was also something quite a few people suggested to me both in person and in the comments to the previous blog. I haven’t merged the patch yet as I am still very uncertain about if I want to do this change. I like the visual feedback you get from seeing the radioboxes getting made sensitive/insensitive bases on container format and drop down lists simply do not give me or the user the same level of feedback. So I think I keep the current UI at least until I get moving on the output profiles.

One thing I realized after adding 3GPP as a container format is that we do not have a good AMR encoder and decoder in GStreamer. The reason for this is mostly that the people who most care about AMR are mobile phone people and even though a lot of them use GStreamer today, they got their own proprietary AMR plugins they use. So to alleviate this I added writing AMR encoder and decoder plugins to our suggested projects list for this years Google Summer of Code. One could probably take the code in Android for AMR and refactor it into a set of GStreamer plugins. Be aware though that Edward tells me that the current Android codec code is very ugly, so be prepared for some spring cleaning if you apply for Summer of Code to do this. This task would even have a bit of synergy effect with Edwards effort of porting GStreamer to Android.

One thing I should mention is that I have been spending a lot of time looking at the code of OggConvert when working on this version. It is really nice code and it does stuff correctly. So far it has always been to complex for me to understand when I look at it, but once I have managed to learn enough by trial and error to get my own code to work, I tend to notice that I am doing more or less the same as OggConvert :)

19 thoughts on “Transmageddon continued”

  1. Hi

    Is it possible to add a feature to convert a MVK file to a file that a PS3 can read like VOB/MPEG or mp4?

    The files are already in h264 and acc, it’s just the Playstation doesn’t like the matroska container

    Cheers

    Mike

  2. @Mike: that is a major goal for me (I got a PS3 too). You can create PS3 friendly files already with the application although you would recode it instead of remux it, which is what you want I think. Remuxing is on my todo list for features though.

    • Please use the email address I posted on the Transmageddon website for patches etc. I do plan on getting a bugzilla etc. for this, but I have not bothered as I am still in very early stages of development and I feel a barrage of bugreports are more useful when the list of bugs I already know about is a bit shorter :) A lot of the items in my TODO list are simply stuff I know is needed to make the application actually work nicely for people in most circumstances and not only work nicely on my machine.

  4. @Daniël: The website got a very clearly mentioned email address which could have been used for this patch. And looking at it here I have no idea what it is supposed to achieve and neither have you told me. I will remove your comment from the list as it is just a very long very cluttering entry as it is. If you really want me to commit this patch email me and explain what it is about.

  5. Just as a side note:

    http://noraisin.net/~jan/gst/convert2bbstorm.sh

    I’m going to give that a shot tonight with the goal being “make it play on my iPhone.” I don’t know what all video formats the PS3 supports. I have a gut feeling h264 / aac in a container that the iPhone likes will work fine.

    Long story short, stuff I’d like to see / will work on:

    1. Query gstreamer for containers, audio codecs, and video codecs.
    2. Profiles.
    3. Eventually a “make it work on my iPhone” type of button (no, it doesn’t have to be a button persay, but you get the idea).

    If anyone else is also working on this stuff, could you give a shoutout so we don’t step on each others toes?

    • @David: The iPhone I presume wants a Quicktime container. The PS3 do not accept Quicktime afaik. The PS3 instead wants a standard MP4 container (which is very close to Qucktime, but not the same). So for h264 and mp3 then MP4 is fine. If you howerver want AC3 audio, you need to use a MPEG TS container on the PS3.

  6. @ureaus I am sorry. I found the address directly when i clicked on ‘Submit Comment’. Thought I cancelled it, but suppose it was too late.

  7. You’re going to get famous with this app :-)

    Congrats on your effort! It looks real nice!

  8. Thanks, but I’m not sure you should be looking at my code for the best way of doing things! :-)

    I actually spent a while working on a general purpose “big brother” to OggConvert, with mostly the same goals as Transmageddon, but didn’t get as far as actually getting something worth releasing. I’m currently backpacking around Australia (which is why OggConvert hasn’t been updated in a few months), but I’ll be watching closely to see how this develops :-)

  9. Am I missing something here, or does the application happily pass data to be encoded even if the target encoder isn’t available? I tried a few options and noticed the errors of this type on the console:

    gst.ElementNotFoundError: x264enc
    gst.ElementNotFoundError: faac
    gst.ElementNotFoundError: mpeg2enc

    If the encoder isn’t present then the option should be grayed out. And if the encoding process fails to initialize correctly then the front-end should catch it and cancel the operation… unless an AVI containing only an MP3 audio track and no video is what you wanted ;)

    • @Sam: yeah, if you look at the TODO list linked from the homepage you see that removing the hardcoded plugin names is on there. Once that is done the ‘easy codec install’ should kick in trying to search all package repositories you have enabled for plugins to support the codecs in question. Once that search is done (and fail) I do agree that the option should be greyed out, at least for the current session. Be aware that this is my first forage into actual coding so there is a lot of stuff in the code far from optimal yet, but I am a firm believer that it is better to do this incrementally than trying to fix ‘everything’ in one go, both to have something that *might* be working for people as I go forward, but also to avoid get frustrated and not look at the issue for a long while :)

  10. Another reason for the common lack of AMR support: perceived patent danger.

  11. @uraeus I was thinking about tackling the h264/mp3 in an MP4 container first anyways. Seems to be a “pretty much works anywhere” format these days. And it has been a while since I looked at MPEG TS support in gstreamer (and I don’t remember it fondly). Haven’t had the time I wanted to work on this, but seeing as how I don’t have to work tomorrow it’ll be “HackingTime!” Well, minus parachute pants and all. Besides, video encoding stuff is WAY more fun than dealing with federal changes in financial aid stuff…

Comments are closed.