[FFmpeg-devel] BUG in use of extradata and extradata_size with dvb subtitles and teletext

Marton Balint cus at passwd.hu
Thu Jan 30 23:54:23 CET 2014


On Wed, 29 Jan 2014, Andriy Lysnevych wrote:

> On Tue, Jan 28, 2014 at 1:33 PM, Dominguez Bonini, David
> <david.dominguez at ikusi.com> wrote:
>> Hi,
>>
>> I have some experience with DVB subtitling decoders outside of the FFMPEG context, but I think I have useful input on this issue.
>>
>>
>>>
>>> Hi,
>>>
>>> I agree with all Marton's comments and will release fixed patches shortly. I
>>> want to discuss only this point:
>>>
>>>> In case of combined streams wouldn't it make sense to set the
>>> composition_id and ancillary_id to the ids of the first entry?
>>>
>>> In documentation I found the following description:
>>>
>>> The composition page carries the segments unique to a single subtitle
>>> stream. It includes the page composition, region composition, CLUT
>>> definition, and object data segments (cf. Figure 5). The ancillary page is an
>>> optional page, which can be used to carry CLUT definition and object data
>>> segments that could be shared by more than one subtitle streams. For
>>> example, it could be used to carry logos or character glyphs, or to carry
>>> objects that are common to two or more subtitle streams.
>>>
>>> I don't know how DVB subtitles decoder behaves in case of multiple
>>> subtitling sub-streams in single DVB subtitle stream. But there are two ways:
>>>
>>> a) If we will set composition and ancillary IDs to values from first subtitle
>>> descriptor then because of this condition:
>>>
>>> if (page_id == ctx->composition_id || page_id == ctx->ancillary_id ||
>>>             ctx->composition_id == -1 || ctx->ancillary_id == -1) {
>>>
>>> Only first DVB subtitle sub-stream will be processed by decoder, all other will
>>> be ignored.
>>
>> This is what is done on practically all DVB SUB decoders, you select a composition/ancillary pair from the PMT subtitling descriptor and init the decoder with them. Which pair you select depends on the language selection on your STB or software decoder.
>>
>>>
>>> b) If we set them to -1 then all sub-streams will be processed, but result is
>>> not predictable for me because I have no such stream to test with the
>>> decoder.
>>>
>>
>> This option will result in not useful results or outright crashes with most subtitling streams, basically because you are trying to draw several subtitling streams over the same "canvas". The regions used by the different composition IDs overlap. If you must render all composition IDs, you have two options in my opinion:
>>  1) Draw each composition ID to an independent output canvas/OSD layer/whatever
>> 2) Assign different screen regions to each subtitling stream and shift/scale the output region coordinates accordingly. This is perfectly possible, though why you would want to do it is debatable. A software that did something like this (though not with DVB SUBs) is PowerDVD, which allowed the display of two different subtitling streams, it displayed one stream on the topof the screen and the other on the bottom. It was hideous in my opinion.
>>
>>> What option is preferable? Is there any support of decoding/displaying
>>> subtitles from streams with multiple subtitling sub-streams (DVB subtitles or
>>> DVB teletext subtitles) in FFmpeg?
>>>
>>> Regards,
>>> Andriy Lysnevych
>
> Thanks for your comments. I decided to use always first substream of
> DVB subtitles in decoder. In future it is possible to implement
> ability to configure sub-stream index that should be decoded by DVB
> subtitles decoder.
>
> In case of copy DVB subtitles scenario all sub-streams will be copied.
>
> Please review the patches.

There is still one compatibility issue, I think the mpegts muxer should 
also support the old style 4-byte extradata. After that you should split 
the muxer and the demuxer part just like you did for the teletext.

Since the extradata is extended, probably you should increase 
LIBAVFORMAT_VERSION_MICRO in the demuxer patch.

Also please use "git send-email" for sending patches.

Thanks,
Marton


More information about the ffmpeg-devel mailing list