Project

General

Profile

Debuging incorrect mkv strcture

Added by Eric Valette almost 12 years ago

I have a new TV that is able to play mkv generated from HDTV. Unfortunately, it plays none of the tvheadend generated mkv while it plays the same channels when recorded in TS or even remuxed in mkv from TS by mkvmerge. Remuxing faulty mkv via mkvmerge produce another faulty mkv.

I was hoping to use the -r option to make tvheadend remux to mkv from ts and produce the faulty mkv and then compare it with the one generated by mkvmerge. I do see the channel as rawts_01 but cannot play or rerecord it! Any hint?

févr. 06 21:49:24 [WARNING]:dvr: Output directory for video recording is not yet configured for DVR configuration "". Defaulting to to "/home/valette/Videos". This can be changed from the web user interface.
févr. 06 21:49:24 [NOTICE]:START: HTS Tvheadend version 3.3.453~g5dd5826 started, running as PID:12295 UID:1000 GID:1000, settings located in '/home/valette/.hts/tvheadend'
févr. 06 21:49:24 [NOTICE]:rawts: Added service 1 (pmt: 4095)
févr. 06 21:49:25 [INFO]:AVAHI: Service 'Tvheadend' successfully established.
févr. 06 21:49:25 [INFO]:dvr: "test" on "rawts_0001" recorder starting
févr. 06 21:49:25 [INFO]:subscription: "DVR: test" subscribing on "rawts_0001", weight: 300, adapter: "<N/A>", network: "<N/A>", mux: "<N/A>", provider: "<N/A>", service: "<N/A>", quality: 100
févr. 06 21:49:27 [ERROR]:dvr: Recording unable to start: "test": No input detected
févr. 06 21:49:31 [INFO]:subscription: "HTTP" subscribing on "rawts_0001", weight: 100, adapter: "<N/A>", network: "<N/A>", mux: "<N/A>", provider: "<N/A>", service: "<N/A>", quality: 100
févr. 06 21:49:33 [WARNING]:webui: Couldn't start streaming /stream/channelid/1, No input detected
févr. 06 21:49:33 [INFO]:subscription: "HTTP" unsubscribing from "rawts_0001"
févr. 06 21:49:33 [INFO]:subscription: "HTTP" subscribing on "rawts_0001", weight: 100, adapter: "<N/A>", network: "<N/A>", mux: "<N/A>", provider: "<N/A>", service: "<N/A>", quality: 100


Replies (10)

RE: Debuging incorrect mkv strcture - Added by Ron L almost 12 years ago

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.

RE: Debuging incorrect mkv strcture - Added by Eric Valette almost 12 years ago

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.

RE: Debuging incorrect mkv strcture - Added by Prof Yaffle almost 12 years ago

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

RE: Debuging incorrect mkv strcture - Added by Eric Valette almost 12 years ago

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.

RE: Debuging incorrect mkv strcture - Added by Eric Valette almost 12 years ago

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?

RE: Debuging incorrect mkv strcture - Added by Prof Yaffle almost 12 years ago

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

RE: Debuging incorrect mkv strcture - Added by Adam Sutton almost 12 years ago

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

RE: Debuging incorrect mkv strcture - Added by Eric Valette almost 12 years ago

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...

RE: Debuging incorrect mkv strcture - Added by Eric Valette over 11 years ago

@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.

RE: Debuging incorrect mkv strcture - Added by Eric Valette over 11 years ago

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

    (1-10/10)