HD Motion-JPEG Rec601 ??
Page 1 of 1 (2 posts)
Tags:
None
Registered Member 
|
I've just been testing some raw HD video clips from several DSLR cameras (Nikon, Panasonic) that were recorded in Motion-JPEG format. Loading the clips into KDenLive 16.12.0 (on Kubuntu 16.04 AMD64) I was surprised to see that Clip Properties reported the colorspace as ITU-R-601, which seemed a bit odd given that this is HD material, not Standard Definition
Analysing the clips with FFProbe also the color primaries are reported to be bt470bg (i.e. smpte170m=Rec.601). Example:
If that really is the case, does it mean that KDenLive will be acting on that information and applying Rec.601 coefficients when converting to and back from RGB and deriving luma and RGB values for the Videoscopes ? Also when using Curves, does it mean that Rec.601 should be selected for the 'Luma Formula' instead of Rec.709? It just seems strange that one would use Rec.601 co-efficients for HD material. To see if it made any difference, I also tried transcoding another HD-AVC.mp4 DSLR clip (with full range luma) to MJPEG, setting the encode colorspace to BT709:
The encode completed without any errors/warnings:
But when I examined the MJPEG encode with FFProbe the Color Primary was again reported as being BT470bg. |
|
Registered Member
|
Well I've reached my own conclusions on this.
Transcoding a Rec709 source directly to MJPEG with ffmpeg does not in itself effect a change in the color matrix to Rec601. That is to say, when encoded like so....
....the color-matrix of the MJPEG encode is still Rec709. To do so requires assertive conversion of the color matrix of the decode output from Rec709 to Rec601:
However, for some reason FFProbe always reports the Color Primary of MJPEG files as being bt470bg. Just why, I don't know. Unless someone can offer a better explanation, my best guess is that it is some legacy from the standard definition days when MJPEG was in vogue i.e. it is an assumptive association - "recognized as MJPEG - so assumed to be Rec601". MediaInfo doesn't report any Color Primary/Matrix Coefficient information for MJPEG files, so the 'bt470bg' designation is surely an FFProbe thing. And unfortunately this does have implications when importing 'direct' Rec709 > MJPEG transcodes into KDenLive. They get treated as if they are Rec601 when they are not, and as a result Rec601 coefficients are incorrectly applied in the internal color-space conversions that take place, resulting in color inaccuracies. How I can I be certain of all of this? Using metric difference analyses, I first examined the YUV characteristics of MJPEG files encoded with and without Rec709>Rec601 color-matrix conversion and compared them with lossless encodes (of the same Rec709 source), where the Rec709 color-matrix had likewise been retained or converted to Rec601. That confirmed without any doubt that MJPEG transcodes retained a Rec709 color-matrix, unless assertively converted to Rec601. I then used these files for input into KDenLive (noting the respective color-space reported in Clip Properties), rendered out to UTVideo and in the same manner compared the YUV characteristics of the test input and rendered files using metric analyses. In addition, I compared the RGB Histograms obtained when the input and rendered files were converted to RGB (with AVISynth) using Rec709 and Rec601 coefficients. From the pattern of results obtained, it was clear that KdenLive does indeed treat all MJPEG encodes as being Rec601, and it is reasonable to assume that this results from FFProbe reporting the color primary as being bt470bg. As such, I would not at all recommend using MJPEG as an intra-frame edit intermediate for Rec709 sources, at least with KDenLive. When I went on to carry out similar tests with Cinelerra CV 2.3 and HV (6), both of which use Quicktime, I did not see this behavior. MJPEG transcodes were only interpreted as being Rec601 when the color-matrix was assertively converted from Rec709 to Rec601 on encoding. And strangely enough, so did Cinelerra 5.1 (Good Guy), which does use ffmpeg for import and export. That said, the latest Cinelerra 5.1 update has a major issue with all input formats, so it's not exactly a yard stick to compare with. Enough said. Anyhow, I'm sure most people would not consider using MJPEG as an edit intermediate with KDenLive when there are better alternatives, but it's something to bear in mind. Edit: Actually what's more interesting, and potentially significant, is that I've now gone back to examine the native 1080p DSLR clips that were recorded in MJPEG format:
And using the same difference metrics to compare the YUV characteristics of original files with lossless ffmpeg transcodes (with and without color-matrix conversion) I find that the native files are also Rec709, and not 'bt470bg' as reported by FFProbe and ITU-R-601 as reported by KDenLive Clip Properties. I also tried changing the color-space from ITU-R 601 to ITU-R 709 in the 'Force Properties' section of Clip Properties and it made no difference to the outcome. |
Page 1 of 1 (2 posts)
Bookmarks
Who is online
Registered users: Bing [Bot], Google [Bot], kde-naveen, Sogou [Bot], Yahoo [Bot]
