This command preserved the colorspace and also video didnt get darker after transcoding
ffmpeg -i input.mp4 -color_primaries smpte170m -color_trc smpte170m -colorspace smpte170m -r 25 -crf 18 output.mp4
more about colorspace: https://trac.ffmpeg.org/wiki/colorspace
For files already encoded to AVI, you'll have to extract the video to a raw HEVC stream first:
ffmpeg -i in.avi -c copy -map 0:v -f hevc in.265
ffmpeg -framerate 30 -i in.265 -i in.avi -c copy -map 0:v -map 1:a -video_track_timescale 1k fixed.mp4
Replace the framerate value with the true rate of the video.
Encode new files to MP4 or MKV.
Try Encoding using "--tune fastdecode" and also check if "Average Bitrate" with "2 Pass" is better than "Constant Quality" with your particular Decoder; trying to maintain Quality over Bitrate can spike the Bitrate (holding a particular Bitrate will drop the Quality on complex Scenes).
Try a few Test Files (short Clips from your Source) and determine which ...
Summary response for summary question :)
CRF 20 will look really nice
8-bit (no advantages over 10-bit)
No tuning. Grain tuning is for grainy source (old content). SSIM is for testing.
No additional parameters needed.
VFR (same as source)
I could really, really, reallly go down the rabbit hole with a more detailed answer, but I'll leave it at this for now.
The name for this feature is Multiview Video Coding (MVC):
an stereoscopic video coding standard for video compression that
allows for the efficient encoding of video sequences captured
simultaneously from multiple camera angles in a single video stream
Can't be done, at present. Not using open source tools. There may be academic or commercial ...
Can't comment on the soundness of your theory, but here's a way to do it. Not directly, but in a roundabout way.
FFmpeg's segment muxer can break up a file at GOP boundaries, so running the command below generates a set of videos which each start with a keyframe but contain no other keyframes.
ffmpeg -i test.mp4 -c copy -f segment -segment_time 0.001 -...
You've specified the encoding bit rate to be 5000*1000 kbs. So the constraint here is the file size, not the quality of the video (i.e., all of your videos will be approximately 5 kbs * duration in size, regardless of the choice of encoding).
HEVC has the potential to have higher quality at a given bit rate, though it comes at a cost of encoding speed (i.e., ...
I've transcoded some of my AVC (h.264) 1080p movies to HEVC (h.265) with 2 pass encoding (using my GPU) and target bitrate set to 50% of original. The other streams (like audio and subtitles) were only copied into the new file.
Mostly I'm using Potplayer to play these files with Madshi renderer, and I can't see any difference on a 55" 4k HDR TV with ...
Personally I always stick to multiple of 8 but here it is:
Multiple of 4: In H.265, DCT can be done in 4x4 Transform Units, so it's not a problem for that. It can also use motion vectors for 8x4 or 4x8 Prediction Units if there is only a single reference frame, or 8x8 if there are 2 reference frames. I suspect this causes some inefficiency, but nowhere near ...
As the excerpt below says,
A thread pool dedicated to a given NUMA node is enabled only when the
number of threads to be created on that NUMA node is explicitly
mentioned in that corresponding position
"+,-,+" --> no numerals stated, hence a single pool.
"8,+,+,+" --> numeral for node 0, hence that's one pool. The other nodes have no numerals, ...
With Mulvya's help, I figured out the issue. FFMPEG was using a codec tag of hev1, while Media Encoder was using hvc1. Nothing I tried in FFMPEG would change this.
Mulvya suggested I use mp4box to repackage. mp4box -add out.mp4 -new final.mp4 didn't work. But, after a little more searching, I ended up following the suggestion here and used mp4box to ...