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

12th January 2009, 20:10

To be consistent with other DS filters I prefer:

Input levels
* TV [RGB: 16-235] (Almost all video formats)
* PC [RGB: 0-255] (Fraps video)
* Custom

Output levels
* PC [RGB: 0-255] (VGA/DVI/HDMI output)
* TV [RGB: 16-235] (S-VIDEO/Component output)
* Custom
For me, that scheme is better than other. My opinion - add Auto to both Input and Output, if possible, and move descriptions from () to tooltips, as someone mentioned earlier, and there give more detailed information about different modes. Also, make this dialog horizontal, so:

Input levels Output levels
* Auto * Auto
* TV [RGB: 16-235] * TV [RGB: 16-235]
* PC [RGB: 0-255] * PC [RGB: 0-255]
* Custom * Custom

tetsuo55

12th January 2009, 20:26

Everyone can get what they want.

There only has to be a decision on what is displayed in the screen and what is hidden in the tooltip.

Still i vote for using accurate descriptions even for the non technical ones.

Display:
Reference Black/White
* Auto
* TV [RGB: 16-235]
* PC [RGB: 0-255]
* Custom

Tooltip:
Luminance levels (and a small explenation)
* (explains how it works)
* Studio RGB (followed by the accurate math)
* Computer/Full RGB (followed by the accurate math)
* (explains how it works)

It's time for haruhiko_yamagata to decide :)

clsid

12th January 2009, 20:57

I dislike the title "Reference Black/White". The values concern luma ranges, not colors.

But I fear this is a never-ending discussion.

tetsuo55

12th January 2009, 21:51

I dislike the title "Reference Black/White". The values concern luma ranges, not colors.

But I fear this is a never-ending discussion.

Luma is the difference between black and white so the naming is accurate.

But i agree that we end users will never agree.

Leak

12th January 2009, 22:32

Luma is the difference between black and white so the naming is accurate.
Luma is simply the brightness channel, but it's inherently not about color - it's as much the same difference between black and bright red, green or blue as it is between black and white...

Octo-puss

12th January 2009, 22:43

I just moved onto 64bit Vista and am curious how is the development of 64bit FFDS. Why is it considered unstable and experimental?

Inventive Software

12th January 2009, 22:46

This whole issue with luma levels has confused me no end, such that I reckon for the videophiles (yesgrey3 I'm looking squarely with no trapezium bend at you) we should cater for their picky needs, and for everyone else hide the option away and pick a default. Is that suitable or not?

clsid

12th January 2009, 23:22

I just moved onto 64bit Vista and am curious how is the development of 64bit FFDS. Why is it considered unstable and experimental?Because it is unstable. Mainly due to compiler bugs.

Octo-puss

12th January 2009, 23:28

damn :(
So I am better off with internal filters of MPC-HC then?

Compiler errors sounds like potential long waiting for authors to fix stuff...

clsid

12th January 2009, 23:42

MPC-HC internal filters have the same issues. ffdshow x64 works reasonably well at this moment.

But you should use the 32-bit MPC and ffdshow. Those work perfectly fine on Vista x64. In general, all 32-bit software runs fine on it.

tetsuo55

12th January 2009, 23:50

Luma is simply the brightness channel, but it's inherently not about color - it's as much the same difference between black and bright red, green or blue as it is between black and white...

The way i understand it is:
-Black represents the absence of light
-White represents the brightness of light

This is why its called reference white and reference black

PS black/White are not colors, using only the luma information and discarding chroma(colors) will give you a black and white image

Octo-puss

12th January 2009, 23:53

The question is why should I :)
But well, it might be that 64bit brings no advantages over 32 in such cases.

STaRGaZeR

13th January 2009, 02:54

Congrats for your recent optimizations Haruhiko, x64 working perfectly now and x86 faster than before! http://www.xtremesystems.org/forums/images/smilies/clap.gif

avivahl

13th January 2009, 03:33

yesgrey

13th January 2009, 03:42

Look, haruhiko asked my opinion, and it's what I have done. I'm just trying to help clarifying all this stuff, nothing more.
I know this is a bit confusing, and the other applications do not help either, with not very clear labels.
If you have the curiosity to learn more about this subject, read Charles Poynton's colorfaq about it. It was what I did a few times back, when I did not understood nothing of this.
Maybe I still do not understand...;)

Thunderbolt8

13th January 2009, 03:54

is normal ffdshow now faster than ffdshow-mt? got with my c2d 47dfps with normal rev. 2614 and with -mt rev. 2615 44dfps, but I have 80fps more with -mt than with normal ffdshow. which value is more important now, fps or dfps?
and whats the difference comapred to the sse_icl build again? they seem to be ~1fps slower than the non sse_icl versions

btw. when switching between the normal and -mt version here I get that nasty computer restart message, because explorer.exe wasnt added to the blocklist.

Snowknight26

13th January 2009, 05:26

dfps, which I'm guessing is displayed fps. Also, if I remember correctly, SSE ICL10 builds were built for optimizations for AMD processors, presumably with -arch:SSE.

cyberbeing

13th January 2009, 06:36

Thunderbolt8, if ffdshow-mt threading isn't working (very slow), I found that completely uninstalling ffdshow and then re-installing ffdshow-mt with settings reset fixed it for me.

Since it's been a week and nobody replied to my post, I guess it was somehow overlooked in this fast moving thread. Does anybody know the answer to my question(s), particularly the one on the bottom?
Could someone add an option to FFDshow to override the output colorspace (on launch) to whatever the built-in Avisynth is outputting and just pass it through to the renderer unmolested? Is there already some global option for this that I am missing?

Currently FFDshow seems to ignore the Avisynth output colorspace and does color conversions and level fixes (for RGB), seemingly based on the input colorspace, to the lowest common denominator colorspace selected in the output panel.

As a separate, somewhat related question, does FFDshow currently take the built-in Avisynth output colorspace into account when it does its own output colorspace conversions?

haruhiko_yamagata

13th January 2009, 11:12

Could someone add an option to FFDshow to override the output colorspace (on launch) to whatever the built-in Avisynth is outputting and just pass it through to the renderer unmolested? Is there already some global option for this that I am missing?

Currently FFDshow seems to ignore the Avisynth output colorspace and does color conversions and level fixes (for RGB), seemingly based on the input colorspace, to the lowest common denominator colorspace selected in the output panel.

As a separate, somewhat related question, does FFDshow currently take the built-in Avisynth output colorspace into account when it does its own output colorspace conversions?This is difficult. ffdshow does not know the output color space of the script on initialization.
Of course ffdshow knows it after processing the first image, it's too late. Video renderers usually do not accept the change of color space during the playback.

bur

13th January 2009, 12:14

It's not really clear in the FAQ that the mt builds are faster. I read the FAQ and to me it sounded like all ffdshow-tryout builds had some mt features, like x264 decoding. But it doesn't say what parts of the mt build is multithreaded that isn't in the common builds.

Anyway, if you say some people did benchmarks and it's faster and generally stable, I guess I'll use it anyway. :)

haruhiko_yamagata

13th January 2009, 16:20

is normal ffdshow now faster than ffdshow-mt? got with my c2d 47dfps with normal rev. 2614 and with -mt rev. 2615 44dfps, but I have 80fps more with -mt than with normal ffdshow. which value is more important now, fps or dfps?
and whats the difference comapred to the sse_icl build again? they seem to be ~1fps slower than the non sse_icl versions

It depends on the sample. mt is sometimes a bit slower than normal one on dual core. Because normal ffdshow has some multithreading.
Normal ffdshow is sometimes fast if its multithreading fits the sample, while ffmpeg-mt has stable performance for all samples.
In most cases mt is faster. On quad core, mt is almost always faster.

clsid

13th January 2009, 16:34

Both x86 and x64 rev2614 (compiled by XvidVideo.ru) are working perfectly here on Vista x64. I don't really know why you guys are saying the x64 build is unstable. I use it daily w/ tons of videos (and subtitles; using the built-in subtitle filter) and it's working wonderfully. Good job guys.
AMR audio decoding is broken. Libavcodec vorbis is broken. *

* Last time I checked. Results may vary depending on the MinGW64 build used for compilation.

STaRGaZeR

13th January 2009, 17:45

AMR audio decoding is broken. Libavcodec vorbis is broken. *

Libavcodec AC3 and E-AC3 are broken too.

I'm surprised, libavcodec DTS didn't work before but now it works like a charm (xvidvideo.ru rev2614). Apart from these issues ffdshow64 is now as stable and functional as ffdshow x86 for me. Granted there are some problems with the filters, but I've not encountered any so far.

tetsuox

13th January 2009, 18:16

Libavcodec vorbis is broken.

Tremor in ffdshow64 works fine for Vorbis though, at least for stereo sources.

qyot27

13th January 2009, 21:07

I did a search for this but couldn't find anything. But there seems to be an issue when trying to use ffdshow in conjunction with x264 - something in both the video decoder and VFW decoder causes x264 to not work unless the full path to x264.exe is specified.

The thread I started about this issue (and where I ultimately came to the conclusion that ffdshow was causing it) is here:
http://forum.doom9.org/showthread.php?t=144215

If there's a way of getting this to work correctly, I'd appreciate it.

cyberbeing

13th January 2009, 22:34

This is difficult. ffdshow does not know the output color space of the script on initialization.
Of course ffdshow knows it after processing the first image, it's too late. Video renderers usually do not accept the change of color space during the playback.
Anyway to add drop-down box override to the avisynth page or output page to tell ffdshow to always expect a certain colorspace from avisynth and a checkbox to not preform any colorspace conversions?

i.e. Expected Avisynth Output Colorspace Override [Have a drop-down box] (requires video to be reopened)
+
i.e. Use Expected Avisynth Output Colorspace Override as Output Colorspace [checkbox]. (all output colorspace options would be grayed out when this is checked, if avisynth is active in avisynth page)

I have no idea how difficult this would be to implement, nor do I have any coding knowledge to make a patch myself.

Video is opened

If built-in avisynth is active on launch, it reads the Expected Avisynth Output Colorspace value (if it exists).

If value exists, ffdshow overrides the colorspace with this value to use as a basis for color space conversions.

If Use Expected Avisynth Output Colorspace Override as Output Colorspace is true, do not preform any output colorspace conversions and just set correct colorspace flag when outputting to the renderer (or next item in the graph).

This way when a video is first loaded and avisynth is active, it would automatically assume the output colorspace is what the override specifies (without checking if it is correct). It would then use the override value as basis for output colorspace conversions, unless the other option is checked to not preform any output colorspace modifications.

I hope this makes sense.

_xxl

14th January 2009, 01:57

Libavcodec AC3 and E-AC3 are broken too.
MinGW64 GCC build? If so then all asm for Win64 should be disabled.

_xxl

14th January 2009, 02:01

STaRGaZeR

14th January 2009, 04:00

MinGW64 GCC build? If so then all asm for Win64 should be disabled.

Yep: http://www.xvidvideo.ru/content/view/573/5/ (libavcodec.dll - GCC 4.4.0 x86_64 version)

Except AMR, Vorbis, AC3 and E-AC3 all other libavcodec audio decoders seem to work fine.

qyot27

14th January 2009, 05:52

ffdshow doesn't use x264.exe
I know that. What I'm talking about is that ffdshow is acting as the decoder for the video (which is ffvhuff) that I'm serving to x264, and thereby causing x264 to act weird (specifically, it ignores relative paths to the exe, even if the exe is in the directory I've cd-ed to; using the absolute path works without a hitch, but it's thoroughly redundant and unnecessary because I have x264 residing in my system path).

AVISource and DirectShowSource both cause this, but FFmpegSource - because it doesn't rely on VFW or DirectShow and hence doesn't call ffdshow - is perfectly fine. As is Lagarith (when I use AVISource, at least). From all of that, the only conclusion I could find is that something with ffdshow - although I don't know exactly what - is the root of the issue. But whatever it is, serving video with DirectShowSource to xvid_encraw works fine, just not x264.

I'm using clsid's generic build of rev2602 - although I can only assume the problems I've been having for the past month or month and a half (at least; I'm fairly sure at the beginning of November things worked fine, but I didn't do any encoding between then and sometime in December) also arose from builds during that span of time as well.

halsboss

14th January 2009, 10:02

dfps, which I'm guessing is displayed fps. Also, if I remember correctly, SSE ICL10 builds were built for optimizations for AMD processors, presumably with -arch:SSE.

I dear, now I'm confused. I have an Intel Q9450 and an Intel Q6600 - should I be using clsid's ICL10 (sse) build or the generic build ?

fastplayer

14th January 2009, 10:28

I dear, now I'm confused. I have an Intel Q9450 and an Intel Q6600 - should I be using clsid's ICL10 (sse) build or the generic build ?
http://ffdshow-tryout.wiki.sourceforge.net/FAQ#performance

halsboss

14th January 2009, 13:13

leeperry

14th January 2009, 14:17

OK, thanks. Almost no performance difference according to that, certainly nothing about AMD-specificity for the ICL10 builds. On that basis I may as well use clsid's generic builds since they appear to be slightly more up to date usually.
this is an old outdated comparison.
as soon as you use sharpening or audio filters, the ICL10 versions are much faster(I got an o/c quad)
I've posted comparisons in the previous pages ;)

when I do frame by frame playback in KMPlayer with the ICL10 builds, it almost works in realtime....with the generic builds, it's much slower.

halsboss

15th January 2009, 04:46

Oh. Back to ICL10, then :)

juanchu

15th January 2009, 12:53

I'm having a problem with FFDShow Video Decoder. I've made a MKA file which contains a MP3 track and a JPG attachment. If I load it without FFDShow Raw Video mode activated, the JPG is shown well in any player, as MPC-HC, or WMP, as if it were a video track. However, with FFDShow Video Decoder with the Raw Video mode activated, the JPG is shown upside down! Have I forgotten something, or is this a bug in FFDShow? I'm using Haali Media Splitter, and FFDShow Prebeta 6 revision 2527. Other video tracks don't have this problem, and are shown correctly.

Thank you so much for your help.

clsid

15th January 2009, 15:56

Upload the file for us please.

juanchu

16th January 2009, 00:37

Here is:

http://www.megaupload.com/es/?d=ZRLRENUB

The file is a MKA, with a FLAC audio track and Matroska logo in JPG. As I said, if I activate "Raw Video" in FFDShow Video Decoder, the JPG is upside down. However, without that option activated, the JPG is shown fine. It happens with every JPG attached in a MKA file.

qyot27

16th January 2009, 20:59

As I posted in my thread on this relative paths issue, I've been able to narrow it down to a gap between November 14th and November 23rd, but not to the specific revision, I just know that:

ffdshow_rev2322_20081114_clsid.exe works fine
ffdshow_rev2347_20081123_clsid.exe displays the relative paths issue

Could this have been something that changed in ffmpeg itself, rather than in ffdshow? Is there some way I can log what's going on with ffdshow, AviSynth, x264, and Windows in a coherent way that can point to what's happening to cause the issue?

ikarad

16th January 2009, 21:18

lpcm HD (from blu-ray) soundtrack doesn'y work with ffdshow audio
When I see a blu-ray which has mlp and lpcm soundtrack with mpc-hc and ffdshow audio, lpcm HD soundtrack are not available with ffdshow audio selected.
To listen lpcm HD (lpcm from blu-ray) soundtrack, I must disable ffdshow audio because MPc-HC decode very well lpcm Hd soundtrack but not ffdshow.

up! thanks

jos99

17th January 2009, 00:04

Sure, here is a 10MB sample of BBC HD (http://rapidshare.com/files/180886722/01-08_00-18-38_BBC_HD__NAR__BBC_HD_Preview.ts), a 5MB sample of Luxe HD (http://rapidshare.com/files/180886723/01-08_00-33-37_Luxe_TV_HD_Shopping.ts). The line of distortion is slightly wider in BBC HD than Luxe.
BBC's one works at rev 2598.
Luxe TV's sample, this is more difficult.
I guess MPC's splitter fails to parse access units (or send two or more access units at a time).
In that case, ffdshow has to parse access units to use ffmpeg-mt.
Using mt 2624 ic10 build both these problems are gone.:thanks:

anyone23

17th January 2009, 16:06

Every time I use libavcodec to decode one of my xvid files i get washed out colors.

Screen: http://img218.imageshack.us/img218/7529/libavcodecwj6.th.png (http://img218.imageshack.us/my.php?image=libavcodecwj6.png)

Sample from the source: http://www.megaupload.com/de/?d=IIZHGT1W

Decoding with "Xvid" works fine.

2 Pics for comparison from another file (not frame accurate)

Decoding with Xvid: http://img218.imageshack.us/img218/1213/xvidmi1.th.png (http://img218.imageshack.us/my.php?image=xvidmi1.png)

Decoding with libav: http://img218.imageshack.us/img218/8763/libavscrubshi3.th.png (http://img218.imageshack.us/my.php?image=libavscrubshi3.png)

Is this my fault or a bug in ffdshow/libavcodec?

haruhiko_yamagata

18th January 2009, 08:07

I agree with this. It was haruhiko who have implemented the current method, so I think the last word should be his. I think he has enough information here already to decide which would be the better option.
Sorry for late reply and than you for your help.
I'll implement some dialog when I get more time.
Auto is difficult except some clear cases such as jpeg and frap.

haruhiko_yamagata

18th January 2009, 09:17

[deleted]
oops, failed in testing

haruhiko_yamagata

18th January 2009, 09:23

up! thanksCan I have a sample?
Though I'm not sure if I have time to implement.

haruhiko_yamagata

18th January 2009, 09:42

ikarad

18th January 2009, 10:32

Can I have a sample?
Though I'm not sure if I have time to implement.

here the example
http://www.zshare.net/info.html?54307328-f4cf1e029ba268fd6fc1e3907e3ab1dc

yesgrey

18th January 2009, 11:23

Sorry for late reply
No problem.;)
I'll implement some dialog when I get more time.
Auto is difficult except some clear cases such as jpeg and frap.
Take your time. It's just a cosmetic thing, so when you have more time is good enough.
I think with the preset autoload conditions we can perform some kind of Auto... I have done it in my setup.

ikarad

18th January 2009, 12:32

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

here an example of this problem
http://www.zshare.net/info.html?54310400-a553b6c77ff2d34994f4f3bc51b23de2

my config:
Q6600
xp sp3
geforce gtx280 180.48
MPC-HC 1.2.976

vmr9 renderless without direct3d and dxva option (i use ffdshow video decoder)
ffdshow audio 2624
xfi titanium last driver

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.