ffdshow development #2

[SeeMoreDigital]

Originally posted by Sirber
Is x2674 updated? Dunno about x2674 my friend ;). But here's what Doom9 says about the changes: - ffdshow 20041003 (http://osdn.dl.sourceforge.net/sourceforge/ffdshow/ffdshow-20041003.exe) contains more than a long page of release notes (https://sourceforge.net/project/shownotes.php?release_id=272514) (as compared to the August 8th release I previously had for download).

We're basically talking about improved MKV and OGM support, various improvements in the subtitle area, support for Nero MPEG4 video, AAC audio support using Nero file source, x264 improvements (a H.264 codec) and the latest libavcodec is being used

Cheers

[Tommy Carrot]

Originally posted by Sirber
Is x264 updated? Haven't a chance yet to install it. I'm in the middle of an encoding :(

Yes, there is the new subpel refinement option, but still no 2-pass. However, "more iterations" mode (the slowest subpel ref. mode) seems to be borked, ugly artifacts appear with it sometimes. The default mode (the second) seems to be ok though. I didn't try the other modes yet, so i can't comment on them.

[netchris]

Yes x264 is updated compared to the ffdshow built of 28/8/04.
Two pass is not available yet.

Some days ago Tommy Carrot (if I remember correctly) posted an ffdshow built. The built was removed some hours later, but I played with it and the x264 codec had some encoding bugs - white blocks appearing randomly, when using anything else than halfpel.
The next day I finally managed to compile on my own the ffdshow code (the 2/10/2004 one), and my built does not have these encoding bugs whatever subpel refinements I choose, but it is quite slower. Testing now the new 03.10 built and the encoding bugs are back (with the speed being as fast as tommy carrots).
The speed difference can be because i did not use any cpu optimazations (I dont know how), or because i got too many warnings when building the code. I used the visual studio net compiler.
I dont understand why the bugs are back,I guess they used older x264 code than the 2/10 one but cant understand why they would use older code.

Anyway the encodes made with my built are very nice, I can only hope the two pass option will make x264 more competitive.

Thanks for your time :)

*********************************************
update : Yes Tommy I am talking abouth these artifacts that are not present in my built

[colin.findlay]

Now, the reason I want WMP to use the ffdshow audio decoder is 2-fold.
a) I'm using a HTPC solution (mediaportal) which integrates with WMP only at this point.
b) I'd like ffdshow to auto-load a different preset for mp3 files. In this case 2.0 stereo out for mp3/wma/ogg & 2.0 stereo mixed to 5.1 out for any other stereo source. (ie. divx with mp3)

I may just end up assigning the presets to hot keys (if poss) and setting up my remote so I can manually switch (not nearly as cool)

BTW. You can replace the ACM with others, but what I would really need is an ACM wrapper for ffdshow with decode-only support, and maybe encoder pass-thru.

Regards
C.

Originally posted by LigH
Since I know why, I would never install any newer MS-WMP version, but rather use really powerful media players instead (like Media Player Classic, VideoLan Client, ZoomPlayer, BSPlayer, The Core Media Player, ...) - I can control them as I decide, and they don't phone home.

You may try to disable or even uninstall this outdated MP3 codec (Control Panel, Sound & MM, Audio Codecs...). If this makes problems, you may re-install the Radium codec afterwards. And if you decide to substitute it, you may try the LAME ACM (RareWares, MP3, latest stable pack, right-click on .INF, Install).

[Tommy Carrot]

Originally posted by netchris
update : Yes Tommy I am talking abouth these artifacts that are not present in my built
If they didn't occured in your build, i suspect that using the cpu optimizations at compilation causes this bug, since the x264 code wasn't touched in the last few days, probably that's the only difference between the 2 builds.

Edit: ok, i was wrong, there were changes in the x264 code 3 days ago, but i still stay with my opinion that using too strong optimization settings at compiling can cause those bugs.

[obieobieobie]

This latest ffdshow seems to crash the Windows Explorer shell when viewing a folder with video files.

[aketon]

Originally posted by Tommy Carrot
Yes, there is the new subpel refinement option, but still no 2-pass. However, "more iterations" mode (the slowest subpel ref. mode) seems to be borked, ugly artifacts appear with it sometimes. The default mode (the second) seems to be ok though. I didn't try the other modes yet, so i can't comment on them.

But in the changelog:

2004-09-09 20:20 milan_cutka

* x264 two pass encoding

:confused: :confused: :confused:

[marcellus]

Although the change log says this:
2004-09-06 08:37 milan_cutka

* use avisynth filter again

2004-09-06 08:30 milan_cutka

* use avisynth filter again
avisynth filtering inside ffdshow is still not working. Last working version was 20040808.
And I really need this.
:( :( :(
Edit:
To give more details:
-When I use it via vfw interface for realtime captures avisynth filtering simply does nothing
-When I open files via MPC (directshow interface) avisynth filtering does nothing and it shows this error on screen:
http://img59.exs.cx/img59/2360/snapshot_01.jpg
Edit 2:
Forgot to mention that is not particular script related, the simplest script like invert() or Info() triggers the error

[aketon]

At least, with this new build, I can encode to theora again!:)

[Leak]

Originally posted by marcellus
Although the change log says this:

avisynth filtering inside ffdshow is still not working. Last working version was 20040808.
And I really need this.

I'd assume he was writing about the AviSynth filter that's now included with ffdshow so you can use ffdshow's functions in AviSynth instead of the other way round. Of course, a fixed AviSynth support in ffdshow would be very nice too...

np: Yoko Kanno - Cream (Ghost In The Shell Stand Alone Complex OST Be Human)

[marcellus]

I'd assume he was writing about the AviSynth filter that's now included with ffdshow so you can use ffdshow's functions in AviSynth instead of the other way round.
Yes, that passed thru my mind too.
Of course, a fixed AviSynth support in ffdshow would be very nice too...
For me is a must. And I don't understand why got broken, for long time, untill version 20040828, it worked fine. If I copy ffdshow.ax ver. 20040808 over the current one it works for my purpose but it's not 100% safe, strange things could happen anytime.

I use ffdshow with my TV capture program to encode real time mpeg2 (SVCD as target resolution). This task is very demanding for my CPU so to be sure I don't have dropped frames I must use this chain:

Capture(704*576)->
(ffdShow)Crop(656*512)->
(ffdShow)Resize(448*512)->
(ffdShow)denoise3D->
(avisynth)[Decomb(eliminate phase shift)->KernelDeintMMX->AddBorders(480*576)]->
(ffdShow)Encode

This way intensive tasks as denoising and deinterlacing are made on a 448x512 picture.
The last part, especially Decomb and AddBorders I can't do it with FFDshow's filters, so I have to do it in AviSynth.
Of course I could do it at a later encode but my purpose is to obtain a SVCD compliant mpeg2 file without the need of a reencode (at least the video part), I'm pretty happy with the quality and I don't want to spend more CPU time for my every day quick and dirty captures.
To dream a little, I wish we could put in ffdshow 2 or more instances of one filter, for example I could use denoise3d after deinterlace and before addborders (so I would have to use avisynth 2 times).

[virus]

Looks like x264 2-pass is available, but not in the usual way. Here's what Milan wrote on SourceForge after I've submitted my requests:

by Milan Cutka:

x264 uses its own two pass algorithm which is similar to libavcodec's and so is the way to use it.
To do the first pass, select constant quantizer (preferred) or constant bitrate and on the Ouput page select Write from "Libavcodec stats" group (sorry, forgot to add x264). In the edit box below you can enter first pass stats file name. For second pass, select constant bitrate and select "Use"
from "Libavcodec stats group. Sorry, I know this isn't very user friendly, but it's because ffdshow's own two pass routines can't be used.

[SeeMoreDigital]

Originally posted by obieobieobie
This latest ffdshow seems to crash the Windows Explorer shell when viewing a folder with video files. Yes, I've noticed this too!

As soon as I have H.264 "libavcodec" enabled and go a hunting for my h.264 encodes, I receive a "Windows Explorer" warning...


Cheers

[obieobieobie]

It is added to the bugtracker over at the ffdshow sourceforge project page. Milan posted a new build (requires an sse capable cpu) which has fixed the problem at least for me.


link to bugthread (http://sourceforge.net/tracker/index.php?func=detail&aid=1039593&group_id=53761&atid=471489)

[Stereodude]

Any change FFDShow can be fixed to read the aspect ratio from Matroska files correctly?

I have 3 computers and only on 1 of them does FFDShow correctly use the aspect ratio / display size value in the .MKV even though the same exact software and filters are used on all 3.

[SeeMoreDigital]

Originally posted by Stereodude
Any change FFDShow can be fixed to read the aspect ratio from Matroska files correctly?

I have 3 computers and only on 1 of them does FFDShow correctly use the aspect ratio / display size value in the .MKV even though the same exact software and filters are used on all 3. What streams have you muxed into MKV?

The current build can't correctly AR Mpeg1 or 2. I've also tried FFdshow with anamorphic 3ivx, XviD, Nero and DivX Mpeg4 streams, in both AVI and MKV. And sadly it does not work!

So for me, I'm sticking with one of XviD's test DSdec filters with auto AR detection!


Cheers

[Stereodude]

Originally posted by SeeMoreDigital
What streams have you muxed into MKV?

The current build can't correctly AR Mpeg1 or 2. I've also tried FFdshow with anamorphic 3ivx, XviD, Nero and DivX Mpeg4 streams, in both AVI and MKV. And sadly it does not work!

So for me, I'm sticking with one of XviD's test DSdec filters with auto AR detection!


Cheers
I was doing Anamorphic 1080x720 xvid decoded to 1280x720 with AC3 audio. It works on one of my computers with FFDShow, the other 2 do not play it back correctly with FFDshow. They all work fine with using the official 1.02 xvid decoder.

[SeeMoreDigital]

Originally posted by Stereodude
I was doing Anamorphic 1080x720 xvid decoded to 1280x720 with AC3 audio. It works on one of my computers with FFDShow, the other 2 do not play it back correctly with FFDshow. They all work fine with using the official 1.02 xvid decoder. If you're re-encoding you're source to 1280x720 (with square) pixels then the encode is no longer anamorphic. It's a "true 16:9 frame" encode!


Cheers

[Stereodude]

Originally posted by SeeMoreDigital
If you're re-encoding you're source to 1280x720 (with square) pixels then the encode is no longer anamorphic. It's a "true 16:9 frame" encode!


Cheers
As I said I am encoding to 1080x720, and playing back at 1280x720. That is anamorphic.

[SeeMoreDigital]

Sorry my mistake!

1080x720 seems a rather odd source size. How did you manage to arrive at it?


Cheers

[virus]

OK, about x264: I've tested both ffdshow-20041003 and ffdshow-20041005-sse and both have the "blocking bug" when subpel refinement is set to something different than "hpel only".

It has been suggested that the problem may be due to compiler optimizations. So: what compiler has been used for those builds? What compiler flags? Is there a way to have a different build with different compiler/params to test it? At least, if we understand where the error actually is, we will be able to submit a bugreport...

some help please? :)

[celtic_druid]

http://celticdruid.no-ip.com/test/ff_x2641.7z
http://celticdruid.no-ip.com/test/ff_x2642.7z

First one I tried and it looked fine. Second one I don't know but it should be faster.

http://celticdruid.no-ip.com/test/ff_x2643.7z
http://celticdruid.no-ip.com/test/ff_x2644.7z
http://celticdruid.no-ip.com/test/ff_x2645.7z
http://celticdruid.no-ip.com/test/ff_x2646.7z

[virus]

thank you celtic_druid, I'm currently testing your 2nd build and the results seem strange to me. 95% of the blocks are gone but not all! There are still very few small artifacts... I'm trying to narrow down the problem and test more.

Anyway the PSNR results for x264 start to be pretty good (better than XviD). I'll report back on the x264 development thread about them later.

[netchris]

Thanks a lot celtic_druid!
The first and second builds are fine,they have exactly the same behaviour as my builds, so they are slow but block-bug free.
The files from 3 to 6 are twice as fast but they all have the block-bug.
What did you change in these builds?

95% of the blocks are gone but not all! There are still very few small artifacts...

The artifacts you see might be unrelated to the bug. I believe they are encoder immaturities.

Also the last mplayer/mencoder build that I did has x264 enabled. Build is optimised for athlon-xp's though.

could you please provide a link for the mencoder build?

[celtic_druid]

2nd build should be reasonably fast. Think it was ICL 7.1 with /O3 /G6 /Qipo /Qunroll /QaxiMK

3rd one was I think -O4 march=pentiumpro mtune=pentiumpro -pipe -ffast-math -fomit-frame-pointer
4th was basically default without -funroll-loops
5th was basically default without -finline
6th was basically default without -finline-functions

Here ya go:
http://celticdruid.no-ip.com/test/ff_x2647.7z
gcc without march, ffast-math or anything.

Hmmm, hang on I don't think that the MSVC project files have nasm enabled. Perhaps that is where the problem lies? Would also explain the speed difference.

[netchris]

The 7th build is slow again (a little faster than second) but without the block bug.


Hmmm, hang on I don't think that the MSVC project files have nasm enabled. Perhaps that is where the problem lies? Would also explain the speed difference.

I hope you are right so that we find the source of all evil.

[virus]

things start getting damn messy... 2nd build as before, but this time I've rised max ref. frames from 1 to 3... and guess what? A blockfeast! Even big blue blocks on white water... :(

I'm gonna check the 7th build with the same settings to see what happens. Right now the "bad" options are subpel ref. 4 ("qpel on all") + max ref. frames 3 + CABAC + in-loop filter + all analyze flags on.

@netchris: could you please try to re-encode with the settings above and see what happens?

[netchris]

I tried 2nd and 7th build that seem identical in quallity, with the options you asked but i dont see any problems here. I always used 3 reference frames. Subpel ref. 4 as well as 5 are clean in my tests.
Maybe there is something wrong with reference frames?(i doubt it)
I'll be gone for some hours so no more tests till then.

[celtic_druid]

Definatly no asm in the msvc project files. I couldn't get it to compile with asm when I added it either. Build 7 has asm, just no gcc opts so if 7 is ok then it isn't a problem with the asm anyway.

[virus]

Tested build 7. No way...
I believe it's a decoding problem. I've verified it under VDub and MPC. Seems to happen when you watch the "buggy" scene, go backwards and then rewatch the same scene. First display is OK, the 2nd is a blockfeast. According to a failed assert thrown by Vdub during decoding, the culprit may be libavcodec (or maybe the libavcodec sources embedded in ffdshow). More later.

[Tommy Carrot]

Originally posted by virus
I believe it's a decoding problem.
Definitely not, because the corrupted blocks are still there with the ateme decoder filter.

I checked build #1, and while it's slow as hell, at least it's working correctly (except the upper-left corner underquantizing problem).

[netchris]

It is not a decoding problem, when you have disabled 264 decoding support in ffdshow and decode it with nero's decoder the problem remains.

First display is OK, the 2nd is a blockfeast. According to a failed assert thrown by Vdub during decoding, the culprit may be libavcodec

what do you meen? In the first display the picture is ok? (without white block bug?)If that is the case, then there is a decoding bug that is unrelated to the white blocks. Appart from the decoding bug, the white blocks are definatelly an encoder's bug.

The problem must lie somewhere in icl's optimizations. I compiled with msvc(version 2003)choosing different options (with and without optimizations) and there never is a white block bug.The only problem is the resulting x264 dll is always quite slow (about as slow as builts 2 and 7). I also tried compiling with mingw-msys an the resulting dll is as fast as icl's fast builds but it also has the white blocks (though the bug might be less frequent with mingw,i am not yet sure about this).
I Also agree that nasm is not the problem as when compiling with msvc it is always enabled (though I dont know if it is being used by the code).

******************************************************************

I apologise in advance if I say something stupid,because I have no previous experience with the compilers, I am currently learning many basic stuff, thanks to x264 :) .
So if i dont make sense in some cases please be patient and you are welcome to correct me.


edit :
Tommy I didn't see your post while I was writing mine :) nice timing

[virus]

oh well, let's start from scratch then :rolleyes:

Let's say the decoding troubles are just a consequence of a broken bitstream then. I've tried to cut the video at the keyframe just before the Bad Things kick in... when I open the resulting clip VDub says that the first frame is bad, the rest good but undecodable (of course!).
But if I cut it a bit early everything works... and the bad blocks only appear if you go forward and backwards when decoding... well, in fact the decoding is rather unpredictable. Sometimes it displays almost no blocks, sometimes a lot of big bad blocks :rolleyes:

Anyway: build 2 and 7 both have the problem for me. Build 2 is ICL, build 7 is gcc... so it cannot be a bug in the compiler I'd say. I'll give a shot at build 1, then I'll try to invent something different.

:confused:

[virus]

All attempts failed miserably. Same problem.

Here's a sample (http://www.webalice.it/riccardo.stievano/video_stuff/x264-b0rked.avi) (930 KB) of my troubled clip, encoded with celtic_druid's build #1.

If you decode it starting from the 1st frame, you should not see any blocks (though I have the impression that some artifacts still lurk somewhere, I should make a frame-by-frame comparison with the source for that). BUT if you decode starting from the second keyframe, bad blocks should appear. If they don't appear, try going forward and backwards and then restart decoding again from the 2nd keyframe. I've checked that with both VDub and MPC.

I hope some of you can confirm what I'm seeing here.
No clue about what's going on. :(

[snacky]

That's not an encoder bug.

In H.264, a p-frame can be predicted from multiple previous reference frames, including (possibly) frames preceding the last iframe. This is the case for the first i-frame in your sample video. This particular i-frame shouldn't be used for seeking directly to, and shouldn't be used as a keyframe.

[virus]

Originally posted by snacky
This particular i-frame shouldn't be used for seeking directly to, and shouldn't be used as a keyframe.
Are you saying that seeking/cutting reliably in H.264 is impossible if you use multiple ref. frames?
If you don't seek to a keyframe, where are you supposed to seek then?

This won't explain the blocks some of us saw using different builds, though. I've seen blocks appear in the middle of a 1000 frames long sequence, decoding from the start (see the scrshots in the x264 thread). Others reported similar problems. Maybe 2 different issues?

[netchris]

I've seen blocks appear in the middle of a 1000 frames long sequence, decoding from the start (see the scrshots in the x264 thread). Others reported similar problems. Maybe 2 different issues?

Please dont mistake it with the white blocks bug. This is an encoding bug, and what you mention is a decoding one. Two seperate bugs. I understand why you mistake them, they produce a similar effect so it might be confusing.

And one question gcc = mingw? isn't gcc linux only?

[akupenguin]

Originally posted by virus
Are you saying that seeking/cutting reliably in H.264 is impossible if you use multiple ref. frames? No, but the seeker/cutter has to distinguish between an I-frame (can be decoded independently, but says nothing about the following frames) and and IDR-frame (which is an I-frame that is guaranteed to be seekable)

Originally posted by netchris
And one question gcc = mingw? isn't gcc linux only? gcc has been ported to everything under the sun. mingw ("Minimalist GNU for Windows") is one such port.

[Stereodude]

Originally posted by SeeMoreDigital
Sorry my mistake!

1080x720 seems a rather odd source size. How did you manage to arrive at it?
I used the native content ratio as DVDs do 1.5:1 which gets anamorphically stretched to 1.78:1.

[virus]

Originally posted by akupenguin
No, but the seeker/cutter has to distinguish between an I-frame (can be decoded independently, but says nothing about the following frames) and and IDR-frame (which is an I-frame that is guaranteed to be seekable)
uhm, I can foresee several problems because of this. No tool that I know of make such distinction (but maybe bond can say something more on that :))

Is there an option in x264 to avoid that P-VOPs reference frames before the I-VOP they depend on? Something similar to "closed GOV" for XviD? Maybe it would be useful.

[Alvy]

Versions before I controlled ffdshow via girder with keyboard commands.
This does not work any more.
I tried all options like "remote control api" and "accept keyboard messages".
Is there a way to get this to work or is that a bug :confused:

[akupenguin]

Originally posted by virus
uhm, I can foresee several problems because of this. No tool that I know of make such distinction (but maybe bond can say something more on that)
If the tool is H.264-aware, it's trivial to make the distinction by looking in the slice-header. Of course, no existing codec-agnostic tool does so, because the distinction didn't exist before H.264.
And as long as the muxer is H.264-aware, the demuxer/seeker doesn't need to be: You just mark non-IDR I-frames as not keyframes (because they really aren't).

Is there an option in x264 to avoid that P-VOPs reference frames before the I-VOP they depend on? Something similar to "closed GOV" for XviD? Maybe it would be useful.
GOVs are already closed. It's just that 1 GOV can contain multiple I-frames.
To answer your question, set IDR interval = 1. (may also be called idrint or idrframe, I don't know what the ffdshow interface looks like.) That will force every I-frame to be IDR.

... Come to think of it, I can't see any function in non-IDR I-frames, except in the rare case of (scene 1)(scene 2)(scene 1) where scene 2 wants an I-frame, but the return of scene 1 could use a long-term reference instead of another I-frame. Still, the codec would have to be smart enough to look that far ahead. And for that matter, you only lose a small overhead for using a P-frame full of I-blocks instead of an I-frame.

[virus]

akupenguin, every time you post we learn something new about H.264 :)

I've opened a feature request item on Sourceforge to have the "IDR interval" option added to the ffdshow GUI (it's not available right now) along with the "deblock{alpha|beta}" one which is missing as well.

[snacky]

Originally posted by akupenguin
... Come to think of it, I can't see any function in non-IDR I-frames, except in the rare case of (scene 1)(scene 2)(scene 1) where scene 2 wants an I-frame, but the return of scene 1 could use a long-term reference instead of another I-frame. Still, the codec would have to be smart enough to look that far ahead. And for that matter, you only lose a small overhead for using a P-frame full of I-blocks instead of an I-frame. [/B]
I have an interest in encoding video game replays, and in this specialized field, non-IDR I-frames are probably useful quite often. Very large flashing objects or sections sometimes occur, and the flashing alone can trigger scene changes. Much more commonly (but also less importantly), meters, counters, and icons usually persist unchanged across genuine scene changes.

[akupenguin]

That gives me an idea... whereby the first pass uses no IDR frames, but records how many times each frame uses each reference. Then the second pass can decide which I-frames should really be IDR (most of them, so you don't sacrifice seeking) but lose no efficiency on snacky's flashes (or even force them to be P, if necessary).

[yaz]

Originally posted by akupenguin
That gives me an idea... whereby the first pass uses no IDR frames, but records how many times each frame uses each reference. Then the second pass can decide which I-frames should really be IDR (most of them, so you don't sacrifice seeking) but lose no efficiency on snacky's flashes (or even force them to be P, if necessary). yep, a kinda auto-idr-ing would be quite beneficial. just like vhq in xvid :-) for simpletons like me it's pretty hard to set a reasonable idr. anyway i doubt that there'd be any good way of it other than analysing the 1st pass.
the bests
y

ps can anyone outline me how's this x264 development going on now? officially x264 is a part of the vlc project but vlc itself provides the less encoding options (at least in the wizzard) ffvfw offers much more but it has serious implementation problems (say, the gui does not accept a/o sets options properly) mencoder gives the more options (including some very exotic stuffs like 3pass encoding and such) but some of them have been never mentioned anywhere else. so, how's it all going ?

[skynetman]

I have got BIG problems with ffdshow-20041003.
Some movies have a strange "colorizing" effect that changes image color balance from standard, to red, to green, to blue without any reason an repeatedly within few seconds .
I just launched gspot for some testing.
Current problematic AVI is XVID with packed bitstream.
Same problem with simple MMX or XVID IDCT , with both postptrocessing and picture properties on and off (obvioulsy colorizing option is always set to zero).
I'll check for other avi with same problems to see if it is xvid related.

[virus]

@celtic_druid

here are the PSNR scores for the 3 builds I've tested. Same material, same encoding params, decoded once from the start so to avoid any problems with non-IDR frames.

build 1: 43.3490 dB
build 2: 43.3490 dB
build 7: 42.0704 dB

So, first 2 are OK, while build 7 has problems... no, not big blocks, but a generalized poor quality on some sections (with PSNR falling below 38 dB!). So maybe it's gcc with ASM the culprit then?

[netchris]

:D :D :D :D :D :D :D :D
OK virus I found whats wrong.
The problem is with the -O3 option.
You have to use -O instead and you get a dll than encodes fast and without the white blocks bug.
If you use -O2 the white blocks reappear.
If you dont use the -Ox at all the encodes are white blocks-free but they are as slow as builds 1,2,7.
All the other options (-funroll-loops, -finline-functions -mtune -march etc) have no relation to the white blocks

So just use -O :cool:

(The compiles were made with mingw-msys)

[akupenguin]

A nice constrast to libavcodec, which fails to compile with anything less than -O2. :D

You might also try running the 'checkasm' tool in x264 svn. It was presumably designed for detecting this sort of situation?