ffdshow tryouts project: Discussion & Development

[albain]

[CODE]
albain for what do you need a sample just add WMVA to the allowed fourcc for VC-1 :)

Which is ?

[CruNcher]

Later revision number but different branch ;) .

oops :)


CoreAVC = 163.7 fps
DivX = 148 fps
ffdshow(2219 ffmpeg-mt) = 105.1 fps (3 threads)

not that bad :D

@albain
its the same as WVC1 just a pre release name for it WMVA = Winodws Media Video Advanced Profile


Q: But wait! Didn't WMP10 ship with a WMV Advanced Profile codec years ago?
A: Indeed it did. Microsoft began working on its implementation of WMV AP before VC-1 spec was finalized. That codec (FourCC: WMVA) shipped with WMP10 (Format SDK 9.5), but as final changes to the VC-1 spec were made, WMVA got out of sync with the official spec. Today WMVA is no longer VC-1 compliant and is generally considered deprecated.

[_xxl]

ffdshow(2219 ffmpeg-mt) = 105.1 fps (3 threads)
Try 8 threads.

[Mercury_22]

Here is the last build of the libavformat branch. I have performed a merge from the trunk, so in the future a merge from the branch to the trunk should be easier

Here is the link :

Beta 23 (http://rapidshare.com/files/154639962/ffdshow_rev2222_20081016_dbt_beta23.exe.html)

Now can we have a 64-bit version too ? Please ! :thanks: :helpful:

[CruNcher]

Try 8 threads.

with a Dual Core CPU ? anyway i tried it doesn't gets faster anymore :)

[STaRGaZeR]

That sounds good, _xxl a test version please :D

albain, with beta23 everything is working fine on my side, except that high pitch sound playing DVDs, which nobody seems to reproduce...

[albain]

Now can we have a 64-bit version too ? Please ! :thanks: :helpful:

Sorry, still the old same problem : I can't get my actual version of mingw cross compiler or binutils (x86_64-pc-mingw32-gcc) does not work.
I also can't get my hand on a previous version (the same as 32 bits version which works)

EDIT : I have built a new 64 bit version anyway. With some luck it will work, else I will try to compile ffmpeg with Visual studio but the performances will suffer.

FFDShow new audio codecs 64 bits beta (http://damienbt.free.fr/ffdshow_rev2222_20081016_x64_dbt_beta.exe)

[Inventive Software]

Note on the WMVA/VC-1 issue: The bitstreams between WMVA and WVC1 are different. However if it is feasibly possible, allowing Microsoft decoders only to decode it, instead of libavcodec, would IMHO ensure full compatibility at this stage. I will raise the issue with libavcodec/ffmpeg developers to see what the score really is. Expect an update probably this weekend. :)

[CruNcher]

If i remember correct the issue was only with Interlaced content ? so Progressive should be absolutely flawless Decoding with libavcodec :)

[STaRGaZeR]

FFDShow new audio codecs 64 bits beta (http://damienbt.free.fr/ffdshow_rev2222_20081016_x64_dbt_beta.exe)

libav AC3, EAC3, DTS, Vorbis crash. liba52 and libdts working.

libav MP3, MP2, MLP, FLAC, TTA working too.

Video libav working too.

[Mercury_22]

libav AC3, EAC3, DTS, Vorbis crash. liba52 and libdts working.

libav MP3, MP2, MLP, FLAC, TTA working too.

Video libav working too.

I can confirm that :(

[haruhiko_yamagata]

with a Dual Core CPU ? anyway i tried it doesn't gets faster anymore :)
Because ffmpeg-mt is frame based multithreading.

Frame A, B and C are decoded in thread A, B and C. Frame B is dependent on frame A, in other words frame B references frame A.
The first steps are CABAC/CAVLC and IDCT for both A and B. These steps can be done independently thus thread A and B can work parallelly. Next step is prediction which requires reference frames. If the picture A is not available in thread B and being decoded in thread A, thread B has to wait for thread A.
Here one core is free, thus you can decode frame C in thread C.
(If I understand correctly.)

If you use more threads, %CPU usage would rise. Too many threads will mess up the memory cache.

bbc-japan_1080p.mov (http://images.apple.com/movies/us/hd_gallery/gl1800/1080p/bbc-japan_1080p.mov).
ffdshow + ffmpeg-mt
(number of decoding threads)User: ...
(1)User: 185s, kernel: 0s, total: 185s, real: 186s, fps: 41.1, dfps: 40.8
(2)User: 13s, kernel: 0s, total: 13s, real: 106s, fps: 548.4, dfps: 71.5
(2)User: 13s, kernel: 0s, total: 13s, real: 106s, fps: 555.2, dfps: 71.6
(2)User: 14s, kernel: 0s, total: 14s, real: 106s, fps: 537.5, dfps: 71.6

(3)User: 14s, kernel: 0s, total: 14s, real: 104s, fps: 511.0, dfps: 72.6
(4)User: 14s, kernel: 0s, total: 14s, real: 106s, fps: 535.7, dfps: 71.8
(5)User: 13s, kernel: 0s, total: 13s, real: 104s, fps: 547.1, dfps: 73.0
(6)User: 14s, kernel: 0s, total: 14s, real: 104s, fps: 515.3, dfps: 72.6

(7)User: 15s, kernel: 0s, total: 15s, real: 104s, fps: 495.4, dfps: 73.1
(8)User: 13s, kernel: 0s, total: 13s, real: 104s, fps: 554.6, dfps: 72.8

ffdshow_rev2210_20081012_clsid.exe
(2)User: 171s, kernel: 0s, total: 171s, real: 175s, fps: 44.3, dfps: 43.4
I didn't have time to see if these results are statistically significant :p .
Probably 3 or 4 is good for use in real application.
Please note that I have chosen the sample file which show the maximum effect of ffmpeg-mt. Not all files are accelerated like this.

//EDIT
Core2duo E6700 2.66GHz

[_xxl]

Test build from ffmpeg-mt trunk:
http://rapidshare.com/files/154890409/ffdshow_rev2227_20081017_mt.exe.html

[CiNcH]

Test build from ffmpeg-mt trunk
Nice!! Check here (http://www.dvbviewer.info/forum/index.php?showtopic=29657&st=0#entry217361). 720p live streams (ORF 1 HD, arte HD) somehow crash ffdshow. Recorded streams from the same channels work fine.

[CruNcher]

@_xxl

CoreAVC = 163.7 fps
DivX = 148 fps
ffdshow(2227 ffmpeg-mt) = 112.2 fps (3 threads)

:)

[albain]

@_xxl

CoreAVC = 163.7 fps
DivX = 148 fps
ffdshow(2227 ffmpeg-mt) = 112.2 fps (3 threads)

:)

Very nice

Good job !

[CiNcH]

Nice!! Check here. 720p live streams (ORF 1 HD, arte HD) somehow crash ffdshow. Recorded streams from the same channels work fine.
Now it works for live with 720p. I am doing an in-depth video format detection now when switching channels. So the correct information (resolution a.s.o.) is now propagated through the video pin which ffdshow seems to need in case of 720p (think that if video detection is disabled some standard default values are propagated which work for 1080i). Think it worked with pre ffmpeg-mt builds. Maybe ffdshow previously used SPS/PPS to configure the decoder library?

Congrats and thanks again to Haruhiko who is doing a lot for the ffdshow video decoder nowadays! And also to those who worked out multithreading for ffmpeg!

[tal.aloni]

haruhiko_yamagata, clsid, albain,

I have some experience with C#, and after some struggle, I was able to add "One pass Normalization" to the project successfully. I tested it as well, and it's adding the necessary functionality, without hurting existing one.
you can see the new combo box at:
http://iknowu.net/files/public/ffdshow/ffdshow-OnePassNorm.png

1. I want to merge my changes to the SVN (quite a few, actually), how do you prefer me to do it?

2. When I inspected the current code, I realized why the "Regain Volume" normalization (the current one) result in distortion:
the normalization coefficient is calculated based on average volume instead of maximum volume, this must be a mistake, and I highly recommend changing that.

3. I got explanation to another wierd phenomenon:
current normalization is not enforced on the first samples, and that's what causing the volume to drop sharply in the beginning of videos.
again, I did not modify this for the "Regain Volume" normalization, but I suggest doing so.

p.s. I was missing dinput.lib when I compiled the project for the first time. it is not supplied with the latest DirectX SDK / Platform SDK, but I was able to get from the internet, I hope this is the right version, here is a copy:
http://iknowu.net/files/public/dinput.lib

Thanks,
Tal Aloni

[clsid]

Create .patch files. Preferably one for each functional change. Upload them somewhere so they can be reviewed. And may be upload a build for the hardcore testers here.

[haruhiko_yamagata]

Maybe ffdshow previously used SPS/PPS to configure the decoder library?No, ffdshow just send width and height that are given from the splitter in media type. libavcodec did not crash if ffdshow set wrong value.

For 1980x1088 samples, Haali's Media Splitter says 1980x1080. ffdshow crashed without the custom code that I added at rev 2226.
I sent the patch to author and he sent back better patch. So the fix will be soon :) .

[tal.aloni]

clsid, thanks.

I've created a patch for each file using WinMerge,
I've included the complete files as well,
changes are based on revision 2228.
the only change is the addition of One-Pass Normalization,
which activates when a new checkbox in the volume tab, labeled "Regain Volume", is unchecked.

http://iknowu.net/files/public/ffdshow/ffdshow-2228-OnePassNorm-RC3.zip

I've tested this build thoroughly, the improvement in sound quality over the existing "DRC"-like method ("Regain Volume" checked), is very noticeable.

Build:
http://iknowu.net/files/public/ffdshow/ffdshow_rev2228_20081018-OnePassNorm-RC3.exe

I'm very proud of the result :D
Thanks,
Tal Aloni

[Leak]

http://iknowu.net/files/public/ffdshow/ffdshow-2228-OnePassNorm-RC3.zip

I'm afraid that style of patch is not very helpful unless you apply it to the exact same version of the code you made it from, because there's no context information in case the line numbers have changed... :(

I'd suggest redoing your patch with the style set to "unified" and a context of at least 5. And, unless I'm reading your patch files wrong, some of them were reversed... (not much of a problem with unified diffs as you can always reverse-apply them, but I'm not sure if that's possible with plain diffs...)

Also - you can create a single patch file for all changed files with WinMerge if you compare two directories, select the files in the list and then hit "Generate patch"... there's no need to create a diff for every file.

Just my 0.02 EYPO... :)

np: Sigur Rós - Glósóli (Takk...)

[tal.aloni]

Thanks for helping out, I made a new patch based on the above suggestions. (one file, correct order)

http://iknowu.net/files/public/ffdshow/ffdshow-OnePassNorm-RC3-Patch.zip

Tal Aloni

[haruhiko_yamagata]

haruhiko_yamagata, clsid, albain,

I have some experience with C#, and after some struggle, I was able to add "One pass Normalization" to the project successfully. I tested it as well, and it's adding the necessary functionality, without hurting existing one.
Great work. The effect is natural, nice to hear and likable.

[tal.aloni]

Thanks,
It was easier to implement than I expected,
the project is well maintained and well documented, kudos.

p.s.
ffdshow's "normalization" is not normalization at all, it would be more correct to change the checkbox title to "auto volume control", but that's just semantics, and totally up to you.

Tal Aloni

[albain]

Here is another 64 bits build of the new audio codecs branch, I disabled MMX optimizations that make libavcodec crash with some codecs (AC3, DTS....).

It should doing fine now :

FFDShow 64 bits beta (new audio codecs) (http://rapidshare.com/files/155223158/ffdshow_rev2222_20081016_x64_dbt_beta.exe.html)

[STaRGaZeR]

No luck, it doesn't crash but no sound/distorted sound with libav.

[albain]

No luck, it doesn't crash but no sound/distorted sound with libav.

Sound problem occurs with TrueHD only or with AC3/EAC3/DTS/TrueHD decoders ?

This is weird, I don't know anything I could do about it, this is likely a ffmpeg bug with 64 bits.

I will try to dig this around and eventually post a new version with libavcodec compiled with MSVC

[albain]

I managed to make it work on my vista 64 environment.

Here are 2 builds:

http://damienbt.free.fr/ffdshow_rev2222_20081016_x64_dbt_beta_MINGW.exe

http://damienbt.free.fr/ffdshow_rev2222_20081016_x64_dbt_beta_MSVC.exe

First build, libavcodec has been compiled under MINGW, so it has better performances

Second build, libacodec compiled under MSVC.

Second build is working for me (AC3 output enabled, resampling always to 48Khz, channels remapped to 3/0/2). I guess it should work with other modes.

Please report which builds are (not) working

[tal.aloni]

I managed to develop another essential feature,
this one has been requested several times in the past:
the ability to deinterlace only interlaced sources (interlaced flag is set)

I added another checkbox to the top of the "Deinterlacing" section, labeled "Deinterlace all frame types" (perhaps this is not the best name), when checked, the current functionality is remained, when unchecked, only videos marked as interlaced are being interlaced. very convenient.
(http://iknowu.net/files/public/ffdshow/ffdshow-SelectiveDeint-RC1.PNG)

Build:
http://iknowu.net/files/public/ffdshow/ffdshow_rev2228_20081018-SmartDeint-RC1.exe

Source(Patch & Complete Files): (EDIT: Fixed Link)
http://iknowu.net/files/public/ffdshow/ffdshow-SelectiveDeint-RC1-Patch.zip

p.s. perhaps there is a better way to implement it, I just added an "if" section to each deinterlacer.

Tal Aloni

[Mercury_22]

I managed to make it work on my vista 64 environment.

Here are 2 builds:

http://damienbt.free.fr/ffdshow_rev2222_20081016_x64_dbt_beta_MINGW.exe

http://damienbt.free.fr/ffdshow_rev2222_20081016_x64_dbt_beta_MSVC.exe

First build, libavcodec has been compiled under MINGW, so it has better performances

Second build, libacodec compiled under MSVC.

Second build is working for me (AC3 output enabled, resampling always to 48Khz, channels remapped to 3/0/2). I guess it should work with other modes.

Please report which builds are (not) working

Thanks for your effort :thanks: Tested E-AC3;AC3;DTS
1.DTS not working in both
2.MING it's not working just noise (sounds like very boosted sound ?!:scared:)
3.MSVC it's working just for EAC3 and AC3

[DigitalDeviant]

I managed to develop another essential feature,
this one has been requested several times in the past:
the ability to deinterlace only interlaced sources (interlaced flag is set)

I added another checkbox to the top of the "Deinterlacing" section, labeled "Deinterlace all frame types" (perhaps this is not the best name), when checked, the current functionality is remained, when unchecked, only videos marked as interlaced are being interlaced. very convenient.
(http://iknowu.net/files/public/ffdshow/ffdshow-SelectiveDeint-RC1.PNG)

Build:
http://iknowu.net/files/public/ffdshow/ffdshow_rev2228_20081018-SmartDeint-RC1.exe

Source(Patch & Complete Files):
http://iknowu.net/files/public/ffdshow/ffdshow_rev2228_20081018-SmartDeint-RC1.exe

p.s. perhaps there is a better way to implement it, I just added an "if" section to each deinterlacer.

Tal Aloni

Does this affect hardware deinterlacing (setting the flag in the outboud stream) or is it only for internal ffdshow deinterlacing?

[albain]

Thanks for your effort :thanks: Tested E-AC3;AC3;DTS
1.DTS not working in both
2.MING it's not working just noise (sounds like very boosted sound ?!:scared:)
3.MSVC it's working just for EAC3 and AC3

I did not test DTS, but what about TrueHD decoding (it works on my side with the last build of MPC Home Cinema and m2ts samples on this forum) ?

[STaRGaZeR]

libav MP3, MP2, MLP(TrueHD), FLAC, TTA work in all betas.

In your very first beta there were problems with: libav AC3, EAC3, DTS and Vorbis. Let's see:

MSVC beta: everything works except DTS (distorted sound). libdts working. Don't know about EAC3 (no samples).

MINGW beta: AC3 distorted sound, DTS no sound, Vorbis crashes. liba52, libdts and tremor working instead. Can't test EAC3.

Maybe is a fault of the splitter, only MPC available in x64 for both Matroska and (m2)ts. They are really bad in x64, we need Haali :(

The difference in perfomance is big, Blu-ray is unplayable with the MSVC beta and a E8400@4GHz.

[tal.aloni]

Does this affect hardware deinterlacing (setting the flag in the outboud stream) or is it only for internal ffdshow deinterlacing?

it is only for internal ffdshow deinterlacing.
if you deinterlace using ffdshow, then you shouldn't set the flag in the outboud stream.
if you deinterlace using your hardware, then the flag should be set, and ffdshow's deinterlacing should be disabled.

[DigitalDeviant]

it is only for internal ffdshow deinterlacing.
if you deinterlace using ffdshow, then you shouldn't set the flag in the outboud stream.
if you deinterlace using your hardware, then the flag should be set, and ffdshow's deinterlacing should be disabled.

Yes, that's how I do it but I have issues with hardware deinterlacing (Ati HD3650). If there is progressive material mixed in with the interlaced I get really bad jerkiness.

[tal.aloni]

Yes, that's how I do it but I have issues with hardware deinterlacing (Ati HD3650). If there is progressive material mixed in with the interlaced I get really bad jerkiness.

Me too (Radeon x700), That's why I use software deinterlacing, and that's why I developed this feature, so deinterlacing will be active only when really needed.

[DigitalDeviant]

Me too (Radeon x700), That's why I use Software deinterlacing, and that's why I developed this feature, so deinterlacing will be active only when really needed.

Can't the output stream flag be set up to change automatically change if the interlace flag is set in the input stream?

Also, what software deinterlacer do you use? I haven't found one that even comes close to the vector adaptive deinterlacer of my Ati card.

[tal.aloni]

Can't the output stream flag be set up to change automatically change if the interlace flag is set in the input stream?

it does.
the reason that's you've got that jerkiness, is because hardware deinterlace does not always work well. (I think that sometimes it tries 3:2 pulldown, when the content is actually 29.97fps)


Also, what software deinterlacer do you use? I haven't found one that even comes close to the vector adaptive deinterlacer of my Ati card.

Linear blending, but I haven't experimented enough.
EDIT:
Linear interpolation seems to do a better job at some clips, but I guess every deinterlacer has it's strong territory.

[DigitalDeviant]

it does.
the reason that's you've got that jerkiness, is because hardware deinterlace does not always work well. (I think that sometimes it tries 3:2 pulldown, when the content is actually 29.97fps)

No, I don't believe that is it. I have some material that mixes hard and soft telecine which exhibits the same behavior. It seemed to me that the flag was permanently set to interlaced if the option was checked. Do nVidia based cards have the same problem?

Edit: It kinda looks like it could be the wrong field order is set. Could this happen?

Linear blending, but I haven't experimented enough.

Linear blending is too blurry for me, not that I would expect it not to be. However, it is the one that I get the least amount of artifacts from. I've tried the descaler filters and a few avisynth deinterlace filters but I couldn't get good results and realtime playback.

[_xxl]

First build, libavcodec has been compiled under MINGW, so it has better performances
Could that asm from ffmpeg is "broken" when compiling MinGW GCC 64 builds? No Win64 support?

[MatMaul]

Can't the output stream flag be set up to change automatically change if the interlace flag is set in the input stream?
+1 it would be good to have an "auto" option in the output tab which use weave (no deinterlacing) or bob according to the interlaced flag given by libavcodec.

[tal.aloni]

+1 it would be good to have an "auto" option in the output tab which use weave (no deinterlacing) or bob according to the interlaced flag given by libavcodec.

Guys, That's what already happen!

[littleD]

Finally.. Big :thanks: for implementing that feature Tal oni. Just call it simplier:p
Anyway, i didnt found useful any of deinterlacing method that ffdhow provide. I there any chance to implement yadif deinterlacing? Is it even possible?

BTW, many new features into ffdshow are coming, keep doing nice work guys.

[Inventive Software]

I managed to develop another essential feature,
this one has been requested several times in the past:
the ability to deinterlace only interlaced sources (interlaced flag is set)

I added another checkbox to the top of the "Deinterlacing" section, labeled "Deinterlace all frame types" (perhaps this is not the best name), when checked, the current functionality is remained, when unchecked, only videos marked as interlaced are being interlaced. very convenient.
(http://iknowu.net/files/public/ffdshow/ffdshow-SelectiveDeint-RC1.PNG)

Build:
http://iknowu.net/files/public/ffdshow/ffdshow_rev2228_20081018-SmartDeint-RC1.exe

Source(Patch & Complete Files):
http://iknowu.net/files/public/ffdshow/ffdshow_rev2228_20081018-SmartDeint-RC1.exe

p.s. perhaps there is a better way to implement it, I just added an "if" section to each deinterlacer.

Tal Aloni

I have been waiting for this for a long time. I will test it later on. :)

[MatMaul]

Guys, That's what already happen!
no when I mean in the output tab I speak about the "set interlace flag in output media type" (aka hardware deinterlacing)

[Reimar]

Could that asm from ffmpeg is "broken" when compiling MinGW GCC 64 builds? No Win64 support?

I don't think any of the developers have a MinGW64 setup, so it certainly was never tested.
If there is a simple "just run the installer" way to get MinGW64 I might try, most likely there are issues if MinGW gcc64 considers "long" as only 32 bit, FFmpeg assumes "long" is native pointer size (though if that is the issue I wonder how it could compile at all, it should fail...).

[clsid]

Using MinGW64 is easy. You can get the complete toolchain here:
http://sourceforge.net/project/showfiles.php?group_id=202880

Just unzip the file and you are pretty much done. Of course you would need to add the bin dir to your path environment variable. And set 'CC' to 'gcc'.

[DigitalDeviant]

no when I mean in the output tab I speak about the "set interlace flag in output media type" (aka hardware deinterlacing)

I see what you're saying. It seems like you can change this manually on the fly but doing so seems to crash a lot when you click apply. Also, it seems to only be related to NV12 output. I switched to Ati's plain adaptive deinterlacer which works under YUY2 and it didn't jerk but the deinterlacing wasn't nearly as good as vector adaptive.

[albain]

I don't think any of the developers have a MinGW64 setup, so it certainly was never tested.
If there is a simple "just run the installer" way to get MinGW64 I might try, most likely there are issues if MinGW gcc64 considers "long" as only 32 bit, FFmpeg assumes "long" is native pointer size (though if that is the issue I wonder how it could compile at all, it should fail...).

Yes I do, I set up a Vista 64 on my 2nd HDD only for testing FFDShow 64, otherwise I don't use it.

Disabling the MMX methods made the crash disappeared, but for an unknown reason now we don't get the same results under mingw and msvc

This problem (crashing) has been met with 32 bits version of FFDShow. xxl and clsid figured out that it came from the version of binutils (plus the version of GCC that counts). But there are not the same versions for 64 bits (all are newer).

This is by using gdb under my Vista 64 set up that I figured out the origin of the problem : mmx functions of libavcodec.


However, if this does not crash anymore, this is another problem.

You guys should also try the same samples with mplayer (compiled under 64 bits), if you get the same results then the problem does not come from FFDShow (I doubt it is) : either the 64 bits splitter of ffmpeg.