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

[Tomas Härdin]

On Fri, 2010-09-24 at 19:22 -0700, Baptiste Coudurier wrote:
> 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 ?

Yes. In fact, that would be a requirement.

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

Don't know.

I've attached a patch implementing of option four. It removes the dvbsub
parser, removes the private_code stuff in the muxer and patches the
encoder and decoder to produce/handle the leading bytes.

It seems this change makes -copyinkf required when remuxing though. I
suspect this should be fixed by marking the subtitle packets as
keyframes in the demuxer , but I'm a little unsure exactly where.

The resulting files are playable in both ffplay and vlc. Finally, the
patch passes the regtests (but do any of them test subs?). It probably
constitutes a major version bump, since the parser was removed.

/Tomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dvbsub_option_4.patch
Type: text/x-patch
Size: 8837 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100928/faa0d94f/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100928/faa0d94f/attachment.pgp>