FFmpeg

110368 Commits

37 Branches

400 Tags

492 MiB

Tag: Branch: Tree: cd30492773

Commit Graph

Author	SHA1	Message	Date
Clément Bœsch	77eeaa2c3d	lavf/srtdec: rewrite parsing logic Fixes Ticket #5032 The samples in Ticket #5032 is using \r\r\n as line breaks. Since we already are handling \r, or \n, or \r\n as line breaks, \r\n\n will be considered as a double line breaks. This is an issue because ff_subtitles_read_text_chunk() will as a result stop extracting a chunk after just one line. So instead of parsing the SRT by "chunks" (which means splitting every double LB), this new parser is detecting timing lines, and split the events on this basis. While this sounds safe and simple, it needs to take into account the event number preceding the timing line while handling situations such as: - event number starting at 0 or actually any number instead of 1 - event numbers not being ordered at all - event number being followed by text garbage (this really happened, see Ticket #4898) - event payload containing one or multiple number (a protagonist saying a count-down, a date or whatever) which could be confused with a chapter number - event number being empty (see Ticket #2167) - all kind of weird line breaks can appear randomly like wild pokémons - untrustable line breaks (Ticket #5032) The sample madness.srt tries to sum up most of this into one sample, ticket5032-rrn.srt is the file containing \r\r\n line breaks. and empty-events-2167.srt contains empty events.	9 years ago

Author

SHA1

Message

Date

Clément Bœsch

77eeaa2c3d

lavf/srtdec: rewrite parsing logic

Fixes Ticket #5032

The samples in Ticket #5032 is using \r\r\n as line breaks.  Since we
already are handling \r, or \n, or \r\n as line breaks, \r\n\n will be
considered as a double line breaks. This is an issue because
ff_subtitles_read_text_chunk() will as a result stop extracting a chunk
after just one line.

So instead of parsing the SRT by "chunks" (which means splitting every
double LB), this new parser is detecting timing lines, and split the
events on this basis. While this sounds safe and simple, it needs to
take into account the event number preceding the timing line while
handling situations such as:

 - event number starting at 0 or actually any number instead of 1
 - event numbers not being ordered at all
 - event number being followed by text garbage (this really happened,
   see Ticket #4898)
 - event payload containing one or multiple number (a protagonist saying
   a count-down, a date or whatever) which could be confused with a
   chapter number
 - event number being empty (see Ticket #2167)
 - all kind of weird line breaks can appear randomly like wild pokémons
 - untrustable line breaks (Ticket #5032)

The sample madness.srt tries to sum up most of this into one sample,
ticket5032-rrn.srt is the file containing \r\r\n line breaks. and
empty-events-2167.srt contains empty events.

9 years ago

1 Commits (cd3049277343abd336f941e07549727d6e1b3ed8)