On Wed, 11 May 2016 19:57:19 +0200
Michael Niedermayer wrote:
> On Thu, May 05, 2016 at 01:45:55AM +0100, Derek Buitenhuis wrote:
> > I am not at all opposed to the idea. I just don't think the current way
> > of using internal headers, structs, and APIS (and a wrapper main()) should
> > at all
On Thu, May 05, 2016 at 01:45:55AM +0100, Derek Buitenhuis wrote:
> On 5/5/2016 1:26 AM, Michael Niedermayer wrote:
> > It was possible to write and register external protocols, codecs,
> > (de)muxers,... in the distant past.
>
> Was there even a such thing as a public API at the time? ;)
There w
On Thu, 5 May 2016 02:26:09 +0200
Michael Niedermayer wrote:
> > This is quite a hack, and we should not add new APIs to support it, in
> > my opinion. I think you will have a hard time finding support in an open
> > source project for adding or re-adding APIs to make internal forks easier
> > to
On 5/5/2016 1:26 AM, Michael Niedermayer wrote:
> It was possible to write and register external protocols, codecs,
> (de)muxers,... in the distant past.
Was there even a such thing as a public API at the time? ;)
> i always liked to allow and support "Plugins" / externally registering
> stuff, b
On Thu, May 05, 2016 at 12:29:11AM +0100, Derek Buitenhuis wrote:
> On 5/4/2016 11:58 PM, Thierry Foucu wrote:
> >> Can i ask why it cannot be part of the public API?
>
> See answer below.
>
> >> It was really practical just to register new prefix, specially, when you
> >> have to create X number
On 5/4/2016 11:58 PM, Thierry Foucu wrote:
>> Can i ask why it cannot be part of the public API?
See answer below.
>> It was really practical just to register new prefix, specially, when you
>> have to create X number of them.
It's not harder to do via AVIO callbacks in actual code using
the API
On Thu, May 5, 2016 at 12:46 AM, Thierry Foucu wrote:
> On Wed, May 4, 2016 at 1:58 PM, Derek Buitenhuis > wrote:
>
>> On 5/4/2016 9:52 PM, wm4 wrote:
>> > This was never allowed and was never public API. Use custom I/O instead
>> > (creating an avio context with your own read/write callbacks).
>>
On Wed, May 4, 2016 at 3:46 PM, Thierry Foucu wrote:
>
>
> On Wed, May 4, 2016 at 1:58 PM, Derek Buitenhuis <
> derek.buitenh...@gmail.com> wrote:
>
>> On 5/4/2016 9:52 PM, wm4 wrote:
>> > This was never allowed and was never public API. Use custom I/O instead
>> > (creating an avio context with
On Wed, May 4, 2016 at 1:58 PM, Derek Buitenhuis wrote:
> On 5/4/2016 9:52 PM, wm4 wrote:
> > This was never allowed and was never public API. Use custom I/O instead
> > (creating an avio context with your own read/write callbacks).
>
>
Can i ask why it cannot be part of the public API?
It was re
On 5/4/2016 9:52 PM, wm4 wrote:
> This was never allowed and was never public API. Use custom I/O instead
> (creating an avio context with your own read/write callbacks).
Yes, I was thinking something akin to:
int my_open(...)
{
if (filename_has_prefix("myownproto://")) {
ctx->opaque
On Wed, 4 May 2016 13:08:14 -0700
Thierry Foucu wrote:
> Hi Team
>
> On Mon, Feb 29, 2016 at 8:51 AM, Derek Buitenhuis wrote:
>
> > ffmpeg | branch: master | Derek Buitenhuis |
> > Mon Feb 29 16:50:39 2016 +| [9c75148e6ebc88a0501e3d0242defb6dbdc3c23d]
> > | committer: Derek Buitenhuis
> >
On 5/4/2016 9:08 PM, Thierry Foucu wrote:
> I noticed that this commit remove the function ffurl_register_protocol
> which allows people to register their own protocol when using libavformat.
This is intended. It was never, ever a public API on purpose, and it
was never supported or allowed.
> Bu
Hi Team
On Mon, Feb 29, 2016 at 8:51 AM, Derek Buitenhuis wrote:
> ffmpeg | branch: master | Derek Buitenhuis |
> Mon Feb 29 16:50:39 2016 +| [9c75148e6ebc88a0501e3d0242defb6dbdc3c23d]
> | committer: Derek Buitenhuis
>
> Merge commit '2758cdedfb7ac61f8b5e4861f99218b6fd43491d'
>
> This commi
13 matches
Mail list logo
