[Dilligaf]

Skins are cool but, my advise would be to not mess with them until you have your system up and running stably , why add another variable into the mix.

[RealDealNeil]

I'm pretty sure 1080i requires a higher bandwidth than 720p (i.e. more pixels per frame). The Pi is capable of normally playing back 720p and 1080i files, so it seems strange that it would stutter on live streams. What codec do the streams use?

Have you tried a different, lightweight back-end (e.g. TVHeadend) to isolate the problem? If the problem doesn't go away, then maybe the Pi truly is at fault. I think many would like to know more about the Pi's limitations before trying setting up PVR.

As I understand it, 1080i is interlaced so that it alternates between sending even and odd rows in each frame. Therefore, only 540 lines are sent each frame but it is so fast that the illusion of 1080 lines is there. Whereas 720p sends 720 rows in every frame (better for sports with fast motion). This would make 720p more heavy to render than 1080i.

I also confirmed that all my channels use dolby digital (even 720p) so it's not decoding DTS audio. My next step would be to try a different back-end, although MediaPortal works fine to my main HTPC.

[AndroiDad75]

OK. I am confused, which isn't new. I would like to get this and put it in my bedroom. All my files have been 1:1 rips using makemkv with both HD and core as audio.

Am I understanding that I can't just plug this into my TV with HDMI and have it play the audio? I do not think my TV can decode DTS or Dolby. I would rather not have to take all my mkvs and create a new audio stream.

Am I understanding this correctly?

[wejones]

I dont even know what 4.2.2 is, but if you can point me to a sample video, I can try it for you.

edit: scratch that, I dont have an mpeg2 license. Maybe Ill order one..

.....

Didn't see the edit soon enough. I uploaded a very short 15 sec MPEG2 clip of a 4.2.2 network show that I just recorded.
http://www.eskerridge.com/bj/sat/test4.2.2b.mpg
I'll leave it there or a day, and if you ever get the license you can try it if nobody else knows for sure if it will work.
I don't know much about exactly what the 4.2.2 is, but most video is 4.2.0. It's supposed to be the chroma info, and the numbers relate somehow to how many frames of different types of color info are sent, so 4.2.2 has more color info than 4.2.0.
CBS uses 4.2.2 in their feeds to the stations, and some of the other networks do too. Programs like VLC can do it, but most sat receivers don't.

If I can remember where I've seen it, I'll try to find a clip of MPEG4 4.2.2 . It's not as common as the MPEG2 version.

[Vertigo]

OK. I am confused, which isn't new. I would like to get this and put it in my bedroom. All my files have been 1:1 rips using makemkv with both HD and core as audio.
Am I understanding that I can't just plug this into my TV with HDMI and have it play the audio? I do not think my TV can decode DTS or Dolby. I would rather not have to take all my mkvs and create a new audio stream.
Am I understanding this correctly?

Indeed, you understood correctly.
You would either need to buy something more powerful than the Pi to decode the DTS signal, perhaps use a plex server or run avconv on your collection to convert or add a stereo audio track. Its not ideal, but only takes about 5-10 minutes per DVD and can be scripted.

---

I'm pretty sure 1080i requires a higher bandwidth than 720p (i.e. more pixels per frame). The Pi is capable of normally playing back 720p and 1080i files, so it seems strange that it would stutter on live streams. What codec do the streams use?

Have you tried a different, lightweight back-end (e.g. TVHeadend) to isolate the problem? If the problem doesn't go away, then maybe the Pi truly is at fault. I think many would like to know more about the Pi's limitations before trying setting up PVR.

As I understand it, 1080i is interlaced so that it alternates between sending even and odd rows in each frame. Therefore, only 540 lines are sent each frame but it is so fast that the illusion of 1080 lines is there. Whereas 720p sends 720 rows in every frame (better for sports with fast motion). This would make 720p more heavy to render than 1080i.

Either way, the Pi can decode 720p with ease. Is it possible its a network issue? Could you copy a test file to some local storage on the Pi and see if that works?

[Dilligaf]

As I understand it, 1080i is interlaced so that it alternates between sending even and odd rows in each frame. Therefore, only 540 lines are sent each frame but it is so fast that the illusion of 1080 lines is there. Whereas 720p sends 720 rows in every frame (better for sports with fast motion). This would make 720p more heavy to render than 1080i.

I also confirmed that all my channels use dolby digital (even 720p) so it's not decoding DTS audio. My next step would be to try a different back-end, although MediaPortal works fine to my main HTPC.

But you're not taking the width into consideration, 1920 vs 1280, 1920 is 50% more than 1280

[Dilligaf]

To clarify
720p 720 x 1280 = 921600 pixels
1080p 1080 x 1920 = 2073600 pixels
1080i 540 x 1920 = 1026800 pixels

so 1080i has more pixels then 720 and is therefore "heavier"

[wejones]

To vertigo and the others who answered my questions above. I downloaded the raspbmc and openelec images today, and tried both.
I must have gotten a corrupted download of the raxpbmc, as it gave errors when trying to run. However the openelec version worked.
I tried my 12.5 Mbps MPEG4 video, and it worked perfectly, which is great. I also tried a similar mpeg2 file, and as expected, it wouldn't play, just like before. I also got my new RPi in the mail today, so I think I'll buy the MPEG2 license since it worked well on MPEG4.
I am still having a couple problems with a few other problems, but I think it's probably better to ask in another section.

Anyway, thanks for the help. I've been trying for a couple weeks now to get video playing on this thing, so this is great. Next task is to try to get it to take video from either a network stream or from a DVB receiver, which I assume must be possible.

Thanks.

[AndroiDad75]

Indeed, you understood correctly.
You would either need to buy something more powerful than the Pi to decode the DTS signal, perhaps use a plex server or run avconv on your collection to convert or add a stereo audio track. Its not ideal, but only takes about 5-10 minutes per DVD and can be scripted.

Bummer. I was hoping I was wrong. I just wanted something cheap to throw into the bedroom that would work with XBMC just plugged into my TV, streaming on my CAT5. I didn't really want to have to buy a receiver.

[Mick1152]

You would either need to buy something more powerful than the Pi to decode the DTS signal, perhaps use a plex server or run avconv on your collection to convert or add a stereo audio track. Its not ideal, but only takes about 5-10 minutes per DVD and can be scripted.

I have to disagree with this. I have 4 Raspberry Pi's and none of them have issues decoding DTS themselves using XBIAN. XBIAN has slight overclocking by default, I would imagine you should get similar results with the other distros and some overclocking. DTS-HD is a no go, but DTS and DD are doable for the Pi when overclocked.

I have a Pi on both of my kids' TV's and one I use in my RV for watching movies and TV shows from a portable hard drive when travelling. My 4th one has been just a screw around extra Pi that has already been used for several different things but at this point it looks like it is going to get a custom case with hard drive enclosure and a battery to make a portable, battery powered media player for my dad's sail boat.

I love these things and cant' recommend them enough for their price. Of course, I've had a lot of fun building fashioning my own cases for them. Wish I had a picture to show right now but I used an old PS3 gift card tin I got years ago and put one of the Pi's in there. By far my favorite case.

[Vertigo]

I have to disagree with this.

I may have to disagree with myself
OKay, so I never tried it, since I do have a DTS receiver, but I read it everywhere and assumed it to be true. And perhaps it is true with some files or formats, but I just tried with a few of my videos, all 1080p h264 with DTS. Most are around 5-8 GB per movie and rarely peak over 10GBps, but one short movie peaks around 29 Mbps. All files played from a local USB drive. I set audio output to analog stereo to force the Pi to decode it, and its playing them back without issue.

Now I wont promise the Pi will do any video this way, but I guess its incorrect to just assume it cant do DTS decoding at all.

update: playing back the same movie over the LAN rather than from a local drive, the Pi does stutter during the high bitrate peaks.
Interestingly, when playing the same file on my laptop while being served from the Pi, it does work. So I guess its not purely network bandwidth thats lacking, perhaps its the combination of IO needed for the LAN and decoding that hits a bottleneck somewhere.

[voochi]

I may have to disagree with myself
OKay, so I never tried it, since I do have a DTS receiver, but I read it everywhere and assumed it to be true. And perhaps it is true with some files or formats, but I just tried with a few of my videos, all 1080p h264 with DTS. Most are around 5-8 GB per movie and rarely peak over 10GBps, but one short movie peaks around 29 Mbps. All files played from a local USB drive. I set audio output to analog stereo to force the Pi to decode it, and its playing them back without issue.

Now I wont promise the Pi will do any video this way, but I guess its incorrect to just assume it cant do DTS decoding at all.

update: playing back the same movie over the LAN rather than from a local drive, the Pi does stutter during the high bitrate peaks.
Interestingly, when playing the same file on my laptop while being served from the Pi, it does work. So I guess its not purely network bandwidth thats lacking, perhaps its the combination of IO needed for the LAN and decoding that hits a bottleneck somewhere.

Yes basically DTS decoding requires a certain amount of resources and depending on what the rest of the system is doing you may push it over the limit.

When you have a very weak system and you are right on the limit, every little thing counts because memory, cpu cycles etc are in short supply.

[watanave]

Hola,

This thread has been so informative, thanks to all of you. I have a question regarding 5.1 96/24 or 2.0 192/24 flac files. Does the Pi be able to decode those files without a problem?

Gracias...

[noggin]

I dont even know what 4.2.2 is, but if you can point me to a sample video, I can try it for you.

edit: scratch that, I dont have an mpeg2 license. Maybe Ill order one..

.....

Didn't see the edit soon enough. I uploaded a very short 15 sec MPEG2 clip of a 4.2.2 network show that I just recorded.
http://www.eskerridge.com/bj/sat/test4.2.2b.mpg
I'll leave it there or a day, and if you ever get the license you can try it if nobody else knows for sure if it will work.
I don't know much about exactly what the 4.2.2 is, but most video is 4.2.0. It's supposed to be the chroma info, and the numbers relate somehow to how many frames of different types of color info are sent, so 4.2.2 has more color info than 4.2.0.
CBS uses 4.2.2 in their feeds to the stations, and some of the other networks do too. Programs like VLC can do it, but most sat receivers don't.

If I can remember where I've seen it, I'll try to find a clip of MPEG4 4.2.2 . It's not as common as the MPEG2 version.

4:2:2 is the standard format used within broadcasters. It means that for every 4 Y (luminance) samples in a line there are 2 Cr (R-Y chroma difference) and 2 Cb (B-Y chroma difference) samples. This means that the chrominance has the same vertical resolution as the luminance and half the horizontal resolution.

4:2:0 is the standard format used for the final leg of broadcasting to the home (DVB, ATSC, ISDB all use it) and for Blu-ray, DVD etc. It means that for every 4 Y samples there are 2 Cr samples on one line, and 2 Cb samples on the next line (i.e. you only get Cr or Cb samples on alternate lines). This means that the chrominance has half the horizontal AND half the vertical resolution of the luminance.

Consumer hardware used to be 4:2:0 only - however I noticed that my WDTV live is fine with 4:2:2 MPEG2 stuff recorded from satellite (though not 4:2:2 H264 stuff).

---

As I understand it, 1080i is interlaced so that it alternates between sending even and odd rows in each frame. Therefore, only 540 lines are sent each frame but it is so fast that the illusion of 1080 lines is there.

Kind of. For static and slow moving information - where there is no movement between the two 1080i fields - decent de-interlacers should deliver vertical resolution closer to 1080p (though most interlaced cameras use a clever frame-line-offset line-pairing algorithm to derive their 540line fields from their source 1080p - or in some cases 4320p - sensors) Only on fast motion does the vertical resolution drop to that of a 540p system.

However on all motion the horizontal resolution should be 1920 (compared to 1280 for 720p) - though some transmission systems use 1440x1080 or even 1280x1080 to save bandwith.

Whereas 720p sends 720 rows in every frame (better for sports with fast motion). This would make 720p more heavy to render than 1080i.

Nope :
1920x540 = 1036800 luma samples
1280x720 = 921600 luma samples

So there are still more samples to render with a 1080i field than a 720p frame. So if you are comparing 1080/60i with 720/60p you still have more samples/pixels to render with 1080i.

If you are also de-interlacing 1080i then you need even more grunt to do a decent job.

720p is lighter to render as it has fewer pixels/samples and no de-interlacing requiremnt.

[Vertigo]

Hola,

This thread has been so informative, thanks to all of you. I have a question regarding 5.1 96/24 or 2.0 192/24 flac files. Does the Pi be able to decode those files without a problem?

Gracias...

I just tried a sample, and it played back ok, but only as PCM 2.0 on my AVR. I think this is an XBMC limitation, not a Pi specific issue. Maybe the new AudioEngine fixes this, but I dont have that on my Pi yet.