[FFmpeg-trac] #7564(avfilter:new): hwdownload fails when size changes

[FFmpeg]

#7564: hwdownload fails when size changes
------------------------------------+------------------------------------
             Reporter:  msiders     |                    Owner:
                 Type:  defect      |                   Status:  new
             Priority:  normal      |                Component:  avfilter
              Version:  git-master  |               Resolution:
             Keywords:  hwdownload  |               Blocked By:
             Blocking:              |  Reproduced by developer:  0
Analyzed by developer:  0           |
------------------------------------+------------------------------------

Comment (by msiders):

 Replying to [comment:9 oromit]:
 > To avoid such confusion, please provide the full uncut output like asked
 at the very beginning in the future.

 Here it is:

 {{{

 }}}

 Please, note the "-loglevel error" in the example.
 And this isn't a joke.

 .
 > The outlink w/h parameters are set during config_props, where they are
 received from the hw_frames_ctx, which is created and set in the hwupload
 filter.

 These values are set correctly at the beginning.
 Nothing to comment about it.

 .
 > Unfortunately that means in its current state both hwupload and
 hwdownload do not support dynamic size changes and cannot be easily
 changed to do so.

 Bravo! You got it!

 But, the problem is not that "they do not support dynamic size changes".
 All video filters at time have such support. And in fact, "hwupload" (as I
 described and demonstrated) doesn't have any problem. That's it supports
 it.

 The problem is that "hwdownload" doesn't do it. And this is a bug!

 .
 > hwupload is the much bigger issue here. It will keep using the original
 hw_frames_ctx, which after the size change either allocates too big(waste
 of space) of a buffer or even too small of a buffer(which probably results
 in a crash).

 Now we're beginning to understand each other.
 However, the "hwupload" doesn't have any problem. Please, see the first
 test with a "scale_cuda" interposed. It doens't fail at all!

 But, Yes! When changing the size of frames, the HW Buffer has troubles as
 it is not resizable (at time). However, at least the size should be able
 to be reduced without changing the allocated space. This is true for other
 HW filters. For example "scale_cuda" doesn't have any problem when the
 software scale resizes the input to a lower value. It handles it
 correctly.

 .
 > Now it could be changed to monitor for input parameter changes, and then
 re-create a new hw_frames_ctx. But all downstream filters are already
 configured to the old context, and do not expect it to change at runtime.

 Yes. I see this problem. The hw context can't be changed without an
 important rewrite of the current code.
 We can live with this limitation until a huge rewrite could be done.

 .
 > Support for runtime parameter changes is also very spotty with pure sw
 filtering. With a hw filter chain it would be a major undertaking
 affecting every single hw filter.
 >
 > So the conclusion here is, that without a lot of bigger changes, runtime
 parameter changes like this are unsupported with a filter chain that uses
 hardware frames.

 Sorry. I need to repeat it: '''ONLY the "hwdownload" filter has problems
 reducing the size'''. I check it. And as I pointed the problem seems to be
 related to uncorrect code.

 If not, then try to explain why interposing the filter "scale_cuda" and
 reducing the size all goes right.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/7564#comment:10>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker