[FFmpeg-devel] [PATCH 1/2] dshow: Add missing library dependency (dxguid)
From: Moriyoshi koizumi Signed-off-by: Moriyoshi koizumi --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 1f684d2..fb8d7d3 100755 --- a/configure +++ b/configure @@ -2832,7 +2832,7 @@ decklink_indev_extralibs="-lstdc++" decklink_outdev_deps="decklink pthreads" decklink_outdev_extralibs="-lstdc++" dshow_indev_deps="IBaseFilter" -dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32 -lshlwapi" +dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32 -lshlwapi -ldxguid" dv1394_indev_deps="dv1394" dv1394_indev_select="dv_demuxer" fbdev_indev_deps="linux_fb_h" -- 2.8.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] dshow: Make dshow device buildable on Cygwin
From: Moriyoshi koizumi
wchar_t is not always the same thing as WCHAR.
Signed-off-by: Moriyoshi koizumi
---
libavdevice/dshow.c | 6 +++---
libavdevice/dshow_capture.h | 10 +-
libavdevice/dshow_filter.c | 16
libavdevice/dshow_pin.c | 10 +-
4 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 678861d..432b643 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -129,7 +129,7 @@ dshow_read_close(AVFormatContext *s)
return 0;
}
-static char *dup_wchar_to_utf8(wchar_t *w)
+static char *dup_wchar_to_utf8(WCHAR *w)
{
char *s = NULL;
int l = WideCharToMultiByte(CP_UTF8, 0, w, -1, 0, 0, 0, 0);
@@ -599,7 +599,7 @@ dshow_cycle_pins(AVFormatContext *avctx, enum
dshowDeviceType devtype,
GUID category;
DWORD r2;
char *name_buf = NULL;
-wchar_t *pin_id = NULL;
+WCHAR *pin_id = NULL;
char *pin_buf = NULL;
char *desired_pin_name = devtype == VideoDevice ? ctx->video_pin_name
: ctx->audio_pin_name;
@@ -734,7 +734,7 @@ dshow_open_device(AVFormatContext *avctx, ICreateDevEnum
*devenum,
IStream *ofile_stream = NULL;
IPersistStream *pers_stream = NULL;
-const wchar_t *filter_name[2] = { L"Audio capture filter", L"Video capture
filter" };
+const WCHAR *filter_name[2] = { L"Audio capture filter", L"Video capture
filter" };
if ( ((ctx->audio_filter_load_file) &&
(strlen(ctx->audio_filter_load_file)>0) && (sourcetype == AudioSourceDevice)) ||
diff --git a/libavdevice/dshow_capture.h b/libavdevice/dshow_capture.h
index f26eaf9..860b782 100644
--- a/libavdevice/dshow_capture.h
+++ b/libavdevice/dshow_capture.h
@@ -176,7 +176,7 @@ long WINAPI libAVPin_ConnectedTo
(libAVPin *, IPin **);
long WINAPI libAVPin_ConnectionMediaType (libAVPin *,
AM_MEDIA_TYPE *);
long WINAPI libAVPin_QueryPinInfo(libAVPin *, PIN_INFO *);
long WINAPI libAVPin_QueryDirection (libAVPin *,
PIN_DIRECTION *);
-long WINAPI libAVPin_QueryId (libAVPin *, wchar_t **);
+long WINAPI libAVPin_QueryId (libAVPin *, WCHAR **);
long WINAPI libAVPin_QueryAccept (libAVPin *, const
AM_MEDIA_TYPE *);
long WINAPI libAVPin_EnumMediaTypes (libAVPin *,
IEnumMediaTypes **);
long WINAPI libAVPin_QueryInternalConnections(libAVPin *, IPin **,
unsigned long *);
@@ -249,7 +249,7 @@ libAVEnumMediaTypes *libAVEnumMediaTypes_Create(const
AM_MEDIA_TYPE *type);
struct libAVFilter {
IBaseFilterVtbl *vtbl;
long ref;
-const wchar_t *name;
+const WCHAR *name;
libAVPin *pin;
FILTER_INFO info;
FILTER_STATE state;
@@ -272,10 +272,10 @@ long WINAPI libAVFilter_GetState
(libAVFilter *, DWORD, FILTER_ST
long WINAPI libAVFilter_SetSyncSource (libAVFilter *,
IReferenceClock *);
long WINAPI libAVFilter_GetSyncSource (libAVFilter *,
IReferenceClock **);
long WINAPI libAVFilter_EnumPins (libAVFilter *, IEnumPins **);
-long WINAPI libAVFilter_FindPin(libAVFilter *, const wchar_t
*, IPin **);
+long WINAPI libAVFilter_FindPin(libAVFilter *, const WCHAR *,
IPin **);
long WINAPI libAVFilter_QueryFilterInfo(libAVFilter *, FILTER_INFO *);
-long WINAPI libAVFilter_JoinFilterGraph(libAVFilter *, IFilterGraph
*, const wchar_t *);
-long WINAPI libAVFilter_QueryVendorInfo(libAVFilter *, wchar_t **);
+long WINAPI libAVFilter_JoinFilterGraph(libAVFilter *, IFilterGraph
*, const WCHAR *);
+long WINAPI libAVFilter_QueryVendorInfo(libAVFilter *, WCHAR **);
void libAVFilter_Destroy(libAVFilter *);
libAVFilter *libAVFilter_Create (void *, void *, enum dshowDeviceType);
diff --git a/libavdevice/dshow_filter.c b/libavdevice/dshow_filter.c
index 7360adc..3ba3871 100644
--- a/libavdevice/dshow_filter.c
+++ b/libavdevice/dshow_filter.c
@@ -20,6 +20,8 @@
*/
#include "dshow_capture.h"
+#include
+#include
DECLARE_QUERYINTERFACE(libAVFilter,
{ {&IID_IUnknown,0}, {&IID_IBaseFilter,0} })
@@ -108,14 +110,14 @@ libAVFilter_EnumPins(libAVFilter *this, IEnumPins
**enumpin)
return S_OK;
}
long WINAPI
-libAVFilter_FindPin(libAVFilter *this, const wchar_t *id, IPin **pin)
+libAVFilter_FindPin(libAVFilter *this, const WCHAR *id, IPin **pin)
{
libAVPin *found = NULL;
dshowdebug("libAVFilter_FindPin(%p)\n", this);
if (!id || !pin)
return E_POINTER;
-if (!wcscmp(id, L"In")) {
+if (!StrCmpW(id, L"In")) {
found = this->pin;
libAVPin_AddRef(found);
}
@@ -140,26 +142,24 @@ libAVFilter_QueryFilterInfo(libAVFilter *this,
FILTER_INFO *info)
}
long WINAPI
libAVFilter_JoinFilterGraph(libAVFilter *this, IFilterGraph *graph,
-const
[FFmpeg-devel] [PATCH 2/2] dshow: Make dshow device buildable on Cygwin
From: Moriyoshi koizumi
wchar_t is not always the same thing as WCHAR.
Signed-off-by: Moriyoshi koizumi
---
libavdevice/dshow.c | 6 +++---
libavdevice/dshow_capture.h | 10 +-
libavdevice/dshow_filter.c | 16
libavdevice/dshow_pin.c | 10 +-
4 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 678861d..432b643 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -129,7 +129,7 @@ dshow_read_close(AVFormatContext *s)
return 0;
}
-static char *dup_wchar_to_utf8(wchar_t *w)
+static char *dup_wchar_to_utf8(WCHAR *w)
{
char *s = NULL;
int l = WideCharToMultiByte(CP_UTF8, 0, w, -1, 0, 0, 0, 0);
@@ -599,7 +599,7 @@ dshow_cycle_pins(AVFormatContext *avctx, enum
dshowDeviceType devtype,
GUID category;
DWORD r2;
char *name_buf = NULL;
-wchar_t *pin_id = NULL;
+WCHAR *pin_id = NULL;
char *pin_buf = NULL;
char *desired_pin_name = devtype == VideoDevice ? ctx->video_pin_name
: ctx->audio_pin_name;
@@ -734,7 +734,7 @@ dshow_open_device(AVFormatContext *avctx, ICreateDevEnum
*devenum,
IStream *ofile_stream = NULL;
IPersistStream *pers_stream = NULL;
-const wchar_t *filter_name[2] = { L"Audio capture filter", L"Video capture
filter" };
+const WCHAR *filter_name[2] = { L"Audio capture filter", L"Video capture
filter" };
if ( ((ctx->audio_filter_load_file) &&
(strlen(ctx->audio_filter_load_file)>0) && (sourcetype == AudioSourceDevice)) ||
diff --git a/libavdevice/dshow_capture.h b/libavdevice/dshow_capture.h
index f26eaf9..860b782 100644
--- a/libavdevice/dshow_capture.h
+++ b/libavdevice/dshow_capture.h
@@ -176,7 +176,7 @@ long WINAPI libAVPin_ConnectedTo
(libAVPin *, IPin **);
long WINAPI libAVPin_ConnectionMediaType (libAVPin *,
AM_MEDIA_TYPE *);
long WINAPI libAVPin_QueryPinInfo(libAVPin *, PIN_INFO *);
long WINAPI libAVPin_QueryDirection (libAVPin *,
PIN_DIRECTION *);
-long WINAPI libAVPin_QueryId (libAVPin *, wchar_t **);
+long WINAPI libAVPin_QueryId (libAVPin *, WCHAR **);
long WINAPI libAVPin_QueryAccept (libAVPin *, const
AM_MEDIA_TYPE *);
long WINAPI libAVPin_EnumMediaTypes (libAVPin *,
IEnumMediaTypes **);
long WINAPI libAVPin_QueryInternalConnections(libAVPin *, IPin **,
unsigned long *);
@@ -249,7 +249,7 @@ libAVEnumMediaTypes *libAVEnumMediaTypes_Create(const
AM_MEDIA_TYPE *type);
struct libAVFilter {
IBaseFilterVtbl *vtbl;
long ref;
-const wchar_t *name;
+const WCHAR *name;
libAVPin *pin;
FILTER_INFO info;
FILTER_STATE state;
@@ -272,10 +272,10 @@ long WINAPI libAVFilter_GetState
(libAVFilter *, DWORD, FILTER_ST
long WINAPI libAVFilter_SetSyncSource (libAVFilter *,
IReferenceClock *);
long WINAPI libAVFilter_GetSyncSource (libAVFilter *,
IReferenceClock **);
long WINAPI libAVFilter_EnumPins (libAVFilter *, IEnumPins **);
-long WINAPI libAVFilter_FindPin(libAVFilter *, const wchar_t
*, IPin **);
+long WINAPI libAVFilter_FindPin(libAVFilter *, const WCHAR *,
IPin **);
long WINAPI libAVFilter_QueryFilterInfo(libAVFilter *, FILTER_INFO *);
-long WINAPI libAVFilter_JoinFilterGraph(libAVFilter *, IFilterGraph
*, const wchar_t *);
-long WINAPI libAVFilter_QueryVendorInfo(libAVFilter *, wchar_t **);
+long WINAPI libAVFilter_JoinFilterGraph(libAVFilter *, IFilterGraph
*, const WCHAR *);
+long WINAPI libAVFilter_QueryVendorInfo(libAVFilter *, WCHAR **);
void libAVFilter_Destroy(libAVFilter *);
libAVFilter *libAVFilter_Create (void *, void *, enum dshowDeviceType);
diff --git a/libavdevice/dshow_filter.c b/libavdevice/dshow_filter.c
index 7360adc..3ba3871 100644
--- a/libavdevice/dshow_filter.c
+++ b/libavdevice/dshow_filter.c
@@ -20,6 +20,8 @@
*/
#include "dshow_capture.h"
+#include
+#include
DECLARE_QUERYINTERFACE(libAVFilter,
{ {&IID_IUnknown,0}, {&IID_IBaseFilter,0} })
@@ -108,14 +110,14 @@ libAVFilter_EnumPins(libAVFilter *this, IEnumPins
**enumpin)
return S_OK;
}
long WINAPI
-libAVFilter_FindPin(libAVFilter *this, const wchar_t *id, IPin **pin)
+libAVFilter_FindPin(libAVFilter *this, const WCHAR *id, IPin **pin)
{
libAVPin *found = NULL;
dshowdebug("libAVFilter_FindPin(%p)\n", this);
if (!id || !pin)
return E_POINTER;
-if (!wcscmp(id, L"In")) {
+if (!StrCmpW(id, L"In")) {
found = this->pin;
libAVPin_AddRef(found);
}
@@ -140,26 +142,24 @@ libAVFilter_QueryFilterInfo(libAVFilter *this,
FILTER_INFO *info)
}
long WINAPI
libAVFilter_JoinFilterGraph(libAVFilter *this, IFilterGraph *graph,
-const
Re: [FFmpeg-devel] [PATCH 57/57] support for matrox m703 mpeg-2
> file attached but i think there is something wrong with the encoder > used, the files do not seem to contain enough non zero bits to > be able to contain full yuv422 10bit > so i am not sure this will resolve this ok, encoded it to m101 10bit: https://www.datafilehost.com/d/119d82c3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] set exact ref frame in AVMotionVector
hi, change the confusing "source" var to "ref" of AVMotionVector. define two constants AV_MV_REF_FRAME_PREVIOUS and AV_MV_REF_FRAME_NEXT all changes: https://github.com/dsmudhar/FFmpeg/commit/33b5ad805cccd7b48a6b0d643c39e8dd26f0e98b please confirm this: snowdec.c Line 96: BlockNode *bn... ... Line 112: avmv->source = -1 - bn->ref; i searched the code, bn->ref set was >= 0 so, i set it always prev: avmv->ref = AV_MV_REF_FRAME_PREVIOUS; since, in current code, "source" is checked if > 0 to be future ref, and line 112 set it always negative. Regards, DSM_ 0001-set-exact-ref-frame-in-AVMotionVector.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] set exact ref frame in AVMotionVector
On 5/6/2016 10:54 AM, Davinder Singh wrote: > change the confusing "source" var to "ref" of AVMotionVector. This would be a backwards incompatible API break, no? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] configure: Enable GCC vectorization on ≥4.9
On Tue, Feb 9, 2016 at 1:28 AM, Timothy Gu wrote: > On Sun, Jan 31, 2016 at 3:38 PM Timothy Gu wrote: >> >> On Sat, Jan 30, 2016 at 07:27:22PM +, Derek Buitenhuis wrote: >> > On 1/30/2016 7:15 PM, Timothy Gu wrote: >> > > FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1. >> > >> > Perhaps this should be restricted to x86? >> >> Fair enough. > > > Pushed. > Just to document it, this has caused build breakage in various scenarios, even in GCC 5.3 (6.1 not tested). The latest reported on IRC just today here: libavcodec/sbrdsp.c: In function 'sbr_neg_odd_64_c': libavcodec/sbrdsp.c:47:13: internal compiler error: in vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596 static void sbr_neg_odd_64_c(float *x) There are various other cases which usually involve inline asm when building with SIMD (ie. --cpu=host) and the optimizer running out of registers, for example: libavcodec/x86/cabac.h:192:5: error: 'asm' operand has impossible constraints IMHO this feature is not quite ready to be enabled unconditionally in our code base, and we should re-evaluate this change. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] vc2enc: prevent random data
Hi, 2016-05-06 2:19 GMT+02:00 Rostislav Pehlivanov : > I plan to merge the fate tests as well tomorrow or on Saturday when I'll > have time to quickly fix bugs which appear on platforms I haven't tested > the encoder on. Hopefully none, but you never know. Sure, makes sense. In case you don't find time nor devices for those tests, Michael seems to have tested on a fair number of archs: "tested on mips/arm/x86 linux and mingw32/64" -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Bonk decoder and demuxer
> > > On 5/5/16, Piotr Bandurski wrote: > > >> > > > > > > > > Improved version attached. > > >> > > > > > >> > > > I found another bug, this time in lossy mode - the file encoded as > > >> > > > "joint stereo" decodes after a few seconds into noise: > > >> > > > > > >> > > > https://www.datafilehost.com/d/c2e8b332 > > >> > > > > >> > > here are a few more samples: > > >> > > > > >> > > https://www.datafilehost.com/d/e4825eb4 > > >> > > > > >> > > quantization: 1.15 > > >> > > downsampling ratio: 1:1/2:1/3:1/10:1 > > >> > > predictor size: 282 > > >> > > enable join stereo > > >> > > > > >> > > > > >> > > in file "down_2_1.bonk" noise stars around 2:30 > > >> > > > >> > hmm it has actually not much to do with "join stereo" option, because > > >> > the same problem happens with mono files: > > >> > > > >> > https://www.datafilehost.com/d/09128a25 > > >> > > >> these mono files hangs with ffmpeg's bonk decoder: > > >> > > >> https://www.datafilehost.com/d/b94fd994 > > > > > > there is actually no hang, I used wrong binary for the test (with applied > > > v1 > > > version of your patch, so it's fixed) > > > > I fixed hangs/crashes but cant locate noise bug anywhere. > > It must be a bug in fre:ac implementation - I located another bug with > lossless 6khz file with predictor set to 512 > fre:ac file decodes into noise with bonk and ffmpeg. > > I created similar sample with bonk (-l -s 512) and it decodes correctly with > ffmpeg. > > There is also some unrelated thing - bonk encoder doesn't like wav files > generated by ffmpeg, but I don't know if this > is a bug in ffmpeg or bonk. > > so summarizing - LGTM from me for your decoder. I was able to isolate this and it looks like it's really a bug in encoder (see "bonkdec_bug_qualization_1_15_down_10_1_pred_282.wav") just original decoder is able to better handle this https://www.datafilehost.com/d/8ca9e3c1 qualization 1.15 downsampling 10:1 predictor ... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 57/57] support for matrox m703 mpeg-2
On Fri, May 06, 2016 at 11:26:04AM +0200, Piotr Bandurski wrote: > > file attached but i think there is something wrong with the encoder > > used, the files do not seem to contain enough non zero bits to > > be able to contain full yuv422 10bit > > so i am not sure this will resolve this > > ok, encoded it to m101 10bit: > > https://www.datafilehost.com/d/119d82c3 thanks, this helped alot should be fixed the encoder though or something between decoder or encoder isnt just encoding this data but smearing and messing it up [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] vf_colorspace: add const to yuv_stride[] argument in DSP functions.
---
libavfilter/colorspacedsp.h | 10 +-
libavfilter/colorspacedsp_template.c | 6 +++---
libavfilter/colorspacedsp_yuv2yuv_template.c | 4 ++--
libavfilter/x86/colorspacedsp_init.c | 8
4 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/libavfilter/colorspacedsp.h b/libavfilter/colorspacedsp.h
index 2ca7b19..7a64f9d 100644
--- a/libavfilter/colorspacedsp.h
+++ b/libavfilter/colorspacedsp.h
@@ -25,20 +25,20 @@
#include
typedef void (*yuv2rgb_fn)(int16_t *rgb[3], ptrdiff_t rgb_stride,
- uint8_t *yuv[3], ptrdiff_t yuv_stride[3],
+ uint8_t *yuv[3], const ptrdiff_t yuv_stride[3],
int w, int h, const int16_t yuv2rgb_coeffs[3][3][8],
const int16_t yuv_offset[8]);
-typedef void (*rgb2yuv_fn)(uint8_t *yuv[3], ptrdiff_t yuv_stride[3],
+typedef void (*rgb2yuv_fn)(uint8_t *yuv[3], const ptrdiff_t yuv_stride[3],
int16_t *rgb[3], ptrdiff_t rgb_stride,
int w, int h, const int16_t rgb2yuv_coeffs[3][3][8],
const int16_t yuv_offset[8]);
-typedef void (*rgb2yuv_fsb_fn)(uint8_t *yuv[3], ptrdiff_t yuv_stride[3],
+typedef void (*rgb2yuv_fsb_fn)(uint8_t *yuv[3], const ptrdiff_t yuv_stride[3],
int16_t *rgb[3], ptrdiff_t rgb_stride,
int w, int h, const int16_t
rgb2yuv_coeffs[3][3][8],
const int16_t yuv_offset[8],
int *rnd[3][2]);
-typedef void (*yuv2yuv_fn)(uint8_t *yuv_out[3], ptrdiff_t yuv_out_stride[3],
- uint8_t *yuv_in[3], ptrdiff_t yuv_in_stride[3],
+typedef void (*yuv2yuv_fn)(uint8_t *yuv_out[3], const ptrdiff_t
yuv_out_stride[3],
+ uint8_t *yuv_in[3], const ptrdiff_t
yuv_in_stride[3],
int w, int h, const int16_t yuv2yuv_coeffs[3][3][8],
const int16_t yuv_offset[2][8]);
diff --git a/libavfilter/colorspacedsp_template.c
b/libavfilter/colorspacedsp_template.c
index db4a8d2..53ac0d7 100644
--- a/libavfilter/colorspacedsp_template.c
+++ b/libavfilter/colorspacedsp_template.c
@@ -52,7 +52,7 @@
#endif
static void fn(yuv2rgb)(int16_t *rgb[3], ptrdiff_t rgb_stride,
-uint8_t *_yuv[3], ptrdiff_t yuv_stride[3],
+uint8_t *_yuv[3], const ptrdiff_t yuv_stride[3],
int w, int h, const int16_t yuv2rgb_coeffs[3][3][8],
const int16_t yuv_offset[8])
{
@@ -127,7 +127,7 @@ static void fn(yuv2rgb)(int16_t *rgb[3], ptrdiff_t
rgb_stride,
}
}
-static void fn(rgb2yuv)(uint8_t *_yuv[3], ptrdiff_t yuv_stride[3],
+static void fn(rgb2yuv)(uint8_t *_yuv[3], const ptrdiff_t yuv_stride[3],
int16_t *rgb[3], ptrdiff_t s,
int w, int h, const int16_t rgb2yuv_coeffs[3][3][8],
const int16_t yuv_offset[8])
@@ -205,7 +205,7 @@ static void fn(rgb2yuv)(uint8_t *_yuv[3], ptrdiff_t
yuv_stride[3],
* the rounding error is distributed over the neighbouring pixels:
*2: 7/16th, 3: 3/16th, 4: 5/16th and 5: 1/16th
*/
-static void fn(rgb2yuv_fsb)(uint8_t *_yuv[3], ptrdiff_t yuv_stride[3],
+static void fn(rgb2yuv_fsb)(uint8_t *_yuv[3], const ptrdiff_t yuv_stride[3],
int16_t *rgb[3], ptrdiff_t s,
int w, int h, const int16_t
rgb2yuv_coeffs[3][3][8],
const int16_t yuv_offset[8],
diff --git a/libavfilter/colorspacedsp_yuv2yuv_template.c
b/libavfilter/colorspacedsp_yuv2yuv_template.c
index 8b0d33a..3fae38c 100644
--- a/libavfilter/colorspacedsp_yuv2yuv_template.c
+++ b/libavfilter/colorspacedsp_yuv2yuv_template.c
@@ -37,8 +37,8 @@
#define fn2(a,b,c,d) fn3(a,b,c,d)
#define fn(a) fn2(a, IN_BIT_DEPTH, OUT_BIT_DEPTH, ss)
-static void fn(yuv2yuv)(uint8_t *_dst[3], ptrdiff_t dst_stride[3],
-uint8_t *_src[3], ptrdiff_t src_stride[3],
+static void fn(yuv2yuv)(uint8_t *_dst[3], const ptrdiff_t dst_stride[3],
+uint8_t *_src[3], const ptrdiff_t src_stride[3],
int w, int h, const int16_t c[3][3][8],
const int16_t yuv_offset[2][8])
{
diff --git a/libavfilter/x86/colorspacedsp_init.c
b/libavfilter/x86/colorspacedsp_init.c
index 78d34bc..5515ab8 100644
--- a/libavfilter/x86/colorspacedsp_init.c
+++ b/libavfilter/x86/colorspacedsp_init.c
@@ -23,8 +23,8 @@
#include "libavfilter/colorspacedsp.h"
#define decl_yuv2yuv_fn(t) \
-void ff_yuv2yuv_##t##_sse2(uint8_t *yuv_out[3], ptrdiff_t yuv_out_stride[3], \
- uint8_t *yuv_in[3], ptrdiff_t yuv_in_stride[3], \
+void ff_yuv2yuv_##t##_sse2(uint8_t *yuv_out[3], const ptrdiff_t
yuv_out_stride[3], \
+ uint8_t *yuv_in[3], con
Re: [FFmpeg-devel] [PATCH] vf_colorspace: add floyd-steinberg dithering option to full conversion.
Hi,
On Thu, May 5, 2016 at 8:16 AM, Michael Niedermayer
wrote:
> On Tue, May 03, 2016 at 01:53:42PM -0400, Ronald S. Bultje wrote:
> > ---
> > doc/filters.texi | 13
> > libavfilter/colorspacedsp.c | 12
> > libavfilter/colorspacedsp.h | 6 ++
> > libavfilter/colorspacedsp_template.c | 128
> +++
> > libavfilter/vf_colorspace.c | 58 +++-
> > 5 files changed, 214 insertions(+), 3 deletions(-)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index b17b115..98a002b 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -5104,6 +5104,19 @@ YUV 4:4:4 planar 12-bits
> > Do a fast conversion, which skips gamma/primary correction. This will
> take
> > significantly less CPU, but will be mathematically incorrect. To get
> output
> > compatible with that produced by the colormatrix filter, use fast=1.
> > +
> > +@item dither
> > +Specify dithering mode.
> > +
> > +The accepted values are:
> > +@table @samp
> > +@item none
> > +No dithering
> > +
> > +@item fsb
> > +Floyd-Steinberg dithering
> > +@end table
> > +
> > @end table
> >
> > The filter converts the transfer characteristics, color space and color
> > diff --git a/libavfilter/colorspacedsp.c b/libavfilter/colorspacedsp.c
> > index d4c43c3..f95805b 100644
> > --- a/libavfilter/colorspacedsp.c
> > +++ b/libavfilter/colorspacedsp.c
> > @@ -20,6 +20,9 @@
> >
> > #include "colorspacedsp.h"
> >
>
> > +/*
> > + * SS_W/H are synonyms for AVPixFmtDescriptor->log2_chroma_w/h.
>
> doesnt explain what SS stands for, that makes this harder to remember
>
Fixed.
> @@ -114,6 +117,15 @@ void ff_colorspacedsp_init(ColorSpaceDSPContext *dsp)
> > init_rgb2yuv_fn(1, 10);
> > init_rgb2yuv_fn(2, 12);
> >
> > +#define init_rgb2yuv_fsb_fn(idx, bit) \
> > +dsp->rgb2yuv_fsb[idx][0] = rgb2yuv_fsb_444p##bit##_c; \
> > +dsp->rgb2yuv_fsb[idx][1] = rgb2yuv_fsb_422p##bit##_c; \
> > +dsp->rgb2yuv_fsb[idx][2] = rgb2yuv_fsb_420p##bit##_c
> > +
> > +init_rgb2yuv_fsb_fn(0, 8);
> > +init_rgb2yuv_fsb_fn(1, 10);
> > +init_rgb2yuv_fsb_fn(2, 12);
>
> is there a plan for bit depth other than these and subsamplings the
> than these ?
>
For bit depth: I currently don't need more, but I see no reason why we
wouldn't eventually want to support up to 14 here (which is the hevc/h264
upper limit, right?).
for chroma subsamplings: not sure. My feeling is that this should address
most real-world needs, but this is obviously hard to say. I think if we
want more, we should simply fix the indexing into this array in
vf_colorspace.c from being hardcoded into working only for 444/422/420 into
becoming a real AV_PIX_FMT_* <-> internal-enum mapping.
0,1,2 is bad, these should be named constants/enums for the subsamplings
> or maybe a 2d array
>
Enum done, but in separate patch.
> diff --git a/libavfilter/colorspacedsp.h b/libavfilter/colorspacedsp.h
> > index 4e70c6c..2ca7b19 100644
> > --- a/libavfilter/colorspacedsp.h
> > +++ b/libavfilter/colorspacedsp.h
> > @@ -32,6 +32,11 @@ typedef void (*rgb2yuv_fn)(uint8_t *yuv[3], ptrdiff_t
> yuv_stride[3],
> > int16_t *rgb[3], ptrdiff_t rgb_stride,
> > int w, int h, const int16_t
> rgb2yuv_coeffs[3][3][8],
> > const int16_t yuv_offset[8]);
>
> > +typedef void (*rgb2yuv_fsb_fn)(uint8_t *yuv[3], ptrdiff_t yuv_stride[3],
> > + int16_t *rgb[3], ptrdiff_t rgb_stride,
> > + int w, int h, const int16_t
> rgb2yuv_coeffs[3][3][8],
> > + const int16_t yuv_offset[8],
> > + int *rnd[3][2]);
>
> lacks documentation
> the strides also can be const as well as rgb
>
>
> > typedef void (*yuv2yuv_fn)(uint8_t *yuv_out[3], ptrdiff_t
> yuv_out_stride[3],
> > uint8_t *yuv_in[3], ptrdiff_t
> yuv_in_stride[3],
>
> off topic but, same here
Both done, as a separate patch also.
> int w, int h, const int16_t
> yuv2yuv_coeffs[3][3][8],
> > @@ -40,6 +45,7 @@ typedef void (*yuv2yuv_fn)(uint8_t *yuv_out[3],
> ptrdiff_t yuv_out_stride[3],
> > typedef struct ColorSpaceDSPContext {
> > yuv2rgb_fn yuv2rgb[3 /* 0: 8bit, 1: 10bit, 2: 12bit */][3 /* 0:
> 444, 1: 422, 2: 420 */];
> > rgb2yuv_fn rgb2yuv[3 /* 0: 8bit, 1: 10bit, 2: 12bit */][3 /* 0:
> 444, 1: 422, 2: 420 */];
> > +rgb2yuv_fsb_fn rgb2yuv_fsb[3 /* 0: 8bit, 1: 10bit, 2: 12bit */][3
> /* 0: 444, 1: 422, 2: 420 */];
> > yuv2yuv_fn yuv2yuv[3 /* in_depth */][3 /* out_depth */][3 /* 0:
> 444, 1: 422, 2: 420 */];
> >
> > void (*multiply3x3)(int16_t *data[3], ptrdiff_t stride,
> > diff --git a/libavfilter/colorspacedsp_template.c
> b/libavfilter/colorspacedsp_template.c
> > index f225391..db4a8d2 100644
> > --- a/libavfilter/colorspacedsp_template.c
> > +++ b/libavfilter/colorspacedsp_template.c
[FFmpeg-devel] [PATCH 3/3] vf_colorspace: use enums for bpp/subsampling array indices.
Also add some documentation for each function to colorspacedsp.h.
---
libavfilter/colorspacedsp.c | 78 ++--
libavfilter/colorspacedsp.h | 31 --
libavfilter/x86/colorspacedsp_init.c | 64 ++---
3 files changed, 98 insertions(+), 75 deletions(-)
diff --git a/libavfilter/colorspacedsp.c b/libavfilter/colorspacedsp.c
index 735e403..b8ba5c0 100644
--- a/libavfilter/colorspacedsp.c
+++ b/libavfilter/colorspacedsp.c
@@ -100,45 +100,45 @@ static void multiply3x3_c(int16_t *buf[3], ptrdiff_t
stride,
void ff_colorspacedsp_init(ColorSpaceDSPContext *dsp)
{
-#define init_yuv2rgb_fn(idx, bit) \
-dsp->yuv2rgb[idx][0] = yuv2rgb_444p##bit##_c; \
-dsp->yuv2rgb[idx][1] = yuv2rgb_422p##bit##_c; \
-dsp->yuv2rgb[idx][2] = yuv2rgb_420p##bit##_c
-
-init_yuv2rgb_fn(0, 8);
-init_yuv2rgb_fn(1, 10);
-init_yuv2rgb_fn(2, 12);
-
-#define init_rgb2yuv_fn(idx, bit) \
-dsp->rgb2yuv[idx][0] = rgb2yuv_444p##bit##_c; \
-dsp->rgb2yuv[idx][1] = rgb2yuv_422p##bit##_c; \
-dsp->rgb2yuv[idx][2] = rgb2yuv_420p##bit##_c
-
-init_rgb2yuv_fn(0, 8);
-init_rgb2yuv_fn(1, 10);
-init_rgb2yuv_fn(2, 12);
-
-#define init_rgb2yuv_fsb_fn(idx, bit) \
-dsp->rgb2yuv_fsb[idx][0] = rgb2yuv_fsb_444p##bit##_c; \
-dsp->rgb2yuv_fsb[idx][1] = rgb2yuv_fsb_422p##bit##_c; \
-dsp->rgb2yuv_fsb[idx][2] = rgb2yuv_fsb_420p##bit##_c
-
-init_rgb2yuv_fsb_fn(0, 8);
-init_rgb2yuv_fsb_fn(1, 10);
-init_rgb2yuv_fsb_fn(2, 12);
-
-#define init_yuv2yuv_fn(idx1, idx2, bit1, bit2) \
-dsp->yuv2yuv[idx1][idx2][0] = yuv2yuv_444p##bit1##to##bit2##_c; \
-dsp->yuv2yuv[idx1][idx2][1] = yuv2yuv_422p##bit1##to##bit2##_c; \
-dsp->yuv2yuv[idx1][idx2][2] = yuv2yuv_420p##bit1##to##bit2##_c
-#define init_yuv2yuv_fns(idx1, bit1) \
-init_yuv2yuv_fn(idx1, 0, bit1, 8); \
-init_yuv2yuv_fn(idx1, 1, bit1, 10); \
-init_yuv2yuv_fn(idx1, 2, bit1, 12)
-
-init_yuv2yuv_fns(0, 8);
-init_yuv2yuv_fns(1, 10);
-init_yuv2yuv_fns(2, 12);
+#define init_yuv2rgb_fn(bit) \
+dsp->yuv2rgb[BPP_##bit][SS_444] = yuv2rgb_444p##bit##_c; \
+dsp->yuv2rgb[BPP_##bit][SS_422] = yuv2rgb_422p##bit##_c; \
+dsp->yuv2rgb[BPP_##bit][SS_420] = yuv2rgb_420p##bit##_c
+
+init_yuv2rgb_fn( 8);
+init_yuv2rgb_fn(10);
+init_yuv2rgb_fn(12);
+
+#define init_rgb2yuv_fn(bit) \
+dsp->rgb2yuv[BPP_##bit][SS_444] = rgb2yuv_444p##bit##_c; \
+dsp->rgb2yuv[BPP_##bit][SS_422] = rgb2yuv_422p##bit##_c; \
+dsp->rgb2yuv[BPP_##bit][SS_420] = rgb2yuv_420p##bit##_c
+
+init_rgb2yuv_fn( 8);
+init_rgb2yuv_fn(10);
+init_rgb2yuv_fn(12);
+
+#define init_rgb2yuv_fsb_fn(bit) \
+dsp->rgb2yuv_fsb[BPP_##bit][SS_444] = rgb2yuv_fsb_444p##bit##_c; \
+dsp->rgb2yuv_fsb[BPP_##bit][SS_422] = rgb2yuv_fsb_422p##bit##_c; \
+dsp->rgb2yuv_fsb[BPP_##bit][SS_420] = rgb2yuv_fsb_420p##bit##_c
+
+init_rgb2yuv_fsb_fn( 8);
+init_rgb2yuv_fsb_fn(10);
+init_rgb2yuv_fsb_fn(12);
+
+#define init_yuv2yuv_fn(idx1, bit1, bit2) \
+dsp->yuv2yuv[idx1][BPP_##bit2][SS_444] = yuv2yuv_444p##bit1##to##bit2##_c;
\
+dsp->yuv2yuv[idx1][BPP_##bit2][SS_422] = yuv2yuv_422p##bit1##to##bit2##_c;
\
+dsp->yuv2yuv[idx1][BPP_##bit2][SS_420] = yuv2yuv_420p##bit1##to##bit2##_c
+#define init_yuv2yuv_fns(bit1) \
+init_yuv2yuv_fn(BPP_##bit1, bit1, 8); \
+init_yuv2yuv_fn(BPP_##bit1, bit1, 10); \
+init_yuv2yuv_fn(BPP_##bit1, bit1, 12)
+
+init_yuv2yuv_fns( 8);
+init_yuv2yuv_fns(10);
+init_yuv2yuv_fns(12);
dsp->multiply3x3 = multiply3x3_c;
diff --git a/libavfilter/colorspacedsp.h b/libavfilter/colorspacedsp.h
index 7a64f9d..a81e4f0 100644
--- a/libavfilter/colorspacedsp.h
+++ b/libavfilter/colorspacedsp.h
@@ -42,12 +42,35 @@ typedef void (*yuv2yuv_fn)(uint8_t *yuv_out[3], const
ptrdiff_t yuv_out_stride[3
int w, int h, const int16_t yuv2yuv_coeffs[3][3][8],
const int16_t yuv_offset[2][8]);
+enum BitDepthIndex {
+BPP_8,
+BPP_10,
+BPP_12,
+NB_BPP,
+};
+
+enum ChromaSubsamplingIndex {
+SS_444,
+SS_422,
+SS_420,
+NB_SS,
+};
+
typedef struct ColorSpaceDSPContext {
-yuv2rgb_fn yuv2rgb[3 /* 0: 8bit, 1: 10bit, 2: 12bit */][3 /* 0: 444, 1:
422, 2: 420 */];
-rgb2yuv_fn rgb2yuv[3 /* 0: 8bit, 1: 10bit, 2: 12bit */][3 /* 0: 444, 1:
422, 2: 420 */];
-rgb2yuv_fsb_fn rgb2yuv_fsb[3 /* 0: 8bit, 1: 10bit, 2: 12bit */][3 /* 0:
444, 1: 422, 2: 420 */];
-yuv2yuv_fn yuv2yuv[3 /* in_depth */][3 /* out_depth */][3 /* 0: 444, 1:
422, 2: 420 */];
+/* Convert input YUV pixel buffer from a user into an internal, 15bpp array
+ * of intermediate RGB data. */
+yuv2rgb_fn yuv2rgb[NB_BPP][NB_SS];
+/* Convert intermediate RGB data (15bpp, internal format) into YUV data and
+ * store into user-provided output buffer */
+rgb2yuv_fn rgb2yuv[NB_BPP][NB_SS];
+/* Same as rgb2yuv(), but use floyd-steinberg dithering */
+
[FFmpeg-devel] [PATCH 1/3] vf_colorspace: add floyd-steinberg dithering option to full conversion.
---
doc/filters.texi | 13
libavfilter/colorspacedsp.c | 13
libavfilter/colorspacedsp.h | 6 ++
libavfilter/colorspacedsp_template.c | 128 +++
libavfilter/vf_colorspace.c | 64 +-
5 files changed, 221 insertions(+), 3 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index b17b115..98a002b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -5104,6 +5104,19 @@ YUV 4:4:4 planar 12-bits
Do a fast conversion, which skips gamma/primary correction. This will take
significantly less CPU, but will be mathematically incorrect. To get output
compatible with that produced by the colormatrix filter, use fast=1.
+
+@item dither
+Specify dithering mode.
+
+The accepted values are:
+@table @samp
+@item none
+No dithering
+
+@item fsb
+Floyd-Steinberg dithering
+@end table
+
@end table
The filter converts the transfer characteristics, color space and color
diff --git a/libavfilter/colorspacedsp.c b/libavfilter/colorspacedsp.c
index d4c43c3..735e403 100644
--- a/libavfilter/colorspacedsp.c
+++ b/libavfilter/colorspacedsp.c
@@ -20,6 +20,10 @@
#include "colorspacedsp.h"
+/*
+ * SS_W/H stands for "subsampling_w/h"
+ * it's analogous to AVPixFmtDescriptor->log2_chroma_w/h.
+ */
#define SS_W 0
#define SS_H 0
@@ -114,6 +118,15 @@ void ff_colorspacedsp_init(ColorSpaceDSPContext *dsp)
init_rgb2yuv_fn(1, 10);
init_rgb2yuv_fn(2, 12);
+#define init_rgb2yuv_fsb_fn(idx, bit) \
+dsp->rgb2yuv_fsb[idx][0] = rgb2yuv_fsb_444p##bit##_c; \
+dsp->rgb2yuv_fsb[idx][1] = rgb2yuv_fsb_422p##bit##_c; \
+dsp->rgb2yuv_fsb[idx][2] = rgb2yuv_fsb_420p##bit##_c
+
+init_rgb2yuv_fsb_fn(0, 8);
+init_rgb2yuv_fsb_fn(1, 10);
+init_rgb2yuv_fsb_fn(2, 12);
+
#define init_yuv2yuv_fn(idx1, idx2, bit1, bit2) \
dsp->yuv2yuv[idx1][idx2][0] = yuv2yuv_444p##bit1##to##bit2##_c; \
dsp->yuv2yuv[idx1][idx2][1] = yuv2yuv_422p##bit1##to##bit2##_c; \
diff --git a/libavfilter/colorspacedsp.h b/libavfilter/colorspacedsp.h
index 4e70c6c..2ca7b19 100644
--- a/libavfilter/colorspacedsp.h
+++ b/libavfilter/colorspacedsp.h
@@ -32,6 +32,11 @@ typedef void (*rgb2yuv_fn)(uint8_t *yuv[3], ptrdiff_t
yuv_stride[3],
int16_t *rgb[3], ptrdiff_t rgb_stride,
int w, int h, const int16_t rgb2yuv_coeffs[3][3][8],
const int16_t yuv_offset[8]);
+typedef void (*rgb2yuv_fsb_fn)(uint8_t *yuv[3], ptrdiff_t yuv_stride[3],
+ int16_t *rgb[3], ptrdiff_t rgb_stride,
+ int w, int h, const int16_t
rgb2yuv_coeffs[3][3][8],
+ const int16_t yuv_offset[8],
+ int *rnd[3][2]);
typedef void (*yuv2yuv_fn)(uint8_t *yuv_out[3], ptrdiff_t yuv_out_stride[3],
uint8_t *yuv_in[3], ptrdiff_t yuv_in_stride[3],
int w, int h, const int16_t yuv2yuv_coeffs[3][3][8],
@@ -40,6 +45,7 @@ typedef void (*yuv2yuv_fn)(uint8_t *yuv_out[3], ptrdiff_t
yuv_out_stride[3],
typedef struct ColorSpaceDSPContext {
yuv2rgb_fn yuv2rgb[3 /* 0: 8bit, 1: 10bit, 2: 12bit */][3 /* 0: 444, 1:
422, 2: 420 */];
rgb2yuv_fn rgb2yuv[3 /* 0: 8bit, 1: 10bit, 2: 12bit */][3 /* 0: 444, 1:
422, 2: 420 */];
+rgb2yuv_fsb_fn rgb2yuv_fsb[3 /* 0: 8bit, 1: 10bit, 2: 12bit */][3 /* 0:
444, 1: 422, 2: 420 */];
yuv2yuv_fn yuv2yuv[3 /* in_depth */][3 /* out_depth */][3 /* 0: 444, 1:
422, 2: 420 */];
void (*multiply3x3)(int16_t *data[3], ptrdiff_t stride,
diff --git a/libavfilter/colorspacedsp_template.c
b/libavfilter/colorspacedsp_template.c
index f225391..db4a8d2 100644
--- a/libavfilter/colorspacedsp_template.c
+++ b/libavfilter/colorspacedsp_template.c
@@ -199,6 +199,134 @@ static void fn(rgb2yuv)(uint8_t *_yuv[3], ptrdiff_t
yuv_stride[3],
}
}
+/* floyd-steinberg dithering - for any mid-top pixel A in a 3x2 block of
pixels:
+ *1 A 2
+ *3 4 5
+ * the rounding error is distributed over the neighbouring pixels:
+ *2: 7/16th, 3: 3/16th, 4: 5/16th and 5: 1/16th
+ */
+static void fn(rgb2yuv_fsb)(uint8_t *_yuv[3], ptrdiff_t yuv_stride[3],
+int16_t *rgb[3], ptrdiff_t s,
+int w, int h, const int16_t
rgb2yuv_coeffs[3][3][8],
+const int16_t yuv_offset[8],
+int *rnd_scratch[3][2])
+{
+pixel **yuv = (pixel **) _yuv;
+pixel *yuv0 = yuv[0], *yuv1 = yuv[1], *yuv2 = yuv[2];
+const int16_t *rgb0 = rgb[0], *rgb1 = rgb[1], *rgb2 = rgb[2];
+int y, x;
+const int sh = 29 - BIT_DEPTH;
+const int rnd = 1 << (sh - 1);
+int cry = rgb2yuv_coeffs[0][0][0];
+int cgy = rgb2yuv_coeffs[0][1][0];
+int cby = rgb2yuv_coeffs[0][2][0];
+int cru = rgb2yuv_coeffs[1][0][0];
+int cgu = rgb2yuv_coeffs[1][1][0];
+int cburv = rgb2yuv_coeffs[1][2][0];
+i
[FFmpeg-devel] [PATCH] fate: add matroska-remux test.
This tests automatic insertion of the vp9_superframe BSF as well as ensuring that the colorspace properties in the video header can be modified when remuxing (-c:v copy). --- tests/Makefile | 1 + tests/fate/matroska.mak | 9 + 2 files changed, 10 insertions(+) create mode 100644 tests/fate/matroska.mak diff --git a/tests/Makefile b/tests/Makefile index 6fef0cd..5c5cfee 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -142,6 +142,7 @@ include $(SRC_PATH)/tests/fate/libavutil.mak include $(SRC_PATH)/tests/fate/libswresample.mak include $(SRC_PATH)/tests/fate/lossless-audio.mak include $(SRC_PATH)/tests/fate/lossless-video.mak +include $(SRC_PATH)/tests/fate/matroska.mak include $(SRC_PATH)/tests/fate/microsoft.mak include $(SRC_PATH)/tests/fate/monkeysaudio.mak include $(SRC_PATH)/tests/fate/mp3.mak diff --git a/tests/fate/matroska.mak b/tests/fate/matroska.mak new file mode 100644 index 000..7c69d9f --- /dev/null +++ b/tests/fate/matroska.mak @@ -0,0 +1,9 @@ +# This tests that the matroska demuxer supports modifying the colorspace +# properties in remuxing (-c:v copy) +# It also tests automatic insertion of the vp9_superframe bitstream filter +FATE_MATROSKA-$(call DEMMUX, MATROSKA, MATROSKA) += fate-matroska-remux +fate-matroska-remux: CMD = md5 -i $(TARGET_SAMPLES)/vp9-test-vectors/vp90-2-2pass-akiyo.webm -color_trc 4 -c:v copy -fflags +bitexact -strict -2 -f matroska +fate-matroska-remux: CMP = oneline +fate-matroska-remux: REF = 2765be5eff4fde7332278a81a7d4e13c + +FATE_SAMPLES_AVCONV += $(FATE_MATROSKA-yes) -- 2.8.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: copy color properties in case of -c:v copy.
Hi, On Tue, May 3, 2016 at 10:21 PM, Michael Niedermayer wrote: > On Tue, May 03, 2016 at 08:58:07PM -0400, Ronald S. Bultje wrote: > > Hi, > > > > On Tue, May 3, 2016 at 8:29 PM, Michael Niedermayer > > > wrote: > > > > > On Tue, May 03, 2016 at 03:21:00PM -0400, Ronald S. Bultje wrote: > > > > I have no idea why the first hunk uses ost->enc_ctx, because as far > as > > > > I understand, that is never used in case of -c:v copy, but this code > > > > block is only entered if encoding_needed=0, which means > stream_copy=1. > > > > > > when the code was added it was followed by a > > > ret = avcodec_copy_context(ost->st->codec, ost->enc_ctx); > > > later that was removed > > > > > > > > > do you have a testcase for which this hunk makes a differnce? > > > > > > ffmpeg -i any_webm_file -color_trc 4 -strict -2 -c:v copy out.webm > > > > Will set the colorspace element in the muxer after, but not before, this > > patch. > > patch should be ok > can you add a testcase for this to fate ? > so this doesnt break, nothing in fate tests this > even commenting the code out entirely made fate still pass Patch for that sent separately. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add M101 decoder
On Thu, May 05, 2016 at 07:45:47PM +0200, Michael Niedermayer wrote: > TODO: find out which LSB for 10bit go where > > Signed-off-by: Michael Niedermayer > --- > libavcodec/Makefile |1 + > libavcodec/allcodecs.c |1 + > libavcodec/avcodec.h|1 + > libavcodec/codec_desc.c |7 +++ > libavcodec/m101.c | 120 > +++ > 5 files changed, 130 insertions(+) > create mode 100644 libavcodec/m101.c fixed various issues, bumped version applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vf_colorspace: make whitepoint adaptation mode configurable.
Also add von kries whitepoint adaptation, and add 'identity' to turn
whitepoint adaptation off.
---
doc/filters.texi| 15 +++
libavfilter/vf_colorspace.c | 39 ---
2 files changed, 47 insertions(+), 7 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 98a002b..beee1cc 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -5117,6 +5117,21 @@ No dithering
Floyd-Steinberg dithering
@end table
+@item wpadapt
+Whitepoint adaptation mode.
+
+The accepted values are:
+@table @samp
+@item bradford
+Bradford whitepoint adaptation
+
+@item vonkries
+von Kries whitepoint adaptation
+
+@item identity
+identity whitepoint adaptation (i.e. no whitepoint adaptation)
+@end table
+
@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 0b6fe32..d119e36 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -59,6 +59,14 @@ enum Whitepoint {
WP_NB,
};
+enum WhitepointAdaptation {
+WP_ADAPT_BRADFORD,
+WP_ADAPT_VON_KRIES,
+NB_WP_ADAPT_NON_IDENTITY,
+WP_ADAPT_IDENTITY = NB_WP_ADAPT_NON_IDENTITY,
+NB_WP_ADAPT,
+};
+
static const enum AVColorTransferCharacteristic default_trc[CS_NB + 1] = {
[CS_UNSPECIFIED] = AVCOL_TRC_UNSPECIFIED,
[CS_BT470M] = AVCOL_TRC_GAMMA22,
@@ -128,6 +136,7 @@ typedef struct ColorSpaceContext {
enum AVPixelFormat in_format, user_format;
int fast_mode;
enum DitherMode dither;
+enum WhitepointAdaptation wp_adapt;
int16_t *rgb[3];
ptrdiff_t rgb_stride;
@@ -379,14 +388,21 @@ static void mul3x3(double dst[3][3], const double
src1[3][3], const double src2[
* See http://www.brucelindbloom.com/index.html?Eqn_ChromAdapt.html
* This function uses the Bradford mechanism.
*/
-static void fill_whitepoint_conv_table(double out[3][3],
+static void fill_whitepoint_conv_table(double out[3][3], enum
WhitepointAdaptation wp_adapt,
enum Whitepoint src, enum Whitepoint
dst)
{
-static const double ma[3][3] = {
-{ 0.8951, 0.2664, -0.1614 },
-{ -0.7502, 1.7135, 0.0367 },
-{ 0.0389, -0.0685, 1.0296 },
+static const double ma_tbl[NB_WP_ADAPT_NON_IDENTITY][3][3] = {
+[WP_ADAPT_BRADFORD] = {
+{ 0.8951, 0.2664, -0.1614 },
+{ -0.7502, 1.7135, 0.0367 },
+{ 0.0389, -0.0685, 1.0296 },
+}, [WP_ADAPT_VON_KRIES] = {
+{ 0.40024, 0.70760, -0.08081 },
+{ -0.22630, 1.16532, 0.04570 },
+{ 0.0, 0.0, 0.91822 },
+},
};
+const double (*ma)[3] = ma_tbl[wp_adapt];
const struct WhitepointCoefficients *wp_src =
&whitepoint_coefficients[src];
double zw_src = 1.0 - wp_src->xw - wp_src->yw;
const struct WhitepointCoefficients *wp_dst =
&whitepoint_coefficients[dst];
@@ -631,10 +647,11 @@ static int create_filtergraph(AVFilterContext *ctx,
fill_rgb2xyz_table(s->out_primaries, rgb2xyz);
invert_matrix3x3(rgb2xyz, xyz2rgb);
fill_rgb2xyz_table(s->in_primaries, rgb2xyz);
-if (s->out_primaries->wp != s->in_primaries->wp) {
+if (s->out_primaries->wp != s->in_primaries->wp &&
+s->wp_adapt != WP_ADAPT_IDENTITY) {
double wpconv[3][3], tmp[3][3];
-fill_whitepoint_conv_table(wpconv, s->in_primaries->wp,
+fill_whitepoint_conv_table(wpconv, s->wp_adapt,
s->in_primaries->wp,
s->out_primaries->wp);
mul3x3(tmp, rgb2xyz, wpconv);
mul3x3(rgb2rgb, tmp, xyz2rgb);
@@ -1098,12 +1115,20 @@ static const AVOption colorspace_options[] = {
{ "fast", "Ignore primary chromaticity and gamma correction",
OFFSET(fast_mode), AV_OPT_TYPE_BOOL, { .i64 = 0},
0, 1, FLAGS },
+
{ "dither", "Dithering mode",
OFFSET(dither), AV_OPT_TYPE_INT, { .i64 = DITHER_NONE },
DITHER_NONE, DITHER_NB - 1, FLAGS, "dither" },
ENUM("none", DITHER_NONE, "dither"),
ENUM("fsb", DITHER_FSB, "dither"),
+{ "wpadapt", "Whitepoint adaptation method",
+ OFFSET(wp_adapt), AV_OPT_TYPE_INT, { .i64 = WP_ADAPT_BRADFORD },
+ WP_ADAPT_BRADFORD, NB_WP_ADAPT - 1, FLAGS, "wpadapt" },
+ENUM("bradford", WP_ADAPT_BRADFORD, "wpadapt"),
+ENUM("vonkries", WP_ADAPT_VON_KRIES, "wpadapt"),
+ENUM("identity", WP_ADAPT_IDENTITY, "wpadapt"),
+
{ NULL }
};
--
2.8.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] vf_colorspace: add floyd-steinberg dithering option to full conversion.
On Fri, May 06, 2016 at 09:06:01AM -0400, Ronald S. Bultje wrote: > --- > doc/filters.texi | 13 > libavfilter/colorspacedsp.c | 13 > libavfilter/colorspacedsp.h | 6 ++ > libavfilter/colorspacedsp_template.c | 128 > +++ > libavfilter/vf_colorspace.c | 64 +- > 5 files changed, 221 insertions(+), 3 deletions(-) i cant test this: Applying: vf_colorspace: add floyd-steinberg dithering option to full conversion. fatal: sha1 information is lacking or useless (libavfilter/vf_colorspace.c). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 vf_colorspace: add floyd-steinberg dithering option to full conversion. When you have resolved this problem run "git am --resolved". If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] configure: Enable GCC vectorization on ≥4.9
On Fri, May 06, 2016 at 12:08:14PM +0200, Hendrik Leppkes wrote: > On Tue, Feb 9, 2016 at 1:28 AM, Timothy Gu wrote: > > On Sun, Jan 31, 2016 at 3:38 PM Timothy Gu wrote: > >> > >> On Sat, Jan 30, 2016 at 07:27:22PM +, Derek Buitenhuis wrote: > >> > On 1/30/2016 7:15 PM, Timothy Gu wrote: > >> > > FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1. > >> > > >> > Perhaps this should be restricted to x86? > >> > >> Fair enough. > > > > > > Pushed. > > > > Just to document it, this has caused build breakage in various > scenarios, even in GCC 5.3 (6.1 not tested). > > The latest reported on IRC just today here: > libavcodec/sbrdsp.c: In function 'sbr_neg_odd_64_c': > libavcodec/sbrdsp.c:47:13: internal compiler error: in > vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596 > static void sbr_neg_odd_64_c(float *x) > > There are various other cases which usually involve inline asm when > building with SIMD (ie. --cpu=host) and the optimizer running out of > registers, for example: > libavcodec/x86/cabac.h:192:5: error: 'asm' operand has impossible constraints > > IMHO this feature is not quite ready to be enabled unconditionally in > our code base, and we should re-evaluate this change. +1 i had a bad feeling since i saw the patch but failed to find a case that actually broke with a easy installable compiler at that time when i tested this back then ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h2645_parse: allow partial escaping
On Fri, May 6, 2016 at 4:30 PM, Hendrik Leppkes wrote: > This ports the fix from 033a533 to the new parser module in prepartion > of using it for the h264 decoder.h2645_parse: allow partial escaping Nevermind the broken message, already fixed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] h2645_parse: allow partial escaping
This ports the fix from 033a533 to the new parser module in prepartion
of using it for the h264 decoder.h2645_parse: allow partial escaping
---
libavcodec/h2645_parse.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index d9721a2..b9d9b48 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -38,7 +38,7 @@ int ff_h2645_extract_rbsp(const uint8_t *src, int length,
nal->skipped_bytes = 0;
#define STARTCODE_TEST \
if (i + 2 < length && src[i + 1] == 0 && src[i + 2] <= 3) { \
-if (src[i + 2] != 3) { \
+if (src[i + 2] != 3 && src[i + 2] != 0) { \
/* startcode, so we must be past the end */ \
length = i; \
} \
@@ -103,7 +103,7 @@ int ff_h2645_extract_rbsp(const uint8_t *src, int length,
if (src[si + 2] > 3) {
dst[di++] = src[si++];
dst[di++] = src[si++];
-} else if (src[si] == 0 && src[si + 1] == 0) {
+} else if (src[si] == 0 && src[si + 1] == 0 && src[si + 2] != 0) {
if (src[si + 2] == 3) { // escape
dst[di++] = 0;
dst[di++] = 0;
--
2.7.2.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] configure: Enable GCC vectorization on ≥4.9
On 5/6/2016 7:08 AM, Hendrik Leppkes wrote: > On Tue, Feb 9, 2016 at 1:28 AM, Timothy Gu wrote: >> On Sun, Jan 31, 2016 at 3:38 PM Timothy Gu wrote: >>> >>> On Sat, Jan 30, 2016 at 07:27:22PM +, Derek Buitenhuis wrote: On 1/30/2016 7:15 PM, Timothy Gu wrote: > FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1. Perhaps this should be restricted to x86? >>> >>> Fair enough. >> >> >> Pushed. >> > > Just to document it, this has caused build breakage in various > scenarios, even in GCC 5.3 (6.1 not tested). > > The latest reported on IRC just today here: > libavcodec/sbrdsp.c: In function 'sbr_neg_odd_64_c': > libavcodec/sbrdsp.c:47:13: internal compiler error: in > vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596 > static void sbr_neg_odd_64_c(float *x) What compile flags? How was ffmpeg configured? I can try to reproduce it and report the bug to gcc. > > There are various other cases which usually involve inline asm when > building with SIMD (ie. --cpu=host) and the optimizer running out of > registers, for example: > libavcodec/x86/cabac.h:192:5: error: 'asm' operand has impossible constraints > > IMHO this feature is not quite ready to be enabled unconditionally in > our code base, and we should re-evaluate this change. > > - Hendrik > ___ > 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
[FFmpeg-devel] [PATCH] vf_colorspace: fix range order.
---
libavfilter/vf_colorspace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index dd66a4e..7776a61 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -805,8 +805,8 @@ static int create_filtergraph(AVFilterContext *ctx,
s->yuv_offset[1][n] = off;
fill_rgb2yuv_table(s->out_lumacoef, rgb2yuv);
bits = 1 << (29 - out_desc->comp[0].depth);
-for (n = 0; n < 3; n++) {
-for (out_rng = s->out_y_rng, m = 0; m < 3; m++, out_rng =
s->out_uv_rng) {
+for (out_rng = s->out_y_rng, n = 0; n < 3; n++, out_rng =
s->out_uv_rng) {
+for (m = 0; m < 3; m++) {
s->rgb2yuv_coeffs[n][m][0] = lrint(bits * out_rng *
rgb2yuv[n][m] / 28672);
for (o = 1; o < 8; o++)
s->rgb2yuv_coeffs[n][m][o] =
s->rgb2yuv_coeffs[n][m][0];
--
2.8.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vf_colorspace: remove debug statement.
This always disabled lrgb2lrgb passthrough, which slightly decreases
performance.
---
libavfilter/vf_colorspace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index d119e36..dd66a4e 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -640,7 +640,7 @@ static int create_filtergraph(AVFilterContext *ctx,
return AVERROR(EINVAL);
}
s->lrgb2lrgb_passthrough = !memcmp(s->in_primaries, s->out_primaries,
- sizeof(*s->in_primaries)) && 0;
+ sizeof(*s->in_primaries));
if (!s->lrgb2lrgb_passthrough) {
double rgb2xyz[3][3], xyz2rgb[3][3], rgb2rgb[3][3];
--
2.8.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h2645_parse: allow partial escaping
On Fri, May 06, 2016 at 04:30:38PM +0200, Hendrik Leppkes wrote: > This ports the fix from 033a533 to the new parser module in prepartion > of using it for the h264 decoder.h2645_parse: allow partial escaping > --- > libavcodec/h2645_parse.c | 4 ++-- LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Patch] Add input swap functionality to movie filter (src_movie.c)
On 04.05.2016, at 17:01, "Felt, Patrick" wrote: > > On 5/4/16, 5:52 AM, "ffmpeg-devel on behalf of Clément Bœsch" > wrote: > >> >> [...] >>> +/* libavfilter documentation says that filter init will be called only >>> once. ffmpeg calls the init twice to enable it to validate >>> + * the complex filtering has the right input and output pads. this allows >>> us to bypass the first call if we've specified a stream >>> + * specifier string */ >>> +static int initRun=0; >>> +static int uninitRun=0; >> >> You're not allowed to do this, it belongs in the local context. > > I did realize that there will be issues if I tried to load the filter twice. > It wouldn’t function as expected with the current solution. The problem is > that ffmpeg calls init twice with two different contexts so any values I set > in the context are cleared on the second run. Indeed, the uninit() function > is called after the first round. Named Pipes don’t like being opened and > closed; the ffmpeg process on the other end terminates because the reader > left and sent an EOF. I need a reasonable way to prevent opening a pipe > twice. Just don't open it in init, but only when it's actually needed? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vf_colorspace: don't enable passthrough if bitdepth doesn't match.
---
libavfilter/vf_colorspace.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index 7776a61..f932ce9 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -754,7 +754,8 @@ static int create_filtergraph(AVFilterContext *ctx,
s->yuv2yuv_fastmode = s->rgb2rgb_passthrough && fmt_identical;
s->yuv2yuv_passthrough = s->yuv2yuv_fastmode && s->in_rng == s->out_rng &&
!memcmp(s->in_lumacoef, s->out_lumacoef,
- sizeof(*s->in_lumacoef));
+ sizeof(*s->in_lumacoef)) &&
+ in_desc->comp[0].depth == out_desc->comp[0].depth;
if (!s->yuv2yuv_passthrough) {
if (redo_yuv2rgb) {
double rgb2yuv[3][3], (*yuv2rgb)[3] = s->yuv2rgb_dbl_coeffs;
@@ -986,7 +987,9 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
td.in_ss_h = av_pix_fmt_desc_get(in->format)->log2_chroma_h;
td.out_ss_h = av_pix_fmt_desc_get(out->format)->log2_chroma_h;
if (s->yuv2yuv_passthrough) {
-av_frame_copy(out, in);
+res = av_frame_copy(out, in);
+if (res < 0)
+return res;
} else {
ctx->internal->execute(ctx, convert, &td, NULL,
FFMIN((in->height + 1) >> 1,
ctx->graph->nb_threads));
--
2.8.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_colorspace: remove debug statement.
Hi,
On Fri, May 6, 2016 at 12:02 PM, Ronald S. Bultje
wrote:
> This always disabled lrgb2lrgb passthrough, which slightly decreases
> performance.
> ---
> libavfilter/vf_colorspace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
> index d119e36..dd66a4e 100644
> --- a/libavfilter/vf_colorspace.c
> +++ b/libavfilter/vf_colorspace.c
> @@ -640,7 +640,7 @@ static int create_filtergraph(AVFilterContext *ctx,
> return AVERROR(EINVAL);
> }
> s->lrgb2lrgb_passthrough = !memcmp(s->in_primaries,
> s->out_primaries,
> - sizeof(*s->in_primaries)) && 0;
> + sizeof(*s->in_primaries));
> if (!s->lrgb2lrgb_passthrough) {
> double rgb2xyz[3][3], xyz2rgb[3][3], rgb2rgb[3][3];
Ignore this, this was a local tree quirk...
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] hevc: fix size condition in ptl parsing
When only one sublayer is present, no information is coded. Only when at least
two
are present, all 8 sublayers are written.
---
libavcodec/hevc_ps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index ce3f3df..83f2ec2 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -280,7 +280,7 @@ static int parse_ptl(GetBitContext *gb, AVCodecContext
*avctx,
{
int i;
if (decode_profile_tier_level(gb, avctx, &ptl->general_ptl) < 0 ||
-get_bits_left(gb) < 8 + 8*2) {
+get_bits_left(gb) < 8 + (8*2 * (max_num_sub_layers - 1 > 0))) {
av_log(avctx, AV_LOG_ERROR, "PTL information too short\n");
return -1;
}
--
2.7.2.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] vf_colorspace: add floyd-steinberg dithering option to full conversion.
Hi, On Fri, May 6, 2016 at 10:14 AM, Michael Niedermayer wrote: > On Fri, May 06, 2016 at 09:06:01AM -0400, Ronald S. Bultje wrote: > > --- > > doc/filters.texi | 13 > > libavfilter/colorspacedsp.c | 13 > > libavfilter/colorspacedsp.h | 6 ++ > > libavfilter/colorspacedsp_template.c | 128 > +++ > > libavfilter/vf_colorspace.c | 64 +- > > 5 files changed, 221 insertions(+), 3 deletions(-) > > i cant test this: > > Applying: vf_colorspace: add floyd-steinberg dithering option to full > conversion. > fatal: sha1 information is lacking or useless > (libavfilter/vf_colorspace.c). > Repository lacks necessary blobs to fall back on 3-way merge. > Cannot fall back to three-way merge. https://github.com/rbultje/ffmpeg/commits/colorspace Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hevc: fix size condition in ptl parsing
Hendrik Leppkes gmail.com> writes:
> -get_bits_left(gb) < 8 + 8*2) {
> +get_bits_left(gb) < 8 + (8*2 * (max_num_sub_layers - 1 > 0))) {
Isnt't "max_num_sub_layers > 1" more readable?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h2645_parse: allow partial escaping
Hendrik Leppkes gmail.com> writes: > This ports the fix from 033a533 to the new parser module in > prepartion of using it for the h264 decoder.h2645_parse: > allow partial escaping Could this patch port ticket #5453 from one codec to the next? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hevc: fix size condition in ptl parsing
On Fri, May 6, 2016 at 7:49 PM, Carl Eugen Hoyos wrote:
> Hendrik Leppkes gmail.com> writes:
>
>> -get_bits_left(gb) < 8 + 8*2) {
>> +get_bits_left(gb) < 8 + (8*2 * (max_num_sub_layers - 1 > 0))) {
>
> Isnt't "max_num_sub_layers > 1" more readable?
>
Perhaps, but this syntax is used in the function everywhere else.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] vf_colorspace: add floyd-steinberg dithering option to full conversion.
On Fri, May 06, 2016 at 01:17:56PM -0400, Ronald S. Bultje wrote: > Hi, > > On Fri, May 6, 2016 at 10:14 AM, Michael Niedermayer > wrote: > > > On Fri, May 06, 2016 at 09:06:01AM -0400, Ronald S. Bultje wrote: > > > --- > > > doc/filters.texi | 13 > > > libavfilter/colorspacedsp.c | 13 > > > libavfilter/colorspacedsp.h | 6 ++ > > > libavfilter/colorspacedsp_template.c | 128 > > +++ > > > libavfilter/vf_colorspace.c | 64 +- > > > 5 files changed, 221 insertions(+), 3 deletions(-) > > > > i cant test this: > > > > Applying: vf_colorspace: add floyd-steinberg dithering option to full > > conversion. > > fatal: sha1 information is lacking or useless > > (libavfilter/vf_colorspace.c). > > Repository lacks necessary blobs to fall back on 3-way merge. > > Cannot fall back to three-way merge. > > > https://github.com/rbultje/ffmpeg/commits/colorspace --- ./tests/ref/lavf/mov2016-05-05 02:36:06.272607621 +0200 +++ tests/data/fate/lavf-mov2016-05-06 20:52:39.831813922 +0200 @@ -13,9 +13,9 @@ ebca72c186a4f3ba9bb17d9cb5b74fef *./tests/data/lavf/lavf.mp4 312457 ./tests/data/lavf/lavf.mp4 ./tests/data/lavf/lavf.mp4 CRC=0x9d9a638a -9944512475d82d2d601f3c96101bdf9c *./tests/data/lavf/lavf.mp4 -321343 ./tests/data/lavf/lavf.mp4 -./tests/data/lavf/lavf.mp4 CRC=0xe8130120 +38b6bcf55731a5905f58c071e8961d4d *./tests/data/lavf/lavf.mp4 +312570 ./tests/data/lavf/lavf.mp4 +./tests/data/lavf/lavf.mp4 CRC=0xb5cb0057 7b3e71f294901067046c09f03a426bdc *./tests/data/lavf/lavf.mp4 312001 ./tests/data/lavf/lavf.mp4 ./tests/data/lavf/lavf.mp4 CRC=0x9d9a638a Test lavf-mov failed. Look at tests/data/fate/lavf-mov.err for details. make: *** [fate-lavf-mov] Error 1 git bisect bad c9b2411cae0e604697b5daf7413077fe325c4208 is the first bad commit commit c9b2411cae0e604697b5daf7413077fe325c4208 Author: Ronald S. Bultje Date: Mon Feb 15 08:29:40 2016 -0500 mov: set variable fps flag. :04 04 aa38e6352eaab2e76519e92dd4e44fd4945b3568 8c61d7cbd6d2de18aa5e622cd1bf7e64f32e8186 M libavformat [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] vf_colorspace: use enums for bpp/subsampling array indices.
On Fri, May 06, 2016 at 09:06:03AM -0400, Ronald S. Bultje wrote: > Also add some documentation for each function to colorspacedsp.h. > --- > libavfilter/colorspacedsp.c | 78 > ++-- > libavfilter/colorspacedsp.h | 31 -- > libavfilter/x86/colorspacedsp_init.c | 64 ++--- > 3 files changed, 98 insertions(+), 75 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] vf_colorspace: add const to yuv_stride[] argument in DSP functions.
On Fri, May 06, 2016 at 09:06:02AM -0400, Ronald S. Bultje wrote: > --- > libavfilter/colorspacedsp.h | 10 +- > libavfilter/colorspacedsp_template.c | 6 +++--- > libavfilter/colorspacedsp_yuv2yuv_template.c | 4 ++-- > libavfilter/x86/colorspacedsp_init.c | 8 > 4 files changed, 14 insertions(+), 14 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_colorspace: don't enable passthrough if bitdepth doesn't match.
On Fri, May 06, 2016 at 12:27:02PM -0400, Ronald S. Bultje wrote:
> ---
> libavfilter/vf_colorspace.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
> index 7776a61..f932ce9 100644
> --- a/libavfilter/vf_colorspace.c
> +++ b/libavfilter/vf_colorspace.c
> @@ -754,7 +754,8 @@ static int create_filtergraph(AVFilterContext *ctx,
> s->yuv2yuv_fastmode = s->rgb2rgb_passthrough && fmt_identical;
> s->yuv2yuv_passthrough = s->yuv2yuv_fastmode && s->in_rng == s->out_rng
> &&
> !memcmp(s->in_lumacoef, s->out_lumacoef,
> - sizeof(*s->in_lumacoef));
> + sizeof(*s->in_lumacoef)) &&
> + in_desc->comp[0].depth ==
> out_desc->comp[0].depth;
> if (!s->yuv2yuv_passthrough) {
> if (redo_yuv2rgb) {
> double rgb2yuv[3][3], (*yuv2rgb)[3] = s->yuv2rgb_dbl_coeffs;
LGTM
> @@ -986,7 +987,9 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
> td.in_ss_h = av_pix_fmt_desc_get(in->format)->log2_chroma_h;
> td.out_ss_h = av_pix_fmt_desc_get(out->format)->log2_chroma_h;
> if (s->yuv2yuv_passthrough) {
> -av_frame_copy(out, in);
> +res = av_frame_copy(out, in);
> +if (res < 0)
> +return res;
> } else {
unrelated ?
but LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_colorspace: don't enable passthrough if bitdepth doesn't match.
Hi,
On Fri, May 6, 2016 at 3:23 PM, Michael Niedermayer
wrote:
> On Fri, May 06, 2016 at 12:27:02PM -0400, Ronald S. Bultje wrote:
> > ---
> > libavfilter/vf_colorspace.c | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
> > index 7776a61..f932ce9 100644
> > --- a/libavfilter/vf_colorspace.c
> > +++ b/libavfilter/vf_colorspace.c
> > @@ -754,7 +754,8 @@ static int create_filtergraph(AVFilterContext *ctx,
> > s->yuv2yuv_fastmode = s->rgb2rgb_passthrough && fmt_identical;
> > s->yuv2yuv_passthrough = s->yuv2yuv_fastmode && s->in_rng ==
> s->out_rng &&
> > !memcmp(s->in_lumacoef, s->out_lumacoef,
> > - sizeof(*s->in_lumacoef));
> > + sizeof(*s->in_lumacoef)) &&
> > + in_desc->comp[0].depth ==
> out_desc->comp[0].depth;
> > if (!s->yuv2yuv_passthrough) {
> > if (redo_yuv2rgb) {
> > double rgb2yuv[3][3], (*yuv2rgb)[3] = s->yuv2rgb_dbl_coeffs;
>
> LGTM
>
>
> > @@ -986,7 +987,9 @@ static int filter_frame(AVFilterLink *link, AVFrame
> *in)
> > td.in_ss_h = av_pix_fmt_desc_get(in->format)->log2_chroma_h;
> > td.out_ss_h = av_pix_fmt_desc_get(out->format)->log2_chroma_h;
> > if (s->yuv2yuv_passthrough) {
> > -av_frame_copy(out, in);
> > +res = av_frame_copy(out, in);
> > +if (res < 0)
> > +return res;
> > } else {
>
> unrelated ?
> but LGTM
Hm, it's sort of related to the same bug. What happened is that when
converting from yuv444p to yuv444p10, it would set passthrough=1 (because
of the bug in hunk 1), and then the lack of the check in hunk 2 would cause
the dest buffer to be uninitialized but the function would return as if it
converted succesfully.
So hunk 2 makes it fail correctly, and hunk 1 makes it then not use
passthrough for that conversion so it actually succeeds.
I'll adjust the log message to make that clearer.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] vf_colorspace: add floyd-steinberg dithering option to full conversion.
Hi, On Fri, May 6, 2016 at 2:55 PM, Michael Niedermayer wrote: > On Fri, May 06, 2016 at 01:17:56PM -0400, Ronald S. Bultje wrote: > > Hi, > > > > On Fri, May 6, 2016 at 10:14 AM, Michael Niedermayer > > > wrote: > > > > > On Fri, May 06, 2016 at 09:06:01AM -0400, Ronald S. Bultje wrote: > > > > --- > > > > doc/filters.texi | 13 > > > > libavfilter/colorspacedsp.c | 13 > > > > libavfilter/colorspacedsp.h | 6 ++ > > > > libavfilter/colorspacedsp_template.c | 128 > > > +++ > > > > libavfilter/vf_colorspace.c | 64 +- > > > > 5 files changed, 221 insertions(+), 3 deletions(-) > > > > > > i cant test this: > > > > > > Applying: vf_colorspace: add floyd-steinberg dithering option to full > > > conversion. > > > fatal: sha1 information is lacking or useless > > > (libavfilter/vf_colorspace.c). > > > Repository lacks necessary blobs to fall back on 3-way merge. > > > Cannot fall back to three-way merge. > > > > > > https://github.com/rbultje/ffmpeg/commits/colorspace > > > --- ./tests/ref/lavf/mov2016-05-05 02:36:06.272607621 +0200 > +++ tests/data/fate/lavf-mov2016-05-06 20:52:39.831813922 +0200 > @@ -13,9 +13,9 @@ > ebca72c186a4f3ba9bb17d9cb5b74fef *./tests/data/lavf/lavf.mp4 > 312457 ./tests/data/lavf/lavf.mp4 > ./tests/data/lavf/lavf.mp4 CRC=0x9d9a638a > -9944512475d82d2d601f3c96101bdf9c *./tests/data/lavf/lavf.mp4 > -321343 ./tests/data/lavf/lavf.mp4 > -./tests/data/lavf/lavf.mp4 CRC=0xe8130120 > +38b6bcf55731a5905f58c071e8961d4d *./tests/data/lavf/lavf.mp4 > +312570 ./tests/data/lavf/lavf.mp4 > +./tests/data/lavf/lavf.mp4 CRC=0xb5cb0057 > 7b3e71f294901067046c09f03a426bdc *./tests/data/lavf/lavf.mp4 > 312001 ./tests/data/lavf/lavf.mp4 > ./tests/data/lavf/lavf.mp4 CRC=0x9d9a638a > Test lavf-mov failed. Look at tests/data/fate/lavf-mov.err for details. > make: *** [fate-lavf-mov] Error 1 > git bisect bad > c9b2411cae0e604697b5daf7413077fe325c4208 is the first bad commit > commit c9b2411cae0e604697b5daf7413077fe325c4208 > Author: Ronald S. Bultje > Date: Mon Feb 15 08:29:40 2016 -0500 > > mov: set variable fps flag. I'll remove that commit, it's something unrelated that was dangling in my tree... Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/riff: add M102 FourCC
0001-avformat-riff-add-M102-FourCC.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/riff: add M102 FourCC
samples are here: https://www.datafilehost.com/d/1a93d9a6 (some matrox uncompressed samples I posted to ticket #2616 are invalid due to bug in the older version of matrox codec which I used to encode them) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] vf_colorspace: add floyd-steinberg dithering option to full conversion.
On Fri, May 06, 2016 at 03:44:49PM -0400, Ronald S. Bultje wrote: > Hi, > > On Fri, May 6, 2016 at 2:55 PM, Michael Niedermayer > wrote: > > > On Fri, May 06, 2016 at 01:17:56PM -0400, Ronald S. Bultje wrote: > > > Hi, > > > > > > On Fri, May 6, 2016 at 10:14 AM, Michael Niedermayer > > > > > wrote: > > > > > > > On Fri, May 06, 2016 at 09:06:01AM -0400, Ronald S. Bultje wrote: > > > > > --- > > > > > doc/filters.texi | 13 > > > > > libavfilter/colorspacedsp.c | 13 > > > > > libavfilter/colorspacedsp.h | 6 ++ > > > > > libavfilter/colorspacedsp_template.c | 128 > > > > +++ > > > > > libavfilter/vf_colorspace.c | 64 +- > > > > > 5 files changed, 221 insertions(+), 3 deletions(-) > > > > > > > > i cant test this: > > > > > > > > Applying: vf_colorspace: add floyd-steinberg dithering option to full > > > > conversion. > > > > fatal: sha1 information is lacking or useless > > > > (libavfilter/vf_colorspace.c). > > > > Repository lacks necessary blobs to fall back on 3-way merge. > > > > Cannot fall back to three-way merge. > > > > > > > > > https://github.com/rbultje/ffmpeg/commits/colorspace > > > > > > --- ./tests/ref/lavf/mov2016-05-05 02:36:06.272607621 +0200 > > +++ tests/data/fate/lavf-mov2016-05-06 20:52:39.831813922 +0200 > > @@ -13,9 +13,9 @@ > > ebca72c186a4f3ba9bb17d9cb5b74fef *./tests/data/lavf/lavf.mp4 > > 312457 ./tests/data/lavf/lavf.mp4 > > ./tests/data/lavf/lavf.mp4 CRC=0x9d9a638a > > -9944512475d82d2d601f3c96101bdf9c *./tests/data/lavf/lavf.mp4 > > -321343 ./tests/data/lavf/lavf.mp4 > > -./tests/data/lavf/lavf.mp4 CRC=0xe8130120 > > +38b6bcf55731a5905f58c071e8961d4d *./tests/data/lavf/lavf.mp4 > > +312570 ./tests/data/lavf/lavf.mp4 > > +./tests/data/lavf/lavf.mp4 CRC=0xb5cb0057 > > 7b3e71f294901067046c09f03a426bdc *./tests/data/lavf/lavf.mp4 > > 312001 ./tests/data/lavf/lavf.mp4 > > ./tests/data/lavf/lavf.mp4 CRC=0x9d9a638a > > Test lavf-mov failed. Look at tests/data/fate/lavf-mov.err for details. > > make: *** [fate-lavf-mov] Error 1 > > git bisect bad > > c9b2411cae0e604697b5daf7413077fe325c4208 is the first bad commit > > commit c9b2411cae0e604697b5daf7413077fe325c4208 > > Author: Ronald S. Bultje > > Date: Mon Feb 15 08:29:40 2016 -0500 > > > > mov: set variable fps flag. > > > I'll remove that commit, it's something unrelated that was dangling in my > tree... fate works fine here without the commit [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle 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 matroska-remux test.
On Fri, May 06, 2016 at 09:27:20AM -0400, Ronald S. Bultje wrote: > This tests automatic insertion of the vp9_superframe BSF as well as > ensuring that the colorspace properties in the video header can be > modified when remuxing (-c:v copy). > --- > tests/Makefile | 1 + > tests/fate/matroska.mak | 9 + > 2 files changed, 10 insertions(+) > create mode 100644 tests/fate/matroska.mak LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] configure: Enable GCC vectorization on ≥4.9
On Fri, May 06, 2016 at 12:08:14PM +0200, Hendrik Leppkes wrote: > > Just to document it, this has caused build breakage in various > scenarios, even in GCC 5.3 (6.1 not tested). > > The latest reported on IRC just today here: > libavcodec/sbrdsp.c: In function 'sbr_neg_odd_64_c': > libavcodec/sbrdsp.c:47:13: internal compiler error: in > vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596 > static void sbr_neg_odd_64_c(float *x) > > There are various other cases which usually involve inline asm when > building with SIMD (ie. --cpu=host) and the optimizer running out of > registers, for example: > libavcodec/x86/cabac.h:192:5: error: 'asm' operand has impossible constraints > > IMHO this feature is not quite ready to be enabled unconditionally in > our code base, and we should re-evaluate this change. I don't have a problem with reverting this commit, but as James mentioned I do prefer the bug to be reported to GCC if possible. Have you also considered the possibility to enable this feature only if inline assembly is not enabled? Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] configure: Enable GCC vectorization on ≥4.9
On 5/6/2016 8:48 PM, Timothy Gu wrote: > On Fri, May 06, 2016 at 12:08:14PM +0200, Hendrik Leppkes wrote: >> >> Just to document it, this has caused build breakage in various >> scenarios, even in GCC 5.3 (6.1 not tested). >> >> The latest reported on IRC just today here: >> libavcodec/sbrdsp.c: In function 'sbr_neg_odd_64_c': >> libavcodec/sbrdsp.c:47:13: internal compiler error: in >> vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596 >> static void sbr_neg_odd_64_c(float *x) >> >> There are various other cases which usually involve inline asm when >> building with SIMD (ie. --cpu=host) and the optimizer running out of >> registers, for example: >> libavcodec/x86/cabac.h:192:5: error: 'asm' operand has impossible constraints >> >> IMHO this feature is not quite ready to be enabled unconditionally in >> our code base, and we should re-evaluate this change. > > I don't have a problem with reverting this commit, but as James mentioned I do > prefer the bug to be reported to GCC if possible. > > Have you also considered the possibility to enable this feature only if inline > assembly is not enabled? Nobody disables inline asm when using GCC, so it'd be the same as removing tree vectorization altogether to begin with. This feature gives some nice speed boost on parts of the code that don't have hand written asm, so I'd very much rather keep it and try to get GCC to fix bugs on their compilers. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] configure: Enable GCC vectorization on ≥4.9
On Sat, May 7, 2016 at 2:02 AM, James Almer wrote: > On 5/6/2016 8:48 PM, Timothy Gu wrote: >> On Fri, May 06, 2016 at 12:08:14PM +0200, Hendrik Leppkes wrote: >>> >>> Just to document it, this has caused build breakage in various >>> scenarios, even in GCC 5.3 (6.1 not tested). >>> >>> The latest reported on IRC just today here: >>> libavcodec/sbrdsp.c: In function 'sbr_neg_odd_64_c': >>> libavcodec/sbrdsp.c:47:13: internal compiler error: in >>> vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596 >>> static void sbr_neg_odd_64_c(float *x) >>> >>> There are various other cases which usually involve inline asm when >>> building with SIMD (ie. --cpu=host) and the optimizer running out of >>> registers, for example: >>> libavcodec/x86/cabac.h:192:5: error: 'asm' operand has impossible >>> constraints >>> >>> IMHO this feature is not quite ready to be enabled unconditionally in >>> our code base, and we should re-evaluate this change. >> >> I don't have a problem with reverting this commit, but as James mentioned I >> do >> prefer the bug to be reported to GCC if possible. >> >> Have you also considered the possibility to enable this feature only if >> inline >> assembly is not enabled? > > Nobody disables inline asm when using GCC, so it'd be the same as removing > tree > vectorization altogether to begin with. > > This feature gives some nice speed boost on parts of the code that don't have > hand written asm, so I'd very much rather keep it and try to get GCC to fix > bugs > on their compilers. Fixing would be nice of course, but it should then only be enabled in versions we know do not have problems, which is none right now. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] configure: Enable GCC vectorization on ≥4.9
On 5/6/2016 9:56 PM, Hendrik Leppkes wrote: > On Sat, May 7, 2016 at 2:02 AM, James Almer wrote: >> On 5/6/2016 8:48 PM, Timothy Gu wrote: >>> On Fri, May 06, 2016 at 12:08:14PM +0200, Hendrik Leppkes wrote: Just to document it, this has caused build breakage in various scenarios, even in GCC 5.3 (6.1 not tested). The latest reported on IRC just today here: libavcodec/sbrdsp.c: In function 'sbr_neg_odd_64_c': libavcodec/sbrdsp.c:47:13: internal compiler error: in vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596 static void sbr_neg_odd_64_c(float *x) There are various other cases which usually involve inline asm when building with SIMD (ie. --cpu=host) and the optimizer running out of registers, for example: libavcodec/x86/cabac.h:192:5: error: 'asm' operand has impossible constraints IMHO this feature is not quite ready to be enabled unconditionally in our code base, and we should re-evaluate this change. >>> >>> I don't have a problem with reverting this commit, but as James mentioned I >>> do >>> prefer the bug to be reported to GCC if possible. >>> >>> Have you also considered the possibility to enable this feature only if >>> inline >>> assembly is not enabled? >> >> Nobody disables inline asm when using GCC, so it'd be the same as removing >> tree >> vectorization altogether to begin with. >> >> This feature gives some nice speed boost on parts of the code that don't have >> hand written asm, so I'd very much rather keep it and try to get GCC to fix >> bugs >> on their compilers. > > Fixing would be nice of course, but it should then only be enabled in > versions we know do not have problems, which is none right now. > > - Hendrik Again, do you know the configure options or compile flags that triggered these compiler errors? None of the many GCC 5.3 FATE clients reproduce them, so it must be a specific combination of compile flags. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hevc: fix size condition in ptl parsing
On Fri, May 06, 2016 at 07:15:06PM +0200, Hendrik Leppkes wrote: > When only one sublayer is present, no information is coded. Only when at > least two > are present, all 8 sublayers are written. > --- > libavcodec/hevc_ps.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/riff: add M102 FourCC
On Fri, May 06, 2016 at 10:48:32PM +0200, Piotr Bandurski wrote:
> From b365a1b2544e5e70652f41e7e8bf4066fb778b4c Mon Sep 17 00:00:00 2001
> From: Piotr Bandurski
> Date: Fri, 6 May 2016 22:43:00 +0200
> Subject: [PATCH] avformat/riff: add M102 FourCC
>
> ---
> libavformat/riff.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/libavformat/riff.c b/libavformat/riff.c
> index ccbe608..dd20aff 100644
> --- a/libavformat/riff.c
> +++ b/libavformat/riff.c
> @@ -420,6 +420,7 @@ const AVCodecTag ff_codec_bmp_tags[] = {
> { AV_CODEC_ID_RSCC, MKTAG('I', 'S', 'C', 'C') },
> { AV_CODEC_ID_CFHD, MKTAG('C', 'F', 'H', 'D') },
> { AV_CODEC_ID_M101, MKTAG('M', '1', '0', '1') },
> +{ AV_CODEC_ID_M101, MKTAG('M', '1', '0', '2') },
>
> { AV_CODEC_ID_NONE, 0 }
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No snowflake in an avalanche ever feels responsible. -- 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 2/2] configure: Enable GCC vectorization on ≥4.9
On 5/6/2016 6:08 AM, Hendrik Leppkes wrote: On Tue, Feb 9, 2016 at 1:28 AM, Timothy Gu wrote: On Sun, Jan 31, 2016 at 3:38 PM Timothy Gu wrote: On Sat, Jan 30, 2016 at 07:27:22PM +, Derek Buitenhuis wrote: On 1/30/2016 7:15 PM, Timothy Gu wrote: FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1. Perhaps this should be restricted to x86? Fair enough. Pushed. Just to document it, this has caused build breakage in various scenarios, even in GCC 5.3 (6.1 not tested). The latest reported on IRC just today here: libavcodec/sbrdsp.c: In function 'sbr_neg_odd_64_c': libavcodec/sbrdsp.c:47:13: internal compiler error: in vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596 static void sbr_neg_odd_64_c(float *x) There are various other cases which usually involve inline asm when building with SIMD (ie. --cpu=host) and the optimizer running out of registers, for example: libavcodec/x86/cabac.h:192:5: error: 'asm' operand has impossible constraints IMHO this feature is not quite ready to be enabled unconditionally in our code base, and we should re-evaluate this change. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel It may also be miscompiling the code on i686 (or specifically MinGW-w64 builds on i686), since I was encountering segfaults at random at startup* in builds of mpv linked against affected FFmpeg builds, but not in ffmpeg.exe itself. Disabling tree vectorization in extra-cflags resolved it. It might work seemingly correctly the first couple invocations, then start crashing on #4 onward. But then at a different time, it would always fail, or work a different number of times before failing. That was on Silvermont* with 2 GBs of RAM; on my old Pentium III and 512 MBs of RAM, it seemed to always fail. *still 32-bit Windows, though. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
