Why does the size increase?

[pwnsweet]

Hello again everyone,

I have another small problem that is seemingly defying logic. I have a video with the following characteristics:

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 8 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 20mn 44s
Bit rate mode : Variable
Bit rate : 268 Kbps
Maximum bit rate : 1 311 Kbps
Width : 720 pixels
Height : 384 pixels
Display aspect ratio : 1.875
Frame rate mode : Constant
Frame rate : 23.976 fps
Resolution : 8 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.040
Stream size : 39.8 MiB (88%)
Writing library : x264 core 55 svn-663
Encoding settings : cabac=1 / ref=5 / deblock=1:1:1 / analyse=0x3:0x133 / me=umh / subme=6 / brdo=1 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=3 / nr=0 / decimate=0 / mbaff=0 / bframes=3 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=3 / wpredb=1 / bime=1 / keyint=250 / keyint_min=25 / scenecut=40(pre) / rc=2pass / bitrate=268 / ratetol=1.0 / rceq='blurCplx^(1-qComp)' / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30
Encoded date : UTC 2010-03-24 08:12:29
Tagged date : UTC 2010-03-24 08:12:34

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : Yes
Format settings, PS : Yes
Codec ID : 40
Duration : 20mn 44s
Bit rate mode : Variable
Bit rate : 32.3 Kbps
Maximum bit rate : 35.7 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Stream size : 4.79 MiB (11%)
Encoded date : UTC 2010-03-24 08:12:34
Tagged date : UTC 2010-03-24 08:12:34


When I re-encode this video in TMPGEnc Xpress with the settings below, the result is a larger video (from approx 40mb to 100mb). Does anyone know why this is, and if so, could you please take a minute to explain it briefly so I can learn why also? I find it odd that the resultant video is larger than the source given that the resolution of the resultant video is lower.


http://obeopg.blu.livefilestore.com/y1piS1Xkk2bpoLgtwyn8Y5vRGwPjrt-l72fZtdyNTslmrrDLDpLPGgaTt8vUU8eA99CVmZU1XvX-oey68hoS4g4-4mo8PPS7-LG/tmpg%20settings%201.jpg
http://obeopg.blu.livefilestore.com/y1puVnb84LK8BxNOcrWzvPpTSz74t8JjYWSKhLbo4h6EUZVS1NVUVHbUkVXeBgoza4XokOjmjDGXxO95xppFOLmNt72_Dvkf9Ok/tmpg%20settings%202.jpg

[Blue_MiSfit]

Well.. dude you're using constant quantization. That's a big giant fail :) It also has no size predictability. Also, your source is less than 300kbps, which is a very low bitrate for 720x480 pixels.

If you're not familiar with the concept, in brief Constant Quantization picks a given "quantization parameter" (or QP for short). The QP is what determines the amount of compression applied to a given frame or macroblock.

When using typical bitrate based rate control modes, one specifies a given target bitrate, and the encoder automatically varies the QPs on a per frame and (with adaptive quantization) per macroblock level. This is because some frames can be compressed more than others, while maintaining image quality.

By using constant QP mode, you're taking away the encoder's ability to vary the QP! Thus the bitrate will be unpredictable, and quality may not be consistent, since certain frames are more compressible than others.

Long story short, use 2 pass VBR if you're targeting a specific bitrate.

In fact, read my signature :) I'm not sure what H.264 encoder TMPGEnc uses, but it's not as good as x264, I guarantee it :devil:

~MiSfit

[Dark Shikari]

When using typical bitrate based rate control modes, one specifies a given target bitrate, and the encoder automatically varies the QPs on a per frame and (with adaptive quantization) per macroblock level. This is because some frames can be compressed more than others, while maintaining image quality.That's mostly just x264 ;)

[Emulgator]

I'm not sure what H.264 encoder TMPGEnc uses...
Mainconcept.
TE4XP 4.7.4.299 uses mch264vout.001 Version 7.5.0.35746

[Blue_MiSfit]

Wow I just realized your source uses x264 svn 663. That's...... ancient :)

[7ekno]

But also highlights how efficient x264 was over Mainconcepts, even back then :P

7ek

[pwnsweet]

Hey guys, thanks for responses. As you can probably tell, I'm not very well versed in the ways of video encoding yet. About two years ago I tried most of the free independent softwares available such as MeGUI, Handbrake, SUPER, StaxRip and MediaCoder (as well as many many more) but they were either too complicated to use, didn't have a GUI or simply didn't do what I wanted them to do. I had a very specific goal at the time (to be able to convert straight from DVD to MPEG-4 AVC using as few pieces of software as possible at the best possible video quality whilst maintaining the smallest possible file size) and when I found TMPGEnc I found a comprehensive video editing package and transcoder in one. Here was a piece of software that:

1. Had an easy to use GUI
2. Had CUDA support
3. Had the ability to edit and apply filters to video and preview the video after all edits were applied before encoding
4. Could transcode between almost all video formats
5. Had batch encode support
6. Could convert directly from DVD to MPEG-4 AVC, either from disc in tray or mounted .iso, with the option to hard encode subtitles from the DVD disc.
7. Had support for user specified output video resolution (no restrictions)
8. Had a low price tag
9. Was multi-threaded

Don't get me wrong, TMPGEnc is certainly not without it's flaws, however it was the only software at the time that checked all of the above boxes. I went through basically ALL the freeware, community created software as well as most of the commercial stuff that had a trial period. I was not able to to find anything that met my requirements like TMPGEnc did. Perhaps TMPGEnc's biggest flaw is no x264 support. As such, I'm now on the hunt for new software that can check this box whilst still fulfilling my rather stringent requirements listed above. If anyone knows of such a software, please point me in its direction!

[nurbs]

x264 doesn't use CUDA so you won't get both. By the way the CUDA H.264 encoders a generally considered low quality.

[pwnsweet]

Well.. dude you're using constant quantization. That's a big giant fail :)

Thanks for your comments in particular Blue_MiSfit. I read through your reply thoroughly and, in the spirit of learning, I went ahead and encoded the first episode of Neon Genesis Evangelion Platinum Edition (NTSC) directly from the DVD source using both methods (constant quantization with the above settings at 368x272 and then again with two-pass variable bitrate at 368x272) ensuring that the resultant file size is the same for both methods(~61mb). I can't explain why, but the constant quantization method results in better image quality. If you (or anyone else!) can explain why I'd be very happy! See below:


Constant Quantization on the LEFT, 2-pass variable bitrate on the RIGHT (http://public.blu.livefilestore.com/y1pplkbJv-plGD-okklZFcr6Mnbf8W3K0-cgOO6R5DHLdf-UCj-5Tk_c3ORaHfC3bLI2P_tYiaEpI26cAImf5635A/Eva%20test.png)

[pwnsweet]

x264 doesn't use CUDA so you won't get both. By the way the CUDA H.264 encoders a generally considered low quality.

Yes you are correct. Given that this is the case, I'd prefer software that supports x264 over CUDA H.264. Or better yet, software that utilizes x264 for encoding and CUDA for filtering/video editing (This is how TMPGEnc's implements CUDA support)

[JEEB]

In my opinion this GUI talk is always a two-headed spear.

Personally in video encoding your selections are so wide that making a GUI that'd try to fix all of your problems would just end up with something like meGUI (although that one as far as I've been told never had a clear line where it was being developed to). You have to limit your app somewhere or the GUI will become a mess that people will cry to (and depending on the overall wideness of your project you will have to think a lot on how to logically and usability-wise design the interface).

Transcoding for a simple device or a pre-defined preset is still somewhat bearable, where the user doesn't really have to have too much control (give them crf / limited crf with vbv and 2pass VBR options) as the "quality"/"bitrate" setting, and let them select --preset ("encoding speed") and --tune (dropping the unneeded-in-daily-encoding ones) and that's it. Then add maybe IVTC/deint and crop. Anything else filtering-wise goes in and you're in for a heck of a ride.

Say, denoisers, for an example. There's a bucketload of them and, although there are some overall good ones, giving the user a very long list and lots of options isn't exactly a good idea. Limits have to be posed and therefore the amount of things you can do will get limited, too. Deinterlacing is somewhat similar in a way, but at least you can pseudo-arrange things there from "fast" to "slow++" (you still will have at least a dozen of different ways of doing something).

On VPx video decoding and GPU filtering: Sure, someone just needs to implement it. You could even use the deint filter for deint, but IVTC I'd still leave to something like TIVTC (or get someone implement that on the GPU).

Otherwise just stick libav*/ffms2 in it, and some kind of preview and it'd be done.

Yes, you'd get an UI and might get something done more easily (such as, say, group-encoding some files to the PSP with a GUI), but when you have one app to "handle it all" -- you're going the way that many have failed (and most probably no-one will ever do properly just because it would mean rethinking at least parts of your interface every time something new comes up -- of course refactoring is always good, but without limits an app will become either nonexisting or way too bloated for standard usage).

TL;DR It's not bad to wish for a good GUI, but you should also know what you would be losing by trying to make something easy to use.

P.S.
I'm not against easily usable GUIs that use the correct tools to do their job and don't fail on, say, VFR and some other weirdness. Actually, I've been brewing an idea of doing something relatively easy for my friend for quite some time now, but I have no idea if it'll ever become something real with my perfectionism.

P.P.S.
Also, pwnsweet -- did you try the newest Handbrake? Please do tell me how you like it as it seems to be the recommended "easy GUI encoding app" at the moment at certain places. It certainly doesn't support VPx decoding of certain video formats, but it also shouldn't be exactly slow either.

[pwnsweet]

In my opinion this GUI talk is always a two-headed spear.

.
.
.

Also, pwnsweet -- did you try the newest Handbrake? Please do tell me how you like it as it seems to be the recommended "easy GUI encoding app" at the moment at certain places. It certainly doesn't support VPx decoding of certain video formats, but it also shouldn't be exactly slow either.

As an advanced user, it's easy to forget how important a GUI is for beginners. Command line, whilst perhaps a better solution in the long run, is completely inaccessible to the beginner to the point where a beginner won't even try the software. In my opinion, the disadvantages of a GUI are far outweighed by the disadvantages of CLI software.

Also, I have tried the newest Handbrake as recently as yesterday. I distinctly remember Handbrake crashing on me several times when I used it two years ago and it seems it hasn't improved much since then in this respect. In fact, it crashed within 5 minutes of using it. I'm sure it's more stable in a Mac environment, but in a Windows environment it's stability has been flaky for me since day one.

[stax76]

@JEEB

Better write about something you are experienced with, code and command shells...

[JEEB]

@JEEB

Better write about something you are experienced with, code and command shells...

Ok, this is going plain off-topic, but I never said "GUIs are bad", nor did my rant mean "Write yer own perl scripts and use command line yarr" :P

And not everything I use is command-line, I like dgindex's GUI f.ex. quite fine, thank you very much. Things that do what they're supposed to do and don't undermine the ease-of-use. mkvmergegui is another purely great example of a usable GUI (with still quite a lot of features on its belt). Also, even if I say it like this, it doesn't mean that these applications couldn't be done better. It's just that they happen to be something that's rather easy to teach people (and they do their job well).

And you must understand that my rant was purely theoretical, with little mentions towards currently available software. But most probably you already misunderstood me completely (or I worded myself badly). Which is a pity.