Tvheadend

There are a lot of bugreports about hardware players. I made workaround - see bug #392

Yura Scheglyuk wrote:

There are a lot of bugreports about hardware players. I made workaround - see bug #392

Using mkmerge over the produced file to remux does not solve the problem for me. However I think it now proved that its a container bug because:
1) The device do play the same video and audio codec using the mepgs2ts stream directly
2) When converting the ts to mkv using ffmepg with copy option for video and audio codec (arte hd for exemple), the resulting file plays correctly,
3) the only things that differ between the tvheadend mkv and the ffmpeg mkv is only the mkv container.
4) there are at least two error in the container (1088 instead of 1080) and the CodecPrivate field

I will ask people if I can patch the two files (mmg can patch the stream description but not the CodecPrivate field).

case HB_VCODEC_X264:
77 track->codecID = MK_VCODEC_MP4AVC;
78 /* Taken from x264 muxers.c /
79 avcC_len = 5 + 1 + 2 + job->config.h264.sps_length + 1 + 2 + job->config.h264.pps_length;
80 avcC = malloc(avcC_len);
81 if (avcC == NULL)
82 return 1;
83
84 avcC⁰ = 1;
85 avcC¹ = job>config.h264.sps¹; / AVCProfileIndication /
86 avcC² = job->config.h264.sps²; / profile_compat /
87 avcC³ = job->config.h264.sps³; / AVCLevelIndication */
88 avcC⁴ = 0xff; // nalu size length is four bytes
89 avcC⁵ = 0xe1; // one sps
90
91 avcC⁶ = job->config.h264.sps_length >> 8;
92 avcC⁷ = job->config.h264.sps_length;
93
94 memcpy(avcC+8, job->config.h264.sps, job->config.h264.sps_length);
95
96 avcC[8+job->config.h264.sps_length] = 1; // one pps
97 avcC[9+job->config.h264.sps_length] = job->config.h264.pps_length >> 8;
98 avcC[10+job->config.h264.sps_length] = job->config.h264.pps_length;
99
100 memcpy( avcC+11+job->config.h264.sps_length, job->config.h264.pps, job->config.h264.pps_length );
101 track->codecPrivate = avcC;

Eric Valette - wrote:

> case HB_VCODEC_X264:
> 77                track->codecID = MK_VCODEC_MP4AVC;
> 78                /* Taken from x264 muxers.c */
> 79                avcC_len = 5 + 1 + 2 + job->config.h264.sps_length + 1 + 2 + job->config.h264.pps_length;
> 80                avcC = malloc(avcC_len);
> 81                if (avcC == NULL)
> 82                    return -1;
> 83    
> 84                avcC[0] = 1;
> 85                avcC[1] = job->config.h264.sps[1];      /* AVCProfileIndication */
> 86                avcC[2] = job->config.h264.sps[2];      /* profile_compat */
> 87                avcC[3] = job->config.h264.sps[3];      /* AVCLevelIndication */
> 88                avcC[4] = 0xff; // nalu size length is four bytes
> 89                avcC[5] = 0xe1; // one sps
> 90    
> 91                avcC[6] = job->config.h264.sps_length >> 8;
> 92                avcC[7] = job->config.h264.sps_length;
> 93    
> 94                memcpy(avcC+8, job->config.h264.sps, job->config.h264.sps_length);
> 95    
> 96                avcC[8+job->config.h264.sps_length] = 1; // one pps
> 97                avcC[9+job->config.h264.sps_length] = job->config.h264.pps_length >> 8;
> 98                avcC[10+job->config.h264.sps_length] = job->config.h264.pps_length;
> 99    
> 100                memcpy( avcC+11+job->config.h264.sps_length, job->config.h264.pps, job->config.h264.pps_length );
> 101                track->codecPrivate = avcC;

BTW isom_write_avcc in avc.c has already the code in question. Just it not used...

Andreas Öman wrote:

Thanks for the troubleshooting.

There is some code in Tvheadend that should be able to do this conversion (from annex-b to AVC) but i never got it to work correctly.

And it seemed that most software based (ie. libav) players worked fine anyway. But apparently the hardware players have problems.
I'll try to finish the conversion code.

Yes as mentioned above the code isom_write_avcc in tvheadends avc.c does it. Note that the bug is worse because it will be complicated for people to remux HD streams:

if you try mkvexetract to try to remux with ffmpeg you get:

mkvextract tracks Retour-vers-le-futur-2.mkv 1:extracted.h264
Erreur : Track 1: NAL too big (because it look into the CodecPrivate to get the the NAL lenght) (checked with author)

and
ffmpeg barks about non monotonically increasing dts as already recorded in other bug reports.

I gave up trying to rescue my files on Linux and switched to windows. I tested the Haali mkvspliter and indeed it does not recognize the video part of the mkv file (exactly for the same reason as in the ffmpeg bug reported in this thread). I also installed the (once free) cyberlink H264 and VC1 codec in addition to Haali codecs and tried to play various in Windows Media Player (XP). The mkv file that play correctly are the same that play correctly on my hardware player. So maybe this could help you for your tests.

question: is the second patch only needed if you want to fix tvheadend .mkv's that are created before the first patch has been applied to the tvheadend source?

If so, then the second patch is only "temporarly" needed ....

Hein Rigolo wrote:

question: is the second patch only needed if you want to fix tvheadend .mkv's that are created before the first patch has been applied to the tvheadend source?

Yes.

If so, then the second patch is only "temporarly" needed ....

But I think all people wanting to rescue their bogus files will appreciate it like I did.

Thanks again patrick.

I am also happy that a source of problems with the mkv has been solved. I was just wondering what the status of the second patch was exactly.

Patrick,
Could you provide this first patch as a pull request on github? Then it can be included in the main brache quicker.

Hein

William Velde wrote:

Hello all,
i thought i had the same issue but not sure what is going on.

When i record hd video which i can watch using xbmc without problems i cannot record the stream and then playback the stream using mplayer or xbmc with audio.
So i patched tvheadend with the above patch to see what happens but tvheadend stil does not record my hd stream with audio.

it does fix the mkvinfo with a known h264 profile

Attached is the output from mkvinfo on the same recording (few minutes later) using tvheadend without the patch and then the output with the patched tvheadend.
Anyone an idea?

With kind regards,

William van de Velde

Logfile from tvheadend displays:
Oct 23 20:49:55 backend tvheadend¹⁶⁸⁰⁷: dvr: # type lang resolution samplerate channels
Oct 23 20:49:55 backend tvheadend¹⁶⁸⁰⁷: dvr: 1 H264 1920 x 1088
Oct 23 20:49:55 backend tvheadend¹⁶⁸⁰⁷: dvr: 2 AC3 dut 96000 0 <disabled, no valid input>
Oct 23 20:49:55 backend tvheadend¹⁶⁸⁰⁷: dvr: 3 TELETEXT
Oct 23 20:49:55 backend tvheadend¹⁶⁸⁰⁷: dvr: 4 CA

William Velde wrote:

Hello all,
i thought i had the same issue but not sure what is going on.

When i record hd video which i can watch using xbmc without problems i cannot record the stream and then playback the stream using mplayer or xbmc with audio.
So i patched tvheadend with the above patch to see what happens but tvheadend stil does not record my hd stream with audio.

it does fix the mkvinfo with a known h264 profile

Attached is the output from mkvinfo on the same recording (few minutes later) using tvheadend without the patch and then the output with the patched tvheadend.
Anyone an idea?

With kind regards,

William van de Velde

What Is see ffrom the mkvinfo file, is that without beeing patched the H264 field stream is incorrect and correct with patched version.
The patch itself does not change anything for audio stream compared to unpatched version.

Probably the audio stream in the streamed TS is recorded in a way that tvheadend does not recognize. Could you dump the TS stream using the TS patch available as a pull request or simply using tzap and use tsinfo on it.

Hello Eric,

how can i dump the ts stream using the ts patch?
Could i otherwise use mplayer -dumpstream?

When i directly play the stream with mplayer i see the following info:
VIDEO H264 AUDIO A52 NO SUBS (yet)! PROGRAM N. 1
Stream not seekable!
FPS seems to be: 25.000000 ==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264) ========================================================================== ==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 48000 Hz, 2 ch, s16le, 384.0 kbit/25.00% (ratio: 48000->192000)
Selected audio codec: [ffac3] afm: ffmpeg (FFmpeg AC-3) ==========================================================================
AO: [pulse] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...

And i do get the audio.
The text from above disabled, no valid input is in the file: dvr_rec.c but i'm not a programmer

With kind regards,

William van de Velde

William Velde wrote:

Hello Eric,

how can i dump the ts stream using the ts patch?
Could i otherwise use mplayer -dumpstream?

As long as you take the initial stream and not something remuxed by tvheadend its OK.

When i directly play the stream with mplayer i see the following info:
VIDEO H264 AUDIO A52 NO SUBS (yet)! PROGRAM N. 1

What is the URL of the stream you give to mplayer? directly from /dev/dvb/adapter0/....

William Velde wrote:

No i use the url from tvheadend:
mplayer -dumpstream http://192.168.10.10:9981/playlist/channelid/44 -dumpfile test.ts

i attached the test.ts file

The file is remuxed by tvheadend so that's not good. Plus there is a bug in EAC3 audio support via the web streaming API that is also corrected by the TS patch...

I propose we continue discution outside this bug because it has nothing to do with this bug.

Eric Valette - wrote:

William Velde wrote:

No i use the url from tvheadend:
mplayer -dumpstream http://192.168.10.10:9981/playlist/channelid/44 -dumpfile test.ts

i attached the test.ts file

The file is remuxed by tvheadend so that's not good. Plus there is a bug in EAC3 audio support via the web streaming API that is also corrected by the TS patch...

I propose we continue discution outside this bug because it has nothing to do with this bug.

BTW: I have sound with the ts sample you provided.

You can use tvheadends dump mux option to create a unmodified dump of your complete transportstream directly fro tvheadend.

Hein,

I can't provide the patch with a pull request on githubt now as I won't be available for the next 15 days. If you can integrate the patch in the main branch, I will appreciate; else I will do it when I come back.

Bug is back with ~pulse-4 provided by Dushmaniac. Changing output to ts in dvr-settings works very well. But matroska (mkv) never work again (H.264-stream is simply missing) - this has been fixed in previous versions (at least in ~pulse-3).

Hmm