Large playback buffer for smooth h.264 playback on lowend systems (bitrate spikes)

[Veazer]

First time caller, long time listener.... :)

Is there a directx framebuffer i can put in the chain to allow playback of videos with high bitrate spikes on low end cpus? (or a similar solution)

Specifically, I am playing back 720p h.264/AVC mkv videos using:

An Asus 1000H netbook with intel onboard video (GMA 950)
Intel Atom 1.6 GHz (usually oc'ed to 1.9 for video playabck)
CoreAVC codec 1.8.5 (ffdshow was not quite usable)
MPC Home Cinema using Overlay renderer
(I'd like to use Haali or EVR CP but the extra cpu overhead was too great)

The average CPU use is around 50% - 65% during playback.

I'd like to find either a player or dx filter that supports a massive buffer to allow the pc to plow through the high bitrate scenes long before they are played back. I know that Haali has one of some sort, but even maxxed out it doesn't seem to work for me. The machine has 2gb of memory so i wouldn't mind giving it 512 or even a gig to use for buffering, i don't need it during playback.

I've so far only encountered a few videos that needed it, the bitrate spiked to nearly 50,000 in a few scenes and playback went down to around 15fps or so (guessing). I've had 8GB mkvs that play all the way through without a problem, it's just these spikes that are holding me back.

Any ideas you can throw at me?

[tetsuo55]

Basically what you're asking for is a "buffer" like that for streaming video.

However in this case you want the rendered frames to be stored and displayed after a few seconds with in sync audio.

This way any spikes will have time to even out and with a long enough buffer you should have smooth playback.

I don't think this is posisble at the moment, but it is an interesting idea.
The decoded frames are HUGE though, so with a large buffer you will quickly hit the ram limits of your system

[Flux]

I'm not sure if decoded umcompressed frames are necessary. Maybe something like pre-calculated "number tables" or something which could cut large amount of real-time processing time?

When you launch a video, media player says "Processing, please wait..." for some time and then video begins or you can do it with some other program to make a video ready for the near future.

[Veazer]

I'm not sure what you mean by pre-calculated "number tables", can you explain that?

It wouldn't need to necessarily make the user wait, it would just max the CPU for a while when playback was started (and after seeking) until the buffer was full. The only time that it would be required to make the user wait would be if the playback was starting during or near a high bitrate segment.

I understand that the uncompressed frames would be huge, and therefore the buffer, but i'm not bothered by this. I tend to shut everything else down prior to watching movies, so there's at least 1.5 gb available when i need to watch movies.

Other than this, i see no way of obtaining smooth playback during those demanding scenes. Maybe i can convince Blight to add this to ZP. :rolleyes:

[Sagekilla]

Decoded frames aren't that "huge." If you have 512 MB of memory allocated for buffering, at 720p that's (512 * 1024 * 1024) / (1280 * 720 * 1.5) = 388 frames you can buffer. If you're playing back 24 fps content, that's over 16 seconds (!) worth of frames. Scale back to even just 128 MB, and you still have a good 4 seconds of buffered video.

[Veazer]

Decoded frames aren't that "huge." If you have 512 MB of memory allocated for buffering, at 720p that's (512 * 1024 * 1024) / (1280 * 720 * 1.5) = 388 frames you can buffer. If you're playing back 24 fps content, that's over 16 seconds (!) worth of frames. Scale back to even just 128 MB, and you still have a good 4 seconds of buffered video.

Sounds great, but any ideas what is capable of doing this?

[Morte66]

If you get the ffdshow raw video filter to sit in the chain after CoreAVC, so core does the h264 decode and ffdshow processes its output, then that has an output queue. It's configured on the "Queue and misc" tab. This enabled me to play some borderline encodes on my old Athlon X2 3800+.

[Blue_MiSfit]

Doesn't Haali renderer also support queuing output frames?

[Sagekilla]

Haali Media Splitter supports a buffer, but that's only for reading from the disk.

[Veazer]

If you get the ffdshow raw video filter to sit in the chain after CoreAVC, so core does the h264 decode and ffdshow processes its output, then that has an output queue. It's configured on the "Queue and misc" tab. This enabled me to play some borderline encodes on my old Athlon X2 3800+.
I played with this briefly before, but i was using ffdshow to handle decoding as well. I just gave it a shot using raw video and it didn't help unfortunately. It's possible that this only works when FFDShow is actually handling the decoding, just a guess.

The reason i didn't pursue this route much is the lack of information and settings for the queue. It's simply enabled or not, but there seems to be no information as to how many frames are queued or how much memory is used nor can it be configured.


Haali Media Splitter supports a buffer, but that's only for reading from the disk.

The renderer buffers output frames, at least as i understand it, but i believe it uses video ram (which would be system ram on this integrated chipset anyway). Unfortunately it doesn't seem to do anything for me, and my bios limits the shared memory to 128 mb.


http://forum.doom9.org/attachment.php?attachmentid=9319&stc=1&d=1232781069