• wm4's avatar
    avformat, ffmpeg: deprecate old rotation API · ddef3d90
    wm4 authored
    The old "API" that signaled rotation as a metadata value has been
    replaced by DISPLAYMATRIX side data quite a while ago.
    
    There is no reason to make muxers/demuxers/API users support both. In
    addition, the metadata API is dangerous, as user tags could "leak" into
    it, creating unintended features or bugs.
    
    ffmpeg CLI has to be updated to use the new API. In particular, we must
    not allow to leak the "rotate" tag into the muxer. Some muxers will
    catch this properly (like mov), but others (like mkv) can add it as
    generic tag. Note applications, which use libavformat and assume the
    old rotate API, will interpret such "rotate" user tags as rotate
    metadata (which it is not), and incorrectly rotate the video.
    
    The ffmpeg/ffplay tools drop the use of the old API for muxing and
    demuxing, as all muxers/demuxers support the new API. This will mean
    that the tools will not mistakenly interpret per-track "rotate" user
    tags as rotate metadata. It will _not_ be treated as regression.
    
    Unfortunately, hacks have been added, that allow the user to override
    rotation by setting metadata explicitly, e.g. via
    
      -metadata:s:v:0 rotate=0
    
    See references to trac #4560. fate-filter-meta-4560-rotate0 tests this.
    It's easier to adjust the hack for supporting it than arguing for its
    removal, so ffmpeg CLI now explicitly catches this case, and essentially
    replaces the "rotate" value with a display matrix side data. (It would
    be easier for both user and implementation to create an explicit option
    for rotation.)
    
    When the code under FF_API_OLD_ROTATE_API is disabled, one FATE
    reference file has to be updated (because "rotate" is not exported
    anymore).
    Tested-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
    Reviewed-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
    ddef3d90
cmdutils.c 71.6 KB