Raspberry Pi for XBMC, some myths and truths
#61
(2013-01-25, 09:48)Vertigo Wrote: 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.

When playing back over LAN, use NFS shares instead of SMB. The SMB "stuff" on the Pi takes up more resources and uses enough that it can cause stutters when decoding DD or DTS on the CPU. Otherwise, playing from USB drives works just fine as well.
HTPC 1 - AMD A8-3870K, ASRock A75M, Silverstone ML03B, Kingston HyperX 4GB DDR3 1866, Crucial M4 64GB SSD
HTPC 2 - HP Stream Mini, 6GB Ram
unRAID 6 Server - Intel Celeron G1610, 20TB Storage

Reply
#62
(2013-01-25, 18:00)Mick1152 Wrote: When playing back over LAN, use NFS shares instead of SMB. The SMB "stuff" on the Pi takes up more resources and uses enough that it can cause stutters when decoding DD or DTS on the CPU. Otherwise, playing from USB drives works just fine as well.

Ah, thats good to know. I dont know anything about NFS, but Ill look in to it, thx for tip.
Reply
#63
(2013-01-25, 14:25)noggin Wrote: .......
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).
...

Thanks for the more accurate description. You're right, that all the stuff aimed at the home viewers in the US is 4.2.0. The US network stuff I used to see on satellite used to be all 4.2.0, except NBC used to have backhauls that were 4.2.2. About 3 years ago CBS started sending out all their HD feeds to the stations in 4.2.2. I think that ABC and NBC still send out 4.2.0 stuff to the stations, as does PBS. I'm not sure about FOX, as they are usually encrypted. So I guess that within the networks, they all use 4.2.2 , but some send 4.2.2 to affiliates, and others send 4.2.0?
There are a couple consumer FTA sat receivers that play 4.2.2. I have an Azbox which does. I don't think any subscription type receiver would. VLC plays MPEG2 4.2.2 fine.
I can't remember where I saw mention of 4.2.2 H264 stuff on sat. I've never run into it myself, but I've seen posts about it in a forum, and was hoping I could search for it and try to record some to try.
Thanks.
Reply
#64
...
Reply
#65
(2013-01-25, 18:37)wejones Wrote: I can't remember where I saw mention of 4.2.2 H264 stuff on sat. I've never run into it myself, but I've seen posts about it in a forum, and was hoping I could search for it and try to record some to try.
Thanks.
Broadcasters are increasingly shifting from 4:2:2 MPEG2 to 4:2:2 H264 for backhaul from outside broadcast sites as it allows a reduction in bitrate for the same picture quality. I believe at least one US broadcaster is using 4:2:2 H264 to distribute their network feed to their affiliates.
Reply
#66
BTW, relative to earlier discussion above, yesterday, I bought the MPEG2 license for my new RPi. Got it in the email today, and tried it. It worked fine as expected on regular 4.2.0 PBS HD. However I tried to play my CBS test recording of 4.2.2 video, and it wouldn't play. So apparently the hardware on the RPi doesn't handle 4.2.2 . I play 4.2.2 fine on my Windows PC which has Radeon HD 4250 on board video hardware acceleration. VLC uses the hardware acceleration. That computer is dual boot with Ubuntu linux, so perhaps I should put XBMC on that computer to see if it is able to use the hardware there too.

Reply
#67
(2013-01-25, 16:41)Vertigo Wrote:
(2013-01-25, 14:19)watanave Wrote: 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.

Thanks, Vertigo.

Only for check... Does your configuration in System -> Audio Output -> Speaker configuration indicates 2.0 or other combination?

Bye.
Reply
#68
(2013-01-26, 19:35)watanave Wrote: Only for check... Does your configuration in System -> Audio Output -> Speaker configuration indicates 2.0 or other combination?

5.1

Reply
#69
Ive uploaded a clip to youtube to show you XBMC on the Pi. Audio and video quality suck, but I thought it might interest some of you anyway:
Showing some 1080p mkvs with DTS decoding as well as youtube

http://www.youtube.com/watch?v=Bi9wh0d7v...e=youtu.be
Reply
#70
(2013-01-26, 19:40)Vertigo Wrote:
(2013-01-26, 19:35)watanave Wrote: Only for check... Does your configuration in System -> Audio Output -> Speaker configuration indicates 2.0 or other combination?

5.1

OK.

Gracias.
Reply
#71
(2013-01-26, 18:13)wejones Wrote: BTW, relative to earlier discussion above, yesterday, I bought the MPEG2 license for my new RPi. Got it in the email today, and tried it. It worked fine as expected on regular 4.2.0 PBS HD. However I tried to play my CBS test recording of 4.2.2 video, and it wouldn't play. So apparently the hardware on the RPi doesn't handle 4.2.2 . I play 4.2.2 fine on my Windows PC which has Radeon HD 4250 on board video hardware acceleration. VLC uses the hardware acceleration. That computer is dual boot with Ubuntu linux, so perhaps I should put XBMC on that computer to see if it is able to use the hardware there too.

Yep - we'd expect Raspberry Pi to be fine with 4:2:0 stuff. 4:2:2 would have been a pleasant surprise!

I can't remember whether I've tried 4:2:2 MPEG2 or H264 in Linux XBMC on either of my main machines (Core2Duo + nVidia 9400 on-board and Core i7-2600K + ATI 5xxx series GPU) but I know it played find in Windows (Media Player Classic Home Cinema - not sure about XBMC)
Reply
#72
To follow up on my issues streaming live TV w/ a MediaPortal back-end, switching the streaming method from TSReader to ffmpeg resolved the buffering issues. TSReader works well on my living room HTPC, but on the RPi, it must be difficult to stream raw buffer files over SMB.
Reply
#73
(2013-01-28, 19:01)RealDealNeil Wrote: To follow up on my issues streaming live TV w/ a MediaPortal back-end, switching the streaming method from TSReader to ffmpeg resolved the buffering issues. TSReader works well on my living room HTPC, but on the RPi, it must be difficult to stream raw buffer files over SMB.

The Pi has issues with playing media over SMB shares so I would assume SMB is going to be the issue here. Is there anyway to stream over NFS? NFS works great for streaming media.
HTPC 1 - AMD A8-3870K, ASRock A75M, Silverstone ML03B, Kingston HyperX 4GB DDR3 1866, Crucial M4 64GB SSD
HTPC 2 - HP Stream Mini, 6GB Ram
unRAID 6 Server - Intel Celeron G1610, 20TB Storage

Reply
#74
(2013-01-28, 19:01)RealDealNeil Wrote: To follow up on my issues streaming live TV w/ a MediaPortal back-end, switching the streaming method from TSReader to ffmpeg resolved the buffering issues. TSReader works well on my living room HTPC, but on the RPi, it must be difficult to stream raw buffer files over SMB.

If you're streaming from TSREADER, I'm not sure I understand why SMB would be involved? I often use a ROKU HD1000 (which is a Linux box), and I can either play recorded files via SMB shares, or I can stream via HTTP from TSREADER. It's been a long time since I checked this out, but if I remember right, the SMB shares maxed out somewhere around 29 Mbps, whereas I could stream at rates up above 40 Mbps from TSREADER. So it's always been my impression that even though when you look at the transfers with a packet sniffer, they look pretty much the same, that the live HTTP streaming was faster than playing a recording from an SMB share. Just an observation.

However, just today, I tried setting up my OpenElec-XBMC for local OTA channels via my HDHomeRun. I got it working thanks to some help on another thread, however it was doing pretty much what you described earlier, ie relative to the part about every 10 seconds it pausing for buffering, although in my case it would eventually freeze. I was surprised, since the bitrate of the OTA video was lower than stuff I've played from SMB shares coming over the same Gb lan. I tried it on 3 different channels 2 were 1080i, and one was 720p, but they all behaved the same, and actually, the one that worked best was the one with the highest bitrate.

Something strange that I couldn't quite see long enough to read, was that when it quickly popped up some buffering thing, I could read something that said "720", even though the source and my TV setup was all 1080i. I was wondering if somehow there were 720p<-->1080i conversions going on that's slowing things downHuh But then I guess I can't explain why it wouldn't be the same for recordings from SMB?

The other thing that I haven't verified, was that I tried playing from SMB onto 2 different TVs. The SMB playback went smoothly on both, however the smaller of the two TVs seemed to work better, ie I was seeing some digital artiacts on the bigger TV that I don't remember seeing there when playing via Windows. Size obviously isn't an issue, but the smaller TV I think is native 720p, while the bigger TV is native 1080p. Makes me wonder if regardless of the settings, the RPi might be 720p and converts to 1080, and it might be that there are several back and forth conversions going on. One other possibility is that I had adjusted the output to my big TV to compensate for significant overscan on the TV. Perhaps that is slowing things down there too.

Anyway, just throwing out a few things that came to mind, since what you're doing is something I also wanted to try, and the problems you're having seem similar to what I saw via HDHR. So I hope you post if you find out more.

Also, since I haven't done it, I'd appreciate a PM regarding how you set up the streaming from TSREADER in XBMC.
Thanks.

Reply
#75
Hi.

What happen if my HT system isn't able to handle DTSHD/TrueHD (only DTS and DD) and I set DTS and DD capability settings in the XBMC?
RPi will pasthrough the hd soundtrack and receiver can get DTS/DD or this isn't working?
Reply

Logout Mark Read Team Forum Stats Members Help
Raspberry Pi for XBMC, some myths and truths 4