View Full Version : ffdshow tryouts project: Discussion & Development
tal.aloni
22nd November 2008, 23:55
Would I be correct in assuming that DTS Express can't be decoded by ffdshow because libavcodec cant (libdts too).
pretty much, but I'm not so sure it would be a priority,
current decoding of DTS-MA / DTS-HD is limited to the core DTS track, so I'm guessing that those formats will have more focus than DTS express. but this is up to the ffmpeg developers.
BatKnight
23rd November 2008, 00:58
the best is getting an 6/8 ch PCM over HDMI cabable receiver.
If we must stay in the s/pdif realm, it would be wiser not to re-encode, but that's not always preferred. for example, my room demand some equalization, so I would prefer re-encoding, that way I could apply the necessary post-processing, most receivers are much more limited in that area.
I understand, but considering the scenario where the external decoder isn't TrueHD or DTS-HD decoding capable, and if it is quaility-wiser not to reencode, then why isn't the option of stripping the AC3 part of a TrueHD track available?
I've tried with the TrueHD 5.1ch 48KHz.m2ts sample file and even with AC3 SPDIF pass-through selected, ffdshow still decodes the MLP.
I get the ffdshow audio decoder saying:
Input: 48000Hz, 6 channels mlp (livabcodec) and the Output Pin: Audio: WAVE_FORMAT_EXTENSIBLE 48000Hz 6ch 4608Kbps
I recall the ability to play the AC3 stream from this same file before the libavcodec branch was merged into the SVN trunk.
I am now using ffdshow-mt 2344, but the SVN ffdshow does the same.
Bat
tal.aloni
23rd November 2008, 08:56
then why isn't the option of stripping the AC3 part of a TrueHD track available?
There is:
Disable the MLP decoder (and enable AC3 S/PDIF pass-through).
haruhiko_yamagata
23rd November 2008, 11:08
That's what I meant - you need GCC anyway, so why suddenly stop supporting it for compiling the main part?Because it takes time to support GCC compilation. Besides I have to give up using any MSVC specific features.
Milan loved GNU so much, I have tried to respect it. However it's just hard.
haruhiko_yamagata
23rd November 2008, 11:21
Perhaps we can statically link in that stuff? Then we could completely switch to VS2008.
http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx
Because a DLL built by linking to a static CRT will have its own CRT state, it is not recommended to link statically to the CRT in a DLL unless the consequences of this are specifically desired and understood. For example, if you call _set_se_translator in an executable that loads the DLL linked to its own static CRT, any hardware exceptions generated by the code in the DLL will not be caught by the translator, but hardware exceptions generated by code in the main executable will be caught.This was the rationale that I didn't want to link statically. Because I couldn't understand what it means.
Now I can understand, I think static link should be OK.
haruhiko_yamagata
23rd November 2008, 11:28
OK, I just updated from 2307 to 2333 mt as I saw the resource leak was fixed and ffdshow h.264 decoder wouldn't load for h.264 TV on DVBviewer.:scared:There is no DVB in Japan. Can you reproduce it with off line file? I can play h264.ts file using DVBViewer (off line mode).
ikarad
23rd November 2008, 14:02
Which is completely useless if your source isn't telecined but "true" interlaced :rolleyes:
To enable Hardware Deinterlacing, check "Set interlaced flag in output media type". I also learned that it may be necessary to limit the output colorspace to NV12.
Also note that Hardware Deinterlacing won't work with Haali Renderer. The Overlay Mixer or VMR7 should work though...
I personally am not really satisfied with Hardware Deinterlacing. But you should give it a try and see if it works well for you or not.
Anyway, the "FFmpeg deinterlacer" is a very simple one. And it's a deinterlacer (25i -> 25p). For smooth motion I'd highly recommend to use a bobber (25i -> 50p).
My favorites quality-wise are: Yadif ("Double Framerate" mode), "Greedy 2 Frame" (available through DScaler plugin) and KernelBob (Threshold < 5).
Most of sources are only telecined like anime.
nm
23rd November 2008, 15:32
Most of sources are only telecined like anime.
Depends on where you live and what you watch. In PAL countries all TV broadcasts and DVD releases are basically either straight progressive (2:2 pulldown) or interlaced. Personally I only have some 3:2 telecine test clips around but I receive interlaced DVB every day.
LoRd_MuldeR
23rd November 2008, 17:28
Most of sources are only telecined like anime.
That applies to NTSC countries and to cinema productions only! In PAL countries there's no such thing as "telecined" video ;)
In PAL countries you either get the movie as progressive (24p -> speed up -> 25p) or you get a crappy field blended conversion (24p -> telecine -> NTSC -> field blend -> PAL).
Also TV productions will always be "true" interlaced, 60 fields/second in NTSC countries or 50 fields/second in PAL countries...
clsid
23rd November 2008, 18:52
@xxl, haruhiko,
I have installed VS2008SP1. Static linking seems to work ok. I am uploading a build to sf.net now so everyone can test. It also includes Haruhiko's recent safe string patch.
Once all vs2008 project files have been updated for static mfc linking, we could completely switch to supporting just vs2008. I think we are then all using vs2008? If so, all vs2003/2005 project files can be removed.
jos99
23rd November 2008, 18:57
There is no DVB in Japan. Can you reproduce it with off line file? I can play h264.ts file using DVBViewer (off line mode).
Sorry for not being more specific- it wasn't just TV, it wouldn't load for any h.264 file- just gave a black screen and ffdshow didn't show up in the filters in use. Maybe I selected something wrong in the setup?
_xxl
23rd November 2008, 18:59
Once all vs2008 project files have been updated for static mfc linking, we could completely switch to supporting just vs2008. I think we are then all using vs2008? If so, all vs2003/2005 project files can be removed.
Ok, when ready please remove them.
fastplayer
23rd November 2008, 19:25
I am uploading a build to sf.net now so everyone can test. It also includes Haruhiko's recent safe string patch.
You just uploaded build 2347, yet 2348 contains the new goodies. Am I missing something? :confused:
clsid
23rd November 2008, 19:37
The build includes the goodies (some of which are not comitted yet).
Reimar
23rd November 2008, 20:59
Then I calculated badly. But it's at least 160% faster.
[...]
Same file, yadif double frame rate
ffdshow_rev2303_20081106-mt.exe:User: 41s, kernel: 0s, total: 41s, real: 42s, fps: 29.2, dfps: 29.2 34.25ms/frame 27.72ms/yadif -> 100%
ffdshow_rev2307_20081107-mt.exe:User: 28s, kernel: 0s, total: 29s, real: 29s, fps: 42.3, dfps: 42.3 23.64ms/frame 17.11ms/yadif -> 162%
Going by this SSE speed is 162% the original speed, but that is the same as being 62 % faster, 162 % faster would be more than double speed!
tal.aloni
23rd November 2008, 21:17
_xxl, great work!
I'm very happy with ffdshow-mt,
finally there's a free and stable alternative for H.264 decoding.
Tal
CruNcher
23rd November 2008, 21:26
though stability compared to commercial decoder seems still low i sometimes lose up to 4 frames of the original source input (beginning,end) :( in different rendering scenarios (AVC,ASP,Mpeg-2), also frame exact seeking is still bad too. Using the same Splitter Haali's for all of them ffdshow always loses frames or endsup @ the wrong frame when for example requesting a b-frame compared to CoreAVC,DivX,Elecard,Cyberlink,Arcsoft,Nero :( I lost hope that the Libavcodec guys gonna ever improve that but i wonder if it can't be done via a workaround over dshow forceing it somehow.
LoRd_MuldeR
23rd November 2008, 21:56
though stability compared to commercial decoder seems still low i sometimes lose up to 4 frames of the original source input (beginning,end) :( in different rendering scenarios (AVC,ASP,Mpeg-2), also frame exact seeking is still bad too. Using the same Splitter Haali's for all of them ffdshow always loses frames or endsup @ the wrong frame when for example requesting a b-frame compared to CoreAVC,DivX,Elecard,Cyberlink,Arcsoft,Nero :( Tough i guess the Libavcodec guys never gonna improve that but i wonder if it can't be done via a workaround over dshow :(
Why not use DGAVCSource when you need frame accurate-access? That will be required for editing only anyways, for pure playback it doesn't matter...
CruNcher
23rd November 2008, 22:08
Easy answer DGAVCSource isn't dshow it would make the transcoding framework unnecessarily complex switching stuff based on input, frame accurate access is for example important capturing frames :(
clsid
23rd November 2008, 22:14
It is still unfinished code so issues are to be expected.
BatKnight
23rd November 2008, 23:53
There is:
Disable the MLP decoder (and enable AC3 S/PDIF pass-through).
OK, sorry. My bad.
But something still bugs me. When playing the "TrueHD 7.1ch 96KHz.m2ts" file with MLP disabled and AC3 pass-through enabled it states the following:
Input: 48000Hz, 6 channels 640 kbps ac3 (liba52).
My question is: why is it stripping only 6 channels, if the file is 7.1 and with MLP decoding it says 8 channels?
Thanks
Bat
Snowknight26
24th November 2008, 00:36
The AC3 'core' is only 5.1.
haruhiko_yamagata
24th November 2008, 02:27
@xxl, haruhiko,
I have installed VS2008SP1. Static linking seems to work ok. I am uploading a build to sf.net now so everyone can test. It also includes Haruhiko's recent safe string patch.
Once all vs2008 project files have been updated for static mfc linking, we could completely switch to supporting just vs2008. I think we are then all using vs2008? If so, all vs2003/2005 project files can be removed.OK, we are working on it.
By the way, what setting did you use to pack the installer? May be you have forced "VS2003SP1" which should be correct for now.
Could you update the installer for static link?
Perhaps we can omit packing msvcr71.dll.
Snowknight26
24th November 2008, 08:09
When installing ffdshow, the shortcut for the VFW config doesn't work because apparently there is no entry point named configureVFW.
haruhiko_yamagata
24th November 2008, 08:21
When installing ffdshow, the shortcut for the VFW config doesn't work because apparently there is no entry point named configureVFW.It works for me. Did you check "VFW interface" on installation? Which build are you using?
Snowknight26
24th November 2008, 08:38
Yes I did. Tried albian's latest build (ffdshow_rev2340_20081121_dbt.exe) and an earlier one from xvidvideo.ru.
Probably irrelevant, but it works on my Vista x64 box, but not on my Server 03 x64 one.
haruhiko_yamagata
24th November 2008, 08:46
Yes I did. Tried albian's latest build (ffdshow_rev2340_20081121_dbt.exe) and an earlier one from xvidvideo.ru.
Probably irrelevant, but it works on my Vista x64 box, but not on my Server 03 x64 one.Well, I don't have Server 03 x64.
Probably it's a bug of Server 2003. It is likely that it has problem in loading msvcr90.dll for a dll installed in the system32 directory.
Please let us know if it works after we have finished static link stuff.
clsid
24th November 2008, 11:52
The builds from xvidvideo.ru might have the runtime detection disabled. That means that the installer won't prompt you if you haven't got the required runtimes installed. But that would also mean that ffdshow audio/video won't work either. Static linking is going to solve the entire runtime issue, as those won;t be required anymore.
@Haruhiko,
I will update the install script once all project files are updated. I will do that later this week. I think that the manifest files (those runtime assembly related ones) are also no longer needed. So things will clean up nicely.
According to xxl, only the ffavisynth plugin won't link statically. Perhaps you could take a look at that one if you have some time.
haruhiko_yamagata
24th November 2008, 12:20
Thanks. I've sent a PM to xxl.
alexins
24th November 2008, 12:47
The builds from xvidvideo.ru might have the runtime detection disabled.
In my assemblings always runtime detection in the position enabled (#define VS2008SP1 = True)
haruhiko_yamagata
24th November 2008, 13:04
Thanks, but does the runtime detection work on 2003 server?
Anyway, we will move to static link, it will solve the CRT problem if it works.
cca
24th November 2008, 14:26
I would like to test the ffdshow-MT, but no build from xvidvideo.ru works, the audio part seems to load, but the video part of ffdshow cannot connect with the splitter. Normal ffdshow worked and works as intended. What am I missing?
haruhiko_yamagata
24th November 2008, 14:42
I would like to test the ffdshow-MT, but no build from xvidvideo.ru works, the audio part seems to load, but the video part of ffdshow cannot connect with the splitter. Normal ffdshow worked and works as intended. What am I missing?Which splitter is used?
Is the video H.264?
albain
24th November 2008, 14:49
OK, sorry. My bad.
But something still bugs me. When playing the "TrueHD 7.1ch 96KHz.m2ts" file with MLP disabled and AC3 pass-through enabled it states the following:
Input: 48000Hz, 6 channels 640 kbps ac3 (liba52).
My question is: why is it stripping only 6 channels, if the file is 7.1 and with MLP decoding it says 8 channels?
Thanks
Bat
If you send the AC3 core directly to SPDIF it will surely be better quality than decoding MLP and reencoding it to AC3.
However, if you decode MLP and sending the (raw) stream directly to your speakers, it will have the best quality.
albain
24th November 2008, 14:54
Just a thought, I don't know how complicated it is :
if ffmpeg team doesn't plan to merge ffmpeg-mt into their main trunk soon, why not creating a separate dll (ie libavcodec-mt.dll) next to libavcodec.dll and load from it only the MT decoders (h264 for now) ?
Then FFDShow should have the ability to load one or the other depending on the input format.
albain
24th November 2008, 14:55
OK, sorry. My bad.
But something still bugs me. When playing the "TrueHD 7.1ch 96KHz.m2ts" file with MLP disabled and AC3 pass-through enabled it states the following:
Input: 48000Hz, 6 channels 640 kbps ac3 (liba52).
My question is: why is it stripping only 6 channels, if the file is 7.1 and with MLP decoding it says 8 channels?
Thanks
Bat
If you send the AC3 core directly to SPDIF it will surely be better quality than decoding MLP and reencoding it to AC3.
Like said before, AC3 is limited in channels (5+1) and in bitrate.
MLP has more channels and higher bitrate, so better quality.
So if you decode MLP and send the (raw) stream directly to your speakers, it will have the best quality.
cca
24th November 2008, 15:04
Which splitter is used?
Is the video H.264?
Both XviD and H264. So it is the standard AVI splitter for XviD and Haali splitter for H264. None work with ffdshow-MT, but work with no problem with normal ffshow. I already have installed the VS 2005 and 2008 redist packages. Does ffshow-MT require any other runtimes?
EDIT: It seems the problem is libavcodec itself. DVD playback using libmpeg2 and XVID playback with xvidcore.dll works. Anything that uses libavcodec just doesn't work. Also, in version details there is nothing displayed for libavcodec.dll, while version numbers are displayed for the rest of the libraries. Either it is not correctly compiled, or some dependecy is missing.
Reino
24th November 2008, 15:30
I'm using rev.2322 (13NOV2008) and I'm having some problems with ASS-subtitles. I believe this due to rev.2270.
Revision 2270 (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2270) - Directory Listing (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/?pathrev=2270)
Modified Fri Oct 31 09:52:42 2008 UTC (3 weeks, 3 days ago) by albain
Improvements of SSA subtitles : collisions, position, move, layers
Added a new dialog box for overriding some SSA settings
Around a month ago I made a tutorial movie (ASS subtitle encoded on top of the video stream!)
Rendered with FFDShow rev.2322: (no settings were enabled under the "ASS/SSA config"-button)
http://img253.imageshack.us/img253/9398/ffdshowrev2322asssubtitpe5.th.png (http://img253.imageshack.us/img253/9398/ffdshowrev2322asssubtitpe5.png)
Rendered with FFDShow rev.2054: (older version on my laptop)
http://img117.imageshack.us/img117/5931/ffdshowrev2054asssubtitro1.th.png (http://img117.imageshack.us/img117/5931/ffdshowrev2054asssubtitro1.png)
The actual subtitle line in the ass-file:
Dialogue: 0,0:02:48.48,0:02:55.52,Default,,0000,0000,0000,,{\pos(320,453)}You can find Avisynth
at {\c&H00FFFF&}http://avisynth.org{\c} and\Nclick the download-link in the upper left corner.
As you can see, the only break ("\N") comes after "and".
I haven't changed any settings compared to the older revision, so I'm wondering why FFDShow shows this behaviour.
Can this be fixed?
haruhiko_yamagata
24th November 2008, 15:32
Just a thought, I don't know how complicated it is :
if ffmpeg team doesn't plan to merge ffmpeg-mt into their main trunk soon, why not creating a separate dll (ie libavcodec-mt.dll) next to libavcodec.dll and load from it only the MT decoders (h264 for now) ?
Then FFDShow should have the ability to load one or the other depending on the input format.
If ffmpeg-mt is finished and ffmpeg still does not merge it, it will be the choice.
I think it's not time for it at this moment.
haruhiko_yamagata
24th November 2008, 15:39
Both XviD and H264. So it is the standard AVI splitter for XviD and Haali splitter for H264. None work with ffdshow-MT, but work with no problem with normal ffshow. I already have installed the VS 2005 and 2008 redist packages. Does ffshow-MT require any other runtimes?
EDIT: It seems the problem is libavcodec itself. DVD playback using libmpeg2 and XVID playback with xvidcore.dll works. Anything that uses libavcodec just doesn't work. Also, in version details there is nothing displayed for libavcodec.dll, while version numbers are displayed for the rest of the libraries. Either it is not correctly compiled, or some dependecy is missing.
pthreadGC2.dll. Where is it in your hard drive?
Are you using Vista x64?
cca
24th November 2008, 15:50
pthreadGC2.dll. Where is it in your hard drive?
Are you using Vista x64?
I do not seem to have such a file. I do use Vista x64, but I use x86 player and ffdshow.
EDIT: Thanks to haruhiko-san I found pthreadGC2.dll from ftp://sourceware.org/pub/pthreads-win32/dll-latest/lib/ and move it to C:\Windows\SysWOW64. Now finally ffdshow-MT works! This file should be included with the setup, or at least some link to obtain it.
alexins
24th November 2008, 16:16
I do not seem to have such a file. I do use Vista x64, but I use x86 player and ffdshow.
EDIT: Thanks to haruhiko-san I found pthreadGC2.dll from ftp://sourceware.org/pub/pthreads-win32/dll-latest/lib/ and move it to C:\Windows\SysWOW64. Now finally ffdshow-MT works! This file should be included with the setup, or at least some link to obtain it.
The file of pthreadGC2.dll automatically is added during the installation of ffdshow-mt.
haruhiko_yamagata
24th November 2008, 16:18
I do not seem to have such a file. I do use Vista x64, but I use x86 player and ffdshow.
EDIT: Thanks to haruhiko-san I found pthreadGC2.dll from ftp://sourceware.org/pub/pthreads-win32/dll-latest/lib/ and move it to C:\Windows\SysWOW64. Now finally ffdshow-MT works! This file should be included with the setup, or at least some link to obtain it.OK, I have fixed the installer.
_xxl
24th November 2008, 16:20
Isn't possible to get rid of pthreadGC2.dll ?
cca
24th November 2008, 16:37
The file of pthreadGC2.dll automatically is added during the installation of ffdshow-mt.
Unfortunately, it is not. Perhaps something related to Vista 64? Anyway, haruhiko-san says he fixed the installer, we should know with the next build.
Edit: from the changelog: "ffmpeg-mt branch: update installer If vfw was not checked, pthreadGC2.dll was not installed."
Indeed, I never check this box, I do not need vfw functionality, and it triggered the problem!
haruhiko_yamagata
24th November 2008, 16:49
Isn't possible to get rid of pthreadGC2.dll ?
Porting pthread.c to Win32 API would take a week or more.
Snowknight26
24th November 2008, 17:15
Thanks, but does the runtime detection work on 2003 server?
Yes it does. I was prompted to install a C++ redistributable the first time I tried to install ffdshow from xvidvideo.ru after a fresh install of Server 2003.
clsid
24th November 2008, 17:55
I am having trouble getting static linking to work properly with the VS2008 ICL project files :(
Are VS2008 builds compatible with win9x?
_xxl
24th November 2008, 18:21
Are VS2008 builds compatible with win9x?
Win98 shouldn't be supported anymore.
Px
24th November 2008, 19:03
I am having trouble getting static linking to work properly with the VS2008 ICL project files :(
Are VS2008 builds compatible with win9x?
No, for Win98 support use VS2005 or VS2003
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.