New ffdshow build (?) [Archive] - Page 10

clsid

6th September 2006, 20:06

from wikipedia
Differences between MMX and SSE2

SSE2 supports almost every integer operation that MMX supports. Therefore, it is possible to convert all existing MMX code to SSE2 equivalent. Since an XMM register are two times as long as an MMX register, loop counters and memory access may need to be changed to accommodate this.

Although one SSE2 instruction can operate on twice as much data as an MMX instruction, performance might not increase significantly. Two major reasons are: accessing SSE2 data in memory not aligned to a 16-byte boundary will incur significant penalty, and the throughput of SSE2 instructions in most x86 implementations is usually smaller than MMX instructions. Intel has recently addresses the first problem by adding an instruction in SSE3 to reduce the overhead of accessing unaligned data, and the last problem by widening the execution engine in their Core microarchitecture.

videomixer9

6th September 2006, 20:13

VC1 decoding still doesn't work for me for some reason and the new VMnc codec also won't run after I added, wonder what I oversaw ... tried various combinations so far already but both won't decode no matter what ...

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev146.exe?download

_xxl

6th September 2006, 20:54

AMD-XP:
http://s21.simpleupload.de/fa18a296e/ffdshow-tryouts-rev145-amd-xp.exe.html
AMD-K8
http://s21.simpleupload.de/fdb8eddb3/ffdshow-tryouts-rev145-k8.exe.html
INTEL-P4
http://s21.simpleupload.de/ffeef6e7a/ffdshow-tryouts-rev145-p4.exe.html

videomixer9

7th September 2006, 01:21

Lol bad day today, fucked up too often with that VMnc thing ... works now but it always crashes ... oh well, need to check if ffmpeg itself crashes too or if it's introduced through porting. Was so busy searching for the error that I oversaw the most obvious. It's early stage so I guess some errors are still in there and it hasn't hit mplayer either for now.

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev148.exe?download

Amour

7th September 2006, 10:50

... works now but it always crashes ...
crash ≠ working

By the way, is there a way to rotate or flip the image when watching (decoding) a video with ffdshow?

Amour

7th September 2006, 11:04

clsid and videomixer9, can you please fill the Release Date field when adding files to SourceForge (I mean on this page (http://sourceforge.net/project/showfiles.php?group_id=173941))? Like that, the files would be listed according to release date, and the package date wouldn't be August 3, 2006 anymore. Or you could keep filenames with the same logic name, so it becomes easy to spot the latest release.

Thanks a lot!

cc979

7th September 2006, 11:15

tested using elephant dream_hd xvid/ac3 (8mbs stream mostly)
using 07-07-06 hali splitter

videomixer9
ffdshow-tryouts-rev148.exe
null: User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 81.4, dfps: 79.0
vmr9: User: 8s, kernel: 0s, total: 9s, real: 10s, fps: 68.4, dfps: 60.8
ovrl: User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 77.2, dfps: 74.6

drevil_xxl
ffdshow-tryouts-rev145-amd-xp.exe
null: User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 79.3, dfps: 76.5
vmr9: User: 8s, kernel: 0s, total: 9s, real: 10s, fps: 67.1, dfps: 59.5
ovrl: User: 8s, kernel: 0s, total: 8s, real: 9s, fps: 74.9, dfps: 72.2
...
ffdshow-tryouts-rev145-k8.exe
null: User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 78.5, dfps: 75.7
vmr9: User: 8s, kernel: 1s, total: 9s, real: 10s, fps: 66.2, dfps: 59.9
ovrl: User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 75.3, dfps: 72.8
...
ffdshow-tryouts-rev145-p4.exe
null: User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 79.7, dfps: 76.8
vmr9: User: 8s, kernel: 1s, total: 9s, real: 10s, fps: 70.2, dfps: 59.9
ovrl: User: 8s, kernel: 0s, total: 8s, real: 9s, fps: 74.5, dfps: 72.7

@videomixer9 your rev148 looks a bit faster, what instruction set is it using?

@drevil_xxl and @clsid if you do a rev148 i'll check them too

:thanks: guys

cc979

7th September 2006, 11:42

Amour

7th September 2006, 12:02

1.FFdshow-Tryouts-20060901-rev122-sse2 crashes on P4
when decoding MPEG-2 using libmpeg2?
2.Libavcodec works fine?
3.FFdshow-Tryouts-20060901-rev122-sse & mmx are working fine?
Don't know, but, here are my tests:

ffdshow-tryouts-rev100-sse2 = working
ffdshow-tryouts-rev111-sse2 = crash
ffdshow-tryouts-rev118-sse2 = crash
ffdshow-tryouts-rev122-sse2 = crash
ffdshow-tryouts-rev138-sse2 = crash
ffdshow-tryouts-rev145-p4 = crash

I made a thread about it on http://ffdshow-tryout.sourceforge.net/phpBB2/

videomixer9

7th September 2006, 12:12

@videomixer9: using your rev148 virtualdudmod stated it could'nt find msvcr80.dll so i copied the one from ffdshow directory into system32 and vdm shows this error

http://img100.imageshack.us/img100/9916/clipboard1og8.png (http://imageshack.us)

try copying it to where the vdub plugin is located only, there should be no copy of it in the windows system32 dir, also note even if you have to also copy the manifest file!

If you want the runtime working everywhere please install vcredist_x86.exe instead of copying the file, the redist doesn't copy the file to the system dir and also comes with the manifests.

I tested the plugin and it works fine as always :P

@videomixer9 your rev148 looks a bit faster, what instruction set is it using?

none really, it's a plain generic build with no single instructionset enforced. It should technically also work on CPUs without MMX. Maybe you should also do some tests with filters enabled. Then my build might be slower ...

Amour

7th September 2006, 12:21

more tests:

ffdshow-tryouts-rev122-sse = crash
ffdshow-tryouts-rev122-mmx = crash

drevil_xxl, I found where is the issue! If you uncheck Enable output queuing during the installation, it will work fine. So you might consider to disable this option by default, or fix the issue.

_xxl

7th September 2006, 12:42

drevil_xxl, I found where is the issue! If you uncheck Enable output queuing during the installation, it will work fine. So you might consider to disable this option by default, or fix the issue.
Output queuing is NOT working and it causes ffdshow to crash?

Amour

7th September 2006, 12:53

Ah, sorry, sorry...

Output queuing enabled + BSPlayer = crash
Output queuing enabled + Windows Media Player = working
Output queuing disabled + BSPlayer = working
Output queuing disabled + Windows Media Player = working

So the problem is a combination of Output queuing and BSPlayer.

Same problem with VM9 releases. clsid is ok because it doesn't have Output queuing by default.

videomixer9

7th September 2006, 13:02

BSPlayer is crap anyways, the free variant is just a spyware throwing cashmachine and the pro version just crap only without the spyware. I guess everyone knows what bs means too ;O No sense working around bsplayer, guess just adding it to the blacklist for output queuing is adequate.

_xxl

7th September 2006, 13:20

Stable version should work with BSPlayer.Adding it to the blacklist is NOT a good idea.

haruhiko_yamagata

7th September 2006, 13:38

I think blacklist is not a good idea. Bsplayer, Crystal player and WMP...

Btw, what is working fine with queue?
MPC mostly works, except for (VMR9 renderless+RGB32+specific video card+pause) = blackout problem.

List working application and check by default
Use queue only in "..."
looks better.

What should be included in the list? I would like to add MPC first.

haruhiko_yamagata

7th September 2006, 14:00

haruhiko_yamagata

7th September 2006, 14:13

none really, it's a plain generic build with no single instructionset enforced. It should technically also work on CPUs without MMX. Maybe you should also do some tests with filters enabled. Then my build might be slower ...
Which filter would be affected?
As for MSVC8, the compiler make autodetecting code, doesn't it? If I'm not wrong, MSVC8(for .ax) generic build is not slow on new CPUs and works on old CPUs (maybe wrong).

videomixer9

7th September 2006, 14:30

MSVC8 doesn't use any autodetection, per default it generates generic running code for any CPU (of course it can detect if certain instruction sets are available and integrate special assembly for that, but it won't generate code making full use of the instruction sets). There are many variants to compile into machine code and every compiler is differently good on this task. Also some add extra checks or produce check routines etc. MSVC is generally producing stable code that is still faster than most of GCCs often unstable code. Intel Compiler uses many advanced compiling technologies to the fullest even without auto vectorization it reaches decently faster speeds that way. However C/C++ is quite slow compared to real well hand written assembler code (you can see this when compiling the plain C code of libavcodec with the compilers). As a human you still know the best which things you can leave out that a compiler would generate like it does for everything even if it may not be really neccessary. The list of optimization techniques is nowadays quite endless, and even more endless the variations, e.g. simple things like loop unrolling, if improperly done it makes things slow (partly that may also fault of the coder and his code), if properly used it speeds things up (with libavcodec and GCC it's usually slower). Same goes for many things. MSVC is a compromise of stable and fast code. ICL is the speedmachine and GCC is mostly portable but not fast. ICLs vectorization that tries converting things automatically to SSE1-SSE4 doesn't know if the vectorizations it does make sense, so it vectorizes quite useless loops and blocks too which can lead to crashes or speed things down as SSE units get stuffed with things to handle while they could just use the regular instruction units.

So as said often, the decoding speed is thanks to hand written code and the rest of the code is better executed the regular way except for some filters maybe. But maybe someone can test that to see how it compares. I'd think though that full GCC builds end up worse than MSVC and ICL builds will prolly be another tick faster, on some filters maybe special SSE/SSE2/SSE3/SSE4 builds may be faster. I released a Core2 Duo version before that is still quite much up2date with the decoding stuff that is usually tested and filters didn't change much either. I'm still wonder if someone could compare the Core2Duo version with a generic build.

As for the filters I'm usually trying filter speed differences with the rather odd combination of xsharpen + Gradual Denoise + Denoise3D. So far ICL generic managed to be 10 fps ahead of MSVC generic there.

haruhiko_yamagata

7th September 2006, 15:01

So MCVC8 creates code for SSE and use it by autodetect, but not so fast. Thank you very much.

videomixer9

7th September 2006, 15:10

haruhiko_yamagata

7th September 2006, 15:16

Bug fix(? alpha test) : Raw video :
When Divx5=disabled and Raw video=all supported, the Divx5 video flips. The player is MPC.
Please see if it does not have any side effects.

videomixer9

7th September 2006, 15:23

Does that even have to really do sth. with ffdshow and not more like funny avi decompressor kicking in before or so? Not even asking which tard uses that kind of configuration ... :O

haruhiko_yamagata

7th September 2006, 15:28

it only does generates SSE code if /arch:SSE is set. The .ax. file will crash on non-SSE CPUs then once a SSE instruction will be actually used. Only few things will be replaced with SSE instructions when this function is used though.
In that case, ffdshow.ax should be autodetected rather than libavcodec. I'm talking about installer.

videomixer9

7th September 2006, 15:31

Only the Innosetup has an autodetection routine to deploy it with several special compiles ... that installer is done by drevil_xxl and clsid, I have no need for such detections as special versions are useless anyways imo. All important things are hand optimized.

Is this another of those brought to us by 2ch tardness questions you're asking cause the cowards over there aren't lazy enough to try ask themselves? They seem to be totally keen on this optimizations shit even if it's worthless. Just tell them there's a magic detection component build in that automagically makes use of anything available :P

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev150.exe?download

Mc Onyx

7th September 2006, 17:01

I was just wondering what happened with the "special" H.264 GPU accelerated ffdshow that was mentioned few pages back?

Egh

7th September 2006, 18:31

I was just wondering what happened with the "special" H.264 GPU accelerated ffdshow that was mentioned few pages back?

looks like that project (along with x264gpu from same author) was born dead :) Not that I actually expected anything soon, especially that devaster mentioned 3rd September for the release :P

Might be that the dev just seriously underestimated the difficulties coding that (take a look at Haali renderer for instance).

_xxl

7th September 2006, 18:36

In that case, ffdshow.ax should be autodetected rather than libavcodec. I'm talking about installer.
FFdshow.ax is autodetected.All files are.
GCC 4.0.3 compiler can compile SSE and SSE2 versions of ffdshow.ax.

clsid

7th September 2006, 18:49

clsid

7th September 2006, 18:55

Lol bad day today, fucked up too often with that VMnc thing ... works now but it always crashes ... oh well, need to check if ffmpeg itself crashes too or if it's introduced through porting. Was so busy searching for the error that I oversaw the most obvious. It's early stage so I guess some errors are still in there and it hasn't hit mplayer either for now.
I tried a nightly build of VLC yesterday and it could play both VC-1 and VMnc samples that I got from the mplayer sample site. VLC also uses code based on ffmpeg, right? So in theory it should work.

videomixer9

7th September 2006, 18:58

yeah ... now just need to find out why it doesn't work in ffdshow so far.

clsid

7th September 2006, 20:04

Sample file with FourCC "WMVA" crashes. I also got VC-1 sample files with FourCC "WMVP" and "WVP2". MPC reports no filters found for those. It also doesn't seem to want to use ffdshow for VMnc.

bond

7th September 2006, 20:35

Sample file with FourCC "WMVA" crashes. I also got VC-1 sample files with FourCC "WMVP" and "WVP2". MPC reports no filters found for those. It also doesn't seem to want to use ffdshow for VMnc."WMVA", "WMVP" and "WVP2" are not vc-1 compliant. therefore ffdshow of course doesnt handle them

_xxl

7th September 2006, 22:42

rev 152 crashes:
http://i3.tinypic.com/2mwfcsx.jpg
rev 151 works.

affter333

7th September 2006, 23:41

Hi,
What's the last version of ffdshow that
supports Win98se ? The newest version (20060828)
doesn't seem to support it anymore..

Thanks for your help..

clsid

7th September 2006, 23:54

My builds support Windows 98.

The info&debug page looks a bit messy since the addition of SSE3/SSE4. Also MMX2 should be named MMXext. MMX2 is incorrect and confusing.

Anima123

8th September 2006, 04:49

I have an old P3 core which does not support MMXext while ffdshow defaultly set MMXext optimization on. Is it a bug with cpu detection routine?

clsid

8th September 2006, 15:10

As far as I know MMXext is a subset of SSE. All P3 support SSE.

videomixer9

8th September 2006, 15:47

ffdshow-tryouts revision 154r2
Download: here (http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev154r2.exe?download)

compilers: ICL 9.1.030 and GCC 3.4.5
changes: igor1st audio normalization tweak

I scraped the new instruction set things for now. Still didn't find the reason for VC-1 and VMnc not properly working, would be great if someone could check those things for stuff I oversaw really :O edit: 5% faster :P

Eragon4ever

8th September 2006, 15:49

You mean r154 not 127?

Egh

8th September 2006, 15:52

You mean r154 not 127?
prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev154.exe?download

announced 127, link leads to 154 :)

videomixer9

8th September 2006, 15:56

ups copy & paste devil striked

LoRd_MuldeR

8th September 2006, 15:59

Found a bug: The "perspective correction" filter makes ffdshow crash when interpolation-mode is set to "cubic", while "linear" and "none" seems to work. Tested with ffdshow-tryouts-rev150-AMD-XP-K8 (drevil) and ffdshow-tryouts-rev154.exe (vm9). My CPU is Athlon-XP.

videomixer9

8th September 2006, 16:09

hm works just fine on my athlon xp

LoRd_MuldeR

8th September 2006, 16:30

hm works just fine on my athlon xp
hmmm, that's strange. I tested with MPC. But that filter isn't very important anyways...

foxyshadis

8th September 2006, 20:28

Probably has something to do with the source being fed into it. Dimensions probably.

Egh

8th September 2006, 21:10

Probably has something to do with the source being fed into it. Dimensions probably.

Exactly. Did quick testing with ffdshow resizer put prior the perspective correction in "Cubic interpolation" mode.

ffdshow crashes reproducibly here on Athlon XP if horizontal size (vertical was autodefined from 16:9 sauce AR) hits 768. In my tests, even 766 works, but just 2 pixels increment crashes ffdshow.

videomixer9

8th September 2006, 23:03

yeah it indeed does with resizer on

affter333

9th September 2006, 01:05

Hi:
There seems to be a huge memory leak When using
kernel deinterlacer on NTSC Mpeg2 (720x480i).
the free physical memory is dropping fast. (-2M/sec)
After playing for about 2 min, free memory down to zero.
But it does release all the used mem when closing player.
(Win98se,wmp 6.4 & 9.0)

My observation is that when there's more motion, it
consume more memory.

It doesn't seem to have the issue when playing
with PAL mpeg2 (720x576i) (or with other deinterlacers)

I'm using ffdshow-tryouts-rev150-INTEL-P4.exe
, don't know about other builds..

Thanks..

_xxl

9th September 2006, 08:19

I'm using ffdshow-tryouts-rev150-INTEL-P4.exe, don't know about other builds..
Thanks..
Please test other builds!
videomixer9 and clsid ffdshow builds.

cc979

9th September 2006, 15:44

tested using elephant dream_hd xvid/ac3 (8mbs stream mostly)
using 07-07-06 hali splitter

drevil_xxl
ffdshow-tryouts-rev155-AMD-XP-K8.exe
null: User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 79.6, dfps: 78.7
vmr9: User: 8s, kernel: 1s, total: 9s, real: 10s, fps: 68.3, dfps: 59.8
ovrl: User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 76.8, dfps: 73.0

just playing some vids everything working as it should, only one problem using vmr9 output on mpc, i've not used the ffdshow brightness controls for a while but when i do now, i've got weird colour only way it works properly is to use either nv21 output on ffdshow or use ordinary overlay output - have i missed something using nvidia driver 91.45 so maybe its them will try early driver see if that fixes it.

or if anybody have another way to fix - let me know thanks

cc979

9th September 2006, 17:35

i've found i get crash playing svq3 files using rev155 build

_xxl

9th September 2006, 18:00

i've found i get crash playing svq3 files using rev155 build
Using rev150 you get same crash?
just playing some vids everything working as it should, only one problem using vmr9output on mpc, i've not used the ffdshow brightness controls for a while but when i do now, i've got weird colour only way it works properly is to use either nv21 output on ffdshow or use ordinary overlay output - have i missed something using nvidia driver 91.45 so maybe its them will try early driver see if that fixes it.
or if anybody have another way to fix - let me know thanks
Works with 91.31 nvidia driver.

videomixer9

9th September 2006, 18:53

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev155.exe?download

i place a bet on this rev155 generic that it is faster than the AMD version ;P

Rash

9th September 2006, 20:40

Isn't NV21 reserved for DXVA? Sorry if that sounded stupid.

cc979

9th September 2006, 22:25

@drevil_xxl rev150 crashes too with same svq3 file
rev150 libavcodec.dll offset 000bbe3a crash shown

videomixer9 rev155 crashes on the svq3 file too
...

tested using elephant dream_hd xvid/ac3 (8mbs stream mostly)
using 07-07-06 hali splitter

videomixer9
ffdshow-tryouts-rev155.exe
null: User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 81.6, dfps: 80.7
vmr9: User: 7s, kernel: 1s, total: 9s, real: 10s, fps: 72.0, dfps: 61.2
User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 78.2, dfps: 75.0

ps. ask if you want anymore crash details

the file in question is here i think
http://files.filefront.com/startreklegacy+om+060706+qtzip/;5127512;/fileinfo.html

guys could you add a little builder tag on the end off yours builds so its easier to kept track of what builds are what, cheers - keep the good work

cc979

9th September 2006, 23:47

after further testing found that window media players it ok using ffdshow rev150 .. maybe a bug in mpc

sorry guys i should have tested this earlier

haruhiko_yamagata

10th September 2006, 03:15

@drevil_xxl rev150 crashes too with same svq3 file
rev150 libavcodec.dll offset 000bbe3a crash shown

videomixer9 rev155 crashes on the svq3 file too
...

ffdshow may be responsible for it, but mainly it's a problem with splitters, I think.
http://forum.doom9.org/showthread.php?p=869291#post869291

videomixer9

10th September 2006, 13:25

ffdshow-tryouts revision 162
Download: here (http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev162.exe?download)

compilers: ICL 9.1.030 and GCC 3.4.5
changes: VP5 & VP6 decoder added

Liisachan

10th September 2006, 14:24

VP5 and 6 don't play so far via ffdshow above, however, now VP62, both in AVI and FLV (ie FLV4) plays by celtic_druid's ffplay.

videomixer9

10th September 2006, 14:56

any link to some VP6 flvs?

Liisachan

10th September 2006, 15:18

glider_flv4.flv (http://minkymomo.info/~meroko_deathnote/tmp/codec_test/glider/)

yangxi

11th September 2006, 11:21

i have the AMD X2 4200+ cpu, which built is best encode speed (avi -> mpg)?

foxyshadis

11th September 2006, 11:43

They'd all give the same speed, the encoding library isn't dependant on compiler optimization.

haruhiko_yamagata

11th September 2006, 15:43

A feature freeze is a good idea. Imho there are already too many formats in ffdshow that are incomplete. First make it stable and then add new features one at a time.

How about this version numbering scheme:
stable: 1.0.0.revision beta
dev: 1.0.0.revision alpha

I agree that a feature freeze is a good idea.

Btw, why beta for stable build?
I suggest
stable: 1.0.0.revision
dev: 1.0.0.revision alpha

Thank you for the list of known problems.

_xxl

11th September 2006, 15:48

A list of known/reported problems:
* VC-1 does not work
* VMnc does not work
* VP5 does not work
* VP62 does not work
* The "perspective correction" filter makes ffdshow crash when interpolation-mode is set to "cubic". Happens only if horizontal video size is 768 or greater.
* SVQ3 crashes (splitter related?)
* kernel deinterlacer memory leak on NTSC Mpeg2 (720x480i) video (uncomfirmed)
* Output queue enabled + BSplayer = crash
* Output queue enabled + VMR9 renderless + RGB32 + specific video card + pause = blackout problem
* FFdshow is crashing when using subtitles stereoscopic
I probably missed a few.
* WMP 10,11 crash
* WME crash

haruhiko_yamagata

11th September 2006, 16:09

* WMP 10,11 crash

When does WMP crash?

thuan

11th September 2006, 17:05

I have a weird problem with some icl9 builds, any build with ffdshow.ax that is about 5MB not the one with around 3MB ax like the 162 one from vm9 or the gcc one compiled by drevil will crash (not exactly it slows my com down to a state that unusable, have to kill player process) when I use denoise3dhq and seek a lot with 5 secs jump time in one direction or sometimes randomly when I seek with denoise3dhq (haven't checked with normal denoise3d). Will happen with all avi files randomly (use MS splitter), IIRC haven't got this with any file that is watched with Haali splitter (I don't check avi here just mkv, ogm, and mp4). I guess it has something to do with compiler optimization. WinXPSP2 T-bred Sempron CPU no SSE2 or above, use MPC rev.611.

_xxl

11th September 2006, 18:20

#define IDFF_MOVIE_AUDX 20
#define IDFF_MOVIE_MAX 20
conflicted with IDFF_AUDX ?

CoRoNe

11th September 2006, 20:25

* SVQ3 crashes (splitter related?)
In what kind of circumstances?

clsid

11th September 2006, 20:50

In what kind of circumstances?See a few pages back in this thread.

I myself don't have any issues with SVQ3.

Jeremy Duncan

12th September 2006, 08:13

I think having a official release with links to daily builds would be nice.
The daily builds can have change logs and anybody with a problem can use a daily built with a fix.

The main designers of FFdshow should colaborate on the 1 release version and then work individually on their daily builds.

The main release version can have it's own webpage with a nice page layout, like Mozilla has.

Peuj

12th September 2006, 11:37

See a few pages back in this thread.

I myself don't have any issues with SVQ3.

Tested with MPC rev611 (celtic_druid's build) with QuickTime set as DirectShow
FFDShow: ffdshow_rev2546-127_20060902.exe

ftp://mplayerhq.hu/MPlayer/samples/V-codecs/SVQ3/finalfantasy_cc.mov
Sound ok but the image is not good (just grey with some colors and artifacts)

ftp://mplayerhq.hu/MPlayer/samples/V-codecs/SVQ3/gt4_tgs2k3.mov
MPC freezed

ftp://mplayerhq.hu/MPlayer/samples/V-codecs/helldeskmaskcable.mov
Sound ok but the image is not good (just grey with some colors and artifacts)

ftp://mplayerhq.hu/MPlayer/samples/V-codecs/rev_theatre_0x3839_640_dl.mov
all ok but there is a line green and red at the bottom of the image.

ftp://mplayerhq.hu/MPlayer/samples/V-codecs/starfox2.mov
Sound ok but the image is not good (just grey with some colors and artifacts)

ftp://mplayerhq.hu/MPlayer/samples/V-codecs/Vertical400kbit.sorenson3.mov
MPC freezed

ftp://mplayerhq.hu/MPlayer/samples/V-codecs/SVQ1/spec-tampax-red-(frames_loss).mov
MPC freezed

All the mov files are well played with QuickTime or MPC and QuickTime codec

hope it helps.

Amour

12th September 2006, 12:46

BTW: Why ffdshow-tryout and not just continue in the original ffdshow sf project?
They said it was because the original admin (Milan) was nowhere to be found, impossible to contact him for a very very very long time (2 years?).

haruhiko_yamagata

12th September 2006, 13:15

They said it was because the original admin (Milan) was nowhere to be found, impossible to contact him for a very very very long time (2 years?).
It was two months. Now it is 3.5 months. If it was 2 years, We'd have taken over the original project. Two months was too short to take over. I still hope milan comes back someday.

clsid

12th September 2006, 13:23

ftp://mplayerhq.hu/MPlayer/samples/V-codecs/SVQ3/finalfantasy_cc.mov
Sound ok but the image is not good (just grey with some colors and artifacts)Confirmed. If I use Haali splitter instead of Gabest, then it even crashes.

I can confirm the problems with the other samples as well. Exvept for the freezes.

Perhaps SVQ3 should be labeled as "incomplete".

Peuj

12th September 2006, 15:14

I can confirm the problems with the other samples as well. Exvept for the freezes.

You don't have the freezes and it works ? because on a clean machine with just MPC and ffdshow I get these messages from MPC:

Vertical400kbit.sorenson3.mov::Apple Sound Media Handler

Media Type 0:
--------------------------
Audio: 0x0000 44100Hz mono

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Audio {73647561-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {34616D69-0000-0010-8000-00AA00389B71}
formattype: FORMAT_WaveFormatEx {05589F81-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 70

WAVEFORMATEX:
wFormatTag: 0x0000
nChannels: 1
nSamplesPerSec: 44100
nAvgBytesPerSec: 0
nBlockAlign: 34
wBitsPerSample: 16
cbSize: 52 (extra bytes)

pbFormat:
0000: 00 00 01 00 44 ac 00 00 00 00 00 00 22 00 10 00 ....D¬......"...
0010: 34 00|00 00 00 34 69 6d 61 34 00 00 00 00 00 00 4....4ima4......
0020: 00 01 00 01 00 00 00 00 00 00 00 01 00 10 00 00 ................
0030: 00 00 ac 44 00 00 00 00 00 40 00 00 00 22 00 00 ..¬D.....@..."..
0040: 00 22 00 00 00 02 ."....

==> No sound but good image

gt4_tgs2k3.mov::Apple Sound Media Handler

Media Type 0:
--------------------------
Audio: 0x0000 44100Hz stereo

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Audio {73647561-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {34616D69-0000-0010-8000-00AA00389B71}
formattype: FORMAT_WaveFormatEx {05589F81-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 70

WAVEFORMATEX:
wFormatTag: 0x0000
nChannels: 2
nSamplesPerSec: 44100
nAvgBytesPerSec: 0
nBlockAlign: 68
wBitsPerSample: 16
cbSize: 52 (extra bytes)

pbFormat:
0000: 00 00 02 00 44 ac 00 00 00 00 00 00 44 00 10 00 ....D¬......D...
0010: 34 00|00 00 00 34 69 6d 61 34 00 00 00 00 00 00 4....4ima4......
0020: 00 01 00 01 00 00 00 00 00 00 00 02 00 10 00 00 ................
0030: 00 00 ac 44 00 00 00 00 00 40 00 00 00 22 00 00 ..¬D.....@..."..
0040: 00 44 00 00 00 02 .D....

==> No sound and bad image same as the others mov (just grey with some colors and artifacts)

clsid

12th September 2006, 15:27

Enable IMA ADPCM in ffdshow audio decoder.

Peuj

12th September 2006, 15:41

Enable IMA ADPCM in ffdshow audio decoder.

Oohh thanks, I miss this one. :thanks:

Anyway for me the image is not good on ftp://mplayerhq.hu/MPlayer/samples/V-codecs/SVQ3/gt4_tgs2k3.mov

Egh

12th September 2006, 16:03

It was two months. Now it is 3.5 months. If it was 2 years, We'd have taken over the original project. Two months was too short to take over. I still hope milan comes back someday.

Revision 2546
Author: milan_cutka
Date: Fri May 5 08:33:42 2006 UTC (4 months, 1 week ago)

Time is moving fast :P

clsid

12th September 2006, 16:40

Here are some screenshots of SVQ3 files that give bad picture:

http://img18.imagevenue.com/loc451/th_75648_gt4_tgs2k3.mov_122_451lo.jpg (http://img18.imagevenue.com/img.php?image=75648_gt4_tgs2k3.mov_122_451lo.jpg)http://img141.imagevenue.com/loc564/th_75648_finalfantasy_cc.mov_122_564lo.jpg (http://img141.imagevenue.com/img.php?image=75648_finalfantasy_cc.mov_122_564lo.jpg)http://img121.imagevenue.com/loc500/th_75649_helldeskmaskcable.mov_122_500lo.jpg (http://img121.imagevenue.com/img.php?image=75649_helldeskmaskcable.mov_122_500lo.jpg)http://img147.imagevenue.com/loc576/th_75650_rev_theatre_0x3839_640_dl.mov_122_576lo.jpg (http://img147.imagevenue.com/img.php?image=75650_rev_theatre_0x3839_640_dl.mov_122_576lo.jpg)

Amour

12th September 2006, 16:51

Weird bug.
I'm using BSPlayer + ffdshow build from the 6th September (could be rev142 from clsid, not 100% sure).

I watch a movie (xvid), I pause it, I switch Windows user, I switch back, and now the movie is upside-down! The video is working fine, I can play, stop, fast-forward, pause,... but everything is upside-down. I had to restart the player to have it back to normal.

clsid

12th September 2006, 16:52

clsid

12th September 2006, 16:58

I watch a movie (xvid), I pause it, I switch Windows user, I switch back, and now the movie is upside-down! The video is working fine, I can play, stop, fast-forward, pause,... but everything is upside-down. I had to restart the player to have it back to normal.Could be some weird Windows bug. What happens if you switch back and forth twice?

haruhiko_yamagata

12th September 2006, 17:24

Weird bug.
I'm using BSPlayer + ffdshow build from the 6th September (could be rev145 from drevil_xxl or rev142 from clsid, not sure).

I watch a movie (xvid), I pause it, I switch Windows user, I switch back, and now the movie is upside-down! The video is working fine, I can play, stop, fast-forward, pause,... but everything is upside-down. I had to restart the player to have it back to normal.
Revision 150 - Directory Listing
Modified Thu Sep 7 13:15:17 2006 UTC (5 days, 2 hours ago) by h_yamagata
Bug fix(? alpha test) : Raw video :
When Divx5=disabled and Raw video=all supported, the Divx5 video flips. The player is MPC.
Please see if it does not have any side effects.
Does anything change before and after rev 150? Please test.

cc979

12th September 2006, 20:29

Confirmed. If I use Haali splitter instead of Gabest, then it even crashes.

I can confirm the problems with the other samples as well. Exvept for the freezes.

Perhaps SVQ3 should be labeled as "incomplete".

that was my problem - cheers

foxyshadis

12th September 2006, 20:47

Btw guys, this is the new thread where thoughts on versioning, stable releases, future plans, etc should be discussed:
http://forum.doom9.org/showthread.php?t=115869

NoX1911

13th September 2006, 02:02

PostProcessing doesn't work with generic build on AMD K7. Or is it just me? :)
What about a changelog in the installer? Maybe at least the last 5 builds?

Egh

13th September 2006, 03:38

Aha.

I found out what was the problem with "decoding page" being disabled.

The page is disabled whenever ffdshow receives uncompressed input (in my case YV12 straight from CoreAVC). Interstingly enough, h264 quality related controls are still enabled on the same page, but they don't contain any values (they can be entered though).

nibbles

13th September 2006, 05:32

Somebody may find this interesting. Those CLSIDs in Peuj's output are reserved by Microsoft
to specify FourCC codes. He listed these:

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Audio {73647561-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {34616D69-0000-0010-8000-00AA00389B71}

and it also had this in the hex output:

pbFormat:
0000: 00 00 01 00 44 ac 00 00 00 00 00 00 22 00 10 00 ....D¬......"...
0010: 34 00|00 00 00 34 69 6d 61 34 00 00 00 00 00 00 4....4ima4......

According to these documents at MSDN, (http://windowssdk.msdn.microsoft.com/en-us/library/ms783788.aspx) any CLSID of the form
XXXXXXXX-0000-0010-8000-00AA00389B71
is reserved, and the Xs are 4 hex numbers backwards because
the registry is little endian, that spell out the FourCC code when
converted back to ASCII and reversed.

Soooo.... following this ASCII chart, (http://everything2.com/index.pl?node_id=159986)

This CLSID 34616D69-0000-0010-8000-00AA00389B71
has hex digits 34 61 6D 69
which spells 4 a m i
so the FourCC is: ima4
I came across this while trying to determine whether HuffYUV should
have its ClassGUID specified in its inf or just use CLASS=Media, a
nasty little puzzle still for me.

haruhiko_yamagata

13th September 2006, 16:04

Revision 173
"Use queue only in:" "mplayerc.exe;" by default.
Revision 171
msvcr80.dll and msvcr71.dll installer.

If vcredist_x86 is not packed or the installation of vcredist_x86 failed,
and if MSVCR8 is defined,
the installer try to install msvcr80.dll as private assembly.

Installation of private assembly have version check, reference count controls, etc.
The version of VC80.CRT is checked before executing vcredist_x86.exe.

MSVCR8 is defined by default.
Please read the header of ffdshow.nsi carefully.
Good bye runtime library errors!?
Rev 173 should contribute to stability.

haruhiko_yamagata

13th September 2006, 16:28

The change to resource.h causes weird thing, if MSVC's intermediate files aren't cleaned. Please clean and rebuild.

DSP8000

13th September 2006, 16:32

Good work :)

Any other changes?
I just finished reading/browsing the SVN and it seems to me that again ffdshow it is just getting more and more features.

Now, how about first fixing/removing the bugs that have been reported by clsid and others.IMHO it is better to have one stable build to refer to than 100's revisions updated daily:) , and confusing the "average Joe" which one should I get.
It's been a long time since we had a stable (nominated) build.

Anyways, great to see that the development of ffdshow is in full speed ahead:)

DSP8000

Egh

13th September 2006, 17:11

....

Another minor issue with ffdshow (just like the previous one reported by me, it's more amusing than actually serious).

If there's an error in avisynth script in ffdshow, the error message is displayed on top of video. That's ok, but interestingly enough, even if I uncheck the whole avisynth page in ffdshow, the error message still remains.

Amour

13th September 2006, 18:21

Does anything change before and after rev 150? Please test.
Sorry, I'm not able to reproduce the flip bug again (any ffdshow revision). When I switched the Windows user, I wasn't on the computer anymore to see what was done by the other user.

Amour

13th September 2006, 19:09

Today's tests (with an xvid file):

[drevil_xxl] rev 155 (default settings = Output queueing ON)
BSPlayer: crash
WMP: ok
MPC: using the seekbar, the video will freeze a few seconds (but not the sound)

[VM9] rev162 (default settings = Output queueing ON)
BSPlayer: crash
WMP: ok
MPC: using the seekbar, the video will freeze a few seconds (but not the sound)

[clsid] rev164 (default settings = Output queueing OFF)
BSPlayer: ok
WMP: ok
MPC: ok

[h-yamagata] rev173 (default settings = Output queueing ON)
BSPlayer: ok
WMP: ok
MPC: using the seekbar, the video will freeze a few seconds (but not the sound)

We only have problems with this Output queueing feature: is it really usefull and user friendly? Instead of applying haruhiko_yamagata's rev173 MPC-only-by-default solution, I advice to use clsid's feature-disabled-by-default solution.

KoD

13th September 2006, 19:22

I still wonder how can something that was not designed to be multithreaded from the beginning can be made to be multithreading-safe ? I mean, how feasible is this ?

LoRd_MuldeR

13th September 2006, 19:26

I still wonder how can something that was not designed to be multithreaded from the beginning can be made to be multithreaded ? I mean, how feasible is this ?

They made the filter-chain multi-threaded, so each filter can run in it's own thread. And the resizer also has it's own thread. Furthermore some of the decoders used by ffdshow are multi-threaded now too. Except some bugs, that always can slip in, there should be nothing that should prevent multi-threaded ffdshow from working properly...

clsid

13th September 2006, 19:28

Updated list of known issues:

1) VC-1, VMnc, VP5 and VP6 do not work. ffdshow isn't even placed in the DirectShow graph.
2) The "perspective correction" filter makes ffdshow crash when interpolation-mode is set to "cubic". Happens only if horizontal video size is 768 or greater.
3) SVQ3 crashes when used in combination with Haali's MP4 splitter. Possibly not a ffdshow issue. (reported by Peuj)
4) Some SVQ3 files play with artifacts / color shifts / totally messed up picture. (reported by Peuj)
5) Kernel deinterlacer memory leak on NTSC Mpeg2 (720x480i) video. (unconfirmed)
6) Output queue enabled + BSplayer = crash. May happen on some other players as well. Possibly related to specific renderers used in those players? Current workaround: queue is only used in MPC.
7) Output queue enabled + VMR9 renderless + RGB32 + specific video cards + pause = blackout problem
8) ffdshow crashes when enabling stereoscopic option on subtitles page. (reported by drevil_xxl)
9) If ffdshow gets uncompressed input, then the decoding options page is disabled. However the H.264 quality controls are not disabled. (reported by Egh)
10) If there's an error in avisynth script in ffdshow, the error message is displayed on top of video. That's ok, but interestingly enough, even if I uncheck the whole avisynth page in ffdshow, the error message still remains. (reported by Egh)
11) Video may freeze for a few seconds in MPC when seeking if queue is enabled. (reported by Amour)

Of this list only 1, 6, 7, 9 and 11 are specific to the ffdshow tryouts. The rest was (probably) already present in revision 2543 of ffdshow.

Amour

13th September 2006, 21:11

Current workaround: queue is only used in MPC.
As I said earlier today, queueing is causing problems even with MPC: when using the seekbar to change the position, the image will often freeze for a few seconds, but not the sound. And that's very annoying.

What is the meaning, the purpose of queueing? I do not understand this functionality/feature.

KoD

13th September 2006, 23:23

The problem in multithreading is when all those threads have to communicate with one another.

clsid

14th September 2006, 00:52

As I said earlier today, queueing is causing problems even with MPC: when using the seekbar to change the position, the image will often freeze for a few seconds, but not the sound. And that's very annoying.

What is the meaning, the purpose of queueing? I do not understand this functionality/feature.
What the queue does is queue video frames before they get send to the renderer. It also executes the video renderer on worker thread. The queue can help decrease the number of frame drops when running at near 100% cpu usage. It is only useful on multicore cpus and perhaps also on P4s with hyperthreading. Haruhiko can give you a better explanation.

Just disable the option if it gives you troubles. I consider it both an expert and experimental option that should be disabled by default.

14th September 2006, 01:03

Revision 150 - Directory Listing
Modified Thu Sep 7 13:15:17 2006 UTC (5 days, 2 hours ago) by h_yamagata
Bug fix(? alpha test) : Raw video :
When Divx5=disabled and Raw video=all supported, the Divx5 video flips. The player is MPC.
Please see if it does not have any side effects.
Does anything change before and after rev 150? Please test.
That is old bug, it appears even if Raw video is also disabled. Reason - when system don't find needed DSH-codec, it search for suitable VfW-codec, and if find it - use him through DSH/VfW layer. Disable support for DivX5 in ffdshow VfW codec, and bug will dissapear....

Jeremy Duncan

14th September 2006, 02:14

Queue output samples, when checked, freezes Media Player Classic when you use the seek bar.

I'm using the August 21, 2006 version of FFdshow, and Media Player Classic 6.4.9.0 and Dscaler 5008 with Reclock.

deadfones

14th September 2006, 04:15

Today's tests (with an xvid file):

<snip>

[clsid] rev164 (default settings = Output queueing OFF)
BSPlayer: ok
WMP: ok
MPC: ok

<snip>

We only have problems with this Output queueing feature: is it really usefull and user friendly? Instead of applying haruhiko_yamagata's rev173 MPC-only-by-default solution, I advice to use clsid's feature-disabled-by-default solution.

clsid build 164 is good. Instant seeks with the seekbar in MPC and where I used to get video stalling using the seekbar, at least now it waits a little, stutters, and catches up.

Without output queuing, I get frame drops (more like play a second then stutter) on divx3, divx5, and xvid, at least. This is with a P4c 3.0ghz and ddr400. My CPU isn't maxed out, it's actually at about 15%, but the frames still drop. It may or may not have something to do with my multiple display configuration (running latest nvidia drivers).

Edit: 15% with HT, so about 30% actually.

DSP8000

14th September 2006, 06:08

clsid build 164 is good. Instant seeks with the seekbar in MPC and where I used to get video stalling using the seekbar, at least now it waits a little, stutters, and catches up.

I can confirm this, build 164 works good.
However, build 181 clsid instantly crashes MPC and ffdshow video decoder config.Even after reinstall & reset settings.I think Output queueing is causing this.

haruhiko_yamagata

14th September 2006, 11:00

We only have problems with this Output queueing feature: is it really usefull and user friendly? Instead of applying haruhiko_yamagata's rev173 MPC-only-by-default solution, I advice to use clsid's feature-disabled-by-default solution.
Don't forget ffdshow is a free software. Be polite.

It's a bug of MPC, not queue's. Even old ffdshow without queue the symptom is here, though the frequency is lower.

Simply uncheck MPC's internal source filter "AVI" and everything goes fine.

clsid

14th September 2006, 11:21

haruhiko_yamagata

14th September 2006, 11:34

I don't have any seeking problems at all when the queue is turned on. Tried with both the internal AVI splitter on and off in MPC (rev 611).

Perhaps the issue appears on multicore or hyperthreading cpus only?
It's reproducible on sigle CPU, too.
The video will freeze a few seconds. It's not a crash nor hang up. I know it's time stamp issue, I'll try to work around the bug when I have time.

haruhiko_yamagata

14th September 2006, 13:42

I can confirm this, build 164 works good.
However, build 181 clsid instantly crashes MPC and ffdshow video decoder config.Even after reinstall & reset settings.I think Output queueing is causing this.
It's not reproducible for me. Why do you think queue is the culplit?

haruhiko_yamagata

14th September 2006, 13:59

Amour

14th September 2006, 14:17

We only have problems with this Output queueing feature: is it really usefull and user friendly? Instead of applying haruhiko_yamagata's rev173 MPC-only-by-default solution, I advice to use clsid's feature-disabled-by-default solution.Don't forget ffdshow is a free software. Be polite.
Sorry.

Was giving an advice, reporting a problem, didn't mean to hurt you.

Amour

14th September 2006, 14:29

I would like to update the French translation of ffdshow (some phrases are displayed in English). Where/What/How should I do?

haruhiko_yamagata

14th September 2006, 14:36

I would like to update the French translation of ffdshow (some phrases are displayed in English). Where/What/How should I do?
Create a patch and post it here (http://sourceforge.net/tracker/?group_id=173941&atid=867362).

KoD

14th September 2006, 16:09

This might be or not related to some audio issues when resuming playback after pausing on WinXpSP2: KB 920872 (http://support.microsoft.com/?kbid=920872).

n3w813

14th September 2006, 18:37

On these 2 ffdshow versions.....(and maybe on other new builds, haven't tried them all yet)

H-Yamagata's
ffdshow-20060913-rev173-Q.exe

CLSID's
ffdshow_rev181_20060913_clsid.exe

When you enable 'Automatic Preset Loading' in the Image Settings menu, and exit, you will get an exception error when you try to start the ffdshow video configuration program again.

To disable auto preset, I go in the registry and change the value for...
HKCU\Software\GNU\ffdshow\autoPresets from 1 to 0
then ffdshow configuration utility will open correctly.

Can somebody else verify this?

clsid

14th September 2006, 20:12

Confirmed.

_xxl

14th September 2006, 21:09

http://minkymomo.info/~meroko_deathnote/tmp/codec_test/glider/glider_vp6.2.0.10.avi
please test!

_xxl

14th September 2006, 22:41

shae

15th September 2006, 00:07

Btw guys, this is the new thread where thoughts on versioning, stable releases, future plans, etc should be discussed:
http://forum.doom9.org/showthread.php?t=115869
foxyshadis! The next thing, you might suggest having a dedicated sub-forum! :) (Does anyone really think it's NOT better? Do the admins object?)

Updated list of known issues:Why not use the SF bug tracker? Much more organized, and maybe easier, though I'm not a fan of the SF structure in general.

---

BTW, how come ffdshow doesn't have a dynamic range compessor? It's very much needed for AC3 and the likes, but also for stereo in cases this was converted from AC3 without adjustments.

KoD

15th September 2006, 00:18

BTW, how come ffdshow doesn't have a dynamic range compessor? It's very much needed for AC3 and the likes, but also for stereo in cases this was converted from AC3 without adjustments.
What do you think Normalize does ?

And you can always enable drc (better than how normalize does its thing) on AC3 and DTS streams since they're meant to work with drc anyway. (it's on the codecs page when you select either ac3 or dts)

foxyshadis

15th September 2006, 00:51

Normalize and DRC solve totally different problems, so neither can substitute for the other. (Though they should be used together.) DRC is very helpful for AAC/MP3 as well, but you have to use a winamp2 filter for it, and those make ffdshow very unstable. There's nothing special about AC3/DTS concerning DRC, other than having in-stream values, just that their decoders include the capability. (The in-stream values tend to suck if the encoding was done cheaply anyway.)

shae

15th September 2006, 05:21

What do you think Normalize does ?Normalizes? :) I.e., maximizes peaks while keeping the wave proportions. That's not very helpful in most cases.

And you can always enable drc
It's on, but doesn't appear to do much (for that reason or another?). The sound shifts from whisper silent parts to unbearable loudness, so I'm constantly playing with the volume.

What's needed is something configurable.

Jeremy Duncan

15th September 2006, 08:05

Such a complicated setting with one line report. What am I supposed to do?

I'm using Media Player Classic 6.4.9.0
FFdshow August 21, 2006 found at afterdawn.com
I'm using Dscaler 5008 audio and video decoder, and reclock in Media Player Classic External Filters.

Dscaler is using YV12
FFdshow is inputting all supported, outputing YV12.
Blur & NR, Denoise3d: Luma: 0.00, Chroma: 2.00, Time: 4.00, HQ checked.
FFdshow is using Resize & Aspect:
Multiply by Resize 2.000, No aspect ratio correction, Lanczos, No luma sharpening, accurate rounding unchecked.
My monitor is set to a refresh rate of 75 Hz.
Reclock is doing a custom adaption set to 60.000 fps, the reclock light is green.
When Reclock is set to 25fps and the refresh rate is 75 Hz I get the same problem.
And lastly, when queue output samples is checked in FFdshow, when I use the seek bar in Media Player Classic, it freezes and I need to use the task manager to end the Media Player Classic process.

Using no setting in FFdshow but queue output samples. Input raw video all supported, output YV12. It still freezes when I use the seek bar in Media Player Classic.

The internal filter in Media Player Classic: "AVI" is unchecked.
The freezing problem is there with it checked or unchecked.

_xxl

15th September 2006, 08:13

clsid

15th September 2006, 14:10

rev173 contains a small change to the presets code. Haruhiko should be able to fix the bug.

In rev184 ffdshow finally gets used in the DirectShow graph for a VP6 file. However, the decoded video is b0rked with weird colors (mostly green) and artifacts. Same for VP5.
I haven't managed to play FLV files containing VP6 video yet. I even tried adding FLV4 FourCC which MPC uses to play such files.

haruhiko_yamagata

15th September 2006, 14:12

I'm using Media Player Classic 6.4.9.0
FFdshow August 21, 2006 found at afterdawn.com
I'm using Dscaler 5008 audio and video decoder, and reclock in Media Player Classic External Filters.

Dscaler is using YV12
FFdshow is inputting all supported, outputing YV12.
Blur & NR, Denoise3d: Luma: 0.00, Chroma: 2.00, Time: 4.00, HQ checked.
FFdshow is using Resize & Aspect:
Multiply by Resize 2.000, No aspect ratio correction, Lanczos, No luma sharpening, accurate rounding unchecked.
My monitor is set to a refresh rate of 75 Hz.
Reclock is doing a custom adaption set to 60.000 fps, the reclock light is green.
When Reclock is set to 25fps and the refresh rate is 75 Hz I get the same problem.
And lastly, when queue output samples is checked in FFdshow, when I use the seek bar in Media Player Classic, it freezes and I need to use the task manager to end the Media Player Classic process.

Using no setting in FFdshow but queue output samples. Input raw video all supported, output YV12. It still freezes when I use the seek bar in Media Player Classic.

The internal filter in Media Player Classic: "AVI" is unchecked.
The freezing problem is there with it checked or unchecked.
I found a bug related to queue and seek. The internal filter in Media Player Classic "AVI" does not call Run at the expected timing. It may not be good, but a bug seems to be in ffdshow side. The bug should not be too difficult to fix, though I'm not sure if the bug is related to your problem.

I have not tryed a reproduce test. Please keep wating here and when the bug is fixed, please test again and report.

haruhiko_yamagata

15th September 2006, 14:18

Recent builds including clsid's and videomixer9's genelic builds do not work on Pentium-MMX.

My "SSE" build ffdshow-20060730-Q.exe works. My "SSE" build simply use "official" makefile and vcproj. I label my build "SSE" just because they are not tested on non SSE CPUs.

So it's not a build problem nor installer's. Perhaps some code in ffdshow-tryouts. Could you confirm this?

igor1st

15th September 2006, 14:49

Recent builds including clsid's and videomixer9's genelic builds do not work on Pentium-MMX.

So it's not a build problem nor installer's. Perhaps some code in ffdshow-tryouts. Could you confirm this?
Revision 71:
"-O3 -march=i586" -> "-O2 -march=i686"

From manual:
i586 - Intel Pentium CPU with no MMX support.
i686 - Intel PentiumPro CPU.
pentium-mmx - Intel PentiumMMX CPU based on Pentium core with MMX instruction set support.

clsid

15th September 2006, 15:14

I will make a test build with "-march=pentium-mmx -mtune=pentium2".

test build (http://www.mytempdir.com/930756)

KoD

15th September 2006, 16:28

Egh

15th September 2006, 16:35

Normalization done during playback is quite bad because of this and very dependent on the audio material it has to work with. If the audio stream has a wide dynamic range already which varies a lot during playback, normalization is quite useless.

I still think that AC3Filter dynamic normalization is superior. I never use ffdshow's one, on my system I make AC3Filter accept decoded raw audio streams from ffdshow.

KoD

15th September 2006, 16:53

haruhiko_yamagata

15th September 2006, 16:53

I will make a test build with "-march=pentium-mmx -mtune=pentium2".

test build (http://www.mytempdir.com/930756)
Great. It works on Pentium-MMX.

cc979

15th September 2006, 18:05

just quick test

tested using elephant dream_hd xvid/ac3 (8mbs stream mostly)
using 07-07-06 hali splitter

clsid
ffdshow_rev187_20060915_clsid.exe
null: User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 76.4, dfps: 73.7
vmr9: User: 8s, kernel: 0s, total: 8s, real: 10s, fps: 77.8, dfps: 59.8
ovrl: User: 8s, kernel: 0s, total: 9s, real: 9s, fps: 72.4, dfps: 70.3

clsid
ffdshow_rev187_20060915_clsid_generic.exe
null: User: 8s, kernel: 0s, total: 8s, real: 9s, fps: 74.5, dfps: 70.1
vmr9: User: 8s, kernel: 0s, total: 8s, real: 11s, fps: 75.0, dfps: 58.1
ovrl: User: 8s, kernel: 0s, total: 9s, real: 9s, fps: 72.7, dfps: 70.1

clsid
ffdshow_rev181_20060913_clsid.exe
null: User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 75.7, dfps: 74.6
vmr9: User: 8s, kernel: 0s, total: 8s, real: 11s, fps: 75.4, dfps: 59.0
ovrl: User: 9s, kernel: 0s, total: 9s, real: 9s, fps: 70.2, dfps: 68.7

videomixer9
ffdshow-tryouts-rev155.exe
null: User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 81.6, dfps: 80.7
vmr9: User: 7s, kernel: 1s, total: 9s, real: 10s, fps: 72.0, dfps: 61.2
User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 78.2, dfps: 75.0

drevil_xxl
ffdshow-tryouts-rev155-AMD-XP-K8.exe
null: User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 79.6, dfps: 78.7
vmr9: User: 8s, kernel: 1s, total: 9s, real: 10s, fps: 68.3, dfps: 59.8
ovrl: User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 76.8, dfps: 73.0

videomixer9

15th September 2006, 19:58

for GCC 3.4.5 add -frename-registers -fweb and -funit-at-a-time. ICL should have global optimizations turned on (/Qip and /Og) and be set to O3 optimization, also for the .ax turn of loop unrolling (/Qunroll0). Any kind of automatic vectorization will make things usually slower, so leave off /Qx or /Qax switches and also don't use /arch. Link Time Code Generation is not really worth it for the .ax file.

foxyshadis

15th September 2006, 20:59

The end result of Normalize is range compression. And it's dynamic if it keeps autoadjusting itself during playback to avoid clipping. Which means the quality is not that great since you'll already have clipping when these adjustments have to be made. Normalization done during playback is quite bad because of this and very dependent on the audio material it has to work with. If the audio stream has a wide dynamic range already which varies a lot during playback, normalization is quite useless. There can be artifacts like in this case: "two people are speaking and suddenly a phone rings somewhere in the room while the people keep on speaking - if clipping happens, normalization will reduce the amplification gain and suddenly the voices of those people are much softer than they were. And if the ring tone is really loud it can happen you won't hear the people speaking at all".

DRC in AC3 and DTS is great if the audio stream was compressed with proper hints. Some of them aren't. DRC hints are much better than normalization during playback for obvious reasons (no real-time analysis for adjustments constraint). One can also use those hints and implement various degrees of range compression, like those "quiet/normal/noisy environment" profiles most commercial decoders have.
That's not DRC, that's dynamic (windowed) peak normalization. DRC is peak amplitude reduction, narrowing the range between soft and loud sounds on a much smaller timescale (limiters are almost instantaneous on/off), usually including some gain/peak normalization to bring the total volume back to maximum. Reference (http://en.wikipedia.org/wiki/Audio_level_compression). No special information is needed in the bitstream, although it can help prevent over- or under-compression, especially is the player is too slow to pick up peaks in time. That's why DTS and AC3 include the DRC hints in the bitstream, along with normalization hints.

I'd like to find some code that can be included in ffdshow, because I don't fancy writing my own. Most of the open source compressors utilize bitstream hints so they don't need a full implementation, which won't be any help to processing raw audio.

igor1st

15th September 2006, 21:30

AC3filter and ffdshow normalization work in the same way since they are both based on the same source code. Here is a more in-depth explanation: ac3filter audio theory docs (http://ac3filter.net/doc/ac3filter/ac3filter_eng.html#theory).
ffdshow uses method2 from mplayer (use several samples to smooth the variations via the standard weighted mean over past samples). And this is not the same as DRC or one-pass normalize in AC3Filter.

KoD

15th September 2006, 21:32

Range compression is still range compression no matter what algorithm you use to achieve it, people.

"use several samples to smooth the variations via the standard weighted mean over past samples". Now I understand why it does so badly on recovering from loud sounds... it treats them as too widely dispersed variations.

TFM_TheMask

15th September 2006, 22:33

I think I found a bug in the latest tryouts.

It seems like when your source is *.MOV with AAC 6 channel audio (for example the HD trailers from Apple (http://www.apple.com/trailers/)) and you want to encode the audio to AC3 with the ffdshow AC3 encoder there are a lot of downmix overflows. The sound seems to be distorted as if the volume is to high.

Now I have installed back an old version of ffdshow (dated 24-11-2005) and the sound is Ok now when doing the AC3 encoding. No downmix overflows.

Jeremy Duncan

16th September 2006, 12:53

I found a bug related to queue and seek. The internal filter in Media Player Classic "AVI" does not call Run at the expected timing. It may not be good, but a bug seems to be in ffdshow side. The bug should not be too difficult to fix, though I'm not sure if the bug is related to your problem.

I have not tryed a reproduce test. Please keep wating here and when the bug is fixed, please test again and report.

When you release the patched version of FFdshow. Please post the download link too.

LoRd_MuldeR

16th September 2006, 13:03

When you release the patched version of FFdshow. Please post the download link too.

Look at the Changelog (http://svn.sourceforge.net/viewvc/ffdshow-tryout/?view=log) to see what has been fixed recently and then get the latest build here (http://sourceforge.net/project/showfiles.php?group_id=173941).

Egh

16th September 2006, 15:56

Range compression is still range compression no matter what algorithm you use to achieve it, people.

Yes, but exact implementation is different. I prefer AC3Filter's one to ffdshow. I think AC3F recovers quicker from loud sounds. And overall does more balanced job, i think. (of course it's largely subjective, but I asked Milan last year to use AC3Filter's one in ffdshow :P)

And i don't use DRC or one-pass btw.

foxyshadis

16th September 2006, 20:51

AC3Filter does seem to have a much better normalizer and compressor, igor1st pointed it out to me and is working with the code. It would be quite nice to have that integrated instead of mplayer's mediocre version.

ckjnigel

16th September 2006, 21:03

I searched to no avail for new trunk (?) builds optimized for 64-bit Windows. Is anybody making them?

pdanpdan

16th September 2006, 21:22

I also have the same problems with autoloading presets on ffdshow video configure on all versions after rev 173

"When you enable 'Automatic Preset Loading' in the Image Settings menu, and exit, you will get an exception error when you try to start the ffdshow video configuration program again."

Kostarum Rex Persia

17th September 2006, 03:05

@

videomixer9 , haruhiko_yamagata, clsid and drevil_xxl

Can you guys, join your forces and finally make some decent 64-bit optimized FFDSHOW. Only celtic_druid made one 64-bit build, long time ago.

This is a big feature request.

17th September 2006, 03:30

As I remember, the 64-bit ffdshow needs 64-bit player, do you know such players?

thuan

17th September 2006, 03:44

There's one as fas as I know graphedit64

foxyshadis

17th September 2006, 04:03

KRP, file an enhancement request on the sourceforge page, so that it's not forgotten, but I can tell you now that it's going to be a low priority request for some time, at least until vista comes out and the rest of the world wakes up to 64-bit.

videomixer9

17th September 2006, 12:33

GCC cannot output win64 binary format, as long as it cannot do that you won't get any real stable x64 builds. However there is a binutils that should be able to output it now, need to make GCC use that stuff though now. A actual build will be still far away though.

17th September 2006, 14:16

What about ICL or MSVC?

LoRd_MuldeR

17th September 2006, 14:35

What about ICL or MSVC?

AFAIK at least the libavcodec needs to be build with GCC...

17th September 2006, 16:08

AFAIK at least the libavcodec needs to be build with GCC...

Revision 183 - Directory Listing
Modified Thu Sep 14 17:33:13 2006 UTC (2 days, 20 hours ago) by drevil_xxl

libavcodec.dll can be compiled with MINGW 3.4.x, 4.0.x, ICL9 and MSVC80.
:rolleyes:

videomixer9

17th September 2006, 16:22

well then compile yourself if you know everything better ... maybe you'll see it then ...

I guess I quit building ffdshow with this too, too many tards involved.

LoRd_MuldeR

17th September 2006, 16:22

:rolleyes:

Even if it can be done, that doesn't mean it works fast and/or stable...
At the moment all ffdshow builds use GCC for libavcodec/libmplayer and I think they have a reason for this ;)
VM9 even uses good old GCC 3.4.5, because this seems to be most reliable...

BTW: Is there any assembler code in ffdshow/libavcodec for AMD64 architecture yet? If not so, then speed improvements for x64 builds won't be that big, eh? Maybe even slower ???

foxyshadis

17th September 2006, 18:32

If you build lavc with MSVC or ICL you get none of the assembly optimizations, and speed plummets. It's just a non-starter. (Good for debugging as long as the problem isn't in the asm, though.) The only thing drevil_xxl did was fix some broken compatibility issues in the C side.

I'm not sure about x64 assembly; I thought there was but I don't see it in ffmpeg.

akupenguin

17th September 2006, 18:43

LoRd_MuldeR

17th September 2006, 18:53

gcc can compile the same inline asm to either ia32 or x86_64. Yes, you'd need separate asm to take full advantage of the extra registers, but the limit is usually the number of mmx registers not the gprs. So you won't see x86_64 specific asm in ffmpeg until one of the developers gets an intel x86_64 box and starts adding sse2.

To sum up: x64 builds won't be any faster until new asm code with x64 specific optimizations is added. And this will presumably not be in the near future...

Kostarum Rex Persia

17th September 2006, 20:01

Ok, thank you guys. It's pity that ffdshow doesn't have decent 64-bit version.

Can anyone start working on changing asm code for 64-bit? It's no matter when that hard job will be completed, it's very important to start.

Episode

17th September 2006, 20:45

Why is it so important to you have everything as 64-bit -versions? I bet it won't have any affect on speeds even if someone would make such build. If you have followed this thread for couple of months, I'm sure you'll have noticed how little different compiling optimizations affect on overall speed.

Also, it's quite annoying to see you whine in every codec/program related thread about these 64-bit versions and say things like "you need to do this for me right away because it's the most important thing in the world for me". Why don't you learn to code yourself and make your own 64-bit versions if it's so goddamn important to you. People are developing fine things like ffdshow on their own freetime without any payment and if they don't see any benefit on starting such a huge project for so minor speed increase, they won't do it, no matter how hard you try to order them to do so.

akupenguin

17th September 2006, 21:32

To sum up: x64 builds won't be any faster until new asm code with x64 specific optimizations is added.
Quite the reverse. I'm saying that we don't need any new asm for amd64 (only for intel). linux64 builds of ffmpeg are already ~10% faster than linux32. win64 will get the same benefit as soon as gcc can compile for win64.

LoRd_MuldeR

17th September 2006, 22:28

Quite the reverse. I'm saying that we don't need any new asm for amd64 (only for intel).
Hmm, interesting! Why does the old ASM code, which was written for x86 and thus doesn't use any x64 specific features, run 10% faster when compiled for x64? And why do we need new ASM code for Intel's 64-bit CPUs while the old code works fine on AMD's 64-Bit CPUs? Shouldn't Intel's implementation of x64 (EM64T) be compatible with AMD64 ???

:confused:

clsid

18th September 2006, 00:03

Perhaps because in some cases less operations are required to move the same amount of data to/from memory since the registers are twice as big?

LoRd_MuldeR

18th September 2006, 00:17

Perhaps because in some cases less operations are required to move the same amount of data to/from memory since the registers are twice as big?

But if we use the *unchanged* old ASM code (and *not* new ASM code with x64 optimizations), then it will still use the same operations that were used on x86. So how can it then benefit form the larger registers? Or will the compiler automatically "change" the ASM code to use x64 operations?

akupenguin

18th September 2006, 01:19

Why does the old ASM code, which was written for x86 and thus doesn't use any x64 specific features, run 10% faster when compiled for x64?
* gcc inline asm, as used in ffmpeg, lets the compiler do register allocation. In order to be compatible with ia32 w/ PIC, we refrain from directly using more than 6 registers at once. But to free up even that many, the compiler has to spill any other values it might be using before the asm block, whereas in x64 it can keep them in the other 9 regs. Also, some arguments (usually any scalar value except pointers) can work either as registers or directly from memory, so we can tell gcc to allocate a register for that if there is one available.

* Calling convention. The x64 abi uses fastcall(6), i.e. passes the first 6 function arguments in registers, whereas ia32's cdecl uses the stack. (Yes, one could use fastcall on ia32 also, but that's only 2 registers, and libavcodec is a library so it has to match the applications' abi.)
btw, win64 won't gain as much as linux64 does from the calling convention, since win64 only uses fastcall(4) and also imposes some other overhead on function calls.

And why do we need new ASM code for Intel's 64-bit CPUs while the old code works fine on AMD's 64-Bit CPUs? Shouldn't Intel's implementation of x64 (EM64T) be compatible with AMD64 ?
It's compatible, but not the fastest way.
(This applies to both ia32 and x64) On amd, mmx is usually faster than sse2 unless your algorithm specifically needs to fit 16 bytes in one xmm register (e.g. 8x8 dct benefits from sse2, but it's one of the few such functions in video codecs.) Intel has optimized for sse2 rather than mmx. But most of the ffmpeg developers use amd, so there isn't much sse2 code in ffmpeg.
x64 provides extra xmm registers, but not extra mmx registers. If you're on intel and using sse2, then x64 allows you to unroll some more, or avoid spilling. ia32 sse2 asm will still work, and it will still be faster than on ia32, but not by as much as if you rewrite the asm to take advantage of that. (Well, vector instrinsics could do that automatically, but so far they're only used on ppc/altivec, and don't work as well as inline asm on x86.) Amd64 of course also has the extra xmm registers, but mmx is still usually faster.

The other factor that would require new asm is sse4.

18th September 2006, 01:19

well then compile yourself if you know everything better
If i could do that, then I don't ask about such builds in forum :)

18th September 2006, 01:22

Even if it can be done, that doesn't mean it works fast and/or stable...
I agree with that, but someone tests this?

BTW: Is there any assembler code in ffdshow/libavcodec for AMD64 architecture yet? If not so, then speed improvements for x64 builds won't be that big, eh? Maybe even slower ???
It can be slower in x64 build because of REX prefix in such mode....

18th September 2006, 01:28

If you build lavc with MSVC or ICL you get none of the assembly optimizations, and speed plummets.

Is there any such build to make a speed comparsion? For ICL interests not only native build, but also optimised. Preffered -QxP or -QxB build.
And why assembly optimisations must depend on compiler?

LoRd_MuldeR

18th September 2006, 01:36

@akupenguin:
Think I understood. Thanks for explanation.

Kostarum Rex Persia

18th September 2006, 03:31

akupenguin, can you explain how celtic_druid made his x64 build. Did he used some changed code, or not?

BlindWanderer

18th September 2006, 06:06

There was a change between rev164 & rev181 that has resulted in ffdshow not working at all (and subsequent builds). Cannot even bring up the video decoder config box (via the start menu), crashes instead. When trying to play video it crashes (video does not load at all). The audio config page loads no prob.

running xpsp2, amd athlon 64 X2 4200+

EDIT:
for grins, i backed up the dll's from the 195 revision; installed the 164 revision, and dropped in the new dll's from 195; haven't had any problems yet...
So what ever the problem is, it's in ffdshow.ax

haruhiko_yamagata

18th September 2006, 06:19

8) ffdshow crashes when enabling stereoscopic option on subtitles page. (reported by drevil_xxl)
I think it should have been working in old ffdshow.
I have ffdshow-20040806.exe and ffdshow-20050303-sse.exe.
ffdshow-20040806.exe don't have strereoscopic option.
ffdshow-20050303-sse.exe have stereoscopic and does not crash, but it's not viewable.
Because building from old svn is hard, could someone help me?

haruhiko_yamagata

18th September 2006, 10:05

btw, what is stereoscopic subtitle?
With old ffdshow, with stereoscopic subtitle on, I've got this.

http://i9.tinypic.com/2aglufd.jpg

Is this what it supposed to be?

Egh

18th September 2006, 13:48

btw, what is stereoscopic subtitle?

Thats has been mystery for me since I first discovered this option.

I'd suggest to remove that feature completely and thus rectify this bug :P (Same probably with cubic interpolation in the perspective correction section).

There was a change between rev164 & rev181 that has resulted in ffdshow not working at all (and subsequent builds).
...
running xpsp2, amd athlon 64 X2 4200+

Thats not quite true. In spite of several recent reports, I still have no serious problems whatsoever with any of the last clsid builds. (181, 187 and 195 to be precise) I'm on XP SP2 too, just single-core A64.

haruhiko_yamagata

18th September 2006, 14:02

Thats has been mystery for me since I first discovered this option.

I'd suggest to remove that feature completely and thus rectify this bug.
Yes, if there's no objection, I will delete the option.

Same probably with cubic interpolation in the perspective correction section
I'm trying to debug it now, but with low motivation. Considering the time, it may be wise to hide the option. Everybody agree?

Jeremy Duncan

18th September 2006, 14:16

Works fine now using Queue output samples in Media Player Classic 6.4.9.0 using FFdshow Avisynth with MT and without MT and without Avisynth.
Input All Supported, Output YV12
VMR7 Windowed renderer.
Reclock.
PowerDVD 6.0 Video Render, using forced weave.
DScaler 5008 Audio Render.
Avisynth 2.5.7 Alpha 2
FFdshow Avisynth script:
SPresso(limit=8, limitC=8, bias=100, biasC=100, RGmode=1, RGmodeC=17)
or
MT("SPresso(limit=8, limitC=8, bias=100, biasC=100, RGmode=1, RGmodeC=17)",3)

Jeremy Duncan

18th September 2006, 15:49

ZoomPlayer 451pro
Overlay Mixer Video Render
Reclock.
PowerDVD 6.0 Video Render, using forced weave.
DScaler 5008 Video Renderer.
DScaler 5008 Audio Render.
FFdshow Rev 195
Avisynth 1.5.7 Alpha 2

The problem I ran into was stopping a movie during playback, without the popup seek bar open.
Then starting the movie again and the screen was black, but there was sound.
Sometimes using the seek bar in the minimized screen, not the popup seek bar, and zooming to a different point in the movie got the picture back.

In FFdshow, I tested the Deinterlacing tab, Deband tab, Resize & Aspect tab, Avisynth tab, Levels tab.
The powerdvd video decoder ran into most of the problems, with DScaler 5008 only having a problem with Denoise3d.

Settings using both video decoders in ZoomPlayer
Input All supported. Output YV12.
AVIsynth used YV12
MT("SPresso(limit=8, limitC=8, bias=100, biasC=100, RGmode=1, RGmodeC=17)",3)
SPresso(limit=8, limitC=8, bias=100, biasC=100, RGmode=1, RGmodeC=17)
Levels Input 0, 235 Output 0, 255
Main Resize & Aspect screen had no problems on any setting.

Powerdvd video decoder problems;
Point resize works.
Simple resize works.
hq2x works.
None works.
No other resize meathod works.

Checking Avisynth doesn't work. using code with or without MT.

Levels works.

Deinterlacing problems;
Tomsmocomp doesn't work.
DGBob doesn't work.
ffmpeg deinterlacer doesn't work.

Blur & NR: Denoise3d; With only HQ checked the denoise 3d works, but having Luma, Chroma, Time set to anything but 0.00 and it doesn't work.
Gradual Denoise at 40 works.

Deband doesn't work.

Using the DScaler 5008 video decoder. The only problem setting is Blur & NR denoise3d when I set Luma, Chroma or Time to anything but 0.00.

And finally.
Having Queue output samples checked, and "Use queue only in" unchecked. Using either video decoder in full or minimized screens.
There was no problem. Worked fine.
So I think the Queue output samples problem is fixed.
Using the seek bar when the above problems weren't causing a problem. It worked fine, no problem.

I was using ffdshow_rev195_20060917_clsid.exe

breez

18th September 2006, 17:08

Jeremy Duncan

18th September 2006, 17:15

What I mean by saying it doesn't work, in my previous post. Is that the black out problem is there because of using the mentioned setting.

clsid

18th September 2006, 17:32

List of known issues in revision 203:

1) VC-1, VMnc, and VP6 in Flash do not work. ffdshow isn't even placed in the DirectShow graph. (reported by clsid)
2) SVQ3 crashes when used in combination with Haali's MP4 splitter. Possibly not a ffdshow issue. (reported by Peuj)
3) Some SVQ3 files play with artifacts / color shifts / totally messed up picture. (reported by Peuj)
4) ffdshow crashes when enabling stereoscopic option on subtitles page. (reported by drevil_xxl)
5) If there's an error in avisynth script in ffdshow, the error message is displayed on top of video. That's ok, but interestingly enough, even if I uncheck the whole avisynth page in ffdshow, the error message still remains. (reported by Egh)
6) VP6 has artifacts and weird colors when decoded. (reported by clsid)
7) When there's more than one audio-stream in the file and you're using ffdshow's built-in audio-switcher, ffdshow performs all audio post-processing on all of the streams, thus slowing it way down. (reported by flanger216)

flanger216

18th September 2006, 17:37

I think I've found a bug in the audio decoder:

When there's more than one audio-stream in the file and you're using ffdshow's built-in audio-switcher, ffdshow performs all audio post-processing on all of the streams, thus slowing it way down.

For instance, for various reasons I upsample to 96khz (it improves my sound-card's virtualization) using the highest-quality method. When there's only one stream in the media-file, this only causes a ~10% jump in CPU usage. However, when I'm watching a file with more than one audio-stream, the CPU usage skyrockets. Can anybody reproduce this? And possibly fix it? :D

(note: you can't use Haali's splitter to reproduce the problem because, of course, it itself acts as a stream-switcher, so ffdshow only comes in contact with one of the audio-streams)

breez

18th September 2006, 18:06

What I mean by saying it doesn't work, in my previous post. Is that the black out problem is there because of using the mentioned setting.

I wasn't actually referring to your post, but your post did remind me of the border bug and I decided to post about it. It was forgotten because I don't use deband at the moment.

foxyshadis

18th September 2006, 19:58

The 16 pixel border problem as described later in this thread (http://forum.doom9.org/showthread.php?t=108681) still persists with the ffdshow deband filter. Tested with the latest rev195, but the bug isn't new, it was there from the start.
I would guess that this is not a bug, but expected behavior. DegrainMedian also doesn't process border pixels because of alignment requirements imposed by MMX/SSE2. Mostly because it's not really as noticeable. (Although ffdshow's lack of flexibility when it comes to filter ordering means you can't do something like adding borders, deband, and crop again - unless you use avisynth, perhaps. I've always wanted to make it so that the same filter can be added more than once in the chain.)

Damn thing's written in assembly, so it's not likely anyone else can fix it anyway. The creator rarely fixes problems, only works on new filters.

Amour

18th September 2006, 21:29

I found the following typos. Maybe somebody can fix them:

\src\settings\filters\ToutputVideoSettings.cpp
_l("NTSF"),
should be:
_l("NTSC"),

\src\settings\TpresetSettingsAudio.cpp
_l("on samplign frequency match"),NULL,
should be:
_l("on sampling frequency match"),NULL,

Eragon4ever

18th September 2006, 22:14

3 things (none is very important to me):

1. The german translation is incomplete and the GUI is to small at some parts.

2. In the audio OSD is the CPU load broken. It shows always 0%.

3. And in the video OSD it shows me FOURCC YV12 when the video is coded with wmv3. In the Input description YV12 is shown as well.

Build: videomixer9 r162

n3w813

18th September 2006, 23:21

List of known issues:

1) VC-1, VMnc, and VP6 in Flash do not work. ffdshow isn't even placed in the DirectShow graph. (reported by clsid)
2) SVQ3 crashes when used in combination with Haali's MP4 splitter. Possibly not a ffdshow issue. (reported by Peuj)
3) Some SVQ3 files play with artifacts / color shifts / totally messed up picture. (reported by Peuj)
4) ffdshow crashes when enabling stereoscopic option on subtitles page. (reported by drevil_xxl)
5) If there's an error in avisynth script in ffdshow, the error message is displayed on top of video. That's ok, but interestingly enough, even if I uncheck the whole avisynth page in ffdshow, the error message still remains. (reported by Egh)
6) revision 173 broke presets
7) VP6 has artifacts and weird colors when decoded. (reported by clsid)
8) When there's more than one audio-stream in the file and you're using ffdshow's built-in audio-switcher, ffdshow performs all audio post-processing on all of the streams, thus slowing it way down. (reported by flanger216)

Deleted, saw issue #6.

:stupid:

Amour

18th September 2006, 23:49

1. The german translation is incomplete and the GUI is to small at some parts.
LOL!
All translations are incomplete: this is a developpement branch of ffdshow, so new features are added everyday. Even the Japanese version where haruhiko_yamagata is working on won't have everything translated (DeBand, Treshold, Output queueing, ...).

Look what was his answer:
Create a patch and post it here (http://sourceforge.net/tracker/?group_id=173941&atid=867362).

Amour

18th September 2006, 23:53

A third typo:

\src\settings\filters\TsubtitlesSettings.cpp
{_l("Indonesian"), _l("ID"),_l("ind")},
{_l("Indonesian"), _l("IN"),_l("ind")},
{_l("Interlingua"), _l("IA"),_l("ina")},
{_l("Interlingue"), _l("IE"),_l("ile")},
{_l("Inuktitut"), _l("IU"),_l("iku")},
{_l("Inupiak"), _l("IK"),_l("ipk")},
{_l("Irish"), _l("GA"),_l("gle")},
{_l("Icelandic"), _l("IS"),_l("ice")},
{_l("Icelandic"), _l("IS"),_l("isl")},
Should be in alphabetical order:
{_l("Icelandic"), _l("IS"),_l("ice")},
{_l("Icelandic"), _l("IS"),_l("isl")},
{_l("Indonesian"), _l("ID"),_l("ind")},
{_l("Indonesian"), _l("IN"),_l("ind")},
{_l("Interlingua"), _l("IA"),_l("ina")},
{_l("Interlingue"), _l("IE"),_l("ile")},
{_l("Inuktitut"), _l("IU"),_l("iku")},
{_l("Inupiak"), _l("IK"),_l("ipk")},
{_l("Irish"), _l("GA"),_l("gle")},

In the same file:
{_l("Swedish"), _l("SV"),_l("swe")},
{_l("Swahili"), _l("SW"),_l("swa")},
Should be the reverse order:
{_l("Swahili"), _l("SW"),_l("swa")},
{_l("Swedish"), _l("SV"),_l("swe")},

Egh

19th September 2006, 00:28

LOL at some of the revisions:

Revision 198 - Directory Listing
Modified Mon Sep 18 13:12:19 2006 UTC (9 hours, 11 minutes ago) by h_yamagata
Bug fix : 2) The "perspective correction" filter makes ffdshow crash when interpolation-mode is set to "cubic". Happens only if horizontal video size is 768 or greater.
When horizontal video size is 768 or greater, use bilinear interpolation.

Revision 191 - Directory Listing
Modified Sat Sep 16 18:25:46 2006 UTC (2 days, 3 hours ago) by drevil_xxl
Added Miro VideoXL.

Revision 192 - Directory Listing
Modified Sat Sep 16 20:24:22 2006 UTC (2 days, 1 hour ago) by drevil_xxl
Removed Miro VideoXL.

Revision 150 - Directory Listing
Modified Thu Sep 7 13:15:17 2006 UTC (11 days, 9 hours ago) by h_yamagata
bug fix(? alpha test) : Raw video :
When Divx5=disabled and Raw video=all supported, the Divx5 video flips. The player is MPC. Please see if it does not have any side effects.

Revision 197 - Directory Listing
Modified Mon Sep 18 13:09:57 2006 UTC (9 hours, 14 minutes ago) by h_yamagata
revert the change of rev 150
side effect was reported (in 2ch/Japan).

ffdshow development certainly feels like fun :)

Jeremy Duncan

19th September 2006, 00:55

I was using ffdshow_rev195_20060917_clsid.exe for the test report I did with ZoomPlayer Professional 451.

foxyshadis

19th September 2006, 03:06

3. And in the video OSD it shows me FOURCC YV12 when the video is coded with wmv3. In the Input description YV12 is shown as well.
FFDshow isn't doing the decoding, that's why. The filterchain is:
WMV Splitter -> (wmv bitstream) -> WMV Decoder DMO -> (raw YV12) -> FFDshow -> Renderer.

If you've turned lavc on for WMV9, you've possibly found a bug or some sort of incompatibility.

Amour

19th September 2006, 04:52

Fourth typo:

\src\subtitles\ThtmlColors.cpp
{_l("comflowerblue"), 0x6495ed},
Should be:
{_l("cornflowerblue"), 0x6495ed},

_xxl

19th September 2006, 10:24

OSD doesn't work!
http://i10.tinypic.com/4840fnl.jpg
ffdshow.ax is compiled by GCC 4.0.3 SSE.
http://rapidshare.de/files/33649379/ffdshow.ax.html
rev 155 works.

Egh

19th September 2006, 13:19

OSD doesn't work!
http://i10.tinypic.com/4840fnl.jpg

I always use OSD and didn't have problems with it with any tryout builds :)

haruhiko_yamagata

19th September 2006, 14:10

I always use OSD and didn't have problems with it with any tryout builds :)
drevil_xxl is right. If ffdshow.ax is compiled by GCC 4.0.3, it crashes.

_xxl

19th September 2006, 14:27

drevil_xxl is right. If ffdshow.ax is compiled by GCC 4.0.3, it crashes.
rev 166 is ok.
rev 167 is not.
IDFF_MOVIE_AUDX was conflicted with IDFF_MOVIE_MAX.
#define IDFF_MOVIE_AUDX 23 // was 20 - conflicted with IDFF_MOVIE_MAX
#define IDFF_MOVIE_MAX 20

LoRd_MuldeR

19th September 2006, 14:46

drevil_xxl is right. If ffdshow.ax is compiled by GCC 4.0.3, it crashes.

If I remember correctly, this was stated a long time ago...

haruhiko_yamagata

19th September 2006, 14:48

rev 166 is ok.
rev 167 is not.
IDFF_MOVIE_AUDX was conflicted with IDFF_MOVIE_MAX.
#define IDFF_MOVIE_AUDX 23 // was 20 - conflicted with IDFF_MOVIE_MAX
#define IDFF_MOVIE_MAX 20

Tconfig.h
int isDecoder[IDFF_MOVIE_MAX+1];
OK, it's easy to fix then.

_xxl

19th September 2006, 15:01

ffdshow_constants.h:
#define IDFF_MOVIE_AUDX 11 // was 20 - conflicted with IDFF_MOVIE_MAX
works ok.

Eragon4ever

19th September 2006, 16:24

All translations are incomplete: this is a developpement branch of ffdshow, so new features are added everyday. Even the Japanese version where haruhiko_yamagata is working on won't have everything translated (DeBand, Treshold, Output queueing, ...).

Look what was his answer:

I'm aware of this (well, I didn't think about the other translations).
I didn't want to say it must be perfect in a project with this high activity, however some - I assume they are - old things are completely english. (Just looked ist 2/3 or more english)

And about the patch: Neither have I an idea how to make one nor is my english well enough to translate it correctly.

@foxyshadis: It's the AVI Splitter but exept that you are right.
And yes, libavcodec should decode "WMV3/9". Maybe this is the "incomplete" part.:rolleyes:

Amour

19th September 2006, 18:24

And about the patch: Neither have I an idea how to make one nor is my english well enough to translate it correctly.
In fact, you cannot imagine how difficult it is to translate this project. Each phrase is assign a number AND a group number. You have to find both numbers in order to be able to translate one phrase. There is no list of phrases-to-translate. You have to find them one by one among all the source files of the project...

But before you can even start translating, you need to learn about some alien thing called SVN, and finally learn about how to do a patch... I hope I will make it one day.

Other softwares I know have easy XML files available for translation.

\src\settings\filters\TresizeAspectSettings.cpp
strncatf(buf,len,_l(", horizontal warp: %-5.3f, verticalWarp: %-5.3f"),simpleWarpXparam/1000.0f,simpleWarpYparam/1000.0f);
Should be:
strncatf(buf,len,_l(", horizontal warp: %-5.3f, vertical warp: %-5.3f"),simpleWarpXparam/1000.0f,simpleWarpYparam/1000.0f);

\src\settings\filters\TsubtitlesSettings.cpp
tsprintf(s,_l("%s %3i%% (%s)"),w?w->_(id):_l("Horizontal position"),x,w?w->_(id,posS):posS);
Should be:
tsprintf(s,_l("%s %3i%% (%s)"),w?w->_(id):_l("Horizontal position:"),x,w?w->_(id,posS):posS);

I will try to propose a patch for all those corrections during the week.

foxyshadis

19th September 2006, 19:24

Actally clsid has been fixing the typos as you've found them. Thanks for searching, btw, it must be very tedious.

clsid

19th September 2006, 19:31

@Amour, I have added all your text fixes to the SVN.

TFM_TheMask

19th September 2006, 20:15

LoRd_MuldeR

19th September 2006, 20:56

@drevil_xxl
Is it possible that your builds turn off the H.264 deblocking?
I installed your rev202 today and I was wondering why my H.264 video look so much blocky.
Then I noticed deblocking was turned off completely :scared:
But I cannot remember to have done that...

haruhiko_yamagata

20th September 2006, 01:06

But before you can even start translating, you need to learn about some alien thing called SVN, and finally learn about how to do a patch... I hope I will make it one day.
Oh, I'm sorry. If making a patch troubles you, please submit the whole translations file.
As for the typo, patches are more desirable though.

BlindWanderer

20th September 2006, 08:29

I think the deblocking turn off may have been a new feature (i don't remember it existing before).

I installed rev202 sse build and it works (but i did set the installer this time to erase my settings) so all is good in the world again.

I peaked at the ffmpeg source and I understand r6290 (and why it was required) but the more i wrap my brain about the source; the less it makes sence... suppose a proper education would help ^^;

_xxl

20th September 2006, 08:38

I think the deblocking turn off may have been a new feature (i don't remember it existing before).
http://i9.tinypic.com/3zk5kkn.jpg

ianken

20th September 2006, 08:57

How about this bug???

I too have found that AC3 encoder and output does not work for any build newer than 20051129.

Which is a bummer since that is one of the coolest features, particluarly if you've got aome AAC 5.1 stuff.

I also use it for XP-MCE to handle layer 2 audio for live tv, do volume normalization and output DD 2.0

BlindWanderer

20th September 2006, 08:59

http://i9.tinypic.com/3zk5kkn.jpg

Yeah, that checkbox is what i was reffering to (i found it while looking for checkboxes).

haruhiko_yamagata

20th September 2006, 12:17

@developpers

I'm trying to install hook script for the svn to send notify e-mails. Untill it begin to work, you may have weird e-mail from sf.net. Please ignore.

_xxl

20th September 2006, 12:30

I think it should have been working in old ffdshow.
I have ffdshow-20040806.exe and ffdshow-20050303-sse.exe.
ffdshow-20040806.exe don't have strereoscopic option.
ffdshow-20050303-sse.exe have stereoscopic and does not crash, but it's not viewable.
Because building from old svn is hard, could someone help me?
ffdshow-20050703.exe works ok.
ffdshow-20050822.exe is not.

LoRd_MuldeR

20th September 2006, 12:52

Yeah, that checkbox is what i was reffering to (i found it while looking for checkboxes).

But why disable deblocking? Maybe usefull when you know what you are doing, but should not be disable for normal users. They might think H.264 looks very blocky and switch to WMV9 instantly...

haruhiko_yamagata

20th September 2006, 12:57

ffdshow-20050703.exe works ok.
ffdshow-20050822.exe is not.
Thank you. I deleted stereoscopic subtitle because nobody seems to need it. If anyone need it, we can revert anytime.

clsid

20th September 2006, 13:09

List of known issues in revision 209:

1) VC-1, VMnc, and VP6F do not work. ffdshow isn't even placed in the DirectShow graph. (reported by clsid)
2) VP6 has artifacts and weird colors when decoded. (reported by clsid)
3) SVQ3 crashes when used in combination with Haali's MP4 splitter. Possibly not a ffdshow issue. (reported by Peuj)
4) Some SVQ3 files play with artifacts / color shifts / totally messed up picture. (reported by Peuj)
5) If there's an error in avisynth script in ffdshow, the error message is displayed on top of video. That's ok, but interestingly enough, even if I uncheck the whole avisynth page in ffdshow, the error message still remains. (reported by Egh)
6) When there's more than one audio-stream in the file and you're using ffdshow's built-in audio-switcher, ffdshow performs all audio post-processing on all of the streams, thus slowing it way down. (reported by flanger216)
7) When outputting the audio to AC3 using the ffdshow AC3 encoder there are a lot of downmix overflows. The sound seems to be distorted as if the volume is to high. (reported by TFM_TheMask)

Notes:
- Problem 2 does NOT occur in FFplay. So FFMPEG/libavcodec code is working.
- Problem 4 also occurs in FFplay, so problem is likely due to incompleteness of SVQ3 in FFMPEG code.

KoD

20th September 2006, 13:27

The h264 in-loop deblocker must be enabled at all times. It's part of how h264 works. Which means that "skip deblocking always" checkbox must be unchecked.

LoRd_MuldeR

20th September 2006, 14:31

The h264 in-loop deblocker must be enabled at all times. It's part of how h264 works. Which means that "skip deblocking always" checkbox must be unchecked.

It can be chcked for better performance, but it definitely should not be checked by default.

Egh

20th September 2006, 16:10

Yeah, that checkbox is what i was reffering to (i found it while looking for checkboxes).

I suggested some time ago that those checkboxes need to be moved to another page ^^ Decoding options looks like proper candidate for them.

And the best solution is to redo them as in CoreAVC -- single combobox with "standard deblocking, no b-frame deblocking, no deblocking" options in it. This would make is much less confusing for the users, who discover a checkbox more than a year after it was introduced ^^

Jeremy Duncan

21st September 2006, 02:35

Software.

Decoders:
DScaler 5008 Video Decoder
NVidia Video Decoder from Theatretek, file version 11.0.0.28844
Cyberlink Video Decoder from Powerdvd 6.0

Players:
Media Player Classic 6.4.9.0
Zoomplayer 451pro

Other stuff:
Reclock & DScaler Audio Decoder, FFdshow rev 195 clsid

DVD's used for testing:
Over Canada: an Aerial Adventure
Equilibrium

Test configuration 1
Movie: Equilibrium
Media Player classic using,
Reclock,
DScaler video decoder set to output YV12,
DScaler audio decoder default,
FFdshow has nothing checked but Output queue samples, Input All supported, output YV12.
Selecting the Navigate to Root Menu freezes the player with queue output samples checked.
Unchecking queue output smaples lets me use the navigate to root menu screen.
During Movie playback same thing, with output quoue samples checked, I can't use the seek bar.

Test configuration 2
Movie: Over Canada: an Aerial Adventure
Media Player classic using,
Reclock,
DScaler video decoder set to output YV12,
DScaler audio decoder default,
FFdshow has nothing checked but Output queue samples, Input All supported, output YV12.
Selecting the Navigate to Root Menu freezes the player with queue output samples checked.
Unchecking queue output smaples lets me use the navigate to root menu button.
During Movie playback with output queue samples checked, the played does not freeze.
It's fine with queue output samples checked or unchecked and using the seek bar.

Test configuration 3
Movie: Equilibrium, Over Canada: an Aerial Adventure
Media Player classic using,
Reclock,
NVidia Video Decoder from Theatretek, file version 11.0.0.28844
Cyberlink Video Decoder from Powerdvd 6.0
DScaler audio decoder default,
FFdshow has nothing checked but Output queue samples, Input All supported, output YV12.
No problems navigating to the root menu or using the seek bar during movie playback in either movie.

Test configuration 4
Movie: Equilibrium, Over Canada: an Aerial Adventure
ZoomPlayer using,
Reclock,
DScaler Video Decoder,
NVidia Video Decoder from Theatretek, file version 11.0.0.28844
Cyberlink Video Decoder from Powerdvd 6.0
DScaler audio decoder default,
FFdshow has nothing checked but Output queue samples, Input All supported, output YV12.
No problems navigating to the root menu or using the seek bar during movie playback in either movie.

I just tested MPC using the Cyberlink video decoder in my last test report.
Sorry about the misunderstanding.

Jeremy Duncan

21st September 2006, 09:15

is DeviL.dLL a part of FFdshow's code ? Or is the only program that uses it Avisynth ?

clsid

21st September 2006, 10:25

It's not part of ffdshow.

_xxl

21st September 2006, 12:40

wmv1, wmv2, wmv3, vc-1 ffmpeg encoders aren't working.
http://img18.imagevenue.com/loc329/th_34624_vfw_122_329lo.jpg (http://img18.imagevenue.com/img.php?image=34624_vfw_122_329lo.jpg)

haruhiko_yamagata

21st September 2006, 13:34

I found a bug.

If ffdshow is inputing DVD decoder's output as raw video,
and if mpeg2 is disabled or DVD decoding is unchecked,
and if Subtitles is unchecked and "File" is valid,
the video shows subtitle unrelated to the DVD movie.

haruhiko_yamagata

21st September 2006, 13:54

Test configuration 1
Movie: Equilibrium
Media Player classic using,
Reclock,
DScaler video decoder set to output YV12,
DScaler audio decoder default,
FFdshow has nothing checked but Output queue samples, Input All supported, output YV12.
Selecting the Navigate to Root Menu freezes the player with queue output samples checked.
Unchecking queue output smaples lets me use the navigate to root menu screen.
During Movie playback same thing, with output quoue samples checked, I can't use the seek bar.
In my reproduce test, DScaler DVD decoder+Queue is problematic. It works with MPC's internal DVD decoder.
Interestingly, if mpeg2 decoder of ffdshow is enabled and DVD decoding is checked, the problem goes. ffdshow does not decode actually. Please see if it is true with your case.

Egh

21st September 2006, 15:03

and if Subtitles is unchecked and "File" is valid,
the video shows subtitle unrelated to the DVD movie.

I think i reported that bug to Milan more than a year ago. Looks like nothing was corrected over that time ^^

clsid

21st September 2006, 15:47

List of known issues in revision 215:

1) VMnc and VP6F do not work. ffdshow isn't even placed in the DirectShow graph. (reported by clsid)
2) VC-1 crashes (FourCC wmva). (reported by clsid)
3) VP6 has artifacts and weird colors when decoded. No such problem occurs in FFMPEG's own FFplay program. (reported by clsid)
4) SVQ3 crashes when used in combination with Haali's MP4 splitter. Possibly not a ffdshow issue. (reported by Peuj)
5) Some SVQ3 files play with artifacts / color shifts / totally messed up picture. Same issues in FFplay, so it is likely due to incompleteness of SVQ3 in FFMPEG code. (reported by clsid)
6) If there's an error in avisynth script in ffdshow, the error message is displayed on top of video. That's ok, but interestingly enough, even if I uncheck the whole avisynth page in ffdshow, the error message still remains. (reported by Egh)
7) When there's more than one audio-stream in the file and you're using ffdshow's built-in audio-switcher, ffdshow performs all audio post-processing on all of the streams, thus slowing it way down. (reported by flanger216)
8) When outputting the audio to AC3 using the ffdshow AC3 encoder there are a lot of downmix overflows. The sound seems to be distorted as if the volume is to high. (reported by TFM_TheMask)
9) Output queue enabled + VMR9 renderless + RGB32 + specific video cards + pause = blackout problem
10) If ffdshow is inputing DScaler DVD decoder's output and queue is enabled, seek does not work. (reported by Jeremy Duncan)
11) If ffdshow is inputing DVD decoder's output as raw video, and if mpeg2 is disabled or DVD decoding is unchecked, and if Subtitles is unchecked and "File" is valid, the video shows subtitle unrelated to the DVD movie. (reported by haruhiko_yamagata)
12) H.264 deblocking options should be moved to 'Decoder options' as single combobox with "standard deblocking, no b-frame deblocking, no deblocking" options in it. (suggested by Egh)

Jeremy Duncan

21st September 2006, 16:06

In my reproduce test, DScaler DVD decoder+Queue is problematic. It works with MPC's internal DVD decoder.
Interestingly, if mpeg2 decoder of ffdshow is enabled and DVD decoding is checked, the problem goes. ffdshow does not decode actually. Please see if it is true with your case.

Movies: Equilibrium, Over Canada: An Aerial Adventure.
Media Player Classic 6.4.9.0
External filters:
Reclock
DScaler 5008 audio decoder, default setting.
DScaler 5008 video decoder, output YV12.

FFdshow rev 195 clsid
Codecs: Mpeg2 set to use either libmpeg2, or libavcodec,
and checking "DVD decoding (not working yet)"
Input: All supported, Output: YV12.
Using denoise3d: 0.00, 2.00, 4.00, HQ
Levels: input 0, 235, Output, 0, 255
Resize & Aspect: New Size: 1280, 720, No aspect ratio correction, Lanczos, lumasharpen 1.60
Queue output samples checked

I can skip to root menu and use the seek bar during movie playback.
Without mpeg2 enabled to either libmpeg2, or libavcodec, and just checking "DVD decoding (not working yet)" it freezes when I skip to the root menu or use the seek bar.
Same thing with mpeg2 enabled to either libmpeg2, or libavcodec, but not checking "DVD decoding (not working yet)".

haruhiko_yamagata

21st September 2006, 16:07

9) Various output queue issues.

I don't like this. should be

9) Output queue enabled + VMR9 renderless + RGB32 + specific video cards + pause = blackout problem
10) If ffdshow is inputing DScaler DVD decoder's output and queue is enabled, seek does not work.

haruhiko_yamagata

21st September 2006, 16:11

Without mpeg2 enabled to either libmpeg2, or libavcodec, and just checking "DVD decoding (not working yet)" it freezes when I skip to the root menu or use the seek bar.
Same thing with mpeg2 enabled to either libmpeg2, or libavcodec, but not checking "DVD decoding (not working yet)".
Thank you. Then I think I'm reproducing your problem properly.

Amour

21st September 2006, 23:11

\src\subtitles\TsubtitlesFile.cpp
const char_t* TsubtitlesFile::mask=_l("Subtitles (*.utf;*.sub;*.srt;*.smi;*.rt;*.txt;*.ssa;*.aqt;*.mpl;*.idx)\0*.utf;*.sub;*.srt;*.smi;*.rt;*.txt;*.ssa;*.aqt;*.mpl;*.usf;*.idx\0All filter (*.*)\0*.*\0");

Should be:
const char_t* TsubtitlesFile::mask=_l("Subtitles (*.utf;*.sub;*.srt;*.smi;*.rt;*.txt;*.ssa;*.aqt;*.mpl;*.idx)\0*.utf;*.sub;*.srt;*.smi;*.rt;*.txt;*.ssa;*.aqt;*.mpl;*.usf;*.idx\0All files (*.*)\0*.*\0");

I will attach my French update tonight.

Amour

21st September 2006, 23:21

Here is my work on the translation. It is not complete at all, but it's better than previous version (compare the file size...). I've included some small test phrases, because I'm not sure about how the all thing works, and I do not know how to compile/test by myself.

[edit: file is in the patch section of sourceforge]

haruhiko_yamagata

22nd September 2006, 13:15

@Amour
@Jeremy Duncan

Here (http://www.mytempdir.com/944519)'s a test build.

Thank you very much for the French translations.
Your translations are included. Please see if it works.

Seek problem with DScaler DVD decoder is fixed. Please check.

Windows NT 4.0 sp6 have not been supported by my builds. This time I have built custom msvcr80.dll to support NT 4.0 sp6. If you are a user of NT 4.0 sp6, please test. If you are not a user of NT 4.0, normal msvcr80.dll is installed.

The build is labeled 228, but it does not include the change of 227 (simply timing issue).

clsid

22nd September 2006, 13:24

rev231 build (http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow_rev231_20060922_clsid.exe?download)

List of known issues in revision 231:

1) VMnc and VP6F do not work. ffdshow isn't even placed in the DirectShow graph. (reported by clsid)
2) VC-1 crashes (FourCC wmva). (reported by clsid)
3) SVQ3 crashes when used in combination with Haali's MP4 splitter. Possibly not a ffdshow issue. (reported by Peuj)
4) Some SVQ3 files play with artifacts / color shifts / totally messed up picture. Same issues in FFplay. (reported by clsid, Peuj)
5) If there's an error in avisynth script in ffdshow, the error message is displayed on top of video. That's ok, but interestingly enough, even if I uncheck the whole avisynth page in ffdshow, the error message still remains. (reported by Egh)
6) When there's more than one audio-stream in the file and you're using ffdshow's built-in audio-switcher, ffdshow performs all audio post-processing on all of the streams, thus slowing it way down. (reported by flanger216)
7) When outputting the audio to AC3 using the ffdshow AC3 encoder there are a lot of downmix overflows. The sound seems to be distorted as if the volume is to high. (reported by TFM_TheMask)
8) Output queue enabled + VMR9 renderless + RGB32 + specific video cards + pause = blackout problem
9) If ffdshow is inputing DVD decoder's output as raw video, and if mpeg2 is disabled or DVD decoding is unchecked, and if Subtitles is unchecked and "File" is valid, the video shows subtitle unrelated to the DVD movie. (reported by haruhiko_yamagata)
10) H.264 deblocking options should be moved to 'Decoder options' as single combobox with "standard deblocking, no b-frame deblocking, no deblocking" options in it. (suggested by Egh)
11) Decoding VP60 and VP61 gives black screen.

Amour

22nd September 2006, 14:38

Your translations are included. Please see if it works.
Looks ok, but the shortcuts from the Start Menu aren't translated (audio decoder configuration, uninstall ffdshow, ...). I'll try to investigate. [edit] It's because I didn't translate it... gomen.

My small test is conclusive: the phrases to translate are case-sensitive (so you need both to translate “None” and “none” for example).

Clsid builds do not offer language choice at installation time. Maybe an auto-detect language script would be convenient.

Now it needs to complete the translation work (add the GNU licence, fix layout for long phrases, complete the translation(s)). I will see another day. :)

Amour

22nd September 2006, 15:21

Hum, couldn't find anywhere the files with the following phrases:
“Installer Language”
“Please select a language.”

Jeremy Duncan

22nd September 2006, 17:22

Movies: Equilibrium, Over Canada: An Aerial Adventure.
Media Player Classic 6.4.9.0
External filters:
Reclock
DScaler 5008 audio decoder, default setting.
DScaler 5008 video decoder, output YV12.

FFdshow ffdshow-20060923-rev228-Q.exe
Codecs: raw video, all supported.
Input: All supported, Output: YV12.
Using denoise3d: 0.00, 2.00, 4.00, HQ
Levels: input 0, 235, Output, 0, 255
Resize & Aspect: New Size: 1280, 720, No aspect ratio correction, Lanczos, lumasharpen 1.60
Queue output samples checked

I can skip to root menu and use the seek bar during movie playback.

It's working great now ! :thanks:

Egh

22nd September 2006, 21:27

khagaroth

22nd September 2006, 21:59

Eragon4ever

22nd September 2006, 22:04

@Amour: I'm currently working on the German translation (I found more or less out how it works:D ) and you only have to save the file and (re)open the ffdshow window.

Edit: @khagaroth: Thank you very much!!:thanks:
This really helps.

clsid

23rd September 2006, 01:08

@ clsid:

just a minor complaint about installer: all your last builds have trouble identifying whenever "raw video" input is enabled for ffdshow.

Despite having "all supported" option chosen in RAW video in ffdshow, your installed still doesn't have "RAW video" box checked automatically.
The installer doesn't check the boxen (in the installer) based on the current settings in the registry. It will re-use the settings chosen during a previous installation, or else use it own defaults. I can change the behaviour to read settings from the registry if there is enough demand for it.

LoRd_MuldeR

23rd September 2006, 02:16

The installer doesn't check the boxen (in the installer) based on the current settings in the registry. It will re-use the settings chosen during a previous installation, or else use it own defaults. I can change the behaviour to read settings from the registry if there is enough demand for it.

So if your installer can "remember" the settings from a previous installation, this means you save those settings to some place in the registry. But why save the settings in installer-specific registry keys when ffdshow saves the settings in the regsitry anyway? Wouldn't it make more sense to use the same registry keys for ffdshow and the installer? I personally would appreciate if your installer could load my current ffdshow settings from the registry.

Anyway, thanks for keeping the builds up-to-date :)

Jeremy Duncan

23rd September 2006, 08:27

Yes, thank you all for helping to make a program like FFdshow.
Thank you very much.

:thanks:

clsid

23rd September 2006, 12:07

So if your installer can "remember" the settings from a previous installation, this means you save those settings to some place in the registry. But why save the settings in installer-specific registry keys when ffdshow saves the settings in the regsitry anyway? Wouldn't it make more sense to use the same registry keys for ffdshow and the installer? I personally would appreciate if your installer could load my current ffdshow settings from the registry.

Anyway, thanks for keeping the builds up-to-date :)The installer software stores that information in its uninstall reg key by default. Its not like I coded it specially for ffdshow. Its a pretty normal behaviour. But I will add some code to read the ffdshow settings when I got some spare time.

Edit: rev236 build (http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow_rev236_20060923_clsid.exe?download) :D