New ffdshow build (?)

[clsid]

The InnoSetup install script now puts the revision and builddate in the registry.

All recent builds are pretty stable.

[foxyshadis]

Small feature request - in OSD menu field "Input bitrate" shows average input bitrate. Could you add ability to see current input bitrate, not average?

How about frame size, then? You can't get any more current than that. If you want something a little closer to most bitrate analysis tools, which smooth bitrate over a half second to one second window, it's possible to come up with something.

[LoRd_MuldeR]

I've just installed ffdshow_rev598_20061127_clsid.exe, but the About page says:

http://img281.imageshack.us/img281/5998/clipboard01ph3.png

However when I go to file properties of ffdshow.ax, it says:
"Build Date" = "27/11/2006 - 15:19:24UTC"

[Px]

How about frame size, then?
It won't help...
You can't get any more current than that.
Media Player Classic shows both average and current bitrate, but doesn't log to file :(, I asked for such functionality in this topic - http://forum.doom9.org/showthread.php?t=101835&page=59, but got no answer at this moment....

[devaster]

can someone give some info where is a point where is applied settings when is ffdshow started ? i have written GPU (i)dct and i cannot find a location where is this selected (for libavcodec). GUI settings i have modified but code ...

[zambelli]

How do the new (*rev*clsid) ffdshow builds hosted on x264.nl compare to the old ones (*gcc*sse)? Same/better functionality? Same/better performance?

[foxyshadis]

can someone give some info where is a point where is applied settings when is ffdshow started ? i have written GPU (i)dct and i cannot find a location where is this selected (for libavcodec). GUI settings i have modified but code ...

ffdshow:
CdecoderOptions.cpp <-- backend of the GUI
Tlibavcodec.cpp <-- set the name/order here, in idctNames
TvideoCodecLibavcodec.cpp <-- avctx->idct_algo gets set to the IDCT here. Don't forget to bump the 6 to a 7.

ffmpeg:
avcodec.h <-- Add a define for yours here. Starts with FF_IDCT_AUTO
dsputil.c <-- where the grunt work happens, in dsputil_init(). Everything's done with function pointers, so include your header and add your newidct.c to the project. See simple_idct.c/h for an example.

[devaster]

ffdshow:
CdecoderOptions.cpp <-- backend of the GUI
Tlibavcodec.cpp <-- set the name/order here, in idctNames
TvideoCodecLibavcodec.cpp <-- avctx->idct_algo gets set to the IDCT here. Don't forget to bump the 6 to a 7.

ffmpeg:
avcodec.h <-- Add a define for yours here. Starts with FF_IDCT_AUTO
dsputil.c <-- where the grunt work happens, in dsputil_init(). Everything's done with function pointers, so include your header and add your newidct.c to the project. See simple_idct.c/h for an example.

:thanks: :thanks: :thanks: foxyshadis

some things i have found another I change

another little question : is somewhere some comments/docs to the code ?

[seewen]

List of known issues in revision 562:

Reported but unconfirmed bugs:

5) The following encoders do not work for me: MPEG 4, MPEG 1, MPEG 2, h.263, H.261 and DV. VirtualDub 1.16.16 gives the following error: "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100)". I know that at least some of these encoders do work for others. My system specs: Windows 2000, AMD Athlon Thunderbird. (reported by clsid)



Same here.
My spec system: Windows Vista, Core 2 duo e6600.
But I've got the same problem with old build (ffdshow-tryouts-rev127 for example). And it works with ffvfw-20031028 (MPEG-4)


Sorry I don't know if it's the right place to post...

[Romario]

@Romario, please upload a small sample file.

OK, here it is. Small 50 second sample is on http://www.egoshare.com/9dad3c13be3968c0ed977ed5cd62e25f/3rd_rock_of_sun_sampleavi.html

[clsid]

How do the new (*rev*clsid) ffdshow builds hosted on x264.nl compare to the old ones (*gcc*sse)? Same/better functionality? Same/better performance?
ffdshow tryouts vs. ffdshow:
- several bugfixes
- some new functionality: e.g. VP5 and VP62 decoders
- improved functionality: WMV3 decoder, output queue
- performance improvements: mainly just for decoding H.264, up to 30%

[clsid]

OK, here it is. Small 50 second sample is on http://www.egoshare.com/9dad3c13be3968c0ed977ed5cd62e25f/3rd_rock_of_sun_sampleavi.html
Ok, I can reproduce it. VideoLAN has the same problem. So it is a bug in the ffmpeg code.

Can someone submit this to the ffmpeg mailing list?

[cc979]

just compiled ffdshow-rev601

all but libavcodec.dll was compiled with gcc-4.0.3

libavcodec.dll was compiled with a patched gcc-4_1-branch revision 118702 as ffdshow.ax crashed on opening filter with video was playing played, apart from it seems ok

its here if you want to test it
http://www.mytempdir.com/1088885

see my gcc page for new gcc build

[Romario]

Thank you, clsid.

Are you sure that ffmpeg is responsible for that annoying bug?

[Inventive Software]

Videolan and ffmpeg (and mencoder and ffdshow) use the same underlying code for the codecs and whatnot, so yes, ffmpeg is responsible since that's where the primary development goes on.

[devaster]

i cannot compile libavcodec project from svn due 500< syntax errors (especially in structures )...
i have compile it as c code in vs2005 with latest platform and directx sdk (march and october)
where is problem ? any ideas ?

[haruhiko_yamagata]

i cannot compile libavcodec project from svn due 500< syntax errors (especially in structures )...
i have compile it as c code in vs2005 with latest platform and directx sdk (march and october)
where is problem ? any ideas ?
libavcodec should be compiled by GCC.
VS2005 may be used to debug, but it often requires fixing source code.

[devaster]

libavcodec should be compiled by GCC.
VS2005 may be used to debug, but it often requires fixing source code.
AHA thanx ill try it ...

[LoRd_MuldeR]

just compiled ffdshow-rev601

all but libavcodec.dll was compiled with gcc-4.0.3

libavcodec.dll was compiled with a patched gcc-4_1-branch revision 118702 as ffdshow.ax crashed on opening filter with video was playing played, apart from it seems ok

its here if you want to test it
http://www.mytempdir.com/1088885

see my gcc page for new gcc build

Your libavcodec.dll seems to work fine for me. Some results:

ffdshow.ax by clsid (ICL9), libavcodec.dll by cc979 (GCC 4.1.2)
User: 58s, kernel: 0s, total: 58s, real: 59s, fps: 126.6, dfps: 124.4
User: 58s, kernel: 0s, total: 58s, real: 59s, fps: 126.7, dfps: 124.3

ffdshow.ax by clsid (ICL9), libavcodec.dll by clsid (GCC 4.0.3)
User: 50s, kernel: 0s, total: 51s, real: 51s, fps: 145.7, dfps: 143.4
User: 50s, kernel: 0s, total: 50s, real: 51s, fps: 146.6, dfps: 143.4

[fastplayer]

Why is there such a difference between 4.0.3 and 4.1.2? Shouldn't performance improve with newer compilers?

[Inventive Software]

Unfortunately, that doesn't appear to be the case with GCC. :(

[LoRd_MuldeR]

Unfortunately, that doesn't appear to be the case with GCC. :(

Well, it's just one test on one specific system.
And cc979 said that he used some "patched" version to get it working. Maybe that's why it's slower...
Last but not least "newer" doesn't mean "more optimized" nor "more reliable"

[cc979]

@LoRd_MuldeR: cheers for checking, think i need to look into it further - 20fps difference, i should check with clsid what optimizations were used on his build

[fastplayer]

Last but not least "newer" doesn't mean "more optimized" nor "more reliable"
In case of software - and compilers in particular - it should. But that's just my opinion ;)

[LoRd_MuldeR]

In case of software - and compilers in particular - it should. But that's just my opinion ;)

Of course it should, but reality often looks different ;)
For example they add a new feature, but it will take some time to optimize...

[fastplayer]

@LoRd_MuldeR:
I know what you mean. It's just odd for a compiler to go "backwards" in terms of performance. IIRC videomixer used 3.4.5 and achieved better performance than builds built with 4.x.x.

What compiler (version) are the ffmpeg guys actually recommending?

[LoRd_MuldeR]

I don't know...
But since all critical code in libavcodec is written in Assembler, the compiler version should not effect the performance very much anyway.
Makes my results even more confusing...

[clsid]

@cc979, no special optimizations have been used, just the supplied makefile

I did some tests with GCC 4.1.1 a while back and that was also slower. GCC 3.4.5 used to be the fastest then, closely followed by GCC 4.0.3. For the current code it is the other way around, 4.0.3 being the fastest.

GCC does need to perform some actions on the assembly code I think. Like register allocation and such. But it is still weird that newer versions have worse performance.

[foxyshadis]

I can't seem to get the environment for 4.2 and 4.3 working correctly, but if anyone can I think it's very important to test those out. 4.3 in particular will enable much simpler and faster multithreading (with OpenMP).

[iron2000]

Something I found at the ffdshow Wikipedia entry (http://en.wikipedia.org/wiki/Ffdshow):
"Important note: The ffdshow uninstaller has a bug and deletes Windows' codec and audio registry."

Is this true still for recent builds?

[foxyshadis]

It was brought up and fixed in August.

I don't understand why it was added to wiki weeks after it was fixed. Oh well, a lot of information on wiki goes unverified for ages.

[edit] There, rewrote the wiki entry, hopefully the important stuff doesn't get clobbered with misinformation again.

[Anima123]

Is there anyone that have successfully compiled ffdshow with gcc 4.3 (OpenMP)?

[haruhiko_yamagata]

Yeah, it does. Bizarre, that. Couldn't find an immediate cause after some digging through the subtitle code, so I'll come back to it later if no one else does.
It's my bug at rev 237. I'm trying to fix it. Thank you.

[LoRd_MuldeR]

Something I found at the ffdshow Wikipedia entry (http://en.wikipedia.org/wiki/Ffdshow):
"Important note: The ffdshow uninstaller has a bug and deletes Windows' codec and audio registry."

Is this true still for recent builds?

Writing stuff to Wikipedia is pain!
Once you update the Weblinks for example, it only takes seconds until your changes are reverted :mad:
Let it be outdated, if they like it that way....

[fastplayer]

@Developers:
I was wondering why only some of the changes that are being made by the ffmpeg guys end up in ffdshow. Why not all of them?
Looking at ffdshow's changelog, it seems like you handpick some of the updated ffmpeg code and integrate it into ffdshow. Why? Or am I completely wrong?

[LoRd_MuldeR]

@Developers:
I was wondering why only some of the changes that are being made by the ffmpeg guys end up in ffdshow. Why not all of them?
Looking at ffdshow's changelog, it seems like you handpick some of the updated ffmpeg code and integrate it into ffdshow. Why? Or am I completely wrong?

Maybe because the devs work in their free time and they cannot do everything at the same time ???

We should be thankful for every update we get!

[clsid]

Not all of the ffmpeg code is used by ffdshow.

[fastplayer]

That would have been my guess.
Do you just copy over the source or do you have to make adjustments? Is there no way to automate this?
By the way, thanks for the new build, clsid! :)

[vlada]

I have a question regarding DVD support. It doesn't work in my favorite player (ViPlay 2.xx) but it works in WMP. But there are 2 small flaws:

1) MPEG-2 decoding only works with libmpeg2. With libavcodec the video is very choppy although CPU usage is low. This bug in ffdshow (or libavcodec?) is there already for a long time.

2) It would be nice if letterboxing (in Subtitles dialog) worked for DVDs too. I mentioned my problems in this thread (http://forum.doom9.org/showthread.php?p=823874).

[Romario]

clsid, what's going on with your bug report about FFMPEG x264 interlace decoding? Do you got any answer form FFMPEG devs?

[clsid]

I haven't submitted a bug report. Feel free to do it yourself:
http://ffmpeg.mplayerhq.hu/bugreports.html

[clsid]

List of known issues in revision 613:

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. FFmpeg bug. Sample file (http://www.egoshare.com/9dad3c13be3968c0ed977ed5cd62e25f/3rd_rock_of_sun_sampleavi.html). (Reported by Romario)

Reported but unconfirmed bugs:

3) Writing an OGM file via VFW interface creates a corrupt file. (reported by clsid)
4) FLV muxer seems to be buggy as well.
5) The following encoders do not work for me: MPEG 4, MPEG 1, MPEG 2, h.263, H.261 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? (reported by: clsid, seewen)

ToDo:

6) Add WM9 decoder passthrough

Other issues:

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

[Inventive Software]

With regard to the encoders problem you have... have you tried it with different frame-rate material? I had that problem with NTSC framerate stuff (both 29.97 and 23.976), and 25 FPS wasn't a problem.

[haruhiko_yamagata]

I reprodeced the freeze on seek problem with Crystal player.
When I unchecked Crystal player's "Direct Show" -> "Allow YV12 (fastest)", it is OK.
When I unchecked ffdshow's "Ouput"->"Supported output colorspaces"->"YV12", it is OK as well.

OK, I found more radical fix. After a little more testing, I'll comit.

[clsid]

With regard to the encoders problem you have... have you tried it with different frame-rate material? I had that problem with NTSC framerate stuff (both 29.97 and 23.976), and 25 FPS wasn't a problem.
Just tested a 25fps input file and the problems remain.

[JarrettH]

what does stuff like this mean in the changelog?

(ffmpeg 7189,7191,7192,7193)

:D

[LoRd_MuldeR]

what does stuff like this mean in the changelog?

(ffmpeg 7189,7191,7192,7193)

:D

Changes on code from ffmpeg. Look at ffmpeg's SVN for details:
http://svn.mplayerhq.hu/ffmpeg/?view=log

[oddball]

Some SVQ3 clips still run like crap. The 'Deck the Halls' trailer for instance.

[Mangix]

a lot of them run very nicely :)

[Anima123]

I reprodeced the freeze on seek problem with Crystal player.
When I unchecked Crystal player's "Direct Show" -> "Allow YV12 (fastest)", it is OK.
When I unchecked ffdshow's "Ouput"->"Supported output colorspaces"->"YV12", it is OK as well.

OK, I found more radical fix. After a little more testing, I'll comit.

I can also reproduce it with ffdshow before rev601. Without "Allow YV12 (fastest)" enabled, Crystal Player cannot play video with YV12 color space like rmvb, which quite puzzled me. I have no idea what's the problem?

Furthermore, with "Allow YV12 (fastest)" enabled in Crystal Player and only allow YV12 output in ffdshow settings, it becomes not only freezing but also take over 90% cpu power.