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

Nicolas George nicolas.george at normalesup.org
Fri Jun 15 16:08:08 CEST 2012


Le septidi 27 prairial, an CCXX, Clément Bœsch a écrit :
> 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.

Note that AVPacket is freed through a "destruct" method that can do various
things instead of free()ing the data. It is used by v4l2 to return memory
buffers mmaped from the device directly, for example.

I am not sure if it can make things simpler, especially with such small
packets as subtitles, but it bears reminding.

>						 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.

Thanks for your work.

> 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 second that with pleasure.

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

Thanks.

Regards,

-- 
  Nicolas George
-------------- 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/20120615/5c6f5207/attachment.asc>


More information about the ffmpeg-devel mailing list