Improving seek in x264 encodes

[Surlias]

So frustrating! I've been doing some checking on my past encodes, and only some of them are affected. Plenty of my old keyint 240 encodes time skip perfectly fine, but some consistently don't. So I definitely think it's an encoding issue, but given that only some are affected (and the same ones consistently fail the test, while the ones that test good consistently test good), I'm inclined to think that it might not have anything to do with any particular setting I'm using, and perhaps rather it is an issue with a background process disrupting the encode in a small and otherwise unnoticeable way. Is that possible? I can't explain this any other way.

[ndjamena]

Audio Codec, Encoding Settings, Muxing application. That's what you need to look at.

And if it is something do with the length, then you need to find the threshold and figure out how many I-frames would be in the index, how big the file size is and how many bits it would take to hold that number.

[poisondeathray]

So frustrating! I've been doing some checking on my past encodes, and only some of them are affected. Plenty of my old keyint 240 encodes time skip perfectly fine, but some consistently don't. So I definitely think it's an encoding issue, but given that only some are affected (and the same ones consistently fail the test, while the ones that test good consistently test good), I'm inclined to think that it might not have anything to do with any particular setting I'm using, and perhaps rather it is an issue with a background process disrupting the encode in a small and otherwise unnoticeable way. Is that possible? I can't explain this any other way.

No, a background process will only slow down the encode but consuming CPU cycles. The encode won't be otherwise affected, only slower to complete

--keyint only places an upper limit. It doesn't mean the actual GOP size is 240 all the time. That's just the maximum. So your observation doesn't necessarily indicate anything

For example, if a scenechange, or some drastic changes in the content, there will be a new "IDR" frame inserted, marking the beginning of a new GOP. So depending on the content, you might already have "short" GOP's despite a --keyint 240 encode


However, if your --keyint 24 encodes still exhibit symptoms, then it's time to look at other reasons

[hello_hello]

As ndjamena said, maybe you should look at the container. I assume they're all MP4 or MKV? You could try remuxing from one container to another, or for MKV maybe try some of these. If VLC can have a seeking problem then maybe XBMC can too.
https://trac.bunkus.org/wiki/FAQ%3APlaybackDoesNotWorkVLCCannotSeekMkvmerge590
Or some other possible fixes.
https://trac.bunkus.org/wiki/FAQ%3AImprovingPlaybackCompatibilityWithPlayers

Or if you have the Haali media Splitter installed, try remuxing an MKV with gdsmux.exe I'm pretty sure it'll also open MP4s and remux them as MKVs.

You could have a bit of a look at a problem video in respect to keyframes. If you have one that won't seek properly in a certain spot you could open it in MPC-HC and use Shift+left/right arrows to navigate forwards/backwards between keyframes. It might give you a rough idea as to how far apart they are.... on average.

[jagabo]

--keyint only places an upper limit. It doesn't mean the actual GOP size is 240 all the time. That's just the maximum. So your observation doesn't necessarily indicate anything

For example, if a scenechange, or some drastic changes in the content, there will be a new "IDR" frame inserted, marking the beginning of a new GOP. So depending on the content, you might already have "short" GOP's despite a --keyint 240 encode

If you want to experiment with GOP sizes use --no-scenecut. That will disable the auto insertion of key frames at scene changes. Every GOP will have --keyint frames. Except the last one.

[_Al_]

It is kind of waste of your time in any case, because you choose 2pass encoding.

Is this your way of saying that CRF is the only viable encoding method?

With 2pass encoding you must choose average bitrate and that gives you overall volume, so you choose a "bucket" and then encoder squeezes everything in it. For another movie you find another "bucket" that you guess might be ok to squeeze you video in, and encode again. There is nothing scientific about that.

Nothing to test, regarding quality. Only to check if that keyint 24 actually seeks better for you, if you think keyint is a reason for bad seeking, but it looks like it might not be ... In this case 2pass is perfectly legit test, only you could do it quicker with 1pass, CRF.

[Surlias]

Regarding containers, remuxing, etc:
I use MakeMKV to extract what I want to encode, since I usually want to encode the special features as well, not just the main feature. Then I use VidCoder (frontend for Handbrake) to re-encode the ripped MKVs, using MKV for the new container of course. I usually passthrough DTS streams (just the core) and re-encode TrueHD to AAC (usually at 960 or 1152 Kbps). Then I remux the resulting MKV with MKVMerge in order to label the streams and add named chapters.

I did some more testing and debunked the hypothesis that only encodes greater than 2 hours are affected. It appears to be completely random which encodes are affected and which aren't.

If you want to experiment with GOP sizes use --no-scenecut. That will disable the auto insertion of key frames at scene changes. Every GOP will have --keyint frames. Except the last one.

Is that setting only practical for testing purposes? Or could having uniform keyframe placement be conducive to more reliable time seeking, without degrading video quality?

[poisondeathray]

Regarding containers, remuxing, etc:
I use MakeMKV to extract what I want to encode, since I usually want to encode the special features as well, not just the main feature. Then I use VidCoder (frontend for Handbrake) to re-encode the ripped MKVs, using MKV for the new container of course. I usually passthrough DTS streams (just the core) and re-encode TrueHD to AAC (usually at 960 or 1152 Kbps). Then I remux the resulting MKV with MKVMerge in order to label the streams and add named chapters.

AAC at 960 ? Really? That might be why

What about VidCoder/Handbrake? Did you set it to CFR ? Because VFR can cause problems

I did some more testing and debunked the hypothesis that only encodes greater than 2 hours are affected. It appears to be completely random which encodes are affected and which aren't.

You were already told duration doesn't affect seeking.


I doubt it's a random occurrence . Look again at the settings and bitrate distribution

If you want to experiment with GOP sizes use --no-scenecut. That will disable the auto insertion of key frames at scene changes. Every GOP will have --keyint frames. Except the last one.

Is that setting only practical for testing purposes? Or could having uniform keyframe placement be conducive to more reliable time seeking, without degrading video quality?

Yes, it's generally only for testing. You would not use it for a real encode, except in specific scenarios (streaming CBR for some specfic devices or networks)

A shorter GOP interval is always more conducive to seeking, but fixed uniform intervals are not necessarily better for seeking. For example, a fixed long interval will still seek poorly, but a short interval will always seek better regardless if it's adaptive or uniform. Both are inversely related to compression efficiency (thus lower quality under most scenarios, the exeption is when you are using very high bitrates/low quantizers). Fixed intervals means lower flexibility for the encoder to choose better placement of frametypes, and shorter intervals mean fewer "low cost" B and P frames, lower temporal compression

Longer GOP's are slower for seeking because P and B frames contain information that rely from other frames. That's what temporal compression is - you only store the differences between frames. And those frames within that GOP have to be decoded which takes extra time and resources, thus the longer the GOP, the worse the seeking characteristics. Only IDR frames are "complete" by themselves and do not rely on other frames. They have a higher bitrate / lower quantizer, thus "cost" more. Thus IDR frame only encodes (or intra encoding) will be very snappy and quick seeking , because that GOP size=1 , only 1 frame has to be decoded - but very poor for temporal compression efficiency. So really these are just trade offs

Scenecut is there to introduce IDR frames. They break up the potentially long GOP's. If you disable it and have long --keyint that is potentially very bad for quality. You will get a deterioriation in the GOP when something complex big happens like explosion etc...all the other subsequent frames will artifact and pixellate

[Surlias]

Yes I have CFR set.

I encoded Kill Bill's PCM audio track to 1152 Kbps AAC (the uncompressed stream is something like 5 GB, so I figured I'd give it a reasonably high bitrate. I mean, even DTS core is 1.5 Mbps, right?), and that is one of the encodes that doesn't have seeking issues.

I know I was told about duration not being a factor, I just thought I'd share that I proved it to myself.

[poisondeathray]

You've already ruled it out for seeking issues - but it's not common for AAC to go that high. It's meant as a high compression format. At higher bitrate ranges it gets outperformed . You might as well use DTS or AC3 . Especially since handbrake's older AAC encoder is downright terrible (FAAC or ffmpeg). It cuts off high frequencies unless you set the cutoff explicitly which I don't think is exposed in the GUI version (and even then it still produces poor quality). I think newer versions have the option to use FDKAAC ? At least that one is much better

[Surlias]

Yeah I'm using FDK AAC. DTS encoding is not available or I'd probably consider using that. I'm using AAC because I was hoping to preserve a bit more quality than 640 Kbps AC-3 when converting from TrueHD and PCM, and I found a few different sources extolling the virtues of AAC as capable of higher quality compared to AC-3. VidCoder allows bitrates up to 1344 Kbps for FDK AAC.

[poisondeathray]

I found a few different sources extolling the virtues of AAC as capable of higher quality compared to AC-3. VidCoder allows bitrates up to 1344 Kbps for FDK AAC.

It might be true - I haven't seen or done any comparisons at those bitrates (!)

There are free dts encoders now, maybe not through handbrake/vidcoder - dcaenc / ffdcaenc

[hello_hello]

Yeah I'm using FDK AAC. DTS encoding is not available or I'd probably consider using that. I'm using AAC because I was hoping to preserve a bit more quality than 640 Kbps AC-3 when converting from TrueHD and PCM, and I found a few different sources extolling the virtues of AAC as capable of higher quality compared to AC-3. VidCoder allows bitrates up to 1344 Kbps for FDK AAC.

I've used the default VBR quality for the NeroAAC enoder for years (q5.0). For stereo the bitrate should in theory average out to around 175kbps. The 5.1ch movie audio I encoded earlier today (originally DTS) resulted in a 455kbps AAC file, which would be reasonably average. You'd hope AAC would do as well as AC3 in respect to quality, only at a lower bitrate, otherwise you'd just use AC3. 1344kbps seems pretty over the top to me. How many channels?

I don't know whether Vidcoder allows you to choose VBR audio these days (it's all I've ever used for AAC) but FDK's VBR presets are a little odd when it comes to bitrate. The other AAC encoders (Nero, FhG, QAAC) have VBR presets which make sense, and their respective presets produce similar bitrates. FDK's highest quality setting (m5) produces something like 240kbps for stereo audio, if memory serves me correctly, while for the second highest quality setting (m4) it drops to 128kbps. Nothing in between. I gave the low pass filter a tweak which seemed to help. I think the low pass frequency is 20kHz or higher for the m5 preset, and around 15kHz for m4. As I mostly encode with the LAME V2 preset I made note of the lowpass frequency it uses (18.5kHz) and added it to the FDK commanline (-w 18500). The average bitrate for the m4 preset increased to around 160kbps for stereo and for the m5 preset it decreased to around 210kbps.

A quick Google for FDK and low pass filter led me to Wikipedia which in turn links to HydrogenAudio.
http://en.wikipedia.org/wiki/Fraunhofer_FDK_AAC
The FDK AAC encoder employs a more aggressive default low-pass filter than is used in other codecs. Higher frequencies are removed so that more bits are available to better describe sounds of lower frequencies, improving the overall quality for most combinations of recordings and listeners. In some, not completely rare, combinations the missing high frequencies are noticeable. The library does allow overriding the low-pass filter setting, and in the highest VBR mode effectively applies no filter at all.
I've no idea what Vidcoder does in respect to adjusting the low pass filter, but I'd guess it doesn't change it.

Lately I've been using QAAC a bit. Mainly because it has an option to remove the encoder delay (padding). Not that it matters to me much, as MKVMergeGUI removes AAC encoder padding and fiddles with the audio delay to compensate if need be (assuming the padding info can be found in the M4A/MP4 file) but not needing a delay at all is probably more ideal.
Out of curiosity I converted a random MP3 to AAC with FDK and had a look. If MediaInfo isn't lying to me the FDK AAC-LC stereo audio encoder padding is 46ms.

FhGAacEnc stands out from the other AAC encoders because it's faster. Around twice the speed of the others.

[_Al_]

Is there any reason to put AAC into MKV instead of AC3?

[Surlias]

I don't know whether my reasoning is valid, but I use AAC at a bitrate higher than AC-3 is capable of to re-encode lossless PCM and TrueHD audio tracks. Hopefully, this is affording my encodes higher quality audio than what can be reproduced by 640 Kbps AC-3.

[El Heggunte]

I don't know whether my reasoning is valid, but I use AAC at a bitrate higher than AC-3 is capable of to re-encode lossless PCM and TrueHD audio tracks. Hopefully, this is affording my encodes higher quality audio than what can be reproduced by 640 Kbps AC-3.

You are wrong. You are just wasting bitrate and storage space.
AAC was designed to give the same quality as MP3 at even lower bitrates, and without the MP3 'caveats'.
Unless you have excellent ears and an excellent audio equipment, you'll really perceive no difference between a stereo AC3 stream at 256kbps and a stereo AAC stream at 144kbps. Or between stereo AAC at 256kbps and stereo AAC at 512kbps.
If you really want to "waste" filesize and storage space, at least use a codec that was designed to be bitrate-hungry,
namely DTS.

[Surlias]

You keep mentioning "stereo" in your examples, so just in case there's been a misunderstanding, I'd like to clarify that I'm not encoding to stereo AAC. I'm encoding to 5.1 AAC @ 48 Khz.

[El Heggunte]

Makes no difference. Stereo at 256kbps == 640kbps at 5.1

(remember that the .1 channel requires a very-low bitrate for itself).


5.1 AAC is generally considered perceptually-transparent at 320kbps.

[hello_hello]

I don't know whether my reasoning is valid, but I use AAC at a bitrate higher than AC-3 is capable of to re-encode lossless PCM and TrueHD audio tracks. Hopefully, this is affording my encodes higher quality audio than what can be reproduced by 640 Kbps AC-3.

If by "quality" you mean "audible difference", then increasing the bitrate probably won't achieve anything. The HydrogenAudio LAME wiki says the same thing about LAME's VBR presets. Once the encoder is "transparent", increasing the bitrate can't make it more transparent.
The LAME VBR presets from V3 to V0 are all considered to be normally transparent and produce average bitrates from 175kbps to 245kbps for stereo. The same logic applies to AAC.
http://wiki.hydrogenaud.io/index.php?title=LAME#Recommended_encoder_settings
-b 320 is an alternative to the VBR settings above.
This CBR mode will maximize the MP3's bitrate and overall file size. The extra space may allow for some parts of the audio to be compressed with fewer sacrifices, but to date, no one has produced ABX test results demonstrating that perceived quality is ever better than the highest VBR profiles described above.

Higher bitrates will no doubt throw less information away, but the audio won't sound any better.
DTS uses much higher bitrates than AC3 but that doesn't necessarily mean it sounds better, just that it doesn't compress as efficiently. The general consensus seems to be (judging from various Bluray reviews I've read) that DTS does sound a fraction better than AC3, but I'm sceptical. The higher bitrate probably contributes to a placebo effect. I've only read one comparison test between DTS and AC3 that appeared to be believable (due to the way they were compared) and while it was years ago the conclusion was 480kbps 5.1ch AC3 is high quality but not transparent, I don't think 755kbps DTS rated particularly high when it comes to quality, however 640kbps AC3 and 1510kbps DTS were both rated pretty much the same. Very high quality.

The main reason most comparison tests of modern encoders are carried out using low bitrates (96kbps for stereo audio seems to be pretty common these days) is because at bitrates much higher than that it becomes too hard to compare them.

Is there any reason to put AAC into MKV instead of AC3?

For me? No there's not. I don't re-encode AC3 because the quality setting I use it doesn't reduce the bitrate all that much, so I just keep the original. DTS is a different story though, so I do re-encode it.

[Surlias]

My highly unscientific observations have led me to favor DTS over AC3. It has nothing to do with blind tests or even simply comparing the same track encoded differently. Rather, just through the course of watching movies and TV, I have consistently found myself underwhelmed by soundtracks encoded to AC3, whereas I've been impressed or at least generally satisfied with DTS. How much of this is the result of the placebo effect is anyone's guess. But that's my premise, and why I've been trying to achieve "higher quality" than what AC3 can offer.

[Surlias]

There are free dts encoders now, maybe not through handbrake/vidcoder - dcaenc / ffdcaenc

I'm having difficulty locating a Win32 build of ffdcaenc (which as far as I can tell is an updated/better version of dcaenc). Any suggestions?

[poisondeathray]

There are free dts encoders now, maybe not through handbrake/vidcoder - dcaenc / ffdcaenc

I'm having difficulty locating a Win32 build of ffdcaenc (which as far as I can tell is an updated/better version of dcaenc). Any suggestions?

Binary here thx to El Heggunte
https://forum.videohelp.com/threads/348702-ffdcaenc-%28an-upgrade-to-dcaenc%29?p=233761...=1#post2337613


I don't have any scientific evidence, but I prefer DTS as well if you have enough bitrate

I haven't tested dcaenc or ffdcaenc compared to retail DTS encoders, so I don't know how it stands

Another possible reasons for using AC3 and DTS is they are usually more compatible with home theatre equipment than AAC , of course not an issue if you have a software player

[Surlias]

Has anyone done a comparison of SurCode and ffdcaenc? Is either one any better than the other?

[hello_hello]

My highly unscientific observations have led me to favor DTS over AC3. It has nothing to do with blind tests or even simply comparing the same track encoded differently. Rather, just through the course of watching movies and TV, I have consistently found myself underwhelmed by soundtracks encoded to AC3, whereas I've been impressed or at least generally satisfied with DTS. How much of this is the result of the placebo effect is anyone's guess. But that's my premise, and why I've been trying to achieve "higher quality" than what AC3 can offer.

I'm not saying you're wrong, but there's so many variables it's impossible to say it's because of the encoder. I think it's been pretty well established that the AC3 and DTS (and even PCM) versions sometimes (and sometimes on the same disc) aren't necessarily encodings of the same original mix. I doubt it's always true but I'm sure it's true some of the time. And AC3 can include dynamic range compression which may or may not be enabled in a player etc. I very, very much doubt DTS has more bass or more dynamic range etc than AC3. It's quite possible one produces artefacts in areas where another doesn't, or one version sounds a little different compared to the original in certain places than another, but without the original to compare them to it'd probably be impossible to say which is "better"..... I guess I'm just sceptical as to whether being "underwhelmed" can be blamed squarely on the encoder.

While writing this I remembered something a bit related, involving AAC and itunes. There was a little controversy over the "mastered for itunes" concept, when a record producer announced he'd remastered an album for itunes to ensure the AAC version sounded as close to the CD version as possible. Maybe he really believed it, or maybe it was a marketing idea, but another sound engineer called "bullshit" and performed a null test on the itunes version and his own AAC encoding of the CD.
To clarify, the same sound engineer realised later Apple's "mastered for itunes" and this particular "mastered for itunes" were two different concepts. Apple wasn't suggesting music should be mastered differently for conversion to AAC, but lots of people were apparently getting in on the act and I don't care who they are, I'm really sceptical.

Anyway, the reason I mention all that is because it'd never really occurred to me before then to try a null test to see what sort of differences there might be between encoders at similar bitrates. Ideally, the null test should result in silence if the encoder reproduces the audio 100% accurately, and what's not silence is a "kind of" representation of how inaccurate it's being. I did start playing around with it a little and meant to experiment some more, but I never got around to it. At high bitrates though, AC3 didn't seem to be doing too badly (I was using the AFTEN AC3 encoder).
Anyway, I thought I'd mention all that in case you might want to experiment yourself. It's fairly easy to do and the video in the link above shows you how, but it's just a matter of importing the original audio, importing an encoded version, making sure the samples line up exactly (which they did for most codecs except AFTEN for some reason), phase reversing one of them and listening for what's not silence. I was converting to various formats with foobar2000, converting the encoded versions to wave files with foobar2000, then importing them into Audacity for the null test (the phase reversal "effect" is called Invert).

[Shaylen]

To negate the increase in file size, this is what I tried, rc-lookahead = keyint/4. Or just test rc-lookahead values when testing keyint but a decreased keyint causes 'still' parts of the video to move like it's distorted. You have to look closely to see it. This also happens in x265. It's noticeable in anime mostly. Hope this helped you. Oh and rc-lookahead must be greater than bframes. I've added a test to prove it to you.

[sneaker]

If you want to decrease file size you increase --crf or choose a slower preset, not play with some random options.

[hello_hello]

To negate the increase in file size, this is what I tried, rc-lookahead = keyint/4. Or just test rc-lookahead values when testing keyint but a decreased keyint causes 'still' parts of the video to move like it's distorted. You have to look closely to see it. This also happens in x265. It's noticeable in anime mostly. Hope this helped you. Oh and rc-lookahead must be greater than bframes. I've added a test to prove it to you.

Maybe you should try --open-gop. It's disabled by default, although it's generally used when encoding with the various Bluray compatibility options, because 100% Bluray compliant video requires reduced keyframe intervals. Apparently it helps reduce the "keyframe pumping" effect. Maybe that's contributing to the "movement" you're seeing, if you're encoding with fairly low bitrates.

Do most devices support --open-gop these days? I don't know, as I don't use it.

I'm struggling to understand how reducing rc-lookahead would improve the quality. I'm not saying it doesn't, but I'm not sure I understand the logic behind reducing it.

[Shaylen]

I didn't say reducing rc-lookahead would improve quality, I said it's a way to reduce file size. If rc-lookahead's > keyint, compression is affected big time and I did a few tests around a month ago. Try it with any crf value but keep it constant throughout all tests to verify.

I know we are talking about x264 but whatever's inherited from x264 in x265 have the same meaning.

Go to https://x265.readthedocs.org/en/default/cli.html to get all details of x265 switches.

--open-gop, --keyint, --scenecut, rc-lookahead, all fall under Slice decision options.
Meaning if one of those are changed, you would want to balance it with the other, that's how I came to that conclusion earlier.

[hello_hello]

I didn't say reducing rc-lookahead would improve quality, I said it's a way to reduce file size. If rc-lookahead's > keyint, compression is affected big time and I did a few tests around a month ago. Try it with any crf value but keep it constant throughout all tests to verify.

I guess I misunderstood you there, although......
I'm still dubious. Isn't "RC" rate control? Therefore to me it seems logical reducing rc-lookahead reduces the encoder's ability to control the bitrate. Either that or it reduces the amount it can compress the video. Either way, that probably results in lower quality for a given bitrate. http://www.chaneru.com/Roku/HLS/X264_Settings.htm#rc-lookahead
In relation to mbtree: http://www.chaneru.com/Roku/HLS/X264_Settings.htm#no-mbtree

--open-gop, --keyint, --scenecut, rc-lookahead, all fall under Slice decision options.
Meaning if one of those are changed, you would want to balance it with the other, that's how I came to that conclusion earlier.

As per the links above, for x264 the rc-lookahead and no-mbtree options seem to be in a rate control category, while the frame type category includes open-gop and no-scenecut. I'm not sure you can necessarily balance out settings by category as such.

[Shaylen]

I actually tested this in x265 first then x264, the options are under one category in x265. So I was like, lets try it in x264 and it works well so.. I'm glad you looked into it.