ffmpeg Coding Help

[chris319]

Help! I can't make this work. How would I meld the second line (unsharp) into the first one? Everything I've tried generates some kind of error.

If I have two instances of -vf on the same line, there is no error but one or the other is ignored.

Thanks in advance.

ffmpeg -y  -i Caltrain156.mp4  -crf 0  -c:v libx264 -vf  lutyuv=y='clip(val,6,245)'    -x264opts colorprim=bt709:transfer=bt709:colormatrix=bt709   -c:a copy  clipped.mp4

-vf  unsharp=luma_msize_x=7:luma_msize_y=7:luma_amount=1.5

[poisondeathray]

use a comma to separate filters in a single sequential linear chain

e.g. To apply filter A,B,C in that order

-vf A,B,C

[chris319]

Thanks pdr, but ...

1. It works if there are no spaces surrounding the comma. It fails if there are space(s) adjacent to the comma.

2. It does what I want if I put unsharp before lutyuv. If I put lutyuv before unsharp, it ignores lutyuv.

[poisondeathray]

Thanks pdr, but ...

1. It works if there are no spaces surrounding the comma. It fails if there are space(s) adjacent to the comma.

Then don't use spaces , or enclose it with parentheses . IIRC it has to do with Windows escape syntax. It might be slightly different on linux

2. It does what I want if I put unsharp before lutyuv. If I put lutyuv before unsharp, it ignores lutyuv.

It works as expected

lutyuv is processed first, then unsharp

The order matters. If you clip first, then apply another filter later that changes the values. Recall what I said about unsharp - it changes the local contrast. Lower values get lower, higher values get higher.

[chris319]

Clipping first is completely undone by the unsharp filter, so clip last.

I'm having moire problems with unsharp, but that's just the nature of the filter. I'm having to use a filter value of 0.5 to overcome most, but not all of the moire.

[poisondeathray]

It's difficult to use filters in ffmpeg like this, because you can't "see" the preview and re-adjust settings on the fly. Nor can you keyframe or dynamically adjust settings without extreme difficulty (maybe some sections need to be brighter, some darker, some sharper, some less sharp , etc...) . A GUI like a NLE is more ideal, where you can use monitoring such as waveform/histogram/vectorscope etc...to guide your settings with live feedback and adjust appropriately

[pandy]

ffmpeg -y -i Caltrain156.mp4 -crf 0 -c:v libx264 -vf "unsharp=luma_msize_x=7:luma_msize_y=7:luma_amount=1.5,lutyuv=y='clip(val,6,245)'" -x264opts "colorprim=bt709:transfer=bt709:colormatrix=bt709" -c:a copy clipped.mp4

[chris319]

What's the difference if I work in "lossless" mp4 (crf 0) or FFV1 or HuffYUV?

I'm using an amount of 0.25 for unsharp. It adds a little bit of "snap" to the picture but there is no moire.

bin\ffmpeg -y  -i Caltrain156.mp4  -crf 0  -c:v libx264  -pix_fmt yuv420p  -s 1280x720  -r 59.94  -vf  unsharp=luma_msize_x=7:luma_msize_y=7:luma_amount=0.25,lutyuv=y='clip(val,6,245)'   -x264opts colorprim=bt709:transfer=bt709:colormatrix=bt709   -c:a copy  clipped.mp4

[chris319]

My NLE program, Shotcut, lacks the ability to add the clipping step, and it has a nice facility for adding text, so I think I'm looking at two processing steps, unfortunately.

[poisondeathray]

What's the difference if I work in "lossless" mp4 (crf 0) or FFV1 or HuffYUV?

It depends on what options are used, what settings are used.

Also , there are many lossless codecs to choose from. Pros/cons to each one, the specific situation would help dictate which ones you might use

They are judged by different criteria:

compression ratio
encoding speed
decoding speed
long gop vs. intra
colorspace support
bitdepth support
compatibility and handling by host applications and OS/platform

For example the original huffyuv (there are several variants of huffyuv) did not support 4:2:0, and you would be upsampling to 4:2:2. It's intra only, without long GOP options. So the filesize would probably be ~2x larger than if you used ffv1 or x264 with higher compression, long gop settings

Lossless codecs will usually increase filesize of the original if it used compression (expect several times larger), because it's "lossless" with respect to the decoded, uncompressed version of the original. If the original used lossy compression, you can never get back the original compression

So if you were short on HDD space, you might choose a higher compression , long GOP option. If your primary goal was editing, it might be a fast decoding , intra option. If it was archival, you'd probably use ffv1 intra with a crc check option. If it was compatibility with other programs, beware that many "lossless" YUV codecs are not lossless in some host applications - many are mishandled and converted to RGB

[chris319]

Let's say I have plenty of disk space and don't care about encoding speed.

[poisondeathray]

I would use whatever works with shotcut or however you're going to be using it . Test the workflow end to end. Since you've decided to use a lossless workflow (for at least some of it), you should probably verify that it's actually treated as lossless - otherwise what's the point? (do import/export , check differences or quality check like ssim/psnr. ffmpeg works, but that doesn't necessarily mean other programs do, or even that other programs using ffmpeg do.), and not getting mangled in other ways you don't know about yet . If you're working with other people, or handing off, you have to check with them too.



also missing from the list above:
-open source vs. closed (can you use it , say 10 years from now ? or is developer on a "holiday" or sick ?)
-active development vs. dead (those still being developed can make use of more cores, more CPU instructions, they keep getting faster)