On 19/11/15 09:45, Vittorio Giovara wrote: > 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, or a somewhat hacky way to store h263 in RFC-2190 > rtp encapsulation. > > 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. Libavformat features a complete > implementation of RFC-2190, for any other case. > > Signed-off-by: Vittorio Giovara <[email protected]> > --- > I received more feedback from Opal, so I mentioned their usecase in > the commit log. Also added APIchange entry as Andreas requested.
Still fine for me. lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
