how to improve slow seek times

[pyrates]

I encoded a 1080i source into a raw h.264 video using x264 build 558 in 1080p, and it takes forever to seek. I also wanted to split it up so that it would fit on 2 dvd-r's, not dual-layered. I put it in an avi container and any seeking done on that, takes like 10 minutes. But when I split it up into 2 4440 MB chunks, trying to play the 2nd one never works. Here is the command line I used to encode the 2nd and 3rd passes:


x264.exe --pass 3 --bitrate 13298 --stats "N:\1080i\Amityville.Horror\movie\1080i.stats" --level 4 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --filter -3,-2 --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4 --merange 32 --threads 2 --thread-input --cqm "jvt" --progress --no-dct-decimate --no-psnr --output "N:\1080i\Amityville.Horror\movie\1080i.264" "N:\1080i\Amityville.Horror\movie\1080i.avs"


Anything I can do beside having to re-encode? Also for b-frame mode, should I use spatial or temporal? and what is the difference between the 2?

[Sharktooth]

Buy a faster CPU, buy CoreAVC, lower the bitrate, lower the reference frames to 3, drop AVI and use an appropriate container (mp4, mkv, mpg, ...), use 2 passes and leave the b-frame direct pred. mode to auto (it will automatically choose the best prediction method).

[foxyshadis]

Your best bet if you can't lower the bitrate (or buy coreavc) is probably to lower the keyint (default 250), and raising the max b-frames will sometimes help. (Because when seeking, b-frames can be skipped and only p-frames need to be decoded back to the last i-frame.) Then again it might be avi's fault; have you tried using mp4 or mkv instead? Generally they're more robust than avi.

b-direct should be auto.

Any reason why you use jvt matrix over the flat or sharktooth's?

And of course binary cutting the file won't work, it hardly works with ASP either. You should be using yamb or mkvmerge for something like that, or splitting your encode into two separate jobs, or at worst, use vdubmod to split at a keyframe so that it keeps certain necessary decoding data.

[pyrates]

Your best bet if you can't lower the bitrate (or buy coreavc) is probably to lower the keyint (default 250), and raising the max b-frames will sometimes help. (Because when seeking, b-frames can be skipped and only p-frames need to be decoded back to the last i-frame.) Then again it might be avi's fault; have you tried using mp4 or mkv instead? Generally they're more robust than avi.

b-direct should be auto.

Any reason why you use jvt matrix over the flat or sharktooth's?

And of course binary cutting the file won't work, it hardly works with ASP either. You should be using yamb or mkvmerge for something like that, or splitting your encode into two separate jobs, or at worst, use vdubmod to split at a keyframe so that it keeps certain necessary decoding data.

It was my first encode, so I chose jvt. I tried using mkvmerge to split it into 2 mkv files and it plays fine. I had to link them though for the mkv split. I tried also putting it into an mp4 container. But it seeks just as slow as the avi one does.

I've already got the coreavc video codec installed. And why only 2 passes? Wouldn't 3 be better?

[foxyshadis]

Do your quantizers average above 30? If not, 3-pass is essentially useless. (If they're in the low or mid teens even 2-pass is overkill.) Try the flat matrix (non-custom) instead of jvt, or sharktooth's if you need extra sharpness.

[pyrates]

Do your quantizers average above 30? If not, 3-pass is essentially useless. (If they're in the low or mid teens even 2-pass is overkill.) Try the flat matrix (non-custom) instead of jvt, or sharktooth's if you need extra sharpness.

In the command line window, the average for Quantization was 16-18.

[GodofaGap]

Besides the key-frame interval, I don't think anything discussed here influences seeking in such a big way (b-frame prediction mode??? number of passes??? :confused: )

[foxyshadis]

Using 10+ b-frames can dramatically improve seek times, in areas that are very conducive to b-frames (primarily pans, stills, and talking heads, as long as there isn't a ton of grain). It has no impact where many b-frames can't be used though.

Maybe you could lower the bitrate to aim for q 20 or 22 instead, which would also dramatically improve seek times. Decode time, the primary factor in seek time, increases almost linearly with bitrate when using cabac. (By using cavlc you can sacrifice some quality for faster decoding.)

[Manao]

Bitrate / resolution have a major influence on the decoding speed, hence on the seeking time. BFrames don't need to be decoded, so the more the faster the seeking.

Indeed, the rest has either a minor influence ( number of refs ) or none at all ( number of passes, direct mode )

Lowering the key frame interval is the obvious fix for lowering seeking time, but I wouldn't do it unless seeking really matter, because it'll hurt the quality ( the PSNR, marginally, the visual quality, quite a bit more ).

[Sharktooth]

My suggestion about lowering reference frames and using 2 passes was all about encoding time (encoding 1920x1080 stuff is just tremendously slow).

[anonymez]

wrt mp4 & seek time, haali's splitter is noticeably (but not that much) faster than gabest's :)

[pyrates]

If x264.exe was writing 64-bit timestamps instead of 32-bit ones, as it was encoding, would that also cause the slow seek times? I know that none of the mp4 and mkv containers support 64-bit timestamps yet and seem to freeze the video without going anywhere. That would seem to be the case for my encoding as I attempted it a second time using the hq-insane profile. And got the same result. Just one part of the file I was able to seek to quickly. About 21 minutes through. The other parts the video would just freeze and go nowhere.

[GodofaGap]

If x264.exe was writing 64-bit timestamps instead of 32-bit ones, as it was encoding, would that also cause the slow seek times?
No, that would cause a crash somewhere far in the past. I can only advise you, in case you use Sharktooth's builds, to try the builds from x264.nl instead because people have repeatedly reported problems with the former.

I know that none of the mp4 and mkv containers support 64-bit timestamps yet and seem to freeze the video without going anywhere.
This is false, I think Matroska has always supported 64 bit and most mp4 writers and parsers should support this for a while now.

[pyrates]

No, that would cause a crash somewhere far in the past. I can only advise you, in case you use Sharktooth's builds, to try the builds from x264.nl instead because people have repeatedly reported problems with the former.


This is false, I think Matroska has always supported 64 bit and most mp4 writers and parsers should support this for a while now.

Actually these encodes are from the build on x264.nl. Built 558.

[unmei]

Matroska uses variable lengths for timecodes (like for most integer data fields). The currently maximum supported length is a total of 8 byte.

A writer can and probably will encode the timecodes into the smallest length possible, therefore the timecodes at the begin of the file start out small, maybe only 1 or 2 byte long and grow larger as the value of the timecode grows.

This limit is "artificial" in that it is just stated in the specs that no longer codes are valid at the moment, but the length code prefixing system is infinite and so supporting even longer fields were simply a matter of upping or removing the limit. This would leave all current codes unaffected. The limit is there because handling integer data of only 64bit is considerably simpler than larger data in most programming languages, since they feature built-in types up to that size.

[Sharktooth]

No, that would cause a crash somewhere far in the past. I can only advise you, in case you use Sharktooth's builds, to try the builds from x264.nl instead because people have repeatedly reported problems with the former.
This is becoming annoying... 2 persons have reported problems out of the 20.000+ megui users (megui comes with my x264 builds!). I've never been able to replicate that problem (it just WORKS FOR ME), so until it's replicable the only thing that could be said is: it's a problem with those 2 computers/OSes/systems...

[GodofaGap]

Fact remains that for those two people using x264.nl build solved it. It was not a critisism towards you, it was just a suggestion for pyrates to try.

My apologies if I offended you, I was only trying to help someone.

[Sharktooth]

I cant guarantee my builds work on screwed systems.
It's up to the user to check if his system is working properly.
Other people fixed all the problems installing an alpha and unstable version of avisynth...
Other people had the same problems with both my builds and x264.nl builds...

[pyrates]

I cant guarantee my builds work on screwed systems.
It's up to the user to check if his system is working properly.
Other people fixed all the problems installing an alpha and unstable version of avisynth...
Other people had the same problems with both my builds and x264.nl builds...

Okay I can now make an official update to the problem I was facing with the slow seek times. It's a very simple fix. On the avisynth script that I use, just add this to the end of it:

assumefps(23976,1000)

This fixes the bug where it forces x264 to use 32-bit timestamps instead of 64-bit timestamps. When you use 64-bit timestamps the containers mkv, avi, and mp4 all seem to take a dive. And the video freezes thus making it almost impossible to seek the video. Now of course avisynth 2.5.6a has this problem, but it's been fixed so far in 2.5.7. The 2.6.0 alpha version hasn't had this fix put in yet, so best to add it to the avisynth script anyways.

Now of course this is when I'm doing 1080p encoding. I'm not sure if it applies to 720p and below encoding, but might as well put it considering how long it takes. But for sure it's good to know this now. So anyone doing 1080p encoding with x264, be sure to add that.

Topic where this is discussed is here:

http://forum.doom9.org/showthread.php?p=874849

Correction: instead use assumefps(24000,1001). It's more accurate.

[GodofaGap]

This fixes the bug where it forces x264 to use 32-bit timestamps instead of 64-bit timestamps. When you use 64-bit timestamps the containers mkv, avi, and mp4 all seem to take a dive.
I think you are really looking in the wrong direction. AVI does not even have timestamps, let alone 64 bit timestamps. MKV has timestamps of variable length (as unmei said), it can use anything up to 64 bit. There is no 32/64 bit switch.

[pyrates]

I think you are really looking in the wrong direction. AVI does not even have timestamps, let alone 64 bit timestamps. MKV has timestamps of variable length (as unmei said), it can use anything up to 64 bit. There is no 32/64 bit switch.

Well all I know is that when I added that at the end of the avisynth script, it was able to seek in the mp4 and in mkv.