[FFmpeg-devel] [PATCH/RFC] Fix dvbsub framing inconsistencies/add dvbsub bsf

Baptiste Coudurier baptiste.coudurier
Sat Sep 25 04:22:10 CEST 2010


On 09/24/2010 07:28 AM, Tomas H?rdin wrote:
> Hi
>
> As you may know from IRC and my last thread on this list, I'm working on
> fixing mpegts subtitle remuxing. The extradata problem was easy enough
> to fix, but while writing the bitstream filter I discovered some
> inconsistencies regarding the framing bytes surrounding the data the
> decoder wants.
>
> Since I don't have the specs at hand, I have been figuring this out by
> looking at the code and hex dumps, and testing my results in ffplay and
> vlc.
>
> I'll be using a PES packet containing 14 B of subtitle essence data as
> an example. It looks like this:
>
> 00 00 01 BD 00 19 85 80 05 21 01 AB 9D CD
> 20 00 0F 10 00 02 00 02 01 94 0F 80 00 02 00 00 FF
>
> That second line (20 00 ... FF) is what the demuxer outputs. That gets
> stripped by dvbsub_parser to the fourteen bytes below:
>
> 0F 10 00 02 00 02 01 94 0f 80 00 02 00 00
>
> This is the format that the decoder expects (starts with 0x0F). However,
> this is not what the dvbsub encoder outputs. See dvbsub.c lines 211 and
> 387
>
>      *q++ = 0x00; /* subtitle_stream_id */
>
>      /* page composition segment */
>
>      *q++ = 0x0f; /* sync_byte */
>      *q++ = 0x10; /* segment_type */
>
> ...
>
>      *q++ = 0xff; /* end of PES data */
>
> In other words, the output from the encoder can not be fed into the
> decoder. It also does not match what is output by the parser, but you
> could also say that the parser's output does not match the encoder's.
>
> Since the output from the encoder is typically fed straight to a muxer,
> the missing 0x20 byte needs to be written before the data is written.
> The hackish code relating to private_code in mpegtsenc.c takes care of
> this:
>
>      if (st->codec->codec_type == AVMEDIA_TYPE_SUBTITLE) {
>          private_code = 0x20;
>      }
>
> ...
>
>      if (private_code != 0)
>          *q++ = private_code;
>
> As I understand it, there are a number of ways to fix this:
>
> 1. Add a bitstream filter that adds a 0x00 to the start and 0xFF to the
> end of the subtitle packets

Overkill IMHO.

> 2. Make the encoder not add said bytes and require its output to be fed
> to a bitstream filter that adds 20 00 .. FF (to which the parsed packets
> are also fed). This allows simplifying the muxer (remove the
> private_code stuff)
> 3. Patch the decoder to accept leading null bytes, and have the parser
> only strip the leading 0x20 byte
> 4. Remove the parser and the muxer hack and have the encoder output
> packets with the 20 00 .. FF framing and accept them in the decoder

I like 4), and you can also remove the the private code stuff in 
mpegtsenc.c right ?

I guess there are other dvbsub decoders around ? What input do they expect ?

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org



More information about the ffmpeg-devel mailing list