Raspberry Pi Forums

I have a lot of UK TV recordings.

The sd recordings are in .ts mpeg 2 format. They work fine with mpeg2 hardware decoder after bought license.

The hd recordings are in .ts format. Windows says they are mpeg2 also but I am not sure.
This is the media info for one of the files:

===================== General =====================
Id : 4
Complete name : \\HOMESERVER\Recorded TV\ITV1 HD\The X Factor\The X Factor - 2012-10-13.ts
Format : MPEG-TS
File size : 11.1 GB
Duration (ms) : 2h 25mn
Total bitrate : 11.0 Mbps

===================== Video =====================
Id : 48 (0x30)
MenuID/String : 137 (0x89)
Format : AVC
Format info : Advanced Video Codec
Format profile : Main@L4.0
Use of CABAC : Yes
RefFrames : 4 frames
Format settings - GOP : M=1, N=24
Codec Id : 27
Duration (ms) : 2h 25mn
Bitrate : 9 987 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Aspect ratio : 16:9
Framerate : 25.000 fps
Colorimetry : YUV
Colos space : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
ScanOrder/String : Top Field First
Bits/(Pixel*Frame) : 0.193
Stream size : 10.1 GB (91%)
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

===================== Audio #1 =====================
Id : 64 (0x40)
MenuID/String : 137 (0x89)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Codec Id : 4
Duration (ms) : 2h 25mn
Bitrate mode : Constant
Bitrate : 192 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Video_Delay/String : -229ms
Stream size : 199 MB (2%)

===================== Audio #2 =====================
Id : 65 (0x41)
MenuID/String : 137 (0x89)
Format : AC-3
Format info : Audio Coding 3
Format settings mode extens : CM (complete main)
Codec Id : 6
Duration (ms) : 2h 25mn
Bitrate mode : Constant
Bitrate : 256 Kbps
Channel(s) : 2 channels
ChannelPositions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Video_Delay/String : -308ms
Stream size : 266 MB (2%)
Language : English

===================== Text #1 =====================
Id : 80 (0x50)
MenuID/String : 137 (0x89)
Format : DVB Subtitle
Codec Id : 6
Language : English

===================== Text #2 =====================
Id : 107 (0x6B)-888
MenuID/String : 137 (0x89)
Format : Teletext Subtitle
Language : English

So are these hd recordings in mpeg2 format ? It says mpeg but then it says AVC .
Also when playing on xbmc it comes up as: D(Video: h264 (Main)

The other thing is these videos no longer play in xbmc with the latest updates/changes. I'm not sure whats causing them to not work now.
If you try using xbian 0.83 or raspbmc rc 5 all you get is a black screen, or a grey screen but you can hear the sound.

If you go back to an earlier release like xbian 0.62 which is running linux kernel 3.1.9 they work fine and play well.

Any ideas whats happened in the latest changes and why these no longer work.

If

Are you sure that during your upgrades you didn't remove the licence key from the card?

I notice that the recording that you are trying to play is a HD .ts from ITV1 HD. I THINK that is mpeg4 and not mpeg2.

I think the UK freesat SD channels are mpeg2 and the HD are mpeg4 avc. I think mpeg4 avc is the same as h.264 (not to be confused with mpeg4 part 2 which is used by xvid etc). Both should be supported by the pi's GPU.

ITV HD Video is mpeg4. These did play with XBMC. I have also noticed that now they do not play. Video's from BBC1 HD and BBC HD played sometimes but not always. I suspect the ITV HD problem is something to do with an XBMC update and will in time sort itself out.

If anybody in UK has a 512 version Raspberry and a recent incarnation of XBMC checking if ITV HD played on it might be a useful diagnostic test.

Ok so these hd channels are not mpeg 2.

They seem to play without the mpeg 2 codec in the config so I guess they are mpeg4 or something.

I'm not sure why windows say they are mpeg 2 then.

I'm not sure if its a xbmc problem. Using a windows computer and same xbmc version they play fine.
Maybe linux version is different.

Would be good to find out why they no longer play.

Also they take a long time to load and start playing. Around 20-25seconds before it starts playing :S

sorry to be flippent but

The X Factor\The X Factor - 2012-10-13.ts

I believe that your RPi has got a good taste not to show this ;-p

The file is h264 (aka AVC) in an mpeg transport stream container.
This was broken recently. The ARM used to do a fairly expensive bitstream conversion of these files which is something the GPU can handle so the conversion was removed.
However some files still need the type of encapsulation to be indicated to the GPU. This is being looked at.

Thank you, hopefully it can be fixed again soon.

Please let me know if there is progress and when it should work again.

I guess when you get it working again with the gpu it will run better than before as it will be using the gpu now to decode instead of the arm ?

sorrowuk wrote:I guess when you get it working again with the gpu it will run better than before as it will be using the gpu now to decode instead of the arm ?

Yes, these types of files (containing NAL units delimited by start codes) were consuming 10-20% of ARM's CPU. So when they are working again, that CPU will be freed up.

Fix is pushed:
https://github.com/xbmc/xbmc/commit/b06 ... 1df9f12641

That was quick . Thanks.

So it should be included in the next xbmc nightly build after this time ?

sorrowuk wrote:So it should be included in the next xbmc nightly build after this time ?

Well there is no XBMC nightly. Raspbmc, openELEC and xbian may include it in their next builds.
I'm sure it will be there in a day or two.

Raspbmc have a new thing where you can download xbmc nightly's from inside there settings app in xbmc.

So might appear there in the next builds.

Anyway thanks for fixing.

Are these already properly handled in omxplayer?

Have just tried a new raspbmc build with a xbmc build which was compiled on the 20th october so I guess this fix is included.

However I am still having some problems.

The 1080i AVC (h264) recordings start playing now however they only play for about 5-10 seconds and then the picture freezes and then 5 seconds later the sound stops and it just sits there.

Happens on all my files of this type.

h264 1080p mkv files playing from the same location work fine.

Any ideas?

This applied to both new xbmc and raspbmc builds.

dom you able to take a look if you have a chance.

Other people are reporting the same with the new openelec and raspbmc builds on the forums.

The files play now for about 5 seconds then the picture freezes and sound freezes a few seconds after.

Technically these files should play as good as h264 mkv's shouldn't they

You'll need to post a sample file that is failing. Dropbox is good for this.

dom wrote:Yes, these types of files (containing NAL units delimited by start codes) were consuming 10-20% of ARM's CPU. So when they are working again, that CPU will be freed up.

Was that down to doing the Exp-Golomb decode on the ARM by any chance? Can't imagine the TS encapsulation itself would give any problems.

ps_bond wrote:Was that down to doing the Exp-Golomb decode on the ARM by any chance? Can't imagine the TS encapsulation itself would give any problems.

Just searching for 00 00 00 01 and replacing with length bytes takes a significant amount of ARM CPU at 40MBit/s.
Check out plots here:
http://www.uclinux.net/blog.html
Was determined that increase in ARM CPU for h264 vs MPEG2 was the NAL unit parsing.

I still maintain that standard (and MPEG2) was written to make hw/fw engineers' lives easier... Finding startcodes is a doddle if you've got hw that does it. Finding them in sw on a non-byte-aligned stream is a considerable PITA.

I am uploading 3 small samples now that I just recorded from 3 different hd channels.

Should be uploaded in 15 minutes

Here you go

Dropbox link : https://www.dropbox.com/s/8yx0aafaxaktu ... amples.zip

It has 3 clips I recorded from hd satellite channels using mediaportal.

For reference all sd mpeg2 clips play fine.

These clips will freeze around halfway through .

Dom, did you take a look at them files, interested to know what you thought was going on, and if it froze for you also when trying to play

Yes, I see the problem. XBMC seems to be pulling some dodgy timestamps out of the file.
If I replace them all with "unknown" the clips play correctly. I've asked Gimli to take a look.

Cool, thanks

Also I don't know if this is a specific raspberry pi xbmc problem, but when I use a windows computer and the windows version of the latest xbmc compiled nightly the files play back fine