ffdshow tryouts project: Discussion & Development [Archive] - Page 18

Leak

24th March 2007, 17:41

EndFlush may be called while ffdshow is decoding the last sample of the current segment. In that case,I'm afraid the filter will buffer the last frame of the current segment as the first frame of the coming segment.
Maybe so, but I'd rather have 1 sample being needlessly shown than 10 or so of them. Anyway, I'll try playing around with this a bit and see what happens; I could also just drop the first frame after a flush since seeking is inexact anyway *and* the graph is obviously already running.

(Note that I'd of course only do all of this if the previous filter in the DirectShow graph was the DVD Navigator - it works fine with everything else already...)

np: Alias & Tarsier - 5 Year Eve (Neotropic Remix) (Plane That Draws A White Line)

albain

24th March 2007, 19:25

is there a lot of extra stuff on sdk v6, compared to dx sdk feb07 (as it does support dx10)

ps. ffdshow builds fine now with gcc

cheers

directx sdk no more includes direct show, it is now located within windows sdk

What's new in v6 (I have listed only the interesting stuff)
- core Audio APIs (the new audio stack from Vista)
- new directshow:
1/The new APIs and interfaces replacing VMR9 : EVR (Enhanced Video Renderer), supposed to be better than VMR9
2/DirectX Video Acceleration V2 (DXVA 2) improves hardware acceleration and better direct3D interaction
3/Support for WDDM capture devices (not useful for ffdshow)
4/Better MPEG1 layer 2 decoder
5/Better DVD playback
6/Audio end point devices

Dr Pizza

24th March 2007, 21:22

Hrrrm. Is there something special I have to do to make it work?

I'm building in VC++ 2005, using the Vista Platform SDK, Release, Unicode, x64. I had to make a couple of minor changes to one file to comment out some inline assembler, which isn't supported in x64 (I realize it'll probably break if that codepath is hit, but I'm not using the code in question anyway), and I had to change an operator new overload to use "size_t" instead of "unsigned", but with that done, it's all building and compiling apparently correctly. The .ax registers properly, and the properties pages work fine. However, it won't join any filter graphs. It's definitely doing something (because I can see ffdshow getting loaded to generate thumbnails in Explorer) but it won't join my filter graph in my 64-bit media playing app.

If I try to construct a graph manually in graphedt, ffdshow refuses to join the graph, claiming "No combination of intermediate filters could be found to make the connection. (Return code: 0x80040217)". I'm guessing that something's broken, but I'm not really sure what.

cc979

24th March 2007, 21:55

directx sdk no more includes direct show, it is now located within windows sdk

What's new in v6 (I have listed only the interesting stuff)
- core Audio APIs (the new audio stack from Vista)
- new directshow:
1/The new APIs and interfaces replacing VMR9 : EVR (Enhanced Video Renderer), supposed to be better than VMR9
2/DirectX Video Acceleration V2 (DXVA 2) improves hardware acceleration and better direct3D interaction
3/Support for WDDM capture devices (not useful for ffdshow)
4/Better MPEG1 layer 2 decoder
5/Better DVD playback
6/Audio end point devices

theres a few things then, maybe i will upgrade next year when its more stable - or maybe sooner if i'm forced to because dx10 and games

SealTooGreat

24th March 2007, 23:34

With:
ffdshow_rev1050_20070319_clsid_sse_icl9.exe
ffdshow_beta2a_20070322_clsid.exe
ffdshow_beta2_20070319_clsid.exe
.... using MPC+Haali splitter, I can't watch my anamorphic encodes(it doesn't stretch to correct AR) and also there's some green line in right border.
Using same ffdshow video presets I don't have that issue with:
ffdshow_beta1_20061211_clsid.exe
Any idea why?!
It works for me. Which video renderer do you use?
Could you upload the sample?
What is the OS and version of the directShow?
What is the video card?
1. Haali renderer(7-march-2007)
2. sample(6mb) (http://depositfiles.com/files/724695)
3. Windows XP Professional SP2. Don't know which software DirectShow version you've meant.
4. Nvidia GeForce 7300 GS.

Blight

24th March 2007, 23:49

Leak

24th March 2007, 23:51

I'm not sure that loading old settings for the "work with application" value is a good idea for future compatibility.
Well, just blowing it's old settings away probably isn't a good idea either...

Blight

25th March 2007, 00:20

leak:
audio/decoder/processing settings should stay as that makes the upgrade have less of an impact in case new default-on settings may cause unforseen issues. Loading the application whitelist setting from a previous installation means that any new whitelisted application introduced in future ffdshow versions will not work ... which makes no sense.

Dr Pizza

25th March 2007, 00:57

Ooops, I was being a dumbass. I hadn't noticed that the libavcodec hadn't built properly. The Win32 project excludes a number of source files (that won't work in VC++, I guess), and so builds the DLL properly. The x64 project doesn't exclude them, so fails to produce a DLL. Excluding the same set of source files allowed the x64 project to emit a file, resulting in a functional ffdshow.

Leak

25th March 2007, 01:14

Loading the application whitelist setting from a previous installation means that any new whitelisted application introduced in future ffdshow versions will not work ... which makes no sense.
Well, what about entries the user has made him/herself? Dropping those won't make the user very happy either...

clsid

25th March 2007, 01:33

Maybe it would be better to disable the whitelist feature by default. At least the first few months. So that a more comprehensive list of compatible apps can be gathered.

skystrife

25th March 2007, 06:49

_xxl

25th March 2007, 09:03

I hadn't noticed that the libavcodec hadn't built properly. The Win32 project excludes a number of source files (that won't work in VC++, I guess), and so builds the DLL properly.
Libavcodec shouldn't be compiled by MSVC.MS can't compile GCC asm syntax.Only GCC can.
Maybe it would be better to disable the whitelist feature by default.
We should add a link to ffdshow-tryouts page in Setup.

haruhiko_yamagata

25th March 2007, 09:31

haruhiko_yamagata:
The previous version I had installed was build 584 (clsid), which was a clean install.

I then tried installing beta2a and was presented with a list that did not contain zplayer.exe. I'm afraid that if Zoom Player users install this version it will no longer work.
zplayer.exe is at the botom of long scroll list(alphabetical order).
Please tell me what applications are listed there.

I'm not sure that loading old settings for the "work with application" value is a good idea for future compatibility.Yes, better implementation is required. Not just over-writing, add new entries with user's permision.

haruhiko_yamagata

25th March 2007, 09:33

Maybe it would be better to disable the whitelist feature by default. At least the first few months. So that a more comprehensive list of compatible apps can be gathered.
Gathering apps exe name and checking compatibility is very very hard work. Unless we set it by default, we won't have any reports.

wiak

25th March 2007, 09:41

Is there really a need for x64 build of ffdshow? I mean, it won't be any faster than normal 32-bit build and x64 is compatible with normal builds.

YES there is need
Vista Media Center x64 has problems with 32bit codecs, so it needs a x64 version

_xxl

25th March 2007, 09:56

I don't know how much faster x64 will be.Because asm code is written for x86 32bit.New x64 asm code is required.

Dr Pizza

25th March 2007, 11:04

Do you think you could make an installer so some of us can start beta testing it?

I've no idea how to make the installer, and someone ought to sanity-check the changes I had to make.

Leak

25th March 2007, 11:10

I've no idea how to make the installer, and someone ought to sanity-check the changes I had to make.
Install InnoSetup, then open the bin\distrib\InnoSetup\ffdshow_installer.iss file with it and compile it.

Dunno if that works out-of-the-box for x64, though.

multiblitz

25th March 2007, 11:35

I guess this is a bug:

If I use ffdshow (rev 1020) to playback VC-1 (HD-DVD) (using Haali's splitter, AnyDVD and ZP), I get a white picture (pure white screen) if I don't resize the picture. With resize (lanzos), I have a nice picture. But I don't want to resize (1920*1080 is already there...)

BIggest Bug so far: If ffdshow is used in the video-part (does not matter if it is only postprocessing-raw-filter after the original MS VC-1 Codec or directly the ffdshow-VC-1-decoder): Instead of correct speed of 23.976 fps, it recognizes 29.999 fps. So, the video is much faster than the audio which indeed is the case...without ffdshow in the video-chain, with pure MS VC-1, it works, eventhough SPDIF is still somewhat jaggy (core duo 6400 at 3.6 ghz).

Any ideas how to solve this ? Has anyone actually looked into this at all ?

Blight

25th March 2007, 11:42

haruhiko_yamagata:
doh, it is listed, it's just that the display list crops the bottom item if there's no room to display a line (this is a weird behavior for a list type display in windows), so it looked to me as if there were only 9 files listed.

leak:
the ratio of users manually adding programs to the white list compared to future white-list additions not being included and stuff not working is pretty high. most users don't change any setting and just click next next next during installation.

DeepBeepMeep

25th March 2007, 11:51

FFdshow is still incompatible with EVO file containing VC1 parsed with Haali filter (video is accelerated and audio / video gets out of sync). Is there any place to fix this issue in the next beta? It is a bit sad to be able to use ffdshow here.
Thanks for your support.

_xxl

25th March 2007, 12:17

Is this a ffdshow issue?

multiblitz

25th March 2007, 12:27

Is this a ffdshow issue?

Just read above, it's the same bug I have now reported twice: BIggest Bug so far: If ffdshow is used in the video-part (does not matter if it is only postprocessing-raw-filter after the original MS VC-1 Codec or directly the ffdshow-VC-1-decoder): Instead of correct speed of 23.976 fps, it recognizes 29.999 fps.

So, even if you don't use fdshow for VC-1-decoding, simply if it is in the filter-chain, you have this bug.

DeepBeepMeep

25th March 2007, 13:37

Is this a ffdshow issue?

It seems to be an ffdshow issue. I have exchanged a few messages with Haali who didn't find any issue with his filter. What seems to indicate that this a ffdshow bug is that like multiblitz mentioned it, if you don't use ffdshow as a VC1 decoder but only as a postprocessor filter you get the issue while the same VC1 decoder alone without ffdshow works fine.

My theory is that the EVO file contains some telecine flags such as 'repeat top' which are supposed to increase every other frame by 50%. This is supposed to enable a 'soft' 3:2 pulldown if a movie is not watched on an interlaced display.

Therefore if these flags are taken into account you get 23.976 frames per second. If these flags are ignored / lost on the way, every frame lasts the same duration and at the end more frames fits in the same second and we have 29.97 frames per second.

Basically what calculates time stamps should take into account these flags or ffdshow should forward the flags (AM_VIDEO_FLAG_FIELD1FIRST / AM_VIDEO_FLAG_REPEAT_FIELD?) to the next filter in the chain.

Just my 2 cents...

haruhiko_yamagata

25th March 2007, 13:51

just been testing the .ts clip from
http://forum.doom9.org/showpost.php?p=974692&postcount=539

it something expands correcting in vlc but in mpc with ffdshow/vmr9 it expands vertical, weird?
Anybody who can reproduce this, please help.
I think this kind of problem is really important but I can't reproduce.
Is this environment specific?
If so, what does it depend?

fastplayer

25th March 2007, 14:20

Anybody who can reproduce this, please help.
I think this kind of problem is really important but I can't reproduce.
Is this environment specific?
If so, what does it depend?
System default renderer:
Sample expands correctly (horizontally) when using MPC+ffdshow's libmpeg2. When using MPC's internal libmpeg, then AR stays the same.
VMR9:
With MPC+ffdshow, the AR changes (slightly bigger black bars at top and bottom of video), but the window doesn't change its size. If I manually seek to the beginning of the sample, then window size changes (vertically, much bigger black bars). In both cases AR is wrong.
When using MPC's internal decoder, the same happens as with VMR7 (AR stays the same throughout the sample).

Dr Pizza

25th March 2007, 14:21

Install InnoSetup, then open the bin\distrib\InnoSetup\ffdshow_installer.iss file with it and compile it.

Dunno if that works out-of-the-box for x64, though.

OK, I'm trying that.

I'm not sure I like the look of the install script, though. It looks like it wants to include app manifests and some other detritus, which doesn't seem right; one, because the manifests are all hardcoded to use x86 dependencies (which isn't right for x64, obviously), two, because they should all be embedded anyway (VC8 embeds manifests by default).

I'm also not compiling anything with gcc; according to the setup script this can cause problems due to the VC8 runtime without the VC8 redist installed (i.e. using private assemblies). I'm not bothered about that, to be honest; it doesn't seem particularly onerous to require people to install the redist. There is a small gotcha; the redist on MS's site hasn't been updated for VC8 SP1 (or at least, wasn't when I last checked).

To address that, I will try embedding the VC8 SP1 redist into the installer, though I don't know how to make sure it does stuff in the right order; it needs to run the redist install before it tries to regsvr32 the .ax.

haruhiko_yamagata

25th March 2007, 15:08

OK, I'm trying that.
...
two, because they should all be embedded anyway (VC8 embeds manifests by default).

It's embedded, none the less, Windows Xp32 requires external manifest to get Xp visual style work. Vista does not have this bug. I don't know about Xp64.
I'm also not compiling anything with gcc; according to the setup script this can cause problems due to the VC8 runtime without the VC8 redist installed (i.e. using private assemblies). Why do you think so? The installer has been tested and works. What's wrong with using private assemlbies?

If you want to install VC8 SP1 redist, you have to uninstall VC8 sp- redist (when I tested before, sp1beta). I don't think it's a good idea.
I'm not bothered about that, to be honest; it doesn't seem particularly onerous to require people to install the redist.Maybe true with x64 builds, x64 users are experts.

//EDIT
As for x64, ffavisynth.dll may require shared assembly or private assembly for it's own directory. In win32, it's compiled by MSVC7, but in x64, MSVC7 can't compile.

fastplayer

25th March 2007, 15:24

It's embedded, none the less, Windows Xp32 requires external manifest to get Xp visual style work.
They can be external or internally embedded as a resource.
I don't know about Xp64.
Changing the line processorArchitecture="X86" to processorArchitecture="*" worked when I was .NETting a while ago...
If you want to install VC8 SP1 redist, you have to uninstall VC8 sp- redist (when I tested before, sp1beta).
Can somebody upload the VC8 SP1 redist? I can't find it on microsoft.com...

haruhiko_yamagata

25th March 2007, 15:42

They can be external or internally embedded as a resource.
Well, just install a build using MSVC8, remove ffdshow.ax.manifext and launch the dialog, you'll find Xp visual style is gone even though ffdshow.ax have a proper embedded manifest as a resource. I think it's a bug of Xp. The manifest loading CRT is processed properly in Xp without external manifest. So Xp requires both embedded and external manifest.

As for the AR problem, I found a similar problem using VMR9 renderless-mixer mode(MPC).

fastplayer

25th March 2007, 15:47

clsid

25th March 2007, 16:28

Dr Pizza

25th March 2007, 16:34

It's embedded, none the less, Windows Xp32 requires external manifest to get Xp visual style work. Vista does not have this bug. I don't know about Xp64.
I don't think that should be the case; I'm sure I've seen themed programs that use only an embedded manifest, just as long as the manifest is correct. The manifests

Why do you think so? The installer has been tested and works. What's wrong with using private assemlbies?
They're hard to patch for e.g. security updates.

If you want to install VC8 SP1 redist, you have to uninstall VC8 sp- redist (when I tested before, sp1beta). I don't think it's a good idea.
Is that actually true, and if it is true, is that actually a problem? None of my VC8 programs have broken since installing VC8SP1, and my SxS directory seems to have both RTM and SP1 runtime libraries, so I think they can coexist fine.

As for x64, ffavisynth.dll may require shared assembly or private assembly for it's own directory. In win32, it's compiled by MSVC7, but in x64, MSVC7 can't compile.
How would I test that?

The only thing I've found that's obviously broken in x64 is the OSD; the display is completely corrupt. This isn't new, though; the old ffdshow x64 build has the same problem, so whatever's broken has been broken for many months.

Dr Pizza

25th March 2007, 16:36

Where can I get a VC8 build of ffdshow? Your builds are not available anymore on sourceforge...

Edit: Found one on http://ffdshow.wyrdic.net/.
Edit: Regarding the VS problems. Please check out 6th post here:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=144703&SiteID=1

Ah, I only ever build unicode programs (multibyte just needs to go away and die), so I guess I've always had the right manifests embedded correctly.

Dr Pizza

25th March 2007, 16:42

I will make some adjustments to the install script so that it can be used to install 64-bit binaries.

Compiling libavcodec with MSVC will probably produce a partially broken binary. Certainly if some asm code must be disabled. There are also two ToDo's that need to be fixed in ffv1.c

The TODOs are commented out, because CONFIG_ENCODERS isn't defined in the project.

Both TODOs relate to C99 VLAs; there are other places in libavcodec that uses them, only they're *not* commented out. I don't think fixing them should be too hard; finding them might be trickier.

fastplayer

25th March 2007, 16:44

AFAIK, Haruhiko's builds were all ANSI. That could explain the manifest issue (see link above or here (http://www.codeguru.com/forum/showthread.php?t=386815&highlight=manifest))
It's all so much easier in a managed environment though :D

clsid

25th March 2007, 17:24

The TODOs are commented out, because CONFIG_ENCODERS isn't defined in the project.

Both TODOs relate to C99 VLAs; there are other places in libavcodec that uses them, only they're *not* commented out. I don't think fixing them should be too hard; finding them might be trickier.
CONFIG_ENCODERS gets defined in config.h

I have updated the install script to support 64-bit installation.

Dr Pizza

25th March 2007, 17:30

CONFIG_ENCODERS gets defined in config.h
Weird. Maybe the IDE is getting confused, 'cos it's adamant that it's not defined. Not the first time IntelliSense loses touch with reality, of course. Anyway, I think I have put together some code that accommodates the lack of VLAs in VC8. Though I'm not 100% sure, as I totally hate C array/pointer declaration syntax.

Dr Pizza

25th March 2007, 17:53

Do VFW files really need to go in system32 and not the app dir?

Dr Pizza

25th March 2007, 18:12

Can somebody upload the VC8 SP1 redist? I can't find it on microsoft.com...

x64:
http://www.file.am/d/file/vcredist_x64.exe/
x86:
http://www.file.am/d/file/vcredist_x86.exe/

fastplayer

25th March 2007, 18:21

x64:
http://www.file.am/d/file/vcredist_x64.exe/
x86:
http://www.file.am/d/file/vcredist_x86.exe/
:thanks:

clsid

25th March 2007, 18:34

Do VFW files really need to go in system32 and not the app dir?
It is allowed to put it anywhere you like. However some applications might assume it is always located in system32. This could lead to some problems. But putting it in the appdir would make the runtime issue a bit less complicated.

In the registry section you need to replace "ff_vfw.dll" with "{code:GetShortName|ExpandConstant('{app}\ff_vfw.dll'))}"

Leak

25th March 2007, 18:39

Okay, here's yet another updated version of my patch:

Download (http://leak.no-ip.org/AviSynth/ffdshow/) (MSVC build)
Patch (https://sourceforge.net/tracker/index.php?func=detail&aid=1676882&group_id=173941&atid=867362) (against rev. 1074)

I've added an AviSynth info item to ffdshow's OSD, which shows the number of back and ahead buffers used since the last reset (i.e. stop, seek, size change or similar); that should help a bit with finding the correct settings. It also shows the input frame number that's considered "current" for the generated frame and the frame numbers that were requested by the AviSynth script to produce it.

If the current settings are too small it doesn't really matter, unless the filter doesn't work right if it doesn't get the frame it really requested. In that case, just up the buffers a bit and see what happens. Also, seeking around in the stream and/or letting it run for a bit might help finding edge cases where the script needs more frames.

(Note that those values will go up when the buffers are flushed at the end of an MPEG2 stream, but that's because there is nothing left to be buffered and can be safely ignored.)

The values can also be logged to a CSV file by checking "Save to" in ffdshow's OSD options.

The buffer defaults were changed to 0/10/0 and Apply Pulldown is turned off by default for backwards compatibility, but of course at those settings it also doesn't really support (pseudo-)random access - but the OSD info should make tweaking the buffer settings a lot easier... :)

I've also added some code to reset AviSynth on a BeginFlush on the DirectShow video input pin to work around a DVD Navigator bug where seeking doesn't cause an onSeek event, and without knowing that the stream was seeked the frames that were buffered before the seek get processed and played after the seek at full tilt, which looks weird and eats extra CPU time.

@haruhiko:
I've added an onFlush method in Tfilters and Tfilter, since that is the easiest and probably cleanest way to handle this (at least concerning the amount of code that needs to be changed and/or checked), although like you said doing anything in them other than flagging that there was a flush is probably a bad idea due to race conditions that may occur then. The flush itself is then handled when process() is next called.

np: Christ - Vernor Vinge (Blue Shift Emissions)

Leak

25th March 2007, 18:45

Oh yeah, I noticed that (at least) the outline strength and radius sliders on the OSD font configuration page always get reset to 0 as opposed to reflecting the current settings.

marcellus

25th March 2007, 19:10

Hi
I use ffdshow for to encode to mpeg2 (the great libavcodec encoder). I live in a PAL country so I usually encode to 25 fps framerate. But recently I tried to encode some Quicktime trailers (the 300 movie taken from Apple site) and I get in VDub an error:
Cannot start video compression:
An unknown error occured (may be corrupt data).
(error code -100)
After much trial and error I come to the conclusion that the framerate is the culprit. This Avisynth script works well:
Blackness(300,640,480,"yv12",25)
but this one gives the error:
Blackness(300,640,480,"yv12",23.976)
I noticed that encoding to mpeg4 gives the error too. I tried several ffdshow versions, including latest beta 2a and latest icl9 build, with the same result.

clsid

25th March 2007, 19:16

Read the first post of this topic for the answer.

marcellus

25th March 2007, 19:37

I see.
:thanks:

Any ideea, can be fixed in the future? Not that it can't be worked around the way it is now, I can change fps in avisynth to 25 fps an then change it back in restream but would be nice to work with any input framerate.

cc979

25th March 2007, 20:13

after further tests using xvid anamorphic clips with ffdshow rev1069

this is what happens with AR changes in avi's and mp4's

http://www.mytempdir.com/1269513

test1 = anamorphic-source.avi+xvid-par16x9-dar1x1.avi
test2 = anamorphic-source.avi+xvid-par1x1-dar16x9.avi

in vlc

xvid-par16x9-dar1x1.avi: AR works
xvid-par1x1-dar16x9.avi: AR works
container16x9-bitstream5x4.mp4: AR works
container-unspecified-bitstream16x9.mp4: AR works
test1: AR works
test2: AR works

in mpc/ffdshow

xvid-par16x9-dar1x1.avi: AR does not work
xvid-par1x1-dar16x9.avi: AR does not work
container16x9-bitstream5x4.mp4: AR works
container-unspecified-bitstream16x9.mp4: AR works
test1: AR does not work
test2: AR does not work

not sure if the naming scheme is correct, using xvid using the 2 types of 16x9 - 1 using PAR 16/9 and other DAR 16/9

and the mp4's i used yamp and told it to use DAR 16/9

cheers all

ps. using render overlay/haali/vmr9-renderless
but with vmr9-windowed all is fine