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

MatMaul

3rd November 2006, 16:28

The newest FFdshow on ffdshow.info is rev490 by drevil_xxl

The rev I need to test the new dialong is rev492.
I'm hoping rev494 will be released today, as MatMaul made me curious.

Sorry but I have just compiled libavcodec.dll because rev494 have h264 decoding improvement, and not ffdshow.ax to do this test.
So waiting a new build of drevil_xxl or clsid.

clsid

3rd November 2006, 17:15

Most of the H.264 decoding improvements were already done before rev. 490. But I'll put a new build up in a moment.

@Haruhiko, can you increase the width of the 'Format' and 'Supported ...' columns a bit on the codecs page?

Jeremy Duncan

3rd November 2006, 20:04

The new dialong looks nice.

And rev494 is faster.

Bathrone

4th November 2006, 00:06

How do I check what changes are in the ffmpeg builds. When I look on the ffmpeg svn in changelog.txt it doesnt have the related build numbers that the ffdshow changelog references.

Also, why is flac decoding not present in all the installer builds? And ones that do have it, it's not installed by default?

4th November 2006, 01:47

I have made a little test to mesure the h264 decoding speed improvement.

ffdshow rev2546 : 104 fps
ffdshow-tryout rev494 : 130 fps (!!)

+25% speed-up !!

Great job and thanks to ffmpeg guys !
I don't see such big improvement before, is someting dramatically change in rev 494?
H.264 1080p

ffdshow-20060604-rev2546.exe
Overlay VMR9
fps dfps fps dfps
19,6 19,3 16,8 15,6
ffdshow_rev420_20061020_clsid.exe
20,6 20,2 20,3 19,1
Overlay VMR9
fps dfps fps dfps

Eragon4ever

4th November 2006, 12:18

How do I check what changes are in the ffmpeg builds. When I look on the ffmpeg svn in changelog.txt it doesnt have the related build numbers that the ffdshow changelog references.

When I checked the svn I can say "show log" in my svn client. (TortioseSVN)
It is not in the changelog file.

clsid

4th November 2006, 12:39

I don't see such big improvement before, is someting dramatically change in rev 494?Nope, there have been several revisions with small performance updates.

4th November 2006, 15:36

Nope, there have been several revisions with small performance updates.
Ok, I'll test it in 3 or 4 hours...

clsid

4th November 2006, 17:56

List of known issues in revision 513:

1) Wavpack decoder only works with lossless wavpack. Lossy and hybrid wavpack is not yet supported.
2) Levels (ylevels, ylevelsG, ylevelsS, ylevelsC) are not implemented correctly. Details about the correct way can be found here (http://forum.doom9.org/showthread.php?p=897854).

Reported but unconfirmed bugs:

3) image settings -> preset autoload conditions -> "on FOURCC match" doesn't work. (reported by juskixxx) (confirmed by clsid) (haruhiko could not reproduce it)
4) Automatic preset loading doesn't seems to be working with on "number of channel match" and AC3 audio on DVD (don't know if it happens with AC3 audio in MKV, AVI or not or any other audio format). I use "3;4;5;6" in "number of channel match" so this should load with audio track with more than 2 channels but with an AC3 2 channels track this is also loaded. (reported by thuan)
5) The following encoders do not work for me: MPEG 4, MPEG 1, MPEG 2, h.263, H.261 and DV. VirtualDub 1.16.16 gives the following error: "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100)". I know that at least some of these encoders do work for others. My system specs: Windows 2000, AMD Athlon Thunderbird. (reported by clsid)
6) Resize filter alters colors. Details (http://forum.doom9.org/showthread.php?p=884778#post884778). (reported by Kador)

Other issues:

7) ICL9 builds of ffdshow.ax crash on files created by a specific old revision of x264 (don't know the rev number). Funny thing however is that the files play without crash if you first play a good file and then play a 'troublesome' file in the same player instance. Also no crash when using an unoptimized debug build. So this seems to be a compiler bug. Sample file (http://rapidshare.com/files/1609924/sample.mp4.html). (reported by clsid)

MatMaul

4th November 2006, 18:49

1) Wavpack decoder doesn't work with this file (http://rapidshare.com/files/1609252/SoC__XviD_WavPack_MP3_-007.mkv.html). (reported by clsid)
After more testing, it doesn't work with all hybrid wavpack files, but I think it's an ffmpeg issue.

EDIT : You have removed vc1 support because it doesn't work.
Can you give me some links of files wich do not work please ?

clsid

4th November 2006, 18:54

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

MatMaul

4th November 2006, 19:07

thanks.
wavpack decoder also doesn't work with 5.1 files.

Liisachan

4th November 2006, 19:32

After more testing, it doesn't work with all hybrid wavpack files, but I think it's an ffmpeg issue.? If using Gabest's splitter, hybrid wavpack doesn't work anyway. Haali's newer splitter works ok with CoreWavpack, which supports hybrid wavpack beautifully. foo_packet_decoder_wavpack too, by using codes from CoreWavpack.

Inventive Software

4th November 2006, 19:33

Potential bug with "Automatic Quality Control" in "Post-processing" tab, as in it's not automatic.
With any previous ffdshow build (not ffdshow_tryout) it's fine, no problems, but ffdshow tryout builds don't have this.
File in question is DivX encoded, and quite post-processing heavy, but with ffdshow builds it's definitely adjusted well. ffdshow_tryouts just don't do this, so something's broken between ffdshow and ffdshow_tryouts.

ffdshow_tryout builds tested include ffdshow_rev494_20061103_clsid (my current build I use), ffdshow-Tryouts-20061023-rev435. Both exhibited said post-processing behaviour.

ffdshow builds tried include ffdshow_rev2543_20060816, ffdshow-20060123, both were fine with automatic post-processing.

Quick note: post processing settings used were 100% strength, mplayer accurate deblocking (and tested with accurate deblocking off).

MatMaul

4th November 2006, 19:41

If using Gabest's splitter, hybrid wavpack doesn't work anyway. Haali's newer splitter works ok with CoreWavpack, which supports hybrid wavpack beautifully. foo_packet_decoder_wavpack too, by using codes from CoreWavpack.
I haven't any problem with splitters, I think it's just ffmpeg wavpack decoder actually doesn't support hybrid and 5.1 wavpack files.

Liisachan

4th November 2006, 20:30

Gabest's splitter does split A_WAVPACK4 in mkv, but the "correction" part--if it exists--is ignored and the downstream receives the lossy part only. Note, if the lossy part is transparent (enough high bitrate) you can't tell this problem by just listening to the output. It's not like it doesn't play. It's not bit-identical like it should be. So, if you use Gabest's splitter or MPC's internal splitter, hybrid wv packed in mkv won't play as lossless even if the wavpack decoder knows how to handle the hybrid. More specifically, altho CoreWavpack can decode the hybrid, it plays the hybrid as Lossy if the upstream is Gabest's splitter.

In this case, tho, it seems that the decoder in ffdshow doesn't like the hybrid either.

Anyway, to test that sample file above, the upstream splitter should be Haali's. That's what I meant. As another note, wv+wvc in matroska would be practically pointless. If you'd like to make the audio in mkv lossless, you can just use lossless WV in the 1st place.

On the other hand, if ffdshow's audio decoder can decode foo.wv+foo.wvc (bare 2 files, not packed in matroska), that may come in handy for some users. But then again, that would mean ffdshow has to look for .wvc in the same folder whenever it plays lossy .wv... I'm not sure if its worth even bothering to do so.

foxyshadis

4th November 2006, 20:42

Potential bug with "Automatic Quality Control" in "Post-processing" tab, as in it's not automatic.
With any previous ffdshow build (not ffdshow_tryout) it's fine, no problems, but ffdshow tryout builds don't have this.

Yes, this was mentioned before, it's most likely because cpu usage has been broken for some time. Unfortunately so far there's no good way to make it work on x64 XP/Vista, without crashing, so it was disabled. If a better method's found, I'm sure it'll be back, but I don't know all that much about WMI.

(Another method is to work that into the QoS system, but the reason I stalled on finishing that is Haali's renderer doesn't send Quality messages, like the windows ones, since ffdshow used to work very badly with them.)

@Everyone: How about releasing a build considered "Stable" at this point?

MatMaul

4th November 2006, 20:48

ok, I understand.
But actually, ffdshow doesn't decode at all the lossy part, so I think ffmpeg library also can't decode a lossy+correction file.

_xxl

4th November 2006, 20:59

@Everyone: How about releasing a build considered "Stable" at this point?
There are known bugs that need to be fixed before the first beta is released.

Inventive Software

4th November 2006, 21:04

@Everyone: How about releasing a build considered "Stable" at this point?
Keep with revisions in my opinion.

Question: how does CPU usage affect the automatic post-processing? That seems like an ineffective way to adjust it IMO. Surely the best way is analysing the image for blocks and adjusting as appropriate?

clsid

4th November 2006, 21:23

That would mean to do some form of post-processing to determine if post-processing is required :P

In old builds auto pp would adjust the amount of pp depending on the current cpu load. The cpu load monitoring code is not used in new builds because it fails on Vista.

foxyshadis

4th November 2006, 21:35

There will always be known bugs, that's the nature of software. Currently, most of the bugs since the last big releases of ffdshow are long gone, performance has risen, and the lack of "stable releases" that don't have disruptive new codecs and features will keep it from being used by many who'd benefit from it.

Inventive: This was all designed back when the P3 was common, and cpu usage was a major problem. PP basically hasn't changed since then, aside from the now-removed h.264, and SPP. The deblocking itself will use the quant to estimate blocks (thus its terrible performance on raw sources), but if you want real analysis you need to use SPP, but it will be slow and kind of fuzzy. ffdshow, ffmpeg, mplayer, and so on have nothing similar to Deblock_QED, sadly.

But ffdshow does have avisynth input. ;)

ExtraEye

4th November 2006, 22:37

sorry but what is "Deblock_QED"?

foxyshadis

4th November 2006, 23:04

An Avisynth filter, you should be able to search the board for it. The wiki isn't up or I'd link to the page for it.

yesgrey

4th November 2006, 23:43

I think ffdshow misses one thing in the resize dialog: the option to resize to screen size.

I use two screens for seeing my stuff: a projector and a monitor. Since both screens have different resolutions, I have always to change the resolution by typing the new one. It would be easier to just set it to screen size and then ffdshow get it and resize to it. Even better if we could also set the aspect ratio, then ffdshow should only use the screen width as the reference.

Something like this:

Resize:
- Specify Size (already done)
- Specify Aspect Ratio (already done but I think it's not very usefull, since it keeps the original width of the file, and then the resize have to be done by the videocard drivers)
- Expand to Next Multiply of (already done)
- Multiply by (already done)
- Screen Size (to be done)
Aspect Ratio (drop list: original; 4:3; 16:9; 2.35:1)

Or it could just be incorporated in the Specify Aspect Ratio.

I think this is a very important feature, because the resize by ffdshow is of a better quality than the resize of the videocard drivers.

Let me know what you think.

Bathrone

5th November 2006, 01:05

Not a bug, but why if flac not installed by default? And I know one installer atleast doesnt seem to offer it during installation as an option.

bob0r

5th November 2006, 02:08

x264.nl added clsid ffdshow revision 497.

I must say i am amazed, using only one core of my Intel D930, a BBC-HD H.264 1080MBAFF sample almost runs smooth (enabled the "no deblocking tweak" ofcourse, but same for coreavc)

If ffmpeg would use multi core/cpu code i am sure it could match, or even surpass all the other H.264 decoders.

Isochroma

5th November 2006, 02:50

Unicode characters in filenames played with MPC & ffdshow show in the ffdshow dialog as ?

5th November 2006, 04:08

5th November 2006, 04:18

Some speed comparsions with ffdshow (previous results was on other system with slower cpu)
Video - cornell_m1080p.mp4, H.264, 1920x1080, 8634 kbps

fps vmr9 overlay
ffdshow_rev135_20060904_icl91 33.4 32.8
ffdshow_rev420_20061020_clsid 33.4 32.8
ffdshow_rev482_20061101_clsid_icl9 33.3 32.8
ffdshow_rev494_20061103_clsid 33.4 33.0

Video - kane_reveal_1280x720_h264.mp4, H.264, 1280x720, 2255 kbps

fps vmr9
ffdshow_rev135_20060904_icl91 117.5
ffdshow_rev420_20061020_clsid 120.3
ffdshow_rev482_20061101_clsid_icl9 119.5
ffdshow_rev494_20061103_clsid 122.5

Only small speedup in second case, but it's better than nothing....

Egh

5th November 2006, 04:26

I think ffdshow misses one thing in the resize dialog: the option to resize to screen size.

I use two screens for seeing my stuff: a projector and a monitor. Since both screens have different resolutions, I have always to change the resolution by typing the new one. It would be easier to just set it to screen size and then ffdshow get it and resize to it. Even better if we could also set the aspect ratio, then ffdshow should only use the screen width as the reference.

You dont' have to specify AR, or to specify resolution in full.

Only thing required is to specify target width, and leave 0 for height. Then ffdshow automatically applies DAR from video.

An option to resize to current screen resolution would be nice, imo. But some questions arise, for instance, what to do if resolution is not constant during video playback. Should ffdshow use only resolution which it gets on initialisation or readjust it whenever it changes? Multimonitor configuration might also cause some problems.

haruhiko_yamagata

5th November 2006, 12:30

Unicode characters in filenames played with MPC & ffdshow show in the ffdshow dialog as ?
What do you mean? Please tell us the detail.
Whose build are you using? I mean, is it ANSI build or UNICODE build?

Amour

5th November 2006, 13:17

Unicode characters in filenames played with MPC & ffdshow show in the ffdshow dialog as ?
Works fine for me.

yesgrey

5th November 2006, 14:24

Only thing required is to specify target width, and leave 0 for height. Then ffdshow automatically applies DAR from video.

Yes I know this, but it does not work always. Sometimes I have to specify also the height because the video DAR is not correct. It also not solves the problem of having to change the width.

yesgrey

5th November 2006, 14:33

But some questions arise, for instance, what to do if resolution is not constant during video playback. Should ffdshow use only resolution which it gets on initialisation or readjust it whenever it changes? Multimonitor configuration might also cause some problems.

I think we can clear up these situations. It could use the resolution it gets on initialization, since I don't know why (yes, I know someone could) anyone would change the screen resolution in the middle of a file viewing. The multimonitor it's not also a big question, because it could simply get the resolution of the screen in which the media application is opened during the initialization process.

I will try to do it and see how it works...

Egh

5th November 2006, 16:43

Yes I know this, but it does not work always. Sometimes I have to specify also the height because the video DAR is not correct.

Which files are those? Anamorphic resolution AVI? You can try to remux them into mkvs and assign proper DAR that way.

Not that I see much anamorphic avis anyway :P

Inventive Software

5th November 2006, 17:01

I think ffdshow misses one thing in the resize dialog: the option to resize to screen size.
Media Player Classic? It has a "Stretch to Window" option which is appropriate for your needs I think.

Egh

5th November 2006, 17:23

Media Player Classic? It has a "Stretch to Window" option which is appropriate for your needs I think.

The problem is that it's not using ffdshow resizer in that case.
And if you haev high-speed CPU but slow GFX card in terms of shaders (for instance my present system configuration) you can't actually use MPC shader-based bicubic or Haali renderer. Such cards could be, for instance, old FX5xxx series, or moden built-in in the motherboard (like 6100/150 in NForce). Not all computers are built keeping gaming in mind (office computers are one such particular case :D)

So if you are not using ffdshow resizer you're able to use only standard bilinear and for me that's not enough.

Liisachan

5th November 2006, 19:59

Ok, I now know the "problem"--i was mislead by this report:

1) Wavpack decoder doesn't work with hybrid wavpack files. Sample file (http://rapidshare.com/files/1609252/SoC__XviD_WavPack_MP3_-007.mkv.html). (reported by clsid)

The audio in that sample file is Wavpack Lossy, not Wavpack Hybrid. So we can simply say "Wavpack decoder doesn't work," which is much bigger problem than not just supporting Hybrid.

_xxl

5th November 2006, 20:51

Ok, I now know the "problem"--i was mislead by this report:
The audio in that sample file is Wavpack Lossy, not Wavpack Hybrid. So we can simply say "Wavpack decoder doesn't work," which is much bigger problem than not just supporting Hybrid.
This file is working ok.
http://ftp.mplayerhq.hu/MPlayer/samples/A-codecs/lossless/luckynight.wv

MatMaul

5th November 2006, 21:25

Yes it's a lossless 2ch sample and it is the only configuration which works.

Liisachan

5th November 2006, 21:35

That file is Wavpack Lossless, not Wavpack Lossy nor Hybrid.
Wavpack decoder doesn't work generally, not only for Hybrid:

Current ffdshow
Wv 4.3 4.4
Lossy x x
Hybrid x x
Lossless o #

# works, if --optimize-mono is not used

MacAddict

5th November 2006, 22:18

(snip)

An option to resize to current screen resolution would be nice, imo.
(/snip)

That would be great and about the only feature I can think of that I'm missing on my HTPC!

6th November 2006, 04:25

Reported but unconfirmed bugs:
4) Instant crash when trying to play this MSS2 WMV file (http://ftp.mplayerhq.hu/MPlayer/samples/V-codecs/MSS2/mss2_speech.wmv). Happens on Windows 2000. No crash on drevil_xxl's XP system. (reported by clsid)

I tested this file in my w2000 system, in WMP all plays fine (of course), in mpc video plays fine, but without sound.....
I cleared my system from codecs garbage, reinstalled last DX and wmp9, now this file plays normally (sound and video) in mpc and bsplayer, so I think that is problen with system, not ffdshow....

Jeremy Duncan

6th November 2006, 05:50

There's a bug in the Levels Tab.

Didée said that the ylevels, ylevelsG, ylevelsS, ylevelsC.
That Milan Cutka put into FFdshow, wasn't done properly.

He said that what Milan put into FFdshow was exactly backwards and he doesn't recommend using the ylevels, ylevelsG, ylevelsS, ylevelsC in FFdshow.

Here's the thread Didée started that shows how ylevels, ylevelsG, ylevelsS, ylevelsC works and the code it uses.
Link (http://forum.doom9.org/showthread.php?s=&threadid=79898)

May I ask that this bug is fixed and Didée's ylevels, ylevelsG, ylevelsS, ylevelsC is properly implemented into the FFdshow Levels tab. :)