Jump to content

GH5 proxy/transcode - what's your workflow?


Linus N
 Share

Recommended Posts

Hey team!

I'm on my 3rd day out of five shooting a project with my GH5. It's the first bigger project I've shot on it and I'm eager to hit the editing suite when I get back. As I'm driving around I keep thinking about the horror that is the Long-GOP codec, so my question to you is: what's your workflow?

I edit on a solid PC in Win10, Premiere for editing, AE for vfx and Resolve for color. Running the 1080/4K is not a problem until I start the heavier vfx/color work.

Shooting a mix of 1080/50fps 10bit and 1080/100fps 8bit (and some 2.7K 25fps on my Mavic). Delivery is 1080/25fps.

Options in my head:

1. Transcode to DNxHR, not sure what flavor. Input much appreciated!

2  Do the proxy workflow in Premiere and render out DNxHR master for coloring. Vfx is done with dynamic link

Interested to hear how others go about this, cheers!

Link to comment
Share on other sites

EOSHD Pro Color 5 for Sony cameras EOSHD Z LOG for Nikon CamerasEOSHD C-LOG and Film Profiles for All Canon DSLRs

I'd be wary of trancoding any original camera media unless you have huge data storage as the edit friendly codecs are like DNx / ProRes use lossy compression and the only way to be sure you are not throwing away data that may become apparent when you start pushing your grade is to use a lossless uncompressed codec which will create huge amounts of data. In Resolve use 'generate optimised media' and in Premier use the 'ingest settings' to do the same to create edit DNx/Prores to do all your editing in. Then when you come to render to output it will use your original camera files as the source. If your PC is still struggling to play back with heavy edits then you can go to proxies.

Link to comment
Share on other sites

3 hours ago, Shirozina said:

I'd be wary of trancoding any original camera media unless you have huge data storage as the edit friendly codecs are like DNx / ProRes use lossy compression and the only way to be sure you are not throwing away data that may become apparent when you start pushing your grade is to use a lossless uncompressed codec which will create huge amounts of data.

The major data loss lies in the extremely lossy acquisition codec. It's a famous Adobe myth that any loss "becomes apparent" with the aforementioned intermediates as valid substitutes for the heavily compressed originals. Unless, of course, the originals have stored more data - or, better: different data levels. Wrapping also can be very lossy, since proprietary codec implementation (such as Sony's XAVC with the wide color gamut, we don't know yet about GH5 10-bit) may include metadata that get lost in translation. This is a known, common issue with wrapping. The same problem applies to transcoding. The software used to decode the video has to be able to recognize it natively. Even if you use Uncompressed, wrong or missing decoding descriptions will degrade quality. Therefore all the current workarounds for PP are crooks. If some NLEs accept the clips already (FCP X, Edius, Resolve Studio), well, that doesn't automatically mean they do better. I suspect they just assume they are standard MP4 for the sake of playback. AVFoundation - the MacOS framework - will decode anything that it recognizes as video. Quicktime on the other hand rejects the GH5 10-bit-clips (but not the 8-bit ones) as unknown. Sounds bitchy and lame, but is probably correct. 

Panasonic should release an importer-tool. Or help the NLE companies to implement the decoder.

Link to comment
Share on other sites

Until CPU's become fast enough to decode highly compressed camera media on the fly what choice is there but to work from Proxies / optimised media substitutes in the timeline? At least you are retaining the original camera files for future use when hardware can handle them. I'm just advising against transcoding as some users may be tempted to throw away the original camera files in the mistaken belief that a transcode is preserving perfectly whatever was contained (however imperfectly) in the original camera files.

Link to comment
Share on other sites

45 minutes ago, Shirozina said:

Until CPU's become fast enough to decode highly compressed camera media on the fly what choice is there but to work from Proxies / optimised media substitutes in the timeline? At least you are retaining the original camera files for future use when hardware can handle them. I'm just advising against transcoding as some users may be tempted to throw away the original camera files in the mistaken belief that a transcode is preserving perfectly whatever was contained (however imperfectly) in the original camera files.

That's right. "Future use" can't be far in the future or either Panasonic or the NLE companies will lose customers. Ridiculous, however, is the remark about today's weak CPUs. H.264 UHD long-gop-10-bit 422 is around for quite a while, for example in FS7's XAVC. It wasn't supported directly in FCP X for a few months, you had to use a Sony plugin (which by the way made sure the clips were interpreted correctly). But apart from that, smooth native playback never was an issue, notoriously on much weaker systems than Adobe needed, be it Windows or OSX. More so, since you could unscrupulously transcode to ProRes, with no visual loss whatsoever.

Link to comment
Share on other sites

  • 2 weeks later...

I use Avid MediaComposer. My Workflow is to use the Drastic MediaReactor Plugin. There are several Typs of Plugin Versions, Workstation and QuickTime, for MAC and PC.

There are Trial Versions. With  MediaReactor for Workstation you can AMA Link the GH5 10Bit 4.2.2

DaVinci Resolve Studio 14 should handle the GH5 10Bit 4.2.2 for 299,-Bugs

Pics are from MediaRector for Quicktime

Drastic 01.PNG

Drastic 02.PNG

Link to comment
Share on other sites

On 2017-5-26 at 9:32 PM, Axel said:

The major data loss lies in the extremely lossy acquisition codec. It's a famous Adobe myth that any loss "becomes apparent" with the aforementioned intermediates as valid substitutes for the heavily compressed originals. Unless, of course, the originals have stored more data - or, better: different data levels. Wrapping also can be very lossy, since proprietary codec implementation (such as Sony's XAVC with the wide color gamut, we don't know yet about GH5 10-bit) may include metadata that get lost in translation. This is a known, common issue with wrapping. The same problem applies to transcoding. The software used to decode the video has to be able to recognize it natively. Even if you use Uncompressed, wrong or missing decoding descriptions will degrade quality. Therefore all the current workarounds for PP are crooks. If some NLEs accept the clips already (FCP X, Edius, Resolve Studio), well, that doesn't automatically mean they do better. I suspect they just assume they are standard MP4 for the sake of playback. AVFoundation - the MacOS framework - will decode anything that it recognizes as video. Quicktime on the other hand rejects the GH5 10-bit-clips (but not the 8-bit ones) as unknown. Sounds bitchy and lame, but is probably correct. 

Panasonic should release an importer-tool. Or help the NLE companies to implement the decoder.

I don't think that's the case in this situation. As Justin discovered it looks like the luminance values are just being tagged incorrectly by the NLEs reading the wrapper. The two files are indistinguishable in quality that is for sure. 

Link to comment
Share on other sites

6 hours ago, Orangenz said:

I don't think that's the case in this situation. As Justin discovered it looks like the luminance values are just being tagged incorrectly by the NLEs reading the wrapper. The two files are indistinguishable in quality that is for sure. 

I find this an academic distinction. If it comes to video (latin for "I see") luminance values change the perception of the image and influence the quality. Remember 5D2RGB? A Quicktime-based transcoder from Canon H.264 mov to ProRes. Full range was right for EOS clips, but if you chose it for Lumix AVCHD (16-235), you actually lost luminance values - and you couldn't recover them in post. I am not stating that this is the case here, but do you know for sure?

Link to comment
Share on other sites

On 26.5.2017 at 0:54 PM, Shirozina said:

Smooth native playback ( or lack thereof) is the issue otherwise why would people need to use proxies / optimised media / transcode?

Because smooth playback will stay smooth with multiple effects, multicam and the like. Your machine has no handicap? 18 strokes for 18 holes? Very impressing. It's just not what I see and hear (not least in this forum).

Link to comment
Share on other sites

On 2017-6-6 at 6:00 AM, Axel said:

I find this an academic distinction. If it comes to video (latin for "I see") luminance values change the perception of the image and influence the quality. Remember 5D2RGB? A Quicktime-based transcoder from Canon H.264 mov to ProRes. Full range was right for EOS clips, but if you chose it for Lumix AVCHD (16-235), you actually lost luminance values - and you couldn't recover them in post. I am not stating that this is the case here, but do you know for sure?

I get your technical point, and it's a good one. But you can see the files so it's not some theoretical thingy. 

Link to comment
Share on other sites

On 5/26/2017 at 7:52 AM, Jn- said:

 

GJeffreys util is a rewrap to MXF, not a transcode, so its very fast, unless you mean playback of the MXF after the rewrap?

 

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

Quote from G Jeffrey ...

"Wrapping to mxf as been updated. Thanks to john_dennis who reported a problem with 23.976fps mov files.

There is also support for multichannel audio.

Refer to my https://www.vegascreativesoftware.info/us/forum/gh5-4k-24-30p-problem--105152/#ca658569  for updated installation instruction and batch files."

 

This is my batch file wrap of the wrap?

Link to JN- zip files with updated code ...

https://www.dropbox.com/sh/j6p4adbm983p435/AABq-0tGLVRzqRDHnAufINjIa?dl=0

Hmm, I'm getting the following errors:
I have put in hardcoded paths to the fmpeg executables, and REM'd the @echo off if you want the complete run.

[mov,mp4,m4a,3gp,3g2,mj2 @ 00000000004e7240] decoding for stream 0 failed
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'P1000002.mp4':

[mov,mp4,m4a,3gp,3g2,mj2 @ 0000000000657160] decoding for stream 0 failed
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'P1000002.mp4':


The resultant file will start in Resolve 12.5, then it becomes Media Not Found, though it's still available.
Unlike the .mp4 file, which Resolve never sees.

One other thing, the file is SMALLER than the .mp4 file.
?
04/11/2017  04:38         6,014,478 bmxtranswrap.exe
04/24/2017  09:00             1,270 mov2mxfV2.2.cmd
06/07/2017  21:26             1,496 mp42mxfV2.2.cmd
06/03/2017  17:16       492,650,061 P1000002.mp4
06/09/2017  22:14       484,120,334 P1000002.mxf
04/11/2017  04:38         5,637,134 raw2bmx.exe

I haven't tried it against .mov files yet...

 

Oh, and the files in your link, do not unzip, corrupt?

https://www.dropbox.com/sh/j6p4adbm983p435/AABq-0tGLVRzqRDHnAufINjIa?dl=0

I'm using the Orangenz

Link to comment
Share on other sites

14 hours ago, Orangenz said:

That link isn't mine. It from Jn by the looks.

Correct, so, I am using your link, files.

6 hours ago, Jn- said:

I just downloaded the CV2MXF.zip, copied the files out of the zip and ran the batch file, on a different pc than from where they were uploaded to dropbox, no problem.

Perhaps someone else would oblige by downloading the 2 zip's and confirm no corruption? Thanks. 

https://www.dropbox.com/sh/j6p4adbm983p435/AABq-0tGLVRzqRDHnAufINjIa?dl=0

These two zips have also had small modifications since first put up, main improvement is they both now only use a single batch file to run, both log total time taken to process all files etc.  The current version number is in the respective readme.txt files.  There were no version numbers in the origionals

Must be my paranoia settings in FireFox, used IE, now works.

Actually, I think I right-clicked the files, and saved as.  If you just dbl-click, it comes up different and now works.

Will run this again, thanks!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • EOSHD Pro Color 5 for All Sony cameras
    EOSHD C-LOG and Film Profiles for All Canon DSLRs
    EOSHD Dynamic Range Enhancer for H.264/H.265
×
×
  • Create New...