On 11/6/2017 9:19 AM, Timo Rothenpieler wrote:
> Am 05.11.2017 um 14:35 schrieb James Almer:
>> On 11/5/2017 9:34 AM, Michael Niedermayer wrote:
>>> This gives libavcodec a field that it can freely and safely use.
>>> Avoiding the need of wraping of a users opaque_ref field and its issues.
>>
>> Co
I would prefer if this field would not be library-specific, but
perhaps just "private_ref" which is not allowed to be touched by
users, and documented to only be valid while within one library - ie.
if you pass a frame from avcodec to avfilter, avfilter could take over
the field (and just free any
Am 05.11.2017 um 14:35 schrieb James Almer:
On 11/5/2017 9:34 AM, Michael Niedermayer wrote:
This gives libavcodec a field that it can freely and safely use.
Avoiding the need of wraping of a users opaque_ref field and its issues.
Could this perhaps be in an opaque internal struct instead, muc
On 11/5/2017 12:25 PM, Michael Niedermayer wrote:
> On Sun, Nov 05, 2017 at 02:52:50PM +0100, Hendrik Leppkes wrote:
>> On Sun, Nov 5, 2017 at 1:34 PM, Michael Niedermayer
>> wrote:
>>> This gives libavcodec a field that it can freely and safely use.
>>> Avoiding the need of wraping of a users opa
On Sun, Nov 5, 2017 at 7:08 PM, Rostislav Pehlivanov
wrote:
> On 5 November 2017 at 13:52, Hendrik Leppkes wrote:
>
>> On Sun, Nov 5, 2017 at 1:34 PM, Michael Niedermayer
>> wrote:
>> > This gives libavcodec a field that it can freely and safely use.
>> > Avoiding the need of wraping of a users
On 5 November 2017 at 13:52, Hendrik Leppkes wrote:
> On Sun, Nov 5, 2017 at 1:34 PM, Michael Niedermayer
> wrote:
> > This gives libavcodec a field that it can freely and safely use.
> > Avoiding the need of wraping of a users opaque_ref field and its issues.
> >
> > Signed-off-by: Michael Nied
On Sun, Nov 05, 2017 at 02:52:50PM +0100, Hendrik Leppkes wrote:
> On Sun, Nov 5, 2017 at 1:34 PM, Michael Niedermayer
> wrote:
> > This gives libavcodec a field that it can freely and safely use.
> > Avoiding the need of wraping of a users opaque_ref field and its issues.
> >
> > Signed-off-by: M
On Sun, Nov 05, 2017 at 10:35:06AM -0300, James Almer wrote:
> On 11/5/2017 9:34 AM, Michael Niedermayer wrote:
> > This gives libavcodec a field that it can freely and safely use.
> > Avoiding the need of wraping of a users opaque_ref field and its issues.
>
> Could this perhaps be in an opaque i
On Sun, Nov 5, 2017 at 1:34 PM, Michael Niedermayer
wrote:
> This gives libavcodec a field that it can freely and safely use.
> Avoiding the need of wraping of a users opaque_ref field and its issues.
>
> Signed-off-by: Michael Niedermayer
> ---
> libavutil/frame.c | 8 +++-
> libavutil/fra
On 11/5/2017 9:34 AM, Michael Niedermayer wrote:
> This gives libavcodec a field that it can freely and safely use.
> Avoiding the need of wraping of a users opaque_ref field and its issues.
Could this perhaps be in an opaque internal struct instead, much like
AVCodecInternal and whatnot? As wm4 s
10 matches
Mail list logo