ffdshow tryouts project: Discussion & Development

[swalker]

Originally Posted by clsid

autocrop has been broken for a long time

Can it (I'd suggest along with anything else that is broken/severely malfunctioning if nobody is working on it presently or recently) get disabled or removed then since I doubt it's a priority with the limited amount of developers ffdshow has at the moment?

Relnoting what is or isn't functional would be nice, well if ffdshow actually had release notes, I suppose a wiki page and/or changelog item would have to suffice.

[haruhiko_yamagata]

Originally Posted by BatKnight

How does it work? Is it like the DeBand filter?
Is it supposed to give better picture quality when checked or the other way around?

Bat

The calculation of YCbCr->RGB conversion is done in 11bit or higher, and the output is dithered to 8bit.
In the end of calculation, RGB values are 12bit for each. Dithering is done by adding 4bit single dice random noise (different values for R,G,B). Finally, the values are shifted to the right by 4 bits.
Thus 100.8125 is mapped to 101 in 81.25% probability and to 100 in 18.75%.

The objective is the same as deband, but the method is different. I actually don't know how deband works though.
The picture quality is better with dithering checked.

Thanks to madTestPatternSource by madshi, the image comparison is easy.

grayramp.ytp none dithered


grayramp.ytp dithered


colors.ytp none dithered


colors.ytp dithered


Hope you can find any real world videos that you can perceive the visual change.

[haruhiko_yamagata]

Originally Posted by mark0077

haruhiko, apologies for 3 bugs I posted a few posts ago, I found all reproducable without ffdshow in the chain.

no problem.

Glad to see dithering in rgb conversion, just wondering could I ask have you thought about adding the workaround for DVD's when resizing. You may remember the problem I and others have had, where some DVD's show the wrong aspect ratio when passing through ffdshow's resize?

Did you try this?

Also just while on the topic of resize, I found a bug (not a critical one) within "Border" section of Resize. After setting one of the dividing borders, for example "Horizontal" to Left 100, Right 0, and hitting apply. Then dragging the slider for "Vertical" resets the "Horizontal" slider to centered on 50:50 again. Just strange. I want dividing borders set to right and bottom because of the way the LED backlight works on this LCD. Keeping black bars to one side or fully to top or bottom can give me blacker blacks.

Thanks.

I can't reproduce. The sliders work for me.

[mark0077]

Originally Posted by haruhiko_yamagata

no problem.

Did you try this?

I can't reproduce. The sliders work for me.

Hi Haruhiko.

Disabling mpc-hc's own aspect ratio correction seemed to do the trick. I don't think any combination of these settings should break the final aspect ratio though if all of the flags are sent and interpreted correctly.

Do you think mpc-hc doesn't interpret the flags sent by ffdshow correctly, if so I can make a bug report. Or does ffdshow not yet send the flags correctly. I would love to see the resize feature work without any manual changing of settings like this as it will only add to the manual settings to configure when setting up a machine.

Thanks for the link.

[haruhiko_yamagata]

MPC-HC expects the pixel aspect ratio in the original DVD is not changed in ffdshow. However, resize with "Process pixel aspect ratio internally" changes PAR. It's the spec of MPC-HC and ffdshow.
You could submit a report to MPC-HC. The solution would be an new API which both should implement.

[mark0077]

Ah I understand. Its like both are trying to do the same fix and neither knows whether the other has already performed the fix or not.?

I have posted a bug in mpc-hc bug tracker. Hopefully some discussion will come up with a solution.
http://sourceforge.net/tracker/?func...61&atid=854651

[ipanema]

I'm trying to connect from my own source filter to the ffdshow video decoder which has H.264/AVC enabled, but I can't seem to discover the correct media type.

The following subtype which I've not found a symbolic name for

8D2D71CB-243F-45E3-B2D8-5FD7967EC09B

seems to work well with other decoders, but EnumMatchingFilters() can't even find the ffdshow video decoder, so I guess ffdshow does not support this subtype.

This Microsoft page:

http://msdn.microsoft.com/en-us/libr...08(VS.85).aspx

says that for a "H.264 Bitstream without Start Codes" you should use MEDIASUBTYPE_AVC1. I've noticed that when Media Player Classic uses the ffdshow video decoder to play m2ts files, the input media type of the ffdshow video decoder is MEDIASUBTYPE_AVC1 and this is confirmed by the sequence-header part of the media type having no start codes.

I assume that to use MEDIASUBTYPE_AVC1 you would have to parse the whole bitstream, replacing start codes and shifting lots of data around in memory before it is sent to the ffdshow decoder. I would rather just send the data as-is (with start codes) which does work fine with other decoders.

What AVC media type (WITH start codes) works best with the ffdshow video decoder?

[leeperry]

has there been any recent change in the Avisynth filter? coz I'm getting BSOD after BSOD when I enable it

usually it simply stutters a bit and reboots the system! I can run 10 passes of IntelBurnTest and my system is not o/c.

it used to work fine, I just updated to the latest build from xvidvideo.ru, I'll try older builds...but anyway, when I disable the Avisynth filter everything works fine! using whatever KMP or MPC, HR or Overlay, Sonic 4.2 or AC3Filter, Reclock or DirectSound....I believe I've narrowed down the problem to the Avisynth filter(I use Avisynth-MT 2.57 on XP SP3)

[leeperry]

ok I'm running a 2 months old build, and everything seems to work just fine!

I can't even enable CUDA in CoreAVC(on top of the Avisynth filter) w/ the latest builds...I get a IRQL_NOT_LESS_OR_EQUAL stop msg right away.

sounds like there's been some changes in the internal buffering of ffdshow lately? anyway, w/ this old build I can get CoreAVC CUDA and Avisynth working apparently.

that's one of the numerous stop msg I got :

0x0000000A
~5
~1C
0x804DC2C5

does the adress of the instruction ring any bell? http://support.microsoft.com/kb/314063

my PC works fine(3 days of foobar in KS, 10 passes of IntelBurnTest, etc etc), just the very latest builds of ffdshow give crazy BSOD's

I'd say the problem arised in the <7 days builds.

[STaRGaZeR]

Haruhiko, corruption fixed. However I don't know why it doesn't work with 2941, when the code you reverted was like it's now.

[Inspector.Gadget]

I can't even enable CUDA in CoreAVC(on top of the Avisynth filter) w/ the latest builds...I get a IRQ_LESS_OR EQUAL stop msg right away.

I had this problem plus random lock-ups after updating to NVIDIA 185.85 drivers, by the way.

[Thunderbolt8]

in how far does yadif's frame duplication option use CPU and GPU sources (e.g. more CPU than GPU based?)

[FredThompson]

Originally Posted by haruhiko_yamagata

If it is related to rev 2666, MMXEXT and 3DNOW! may matter.
Could you uncheck them?

I assume you mean the VirtualDub CPU functions? I turned all of those off and the problem still exists for build 2954.

[Leak]

Originally Posted by Thunderbolt8

in how far does yadif's frame duplication option use CPU and GPU sources (e.g. more CPU than GPU based?)

Considering that all ffdshow uses is the CPU - all CPU, no GPU?

(Unless you consider that the renderer will have to upload twice the amount of frames to the graphics card for display, of course...)

[swalker]

Given the following from the March 10, 2009 news on http://www.ffmpeg.org/.

# AAC with ADTS support and >2x the speed of FAAD! (no HE AAC support yet)

Should the libavcodec AAC decoding choice be uncommented in the installer script and be offered along with libfaad2, noting libavcodec's lack of HE AAC support?

# AC-3 that is faster than liba52 in 5.1, up to 2x faster in stereo and also supports E-AC-3! Hence liba52 is now obsolete.

Should a default switch be made to using libavcodec for AC-3 decoding with eventual removal of liba52 if no problems are found?

Are there that many bugs/efficiency differences in each MPEG-1 audio decoder to warrant having a choice of three of them?

[tetsuo55]

I use libvacodec for everything, i have encountered no problems (any issue i find can be reproduced with the alternative codec)

I agree that we should think about moving out as many of the extra codecs as possible and focus on getting libvacodec as compatible as possible (most of the alternatives are no longer being updated)

[Thunderbolt8]

Originally Posted by Leak

Considering that all ffdshow uses is the CPU - all CPU, no GPU?

(Unless you consider that the renderer will have to upload twice the amount of frames to the graphics card for display, of course...)

is it optimized for multi core cpus?

[haruhiko_yamagata]

Originally Posted by ipanema

I'm trying to connect from my own source filter to the ffdshow video decoder which has H.264/AVC enabled, but I can't seem to discover the correct media type.

Please read
http://ffdshow-tryout.sourceforge.ne...pic.php?t=1138
You could write to the thread for more discussion.

8D2D71CB-243F-45E3-B2D8-5FD7967EC09B

What does this subtype indicate?

I assume that to use MEDIASUBTYPE_AVC1 you would have to parse the whole bitstream, replacing start codes and shifting lots of data around in memory before it is sent to the ffdshow decoder. I would rather just send the data as-is (with start codes) which does work fine with other decoders.

Yes, MPC and haali's splitter does this, as older ffdshow couldn't do without it. Current version doesn't require full access unit parsing by the splitter.

[haruhiko_yamagata]

Originally Posted by FredThompson

I assume you mean the VirtualDub CPU functions? I turned all of those off and the problem still exists for build 2954.

Nope, I mean CPU in ffdshow.
It is placed in "ffdshow (DirectShow) video decoder configuration", Info & CPU page.

[ipanema]

Thanks haruhiko.

What does this subtype 8D2D71CB-243F-45E3-B2D8-5FD7967EC09B indicate?

I don't really know. I found it mentioned a few times when searching for H.264 media types. There didn't seem to be consistent "name" for it but it does seem to work OK with other decoders. Perhaps it is just a duplication of MEDIASUBTYPE_H264.

Current version doesn't require full access unit parsing by the splitter.

That's fine. So if I use the H264 subtype instead of the AVC1 subtype then I shouldn't have to replace start codes with lengths or shift data around.

Anyway, I've managed to get the connection to the ffdshow video decoder to succeed now using either the above 8D2D... subtype or MEDIASUBTYPE_H264. But when I attempt to play I get no frames delivered for a while and then occasional decoded frames which look fine apart from a small amount of corruption.

I've concluded that the connection media type is OK, so it's likely that the way the data is being presented to the ffdshow video decoder is the problem.

As I was familiar with the Microsoft MPEG-2 Demultiplexer and it works OK with other H.264 decoders, that's what I am using to feed the ffdshow decoder. The Microsoft Demux doesn't look at the PES payload contents - it just seems to extract the video PES payload bytes from consective TS packets, concatenate them and output it in samples of 8192 bytes in length. It carries on doing this until it reaches the next frame and then starts sending a new series of 8192 byte samples. The first 8192 byte sample of a frame has a start and end stream time (but no media times) and Sync Point set; and subsequent samples have no timestamps at all and Sync Point is not set.

You mentioned in the other thread

If you use 'H264' as fourcc, ffdshow can parse access units if the stream has AU delimiter. If the stream does not have AU delimiter, please parse access units at your side.

What do you mean by a AU delimiter? Does the above description of Microsoft's demux behaviour seem to satisfy ffdshow's requirements? I think it may not because of the problems I'm having getting perfect decoded frames.