[FFmpeg-devel] DVB Subtitles
Reimar Döffinger
Reimar.Doeffinger at gmx.de
Wed Dec 4 16:56:33 CET 2013
On Wed, Dec 04, 2013 at 04:42:50PM +0100, Michael Niedermayer wrote:
> On Wed, Dec 04, 2013 at 04:25:00PM +0100, Reimar Döffinger wrote:
> > 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?
>
> one way would be to set the default immedeatly and make the code
> use a different stop condition for DVB subtites
Obviously :-) But the question is what would be a good way?
Actually I think that just setting the default immediately
should be ok as well, it's just that if ffmpeg doesn't support
subtitle "resolution" changes it will break its DVB support fairly
thoroughly.
Do we have any test streams for this?
More information about the ffmpeg-devel
mailing list