Extremely big files while using AutoGK

[tbsvk]

Hello. I'm tried to use AutoGK to convert small VOBs (2-3 minutes) using DivX 6.7 codec. Output files are extremely high (100-150 MB). What I do wrong ?

Here's a log
====================================================
[12.03.2009 13:51:53] AutoGK 2.55
[12.03.2009 13:51:53] OS: Win2000 (5.0.2195).2
[12.03.2009 13:51:53] Job started.
[12.03.2009 13:51:53] Input file: E:\VIDEO_TS\VTS_19_0.IFO
[12.03.2009 13:51:53] Output file: C:\DVD3\19.avi
[12.03.2009 13:51:53] Output codec: DivX
[12.03.2009 13:51:53] Audio 1: English AC3 2ch
[12.03.2009 13:51:53] Subtitles: none
[12.03.2009 13:51:53] Format: AVI
[12.03.2009 13:51:53] Target size: 1400Mb
[12.03.2009 13:51:53] Audio 1 settings: CBR MP3 with bitrate: 128Kbps
[12.03.2009 13:51:53] Started encoding.
[12.03.2009 13:51:53] Demuxing and indexing.
[12.03.2009 13:52:21] Processing file: E:\VIDEO_TS\VTS_19_1.VOB
[12.03.2009 13:52:21] Source resolution: 720x576
[12.03.2009 13:52:21] Found PAL source.
[12.03.2009 13:52:21] Source aspect ratio: 4:3
[12.03.2009 13:52:21] Analyzing source.
[12.03.2009 13:53:42] Source is considered to be interlaced.
[12.03.2009 13:53:42] Output will contain 4117 frames
[12.03.2009 13:53:42] Decoding audio.
[12.03.2009 13:53:45] Normalizing audio.
[12.03.2009 13:53:46] Encoding audio.
[12.03.2009 13:54:09] Audio1 size: 2,635,392 bytes (2.51 Mb)
[12.03.2009 13:54:10] Overhead: 152,704 bytes (0.15 Mb)
[12.03.2009 13:54:10] Video size: 1,465,218,304 bytes (1397.34 Mb)
[12.03.2009 13:54:10] Target bitrate is: 71179kbps
[12.03.2009 13:54:10] Running compressibility test.
[12.03.2009 13:57:09] Duration was: 2 minutes 58 seconds
[12.03.2009 13:57:09] Speed was: 11,29 fps.
[12.03.2009 13:57:09] Compressibility percentage is: 1255,68
[12.03.2009 13:57:09] Switching b-frames off
[12.03.2009 13:57:09] Chosen resolution is: 720x544 ( AR: 1,32 )
[12.03.2009 13:57:09] Predicted comptest value is: 991,47%
[12.03.2009 13:57:09] Running first pass.
[12.03.2009 14:02:51] Duration was: 5 minutes 41 seconds
[12.03.2009 14:02:51] Speed was: 12,04 fps.
[12.03.2009 14:02:51] Running second pass.
[12.03.2009 14:08:32] Duration was: 5 minutes 40 seconds
[12.03.2009 14:08:32] Speed was: 12,11 fps.
[12.03.2009 14:08:33] No splitting required
[12.03.2009 14:08:33] Job finished. Total time: 16 minutes 39 seconds
====================================================

[Inspector.Gadget]

I haven't used AutoGK lately, but I suspect this is it:

[12.03.2009 13:51:53] Target size: 1400Mb

How are you picking a target size or bitrate? Seems like some setting elsewhere might be overriding your intended size.

[BigDid]

Hi and welcome to the forum

Culprit is the final size you did define:
[12.03.2009 13:51:53] Target size: 1400Mb

Results being:
[12.03.2009 13:54:10] Target bitrate is: 71179kbps
...
[12.03.2009 13:57:09] Compressibility percentage is: 1255,68
...


If you don't know what size to affect, for small vobs like these, begin by doing a 1 pass encode (default 75%) that will give you a good estimation of size with very good quality. Once done, you can do you maths again for a 2pass encode ...

Did

Edit: Gadget was quicker on this one :cool:
And, technically, the final file is undersized if it is 150Mb, it should be 1400 MB (joke) :D

[tbsvk]

I read in Tutorial, that "if you use a Percentage output, you'll lose control over file size".
I tried, btw, set the file size to 10MB, but quality of this file was really weak.

[unskinnyboy]

I read in Tutorial, that "if you use a Percentage output, you'll lose control over file size".
I tried, btw, set the file size to 10MB, but quality of this file was really weak.What is your acceptable file size here? If you cannot compromise on file size being above 10 MB, lower the resolution from your current 720x544.

Like BigDid said, do a 75% 1-pass encode with a resolution that is acceptable to you, and then take it from there.

[BigDid]

I read in Tutorial, that "if you use a Percentage output, you'll lose control over file size".
Hi,

True but out of the context which is:
... A Quality encode will give you even quality throughout the movie at your designated percentage. The default is 75%, which will give you very good quality (but for DivX6 default is 60%). Good quality percentages begin at about 67% (Quantizer 3). I don't think there's much point in going above about 80% because then you'll lose some of the benefits of MPEG4's compression abilities. That's up to you, though. But remember, if you use a Percentage output, you'll lose control over file size

Please tell me which part of my post you do not understand to answer like this; is it this part:
...begin by doing a 1 pass encode (default 75%) that will give you a good estimation of size with very good quality or this one: Once done, you can do you maths again for a 2pass encode
--------------------------

I tried, btw, set the file size to 10MB, but quality of this file was really weak.
Nevermind, we now have 2 estimation of size :
1/ the first encode being a 2pass, 100% quality(=compressibility percentage) and 720 width for +/- 150Mb
2/ your 2nd encode being 10Mb, no indication for quality or width but very weak

My bet is aim for a 2pass, 75Mb (150Mb/2), autowidth; if size is too big lower to 50 or 25Mb always autowidth, try again and visually compare what compromise size/quality you accept between these 3 files.

You do not give enough indication to why 150Mb is too much, why 10Mb is too "weak" so it's up to you to make the final decision and if the result doesn't please you , you can always begin all over again; just some electricity and time...

Did

[budwzr]

I myself am a big fan of the "quality" (quantizer) approach because it gives AGK the authority to really optimize the output.

This optimization is compromised when a constraining quantity like output file size or bitrate is introduced.

In my opinion it seems like the author of AGK put a default quality setting of 75% there as a way of saying "let AGK wow you", and it certainly does.

Although the quality setting does give up file size control, it does eliminate quality issues like artifacts during panning. When file size is a concern, I always author at 75%, and re-encode to FLV with ON2's (creators of Ogg Theora) VP6 high-def format, and the result is astounding.

[unskinnyboy]

I always author at 75%, and re-encode to FLV with ON2's (creators of Ogg Theora) VP6 high-def format, and the result is astounding.And the reason you don't directly encode to VP6/FLV is?

[budwzr]

I have a legacy network media player and portable device that don't support flash.


And the reason you don't directly encode to VP6/FLV is?

[unskinnyboy]

I have a legacy network media player and portable device that don't support flash.
Then why are you encoding to FLV? My question specifically was, why the intermediate AVI? Why not directly from DVD -> FLV?

[budwzr]

I use FLV's for http streaming, and AVI's for local streaming.


Then why are you encoding to FLV? My question specifically was, why the intermediate AVI? Why not directly from DVD -> FLV?

[AMED]

I don't think your following what unskinnyboy is getting at

he is asking why are you encoding like this

DVD -> AVI -> FLV

When you should be encoding like this

DVD -> AVI
DVD -> FLV

[budwzr]

Because the quality of a 75% AGK file is high enough to produce an excellent FLV.

Because it cuts down on encoding time for the FLV.

Because the FLV encoder occasionally chokes on mpeg2 files.

Because the resulting FLV is smaller (but still sharp) than if encoded directly from mpeg2.

None of my rendered videos have any motion blurring or visible artifacts. I view my process as equivalent to a single "2 pass" FLV encode, only I get the two files I need in a similar amount of time.

My playback devices are:

Archos 7 Internet Media Tablet
Archos TV+
D-Link DSM-520 Media Player
Archos 10 NetBook
Archos 604 WiFi





I don't think your following what unskinnyboy is getting at

he is asking why are you encoding like this

DVD -> AVI -> FLV

When you should be encoding like this

DVD -> AVI
DVD -> FLV

[unskinnyboy]

Because the quality of a 75% AGK file is high enough to produce an excellent FLV.If you must make an AVI, then why not do it at 100%?

Because it cuts down on encoding time for the FLV.This makes little sense. Encoding time should depend on the length of the input video, the resolution chosen and the complexity/simplicity of the settings and the filters used, not based on whether an input is MPEG-2 or AVI.

Because the FLV encoder occasionally chokes on mpeg2 files.Why? How are you encoding this anyway? Perhaps you should change your encoder.

Because the resulting FLV is smaller (but still sharp) than if encoded directly from mpeg2.If this was a constant quality encode, then the reason your FLV is smaller is because it has less details (the frames are of lower quality) than if you had encoded from MPEG-2.

Lastly, we don't have to continue debating this, as I am probably giving unsolicited advice here. If it works for you, and you are happy with it, then so be it. But in theory and in practice, you are losing quality, whether you realize it or not. Just understand that.

[budwzr]

1) To save some disc space and playback bandwidth (the AVI stays in my library). My NAS might get an outside http connection while I'm watching a movie at home.
2) The AVI is already partially compressed (some of the work has already been done), mpg2 is not.
3) My encoder is from ON2. Maybe it's a hardware issue, not encoder's fault.
4) It's a 2-pass (vbr) encode.
5) I don't mind, here's some unsolicited advice from me:

At high enough bitrates the rules of conversion don't matter except in theoretical terms.

If you must make an AVI, then why not do it at 100%?

This makes little sense. Encoding time should depend on the length of the input video, the resolution chosen and the complexity/simplicity of the settings and the filters used, not based on whether an input is MPEG-2 or AVI.

Why? How are you encoding this anyway? Perhaps you should change your encoder.

If this was a constant quality encode, then the reason your FLV is smaller is because it has less details (the frames are of lower quality) than if you had encoded from MPEG-2.

Lastly, we don't have to continue debating this, as I am probably giving unsolicited advice here. If it works for you, and you are happy with it, then so be it. But in theory and in practice, you are losing quality, whether you realize it or not. Just understand that.