Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: Remove dead code in vps_id check
On Sun, 22. Sep 00:44, Carl Eugen Hoyos wrote:
> Am Sa., 21. Sept. 2019 um 04:06 Uhr schrieb Andriy Gelman
> :
> >
> > From: Andriy Gelman
> >
> > Since reading 4 bits always returns a value in the range [0, 15], the
> > check for vps_id >= HEVC_MAX_VPS_COUNT, where HEVC_MAX_VPS_COUNT = 16, is
> > redudant.
> > ---
> > libavcodec/hevc_ps.c | 12 ++--
> > 1 file changed, 2 insertions(+), 10 deletions(-)
> >
> > diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> > index abf08b919b..498467730b 100644
> > --- a/libavcodec/hevc_ps.c
> > +++ b/libavcodec/hevc_ps.c
> > @@ -447,11 +447,7 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
> > AVCodecContext *avctx,
> > }
> > memcpy(vps->data, gb->buffer, vps->data_size);
> >
> > -vps_id = get_bits(gb, 4);
> > -if (vps_id >= HEVC_MAX_VPS_COUNT) {
> > -av_log(avctx, AV_LOG_ERROR, "VPS id out of range: %d\n", vps_id);
> > -goto err;
> > -}
> > +vps_id = get_bits(gb, 4); // vps_id in [0, HEVC_MAX_VPS_COUNT-1] so no
> > check needed
> >
> > if (get_bits(gb, 2) != 3) { // vps_reserved_three_2bits
> > av_log(avctx, AV_LOG_ERROR, "vps_reserved_three_2bits is not
> > three\n");
> > @@ -882,11 +878,7 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
> > unsigned int *sps_id,
> >
> > // Coded parameters
> >
> > -sps->vps_id = get_bits(gb, 4);
> > -if (sps->vps_id >= HEVC_MAX_VPS_COUNT) {
> > -av_log(avctx, AV_LOG_ERROR, "VPS id out of range: %d\n",
> > sps->vps_id);
> > -return AVERROR_INVALIDDATA;
> > -}
> > +sps->vps_id = get_bits(gb, 4); // sps->vps_id in [0,
> > HEVC_MAX_VPS_COUNT-1] so no check needed
>
> The comments look unneeded.
ok, I removed and sent updated version.
Thanks,
--
Andriy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avcodec/hevc_ps: Remove dead code in vps_id check
From: Andriy Gelman
Since reading 4 bits always returns a value in the range [0, 15], the
check for vps_id >= HEVC_MAX_VPS_COUNT, where HEVC_MAX_VPS_COUNT = 16, is
redundant.
Signed-off-by: Andriy Gelman
---
libavcodec/hevc_ps.c | 8
1 file changed, 8 deletions(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index abf08b919b..a30b8b8022 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -448,10 +448,6 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
AVCodecContext *avctx,
memcpy(vps->data, gb->buffer, vps->data_size);
vps_id = get_bits(gb, 4);
-if (vps_id >= HEVC_MAX_VPS_COUNT) {
-av_log(avctx, AV_LOG_ERROR, "VPS id out of range: %d\n", vps_id);
-goto err;
-}
if (get_bits(gb, 2) != 3) { // vps_reserved_three_2bits
av_log(avctx, AV_LOG_ERROR, "vps_reserved_three_2bits is not three\n");
@@ -883,10 +879,6 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
unsigned int *sps_id,
// Coded parameters
sps->vps_id = get_bits(gb, 4);
-if (sps->vps_id >= HEVC_MAX_VPS_COUNT) {
-av_log(avctx, AV_LOG_ERROR, "VPS id out of range: %d\n", sps->vps_id);
-return AVERROR_INVALIDDATA;
-}
if (vps_list && !vps_list[sps->vps_id]) {
av_log(avctx, AV_LOG_ERROR, "VPS %d does not exist\n",
--
2.23.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v4 2/2] avcodec/v210dec: add the frame and slice threading support
From: Limin Wang
The multithread is avoid one core cpu is full with other filter like scale etc.
About the performance, the gain is very small, below is my testing for
performance.
In order to avoid the disk bottleneck, I'll use stream_loop mode for 10 frame
only.
./ffmpeg -y -i ~/Movies/4k_Rec709_ProResHQ.mov -c:v v210 -f rawvideo -frames 10
~/Movies/1.v210
master:
./ffmpeg -threads 1 -s 4096x3072 -stream_loop 100 -i ~/Movies/1.v210 -benchmark
-f null -
frame= 1010 fps= 42 q=-0.0 Lsize=N/A time=00:00:40.40 bitrate=N/A speed=1.69x
video:529kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: unknown
bench: utime=10.082s stime=13.784s rtime=23.889s
bench: maxrss=147836928kB
patch applied:
./ffmpeg -threads 4 -thread_type frame+slice -s 4096x3072 -stream_loop 100 -i
~/Movies/1.v210 -benchmark -f null -
frame= 1010 fps= 55 q=-0.0 Lsize=N/A time=00:00:40.40 bitrate=N/A speed=2.22x
video:529kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: unknown
bench: utime=11.407s stime=17.258s rtime=18.279s
bench: maxrss=442884096kB
Signed-off-by: Limin Wang
---
libavcodec/v210dec.c | 131 ---
1 file changed, 83 insertions(+), 48 deletions(-)
diff --git a/libavcodec/v210dec.c b/libavcodec/v210dec.c
index 6ce18aa..2e46342 100644
--- a/libavcodec/v210dec.c
+++ b/libavcodec/v210dec.c
@@ -28,6 +28,7 @@
#include "libavutil/internal.h"
#include "libavutil/mem.h"
#include "libavutil/intreadwrite.h"
+#include "thread.h"
#define READ_PIXELS(a, b, c) \
do { \
@@ -37,6 +38,12 @@
*c++ = (val >> 20) & 0x3FF; \
} while (0)
+typedef struct ThreadData {
+AVFrame *frame;
+uint8_t *buf;
+int stride;
+} ThreadData;
+
static void v210_planar_unpack_c(const uint32_t *src, uint16_t *y, uint16_t
*u, uint16_t *v, int width)
{
uint32_t val;
@@ -70,55 +77,28 @@ static av_cold int decode_init(AVCodecContext *avctx)
return 0;
}
-static int decode_frame(AVCodecContext *avctx, void *data, int *got_frame,
-AVPacket *avpkt)
+static int v210_decode_slice(AVCodecContext *avctx, void *arg, int jobnr, int
threadnr)
{
V210DecContext *s = avctx->priv_data;
-
-int h, w, ret, stride, aligned_input;
-AVFrame *pic = data;
-const uint8_t *psrc = avpkt->data;
+int h, w;
+ThreadData *td = arg;
+AVFrame *frame = td->frame;
+int stride = td->stride;
+int slice_h = avctx->height / avctx->thread_count;
+int slice_m = avctx->height % avctx->thread_count;
+int slice_start = jobnr * slice_h;
+int slice_end = slice_start + slice_h;
+const uint8_t *psrc = td->buf + stride * slice_start;
uint16_t *y, *u, *v;
-if (s->custom_stride )
-stride = s->custom_stride;
-else {
-int aligned_width = ((avctx->width + 47) / 48) * 48;
-stride = aligned_width * 8 / 3;
-}
-
-if (avpkt->size < stride * avctx->height) {
-if avctx->width + 23) / 24) * 24 * 8) / 3 * avctx->height ==
avpkt->size) {
-stride = avpkt->size / avctx->height;
-if (!s->stride_warning_shown)
-av_log(avctx, AV_LOG_WARNING, "Broken v210 with too small
padding (64 byte) detected\n");
-s->stride_warning_shown = 1;
-} else {
-av_log(avctx, AV_LOG_ERROR, "packet too small\n");
-return AVERROR_INVALIDDATA;
-}
-}
-if (avctx->codec_tag == MKTAG('C', '2', '1', '0')
-&& AV_RN32(psrc) == AV_RN32("INFO")
-&& avpkt->size - 64 >= stride * avctx->height)
-psrc += 64;
-
-aligned_input = !((uintptr_t)psrc & 0x1f) && !(stride & 0x1f);
-if (aligned_input != s->aligned_input) {
-s->aligned_input = aligned_input;
-ff_v210dec_init(s);
-}
-
-if ((ret = ff_get_buffer(avctx, pic, 0)) < 0)
-return ret;
-
-y = (uint16_t*)pic->data[0];
-u = (uint16_t*)pic->data[1];
-v = (uint16_t*)pic->data[2];
-pic->pict_type = AV_PICTURE_TYPE_I;
-pic->key_frame = 1;
+/* add the remaining slice for the last job */
+if (jobnr == avctx->thread_count - 1)
+slice_end += slice_m;
-for (h = 0; h < avctx->height; h++) {
+y = (uint16_t*)frame->data[0] + slice_start * frame->linesize[0] / 2;
+u = (uint16_t*)frame->data[1] + slice_start * frame->linesize[1] / 2;
+v = (uint16_t*)frame->data[2] + slice_start * frame->linesize[2] / 2;
+for (h = slice_start; h < slice_end; h++) {
const uint32_t *src = (const uint32_t*)psrc;
uint32_t val;
@@ -154,10 +134,63 @@ static int decode_frame(AVCodecContext *avctx, void
*data, int *got_frame,
}
psrc += stride;
-y += pic->linesize[0] / 2 - avctx->width + (avctx->width & 1);
-u += pic->linesize[1] / 2 - avctx->width / 2;
-v += pic->linesize[2] / 2 - avctx->width / 2;
+y += frame->linesize[0] / 2 - avctx->width
Re: [FFmpeg-devel] [PATCH v2 2/2] avcodec/v210dec: add the frame and slice threading support
On Sat, Sep 21, 2019 at 11:04:27PM +0200, Michael Niedermayer wrote:
> On Sat, Sep 21, 2019 at 07:45:58AM +0800, Limin Wang wrote:
> > On Fri, Sep 20, 2019 at 07:57:10PM +0200, Michael Niedermayer wrote:
> > > On Fri, Sep 06, 2019 at 11:28:29PM +0800, lance.lmw...@gmail.com wrote:
> > > > From: Limin Wang
> > > >
> > > > The multithread is avoid one core cpu is full with other filter like
> > > > scale etc.
> > > > About the performance, the gain is very small, below is my testing for
> > > > performance.
> > > > In order to avoid the disk bottleneck, I'll use stream_loop mode for 10
> > > > frame
> > > > only.
> > > >
> > > > ./ffmpeg -y -i ~/Movies/4k_Rec709_ProResHQ.mov -c:v v210 -f rawvideo
> > > > -frames 10
> > > > ~/Movies/1.v210
> > > >
> > > > master:
> > > > ./ffmpeg -threads 1 -s 4096x3072 -stream_loop 100 -i ~/Movies/1.v210
> > > > -benchmark
> > > > -f null -
> > > > frame= 1010 fps= 42 q=-0.0 Lsize=N/A time=00:00:40.40 bitrate=N/A
> > > > speed=1.69x
> > > > video:529kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
> > > > muxing
> > > > overhead: unknown
> > > > bench: utime=10.082s stime=13.784s rtime=23.889s
> > > > bench: maxrss=147836928kB
> > > >
> > > > patch applied:
> > > > ./ffmpeg -threads 4 -thread_type frame+slice -s 4096x3072 -stream_loop
> > > > 100 -i
> > > > ~/Movies/1.v210 -benchmark -f null -
> > > >
> > > > frame= 1010 fps= 55 q=-0.0 Lsize=N/A time=00:00:40.40 bitrate=N/A
> > > > speed=2.22x
> > > > video:529kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
> > > > muxing
> > > > overhead: unknown
> > > > bench: utime=11.407s stime=17.258s rtime=18.279s
> > > > bench: maxrss=442884096kB
> > > >
> > > > Signed-off-by: Limin Wang
> > > > ---
> > > > libavcodec/v210dec.c | 135
> > > > +--
> > > > libavcodec/v210dec.h | 1 +
> > > > 2 files changed, 88 insertions(+), 48 deletions(-)
> > > >
> > > > diff --git a/libavcodec/v210dec.c b/libavcodec/v210dec.c
> > > > index 6ce18aa..2cdb99e 100644
> > > > --- a/libavcodec/v210dec.c
> > > > +++ b/libavcodec/v210dec.c
> > > > @@ -28,6 +28,7 @@
> > > > #include "libavutil/internal.h"
> > > > #include "libavutil/mem.h"
> > > > #include "libavutil/intreadwrite.h"
> > > > +#include "thread.h"
> > > >
> > > > #define READ_PIXELS(a, b, c) \
> > > > do { \
> > > > @@ -37,6 +38,13 @@
> > > > *c++ = (val >> 20) & 0x3FF; \
> > > > } while (0)
> > > >
> > > > +#define MAX_SLICES 32
> > > > +typedef struct ThreadData {
> > > > +AVFrame *frame;
> > > > +uint8_t *buf;
> > > > +int stride;
> > > > +} ThreadData;
> > > > +
> > > > static void v210_planar_unpack_c(const uint32_t *src, uint16_t *y,
> > > > uint16_t *u, uint16_t *v, int width)
> > > > {
> > > > uint32_t val;
> > > > @@ -67,58 +75,32 @@ static av_cold int decode_init(AVCodecContext
> > > > *avctx)
> > > > s->aligned_input = 0;
> > > > ff_v210dec_init(s);
> > > >
> > > > +s->slice_count = av_clip(avctx->thread_count, 1, MAX_SLICES);
> > >
> > > why is there a MAX_SLICES ?
> >
> > It's limit the slice thread count, if it's not OK, I can use
> > MAX_AUTO_THREADS for max.
>
> why is a limit needed here ?
> where does avctx->thread_count get a bad value ?
No other limit, only thread_count need great than 0, by my testing, I'll be
auto thread even
using -threads 0, so it's OK to remove it.
>
> This feels a bit arbitrary to limit it to 32 (or any number)
> will that be still correct in 10 years ? if not then this is
> not a good way to limit it
>
> thx
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The misfortune of the wise is better than the prosperity of the fool.
> -- Epicurus
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] avcodec/v210enc: add yuv420p/yuv420p10 input pixel format support
> On Sep 21, 2019, at 4:44 PM, Michael Niedermayer > wrote: > >> The patch just expands 4:2:0 to 4:2:2 while properly supporting interlaced >> chroma. > > 4:2:0 and 4:2:2 have a chroma plane with different resolution. > converting between planes of different resolution is what i called scaling. > > >> It avoids having to auto insert the swscale filter in the case where there >> is no scaling required (e.g. H.264 4:2:0 video being output to decklink in >> its original resolution). > > yes, doing an operation in the encoder avoids a filter being inserted which > does that operation. > Thats true for every encoder and every filter. The key thing here is the encoder is already touching every pixel, so avoiding having the need for the filter essentially allows the conversion to happen at essentially zero cost (as we repack the pixels into the requisite v210 layout). > Also replacing interpolation by a nearest neighbor implementation > is quite expectedly faster. Yes, and we can certainly argue about whether doing interpolation of chroma when doing 4:2:0 to 4:2:2 actually has any visible benefit. I can however say the cost of having swscaler in the pipeline is considerable. In fact I didn’t appreciate it myself until I was trying to deliver 1080p60 in realtime to four decklink outputs and couldn’t keep up on my target platform. And because filters generally aren’t threaded, I got hit with one of those cases where I had to break out the profiler and ask “why on Earth is the main ffmpeg thread so busy?" > one problem is > the user can setup the scale filter with high quality in mind or with > low quality and speed in mind. > But after this patch she always gets low quality because the low quality > convertion code is hardcoded in the encoder which pretends to support 420. > The outside code has no chance to know it shouldnt feed 420 if high quality > is wanted. The user can still insert a scaler explicitly or use the pix_fmt argument so the format filter gets put into the pipeline. > > Also why should this be in one encoder and not be available to other > encoders supporting 4:2:2 input ? > A solution should work for all of them I would assume this would really only be helpful in encoders which only support 4:2:2 and not 4:2:0, since typical encoders that accept 4:2:0 would preserve that in their resulting encoding (i.e. they wouldn’t blindly upscale 4:2:0 to 4:2:2 for no good reason). I did actually consider doing a separate filter which just does packed/planer conversion and 4:2:0 to 4:2:2 (as opposed to swscaler). In this case though the additional modularity in such a filter was outweighed by my goal to minimize the number of times I’m copying the frame data. Combining it with the v210 encoding meant only a single pass over the data. > > Iam not sure what is the best solution but simply hardcoding this in > one encoder feels rather wrong The scale filter performs three basic roles: 1. Scaling 2. Packed to planer conversion (or vice versa) 3. Colorspace conversion I supposed potentially someone could redesign swscale to include the option to not take the slow path for cases where scaling isn’t actually required (i.e. cases where only 2 and 3 are needed). Just so we’re all on the same page - this wasn’t a case of random or premature optimization. I have a specific use case where I’m decoding four instances of 1080p60 video and the platform can’t keep up without this change. It’s the result of actually profiling the entire pipeline as opposed to some unit test with a benchmark. In fact I don’t particularly agree with Limin's numbers where he used the benchmark option, since that fails to take into account caching behavior or memory bandwidth on a platform which is constrained (a problem which is exacerbated when running multiple instances). In a perfect world we would have very small operations which each perform some discrete function, and we can combine all of those in a pipeline. In the real world though, significant benefits can be gained by combining certain operations to avoid copying the same pixels over and over again. Devin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] avcodec/mpeg4audio: add avpriv_mpeg4audio_get_config2()
Identical to avpriv_mpeg4audio_get_config() except taking a size argument in
bytes, and featuring a new logging context paremeter.
Schedule avpriv_mpeg4audio_get_config() for removal as soon as major is bumped
as well.
Signed-off-by: James Almer
---
libavcodec/aacdec_template.c | 2 +-
libavcodec/mpeg4audio.c | 22 --
libavcodec/mpeg4audio.h | 17 -
3 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 6e086e00df..8726c8b828 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -975,7 +975,7 @@ static int decode_audio_specific_config_gb(AACContext *ac,
int i, ret;
GetBitContext gbc = *gb;
-if ((i = ff_mpeg4audio_get_config_gb(m4ac, , sync_extension)) < 0)
+if ((i = ff_mpeg4audio_get_config_gb(m4ac, , sync_extension, avctx)) <
0)
return AVERROR_INVALIDDATA;
if (m4ac->sampling_index > 12) {
diff --git a/libavcodec/mpeg4audio.c b/libavcodec/mpeg4audio.c
index 219714752f..6962a42537 100644
--- a/libavcodec/mpeg4audio.c
+++ b/libavcodec/mpeg4audio.c
@@ -84,7 +84,7 @@ static inline int get_sample_rate(GetBitContext *gb, int
*index)
}
int ff_mpeg4audio_get_config_gb(MPEG4AudioConfig *c, GetBitContext *gb,
-int sync_extension)
+int sync_extension, void *logctx)
{
int specific_config_bitindex, ret;
int start_bit_index = get_bits_count(gb);
@@ -152,6 +152,7 @@ int ff_mpeg4audio_get_config_gb(MPEG4AudioConfig *c,
GetBitContext *gb,
return specific_config_bitindex - start_bit_index;
}
+#if LIBAVCODEC_VERSION_MAJOR < 59
int avpriv_mpeg4audio_get_config(MPEG4AudioConfig *c, const uint8_t *buf,
int bit_size, int sync_extension)
{
@@ -165,5 +166,22 @@ int avpriv_mpeg4audio_get_config(MPEG4AudioConfig *c,
const uint8_t *buf,
if (ret < 0)
return ret;
-return ff_mpeg4audio_get_config_gb(c, , sync_extension);
+return ff_mpeg4audio_get_config_gb(c, , sync_extension, NULL);
+}
+#endif
+
+int avpriv_mpeg4audio_get_config2(MPEG4AudioConfig *c, const uint8_t *buf,
+ int size, int sync_extension, void *logctx)
+{
+GetBitContext gb;
+int ret;
+
+if (size <= 0)
+return AVERROR_INVALIDDATA;
+
+ret = init_get_bits8(, buf, size);
+if (ret < 0)
+return ret;
+
+return ff_mpeg4audio_get_config_gb(c, , sync_extension, logctx);
}
diff --git a/libavcodec/mpeg4audio.h b/libavcodec/mpeg4audio.h
index b9cea8af17..00aa680c13 100644
--- a/libavcodec/mpeg4audio.h
+++ b/libavcodec/mpeg4audio.h
@@ -53,11 +53,13 @@ extern const uint8_t ff_mpeg4audio_channels[8];
* @param[in] cMPEG4AudioConfig structure to fill.
* @param[in] gb Extradata from container.
* @param[in] sync_extension look for a sync extension after config if true.
+ * @param[in] logctx opaque struct starting with an AVClass element, used for
logging.
* @return On error -1 is returned, on success AudioSpecificConfig bit index
in extradata.
*/
int ff_mpeg4audio_get_config_gb(MPEG4AudioConfig *c, GetBitContext *gb,
-int sync_extension);
+int sync_extension, void *logctx);
+#if LIBAVCODEC_VERSION_MAJOR < 59
/**
* Parse MPEG-4 systems extradata from a raw buffer to retrieve audio
configuration.
* @param[in] cMPEG4AudioConfig structure to fill.
@@ -68,6 +70,19 @@ int ff_mpeg4audio_get_config_gb(MPEG4AudioConfig *c,
GetBitContext *gb,
*/
int avpriv_mpeg4audio_get_config(MPEG4AudioConfig *c, const uint8_t *buf,
int bit_size, int sync_extension);
+#endif
+
+/**
+ * Parse MPEG-4 systems extradata from a raw buffer to retrieve audio
configuration.
+ * @param[in] cMPEG4AudioConfig structure to fill.
+ * @param[in] buf Extradata from container.
+ * @param[in] size Extradata size in bytes.
+ * @param[in] sync_extension look for a sync extension after config if true.
+ * @param[in] logctx opaque struct starting with an AVClass element, used for
logging.
+ * @return negative AVERROR code on error, AudioSpecificConfig bit index in
extradata on success.
+ */
+int avpriv_mpeg4audio_get_config2(MPEG4AudioConfig *c, const uint8_t *buf,
+ int size, int sync_extension, void *logctx);
enum AudioObjectType {
AOT_NULL,
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] avcodec: use avpriv_mpeg4audio_get_config2()
Signed-off-by: James Almer
---
libavcodec/aac_adtstoasc_bsf.c | 4 ++--
libavcodec/alsdec.c| 4 ++--
libavcodec/mpegaudiodec_template.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/aac_adtstoasc_bsf.c b/libavcodec/aac_adtstoasc_bsf.c
index 6541b1189c..e378296950 100644
--- a/libavcodec/aac_adtstoasc_bsf.c
+++ b/libavcodec/aac_adtstoasc_bsf.c
@@ -134,8 +134,8 @@ static int aac_adtstoasc_init(AVBSFContext *ctx)
/* Validate the extradata if the stream is already MPEG-4
AudioSpecificConfig */
if (ctx->par_in->extradata) {
MPEG4AudioConfig mp4ac;
-int ret = avpriv_mpeg4audio_get_config(, ctx->par_in->extradata,
- ctx->par_in->extradata_size *
8, 1);
+int ret = avpriv_mpeg4audio_get_config2(, ctx->par_in->extradata,
+ctx->par_in->extradata_size,
1, ctx);
if (ret < 0) {
av_log(ctx, AV_LOG_ERROR, "Error parsing AudioSpecificConfig
extradata!\n");
return ret;
diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
index a53c170d18..b91c690005 100644
--- a/libavcodec/alsdec.c
+++ b/libavcodec/alsdec.c
@@ -302,8 +302,8 @@ static av_cold int read_specific_config(ALSDecContext *ctx)
if ((ret = init_get_bits8(, avctx->extradata, avctx->extradata_size)) <
0)
return ret;
-config_offset = avpriv_mpeg4audio_get_config(, avctx->extradata,
- avctx->extradata_size * 8, 1);
+config_offset = avpriv_mpeg4audio_get_config2(, avctx->extradata,
+ avctx->extradata_size, 1,
avctx);
if (config_offset < 0)
return AVERROR_INVALIDDATA;
diff --git a/libavcodec/mpegaudiodec_template.c
b/libavcodec/mpegaudiodec_template.c
index 9cce88e263..3f1674e827 100644
--- a/libavcodec/mpegaudiodec_template.c
+++ b/libavcodec/mpegaudiodec_template.c
@@ -1851,8 +1851,8 @@ static av_cold int decode_init_mp3on4(AVCodecContext *
avctx)
return AVERROR_INVALIDDATA;
}
-avpriv_mpeg4audio_get_config(, avctx->extradata,
- avctx->extradata_size * 8, 1);
+avpriv_mpeg4audio_get_config2(, avctx->extradata,
+ avctx->extradata_size, 1, avctx);
if (!cfg.chan_config || cfg.chan_config > 7) {
av_log(avctx, AV_LOG_ERROR, "Invalid channel config number.\n");
return AVERROR_INVALIDDATA;
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] avformat: use avpriv_mpeg4audio_get_config2()
Signed-off-by: James Almer
---
libavformat/adtsenc.c | 2 +-
libavformat/isom.c| 4 ++--
libavformat/latmenc.c | 2 +-
libavformat/matroskaenc.c | 3 +--
4 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/libavformat/adtsenc.c b/libavformat/adtsenc.c
index 3c2840c6ab..d937e2bea9 100644
--- a/libavformat/adtsenc.c
+++ b/libavformat/adtsenc.c
@@ -53,7 +53,7 @@ static int adts_decode_extradata(AVFormatContext *s,
ADTSContext *adts, const ui
int off;
init_get_bits(, buf, size * 8);
-off = avpriv_mpeg4audio_get_config(, buf, size * 8, 1);
+off = avpriv_mpeg4audio_get_config2(, buf, size, 1, s);
if (off < 0)
return off;
skip_bits_long(, off);
diff --git a/libavformat/isom.c b/libavformat/isom.c
index fa2e318099..edd0d81063 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -547,8 +547,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
return ret;
if (st->codecpar->codec_id == AV_CODEC_ID_AAC) {
MPEG4AudioConfig cfg = {0};
-ret = avpriv_mpeg4audio_get_config(, st->codecpar->extradata,
- st->codecpar->extradata_size *
8, 1);
+ret = avpriv_mpeg4audio_get_config2(, st->codecpar->extradata,
+st->codecpar->extradata_size,
1, fc);
if (ret < 0)
return ret;
st->codecpar->channels = cfg.channels;
diff --git a/libavformat/latmenc.c b/libavformat/latmenc.c
index 1b16d752b6..db867ebf1a 100644
--- a/libavformat/latmenc.c
+++ b/libavformat/latmenc.c
@@ -62,7 +62,7 @@ static int latm_decode_extradata(AVFormatContext *s, uint8_t
*buf, int size)
av_log(s, AV_LOG_ERROR, "Extradata is larger than currently
supported.\n");
return AVERROR_INVALIDDATA;
}
-ctx->off = avpriv_mpeg4audio_get_config(, buf, size * 8, 1);
+ctx->off = avpriv_mpeg4audio_get_config2(, buf, size, 1, s);
if (ctx->off < 0)
return ctx->off;
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index cef504fa05..a64ffdb690 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -717,8 +717,7 @@ static int get_aac_sample_rates(AVFormatContext *s, uint8_t
*extradata, int extr
MPEG4AudioConfig mp4ac;
int ret;
-ret = avpriv_mpeg4audio_get_config(, extradata,
- extradata_size * 8, 1);
+ret = avpriv_mpeg4audio_get_config2(, extradata, extradata_size, 1,
s);
/* Don't abort if the failure is because of missing extradata. Assume in
that
* case a bitstream filter will provide the muxer with the extradata in the
* first packet.
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/mpeg4audio: add a logging context parameter to avpriv_mpeg4audio_get_config()
On 9/21/2019 7:42 PM, Carl Eugen Hoyos wrote: > Am So., 22. Sept. 2019 um 00:40 Uhr schrieb James Almer : >> >> On 9/21/2019 7:38 PM, Carl Eugen Hoyos wrote: >>> Am So., 22. Sept. 2019 um 00:36 Uhr schrieb James Almer : On 9/21/2019 7:31 PM, Carl Eugen Hoyos wrote: > Am Sa., 21. Sept. 2019 um 17:53 Uhr schrieb James Almer > : > >> This is an ABI change, so it's scheduled for the next bump. > > Why don't you add avpriv_mpeg4audio_get_config2() now? I don't like the idea of adding a function that will be gone as soon as we bump (and still require line changes in lavf once it's removed). >>> >>> Don't remove it. >> >> Why would i leave a redundant internal function? > > Drop avpriv_mpeg4audio_get_config(), keep avpriv_mpeg4audio_get_config2(). Yes, of course, but i'm talking about the name. I'll be dropping the old function as soon as we bump, but also ensuring the new one starts using the old name. > But if that's preferred to get the logging context in lavf working right now, then i can do it. >>> >>> It's just less ugly and it avoids code changes for third parties. >> >> What third parties? This is not public API. > > True, it's still less ugly. Alright, will do that instead. > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: Remove dead code in vps_id check
Am Sa., 21. Sept. 2019 um 04:06 Uhr schrieb Andriy Gelman
:
>
> From: Andriy Gelman
>
> Since reading 4 bits always returns a value in the range [0, 15], the
> check for vps_id >= HEVC_MAX_VPS_COUNT, where HEVC_MAX_VPS_COUNT = 16, is
> redudant.
> ---
> libavcodec/hevc_ps.c | 12 ++--
> 1 file changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> index abf08b919b..498467730b 100644
> --- a/libavcodec/hevc_ps.c
> +++ b/libavcodec/hevc_ps.c
> @@ -447,11 +447,7 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
> AVCodecContext *avctx,
> }
> memcpy(vps->data, gb->buffer, vps->data_size);
>
> -vps_id = get_bits(gb, 4);
> -if (vps_id >= HEVC_MAX_VPS_COUNT) {
> -av_log(avctx, AV_LOG_ERROR, "VPS id out of range: %d\n", vps_id);
> -goto err;
> -}
> +vps_id = get_bits(gb, 4); // vps_id in [0, HEVC_MAX_VPS_COUNT-1] so no
> check needed
>
> if (get_bits(gb, 2) != 3) { // vps_reserved_three_2bits
> av_log(avctx, AV_LOG_ERROR, "vps_reserved_three_2bits is not
> three\n");
> @@ -882,11 +878,7 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
> unsigned int *sps_id,
>
> // Coded parameters
>
> -sps->vps_id = get_bits(gb, 4);
> -if (sps->vps_id >= HEVC_MAX_VPS_COUNT) {
> -av_log(avctx, AV_LOG_ERROR, "VPS id out of range: %d\n",
> sps->vps_id);
> -return AVERROR_INVALIDDATA;
> -}
> +sps->vps_id = get_bits(gb, 4); // sps->vps_id in [0,
> HEVC_MAX_VPS_COUNT-1] so no check needed
The comments look unneeded.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/mpeg4audio: add a logging context parameter to avpriv_mpeg4audio_get_config()
Am So., 22. Sept. 2019 um 00:40 Uhr schrieb James Almer : > > On 9/21/2019 7:38 PM, Carl Eugen Hoyos wrote: > > Am So., 22. Sept. 2019 um 00:36 Uhr schrieb James Almer : > >> > >> On 9/21/2019 7:31 PM, Carl Eugen Hoyos wrote: > >>> Am Sa., 21. Sept. 2019 um 17:53 Uhr schrieb James Almer > >>> : > >>> > This is an ABI change, so it's scheduled for the next bump. > >>> > >>> Why don't you add avpriv_mpeg4audio_get_config2() now? > >> > >> I don't like the idea of adding a function that will be gone as soon as > >> we bump (and still require line changes in lavf once it's removed). > > > > Don't remove it. > > Why would i leave a redundant internal function? Drop avpriv_mpeg4audio_get_config(), keep avpriv_mpeg4audio_get_config2(). > >> But if that's preferred to get the logging context in lavf working right > >> now, then i can do it. > > > > It's just less ugly and it avoids code changes for third parties. > > What third parties? This is not public API. True, it's still less ugly. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/mpeg4audio: add a logging context parameter to avpriv_mpeg4audio_get_config()
On 9/21/2019 7:38 PM, Carl Eugen Hoyos wrote: > Am So., 22. Sept. 2019 um 00:36 Uhr schrieb James Almer : >> >> On 9/21/2019 7:31 PM, Carl Eugen Hoyos wrote: >>> Am Sa., 21. Sept. 2019 um 17:53 Uhr schrieb James Almer : >>> This is an ABI change, so it's scheduled for the next bump. >>> >>> Why don't you add avpriv_mpeg4audio_get_config2() now? >> >> I don't like the idea of adding a function that will be gone as soon as >> we bump (and still require line changes in lavf once it's removed). > > Don't remove it. Why would i leave a redundant internal function? > >> But if that's preferred to get the logging context in lavf working right >> now, then i can do it. > > It's just less ugly and it avoids code changes for third parties. What third parties? This is not public API. > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/mpeg4audio: add a logging context parameter to avpriv_mpeg4audio_get_config()
Am So., 22. Sept. 2019 um 00:36 Uhr schrieb James Almer : > > On 9/21/2019 7:31 PM, Carl Eugen Hoyos wrote: > > Am Sa., 21. Sept. 2019 um 17:53 Uhr schrieb James Almer : > > > >> This is an ABI change, so it's scheduled for the next bump. > > > > Why don't you add avpriv_mpeg4audio_get_config2() now? > > I don't like the idea of adding a function that will be gone as soon as > we bump (and still require line changes in lavf once it's removed). Don't remove it. > But if that's preferred to get the logging context in lavf working right > now, then i can do it. It's just less ugly and it avoids code changes for third parties. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/mpeg4audio: add a logging context parameter to avpriv_mpeg4audio_get_config()
On 9/21/2019 7:31 PM, Carl Eugen Hoyos wrote: > Am Sa., 21. Sept. 2019 um 17:53 Uhr schrieb James Almer : > >> This is an ABI change, so it's scheduled for the next bump. > > Why don't you add avpriv_mpeg4audio_get_config2() now? I don't like the idea of adding a function that will be gone as soon as we bump (and still require line changes in lavf once it's removed). But if that's preferred to get the logging context in lavf working right now, then i can do it. > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/mpeg4audio: add a logging context parameter to avpriv_mpeg4audio_get_config()
Am Sa., 21. Sept. 2019 um 17:53 Uhr schrieb James Almer : > This is an ABI change, so it's scheduled for the next bump. Why don't you add avpriv_mpeg4audio_get_config2() now? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: increase probe score of buffers entirely composed of valid packets
Am Sa., 21. Sept. 2019 um 20:16 Uhr schrieb Rodger Combs : > > Fixes some files misdetecting as MPEG PS The reason for the misdetection (mp3 file with 50k header that contains a mjpeg cover) are the following "lame tags" (I couldn't immediately find out what they really are) which nearly all contain "02 ae" which is identified as VIDEO_ID by the mpegps probe function. The video variable is 9 after 64k of the function, all other relevant variables are 0): e880 00 00 00 00 00 00 00 00 00 00 00 00 00 ff fb e2 || e890 44 00 0f f0 78 00 ab 83 e0 00 00 0e 80 16 c0 7c |D...x..|| e8a0 00 00 01 e0 02 ae 0f 80 00 00 3a 00 5b 01 f0 00 |..:.[...| e8b0 00 2b f4 b7 ff ff ff ff ff d3 ff ff ff ff ff e9 |.+..| e8c0 2b e8 3b ff ff ff ff ff ff ff ff ff ff fe 82 bf |+.;.| e8d0 4b 7f ff ff ff ff fd 3f ff ff ff ff fe 92 be 83 |K..?| e8e0 bf ff ff ff ff ff ff ff ff ff ff e8 4c 41 4d 45 |LAME| e8f0 33 2e 39 38 2e 32 00 00 00 00 00 00 00 00 00 00 |3.98.2..| e900 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * eca0 00 00 ff fb e2 44 00 0f f0 78 00 ab 83 e0 00 00 |.D...x..| ecb0 0e 80 16 c0 7c 00 00 01 e0 02 ae 0f 80 00 00 3a ||..:| ecc0 00 5b 01 f0 00 00 2b f4 b7 ff ff ff ff ff d3 ff |.[+.| ecd0 ff ff ff ff e9 2b e8 3b ff ff ff ff ff ff ff ff |.+.;| ece0 ff ff fe 82 bf 4b 7f ff ff ff ff fd 3f ff ff ff |.K..?...| ecf0 ff fe 92 be 83 bf ff ff ff ff ff ff ff ff ff ff || ed00 e8 4c 41 4d 45 33 2e 39 38 2e 32 00 00 00 00 00 |.LAME3.98.2.| ed10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * f0b0 00 00 00 00 00 00 00 ff fb e2 44 00 0f f0 78 00 |..D...x.| f0c0 ab 83 e0 00 00 0e 80 16 c0 7c 00 00 01 e0 02 ae |.|..| f0d0 0f 80 00 00 3a 00 5b 01 f0 00 00 2b f4 b7 ff ff |:.[+| f0e0 ff ff ff d3 ff ff ff ff ff e9 2b e8 3b ff ff ff |..+.;...| f0f0 ff ff ff ff ff ff ff fe 82 bf 4b 7f ff ff ff ff |..K.| f100 fd 3f ff ff ff ff fe 92 be 83 bf ff ff ff ff ff |.?..| f110 ff ff ff ff ff e8 4c 41 4d 45 33 2e 39 38 2e 32 |..LAME3.98.2| f120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * f4c0 00 00 00 00 00 00 00 00 00 00 00 00 ff fb e2 44 |...D| f4d0 00 0f f0 78 00 ab 83 e0 00 00 0e 80 16 c0 7c 00 |...x..|.| f4e0 00 01 e0 02 ae 0f 80 00 00 3a 00 5b 01 f0 00 00 |.:.[| f4f0 2b f4 b7 ff ff ff ff ff d3 ff ff ff ff ff e9 2b |+..+| f500 e8 3b ff ff ff ff ff ff ff ff ff ff fe 82 bf 4b |.;.K| f510 7f ff ff ff ff fd 3f ff ff ff ff fe 92 be 83 bf |..?.| f520 ff ff ff ff ff ff ff ff ff ff e8 4c 41 4d 45 33 |...LAME3| f530 2e 39 38 2e 32 00 00 00 00 00 00 00 00 00 00 00 |.98.2...| f540 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * f8e0 00 ff fb e2 44 00 0f f0 78 00 ab 83 e0 00 00 0e |D...x...| f8f0 80 16 c0 7c 00 00 01 e0 02 ae 0f 80 00 00 3a 00 |...|..:.| f900 5b 01 f0 00 00 2b f4 b7 ff ff ff ff ff d3 ff ff |[+..| f910 ff ff ff e9 2b e8 3b ff ff ff ff ff ff ff ff ff |+.;.| f920 ff fe 82 bf 4b 7f ff ff ff ff fd 3f ff ff ff ff |K..?| f930 fe 92 be 83 bf ff ff ff ff ff ff ff ff ff ff e8 || f940 4c 41 4d 45 33 2e 39 38 2e 32 00 00 00 00 00 00 |LAME3.98.2..| f950 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * fcf0 00 00 00 00 00 00 ff fb e2 44 00 0f f0 78 00 ab |.D...x..| fd00 83 e0 00 00 0e 80 16 c0 7c 00 00 01 e0 02 ae 0f ||...| fd10 80 00 00 3a 00 5b 01 f0 00 00 2b f4 b7 ff ff ff |...:.[+.| fd20 ff ff d3 ff ff ff ff ff e9 2b e8 3b ff ff ff ff |.+.;| fd30 ff ff ff ff ff ff fe 82 bf 4b 7f ff ff ff ff fd |.K..| fd40 3f ff ff ff ff fe 92 be 83 bf ff ff ff ff ff ff |?...| fd50 ff ff ff ff e8 4c 41 4d 45 33 2e 39 38 2e 32 00 |.LAME3.98.2.| fd60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || I would expect that it is possible to detect that the above are not valid mpeg video packets. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] avcodec/v210dec: add the frame and slice threading support
On Sat, Sep 21, 2019 at 07:45:58AM +0800, Limin Wang wrote:
> On Fri, Sep 20, 2019 at 07:57:10PM +0200, Michael Niedermayer wrote:
> > On Fri, Sep 06, 2019 at 11:28:29PM +0800, lance.lmw...@gmail.com wrote:
> > > From: Limin Wang
> > >
> > > The multithread is avoid one core cpu is full with other filter like
> > > scale etc.
> > > About the performance, the gain is very small, below is my testing for
> > > performance.
> > > In order to avoid the disk bottleneck, I'll use stream_loop mode for 10
> > > frame
> > > only.
> > >
> > > ./ffmpeg -y -i ~/Movies/4k_Rec709_ProResHQ.mov -c:v v210 -f rawvideo
> > > -frames 10
> > > ~/Movies/1.v210
> > >
> > > master:
> > > ./ffmpeg -threads 1 -s 4096x3072 -stream_loop 100 -i ~/Movies/1.v210
> > > -benchmark
> > > -f null -
> > > frame= 1010 fps= 42 q=-0.0 Lsize=N/A time=00:00:40.40 bitrate=N/A
> > > speed=1.69x
> > > video:529kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
> > > muxing
> > > overhead: unknown
> > > bench: utime=10.082s stime=13.784s rtime=23.889s
> > > bench: maxrss=147836928kB
> > >
> > > patch applied:
> > > ./ffmpeg -threads 4 -thread_type frame+slice -s 4096x3072 -stream_loop
> > > 100 -i
> > > ~/Movies/1.v210 -benchmark -f null -
> > >
> > > frame= 1010 fps= 55 q=-0.0 Lsize=N/A time=00:00:40.40 bitrate=N/A
> > > speed=2.22x
> > > video:529kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
> > > muxing
> > > overhead: unknown
> > > bench: utime=11.407s stime=17.258s rtime=18.279s
> > > bench: maxrss=442884096kB
> > >
> > > Signed-off-by: Limin Wang
> > > ---
> > > libavcodec/v210dec.c | 135
> > > +--
> > > libavcodec/v210dec.h | 1 +
> > > 2 files changed, 88 insertions(+), 48 deletions(-)
> > >
> > > diff --git a/libavcodec/v210dec.c b/libavcodec/v210dec.c
> > > index 6ce18aa..2cdb99e 100644
> > > --- a/libavcodec/v210dec.c
> > > +++ b/libavcodec/v210dec.c
> > > @@ -28,6 +28,7 @@
> > > #include "libavutil/internal.h"
> > > #include "libavutil/mem.h"
> > > #include "libavutil/intreadwrite.h"
> > > +#include "thread.h"
> > >
> > > #define READ_PIXELS(a, b, c) \
> > > do { \
> > > @@ -37,6 +38,13 @@
> > > *c++ = (val >> 20) & 0x3FF; \
> > > } while (0)
> > >
> > > +#define MAX_SLICES 32
> > > +typedef struct ThreadData {
> > > +AVFrame *frame;
> > > +uint8_t *buf;
> > > +int stride;
> > > +} ThreadData;
> > > +
> > > static void v210_planar_unpack_c(const uint32_t *src, uint16_t *y,
> > > uint16_t *u, uint16_t *v, int width)
> > > {
> > > uint32_t val;
> > > @@ -67,58 +75,32 @@ static av_cold int decode_init(AVCodecContext *avctx)
> > > s->aligned_input = 0;
> > > ff_v210dec_init(s);
> > >
> > > +s->slice_count = av_clip(avctx->thread_count, 1, MAX_SLICES);
> >
> > why is there a MAX_SLICES ?
>
> It's limit the slice thread count, if it's not OK, I can use MAX_AUTO_THREADS
> for max.
why is a limit needed here ?
where does avctx->thread_count get a bad value ?
This feels a bit arbitrary to limit it to 32 (or any number)
will that be still correct in 10 years ? if not then this is
not a good way to limit it
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec/v210enc: add yuv420p/yuv420p10 input pixel format support
Am Sa., 21. Sept. 2019 um 16:49 Uhr schrieb Limin Wang : > however the patch try to fix the autoscale, if user prefer to use > swscale conversion, he can use it still by claims pix_fmt clearly. This seems like a very bad argument assuming there is a quality hit and the speed gain is very limited. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fix rtmp handshake for some streams [v2]
On Thu, Aug 29, 2019 at 03:54:21PM -0700, William Martin wrote:
> From: Will Martin
>
> Some rtmp streamers (i.e. AWS Elemental Encoder, Wirecast) send C0 and C1
> together and expect S0 and S1 returned together. When sent in different
> packets, this results in a C2 handshake. This patch fixes that error.
> Note that the patch is based off of a fix proposed by rubensanchez in
> https://trac.ffmpeg.org/ticket/6453.
> The only difference between that propsed fix and this patch is that
> dummy_unit is declared as a uint32_t instead of unit8_8 (this addresses a
> crash in debug builds).
> This patch being submitted in a [v2] so that these commit messages could be
> added for clarity.
> ---
> libavformat/rtmpproto.c | 103 +++-
> 1 file changed, 59 insertions(+), 44 deletions(-)
>
> diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
> index b741e421af..24070ba0f5 100644
> --- a/libavformat/rtmpproto.c
> +++ b/libavformat/rtmpproto.c
> @@ -1416,71 +1416,86 @@ static int rtmp_send_hs_packet(RTMPContext* rt,
> uint32_t first_int,
> */
> static int rtmp_server_handshake(URLContext *s, RTMPContext *rt)
> {
> -uint8_t buffer[RTMP_HANDSHAKE_PACKET_SIZE];
> -uint32_t hs_epoch;
> +uint8_t hs_s0s1[RTMP_HANDSHAKE_PACKET_SIZE + 1];
> +uint8_t hs_c0c1[RTMP_HANDSHAKE_PACKET_SIZE + 1];
> +uint8_t hs_c2[RTMP_HANDSHAKE_PACKET_SIZE + 1];
> +uint8_t hs_s2[RTMP_HANDSHAKE_PACKET_SIZE];
> +uint32_t dummy_uint;
> uint32_t hs_my_epoch;
> -uint8_t hs_c1[RTMP_HANDSHAKE_PACKET_SIZE];
> -uint8_t hs_s1[RTMP_HANDSHAKE_PACKET_SIZE];
> -uint32_t zeroes;
> uint32_t temp = 0;
> int randomidx = 0;
> int inoutsize = 0;
> int ret;
>
> -inoutsize = ffurl_read_complete(rt->stream, buffer, 1); // Receive
> C0
> -if (inoutsize <= 0) {
> -av_log(s, AV_LOG_ERROR, "Unable to read handshake\n");
> -return AVERROR(EIO);
> +/
> + * Receive C0+C1
> + ***/
> +ret = rtmp_receive_hs_packet(rt, _uint, _uint, hs_c0c1,
> + RTMP_HANDSHAKE_PACKET_SIZE + 1);
> +if (ret) {
> +av_log(s, AV_LOG_ERROR, "RTMP Handshake C1 Error %d\n", ret);
> +return ret;
> }
> // Check Version
> -if (buffer[0] != 3) {
> -av_log(s, AV_LOG_ERROR, "RTMP protocol version mismatch\n");
> +if (hs_c0c1[0] != 3) {
> +av_log(s, AV_LOG_ERROR, "RTMP protocol version mismatch. Expected
> 0x03 received %02x\n", hs_c0c1[0]);
> return AVERROR(EIO);
> }
> -if (ffurl_write(rt->stream, buffer, 1) <= 0) { // Send S0
> -av_log(s, AV_LOG_ERROR,
> - "Unable to write answer - RTMP S0\n");
> +// Get client epoch and set our with the same value
> +hs_my_epoch = AV_RB32(hs_c0c1 + 1);
> +
> +/*
> + * Send S0+S1
> + /
> +// Generate random data to send it on S0+S1
> +for (randomidx = 9; randomidx < (RTMP_HANDSHAKE_PACKET_SIZE + 1);
> + randomidx += 4)
> +AV_WB32(hs_s0s1 + randomidx, av_get_random_seed());
> +// Set the RTMP protocol code on S0+S1 (First byte)
> +hs_s0s1[0] = 0x03;
> +// Copy the random data from C1 to S1
> +memcpy(hs_s0s1 + 1, hs_c0c1 + 1, RTMP_HANDSHAKE_PACKET_SIZE);
> +AV_WB32(hs_s0s1 + 1, hs_my_epoch);
> +AV_WB32(hs_s0s1 + 5, 0);
> +inoutsize = ffurl_write(rt->stream, hs_s0s1,
> +RTMP_HANDSHAKE_PACKET_SIZE + 1);
> +if (inoutsize != RTMP_HANDSHAKE_PACKET_SIZE + 1) {
> +av_log(s, AV_LOG_ERROR, "RTMP Handshake S1 Error %d\n", ret);
> return AVERROR(EIO);
> }
> -/* Receive C1 */
> -ret = rtmp_receive_hs_packet(rt, _epoch, , hs_c1,
> - RTMP_HANDSHAKE_PACKET_SIZE);
> -if (ret) {
> -av_log(s, AV_LOG_ERROR, "RTMP Handshake C1 Error\n");
> -return ret;
> -}
> -/* Send S1 */
> -/* By now same epoch will be sent */
> -hs_my_epoch = hs_epoch;
> -/* Generate random */
> -for (randomidx = 8; randomidx < (RTMP_HANDSHAKE_PACKET_SIZE);
> - randomidx += 4)
> -AV_WB32(hs_s1 + randomidx, av_get_random_seed());
>
> -ret = rtmp_send_hs_packet(rt, hs_my_epoch, 0, hs_s1,
> - RTMP_HANDSHAKE_PACKET_SIZE);
> -if (ret) {
> -av_log(s, AV_LOG_ERROR, "RTMP Handshake S1 Error\n");
> -return ret;
> -}
> -/* Send S2 */
> +/***
> + * Send S2
> + **/
> +// Get the S2 random data from C0+C1
> +memcpy(hs_s2, hs_c0c1, RTMP_HANDSHAKE_PACKET_SIZE);
> -ret = rtmp_send_hs_packet(rt, hs_epoch, 0, hs_c1,
> +ret = rtmp_send_hs_packet(rt, hs_my_epoch, 0, hs_s2,
>RTMP_HANDSHAKE_PACKET_SIZE);
> if (ret) {
> av_log(s, AV_LOG_ERROR, "RTMP Handshake S2 Error\n");
> return ret;
>
Re: [FFmpeg-devel] [PATCH v1] avcodec/v210enc: add yuv420p/yuv420p10 input pixel format support
On Fri, Sep 20, 2019 at 03:19:52PM -0400, Devin Heitmueller wrote: > Hello Michael, > > > > On Sep 20, 2019, at 12:10 PM, Michael Niedermayer > > wrote: > > > > On Fri, Sep 20, 2019 at 11:55:17PM +0800, lance.lmw...@gmail.com wrote: > >> From: Limin Wang > >> > >> Signed-off-by: Limin Wang > >> --- > >> libavcodec/v210_template.c | 20 > >> libavcodec/v210enc.c | 8 +--- > >> 2 files changed, 25 insertions(+), 3 deletions(-) > > > > Adding a nearest neighbor scaler or in fact any scaler > > into an encoder is not ok > > > > This belongs in swscale and it is already there. > > > Just to be clear, there is no scaling going on here. > The patch just expands 4:2:0 to 4:2:2 while properly supporting interlaced > chroma. 4:2:0 and 4:2:2 have a chroma plane with different resolution. converting between planes of different resolution is what i called scaling. > It avoids having to auto insert the swscale filter in the case where there is > no scaling required (e.g. H.264 4:2:0 video being output to decklink in its > original resolution). yes, doing an operation in the encoder avoids a filter being inserted which does that operation. Thats true for every encoder and every filter. Also replacing interpolation by a nearest neighbor implementation is quite expectedly faster. one problem is the user can setup the scale filter with high quality in mind or with low quality and speed in mind. But after this patch she always gets low quality because the low quality convertion code is hardcoded in the encoder which pretends to support 420. The outside code has no chance to know it shouldnt feed 420 if high quality is wanted. Also why should this be in one encoder and not be available to other encoders supporting 4:2:2 input ? A solution should work for all of them Iam not sure what is the best solution but simply hardcoding this in one encoder feels rather wrong Thanks -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] tools/patcheck: remove gcc-2.95 compat check
On Fri, Sep 20, 2019 at 12:38 AM Paul B Mahol wrote: > > LGTM > > On 9/20/19, James Zern wrote: > > this conflicts with the current contributing guidance: > > http://ffmpeg.org/developer.html#Contributing > > FFmpeg is programmed in the ISO C90 language with a few additional > > features from ISO C99, namely: > > ... > > for loops with variable definition (‘for (int i = 0; i < 8; i++)’); > > > > Signed-off-by: James Zern > > --- > > tools/patcheck | 1 - > > 1 file changed, 1 deletion(-) > > applied. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavf/movdec: add position_order option
Am Sa., 21. Sept. 2019 um 19:58 Uhr schrieb Rodger Combs
:
> +{ "position_order", "Read packets in position order (rather than
> timestamp order)",
> +OFFSET(position_order), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, FLAGS },
Should this also say "avoids seeks"?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavf/tcp: add resolve_hosts option
Rodger Combs (12019-09-21):
> This can be used to resolve particular hosts offline without affecting
> HTTP headers, TLS SNI, or cross-domain redirects. It works similarly to
> curl's --resolve option, but without port-specific handling.
> ---
> libavformat/tcp.c | 27 +++
> libavformat/version.h | 2 +-
> 2 files changed, 28 insertions(+), 1 deletion(-)
I personally do not like it much. Here are my objections:
- This could apply to any networking program, it should be in the libc.
- If it is done inside FFmpeg, it should work for all name resolution,
including UDP.
- The syntax you chose makes it awkward for IPv6 because of multiple
colons.
- You neglected the documentation.
>
> diff --git a/libavformat/tcp.c b/libavformat/tcp.c
> index 2198e0f00e..e4c439ee56 100644
> --- a/libavformat/tcp.c
> +++ b/libavformat/tcp.c
> @@ -45,6 +45,7 @@ typedef struct TCPContext {
> #if !HAVE_WINSOCK2_H
> int tcp_mss;
> #endif /* !HAVE_WINSOCK2_H */
> +char *resolve_hosts;
> } TCPContext;
>
> #define OFFSET(x) offsetof(TCPContext, x)
> @@ -60,6 +61,7 @@ static const AVOption options[] = {
> #if !HAVE_WINSOCK2_H
> { "tcp_mss", "Maximum segment size for outgoing TCP packets",
> OFFSET(tcp_mss), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,
> .flags = D|E },
> #endif /* !HAVE_WINSOCK2_H */
> +{ "resolve_hosts", "Comma-separated host resolutions, in the form
> host:ip", OFFSET(resolve_hosts), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0,
> .flags = D|E },
> { NULL }
> };
>
> @@ -99,6 +101,27 @@ static void customize_fd(void *ctx, int fd)
> #endif /* !HAVE_WINSOCK2_H */
> }
>
> +static int lookup_host(URLContext *h, char *hostname, size_t hostname_size)
> +{
> +TCPContext *s = h->priv_data;
> +if (hostname[0]) {
> +size_t hostlen = strlen(hostname);
> +for (const char *addr = s->resolve_hosts; addr; addr = strchr(addr,
> ','), addr && addr++) {
> +if (!strncmp(addr, hostname, hostlen) && addr[hostlen] == ':') {
> +addr += hostlen + 1;
> +const char *end = strchr(addr, ',');
> +size_t len = end ? end - addr : strlen(addr);
> +if (len >= hostname_size - 1)
> +return AVERROR(ENOMEM);
> +memcpy(hostname, addr, len);
> +hostname[len] = 0;
> +return 0;
> +}
> +}
I find the duplicated comma search awkward. I find this code structure
easier to understand:
while (1) {
end = strchr(addr, ',');
len = end ? end - addr : strlen(addr);
/* or len = strcspn(addr, ","); */
/* process with len */
addr += len;
if (*addr)
break;
addr++;
}
> +}
> +return 0;
> +}
> +
> /* return non zero if error */
> static int tcp_open(URLContext *h, const char *uri, int flags)
> {
> @@ -120,6 +143,10 @@ static int tcp_open(URLContext *h, const char *uri, int
> flags)
> av_log(h, AV_LOG_ERROR, "Port missing in uri\n");
> return AVERROR(EINVAL);
> }
> +
> +if ((ret = lookup_host(h, hostname, sizeof(hostname))) < 0)
> +return ret;
> +
> p = strchr(uri, '?');
> if (p) {
> if (av_find_info_tag(buf, sizeof(buf), "listen", p)) {
> diff --git a/libavformat/version.h b/libavformat/version.h
> index 2eb14659d0..d1dbb1e2d1 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@ -33,7 +33,7 @@
> // Also please add any ticket numbers that you believe might be affected here
> #define LIBAVFORMAT_VERSION_MAJOR 58
> #define LIBAVFORMAT_VERSION_MINOR 32
> -#define LIBAVFORMAT_VERSION_MICRO 105
> +#define LIBAVFORMAT_VERSION_MICRO 106
>
> #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
> LIBAVFORMAT_VERSION_MINOR, \
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavf/mp3dec: increase probe score of buffers entirely composed of valid packets
Fixes some files misdetecting as MPEG PS
---
libavformat/mp3dec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 258f19174b..d9aaee50b9 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -100,13 +100,13 @@ static int mp3_read_probe(const AVProbeData *p)
max_framesizes = FFMAX(max_framesizes, framesizes);
if(buf == buf0) {
first_frames= frames;
-if (buf2 == end + sizeof(uint32_t))
+if (buf2 >= end + sizeof(uint32_t))
whole_used = 1;
}
}
// keep this in sync with ac3 probe, both need to avoid
// issues with MPEG-files!
-if (first_frames>=7) return AVPROBE_SCORE_EXTENSION + 1;
+if (first_frames>=7) return AVPROBE_SCORE_EXTENSION + 1 + whole_used *
FFMIN(first_frames / 2, 5);
else if(max_frames>200 && p->buf_size < 2*max_framesizes)return
AVPROBE_SCORE_EXTENSION;
else if(max_frames>=4 && p->buf_size < 2*max_framesizes) return
AVPROBE_SCORE_EXTENSION / 2;
else if(ff_id3v2_match(buf0, ID3v2_DEFAULT_MAGIC) &&
2*ff_id3v2_tag_len(buf0) >= p->buf_size)
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavf/tcp: add resolve_hosts option
This can be used to resolve particular hosts offline without affecting
HTTP headers, TLS SNI, or cross-domain redirects. It works similarly to
curl's --resolve option, but without port-specific handling.
---
libavformat/tcp.c | 27 +++
libavformat/version.h | 2 +-
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/libavformat/tcp.c b/libavformat/tcp.c
index 2198e0f00e..e4c439ee56 100644
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@ -45,6 +45,7 @@ typedef struct TCPContext {
#if !HAVE_WINSOCK2_H
int tcp_mss;
#endif /* !HAVE_WINSOCK2_H */
+char *resolve_hosts;
} TCPContext;
#define OFFSET(x) offsetof(TCPContext, x)
@@ -60,6 +61,7 @@ static const AVOption options[] = {
#if !HAVE_WINSOCK2_H
{ "tcp_mss", "Maximum segment size for outgoing TCP packets",
OFFSET(tcp_mss), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,
.flags = D|E },
#endif /* !HAVE_WINSOCK2_H */
+{ "resolve_hosts", "Comma-separated host resolutions, in the form
host:ip", OFFSET(resolve_hosts), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0,
.flags = D|E },
{ NULL }
};
@@ -99,6 +101,27 @@ static void customize_fd(void *ctx, int fd)
#endif /* !HAVE_WINSOCK2_H */
}
+static int lookup_host(URLContext *h, char *hostname, size_t hostname_size)
+{
+TCPContext *s = h->priv_data;
+if (hostname[0]) {
+size_t hostlen = strlen(hostname);
+for (const char *addr = s->resolve_hosts; addr; addr = strchr(addr,
','), addr && addr++) {
+if (!strncmp(addr, hostname, hostlen) && addr[hostlen] == ':') {
+addr += hostlen + 1;
+const char *end = strchr(addr, ',');
+size_t len = end ? end - addr : strlen(addr);
+if (len >= hostname_size - 1)
+return AVERROR(ENOMEM);
+memcpy(hostname, addr, len);
+hostname[len] = 0;
+return 0;
+}
+}
+}
+return 0;
+}
+
/* return non zero if error */
static int tcp_open(URLContext *h, const char *uri, int flags)
{
@@ -120,6 +143,10 @@ static int tcp_open(URLContext *h, const char *uri, int
flags)
av_log(h, AV_LOG_ERROR, "Port missing in uri\n");
return AVERROR(EINVAL);
}
+
+if ((ret = lookup_host(h, hostname, sizeof(hostname))) < 0)
+return ret;
+
p = strchr(uri, '?');
if (p) {
if (av_find_info_tag(buf, sizeof(buf), "listen", p)) {
diff --git a/libavformat/version.h b/libavformat/version.h
index 2eb14659d0..d1dbb1e2d1 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -33,7 +33,7 @@
// Also please add any ticket numbers that you believe might be affected here
#define LIBAVFORMAT_VERSION_MAJOR 58
#define LIBAVFORMAT_VERSION_MINOR 32
-#define LIBAVFORMAT_VERSION_MICRO 105
+#define LIBAVFORMAT_VERSION_MICRO 106
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavf/movdec: add position_order option
This allows reading packets linearly, which prevents large numbers of
unnecessary seeks in poorly-interleaved files with consumer software that
handles those cases well on its own.
---
libavformat/isom.h| 1 +
libavformat/mov.c | 11 +++
libavformat/version.h | 2 +-
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 69452cae8e..3e29e9877d 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -288,6 +288,7 @@ typedef struct MOVContext {
int decryption_key_len;
int enable_drefs;
int32_t movie_display_matrix[3][3]; ///< display matrix from mvhd
+int position_order;
} MOVContext;
int ff_mp4_read_descr_len(AVIOContext *pb);
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 675b915906..a1559b8a8f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -7626,8 +7626,10 @@ static int mov_read_header(AVFormatContext *s)
static AVIndexEntry *mov_find_next_sample(AVFormatContext *s, AVStream **st)
{
+MOVContext *mov = s->priv_data;
AVIndexEntry *sample = NULL;
int64_t best_dts = INT64_MAX;
+int use_pos = mov->position_order || !(s->pb->seekable &
AVIO_SEEKABLE_NORMAL);
int i;
for (i = 0; i < s->nb_streams; i++) {
AVStream *avst = s->streams[i];
@@ -7636,11 +7638,10 @@ static AVIndexEntry
*mov_find_next_sample(AVFormatContext *s, AVStream **st)
AVIndexEntry *current_sample =
>index_entries[msc->current_sample];
int64_t dts = av_rescale(current_sample->timestamp, AV_TIME_BASE,
msc->time_scale);
av_log(s, AV_LOG_TRACE, "stream %d, sample %d, dts %"PRId64"\n",
i, msc->current_sample, dts);
-if (!sample || (!(s->pb->seekable & AVIO_SEEKABLE_NORMAL) &&
current_sample->pos < sample->pos) ||
-((s->pb->seekable & AVIO_SEEKABLE_NORMAL) &&
- ((msc->pb != s->pb && dts < best_dts) || (msc->pb == s->pb &&
+if (!sample || (use_pos ? (current_sample->pos < sample->pos) :
+(((msc->pb != s->pb && dts < best_dts) || (msc->pb == s->pb &&
((FFABS(best_dts - dts) <= AV_TIME_BASE &&
current_sample->pos < sample->pos) ||
- (FFABS(best_dts - dts) > AV_TIME_BASE && dts <
best_dts)) {
+ (FFABS(best_dts - dts) > AV_TIME_BASE && dts <
best_dts))) {
sample = current_sample;
best_dts = dts;
*st = avst;
@@ -8017,6 +8018,8 @@ static const AVOption mov_options[] = {
{ "decryption_key", "The media decryption key (hex)",
OFFSET(decryption_key), AV_OPT_TYPE_BINARY, .flags = AV_OPT_FLAG_DECODING_PARAM
},
{ "enable_drefs", "Enable external track support.", OFFSET(enable_drefs),
AV_OPT_TYPE_BOOL,
{.i64 = 0}, 0, 1, FLAGS },
+{ "position_order", "Read packets in position order (rather than timestamp
order)",
+OFFSET(position_order), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, FLAGS },
{ NULL },
};
diff --git a/libavformat/version.h b/libavformat/version.h
index edfa73fb97..2eb14659d0 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -33,7 +33,7 @@
// Also please add any ticket numbers that you believe might be affected here
#define LIBAVFORMAT_VERSION_MAJOR 58
#define LIBAVFORMAT_VERSION_MINOR 32
-#define LIBAVFORMAT_VERSION_MICRO 104
+#define LIBAVFORMAT_VERSION_MICRO 105
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/5] avcodec/sunrast: Fix return type for "unsupported (compression) type"
LGTM
On 9/21/19, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/sunrast.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/sunrast.c b/libavcodec/sunrast.c
> index 0af5626e35..883421202a 100644
> --- a/libavcodec/sunrast.c
> +++ b/libavcodec/sunrast.c
> @@ -72,7 +72,7 @@ static int sunrast_decode_frame(AVCodecContext *avctx,
> void *data,
>
> if (type == RT_FORMAT_TIFF || type == RT_FORMAT_IFF) {
> av_log(avctx, AV_LOG_ERROR, "unsupported (compression) type\n");
> -return -1;
> +return AVERROR_PATCHWELCOME;
> }
>
> switch (depth) {
> --
> 2.23.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/5] avformat/mpsubdec: Clear queue on error
Fixes: Memleaks Fixes: 17219/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5720539124989952 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/mpsubdec.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavformat/mpsubdec.c b/libavformat/mpsubdec.c index 3d8dcb35c2..82c73457ea 100644 --- a/libavformat/mpsubdec.c +++ b/libavformat/mpsubdec.c @@ -163,6 +163,9 @@ static int mpsub_read_header(AVFormatContext *s) ff_subtitles_queue_finalize(s, >q); end: +if (res < 0) +ff_subtitles_queue_clean(>q); + av_bprint_finalize(, NULL); return res; } -- 2.23.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/5] avcodec/sunrast: Fix indention
Signed-off-by: Michael Niedermayer
---
libavcodec/sunrast.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/sunrast.c b/libavcodec/sunrast.c
index 883421202a..baf184968f 100644
--- a/libavcodec/sunrast.c
+++ b/libavcodec/sunrast.c
@@ -132,8 +132,8 @@ static int sunrast_decode_frame(AVCodecContext *avctx, void
*data,
return AVERROR(ENOMEM);
stride = (w + 15 >> 3) * depth;
} else {
-ptr= p->data[0];
-stride = p->linesize[0];
+ptr= p->data[0];
+stride = p->linesize[0];
}
/* scanlines are aligned on 16 bit boundaries */
--
2.23.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/5] avcodec/sunrast: Check for availability of maplength before allocating image
Signed-off-by: Michael Niedermayer
---
libavcodec/sunrast.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/sunrast.c b/libavcodec/sunrast.c
index baf184968f..98bc4ffa63 100644
--- a/libavcodec/sunrast.c
+++ b/libavcodec/sunrast.c
@@ -100,14 +100,14 @@ static int sunrast_decode_frame(AVCodecContext *avctx,
void *data,
if (ret < 0)
return ret;
+if (buf_end - buf < maplength)
+return AVERROR_INVALIDDATA;
+
if ((ret = ff_get_buffer(avctx, p, 0)) < 0)
return ret;
p->pict_type = AV_PICTURE_TYPE_I;
-if (buf_end - buf < maplength)
-return AVERROR_INVALIDDATA;
-
if (depth > 8 && maplength) {
av_log(avctx, AV_LOG_WARNING, "useless colormap found or file is
corrupted, trying to recover\n");
--
2.23.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/5] avcodec/sunrast: Check that the input is large enough for the maximally compressed image
Fixes: Timeout (17sec -> 15ms)
Fixes:
17224/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SUNRAST_fuzzer-5663218491457536
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/sunrast.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/sunrast.c b/libavcodec/sunrast.c
index 98bc4ffa63..e1ec8a0832 100644
--- a/libavcodec/sunrast.c
+++ b/libavcodec/sunrast.c
@@ -100,7 +100,11 @@ static int sunrast_decode_frame(AVCodecContext *avctx,
void *data,
if (ret < 0)
return ret;
-if (buf_end - buf < maplength)
+/* scanlines are aligned on 16 bit boundaries */
+len = (depth * w + 7) >> 3;
+alen = len + (len & 1);
+
+if (buf_end - buf < maplength + (len * h) * 3 / 256)
return AVERROR_INVALIDDATA;
if ((ret = ff_get_buffer(avctx, p, 0)) < 0)
@@ -136,10 +140,6 @@ static int sunrast_decode_frame(AVCodecContext *avctx,
void *data,
stride = p->linesize[0];
}
-/* scanlines are aligned on 16 bit boundaries */
-len = (depth * w + 7) >> 3;
-alen = len + (len & 1);
-
if (type == RT_BYTE_ENCODED) {
int value, run;
uint8_t *end = ptr + h * stride;
--
2.23.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/5] avcodec/sunrast: Fix return type for "unsupported (compression) type"
Signed-off-by: Michael Niedermayer
---
libavcodec/sunrast.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/sunrast.c b/libavcodec/sunrast.c
index 0af5626e35..883421202a 100644
--- a/libavcodec/sunrast.c
+++ b/libavcodec/sunrast.c
@@ -72,7 +72,7 @@ static int sunrast_decode_frame(AVCodecContext *avctx, void
*data,
if (type == RT_FORMAT_TIFF || type == RT_FORMAT_IFF) {
av_log(avctx, AV_LOG_ERROR, "unsupported (compression) type\n");
-return -1;
+return AVERROR_PATCHWELCOME;
}
switch (depth) {
--
2.23.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Ronald S. Bultje (12019-09-21): > I take that back, there's a COPYING that addresses this: > > https://github.com/traviscross/freeswitch/blob/master/docs/COPYING You are not looking at the relevant file: https://github.com/traviscross/freeswitch/blob/master/libs/libg722_1/COPYING Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Hi, On Sat, Sep 21, 2019 at 11:53 AM Ronald S. Bultje wrote: > Hi, > > On Sat, Sep 21, 2019 at 11:05 AM Carl Eugen Hoyos > wrote: > >> Am Sa., 21. Sept. 2019 um 16:51 Uhr schrieb Ronald S. Bultje >> : >> >> > So it appears, from the discussion (..), that although there is source >> > code, it is not actually "open" in the sense that it's not >> redistributable >> > (at least not explicitly so) or modifiable? If I were hosting a copy on, >> > say, github (or Debian), I'd be in legal trouble with this Freeswitch >> > company? >> >> (Afaik) Freeswitch is a distributor of binaries based on FFmpeg's and >> Polycom's source code. Freeswitch also hosts Polycom's source code. >> >> It appears to me that Freeswitch claims that while libg7221 is not a >> Free library (and has a license incompatible with the GPL), it is >> "open source" and can be distributed. > > > Hm... Right, OK, so the question is indeed going to hinge on whether that > is true or not. I suggest we open a github issue/request with exactly that > question. :-). > I take that back, there's a COPYING that addresses this: https://github.com/traviscross/freeswitch/blob/master/docs/COPYING Seems relatively sane to me? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Hi, On Sat, Sep 21, 2019 at 11:05 AM Carl Eugen Hoyos wrote: > Am Sa., 21. Sept. 2019 um 16:51 Uhr schrieb Ronald S. Bultje > : > > > So it appears, from the discussion (..), that although there is source > > code, it is not actually "open" in the sense that it's not > redistributable > > (at least not explicitly so) or modifiable? If I were hosting a copy on, > > say, github (or Debian), I'd be in legal trouble with this Freeswitch > > company? > > (Afaik) Freeswitch is a distributor of binaries based on FFmpeg's and > Polycom's source code. Freeswitch also hosts Polycom's source code. > > It appears to me that Freeswitch claims that while libg7221 is not a > Free library (and has a license incompatible with the GPL), it is > "open source" and can be distributed. Hm... Right, OK, so the question is indeed going to hinge on whether that is true or not. I suggest we open a github issue/request with exactly that question. :-). Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] avcodec/mpeg4audio: make the size parameter in avpriv_mpeg4audio_get_config() take bytes instead of bits
This is an ABI change, so it's scheduled for the next bump.
Signed-off-by: James Almer
---
libavcodec/alsdec.c| 2 +-
libavcodec/mpeg4audio.c| 12
libavcodec/mpeg4audio.h| 2 +-
libavcodec/mpegaudiodec_template.c | 2 +-
libavformat/adtsenc.c | 2 +-
libavformat/isom.c | 2 +-
libavformat/latmenc.c | 2 +-
libavformat/matroskaenc.c | 2 +-
8 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
index 767d1be7d3..6b4f3555c0 100644
--- a/libavcodec/alsdec.c
+++ b/libavcodec/alsdec.c
@@ -306,7 +306,7 @@ static av_cold int read_specific_config(ALSDecContext *ctx)
#if LIBAVCODEC_VERSION_MAJOR < 59
avctx->extradata_size * 8, 1);
#else
- avctx->extradata_size * 8, 1,
avctx);
+ avctx->extradata_size, 1,
avctx);
#endif
if (config_offset < 0)
diff --git a/libavcodec/mpeg4audio.c b/libavcodec/mpeg4audio.c
index 43c19c4188..b2c8baf815 100644
--- a/libavcodec/mpeg4audio.c
+++ b/libavcodec/mpeg4audio.c
@@ -154,21 +154,25 @@ int ff_mpeg4audio_get_config_gb(MPEG4AudioConfig *c,
GetBitContext *gb,
#if LIBAVCODEC_VERSION_MAJOR < 59
int avpriv_mpeg4audio_get_config(MPEG4AudioConfig *c, const uint8_t *buf,
- int bit_size, int sync_extension)
+ int size, int sync_extension)
{
void *logctx = NULL;
#else
int avpriv_mpeg4audio_get_config(MPEG4AudioConfig *c, const uint8_t *buf,
- int bit_size, int sync_extension, void
*logctx)
+ int size, int sync_extension, void *logctx)
{
#endif
GetBitContext gb;
int ret;
-if (bit_size <= 0)
+if (size <= 0)
return AVERROR_INVALIDDATA;
-ret = init_get_bits(, buf, bit_size);
+#if LIBAVCODEC_VERSION_MAJOR < 59
+ret = init_get_bits(, buf, size);
+#else
+ret = init_get_bits8(, buf, size);
+#endif
if (ret < 0)
return ret;
diff --git a/libavcodec/mpeg4audio.h b/libavcodec/mpeg4audio.h
index ee6c8da233..79ab352ce2 100644
--- a/libavcodec/mpeg4audio.h
+++ b/libavcodec/mpeg4audio.h
@@ -72,7 +72,7 @@ int avpriv_mpeg4audio_get_config(MPEG4AudioConfig *c, const
uint8_t *buf,
#if LIBAVCODEC_VERSION_MAJOR < 59
int bit_size, int sync_extension);
#else
- int bit_size, int sync_extension, void
*logctx);
+ int size, int sync_extension, void *logctx);
#endif
enum AudioObjectType {
diff --git a/libavcodec/mpegaudiodec_template.c
b/libavcodec/mpegaudiodec_template.c
index a89d7e408f..c35c1ee216 100644
--- a/libavcodec/mpegaudiodec_template.c
+++ b/libavcodec/mpegaudiodec_template.c
@@ -1855,7 +1855,7 @@ static av_cold int decode_init_mp3on4(AVCodecContext *
avctx)
#if LIBAVCODEC_VERSION_MAJOR < 59
avctx->extradata_size * 8, 1);
#else
- avctx->extradata_size * 8, 1, avctx);
+ avctx->extradata_size, 1, avctx);
#endif
if (!cfg.chan_config || cfg.chan_config > 7) {
av_log(avctx, AV_LOG_ERROR, "Invalid channel config number.\n");
diff --git a/libavformat/adtsenc.c b/libavformat/adtsenc.c
index 48871efe1a..d63fad8e76 100644
--- a/libavformat/adtsenc.c
+++ b/libavformat/adtsenc.c
@@ -56,7 +56,7 @@ static int adts_decode_extradata(AVFormatContext *s,
ADTSContext *adts, const ui
#if LIBAVCODEC_VERSION_MAJOR < 59
off = avpriv_mpeg4audio_get_config(, buf, size * 8, 1);
#else
-off = avpriv_mpeg4audio_get_config(, buf, size * 8, 1, s);
+off = avpriv_mpeg4audio_get_config(, buf, size, 1, s);
#endif
if (off < 0)
return off;
diff --git a/libavformat/isom.c b/libavformat/isom.c
index 6d5e9b56d0..6e28407f8f 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -551,7 +551,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
#if LIBAVCODEC_VERSION_MAJOR < 59
st->codecpar->extradata_size *
8, 1);
#else
- st->codecpar->extradata_size *
8, 1, fc);
+ st->codecpar->extradata_size,
1, fc);
#endif
if (ret < 0)
return ret;
diff --git a/libavformat/latmenc.c b/libavformat/latmenc.c
index d33e39074c..74030d8b3c 100644
--- a/libavformat/latmenc.c
+++ b/libavformat/latmenc.c
@@ -65,7 +65,7 @@ static int latm_decode_extradata(AVFormatContext *s, uint8_t
*buf, int size)
#if LIBAVCODEC_VERSION_MAJOR < 59
ctx->off = avpriv_mpeg4audio_get_config(, buf, size * 8, 1);
#else
-ctx->off = avpriv_mpeg4audio_get_config(, buf, size * 8, 1, s);
+ctx->off = avpriv_mpeg4audio_get_config(, buf, size, 1, s);
#endif
[FFmpeg-devel] [PATCH 3/3] avcodec/mpeg4audio: fix return value described in avpriv_mpeg4audio_get_config() doxy
Signed-off-by: James Almer --- libavcodec/mpeg4audio.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/mpeg4audio.h b/libavcodec/mpeg4audio.h index 79ab352ce2..3774dc79c2 100644 --- a/libavcodec/mpeg4audio.h +++ b/libavcodec/mpeg4audio.h @@ -54,7 +54,7 @@ extern const uint8_t ff_mpeg4audio_channels[8]; * @param[in] gb Extradata from container. * @param[in] sync_extension look for a sync extension after config if true. * @param[in] logctx opaque struct starting with an AVClass element, used for logging. - * @return On error -1 is returned, on success AudioSpecificConfig bit index in extradata. + * @return Negative AVERROR code on error, AudioSpecificConfig bit index in extradata on success. */ int ff_mpeg4audio_get_config_gb(MPEG4AudioConfig *c, GetBitContext *gb, int sync_extension, void *logctx); @@ -66,7 +66,7 @@ int ff_mpeg4audio_get_config_gb(MPEG4AudioConfig *c, GetBitContext *gb, * @param[in] bit_size Extradata size in bits. * @param[in] sync_extension look for a sync extension after config if true. * @param[in] logctx opaque struct starting with an AVClass element, used for logging. - * @return On error -1 is returned, on success AudioSpecificConfig bit index in extradata. + * @return Negative AVERROR code on error, AudioSpecificConfig bit index in extradata on success. */ int avpriv_mpeg4audio_get_config(MPEG4AudioConfig *c, const uint8_t *buf, #if LIBAVCODEC_VERSION_MAJOR < 59 -- 2.22.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] avcodec/mpeg4audio: add a logging context parameter to avpriv_mpeg4audio_get_config()
This is an ABI change, so it's scheduled for the next bump.
Signed-off-by: James Almer
---
libavcodec/aacdec_template.c | 2 +-
libavcodec/alsdec.c| 4
libavcodec/mpeg4audio.c| 11 +--
libavcodec/mpeg4audio.h| 8 +++-
libavcodec/mpegaudiodec_template.c | 4
libavformat/adtsenc.c | 4
libavformat/isom.c | 4
libavformat/latmenc.c | 4
libavformat/matroskaenc.c | 4
9 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 6e086e00df..8726c8b828 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -975,7 +975,7 @@ static int decode_audio_specific_config_gb(AACContext *ac,
int i, ret;
GetBitContext gbc = *gb;
-if ((i = ff_mpeg4audio_get_config_gb(m4ac, , sync_extension)) < 0)
+if ((i = ff_mpeg4audio_get_config_gb(m4ac, , sync_extension, avctx)) <
0)
return AVERROR_INVALIDDATA;
if (m4ac->sampling_index > 12) {
diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
index a53c170d18..767d1be7d3 100644
--- a/libavcodec/alsdec.c
+++ b/libavcodec/alsdec.c
@@ -303,7 +303,11 @@ static av_cold int read_specific_config(ALSDecContext *ctx)
return ret;
config_offset = avpriv_mpeg4audio_get_config(, avctx->extradata,
+#if LIBAVCODEC_VERSION_MAJOR < 59
avctx->extradata_size * 8, 1);
+#else
+ avctx->extradata_size * 8, 1,
avctx);
+#endif
if (config_offset < 0)
return AVERROR_INVALIDDATA;
diff --git a/libavcodec/mpeg4audio.c b/libavcodec/mpeg4audio.c
index 219714752f..43c19c4188 100644
--- a/libavcodec/mpeg4audio.c
+++ b/libavcodec/mpeg4audio.c
@@ -84,7 +84,7 @@ static inline int get_sample_rate(GetBitContext *gb, int
*index)
}
int ff_mpeg4audio_get_config_gb(MPEG4AudioConfig *c, GetBitContext *gb,
-int sync_extension)
+int sync_extension, void *logctx)
{
int specific_config_bitindex, ret;
int start_bit_index = get_bits_count(gb);
@@ -152,9 +152,16 @@ int ff_mpeg4audio_get_config_gb(MPEG4AudioConfig *c,
GetBitContext *gb,
return specific_config_bitindex - start_bit_index;
}
+#if LIBAVCODEC_VERSION_MAJOR < 59
int avpriv_mpeg4audio_get_config(MPEG4AudioConfig *c, const uint8_t *buf,
int bit_size, int sync_extension)
{
+void *logctx = NULL;
+#else
+int avpriv_mpeg4audio_get_config(MPEG4AudioConfig *c, const uint8_t *buf,
+ int bit_size, int sync_extension, void
*logctx)
+{
+#endif
GetBitContext gb;
int ret;
@@ -165,5 +172,5 @@ int avpriv_mpeg4audio_get_config(MPEG4AudioConfig *c, const
uint8_t *buf,
if (ret < 0)
return ret;
-return ff_mpeg4audio_get_config_gb(c, , sync_extension);
+return ff_mpeg4audio_get_config_gb(c, , sync_extension, logctx);
}
diff --git a/libavcodec/mpeg4audio.h b/libavcodec/mpeg4audio.h
index b9cea8af17..ee6c8da233 100644
--- a/libavcodec/mpeg4audio.h
+++ b/libavcodec/mpeg4audio.h
@@ -53,10 +53,11 @@ extern const uint8_t ff_mpeg4audio_channels[8];
* @param[in] cMPEG4AudioConfig structure to fill.
* @param[in] gb Extradata from container.
* @param[in] sync_extension look for a sync extension after config if true.
+ * @param[in] logctx opaque struct starting with an AVClass element, used for
logging.
* @return On error -1 is returned, on success AudioSpecificConfig bit index
in extradata.
*/
int ff_mpeg4audio_get_config_gb(MPEG4AudioConfig *c, GetBitContext *gb,
-int sync_extension);
+int sync_extension, void *logctx);
/**
* Parse MPEG-4 systems extradata from a raw buffer to retrieve audio
configuration.
@@ -64,10 +65,15 @@ int ff_mpeg4audio_get_config_gb(MPEG4AudioConfig *c,
GetBitContext *gb,
* @param[in] buf Extradata from container.
* @param[in] bit_size Extradata size in bits.
* @param[in] sync_extension look for a sync extension after config if true.
+ * @param[in] logctx opaque struct starting with an AVClass element, used for
logging.
* @return On error -1 is returned, on success AudioSpecificConfig bit index
in extradata.
*/
int avpriv_mpeg4audio_get_config(MPEG4AudioConfig *c, const uint8_t *buf,
+#if LIBAVCODEC_VERSION_MAJOR < 59
int bit_size, int sync_extension);
+#else
+ int bit_size, int sync_extension, void
*logctx);
+#endif
enum AudioObjectType {
AOT_NULL,
diff --git a/libavcodec/mpegaudiodec_template.c
b/libavcodec/mpegaudiodec_template.c
index 9cce88e263..a89d7e408f 100644
--- a/libavcodec/mpegaudiodec_template.c
+++ b/libavcodec/mpegaudiodec_template.c
@@ -1852,7 +1852,11 @@ static av_cold int
Re: [FFmpeg-devel] [PATCH V1] lavc/mpeg4audio: add chan_config check to avoid indeterminate channels
On 9/21/2019 8:29 AM, Jun Zhao wrote:
> From: Jun Zhao
>
> add chan_config check to avoid indeterminate channels.
>
> Signed-off-by: Jun Zhao
> ---
> libavcodec/mpeg4audio.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/libavcodec/mpeg4audio.c b/libavcodec/mpeg4audio.c
> index 2197147..0ada239 100644
> --- a/libavcodec/mpeg4audio.c
> +++ b/libavcodec/mpeg4audio.c
> @@ -93,6 +93,10 @@ int ff_mpeg4audio_get_config_gb(MPEG4AudioConfig *c,
> GetBitContext *gb,
> c->chan_config = get_bits(gb, 4);
> if (c->chan_config < FF_ARRAY_ELEMS(ff_mpeg4audio_channels))
> c->channels = ff_mpeg4audio_channels[c->chan_config];
> +else {
> +av_log(NULL, AV_LOG_ERROR, "Invalid chan_config %d\n",
> c->chan_config);
Is chan_config > 8 invalid, or currently unsupported instead?
> +return -1;
> +}
> c->sbr = -1;
> c->ps = -1;
> if (c->object_type == AOT_SBR || (c->object_type == AOT_PS &&
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/opt: Fix type specifier
lgtm On 9/21/19, Andreas Rheinhardt wrote: > This bug has been introduced in 9e0a071e. > > Signed-off-by: Andreas Rheinhardt > --- > libavutil/opt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavutil/opt.c b/libavutil/opt.c > index 35dc9e153d..7c2649725f 100644 > --- a/libavutil/opt.c > +++ b/libavutil/opt.c > @@ -1200,7 +1200,7 @@ static void opt_list(void *obj, void *av_log_obj, > const char *unit, > break; > case AV_OPT_TYPE_CONST: > if (parent_type == AV_OPT_TYPE_INT) > -av_log(av_log_obj, AV_LOG_INFO, "%-12d ", > opt->default_val.i64); > +av_log(av_log_obj, AV_LOG_INFO, "%-12"PRId64" ", > opt->default_val.i64); > else > av_log(av_log_obj, AV_LOG_INFO, "%-12s ", ""); > break; > -- > 2.20.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V1] lavc/mpeg4audio: add chan_config check to avoid indeterminate channels
On 9/21/2019 10:07 AM, Moritz Barsnick wrote:
> On Sat, Sep 21, 2019 at 19:29:47 +0800, Jun Zhao wrote:
>> +else {
>> +av_log(NULL, AV_LOG_ERROR, "Invalid chan_config %d\n",
>> c->chan_config);
>> +return -1;
>> +}
>
> I know the function definition says it returns -1 on error, but that's
> already not the case: It can return AVERROR_INVALIDDATA by means of the
> call to parse_config_ALS(). I believe the doc should be changed, and
> this code change should also return AVERROR_INVALIDDATA.
>
> Furthermore, can you pass and find a useful context for this av_log()
> (and for the one in parse_config_ALS()? av_log() with NULL context is
> very unfortunate.
avpriv_mpeg4audio_get_config() is tied to the ABI, so such changes can
only happen after a major bump.
It could be done to ff_mpeg4audio_get_config_gb() in the meantime, using
a new logctx paramtere, and schedule the addition to
avpriv_mpeg4audio_get_config() with a preprocessor check.
I'll look into doing that in a bit.
>
> Cheers,
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Am Sa., 21. Sept. 2019 um 16:51 Uhr schrieb Ronald S. Bultje : > So it appears, from the discussion (..), that although there is source > code, it is not actually "open" in the sense that it's not redistributable > (at least not explicitly so) or modifiable? If I were hosting a copy on, > say, github (or Debian), I'd be in legal trouble with this Freeswitch > company? (Afaik) Freeswitch is a distributor of binaries based on FFmpeg's and Polycom's source code. Freeswitch also hosts Polycom's source code. It appears to me that Freeswitch claims that while libg7221 is not a Free library (and has a license incompatible with the GPL), it is "open source" and can be distributed. > That's a serious issue, and I'd tend to agree with Nicolas we then > probably don't want to link to such code... I still wonder what the difference between the libraries that are only allowed to be used with a patent license is... Carl Eugen PS: In case this isn't obvious: We should of course improve our existing related decoder instead of linking a non-free library. I just believe that the used argumentation is surprisingly weak. And I still wonder why the mentioned patch wasn't published for interested parties... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1 4/4] avfilter/vf_framerate: limit the scene level max range
lgtm
On 9/21/19, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/vf_framerate.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_framerate.c b/libavfilter/vf_framerate.c
> index 6383f69..59d58e7 100644
> --- a/libavfilter/vf_framerate.c
> +++ b/libavfilter/vf_framerate.c
> @@ -53,7 +53,7 @@ static const AVOption framerate_options[] = {
>
> {"interp_start","point to start linear interpolation",
> OFFSET(interp_start),AV_OPT_TYPE_INT, {.i64=15}, 0,
> 255, V|F },
> {"interp_end", "point to end linear interpolation",
> OFFSET(interp_end), AV_OPT_TYPE_INT, {.i64=240},0,
> 255, V|F },
> -{"scene", "scene change level",
> OFFSET(scene_score), AV_OPT_TYPE_DOUBLE, {.dbl=8.2},0,
> INT_MAX, V|F },
> +{"scene", "scene change level",
> OFFSET(scene_score), AV_OPT_TYPE_DOUBLE, {.dbl=8.2},0,
> 100., V|F },
>
> {"flags", "set flags", OFFSET(flags), AV_OPT_TYPE_FLAGS,
> {.i64=FRAMERATE_FLAG_SCD}, FRAMERATE_FLAG_NONE, FRAMERATE_FLAG_SCD, V|F,
> "flags" },
> CONST("none", "disable scene change detection",
> FRAMERATE_FLAG_NONE,"flags"),
> --
> 2.6.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Hi, On Sat, Sep 21, 2019 at 10:07 AM Nicolas George wrote: > Carl Eugen Hoyos (12019-09-21): > > I now wonder if this isn't much nicer than "You may use this FDK AAC > > Codec software or modifications thereto only for purposes that are > > authorized by appropriate patent licenses." > > (In the sense that it doesn't try to conceal the true terms) > > It is not "nicer", it is incompetent. If you read the whole COPYING file > from libg722_1: > > > https://github.com/traviscross/freeswitch/blob/master/libs/libg722_1/COPYING > > you realize is is not actually a license: is does not contain anything > that gives the authorization to use their code. > > Compare to the license of fdk-aac, which is proper legalese, gives > explicitly the right to use the code, and has been vetted by Debian. OK, hold on guys, wait. I had to read this 3x and it took me a while to get to this point (in my head). Others may be similarly confused. So it appears, from the discussion (..), that although there is source code, it is not actually "open" in the sense that it's not redistributable (at least not explicitly so) or modifiable? If I were hosting a copy on, say, github (or Debian), I'd be in legal trouble with this Freeswitch company? That's a serious issue, and I'd tend to agree with Nicolas we then probably don't want to link to such code... Or do I misunderstand? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v1 4/4] avfilter/vf_framerate: limit the scene level max range
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_framerate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_framerate.c b/libavfilter/vf_framerate.c
index 6383f69..59d58e7 100644
--- a/libavfilter/vf_framerate.c
+++ b/libavfilter/vf_framerate.c
@@ -53,7 +53,7 @@ static const AVOption framerate_options[] = {
{"interp_start","point to start linear interpolation",
OFFSET(interp_start),AV_OPT_TYPE_INT, {.i64=15}, 0,
255, V|F },
{"interp_end", "point to end linear interpolation",
OFFSET(interp_end), AV_OPT_TYPE_INT, {.i64=240},0,
255, V|F },
-{"scene", "scene change level",
OFFSET(scene_score), AV_OPT_TYPE_DOUBLE, {.dbl=8.2},0,
INT_MAX, V|F },
+{"scene", "scene change level",
OFFSET(scene_score), AV_OPT_TYPE_DOUBLE, {.dbl=8.2},0,
100., V|F },
{"flags", "set flags", OFFSET(flags), AV_OPT_TYPE_FLAGS,
{.i64=FRAMERATE_FLAG_SCD}, FRAMERATE_FLAG_NONE, FRAMERATE_FLAG_SCD, V|F,
"flags" },
CONST("none", "disable scene change detection",
FRAMERATE_FLAG_NONE,"flags"),
--
2.6.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v1 3/4] avfilter/vf_framerate: remove duplicate code with macro-based function
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/framerate.h| 3 +--
libavfilter/vf_framerate.c | 58 +-
2 files changed, 27 insertions(+), 34 deletions(-)
diff --git a/libavfilter/framerate.h b/libavfilter/framerate.h
index 3d8200b..887f173 100644
--- a/libavfilter/framerate.h
+++ b/libavfilter/framerate.h
@@ -28,8 +28,7 @@
ptrdiff_t width, ptrdiff_t height, \
int factor1, int factor2, int half
-#define BLEND_FACTOR_DEPTH8 7
-#define BLEND_FACTOR_DEPTH16 15
+#define BLEND_FACTOR_DEPTH(n) (n-1)
typedef void (*blend_func)(BLEND_FUNC_PARAMS);
diff --git a/libavfilter/vf_framerate.c b/libavfilter/vf_framerate.c
index 1254da8..6383f69 100644
--- a/libavfilter/vf_framerate.c
+++ b/libavfilter/vf_framerate.c
@@ -236,44 +236,38 @@ static int query_formats(AVFilterContext *ctx)
return ff_set_common_formats(ctx, fmts_list);
}
-static void blend_frames_c(BLEND_FUNC_PARAMS)
-{
-int line, pixel;
-for (line = 0; line < height; line++) {
-for (pixel = 0; pixel < width; pixel++)
-dst[pixel] = ((src1[pixel] * factor1) + (src2[pixel] * factor2) +
half) >> BLEND_FACTOR_DEPTH8;
-src1 += src1_linesize;
-src2 += src2_linesize;
-dst += dst_linesize;
-}
-}
-
-static void blend_frames16_c(BLEND_FUNC_PARAMS)
-{
-int line, pixel;
-uint16_t *dstw = (uint16_t *)dst;
-uint16_t *src1w = (uint16_t *)src1;
-uint16_t *src2w = (uint16_t *)src2;
-width /= 2;
-src1_linesize /= 2;
-src2_linesize /= 2;
-dst_linesize /= 2;
-for (line = 0; line < height; line++) {
-for (pixel = 0; pixel < width; pixel++)
-dstw[pixel] = ((src1w[pixel] * factor1) + (src2w[pixel] * factor2)
+ half) >> BLEND_FACTOR_DEPTH16;
-src1w += src1_linesize;
-src2w += src2_linesize;
-dstw += dst_linesize;
-}
+#define BLEND_FRAME_FUNC(nbits) \
+static void blend_frames##nbits##_c(BLEND_FUNC_PARAMS) \
+{ \
+int line, pixel;\
+uint##nbits##_t *dstw = (uint##nbits##_t *)dst;\
+uint##nbits##_t *src1w = (uint##nbits##_t *)src1; \
+uint##nbits##_t *src2w = (uint##nbits##_t *)src2; \
+int bytes = nbits / 8; \
+width /= bytes; \
+src1_linesize /= bytes; \
+src2_linesize /= bytes; \
+dst_linesize /= bytes; \
+for (line = 0; line < height; line++) { \
+for (pixel = 0; pixel < width; pixel++) \
+dstw[pixel] = ((src1w[pixel] * factor1) + \
+(src2w[pixel] * factor2) + half)\
+>> BLEND_FACTOR_DEPTH(nbits); \
+src1w += src1_linesize; \
+src2w += src2_linesize; \
+dstw += dst_linesize; \
+} \
}
+BLEND_FRAME_FUNC(8)
+BLEND_FRAME_FUNC(16)
void ff_framerate_init(FrameRateContext *s)
{
if (s->bitdepth == 8) {
-s->blend_factor_max = 1 << BLEND_FACTOR_DEPTH8;
-s->blend = blend_frames_c;
+s->blend_factor_max = 1 << BLEND_FACTOR_DEPTH(8);
+s->blend = blend_frames8_c;
} else {
-s->blend_factor_max = 1 << BLEND_FACTOR_DEPTH16;
+s->blend_factor_max = 1 << BLEND_FACTOR_DEPTH(16);
s->blend = blend_frames16_c;
}
if (ARCH_X86)
--
2.6.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v1 2/4] avfilter/vf_framerate: refine the filter_slice code for better readiablity
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/framerate.h| 1 +
libavfilter/vf_framerate.c | 35 +--
2 files changed, 14 insertions(+), 22 deletions(-)
diff --git a/libavfilter/framerate.h b/libavfilter/framerate.h
index 8048dfa..3d8200b 100644
--- a/libavfilter/framerate.h
+++ b/libavfilter/framerate.h
@@ -43,6 +43,7 @@ typedef struct FrameRateContext {
int interp_end; ///< end of range to apply linear
interpolation
int line_size[4]; ///< bytes of pixel data per line for
each plane
+int height[4]; ///< bytes of pixel data per height
for each plane
int vsub;
AVRational srce_time_base; ///< timebase of source
diff --git a/libavfilter/vf_framerate.c b/libavfilter/vf_framerate.c
index 99faf75..1254da8 100644
--- a/libavfilter/vf_framerate.c
+++ b/libavfilter/vf_framerate.c
@@ -98,29 +98,20 @@ static int filter_slice(AVFilterContext *ctx, void *arg,
int job, int nb_jobs)
{
FrameRateContext *s = ctx->priv;
ThreadData *td = arg;
+AVFrame *work = s->work, *src1 = td->copy_src1, *src2 = td->copy_src2;
uint16_t src1_factor = td->src1_factor;
uint16_t src2_factor = td->src2_factor;
int plane;
-for (plane = 0; plane < 4 && td->copy_src1->data[plane] &&
td->copy_src2->data[plane]; plane++) {
-int cpy_line_width = s->line_size[plane];
-uint8_t *cpy_src1_data = td->copy_src1->data[plane];
-int cpy_src1_line_size = td->copy_src1->linesize[plane];
-uint8_t *cpy_src2_data = td->copy_src2->data[plane];
-int cpy_src2_line_size = td->copy_src2->linesize[plane];
-int cpy_src_h = (plane > 0 && plane < 3) ? (td->copy_src1->height >>
s->vsub) : (td->copy_src1->height);
-uint8_t *cpy_dst_data = s->work->data[plane];
-int cpy_dst_line_size = s->work->linesize[plane];
-const int start = (cpy_src_h * job ) / nb_jobs;
-const int end = (cpy_src_h * (job+1)) / nb_jobs;
-cpy_src1_data += start * cpy_src1_line_size;
-cpy_src2_data += start * cpy_src2_line_size;
-cpy_dst_data += start * cpy_dst_line_size;
-
-s->blend(cpy_src1_data, cpy_src1_line_size,
- cpy_src2_data, cpy_src2_line_size,
- cpy_dst_data, cpy_dst_line_size,
- cpy_line_width, end - start,
+for (plane = 0; plane < 4 && src1->data[plane] && src2->data[plane];
plane++) {
+const int start = (s->height[plane] * job ) / nb_jobs;
+const int end = (s->height[plane] * (job+1)) / nb_jobs;
+uint8_t *src1_data = src1->data[plane] + start * src1->linesize[plane];
+uint8_t *src2_data = src2->data[plane] + start * src2->linesize[plane];
+uint8_t *dst_data = work->data[plane] + start * work->linesize[plane];
+
+s->blend(src1_data, src1->linesize[plane], src2_data,
src2->linesize[plane],
+ dst_data, work->linesize[plane], s->line_size[plane], end -
start,
src1_factor, src2_factor, s->blend_factor_max >> 1);
}
@@ -296,13 +287,13 @@ static int config_input(AVFilterLink *inlink)
const AVPixFmtDescriptor *pix_desc = av_pix_fmt_desc_get(inlink->format);
int plane;
+s->vsub = pix_desc->log2_chroma_h;
for (plane = 0; plane < 4; plane++) {
-s->line_size[plane] = av_image_get_linesize(inlink->format, inlink->w,
-plane);
+s->line_size[plane] = av_image_get_linesize(inlink->format, inlink->w,
plane);
+s->height[plane] = inlink->h >> ((plane == 1 || plane == 2) ? s->vsub
: 0);
}
s->bitdepth = pix_desc->comp[0].depth;
-s->vsub = pix_desc->log2_chroma_h;
if ((s->flags & FRAMERATE_FLAG_SCD)) {
s->sad = ff_scene_sad_get_fn(s->bitdepth == 8 ? 8 : 16);
--
2.6.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v1 1/4] avfilter/vf_framerate: add flags none to disable scene change detection if necessary
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/filters.texi | 2 ++
libavfilter/vf_framerate.c | 17 +++--
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index bbfdad4..fce4ef4 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10637,6 +10637,8 @@ Specify flags influencing the filter process.
Available value for @var{flags} is:
@table @option
+@item none
+Disable scene change detection
@item scene_change_detect, scd
Enable scene change detection using the value of the option @var{scene}.
This flag is enabled by default.
diff --git a/libavfilter/vf_framerate.c b/libavfilter/vf_framerate.c
index 06e463e..99faf75 100644
--- a/libavfilter/vf_framerate.c
+++ b/libavfilter/vf_framerate.c
@@ -44,7 +44,9 @@
#define OFFSET(x) offsetof(FrameRateContext, x)
#define V AV_OPT_FLAG_VIDEO_PARAM
#define F AV_OPT_FLAG_FILTERING_PARAM
+#define FRAMERATE_FLAG_NONE 00
#define FRAMERATE_FLAG_SCD 01
+#define CONST(name, help, val, unit) { name, help, 0, AV_OPT_TYPE_CONST,
{.i64=val}, 0, 0, V|F, unit }
static const AVOption framerate_options[] = {
{"fps", "required output frames per second rate",
OFFSET(dest_frame_rate), AV_OPT_TYPE_VIDEO_RATE, {.str="50"}, 0,
INT_MAX, V|F },
@@ -53,9 +55,10 @@ static const AVOption framerate_options[] = {
{"interp_end", "point to end linear interpolation",
OFFSET(interp_end), AV_OPT_TYPE_INT, {.i64=240},0,
255, V|F },
{"scene", "scene change level",
OFFSET(scene_score), AV_OPT_TYPE_DOUBLE, {.dbl=8.2},0,
INT_MAX, V|F },
-{"flags", "set flags",
OFFSET(flags), AV_OPT_TYPE_FLAGS,{.i64=1}, 0,
INT_MAX, V|F, "flags" },
-{"scene_change_detect", "enable scene change detection", 0,
AV_OPT_TYPE_CONST,{.i64=FRAMERATE_FLAG_SCD}, INT_MIN,
INT_MAX, V|F, "flags" },
-{"scd", "enable scene change detection", 0,
AV_OPT_TYPE_CONST,{.i64=FRAMERATE_FLAG_SCD}, INT_MIN,
INT_MAX, V|F, "flags" },
+{"flags", "set flags", OFFSET(flags), AV_OPT_TYPE_FLAGS,
{.i64=FRAMERATE_FLAG_SCD}, FRAMERATE_FLAG_NONE, FRAMERATE_FLAG_SCD, V|F,
"flags" },
+CONST("none", "disable scene change detection",
FRAMERATE_FLAG_NONE,"flags"),
+CONST("scene_change_detect", "enable scene change detection",
FRAMERATE_FLAG_SCD, "flags"),
+CONST("scd", "enable scene change detection",
FRAMERATE_FLAG_SCD, "flags"),
{NULL}
};
@@ -301,9 +304,11 @@ static int config_input(AVFilterLink *inlink)
s->bitdepth = pix_desc->comp[0].depth;
s->vsub = pix_desc->log2_chroma_h;
-s->sad = ff_scene_sad_get_fn(s->bitdepth == 8 ? 8 : 16);
-if (!s->sad)
-return AVERROR(EINVAL);
+if ((s->flags & FRAMERATE_FLAG_SCD)) {
+s->sad = ff_scene_sad_get_fn(s->bitdepth == 8 ? 8 : 16);
+if (!s->sad)
+return AVERROR(EINVAL);
+}
s->srce_time_base = inlink->time_base;
--
2.6.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec/v210enc: add yuv420p/yuv420p10 input pixel format support
On Sat, Sep 21, 2019 at 03:13:46PM +0200, Carl Eugen Hoyos wrote: > Am Sa., 21. Sept. 2019 um 14:42 Uhr schrieb : > > > > From: Limin Wang > > > > With the patch, we simply reuse the same source chroma line for each pair > > of lines in the output > > Is there really no quality hit for a 20% speed-up? The quality is OK by my testing for the 420 to 422, I have no idea how to compare with the difference between them, Micheal can give more suggestion on that. however the patch try to fix the autoscale, if user prefer to use swscale conversion, he can use it still by claims pix_fmt clearly. The following command shows how to use the old conversion by swscale. no swscale: ./ffmpeg -y -lavfi testsrc2=s=4096x3072:r=10:d=10,format=pix_fmts=yuv420p -c:v v210 -f null - swscale: ./ffmpeg -y -lavfi testsrc2=s=4096x3072:r=10:d=10,format=pix_fmts=yuv420p -c:v v210 -pix_fmt yuv422p -f null - Thanks, Limin > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Carl Eugen Hoyos (12019-09-21): > And again, you cut the relevant part: > Are you maybe less interested in arguments than you claim? > Or just having a bad day? I am having a bad day because I find this very discussion with you very annoying. If you have anything to add to the discussion, do it in a self-contained, fully documented way. For now, I consider the matter settled: lacking a proper license, we cannot even consider including this library. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Am Sa., 21. Sept. 2019 um 16:25 Uhr schrieb Nicolas George : > > I believe you misunderstand. > > You are entitled to your beliefs. Let us discuss arguments on this > mailing-list. > > Can we close the subject now? And again, you cut the relevant part: Are you maybe less interested in arguments than you claim? Or just having a bad day? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Carl Eugen Hoyos (12019-09-21): > Interesting how different we interpret the licenses. There should be no interpreting a license: it is a legal document, what counts is what is written explicitly. > I believe you misunderstand. You are entitled to your beliefs. Let us discuss arguments on this mailing-list. Can we close the subject now? Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Am Sa., 21. Sept. 2019 um 16:07 Uhr schrieb Nicolas George : > > Carl Eugen Hoyos (12019-09-21): > > I now wonder if this isn't much nicer than "You may use this FDK AAC > > Codec software or modifications thereto only for purposes that are > > authorized by appropriate patent licenses." > > (In the sense that it doesn't try to conceal the true terms) > > It is not "nicer", it is incompetent. If you read the whole COPYING file > from libg722_1: > > https://github.com/traviscross/freeswitch/blob/master/libs/libg722_1/COPYING > > you realize is is not actually a license: is does not contain anything > that gives the authorization to use their code. > > Compare to the license of fdk-aac, which is proper legalese, gives > explicitly the right to use the code, and has been vetted by Debian. Interesting how different we interpret the licenses. > > Anyway, the more important question is how to deal with Freeswitch. > > Not accept their code unless they fix the license. Easy. I believe you misunderstand. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Carl Eugen Hoyos (12019-09-21): > I now wonder if this isn't much nicer than "You may use this FDK AAC > Codec software or modifications thereto only for purposes that are > authorized by appropriate patent licenses." > (In the sense that it doesn't try to conceal the true terms) It is not "nicer", it is incompetent. If you read the whole COPYING file from libg722_1: https://github.com/traviscross/freeswitch/blob/master/libs/libg722_1/COPYING you realize is is not actually a license: is does not contain anything that gives the authorization to use their code. Compare to the license of fdk-aac, which is proper legalese, gives explicitly the right to use the code, and has been vetted by Debian. > Anyway, the more important question is how to deal with Freeswitch. Not accept their code unless they fix the license. Easy. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Am Sa., 21. Sept. 2019 um 15:19 Uhr schrieb Nicolas George : > > Carl Eugen Hoyos (12019-09-21): > > I did and I ask you. > > Please tell me how you can think that "require the licencing of patents > from Polycom" is compatible with "shall not restrict any party from > selling or giving away the software"? I now wonder if this isn't much nicer than "You may use this FDK AAC Codec software or modifications thereto only for purposes that are authorized by appropriate patent licenses." (In the sense that it doesn't try to conceal the true terms) Anyway, the more important question is how to deal with Freeswitch. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/ffwavesynth: Fix integer overflow in timestamps
Michael Niedermayer (12019-09-06):
> Fixes: signed integer overflow: 9223371075321077760 * 2 cannot be represented
> in type 'long'
> Fixes:
> 16447/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFWAVESYNTH_fuzzer-5698937431785472
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/ffwavesynth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/ffwavesynth.c b/libavcodec/ffwavesynth.c
> index cfd0951d8f..8079e34539 100644
> --- a/libavcodec/ffwavesynth.c
> +++ b/libavcodec/ffwavesynth.c
> @@ -220,7 +220,7 @@ static void wavesynth_seek(struct wavesynth_context *ws,
> int64_t ts)
> int64_t pink_ts_cur = (ws->cur_ts + PINK_UNIT - 1) & ~(PINK_UNIT -
> 1);
> int64_t pink_ts_next = ts & ~(PINK_UNIT - 1);
> int pos = ts & (PINK_UNIT - 1);
> -lcg_seek(>pink_state, (pink_ts_next - pink_ts_cur) * 2);
> +lcg_seek(>pink_state, (pink_ts_next - pink_ts_cur) * 2ULL);
Casting (pink_ts_next - pink_ts_cur) to uint32_t seems like a better
idea.
> if (pos) {
> pink_fill(ws);
> ws->pink_pos = pos;
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Carl Eugen Hoyos (12019-09-21): > I did and I ask you. Please tell me how you can think that "require the licencing of patents from Polycom" is compatible with "shall not restrict any party from selling or giving away the software"? > Note that in this case, cutting the remaining message seems not ideal. Wasting my time and the time of everybody still reading this thread is even less ideal. Admit you are ill-documented about software licenses, read about it a lot. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Am Sa., 21. Sept. 2019 um 15:11 Uhr schrieb Nicolas George : > > Carl Eugen Hoyos (12019-09-21): > > But I wonder now which specific part of the OSI definition is not met > > by libg7221 in your opinion? > > Read the license, read the OSD. I did and I ask you. Note that in this case, cutting the remaining message seems not ideal. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec/v210enc: add yuv420p/yuv420p10 input pixel format support
Am Sa., 21. Sept. 2019 um 14:42 Uhr schrieb : > > From: Limin Wang > > With the patch, we simply reuse the same source chroma line for each pair > of lines in the output Is there really no quality hit for a 20% speed-up? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Carl Eugen Hoyos (12019-09-21): > But I wonder now which specific part of the OSI definition is not met > by libg7221 in your opinion? Read the license, read the OSD. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Am Sa., 21. Sept. 2019 um 15:03 Uhr schrieb Nicolas George : > > Carl Eugen Hoyos (12019-09-21): > > The FSF does make a difference between open-source software and > > free software, I believe they are more qualified than you are. > > The FSF is known to make a fuss about minute details. But in this case > you are wrong and I was right. Please read about it. The OSI definition - that supports your point - is the definition that the FSF - which defined the licenses we are using - refuses. But I wonder now which specific part of the OSI definition is not met by libg7221 in your opinion? Note that your answer will most likely not be shared by the Freeswitch people who apparently distribute binaries based on libg7221... (I have neither downloaded nor used Freeswitch, afaict thay may just offer libg7221 as additional source.) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V1] lavc/mpeg4audio: add chan_config check to avoid indeterminate channels
On Sat, Sep 21, 2019 at 19:29:47 +0800, Jun Zhao wrote:
> +else {
> +av_log(NULL, AV_LOG_ERROR, "Invalid chan_config %d\n",
> c->chan_config);
> +return -1;
> +}
I know the function definition says it returns -1 on error, but that's
already not the case: It can return AVERROR_INVALIDDATA by means of the
call to parse_config_ALS(). I believe the doc should be changed, and
this code change should also return AVERROR_INVALIDDATA.
Furthermore, can you pass and find a useful context for this av_log()
(and for the one in parse_config_ALS()? av_log() with NULL context is
very unfortunate.
Cheers,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Carl Eugen Hoyos (12019-09-21): > The FSF does make a difference between open-source software and > free software, I believe they are more qualified than you are. The FSF is known to make a fuss about minute details. But in this case you are wrong and I was right. Please read about it. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Am Sa., 21. Sept. 2019 um 14:48 Uhr schrieb Nicolas George : > > Carl Eugen Hoyos (12019-09-21): > > This is obviously not true as there are licenses that - for example - > > only allow non-commercial distribution. > > They are therefore not Open Source. You obviously have acquired less > documentation about the subject than me: I ask that you either trust > that I am right or take the time to check by yourself. But please stop > assuming you are informed. Thank you (again)! The FSF does make a difference between open-source software and free software, I believe they are more qualified than you are. Thank you for your enlightenment, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Carl Eugen Hoyos (12019-09-21): > This is obviously not true as there are licenses that - for example - > only allow non-commercial distribution. They are therefore not Open Source. You obviously have acquired less documentation about the subject than me: I ask that you either trust that I am right or take the time to check by yourself. But please stop assuming you are informed. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Am Sa., 21. Sept. 2019 um 14:43 Uhr schrieb Nicolas George : > There is almost no practical difference between Free Software > and Open Source. This is obviously not true as there are licenses that - for example - only allow non-commercial distribution. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Carl Eugen Hoyos (12019-09-21): > Thanks for the repeated ad-hominem Repeated? > but are you sure that you are not > mixing up Free Software and Open Source? Are you sure you know the difference between Free Software and Open Source? This question shows that you do not. There is almost no practical difference between Free Software and Open Source. The main difference is point of view and emphasis. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avcodec/v210enc: add yuv420p/yuv420p10 input pixel format support
From: Limin Wang
With the patch, we simply reuse the same source chroma line for each pair
of lines in the output and the yuv420 and yuv420p10 format of the decoder
can go to the v210 encoder without having to touch the pixels at all with
autoscale by swscale filter.
The end effect is swscale filter is running the full scaling algorithm
against a line that doesn't require any scaling or bit depth conversion,
where a simple memcpy() could achieve the same result.
This can improve performance a lot, the following are the benchmark results:
1. yuv420p
./ffmpeg -benchmark -y -lavfi testsrc2=s=4096x3072:r=10:d=10 -pix_fmt yuv420p
-c:v v210 -f null -
master:
frame= 100 fps= 30 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A speed=3.02x
bench: utime=2.762s stime=0.539s rtime=3.308s
bench: maxrss=93372416kB
applied the patch:
frame= 100 fps= 36 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A speed=3.57x
video:3302400kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown
bench: utime=2.258s stime=0.536s rtime=2.803s
bench: maxrss=80809984kB
2. yuv420p10
./ffmpeg -benchmark -y -lavfi testsrc2=s=4096x3072:r=10:d=10 -pix_fmt
yuv420p10 -c:v v210 -f null -
master:
frame= 100 fps= 26 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A speed=2.61x
video:3302400kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown
bench: utime=3.257s stime=0.559s rtime=3.827s
bench: maxrss=152371200kB
applied the patch
frame= 100 fps= 31 q=-0.0 Lsize=N/A time=00:00:10.00 bitrate=N/A speed=3.11x
video:3302400kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown
bench: utime=2.625s stime=0.573s rtime=3.212s
bench: maxrss=127197184kB
Signed-off-by: Devin Heitmueller
Signed-off-by: Limin Wang
---
libavcodec/v210_template.c | 20
libavcodec/v210enc.c | 8 +---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/libavcodec/v210_template.c b/libavcodec/v210_template.c
index 9e1d9f9..083a9f1 100644
--- a/libavcodec/v210_template.c
+++ b/libavcodec/v210_template.c
@@ -43,11 +43,31 @@ static void RENAME(v210_enc)(AVCodecContext *avctx,
const TYPE *y = (const TYPE *)pic->data[0];
const TYPE *u = (const TYPE *)pic->data[1];
const TYPE *v = (const TYPE *)pic->data[2];
+const TYPE *u_even = u;
+const TYPE *v_even = v;
const int sample_size = 6 * s->RENAME(sample_factor);
const int sample_w= avctx->width / sample_size;
for (h = 0; h < avctx->height; h++) {
uint32_t val;
+
+if (pic->format == AV_PIX_FMT_YUV420P10 ||
+pic->format == AV_PIX_FMT_YUV420P) {
+int mod = pic->interlaced_frame == 1 ? 4 : 2;
+if (h % mod == 0) {
+u_even = u;
+v_even = v;
+} else {
+/* progressive chroma */
+if (mod == 2) {
+u = u_even;
+v = v_even;
+} else if (h % 4 == 2) {
+u = u_even;
+v = v_even;
+}
+}
+}
w = sample_w * sample_size;
s->RENAME(pack_line)(y, u, v, dst, w);
diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
index 16e8810..2180737 100644
--- a/libavcodec/v210enc.c
+++ b/libavcodec/v210enc.c
@@ -131,9 +131,9 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
}
dst = pkt->data;
-if (pic->format == AV_PIX_FMT_YUV422P10)
+if (pic->format == AV_PIX_FMT_YUV422P10 || pic->format ==
AV_PIX_FMT_YUV420P10)
v210_enc_10(avctx, dst, pic);
-else if(pic->format == AV_PIX_FMT_YUV422P)
+else if(pic->format == AV_PIX_FMT_YUV422P || pic->format ==
AV_PIX_FMT_YUV420P)
v210_enc_8(avctx, dst, pic);
side_data = av_frame_get_side_data(pic, AV_FRAME_DATA_A53_CC);
@@ -165,5 +165,7 @@ AVCodec ff_v210_encoder = {
.priv_data_size = sizeof(V210EncContext),
.init = encode_init,
.encode2= encode_frame,
-.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV422P10,
AV_PIX_FMT_YUV422P, AV_PIX_FMT_NONE },
+.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV422P10,
AV_PIX_FMT_YUV422P,
+AV_PIX_FMT_YUV420P10,
AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_NONE },
};
--
2.6.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Am Sa., 21. Sept. 2019 um 14:35 Uhr schrieb Nicolas George : > > Carl Eugen Hoyos (12019-09-21): > > Both libraries are open-source > > Please re-read my mail from 13:41:34 +0200 and the license I pointed at > 13:55:53 +0200. > > And just in case you managed to stay for more than a decade contributing > to an open-source project without knowing what it means, read the Open > Source Definition. Thanks for the repeated ad-hominem but are you sure that you are not mixing up Free Software and Open Source? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Carl Eugen Hoyos (12019-09-21): > Both libraries are open-source Please re-read my mail from 13:41:34 +0200 and the license I pointed at 13:55:53 +0200. And just in case you managed to stay for more than a decade contributing to an open-source project without knowing what it means, read the Open Source Definition. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Am Sa., 21. Sept. 2019 um 14:29 Uhr schrieb Nicolas George : > > Carl Eugen Hoyos (12019-09-21): > > So what is the difference between open-source software with a license > > incompatible > > with the GPL and an open-source software with a license incompatible > > with the GPL? > > Please fix your question. As it is, it is absurd. What is - in your opinion - the difference between libg7221 and libfdk-aac from FFmpeg's GPL license point-of-view? Both libraries are open-source, and both libraries have licenses incompatible with the GPL. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Carl Eugen Hoyos (12019-09-21): > So what is the difference between open-source software with a license > incompatible > with the GPL and an open-source software with a license incompatible > with the GPL? Please fix your question. As it is, it is absurd. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Am Sa., 21. Sept. 2019 um 13:56 Uhr schrieb Nicolas George : > > Carl Eugen Hoyos (12019-09-21): > > Could you elaborate? > > I can point you to the license file: > > https://github.com/traviscross/freeswitch/blob/master/libs/libg722_1/COPYING So what is the difference between open-source software with a license incompatible with the GPL and an open-source software with a license incompatible with the GPL? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Carl Eugen Hoyos (12019-09-21): > Could you elaborate? I can point you to the license file: https://github.com/traviscross/freeswitch/blob/master/libs/libg722_1/COPYING Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Am Sa., 21. Sept. 2019 um 13:41 Uhr schrieb Nicolas George : > > Carl Eugen Hoyos (12019-09-21): > > > Non-free originally came to be because of fdk-aac, which is open > > > source but doesn't meet the requirements of the (L)GPL. > > How is that different from libg7221? > > libg7221 is not open-source, AFAICT. Could you elaborate? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Carl Eugen Hoyos (12019-09-21): > > Non-free originally came to be because of fdk-aac, which is open > > source but doesn't meet the requirements of the (L)GPL. > How is that different from libg7221? libg7221 is not open-source, AFAICT. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it ok to add G.722.1 decoder as external lib?
Am Do., 19. Sept. 2019 um 09:10 Uhr schrieb Tomas Härdin : > Non-free originally came to be because of fdk-aac, which is open > source but doesn't meet the requirements of the (L)GPL. How is that different from libg7221? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V1] lavc/mpeg4audio: add chan_config check to avoid indeterminate channels
From: Jun Zhao
add chan_config check to avoid indeterminate channels.
Signed-off-by: Jun Zhao
---
libavcodec/mpeg4audio.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/libavcodec/mpeg4audio.c b/libavcodec/mpeg4audio.c
index 2197147..0ada239 100644
--- a/libavcodec/mpeg4audio.c
+++ b/libavcodec/mpeg4audio.c
@@ -93,6 +93,10 @@ int ff_mpeg4audio_get_config_gb(MPEG4AudioConfig *c,
GetBitContext *gb,
c->chan_config = get_bits(gb, 4);
if (c->chan_config < FF_ARRAY_ELEMS(ff_mpeg4audio_channels))
c->channels = ff_mpeg4audio_channels[c->chan_config];
+else {
+av_log(NULL, AV_LOG_ERROR, "Invalid chan_config %d\n", c->chan_config);
+return -1;
+}
c->sbr = -1;
c->ps = -1;
if (c->object_type == AOT_SBR || (c->object_type == AOT_PS &&
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avutil/opt: Fix type specifier
This bug has been introduced in 9e0a071e. Signed-off-by: Andreas Rheinhardt --- libavutil/opt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/opt.c b/libavutil/opt.c index 35dc9e153d..7c2649725f 100644 --- a/libavutil/opt.c +++ b/libavutil/opt.c @@ -1200,7 +1200,7 @@ static void opt_list(void *obj, void *av_log_obj, const char *unit, break; case AV_OPT_TYPE_CONST: if (parent_type == AV_OPT_TYPE_INT) -av_log(av_log_obj, AV_LOG_INFO, "%-12d ", opt->default_val.i64); +av_log(av_log_obj, AV_LOG_INFO, "%-12"PRId64" ", opt->default_val.i64); else av_log(av_log_obj, AV_LOG_INFO, "%-12s ", ""); break; -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] libavfilter/dnn: add layer maximum for native mode.
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Pedro Arthur > Sent: Friday, September 20, 2019 11:14 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH 1/4] libavfilter/dnn: add layer maximum for > native mode. > > Em sex, 20 de set de 2019 às 11:50, Guo, Yejun > escreveu: > > > > > > > > > -Original Message- > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of > > > Pedro Arthur > > > Sent: Friday, September 20, 2019 10:17 PM > > > To: FFmpeg development discussions and patches > > > > Subject: Re: [FFmpeg-devel] [PATCH 1/4] libavfilter/dnn: add layer maximum > for > > > native mode. > > > > > > Hi, > > > > > > Em sex, 20 de set de 2019 às 01:00, Guo, Yejun > > > escreveu: > > > > > > > > The reason to add this layer is that it is used by srcnn in vf_sr. > > > > This layer is currently ignored in native mode. After this patch, > > > > we can add multiple outputs support for native mode. > > > > > > > I did not quite understand the commit message. Where does srcnn needs > > > max a layer? > > > > see > https://github.com/HighVoltageRocknRoll/sr/blob/master/models/model_srcn > n.py#L39 , > > the maximum layer is the last layer of the model. > I see, indeed if I'm not missing something this max layer is > superfulous as the relu activation already does this right? > What we have to guarantee is that the output is in the range [0, 1], > that means we should have had a layer min(y, 1) instead of the max or > guarantee the conversion from float to integer properly saturates y > > 1. yes, I think so. > > > > > > What is the relation between max layer and supporting multiple outputs? > > > > thanks, I did not describe it explicitly, will add more detail as below. > > > > The direct relation is the max layer and the model output name, and then > multiple outputs > > can be supported after the output name matching is supported. > > > > suppose the output name of srcnn is 'y', it means that the output name of > max layer is 'y' > > since max layer is the last layer. And suppose the input name of max layer > > is > 'z', the network > > looks like: > > ... -> 'z' -> (max layer) -> 'y' > > > > In current implementation, the max layer is ignored in native mode, it means > that 'y' is also > > discarded in native mode. The output name of the native model becomes 'z'. > And so we could not > > find the correct output operand with name 'y'. > > > > The reason that current implementation works is that we just consider the > last operand as the > > model output, ignoring the name matching. > > > > to support multiple outputs, we have to recognize output operands by names. > To support the output searching > > with name, we must add 'y' back to srcnn (that is to handle max layer), so > > the > vf_sr is compatible to work in both tf mode and native mode. > > > thanks, in any case the patch is useful, I should push it soon. thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
