Re: [FFmpeg-devel] [PATCH 03/14] pthread_frame: merge the functionality for normal decoder init and init_thread_copy
On 4/2/20 2:13 AM, Anton Khirnov wrote: > Quoting David Bryant (2020-04-01 23:35:13) >> On 3/31/20 2:47 AM, Anton Khirnov wrote: > Looking at wavpack, the code looks suspicious to me. You allocate one > dsdctx per channel at init, but AFAIU the number of channels can change > at each frame. > Multichannel WavPack consists of sequences of stereo or mono WavPack blocks that include flags indicating whether they are the beginning or end of a "frame" or "packet". This allows the number of channels available to be essentially unlimited, however the total number of channels in a stream may not change. When decoding, if a sequence of blocks generates more or less than the correct number of channels, this is flagged as an error and overrun is prevented (see libavcodec/wavpack.c, line 1499 and line 1621). >>> If my reading of the code is correct, line 1499 only checks for overflow >>> of the channel count read for the current sequence. That channel count >>> is exported to AVCodeContext in the block starting on line 1464 and >>> I don't see any checks for whether it is equal to the initial one. >>> >> Full disclosure: I did not write the WavPack decoder. I understand _how_ it >> works, but I don't necessarily understand _why_ it >> was written the way it was due to gaps in my knowledge of the FFmpeg >> internals, and there are certainly things in there that >> don't look quite right to me. >> >> That said, I have tested it thoroughly and it handles everything I throw at >> it, and I have extended it to handle the DSD mode >> without anything unexpected happening. And of course it seems to handle >> extensive fuzzing, and the recent error was related to >> my DSD change, suggesting that the core it pretty robust. My inclination has >> been to not "fix" anything that wasn't broken. >> >> Yes, that channel count stuff is a little difficult to follow. I could >> experiment with streams that abruptly change channel >> configuration, but again I'm hesitant to change code that's worked so well >> so long. > I can easily get the decoder to crash even in single-threaded mode. Just > make the demuxer always say the stream is mono, then try decoding your > DSD sample. Okay, I reproduced that. However, I'm not sure it's really that serious because the demuxer and the decoder use basically the same logic to determine that number of channels, so it would be tricky to craft a file that caused the demuxer to calculate 1 channel and the decoder to reach a different result, which is probably why the fuzzers have not been able to do so. That said, it would not be hard to have the decoder save away the initial channel count from avctx, never overwrite it, and verify that all superblocks match that count. I don't know off hand whether that would break anything though. Is it guaranteed that avctx->channels is correct during the call to decode_init(), even if it's being demuxed from Matroska, for example? If so, why is the WavPack decoder _ever_ writing to the avctx channel count? > > Also, I looked at the specification PDF you linked in the previous email > and I see nothing in it that explicitly forbids the channel count from > changing from one "superblock" to the next. It seems to me like you > could just concatenate wavpack files with different channel counts and > get a valid wavpack file. > You're right, I could not find that being explicitly forbidden. Nevertheless, it _is_ forbidden for any stream parameters to change (e.g. data format, sampling rate, channel count or mapping) and both libwavpack and the FFmpeg demuxer enforce this (see libavformat/wvdec.c starting at line 211), or at least gracefully fail without crashing. The reason it's never mentioned is probably just because it never occurred to me. None of the source file formats for WavPack (e.g., wav, caf, dsdiff) allow format changes and neither do any of the other lossless compressors I am aware of. I can't imagine how that would work, and extensive fuzzing has ensured that pathological files like you suggest are unlikely to be the source of exploits. Kind regards, David ___ 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] configure: fix build issue of vf_dnn_processing.c when --disable-swscale
> -Original Message- > From: Fu, Linjie > Sent: Thursday, April 02, 2020 12:16 PM > To: FFmpeg development discussions and patches > Cc: Guo, Yejun > Subject: RE: [FFmpeg-devel] [PATCH] configure: fix build issue of > vf_dnn_processing.c when --disable-swscale > > > From: ffmpeg-devel On Behalf Of > > Guo, Yejun > > Sent: Thursday, April 2, 2020 11:37 > > To: ffmpeg-devel@ffmpeg.org > > Cc: Guo, Yejun > > Subject: [FFmpeg-devel] [PATCH] configure: fix build issue of > > vf_dnn_processing.c when --disable-swscale > > > > vf_dnn_processing.c recently changed to use swscale to trasfer data > > between AVFrame and dnn model. > > > > Signed-off-by: Guo, Yejun > > --- > > configure | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/configure b/configure > > index 21827ee..56888a5 100755 > > --- a/configure > > +++ b/configure > > @@ -3498,6 +3498,7 @@ derain_filter_select="dnn" > > deshake_filter_select="pixelutils" > > deshake_opencl_filter_deps="opencl" > > dilation_opencl_filter_deps="opencl" > > +dnn_processing_filter_deps="swscale" > > dnn_processing_filter_select="dnn" > > drawtext_filter_deps="libfreetype" > > drawtext_filter_suggest="libfontconfig libfribidi" > > -- > > Looks reasonable, and verified the failure is gone with this patch. thanks, will push it. > > - Linjie ___ 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] configure: Do not abort when cross-compiling to the native CPU
On Thu, Apr 2, 2020 at 5:38 PM Michael Niedermayer wrote: > On Wed, Apr 01, 2020 at 12:07:55AM -0400, David Michael wrote: > > Using a compiler with a different host triplet is considered > > cross-compiling, even when it is for the same architecture as the > > build system. With such a cross-compiler, it is still valid to > > optimize builds with --cpu=host. Make the condition that aborts in > > this case into a warning instead, since a cross-compiler for an > > incompatible architecture will fail with -mtune=native anyway. > > > > Signed-off-by: David Michael > > --- > > > > Changes since v1: > > * Use a warning instead of dropping the condition altogether > > > > configure | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > will apply 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".
Re: [FFmpeg-devel] [PATCH] swscale/swscale: remove useless code
On Wed, Apr 01, 2020 at 03:32:15PM +0800, Ruiling Song wrote: > Signed-off-by: Ruiling Song > --- > libswscale/swscale.c | 16 +--- > libswscale/swscale_internal.h | 5 + > libswscale/x86/swscale.c | 3 +-- > 3 files changed, 3 insertions(+), 21 deletions(-) seems this has indeed become unused will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus 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] configure: Do not abort when cross-compiling to the native CPU
On Wed, Apr 01, 2020 at 12:07:55AM -0400, David Michael wrote: > Using a compiler with a different host triplet is considered > cross-compiling, even when it is for the same architecture as the > build system. With such a cross-compiler, it is still valid to > optimize builds with --cpu=host. Make the condition that aborts in > this case into a warning instead, since a cross-compiler for an > incompatible architecture will fail with -mtune=native anyway. > > Signed-off-by: David Michael > --- > > Changes since v1: > * Use a warning instead of dropping the condition altogether > > configure | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. 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 v9 2/3] libavcodec/jpeg2000dec.c: Add support for PPT marker
On Thu, Apr 02, 2020 at 08:24:13AM +0530, Gautam Ramakrishnan wrote: > On Thu, Apr 2, 2020 at 12:58 AM Michael Niedermayer > wrote: > > > > On Wed, Apr 01, 2020 at 08:01:48AM +0530, Gautam Ramakrishnan wrote: > > > On Wed, Apr 1, 2020 at 6:17 AM Michael Niedermayer > > > wrote: > > > > > > > > On Tue, Mar 31, 2020 at 05:32:41PM +0530, gautamr...@gmail.com wrote: > > > > > From: Gautam Ramakrishnan > > > > > > > > > > This patch adds functional changes to support the > > > > > PPT marker. > > > > > --- > > > > > libavcodec/jpeg2000dec.c | 85 > > > > > +++- > > > > > 1 file changed, 76 insertions(+), 9 deletions(-) > > > > > > > > can you explain why the jpeg2000_decode_packet* function is / needs to > > > > be > > > > split for this ? > > > > iam asking as it duplicates quite some code in the previous patch > > > > > > > so, if we can represent packet header as H and data as D, > > > without a PPT marker, the packet data is represented as > > > HDHDHDHD. > > > However, with the PPT marker, this is changed to > > > HDDD. > > > The jpeg2000_decode_packet() decodes a packet in the HD format. > > > However, to decode packets in packed form (this change should apply > > > even if PPM marker support is added), I thought it would be better if we > > > break the function to decode header and data separately. > > > > Is there any plan/need to call the 2 functions differently than always > > first one and immedeatly the 2nd ? > Hmm, I did not think of this. At the moment, I do not think so. Imo, even the > PPM marker addition should not make a difference. I really doubt that the > calling order will change. Does it look like a good idea to merge the function > back? i think so, it would be less duplicated code thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA 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] libavformat/amr.c: Check return value from avio_read()
On Wed, Apr 01, 2020 at 01:55:12PM -0700, John Rummell wrote:
> Updated to return AVERROR_INVALIDDATA.
>
> On Wed, Apr 1, 2020 at 12:33 PM Michael Niedermayer
> wrote:
>
> > On Mon, Mar 30, 2020 at 09:48:13PM -0700, John Rummell wrote:
> > > Hit send too soon. Patch attached.
> > >
> > > On Mon, Mar 30, 2020 at 9:44 PM John Rummell
> > wrote:
> > >
> > > > Another uninitialized memory access detected by the Chromium fuzzers.
> > > >
> >
> > > amr.c |6 --
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > > db486a31c1d3c7f4f51a7e5f5333f871744d6c87
> > 0001-libavformat-amr.c-Check-return-value-from-avio_read.patch
> > > From 0ef90d64a760f730652f3832da2abca47cff62d6 Mon Sep 17 00:00:00 2001
> > > From: John Rummell
> > > Date: Mon, 30 Mar 2020 21:30:33 -0700
> > > Subject: [PATCH] libavformat/amr.c: Check return value from avio_read()
> > >
> > > If the buffer doesn't contain enough bytes when reading a stream,
> > > fail rather than continuing on with initialized data. Caught by
> > > Chromium fuzzeras (crbug.com/1065731).
> > > ---
> > > libavformat/amr.c | 6 --
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavformat/amr.c b/libavformat/amr.c
> > > index eccbbde5b0..8570d43302 100644
> > > --- a/libavformat/amr.c
> > > +++ b/libavformat/amr.c
> > > @@ -89,13 +89,15 @@ static int amr_read_header(AVFormatContext *s)
> > > AVStream *st;
> > > uint8_t header[9];
> > >
> > > -avio_read(pb, header, 6);
> > > +if (avio_read(pb, header, 6) != 6)
> > > +return -1;
> > >
> > > st = avformat_new_stream(s, NULL);
> > > if (!st)
> > > return AVERROR(ENOMEM);
> > > if (memcmp(header, AMR_header, 6)) {
> > > -avio_read(pb, header + 6, 3);
> > > +if (avio_read(pb, header + 6, 3) != 3)
> > > +return -1;
> >
> > I see some of the existing code uses -1 instead of AVERROR*
> > but i think for newly added cases AVERROR* codes would be better
> >
> > thx
> >
> > [...]
> >
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
> > ___
> > 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".
> amr.c |6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
> 193bfc49b025e3cf58b28a53b38eb2e02a1e0e5f
> 0001-libavformat-amr.c-Check-return-value-from-avio_read.patch
> From 1d6313c4354f88ea985b32b6cc0255081a3fff7b Mon Sep 17 00:00:00 2001
> From: John Rummell
> Date: Mon, 30 Mar 2020 21:30:33 -0700
> Subject: [PATCH] libavformat/amr.c: Check return value from avio_read()
>
> If the buffer doesn't contain enough bytes when reading a stream,
> fail rather than continuing on with initialized data. Caught by
> Chromium fuzzeras (crbug.com/1065731).
> ---
> libavformat/amr.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
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 2/2] libswscale/tests/swscale: Use slices randomly
Output is identical
Signed-off-by: Michael Niedermayer
---
libswscale/tests/swscale.c | 41 --
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/libswscale/tests/swscale.c b/libswscale/tests/swscale.c
index 19878a7877..82eb135824 100644
--- a/libswscale/tests/swscale.c
+++ b/libswscale/tests/swscale.c
@@ -55,6 +55,35 @@
(x) == AV_PIX_FMT_RGB32_1 || \
(x) == AV_PIX_FMT_YUVA420P)
+static int sws_scale_test(struct SwsContext *c,
+ const uint8_t * const srcSlice[],
+ const int srcStride[], int srcSliceY,
+ int srcSliceH, uint8_t *const dst[],
+ const int dstStride[], int vsub1)
+{
+int h = srcSliceH;
+int y, i;
+static int t = 0;
+const uint8_t * src[4];
+t ++;
+y = FFALIGN(t, 4) % FFALIGN(h, 4);
+
+if (y && !srcSliceY && h == srcSliceH) {
+int ret = sws_scale(c, srcSlice, srcStride, 0, y, dst, dstStride);
+if (ret < 0)
+return ret;
+srcSliceY = y;
+srcSliceH -= y;
+
+for (i=0; i<4; i++) {
+int vsub= ((i+1)&2) ? vsub1 : 0;
+src[i] = srcSlice[i] + (y>>vsub) * srcStride[i];
+}
+srcSlice = src;
+}
+return sws_scale(c, srcSlice, srcStride, srcSliceY, srcSliceH, dst,
dstStride);
+}
+
static uint64_t getSSD(const uint8_t *src1, const uint8_t *src2,
int stride1, int stride2, int w, int h)
{
@@ -132,8 +161,8 @@ static int doTest(const uint8_t * const ref[4], int
refStride[4], int w, int h,
res = -1;
goto end;
}
-sws_scale(srcContext, ref, refStride, 0, h,
- (uint8_t * const *) src, srcStride);
+sws_scale_test(srcContext, ref, refStride, 0, h,
+ (uint8_t * const *) src, srcStride, 1);
sws_freeContext(srcContext);
cur_srcFormat = srcFormat;
@@ -180,7 +209,7 @@ static int doTest(const uint8_t * const ref[4], int
refStride[4], int w, int h,
flags);
fflush(stdout);
-sws_scale(dstContext, (const uint8_t * const*)src, srcStride, 0, srcH,
dst, dstStride);
+sws_scale_test(dstContext, (const uint8_t * const*)src, srcStride, 0,
srcH, dst, dstStride, desc_src->log2_chroma_h);
for (i = 0; i < 4 && dstStride[i]; i++)
crc = av_crc(av_crc_get_table(AV_CRC_32_IEEE), crc, dst[i],
@@ -212,8 +241,8 @@ static int doTest(const uint8_t * const ref[4], int
refStride[4], int w, int h,
res = -1;
goto end;
}
-sws_scale(outContext, (const uint8_t * const *) dst, dstStride, 0,
dstH,
- out, refStride);
+sws_scale_test(outContext, (const uint8_t * const *) dst, dstStride,
0, dstH,
+ out, refStride, desc_dst->log2_chroma_h);
ssdY = getSSD(ref[0], out[0], refStride[0], refStride[0], w, h);
if (hasChroma(srcFormat) && hasChroma(dstFormat)) {
@@ -422,7 +451,7 @@ bad_option:
for (y = 0; y < H; y++)
for (x = 0; x < W * 4; x++)
rgb_data[ x + y * 4 * W] = av_lfg_get();
-sws_scale(sws, rgb_src, rgb_stride, 0, H / 12, (uint8_t * const *) src,
stride);
+sws_scale_test(sws, rgb_src, rgb_stride, 0, H / 12, (uint8_t * const *)
src, stride, 0);
sws_freeContext(sws);
av_free(rgb_data);
--
2.17.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 1/2] swscale/yuv2rgb: Fix vertical dither offset with slices
Signed-off-by: Michael Niedermayer
---
libswscale/yuv2rgb.c | 43 ++-
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/libswscale/yuv2rgb.c b/libswscale/yuv2rgb.c
index d0df061e4d..588462504e 100644
--- a/libswscale/yuv2rgb.c
+++ b/libswscale/yuv2rgb.c
@@ -138,10 +138,11 @@ const int *sws_getCoefficients(int colorspace)
srcStride[2] *= 2; \
} \
for (y = 0; y < srcSliceH; y += 2) {\
+int yd = y + srcSliceY; \
dst_type *dst_1 = \
-(dst_type *)(dst[0] + (y + srcSliceY) * dstStride[0]); \
+(dst_type *)(dst[0] + (yd) * dstStride[0]); \
dst_type *dst_2 = \
-(dst_type *)(dst[0] + (y + srcSliceY + 1) * dstStride[0]); \
+(dst_type *)(dst[0] + (yd + 1) * dstStride[0]); \
dst_type av_unused *r, *g, *b; \
const uint8_t *py_1 = src[0] + y * srcStride[0]; \
const uint8_t *py_2 = py_1 +srcStride[0]; \
@@ -498,8 +499,8 @@ CLOSEYUV2RGBFUNC(8)
// r, g, b, dst_1, dst_2
YUV2RGBFUNC(yuv2rgb_c_8_ordered_dither, uint8_t, 0)
-const uint8_t *d32 = ff_dither_8x8_32[y & 7];
-const uint8_t *d64 = ff_dither_8x8_73[y & 7];
+const uint8_t *d32 = ff_dither_8x8_32[yd & 7];
+const uint8_t *d64 = ff_dither_8x8_73[yd & 7];
#define PUTRGB8(dst, src, i, o) \
Y = src[2 * i];\
@@ -528,8 +529,8 @@ YUV2RGBFUNC(yuv2rgb_c_8_ordered_dither, uint8_t, 0)
PUTRGB8(dst_1, py_1, 3, 6);
ENDYUV2RGBLINE(8, 0)
-const uint8_t *d32 = ff_dither_8x8_32[y & 7];
-const uint8_t *d64 = ff_dither_8x8_73[y & 7];
+const uint8_t *d32 = ff_dither_8x8_32[yd & 7];
+const uint8_t *d64 = ff_dither_8x8_73[yd & 7];
LOADCHROMA(0);
PUTRGB8(dst_1, py_1, 0, 0);
PUTRGB8(dst_2, py_2, 0, 0 + 8);
@@ -539,8 +540,8 @@ ENDYUV2RGBLINE(8, 0)
PUTRGB8(dst_1, py_1, 1, 2);
ENDYUV2RGBLINE(8, 1)
-const uint8_t *d32 = ff_dither_8x8_32[y & 7];
-const uint8_t *d64 = ff_dither_8x8_73[y & 7];
+const uint8_t *d32 = ff_dither_8x8_32[yd & 7];
+const uint8_t *d64 = ff_dither_8x8_73[yd & 7];
LOADCHROMA(0);
PUTRGB8(dst_1, py_1, 0, 0);
PUTRGB8(dst_2, py_2, 0, 0 + 8);
@@ -549,8 +550,8 @@ ENDYUV2RGBFUNC()
YUV2RGBFUNC(yuv2rgb_c_4_ordered_dither, uint8_t, 0)
-const uint8_t * d64 = ff_dither_8x8_73[y & 7];
-const uint8_t *d128 = ff_dither_8x8_220[y & 7];
+const uint8_t * d64 = ff_dither_8x8_73[yd & 7];
+const uint8_t *d128 = ff_dither_8x8_220[yd & 7];
int acc;
#define PUTRGB4D(dst, src, i, o)\
@@ -581,8 +582,8 @@ YUV2RGBFUNC(yuv2rgb_c_4_ordered_dither, uint8_t, 0)
PUTRGB4D(dst_1, py_1, 3, 6);
ENDYUV2RGBLINE(4, 0)
-const uint8_t * d64 = ff_dither_8x8_73[y & 7];
-const uint8_t *d128 = ff_dither_8x8_220[y & 7];
+const uint8_t * d64 = ff_dither_8x8_73[yd & 7];
+const uint8_t *d128 = ff_dither_8x8_220[yd & 7];
int acc;
LOADCHROMA(0);
PUTRGB4D(dst_1, py_1, 0, 0);
@@ -593,8 +594,8 @@ ENDYUV2RGBLINE(4, 0)
PUTRGB4D(dst_1, py_1, 1, 2);
ENDYUV2RGBLINE(4, 1)
-const uint8_t * d64 = ff_dither_8x8_73[y & 7];
-const uint8_t *d128 = ff_dither_8x8_220[y & 7];
+const uint8_t * d64 = ff_dither_8x8_73[yd & 7];
+const uint8_t *d128 = ff_dither_8x8_220[yd & 7];
int acc;
LOADCHROMA(0);
PUTRGB4D(dst_1, py_1, 0, 0);
@@ -602,8 +603,8 @@ ENDYUV2RGBLINE(4, 1)
ENDYUV2RGBFUNC()
YUV2RGBFUNC(yuv2rgb_c_4b_ordered_dither, uint8_t, 0)
-const uint8_t *d64 = ff_dither_8x8_73[y & 7];
-const uint8_t *d128 = ff_dither_8x8_220[y & 7];
+const uint8_t *d64 = ff_dither_8x8_73[yd & 7];
+const uint8_t *d128 = ff_dither_8x8_220[yd & 7];
#define PUTRGB4DB(dst, src, i, o) \
Y = src[2 * i];\
@@ -631,8 +632,8 @@ YUV2RGBFUNC(yuv2rgb_c_4b_ordered_dither, uint8_t, 0)
PUTRGB4DB(dst_2, py_2, 3, 6 + 8);
PUTRGB4DB(dst_1, py_1, 3, 6);
ENDYUV2RGBLINE(8, 0)
-const uint8_t *d64 = ff_dither_8x8_73[y & 7];
-const uint8_t *d128 = ff_dither_8x8_220[y & 7];
+const uint8_t *d64 = ff_dither_8x8_73[yd & 7];
+const uint8_t *d128 = ff_dither_8x8_220[yd & 7];
LOADCHROMA(0);
PUTRGB4DB(dst_1, py_1, 0, 0);
PUTRGB4DB(dst_2, py_2, 0, 0 + 8);
@@ -641,15 +642,15 @@ ENDYUV2RGBLINE(8, 0)
PUTRGB4DB(dst_2, py_2, 1, 2 + 8);
PUTRGB4DB(dst_1, py_1, 1, 2);
ENDYUV2RGBLINE(8, 1)
-const uint8_t *d64 = ff_dither_8x8_73[y & 7];
-const uint8_t *d128 = ff_dither_8x8_220[y & 7];
+const
Re: [FFmpeg-devel] [PATCH] lavc/vaapi_decode: fix the build failure when hevc_vaapi is disabled
Am Do., 2. Apr. 2020 um 04:21 Uhr schrieb Fu, Linjie :
>
> > From: ffmpeg-devel On Behalf Of
> > Carl Eugen Hoyos
> > Sent: Thursday, April 2, 2020 03:22
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_decode: fix the build failure
> > when hevc_vaapi is disabled
> >
> > Am Mi., 1. Apr. 2020 um 17:24 Uhr schrieb Linjie Fu :
> > >
> > > Verified with ./configure --enable-vaapi --disable-hwaccel=hevc_vaapi
> > >
> > > Failure reported in:
> > > http://fate.ffmpeg.org/report.cgi?time=20200401135031=x86_64-
> > archlinux-gcc-random
> > >
> > > Signed-off-by: Linjie Fu
> > > ---
> > > libavcodec/vaapi_decode.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> > > index 54a0ecb..06916cc 100644
> > > --- a/libavcodec/vaapi_decode.c
> > > +++ b/libavcodec/vaapi_decode.c
> > > @@ -383,6 +383,7 @@ static const struct {
> > > H264ConstrainedBaseline),
> > > MAP(H264,H264_MAIN, H264Main),
> > > MAP(H264,H264_HIGH, H264High),
> > > +#if CONFIG_HEVC_VAAPI_HWACCEL
> > > #if VA_CHECK_VERSION(0, 37, 0)
> >
> > Can these lines be joined?
> > Or am I missing something between the chunks?
>
> The complete code contains 2 different libva version checks for compatibility
> which didn't show up in the diff chunks:
>
> #if CONFIG_HEVC_VAAPI_HWACCEL
> #if VA_CHECK_VERSION(0, 37, 0)
> MAP(HEVC,HEVC_MAIN, HEVCMain),
> MAP(HEVC,HEVC_MAIN_10,HEVCMain10 ),
> MAP(HEVC,HEVC_MAIN_STILL_PICTURE,
> HEVCMain),
> #endif
> #if VA_CHECK_VERSION(1, 2, 0)
> MAP(HEVC,HEVC_REXT, None,
> ff_vaapi_parse_hevc_rext_profile ),
> #endif
> #endif
> hence I think maybe no need for a join?
Of course not, sorry for not taking the time to look myself.
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] Add support for playing Audible AAXC (.aaxc) files
Am Do., 2. Apr. 2020 um 07:39 Uhr schrieb Vesselin Bontchev : > +c->aes_decrypt = av_aes_alloc(); Don't you have to free this in the fail path? An alternative is to allocate this after the length check... If the alloc function returns NULL, you should return ENOMEM. 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] avformat/mpegts: use a buffer pool for PES payloads
On Thu, 2 Apr 2020, James Almer wrote:
On 4/2/2020 3:49 PM, Marton Balint wrote:
On Thu, 2 Apr 2020, James Almer wrote:
On 4/2/2020 3:27 PM, Marton Balint wrote:
On Thu, 2 Apr 2020, Marton Balint wrote:
On Thu, 2 Apr 2020, James Almer wrote:
On 3/29/2020 6:07 PM, James Almer wrote:
This produces a small speed up in demuxing
Signed-off-by: James Almer
---
libavformat/mpegts.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 7f56bacb2c..7746a524c4 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -157,6 +157,8 @@ struct MpegTSContext {
int resync_size;
int merge_pmt_versions;
+ AVBufferPool *pool;
+
/**/
/* private mpegts data */
/* scan context */
@@ -1177,8 +1179,7 @@ static int mpegts_push_data(MpegTSFilter
*filter,
pes->total_size = MAX_PES_PAYLOAD;
/* allocate pes buffer */
- pes->buffer = av_buffer_alloc(pes->total_size +
-
AV_INPUT_BUFFER_PADDING_SIZE);
+ pes->buffer = av_buffer_pool_get(ts->pool);
if (!pes->buffer)
return AVERROR(ENOMEM);
@@ -1351,8 +1352,7 @@ skip:
if (ret < 0)
return ret;
pes->total_size = MAX_PES_PAYLOAD;
- pes->buffer = av_buffer_alloc(pes->total_size +
-
AV_INPUT_BUFFER_PADDING_SIZE);
+ pes->buffer = av_buffer_pool_get(ts->pool);
if (!pes->buffer)
return AVERROR(ENOMEM);
ts->stop_parse = 1;
@@ -3032,6 +3032,10 @@ static int mpegts_read_header(AVFormatContext
*s)
ts->stream = s;
ts->auto_guess = 0;
+ ts->pool = av_buffer_pool_init(MAX_PES_PAYLOAD +
AV_INPUT_BUFFER_PADDING_SIZE, NULL);
+ if (!ts->pool)
+ return AVERROR(ENOMEM);
+
if (s->iformat == _mpegts_demuxer) {
/* normal demux */
@@ -3200,6 +3204,8 @@ static void mpegts_free(MpegTSContext *ts)
clear_programs(ts);
+ av_buffer_pool_uninit(>pool);
+
for (i = 0; i < NB_PID_MAX; i++)
if (ts->pids[i])
mpegts_close_filter(ts, ts->pids[i]);
@@ -3295,6 +3301,12 @@ MpegTSContext
*avpriv_mpegts_parse_open(AVFormatContext *s)
ts->stream = s;
ts->auto_guess = 1;
+ ts->pool = av_buffer_pool_init(MAX_PES_PAYLOAD +
AV_INPUT_BUFFER_PADDING_SIZE, NULL);
+ if (!ts->pool) {
+ av_free(ts);
+ return NULL;
+ }
+
mpegts_open_section_filter(ts, SDT_PID, sdt_cb, ts, 1);
mpegts_open_section_filter(ts, PAT_PID, pat_cb, ts, 1);
mpegts_open_section_filter(ts, EIT_PID, eit_cb, ts, 1);
Will apply soon if no one objects.
LGTM.
On second thought aint this going to waste too much memory on small
packets? If packets are queued somewhere it can make a huge difference
if every buffer is 200kb...
Does the speedup goes away if only unbound packets make use of the
buffer pool?
Thanks,
Marton
I tried these two LG 4k HDR sample videos, and the pool was never bigger
than 3 to 5 buffers for the entire demuxing process.
That is the case if there is no packet buffering, like in ffmpeg using a
single input. But in ffplay or a lot of other apps packets are
pre-buffered to remove the latency of the source media. An app could
have assumed that if it buffers 1 MB of packets it will not consume a
lot more than 1 MB of memory.
I'll bench again with your suggestion, but i don't think it will be a
problem even as is.
Maybe we should create log2(MAX_PACKET_SIZE) number of buffer pools
instead? In that case the memory wasted is at most 100%... Still not
very good, but a lot more acceptable.
I don't think that's possible, or worth trying. There's currently no way
to query the amount of buffers in a given pool, and definitely no way to
know what buffers will be returned to a pool once all their references
are freed, other than keeping track of them within the muxer.
I meant something like this:
required_size = pes->total_size + AV_INPUT_BUFFER_PADDING;
index = av_log2(requred_size);
if (!ts->pools[index]) {
pool_size = FFMIN(MAX_PES_PAYLOAD + AV_INPUT_BUFFER_PADDING, 2 << index);
ts->pools[index] = av_buffer_pool_init(pool_size);
}
pes->buffer = av_buffer_pool_get(ts->pool[index]);
I'll try limiting the usage of the pool to unbound packets only, but i
suspect it will not make much of a difference compared to no pool usage
at all.
Yeah, I expect this outcome as well.
Regards,
Marton
___
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]lavc/sbc: Remove bool usage
Am Do., 2. Apr. 2020 um 20:52 Uhr schrieb Nicolas George : > > Derek Buitenhuis (12020-04-02): > > Interesting... Altivec isn't standards compliant? TIL. > > What I read is Apple isn't standards compliant. I knew that. "Apple" as in the people who launched ppc64el Linux? Can we stop this? 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] avformat/mpegts: use a buffer pool for PES payloads
On 4/2/2020 3:49 PM, Marton Balint wrote:
>
>
> On Thu, 2 Apr 2020, James Almer wrote:
>
>> On 4/2/2020 3:27 PM, Marton Balint wrote:
>>>
>>>
>>> On Thu, 2 Apr 2020, Marton Balint wrote:
>>>
On Thu, 2 Apr 2020, James Almer wrote:
> On 3/29/2020 6:07 PM, James Almer wrote:
>> This produces a small speed up in demuxing
>>
>> Signed-off-by: James Almer
>> ---
>> libavformat/mpegts.c | 20
>> 1 file changed, 16 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
>> index 7f56bacb2c..7746a524c4 100644
>> --- a/libavformat/mpegts.c
>> +++ b/libavformat/mpegts.c
>> @@ -157,6 +157,8 @@ struct MpegTSContext {
>> int resync_size;
>> int merge_pmt_versions;
>>
>> + AVBufferPool *pool;
>> +
>> /**/
>> /* private mpegts data */
>> /* scan context */
>> @@ -1177,8 +1179,7 @@ static int mpegts_push_data(MpegTSFilter
>> *filter,
>> pes->total_size = MAX_PES_PAYLOAD;
>>
>> /* allocate pes buffer */
>> - pes->buffer = av_buffer_alloc(pes->total_size +
>> -
AV_INPUT_BUFFER_PADDING_SIZE);
>> + pes->buffer = av_buffer_pool_get(ts->pool);
>> if (!pes->buffer)
>> return AVERROR(ENOMEM);
>>
>> @@ -1351,8 +1352,7 @@ skip:
>> if (ret < 0)
>> return ret;
>> pes->total_size = MAX_PES_PAYLOAD;
>> - pes->buffer = av_buffer_alloc(pes->total_size +
>> -
AV_INPUT_BUFFER_PADDING_SIZE);
>> + pes->buffer = av_buffer_pool_get(ts->pool);
>> if (!pes->buffer)
>> return AVERROR(ENOMEM);
>> ts->stop_parse = 1;
>> @@ -3032,6 +3032,10 @@ static int mpegts_read_header(AVFormatContext
>> *s)
>> ts->stream = s;
>> ts->auto_guess = 0;
>>
>> + ts->pool = av_buffer_pool_init(MAX_PES_PAYLOAD +
AV_INPUT_BUFFER_PADDING_SIZE, NULL);
>> + if (!ts->pool)
>> + return AVERROR(ENOMEM);
>> +
>> if (s->iformat == _mpegts_demuxer) {
>> /* normal demux */
>>
>> @@ -3200,6 +3204,8 @@ static void mpegts_free(MpegTSContext *ts)
>>
>> clear_programs(ts);
>>
>> + av_buffer_pool_uninit(>pool);
>> +
>> for (i = 0; i < NB_PID_MAX; i++)
>> if (ts->pids[i])
>> mpegts_close_filter(ts, ts->pids[i]);
>> @@ -3295,6 +3301,12 @@ MpegTSContext
*avpriv_mpegts_parse_open(AVFormatContext *s)
>> ts->stream = s;
>> ts->auto_guess = 1;
>>
>> + ts->pool = av_buffer_pool_init(MAX_PES_PAYLOAD +
AV_INPUT_BUFFER_PADDING_SIZE, NULL);
>> + if (!ts->pool) {
>> + av_free(ts);
>> + return NULL;
>> + }
>> +
>> mpegts_open_section_filter(ts, SDT_PID, sdt_cb, ts, 1);
>> mpegts_open_section_filter(ts, PAT_PID, pat_cb, ts, 1);
>> mpegts_open_section_filter(ts, EIT_PID, eit_cb, ts, 1);
>
> Will apply soon if no one objects.
LGTM.
>>>
>>> On second thought aint this going to waste too much memory on small
>>> packets? If packets are queued somewhere it can make a huge difference
>>> if every buffer is 200kb...
>>>
>>> Does the speedup goes away if only unbound packets make use of the
>>> buffer pool?
>>>
>>> Thanks,
>>> Marton
>>
>> I tried these two LG 4k HDR sample videos, and the pool was never bigger
>> than 3 to 5 buffers for the entire demuxing process.
>
> That is the case if there is no packet buffering, like in ffmpeg using a
> single input. But in ffplay or a lot of other apps packets are
> pre-buffered to remove the latency of the source media. An app could
> have assumed that if it buffers 1 MB of packets it will not consume a
> lot more than 1 MB of memory.
>
>>
>> I'll bench again with your suggestion, but i don't think it will be a
>> problem even as is.
>
> Maybe we should create log2(MAX_PACKET_SIZE) number of buffer pools
> instead? In that case the memory wasted is at most 100%... Still not
> very good, but a lot more acceptable.
I don't think that's possible, or worth trying. There's currently no way
to query the amount of buffers in a given pool, and definitely no way to
know what buffers will be returned to a pool once all their references
are freed, other than keeping track of them within the muxer.
I'll try limiting the usage of the pool to unbound packets only, but i
suspect it will not make much of a difference compared to no pool usage
at all.
>
> Regards,
> Marton
> ___
> ffmpeg-devel mailing list
>
Re: [FFmpeg-devel] [PATCH]lavc/sbc: Remove bool usage
On 02/04/2020 19:52, Nicolas George wrote: > What I read is Apple isn't standards compliant. I knew that. > > This fix seems harmless enough. The fix in the linked archive? I agree. - Derek ___ 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]lavc/sbc: Remove bool usage
Derek Buitenhuis (12020-04-02): > Interesting... Altivec isn't standards compliant? TIL. What I read is Apple isn't standards compliant. I knew that. This fix seems harmless enough. 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] [PATCH]lavc/sbc: Remove bool usage
On 02/04/2020 19:23, Thierry Foucu wrote: > And here is the patch they used to fix it: > https://mails.dpdk.org/archives/dev/2018-August/110485.html Interesting... Altivec isn't standards compliant? TIL. - Derek ___ 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] avformat/mpegts: use a buffer pool for PES payloads
On Thu, 2 Apr 2020, James Almer wrote:
On 4/2/2020 3:27 PM, Marton Balint wrote:
On Thu, 2 Apr 2020, Marton Balint wrote:
On Thu, 2 Apr 2020, James Almer wrote:
On 3/29/2020 6:07 PM, James Almer wrote:
This produces a small speed up in demuxing
Signed-off-by: James Almer
---
libavformat/mpegts.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 7f56bacb2c..7746a524c4 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -157,6 +157,8 @@ struct MpegTSContext {
int resync_size;
int merge_pmt_versions;
+ AVBufferPool *pool;
+
/**/
/* private mpegts data */
/* scan context */
@@ -1177,8 +1179,7 @@ static int mpegts_push_data(MpegTSFilter *filter,
pes->total_size = MAX_PES_PAYLOAD;
/* allocate pes buffer */
- pes->buffer = av_buffer_alloc(pes->total_size +
-
AV_INPUT_BUFFER_PADDING_SIZE);
+ pes->buffer = av_buffer_pool_get(ts->pool);
if (!pes->buffer)
return AVERROR(ENOMEM);
@@ -1351,8 +1352,7 @@ skip:
if (ret < 0)
return ret;
pes->total_size = MAX_PES_PAYLOAD;
- pes->buffer = av_buffer_alloc(pes->total_size +
-
AV_INPUT_BUFFER_PADDING_SIZE);
+ pes->buffer = av_buffer_pool_get(ts->pool);
if (!pes->buffer)
return AVERROR(ENOMEM);
ts->stop_parse = 1;
@@ -3032,6 +3032,10 @@ static int mpegts_read_header(AVFormatContext
*s)
ts->stream = s;
ts->auto_guess = 0;
+ ts->pool = av_buffer_pool_init(MAX_PES_PAYLOAD +
AV_INPUT_BUFFER_PADDING_SIZE, NULL);
+ if (!ts->pool)
+ return AVERROR(ENOMEM);
+
if (s->iformat == _mpegts_demuxer) {
/* normal demux */
@@ -3200,6 +3204,8 @@ static void mpegts_free(MpegTSContext *ts)
clear_programs(ts);
+ av_buffer_pool_uninit(>pool);
+
for (i = 0; i < NB_PID_MAX; i++)
if (ts->pids[i])
mpegts_close_filter(ts, ts->pids[i]);
@@ -3295,6 +3301,12 @@ MpegTSContext
*avpriv_mpegts_parse_open(AVFormatContext *s)
ts->stream = s;
ts->auto_guess = 1;
+ ts->pool = av_buffer_pool_init(MAX_PES_PAYLOAD +
AV_INPUT_BUFFER_PADDING_SIZE, NULL);
+ if (!ts->pool) {
+ av_free(ts);
+ return NULL;
+ }
+
mpegts_open_section_filter(ts, SDT_PID, sdt_cb, ts, 1);
mpegts_open_section_filter(ts, PAT_PID, pat_cb, ts, 1);
mpegts_open_section_filter(ts, EIT_PID, eit_cb, ts, 1);
Will apply soon if no one objects.
LGTM.
On second thought aint this going to waste too much memory on small
packets? If packets are queued somewhere it can make a huge difference
if every buffer is 200kb...
Does the speedup goes away if only unbound packets make use of the
buffer pool?
Thanks,
Marton
I tried these two LG 4k HDR sample videos, and the pool was never bigger
than 3 to 5 buffers for the entire demuxing process.
That is the case if there is no packet buffering, like in ffmpeg using a
single input. But in ffplay or a lot of other apps packets are
pre-buffered to remove the latency of the source media. An app could have
assumed that if it buffers 1 MB of packets it will not consume a lot more
than 1 MB of memory.
I'll bench again with your suggestion, but i don't think it will be a
problem even as is.
Maybe we should create log2(MAX_PACKET_SIZE) number of buffer pools
instead? In that case the memory wasted is at most 100%... Still not very
good, but a lot more acceptable.
Regards,
Marton
___
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]lavc/sbc: Remove bool usage
On Thu, Apr 2, 2020 at 11:18 AM Thierry Foucu wrote: > > > On Thu, Apr 2, 2020 at 11:11 AM Derek Buitenhuis < > derek.buitenh...@gmail.com> wrote: > >> On 02/04/2020 17:47, Moritz Barsnick wrote: >> > I though this was the practical argument?: >> > >> > http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259430.html >> > http://trac.ffmpeg.org/ticket/8591 >> >> It isn't really clear to me what the actual problem is from the >> description - how is bool fundementally different on PPC? >> > > Seems other project have the same problem with PPC64EL > https://mails.dpdk.org/archives/dev/2018-August/110281.html > > but that was in 2018.. > And here is the patch they used to fix it: https://mails.dpdk.org/archives/dev/2018-August/110485.html > > >> >> (Sorry, I am not familiar with PPC...) >> >> - Derek >> ___ >> 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". > > > > -- > > Thierry Foucu > -- Thierry Foucu ___ 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] avformat/mpegts: use a buffer pool for PES payloads
On 4/2/2020 3:27 PM, Marton Balint wrote:
>
>
> On Thu, 2 Apr 2020, Marton Balint wrote:
>
>>
>>
>> On Thu, 2 Apr 2020, James Almer wrote:
>>
>>> On 3/29/2020 6:07 PM, James Almer wrote:
This produces a small speed up in demuxing
Signed-off-by: James Almer
---
libavformat/mpegts.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 7f56bacb2c..7746a524c4 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -157,6 +157,8 @@ struct MpegTSContext {
int resync_size;
int merge_pmt_versions;
+ AVBufferPool *pool;
+
/**/
/* private mpegts data */
/* scan context */
@@ -1177,8 +1179,7 @@ static int mpegts_push_data(MpegTSFilter *filter,
pes->total_size = MAX_PES_PAYLOAD;
/* allocate pes buffer */
- pes->buffer = av_buffer_alloc(pes->total_size +
-
>> AV_INPUT_BUFFER_PADDING_SIZE);
+ pes->buffer = av_buffer_pool_get(ts->pool);
if (!pes->buffer)
return AVERROR(ENOMEM);
@@ -1351,8 +1352,7 @@ skip:
if (ret < 0)
return ret;
pes->total_size = MAX_PES_PAYLOAD;
- pes->buffer = av_buffer_alloc(pes->total_size +
-
>> AV_INPUT_BUFFER_PADDING_SIZE);
+ pes->buffer = av_buffer_pool_get(ts->pool);
if (!pes->buffer)
return AVERROR(ENOMEM);
ts->stop_parse = 1;
@@ -3032,6 +3032,10 @@ static int mpegts_read_header(AVFormatContext
*s)
ts->stream = s;
ts->auto_guess = 0;
+ ts->pool = av_buffer_pool_init(MAX_PES_PAYLOAD +
>> AV_INPUT_BUFFER_PADDING_SIZE, NULL);
+ if (!ts->pool)
+ return AVERROR(ENOMEM);
+
if (s->iformat == _mpegts_demuxer) {
/* normal demux */
@@ -3200,6 +3204,8 @@ static void mpegts_free(MpegTSContext *ts)
clear_programs(ts);
+ av_buffer_pool_uninit(>pool);
+
for (i = 0; i < NB_PID_MAX; i++)
if (ts->pids[i])
mpegts_close_filter(ts, ts->pids[i]);
@@ -3295,6 +3301,12 @@ MpegTSContext
>> *avpriv_mpegts_parse_open(AVFormatContext *s)
ts->stream = s;
ts->auto_guess = 1;
+ ts->pool = av_buffer_pool_init(MAX_PES_PAYLOAD +
>> AV_INPUT_BUFFER_PADDING_SIZE, NULL);
+ if (!ts->pool) {
+ av_free(ts);
+ return NULL;
+ }
+
mpegts_open_section_filter(ts, SDT_PID, sdt_cb, ts, 1);
mpegts_open_section_filter(ts, PAT_PID, pat_cb, ts, 1);
mpegts_open_section_filter(ts, EIT_PID, eit_cb, ts, 1);
>>>
>>> Will apply soon if no one objects.
>>
>> LGTM.
>
> On second thought aint this going to waste too much memory on small
> packets? If packets are queued somewhere it can make a huge difference
> if every buffer is 200kb...
>
> Does the speedup goes away if only unbound packets make use of the
> buffer pool?
>
> Thanks,
> Marton
I tried these two LG 4k HDR sample videos, and the pool was never bigger
than 3 to 5 buffers for the entire demuxing process.
I'll bench again with your suggestion, but i don't think it will be a
problem even as is.
___
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] avformat/mpegts: use a buffer pool for PES payloads
On Thu, 2 Apr 2020, Marton Balint wrote:
On Thu, 2 Apr 2020, James Almer wrote:
On 3/29/2020 6:07 PM, James Almer wrote:
This produces a small speed up in demuxing
Signed-off-by: James Almer
---
libavformat/mpegts.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 7f56bacb2c..7746a524c4 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -157,6 +157,8 @@ struct MpegTSContext {
int resync_size;
int merge_pmt_versions;
+AVBufferPool *pool;
+
/**/
/* private mpegts data */
/* scan context */
@@ -1177,8 +1179,7 @@ static int mpegts_push_data(MpegTSFilter *filter,
pes->total_size = MAX_PES_PAYLOAD;
/* allocate pes buffer */
-pes->buffer = av_buffer_alloc(pes->total_size +
-
AV_INPUT_BUFFER_PADDING_SIZE);
+pes->buffer = av_buffer_pool_get(ts->pool);
if (!pes->buffer)
return AVERROR(ENOMEM);
@@ -1351,8 +1352,7 @@ skip:
if (ret < 0)
return ret;
pes->total_size = MAX_PES_PAYLOAD;
-pes->buffer = av_buffer_alloc(pes->total_size +
-
AV_INPUT_BUFFER_PADDING_SIZE);
+pes->buffer = av_buffer_pool_get(ts->pool);
if (!pes->buffer)
return AVERROR(ENOMEM);
ts->stop_parse = 1;
@@ -3032,6 +3032,10 @@ static int mpegts_read_header(AVFormatContext *s)
ts->stream = s;
ts->auto_guess = 0;
+ts->pool = av_buffer_pool_init(MAX_PES_PAYLOAD +
AV_INPUT_BUFFER_PADDING_SIZE, NULL);
+if (!ts->pool)
+return AVERROR(ENOMEM);
+
if (s->iformat == _mpegts_demuxer) {
/* normal demux */
@@ -3200,6 +3204,8 @@ static void mpegts_free(MpegTSContext *ts)
clear_programs(ts);
+av_buffer_pool_uninit(>pool);
+
for (i = 0; i < NB_PID_MAX; i++)
if (ts->pids[i])
mpegts_close_filter(ts, ts->pids[i]);
@@ -3295,6 +3301,12 @@ MpegTSContext
*avpriv_mpegts_parse_open(AVFormatContext *s)
ts->stream = s;
ts->auto_guess = 1;
+ts->pool = av_buffer_pool_init(MAX_PES_PAYLOAD +
AV_INPUT_BUFFER_PADDING_SIZE, NULL);
+if (!ts->pool) {
+av_free(ts);
+return NULL;
+}
+
mpegts_open_section_filter(ts, SDT_PID, sdt_cb, ts, 1);
mpegts_open_section_filter(ts, PAT_PID, pat_cb, ts, 1);
mpegts_open_section_filter(ts, EIT_PID, eit_cb, ts, 1);
Will apply soon if no one objects.
LGTM.
On second thought aint this going to waste too much memory on small
packets? If packets are queued somewhere it can make a huge difference if
every buffer is 200kb...
Does the speedup goes away if only unbound packets make use of the buffer
pool?
Thanks,
Marton
___
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]lavc/sbc: Remove bool usage
Am Do., 2. Apr. 2020 um 20:11 Uhr schrieb Derek Buitenhuis : > > On 02/04/2020 17:47, Moritz Barsnick wrote: > > I though this was the practical argument?: > > > > http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259430.html > > http://trac.ffmpeg.org/ticket/8591 > > It isn't really clear to me what the actual problem is from the > description - how is bool fundementally different on PPC? bool is defined as a vector on ppc altivec unless you tell the compiler not to (which most likely has other side-effects). But this is unrelated to the patch posted here. 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]lavc/sbc: Remove bool usage
On Thu, Apr 2, 2020 at 11:11 AM Derek Buitenhuis wrote: > On 02/04/2020 17:47, Moritz Barsnick wrote: > > I though this was the practical argument?: > > > > http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259430.html > > http://trac.ffmpeg.org/ticket/8591 > > It isn't really clear to me what the actual problem is from the > description - how is bool fundementally different on PPC? > Seems other project have the same problem with PPC64EL https://mails.dpdk.org/archives/dev/2018-August/110281.html but that was in 2018.. > > (Sorry, I am not familiar with PPC...) > > - Derek > ___ > 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". -- Thierry Foucu ___ 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] avformat/mpegts: use a buffer pool for PES payloads
On Thu, 2 Apr 2020, James Almer wrote:
On 3/29/2020 6:07 PM, James Almer wrote:
This produces a small speed up in demuxing
Signed-off-by: James Almer
---
libavformat/mpegts.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 7f56bacb2c..7746a524c4 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -157,6 +157,8 @@ struct MpegTSContext {
int resync_size;
int merge_pmt_versions;
+AVBufferPool *pool;
+
/**/
/* private mpegts data */
/* scan context */
@@ -1177,8 +1179,7 @@ static int mpegts_push_data(MpegTSFilter *filter,
pes->total_size = MAX_PES_PAYLOAD;
/* allocate pes buffer */
-pes->buffer = av_buffer_alloc(pes->total_size +
-
AV_INPUT_BUFFER_PADDING_SIZE);
+pes->buffer = av_buffer_pool_get(ts->pool);
if (!pes->buffer)
return AVERROR(ENOMEM);
@@ -1351,8 +1352,7 @@ skip:
if (ret < 0)
return ret;
pes->total_size = MAX_PES_PAYLOAD;
-pes->buffer = av_buffer_alloc(pes->total_size +
-
AV_INPUT_BUFFER_PADDING_SIZE);
+pes->buffer = av_buffer_pool_get(ts->pool);
if (!pes->buffer)
return AVERROR(ENOMEM);
ts->stop_parse = 1;
@@ -3032,6 +3032,10 @@ static int mpegts_read_header(AVFormatContext *s)
ts->stream = s;
ts->auto_guess = 0;
+ts->pool = av_buffer_pool_init(MAX_PES_PAYLOAD +
AV_INPUT_BUFFER_PADDING_SIZE, NULL);
+if (!ts->pool)
+return AVERROR(ENOMEM);
+
if (s->iformat == _mpegts_demuxer) {
/* normal demux */
@@ -3200,6 +3204,8 @@ static void mpegts_free(MpegTSContext *ts)
clear_programs(ts);
+av_buffer_pool_uninit(>pool);
+
for (i = 0; i < NB_PID_MAX; i++)
if (ts->pids[i])
mpegts_close_filter(ts, ts->pids[i]);
@@ -3295,6 +3301,12 @@ MpegTSContext *avpriv_mpegts_parse_open(AVFormatContext
*s)
ts->stream = s;
ts->auto_guess = 1;
+ts->pool = av_buffer_pool_init(MAX_PES_PAYLOAD +
AV_INPUT_BUFFER_PADDING_SIZE, NULL);
+if (!ts->pool) {
+av_free(ts);
+return NULL;
+}
+
mpegts_open_section_filter(ts, SDT_PID, sdt_cb, ts, 1);
mpegts_open_section_filter(ts, PAT_PID, pat_cb, ts, 1);
mpegts_open_section_filter(ts, EIT_PID, eit_cb, ts, 1);
Will apply soon if no one objects.
LGTM.
Thanks,
Marton
___
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]lavc/sbc: Remove bool usage
On 02/04/2020 17:47, Moritz Barsnick wrote: > I though this was the practical argument?: > > http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259430.html > http://trac.ffmpeg.org/ticket/8591 It isn't really clear to me what the actual problem is from the description - how is bool fundementally different on PPC? (Sorry, I am not familiar with PPC...) - Derek ___ 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/dss: Remove unnecessary allocation
Put a buffer with a known fixed size into the demuxer's context instead
of allocating it separately. This also allows to remove the demuxer's
read_close()-function.
Signed-off-by: Andreas Rheinhardt
---
libavformat/dss.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/libavformat/dss.c b/libavformat/dss.c
index ae7a259526..0585049130 100644
--- a/libavformat/dss.c
+++ b/libavformat/dss.c
@@ -50,7 +50,7 @@ typedef struct DSSDemuxContext {
int counter;
int swap;
int dss_sp_swap_byte;
-int8_t *dss_sp_buf;
+int8_t dss_sp_buf[DSS_FRAME_SIZE + 1];
int packet_size;
int dss_header_size;
@@ -168,10 +168,6 @@ static int dss_read_header(AVFormatContext *s)
ctx->counter = 0;
ctx->swap= 0;
-ctx->dss_sp_buf = av_malloc(DSS_FRAME_SIZE + 1);
-if (!ctx->dss_sp_buf)
-return AVERROR(ENOMEM);
-
return 0;
}
@@ -327,15 +323,6 @@ static int dss_read_packet(AVFormatContext *s, AVPacket
*pkt)
return dss_723_1_read_packet(s, pkt);
}
-static int dss_read_close(AVFormatContext *s)
-{
-DSSDemuxContext *ctx = s->priv_data;
-
-av_freep(>dss_sp_buf);
-
-return 0;
-}
-
static int dss_read_seek(AVFormatContext *s, int stream_index,
int64_t timestamp, int flags)
{
@@ -382,7 +369,6 @@ AVInputFormat ff_dss_demuxer = {
.read_probe = dss_probe,
.read_header= dss_read_header,
.read_packet= dss_read_packet,
-.read_close = dss_read_close,
.read_seek = dss_read_seek,
.extensions = "dss"
};
--
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] [PATCH 2/3] avformat/mpc: Simplify cleanup
Currently Musepack allocates an array that needs to be freed later in
the demuxer's read_close-function; it is the sole reason for said
function's existence. But it is unnecessary, because one can store this
array in the stream's priv_data pointer, so that it will be freed
generically.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mpc.c | 40
1 file changed, 16 insertions(+), 24 deletions(-)
diff --git a/libavformat/mpc.c b/libavformat/mpc.c
index 85036cd118..6a94b5d1d0 100644
--- a/libavformat/mpc.c
+++ b/libavformat/mpc.c
@@ -57,6 +57,7 @@ static int mpc_read_header(AVFormatContext *s)
{
MPCContext *c = s->priv_data;
AVStream *st;
+int ret;
if(avio_rl24(s->pb) != MKTAG('M', 'P', '+', 0)){
av_log(s, AV_LOG_ERROR, "Not a Musepack file\n");
@@ -72,15 +73,6 @@ static int mpc_read_header(AVFormatContext *s)
av_log(s, AV_LOG_ERROR, "Too many frames, seeking is not possible\n");
return AVERROR_INVALIDDATA;
}
-if(c->fcount){
-c->frames = av_malloc(c->fcount * sizeof(MPCFrame));
-if(!c->frames){
-av_log(s, AV_LOG_ERROR, "Cannot allocate seektable\n");
-return AVERROR(ENOMEM);
-}
-}else{
-av_log(s, AV_LOG_WARNING, "Container reports no frames\n");
-}
c->curframe = 0;
c->lastframe = -1;
c->curbits = 8;
@@ -88,15 +80,27 @@ static int mpc_read_header(AVFormatContext *s)
st = avformat_new_stream(s, NULL);
if (!st)
-goto mem_error;
+return AVERROR(ENOMEM);
+
+if (c->fcount) {
+c->frames = av_malloc(c->fcount * sizeof(MPCFrame));
+if (!c->frames) {
+av_log(s, AV_LOG_ERROR, "Cannot allocate seektable\n");
+return AVERROR(ENOMEM);
+}
+st->priv_data = c->frames;
+} else {
+av_log(s, AV_LOG_WARNING, "Container reports no frames\n");
+}
+
st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
st->codecpar->codec_id = AV_CODEC_ID_MUSEPACK7;
st->codecpar->channels = 2;
st->codecpar->channel_layout = AV_CH_LAYOUT_STEREO;
st->codecpar->bits_per_coded_sample = 16;
-if (ff_get_extradata(s, st->codecpar, s->pb, 16) < 0)
-goto mem_error;
+if ((ret = ff_get_extradata(s, st->codecpar, s->pb, 16)) < 0)
+return ret;
st->codecpar->sample_rate = mpc_rate[st->codecpar->extradata[2] & 3];
avpriv_set_pts_info(st, 32, MPC_FRAMESIZE, st->codecpar->sample_rate);
/* scan for seekpoints */
@@ -113,9 +117,6 @@ static int mpc_read_header(AVFormatContext *s)
}
return 0;
-mem_error:
-av_freep(>frames);
-return AVERROR(ENOMEM);
}
static int mpc_read_packet(AVFormatContext *s, AVPacket *pkt)
@@ -176,14 +177,6 @@ static int mpc_read_packet(AVFormatContext *s, AVPacket
*pkt)
return 0;
}
-static int mpc_read_close(AVFormatContext *s)
-{
-MPCContext *c = s->priv_data;
-
-av_freep(>frames);
-return 0;
-}
-
/**
* Seek to the given position
* If position is unknown but is within the limits of file
@@ -232,7 +225,6 @@ AVInputFormat ff_mpc_demuxer = {
.read_probe = mpc_probe,
.read_header= mpc_read_header,
.read_packet= mpc_read_packet,
-.read_close = mpc_read_close,
.read_seek = mpc_read_seek,
.extensions = "mpc",
};
--
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] avformat/mpegts: use a buffer pool for PES payloads
On 3/29/2020 6:07 PM, James Almer wrote:
> This produces a small speed up in demuxing
>
> Signed-off-by: James Almer
> ---
> libavformat/mpegts.c | 20
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index 7f56bacb2c..7746a524c4 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -157,6 +157,8 @@ struct MpegTSContext {
> int resync_size;
> int merge_pmt_versions;
>
> +AVBufferPool *pool;
> +
> /**/
> /* private mpegts data */
> /* scan context */
> @@ -1177,8 +1179,7 @@ static int mpegts_push_data(MpegTSFilter *filter,
> pes->total_size = MAX_PES_PAYLOAD;
>
> /* allocate pes buffer */
> -pes->buffer = av_buffer_alloc(pes->total_size +
> -
> AV_INPUT_BUFFER_PADDING_SIZE);
> +pes->buffer = av_buffer_pool_get(ts->pool);
> if (!pes->buffer)
> return AVERROR(ENOMEM);
>
> @@ -1351,8 +1352,7 @@ skip:
> if (ret < 0)
> return ret;
> pes->total_size = MAX_PES_PAYLOAD;
> -pes->buffer = av_buffer_alloc(pes->total_size +
> -
> AV_INPUT_BUFFER_PADDING_SIZE);
> +pes->buffer = av_buffer_pool_get(ts->pool);
> if (!pes->buffer)
> return AVERROR(ENOMEM);
> ts->stop_parse = 1;
> @@ -3032,6 +3032,10 @@ static int mpegts_read_header(AVFormatContext *s)
> ts->stream = s;
> ts->auto_guess = 0;
>
> +ts->pool = av_buffer_pool_init(MAX_PES_PAYLOAD +
> AV_INPUT_BUFFER_PADDING_SIZE, NULL);
> +if (!ts->pool)
> +return AVERROR(ENOMEM);
> +
> if (s->iformat == _mpegts_demuxer) {
> /* normal demux */
>
> @@ -3200,6 +3204,8 @@ static void mpegts_free(MpegTSContext *ts)
>
> clear_programs(ts);
>
> +av_buffer_pool_uninit(>pool);
> +
> for (i = 0; i < NB_PID_MAX; i++)
> if (ts->pids[i])
> mpegts_close_filter(ts, ts->pids[i]);
> @@ -3295,6 +3301,12 @@ MpegTSContext
> *avpriv_mpegts_parse_open(AVFormatContext *s)
> ts->stream = s;
> ts->auto_guess = 1;
>
> +ts->pool = av_buffer_pool_init(MAX_PES_PAYLOAD +
> AV_INPUT_BUFFER_PADDING_SIZE, NULL);
> +if (!ts->pool) {
> +av_free(ts);
> +return NULL;
> +}
> +
> mpegts_open_section_filter(ts, SDT_PID, sdt_cb, ts, 1);
> mpegts_open_section_filter(ts, PAT_PID, pat_cb, ts, 1);
> mpegts_open_section_filter(ts, EIT_PID, eit_cb, ts, 1);
Will apply soon if no one objects.
___
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] avformat/ilbc: Don't reimplement ff_raw_write_packet
Signed-off-by: Andreas Rheinhardt
---
libavformat/ilbc.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/libavformat/ilbc.c b/libavformat/ilbc.c
index d41027174d..c778f5a5af 100644
--- a/libavformat/ilbc.c
+++ b/libavformat/ilbc.c
@@ -21,6 +21,7 @@
#include "avformat.h"
#include "internal.h"
+#include "rawenc.h"
static const char mode20_header[] = "#!iLBC20\n";
static const char mode30_header[] = "#!iLBC30\n";
@@ -52,12 +53,6 @@ static int ilbc_write_header(AVFormatContext *s)
return 0;
}
-static int ilbc_write_packet(AVFormatContext *s, AVPacket *pkt)
-{
-avio_write(s->pb, pkt->data, pkt->size);
-return 0;
-}
-
static int ilbc_probe(const AVProbeData *p)
{
// Only check for "#!iLBC" which matches both formats
@@ -133,6 +128,6 @@ AVOutputFormat ff_ilbc_muxer = {
.extensions = "lbc",
.audio_codec = AV_CODEC_ID_ILBC,
.write_header = ilbc_write_header,
-.write_packet = ilbc_write_packet,
+.write_packet = ff_raw_write_packet,
.flags= AVFMT_NOTIMESTAMPS,
};
--
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]lavc/sbc: Remove bool usage
Am Do., 2. Apr. 2020 um 18:53 Uhr schrieb Moritz Barsnick : > > On Thu, Apr 02, 2020 at 15:33:02 +0200, Nicolas George wrote: > > If there are no actual practical arguments against bool, from either you > > or somebody else, then I suggest we leave this one as it is and no > > longer reject patches based on this. > > I though this was the practical argument?: > > http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259430.html > http://trac.ffmpeg.org/ticket/8591 The argument for my patch in this thread is only that when the sbc files were originally cleaned of bool, one occurrence was forgotten. 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]lavc/sbc: Remove bool usage
On Thu, Apr 02, 2020 at 15:33:02 +0200, Nicolas George wrote: > If there are no actual practical arguments against bool, from either you > or somebody else, then I suggest we leave this one as it is and no > longer reject patches based on this. I though this was the practical argument?: http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259430.html http://trac.ffmpeg.org/ticket/8591 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] [RFC] FFmpeg 4.3 release date?
On 4/2/20, Gyan Doshi wrote: > > When is 4.3 due? 4.2 was cut on 5th August 2019, almost 8 months ago. > When some things of uttermost importance are finished, polished and committed. > Regards, > Gyan > ___ > 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] [RFC] FFmpeg 4.3 release date?
When is 4.3 due? 4.2 was cut on 5th August 2019, almost 8 months ago. Regards, Gyan ___ 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]lavc/sbc: Remove bool usage
On 4/2/20, Nicolas George wrote: > Paul B Mahol (12020-04-02): >> No code in FFmpeg use it. >> And it was disallowed before and should be now. > > There are many features that were not used and have become used when the > need happened. Named initializers, for example. Compound literals. > > If there are no actual practical arguments against bool, from either you > or somebody else, then I suggest we leave this one as it is and no > longer reject patches based on this. > It is pointless discussion. I gonna commit this patch NOW. Certainly I will reject any patch with bool in any code that I maintain. > -- > Nicolas George > ___ > 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]lavc/sbc: Remove bool usage
On Thu, 2 Apr 2020 at 14:24, Paul B Mahol wrote: > On 4/2/20, Derek Buitenhuis wrote: > > On 02/04/2020 10:41, Paul B Mahol wrote: > >> I do not care, bool is evil and should never be used. > > > > Why? 'We don't like it' isn't a technical reason. > > > > Also, FFmpeg already uses plenty of C99 features and thus > > requires a C99 compiler. What is so inherently evil about a boolean > > type that it must not be allowed, but other C99 features are? > > > > I am curious what compilers support all the C99 features used that > > do not support stdbool.h, and are still actually used (even by 2 people). > > No code in FFmpeg use it. > And it was disallowed before and should be now. > https://en.wikipedia.org/wiki/Appeal_to_tradition Kieran ___ 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]lavc/sbc: Remove bool usage
On 02/04/2020 14:24, Paul B Mahol wrote: > No code in FFmpeg use it. > And it was disallowed before and should be now. 'Because we've always done it that way' is not a valid technical argument. - Derek ___ 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]lavc/sbc: Remove bool usage
Paul B Mahol (12020-04-02): > No code in FFmpeg use it. > And it was disallowed before and should be now. There are many features that were not used and have become used when the need happened. Named initializers, for example. Compound literals. If there are no actual practical arguments against bool, from either you or somebody else, then I suggest we leave this one as it is and no longer reject patches based on this. -- Nicolas George ___ 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]lavc/sbc: Remove bool usage
On 4/2/20, Derek Buitenhuis wrote: > On 02/04/2020 10:41, Paul B Mahol wrote: >> I do not care, bool is evil and should never be used. > > Why? 'We don't like it' isn't a technical reason. > > Also, FFmpeg already uses plenty of C99 features and thus > requires a C99 compiler. What is so inherently evil about a boolean > type that it must not be allowed, but other C99 features are? > > I am curious what compilers support all the C99 features used that > do not support stdbool.h, and are still actually used (even by 2 people). No code in FFmpeg use it. And it was disallowed before and should be now. > > - Derek > ___ > 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]lavc/sbc: Remove bool usage
On 02/04/2020 10:41, Paul B Mahol wrote: > I do not care, bool is evil and should never be used. Why? 'We don't like it' isn't a technical reason. Also, FFmpeg already uses plenty of C99 features and thus requires a C99 compiler. What is so inherently evil about a boolean type that it must not be allowed, but other C99 features are? I am curious what compilers support all the C99 features used that do not support stdbool.h, and are still actually used (even by 2 people). - Derek ___ 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]lavc/sbc: Remove bool usage
On 4/2/20, Kieran Kunhya wrote: > On Thu, 2 Apr 2020 at 08:53, Paul B Mahol wrote: > >> On 4/1/20, Thierry Foucu wrote: >> > On Wed, Apr 1, 2020 at 12:31 PM Carl Eugen Hoyos >> wrote: >> > >> >> Hi! >> >> >> >> It seems to me that this was forgotten when the codec was originally >> >> ported. >> >> >> > >> > why removing "stdbool.h"? >> > it was defined in 2001? so, most compiler should support it.. >> > Should we not check for the compiler support of it and if not, then >> either >> > reject the compiler or defines the type ourself? >> >> You are deeply wrong. >> > > What modern compiler does not support bool? > I do not care, bool is evil and should never be used. > Kieran > ___ > 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]lavc/sbc: Remove bool usage
On Thu, 2 Apr 2020 at 08:53, Paul B Mahol wrote: > On 4/1/20, Thierry Foucu wrote: > > On Wed, Apr 1, 2020 at 12:31 PM Carl Eugen Hoyos > wrote: > > > >> Hi! > >> > >> It seems to me that this was forgotten when the codec was originally > >> ported. > >> > > > > why removing "stdbool.h"? > > it was defined in 2001? so, most compiler should support it.. > > Should we not check for the compiler support of it and if not, then > either > > reject the compiler or defines the type ourself? > > You are deeply wrong. > What modern compiler does not support bool? Kieran ___ 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 03/14] pthread_frame: merge the functionality for normal decoder init and init_thread_copy
Quoting David Bryant (2020-04-01 23:35:13) > On 3/31/20 2:47 AM, Anton Khirnov wrote: > >>> Looking at wavpack, the code looks suspicious to me. You allocate one > >>> dsdctx per channel at init, but AFAIU the number of channels can change > >>> at each frame. > >>> > >> Multichannel WavPack consists of sequences of stereo or mono WavPack > >> blocks that include flags indicating whether they are the > >> beginning or end of a "frame" or "packet". This allows the number of > >> channels available to be essentially unlimited, however the > >> total number of channels in a stream may not change. When decoding, if a > >> sequence of blocks generates more or less than the > >> correct number of channels, this is flagged as an error and overrun is > >> prevented (see libavcodec/wavpack.c, line 1499 and line > >> 1621). > > If my reading of the code is correct, line 1499 only checks for overflow > > of the channel count read for the current sequence. That channel count > > is exported to AVCodeContext in the block starting on line 1464 and > > I don't see any checks for whether it is equal to the initial one. > > > Full disclosure: I did not write the WavPack decoder. I understand _how_ it > works, but I don't necessarily understand _why_ it > was written the way it was due to gaps in my knowledge of the FFmpeg > internals, and there are certainly things in there that > don't look quite right to me. > > That said, I have tested it thoroughly and it handles everything I throw at > it, and I have extended it to handle the DSD mode > without anything unexpected happening. And of course it seems to handle > extensive fuzzing, and the recent error was related to > my DSD change, suggesting that the core it pretty robust. My inclination has > been to not "fix" anything that wasn't broken. > > Yes, that channel count stuff is a little difficult to follow. I could > experiment with streams that abruptly change channel > configuration, but again I'm hesitant to change code that's worked so well so > long. I can easily get the decoder to crash even in single-threaded mode. Just make the demuxer always say the stream is mono, then try decoding your DSD sample. Also, I looked at the specification PDF you linked in the previous email and I see nothing in it that explicitly forbids the channel count from changing from one "superblock" to the next. It seems to me like you could just concatenate wavpack files with different channel counts and get a valid wavpack file. -- Anton Khirnov ___ 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]lavc/sbc: Remove bool usage
Am Mi., 1. Apr. 2020 um 23:23 Uhr schrieb Thierry Foucu : > > On Wed, Apr 1, 2020 at 12:31 PM Carl Eugen Hoyos wrote: > > > Hi! > > > > It seems to me that this was forgotten when the codec was originally > > ported. > > > > why removing "stdbool.h"? We never liked it (and I am sure there are examples of rejected patches), in this particular case, looking at the code, it was just an oversight when cleaning the code of bool. > it was defined in 2001? > so, most compiler should support it.. I hope you find the most important word in your sentence;-) > Should we not check for the compiler support of it and if not, then either > reject the compiler or defines the type ourself? It seems significantly easier to avoid 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".
Re: [FFmpeg-devel] [PATCH]lavc/sbc: Remove bool usage
On 4/1/20, Thierry Foucu wrote: > On Wed, Apr 1, 2020 at 12:31 PM Carl Eugen Hoyos wrote: > >> Hi! >> >> It seems to me that this was forgotten when the codec was originally >> ported. >> > > why removing "stdbool.h"? > it was defined in 2001? so, most compiler should support it.. > Should we not check for the compiler support of it and if not, then either > reject the compiler or defines the type ourself? You are deeply wrong. > > > >> >> Please comment, 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". > > > > -- > > Thierry Foucu > ___ > 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".
