PDA

View Full Version : New ffvfw release


-h
23rd August 2002, 06:00
In case anyone hasn't noticed, the wonderful Milan has released a new version of ffvfw - http://cutka.szm.sk/ffvfw/index.html .

This version is vastly improved over the old build, with a more recent build of libavcodec for the engine. I just ran a few quick tests, and I'm sure many people will find its MPEG-4 performance to be surprisingly good. PSNR tests were a tad odd though. Also welcome is variable coefficient thresholding.. well I'll let everyone see for themselves.

One problem I had, however, is that I had to change the FourCC codes to xvid/XVID for the file to play back - it appears ffvfw doesn't like decoding its own content.

-h

-h
23rd August 2002, 07:09
I just played around a bit more, and have come to the conclusion that since libavcodec doesn't have a prefilter or thresholding by default, its fdct() implementation must be *very* severe on fine details - quant=3 tests between ffvfw and xvid show ffvfw performing anywhere from 0.5 to 1.5 (!) dB worse in PSNR, and I'm now noticing the smoothing out of details. Of course you do get a lower file size out of it.

This may be a great plus to someone encoding anime or something similar - try enabling "single coefficient elimination" in the quantization controls and see how you like the output.

-h

easyfab
23rd August 2002, 10:58
i've wanted to test but i always have this message :
Video compression error: An unknown error occurred (may be corrupt data).(error code -100).
I tested all options but always the same message.
I have an amd processor, a ati aiw 8500dv, a msi kt3 motherboard.
I try to encode with virtual dub in fast mode and in full mode.
The previous ffvfw codec work. So is something wrong in my settings or what ?

easyfab
23rd August 2002, 11:01
I forgot to say that i'm under win xp.
the codec is only tested by milan under win 2000.
can that be the cause of the pbs

Drachir
23rd August 2002, 21:25
I want test ffvfw but it crashes :( . I use Win2k Sp3 with a K6-2+ 550 MHz. I atached the log from VirtuelDub.

VirtualDub crash report -- build 13870
--------------------------------------

Disassembly:
6bf03a40: 29cf sub edi, ecx
6bf03a42: 0f6f0c0e movq mm1, [esi+ecx]
6bf03a46: 0f6f1406 movq mm2, [esi+eax]
6bf03a4a: 01c6 add esi, eax
6bf03a4c: 0f0fc1bf pavgusb mm0, mm1
6bf03a50: 0f0fcabf pavgusb mm1, mm2
6bf03a54: 0f6f1c0f movq mm3, [edi+ecx]
6bf03a58: 0f6f2407 movq mm4, [edi+eax]
6bf03a5c: 0f0fc3bf pavgusb mm0, mm3
6bf03a60: 0f0fccbf pavgusb mm1, mm4
6bf03a64: 0f7f040f movq [edi+ecx], mm0
6bf03a68: 0f7f0c07 movq [edi+eax], mm1
6bf03a6c: 0f6f0c0e movq mm1, [esi+ecx]
6bf03a70: 0f6f0406 movq mm0, [esi+eax]
6bf03a74: 0f0fd1bf pavgusb mm2, mm1
6bf03a78: 0f0fc8bf pavgusb mm1, mm0
6bf03a7c: 01c7 add edi, eax
6bf03a7e: 01c6 add esi, eax
6bf03a80: 0f6f1c0f movq mm3, [edi+ecx]
6bf03a84: 0f6f2407 movq mm4, [edi+eax]
6bf03a88: 0f0fd3bf pavgusb mm2, mm3
6bf03a8c: 0f0fccbf pavgusb mm1, mm4
6bf03a90: 0f7f140f movq [edi+ecx], mm2
6bf03a94: 0f7f0c07 movq [edi+eax], mm1
6bf03a98: 01c7 add edi, eax
6bf03a9a: 83ea04 sub edx, 04
6bf03a9d: 75a3 jnz 6bf03a42
6bf03a9f: 8b3424 mov esi, [esp]
6bf03aa2: 8b7c2404 mov edi, [esp+04]
6bf03aa6: 83c408 add esp, 08
6bf03aa9: c3 ret
6bf03aaa: 8db600000000 lea esi, [esi+00]
6bf03ab0: 83ec08 sub esp, 08
6bf03ab3: 8b4c2414 mov ecx, [esp+14]
6bf03ab7: 893424 mov [esp], esi
6bf03aba: 8b542418 mov edx, [esp+18]
6bf03abe: 897c2404 mov [esp+04], edi
6bf03ac2: 8b742410 mov esi, [esp+10]
6bf03ac6: 8b7c240c mov edi, [esp+0c]
6bf03aca: 0f6f35a829f06b movq mm6, [6bf029a8]
6bf03ad1: 8d0409 lea eax, [ecx+ecx]
6bf03ad4: 0f6f06 movq mm0, [esi] <-- FAULT
6bf03ad7: 0f0f4601bf pavgusb mm0, [esi+01]
6bf03adc: 8d742600 lea esi, [esi+00]
6bf03ae0: 0f6f1406 movq mm2, [esi+eax]
6bf03ae4: 0f6f0c0e movq mm1, [esi+ecx]
6bf03ae8: 0fd8d6 psubusb mm2, mm6
6bf03aeb: 0f0f4c0e01bf pavgusb mm1, [esi+ecx+01]
6bf03af1: 0f0f540601bf pavgusb mm2, [esi+eax+01]
6bf03af7: 01c6 add esi, eax
6bf03af9: 0f0fc1bf pavgusb mm0, mm1
6bf03afd: 0f0fcabf pavgusb mm1, mm2
6bf03b01: 0f0f07bf pavgusb mm0, [edi]
6bf03b05: 0f0f0c0fbf pavgusb mm1, [edi+ecx]
6bf03b0a: 0f7f07 movq [edi], mm0
6bf03b0d: 0f7f0c0f movq [edi+ecx], mm1
6bf03b11: 0f6f0c0e movq mm1, [esi+ecx]
6bf03b15: 0f6f0406 movq mm0, [esi+eax]
6bf03b19: 0f0f4c0e01bf pavgusb mm1, [esi+ecx+01]
6bf03b1f: 0f0f440601bf pavgusb mm0, [esi+eax+01]
6bf03b25: 01c7 add edi, eax
6bf03b27: 01c6 add esi, eax
6bf03b29: 0f0fd1bf pavgusb mm2, mm1
6bf03b2d: 0f0fc8bf pavgusb mm1, mm0
6bf03b31: 0f0f17bf pavgusb mm2, [edi]
6bf03b35: 0f0f0c0fbf pavgusb mm1, [edi+ecx]
6bf03b3a: 0f7f17 movq [edi], mm2
6bf03b3d: 0f7f0c movq [esp], mm1

Windows 5.0 (Win2000 build 2195) [Service Pack 3]

EAX = 00000540
EBX = 0000000c
ECX = 000002a0
EDX = 00000010
EBP = 042dfe9d
DS:ESI = 0023:042dfe9d
ES:EDI = 0023:043cc490
SS:ESP = 0023:04e66c00
CS:EIP = 001b:6bf03ad4
FS = 003b
GS = 0000
EFLAGS = 00010206

MM0 = 7979797878777776
MM1 = 7979797878777776
MM2 = 0001000200010001
MM3 = 0000000100010001
MM4 = 7a79797979797776
MM5 = 7a79797979797776
MM6 = 0101010101010101
MM7 = 0000000000000000
Crash reason: Access Violation

Thread 000005fc (Main thread)
T:\projects\VirtualDub_old\main\VideoSource.cpp(1624)
T:\projects\VirtualDub_old\main\VideoSource.cpp(1612)
T:\projects\VirtualDub_old\main\VideoSource.cpp(1624)
T:\projects\VirtualDub_old\main\VideoSource.cpp(1612)
T:\projects\VirtualDub_old\main\VideoSource.cpp(1624)
T:\projects\VirtualDub_old\main\VideoSource.cpp(1612)
T:\projects\VirtualDub_old\main\VideoSource.cpp(1624)
T:\projects\VirtualDub_old\main\VideoSource.cpp(1612)
T:\projects\VirtualDub_old\main\VideoSource.cpp(1624)
T:\projects\VirtualDub_old\main\VideoSource.cpp(1612)
T:\projects\VirtualDub_old\main\VideoSource.cpp(1624)
T:\projects\VirtualDub_old\main\Main.cpp(397)
T:\projects\VirtualDub_old\main\Main.cpp(414)
T:\projects\VirtualDub_old\main\Main.cpp(450)
T:\projects\VirtualDub_old\main\FilterSystem.cpp(561)
T:\projects\VirtualDub_old\main\FilterSystem.cpp(427)
Thread 00000540 (FastWriteStream)
Thread 00000610 (Processing)
T:\projects\VirtualDub_old\main\VideoSequenceCompressor.cpp(371)
T:\projects\VirtualDub_old\main\Dub.cpp(3022)
T:\projects\VirtualDub_old\main\Dub.cpp(3220)
T:\projects\VirtualDub_old\main\Dub.cpp(2835)
T:\projects\VirtualDub_old\main\VideoSource.cpp(1433)
T:\projects\VirtualDub_old\main\VideoSource.cpp(1461)
T:\projects\VirtualDub_old\main\Dub.cpp(2840)
T:\projects\VirtualDub_old\main\VideoSequenceCompressor.cpp(358)
T:\projects\VirtualDub_old\main\VideoSequenceCompressor.cpp(371)
T:\projects\VirtualDub_old\main\Dub.cpp(3022)
T:\projects\VirtualDub_old\main\Dub.cpp(3220)
T:\projects\VirtualDub_old\main\Dub.cpp(2835)
T:\projects\VirtualDub_old\main\VideoSource.cpp(1433)
T:\projects\VirtualDub_old\main\VideoSource.cpp(1461)
T:\projects\VirtualDub_old\main\Dub.cpp(2840)
T:\projects\VirtualDub_old\main\VideoSequenceCompressor.cpp(358)
Thread 00000518 (I/O processing)


6bf03ad4: libavcodec_enc!getVersion [6bec0000+42320+17b4]
6beed5c4: libavcodec_enc!avcodec_init [6bec0000+2170+2b454]
6bf09fe8: libavcodec_enc!getVersion [6bec0000+42320+7cc8]
6bee9ab9: libavcodec_enc!avcodec_init [6bec0000+2170+27949]
6bec7730: libavcodec_enc!avcodec_init [6bec0000+2170+55c0]
7788e440: ntdll!RtlSetBits [77880000+e110+330]
7788e602: ntdll!RtlUnwind [77880000+e526+dc]
7788e62b: ntdll!RtlUnwind [77880000+e526+105]
7788e440: ntdll!RtlSetBits [77880000+e110+330]
7788e602: ntdll!RtlUnwind [77880000+e526+dc]
7788e62b: ntdll!RtlUnwind [77880000+e526+105]
77e76e8b: KERNEL32!ValidateLCType [77e70000+690c+57f]
77896ff1: ntdll!NtCreateTimer [77880000+16e58+199]
778971b4: ntdll!NtCreateTimer [77880000+16e58+35c]
77e76e8b: KERNEL32!ValidateLCType [77e70000+690c+57f]
77896ff1: ntdll!NtCreateTimer [77880000+16e58+199]
778971b4: ntdll!NtCreateTimer [77880000+16e58+35c]
77e76e8b: KERNEL32!ValidateLCType [77e70000+690c+57f]
77e918ca: KERNEL32!GetThreadContext [77e70000+2183a+90]
77e76e8b: KERNEL32!ValidateLCType [77e70000+690c+57f]
7788e440: ntdll!RtlSetBits [77880000+e110+330]
7788e4db: ntdll!RtlSetBits [77880000+e110+3cb]
77e76e8b: KERNEL32!ValidateLCType [77e70000+690c+57f]
77e918ca: KERNEL32!GetThreadContext [77e70000+2183a+90]
7788e440: ntdll!RtlSetBits [77880000+e110+330]
7788e4db: ntdll!RtlSetBits [77880000+e110+3cb]
778829a9: ntdll!RtlUniform [77880000+2969+40]
778814b4: ntdll!DbgPrint [77880000+13f6+be]
778a0316: ntdll!KiUserExceptionDispatcher [77880000+20308+e]
77e8e8bb: KERNEL32!RaiseException [77e70000+1e884+37]
77882b10: ntdll!_vsnprintf [77880000+2ae4+2c]
778829a9: ntdll!RtlUniform [77880000+2969+40]
778814b4: ntdll!DbgPrint [77880000+13f6+be]
77e8e8bb: KERNEL32!RaiseException [77e70000+1e884+37]
77e8e8bb: KERNEL32!RaiseException [77e70000+1e884+37]
77e71a0d: KERNEL32!OutputDebugStringA [77e70000+18c8+145]
7788e440: ntdll!RtlSetBits [77880000+e110+330]
7788e602: ntdll!RtlUnwind [77880000+e526+dc]
7788e62b: ntdll!RtlUnwind [77880000+e526+105]
77e76e8b: KERNEL32!ValidateLCType [77e70000+690c+57f]
0274acb7: xvid!xvid_encore [02710000+7920+33397]
02740ea7: xvid!xvid_encore [02710000+7920+29587]
0273f6c1: xvid!xvid_encore [02710000+7920+27da1]
0274104d: xvid!xvid_encore [02710000+7920+2972d]
03c74dc7: ffvfw!DriverProc [03c70000+3660+1767]
77896ff1: ntdll!NtCreateTimer [77880000+16e58+199]
778971b4: ntdll!NtCreateTimer [77880000+16e58+35c]
77e76e8b: KERNEL32!ValidateLCType [77e70000+690c+57f]
77e76e8b: KERNEL32!ValidateLCType [77e70000+690c+57f]
77e918ca: KERNEL32!GetThreadContext [77e70000+2183a+90]
7788e440: ntdll!RtlSetBits [77880000+e110+330]
7788e4db: ntdll!RtlSetBits [77880000+e110+3cb]
778a0316: ntdll!KiUserExceptionDispatcher [77880000+20308+e]
77e8e8bb: KERNEL32!RaiseException [77e70000+1e884+37]
77882b10: ntdll!_vsnprintf [77880000+2ae4+2c]
6bec3810: libavcodec_enc!avcodec_init [6bec0000+2170+16a0]
6bec4ad2: libavcodec_enc!avcodec_init [6bec0000+2170+2962]
6bec3a81: libavcodec_enc!avcodec_init [6bec0000+2170+1911]
6bec1f1f: libavcodec_enc!avcodec_encode_video [6bec0000+1ef0+2f]
03c7743a: ffvfw!DriverProc [03c70000+3660+3dda]
03c74ae3: ffvfw!DriverProc [03c70000+3660+1483]
77e8e8bb: KERNEL32!RaiseException [77e70000+1e884+37]
77e71a0d: KERNEL32!OutputDebugStringA [77e70000+18c8+145]
0274588f: xvid!xvid_encore [02710000+7920+2df6f]
027428e7: xvid!xvid_encore [02710000+7920+2afc7]
02742907: xvid!xvid_encore [02710000+7920+2afe7]
0274292d: xvid!xvid_encore [02710000+7920+2b00d]
0271790e: xvid!xvid_decore [02710000+78d0+3e]
02713cd4: xvid!00003cd4
027171ac: xvid!DriverProc [02710000+6f00+2ac]
03c739e6: ffvfw!DriverProc [03c70000+3660+386]
77e78774: KERNEL32!GetModuleFileNameA [77e70000+860c+168]
77883970: ntdll!RtlExtendedMagicDivide [77880000+3816+15a]
778cb516: ntdll!RtlAllocateHeap [77880000+4b178+39e]
778cb52d: ntdll!RtlAllocateHeap [77880000+4b178+3b5]
779b83c3: OLEAUT32!VarBstrFromDate [779a0000+16930+1a93]
778cbc44: ntdll!RtlFreeHeap [77880000+4b691+5b3]
778cbb46: ntdll!RtlFreeHeap [77880000+4b691+4b5]
778cbd73: ntdll!RtlFreeHeap [77880000+4b691+6e2]
778cb650: ntdll!RtlAllocateHeap [77880000+4b178+4d8]
778cb516: ntdll!RtlAllocateHeap [77880000+4b178+39e]
778cb52d: ntdll!RtlAllocateHeap [77880000+4b178+3b5]
778cbb46: ntdll!RtlFreeHeap [77880000+4b691+4b5]
778cbd73: ntdll!RtlFreeHeap [77880000+4b691+6e2]
778cb650: ntdll!RtlAllocateHeap [77880000+4b178+4d8]
778cb516: ntdll!RtlAllocateHeap [77880000+4b178+39e]
778cb52d: ntdll!RtlAllocateHeap [77880000+4b178+3b5]
7788c696: ntdll!RtlDowncaseUnicodeString [77880000+c1f3+4a3]
77e09df0: USER32!ClientThreadSetup [77e00000+9db8+38]
0047fd51: _heap_alloc()
6a7717f8: MSVFW32!ICSendMessage [6a770000+17c4+34]
6a7717f8: MSVFW32!ICSendMessage [6a770000+17c4+34]
6a774ea4: MSVFW32!ICCompress [6a770000+4e43+61]
0046e271: VideoSequenceCompressor::packFrame()
0046798f: Dubber::WriteVideoFrame()
00407adc: AVIOutputStream::_write()
0046844f: Dubber::ProcessingThread()
00468316: Dubber::ProcessingThreadKickstart()
004800e8: _threadstart@4()
77e787dd: KERNEL32!GetModuleFileNameA [77e70000+860c+1d1]

-- End of report

bill_baroud
23rd August 2002, 22:56
hm i have run some test, with a win2K ... i haven't encounter any problem and the result is quite good.

i have just test on a anime HDTV rip with a lot of grain/details (SoulTaker opening) ... the result is a little more smooth than Xvid which retains all the details. But the output of ffwfv isn't bad, i like the way it encode .... and the GUI IS SO GOOD !!!!

i love how the way Milan have done this, with Alt CC calculator & graphical analyzer. (no need to log with debugView :P)


and it's fast ! (640x368 : 18fps, Xvid: 16fps, same param )

GREAT job Milan ! i'm wait with [edit : not impatience, but ] eagerness the next =)


P.S. : i can post some extract if someone is interested.

cult
23rd August 2002, 23:15
bill_baroud-yes,please,post.
I think it cant be run under job control in vd,does it?I use w2k.
whats the difference with xvid exactly?I loved the way it calculates the alt cc

bill_baroud
24th August 2002, 02:35
ok is there my test on Soul Taker Opening.

the original file is : 832x480 , mpeg4 v2 , m4c. (mp3, 256Kbits), 46.5mb



for the test, i have just put a Precise Bilinear Resize , to 640x368.

we're not here to test noise reduction ;)

-----------------------------------
FFwFv settings :
----------------
generic : fourcc XVID, max I 250, min I 1. no b-frame, no choice of codec.
Motion-est : EPZS, with 4 MV&High Quality
Quantization : 2-7, 2-7, Single coef to 4 with DC for Luma, and 10 without DC for Croma. H263 for the first pass and modulated for the 2nd.
Alt CC : i have use the analyzer and puch the "perfect button"
so High aggression, Hi-332, lo-99. AutoMRQ at 30, ManualBias at 80.

file size : 15 000

the result is here (http://breizhbill.baroud.free.fr/FFwfv_Test/SoulT_FFwfv.avi)

it's pretty good, but i have choose a too little size, so some macroblock when the camera move into smoke, and co. but it's watchable ;) ... red is handle quite good.

GUI looks like this :

http://breizhbill.baroud.free.fr/FFwfv_Test/FFwfv_analyze.jpg

and
http://breizhbill.baroud.free.fr/FFwfv_Test/FFwfv_altcc.jpg


-----------------------------------
Xvid settings :
---------------

err i have used the same param as for FFwfv
dunno if it's a good idea, but i have any doc on ffwfv to start with.

the results is here (http://breizhbill.baroud.free.fr/FFwfv_Test/SoulT_Xvid.avi)

for my taste, it's little worse than FFwfv ... there is more details, but i have a notice some color spreading when a lot of motion, and there is macroblock on very lighter color (red/yellow/green flash)

ok the size is too small i think, with 17.5mb without audio, it's harder to notice difference, but well, i like the way if ffwfv !

if -h or someone could add some info on "Single Coefficient Elimination" it would be great =)

Belgabor
25th August 2002, 23:05
I've tried to test it, but i cant get it to work :(

- Choosing XVID (mpeg4 codec): vdub quits without comment when i started the 2nd pass.
- Choosing DIV3 (msmpeg4 codec): file not playable (no error though, video is black)
- Choosing MP42 (msmpeg4v2 codec): file plays with funny results. Kinda looks like a rpaired bad freeze in a divx 3.11 movie (throughout though ;))

Perhaps I'm doing something wrong, but if so, i dunno what (yes, hight and width are divisible by 16)

Cheers
Belgabor

Phanton_13
26th August 2002, 03:27
When I can download the original file. I'm testing various codec in diferents situations an this is a good video for my purposes, my test is in the range of low bitrate to high bitrate, its quite dificult to the nature of diferents formats the results of my tests are stranges good codecs in bad sitution and worse codecs in the same situationas create contardictories results.
my preliminar conclusions:
RM9: good in all situations
DIVX5: Bad at extremedly low bitrates
XVID: same as divx5
DDVFW: testing the new realease
VP3: good a extremedly low bitrates and is beted at medium bitrates by DIV5 and xvid but dificult to configure for best results( I ned to compile the new version 3.6.x, with a litle improvements it cam beat a divx5 in any situations).
Rududu: exclude is very bad.
MSMPEG4/Divx 3.11 : not teste but im planing to test it.
the list continues....)

bill_baroud
26th August 2002, 21:24
@belgabor :


ehehe, don't choose any codec , just uncheck the box ... it's how i have obtain something (it's the default option :p baka :p ).

i have just try msmpeg4 one times , and have obtain a blackscreen too (but the same file size ;) ). Might be a decompression issue.

Dali Lama
27th August 2002, 12:57
I used to have that Soul Taker OP in HDTV. I got it from Jackei's site once. Is there anyway you could put up that clip or another anime or regular movie HDTV clip. I'd like to test out some compression settings on HDTV clips.

Thanks if you can,

Dali

milan
27th August 2002, 13:59
Thank you for testing ffvfw.

I know libavcodec is generaly worse than XviD, but I just wanted to make it fully usable - not only the decoding part. And for those who find XviD better but like ffvfw GUI, there is possiblity to use almost all XviD features with ffvfw: it was realy easy to add, because XviD API is simple and it's VFW is very readable.

And thank you for bugreports, this is exactly what I need. I want to fix most critical ffvfw bugs (I'm afraid there are many of them) and then focus on ffdshow again. New release is realy needed.
BTW as you may notice, ffvfw can use ffdshow filters for preprocessing and this would be enabled only with new ffdshow version.

@Belgabor
I don't know why VirtualDub crashes when XVID is selected, but for DIV3 and MP42 I think you have to disable 4MV and/or high quality. Not all combinations of codecs and ME settings works and I have to find out what is allowed and what not.

bill_baroud
27th August 2002, 16:57
humm, i had downloaded about 3gb of HDTV/DVDrip anime opening/ending on this site :

http//www.irradiance.net

but i have forgot the path after that, and now the site is slow as hell.

i have deleted a lot of them, but i have still some other clip, but not HDTV (just Chobits & SoulTaker ... and a CCS one, but i haven't those ;) )

my webspace is low (100mb) and each clip are about 40-50mb~ so it's difficult for me to up this ... if you have some space, no problem.

...
yah
find it (see my post on RP9 ;) )
http://www.irradiance.net/Animation/GroupsMPEG4/wind/

but slooow now.

@milan : great work ! i'm looking for the next !

cult
27th August 2002, 18:27
i have tested ffvfw choosing xvid and vd and it works fine for me(w2k).
It crashes though if u try to encode addin jobs in vd

Belgabor
27th August 2002, 20:41
ehehe, don't choose any codec , just uncheck the box ... it's how i have obtain something (it's the default option baka ).

I know :p Thats what i did, just wanted to be clear on the differences.

@milan: What you proposed for div3 worked. Only strange thing is the video won't play with the original divx 3.11 playback filter until i seek a bit. Then I can go back to the start and it works?! No problem with ffdshow though.

General question. Are there in principle any differnces (= encoding code) used in encoding with the diffrent selectable codecs or do they only differ in what kind of options are supported and bitstream format? Or to put it another way (to make clear what i mean) if I use the same options and encode with mpeg4 and msmpeg4 (e.g.) are there any differences in the encoding routines used?

Cheers
Belgabor

Easy123
27th August 2002, 22:19
Donīt flame me... But is there any kind of documentation of how to use this Program? I installed it for the 1st time... The Installer says that it installed a readme.txt to help folder, but thatīs empty on my PC... So just a Question. If there is a doc where can it be found????


CU
Easy123

bill_baroud
27th August 2002, 22:27
if you read the website of milan , it say something like : there isn't any documentation for instance, i need to write one :P

i was little disappointed too, when i looked in the help dir ;)

there is a few explication in the "about" section in the configuration.

some info one the "single coefficient elimination" would be great :)


@ milan : i have forgot this .... when i use B-frame (to 1, cause to the avi format ...) , i have noticed a strong reduction of the brightness...it's remain me that divx5 have this too no ? it's entirely due to b-frame or something else ?


... last minute ...
[bug report]
i get a "VideoSourceAVI error : the source image format isn't acceptable. (error(-2))" when i try to seek the file i have uploaded in VirtualDub.
[/bug report]



after test, it's the Single Coef elimination on the Luma (treshold 4, with DC -what's that ?-) which cause the change of brightness (darker) , not the B-frame.
don't use them, it's worse than without ;) (in my test, dunno if i do the things right).

[bug report]
if B-frame activated in the first pass, the second pass crash.
i don't know if use B-Frame just in the 2nd pass is a good idea (the frame graph is _really_ different). i can't verify if the file is right cause the Vdub bug.
(well you have said you have a decompression problem, so i think is related to that)
[/bug report]

it's all for today, i go to sleep =)

-h
27th August 2002, 23:49
I can't actually get it to run at all now - VirtualDub crashes when you open the codec list box.

But anyway, I was wondering if it would be possible for ffvfw to "ignore" the AVI-output buffer, and instead write the output to its own file? That way it could output an MPEG-1 video stream, or whatever other formats ffmpeg picks up along the way.

Just a suggestion. It'd be nice to have another MPEG-1 codec, especially one as fast as ffmpeg.

-h

milan
28th August 2002, 07:40
I use the same options and encode with mpeg4 and msmpeg4 (e.g.) are there any differences in the encoding routines used?


I'm not sure. As I know libavcodec has many routines common for all codecs, but of course not all codecs supports same features. If you have time, please try this and let me know.


It crashes though if u try to encode addin jobs in vd


I didn't test it with jobs. I will do this.


I've just tried to save VirtualDub jobs with ffvfw selected and when job should be executed VDub reports Sylia script error: parse error. I think it's because ffvfw stores it's state in 8192 bytes and thats maybe too long. But that's just guess, maybe it's realy ffvfw fault.



But is there any kind of documentation of how to use this Program? I installed it for the 1st time... The Installer says that it installed a readme.txt to help folder, but thatīs empty on my PC... So just a Question. If there is a doc where can it be found?


Readme.txt it the same as text in about page. It isn't installed because of small bug in installer script. There is no documentation yet. Some options are explained in Koepi's XOE, but doc for libavcodec's special options isn't available yet. When I will bugfix ffvfw I will try to write something.


some info one the "single coefficient elimination" would be great


I'm not sure what is it good for, but recent libavcodec supports it, so I added it into ffvfw too. Some info should be in MPEG4 standard and in ffmpeg mailing list.


i have forgot this .... when i use B-frame (to 1, cause to the avi format ...) , i have noticed a strong reduction of the brightness...it's remain me that divx5 have this too no ? it's entirely due to b-frame or something else ?


That's strange I didn't notice that. More tests needed... Rather don't use coeff. elimination yet. I will ask Michael Niedermayer about info how it works.


i get a "VideoSourceAVI error : the source image format isn't acceptable. (error(-2))" when i try to seek the file i have uploaded in VirtualDub.


If this happens when ffvfw should be used for decoding, it is known bug. I will fix that when more important bug will be fixed.

B frames should be used in both passes, but b frame multiplier and offset can (and propably) should be changed. And BTW: there is no special b frames handling in two pass code, they are handled just like p frames. I wanted to wait how XviD developers would solve this when XviD b frames will be finished.


I can't actually get it to run at all now - VirtualDub crashes when you open the codec list box.


I think it has somethink to do with old ffdshow version present in your system. I will try to fix it.


But anyway, I was wondering if it would be possible for ffvfw to "ignore" the AVI-output buffer, and instead write the output to its own file? That way it could output an MPEG-1 video stream, or whatever other formats ffmpeg picks up along the way.

Just a suggestion. It'd be nice to have another MPEG-1 codec, especially one as fast as ffmpeg.


I think somethink like this already exists (or existed years ago). It would be possible to implement in ffvfw - MPEG muxer sources are available from many projects.

Thank you for interesting in ffvfw and for your ideas and bugreport. I will try to fix ffvfw - I'm realy surprised how many bugs I've made.

P.S.

I think it would be interesting to have install builds for now. If you think they can be useful too and are able to provide them, please email me.