ffdshow development

[Sirber]

In registry, what does "hwOverlay" do at "2" ?

[m0rbidini]

Hi everyone,

I have a tiny problem with ffdshow subtitles support (latest athos builds up until 2004-04-05). I have some (a lot actually) subtitles that fail to display a lot of lines If I set the vertical position > 96%. With the build dated 2003-11-28 it works correctly even if I set the vertical position to 100%. Don't know if this is a bug or not, though.

Here's a link of a (portuguese) subtitle that fails in ffdshow: example (http://pwp.netcabo.pt/m0rbidini/example.srt)
These lines, among many others, fail to render:


195
00:17:17,360 --> 00:17:18,270
Não!

196
00:17:18,920 --> 00:17:20,399
Não, não, não!

197
00:17:20,960 --> 00:17:23,633
Trinta e seis vezes, não!

198
00:17:23,880 --> 00:17:26,155
Enviaram-me um guinéu? Não!


Thanks everyone.

[athos]

New build today. Same location.
Compiled partly with ICL 7.1

[Andy2222]

Originally posted by athos
New build today. Same location.
Compiled partly with ICL 7.1

little notice for those build: the new "half mode" integration bugged the nic's pp filter and also the asharp filter, if u enable those filters u get a green screen or a strange sharped picture. All other "normal" filters seems to work.

[LotharZ]

Originally posted by athos
New build today. Same location.
Compiled partly with ICL 7.1
With this new build Im getting a green screen with messed subs when Ive some of the "Processing Method" is enable and "Subtitles" at same time.

ffdshow-20040418 + WMPC 6.4.8.2 + Win2k3

[BoNz1]

Yay, ffdshow can now play video encoded with CABAC p-frames so vss good quality now works.
EDIT: and at a very respectable 50% cpu load on a P4 1.6 at 704x288.

[oddball]

I've given up on ffdshow for the time being. Playing with XviD b4 decoder and enjoying jerk free playback.

[TheShadowRunner]

woohoo! something must have been done regarding SVQ3 since the latest Athos build (ffdshow-20040418) now works again without crashing libacodec.dll.
However the framerate doesn't resolve, and it's MUCH slower than with ffdshow 20040312; but at least it doesn't crash ;)
Later,

TSR

[Tommy Carrot]

Originally posted by BoNz1
Yay, ffdshow can now play video encoded with CABAC p-frames so vss good quality now works.
EDIT: and at a very respectable 50% cpu load on a P4 1.6 at 704x288.

The CABAC support is not perfect yet, the moving objects leave trails and blocks behind, which are not there with the VSS decoder. No problems with CAVLC decoding though. :)

[gotaserena]

Forgive me if this is a known issue (I wouldn't call it a problem)

I've been comparing the output of XviD decoding with both ffdshow and XviD decoders. I found that ffdshow colours are consistently shifted to magenta and/or blue when compared to XviD decoder.

Is it something that can be simply fixed (I've tried shifting to XviD4, but there was no difference), or is it something having to do with MPC?

[LigH]

ffdshow provides several iDCT functions - did you compare them all?

[BoNz1]

Originally posted by Tommy Carrot
The CABAC support is not perfect yet, the moving objects leave trails and blocks behind, which are not there with the VSS decoder. No problems with CAVLC decoding though. :)

Ah, yes you are right. I just checked my test clip and there are a few small trails but so you are right it isn't perfect yet however, the trails are almost unnoticable in my test clip.

[dslava]

With thå new build I get green screen with messed up subs everytime sub showing up

ffdshow-20040418
WMPC 6.4.8.2
Win XP

[Lekanda]

I can confirm that. Also OSD-on turns everything green.

[CruNcher]

http://cruncher.mufflastig.com/ffdshow/

x264 support

*link corrected*

[LigH]

DOKUMENT NICHT GEFUNDEN

Die von Ihnen angeforderte Seite

wurde nicht gefunden.

....hosted by KONTENT

[rds_correia]

Originally posted by athos
New build is up on SF. This time I skipped ICL7 and used the regular MSVC++6 compiler, as the builds since 2002-12-13 has caused Explorer to crash when building thumbnails for video files in thumbnail view. This one doesnt seem to do that, at least not yet. Please post your findings regarding stability and possible performance loss (or gain?).
Hi Athos,
Last version I used was ffvfw-20030927.exe.
I know this is FFdshow but from what I've been told both products are now bundled in FFdshow, right?
If so, then my feedback is positive.
I've always had Windows Explorer's crashes due to just hovering the mouse cursor on top of a makeAVIS fake avi.
With the latest release I have ffdshow-20040418.exe this doesn't happen.
BTW I have a problem with the new fake avis provided by makeAVIS.
When used with mencoder, for instance, the encoded stream gets upside down :(
Any ideas why?
Cheers buddy.

[Tommy Carrot]

Originally posted by CruNcher
http://cruncher.mufflastig.com/ffdshow/

x264 support



Wow, looks great! It's faster and easier to configure than VSS codec. My opinion about the quality is coming soon. ;)

First issue: it doesn't insert keyframes into the scene-changes.

[Tommy Carrot]

Hmm, after a brief test, the VSS codec seems to be the winner. The image is more solid, and it preserves the details better. But it's only a brief test, i'm not sure we can extrapolate the result to every bitrates and scenarios.

Anyway, great to see a working open-source implementation.

[BoNz1]

Originally posted by Tommy Carrot
Wow, looks great! It's faster and easier to configure than VSS codec. My opinion about the quality is coming soon. ;)

First issue: it doesn't insert keyframes into the scene-changes.

Well there is no frame decision just a fixed pattern and constant quant. It does work rather well and is relatively fast. I used the standalone exe a couple of weeks ago. When I used it there was a lot of inline assembler which as you might know is not too windows friendly. Some of the assembler has been ported for nasm since then but definitely not all I don't think, so a lot of the code you are running is just c code I think.

[gitoshi]

is the Luminance Gain crash gone in the 20040418 version????
Asharp filter is broken.


G

[arno]

Originally posted by gitoshi
is the Luminance Gain crash gone in the 20040418 version????
Asharp filter is broken.


G

Crash seems to be fixed over here... :-)

[Arcon]

Originally posted by CruNcher
http://cruncher.mufflastig.com/ffdshow/

x264 support

*link corrected*
if i install it i can play xvid files with it but as soon as i try to open the settings window i get an access violation at 029f687f, write of address 00000007.

i'm back at build 040405 :(

[Tommy Carrot]

Originally posted by Arcon
if i install it i can play xvid files with it but as soon as i try to open the settings window i get an access violation at 029f687f, write of address 00000007.

i'm back at build 040405 :(

Yupp, same here. Athos' 20040418 build is safe to use though, but it doesn't have x264 codec support.

[athos]

New build today.

libavcodec is updated
Managed to compile _all_ VC stuff with ICL 7.1, except TomsMoComp.
Targetted at i686 (in VC and GCC)
Win9x install path ($SHORTINSTDIR)
included makeAVIS.exe
included skl_drv_mpg.dll
included ff_x264.dll
Andy2222's OM fix
had to comment out declaration of getCodecFOURCCs, I hope this doesnt break anything.

[Soulhunter]

Originally posted by athos
New build today.
Nice... :)


But as suggestion:

Its always a pain to (re)search the link to your ffdshow builds in my favourite's... :(

Could you maybe add the link into your sign or the posts to make access easier ???


Tia n' Bye

[athos]

Originally posted by Soulhunter

Could you maybe add the link into your sign or the posts to make access easier ???

Good idea, added it to my sign.

[Soulhunter]

Originally posted by athos
Good idea, added it to my sign. Lovely... :D


THX n' Bye

[iradic]

i have problems with decoding xvid rc3 with ac3 or mp3 audio with libavcodec...

always happens at same frame (it seems it skips few frames) and a/v synch is lost afterwards...
without audio it looks to me like it doesnt skip frames...

decoding with xvid decoder is just fine (with/without audio)...

tried latest build and 29-03-2004 and ac3-filter 0.7, mp3 from besweet profile for avi, muxed with vdubmod or nandub...

[skynetman]

20040424 solved all my problems with gain and offset crash on AMD + win2003.
Well done ;)

[Affar]

Hi

I have a problem with versions after 23-3-2004.

In first case, my AMD K6-2 400Mhz is crash in every players, but in before versions works fine.

In second case, i have problems to decoder some videos (XviD 1.0 RC4), and to fix this i need to desactivate "autodetect" in Miscellaneous option. Here are sample with this bug http://www.portaldivx.com/error_ffdshow.avi [548k]

Thanks and sorry for my poor english

[Kurosu]

@Affar
You processor hardly support anything else than MMX: I believe there is no 3DNow code that isn't iSSE in fact. So someone will have to make a specific build, as the ones around here are for Athlons and P4s.

@All (and especially Didée and some others)
Date: Sun, 25 Apr 2004 21:03:37 +0200 (CEST)
From: Michael Niedermayer CVS <michael@mplayerhq.hu>
Reply-To: ffmpeg-devel@lists.sourceforge.net
To: ffmpeg-devel@lists.sourceforge.net
Subject: [Ffmpeg-devel] CVS: ffmpeg/libavcodec h263.c,1.248,1.249

Update of /cvsroot/ffmpeg/ffmpeg/libavcodec
In directory mail:/var2/tmp/cvs-serv14794

Modified Files:
h263.c
Log Message:
fix decoding with quant matrixes which contain elements <16
I think that is something you all waited for. I don't have videos to test if the change really improved decoding.

[Didée]

fix decoding with quant matrixes which contain elements <16
/* me starts dancing around, on, and under the table*/ ;)

[Kurosu]

Actually, I'm not that sure anymore. I don't know if h263's DCT/quant functions are actually used in all MPEG-like (de)coders.

[Andy2222]

Originally posted by Kurosu
@Affar
You processor hardly support anything else than MMX: I believe there is no 3DNow code that isn't iSSE in fact. So someone will have to make a specific build, as the ones around here are for Athlons and P4s.

All ffdshow builds are not "special" builds for Athlon's/P4, Athos used "blend" for the older and "/G6" wich means pentium pro class cpu compiles for the new compiles. Even a /G7 compile wich means "pentium 4" class will run on older cpu's. Only a gcc -"--march=pentium4" build will not run on other CPU's than P4, but Athos surly used "mtune" or "mcpu" for the gcc stuff.

The AMD K6-2 is surly a pentium pro class cpu, so it should work. Maybe ask athos to build a "blend" compile as fix.

Affar can u open the ffdshow setting's page and can u try run a movie with all filters disabled?

[Kurosu]

Originally posted by Andy2222
[B]All ffdshow builds are not "special" builds for Athlon's/P4, Athos used "blend" for the older
I was refering to gcc-compiled parts, but you are nonetheless true. However, if you check Makefiles/source lists, you can notice that mpeg2enc and ffmpeg build SSE code. I don't know if it's actually used. But I don't think that an error such as mixing iSSE ops with MMX/3DNow ops is the source of the error, otherwise it would have been signaled and fixed a long time ago in ffmpeg.

One solution would be to disassemble dlls/ax with nasm, and grep the output for non-MMX/K6 ops. Checking if that code is actually used comes next.

[Andy2222]

Originally posted by Kurosu
I was refering to gcc-compiled parts, but you are nonetheless true. However, if you check Makefiles/source lists, you can notice that mpeg2enc and ffmpeg build SSE code. I don't know if it's actually used. But I don't think that an error such as mixing iSSE ops with MMX/3DNow ops is the source of the error, otherwise it would have been signaled and fixed a long time ago in ffmpeg.

One solution would be to disassemble dlls/ax with nasm, and grep the output for non-MMX/K6 ops. Checking if that code is actually used comes next.

The question is what part of ffdshow crash for Affar, libav or ffdshow.ax or mplayer.dll or some of the other dll's. All the mmx2/sse1+2 code is only used if the cpu support it, otherwise the normal mmx function is used. The only problem i know are some mmx2 (pshufw) instruction's wich are used in the so called mmx version's but are mmx2 instructuion's (i think it was in the nic pp). But i think the k6-2 also have mmx2?

The problem is prolly the same like the "offset" crash wich is "fixed" now but i dont see any special code change wich direct fixed that crash, so its more like a random fix. Aka new version work old dont and no1 know realy why :)

[Kurosu]

Originally posted by Andy2222
But i think the k6-2 also have mmx2?Basically, it's 3DNow! 1 (not Extended/2) that introduced (most of) the new integer ops. I think that is also called MMX Extended. By changing caching stuff, you should have iSSE. One exception might be pavgusb (3DNow!)<->pavgb(iSSE) which maybe has a different code.

The problem is prolly the same like the "offset" crash wich is "fixed"I don't know if the fix was committed to CVS, but I never had this problem. Probably because of what you described.

[athos]

Just a note: the latest builds i have targetted for Pentium Pro (i686) cpu classes. So in VC i use /G6, and in GCC i use -march=i686. The default settings from CVS are (mostly) Blend in VC, and -march=i586 -mcpu=i686 in GCC. I decided to go I686 all the way since I didnt think anyone uses below-i686-class cpus for decoding.

[Andy2222]

Originally posted by athos
Just a note: the latest builds i have targetted for Pentium Pro (i686) cpu classes. So in VC i use /G6, and in GCC i use -march=i686. The default settings from CVS are (mostly) Blend in VC, and -march=i586 -mcpu=i686 in GCC. I decided to go I686 all the way since I didnt think anyone uses below-i686-class cpus for decoding.

yeah -march=i586 should prolly work on all cpu's these day's. Btw u dont have to use -mcpu=i686 since march=i586 overwrite that option. march produce code special for that cpu, while -mcpu build code for that special cpu too, but will also run on any other.

Example: -march=pentium4 will produce code special for p4 wich prolly crash on any other cpu. While -mcpu=pentium4 will also produce code for P4 but dont crash. In general for max. compatibility only use -mcpu or -mtune for gcc 3.4.

I tested some march against mtune or mcpu for my athlon-xp and i dont see any speed improvments or looss. Its prolly cause all the cpu intensive functions are asm coded and arnt effected by special compiler switches.
--------------------------------------------------------------------

-mcpu=cpu-type
Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions. The choices for cpu-type are i386, i486, i586, i686, pentium, pentium-mmx, pentiumpro, pentium2, pentium3, pentium4, k6, k6-2, k6-3, athlon, athlon-tbird, athlon-4, athlon-xp, athlon-mp, winchip-c6, winchip2 and c3.
While picking a specific cpu-type will schedule things appropriately for that particular chip, the compiler will not generate any code that does not run on the i386 without the -march=cpu-type option being used. i586 is equivalent to pentium and i686 is equivalent to pentiumpro. k6 and athlon are the AMD chips as opposed to the Intel ones.


-march=cpu-type
Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mcpu. Moreover, specifying -march=cpu-type implies -mcpu=cpu-type.

[Affar]

@Andy
The error happens when i try to watch the video because the config is ok.

@athos
Ever now that everyone have modern pcs, there's still people that have a pc that is non compatible with those instructions. 23-5-2003 version works perfectly and it's, without a doubt, the version that consumes less resources, but this versions doesn't warked with xvid 1.0 with packed bistreams, apart from the new functions in the ffdshow.

I hope you can solve this problems. Seeya

[athos]

Originally posted by Affar

@athos
Ever now that everyone have modern pcs, there's still people that have a pc that is non compatible with those instructions.
I'm not sure if i686 introduced any new instructions? We are talking pre-mmx here, processors with speed below 200mhz.
Maybe the problems are not due to the compiler flags i use, as this change was only in the latest 3 or so builds.

[Andy2222]

Originally posted by Affar
@Andy
The error happens when i try to watch the video because the config is ok.

"..because the config is ok." ???

so u get a crash message? Can u post this message since i still dont have a clue which part of ffdshow crash....

@Athos dont worry its prolly not a 586 or 686 code problem, the AMD k6-2 is a pentium pro class cpu and the change to 686 will just crash pentium 1 cpu's... aka 200-250Mhz cpu's. And if some1 cant get a new cpu for 40$ and still want use ffdshow with his 250Mhz cpu than something is wrong :)

[avih]

eventhough the latest (2004-04-24) works amazingly well with my computer (Athlon Xp 2500+) especially ffvfw, i think that many ppl will benefit from a a build with fewer optimizations (would mmx be the minimal? i tend to think so).

i.e. my brother still uses a celeron 300, many others still use lower specs pc since not everyone has the money to upgrade (i only recently upgraded from duron 800), and some just use a secondary old pc as a living-room playback machine.

of course, it all depends on the good will of the builders (i.e. athos and others). if, though, u think it's a viable option (as myself) i suggest posting a poll about what computers will be used with such ffdshow/ffvfw builds. again, my guess is that mmx only is the sweet spot in this regard.

cheers.

[Affar]

@Andy2222

Here is the message error:

http://www.portaldivx.com/pc_viejo1.gif
In every player appears same message (or similar).

Seeya

[Blkbird]

Why isn't any Open Type fonts using OTF container showing up in the font list for subtitle? I only see fonts using TTF container.

[Owen]

Since we are on the subject of CPU optimisations, I would like to request a fully P4 optimised build for use HTPC users who push FFDShow to the limit. Even a 3.5Gig P4 is struggling when you get really serious with FFDShow filters and an optimised version to take full advantage of the P4’s capabilities would be great.

I’m sure the Athlon XP users would appreciate an optimised version as well.

Is it possible to do a build that can do both P4 and Athlon XP without compromising performance of either?

It would be a great pity if the performance of FFDShow was to be compromised just to allow compatibility with outdated CPU’s.

Even P3 and early P4 or Athlon CPU’s are to slow for effective use of FFDShow filters. Older CPU’s have no chance.

Thanks

Owen

[ADLANCAS]

I’m sure the Athlon XP users would appreciate an optimised version as well.
I´m in this team.;)

[esby]

For me ffdshow is a general purpose decoder,
Not a beast running at the max speed it can the maximum ammount of filters when playbacking...
I explain,
if it can decodes and do some filtering, that's ok.
But if you want to use it like avisynth, while keeping the fps to the top,
you'll need something better than the two upcoming generations of processors no matter the brand,
unless you plan to buy a z-serie machine from ibm...

And don't forget that heavy filtering don't enhance this much the video quality,
since it tends more to denaturate it than anything else.

esby

PS: but I agree that if someone can do cpu optimization
without running into futher problems it will be ok for me...

[Andy2222]

Originally posted by Owen
Since we are on the subject of CPU optimisations, I would like to request a fully P4 optimised build for use HTPC users who push FFDShow to the limit. Even a 3.5Gig P4 is struggling when you get really serious with FFDShow filters and an optimised version to take full advantage of the P4’s capabilities would be great.

Is it possible to do a build that can do both P4 and Athlon XP without compromising performance of either?

Thanks

Owen

"Is it possible to do a build that can do both P4 and Athlon XP without compromising performance of either?" nope

since u have to tell the compiler for what CPU u want to schedule the instruction's, there is no compiler wich can include more than 2 way's (normal i386 and the specific CPU) pathed code.

The problem is that the P4 is in some causes a very "strange" cpu compared to the P3 or AMD Athlon, wich means that the compiler change some stuff for the P4 for optimal performance, while those changes might slow down if executed on the Athlon.

A full optimized P4 or Athlon build wont boost the performance btw. since the compiler cant magically integrate mmx or sse code. The compiler arrange/schedule instructions for the special cpu (if u tell him) and thats all. U have to look at the most consuming functions to understand why ffdshow takes so much cpu time. 20%-30 goes to libavcodec.dll for decoding the frames, around 20-40% goes to the mplayer.dll (resize/sharpen function wich depends on the type and how big u resize) and 20-60% goes to ffdshhow depending on wich filters/color conversion u have enabled.

To build a AMD or P4 version some1 has to review all the hand coded asm code for those newer CPU's and optimize them. That means not only a general mmx/mmx2 or sse1/2 version. It means to arrange/use asm instructions special for athlon or p4.
The main problem is that the code is already in ASM syntax, so its a damm pain to understand what its going on in that parts .... u will prolly need the org. plain C++ version's and rewrite the asm parts complete new. But where to get the org. C++ version's, they arnt in the code anymore...