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 ?

[foxyshadis]

Not right now, some ffmpeg updates broke compatibility. It's only worthwhile for debugging, anyway, since it can't compile any of the assembly code. (Can ICL compile ffmpeg natively? I haven't tried, ICL doesn't work right for me since I upgraded to VS2005SP1, always internal linker errors about bad debug information.)

[Peuj]

Hi,

I use the lastest MPC rev611-3.2 and ffdshow_rev731_20061230_clsid.exe

When I try to play the mov from this link:
http://www.jeuxvideo.fr/telecharger-video-1-cinematique-d-introduction-39197.html

MPC freezes and I have to kill it. Something wrong with H.264 ?

Thanks

[fastplayer]

Plays fine here except I hear no sound. Don't know which decoder is needed...

Edit: It's IMA4 Audio. Trailer plays fine.

[Peuj]

Plays fine here except I hear no sound. Don't know which decoder is needed...

Edit: It's IMA4 Audio. Trailer plays fine.

Video #0
Codec : H.264
Codec/Info : H.264 (3GPP)
PlayTime : 1mn 42s
Bit rate : 2055 Kbps
Width : 720 pixels
Height : 486 pixels
Aspect ratio : 4/3
Frame rate : 29.970 fps
StreamSize : 25.1 MiB

Audio #0
Codec : ADPCM
PlayTime : 1mn 42s
Bit rate : 384 Kbps
Channel(s) : 2 channels
Resolution : 16 bits
StreamSize : 4.68 MiB


OK thanks. Something wrong on my computer so. :(

[SeeMoreDigital]

Yep... it plays fine for me too!

[fastplayer]

OK thanks. Something wrong on my computer so. :(
I'm using exactly the same version of MPC (system default renderer) and ffdshow as you. Maybe the file is broken... :?

[clsid]

Btw what happend to the snow? its several revs behind. i patched ffdshow with latest snow code from ffmpeg, playback seem to work fine here(encoded with latest mencoder).You can commit the patch to SVN if you want.
Could you also upload a sample SNOW file encoded with mencoder for all of us to put in our collections?

[_xxl]

http://forum.doom9.org/showthread.php?p=923987#post923987
Snow should be removed.

[clsid]

SNOW isn't backward compatible. But supporting playback of the latest version is better than no support at all.

[Taurus]

Hi,

I use the lastest MPC rev611-3.2 and ffdshow_rev731_20061230_clsid.exe

When I try to play the mov from this link:
http://www.jeuxvideo.fr/telecharger-video-1-cinematique-d-introduction-39197.html

MPC freezes and I have to kill it. Something wrong with H.264 ?

Thanks
With newest Haali's Media Splitter enabled I've got no sound too.
Haali's disabled - everythings just fine.
Apps same as mentioned in the quote.

[F_L_C]

Why don't you guys delete "Nightly builds by videomixer9" from the download page because it's apparent this developer is no longer active. The last updates were 5 months ago.

Also, one of clsid's old generic builds (rev696) somehow got placed into Q's old generic builds.

[Episode]

I'm pretty sure videomixer9 will eventually come back and start updating his builds again. Also, since he was one of the founding members of this project (ffdshow-tryouts), it wouldn't be nice to remove he's builds ;-)

[foxyshadis]

They're just builds, they can be remade or reuploaded. They should probably go in an 'archived builds' section otherwise. Once in a while it helps to test really old builds when checking out when a bug appeared.

[edit] Too late, they've already been set hidden. :p

[Inventive Software]

Feature request: incorporate libavformat and have it similar to ffdshow's configuration currently. Not sure how practical this is, but it'd be nice for ffdshow to have the source "splitters" or container formats support as well as the codecs, thus making ffdshow the premier DShow filter. :)

[Peuj]

With newest Haali's Media Splitter enabled I've got no sound too.
Haali's disabled - everything just fine.
Apps same as mentioned in the quote.

Ok the problem was that the nero splitter was used instead of ffdshow. I have changed the merit filter with GSpot to use ffdshow.

About the sound I have enabled IMA ADPCM in ffdshow audio and I have no problem with Haali.

Just to know: is there another way to change the merit filter instead GSpot ?

Thanks

[HeadBangeR77]

(...)

Just to know: is there another way to change the merit filter instead GSpot ?

Thanks

This is obviously an OT, but here you are:

http://www.softella.com/dsfm/index.en.htm

the best tool for setting merits I've ever used - freeware and a single executable only ;)

In order to remain in the main topic:
I installed a new nightly build yesterday, namely 'ffdshow_rev735_20070102_xxl', and the 'about section' says it is in fact tryout revision 621. The rest (e.g. dates of compilation of different libraries) seems to be up-to-date, so I hope it's just a simple typo, isn't it?

Btw. I've been reading through Doom9's Forums for years before registering and posting - believe me or not, but it's a strange feeling, this 'first time', like experiencing deja-vu :D ;)

cheers /HeadB.

[wyrd]

It seems good for me.
ffdshow_rev735_20070102_xxl.exe MD5:BE9C97EB299EAA9B68F0E66ADC64CEB4
http://tirnanog.fate.jp/tmp/snap/xxl_735_t.jpg (http://tirnanog.fate.jp/tmp/snap/xxl_735.jpg)

@Peuj,as you please
http://tirnanog.fate.jp/tmp/snap/dftools_t.jpg (http://tirnanog.fate.jp/tmp/snap/dftools.jpg)
Thanks

[HeadBangeR77]

@ wyrd

I already know what I did: I uninstalled the previous version (621) and installed the newer one (735), then messed up with some settings, and returned to the old ones by adding them to the registry from my back-up files. Those back-ups contain all decoder settings, including version and compilation date. Weird, the compilation date (2nd of Jan) is all right, the revision number was taken from the old build :D

Are those registry values (build number and compilation date) there for a certain reason (I mean the exported back-ups, of course), or just to make a humble user crazy in the middle of the night? ;) ;) ;)

[Dark_Angel_PT]

drevil_xxl:
Do you own the domain in your sig?
Why doesn't it directs to the new webpage (that i personally like BTW)at ffdshow-tryout.sourceforge.net ?


I posted two suggestions to the OSD in the ffdshow forum, would like to know what you think...

http://ffdshow-tryout.sourceforge.net/phpBB2/viewtopic.php?t=226

[foxyshadis]

http://www.zend.com/forums/index.php?t=msg&goto=2272&S=747c3b529f3fe9d65756e24d1d443699

Do you guys think this will be useful? It could be used to automatically update the version resource (mainly for zoomplayer and the curious) as well as the rev numbers in the build scripts.

[Yong]

My lastest build, for testing only
http://y0ngc6.googlepages.com/ffdshow_rev738_20070105.exe
compiled with lastest snow code from ffmpeg,
and the ffmpeg binary
http://y0ngc6.googlepages.com/ffmpeg-r7407.7z

NOTE: the snow bitstream has changed, do not use older snow created by old revision of mencoder/ffmpeg to play with this build.

[haruhiko_yamagata]

http://www.zend.com/forums/index.php?t=msg&goto=2272&S=747c3b529f3fe9d65756e24d1d443699

Do you guys think this will be useful? It could be used to automatically update the version resource (mainly for zoomplayer and the curious) as well as the rev numbers in the build scripts.
SubWCRev.exe depends on TortoiseSVN. Considering most of us are using TortoiseSVN, it may be usefull. But the code should be written carefully not to depend too much on TortoiseSVN. At least have to work around if TortoiseSVN is not used for the working copy. Too hard :scared: .

The registry where to store revision need reconsidering.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ffdshow_is1 may be better.

[clsid]

If TortoiseSVN is installed, then verinc.exe should use the the revision as micro version. Else increment existing version (current behaviour).

Another possibility would be to remove verinc.exe completely and manually adjust the version. I think that manually adjusting the version once every X revisions (25,50,100?) will be enough.

Edit: Changing the registry key location has some major downsides. First, InnoSetup overwrites the uninstall key at the end of the installation. So keys also need to be written at the end from [code] section to prevent them from being deleted. Second, using the uninstall key binds the info explicitly to our installer. So the info can't be used by NSIS installer, codec packs, etc.

[chros]

I'm using Winamp's DFX plugin for a long time, to increase the audio quality.
There's a new version of it (8.0) which can deal with multichannel source ! But ffdshow doesn't allow to connect them ...
There's a source which shows the splitter that it has only 2ch audio but it has true 5.1: it works well with DFX.

Can you do anything about this?

Thanks

[dk75]

maybe you should post the sample of this file with 5.1ch/2ch problem?

[haruhiko_yamagata]

libmpeg2 : bug fix : MPEG 1/2 seek issue.
Crash and artifact on seek(or startup) is fixed.
Now we can seek better in FruitBeer.vob.
No more green artifact at the startup of hbo_trailer_6ksd.ts.
No more crash on seek in this sample (http://www.stronger.jp/figure/dl/pv/figurehead_pv.lzh). To reproduce:With Zoom player + gabest's MpegSplitter, it crashes on first few seeks. If you secceeded several times, you have to restart the application.

[fastplayer]

:thanks: a bunch for the fix!
This should get ffdshow's MPEG2 decoder closer to MPC's which has no problems playing these files back by the way.

[cc979]

just tried to compile rev.752 usinggcc-4.0.3 i get this

make[1]: *** [FLT_ffdshow.o] Error 1
make[1]: Leaving directory `/home/user/svn/ffdshow-tryout/trunk/dscaler'
make: *** [DSCALER] Error 2

[_xxl]

The same error:
FLT_ffdshow.cpp:174:2: warning: no newline at end of file
../src/imgFilters/avisynth/avisynth.h: In member function 'int VideoInfo::GetPlaneWidthSubsampling(int) const':
../src/imgFilters/avisynth/avisynth.h:228: error: exception handling disabled, use -fexceptions to enable

-fno-exceptions is used.

[Yong]

try "make EXCEPTIONS=1"

[foxyshadis]

I fixed avisynth.h so it doesn't rely on exceptions again (unnecessary for what it does).

[MatMaul]

Hello !
I proposed some adds for the audio part of ffdshow :

- Add a volume control on the left click of the audio ffdshow icon in the system tray, like with the Windows mixer icon :

http://www.etud.insa-toulouse.fr/~mvelten/volume.png

- Add an option to reset the volume control when the filter is loaded, to not have a +15dB if the volume of the audio is high :p

http://www.etud.insa-toulouse.fr/~mvelten/reset.png

[clsid]

List of known issues in revision 755:

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)

Other bug reports:

3) The following encoders do not work for me: MPEG 1, MPEG 2 and DV (does DV have input limitations like H263?). VirtualDub 1.6.17 gives the following error: "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100)". (reported by: clsid)
4) 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)
5) There is an abnormal increase in CPU usage when the ffdshow audio panel is open during playback. (reported by foxyshadis)
6) Queue is off in Overlay Mixer. (reported by clsid)
7) ffdshow raw filter doesn't work in ZoomPlayer. (reported by midiboy)

ToDo:

8) Update SNOW
9) Fix VMnc decoding
10) Fix libavcodec VC-1 decoding
11) 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:

12) 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)

[Episode]

@clsid, for some reason my computer decided to reboot itself automaticly after installing your latest build (752). I didn't see any question whether I want to reboot my computer, so I assume that it's a bug since it happened again when I tried to install it again.

[clsid]

Are you sure that there wasn't a restart option on the last page of the installation wizard?



@all, since this topic is getting very long, I have created a fresh topic. So please continue the discussions there:
http://forum.doom9.org/showthread.php?t=120465

If a mod reads this, please lock this topic.

[Episode]

Yes, I'm sure. I can reproduce this bug every time I try to install build 752. However, it doesn't happen with any other builds. There isn't any restart option on the last page. And if there is a need for restart, the installer should ask again if you really want to do that :)

[clsid]

It uses the same install script as previous builds. Also if a restart is needed, InnoSetup will always give an option. Perhaps ffdshow is causing a BSOD which makes your computer restart.

I'll put a new build online.

[Episode]

It wasn't a BSOD, but that doesn't matter anymore since the new build seems to install correctly without restart. Thanks a lot.