Virtualdub problems

[Qyot27]

Or just say 'screw it', and use mpv.

And even though the announcement is right there on the front page on googlecode, FFMS2 moved to Github. Those looking for a build of 2.19* can get one here:
http://forum.doom9.org/showthread.php?p ... ost1643738

*it's the C-plugin

The revision number on future releases will change (read: shift downward), since I'm not entirely satisfied with the method I used this time. I'll probably move to a master+c_plugin notation using more sophisticated git rev-list trickery.

[mirkosp]

Is the colour fuckup of the 2.19RC1 fixed or is it still around in the final? I've just switched so L-SMASH Works so I wouldn't even know...

[Qyot27]

I don't know. I wasn't aware there was a color issue since there was no reference to such a problem on doom9 or the issues area on googlecode/Github. The closest thing I could find was a h264 fullrange thing that actually seems to have been a problem since 2.16.



And in totally unrelated news, actual movement on implementing HEVC support in Matroska (and Opus in Matroska is now officially no longer regarded as experimental; use mkvmerge 6.4.1*), experimental support for HEVC muxing/demuxing in L-SMASH, but any further movement on the decoder is still quiet on the libav-devel mailing list, and likewise silent for any input and output modules in x265 to make it easier to put video through.

*I cheated on Daybreak by using a pre-release version of it from just shortly after it got official.

[mirkosp]

My bad, it was in the 2.18 RC1 (at least that's when I realized there was the bug). Anyway, took me a bit to hunt the images, and I guess many won't see the difference, but here:
ffvideosource 2.18 RC1: http://www.abload.de/img/1314ff7hux8.png
lav video+madvr: http://www.abload.de/img/1314cccpmadvrdhkj6.png
I most easily notice the difference in the background.

[Qyot27]

I can barely see it by swapping back and forth between the images in Firefox. Is there a known good build of FFMS2 where the problem doesn't occur? Is it there in the build I posted of r836/2.19?

I have a hunch it may have been introduced either in r697 or r719. If it was r719 then the problem might actually be in how SWScale handles things, and that means that the issue is highly build-specific (meaning, branch-specific or age-specific depending on how recent the libraries used were) rather than in FFMS2's code itself.

[mirkosp]

Haven't checked with 2.19, but I too think it's probably SWScale, as I'm guessing this happens when ffms2 has to convert colourspace (which, with 10bit input, means always).
I'll be mean and say I don't particularly care about it, though, since I've already switched to L-Smash Works...

[Qyot27]

Fair enough.

[l33tmeatwad]

I definitely think L-SMASH-Works is better, but the lack of publicity really is hindering its adoptions rate. I probably wouldn't have discovered its existence had it not been for mirkosp telling me about it.