[FFmpeg-trac] #1924(avformat:closed): ASS subtitles are demuxed inconsistently
FFmpeg
trac at avcodec.org
Sat Nov 17 13:50:35 CET 2012
#1924: ASS subtitles are demuxed inconsistently
-------------------------------------+------------------------------------
Reporter: gjdfgh | Owner:
Type: enhancement | Status: closed
Priority: normal | Component: avformat
Version: unspecified | Resolution: invalid
Keywords: ass | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+------------------------------------
Comment (by gjdfgh):
About the packet format: it's certainly a bit odd that SRT subs don't have
time codes inline, while ASS subs do. Note that there's also the "layer"
field before the time codes (the first number). The Matroska-internal
format eliminates the redundant time codes, and adds the ReadOrder field.
On the other hand, the current ffmpeg packet format is a bit easier to
understand and more intuitive at first.
Here's a suggestion: at least, ASS packets could perhaps have the duration
field set, and the ReadOrder (matroska files) / event index (ASS files)
could be separately exported. (Maybe an additional packet field?)
I have no idea what the ReadOrder field is about. Looking at libass, it
looks like a fully demuxed ASS file might behave differently from muxed
subs that are fed per-packet as they are demuxed from an interleaved
stream.
Aside from using the ReadOrder field to eliminate duplicate events (i.e.
packets that have been fed to libass more than once, as all events are
stored permanently), this is the only use of the ReadOrder field I could
find:
http://repo.or.cz/w/libass.git/blob/c207000c7cdde335679b53a8cffc22bef61ffa45:/libass/ass_render.c#l2274
Also, note that ass_process_chunk() might be faster than
ass_process_data(), as the latter has to search for plain text rather than
comparing the ReadOrder field to eliminate duplicate events. ReadOrder
acts as unique packet identifier here.
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1924#comment:5>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list