New ffdshow build (?)

[videomixer9]

Just placing the bin directory into the windows directory is a dumb idea, subdirs are not automatically in the systems PATH variable. Also a file is registered to the location it was when registering, you cannot register a filter and then just move it to some random other location, windows won't find it anymore where it was and decides that it's dead.

Don't build libavcodec and libmplayer with VS. It doesn't use handoptimized MMX code then which is made specially for GCC. It will be way slower this way.

Easiest is to just run ffdshow.nsi with NSIS installer (just right-clicking the nsi file and select compile installer should be fine usually) and make a proper installer for the compiled files, or just keep them where they are and let VS register the .ax file and don't move anything.

Honestly you got a deep lack of knowledge about the OS and other things as it seems ... better fix that first :P There isn't any real gain in compiling ffdshow yourself anyways if you're mostly clueless :O

And yes MSVC 2005 sometimes crashing on exiting after compiling the .ax file.

[Farhad]

Hi,
I was wondering if someone could point me to documentation
on ffdshow that would explain how the code is structured.
Thanks,

Farhad

[Farhad]

The problem was solved by proper installation using NSIS (as suggested by videomixer9). Thanks to your insightful advise, videomixer9. Any suggestion on a proper documentation of ffdshow?
Regards,

Farhad

Just placing the bin directory into the windows directory is a dumb idea, subdirs are not automatically in the systems PATH variable. Also a file is registered to the location it was when registering, you cannot register a filter and then just move it to some random other location, windows won't find it anymore where it was and decides that it's dead.

Don't build libavcodec and libmplayer with VS. It doesn't use handoptimized MMX code then which is made specially for GCC. It will be way slower this way.

Easiest is to just run ffdshow.nsi with NSIS installer (just right-clicking the nsi file and select compile installer should be fine usually) and make a proper installer for the compiled files, or just keep them where they are and let VS register the .ax file and don't move anything.

Honestly you got a deep lack of knowledge about the OS and other things as it seems ... better fix that first :P There isn't any real gain in compiling ffdshow yourself anyways if you're mostly clueless :O

And yes MSVC 2005 sometimes crashing on exiting after compiling the .ax file.

[zilexa]

Can anyone confirm version http://kurosu.free.fr/ffdshow-20060424-13H04-k8.exe
is stable/no bugs reported so far? Trying to figure out fast/good version for a new PC with socket AM2 amd64 3200+ cpu.

[Farhad]

Has anybody tried this?
Thanks,

Farhad

[CruNcher]

http://gda.utp.edu.co/~ceniza/GCC-4.1.1/ <- is it down ?

[therealjoeblow]

Hoping one (or some) of the dev's read this forum from time to time...

It appears that it's impossible to setup the Keys & remote triggers without 2 activation keys (default are ctrl and alt). Would it be possible to allow this? IE, no activation keys, just a single key trigger?

I want to use my ATI remote wonder's 7, 8, 9, and 0 keys to send commands to toggle sharpening, post processing, subtitles, etc, but without getting into the complexities of installing and programming girder, I can't send the activation trigger keys to ffdshow with a single keypad press on the remote. It would be much simpler if the activation keys could just be disabled so that ffdshow just watches for simple single key presses.

And while we're at it, there's no trigger to toggle the DScaler filter - could that be added too please?

Many thanks,

[KikeG]

I don't know if this is already known, but there is a small bug in my Feb-26-2006 build (and I think in other builds too).

The bug is in the displayed coded frame size information in the OSD info when playing mpeg-4 files. The size of I/P/B frames is not in sync with the current frame being shown. I mean, when showing a B-frame, the coded frame size shown is usually much bigger than the one of the previous I or P-frame, so I guess the coded frame size is shown in the wrong order.

[foxyshadis]

I noted this a while back and haven't really had time to look in and investigate. The first problem is the B-frame delay, though; the first size is correct, then x sizes are skipped where x is the delay (1 for b-frames, 2 for b-pyramid) and the rest are all shifted by that much. This affects all containers except avi, bizarrely! You'd expect the opposite, but it looks like someone 'fixed' it for avi at one point by breaking other containers.

It also tends to repeats frame #s wrong a lot with mkv, then make big jumps to cover the gap. Strange.

It used to show B/P in coding, not display order, but I'm glad to see that's apparently been fixed now.

It's a lot easier to analyze OSD by saving it into a file. Quite handy, that.

[KikeG]

Well, it does show wrong sizes in mpeg4 AVIs, I don't know about other containers. OSD saved to a file is wrong too.

I have checked it and I/P/B frame type and quantizer displayed are right, but their frame sizes are wrong.

[LoRd_MuldeR]

I found a bug with ffdshow (latest build from Videomixer9) when playing MEPG4 files and using xvid decoder. The AVI has fourcc "DIVX" and plays fine in both MPlayer and VLC. However in MPC with ffdshow I got a black screen - audio only. Then I changed decoder for "Generic MPEG4" from xivd to libavcodec and when I tried again it worked. Back to xvid and same problem as before. Even tried latest xvidcore.dll from Celtic Druid, but didn't help.

[haruhiko_yamagata]

fixed crash on huffyuv playback.
a bug of multithreading of swscaler.
Refuse loading from blacklist :
Re-installing ffdshow.ax sometimes fails because ffdshow.ax cannot be deleted.
Explorer.exe loads ffdshow.ax and never releases.
That causes annoying error on re-install that one have to log off.
With this patch, ffdshow.ax avoids to be loaded by returning false on DllMain
if the caller is included in BlackList("Don't use ffdshow in:").
aWarpSharp
changed default setting of "Chroma mode"
For better single CPU/multithreading (test).
This time, THREAD_PRIORITY_BELOW_NORMAL for streaming thread, only when it write to V-RAM(Single CPU only).OSD item : Queued samples (joke).

Fixed resource leak : Thanks, hartlerl
http://sourceforge.net/tracker/index.php?func=detail&aid=1386965&group_id=53761&atid=471489.
[Patch] (http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491)
ffdshow_multithread_060625.patch is PATCH to PATCH.
To rev2546 + ...060517.patch + ...060601.patch + ...060604.patch
Some of the changes are not related to multithreading, so the patch is supposed to be separated. But it's too complicated, I chosed to merge :D .

[videomixer9]

wow, sunday morning, how dirty. Well whatever, new build incl. the patches available here (http://ffdshow.da.cx).

[LoRd_MuldeR]

whatever, new build incl. the patches available here (http://ffdshow.da.cx).

nope :scared:

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.

[videomixer9]

that is so typical, you upload one second one wrong file and idiot strikes and loads it ... try again :P Tried some .htaccess setting and it was obviously not allowed on the host ...

[SeeMoreDigital]

As an IE7 beta user I get: -Sorry your browser doesn't properly support XHTML. Please change to a browser with proper XHTML support like Firefox or Opera.

[foxyshadis]

You could try disabling javascript. :p

There still seems to be some problems with huffyuv, it used to play this non-mod16 (676x444) video just fine, now it silently crashes every time. Opens fine in vdub with ffvfw doing the decoding though! (Recompressing it without resize/crop crashes though.)

[videomixer9]

IE7 is an utter piece of shit, it may support some things but it's utterly broken for CSS. Opera and Firefox render correctly, so see what IE7 outputs:
http://xs302.xs.to/xs302/06250/ie7crap.png.xs.jpg (http://xs.to/xs.php?h=xs302&d=06250&f=ie7crap.png)
http://xs302.xs.to/xs302/06250/ie7crap2.png.xs.jpg (http://xs.to/xs.php?h=xs302&d=06250&f=ie7crap2.png)

Neither does it obey the proper padding and margin settings, nor does it clip the thing correctly, it instead takes the width of the first table cell the style applied to and clips text and style differently, so even if you set a width the text is clipped still to the table cell width while the rest isn't. Same effect on the top, clipping is taken from table cell, but the content isn't even anymore in the cell really, padding and margin are applied, but the nice thing is, the left margin get intended by the <ul> tag but the top margin applies incorrectly from the <ul> on level higher, different behaviour on both margins, just awesome. It is amazing IE7 even does this CSS hover popups anyways but the current way it totally unusable and not near any standards.

If you want to see anything correctly get a browser that sends also handles application/xhtml+xml properly, IE doesn't, so it has to stay outside for more than enough other reasons too.

The check is serverside scripted, if your browser doesn't send an Accept: application/xhtml+xml it gets this message, there is not a single line of javascript on the website except for the google analytics code.

[LoRd_MuldeR]

@Videmomixer:
Why you make "no-sse" builds now?

[Egh]

wow, sunday morning, how dirty. Well whatever, new build incl. the patches available here (http://ffdshow.da.cx).

BTW, what happened with WMV3/9 option in the installer? It dissappeared several builds ago :P

[videomixer9]

Too many people seemed to think it's something else than the old crappy support for WMV3 that is in ffdshow since ages. So I removed it again, people may hack registry again if they want it :P

Basically some of the later SSE builds would prolly work on non-SSE too and libavcodec and libmplayer don't use the GCC switches that generate this code anyways, so it's generic as ICL doesn't generate code that needs it really to be there.

[haruhiko_yamagata]

You could try disabling javascript. :p

There still seems to be some problems with huffyuv, it used to play this non-mod16 (676x444) video just fine, now it silently crashes every time. Opens fine in vdub with ffvfw doing the decoding though! (Recompressing it without resize/crop crashes though.)
Thank you for report.
Was prior version OK?
In which module does it crash?
If it is libmplayer.dll, I still have known theoretical bugs that I don't have proper sample to make it crash.

[LoRd_MuldeR]

If you set everything correctly during the installation, you won't have to edit anything ^^

[foxyshadis]

http://neuron2.net/misc/1deint.avi

This is the huffyuv file. It was playable around early may, when I first downloaded it. I don't know if it's just some recent optimization or compiler options.

Mulder: Because ICL takes twice as long to compile with sse on? =p (Maybe that's changed though.)

Edit: Ack, I downloaded the wrong ffdshow; the current one plays this file fine. False alarm!

[Egh]

@ haruhiko_yamagata :

Thanks for your participation in ffdshow development btw!

Is it possible to request patch? I've been asking Milan to do that for ages, but still nothing was done.

In the software resizer (which i nearly always use) you need to specify BOTH dimensions (i.e. if i resize to 1024, i need to take DAR into account myself, and put 576 for 16:9 or 768 for 4:3). Since ffdshow itself has access to DAR value, I think it's relatively easy to let user enter only horizontal dimension and calculate vertical target resolution based on the DAR value received. Current behaviour (when user is forced to specify both values) seems to be rather stupid imo.

I think that can be just several lines of code which need to be changed :P

[LoRd_MuldeR]

Mulder: Because ICL takes twice as long to compile with sse on? =p (Maybe that's changed though.)

But the build would be a lot "faster" with SSE enabled, eh?

[videomixer9]

ICL actually always takes quite long to compile and honestly for decoding libav is the thing which matters and for resize etc. libmplayer. The rest doesn't seem to profit that much from SSE and SSE2, but maybe someone can show me an example with some major difference in speed.

[haruhiko_yamagata]

http://neuron2.net/misc/1deint.avi

This is the huffyuv file. It was playable around early may, when I first downloaded it. I don't know if it's just some recent optimization or compiler options.

Mulder: Because ICL takes twice as long to compile with sse on? =p (Maybe that's changed though.)

Edit: Ack, I downloaded the wrong ffdshow; the current one plays this file fine. False alarm!
Thank you. My own build played fine.
Videomixer9, I forgot to write "please be sure to re-compile libmplayer.dll".

[videomixer9]

One of my versions before made use of auto-vectorization of GCC which worked fine except that it broke huffyuv, however I had it replaced with a non-vectorized version then, seems the final GCC 4.1.1 has it still unusable too.

[haruhiko_yamagata]

I'm sorry, I downloaded ffdshow-20060621-rev2546.exe carelessly.

ffdshow-20060625-rev2546-icl91-nosse.exe works fine.

[videomixer9]

lots of people downloading wrong things today o_O

[_xxl]

http://www.mplayerhq.hu/design7/news.html
MPEG-1/2/4 and H.264 decoder speedup
skiploopfilter/skipidct/skipframe decoder options for very fast H.264 decoding

[videomixer9]

and i bet it'll look like shit ... speedup I'd call some better optimized code doing everything and not skipping half of the decoding work. Otherwise that release version bases it changes on the last pre7 version which was ancient.

[Liisachan]

ffdshow-20060625-rev2546-icl91-nosse1.exe
"Queue output samples" and Pause don't mix well yet.

- Let's say the video is paused at Frame #1000; then MPC gets Frame #1009 or so, which is off by 9.
- When the video is restarted, it's restarted from #1001 or so, correctly.

VMR9 Renderless. RGB32.

[haruhiko_yamagata]

ffdshow-20060625-rev2546-icl91-nosse1.exe
"Queue output samples" and Pause don't mix well yet.

- Let's say the video is paused at Frame #1000; then MPC gets Frame #1009 or so, which is off by 9.
- When the video is restarted, it's restarted from #1001 or so, correctly.

VMR9 Renderless. RGB32.
It is very difficult.
I'm trying very hard to fix it but still clueless.
I wrote very incomplete patch for MPC, but I wonder if I should post it. It just works, but fails to repaint. VMR9's StretchRect returns error for unknown reason, and blackout. The patch trys not to call Present when StretchRect failed(trys not to show incompleat backbuffer). Not radical at all.

I think the bug(unknown error of StrechRect) may not be ffdshow's nor MPC's. It may be rather VMR9 or deveice driver's. Intel 82865G fails, but some other VGA card works.

[Liisachan]

@haruhiko_yamaga
Well, I guess it's not a big deal. I mean, I can live with it. I just figured I'd let you know thinking it might be a problem easy to fix.
Thanks you very much for your efforts.

[haruhiko_yamagata]

@ haruhiko_yamagata :

Thanks for your participation in ffdshow development btw!

Is it possible to request patch? I've been asking Milan to do that for ages, but still nothing was done.

In the software resizer (which i nearly always use) you need to specify BOTH dimensions (i.e. if i resize to 1024, i need to take DAR into account myself, and put 576 for 16:9 or 768 for 4:3). Since ffdshow itself has access to DAR value, I think it's relatively easy to let user enter only horizontal dimension and calculate vertical target resolution based on the DAR value received. Current behaviour (when user is forced to specify both values) seems to be rather stupid imo.

I think that can be just several lines of code which need to be changed :P
Entering your screen size to "Specify size / New size" and selecting "Keep original aspect ratio" will do nealy what you say as far as you use fullscreen mode, though it may be heavy.
Anyway it's a good idea, I'll try when I have time (perhaps not so easy, it needs a lot of re-engineering).

[Egh]

Entering your screen size to "Specify size / New size" and selecting "Keep original aspect ratio" will do nealy what you say as far as you use fullscreen mode, though it may be heavy.


Well soon this idea will be a year old :P At least counting from the moment I first presented it to Milan.

And your method is not good. It's known for ages, but it leaves THE notorious black bars above and below the actual video frame, which is stupid and CPU waste imo. Turn OSD on, for instance, and see where the text is displayed. Thus in such mode instead of operating only with 1280*720 surface, ffdshow deals with full 1280*1024 (if that's fullscreen resolution used, which is btw standard one for all 19" TFT). And then due to that subs are displayed at a wrong position :P This was known for ages, I think ffdshow sf trackers have prooly 3-4 separate entries related to that (including one mine ^^) over the last year, but Milan seem never was bovvered enough to change that behaviour :P

And of course once I originally made up this idea, others suggested some improvement to it. One which I like was to let the ffdshow automatically get the current fullscreen resolution and resize to that horizontally (if an option is enabled, of course) and take into account DAR, of course.

[foxyshadis]

I don't believe it's a waste of cpu at all - it's a bug in output module, not in the resize itself, as far as I can tell. When I first started using resizing and noticed it happening, I made tests (like turning on heavy noise) and nothing shows in the black area, so it isn't affecting downstream filters, just adding some extra memory copies on the output. (Unless you use VMR9 renderless or Haali's, then it would waste a little gpu in the pixel shaders.) I suspect the output module because I think that's where OSD is rendered.

Screwing up subtitles definitely would be annoying, though.

[Dark Eiri]

Hey guys!
I was wondering... there is a SSE3 build of ffdshow?
In SSE3 capable CPUs, the performance would be how better (in %) with a SSE3 optimized build?

Thanks in advance ^^

[Liisachan]

http://kurosu.free.fr/ffdshow-20060424-13H04-sse3.exe

[foxyshadis]

Depends. Is it an Athlon/Opteron? Virtually no difference over SSE even with full optimization, because SSE2/3 is internally broken into SSE in AMD architectures. On Intel there could be a performance enhancement in certain decoders and filters, but it'd be incredibly dependant on what decoders & filters you use, and most likely employing kassandro to perform the optimization (even ICL isn't a tenth as amazing as he is).

If you just want to compare old SSE vs SSE3 ICL builds of vm9's, I think I found a 1-2% difference for avc video with resizing.

[Dark Eiri]

Depends. Is it an Athlon/Opteron? Virtually no difference over SSE even with full optimization, because SSE2/3 is internally broken into SSE in AMD architectures. On Intel there could be a performance enhancement in certain decoders and filters, but it'd be incredibly dependant on what decoders & filters you use, and most likely employing kassandro to perform the optimization (even ICL isn't a tenth as amazing as he is).

If you just want to compare old SSE vs SSE3 ICL builds of vm9's, I think I found a 1-2% difference for avc video with resizing.

Thank you for all your explanations. You are really helpful ^^
And Yeah, it is an AMD Athlon64. :(

Liisachan: Thank you for the link! I'll try this build anyway. :D

[_xxl]

http://rapidshare.de/files/24249564/ffdshow-20060627.exe.html

[Livesms]

http://rapidshare.de/files/24249564/ffdshow-20060627.exe.html


When somebody will fix bug with PP for H264
Set by default "when decoding H.264 video" and not "when decoding H.264 video and decoder deblocking off".

There is no sense to disable PP at all, but this washed-out picture when "when decoding H.264 video and decoder deblocking off" :sly:

[foxyshadis]

Set it to that and remove the option. Leave it in the registry if anyone needs it but remove the damn useless and misleading option if no one's going to implement detection of when inloop is disabled in the source. </rant>

[Egh]

if no one's going to implement detection of when inloop is disabled in the source. </rant>

Hmm... Does ffdshow fail to detect that inloop is disabled in sauce or what? Seems a bit strange...

[videomixer9]

I brilliantly hate postprocessing in ffdshow so much that if I didn't break anything postprocessing should be disabled when installing per default (milans script has it enabled together with the sound normalization), dunno which idiotic idea drove milan to make this crap on per default. I don't care about the other things as imo anyone who enables postprocessing must be insane anyways :P

[trodas]

Postprocessing MUST be OFF by default. No-one want to see blurry picture when it should not be that blurry. Blocky? Well, that is the source/bitrate/codec problem and compensating it by blurring everything SUXX :(

Futhermore I have strange problems/crashes when trying to play mp4 video with FFD show May 26 2006... :(

It won't even install on my W2k SP2, however when I install older version and just replace the files - all working. Except MP4 files, damn :(


PS. install of the latest version there from the RapidShare works well, however still crash:

BSplayer v1.41.832, Unhandled exception at EIP: 77FCB892
If you click 'Close' application will be terminated.
Please report this info to the author with description what were you doing.
If you have internet connection, it's recommended to send error report, this will help us solve problems faster.
Access violation at address 77FCB892 in module 'ntdll.dll'. Write of address 0000A904
EAccessViolation
Call stack: 00000000,77FCB892,0040482B

[haruhiko_yamagata]

Hello, trodas. Is the crash related to postprocessing?