View Full Version : New ffdshow build (?)
So you are saying that if I hadn't installed the WM9 VCM codec, that ffdshow could allow me to load WM9 AVIs directly in vdub?no, ffdshow doesnt support it
Isochroma
30th May 2006, 17:31
So what did clsid mean when he said "decoding though vfw is not the same..."? Other than the video encoder, ffdshow is a Directshow only decoder, correct? If it is a VFW decoder also, it would work with vdub...
hm it seems ffdshow indeed includes wmv9 decoding (for vfw), so when enabling wmv9 decoding via vfw it should also work in a dshow player
SeeMoreDigital
30th May 2006, 17:51
So what did clsid mean when he said "decoding though vfw is not the same..."? Other than the video encoder, ffdshow is a Directshow only decoder, correct? If it is a VFW decoder also, it would work with vdub...What you want to do should be possible with VirtualDub-MPEG-2 v1.6.11... but not with regular builds of VirtualDub.
Liisachan
30th May 2006, 17:53
You can open (WMV3).avi via VfW without WMV VCM, if WMV is enabled in ffdshow VfW.
iirc You can (unofficially?) open (WMV3).avi via DS too with ffdshow, but there's no GUI setting for it and you'll need to configure ffdshow with regedit.
Liisachan
30th May 2006, 17:57
So what did clsid mean when he said "decoding though vfw is not the same..."?
For instance, just because you can decode (x264) via DirectShow with ffdshow, doesn't mean you can open (x264).avi via VfW. You'd need to enable AVC via VfW separately if you wanted.
Other than the video encoder, ffdshow is a Directshow only decoder, correct? no both DirectShow decoding and VfW decoding are supported, separately.
shon3i
30th May 2006, 18:27
iirc You can (unofficially?) open (WMV3).avi via DS too with ffdshow, but there's no GUI setting for it and you'll need to configure ffdshow with regedit.
Interesting and True, i don't know why ffdshow devs hide this?
breez
30th May 2006, 19:51
Curiously this one build crashes when entering Info&Debug page in ffdshow while decoding WMV3 (DS). Playback seemed fine.
Isochroma
30th May 2006, 21:56
I was today playing with ffdshow's colorspace conversion. Noticed that with yv12 output it uses about half the CPU for HD clips. However, my Nvidia card does incorrect colorspace conversion, so I have to either use software conversion or use "levels" as suggested earlier in the thread.
However, if levels is used, it maps the range 16-235 to 0-255. This means that it clips 0-16 and 235-255 in the source signal, correct? So there would be a quality loss compared to YV12>RGB conversion, I assume?
After comparing them side-by-side, I can see banding in the levels version that is not present in the RGB-converted one. This must be due to the merging of values.
foxyshadis
30th May 2006, 23:33
WMV3 was available for selection a few months ago, but it's crazy buggy and glitches up a lot. That's probably why it's hidden. (In particular, it seems to occasionally miss keyframes, so the entire next scene is all messed up. Maybe VC-1 has a secondary keyframe form or something like that.) Of course I haven't tried it in a few months now.
baribal
31st May 2006, 22:36
Hi2all.
Q1: I have a crash when i use ffdshow for image processing (crop, deinterlace, etc.) in my tvtuner program. It happens with all 2546 builds not depending of compilation. I had no problems with earlier builds. I'm alone with this problem?
Q2: When i use ffdshow for compression on-the-fly i usually set options: encoder to XVID, FOURCC to XVID, mode to two passes-first pass. When i try to do the second pass of my first pass full video file in the VDub with XVID codec or try to open video.stats in the program "stats analyzer" i have a crash. So i have video.stats file that doesn't compatible with XVID
video.pass file. When i do the second pass with ffdshow codec all is ok but quality of second pass are terrible (huge blocking effect). So can i compress video with ffdshow and get
video.pass format file not the video.stats format?
cc979
1st June 2006, 00:30
does normal xvid codec work for you ?
foxyshadis
1st June 2006, 03:42
No, xvid and ffdshow's formats are incompatible and unresolvable, unless you were to write a utility to translate between them. You'll just have to run both passes afterward, or set ffdshow's second pass options better (it's pretty difficult to configure, I don't blame you for getting bad results).
What tv tuner program?
baribal
1st June 2006, 08:47
does normal xvid codec work for you ?
Yes. But when i use on-the-fly crop, deinterlace etc. in the tvtuner program i have a high CPU load. So i think that ffdshow image processing is more optimized for speed and quality probably than filters in my beholdtv tvtuner program.
baribal
1st June 2006, 08:54
You'll just have to run both passes afterward, or set ffdshow's second pass options better.
What tv tuner program?
I use BeholdTV. When i get full quality first pass video file (is it quant 2 or 1 encoding?) is there some quality loss while i'm doing two-pass encoding of it? Or it'll be better to do only second pass of it?
PS And how to tune the second pass in the ffdshow? I usually set only video target size in XVID codec and never have this ffdshow strange blocking artifacts.
Livesms
1st June 2006, 09:00
I use BeholdTV. When i get full quality first pass video file (is it quant 2 or 1 encoding?) is there some quality loss while i'm doing two-pass encoding of it? Or it'll be better to do only second pass of it?
PS And how to tune the second pass in the ffdshow? I usually set only video target size in XVID codec and never have this ffdshow strange blocking artifacts.
Can you post your ffdshow build, codec setting, btv&drv version? I'm using BeholdTV 507RDS and interested in realtime high quality capturing.
baribal
1st June 2006, 09:27
Can you post your ffdshow build, codec setting, btv&drv version?
ffdshow version 2534. Settings:
Encoder - XVID, Mode - Two pass - fisrt pass, b-frames - 2, croma ME - off, preset motion set precision - Ultra high, preset VHQ mode - mode decision, quantization - H263, Trellis - on.
Image processing: Crop - 4-4-4-4, deinterlace - kernel or tomsmocomp, resize - lanczoz 576:416.
BeholdTV - 4.80, driver - v4000. Frame - 768х576.
CPU: Athlon64 1800Mhz(2520Mhz).
And you have to do second pass in VDub.
Livesms
1st June 2006, 09:40
ffdshow version 2534. Settings:
Encoder - XVID, Mode - Two pass - fisrt pass, b-frames - 2, croma ME - off, preset motion set precision - Ultra high, preset VHQ mode - mode decision, quantization - H263, Trellis - on.
Image processing: Crop - 4-4-4-4, deinterlace - kernel or tomsmocomp, resize - lanczoz 576:416.
BeholdTV - 4.80, driver - v4000. Frame - 768х576.
CPU: Athlon64 1800Mhz(2520Mhz).
And you have to do second pass in VDub.
Is it your settings for realtime capture? Seems not...
Two pass - fisrt pass
b-frames - 2
preset motion set precision - Ultra high
Will load your CPU up to 300% in realtime :)
I asked for realtime codec settings
videomixer9
1st June 2006, 09:51
Especially the two pass encoding seems odd to me for realtime capturing. The source is kinda gone and not available anymore for the second pass. I still use the freakazoid huffyuv version from ffdshow for realtime captures, wastes space in masses but I can nicely reencode it later without frameloss. 1 TB diskspace isn't that rare nowadays either ...
baribal
1st June 2006, 09:59
Two pass - fisrt pass
b-frames - 2
preset motion set precision - Ultra high
Will load your CPU up to 300% in realtime :)
It's my realtime settings. :) Trust me. :)
baribal
1st June 2006, 10:01
Especially the two pass encoding seems odd to me for realtime capturing. The source is kinda gone and not available anymore for the second pass.
But i have full quality first pass. It's max quality video that i may get.
haruhiko_yamagata
1st June 2006, 15:59
This patch queue samples just before sent to video
renderer and execute video renderer on worker thread.
Compared to rev2546, 10 to 20%(Max 35%) of frame rate
improvement is expected. Single CPU/multithreading is
interesting, though it is not tested.
[Status]
Alpha testing.
Prior version should be more stable.
[Patch]
ffdshow_multithread_060601.patch is PATCH to PATCH.
To rev2546+ffdshow_multithread_060517.patch
http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491
videomixer9
1st June 2006, 16:10
Thanks for making it a patch to the patch :thanks:
Liisachan
1st June 2006, 16:17
*waiting impatiently*
videomixer9
1st June 2006, 16:30
Click here (http://www.fileking.to/download.php?n=r36uAay4jJ) or here (http://www.sebone.de/download.php?file=53a83db3d21c798959a644f6af786980) or here (http://www.filepoint.de/download/5968-dl-ffdshow-20060601-rev2546_exe) or here (http://www.mooload.com/new/file.php?file=files/010606/1149176115/ffdshow-20060601-rev2546.exe)
*waiting-over*
haruhiko_yamagata
1st June 2006, 16:39
Thanks for making it a patch to the patch :thanks:
Hello. You are wellcome.
You are fast!
http://rapidshare.de/files/21944958/ffdshow-20060601.exe.html
http://www.mytempdir.com/707418
http://www.megaupload.com/?d=RX2BPLLE
LoRd_MuldeR
1st June 2006, 16:54
Click here (http://www.fileking.to/download.php?n=r36uAay4jJ) or here (http://www.sebone.de/download.php?file=53a83db3d21c798959a644f6af786980) or here (http://www.filepoint.de/download/5968-dl-ffdshow-20060601-rev2546_exe) or here (http://www.mooload.com/new/file.php?file=files/010606/1149176115/ffdshow-20060601-rev2546.exe)
*waiting-over*
Seems to work here.
Liisachan
1st June 2006, 17:06
ffdshow-20060601-rev2546.exe
just did a quick test, no obvious pb so far
installer's wmv3 option seemed cool,
wmv3 does play via ds tho being unstable
videomixer9
1st June 2006, 17:20
what's more interesting that the broken wmv is if the multithread patch shows it effectiveness :p
On single core on pure benchmarking this doesn't help much, timeCodec results were almost identical at least without the resizing, so I maybe try that next, prolly just using the multiply x2 option.
cc979
1st June 2006, 19:58
Yes. But when i use on-the-fly crop, deinterlace etc. in the tvtuner program i have a high CPU load. So i think that ffdshow image processing is more optimized for speed and quality probably than filters in my beholdtv tvtuner program.
you could encode with huffYUV then load it into vdub do you post-processing then encode to xvid
foxyshadis
1st June 2006, 22:01
vm9: Try playing a 720p avc file with old/new version. Or any file that drives your cpu near the edge and causes stuttering (toss on a few filters if you have to :p) . If it's way under or way over your cpu's capabilities you won't notice much difference.
I have the perfect set of almost-but-not-quite shows at home, I'll test tonight.
haruhiko_yamagata
1st June 2006, 23:33
On single core on pure benchmarking this doesn't help much, timeCodec results were almost identical at least without the resizing, so I maybe try that next, prolly just using the multiply x2 option.
Did you use null video for "pure benchmarking" ?
The patch need video renderer to take effect. With old video renderer it cannot do anything but to add bugs:o . Zoom player's overlay mixer is the old video renderer.
Use overlay mixer, VMR 7/9 and test files with frame rate 17 to 20 with prior version to see the effect.
thuan
2nd June 2006, 06:37
Test with newest build from vm9 with latest patch from haruhiko_yamagata, here the result from testing on an AMD T-bred 1.5GHz 512MB RAM video renderer Overlaymixer, no filter with first two mins from Shinsen-subs Ergo Proxy ep1 HD.ffdshow-20060601-rev2546:
user: 56s, kernel: 1s, total: 57s, real: 71s, fps: 51, dfps:41.3
ffdshow-20060531-rev2546:
user: 56s, kernel: 6s, total: 63s, real: 77s, fps: 46.7, dfps: 37.9
CoreAVC1.0 pro:
user: 36s, kernel: 6s, total: 42s, real: 57s, fps: 68.6, dfps: 51.6According to the number then CoreAVC is still much faster but with the new ffdshow build I can watch 720p AVC content fine, with the old one it's jerky and lag like hell. Thanks Haruhiko. I wonder why I bought CoreAVC so soon, now I can play what I want okay for free damn.
EDIT: the OP of Ergo Proxy is a little choppy (guess I take back what I said about buying CoreAVC) but now with output queue there's no lag (ffdshow automatic drop frame), I'm happy with it.
Liisachan
2nd June 2006, 06:57
afaik, CoreAVC is not payware just because they want to make much money, but because they have to pay MPEG license fees.
But I would rather not buy CoreAVC but would make some donation to haruhiko_yamagata or milan. That way I'd feel much, much better even if the money spent would be more.
videomixer9
2nd June 2006, 07:31
Did you use null video for "pure benchmarking" ?
The patch need video renderer to take effect. With old video renderer it cannot do anything but to add bugs:o . Zoom player's overlay mixer is the old video renderer.
Use overlay mixer, VMR 7/9 and test files with frame rate 17 to 20 with prior version to see the effect.
Oh well I tried a renderer but prolly messed up yesterday, whatever I redid a test this morning with superman.mp4 on VMR7 instead of like before VMR9 and got this
200605031:
User: 89s, kernel: 5s, total: 94s, real: 98s, fps: 23.9, dfps: 22.9
20060601:
User: 89s, kernel: 0s, total: 90s, real: 94s, fps: 24.9, dfps: 23.9
of course it cannot boost the decoder much but noticable is the massive reduction of kernel time used, which is prolly the time the renderer wastes. 1fps overall gain but it appears to be running much smoother, while old version will lag behind sometimes. So even on single CPU this is a nice patch to make the overall video appearance a smoother thing and put load off the video renderer! So everyone get sure to enable output queuing! :thanks:
As far as I think it's not enabled per default, but I guess I make it one, just need to mod the installer again.
Liisachan
2nd June 2006, 10:20
So everyone get sure to enable output queuing! :thanks:
As far as I think it's not enabled per default, but I guess I make it one, just need to mod the installer again. You mean Miscellaneous | Other controls | Queue output sample? If so, you're right, it's not enabled by def. Are there any possible bad side-effects thinkable by enabling it? I'm kindof curious if this works with VSFilter/MPC's sub pic buffering OR non-buffering (i.e. what if you disable subpic buffering in VS/MPC)...
haruhiko_yamagata
2nd June 2006, 11:10
afaik, CoreAVC is not payware just because they want to make much money, but because they have to pay MPEG license fees.
But I would rather not buy CoreAVC but would make some donation to haruhiko_yamagata or milan. That way I'd feel much, much better even if the money spent would be more.
Thank you ver much. Apparently milan should be donated, not me. But I'm glad to read your post.
haruhiko_yamagata
2nd June 2006, 12:38
You mean Miscellaneous | Other controls | Queue output sample? If so, you're right, it's not enabled by def. Are there any possible bad side-effects thinkable by enabling it?
I'm testing single CPU PCs now.
In some cases, frame rate significantly drops when checked.
In some cases, vice versa.
haruhiko_yamagata
4th June 2006, 12:25
For better single CPU/multithreading (test).
In some cases, output queue lost performance with the prior revision.
The streaming thread has access to the VRAM buffer,
the video renderer thread has it too.
Nervus VRAM should not be accessed from two threads simultaneously.
This time, THREAD_PRIORITY_ABOVE_NORMAL for video rendering thread.
This will prevent simultaneous access to VRAM from two threads.
This may cause conflict with audio rendering thread.
The side effect would be clicking noise in the audio.
It was not heard in my limited tests.
If it apears, I have another option to test.
Please report.
Bug fix: fixed reconnect to VMR9.
To change resize setting while playing may cause dynamic reconnect.
Prior revision VMR9(non renderless) blacked out after changing resize setting.
Not all the video renderer succeed in reconnect.
[patch] (http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491)
ffdshow_multithread_060604.patch is PATCH to PATCH.
To rev2546 + ...060517.patch + ...060601.patch
videomixer9
4th June 2006, 12:42
Click here (http://ffdshow.drition.net/current.php) to download newest build with ffdshow_multithread_060604.patch :p
Liisachan
4th June 2006, 15:29
nice :D
videomixer9
4th June 2006, 16:57
cannot help this, but my impression is somewhat funny, during some stupid benchmarks this seemed to be slower, during actual playback and watching taskmanager it doesn't seem to make any real difference ... I had an odd behaviour with dvd playback via ffdshow with the older one, that thing disappeared.
Avish
5th June 2006, 15:45
Is it possible to add "auto" option in ffdshow's deinterlacing section? Coz I'm not quiet sure which one to use when. :D
SeeMoreDigital
5th June 2006, 17:30
Speaking of de-interlacing....
Does anybody know whether if the libavcodec MPEG-4 decoder filter is able to offer interlaced decoding?
Cheers
LoRd_MuldeR
5th June 2006, 21:08
Is it possible to add "auto" option in ffdshow's deinterlacing section? Coz I'm not quiet sure which one to use when. :D
I think you should try KernelDeinterlacer or TomsMoComp
With TomsMoComp I prefer Vertical-Filter enabled plus some Sharpen filter afterwards...
Avish
5th June 2006, 21:28
I think you should try KernelDeinterlacer or TomsMoComp
With TomsMoComp I prefer Vertical-Filter enabled plus some Sharpen filter afterwards...Thanks. I'll try them. But still I'd prefer "auto" if it's possible. :D
BTW, what's that "speedup tricks" option for, when I choose libavcodec? What speedup tricks it uses?
LoRd_MuldeR
5th June 2006, 22:26
Thanks. I'll try them. But still I'd prefer "auto" if it's possible. :D
BTW, what's that "speedup tricks" option for, when I choose libavcodec? What speedup tricks it uses?
Well, an auto detection for interlaced material would be nice.
So the deinterlace filter could be enabled/disabled automatically.
But which deinterlacer you want to use, is still your choice.
Different people prefer different deinterlacers...
Just try out which looks best for your eyes and use this one ;-)
mpioner
6th June 2006, 00:08
Avish
SeeMoreDigital
LoRd_MuldeR
http://sourceforge.net/tracker/index.php?func=detail&aid=1244154&group_id=53761&atid=471492
Zarxrax
6th June 2006, 01:21
I have a question regarding FFDshow's audio processing.
I would like to watch some videos at a faster speed. I can add an assumefps() avisynth command on the ffdshow video decoder, and that will change the speed of the video. However, I cant find a way to make a similar change for the audio.
Is this possible with current ffdshow, or does anyone know if ffdshow can have avisynth processing added into the audio decoder?
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.