Adobe breaks GH5 10bit import for PC - Solution Inside!

[Orangenz]

Well I was pretty happy editing the 10bit files with Premiere PC. Adobe has gone and broken it though so don't update to the latest version :/  Can try reverting http://blogs.adobe.com/adobecare/2015/06/16/how-to-find-and-install-previous-version-of-adobe-apps-in-cc-2015/ or the official statement is to transcode with a non-adobe product.

[Orangenz]

57 minutes ago, Jn- said:

Hi Orangenz, GJeffrey on Vegs Pro forum made up a tool to convert GH5 10 bit 422 to MXF without transcoding, just a rewrap, so no data loss and very fast.  Uses ffmpeg and BMX tools. 

 

https://www.vegascreativesoftware.info/us/forum/gh5-4k-24-30p-problem--105152/#ca658650

OOOOoo love you! Hopefully works for Premiere as well as Vegas.

[Orangenz]

1 hour ago, Jn- said:

Hope it works out, do tell.  An alternative is to transcode to Prores also using ffmpeg, it's just slower than GJeffrey's solution.

Yes it works. It seems to play faaaar smoother than the mp4 files as well. STRANGELY better in fact. Still a loud click on the end of files. Still 8 audio free frames at the start of each clip but now no gap at the end of clips. 

https://www.vegascreativesoftware.info/us/forum/gh5-4k-24-30p-problem--105152/#ca658569

I used ninite.com to download the 7z unzipper. It's easier that way and don't risk adware. 

Have put all the instructions into a pdf here. It rewraps the files, not transcode so it's very fast. 

GH5 10 bit fix.pdf

[JustinJohnson]

Thanks for the info on this. Would you test an 8-bit file for me?

My testing shows that I have to shift the video part over 2 frames and leave the audio in it's original spot to line up with the original mp4 8-bit file .  Also the C4K files are being read by Premiere with a non 1.0 aspect ratio. The UHD version comes over fine but I have the above issue.

[JustinJohnson]

For my test.. I used tool from the link to convert a UHD 8 bit mp4 file to mxf. It should be a re-wrap. When I place both of them on a new timeline in Premiere.. the mxf video track is shorter by 3 frames. I placed the mxf above the mp4 video track to check this.  Turning on/off the mxf video track shows it's not matched up frame perfect. By shifting the video portion 2 frames to the right it lines up with the mp4.  Thanks for checking that out for me.

Edit: Interesting enough. I installed latest version of Vegas 14. Added my two clips in and the properties show 1 frame different. Placing them like I did in premiere , one above the other, the 1st two frames are different..but every frame after that appears to line up perfectly. With the only other issue being the mxf file is one frame shorter on the end. So Vegas appears to handle the re-wrap better for sure. At least on my system.

Edit 2: Using MediaInfo to look at the files, it reports a different duration also. 

MP4 : Duration : 6 s 0 ms

MXF : Duration : 5 s 958 ms

[Orangenz]

3 hours ago, Jn- said:

Hi JustinJohnson,  I'm not certain I follow you but this is what I've checked.

On Win 10, Vegas Pro 14,  I tested 2 4K UHD 8 bit  .mp4 and .mov files also 2 2K .mp4 and .mov files, only 8 bit.  

The audio and video were both exactly the same lengths and matched start to end, no displacement for all 4 files, not even 1 frame off.  Hope that helps.

Yes Vegas corrects some of those audio shifts. For premiere and 8 bit you just rename the files from .MP4 to .MPEG and it imports them at the right length. 

5 hours ago, JustinJohnson said:

Thanks for the info on this. Would you test an 8-bit file for me?

My testing shows that I have to shift the video part over 2 frames and leave the audio in it's original spot to line up with the original mp4 8-bit file .  Also the C4K files are being read by Premiere with a non 1.0 aspect ratio. The UHD version comes over fine but I have the above issue.

Try the renaming. My Onehunga vid was 10bit C4K and didn't have a problem with aspect.

9 hours ago, Jn- said:

Very good!  Nice and useful PDF.

For my own convience I wrapped a batch file (old style) around the tools supplied by GJeffrey, CV2MXF.ZIP

The CV2P.ZIP is for GH5 10 bit 422 to Prores, requires ffmpeg also.

CV2MXF.zip

CV2P.zip

So, what does that do?

[Orangenz]

7 hours ago, Jn- said:

"Still a loud click on the end of files. Still 8 audio free frames at the start of each clip but now no gap at the end of clips."

Hi Orangez, that may be only an Adobe issue.  I haven't seen this with Vegas 14, tested using 10 bit 422 files obviously and a .mov and .mp4 version, converted to .mxf. The native files are of course unreadable in Vegas Pro, video is just green colour.

I hear it in Vegas as well. It sounds related to hitting the shutter button to stop recording, although an electronic byproduct. Will try using remote start stop, but that won't affect it if electronic in source.

[Orangenz]

Any simple way of getting windows explorer to show a content thumbnail for the mxf files?

[JustinJohnson]

Hey Orange, I posted a response on the Adobe boards but hopefully you see this here. Check your Luminance Level in the GH5. If it's set to 64-940 or 64-1023 10 bit files work just fine. It's only when it's set to 0-1023 that I get the audio import only.

I have recorded a bunch of clips with my level set to 64-940 now and now import errors. This should be the proper setting for Premiere as I know it, it defaults to 0-1023 I believe.

I am running some more test to see if this is it.

[Orangenz]

7 hours ago, JustinJohnson said:

Hey Orange, I posted a response on the Adobe boards but hopefully you see this here. Check your Luminance Level in the GH5. If it's set to 64-940 or 64-1023 10 bit files work just fine. It's only when it's set to 0-1023 that I get the audio import only.

I have recorded a bunch of clips with my level set to 64-940 now and now import errors. This should be the proper setting for Premiere as I know it, it defaults to 0-1023 I believe.

I am running some more test to see if this is it.

Was going to copy and paste your info here but ermm got distracted by the European judo champs on tv. If the rewrapping isn't working for you then the luminance change is the next best thing. Thanks for finding it out!

[Orangenz]

Bump so people can be reminded about this solution. GH5 10 bit fix.pdf

[Sage]

On 4/21/2017 at 1:29 AM, JustinJohnson said:

Hey Orange, I posted a response on the Adobe boards but hopefully you see this here. Check your Luminance Level in the GH5. If it's set to 64-940 or 64-1023 10 bit files work just fine. It's only when it's set to 0-1023 that I get the audio import only.

I have recorded a bunch of clips with my level set to 64-940 now and now import errors. This should be the proper setting for Premiere as I know it, it defaults to 0-1023 I believe.

I am running some more test to see if this is it.

Thanks for sharing this Justin. To further this, it looks like the 64-940 (0-100%) IRE placement matches the official Varicam specification for V-log, as shown in the graphs on this page:

http://www.slashcam.de/artikel/News/Naeheres-zum-Panasonic-GH4-V-Log-Update.html

It would make sense that it is the data arrangement that Premiere is expecting and was coded to handle previously (standard Varicam levels)

[Sage]

Indeed; its confirmed. In this white paper:

http://pro-av.panasonic.net/en/varicam/common/pdf/VARICAM_V-Log_V-Gamut.pdf

- the values of 7.3% IRE and 61% IRE cited as corresponding to the 10-bit values of 128 & 602 respectively exactly match the 64-940 luminance level placement.

[Orangenz]

5 hours ago, Sage said:

Thanks for sharing this Justin. To further this, it looks like the 64-940 (0-100%) IRE placement matches the official Varicam specification for V-log, as shown in the graphs on this page:

http://www.slashcam.de/artikel/News/Naeheres-zum-Panasonic-GH4-V-Log-Update.html

It would make sense that it is the data arrangement that Premiere is expecting and was coded to handle previously (standard Varicam levels)

As Luke said elsewhere, Adobe was given the files a long time before release. In addition, the luminance setting of vlog files is set by the camera and the compressed luminance recording is on top of the full range for consistent scale. For non-log files making this change does allow import into Premiere but I don't find this particularly useful as the rewrapped files edit considerably easier and have the corrected length. 

[Sage]

1 hour ago, Orangenz said:

As Luke said elsewhere, Adobe was given the files a long time before release. In addition, the luminance setting of vlog files is set by the camera and the compressed luminance recording is on top of the full range for consistent scale. For non-log files making this change does allow import into Premiere but I don't find this particularly useful as the rewrapped files edit considerably easier and have the corrected length. 

Yes, the rewrap approach is probably the best way to go (I don't have the camera yet)

The information above, and the little discovery by Justin is of particular interest to me as I am working on a little project involving V-log mapping at the moment

That compressed luminance recording of v-log and v-log L is even beyond the 64-940 (0-100%) IRE envelope. I.E. exposure bottom* is intended to map at 128. And that is with the 64-940 envelope

[Orangenz]

42 minutes ago, Sage said:

Yes, the rewrap approach is probably the best way to go (I don't have the camera yet)

The information above, and the little discovery by Justin is of particular interest to me as I am working on a little project involving V-log mapping at the moment

That compressed luminance recording of v-log and v-log L is even beyond the 64-940 (0-100%) IRE envelope. I.E. black is intended to map at 128. And that is with the 64-940 envelope

You cannot change the luminance values in log mode. 

[Sage]

10 minutes ago, Orangenz said:

You cannot change the luminance values in log mode. 

Excellent, that is what I was missing. This is even more puzzling; why wouldn't it work, given the 64-940 envelope? Adobe used to be fast with this kind of thing

[Orangenz]

1 hour ago, Sage said:

Excellent, that is what I was missing. This is even more puzzling; why wouldn't it work, given the 64-940 envelope? Adobe used to be fast with this kind of thing

Log is set to full range Lum values in 8 or 10bit modes, not reduced. Considering the time they had the codecs from panasonic, I also think they should have been able to do a bit better.

[Orangenz]

Updated pdf. Although I don't know what the reference to ffprobe.exe is about. 

GH5 10 bit fix.pdf

[Sage]

9 hours ago, Orangenz said:

Log is set to full range Lum values in 8 or 10bit modes, not reduced. Considering the time they had the codecs from panasonic, I also think they should have been able to do a bit better.

That makes the most sense as to why its not working; that would mean that Panasonic has coded the GH5 file header to specify the wrong IRE placement, according to their own V-Log specs (or it is misread by Premiere, due to differing header format from Varicam). And it is a matter of file header ID, as the wrapping method's success reveals (explains the inconsistent handling of levels across NLEs)