ffdshow tryouts project: Discussion & Development

[LigH]

So for some reason, your personal matching locale was possibly preferred over a compatible "common base".

[STaRGaZeR]

I'd like to vote to keep ffdshow's M-JPEG codec. It is by far the best quality M-JPEG codec I know. See my comparison thread in the german board (http://forum.gleitz.info/showthread.php?24071-MotionJPEG-Codec-Vergleich&highlight=picvideo). There is no substitution for me.

Reply #1 (start) = artifical still content with samples (click the smilies for sample pictures); reply #19 (http://forum.gleitz.info/showthread.php?24071-MotionJPEG-Codec-Vergleich&p=217751&viewfull=1#post217751) = VQEG comparison with PSNR and SSIM

So you made a comparison back in 2005 with a sinthetic image and ffmpeg's MJPEG encoder won. Have you ever used it for anything other than that comparison or you just want to keep it in ffdshow because it's good?

[clsid]

Also, does the MJPEG encoder have any practical use? I mean, when does one use it instead of some other video format?


Guys, should we also remove xvidcore.dll from the installer? Some people use it as decoder in ffdshow (instead of libavcodec). Do we keep it, or should such people just install Xvid if they want to be able to use xvidcore inside ffdshow?

[fastplayer]

Guys, should we also remove xvidcore.dll from the installer?
Please do so! When was the last time ffmpeg screwed up Xvid/DivX decoding so badly that you had to switch to xvidcore? (That was a rhetorical question...)

[CruNcher]

@clsid
something is wrong there is no other solution then to switch to the proprietary RealVideo decoder instead, it fixed the Jitter issue immediately obviously its performance is also still better then ffv40 (at least the used one in ffdshow)

Proprietary Decoder (drvc.dll)

http://img72.imageshack.us/img72/2083/jitterfixed.png

[Brazil2]

When was the last time ffmpeg screwed up Xvid/DivX decoding so badly that you had to switch to xvidcore?
Since Xvidcore can properly play this video but none of the ffmpeg decoders:
http://www.mediafire.com/download.php?nub79dtss0kacb2

Not to mention I always thought the idea behind ffdshow is an all-in-one tool and all about options and that's why it's great.
I understand the wish to remove some encoders but why the decoders ? They are always usefull for someone somewhere because there is no one standard ffdshow configuration running on one standard computer but each individual is a particular case.

[LigH]

So you made a comparison back in 2005 with a sinthetic image and ffmpeg's MJPEG encoder won. Have you ever used it for anything other than that comparison or you just want to keep it in ffdshow because it's good?

1. Yes, the test was old, and the first part was quite artifical. But you ignored the second part (VQEG). And you don't seem to care about the magnitude of the advantage either.

2. I'd like to keep that codec because it is good, yes. So if you want it out of ffdshow by all means, don't let it die completely. ffdshow's MJPG codec is not just better. It is by far better than all commercial MJPG codecs with an impressive distance.

3. I am not the one who uses it often. But use my voice vicariously for all those who still use it but are not a board member here (e.g. because they don't speak english) and are not heard here. If necessary, I will collect signatures of those who like it still today.

[CruNcher]

Since Xvidcore can properly play this video but none of the ffmpeg decoders:
http://www.mediafire.com/download.php?nub79dtss0kacb2

Not to mention I always thought the idea behind ffdshow is an all-in-one tool and all about options and that's why it's great.
I understand the wish to remove some encoders but why the decoders ? They are always usefull for someone somewhere because there is no one standard ffdshow configuration running on one standard computer but each individual is a particular case.

though i would prefer rather the divx decoder then xvidcore it also shows no decoding problems on the interlaced parts has better performance and multithreading support compared to xvidcore.
You also should really report this decoding problem to the ffmpeg developers and upload it to their test ftp with a description of the decoding problem.
I guess if you upload this to youtube it should also fail *g*

[nm]

Since Xvidcore can properly play this video but none of the ffmpeg decoders:
http://www.mediafire.com/download.php?nub79dtss0kacb2

Plays fine with mplayer -lavdopts bug=16 and ffplay -bug 16

Bug=16 is "(mpeg4): padding bug (autodetected)", so it looks like a problem in encoder bug detection in h263dec.c.

As CruNcher said, it would be a good idea to report this on FFmpeg bug tracker even when you have another decoder that works better. FFmpeg is ubiquitous.

[clsid]

Libavcodec workarounds can be enabled in the ffdshow settings, on the 'Decoder options' page.

By default autodetect is used. That obviously does not work for this sample, so please report it to FFmpeg bug tracker.
https://roundup.ffmpeg.org/

Due to the existence of the autodetect option, I assume that there may be unwanted side effect to forcing workarounds when not needed (enable always). Does anyone know if that is really the case?

[clsid]

@LigH

The encoders from ffdshow come from FFmpeg, so anyone who would like to use the MJPEG (or other) encoder can do so by using FFmpeg or any of the many conversion programs that are based on it. So lets rephrase the question. Is there a specific need for using ffdshow to encode to MJPEG? Also, when do people use MJPEG?

[STaRGaZeR]

1. Yes, the test was old, and the first part was quite artifical. But you ignored the second part (VQEG). And you don't seem to care about the magnitude of the advantage either.

2. I'd like to keep that codec because it is good, yes. So if you want it out of ffdshow by all means, don't let it die completely. ffdshow's MJPG codec is not just better. It is by far better than all commercial MJPG codecs with an impressive distance.

3. I am not the one who uses it often. But use my voice vicariously for all those who still use it but are not a board member here (e.g. because they don't speak english) and are not heard here. If necessary, I will collect signatures of those who like it still today.

Do you understand that all these encoders are ffmpeg encoders? We are simply removing from ffdshow those that virtually nobody uses for virtually anything. If you want to use it, it's better to use ffmpeg to have full control over it or, as clsid said, one of the multiple programs that will give you exactly the same. ffdshow is just a wrapper for ffmpeg in this regard.

And yes, it would be useful to know: 1. who uses MJPEG, 2. for what purpose, 3. vfw through ffdshow?

@devs, I have a patch that completely removes x264 from ffdshow, tell me when and if you want it commited.

[Brazil2]

By default autodetect is used. That obviously does not work for this sample, so please report it to FFmpeg bug tracker.
https://roundup.ffmpeg.org/
Well, I'm not going to create an account just to report only one bug while I'm quite sure many of you already have accounts and some of you may even be in touch with the ffmpeg devs. So feel free to report this bug.


Libavcodec workarounds can be enabled in the ffdshow settings, on the 'Decoder options' page.

Due to the existence of the autodetect option, I assume that there may be unwanted side effect to forcing workarounds when not needed (enable always).
Exactly, that's why I'm asking to keep Xvidcore in ffdshow, at least while awaiting for the ffmpeg decoder to be fixed.

[fastplayer]

@devs, I have a patch that completely removes x264 from ffdshow, tell me when and if you want it commited.
If _xxl doesn't intend to maintain it anymore and nobody wants to fill in, then please remove it.

[Brazil2]

3. I am not the one who uses it often. But use my voice vicariously for all those who still use it but are not a board member here (e.g. because they don't speak english) and are not heard here.
That's a good point, I also think that the vast majority of ffdshow users have never heard about this board and they are using ffdshow because it's quite simple, all-in-one and also to avoid codec packs and their related problems. I do believe that the advanced users of this board are not representative of this vast majority of users.


And yes, it would be useful to know
3. vfw through ffdshow?
Anyone who is using VirtualDub(Mod) and it seems there is still an army of VD users.

[clsid]

Considering that the current x264 encoder is buggy and there is no maintainer, I agree it can be removed.

@Brazil2, the ability to decode using xvidcore will not be removed. We are just considering to remove the dll from the installer. ffdshow will still be able to use an externally installed copy. Files that need it are very rare and made by buggy encoders, plus there is a known workaround.

I don't have an account there either. Is there anyone here that has one and is willing to report this issue?

[dann23]

@clsid. you said that ffdshow has a DS encoder. how do we use it and where do we find it? also it will be usefull if you recommed a substitute for virtualdub. because, now, with ffmpef mpeg4 removed, virtualdub is useless for me. I don't have a problem if the devs remove all vfw from ffdshow, but we need some alternative if you do this.

[clsid]

ffdshow is feature rich, but not an "all-in-one" solution. Some people think they can do everything with it, but that is just not true. I have needed to help people many times that were missing for example a source filter, thinking ffdshow would take care of it, possibly after being told that ffdshow was 'all they need'. Some even think it can convert their files. The number of people that actually have real problems with codec packs are much much smaller than codec pack haters like you think. Plus most problems are user errors or unrelated problems caused by other software. Besides, a codec pack is not suddenly needed if ffdshow no longer supports MJPEG encoding. Many encoding tools rely on their own private encoders.

Adding/keeping features is not something we must do simply because we can, it must be done if it has significant benefits for the users. If something is used rarely and there are good enough or even better alternatives available, then we might better off without it. Manpower for maintaining/fixing things in ffdshow is simply too scarce.

[clsid]

@clsid. you said that ffdshow has a DS encoder. how do we use it and where do we find it? also it will be usefull if you recommed a substitute for virtualdub. because, now, with ffmpef mpeg4 removed, virtualdub is useless for me. I don't have a problem if the devs remove all vfw from ffdshow, but we need some alternative if you do this.
Why is VirtualDub suddenly useless? If you want to encode MPEG-4, then simply install Xvid (or DivX). That is also better than the encoder offered by ffdshow.

If you want to use the ffdshow filters inside VirtualDub, you can still do that, even regardless of your chosen encoder. Simply use the VirtualDub plugin (ffvdub.vdf) that is included with ffdshow.

The GUID of the DS encoder is {4DB2B5D9-4556-4340-B189-AD20110D953F}, but it has the same functionality as the VFW one.

[dann23]

then the DS encoder is useless to :)
I used ffmpeg mpeg 4 because it was there and I didn't have to install other encoders. So in this case I have to get used to virtualdub external encoders and comand line parameters.

[GrofLuigi]

I use commercial MJPEG codec, but I would imagine many users would still benefit from it in ffdshow.

Mainly because of VFW interface and capture, either from screen or external source. Yes, even webcam, it can be quite useful.

I don't know much about the current implementation, but if it isn't broken and doesn't break other things, why not keep it? :thanks:

GL

[clsid]

It would mostly just mean size reduction for ffmpeg.dll (edit: diff is about 240 KB).

The question I still haven't seen answered is: why use MJPEG instead of some other video formats like Huffyuv (lossless) or Xvid/H.264 (lossy)? Is it faster, does it have better compression/quality ratio for certain types of content, etc. I rarely do any encoding, so I don't have any experience with the MJPEG format.

[STaRGaZeR]

That's a good point, I also think that the vast majority of ffdshow users have never heard about this board and they are using ffdshow because it's quite simple, all-in-one and also to avoid codec packs and their related problems. I do believe that the advanced users of this board are not representative of this vast majority of users.

Anyone who is using VirtualDub(Mod) and it seems there is still an army of VD users.

Let's get real here. The vast majority of ffdshow users don't even know it encodes, let alone its MJPEG capabilities. So yes, you're right, this forum is not representative of the vast majority of users. Besides, the encoder part of ffdshow is far from being all-in-one, easy to use and bug free.

You forgot 1. and 2., please answer these before answering 3. otherwise it's meaningless. We are talking about the MJPEG encoder, not about the vfw encoder in general.

Considering that the current x264 encoder is buggy and there is no maintainer, I agree it can be removed.

OK, I'll remove it then.

I use commercial MJPEG codec, but I would imagine many users would still benefit from it in ffdshow.

Mainly because of VFW interface and capture, either from screen or external source. Yes, even webcam, it can be quite useful.

I don't know much about the current implementation, but if it isn't broken and doesn't break other things, why not keep it? :thanks:

GL

The vfw interface is not going away. Again, x264 and xvid have really good vfw interfaces that are a lot better, are updated and bug free, ffdshow is not. People using vfw should use them.
Just curious, why do you capture to MJPEG and not to a higher quality, easier to use format?

[HeadlessCow]

I've used the MJpeg functionality in the past because it was significantly lower size and CPU usage than using one of the lossless codecs and I didn't care about perfect quality.

My preference (for what it matters) is to leave the formats that libavcodec supports internally and ditch all the formats that are using external libraries (xvid, x264, WMV, ??).

The bare minimum I'd like to see kept is HuffYUV and FFV1, though I mostly use Lagarith lately instead.

[XhmikosR]

How much size will we gain if the encoders supported by ffmpeg are removed from ffdshow? Of course someone can use ffmpeg directly but one might not want or know how to use ffmpeg through the commandline, or simply it's easier to configure the settings through ffdshow. Maybe they shouldn't be removed.
I still want to have different output dirs based on the compiler used. ffmpeg and gcc built files will still be in the bin directory since I don't wanna mess with the makefiles at the moment. This way we can make sure everything goes well for people using different compilers. Does everybody agree with this?

[clsid]

Avidemux is an easy to use, VirtualDub like, interface for using FFmpeg encoders.

Removing MJPEG and Lossless JPEG saves about 240KB in ffmpeg.dll

Use these dirs: bin\x86, bin\x64, bin\x86_icl
Installer should then use a defined value "bin_dir", set by user settings, and use non-icl dir otherwise.

[XhmikosR]

I don't like your suggestion for the simple reason that there are a lot of configurations and I want to keep the compiled files, the pdb files etc in one dir. I'm still thinking about it but it will be something like root\bin10 for VS2010 and root\icl12 for ICL12 (this will fix those warnings about the OutDir and the linker's dir).
I don't really care about VS08 so I may not even touch those projects. The same goes for the ICL10 projects. Whoever uses and maintains those can make any changes they want.
Oh, and it's a good time to remove the random solution files.

As for the installer, that's what my plans are. Also, I have a few suggestions for the installer.

-remove the types since only one is used.
-remove the various MinVersion and use a MinVersion in [Setup] section. Since Inno Setup Unicode is used the minimum version is 0,5.0.
-the main ffdshow component shouldn't be uncheckable like it is now.

[STaRGaZeR]

I've used the MJpeg functionality in the past because it was significantly lower size and CPU usage than using one of the lossless codecs and I didn't care about perfect quality.

Do you use it now? If yes, for what, and would you use it with xvid and x264 around, considering the compatibility, highly customizable compression/speed/size ratios of these 2 encoders? These are the questions to answer. So far no responses, the closest to a good reason has been yours, and you're comparing it to lossless codecs (why?). Still waiting to see some evidence of LigH's "all those who still use it but are not a board member here" though, sounds like a lot of people.

On a side note, I just encoded something with it. Ignoring the crashes because of access violations I got, man it looks horrible. For the same size and encoding speed, x264 and xvid look a lot better, night and day. If you can use ffdshow vfw for webcam capture or something like that as previously mentioned, you can also use x264vfw and xvid, so do yourself a favor and use them instead.

How much size will we gain if the encoders supported by ffmpeg are removed from ffdshow? Of course someone can use ffmpeg directly but one might not want or know how to use ffmpeg through the commandline, or simply it's easier to configure the settings through ffdshow. Maybe they shouldn't be removed.

It's not about the size gain, which is nice, is about why keep them there if nobody realistically uses them, they're buggy and there are way better alternatives. We do have evidence that people use the lossless encoders a lot, none so far about MJPEG, lossless JPEG and the others.

[Valeron]

Hi, XhmikosR.
I've a question regards to your MSVC10 build.
Can MSVC10 build ffmpeg now? Afaik, MSVC10 is still incapable of compiling C99 codes, isn't it?
:thanks:

[betaking]

BUG report! installed last ffdshow_rev3680_20101213_xhmikosr_MSVC2010(X86) or ffdshow_rev3680_20101213_MSVC2010(X86)form xvidvideo.ru click stat-ffdshow-Video decoder configuration click about- Version details,The settings interface did not automatically turn off any tips!
but not happen on ffdshow_rev3679_20101212_MSVC2010(X86) form xvidvideo.ru & ffdshow_rev3680_20101213_xhmikosr_icl12!

[LigH]

Sometimes it happens that the majority of developers assumes wrong about the habits of the majority of the users.

When would anyone decide to use an MJPEG VfW codec? ... Well, I wonder for what purpose all the other commercial MJPEG codecs were made, if not for e.g. analog capturing.

I don't belong to the people who regularly use a capture card. But I am quite certain that there are still some.

What kind of substitution for an MJPEG VfW codec would you recommend for analog capturing? Lossless codecs take more space. DV codecs may have a worse chroma subsampling and less bitrate control. Stronger compressing codecs (e.g. Xvid) may have more obvious artefacts. IMHO, MJPEG is still a useful codec for that purpose. It would be a pity to lose the best-quality variant of them only because the developers believe there are no users.

I believe you will at least agree that a stand-alone ffmpeg.exe won't be used for analog video capturing as long as there are tools like VirtualDub, VirtualVCR etc.
__

P.S.: Let's see how this poll (http://forum.gleitz.info/showthread.php?43081-ffdshow-VfW-wird-quot-ausgemistet-quot-bald-ohne-MJPEG) will develop over the next week(s)...

[GRKNGLR]

BUG report! installed last ffdshow_rev3680_20101213_xhmikosr_MSVC2010(X86) or ffdshow_rev3680_20101213_MSVC2010(X86)form xvidvideo.ru click stat-ffdshow-Video decoder configuration click about- Version details,The settings interface did not automatically turn off any tips!
but not happen on ffdshow_rev3679_20101212_MSVC2010(X86) form xvidvideo.ru & ffdshow_rev3680_20101213_xhmikosr_icl12!

I have same problem too.

[STaRGaZeR]

Sometimes it happens that the majority of developers assumes wrong about the habits of the majority of the users.

When would anyone decide to use an MJPEG VfW codec? ... Well, I wonder for what purpose all the other commercial MJPEG codecs were made, if not for e.g. analog capturing.

I don't belong to the people who regularly use a capture card. But I am quite certain that there are still some.

What kind of substitution for an MJPEG VfW codec would you recommend for analog capturing? Lossless codecs take more space. DV codecs may have a worse chroma subsampling and less bitrate control. Stronger compressing codecs (e.g. Xvid) may have more obvious artefacts. IMHO, MJPEG is still a useful codec for that purpose. It would be a pity to lose the best-quality variant of them only because the developers believe there are no users.

I believe you will at least agree that a stand-alone ffmpeg.exe won't be used for analog video capturing as long as there are tools like VirtualDub, VirtualVCR etc.
__

P.S.: Let's see how this poll (http://forum.gleitz.info/showthread.php?43081-ffdshow-VfW-wird-quot-ausgemistet-quot-bald-ohne-MJPEG) will develop over the next week(s)...

I won't comment on the bolded parts, they speak for themselves.

MJPEG is a lossy codec. Any faster, better quality, better compression lossy encoder will do the job. And if you are into video encoding, you'd know MJPEG is a very, very bad choice unless you're forced to use it for some reason.
Stronger compressing codecs may have more obvious artifacts? Seriously, what are you talking about?

Yes, I agree. We are telling you to use better-in-all-aspects vfw encoders for that, not ffmpeg.exe

And please, when posting links from the German forum here, post at least a Google translate link. This is the English forum, not the German forum. Or better, write in proper English what the poll options mean, because Google fails. About the poll itself, I bet the winner will be the equivalent of "I never use it, but it'll be nice if they keep it, just in case". It has been there for a long time already, just in case. That's the point.

I have same problem too.

Can you please describe it in detail? I don't really understand what "The settings interface did not automatically turn off any tips!" means.

[betaking]

download screen recoder files! After seeing this I think you should understand!
http://www.mediafire.com/?v79zkluwl22p7mm

[STaRGaZeR]

I see now. It crashes here instead of disappearing. ICL12 is fine. Duh.

[XhmikosR]

Hi, XhmikosR.
I've a question regards to your MSVC10 build.
Can MSVC10 build ffmpeg now? Afaik, MSVC10 is still incapable of compiling C99 codes, isn't it?
:thanks:

No one uses MSVC for ffmpeg, all the release builds use gcc for ffmpeg(-mt). MSVC can be used for the debug builds which has some code commented out, but right now debug builds won't compile.


It's not about the size gain, which is nice, is about why keep them there if nobody realistically uses them, they're buggy and there are way better alternatives. We do have evidence that people use the lossless encoders a lot, none so far about MJPEG, lossless JPEG and the others.
Good point. I guess there's no real reason to keep them then.

[GRKNGLR]

Can you please describe it in detail? I don't really understand what "The settings interface did not automatically turn off any tips!" means.

When I go to ffdshow settings > about screen and hit the version details, the window gets closed instead of showing the details. I thought that message was the same as mine; that's why I said I had the same problem.

[HeadlessCow]

Do you use it now? If yes, for what, and would you use it with xvid and x264 around, considering the compatibility, highly customizable compression/speed/size ratios of these 2 encoders? These are the questions to answer. So far no responses, the closest to a good reason has been yours, and you're comparing it to lossless codecs (why?). Still waiting to see some evidence of LigH's "all those who still use it but are not a board member here" though, sounds like a lot of people.

On a side note, I just encoded something with it. Ignoring the crashes because of access violations I got, man it looks horrible. For the same size and encoding speed, x264 and xvid look a lot better, night and day. If you can use ffdshow vfw for webcam capture or something like that as previously mentioned, you can also use x264vfw and xvid, so do yourself a favor and use them instead.



It's not about the size gain, which is nice, is about why keep them there if nobody realistically uses them, they're buggy and there are way better alternatives. We do have evidence that people use the lossless encoders a lot, none so far about MJPEG, lossless JPEG and the others.

Like I said, I used it in the past, not now.

I compared to lossless codecs because that was what clsid asked about it.


The question I still haven't seen answered is: why use MJPEG instead of some other video formats like Huffyuv (lossless) or Xvid/H.264 (lossy)? Is it faster, does it have better compression/quality ratio for certain types of content, etc. I rarely do any encoding, so I don't have any experience with the MJPEG format.

At the time, xvid was too slow to encode at real time on the system I was using (at least without turning off so much stuff that it looked like shit) and with a high quality setting for MJpeg I was able to capture in realtime to a high enough quality that I was able to edit the capture and reencode the results to a format that I actually wanted. Lossless files were too large to deal with.

I don't use it anymore because of three things:
1) A processor fast enough to do x264 in realtime.
2) Tons of cheap disk space.
3) Not capturing video anymore.

Having MJpeg available in ffdshow was convenient since capture apps let you choose a vfw encoder and ffdshow was free and better quality than the competitors.

I don't know if anyone STILL requires this, but it's not hard for me to imagine someone being in the position I used to be in.

[clsid]

I have updated the ac3 encoder, but I haven't got the hardware to test spdif output. Everyone please test it.

[STaRGaZeR]

When I go to ffdshow settings > about screen and hit the version details, the window gets closed instead of showing the details. I thought that message was the same as mine; that's why I said I had the same problem.

Should be fixed after r3682. Thanks to sansnom05 for finding the cause :)

[betaking]

Should be fixed after r3682. Thanks to sansnom05 for finding the cause :)

YES it fixed! thanks!

[dann23]

ati released 10.12 driver and it brings support for decoding divx on gpu. any chance to see this implemented on ffdshow? and I hope someday we'll get mpeg2 decoding using dxva.

[sansnom05]

Everyone:

I've updated the ff_unrar from 3.40 beta 4(2004-08-03) to 3.93 beta 0(2010-03-15), here's the test build link: http://www.mediafire.com/?3cvpw2t14yown4a.

Please test it then report back, if it's ok I'll consider commit it. :thanks:

Edit: the link is corrected.

[GrofLuigi]

Just curious, why do you capture to MJPEG and not to a higher quality, easier to use format?

As others said, because of:

1. CPU usage (my computers are not top-notch and I want to see lower than 50% CPU usage if I need to troubleshoot a problem or have a chance of using another, any, realtime filter).

2. 100% quality is very close to lossles to my eyes, so it's often good enough for me, especially considering the quality of SD sources.

3. If I'm pressed for disk space (not a problem lately, but it might happen), I just lower the quality a little bit and the job is done.

4. General ease of use, all the parameters are well known to me.

GL

[fastplayer]

Please test it then report back, if it's ok I'll consider commit it. :thanks:
I tested it only with one VobSub and it seems to work. :)

[LigH]

Just 5 replies to my poll (http://forum.gleitz.info/showthread.php?43081-ffdshow-VfW-wird-quot-ausgemistet-quot-bald-ohne-MJPEG) so far... but mainly positive answers.

a) must have - rescue it: 1x (not mine!)
b) would use if improved: 1x -- not sure what to be improved; I believe there are compatibility issues with some capturing tool like VirtualVCR
c) nice to have - keep it: 3x (one was mine)
d) don't care, kick it out: 0x

Probably not an urging argument; but at least you can't say "nobody needs it"; such an assumption is quite generalized, don't you agree?

The MJPEG format has its advantages in cases with limited resources. It is a basic and unique format, a milestone in the development of video technologies, with a unique computing/quality/size relation (useful where computing power is low and little quality loss acceptable).

And in ffdshow's VfW codec, the price/quality ratio is exceptional -- I don't even know only one other free MJPEG codec available. So if you really need to remove it from ffdshow, please try to release it separately. Or tell me about a free alternative MJPEG codec with similar quality.

[MicMec]

Sorry to change the subject, I have two questions regarding using ffdshow tryout rather than developing the application. Firstly when I pause a video it works fine but does not display the current frame on the screen I just see a black screen with the time bar at the bottom, is this the intended behaviour? Secondly I think playback works correctly for all audio/video/container combinations I have encountered except AC3 audio in an AVI container is this supported?

I am running ffdshow_rev3631_20101115_clsid under Windows 7 32 bit.

[adam777]

Hello all,
Just a quick question - while playing 24 bit DTS content, I noticed FFDShow which is used as the decoder (libavcodec) choose to output as 16 bit, although 24 bit is also chosen as possible output format.
Anything special I should check to find out what might be the reason?
Thanks, Adam.

[clsid]

Pause behavior is done by your player, ffdshow does nothing more than decode.

AC3 in AVI is extremely common and supported just fine by ffdshow.

libavcodec decodes to 16bit, hence the 16bit output.

[STaRGaZeR]

@devs, I need you help.

I'm trying to use new ffmpeg functions. As I've always done, I export them from ffmpeg.dll putting them in ffmpeg.def, then I load them in Tlibavcodec so they can be used elsewhere. However, this time it's not working.

Here's a simple patch to show the issue: http://www.mediafire.com/?3jvbbagt9dajknq

The problem is that when dll->loadFunction(avfilter_graph_alloc,"avfilter_graph_alloc"); is called, the pointer is set to 0x00000000 instead of the proper address, causing ffdshow to crash. I can see (with DLL Export Viewer) that the function is apparently correctly exported. All the other functions are set to their proper addresses, but if I try to add this or any other function, it'll crash for the same reason. Any suggestions?