On Sat, 24 Jun 2017 21:42:23 -0400
"Ronald S. Bultje" wrote:
> Hi Philip,
>
> On Sat, Jun 24, 2017 at 7:40 PM, Philip Langdale
> wrote:
>
> > Feedback on first proposal was lack of interest in having default
> > behaviour vary between hwaccels, despite their other differences.
>
>
> I thin
On Sun, 25 Jun 2017 12:43:12 +0100
Mark Thompson wrote:
> Point (2) is somewhat more subtle. The default hwaccel behaviour is
> made for the real hwaccels attached to the normal decoder, and won't
> do the right thing for the dummy ones. The specific case that we
> strongly want to avoid is som
On 25/06/17 00:40, Philip Langdale wrote:
> Second try.
>
> Feedback on first proposal was lack of interest in having default behaviour
> vary between hwaccels, despite their other differences.
>
> In this patch series, I instead force the user to confront the change in
> command line semantics w
Hi Philip,
On Sat, Jun 24, 2017 at 7:40 PM, Philip Langdale wrote:
> Feedback on first proposal was lack of interest in having default behaviour
> vary between hwaccels, despite their other differences.
I think that's because many of us - including me - don't really understand
this.
I, for on
Second try.
Feedback on first proposal was lack of interest in having default behaviour
vary between hwaccels, despite their other differences.
In this patch series, I instead force the user to confront the change in
command line semantics when doing cuvid/nvenc transcoding. They will only
get fu
Second go at this, with an attempt at making the new hwaccel work the same as
the old one. I think most people don't actually agree with what's implemented
here (allowing an hwaccel to indicate that the hardware format should be the
default), but I want to capture the discussion the mailing list, a
