New ffdshow build (?)

[Isochroma]

@CLSID: Yes, there is a bug in CoreAVC or ffdshow or both.

There are many RAW formats that can be selected; selecting YUV only means ffdshow should ONLY put itself in the graph if the upstream filter is outputting YUV.

However, even if CoreAVC is set to some RGB output, ffdshow still puts itself ahead and then CoreAVC outputs YUV.

[clsid]

@midiboy, try using {04FE9017-F873-410E-871E-AB91661A4EF7} and enable RAW support in the normal ffdshow decoder.


@Isochroma, do you mean that if you set ffdshow to accept only YUV in RAW mode, then CoreAVC suddenly starts outputting YUV instead of RGB?

[Isochroma]

YES, EXACTLY, you have hit the nail on the head.

[foxyshadis]

I bet CoreAVC uses YUV as a fallback mode, then, even if RGB is selected. Probably queries for all supported colorspaces, and if it does YUV but not RGB it'll switch. I wonder if it will use RGB fallback if you have YUV selected, too.

You'll have to ask Core about that behavior though.

[midiboy]

midiboy, try using {04FE9017-F873-410E-871E-AB91661A4EF7} and enable RAW support in the normal ffdshow decoder.

Hi Clsid,

yeah I know I can do that but then ffdshow will insert itself in all kinds of graphs where I don´t want it (tv recording software etc.).

Why did you stop using the raw video processor filter ? That was a very good idea, having a seperate filter for raw video processing that can be used for special things like DVD postprocessing WITHOUT disturing other playback graphs.

Would it be too much work supporting it again ??

Thanks,
Alex

[KoD]

midiboy, what's wrong with enabling what raw formats you want ffdshow to act as a postprocessing filter in ffdshow video decoder configuration -> Codecs page -> Raw option ?

If you want graph building control (which filters go where and in what order), you should know that's not meant for a filter in the graph to decide, but for the player that builds the graph. Use something like ZoomPlayer that offers the user an interface to alter the graph as he wants or contact the makers of the playback software you are using to implement such a functionality. Having filters force what goes where is wrong ! I leave it up to you as an exercise to find out why. ffdshow already forces its choices in some situations, and that's what's causing some issues (as well as solving some issues like explorer thumbnails).

And as amazing as it may seem, falling back to a format that all filters in the graph agree upon is what's meant to happen. Is what makes automatic graph building work.

[clsid]

Afaik, no changes have been made to the raw filter. Try some old versions to see when it stopped working for you.

[haruhiko_yamagata]

Though I'm messed up with the bug (http://forum.doom9.org/showthread.php?p=919534#post919534) of the patch for MPC and don't have much time, it may be interesting to try adding a option "DVD only" for Raw video.
TffdshowDecVideo::dvdproc shows if the source is DVD in most cases.
{04FE9017-F873-410E-871E-AB91661A4EF7} is suposed to be added into filter graph manually and used in graphedit.exe. That's why it has that low merit setting.

[foxyshadis]

And as amazing as it may seem, falling back to a format that all filters in the graph agree upon is what's meant to happen. Is what makes automatic graph building work.

I realize that, but Isochroma implied that it was exclusive. Similar to how ffdshow has total control over preferred/fallback/disabled formats. Now that I found a screenshot of 1.1 prefs (http://www.coreavc.com/index.php?option=com_joom12pic&Itemid=1), which I assume is the same in 1.2, it really is a full list of formats in order of preference, and there's no way to easily remove RGB or YUV modes, so a fallback to YUV is totally understandable. (I'm surprised it's possible to disable them completely via the registry, honestly.)

[Reino]

The fact that the following MOV[SVQ3+AAC] crashes...is this FFDShow to blame or the MP4 Splitter?

link: http://www.a-film.nl/film/trailer/00000397_quicktime_HOOG.mov

[Episode]

@clsid, would it be possible to have another icl9 build sometime soon? Thanks in advance!

[Jeremy Duncan]

Though I'm messed up with the bug (http://forum.doom9.org/showthread.php?p=919534#post919534) of the patch for MPC and don't have much time, it may be interesting to try adding a option "DVD only" for Raw video.
TffdshowDecVideo::dvdproc shows if the source is DVD in most cases.
{04FE9017-F873-410E-871E-AB91661A4EF7} is suposed to be added into filter graph manually and used in graphedit.exe. That's why it has that low merit setting.

That's a nice idea.

[Px]

I tested the VFW encoder side of ffdshow. rev 696, the following encoders worked, assume those not listed didn't work.
I tested
ffdshow_rev705_20061222_clsid.exe
ffdshow_rev705_20061222_clsid_icl9.exe
Still "Cannot start encoder (-100)" on MPEG4 codec. Which build, you are used for test?


All other codecs chucked out a "Cannot start encoder (-100)" error in VirtualDub 1.7.0. The source used was an AviSynth input size 720x576@25 FPS, YV12 colourspace. The settings used were the defaults for each codec, 1 pass quality 80.
Did you tried to recompress files? I try both Vdub/Vdubmod, 5 or 6 files with different codecs, divx, xvid, mpeg2, on all of them "Cannot start encoder (-100)" error appeared :(

[_xxl]

I compiled ffdshow with wvc1 support in wmv9lib.
Please enable vc1 from codec list.
http://www.mytempdir.com/1129848

[Episode]

I really don't understand why CCCP -project considers ffdshow-tryouts as very unstable and unusable. They released a new version few days ago with a version of ffdshow that's dated way back in the september and they won't use tryouts versions because they have "very badly written multithreading code and almost none real improvements". Is the original code really that much more stable than what we have now or is CCCP just ignoring this project since the changes are not made by milan?-)

[foxyshadis]

Presumably one of their members used a build with queuing in the summer sometime, it didn't noticeably improve performance (or he stumbled onto one of the hanging bugs), and instead of filing a bug they wrote off the whole project indefinitely. But I'll see if I can convince them; I was sort of hoping Check would, since he's somehow involved with the group.

The original code is most definitely not more stable than what we have now. If CCCP wants to disable multithreading in their installer that's easy enough, but that's no excuse for ignoring the numerous bugfixes and performance improvements even in the original ffdshow code. Obvs none of them have compared current AVC performance to the last official build's.

[fastplayer]

Quote from the CCCP changelog (http://www.cccp-project.net/wiki/index.php?title=Main_Page):
Updated ffdshow to 2006-09-23, no multithreading since it isn't currently stable enough. Yes, this build might seem old. The reason for this is that ffdshow-tryouts isn't (and hasn't been) very stable. We prioritize stability over bleeding-edge features.
I'd really like to know what sh|t they're on... :rolleyes:

[_xxl]

Updated ffdshow to 2006-09-23, no multithreading since it isn't currently stable enough. Yes, this build might seem old. The reason for this is that ffdshow-tryouts isn't (and hasn't been) very stable. We prioritize stability over bleeding-edge features.
Yes,they seem to know everything better than we do.:confused:

[sillKotscha]

wtf is cccp? and more important... who cares about them?

[foxyshadis]

Combined Community Codec Pack (http://www.cccp-project.net/). The most popular codec pack on the net currently; k-lite has lost a lot of popular support over the past year or two, since CCCP showed up, because the alternative is much simpler and less dangerous on the system, and does a great job of cleaning up other codec packs' leftover garbage. They basically center the pack around ffdshow & haali's splitter, with a few extras to take up the slack. Fansub groups in particular nearly unanimously recommend CCCP now. It's important, because more people install such things than ever install ffdshow separately.

(In case you know the real meaning of CCCP, they do hint at that as well.)

[haruhiko_yamagata]

QueueUp20061223.patch (http://sourceforge.net/tracker/index.php?func=detail&aid=1621133&group_id=173941&atid=867362)

New version of queue. This patch was writen to improve the stability and compatibility issue. Ironically this patch is too large and needs more testing.

As a result, queue becomes effective with Zoom player and MPC + VMR9.

Another fix includes,
improved compatibility issue with BSPlayer.
Windows Media Player is excluded from queueing internally regardless of the settings.

VMR9 rengerless + RGB out + patched MPC : continue pressing right cursor key freezes. This issue is improved if queue is off. If queue is on, we have to wait for new builds.

My binary (http://downloads.sourceforge.net/ffdshow-tryout/ffdshow_rev706p_20061223_Q.exe) is available for testing.

ListEmptyIMediaSamples is a helper class of queue and does prefetch.
GetBuffer and Receive is now called from the same thread.
If Receive and GetBuffer is called from other threads, GetBuffer often returns error.
By cooperating with TffOutputQ, ListEmptyIMediaSamples buffers the IMediaSample as soon as it is released in TffOutputQ::ThreadProc.

[sillKotscha]

(In case you know the real meaning of CCCP, they do hint at that as well.)

Союз Советских Социалистических Республик :D

installing codec packs... that's the point - if a widely accepted codec pack offers ffdshow respectively build the pack around ffdshow than someone should convince them to include the last marked stable beta release... as it is rock solid for 99% of the users...

on the other hand it is a move in the right direction that no rip-offs of (il-) legal codecs are floating around but ffdshow is used instead in their pack... but to be honest - I don't care about codec packs :)

it's just kind of a sad feeling that your (devs around ffdshow) work doesn't get that respected as you've worked hard to release a stable beta release of ffdshow...

[Liisachan]

Personally, I don't use codec packs either, but codec packs are not all bad if you use it right. ffdshow is a codec pack too, in a way. The good point of CCCP would be, with it you can play video on relatively slow computers. So it could be recommended for general users who may or may not have fast CPU.

However, if you have fast CPU and prefer quality over speed that's a whole different story.

For instance, ffdshow's high-quality RGB32 output or MPC's internal sub-renderer with no sub-pic buffering.

Originally, haruhiko's mt patch was for that very purpose--VMR9 Renderless RGB32; so... that codec pack is in a way inconsistent with ffdshow's philosophy. ffdshow is quality-oriented (as in vorbis decoder, changed into high-quality mode). Actually, tho, many users didn't know old ffdshow's default Vorbis decoder was problematic; even today, many users don't know their video is out of sync, audio being about 50ms (typically 1 video frame) too late because of encoder delay + lame tag, as the encoders use lame default without knowing what they are doing. Obviously I wouldn't listen to "recommendations" of such people.

CCCP is "people's pack" (or "poor men's" pack in a good sense); Fast VSFilter softsubs instead of MPC's too beautiful but too slow desktop resolution (reasonable for normal users). Fast YUV color space instead of software-side RGB (the quality is especially degraded for many of nVidia users who don't configure the driver correctly; not CCCP's fault, tho). As another note, last time I checked, the official Matroska pack from matroska.org was CCCP-based too. (They didn't include ffdshow's mp4 encoders as legal precautions)
So, altho I'm not sure if cccp is good or not (as I'm not a user), it's used relatively widely, and I believe it must be much better than Nimo (?) or something, I don't remember the exact name, but I mean old notorious codec packs.
From what I gathered many people recommend cccp too, tho just because many ppl recommend it doesn't mean I automatically agree with that.

[LoRd_MuldeR]

QueueUp20061223.patch (http://sourceforge.net/tracker/index.php?func=detail&aid=1621133&group_id=173941&atid=867362)

New version of queue. This patch was writen to improve the stability and compatibility issue. Ironically this patch is too large and needs more testing.

As a result, queue becomes effective with Zoom player and MPC + VMR9.

Another fix includes,
improved compatibility issue with BSPlayer.
Windows Media Player is excluded from queueing internally regardless of the settings.

VMR9 rengerless + RGB out + patched MPC : continue pressing right cursor key freezes. This issue is improved if queue is off. If queue is on, we have to wait for new builds.

My binary (http://downloads.sourceforge.net/ffdshow-tryout/ffdshow_rev706p_20061223_Q.exe) is available for testing.

ListEmptyIMediaSamples is a helper class of queue and does prefetch.
GetBuffer and Receive is now called from the same thread.
If Receive and GetBuffer is called from other threads, GetBuffer often returns error.
By cooperating with TffOutputQ, ListEmptyIMediaSamples buffers the IMediaSample as soon as it is released in TffOutputQ::ThreadProc.

Tested with MPC:
VMR7 works fine
VMR9 works fine
Haali Renderer completely freezes with Queue enabled, otherwise is does not
Overlay says "not supported"

[cc979]

i've recompiled gcc-4.1.2 with the strip option, @clsid files are smaller - check my sig for the file

i try to compile ffdshow - and every thing compiles ok - ffdshow.ax will crash when looking the filters
but i've found a solution it has to do with '-march=pentium-mmx -mtune=i686' in makefile.inc's

if i remove them, it does compile and function correctly on my athlon_x64, but shows on version page x86, sse

and in the .bat files it should be "%SystemRoot%\..\Program Files\NSIS\makensisw.exe" for people who have windows on a drive

cheers

[haruhiko_yamagata]

Tested with MPC:
VMR7 works fine
VMR9 works fine
Haali Renderer completely freezes with Queue enabled, otherwise is does not
Overlay says "not supported"
Thank you very much for testing. Haali's renderer does not work on my developing environment. I find a PC that Haali's renderer works and reproduced the problem.

//EDIT
Overlay often fail over old renderer. That's why the OSD says "not supported".

[foxyshadis]

Still have issues with video output freezing when I make on-the-fly adjustments to avisynth. (Did I ever report that? Only noticed recently.) While the video's either playing or paused. Seeking fixes it.

Queue works well in YV12 and not in YUY2 here, in VMR9 renderless YUV mixing mode, just to let you know. I got it to work once in Zoomplayer, too, but it wouldn't after that. ;_;

And pretty much all MPEG-4 and WMV based codecs are crashing, the last few revisions, but only in MPC. Grr, and I have yet to successfully compile MPC to debug (when attempting to debug the binary, it exits process before it can be attached properly).

[haruhiko_yamagata]

I got it to work once in Zoomplayer, too, but it wouldn't after that. ;_;
Thank you for report. Is it about ffdshow_rev706p*_20061223_Q.exe? Please let me know the detail.

[Px]

I tested
ffdshow_rev705_20061222_clsid.exe
ffdshow_rev705_20061222_clsid_icl9.exe
Still "Cannot start encoder (-100)" on MPEG4 codec. I try both Vdub/Vdubmod, 5 or 6 files with different codecs, divx, xvid, mpeg2, on all of them "Cannot start encoder (-100)" error appeared :(
Today I made some additional test on huffyuv compressed 720x576 video, MPEG4 encoder works normally. Could it be, that ffdshow can't start encoding because another instance of vfw codec must be used for decoding?

[Px]

I compiled ffdshow with wvc1 support in wmv9lib.
Please enable vc1 from codec list.
Where I can download vc1 samples for testing?

[Px]

And one another thing (or maybe I missed something?):
I recently upgraded my cpu to dualcore, and found that when I play 24 Mbps H.264 sample in MPC, ffdshow works as if it multithreaded, first core load near 60%, and second - 40%. When I play same file in bsplayer, cores load 80-100/20...

[clsid]

Today I made some additional test on huffyuv compressed 720x576 video, MPEG4 encoder works normally. Could it be, that ffdshow can't start encoding because another instance of vfw codec must be used for decoding?
I tried disabling everything in ffdshow VFW decoder and it still has the same problems. Even with uncompressed input.

[foxyshadis]

Thank you for report. Is it about ffdshow_rev706p*_20061223_Q.exe? Please let me know the detail.

Yes, my apologies, it's your test build. Queue seems to be working normally in Zoom Player again now (in YUY2 VMR9), I think it might have stopped working because I installed clsid's build, oops. :o Btw, if it's important: ATI X1400 Mobility, Catalyst 6.10. XP SP2.

Btw, can the queue limit be raised, if there's enough free memory? Once in a while it'll hit a scene or the system will get busy and it shrinks to zero.

I still have to test certain scenes that had jerky panning before even with 9 frames in queue.

Where I can download vc1 samples for testing?

http://www1.mplayerhq.hu/MPlayer/samples/V-codecs/WVC1/

Lots of video game sites are using it for trailers now, too.

And one another thing (or maybe I missed something?):
I recently upgraded my cpu to dualcore, and found that when I play 24 Mbps H.264 sample in MPC, ffdshow works as if it multithreaded, first core load near 60%, and second - 40%. When I play same file in bsplayer, cores load 80-100/20...

Decoding is not yet multithreaded. (Except mpeg 1/2.) The queue only works if you have enough spare cpu to decode ahead a few frames. (Turn on ffdshow's OSD and select Queued Samples to find out if that's the case.) Once the pictures leave the decoder they can be multithread through the rest of the pipeline, to some degree, as well as fully threaded software resize.

Instead of watching task manager's graphs, it's often better to watch the cpu% in the process list, where you don't have to eyeball total utilization. If you really need graphs, process explorer has a single per-process graph that I think you'd like. It's hard to push mine above 50%, but I did it by resizing to 1280x1024. :p

[Px]

http://www1.mplayerhq.hu/MPlayer/samples/V-codecs/WVC1/

Lots of video game sites are using it for trailers now, too.
Thanks :)

Decoding is not yet multithreaded. (Except mpeg 1/2.) The queue only works if you have enough spare cpu to decode ahead a few frames. (Turn on ffdshow's OSD and select Queued Samples to find out if that's the case.) Once the pictures leave the decoder they can be multithread through the rest of the pipeline, to some degree, as well as fully threaded software resize.
Ok, I see, the Queued Samples most time is 9-10, in worth cases - 3-4

Instead of watching task manager's graphs, it's often better to watch the cpu% in the process list, where you don't have to eyeball total utilization.
I don't watch task manager, I use RMClock for watching and Rivatuner for logging core usage separately :)

[haruhiko_yamagata]

celtic_druid has compiled a new build for MPC.
Both the cursor key problem (http://forum.doom9.org/showthread.php?p=919534#post919534) and DTS problem are fixed.

mplayerc.rev611-3.2kxp.7z (http://tirnanog.fate.jp/mirror/Media%20Player%20Classic/mplayerc.rev611-3.2kxp.7z)

Thank you very much, celtic_druid.

[foxyshadis]

A couple interesting results, with r706p and the new MPC 611-3. The video hang when editing avisynth (or output) during playback is still there, but now it only lasts a second before resetting and playing normally. Also YUY2 works for queue now. Oh wow, that's awesome. (RGB also works, naturally.)

[fastplayer]

Not a biggie but... XP visual styles are not working with the latest MPC build.

[foxyshadis]

They work here. You might want to try searching your system for mplayerc.* and delete whatever comes up; a stray manifest might be breaking something. Or it might be something entirely different, not sure.

[celtic_druid]

The manifest file is embedded, so yeah it should work.

[haruhiko_yamagata]

Yes, my apologies, it's your test build. Queue seems to be working normally in Zoom Player again now (in YUY2 VMR9), I think it might have stopped working because I installed clsid's build, oops. :o Btw, if it's important: ATI X1400 Mobility, Catalyst 6.10. XP SP2.

Btw, can the queue limit be raised, if there's enough free memory? Once in a while it'll hit a scene or the system will get busy and it shrinks to zero.

I still have to test certain scenes that had jerky panning before even with 9 frames in queue.

I need a hard ware compatiblity list:(.
The limit of queue count can be raised, though I doubt the efficacy. Registry option for testing may help.

[fastplayer]

They work here. You might want to try searching your system for mplayerc.* and delete whatever comes up; a stray manifest might be breaking something. Or it might be something entirely different, not sure.

The manifest file is embedded, so yeah it should work.

@foxyshadis:
There's no hidden manifest file in my MPC directory or anywhere else. Just the EXE and INI.
@celtic_druid:
I remember that this happened with one of your previous MPC builds. I think the manifest file wasn't properly embedded as a resource or something...
Update: manifest is not embedded. Couldn't find it with ResHacker but I added it from your previous MPC build. See link below.

Edit: Fixed it by adding a manifest file.
Edit2: MPC build rev611-3.2 by celtic_druid + embedded manifest for XP visual styles support:
http://d.turboupload.com/d/1361725/mplayerc.rar.html

[leeperry]

call me stupid but I got a pretty annoying problem with the latest versions of ffdshow :(

in the older "official" releases, it was possible to fine-tune the aspect ratio with the keyboard arrows in order to reach 1.67/1.78/1.85 and 2.35

with the newer versions it doesn't work anymore, so you have to move the mouse like crazy to more or less reach the ratio you want........and you can only reach 1.66/1.77/1.84-1.86 and 2.36

is there a recent release that lets you change it with the keyboard arrows ?!!?!?

thanks ;)

[celtic_druid]

Yeah, MSVC sometimes leaves out embedding it. You can add it with MSVC (copy paste from previous exe).

[fastplayer]

Yeah, MSVC sometimes leaves out embedding it. You can add it with MSVC (copy paste from previous exe).
I actually copied the %windir%\system32\cdplayer.exe.manifest file into the MPC folder, renamed it to mplayerc.exe.manifest and voilà it works again :)

[leeperry]

any chance getting a reply pls ?
noone cares to get perfect aspect ratio but me ? :(

[haruhiko_yamagata]

any chance getting a reply pls ?
noone cares to get perfect aspect ratio but me ? :(
Please wait. I'm looking into it.

[leeperry]

awesome, thanks a lot :)

actually I'd be really great to be able to choose between :
1.0
1.22
1.33
1.47
1.666666
1.777777
1.85
2.35

and then being able to input it manually

[haruhiko_yamagata]

awesome, thanks a lot :)

actually I'd be really great to be able to choose between :
1.0
1.22
1.33
1.47
1.666666
1.777777
1.85
2.35

and then being able to input it manually
Just fixed at rev 708. Restored from the code just before rev 1427 of the original project. Direct text input is not supported though.

[mpioner]

celtic_druid
time to do MPC-tryout :D

[leeperry]

Just fixed at rev 708. Restored from the code just before rev 1427 of the original project. Direct text input is not supported though.

better talk to god than to his saints I guess, thank you so much :D

so I can use the keyboard arrows to finetune ?
any chance of implementing buttons with just 1.33/1.66666/1.77777/1.85 and 2.35 ?
or making the incremental change a lot slower when the right button is pushed ?
coz sometimes I just got my wireless mouse handy, no keyboard :D

where could I get a SSE2(GCC?) compiled version ?

thanks again and merry xmas :D