Am 17.06.2017 um 00:11 schrieb Philip Langdale:
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 :-)
One thing to keep in mind is that cuvid is vastly different from other
hwaccels.
While for example for vaapi, specifying -hwaccel vaapi makes the h264
decoder use vaapi. But for cuvid, the h264_cuvid decoder always uses
hardware, and the -hwaccel cuvid flag is essentially used to switch its
output mode to cuda frames.
With the new approach, there is no apparent difference from using cuvid
with or without -hwaccel cuvid.
That situation would seem kinda weird and confusing to me.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
