New ffdshow build (?)

[thuan]

Nah it's in there long ago, and it's default ffdshow behavior seems weird though. Just try to check one of the colorspace above and DV is unchecked but better use the reset button.

[pandy]

Hello, bob0r. Nice to see you again.

Another known bug : mpeg2 is sluggish after rev 30. I'm trying to fix this.


haruhiko-san probably not only MPEG-2 is "sluggish", MPEG-1 to...

[igor1st]

Another known bug : mpeg2 is sluggish after rev 30. I'm trying to fix this.
libmpeg2 is always the better decoder for mpeg1/2 in ffdshow (and it's faster). So it's not big problem.

bob0r, if you are distributing for end users, I recommend rev 13. Patch rev 37 should be added to rev 13.
Updating libavcodec is important work, it is being debuged and needs more testing for release.
I think adding patches from revs 38, 64, 70 also has sense in that case.

[_xxl]

libmpeg2 is always the better decoder for mpeg1/2 in ffdshow (and it's faster).
Autodetecting best optimizations:
http://rapidshare.de/files/30567750/FFdshow-20060823-rev2546.exe.html
Libmpeg2 is default MPEG1/2 Decoder.

[clsid]

I compared a few files with the latest ffmpeg revision and there are plenty of differences. So updating to latest ffmpeg code might solve a few problems. I only don't know if there are intentional differences in the ffdshow code. If there are any, then I think it is a good idea to document them in a readme file. That would make future updating of the code a whole lot easier.

[haruhiko_yamagata]

I compared a few files with the latest ffmpeg revision and there are plenty of differences. So updating to latest ffmpeg code might solve a few problems. I only don't know if there are intentional differences in the ffdshow code. If there are any, then I think it is a good idea to document them in a readme file. That would make future updating of the code a whole lot easier.
Yes, it's a good idea. There are intentional differences. Though it is sometimes hard to understand why such changes are needed, ffdshow doesn't work without them.

[Isochroma]

drevil_xxl: just tested 20060823, looks great! Excellent work I must say. WMV7/8 encoding works fine, extra WMV3 entry in the DS decoder is gone, and makeAVIS is present & working (note: previous versions of ffdshow put a link to it in the Start menu, this one doesn't).

[bob0r]

I'll just patiently await a more stable build.

[clsid]

@drevil_xxl, I don't know if it still applies to your current script, but here are some pointers based on the last one that you posted:
- Don't use uninsclearvalue. Use uninsdeletevalue instead. Empty values in the driver32 regkey are not good.
- You don't need to delete/clear each subvalue in the ffdshow registry keys separately. Just use uninsdeletekey on keys such as HKCU\Software\GNU\ffdshow.
- You don't need "MinVersion: 0,4.0;" on all items. You already enforce that globally in the [Setup] section.


rev87 build (http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow_rev2546-87_20060825.exe?download)

AviSynth plugin now automatically gets placed in AviSynth plugin. Added some more a/v formats to the tasks page on the installer. More can be added on request.

[akupenguin]

libmpeg2 is always the better decoder for mpeg1/2 in ffdshow (and it's faster). So it's not big problem.
Anyone want to put together a list of cpus where that's true? (assuming it is cpu-dependent)
Because I have heard several times on mplayer-dev-eng that libmpeg2 is faster, but ffmpeg12 always beats it by a fair margin on my computer (athlon64 3400 in 64bit mode, linux, mplayer).

[jffulcrum]

haruhiko_yamagata
mpeg2 is sluggish after rev 30. I'm trying to fix this
Seems that problem with MPEG1&2 is in FFDShow filter/parser, not in libavcodec themselves, because with video in AVI or MKV container all work normal

[_xxl]

@drevil_xxl, I don't know if it still applies to your current script, but here are some pointers based on the last one that you posted:
- Don't use uninsclearvalue. Use uninsdeletevalue instead. Empty values in the driver32 regkey are not good.
- You don't need to delete/clear each subvalue in the ffdshow registry keys separately. Just use uninsdeletekey on keys such as HKCU\Software\GNU\ffdshow.
- You don't need "MinVersion: 0,4.0;" on all items. You already enforce that globally in the [Setup] section.
Done. Thanks for help!

[haruhiko_yamagata]

I only don't know if there are intentional differences in the ffdshow code. If there are any, then I think it is a good idea to document them in a readme file. That would make future updating of the code a whole lot easier.
The slugish mpeg2/libavcodec is fixed by rev 89. And that was exactly "intentional differences in the ffdshow code".

@pandy : Perhaps mpeg1 is fixed too, though I don't have any sample of mpeg1 that shows the problem.

[igor1st]

Anyone want to put together a list of cpus where that's true? (assuming it is cpu-dependent)
Because I have heard several times on mplayer-dev-eng that libmpeg2 is faster, but ffmpeg12 always beats it by a fair margin on my computer (athlon64 3400 in 64bit mode, linux, mplayer).
I tested only inside ffdshow on my old AXP 2.2GHz with WinXP.
my 2543 build: 208fps vs 183fps
my tryout build: 208fps vs 120fps (so lavc update influenced not only for ASP decoding speed)

[jffulcrum]

haruhiko_yamagata
Thank you, MPEG-1 playback via libavcodec now good.

[Isochroma]

1920x1080i .ts decode using libmpeg2 is causing mpc to instant-crash (disappear) when seeking, using haali's renderer (2006-07-07). With haali's renderer, libavcodec works fine, but decodes at about 1/2 the speed (unplayable). Using MPC's internal .ts splitter, seeks work using libmpeg2, but first 1/2 second has weird green blocks.

Playback using Elecard's MPEG-2 decoder (reference) works perfectly, but it only outputs YUY2, so is unusable with the haali renderer (see my last post in the haali render thread for why).

[clsid]

I can confirm the green blocks/artifacts when using Gabest's splitter. Happens only on one of my MPEG-2 files. Using Overlay Mixer as renderer.

Here is the file that has the block issue:
http://www.nextcomwireless.com/r5000/download/hbo_trailer_6ksd.zip

Other that that I haven't had any problems playing MPEG files with the latest revision. Performance is the same as rev2543.

[haruhiko_yamagata]

I can confirm the green blocks/artifacts when using Gabest's splitter. Happens only on one of my MPEG-2 files. Using Overlay Mixer as renderer.

Here is the file that has the block issue:
http://www.nextcomwireless.com/r5000/download/hbo_trailer_6ksd.zip

Other that that I haven't had any problems playing MPEG files with the latest revision. Performance is the same as rev2543.
Your sample shows a problem with hard ware deinterlacing. I don't see green blocks on my hard ware, but it's slugish. Software deinterlacing(ffdshow) gives the best result, followed by HD deinterlacing by old ffdshow.

//EDIT
Now, I can see the green block when libmpeg2 is selected. So both of the decoders are broken.
libmpeg2 seems to have built in deinterlace.

[toby77jo]

dvd navigation in mpc when using dscaler5 video decoder in all of your builds is broken, it's working fine in ffdshow rev. 2543. is there a fix for this?

[KoD]

Am I correct in assuming that libavcodec cannot still be used for decoding mpeg2 when playing a DVD ? At least, it doesn't seem to work for me (plays a batch of frames, then it stops then plays another batch and so on) I've tseted this only with clsid's rev81 build on my old P4 2.4Ghz, no HT, SSE2.

[thuan]

Same with clsid's r.91.

[KoD]

I wanted to say r91 myself, but I misstyped it as r81 ^^;

[igor1st]

"Queue output samples" is an accelerator rather than multithreading, but I belive it is effective on P4HT or dual core.

I tested "queue output samples" on my single-core CPU today (Athlon-XP). Tested with almost full CPU loading (my special AVC file with resize). Using queue is definitely bringing benefit over non-queue output in such situation.

[haruhiko_yamagata]

Thank you, igor1st.

Rev 95:
Bug fix : hardware deinterlace : mpeg12.c based on 5578/ffmpeg

Known bug : slow decoding of MPEG4-ASP.
Are there any other bugs related to libavcodec?

[jffulcrum]

igor1st
Tested with almost full CPU loading (my special AVC file with resize). Using queue is definitely bringing benefit over non-queue output in such situation.
But on latest P3`s , and old P4 CPU`s with Willamete core enabling this option in case of 720 AVC/HQ ASP playback (almost 95+% CPU Usage) bail-out any player, even simplest mplayer2.exe . So is not good idea to always enable this trick.

[igor1st]

Known bug : slow decoding of MPEG4-ASP.
Are there any other bugs related to libavcodec?
Not only ASP but mpeg2 and maybe mpeg1 too:
http://forum.doom9.org/showthread.php?p=867826#post867826

[LoRd_MuldeR]

Today I wanted to play an old H.264 video and I noticed that with the current ffdshow builds it doesn't play smooth. I get full CPU load and a lot of dropped frames. The video is only 640x480 at 25fps, so it should play fine on my machine. I got hundreds of similar files, that all play 100%. When I play the same file in MPlayer or VLC there's no problem. So it's an ffdshow problem. Furthermore I remember that I played the file a while ago and there was no problem; no idea what ffdshow version I used at that time...

Here is the sample file:
http://uploaded.to/?id=bd326d (PW is "Doom9")

Note: It's from an old video tape, so don't care about the visual quality ^^

[foxyshadis]

Mulder, are all filters off?

[LoRd_MuldeR]

Mulder, are all filters off?

I use LanczosResize to 1920 × 1080 plus High Qulaity Denoise :p
Nope, they are all off ;)

Could you please test my video and check for unexpected high CPU usage?

[foxyshadis]

You set a password on it. >.>

I can say that with my personal build I have the exact same decode times on several very-high-bitrate test files I made as in versions over the past 4-5 months (I use them to track any improvements to AVC), as well and normal cpu usage in normal movies, so maybe yours just have optimizations turned off somehow. (Or were built in msvc only?)

(I should have hit post before I went to sleep.)

[LoRd_MuldeR]

You set a password on it. >.>

Sorry, I forgot :o PW is "Doom9"

I can say that with my personal build I have the exact same decode times on several very-high-bitrate test files I made as in versions over the past 4-5 months (I use them to track any improvements to AVC), as well and normal cpu usage in normal movies, so maybe yours just have optimizations turned off somehow. (Or were built in msvc only?)

(I should have hit post before I went to sleep.)

It's only that one specific file that makes trouble...

[pandy]

i dont know that anybody use a motion vector visualization but this functionality seems to be lost from few last ffdshow builds...
(quantizers and graph working ok)

[haruhiko_yamagata]

i dont know that anybody use a motion vector visualization but this functionality seems to be lost from few last ffdshow builds...
(quantizers and graph working ok)
It's working for me. What kind of decoder is in trouble?

[_xxl]

Applied patches:
accuracy.diff,aspect.diff,dts.patch,faad2.patch
ffdshow_mbaff.patch,ogg-5.1ch.diff,tsampleformat.patch
indicate we are using high accuracy tremor in gui,
fixed volume normalization by Kurosu,
faad 2.6 beta,xsharpen + swscaler = green problem.It was a bug caused xsharpen that did not call EMMS
by h_yamagata,libsamplerate 0.1.2.
http://prdownloads.sourceforge.net/ffdshow-tryout/FFdshow-20060828-rev2543.exe?download

[pandy]

It's working for me. What kind of decoder is in trouble?

Ver. from Aug 23 2006 13:32:09 (icl 9, x86, unicode)...

[_xxl]

Applied patches:
accuracy.diff,aspect.diff,dts.patch,faad2.patch
ffdshow_mbaff.patch,ogg-5.1ch.diff,tsampleformat.patch
indicate we are using high accuracy tremor in gui,
fixed volume normalization by Kurosu,better management of buffers of the queue,faad 2.6 beta,xsharpen + swscaler = green problem.It was a bug caused xsharpen that did not call EMMS by h_yamagata,libsamplerate 0.1.2.
http://prdownloads.sourceforge.net/ffdshow-tryout/FFdshow-20060828-rev2546.exe?download

[Egh]

Ver. from Aug 23 2006 13:32:09 (icl 9, x86, unicode)...

not all decoders in ffdshow support motion vector visualization.

iirc if you enable decoding thru xvid, you won't see any.

Just tested on last clsid build: motion vectors are properly shown from xvid and divx content decoded by libavc.

[_xxl]

http://prdownloads.sourceforge.net/ffdshow-tryout/FFdshow-Tryouts-20060828-rev100.exe?download

[jffulcrum]

Something wrong with Sorenson SVQ decoder in libavcodec since rev. 91 of ffdshow-tryout:

Application Failure zplayer.exe 4.5.1.0 in libavcodec.dll 0.0.0.0 at offset 000bafba

Same error with MPC. Tried different builds.

[haruhiko_yamagata]

Something wrong with Sorenson SVQ decoder in libavcodec since rev. 91 of ffdshow-tryout:

Application Failure zplayer.exe 4.5.1.0 in libavcodec.dll 0.0.0.0 at offset 000bafba

Same error with MPC. Tried different builds.
Could you upload a sample?

[foxyshadis]

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

Great resource for many codec samples. Since svq3 hasn't changed in some time, in either ffmpeg or ffdshow, it seems the bitstream must have changed... unless it is a r30 problem, not r91.

[pandy]

not all decoders in ffdshow support motion vector visualization.

iirc if you enable decoding thru xvid, you won't see any.

Just tested on last clsid build: motion vectors are properly shown from xvid and divx content decoded by libavc.

Yes i know - but for MPEG-2 they should be visible (hm... in the past i use libavcodec but at this moment decode mpeg-2 and mpeg-1 by the libmpeg - maybe this is a problem that motion vector is not showed at all...?)

[haruhiko_yamagata]

Yes i know - but for MPEG-2 they should be visible (hm... in the past i use libavcodec but at this moment decode mpeg-2 and mpeg-1 by the libmpeg - maybe this is a problem that motion vector is not showed at all...?)
You are right, libmpeg2 doesn't show arrows.
clsid's installer overwrite the setting of mpeg1&2 decoder.

[jffulcrum]

haruhiko_yamagata
http://64.207.133.64/upload/Director%20File/Jonas%20Akerlund/high%20Res./madonna_BbandHi.mov (27 mb)

[haruhiko_yamagata]

haruhiko_yamagata
http://64.207.133.64/upload/Director%20File/Jonas%20Akerlund/high%20Res./madonna_BbandHi.mov (27 mb)
Thank you, but I can play your file on my PC. I can't reproduce the problem.
Is the problem specific to zoom player? I use MPC.

[jffulcrum]

haruhiko_yamagata
Same error with MPC

But now i found source of problem. Damn Haali Media Splitter. It`s time to connect them with Norton Wipeinfo :) . With Gabest and Nero splitters all fine. Interesting, that ffdshow had time to decode about 20 frames before player crashed

[_xxl]

SSE:
http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev100-sse.exe?download
SSE2:
http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev100-sse2.exe?download
All files are by GCC 4.0.3.

[haruhiko_yamagata]

@foxyshadis
I can't compile rev 102 by GCC 4.0.3.
gcc -c -I. -I.. -Ilibavcodec -Ilibavutil -I../codecs -I../imgFilters -I../zlib - DHAVE_AV_CONFIG_H -std=gnu99 -DALLOW_INTERLACE -mno-cygwin -mdll -mthreads -pipe -DNDEBUG -UDEBUG -DWIN32 -D_WIN32 -O2 -march=i686 -mtune=i686 -fomit-frame-poi nter -finline-functions -finline -MMD -o libavcodec/i386/dsputil_mmx.o libavcode c/i386/dsputil_mmx.c
In file included from libavcodec/i386/dsputil_mmx.c:150:
libavcodec/i386/dsputil_mmx_rnd.h: In function 'avg_no_rnd_pixels4_mmx':
libavcodec/i386/dsputil_mmx_rnd.h:302: error: syntax error before 'ASMALIGN'
libavcodec/i386/dsputil_mmx_rnd.h: In function 'avg_no_rnd_pixels8_mmx':
libavcodec/i386/dsputil_mmx_rnd.h:322: error: syntax error before 'ASMALIGN'
libavcodec/i386/dsputil_mmx_rnd.h: In function 'avg_no_rnd_pixels16_mmx':
libavcodec/i386/dsputil_mmx_rnd.h:341: error: syntax error before 'ASMALIGN'
libavcodec/i386/dsputil_mmx_rnd.h: In function 'avg_no_rnd_pixels8_x2_mmx':
libavcodec/i386/dsputil_mmx_rnd.h:364: error: syntax error before 'ASMALIGN'
libavcodec/i386/dsputil_mmx_rnd.h: In function 'avg_no_rnd_pixels8_l2_mmx':
libavcodec/i386/dsputil_mmx_rnd.h:384: error: syntax error before 'ASMALIGN'
libavcodec/i386/dsputil_mmx_rnd.h: In function 'avg_no_rnd_pixels16_x2_mmx':
libavcodec/i386/dsputil_mmx_rnd.h:405: error: syntax error before 'ASMALIGN'
libavcodec/i386/dsputil_mmx_rnd.h: In function 'avg_no_rnd_pixels16_l2_mmx':
libavcodec/i386/dsputil_mmx_rnd.h:431: error: syntax error before 'ASMALIGN'
In file included from libavcodec/i386/dsputil_mmx.c:164:
libavcodec/i386/dsputil_mmx_rnd.h: In function 'avg_pixels4_mmx':
libavcodec/i386/dsputil_mmx_rnd.h:302: error: syntax error before 'ASMALIGN'
libavcodec/i386/dsputil_mmx_rnd.h: In function 'avg_pixels8_mmx':
libavcodec/i386/dsputil_mmx_rnd.h:322: error: syntax error before 'ASMALIGN'
libavcodec/i386/dsputil_mmx_rnd.h: In function 'avg_pixels16_mmx':
libavcodec/i386/dsputil_mmx_rnd.h:341: error: syntax error before 'ASMALIGN'
libavcodec/i386/dsputil_mmx_rnd.h: In function 'avg_pixels8_x2_mmx':
libavcodec/i386/dsputil_mmx_rnd.h:364: error: syntax error before 'ASMALIGN'
libavcodec/i386/dsputil_mmx_rnd.h: In function 'avg_pixels8_l2_mmx':
libavcodec/i386/dsputil_mmx_rnd.h:384: error: syntax error before 'ASMALIGN'
libavcodec/i386/dsputil_mmx_rnd.h: In function 'avg_pixels16_x2_mmx':
libavcodec/i386/dsputil_mmx_rnd.h:405: error: syntax error before 'ASMALIGN'
libavcodec/i386/dsputil_mmx_rnd.h: In function 'avg_pixels16_l2_mmx':
libavcodec/i386/dsputil_mmx_rnd.h:431: error: syntax error before 'ASMALIGN'
libavcodec/i386/dsputil_mmx.c: In function 'get_pixels_mmx':
libavcodec/i386/dsputil_mmx.c:210: error: syntax error before 'ASMALIGN'
libavcodec/i386/dsputil_mmx.c: In function 'diff_pixels_mmx':
libavcodec/i386/dsputil_mmx.c:238: error: syntax error before 'ASMALIGN'
libavcodec/i386/dsputil_mmx.c: In function 'put_pixels4_mmx':
libavcodec/i386/dsputil_mmx.c:381: error: syntax error before 'ASMALIGN'
libavcodec/i386/dsputil_mmx.c: In function 'put_pixels8_mmx':
libavcodec/i386/dsputil_mmx.c:407: error: syntax error before 'ASMALIGN'
libavcodec/i386/dsputil_mmx.c: In function 'put_pixels16_mmx':
libavcodec/i386/dsputil_mmx.c:433: error: syntax error before 'ASMALIGN'
libavcodec/i386/dsputil_mmx.c: In function 'vector_fmul_add_add_3dnow':
libavcodec/i386/dsputil_mmx.c:2898: warning: implicit declaration of function 'f f_vector_fmul_add_add_c'
libavcodec/i386/dsputil_mmx.c: In function 'dsputil_init_mmx':
libavcodec/i386/dsputil_mmx.c:3418: error: 'struct DSPContext' has no member nam ed 'vector_fmul'
libavcodec/i386/dsputil_mmx.c:3420: error: 'struct DSPContext' has no member nam ed 'float_to_int16'
libavcodec/i386/dsputil_mmx.c:3423: error: 'struct DSPContext' has no member nam ed 'vector_fmul_reverse'
libavcodec/i386/dsputil_mmx.c:3426: error: 'struct DSPContext' has no member nam ed 'vector_fmul'
libavcodec/i386/dsputil_mmx.c:3427: error: 'struct DSPContext' has no member nam ed 'float_to_int16'
libavcodec/i386/dsputil_mmx.c:3428: error: 'struct DSPContext' has no member nam ed 'vector_fmul_reverse'
libavcodec/i386/dsputil_mmx.c:3429: error: 'struct DSPContext' has no member nam ed 'vector_fmul_add_add'
libavcodec/i386/dsputil_mmx.c:3432: error: 'struct DSPContext' has no member nam ed 'vector_fmul_add_add'
make: *** [libavcodec/i386/dsputil_mmx.o] Error 1

[haruhiko_yamagata]

haruhiko_yamagata


But now i found source of problem. Damn Haali Media Splitter. It`s time to connect them with Norton Wipeinfo :) . With Gabest and Nero splitters all fine. Interesting, that ffdshow had time to decode about 20 frames before player crashed
Confirmed. When MPC's internal filter-"MP4/MOV" turned off, ffdshow-20060730-Q.exe or ffdshow-20051115.exe does not crash, but the picture is blocky and there's no sound. So the culplit is *likely* the parser filter.

[foxyshadis]

Sorry, it compiled with 3.4.x so I assumed it would elsewhere. I reimported a little more carefully and I'm pretty sure I fixed it now, if you could recompile that'd be great.