ffdshow tryouts project: Discussion & Development [Archive] - Page 128

albain

26th January 2009, 10:51

P.S: Just checked out "wmcodecdsp.h" in the Windows SDK. There are a number of interesting GUIDs in there:

DEFINE_GUID(MEDIASUBTYPE_MSAUDIO1, 0x00000160, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_WMAUDIO2, 0x00000161, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_WMAUDIO3, 0x00000162, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_WMAUDIO_LOSSLESS, 0x00000163, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_WMASPDIF, 0x00000164, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_MPEG_ADTS_AAC, 0x00001600, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_MPEG_RAW_AAC, 0x00001601, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_NOKIA_MPEG_ADTS_AAC, 0x00001608, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_NOKIA_MPEG_RAW_AAC, 0x00001609, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_VODAFONE_MPEG_ADTS_AAC, 0x0000160A, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_VODAFONE_MPEG_RAW_AAC, 0x0000160B, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_DOLBY_DDPLUS, 0xa7fb87af, 0x2d02, 0x42fb, 0xa4, 0xd4, 0x5, 0xcd, 0x93, 0x84, 0x3b, 0xdd);
DEFINE_GUID(MEDIASUBTYPE_DOLBY_TRUEHD, 0xeb27cec4, 0x163e, 0x4ca3, 0x8b, 0x74, 0x8e, 0x25, 0xf9, 0x1b, 0x51, 0x7e);
DEFINE_GUID(MEDIASUBTYPE_DTS_HD, 0xa2e58eb7, 0xfa9, 0x48bb, 0xa4, 0xc, 0xfa, 0xe, 0x15, 0x6d, 0x6, 0x45);
I'd suggest adding support for DOLBY_DDPLUS, DOLBY_TRUEHD and DTS_HD. I think DOLBY_DDPLUS and DTS_HD should be treated just the same way as the conventional AC3 and DTS GUIDs, though...

I will add those too. Let's hope that the splitters will be updated soon too

*EDIT* : done in revision 2635

madshi

26th January 2009, 12:18

I will add those too. Let's hope that the splitters will be updated soon too

*EDIT* : done in revision 2635
Thanks! I've already notified the MPC HC guys and also Nero, so I hope that at least those two splitters will be updated sooner or later...

SledgeHammer_999

26th January 2009, 18:09

Hey guys, I have problems with latest builds from albain/clsid/xxl. They all temporarely "pause" after some seconds of playback of a certain file. The thing is I don't know if I am allowed(by the forum rules) to link to the torrent file(it is a fansub of an anime ep).

EDIT: rev2615 works fine. The "pausiness" exists in 2630/2635/2636/2633(mt)

iron2000

26th January 2009, 18:10

Not sure if its me only but for 2636, after I merge my settings from 2630 I will get an error when playing Xvid or DivX files.
Using MPC to play, WMP10 will freeze and spout a second then third process, end task before more could appear.

2635 is fine, using that now.

Inspector.Gadget

26th January 2009, 19:26

madshi

27th January 2009, 10:51

Now that the new GUIDs are in place, what happens with the different audio formats? As I understand it:
AC3 -> libavcodec or liba52 decoding.
EAC3 -> libavcodec decoding.
MLP/THD -> libavcodec decoding.
DTS -> libavcodec or libdts decoding.
DTS-HD -> libavcodec decoding of DTS core?
DTS-HD MA -> libavcodec decoding of DTS core?

Is this right? Thanks!
I would generally not trust in that GUID AC3 means that the actual data could not be E-AC3. Or GUID DTS can still contain DTS-HD data. So I think the new GUIDs should not improve anything for end users. It just means that hopefully splitters and decoders will be slightly more compatible with the new HD audio formats in the future than they were in the past.

gruppo_sd

27th January 2009, 11:44

for me crash when open all avi (divx-xvid), works with h264 an other.
excuse for bad english

clsid

27th January 2009, 16:14

Should be fixed now.

clsid

27th January 2009, 17:09

@Albain
Could you have a look at these bug reports:
http://sourceforge.net/tracker/index.php?func=detail&aid=2510125&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=2517100&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=2498294&group_id=173941&atid=867360

@Haruhiko
Could you have a look at this bug report:
http://sourceforge.net/tracker/index.php?func=detail&aid=2510125&group_id=173941&atid=867360

@Leak
Could you have a look at this bug report:
http://sourceforge.net/tracker/index.php?func=detail&aid=2528457&group_id=173941&atid=867360

albain

27th January 2009, 19:17

I use MPC-HC 976 and I can select LPCM soundtrack and I have sound

Try to disable haali's media splitter because before I used haali and with haali I could not listen lpcm soundtrack from blu-ray but It was 6 months ago

Hi,
That means that you played a blu-ray having an uncompressed 7.1 stream ?
I don't know if it possible for you to get a sample but I don't have any (I "only" have blurays with compressed TrueHD as highest quality, not with uncompressed streams)

I don't use haali's media splitter
I try an old version 2489 (but it is the same since mlp support in ffdshow (october or november)) and i d'ont have sound with mlp soundtrack.
when i play the sample from the beginning, there is no sound.
However, if I play the sample from the beginning and during the movie, If I move the cursor of the sliding bar (which indicates the current playing time) to another location, then the sound can be listened whatever 2489 or the last version.
I have the same problem for all blu-rays (that I own) including both lpcm and mlp soundtracks.
Is this always related to LPCM checkbox or can you hear sound when you check AC3 SPDIF ?

In all cases I suppose that you have an ATI 4xxx card that is able to bitstream LPCM 7.1 with high bitrates through the HDMI connector ?

If this is the case it will be hard to figure out because I only have SPDIF to test.

EDIT :
I have made a few tests. Actually, LPCM does work on regular AC3/DTS streams but not on TrueHD, but it may be due to my SPDIF bandwidth limitation.

moshmothma

28th January 2009, 01:20

I notice a another bug with ffdshow.
With some blu-ray, If I select MLP soundtrack, I have no sound

EDIT:I try an old version 2489 (but it is the same since mlp support in ffdshow (october or november)) and i d'ont have sound with mlp soundtrack.
when i play the sample from the beginning, there is no sound.
However, if I play the sample from the beginning and during the movie, If I move the cursor of the sliding bar (which indicates the current playing time) to another location, then the sound can be listened whatever 2489 or the last version.
I have the same problem for most of blu-rays (that I own) including both lpcm and mlp soundtracks.

I have the same issue. I have to move the slider before the sound will kick in (or alternately I can click on the subtitle option in the splitter output). I am using an ATI HDMI sound card. I have used various revs of MPC-HC filters along with different revs of ffdshow. This only happens with TrueHD. thx

albain

28th January 2009, 08:44

I remember this issue and it comes from the splitter that messes up with the frames. Casimir666 sent me a PM that he was implementing MLP splitting in MPCHC. I don't know if this is done by now.

However, it may also be a bug in FFDShow. Could you post a sample ?

leeperry

28th January 2009, 18:32

@Haruhiko : considering you're redoing the RGB32 conversion section in ffdshow, maybe you could use tritical's chroma upsampling algorithm ?

on tests patterns it looks really good :
http://forum.doom9.org/showpost.php?p=1242736&postcount=142

it's in ddcc's source code(http://bengal.missouri.edu/~kes25c/ddcc.zip), and I'm sure tritical wouldn't mind :D

also about OzoneMP, ffdshow works perfectly fine with FFX-4(from my friend Vincent Burel), so I'm now using Ozone3 DirectX with it in 32 bits float :

http://www.barryrudolph.com/mix/graphics/oz3stereo.gif

thing is FFX-4 shows its GUI when I play a file, but I've asked Vincent if he can disable that ;)

as you can see, Ozone is widely used :
http://www.head-fi.org/forums/f46/how-get-warmer-384571/#post5059409

:thanks: again for your fantastic work on ffdshow :cool:

mark0077

28th January 2009, 21:06

EDIT:

I found that avisynth's rgb32lut conversion that outputs rgb32, along with the use of libavcodec, causes ffdshow to do its own rgb32 conversion, which is not what is expected.

With libavcodec disabled, and using mpc-hc's mpeg2 decoder, ffdshow no longer seems to do the rgb32 conversion which is the expected behaviour.

haruhiko_yamagata

29th January 2009, 11:07

@Haruhiko : considering you're redoing the RGB32 conversion section in ffdshow, maybe you could use tritical's chroma upsampling algorithm ?
1 - linear interpolation (average u/v of first y with u/v of first y in next yuyv set)
Current ffdshow (HQ) and AviSynth's YUY2->RGB conversion use that algorithm. It's not perfect, it has an issue like this (http://img131.imageshack.us/my.php?image=comparisonzoomxr4.png).

What about my algorithm :D
Y0U0Y1V0 Y2U2Y3V2 Y4U4Y5V4 ...

newY1 = Y1
newU1 = (3*U0 + U2)/4

newY2 = Y2
newU2 = (U0 + 3*U2)/4

newY3 = Y3
newU3 = (3*U2 + U4)/4

newY4 = Y4
newU4 = (U2 + 3*U4)/4

AviSynth's YV12->YUY2 converter does this vertically, but it has limitation of output bit depth (naturally 8bit).
My implementation output 10bit vertical 75:25 averaging, 12 bit horizontal 75:25 averaging, other calculations are more than 10bit.

The implementation (patch (http://ffdshow-tryout.sourceforge.net/samples/newRGBconversion20090128.patch), build (http://ffdshow-tryout.sourceforge.net/samples/ffdshow_rev2640_20090128_Q.exe)).

20% faster than current "High quality YV12 to RGB conversion" with better quality. Make sure "High quality YV12 to RGB conversion" checked and have SSE2.
At this moment, YV12 progressive->RGB32 only.
Please wait a week or two, I'll add some more color spaces support. Maybe multithreading too. Please feel free to use my code in any GNU projects (under some other free software license, PM me).

// EDIT: 20% faster on Core2 Quad 9550 plus relatively slow memory. Maybe slower on 65nm Core2 or older and on system with very fast memory.

madshi

29th January 2009, 11:23

Current ffdshow (HQ) and AviSynth's YUY2->RGB conversion use that algorithm. It's not perfect, it has an issue like this (http://img131.imageshack.us/my.php?image=comparisonzoomxr4.png).

What about my algorithm :D

AviSynth's YV12->YUY2 converter does this vertically, but it has limitation of output bit depth (naturally 8bit).
My implementation output 10bit vertical 75:25 averaging, 12 bit horizontal 75:25 averaging, other calculations are more than 10bit.

The implementation (patch (http://ffdshow-tryout.sourceforge.net/samples/newRGBconversion20090128.patch), build (http://ffdshow-tryout.sourceforge.net/samples/ffdshow_rev2640_20090128_Q.exe)).

20% faster than current "High quality YV12 to RGB conversion" with better quality. Make sure "High quality YV12 to RGB conversion" checked and have SSE2.
Nice!!

In the image comparison you linked to is your new algorithm the one at the bottom of the comparison ("YV12 + Chroma Upscampler")?

leeperry

29th January 2009, 11:30

Current ffdshow (HQ) and AviSynth's YUY2->RGB conversion use that algorithm. It's not perfect, it has an issue like this (http://img131.imageshack.us/my.php?image=comparisonzoomxr4.png).
actually, these tests from mark0077 might be flawed, as he said himself here :
http://forum.doom9.org/showpost.php?p=1243013&postcount=156

here's ffdshow in RGB32/601 :

http://thumbnails.imagebam.com/2499/fe9a1124987333.gif (http://www.imagebam.com/image/fe9a1124987333)

and in RGB32HQ/601 :

http://thumbnails2.imagebam.com/2499/6a0f6e24987337.gif (http://www.imagebam.com/image/6a0f6e24987337)

this is tritical's ddcc :

http://thumbnails16.imagebam.com/2499/efa09524987327.gif (http://www.imagebam.com/image/efa09524987327)

and this is your new test build in RGB32HQ :

http://thumbnails13.imagebam.com/2499/058c4224987340.gif (http://www.imagebam.com/image/058c4224987340)

tritical explained it thorougly in this post :
http://forum.doom9.org/showpost.php?p=1235348&postcount=102

your new test build looks really good! :eek:

I will link your code in tritical's thread so you guys can discuss it :thanks:

please note that this is an extreme test pattern, the difference is hardly noticeable in movies, as shown here :
http://forum.doom9.org/showpost.php?p=1242783&postcount=149

but I'm kind of a nitpicker myself :D

the only TRUE difference is that yesgrey3's REC601/709 seem a lot more accurate than ffdshow's....the black background is actually R0-G0-B0 in ddcc, but in Convert()(full range 601)/ffdshow(full range 601) it's R2-G0-B1 :confused:

haruhiko_yamagata

29th January 2009, 11:58

the only TRUE difference is that yesgrey3's REC601/709 seem a lot more accurate than ffdshow's....the black background is actually R0-G0-B0 in ddcc, but in Convert()(full range 601)/ffdshow(full range 601) it's R2-G0-B1 :confused:
Does this still exist in the new build?

leeperry

29th January 2009, 11:59

Does this still exist in the new build?
it has improved a bit, now it's R2/G0/B0 :)

haruhiko_yamagata

29th January 2009, 12:11

it has improved a bit, now it's R2/G0/B0 :)
Could you send me the sample? I think (Y,Cb,Cr)-(16,128,128) is correctly mapped (0,0,0). The source may be slightly off (16,128,128).

leeperry

29th January 2009, 12:15

Could you send me the sample? I think (Y,Cb,Cr)-(16,128,128) is correctly mapped (0,0,0). The source may be slightly off (16,128,128).
http://rapidshare.com/files/122925763/Bronz_s.mkv.html http://forum-images.hardware.fr/images/perso/d4buff.gif

haruhiko_yamagata

29th January 2009, 12:25

Nice!!

In the image comparison you linked to is your new algorithm the one at the bottom of the comparison ("YV12 + Chroma Upscampler")?No. Mine is as good as "YV12".

haruhiko_yamagata

29th January 2009, 12:34

http://rapidshare.com/files/122925763/Bronz_s.mkv.html http://forum-images.hardware.fr/images/perso/d4buff.gif
The "black" is not black. It's (17,129,129). ffdshow is doing correct conversion. It is (R,G,B)=(3,0,1) as it should.

leeperry

29th January 2009, 12:37

The "black" is not black. It's (17,129,129). ffdshow is doing correct conversion. It is (R,G,B)=(3,0,1) as it should.
oops OK, I'll let yesgrey3 know :thanks:

yesgrey

29th January 2009, 13:00

haruhiko,
Nice work with the new YV12 algorythm!:)
Since you are working in that part of ffdshow's code, if you have the time could you add the option of using the 3D LUT? Remember that it's just loading the file in memory and then map the YCbCr or RGB data through it... The 3D LUT final goal would be a complete custumization of the output to match exactly the user's display, and the new YV12 algorythm will help increasing the quality!;)

oops OK, I'll let yesgrey3 know :thanks:
I will take a look at it...

yesgrey

29th January 2009, 13:16

leeperry,
I have tested with the exact same 3D LUT files and my results are:
BT.601: RGB[3,0,1]
BT.709: RGB[3,1,1]
Exactly the same values I get with ffdshow, so, both 3D LUT and ffdshow perform accurate conversions.
You should be doing something wrong... Try disabling the other filters you are using.

mark0077

29th January 2009, 13:23

Very impressed with the new ffdshow rgb32hq. Files are smaller than original rgb32hq and smaller than leeperry's (can't test properly because of some bug somewhere) posted code but look perfect.

Actually the new rgh32hq looks almost identical to Nvidias effort which is..... excellent!! GREAT STUFF

One final comment before I try and do a proper comparison with my machine, is there going to be an implementation of the two different REC.601's as I see in many posts there are two different ones.

leeperry

29th January 2009, 13:24

You should be doing something wrong... Try disabling the other filters you are using.
all I'm doing is colorYUV(levels="tv->pc") to output full range YUY2 + your 16-235 LUT(so it keeps the levels untouched and outputs 0-255).
I would appreciate one 601 and one 709 LUT for full range YUY2 if that's where the issue lies please.

I was also using colorYUV(levels="tv->pc") in the ffdshow tests, w/ ffdshow set to full range....so I guess the problem is w/ the LUT then?

yesgrey

29th January 2009, 14:03

so I guess the problem is w/ the LUT then?
There is no problem with the LUT.
What renderer have you used? I have used VMR9 in ZoomPlayer.
How are you measuring the RGB color?
I use this (http://www.iconico.com/colorpic/) free tool.

leeperry

29th January 2009, 14:06

There is no problem with the LUT.
What renderer have you used? I have used VMR9 in ZoomPlayer.
How are you measuring the RGB color?
I use this (http://www.iconico.com/colorpic/) free tool.
HR in RGB32, I used Photofiltre to check the screenshots(free alternative to Photoshop) :
http://photofiltre.free.fr/frames_en.htm

maybe you could try in full range in HR/RGB32 w/ colorYUV(levels="tv->pc") ?

haruhiko_yamagata

29th January 2009, 15:58

Since you are working in that part of ffdshow's code, if you have the time could you add the option of using the 3D LUT? Remember that it's just loading the file in memory and then map the YCbCr or RGB data through it... The 3D LUT final goal would be a complete custumization of the output to match exactly the user's display, and the new YV12 algorythm will help increasing the quality!;)
Well, if I have time.
We can use 3D LUT in AviSynth filter in ffdshow. For now, it's good enough for advanced users who can control 3D LUT.

yesgrey

29th January 2009, 16:32

Well, if I have time.
We can use 3D LUT in AviSynth filter in ffdshow. For now, it's good enough for advanced users who can control 3D LUT.
Yes, you're right. My request only makes sense if it would be faster using the 3D LUT directly inside ffdshow than using it via Avisynth filter in ffdshow. Do you think it would be faster, or would it be the same speed? If it would be the same speed, I think then we should forget about it and keep it the way it is, and use your time in improving other stuff...;)

yesgrey

29th January 2009, 16:41

maybe you could try in full range in HR/RGB32 w/ colorYUV(levels="tv->pc") ?
It's a ColorYUV problem. With it I get RGB[0,0,0] with the 3D LUT and with ffdshow. If you want accurate colors, do not use ColorYUV, or report the problem in Avisynth forum.

leeperry

29th January 2009, 17:12

It's a ColorYUV problem. With it I get RGB[0,0,0] with the 3D LUT and with ffdshow. If you want accurate colors, do not use ColorYUV, or report the problem in Avisynth forum.
I think I mixed the LUT's http://www.image-load.eu/out.php/i142320_slap.gif
I'll try again and PM you if required ;)

mark0077

29th January 2009, 17:55

Guys, will we have a new yuy2 => rgb32hq coming to compliment the excellent yv12 => rgb32hq?

Leak

29th January 2009, 18:35

In the image comparison you linked to is your new algorithm the one at the bottom of the comparison ("YV12 + Chroma Upscampler")?
I assume that's YV12 plus my "YV12 Chroma Upsampling" shader for MPC HC.

But that one is actually meant to be used with something that looks like the RGB32 sample in that picture, if you use it on something like the YV12 sample it'll just blur the chroma - not that this must be a bad thing, mind you...

np: New Order - Confusion (Power, Corruption & Lies Extras)

29th January 2009, 19:06

Please wait a week or two, I'll add some more color spaces support
In such case, I want to request one feature - add to ffdshow ability to convert resulting picture from sRGB to Adobe RGB (Wide Gamut)
Short description of problem (why this option may be added): on wide gamut displays, when you play videos (which are sRGB), you have oversaturated colors on the picture.
More detailed explanation:
Working with color and software, the graphics card and monitor both operate not with physical measurement units but with some formal numbers, from 0 to 255 for each of the basic colors. For example, {0; 255; 0} is not green, it is just a set of numbers. It will become green if we assume that this set corresponds to the monitor’s showing a green subpixel.

So, the problem is that a green subpixel has different color on an ordinary monitor and on an extended-gamut monitor. It is greener on the latter. That is, it is purer, more saturated. If you put two such monitors next to each other and display the color {0; 255; 0} on both, you will see a pure green on the extended-gamut monitor and a green with a noticeable yellowish hue on the ordinary monitor.
...
As a result, monitors with an extended color gamut – which is extended relative to the standard sRGB gamut – will distort colors when displaying sRGB-oriented pictures prepared in sRGB-oriented software that does not know anything about non-sRGB monitors. The monitor will just stretch the sRGB-oriented picture out to fit its own gamut. Not only the pure colors, but also halftones will shift. The only exception is white and gray which are going to look correctly on any monitor unless the monitor is set up badly.
Source (http://www.xbitlabs.com/articles/monitors/display/samsung-sm-xl24-xl30_2.html#sect0)
I've searched in the Web for color space conversion samples, and find two sites, which can provide necessary functionality
http://www.color.org/sampleicc.xalter
http://www.littlecms.com/
Thanks! :)

gonwk

29th January 2009, 20:30

Hi folks,

Total newbie ... I was reading CLSID's 1st page pointer that it does not matter what version of FFDSHOW I should use ...

I have T5750 and ATI HD2600 card and my OS is Vista Home Prem., 64-bit ...

So I decided to try clsid r2639 ... my last version I forget what it was ... but I notice in this new version ... 3 of the file sizes are much smaller than my old version ... "ff_kernelDeint.dll" & "ffdshow.ax" & "libavcodec.dll".

Q1: Should I use the ICL version!?!?

Q2: When using DVDShrink ... the ffdshow Video & Audio icons pop-up in my Tray Bar ... is Shrink using FFDSHOW for Transcoding then?

Q3: I have a Greenish Color in my Preview Window ... which I fixed changing my DirectX Video Renderer in Shrink ... is there a fix with FFDSHOW or some other Codecs!?!?

Thanks,

G!:)

jmartinr

29th January 2009, 20:38

Current ffdshow (HQ) and AviSynth's YUY2->RGB conversion use that algorithm. It's not perfect, it has an issue like this (http://img131.imageshack.us/my.php?image=comparisonzoomxr4.png).

What about my algorithm :D

AviSynth's YV12->YUY2 converter does this vertically, but it has limitation of output bit depth (naturally 8bit).
My implementation output 10bit vertical 75:25 averaging, 12 bit horizontal 75:25 averaging, other calculations are more than 10bit.

Is this conversion not a sort of resize, giving lots of different possible methods?

Jeremy Duncan

29th January 2009, 20:44

understand you are talking about RGB?

I know a Secret about RGB and I will tell it to you now.
- If you open a "Gradient Ramp", you can actually see if the RGB range is good or not!

In the ffdshow version I'm using: 2547. There is a difference in quality depending on if I use full range or standard, in the RGB conversion tab.
This is using bt.601, and output RGB32, high quality yv12 to RGB conversion.

I have tested the same gradient ramp on powerdvd ultra and the result was a better looking gradient ramp, and the ps3 gives a better esult as well than the ffdshow version I'm using.

So, you need to use a gradient ramp to see the difference.
I will now show you what a gradient ramp is, in case you don't know already. :)

http://img90.imageshack.us/img90/8723/gradientrampfullrangezy0.th.png (http://img90.imageshack.us/my.php?image=gradientrampfullrangezy0.png)

clsid

29th January 2009, 21:20

yesgrey

29th January 2009, 23:49

In such case, I want to request one feature - add to ffdshow ability to convert resulting picture from sRGB to Adobe RGB (Wide Gamut)
Have you looked here (http://forum.doom9.org/showthread.php?t=139389)? That's what we are talking about...;) and it's alreading working in ffdshow.

30th January 2009, 00:28

Have you looked here (http://forum.doom9.org/showthread.php?t=139389)?
No, I'll take a quick look and didn't find anything about wide gamut or Adobe RGB, but I'll read fully it tomorrow
and it's alreading working in ffdshow.
With Avisynth, yes? :rolleyes: I don't use Avisynth and wish that ffdshow do that without additional software :)

yesgrey

30th January 2009, 01:10

No, I'll take a quick look and didn't find anything about wide gamut or Adobe RGB
Was added in the new version released today, v1.7. I also already included it in my program for creating the 3D LUTs

With Avisynth, yes? :rolleyes: I don't use Avisynth and wish that ffdshow do that without additional software :)
Yes. Well, if you don't want to use Avisynth then you'll have to wait someone who will do it, which I think it's not a priprity, since we already have a working solution...
You just need to install Avisynth in your machine and use two lines in ffdshow's Avisynth filter.
Doing it in ffdshow will be a lot more work than this for one of the developers... and I think it's not fair asking ffdshow's developers to spend their time with something that is already working...;)

gonwk

30th January 2009, 01:50

1) The version you have now is fine.
2) If you see the icons, then it is using ffdshow for decoding. If you don't want that, put dvdschrink on the blacklist (ffdshow configuration -> directshow control).
3) That is a renderer bug.

Hi clsid,

THANKS for your reply!

G!:)

madshi

30th January 2009, 09:22

I assume that's YV12 plus my "YV12 Chroma Upsampling" shader for MPC HC.

But that one is actually meant to be used with something that looks like the RGB32 sample in that picture, if you use it on something like the YV12 sample it'll just blur the chroma - not that this must be a bad thing, mind you...
Not sure which quality is better, to be honest. The "YV12 Chroma Upsampling" image looks cleanest to me, but the red color seems to be slightly less saturated compared to the other 3 images.

( the comparison image I'm talking about (http://img131.imageshack.us/my.php?image=comparisonzoomxr4.png) )

haruhiko_yamagata

30th January 2009, 11:57

Yes, you're right. My request only makes sense if it would be faster using the 3D LUT directly inside ffdshow than using it via Avisynth filter in ffdshow. Do you think it would be faster, or would it be the same speed? If it would be the same speed, I think then we should forget about it and keep it the way it is, and use your time in improving other stuff...;)
On Core2 Quad 9550, premiere-paff.ts (H.264 1920x1080), yadif double framerate
Yadif in ffdshow (SSE2, SSSE3 and multithreading disabled): 31.0fps
Yadif in AviSynth: 27.1fps

The performance boost may not be negligible. Patches are welcome.