ffdshow tryouts project: Discussion & Development

[haruhiko_yamagata]

Originally Posted by wozio

Isn't it VIDEOINFOHEADER2 set for each media sample passed to renderer?

Yes.

So only thing to do for decoder is to pass flags from encoded stream.

ffdshow pass interlacing flags only when "HW deinterlacing" is checked. Otherwise ffdshow sets the flag progressive. Most of DirectShow decoders have this kind of option.

It is up to renderer (or in fact drivers if we are talking about VMR) to detect correct deinterlacing mode.

Decoders can choose weave and bob.

[zambelli]

Originally Posted by haruhiko_yamagata

Yes.
ffdshow pass interlacing flags only when "HW deinterlacing" is checked. Otherwise ffdshow sets the flag progressive. Most of DirectShow decoders have this kind of option.
Decoders can choose weave and bob.

Correct. In most cases "weave" is the same as progressive (or no VIH2) since it instructs the renderer to simply leave the frames weaved as is. "Weave" basically means "don't touch".

Most decoders will signal AMINTERLACE_DisplayModeBobOnly when they want the renderer to deinterlace the video, but this doesn't imply that bobbing must be used. Depending on the VMR and its mode (VMR7 acts differently in regular vs YUV Mixing mode), same-framerate deinterlacing or double-framerate bobbing might occur. That part's up to the renderer and the video HW.

Furthermore, I've noticed that most GPU deinterlacers do a good job of detecting true interlaced vs progressive signaled as interlaced and adapting the renderered framerate on the fly. I encoded a video once of a 1-minute source where the first half was truly interlaced, and then the second half was the same as the first half but deinterlaced. The first half was encoded in VC-1 as field interlaced, and the second half was encoded as progressive - but the whole ASF file was signaled as interlaced. When decoded back via DXVA and VMR9, the first half was played back at 59.94 fps, and then at the midpoint the framerate started dropping until it reached 29.97 fps. I think I tested this on an Nvidia 6600 GPU.

[wozio]

Originally Posted by zambelli

Depending on the VMR and its mode (VMR7 acts differently in regular vs YUV Mixing mode

I noticed the same for VMR9 but I think it is not regular mixing vs YUV mixing but more non mixing vs mixing mode (as far as I can tell yuv mixing is almost the same as rgb mixing but without last step of converting to RGB and passing it as a output, but I'm trying it only with one HW and only in my own app so I probably messed something).

Originally Posted by zambelli

Furthermore, I've noticed that most GPU deinterlacers do a good job of detecting true interlaced vs progressive signaled as interlaced and adapting the renderered framerate on the fly. I encoded a video once of a 1-minute source where the first half was truly interlaced, and then the second half was the same as the first half but deinterlaced. The first half was encoded in VC-1 as field interlaced, and the second half was encoded as progressive - but the whole ASF file was signaled as interlaced. When decoded back via DXVA and VMR9, the first half was played back at 59.94 fps, and then at the midpoint the framerate started dropping until it reached 29.97 fps. I think I tested this on an Nvidia 6600 GPU.

Modern GPUs can do even more, for example regular film telecined material broadcasted with scrolling text in regular ntsc frame rate can be properly deinterlaced to maintain both ivtc and smooth text movement

One more thing to add here. On my HW (ATI X1650) renderer (VMR9) input colorspace must be set to NV12 for advanced deinterlacing to work. With other colospaces driver does simple bob. So I have to disable all other colorspaces in ffdshow to force NV12 output. It would be good to add some kind of list with possibility to prioritize proposed colorspaces. This is really done well in coreavc, there is a list with colorspaces and they are proposed downstream in order (it is possible to move colorspaces on list as weel as disabling some of them).

Anyway for me this HW deinterlacing setting in ffdshow is not needed and confusing.

[alter4]

Originally Posted by haruhiko_yamagata

I cannot reproduce.
What is your CPU? Which build do you use?
What is the size (width, height) of the video?

My CPU is pentium 4 (model 631) video size 540x300
which build is not important, bug appears in all builds

[iron2000]

Originally Posted by wozio

Anyway for me this HW deinterlacing setting in ffdshow is not needed and confusing.

Wow, sure did confuse me.

So when checked the next filter after ffdshow will know if the video is interlaced or not and when unchecked ffdshow will mark all videos as deinterlaced?

What if the driver has more method other than weave and bob, does it mean that ffdshow restricts it only to the 2 methods?

The guide at MeWiki is a pretty good start, hope that it will cover all the options in the future or maybe put them up on a ffdshow-tryouts wiki.

[haruhiko_yamagata]

Originally Posted by iron2000

Wow, sure did confuse me.

So when checked the next filter after ffdshow will know if the video is interlaced or not and when unchecked ffdshow will mark all videos as deinterlaced?

Yes. As a hint for downstream. But downstream filter may detect the stream interlaced (or telecined DVD) and try to deinterlace (IVTC). It's downstream's choice.

What if the driver has more method other than weave and bob, does it mean that ffdshow restricts it only to the 2 methods?

It's just flag. Downstream filters may ignore the flag. You can force the downtream filter to ignore the upper stream's flag, if the filter supports the configuration.

[vlada]

Originally Posted by iron2000

What if the driver has more method other than weave and bob, does it mean that ffdshow restricts it only to the 2 methods?

As zambelli already said, weave is not a deinterlace method. It means, that the renderer treats the video as if it was progressive (no matter if it really is). So the only choice for an interlaced video is (smart) bob. There are usually no other deinterlace methods. But if you had for example a graphic card with more deinterlace algorithms, you'd have to choose them in driver properties. There's no way how ffdhsow could control it.

[cc979]

on ffdshow svn version 1122 is there a typo on
line 124 of makefile_c.inc

should it be this ?

--def $(GCCDEF) $(GCCDLLENTRY) -o $@ $(OBJS) -lpthread $(GCCLIBS)

as it did not compile before i changed it

[_xxl]

I would like to uncheck TomsMoComp,kernelDeint and x264 from msvc 2003(2005) solution files.

TomsMoComp,kernelDeint should be compiled by ICL and x264 by GCC.

[zambelli]

I have a question regarding the Audio Decoder Configuration option under Output named "Don't use WAVEFORMATEXTENSIBLE header when not needed"...

Would it be possible to make this into a dropdown list with options:
* Never use WAVE_FORMAT_EXTENSIBLE
* Don't use WAVE_FORMAT_EXTENSIBLE when not needed
* Always use WAVE_FORMAT_EXTENSIBLE

As it is right now, I can prevent Ffdshow from outputting WAVE_FORMAT_EXTENSIBLE headers, but I can't force it to output WAVE_FORMAT_EXTENSIBLE headers.

[check]

The second option would be better worded "Only use when needed". Double negatives suck :P

[Leak]

Originally Posted by drevil_xxl

TomsMoComp,kernelDeint should be compiled by ICL and x264 by GCC.

No argument about x264 from me, but what about us folks who only have MSVC (and of course GCC, since it's free)?

And isn't there a separate ICL9 project anyway?

[clsid]

ICL9 binaries for TomsMoComp and kernelDeint are in the SVN. So there is no need to compile them.

I agree that they should be removed (not just unchecked) from the main msvc solution files. There are separate project files present for them anyway.

[TheShadowRunner]

2 little suggestions:

- for the installer: if it could remember the language used during previous ffdshow installations.

- for ffdshow: for the "logoaway" feature, if we could have a feature for setting the position easily. Like a preview either in red or as negative image, to set the position accurately, and then we would disable it for the normal processing.
Hope you see what i mean ^^;
Later,

TSR

[clsid]

Originally Posted by TheShadowRunner

2 little suggestions:
- for the installer: if it could remember the language used during previous ffdshow installations.

That is not possible with the install software that we use.

[haruhiko_yamagata]

Originally Posted by alter4

My CPU is pentium 4 (model 631) video size 540x300
which build is not important, bug appears in all builds

Thank you. Now I can reproduce the bug.
The debug may be hard because it's random and rare.

[Seb.26]

Hi world !

is there a way to disabling the TV->PC level remapping done when input is YV12/YU2 and output is RGB32 ?!
( = just output same level in RGB32 ... )

Thanks !
Seb.

[_xxl]

I have added SSE3 & SSSE3 detection code:
Patch
http://rapidshare.com/files/28159079/ssse3.rar.html
Bin
http://rapidshare.com/files/28158873..._test.exe.html
Yasm 0.6.0 is needed.
If anybody is interested in testing and helping me to fix it.
This will be used in xvidcore 1.2 and x264.

[Px]

Originally Posted by drevil_xxl

I have added SSE3 & SSSE3 detection code:
Patch
http://rapidshare.com/files/28159079/ssse3.rar.html
Bin
http://rapidshare.com/files/28158873..._test.exe.html
Yasm 0.6.0 is needed.
If anybody is interested in testing and helping me to fix it.
This will be used in xvidcore 1.2 and x264.

Intel E6300

Intel P3-450


Also small speedup compared to 1090 icl9

1090
Null
User: 44s, kernel: 0s, total: 44s, real: 46s, fps: 26.4, dfps: 25.5
o/m
User: 45s, kernel: 0s, total: 45s, real: 46s, fps: 26.1, dfps: 25.6
1124
Null
User: 43s, kernel: 0s, total: 43s, real: 44s, fps: 26.9, dfps: 26.3
o/m
User: 44s, kernel: 0s, total: 44s, real: 45s, fps: 26.5, dfps: 25.9

[_xxl]

Intel E6300 doesn't have 3dnow! ext.
3dnow! ext can't be disabled...