Re: [FFmpeg-devel] PATCH to configure for openssl-1.1.0
On Thu, Sep 01, 2016 at 08:52:34PM -0600, Joseph Parmelee wrote: > > Greetings: > > I found that ffmpeg configure crashes with the new openssl-1.1.0. what do you mean by crash ? > This is > due to changes made in openssl-1.1.0 to both the header file ssl.h and to > the libraries libssl.so and libcrypto.so. The symbol SSL_library_init no > longer exists in either library; openssl changed its ABI ? > it has been replaced by OPENSSL_init_ssl in > libssl.so and is defined as a macro in ssl.h. Neither symbol exists in > libcrypto.so. > > The attached patch fixes the problem for me (building from source) but > further changes may be necessary for others as this patch only fixes the > first part of the OR. The ffmpeg build and install appear to work correctly > with this patch applied to the source on a 686 linux system. this patch makes the changed test fail as OPENSSL_init_ssl does not exist in previous openssl conftemp...c: In function 'check_OPENSSL_init_ssl': conftemp...c:2:51: error: 'OPENSSL_init_ssl' undeclared (first use in this function) conftemp...c:2:51: note: each undeclared identifier is reported only once for each function it appears in or said differently this effectively disables pkg-config with openssl prior to 1.1.0 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: don't include vdpau_compat.h when vdpau is not enabled
On Fri, Aug 05, 2016 at 11:24:35PM +0200, Carl Eugen Hoyos wrote: > Hi! > > 2016-08-04 16:01 GMT+02:00 James Almer : > >> So the advantage is that compilation gets measurably faster > >> with your patch? > > > > No, our headers are not the Boost package. i just want to reduce > > dependencies so they don't get recompiled every time you modify > > any of those 10+ unrelated headers or their dependencies. > > If you believe this helps, I can't object. whats the status of this ? is this droped ? does it need a review ? iam asking due to pachwork showing this as "NEW" without being delegated to anyone. Updating statuses in patchwork is important to keep patchwork effective as a way to keep track of patches ... (it cannot know if a patch was dropped or is still waiting on somethig) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] CNG (consistent noise generation) patch for AC-3 decoder
On 09/02/2016 05:35 PM, Michael Niedermayer wrote:
> On Fri, Sep 02, 2016 at 05:31:35PM -0700, Jonathan Campbell wrote:
>>> should be in a different patch
>>> also needs minor version bump and APIChanges update
>>>
>>> also please generate patches with git format-patch or git send-email
>>> see the respective man pages
>>> (otherwise they woul be lacking commit messages)
>>>
>>> thx
>>>
>>> [...]
>>>
>>>
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>> One patch for the new function in lfg.c, and another patch to use
>> the addition in the ac3 decoder, right? I can do that.
>
> yes
>
>
>>
>> The version minor bump would bring libavutil 55.30.100 (or should it
>> be 55.30.0?). I'll format the patch correctly.
>
> 55.30.100
>
> thx
>
> [...]
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Here you go (as attachments).
Jonathan Campbell
From 5de30d309fb48b26acd8d95f14ef4d4064450ddc Mon Sep 17 00:00:00 2001
From: Jonathan Campbell
Date: Sat, 3 Sep 2016 03:20:41 -0700
Subject: [PATCH 1/3] libavutil version bump, av_lfg_init_from_data() incoming
---
libavutil/version.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/version.h b/libavutil/version.h
index 7d32c7b..60b58eb 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 55
-#define LIBAVUTIL_VERSION_MINOR 29
+#define LIBAVUTIL_VERSION_MINOR 30
#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
--
2.2.2
From 3cc9a0e4a8bae127ca9254f31cd8b7f00d107395 Mon Sep 17 00:00:00 2001
From: Jonathan Campbell
Date: Sat, 3 Sep 2016 03:29:29 -0700
Subject: [PATCH 2/3] libavutil av_lfg_init_from_data() function
seeds an AVLFG from binary data.
---
libavutil/lfg.c | 27 +++
libavutil/lfg.h | 9 +
2 files changed, 36 insertions(+)
diff --git a/libavutil/lfg.c b/libavutil/lfg.c
index 08a4f67..0ef456a 100644
--- a/libavutil/lfg.c
+++ b/libavutil/lfg.c
@@ -23,7 +23,9 @@
#include
#include
#include "lfg.h"
+#include "crc.h"
#include "md5.h"
+#include "error.h"
#include "intreadwrite.h"
#include "attributes.h"
@@ -58,3 +60,28 @@ void av_bmg_get(AVLFG *lfg, double out[2])
out[0] = x1 * w;
out[1] = x2 * w;
}
+
+int av_lfg_init_from_data(AVLFG *c, const uint8_t *data, unsigned int length) {
+unsigned int beg, end, segm;
+const AVCRC *avcrc;
+uint32_t crc = 1;
+
+c->index = 0;
+avcrc = av_crc_get_table(AV_CRC_32_IEEE); /* This can't fail. It's a
well-defined table in crc.c */
+
+/* avoid integer overflow in the loop below. */
+if (length > (UINT_MAX / 128U)) return AVERROR(EINVAL);
+
+/* across 64 segments of the incoming data,
+ * do a running crc of each segment and store the crc as the state for
that slot.
+ * this works even if the length of the segment is 0 bytes. */
+beg = 0;
+for (segm = 0;segm < 64;segm++) {
+end = (((segm + 1) * length) / 64);
+crc = av_crc(avcrc, crc, data + beg, end - beg);
+c->state[segm] = (unsigned int)crc;
+beg = end;
+}
+
+return 0;
+}
diff --git a/libavutil/lfg.h b/libavutil/lfg.h
index ec90562..72eb673 100644
--- a/libavutil/lfg.h
+++ b/libavutil/lfg.h
@@ -22,6 +22,8 @@
#ifndef AVUTIL_LFG_H
#define AVUTIL_LFG_H
+#include /* uint8_t type */
+
typedef struct AVLFG {
unsigned int state[64];
int index;
@@ -29,6 +31,13 @@ typedef struct AVLFG {
void av_lfg_init(AVLFG *c, unsigned int seed);
+/*
+ * Seed the state of the ALFG using binary data.
+ *
+ * Return value: 0 on success, negative value (AVERROR) on failure.
+ */
+int av_lfg_init_from_data(AVLFG *c, const uint8_t *data, unsigned int length);
+
/**
* Get the next random unsigned 32-bit number using an ALFG.
*
--
2.2.2
From eb8b354c5edf9c876f3e4a209ec617500776fcf2 Mon Sep 17 00:00:00 2001
From: Jonathan Campbell
Date: Sat, 3 Sep 2016 03:34:01 -0700
Subject: [PATCH 3/3] ac3dec consistent noise generation option.
use av_lfg_init_from_data() to seed AC-3 dithering from the AC-3 frame
data to make it consistent given the same AC-3 frame, if option is set.
---
libavcodec/ac3dec.c | 7 +++
libavcodec/ac3dec.h | 4
libavcodec/ac3dec_fixed.c | 1 +
libavcodec/ac3dec_float.c | 1 +
4 files changed, 13 insertions(+)
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index fac189b..18a674b 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -1419,6 +1419,13 @@ static int ac3_decode_frame(AVCodecContext * avctx, void
*data,
(const uint16_t *) buf, cnt);
} else
memcpy(s->input_buffer, buf, FFMIN(buf_size, AC3_FRAME_BUFFER_SIZE));
+
+/* if consistent nois
Re: [FFmpeg-devel] CNG (consistent noise generation) patch for AC-3 decoder
Hi!
2016-09-03 12:50 GMT+02:00 Jonathan Campbell :
> Here you go (as attachments).
The changes to lfg and the version bump must be one patch.
> +{ "cons_noisegen", "enable consistent noise generation",
> OFFSET(consistent_noise_generation), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, PAR
> },
If this change makes sense why is it not the default?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/utils: print initial and trailing paddings only in verbose levels
2016-09-02 23:12 GMT+02:00 James Almer : > Ping for set. Both patches look very useful to me. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/mjpegdec: Do not skip reading quantization tables
Hi! 2016-09-02 22:53 GMT+02:00 Michael Niedermayer : > On Fri, Sep 02, 2016 at 05:14:10PM +0200, Carl Eugen Hoyos wrote: >> >> Attached patch fixes ticket #5819, I couldn't immediately find information >> if such quantization tables are valid. >> If ok, I'll also fix this in the jpeg auto-detection. > > they are valid > LGTM Patches applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] swscale: add unscaled conversion from yuv420p to p010
2016-09-03 0:06 GMT+02:00 Timo Rothenpieler : > On 9/2/2016 7:16 PM, Carl Eugen Hoyos wrote: >> 2016-09-02 16:36 GMT+02:00 Timo Rothenpieler : >> >>> +#if AV_HAVE_BIGENDIAN >>> +static int planar8ToP010leWrapper(SwsContext *c, const uint8_t *src[], >> >> Why does this function not work on both big and little endian hardware? > > It does, but it's significantly slower. > In my tests, it takes double the time than the pure native one. Do you know why exactly it is slower? If performance matters, this likely can be SIMD-optimized, no reason to duplicate the function. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] swscale: add unscaled conversion from yuv420p to p010
Hi! 2016-09-02 16:36 GMT+02:00 Timo Rothenpieler : > +AV_WL16(&dstUV[2*x ], (t | (t << 8)) & 0xFFC0); Why is "& 0xFFC0" necessary? (Same below.) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/httpauth: Do case-insensitive http header checks.
2016-09-02 4:07 GMT+02:00 Michael Niedermayer : >> Subject: [PATCH] lavf/httpauth: Do case-insensitive http header checks. >> >> Fixes ticket #5786. > > LGTM Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavfi/decimate: Do not assume a scene change for the first frame
2016-08-31 17:35 GMT+02:00 Carl Eugen Hoyos : > > Attached patch fixes ticket #4990 concerning the output file. > It is possible that there is nothing to fix though, the input > file is "dirty" and "dupthresh" is not underbid by two visually > identical frames. Please ignore, the patch (that I had already had dismissed myself months ago) is wrong. The question is still why the user claims his sample is correctly processed by the original filter and output is different with FFmpeg's implementation. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/mjpegdec: Only read JFIF thumbnail size if the segment is long enough.
2016-08-29 12:59 GMT+02:00 Michael Niedermayer : > On Mon, Aug 29, 2016 at 12:12:34AM +0200, Carl Eugen Hoyos wrote: >> Fixes ticket #5805. > > LGTM, Patch applied. > can you add a fate test for this ? Please upload the sample to fate-suite/jpg/. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf(webm_chunk: Print an error if no header filename was provided.
2016-08-03 18:42 GMT+02:00 Carl Eugen Hoyos : > > Attached patch gives users (and testers) a chance to know why > webm_chunk muxing fails. Patch applied, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] swscale: add unscaled conversion from yuv420p to p010
On 9/3/2016 1:47 PM, Carl Eugen Hoyos wrote: > 2016-09-03 0:06 GMT+02:00 Timo Rothenpieler : >> On 9/2/2016 7:16 PM, Carl Eugen Hoyos wrote: >>> 2016-09-02 16:36 GMT+02:00 Timo Rothenpieler : >>> +#if AV_HAVE_BIGENDIAN +static int planar8ToP010leWrapper(SwsContext *c, const uint8_t *src[], >>> >>> Why does this function not work on both big and little endian hardware? >> >> It does, but it's significantly slower. >> In my tests, it takes double the time than the pure native one. > > Do you know why exactly it is slower? > > If performance matters, this likely can be SIMD-optimized, no reason to > duplicate the function. No idea, but it was hinted that the AV_WL macros do some thing to assure it works on systems with strict alignment requirements. And it's slow enough to be no longer capable of processing in real time, while the other implementation easily handles 100+ fps. I have another idea how to reduce the overhead of having two versions. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] swscale: add unscaled conversion from yuv420p to p010
On 9/3/2016 1:46 PM, Carl Eugen Hoyos wrote: > Hi! > > 2016-09-02 16:36 GMT+02:00 Timo Rothenpieler : > >> +AV_WL16(&dstUV[2*x ], (t | (t << 8)) & 0xFFC0); > > Why is "& 0xFFC0" necessary? > (Same below.) Because P010 expects the 10 bits in the 10 most significant bit. I'm not 100% sure if the other 6 bits are undefined or 0, but all the other implementations treat them as zeroes. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] swscale: add unscaled conversion from yuv420p to p010
2016-09-03 14:54 GMT+02:00 Timo Rothenpieler : >>> +AV_WL16(&dstUV[2*x ], (t | (t << 8)) & 0xFFC0); >> >> Why is "& 0xFFC0" necessary? >> (Same below.) > > Because P010 expects the 10 bits in the 10 most significant bit. > I'm not 100% sure if the other 6 bits are undefined or 0, but all the > other implementations treat them as zeroes. I suggest to remove this. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] swscale: add unscaled conversion from yuv420p to p010
On 9/3/2016 3:15 PM, Carl Eugen Hoyos wrote: > 2016-09-03 14:54 GMT+02:00 Timo Rothenpieler : > +AV_WL16(&dstUV[2*x ], (t | (t << 8)) & 0xFFC0); >>> >>> Why is "& 0xFFC0" necessary? >>> (Same below.) >> >> Because P010 expects the 10 bits in the 10 most significant bit. >> I'm not 100% sure if the other 6 bits are undefined or 0, but all the >> other implementations treat them as zeroes. > > I suggest to remove this. At least https://technet.microsoft.com/pt-br/library/bb970578.aspx describes the lower 6 bits as set to 0, so leaving them in an undefined state might have unintended sideeffects. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] swscale: add unscaled conversion from yuv420p to p010
2016-09-03 15:18 GMT+02:00 Timo Rothenpieler : > On 9/3/2016 3:15 PM, Carl Eugen Hoyos wrote: >> 2016-09-03 14:54 GMT+02:00 Timo Rothenpieler : >> > +AV_WL16(&dstUV[2*x ], (t | (t << 8)) & 0xFFC0); Why is "& 0xFFC0" necessary? (Same below.) >>> >>> Because P010 expects the 10 bits in the 10 most significant bit. >>> I'm not 100% sure if the other 6 bits are undefined or 0, but all the >>> other implementations treat them as zeroes. >> >> I suggest to remove this. > > At least https://technet.microsoft.com/pt-br/library/bb970578.aspx > describes the lower 6 bits as set to 0 And the very next sentence explicitely contradicts. > so leaving them in an undefined > state might have unintended sideeffects. That is more than unlikely. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/udp: Do not use MCAST_* for multicast on tvOS
2016-08-16 17:53 GMT+02:00 Carl Eugen Hoyos : > Attached patch fixes ticket #5774. Patch applied. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] swscale: add unscaled conversion from yuv420p to p010
---
libswscale/swscale_unscaled.c| 57
tests/ref/fate/filter-pixdesc-p010le | 2 +-
tests/ref/fate/filter-pixfmts-copy | 2 +-
tests/ref/fate/filter-pixfmts-crop | 2 +-
tests/ref/fate/filter-pixfmts-field | 2 +-
tests/ref/fate/filter-pixfmts-hflip | 2 +-
tests/ref/fate/filter-pixfmts-il | 2 +-
tests/ref/fate/filter-pixfmts-null | 2 +-
tests/ref/fate/filter-pixfmts-scale | 2 +-
tests/ref/fate/filter-pixfmts-vflip | 2 +-
10 files changed, 66 insertions(+), 9 deletions(-)
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index ca7374a..cca2302 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -33,6 +33,7 @@
#include "libavutil/bswap.h"
#include "libavutil/pixdesc.h"
#include "libavutil/avassert.h"
+#include "libavutil/avconfig.h"
DECLARE_ALIGNED(8, static const uint8_t, dithers)[8][8][8]={
{
@@ -236,6 +237,57 @@ static int planarToP010Wrapper(SwsContext *c, const
uint8_t *src8[],
return srcSliceH;
}
+#if AV_HAVE_BIGENDIAN || 1
+#define output_pixel(p, v) do { \
+uint16_t *pp = (p); \
+AV_WL16(pp, (v)); \
+} while(0)
+#else
+#define output_pixel(p, v) (*p) = (v)
+#endif
+
+static int planar8ToP010leWrapper(SwsContext *c, const uint8_t *src[],
+ int srcStride[], int srcSliceY,
+ int srcSliceH, uint8_t *dstParam8[],
+ int dstStride[])
+{
+uint16_t *dstY = (uint16_t*)(dstParam8[0] + dstStride[0] * srcSliceY);
+uint16_t *dstUV = (uint16_t*)(dstParam8[1] + dstStride[1] * srcSliceY / 2);
+int x, y, t;
+
+av_assert0(!(dstStride[0] % 2 || dstStride[1] % 2));
+
+for (y = 0; y < srcSliceH; y++) {
+uint16_t *tdstY = dstY;
+const uint8_t *tsrc0 = src[0];
+for (x = c->srcW; x > 0; x--) {
+t = *tsrc0++;
+output_pixel(tdstY++, (t | (t << 8)) & 0xFFC0);
+}
+src[0] += srcStride[0];
+dstY += dstStride[0] / 2;
+
+if (!(y & 1)) {
+uint16_t *tdstUV = dstUV;
+const uint8_t *tsrc1 = src[1];
+const uint8_t *tsrc2 = src[2];
+for (x = c->srcW / 2; x > 0; x--) {
+t = *tsrc1++;
+output_pixel(tdstUV++, (t | (t << 8)) & 0xFFC0);
+t = *tsrc2++;
+output_pixel(tdstUV++, (t | (t << 8)) & 0xFFC0);
+}
+src[1] += srcStride[1];
+src[2] += srcStride[2];
+dstUV += dstStride[1] / 2;
+}
+}
+
+return srcSliceH;
+}
+
+#undef output_pixel
+
static int planarToYuy2Wrapper(SwsContext *c, const uint8_t *src[],
int srcStride[], int srcSliceY, int srcSliceH,
uint8_t *dstParam[], int dstStride[])
@@ -1645,6 +1697,11 @@ void ff_get_unscaled_swscale(SwsContext *c)
dstFormat == AV_PIX_FMT_P010) {
c->swscale = planarToP010Wrapper;
}
+/* yuv420p_to_p010le */
+if ((srcFormat == AV_PIX_FMT_YUV420P || srcFormat == AV_PIX_FMT_YUVA420P)
&&
+dstFormat == AV_PIX_FMT_P010LE) {
+c->swscale = planar8ToP010leWrapper;
+}
if (srcFormat == AV_PIX_FMT_YUV410P && !(dstH & 3) &&
(dstFormat == AV_PIX_FMT_YUV420P || dstFormat == AV_PIX_FMT_YUVA420P)
&&
diff --git a/tests/ref/fate/filter-pixdesc-p010le
b/tests/ref/fate/filter-pixdesc-p010le
index cac2635..2500604 100644
--- a/tests/ref/fate/filter-pixdesc-p010le
+++ b/tests/ref/fate/filter-pixdesc-p010le
@@ -1 +1 @@
-pixdesc-p010le 0268fd44f63022e21ada69704534fc85
+pixdesc-p010le 7b4a503997eb4e14cba80ee52db85e39
diff --git a/tests/ref/fate/filter-pixfmts-copy
b/tests/ref/fate/filter-pixfmts-copy
index ce957f7..bcc4475 100644
--- a/tests/ref/fate/filter-pixfmts-copy
+++ b/tests/ref/fate/filter-pixfmts-copy
@@ -36,7 +36,7 @@ monow 54d16d2c01abfd72ecdb5e51e283937c
nv128e24feb2c544dc26a20047a71e4c27aa
nv21335d85c9af6110f26ae9e187a82ed2cf
p010be 7f9842d6015026136bad60d03c035cc3
-p010le 1929db89609c4b8c6d9c9030a9e7843d
+p010le 9ba7bc4611e36b2435eb2dff353b8af5
pal8ff5929f5b42075793b2c34cb441bede5
rgb00de71e5a1f97f81fb51397a0435bfa72
rgb24 f4438057d046e6d98ade4e45294b21be
diff --git a/tests/ref/fate/filter-pixfmts-crop
b/tests/ref/fate/filter-pixfmts-crop
index e2c77a8..51c6df9 100644
--- a/tests/ref/fate/filter-pixfmts-crop
+++ b/tests/ref/fate/filter-pixfmts-crop
@@ -34,7 +34,7 @@ gray16le9ff7c866bd98def4e6c91542c1c45f80
nv1292cda427f794374731ec0321ee00caac
nv211bcfc197f4fb95de85ba58182d8d2f69
p010be 8b2de2eb6b099bbf355bfc55a0694ddc
-p010le a1e4f713e145dfc465bfe0cc77096a03
+p010le fa78436272020be0d2569139808429b6
pal81f2cdc8e7
Re: [FFmpeg-devel] [PATCH v2] swscale: add unscaled conversion from yuv420p to p010
> @@ -236,6 +237,57 @@ static int planarToP010Wrapper(SwsContext *c, const > uint8_t *src8[], > return srcSliceH; > } > > +#if AV_HAVE_BIGENDIAN || 1 Nevermind the || 1, left over from testing speed differences and forgot to remove it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv3] vf_colorspace: Allow overriding input color properties
The filter needs input frames with color properties filled out by
the decoder. Since this is not always possible, add input options to
the filter so that user may override color space, color primaries,
transfer characteristics, and color range, as well as a generic option
to set all properties at once.
Signed-off-by: Vittorio Giovara
---
Options moved at the bottom of the list as requested.
Vittorio
doc/filters.texi| 20
libavfilter/vf_colorspace.c | 40 +++-
2 files changed, 55 insertions(+), 5 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index c12b093..00ec1ea 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -5235,6 +5235,7 @@ Convert colorspace, transfer characteristics or color
primaries.
The filter accepts the following options:
@table @option
+@anchor{all}
@item all
Specify all color properties at once.
@@ -5266,6 +5267,7 @@ BT.2020
@end table
+@anchor{space}
@item space
Specify output colorspace.
@@ -5291,6 +5293,7 @@ BT.2020 with non-constant luminance
@end table
+@anchor{trc}
@item trc
Specify output transfer characteristics.
@@ -5319,6 +5322,7 @@ BT.2020 for 12-bits content
@end table
+@anchor{primaries}
@item primaries
Specify output color primaries.
@@ -5344,6 +5348,7 @@ BT.2020
@end table
+@anchor{range}
@item range
Specify output color range.
@@ -5423,6 +5428,21 @@ von Kries whitepoint adaptation
identity whitepoint adaptation (i.e. no whitepoint adaptation)
@end table
+@item iall
+Override all input properties at once. Same accepted values as @ref{all}.
+
+@item ispace
+Override input colorspace. Same accepted values as @ref{space}.
+
+@item iprimaries
+Override input color primaries. Same accepted values as @ref{primaries}.
+
+@item itrc
+Override input transfer characteristics. Same accepted values as @ref{trc}.
+
+@item irange
+Override input color range. Same accepted values as @ref{range}.
+
@end table
The filter converts the transfer characteristics, color space and color
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index e4022f8..45fd917 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -128,11 +128,11 @@ typedef struct ColorSpaceContext {
ColorSpaceDSPContext dsp;
-enum Colorspace user_all;
-enum AVColorSpace in_csp, out_csp, user_csp;
-enum AVColorRange in_rng, out_rng, user_rng;
-enum AVColorTransferCharacteristic in_trc, out_trc, user_trc;
-enum AVColorPrimaries in_prm, out_prm, user_prm;
+enum Colorspace user_all, user_iall;
+enum AVColorSpace in_csp, out_csp, user_csp, user_icsp;
+enum AVColorRange in_rng, out_rng, user_rng, user_irng;
+enum AVColorTransferCharacteristic in_trc, out_trc, user_trc, user_itrc;
+enum AVColorPrimaries in_prm, out_prm, user_prm, user_iprm;
enum AVPixelFormat in_format, user_format;
int fast_mode;
enum DitherMode dither;
@@ -581,6 +581,10 @@ static int create_filtergraph(AVFilterContext *ctx,
if (!s->out_primaries || !s->in_primaries) {
s->in_prm = in->color_primaries;
+if (s->user_iall != CS_UNSPECIFIED)
+s->in_prm = default_prm[FFMIN(s->user_iall, CS_NB)];
+if (s->user_iprm != AVCOL_PRI_UNSPECIFIED)
+s->in_prm = s->user_iprm;
s->in_primaries = get_color_primaries(s->in_prm);
if (!s->in_primaries) {
av_log(ctx, AV_LOG_ERROR,
@@ -638,6 +642,10 @@ static int create_filtergraph(AVFilterContext *ctx,
if (!s->in_txchr) {
av_freep(&s->lin_lut);
s->in_trc = in->color_trc;
+if (s->user_iall != CS_UNSPECIFIED)
+s->in_trc = default_trc[FFMIN(s->user_iall, CS_NB)];
+if (s->user_itrc != AVCOL_TRC_UNSPECIFIED)
+s->in_trc = s->user_itrc;
s->in_txchr = get_transfer_characteristics(s->in_trc);
if (!s->in_txchr) {
av_log(ctx, AV_LOG_ERROR,
@@ -680,7 +688,13 @@ static int create_filtergraph(AVFilterContext *ctx,
if (!s->in_lumacoef) {
s->in_csp = in->colorspace;
+if (s->user_iall != CS_UNSPECIFIED)
+s->in_csp = default_csp[FFMIN(s->user_iall, CS_NB)];
+if (s->user_icsp != AVCOL_SPC_UNSPECIFIED)
+s->in_csp = s->user_icsp;
s->in_rng = in->color_range;
+if (s->user_irng != AVCOL_RANGE_UNSPECIFIED)
+s->in_rng = s->user_irng;
s->in_lumacoef = get_luma_coefficients(s->in_csp);
if (!s->in_lumacoef) {
av_log(ctx, AV_LOG_ERROR,
@@ -1078,6 +1092,22 @@ static const AVOption colorspace_options[] = {
ENUM("vonkries", WP_ADAPT_VON_KRIES, "wpadapt"),
ENUM("identity", WP_ADAPT_IDENTITY, "wpadapt"),
+{ "iall", "Set all input color properties together",
+ OFFSET(user_iall), AV_OPT_TYPE_INT, { .i64 = CS_UNSPECIFIED },
+ CS_UNSPECIFIED, CS_NB - 1, FLAGS, "all" },
+{ "ispace", "Input colorspa
Re: [FFmpeg-devel] CNG (consistent noise generation) patch for AC-3 decoder
On 9/3/2016 8:09 AM, Carl Eugen Hoyos wrote: > The changes to lfg and the version bump must be one patch. They will be squashed. See https://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/198446.html https://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/198448.html https://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/198449.html ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] CNG (consistent noise generation) patch for AC-3 decoder
On 9/3/2016 7:50 AM, Jonathan Campbell wrote:
> +int av_lfg_init_from_data(AVLFG *c, const uint8_t *data, unsigned int
> length) {
> +unsigned int beg, end, segm;
> +const AVCRC *avcrc;
> +uint32_t crc = 1;
> +
> +c->index = 0;
The AVLFG struct should IMO remain untouched if init is guaranteed to fail,
as it would be the case with an out or range length value, so move this after
that check.
> +avcrc = av_crc_get_table(AV_CRC_32_IEEE); /* This can't fail. It's a
> well-defined table in crc.c */
You could also move this one below.
> +
> +/* avoid integer overflow in the loop below. */
> +if (length > (UINT_MAX / 128U)) return AVERROR(EINVAL);
> +
> +/* across 64 segments of the incoming data,
> + * do a running crc of each segment and store the crc as the state for
> that slot.
> + * this works even if the length of the segment is 0 bytes. */
> +beg = 0;
> +for (segm = 0;segm < 64;segm++) {
> +end = (((segm + 1) * length) / 64);
> +crc = av_crc(avcrc, crc, data + beg, end - beg);
The thing about speed made me wonder, wouldn't using adler32 be faster?
If so, this feature could maybe even be enabled by default with it.
> +c->state[segm] = (unsigned int)crc;
> +beg = end;
> +}
> +
> +return 0;
> +}
> diff --git a/libavutil/lfg.h b/libavutil/lfg.h
> index ec90562..72eb673 100644
> --- a/libavutil/lfg.h
> +++ b/libavutil/lfg.h
> @@ -22,6 +22,8 @@
> #ifndef AVUTIL_LFG_H
> #define AVUTIL_LFG_H
>
> +#include /* uint8_t type */
> +
> typedef struct AVLFG {
> unsigned int state[64];
> int index;
> @@ -29,6 +31,13 @@ typedef struct AVLFG {
>
> void av_lfg_init(AVLFG *c, unsigned int seed);
>
> +/*
This is meant for doxygen, so /** like in every other function.
> + * Seed the state of the ALFG using binary data.
> + *
> + * Return value: 0 on success, negative value (AVERROR) on failure.
> + */
> +int av_lfg_init_from_data(AVLFG *c, const uint8_t *data, unsigned int
> length);
> +
> /**
> * Get the next random unsigned 32-bit number using an ALFG.
> *
No more comments for me.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/utils: print initial and trailing paddings only in verbose levels
On 9/3/2016 8:24 AM, Carl Eugen Hoyos wrote: > 2016-09-02 23:12 GMT+02:00 James Almer : > >> Ping for set. > > Both patches look very useful to me. > > Carl Eugen Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] CNG (consistent noise generation) patch for AC-3 decoder
On 09/03/2016 04:09 AM, Carl Eugen Hoyos wrote:
> Hi!
>
> 2016-09-03 12:50 GMT+02:00 Jonathan Campbell :
>
>> Here you go (as attachments).
>
> The changes to lfg and the version bump must be one patch.
>
>> +{ "cons_noisegen", "enable consistent noise generation",
>> OFFSET(consistent_noise_generation), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1,
>> PAR },
>
> If this change makes sense why is it not the default?
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
The option is intended for non-linear editing software that needs to be able to
decode AC-3 from any arbitrary point in the stream. Making the dithering noise
consistent means the AC-3 decoder will produce the same audio samples on output
no matter where you begin decoding or how many frames you've decoded.
If the dithering noise is allowed to vary, then decoding from point A to B,
freeing the decoder context, then later allocating a context and resuming
decode from point B to C, will produce a slight discontinuity at point B where
the decoded audio is put together because the dithering noise applied to some
frequency bands came out differently between the two decodes. If the noise is
made consistent, then the decoded audio at point B will come out the exact same
as if you had decoded continuously from point A to C.
But, if you just want to play a media file and you don't care about that
consistency, then the CPU work to ensure a consistent decode like that is a
waste of effort. Playing, streaming and transcoding sequentially is probably 99
percent of FFMPEG's general use, right?
I'm well aware the AC-3 decoder has a window delay in the frequency domain.
Decoding from point B to C actually means going to point B, stepping back 1 to
2 AC-3 frames, decoding up to B and discarding the audio, then taking decoded
audio from point B on.
Do you understand now why this is useful for NLE software, but should not be
enabled by default?
Jonathan Campbell
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/mjpegdec: Only read JFIF thumbnail size if the segment is long enough.
On Sat, Sep 03, 2016 at 02:26:36PM +0200, Carl Eugen Hoyos wrote: > 2016-08-29 12:59 GMT+02:00 Michael Niedermayer : > > On Mon, Aug 29, 2016 at 12:12:34AM +0200, Carl Eugen Hoyos wrote: > > >> Fixes ticket #5805. > > > > LGTM, > > Patch applied. > > > can you add a fate test for this ? > > Please upload the sample to fate-suite/jpg/. uploaded thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] cuvid: Add hwaccels and decoders for remaining supported formats
cuvid/nvdecode also supports mpeg1, mpeg2, h.263/mpeg4-asp and mjpeg. It should, in theory, also support wmv3 via the vc1 support, given that vdpau supports this. However, it failed to play wmv3 samples which vdpau played correctly, so I'm not sure what to make of it. Signed-off-by: Philip Langdale --- configure | 18 ++ libavcodec/allcodecs.c | 10 ++ libavcodec/cuvid.c | 45 + libavcodec/version.h | 2 +- 4 files changed, 74 insertions(+), 1 deletion(-) diff --git a/configure b/configure index ce69936..c17e37c 100755 --- a/configure +++ b/configure @@ -2549,6 +2549,7 @@ videotoolbox_hwaccel_deps="videotoolbox pthreads" videotoolbox_hwaccel_extralibs="-framework QuartzCore" xvmc_deps="X11_extensions_XvMClib_h" +h263_cuvid_hwaccel_deps="cuda cuvid CUVIDMPEG4PICPARAMS" h263_vaapi_hwaccel_deps="vaapi" h263_vaapi_hwaccel_select="h263_decoder" h263_videotoolbox_hwaccel_deps="videotoolbox" @@ -2591,10 +2592,12 @@ hevc_vaapi_hwaccel_deps="vaapi VAPictureParameterBufferHEVC" hevc_vaapi_hwaccel_select="hevc_decoder" hevc_vdpau_hwaccel_deps="vdpau VdpPictureInfoHEVC" hevc_vdpau_hwaccel_select="hevc_decoder" +mjpeg_cuvid_hwaccel_deps="cuda cuvid CUVIDJPEGPICPARAMS" mpeg_vdpau_decoder_deps="vdpau" mpeg_vdpau_decoder_select="mpeg2video_decoder" mpeg_xvmc_hwaccel_deps="xvmc" mpeg_xvmc_hwaccel_select="mpeg2video_decoder" +mpeg1_cuvid_hwaccel_deps="cuda cuvid CUVIDMPEG2PICPARAMS" mpeg1_vdpau_decoder_deps="vdpau" mpeg1_vdpau_decoder_select="mpeg1video_decoder" mpeg1_vdpau_hwaccel_deps="vdpau" @@ -2604,6 +2607,7 @@ mpeg1_videotoolbox_hwaccel_select="mpeg1video_decoder" mpeg1_xvmc_hwaccel_deps="xvmc" mpeg1_xvmc_hwaccel_select="mpeg1video_decoder" mpeg2_crystalhd_decoder_select="crystalhd" +mpeg2_cuvid_hwaccel_deps="cuda cuvid CUVIDMPEG2PICPARAMS" mpeg2_d3d11va_hwaccel_deps="d3d11va" mpeg2_d3d11va_hwaccel_select="mpeg2video_decoder" mpeg2_dxva2_hwaccel_deps="dxva2" @@ -2622,6 +2626,7 @@ mpeg2_videotoolbox_hwaccel_select="mpeg2video_decoder" mpeg2_xvmc_hwaccel_deps="xvmc" mpeg2_xvmc_hwaccel_select="mpeg2video_decoder" mpeg4_crystalhd_decoder_select="crystalhd" +mpeg4_cuvid_hwaccel_deps="cuda cuvid CUVIDMPEG4PICPARAMS" mpeg4_mmal_decoder_deps="mmal" mpeg4_mmal_decoder_select="mmal" mpeg4_mmal_hwaccel_deps="mmal" @@ -2679,6 +2684,8 @@ scale_npp_filter_deps="cuda libnpp" nvenc_deps_any="dlopen LoadLibrary" nvenc_encoder_deps="nvenc" +h263_cuvid_decoder_deps="cuda cuvid CUVIDMPEG4PICPARAMS" +h263_cuvid_decoder_select="h263_cuvid_hwaccel" h264_cuvid_decoder_deps="cuda cuvid CUVIDH264PICPARAMS" h264_cuvid_decoder_select="h264_mp4toannexb_bsf h264_cuvid_hwaccel" h264_nvenc_encoder_deps="nvenc" @@ -2698,10 +2705,18 @@ hevc_qsv_encoder_deps="libmfx" hevc_qsv_encoder_select="qsvenc" hevc_vaapi_encoder_deps="VAEncPictureParameterBufferHEVC" hevc_vaapi_encoder_select="vaapi_encode golomb" +mjpeg_cuvid_decoder_deps="cuda cuvid CUVIDJPEGPICPARAMS" +mjpeg_cuvid_decoder_select="mjpeg_cuvid_hwaccel" +mpeg1_cuvid_decoder_deps="cuda cuvid CUVIDMPEG2PICPARAMS" +mpeg1_cuvid_decoder_select="mpeg1_cuvid_hwaccel" +mpeg2_cuvid_decoder_deps="cuda cuvid CUVIDMPEG2PICPARAMS" +mpeg2_cuvid_decoder_select="mpeg2_cuvid_hwaccel" mpeg2_qsv_decoder_deps="libmfx" mpeg2_qsv_decoder_select="qsvdec mpeg2_qsv_hwaccel" mpeg2_qsv_encoder_deps="libmfx" mpeg2_qsv_encoder_select="qsvenc" +mpeg4_cuvid_decoder_deps="cuda cuvid CUVIDMPEG4PICPARAMS" +mpeg4_cuvid_decoder_select="mpeg4_cuvid_hwaccel" nvenc_h264_encoder_deps="nvenc" nvenc_hevc_encoder_deps="nvenc" @@ -5562,6 +5577,9 @@ check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC" check_type "cuviddec.h" "CUVIDH264PICPARAMS" check_type "cuviddec.h" "CUVIDHEVCPICPARAMS" +check_type "cuviddec.h" "CUVIDJPEGPICPARAMS" +check_type "cuviddec.h" "CUVIDMPEG2PICPARAMS" +check_type "cuviddec.h" "CUVIDMPEG4PICPARAMS" check_type "cuviddec.h" "CUVIDVC1PICPARAMS" check_type "cuviddec.h" "CUVIDVP9PICPARAMS" diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c index 4c6b94e..a26a80e 100644 --- a/libavcodec/allcodecs.c +++ b/libavcodec/allcodecs.c @@ -67,6 +67,7 @@ void avcodec_register_all(void) initialized = 1; /* hardware accelerators */ +REGISTER_HWACCEL(H263_CUVID,h263_cuvid); REGISTER_HWACCEL(H263_VAAPI,h263_vaapi); REGISTER_HWACCEL(H263_VIDEOTOOLBOX, h263_videotoolbox); REGISTER_HWACCEL(H264_CUVID,h264_cuvid); @@ -86,9 +87,12 @@ void avcodec_register_all(void) REGISTER_HWACCEL(HEVC_QSV, hevc_qsv); REGISTER_HWACCEL(HEVC_VAAPI,hevc_vaapi); REGISTER_HWACCEL(HEVC_VDPAU,hevc_vdpau); +REGISTER_HWACCEL(MJPEG_CUVID, mjpeg_cuvid); +REGISTER_HWACCEL(MPEG1_CUVID, mpeg1_cuvid); REGISTER_HWACCEL(MPEG1_XVMC,mpeg1_xvmc); REGISTER_HWACCEL(MPEG1_VDPAU, mpeg1_vdpau); REGISTER_HWACCEL(MPEG1_VIDEOTOOLBOX, mpeg1_videotoolbox); +REGISTER_HWACCEL(MPEG2_CUVID
Re: [FFmpeg-devel] CNG (consistent noise generation) patch for AC-3 decoder
On 2 September 2016 at 02:59, Jonathan Campbell <
jonat...@impactstudiopro.com> wrote:
> I finished the consistent noise generation patch for AC-3 decoding.
>
> Set AVOption "cons_noisegen" to 1 (true) to enable it.
>
> Git repository:
> https://github.com/joncampbell123/FFmpeg.git
>
> commit dbd086586f0ad1591ea2013293bbb6e4dbfd0455
> Author: Jonathan Campbell
> Date: Thu Sep 1 18:46:16 2016 -0700
>
> AC-3 consistent noise generation: avopt -cons_noisegen
>
> When -cons_noisegen 1, the linear feedback generator used for AC-3
> dithering is seeded with the contents of the AC-3 frame. Seeding from
> the AC-3 frame ensures the dithering noise comes out exactly the same
> when given the same AC-3 frame data, which can then be used by
> non-linear editing software to reliably decode discontinuous segments
> of
> an AC-3 bitstream without gaps or discontinuities.
>
> Jonathan Campbell
>
> Patch follows, hope Thunderbird doesn't garble it:
>
> diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
> index fac189b..28048d7 100644
> --- a/libavcodec/ac3dec.c
> +++ b/libavcodec/ac3dec.c
> @@ -1419,6 +1419,19 @@ static int ac3_decode_frame(AVCodecContext *
> avctx, void *data,
> (const uint16_t *) buf, cnt);
> } else
> memcpy(s->input_buffer, buf, FFMIN(buf_size,
> AC3_FRAME_BUFFER_SIZE));
> +
> +/* if consistent noise generation is enabled, seed the linear
> feedback generator
> + * with the contents of the AC-3 frame so that the noise is identical
> across
> + * decodes given the same AC-3 frame data, for use with non-linear
> edititing software. */
> +if (s->consistent_noise_generation) {
> +const AVCRC *avcrc = av_crc_get_table(AV_CRC_32_IEEE);
> +
> +if (avcrc != NULL)
> +av_lfg_init(&s->dith_state, av_crc(avcrc, 0, s->input_buffer,
> FFMIN(buf_size, AC3_FRAME_BUFFER_SIZE)));
> +else
> +av_log(avctx, AV_LOG_ERROR, "CNG unable to seed from frame");
> +}
> +
> buf = s->input_buffer;
> /* initialize the GetBitContext with the start of valid AC-3 Frame */
> if ((ret = init_get_bits8(&s->gbc, buf, buf_size)) < 0)
> diff --git a/libavcodec/ac3dec.h b/libavcodec/ac3dec.h
> index c2b867e..98184e9 100644
> --- a/libavcodec/ac3dec.h
> +++ b/libavcodec/ac3dec.h
> @@ -177,6 +177,10 @@ typedef struct AC3DecodeContext {
> int end_freq[AC3_MAX_CHANNELS]; ///< end frequency bin
> (endmant)
> ///@}
>
> +///@name Consistent noise generation
> +int consistent_noise_generation;///< seed noise generation
> with AC-3 frame on decode
> +///@}
> +
> ///@name Rematrixing
> int num_rematrixing_bands; ///< number of rematrixing
> bands(nrematbnd)
> int rematrixing_flags[4]; ///< rematrixing flags
> (rematflg)
> diff --git a/libavcodec/ac3dec_fixed.c b/libavcodec/ac3dec_fixed.c
> index 6416da4..1f79ade 100644
> --- a/libavcodec/ac3dec_fixed.c
> +++ b/libavcodec/ac3dec_fixed.c
> @@ -168,6 +168,7 @@ static void ac3_downmix_c_fixed16(int16_t **samples,
> int16_t (*matrix)[2],
> #include "ac3dec.c"
>
> static const AVOption options[] = {
> +{ "cons_noisegen", "enable consistent noise generation",
> OFFSET(consistent_noise_generation), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1,
> PAR },
> { "drc_scale", "percentage of dynamic range compression to apply",
> OFFSET(drc_scale), AV_OPT_TYPE_FLOAT, {.dbl = 1.0}, 0.0, 6.0, PAR },
> { "heavy_compr", "enable heavy dynamic range compression",
> OFFSET(heavy_compression), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, PAR },
> { NULL},
> diff --git a/libavcodec/ac3dec_float.c b/libavcodec/ac3dec_float.c
> index 0a5319a..b85a4ce 100644
> --- a/libavcodec/ac3dec_float.c
> +++ b/libavcodec/ac3dec_float.c
> @@ -32,6 +32,7 @@
> #include "ac3dec.c"
>
> static const AVOption options[] = {
> +{ "cons_noisegen", "enable consistent noise generation",
> OFFSET(consistent_noise_generation), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1,
> PAR },
> { "drc_scale", "percentage of dynamic range compression to apply",
> OFFSET(drc_scale), AV_OPT_TYPE_FLOAT, {.dbl = 1.0}, 0.0, 6.0, PAR },
> { "heavy_compr", "enable heavy dynamic range compression",
> OFFSET(heavy_compression), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, PAR },
> { "target_level", "target level in -dBFS (0 not applied)",
> OFFSET(target_level), AV_OPT_TYPE_INT, {.i64 = 0 }, -31, 0, PAR },
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Any random noise, hardcoded constant or not sill sounds like white noise.
What is the point of this patch?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] CNG (consistent noise generation) patch for AC-3 decoder
On 9/3/2016 11:07 AM, James Almer wrote:
>> > +
>> > +/* avoid integer overflow in the loop below. */
>> > +if (length > (UINT_MAX / 128U)) return AVERROR(EINVAL);
>> > +
>> > +/* across 64 segments of the incoming data,
>> > + * do a running crc of each segment and store the crc as the state
>> > for that slot.
>> > + * this works even if the length of the segment is 0 bytes. */
>> > +beg = 0;
>> > +for (segm = 0;segm < 64;segm++) {
>> > +end = (((segm + 1) * length) / 64);
>> > +crc = av_crc(avcrc, crc, data + beg, end - beg);
> The thing about speed made me wonder, wouldn't using adler32 be faster?
Nevermind, probably not a good idea. adler32 wouldn't be a good seed
for lfg.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] CNG (consistent noise generation) patch for AC-3 decoder
Hi! 2016-09-03 18:27 GMT+02:00 Jonathan Campbell : > Do you understand now why this is useful for NLE software, Of course. > but should not be enabled by default? Only if I completely underestimate the additional cpu usage. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] CNG (consistent noise generation) patch for AC-3 decoder
On 09/03/2016 01:32 PM, Rostislav Pehlivanov wrote:
> On 2 September 2016 at 02:59, Jonathan Campbell <
> jonat...@impactstudiopro.com> wrote:
>
>> I finished the consistent noise generation patch for AC-3 decoding.
>>
>> Set AVOption "cons_noisegen" to 1 (true) to enable it.
>>
>> Git repository:
>> https://github.com/joncampbell123/FFmpeg.git
>>
>> commit dbd086586f0ad1591ea2013293bbb6e4dbfd0455
>> Author: Jonathan Campbell
>> Date: Thu Sep 1 18:46:16 2016 -0700
>>
>> AC-3 consistent noise generation: avopt -cons_noisegen
>>
>> When -cons_noisegen 1, the linear feedback generator used for AC-3
>> dithering is seeded with the contents of the AC-3 frame. Seeding from
>> the AC-3 frame ensures the dithering noise comes out exactly the same
>> when given the same AC-3 frame data, which can then be used by
>> non-linear editing software to reliably decode discontinuous segments
>> of
>> an AC-3 bitstream without gaps or discontinuities.
>>
>> Jonathan Campbell
>>
>> Patch follows, hope Thunderbird doesn't garble it:
>>
>> diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
>> index fac189b..28048d7 100644
>> --- a/libavcodec/ac3dec.c
>> +++ b/libavcodec/ac3dec.c
>> @@ -1419,6 +1419,19 @@ static int ac3_decode_frame(AVCodecContext *
>> avctx, void *data,
>> (const uint16_t *) buf, cnt);
>> } else
>> memcpy(s->input_buffer, buf, FFMIN(buf_size,
>> AC3_FRAME_BUFFER_SIZE));
>> +
>> +/* if consistent noise generation is enabled, seed the linear
>> feedback generator
>> + * with the contents of the AC-3 frame so that the noise is identical
>> across
>> + * decodes given the same AC-3 frame data, for use with non-linear
>> edititing software. */
>> +if (s->consistent_noise_generation) {
>> +const AVCRC *avcrc = av_crc_get_table(AV_CRC_32_IEEE);
>> +
>> +if (avcrc != NULL)
>> +av_lfg_init(&s->dith_state, av_crc(avcrc, 0, s->input_buffer,
>> FFMIN(buf_size, AC3_FRAME_BUFFER_SIZE)));
>> +else
>> +av_log(avctx, AV_LOG_ERROR, "CNG unable to seed from frame");
>> +}
>> +
>> buf = s->input_buffer;
>> /* initialize the GetBitContext with the start of valid AC-3 Frame */
>> if ((ret = init_get_bits8(&s->gbc, buf, buf_size)) < 0)
>> diff --git a/libavcodec/ac3dec.h b/libavcodec/ac3dec.h
>> index c2b867e..98184e9 100644
>> --- a/libavcodec/ac3dec.h
>> +++ b/libavcodec/ac3dec.h
>> @@ -177,6 +177,10 @@ typedef struct AC3DecodeContext {
>> int end_freq[AC3_MAX_CHANNELS]; ///< end frequency bin
>> (endmant)
>> ///@}
>>
>> +///@name Consistent noise generation
>> +int consistent_noise_generation;///< seed noise generation
>> with AC-3 frame on decode
>> +///@}
>> +
>> ///@name Rematrixing
>> int num_rematrixing_bands; ///< number of rematrixing
>> bands(nrematbnd)
>> int rematrixing_flags[4]; ///< rematrixing flags
>> (rematflg)
>> diff --git a/libavcodec/ac3dec_fixed.c b/libavcodec/ac3dec_fixed.c
>> index 6416da4..1f79ade 100644
>> --- a/libavcodec/ac3dec_fixed.c
>> +++ b/libavcodec/ac3dec_fixed.c
>> @@ -168,6 +168,7 @@ static void ac3_downmix_c_fixed16(int16_t **samples,
>> int16_t (*matrix)[2],
>> #include "ac3dec.c"
>>
>> static const AVOption options[] = {
>> +{ "cons_noisegen", "enable consistent noise generation",
>> OFFSET(consistent_noise_generation), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1,
>> PAR },
>> { "drc_scale", "percentage of dynamic range compression to apply",
>> OFFSET(drc_scale), AV_OPT_TYPE_FLOAT, {.dbl = 1.0}, 0.0, 6.0, PAR },
>> { "heavy_compr", "enable heavy dynamic range compression",
>> OFFSET(heavy_compression), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, PAR },
>> { NULL},
>> diff --git a/libavcodec/ac3dec_float.c b/libavcodec/ac3dec_float.c
>> index 0a5319a..b85a4ce 100644
>> --- a/libavcodec/ac3dec_float.c
>> +++ b/libavcodec/ac3dec_float.c
>> @@ -32,6 +32,7 @@
>> #include "ac3dec.c"
>>
>> static const AVOption options[] = {
>> +{ "cons_noisegen", "enable consistent noise generation",
>> OFFSET(consistent_noise_generation), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1,
>> PAR },
>> { "drc_scale", "percentage of dynamic range compression to apply",
>> OFFSET(drc_scale), AV_OPT_TYPE_FLOAT, {.dbl = 1.0}, 0.0, 6.0, PAR },
>> { "heavy_compr", "enable heavy dynamic range compression",
>> OFFSET(heavy_compression), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, PAR },
>> { "target_level", "target level in -dBFS (0 not applied)",
>> OFFSET(target_level), AV_OPT_TYPE_INT, {.i64 = 0 }, -31, 0, PAR },
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> Any random noise, hardcoded constant or not sill sounds like white noise.
Yes.
> What is the point of this patch?
To make the random noise consistent with the AC-3 frame data
[FFmpeg-devel] [PATCH]fate: Add a test for ticket #5805.
Hi! Attached is a patch to test ticket #5805. Unrelated: There is an unused (never used) sample in fate/jpg, see https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/181127.html Please comment, Carl Eugen From 7fa7dd607866ba8106e1964e794228c900847c8a Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Sun, 4 Sep 2016 00:33:50 +0200 Subject: [PATCH] fate: Add test for ticket #5805. --- tests/fate/image.mak|7 +++ tests/ref/fate/jpg-jfif |6 ++ 2 files changed, 13 insertions(+) create mode 100644 tests/ref/fate/jpg-jfif diff --git a/tests/fate/image.mak b/tests/fate/image.mak index 178624a..f786503 100644 --- a/tests/fate/image.mak +++ b/tests/fate/image.mak @@ -393,6 +393,13 @@ FATE_XBM-$(call DEMDEC, IMAGE2, XBM) += $(FATE_XBM) FATE_IMAGE += $(FATE_XBM-yes) fate-xbm: $(FATE_XBM-yes) +FATE_JPG += fate-jpg-jfif +fate-jpg-jfif: CMD = framecrc -idct simple -i $(TARGET_SAMPLES)/jpg/12bpp.jpg + +FATE_JPG-$(call DEMDEC, IMAGE2, MJPEG) += $(FATE_JPG) +FATE_IMAGE += $(FATE_JPG-yes) +fate-jpg: $(FATE_JPG-yes) + FATE_IMAGE += $(FATE_IMAGE-yes) FATE_SAMPLES_FFMPEG += $(FATE_IMAGE) diff --git a/tests/ref/fate/jpg-jfif b/tests/ref/fate/jpg-jfif new file mode 100644 index 000..4c44217 --- /dev/null +++ b/tests/ref/fate/jpg-jfif @@ -0,0 +1,6 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 999x749 +#sar 0: 300/300 +0, 0, 0,1, 1496502, 0xd91deb4b -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/mjpegdec: Only read JFIF thumbnail size if the segment is long enough.
2016-09-03 19:58 GMT+02:00 Michael Niedermayer : >> > can you add a fate test for this ? >> >> Please upload the sample to fate-suite/jpg/. > > uploaded Patch sent. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] CNG (consistent noise generation) patch for AC-3 decoder
On 09/03/2016 07:07 AM, James Almer wrote:
> On 9/3/2016 7:50 AM, Jonathan Campbell wrote:
>> +int av_lfg_init_from_data(AVLFG *c, const uint8_t *data, unsigned int
>> length) {
>> +unsigned int beg, end, segm;
>> +const AVCRC *avcrc;
>> +uint32_t crc = 1;
>> +
>> +c->index = 0;
>
> The AVLFG struct should IMO remain untouched if init is guaranteed to fail,
> as it would be the case with an out or range length value, so move this after
> that check.
>
>> +avcrc = av_crc_get_table(AV_CRC_32_IEEE); /* This can't fail. It's a
>> well-defined table in crc.c */
>
> You could also move this one below.
>
>> +
>> +/* avoid integer overflow in the loop below. */
>> +if (length > (UINT_MAX / 128U)) return AVERROR(EINVAL);
>> +
>> +/* across 64 segments of the incoming data,
>> + * do a running crc of each segment and store the crc as the state for
>> that slot.
>> + * this works even if the length of the segment is 0 bytes. */
>> +beg = 0;
>> +for (segm = 0;segm < 64;segm++) {
>> +end = (((segm + 1) * length) / 64);
>> +crc = av_crc(avcrc, crc, data + beg, end - beg);
>
> The thing about speed made me wonder, wouldn't using adler32 be faster?
> If so, this feature could maybe even be enabled by default with it.
>
>> +c->state[segm] = (unsigned int)crc;
>> +beg = end;
>> +}
>> +
>> +return 0;
>> +}
>> diff --git a/libavutil/lfg.h b/libavutil/lfg.h
>> index ec90562..72eb673 100644
>> --- a/libavutil/lfg.h
>> +++ b/libavutil/lfg.h
>> @@ -22,6 +22,8 @@
>> #ifndef AVUTIL_LFG_H
>> #define AVUTIL_LFG_H
>>
>> +#include /* uint8_t type */
>> +
>> typedef struct AVLFG {
>> unsigned int state[64];
>> int index;
>> @@ -29,6 +31,13 @@ typedef struct AVLFG {
>>
>> void av_lfg_init(AVLFG *c, unsigned int seed);
>>
>> +/*
>
> This is meant for doxygen, so /** like in every other function.
>
>> + * Seed the state of the ALFG using binary data.
>> + *
>> + * Return value: 0 on success, negative value (AVERROR) on failure.
>> + */
>> +int av_lfg_init_from_data(AVLFG *c, const uint8_t *data, unsigned int
>> length);
>> +
>> /**
>> * Get the next random unsigned 32-bit number using an ALFG.
>> *
>
> No more comments for me.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Here you go.
Jonathan Campbell
From 5de30d309fb48b26acd8d95f14ef4d4064450ddc Mon Sep 17 00:00:00 2001
From: Jonathan Campbell
Date: Sat, 3 Sep 2016 03:20:41 -0700
Subject: [PATCH 1/4] libavutil version bump, av_lfg_init_from_data() incoming
---
libavutil/version.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/version.h b/libavutil/version.h
index 7d32c7b..60b58eb 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 55
-#define LIBAVUTIL_VERSION_MINOR 29
+#define LIBAVUTIL_VERSION_MINOR 30
#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
--
2.2.2
From 3cc9a0e4a8bae127ca9254f31cd8b7f00d107395 Mon Sep 17 00:00:00 2001
From: Jonathan Campbell
Date: Sat, 3 Sep 2016 03:29:29 -0700
Subject: [PATCH 2/4] libavutil av_lfg_init_from_data() function
seeds an AVLFG from binary data.
---
libavutil/lfg.c | 27 +++
libavutil/lfg.h | 9 +
2 files changed, 36 insertions(+)
diff --git a/libavutil/lfg.c b/libavutil/lfg.c
index 08a4f67..0ef456a 100644
--- a/libavutil/lfg.c
+++ b/libavutil/lfg.c
@@ -23,7 +23,9 @@
#include
#include
#include "lfg.h"
+#include "crc.h"
#include "md5.h"
+#include "error.h"
#include "intreadwrite.h"
#include "attributes.h"
@@ -58,3 +60,28 @@ void av_bmg_get(AVLFG *lfg, double out[2])
out[0] = x1 * w;
out[1] = x2 * w;
}
+
+int av_lfg_init_from_data(AVLFG *c, const uint8_t *data, unsigned int length) {
+unsigned int beg, end, segm;
+const AVCRC *avcrc;
+uint32_t crc = 1;
+
+c->index = 0;
+avcrc = av_crc_get_table(AV_CRC_32_IEEE); /* This can't fail. It's a
well-defined table in crc.c */
+
+/* avoid integer overflow in the loop below. */
+if (length > (UINT_MAX / 128U)) return AVERROR(EINVAL);
+
+/* across 64 segments of the incoming data,
+ * do a running crc of each segment and store the crc as the state for
that slot.
+ * this works even if the length of the segment is 0 bytes. */
+beg = 0;
+for (segm = 0;segm < 64;segm++) {
+end = (((segm + 1) * length) / 64);
+crc = av_crc(avcrc, crc, data + beg, end - beg);
+c->state[segm] = (unsigned int)crc;
+beg = end;
+}
+
+return 0;
+}
diff --git a/libavutil/lfg.h b/libavutil/lfg.h
index ec90562..72eb673 100644
--- a/libavutil/lfg.h
+++ b/libavutil/lfg.h
@@ -22,6 +22,8 @@
#ifndef AVUTIL_LFG_H
#define AVUTIL_LFG_H
+#include /* uint8_t type */
+
typedef struct AVLFG {
Re: [FFmpeg-devel] [PATCH 4/4] lavf/mov: Add support for edit list parsing.
On Sat, Sep 03, 2016 at 12:06:39PM -0700, Sasi Inguva wrote: > Hi Michael, > > In fact from audacity I see that out-ingu.wav out-mp3.wav are almost > equivalent, They do not match. (and that is alot more vissible if you scale the time axis up a bit) You also dont use the existing API for handling initial padding/skip And you didnt reply to this concern its probably not that hard to fix that ... instead of droping just at packet granularity you would set the stuff for droping at sample granularity (too) also maybe you missed my question about your oppinion on the correct timestamp output: "My first question is, entirely independant of the implementation from the patches. What is the correct output ? (my primary focus is on the timestamps)" Iam curious because to me the timestamps of the dropped packets look wrong and id like to know your oppinion about this. Is this a implementation issue (if so please explain) or is there some reason independant of the implementation (if so please explain too) [...] > though not exactly. However if I do the same RAW->MOV->WAV > conversion with head, I see that the out-head.wav is shifted to the right . git master gets it totally wrong with mp3 in mov i agree here 100% can you fix this exactly (not just almost) ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]fate: Add a test for ticket #5805.
On Sun, Sep 04, 2016 at 12:36:46AM +0200, Carl Eugen Hoyos wrote: > Hi! > > Attached is a patch to test ticket #5805. > Unrelated: There is an unused (never used) sample in fate/jpg, see > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/181127.html > > Please comment, Carl Eugen > fate/image.mak|7 +++ > ref/fate/jpg-jfif |6 ++ > 2 files changed, 13 insertions(+) > 893010ecbe7b0e0c1654f81d1c9156c21f9cab10 > 0001-fate-Add-test-for-ticket-5805.patch > From 7fa7dd607866ba8106e1964e794228c900847c8a Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos > Date: Sun, 4 Sep 2016 00:33:50 +0200 > Subject: [PATCH] fate: Add test for ticket #5805. fails on mips --- tests/ref/fate/jpg-jfif 2016-09-04 00:52:48.498542838 +0200 +++ tests/data/fate/jpg-jfif2016-09-04 02:32:17.618668591 +0200 @@ -3,4 +3,4 @@ #codec_id 0: rawvideo #dimensions 0: 999x749 #sar 0: 300/300 -0, 0, 0,1, 1496502, 0xd91deb4b +0, 0, 0,1, 1496502, 0x7593eb4b Test jpg-jfif failed. Look at tests/data/fate/jpg-jfif.err for details. make: *** [fate-jpg-jfif] Error 1 Stream #0:0: Video: rawvideo ([16][0]1Y / 0x59310010), gray16be(12 bpc), 999x749 [SAR 300:300 DAR 999:749], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc ^^ [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Discussion: How to extend the AVFrame to hold caption data?
While I'm finishing up the CNG patch, I'd like to start developing another feature that I think FFMPEG should be able to at least expose through the API. I'm aware that FFMPEG supports subtitle tracks, but as far as I know, doesn't support caption data embedded in the video stream itself. Some scenarios especially in broadcast TV transmit MPEG-2 or H.264 video with caption data embedded in the encoded frame. I would like to write a patch that can read the caption data embedded in MPEG-2 user packets and expose it in the AVFrame. There are two common forms I work with in software: One carries EIA 608 closed caption packets per keyframe (typically seen on DVDs here in America), the other carries CEA 708 closed caption data (Caption Description Packets) every frame (or every I/P frame) with a side channel for 608 (typically seen in terrestrial HDTV broadcast here in America). How could I modify the MPEG-2 decoder and/or bitstream parser to read and expose this data through the API for software that needs it? I'm also interested in modding the MPEG-2 encoder to take this data through the API and encode it into the frame. If done right, the extension could allow FFMPEG to transcode DVD or HDTV broadcasts while keeping the caption data intact. Similar standards exist to carry caption data packets in H.264 (as SEI packets) and DV video (as DIF packets). Jonathan Campbell ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion: How to extend the AVFrame to hold caption data?
AVFrame already has some support for embedded 608/708 subtitles in a form of side data (AV_FRAME_DATA_A53_CC tag), and some decoders/encoders already can handle that. Main issue with this approach is that video frames can be modified, removed or duplicated (mainly by video filters but also by ffmpeg's video sync code). 2016-09-04 6:14 GMT+03:00 Jonathan Campbell : > While I'm finishing up the CNG patch, I'd like to start developing another > feature that I think FFMPEG should be able to at least expose through the > API. > > I'm aware that FFMPEG supports subtitle tracks, but as far as I know, > doesn't support caption data embedded in the video stream itself. > > Some scenarios especially in broadcast TV transmit MPEG-2 or H.264 video > with caption data embedded in the encoded frame. I would like to write a > patch that can read the caption data embedded in MPEG-2 user packets and > expose it in the AVFrame. > > There are two common forms I work with in software: One carries EIA 608 > closed caption packets per keyframe (typically seen on DVDs here in > America), the other carries CEA 708 closed caption data (Caption > Description Packets) every frame (or every I/P frame) with a side channel > for 608 (typically seen in terrestrial HDTV broadcast here in America). How > could I modify the MPEG-2 decoder and/or bitstream parser to read and > expose this data through the API for software that needs it? I'm also > interested in modding the MPEG-2 encoder to take this data through the API > and encode it into the frame. If done right, the extension could allow > FFMPEG to transcode DVD or HDTV broadcasts while keeping the caption data > intact. > > Similar standards exist to carry caption data packets in H.264 (as SEI > packets) and DV video (as DIF packets). > > Jonathan Campbell > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion: How to extend the AVFrame to hold caption data?
On 09/03/2016 11:26 PM, Andrey Turkin wrote: > AVFrame already has some support for embedded 608/708 subtitles in a form > of side data (AV_FRAME_DATA_A53_CC tag), and some decoders/encoders already > can handle that. > Main issue with this approach is that video frames can be modified, removed > or duplicated (mainly by video filters but also by ffmpeg's video sync > code). > > 2016-09-04 6:14 GMT+03:00 Jonathan Campbell : > >> While I'm finishing up the CNG patch, I'd like to start developing another >> feature that I think FFMPEG should be able to at least expose through the >> API. >> >> I'm aware that FFMPEG supports subtitle tracks, but as far as I know, >> doesn't support caption data embedded in the video stream itself. >> >> Some scenarios especially in broadcast TV transmit MPEG-2 or H.264 video >> with caption data embedded in the encoded frame. I would like to write a >> patch that can read the caption data embedded in MPEG-2 user packets and >> expose it in the AVFrame. >> >> There are two common forms I work with in software: One carries EIA 608 >> closed caption packets per keyframe (typically seen on DVDs here in >> America), the other carries CEA 708 closed caption data (Caption >> Description Packets) every frame (or every I/P frame) with a side channel >> for 608 (typically seen in terrestrial HDTV broadcast here in America). How >> could I modify the MPEG-2 decoder and/or bitstream parser to read and >> expose this data through the API for software that needs it? I'm also >> interested in modding the MPEG-2 encoder to take this data through the API >> and encode it into the frame. If done right, the extension could allow >> FFMPEG to transcode DVD or HDTV broadcasts while keeping the caption data >> intact. >> >> Similar standards exist to carry caption data packets in H.264 (as SEI >> packets) and DV video (as DIF packets). >> >> Jonathan Campbell >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Cool, that's why I asked. I see it now in mpeg12dec.c It looks like mpeg12enc.c though is lacking the code to read the A53_CC side data and put the caption data into the encoded frame. Mind if I write a patch to do that? Jonathan Campbell ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
