View Full Version : ffdshow tryouts project: Discussion & Development
Atak_Snajpera
11th March 2008, 00:09
Is it possible to implement TrueHD support in FFDShow?
Inventive Software
11th March 2008, 01:07
Good question. If the patch is *easily* compilable with libavcodec on Windows, then I don't see why not. I'd attempt it, but that means re-installing MinGW and re-compiling a load of stuff that I can't remember how to, having not done it seriously in about a year. :D
EDIT: It also depends on a TrueHD parser having been written and working on Windows.
clsid
11th March 2008, 01:44
I made a custom MinGW installer a few days ago. Here it is:
Download (http://www.zshare.net/download/8749833fa15553/) (8.8 MB)
With this you'll have a fully working and up-to-date MinGW/MSYS environment in a matter of seconds :)
Are there already any (open-source) DirectShow splitters that can parse TrueHD? Without those a decoder in ffdshow would not yet be useful.
If you want you could also attempt to add E-AC3 support. I think that is more wanted than TrueHD.
Inventive Software
11th March 2008, 13:54
Wow, thanks clsid. Wasn't expecting that! :)
AFAIK, no on the splitter front. A parser exists in ffmpeg for TrueHD as a patch, but I'd have to look at eac3to to see how it integrates E-AC3 and TrueHD decoding, and how easy it would be to add the relevant patches to ffdshow.
SeeMoreDigital
11th March 2008, 20:12
Is there any way that files containing DTS-HD or True-HD audio can be "down-converted" to their DTS or AC3 cores on-the-fly?
Cheers
Inventive Software
11th March 2008, 22:47
If eac3to can do it in faster than real-time, then there must be a way. I dunno about on the fly though.
nautilus7
12th March 2008, 00:40
DTS-HD on the fly to DTS isn't needed, because every DTS-HD track contains a simple DTS @ 1536 kbps core.
BTW, the new version of mkvtoolnix supports DTS-HD muxing and haali media splitter can pass the complete track to the decoder (not only the dts core). So using sonic audio decoder, dts-hd playback should work.
@ Inventive Software
You should talk to madshi... He said once that he might make a dshow filter for truehd and eac3 based on libav/ffmpeg decoder.
Thunderbolt8
12th March 2008, 01:42
what was the reason for disabling multithreading with mbaff/paff? was it buggy?
haruhiko_yamagata
12th March 2008, 10:51
well Ozone works, until you open a new file :Thanks. I can reproduce now.
haruhiko_yamagata
12th March 2008, 10:52
what was the reason for disabling multithreading with mbaff/paff? was it buggy?Multithreading worked for interlaced H.264 only if B frames were not used.
leeperry
12th March 2008, 11:34
Thanks. I can reproduce now.
OMG, I hope so much that you can fix this problem and add an option to always hide the winamp2 plugin GUI http://forum-images.hardware.fr/images/perso/kornichon.gif
my HTPC works pefectly now with MPC HC/EVR/Reclock/pstrip....the only last remaining issue is ffdshow crashing with Ozone :(
I'm far from a coder, but I've tried to find how to hide the plugin GUI, and it might have to do with the "Plugin.MainWindow" command :
http://www.codeproject.com/KB/audio-video/winampoutput.aspx
if you could make it always disabled, except if we click on "configure" in the ffdshow audio winamp2 plugin section, that would be marvelous :)
TIA,
chros
12th March 2008, 11:55
if you could always make it disabled, except if we click on "configure" in the ffdshow audio winamp2 plugin section, that would marvelous :)
+1 :)
Thanks
georgevalkov
13th March 2008, 01:13
Hello clsid, I have noticed that the H264 encodding feature is back to ffdshow, so I came to say "thank You" for that, and thanks for spending Your time on that great ffdshow project!
:thanks:
And another one "thank You" for h264 encoder from me :)
Inventive Software
13th March 2008, 02:25
You have xxl to thank for that, not clsid. ;)
georgevalkov
13th March 2008, 04:35
:) Thank You, xxl! :thanks:
By the way where can I read more about the advantages and differences between the two builds: xxl's vs. clsid's SSE
I've been using clsid's SSE version in the past year, because of the SSE instruction set in its title. Or may be I should run a few benchmarks, to see, which is better? :rolleyes:
Mangix
13th March 2008, 05:19
SSE only applies to filter AFAIK
fastplayer
13th March 2008, 11:27
By the way where can I read more about the advantages and differences between the two builds: xxl's vs. clsid's SSE
http://ffdshow-tryout.sourceforge.net/html/en/faq.htm
clsid
13th March 2008, 14:52
It is also explained in the very first post of this topic.
fastplayer
14th March 2008, 13:17
Can ffdshow be updated to use SSE4.1 instructions on 45nm Core 2(Penryn core) cpus to speed up decoding of H.264? I saw from an earlier reply in this thread about Core 2(65nm Conroe) getting SSSE3 support to improve motion compensation.
And if you've looked further you would've noticed that this is not in our hands. Talk to the ffmpeg guys...
clsid
14th March 2008, 15:05
Read the other topics here on Doom9 that are about SSE4. The general conclusion is that using SSE4 will not bring any significant performance improvements compared to the existing implementations (which includes some SSSE3 code).
Furthermore, as mentioned several times before in this topic, we don't develop libavcodec. That is done by the FFmpeg project.
End of discussion.
cc979
15th March 2008, 04:58
anyone tried compile ffdshow-tryout svn1898 with gcc-4.3
i get this error:
make -C baseclasses
make[1]: Entering directory `/home/User/svn/ffdshow-tryout/ffdshow-tryout/src/baseclasses'
gcc-4.3 -c -DRELEASE -mno-cygwin -mdll -fno-rtti -mthreads -pipe -D_WINGDI_ -DUCLIBCPP -D_GLIBCPP_HAVE_MBSTATE_T -D_WIN32_IE=0x0500 -DARCH_IS_IA32 -DARCH_IS_32BIT -DHAVE_MMX -mmmx -w -DNDEBUG -UDEBUG -DFFDEBUG=0 -I. -I.. -Iuclibc++ -Ibaseclasses -I../baseclasses -IimgFilters -I../imgFilters -Implayer -I../mplayer -Isettings -I../settings -Isettings/filters -I../settings/filters -Icodecs -I../codecs -Isubtitles -I../subtitles -Iconvert -I../convert -Idialog -I../dialog -IaudioFilters -I../audioFilters -Icygwin -I../cygwin -Iffmpeg -I../ffmpeg -Iacm -I../acm -Ifilters -I../filters -Imuxers -I../muxers -I/dx/Include -L/dx/MingLib -ldx9 -O2 -march=pentium-mmx -mtune=i686 -fomit-frame-pointer -finline-functions -finline -frename-registers -fweb -funit-at-a-time -MMD -o baseclasses_all.o baseclasses_all.cpp
make[1]: Leaving directory `/home/User/svn/ffdshow-tryout/ffdshow-tryout/src/baseclasses'
make -C acm
make[1]: Entering directory `/home/User/svn/ffdshow-tryout/ffdshow-tryout/src/acm'
gcc-4.3 -c -mno-cygwin -mdll -fno-rtti -mthreads -pipe -D_WINGDI_ -DUCLIBCPP -D_GLIBCPP_HAVE_MBSTATE_T -D_WIN32_IE=0x0500 -DARCH_IS_IA32 -DARCH_IS_32BIT -DHAVE_MMX -mmmx -w -DNDEBUG -UDEBUG -DFFDEBUG=0 -I. -I.. -Iuclibc++ -Ibaseclasses -I../baseclasses -IimgFilters -I../imgFilters -Implayer -I../mplayer -Isettings -I../settings -Isettings/filters -I../settings/filters -Icodecs -I../codecs -Isubtitles -I../subtitles -Iconvert -I../convert -Idialog -I../dialog -IaudioFilters -I../audioFilters -Icygwin -I../cygwin -Iffmpeg -I../ffmpeg -Iacm -I../acm -Ifilters -I../filters -Imuxers -I../muxers -I/dx/Include -L/dx/MingLib -ldx9 -O2 -march=pentium-mmx -mtune=i686 -fomit-frame-pointer -finline-functions -finline -frename-registers -fweb -funit-at-a-time -MMD -o Tacm.o Tacm.cpp
In file included from ../imgFilters/avisynth/Tavisynth.h:5,
from Tacm.h:5,
from Tacm.cpp:21:
../imgFilters/avisynth/avisynth.h:697: error: conflicting type attributes specified for 'virtual GenericVideoFilter::~GenericVideoFilter()'
../imgFilters/avisynth/avisynth.h:549: error: overriding 'virtual IClip::~IClip()'
make[1]: *** [Tacm.o] Error 1
make[1]: Leaving directory `/home/User/svn/ffdshow-tryout/ffdshow-tryout/src/acm'
make: *** [lib] Error 2
cheers
Leak
15th March 2008, 11:03
anyone tried compile ffdshow-tryout svn1898 with gcc-4.3
i get this error:
In file included from ../imgFilters/avisynth/Tavisynth.h:5,
from Tacm.h:5,
from Tacm.cpp:21:
../imgFilters/avisynth/avisynth.h:697: error: conflicting type attributes specified for 'virtual GenericVideoFilter::~GenericVideoFilter()'
../imgFilters/avisynth/avisynth.h:549: error: overriding 'virtual IClip::~IClip()'
That has to be a bug in gcc, seeing as GenericVideoFilter doesn't even declare it's own destructor:
// instantiable null filter
class GenericVideoFilter : public IClip {
protected:
PClip child;
VideoInfo vi;
public:
GenericVideoFilter(PClip _child) : child(_child) { vi = child->GetVideoInfo(); }
PVideoFrame __stdcall GetFrame(int n, IScriptEnvironment* env) { return child->GetFrame(n, env); }
void __stdcall GetAudio(void* buf, __int64 start, __int64 count, IScriptEnvironment* env) { child->GetAudio(buf, start, count, env); }
const VideoInfo& __stdcall GetVideoInfo() { return vi; }
bool __stdcall GetParity(int n) { return child->GetParity(n); }
void __stdcall SetCacheHints(int cachehints,int frame_range) { } ; // We do not pass cache requests upwards, only to the next filter.
};
np: Proem - Live @ LSR 03-19-2006 (Merck Fragments)
leeperry
18th March 2008, 14:41
ok, I'm exchanging PM's with haruhiko concerning the winamp2 plugin crashing problem.
he told me he would need some open source winamp2 plugin with the problem, so he can find what's wrong.
I'm in contact with Vincent Burel, his FFX4 plugin has the problem as explained here :
http://forum.doom9.org/showpost.php?p=1096605&postcount=3111
he told me that he would help to find the problem, and I asked him if he could PM haruhiko and apparently he's willing to :)
also, haruhiko can't find how to hide the winamp2 plugin GUI, so if anyone knows ?!
I'm also in contact with Seb.26 to see if he can help.
I'm far from a coder, but I've tried to find how to hide the plugin GUI, and it might have to do with the "Plugin.MainWindow" command :
http://www.codeproject.com/KB/audio-video/winampoutput.aspx
if anyone knows of an open source winamp2 plugin that crashes ffdshow audio, please help :p
at least I'm not sitting on my ass moaning clsid :D
Inventive Software
18th March 2008, 15:15
If the plugin has a GUI hard-coded into it, then it's likely that it's near impossible to hide it. If Winamp can hide it, then debugging that and seeing what calls it gives out to the window would be a step closer. :)
leeperry
18th March 2008, 15:22
well yeah, you can hide any DSP plugin window with winamp :)
leeperry
18th March 2008, 16:06
ok I've talked to Vincent Burel.
he's told me the best way would be to get back to him with details on the crash, and he would do his best to help.
his email is vincent.burel____vb-audio.com (replace ____ with @)
the problem is the same with Ozone or with his FFX4 plugin as explained here :
http://forum.doom9.org/showpost.php?p=1096605&postcount=3111
as soon as you open a new track in MPC HC, ffdshow crashes.....but if you click on CONFIGURE in the fffdshow audio winamp2 section, then it doesn't crash anymore but after 3 files in a row it's using 70% of CPU time :eek:
hope something can be worked out :(
leeperry
19th March 2008, 10:57
OK, Vincent Burel has given me some infos about his FFX4 winamp2 plugin(that also crashes with ffda).
FFX4 is using the SDK 0.9 for winamp2.
it's a very basic SDK that only defines 4 functions :
-init : to create the plugin
-modifysamples : to process the audio
-quit : to kill the plugin
and finally "config" to open the plugin GUI.
but nothing's been done to communicate from the host, which doesn't even know the handle name of the plugin GUI(if that was the case, a SW_HIDE would be fine to hide the window)
so he believes that the only way to never have the plugin GUI showing up is to never call the "config" function.
once this function has been called, to hide the GUI again, you would have to kill the effect(QUIT) and recreate it(without using "config" of course)
leeperry
19th March 2008, 11:32
calling CONFIG twice in a row might also hide the GUI, considering the plugin knows its GUI is already being shown
leeperry
20th March 2008, 22:26
somehow I can sense Ozone will keep on crashing with ffdshow audio for a long long time :D
Seb.26 is gonna take a look on this week end, but he told me ffdshow audio is basically thousands of code lines w/o any comments :(
EpheMeroN
21st March 2008, 10:03
Would it be possible to implement ReClock's capabilities into the new ffdshow-tryouts?
dimzon
21st March 2008, 13:26
Would it be possible to implement ReClock's capabilities into the new ffdshow-tryouts?
+1
:)
clsid
21st March 2008, 14:37
Such functionality is not the job of a decoder. Its probably even technically impossible. So imo the answer is NO. In its current state ffdshow is already large and complex enough.
Also, instead of re-inventing the wheel, the existing wheel should just be improved.
leeperry
21st March 2008, 14:42
besides Reclock works perfectly fine :)
some friends of mine very much enjoy the "Frame Rate doubler" in the deinterlacer section of ffdshow.
you force 24fps with Reclock and you get "DNM-like" 48fps this way.
you run your display in 48Hz with pstrip, and you're good to go :)
it doesn't work too well on my PC though(random freezes+artifacts with scene changes), so I prefer to use only Reclock in 23.976@24 in 48Hz :cool:
Leak
21st March 2008, 17:11
Such functionality is not the job of a decoder. Its probably even technically impossible. So imo the answer is NO. In its current state ffdshow is already large and complex enough.
Well, it should be possible to twiddle the video timestamps to some other frame rate and resample/timestretch the audio accordingly.
But synchronizing the whole shebang with the monitor's refresh rate? Yeah, that's out of ffdshow's league and needs to be done by the video renderer.
np: Autechre - Nofour (Quaristice (Versions))
clsid
21st March 2008, 18:47
True, but that would require ffdshow to decode both audio and video, which is not necessarily always the case. But anyway, lets just quickly forget this topic.
fano
26th March 2008, 20:45
I have a feature request now if I have for example a 5.1 AAC file I must encode it to AC3 5.1 @ 640 Kbit/s to send it to my receiver via spdif... is possible to add DTS encoding @ 1.5 Mb/s?
I think we can have more quality in this way (less compression!).
Are you working in hdmi uncompressed PCM support (maybe is too early... no real HDMI soundcard for now) and new DTS and AC3 HD codec?
I think is very important to have free solution for audio HD decoding...
Thanks for the answers,
fanoI
clsid
26th March 2008, 21:32
I don't think an open-source DTS encoder currently exists. So the answer would be no.
Kurtnoise
26th March 2008, 21:47
\o/ (http://svn.mplayerhq.hu/soc/dcaenc/)...
bwahn
27th March 2008, 07:08
hi~ ffdshow tryout team.
I have a question about dxva.
in svn, I checkout ffdshow-tryout.rev1913 and /branches/dxva.
then, I copied dxva/src/*.* files into ffdshow-tryout.rev1913/src directory.
using ffdshow_2005.vcproj, I tried compile ffdshow.
I have some error.
....
fatal error C1083: Cannot open include file: 'dxva2api.h': No such file or directory
...
trying find dxva2api.h , but can't found it.
where can I download dxva2api.h?
or something sdk install?
I installed "Windows Server 2003 R2 Platform SDK.3790.2075" and "Microsoft DirectX SDK (April 2007)".
thanks for any help.
Eric Ahn.
_xxl
27th March 2008, 07:34
DXVA is not supported. Try MPC-HC for h.264 and vc-1 dxva decoders.
fano
27th March 2008, 09:08
\o/ (http://svn.mplayerhq.hu/soc/dcaenc/)...
So a free DTS encoder is on the way... good.
We have to wait when it is completed and integrated in ffdshow!
Maybe will arrive first the PCM multichannel conversion for usage on real HDMI output... the problem is that for now there is not HDMI soundcard :eek:
fano
CruNcher
27th March 2008, 14:33
is it possible to watch elementary .264 files with ffdshow? it seems ffdshow can't parse the Mpeg-2 data from Mainconcept based parser correctly (detecting its AVC flag and so redirect to the H.264 Decoder instead of the Mpeg-2) that stops the connection? :(
MainConcept MPEG Demultiplexer::AVC
Media Type 0:
--------------------------
Video: MPEG2 Video 1280x720 25.00fps
AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {8D2D71CB-243F-45E3-B2D8-5FD7967EC09B}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
ahh i see when Mpeg-2 under Codecs is set to Libavcodec then it works (tough if someone doesn't want Mpeg-2 to be decoded with it that's no real solution) :)
and it's still not correctly playing (alot of frame skips with -b-pyramid and -bime jumps to the next i-frame to many b-frames in general seem to be the problem)
Filter : MainConcept MPEG Demultiplexer - CLSID : {79DF8A70-E7D5-49DB-ADC4-A4BE0E193AA2}
- Connected to:
CLSID: {04FE9017-F873-410E-871E-AB91661A4EF7}
Filter: ffdshow Video Decoder
Pin: In
- Connection media type:
Video: MPEG2 Video 720x576 (4:3) 25.00fps
AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {8D2D71CB-243F-45E3-B2D8-5FD7967EC09B}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 184
VIDEOINFOHEADER:
rcSource: (0,0)-(720,576)
rcTarget: (0,0)-(720,576)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 400000
VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 4
dwPictAspectRatioY: 3
dwControlFlags: 0x00000000
dwReserved2: 0x00000000
MPEG2VIDEOINFO:
dwStartTimeCode: 0
cbSequenceHeader: 48
dwProfile: 0x0000004d
dwLevel: 0x0000001f
dwFlags: 0x00000000
BITMAPINFOHEADER:
biSize: 40
biWidth: 720
biHeight: 576
biPlanes: 0
biBitCount: 0
biCompression: 0
biSizeImage: 0
biXPelsPerMeter: 2868
biYPelsPerMeter: 3128
biClrUsed: 0
biClrImportant: 0
pbFormat:
0000: 00 00 00 00 00 00 00 00 d0 02 00 00 40 02 00 00 ........Ð...@...
0010: 00 00 00 00 00 00 00 00 d0 02 00 00 40 02 00 00 ........Ð...@...
0020: 00 00 00 00 00 00 00 00 80 1a 06 00 00 00 00 00 ........€.......
0030: 00 00 00 00 00 00 00 00 04 00 00 00 03 00 00 00 ................
0040: 00 00 00 00 00 00 00 00 28 00 00 00 d0 02 00 00 ........(...Ð...
0050: 40 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 @...............
0060: 34 0b 00 00 38 0c 00 00 00 00 00 00 00 00 00 00 4...8...........
0070: 00 00 00 00 30 00 00 00 4d 00 00 00 1f 00 00 00 ....0...M.......
0080: 00 00 00 00|00 00 00 01 67 4d 40 1f b9 04 01 68 ........gM@.¹..h
0090: 24 d0 80 00 00 03 00 80 00 00 19 71 30 00 0d 59 $Ѐ....€...q0..Y
00a0: f8 00 06 ac fd 02 8c c7 51 a2 d8 88 00 00 00 01 ø..¬ý.ŒÇQ¢Øˆ....
00b0: 68 e9 39 f2 00 00 00 00 hé9ò....
- Enumerated media type 0:
Set as the current media type
i added the {8D2D71CB-243F-45E3-B2D8-5FD7967EC09B} to ffdshow i think that makes the connection possible @ all
Inventive Software
27th March 2008, 16:38
.264 playback needs a parser. I'm in the process of seeing how integrating most of libavformat to play said files to a DShow filter, but I cannot for the life of me find a skeleton DShow filter to do this. :(
clsid
27th March 2008, 17:38
You could have a look in the MPC-HC/Guliverkli2 projects. That contains a 'BaseSplitter'. Maybe that's useful.
SeeMoreDigital
27th March 2008, 19:17
Donald Graft's DGAVCIndex (http://forum.doom9.org/showthread.php?t=122598) application is able to play elementary AVC streams, with libavcodec.dll. Could any of his software be incorporated/used?
clsid
27th March 2008, 19:31
Unless that application uses DirectShow, it's useless.
georgevalkov
28th March 2008, 13:25
Hello ffdshow developers!
There's a minor problem with the Logoaway filter, when an image mask is used (Mode:Shape XY). Please fix it, if You find time! :thanks:
1. The picture under the black area of the mask is shifted up by 1 line. It should be left unchanged.
2. The colours under the black area of the mask are modified. They should be left unchanged.
I tried interlaced material: 720x576@25i PAL; 704x576@25i PAL;
YUY2 and RGB24 - all produced the same problem in the output.
The mask is in its original size. The other images below are zoomed 200% or 400% (nearest neighbour in Photoshop).
CruNcher
29th March 2008, 22:45
There seems to be a Multithreading Slice Decoding bug in the H.264 Decoder in the current ffdshow, you can see the problem it couses here with this stream.
http://mirror05.x264.nl/CruNcher/force.php?file=./chromaprob/ateme-high.mp4
http://s6.directupload.net/images/080329/lo7lapez.png
MPCs Internal Decoder has the same problem it helps to set the threads to 1, to avoid it tough ffdshow tryout has no such option (didn't found any)
The stable build works without problems, it seems to be existing allready very long as build 1890 (i used before) also had these decoding problems.
clsid
30th March 2008, 00:08
You can change the number of threads in "Decoder options" section of ffdshow config.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.