On 08/08/2020 17:22, Linjie Fu wrote:
On Sat, Aug 8, 2020 at 7:21 PM Timo Rothenpieler <t...@rothenpieler.org> wrote:On 08.08.2020 02:48, Linjie Fu wrote:On Fri, Aug 7, 2020 at 4:19 PM leozhang <leozh...@qiyi.com> wrote:Allow dynamic resolution change, this is useful for real time video communication application. Use below commands to test it, ffmpeg -i reinit-large_420_8-to-small_420_8.h264 -noautoscale -c:v hevc_nvenc out.265 -loglevel verbose -y ffmpeg -i reinit-large_420_8-to-small_420_8.h264 -noautoscale -c:v h264_nvenc out.264 -loglevel verbose -y Signed-off-by: leozhang <leozh...@qiyi.com> --- libavcodec/nvenc.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-)Hi leozhang, Adding dynamic resolution encoding support is the tendency, and there are some previous discussions[1] [2] about adding support for dynamic resolution encoding. And one conclusion is that we'd prefer to cope with this in a more general way, like recreating the encoder instance instead of modifying in specific codec. - LinjieThe problem is, that specially in the case of nvenc, re-creating the encoder can take several seconds.There is once a concern about parameter changing in the AVCodecontext in the last discussion: [1] libavcodec encoders have always assumed that the stream parameters are set once and never change afterwards.Patch generally looks okay to me, and I'm fine with applying it.I'm ok with this if it didn't cause the side-effects you've mentioned. (since before we got a decent support, better ever than never) - Linjie [1] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2020-February/257377.html _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
As far as I am aware, the NVENC encoder requires that both maxEncodeWidth and maxEncodeHeight are greater or equal to the new resolution you are targetting. If they aren't, the resolution change will fail. It is most likely safe to assume that the encoder is unsafe to use if that change fails.
For example in live transcoding you would have to know the possible maximum resolution ahead of time - which unless documented or included in the container information is impossible. But it might be safe to just set them to the resolution that started the encode session, and only allow switching to smaller-than-original resolutions.
Note that dynamic resolution changes should be impossible while maxEncodeWidth and maxEncodeHeight are at 0, according to the nvEncodeAPI.h file:
> Client should allocate output buffers according to this dimension for dynamic resolution change. If set to 0, Encoder will not allow dynamic resolution change.
-- Sincerely | Mit freundlichen Grüßen Michael Fabian 'Xaymar' DirksPS: I apologize if I made any mistake replying to this list. I haven't actively used mailing lists for several years now.
OpenPGP_0xE3F6FC54A2BACD73.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
