ffdshow tryouts project: Discussion & Development

[e-t172]

I posted this on slysoft forums and the answer there was

"Just disable the DShow estimator."

so how can I do that and does this have any disadvantages?

You can disable it in the Reclock options, Video Settings. I don't think there will be serious disadvantages.

[cca]

You can disable it in the Reclock options, Video Settings. I don't think there will be serious disadvantages.

That is completely subjective and depends on the video content used. For me for example there would be a big disadvantage since I use VFR videos 80% of the time, the other estimator of ReClock can't cope with them. But this is getting offtopic.

[haruhiko_yamagata]

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:



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.
I have fixed the limitation that ffdshow required dimension of the video at rev 2994.
Could you remove SPS and PPS from the dwSequenceHeader as a test? I'm not sure if it makes a difference though.

[clsid]

@Albain

AutoCrop is still a bit buggy after your changes in rev 2996. At tolerance 40 (default) it will crop parts of the video. To be more precise, it actually replaced the top/bottom parts of the video with black bars. The output resolution did not change.
The problem does not happen with tolerance 10.
I tested with a video that did not have any black bars, so AutoCrop should have done nothing in that case.

[STaRGaZeR]

How autocrop is supposed to work? I've a good amount of videos with big black bars, both horizontal and vertical, none of them are detected. It's seems the filter is doing nothing. Cropping manually works of course.

[clsid]

You are probably not yet using revision 2996.

[STaRGaZeR]

You are probably not yet using revision 2996.

I'm using it. Whatever I do with the autocrop configuration and/or sources, the output is just the same. No other filters are used.

[Octo-puss]

Will rev 3000 be anything special? It should! :)

[Blight]

Maybe rev 3000 can be ffdshow v1.00 final :P

[swalker]

@tetsuo55 and therealjoeblow
I have fixed at rev 2990. Thank you for report and sorry for late reply.

tetsuo55 and therealjoeblow, have either of you seen the same issue with AC-3 over SPDIF?

[Kurtnoise]

@devs: could you sum up somewhere (in the wiki for example ?) which lib(s) must be compiled mandatory w/ gcc ?

[albain]

@Albain

AutoCrop is still a bit buggy after your changes in rev 2996. At tolerance 40 (default) it will crop parts of the video. To be more precise, it actually replaced the top/bottom parts of the video with black bars. The output resolution did not change.
The problem does not happen with tolerance 10.
I tested with a video that did not have any black bars, so AutoCrop should have done nothing in that case.

I'm using it. Whatever I do with the autocrop configuration and/or sources, the output is just the same. No other filters are used.


Hi,

do you have samples so that I can test with ?

Thanks

Damien

[tetsuo55]

tetsuo55 and therealjoeblow, have either of you seen the same issue with AC-3 over SPDIF?
i have not

[STaRGaZeR]

Sure, here you have one: http://www.megaupload.com/?d=OF3EIVF2 (144MB)

I'm unable to make it work with any source, not specifically this one. It doesn't crop anything.

[haruhiko_yamagata]

@devs: could you sum up somewhere (in the wiki for example ?) which lib(s) must be compiled mandatory w/ gcc ?
Please read our wiki (http://ffdshow-tryout.sourceforge.net/wiki/devel:building#which_compiler_to_use).

[clsid]

For kerneldeint and TomsMoComp I recommend using GCC as well. Gives better performance than ICL10.

[Kurtnoise]

ok, thanks...I was blind this morning.

[haruhiko_yamagata]

For kerneldeint and TomsMoComp I recommend using GCC as well. Gives better performance than ICL10.
OK, updated the wiki.

[albain]

Hi,

do you have samples so that I can test with ?

Thanks

Damien

Okay, I have tested with your sample and it works (with both tolerances 10 & 40) : the slight vertical black bars are removed. Maybe you don't have the right revision ??

@clsid : indeed when the tolerance is too high it will cut some parts of the video (horizontally and/or vertically) but it won't add black bars, if you resize the window of your player you will see those black bars disappear.
The right sample is to have blue bars in the video. I will try to upload a such sample.
Sample :
Sample (http://damienbt.free.fr/Sequence02.avi)

So a lower tolerance should be set by default and also there are 2 kinds of tolerances which I calculate and compare to the tolerance parameter :
1/ Tolerance inside a line : it should have the same luminance on all its length (standard deviation should be low). However sometimes there may be a logo on the black bars.
2/ Tolerance between 2 lines : both should have the same luminance (average luminance should be equals)

Maybe those 2 should not be compared in the same way or maybe an additional parameter is necessary to tune autocrop.

[STaRGaZeR]

Yes albain, I'm using the right revision. I was using my own build but I just downloaded xvidvideo.ru's to be sure and it still does nothing. I've it configured like this:

http://thumbnails6.imagebam.com/3880/fc493c38793625.gif (http://www.imagebam.com/image/fc493c38793625)

That sample has wide vertical and horizontal black bars. I get nothing from any of the options. It must be something in my side if it works for you, but what?

[clsid]

@clsid : indeed when the tolerance is too high it will cut some parts of the video (horizontally and/or vertically) but it won't add black bars, if you resize the window of your player you will see those black bars disappear.
The right sample is to have blue bars in the video. I will try to upload a such sample.
So a lower tolerance should be set by default and also there are 2 kinds of tolerances which I calculate and compare to the tolerance parameter :
1/ Tolerance inside a line : it should have the same luminance on all its length (standard deviation should be low). However sometimes there may be a logo on the black bars.
2/ Tolerance between 2 lines : both should have the same luminance (average luminance should be equals)

Maybe those 2 should not be compared in the same way or maybe an additional parameter is necessary to tune autocrop.
A few comments and ideas:
* I think the tolerance option should be removed. The average user will have no clue what value to set there. So lets not complicate things for them. The less unnecessary options the better.
* Some fixed tolerances should be set internally. I am sure that the feedback of some of the regular testers here can help to find good values.
* Different constraints should use different tolerances.
* Perhaps chroma values should also be taken into consideration? The pixels in a line should have approximately the same color, not just the same luminance.
* Is your algorithm designed to crop black bars only, or does it support other colors? Restricting the algorithm to black only, could probably simplify the algo. Instead of the pixels having almost same color, the algo could then check if they are all (almost) black.
* Logo detection: perhaps allow a small range of the pixels in a line to have different color (non-black)? For example, take the first and last pixel in the line that have a 'different' color than the rest. If the distance between those two pixels is less than 10-15% of the length of the whole line, then there might be a logo.

[therealjoeblow]

tetsuo55 and therealjoeblow, have either of you seen the same issue with AC-3 over SPDIF?

I'm pretty sure I only saw it with DTS. That's why it took me so long to figure out what the issue really was, because it only occurred from time to time and I wasn't paying particular attention to the source.

[albain]

A few comments and ideas:
* I think the tolerance option should be removed. The average user will have no clue what value to set there. So lets not complicate things for them. The less unnecessary options the better.
* Some fixed tolerances should be set internally. I am sure that the feedback of some of the regular testers here can help to find good values.
* Different constraints should use different tolerances.
* Perhaps chroma values should also be taken into consideration? The pixels in a line should have approximately the same color, not just the same luminance.
* Is your algorithm designed to crop black bars only, or does it support other colors? Restricting the algorithm to black only, could probably simplify the algo. Instead of the pixels having almost same color, the algo could then check if they are all (almost) black.
* Logo detection: perhaps allow a small range of the pixels in a line to have different color (non-black)? For example, take the first and last pixel in the line that have a 'different' color than the rest. If the distance between those two pixels is less than 10-15% of the length of the whole line, then there might be a logo.

The algorithm will work for coloured bars too (which can occur even if it is not common)
Okay to remove the tolerance, but as you said tests will be needed with samples : bad sample (such as vhs capture), a good sample, some samples with a logo

[Inventive Software]

Maybe rev 3000 can be ffdshow v1.00 final :P

Nah, they're saving that for rev 4000! :p

[haruhiko_yamagata]

Maybe rev 3000 can be ffdshow v1.00 final :P
Congratulations, you have gotten it.

[clsid]

There seems to be a bug in ffdshow that causes Explorer to crash on Windows 7 (build 7231).
Last known good revision is 2992. First known bad revision is 2996. I will try to narrow it down further.
Any ideas on what might be the cause?

[Blight]

clsid:
Possibly due to the iffdecoder com object api fixes introduced in build 2987? I know it's earlier than 2992, but it's pretty close and a 3rd party app using the api may crash, taking explorer with it. Perhaps some plugin that uses ffdshow to get a thumbnail image.

[Spec-Chum]

I know this question has been asked before, but I can't seem to find a definative answer, does ffdshow apply the +10db to the LFE channel when decoding ac3/dts/flac?

Also, is it true that bass redirection replaces the LFE channel instead of adding to it? My av amp adds either 0-15db to the SW input, but I just can't get it to sound right.

Many thanks

[clsid]

clsid:
Possibly due to the iffdecoder com object api fixes introduced in build 2987? I know it's earlier than 2992, but it's pretty close and a 3rd party app using the api may crash, taking explorer with it. Perhaps some plugin that uses ffdshow to get a thumbnail image.
I just finished installing Windows 7 build 7231 and I don't get any crashes myself. The crash was reported to me by someone else. I'll try to get more details from that user.

[haruhiko_yamagata]

There seems to be a bug in ffdshow that causes Explorer to crash on Windows 7 (build 7231).
Last known good revision is 2992. First known bad revision is 2996. I will try to narrow it down further.
Any ideas on what might be the cause?
Rev 2994 is most likely.
I think the user has a file that makes ffdshow crash. I need that file.

[clsid]

I think it may have been a false alarm.

[albain]

Same thing here, I had crashes with earlier revisions but not anymore on recent ones (since the boost library updates)

[her34]

wmv files broken in rev2954 and rev2968

works in rev2946

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

wmv still broken in rev2992

[ipanema]

I have fixed the limitation that ffdshow required dimension of the video at rev 2994.
Could you remove SPS and PPS from the dwSequenceHeader as a test? I'm not sure if it makes a difference though.

Sorry fo the delay in replying. I'm not sure what you mean. The apparent requirement for the video dimension to be filled in was just to get the pins to connect correctly - it was just an extra observation.

Do you mean that I should set the dwSequenceHeader to NULL? But that would deprive the decoder of all the info in the SPS and PPS which decoders seem to require (and largely ignore corresponding info in the main part of the MPEG2VIDEOINFO structure).

The problem of the decoded H.264 being corrupted still exists in rev3004 that I've just installed and tried out.

[haruhiko_yamagata]

Sorry fo the delay in replying. I'm not sure what you mean. The apparent requirement for the video dimension to be filled in was just to get the pins to connect correctly - it was just an extra observation.
Yes.

Do you mean that I should set the dwSequenceHeader to NULL? But that would deprive the decoder of all the info in the SPS and PPS which decoders seem to require (and largely ignore corresponding info in the main part of the MPEG2VIDEOINFO structure).

Yes, and in that case, decoders can extract the dimensions from the stream as far as the stream has SPS and PPS. Just as a test.

[Gleb Egorych]

There is a problem with ffdshow and DVBViewer. Looks like a bug in DVBViewer source filter that confuses ffdshow (from beta6 to r3004).

On mono channels (MPEG2 video + MP2 audio) with DVBViewer I had no sound, so I made a discovery and supposed that DVBViewer sent wrong channel number to decoder.
I tested all available options for MP2 decoding, here are the results:

libmad: detects input as stereo and gives no output, info page is blank.
mp3lib: detects input as stereo and outputs as stereo.
libavcodec: detects input as mono and outputs as mono.

Looks like libavcodec is the most foolproof, but by default libmad is used for MP2. So I believe libmad has higher quality (?).

With another DVB program mono channels are perfeclty detected and played with all three libraries.

[Gleb Egorych]

http://www.gametrailers.com/video/preview-hd-prototype/49703
...
wmv still broken in rev2992
I confirm, broken in 3004, works in 2940.

[haruhiko_yamagata]

There is a problem with ffdshow and DVBViewer. Looks like a bug in DVBViewer source filter that confuses ffdshow (from beta6 to r3004).

On mono channels (MPEG2 video + MP2 audio) with DVBViewer I had no sound, so I made a discovery and supposed that DVBViewer sent wrong channel number to decoder.
I tested all available options for MP2 decoding, here are the results:

libmad: detects input as stereo and gives no output, info page is blank.
mp3lib: detects input as stereo and outputs as stereo.
libavcodec: detects input as mono and outputs as mono.

Looks like libavcodec is the most foolproof, but by default libmad is used for MP2. So I believe libmad has higher quality (?).

With another DVB program mono channels are perfeclty detected and played with all three libraries.
If you have off line file that can reproduce the issue, please send us one.

[ipanema]

OK I set the dwSequenceHeader to NULL and filled in some of the fields in the main part of the media type structure. The values should be correct because I'v read them from the SPS and PPS of the file.

It seems to play pretty much the same. Most of the frame is grey blockiness but there are patches of near-perfectly decoded video.

Here is a dump of the media type structure in case it helps:


- mt
+ 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
+ pUnk 0x00000000 IUnknown *
cbFormat 136 unsigned long
+ pbFormat 0x0239af20 "" unsigned char *


- pMVI
- hdr
+ rcSource {top=0 bottom=1088 left=0 right=1440} tagRECT
+ rcTarget {top=0 bottom=1088 left=0 right=1440} 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 1440 long
biHeight 1088 long
biPlanes 0 unsigned short
biBitCount 0 unsigned short
biCompression 875967080 unsigned long
biSizeImage 0 unsigned long
biXPelsPerMeter 0 long
biYPelsPerMeter 0 long
biClrUsed 0 unsigned long
biClrImportant 0 unsigned long
dwStartTimeCode 0 unsigned long
cbSequenceHeader 0 unsigned long
dwProfile 77 unsigned long
dwLevel 40 unsigned long
dwFlags 0 unsigned long
- dwSequenceHeader 0x0239afa4 unsigned long [1]
[0] 0 unsigned long

[Gleb Egorych]

If you have off line file that can reproduce the issue, please send us one.
No, sample is useless, because only live playback is affected. If record TS file and play it even in DVBViewer itself then there is no problem.

[haruhiko_yamagata]

OK I set the dwSequenceHeader to NULL and filled in some of the fields in the main part of the media type structure. The values should be correct because I'v read them from the SPS and PPS of the file.

It seems to play pretty much the same. Most of the frame is grey blockiness but there are patches of near-perfectly decoded video.

Here is a dump of the media type structure in case it helps:
Thank you for testing anyway. I'll think about this.

[haruhiko_yamagata]

No, sample is useless, because only live playback is affected. If record TS file and play it even in DVBViewer itself then there is no problem.
OK, please send the file to me anyway. MPEG-2 + mono audio is not so common in my collection. I'll try to simulate imaginable mediatypes.

[clsid]

I propose releasing Beta 7 sometime next month. Of course all regressions since beta 6 should be fixed first.

Known regressions:
- WMV3 decoding crash. This is a bug in FFmpeg code. Will hopefully be fixed soon.
- SPDIF related issues? Can anyone who suffers from this problem summarize the problem, including last known good revision and first known bad revision?

If there is anything I forgot, please let me know.

Improving AutoCrop before releasing beta 7 would be nice. But since it was broken before, not a requirement.

@Haruhiko, do you have any plans for changes that you would like to include in beta 7?

[haruhiko_yamagata]

@Haruhiko, do you have any plans for changes that you would like to include in beta 7?
I'm trying to fix libavcodec MPEG-2 timestamps calculation.
Next month is good. I would call it RC1.

[ipanema]

Haruhiko. I just tried to PM you a debug log as requested, but after sending it the Control Panel still says I have 0 sent messages so I do not know if the message was really sent - there were no error messages.

If you don't receive it please let me know.

[Gleb Egorych]

OK, please send the file to me anyway. MPEG-2 + mono audio is not so common in my collection. I'll try to simulate imaginable mediatypes.
Here you are: http://www.mediafire.com/?tobwmzjokzn

[MatMaul]

an other issue :
ffdshow don't get back to ac3 decoding after a switch to eac3.
so with my dvb software change from an ac3 track to an eac3 track is ok but not the other way around.

[albain]

I propose releasing Beta 7 sometime next month. Of course all regressions since beta 6 should be fixed first.

Improving AutoCrop before releasing beta 7 would be nice. But since it was broken before, not a requirement.

I am working on it (improvements of the algorithm : temporal analysis added, tuning of the parameters)

I will release binary builds links on this forum only for testing purposes.

If some have samples to test with (with vhs quality vs dvd quality, with logo) I am interested.

an other issue :
ffdshow don't get back to ac3 decoding after a switch to eac3.
so with my dvb software change from an ac3 track to an eac3 track is ok but not the other way around.
How does the streams switching occur ? Is it made within FFDShow internal audio splitter or from an external audio splitter ?
Do you have a sample ?

[MatMaul]

How does the streams switching occur ? Is it made within FFDShow internal audio splitter or from an external audio splitter ?
Do you have a sample ?
It is internal to ffdshow.
My dvb software uses the same decoder for ac3 and eac3 decoding (they use the same mediatype anyway if I remember correctly).
When a switch occurs the graph isn't rebuild, there is no connection or reconnection of the filters, and the dvb soft doesn't "warn" in any way the decoder that the codec have changed.
perhaps we need to separate the ac3/eac3 decoding as we do with ac3/mp2 if you think this is not the responsability of ffdshow to detect the change.
The weird thing is it works great when switching from ac3 to eac3 (I can see the codec change in the info tab of ffdshow).

EDIT : I know you are french so if you have access to a dvb-t tuner you can test that with the software I am talking about :
http://pouchintv.baysse.fr/forum/
just switch from an HD channel (eac3) to an SD channel and set the audio track to ac3.

[haruhiko_yamagata]

OK I set the dwSequenceHeader to NULL and filled in some of the fields in the main part of the media type structure. The values should be correct because I'v read them from the SPS and PPS of the file.

It seems to play pretty much the same. Most of the frame is grey blockiness but there are patches of near-perfectly decoded video.

I think ffdshow's access unit parsing is not enabled for your filter because your filter does not set file name on connection. If it is a file, please set file name in FILTER_INFO::achName. But if it is a live stream, it does not have file name and extension.

It was AVI files that I had to add that broken hack.
AVI splitter and "Neuview Source" (http://www.neuviewed.com/neuview6) use MEDIASUBTYPE_H264 and use start code. This is OK, but it doesn't have access unit delimiter at all. One DirectShow sample is one access unit in this case. So if ffdshow enables access unit parsing that depends on access unit delimiters, it won't find any access units.

That's why ffdshow has to look at the extension of the file name. AVI splitter set file name on connection, no problem. However, Neuview Source does not set file name at all.

If the file name is NULL, ffdshow has no hint if it should parse access units depending on access unit delimiter. Now ffdshow parses access units if the file name extension is NULL. I have added workaround to find "Neuview Source" in the upper stream and if it is detected, ffdshow does not parse access units.

I'll commit this local change soon.

Of course the best solution is to parse access units without depending on access unit delimiters. I know what I should do, but it's too hard.