[FFmpeg-devel] Internal handling of subtitles in ffmpeg

Michael Niedermayer michaelni
Fri Dec 19 12:20:46 CET 2008


On Fri, Dec 19, 2008 at 11:00:19AM +0100, Reimar D?ffinger wrote:
> On Thu, Dec 18, 2008 at 11:39:12PM +0100, Michael Niedermayer wrote:
> > On Thu, Dec 18, 2008 at 11:32:01PM +0100, Reimar D?ffinger wrote:
> > > On Thu, Dec 18, 2008 at 11:12:31PM +0100, Michael Niedermayer wrote:
> > > > What you suggest is _exactly_ what i want and what the original author
> > > > suggested (if i understood it correctly) but with different terminology
> > > > 
> > > > yours:
> > > > ASS -(decoder)-> bitmap
> > > > text_in_bitstream -(bitstream filter)-> ASS
> > > > ASS -(bitstream filter)-> text_in_bitstream
> > > > 
> > > > mine:
> > > > ASS -(renderer)-> bitmap
> > > > text_in_bitstream -(decoder)-> ASS
> > > > ASS -(encoder)-> text_in_bitstream
> > > 
> > > Well, possibly, but I think my terminology matches the existing code
> > > better,
> > 
> > the mplayer code yes, ffmpeg very certainly not.
> 
> Uh, no, it does not match MPlayer at all, in MPlayer the
> renderer/decoders are filters, and the decoder/bitstream filters
> is just a big ugly blob of code.
> 
> > > there is an actual bitstream filter to convert between mov and
> > > plain text text subtitles
> > 
> > >, and the subtitle "renderers" are called
> > > decoders right now.
> > 
> > huh?
> > which of our decoders converts text to bitmaps?
> 
> _text_ to bitmaps no, but _subtitles_ to bitmaps yes.

yes but the decoders just extract what is stored in the subtitles
and all we have decoders for, store bitmaps.


> 
> > our decoders output the vector based graphics when such are stored in the
> > format.
> > For text based formats the logic extension is to export the text ...
> > this needs a char* to be added to AVSubtitleRect and filled by the decoder
> 
> Well, that's one of the questions. Going by what I heard in some
> discussions it would be appropriate to call ASS subtitles a highly compressed
> representation of bitmaps and thus have it decode to bitmaps (yes, it
> is a bit silly - though I'll also add that IIRC the sucessor of ASS
> supports embedded images, calling something that may discard about
> 90% of the content would match even the term "encoder" better than
> "decoder")...
> Also I don't see how that fits particularly well in the current scheme,
> since the one "to text" "decoder" in existence currently is a bitstream
> filter.
> Anyway, not saying which one is better and I don't think I care much,
> I just think that things are not as obvious as you think...

i really cant follow your reasoning, actually i dont even understand what
you reason about.
the subtitle decoders are supposed to output what is stored in the bitstream
in a decompressed and generic repressentation.
this repressentation can contain bitmaps as well as pieces of text,
a subtitle decoder outputs a AVSubtitle which contains several AVSubtitleRect
each of these could be a bitmap, or text (text isnt supported yet).
If a ASS supports bitmaps in addition to text this would not even need a
change to what i suggested. The output of our subtitle
decoders IS vector based and always was, there is no issue with mixing
text and graphics.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081219/afd00008/attachment.pgp>



More information about the ffmpeg-devel mailing list