On Thu, 12 Jan 2017 23:31:11 +0100 Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
> 2017-01-12 23:20 GMT+01:00 Hendrik Leppkes <h.lepp...@gmail.com>: > > On Fri, Jan 13, 2017 at 1:10 AM, Carl Eugen Hoyos <ceffm...@gmail.com> > > wrote: > >> 2017-01-11 12:24 GMT+01:00 Moritz Barsnick <barsn...@gmx.net>: > >>> On Tue, Jan 10, 2017 at 17:05:47 +0100, Carl Eugen Hoyos wrote: > >>>> + enum AVPixelFormat pix_fmt = > >>>> avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi, > >>>> + > >>>> par->bits_per_coded_sample); > >>>> + if (par->format != pix_fmt && par->format != > >>>> AV_PIX_FMT_NONE) > >>>> + av_log(s, AV_LOG_ERROR, "%s rawvideo cannot be > >>>> written to vfw mkv, output file will be unreadable\n", > >>>> + av_get_pix_fmt_name(par->format)); > >>> > >>> Should it really be an error (and not a warning) if its detection > >>> doesn't change ffmpeg's behavior? > >> > >> Just copying what avi and mov muxer do. > >> > >> Note that (many) decoders print errors and (can) continue. > >> > >> (I believe library users can - and do - put rawvideo into standard > >> containers and force the right pix_fmt on reading.) > > > > That seems silly, we shouldn't log an error that a file will be broken > > and then still write it. Muxers should be strict and write only valid > > files. > > This is what we currently do for both other multi-purpose containers > (while FFmpeg logs no message for unreadable transport streams), > so lets please commit this. I have to agree with Hendrik. Your patch is all about adding a message for this case. Why not do the right thing in the first place? You'd only have to add an error return or so. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
