Im actually using "x264-params" and "x265-params" internally and relabeled the UI elements to that names. I see this as a temporary possiblity to test parameters as the UI elements for these parameters are still missing. Premiere limits this field to 255 characters so this is not even the right way to day with complex parameter configurations.
Maybe later we can have an interface / custom dialog in which you can enter command line options.
I made a new build as some users were having problems with that last debug build:
Edit: Have a lot of x264 parameters added to the GUI (incl. blu-ray relevant ones)
Our website is made possible by displaying online advertisements to our visitors.
Please consider supporting us by disabling your ad blocker or buy PlayOn and record Netflix! :)
Please consider supporting us by disabling your ad blocker or buy PlayOn and record Netflix! :)
+ Reply to Thread
Results 31 to 58 of 58
Last edited by Vouk; 20th Oct 2017 at 16:01.
This is fantastic, just what i was looking for. Hoping for a textbox to paste in x264/x265 settings from megui/staxrip so that i can just use this instead, would save a lot of time.
Youtube added support for uploading h265 files in April 2017 btw so this new x265 support will save a lot of upload time due to smaller filesizes. Vimeo added support a lot earlier.
doublepost, please delete.
It's nice to hear you like what i am working on. It seems this command line interface / parser is really important to some people. I still need to think about a good way to implement this feature. A simple textbox does not work. Maybe i need to solve this just like MeGUI configuration dialog. I am open for any ideas / suggestions.
There is a new release:
* All CPU cores should be used now
* General speed optimizations
* x264: Profiles high422 and high444 supported
* x264: Lossless works
* x265: Subsamplings 420,422,444 in 8, 10 and 12 bit added
* prores_ks: All options added
* prores_ks: Extreme speed improvements
Thanks for the continued development
x265/hevc lossless seems to have issues on export. I tested 8bit422 configuration (I chose this because 8bit422 uncompressed with fourcc UYVY is one of the "special" formats that PP can import/export losslessly without any conversions colorspace or otherwise - so it's easy to verify against) . There appear to be some additional processing , almost like a gross/large dithering pattern but only on certain colors. Difference testing reveals it so its easier to see. Not sure if this is pre plugin, plugin issue, or some libav implementation of libx265 issue. Let me know if you want more detailed info or samples
This isn't something specific to the plugin, but just an FYI that x264 lossless IMports are not handled correctly in premiere pro, it's a decoding issue. (At least they are decoded in 2017 now, but there is some loss or deviation from a lossless decode through libavcodec) .
I think there might be some x264 lossless issues as well, but I'll do some more tests and report back
I noticed FFV1 was removed for now? I recall that it had problems in some of the earlier versions
but this should be done after you have already exported and archived a lossless master not instead.
That said, I've fine with Adobe Media Encoder in CS4. Does that still exist on the new CC versions? You all are acting like H.264 export is something extraordinary. Did I miss something? I do find the x264 love to be a bit hype-ish, always have.
If the dev wants to go into x264/etc, I'm for it.
@poisondeathray: That's the kind of technical feedback i need! Thanks.
Can you give me some steps on how to reproduce this? I did not find any information at all about the different Adobe pixel formats.
Yes, there is some processing:
yuv420 is available as a planar format and so i can just pass it 1:1 from premiere to ffmpeg -> no problems
all other formats are packed formats and it was really difficult to get the somehow into ffmpeg... everything is planar there and it seems the pixelformats are somehow different there. I only got pink or green scrambled pictures. I converted packed to planar (not that difficult), swapped components YUVA > VUYA, it still didn't work. I assume it has something to do with the bit structure inside a component/pixel block.
What i finally did was getting all data as 32bit float values and calculated 16bit integers out of it (using YUV scaling factors). The 16bit will be converted to the target pixel format using swscale. Maybe thats also the reason why its slow. I really need some information on how to do this right.
It is basically working, but only on 1 CPU core. At this moment i could enable *any* codec of FFMpeg, but i want the color conversion working right first.
@lordsmurf: What about ProRes? And there is so much more ...
Last edited by _Al_; 8th Dec 2017 at 16:48.
First Some BG info . I apologize if you know this already.
Adobe PP doesn't treat "lossless" YUV codecs as lossless, because they get converted to RGB. This is on the decoding side . 2 formats that get complete passthrough; treated as truly lossless for INPUT/OUTPUT are UYVY for 8bit 422 and v210 for 10bit422 . Not all "uncompressed" formats get passthrough. For example packed YUY2 is also 8bit422 but packed and gets RGB treatment . YV16 is planar 8bit422 but gets RGB treatment as well. There are differences between packed vs planar, and how they are stored. A list of some more common fourcc's
Since UYVY and v210 are verifed to pass through, they are good to test against. You can make various patterns or test depending on what you want to look at. I attached a simple UYVY color bars test, and the output of PP using UYVY , and the difference testing visulization. If you can encode with x265 (or anything) and decode it to the equivalent, then it's verified lossless (at least on that limited test) . But if you look at the patterns on the amplifed diff, they look almost like dithering patterns (from bit depth conversion), but it's not a standard pattern that I've seen before (I've tested quite a few in the past)
You can validate "lossless(ness)" test with many methods. Difference testing/ amplified differences, PSNR, SSIM . I like amplified difference testing because you can "see" where the problem areas are. For example if somewhere it was using nearest neighbor to upsample 422 to 444, you could see this easily on the edges of pattern. If you have many tests, and just want quick verification you can batch SSIM or PSNR with ffmpeg for example.
No completely sure on this but AFAIK , premiere's preferred pixel format is AYUV422 (you can drop the alpha) . One of the plugin developers for x264pro dropped by a long time ago to discuss this info when developing that plugin, he would know the details on the Premiere timeline side of things and how a plugin requests certain pixel formats. But some info is in older threads on this board; I'll try to find them. So the timeline mostly works in YUV422 with YUV assets . I know older versions were actually able to pass through fourcc "IYUV" as 4:2:0 (much like UYVY and v210 get "special" treatment, but "YV12" which is planar 4:2:0 did not get special treatment) , but I cannot replicate this with newer versions - it looks like they changed some handling . Because 4:2:0 passthrough would be VERY nice to have.
In theory packed/planar all the fourcc's should all be interconvertable losslessly (actually ffmpeg, avisynth, vapoursynth can losslessly convert some of them). But in reality, not all programs treat them the same. In most Windows NLE's , most get converted to RGB with the exception of a few like UYVY. (ie. 8bit 4:2:2 as fourcc UYVY arrangement should be able to be converted to something like 2VUY or YUY2 or any of the dozens of other arrangements. ie. 8bit422 should effectively be 8bit422 , the only difference are in how they are stored and arranged)
Thanks for all the info. It was really, really useful and i started fixed some of this already. I also got a good book donated recently "Digital Video and HD" by Charles Poynton. It might give me even more insight and understanding on this topic.
I just did a new release 0.5.1 of the plugin:
- It uses multithreaded push export now, so it finally uses the full power of all cpu cores
- I am not quite sure if the lossless encoding is fixed. I did not see such artifacts as mentioned above (ffmpeg -y -i z:\test.mp4 -i z:\Raw.avi -filter_complex "blend=all_mode=difference" z:\comp.mp4) anymore
@poisondeathray: Could you share your ffmpeg command line to create the difference images with me?
Can you clarify what you want?
I use ffmpeg for psnr and ssim; not "images" for visualization . psnr and ssim are just "numbers", but you can check per-frame values easily and use plotting software to make graphs
For visualization, I usually use avisynth or vapoursynth to "see" the differences
Another method for visualization is in after effects with "difference" layer mode . You can amplify differences by adding an adjustment layer with the levels effect, gamma value set higher
If want to see the difference between 2 videos you can use this:
With it you can see the difference between a source video and an encoded video and it helps in determining encoded quality.
He already posted that in post #42
For visualization - is it's nice to have a GUI to navigate frames and zoom in/out to "see" the actual differences and problems. ffmpeg/ffplay aren't really "GUIs" . If you just want to know if it's the same or different, usually PSNR or SSIM is good enough, there is no need to "visualize" anything.
I usually use avspmod for this because you can use the arrow keys to navigate, slider to seek, zoom in/out, and use the number keys to swap shots (e.g. if you load video1, video2, difference, amp difference in separate tabs, it makes comparing them easily because they are aligned on the same frame). This makes diagnosing problem areas much more convenient . e.g. what if you see a problem on the diff but wanted to see video1 or video2 how they really look ? well it's right there just push the key to toggle the tab and it's aligned right on the same spot . You can't really do that with ffmpeg/ffplay
On some videos where there are tiny, tiny differences , you won't be able to "see" differences at all unless you amplify the differences. You can do this easily in the script. For the ffmpeg/ffmpeg visualization, I guess you can chain a levels filter after the difference
There are little "gotchas" , such as frame alignment . When you jump around and do non linear seeks with ffmpeg with long-gop formats, you can "lose your place" . And the result will be off because you're actually comparing 2 different frames . In avisynth, if you use an indexed source filter, it's always aligned
@vouk - I'm still getting differences . What settings did you use for "lossless" ? What input file did you use to test ? Was it the "UYVY_INPUT.avi" I uploaded above ? If so, can you upload your export ?
I fixed a few bugs and checked the mediainfo of the export. In 0.5.1 x265 with the setting "lossless"exports actually as crf=23. Now it looks like this:
Format : HEVC Format/Info : High Efficiency Video Coding Format profile : @L8.5@Main Codec ID : hev1 Codec ID/Info : High Efficiency Video Coding Bit rate : 4 914 kb/s Width : 1 920 pixels Height : 1 080 pixels Display aspect ratio : 16:9 Frame rate : 23.976 (24000/1001) FPS Color space : YUV Chroma subsampling : 4:2:2 Bit depth : 8 bits Bits/(Pixel*Frame) : 0.099 Stream size : 25.0 KiB (69%) Writing library : x265 2.6+8-g33ca535:[Windows][MSVC 1911][64 bit] 8bit+10bit+12bit Encoding settings : cpuid=1173503 / frame-threads=2 / numa-pools=4 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=2 / input-res=1920x1080 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-reuse-mode=0 / lossless / cbqpoffs=0 / crqpoffs=0 / rc=cqp / qp=4 / ipratio=1.40 / pbratio=1.30 / aq-mode=0 / aq-strength=0.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=64 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-mv-type=0 / copy-pic=1 Color range : Limited Color primaries : BT.709 Transfer characteristics : BT.709 Matrix coefficients : BT.709
Unfortunately my ffmpeg does not like to work with single frame videos (at least not when i tried): ffmpeg -y -i z:\x265.mp4 -i z:\uyvy_input.avi -filter_complex "ssim" z:\comp2.mp4
Yes, the crf23. Did you enter qp4 manually? I guess --lossless wasn't passed before?
Yes, that sample is confirmed lossless (by other methods as well) . I'll do some more testing on other patterns/sample later
Nice to have a truly lossless compression alternative to UYVY 8bit422
"x265_classic.mp4" is not.
The loss pattern suggests horizontal chroma resizing at some point
You can actually "see" this with naked eye without any special tests. Look adjacent to vertical lines, they are not as sharp, they will be slight "blurring"
I recently searched for NLEs that support x264 export or that have plugins available for them that can do this. I found this thread via Google and it looks very promising. Since I currently don't use Premiere Pro myself and therefore can't test it, some small questions:
1) Are there any major feature or speed differences between your plugin and other ones? I'm assuming the quality is the same since all use x264, correct? I'm mostly interested in CRF encoding of 1080p content. Other plugins I've found are "x264 PRO" and "TMPGEnc Movie Plug-in AVC for Premiere Pro".
2) How are updates of x264 and other encoders handled? Right now it looks like everything is compiled into the plugin. I'm asking because I've read that other plugins update very rarely and therefore mostly use old encoder versions. Is there any chance to have external encoders so that they can be updated separately?
3) Do you have plans to support other NLEs too? I'm especially interested in Vegas Pro since that's the one I'm using right now.
1) The original idea for this plugin was to get rid of PPro + Frameserver + Encoder and have a better way to use x264 with CRF for content creators. It uses static built FFMpeg libs inside so it will most likely have the similar speed. The 8bit mode is pretty much optimized already. Another big improvement is that you can queue projects with Media Encoder.
2) I wanted to have it as easy as possible, all you need is (inside) the Voukoder.prm file. An external FFMpeg version will not be supported. I am doing alot of releases at he moment and building a new FFMpeg version is not a problem. But honestly speaking: I did not encounter big performance improvements with any lib update. After all ... i plan to have a fixed release cycle.
3) Many people asked me for a Vegas version and I have made some preparations for Vegas already. But i did not find the right SDK for an exporter plugin yet. I only found an SDK for effects (openFX). Vegas is on my list, but not short term. And then ... i also need a vegas license.
I've also used the Frameserver method before (with Vegas Pro), therefore I can fully agree that an easy CRF export (with as many encoder settings as possible) is the best feature any x264 (or x265) export plugin can provide. My question about the speed was just because I saw multiple speed related notes in your release notes and therefore though you might have compared your plugin with the other available ones.
On the official site there are downloads for script and extension programming, but as far as I can tell those are only simple GUI scripts/extensions. Render extensions like the one from Frameserver seem to use "libFileIO" as written in the Frameserver Git repository readme. The download link there doesn't work any more, but I've found something in the Frameserver Google group:
You will need the "File I/O plugin SDK" from Sony. This is not publicly available for download and you will have to contact them via the Sony Vegas forums and ask about it, sign an NDA etc. before you get a copy.
The speed related notes were about the plugin itself, making its internal processing as performant as possible.
An interesting fact is i will most likely have NVENC h264/h265 included with the next release (unfortunately this has no CRF, but at least CQP) and premieres rendering is too slow to use the full potential of a hardware encoder. With 280fps HEVC encoding speed the GPU encoder is at 50%. Really crazy.
I have sent an email to Magix (the new owner of vegas) to get access to that SDK. No response so far.
Could it be possible by any chance that we can have an option to have the output file just copied and not re-encoded (Direct stream copy)
in case we are just doing some cuts from a video file? This would be a great option as is missing for now in premiere and many asking for it
on adobe forums.
That is not how Premiere exporters work. In the plugin i have to create a video renderer and get the already decoded pixels only. I don't know if there is a way to get encoded frames. Probably not.