View Full Version : ffdshow tryouts project: Discussion & Development
Amdh
30th November 2007, 11:53
Yei Friend It's H.264 In An AVI Container, I Usualy Use CoreAVC To Decode It And It's Working Well Since Ever, However I Just Tried To Use Ffdshow Decoder And I Discovered That He's Decoding It As YV12 ..
clsid
30th November 2007, 12:25
You can configure the output colorspace in ffdshow options.
haruhiko_yamagata
30th November 2007, 12:44
Yei Friend It's H.264 In An AVI Container, I Usualy Use CoreAVC To Decode It And It's Working Well Since Ever, However I Just Tried To Use Ffdshow Decoder And I Discovered That He's Decoding It As YV12 ..H.264 (http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC) encode RGB32? It's impossible.
Amdh
30th November 2007, 13:32
Impossible .. Why Friend ? I'm Doing That Since 2 Years, It's Working Well As For The Encoding And Decoding, I'm Even Encoding In RGB32 With Ffdshow H264 Encoder .. When Decoding With CoreAVC Pro The Decoder Shows That He's Decoding In RGB32. So Am I Doing Something Wrong .. ? If Yes Please Tell Me How To Correct That .. ?
max-pain
30th November 2007, 14:14
Any chance for a newer 64 bit build?
clsid
30th November 2007, 14:34
Impossible .. Why Friend ? I'm Doing That Since 2 Years, It's Working Well As For The Encoding And Decoding, I'm Even Encoding In RGB32 With Ffdshow H264 Encoder .. When Decoding With CoreAVC Pro The Decoder Shows That He's Decoding In RGB32. So Am I Doing Something Wrong .. ? If Yes Please Tell Me How To Correct That .. ?
Encoding into RGB32 is impossible for H.264. But I think what you mean is encoding RGB32 into H.264 format and decoding H.264 to RGB32.
Like I said before, go to ffdshow video decoder configuration, on the output page uncheck all colorspaces except for RGB32. Then ffdshow will output RGB32.
Leak
30th November 2007, 14:39
So Am I Doing Something Wrong .. ?
Well, for one screenshots of the right and wrong decoding results would be nice, as well as a small sample... :)
Amdh
30th November 2007, 15:05
Thanks For The Info Friends .. I've Tried That Decoding Tip And It Worked Well .. Ffdshow Was Able To Decode RGB32 Corectly, Anyway, If It's Impossible To Encode RGB32 In H264 Then I Was Surely Doing Something Wrong, Gonna Try Some Other Color Spaces, Any Suggestions About That ?
St Devious
30th November 2007, 16:55
is it possible to automate 2-pass encoding in ffdshow vfw with xvid and H.264 codecs , or does it have to be done manually ( first running the first pass , then the second ) ?
Help !!
clsid
30th November 2007, 17:06
Thanks For The Info Friends .. I've Tried That Decoding Tip And It Worked Well .. Ffdshow Was Able To Decode RGB32 Corectly, Anyway, If It's Impossible To Encode RGB32 In H264 Then I Was Surely Doing Something Wrong, Gonna Try Some Other Color Spaces, Any Suggestions About That ?
You are understanding it wrong. The H.264 format has NOTHING to do with colorspaces.
And please stop using annoying fonts.
LoRd_MuldeR
30th November 2007, 17:16
is it possible to automate 2-pass encoding in ffdshow vfw with xvid and H.264 codecs , or does it have to be done manually ( first running the first pass , then the second ) ?
I think this can not be automated, due to limitations in VFW itself. As far as I know, the VFW interface does not support 2-Pass encoding at all! In fact the 2-Pass encoding with all VFW Codecs I'm aware of is simply "emulated" with 2 separate encodes of the same video. Of course the VFW Codec has to be reconfigured between the two encodes, because it needs to know which run is the first and which run is the second pass. But from the point of view of the VFW interface (or the host application) those are still two independent encodes. You might want to give Avidemux a try, which does not use VFW Codecs and is able to automate 2-Pass encoding with both, x264 and Xvid:
http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux
St Devious
30th November 2007, 18:56
You might want to give Avidemux a try, which does not use VFW Codecs and is able to automate 2-Pass encoding with both, x264 and Xvid:
http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux
i already use avidemux , i wanted to render files in vegas so i asked the q .
Taurus
30th November 2007, 18:59
Thank you very much.
This sample (http://www.matroska.org/samples/mewmew/index.html) would help testing subtitles. It has UTF-8 SSA subtitles, which may be a bit difficult task for Win98.
No chance on win98
The letters are burked and language subs are missing
http://img119.imageshack.us/img119/1783/snapshotwk2.th.jpg (http://img119.imageshack.us/my.php?image=snapshotwk2.jpg)
clsid
30th November 2007, 19:27
That is to be expected since Win9x does not support unicode. Most important thing is that it doesn't crash.
Amdh
30th November 2007, 22:18
OK .. I've understood the thing .. thanks !
Taurus
30th November 2007, 23:43
That is to be expected since Win9x does not support unicode. Most important thing is that it doesn't crash.
Yeah, real stable OS :D
Running in the same Rig since 1998.
haruhiko_yamagata
1st December 2007, 01:37
No chance on win98
The letters are burked and language subs are missing
http://img119.imageshack.us/img119/1783/snapshotwk2.th.jpg (http://img119.imageshack.us/my.php?image=snapshotwk2.jpg)Thank you. Then we can anounce that beta4 does not support subtitles in Win9x.
I may try to fix the problem for beta4a or later if I have time.
Inventive Software
1st December 2007, 03:25
Hold it right there... Win98 has a unicode DLL that can be downloaded IIRC.... is there still a chance that it can still be supported?
haruhiko_yamagata
1st December 2007, 05:56
Hold it right there... Win98 has a unicode DLL that can be downloaded IIRC.... is there still a chance that it can still be supported?hmm... It may work. ffdshow may have to detect the dll and treat Win98 as Unicode OS.
Liisachan
1st December 2007, 06:26
You guys might want to use another clip to test Unicode SSA subs on Win98 if you test it at all. The reason is, mewmew vorbis has the Encoding parameter 0 for all subs. For instance, the Russian has:
Style: Ichigo,Verdana,32,...30,30,15,0,0
The last '0' is supposed to be lfCharSet, and if it is 204 (RUSSIAN_CHARSET), Win98 may like it more. That's how it was when I tested it long ago (in 2003), on Win98 with vsfilter. I couldn't re-test it to confirm it, as I don't have win98 anymore (or do I... somewhere...) Back then, I thought that last 0 (or \fe) was just a place holder for a Unicode SSA, since the file is in Unicode and CharSet is irrelevant (Haali said the same thing too, Mosu a Linux uers even said he didn't understand the meaning of \fe at all and he's right, charset is Window specific), but apparently it may be useful for VSFilter. (Gabest's ass-specs.doc has it about that param "When the file is Unicode, this field is useful during file format conversions." btw). ffdshow may be totally different than vsfilter so this might not be the problem, but when I tested it, mewmew vorbis + win98 + vsfilter (or mpc) worked more or less iff I changed that CharSet param 0 to an appropriate value.
SSA should have 204 as that parameter if it is in Russian, or 134 if it's in simplified chinese, etc etc. That is basically so even now that SSA/ASS is in Unicode. For instance, even in Unicode, even on Windows XP, Simp Chinese SSA doesn't work correctly without that magic number 134 (or actually 1, DEFAULT_CHARSET will do too) w/ VSFilter/MPC. (Subs may be readable but CreateFont fails and so not styled) Yet, mewmew vorsbis has every Encoding parameter 0.
So, altho ffdshow's algo might be totally different, I'd say mewmew vorbis may not be a good clip for testing in this case.
Also note that even on Windows XP, some languages are not displayed correctly unless you have East Asian Language support installed, or complicated text support like RtoL.
Here's another test clip (http://ffdshow.faireal.net/tmp/test-vorbis-ass.mkv) that has proper Encoding parameters in ASS. Win98 might like it better (tho I'm quite skeptical anyway~)
haruhiko_yamagata
1st December 2007, 11:15
Liisachan, thank you for the info.
I've installed Virtual PC 2007, Windos 98 work on it :).
Thank you, Taurus, I can reproduce the problem.
I've changed the source code of ffdshow to use Microsoft Layer for Unicode on Windows 98. It's better now, still crashes though.
I'm learning how to use remote debugger. It's quite :confused:.
Taurus
1st December 2007, 11:48
Hold it right there... Win98 has a unicode DLL that can be downloaded IIRC.... is there still a chance that it can still be supported?
hmm... It may work. ffdshow may have to detect the dll and treat Win98 as Unicode OS.
Thats what I have tried at first attempt.
Unicode assistance for Win98 is installed on this machine for a long time.
http://www.microsoft.com/downloads/details.aspx?FamilyId=73BA7BD7-ed06-4F0D-80A4-2A7EEAEE17E2&displaylang=en
@haruhiko_yamagata
You're faster...
If you want me to test another build...
Count on me
haruhiko_yamagata
1st December 2007, 11:58
Thats what I have tried at first attempt.
Unicode assistance for Win98 is installed on this machine for a long time.
http://www.microsoft.com/downloads/details.aspx?FamilyId=73BA7BD7-ed06-4F0D-80A4-2A7EEAEE17E2&displaylang=en
Layer for Unicode is used only if calling program (ffdshow) is build to use it.
Taurus
1st December 2007, 12:20
Layer for Unicode is used only if calling program (ffdshow) is build to use it.
I know ;)
Here is another pic from the clip Liisachan provided.
http://img70.imageshack.us/img70/716/snapshot2vl9.th.jpg (http://img70.imageshack.us/my.php?image=snapshot2vl9.jpg)
sillKotscha
1st December 2007, 16:58
just a question about "good old" mov format again ;)
I have found some mov videos - they can be found/ downloaded here (http://download.neilpryde.com/2002/video/stone_videos/) - which ffdshow fails to play... sound and video
is it a ffdshow issue or a splitter issue??
Quicktime Player plays them just fine...
EDIT: sorry, found the problem... it is the internal mp4/mov source filter of MPC - disable it and the files play just fine... I can see that the quicktime movie parser is used instead...
EDIT II: who's working/ developing the mp4/mov source filter... I'd like to ask for a possible fix - as those files a the only files I have not working with this splitter...
clsid
1st December 2007, 18:05
The filter is open source. But there currently is nobody who is working on it. You could ask Casimir666 if he can take a look at your samples.
sillKotscha
1st December 2007, 18:20
thx for your answer
Inventive Software
2nd December 2007, 01:34
Can somebody confirm that interlaced H.264 decoding is broken? I've uploaded a sample here: http://rapidshare.com/files/73670684/Interlaced_test.mkv. It's an x264 encode with --interlaced and --crf 20. That's it. Basically, the decoder gives a grey garbled image. I've made it mod-32 in height and width, but that hasn't done anything. I don't have another H.264 decoder to test it with so I can't determine if it's the encoder or decoder that's the problem. :(
EDIT: I've tested with ffplay on Windows, and it's ffdshow that's not decoding correctly. ffplay has no trouble, so something's missing in the libavcodec H.264 decoder you guys have.
EDIT 2: My bad. Was using rev 1620, updated to rev 1656, and that seems to have fixed it. I gotta concentrate more! :D
Harukalover
2nd December 2007, 03:16
Some bugs I've encountered in latest build of ffdshow tryouts. (ffdshow_prebeta4_rev1656_20071029_clsid.exe was the one tested) All of them dealing with lossless audio.
First is a flac issue. In the particular sample it skips all the way to the end of the file as soon as it hits around 4 seconds in. Here it is for testing:
http://dnous.nekonation.org/Harukalover/flac_skip.mkv
This doesn't happen if I use CoreFLAC to decode instead of libavcodec in ffdshow.
Second issue involves tta audio.
http://www.cccp-project.net/beta/test_files/[CCCP]_Mega_Lossless_Audio_Test.mkv
Download that and switch to the 2ch tta track. You'll notice if using libavcodec to decode it. That there is a large desync of audio. You can definitely notice this at 00:28 in where the crowd comes in really late.
After that switch to the 6ch tta track. You should notice a mix of speedup/slowdown of the video. Especially at 00:12 in which it will just stall the video for a bit.
Both of those tta issues are gone when using the official tta decoder from True Audio's website instead of libavcodec.
haruhiko_yamagata
2nd December 2007, 12:34
@Harukalover
Thank you for report. I can reproduce both of the problems.
haruhiko_yamagata
2nd December 2007, 14:09
I know ;)
Here is another pic from the clip Liisachan provided.
http://img70.imageshack.us/img70/716/snapshot2vl9.th.jpg (http://img70.imageshack.us/my.php?image=snapshot2vl9.jpg)OK, now I've fixed the word wrapping issue and crash issue. I've updated the installer to install unicows.dll on Windows 9x. I'll commit when ready.
getTextExtentExPointW seems to be buggy on Layer for Unicode. It requires 2 * strlen instead of strlen for alpDx array size.
Nevertheless, Layer for Unicode is useful. I think we don't have to drop Windows 9x support for a while.
Taurus
2nd December 2007, 18:22
I think we don't have to drop Windows 9x support for a while.
Thanks!:D
Thunderbolt8
3rd December 2007, 01:01
Can somebody confirm that interlaced H.264 decoding is broken? I've uploaded a sample here: http://rapidshare.com/files/73670684/Interlaced_test.mkv. It's an x264 encode with --interlaced and --crf 20. That's it. Basically, the decoder gives a grey garbled image. I've made it mod-32 in height and width, but that hasn't done anything. I don't have another H.264 decoder to test it with so I can't determine if it's the encoder or decoder that's the problem. :(
EDIT: I've tested with ffplay on Windows, and it's ffdshow that's not decoding correctly. ffplay has no trouble, so something's missing in the libavcodec H.264 decoder you guys have.
EDIT 2: My bad. Was using rev 1620, updated to rev 1656, and that seems to have fixed it. I gotta concentrate more! :D
afaik galapagos HD DVD VC-1 interlaced at 29.97 is still not playable with ffdshow, no picture.
Inventive Software
3rd December 2007, 02:50
I have tested with WMV9 AP, encoded as interlaced, decoded with libavcodec, and that was fine...
vlada
3rd December 2007, 07:41
Try this sample: http://www.megaupload.com/de/?d=7QIPXP6I or http://www.sendspace.com/file/lvlvtv.
demoniccannon
3rd December 2007, 11:15
helloooooooooooo guys, i finally managed to register an account here because i have a few bugs and suggestions to say.
1. h.264 lossless encoding simply doesn't work. whenever i encode with it in virtualdub, it pops "cannot start video compression: an unknown error occurred(error code -100)". but i remember an older version of ffdshow worked, which turned out to be beta2.
2. newer versions of ffdshow crash with certain .ass subtitles, usually when displaying several lines at different positions, for example on line at the top and the other at the bottom simultaneously. older versions such as beta3 don't crash, but display subtitles at wrong positions instead. well i see you claimed ass/ssa support experimental so i have to live with it, but i hope you would keep working on it.
3. what about adding support to 2pass/3pass h.264 encoding? since it's supported by x264.
4. who are the guys working on libavcodec? can decoding speed be even further improved? although it's pretty fast compared to other codecs, it still stretches my poor old computer out.
5. i hear you are going drop support for win9x, that's a sad news because many people still keep their ancient computers and win98 as a backup platform to run certain old games and applications, and there will be no effective codecs to play various media types on those computers. so if you plan to do that, i hope there would least be a relatively complete and stable final release for win98 before that.
last, dispite a few flaws, ffdshow is still my favorite codec so keep on good work!
and btw the ffdshow forum sux. i have tried to register at least 3 accounts using different mail addresses, but none of them received the "activation mail"!
haruhiko_yamagata
3rd December 2007, 11:50
2. newer versions of ffdshow crash with certain .ass subtitles, usually when displaying several lines at different positions, for example on line at the top and the other at the bottom simultaneously. older versions such as beta3 don't crash, but display subtitles at wrong positions instead. well i see you claimed ass/ssa support experimental so i have to live with it, but i hope you would keep working on it.Thank you for testing and report. Could you send me a sample? As far as I know, it works.
5. i hear you are going drop support for win9x, that's a sad news because many people still keep their ancient computers and win98 as a backup platform to run certain old games and applications, and there will be no effective codecs to play various media types on those computers. so if you plan to do that, i hope there would least be a relatively complete and stable final release for win98 before that.I'm working on it.
Inventive Software
4th December 2007, 06:15
I got a suggestion for the SVN changelog... when you put "updated libavcodec", maybe a note to say what ffmpeg SVN version you used would be good so we can track changes more. "updated libavcodec" just seems too general in a way. :)
vio_man
5th December 2007, 00:02
I've seen this decoder test (I know this is not 0-day news) and I would like to know if the ffdshow's decoding speed has been improved since this test?
demoniccannon
5th December 2007, 02:30
Thank you for testing and report. Could you send me a sample? As far as I know, it works.
hello haruhiko_yamagata, i m sorry i can't send you the crashing sample because it's 300mb large to send, also it's mkv encapsulation so it's difficult to cut the crashing part and keep the crashing ass in sync time.
btw: the sample never crashed with subtitles turned off, so i m sure it's caused by ass handling.
haruhiko_yamagata
5th December 2007, 09:15
hello haruhiko_yamagata, i m sorry i can't send you the crashing sample because it's 300mb large to send, also it's mkv encapsulation so it's difficult to cut the crashing part and keep the crashing ass in sync time.
btw: the sample never crashed with subtitles turned off, so i m sure it's caused by ass handling.
I don't need the video and audio tracks of the file. Please extract the subtitle track.
Download and install mkvtoolnix (http://www.bunkus.org/videotools/mkvtoolnix/).
Launch cmd.exe and goto the directory where the file exists.
Type "mkvmerge -i filename.mkv" to get the track number of the subtitle.
Type "mkvextract tracks filename.mkv 3:ass_crash.ass", if the track number of the subtitle is 3.
Please send me ass_crash.ass and tell me dimension of the video and where it chrashes.
albain
5th December 2007, 11:31
I have posted an updated build of FFDShow 64 bit to sourceforge.
Can someone tell me if it is working ?
Thanks
Damien BT
Px
5th December 2007, 23:43
I have posted an updated build of FFDShow 64 bit to sourceforge.
Can someone tell me if it is working ?
Thanks
Damien BT
Check in Vdub x64 and MPC-HC x64 under WinXP x64 on variety of files (DivX, Xvid, Mpeg2, H.264, both SD and HD up to 1080p), works fine :)
albain
6th December 2007, 09:20
Check in Vdub x64 and MPC-HC x64 under WinXP x64 on variety of files (DivX, Xvid, Mpeg2, H.264, both SD and HD up to 1080p), works fine :)
OK thanks !
PatchWorKs
6th December 2007, 11:23
Check in Vdub x64 and MPC-HC x64 under WinXP x64 on variety of files (DivX, Xvid, Mpeg2, H.264, both SD and HD up to 1080p), works fine :)
+1 (Win x64/MPC-HC & DV files)
clsid
6th December 2007, 20:05
Beta 4 has officially been released. :D
fastplayer
6th December 2007, 20:35
Beta 4 has officially been released. :D
Great! :cool:
I'll update the links and changelog ASAP.
Delerue
6th December 2007, 20:57
Beta 4 has officially been released. :D
Weird... This video here (http://www.zshare.net/download/440879281feed3/) uses dual-thread when decoded by 1681 xxl build, but it uses only one if decoded by your beta 4 1685 build. Any idea?
clsid
6th December 2007, 21:11
That is because the EXPERIMENTAL multithreading patch for H.264 decoding has NOT yet been applied to the official ffdshow code. Please read the opening post of this topic before you start asking when that will happen.
Delerue
6th December 2007, 21:24
That is because the EXPERIMENTAL multithreading patch for H.264 decoding has NOT yet been applied to the official ffdshow code. Please read the opening post of this topic before you start asking when that will happen.
Hmmmm... I'm not asking for a 'when'. I only thought that is weird that an earlier build doesn't have something that an old build has. Sorry, man.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.