Panasonic GH5 test videos don't work in Resolve 12.5

Get answers to your questions about color grading, editing and finishing with DaVinci Resolve.
  • Author
  • Message
Offline

Bryan Worsley

  • Posts: 341
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostFri Mar 24, 2017 5:48 pm

Andrew Kolakowski wrote:You have to make sure that TMPGEnc preserves 10bit pipe in case of Cineform or DNxHR as target. It's not that obvious.


I don't see DNxHR being an option with Mastering Works 6 - it can only convert to third-party avi formats for which an accessible VFW codec is installed, but in the context of Cineform output that's what I meant by:

Bryan Worsley wrote:I'm not sure what bit depth MW6 processes at though.


I'll contact Pegasys about that.

Out of interest is anyone using Pegasys Smart Renderer 5? I'm intrigued to know if it can also import these GH5 files and actually "smart render" them. I've been using Smart Renderer 4 for years now, mostly for lossless rough-trimming (at key frame level) of HD-AVC.mp4 footage prior to transcoding. I ran a trial of Smart Renderer 5 when it first came out, but decided it offered nothing worth upgrading for, at that time. Unfortunately, Pegaysys remembers that and I won't let me run the trial again.

Edit: Smart Renderer (4/5) has a 'Smart Rendering Analyzer' that shows those segments of a clip that we will be "smart rendered" (copied) and those that will be re-encoded.
Last edited by Bryan Worsley on Sat Mar 25, 2017 3:16 am, edited 2 times in total.
Offline
User avatar

Jean Claude

  • Posts: 1738
  • Joined: Sun Jun 28, 2015 4:41 pm

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostFri Mar 24, 2017 6:01 pm

Bryan Worsley wrote:
Andrew Kolakowski wrote:You have to make sure that TMPGEnc preserves 10bit pipe in case of Cineform or DNxHR as target. It's not that obvious.


I don't see DNxHR being an option with Mastering Works 6 - it can only convert to third-party avi formats for which an accessible VFW codec is installed, but in the context of Cineform output that's what I meant by:

Bryan Worsley wrote:I'm not sure what bit depth MW6 processes at though.


I'll contact Pegasys about that.

Out of interest is anyone using Pegasys Smart Renderer 5? I'm intrigued to know if it can also import these GH5 files and actually "smart render" them. I've been using Smart Renderer 4 for years now, mostly for lossless rough-trimming (at key frame level) of HD-AVC.mp4 footage prior to transcoding. I ran a trial of Smart Renderer 5 when it first came out, but decided it offered nothing worth upgrading for, at that time. Unfortunately, Pegaysys remembers that and I won't let me run the trial again.


Download codecs AVID => it's free :)
Windows 10 PRO X64 1709 and 1803 | DaVinci Resolve Studio 15.1.2.008 | Fusion Studio 9.0.2 | Decklink Studio 4K 6G | Desktop Video 10.10.11 | Nvidia 416.16
Offline

Andrew Kolakowski

  • Posts: 4315
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostFri Mar 24, 2017 6:23 pm

For h264 based files mediainfo shows correct bitdepth and it should be 100% accurate as it's taken from actual h264 headers.

DNxHR HQX from Resolve is always 12bit, but from AME is 10bit (HQX can be both).
Cineform is 10bit. AME RGB 12bit mode is actually also 10bit. This has been reported as bug and Adobe analysed it, but never gave me an answer.

Regardless all of this, you also needs to know that your software actually preserves 10bit (or whatever) depth and does not use eg. 8bit processing on the way.
Anything based on VFW/directshow/QT quite often is going through 8bit at some point, that's why I said- make sure TMPEgenc is preserving 10bit in the chain.
Offline

Bryan Worsley

  • Posts: 341
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSat Mar 25, 2017 1:06 am

Jean Claude wrote:
Bryan Worsley wrote:
Andrew Kolakowski wrote:You have to make sure that TMPGEnc preserves 10bit pipe in case of Cineform or DNxHR as target. It's not that obvious.


I don't see DNxHR being an option with Mastering Works 6 - it can only convert to third-party avi formats for which an accessible VFW codec is installed, but in the context of Cineform output that's what I meant by:

Bryan Worsley wrote:I'm not sure what bit depth MW6 processes at though.


I'll contact Pegasys about that.

Out of interest is anyone using Pegasys Smart Renderer 5? I'm intrigued to know if it can also import these GH5 files and actually "smart render" them. I've been using Smart Renderer 4 for years now, mostly for lossless rough-trimming (at key frame level) of HD-AVC.mp4 footage prior to transcoding. I ran a trial of Smart Renderer 5 when it first came out, but decided it offered nothing worth upgrading for, at that time. Unfortunately, Pegaysys remembers that and I won't let me run the trial again.


Download codecs AVID => it's free :)


Neat. I didn't realize until I poked around that Mastering Works 6 supported third-party QT codecs as well.
Offline
User avatar

Jean Claude

  • Posts: 1738
  • Joined: Sun Jun 28, 2015 4:41 pm

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSat Mar 25, 2017 10:32 am

Andrew Kolakowski wrote:For h264 based files mediainfo shows correct bitdepth and it should be 100% accurate as it's taken from actual h264 headers.

DNxHR HQX from Resolve is always 12bit, but from AME is 10bit (HQX can be both).
Cineform is 10bit. AME RGB 12bit mode is actually also 10bit. This has been reported as bug and Adobe analysed it, but never gave me an answer.

Regardless all of this, you also needs to know that your software actually preserves 10bit (or whatever) depth and does not use eg. 8bit processing on the way.
Anything based on VFW/directshow/QT quite often is going through 8bit at some point, that's why I said- make sure TMPEgenc is preserving 10bit in the chain.


Hi Andrew,

I did the test TMPGEMW 6 in MOV with the codec BM 10 bits. The suite 10 bits "would" maintained because in output I have:
Chroma subsampling: 4: 2: 2
Bit depth: 10 bits

Or is it just a matter of metadata?
Code: Select all
Général
Complete name                            : M:\Project_4\GH5 sample movieBM10bits.mov
Format                                   : MPEG-4
Format profile                           : QuickTime
Codec ID                                 : qt   2005.03 (qt  )
File size                                : 6,11 Gio
Duration                                 : 11s 500 ms
Overall bit rate mode                    : Constant
Overall bit rate                         : 4 567 Mb/s
Encoded date                             : UTC 2017-03-24 15:45:50
Tagged date                              : UTC 2017-03-24 15:47:00
Writing library                          : Apple QuickTime

Vidéo
ID                                       : 1
Format                                   : YUV
Codec ID                                 : v210
Codec ID/Hint                            : AJA Video Systems Xena
Duration                                 : 11s 500 ms
Bit rate mode                            : Constant
Bit rate                                 : 4 565 Mb/s
Width                                    : 4 096 pixels
Height                                   : 2 160 pixels
Display aspect ratio                     : 1,896
Frame rate mode                          : Constant
Frame rate                               : 24,000 Im/s
Color space                              : YUV
Chroma subsampling                       : 4:2:2
Bit depth                                : 10 bits
Compression mode                         : Sans perte
Bits/(Pixel*Frame)                       : 21.500
Stream size                              : 6,11 Gio (100%)
Title                                    : Module de gestion vidéo / Gestionnaire d’alias Apple
Language                                 : Anglais
Encoded date                             : UTC 2017-03-24 15:45:50
Tagged date                              : UTC 2017-03-24 15:47:00

Audio
ID                                       : 2
Format                                   : PCM
Format settings, Endianness              : Big
Format settings, Sign                    : Signed
Codec ID                                 : twos
Duration                                 : 11s 500 ms
Bit rate mode                            : Constant
Bit rate                                 : 1 411,2 kb/s
Channel(s)                               : 2 canaux
Channel positions                        : Front: L R
Sampling rate                            : 44,1 kHz
Bit depth                                : 16 bits
Stream size                              : 1,93 Mio (0%)
Title                                    : Module de gestion Son / Gestionnaire d’alias Apple
Language                                 : Anglais
Encoded date                             : UTC 2017-03-24 15:45:50
Tagged date                              : UTC 2017-03-24 15:47:00
Windows 10 PRO X64 1709 and 1803 | DaVinci Resolve Studio 15.1.2.008 | Fusion Studio 9.0.2 | Decklink Studio 4K 6G | Desktop Video 10.10.11 | Nvidia 416.16
Offline

Andrew Kolakowski

  • Posts: 4315
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSat Mar 25, 2017 12:23 pm

You can't be sure just based on this at all.
Generate gradient in some software (e.g. AE), export the same format as you testing. If not possible then export v210 uncompresed out of AE and convert to 10bit h264 in ffmpeg- use very high bitrate (e.g. crf=1). Convert this h264 in TMPEGenc and load your final 10bit back to AE set to 16bit mode. Do crazy curve filter (you can do even 2 instances which pushes things a lot) on both (source and you exported file) and compare. You will see straight away if file is 8bit or 10bit.
This is the way to tell if your workflow keeps 10bit. Metadata in this case is meaningless as you don't know what data went through during whole conversion.


Use this:
v210:
https://drive.google.com/open?id=0B5Sgc ... DBSd3htaGc

h264_10bit:
https://drive.google.com/open?id=0B5Sgc ... UtnZkhLWG8

Added strong curve in Resolve:
https://drive.google.com/open?id=0B5Sgc ... TBMWW15UmM

Image


10bit h264, dithered 8bit h264 (ffmpeg does it by default now), pure 8bit h264 (check original 16bit TIFF)
You have to be watching for dithering also. Looks like ffmpeg now does it by default (ffmbc did for long time). Ordered dithering is compression resistant but it also creates distinct pattern. If some tool uses dithering you may be fooled, so watch for it. Zoom in AE to 400% and you will see pattern easily. Also- grey color changes due to dithering. If gradient looks very good on 8bit preview it most likely uses dithering. It may even look better than real 10bit file. This won't be the case when you have real 10bit panel and 10bit preview.
Offline
User avatar

Jean Claude

  • Posts: 1738
  • Joined: Sun Jun 28, 2015 4:41 pm

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSat Mar 25, 2017 2:27 pm

Ok I did the test. I downloaded the 3 links and imported them into TMPGENC WM6 and exported it to X264 10bits (MP4).

No after effect but I opened the MP4 with VD PFMOD then export in TIFF sequence 16 bit image.

Open in Photoshop 16-bit mode and enlarged to 400% (very clean). Then from photoshop export web to jpg.

(From top to bottom: comp, H264_10bits and V210)
Comp_H264_V210_10_bits.jpg
(From top to bottom: comp, H264_10bits and V210)
Comp_H264_V210_10_bits.jpg (837.97 KiB) Viewed 6204 times



And the links to the original TIFF:
Http://imgur.com/iJ2jnam
Http://imgur.com/qD1WuFE
Http://imgur.com/dLfmXU0
Windows 10 PRO X64 1709 and 1803 | DaVinci Resolve Studio 15.1.2.008 | Fusion Studio 9.0.2 | Decklink Studio 4K 6G | Desktop Video 10.10.11 | Nvidia 416.16
Offline

Martin Schitter

  • Posts: 820
  • Joined: Tue Apr 28, 2015 10:41 pm

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSat Mar 25, 2017 3:02 pm

Andrew Kolakowski wrote:You have to be watching for dithering also. Looks like ffmpeg now does it by default (ffmbc did for long time). [...] If some tool uses dithering you may be fooled, so watch for it.


ffmpeg is indeed dithering by default, but it shows some very nasty issues concerning this feature. depending on the used pixelfomat it often ignores the concerning command line options and doesn't allow more advanced dithering methods. but of course it's better than nothing.
Offline

Andrew Kolakowski

  • Posts: 4315
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSat Mar 25, 2017 11:39 pm

Yep, I actually couldn't turn it off and this matches what I said about ffmpeg doing some things great and others badly :)
Again- solution is to use zscale :)
Offline

Martin Schitter

  • Posts: 820
  • Joined: Tue Apr 28, 2015 10:41 pm

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 12:00 am

Andrew Kolakowski wrote:Again- solution is to use zscale :)

yes -- zscale (z.lib) has better dithering capabilities, but i'm in doubt if this ffmpeg-filter can be actually utilized for proper 10->8bit preparation?
Offline

Andrew Kolakowski

  • Posts: 4315
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 12:09 am

It works quite well inside ffmpeg (at least bits which I've tried).
It did not originated as part of ffmepg- it was ported to ffmpeg. It was written as generic library. It also exists in avisynth, vapourysnth.
Offline

Andrew Kolakowski

  • Posts: 4315
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 12:41 am

Jean Claude wrote:Ok I did the test. I downloaded the 3 links and imported them into TMPGENC WM6 and exported it to X264 10bits (MP4).

No after effect but I opened the MP4 with VD PFMOD then export in TIFF sequence 16 bit image.

Open in Photoshop 16-bit mode and enlarged to 400% (very clean). Then from photoshop export web to jpg.

(From top to bottom: comp, H264_10bits and V210)
Comp_H264_V210_10_bits.jpg (but in jpg)



And the links to the original TIFF:
Http://imgur.com/iJ2jnam
Http://imgur.com/qD1WuFE
Http://imgur.com/dLfmXU0


I'm not that convinced about your way of making TIFFs. Your workflow does not sound very reliable. Rather have actual files and check them in AE directly. You also have to apply some strong curve etc in order to be able reliably tell the difference on typical 8bit monitor screen.

dLfmXU0 is 8bit for sure.
qD1WuFE may be 10bit, but colors are broken (probably your many steps workflow issue).

Also- I thought you want to check h264 10bit to v210 conversion (which is equivalent to GH5 files to v210).
Offline

Martin Schitter

  • Posts: 820
  • Joined: Tue Apr 28, 2015 10:41 pm

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 1:13 am

Andrew Kolakowski wrote:It works quite well inside ffmpeg (at least bits which I've tried).


i see -- i can not try it, because zscale support is not enabled in ffmpeg (3.2.4) builds on debian right now... :(

Andrew Kolakowski wrote:It did not originated as part of ffmepg- it was ported to ffmpeg. It was written as generic library. It also exists in avisynth, vapourysnth.


yes -- i know. but i don't like this kind of eclectic library inclusion in ffmpeg so much. fixing bugs in the default swscaler and its dithering routines or a consequent replacement by an alternative implementation would look more desirable to me, than just duplicating features again and again...
Offline

Bryan Worsley

  • Posts: 341
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 4:30 am

Andrew Kolakowski wrote:Also- I thought you want to check h264 10bit to v210 conversion (which is equivalent to GH5 files to v210).


I must say, I thought also the interest here was in:

Andrew Kolakowski wrote:...Anything based on VFW/directshow/QT quite often is going through 8bit at some point, that's why I said- make sure TMPEgenc is preserving 10bit in the chain.


...not least because Resolve will not import any of the 10-bit 422, Hi444PP or 420 exports from MW6. And it doesn't necessarily follow that the 'bit-depth' path(s) engineered for these 'internal' 10-bit export formats extend to third-party 10-bit VFW and QT formats as well.

Unfortunately I don't have AE available to replicate Andrew's test methodology, but I hope you smart guys can glean some further evidence-based insight on this. Meanwhile, like I said, I will contact Pegasys to see what light they can shed.
Offline
User avatar

Jean Claude

  • Posts: 1738
  • Joined: Sun Jun 28, 2015 4:41 pm

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 8:22 am

Andrew Kolakowski wrote:
Jean Claude wrote:Ok I did the test. I downloaded the 3 links and imported them into TMPGENC WM6 and exported it to X264 10bits (MP4).

No after effect but I opened the MP4 with VD PFMOD then export in TIFF sequence 16 bit image.

Open in Photoshop 16-bit mode and enlarged to 400% (very clean). Then from photoshop export web to jpg.

(From top to bottom: comp, H264_10bits and V210)
The attachment Comp_H264_V210_10_bits.jpg (but in jpg) is no longer available



And the links to the original TIFF:
Http://imgur.com/iJ2jnam
Http://imgur.com/qD1WuFE
Http://imgur.com/dLfmXU0


I'm not that convinced about your way of making TIFFs. Your workflow does not sound very reliable. Rather have actual files and check them in AE directly. You also have to apply some strong curve etc in order to be able reliably tell the difference on typical 8bit monitor screen.

dLfmXU0 is 8bit for sure.
qD1WuFE may be 10bit, but colors are broken (probably your many steps workflow issue).

Also- I thought you want to check h264 10bit to v210 conversion (which is equivalent to GH5 files to v210).


OK (bis) repeats the test H264 => V210. I do not have After effect.
So I imported the clip into Resolve.

Code: Select all
Général
Complete name                            : M:\Project_4\h264_10bit.mov
Format                                   : MPEG-4
Format profile                           : QuickTime
Codec ID                                 : qt   2005.03 (qt  )
File size                                : 26,4 Mio
Duration                                 : 208 ms
Overall bit rate mode                    : Constant
Overall bit rate                         : 1 065 Mb/s
Encoded date                             : UTC 2017-03-26 09:08:39
Tagged date                              : UTC 2017-03-26 09:08:39
Writing library                          : Apple QuickTime

Vidéo
ID                                       : 1
Format                                   : YUV
Codec ID                                 : v210
Codec ID/Hint                            : AJA Video Systems Xena
Duration                                 : 208 ms
Bit rate mode                            : Constant
Bit rate                                 : 1 062 Mb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16/9
Frame rate mode                          : Constant
Frame rate                               : 24,000 Im/s
Color space                              : YUV
Chroma subsampling                       : 4:2:2
Bit depth                                : 10 bits
Compression mode                         : Sans perte
Bits/(Pixel*Frame)                       : 21.333
Stream size                              : 26,4 Mio (100%)
Title                                    : Module de gestion vidéo / Gestionnaire d’alias Apple
Language                                 : Anglais
Encoded date                             : UTC 2017-03-26 09:08:39
Tagged date                              : UTC 2017-03-26 09:08:39

Audio
ID                                       : 2
Format                                   : PCM
Format settings, Endianness              : Big
Format settings, Sign                    : Signed
Codec ID                                 : twos
Duration                                 : 207 ms
Bit rate mode                            : Constant
Bit rate                                 : 1 411,2 kb/s
Channel(s)                               : 2 canaux
Channel positions                        : Front: L R
Sampling rate                            : 44,1 kHz
Bit depth                                : 16 bits
Stream size                              : 35,9 Kio (0%)
Title                                    : Module de gestion Son / Gestionnaire d’alias Apple
Language                                 : Anglais
Encoded date                             : UTC 2017-03-26 09:08:39
Tagged date                              : UTC 2017-03-26 09:08:39


V210.jpg
V210 in Davinci Resolve
V210.jpg (26.06 KiB) Viewed 6149 times

v210_scope.jpg
v210_scope.jpg (109.63 KiB) Viewed 6149 times
Windows 10 PRO X64 1709 and 1803 | DaVinci Resolve Studio 15.1.2.008 | Fusion Studio 9.0.2 | Decklink Studio 4K 6G | Desktop Video 10.10.11 | Nvidia 416.16
Offline

Peter Cave

  • Posts: 815
  • Joined: Thu Aug 23, 2012 6:45 am

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 10:02 am

GH5 video samples work fine on MacOSX with Resolve Studio 12.5.5
Resolve 15
Mac OSX 10.13.3
iMac (Retina 5K, 27-inch, Late 2014)
4 GHz Intel Core i7
AMD Radeon R9 M295X 4096 MB
Offline
User avatar

Jean Claude

  • Posts: 1738
  • Joined: Sun Jun 28, 2015 4:41 pm

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 10:10 am

Yes, on windows too but in 8 bits. When it is in 10 bits => media offlline. (Unless it's my PC?)
Windows 10 PRO X64 1709 and 1803 | DaVinci Resolve Studio 15.1.2.008 | Fusion Studio 9.0.2 | Decklink Studio 4K 6G | Desktop Video 10.10.11 | Nvidia 416.16
Offline

Andrew Kolakowski

  • Posts: 4315
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 11:13 am

Martin Schitter wrote:
yes -- i know. but i don't like this kind of eclectic library inclusion in ffmpeg so much. fixing bugs in the default swscaler and its dithering routines or a consequent replacement by an alternative implementation would look more desirable to me, than just duplicating features again and again...


According to some developers swscaler is a mess and should be re-wrtitten. That's why zscale is great option and it's very accurate.
Offline

Andrew Kolakowski

  • Posts: 4315
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 11:26 am

Jean Claude wrote:
V210.jpg

v210_scope.jpg


Scope preview won't tell you easily if it's 10bit or not.

Apply crazy curve on your v210 source:

Image

and compare it for my v210, dLfmXU0.tiff and your last v210. You should see massive difference for file which holds only 8bit data (dLfmXU0.tiff).

You will get very clear steps with 8bit:

Image

key point is to do heavy processing, otherwise it's not easy to tell (if you have 10bit monitoring with good 10bit panel then it's easier to tell even on 1:1 preview).
Offline

Martin Schitter

  • Posts: 820
  • Joined: Tue Apr 28, 2015 10:41 pm

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 11:41 am

Andrew Kolakowski wrote:According to some developers swscaler is a mess and should be re-wrtitten. That's why zscale is great option and it's very accurate.


yes -- but it's also quit limited and looking more backward oriented, supporting only the most common cases in a hardcoded manner. i personally prefer OpenColorIO for more advanced color space transformations, even if it's slower. anyway, ffmpegs color subsampling and dithering simply has to be fixed in more comprehensive way.

and concerning the topic of this thread:
i think, it's quite useful to choose testimages/gradients, which show 8bit and 10bit quantization in parallel, like this one. it makes the difference and irritating side effects more obvious.
Offline
User avatar

Jean Claude

  • Posts: 1738
  • Joined: Sun Jun 28, 2015 4:41 pm

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 2:40 pm

Hi,

You're right Andrew: TMPGWM6 does not roll back correctly in 10 bits.

I re-tested the H264 10 bits and went through Convert V4 (FFMPEG) to DNXHD 422 10 bits and there it is correct.

h264_to_DNXHD_10_bits.jpg
h264_to_DNXHD_10_bits.jpg (12.98 KiB) Viewed 6122 times

(Copy DR screen but PC monitor ..8bits)

I also passed the GH5 10-bit test video by Convert V4 to 10 bit ProRes 422. Very nice pictures but: 3fps .... No problem reading in Davinci Rresolve.
Windows 10 PRO X64 1709 and 1803 | DaVinci Resolve Studio 15.1.2.008 | Fusion Studio 9.0.2 | Decklink Studio 4K 6G | Desktop Video 10.10.11 | Nvidia 416.16
Offline

Bryan Worsley

  • Posts: 341
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 3:51 pm

Just to add another diversion and more technical eye-candy to the mix ;)

Bryan Worsley wrote:Out of interest is anyone using Pegasys Smart Renderer 5? I'm intrigued to know if it can also import these GH5 files and actually "smart render" them. I've been using Smart Renderer 4 for years now, mostly for lossless rough-trimming (at key frame level) of HD-AVC.mp4 footage prior to transcoding. I ran a trial of Smart Renderer 5 when it first came out, but decided it offered nothing worth upgrading for, at that time. Unfortunately, Pegaysys remembers that and I won't let me run the trial again.

Edit: Smart Renderer (4/5) has a 'Smart Rendering Analyzer' that shows those segments of a clip that we will be "smart rendered" (copied) and those that will be re-encoded.


I went ahead and purchased the Smart Renderer 5 (SR5) upgrade and it does import the GH5 UHD 10-bit 422 files and 'smart render' them. If cut-excisions are applied at the 'Key (I) Frame' (whole GOP) level, there is no re-encoding....completely lossless. If cuts are applied at the 'Frame' (intra GOP) level however there is always some re-encoding and the behavior is similar to that seen with HD-AVC.mp4 (4:2:0) clips. Even if just one frame is excised, the affected GOP and following four GOP's are re-encoded, so when joining trimmed clips, six GOP's are re-encoded around each splice point. Since 1 GOP = 0.5 sec of video, that can add up.

That said, at suitably poised quality settings, the quality of the re-encoded frames is very good and in all the time I used Smart Renderer 4 with HD-AVC material, I never once encountered a problem with playback or stream errors when transcoding or loading the renders in other NLE's. TMPGenc has always been very strict on standards/systems compliance. The same can not be said of other so called 'smart cutters' out there.

Needless to say, Resolve will not import the SR5 edited GH5 10-bit 422 files, but this does (at Key Frame Level) offer a means of lossless rough trimming prior to transcoding.

As an example, here is the GOP analysis (Elecard Stream Eye) of one of the GH5 UHD 30p 10-bit 422 clips ("Perpetua Dolly") from that Neumannfilms set before and after Key and Frame level trimming with SR5:

Image


The red bars are I frames and the blue bars P frames. The 'display' (read) sequence is the same as the 'stream' sequence. I haven't shown it there, but those higher bitrate P frames inserted in place of the original I frames in the frame level edit can be re-instated as I frames by marking the key frames when editing.

And here's the SRF 'Smart Rendering Analysis' of the same cut edits before rendering:

Image
Offline

Martin Schitter

  • Posts: 820
  • Joined: Tue Apr 28, 2015 10:41 pm

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 4:30 pm

i don't think, smart rendering will have any positive impact, if you use resolve!
sure, you could use it in some proxy scenarios to get a minimal advantage of image quality on the final rendering, but otherwise resolve will be quite unhappy and slow using this kind of long GOP source footage.
you should also be aware, that smart rendering may also effect some nasty time code related issues.
Offline

Bryan Worsley

  • Posts: 341
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 4:46 pm

Like I said, I would consider this more as a way of lossless rough trimming prior to transcoding, so as to keep file sizes down:

Bryan Worsley wrote:Needless to say, Resolve will not import the SR5 edited GH5 10-bit 422 files, but this does (at Key Frame Level) offer a means of lossless rough trimming prior to transcoding.
Offline

Bryan Worsley

  • Posts: 341
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 4:56 pm

Jean Claude wrote:I also passed the GH5 10-bit test video by Convert V4 to 10 bit ProRes 422. Very nice pictures but: 3fps .... No problem reading in Davinci Rresolve.


Something to bear in mind when transcoding native full luma range (0-255) footage (as these GH5 10-bit sample clips are) to ProRes or DNxHD with ffmpeg - the luma gets compressed to limited 16-235 range. And Convert V4 is no exception:

https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=57068#p330931

Bryan Worsley wrote:That's why when transcoding native full-swing 4:2:0 H264 sources with ffmpeg, I prefer to use the command line to make sure it's done correctly; even for DNxHD or ProRes transcodes there are ways (using -vf filters) to pass-through and preserve full luma range. But with native 4:2:2 source formats that, to my knowledge, is not possible with ffmpeg directly [i]Edit: although maybe via VapourSynth with VSPipe, but that's rather convoluted.[/b]


There I was referring to the use of the mergeplanes -vf filter (i.e. shuffle/merge planes) to pass-through full luma range from native 4:2:0 sources. If you ffmpeg savvy guys know of a way that can be done with 4:2:2 sources (without intermediary conversion) I'd be glad to know.
Last edited by Bryan Worsley on Sun Mar 26, 2017 5:21 pm, edited 1 time in total.
Offline
User avatar

Jean Claude

  • Posts: 1738
  • Joined: Sun Jun 28, 2015 4:41 pm

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 5:08 pm

Hi Bryan

YUV...

.../...
Y′ values are conventionally shifted and scaled to the range [16, 235] (referred to as studio swing or "TV levels") rather than using the full range of [0, 255] (referred to as full swing or "PC levels").
.../...

https://en.wikipedia.org/wiki/YUV

maybe i'm wrong?

Another solution: you download ffmpeg and you do your tests yourself. There are plenty of opportunities with FFMPEG but you have to know what you do (?)

maybe i'm wrong? :?
Windows 10 PRO X64 1709 and 1803 | DaVinci Resolve Studio 15.1.2.008 | Fusion Studio 9.0.2 | Decklink Studio 4K 6G | Desktop Video 10.10.11 | Nvidia 416.16
Offline

Bryan Worsley

  • Posts: 341
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 5:36 pm

Yes, I'm referring to YUV luma range.

I do use ffmpeg a fair bit for transcoding but I'm not as a savvy as others on the forum. I removed Convert v4 after testing and I'm not particularly inclined to reinstall it on my shiny new clean Windows 10 install. But I'll show you what I mean with ffmpeg CLI when I have a bit more time.
Last edited by Bryan Worsley on Mon Mar 27, 2017 10:25 am, edited 1 time in total.
Offline

John Paines

  • Posts: 1542
  • Joined: Tue Jul 28, 2015 4:04 pm

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 5:51 pm

Bryan Worsley wrote:Something to bear in mind when transcoding native full luma range (0-255) footage (as these GH5 10-bit sample clips are)



Are you sure the files are full range? Seems odd, for what remains a consumer camera recording to a consumer format.
Offline

Andrew Kolakowski

  • Posts: 4315
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 6:25 pm

They can be (as well as limited)- it's user setting inside GH5. If they are full range then they can cause issues as any auto detection will assume rather limited range. There are only few solutions which will properly read range flag in h264 and choose correct processing. In Resolve you can at least set it manually- limited v full.
It's fairly easy for BM to add paper auto detection, specially that GH4/5 sets h264 range flag correctly (and it's always present).
Offline

Bryan Worsley

  • Posts: 341
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 6:38 pm

John Paines wrote:
Bryan Worsley wrote:Something to bear in mind when transcoding native full luma range (0-255) footage (as these GH5 10-bit sample clips are)


Are you sure the files are full range? Seems odd, for what remains a consumer camera recording to a consumer format.


Actually, I was just testing as you wrote.

Although MediaInfo reports the Color Range of all of those (Neumannfilms) GH5 samples as being 'Full' (as opposed to 'Limited'), FFProbe reports the pixel format of the 10-bit 422 clips (24p and 30p) as being yuv422p10le, and not yuvj422p10le. So ffmpeg does not treat these clips as having 'full range' luma and the original luma profile will be passed through on transcoding to ProRes and DNxHD. But compression to 16-235 range will occur with the two GH5 8-bit 420 60p samples, both of which have the pix_fmt designation yuvj420p, unless measures are taken to circumvent (e.g. using -vf merge planes filter) or counter that i.e. transcoding to a format where the full range pix_fmt designation is respected by the respective ffmpeg encoder (e.g. x264, mjpeg, 8-bit raw). Again, I'll post some examples when I have time.
Last edited by Bryan Worsley on Sun Mar 26, 2017 7:12 pm, edited 1 time in total.
Offline

Andrew Kolakowski

  • Posts: 4315
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 7:07 pm

Probably because ffmpeg does not detect range properly for 4:2:2 10bit h264?
There is no such a thing like yuvj422p10le pixel format in ffmpeg as far as I know. This is rather handled as 10bit yuv and full range flag separately.

Re-scaling to YUV range is not end of the world as long as you know that source is full range. Problem happens if file is YUV (and full range) but it's passed further in processing chain as limited range, purely based of the fact that it's YUV (so assumed as limited range).
Every YUV file which is full range should have range flag, but this is not always the case. Another issue is that eg. ProRes does not have such a flag at all, so it's all pure guess or manual setting (like it can be done in Resolve).
Last edited by Andrew Kolakowski on Sun Mar 26, 2017 7:19 pm, edited 1 time in total.
Offline

Bryan Worsley

  • Posts: 341
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 7:19 pm

Andrew Kolakowski wrote:Probably because ffmpeg does not detect range properly for 4:2:2 10bit h264?
There is no such a thing like yuvj422p10le pixel format in ffmpeg as far as I know. This is rather handled as 10bit yuv and full range flag separately.


Ah you're probably right. But ffmpeg definitely treats those GH5 10-bit 422 clips as being 'Limited' range (or 'tv' range as FFProbe reports it) on the basis of the yuv422p10le flag, regardless of what MediaInfo states. Of course 'tv' range in this context also includes 16-255 ('extended') range, which is what most 'consumer level' HD-AVC camcorders shoot in, as did HDV and DV camcorers before them.

I'm not sure about the GH5 (without checking a User Manual), but I know GH4 permits selection of the luma recording range - full (0-255), extended (16-255) and limited (16-235).
Offline

Andrew Kolakowski

  • Posts: 4315
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 7:38 pm

GH5 has the same settings (as far I read on the net).
16-255 is some strange invention and should be avoided I would say.
For 10bit format you can use limited range and not really loose much in real world. For 8bit limited range is problematic and can quickly cause banding (full range adds more precious levels in 8bit).
Last edited by Andrew Kolakowski on Sun Mar 26, 2017 8:02 pm, edited 1 time in total.
Offline

Bryan Worsley

  • Posts: 341
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 7:46 pm

Andrew Kolakowski wrote:GH5 has the same settings (as far I read on the net).


Confirmed (without sifting through the GH5 User Manual), quote:

"Luminance levels can be selected between 0-255 / 16-235 / 16-255/ (8-bit) and 0‒1023 / 64‒940 / 64‒1023 (10-bit) on the GH5"

http://mirrorlesscomparison.com/preview/panasonic-lumix-gh5-vs-g85-gh5-vs-g80/

Andrew Kolakowski wrote:16-255 is some strange invention and should be avoided I would say.


A popular opinion is that camcorder engineers, from all of the major companies, exploited allowances in the Rec.601 and then Rec.709 standards for 8-bit encoding in the 236-254 range to accommodate filter overshoot, transient signals and specular highlights, and used this as a way of gaining a little extra dynamic range and headroom for grading. To what extent that's true or simply that full (data) level YV12 decoding reveals these "super-white" excursions, I'm not sure.

Personally, I prefer to preserve 16-255 range when transcoding for Resolve. That way there's scope for "bringing down" any useful near-blown highlight detail.
Offline

Andrew Kolakowski

  • Posts: 4315
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 8:20 pm

YUV (420,422,444,etc) has no problem to be full range from technical point, but it's rather uncommon. YUV444 full range is the same as RGB- just different way of storing data (better for some things, worse for others).

If you want margins than shoot limited range. 16-255 makes not much sense for me. One end has margin, another not?
16-255 has to be treated in this case as full range (no other option), so in case of Rec.709 signal your white level is going be wrong. You're asking for one end to be limited, but other full. Strange combination.
How are you going to flag such a strange thing like 16-255 for proper automated transcoding? We have issues just with limited v full. There is no existing spec for such a thing, so it has to b treated as full range, so you may as well extend black to 0.
If you want to get the most of camera use full range and watch your exposure carefully. For 10bit it should be no problem, so better to stick with limited range just because h264 are by default treated this way (avoids possible clipping on interpretation).

There is also possibility to encode h264 in RGB, but this is less efficient than YUV, so no one really does it (ffmepg by default convert RGB to yuv444).
x264 supports such a thing, even in lossless mode, which means you can take some bitmap, encode to lossless x264 in RGB mode, decode it back to RGB and it will be 100% identical to source bitmap. Such a h264 file could be decoded by Resolve directly to RGB (no YUV<->RGB conversion issues) and process directly like any other RGB signal (TIFF etc).
Offline

Bryan Worsley

  • Posts: 341
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSun Mar 26, 2017 10:28 pm

Andrew Kolakowski wrote:If you want margins than shoot limited range. 16-255 makes not much sense for me. One end has margin, another not?
16-255 has to be treated in this case as full range (no other option), so in case of Rec.709 signal your white level is going be wrong. You're asking for one end to be limited, but other full. Strange combination.


Strange or not, that is how most 'consumer' and lower-end pro-line camcorders record HD-AVC, and now 4K AVC, and with no option to change that.

Andrew Kolakowski wrote:How are you going to flag such a strange thing like 16-255 for proper automated transcoding? We have issues just with limited v full. There is no existing spec for such a thing, so it has to b treated as full range, so you may as well extend black to 0.


If you mean transcoding with the Transcode function in Resolve. Well here's what I do. Taking 1080/30p HD-AVC.mp4 clips off my Canon HF-G30 as an example. If I bring the native clips into Resolve and let 'Auto' Data Levels interpret them, they are assigned at 'Video' levels. So if I transcode to DNxHD.mov or Cineform.mov using the Resolve Transcode function, yes, the original 16-255 range will get clamped to limited range 16-235 (10-bit 64‒940). To avoid that, I go into Clip Attributes and change the Data Level to Full. That way, when transcoded the original 16-255 range is preserved. Then when bringing the transcode into the Media Pool I change the Data Level interpretation back to Video Levels. As you know one of the nice things about Resolve is that it always processes in the background at Full Data Levels with 32-bit float. So even when working at Video levels, where there may be apparent clamping of the 'super-whites', that data is not lost and is still available for pull-down if so desired. And finally, I will export out at Video levels.

As for transcoding to DNxHD or ProRes with ffmpeg, no special precautions are necessary. These clips carry the yuv420p designation, so ffmpeg merely passes through the original 16-255 range.

No, I don't think that processing the these 16-255 range native clips or transcodes at Full Data Levels, and bringing the black point down to zero is the right way to go. That would then make 255 'true white' which it is not; 235 is the true white point for this 16-255 range material - in other words it is effectively 16-235 Rec709 range, but allows for specular excursion into the 'superwhites'. Trust me, I've been around the houses on this.

As to what luminance range I would shoot on the Pana GH5, well that would depend on a number of factors, not least the target delivery platform.
Offline

Andrew Kolakowski

  • Posts: 4315
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostMon Mar 27, 2017 12:13 am

Bryan Worsley wrote:If you mean transcoding with the Transcode function in Resolve. Well here's what I do. Taking 1080/30p HD-AVC.mp4 clips off my Canon HF-G30 as an example. If I bring the native clips into Resolve and let 'Auto' Data Levels interpret them, they are assigned at 'Video' levels. So if I transcode to DNxHD.mov or Cineform.mov using the Resolve Transcode function, yes, the original 16-255 range will get clamped to limited range 16-235 (10-bit 64‒940). To avoid that, I go into Clip Attributes and change the Data Level to Full. That way, when transcoded the original 16-255 range is preserved. Then when bringing the transcode into the Media Pool I change the Data Level interpretation back to Video Levels. As you know one of the nice things about Resolve is that it always processes in the background at Full Data Levels with 32-bit float. So even when working at Video levels, where there may be apparent clamping of the 'super-whites', that data is not lost and is still available for pull-down if so desired. And finally, I will export out at Video levels.



Ok, I understand why they want to do it, but many apps are not ready for it :)

Your way is far from being reliable for typical transcoding scenario. You know what you do, most people don't. They load clip and see clipping :)
As you also found- ffmpeg won't auto detect GH5 clip as full range. So only option is based on human/manual overwriting Resolve auto detection. Many users won't know about this at all!
Solutions is plain simple- read range flag in GH5 clips and set correct levels automatically. If this is for any reason wrong than you can change manually. Good thing is that GH4/5 clips do carry this metadata and I assume it's accurate in all cases (as it's set in camera).
Offline

Bryan Worsley

  • Posts: 341
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostMon Mar 27, 2017 1:39 am

Andrew Kolakowski wrote:
Ok, I understand why they want to do it, but many apps are not ready for it :)

Your way is far from being reliable for typical transcoding scenario. You know what you do, most people don't. They load clip and see clipping :)


This is true, and many people hold that that is how this 16-255 range material should be treated - clamped to 'broadcast' safe range, which is fine. I just see benefits in being able to manipulate the 'superwhite' data.

Andrew Kolakowski wrote:As you also found- ffmpeg won't auto detect GH5 clip as full range. So only option is based on human/manual overwriting Resolve auto detection. Many users won't know about this at all!
Solutions is plain simple- read range flag in GH5 clips and set correct levels automatically. If this is for any reason wrong than you can change manually. Good thing is that GH4/5 clips do carry this metadata and I assume it's accurate in all cases (as it's set in camera).


As a case in point it's interesting that Resolve 'auto' assigns those sample GH5 UHD/60p (8-bit 4:2:0 AVC) clips to Video levels, despite Clip Details reporting the Data Level as 'Full', MediaInfo reporting the Color Range as 'Full' and FFProbe reporting the pix_fmt as yuvj420.

What would be helpful is if Resolve actually declared the Data Level to which a given clip has been 'auto' assigned. With unfamiliar log footage especially that is not always immediately obvious from the Videoscopes and you have to go back into Clip Attributes to compare the scope profiles at Full and Video levels to be sure. What doesn't help also is that the Waveform and Parade are scaled 0-1023 in both Full and Video level processing modes, which is rather misleading. Personally I think there should be separate scope sets for Full and Video levels, appropriately scaled and marked as such. I was thinking to suggest this in the 'Resolve 13 Big Feature Request List' thread.
Offline

Uli Plank

  • Posts: 3489
  • Joined: Fri Feb 08, 2013 2:48 am

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostMon Mar 27, 2017 2:46 am

What doesn't help also is that the Waveform and Parade are scaled 0-1023 in both Full and Video level processing modes, which is rather misleading. Personally I think there should be separate scope sets for Full and Video levels, appropriately scaled and marked as such. I was thinking to suggest this in the 'Resolve 13 Big Feature Request List' thread.


I second this!

P.S. Added to the list.
Resolve Studio and Fusion Studio
iMac 2017 Radeon Pro 580 8 GB VRAM and 32 GB RAM
Offline

Martin Schitter

  • Posts: 820
  • Joined: Tue Apr 28, 2015 10:41 pm

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostMon Mar 27, 2017 10:50 am

Bryan Worsley wrote:What doesn't help also is that the Waveform and Parade are scaled 0-1023 in both Full and Video level processing modes, which is rather misleading. Personally I think there should be separate scope sets for Full and Video levels, appropriately scaled and marked as such.


no -- i don't think, this request makes much sense!
you have to see, what this scopes represent and where the measuring point is located in the processing pipeline.

the only misleading aspect i see, is the 0-1023 scale and the implicit translation from 32bit linear (Y)RGB internal data representation to more common display referred representation, which somehow resembles a simulation of the final output. the scopes [and viewers] do not show anything related to the unprocessed raw input. it's always related to the internal data processing after the IDTs and their applied level shaping for the different transport conventions. the well known interferences between display calibration LUTs and resolves scopes are IMHO a much more problematic flaw of resolves metering solutions.

in other applications (e.g. nuke/natron) you can place the connections of viewers and scopes resp. measuring points more directed to different steps in the processing pipeline and also translate their displayed values according to different manual chosen RRTs/ODTs. that's very useful, if you have to analyze the whole processing in a more precise way, but that's far beyond the scope of resolves common use.
Offline

Bryan Worsley

  • Posts: 341
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostMon Mar 27, 2017 3:04 pm

Bryan Worsley wrote:Although MediaInfo reports the Color Range of all of those (Neumannfilms) GH5 samples as being 'Full' (as opposed to 'Limited'), FFProbe reports the pixel format of the 10-bit 422 clips (24p and 30p) as being yuv422p10le, and not yuvj422p10le. So ffmpeg does not treat these clips as having 'full range' luma and the original luma profile will be passed through on transcoding to ProRes and DNxHD. But compression to 16-235 range will occur with the two GH5 8-bit 420 60p samples, both of which have the pix_fmt designation yuvj420p, unless measures are taken to circumvent (e.g. using -vf merge planes filter) or counter that i.e. transcoding to a format where the full range pix_fmt designation is respected by the respective ffmpeg encoder (e.g. x264, mjpeg, 8-bit raw). Again, I'll post some examples when I have time.


Here below are the Resolve scope profiles (all at Full Data Levels) produced with one of those (Neumannfims) UHD/60p samples ('Snow Handheld') before and after transcoding to ProResHQ with ffmpeg, in the first instance using a standard command line:
Code: Select all
ffmpeg -i {PATH}/GH5_UHD_60p.MP4 -vcodec prores -profile:v 3 -r 60000/1001 -acodec copy {PATH}/GH5_UHD_60p_ProResHQ.mov

Although less obvious with this log (?V-Log) footage, you can see there proportional compression of the scope profiles as result of the [0-255] > [16-235] YUV compression (decode output) that occurs with native sources bearing the yuvj420p flag.

And then using the -vf mergeplanes filter to pass-through and preserve the original luma range:
Code: Select all
ffmpeg -i {PATH}/GH5_UHD_60p.MP4 -vf mergeplanes=0x000102:yuv420p -vcodec prores -profile:v 3 -r 60000/1001 -acodec copy {PATH}/GH5_UHD_60p_lumapassthru_ProResHQ.mov

Image
Offline

Andrew Kolakowski

  • Posts: 4315
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostMon Mar 27, 2017 5:30 pm

What if you use -vf zscale=rangein=full:range=full ?
Offline

Bryan Worsley

  • Posts: 341
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostMon Mar 27, 2017 6:14 pm

Yes, that works very nicely. Thanks.
Offline

Bryan Worsley

  • Posts: 341
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostThu Mar 30, 2017 2:48 am

Bryan Worsley wrote:
Jean Claude wrote:I also passed the GH5 10-bit test video by Convert V4 to 10 bit ProRes 422. Very nice pictures but: 3fps .... No problem reading in Davinci Rresolve.


Something to bear in mind when transcoding native full luma range (0-255) footage (as these GH5 10-bit sample clips are) to ProRes or DNxHD with ffmpeg - the luma gets compressed to limited 16-235 range. And Convert V4 is no exception:

https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=57068#p330931

Bryan Worsley wrote:That's why when transcoding native full-swing 4:2:0 H264 sources with ffmpeg, I prefer to use the command line to make sure it's done correctly; even for DNxHD or ProRes transcodes there are ways (using -vf filters) to pass-through and preserve full luma range. But with native 4:2:2 source formats that, to my knowledge, is not possible with ffmpeg directly [i]Edit: although maybe via VapourSynth with VSPipe, but that's rather convoluted.[/b]


There I was referring to the use of the mergeplanes -vf filter (i.e. shuffle/merge planes) to pass-through full luma range from native 4:2:0 sources. If you ffmpeg savvy guys know of a way that can be done with 4:2:2 sources (without intermediary conversion) I'd be glad to know.


Actually, turns out that ClipToolz v2, the forerunner of what re-emerged as Convert v4, did give the option to choose 16-235 or 0-255 range, but only for 4K ProRes HQ 4:2:2 output. John Paines brought attention to it.

Testing those full range GH5 UHD/60p 8-bit 4:2:0 AVC clips (from Neumann films) with a copy of ClipToolz v2 I had archived from years back, selecting the 0-255 option does indeed bypass the compression that otherwise occurs with the default 16-235 range option. Why such an important feature was not implemented in Convert v4, I don't understand. As for the UHD/30p 10-bit 422 GH5 samples - ClipToolz v2, like Convert v4, merely passes through the original luma range and irrespective of whether 16-235 or 0-255 is selected.

The free standalone videoscope tool is quite handy though for spot-checks, even if not for real time view:

http://hdcinematics.com/freeTools.html
Offline

Bryan Worsley

  • Posts: 341
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostFri Mar 31, 2017 3:22 am

FWIW - the transcode function in the free Sony Catalyst Browse software can convert the Pana GH5 UHD 10-bit 422 files to XAVC-I (Class 480).mxf, which Resolve will import, but attempting to output HD XAVC-I just produces an unplayable file with green screen.

And Resolve won't import the 'pseudo' XAVC-I transcodes (x264) produced with these ffmpeg routines:



No surprise there.
Offline
User avatar

Cary Knoop

  • Posts: 699
  • Joined: Sun Mar 12, 2017 6:35 pm
  • Location: Newark, CA USA

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostFri Mar 31, 2017 8:04 am

Bryan Worsley wrote:And Resolve won't import the 'pseudo' XAVC-I transcodes (x264) produced with these ffmpeg routines:

You could use ProRes instead.
Offline

Andrew Kolakowski

  • Posts: 4315
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostFri Mar 31, 2017 8:27 am

Bryan Worsley wrote:FWIW - the transcode function in the free Sony Catalyst Browse software can convert the Pana GH5 UHD 10-bit 422 files to XAVC-I (Class 480).mxf, which Resolve will import, but attempting to output HD XAVC-I just produces an unplayable file with green screen.

And Resolve won't import the 'pseudo' XAVC-I transcodes (x264) produced with these ffmpeg routines:



No surprise there.


Love these videos and how inaccurate they are in most cases.
Example from here- never ever (using loud voice) use with ffmpeg -r 23.976, but -r 24000/1001.
Whole workaround makes not much sense.

Reminds me certain news papers, like The Sun etc :) Big stories about small, meaningless things :)
Offline

Bryan Worsley

  • Posts: 341
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostFri Mar 31, 2017 2:41 pm

Cary Knoop wrote:
Bryan Worsley wrote:And Resolve won't import the 'pseudo' XAVC-I transcodes (x264) produced with these ffmpeg routines:

You could use ProRes instead.


Well, for ffmpeg transcoding at downscaled HD resolution there's DNxHD is also, but for preserved UHD transcoding with ffmpeg, I agree, ProRes is really the only practical 10-bit 422 option. I just wanted to leave stone un-turned.

Andrew Kolakowski wrote:Example from here- never ever (using loud voice) use with ffmpeg -r 23.976, but -r 24000/1001.

I didn't and never ever do (said in a defensively emphatic voice).

Andrew Kolakowski wrote:Reminds me certain news papers, like The Sun etc :) Big stories about small, meaningless things :)


But people still buy it...for some reason ;)
Offline

Andrew Kolakowski

  • Posts: 4315
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostFri Mar 31, 2017 3:04 pm

Many buy it! Maybe because it has big and saturated pictures :)
Offline

Peter Cave

  • Posts: 815
  • Joined: Thu Aug 23, 2012 6:45 am

Re: Panasonic GH5 test videos don't work in Resolve 12.5

PostSat Apr 01, 2017 5:36 am

Jean Claude wrote:Yes, on windows too but in 8 bits. When it is in 10 bits => media offlline. (Unless it's my PC?)


GH5 10bit files are working perfectly on Mac Resolve 12.5.5, it may be your Windows system.
Resolve 15
Mac OSX 10.13.3
iMac (Retina 5K, 27-inch, Late 2014)
4 GHz Intel Core i7
AMD Radeon R9 M295X 4096 MB
PreviousNext

Return to DaVinci Resolve

Who is online

Users browsing this forum: centralparker, Marc Wielage, Peter Fleming, Ron Simmons and 17 guests