[FFmpeg-devel] Video codec design for very low-end decoder
Hi, If you were to design a video codec for a very low-end decoder, what would it look like? My target is MIPS 100MHz, and it should decode 320x240x30 in full speed in software, with headroom for audio too. Seems all the codec research in last 20 years has been more quality with more overhead, nobody looking into "improve quality without more overhead". Currently I'm thinking it would have to be a variant of vector quantization, like Cinepak. The target bitrates however are ~250 kbps or lower, where Cinepak targeted 1200 or higher. Are there any tricks that would improve quality with only encoder-side effort? What is the current top-of-the-line interframe prediction, that is still fast to decode? The platform is fast enough to play back mpeg1, and xvid simple profile L3 barely. Cinepak should also work, but I'd like the quality to be higher than these three. The last relevant VQ paper I found was https://arxiv.org/abs/1710.05311 which used a genetic algorithm to seed the codebook generation, improving PSNR by a few db over previous approaches. I've implemented that (for a single grayscale frame), but it looks too bad at reasonable bitrates. The modern approaches, DCT, FFT, wavelets and such transforms, are all likely too slow to decode. Not sure if this would be better off on other MLs, didn't seem to apply to ffmpeg-user really. - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] intreadwrite: add AV_RL64A, AV_WL64A
macros for reading and writing 64-bit aligned little-endian values.
these macros are used by the DST decoder and give a performance boost
on big-endian platforms that where the compiler must normally guard
against unaligned memory access.
---
libavutil/intreadwrite.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/libavutil/intreadwrite.h b/libavutil/intreadwrite.h
index 67c763b135..4c8413a536 100644
--- a/libavutil/intreadwrite.h
+++ b/libavutil/intreadwrite.h
@@ -542,6 +542,21 @@ union unaligned_16 { uint16_t l; } __attribute__((packed))
av_alias;
# define AV_WN64A(p, v) AV_WNA(64, p, v)
#endif
+#if AV_HAVE_BIGENDIAN
+# define AV_RLA(s, p)av_bswap##s(AV_RN##s##A(p))
+# define AV_WLA(s, p, v) AV_WN##s##A(p, av_bswap##s(v))
+#else
+# define AV_RLA(s, p)AV_RN##s##A(p)
+# define AV_WLA(s, p, v) AV_WN##s##A(p, v)
+#endif
+
+#ifndef AV_RL64A
+# define AV_RL64A(p) AV_RLA(64, p)
+#endif
+#ifndef AV_WL64A
+# define AV_WL64A(p, v) AV_WLA(64, p, v)
+#endif
+
/*
* The AV_COPYxxU macros are suitable for copying data to/from unaligned
* memory locations.
--
2.17.1
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] dstdec: big-endian compatiblity
--- updated accordingly... libavcodec/dstdec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/dstdec.c b/libavcodec/dstdec.c index 511861f4d2..0614c99c4b 100644 --- a/libavcodec/dstdec.c +++ b/libavcodec/dstdec.c @@ -343,8 +343,8 @@ static int decode_frame(AVCodecContext *avctx, void *data, v = ((predict >> 15) ^ residual) & 1; dsd[((i >> 3) * channels + ch) << 2] |= v << (7 - (i & 0x7 )); -AV_WN64A(status + 8, (AV_RN64A(status + 8) << 1) | ((AV_RN64A(status) >> 63) & 1)); -AV_WN64A(status, (AV_RN64A(status) << 1) | v); +AV_WL64A(status + 8, (AV_RL64A(status + 8) << 1) | ((AV_RL64A(status) >> 63) & 1)); +AV_WL64A(status, (AV_RL64A(status) << 1) | v); } } -- 2.17.1 -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] intreadwrite: add AV_RL64A, AV_WL64A
2019-01-07 12:40 GMT+01:00, Peter Ross : > macros for reading and writing 64-bit aligned little-endian values. > > these macros are used by the DST decoder and give a performance boost > on big-endian platforms that where the compiler must normally guard > against unaligned memory access. I thought there is a performance gain on little-endian... Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/vp3data: use more compact data type
---
this table is used at vp3_decode_init time, and is needlessly uint32_t.
will push in a day or so.
libavcodec/vp3data.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vp3data.h b/libavcodec/vp3data.h
index 3884bca878..c82b1b3a86 100644
--- a/libavcodec/vp3data.h
+++ b/libavcodec/vp3data.h
@@ -73,7 +73,7 @@ static const uint8_t vp31_dc_scale_factor[64] = {
20, 10, 10, 10, 10, 10, 10, 10
};
-static const uint32_t vp31_ac_scale_factor[64] = {
+static const uint16_t vp31_ac_scale_factor[64] = {
500, 450, 400, 370, 340, 310, 285, 265,
245, 225, 210, 195, 185, 180, 170, 160,
150, 145, 135, 130, 125, 115, 110, 107,
--
2.17.1
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] intreadwrite: add AV_RL64A, AV_WL64A
On Mon, Jan 07, 2019 at 12:42:24PM +0100, Carl Eugen Hoyos wrote: > 2019-01-07 12:40 GMT+01:00, Peter Ross : > > macros for reading and writing 64-bit aligned little-endian values. > > > > these macros are used by the DST decoder and give a performance boost > > on big-endian platforms that where the compiler must normally guard > > against unaligned memory access. > > I thought there is a performance gain on little-endian... true... i will omit 'big-endian' from the comment to make it clearer. -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V6 1/2] avutil: add ROI (Region Of Interest) data struct and bump version
The encoders such as libx264 support different QPs offset for different MBs,
it makes possible for ROI-based encoding. It makes sense to add support
within ffmpeg to generate/accept ROI infos and pass into encoders.
Typical usage: After AVFrame is decoded, a ffmpeg filter or user's code
generates ROI info for that frame, and the encoder finally does the
ROI-based encoding.
The ROI info is maintained as side data of AVFrame.
Signed-off-by: Guo, Yejun
---
libavutil/frame.c | 1 +
libavutil/frame.h | 35 +++
libavutil/version.h | 2 +-
3 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 34a6210..dcf1fc3 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -841,6 +841,7 @@ const char *av_frame_side_data_name(enum
AVFrameSideDataType type)
case AV_FRAME_DATA_QP_TABLE_DATA: return "QP table data";
#endif
case AV_FRAME_DATA_DYNAMIC_HDR_PLUS: return "HDR Dynamic Metadata
SMPTE2094-40 (HDR10+)";
+case AV_FRAME_DATA_REGIONS_OF_INTEREST: return "Regions Of Interest";
}
return NULL;
}
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 582ac47..8d0dfed 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -173,6 +173,12 @@ enum AVFrameSideDataType {
* volume transform - application 4 of SMPTE 2094-40:2016 standard.
*/
AV_FRAME_DATA_DYNAMIC_HDR_PLUS,
+
+/**
+ * Regions Of Interest, the data is an array of AVRegionOfInterest type,
the number of
+ * array element is implied by AVFrameSideData.size /
AVRegionOfInterest.self_size.
+ */
+AV_FRAME_DATA_REGIONS_OF_INTEREST,
};
enum AVActiveFormatDescription {
@@ -201,6 +207,35 @@ typedef struct AVFrameSideData {
} AVFrameSideData;
/**
+ * Structure to hold Region Of Interest.
+ *
+ * self_size specifies the size of this data structure. This value
+ * should be set to sizeof(AVRegionOfInterest). EINVAL is returned if
self_size is zero.
+ *
+ * Number of pixels to discard from the top/bottom/left/right border of
+ * the frame to obtain the region of interest of the frame.
+ * They are encoder dependent and will be extended internally
+ * if the codec requires an alignment.
+ * If the regions overlap, the last value in the list will be used.
+ *
+ * qoffset is quant offset, and base rule here:
+ * returns EINVAL if AVRational.den is zero.
+ * the value (num/den) range is [-1.0, 1.0], clamp to +-1.0 if out of range.
+ * 0 means no picture quality change,
+ * negtive offset asks for better quality (and the best with value -1.0),
+ * positive offset asks for worse quality (and the worst with value 1.0).
+ * How to explain/implement the different quilaity requirement is encoder
dependent.
+ */
+typedef struct AVRegionOfInterest {
+uint32_t self_size;
+int top;
+int bottom;
+int left;
+int right;
+AVRational qoffset;
+} AVRegionOfInterest;
+
+/**
* This structure describes decoded (raw) audio or video data.
*
* AVFrame must be allocated using av_frame_alloc(). Note that this only
diff --git a/libavutil/version.h b/libavutil/version.h
index f997615..1fcdea9 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 56
-#define LIBAVUTIL_VERSION_MINOR 25
+#define LIBAVUTIL_VERSION_MINOR 26
#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V6 2/2] avcodec/libx264: add support for ROI-based encoding
This patch just enables the path from ffmpeg to libx264,
the more encoders can be added later.
Signed-off-by: Guo, Yejun
---
libavcodec/libx264.c | 67
1 file changed, 67 insertions(+)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index a68d0a7..9cfbaed 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -40,6 +40,10 @@
#include
#include
+// from x264.h, for quant_offsets, Macroblocks are 16x16
+// blocks of pixels (with respect to the luma plane)
+#define MB_SIZE 16
+
typedef struct X264Context {
AVClass*class;
x264_param_tparams;
@@ -282,6 +286,7 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt,
const AVFrame *frame,
x264_picture_t pic_out = {0};
int pict_type;
int64_t *out_opaque;
+AVFrameSideData *sd;
x264_picture_init( &x4->pic );
x4->pic.img.i_csp = x4->params.i_csp;
@@ -345,6 +350,68 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt,
const AVFrame *frame,
}
}
}
+
+sd = av_frame_get_side_data(frame, AV_FRAME_DATA_REGIONS_OF_INTEREST);
+if (sd) {
+static int show_aq_warning = 1;
+static int show_interlaced_frame_warning = 1;
+if (x4->params.rc.i_aq_mode == X264_AQ_NONE && show_aq_warning) {
+show_aq_warning = 0;
+av_log(ctx, AV_LOG_WARNING, "Adaptive quantization must be
enabled to use ROI encoding, skipping ROI.\n");
+} else {
+if (frame->interlaced_frame == 0) {
+int mbx = (frame->width + MB_SIZE - 1) / MB_SIZE;
+int mby = (frame->height + MB_SIZE - 1) / MB_SIZE;
+int nb_rois;
+AVRegionOfInterest* roi;
+float* qoffsets;
+qoffsets = (float*)av_mallocz_array(mbx * mby,
sizeof(*qoffsets));
+if (!qoffsets)
+return AVERROR(ENOMEM);
+
+nb_rois = sd->size / sizeof(AVRegionOfInterest);
+roi = (AVRegionOfInterest*)sd->data;
+for (int count = 0; count < nb_rois; count++) {
+int starty = FFMIN(mby, roi->top / MB_SIZE);
+int endy = FFMIN(mby, (roi->bottom + MB_SIZE - 1)/
MB_SIZE);
+int startx = FFMIN(mbx, roi->left / MB_SIZE);
+int endx = FFMIN(mbx, (roi->right + MB_SIZE - 1)/
MB_SIZE);
+float qoffset;
+
+if (roi->qoffset.den == 0) {
+av_free(qoffsets);
+av_log(ctx, AV_LOG_ERROR,
"AVRegionOfInterest.qoffset.den should not be zero.\n");
+return AVERROR(EINVAL);
+}
+qoffset = roi->qoffset.num * 1.0f / roi->qoffset.den;
+qoffset = FFMIN(qoffset, 1.0f);
+qoffset = FFMAX(qoffset, -1.0f);
+
+// 25 is a number that I think it is a possible proper
scale value.
+qoffset = qoffset * 25;
+
+for (int y = starty; y < endy; y++) {
+for (int x = startx; x < endx; x++) {
+qoffsets[x + y*mbx] = qoffset;
+}
+}
+
+if (roi->self_size == 0) {
+av_free(qoffsets);
+av_log(ctx, AV_LOG_ERROR,
"AVRegionOfInterest.self_size should be set to sizeof(AVRegionOfInterest).\n");
+return AVERROR(EINVAL);
+}
+roi = (AVRegionOfInterest*)((char*)roi +
roi->self_size);
+}
+
+x4->pic.prop.quant_offsets = qoffsets;
+x4->pic.prop.quant_offsets_free = av_free;
+} else if (show_interlaced_frame_warning) {
+show_interlaced_frame_warning = 0;
+av_log(ctx, AV_LOG_WARNING, "interlaced_frame not
supported for ROI encoding yet, skipping ROI.\n");
+}
+}
+}
}
do {
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V5 1/2] avutil: add ROI (Region Of Interest) data struct and bump version
On Sat, Jan 5, 2019 at 2:15 AM James Almer wrote:
> On 1/4/2019 10:08 AM, Vittorio Giovara wrote:
> > On Fri, Jan 4, 2019 at 12:22 PM Nicolas George wrote:
> >
> >> Rostislav Pehlivanov (12019-01-04):
> +typedef struct AVRegionOfInterest {
> +size_t self_size;
> +size_t top;
> +size_t bottom;
> +size_t left;
> +size_t right;
> >>> I'd still much rather have uints with fixed sizes than these platform
> >>> dependent types.
> >>
> >> Guo, Yejun said:
> >>
> I usually choose 'size_t' for the meanings with length/size.
> >>
> >> But that is a mistake. size_t is for length/size of objects in memory,
> >> not any length/size.
> >>
> >> These numbers, unless I am mistaken, are coordinates within an AVFrame.
> >> In that case, the only correct type is the same as AVFrame.width and
> >> AVFrame.height.
> >>
> >
> > I personally disagree, what are coordinates within an AVFrame if not the
> > length/size of an object in memory?
> > A buffer containing video data is still an object in memory after all, so
> > IMHO using size_t makes a lot of sense here.
>
> We already did size_t for AVSphericalMapping and had to change them to
> uint32_t.
> size_t is not the correct type at all, as video dimensions are not
> system dependent, and it will generate the same issues we already
> experienced with AVSphericalMapping in fate tests.
>
>
Just for the sake of information, the issue with the spherical fate tests
is that some mov tests included the side data size which was thankfully
removed because it did not made any sense. Even then, the
AVSphericalMapping structure was changed only to make it more similar to
the specification -- this is not the case here: size_t represents a length
so using it for video dimensions makes perfect sense. That being said, use
whatever type you want, as long as it's correctly documented and argumented.
Regards
--
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V5 1/2] avutil: add ROI (Region Of Interest) data struct and bump version
Vittorio Giovara (12019-01-07): > size_t represents a length > so using it for video dimensions makes perfect sense. size_t represents a system-dependent size of object in memory, not any "length". There is no reason to have different resolution limits on 32 and 64 bits systems, as long as the data fits in memory. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Video codec design for very low-end decoder
On Mon, Jan 07, 2019 at 10:17:48AM +0200, Lauri Kasanen wrote: > Hi, > > If you were to design a video codec for a very low-end decoder, what > would it look like? > > My target is MIPS 100MHz, and it should decode 320x240x30 in full speed > in software, with headroom for audio too. Seems all the codec research > in last 20 years has been more quality with more overhead, nobody > looking into "improve quality without more overhead". > > Currently I'm thinking it would have to be a variant of vector > quantization, like Cinepak. The target bitrates however are ~250 kbps > or lower, where Cinepak targeted 1200 or higher. Are there any tricks > that would improve quality with only encoder-side effort? What is the > current top-of-the-line interframe prediction, that is still fast to > decode? > > The platform is fast enough to play back mpeg1, and xvid simple > profile L3 barely. Cinepak should also work, but I'd like the quality > to be higher than these three. > > The last relevant VQ paper I found was > https://arxiv.org/abs/1710.05311 which used a genetic algorithm to seed > the codebook generation, improving PSNR by a few db over previous > approaches. I've implemented that (for a single grayscale frame), but it > looks too bad at reasonable bitrates. > > The modern approaches, DCT, FFT, wavelets and such transforms, are all > likely too slow to decode. you said it can do mpeg1 and xvid, these are DCT based have you tried H.264 ? (i imagine that might with asm optimizations and avoidance of more complex features like CABAC and the loop filter work maybe, maybe not) also if h.264 with everything disabled works maybe some features can be turned on sometimes like the loop filter for key frames, that might then help compression ... and beating an existing codec, while certainly possible might be hard > > Not sure if this would be better off on other MLs, didn't seem to apply > to ffmpeg-user really. > > - Lauri > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Video codec design for very low-end decoder
On Mon, Jan 07, 2019 at 01:44:56PM +0100, Michael Niedermayer wrote: > On Mon, Jan 07, 2019 at 10:17:48AM +0200, Lauri Kasanen wrote: > > Hi, > > > > If you were to design a video codec for a very low-end decoder, what > > would it look like? > > > > My target is MIPS 100MHz, and it should decode 320x240x30 in full speed > > in software, with headroom for audio too. Seems all the codec research > > in last 20 years has been more quality with more overhead, nobody > > looking into "improve quality without more overhead". > > > > Currently I'm thinking it would have to be a variant of vector > > quantization, like Cinepak. The target bitrates however are ~250 kbps > > or lower, where Cinepak targeted 1200 or higher. Are there any tricks > > that would improve quality with only encoder-side effort? What is the > > current top-of-the-line interframe prediction, that is still fast to > > decode? > > > > The platform is fast enough to play back mpeg1, and xvid simple > > profile L3 barely. Cinepak should also work, but I'd like the quality > > to be higher than these three. > > > > The last relevant VQ paper I found was > > https://arxiv.org/abs/1710.05311 which used a genetic algorithm to seed > > the codebook generation, improving PSNR by a few db over previous > > approaches. I've implemented that (for a single grayscale frame), but it > > looks too bad at reasonable bitrates. > > > > > The modern approaches, DCT, FFT, wavelets and such transforms, are all > > likely too slow to decode. > > you said it can do mpeg1 and xvid, these are DCT based > have you tried H.264 ? (i imagine that might with asm optimizations > and avoidance of more complex features like CABAC and the loop filter > work maybe, maybe not) > also if h.264 with everything disabled works maybe some features can > be turned on sometimes like the loop filter for key frames, that > might then help compression ... > > and beating an existing codec, while certainly possible might be hard beating the best existing codec that works for you, while certainly possible might be hard [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Video codec design for very low-end decoder
On Mon, 7 Jan 2019 13:44:56 +0100 Michael Niedermayer wrote: > > The modern approaches, DCT, FFT, wavelets and such transforms, are all > > likely too slow to decode. > > you said it can do mpeg1 and xvid, these are DCT based > have you tried H.264 ? (i imagine that might with asm optimizations > and avoidance of more complex features like CABAC and the loop filter > work maybe, maybe not) > also if h.264 with everything disabled works maybe some features can > be turned on sometimes like the loop filter for key frames, that > might then help compression ... > > and beating an existing codec, while certainly possible might be hard According to a 2010 comparison https://keyj.emphy.de/video-encoder-comparison/ x264 constrained baseline (everything off) takes something like 30% longer to decode vs xvid at the same rate. Probably more because that site used xvid's full features, while I used it "everything off". The issue with xvid simple and mpeg1 were that they were slightly too slow, and looked too bad. The platform does not have any SIMD, so I doubt asm optimizations will help much. Cinepak is almost 30 years old, surely it should be possible to match the decoding & quality, but at a 5x lower bitrate :P - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add dumpwave filter.
Signed-off-by: Dmitry Humeniuk
---
Changelog|1 +
doc/filters.texi | 23 +
libavfilter/Makefile |1 +
libavfilter/af_dumpwave.c| 234
libavfilter/allfilters.c |1 +
libavfilter/version.h|4 +-
tests/fate-run.sh|9 +
tests/fate/filter-audio.mak | 12 +
tests/ref/fate/filter-dumpwave | 1800 ++
tests/ref/fate/filter-dumpwave-24bit | 1800 ++
tests/ref/fate/filter-dumpwave-fltp | 1800 ++
11 files changed, 5683 insertions(+), 2 deletions(-)
create mode 100644 libavfilter/af_dumpwave.c
create mode 100644 tests/ref/fate/filter-dumpwave
create mode 100644 tests/ref/fate/filter-dumpwave-24bit
create mode 100644 tests/ref/fate/filter-dumpwave-fltp
diff --git a/Changelog b/Changelog
index f135fa56b6..1eb337796b 100644
--- a/Changelog
+++ b/Changelog
@@ -13,6 +13,7 @@ version :
- GIF parser
- vividas demuxer
- hymt decoder
+- dumpwave filter
version 4.1:
diff --git a/doc/filters.texi b/doc/filters.texi
index 98858c5356..66c2961fd8 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2912,6 +2912,29 @@ Set window length in seconds used to split audio into
segments of equal length.
Default is 3 seconds.
@end table
+@section dumpwave
+Dump RMS envelope to a file.
+Convert samples to decibels and calculates RMS (Root-Mean-Square) audio power
in 0 to 1.0 floats.
+
+@table @option
+@item w, width
+Number of data values.
+The default value is @var{1800}
+
+@item n, nb_samples
+Samples count per value per channel, default 128
+
+@item f, file
+Path to a file ``-'' is a shorthand
+for standard output.
+@end table
+
+For example, to generate RMS envelope for 44.1 kHz 6 seconds length audio
+with dimensions @var{1800x140}, samples count @code{44100*6/1800=147} and
store it to @var{/tmp/out.csv}, you might use:
+@example
+dumpwave=w=1800:n=147:f=/tmp/out.csv
+@end example
+
@section dynaudnorm
Dynamic Audio Normalizer.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 6e2658186d..c40e61fcbe 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -99,6 +99,7 @@ OBJS-$(CONFIG_CROSSFEED_FILTER) += af_crossfeed.o
OBJS-$(CONFIG_CRYSTALIZER_FILTER)+= af_crystalizer.o
OBJS-$(CONFIG_DCSHIFT_FILTER)+= af_dcshift.o
OBJS-$(CONFIG_DRMETER_FILTER)+= af_drmeter.o
+OBJS-$(CONFIG_DUMPWAVE_FILTER) += af_dumpwave.o
OBJS-$(CONFIG_DYNAUDNORM_FILTER) += af_dynaudnorm.o
OBJS-$(CONFIG_EARWAX_FILTER) += af_earwax.o
OBJS-$(CONFIG_EBUR128_FILTER)+= f_ebur128.o
diff --git a/libavfilter/af_dumpwave.c b/libavfilter/af_dumpwave.c
new file mode 100644
index 00..19917ed22f
--- /dev/null
+++ b/libavfilter/af_dumpwave.c
@@ -0,0 +1,234 @@
+/*
+ * Copyright (c) 2019 Dmytro Humeniuk
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * waveform audio filter – dump RMS amplitude to a file
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/avstring.h"
+#include "libavutil/channel_layout.h"
+#include "libavutil/opt.h"
+#include "libavutil/parseutils.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "audio.h"
+#include "internal.h"
+
+typedef struct DumpWaveContext {
+const AVClass *class; /**< class for AVOptions */
+int width; /**< number of data values */
+int idx;/**< index of current value */
+char *filename; /**< output filename */
+float *values; /**< scaling factors */
+int64_t nb_samples; /**< samples per value per channel */
+int64_t count; /**< current number of samples counted */
+int64_t frame_size; /**< samples per value */
+double sum; /**< sum of the squared samples per value */
+double max_value; /**< keep track of max value */
+FILE *dump_fp;
+} DumpWaveContext;
+
+#define OFFSET(x) offsetof(DumpWaveContext, x)
+#define FLAGS AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption dumpwave_options[] = {
+{ "w", "set number of data values
Re: [FFmpeg-devel] Video codec design for very low-end decoder
On Mon, Jan 07, 2019 at 03:38:35PM +0200, Lauri Kasanen wrote: > On Mon, 7 Jan 2019 13:44:56 +0100 > Michael Niedermayer wrote: > > > > The modern approaches, DCT, FFT, wavelets and such transforms, are all > > > likely too slow to decode. > > > > you said it can do mpeg1 and xvid, these are DCT based > > have you tried H.264 ? (i imagine that might with asm optimizations > > and avoidance of more complex features like CABAC and the loop filter > > work maybe, maybe not) > > also if h.264 with everything disabled works maybe some features can > > be turned on sometimes like the loop filter for key frames, that > > might then help compression ... > > > > and beating an existing codec, while certainly possible might be hard > > According to a 2010 comparison > https://keyj.emphy.de/video-encoder-comparison/ > x264 constrained baseline (everything off) takes something like 30% > longer to decode vs xvid at the same rate. Probably more because that > site used xvid's full features, while I used it "everything off". constrained baseline is not "everything off" > > The issue with xvid simple and mpeg1 were that they were slightly too > slow, and looked too bad. The platform does not have any SIMD, so I > doubt asm optimizations will help much. I would guess that with rare or odd architectures compilers are not so good when it comes to generating efficient code. I would not be surprised if someone who knows the target CPUs pipeline and timings could beat the compiler by quite some amount. This is one part where the amount of man hours needed is significant of course. Would that be worth it, well its your project you have to know what amount of work you are willing to do for this, i wouldnt do that work ;) besides, why this low end chip ? > > Cinepak is almost 30 years old, surely it should be possible to match > the decoding & quality, but at a 5x lower bitrate :P > > - Lauri > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Video codec design for very low-end decoder
Hi Lauri, On Mon, Jan 7, 2019 at 3:15 AM Lauri Kasanen wrote: > If you were to design a video codec for a very low-end decoder, what > would it look like? > Have you considered vp8? It may sound weird but this is basically what vp8 was great at: being really simple to decode. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add anlmdn audio filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 27
libavfilter/Makefile | 1 +
libavfilter/af_anlmdn.c | 257 +++
libavfilter/allfilters.c | 1 +
4 files changed, 286 insertions(+)
create mode 100644 libavfilter/af_anlmdn.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 98858c5356..35d68cf85a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -1750,6 +1750,33 @@ Full filter invocation with asendcmd may look like this:
asendcmd=c='4.0 anequalizer change 0|f=200|w=50|g=1',anequalizer=...
@end table
+@section anlmdn
+
+Reduce broadband noise in audio samples using Non-Local Means algorithm.
+
+Each sample is adjusted by looking for other samples with similar contexts.
This
+context similarity is defined by comparing their surrounding patches of size
+@option{p}. Patches are searched in an area of @option{r} around the sample.
+
+The filter accepts the following options.
+
+@table @option
+@item s
+Set denoising strength. Allowed range is from 1 to . Default value is 1.
+
+@item p
+Set patch radius duration. Allowed range is from 1 to 24 milliseconds.
+Default value is 2 milliseconds.
+
+@item r
+Set research radius duration. Allowed range is from 2 to 48 milliseconds.
+Default value is 12 milliseconds.
+
+@item n
+Set number of patches to filter at once. Allowed range is from 1 to 100.
+Default value is 1.
+@end table
+
@section anull
Pass the audio source unchanged to the output.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 6e2658186d..d31fa59e0d 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -63,6 +63,7 @@ OBJS-$(CONFIG_AMETADATA_FILTER) += f_metadata.o
OBJS-$(CONFIG_AMIX_FILTER) += af_amix.o
OBJS-$(CONFIG_AMULTIPLY_FILTER) += af_amultiply.o
OBJS-$(CONFIG_ANEQUALIZER_FILTER)+= af_anequalizer.o
+OBJS-$(CONFIG_ANLMDN_FILTER) += af_anlmdn.o
OBJS-$(CONFIG_ANULL_FILTER) += af_anull.o
OBJS-$(CONFIG_APAD_FILTER) += af_apad.o
OBJS-$(CONFIG_APERMS_FILTER) += f_perms.o
diff --git a/libavfilter/af_anlmdn.c b/libavfilter/af_anlmdn.c
new file mode 100644
index 00..b7efd8387b
--- /dev/null
+++ b/libavfilter/af_anlmdn.c
@@ -0,0 +1,257 @@
+/*
+ * Copyright (c) 2019 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+
+#include "libavutil/avassert.h"
+#include "libavutil/audio_fifo.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "audio.h"
+#include "formats.h"
+
+#define SQR(x) ((x) * (x))
+
+typedef struct AudioNLMeansContext {
+const AVClass *class;
+
+float a;
+int64_t pd;
+int64_t rd;
+int n;
+
+int K;
+int S;
+
+int N;
+int hop_size;
+
+AVFrame *in;
+AVFrame *cache;
+
+int64_t pts;
+
+AVAudioFifo *fifo;
+
+float (*compute_distance)(const float *f1, const float *f2, int K);
+} AudioNLMeansContext;
+
+#define OFFSET(x) offsetof(AudioNLMeansContext, x)
+#define AF AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption anlmdn_options[] = {
+{ "s", "set denoising strength", OFFSET(a), AV_OPT_TYPE_FLOAT,
{.dbl=1},1, , AF },
+{ "p", "set patch duration", OFFSET(pd), AV_OPT_TYPE_DURATION,
{.i64=2000}, 1000, 24000, AF },
+{ "r", "set research duration", OFFSET(rd), AV_OPT_TYPE_DURATION,
{.i64=12000}, 2000, 48000, AF },
+{ "n", "set number of patches to filter at once", OFFSET(n),
AV_OPT_TYPE_INT, {.i64=1}, 1, 100, AF },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(anlmdn);
+
+static int query_formats(AVFilterContext *ctx)
+{
+AVFilterFormats *formats = NULL;
+AVFilterChannelLayouts *layouts = NULL;
+static const enum AVSampleFormat sample_fmts[] = {
+AV_SAMPLE_FMT_FLTP,
+AV_SAMPLE_FMT_NONE
+};
+int ret;
+
+formats = ff_make_format_list(sample_fmts);
+if (!formats)
+return AVERROR(ENOMEM);
+ret = ff_set_common_formats(ctx, formats);
+if (ret < 0)
+return ret;
+
+layouts = ff_all_channel_counts();
+if (!layouts)
+return AVERROR(ENOMEM);
+
+ret = ff_set_common_channel_layouts(ctx, layouts);
+if (ret < 0)
+
Re: [FFmpeg-devel] Video codec design for very low-end decoder
On Mon, 7 Jan 2019 17:42:58 +0100 Michael Niedermayer wrote: > > According to a 2010 comparison > > https://keyj.emphy.de/video-encoder-comparison/ > > x264 constrained baseline (everything off) takes something like 30% > > longer to decode vs xvid at the same rate. Probably more because that > > site used xvid's full features, while I used it "everything off". > > constrained baseline is not "everything off" Wikipedia's table shows CBP as "all off", but perhaps it doesn't list every option. It lists CABAC etc, but not deblocking. Do you think the unlisted options could account for 30%? > > The issue with xvid simple and mpeg1 were that they were slightly too > > slow, and looked too bad. The platform does not have any SIMD, so I > > doubt asm optimizations will help much. > > I would guess that with rare or odd architectures > compilers are not so good when it comes to generating efficient code. > > I would not be surprised if someone who knows the target CPUs pipeline > and timings could beat the compiler by quite some amount. > This is one part where the amount of man hours needed is significant > of course. Would that be worth it, well its your project you have > to know what amount of work you are willing to do for this, > i wouldnt do that work ;) > > besides, why this low end chip ? Just for fun ;) MIPS does not have any timings, all instructions complete in the same amount of cycles (except floating point, cache misses, interrupts, etc). This makes it fairly suitable for a compiler I think, limiting what could be gotten from hand-writing asm. On Mon, 7 Jan 2019 12:02:58 -0500 "Ronald S. Bultje" wrote: > Have you considered vp8? It may sound weird but this is basically what vp8 > was great at: being really simple to decode. VP8 has a reputation of being slow, so I didn't consider it. Benchmarks show it as decoding slower than h264. Perhaps it too has features that can be disabled? - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Video codec design for very low-end decoder
Hi, On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen wrote: > On Mon, 7 Jan 2019 12:02:58 -0500 > "Ronald S. Bultje" wrote: > > > Have you considered vp8? It may sound weird but this is basically what > vp8 > > was great at: being really simple to decode. > > VP8 has a reputation of being slow, so I didn't consider it. Benchmarks > show it as decoding slower than h264. > It is faster than h264 when comparing ffh264 vs. ffvp8: https://blogs.gnome.org/rbultje/files/2014/02/sintel_decspeed.png Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Video codec design for very low-end decoder
On Mon, Jan 07, 2019 at 07:24:53PM +0200, Lauri Kasanen wrote: > On Mon, 7 Jan 2019 17:42:58 +0100 > Michael Niedermayer wrote: > > > > According to a 2010 comparison > > > https://keyj.emphy.de/video-encoder-comparison/ > > > x264 constrained baseline (everything off) takes something like 30% > > > longer to decode vs xvid at the same rate. Probably more because that > > > site used xvid's full features, while I used it "everything off". > > > > constrained baseline is not "everything off" > > Wikipedia's table shows CBP as "all off", but perhaps it doesn't list > every option. It lists CABAC etc, but not deblocking. Do you think the > unlisted options could account for 30%? deblocking is complex, if everything else is turned off relatively speaking Also if h264 is still too slow after this try intra only h264. same thing for mpeg4 ASP (what you call xvid) and mpeg1, intra only might be fast enough > > > > The issue with xvid simple and mpeg1 were that they were slightly too > > > slow, and looked too bad. The platform does not have any SIMD, so I > > > doubt asm optimizations will help much. > > > > I would guess that with rare or odd architectures > > compilers are not so good when it comes to generating efficient code. > > > > I would not be surprised if someone who knows the target CPUs pipeline > > and timings could beat the compiler by quite some amount. > > This is one part where the amount of man hours needed is significant > > of course. Would that be worth it, well its your project you have > > to know what amount of work you are willing to do for this, > > i wouldnt do that work ;) > > > > besides, why this low end chip ? > > Just for fun ;) > > MIPS does not have any timings, all instructions complete in the same > amount of cycles (except floating point, cache misses, interrupts, > etc). This makes it fairly suitable for a compiler I think, limiting > what could be gotten from hand-writing asm. have you ever looked at asm code generated by gcc ? you should instead of assuming it is good code. Ive seen really crappy code generated by compilers and i speak of x86 here. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/qpeg: Optimize long runs in qpeg_decode_intra() not spanning a full row
On 1/7/19, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes:
> 11354/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
>
> Before: Executed
> clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
> in 9470 ms
> After : Executed
> clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
> in 134 ms
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/qpeg.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/qpeg.c b/libavcodec/qpeg.c
> index cb452621e7..654fd998d6 100644
> --- a/libavcodec/qpeg.c
> +++ b/libavcodec/qpeg.c
> @@ -80,7 +80,10 @@ static void qpeg_decode_intra(QpegContext *qctx, uint8_t
> *dst,
>
> p = bytestream2_get_byte(&qctx->buffer);
> for(i = 0; i < run; i++) {
> -dst[filled++] = p;
> +int step = FFMIN(run - i, width - filled);
> +memset(dst+filled, p, step);
> +filled += step;
> +i += step - 1;
> if (filled >= width) {
> filled = 0;
> dst -= stride;
> --
> 2.20.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
lgtm if output does not change.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] libswscale/ppc: VSX-optimize 9-16 bit yuv2planeX
On Mon, Jan 07, 2019 at 10:01:22AM +0200, Lauri Kasanen wrote:
> ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt
> yuv420p16be \
> -s 1920x1728 -f null -vframes 100 -v error -nostats -
>
> 9-14 bit funcs get about 6x speedup, 16-bit gets about 15x.
> Fate passes, each format tested with an image to video conversion.
>
> Only POWER8 includes 32-bit vector multiplies, so POWER7 is locked out
> of the 16-bit function. This includes the vec_mulo/mule functions too,
> not just vmuluwm.
>
> yuv420p9le
> 12341 UNITS in planarX, 130976 runs, 96 skips
> 73752 UNITS in planarX, 131066 runs, 6 skips
> yuv420p9be
> 12364 UNITS in planarX, 131025 runs, 47 skips
> 73001 UNITS in planarX, 131055 runs, 17 skips
> yuv420p10le
> 12386 UNITS in planarX, 131042 runs, 30 skips
> 72735 UNITS in planarX, 131062 runs, 10 skips
> yuv420p10be
> 12337 UNITS in planarX, 131045 runs, 27 skips
> 72734 UNITS in planarX, 131057 runs, 15 skips
> yuv420p12le
> 12236 UNITS in planarX, 131058 runs, 14 skips
> 73029 UNITS in planarX, 131062 runs, 10 skips
> yuv420p12be
> 12218 UNITS in planarX, 130973 runs, 99 skips
> 72402 UNITS in planarX, 131069 runs, 3 skips
> yuv420p14le
> 12168 UNITS in planarX, 131067 runs, 5 skips
> 72480 UNITS in planarX, 131069 runs, 3 skips
> yuv420p14be
> 12358 UNITS in planarX, 130948 runs,124 skips
> 73772 UNITS in planarX, 131063 runs, 9 skips
> yuv420p16le
> 10439 UNITS in planarX, 130911 runs,161 skips
> 157923 UNITS in planarX, 131068 runs, 4 skips
> yuv420p16be
> 10463 UNITS in planarX, 130874 runs,198 skips
> 154405 UNITS in planarX, 131061 runs, 11 skips
>
> Signed-off-by: Lauri Kasanen
> ---
>
> v2: Separate macros so that yuv2plane1_16_vsx remains available for power7
>
> libswscale/ppc/swscale_ppc_template.c | 4 +-
> libswscale/ppc/swscale_vsx.c | 190
> +-
> 2 files changed, 189 insertions(+), 5 deletions(-)
>
> diff --git a/libswscale/ppc/swscale_ppc_template.c
> b/libswscale/ppc/swscale_ppc_template.c
> index 00e4b99..11decab 100644
> --- a/libswscale/ppc/swscale_ppc_template.c
> +++ b/libswscale/ppc/swscale_ppc_template.c
> @@ -21,7 +21,7 @@
> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> */
>
> -static void FUNC(yuv2planeX_16)(const int16_t *filter, int filterSize,
> +static void FUNC(yuv2planeX_8_16)(const int16_t *filter, int filterSize,
>const int16_t **src, uint8_t *dest,
>const uint8_t *dither, int offset, int x)
> {
> @@ -88,7 +88,7 @@ static void FUNC(yuv2planeX)(const int16_t *filter, int
> filterSize,
> yuv2planeX_u(filter, filterSize, src, dest, dst_u, dither, offset, 0);
>
> for (i = dst_u; i < dstW - 15; i += 16)
> -FUNC(yuv2planeX_16)(filter, filterSize, src, dest + i, dither,
> +FUNC(yuv2planeX_8_16)(filter, filterSize, src, dest + i, dither,
>offset, i);
>
> yuv2planeX_u(filter, filterSize, src, dest, dstW, dither, offset, i);
> diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
> index 70da6ae..1fd392e 100644
> --- a/libswscale/ppc/swscale_vsx.c
> +++ b/libswscale/ppc/swscale_vsx.c
> @@ -83,6 +83,8 @@
> #include "swscale_ppc_template.c"
> #undef FUNC
>
> +#undef vzero
> +
> #endif /* !HAVE_BIGENDIAN */
>
> static void yuv2plane1_8_u(const int16_t *src, uint8_t *dest, int dstW,
> @@ -180,6 +182,76 @@ static void yuv2plane1_nbps_vsx(const int16_t *src,
> uint16_t *dest, int dstW,
> yuv2plane1_nbps_u(src, dest, dstW, big_endian, output_bits, i);
> }
>
> +static void yuv2planeX_nbps_u(const int16_t *filter, int filterSize,
> + const int16_t **src, uint16_t *dest, int dstW,
> + int big_endian, int output_bits, int start)
> +{
> +int i;
> +int shift = 11 + 16 - output_bits;
> +
> +for (i = start; i < dstW; i++) {
> +int val = 1 << (shift - 1);
> +int j;
> +
> +for (j = 0; j < filterSize; j++)
> +val += src[j][i] * filter[j];
> +
> +output_pixel(&dest[i], val);
> +}
> +}
> +
> +static void yuv2planeX_nbps_vsx(const int16_t *filter, int filterSize,
> +const int16_t **src, uint16_t *dest, int
> dstW,
> +int big_endian, int output_bits)
> +{
> +const int dst_u = -(uintptr_t)dest & 7;
> +const int shift = 11 + 16 - output_bits;
> +const int add = (1 << (shift - 1));
> +const int clip = (1 << output_bits) - 1;
> +const uint16_t swap = big_endian ? 8 : 0;
> +const vector uint32_t vadd = (vector uint32_t) {add, add, add, add};
> +const vector uint32_t vshift = (vector uint32_t) {shift, shift, shift,
> shift};
> +const vector uint16_t vswap = (vec
Re: [FFmpeg-devel] [PATCH V6 2/2] avcodec/libx264: add support for ROI-based encoding
On Tue, Jan 08, 2019 at 03:54:38AM +0800, Guo, Yejun wrote:
> This patch just enables the path from ffmpeg to libx264,
> the more encoders can be added later.
>
> Signed-off-by: Guo, Yejun
> ---
> libavcodec/libx264.c | 67
>
> 1 file changed, 67 insertions(+)
>
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index a68d0a7..9cfbaed 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -40,6 +40,10 @@
> #include
> #include
>
> +// from x264.h, for quant_offsets, Macroblocks are 16x16
> +// blocks of pixels (with respect to the luma plane)
> +#define MB_SIZE 16
> +
> typedef struct X264Context {
> AVClass*class;
> x264_param_tparams;
> @@ -282,6 +286,7 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt,
> const AVFrame *frame,
> x264_picture_t pic_out = {0};
> int pict_type;
> int64_t *out_opaque;
> +AVFrameSideData *sd;
>
> x264_picture_init( &x4->pic );
> x4->pic.img.i_csp = x4->params.i_csp;
> @@ -345,6 +350,68 @@ static int X264_frame(AVCodecContext *ctx, AVPacket
> *pkt, const AVFrame *frame,
> }
> }
> }
> +
> +sd = av_frame_get_side_data(frame,
> AV_FRAME_DATA_REGIONS_OF_INTEREST);
> +if (sd) {
> +static int show_aq_warning = 1;
> +static int show_interlaced_frame_warning = 1;
non constant statics are a bad idea.
there is not neccesarily just a single x264 encoder
> +if (x4->params.rc.i_aq_mode == X264_AQ_NONE && show_aq_warning) {
> +show_aq_warning = 0;
> +av_log(ctx, AV_LOG_WARNING, "Adaptive quantization must be
> enabled to use ROI encoding, skipping ROI.\n");
> +} else {
> +if (frame->interlaced_frame == 0) {
> +int mbx = (frame->width + MB_SIZE - 1) / MB_SIZE;
> +int mby = (frame->height + MB_SIZE - 1) / MB_SIZE;
> +int nb_rois;
> +AVRegionOfInterest* roi;
> +float* qoffsets;
> +qoffsets = (float*)av_mallocz_array(mbx * mby,
> sizeof(*qoffsets));
the cast is unneeded
> +if (!qoffsets)
> +return AVERROR(ENOMEM);
> +
> +nb_rois = sd->size / sizeof(AVRegionOfInterest);
> +roi = (AVRegionOfInterest*)sd->data;
> +for (int count = 0; count < nb_rois; count++) {
> +int starty = FFMIN(mby, roi->top / MB_SIZE);
> +int endy = FFMIN(mby, (roi->bottom + MB_SIZE - 1)/
> MB_SIZE);
> +int startx = FFMIN(mbx, roi->left / MB_SIZE);
> +int endx = FFMIN(mbx, (roi->right + MB_SIZE - 1)/
> MB_SIZE);
vertical alignment makes this more readable
> +float qoffset;
> +
> +if (roi->qoffset.den == 0) {
> +av_free(qoffsets);
> +av_log(ctx, AV_LOG_ERROR,
> "AVRegionOfInterest.qoffset.den should not be zero.\n");
> +return AVERROR(EINVAL);
> +}
> +qoffset = roi->qoffset.num * 1.0f / roi->qoffset.den;
> +qoffset = FFMIN(qoffset, 1.0f);
> +qoffset = FFMAX(qoffset, -1.0f);
av_clipf()
> +
> +// 25 is a number that I think it is a possible
> proper scale value.
> +qoffset = qoffset * 25;
> +
> +for (int y = starty; y < endy; y++) {
> +for (int x = startx; x < endx; x++) {
> +qoffsets[x + y*mbx] = qoffset;
> +}
> +}
> +
> +if (roi->self_size == 0) {
> +av_free(qoffsets);
> +av_log(ctx, AV_LOG_ERROR,
> "AVRegionOfInterest.self_size should be set to
> sizeof(AVRegionOfInterest).\n");
> +return AVERROR(EINVAL);
> +}
> +roi = (AVRegionOfInterest*)((char*)roi +
> roi->self_size);
> +}
> +
> +x4->pic.prop.quant_offsets = qoffsets;
> +x4->pic.prop.quant_offsets_free = av_free;
> +} else if (show_interlaced_frame_warning) {
> +show_interlaced_frame_warning = 0;
> +av_log(ctx, AV_LOG_WARNING, "interlaced_frame not
> supported for ROI encoding yet, skipping ROI.\n");
> +}
> +}
> +}
> }
>
> do {
> --
> 2.7.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
Michael
Re: [FFmpeg-devel] [PATCH V6 1/2] avutil: add ROI (Region Of Interest) data struct and bump version
On Tue, Jan 08, 2019 at 03:54:14AM +0800, Guo, Yejun wrote: > The encoders such as libx264 support different QPs offset for different MBs, > it makes possible for ROI-based encoding. It makes sense to add support > within ffmpeg to generate/accept ROI infos and pass into encoders. > > Typical usage: After AVFrame is decoded, a ffmpeg filter or user's code > generates ROI info for that frame, and the encoder finally does the > ROI-based encoding. > > The ROI info is maintained as side data of AVFrame. > > Signed-off-by: Guo, Yejun > --- > libavutil/frame.c | 1 + > libavutil/frame.h | 35 +++ > libavutil/version.h | 2 +- > 3 files changed, 37 insertions(+), 1 deletion(-) needs a update to doc/APIchanges thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/vp3data: use more compact data type
On Mon, Jan 07, 2019 at 10:45:02PM +1100, Peter Ross wrote:
> ---
> this table is used at vp3_decode_init time, and is needlessly uint32_t.
> will push in a day or so.
>
> libavcodec/vp3data.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vp3data.h b/libavcodec/vp3data.h
> index 3884bca878..c82b1b3a86 100644
> --- a/libavcodec/vp3data.h
> +++ b/libavcodec/vp3data.h
> @@ -73,7 +73,7 @@ static const uint8_t vp31_dc_scale_factor[64] = {
> 20, 10, 10, 10, 10, 10, 10, 10
> };
>
> -static const uint32_t vp31_ac_scale_factor[64] = {
> +static const uint16_t vp31_ac_scale_factor[64] = {
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/qpeg: Optimize long runs in qpeg_decode_intra() not spanning a full row
On Mon, Jan 07, 2019 at 07:41:04PM +0100, Paul B Mahol wrote:
> On 1/7/19, Michael Niedermayer wrote:
> > Fixes: Timeout
> > Fixes:
> > 11354/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
> >
> > Before: Executed
> > clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
> > in 9470 ms
> > After : Executed
> > clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
> > in 134 ms
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/qpeg.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/qpeg.c b/libavcodec/qpeg.c
> > index cb452621e7..654fd998d6 100644
> > --- a/libavcodec/qpeg.c
> > +++ b/libavcodec/qpeg.c
> > @@ -80,7 +80,10 @@ static void qpeg_decode_intra(QpegContext *qctx, uint8_t
> > *dst,
> >
> > p = bytestream2_get_byte(&qctx->buffer);
> > for(i = 0; i < run; i++) {
> > -dst[filled++] = p;
> > +int step = FFMIN(run - i, width - filled);
> > +memset(dst+filled, p, step);
> > +filled += step;
> > +i += step - 1;
> > if (filled >= width) {
> > filled = 0;
> > dst -= stride;
> > --
> > 2.20.1
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
> lgtm if output does not change.
fate-qpeg passes and it executes this codepath
do you have any other files i should test ?
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/qpeg: Optimize long runs in qpeg_decode_intra() not spanning a full row
On 1/7/19, https://ieeexplore.ieee.org/document/7291728Michael
Niedermayer wrote:
> On Mon, Jan 07, 2019 at 07:41:04PM +0100, Paul B Mahol wrote:
>> On 1/7/19, Michael Niedermayer wrote:
>> > Fixes: Timeout
>> > Fixes:
>> > 11354/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
>> >
>> > Before: Executed
>> > clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
>> > in 9470 ms
>> > After : Executed
>> > clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
>> > in 134 ms
>> >
>> > Found-by: continuous fuzzing process
>> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> > Signed-off-by: Michael Niedermayer
>> > ---
>> > libavcodec/qpeg.c | 5 -
>> > 1 file changed, 4 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/libavcodec/qpeg.c b/libavcodec/qpeg.c
>> > index cb452621e7..654fd998d6 100644
>> > --- a/libavcodec/qpeg.c
>> > +++ b/libavcodec/qpeg.c
>> > @@ -80,7 +80,10 @@ static void qpeg_decode_intra(QpegContext *qctx,
>> > uint8_t
>> > *dst,
>> >
>> > p = bytestream2_get_byte(&qctx->buffer);
>> > for(i = 0; i < run; i++) {
>> > -dst[filled++] = p;
>> > +int step = FFMIN(run - i, width - filled);
>> > +memset(dst+filled, p, step);
>> > +filled += step;
>> > +i += step - 1;
>> > if (filled >= width) {
>> > filled = 0;
>> > dst -= stride;
>> > --
>> > 2.20.1
>> >
>> > ___
>> > ffmpeg-devel mailing list
>> > ffmpeg-devel@ffmpeg.org
>> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> >
>>
>> lgtm if output does not change.
>
> fate-qpeg passes and it executes this codepath
> do you have any other files i should test ?
>
look in samples.ffmpeg.org ?
> thx
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Good people do not need laws to tell them to act responsibly, while bad
> people will find a way around the laws. -- Plato
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/qpeg: Optimize long runs in qpeg_decode_intra() not spanning a full row
On Mon, Jan 07, 2019 at 08:51:33PM +0100, Paul B Mahol wrote:
> On 1/7/19, https://ieeexplore.ieee.org/document/7291728Michael
> Niedermayer wrote:
> > On Mon, Jan 07, 2019 at 07:41:04PM +0100, Paul B Mahol wrote:
> >> On 1/7/19, Michael Niedermayer wrote:
> >> > Fixes: Timeout
> >> > Fixes:
> >> > 11354/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
> >> >
> >> > Before: Executed
> >> > clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
> >> > in 9470 ms
> >> > After : Executed
> >> > clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
> >> > in 134 ms
> >> >
> >> > Found-by: continuous fuzzing process
> >> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> >> > Signed-off-by: Michael Niedermayer
> >> > ---
> >> > libavcodec/qpeg.c | 5 -
> >> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/libavcodec/qpeg.c b/libavcodec/qpeg.c
> >> > index cb452621e7..654fd998d6 100644
> >> > --- a/libavcodec/qpeg.c
> >> > +++ b/libavcodec/qpeg.c
> >> > @@ -80,7 +80,10 @@ static void qpeg_decode_intra(QpegContext *qctx,
> >> > uint8_t
> >> > *dst,
> >> >
> >> > p = bytestream2_get_byte(&qctx->buffer);
> >> > for(i = 0; i < run; i++) {
> >> > -dst[filled++] = p;
> >> > +int step = FFMIN(run - i, width - filled);
> >> > +memset(dst+filled, p, step);
> >> > +filled += step;
> >> > +i += step - 1;
> >> > if (filled >= width) {
> >> > filled = 0;
> >> > dst -= stride;
> >> > --
> >> > 2.20.1
> >> >
> >> > ___
> >> > ffmpeg-devel mailing list
> >> > ffmpeg-devel@ffmpeg.org
> >> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >> >
> >>
> >> lgtm if output does not change.
> >
> > fate-qpeg passes and it executes this codepath
> > do you have any other files i should test ?
> >
>
> look in samples.ffmpeg.org ?
ive found and tested
qpeg-test.avi
Space.avi
Clock.avi
anything else i should test ?
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The educated differ from the uneducated as much as the living from the
dead. -- Aristotle
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/qpeg: Optimize long runs in qpeg_decode_intra() not spanning a full row
On 1/7/19, Michael Niedermayer wrote:
> On Mon, Jan 07, 2019 at 08:51:33PM +0100, Paul B Mahol wrote:
>> On 1/7/19, https://ieeexplore.ieee.org/document/7291728Michael
>> Niedermayer wrote:
>> > On Mon, Jan 07, 2019 at 07:41:04PM +0100, Paul B Mahol wrote:
>> >> On 1/7/19, Michael Niedermayer wrote:
>> >> > Fixes: Timeout
>> >> > Fixes:
>> >> > 11354/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
>> >> >
>> >> > Before: Executed
>> >> > clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
>> >> > in 9470 ms
>> >> > After : Executed
>> >> > clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5766275943366656
>> >> > in 134 ms
>> >> >
>> >> > Found-by: continuous fuzzing process
>> >> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> >> > Signed-off-by: Michael Niedermayer
>> >> > ---
>> >> > libavcodec/qpeg.c | 5 -
>> >> > 1 file changed, 4 insertions(+), 1 deletion(-)
>> >> >
>> >> > diff --git a/libavcodec/qpeg.c b/libavcodec/qpeg.c
>> >> > index cb452621e7..654fd998d6 100644
>> >> > --- a/libavcodec/qpeg.c
>> >> > +++ b/libavcodec/qpeg.c
>> >> > @@ -80,7 +80,10 @@ static void qpeg_decode_intra(QpegContext *qctx,
>> >> > uint8_t
>> >> > *dst,
>> >> >
>> >> > p = bytestream2_get_byte(&qctx->buffer);
>> >> > for(i = 0; i < run; i++) {
>> >> > -dst[filled++] = p;
>> >> > +int step = FFMIN(run - i, width - filled);
>> >> > +memset(dst+filled, p, step);
>> >> > +filled += step;
>> >> > +i += step - 1;
>> >> > if (filled >= width) {
>> >> > filled = 0;
>> >> > dst -= stride;
>> >> > --
>> >> > 2.20.1
>> >> >
>> >> > ___
>> >> > ffmpeg-devel mailing list
>> >> > ffmpeg-devel@ffmpeg.org
>> >> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> >> >
>> >>
>> >> lgtm if output does not change.
>> >
>> > fate-qpeg passes and it executes this codepath
>> > do you have any other files i should test ?
>> >
>>
>> look in samples.ffmpeg.org ?
>
> ive found and tested
> qpeg-test.avi
> Space.avi
> Clock.avi
>
> anything else i should test ?
Every single possible encoder output.
On serious side its fine.
>
> thanks
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The educated differ from the uneducated as much as the living from the
> dead. -- Aristotle
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Support HDR dynamic metdata (HDR10+) in HEVC decoder.
---
libavcodec/hevc_sei.c | 236 --
libavcodec/hevc_sei.h | 6 ++
libavcodec/hevcdec.c | 19
3 files changed, 255 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index c59bd4321e..7e59bf0813 100644
--- a/libavcodec/hevc_sei.c
+++ b/libavcodec/hevc_sei.c
@@ -25,6 +25,7 @@
#include "golomb.h"
#include "hevc_ps.h"
#include "hevc_sei.h"
+#include "libavutil/hdr_dynamic_metadata.h"
static int decode_nal_sei_decoded_picture_hash(HEVCSEIPictureHash *s,
GetBitContext *gb)
{
@@ -206,10 +207,205 @@ static int
decode_registered_user_data_closed_caption(HEVCSEIA53Caption *s, GetB
return 0;
}
-static int decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s,
GetBitContext *gb,
+static int decode_registered_user_data_dynamic_hdr_plus(AVDynamicHDRPlus *s,
GetBitContext *gb,
+void *logctx, int size)
+{
+const int luminance_den = 1;
+const int peak_luminance_den = 15;
+const int rgb_den = 10;
+const int fraction_pixel_den = 1000;
+const int knee_point_den = 4095;
+const int bezier_anchor_den = 1023;
+const int saturation_weight_den = 8;
+
+int bits_left = size * 8;
+int w, i, j;
+
+if (bits_left < 2)
+return AVERROR_INVALIDDATA;
+
+s->num_windows = get_bits(gb, 2);
+bits_left -= 2;
+if (s->num_windows < 1 || s->num_windows > 3) {
+av_log(logctx, AV_LOG_ERROR, "num_windows=%d, must be in [1, 3]\n",
+ s->num_windows);
+return AVERROR_INVALIDDATA;
+}
+
+if (bits_left < ((19 * 8 + 1) * (s->num_windows - 1)))
+return AVERROR(EINVAL);
+for (w = 1; w < s->num_windows; w++) {
+s->params[w].window_upper_left_corner_x.num = get_bits(gb, 16);
+s->params[w].window_upper_left_corner_y.num = get_bits(gb, 16);
+s->params[w].window_lower_right_corner_x.num = get_bits(gb, 16);
+s->params[w].window_lower_right_corner_y.num = get_bits(gb, 16);
+// The corners are set to absolute coordinates here. They should be
+// converted to the relative coordinates (in [0, 1]) in the decoder.
+s->params[w].window_upper_left_corner_x.den = 1;
+s->params[w].window_upper_left_corner_y.den = 1;
+s->params[w].window_lower_right_corner_x.den = 1;
+s->params[w].window_lower_right_corner_y.den = 1;
+
+s->params[w].center_of_ellipse_x = get_bits(gb, 16);
+s->params[w].center_of_ellipse_y = get_bits(gb, 16);
+s->params[w].rotation_angle = get_bits(gb, 8);
+s->params[w].semimajor_axis_internal_ellipse = get_bits(gb, 16);
+s->params[w].semimajor_axis_external_ellipse = get_bits(gb, 16);
+s->params[w].semiminor_axis_external_ellipse = get_bits(gb, 16);
+s->params[w].overlap_process_option = get_bits(gb, 1);
+bits_left -= 19 * 8 + 1;
+}
+
+if (bits_left < 28)
+return AVERROR(EINVAL);
+s->targeted_system_display_maximum_luminance.num = get_bits(gb, 27);
+s->targeted_system_display_maximum_luminance.den = luminance_den;
+s->targeted_system_display_actual_peak_luminance_flag = get_bits(gb, 1);
+bits_left -= 28;
+
+if (s->targeted_system_display_actual_peak_luminance_flag) {
+int rows, cols;
+if (bits_left < 10)
+return AVERROR(EINVAL);
+rows = get_bits(gb, 5);
+cols = get_bits(gb, 5);
+if (((rows < 2) && (rows > 25)) || ((cols < 2) && (cols > 25))) {
+av_log(logctx, AV_LOG_ERROR, "num_rows=%d, num_cols=%d, they must "
+ "be in [2, 25] for "
+ "targeted_system_display_actual_peak_luminance\n",
+ rows, cols);
+return AVERROR_INVALIDDATA;
+}
+s->num_rows_targeted_system_display_actual_peak_luminance = rows;
+s->num_cols_targeted_system_display_actual_peak_luminance = cols;
+bits_left -= 10;
+
+if (bits_left < (rows * cols * 4))
+return AVERROR(EINVAL);
+
+for (i = 0; i < rows; i++) {
+for (j = 0; j < cols; j++) {
+s->targeted_system_display_actual_peak_luminance[i][j].num =
+get_bits(gb, 4);
+s->targeted_system_display_actual_peak_luminance[i][j].den =
+peak_luminance_den;
+}
+}
+bits_left -= (rows * cols * 4);
+}
+for (w = 0; w < s->num_windows; w++) {
+if (bits_left < (3 * 17 + 17 + 4))
+return AVERROR(EINVAL);
+for (i = 0; i < 3; i++) {
+s->params[w].maxscl[i].num = get_bits(gb, 17);
+s->params[w].maxscl[i].den = rgb_den;
+}
+s->params[w].average_maxrgb.num = get_bits(gb, 17);
+s->params[w].average_maxrgb.den = rgb_den;
+s->params[w].num_distribution_maxrgb_percentiles = get_bits(gb, 4);
+bits_left -= (3 * 17 + 17 + 4
Re: [FFmpeg-devel] [PATCH V6 1/2] avutil: add ROI (Region Of Interest) data struct and bump version
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Michael Niedermayer > Sent: Tuesday, January 08, 2019 3:21 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH V6 1/2] avutil: add ROI (Region Of > Interest) data struct and bump version > > On Tue, Jan 08, 2019 at 03:54:14AM +0800, Guo, Yejun wrote: > > The encoders such as libx264 support different QPs offset for > > different MBs, it makes possible for ROI-based encoding. It makes > > sense to add support within ffmpeg to generate/accept ROI infos and pass > into encoders. > > > > Typical usage: After AVFrame is decoded, a ffmpeg filter or user's > > code generates ROI info for that frame, and the encoder finally does > > the ROI-based encoding. > > > > The ROI info is maintained as side data of AVFrame. > > > > Signed-off-by: Guo, Yejun > > --- > > libavutil/frame.c | 1 + > > libavutil/frame.h | 35 +++ > > libavutil/version.h | 2 +- > > 3 files changed, 37 insertions(+), 1 deletion(-) > > needs a update to doc/APIchanges thanks, will update in a separate patch. (looks that this file is usually updated in a separated patch). > > thx > > [...] > -- > Michael GnuPG fingerprint: > 9FF2128B147EF6730BADF133611EC787040B0FAB > > Those who would give up essential Liberty, to purchase a little temporary > Safety, deserve neither Liberty nor Safety -- Benjamin Franklin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Support HDR dynamic metdata (HDR10+) in HEVC decoder.
On 1/7/2019 8:55 PM, Mohammad Izadi wrote:
> ---
> libavcodec/hevc_sei.c | 236 --
> libavcodec/hevc_sei.h | 6 ++
> libavcodec/hevcdec.c | 19
> 3 files changed, 255 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
> index c59bd4321e..7e59bf0813 100644
> --- a/libavcodec/hevc_sei.c
> +++ b/libavcodec/hevc_sei.c
> @@ -25,6 +25,7 @@
> #include "golomb.h"
> #include "hevc_ps.h"
> #include "hevc_sei.h"
> +#include "libavutil/hdr_dynamic_metadata.h"
>
> static int decode_nal_sei_decoded_picture_hash(HEVCSEIPictureHash *s,
> GetBitContext *gb)
> {
> @@ -206,10 +207,205 @@ static int
> decode_registered_user_data_closed_caption(HEVCSEIA53Caption *s, GetB
> return 0;
> }
>
> -static int decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s,
> GetBitContext *gb,
> +static int decode_registered_user_data_dynamic_hdr_plus(AVDynamicHDRPlus *s,
> GetBitContext *gb,
> +void *logctx, int
> size)
> +{
> +const int luminance_den = 1;
> +const int peak_luminance_den = 15;
> +const int rgb_den = 10;
> +const int fraction_pixel_den = 1000;
> +const int knee_point_den = 4095;
> +const int bezier_anchor_den = 1023;
> +const int saturation_weight_den = 8;
> +
> +int bits_left = size * 8;
> +int w, i, j;
> +
> +if (bits_left < 2)
> +return AVERROR_INVALIDDATA;
> +
> +s->num_windows = get_bits(gb, 2);
> +bits_left -= 2;
> +if (s->num_windows < 1 || s->num_windows > 3) {
> +av_log(logctx, AV_LOG_ERROR, "num_windows=%d, must be in [1, 3]\n",
> + s->num_windows);
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (bits_left < ((19 * 8 + 1) * (s->num_windows - 1)))
> +return AVERROR(EINVAL);
AVERROR_INVALIDDATA for invalid bistreams, AVERROR(EINVAL) for invalid
user arguments.
> +for (w = 1; w < s->num_windows; w++) {
> +s->params[w].window_upper_left_corner_x.num = get_bits(gb, 16);
> +s->params[w].window_upper_left_corner_y.num = get_bits(gb, 16);
> +s->params[w].window_lower_right_corner_x.num = get_bits(gb, 16);
> +s->params[w].window_lower_right_corner_y.num = get_bits(gb, 16);
> +// The corners are set to absolute coordinates here. They should be
> +// converted to the relative coordinates (in [0, 1]) in the decoder.
> +s->params[w].window_upper_left_corner_x.den = 1;
> +s->params[w].window_upper_left_corner_y.den = 1;
> +s->params[w].window_lower_right_corner_x.den = 1;
> +s->params[w].window_lower_right_corner_y.den = 1;
> +
> +s->params[w].center_of_ellipse_x = get_bits(gb, 16);
> +s->params[w].center_of_ellipse_y = get_bits(gb, 16);
> +s->params[w].rotation_angle = get_bits(gb, 8);
> +s->params[w].semimajor_axis_internal_ellipse = get_bits(gb, 16);
> +s->params[w].semimajor_axis_external_ellipse = get_bits(gb, 16);
> +s->params[w].semiminor_axis_external_ellipse = get_bits(gb, 16);
> +s->params[w].overlap_process_option = get_bits(gb, 1);
> +bits_left -= 19 * 8 + 1;
> +}
> +
> +if (bits_left < 28)
> +return AVERROR(EINVAL);
> +s->targeted_system_display_maximum_luminance.num = get_bits(gb, 27);
> +s->targeted_system_display_maximum_luminance.den = luminance_den;
> +s->targeted_system_display_actual_peak_luminance_flag = get_bits(gb, 1);
> +bits_left -= 28;
> +
> +if (s->targeted_system_display_actual_peak_luminance_flag) {
> +int rows, cols;
> +if (bits_left < 10)
> +return AVERROR(EINVAL);
> +rows = get_bits(gb, 5);
> +cols = get_bits(gb, 5);
> +if (((rows < 2) && (rows > 25)) || ((cols < 2) && (cols > 25))) {
> +av_log(logctx, AV_LOG_ERROR, "num_rows=%d, num_cols=%d, they
> must "
> + "be in [2, 25] for "
> + "targeted_system_display_actual_peak_luminance\n",
> + rows, cols);
> +return AVERROR_INVALIDDATA;
> +}
> +s->num_rows_targeted_system_display_actual_peak_luminance = rows;
> +s->num_cols_targeted_system_display_actual_peak_luminance = cols;
> +bits_left -= 10;
> +
> +if (bits_left < (rows * cols * 4))
> +return AVERROR(EINVAL);
> +
> +for (i = 0; i < rows; i++) {
> +for (j = 0; j < cols; j++) {
> +s->targeted_system_display_actual_peak_luminance[i][j].num =
> +get_bits(gb, 4);
> +s->targeted_system_display_actual_peak_luminance[i][j].den =
> +peak_luminance_den;
> +}
> +}
> +bits_left -= (rows * cols * 4);
> +}
> +for (w = 0; w < s->num_windows; w++) {
> +if (bits_left < (3 * 17 + 17 + 4))
> +return AVERROR(EINVAL);
> +for
Re: [FFmpeg-devel] [PATCH V6 2/2] avcodec/libx264: add support for ROI-based encoding
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Michael Niedermayer
> Sent: Tuesday, January 08, 2019 3:20 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH V6 2/2] avcodec/libx264: add support
> for ROI-based encoding
>
> On Tue, Jan 08, 2019 at 03:54:38AM +0800, Guo, Yejun wrote:
> > This patch just enables the path from ffmpeg to libx264, the more
> > encoders can be added later.
> >
> > Signed-off-by: Guo, Yejun
> > ---
> > libavcodec/libx264.c | 67
> >
> > 1 file changed, 67 insertions(+)
> >
> > diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c index
> > a68d0a7..9cfbaed 100644
> > --- a/libavcodec/libx264.c
> > +++ b/libavcodec/libx264.c
> > @@ -40,6 +40,10 @@
> > #include
> > #include
> >
> > +// from x264.h, for quant_offsets, Macroblocks are 16x16 // blocks of
> > +pixels (with respect to the luma plane) #define MB_SIZE 16
> > +
> > typedef struct X264Context {
> > AVClass*class;
> > x264_param_tparams;
> > @@ -282,6 +286,7 @@ static int X264_frame(AVCodecContext *ctx,
> AVPacket *pkt, const AVFrame *frame,
> > x264_picture_t pic_out = {0};
> > int pict_type;
> > int64_t *out_opaque;
> > +AVFrameSideData *sd;
> >
> > x264_picture_init( &x4->pic );
> > x4->pic.img.i_csp = x4->params.i_csp;
> > @@ -345,6 +350,68 @@ static int X264_frame(AVCodecContext *ctx,
> AVPacket *pkt, const AVFrame *frame,
> > }
> > }
> > }
> > +
> > +sd = av_frame_get_side_data(frame,
> AV_FRAME_DATA_REGIONS_OF_INTEREST);
> > +if (sd) {
>
> > +static int show_aq_warning = 1;
> > +static int show_interlaced_frame_warning = 1;
>
> non constant statics are a bad idea.
> there is not neccesarily just a single x264 encoder
ok, I'll revert it.
>
>
> > +if (x4->params.rc.i_aq_mode == X264_AQ_NONE &&
> show_aq_warning) {
> > +show_aq_warning = 0;
> > +av_log(ctx, AV_LOG_WARNING, "Adaptive quantization must be
> enabled to use ROI encoding, skipping ROI.\n");
> > +} else {
> > +if (frame->interlaced_frame == 0) {
> > +int mbx = (frame->width + MB_SIZE - 1) / MB_SIZE;
> > +int mby = (frame->height + MB_SIZE - 1) / MB_SIZE;
> > +int nb_rois;
> > +AVRegionOfInterest* roi;
> > +float* qoffsets;
>
> > +qoffsets = (float*)av_mallocz_array(mbx * mby,
> > + sizeof(*qoffsets));
>
> the cast is unneeded
thanks, will remove it.
>
>
>
> > +if (!qoffsets)
> > +return AVERROR(ENOMEM);
> > +
> > +nb_rois = sd->size / sizeof(AVRegionOfInterest);
> > +roi = (AVRegionOfInterest*)sd->data;
> > +for (int count = 0; count < nb_rois; count++) {
>
> > +int starty = FFMIN(mby, roi->top / MB_SIZE);
> > +int endy = FFMIN(mby, (roi->bottom + MB_SIZE - 1)/
> MB_SIZE);
> > +int startx = FFMIN(mbx, roi->left / MB_SIZE);
> > +int endx = FFMIN(mbx, (roi->right + MB_SIZE -
> > + 1)/ MB_SIZE);
>
> vertical alignment makes this more readable
yes, will refine it.
>
>
> > +float qoffset;
> > +
> > +if (roi->qoffset.den == 0) {
> > +av_free(qoffsets);
> > +av_log(ctx, AV_LOG_ERROR,
> "AVRegionOfInterest.qoffset.den should not be zero.\n");
> > +return AVERROR(EINVAL);
> > +}
> > +qoffset = roi->qoffset.num * 1.0f /
> > + roi->qoffset.den;
>
> > +qoffset = FFMIN(qoffset, 1.0f);
> > +qoffset = FFMAX(qoffset, -1.0f);
>
> av_clipf()
thanks, will change to it.
>
> > +
> > +// 25 is a number that I think it is a possible
> > proper scale value.
> > +qoffset = qoffset * 25;
> > +
> > +for (int y = starty; y < endy; y++) {
> > +for (int x = startx; x < endx; x++) {
> > +qoffsets[x + y*mbx] = qoffset;
> > +}
> > +}
> > +
> > +if (roi->self_size == 0) {
> > +av_free(qoffsets);
> > +av_log(ctx, AV_LOG_ERROR,
> > "AVRegionOfInterest.self_size
> should be set to sizeof(AVRegionOfInterest).\n");
> > +return AVERROR(EINVAL);
> > +}
> > +roi = (AVRegionOfInterest*)((char*)roi +
> > roi->self_size);
> > +
Re: [FFmpeg-devel] [PATCH] Support HDR dynamic metdata (HDR10+) in HEVC decoder.
On Tue, 8 Jan 2019 at 00:26, Mohammad Izadi wrote:
> ---
> libavcodec/hevc_sei.c | 236 --
> libavcodec/hevc_sei.h | 6 ++
> libavcodec/hevcdec.c | 19
> 3 files changed, 255 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
> index c59bd4321e..7e59bf0813 100644
> --- a/libavcodec/hevc_sei.c
> +++ b/libavcodec/hevc_sei.c
> @@ -25,6 +25,7 @@
> #include "golomb.h"
> #include "hevc_ps.h"
> #include "hevc_sei.h"
> +#include "libavutil/hdr_dynamic_metadata.h"
>
> static int decode_nal_sei_decoded_picture_hash(HEVCSEIPictureHash *s,
> GetBitContext *gb)
> {
> @@ -206,10 +207,205 @@ static int
> decode_registered_user_data_closed_caption(HEVCSEIA53Caption *s, GetB
> return 0;
> }
>
> -static int decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s,
> GetBitContext *gb,
> +static int decode_registered_user_data_dynamic_hdr_plus(AVDynamicHDRPlus
> *s, GetBitContext *gb,
> +void *logctx, int
> size)
> +{
> +const int luminance_den = 1;
> +const int peak_luminance_den = 15;
> +const int rgb_den = 10;
> +const int fraction_pixel_den = 1000;
> +const int knee_point_den = 4095;
> +const int bezier_anchor_den = 1023;
> +const int saturation_weight_den = 8;
> +
> +int bits_left = size * 8;
> +int w, i, j;
> +
> +if (bits_left < 2)
> +return AVERROR_INVALIDDATA;
> +
> +s->num_windows = get_bits(gb, 2);
> +bits_left -= 2;
>
Remove bits_left. You can check how many bits you've read via
get_bits_count (just keep the start value as an offset to subtract).
+if (s->num_windows < 1 || s->num_windows > 3) {
> +av_log(logctx, AV_LOG_ERROR, "num_windows=%d, must be in [1,
> 3]\n",
> + s->num_windows);
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (bits_left < ((19 * 8 + 1) * (s->num_windows - 1)))
> +return AVERROR(EINVAL);
> +for (w = 1; w < s->num_windows; w++) {
> +s->params[w].window_upper_left_corner_x.num = get_bits(gb, 16);
> +s->params[w].window_upper_left_corner_y.num = get_bits(gb, 16);
> +s->params[w].window_lower_right_corner_x.num = get_bits(gb, 16);
> +s->params[w].window_lower_right_corner_y.num = get_bits(gb, 16);
> +// The corners are set to absolute coordinates here. They should
> be
> +// converted to the relative coordinates (in [0, 1]) in the
> decoder.
> +s->params[w].window_upper_left_corner_x.den = 1;
> +s->params[w].window_upper_left_corner_y.den = 1;
> +s->params[w].window_lower_right_corner_x.den = 1;
> +s->params[w].window_lower_right_corner_y.den = 1;
> +
> +s->params[w].center_of_ellipse_x = get_bits(gb, 16);
> +s->params[w].center_of_ellipse_y = get_bits(gb, 16);
> +s->params[w].rotation_angle = get_bits(gb, 8);
> +s->params[w].semimajor_axis_internal_ellipse = get_bits(gb, 16);
> +s->params[w].semimajor_axis_external_ellipse = get_bits(gb, 16);
> +s->params[w].semiminor_axis_external_ellipse = get_bits(gb, 16);
> +s->params[w].overlap_process_option = get_bits(gb, 1);
> +bits_left -= 19 * 8 + 1;
> +}
> +
> +if (bits_left < 28)
> +return AVERROR(EINVAL);
> +s->targeted_system_display_maximum_luminance.num = get_bits(gb, 27);
> +s->targeted_system_display_maximum_luminance.den = luminance_den;
> +s->targeted_system_display_actual_peak_luminance_flag = get_bits(gb,
> 1);
> +bits_left -= 28;
> +
> +if (s->targeted_system_display_actual_peak_luminance_flag) {
> +int rows, cols;
> +if (bits_left < 10)
> +return AVERROR(EINVAL);
> +rows = get_bits(gb, 5);
> +cols = get_bits(gb, 5);
> +if (((rows < 2) && (rows > 25)) || ((cols < 2) && (cols > 25))) {
> +av_log(logctx, AV_LOG_ERROR, "num_rows=%d, num_cols=%d, they
> must "
> + "be in [2, 25] for "
> + "targeted_system_display_actual_peak_luminance\n",
> + rows, cols);
>
Align this better, we don't have strict 80 col line rule.
+return AVERROR_INVALIDDATA;
> +}
> +s->num_rows_targeted_system_display_actual_peak_luminance = rows;
> +s->num_cols_targeted_system_display_actual_peak_luminance = cols;
> +bits_left -= 10;
> +
> +if (bits_left < (rows * cols * 4))
> +return AVERROR(EINVAL);
> +
> +for (i = 0; i < rows; i++) {
> +for (j = 0; j < cols; j++) {
> +
> s->targeted_system_display_actual_peak_luminance[i][j].num =
> +get_bits(gb, 4);
> +
> s->targeted_system_display_actual_peak_luminance[i][j].den =
> +peak_luminance_den;
>
Same, just put the assignment values on the same line.
+}
> +}
> +bits_left -= (rows * cols * 4);
> +}
>
[FFmpeg-devel] [PATCH V7 1/3] avutil: add ROI (Region Of Interest) data struct and bump version
The encoders such as libx264 support different QPs offset for different MBs,
it makes possible for ROI-based encoding. It makes sense to add support
within ffmpeg to generate/accept ROI infos and pass into encoders.
Typical usage: After AVFrame is decoded, a ffmpeg filter or user's code
generates ROI info for that frame, and the encoder finally does the
ROI-based encoding.
The ROI info is maintained as side data of AVFrame.
Signed-off-by: Guo, Yejun
---
libavutil/frame.c | 1 +
libavutil/frame.h | 35 +++
libavutil/version.h | 2 +-
3 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 34a6210..dcf1fc3 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -841,6 +841,7 @@ const char *av_frame_side_data_name(enum
AVFrameSideDataType type)
case AV_FRAME_DATA_QP_TABLE_DATA: return "QP table data";
#endif
case AV_FRAME_DATA_DYNAMIC_HDR_PLUS: return "HDR Dynamic Metadata
SMPTE2094-40 (HDR10+)";
+case AV_FRAME_DATA_REGIONS_OF_INTEREST: return "Regions Of Interest";
}
return NULL;
}
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 582ac47..8d0dfed 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -173,6 +173,12 @@ enum AVFrameSideDataType {
* volume transform - application 4 of SMPTE 2094-40:2016 standard.
*/
AV_FRAME_DATA_DYNAMIC_HDR_PLUS,
+
+/**
+ * Regions Of Interest, the data is an array of AVRegionOfInterest type,
the number of
+ * array element is implied by AVFrameSideData.size /
AVRegionOfInterest.self_size.
+ */
+AV_FRAME_DATA_REGIONS_OF_INTEREST,
};
enum AVActiveFormatDescription {
@@ -201,6 +207,35 @@ typedef struct AVFrameSideData {
} AVFrameSideData;
/**
+ * Structure to hold Region Of Interest.
+ *
+ * self_size specifies the size of this data structure. This value
+ * should be set to sizeof(AVRegionOfInterest). EINVAL is returned if
self_size is zero.
+ *
+ * Number of pixels to discard from the top/bottom/left/right border of
+ * the frame to obtain the region of interest of the frame.
+ * They are encoder dependent and will be extended internally
+ * if the codec requires an alignment.
+ * If the regions overlap, the last value in the list will be used.
+ *
+ * qoffset is quant offset, and base rule here:
+ * returns EINVAL if AVRational.den is zero.
+ * the value (num/den) range is [-1.0, 1.0], clamp to +-1.0 if out of range.
+ * 0 means no picture quality change,
+ * negtive offset asks for better quality (and the best with value -1.0),
+ * positive offset asks for worse quality (and the worst with value 1.0).
+ * How to explain/implement the different quilaity requirement is encoder
dependent.
+ */
+typedef struct AVRegionOfInterest {
+uint32_t self_size;
+int top;
+int bottom;
+int left;
+int right;
+AVRational qoffset;
+} AVRegionOfInterest;
+
+/**
* This structure describes decoded (raw) audio or video data.
*
* AVFrame must be allocated using av_frame_alloc(). Note that this only
diff --git a/libavutil/version.h b/libavutil/version.h
index f997615..1fcdea9 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 56
-#define LIBAVUTIL_VERSION_MINOR 25
+#define LIBAVUTIL_VERSION_MINOR 26
#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V7 2/3] doc/APIchanges: add entry for AV_FRAME_DATA_REGIONS_OF_INTEREST
Signed-off-by: Guo, Yejun --- doc/APIchanges | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/APIchanges b/doc/APIchanges index 5889fb2..a39a3ff 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -15,6 +15,9 @@ libavutil: 2017-10-21 API changes, most recent first: +2019-01-08 - xx - lavu 56.26.100 - frame.h + Add AV_FRAME_DATA_REGIONS_OF_INTEREST + 2018-12-21 - 2744d6b364 - lavu 56.25.100 - hdr_dynamic_metadata.h Add AV_FRAME_DATA_DYNAMIC_HDR_PLUS enum value, av_dynamic_hdr_plus_alloc(), av_dynamic_hdr_plus_create_side_data() functions, and related structs. -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V7 3/3] avcodec/libx264: add support for ROI-based encoding
This patch just enables the path from ffmpeg to libx264,
the more encoders can be added later.
Signed-off-by: Guo, Yejun
---
libavcodec/libx264.c | 62
1 file changed, 62 insertions(+)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index a68d0a7..a3493f3 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -40,6 +40,10 @@
#include
#include
+// from x264.h, for quant_offsets, Macroblocks are 16x16
+// blocks of pixels (with respect to the luma plane)
+#define MB_SIZE 16
+
typedef struct X264Context {
AVClass*class;
x264_param_tparams;
@@ -282,6 +286,7 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt,
const AVFrame *frame,
x264_picture_t pic_out = {0};
int pict_type;
int64_t *out_opaque;
+AVFrameSideData *sd;
x264_picture_init( &x4->pic );
x4->pic.img.i_csp = x4->params.i_csp;
@@ -345,6 +350,63 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt,
const AVFrame *frame,
}
}
}
+
+sd = av_frame_get_side_data(frame, AV_FRAME_DATA_REGIONS_OF_INTEREST);
+if (sd) {
+if (x4->params.rc.i_aq_mode == X264_AQ_NONE) {
+av_log(ctx, AV_LOG_WARNING, "Adaptive quantization must be
enabled to use ROI encoding, skipping ROI.\n");
+} else {
+if (frame->interlaced_frame == 0) {
+int mbx = (frame->width + MB_SIZE - 1) / MB_SIZE;
+int mby = (frame->height + MB_SIZE - 1) / MB_SIZE;
+int nb_rois;
+AVRegionOfInterest* roi;
+float* qoffsets;
+qoffsets = av_mallocz_array(mbx * mby, sizeof(*qoffsets));
+if (!qoffsets)
+return AVERROR(ENOMEM);
+
+nb_rois = sd->size / sizeof(AVRegionOfInterest);
+roi = (AVRegionOfInterest*)sd->data;
+for (int count = 0; count < nb_rois; count++) {
+int starty = FFMIN(mby, roi->top / MB_SIZE);
+int endy = FFMIN(mby, (roi->bottom + MB_SIZE - 1)/
MB_SIZE);
+int startx = FFMIN(mbx, roi->left / MB_SIZE);
+int endx = FFMIN(mbx, (roi->right + MB_SIZE - 1)/
MB_SIZE);
+float qoffset;
+
+if (roi->qoffset.den == 0) {
+av_free(qoffsets);
+av_log(ctx, AV_LOG_ERROR,
"AVRegionOfInterest.qoffset.den should not be zero.\n");
+return AVERROR(EINVAL);
+}
+qoffset = roi->qoffset.num * 1.0f / roi->qoffset.den;
+qoffset = av_clipf(qoffset, -1.0f, 1.0f);
+
+// 25 is a number that I think it is a possible proper
scale value.
+qoffset = qoffset * 25;
+
+for (int y = starty; y < endy; y++) {
+for (int x = startx; x < endx; x++) {
+qoffsets[x + y*mbx] = qoffset;
+}
+}
+
+if (roi->self_size == 0) {
+av_free(qoffsets);
+av_log(ctx, AV_LOG_ERROR,
"AVRegionOfInterest.self_size should be set to sizeof(AVRegionOfInterest).\n");
+return AVERROR(EINVAL);
+}
+roi = (AVRegionOfInterest*)((char*)roi +
roi->self_size);
+}
+
+x4->pic.prop.quant_offsets = qoffsets;
+x4->pic.prop.quant_offsets_free = av_free;
+} else {
+av_log(ctx, AV_LOG_WARNING, "interlaced_frame not
supported for ROI encoding yet, skipping ROI.\n");
+}
+}
+}
}
do {
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] patch for failing on WavPack DSD files
On 1/6/19 4:43 AM, Carl Eugen Hoyos wrote: > 2019-01-03 6:19 GMT+01:00, David Bryant : >> On 12/28/18 3:56 AM, Paul B Mahol wrote: >>> On 12/24/18, Derek Buitenhuis wrote: On 24/12/2018 17:47, David Bryant wrote: > I want to do that, but am swamped at work right now, so it will probably > be a few months before I can get to that. > > In the meantime, I think this patch would be a safe stopgap (and prevent > the Kodi crash). I think it's OK for the meantime (my opinion). >>> Applied. >> The guys at Kodi asked me to request that this patch be backported to 4.0. > While this may be ok, somebody should tell the Kodi developers > to fix the crash as I would expect it's possible to create files > that are still tried to be decoded but produce identical output > as before. > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I agree. In fact, take a WavPack DSD file and clear the bit that this patch checks for, and I'll bet you'll get exactly the old behavior. It should be investigated as to why Kodi crashes with these files while FFmpeg just spews a bunch of error messages. -David ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
