Conversion Software

[Benjamin Hilton]

Hey all,

I'm in the process of switching editing software for our company from Premiere Pro to FCPX. I really liked Premiere, it has the bases of our workflow for many years now. Our main issue was stability, just so many issues over and over again with no sign of improvement. I've cut two projects in FCPX over the last couple of weeks and really enjoyed it! I feel like my editing speed has gone up due to the flawless performance of the software and I really get this feeling like FCPX just gets out of the way of my editing...revolutionary I know. 

My main question is what conversion software do you guys use? I am used to the abundance of options available in Premiere Pro for rendering that are lacking in Final Cut.  I could drop the $50 for compressor, but just wondering if that is the best option. Anything better/cheaper for encoding/conversion etc.?

[rawshooter]

29 minutes ago, Benjamin Hilton said:

Anything better/cheaper for encoding/conversion etc.?

If your target is h264/h265, Handbrake is not only free and Open Source, but also achieves better image quality than Adobe Media Encoder. 

[kye]

Not sure about the quality, but Resolve comes with a Media Management engine built in.  It's kind of hidden, but its super simple to use, and has all the cool codecs.

https://***URL not allowed***/davinci-resolve-media-manager/

[Benjamin Hilton]

Thanks for the suggestions. I tried Handbrake and it is definitely slower than Media Encoder, but great final output! Might just work for me...

[Mark Romero 2]

A couple of people on the Resolve forums suggest staxrip. I haven't used it myself. But they swear by it for encoding to h.264. I don't even know if it is available for Mac.

[rawshooter]

In the end, all the free/Open Source conversion programs - including Handbrake and Staxrip - are just graphical user interfaces for ffmpeg, and will thus yield the same results and performance. So one can simply stick with the tool whose user interface one prefers - or use ffmpeg directly on the command line. (Which provides more advanced functions such as ProRes and DNxHR encoding...)

[KnightsFan]

I always use ffmpeg from the command line. Like @rawshooter said, all the free converters use ffmpeg under the hood but may expose different options. If you put some time into learning it, running ffmpeg commands yourself offers the most flexibility, for free. You can really dial in the quality/encoding time/size compromises to just where you want it, and if you can take advantage of hardware acceleration then it's lightning fast.

[Mark Romero 2]

18 hours ago, rawshooter said:

In the end, all the free/Open Source conversion programs - including Handbrake and Staxrip - are just graphical user interfaces for ffmpeg, and will thus yield the same results and performance. So one can simply stick with the tool whose user interface one prefers - or use ffmpeg directly on the command line. (Which provides more advanced functions such as ProRes and DNxHR encoding...)

Thanks for the insight.

Out of curiosity, ffmpeg is multiplatform, right?

And if so, is there any benefit to running it on a linux box over running it on a windows box?

I know Linux generally has less codex / libraries than windows but maybe there is something I am overlooking???

17 hours ago, KnightsFan said:

You can really dial in the quality/encoding time/size compromises to just where you want it, and if you can take advantage of hardware acceleration then it's lightning fast.

I've heard that - at least in resolve - that using hardware acceleration might degrade quality in terms of exporting to an h.264 codec. I don't know if this is true or not. Is there any consensus that for ffmpeg whether hardware acceleration degrades quality (or results in a larger finished file to get the same quality as using software rendering)?

[KnightsFan]

10 minutes ago, Mark Romero 2 said:

I know Linux generally has less codex / libraries than windows but maybe there is something I am overlooking???

Ffmpeg is the library, so that shouldnt be an issue. I dont know if performance is different.

30 minutes ago, Mark Romero 2 said:

I've heard that - at least in resolve - that using hardware acceleration might degrade quality in terms of exporting to an h.264 codec. I don't know if this is true or not. Is there any consensus that for ffmpeg whether hardware acceleration degrades quality (or results in a larger finished file to get the same quality as using software rendering)?

Resolve's encoders suck in general. I recently discovered that their AAC encoder produces all kinds of artifacts, so i am using trusty ffmpeg to encode audio from PCM and losslessly mux with the video.

I have not tested hardware encoding quality in ffmpeg, i use it for creating proxies so i want it to be fast rather than high quality. It would be interesting to test.

[rawshooter]

39 minutes ago, Mark Romero 2 said:

Out of curiosity, ffmpeg is multiplatform, right?

And if so, is there any benefit to running it on a linux box over running it on a windows box?

I know Linux generally has less codex / libraries than windows but maybe there is something I am overlooking???

I've heard that - at least in resolve - that using hardware acceleration might degrade quality in terms of exporting to an h.264 codec. I don't know if this is true or not. Is there any consensus that for ffmpeg whether hardware acceleration degrades quality (or results in a larger finished file to get the same quality as using software rendering)?

ffmpeg is multiplatform and only uses its own, included codec library (here is a complete list of all encoders). Performance is practically the same on Windows, Linux and MacOS, although the program is chiefly developed under Linux.

Hardware acceleration indeed degrades the export quality to h.264 or h.265 if you use the (very fast) on-chip encoders of Nvidia and AMD GPUs. The CPU-only x264 and x265 codecs of ffmpeg yield much better image quality, especially if you use the "slow" or "very slow" encoding preset and the "film" tuning parameter. (They are also available in the Handbrake GUI.) You pay with much longer encoding time. Optionally/alternatively, ffmpeg can also use the Nvidia on-chip encoder (nvenc, which you can select in Handbrake as well).

For me, as a commandline person, it's easier to just type "ffmpeg -i myvideo.mxf -vcodec libx264 -b:v 18000k -tune film -preset veryslow -b:a 192k myvideo.mp4" than clicking through Handbrake's menus, but your mileage may vary... 

[Mark Romero 2]

47 minutes ago, KnightsFan said:

Resolve's encoders suck in general. I recently discovered that their AAC encoder produces all kinds of artifacts, so i am using trusty ffmpeg to encode audio from PCM and losslessly mux with the video.

I have not tested hardware encoding quality in ffmpeg, i use it for creating proxies so i want it to be fast rather than high quality. It would be interesting to test.

Thanks so much for the response and the information.

47 minutes ago, rawshooter said:

ffmpeg is multiplatform and only uses its own, included codec library (here is a complete list of all encoders). Performance is practically the same on Windows, Linux and MacOS, although the program is chiefly developed under Linux.

Hardware acceleration indeed degrades the export quality to h.264 or h.265 if you use the (very fast) on-chip encoders of Nvidia and AMD GPUs. The CPU-only x264 and x265 codecs of ffmpeg yield much better image quality, especially if you use the "slow" or "very slow" encoding preset and the "film" tuning parameter. (They are also available in the Handbrake GUI.) You pay with much longer encoding time. Optionally/alternatively, ffmpeg can also use the Nvidia on-chip encoder (nvenc, which you can select in Handbrake as well).

For me, as a commandline person, it's easier to just type "ffmpeg -i myvideo.mxf -vcodec libx264 -b:v 18000k -tune film -preset veryslow -b:a 192k myvideo.mp4" than clicking through Handbrake's menus, but your mileage may vary... 

Thanks so much for the elaboration.

I have one client that NEEDS the final video file to be under 500MB (as in, 499MB is fine, but 500MB is too big). It can be either h.264 or h.265 codec, and off the top of my head, the wrapper doesn't matter so much, so I think either .mov or .mp4 is fine.

The problem is, I can't "predict" how big the final video file is going to be before rendering it. So using the slow encoding presets means I have to spend an hour or so to render a three minute video file, only to find out it is over 500MB and too big for the client.

So is there a way either with ffmpeg or with one of the GUI for ffmpeg to "preview" what the final size is before rendering? Or to even limit the file by size?

Ideally, I would love for the software to just figure out what the best quality settings should be automatically while still keeping it at under 500MB final file size.

Don't know if that exists in the command line ffmpeg options or in a particular GUI.

[KnightsFan]

23 minutes ago, Mark Romero 2 said:

have one client that NEEDS the final video file to be under 500MB (as in, 499MB is fine, but 500MB is too big). It can be either h.264 or h.265 codec, and off the top of my head, the wrapper doesn't matter so much, so I think either .mov or .mp4 is fine.

The problem is, I can't "predict" how big the final video file is going to be before rendering it. So using the slow encoding presets means I have to spend an hour or so to render a three minute video file, only to find out it is over 500MB and too big for the client.

So is there a way either with ffmpeg or with one of the GUI for ffmpeg to "preview" what the final size is before rendering? Or to even limit the file by size?

Look into 2-pass encoding. You can do it with ffmpeg, there is a description here https://trac.ffmpeg.org/wiki/Encode/H.264 (also available with H.265).

Alternatively, you can specify min and max bitrates, but two pass is generally the way to go for targeting a specific file size. I'm sure there are GUIs out there that do it, just look for something with two pass encoding options.

[Benjamin Hilton]

On 1/21/2020 at 4:25 PM, KnightsFan said:

I always use ffmpeg from the command line. Like @rawshooter said, all the free converters use ffmpeg under the hood but may expose different options. If you put some time into learning it, running ffmpeg commands yourself offers the most flexibility, for free. You can really dial in the quality/encoding time/size compromises to just where you want it, and if you can take advantage of hardware acceleration then it's lightning fast.

This is really good to know

[Benjamin Hilton]

On 1/22/2020 at 11:49 AM, Mark Romero 2 said:

Thanks so much for the response and the information.

Thanks so much for the elaboration.

I have one client that NEEDS the final video file to be under 500MB (as in, 499MB is fine, but 500MB is too big). It can be either h.264 or h.265 codec, and off the top of my head, the wrapper doesn't matter so much, so I think either .mov or .mp4 is fine.

The problem is, I can't "predict" how big the final video file is going to be before rendering it. So using the slow encoding presets means I have to spend an hour or so to render a three minute video file, only to find out it is over 500MB and too big for the client.

So is there a way either with ffmpeg or with one of the GUI for ffmpeg to "preview" what the final size is before rendering? Or to even limit the file by size?

Ideally, I would love for the software to just figure out what the best quality settings should be automatically while still keeping it at under 500MB final file size.

Don't know if that exists in the command line ffmpeg options or in a particular GUI.

You should be able to set a maximum bit-rate and calculate the size based on the video length. Meaning a 500MB = 4000mb = 22mb/sec for a 3 minute video

[Mark Romero 2]

40 minutes ago, Benjamin Hilton said:

You should be able to set a maximum bit-rate and calculate the size based on the video length. Meaning a 500MB = 4000mb = 22mb/sec for a 3 minute video

Thanks.

Does that hold true if the final codec is h.265 (as opposed to h.264)?

Also, does the "preset" being used (fast, slow, very slow) not affect the final file size?

[rawshooter]

1 hour ago, Mark Romero 2 said:

Does that hold true if the final codec is h.265 (as opposed to h.264)?

Also, does the "preset" being used (fast, slow, very slow) not affect the final file size?

The choice of codec and the preset makes no difference for the resulting file size. 

You simply use a tool like this one:
https://www.dr-lex.be/info-stuff/videocalc.html (Video Bitrate Calculator)

...which calculates the video and audio bitrate for you, then you use Handbrake/ffmpeg, specify the same two bitrates for the encoding, and choose 2-pass (possibly with "turbo first pass" option) encoding for the highest accuracy of your video matching the desired file size.

 

[Mark Romero 2]

7 minutes ago, rawshooter said:

The choice of codec and the preset makes no difference for the resulting file size. 

You simply use a tool like this one:
https://www.dr-lex.be/info-stuff/videocalc.html (Video Bitrate Calculator)

...which calculates the video and audio bitrate for you, then you use Handbrake/ffmpeg, specify the same two bitrates for the encoding, and choose 2-pass (possibly with "turbo first pass" option) encoding for the highest accuracy of your video matching the desired file size.

 

Thanks!!!

[njekolino]

Shutter Encoder. Best software for converting really

[Benjamin Hilton]

20 hours ago, rawshooter said:

The choice of codec and the preset makes no difference for the resulting file size. 

You simply use a tool like this one:
https://www.dr-lex.be/info-stuff/videocalc.html (Video Bitrate Calculator)

...which calculates the video and audio bitrate for you, then you use Handbrake/ffmpeg, specify the same two bitrates for the encoding, and choose 2-pass (possibly with "turbo first pass" option) encoding for the highest accuracy of your video matching the desired file size.

 

That's right, the bitrate will always determine your file size, no matter what codec you use. The codec just decides how efficient the bitrate you use is for the video, meaning 10mb/sec will look much better in h.265 as compared to h.264 as it is more efficient.