New free x264 plugin for premiere

[Vouk]

Looking for testers! I am currently developing a plugin for premiere (both pro and elements) that uses x264 for encoding. It is also working as Media Encoder plugin so you can do all the batch encoding and stuff like that w/o the need of MeGUI (or other). It is based on LIBAV and can theoretically support any codec that is supported by LIBAV in the future.

The best thing: it is open source and free.

https://github.com/Vouk/voukoder/releases/

So i would really appreciate it if you would help me with testing and provide some feedback.

[poisondeathray]

Thanks.


Some quick tests/observations

1) issue with YUV/RGB conversions 601/709 mismatch, maybe expose option to control the YUV<=>RGB matrix 601/709/2020, and option to tag --colormatrix , --transfer, --colorprim within x264

2) issue with framerate . seems to be some jitter in timecodes. e.g. 29.97 project (or 30000/1001) was exported as 30.048

3) suggest options for more control, exposing some of libav/ffmpeg/ libx264

-perhaps more options for container support such as mp4, ts . mkv still is not supported as well, and especially not on "professional" applications and scenarios

-so far exported as 422 only, but 420 far more common for end delivery, so more support for output options, and the actual conversion(s)

-maybe expose some more advanced settings in libx264, things beyond presets and tunings . Even a commandline box for advanced users would be appreciated

[Vouk]

Thanks for your feedback.

1) I really need to look into this and find out how to configure this in my filter graph. with swscaler this was easy, but i changed it to use a filter graph instead.
2) I experienced this too and noticed the timeline in VLC is sometimes not in sync with the video. I did not find the issue yet though.
3) More options will come as soon as the base system is working properly. Theoretically i can make all muxers and encoders of libav available to premiere.
- mp4 can be selected in the multiplexers tab already (just like mov), mkv is wanted by youtubers most and supports most codec combinations
- yuv422 is hardcoded at the moment but is on my agenda
- i will add more/all options once the base system is working

Currently i get the frames from premiere as RGBA and convert it to the target format using libav. Also something i need to look into and maybe change this.

Edit:

Changed yuv422 to yuv420. This is correct for baseline, main and high profiles.
Interestingly setting it to yuv420 fixed also the framerate issue. The timeline is also in sync now.

[poisondeathray]

Is the only option from premiere RGBA ? even from a YUV timeline ? Are there other options exposed in the Adobe/PP API ?

If RGBA only, the currently only way ffmpeg/libav to convert RGB to YUV is with swscale, and this uses Rec601 . This is ok for SD projects (which should use 601). But not for HD projects. It's not ideal, because this means 2 conversions, and more rounding errors/ quality loss, but the 3 "workarounds" are either a) -vf colormatrix, or b) -vf scale specifying in_color_matrix and out_color_matrix, or c) using -vf zscale . Also a switch must be included for interlaced vs. progressive colorspace conversion, otherwise the conversion will be incorrect (chroma errors).

[Vouk]

No, i will make the pixel format selectable in a dropdown box and default it to 420. Then no conversion is necessary. This might also speed up rendering the frame.

btw, as far as i know "-vf colormatrix" is only supported by ffmpeg not by libav. It is not in the documentation.

[Vouk]

Version 0.2.2

Changes
- Timecode issues seems to be solved with changing output entirely to 4:2:0. Need to watch this though.
- Added version number to plugin name
- Changed output to YUV 4:2:0 which is correct for all supported encoder profiles
- Color space can be selected in a dropdown (Currently BT601 and BT709 only)
- Color range can be selected in a dropdown (Full and limited)
- X264 VUI flags will be set to color space and -range accordingly
- Exporting directly from Premiere as YUV 4:2:0, no RGBA conversion anymore

Issues
- Lossless export needs to be fixed later as lossless is only possible with 4:2:2 or 4:4:4

https://github.com/Vouk/voukoder/releases/tag/0.2.2

[poisondeathray]

Seems to be issue with 0.2.2 exporting

error compiling movie

unknown error

low level exception occurred in voukoder 0.2.2

I didn't have time to go into more detail yet , or what conditions might work / don't work but so far nothing gets export

[Vouk]

Please delete any existing Voukoder presets first. I added new parameters and they don't exist in these presets. I just tested it using my last day trial period in CC 2017. Exporting an interlaced DVCAM Avi and MagicYuv Avi worked.

[poisondeathray]

I didn't use any presets

It seems export is ok if timeline is in YUV with YUV assets

But if you use RGB asset (e.g. a PNG) or filter, that error pops up

So it suggests an issue with RGB=>YUV commnunication/conversion

[Vouk]

Sounds logical. I currently handle yuv420 pixel formats only. And it seems like each frame can be rendered in a different pixel format. I will look into this.
What about your previous observations, can you confirm they are fixed?

[poisondeathray]

yes they are fixed

a) the vui options seem not to written to metadata when sd box is checked . eg. sd project, sd export, 601 box checkmarked => but the export file doesn't show 601 in the metadata (when using something like mediainfo to check). But works ok with 709

b) I think it's along the same lines as the filter issue within PP - if you try to resize within the export dialog box (e.g. maybe a HD to SD project) , it will give the same error too (error compiling movie...)

[Vouk]

a) Fixed.

b) I can't reproduce it. I added a png to the timeline: worked. I added a bmp to a timeline: worked. I added a b/w filter to an existing DVCAM file and resized it to a quarter size: worked. Am i missing something?

[poisondeathray]

I can reproduce it on 2 different computers, 2 different premiere versions, CC2015 and CC2017

On a mixed media timeline - it seems to export YUV segments ok, but as soon as it encounters a segment with RGB or filter, the error pops up. For example if the YUV segment was first, it seems to work until it encounters the RGB segment then errors out. If the RGB segment was first, it aborts immediately with the error. So I still think it's related to colorspace/pixel format communication/conversion

[Vouk]

Ok, i only have Elements 15 here. It seems Elements and CC handle this differently, although i thought the underlying engine is the same.

Edit: I just signed up for the CC membership plan and will try to reproduce it later.


New release 0.2.3:

Fixes
- VUI flags are now set correctly for bt601
- Mixed YUV/RGB assets in a timeline do not cause an exception anymore

https://github.com/Vouk/voukoder/releases/tag/0.2.3

[poisondeathray]

601 VUI flags, and the rgb/yuv mixed timeline issue , filters etc... issues appear fixed in 0.2.3. Nice work

1) Interlaced encoding --tff not passed . eg. interlaced sequence, interlaced assets , upper field first set in the export settings, but x264 metadata says progressive. But the actual content is ok (interlaced TFF), just encoded as progressive instead of MBAFF TFF . Same with --bff for SD interlaced (content is ok, but encoded progressive)



2) framerate discrepancy issue with mkv muxer .
eg. 23.976 random youtube source, 23.976 sequence settings, 23.976 export settings - exports ok with MP4 , but as 24.0 FPS with mkv (according to mediainfo), and 24.42fps according to ffmpeg. Sort of related to the jitter in the timecodes again ,but I think it's container related. Elementary stream declared framerate is ok

MP4 (as read by ffmpeg)
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709)
, 1280x720, 1193 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 tbc (default)

MKV (as read by ffmpeg)
Stream #0:0: Video: h264 (High), yuv420p(tv, bt709, progressive), 1280x720,
SAR 1:1 DAR 16:9, 24.42 fps, 23.98 tbr, 1k tbn, 47.95 tbc


In ffmpeg, tbn is the timebase reported by container

I didn't detect any sync issues, but it was only on short samples so far

This framerate and timebase can be represented properly in mkv container, because remuxing original source with either ffmpeg or mkvmerge gives proper values (as read by mediainfo and ffmpeg)

[sophisticles]

Can I ask what the point of this is? There already exists an x264 export plugin for Premiere and although it's a paid for plugin, that is not the barrier to it being used because the cost of the plugin is negligible compared to the cost of Premiere.

The reason people don't use it is for the same reason that Adobe doesn't simply offer the option to export to x264 built into Premiere, there isn't any demand for it.

Premiere is a NLE, a "Non Linear Editor" NOT a "Non Linear Encoder". The purpose of a NLE is for you to add your assets, edit as needed, combine them into your final product and then export a mastering copy not a delivery copy. That's why all NLE's export to high quality lossless and intermediate formats but generally they don't do delivery formats, at least not that well.

If someone want to encode to x264 there are plenty of ways, via CLI or any number of the free GUI front-ends, but this should be done after you have already exported and archived a lossless master not instead.

I return you now to wasting your time.

[poisondeathray]

@sophisticles - I think many people will find it useful in various scenarios. Not every project is a major undertaking with high quality lossless or near lossless master. Sometimes you need a WIP preview in collaborative settings, or sometimes just something quick for youtube or friends.

Also , this eventually opens up other possible options through libav such has x265/vp9 / eventually VP10, AV1 etc...

[Vouk]

Also , this eventually opens up other possible options through libav such has x265/vp9 / eventually VP10, AV1 etc...

This is exactly my plan.

btw, interlaced issues are fixed, i will look into the mkv issues after work today.

https://github.com/Vouk/voukoder/releases/tag/0.2.4

[poisondeathray]

Confirmed interlaced issue fixed

@Vouk - Are 2pass , BD, VBV options on the development timeline ?

@sophi - libx264 can export lossless 8,10bit 420/422/444 and even RGB . ffv1 through libav can export 8-16bit lossless . These have long gop lossless options as well, so high compression, high bit depth lossless "masters". So they offer more intermediate and mastering options . More free/open source options are always appealing

[sophisticles]

@sophisticles - I think many people will find it useful in various scenarios. Not every project is a major undertaking with high quality lossless or near lossless master. Sometimes you need a WIP preview in collaborative settings, or sometimes just something quick for youtube or friends.

Also , this eventually opens up other possible options through libav such has x265/vp9 / eventually VP10, AV1 etc...

Premiere cost $240 per year per pc, I think that it's the wrong tool to be using for "something quick for youtube or friends".

In my way of thinking, if you're going to spend money on a monthly or annual subscription plan for a piece of software that you never actually own and can only use on a single system per license, then you should be using it for projects that generate income for you and that to me means exporting high quality lossless or near lossless masters for archiving.

[poisondeathray]

In my way of thinking, if you're going to spend money on a monthly or annual subscription plan for a piece of software that you never actually own and can only use on a single system per license, then you should be using it for projects that generate income for you and that to me means exporting high quality lossless or near lossless masters for archiving.

Sure, and this plugin has the potential to offer more lossless compression options, more lossless bit depth options, more options for mastering or high quality intermediates . See the post above I think we cross posted






One big selling point of the current "pro" plugin is BD support . So if vouk can implement 2pass, BD, VBV options, it basically makes that obsolete in terms of function. But I think the "pro" plugin comes with licensing, so there are commercial implications in that scenario

[Vouk]

@sophisticles: I did alot of youtube videos some time ago and spent alot of time in youtube content creators forums. These guys are doing one or even more videos a day and spending $20 / month is not a problem for most them. There is even "Elements" which is about $80 in total with the same plugin interface. So when doing videos so frequently the workflow needs to be fast and uncomplicated. They don't want to use Adobes / Mainconcepts H264 encoder as it does not support crf and x264 is known for its quality.

So how do these guys work?

Premiere > Frameserver > AviSynth -> MeGUI

I tried this and i found it horrible. You need to start that stuff in the right order, keep it running, can not abort rendering (frameserver crashes), can't do batch rendering and so on.

I asked myself "Can i do it better?" and that's how "Voukoder" was born. It is built that the x264 integration is defined by a big configuration file. So if i want to support x265 (or any other encoder) i just need to compile it in, create that configuration file and all Premiere UI elements and so on will be automatically created.

And it is never a waste of time as long as i can improve my programming skills and learn something.

I know the commercial plugin and it comes with licensing, support and all the other stuff important for a big production environment. And as i said, i want to go beyond supporting x264 only.


@poisondeathray: Once the plugin works decently, i will create something like an "advanced" tab and explose all x264 configuration options as UI elements. But maybe it is a good idea to create a text-field for additional custom options first. Then users can try and add settings without the gui elements.

I need to make changes for 2-pass rendering, but theoretically its possible.

[sophisticles]

@sophisticles: I did alot of youtube videos some time ago and spent alot of time in youtube content creators forums. These guys are doing one or even more videos a day and spending $20 / month is not a problem for most them. There is even "Elements" which is about $80 in total with the same plugin interface. So when doing videos so frequently the workflow needs to be fast and uncomplicated. They don't want to use Adobes / Mainconcepts H264 encoder as it does not support crf and x264 is known for its quality.

You seem to be ignoring one "minor" thing, google/youtube re-encodes everything you upload so it doesn't matter if "x264 is known for its quality".

If youtube is your goal, take a look at the guidelines for content uploaded:

https://support.google.com/youtube/answer/1722171?hl=en

Plus your reasoning is a bit odd, these people supposedly "do one or more videos a day and spending $20 / month is not a problem for most of them", are these people making any money from the uploads? Do they create their own content or repackage someone else's.

I just don't follow the logic, assuming that every single youtube uploader was using Premiere and didn't mind paying a monthly subscription fee to do so it still makes zero sense to want to use a 3rd party plug in instead of one of the built in encoders because youtube will re-encode the content anyway with options that are a purposely kept secret.

I see no reason to not export with the built in encoders with as much bitrate as you can and call it a day.

[poisondeathray]

You seem to be ignoring one "minor" thing, google/youtube re-encodes everything you upload so it doesn't matter if "x264 is known for its quality".

If youtube is your goal, take a look at the guidelines for content uploaded:

https://support.google.com/youtube/answer/1722171?hl=en

Plus your reasoning is a bit odd, these people supposedly "do one or more videos a day and spending $20 / month is not a problem for most of them", are these people making any money from the uploads? Do they create their own content or repackage someone else's.

I just don't follow the logic, assuming that every single youtube uploader was using Premiere and didn't mind paying a monthly subscription fee to do so it still makes zero sense to want to use a 3rd party plug in instead of one of the built in encoders because youtube will re-encode the content anyway with options that are a purposely kept secret.

I see no reason to not export with the built in encoders with as much bitrate as you can and call it a day.

What kind of logic is that ?

So you'd rather take longer to encode a lower quality product that is significantly larger in filesize , in order to waste more bandwidth to upload for a longer period of time ?

I could understand there might be some resistance if there was significant cost , or maybe the workflow was convoluted (like massive commandlines, or frameserving, or avisynth, or complex GUI's) , but this is a free, open source plugin, it's easy to install or uninstall. It's easy to use, fast, with no convoluted workflow



People are going to want to use the lossy version in those scenarios where they need good quality , decent filesize. People have been doing this for years for similar reasons going to great lengths with frameserving, avisynth, megui , others with handbrake... etc. The ends justified the means of jumping through all those hoops . This makes it easier.

Well maybe they don't have fibre connection and unlimited bandwidth caps. Maybe they want the slightly better compression or they can't waste so much time uploading. Maybe need low pings for co-op gameplay and can't multitask/simultaneous upload. Or maybe all their limited bandwidth was spent, etc...

For vimeo-ers with an account, it's often used to showcase demo reels and work, because the original can be downloaded. So the main theme again, is good quality, decent filesize

For corporate and professional websites , where you host and use the original, you're not going to want the bundled encoders

[hello_hello]

What kind of logic is that ?

It definitely wasn't his finest "x264 bashing" hour.

[sophisticles]

What kind of logic is that ?

It definitely wasn't his finest "x264 bashing" hour.

In what way was I "bashing" anything? I don't see why people would spend hundreds of dollars on a NLE, that they never own outright and then export their work to a lossy format instead of making a high quality lossless or near-lossless master.

The excuse offered was that it would aid those that upload videos to youtube, I pointed out that youtube will re-encode their uploads anyway so what's the point of exporting to a bit rate starved x264 encode instead of just using a one of the high bit rate built in options.

Based on their reasoning why not create a x265 plugin instead? Or am I just "x264 bashing" again?

[Vouk]

Geez, can we get back to topic ... please?

[Vouk]

I have an update:

https://github.com/Vouk/voukoder/releases/tag/0.3.0

Changes:
- Added custom arguments field
- Added x265 support (Proof of concept)

Custom arguments are supported in the format: option=value:option2=value:option3=value ...
options with no value need to have 1 as value (i.e. ssim=1, no-cabac=1)

The input field is limited to 255 characters.

(This release is a debug build and is slightly bigger in filesize)

[Cornucopia]

As there might be a number of users who want to use the custom arguments feature, but many of them are likely going to be doing copy+paste from some previous successful examples, I strongly suggest you keep the custom arguments format equal/identical to the original command-line format, including especially the use of specific values as defaults when not explicitly specified.
Of course this will complicate things WRT application of different codecs, as each would need to have their own formats & defaults. But otherwise you risk incompatibility and/or confusion.

Scott

[poisondeathray]

Pros/cons but I'm in the camp that think it's probably ok like that, because that's how libx264 does it for -x264opts or -x264-params for ffmpeg and libav. (and libx265 with -x265-params). And he's basing this off libav. Formatting/syntax for x264cli is slightly different, but it will be more consistent if he sticks with libav for everything