[FFmpeg-devel] Format of decoded subtitles (was: matroska: Identify S_TEXT/UTF-8 tracks as SRT and not TEXT.)

[Michael Niedermayer]

On Thu, May 31, 2012 at 05:07:33PM +0200, Nicolas George wrote:
> Le sextidi 6 prairial, an CCXX, Clément Bœsch a écrit :
> > So if I understand well, you would propose a model with libsubconvert
> > doing any kind of markup conversion instead of the current model where the
> > decoder is "encoding" the event in ASS, bitmap or text?
> 
> Well, it does not need to be a separate library per se, but I really think
> we need some kind of:
> 
> 	ctx = avsub_markup_convert_init(ASS, HTML);
> 	avsub_markup_convert(ctx, sub_ass, sub_html);
> 
> or something.
> 

> > It should, for text-based subtitles. At least for the "useful" markup. But
> > I admit ASS has some annoying limitations, especially with some particular
> > subtitles features:
> > 
> >  - the first one I have in mind is that there is no text representation
> >    for the "last up to the next subtitles" feature. Example: MicroDVD (and
> >    SAMI which I'm working on ATM) have features like this:
> > 
> >    {500}{600}this is printed starting at frame 500 and last until frame 600
> >    {1234}{}this starts being displayed at frame 1234...
> >    {1400}{}...and will be "replaced" by this text until the end.
> > 
> >    We can express this in the AVPacket (pkt.duration = -1 for example),
> >    but to encode the ASS event, it's not possible to have 00:01:02:03
> >    -1:-1:-1:-1 for instance. So we need to workaround this.
> 
> I am not sure I follow you: this is not markup, this is timing, and IMHO,
> timing belongs in the demuxer and should be decoded by it. For the example,
> the demuxer should output packets like that:
> 
>   { .pts =  500, .duration = 100, .data = "this is printed starting..." },
>   { .pts = 1234, .duration = 166, .data = "this starts being displayed..." },
>   { .pts = 1400, .duration = PTS_MAX - 1400, .data = "...and will..." },

not taking any sides in this discussion but rather trying to provide
some additional information/viewpoint

mpeg/h26* tend to contain some form of timestamps and durations in
the video stream

in mpeg-ps/ts many frames (up to 0.5 seconds) can be in a single
piece of bytestream without any headers between at the muxer level.
the timing in this case is clearly in the video stream
we split things up in frames, decode the timing and put it in
AVPackets.*  but we do not remove anything from AVPacket.data.
simply concatenating the AVPacket.data would restore the complete
elementary video stream with duration information on the frames/fields

[...]


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120531/09377fad/attachment.asc>