On 08/08/2020 12:22, Timo Rothenpieler wrote:
On 07.08.2020 10:18, leozhang 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
Are there any negative side-effects of this?
Like, what happens if the user is transcoding a live tv recording that switches
resolutions? Will nvenc and the muxer after it handle it gracefully? How are
they handling it right now?
Many muxers won't. Anything which requires global headers (such as mp4 or mkv) will write a nonconformant file which will work in some cases but fail in others - some players will not work at all,
and seeking across the boundary will be broken if the headers are not included in front of every seek point.
I don't immediately see a bad case if you make sure it rejects the change immediately if the user tries to use it when avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER and have it always include inline
headers on every seek point, but there might be something else I'm missing. (There is a good reason why autoscale is the default.)
More generally, the API doesn't currently allow this and all other users seem to be happy with doing a close/reopen. Is there something wrong with how libavcodec is using Nvidia to make it especially
slow here? They advertise being able to do more than 20 simultaneous streams on one card - does that really take 40 seconds to start?
- Mark
_______________________________________________
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".
