On 02/06/2019 21:19, Derek Buitenhuis wrote:
> This has nothing to do with API changes, it's a Rust toolchain (build
> system, specifically) thing. These changes don't change API/ABI.
Also to add: We will probably be cutting a 'real' rav1e release soon (0.1.0),
I think. That could also be a place
On 02/06/2019 19:27, Carl Eugen Hoyos wrote:
> Since a lot of unexpected changes can happen after months,
> this sounds to me like a strong reason to wait.
This has nothing to do with API changes, it's a Rust toolchain (build
system, specifically) thing. These changes don't change API/ABI.
- Dere
On 02/06/2019 19:45, Moritz Barsnick wrote:
> https://github.com/lu-zero/crav1e says:
>
> Status
> The API is far from stable
Yeah, that's not super true any more, and I'll remove it.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 6/2/19, Carl Eugen Hoyos wrote:
> Am So., 2. Juni 2019 um 19:54 Uhr schrieb Derek Buitenhuis
> :
>>
>> On 31/05/2019 23:08, Carl Eugen Hoyos wrote:
>> > So is your patch meant to wait until this merge is done?
>> > I would suggest so...
>>
>> Soon has a (TM) beside it for a reason (there needs
On Sun, Jun 02, 2019 at 18:46:17 +0100, Derek Buitenhuis wrote:
> take at least 1-2 months. The API itself won't change.
https://github.com/lu-zero/crav1e says:
Status
The API is far from stable
Just sayin',
Moritz
___
ffmpeg-devel mailing list
f
Am So., 2. Juni 2019 um 19:54 Uhr schrieb Derek Buitenhuis
:
>
> On 31/05/2019 23:08, Carl Eugen Hoyos wrote:
> > So is your patch meant to wait until this merge is done?
> > I would suggest so...
>
> Soon has a (TM) beside it for a reason (there needs to be some
> work done on Rust itself first, I
On 31/05/2019 23:08, Carl Eugen Hoyos wrote:
> So is your patch meant to wait until this merge is done?
> I would suggest so...
Soon has a (TM) beside it for a reason (there needs to be some
work done on Rust itself first, I think.) I would expect it to
take at least 1-2 months. The API itself won
Am Di., 28. Mai 2019 um 19:29 Uhr schrieb Derek Buitenhuis
:
> * The C bindings for rav1e currently live in the crav1e repo. This will
> be merged into rav1e's repo Soon(TM), when stuff stabalizes.
So is your patch meant to wait until this merge is done?
I would suggest so...
Carl Euge
On 29/05/2019 01:19, James Darnley wrote:
> IIRC either qp or cqp
Yeah, I'll use that; it makes sense.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or e
On 2019-05-28 22:00, Derek Buitenhuis wrote:
> On 28/05/2019 20:58, James Almer wrote:
>> I think x26* and vpx/aom call it crf? It's not in option_tables.h in any
>> case.
>
> They do not. This is a constant quantizer mode, not constant rate factor.
IIRC either qp or cqp
signature.asc
Descrip
On 28/05/2019 20:58, James Almer wrote:
> I think x26* and vpx/aom call it crf? It's not in option_tables.h in any
> case.
They do not. This is a constant quantizer mode, not constant rate factor.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpe
On 28/05/2019 20:49, Derek Buitenhuis wrote:
>>> +static const AVOption options[] = {
>>> +{ "quantizer", "use constant quantizer mode", OFFSET(quantizer),
>>> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 255, VE },
>>> +{ "max-quantizer", "max quantizer when using bitrate mode",
>>> OFFSET(max_qu
On 5/28/2019 4:49 PM, Derek Buitenhuis wrote:
> On 28/05/2019 20:32, James Almer wrote:
>>> +default:
>>> +// This should be impossible
>>> +return (RaChromaSampling) -1;
>>
>> If it's not meant to happen, then it should probably be an av_assert0.
>
> Yeah, that makes more sens
On 28/05/2019 20:32, James Almer wrote:
>> +default:
>> +// This should be impossible
>> +return (RaChromaSampling) -1;
>
> If it's not meant to happen, then it should probably be an av_assert0.
Yeah, that makes more sense. Will change.
>> +int rret;
>> +int ret = 0;
On 5/28/2019 2:29 PM, Derek Buitenhuis wrote:
> Uses the crav1e C bindings for rav1e.
>
> Missing version bump and changelog entry.
>
> Signed-off-by: Derek Buitenhuis
> ---
> Hoping to get some eyes on this, and maybe help some people who want to
> test out rav1e without having to use Y4Ms or p
Uses the crav1e C bindings for rav1e.
Missing version bump and changelog entry.
Signed-off-by: Derek Buitenhuis
---
Hoping to get some eyes on this, and maybe help some people who want to
test out rav1e without having to use Y4Ms or pipes.
Some points:
* The C bindings for rav1e currently l
16 matches
Mail list logo
