FRAPs captured video tinted green by affine
Brought to you by:
ddennedy,
lilo_booter
Menu
▾
▴
#230 FRAPs captured video tinted green by affine
Hi, have attached 6 files, some of them are quite large due to the method of capture (FRAPs captures game footage with lossless luma).
Here is a description of the files that also exists in the file called 'WhatisHere'
sh4yuvj420FRAPS.avi - Original FRAPs
sh4yuv420ffmpeg.avi - Created with ffmpeg -i sh4yuvj420FRAPS.avi -qp 0 -vcodec libx264 -acodec pcm_s16le -pix_fmt yuv420p sh4yuv420ffmpeg.avi
sh4rgbffmpeg.avi - Created with ffmpeg -i sh4yuvj420FRAPS.avi -qp 0 -vcodec libx264rgb -acodec pcm_s16le -pix_fmt yuv420p sh4rgbffmpeg.avi
sh4yuv420ffmpegcrf.avi - Created with ffmpeg -i sh4yuvj420FRAPS.avi -crf 18 -vcodec libx264 -acodec pcm_s16le -pix_fmt yuv420p sh4yuv420ffmpegcrf.avi
test.mkv - Created with melt colour:black out=600 -track sh4yuvj420FRAPS.avi out=600 -transition affine in=300 out=314 -consumer avformat:test.mkv real_time=-1
The issue is that when you take FRAPs footage (default settings to produce pix_fmt:yuvj420p file) and play it back with melt you get perfect playback.
melt frapsfile.avi
If you take FRAPs footage and use an affine, you get slightly green-tinted footage where the affine is.
melt colour:black out=600 -track frapsfile.avi out=600 -transition affine in=300 out=314
Extra info from experimenting a bit and transcoding the original fraps file to other formats.
The problem does not exist if you first convert the fraps file to x264 rgb rather than x264 yuv.
The problem persists, but is lessened when converting the fraps file to x264 yuv.
Came across the issue in kdenlive when applying zoom affines to text overlays on top of fraps captured footage. Replicated with simple melt command line, so reporting it here.
Work-arounds are: capturing in RGB lossless from FRAPs directly, or converting the video to x264rgb. However neither is that great as they both increase the filesizes involved dramatically.
melt -version
melt 0.9.8
This is on openSUSE Tumbleweed, but to be honest, I've seen this in various versions of melt on various OSs. Earliest mlt was prolly 0.9.2.
Please let me know if you would like more information.
Sorry, the attachment of the files didn't work.
Find them here instead: http://www.corrosivetruths.org/mltbugfiles/
Last edit: Peter Robertson 2015-09-11
I just saw this bug and started looking into it. I can reproduce it. It appears to be related to FFmpeg libswscale YUV<->RGB conversions because I can reproduce it with the frei0r.alpha0ps filter, which does not even touch the RGB pixel components. Furthermore, forcing it back and forth between YUV and RGB a couple times exagerates the problem:
(filter gamma with default value skips image processing but that filter forces the image to convert back to yuv). When testing with that, the problem is clearly unrelated to yuvj420 as well.
We are setting some quality flags on swscale, and I tried removing those with no improvement. I also tried to remove our calls to explicitly set colorspace (Rec. 601 vs. 709) on swscale, but that made no improvement either.
Related evidence:
https://ffmpeg.org/pipermail/ffmpeg-user/2013-February/013500.html
https://trac.ffmpeg.org/ticket/3785
See also http://www.poynton.com/PDFs/Merging_RGB_and_422.pdf
More related info. MLT uses YUV 4:2:2 internally when not using RGB(A). When encoding (original command line), the RGBA output from the affine filter is converted to yuv422 before yuv420p per the codec default.
I guess I should try to replicate this in ffmpeg and report it there instead.
Thank you for looking into this, Dan, really appreciate it, especially considering the file sizes and awkwardness to replicate!
Hi Dan, looks like your fix for https://github.com/mltframework/shotcut/issues/674 also fixed this?