ffdshow tryouts project: Discussion & Development

[swalker]

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]

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 (http://forum.doom9.org/showthread.php?t=146203) by madshi, the image comparison is easy.

grayramp.ytp none dithered
http://ffdshow-tryout.sourceforge.net/doom9/gray_none_dithered.png

grayramp.ytp dithered
http://ffdshow-tryout.sourceforge.net/doom9/gray_dithered.png

colors.ytp none dithered
http://ffdshow-tryout.sourceforge.net/doom9/color_none_dithered.png

colors.ytp dithered
http://ffdshow-tryout.sourceforge.net/doom9/color_dithered.png

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

[haruhiko_yamagata]

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 (http://ffdshow-tryout.sourceforge.net/wiki/video:resize_aspect#example)?

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]

no problem.

Did you try this (http://ffdshow-tryout.sourceforge.net/wiki/video:resize_aspect#example)?

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=detail&aid=2793920&group_id=170561&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/library/dd757808(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]

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]

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]

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]

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.net/phpBB2/viewtopic.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]

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.

[tetsuo55]

Has anyone tried bitstreaming True-HD or DTS-HD over hdmi?

As ffdshow does not need HDCP or PAP at all it might just work...

[mark0077]

tetsuo, do you know if ffdshow decodes dts-hd ma and true-hd without downsampling?

[tetsuo55]

tetsuo, do you know if ffdshow decodes dts-hd ma and true-hd without downsampling?

i hope it does, but i currently do not have any movies with higher than 48khz tracks so i cannot be sure
So the question is

Do the DTS(-HD) and the (e-)AC-3 decoders support 24 bit and 192khz decoding with full support for all 7.1 channels? And if so does it stay that way through all of the filters until it finally gets output to the audio renderer?

What about the other audio codecs? The complete ffdshow audio path should support 32bit/192khz imho (and all decoders should be able to natively decode 32/192 where sanely possible)

[e-t172]

do you know if ffdshow decodes dts-hd ma and true-hd without downsampling?

- ffdshow does not decode DTS HD MA, just the DTS core (it's even worse than downsampling).
- ffdshow decode TrueHD without downsampling.

[mark0077]

Ah thanks alot, hopefully we will see DTS-HD MA soon ;)

[e-t172]

Ah thanks alot, hopefully we will see DTS-HD MA soon ;)

I don't think so. Sadly, there hasn't been any news on DTS-HD MA in ffdshow for what... months, years ? By the way, I don't understand why TrueHD has been implemented so quickly in libavcodec but not DTS-HD MA...

[mark0077]

Well I'm surprised in two ways, that trueHD can be decoded without always sampling down to 16bit 48khz, thought only some TMT decoders could do that, and I'm also surprised like you that dts-hd ma hasn't had a decoder yet.

[tetsuo55]

the reason is very simple, DTS-HD is far more difficult to reverse engineer, probably due to lack of publicly available information on how it works

[mark0077]

the reason is very simple, DTS-HD is far more difficult to reverse engineer, probably due to lack of publicly available information on how it works

Is there some sort of money or licence involved? I can't imagine anyone like DTS, Dolby etc coming up with something like this and not giving out information on how it works...

[tetsuo55]

Is there some sort of money or licence involved? I can't imagine anyone like DTS, Dolby etc coming up with something like this and not giving out information on how it works...

A company wishing to implement DTS decoding has to pay a license fee and probably sign a NDA contract

[therealjoeblow]

There appears to be a bug with the output framerate when playing back DVD's

All samples act the same, output is always fixed at 25fps

...

Also it appears that DTS over Spdif is not working for me anymore all of suddon (it used to work, i did not touch any of the ffdshow settings) now all i get is silence or pops.
AC3 is working as expected.

I am streaming over HDMI
Build im currently using is 2940

I had problems a few builds back with DTS over SPDIF creating a jerk (like a dropped frame) in the video every 6 seconds. I ended up using AC3Filter for DTS and it doesn't do that. My post about the issue I don't think were ever responded to. I haven't tried a recent build to see if it was fixed, but maybe someone was working on it and didn't complete the fix?

Cheers
The REAL Joe

[mark0077]

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.

DVD Aspect Ratios
haruhiko, I posted over on the mpc-hc forum and made a bug / feature request for this.

https://sourceforge.net/tracker/?func=detail&aid=2793920&group_id=170561&atid=854651

However beliyaal replied to the bug report with a comment saying "ffdshow should output the aspect ration
corresponding to the desired PAR.". I am not familiar with how par and sar work together etc but he doesn't seem to think disabling mpc-hc's "Keep Aspect Ratio" should be needed. i am eager to keep this "problem" in upper minds of you guys because I know this effects ALOT of people who are especially new to ffdshow and are trying its resize functionality with their DVD's.

DVD Menu Hang - Still some remaining problem DVD Menus
haruhiko, as promised I have provided a sample of a dvd menu that is able to make ffdshow either stall or act very slowly. In the following dvd menu from star wars episode 2, navigating into the THX tests menu can work very fast without ffdshow in evr-cp in mpc-hc (using any of the latest builds, currently 1120). With ffdshow however, navigating can be extremely slow and often take maybe 5-10 seconds to navigate from one frame to the next. I am simply decoding using libmpeg2 in ffdshow and outputting in RGB32 with no de-interlacing.

Here is the sample that illustrates the remaining problem.
http://www.megaupload.com/?d=GAY1HQAD

To reproduce: Start dvd using video_ts.ifo file and wait for initial white images and menus to pass. These were removed to reduce file size. It might take a minute. You will then see a dvd menu appearing. I have only included one menu path which illustrates the problem. Instructions to navigate through this path is below.

"DVD Main Menu" -> "Language Selection" -> "THX Optimizer Logo" -> "Audio Tests" and then back to "THX Optimizer Menu"

When doing this, move the mouse around a little bit over some of the possible options, then select the next item in the path. This usually lets me reproduce the problem easily. You will notice a large slowdown and sometimes even upto 10 or more seconds delay before you are taken to the next menu. It does not happen every time. One time it may hang and be slow, next time it will be perfect but after a couple of navigations through the menu you should eventually see the problem.

Please let me know if you can reproduce. Other than this dvd menu navigation is almost perfect now with ffdshow and is actually already better than mpc-hc on its own. Thanks.

[haruhiko_yamagata]

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.
Access unit delimiter.
code & 0xffffff1f == 0x00000109

[ipanema]

Access unit delimiter.
code & 0xffffff1f == 0x00000109

Oh right. Yes the demux always starts a new series of 8192 sized samples at a 0, 0, 0, 1, 9 sequence. So the AU code always occurs at the start of a sample.

But I still can't get correctly decoded frames from the ffdshow video apart from occasional frames with a small amount of visible corruption.

There must still be something which ffdshow H.264 decoder is expecting which it is not getting.

Below is a summary of the samples that the demux sends. The start and end times given are stream times (there are no media times set), and they are only set for the first sample of a series.


Received sample 0 (21974974ms) First sample of 1st series
Start time (0x332A48A79A)
End time (0x332A48A79B)
Sync point (1)
Preroll (0)
Discontinuity (1)
Actual data length (8192)
Type changed (0)
0 0 0 1 9 10 0 0 0 1 27 64 0 28 ad 88
11 21 48 30 41 46 85 31 90 89 10 22 4c 9c 99 22
48 82 48 d2 74 91 c4 14 c4 6d 1d 8 23 31 d8 e1
24 b9 ca 31 26 98 a1 3 79 c 53 98 71 83 b0 90
....

Received sample 1 (21974976ms)
Sync point (0)
Preroll (0)
Discontinuity (0)
Actual data length (8192)
Type changed (0)
33 a3 8a 3e 80 39 8 17 1b aa fe bc 24 96 3a 5a
f5 17 62 10 f2 60 5b 9 69 0 5a 52 19 c2 e2 fe
4c 58 d1 a6 cb 2 e8 3c 28 eb 12 0 fa 5 b2 58
....

More samples similar to sample 1.....

Received sample 15 (21974986ms) Final sample of series
Sync point (0)
Preroll (0)
Discontinuity (0)
Actual data length (766)
Type changed (0)
9f 27 c5 3d b6 3c 6c 28 8d 3 41 7c 3a b3 2d f3
28 4e a9 aa 17 49 62 5b 4b 92 17 ff be dc d0 8a
6d 27 47 22 31 d0 2f 19 3 f0 b4 bc c2 53 eb e8
....

Received sample 16 (21974987ms) First sample of 2nd series
Start time (0x332A3E78D5)
End time (0x332A3E78D6)
Sync point (1)
Preroll (0)
Discontinuity (0)
Actual data length (4303)
Type changed (0)
0 0 0 1 9 50 0 0 0 1 28 ea 43 ce 20 92
14 83 8 51 a1 42 c6 14 2a 44 12 4c 85 c8 59 a
24 88 54 d2 74 91 c4 14 c4 6d 1d 8 23 21 ca 38
49 2e 72 8c 49 a2 8a 30 de 43 14 e6 18 60 fc 20
....

Received sample 17 (21974988ms) First sample of 3rd series
Start time (0x332A439038)
End time (0x332A439039)
Sync point (1)
Preroll (0)
Discontinuity (0)
Actual data length (8192)
Type changed (0)
0 0 0 1 9 50 0 0 0 1 6 1 9 0 4 0
6c 68 0 0 3 0 1 80 0 0 0 1 1 9e 37 a2
33 ff d8 e3 9b e1 b1 dc c4 4c 70 18 16 e7 a2 2
....

Received sample 18 (21974988ms)
Sync point (0)
Preroll (0)
Discontinuity (0)
Actual data length (533)
Type changed (0)
e1 26 56 77 2c e0 f 59 35 aa 0 31 4c f1 2b 51
fc 24 9a ce 80 48 8b 0 71 a4 a6 80 2f 98 4f 24
8d a5 2b 7b 5a 10 8a 6a ec 3b 1b 53 ec 15 8e 37
....

Received sample 19 (21974989ms) First sample of 4th series
Start time (0x332A52D660)
End time (0x332A52D661)
Sync point (1)
Preroll (0)
Discontinuity (0)
Actual data length (8192)
Type changed (0)
0 0 0 1 9 30 0 0 0 1 6 1 9 0 6 10
6c 68 0 0 3 0 1 80 0 0 0 1 21 9a 31 4
77 d1 25 71 ad b6 a2 c5 ff af a1 46 b5 63 8d ef
9c 66 e8 fc ed b5 ce 67 e3 7c 80 61 f9 4f 17 c8
....

And so on ..................


Other AVC decoders seem happy with this.

Is there anything in this formatting which the ffdshow H.264 might not like?

[haruhiko_yamagata]

I couldn't find anything wrong.

I can get working filter graph "TS File Source"->Microsoft MPEG-2 Demultiplexer->ffdshow->video renderer in graphedit.exe. It should basically be OK with Microsoft's MPEG-2 Demultiplexer.

Before rev 2955, you had to call IPin::NewSegment. Please try the latest. (Rev 2955 available here (http://www.xvidvideo.ru/content/category/1/4/5/)).
There may be other compatibility issues...

[tetsuo55]

The ffmpeg links to SVN in the start post no longer work, it looks like the entire SVN was deleted

[Leak]

The ffmpeg links to SVN in the start post no longer work, it looks like the entire SVN was deleted
It's svn://svn.ffmpeg.org/ffmpeg/trunk according to the ffmpeg website - i.e. directly using SVN, not through HTTP.

Looks more like they threw out the apache SVN modules and went to serving SVN directly - actually, it looks more like they've thrown out Apache wholly and replaced it with lighttpd.

np: Kettel - Whom (Re: Through Friendly Waters)

[clsid]

Their SVN web-interface is simply not activated anymore since they moved to a different server. I have removed the links.

[Reimar]

Their SVN web-interface is simply not activated anymore since they moved to a different server. I have removed the links.

That's not quite accurate. The web interface was shut down because it was buggy in ways that caused trouble for the server. It was supposed to go live again, but I am not up-to-date on that. This has nothing to do with a server move.
While you're at it, would you mind changing ffmpeg.mplayerhq.hu to ffmpeg.org, the later is the official domain nowadays?
(Also, Apache never ran on the server, and at no time was SVN available over http for FFmpeg. The git repository might be available via http though).

[clsid]

With web-interface I meant the ViewVC interface, like we have for ffdshow.
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/

git repo is indeed viewable online. For those interested here is the link:
http://git.ffmpeg.org/?p=ffmpeg;a=shortlog

[Casshern]

I can confirm this. I switched to AC3 Filter for outputting DTS (and the DTS core) over sp/dif. Ffdshow instroduces way to much jitter leading to packt drops/repeats in Reclock. This started about a year ago. Mpc hcs internal decoder has the same probs as ffdshow (does not matter whether libdts or libav is used). 2956 still has the bug.
I had problems a few builds back with DTS over SPDIF creating a jerk (like a dropped frame) in the video every 6 seconds. I ended up using AC3Filter for DTS and it doesn't do that. My post about the issue I don't think were ever responded to. I haven't tried a recent build to see if it was fixed, but maybe someone was working on it and didn't complete the fix?

Cheers
The REAL Joe

[haruhiko_yamagata]

DVD Menu Hang - Still some remaining problem DVD Menus
haruhiko, as promised I have provided a sample of a dvd menu that is able to make ffdshow either stall or act very slowly. In the following dvd menu from star wars episode 2, navigating into the THX tests menu can work very fast without ffdshow in evr-cp in mpc-hc (using any of the latest builds, currently 1120). With ffdshow however, navigating can be extremely slow and often take maybe 5-10 seconds to navigate from one frame to the next. I am simply decoding using libmpeg2 in ffdshow and outputting in RGB32 with no de-interlacing.

Here is the sample that illustrates the remaining problem.
http://www.megaupload.com/?d=GAY1HQAD

To reproduce: Start dvd using video_ts.ifo file and wait for initial white images and menus to pass. These were removed to reduce file size. It might take a minute. You will then see a dvd menu appearing. I have only included one menu path which illustrates the problem. Instructions to navigate through this path is below.

"DVD Main Menu" -> "Language Selection" -> "THX Optimizer Logo" -> "Audio Tests" and then back to "THX Optimizer Menu"

When doing this, move the mouse around a little bit over some of the possible options, then select the next item in the path. This usually lets me reproduce the problem easily. You will notice a large slowdown and sometimes even upto 10 or more seconds delay before you are taken to the next menu. It does not happen every time. One time it may hang and be slow, next time it will be perfect but after a couple of navigations through the menu you should eventually see the problem.

Please let me know if you can reproduce. Other than this dvd menu navigation is almost perfect now with ffdshow and is actually already better than mpc-hc on its own. Thanks.
It works for me. The highlight may not follow mouse cursor just after moving to a new page, but if I move mouse again, it responds.
libavcodec doesn't work for that sample. Though it may be due to editing, libmpeg2 seems to be more stable for such streams.

[ipanema]

Please try the latest. (Rev 2955)

I installed rev 2955 (was previously using the latest stable version dated December 2008), and it does behave differently. I seem to get more frames being displayed but there is extreme corruption - lots of pixelation and grey areas, but with small areas of perfect image.

I can get working filter graph "TS File Source"->Microsoft MPEG-2 Demultiplexer->ffdshow->video renderer in graphedit.exe. It should basically be OK with Microsoft's MPEG-2 Demultiplexer.

When I eventually managed to get a connection to ffdshow video decoder in Graphedit it played for a duration much shorter than the file and the renderer window stayed black.

I assumed this might be because there isn't a mechanism in Graphedit for setting the exact demux output pin media type (with the SPS and PPS).

I also tried TS File Source v2.2.0.7 in Graphedit but couldn't get a connection between the demux and ffdshow filter at all. Strangely the TS File Source property page doesn't show any PID info for m2ts files.

Were you using a m2ts file as the source? Also what settings did you use the the GUI properties page for the demux video output pin?

[mark0077]

It works for me. The highlight may not follow mouse cursor just after moving to a new page, but if I move mouse again, it responds.
libavcodec doesn't work for that sample. Though it may be due to editing, libmpeg2 seems to be more stable for such streams.

Yeah thats strange. For me the highlights work perfectly, but the actual delay from clicking an item, to the next page appearing can vary from instant to maybe 10 seconds. I am using evr-cp. Thanks for testing, its my only problem with ffdshow's handling of dvd menu's. I can survive without it but would have been nice to find out why the long delay.

[Mixer73]

Hey guys

I'm having horrible trouble with 2527 build on my MCE box, basically if I have played a couple of xvids eventually MCE will crash with FFDShow.ax as the cause.

I'm running more recent builds on my desktop without any issues so I guess I should run up the latest SVN and see if the the problem persists, and if it does provide some info about the crash?

I noted lots of fixes that seem to impact MCE recently so fingers crossed, love the great work you all do!

[haruhiko_yamagata]

Were you using a m2ts file as the source? Also what settings did you use the the GUI properties page for the demux video output pin?
I was using TS files which worked OK.
It doesn't work with m2ts. ffdshow has connection but black window (no image). Other decoders crash on connection.

[tetsuo55]

There appears to be a bug with the output framerate when playing back DVD's

All samples act the same, output is always fixed at 25fps

Here is a screenshot:
http://img33.imageshack.us/img33/5011/incorrectframerate.th.png (http://img33.imageshack.us/my.php?image=incorrectframerate.png)

And here is the pin out information for that file (same problem with every renderer)

Filter : madVR - CLSID : {E1A8B82A-32CE-4B0D-BE0D-AA68C772E423}

- Connected to:

CLSID: {04FE9017-F873-410E-871E-AB91661A4EF7}
Filter: ffdshow Video Decoder
Pin: Out

- Connection media type:

Video: YV12 720x480 (4:3) 25.00fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 518400
cbFormat: 112

VIDEOINFOHEADER:
rcSource: (0,0)-(720,480)
rcTarget: (0,0)-(720,480)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 400000

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 4
dwPictAspectRatioY: 3
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 720
biHeight: 480
biPlanes: 3
biBitCount: 12
biCompression: YV12
biSizeImage: 518400
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 d0 02 00 00 e0 01 00 00 ........Ð...à...
0010: 00 00 00 00 00 00 00 00 d0 02 00 00 e0 01 00 00 ........Ð...à...
0020: 00 00 00 00 00 00 00 00 80 1a 06 00 00 00 00 00 ........€.......
0030: 00 00 00 00 00 00 00 00 04 00 00 00 03 00 00 00 ................
0040: 00 00 00 00 00 00 00 00 28 00 00 00 d0 02 00 00 ........(...Ð...
0050: e0 01 00 00 03 00 0c 00 59 56 31 32 00 e9 07 00 à.......YV12.é..
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Also it appears that DTS over Spdif is not working for me anymore all of suddon (it used to work, i did not touch any of the ffdshow settings) now all i get is silence or pops.
AC3 is working as expected.

I am streaming over HDMI
Build im currently using is 2940It has been confirmed that this is a bug with the "DVD Navigator" so this can be ignored.

[ipanema]

It doesn't work with m2ts. ffdshow has connection but black window (no image). Other decoders crash on connection.

Ah right. I'm using my own m2ts source filter. The only difference between m2ts and m2t is the extra 4 bytes at the start of each packet so it's just as easy to source m2ts files.

I'm having good results using this and the Microsoft MPEG-2 demux filter with other H.264 filters. It's a pity that ffdshow H.264 decoder is still evading a solution. There's a link below to a couple of images showing what I'm getting from the H.254 ffdshow decoder. The first pic shows almost perfect decoding apart from the grey areas, and the second pic shows much more corruption.

http://img7.imageshack.us/gal.php?g=pic1dwk.jpg

I'm obviously very close to a solution but it's difficult to know what more ffdshow is requiring.

[ipanema]

I think I may have found the cause of the problem.

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.

If I understand you correctly, this means that any occurance of the Access UD byte sequence 0 0 0 1 9 must only appear at the start of a new directshow sample arriving at the ffdshow H.264 decoder.

The MPEG-2 demux only starts a new output sample for Access UDs at the start of a frame. It seems there are usually 2 or maybe more Access UD byte sequences occuring for each frame, so perhaps ffdshow is missing these extra Access UDs which could appear anywhere in the samples. I guess other decoders don't care about the alignment of Access UDs on sample boundaries and that's why they are successful.

I don't think it's possible to persuade the MPEG-2 decoder to break samples on Access UDs, so I may have to give up on H.264 ffdshow.

Is there any prospect of a future version of ffdshow where the H.264 decoder doesn't require Access UDs to be always at the start of samples?

[haruhiko_yamagata]

ffdshow does not require access unit delimiters to be placed at the start of DirectShow sample boundary.
Maybe the sample does not have access unit delimiter for all access unit.