Aug 7, 2019, 11:46 PM by juandl-at-google@ffmpeg.org:
> On Tue, Aug 6, 2019 at 5:07 PM Mark Thompson wrote:
>
>> This should be in libavcodec, not libavutil - it relates directly to
>> codecs. (Indeed, you've ended up having to define a special non-libavcodec
>> enum of codecs below to make
On Tue, Aug 6, 2019 at 5:07 PM Mark Thompson wrote:
> This should be in libavcodec, not libavutil - it relates directly to
> codecs. (Indeed, you've ended up having to define a special non-libavcodec
> enum of codecs below to make it work in libavutil at all.)
>
If this belongs in avcodec I can
On Wed, Aug 07, 2019 at 12:59:33AM +0100, Mark Thompson wrote:
> On 05/08/2019 20:20, Juan De León wrote:
[...]
>
> > +/**
> > + * Stores an id corresponding to one of the supported codecs
> > + */
> > +enum AVExtractQPSupportedCodecs codec_id;
>
> enum AVCodecID, with this in
On 05/08/2019 20:20, Juan De León wrote:
> AVQuantizationParams data structure for extracting qp and storing as
> AV_FRAME_DATA_QUANTIZATION_PARAMS AVFrameSideDataType
> design doc:
> https://docs.google.com/document/d/1WClt3EqhjwdGXhEw386O0wfn3IBQ1Ib-_5emVM1gbnA/edit?usp=sharing
>
>
On Mon, Aug 5, 2019 at 1:07 PM Michael Niedermayer
wrote
> a macro would still require a major version bump as its a ABI change, if
> it changes.
> To fix this would probably require a deeper change, we could also
> of course just leave it and accept that as the maximum till the next
> ABI major
On Mon, Aug 05, 2019 at 12:16:08PM -0700, Juan De León wrote:
> On Sat, Aug 3, 2019 at 12:15 PM Michael Niedermayer
> wrote:
>
> > > +const char* av_get_qp_type_string(enum AVExtractQPSupportedCodecs
> > codec_id, int index)
> > > +{
> > > +switch (codec_id) {
> > > +case
On Sat, Aug 3, 2019 at 12:15 PM Michael Niedermayer
wrote:
> > +const char* av_get_qp_type_string(enum AVExtractQPSupportedCodecs
> codec_id, int index)
> > +{
> > +switch (codec_id) {
> > +case AV_EXTRACT_QP_CODEC_ID_H264:
> > +return index < AV_QP_ARR_SIZE_H264 ?
On Thu, Aug 01, 2019 at 04:48:32PM -0700, Juan De León wrote:
> Fixed
>
> design doc:
> https://docs.google.com/document/d/1WClt3EqhjwdGXhEw386O0wfn3IBQ1Ib-_5emVM1gbnA/edit?usp=sharing
>
> Signed-off-by: Juan De León
> ---
> libavutil/Makefile | 2 +
> libavutil/frame.h
On Mon, Jul 29, 2019 at 11:12:34AM -0700, Juan De León wrote:
> Here is the second patch, I sent the first one twice accidentaly.
> First patch is libavutil, this patch is libavcodec.
>
> Signed-off-by: Juan De León
> ---
> libavcodec/avcodec.h | 1 +
> libavcodec/h264dec.c | 44
On Thu, Aug 01, 2019 at 04:48:32PM -0700, Juan De León wrote:
> Fixed
That would end in the commit message which is probably unintended
>
> design doc:
> https://docs.google.com/document/d/1WClt3EqhjwdGXhEw386O0wfn3IBQ1Ib-_5emVM1gbnA/edit?usp=sharing
>
> Signed-off-by: Juan De León
> ---
>
On Tue, Jul 30, 2019 at 06:47:23PM -0700, Juan De León wrote:
> Removed AVQuantizationParamsArray to prevent ambiguous memory allocation.
> For simplicity, the side data will be allocated as an array of
> AVQuantizationParams and the last element of the array will have w and h set
> to 0.
>
>
On Tue, Jul 30, 2019 at 6:50 PM Juan De León wrote:
> Removed AVQuantizationParamsArray to prevent ambiguous memory allocation.
> For simplicity, the side data will be allocated as an array of
> AVQuantizationParams and the last element of the array will have w and h
> set to 0.
>
> Better
On Tue, Jul 30, 2019 at 10:49:00AM -0700, Juan De León wrote:
> On Mon, Jul 29, 2019 at 7:59 PM James Almer wrote:
>
> > Side data, or more specifically, any AVBufferRef, must be a flat array.
> > You can't have pointers to some other allocated buffer within them since
> > you can't really
On Tue, Jul 30, 2019 at 2:20 AM Andrey Semashev
wrote:
> Just a thought. If you need codec ids and implement codec-specific
> functionality, then this whole thing probably belongs to libavcodec, not
> libavutil.
>
My understanding is that only encoders and decoders are supposed to be in
On Mon, Jul 29, 2019 at 7:59 PM James Almer wrote:
> Side data, or more specifically, any AVBufferRef, must be a flat array.
> You can't have pointers to some other allocated buffer within them since
> you can't really control their lifetime.
>
Here's a snippet of how I'm doing it right now:
On 7/30/19 12:11 PM, Andrey Semashev wrote:
On 7/30/19 5:39 AM, Juan De León wrote:
I tried to fix all you suggested, please have a look and let me know
what you think.
design doc:
https://docs.google.com/document/d/1WClt3EqhjwdGXhEw386O0wfn3IBQ1Ib-_5emVM1gbnA/edit?usp=sharing
On 7/30/19 5:39 AM, Juan De León wrote:
I tried to fix all you suggested, please have a look and let me know what you
think.
design doc:
https://docs.google.com/document/d/1WClt3EqhjwdGXhEw386O0wfn3IBQ1Ib-_5emVM1gbnA/edit?usp=sharing
Signed-off-by: Juan De León
---
libavutil/Makefile
On 7/29/2019 11:19 PM, Juan De León wrote:
> On Mon, Jul 29, 2019 at 12:48 PM Mark Thompson wrote:
>
>> This doesn't belong in the commit message.
>>
>> What does belong here would be some commentary on why you want this
>> feature.
>>
> Here is the, somewhat outdated, design document, this
On Mon, Jul 29, 2019 at 12:48 PM Mark Thompson wrote:
> This doesn't belong in the commit message.
>
> What does belong here would be some commentary on why you want this
> feature.
>
Here is the, somewhat outdated, design document, this should explain it.
On 29/07/2019 19:09, Juan De León wrote:
> Changes to libavcodec, hope this addresses all your comments.
> Cheers.
This doesn't belong in the commit message.
What does belong here would be some commentary on why you want this feature.
> Signed-off-by: Juan De León
> ---
> libavutil/Makefile
Thank you for the feedback Andrey, I will fix it ASAP.
On Mon, Jul 29, 2019 at 12:11 PM Andreas Håkon
wrote:
> Interesting patch. But I have a question:
> Could you implement the same thing when using the hardware decoders?
I believe this might be in the scope of my project.
I'm not too
Hi Juan,
‐‐‐ Original Message ‐‐‐
On Monday, 29 de July de 2019 20:12, Juan De León
wrote:
> Here is the second patch, I sent the first one twice accidentaly.
> First patch is libavutil, this patch is libavcodec.
>
Interesting patch. But I have a question:
Could you implement the
Just a few random comments. Disclaimer: I'm not a maintainer.
On 7/29/19 9:09 PM, Juan De León wrote:
Changes to libavcodec, hope this addresses all your comments.
Cheers.
Signed-off-by: Juan De León
---
libavutil/Makefile | 2 +
libavutil/frame.h | 6 ++
On Wed, Jul 24, 2019 at 12:18:59PM -0700, Juan De León wrote:
> ---
> libavcodec/avcodec.h| 1 +
> libavcodec/h264dec.c| 37
> libavcodec/options_table.h | 1 +
> libavutil/Makefile | 2 +
> libavutil/frame.h | 6 ++
>
Previous thread:
http://ffmpeg.org/pipermail/ffmpeg-devel/2019-July/246951.html
I added the modifications to the decoder, I ran some tests for performance
and run times are only affected if my flag is enabled.
Decoded 3 different encoded videos 20 times each with and without my debug
flag, here
25 matches
Mail list logo
