ffdshow development

[Andy2222]

new version up (normal mmx and SSE2) just few fixes:

2004-07-09 Andy2222

* Luma Offset/Gain fixed

2004-07-08 milan_cutka

* clear input buffer when decoding audio using libavcodec
* better keyboard handling in codecs and keys pages

2004-07-07 milan_cutka

* fixed aac decoding
* imported faad2 library
* working on liba52 integration
* better ac3 support

2004-07-06 milan_cutka

* working on audio part 2
* multithreaded encoding using libavcodec
* split long subtitle lines

[thop]

Is ist just me or did CPU usage really go down with the latest version? It used to be 20-30% here, now it's 5-20%!

[swalker]

Andy2222, could you fix your local copy of ffdshow.ax.manifest? The one in your builds is broken (widgets do not pick up windows xp theming) and does not look anything like the cvs version.

[RadicalEd]

A non-sse2 version that decodes cabac correctly. SWEET. Thanks.

[pankov]

Andy,
in the non SSE2 version log I didn't see the "green fix". Does this mean that it's not implemented yet?
I'm not at home now so I can't check it myself.

[marcellus]

The new (non SSE2) release is really faster. I can now capture at 704x576, crop , resize (bilinear), denoise 3d (non HQ), deinterlace, addborders via avisynth and encode mpeg2 at 480x576 all in real time and decent quality. My CPU (AthlonXP 1800+) stays at 88-95% usage (no more dropped frames). Really great!

BTW, is there any way to add borders in ffdshow like in avisynth, without resizing the image to make room, just add them around the image? It would be cool, because now I have to use avisynth and is slower (not by much, but when CPU is at 95% usage the difference might mean dropped frames). To make myself more clear: I capture at 704x576, I crop it to 656x512, I resize it to 448x512 then I add borders to make it 480x576 to obtain the final m2v file (after I demux the avi) at SVCD resolution, ready to be burned without more encoding.

Selecting multiple threads has any speed effects with only one processor? I supose not, I didn't noticed any. Selecting more than one thread with mjpeg makes the encoder do nothing at all (but doesn't crash either :cool: ).
My problems with previos Andy's builds (mpeg2 and mjpeg encoding crashes) - gone. :) :cool:

One odd thing though (I think it's an old issue): mjpeg decoding of files encoded with ffdshow is normal but when I try to play avi files made by my digital camera there are swaped UV. With picvideo as decoder I dont't have this problem.

bye and many thanks!
marcellus

[bond]

ok i now tested it myself and the pervious problems ffdshow had with cabac decoding have definitely been fixed now! so ffdshow should be a very stable codec

should because i noticed another problem:
everytime i play a h.264 stream (tried it with one encoded with x264, CABAC, All BlockSizes, 5 ReferenceFrames and Q13) in graphedit, i get the first time a pretty dark, more grey picture, after i push stop and play again the color is the right one

anyone else experienced this?

[oddball]

All ffdshow builds since about february or so exhibit jerk-o-vision on playback. I've never gotten smooth playback with the later builds. If I playback with plain vanilla XviD 1.0 decoder it's smooth as silk.

[Andy2222]

@Pankov yes, im not at home atm and had no time to look into this yet

i will also check the manifest problem if im back

for the speed, i did not realy enhanced something in this release but we integrated the new mmx2 denoise3d (HQ version) code in the cvs and this version, so i suggest to only use HQ.

@oddball sorry to hear this, but its prolly no ffdshow problem since with all filters disabled and only using libav codec u should be able to decode a xvid movie without problems even on a 500mhz pentium. I also never heard about speed problems for pure decoding only of xvid movies. Did u try build a manual graph without adio filters in graphedit?

[Sirber]

bug report: lastest ffdshow crash with awarpsharp and post processing enabled. :o Gonna try with avisynth awarpsharp soon :)

[Andy2222]

Originally posted by Sirber
bug report: lastest ffdshow crash with awarpsharp and post processing enabled. :o Gonna try with avisynth awarpsharp soon :)

mhh cant confirm this, pls send me your ffdshow filter chain (what filters u use and in wich order) per PM.

thx

[nanoflower]

Any idea when the MPEG2 decoding will be fixed in libavcodec? I notice that the FOURCC column under the supported codecs is marked as "currently broken". When trying to play back an MPEG2 stream I'm only seeing the key frames so the B and P frames are being skipped. It would be nice if ffdshow could decode them.

[bokus70]

What is the difference between the athos and andy222 versions? SSE2 instructions? Something else?

I just recently popped into this thread only to find myself puzzled about these two builds.

thx

[sh0dan]

Originally posted by iradic
MMX -> Pentium MMX, Pentium II, K6, K6II, K6III and later
iSSE -> Pentium III, all Duron (called 3DNow extension), all Athlon (called 3DNow extension)
SSE -> Pentium III, Duron (core Morgan), Athlon XP and later
SSE2 -> PIV
A bit outdated:

SSE2 -> P-IV, Opteron, Athlon 64
SSE3 -> P-IV Prescott, Athlon 64 - 90nm, AMD Sempron.

- Since both Intel & AMD has added SSE3 into existing processors, it will probably cause some confusion, when it will eventually be utilized. (SSE3 isn't that big a change, though - at least for video processing).

[Andy2222]

Originally posted by sh0dan
A bit outdated:

SSE2 -> P-IV, Opteron, Athlon 64
SSE3 -> P-IV Prescott, Athlon 64 - 90nm, AMD Sempron.

- Since both Intel & AMD has added SSE3 into existing processors, it will probably cause some confusion, when it will eventually be utilized. (SSE3 isn't that big a change, though - at least for video processing).

So AMD actually integrated SSE3 in the latest AMD64 versions? I just wonder cause i read that AMD dont plan to integrate SSE3 soon, since they dont see much support for it.
On the AMD site i cant find infos about SSE3 support on AMD64 CPU's, can u gimme a link.

"SSE3 isn't that big a change, though - at least for video processing"

SSE3 has those nice horizontal add/sub stuff wich is common used in codecs and video processing, i dont know how its integrated in the CPU and how much cycles it takes, but at least having a horizontal add command saves the register copy and reorg. instructions, so those instructions are very helpfull for vector operations.

[Sharktooth]

SSE3 -> P-IV Prescott, Athlon 64 - 90nm, AMD Sempron.

Athlon 64 - 90nm is the NEXT generation of Athlon 64, not the current one.
Sempron is (will be) the new low end CPU from AMD available in both Socket A and Socket 754 (no 64 bit execution).

[Longinus]

Is it just me, or Andy's site don't work any more?

[athos]

New build today. Pentium (vc++) / i686 (gcc) target. Usual fixes.

[Leak]

Originally posted by Longinus
Is it just me, or Andy's site don't work any more?

Yeah, seems like Lycos.de pulled it - I'd guess it was producing too much traffic, and with today's free webhost offerings this is a big no-no...

np: Radiohead - Where Bluebirds Fly (Com Lag (2+2=5))

[Guy Incognito]

I uploaded Andy's latest SSE2 build to my webspace, you can get it here (http://blubb.at/sesshoumaru/ffdshow/).

[Andy2222]

Originally posted by Leak
Yeah, seems like Lycos.de pulled it - I'd guess it was producing too much traffic, and with today's free webhost offerings this is a big no-no...


jup just got the mail today, they "unplugged me"...
I will try to find a solution for a more stable webhost.

[fakey]

Originally posted by sh0dan
A bit outdated:

SSE2 -> P-IV, Opteron, Athlon 64
SSE3 -> P-IV Prescott, Athlon 64 - 90nm, AMD Sempron.

- Since both Intel & AMD has added SSE3 into existing processors, it will probably cause some confusion, when it will eventually be utilized. (SSE3 isn't that big a change, though - at least for video processing).


Some more things.:)

No SSE2/3 implementation in Socket462 Sempron.
coz it has old AthlonXP core.

And some rumours suggest that only 2ch ver.(socket939?) of Sempron will implement SSE3.

[Leak]

Originally posted by Andy2222
jup just got the mail today, they "unplugged me"...
I will try to find a solution for a more stable webhost.

Couldn't athos host those files at his sourceforge project? That would also solve the problem that people looking at the project page download the ancient alpha build that's up there...

np: Radiohead - Skttrbrain (Com Lag (2+2=5))

[athos]

The Sourceforge project is milan's, and he asked me not to put up alphas there until he felt the code was more stable..
But maybe I can find some other place.

[Leak]

Originally posted by athos
The Sourceforge project is milan's, and he asked me not to put up alphas there until he felt the code was more stable..
But maybe I can find some other place.

How about a second sourceforge project? ;)

np: T.Raumschmiere - Dual Kanal (Anti)

[Sharktooth]

Originally posted by fakey
Some more things.:)

No SSE2/3 implementation in Socket462 Sempron.
coz it has old AthlonXP core.

And some rumours suggest that only 2ch ver.(socket939?) of Sempron will implement SSE3.
Sempron will be available for Socket A (ahtlon xp, but only for motherboard wich supports 200Mhz FSB) and socket 754.
It is not based on the old Athlon XP core but on the Athlon64 core with 64 bit execution disabled.
The 3100+ will be clocked at 1800Mhz.
No SSE3 cpu from AMD is actually in production.
A quick search on the internet will confirm what i said (some guys are actually testing those CPUs).
However also those informations are subject to changes.
Please dont spread false rumors.

[Longinus]

@Andy2222

I have some space on my server if you like.
How much bandwidth did your lycos page used??
Mail me if you are interested (longinus@gmail.com)

[fakey]

Originally posted by Sharktooth
Sempron will be available for Socket A (ahtlon xp, but only for motherboard wich supports 200Mhz FSB) and socket 754.
It is not based on the old Athlon XP core but on the Athlon64 core with 64 bit execution disabled.
The 3100+ will be clocked at 1800Mhz.
No SSE3 cpu from AMD is actually in production.
A quick search on the internet will confirm what i said (some guys are actually testing those CPUs).
However also those informations are subject to changes.
Please dont spread false rumors.

Yes, Sempron will be available both for Socket A(Socket462) and Socket 754.
(and for Socket939 by Q1'05)
And No, Socket462 Sempron IS based on AthlonXP core unlike Socket754 one.
Anandtech says it's Thoroughbred and some other says Barton or Thorton, not certain which is correct but they're all AthlonXP core.
Sempron is only common trademark in AMD's value line for two explicitly different CPUs from different generation core.
I don't want to discuss something based on rumours either.
Sorry for being OT.

[Andy2222]

Originally posted by Longinus
@Andy2222

I have some space on my server if you like.
How much bandwidth did your lycos page used??
Mail me if you are interested (longinus@gmail.com)

thx for the kind offer, Athos was already so kind and got me access on his host.

[Andy2222]

[edit]
problem solved

[Sharktooth]

some AMD sempron informations can be found here: http://www.theinquirer.net/?article=17314
Nothing of real interest...

[faxmactor]

I have video that is likely to be made with an buggy, early Xvid 1.0 (or earlier) build. It has lots of b-frames but no keyframes in the beginning.

Xvid is able to display it correctly as well as mplayer (which uses libavcodec, too), so I came to a conlusion that this issue could be fixed in ffdshow as wll. Milan, please have a look at.

A screenshot: HERE (http://ozdtersegi.axelero.net/ffdshow_issue.jpg)

A short clip (2,5M) demonstrating the issue "live": HERE (http://faxmactor.port5.com/Excel%20Saga%20-%2001%20-%20The%20Plan%20To%20Murder%20Koshi%20Rikudo%20(AHQ).ogm)

[Bogalvator]

Did you try setting the IDCT setting to XviD? (under the "Miscellaneous" section)

[Soulhunter]

Some questions regarding ffdshow's audio decoder !!!


As its possible to upsample the audio...

- Could it be used the fix the SoundBlaster upsampling problem ???

- Should I upsample everything to 96000Hz for a Audigy2 ZS ???

- Is Kaiser "the best" upsampling algorithm of ffdshow ???

- Is it better than the Audigy's "bad" resampling ???

- When yes, how much better is it ???


Tia n' Bye

[SeeMoreDigital]

Originally posted by faxmactor
A short clip (2,5M) demonstrating the issue "live": HERE (http://faxmactor.port5.com/Excel%20Saga%20-%2001%20-%20The%20Plan%20To%20Murder%20Koshi%20Rikudo%20(AHQ).ogm) How about having the encode in an AVI container!

[faxmactor]

Originally posted by SeeMoreDigital
How about having the encode in an AVI container!
How about Matroska ;) BTW, it was not me who encoded this series, so can't do anything about it. But I don't think that the container format has anything to do with the video stream having been encoded with a dev version codec.

[Coroner]

@Soulhunter

The upsampling problem isn't solveable. It's a hardware issue with them. Some other cards (Not creative)with hacked drivers etc will give a non re-sampled output. There are few cards that will give a bit perfect output.

The EMU Digital Audio System cards which use a derivative of the EMU10K series will give bit perfect output. So will the Chaintech AV-710 with hacked firmware and drivers, although I think just the latest drivers will do it now. The M-Audio Transit USB (I have one) has bit perfect output with standard drivers. Of course none of these cards will do 3D audio EAX etc. Not sure on the AV-710 though, but I presume kmixer in windows will re-sample it anyway.

In short in order to get a non re-sampled bit perfect out put in windows one has to stuff around a bit.

For music I use foobar2000 with the ASIO output plugin and no re-sample output at 24 bits. For MPC I'm not sure whether it is possible to do it. A kernel streaming output or ASIO would probably do it.

For more info on the evil of kmixer and non bit perfect cards see Head-Fi Computers as source forum (http://www4.head-fi.org/forums/forumdisplay.php?f=59)

It's a rather in-depth topic. Basically at the end of the day you can't get non re-sampled bit pefect output from any Creative card. Even the digital outputs on these cards are re-sampled. You can of course use a better software upsample to 48Khz before hand (or 96khz, if you choose) but it still will not be bit perfect. Unfortunately Creative continues to force this resampled non bitperfect problem on you no matter what. If you play games though I guess your stuck with them, as sensaura etc just from my experience isn't up to scratch.

[athos]

milan gave me the go, so this is the first release in over a year to be put up on sourceforge:
http://sourceforge.net/project/showfiles.php?group_id=53761&package_id=59355&release_id=255667

Plain vanilla; should work on i586 (Pentium) and up.

[bond]

Originally posted by athos
milan gave me the go, so this is the first release in over a year to be put up on sourceforge:
http://sourceforge.net/project/showfiles.php?group_id=53761&package_id=59355&release_id=255667great!

maybe we should take this opportunity and close this 65 sites strong thread and continue the discussion in a new "ffdshow development #2" thread? i think noone finds anything anymore in this thread :D
what do you guys think?

[Tommy Carrot]

IMO the most important infos about ffdshow should go to a sticky, and this thread should be keeped for the normal everyday discussions about ffdshow (so we'd have a chance to make it the longest thread in doom9 :D).

[bond]

okidoki, from my point of view its not a good idea to have too long (like 65 pages) threads, as its simply far too difficult to find any infos in them anymore

thats why this thread is now closed and everyone is invited in continuing the discussion about ffdshow development in the new and cosy ffdshow development #2 (http://forum.doom9.org/showthread.php?s=&threadid=80256) thread :D