On 12/6/2016 2:31 PM, Vittorio Giovara wrote: > On Tue, Dec 6, 2016 at 10:50 AM, James Almer <jamr...@gmail.com> wrote: >> On 12/2/2016 5:17 PM, James Almer wrote: >>> On 12/2/2016 5:00 PM, Vittorio Giovara wrote: >>>> This will simplify identifying files that were generated with >>>> unfinished/incomplete/non-standard specifications. >>>> >>>> Signed-off-by: Vittorio Giovara <vittorio.giov...@gmail.com> >>>> --- >>>> libavformat/movenc.c | 2 ++ >>>> 1 file changed, 2 insertions(+) >>> >>> Maybe lavf and lavc should add "experimental" to the container and >>> stream's metadata alongside the library version, much like how we're >>> adding the name of the encoder alongside the lavc version to the >>> stream's metadata. >>> >>> A warning printed by the muxer not going to help once such a file >>> is in the wild. > > Yeah I was unsure about that -- are you saying that whenever -strict > experimental is used we should add this tag regardless? > > The idea behind this is that in the future, when the standard is > consolidated, if there is a file is in the wild encoded with an > "experimental" codec/container combination and it is not playing > correctly, this tag will make evident that the bug lies within the > file and the playback issues are probably due the unfinished state of > the specification, rather than in in the modern implementation of the > demuxer. In other words, people will be less inclined to hack around > their own demuxer to accommodate for broken files.
Oh, i misread the patch. I thought it was printing a warning, not adding a "WARNING" stream metadata tag. This patch is ok as is, i guess, but maybe a more general solution like what i suggested is better. Having the standard "encoder" tags read something like "Lavf5x.xx.xx (experimental)" and "Lavc5x.xx.xx vorbis (experimental)" if -strict experimental is used regardless of format, instead of a non standard "WARNING" tag in one or two specific containers, which may or may not be ignored by players and parsers. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel