ffdshow tryouts project: Discussion & Development

[mandarinka]

Originally Posted by j7n

Is it known that still frame Grabbing doesn't work on oddball width (mod-2) video? I get a skewed picture with alternating red, green and blue lines in the BMP output, as if the row length was specified incorrectly. The position of the Grab filter makes no difference. Playback is correct. I can capture frames if I use AviSynth with AddBorders(0,0,2,0) above Grab, which adds a black column to bring the width to mod-4.

This is weird, because grab definitely used to work with non-mod4. If you need this feature, revert to some older build. (BTW if you by chance isolate at which revision this got broken, post it here, even if currently nobody is willing to fix it... it might be useful to somebody.)

Edit: I have revision 4499 (2 years old by now) installed on W8.1 64 and it works with 714x478 video (both 10-bit and 8-bit H.264). Note that I have SSE2-capable CPU, it might be different on processors without that. Also maybe try if it starts to work if you disable decoding in ffdshow and use it as a postprocessor after LAV video. Proofs

[clsid]

You don't have to bother testing that older version, because nothing has changed with regard to the Grab filter. In fact, there haven't been any significant changes to ffdshow at all in the past years.

I can confirm the problem with mod2 width for BMP. PNG output works ok, so use that, or use Resize&Aspect to expand to a multiple of 4.

[mandarinka]

Ah, I see, I didn't try BMP. It didn't occur to me that the trouble could actually be just in the output part (IIRC png uses different colorspace). That is pretty acceptable workaround, too.

[j7n]

I do have SSE2, but I find PNG too slow to be practical for any kind of screen grabs without a computer from space. I usually take dozens and discard most that don't show what I want. It would be cool if the quality slider that doesn't do anything could perhaps adjust the PNG compression between none and max. I would of course use no compression for temporary grabs.

The workaround with AddBorders(0,0,2,0) works for me. I then easily crop off the extra columns with IrfanView. As far as I understand both BMP and PNG are in RGB24 color space. Here is how a broken still frame looks like: 710*480

[mandarinka]

Originally Posted by j7n

I do have SSE2, but I find PNG too slow to be practical for any kind of screen grabs without a computer from space. I usually take dozens and discard most that don't show what I want. It would be cool if the quality slider that doesn't do anything could perhaps adjust the PNG compression between none and max. I would of course use no compression for temporary grabs.

The workaround with AddBorders(0,0,2,0) works for me. I then easily crop off the extra columns with IrfanView. As far as I understand both BMP and PNG are in RGB24 color space. Here is how a broken still frame looks like: 710*480

Both is R/G/B 8/8/8 bit, but the arrangement of the channel can be different IIRC or something - BGR/RGB etc.

[foxyshadis]

Moved increasingly off-topic posts about audio sampling to audio forum.

[djonline]

There is no FFV1 version 3 in ffdshow ?
Is there is any vfw build of ffv1.3 for encoding/decoding ?

[HackAR]

I've written a neat Avisynth script to do some transformations on the videos. But it involves changing YV12 to YV16. If I create a avs file and load the video in it, everything displays fine. But if I put the same script into Avisynth section of ffdshow (so it is active with all videos), the output is shown in wrong colorspace and colors are displaced.

Anyone met this bug? Any idea how to solve it or is there a workaround?

[LigH]

I doubt ffdshow supports YV16...

[clsid]

Try converting back to a more common colorspace at the end of the script. Like RGB32.

[LigH]

YUY2 would be more appropriate. It has about the same amount of information (both YUV 4:2:2), just that YV16 is planar, and YUY2 is interleaved (packed pixels).

[HackAR]

Yes I did a major rearrangement in my filter (Planar YV16 to Packed YUY2)
Now it works almost well in ffdshow. There are still 2 things: for some reason ffdshow still tries to output in NV12, messing with chroma values. If I deactivate the 4:2:0 output modes, it chooses RGB . Only if I deactivate RGB output too, it stays with YUY2. Why?

Btw, all other processing steps are deactivated, only the AviSynth is active.

[foxyshadis]

YUY2 is probably the least-commonly output colorspace of all, so it's no surprise it's the victim of driver and ffdshow bugs. It's chosen dead last because compatibility is so low.

[HackAR]

My first chose was YV16
But I assumed ffdshow outputs the best matched (and supported) colorspace. I was very surprised about 4:2:2 to 4:2:0 and also about YVU to RGB conversions.

[shae]

Is ffdshow-tryouts still the recommended way to add video/audio processing over other decoders (such as LAV)? For example, I want to get a histogram.

[LigH]

With both numerous built-in post-processing filters and the additional support for AviSynth filter scripts, ffdshow is probably still unrivaled.

[HackAR]

Yes, if ffdshow dies, an important and unmatched piece of software will be lost.

[clsid]

ffdshow is already dead. There are no active developers and there haasn't been any serious development in years.

Of course, it will always remain available in its current form.

[mandarinka]

That's the upside of windows ecosystem - you can use software that is unmaintained, and stability of frameworks like dshow sorta give it chance to work with newer components.

Hmm, now I realise that when I'll get 64bit MPC/LAV Video/MadVR now, I won't be able to use FFDshow for decimating, IVTCing and other such things... I hope having a parallel 32bit and 64bit components is going to work.

[madshi]

Parallel installation works just fine, no problems whatsoever. And for decimating & IVTC madVR's forced film mode should do the trick. It does even things like 720p60 -> 720p24 decimation etc...