On Fri, Nov 26, 2021 at 4:09 PM Andreas Rheinhardt
<andreas.rheinha...@outlook.com> wrote:
>
> Soft Works:
> > Also introduce deferred loading of ass headers for all cases where it can't
> > be taken from the context of a decoder.
>
> This should be a commit of its own.
>
> >
> > Signed-off-by: softworkz <softwo...@hotmail.com>
> > ---
> > libavcodec/assenc.c | 81 ++++++++++++++++++++---------
> > libavcodec/avcodec.h | 7 +++
> > libavcodec/dvbsubenc.c | 85 +++++++++++++++---------------
> > libavcodec/dvdsubenc.c | 89 +++++++++++++++++---------------
> > libavcodec/encode.c | 98 ++++++++++++++++++++++++++++++++++-
> > libavcodec/movtextenc.c | 103 +++++++++++++++++++++++++------------
> > libavcodec/srtenc.c | 96 ++++++++++++++++++++++------------
> > libavcodec/tests/avcodec.c | 2 -
> > libavcodec/ttmlenc.c | 82 +++++++++++++++++++++++------
> > libavcodec/webvttenc.c | 73 +++++++++++++++++++-------
> > libavcodec/xsubenc.c | 65 ++++++++++++-----------
> > 11 files changed, 541 insertions(+), 240 deletions(-)
> >
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index 0c5819b116..304b35ba86 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -2949,10 +2949,17 @@ void av_parser_close(AVCodecParserContext *s);
> > * @{
> > */
> >
> > + /**
> > + * @deprecated Use @ref avcodec_encode_subtitle2() instead.
> > + */
> > +attribute_deprecated
> > int avcodec_encode_subtitle(AVCodecContext *avctx, uint8_t *buf, int
> > buf_size,
> > const AVSubtitle *sub);
> >
> >
> > +int avcodec_encode_subtitle2(AVCodecContext* avctx, struct AVPacket* avpkt,
> > + AVFrame* frame, int* got_packet);
> > +
>
> Missing documentation. The signature and the implementation shows that
> you have recreated the old encode API avcodec_encode_(audio2|video2)
> with the difference that you (like the current subtitle API) require
> preallocated (not necessarily refcounted) buffers in avpkt. Why not use
> the ordinary encode API?
I concur on that question. We have a generic encode/decode API without
dependency on any media type, that should be used going forward for
all media types, and not anything else being introduced now.
- Hendrik
_______________________________________________
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".
