haasn
commented
7 years ago From the log/file, it seems to get decoded as bayer_rggb16 and then converted to rgb24 by swscale. So this would be a swscale bug, not an mpv bug. (Unless mpv gets native support for bayer_rggb16, which seems unlikely.) The forum post also seems to indicate that this is an issue with ffmpeg's bayer_rggb16 -> rgb24 conversion.
That said, you can use the -vf lut3d command with mpv as well.
revast
mpv 2:0.27.0~xenial1
FFMPEG has support for Magic Lantern .mlv files for quite a while now, so has mpv in consequence, but they are all played back with a greenish color tint - this is also the case with ffmpeg git master and mpv 2:0.27.0
At the MagicLantern Forum, there is also a talk about this greenish issue, they call it an issue with black level decoding.
As for now, I use ffplay -vf lut3d=/opt/FFplay_mlv_dump.cube with the .cube correction file posted in the same forum thread to circumvent the problem, but this is a suboptimal workaround (and does not work with mpv as far as I know).
I also asked about this in FFMPEG IRC channel and was pointed here.
Reproduction steps
mpv 10bit.MLV
Expected behavior
Video gets shown with right colors.
Actual behavior
Video has greenish tint / wrong black level decoding.
Log file
https://pastebin.com/8WLGR6w0
Sample files
Test file: http://openartist.org/magiclantern/10bit.MLV even more samples: http://www.magiclantern.fm/forum/index.php?topic=11899.0
I have used the little cross-platform floss c++/qt5 MLV App which is kind of a developer/converter/player for .mlv files, they get it right with the colors, maybe there is knowledge to dock on. Or at mlv_dump, which is the reference implementation.