On Fri, Aug 23, 2019 at 12:28 PM Nicolas George wrote:
> Juan De León (12019-08-23):
> > I changed it to an inline function, returns SIZE_MAX if it fails to make
> > av_malloc() fail and return NULL.
>
> You neglected to check for SIZE_MAX afterwards. I suspect there are
in the
frame.
Can be extended to support extraction of other block information.
Signed-off-by: Juan De León
---
libavutil/Makefile | 2 +
libavutil/encode_info.c | 72 ++
libavutil/encode_info.h | 110
libavutil/frame.c
On Fri, Aug 23, 2019 at 8:07 AM Nicolas George wrote:
> > +if (nb_blocks - 1 > (SIZE_MAX - sizeof(AVEncodeInfoFrame)) /
> sizeof(AVEncodeInfoBlock))
> > +return NULL;
>
> nb_blocks - 1 overflows for 0. Move the -1 right of the = as +1.
>
> > +//AVEncodeInfoFrame already allocates
in the
frame.
Can be extended to support extraction of other block information.
Signed-off-by: Juan De León
---
libavutil/Makefile | 2 +
libavutil/encode_info.c | 74 +++
libavutil/encode_info.h | 110
libavutil/frame.c
in the
frame.
Can be extended to support extraction of other block information.
Signed-off-by: Juan De León
---
libavutil/Makefile | 2 +
libavutil/encode_info.c | 71 ++
libavutil/encode_info.h | 110
libavutil/frame.c
On Mon, Aug 19, 2019 at 4:37 PM Juan De León wrote:
> Proposed changes to use AVEncodeInfoFrame and AVencodeInfoBlock
> data types as AVFrameSideData, including the changes tothe h264
> decoder as well as a filter to output the data extracted.
>
> Filter can be called using:
Extracts quantization parameters data from AVEncodeInfoFrame side data,
if available, then calculates min/max/avg and outputs the results in a log file.
Signed-off-by: Juan De León
---
doc/filters.texi | 40 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1
Proposed changes to use AVEncodeInfoFrame and AVencodeInfoBlock
data types as AVFrameSideData, including the changes tothe h264
decoder as well as a filter to output the data extracted.
Filter can be called using:
ffmpeg -debug extractqp -i -lavfi extractqp=extractqp.log -f null -
More options
in the
frame.
Can be extended to support extraction of other block information.
Signed-off-by: Juan De León
---
libavutil/Makefile | 2 +
libavutil/encode_info.c | 70 +
libavutil/encode_info.h | 110
libavutil/frame.c | 1
Added extractqp flag as an argument to the -debug flag to enable qp extraction
for the h264 decoder using AVEncodeInfo as AVFrameSideData.
Signed-off-by: Juan De León
---
libavcodec/avcodec.h | 1 +
libavcodec/h264dec.c | 40 ++
libavcodec
rameEncodeInfo the block array is initialized as blocks[1], so when
allocating memory for the array we must consider 1 block is already
allocated.
nb_blocks can be 0, if it is unsigned the subtraction wraps it around to
UINT_MAX, the cast to int is to prevent that.
If this is confusing, I t
in the
frame.
Can be extended to support extraction of other block information.
Signed-off-by: Juan De León
---
libavutil/Makefile | 2 +
libavutil/encode_info.c | 68 +
libavutil/encode_info.h | 110
libavutil/frame.c | 1
in the
frame.
Can be extended to support extraction of other block information.
Signed-off-by: Juan De León
---
libavutil/Makefile | 2 +
libavutil/encode_info.c | 68 +
libavutil/encode_info.h | 110
libavutil/frame.c | 1
On Wed, Aug 14, 2019 at 12:11 PM Juan De León wrote:
> AVEncodeInfoFrame data structure to store as AVFrameSideData of type
> AV_FRAME_DATA_ENCODE_INFO.
> The structure stores quantization index for each plane, DC/AC deltas
> for luma and chroma planes, and an array of AVEncodeIn
in the
frame.
Can be extended to support extraction of other block information.
Signed-off-by: Juan De León
---
libavutil/Makefile | 2 +
libavutil/encode_info.c | 68
libavutil/encode_info.h | 112
libavutil/frame.c | 1
On Wed, Aug 14, 2019 at 12:10 AM Nicolas George wrote:
> James Almer (12019-08-13):
> > I'm fairly sure this was discussed before, but invalid arguments
> > shouldn't crash an user's application. They even have their own
> > standardized errno value for this purpose.
> > asserts() are to catch
On Tue, Aug 13, 2019 at 4:49 PM James Almer wrote:
> I'm fairly sure this was discussed before, but invalid arguments
> shouldn't crash an user's application. They even have their own
> standardized errno value for this purpose.
> asserts() are to catch bugs in our code, not in theirs. Returning
in the
frame.
Can be extended to support extraction of other block information.
Signed-off-by: Juan De León
---
libavutil/Makefile | 2 +
libavutil/encode_info.c | 68 +
libavutil/encode_info.h | 110
libavutil/frame.c | 1
On Tue, Aug 13, 2019 at 2:49 PM Nicolas George wrote:
> > +info->blocks_offset = offsetof(AVEncodeInfoFrame, blocks);
>
> You can use sizeof(AVEncodeInfoFrame) and dispense with the blocks final
> array entirely.
>
The array is there so that the structure isn't opaque, it should be
accessed
in the
frame.
Can be extended to support extraction of other block information.
Signed-off-by: Juan De León
---
libavutil/Makefile | 2 +
libavutil/encode_info.c | 68 +
libavutil/encode_info.h | 110
libavutil/frame.c | 1
Pinging,
Any other opinions?
On Sat, Aug 10, 2019 at 2:22 AM Nicolas George wrote:
> Lynne (12019-08-10):
> > >> +typedef struct AVEncodeInfoBlock{
> > >> +/**
> > >> + * Distance in luma pixels from the top-left corner of the
> visible frame
> > >> + * to the top-left corner of the
in the
frame.
Can be extended to support extraction of other block information.
Signed-off-by: Juan De León
---
libavutil/Makefile | 2 +
libavutil/encode_info.c | 68 +++
libavutil/encode_info.h | 90 +
libavutil/frame.c
in the frame.
Can be extended to support extraction of other block information.
Signed-off-by: Juan De León
---
libavutil/Makefile | 2 +
libavutil/encode_info.c | 67 +++
libavutil/encode_info.h | 87 +
libavutil/frame.c
in the frame.
Can be extended to support extraction of other block information.
Signed-off-by: Juan De León
---
fixed a typo in frame.h comment
libavutil/Makefile | 2 +
libavutil/encode_info.c | 67 +++
libavutil/encode_info.h | 87
define
> them as the distance in pixels from the left or the top edge of the picture
> to the top-left corner of the block.
>
That's exactly their purpose, the distance in pixels from the top-left
corner of the frame, to the top-left corner of the block. I will make the
description cle
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
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
Signed-off-by: Juan De León
---
libavutil/Makefile
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 ?
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 | 6 ++
libavutil/quantization_params.c | 42 +
libavutil
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
/d/1WClt3EqhjwdGXhEw386O0wfn3IBQ1Ib-_5emVM1gbnA/edit?usp=sharing
Signed-off-by: Juan De León
---
libavutil/Makefile | 2 +
libavutil/frame.h | 6 ++
libavutil/quantization_params.c | 41 +
libavutil/quantization_params.h | 101
av_get_qp_type_string now returns const char
added descriptions to QP in enum
Tell me 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 | 2 +
libavutil
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:
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 | 2 +
libavutil/frame.h
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.
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
Signed-off-by: Juan De León
---
libavutil/Makefile | 2 +
libavutil/frame.h | 6 ++
libavutil/quantization_params.c | 41
libavutil/quantization_params.h | 106
4 files changed, 155 insertions(+)
create mode 100644
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 ++
libavcodec/options_table.h | 1 +
3
Changes to libavcodec, hope this addresses all your comments.
Cheers.
Signed-off-by: Juan De León
---
libavutil/Makefile | 2 +
libavutil/frame.h | 6 ++
libavutil/quantization_params.c | 41
libavutil/quantization_params.h | 106
I submitted another patch in a new email thread addressing your concerns,
apologies for the confusion.
The subject is "[PATCH] Extract QP from h264 encoded videos".
Here is the link to the archive
http://ffmpeg.org/pipermail/ffmpeg-devel/2019-July/247037.html
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
---
libavcodec/avcodec.h| 1 +
libavcodec/h264dec.c| 37
libavcodec/options_table.h | 1 +
libavutil/Makefile | 2 +
libavutil/frame.h | 6 ++
libavutil/quantization_params.c | 40 +
> On Mon, Jul 22, 2019 at 12:17 PM Lynne wrote:
> You can't hack a decoder in any nice and performant way for it to output
data to an analyzer.
Hi, Lynne
I hear your concern about the decoder performance.
I believe that the way we would like to modify the decoder should not
affect its
On Fri, Jul 19, 2019 at 12:47 PM Moritz Barsnick wrote:
> On Fri, Jul 19, 2019 at 10:00:52 +0200, Nicolas George wrote:
> > I do not judge whether this filter would be useful and should be
> > included, but if so, then I would appreciate that the output be done
> > using AVIO, so that it can go
Thanks for the feedback, appreciate it.
I added the AV_FRAME_DATA_QUANTIZATION_PARAMS type to AVFrameSideData and I
removed the filter since it is not complete yet.
I will send the filter and the modification to the encoders when those are done.
---
libavutil/Makefile | 2 +
For context
https://docs.google.com/document/d/1WClt3EqhjwdGXhEw386O0wfn3IBQ1Ib-_5emVM1gbnA/edit?usp=sharing
Feel free to comment the doc.
On Wed, Jul 17, 2019 at 4:18 PM Juan De León wrote:
> ---
> libavfilter/vf_extractqp.c | 116
> libavutil
---
libavfilter/vf_extractqp.c | 116
libavutil/Makefile | 2 +
libavutil/quantization_params.c | 28
libavutil/quantization_params.h | 98 +++
4 files changed, 244 insertions(+)
create mode 100644
48 matches
Mail list logo
