No audio with UK DVB-T HD channels

[laz]

Sorry if this is a known problem but I'm only just getting to speed with this!



After an evening's testing, SD recordings and live TV all work well for me. HD recordings and live TV give me video but no audio. The log shows lots of:


22:48:12.264200 [debug]  3427 Audio - We can not decompress 323 save for later 1 42f03024 0
22:48:12.277927 [debug]  3427 Audio - We can not decompress 322 save for later 1 42f03024 0
22:48:12.291955 [debug]  3427 Audio - We can not decompress 323 save for later 1 42f03182 15e
22:48:12.322358 [debug]  3427 Audio - We can not decompress 315 save for later 1 42f03024 0

and the occasional
[mp3 @ 0x1da8f00] incomplete frame
or
[mp3 @ 0x1da8f00] Header missing

This is all with DVT-T in the UK (Freeview). From my experiences with softdevice and xineliboutput, I seem to remember that the audio of these channels is in a fairly obscure format (AAC in LATM) and I think it needed a fairly recent ffmpeg from git to decode it properly. It used to need a fairly recent git checkout to decode it properly: is libavcodec + libavformat in raspian up-to-date enough to decode this audio?

Or maybe I'm missing something somewhere?!

Laz

[MartenR]

Well vomp does only support mpeg1 audio layer 1 and 2 and ac3.
So your audio format is not supported.
Anyway adding software decoding of another format should not be a big deal, if the cpu is fast enough. (I will only support stereo output, if you need more, someelse have to implement PCM multichannel support, some of the UK vomp developers interested?? ).

But I am not in the UK, so in order to implement this, I need the following:

• Please test if a vdr recording can be played back with omxplayer to ensure, that the performance of the raspberry is fast enough.
• I need a copy of your log file, and the line of the channel from your channel conf, it is likely, that I need to change the server side.
• I need a sample recording file 1-2 minutes, not to annoying content (I will probably watch the clip a hundred times).
  

The other thing I need, that it is supported by libav on raspbian.

Marten

[laz]

Well vomp does only support mpeg1 audio layer 1 and 2 and ac3.
So your audio format is not supported.
Anyway adding software decoding of another format should not be a big deal, if the cpu is fast enough. (I will only support stereo output, if you need more, someelse have to implement PCM multichannel support, some of the UK vomp developers interested?? ).

But I am not in the UK, so in order to implement this, I need the following:

• Please test if a vdr recording can be played back with omxplayer to ensure, that the performance of the raspberry is fast enough.
• I need a copy of your log file, and the line of the channel from your channel conf, it is likely, that I need to change the server side.
• I need a sample recording file 1-2 minutes, not to annoying content (I will probably watch the clip a hundred times).
  

The other thing I need, that it is supported by libav on raspbian.

Marten

I thought that "currently unsupported" was probably the case! Not that much of an issue for me, to be honest, because I can never tell the difference between SD and HD!

As I say, I've only had a quick play with this so far but I'll try to look into it a bit more deeply in the next few days and get back to you with what you need if it is worth it.

Assuming that libavformat and libavcodec are the same ones in the standard Debian distributions,  I doubt AAC-LATM is supported: I always had to get ffmpeg from git to get it to work with xineliboutput! If it isn't supported, I don't think it's really worth the effort at the moment (for me at least!).

Laz

[MartenR]

Assuming that libavformat and libavcodec are the same ones in the standard Debian distributions,  I doubt AAC-LATM is supported: I always had to get ffmpeg from git to get it to work with xineliboutput! If it isn't supported, I don't think it's really worth the effort at the moment (for me at least!).

LATM is only a special way of packing aac. Since I am always implementing unpacking directly into vomp, this is not much of an issue.
The only issue will be if aac decoding is fast enough.
For me it is important, that I do the implementation soon, before I will forget the detail of the audio implementation.
The reason why it is not implemented yet, is that on SD it was never an issue and I do receive dvb transmission in HD with AAC.

Marten

[laz]

LATM is only a special way of packing aac. Since I am always implementing unpacking directly into vomp, this is not much of an issue.
The only issue will be if aac decoding is fast enough.
For me it is important, that I do the implementation soon, before I will forget the detail of the audio implementation.
The reason why it is not implemented yet, is that on SD it was never an issue and I do receive dvb transmission in HD with AAC.

OK. I have just recorded 5 minutes from BBC HD (I'll PM you a link to it once I've copied it to my web server). I will also upload a debug log from vompclient starting up and then showing BBC1 HD live TV for a few seconds.

Bizarrely, when I tried to play back the 5 minute recording with vompclient it doesn't even show the video. The debug log is then full of lots of:

20:29:46.240877 [debug]  2698 VDR - RR unsleep
20:29:46.257776 [debug]  2698 VDR - RR sleep - opcode 7
20:29:46.328412 [debug]  2698 VDR - Rxd a response packet, requestID=178, len=100000
20:29:46.329942 [debug]  2698 VDR - RR unsleep
20:29:46.346665 [debug]  2698 VDR - RR sleep - opcode 7
20:29:46.416953 [debug]  2698 VDR - Rxd a response packet, requestID=179, len=100000
20:29:46.418518 [debug]  2698 VDR - RR unsleep
20:29:46.443122 [debug]  2698 VDR - RR sleep - opcode 7
20:29:46.512892 [debug]  2698 VDR - Rxd a response packet, requestID=180, len=100000

messages (intermixed with other messages earlier on) that continue until I stop playback. After that, vompclient becomes unresponsive, although remote presses are logged. If I try to kill with CTRL-C or kill PID the debug log has messages saying it is stopping but it doesn't; I have to resort to kill -KILL PID to kill it.
-------------------------------------------------------------
I had a go with omxplayer and that seems to play back the file fine, both video and audio and the output from that is:

$ omxplayer -o hdmi 00001.ts
file : 00001.ts result 0 format mpegts audio streams 2 video streams 1 chapters 0 subtitles 1
Video codec omx-h264 width 1920 height 1080 profile 100 fps 50.000000
Audio codec aac_latm channels 2 samplerate 48000 bitspersample 16
Subtitle count : 1 state off : index 1

have a nice day

omxplayer did sit on 100% CPU usage for about 10 s not appearing to do anything before the file began playing and CPU dropped down to a modest 21% or so. I'm not sure whether that is normal or not: it's the first time I've run it! Maybe the very start of the file has errors that confuses it and also vompclient? I can record another few minutes if you wish.

-------------------------------------------------------------
The same recording plays back fine with mplayer from stock Debian testing and it outputs:

MPlayer svn r34540 (Debian), built with gcc-4.7 (C) 2000-2012 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing 00001.ts.
libavformat version 53.21.0 (external)
Mismatching header version 53.19.0
TS file format detected.
VIDEO H264(pid=101) AUDIO AAC LATM(pid=102) NO SUBS (yet)!  PROGRAM N. 132
FPS seems to be: 25.000000
Load subtitles in ./
Failed to open VDPAU backend libvdpau_r300.so: cannot open shared object file: No such file or directory
[vdpau] Error when calling vdp_device_create_x11: 1
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 53.35.0 (external)
Mismatching header version 53.32.2
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
[aac_latm @ 0x7f40deaa7380]audio config changed
AUDIO: 48000 Hz, 2 ch, s16le, 0.0 kbit/0.00% (ratio: 0->192000)
Selected audio codec: [fflatm] afm: ffmpeg (FFmpeg AAC in LATM)
==========================================================================     
AO: [pulse] 48000Hz 2ch s16le (2 bytes per sample)                             
Starting playback...                                                           
Unsupported PixelFormat 61                                                     
Unsupported PixelFormat 53                                                     
Unsupported PixelFormat 81                                                     
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.                   
VO: [xv] 1920x1080 => 1920x1080 Planar YV12                                     
A:69872.4 V:69871.9 A-V:  0.414 ct: -0.252 117/117 174% 16%  4.2% 109 0

-----------------------------------------------------------------------------
Here are the lines from my channels.conf:

BBC One HD :634000000:B8C23D23M256Y0:T:0:6601=27:6602=eng@17,6606=eng@17:0;6605=eng:0:17540:9018:16521:0

BBC HD :634000000:B8C23D23M256Y0:T:0:101=27:102=eng@17,106=eng@17:0;105=eng:0:17472:9018:16521:0


So, it all looks as if it might just work.

Laz

[MartenR]

Support is now in git. You will need an update of the server side. Patches will appear soon here in the forum and later in git.
There is one problem, the video has two streams, the second stream is a different audio type but also flagged as aac latm, so if you select this one there will be noise and distortion for your speaker, so please do not select him.

Of course only recordings tested.

Marten

[laz]

Support is now in git. You will need an update of the server side. Patches will appear soon here in the forum and later in git.
There is one problem, the video has two streams, the second stream is a different audio type but also flagged as aac latm, so if you select this one there will be noise and distortion for your speaker, so please do not select him.

Of course only recordings tested.

Marten

The second audio track is, I think, audio description for the partially sighted. It doesn't surprise me in the slightest that it has a format different from the one it claims!

I had a quick test earlier on and I did have sound on live BBC1 HD. However, after a short while (30 s?) sound disappeared and I had to kill vompclient.

I managed to update my sources and test between your bug-fix for the SIGILL bug. I got that the first time I ran it but it started fine the next time (when I did the quick test mentioned).

I have now pulled in your SIGILL bug fix and a quick test shows that it plays back that recording I uploaded with sound and video. CPU usage hovers around 50%. After a few tens of seconds, the audio cuts out and in every few seconds.

Another quick test with live ITV1 HD and I watched several minutes of video and sound that all worked perfectly.

Maybe it's just a signal quality issue (I've never really watched the HD channels before): I'll do some more intensive tests this evening once my daughter has gone to bed so I don't get crawled over as I do it...

Looks good, though.



Laz

[MartenR]

The second audio track is, I think, audio description for the partially sighted. It doesn't surprise me in the slightest that it has a format different from the one it claims!

I assume, that there is in the moment no support in the vdr for this format. So that vdr did not include enough information about this track into the TS stream.
Anyway in the moment I have no idea, what to do against it
[Edit: I have read the wikipedia article on freeview hd, they said that it might be HE-AAC, if it is version two, then it is not fully implemented in libav, so that is the reason].

I had a quick test earlier on and I did have sound on live BBC1 HD. However, after a short while (30 s?) sound disappeared and I had to kill vompclient.

Was video ok? So was it running? If not, it was probably the video blocking the audio playback this will be fix within the next hour in git.
It it is something different, please test if you can reproduce it with an recording, so that I can do something to fix it.

I have now pulled in your SIGILL bug fix and a quick test shows that it plays back that recording I uploaded with sound and video. CPU usage hovers around 50%. After a few tens of seconds, the audio cuts out and in every few seconds.

I am not sure what you mean with cuts out and in?
Is it like stopping and continuing playback? I suggest that you play with the TCPwindowsize in settings, it can be a network performance issue.

Marten

[laz]

I had a quick test earlier on and I did have sound on live BBC1 HD. However, after a short while (30 s?) sound disappeared and I had to kill vompclient.

Was video ok? So was it running? If not, it was probably the video blocking the audio playback this will be fix within the next hour in git.
It it is something different, please test if you can reproduce it with an recording, so that I can do something to fix it.

Sorry, I wasn't specific enough. Video kept going fine but sound was lost after a few seconds.

I have now pulled in your SIGILL bug fix and a quick test shows that it plays back that recording I uploaded with sound and video. CPU usage hovers around 50%. After a few tens of seconds, the audio cuts out and in every few seconds.

I am not sure what you mean with cuts out and in?
Is it like stopping and continuing playback? I suggest that you play with the TCPwindowsize in settings, it can be a network performance issue.

The video was fine and playing smoothly but the sound would be perfect for a few seconds, disappear for a few seconds, and then be back perfect again.

I have just checked out your latest patches and am recompiling.

I'll do a bit of testing and hopefully post some log files later on.

Cheers,

Laz

[laz]

It looks like my main problem was the TCP receive window size. On your suggestion, I reduced it from the default(?) of 65536 to 32768 and so far so good. All 4 of my available HD channels seem happy: both video and audio working well. (Or no problems apart from the drivers for my HD card being a bit dodgy at times!) HD recordings seem to be fine too.

CPU usage varies about 40-50%, depending on the channel (presumably with bit-rate). In comparison, SD stuff seems to be around 25-30%. I'll try to test HD stuff a bit more thoroughly.

One thing I've also spotted is that SD recordings and live TV give me LOTS of "[mp3 @ 0x47127b20] incorrect frame size" messages if I run "vompclient -n". I guess this is because it's an MP2 stream being decoded by CODEC_ID_MP3. No problem with the decoding, though and avcodec.h has "CODEC_ID_MP3, ///< preferred ID for decoding MPEG audio layer 1, 2 or 3"! They could probably be quietened with a call to av_log_set_level()!

Cheers,

Laz

[MartenR]

incorrect frame size"

You can ignore these messages. I am just too lazy to implement a parser of the mpeg audio header to set the right frame size.
Except for the messages it cause any harm.

Marten