Delivering x264

I'm a fan of the free x264 encoder, especially the CRF option that never seems to show up in commercial encoders. At the moment, I'm using a convoluted process of exporting Cineform from Resolve, using Adobe Media Encoder to create a UT AVI file, then finally transcoding with MeGUI to x264. (I don't care for command line tools, I want that GUI experience.)

https://www.videohelp.com/software/Ut-Video-Codec-Suite

I'd love to simplify the process. What methods are you guys using to deliver x264?

Use:
https://sourceforge.net/projects/vdfiltermod/

which will read Cineform directly (it uses native support based on latest Cineform SDK).

You have easy access to x264 and x265 including 8/10 (and 12bit for x265). Export as MOV, MP4 or MKV.

If you want to simplify things I still would suggest using a simple command line:

1. Export Cineform from Resolve
2. ffmpeg -i cinefile.mov -c:v libx264 -crf 15 h264.mp4

It can't get any simpler than that!

If you want to simplify things I still would suggest using a simple command line:

1. Export Cineform from Resolve
2. ffmpeg -i cinefile.mov -c:v libx264 -crf 15 h264.mp4

It can't get any simpler than that!

#2 can be made even simpler, by writing a batch script. Then it's just double click the script to run it, it's even faster than a GUI!

If you want to simplify things I still would suggest using a simple command line:

1. Export Cineform from Resolve
2. ffmpeg -i cinefile.mov -c:v libx264 -crf 15 h264.mp4

It can't get any simpler than that!

#2 can be made even simpler, by writing a batch script. Then it's just double click the script to run it, it's even faster than a GUI!

Yes, and you can write a batch file taking a parameter so it would work for every given file or for instance for all files in a given folder. Also I would recommend ConEmu, it is an application that makes using the windows command line a lot more friendly.

There are some GUIs for ffmpeg so if you need such a functionality then you can use one of them.
CMD is definitely not what most people want to do on daily basis.

So after running some test exports and doing some pixel peeping at 400%, I'm pretty well satisfied with Resolve's Medium setting for MP4 deliverables. It's not quite as good as my MeGUI transcodes, but without the 400% pixel peeping, I'd never know the difference. (And even with 400%, it was often difficult to see the difference.)

I'm pleasantly surprised how good Resolve's H.264 encoding is. Very usable for my event-work clients.

What bitrate are we talking about?

At the Medium setting, it came out to around 20 Mb/s. At High it was around 30 Mb/s. Best came out around 50 Mb/s.

For HD?
You must be on PC as on Mac options are different.

It's just a question :
The H264 is standardized by the ITU-T Video Coding Experts Group (VCEG) and the ISO / IEC JTC1 Moving Picture Experts Group (MPEG).

What about x264 ?

x264 is just the name of the product- it's the same standard h264.
Everyone can write own h264 encoder- one will be great another crap (all still will adhere to h264 standard).
x264 was made as open source project where many people contributed their skills- this is why it's so good. It's product of many talented programmers (students and not only) supported by doom9 community which provided testing (on a level which not a single company can get).

You must be on PC

Of course. I ain't no weirdo.

I've just installed Win10 on my Mac and after 10min it already made me frustrated
Will use it when I need, but don't think I will come back (and been PC user for 15 years and Mac only for 3).
Looks like there is no hope me me

I'm a fan of the free x264 encoder, especially the CRF option that never seems to show up in commercial encoders. At the moment, I'm using a convoluted process of exporting Cineform from Resolve, using Adobe Media Encoder to create a UT AVI file, then finally transcoding with MeGUI to x264. (I don't care for command line tools, I want that GUI experience.)

https://www.videohelp.com/software/Ut-Video-Codec-Suite

I'd love to simplify the process. What methods are you guys using to deliver x264?

I used to use MeGUI for transcoding Cineform avi exports to x264, but I used the VFW Cineform codec (with GoPro Studio - Quik installed) as decoder. So I would create the input AVISynth script using the MeGUI 'AVS Script Creator' tool - 'Enable Direct Show in the AVS Script Creator' now needs to be checked in Options > Settings to give AVISource as an input option (you probably know that). I would then modify the script (Script tab) adding the line ConvertToYV12(interlaced=false) - for progressive Rec709 content, that is - to convert decode YUY2 to YV12. For audio transcoding I would use the source Cineform avi (with WAV audio) file for input. And then mux the x264.mp4 and AAC audio encodes using the integrated mp4 muxer. Or else if encoding for Blu-ray I would encode to x264 raw (.264) and AC3 audio and mux to m2ts using tsMuxer.

So also pretty convoluted I guess, but not involving any secondary lossless intermediate (I assume you configure the UTVideo encoder for YUV420 compression so as to convert YUY2 to YV12 internally ?) And that protocol suited me because I could add other AVS processing filters to the script as needed. Still prefer AVISynth for some PP - denoise/contra-sharpening, deinterlacing. There again I'm using the free version of Resolve.

These days though for straight transcoding to x264 I mostly use FFMPEG (command line) or, more recently, VirtualDub_FilterMod, as Andrew mentioned. It really is an excellent tool with very active development. Just a matter of configuring the x264 encoder parameters to match your existing MeGUI profile(s). There's provision for adding extra command line parameters if you need them. No fussing with AVISynth scripts, but that's an input option if you want it.

That's exactly how I used to do it, Bryan. But for some reason beyond my ability to sus out, it's just not working any more. I cannot get MeGUI to open Cineform AVI files using AVI Source, despite having the setting turned on and Cineform decoder installed through GoPro Studio. The UT conversion is only there because that opens fine in MeGUI. Unfortunately, Resolve doesn't work like every other Windows program in existence. It doesn't allow access to DirectShow codecs installed on the system, so I can't export UT files directly.

I cannot get MeGUI to open Cineform AVI files using AVI Source, despite having the setting turned on and Cineform decoder installed through GoPro Studio.

That's odd - sounds like there's some codec conflict going on somewhere. Maybe try re-installing GoPro Studio (Quik) ?

Only thing I can suggest otherwise is trying VirtualDub_FilterMod which uses the 'native' (SDK implementation) Cineform decoder, even with GoPro Studio installed.

Edit: Just rechecked MeGUI - latest version 2824 on the Development Update Server - and it loads Resolve-exported Cineform.avi files with AVISource just fine. If you are using the Stable version, maybe try switching to the Development server version or reinstalling. Purely a stab in the dark. If you can load UTVideo.avi files OK, it does seem like there's some codec conflict going on.

Thanks for trying, but I've done both of those things already. Reinstalled GoPro Studio and am using MeGUI 2824.

It just doesn't work. AVI Source will not show as an option for Cineform AVI files. It used to, which makes this all the more frustrating.

Beats me, and exporting Cineform.mov is not an option for MeGUI input either. AVS Script Creator will give L-Smash as an available file indexer but the resulting decode image is garbled.

When I was on Win7 I once had an issue with UTVideo where the RGB compression variants no longer showed up in any program supporting third-party VFW codecs. Never got to the bottom of it.

Maybe Andrew has some further insight as to what's going on ?

There has to be some issue in your system. It could be issue with 32bit v 64bit, but Cineform has modules for both as far a I know.

Try uninstalling GoPro Studio and install just decoder part:
http://cineform.com/gopro-cineform-decoder
(this definitely has 64bit module)

If not use VirtualDub_FilterMod which is nice and simple way of encoding to x264/5 (and it has all bit depths). It will read Cineform, DNxHR, ProRes etc. It's old, good Vdub on steroids

AVS Script Creator will give L-Smash as an available file indexer but the resulting decode image is garbled.

Yep. That's what happens with my Cineform AVI files.

Well, I'm getting closer. Installing the linked to Cineform decoder now offers the option in MeGUI to open the Cineform AVI file with DirectShow Source. The preview even comes up and plays.

Unfortunately, the AVS script throws up a 32/64 bit error incompatibility when trying to load the video.

It's always something.

AVS Script Creator will give L-Smash as an available file indexer but the resulting decode image is garbled.

Yep. That's what happens with my Cineform AVI files.

That's odd - in my tests no file indexer option is given for Cineform.avi files, only AVISource. On the other hand, L-Smash and ffms2 are available as file indexer options for UTVideo.avi and MagicYUV.avi transcodes (YV12 compression) and the created scripts preview/import perfectly well.

Well, I'm getting closer. Installing the linked to Cineform decoder now offers the option in MeGUI to open the Cineform AVI file with DirectShow Source. The preview even comes up and plays.

Unfortunately, the AVS script throws up a 32/64 bit error incompatibility when trying to load the video.

Likewise, don't see any 'DirectShow Source' option per se with the AVS Script Creator, only AVISource. At least that's the case with GoPro Studio installed. Does the linked-to Cineform decoder somehow give different options ?

Another stab in the dark. Are you using the 32-bit (x86) MeGUI:

https://sourceforge.net/projects/megui/files/megui-stable/2808/

... or the 64-bit (test) version that uses AVISynth+ ?

https://sourceforge.net/projects/megui/files/megui-test/2808/

I have the 32-bit version but thought I'd check-out the 64-bit build also. On my system at least, both versions (updated from Development Server to 2825) imported Cineform.avi files as AVISource without any problems, but what had me wondering about your situation was this VideoHelp forum thread:

https://forum.videohelp.com/threads/387552-Megui-DirectShowSource-or-AVISource-is-not-supported

If you are using the 64-bit version, worth maybe trying the 32-bit version instead...or vice-versa?

You could also raise your issue on the Doom9 forum MeGUI: General Questions and Troubleshooting thread:

https://forum.doom9.org/showthread.php?t=105920

There's another thread devoted to the 64-bit version:

http://forum.doom9.org/showthread.php?t=153904

or for bug reports/feature requests specifically:

https://sourceforge.net/p/megui/bugs/
https://forum.doom9.org/showthread.php?t=151159

Well, I'm getting closer. Installing the linked to Cineform decoder now offers the option in MeGUI to open the Cineform AVI file with DirectShow Source. The preview even comes up and plays.

Unfortunately, the AVS script throws up a 32/64 bit error incompatibility when trying to load the video.

It's always something.

You have issue with 32bit v 64bit.
Try making everything 64bit (avisyth and MeGUI).

What methods are you guys using to deliver x264?

1/ Resolve -> ProRes
2/ ProRes -> Handbrake

Does the linked-to Cineform decoder somehow give different options ?

It does. With GoPro Studio installed, my only option was File Indexer, which went down the L-Smash route.

With the Cineform decoder installed, I get a DirectShowSource option. Using that, MeGUI is trying to open the file using Haali Media Splitter, which only has a 32 bit version and doesn't work with the 64 bit install of AVISynth and MeGUI.

With my UT files, I still get the AVISource option.

You should move to 64bit apps.
Directshow source file loading should be avoided as it's not very robust and it's single threaded inside avisynth.


L-Smash route is totally separate from Cienofrm codec as it provides native decoding. You need quite latest version as Cienform decoder is quite new. It's also not very fast.

Best way is avisource() as this will use multithreaded 64bit Cineform official decoder which is very fast/reference one.

All this hassle can be avoided by using Vdub FilerMod- simple, stand alone and effective app.

You should move to 64bit apps.

That was the version that was giving me no end of troubles. I removed it and went with the 32 bit version, and it seems to be working again. I can export Cineform AVI from Resolve and go straight into MeGUI again.

Thanks everyone for your input on this. I was looking for a work around, and ended up with a fix.

Ok, at least you are back to "normal".

Well, I thought I had it.

For some reason, Resolve isn't exporting Cineform AVI properly. It's adding contrast that shouldn't be there. In comparison, Resolve is exporting Cineform MOV correctly. This was determined by bringing both exports back into Resolve and comparing to the original timeline.

(It's always something.)

On a positive note, it looks like Resolve's High MP4 preset is very close to my "Ludicrous Speed" MeGUI settings in overall bitrate and quality, so maybe I'll just use that.

For some reason, Resolve isn't exporting Cineform AVI properly. It's adding contrast that shouldn't be there. In comparison, Resolve is exporting Cineform MOV correctly.

Set your data levels at "video" (don't leave it at "auto"). Looks to be a bug, auto shouldn't be defaulting to "full".

My typical x264 deliverable workflow:

Prores HQ masters/openEXR DI -> Resolve
Resolve -> openEXR DI
openEXR DI -> ffmpeg libx264

Perfectly lossless workflows between Resolve, After Effects, Nuke, and Premiere Pro, personally vetted and the only thing that matters to me, but just happens to offer the added benefit of segmented encoding.

Not for everyone as it's very specific due to Nuke etc. envelopment.
80% people won't need to touch EXR.

Set your data levels at "video" (don't leave it at "auto").

That seems to give me output on parity with the original timeline. Thanks.

Though it does raise another concern. The footage was shot on the GH4 in full range (0-255). Why is Resolve treating it internally as 16-235?

I notice that even working with CinemaDNG, Resolve seems to be treating it as Video range internally. That seems weird to me.

On a positive note, it looks like Resolve's High MP4 preset is very close to my "Ludicrous Speed" MeGUI settings in overall bitrate and quality, so maybe I'll just use that.

Out of interest, what are your MeGUI x264 settings ?

The footage was shot on the GH4 in full range (0-255). Why is Resolve treating it internally as 16-235?

Because Resolve doesn't recognize ('auto' interpret) this footage as being full range and defaults to 'Video' levels i.e. clamps full 0-255 range to (limited, broadcast safe) 16-235 range (or 0-1023 to 64-940 in 10-bit scale). If you want to process and export at full range you should set the Data Levels in the Clip Attributes and Export Video>Advanced Settings to 'Full' to assert that interpretation.

Something to be aware of also - if you were to import and 'pass through' (i.e. without any manipulation of levels on the Color page) your full range footage at 'Full' data levels and export at 'Video' levels it will get compressed (proportionately) to 16-235 (64 - 940) range on export, not clamped/clipped i.e. reduced contrast owing to the raised black and lowered white points.

For some reason, Resolve isn't exporting Cineform AVI properly. It's adding contrast that shouldn't be there. In comparison, Resolve is exporting Cineform MOV correctly.

Set your data levels at "video" (don't leave it at "auto"). Looks to be a bug, auto shouldn't be defaulting to "full".

What's happening there is that your full range footage gets clamped to 16-235 (64-940) on import (Auto>'Video' levels) and then on export (Auto>'Full' levels) that clamped range is expanded out (proportionately) to 0-255 (0-1023) range - hence the increased contrast.

Personally, with (linear) full range material I'm more inclined to soft-clip, either on first pass at 'Full' data levels or else at 'Video' levels - although clamped to 64-940 range on the timeline, source data outside of those points is not lost and can be pulled in.

What's happening there is that your full range footage gets clamped to 16-235 (64-940) on import (Auto>'Video' levels) and then on export (Auto>'Full' levels) that clamped range is expanded out (proportionately) to 0-255 (0-1023) range - hence the increased contrast.

I don't think that's quite it. Cineform .avi delivery in R14, set at "auto", remaps *all* video footage, including Prores HQ, with blacks getting crushed and highlights clipped. Last I checked, Cineform .mov exports are correct, at "auto".

I notice that even working with CinemaDNG, Resolve seems to be treating it as Video range internally. That seems weird to me.

Once debayered, CDNG is going to be mapped to 16-235, no? "Full" is what would be weird.

Once debayered, CDNG is going to be mapped to 16-235, no? "Full" is what would be weird.

Limited range is rather for YUV based formats.
If you record inside camera to YUV based format then you most likely will get limited (although some cameras allow for full range also).

Just debayered RAW data from decent camera should be presented as full range in my opinion.

Cineform YUV should be rather limited range, where RGB mode full range.

[Just debayered RAW data from decent camera should be presented as full range in my opinion.

CDNG mapped as "full" would I think create an unworkable situation. What if CDNG and Prores HQ (for example) are on the same timeline? In my case, this is common. It's all video in the end, and will be delivered as video. Why fight it?

There is no really harm in treating it as limited, but for me RAW data should be mapped to full.
At the export it's decided by export codec and has to be scaled to full or limited accordingly anyway.

DNG as full and ProRes as limited should still give you same end result (if it's all handled properly). It's all converted to 32bit float data anyway and if file is properly interested then all will be fine.

If you want to process and export at full range you should set the Data Levels in the Clip Attributes and Export Video>Advanced Settings to 'Full' to assert that interpretation.

Thanks, Bryan.

How does that work, exactly? Changing the Clip Attributes doesn't result in any observable difference.

It should be visible in preview once you change it and hit apply.
If you didn't see change it means auto was the same as you manually chosen. Try opposite.

What if CDNG and Prores HQ (for example) are on the same timeline?

I would want both at Full range. I'm not delivering broadcast.

Auto, Video and Full setting in Clip Attributes all look identical for a CinemaDNG (Pocket) clip. No difference is observable when changing that setting.

There is no really harm in treating it as limited

Aren't you reducing Dynamic Range a little bit?

Auto, Video and Full setting in Clip Attributes all look identical for a CinemaDNG (Pocket) clip. No difference is observable when changing that setting.

Which I would say is correct as this is RAW source and it's handled differently than "normal" video source files.

There is no really harm in treating it as limited

Aren't you reducing Dynamic Range a little bit?

Yes, this what happens inside camera which debayers and save data as final limited range file.
This can have real effect (limited v full) for cameras which records internally as 8bit only (then you have bit more useful data for full range files).

With RAW it's rather different I would say. 12bit precision and fact that end result goes directly to 32bit float data means there is no place for full v limited. Even if data would be going to e.g. 16bit integer format as limited range then it would still have no real world side effect.

What's happening there is that your full range footage gets clamped to 16-235 (64-940) on import (Auto>'Video' levels) and then on export (Auto>'Full' levels) that clamped range is expanded out (proportionately) to 0-255 (0-1023) range - hence the increased contrast.

I don't think that's quite it. Cineform .avi delivery in R14, set at "auto", remaps *all* video footage, including Prores HQ, with blacks getting crushed and highlights clipped. Last I checked, Cineform .mov exports are correct, at "auto".

I think we're saying the same thing, aren't we? Just checked this through with a full range (0-255) greyscale gradient (8-bit DNxHD), imported into DR14.2 at 'video' data levels and exported to Cineform.avi and mov at Auto, Video and Full data levels. Then examined the YUV luma profiles of the exports using the AVISynth Histogram filter.

Cineform.avi
Auto levels - clamped 16-235 mapped out to 0-255 (i.e. clamped and crushed)
Video levels - clamped 16-235
Full levels - clamped 16-235 mapped out to 0-255

Cineform.mov
Auto levels - clamped 16-235
Video levels - clamped 16-235
Full levels - clamped 16-235 mapped out to 0-255

Which is consistent with:

For some reason, Resolve isn't exporting Cineform AVI properly. It's adding contrast that shouldn't be there. In comparison, Resolve is exporting Cineform MOV correctly.

Set your data levels at "video" (don't leave it at "auto"). Looks to be a bug, auto shouldn't be defaulting to "full".

If you want to process and export at full range you should set the Data Levels in the Clip Attributes and Export Video>Advanced Settings to 'Full' to assert that interpretation.

Thanks, Bryan.

How does that work, exactly? Changing the Clip Attributes doesn't result in any observable difference.

I'm a bit confused now. I was responding there to your comment:

The footage was shot on the GH4 in full range (0-255). Why is Resolve treating it internally as 16-235?

Because Resolve doesn't recognize ('auto' interpret) this footage as being full range and defaults to 'Video' levels i.e. clamps full 0-255 range to (limited, broadcast safe) 16-235 range (or 0-1023 to 64-940 in 10-bit scale). If you want to process and export at full range you should set the Data Levels in the Clip Attributes and Export Video>Advanced Settings to 'Full' to assert that interpretation.

I find it hard to believe that changing the data levels interpretation in the Clip Attributes made no difference unless the input was not the original GH4 clip and had somehow got constrained to limited 16-235 range on transcoding or was maybe shot in log. Or were you just referring to CinemaDNG footage specifically, as per your subsequent comment:

Auto, Video and Full setting in Clip Attributes all look identical for a CinemaDNG (Pocket) clip. No difference is observable when changing that setting.

If so, what did happen with your full range GH4 footage when you changed the data level interpretation in Clip Attributes i.e. did the timeline scope profiles at Auto levels align with 'Full' or 'Video' levels - I would assume 'Video' levels based on your comment:

Why is Resolve treating it internally as 16-235?

And was this the original GH4 footage or a transcode ?