On Fri, Mar 24, 2017 at 01:49:16PM +0100, wm4 wrote: > 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). > --- > cmdutils.c | 10 +--------- > ffmpeg.c | 41 ++++++++++++++++++++++++++++++++++++----- > ffmpeg.h | 1 + > ffmpeg_opt.c | 12 ++++++++---- > libavformat/mov.c | 2 ++ > libavformat/movenc.c | 4 ++++ > libavformat/version.h | 3 +++ > 7 files changed, 55 insertions(+), 18 deletions(-)
Is this intended to fix (relative to last patch) ./ffmpeg -i ~/tickets/4012/IMG_4596.MOV -t 0.5 test.mov ./ffplay test.mov ? it seems to still be upside down with this applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
