A wish for ffmpeg to be able to reference input properties

[Mulvya]

This is a feature request for ffmpeg to have the ability to reference input properties like codec, container, dimensions, bitrate, duration, GOP size..etc. Often the output properties bear some relation to input properties and adding the requested ability to ffmpeg will allow to bypass a script with ffprobe/grep multi-command-chain. This feature will be most useful when one wishes to perform adaptive processing of a batch of files having diverse properties.

Here is a mock (exaggerated) command example to illustrate the use of such a facility.

    ffmpeg -i file.ext -i file2.ext2 \
-t len(0:a) -s trunc(dim(1:v:1)/2) -c:v codec(1:v:1) -b:v bitrate(0:v) \ 
-other_filter_or_parameters -f type(0) output

Here -c:v codec(1:v:1) evaluates the codec of the 2nd video stream in the 2nd input and sets that as the output encoder.

-b:v bitrate(0:v) sets the target bitrate to be the same as the evaluated bitrate of the first video stream in the first input

-t len(0:a) encodes till the output reaches the duration of 0:a:0

-s trunc(dim(1:v:1)/2) sets the size to half of the 2nd video stream in the 2nd input

-f type(0) sets the f flag to the same format as the 1st input. Useful in cases like MXF where there are variants and extension isn't unique.

Thank You.

[Misaki]

In the contrived example, -shortest might be able to accomplish the same goal, but it might sometimes have some 'bugs'. (Audio ending slightly before video if they come from the same input file, things like that... -frames:v sometimes has similar issues)

In my experience, batch processing of diverse files is not ideal. One example, a file that is really 30 fps, but was encoded at 60 fps causing every other frame to be a duplicate. This doesn't show up in the file properties, and leaving it that way will cause CPU usage to be about twice as high during playback. Using a filter would remove the duplicate frames automatically, but the file would still have '60 fps' in the properties, so many video players (like VLC) will avoid using hardware decoding using the default method (VDPAU) in Linux, even if it's actually just 30 fps and could be played with no problems.

ffmpeg doesn't have a 'same quality as source' option, and common codecs like h.264 don't seem to facilitate it. So basically, video encoding is currently aimed at people with high-quality source videos. (Vine, and maybe Instagram, use h264 for their videos and the options are the same as the default in ffmpeg, so maybe they use it!)