[FFmpeg-devel] [libav-devel] [PATCH 2/2] lavf: move internal fields from public to internal context
wm4
nfxjfg at googlemail.com
Wed Mar 4 21:14:57 CET 2015
On Wed, 4 Mar 2015 21:05:04 +0100
Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> On Wed, Mar 4, 2015 at 8:59 PM, wm4 <nfxjfg at googlemail.com> wrote:
> > On Wed, 04 Mar 2015 20:21:26 +0100
> > Andreas Cadhalpun <andreas.cadhalpun at googlemail.com> wrote:
> >
> >> Hi,
> >>
> >> On 06.02.2015 14:53, wm4 wrote:
> >> > This is not an API change; the fields were explicitly declared private
> >> > before.
> >>
> >> Unfortunately XBMC is using these semi-private fields, so it gets broken by this
> >> change. Therefore I think it would be better to postpone this until after a
> >> SOVERSION bump.
> >>
> >> Looking a bit closer at the source [1], it seems XBMC uses this only to provide
> >> a ff_read_frame_flush equivalent called xbmc_read_frame_flush.
> >>
> >> To avoid having to do that in XBMC I suggest to rename ff_read_frame_flush back
> >> to av_read_frame_flush and add it to the public API. Thoughts?
> >>
> >
> > I don't think this is a valid excuse. Tell XBMC to fix their code.
>
>
> I agree. API explicitly marked as private needs to be possible to be
> changed at any time, or our development is severly impaired.
This may be in conflict with the FFmpeg philosophy /sarcasm.
> Doesn't XBMC use a private copy of ffmepg anyway? They can adapt by
> the time they update it.
Yep.
> Also, instead of just making some function public, maybe someone
> should bother to explain why we would need it?
Flushing the demuxer can actually be useful. I even sent a patch once,
but apparently it went nowhere. It still can be simulated with a byte
seek to the current position, though.
More information about the ffmpeg-devel
mailing list