ffdshow tryouts project: Discussion & Development

[chros]

I've used a MKV file with MP3, AAC and Ogg Vorbis audio tracks. I've used too a MKA file generated by me with three audio tracks: one in FLAC (8 channels), one in TTA (8 channels) and one in WavPack (8 channels). If I load the original files, one by one, independently that are or not inside a MKA, there are no problem, but if I use them in an only file (the MKA I mentioned), FFDShow won't work in audio changing. The only exception is that audio tracks have the same encoding; then, FFDShow continues loaded and are heared correctly, with the downmixing done properly.

I don't know if this info may help, but I'll say it: I'm using latest Haali Media Splitter, and I'm using too latest build of FFDShow tryouts.
Are you sure that the internal mkv splitter is disabled in MPCHC/MPC ? (so you're using Haali's splitter ?)

I have tried with mkv+x264+aac+ac3 and I have set the corresponding internal audio decoders in MPCHC, and set "uncompressed" to "all supported" in ffdshow: some strange thing's happening, but I can switch the audios back-and-forth.

But if I disable the the built-in audio decoders and ffdshow is responsible for the audio decoders, everything is fine with Haali's splitter but NOT with the built-in splitter (same effect when I said "strange") !!!
See this post: http://forum.doom9.org/showthread.php?p=1124285#post1124285

So, my suggestion is that try to find the corresponding audio decoders within ffdshow (if they exist in it) ...

[juanchu]

OK, chros, thank you so much.

I'm totally sure that I'm using Haali Media Splitter (icon is loaded in sistem tray).

This is what has happened when I've activated FFDShow's filters of codecs with >2 channels support (Ogg Vorbis, FLAC, TTA and WavPack), and whose decoders I'm using haven't downmixing support, the ones that are importante to me for being heared correctly:

-If I activate Ogg Vorbis support, the decoding is correctly, even when I change audio track.

-If I activate FLAC support, the decoding is correctly, even when I change audio track.

-If I activate TTA support, doesn't work, it's heared horribly. However, is I use True Audio Decoder and FFDShow's downmixing, everything is OK, even when I change audio track, because True Audio Decoder's output is a PCM 8 Channels, and FFDShow will be forced to be loaded, because mi soundcard doesn't support that tipe of audio input (however, FFDShow's PCM 2 channels output works great).

-So, the problem comes with WavPack. I don't see that FFDShow has support for this, and with this codec happens what I've said: if it's loaded if first place, it works the downmixing, but if it's loaded in second, third, etc. place, downmixing won't be done, and I will only hear the first two channels (it doesn't happen same thing as TTA, because CoreWavPack's output is WAVE_FORMAT_EXTENSIBLE).

So, with this configuration, the problem is partially resolved, but problems will continue when secondary audio tracks are encoded with codecs with >2 channels support, FFDShow isn't used to decode them, only for doing the downmixing, and the decoders used to decode these tracks haven't downmixing support (I'm forced to use FFDShow with FLAC (I normally use madFlac decoder) and Ogg Vorbis (I normally use CoreVorbis decoder)).

So, as I said, problem is partially resolved, but if I get or do a file with secondary audio tracks in WavPack with >2 channels, I will be forced to make a MKV file whose default audio track is the one that isn't downmixed when I do the track's changing.

Well, I hope that this problem is seen by developers, and fixed. In ZoomPlayer, with changing audio track with this configuration, I got sometimes memory errors, so I think it's FFDShow's problem.

Thank you so much for your help!

[clsid]

The problem that you describe is a "known" problem. It has been discussed in the past in the Haali Media Splitter topic. I don't remember the details, but it has something to do with dynamically changing the DirectShow filter graph. That doesn't always go well when different decoders are used. It's not a specific ffdshow problem.

[juanchu]

Thank you for this interesting info, clsid!

Well, it seems that I'll have to wait until WavPack is supported in FFDShow. Then, this problem will "dissapear". Until then, I will use MKVmerge to generate a MKV or MKA whose main audio track is the WavPack's one.

Thank you!

[chros]

Thank you so much for your help!
I'm glad that I could help.

Ask haruhiko_yamagata for supporting wavpack, he's "responsible" for the audio part :) He's very smart and very kind !!!

And welcome here at the doom9 community ! :)

[leeperry]

I was wondering, if I resize 1280*544 to 1280*768 and keeping AR, does ffdshow only add black borders or does it actually resize the picture ?

because if I increase the luma sharpen, it does make a difference........after all :)

otherwise is there a way to simply add borders up to 1280*768 w/o resize ?

[clsid]

FFmpeg does not have good WavPack decoding code last time I checked, and I am against adding functionality that doesn't work properly.

[juanchu]

Obviusly, clsid, is preferible waiting for until WavPack's support is better in FFMPEG (lossy, lossless and hybrid modes). So, I will continue using CoreWavPack, and will generate my own MKV with WavPack's track as the default one if I get one with this particularity (WavPack's track as secondary one, and >2 channels). It's not the best solution, but doesn't matter.

Thank you for all info that you're giving to me! I'm learning a lot of things!

[yangxi]

New GCC Quick Reference Guide for Optimized x86 Code Generation
http://developer.amd.com/assets/AMD_GCC_Quick_Reference_Guide080509.pdf

Does it any improve for PHENOM cpu?..

[Manao]

haruhiko_yamagata : YV16 is Y/V/U 422 planar. I422 is Y/U/V 422 planar. It's the same difference as YV12 / I420 (and, by inference, YV24/I444)

[ericab]

anyone know where i can get a pre-compiled ffdshow build 1967 ?

[cc979]

svn1967
http://www.speedyshare.com/721267853.html

[ericab]

svn1967
http://www.speedyshare.com/721267853.html

thanks cc979.

[chros]

FFmpeg does not have good WavPack decoding code last time I checked, and I am against adding functionality that doesn't work properly.
But I meant that we can see at the video config: eg. supporting xvid -> xvid and vc-1 -> wmv9 (external decoders ?)

Sorry if I'm misunderstanding something ...

[nautilus7]

I get glitches decoding this (http://www.sendspace.com/file/5421g7) H.264 video sample (it's from Chicken little blu-ray disc). The problem is only in the very first seconds. Both ffdshow and mpc-hc's internal decoder behave the same, while other decoders such CoreAVC and Cyberlink work fine. Is it an ffdshow problem or an ffmpeg one? Thanks.

[haruhiko_yamagata]

haruhiko_yamagata : YV16 is Y/V/U 422 planar. I422 is Y/U/V 422 planar. It's the same difference as YV12 / I420 (and, by inference, YV24/I444)
Thank you.
In ffdshow,
YV12 is FF_CSP_420P and
I420 is FF_CSP_420P|FF_CSP_FLAGS_YUV_ORDER.

So
YV16 should be FF_CSP_422P and
I422 should be FF_CSP_422P|FF_CSP_FLAGS_YUV_ORDER.

Unfortunately, in current ffdshow FF_CSP422P is I422.

I tried to change this, but it was too much work. I have added FF_CSP_YV16. It's working. I'll commit soon.

[lamer_de]

I know this is prbably not high on the priority list, but it would be really nice to have a slightly improved ssa/ass subtitle support. A rather important feature for me would be the ability to display 2 lines of text at once. Currently, whenever there are 2 lines displayed simultaneously, only the one that starts earlier gets shown. This is basically the case everytime a sign is displayed (which happens quite a lot, be it with fansubs or subtitles for "regular" movies).

What would also be nice to have is the support for the \fr (rotation) tag, which is also quite common for styled signs. I have no clue how much coding this would involve, but seeing that mplayer supports these things, I guess there might be code that is reusable(?)

[haruhiko_yamagata]

I know this is prbably not high on the priority list, but it would be really nice to have a slightly improved ssa/ass subtitle support. A rather important feature for me would be the ability to display 2 lines of text at once. Currently, whenever there are 2 lines displayed simultaneously, only the one that starts earlier gets shown. This is basically the case everytime a sign is displayed (which happens quite a lot, be it with fansubs or subtitles for "regular" movies). Please check "Subtitles->Text->Overlap subtitles with same time". Collisions are not supported though.

What would also be nice to have is the support for the \fr (rotation) tag, which is also quite common for styled signs. I have no clue how much coding this would involve, but seeing that mplayer supports these things, I guess there might be code that is reusable(?)
Yes, there is re-usable code. But I'm sorry, it's priority is low.

[Mr VacBob]

svn1967
http://www.speedyshare.com/721267853.html

It's not important, but the GPL shouldn't be used as a click-through license here. It specifically allows you to use ffdshow/whatever even if you don't agree to it.

edit: also, the proper fix for r1960 would be adding 'dst->mb_xy = src->mb_xy;' to copy_mb_to_context in h264.c. If that doesn't work, recalculate it as in the removed line in decode_mb_cabac.

[cc979]

It's not important, but the GPL shouldn't be used as a click-through license here. It specifically allows you to use ffdshow/whatever even if you don't agree to it.


Explain, do you mean - many ffdshow-tryout compiles avaible for testing, why post about that one ?

[Mr VacBob]

It was the last one linked - that applies to anything with the same installer.

[cc979]

i did not design it, i just compiled it from the sources - best take it up with the project leaders

[Mercury_22]

I have successfully cross-compiled libavcodec from win32 to win64 using MinGW GCC 4.4.0.
This had to be changed:
Index: idct_sse2_xvid.c
===================================================================
--- idct_sse2_xvid.c (revision 1965)
+++ idct_sse2_xvid.c (working copy)
@@ -338,7 +338,7 @@
"movdqa %%xmm6, 4*16("dct") \n\t" \
"movdqa "SREG2", 7*16("dct") \n\t"

-inline void ff_idct_xvid_sse2(short *block)
+void ff_idct_xvid_sse2(short *block)
{
asm volatile(
"movq "MANGLE(m127)", %%mm0 \n\t"
ffdshow-tryouts 1966 x64 build:
Download (http://www.dump.ro/download.php?file=ffdshow_rev1965_20080520_x64.7z&id=MDE5OGNiMWRiZTA3MGZhM2RhZTY2YTBkMjUyZmYxMTA=&download=true)

Hi ! link it's not working ! when I try to download it's an 798 bytes (ffdshow_rev1965_20080520_x64_[from_www.dump.ro].7z ) file which I can't open :confused:

[LoRd_MuldeR]

Hi ! link it's not working ! when I try to download it's an 798 bytes (ffdshow_rev1965_20080520_x64_[from_www.dump.ro].7z ) file which I can't open :confused:

Open the downloaded file in a text editor. You'll see:
<br />
<b>Warning</b>: filesize() [<a href='function.filesize'>function.filesize</a>]: stat failed for upload//ffdshow_rev1965_20080520_x64 [from www.dump.ro].7z in <b>/var/www/localhost/htdocs/vhosts/www.dump.ro/download.php</b> on line <b>48</b><br />
<br />
<b>Warning</b>: Cannot modify header information - headers already sent by (output started at /var/www/localhost/htdocs/vhosts/www.dump.ro/download.php:48) in <b>/var/www/localhost/htdocs/vhosts/www.dump.ro/download.php</b> on line <b>48</b><br />
<br />
<b>Warning</b>: readfile(upload//ffdshow_rev1965_20080520_x64 [from www.dump.ro].7z) [<a href='function.readfile'>function.readfile</a>]: failed to open stream: No such file or directory in <b>/var/www/localhost/htdocs/vhosts/www.dump.ro/download.php</b> on line <b>49</b><br />

Obviously a server problem :rolleyes:

[Shinigami-Sama]

go go phphail

looks like output buffering wasn't active/working/used when you tried to DL it

[_xxl]

Please wait new ffdshow-tryouts 32 and 64 bit will be available from SF.

[Mercury_22]

Please wait new ffdshow-tryouts 32 and 64 bit will be available from SF.

I've just installed ffdshow_rev1972_20080524_x64 Thanks for the great work! :thanks:

However I have a small problem with ffdshow_rev1972_20080524_x64's Audio decoder : on a vob file with 2 audio ac3streams 2Channel and 5+1Channels I can't hear anything all though in ffdshow's Audio decoder Volume "page" I can see levels moving for L, C, R, BackL, BackR and LFE ! Any Idea ?:confused:
(With MPC-HCx64's internal AC3 I can hear the 2 channels stream)

[clsid]

Please try an older x64 build to see if that gives the same problems.

[_xxl]

No just MinGW GCC x64 is broken, msvc x64 works.
I''ll update soon.

[draggoon01]

are there plans to release a stable build any time soon?

[clsid]

No just MinGW GCC x64 is broken, msvc x64 works.
I''ll update soon.
Ok, so the problem is unrelated to your code changes from rev1972? Just some GCC bug?

[_xxl]

Don't know yet, before 1972 liba52 couldn't be compiled by MinGW GCC 4.4.0 for x64.
Will update soon.

[arfster]

HI folks. Quick suggestion: how about an auto mode for bt601/709? The method Haali renderer uses makes sense, based on horizontal res (if above 1024 use bt709, if below bt601).

[3ngel]

It seems that the YV16 problem is corrected in the last build.
Thank you very much.

[Atak_Snajpera]

Can we expect e-ac3 support in near future?

[clsid]

From what I read on the FFmpeg mailing list, it is finally going to be commited to FFmpeg SVN in the very near future. After that we will attempt to add it to ffdshow as well. xxl recently already tried to add AC3/EAC3/DTS support to ffdshow's libavcodec, but that didn't work properly yet. So it isn't going to to be a trivial update.

[iron2000]

HI folks. Quick suggestion: how about an auto mode for bt601/709? The method Haali renderer uses makes sense, based on horizontal res (if above 1024 use bt709, if below bt601).

I'm doing this now with auto-load profiles as previously suggested by leeperry.

[nnever2000]

are there plans to release a stable build any time soon?

Good question, I'm still with last stable: ffdshow_rev610_20061201_clsid.exe

[_xxl]

That is an old buggy build, please update!

[compunett]

Indeed Justin Ruggles who work on the EAC3 support is doing the last adjustment before committing. I don't know how much the intricate things of ffmpeg and directshow can infer on this merge, or even if the difficulty is tied to that, but I guess the author can probably help you out.

[nnever2000]

That is an old buggy build, please update!

There is no other stable release!

Can the tryouts be considered stable?

Thanks

[Eragon4ever]

The beta builds are labeld "stable" because they are tested for a while before release. Latest beta ist beat4 (rev1723).

But I consider even the nightlys as stable - never had any problems.

[nnever2000]

The beta builds are labeld "stable" because they are tested for a while before release. Latest beta ist beat4 (rev1723).

But I consider even the nightlys as stable - never had any problems.

Ok I will replace the 610 version with 1723.
Thanks for help

[Atak_Snajpera]

Ok I will replace the 610 version with 1723.
Thanks for help

Don't pay attention on 'unstable' label. Use latest revision.

[Shinigami-Sama]

Don't pay attention on 'unstable' label. Use latest revision.

+1
that 'stable' release stuff is BS and shouldn't be applied like a blanket or you end up like debian

this is an example of a package that its latest builds are stable, often more so than the older builds!

[nnever2000]

Ok, ok, just updated with the last

ffdshow_rev1980_20080602_clsid.exe

for now, no problem at all.

Thanks, the h264 decoder seem much better.

[Atak_Snajpera]

I have tiny request. Could you clsid and xxl add revision number in registry? This would help me to detect installed FFDShow revision on users pc.

[clsid]

The installer already does that :)

HKLM\Software\GNU\ffdshow, dword: revision

[Atak_Snajpera]

OK. Thanks a lot. I was looking in Current_user :)

[nnever2000]

Ok, ok, just updated with the last

ffdshow_rev1980_20080602_clsid.exe

for now, no problem at all.

Thanks, the h264 decoder seem much better.

Only a little bug: on the vfw decoder the DIVX3 combo is blank and not "libvcodec" or "disabled"