[FFmpeg-devel] [PATCH] Exposing forced flag for DVD and PGS subtitles

Michael Niedermayer michaelni at gmx.at
Tue Apr 17 16:50:18 CEST 2012

On Mon, Apr 16, 2012 at 09:44:48PM +0200, Reimar Döffinger wrote:
> On 16 Apr 2012, at 12:45, Joakim Plate <elupus at ecce.se> wrote:
> > Erik Miranda <erikmiranda <at> gmail.com> writes:
> >> This patch adds a "forced" member to the AVSubtitleRect structure and 
> >> implements setting this flag in the DVD and PGS subtitle decoders, since 
> >> these are the formats I'm aware of that include such a function. Since 
> >> this patch changes AVSubtitleRect, it leads to a public API change. As 
> >> far as I can tell, this is the best method to allow access to this 
> >> information. Please advise me if otherwise, or if further changes are 
> >> required as part of changing AVSubtitleRect. I think the libavcodec 
> >> version would need a bump, correct?
> > 
> > There is already a content dispostion type for forced. That is stream
> > global thou. So one option would be to duplicate forced subs into a
> > secondary subtitle stream.
> What would be the point? What would someone do with that information except drop all non-forced ones?
> I guess it might be relevant if you want to preserve the info when reencoding.
> It should be possible to avoid the API/ABI breakage by adding an extra array to AVSubtitle instead of putting it into the AVSubtitleRect.
> Though we might consider changing the whole API so extending the rect is possible without changing the API in the future.

Is there really a ABI/API issue with adding fields to AVSubtitleRect ?
rect is a array of pointers

assuming theres no inherent problem with adding fields to
to be able to maintain compatibility with forks of ffmpeg (which we
try to currently)
a bit of extra red tape is needed see fef411ef for how it was done for
Also just grep for avcodec_get_frame_class() to see code using this

Code inside the lib declaring the AVSubtitleRect struct of course can
do direct accesses
its just applications which want to use shared libs that should avoid
direct access
This way shared libs can be exchanged between various forks in a binary
compatibile way.

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120417/5cab5907/attachment.asc>

More information about the ffmpeg-devel mailing list