[FFmpeg-devel] [PATCH] Text subtitle decoder

[Tomas Härdin]

On Sun, 2010-11-28 at 22:52 +1100, Peter Ross wrote:
> On Sat, Nov 27, 2010 at 06:16:45PM +0100, Aurelien Jacobs wrote:
> > On Sat, Nov 27, 2010 at 09:43:01PM +1100, Peter Ross wrote:
> > > $subject (Purging my patch queue.)
> 
> > > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> > > index fbae0f6..3aa28b2 100644
> > > --- a/libavcodec/allcodecs.c
> > > +++ b/libavcodec/allcodecs.c
> > > @@ -346,6 +346,7 @@ void avcodec_register_all(void)
> > >      REGISTER_ENCDEC  (DVBSUB, dvbsub);
> > >      REGISTER_ENCDEC  (DVDSUB, dvdsub);
> > >      REGISTER_DECODER (PGSSUB, pgssub);
> > > +    REGISTER_ENCDEC  (TEXT, text);
> > 
> > ENCDEC ???
> 
> Noted.
> 
> > > diff --git a/libavcodec/text.c b/libavcodec/text.c
> > > new file mode 100644
> > > index 0000000..5876a94
> > > --- /dev/null
> > > +++ b/libavcodec/text.c
> > > @@ -0,0 +1,61 @@
> 
> > > +    sub->end_display_time   = pts + 500;
> > 
> > Why pts + 500 ???
> 
> There is no 'end' time.
> 
> > More generally, what is this decoder useful for ?
> > Currently, there are only 3 demuxers which produce CODEC_ID_TEXT streams:
> > matroska, nut and ogm.
> > For both matroska and ogm this is plain wrong to use CODEC_ID_TEXT, as
> > those streams contains in fact SubRip formated text (including some html
> > like formatting, like <b>, <font size="20">, etc...). I will fix both of
> > them very soon now, so that they output CODEC_ID_SRT instead.
> > So this will leave us with nut as the only demuxer producing
> > CODEC_ID_TEXT. I don't know if this type of track is really used in
> > actual files, and if it is a good idea to support this kind "codec"
> > that is used nowhere else, but my gut feeling says that we should just
> > drop CODEC_ID_TEXT entirely.
> 
> Its a toy, tested with some sample Matroska files containg UTF-8 text.
> If nothing more, it highlights that CODEC_ID_TEXT is inadequate.
> 
> btw, have you had any thoughts one subtitle format conversion API,
> e.g. converting SUBTITLE_ASS to SUBTITLE_BITMAP, for display in FFmpeg.

Wouldn't something like this fit in libavfilter? If I understand
correctly, it's already possible to have a filter that takes audio and
produces video or vice versa, so adding support for filtering subtitle
media would make sense. That way you could have one filter render the
text into graphics rects, while another does the blending. This would
allow simplifying ffplay and allowing hardsubbing in ffmpeg.

Also, one could create an OCR filter using some existing library to do
the inverse of the above.

/Tomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101129/46b6d2ec/attachment.pgp>