>> >> >> Can you explain the actual intended use-case for this? >> >> The current way to handle resolution changes (or any other stream change of >> similar magnitude, like a pixel format change) is to flush the existing >> encoder and then make a new one with the new parameters. Even ignoring the >> trivial benefit that all encoders handle this with no additional code, it >> has the significant advantage that all of the stream metadata, including >> parameter sets, can be handled correctly. The handling here does rather >> badly at this - stream metadata will be misleading, and if you take one of >> these streams and try to put it into some container with global headers you >> may well end up with a quite broken file. >> > > I’m not sure I follow; your logic seems contradictory here - clearly if you > are trying to do this in a stream with global headers you’re going to run > into trouble, but during writing to such a stream whether you 1) flush, > delete and re-create, or 2) reconfigure the encoder is going to have the same > effect iand won’t change anything since it’s not the encoder writing any such > global stream headers it’s the muxer? Or did you mean something else? > > I’m using it in a server app where I want to quickly and efficiently change > the video size/bitrate of a transport stream sent over long distance either > when the remote user requests or in response to changing network conditions, > with as little disruption to the viewing experience as possible. > > For the record when this patch is used in conjunction with encoding into an > mpegts stream it plays fine in VLC/libVLC, which defects the video changes in > the stream and recreates the vout/resizes the video accordingly. > >> Given that, I think there should be some justification for why you might >> want to do this rather than following the existing approach. Some mention >> in the API (avcodec.h) to explain what's going on might be a good idea, >> since that is currently assuming that parameters like width/height are fixed >> and must be set before opening the encoder. Relatedly, if there isn't any >> support for retrieving new metadata then it should probably display a big >> warning if the user tries to make a stream like this with global headers, >> since the global headers provided to the user on startup won't actually work >> for the whole stream. >> > > I think the fact this functionality is only accessible programmatically means > that the bar would be quite high, ie the user likely knows what they are > doing, but I can certainly put a comment next to the width/height avcodecctx > members along the lines of “In some limited scenarios such as when using > nvenc the width/height can be changed during encoding and will be detected by > the encoder causing it to reconfigure itself to the new picture sIze. Extreme > care should be taken when doing this with a format that uses global headers > as the global headers will no longer correspond to the adjusted picture size!” > > Alternatively, maybe this is all a bit too obscure and it’s better left in my > own customised ffmpeg branch? That would be quite ok, although the code does > already handle dynamic bitrate and DAR changes so I figured to offer you the > patch... >
Updated patch with added comment following Mark's feedback. Regards Oliver
0001-avcodec-nvenc-Reconfigure-resolution-on-the-fly.patch
Description: Binary data
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
