Smart Encoding and lower-quality output

[Kloppstock]

:stupid:Im having issues to perfom smart encoding file-splitting in various 'fan-applications', since the comersial splitters seems to use trued split instead

I use AVIdemux and various relatives to Virtualdub for AVI,
my problem gets the same on both, the output loose in video quality for some reason, alot worse b/px quality and bitrate, it works thou, but unacceptable :)

in VD i use direct stream copy on everything, and just slide-mark the places and save it out

In AVIdemux i just input, slide-mark and save as, and say yes to every prompts it suggest (its accually enough to just say yes to smart encoding for it to get worse quality output i have concluded)

what am i doing wrong thath makes 2 programs to lower the quality? i have talked to some people and it should not lower it, its harder to get a solution from them thou, so do you have any instead?
or do you perhaps have any other programs thath you know splitt smart without lowering Quality thath you can instruct?

/Thanks in advance

[GodofaGap]

If you use DSC in VirtualDub and the equivalent in AVIdemux the bitrate changes because the files were encoded with a 2 pass VBR mechanism, which means the bitrate can vary between different parts. This only becomes visible when splitting but this not a lowering of the quality. The quality cannot be lowered since the programs are simply passing on the encoded data from one file to another.

The behavior you are seeing is normal. Bitrate and bpp are not indicators of quality. Otherwise show a screenshot where quality was lowered while using DSC.

If you are talking about the smart rendering option in VirtualDub, the outcoming quality is completely dependent on your codec settings, not on the application itself.

[Kloppstock]

If you use DSC in VirtualDub and the equivalent in AVIdemux the bitrate changes because the files were encoded with a 2 pass VBR mechanism, which means the bitrate can vary between different parts. This only becomes visible when splitting but this not a lowering of the quality. The quality cannot be lowered since the programs are simply passing on the encoded data from one file to another..
The behavior you are seeing is normal. Bitrate and bpp are not indicators of quality. Otherwise show a screenshot where quality was lowered while using DSC.

I here use direct stream copy on video and audio on this input thath are in VBR audio yes, wich im not correcting
http://img177.imageshack.us/img177/7070/namnlslk4.th.jpg (http://img177.imageshack.us/my.php?image=namnlslk4.jpg)
No quality dropp here?
file withouth VBR-audio i then guess no value will change at all?
the result in videoinpector thath really represents the quality then must be fps and resolution i guess? wich seems to become the same luckily

If you are talking about the smart rendering option in VirtualDub, the outcoming quality is completely dependent on your codec settings, not on the application itself.
I have not even located any smart rendering option lol

I get pretty representive results as above in Avidemux
(Only If you use it)
In thath program by the way it somethimes (depending on where you choose to splitt) prompt if it shall apply something called Q-factor (set 4) before start splitting, shall i use deafult 4 there? (to avoid getting quality loss there instead lol)

By the way do you know any splitters thath can smart encode wmv?

[Kloppstock]

because the files were encoded with a 2 pass VBR mechanism.
Now i have a file thath were not encoded with a 2 pass VBR mechanism. Virtualddub and another revealing programs dont have any opinion at all on the input, however the output gets the same result as above, on thoose 2 values, is thath still normal? now i have 3 programs thath gives me the same result both with and without VBR :helpful:

[GodofaGap]

No quality dropp here?
Not if you used Direct Stream Copy. DSC does not touch the video at all, it just copies it from one file to another. The name says it all. It's not any different from copying a word-file from one disk to another. Do words suddenly change there?



the result in videoinpector thath really represents the quality then must be fps and resolution i guess? wich seems to become the same luckily
There is nothing really in the screenshot that really indicates video quality.

I have not even located any smart rendering option lol
It's in the video menu of the latest version.


By the way do you know any splitters thath can smart encode wmv?
No.

Now i have a file thath were not encoded with a 2 pass VBR mechanism. Virtualddub and another revealing programs dont have any opinion at all on the input, however the output gets the same result as above, on thoose 2 values, is thath still normal?
Yes that's still normal. Except for a few formats and uncompressed video, video is VBR by nature. ABR is just a special case of VBR where the bitrate only fluctuates within certain bounds and 1 pass quality based is basically the same as a 2 pass VBR mechanism (with the exception of knowing the resulting file size).

[Kloppstock]

I see



There is nothing really in the screenshot that really indicates video quality.

Now then:devil: sound the alarm by strangling a cock pheasant if you see any irregularity

http://img166.imageshack.us/img166/3088/namnlssfu4.th.jpg (http://img166.imageshack.us/my.php?image=namnlssfu4.jpg)

G-spot - Container

701 Mb

File Length Correct
DivX Style "packed bitstream" AVI
AVI v1.0
Interleave: 36 ms (1.1 v.frames), preload=432
Audio frames: Aligned on interleaves
Video: 679 MB (96.90%)
Audio: 17.1 MB (2.44%)
AVI Overhead: 4.57 MB (0.65%)

5.49 Mb

File Length Correct
DivX Style "packed bitstream" AVI
OpenDML (AVI v2.0)
Interleave: 1 vid frame (33 ms), preload=432
Audio frames: Split across interleaves
Video: 5.17 MB (92.51%)
Audio: 356 KB (6.21%)
AVI Overhead: 73.5 KB (1.28%)

I can allso serve you with a attachment below over a Virtualdub 1.7.8 (and all other Virtualdub relatives) crash report, cause it feels like half of the files i input crash as soon as i press the play window to mark the cutts, perhaps it could be installed codec related?

reason is 'Integer Divide-by-zero'...whatever thath means

[Irakli]

@Kloppstock

Well, there is nothing wrong in that "Test1.avi" on your screenshot has lower bitrate than "Test.avi".
Why? Because your original file ("Test.avi") is variable bitrate file, meaning that for some chunks bitrate goes above the average while for others it goes below the average. In this case you simply extracted chunk with lower than average bitrate.

[Kloppstock]

@Kloppstock

Well, there is nothing wrong in that "Test1.avi" on your screenshot has lower bitrate than "Test.avi".
Why? Because your original file ("Test.avi") is variable bitrate file, meaning that for some chunks bitrate goes above the average while for others it goes below the average. In this case you simply extracted chunk with lower than average bitrate.
Is variable bitrate classified as standard? since i get the same on every form of normal avi i test, i mean there must be some avi thath have not variable bitrate allso..and how you fasst can locate if thath is the case or not?
i thauth VBR audio whas the sign for thath? but i think GodofaGap have told me thath it isnt so above...

[Irakli]

Is variable bitrate classified as standard? since i get the same on every form of normal avi i test, i mean there must be some avi thath have not variable bitrate allso..and how you fasst can locate if thath is the case or not?
i thauth VBR audio whas the sign for thath? but i think GodofaGap have told me thath it isnt so above...

I meant variable bitrate video (audio is not VBR on your screenshots). And there are virtually no constant bitrate video files.

[GodofaGap]

The only non-uncompressed video I know of that is completely CBR is DV.

[delacroixp]

reason is 'Integer Divide-by-zero'...whatever thath means
VirtualDub crash report -- build 28346 (release)
--------------------------------------

Disassembly:
100367a0: 106a04 adc [edx+04h], ch
100367a3: e8c88effff call 1002f670
100367a8: 8b4c2428 mov ecx, [esp+28h]
100367ac: 51 push ecx
100367ad: 68dc830410 push 100483dc
100367b2: 6a04 push 04h
100367b4: e8b78effff call 1002f670
100367b9: 83c418 add esp, 18h
100367bc: 85ed test ebp, ebp
100367be: 7507 jnz 100367c7
100367c0: b849000000 mov eax, 00000049
100367c5: eb0c jmp 100367d3
100367c7: 8bc5 mov eax, ebp
100367c9: 48 dec eax
100367ca: f7d8 neg eax
100367cc: 1bc0 sbb eax, eax
100367ce: 24f2 and al, 0f2h
100367d0: 83c050 add eax, 50h
100367d3: 8b54241c mov edx, [esp+1ch]
100367d7: 52 push edx
100367d8: 57 push edi
100367d9: 50 push eax
100367da: 68d0830410 push 100483d0
100367df: 6a08 push 08h
100367e1: e88a8effff call 1002f670
100367e6: 83c414 add esp, 14h
100367e9: 83fd02 cmp ebp, 02h
100367ec: 746f jz 1003685d
100367ee: 8b83b8000000 mov eax, [ebx+b8]
100367f4: 8b8bbc000000 mov ecx, [ebx+bc]
100367fa: 33d2 xor edx, edx
100367fc: 03f8 add edi, eax
100367fe: 8983c0000000 mov [ebx+c0], eax
10036804: 8b44241c mov eax, [esp+1ch]
10036808: 13d1 adc edx, ecx
1003680a: 89bbb8000000 mov [ebx+b8], edi
10036810: 8bbbc8000000 mov edi, [ebx+c8]
10036816: 8993bc000000 mov [ebx+bc], edx
1003681c: 99 cdq
1003681d: 898bc4000000 mov [ebx+c4], ecx
10036823: 8983b0000000 mov [ebx+b0], eax
10036829: 8993b4000000 mov [ebx+b4], edx
1003682f: 8b0d3c410710 mov ecx, [1007413c]
10036835: 2bc7 sub eax, edi
10036837: 33d2 xor edx, edx
10036839: 03c1 add eax, ecx
1003683b: f7f1 div eax, ecx <-- FAULT
1003683d: 8b83b0000000 mov eax, [ebx+b0]
10036843: 8b8bb4000000 mov ecx, [ebx+b4]
10036849: 8983c8000000 mov [ebx+c8], eax
1003684f: 898bcc000000 mov [ebx+cc], ecx
10036855: 8993d0000000 mov [ebx+d0], edx
1003685b: eb31 jmp 1003688e
1003685d: 8b44241c mov eax, [esp+1ch]
10036861: 99 cdq
10036862: 8983b0000000 mov [ebx+b0], eax
10036868: 8b83c8000000 mov eax, [ebx+c8]
1003686e: 8993b4000000 mov [ebx+b4], edx
10036874: 8bbbb0000000 mov edi, [ebx+b0]
1003687a: 8b0d3c410710 mov ecx, [1007413c]
10036880: 2bc7 sub eax, edi
10036882: 03c1 add eax, ecx
10036884: 33d2 xor edx, edx
10036886: f7f1 div eax, ecx
10036888: 8993d4000000 mov [ebx+d4], edx
1003688e: 8b4e0c mov ecx, [esi+0ch]
10036891: 41 inc ecx
10036892: 8bc1 mov eax, ecx
10036894: 894e0c mov [esi+0ch], ecx
10036897: 83f820 cmp eax, 20h
1003689a: 7232 jc 100368ce
1003689c: 8b5604 mov edx, [esi+04h]
1003689f: 8b db 8bh

Built on KOS-MOS on Tue Feb 12 22:09:24 2008 using compiler version 1400

Windows 5.1 (Windows XP x86 build 2600) [Service Pack 2]

EAX = 9bda6dc6
EBX = 01901f20
ECX = 00000000
EDX = 00000000
EBP = 00000001
ESI = 025df6a0
EDI = 676f7250
ESP = 025df5c0
EIP = 1003683b
EFLAGS = 00010286
FPUCW = ffff027f
FPUTW = ffffffff

Crash reason: Integer Divide-by-Zero

It's mathematically inadmissable (meaningless) to divide by zero.

It looks like ecx was moved to register memory location [esp+28h] then [ebx+bc] added to eax and finally died.
A sad ending to a neat bit of assemly by VirtualDub... RIP !

It's all good.


:):devil::D
Pascal