ffdshow tryouts project: Discussion & Development

[Eragon4ever]

I would say:

Indeterminate state: First try advanced connection method, if it fails try classic connection method.

[Leak]

Agreed - those options really are named a bit awkward nowadays.

Originally Posted by haruhiko_yamagata

I would like to rename "Use overlaymixer" -> "Set pixel aspect ratio in output media type" and add tooltip hint

Hmmm...

Unchecked: Use classic connection method
Checked: Use an advanced connection method that includes pixel aspect ratio (SAR) and interlacing information when connecting with the next filter (usually a video renderer).
Indeterminate/grayed: Try advanced connection method first and fall back to classic connection method if it fails.

(formerly called "Use overlay mixer")

and rename "HW deinterlacing"->"Set interlacing related flag in output media type"

I would have called it "Set interlace flag in output media type":

Send interlacing related information obtained from the input stream or ffdshow's internal decoders to the next filter.
Some filters (like video renderers) will use this information to deinterlace the video if neccessary.

This is just for informing the downstream filters - the actual result will depend purely on the implementation of these filters.

(formerly called "HW deinterlacing")

Please fix my English and anything.

I put the "formerly called ..." at the end of the tooltip, since information about what the option does is probably more relevant.

EDIT: Whoa... 2 other replies while I was writing my reply...

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

[LoRd_MuldeR]

Originally Posted by haruhiko_yamagata

Please uncheck "Allow output format changes during playback" and try again.

Yup, that fixes the problem

Do I still need to find the revision that introduced the bug?

Originally Posted by Episode

@LoRd_MuldeR, I'm betting this has something to do with graphic card's drivers or operating system. It works fine for me with Nvidia 7800GS with 165.01 driverset under Windows XP.

I've got an ATI Radeon 9800 Pro, running with latest Catalyst 7.4 drivers under Windows XP.

[GmorG McRoth]

Anyone else noticed performance drop between
ffdshow_rev1187_20070520_clsid.exe and ffdshow_rev1193_20070522_clsid.exe
I may be wrong and my testing is unscientific (using task manager), but it seems like with ffdshow_rev1193_20070522_clsid.exe i'm getting about 3-7% more CPU usage (tested on mpeg1 file and divx5 file)

My CPU is prescott 3.0 GHz
GFX is GeForce FX 5700
I'm using MPC with Haali renderer.

[Haali]

Btw, why do you even need that overlay mixer checkbox? I offer both mediatypes (VideoInfo2 first and VideoInfo after it) in my filters, and it seems to work quite good without any need for tunable settings. As for interlaced output, you can easily change the interlace mode with a dynamic mt change. If the only thing that you change is dwInterlaceFlags, then it doesn't cause any problems.

[haruhiko_yamagata]

Originally Posted by LoRd_MuldeR

Yup, that fixes the problem

OK, then I'll think what it means.

Do I still need to find the revision that introduced the bug?

No.

[LoRd_MuldeR]

Originally Posted by haruhiko_yamagata

OK, then I'll think what it means.

[haruhiko_yamagata]

Originally Posted by Haali

Btw, why do you even need that overlay mixer checkbox? I offer both mediatypes (VideoInfo2 first and VideoInfo after it) in my filters, and it seems to work quite good without any need for tunable settings. As for interlaced output, you can easily change the interlace mode with a dynamic mt change. If the only thing that you change is dwInterlaceFlags, then it doesn't cause any problems.

I agree most people including me don't need "Use overlaymixer" check box. I think this check box is historical stuff. On Windows Xp, it's almost useless.
On Windows 2000, when system default renderer is selected, overlaymixer will be used if checked, while old renderer will be used if unchecked.

As for HW deinterlacing, it's required because the interlacing flag is not always reliable.

Anyway, thank you for coming here.

[Peuj]

Originally Posted by B.F.

URL http://www.comq.ru/user/alex/pirates2/pirates2.mp4
Mpeg4AVC HighProfile video.
Picture is broken using ffdshow, mplayer or KMP.
Look normal using CoreAVC 1.2.

Originally Posted by chros

Confirmed with rev 1133, and it plays fine with CoreAVC 1.3 too (You sould report this in the coreavc thread, because this is the 1st time when coreavc is able to decode something that ffdshow isn't )

No matter, if I remux to mkv. Does the whole file produce this, or only this splitted chunk?

Originally Posted by akupenguin

I get artifacts when playing that in MPlayer, and I still get artifacts after remuxing to mkv, but if I demux to raw .264 and play that then it works. (had to demux with MP4Box; mkvextract refuses.) So... maybe a bug in lavc's AVC1 bitstream parser?

Hi,

So it's a libavcodec problem? does somebody has report the problem to the ffmpeg team?

[Thunderbolt8]

anything like multithreading/multi-cpu support planned for ffdshow ?

[haruhiko_yamagata]

@fastplayer, Eragon4ever, Leak
Thank you. Committed as rev 1200.

[Jeremy Duncan]

Hello,

I'm glad to see Leak's tweak added to FFDshow.

I just downloaded and installed FFDshow version 1198, clsid.
I then setup FFDshow as I usually do.
I set output to yv12, input to all supported raw video.
I then used only avisynth, and set the osd to show the nessessary frames, so I could tweak the new setting.
But if showed no frame change.

SetMemoryMax(1024)
FluxSmoothT(3)
ColorMatrix(Mode="Rec.601->Rec.709",scaling=2,threads=2)
MT("SeeSaw(NRlimit=0, NRlimit2=5, Sstr=2.40, Szp=1, Slimit=50, Sdamplo=16, Spower=1, sootheT=95, SdampHi=39)",3)
lanczosresize(1680, 1050)

I used the settings in post # 2
Link

The frontend I used was MPC, the one I lined to in the link above.

Previously, with Leak's other avisynth tweaked ffdshow, there was a few frames shown ahead and back, so I know that it shouldn't be zero.

Please fix this leak.

Edit. Oh, the movie was blade 1, the ntsc sddvd version.
If you look at page 6 in the link it will show you previous results using Leak's tweak.

[multiblitz]

Originally Posted by multiblitz

Has anyonw looked into this bug:

http://sourceforge.net/tracker/index...41&atid=867360

"When I build a graph with Haali-splitter, VC-1 codec from Microsoft, I have
a fine playback at 24 fps (HD-DVD-rip from my own Discs onto my media,
server, playing *.evo).

When I integrate ffdshow into the chain, re-clock reports not only 30fps,
but audio and video are heavily out of sync. It does not matter if I use
ffdshow as raw-postprocessor or if I use ffshow as VC-1-decoder as well. As
soon as ffdshow is in the video-chain, video and audio is out of sync
(beta2 release). "

?

If not, could you please be so kind ? I would love to use ffdshow as my playback/pq-tuning solution as well for HD-DCD, as my cinema has a pretty big screnn and ffdshow really shines...

As haali and all other active members are together here: Would it be possible to taggle this bug together ?

[haruhiko_yamagata]

Originally Posted by multiblitz

As haali and all other active members are together here: Would it be possible to taggle this bug together ?

I looked into this, I found the timestamps are set to increase 33.36ms (should be 41.6ms) for every frame.
I found no interlacing related flags are set for either for each samples or connection info.

I looked into livavcodec's vc1 decoder, it does not seem to find any information that can fix this issue. Perhaps I passed over it or it's not implemented (stored as "reserved").

But in fact MS decoder can decode properly connected to Haali's splitter.

When microsoft's DMO is called from ffdshow, the DMO does not return any usefull information.

When ffdshow is connect to the DMO's output pin, it does not send any usefull information.

So the information is hidden in the stream, but I cannot find it.
Haali, any advice is wellcome. Should I go to your thread?

[LoRd_MuldeR]

Originally Posted by haruhiko_yamagata

Please uncheck "Allow output format changes during playback" and try again.

I noticed that this bug is related to "Allow output format changes during playback" and "Set pixel aspect ratio in output media type". If I disable both of them, I get 'correct' video but without any pre-scaling applied. So it's not 4:3, as it should be. If I check "Set pixel aspect ratio in output media type" only, then I still get no pre-scaling! If I check "Allow output format changes during playback" only, then I get the bug, where the lower half of the video frame is filled with crap. Only both options enabled give good result!

[haruhiko_yamagata]

@LoRd_MuldeR
I still cannot reproduce.
I have added a small work around for this issue.
Please see if rev 1203 works.

If I check "Set pixel aspect ratio in output media type" only, then I still get no pre-scaling!

Output format change occurs just before the first frame is shown because AVI splitters do not give the SAR info in the connection process. So technically it's "during playback". I know it's not very user friendly but how should it be explained in the dialog?

[LoRd_MuldeR]

Originally Posted by haruhiko_yamagata

Output format change occurs just before the first frame is shown because AVI splitters do not give the SAR info in the connection process.

Thank you for looking into that issue.
I will test your workaround as soon as there's a new build available...

[LoRd_MuldeR]

Originally Posted by haruhiko_yamagata

@LoRd_MuldeR
I still cannot reproduce.
I have added a small work around for this issue.
Please see if rev 1203 works.

Yes, in rev 1203 I cannot reproduce the error any more

Nevertheless I still need to check both options ("Allow output format changes during playback" and "Set pixel aspect ratio in output media type") to make the video renderer pre-scale the video to the required aspect of 4:3. This combination worked with previous build too.

[haruhiko_yamagata]

Originally Posted by LoRd_MuldeR

Yes, in rev 1203 I cannot reproduce the error any more

Nevertheless I still need to check both options ("Allow output format changes during playback" and "Set pixel aspect ratio in output media type") to make the video renderer pre-scale the video to the required aspect of 4:3. This combination worked with previous build too.

Thank you for testing.
It's OK, because it's the default settings. On beta2a, it was necessary to change "Allow output format changes during playback" from intermediate state to checked.

[Haali]

Originally Posted by haruhiko_yamagata

I looked into this, I found the timestamps are set to increase 33.36ms (should be 41.6ms) for every frame.
I found no interlacing related flags are set for either for each samples or connection info.

I looked into livavcodec's vc1 decoder, it does not seem to find any information that can fix this issue. Perhaps I passed over it or it's not implemented (stored as "reserved").

But in fact MS decoder can decode properly connected to Haali's splitter.

When microsoft's DMO is called from ffdshow, the DMO does not return any usefull information.

When ffdshow is connect to the DMO's output pin, it does not send any usefull information.

So the information is hidden in the stream, but I cannot find it.
Haali, any advice is wellcome. Should I go to your thread?

The samples I have here have 30000/1001 fps interlaced set in the sequence header. I didn't investigate further, but I guess the stream is actually progressive with rff flags set similar to mpeg-2 case. The DMO Wrapper + DMO then ignore the interlaced part and output 24000/1001 fps progressive video.

Edit: I've checked the frame headers, and the streams indeed use TFF/RFF flags. I'll copy them into sample properties, and adjust timestamps slightly to account for RFF, but that's all I can do in the splitter.