New ffdshow build (?)

[fastplayer]

How did you fix the odd line bug? AFAIK, YV12 output has to be a multiple of 2 for height and width. Did you "secretly" add one line to output?

[haruhiko_yamagata]

How did you fix the odd line bug? AFAIK, YV12 output has to be a multiple of 2 for height and width. Did you "secretly" add one line to output?
Yes, I did. Just added one line at the bottom.

[fastplayer]

As for VMR9, maybe the latest DirectX SDK is needed. MS fixes quite a few bugs from time to time...

Edit: Forget about that. Just went through the changelogs of the previous releases and not one word about VMR... :/

[clsid]

Now YV12 plays better than before in odd line numbers.
STORMAHEAD_PodsTrailer.mov as well as many files from YouTube plays better.

I still have issue in VMR9, but I'm sure it's VMR9's responsibility unless using YV12 in VMR9 of itself is wrong.

Do you agree to adding an option like "Disable YV12 in VMR9" and set it to default?
Because YV12 is the fastest, I think we need a poll.

I guess it should work in DVD resolution. Please test using resize to small(dx<320) and large size(dx>1024).
I tried several small and large horizontal video sizes with YV12 in VMR-9 (renderless) and all played ok. So I guess this depends on the graphics card or drivers.

The YV12 odd resolution fix works great. Thanks!

The color shift problem with "beyonce.at.the.bbc.1080mbaff.sample.ts" only happens in Overlay for me. In VMR-9 it plays ok. If I use the resizer in ffdshow then it also works ok in Overlay, but only if the horizontal size is smaller than 344.

[fastplayer]

The color shift problem with "beyonce.at.the.bbc.1080mbaff.sample.ts" only happens in Overlay for me. In VMR-9 it plays ok. If I use the resizer in ffdshow then it also works ok in Overlay, but only if the horizontal size is smaller than 344.
Confirmed. All output modes in MPC work except Overlay Mixer.

[foxyshadis]

Drevil, is there any reason for icl project files to include "libirc.lib libm.lib svml_disp.lib" or were those accidentally added?

Edit: Ugh, I'm such a space case, I finally noticed while debugging that it came down to ffdshow (or ffmpeg? still investigating) returning bad frame numbers for IDFF_currentFrame, sometimes duplicates and sometimes skipping. That's "useful", since avisynth relies on those. >.> I'll write back if I find a workaround or a fix.

[clsid]

Drevil, is there any reason for icl project files to include "libirc.lib libm.lib svml_disp.lib" or were those accidentally added?
Yes, those are required. Without them there will be linker errors.

[foxyshadis]

Oh, I see why now. I was loading it from the vcproj and not the icproj when I compiled it today, sorry.

[Inventive Software]

I tested the VFW encoder side of ffdshow. rev 696, the following encoders worked, assume those not listed didn't work.

libavcodec

MPEG-4
MPEG-1
MPEG-2
Lossless JPEG
HuffYUV
FFV1
DV

libtheora
Theora

wmv9 (Note: these encoders used the default WMP10 codecs after installation of WMP10)

Windows Media Video 9
Windows Media Video 9 Advanced Profile (WMVA, not WVC1)
Windows Media Video 9 Screen
Windows Media Video V7
Windows Media Video V8

All other codecs chucked out a "Cannot start encoder (-100)" error in VirtualDub 1.7.0. The source used was an AviSynth input size 720x576@25 FPS, YV12 colourspace. The settings used were the defaults for each codec, 1 pass quality 80.

I will try an old tryouts revision, as well as an old ffdshow revision to determine when the encoder support was broken.

What I should have mentioned is that encoders were tested with 2 threads. 1 thread, and the following codecs FAILED (assume those not listed worked)

libavcodec
H.263
H.261

Multithreading's broken in a lot of codecs it seems. ;)

[_xxl]

Multithreading's broken in a lot of codecs it seems. ;)
multithreaded/SMP encoding for MPEG1/MPEG2/MPEG4/H263
was added in ffmpeg(libavcodec) in rev 2772 & 2778.
Here are some results:
libavcodec h263+:
http://i16.tinypic.com/2rxbm80.jpg
libavcodec mpeg4 xvid:
http://i13.tinypic.com/3zluejo.jpg

[Mangix]

got a question about SSE and SSE2 builds. are they supposed to decrease the decoding time so that videos load faster? i just tried one of celtic_druid's mplayer builds and i noticed that H.264 was faster than drevil_xxl's rev 730 build of ffdshow. actually, it was really unbearable.

[clsid]

You can't compare mplayer with ffdshow. Mplayer has always been a bit faster because it doesn't use DirectShow.

[Mangix]

i don't mean a bit faster. i mean WAY faster. i know that ffdshow uses DirectShow, but i never imagined that there's a huge difference between it and mplayer. i mean with mplayer, i can get clear and smooth playback on a 1280x720 file(quite large i know). on ffdshow, it does 15-20 fps.

[_xxl]

Mplayer is faster.If compiled with "FAST" is more faster but less quality.Some ffdshow filters can use SSE(2).Decoding parts are written in hand-optimized assembler for maximum speed.

[Mangix]

so i take it that there is SOME optimization in libavcodec's H.264 decoding code?

[fastplayer]

This has been discussed over and over again --> :search:
Quote from http://en.wikipedia.org/wiki/Ffdshow
A common misconception is that ICL SSE/SSE2 builds will decode video better than "generic" builds. In fact, the video decoders are always compiled in gcc and are usually hand-optimized; it's the ffdshow filters that benefit from ICL.

[Mangix]

doesn't that only apply to ICL builds :p

anyways, if that quote is true for all the builds, then i guess the actual decoding speed is not affected.

[clsid]

You could try enabling "skip H.264 deblocking" in ffdshow. That will increase performance considerably. At the cost of a little lower output quality.

[Yong]

Compiling error with lastest svn (gcc4.0.3)...
$ make -s
In file included from ../imgFilters/avisynth/Tavisynth.h:5,
from Tacm.h:5,
from Tacm.cpp:21:
../imgFilters/avisynth/avisynth.h:349: error: integer constant is too large for 'long' type
../imgFilters/avisynth/avisynth.h: In member function 'BYTE* VideoFrame::GetWritePtr() const':
../imgFilters/avisynth/avisynth.h:500: error: '_ASSERT' was not declared in this scope
../imgFilters/avisynth/avisynth.h: In member function 'BYTE* VideoFrame::GetWritePtr(int) const':
../imgFilters/avisynth/avisynth.h:509: error: '_ASSERT' was not declared in this scope
make[1]: *** [Tacm.o] Error 1
make: *** [lib] Error 2

[foxyshadis]

ffdshow and mplayer should have raw decoding speeds within a couple fps of each other if everything else is the same - no ffdshow filters, obviously, yuv output, and using overlay renderer, as well as no upstream, downstream, or audio filters hogging cpu time. Those latter parts ffdshow has no control over, and are just perils of directshow.

Graphedit is a quick way to check what filters show up, or mpc's filters menu, though it's hard to tell what should and shouldn't be there without doing this stuff a lot. Basically it should be something like:

file -> ffdshow video -> video renderer
\-> ffdshow audio -> directsound

Edit: GCC doesn't like the avisynth.h update? Okay, I'll check that.

Edit 2: That should do it.

[fastplayer]

I noticed the ffdshow audio mixer takes a lot of cpu time, at least in the recent past, even when it's just doing 2.0->2.0, so you might check whether that's enabled.
How did you measure this and compared to what (MPC's internal audio filters?)?

[foxyshadis]

How did you measure this and compared to what (MPC's internal audio filters?)?

Not ffdshow's audio decoder, the mixer filter (mpc doesn't have anything comprable). CPU usage spiked considerably, so it's always off.

But thanks for making me test again, because I found I was wrong - it's having the audio panel open that does it, not whether mixer is on or off. :o Must be a case of refreshing the gui too much; I guess I don't have to leave it off after all.

SVN should be fixed.

[fastplayer]

But thanks for making me test again, because I found I was wrong - it's having the audio panel open that does it, not whether mixer is on or off.
Yes, I can confirm this behavior too.

[_xxl]

AAC audio decoding bug:
http://forum.doom9.org/showthread.php?t=119932

[_xxl]

I have some test results.
Rev 730 sse2 + h.264 sample + MPC latest.
first play:
http://i16.tinypic.com/3z0sqoz.jpg
second play:(don't exit MPC)
http://i13.tinypic.com/2ed6xle.jpg
third play:(don't exit MPC)
http://i11.tinypic.com/30mqxp4.jpg
Just what am I looking at?I don't understand.
http://i12.tinypic.com/2u8w5zm.jpg
If I exit MPC and play this sample again I'll get first case.
If I stop and play again in MPC I get case 2 or 3.

[foxyshadis]

Try process explorer's single aggregate graph, in process properties. Or just set MPC's affinity to one CPU. You'll find the graphs are mostly stable, and all you're seeing is the kernel's habit of tossing threads around in strange fashions. It doesn't really affect performance to execute half-and-half on two cpus instead of one.

[Yong]

rev 734 fixed the gcc compiling error, Thx. but i have to use EXCEPTIONS=1 when compiling, is that normal?

Btw what happend to the snow? its several revs behind. i patched ffdshow with latest snow code form ffmpeg, playback seem to work fine here(encoded with latest mencoder).

[_xxl]

Snow is buggy.
Latest snow is not compatible with old version from ffdshow.

[foxyshadis]

Should we just update it, mention its instability like we used to for FFV1, and point to a specific version (like beta 1) for decoding old versions of snow? Perpetuating an outdated version might only lead to more problems.

[Liisachan]

Using vstrict=-2 means that you know what you are doing.
That's a bit different than being 'buggy' as you were already warned.


Snow is an experimental wavelet-based codec made by the FFmpeg developers,
and while it is still in heavy development, it is already giving very good
results.
Be very careful though, as the format of the bitstream produced might
change, do not rely on it to store videos that you value.
For this reason, MEncoder will not encode without 'vstrict=-2' on the
command line.

http://www.mplayerhq.hu/DOCS/tech/snow.txt

[Jeremy Duncan]

clsid,

May I ask you to post another generic FFDshow with the latest revision.

:thanks:

[haruhiko_yamagata]

I found a bug in YV12 and odd number lines.
With old video renderer, it sometimes crashes. When aplication finishes or changed to full screen.

[fastplayer]

I can't reproduce it with the STORMAHEAD_PodsTrailer.mov video.
Using latest MPC (old renderer), ffdshow rev731, XP SP2, and Radeon X800 GTO with 6.11 CAT driver.

Edit: One odd thing happened though: MPC doesn't rewind even though "Rewind when done playing" is checked. I don't know if this has anything to do with it...
Edit2: Checked with all 3 samples (http://tirnanog.fate.jp/tmp/odd_line/) provided by user wyrd and no crashes here...

[Inventive Software]

I want to clear up the VFW encoders tests I did. Here goes.

I tested ffdshow_tryout rev 696 (clsid) and ffdshow rev 2546 20060603 (videomixer9). Both produced identical results. Sample used was AviSynth 720x576@25FPS. H.263 and H.261 tested with 352x288@25FPS.

The following encoders worked with 1 thread:

libavcodec
MPEG-4
DivX 3
MS MPEG-4 V2
MPEG-1
MPEG-2
H.263
H.263+
H.261
WMV7
WMV8
MJPEG
Lossless JPEG
HuffYUV
FFV1
DV
FLV1

libtheora
Theora

wmv9
Windows Media Video 9
Windows Media Video 9 Advanced Profile (WMVA)
Windows Media Video 9 Screen
Windows Media Video V7
Windows Media Video V8

The following codecs failed to work and produced a -100 error in VirtualDub:

wmv9
Windows Media Screen V7
Windows Media Video 9 Image
Windows Media Video 9 Image v2
(This is because they're for single images only, is my guess)

The following codecs worked with 2 threads:

libavcodec
MPEG-4
MPEG-1
MPEG-2
Lossless JPEG
HuffYUV
FFV1

libtheora
Theora

wmv9
Windows Media Video 9
Windows Media Video 9 Advanced Profile (WMVA)
Windows Media Video 9 Screen
Windows Media Video V7
Windows Media Video V8

The following encoders failed to work and produced a -100 error in VirtualDub:

DivX 3
MS MPEG-4 V2
H.263
H.263+
WMV7
WMV8
MJPEG
DV
FLV1

wmv9
Windows Media Screen V7
Windows Media Video 9 Image
Windows Media Video 9 Image v2
(Again, these are single frame codecs I think)
(Note: the lossless codecs and H.261 don't have a threads box in the config pages)

Multithreading (i.e threads > 1) is therefore broken in the following codecs:

libavcodec
DivX 3
MS MPEG-4 V2
H.263
H.263+
WMV7
WMV8
MJPEG
DV
FLV1

Hope that makes everything more clearer.

EDIT: Updated with correct resolutions for H.263 and H.261, H.263's broken with multithreading.

[Yong]

IIRC h261 and h263 encoder only works with specific resolution,
for h261 are 176x144 and 352x288.
for h263 are 128x96, 176x144, 352x288, 704x576 and 1408x1152.

[Inventive Software]

That might explain why I couldn't get them to work then.

[_xxl]

libavcodec decode:
int numthreads=deci->getParam2(IDFF_numLAVCdecThreads);
if (numthreads>1 && mpeg12_codec(codecId))
libavcodec->avcodec_thread_init(avctx,threadcount=numthreads);
else
threadcount=0;
libavcodec encode:
if (coCfg->numthreads>1 && sup_threads(coCfg->codecId))
libavcodec->avcodec_thread_init(avctx,threadcount=coCfg->numthreads);
else
threadcount=0;

Multithreading encoding was added in 2004.

[Inventive Software]

So proper multithreaded decode is only with MPEG-1 and MPEG-2... right?

[wyrd]

I found a bug in YV12 and odd number lines.
With old video renderer, it sometimes crashes. When aplication finishes or changed to full screen.
I confirmed it in rev731,732 (in my case, open view -> option)
samples (http://tirnanog.fate.jp/tmp/odd_line/)
Regards

[clsid]

List of known issues in revision 736:

1) Wavpack decoder only works with lossless wavpack. Lossy and hybrid wavpack is not yet supported.
2) Some files with interlaced H.264 video don't decode properly. Sample file (http://www.egoshare.com/9dad3c13be3968c0ed977ed5cd62e25f/3rd_rock_of_sun_sampleavi.html). FFmpeg bug or perhaps a x264 VFW bug? (Reported by Romario)
3) Encoding fails if threads > 1 for the following formats: DivX 3, MS MPEG-4 V2, H.263(+), WMV7, WMV8, MJPEG, DV and FLV1.

Other bug reports:

4) Writing an OGM file via VFW interface creates a corrupt file. (reported by clsid)
5) FLV muxer seems to be buggy as well.
6) The following encoders do not work for me: MPEG 4, MPEG 1, MPEG 2 and DV. VirtualDub 1.6.17 gives the following error: "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100)". At least some of these encoders do work for others? Seems to depend on the input? Sample input file (http://www.mytempdir.com/1105695). (reported by: a few people)
7) I think I have found a bug in the ffdshow subtitle filter. If I slow down the playback speed of the video in Media Player Classic, then the subtitles will continue to play at their normal speed. So the subs go faster than the video and synchronization is lost. After changing the playback speed back to normal, the subtitles will synchronize and continue at the correct position. (reported by clsid)
8) There is an abnormal increase in CPU usage when the ffdshow audio panel is open during playback. (reported by foxyshadis)
9) Queue is off in Overlay Mixer. (reported by clsid)
10) ffdshow raw filter doesn't work in ZoomPlayer. (reported by midiboy)

ToDo:

11) Update SNOW
12) Fix VMnc decoding
13) Fix libavcodec VC-1 decoding
14) H.261 and H.263 encoders only support specific resolutions. An error message should be added and shown when an unsupported input resolution is used. H.261 supports 176x144 and 352x288. H.263 supports 128x96, 176x144, 352x288, 704x576 and 1408x1152.

Other issues:

15) ICL9 builds of ffdshow.ax crash on files created by a specific old revision of x264 (don't know the rev number). These files should be very rare. Funny thing however is that the files play fine and without crash if you first play another file and then play the '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)

[Jeremy Duncan]

libavcodec decode:
int numthreads=deci->getParam2(IDFF_numLAVCdecThreads);
if (numthreads>1 && mpeg12_codec(codecId))
libavcodec->avcodec_thread_init(avctx,threadcount=numthreads);
else
threadcount=0;
libavcodec encode:
if (coCfg->numthreads>1 && sup_threads(coCfg->codecId))
libavcodec->avcodec_thread_init(avctx,threadcount=coCfg->numthreads);
else
threadcount=0;

Test my new build:
http://www.mytempdir.com/1145846

It works fine on my Pentium M 725.

Did you tweak how FFDshow multithreads ?

[Blight]

A couple of requests:

1. Can you expose the subtitle streams as an IAMStreamSelect interface with an option to select each subtitle stream and a last option to hide/show the subtitles?

2. Can you create a separate instance of ffdshow for the
subtitle filter (similar to how you have the RAW filter). This would make subtitling much more flexible (design-wise).

[MacAddict]

Hmm, wonder if it's possible to display 'queue samples' in the info window as well? As it is the only way to see it is to have OSD turned on right?

Looks like plenty of space exists just below the line that shows 'current frame' :-)

[Kurtnoise]

I've got some errors (http://kurtnoise.free.fr/BuildLog.htm) during lavc compilation...Any ideas ?

[_xxl]

Libavcodec can be compiled by MinGW GCC 3.4.x or 4.0.x.

[Inventive Software]

@clsid: You can update your "threads > 1 broken" list with H.263 as well.

[Romario]

Libavcodec can be compiled by MinGW GCC 3.4.x or 4.0.x.

Why not with 4.1.x or 4.2.x ?

[Px]

I compiled ffdshow with wvc1 support in wmv9lib.
Please enable vc1 from codec list.
http://www.mytempdir.com/1129848
I've finally got some time to do this, with FlightSimX_720p60_51_15Mbps.wmv and Test_1440x576_WVC1_6Mbps.wmv all works fine, cpu usage similar to ms codecs

[_xxl]

I've finally got some time to do this, with FlightSimX_720p60_51_15Mbps.wmv and Test_1440x576_WVC1_6Mbps.wmv all works fine, cpu usage similar to ms codecs
wmv9lib uses ms codecs to decode WVC1.You need to have WMP11 or ms vc1 codec.

[Kurtnoise]

Libavcodec can be compiled by MinGW GCC 3.4.x or 4.0.x.
...and can't be compiled with MSVC ?