ffdshow tryouts project: Discussion & Development

[haruhiko_yamagata]

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?
Here's another related thread.
http://ffdshow-tryout.sourceforge.net/phpBB2/viewtopic.php?t=968
Some stream does not have access unit delimiter. sensing has kindly offered us a patch, which is unfinished.
I know what I should do to parse such streams, but haven't have time until now. Speaking of future plan, yes. But please don't expect too much, there are too many things in my private todo.

[ikarad]

Is it possible to add an option which allow to define core affinity of different filters or plug-in in ffdshow?

For example, when I want to see interlaced blu-ray movie at 30 fps, I would like to use TIVTC (avisynth plug-in) but IVTC isn't multithread and my cpu (Q6600@3.0ghz) isn't powerfull because on the different cores, yet, some percents (nearly 30 %) is used for video decoding.
My idea would be to use only 3 cores to decode video (we can do with decoder option in ffdshow) and the core 4 would be used only for IVTC.

The problem is when I select 3 threads in decoder option of ffdshow, if I activate TIVTC, it's not the core 4 which is used but one of three cores yet used for decoding.

I don't know if it's possible but if it is possible, it would be wonderfull.

[haruhiko_yamagata]

Is it possible to add an option which allow to define core affinity of different filters or plug-in in ffdshow?
No, it isn't.

[ipanema]

Thanks. That thread looks promising. But I think that the sample files I have always seem to have the complete 00 00 00 01 09 byte sequences.

For example here is the NAL sequence from a typical file:


--- New MPEG-2 Demux output sample starts here ---
Access UD (00 00 00 01 09 10)
Sequence parameter set
Picture Parameter set
SEI
SEI
SEI
SEI
SEI
Coded slice of an IDR picture
Access UD (00 00 00 01 09 30)
SEI
Coded slice of a non-IDR picture

--- New MPEG-2 Demux output sample starts here ---
Access UD (00 00 00 01 09 50)
Picture parameter set
SEI
Coded slice of a non-IDR picture
Access UD (00 00 00 01 09 50)
SEI
Coded slice of a non-IDR picture

--- New MPEG-2 Demux output sample starts here ---
Access UD (00 00 00 01 09 50)
SEI
Coded slice of a non-IDR picture
Access UD (00 00 00 01 09 50)
SEI
Coded slice of a non-IDR picture

--- New MPEG-2 Demux output sample starts here ---
Access UD (00 00 00 01 09 30)
SEI
Coded slice of a non-IDR picture
Access UD (00 00 00 01 09 30)
Picture parameter set
SEI
Coded slice of a non-IDR picture

--- New MPEG-2 Demux output sample starts here ---
Access UD (00 00 00 01 09 50)
SEI
Coded slice of a non-IDR picture
Access UD (00 00 00 01 09 50)
SEI
Coded slice of a non-IDR picture

--- New MPEG-2 Demux output sample starts here ---
Access UD (00 00 00 01 09 30)
SEI
Coded slice of a non-IDR picture
Access UD (00 00 00 01 09 30)
SEI
Coded slice of a non-IDR picture

--- New MPEG-2 Demux output sample starts here ---
Access UD (00 00 00 01 09 50)
Picture parameter set
SEI
Coded slice of a non-IDR picture
Access UD (00 00 00 01 09 50)


"New MPEG-2 Demux output sample starts here" indicates where a new output sample from the MPEG-2 mux begins, and this always seems to coincide with the start of a new frame. Note that there seem to be 2 Access UDs in each frame - one at the start of the frame (and therefore appears at the start of the demux output sample) and the other could appear anywhere in a sample.

Between the "New MPEG-2 Mux output sample starts here" markers, the output sample will also be split when the byte count exceeds 8192 bytes (that is the maximum sample size from the demux is 8192 bytes). This split occurs with no regard to the sample contents - it just splits at the 8192th byte.

The important thing to notice is that there is always a 00 00 00 01 09 seqence present, and yet I'm still getting the corruption from these sort of files.

As the patch you mentioned seems to address Access UD markers being missing, I'm not sure that it will solve this problem - unless I've missed something from the thread you referenced.

[haruhiko_yamagata]

@ipanema
Can I have a testing environment?
If not, please tell us the full media type on pin connection. SPS and PPS are not required there.

[ipanema]

Can I have a testing environment?
If not, please tell us the full media type on pin connection. SPS and PPS are not required there.

I'm using VC++ and it would be a massive job to extract the code and construct a standalone test case. So here is the media type you asked for. This is when reading the file that I listed the NALs for above.

I've just connected the video output pin of the Demux to the ffdshow video decoder, and then called ConnectionMediaType() on the Demux's video output pin.

This is the media type listed from the Visual Studio debugger with a small amount of reformatting to make it easier to read. Note that I'm using the 8D2D... subtype here but the H264 subtype (34363248-0000-0010-8000-00AA00389B71) gives the same results.


// AM_MEDIA_TYPE
tmpMediaType
majortype {73646976-0000-0010-8000-00AA00389B71} _GUID
subtype {8D2D71CB-243F-45E3-B2D8-5FD7967EC09B} _GUID
bFixedSizeSamples 1 int
bTemporalCompression 0 int
lSampleSize 1 unsigned long
formattype {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA} _GUID (FORMAT_MPEG2_VIDEO)
pUnk 0x00000000 IUnknown *
cbFormat 275 unsigned long
pbFormat 0x00d05318 "" unsigned char *

// pbFormat expanded
(MPEG2VIDEOINFO *)(tmpMediaType.pbFormat)
hdr
rcSource {top=0 bottom=1088 left=0 right=1920} tagRECT
rcTarget {top=0 bottom=1088 left=0 right=1920} tagRECT
dwBitRate 0 unsigned long
dwBitErrorRate 0 unsigned long
AvgTimePerFrame 0 __int64
dwInterlaceFlags 0 unsigned long
dwCopyProtectFlags 0 unsigned long
dwPictAspectRatioX 16 unsigned long
dwPictAspectRatioY 9 unsigned long
dwControlFlags 0 unsigned long
dwReserved1 0 unsigned long
dwReserved2 0 unsigned long
bmiHeader
biSize 40 unsigned long
biWidth 0 long
biHeight 0 long
biPlanes 0 unsigned short
biBitCount 0 unsigned short
biCompression 875967080 unsigned long ('H264')
biSizeImage 0 unsigned long
biXPelsPerMeter 0 long
biYPelsPerMeter 0 long
biClrUsed 0 unsigned long
biClrImportant 0 unsigned long
dwStartTimeCode 0 unsigned long
cbSequenceHeader 139 unsigned long
dwProfile 100 unsigned long
dwLevel 40 unsigned long
dwFlags 0 unsigned long
dwSequenceHeader 0x00d0539c unsigned long [1]

// Sequence header dump (hexadecimal)
pSeqHdr,139 0x00d0539c "" unsigned char *
[0x0] 0x00 unsigned char
[0x1] 0x00 unsigned char
[0x2] 0x00 unsigned char
[0x3] 0x01 unsigned char
[0x4] 0x27 unsigned char
[0x5] 0x64 unsigned char
[0x6] 0x00 unsigned char
[0x7] 0x28 unsigned char
[0x8] 0xad unsigned char
[0x9] 0x88 unsigned char
[0xa] 0x11 unsigned char
[0xb] 0x21 unsigned char
[0xc] 0x48 unsigned char
[0xd] 0x30 unsigned char
[0xe] 0x41 unsigned char
[0xf] 0x46 unsigned char
[0x10] 0x85 unsigned char
[0x11] 0x31 unsigned char
[0x12] 0x90 unsigned char
[0x13] 0x89 unsigned char
[0x14] 0x10 unsigned char
[0x15] 0x22 unsigned char
[0x16] 0x4c unsigned char
[0x17] 0x9c unsigned char
[0x18] 0x99 unsigned char
[0x19] 0x22 unsigned char
[0x1a] 0x48 unsigned char
[0x1b] 0x82 unsigned char
[0x1c] 0x48 unsigned char
[0x1d] 0xd2 unsigned char
[0x1e] 0x74 unsigned char
[0x1f] 0x91 unsigned char
[0x20] 0xc4 unsigned char
[0x21] 0x14 unsigned char
[0x22] 0xc4 unsigned char
[0x23] 0x6d unsigned char
[0x24] 0x1d unsigned char
[0x25] 0x08 unsigned char
[0x26] 0x23 unsigned char
[0x27] 0x31 unsigned char
[0x28] 0xd8 unsigned char
[0x29] 0xe1 unsigned char
[0x2a] 0x24 unsigned char
[0x2b] 0xb9 unsigned char
[0x2c] 0xca unsigned char
[0x2d] 0x31 unsigned char
[0x2e] 0x26 unsigned char
[0x2f] 0x98 unsigned char
[0x30] 0xa1 unsigned char
[0x31] 0x03 unsigned char
[0x32] 0x79 unsigned char
[0x33] 0x0c unsigned char
[0x34] 0x53 unsigned char
[0x35] 0x98 unsigned char
[0x36] 0x71 unsigned char
[0x37] 0x83 unsigned char
[0x38] 0xb0 unsigned char
[0x39] 0x90 unsigned char
[0x3a] 0x90 unsigned char
[0x3b] 0x98 unsigned char
[0x3c] 0x68 unsigned char
[0x3d] 0x58 unsigned char
[0x3e] 0x90 unsigned char
[0x3f] 0x94 unsigned char
[0x40] 0x41 unsigned char
[0x41] 0x24 unsigned char
[0x42] 0xd7 unsigned char
[0x43] 0x5e unsigned char
[0x44] 0xbe unsigned char
[0x45] 0xbf unsigned char
[0x46] 0x18 unsigned char
[0x47] 0x2f unsigned char
[0x48] 0xe4 unsigned char
[0x49] 0x45 unsigned char
[0x4a] 0xf1 unsigned char
[0x4b] 0x48 unsigned char
[0x4c] 0x5f unsigned char
[0x4d] 0x22 unsigned char
[0x4e] 0x2b unsigned char
[0x4f] 0x43 unsigned char
[0x50] 0x10 unsigned char
[0x51] 0x4e unsigned char
[0x52] 0x30 unsigned char
[0x53] 0xe2 unsigned char
[0x54] 0xc2 unsigned char
[0x55] 0x47 unsigned char
[0x56] 0x38 unsigned char
[0x57] 0xed unsigned char
[0x58] 0x30 unsigned char
[0x59] 0x1e unsigned char
[0x5a] 0x01 unsigned char
[0x5b] 0x13 unsigned char
[0x5c] 0xf7 unsigned char
[0x5d] 0x80 unsigned char
[0x5e] 0x88 unsigned char
[0x5f] 0x00 unsigned char
[0x60] 0x00 unsigned char
[0x61] 0x7d unsigned char
[0x62] 0x20 unsigned char
[0x63] 0x00 unsigned char
[0x64] 0x1d unsigned char
[0x65] 0x4c unsigned char
[0x66] 0x07 unsigned char
[0x67] 0x43 unsigned char
[0x68] 0x00 unsigned char
[0x69] 0x07 unsigned char
[0x6a] 0xa1 unsigned char
[0x6b] 0x20 unsigned char
[0x6c] 0x00 unsigned char
[0x6d] 0x08 unsigned char
[0x6e] 0x95 unsigned char
[0x6f] 0x45 unsigned char
[0x70] 0x77 unsigned char
[0x71] 0x97 unsigned char
[0x72] 0x1a unsigned char
[0x73] 0x18 unsigned char
[0x74] 0x00 unsigned char
[0x75] 0x3d unsigned char
[0x76] 0x09 unsigned char
[0x77] 0x00 unsigned char
[0x78] 0x00 unsigned char
[0x79] 0x44 unsigned char
[0x7a] 0xaa unsigned char
[0x7b] 0x2b unsigned char
[0x7c] 0xbc unsigned char
[0x7d] 0xb8 unsigned char
[0x7e] 0x7c unsigned char
[0x7f] 0x22 unsigned char
[0x80] 0x11 unsigned char
[0x81] 0x45 unsigned char
[0x82] 0x80 unsigned char
[0x83] 0x00 unsigned char
[0x84] 0x00 unsigned char
[0x85] 0x00 unsigned char
[0x86] 0x01 unsigned char
[0x87] 0x28 unsigned char
[0x88] 0xea unsigned char
[0x89] 0x43 unsigned char
[0x8a] 0xcb unsigned char


Note that when setting up the media type for the demux video pin, other decoders seem to be happy with most of the structure all zero-ed apart from the dwSequenceHeader - I assume that they get all the info they need from the SPS and PPS which would agree with the Microsoft page

http://msdn.microsoft.com/en-us/library/dd757808(VS.85).aspx

which says:

When the bitstream contains start codes, any of the format types listed here is sufficient, because the decoder does not require any additional information to parse the stream. The bitstream already contains all of the information needed by the decoder, and the start codes enable the decoder to locate the start of each NALU.

But I found that ffdshow needs some fields to be filled in such as rcSource otherwise pins will not connect later on in the graph.

The values above seem to be the same as the values I assigned - that is, no additional fields seem to get filled in during pin connection negotiation.

[haruhiko_yamagata]

OK, I'll see if I can improve anything around this. As you say, it's ffdshow's limitation that it requires some values in the media type.

[ipanema]

Thanks Haruhiko. If you need any more info let me know. Note that the values that I did fill in above I had extracted from the SPS (they aren't just hard-coded guesses).

[haruhiko_yamagata]

Oh, you have already done that, then why not fill bmiHeader::biWidth and biHeight? I'm not sure if it takes any effect though.

[ipanema]

I've been trying a variety of BMI and MPEG2VIDEO fields filled-in over the last couple of days but with no luck in getting rid of the corruption in decoded frames. Sorry I thought that the debuging snapshot I posted had all of the fields filled in that I had tried, but I must have commented out the BMI width and height fields again before that run.

Just to be absolutely sure I just un-commented them (BMI width and height now being set to 1920 and 1088 respectively) and re-ran and there is no difference. I still get corrupted decoded frames.

I think that the size of the video is being picked up correctly in the decoder because the decoded frames seem to be the right size and the small areas that are not corrupted look OK (see the link to screen shots I posted earlier).

[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.

Unfortunately using the guide at http://ffdshow-tryout.sourceforge.net/wiki/video:resize_aspect#example I have many many DVD's which show incorrect aspect ratio when passing through ffdshow's resize, even with mpc-hc's own "Keep Aspect Ratio" disabled. I am resizing to my screen resolution of 1920 x 1080, with "Keep original aspect ratio 1.78:1" selected, this 16:9 movie appears to be squashed to something like 4:3.

With "No aspect ratio correction" these dvd's work fine and are not squashed.

I am still struggling to find a configuration that will allow me to reliably use ffdshow's resize and keep aspect ratio's correct. In this scenario where the DVD is 16:9 (1.78:1 with black bars top and bottom) maybe you might know what is going wrong? Is ffdshow able to handle these type of DVD's yet, ones not marked as 16:9 or 4:3?

I was not clear if you had implemented the forcing of 16:9 or 4:3 for dvd's so maybe this 1.78:1 isn't handled by ffdshow in the current builds but here is my ffdshow settings incase it helps at all.

http://img198.imageshack.us/img198/5350/ffdshowsettings.th.jpg (http://img198.imageshack.us/my.php?image=ffdshowsettings.jpg)

This is the squashed image it produces.
http://img39.imageshack.us/img39/7414/wrongaspectratio.th.jpg (http://img39.imageshack.us/my.php?image=wrongaspectratio.jpg)

I am wondering if
1) There is another flag / aspect ratio variable that needs to be read for DVD's which would give the correct AR, ie 16:9 or 4:3
2) If forcing of 16:9 or 4:3 for DVD content can be implemented in an upcoming version if not already done.

I look forward to getting this issue resolved with your help. Thanks.

[therealjoeblow]

Unfortunately using the guide at http://ffdshow-tryout.sourceforge.net/wiki/video:resize_aspect#example I have many many DVD's which show incorrect aspect ratio when passing through ffdshow's resize, even with mpc-hc's own "Keep Aspect Ratio" disabled. I am resizing to my screen resolution of 1920 x 1080, with "Keep original aspect ratio 1.78:1" selected, this 16:9 movie appears to be squashed to something like 4:3.

With "No aspect ratio correction" these dvd's work fine and are not squashed.

I am still struggling to find a configuration that will allow me to reliably use ffdshow's resize and keep aspect ratio's correct. In this scenario where the DVD is 16:9 (1.78:1 with black bars top and bottom) maybe you might know what is going wrong? Is ffdshow able to handle these type of DVD's yet, ones not marked as 16:9 or 4:3?

I was not clear if you had implemented the forcing of 16:9 or 4:3 for dvd's so maybe this 1.78:1 isn't handled by ffdshow in the current builds but here is my ffdshow settings incase it helps at all.


I am wondering if
1) There is another flag / aspect ratio variable that needs to be read for DVD's which would give the correct AR, ie 16:9 or 4:3
2) If forcing of 16:9 or 4:3 for DVD content can be implemented in an upcoming version if not already done.

I look forward to getting this issue resolved with your help. Thanks.

I use ffdshow's resize for DVD's with ZoomPlayer 6 *all* the time, and I don't recall it ever producing an aspect ratio problem. I've watched hundreds of DVD's, anamorphic 16:9, letterboxed 16:9, 4:3, PAL, NTSC, Interlaced, Progressive, homebrew from my Pioneer DVD DVR-650H Recorder, homebrew with ConvertX2DVD, and never an aspect ratio problem that I can recall.

My settings are exactly the same as yours with one main exception:

-under the "Resize" section at the top left, I have HORIZONTAL specified only, 1920 (you have "Resize to screen resolution checked")

-also under "Resize if" I have "Resize Always" checked, but that's not likely to be the problem, it's only the trigger to enable or disable the filter.

Like I said, no issues with aspect ratio ever.

I don't use MPC of any variety - I tried it and found it to be really disfunctional compared to ZP. Maybe try another player and see if it's MPC that's the root of your problems.

[mark0077]

I use ffdshow's resize for DVD's with ZoomPlayer 6 *all* the time, and I don't recall it ever producing an aspect ratio problem. I've watched hundreds of DVD's, anamorphic 16:9, letterboxed 16:9, 4:3, PAL, NTSC, Interlaced, Progressive, homebrew from my Pioneer DVD DVR-650H Recorder, homebrew with ConvertX2DVD, and never an aspect ratio problem that I can recall.

My settings are exactly the same as yours with one main exception:

-under the "Resize" section at the top left, I have HORIZONTAL specified only, 1920 (you have "Resize to screen resolution checked")

-also under "Resize if" I have "Resize Always" checked, but that's not likely to be the problem, it's only the trigger to enable or disable the filter.

Like I said, no issues with aspect ratio ever.

I don't use MPC of any variety - I tried it and found it to be really disfunctional compared to ZP. Maybe try another player and see if it's MPC that's the root of your problems.

See in this case mpc-hc does no aspect ratio adjustment at all (have its internal aspect ratio control disabled), it just shows what its given. In this situation ffdshow is actually squasing up the image horizontally where it should be just outputting the entire frame at 16:9. This is why I feel there must be an error in calculation somewhere.

[MatMaul]

here is a patch to update the spectral extension code of the eac3 decoder :
http://www.etud.insa-toulouse.fr/~mvelten/bordel/ffdshow_eac3_spx.diff

it comes from here :
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-May/069726.html

[clsid]

applied.

[mark0077]

To update on resize problem with various DVD's. Here are details shown on the ffdshow osd of a DVD movie that gets output in a window that looks like 4:3 (mpc-hc's own aspect ratio controls disabled).

With both "No aspect ratio correction" AND "Keep original aspect ratio 1.78:1" the same details below get output
Input 720 x 576 SAR 64/45 DAR 16/9
Output SAR 1/1 DAR 16:9

BUT

With "No aspect ratio correction", this particular disk outputs perfectly in 16:9, but with "Keep original....." it gets output squashed. I think this indicates some problem with "Keep original aspect ratio" setting somewhere as both options give same output on OSD, but massive difference in ACTUAL output ratio.

Grey bars below show what ffdshow is adding to the sides of the content when "keep original aspect ratio" is enabled. Something wrong somewhere.
http://img33.imageshack.us/img33/6266/weirdj.th.jpg (http://img33.imageshack.us/my.php?image=weirdj.jpg)

Thanks.

[her34]

wmv files broken in rev2954 and rev2968

works in rev2946

sample file:
http://www.gametrailers.com/video/preview-hd-prototype/49703

[jmartinr]

To update on resize problem with various DVD's. Here are details shown on the ffdshow osd of a DVD movie that gets output in a window that looks like 4:3 (mpc-hc's own aspect ratio controls disabled).

With both "No aspect ratio correction" AND "Keep original aspect ratio 1.78:1" the same details below get output
Input 720 x 576 SAR 64/45 DAR 16/9
Output SAR 1/1 DAR 16:9

BUT

With "No aspect ratio correction", this particular disk outputs perfectly in 16:9, but with "Keep original....." it gets output squashed. I think this indicates some problem with "Keep original aspect ratio" setting somewhere as both options give same output on OSD, but massive difference in ACTUAL output ratio.

Grey bars below show what ffdshow is adding to the sides of the content when "keep original aspect ratio" is enabled. Something wrong somewhere.
http://img33.imageshack.us/img33/6266/weirdj.th.jpg (http://img33.imageshack.us/my.php?image=weirdj.jpg)

Thanks.

Just checking the obvious: you have enabled "process pixel aspect ratio internally"?

[mark0077]

Yeah here is a screenshot with my settings
http://img198.imageshack.us/img198/5350/ffdshowsettings.th.jpg (http://img198.imageshack.us/my.php?image=ffdshowsettings.jpg)

This is a very simple case above where the output should be 16:9 but ffdshow adds bars to each side of the image.

[tetsuo55]

Yeah here is a screenshot with my settings
http://img198.imageshack.us/img198/5350/ffdshowsettings.th.jpg (http://img198.imageshack.us/my.php?image=ffdshowsettings.jpg)

This is a very simple case above where the output should be 16:9 but ffdshow adds bars to each side of the image.
Judging from your settings this might not be a bug.

What happens when you use these settings instead:
-Multiply by 3
-No aspect ratio correction

[EpsilonX]

To update on resize problem with various DVD's. Here are details shown on the ffdshow osd of a DVD movie that gets output in a window that looks like 4:3 (mpc-hc's own aspect ratio controls disabled).

With both "No aspect ratio correction" AND "Keep original aspect ratio 1.78:1" the same details below get output
Input 720 x 576 SAR 64/45 DAR 16/9
Output SAR 1/1 DAR 16:9

BUT

With "No aspect ratio correction", this particular disk outputs perfectly in 16:9, but with "Keep original....." it gets output squashed. I think this indicates some problem with "Keep original aspect ratio" setting somewhere as both options give same output on OSD, but massive difference in ACTUAL output ratio.

Grey bars below show what ffdshow is adding to the sides of the content when "keep original aspect ratio" is enabled. Something wrong somewhere.
http://img33.imageshack.us/img33/6266/weirdj.th.jpg (http://img33.imageshack.us/my.php?image=weirdj.jpg)

Thanks.

I am using ZP6...
I got the same "squashed" DVD menu...
Both "No aspect ratio correction" and "keep original aspect ratio" resulted the same...
It only happened if I use ZP6 default and recommended aspect ratio setting, which is "Derived"...
Changed ZP aspect ratio setting to "Widescreen 16:9" and the picture is fine...
In MPC, to make the picture correct it required "keep original aspect ratio" in FFDShow and uncheck “Keep Aspect Ratio” in MPC...
Just like what the wiki example...

http://ffdshow-tryout.sourceforge.net/wiki/video:resize_aspect#example

[tetsuo55]

i just ran some tests to try and reproduce this problem

And as EpsilonX said it's a conflict between the MPC aspect ratio settings and the FFdshow aspect ratio settings.

The best setting i was able to find was:
MPC:
-Touch windows from the inside
-Keep aspect ratio

FFdshow: Keep aspect ratio, or no aspect ratio correction, other settings have no influence.

[mark0077]

i just ran some tests to try and reproduce this problem

And as EpsilonX said it's a conflict between the MPC aspect ratio settings and the FFdshow aspect ratio settings.

The best setting i was able to find was:
MPC:
-Touch windows from the inside
-Keep aspect ratio

FFdshow: Keep aspect ratio, or no aspect ratio correction, other settings have no influence.

Thanks for that. I was using haruhiko's suggestion from his link of disabling mpc-hc's keep aspect ratio. I am just trying to nudge the workings of both to be very consistent. At the moment I can find many combinations of settings that doesn't give the right aspect ratio. The only way I find to get aspect ratio correct ALL of the time is to just use mpc-hc keep aspect ratio and ignore ffdshow.

The image I posted above with bars on the side is definitely not right through. In this case ffdshow is the only piece of software I have that adds black bars to the side of this 16:9 movie. Maybe another flag needs to be ignored / forced to a certain value because of the fact that its a DVD?

[tetsuo55]

Thanks for that. I was using haruhiko's suggestion from his link of disabling mpc-hc's keep aspect ratio. I am just trying to nudge the workings of both to be very consistent. At the moment I can find many combinations of settings that doesn't give the right aspect ratio. The only way I find to get aspect ratio correct ALL of the time is to just use mpc-hc keep aspect ratio and ignore ffdshow.

The image I posted above with bars on the side is definitely not right through. In this case ffdshow is the only piece of software I have that adds black bars to the side of this 16:9 movie. Maybe another flag needs to be ignored / forced to a certain value because of the fact that its a DVD?

I did some more tests:
Using the default recommended MPC settings i posted above.
No aspect ratio correction: Image is always correct
Keep aspect ratio: there is a 50% chance of the image being squashed
Manual: Image is always correct(conforms to the input value)

Now if you want to disable MPC's correction and do everything manually with FFdshow you have to match the settings exactly to both the display and the source image (MPC will make a empty canvas the size of the window(or full screen) and then it's up to FFdshow to fill that canvas any way it want's to)

----------

Based on these results i would say the "keep aspect ratio" function is broken.


EDIT:

Can you reproduce this problem with any other container format?
The DVD navigator in windows can be a real problem for some options, also different windows versions have different navigators that all behave differentely, even same version can be behave differentely depending on output renderer.

[haruhiko_yamagata]

To update on resize problem with various DVD's.
...
Does it work if you uncheck resize?

[EpsilonX]

I did some more tests:
Using the default recommended MPC settings i posted above.
No aspect ratio correction: Image is always correct
Keep aspect ratio: there is a 50% chance of the image being squashed
Manual: Image is always correct(conforms to the input value)

Now if you want to disable MPC's correction and do everything manually with FFdshow you have to match the settings exactly to both the display and the source image (MPC will make a empty canvas the size of the window(or full screen) and then it's up to FFdshow to fill that canvas any way it want's to)

----------

Based on these results i would say the "keep aspect ratio" function is broken.


EDIT:

Can you reproduce this problem with any other container format?
The DVD navigator in windows can be a real problem for some options, also different windows versions have different navigators that all behave differentely, even same version can be behave differentely depending on output renderer.

Which "keep aspect ratio" setting..?
FFDShow or MPC's..?
About other container...
Assuming it's encoded correctly, no problem whatsoever...
I use FFDShow Resize's "Keep aspect ratio" and ZP6 in "Derived" setting for those...
It's only DVD for me, cause I have to force ZP6's "Widescreen" aspect ratio....
To sum it up...

Vista SP2 32-bit
FFDShow Tryout rev2972 ICL10
ZoomPlayer 6
Media Player Classic Home Cinema 1.2.1125

FFDShow "Keep original aspect ratio" + ZP6 "Derived" = Squashed
FFDShow “No aspect ratio correction” + ZP6 "Derived" = Squashed
FFDShow "Keep original aspect ratio" + ZP6 "Widescreen" = Normal
FFDShow “No aspect ratio correction” + ZP6 "Widescreen" = Depends on the menu

FFDShow "Keep original aspect ratio" + MPC “Keep Aspect Ratio” enabled = Squashed
FFDShow “No aspect ratio correction” + MPC “Keep Aspect Ratio” enabled = Squashed
FFDShow "Keep original aspect ratio" + MPC “Keep Aspect Ratio” disabled = Normal
FFDShow “No aspect ratio correction” + MPC “Keep Aspect Ratio” disabled = Depends on the menu

*Depends on the menu = some menu are stretched

For now I set FFDShow's to "Keep original aspect ratio", ZP6 to "Widescreen" and uncheck MPC's “Keep Aspect Ratio”...
All my videos seems fine...

[tetsuo55]

Which "keep aspect ratio" setting..?
FFDShow or MPC's..?
About other container...
Assuming it's encoded correctly, no problem whatsoever...
I use FFDShow Resize's "Keep aspect ratio" and ZP6 in "Derived" setting for those...
It's only DVD for me, cause I have to force ZP6's "Widescreen" aspect ratio....
To sum it up...

Vista SP2 32-bit
FFDShow Tryout rev2972 ICL10
ZoomPlayer 6
Media Player Classic Home Cinema 1.2.1125

FFDShow "Keep original aspect ratio" + ZP6 "Derived" = Squashed
FFDShow “No aspect ratio correction” + ZP6 "Derived" = Squashed
FFDShow "Keep original aspect ratio" + ZP6 "Widescreen" = Normal
FFDShow “No aspect ratio correction” + ZP6 "Widescreen" = Depends on the menu

FFDShow "Keep original aspect ratio" + MPC “Keep Aspect Ratio” enabled = Squashed
FFDShow “No aspect ratio correction” + MPC “Keep Aspect Ratio” enabled = Squashed
FFDShow "Keep original aspect ratio" + MPC “Keep Aspect Ratio” disabled = Normal
FFDShow “No aspect ratio correction” + MPC “Keep Aspect Ratio” disabled = Depends on the menu

*Depends on the menu = some menu are stretched

For now I set FFDShow's to "Keep original aspect ratio", ZP6 to "Widescreen" and uncheck MPC's “Keep Aspect Ratio”...
All my videos seems fine...
I mean the ffdshow setting.

Have you also enabled "touch window from the inside" in MPC?

That other containers work properly basically confirms that the problem is caused by the dvd navigator

[EpsilonX]

I mean the ffdshow setting.

Have you also enabled "touch window from the inside" in MPC?

That other containers work properly basically confirms that the problem is caused by the dvd navigator

Yes I did... :D
Along with “Process pixel aspect ratio internally”...
And I resize it to "1360x768"...
Any alternative DVD Navigator to use with ZP or MPC..?
IIRC I've tried Cyberlink's and it failed to connect...

[tetsuo55]

Not that i know of, a lot of people trying to find one though.

What we basically need is an opensource dvd navigator compatible with directshow

[therealjoeblow]

Do the settings for "YCbCr Specification", "Input Levels" and "Output Levels" actually work for anyone? I've tried changing the various options and never see the picture getting darker or lighter as would be expected for any of XviD, H264 or DVD's. The similar options available in CoreAVC produce the expected darkening/lightening of the picture when they are adjusted; as do the similar options when the Haali Renderer is used, but they definitely do nothing in ffdshow?

I tried on two of my machines, both are running WinXP32 SP3; one has an ATI Radeon 3200 (780G) chipset with Catalyst 9.4; the other is a Dell Laptop with an Intel Mobile 965 Express graphics chipset. Same results on both.

[mark0077]

Found another bug relating to aspect ratios. I have just converted all of my DVD TV Show Episodes to mkv's. Using ffdshow, without resize (as I am having too many problems), using ffdshow's mpeg2 decoders, none of these mkv's play at the correct AR. They are squashed with black bars at the top and bottom. Using mpc-hc's own mpeg2 decoder everything is fine. I am getting confused now as this only happens when using one of ffdshow's mpeg2 decoders. Below ar

Using ffdshow Decoders
Original DVD
Input: Resolution: 720 x 576, SAR: 64/45, DAR 16/9
Output: SAR: 64/45, DAR: 16/9

mkv
Input: Resolution: 720 x 576, SAR: 64/45, DAR 16/9
Output: SAR: 256/135, DAR: 64/27

Original DVD
Input: Resolution: 720 x 576, SAR: 64/45, DAR 16/9
Output: SAR: 64/45, DAR: 16/9

mkv
Input: Resolution: 720 x 576, SAR: 64/45, DAR 16/9
Output: SAR: 64/45, DAR: 16/9

This time, the only combination that gives the incorrect AR is using ffdshow's internal mpeg2 decoders. This is with ffdshow resize off.

AND SURPRISE SURPRISE

Now all of my previous problem dvd's (the 3 or 4 that I have tested) are magically working perfectly even with ffdshow's resize but only when ffdshow's mpeg2 decoders are disabled. haruhiko: Is this where you talked about doing the enforcement of certain aspect ratios for DVD's? Something is going wrong only when using ffdshows mpeg2 decoders. Disabling the ffdshow mpeg2 decoders seemed to do the trick so this might give a clue to whats giving the strange output numbers I showed above. I suppose to test any fixes that may come, we can just check (or at least for this disk I am testing with) if the Output in the ffdshow OSD is "SAR: 64/45, DAR: 16/9" when its internal decoders are enabled

[yesgrey]

Do the settings for "YCbCr Specification", "Input Levels" and "Output Levels" actually work for anyone? I've tried changing the various options and never see the picture getting darker or lighter as would be expected for any of XviD, H264 or DVD's.
Have you checked only RGB32 output in the "supported output colorspaces"?

[tetsuo55]

Something is going wrong only when using ffdshows mpeg2 decoders. Disabling the ffdshow mpeg2 decoders seemed to do the trickI think your conclusion is correct, this would also explain why other codecs don't have this problem.

I even found a disc that would crash with both mpeg2 decoders, but works fine with the one in MPC-HC.
I don't have a clue where the disc is (we changed the living room and the disc got cleaned up somewhere :()

EDIT:
The movie is "Pulse 2"

[cca]

I don't know if anyone else here uses ReClock, but I am unable to use versions higher than rev. 2955 when ffmpeg-mt is used as a decoder. It causes a crash in ReClockHelper.dll .From what I know that helper is trying to construct a directshow graph of the source file in order to extract the fps of the video. If libavcodec is selected as a decoder the crash does not occur, it also does not occur if I have ffmpeg-mt selected with number of threads 2 or 1.

[haruhiko_yamagata]

Found another bug relating to aspect ratios. I have just converted all of my DVD TV Show Episodes to mkv's. Using ffdshow, without resize (as I am having too many problems), using ffdshow's mpeg2 decoders, none of these mkv's play at the correct AR. They are squashed with black bars at the top and bottom. Using mpc-hc's own mpeg2 decoder everything is fine. I am getting confused now as this only happens when using one of ffdshow's mpeg2 decoders. Below ar

Using ffdshow Decoders
Original DVD
Input: Resolution: 720 x 576, SAR: 64/45, DAR 16/9
Output: SAR: 64/45, DAR: 16/9

mkv
Input: Resolution: 720 x 576, SAR: 64/45, DAR 16/9
Output: SAR: 256/135, DAR: 64/27

Original DVD
Input: Resolution: 720 x 576, SAR: 64/45, DAR 16/9
Output: SAR: 64/45, DAR: 16/9

mkv
Input: Resolution: 720 x 576, SAR: 64/45, DAR 16/9
Output: SAR: 64/45, DAR: 16/9

This time, the only combination that gives the incorrect AR is using ffdshow's internal mpeg2 decoders. This is with ffdshow resize off.

AND SURPRISE SURPRISE

Now all of my previous problem dvd's (the 3 or 4 that I have tested) are magically working perfectly even with ffdshow's resize but only when ffdshow's mpeg2 decoders are disabled. haruhiko: Is this where you talked about doing the enforcement of certain aspect ratios for DVD's? Something is going wrong only when using ffdshows mpeg2 decoders. Disabling the ffdshow mpeg2 decoders seemed to do the trick so this might give a clue to whats giving the strange output numbers I showed above. I suppose to test any fixes that may come, we can just check (or at least for this disk I am testing with) if the Output in the ffdshow OSD is "SAR: 64/45, DAR: 16/9" when its internal decoders are enabled
Then the stream is wrong. MPC-HC gets the AR from container, not the stream. But in that case, it won't be able to decode such streams whose PAR change during playback.
And yes, it's the enforcement that I have spoken of. The enforcement is restricted to DVD playback.
Sample (http://ffdshow-tryout.sourceforge.net/doom9/ARchangeDuringPlayback.ts)

[haruhiko_yamagata]

I don't know if anyone else here uses ReClock, but I am unable to use versions higher than rev. 2955 when ffmpeg-mt is used as a decoder. It causes a crash in ReClockHelper.dll .From what I know that helper is trying to construct a directshow graph of the source file in order to extract the fps of the video. If libavcodec is selected as a decoder the crash does not occur, it also does not occur if I have ffmpeg-mt selected with number of threads 2 or 1.
I'm not sure if it is a bug of ffdshow.
Could you tell me the last working version?

[mark0077]

Then the stream is wrong. MPC-HC gets the AR from container, not the stream. But in that case, it won't be able to decode such streams whose PAR change during playback.
And yes, it's the enforcement that I have spoken of. The enforcement is restricted to DVD playback.
Sample (http://ffdshow-tryout.sourceforge.net/doom9/ARchangeDuringPlayback.ts)

OK Thanks for the clarification. But this particular mkv, when opened in mkvinfo, shows the mpeg2 stream has the values

Pixel width: 720
Pixel height: 576
Display height: 576
Display width: 1024

I think this is correct...., basically saying the image should be stretched to 1024 x 576 right? Are there even more variables like this somewhere else in there that you think are wrong?

[cca]

I'm not sure if it is a bug of ffdshow.
Could you tell me the last working version?

Last known working version is revision 2955.

[haruhiko_yamagata]

OK Thanks for the clarification. But this particular mkv, when opened in mkvinfo, shows the mpeg2 stream has the values

Pixel width: 720
Pixel height: 576
Display height: 576
Display width: 1024

I think this is correct...., basically saying the image should be stretched to 1024 x 576 right? Are there even more variables like this somewhere else in there that you think are wrong?
It's the container AR, I think.
As I said earlier, there are two ways of calculating PAR from the bit-stream, one is wrong of course. So we can only guess the PAR.

[haruhiko_yamagata]

Last known working version is revision 2955.
Then which is the oldest version that does not work? 2956?

[cca]

Then which is the oldest version that does not work? 2956?

I get my builds from www.xvidvideo.ru, the first version after 2955 was 2964, so something that was changed between 2955 and 2964. In the changelog I see many updates to ffmpeg-mt, I guess something in one of those.

[STaRGaZeR]

I don't know if anyone else here uses ReClock, but I am unable to use versions higher than rev. 2955 when ffmpeg-mt is used as a decoder. It causes a crash in ReClockHelper.dll .From what I know that helper is trying to construct a directshow graph of the source file in order to extract the fps of the video. If libavcodec is selected as a decoder the crash does not occur, it also does not occur if I have ffmpeg-mt selected with number of threads 2 or 1.

I have this problem too, but only when the used profile has Avisynth enabled. It's not related to ffmpeg-mt as it happens with any file. However I've experienced it one or two times with the default profile.

[haruhiko_yamagata]

I get my builds from www.xvidvideo.ru, the first version after 2955 was 2964, so something that was changed between 2955 and 2964. In the changelog I see many updates to ffmpeg-mt, I guess something in one of those.
Then it alters timing. I think it is not a bug of ffdshow.
The graph state change from pause to playing when first video frame is delivered. It may be triggering a bug in ReClock. The timing first frame is delivered differs a great deal between libavcodec and ffmpeg-mt.
As the crashing module is ReClockHelper.dll, it is most likely a bug of ReClock. If ffmpeg-mt is causing delayed crash (ie breaking heap), it should crash even without ReClock.

[cca]

Then it alters timing. I think it is not a bug of ffdshow.
The graph state change from pause to playing when first video frame is delivered. It may be triggering a bug in ReClock. The timing first frame is delivered differs a great deal between libavcodec and ffmpeg-mt.
As the crashing module is ReClockHelper.dll, it is most likely a bug of ReClock. If ffmpeg-mt is causing delayed crash (ie breaking heap), it should crash even without ReClock.

I will forward this to the ReClock forums then, see what the developer will say.

[mark0077]

It's the container AR, I think.
As I said earlier, there are two ways of calculating PAR from the bit-stream, one is wrong of course. So we can only guess the PAR.

Ah I see, so its the mpeg2 stream (from the original DVD) thats incorrect, and only when playing from original disk does ffdshow do the workaround for DVD mpeg2 streams? I think I understand now.

I guess it is not recommended to convert DVD to mkv then unless you know the mkv creator performs these corrections to the incorrect DVD aspect ratio flags... I am just confused how both the mkv container AND the stream can be different. The makemkv tool I used should have read the AR (even if incorrect) from the mpeg2 stream and saved that in the mkv container... but instead both must be different which baffles me.

I will try find a tool to edit the mpeg2 streams of all of my newly created mkv's anyways. Thanks.

[tetsuo55]

Ah I see, so its the mpeg2 stream (from the original DVD) thats incorrect, and only when playing from original disk does ffdshow do the workaround for DVD mpeg2 streams? I think I understand now.

I guess it is not recommended to convert DVD to mkv then unless you know the mkv creator performs these corrections to the incorrect DVD aspect ratio flags... I am just confused how both the mkv container AND the stream can be different. The makemkv tool I used should have read the AR (even if incorrect) from the mpeg2 stream and saved that in the mkv container... but instead both must be different which baffles me.

I will try find a tool to edit the mpeg2 streams of all of my newly created mkv's anyways. Thanks.I'm in the proces of converting all my DVD's to MKV using the same tool.
So far i have been lucky, all show correct aspect ratio in the MKV container.

I've dicided to completely avoid all those unfixable/hacky-solution DVD problems.
I had already converted all my other containers to MKV for similar reasons in the past
The only thing i don't have in MKV now is Realmedia (which is stored in the RMVB container), but with the full realmedia support of ffmpeg i technically should be able to do a problem free conversion to MKV

[mark0077]

I'm in the proces of converting all my DVD's to MKV using the same tool.
So far i have been lucky, all show correct aspect ratio in the MKV container.

I've dicided to completely avoid all those unfixable/hacky-solution DVD problems.
I had already converted all my other containers to MKV for similar reasons in the past
The only thing i don't have in MKV now is Realmedia (which is stored in the RMVB container), but with the full realmedia support of ffmpeg i technically should be able to do a problem free conversion to MKV

Good stuff, but are you using mpc-hc's mpeg2 decoder or ffdshow's. If using mpc-hc's you may have badly marked mpeg2 streams also which I think is the case with me. I would rather have them all set correctly so I can use any decoder.

[STaRGaZeR]

haruhiko, rev2976 makes seeking slower. Are dropped frames on seeking really a problem?

[tetsuo55]

Good stuff, but are you using mpc-hc's mpeg2 decoder or ffdshow's. If using mpc-hc's you may have badly marked mpeg2 streams also which I think is the case with me. I would rather have them all set correctly so I can use any decoder. I use libvacodec decoder in ffdshow

[mark0077]

I know its off topic but do you know of a tool to edit the mpeg2 screen AR flags that must be set incorrectly in alot of my mkv's now. Will be nice to fix them all.