Added transcoing support for TVHeadend servers #581

wants to merge 1 commit into


None yet
4 participants

This patch enables the use of the live transcoding feature I've added to my branch of tvheadend.
It might come in handy for low end hardware like the raspberry pie or cellphones that lack hardware mpeg2 decoders.

The server branch can be cloned from:

The transcoding is performed in software using ffmpeg so the server needs to be running on a rather recent CPU, depending on the resolution configured on the client side.

@opdenkamp opdenkamp commented on the diff Jul 24, 2012

@@ -444,6 +444,13 @@ bool CHTSPDemux::SendSubscribe(int subscription, int channel)
htsmsg_add_str(m, "method" , "subscribe");
htsmsg_add_s32(m, "channelId" , channel);
htsmsg_add_s32(m, "subscriptionId", subscription);
+ if(g_bTranscode)
+ {
+ htsmsg_add_u32(m, "maxWidth" , 0xffffffff); // Don't care
+ htsmsg_add_u32(m, "maxHeight" , g_iResolution);
+ htsmsg_add_str(m, "audioCodec" , g_strAudioCodec.c_str());
+ htsmsg_add_str(m, "videoCodec" , g_strVideoCodec.c_str());
+ }

opdenkamp Jul 24, 2012


haven't tested this yet, but will tvheadend version that don't support this feature just ignore it or bug out because the message is invalid?

also, we need some method to determine whether the backend supports this, or we'll get questions from users who set up these options, but still get the recording in the original format.


john-tornblom Jul 24, 2012

The extra method arguments should not cause any harm, they will just be ignored. I will double check this and report back.

Regarding the version detection, I can either bump the protocol version number sent during hello, or perhaps add a "capabillities" argument to the method, listing transcoding support or even fully supported codecs. Some systems don't have libx264 installed... I'll have a chat with andoma and see how he would like to have it.

What I don't know how to do is make the xbmc configuration dialog dynamic. There is a dependency between the tabs in the dialog. In order render the transcoding tab correctly, a connection must be established with the server. Is there a way to create these "wizard-like" UIs in an easy way in XBMC?


adamsutton Jul 24, 2012

I can confirm the point regarding ignoring options etc. Tvh only validates options Its aware of, i.e. it doesnt do whole message validation.

As you guys should be aware @andoma should be passing git repo ownership to (hopefully this weekend/next week). Finer points still to be arranged but my hope is that after some basic housekeeping we will make a plan to merge some new work and create a new release. This will hopefully include Johns work.


andoma Jul 25, 2012

I think the "0xffffffff == don't care" semantics should go away either way (just don't add the field instead)

The rest i think is quite ok. adding some kind of capabilities field to HTSP is probably also the way to go I think.


opdenkamp Jul 25, 2012


ok, then we'll just need that capabilities field and then this is good to go.

@adamsutton I'd rather do this recording profile stuff in the frontend (xbmc / showtime) and send the raw parameters based on the settings in the profile to the backend, or it'll be very messy to support both. I'm not going to add something that will only work with tvheadend to the api, so unless other backends support these profiles too, I won't add something like this to the api.

On a more general point, I think that it might be sensible to postpone this PR until after we've actually got this all worked out properly in TVH? Which hopefully will be soon.

I have some thoughts on John's work, that might require slightly different XBMC options. Quick example: I'd like to mod the TVH config to have a series of "profiles" (some of which we might predefine, such as RasPi, AndroidTab, etc... specifics TBD). And XBMC involvement might simply be to select a profile (rather than explicit options). Though that doesn't replace having the opportunity to set/override the explicit options.

For example for RPi, I'd probably want to configure to do the following for video (though not yet support by john's code):
MPEG2VIDEO -> MPEG4VIDEO (part2?, as its much quicker transcode than part10, and I don't care about compression)
H264 -> H264 (i.e. leave HD streams untouched).

I think that will be easier via some "profile" based configuration in TVH, which I can then select (dropdown) in XBMC.

I think the suggestions about a general capabilities check on HTSP connection setup (beyond a simple protocol version) would be a really good idea. Protocol version should define how we talk, capabilities will define what features we can support. There will be some amount of crossover (since a bump in protocol version may imply new capabilities), but generally it would be a good idea to separate these out.

Sorry some of this is a bit of topic for this PR.

@opdenkamp What I was thinking of was something fairly simple / flexible that would help to protect the front end from the complexities of what might be supported in the backend.

I was thinking a simple API something like:

int/string? id
string description

and then user can select (from drop down) one of these profiles OR enter specific details. And either the profile name/specific settings will be passed in the channel request.

For example JT's proposed implementation provides for fairly basic configuration (a|v)codec and image size. Also current codec lists are hardcoded, so where will they come from? It also doesn't support what I would require, i.e. I want the TO video codec to depend on the FROM (i.e for rpi no need to transcode HD h264, only need to transcode SD MPEG2).

And what if someone comes along and adds more complex configuration options for transcoding to TVH (or other backends)? Such as setting compression levels, etc...

Having the settings JT proposes (based on what he's currently implemented) is sensible enough but offering a nice flexible and simple to implement interface between front/back end either in replacement (or more likely side-by-side with) JT's current suggestions seems like a good idea to me?

My suggestion regarding predefined profiles was merely me thinking aloud about what we might do in TVH, i.e. we might ship it with some profiles for common use cases (like rpi).

Anyway just my opinion :)


opdenkamp commented Sep 5, 2012

Now that PVR support has been merged into mainline XBMC, every pull request must be sent as a pull request to mainline XBMC too:

That's why I am closing this one. Sorry for the trouble.

opdenkamp closed this Sep 5, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment