My 54Mbps router can not transfer this fast enough for the pi to play smoothly. It only manages to buffer 2 seconds from the clip even if I pause in advance, because then it will wait for the clip to play those 2 seconds and only then rebuffer again the next 2 seconds and so on. If there was a way to make the pi buffer more than that in advance then it might be able to produce a watchable file by pausing for some time and letting the pi buffer enough of the clip off the slow network.
But the 2 other clips I talked about a few comments back were 720p and the network can certainly handle them in terms of speed. Something else is making them stutter during network streaming.
im not sure but i think that would not be possible to load more into buffer as there is a HW limitation of RPi,
but lets wait for devs to confirm
btw, if you have and outdated network system, maybe is a time to upgrade in HD era ?
indeed, yes RPi is capable to play much higher than 720p as I stream 1080p DTS easy
Im also able to stream video with 40+ Mb/s bitrate
over SMB
so really odd you having issue to play your files
I would see this as HW issue, but cant see what.It may be the PSU, PSU cable, SD Card, your network, ,
I dont see this would be RPi or software problem as majority of users, included me have no problems at all
What class is your SD Card? Class 10 is recommended.
(24th Dec, 2012 04:51 AM)Koenkk Wrote: [ -> ]What class is your SD Card? Class 10 is recommended.
Class 4.
Can this be an issue even though they play smoothly (720p) if I place them directly on the SD card?
Furthermore, like I said before:
Executed "sudo hdparm -tT /dev/mmcblk0" test and got:
Terminal
Timing cached reads: 162 MB in 2.00 seconds = 80.80 MB/sec
Timing buffered disk reads: 58 MB in 3.06 seconds = 18.96 MB/sec
These are said to be quite capable speeds.
I narrowed it down to being 2 issues with 2 separate 720p files:
1st is an issue with DTS audio. Via latest Openelec which is 12.0-RC2 it plays fine if I stream it by UPnP (probably the best protocol for my win7).
2nd is I think a codec issue with an .m4v file. If it is allowed I'd like to post a sample from the video so other people can try to stream it over their network. The problem is only when streaming and that is very strange since it's not a demanding file, higher bitrate files and with more complex HW needs play fine.
Both files codec detail etc. were posted a few comments back in to this thread:
http://forum.xbian.org/thread-96-post-886.html#pid886
I just read somewhere that a user who first used a class 6 card had stuttering problems. When he upgraded to a class 10 card these problems were solved.
I'm not too sure myself that testing the speed of the SD card by reading data from the SD card is a meaningful test. The operating system has to run from the SD card and the file is coming from network in the case you want. Does anybody know if any data even gets buffered to the SD card? I'm guessing that perhaps when viewing files from a network share, the system merely buffers as much as possible into the RAM and then plays it back. Thus the SD card may not be an issue. Would be interesting to check this with the Raspi XBMC developer (yes apparently there is only one).
Will a cheap class 10 30MB/s card from Sandisk suffice? 45MB/s-85MB/s ones cost considerably more here and I would like to keep my Pi related purchases economical.
8gb class 10 = +- 10 euros (brand : pretec)
Mine is an Icidu 8gb class 10, also 10 euro's.
Hello, some updates. 1st, regarding 720p files that stutter over network stream, it is codec issues for sure. The problems with one type of file was DTS- known issue, and some versions of XBMC for RPi managed to solve (or almost) the issue. In other words 720p files play fine now.
One exception is an M4V file of what was labelled "WEB RIP" so there might be some unconventional encoding involved. The file SHOULD under all circumstances play smoothly with no problem and plays smoothly on my Sony streamer, but it doesn't on the RPi via network stream. Again- this must be some kind of codec issue with the RPi because it fails to play smoothly under all RPi XBMC versions via network. When I tried cutting a sample of the video to upload so people can checkout no program could cut it exactly as it was and something always slightly changes, audio or video, and the sample would play smoothly on the RPi while the original video still does not. While I see all files buffer and cache their videos, this video fails to produce more than a 2mb cache and it runs down very quickly and thus the video stops every few seconds. Heavier videos run with no problem.
This the the M4V video details:
Quote:Format file : MPEG-4
Codec ID : M4V
File size : 710 MiB
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Bit rate : 4 111 Kbps
Audio #1
Format : AAC
Bit rate mode : Variable
Bit rate : 154 Kbps
Maximum bit rate : 258 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Audio #2
Format : AC-3
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 6 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits
*works smoothly via USB.
If someone has a suggestion how I can cut this file with zero re encoding so I could share it, I'll be happy to hear. Or if anyone spots from the details above a known problematic codec it will also be beneficial to know at least that the issue is noted and might be fixed in the future with these kinds of video supported.
Just tested an apparently similar file over wireless NFS share (Windows 7):
Quote:Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : No
Format settings, ReFrames : 2 frames
Format settings, GOP : N=1
Codec ID : V_MPEG4/ISO/AVC
Duration : 42mn 15s
Bit rate : 4 059 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.184
Stream size : 1.20 GiB (90%)
Language : English
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
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Codec ID : A_AC3
Duration : 42mn 15s
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 116 MiB (8%)
Language : English
It started with buffering every 30 seconds, but after 1 min 30 secs it went smooth. I then disabled the AC3 capable receiver which should cause more buffering, but after initial buffering it played smooth.
Under video settings, what is your refresh rate? When investigating my first stuttering issues with my Class 4 card I've read that lowering this would increase performance, which it did in my case for the old card.