[james25182]

Hi,

I've been using Openelec 2.0 on an ASRock Ion 330 with TVHeadend backend. With standard definition channels all is well but as soon as I try to watch HD content from the backend it starts freezing and stuttering and is unwatchable. This is the same for live and for recorded HD content. The content plays fine if viewed with VLC so the problem doesn't seem to be the backend.

I've turned on debug logging and I get lots of errors like this:

ERROR: ffmpeg[E8C]: [h264] Failed to begin frame
ERROR: ffmpeg[E8C]: [h264] hardware accelerator failed to decode picture

I tried it on my desktop machine running Windows and XBMC 11 which has a much more powerful graphics card and had the same issue. However, if I turned off hardware accelerated decoding the content played smoothly. Naturally, I can't do this on the ASRock HTPC as the dual-core Atom isn't up to software decoding!

Is there an issue with the hardware decoding of HD content on UK Terrestrial TV? I notice it's broadcast in 1080i if that's the issue.

What can I do to get HDTV working?

Thanks,

James

[Prof Yaffle]

Can you post a sample file anywhere? If so, I'll have a look on my system - Openelec 2.0 on a Revo R3600 and R3700, but they're ION systems as well, albeit of different ages. At least we'll eliminate whether it's your source or the client that's struggling.

I can reciprocate if you wish, and quickly record some BBC HD or similar so you can test in reverse.

I'm not aware of the problem on my system(s), by the way.

[james25182]

Hi Professor,

Thanks for the reply - and sorry it's taken me so long to do the same. Kids are a huge time sink!

I've uploaded a short ~30 second recording from BBC HD which stutters and jumps on my openelec ION system. It's available here:

http://speedy.sh/FgupX/The-Dark-Ages-An-...2-12-02.ts

It's about 16MB.

If you could upload a short BBC HD clip in return that would help in my diagnosis.

Thanks again.

James.

[Prof Yaffle]

I need to reciprocate the delay, I'm afraid - I'm out of the country at the mo' - but I'll test on the weekend and upload something in return for you.

Cheers...

[Prof Yaffle]

Right, here now - apologies for that.

Your clip plays perfectly on both of my Linux ION systems (OpenElec on a D525 @ 1.8GHz with Nvidia 295.71 and an older 230 @ 1.6GHz running XBMCLive/Ubuntu 11.10 with Nvidia 304.6). I tried it on a non-ION WinXP ATOM system as well, and that just choked without hardware acceleration, as you say. And finally, I also fed it to a Core i5 Win7 box, and that was quite happy (no idea if acceleration was on, it doesn't need it!).

I've grabbed a couple of recordings for you - the first is MKV, split down to 30s with mkvmerge:

http://www.datafilehost.com/download-ca4cefcf.html

... and the second is TS, split with avidemux:

http://www.datafilehost.com/download-b08a30fd.html

I've given you both formats in case that helps with diagnostics... I've also split using passthrough so the underlying streams should be untouched.

One thought: cutting these files may still have altered the stream, so we probably need to be thinking about the original, unaltered, as-it-came-off-the-presses files, despite the size.

Another one: since you're using .TS, have you thought about running it through ProjectX to see if that fixes anything? Or even remuxing it? I just have always had issues with TS despite everyone else on the planet being perfectly happy with it, so I'm just suspicious by nature...!

Now the bad, I'm-an-idiot news: as I'm writing this, I've realised that these are from a DVB-S2 source, not DVB-T2 - I don't have HD DVB-T, I'm afraid, so I may have been leading you astray on that, sorry. Should've read your original post more carefully... but at least your file plays okay on my systems, if that helps at all!

[FernetMenta]

Maybe it's related to audio. Is audio LATM on those channels?

[Prof Yaffle]

@FernetMenta - looks like, ffmpeg -i on the OP's sample says:

Code:

Input #0, mpegts, from 'The Dark Ages- An Age of Light.2012-12-02.ts':
  Duration: 00:00:25.44, start: 63657.501622, bitrate: 5159 kb/s
  Program 1
    Stream #0:0[0x65]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 90k tbn, 50 tbc
    Stream #0:1[0x66](eng): Audio: aac_latm ([17][0][0][0] / 0x0011), 48000 Hz,stereo, s16
    Stream #0:2[0x6a](eng): Audio: aac_latm ([17][0][0][0] / 0x0011), 48000 Hz,stereo, s16
    Stream #0:3[0x69](eng): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)

However, the same -i throws pages of errors like these, and I've no idea if they're relevant (they're probably the normal TS noise):

Code:

[h264 @ 00bad1c0] non-existing SPS 0 referenced in buffering period
[h264 @ 00bad1c0] non-existing PPS referenced
[h264 @ 00bad1c0] non-existing SPS 0 referenced in buffering period
[h264 @ 00bad1c0] non-existing PPS 0 referenced
[h264 @ 00bad1c0] decode_slice_header error
[h264 @ 00bad1c0] non-existing PPS 0 referenced
[h264 @ 00bad1c0] decode_slice_header error
[h264 @ 00bad1c0] non-existing PPS 0 referenced
[h264 @ 00bad1c0] decode_slice_header error
[h264 @ 00bad1c0] non-existing PPS 0 referenced
[h264 @ 00bad1c0] decode_slice_header error
[h264 @ 00bad1c0] non-existing PPS 0 referenced
[h264 @ 00bad1c0] decode_slice_header error
[h264 @ 00bad1c0] non-existing PPS 0 referenced
[h264 @ 00bad1c0] decode_slice_header error
[h264 @ 00bad1c0] no frame!
[h264 @ 00bad1c0] mmco: unref short failure

Interestingly, the DVB-S2 TS file I recorded doesn't show LATM (unless I'm misunderstanding the output):

Code:

Input #0, mpegts, from 'BBC HD Test - ts.2012-12-08.12-00.ts':
  Duration: 00:11:01.10, start: 47143.045200, bitrate: 7511 kb/s
  Program 1
    Stream #0:0[0x157c]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
    Stream #0:1[0x157e](nar): Audio: mp2 ([4][0][0][0] / 0x0004), 48000 Hz, stereo, s16, 256 kb/s
    Stream #0:2[0x1580](eng): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)
    Stream #0:3[0x157d](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, 5.1(side), s16, 384 kb/s
  No Program
    Stream #0:4[0x157f]: Unknown: none
At least one output file must be specified

... so let's see if that plays correctly on the OP's system, that'd be helpful information.

Remuxing the original file and re-encoding the audio stream would then be a useful test, I suppose.

[FernetMenta]

Currently I am investigating LATM issues for VNSI which is basically the same code as for hts in terms of LATM. Unfortunately I have no LATM channels on DVB-S2.
I am working on a test harness to feed recordings to the live demuxers.

[Prof Yaffle]

@james - I've quickly resampled the audio on your original sample (so it's AC3 instead of AAC now) using avidemux - see if that makes any difference whatsoever.

http://www.datafilehost.com/download-d5f541b7.html

@FernetMenta - if the problem is in the back end, could it be too late for a recording like this? I'm just wondering whether the issues you mention would permanently corrupt the file in some way (though that wouldn't explain why I can play it, of course...) - if so, no amount of resampling will necessarily fix it unless the process corrects a sync issue or similar.

(Couldn't you just play files on something like VLC and then add it to as a live IPTV steam, btw?)

[FernetMenta]

tvheadend and vnsi are the only backends which use a optimized protocol for live TV. This has its own demuxers. Recordings and other live streams use ffmpeg parser/demuxer.
I am not sure how tvheadend does recordings but vdr just records the mpeg-ts stream which comes from the dvb card and adds pat/pmt. It would surprise me if tvheadend used live demuxers for recordings. This means that recordings work fine whereas live tv does not.

[james25182]

I haven't managed to try the files you sent on my Ion system but did on my desktop. They both played fine. The resampled file that you uploaded had the same dreadful stuttering still so it's unlikely an audio issue. I'll try them on my Ion system as soon as I can.

I've tried tvheadend in both .ts and .mkv formats with the same results. The stuttering happens on both live and recorded TV.

I'm really struggling to think what the common cause of this is as I've got the same issue on two separate systems running different operating systems. The only thing in common is that they both use the nvidia hardware decoder. You mention Nvidia 295.71 on Openelec. Is that a driver version? I thought the driver was built in to openelec?

Not sure about the vlc and iptv stream - sounds like it wouldn't be very wife-friendly though.

Once again, I appreciate your help!

[Prof Yaffle]

Yes, the 295.71 is the driver version - and yes, it's built into OpenElec, but it still gets reported by XBMC on the System -> System Info -> Video page. But you can't change it easily, you're right.

Random thought time, no particular order... apologies if any of these are bleedin' obvious, I'm just thinking aloud!

• Are you using the ION build of OpenElec? Just to make sure you have VDPAU support... 32- or 64-bit build? Any difference if you try the other one? (I actually use the Pulse-Eight build, so it's not 'pure' OE 2.0)
  
  
• You have VDPAU acceleration switched on, yes? System->Settings->Video->Playback
  
  
• Can you change (increase) the video RAM in the BIOS, or are there any other settings of note in there?
  
  
• When playing the file, press i to call up the video information - what gets revealed there in terms of CPU load, video queue length, CODEC, etc.?
  
  
• What happens if you re-wrap into, say, avi without re-encoding anything?
  
  
• Can you re-encode the video stream to H.264 High (e.g. with Handbrake), does that still show problems? Can you encode it to MPEG2, does that? Does it only happen on H.264-encoded files...?
  
  
• What medium are you using for the files - is it over the LAN (wired, wireless, mirrors, carrier pigeon, NAS, NFS, CIFS...?), is it on SSD, HDD, USB, ink-on-parchment?
  

(The VLC comment was a random thought on how FernetMenta could perhaps stream a recording into VNSI/TVH as if it were a live feed - really not the same WAF as OpenElec, though, so not recommended for home use!)

[FernetMenta]

@james25182, can you post a debug log?

[james25182]

Hi,

I had a chance to try a few things yesterday on the ION system. All those files failed to play properly on the ION system with exactly the same choppiness.

Thanks for random thoughts - here are my random replies:

I am using x64 ION build.
VDPAU acceleration is on
VRAM set at maximum (256MB, I think)
On screen display shows huge numbers of dropped frames. I didn't note the VQ or other parameters. I'll try to have another look later.
Haven't tried a re-wrap but I think .ts and .mkv are just different wrappers of the same content so will probably have the same problem.
Will try some re-encodes and report back.
tvheadend and the content is stored on an Ubuntu box streaming over wired LAN using Samba. Content is on an HDD.

Here's a debug log from trying to play live TV yesterday evening:

http://pastebin.com/skxxcyxR

Two other things I noted - on my desktop system I see the same choppiness with HDTV content but when I tried Frodo Beta 3 it seemed to work fine. Might try the openelec beta based on it to see what happens. Also noted that the temperature of my GPU in the ION system is at about 85 degrees when just running the GUI. Could it be overheating and throttling? Although, that wouldn't explain why it's choppy on my desktop...

[FernetMenta]

I think the main problem is your limited VRAM. The vdpau improvements in OE require a bit more VRAM than the implementation in mainline.

In OE 3 that is an additional settings for vdpau "interop YUV". Enable this and set de-interlacing to Bob (NOT vdpau Bob).

Don't worry about 85 degrees as long as it does not hit the limit which I think is 105 or so.