On Wed, Oct 28, 2015 at 7:19 PM, Martin Storsjö <[email protected]> wrote: > On Wed, 28 Oct 2015, Vittorio Giovara wrote: > >> On Wed, Oct 28, 2015 at 4:05 PM, Luca Barbato <[email protected]> wrote: >>>> >>>> >>>> Signed-off-by: Vittorio Giovara <[email protected]> >>>> --- >>>> libavcodec/avcodec.h | 6 ++++++ >>>> libavcodec/mpegvideo_enc.c | 8 ++++++++ >>>> libavcodec/version.h | 3 +++ >>>> 3 files changed, 17 insertions(+) >> >> >> amended: >> >> This function returns the encoded data of a frame, one slice at a time >> directly when that slice is encoded, instead of waiting for the full >> frame to be done. >> >> The usefulness of this field is debatable, the name is misleading, as it >> isn't >> rtp-specific in any way, and it looks like it is >> mainly a convoluted way to get data at lowest possible latency, and >> only when transmitting over RTP (despite not being enforced by any means). > > > You're still contradicting yourself - first you say it isn't rtp-specific, > but then you say you could only use it when transmitting over RTP. > > You could use this approach with any transport protocol where you can start > sending individual slices before the full frame is available.
umh right, would the following sound better? This function returns the encoded data of a frame, one slice at a time directly when that slice is encoded, instead of waiting for the full frame to be done. However this field has a debatable usefulness, since it looks like it is just a convoluted way to get data at lowest possible latency, and has a very misleading name, as it isn't rtp-specific in any way. Moreover when multi-threading is enabled (which is by default) the order of returned slices is not deterministic at all, making the use of this function not reliable at all (or at the very least, more complicated than it should be). So, for the reasons stated above, and being used by only a single encoder family (mpegvideo), this field is deemed unnecessary, overcomplicated, and not really belonging to libavcodec. -- Vittorio _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
