i7-9700K but extremely low performance enconding of FFMPEG/x264?

[amaipaipai]

Thank you for the info poisondeathray!

Today it's Christmas, I'm not working, lets poke around with ffmpeg, give it a second chance.

So we understood that x264 settings go inside "-x264opts", got it! Lets buid a script to handle it:

source.avs

FFvideoSource("2018-12-22 10-33-54.avi").Trim(120,3720)# 3720-120=3600, 1 minute cut

sample.bat

cd %~dp0
SET vsource=%1
SET x264opts=threads=9:no-interlaced:videoformat=component:range=pc
ffmpeg-32\bin\ffmpeg -y -i "%vsource%" -pix_fmt yuv422p -c:v libx264 -profile:v high422 -level:v 4.2 -g 33 -bf 2 -crf 19 -x264opts %x264opts% -flags +ildct+ilme -field_order progressive -an "%~n1-ff.h264"
:: just to check if everything goes ok.
pause

we run it with sample source.avs

Input #0, avisynth, from 'sample.avs':
  Duration: 00:01:00.02, start: 0.000000, bitrate: 0 kb/s
    Stream #0:0: Video: rawvideo (BGRA / 0x41524742), bgra, 1920x1080, 60 fps, 60 tbr, 60 tbn, 60 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
Press [q] to stop, [?] for help
[libx264 @ 07414100] bad option 'range': 'pc'
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
Conversion failed!

Okay?!
Back to documentation...
https://www.ffmpeg.org/ffmpeg-all.html#libx264_002c-libx264rgb

x264opts (N.A.)
Set any x264 option, see x264 --fullhelp for a list.

Argument is a list of key=value couples separated by ":". In filter and psy-rd options that use ":" as a separator themselves, use "," instead. They accept it as well since long ago but this is kept undocumented for some reason.

Okay.

x264 --fullhelp 2>&1 | findstr "\--range"
--range <string>        Specify color range ["auto"]

Still a valid option, lets see what the documentation for h264 encodings says about it:
https://trac.ffmpeg.org/wiki/Encode/H.264

And we get alread a big warning:

Warning: Do not use the option x264opts, as it will eventually be removed. Use x264-params instead.

So we have to change x264opts over x264-params:

cd %~dp0
SET vsource=%1
SET x264opts=threads=9:no-interlaced:videoformat=component:range=pc
ffmpeg-32\bin\ffmpeg -y -i "%vsource%" -pix_fmt yuv422p -c:v libx264 -profile:v high422 -level:v 4.2 -g 33 -bf 2 -crf 19 -x264-params %x264opts% -flags +ildct+ilme -field_order progressive -an "%~n1-ff.h264"
:: just to check if everything goes ok.
pause

Maybe it will work now... wrong:

[libx264 @ 06962f80] Error parsing option 'no-interlaced:range = pc'.
[libx264 @ 06962f80] interlace + weightp is not implemented
[libx264 @ 06962f80] interlaced (1) > level limit (0)

"no-interlaced" it's a valid option maybe ffmpeg accept only integers:

cd %~dp0
SET vsource=%1
SET x264opts=threads=9:interlaced=0:videoformat=component:range=pc
ffmpeg-32\bin\ffmpeg -y -i "%vsource%" -pix_fmt yuv422p -c:v libx264 -profile:v high422 -level:v 4.2 -g 33 -bf 2 -crf 19 -x264-params %x264opts% -flags +ildct+ilme -field_order progressive -an "%~n1-ff.h264"
:: just to check if everything goes ok.
pause

Maybe it's okay now... Wrong:

[libx264 @ 06962f80] Error parsing option 'range = pc'.

From x264 help, "--range" values are auto, tv and pc, maybe auto=0, tv=1 and pc=2... Wrong...

[libx264 @ 06504100] Error parsing option 'range = 2'.

Maybe the correct values are auto=1, tv=2 and pc=3? Wrong...

[libx264 @ 06504100] Error parsing option 'range = 3'.

Maybe the whole x264 options are not used, maybe it's something else, back to source code:
https://www.ffmpeg.org/doxygen/4.1/libx264_8c_source.html

Lets see what we can find related with pixel format 4:2:2 and color range, line 759:

x4->params.vui.b_fullrange = avctx->pix_fmt == AV_PIX_FMT_YUVJ420P ||
	avctx->pix_fmt == AV_PIX_FMT_YUVJ422P ||
	avctx->pix_fmt == AV_PIX_FMT_YUVJ444P ||
	avctx->color_range == AVCOL_RANGE_JPEG;

Looks like the parameter we are looking for is fullrange, lets try:

cd %~dp0
SET vsource=%1
SET x264opts=threads=9:interlaced=0:videoformat=component:fullrange=1
ffmpeg-32\bin\ffmpeg -y -i "%vsource%" -pix_fmt yuv422p -c:v libx264 -profile:v high422 -level:v 4.2 -g 33 -bf 2 -crf 19 -x264-params %x264opts% -flags +ildct+ilme -field_order progressive -an "%~n1-ff.h264"
:: just to check if everything goes ok.
pause

No!

[libx264 @ 066047c0] Error parsing option 'fullrange = 1'.

Maybe it doesn't need an option, maybe if we use just fullrange instead...

[libx264 @ 064b47c0] interlace + weightp is not implemented
[libx264 @ 064b47c0] interlaced (1) > level limit (0)

Wrong again! What interlaced? The source is progressive 60fps Mother

Maybe it's not an integer but a non-integer instead:

cd %~dp0
SET vsource=%1
SET x264opts=threads=9:interlaced=0:videoformat=component:fullrange=on
ffmpeg-32\bin\ffmpeg -y -i "%vsource%" -pix_fmt yuv422p -c:v libx264 -profile:v high422 -level:v 4.2 -g 33 -bf 2 -crf 19 -x264-params %x264opts% -flags +ildct+ilme -field_order progressive -an "%~n1-ff.h264"
:: just to check if everything goes ok.
pause

YES!

Input #0, avisynth, from 'source.avs':
  Duration: 00:01:00.02, start: 0.000000, bitrate: 0 kb/s
    Stream #0:0: Video: rawvideo (BGRA / 0x41524742), bgra, 1920x1080, 60 fps, 60 tbr, 60 tbn, 60 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
Press [q] to stop, [?] for help
[libx264 @ 06553880] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA3 BMI1
[libx264 @ 06553880] profile High 4:2:2, level 4.2, 4:2:2, 8-bit
Output #0, h264, to 'cputest-ff-3.h264':
  Metadata:
    encoder         : Lavf58.20.100
    Stream #0:0: Video: h264 (libx264), yuv422p(progressive), 1920x1080, q=-1--1, 60 fps, 60 tbn, 60 tbc
    Metadata:
      encoder         : Lavc58.35.100 libx264
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1

Format                                   : AVC
Format/Info                              : Advanced Video Codec
File size                                : 20.2 MiB
Writing library                          : x264 core 157 r2935 545de2f
Encoding settings                        : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=9 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=2 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=33 / keyint_min=3 / scenecut=40 / intra_refresh=0 / rc_lookahead=33 / rc=crf / mbtree=1 / crf=19.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

Video
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High 4:2:2@L4.2
Format settings                          : CABAC / 4 Ref Frames
Format settings, CABAC                   : Yes
Format settings, RefFrames               : 4 frames
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Variable
Standard                                 : Component
Color space                              : YUV
Chroma subsampling                       : 4:2:2
Bit depth                                : 8 bits
Scan type                                : Progressive
Writing library                          : x264 core 157 r2935 545de2f
Encoding settings                        : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=9 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=2 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=33 / keyint_min=3 / scenecut=40 / intra_refresh=0 / rc_lookahead=33 / rc=crf / mbtree=1 / crf=19.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Color range                              : Full

This is all a big joke of mine to show you what the user has to go through to define one setting in ffmpeg if he knows how to figure things out, this is why it's I told it's a big waste of time, to play with it, it took me about one hour and half. Later you figure it out that none of that is necessary, all you have to do it's to use ffmpeg -color_range 2 setting, invalidating already what we have established in the first place and going against what the documentation says.

I understand that once you got it, you let it be for a long time until the developers remove that "x264opts" without telling you, there is not warning telling you that "x264opts" will be relaced, then one day you'll update your ffmpeg to figure it out that all your settings don't work anymore and you'll have to go through all this mess all over again.
HAHAHAHAHAHAHAHAHAHAHA

[poisondeathray]

This is all a big joke of mine to show you what the user has to go through to define one setting in ffmpeg if he knows how to figure things out, this is why it's I told it's a big waste of time, to play with it, it took me about one hour and half. Later you figure it out that none of that is necessary, all you have to do it's to use ffmpeg -color_range 2 setting, invalidating already what we have established in the first place and going against what the documentation says.

I understand that once you got it, you let it be for a long time until the developers remove that "x264opts" without telling you, there is not warning telling you that "x264opts" will be relaced, then one day you'll update your ffmpeg to figure it out that all your settings don't work anymore and you'll have to go through all this mess all over again.
HAHAHAHAHAHAHAHAHAHAHA

It's definitely not for beginners

Right now they are mostly interchangeable , x264opts and x264-params, yes it might change in the future

I'm assuming you wanted "full" range because you actually wanted full range ? I'm assuming you wanted "HD" colors / 709 because it's 1920x1080 ?

Did you check your output ? Your avs source is rgb, so you have other problems with the conversion (wrong matrix). Did you check the levels ? (Wrong levels too)

Input #0, avisynth, from 'source.avs':
Duration: 00:01:00.02, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (BGRA / 0x41524742), bgra, 1920x1080, 60 fps, 60 tbr, 60 tbn, 60 tbc

The reason why you want to control the parameters instead of using -color_range is you want to control whether or not the levels are actually expanded vs. flagging only. You will get the wrong results using -color_range only. You want to control the actual conversion and matrix. Consider the cases where the input is YUV full range vs limited range vs RGB. You're going to get the wrong results if you don't know what you're doing.

But you could argue a beginner using x264 cli would have similar problems too, because they don't know what they are doing. They would screw up matrix, colors and levels too.

But you would expect fewer issues with x264, because it does fewer things. x264 doesn't do other things like filters, audio or filtering (for the most part, some patches can), multiple encoders and a/v manipulation. So you should expect ffmpeg to have more problems, wouldn't you?

But ffmpeg land is definitely a minefield, no argument there. Yes documentation could be improved

[_Al_]

Setting color matrix is the thing I am sorry that i did not set deliberately all the time, like Matrix, Transfer and Primaries . For example for NTSC DVavi videos:
x264.exe ....some options ..... --colorprim smpte170m --transfer smpte170m --colormatrix smpte170m
to see in mediainfo or other devices detecting it, so source plugins (like ffms2 in Vapoursynth) could read that,

Color primaries                          : BT.601 NTSC
Transfer characteristics                 : BT.601
Matrix coefficients                      : BT.601

nowadays it is being forked out into low resolution color spaces , HD and latest 2020 yet another transfers, so it should be at least always specified while encoding

btw to be on topic : ffmpeg settings, again, it is not intuitive for PAL, look at the bottom of this page it uses yet some twist to set it correctly for PAL color transfer: -color_trc gamma28 ,
so again, how many people figured it actually out

[poisondeathray]

Setting color matrix is the thing I am sorry that i did not set deliberately all the time, like Matrix, Transfer and Primaries . For example for NTSC DVavi videos:
x264.exe ....some options ..... --colorprim smpte170m --transfer smpte170m --colormatrix smpte170m
to see in mediainfo or other devices detecting it, so source plugins (like ffms2 in Vapoursynth) could read that,

Color primaries                          : BT.601 NTSC
Transfer characteristics                 : BT.601
Matrix coefficients                      : BT.601

nowadays it is being forked out into low resolution color spaces , HD and latest 2020 yet another transfers, so it should be at least always specified while encoding

vapoursynth is nice, in that it actually uses that metadata as clip props. But at the same time , if something is flagged wrong, you can get wrong results if you don't set the clip props. I've been burned many times, so I almost always display the props now in vapoursynth.

In that example amaipaipai posted above, it would have been an RGB to YUV conversion using 601, but limited range, yet flagged full range . So yes, a problem. No flag is better than wrong flag IMO

IMO, it's better to do the correct conversion, then flag it appropriately. Fewer screwups that way in my experience

The -colorspace -color_primaries -color_trc -color_range switches can problematic, because the actual data can change with some of them . If you don't know what you're doing , you're going to get the wrong results.

btw to be on topic : ffmpeg settings, again, it is not intuitive for PAL, look at the bottom of this page it uses yet some twist to set it correctly for PAL color transfer: -color_trc gamma28 ,
so again, how many people figured it actually out

-color_trc gamma28 is actually listed in the ffmpeg help under -color_trc, for bt.470 BG . So if you knew you needed bt470BG, it's easy to find. But it's better IMO to use the x264/265 VUI flag directly. So you know exactly what is going on, no mixups, no actual data changes for colormatrix, transfer, colorprim . Those 3 are VUI flags strictly) . If you had multiple ffmpeg outputs, they are not screwed up either. The tags are strictly assigned to each

  -color_trc         <int>        ED.V..... color transfer characteristics (from 1 to INT_MAX) (default unknown)
     bt709                        ED.V..... BT.709
     unknown                      ED.V..... Unspecified
     gamma22                      ED.V..... BT.470 M
     gamma28                      ED.V..... BT.470 BG
     smpte170m                    ED.V..... SMPTE 170 M
     smpte240m                    ED.V..... SMPTE 240 M
     linear                       ED.V..... Linear
.
.
<snip>

Whereas some hidden flags for -x264opts/-x264-params are not explicitly listed . Yes, most of them are the same as x264cli, but not all - so those are even harder to figure out

[_Al_]

No flag is better than wrong flag IMO

yes I guess that's the best

not talking about rips now, but camcorder, photo, phone videos, the sane workflow is knowing what colorspace camcorder is shooting and comparing RED(original vs. encoded), otherwise if getting HD fixing wrongly encoded video as 601 matrix it has to be deliberately switched in Vapoursynth for example :
fromBT601 to BT709:

clip = core.resize.Bicubic(clip, matrix_in_s = '470bg', matrix_s = '709')
or
clip = core.resize.Bicubic(clip, matrix_in = 5, matrix = 1)

that registers it in _Matrix prop correctly as 1
or this has the same effect:

clip = core.std.SetFrameProp(clip, prop="_Matrix",intval = 5)

color transfers are ok but it is registered still as BT601 on input end
its important when processes are automatized
or this fixes it too if trying to get RGB:

clip = core.resize.Bicubic(clip, matrix_in = 5, format = vs.RGB24)

but it is not registered within Vapoursynth, so if doing it later, matrix_in has to be specified again, all the time)
so that line is equivalent to:

clip = core.std.SetFrameProp(clip, prop="_Matrix",intval = 5)
clip = core.resize.Bicubic(clip, format = vs.RGB24)

So matrix_in does not have to be specified later after registering it. I love Vapoursynth how it handles color conversions, it gives you error, if not set right, nothing behind your back, say , oh data missing, lets throw there BT709 as default, no.

the best way is to compare red colors of original camcorder footage and encoded footage if encoding with software that uses all kinds of defaults, or just encode yourself using x264

[poisondeathray]

Other common scenario - eg. progressive content , encoded interlaced. For example some camcorders which do not shoot native progressive, some "25p" pal dvd's, . It's flagged interlaced, so all operations in vpy are now treated as interlaced. You have to remember override the prop. It just takes some getting used to. I just display the props to double check everything , especially when some vpy scripts are imported (user functions) , which do a bunch of operations on the back end, they might do it incorrectly

[_Al_]

yes, that props concept is neat

[amaipaipai]

I'm assuming you wanted "full" range because you actually wanted full range ? I'm assuming you wanted "HD" colors / 709 because it's 1920x1080 ?

I'm using full range because all my equipment can deal with it unless it require a limited range or the source comes from a limited source.

Did you check your output ? Your avs source is rgb, so you have other problems with the conversion (wrong matrix). Did you check the levels ? (Wrong levels too)

Input #0, avisynth, from 'source.avs':
Duration: 00:01:00.02, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (BGRA / 0x41524742), bgra, 1920x1080, 60 fps, 60 tbr, 60 tbn, 60 tbc

No I did not.
My main concern was rendering time, rendering speed, file size and all the things we were talking about. Also, any of my playback equipment, besides my computer, can handle 4:2:2, my idea was to use the OP settings and see how it goes, so I didn't even care for levels or color matrix. My encodings are limited to YV12 4:2:0 and my AVS I use the propper conversion like:

ConvertToYV12(matrix="Rec709")

Since you asked, yes the levels are different and all the rest is a big mess.

RGB Source


Converted


Gettings a close up we can see the mess:

RGB Source


Converted


I don't use this settings so I don't care too much about it, but fell free to show us a correct use or a sollution, I'm sure everybody will learn from it, including me.

The reason why you want to control the parameters instead of using -color_range is you want to control whether or not the levels are actually expanded vs. flagging only. You will get the wrong results using -color_range only. You want to control the actual conversion and matrix. Consider the cases where the input is YUV full range vs limited range vs RGB. You're going to get the wrong results if you don't know what you're doing.

But you could argue a beginner using x264 cli would have similar problems too, because they don't know what they are doing. They would screw up matrix, colors and levels too.

That is why I don't use it and don't like it for video encodings, I use it for small stuff but never for audio or video encoding. The joke about "-color_range" was to show how deep inside the rabbit hole you have to go and when you get down there, it might not even be what you want or need. As I've demonstrated, genral users are gonna get wrong results and not even notice untill years latter.

But you would expect fewer issues with x264, because it does fewer things. x264 doesn't do other things like filters, audio or filtering (for the most part, some patches can), multiple encoders and a/v manipulation. So you should expect ffmpeg to have more problems, wouldn't you?

I like it simple to avoid unnecessary mess and more problems.
When I need a H264 encoding I use a x264 encoder, if I need a filter or something I do it in pre production, for DVD/Blu-Ray authoring I rather pay for a profissional solution like Pegasys you know, all you have to do it's to setup what you want and render it. I'm over 45 years old, I've came fom an era that if you need a text editor you had to program your own, I know because I've programmed mine using basic in a MSX and this took hours and hours to make, than came DOS, PC's, Windows 3, etc, etc. Today you just download what you need.

This is why I don't care much about ffmpeg, you just don't set what you want, you have to learn how to do it and you loose too much time in this learning curve. If it's not documented then you'll learn as you go or waste hours of your time looking in to it, like I did. Don't get me wrong, I don't mind to have control, I'm a big fan of Hybrid for instance, but ffmpeg is a waste of time, who in this day and age are gonna look in to the source code to figure it out the correct parameters? The "x264 help" was a perfect example, the manual ask you to go look in to that to see the correct parameters and ffmpeg uses a complete different one instead.

I lost 2/3 of my life in front a computer screen, inside a room or office. And waste more time learning ffmpeg's it's not a project I need in to my life right now.

[poisondeathray]

I agree, ffmpeg is not very fun to start with . It's not for everyone . If it's that painful you should avoid using it

Definitely there are some issues, and documentation could be better, but it's also a very useful tool . Pros/cons. Every tool has a learning curve or various quirks. (eg. avisynth is painful for many people. But yes, ffmpeg has more "issues" than most...)



But if there are "real" bugs (as in - you can't get the output you want, despite using the correct switches - even if they are not documented - someone out there knows how to do it if it's possible) , then it should be reported . "real" bugs tend to take precedence for developer time, over ones like cosmetic or documentation updates


Cheers

[Phlexor]

Not sure how much of a difference it would make, but you are running in single channel with only 1 dimm.

Another thing, being a laptop, I wonder if the CPU is throttling down due to heat?

[amaipaipai]

I agree, ffmpeg is not very fun to start with . It's not for everyone . If it's that painful you should avoid using it

It's not painful at all, it's the annoyance that get me. It's like going to a Mcdonald's order a burger and the person responsible to take your order tell you to go inside the kitchen and talk directly with the guy that are cooking the type of burger you want, if I have to do this directly myself, why we need a person to take your orders in the first place?

If ffmpeg requires you to set your settings direct in to the encoder, ffmpeg it's useless, it's just a very bad thought out front end. If this is the case, use the encoder directly, remove the goofy ffmpeg out of the way!

If we are going to encode H264 use x264, if we need mp3 use lame, AAC use qaac, to mux it we can use MP4Box or any other mkv tool, wrap all this inside a script and thats it. Use ffmpeg to something else like "faststart" flag or whatever.

Well, this is me.

Have a good one!

[poisondeathray]

It's not painful at all, it's the annoyance that get me. It's like going to a Mcdonald's order a burger and the person responsible to take your order tell you to go inside the kitchen and talk directly with the guy that are cooking the type of burger you want, if I have to do this directly myself, why we need a person to take your orders in the first place?

If ffmpeg requires you to set your settings direct in to the encoder, ffmpeg it's useless, it's just a very bad thought out front end. If this is the case, use the encoder directly, remove the goofy ffmpeg out of the way!

If we are going to encode H264 use x264, if we need mp3 use lame, AAC use qaac, to mux it we can use MP4Box or any other mkv tool, wrap all this inside a script and thats it. Use ffmpeg to something else like "faststart" flag or whatever.

I don't understand that faulty logic, and it's a bad analogy - because you have enter the settings for x264, qaac, mp4box too. How else would FFmpeg "guess" what you want to do ? So you'd rather use 3 tools, instead of one. Ok...you'd rather place 3 different orders with 3 different cooks and wait in line for 2 of them to finish cooking sequentially before you can start to eat your order. That's not annoying ? With FFmpeg, you can eat all 3 as you go, because all 3 are processed simultaneously . It's faster

I wouldn't really call it a "front end" per se; It's a CLI application. Yes it does make use of libx264 and bunch of other tools and libraries but it's not a direct front end for x264.exe, or mp4box.exe, or mkvmerge.exe etc..., (it doesn't even use the later two, and libx264 is just the same library, the x264 binary is not called). Something like hybrid, staxrip would more appropriately called a "front end" . FFmpeg does not necessarily replace the other tools completely (although it can in some scenarios, but some functions are missing), it complements them.

Take it from someone comfortable with these tools - they each have pros/cons. FFmpeg is very useful / better in some scenarios/ worse in others , there are reasons why some users prefer to use it in some scenarios but not others.

They are just tools , but some are true gems, and well worth investing the learning time . FFmpeg is one of them. I get it , some people hate x264cli , some hate avisynth , it's "useless" to them for various reasons - but these are all useful tools in some scenarios

[pandy]

Pandy ask me to, I don't use ffmpeg for video encoding.

I must say i that my first intention was to not react knowing how overreacting you can be but as this discussion continue bellow my two cents.

Nope, i never asked you to "do" anything, i just asked why are you using two different encoder settings to compare encoding speed, quality and coding gain especially that differences between them was fundamental (progressive vs non progressive).

Also i provided sample how to use ffmpeg with libx264 to control properly libx264 in very similar fashion as you can control x264.
ffmpeg can provide almost full functionality of x264 - differences are related to mostly pulldown related (and overall time) settings , funny is that x264 using ffmpeg as optional frontend (some filters for example).

I like ffmpeg even if i complain a lot but for sure it is like swiss army knife - it will be difficult to cut large tree but still it can save your life. One thing i'm sure - i would not complain that tool doesn't work if i don't know how to use it - this is like complaining that some damages occurs because philips tip screwdriver didn't worked for pozidrive bolt head (or vice versa).

FYI ffmpeg use libx264 but this is one of few h.264 encoders supported by ffmpeg (i use private ffmpeg build that support those encoders: libx264 libx264rgb libopenh264 h264_amf h264_nvenc h264_qsv nvenc nvenc_h264) and as libx264 is external library thus it have own, private set of parameters - IMHO quite reasonable approach (some global ffmpeg are mapped directly but anyway they can be override by private options if they exist) - outcome of using external library is that you can have with identical encoder settings identical output with all benefits related to ffmpeg ecosystem.

[amaipaipai]

I don't understand that faulty logic, and it's a bad analogy - because you have enter the settings for x264, qaac, mp4box too. How else would FFmpeg "guess" what you want to do ? So you'd rather use 3 tools, instead of one. Ok...you'd rather place 3 different orders with 3 different cooks and wait in line for 2 of them to finish cooking sequentially before you can start to eat your order. That's not annoying ? With FFmpeg, you can eat all 3 as you go, because all 3 are processed simultaneously . It's faster

I don't understand the fault in logic as mine because you will have to do exact that with ffmpeg. You'll enter the settings for x264, for audio, for your container, for your flags, not to say the circular dependency and redundancy ffmpeg has. I rather have a specialist for each and every thing I need than one does all and does it very badly, since this is the case, I don't mind to wait a little longer to get the process done right.

I wouldn't really call it a "front end" per se; It's a CLI application. Yes it does make use of libx264 and bunch of other tools and libraries but it's not a direct front end for x264.exe, or mp4box.exe, or mkvmerge.exe etc..., (it doesn't even use the later two, and libx264 is just the same library, the x264 binary is not called). Something like hybrid, staxrip would more appropriately called a "front end" . FFmpeg does not necessarily replace the other tools completely (although it can in some scenarios, but some functions are missing), it complements them.

I call it garbage, my opinion, I'm not trying to offend anyone with it.

Take it from someone comfortable with these tools - they each have pros/cons. FFmpeg is very useful / better in some scenarios/ worse in others , there are reasons why some users prefer to use it in some scenarios but not others.

Agree!

They are just tools , but some are true gems, and well worth investing the learning time . FFmpeg is one of them. I get it , some people hate x264cli , some hate avisynth , it's "useless" to them for various reasons - but these are all useful tools in some scenarios

I agree with everything you said in this quote but ffmpeg's. I rather invest my time with avisynth, this is a true gem! I'm still learning how to use it, it has some annoyances but with reading and dedication the end results are amazing! Take QTGMC for instance, all the people responsible for that are geniuses, not only them but all the people involved with external library it require to work, all the people that share their own scripts, hands down, no question. I include jagabo on this list, the black bars script he did taking in consideration the resolution and aspect ratio still has a "WOW" effect on me.

Very different from ffmpeg that even reading different sources the information lead you in to a dead end as I've explained and demonstrated already.
Again, I don't care about ffmpeg anymore, fell free to use it!
I'm sure it's a handy tool to many people out there.

You have a good one poisondeathray

[pandy]

I agree with everything you said in this quote but ffmpeg's. I rather invest my time with avisynth, this is a true gem! I'm still learning how to use it, it has some annoyances but with reading and dedication the end results are amazing! Take QTGMC for instance, all the people responsible for that are geniuses, not only them but all the people involved with external library it require to work, all the people that share their own scripts, hands down, no question. I include jagabo on this list, the black bars script he did taking in consideration the resolution and aspect ratio still has a "WOW" effect on me.

But Avisynth and ffmpeg covers completely different areas... They are complementary and in almost non overlapping areas... Your comment triggered my memory that i started from Avisynth and Avisynth leaded me to ffmpeg - synergy between Avisynth and ffmpeg is quite obvious.

[amaipaipai]

But Avisynth and ffmpeg covers completely different areas...

That wasn't my point.
My point was that both require time and effort to learn how to use it, the main difference is that the learning curve with Avisynth pay off. Avisynth it's a perfect example of what ffmpeg should be, with avisynth you can take different library's and tools to make it work as one!

ffmpeg uses x264 library, for instance, tell you to look in to the x264 documentation for options and it doesn't work as I have already demonstrated because someone there thought it was a good idea to make the change without telling people about it and without updating their own documentation, so the end user has to guess his way out as he goes.

They are complementary and in almost non overlapping areas... Your comment triggered my memory that i started from Avisynth and Avisynth leaded me to ffmpeg - synergy between Avisynth and ffmpeg is quite obvious.

At first it was the same with me and many others, I don't see it like that anymore, sorry.

[_Al_]

Point is we have choices and free tools, also thanks ffmpeg there are libraries that different tools use in their packages. What is better or worse, more confusing or not confusing could be hardly narrowed down as a consensus.

[pandy]

Point is we have choices and free tools, also thanks ffmpeg there are libraries that different tools use in their packages. What is better or worse, more confusing or not confusing could be hardly narrowed down as a consensus.

Point is that ffmpeg and avisynth can't be compared as they are two different things, avisynth can't replace ffmpeg and ffmpeg can't replace avisynth - that's all.

[_Al_]

Sure, and ffmpeg could be a spot on weapon, loading video, selecting streams and encoding to a container. Easy and it works. amaipaipai might be trying to emphasize that if things get complicated, it can get weird, but that's anyone's choice. Some scenarios are figured out and then just simply used again and again.