x264 supports both 8-bit and 10-bit outputs, and you don't have to do anything special.
If using ffmpeg you can see what pixel formats and bit depths are supported by libx264:
$ ffmpeg -h encoder=libx264
Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p nv12 nv16 nv21 yuv420p10le yuv422p10le yuv444p10le nv20le
edit: I successfully made a 10bit encode of Ducks Take Off.
First way: I built a 10bit x264 binary that statically links libx264.
cp -al x264-git x264-10bit # instead of changing my normal git checkout
./configure --extra-cflags=-march=native --enable-static --disable-interlaced --bit-depth=10
sudo install x264 /usr/local/bin/x264-...
Adobe licenses its H.264 encoder from Mainconcept, which doesn't do that well at low bitrates. x264 is pretty much the frontier when it comes at low size output for a given quality target, or quality for a given bitrate target. x264 is what's used by platforms like Youtube / Vimeo ..etc to encode user videos.
One thing you could try is to increase the ...
Cabac is lossless, but h264 is lossy. The part you are missing is that cabac is not THE compression algorithm. It is just the final step out of hundreds of steps in video compression. By the time you get to cabac, all the lossy steps have already been performed, and a final lossless step is added to squeeze a few more bits out.
The first thing I would try is to add -force_key_frames to your original command, drop the preset and lower the -crf value. The following example sets a key frame every second.
ffmpg -i input.mov -c:v libx264 -profile main \
-force_key_frames expr:gte(t,n_forced*1) \
-crf 15 -pix_fmt yuv420p -an output.mp4
As a second resort I would use a series of ...
Depending how the content was made, the banding might be introduced when you're converting your content from RGB colorspace to YUV. You can try to make an h264 while keeping RGB colorspace, although I've read it's not easy. Are you able to use another codec?
The bands you're referring to could well just be a limitation of the 8-bit colour space.
In theory the way to solve this is to use 10- or 12-bit colour space through every stage from rendering, to editing and mastering, through to output and even in the screen or projector. However your final output is probably going to be displayed in an 8 bits per ...
I finally made it work in splicing directly the VOB files with the commands below :
ffmpeg -i VTS_01_2.VOB -ss 463 -c copy -vframes 325 2-manuchoisit.vob
ffmpeg -i VTS_01_2.VOB -ss 353 -t 16 -c copy 3-manutombe.vob
and then concat the extracts and convert with
ffmpeg -analyzeduration 200M -probesize 150M -i "concat:1-manubus.vob|2-manuchoisit.vob|3-...
In the first step you are doing a lossy conversion, you transcode from vob to mp4, and then to ts. For a lossless re-mux you should just re-mux, better to specify both video and audio:
ffmpeg -i VTS_01_1.VOB -c:v copy -c:a copy -bsf:v h264_mp4toannexb -f mpegts intermediate1.ts
However, if you re-mux for the purpose of slicing then you should be aware that ...
Short answer is No.
Longer answer is, it depends.
If you're encoding a file, then generally the output is the duration of the input, unless there's speed change or trim filters or -ss, -to, -t options applied. For a live input, FFmpeg will stop the encode when it encounters EOF on the input, so unless you know that, you won't know the output duration. For ...
I avoid AME and use x264 via ffmpeg for H.264 encoding. From Premiere I prefer to output a temporary lossless compressed format as the intermediate, such as the free and open-source Ut video, instead of DNxHD/DNxHR/ProRes. This avoids any generation loss (minor as it may be with ProRes/DNxHD, but still technically present as they are not lossless). Also, I'm ...
It's a rendering artifact, not an actual error.
ffplay test444.mp4 -vf scale=iw*16:-1:flags=neighbor
ffmpeg -i test444.mp4 roundtrip.png
You should see no black pixels.
Update: ffplay downsamples YUV inputs to 420 before final conversion to RGB.
[swscaler @ 0000000005a82800] bicubic scaler, from yuv444p to yuv420p using MMXEXT
You can avoid ...
The scale filter has no effect on the encoder's bitrate control.
Yes, a scaled down video should have a lower bitrate if it is encoded with the same encoder settings as the source. In your command, since no encoder parameters are explicitly set, ffmpeg defaults to encoder x264 with rate-control mode CRF with value 23. Apparently, this results in the same ...
Just to add a bit to AJ Henderson correct answer.
You do can compress in a lossless way with h264, this is the lossless predictive profile and is achieved by encoding with a CRF setting of 0.
Though while you get lossless h264 compression that way you will endup with a larger file than your source file.
Lossy compression cant be done twice without loosing ...
You have a misunderstanding of how compression works. In all but a few specialized types of lossy compression, when you compress something a second time, even in a much higher quality level than previous encodings, you still lose additional quality.
Using a slower encoding from the same original source with constant quality will often produce a smaller ...