[FFmpeg-devel] [RFC] General design for subtitles demuxers

[Clément Bœsch]

On Wed, Jun 13, 2012 at 08:34:23PM +0200, Nicolas George wrote:
> Le sextidi 26 prairial, an CCXX, Clément Bœsch a écrit :
> > Thanks for the hint, that could do the trick, but unfortunately sorting
> > the entries will be more complex: AVPacketList, as the name suggests, is a
> > list, and not an array, so you need something more complicated than just
> > using qsort() to sort the events.
> > 
> > I though about adding a insert_sort flag add_to_pktbuf(), but that won't
> > work because the durations must be set on the unsorted list.
> > 
> > IMO it's simpler to create an array, set a simple loop to set the
> > durations, and then qsort() the array.
> 
> Writing a merge sort for a linked list is very easy.
> 
> But reusing a data structure for the sake of reusing it would be silly. You
> should, obviously, write the code the way you think it simpler.
> 

Yes, but actually, even AVPacket is not a good way of storing the demuxed
subtitles events; the proposed design was to make a list of AVPacket in
read_header() and then incrementally raise them in read_packet(). But
doing this means we can't support seek simply; imagine the following:

  demux 5 packets, seek 3 packets backward, demux 5 packets

The "user" code responsible for the first 5 demux will free the packets,
so we need in read_packet() to copy the data in the AVPacket from the
internal list, with the necessary padding etc. This is complex for
nothing, so I started with a simple struct similar to what I've done in
JACOsub demuxer (SubEvent). And I'm going to use this API for MicroDVD and
ASS demuxers, as stated in the original message.

BTW, this makes me wonder if we should store at all the timing information
in the packet demuxer: if we do that, we won't be able to do something
like: ffmpeg -i input.srt -ss 00:02:31 -c copy output.srt. So I withdraw
my proposition of having two "formats" of packets (one with the timing and
the other without): all the timing information should be in the AVPacket,
and the muxer should use that. The question is how we will deal with the
current state, but we can discuss this later.

I plan to send a patchset for all of this this week end, with the SAMI
patch reworked.

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120614/f3fcebd1/attachment.asc>