Prebuffering for Video playback

[arris69]

As an update:

Today I decided to try NFS instead of SMB. Installed Allegro NFS on the webroot and had success with avi files. Sometimes I have to start them twice as the TV still says unsupported format the first time. In my tests they all played stutter free. mkv files do also play ok for some time. But after a little while they start to stutter, audio drops and I have to jump back some seconds to make them play again. I was surprised that this can happen in bitrate unintensive scenes.

So the need for prebuffering remains, but is limited to mkv (and avis with high bitrate spikes).

So long!

you cat try to play around with the mount options rsize= wsize=
but i say,if you want watch hd-movies over the network do if with gigabit lan
none of the protocols was designed for movie playing (http, nfs, smb) so caching and buffering is up to the player. than 2MB can be 1 frame but also 6.

arris

[erdem_ua]

I advice you to watch bandwith of your router via SNMP tools. So you can debug the BW usage.
You can test it via LAN too. You can watch the fast scenes bitrates. If it faster than 1,6 MB Its all natural that your files shuttering. Because with our hack makes TV think the files on the USB device.

[erdem_ua]

Ok I understand the hack just creates a mount on the usb-device and tricks the TV to use it as a device.

Could one consider to use the usb-device or RAM as a buffer? Otherwise the player would have to be altered to do the buffering (something impossible?).

The mkvs I am talking of have average bitrates much lower than 16mbit. Around 5000kbits including audio. So one just needs to buffer a bit for the spikes.

Something different would be an ftp to fs hack. In my book it is quite the most solid way to transfer data with less overhead.
I sometimes use it to watch mkvs while still downloading.

Average bitrates are not important for shuttering. The Spikes we needed to handle well.
I think a ftp or fs hack will not solve your problem.Why? Because TV says the required byte size for each frame. Try to read 100k continuously and when the keyframe comes, it request to read 2MB. You can't handle this problem with larger cache or buffer. Cache and buffer works for if there is a need of "previous" frames. Since you needed the "next" frames. So pre-caching required to handle that. You can't pre-cache the stream easily too if media player not support it.

I have some profession on MKV files. You can watch a MKV while you downloading, but you have no seeking options and you cant FF or RW, because index of mkv usually at end of the MKV stream.( Except using my tool for that, meteorite. )

Last think at my mind might solve your problem is that: Service menu.
I remember a parameter that in the service menu adjust the cache/buffer size for media playback. If request came from media player itself, than it works as precache for FS.
You needed to try.
You also needed to take photo of each menu first when you enter the menu. It will save your TV if you are confused. You have risk to brick your TV with changing some other options like panel type...

[erdem_ua]

Well you could buffer files. /dtv is a tmpfs so it will take pages from RAM basically as needed. So depending on how much ram is in there, you could have a script sit there and append to a file in a tmpfs mounted point inside /dtv from the nfs/cifs mounted other volume and play the file in the /tmpfs that you mounted but you basically need intelligent buffering with this since I doubt you can buffer anything huge (depending on how much RAM is in there).

GP

There is only ~100 MB ram there and not sufficient to buffer multi gigabyte files. This require some exotic programming (like creating virtual file driven from kernel module and aware where is reading by exeDSP...) and could not possible with some little scripts.