On Wed, 4 Mar 2015 21:05:04 +0100 Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Wed, Mar 4, 2015 at 8:59 PM, wm4 <nfx...@googlemail.com> wrote: > > On Wed, 04 Mar 2015 20:21:26 +0100 > > Andreas Cadhalpun <andreas.cadhal...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
