On Fri, 16 Jun 2017 21:53:22 +0200 wm4 <nfx...@googlemail.com> wrote:
> On Fri, 16 Jun 2017 20:31:14 +0200 > Timo Rothenpieler <t...@rothenpieler.org> wrote: > > > Am 16.06.2017 um 16:41 schrieb Philip Langdale: > > > This is mechanically simple, but does the fact that additional > > > command line arguments have to be used to get the same results > > > count as a compatibility break? Do we need to fix that before we > > > can actually make this change? > > > > I'd consider that as a breaking change, even though things don't > > "break", it results in unexpected behavior that is not obvious. > > Probably, but it's also slightly saner in general if you consider that > a user could add video filters. Currently, hwaccel filters and normal > filters are completely different beasts, so the user needs to be aware > of the difference, and select the appropriate mode. So depending on > whether you output hw surfaces by default, you'll break hw filters or > sw filters by default. Making sure sw filters work by default seems > like the better choice. > > But yes, maybe we could rename the hwaccel just so that users of the > old hwaccel become aware of the change. You could even keep the old > hwaccel name, and make it somehow override the -hwaccel_output_format > option and print a warning, in case you care enough for compatibility > in this case. We could use it as an opportunity to rename it to 'cuda' which is more accurate. Keeping the old specialised code for 'cuvid' would also ensure compatibility :-) --phil _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
