View Full Version : ffdshow tryouts project: Discussion & Development
multiblitz
6th December 2007, 23:42
I found the flag. Haali's media splitter is working perfectly.
Damn, I did check the AM_SAMPLE2_PROPERTIES::dwTypeSpecificFlags of the first and second frames, but didn't check the third...
I've modified the code a bit to set time stamp properly. Now the sync is OK, but it still has two problems. One is interlacing related flags to send to downstream, one is jerkiness caused by unloading and loading dlls during playback. Second problem is caused because ffdshow receives samples with media type attached and then re-initialize codec drivers.
The fix will surely break the code too much that I can't do without adding bugs. I'm going to do it after beta4. Please wait.
Now that Beta 4 is out: PLEEEEEAAAASE, Please give us the possibilty to playback HD-DVD with ffdshow...to het the ultimate home-cinema experience....THX a lot
Inventive Software
7th December 2007, 00:32
We're waiting on menu support for that miracle to happen, and a *proper* E-AC3 decoding patch, along with TrueHD and DTS-HD decoders. All of these are quite a long way off. E-AC3 is preliminarily a dodgy patch in ffmpeg, TrueHD requires the actual decoder, DTS-HD hasn't been reverse-engineered yet.
Inventive Software
7th December 2007, 03:26
My digital camera videos with FourCC SP54 are unable to be decoded by ffdshow, where they were a couple of years ago. It's the Sunplus MJPEG codec, and they used various FourCCs for different cameras. The only one I could spot that was similar was SP5X. Any chance of SP54 being added to the list? If memory serves correctly, FourCCs SP51, SP55, SP56 and SP57 were also used...
Liisachan
7th December 2007, 06:20
Hi,
Is this a known limitation or am I doing something wrong?
- Xvid and DivX with b-frames get decoder delay when decoded by ffdshow VFW 'libavcodec' but not by 'Xvid'.
If it's a known limitation, I'd prefer that ffdshow VFW uses 'Xvid' by default for Xvid/DivX. Or if it's fixable that'd be the best of course.
- Phenomenon: If Xvid or DivX video in AVI with b-frames is decoded by ffdshow 'libavcodec' via VfW (e.g. on VirtualDub),
the results get some kind of decoder delay:
* Frame 0 is first displayed as null (empty black) even if it is not originally empty black.
* Seeking via keyframes doesn't work correctly. VirtualDub apparently knows the correct frame number
for keyframes, but not getting the correct image at that frame number in presentation order. Apparently 1 (or 2) off.
* The results of seeking around the keyframe is different depending on whether you're seeking forward or seeking back.
This happened when I happened to uninstall Xvid/DivX and ffdshow was the only decoder avilable.
- If 'Xvid' is selected in the ffdshow VfW conf, the pb is gone.
Also, there is no such pb if Xvid or DivX codecs are used to decode it instead of ffdshow.
- ffdshow 'libavcodec' via DirectShow seems okay too.
- Tested both ffdshow beta 3 and 4.
Thanks for any suggestions :)
JarrettH
7th December 2007, 08:18
Congrats on beta 4 you guys :cool:
Yong
7th December 2007, 12:11
ffdshow OSD screw up when playback this mjpeg video
http://y0ngc6.googlepages.com/DungeonSiegeIITrailer2.7z
btw thanks, ffdshow is getting better and better now, i think we are close to 1.0 :D
clsid
7th December 2007, 13:06
My digital camera videos with FourCC SP54 are unable to be decoded by ffdshow, where they were a couple of years ago. It's the Sunplus MJPEG codec, and they used various FourCCs for different cameras. The only one I could spot that was similar was SP5X. Any chance of SP54 being added to the list? If memory serves correctly, FourCCs SP51, SP55, SP56 and SP57 were also used...
Can you upload a sample file? I prefer to test playback when I add new FourCCs.
multiblitz
7th December 2007, 13:39
We're waiting on menu support for that miracle to happen, and a *proper* E-AC3 decoding patch, along with TrueHD and DTS-HD decoders. All of these are quite a long way off. E-AC3 is preliminarily a dodgy patch in ffmpeg, TrueHD requires the actual decoder, DTS-HD hasn't been reverse-engineered yet.
Well, let's start small: Simply by getting rid of the 24/30 fps bug, which does not allow to have ffdshow in dthe filer-chain for video. For Audio, the sonic codecs work OK for the moment.
The topic becomes obviously hotter now as cyberlink has erase the option to playback HD-DVD from harddisk in PDVD ultra. So, many people are looking now for alternatives. I personally found that a hood sharpening and noise-reduction is still important with HD-stuff...plus: PDVD in XP only works with overlay, not VMR9. So a good quality video-chain with ffdshow in would help a lot and later than aiudio and we have perfection...
Blkbird
7th December 2007, 15:30
The "Subtitles > Letterbox" option of the video decoder erroneously applies cropping instead of letterboxing if the specified AR is wider than the AR of the given video.
For example, if the letterbox AR is set to 8:5 (which is the common AR for most widescreen monitors nowadays), then a 16:9 video gets properly letterboxed top and bottom, however a 4:3 video isn't correctly letterboxed left and right, but instead gets cropped top and bottom. Since this happens both with Zoom Player and Media Player Classic, I'm pretty sure it's a problem with ffdshow and not with the player software.
I discovered this bug after recently (and finally) dumping my old CRT monitor and replacing it with a LCD one. I'm very surprise to find - through searching in this forum - that this bug has actually been reported year ago, but still isn't fixed yet. I would have thought a lot of users are affected by the bug, and I believe it shouldn't even be difficult to fix.
Also, while we at it, could someone please add an option to have vertical letterboxing - i. e. top and bottom, if the video is wider than the screen - applied asymmetrically? I assume most people choose to have their subtitle displayed on the bottom, and by having the letterboxing applied only to the bottom, there will be more empty space for the subtitle, so it remains more reliably off the video.
haruhiko_yamagata
7th December 2007, 16:13
Hi,
Is this a known limitation or am I doing something wrong?
- Xvid and DivX with b-frames get decoder delay when decoded by ffdshow VFW 'libavcodec' but not by 'Xvid'.
If it's a known limitation, I'd prefer that ffdshow VFW uses 'Xvid' by default for Xvid/DivX. Or if it's fixable that'd be the best of course.
Thank you. I can reproduce. I saw the black screen many times, I wasn't careful enough to find a bug.
haruhiko_yamagata
7th December 2007, 16:21
ffdshow OSD screw up when playback this mjpeg video
http://y0ngc6.googlepages.com/DungeonSiegeIITrailer2.7z
btw thanks, ffdshow is getting better and better now, i think we are close to 1.0 :DThank you. Confirmed.
Inventive Software
7th December 2007, 18:03
Can you upload a sample file? I prefer to test playback when I add new FourCCs.
Ask and ye shall receive... within reason! ;)
http://rapidshare.com/files/74954695/bgp_0041.avi
fastplayer
7th December 2007, 19:58
Can somebody please check out the new "Speed Racer" trailer?
All I get with MPC/beta4 is 100% CPU load and weird noise. VLC plays the trailer without breaking a sweat...
Download (http://pdl.stream.aol.com/aol/us/moviefone/movies/2007/speedracer_028006/speedracer_trlr_01_itjlsfc_720p_dl.mov) [85.3MB, H.264/SOWT]
Liisachan
7th December 2007, 20:01
Thank you. I can reproduce. You're very welcome.
Another thing, for anyone who is in charge of the web pages. The change log here still says "Added before beta1... WavPack (lossless)"...
http://ffdshow-tryout.sourceforge.net/html/en/
...which is misleading and confusing since WavPack support was dropped. Maybe not saying about WavPack at all would be better. Either that or adding a note like "(WavPack support has been temporarily removed due to technical problems)"?
clsid
7th December 2007, 20:02
Ask and ye shall receive... within reason! ;)
http://rapidshare.com/files/74954695/bgp_0041.avi
FourCCs have been added in rev1688 ;)
fastplayer
7th December 2007, 20:08
Either that or adding a note like "(WavPack support has been temporarily removed due to technical problems)"?
If there are no objections, I'll change the docs.
clsid
7th December 2007, 20:16
Can somebody please check out the new "Speed Racer" trailer?
All I get with MPC/beta4 is 100% CPU load and weird noise. VLC plays the trailer without breaking a sweat...
Download (http://pdl.stream.aol.com/aol/us/moviefone/movies/2007/speedracer_028006/speedracer_trlr_01_itjlsfc_720p_dl.mov) [85.3MB, H.264/SOWT]
Sound is ok with Haali's splitter, which detects the audio as PCM.
Noise and high cpu confirmed with Gabest's splitter.
fastplayer
7th December 2007, 20:56
Sound is ok with Haali's splitter, which detects the audio as PCM.
Noise and high cpu confirmed with Gabest's splitter.
Thanks for confirmation.
"Uncompressed audio --> 16bit integer" is the correct configuration for this trailer though, right?
Inventive Software
7th December 2007, 21:26
FourCCs have been added in rev1688 ;)
I owe you a drink at some point. Thanks very much for that! :D
haruhiko_yamagata
8th December 2007, 04:47
If there are no objections, I'll change the docs.
Thank you. Please remove the line.
haruhiko_yamagata
8th December 2007, 08:27
Hi,
Is this a known limitation or am I doing something wrong?
- Xvid and DivX with b-frames get decoder delay when decoded by ffdshow VFW 'libavcodec' but not by 'Xvid'.
If it's a known limitation, I'd prefer that ffdshow VFW uses 'Xvid' by default for Xvid/DivX. Or if it's fixable that'd be the best of course.
Unfortunately it seems to be the spec of libavcodec. The fix would be hard.
@clsid : Could you update the installer so that Xvid is used as VFW decoder (of course if Xvid is packed in the package)?
haruhiko_yamagata
8th December 2007, 08:32
The "Subtitles > Letterbox" option of the video decoder erroneously applies cropping instead of letterboxing if the specified AR is wider than the AR of the given video.
For example, if the letterbox AR is set to 8:5 (which is the common AR for most widescreen monitors nowadays), then a 16:9 video gets properly letterboxed top and bottom, however a 4:3 video isn't correctly letterboxed left and right, but instead gets cropped top and bottom. Since this happens both with Zoom Player and Media Player Classic, I'm pretty sure it's a problem with ffdshow and not with the player software.
I discovered this bug after recently (and finally) dumping my old CRT monitor and replacing it with a LCD one. I'm very surprise to find - through searching in this forum - that this bug has actually been reported year ago, but still isn't fixed yet. I would have thought a lot of users are affected by the bug, and I believe it shouldn't even be difficult to fix.Thank you I can reproduce.
Also, while we at it, could someone please add an option to have vertical letterboxing - i. e. top and bottom, if the video is wider than the screen - applied asymmetrically? I assume most people choose to have their subtitle displayed on the bottom, and by having the letterboxing applied only to the bottom, there will be more empty space for the subtitle, so it remains more reliably off the video.Please use resize and borders for this advanced configuration. "Dividing borders" options have been added for your purpose. It is possible to use those settings for letterboxing. Is it a good idea?
Blkbird
8th December 2007, 10:23
Thank you I can reproduce.
Great! Hope it can be fixed soon.
Please use resize and borders for this advanced configuration. "Dividing borders" options have been added for your purpose. It is possible to use those settings for letterboxing. Is it a good idea?
The way I see it, "Resize & aspect > Borders" sets an unconditional borders - which isn't what I want. I want the letterboxing only to apply if the video AR is not equal to my screen AR. And I want the config to be universal, so I don't have to change it when I watch a different video.
But I think you've indirectly raised a valid point - whether the "Letterbox" option should belong to "Subtitles", or is it logically more consistent to move it somewhere under "Resize".
This is what I'd like to have:
1. The video canvas of the media player should always have the same AR as my screen at all times, letterboxing in case the video has a different AR.
2. Keep the letterboxing to the minimum, meaning do it either horizontally or vertically (or none as all of course, if the video AR is already equal to the screen AR), depending on the AR difference, but never both.
3. In case of vertical letterboxing, apply only to the bottom side and keep the video all the way up.
haruhiko_yamagata
8th December 2007, 11:44
The way I see it, "Resize & aspect > Borders" sets an unconditional bordersNope, this is not correct.
Resize to your screen size and select "Keep original aspect ratio". Check "Process pixel aspect ratio internally". Inside/Outsize borders 0%. Dvide vertical borders to bottom 100% or whatever you like. Goto Reize settings page and select Luma method which is suitable for your CPU power. If your CPU is powerful enough use Bicubic or Lanczos and output in RGB32 for better quality.
In the settings above, borders are added only when necessary.
Yong
8th December 2007, 14:28
uh one more crash, didnt test it carefully :p
same clip:
http://y0ngc6.googlepages.com/DungeonSiegeIITrailer2.7z
ffdshow.ax crash if using ffdshow avisynth filter.
haruhiko_yamagata
8th December 2007, 14:59
Now that Beta 4 is out: PLEEEEEAAAASE, Please give us the possibilty to playback HD-DVD with ffdshow...to het the ultimate home-cinema experience....THX a lotI'm working on it :).
Thunderbolt8
8th December 2007, 18:24
Now that Beta 4 is out: PLEEEEEAAAASE, Please give us the possibilty to playback HD-DVD with ffdshow...to het the ultimate home-cinema experience....THX a lot
same for blu-rays please :thanks:
Liisachan
8th December 2007, 19:37
Unfortunately it seems to be the spec of libavcodec. The fix would be hard.
@clsid : Could you update the installer so that Xvid is used as VFW decoder (of course if Xvid is packed in the package)?
I did some more tests. Not surprisingly, libavcodec has the same problem with other MPEG4 Part2 codecs, such as 3ivx, too. But selecting 'Xvid' doesn't help here and I see no reason to change this one:
Other MPEG4 -- libavcodec
while these appear to be reasonable, fixing the pb.
Xvid -- Xvid
DivX 4/5/6 -- Xvid
The pb doesn't happen as long as you have Xvid and/or DivX installed, when ffdshow is not used in VFW (VirtualDub etc). Those who use VirtualDub are very likely to have Xvid or DivX, so I'd say this problem is not that critical in reality. A hidden glitch that usually doesn't surface, until for some reason you need to do frame-accurate editing of video via ffdshow VfW.
Thanks again anyway~:)
Blkbird
9th December 2007, 04:24
Resize to your screen size and select "Keep original aspect ratio". Check "Process pixel aspect ratio internally". Inside/Outsize borders 0%. Dvide vertical borders to bottom 100% or whatever you like.
Looks incredibly complicated, but it's indeed somehow working. Now I'm wondering why "Subtitles > Letterboxing" is there in the first place because it's fully redundant to this set of settings. Anyway, I would have never figured it out by myself since I don't know what a lot of those options really mean.
BTW, do you really want me to "resize to screen size" as opposed to "resize to screen AR"? Because if the player canvas is resized to screen size, then the player window would overflow the screen.
Also, who is normally doing the fullscreen resizing, the video renderer? Would the resize by ffdshow be significantly better then, say, VMR9?
Goto Reize settings page and select Luma method which is suitable for your CPU power. If your CPU is powerful enough use Bicubic or Lanczos and output in RGB32 for better quality.
What is this "Lanczos" method really? And what do you mean by "output in RGB32"? - Should I disable all output colorspaces except for RGB32?
My CPU is an Athlon 64 X2, so yes, it's fairly fast.
squid_80
9th December 2007, 04:54
I did some more tests. Not surprisingly, libavcodec has the same problem with other MPEG4 Part2 codecs, such as 3ivx, too. But selecting 'Xvid' doesn't help here and I see no reason to change this one:
If the bitstream isn't packed, you're going to have delay issues no matter what codec is used for decoding.
Liisachan
9th December 2007, 06:05
If the bitstream isn't packed, you're going to have delay issues no matter what codec is used for decoding.
Of course it is packed for Xvid/divx. That's default, isn't it? And the user data is getting "p" like "DivX503b1393p" in Xvid too, for example.
That's about Xvid and divx. I don't know about 3ivx. I just used it for testing; had never used it before, and probably will never use it for anything real. Since 3ivxVfWCodec.dll itself cannot decode its own format frame-accurately, we cannot blame libavcodec here.
haruhiko_yamagata
9th December 2007, 06:23
Looks incredibly complicated, but it's indeed somehow working. Now I'm wondering why "Subtitles > Letterboxing" is there in the first place because it's fully redundant to this set of settings. Anyway, I would have never figured it out by myself since I don't know what a lot of those options really mean.Yes, it's incredibly complicated. Here (http://ffdshow-tryout.sourceforge.net/html/en/resize.htm) is a document. Not perfect though.
BTW, do you really want me to "resize to screen size" as opposed to "resize to screen AR"? Because if the player canvas is resized to screen size, then the player window would overflow the screen."resize to screen AR" is OK too. "resize to screen size" is for full screen mode, i.e. home theater purpose.
Also, who is normally doing the fullscreen resizing, the video renderer? Would the resize by ffdshow be significantly better then, say, VMR9?Nope, but if you want better quality for subtitles, it is best to use software resize before subtitles and output in RGB32.And what do you mean by "output in RGB32"? - Should I disable all output colorspaces except for RGB32?Yes. The document (http://ffdshow-tryout.sourceforge.net/html/en/outputv.htm). The help button on the dialog page works.
My CPU is an Athlon 64 X2, so yes, it's fairly fast.I hope that's fast enough, but the settings described here is quite heavy.
Liisachan
9th December 2007, 07:11
If the bitstream isn't packed, you're going to have delay issues no matter what codec is used for decoding.
PS: I think you're right about 3ivx. I just found that this 3ivx AVI is not frame-accurate even when it is played via DirectShow., and cannot be used for anything that requires good sync (eg softsubbing, karaoke).
Among ffdshow 'Other MPEG4', 'libavcodec' works relatively better for me than 'Xvid', both in VFW and DS, for this 3ivx thing, which however you cannot seek frame-accurately anyway.
Then again, I don't believe there are many people who use 3ivx in AVI. Xvid and DivX are much more common, and 3ivx is not free either.
Anyway, 'libavcodec' VFW is getting the decoder delay even if the bitstream is 'packed', while 'Xvid' supports that hack; that's why I'd like to suggest 'Xvid' as default in Xvid and DivX.
clsid
9th December 2007, 15:38
The installer has already been modified to use xvidcore by default for VFW decoding.
Why should libavcodec be used for 'Other MPEG4'? XviD/DivX encoded video can also fall under this type, since the choice is simply made based on the FourCC.
SeeMoreDigital
9th December 2007, 16:24
Do we really need to separate all the MPEG-4.2 "format" types now anyway?
Why not offer just one, like there is for "H.264/AVC" and call it something like "MPEG-4 ASP". Complete with the "disabled, libavcodec and Xvid" decoder options?
Cheers
clsid
9th December 2007, 16:50
Yes, they are needed because not everyone uses ffdshow for all MPEG-4 ASP variants.
Blkbird
9th December 2007, 21:30
And what do you mean by "output in RGB32"? - Should I disable all output colorspaces except for RGB32?
Yes. The document (http://ffdshow-tryout.sourceforge.net/html/en/outputv.htm).
After turning off all YUV output formats, I only get blank screen with all the XviD videos (ffdshow build 1673, icl, x86, unicode).
SeeMoreDigital
9th December 2007, 23:01
Yes, they are needed because not everyone uses ffdshow for all MPEG-4 ASP variants.More fools them....
haruhiko_yamagata
10th December 2007, 00:20
After turning off all YUV output formats, I only get blank screen with all the XviD videos (ffdshow build 1673, icl, x86, unicode).It doesn't seem to be a bug of ffdshow.
To which filter ffdshow is connected?
Updating the video driver may help.
Liisachan
10th December 2007, 01:18
The installer has already been modified to use xvidcore by default for VFW decoding.
Why should libavcodec be used for 'Other MPEG4'? XviD/DivX encoded video can also fall under this type, since the choice is simply made based on the FourCC.
in my tests, libavcodec works better for 3ivx in seeking, while xvid is better for xvid. the stand alone xvid decoder does not even support 3ivx officially btw
Liisachan
10th December 2007, 01:35
Why not offer just one, like there is for "H.264/AVC" and call it something like "MPEG-4 ASP". Complete with the "disabled, libavcodec and Xvid" decoder options? Maybe one of the typical situations is, when you have Xvis or DivX or other codecs installed and you want them decode things (everything they can decode or their own formats), but you want ffdshow to decode the other formats. Many users use Xvid standalone codec for Xvid in VFW (if they used ffdshow def. there would be a lot of bug reports by now) or maybe also in DS, but they don't have 3ivx so they still need ffdshow in some case when they happen to need to test a 3ivx clip. Or similarly some ppl may prefer Divx standalone decoder.
Plus, altho I'm not sure about this, a specific standalone decder may have too high merit, and ffdshow might have to use really hight merit for that specific format to be enabled, as a workaround. If ffdshow has a very high merit for MPEG-4 Part2 generally, there might be some kind of bad side effects. A very hight merit is supposed to be a workaround only for a specific codec for specific fourccs. I kind of remember milan says something about this, about DivX... but I may be wrong.
Personally, I can live with it if MPEG-4 Part 2 becomes one item. (But don't call part2 mepg4 "ASP". It's a term used mainly only in doom9 forums)
SeeMoreDigital
10th December 2007, 09:34
Personally, I can live with it if MPEG-4 Part 2 becomes one item. (But don't call part2 mepg4 "ASP". It's a term used mainly only in doom9 forums)Agreed...
I much prefer to see terms such as: MPEG-4 Part-2 or MPEG-4.2. And MPEG-4 Part-10 or MPEG-4.10, being used....
FFWD
10th December 2007, 13:55
[edit]
potential flame-bait removed.
haruhiko_yamagata
10th December 2007, 14:09
Is there any reason why the CCCP guys deny they use ffdshow tryouts, while they actually ARE using it? Why the bashing?
btw: they haven't published their patches for the latest beta.
Everyone, please just ignore them. I don't want flame here.
And it's best not to read that link.
Liisachan
10th December 2007, 15:05
@SeeMoreDigital
"DivX, Xvid, etc."
would be easier to understand for many users. And btw, when I said, '(but don't call part2 mepg4 "ASP")', I meant in the menu of ffdshow. I have nothing against the term "ASP" itself. It should be ok to call MPEG-4 Part2 "ASP" here in this forum as a kind of convention, because they/we/you know what it means.
haruhiko_yamagata
10th December 2007, 15:39
Fix: If ffdshow was used for decoding VC-1 video, then framerate got changed from 23,976 fps to 29.97 fps.Now it should work as long as you decode VC-1 in ffdshow. I don't have many samples, please send me a sample that doesn't work.
Unfortunately, DMO wrapper doesn't send field 1 repeat flag if it is connected to ffdshow as raw video processor. Besides it sets wrong time stumps, which is much worse than nothing.
I don't know what trick it uses to present at the correct time when it is connected to VMR. Perhaps it doesn't set time stumps and send field 1 repeat flags if it is connected to VMR (just a random guess though).
Thunderbolt8
11th December 2007, 01:47
Now it should work as long as you decode VC-1 in ffdshow. I don't have many samples, please send me a sample that doesn't work.
the remuxed video from galapagos HD DVD made trouble, vc-1 with libavcodec didnt give out a picture at all, only sound. had to switch back to wmv9 for that. the video is 1080i at 29.97 fps, guess this combination was too tricky. unfortunately my samples at sendspace or megaupload already got deleted :S
Shakey_Jake33
11th December 2007, 02:22
This isn't an essential thing, and I don't know how difficult it would be to do, but I have both the 32-bit and 64-bit builds of ffdshow installed (no real need I know, but I do occasionally fiddle with Vista Media Center x64 and mpc x64), and whatever settings/changes I make for one build, it affects the other (for example, if I disable H.264 in the 32-bit version, it disables it in the 64-bit version too).
Any chance they can be made completely separate from each other at some point?
(same goes for mpc actually, settings changed in one affect the other)
squid_80
11th December 2007, 03:50
Any chance they can be made completely separate from each other at some point?Why would you want that?
check
11th December 2007, 06:29
Is there any reason why the CCCP guys deny they use ffdshow tryouts, while they actually ARE using it? Why the bashing?You are trying to stir up trouble. We like and endorse tryouts. You can see that because we use it in our packs and explicitly name the project during our installation. Tryouts is awesome and the developers are awesomer for continuing to keep ffdshow up to date.
The only thing said in that thread was that we didn't include beta3 in the pack. beta3 is rev1324. We include r1355. Therefore, we don't include beta3.
btw: they haven't published their patches for the latest beta.We don't need to, patches must only be published for releases. Betas are for testing by CCCP staff and other interested users.
Please, let me say it again. We Heart Tryouts.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.