[FFmpeg-devel] DVB Subtitles

[JULIAN GARDNER]

----- Original Message -----
> From: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Cc: 
> Sent: Wednesday, 4 December 2013, 16:25
> Subject: Re: [FFmpeg-devel] DVB Subtitles
> 
> On Wed, Dec 04, 2013 at 03:57:14PM +0100, Reimar Döffinger wrote:
>>  On 04.12.2013, at 14:37, JULIAN GARDNER <joolzg at btinternet.com> 
> wrote:
>>  > ----- Original Message -----
>>  >> From: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
>>  >> To: FFmpeg development discussions and patches 
> <ffmpeg-devel at ffmpeg.org>
>>  >> Cc: 
>>  >> Sent: Wednesday, 4 December 2013, 14:10
>>  >> Subject: Re: [FFmpeg-devel] DVB Subtitles
>>  >> 
>>  >> On Wed, Dec 04, 2013 at 12:26:15PM +0000, JULIAN GARDNER wrote:
>>  >>>   So as you see the canvas is being set to 1280x720 where as 
> the subtitles 
>>  >> are sized for a 720x576 screen.
>>  >>>   >>2013-12-04_11:44:10.28027 [mpegts @ 0x3231f80] 
> sub2video: using 
>>  >> 1280x720 canvas
>>  >>> 
>>  >>>   There is no DDS so the subtitles are draw in the top left 
> corner and when 
>>  >> overlayed over the live video are in the wrong place and small 
> compared to the 
>>  >> video.
>>  >>> 
>>  >>>   So my 1st idea is to change the way we set the canvas size, 
> in this case it 
>>  >> would be based on 720x576 as there is no DDS.
>>  >> 
>>  >> Unfortunately my experience from MPlayer is that this will most 
> likely
>>  >> break many streams.
>>  >> I don't know whether that is a sample with or without DDS (nor 
> if it
>>  >> maybe specifies the size correctly in the stream properties), so 
> it might
>>  >> not quite demonstrate my point, but if you create any patch make 
> sure it
>>  >> will not break http://samples.mplayerhq.hu/sub/largeres_vobsub.mkv
>>  >> Remuxing that one to MPEG-TS and checking it still plays correctly 
> might
>>  >> be a good idea, too.
>>  >> I'll tell you if I manage to find any other samples.
>>  >> But in principle the assumption of missing DDS -> use video 
> size as
>>  >> canvas size seems more reasonable to me than assuming it to be in 
> SD
>>  >> resolution (again, who creates HD content with SD subtitles? That 
> must
>>  >> look like crap).
>>  >> _______________________________________________
>>  >> ffmpeg-devel mailing list
>>  >> ffmpeg-devel at ffmpeg.org
>>  >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>  >> 
>>  > 
>>  > I think the assumption is wrong on your part. DDS was added later to 
> the DVBSubtitle spec to help fix this exact problem, it was not part of the 1st 
> spec i worked with.
>> 
>>  That isn't very relevant if the DDS was added before HD streams became 
> common IMHO.
>> 
>>  > All the DVBsubtitle engines i have used base their osd drawing on a 
> standard screen UNLESS DDS is included.
>> 
>>  That is a good argument. I confused myself thinking of DVD instead of DVB 
> subtitles, I have a hard time to keep them apart, sorry.
>> 
>>  > Read Appendix B of 
> http://www.etsi.org/deliver/etsi_en/300700_300799/300743/01.03.01_60/en_300743v010301p.pdf
>>  > 
>>  > This being the one that pertains to this problem
>>  > 
>>  > "b) DVB subtitles for an HDTV service where the on-screen 
> graphics display is standard definition (720 by 576) 
>>  > and is upconverted by the receiver before being overlaid on the HDTV 
> video image:"
>>  > 
>>  > The spec talks in terms of "standard definition" which is 
> what is taken as default if no DDS is present
>> 
>>  I still find it silly to both have a HD stream _and_ not have subtitles in 
> HD _and_ not include a DDS, it seems really crappy way to do it.
>>  Still, at least the specs seems quite clear to me (though personally I 
> think they should have strongly recommended including a DDS at least for HD 
> streams where backwards-compatibility should not be much of an issue).
>>  I think that means that our decoder should set width/height to 720x576 
> unless it finds a DDS.
>>  Even that still leaves the d) case unhandled though (lower resolution 
> subtitles that should be displayed on the bottom centre instead of scaled), but 
> that would probably be more messy.
>>  Or does anyone think differently?
> 
> Unfortunately the decoder is even more broken:
>     if (!avctx->width || !avctx->height) {
>         avctx->width  = display_def->width;
>         avctx->height = display_def->height;
>     }
> 
> This means if we start out with one DDS but then the DDS changes to something 
> else,
> the context width/height will not be updated.
> The problem is: we'd really want to have probing to scan for a DDS and
> set the right values. However probing stops as soon as we set width/height.
> So how can we default to a 720x576 width/height while still having probing
> continue until a DDS is found or the limit is reached?
> Does anyone know how this should be working?
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Well the bigger problem is that these can change on the fly, so we really need a dynamic canvas, where we can change its size when needed.

joolz