View Full Version : ffdshow tryouts project: Discussion & Development
STaRGaZeR
4th January 2011, 18:30
There's a problem in the filter, ffmpeg produces correct output while ffdshow doesn't. I'll look into it.
TheShadowRunner
5th January 2011, 02:42
Build 3713 crashes badly when feeding it the attached XVID file (crash in ntdll.dll).
No issues with build 3703 !
(XP SP3 32bit)
nightfly
5th January 2011, 08:25
How hard would it be to implement the following rule for "Swap Channel" feature:
If LPCM == 6 Channel then enable the swap channel setting/feature.
The reason is that Nvidia's HDMI driver has had this nastly bug for some time where if you have a 7.1 speaker setup and playback a 5.1 LPCM track, it'll output the surround channels to the rear channel instead of the side.
I've hacked on MPC-HC before so I am willing to take a look, just need to know where to start or solicit alternate ideas.
cyberbeing
5th January 2011, 09:22
That isn't really a bug. It's not strange for the rear left and rear right surrounds of a 5.1 track to playback on the rear left and rear right surrounds in a 7.1 speaker setup. The side channel speakers you speak of, don't exist in a 5.1 setup.
Does setting a Preset solve your problem?
on decoder match: raw LPCM
AND
on number of channels: 6
STaRGaZeR
5th January 2011, 20:21
Deband is fixed in r3718. Report any issues as always.
ICL12: http://www.mediafire.com/?168mvl4d0vpc786
MSVC x64: http://www.mediafire.com/?qyxbeb0jpjtzyjq
Despite the name, the builds are r3718.
clsid
5th January 2011, 21:06
Build 3713 crashes badly when feeding it the attached XVID file (crash in ntdll.dll).
No issues with build 3703 !
(XP SP3 32bit)Please upload the file somewhere else.
clsid
6th January 2011, 00:17
I have noticed a weird bug with decoding Techsmith video (TSCC). It decodes with correct colors during DirectShow playback (using r3719). It then converts from BGR24 to RGB32.
When decoding in VirtualDub using VFW mode, the colors are wrong. Red and blue seem swapped. However, when I force a different colorspace like RGB32 or YV12 (VDub menu > Video > Color Depth), it decodes with correct colors. Colors are also wrong when using the Old Renderer in MPC, in which case it outputs RGB24.
Does anyone have an idea what might be wrong?
Here is a sample file:
http://www.mediafire.com/?7llbdqshl33s620
nightfly
6th January 2011, 00:30
That isn't really a bug. It's not strange for the rear left and rear right surrounds of a 5.1 track to playback on the rear left and rear right surrounds in a 7.1 speaker setup. The side channel speakers you speak of, don't exist in a 5.1 setup.
Does setting a Preset solve your problem?
on decoder match: raw LPCM
AND
on number of channels: 6
Well, a 7.1 differs from a 5.1 setup by adding rear speakers and thus the rears should only be used in 7.1 audio formats.
I am not familiar with "Presets" but will look around ffdshow and see if I can find what you're referencing as that does sound like it could work.
So I'd define a preset and that preset would contain the channel swap?
Snowknight26
6th January 2011, 05:14
Does anyone have an idea what might be wrong?
Conversion from BGR is broken. I think I've mentioned it (when it came up with Fraps) a few too many times. ;)
cyberbeing
6th January 2011, 11:26
Deband is fixed in r3718. Report any issues as always.
ICL12: http://www.mediafire.com/?168mvl4d0vpc786
MSVC x64: http://www.mediafire.com/?qyxbeb0jpjtzyjq
Despite the name, the builds are r3718.
No wonder it looked so bad before, the initial commit was borked.
I haven't compared against the old ffdshow gradfun2db yet, but the r3718 fixed ffmpeg deband filter does seem to be working properly now. The major problems I had with r3717 seem to be gone.
Well, a 7.1 differs from a 5.1 setup by adding rear speakers and thus the rears should only be used in 7.1 audio formats.
This is incorrect. A 7.1 setup adds side speakers to a 5.1 setup.
5.1 (Front L, Center, Front R, Rear L, Rear R)
7.1 (Front L, Center, Front R, Rear L, Rear R, Side L, Side R)
I am not familiar with "Presets" but will look around ffdshow and see if I can find what you're referencing as that does sound like it could work.
So I'd define a preset and that preset would contain the channel swap?
Yes, you create a preset which auto-loads with 6 channel LPCM and does your channel swap. Your default preset will load in all other cases.
madshi
6th January 2011, 11:52
A 7.1 setup adds side speakers to a 5.1 setup.
5.1 (Front L, Center, Front R, Rear L, Rear R)
7.1 (Front L, Center, Front R, Rear L, Rear R, Side L, Side R)
No, that's not true. The surround channels in a 5.1 setup are considered "side/surround", not "rear/back". There was a long discussion about this in the eac3to thread, and after studying Dolby and DTS papers and even an email reply from Microsoft the general consensus was that 5.1 has side/surround channels and not rear/back channels.
cyberbeing
6th January 2011, 12:28
Interesting, but I think it really just comes down to how someone has their 7.1 system set up.
If the 7.1 system is setup like this, the sides wouldn't represet a 5.1 surround channels very well, since they are suppose to represent sound from the rear surrounds of the viewer (not direct sides):
http://img193.imageshack.us/img193/9123/standard71surroundsound.png
In a setup like that, using the 7.1 Rear Left and Right would be closer to the 5.1 Left and Right Surrounds.
madshi
6th January 2011, 12:39
Interesting, but I think it really just comes down to how someone has their 7.1 system set up.
If the 7.1 system is setup like this, the sides wouldn't represet a 5.1 surround channels very well, since they are suppose to represent sound from the rear sides of the viewer (not direct sides)
[...]
In a setup like that, using the 7.1 Rear Left and Right would be closer to the 5.1 Left and Right Surrounds.
Check out the Dolby speaker placement guide:
http://www.dolby.com/consumer/setup/speaker-setup-guide/index.html
If you click on "5.1", the guide says:
"Left and Right Surround Speakers: These speakers should be placed to the sides of your seating position".
The recommended angle is 90-110°. Now compare that to the Dolby recommended setup for 7.1, and you'll find that the position of the surround speakers is *exactly* the same. 7.1 just adds back speakers to 5.1. The placement of the 5.1 speakers doesn't change at all.
And if you think about it, it makes sense, at least if you want to watch 5.1 movies in their original form and not artificially upconverted to 7.1 (by some phony algorithm by the receiver). If the surround speaker placement would differ between 5.1 and 7.1, you'd have to move the surround speakers around all the time, if you switch between 5.1 and 7.1 movies.
So the final word is:
A 7.1 setup adds back speakers to a 5.1 setup.
cyberbeing
6th January 2011, 13:04
http://img832.imageshack.us/img832/3067/70289179.pnghttp://img141.imageshack.us/img141/7994/77417220.png
Even though they list the same numbers, they must be calculating them differently, as Dolby Digital's diagrams show significantly different placement. And as before, ignoring numbers, with speaker placement as those diagrams show, the 7.1 rears would be closer to what the 5.1 rear surrounds are supposed to represent.
madshi
6th January 2011, 13:18
I would rather trust the numbers than the diagrams. In the 7.1 diagram it looks like 90°, while in the 5.1 diagram it looks like 110°. So both diagrams are "within spec".
There are more indications for what I said, all already discussed in the eac3to thread. Let me list a couple:
(1) according to MS docus the MS mixer drops the *back* channels if you play 7.1 content with a 5.1 speaker system
(2) the header files for XPSP2 and newer OSs define the 5.1 speaker mask in such a way that surround/side channels are included, but rear/back channels are not
(3) 5.1 DTS-HD files have speaker information stored in the header, they list: "C L R Ls Rs LFE" (you can check with "eac3to some.dts -logdts")
(4) the official Dolby AC3 spec names the speakers of the 5.1 AC3 format "L,C,R,Ls,Rs, LFE"
cyberbeing
6th January 2011, 13:42
I would rather trust the numbers than the diagrams. In the 7.1 diagram it looks like 90°, while in the 5.1 diagram it looks like 110°. So both diagrams are "within spec".
As I mentioned, the 5.1 seems the be calculated from the center (rear?) of the viewers head, while the 7.1 seems calculated from the front (center?) of the viewers lap. The intention seems clear. The 5.1 rear surrounds are designed to act as both side and rear speakers (which is why the 5.1 surrounds are angled exactly between where the 7.1 side and rear are in the diagram). With 7.1 it split the rear surrounds of 5.1 into distinct side and rear speakers.
Using the dot on the diagram, the 5.1 in that diagram shows 120° with a range of 115°-125°. Using the center of where the viewer's head would be as the reference, the 5.1 in that diagram shows 100° with a range of 90°-110°.
The 7.1 in that diagram shows 100° with a range of 90°-110° from the dot.
There is no right or wrong, it only comes down to where you have your 7.1 side and rear speakers placed in your setup. In some cases the sides would be sufficient, in others the rears would be preferable. If your 7.1 side speakers are arranged like the surround in the 5.1 diagram, then they are best used on 5.1 tracks. If your 7.1 side speakers are arranged like the 7.1 diagram, the rears would be best used on 7.1 tracks.
So the final word is:
A 7.1 setup splits 5.1 rear surrounds into distinct side and rear speakers :rolleyes:
nevcairiel
6th January 2011, 14:29
Wow, you're seriously arguing with the dot-position now? The dot is the head. No matter what gfx of a sofa is under there. Also, trust numbers, don't trust graphics.
Anyhow, if you setup your 5.1 surround speakers as rear speakers, thats just how it is.
If you setup 7.1, you will have side speakers, which should be directly to the side, or a bit behind you.
If your personal preference is to have the 5.1 go to the rear speakers, thats your personal opinion, of course. Having an option to output it there might be useful for you, i guess. But its not the "right" way, nor the "wrong" way. Just not the "standard" way. Maybe someone will some day write it for you :d
With profiles you should be able to do it anyway, unless you're bitstreaming to your receiver.
STaRGaZeR
6th January 2011, 15:27
No wonder it looked so bad before, the initial commit was borked.
I haven't compared against the old ffdshow gradfun2db yet, but the r3718 fixed ffmpeg deband filter does seem to be working properly now. The major problems I had with r3717 seem to be gone.
Yeah, sorry about that. The filter system in ffdshow is... strange.
BatKnight
6th January 2011, 16:04
The main question is simple:
Is ffdshow audio mixer correctly playing 5.1 and 7.1 files, sending the audio to the correct speaker, considering the Dolby setup?
Nuno
clsid
6th January 2011, 19:30
Conversion from BGR is broken. I think I've mentioned it (when it came up with Fraps) a few too many times. ;)Isn't that a different problem, related to tv/pc range?
BGR24 to RGB32 is done properly for TSCC. But it seems that BGR24 is outputted as RGB24 without conversion.
TheShadowRunner
6th January 2011, 23:30
Please upload the file somewhere else.
Sure, here it is:
http://videoff7.free.fr/Check_color_space_vmr9-test.zip
(Build 3713 crashes badly when feeding it the attached XVID file (crash in ntdll.dll). No issues with build 3703 !)
nightfly
7th January 2011, 00:46
As I mentioned, the 5.1 seems the be calculated from the center (rear?) of the viewers head, while the 7.1 seems calculated from the front (center?) of the viewers lap. The intention seems clear. The 5.1 rear surrounds are designed to act as both side and rear speakers (which is why the 5.1 surrounds are angled exactly between where the 7.1 side and rear are in the diagram). With 7.1 it split the rear surrounds of 5.1 into distinct side and rear speakers.
Using the dot on the diagram, the 5.1 in that diagram shows 120° with a range of 115°-125°. Using the center of where the viewer's head would be as the reference, the 5.1 in that diagram shows 100° with a range of 90°-110°.
The 7.1 in that diagram shows 100° with a range of 90°-110° from the dot.
There is no right or wrong, it only comes down to where you have your 7.1 side and rear speakers placed in your setup. In some cases the sides would be sufficient, in others the rears would be preferable. If your 7.1 side speakers are arranged like the surround in the 5.1 diagram, then they are best used on 5.1 tracks. If your 7.1 side speakers are arranged like the 7.1 diagram, the rears would be best used on 7.1 tracks.
So the final word is:
A 7.1 setup splits 5.1 rear surrounds into distinct side and rear speakers :rolleyes:
There's just no convincing you huh? Believe what you want. (Regardless, thanks for the 'Preset' tip, that will work for me ;-))
In a 7.1 setup with a 7.1 audio track, each channel has a distinct channel signal (the rears and/or sides may have duplicated content, but they are distinct channels - no multiplexing going on...). In a 6.1 audio track, the rears share the same channel (DD Ex, DTS 6.1, etc.)
Before 7.1 there was 5.1 for many years. The "surrounds" where specified to mounted to the side of the listener, about 3 to 5 ft higher than their heads - this was from Dolby. You go to any non stadium (perhaps older) theaters and they are all only 5.1 setups with multiple side speakers, typically between every two rows - nothing in the rear.
Also, any 5.1 audio track decoded by my receiver has the sides correctly output to the side surrounds: this was two diff HKs and two Denons. Also, even now, sp/dif output correctly on my HTPC for everything but LPCM/PCM.
So it's only wrong when Nvidia is in the loop and has to choose what channel goes where. Also, from what I've read the new SandyBridge drivers suffer from the same issue for LPCM.
I first got into 7.1 due to the LOTR DVDs that had a DTS 6.1 track and you simply put those speakers behind you. All DD/DTS 5.1 never ever used the rears. It's that simple. I just want LPCM 5.1 on Nvidia systems to do the same.
Snowknight26
7th January 2011, 07:13
Isn't that a different problem, related to tv/pc range?
BGR24 to RGB32 is done properly for TSCC. But it seems that BGR24 is outputted as RGB24 without conversion.
Nope, same issue (it's changed a bit since then but the point remains.):
http://forum.doom9.org/showthread.php?p=1412801#post1412801
First shot illustrates BGR32 -> RGB32, which shows the same issue as BGR24->RGB24.
BGR32->RGB24 is fine, just like with your BGR24->RGB32.
nevcairiel
7th January 2011, 08:01
T I just want LPCM 5.1 on Nvidia systems to do the same.
I just have ReClock set the appropriate channel count on the audio device, that way on 6 channel sources, the audio is output as 6 channel, and not as 8 channels with 2 channels blank, that way it always seems to work just fine, also i can tell my receiver to upmix stereo sources instead of trying to use some matrix in ffdshow
PS:
I haven't tried this for quite a while, maybe something new broke in the drivers. Since moving into a new place i only have 5.1 speakers setup. Barely have anything with 6.1/7.1 audio anyway ~.~
TheShadowRunner
8th January 2011, 03:10
Thanks clsid, 3721 fixed the XVID issue.
Mark_A_W
8th January 2011, 03:57
There's just no convincing you huh? Believe what you want. (Regardless, thanks for the 'Preset' tip, that will work for me ;-))
In a 7.1 setup with a 7.1 audio track, each channel has a distinct channel signal (the rears and/or sides may have duplicated content, but they are distinct channels - no multiplexing going on...). In a 6.1 audio track, the rears share the same channel (DD Ex, DTS 6.1, etc.)
Before 7.1 there was 5.1 for many years. The "surrounds" where specified to mounted to the side of the listener, about 3 to 5 ft higher than their heads - this was from Dolby. You go to any non stadium (perhaps older) theaters and they are all only 5.1 setups with multiple side speakers, typically between every two rows - nothing in the rear.
Also, any 5.1 audio track decoded by my receiver has the sides correctly output to the side surrounds: this was two diff HKs and two Denons. Also, even now, sp/dif output correctly on my HTPC for everything but LPCM/PCM.
So it's only wrong when Nvidia is in the loop and has to choose what channel goes where. Also, from what I've read the new SandyBridge drivers suffer from the same issue for LPCM.
I first got into 7.1 due to the LOTR DVDs that had a DTS 6.1 track and you simply put those speakers behind you. All DD/DTS 5.1 never ever used the rears. It's that simple. I just want LPCM 5.1 on Nvidia systems to do the same.
I don't really want to get in the middle of this...
But I prefer my 5.1 surrounds to be the sides in my 7.1 system - for a 5.1 signal.
The Xonar also sends 5.1 to the rears, when 7.1 speakers are active, which is different to the behaviour of a typical receiver, in my experience.
So, I would also like some sort of setting where you can send the 5.1 over 7.1 to either sides or rear, with 2 channels of silence. But intelligently leave 7.1 alone (so a simple permanent channel swap is no good).
In my case I'd have to send the full 7.1 channels (2 silent) for 5.1, or the Xonar messes it up.
Or.....decent upmixing of 5.1 to 7.1 would just make this all go away!
nightfly
9th January 2011, 01:47
I don't really want to get in the middle of this...
But I prefer my 5.1 surrounds to be the sides in my 7.1 system - for a 5.1 signal.
The Xonar also sends 5.1 to the rears, when 7.1 speakers are active, which is different to the behaviour of a typical receiver, in my experience.
So, I would also like some sort of setting where you can send the 5.1 over 7.1 to either sides or rear, with 2 channels of silence. But intelligently leave 7.1 alone (so a simple permanent channel swap is no good).
In my case I'd have to send the full 7.1 channels (2 silent) for 5.1, or the Xonar messes it up.
Or.....decent upmixing of 5.1 to 7.1 would just make this all go away!
That hasn't been my experience with the Xonar...it only has problems with 5.1 LPCM when Nvidia is in the loop (or more precisely, when their HDMI driver is outputting decoded audio)
Otherwise, there's no beef - cyberbieng is happy with his setup (though I guess he'll never bitstream as then 5.1 will always be wrong for him) and I am very happy with cyberbieng's tip - works great for me.
I am checking out the Reclock tip - as that sounds like a better overall solution for music and video. I just want my HTPC to let my Receiver handle all audio "everything" just hand it off untouched and be done. Bitstreaming gets me 75% of the way there.
Mark_A_W
9th January 2011, 02:40
I'm using my Xonar via 7.1 Analogue out, so we have different setups.
BTW the non Asus Unified Xonar Drivers seem to work fine.
cyberbeing
9th January 2011, 09:51
Otherwise, there's no beef - cyberbieng is happy with his setup (though I guess he'll never bitstream as then 5.1 will always be wrong for him) and I am very happy with cyberbieng's tip - works great for me.
For the record, I only have 5.1 setups at my computer and home theater, so I'm personally unaffected by any 7.1 issues. In any case, it's nice to hear that a simple ffdshow preset was able workaround your issue.
Also since it seems what I was saying was being misunderstood, and Dolby makes crappy diagrams, I made a corrected 7.1 diagram (moved dot and corrected angles to spec) to hopefully clear up any confusion. As it turns out, for the 7.1 Dolby diagram in my previous post the angles listed were wrong based on the 1 dot's incorrect location. This in turn means the side channels were way out of spec, sitting at 80°, which is why I was saying if someone had their 7.1 system setup like that diagram, the 7.1 rear channels would likely be better for 5.1 tracks.
http://img189.imageshack.us/img189/5462/701456.png
The above image shows what correct in-spec 7.1 setup looks like, one in which a 5.1 track rear surrounds should playback on the 7.1 side surrounds.
The moral of the story is if you have a correct in-spec 7.1 setup with angles based on the center of the viewer's head, the side channels should always be used on 5.1 tracks. If you have an out-of-spec or creatively laid out 7.1 setup (like the 7.1 image in my previous post from Dolby) with the side channels placed in front of you, the 7.1 rear channels would then become preferable for 5.1 tracks.
god_md5
9th January 2011, 10:46
i get this file no video output ,is use mpc-hc 1.4.2820 with ffdshow 3721
is Splitter bug?
http://dl.dropbox.com/u/3668343/sample3.ts
nightfly
10th January 2011, 00:58
For the record, I only have 5.1 setups at my computer and home theater, so I'm personally unaffected by any 7.1 issues. In any case, it's nice to hear that a simple ffdshow preset was able workaround your issue.
Also since it seems what I was saying was being misunderstood, and Dolby makes crappy diagrams, I made a corrected 7.1 diagram (moved dot and corrected angles to spec) to hopefully clear up any confusion. As it turns out, for the 7.1 Dolby diagram in my previous post the angles listed were wrong based on the 1 dot's incorrect location. This in turn means the side channels were way out of spec, sitting at 80°, which is why I was saying if someone had their 7.1 system setup like that diagram, the 7.1 rear channels would likely be better for 5.1 tracks.
http://img189.imageshack.us/img189/5462/701456.png
The above image shows what correct in-spec 7.1 setup looks like, one in which a 5.1 track rear surrounds should playback on the 7.1 side surrounds.
The moral of the story is if you have a correct in-spec 7.1 setup with angles based on the center of the viewer's head, the side channels should always be used on 5.1 tracks. If you have an out-of-spec or creatively laid out 7.1 setup (like the 7.1 image in my previous post from Dolby) with the side channels placed in front of you, the 7.1 rear channels would then become preferable for 5.1 tracks.
Regardless of one's individual speaker setup and preferences (I won't argue your points there, to each his own) according to everything I've experienced and read, in a 5.1 audio track, the surround channels go to the side speakers. If nothing else, use your receiver as a reference when it decodes any 5.1 audio format.
cyberbeing
10th January 2011, 15:08
Regardless of one's individual speaker setup and preferences (I won't argue your points there, to each his own) according to everything I've experienced and read, in a 5.1 audio track, the surround channels go to the side speakers. If nothing else, use your receiver as a reference when it decodes any 5.1 audio format.
The behavior of receivers to output a 5.1 tracks rear surrounds to the 7.1 side channels is correct, when someone has their 7.1 system set up in-spec like the corrected diagram in my previous post. If I got a 7.1 setup, that is how I would set it up as well. And yes, if your 7.1 setup is in-spec, it does indeed add rear channels to a 5.1 setup.
I was only basing my statement that a 7.1 rear channels would be preferable based on poor out-of-spec diagrams like the one from the Dolby website. If your 7.1 setup is out-of-spec, it may end up more like the 7.1 setup is adding side speakers to a 5.1 setup. Since I'm sure the majority of people never do measurements and just place speakers roughly based on potentially inaccurate diagrams, it's still relevant, even if technically wrong.
From a software point of view, the best behavior would be defaulting to side speakers since that is the in-spec behavior, but also having option to output to rear or both rear and side if desired for people with less-than-optimal setups. For example here is what the Creative drivers do:
http://img23.imageshack.us/img23/7521/creative5171.png
XhmikosR
10th January 2011, 15:10
@devs: With libavcodec AAC no bitrate is shown in the Info & cpu tab. I didn't notice the same with other ffmpeg decoders.
@STaRGaZeR: can you post again your patch regarding the crash with ICL12? I can reproduce it again unfortunately.
clsid
10th January 2011, 15:28
The ffdshow forum is being swamped with spammers. I am tired of cleaning it up every day, so I have disabled posting.
The problem is that there is no user account verification because there is no working e-mail setup on the board and the captcha system isn't effective. Does anyone know of a free SMTP server that doesn't require SSL? Maybe updating phpbb will help combat the spambots?
madshi
10th January 2011, 15:36
FWIW, I've recently updated my own forum to phpbb3 and it helped in so far that I can now easily delete a user with all of his posts in one step. With phpbb2 you had to delete user and posts manually, which could be extremely painful.
STaRGaZeR
10th January 2011, 16:48
@devs: With libavcodec AAC no bitrate is shown in the Info & cpu tab. I didn't notice the same with other ffmpeg decoders.
@STaRGaZeR: can you post again your patch regarding the crash with ICL12? I can reproduce it again unfortunately.
The bitrate problem is because we don't use the AAC parser, and it seems that bitrate is updated in the parser. So unless someone finds why the parser doesn't work the bug is here to stay.
I don't have it anymore, I just changed the ICL #ifdefs in that golomb file, so you can do it again in your PC. But it didn't work for you so maybe the problem is elsewhere.
BTW, it would be nice to see some MSVC vs ICL again with the new deband, with the same sample and filters as in my previous comparison MSVC2010 and ICL12 are less than 1% (margin of error) away from each other. I have virtually no reason to use ICL12 builds anymore.
Brazil2
10th January 2011, 16:56
What is wrong with the official Xvid codec?
You need to install it and to configure it separately. Which is not a problem for you and me and the vast majority of the users of this forum, but which can be a real pain for some people (e.g. my old mother, my sisters) while ffdshow did that in only one install, untill now.
STaRGaZeR
10th January 2011, 17:03
You need to install it and to configure it separately. Which is not a problem for you and me and the vast majority of the users of this forum, but which can be a real pain for some people (e.g. my old mother, my sisters) while ffdshow did that in only one install, untill now.
ffdshow doesn't configure itself to encode anything "in one install" as you say. So I don't really get your point.
XhmikosR
10th January 2011, 18:42
The bitrate problem is because we don't use the AAC parser, and it seems that bitrate is updated in the parser. So unless someone finds why the parser doesn't work the bug is here to stay.
I don't have it anymore, I just changed the ICL #ifdefs in that golomb file, so you can do it again in your PC. But it didn't work for you so maybe the problem is elsewhere.
BTW, it would be nice to see some MSVC vs ICL again with the new deband, with the same sample and filters as in my previous comparison MSVC2010 and ICL12 are less than 1% (margin of error) away from each other. I have virtually no reason to use ICL12 builds anymore.
I don't have the time to make any benchmarks. The last time I did a benchmark I used deband + xsharpen + High quality YV12 to RGB conversion. But that was for ICL11 vs MSVC2008.
I'll try to see what I can do with the ICL12 crash when I have some time.
EDIT: Is there any reason why the manifest files are not embedded?
ikarad
12th January 2011, 15:01
DXVA decoder in ffdshow 3721 doesn't work with some movies. It works with some movies but it doesn't work with other movies. I have sound but screen is black.
Although, with ffmpeg-mt it works very well
geforce9600mt with 260.99 drivers
vista 32 sp2
e-t172
16th January 2011, 00:12
Hi, I have an issue with Blu-ray subtitles (PGS, Presentation Graphics Stream) using MPC-HC and ffdshow.
Here is the result with madVR as the video renderer:
http://uppix.net/8/c/b/c376ca607522a7fb9663b891b11a7t.jpg (http://uppix.net/8/c/b/c376ca607522a7fb9663b891b11a7.html)
As you can see, it's quite ugly. The issue appears with (at least) madVR and EVR, although it seems less visible in EVR. Also, the subtitles flicker in madVR (but that's probably an unrelated issue). Other subtitles (SRT for example) seem to work fine.
Software used (all latest, 32-bit):
- Media Player Classic Homecinema 1.4.2499.0
- ffdshow r3721
- madVR 0.36
- Windows 7
Any idea what's going on?
ikarad
17th January 2011, 19:04
Hi, I have an issue with Blu-ray subtitles (PGS, Presentation Graphics Stream) using MPC-HC and ffdshow.
Here is the result with madVR as the video renderer:
http://uppix.net/8/c/b/c376ca607522a7fb9663b891b11a7t.jpg (http://uppix.net/8/c/b/c376ca607522a7fb9663b891b11a7.html)
As you can see, it's quite ugly. The issue appears with (at least) madVR and EVR, although it seems less visible in EVR. Also, the subtitles flicker in madVR (but that's probably an unrelated issue). Other subtitles (SRT for example) seem to work fine.
Software used (all latest, 32-bit):
- Media Player Classic Homecinema 1.4.2499.0
- ffdshow r3721
- madVR 0.36
- Windows 7
Any idea what's going on?
Maybe a problem with madvr because without madvr I don't have this bug since many versions of ffdshow.
Can you test without madvr?
e-t172
18th January 2011, 12:01
With EVR there is still some chroma issues around the edges of the letters, albeit much more subtle:
http://uppix.net/d/b/3/9f4e3227209f06dfe5938f56aa4eft.jpg (http://uppix.net/d/b/3/9f4e3227209f06dfe5938f56aa4ef.html)
(see the bottom of "assassination")
Maybe the problem with madVR is unrelated to the much smaller corruption in EVR. Should I post in the madVR thread?
hoborg
18th January 2011, 22:34
Hi.
I have problem to open this MOV video (http://www.ronkramer.net/MVI_2280.MOV) - tested using LAVF and MPC-HC MP4 splitter.
Medialooks QT source + QTLite 4.10 doesnt work either.
It plays fine in Firefox using QTLite 4.10
Complete name : D:\download\Mvi_2280.mov
Format : MPEG-4
Format profile : QuickTime
Codec ID : qt
File size : 10.5 MiB
D:\download\Mvi_2280.mov::Output
Media Type 0:
--------------------------
Unknown
AM_MEDIA_TYPE:
majortype: MEDIATYPE_Stream {E436EB83-524F-11CE-9F53-0020AF0BA770}
subtype: Unknown GUID Name {08E22ADA-B715-45ED-9D20-7B87750301D4}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 0
Media Type 1:
--------------------------
Unknown
AM_MEDIA_TYPE:
majortype: MEDIATYPE_Stream {E436EB83-524F-11CE-9F53-0020AF0BA770}
subtype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 0
Not supported by FFDshow? Any idea what decoder use to play it in DirectShow?
Thanks.
nm
19th January 2011, 00:18
Hi.
I have problem to open this MOV video (http://www.ronkramer.net/MVI_2280.MOV) - tested using LAVF and MPC-HC MP4 splitter.
Medialooks QT source + QTLite 4.10 doesnt work either.
It plays fine in Firefox using QTLite 4.10
Complete name : D:\download\Mvi_2280.mov
Format : MPEG-4
Format profile : QuickTime
Codec ID : qt
File size : 10.5 MiB
Looks like you only got part of the 28 MB file. Might explain some of the difficulties with it.
MPlayer plays the clip fine with libavformat.
takenori
20th January 2011, 15:35
Hi, my first post here:)
I have a problem with a dvd ripped-video via Handbrake 0.9.5 ("regular-high profile" profile) in which the video crashing out the mpc-hc when ffdshow set as decoder (all setting in default)
strangely enough, when I play other video and then play the said video without closing the player, the video play just fine.
heres the mediainfo:
Format : Matroska
File size : 111 MiB
Duration : 2mn 54s
Overall bit rate : 5 333 Kbps
Writing application : HandBrake 0.9.5
Writing library : libmkv 0.6.4.1
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Format settings, GOP : M=1, N=16
Codec ID : V_MPEG4/ISO/AVC
Duration : 2mn 54s
Nominal bit rate : 5 000 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Original display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 29.908 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.484
Writing library : x264 core 112
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=300 / keyint_min=29 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=5000 / ratetol=1.0 / qcomp=0.60 / qpmin=3 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Language : English
Color primaries : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M
for a cmoparison, heres the rip with handbrake 0.9.4, with the same profile, which works fine
Format : Matroska
File size : 155 MiB
Duration : 4mn 4s
Overall bit rate : 5 329 Kbps
Writing application : HandBrake 0.9.4
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 4mn 4s
Bit rate : 5 000 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.603
Stream size : 143 MiB (92%)
Writing library : x264 core 79
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=3 / nr=0 / decimate=1 / mbaff=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=1 / wpredb=1 / wpredp=2 / keyint=240 / keyint_min=24 / scenecut=40 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=5000 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Language : English
Color primaries : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M
thanks for the answer :thanks:
adam777
20th January 2011, 17:10
Hello all,
I've recently came across a VobSub (sub/idx) subtitle that for some reason FFDShow was not able to load.
I made sure VobSub subtitles are ticked under "Subtitles" and it also worth noting that FFDShow is able to play srt files with no problems and also that the above VobSub subtitles loads just fine in DirectVobSub.
Any ideas as to what I should look at to help resolve this issue?
Thank, Adam.
clsid
20th January 2011, 18:01
It is a know bug with VobSubs.
There is nothing you can do except try to fix it yourself and submit a patch. None of the current devs has time/knowledge/motivation to fix it.
Brazil2
20th January 2011, 18:17
@ clsid
FYI the link to "ffdshow SVN builds" in your signature is now pointing to the "Very old builds" folder rather than your main folder (http://sourceforge.net/projects/ffdshow-tryout/files/SVN builds by clsid/).
adam777
20th January 2011, 18:58
It is a know bug with VobSubs.
There is nothing you can do except try to fix it yourself and submit a patch. None of the current devs has time/knowledge/motivation to fix it.
Fair enough, thanks for the quick reply clsid :)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.