VideoHelp Forum
+ Reply to Thread
Results 1 to 14 of 14
Thread
  1. Hello All,
    A semi-newbie here (warning, this post will likely be sort of long...I've been at this stuff all day, so my sanity at this point is questionable), trying to get into some more advanced video encoding. I recently discovered the "truth" about MainConcept/Premiere Pro's H.264 encoder, which is just the fact that it's not the best option for exporting H.264, and so began researching the alternatives.
    To make a long story short, I want to get a short (5 min.) sequence exported using x264 (the best alternative, it seems) from Premiere, for Vimeo/YouTube upload and festival submissions.
    So far I've tried quite a few things with no positive results, namely, exporting an uncompressed MOV using the YUV codec (from AME) and then re-encoding through HandBrake with x264, which just crashed. Because of the fact that I'm on a Mac, I haven't found a way to make that intermediate uncompressed file an AVI or any of the other, better (or so it seems), uncompressed formats like Lagarith, HuffYuv or UT. PPro/AME have so many uncompressed QT codecs (Animation, DNxHD (?), Graphics, PNG, TIFF, None...to name a few, I think) that I have no idea which would be best.
    I'd love to use something like FrameServer, but, again, Mac.
    I tried, but using x264 in the command line or in some of its other (stranger) forms, as well as tools like ffmpeg, AviDemux, AviSynth and such are over my head. Of course, I'd love to/am willing to learn anything necessary, but I'm not sure if it's exactly worth it, and I'd need a guide starting from the very basics.
    Any links, tips, ideas, etc. greatly appreciated!
    I've been reading forum post here and everywhere else all day trying to get my head around this stuff, but since so far I've managed nothing, I resorted to posting...which means that I'm fully aware of the fact that there are lots of other threads on this, and that I'm sorry if starting a new one was redundant. (I just need personal help, please! )
    Thanks a ton!

    Unreel
    Last edited by Realm of the Unreel; 28th Dec 2014 at 16:37. Reason: Clarity
    Quote Quote  
  2. You can export prores hq 422 in mov , then use handbrake or hybrid

    Try a more recent handbrake build or nightly build. Or hybid which is updated more often

    If you're going to be doing this frequently, you might even consider x264pro ($), which is a plugin for Adobe to export x264 directly
    Quote Quote  
  3. My understanding is ProRes isn't lossless, but you think it should be good enough for the jump?
    I've got the latest official version of HB so I'll see how that goes with the ProRes.
    $$ aside (I'd never be able to afford x264pro – looked at it already, thanks) some people were also saying that it didn't seem to be as good as the original x264?
    Thanks for the quick reply!
    Quote Quote  
  4. Prores HQ isn't lossless, but it will be more than good enough for youtube/vimeo or festival submissions



    In what way wasn' t x264pro as "good" ?

    If you use the same x264 library revision, you should get the same results .eg. if you use x264.exe or ffmpeg libx264 - if they are based on the same revision you will get the same results, provided you're not doing other filtering or operations (just the encoding)



    You got to be careful about what you believe or read, or at least examine the methodology on how they came to their conclusions

    For example, even that article you linked to above, it posts 1 screenshot. Is that proof? Hell no. The author doesn't say what type of frame e.g .is it a b-frame vs. i-frame comparison ?, and it's a jpeg (lossy). I have no doubt that AME is terrible for h264 encoding (it is), but there are proper scientific ways of testing and proof, and there are "bad" ways for trying to support your assertions. 1 screenshot doesn't "prove" or "disprove" anything
    Quote Quote  
  5. For sure, the article is very flawed. The author and the guy pointing out the issue both seemed rather un/misinformed and it's all very sensationalist (as the comments point out) but I just referenced it because I wasn't aware of the issue before reading the article — I'm no expert on compression myself and only would have discovered how bad AME is because of something similar to the original guy. That said, I then went on to do quite a bit of research besides, where I verified the original statements and discovered the x264 option.
    I understand the way x264 works in that it should always give the same results, but I was referring to a thread at the Adobe Forums I'm sure you've seen (https://forums.adobe.com/message/6791439#6791439). That thread, of course, shows much of the same errors in its methodology as the one's you were pointing out in the article, and I referenced it more as an off-hand comment or point of interest than as an absolute truth (hence the question mark in that sentence).

    All that aside, I've got the ProRes exporting already, so we'll just have to see how that goes! Thanks again.
    Quote Quote  
  6. Originally Posted by Realm of the Unreel View Post
    For sure, the article is very flawed. The author and the guy pointing out the issue both seemed rather un/misinformed and it's all very sensationalist (as the comments point out) but I just referenced it because I wasn't aware of the issue before reading the article — I'm no expert on compression myself and only would have discovered how bad AME is because of something similar to the original guy. That said, I then went on to do quite a bit of research besides, where I verified the original statements and discovered the x264 option.
    I understand the way x264 works in that it should always give the same results, but I was referring to a thread at the Adobe Forums I'm sure you've seen (https://forums.adobe.com/message/6791439#6791439). That thread, of course, shows much of the same errors in its methodology as the one's you were pointing out in the article, and I referenced it more as an off-hand comment or point of interest than as an absolute truth (hence the question mark in that sentence).

    All that aside, I've got the ProRes exporting already, so we'll just have to see how that goes! Thanks again.

    Did it work ok for you?



    No , I didn't see that thread. Thanks.

    Interesting that 3am Digital Studios author didn't reply for over a month... Doesn't look so good...

    I didn't purchase the plugin, but I'll have a look at the video files in the last post
    Quote Quote  
  7. I looked at the samples in the last post in the Adobe thread.

    I'll reply here, but it should be 3am Digital Studio's responsibility to reply to the Adobe thread.



    Yes there are some quality issues with the x264pro encode. But to be fair , they didn't use apples to apples same settings

    The x264 (CLI) encode (slow) uses 5 reference frames, unrestricted VBV, 2 passes

    The x264pro encode (slow) uses 4 refrence frames, --vbv maxrate 12000, --vbv-bufsize 30000, 1 pass ABR, with --psy-rd 1:0.15

    The biggest deterioration in visual quality to the naked eye is in the intro section with the sparkling graphics. It requires a lot of bitrate to encode that type of content because there are a lot of changes between frames . Recall the temporal compression (Long GOP compression) stores the differences between frames . Lots of change, means lots of bitrate required. The VBV restriction is the main cause of that deterioration, although 2 passes vs 1 pass plays a role as well. A larger maxrate will allow more bitrate to enter the buffer, or a larger buffer would have allowed larger allocation to where it was needed. Right now the maxrate is set to 12000kbps, so x264pro will only allow 12000kb and any given second to enter the buffer. The requested amount for an unrestricted encode is much larger. If you look at the bitrate graph for the unrestricted encode, it's well over 12000 for that entire intro period. When using VBV, x264 won't let you empty the buffer (buffer underrun), so it allocates less bitrate to that section. Compare the bitrate graphs below (open them in different tabs and flip back & forth) and look at the "fullness" of that beginning period . VBV settings should only be used if there was a specified reason like a target device. I don't know if the x264pro GUI allows you to adjust these types of VBV or advanced settings, or what the actual target was for this particular test

    psy-rd and psy-trellis will tend to make edges and encodes noisier, unless you have adequate bitrate. So that combination of higher psy-trellis along with low relative bitrate allocation in that section will cause quality problems

    "x264 (Slow) = 59 sek.mp4"
    Click image for larger version

Name:	x264slow.png
Views:	726
Size:	17.3 KB
ID:	29357

    "x264 PRO (Slow) = 53 sek.mp4"
    Click image for larger version

Name:	x264pro.png
Views:	734
Size:	17.7 KB
ID:	29358
    Quote Quote  
  8. First off, thanks so much to you, poisondeathray, for all the help…really incredible!
    The results I've been getting with x264 totally just blow MainConcept's stuff out of the water, it's insane. Lots of pics below for everyone to see for themselves.
    Settings for both (tried to match as closely as possible)...
    Premiere: VBR 2 pass, avg target bitrate 8000 kbps, max 50000 kbps, 1080p 23.976fps. Final size: 328 MB
    HandBrake x264: VBR 2 pass, avg 8000, preset veryslow, tune film, profile/level auto, 1080p 23.976 constant framerate. Final size: 326.8 MB

    Only minus I saw was some strange artifacts in Quicktime X, I'll post a screen shot below.

    But first, the comparisons:
    Test 1
    Master (straight from Premiere sequence)
    Click image for larger version

Name:	Export Comparisons3.Master.png
Views:	845
Size:	1.57 MB
ID:	29367
    ProRes (just in case, for reference)
    Click image for larger version

Name:	Export Comparisons3.ProRes.png
Views:	923
Size:	1.56 MB
ID:	29360
    MainConcept
    Click image for larger version

Name:	Export Comparisons3.MCH.264.png
Views:	883
Size:	985.7 KB
ID:	29362
    x264
    Click image for larger version

Name:	Export Comparisons3.HBx264.png
Views:	847
Size:	1.36 MB
ID:	29364

    TEST 2
    Master
    Click image for larger version

Name:	Export Comparisons2.Master.png
Views:	895
Size:	3.72 MB
ID:	29365
    MainConcept
    Click image for larger version

Name:	Export Comparisons2.MCH.264.png
Views:	832
Size:	2.88 MB
ID:	29359
    x264
    Click image for larger version

Name:	Export Comparisons2.HBx264.png
Views:	812
Size:	3.16 MB
ID:	29363


    Quicktime issues:
    Click image for larger version

Name:	Screen shot 2014-12-28 at 10.52.27 PM.png
Views:	660
Size:	2.39 MB
ID:	29366


    Honestly, I can't really say that I got all of what you're talking about x264pro, but thanks for explaining it all and going into detail. Hopefully someday I'll be able to reply with something more semi-intelligent than this! That being said, well, for now this workflow will do it for me (ProRes>HB x254), and though x264pro looks really comfortable and nice, for that kind of money and considering some doubts that still need further testing (with more matched settings, as you were saying) I think it's safe to say that the long route will do. It would be nice if 3am replied adequately to that thread, at this point it leaves (people like) me with a lingering doubt about the developer and his/her product. The fact that the images look rather radically different and that he/she never responded is unnerving, to say the least, and your analysis, while perhaps overly-technical for the basic users, certainly helps settle some of the dust. Anyways, at this point I'm just blabbering on pointlessly.
    Thanks so much, again, for everything! I've learned a lot and will be sure to keep researching and hopefully expanding my knowledge on all these technicalities of digital video. At least I know there's always somewhere I can go if I need help!
    Thanks (and a happy new year)

    Unreel
    Last edited by Realm of the Unreel; 29th Dec 2014 at 22:04.
    Quote Quote  
  9. 1) Double check with your festival submission guidelines - usually there are some restrictions or required formats that they stipulate. So you might need different versions for different festivals or youtube/vimeo

    2) Quicktime - QTX is an improvement over QT7, but still has problems .

    2a) If you need QTX compatibility, see this
    http://mewiki.project357.com/wiki/X264_Encoding_Suggestions#QuickTime_Player_X_compatibility

    Basically, since you used --preset veryslow, that automatically bumps up the reference frames and bframes to 8. Which is a problem in quicktime. You need to use --ref 4 --bframes 3 to ensure QTX compatibility

    2b) If you need QT7 compabitility, see this
    http://mewiki.project357.com/wiki/X264_Encoding_Suggestions#QuickTime_Player_7.7_compatibility

    Basically same as above, but also add --qpmin 4

    I haven't used handbrake in a while, but I think it has some QT compatibility presets ?

    3) Hopefully 3am Digital Studios is just on vacation and isn't ill or something bad happened ...


    And thanks for sharing your results! Good luck with the festivals! and Happy New Year to you too
    Last edited by poisondeathray; 29th Dec 2014 at 22:15.
    Quote Quote  
  10. So basically to ensure more universal support, I should leave my preset at medium? This should be more than good enough with quality, while not having any issues playing. Or, I can stick to the veryslow preset just changing the number of ref and b frames. Which route would you recommend?

    Hopefully nothing bad, for sure. It is strange that 3am Digital Studios never replied to that last comment

    Thanks for the good wishes! Don't worry about my last question, I think I can figure it out by myself
    Quote Quote  
  11. Define "universal support" ? Because those encoding settings will make the file not play natively without 3rd party software or mods on early gen devices like early gen Apple TV, early gen ipads, early gen iphones, early androids, etc... Basically, devices have limited power, and can only decode a certain subset of encoding options. They also need certain restrictions like VBV. Just the --preset setting alone doesn't include those switches like VBV

    There is no 1 setting that covers everything, every device, every target . And you don't want it to. You don't want to have to "dumb down" your high quality encode across the board. You custom tailor your versions for the device/target(s) that you have in mind

    "veryslow" does more than just adjust the bframes and reference frames . This is what it does over the "medium" preset:

    Code:
    - veryslow:
                                        --b-adapt 2 --bframes 8 --direct auto
                                        --me umh --merange 24 --partitions all
                                        --ref 16 --subme 10 --trellis 2
                                        --rc-lookahead 60
    IMO, "veryslow" isn't worth the time investment, unless you were encoding very very low bitrates (relative to content complexity). There are large diminishing returns with respect to quality vs. time when using the slower presets. I guess if you have time to spare it doesn't hurt (except the trees.... j/k )

    But seriously, if you only need this to play on QT7/X , just add those commandline options --ref 4 --bframes 3 --qpmin 4
    Last edited by poisondeathray; 29th Dec 2014 at 22:47.
    Quote Quote  
  12. I recently discovered Premiere's incredibly bad H264 output quality. x264 Pro for Premiere is ridiculously high-priced, so I can only offer you a cheaper and easy Windows solution: Pegays TMPGEnc Movie Plug-in AVC for Premiere Pro, which seems far more configurable than x264 Pro for Mac and blows Premiere's H264 out of the water.
    Quote Quote  
  13. Originally Posted by Greathelp View Post
    I recently discovered Premiere's incredibly bad H264 output quality. x264 Pro for Premiere is ridiculously high-priced, so I can only offer you a cheaper and easy Windows solution: Pegays TMPGEnc Movie Plug-in AVC for Premiere Pro, which seems far more configurable than x264 Pro for Mac and blows Premiere's H264 out of the water.
    Interesting but as you note, it is PC only, and on the PC side you can export directly using the (free) x.264 vfw codec.
    Last edited by smrpix; 20th Apr 2015 at 10:45.
    Quote Quote  
  14. Banned
    Join Date
    Oct 2014
    Location
    Northern California
    Search PM
    Originally Posted by Realm of the Unreel View Post
    Hello All,
    A semi-newbie here (warning, this post will likely be sort of long...I've been at this stuff all day, so my sanity at this point is questionable), trying to get into some more advanced video encoding. I recently discovered the "truth" about MainConcept/Premiere Pro's H.264 encoder, which is just the fact that it's not the best option for exporting H.264, and so began researching the alternatives.
    So you spend all that time looking at the differences while you render the 1080/24p video at a measly 8Mb/s?

    Why o why?
    Quote Quote  
Visit our sponsor! Try DVDFab and backup Blu-rays!