On Fri, Nov 20, 2015 at 11:52 AM, Martin Storsjö <[email protected]> wrote:
> On Fri, 20 Nov 2015, Andreas Cadhalpun wrote:
>
>> On 19.11.2015 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.
>>>
>>> Vittorio
>>>
>>>  doc/APIchanges             | 3 +++
>>>  libavcodec/avcodec.h       | 6 ++++++
>>>  libavcodec/mpegvideo_enc.c | 8 ++++++++
>>>  libavcodec/version.h       | 5 ++++-
>>>  4 files changed, 21 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/doc/APIchanges b/doc/APIchanges
>>> index fbabb51..52b09ae 100644
>>> --- a/doc/APIchanges
>>> +++ b/doc/APIchanges
>>> @@ -13,6 +13,9 @@ libavutil:     2015-08-28
>>>
>>>  API changes, most recent first:
>>>
>>> +2015-xx-xx - xxxxxxx - lavc 57.9.1 - avcodec.h
>>> +  Deprecate rtp_callback in favour of AVFormat rtpenc muxer.
>>
>>
>> Does that mean opal can use the AVFormat rtpenc muxer for its purposes?
>> I'm just wondering, because you previously mentioned that there was no
>> replacement.
>
>
> The rtpenc muxer is not related to the rtp_callback whatsoever. The rtpenc
> muxer is not a replacement, and even if you used rtp_callback before, you
> still also would have used the rtpenc muxer (or an equivalent).
>
> Vittorio, how many times do we have to explain this?
>
> The rtp_callback was only a way to get one slice returned from the encoder
> at a time, without having to wait for the full frame to be encoded. You
> can't replace that with a muxer, that's just plain nonsense.

Martin, I am aware of what was explained, however rtp encapsulation
under a specific rfc is what was this is used for, at least from one
of the users. As far as I can tell, there is no trace of AVFormat in
the user code, so they are probably doing muxing manually, slice by
slice. I assumed the mentioned muxer did the same (after a frame was
encoded) hence my suggestion to use AVFormat.
If you still prefer that I completely remove any reference to
AVFormat, I'll do so.
-- 
Vittorio
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to