Tvheadend

So... your TV plays the TS recordings? Recording to a TS container is fine and personally prefered. You can transcode the TS and then put it in an MKV container. I don't understand the reason to record to MKV if record to TS plays fine in your TV.

For recording mkv is better for several reasons (meta data including epg info, better fast forward because I frame are indexed, size of files, ...). So thanks for your suggestion but you do not answer the question in this post.

Yeah, let's not get into a .TS vs .MKV debate - I personally loathe .TS for a whole stack of reasons.

@Eric - can we rule out that it's your TV that's at fault? tvheadend mkvs have typically played in anything I throw them at (albeit with the old 30s offset before the fix in master). So is it new mkvs, or do ones from, say, a year ago play (which would suggest an issue in the updated muxer code)?

Prof Yaffle wrote:

Yeah, let's not get into a .TS vs .MKV debate - I personally loathe .TS for a whole stack of reasons.

@Eric - can we rule out that it's your TV that's at fault? tvheadend mkvs have typically played in anything I throw them at (albeit with the old 30s offset before the fix in master). So is it new mkvs, or do ones from, say, a year ago play (which would suggest an issue in the updated muxer code)?

No I disgree. I have several hardware DMP's at work that refuse to play tvheadend MKV's while playing simiklar content from other sources. So far I did no want to investigate since it was at work. My Panasonic is not at fault as it understand MKV and the various codecs. Generated mkv is at fault since mkvmerge does a better job than tvheadend for mkv muxing from the same TS source.

And please focus on the question : how do I use tvheaedend to remux a TS via the -r option.

As a side note, we already fixed the mkv generation once in the past (~ years ago) as it was absolutely not working on hardware decoders because the h264 stream was incorrectly generated. And yes without hardware players, you did not notice it as ffmpeg, xbmc and vlc viewer where working. So when you say everything I throw them at could you be more specific?

Clearly a spiky day. No worries, I thought I was trying to help you. I'll leave you to it.

Agreed, let's not argue over the whole TS v MKV format, we've been there done that and I think all parties have their opinions and that's fine

With regard to the MKV stuff, I wouldn't say that just because a HW decoder cannot play it means that the MKV is invalid. If the HW decoder has decided to implement a subset of the full spec, because they think that represents 90+% of the content they'll see then it is still strictly at fault. However, we also don't want to completely ignore the problem if we can output stuff that will be more compatible (without sacrificing functionality that we want for 90+% of our user base).

I've already assigned the task to John Tornblom, however he's very busy at the moment with other stuff, but I'm sure he'll get on it as soon as he can.

Eric Valette apologies with regard to the -r stuff, I completely forgot that you cannot easily record stuff from there since you generally need EPG data to be able to set up recording. I did manage to create a workaround in the past and I'll try and figure out what I did and let you know.

Adam

Adam Sutton wrote:

With regard to the MKV stuff, I wouldn't say that just because a HW decoder cannot play it means that the MKV is invalid. If the HW decoder has decided to implement a subset of the full spec, because they think that represents 90+% of the content they'll see then it is still strictly at fault. However, we also don't want to completely ignore the problem if we can output stuff that will be more compatible (without sacrificing functionality that we want for 90+% of our user base).

Agreed. That's why I want to investigate and for me, the most easiest way would be to compare the same ts source muxed by mkvmerge and muxed by tvheadend as if it was coming from DVB adapter or IP source with a single program. Of course I could try to resend it using vlc as a multicast stream and create a pseudo IP channel but I'm afraid about the synchronisation to have exactly the same content source muxed. Depending on the findings, I can send the bug to panasonic and add a personnal workaround (or even publish it for panasonic users as tv set is from late 2012 and likely exist in all their current product). That's my plan. BTW mkvalidator barks about clusters not always starting with I-frame but at warning level only.

One thing I have already seen is the use of the latest value in DisplayUnit

if(ssc->ssc_aspect_num && ssc->ssc_aspect_den) {
ebml_append_uint(vi, 0x54b2, 3); // Display width/height is in DAR
ebml_append_uint(vi, 0x54b0, ssc->ssc_aspect_num);
ebml_append_uint(vi, 0x54ba, ssc->ssc_aspect_den);

}

While its legal as the current spec, the value 3 has been only added very lately (2010) and it thus a bit risky. Same for the 30/17 value due to 1088 instead of 1080 compared to the classical 16/9 that mkvmerge produce. I will change this manually at home and see if it changes anything.

I've already assigned the task to John Tornblom, however he's very busy at the moment with other stuff, but I'm sure he'll get on it as soon as he can.

Eric Valette apologies with regard to the -r stuff, I completely forgot that you cannot easily record stuff from there since you generally need EPG data to be able to set up recording. I did manage to create a workaround in the past and I'll try and figure out what I did and let you know.

I think this would be great for debugging purpose e.g when TS is correct but mkv isn't like the various problem we got with missing audio tracks or subtitle or teletext in the past. I do not know why code requires epg for enabling the live play or the instant recording...

@Prof Yaffle : the mkv generated is incorrect because at least the CodecprivateData field is wrong (said by one of our H264 expert). Analyzing the code this means that the avc_find_start_code is wrong that may have other consequences...

So its not because some hardware works that the code/recordings are correct. The panasonic TV is probably just more picky.

lets see if updated code fixes the problem.

Just for the sake of completeness, I've created a bug for this and the bug contains the fix by replacing avc.c.