Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Mandarinka]

Hello, I tried testing 2011-10-29 CCCP beta and found that h.264 video with non-mod4 width doesn't get displayed correctly (or rather, is fucked like this: http://i.imgur.com/SpvI7.png) with vsfilter active. I tried 714x480 8-bit and 718x480 10-bit h.264 videos, but the problem might happen with all codecs, it did occur when I set ffdshow to process raw video and used LAV video to do the actual decoding, outputting yv12. Forcing LAV video to output rgb32 makes the problem go away. Also, when I use ffdshow's grab, the cap (http://i.imgur.com/BaSdu.png) made by it is correct, even if the displayed video in mpc is broken.

System: Win XP SP3 Home/32-bit, K8 cpu, Radeon x700 running the 2010 legacy driver (latest available from AMD), mpc-hc and other playback components from 2011-10-29 beta.

Here's a sample that should be able to trigger the issue: http://www.mediafire.com/?vx9a6vn0eacz7y9

Edit: Reverting to latest stable (7-30) makes the corruption go away, but there is an ugly glitch, a green line on the right border (this time only 10-bit is affected): http://i.imgur.com/Kt15X.png. Again, this appears on display in mpc, but not in grab. (My, these padding bugs of vsfilter/ffdshow...)

[Lenmaer]

That problem also appears with older betas released after the latest stable (7-30).
I thought it was a common bug, so I never bothered to report it. Also I never had the chance to play one non-mod4 video using the latest stable.

You can also check it with "American.Horror.Story.S01E05.720p.HDTV.x264-IMMERSE" which is 1278x720P. It's also distorted, though it plays fine with VLC.

[JEEB]

Yes, low-mod pictures have always been a problem for VSFilter, and generally unrecommended to encoders because of this. Now we know exactly where it currently fails. Also, it irritates me that you didn't state the result of LAV Video->VSFilter with YV12 output, and instead talked about using tryouts' filtering capabilities for something. But since you mention that LAV Video's RGB output works, I will guess that VSFilter gives you those results no matter which filter gives it the YV12 YUV stuff. Thus limiting the problem to VSFilter, and 4:2:0 YUV.

When I was first confronted with this problem, it was that CoreAVC worked and -tryouts got a border. This was with a mod4 clip. The code for the border-adding was rather quickly found from -tryouts. The comment in there said "// vsfilter accepts only multiple of 8 on YV12.". Now, you can guess what kind of 1+1 thought chain went on in my head after that .

The border hack was removed, and mod4 clips worked fine. After I uploaded the then-current beta -tryouts sources onto my git repo, clsid then rather quickly merged this change onto mainline -tryouts (revision 3989).

Now, though, we have learned the true limitation of VSFilter's 4:2:0 YUV rendering, that is non-mod4. So now we either fix this, or add border hacks a la what was in -tryouts

[Mandarinka]

Oh, sorry, I thought it was more or less clear that LAV video -> vsfilter using yv12 is fine (non-ffdshow decoders generaly tend to be...) - that is why I didn't post that. Of course, I have no idea why it averts this. *Personally*, I only ever encountered the border padding (or border corruptions even) with ffdshow, not other decoders. However, tother people said things to the contrary to me, so who knows how it is in reality.

Before this though, there really have only been border padding issues (black bar, grey bar in older tryouts, now the black bar & the green column...), not a total snafu like this. I mean, my point wasn't really that there is a bug, more like that the bug has seen a regression

(P.S. Any more information or testing needed?)

[JEEB]

I thought it was more or less clear that LAV video -> vsfilter using yv12 is fine.

WHAT!?

Seriously? Can you post both the pin info of LAV Video connected to VSFilter, as well as VSFilter's pin info for in/out?

The picture itself should be pretty much the same, so I'm qu~ite surprised it fails, unless there is another workaround somewhere for something.

Edit: Just post the pin info for both (LAV Video/-tryouts), I'm quite interested in what's happening.

[Mandarinka]

Tryout (beta): "[OUT] Out" http://pastebin.com/az938v8i
vshitler - 
"[IN] Video": http://pastebin.com/2Xmkv1HB
"[OUT] Output": http://pastebin.com/eTRQJZ6G

(video is garbled with ^)

LAV Video (0.38): "[OUT] XForm Out": http://pastebin.com/mC9NuGwt
vshitler - 
"[IN] Video": http://pastebin.com/RSXNX0vn
"[OUT] Output": http://pastebin.com/Y4YHY5LJ

(video is fine with ^, no padding seen...)

This is just copypasted from mpc... if that is no good, I think I'll need some pointers as to how/with what to get the info.

Edit: this was taken after installing CCCP beta, so the vsfilter should be that same version in both cases.
Edit2: this is with the (20 mb) sample I posted above.
Edit3: Do you want these for the stable CCCP's ffdshow, too? (7-30's tryout padds with black bar for 8-bit video, and for 10-bit video, there is the green column on the border in addition to that.)

[JEEB]

Finally noted the sample, somehow passed my mind completely.

Also, quick testing with the 2011-11-03 beta:
- DSS2: -tryouts works perfectly, LAV Video borks as soon as you seek to another frame.
- DirectShowSource: -tryouts has a weird green line in the bottom, otherwise perfect, LAV Video works perfect.
- MPC-HC without VSFilter: -tryouts WorksJustFine. LAV Video as well.

And I cannot find anything that -tryouts would do in a special way in its sources, so I'm guessing it's VSFilter.
Full herp derp moodo, go! Will have to wait until Lord gets around...

[cyberbeing]

so I'm guessing it's VSFilter.

Then why does FFDShow -> FFDShow_Raw_Video_Filter without VSFilter in the graph produce the exact same problem?

I'm thinking the issue is that FFDShow is unable to output YV12 mod2 if the filter it's connecting to doesn't support that 1024 multiple padding which some directshow filters use? Maybe it's lying about its output pin and using unsupported padding anyway, which could explain the corruption with FFDShow_Raw_Video_Filter and VSFilter? Does that sound plausible?

Corrupted Output in FFDShow:

Code: [Select]

- Connection media type:

Video: YV12 714x480 (42:31) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 514560
cbFormat: 112

VIDEOINFOHEADER:
rcSource: (0,0)-(714,480)
rcTarget: (0,0)-(714,480)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000081
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 42
dwPictAspectRatioY: 31
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 714
biHeight: 480
biPlanes: 3
biBitCount: 12
biCompression: YV12
biSizeImage: 514560
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0
Correct Output in FFDShow:

Code: [Select]

- Connection media type:

Video: YV12 1024x480 (42:31) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 737280
cbFormat: 1152

VIDEOINFOHEADER:
rcSource: (0,0)-(714,480)
rcTarget: (0,0)-(714,480)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000081
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 42
dwPictAspectRatioY: 31
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1024
biHeight: -480
biPlanes: 1
biBitCount: 12
biCompression: YV12
biSizeImage: 737280
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

[JEEB]

I don't know if I can fix this any better, thus I modified the old VSFilter hack in -tryouts to match our results so far (link). Comments welcome.

Also, contained in today's beta.

[Mandarinka]

Thanks!

It seems to work, additionaly the green line on the border that happens in stable CCCP with 10-bit video (iirc, I'm sort of losing orientation already...) is gone now, so double hooray

Edit: Seems that green line thing is back. No idea why I got different results before, I must have overlooked something.
Edit2: I found that enabling some filter (OSD, or sharpen, prolly others too) makes the green line go away. That's what must have happened.

[JEEB]

I would love to have this properly fixed in VSFilter, though :/ (esp. the "breaking with mod2 height" which happens with both LAV Video and -tryouts) .

...and whatever breaks with -tryouts -> -tryouts raw video, but that's less important.

[Mandarinka]

That's weird... I actually never got a breakage with non-mod4 height (visible breakage at least) with stuff I encoded myself... are there any steps needed to reproduce that, or a sample?

(Hmm, unless there was always padding used to workaround, I guess that 2 pixels of height wouldn't be that obvious; however, it would show on mpc screenshots.)

[cyberbeing]

I'm not getting breakage or black borders playing videos with mod2 width & height using CoreAVC 3.0.1 or LAV Video 0.38 with VSFilter.

The problem seems unique to FFDShow (broken YV12 non-mod4 output) and Avisynth (which doesn't support non-mod4 YV12 output).

[JEEB]

I based my assumption on:

<Twilight-i5-Sparkle> yeah, sorry I just found a 712x478 sample which gives me a green screen
<Twilight-i5-Sparkle> *video area
<Twilight-i5-Sparkle> with lav video as well

(that's namaiki btw)

Granted, that's only mod2 height, width being mod4. Gonna make myself a mod2xmod2 sample and test with it :V .

...and Avisynth (which doesn't support non-mod4 YV12 output).

Also, uhm -- that's either an avisynth 2.5.x-related limitation or a limitation of VirtualDub (IIRC it was more strict than Avisynth itself in some ways resolution-wise).

"BlankClip(9000,714,478).ConvertToYV12()" WorksForMe in AvsPmod.

Edit: Also, definitely experiencing a green border with LAV Video + VSFilter with this sample.

[cyberbeing]

I just tested a 714x478 video and had no problem with CoreAVC or LAV Video + VSFilter. 

__________
CoreAVC YV12 mod2 output

BITMAPINFOHEADER:
biSize: 40
biWidth: 714
biHeight: 478
biPlanes: 3
biBitCount: 12
biCompression: YV12
biSizeImage: 511938
biXPelsPerMeter: 1
biYPelsPerMeter: 1
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020: 00 00 00 00 00 00 00 00 3b 5d 06 00 00 00 00 00 ........;]......
0030: 00 00 00 00 00 00 00 00 65 01 00 00 ef 00 00 00 ........e...ï...
0040: 00 00 00 00 00 00 00 00 28 00 00 00 ca 02 00 00 ........(...Ê...
0050: de 01 00 00 03 00 0c 00 59 56 31 32 c2 cf 07 00 Þ.......YV12ÂÏ..
0060: 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................

__________

LAV Video mod2 output

BITMAPINFOHEADER:
biSize: 40
biWidth: 714
biHeight: 478
biPlanes: 3
biBitCount: 12
biCompression: YV12
biSizeImage: 511938
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 ca 02 00 00 de 01 00 00 ........Ê...Þ...
0010: 00 00 00 00 00 00 00 00 ca 02 00 00 de 01 00 00 ........Ê...Þ...
0020: 00 00 00 00 00 00 00 00 3b 5d 06 00 00 00 00 00 ........;]......
0030: 00 00 00 00 00 00 00 00 ef 00 00 00 a0 00 00 00 ........ï... ...
0040: 81 25 01 00 00 00 00 00 28 00 00 00 ca 02 00 00 %......(...Ê...
0050: de 01 00 00 03 00 0c 00 59 56 31 32 c2 cf 07 00 Þ.......YV12ÂÏ..
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
__________

FFDShow (without mod-4 patch) corrupted mod2 output

BITMAPINFOHEADER:
biSize: 40
biWidth: 714
biHeight: 478
biPlanes: 3
biBitCount: 12
biCompression: YV12
biSizeImage: 512416
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0


pbFormat:
0000: 00 00 00 00 00 00 00 00 ca 02 00 00 de 01 00 00 ........Ê...Þ...
0010: 00 00 00 00 00 00 00 00 ca 02 00 00 de 01 00 00 ........Ê...Þ...
0020: 00 00 00 00 00 00 00 00 3b 5d 06 00 00 00 00 00 ........;]......
0030: 81 00 00 00 00 00 00 00 65 01 00 00 ef 00 00 00 .......e...ï...
0040: 00 00 00 00 00 00 00 00 28 00 00 00 ca 02 00 00 ........(...Ê...
0050: de 01 00 00 03 00 0c 00 59 56 31 32 a0 d1 07 00 Þ.......YV12 Ñ..
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
__________

Corruption like FFDShow is producing usually happens when a decoder is lying about its output pin. You may want to look into what is causing FFDShow's mod2 YV12 output (biSizeImage) to be larger than other decoders.

I also tested a 712x478 video as well and FFDShow (without mod4 patch) + VSFilter doesn't have corruption either?! In this case FFDShow's biSizeImage matches other decoders. So it may not even be a global non-mod4 problem, but only specific dimensions? No clue why namaiki is having issues, must be a problem with his system? A broken sample would help.

Also, uhm -- that's either an avisynth 2.5.x-related limitation or a limitation of VirtualDub (IIRC it was more strict than Avisynth itself in some ways resolution-wise).

That was with Avisynth 2.5.8, playing back an avs script in MPC-HC with Directshowsource and DSS2.

Edit:

Edit: Also, definitely experiencing a green border with LAV Video + VSFilter with this sample.

No problem with LAV Video 0.38 or CoreAVC 3.0.1 + VSFilter on my end with that sample. Only FFDShow (without mod4 patch) is corrupted.