Encoders: don't let this be you.

[Dark Shikari]

This is from a recent anime encode from a group which will not be named. A number of people were stunned with the incredibly bad quality despite being an x264 encode of reasonable bitrate. Of course, it had the obvious problems: wrong aspect ratio and it was in an AVI file. But a quick look at the x264 header revealed far worse:

x264 - core 57 - H.264/MPEG-4 AVC codec - Copyleft 2005 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0x1:0 me=dia subme=7 brdo=0 mixed_ref=0 me_range=4 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 chroma_qp_offset=0 threads=2 nr=0 decimate=1 mbaff=0 bframes=0 keyint=250 keyint_min=25 scenecut=0(pre) rc=abr bitrate=938 ratetol=8.7 rceq='tex^qComp' qcomp=0.50 qpmin=10 qpmax=31 qpstep=3 ip_ratio=1.25

Here's the challenge, encoders: how many things wrong can you spot with this commandline?

Spoiler for Answers:

Red == inexcusible, orange == tolerable

x264 - core 57 - H.264/MPEG-4 AVC codec - Copyleft 2005 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0x1:0 me=dia subme=7 brdo=0 mixed_ref=0 me_range=4 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 chroma_qp_offset=0 threads=2 nr=0 decimate=1 mbaff=0 bframes=0 keyint=250 keyint_min=25 scenecut=0(pre) rc=abr bitrate=938 ratetol=8.7 rceq='tex^qComp' qcomp=0.50 qpmin=10 qpmax=31 qpstep=3 ip_ratio=1.25

Explanations:
1. This encode is very recent, but the x264 being used is still quite old.
2. cabac=0 means --no-cabac. We're not encoding for iPods here, folks.
3. ref=1 means one reference frame, which, especially for anime, is unbelievably stupid.
4. No deblocking? Bahahahahaha! (The trick: 1:0:0 means enabled with default deblock settings, 0:0:0 means off)
5. Analyse=0x1:0 means all partitions are disabled.
6. me=dia is of course the worst motion estimation mode. But we have subme=7, so we're using slow settings with the worst motion estimation mode...
7. B-rdo should probably be on if you're using something as slow as subme 7. (Technically this isn't an error, since B-frames are off, but I'll count it as one anyways)
8. Mixed-refs should definitely be on (though technically since ref=1 it would do nothing, but ref=1 is an error in and of itself).
9. Merange 4??! This means the motion search is going to have some serious difficulties.
10. No trellis? You can justify not using trellis in certain cases, but I highly doubt these guys were thinking about that...
11. No 8x8dct? Again, we're not encoding for iPods.
12. Threads should be auto, which should get cores * 1.5 as number of threads. Threads=2 is impossible if you use auto.
13. No B-frames? Again, we're not encoding for iPods.
14. One-pass bitrate-mode encoding?
15. The bad (non-default) RCEQ suggests that the encoder was using ffmpeg and didn't realize what a massive hassle encoding x264 with ffmpeg is, nor had any idea how to use it.
16-18. Same as above for qpmax, qpstep, and ipratio.

Scoring:
0-4: Brush up on your x264 documentation and learn more about the encoder you're using!
5-9: Good, you know a bit of your stuff and can spot the obvious errors.
10-14: You're an expert here; you can spot most of what's wrong with what they did.
15+: Why aren't you in #x264dev on Freenode?

[Nagato]

Now, I need someone doing speed/quality test with --ref
How much using high B-frame, say 16 effect decoding?
Well, even with --bframes 16 I still get low bframes : pframes without raising --b-bias.

More question. Sometimes there's blocking in dark area. Even applying higher aq still doesn't help. Would use zone and allocate more bits to that area solve this problem? I tried this but the blocking still remains, or still more bits are needed?
Yes, I leave the deblocking strength at default.

[Dark Shikari]

Originally Posted by Nagato

Now, I need someone doing speed/quality test with --ref

For anime, huge numbers of refs can help a lot. Its quite surprising, actually.

Originally Posted by Nagato

How much using high B-frame, say 16 effect decoding?
Well, even with --bframes 16 I still get low bframes : pframes without raising --b-bias.

--b-bias isn't generally a good idea; its not advisable to try to second-guess x264's B-frame decision process. Too many B-frames isn't a good thing; --bframes 16 just lets x264 use as many is reasonable.

Decoding-speed wise, more B-frames probably actually speeds up decoding because it reduces the bitrate by increasing efficiency. Testing would probably be required to be absolutely sure, since it likely depends on bitrate. I would guess at really really low bitrates more B-frames might lower decoding speed a bit. More refs has minimal effect.

Originally Posted by Nagato

More question. Sometimes there's blocking in dark area. Even applying higher aq still doesn't help. Would use zone and allocate more bits to that area solve this problem? I tried this but the blocking still remains, or still more bits are needed?
Yes, I leave the deblocking strength at default.

One thing I've found is that increasing deblocking strength can help quite a bit on anime. AQ reduces quantizer in flat/dark areas--which results in them getting weaker deblocking in addition to getting more bits.

[D404]

Dark Shikari, I hope you are aware that it is encoded like this on purpose. (Read: DB are Trolls, in particular, timecop) (OSHI- I name dropped!).

Dude actually knows what he's doing.. just likes to be gay to all the db-fans/fags.

I fully condone this.

[Dark Shikari]

Originally Posted by D404

Dark Shikari, I hope you are aware that it is encoded like this on purpose. (Read: DB are Trolls, in particular, timecop) (OSHI- I name dropped!).

Dude actually knows what he's doing.. just likes to be gay to all the db-fans/fags.

I fully condone this.

Nope, it wasn't DB... I am 99% certain this encode was serious

[D404]

Oh, lol. Then this is rather sad then. :P

EDIT: After a quick search on tt, and a few other sites.. it's clear who it is. :F

[shinjipierre]

What's sad is that you seem to understand what's typed.

[checkers]

15+: Why aren't you in #x264dev on Freenode?

I got 14. Don't kick me out ;_;

Originally Posted by D404

Dark Shikari, I hope you are aware that it is encoded like this on purpose. (Read: DB are Trolls, in particular, timecop) (OSHI- I name dropped!).

Dude actually knows what he's doing.. just likes to be gay to all the db-fans/fags.

I fully condone this.

Timecop knows nothing. He's not a zen master pretending to be an idiot. He's just an idiot pretending to be a zen master pretending to be an idiot.

[Heibi]

Whew, none of those were in my settings. Though we're guilty of using h264 for our .avi files. Makes the picture better. Though Id like to be doing it the right way.

Maybe you should inform the group about this(if you haven't already). The problem I always see here is - I don't wanna mention names, the show, etc...
Nothing improves unless the people doing it wrong are told. They may not even be reading this forum. And if they don't accept your criticism with a nob and a thank-you, leave them be and sigh.

A note to encoders who are experts - please try to put together a file that pilots can use for encoding. This means, coming from one pilot-type, so easy a monkey/caveman/dummy can do it. I know I'd love something like that. I know threads exist discussing it, but they get long and obtrusive. Dark sounds like he knows his stuff and I'm sure could throw something together.

Heibi
Central Anime

[emptyeighty]

Originally Posted by Heibi

Whew, none of those were in my settings. Though we're guilty of using h264 for our .avi files. Makes the picture better.

Containers don't impact visual quality as long as they correctly support all aspects of a codec. Avi can't be used with certain h.264 features, therefore it only decreases video quality over working containers like mp4 or mkv.

[Heibi]

Originally Posted by emptyeighty

Containers don't impact visual quality as long as they correctly support all aspects of a codec. Avi can't be used with certain h.264 features, therefore it only decreases video quality over working containers like mp4 or mkv.

We currently use virtuadub with h264 in it. There is no "save as" for mp4 or mkv, unless I'm missing something. Can you recommend a different encoding program for h264?

[edogawaconan]

Originally Posted by Heibi

We currently use virtuadub with h264 in it. There is no "save as" for mp4 or mkv, unless I'm missing something. Can you recommend a different encoding program for h264?

you're missing the fact that bframe in avi is hackery

maybe you can try meGUI. www.x264.nl
it should be straightforward (assuming you're familiar with avisynth - which you should be O.o )
and use mkvmerge (or mp4box) to mux

[D404]

Originally Posted by checkers

Timecop knows nothing. He's not a zen master pretending to be an idiot. He's just an idiot pretending to be a zen master pretending to be an idiot.

Yes, you just continue to believe that.

[Kristen]

Originally Posted by Heibi

We currently use virtuadub with h264 in it. There is no "save as" for mp4 or mkv, unless I'm missing something. Can you recommend a different encoding program for h264?

Megui. It works very nicely, but it has a disadvantage that you have to make a .avs script for video input. You also should never make timing raws/work raws in there, at least for the timer to use, because some people's Aegis won't read the keyframes (pink lines on audio). Though Megui is MUCH better at getting your files to your target size (If you use Auto-encode instead of "Enqueue"). Heck, I always put in 230 MB as my target size (Well, 222 with DCIISS due to the fonts), and the results have come out between 229 and 231 MB. With VDubMod, I put in 137000 kb as my target XVid size, and the end results have varied from 167 MB to 172 MB.
Also, Megui requires less calculations if you use Autoencode. But if you use "Enqueue", I think it requires more...

[emptyeighty]

Originally Posted by Heibi

We currently use virtuadub with h264 in it. There is no "save as" for mp4 or mkv, unless I'm missing something. Can you recommend a different encoding program for h264?

Either the already suggested MeGUI, or the x264 CLI directly. It accepts .avs input (if you're familiar with that) and can output .mp4.

[dj_tjerk]

Originally Posted by ChrissieXD

You also should never make timing raws/work raws in there, at least for the timer to use, because some people's Aegis won't read the keyframes (pink lines on audio).

For gods sake.. please..

1. open avimuxgui
2. go to settings
3. go to Avi File Structure
4. disable "use Open-DML output"
5. quit
6. make 'aegisub-compatible' workraws

This has nothing to do with MeGUI; it's just the settings you use to mux avi's (and MeGUI use AviMuxGUI for that with default settings, so if you THINK for one second and read the replies for your post in that other thread, and change the default settings to output 'aegisub-compatible' avi's, there'd be no problem at all to keep one from using megui and instead use virtualdub. If you still by accident mux with OpenDML.. just remux with OpenDML disabled (again with AviMuxGUI), or do that stuff with virtualdub.

[Kristen]

Originally Posted by dj_tjerk

For gods sake.. please..

1. open avimuxgui
2. go to settings
3. go to Avi File Structure
4. disable "use Open-DML output"
5. quit
6. make 'aegisub-compatible' workraws

This has nothing to do with MeGUI; it's just the settings you use to mux avi's (and MeGUI use AviMuxGUI for that with default settings, so if you THINK for one second and read the replies for your post in that other thread, and change the default settings to output 'aegisub-compatible' avi's, there'd be no problem at all to keep one from using megui and instead use virtualdub. If you still by accident mux with OpenDML.. just remux with OpenDML disabled (again with AviMuxGUI), or do that stuff with virtualdub.

I know, I read it, and I'm trying that now. I just don't want to explain all of that to him, so I said to not use it for timeraws.

[Heibi]

For my purposes all I need to know is how to get the final encode done using the proper program to get an mp4 or mkv output.(Thus, we stop releasing shows encoded using h264 with a .avi). I can get the show timed and edited with no problem.

[emptyeighty]

Heibi: The proper program is, as mentioned, MeGUI or x264 CLI.

[Kristen]

Originally Posted by Heibi

For my purposes all I need to know is how to get the final encode done using the proper program to get an mp4 or mkv output.(Thus, we stop releasing shows encoded using h264 with a .avi). I can get the show timed and edited with no problem.

If you really really wanted, you could encode it to h.264 in a .avi container and then just re-name it to filename.mkv. After all, AVI, MKV, and MP4 are just containers.