Timeshifting

[Daemas]

If I have a file with a particularly high bitrate and a large file size, whenever I try to skip around (fast forward, rewind), it stops for a second or two and buffers.

But most of my files don't do that, just a few of the really HQ ones.

What causes these movies to buffer, and what will fix it?

I have a Q6600 OCed to 3.0GHz, 4GB or DDR3, 30GB Vertex. Those are about the only three potential bottlenecks that I can think of. Which part is making me annoyed?

thanks in advance

EDIT: Are there certain file types that are less prone to doing this than others? The videos that buffer are just regular old .wmvs

 

[0roo0roo]

dunno, maybe the more advanced profile has more partial frames between reference frames and other processing. i doubt anything would fix it, there are just a lot of frames it has to crunch around the spot where you choose before it can start i bet.

 

[swerus]

Interesting question that I don't have the answer to either. You gear you listed should be able to handle it? What formats work the best for you?

 

[0roo0roo]

oh wait he said wmv.
wmv performance sucks. that is just how it is.

 

[Cogman]

Here is the issue.

With most modern codecs you will probably observe this. The problem is that finding the exact position of the frame is a complex process that essentially results in the computer having to decode up to the point that you shifted. It could be done with something akin to a binary search, but it is still relying on jumping around a lot in the hard drive.

Not only that, but things get even more mess with the fact that generally there will be something like a key frame, and then several frames that base part of their info off of previous frames/the key frame. This makes operations that much more difficult as the system has to search backwards until it finds the key frame that corresponds with the frame you chose.

In other words. Due to compression, operations like randomly opening some location on the file are complex.

 

[Daemas]

h.264 works much better in terms of buffering (like .25 seconds, which is more than acceptable), but for some reason, it stutters and slows down during regular playback (almost like an FPS problem, but there's no way a GTX460 OCed to 900MHz is having a problem with a 1080p video)

So the answer is to either wait until we develop a better codec or develop a faster processor that can brute force through these codec's shitty compression algorithms?

 

[swerus]

You try core avc?

 

[Cogman]

h.264 works much better in terms of buffering (like .25 seconds, which is more than acceptable), but for some reason, it stutters and slows down during regular playback (almost like an FPS problem, but there's no way a GTX460 OCed to 900MHz is having a problem with a 1080p video)

So the answer is to either wait until we develop a better codec or develop a faster processor that can brute force through these codec's shitty compression algorithms?

It has nothing to do with "Shitty compression algorithms". It has to do with the fact that compression by its nature makes it hard to locate specific frames. The fact that algorithms use lots of processing power doesn't indicate the goodness of the algorithm.

 

[0roo0roo]

You try core avc?

h.264 only.

It has nothing to do with "Shitty compression algorithms". It has to do with the fact that compression by its nature makes it hard to locate specific frames. The fact that algorithms use lots of processing power doesn't indicate the goodness of the algorithm.

Eh...sorta
The reality i've found is wmv just sucks. I can seek 1080p mkv h264 in a snap, wmv at 720p even will always take several fold longer. there is just something rather broken about wmv

 

[mfenn]

h.264 works much better in terms of buffering (like .25 seconds, which is more than acceptable), but for some reason, it stutters and slows down during regular playback (almost like an FPS problem, but there's no way a GTX460 OCed to 900MHz is having a problem with a 1080p video)

So the answer is to either wait until we develop a better codec or develop a faster processor that can brute force through these codec's shitty compression algorithms?

Are you actually using DXVA?

Also, you mention that you have 30GB Vertex, but I assume the media files are not on there. What kind of storage is the media located on? If that's really fragmented/slow/overworked you could see stutters from not being able to read data fast enough.

 

[Daemas]

no to core avc, yes to DXVA

Also, in regards to my HDD : Yes, I am running them off my 7200RPM 1.5TB Seagate BUT there was ZERO difference when I tried to view off my vertex.

 

[Mark R]

It comes down to the CODEC and the container format - there is a lot of variability in how seeking is handled between them.

Most modern CODECs - h.264 and VC-1 in particular, make considerable use of 'bidirectional' compression. This means that where you have a series of frames:
1...2...3...4...5

On older CODECs, frames 1 and 5 would be fully encoded - and 2 would be a list of changes from 1. 3 encoded as a list of changes from 2, and 4 as a list of changes from 3.

On modern CODECs, 2, 3, 4 are encoded as a list of changes from both 1 and 5 (as well as neigboring frames). This means that following seeking frames have to be decoded in a complex order (starting from anything up to 10 or 20 frames ahead - depending on the encoder configuration) - as a result, there may be a significant decoding delay if you seek to a frame that isn't a 'key frame' (one that is fully encoded without reference to any others). This type of encoding is extremely resource intensive - as a result DXVA will only work on files where encoders have made limited use of this type of compression.

The other problem is how a player finds a particular frame in a file. Frames are of variable length - so there isn't an easy way of calculating the point in the file that corresponds to a particular frame. This can come down to having to perform some type of search.

Some advanced containers (e.g. MKV) get around this by indexing frames (usually keyframes). This way, a player can simply look in the index, and be able to start playing directly from a keyframe with minimal overhead. Some encoders minimize the amount of indexing performed, or save the index in a sub-optimal manner - so you might not get the full benefits. Matroska have a tool called 'mkclean' which reorganises indexes and other data in an optimal manner, which can improve seeking speed in mkv files. (Note if you want to download it - make sure you get the old version 0.5.7 - the current version 0.6.0 is severely broken).

Some formats are less good than others. E.g. the WMV format is noticably worse for seeking than MKV - even with the same CODECs.

 

[0roo0roo]

no to core avc, yes to DXVA

Also, in regards to my HDD : Yes, I am running them off my 7200RPM 1.5TB Seagate BUT there was ZERO difference when I tried to view off my vertex.

i have coreavc and it doesn't matter if i use it or not, wmv is just way way slower than mkv decoded by either.