[FFmpeg-devel] [libav-devel] [PATCH 2/2] lavf: move internal fields from public to internal context

Andreas Cadhalpun andreas.cadhalpun at googlemail.com
Wed Mar 4 21:49:17 CET 2015


On 04.03.2015 21:14, wm4 wrote:
> 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:
>>>> 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.

It's no excuse, but a problem that has to be solved one way or another.
And making ff_read_frame_flush public is the easiest fix, isn't it?

>> I agree. API explicitly marked as private needs to be possible to be
>> changed at any time, or our development is severly impaired.

That's true, but it's not entirely XBMC's fault, since the function was
called av_read_frame_flush first (as if it was public) and only later
renamed. (They shouldn't have worked around that by using other private
functions, though.)

> 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.

At least in Debian it luckily doesn't use that, but instead the shared
libraries.

>> 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.

So what do you think about resurrecting this patch (add avformat_flush)?
It seems to have only stalled on the associated documentation and the
XBMC developers are apparently not the only ones who would find it useful.

Best regards,
Andreas


More information about the ffmpeg-devel mailing list