[FFmpeg-devel] [PATCH] add avsubtitle_free

Reimar Döffinger Reimar.Doeffinger
Sun Jul 11 00:05:12 CEST 2010

On Sat, Jul 10, 2010 at 11:06:19PM +0200, Michael Niedermayer wrote:
> On Sat, Jul 10, 2010 at 10:59:17PM +0200, Reimar D?ffinger wrote:
> > Well, I think subtitles have enough complexities, also due to
> > num_rects a get_buffer/release_buffer would have to support a lot
> > more "outstanding" frames than for video, so it would be different
> > anyway.
> ok but please document this difference between video & subtitles somewhere
> explicitly with the reasoning. Otherwise people might use it to say the
> api design is an inconsistant mess

Where and how? Something like this?
I on purpose did not document whether get_buffer is called or, that's
something internal IMO.
Index: libavcodec/avcodec.h
--- libavcodec/avcodec.h        (revision 24159)
+++ libavcodec/avcodec.h        (working copy)
@@ -3542,15 +3542,23 @@
  * Return a negative value on error, otherwise return the number of bytes used.
  * If no subtitle could be decompressed, got_sub_ptr is zero.
  * Otherwise, the subtitle is stored in *sub.
+ * Note that CODEC_CAP_DR1 is not available for subtitle codecs. This is for
+ * simplicity, because the performance difference is expect to be negligible
+ * and reusing a get_buffer written for video codecs would probably perform badly
+ * due to a potentially very different allocation pattern.
  * @param avctx the codec context

> > Also more than one subtitle frame per second is unrealistic, which
> > means that efficiency is not that important and P-frames are unlikely
> > to be used since that works too bad with seeking.
> depends, ive seen songs with lyrics in subtitles that showed effects
> per letter and that surely where more updates than 1 per second

True, it might be that things change somewhen in the future.
Although it might be that if so, it will be implemented using a
regular video codec. To me it feels like the kind of thing you better
update the API for when you have a real-world sample to test.

More information about the ffmpeg-devel mailing list