[FFmpeg-devel] DVB Subtitles

[Reimar Döffinger]

On Wed, Dec 04, 2013 at 03:41:43PM +0000, JULIAN GARDNER 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, 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?
> 
> 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.

I see no big problem there, we support resolution changes for video already.
And applications like MPlayer should support canvas changes as well.
If ffmpeg doesn't that is a bug, however IMHO not one specific to DVB.
Or a less trollish reply: Either way the DVB decoder needs to be fixed
first.