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

Socio

14th November 2005, 01:48

Egh

14th November 2005, 03:31

Is there a trick to get Virtualdub to show up in ffdshow?

During ffdshow installation I have tried pointing it to the main Virtualdub folder and to the Virtualdub plugin folder but either way it does not show up.

I am currently running ffdshow version ffdshow-20051111 if that helps.

It should be there. Both as an encoder (that's natural, ffdshow has vfw plugin so it should appear not only in vdub) and as an image processing filter (that what you need plugin for). Make sure you operate in RGB32 [Full Processing] mode in vdub first. And the name of the plugin as it appears in vdub filters list will be ffvdub, not ffdshow :P

And, the last but not the least, you need ffvdub in plugins folder, not main program one.

Liisachan

14th November 2005, 13:04

Audio decoder config box says "low accuracy mode enable(d)" for Vorbis.
Does anyone know what this "low accuracy mode" is and if it is possible to disable (?) it to make it high-accuracy?

celtic_druid

14th November 2005, 13:10

Commenting out #define _LOW_ACCURACY_ in os_types.h should do it. You could also use libavcodec instead of termor.

Leak

14th November 2005, 13:44

Is there a trick to get Virtualdub to show up in ffdshow?

During ffdshow installation I have tried pointing it to the main Virtualdub folder and to the Virtualdub plugin folder but either way it does not show up.
Ummm... if you really mean that you want to use VirtualDub's filters in ffdshow - that's not possible.

What this does is install a VirtualDub plugin to use ffdshow's filters in VirtualDub...

Liisachan

14th November 2005, 14:07

Commenting out #define _LOW_ACCURACY_ in os_types.h should do it. You could also use libavcodec instead of termor.
Thanks for the tip. I get a small but noticeable bzzzzzz noise when decoding vorbis in a specific OggFile by "termor", so I have to say "termor" is not as good as CoreVorbis. However, using libavcodec in ffdshow as vorbis decoder fixes the problem too.

celtic_druid

14th November 2005, 14:28

http://celticdruid.no-ip.com/test/ff_tremor.7z
compiled without #define _LOW_ACCURACY_

Liisachan

14th November 2005, 16:12

Thank you very much :) This sure fixes the problem.
I also ABXed 2 WAVs I got by:
Vorbis Decoder (ffdshow) -> WavDest -> .wav
using tremor, 20051103 normal against ff_tremor replaced,
and got 14/15. So _LOW_ACCURACY_ makes the decoded result significantly low-quality
at least in this specific sample.

EDIT
Still I think both tremor and libavcodec are not as reliable as CoreVorbis.

canuckerfan

15th November 2005, 03:54

shouldn't ffdshow get its own sub forum? it's hard keeping a track of everything ffdshow-related on one thread.

esby

15th November 2005, 09:01

@canuckerfan:
Your question is a recuring troll.
There were two ffdshow related thread, one got closed when the second was opened, the problem being that the thread was too long to be followed by 'new user'.
The second got closed some months ago in the goal of having the respective problem threated in the corresponding parts of the forum.
In theory, this thread should only talk of availability of the (recent) builds and their inner changes.
Now I don't want to enter the 'troll'.

esby

_xxl

15th November 2005, 11:35

http://cutka.szm.sk/files/ffdshow-20051115.exe

yester

15th November 2005, 11:40

ExtraEye

15th November 2005, 14:27

http://cutka.szm.sk/files/ffdshow-20051115.exe
no SSE or SSE2?

thuan

15th November 2005, 16:15

icl8 so SSE and SSE2 should be supported

bob0r

15th November 2005, 20:03

hello ffdshow fellows,

want to post an bugreport...

since the mid 2005 every new ffdshow alpha build crashes on my k6-2+ in the libavcodec (regardless which build)... ffmpeg lib was not affected but later removed ... so i want to ask if the developers (celticdruid?) may take an look into this topic ... (perhaps some problem with the 3dnow+ support without extended mmx support like athlon on the k6-2+ & k6-3+)

some other k6 or k6+ user got this problem?

Although celtic_druid is a great coder, he is not the ffdshow developer.

Please report your bug to the ffdshow developer straight, via source forge, here is the link:
http://sourceforge.net/projects/ffdshow
Bugs (report it here):
http://sourceforge.net/tracker/?group_id=53761&atid=471489

@all
Hmm, sourceforge has new outlook, CVS is still out-to-date though :(
Updating layout when your servers are slow and out-to-date to start with, who ever manages sourceforge, needs to be updated aswell :cool:

Egh

15th November 2005, 22:04

hello ffdshow fellows,

want to post an bugreport...

since the mid 2005 every new ffdshow alpha build crashes on my k6-2+ in the libavcodec (regardless which build)... ffmpeg lib was not affected but later removed ... so i want to ask if the developers (celticdruid?) may take an look into this topic ... (perhaps some problem with the 3dnow+ support without extended mmx support like athlon on the k6-2+ & k6-3+)

some other k6 or k6+ user got this problem?

are you sure you tried fully ICL build? I mean those recent daily builds from milan cutka himself. I believe those should support the biggest range of CPUs. most likely it's "shuffle" command iirc there was one bug related to that already. try browsing thru bugtracker.

btw, ffdshow now uses 3DNow! in a very limited way, and probably that is already redundant due to sse/sse2 support on all good more or less modern processors :)

Egh

16th November 2005, 14:43

http://www.torrentspy.com/directory.asp?mode=torrentdetails&id=449079&query=ffdshow
k6-2 cpu's maybe...

if chap previously tried full MSVC build from movax or b0b0r (he says he tried most latest builds as I understood) then this one will be no difference.

Though slow, I think MSVC builds should have no problems on K6-2. Test it and report :P

bob0r

16th November 2005, 20:54

ffavisynth compileable with GCC
http://cia.navi.cx/stats/project/ffdshow/.message/6426679

Yet this is not the case.
CVS finally updated and i tried to make a new build.

I have reported this bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=1358380&group_id=53761&atid=471489

My plan was to compile ffdshow-20051116-x264.nl.exe :sly:

Egh

16th November 2005, 23:10

ffavisynth compileable with GCC
http://cia.navi.cx/stats/project/ffdshow/.message/6426679

Yet this is not the case.
CVS finally updated and i tried to make a new build.

My plan was to compile ffdshow-20051116-x264.nl.exe :sly:

The explanation might in fact be quite simple -- it hasn't been updated yet :P
I mean CVS on SF. Last entry there is 32 hours ago (from atm, naturally), whilest there were two more entries after that (gcc compilation and DCT filter). Those are not shown at http://cvs.sourceforge.net/viewcvs.py/ffdshow/ffdshow/src/?sortby=date
but shown at http://cia.navi.cx/stats/project/ffdshow .

bob0r

16th November 2005, 23:56

Nah you are wrong here

http://cvs.sourceforge.net/viewcvs.py/ffdshow/ffdshow/src/imgFilters/?sortby=date

Is indeed updated. (finally (?) fixed DCT filter is the last update)

The files are updated, but something is broken.

Next build will have new filename, with even more info:
ffdshow-2005xxxx-gcc4.0.2-sse-x264.nl.exe

I also added

!define COMPRESSION "/FINAL /SOLID lzma" (instead of !define COMPRESSION lzma) which creates a smaller file.

Now we just have to wait for Milan to fix this bug and a new GCC build will be online ;)

_xxl

17th November 2005, 09:36

Best GNU License executable file compression and decompression utility that supports many executable file formats is UPX.It can be used for FFdshow.ax
and *.dll.
30-70% compression ratio!
upx.exe --best ffdshow.ax 2,883,584 bytes---upx=879,104 bytes
ratio 30.49%
upx.exe --best libavcodec.dll 2,674,176 bytes---upx=914,944 bytes
ratio 34.21%

madman1980

17th November 2005, 10:27

Is there any chance you could make these settings default in future ffdshow builds?

http://img108.imageshack.us/img108/66/ffdshowanamorphicoverlaysettin.png

It enables the aspect ratio to change to the ratio specified in the file, which might be different from the ratio according to the pixel ratio. This should really be natural behavior, just look at MPEG2, both DVD and SVCD data need the aspect ratio info to play correctly. I have a big problem now with divx/xvid files that have big black bars vertically and horisontally and look really squeezed.

I would like to repeat this request. If anyone has any idea how I can reach the developers to get an answer that would be great too. Tried mailing milan at the address in the ffdshow about box, but I've heard nothing.

signatory

17th November 2005, 10:43

I would like to repeat this request. If anyone has any idea how I can reach the developers to get an answer that would be great too. Tried mailing milan at the address in the ffdshow about box, but I've heard nothing.

You seem to have a special reason for this that not many would care about :) I would suggest you save your own ffdshow.reg registry settings and include it in your own install package or some other way.

celtic_druid

17th November 2005, 10:53

The nsi script could easy be changed to do it.
If you use upx, then the installer will most likely be larger.

cc979

17th November 2005, 12:36

I would like to repeat this request. If anyone has any idea how I can reach the developers to get an answer that would be great too. Tried mailing milan at the address in the ffdshow about box, but I've heard nothing.

what do you use to play videos, if mpc do you have touch from inside enabled on video frames options?

videomixer9

17th November 2005, 13:12

Do we really need to compress the ffdshow.ax and libavcodec.dll? My expierence is that compressing especially files build as dll introduce strange behaviour when they are compressed. Besides I don't think ppl got that less disk space nowadays, and the installer shouldn't be affected if you compress these files as it does pretty good compression itself.

dimzon

17th November 2005, 13:15

Do we really need to compress the ffdshow.ax and libavcodec.dll?
No! Please, stop compressing this files!

Inventive Software

17th November 2005, 13:22

The nsi script could easy be changed to do it.
If you use upx, then the installer will most likely be larger.
Not necessarily. The installer uses compression as well. UPX is streamlined for executables, LZMA is uniformly available for all file types. By using UPX on the already compressed installer, you are only getting a small payback with UPX. By using UPX on the components it supports and then using a suitable compression technique, you may well have more compression.

This is just theory, and my theories are usually flawed! :D

dimzon

17th November 2005, 13:51

Not necessarily
Wrong!

madman1980

17th November 2005, 13:59

what do you use to play videos, if mpc do you have touch from inside enabled on video frames options?

Yes I do, but this does not take into account the aspect ratio that is defined in the divx/xvid file if that is different from the resolution AR.

celtic_druid

17th November 2005, 14:02

If you UPX the ax/dll's then the installer won't be able to do as good a job at compressing them, so overall the filesize should go up, one installed though it will take up less space. Part of the installer is compressed with UPX by the way.

madman1980

17th November 2005, 14:03

You seem to have a special reason for this that not many would care about :) I would suggest you save your own ffdshow.reg registry settings and include it in your own install package or some other way.

No, the reason is not special. The reason is something that everyone should care about. If an aspect ratio is specified in a xvid/divx file, it is not used with ffdshow by the default. This is what I want to change. If an AR is specified in the file, it usually is for a good reason. Take a look at SVCD, it would be unwatchable unless the decoder took the specified AR into account as its resolution is 480x480 or 480x576 while the AR is 4:3 or 16:9. I want ffdshow to do the same with divx/xvid that is not encoded in a way where resolution AR corresponds to the AR of the material. You see?

kurt

17th November 2005, 15:19

madman1980 is right - "overlay mixer" and "allow output format changes during playback" should be default...

if you do anamorphical encodes and set the AR to 16:9 (for example in mmg) ffdshow doesn't read the flag properly with default settings (mpc, zoomplayer, tcmp....).

I think various people use ffdshow like that...

marcellus

17th November 2005, 15:41

You seem to have a special reason for this that not many would care about :) I would suggest you save your own ffdshow.reg registry settings and include it in your own install package or some other way.
I agree with signatory.
@madman1980:
Make the changes you like, click on 'Export all settings', save ffdshow.reg somewhere and double click it whenever you install a new ffdshow version. That would be all.

I think a debate on what setting should be default or not in ffdshow would take forever and has no point. Anybody can make his own 'default' settings.

Egh

17th November 2005, 15:55

Generally speaking, compressing .exe/.dll files is quite stupid idea nowadays. It saves disk space a bit, but doesn't save you memory usage :)

in fact it likely uses more system memory than without it!

And there were several problems with UPX on XP SP2 systems. So better drop this idea :) Though who is interested may simply pack .ax/.dll himself.

madman1980

17th November 2005, 16:06

I agree with signatory.
@madman1980:
Make the changes you like, click on 'Export all settings', save ffdshow.reg somewhere and double click it whenever you install a new ffdshow version. That would be all.

I think a debate on what setting should be default or not in ffdshow would take forever and has no point. Anybody can make his own 'default' settings.

Why? If you think debate is useless you at least have to say why. You present no reasoning whatsoever, so I can't even tell if you know what the issue is. Can you name one disadvantage enabling this setting would have?

I have explained why this setting would be useful, and in fact, I can't see any disadvantages to it. If a setting for AR is stored in a divx/xvid file, it is intended to be used, and that's what I want. This will benefit everyone.

I've been using this setting without problems for a good while now, while not using it gives me problems with the files that are not encoded with a pixel resolution that correspond to the AR, like the anamorphic example kurt reffered to.

celtic_druid

17th November 2005, 16:12

Maybe Milan knows of a reason? Could be that he didn't make it default for a reason.
It isn't hard to change the settings anyway though. Couple of mouse clicks and you are done.

No reason why others can't edit the nsi script for their builds though to make it default.

madman1980

17th November 2005, 16:19

celtic_druid

17th November 2005, 16:23

Try: http://sourceforge.net/tracker/?group_id=53761&atid=471489

madman1980

17th November 2005, 16:31

Thanks, I'll submit a request.

signatory

17th November 2005, 19:43

Yep, I'd very much like to know what he (is he the lead (or only) developer?) has to say, but I haven't been able to get an answer.

It's very easy to enable the setting manually, but I've still yet to find out a good reason why it shouldn't be enabled by default, so that's why I'm asking about it. Why should we really have to? I'd be really glad to see a build with it if it is confirmed that there are no problems.

I think there is a way to resolve this issue in a excellent way for all of us. Personally I don't want it as default.

But hopefully milan will go with a checkbox option for these overlay settings in the installer. Just like there are checkboxes for what formats and filters to use. And then as one would install updated packages the settings would be pre-selected.

Revgen

17th November 2005, 21:54

Tried mailing milan at the address in the ffdshow about box, but I've heard nothing.

The last time I emailed Milan he responded in about 3 days. When did you last email him?

esby

18th November 2005, 11:15

Well about the upx discussion:
Since the installer is compacted, you'll gain no space on it if you compact the executables with the same type of compacting algorithm.
The only gain you could have is if the algorithm used for compacting the executable is better than the one used for the executable, in fact, it will not happend, they both are at the same level.
Now the real question is: Do we want smaller executable installed? I would say it does not matter anymore, space is never a problem now. Now something that could be done (in theory) is putting a dialog option, add upx to the installer, and compact the executables installed during the installation, if the user wants to install executables in their compacted form.
Now for the upx 'problems' with executable, the only problem I encountered with exectutable is when accessing resources with hackish method, since the exe is compacted, the hackish methods will most likely not work properly, for example, try reading a string from the executable resource, while acessing the exe, you'll most likely end with a different result than what you were expecting.

esby

madman1980

18th November 2005, 14:01

https://sourceforge.net/tracker/?func=detail&atid=471489&aid=1359113&group_id=53761

Got a reply!

signatory: Still you haven't said why you don't want is as default. Is it too much to ask why? I'd like to learn more about it, and they way you wrote it seemed it was because of you personal preference, not because you thought it would introduce bugs. I'd like to hear why you don't want it regardless.

An option during the install process would be great, but I still don't see any disadvantages (except perhaps technical ones that can be sorted out) why it shouldn't be default. So please enlighten me.

bob0r

18th November 2005, 18:30

http://sourceforge.net/docs/A04/

( 2005-11-16 05:35:18 - Project CVS Service ) As of 2005-11-16 the sync between developer and anonymous CVS services is still disabled. This is as a result of a hardware failure that we are actively working on, and the sync will be restarted as soon as the hardware issues are resolved.

I just compiled ffdshow-20051118-gcc4.0.2-sse-x264.nl.exe, and ffavisynth compiling works again.
(updated to: dynamically link avisynth.dll from ffavisynth - http://cia.navi.cx/stats/project/ffdshow/.message/6451522)

Two more updates:
- option to connect to any filter but allow output format changes only on supported ones - a new default
- fast SPP deblocking

My build worked, but i'd like to include these last 2 updates (and possible more if CVS stays out-to-date again)
But the update 'dynamically link avisynth.dll from ffavisynth' was today, so with any luck, a new build soon!