[FFmpeg-devel] [PATCH] nvenc: Allow different const qps for I, P and B frames
Adding subject line. Thanks and regards, Konda Raju -Original Message- From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Konda Raju Sent: Friday, March 17, 2017 9:56 AM To: ffmpeg-devel@ffmpeg.org Cc: phil...@overt.org Subject: [FFmpeg-devel] [PATCH] nvenc: Hi, Please review the attached patch. This patch allows to specify different const qp values for I, P and B frames. This change is backward compatible. Note that the constQP values are initialized with default values in preset configuration, hence there is not "else()" block in set_constqp(). Thanks and regards, Konda Raju --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- 0001-Allow-different-const-qps-for-I-P-and-B-frames.patch Description: 0001-Allow-different-const-qps-for-I-P-and-B-frames.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] nvenc:
Hi, Please review the attached patch. This patch allows to specify different const qp values for I, P and B frames. This change is backward compatible. Note that the constQP values are initialized with default values in preset configuration, hence there is not "else()" block in set_constqp(). Thanks and regards, Konda Raju --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- 0001-Allow-different-const-qps-for-I-P-and-B-frames.patch Description: 0001-Allow-different-const-qps-for-I-P-and-B-frames.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] decklink: new option 'format' to set video format by fourCC
On Thursday, March 16, 2017 3:54:39 PM CDT Marton Balint wrote: > On Thu, 16 Mar 2017, Nicolas George wrote: > > Le sextidi 26 ventôse, an CCXXV, Matthias Hunstock a écrit : > >> I did not find a comparable option for another device in libavdevice, > >> "format" was the initial suggestion of Marton. This is at least > >> consistent with the existing "list_formats" option. > > > > I do not know what the option does, and therefore can not propose a > > better name. > > It selects video standard, field order and frame rate, these fourcc-s are > defined in the BlackMagic SDK. Example: 'Hp50' - HD 1080p50 format. > > > All I know is that we decided not to build an inconvenient > > infrastructure to avoid the collision between global, format, codecs > > options, at the cost of having to be careful when adding said options. > > This is exactly one of these cases: "format" can be added as a global > > option, as a ffmpeg.c option or anything else, because it is very > > generic. > How about “scan_format”, to be act as a collection of sub-elements “scan_width”, “scan_rate” and "scan_type"? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3] avformat/rtmpproto: change rtmp_open from url_open to url_open2
use the option set by user
Reported-by: Lancelot Lai
Signed-off-by: Steven Liu
---
libavformat/rtmpproto.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index 5d7ad79..7b2bd81 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -2604,14 +2604,13 @@ static int inject_fake_duration_metadata(RTMPContext
*rt)
* and 'playpath' is a file name (the rest of the path,
* may be prefixed with "mp4:")
*/
-static int rtmp_open(URLContext *s, const char *uri, int flags)
+static int rtmp_open(URLContext *s, const char *uri, int flags, AVDictionary
**opts)
{
RTMPContext *rt = s->priv_data;
char proto[8], hostname[256], path[1024], auth[100], *fname;
char *old_app, *qmark, *n, fname_buffer[1024];
uint8_t buf[2048];
int port;
-AVDictionary *opts = NULL;
int ret;
if (rt->listen_timeout > 0)
@@ -2648,7 +2647,7 @@ static int rtmp_open(URLContext *s, const char *uri, int
flags)
}
if (!strcmp(proto, "rtmpt") || !strcmp(proto, "rtmpts")) {
if (!strcmp(proto, "rtmpts"))
-av_dict_set(&opts, "ffrtmphttp_tls", "1", 1);
+av_dict_set(opts, "ffrtmphttp_tls", "1", 1);
/* open the http tunneling connection */
ff_url_join(buf, sizeof(buf), "ffrtmphttp", NULL, hostname, port,
NULL);
@@ -2659,7 +2658,7 @@ static int rtmp_open(URLContext *s, const char *uri, int
flags)
ff_url_join(buf, sizeof(buf), "tls", NULL, hostname, port, NULL);
} else if (!strcmp(proto, "rtmpe") || (!strcmp(proto, "rtmpte"))) {
if (!strcmp(proto, "rtmpte"))
-av_dict_set(&opts, "ffrtmpcrypt_tunneling", "1", 1);
+av_dict_set(opts, "ffrtmpcrypt_tunneling", "1", 1);
/* open the encrypted connection */
ff_url_join(buf, sizeof(buf), "ffrtmpcrypt", NULL, hostname, port,
NULL);
@@ -2678,7 +2677,7 @@ static int rtmp_open(URLContext *s, const char *uri, int
flags)
reconnect:
if ((ret = ffurl_open_whitelist(&rt->stream, buf, AVIO_FLAG_READ_WRITE,
-&s->interrupt_callback, &opts,
+&s->interrupt_callback, opts,
s->protocol_whitelist,
s->protocol_blacklist, s)) < 0) {
av_log(s , AV_LOG_ERROR, "Cannot open connection %s\n", buf);
goto fail;
@@ -2896,7 +2895,7 @@ reconnect:
return 0;
fail:
-av_dict_free(&opts);
+av_dict_free(opts);
rtmp_close(s);
return ret;
}
@@ -3141,7 +3140,7 @@ static const AVClass flavor##_class = { \
\
const URLProtocol ff_##flavor##_protocol = { \
.name = #flavor, \
-.url_open = rtmp_open, \
+.url_open2 = rtmp_open, \
.url_read = rtmp_read, \
.url_read_seek = rtmp_seek, \
.url_read_pause = rtmp_pause,\
--
2.10.1 (Apple Git-78)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample/resample: do not assert compensation_distance on rebuild_filter
On Fri, Mar 17, 2017 at 9:27 AM, wm4 wrote: > On Fri, 17 Mar 2017 08:01:23 +0700 > Muhammad Faiz wrote: > >> when set_compensation is called with zero sample_delta, >> compensation does not happen (because dst_incr == ideal_dst_incr) >> but compensation_distance is set >> >> regression since 01ebb57c03abde89bca7bdbc552917efcb8f551d >> >> Found-by: wm4 >> Signed-off-by: Muhammad Faiz >> --- >> libswresample/resample.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libswresample/resample.c b/libswresample/resample.c >> index 8f3428f..144b232 100644 >> --- a/libswresample/resample.c >> +++ b/libswresample/resample.c >> @@ -388,7 +388,7 @@ static int >> rebuild_filter_bank_with_compensation(ResampleContext *c) >> if (phase_count == c->phase_count) >> return 0; >> >> -av_assert0(!c->frac && !c->dst_incr_mod && !c->compensation_distance); >> +av_assert0(!c->frac && !c->dst_incr_mod); >> >> new_filter_bank = av_calloc(c->filter_alloc, (phase_count + 1) * >> c->felem_size); >> if (!new_filter_bank) > > Certainly fixes the crash for me. Applied Thank's ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample/resample: do not assert compensation_distance on rebuild_filter
On Fri, 17 Mar 2017 08:01:23 +0700 Muhammad Faiz wrote: > when set_compensation is called with zero sample_delta, > compensation does not happen (because dst_incr == ideal_dst_incr) > but compensation_distance is set > > regression since 01ebb57c03abde89bca7bdbc552917efcb8f551d > > Found-by: wm4 > Signed-off-by: Muhammad Faiz > --- > libswresample/resample.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libswresample/resample.c b/libswresample/resample.c > index 8f3428f..144b232 100644 > --- a/libswresample/resample.c > +++ b/libswresample/resample.c > @@ -388,7 +388,7 @@ static int > rebuild_filter_bank_with_compensation(ResampleContext *c) > if (phase_count == c->phase_count) > return 0; > > -av_assert0(!c->frac && !c->dst_incr_mod && !c->compensation_distance); > +av_assert0(!c->frac && !c->dst_incr_mod); > > new_filter_bank = av_calloc(c->filter_alloc, (phase_count + 1) * > c->felem_size); > if (!new_filter_bank) Certainly fixes the crash for me. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/mjpegdec: Check quant_matrixes values for being non zero
Signed-off-by: Michael Niedermayer
---
libavcodec/mjpegdec.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 4e78e1e3ae..b159cac197 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -188,6 +188,10 @@ int ff_mjpeg_decode_dqt(MJpegDecodeContext *s)
/* read quant table */
for (i = 0; i < 64; i++) {
s->quant_matrixes[index][i] = get_bits(&s->gb, pr ? 16 : 8);
+if (s->quant_matrixes[index][i] == 0) {
+av_log(s->avctx, AV_LOG_ERROR, "dqt: 0 quant value\n");
+return AVERROR_INVALIDDATA;
+}
}
// XXX FIXME fine-tune, and perhaps add dc too
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/mjpegdec: quant_matrixes can be up to 65535, use uint16_t
Fixes invalid shift
Fixes: 870/clusterfuzz-testcase-5649105424482304
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/mjpegdec.c | 10 +-
libavcodec/mjpegdec.h | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index b159cac197..7f8521eccc 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -686,7 +686,7 @@ static inline int mjpeg_decode_dc(MJpegDecodeContext *s,
int dc_index)
/* decode block and dequantize */
static int decode_block(MJpegDecodeContext *s, int16_t *block, int component,
-int dc_index, int ac_index, int16_t *quant_matrix)
+int dc_index, int ac_index, uint16_t *quant_matrix)
{
int code, i, j, level, val;
@@ -736,7 +736,7 @@ static int decode_block(MJpegDecodeContext *s, int16_t
*block, int component,
static int decode_dc_progressive(MJpegDecodeContext *s, int16_t *block,
int component, int dc_index,
- int16_t *quant_matrix, int Al)
+ uint16_t *quant_matrix, int Al)
{
int val;
s->bdsp.clear_block(block);
@@ -754,7 +754,7 @@ static int decode_dc_progressive(MJpegDecodeContext *s,
int16_t *block,
/* decode block and dequantize - progressive JPEG version */
static int decode_block_progressive(MJpegDecodeContext *s, int16_t *block,
uint8_t *last_nnz, int ac_index,
-int16_t *quant_matrix,
+uint16_t *quant_matrix,
int ss, int se, int Al, int *EOBRUN)
{
int code, i, j, level, val, run;
@@ -852,7 +852,7 @@ for (; ; i++) {
\
/* decode block and dequantize - progressive JPEG refinement pass */
static int decode_block_refinement(MJpegDecodeContext *s, int16_t *block,
uint8_t *last_nnz,
- int ac_index, int16_t *quant_matrix,
+ int ac_index, uint16_t *quant_matrix,
int ss, int se, int Al, int *EOBRUN)
{
int code, i = ss, j, sign, val, run;
@@ -1383,7 +1383,7 @@ static int
mjpeg_decode_scan_progressive_ac(MJpegDecodeContext *s, int ss,
int mb_x, mb_y;
int EOBRUN = 0;
int c = s->comp_index[0];
-int16_t *quant_matrix = s->quant_matrixes[s->quant_sindex[0]];
+uint16_t *quant_matrix = s->quant_matrixes[s->quant_sindex[0]];
av_assert0(ss>=0 && Ah>=0 && Al>=0);
if (se < ss || se > 63) {
diff --git a/libavcodec/mjpegdec.h b/libavcodec/mjpegdec.h
index fb811294a1..024cedcb5a 100644
--- a/libavcodec/mjpegdec.h
+++ b/libavcodec/mjpegdec.h
@@ -50,7 +50,7 @@ typedef struct MJpegDecodeContext {
int buffer_size;
uint8_t *buffer;
-int16_t quant_matrixes[4][64];
+uint16_t quant_matrixes[4][64];
VLC vlcs[3][4];
int qscale[4]; ///< quantizer scale calculated from quant_matrixes
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/avcodec: Constify AVBitStreamFilter* in AVBitStreamFilterContext struct.
On Thu, Mar 16, 2017 at 10:38:24PM +0100, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes one of two remaining warnings when compiling > bitstream_filter.c. > > Please comment, Carl Eugen > avcodec.h |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > cf539519c5fa10e4af07d38e7a5d3ed10a3014a7 > 0001-lavc-avcodec-Constify-AVBitStreamFilter-in-AVBitStre.patch > From 7fb60d42ee2137d1181ad0f6e214df87ed06400e Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos > Date: Thu, 16 Mar 2017 22:31:44 +0100 > Subject: [PATCH] lavc/avcodec: Constify AVBitStreamFilter* in > AVBitStreamFilterContext struct. > > Fixes a gcc warning: > libavcodec/bitstream_filter.c:71:20: warning: assignment discards 'const' > qualifier from pointer target type LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample/options: enable linear_interp and exact_rational by default
On Fri, Mar 17, 2017 at 7:09 AM, wm4 wrote: > On Fri, 10 Mar 2017 09:19:38 +0700 > Muhammad Faiz wrote: > >> for higher quality resampling >> >> Signed-off-by: Muhammad Faiz >> --- > > This patch triggers this assertion: > > Assertion !c->frac && !c->dst_incr_mod && !c->compensation_distance failed at > libswresample/resample.c:391 > > when I use avresample_set_compensation(). Setting exact_rational=0 > seems to avoid this. I've posted a patch to fix it Thank's ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] swresample/resample: do not assert compensation_distance on rebuild_filter
when set_compensation is called with zero sample_delta, compensation does not happen (because dst_incr == ideal_dst_incr) but compensation_distance is set regression since 01ebb57c03abde89bca7bdbc552917efcb8f551d Found-by: wm4 Signed-off-by: Muhammad Faiz --- libswresample/resample.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libswresample/resample.c b/libswresample/resample.c index 8f3428f..144b232 100644 --- a/libswresample/resample.c +++ b/libswresample/resample.c @@ -388,7 +388,7 @@ static int rebuild_filter_bank_with_compensation(ResampleContext *c) if (phase_count == c->phase_count) return 0; -av_assert0(!c->frac && !c->dst_incr_mod && !c->compensation_distance); +av_assert0(!c->frac && !c->dst_incr_mod); new_filter_bank = av_calloc(c->filter_alloc, (phase_count + 1) * c->felem_size); if (!new_filter_bank) -- 2.9.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/rtmpproto: change rtmp_open from url_open to url_open2
On Thu, Mar 16, 2017 at 08:31:34PM +0800, Steven Liu wrote: > use the option set by user > > Reported-by: Lancelot Lai > Signed-off-by: Steven Liu > --- > libavformat/rtmpproto.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) This causes rtmp to segfault: example: ./ffmpeg_g -rtmp_live 0 -i rtmp://127.0.0.1 file.avi [tcp @ 0x20f0b80] Connection to tcp://127.0.0.1:1935 failed: Connection refused [rtmp @ 0x20f0420] Cannot open connection tcp://127.0.0.1:1935 Program received signal SIGSEGV, Segmentation fault. 0x010ffd03 in av_dict_get () (gdb) bt #0 0x010ffd03 in av_dict_get () #1 0x010fff6a in av_dict_set () #2 0x00630976 in ffurl_connect () #3 0x00631286 in ffurl_open_whitelist () #4 0x006354c5 in ffio_open_whitelist () #5 0x006eb2b1 in io_open_default () #6 0x007460ed in avformat_open_input () #7 0x004b051b in open_input_file () #8 0x004ade9c in open_files.isra () #9 0x004b564c in ffmpeg_parse_options () #10 0x004a5a1e in main () [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3 v2] Documentation: update decklink options
Signed-off-by: Matthias Hunstock
---
doc/indevs.texi | 14 ++
doc/outdevs.texi | 15 +++
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 27cc3d5..a4c99a9 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -233,6 +233,12 @@ Defaults to @option{false}.
If set to @option{true}, print a list of supported formats and exit.
Defaults to @option{false}.
+@item format_code
+This sets the input video format to the format given by the FourCC. To see
+the supported values of your device(s) use @option{list_formats}.
+Note that there is a fourCC @option{'pal '} that can also be used
+as @option{pal} (3 letters).
+
@item bm_v210
If set to @samp{1}, video is captured in 10 bit v210 instead
of uyvy422. Not all Blackmagic devices support this option.
@@ -296,21 +302,21 @@ ffmpeg -f decklink -list_formats 1 -i 'Intensity Pro'
@end example
@item
-Capture video clip at 1080i50 (format 11):
+Capture video clip at 1080i50:
@example
-ffmpeg -f decklink -i 'Intensity Pro@@11' -acodec copy -vcodec copy output.avi
+ffmpeg -format_code Hi50 -f decklink -i 'Intensity Pro' -acodec copy -vcodec
copy output.avi
@end example
@item
Capture video clip at 1080i50 10 bit:
@example
-ffmpeg -bm_v210 1 -f decklink -i 'UltraStudio Mini Recorder@@11' -acodec copy
-vcodec copy output.avi
+ffmpeg -bm_v210 1 -format_code Hi50 -f decklink -i 'UltraStudio Mini Recorder'
-acodec copy -vcodec copy output.avi
@end example
@item
Capture video clip at 1080i50 with 16 audio channels:
@example
-ffmpeg -channels 16 -f decklink -i 'UltraStudio Mini Recorder@@11' -acodec
copy -vcodec copy output.avi
+ffmpeg -channels 16 -format_code Hi50 -f decklink -i 'UltraStudio Mini
Recorder' -acodec copy -vcodec copy output.avi
@end example
@end itemize
diff --git a/doc/outdevs.texi b/doc/outdevs.texi
index df41cc8..40206a4 100644
--- a/doc/outdevs.texi
+++ b/doc/outdevs.texi
@@ -146,6 +146,15 @@ Defaults to @option{false}.
If set to @option{true}, print a list of supported formats and exit.
Defaults to @option{false}.
+@item format_code
+This sets the output video format to the format given by the FourCC. To see
+the supported values of your device(s) use @option{list_formats}.
+Note that there is a fourCC @option{'pal '} that can also be used
+as @option{pal} (3 letters).
+
+Without this option the correct output video format is chosen automatically.
+Use this option only to enforce a specific output format in special use cases.
+
@item preroll
Amount of time to preroll video in seconds.
Defaults to @option{0.5}.
@@ -180,6 +189,12 @@ Play video clip with non-standard framerate or video size:
ffmpeg -i test.avi -f decklink -pix_fmt uyvy422 -s 720x486 -r 24000/1001
'DeckLink Mini Monitor'
@end example
+@item
+Play video clip, enforce interlaced playout of progressive video
+@example
+ffmpeg -i test.avi -f decklink -pix_fmt uyvy422 -field_order tt 'DeckLink Mini
Monitor'
+@end example
+
@end itemize
@section fbdev
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3 v2] decklink: new option 'format_code' to set video format by fourCC
Signed-off-by: Matthias Hunstock
---
libavdevice/decklink_common.cpp | 17 +
libavdevice/decklink_common_c.h | 1 +
libavdevice/decklink_dec.cpp| 5 +++--
libavdevice/decklink_dec_c.c| 1 +
libavdevice/decklink_enc_c.c| 1 +
5 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index 82b3a0c..a75ccc1 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -33,6 +33,7 @@ extern "C" {
#include "libavformat/avformat.h"
#include "libavformat/internal.h"
#include "libavutil/imgutils.h"
+#include "libavutil/intreadwrite.h"
#include "libavutil/bswap.h"
}
@@ -158,8 +159,8 @@ int ff_decklink_set_format(AVFormatContext *avctx,
int i = 1;
HRESULT res;
-av_log(avctx, AV_LOG_DEBUG, "Trying to find mode for frame size %dx%d,
frame timing %d/%d, field order %d, direction %d, mode number %d\n",
-width, height, tb_num, tb_den, field_order, direction, num);
+av_log(avctx, AV_LOG_DEBUG, "Trying to find mode for frame size %dx%d,
frame timing %d/%d, field order %d, direction %d, mode number %d, format code
%s\n",
+width, height, tb_num, tb_den, field_order, direction, num,
(cctx->format_code) ? cctx->format_code : "(unset)");
if (ctx->duplex_mode) {
DECKLINK_BOOL duplex_supported = false;
@@ -196,12 +197,18 @@ int ff_decklink_set_format(AVFormatContext *avctx,
return AVERROR(EIO);
}
+BMDDisplayMode target_mode = 0;
+char format_buf[] = " ";
+if (cctx->format_code)
+av_strlcpy(format_buf, cctx->format_code, sizeof(format_buf));
+target_mode = av_bswap32(AV_RL32(format_buf));
AVRational target_tb = av_make_q(tb_num, tb_den);
ctx->bmd_mode = bmdModeUnknown;
while ((ctx->bmd_mode == bmdModeUnknown) && itermode->Next(&mode) == S_OK)
{
BMDTimeValue bmd_tb_num, bmd_tb_den;
int bmd_width = mode->GetWidth();
int bmd_height = mode->GetHeight();
+BMDDisplayMode bmd_mode = mode->GetDisplayMode();
BMDFieldDominance bmd_field_dominance = mode->GetFieldDominance();
mode->GetFrameRate(&bmd_tb_num, &bmd_tb_den);
@@ -210,8 +217,10 @@ int ff_decklink_set_format(AVFormatContext *avctx,
if ((bmd_width == width &&
bmd_height == height &&
!av_cmp_q(mode_tb, target_tb) &&
- field_order_eq(field_order, bmd_field_dominance)) || i == num) {
-ctx->bmd_mode = mode->GetDisplayMode();
+ field_order_eq(field_order, bmd_field_dominance))
+ || i == num
+ || target_mode == bmd_mode) {
+ctx->bmd_mode = bmd_mode;
ctx->bmd_width = bmd_width;
ctx->bmd_height = bmd_height;
ctx->bmd_tb_den = bmd_tb_den;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index d565631..72c5f9a 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -47,6 +47,7 @@ struct decklink_cctx {
int audio_input;
int video_input;
int draw_bars;
+char *format_code;
};
#endif /* AVDEVICE_DECKLINK_COMMON_C_H */
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 7df841b..ffe65db 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -539,9 +539,10 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
goto error;
}
-if (mode_num > 0) {
+if (mode_num > 0 || cctx->format_code) {
if (ff_decklink_set_format(avctx, DIRECTION_IN, mode_num) < 0) {
-av_log(avctx, AV_LOG_ERROR, "Could not set mode %d for %s\n",
mode_num, fname);
+av_log(avctx, AV_LOG_ERROR, "Could not set mode number %d or
format code %s for %s\n",
+mode_num, (cctx->format_code) ? cctx->format_code : "(unset)",
fname);
ret = AVERROR(EIO);
goto error;
}
diff --git a/libavdevice/decklink_dec_c.c b/libavdevice/decklink_dec_c.c
index 31818d2..d4ae4e5 100644
--- a/libavdevice/decklink_dec_c.c
+++ b/libavdevice/decklink_dec_c.c
@@ -31,6 +31,7 @@
static const AVOption options[] = {
{ "list_devices", "list available devices" , OFFSET(list_devices),
AV_OPT_TYPE_INT , { .i64 = 0 }, 0, 1, DEC },
{ "list_formats", "list supported formats" , OFFSET(list_formats),
AV_OPT_TYPE_INT , { .i64 = 0 }, 0, 1, DEC },
+{ "format_code", "set format by fourcc", OFFSET(format_code),
AV_OPT_TYPE_STRING, { .str = NULL}, 3, 4, DEC },
{ "bm_v210", "v210 10 bit per channel" , OFFSET(v210),
AV_OPT_TYPE_INT , { .i64 = 0 }, 0, 1, DEC },
{ "teletext_lines", "teletext lines bitmask", OFFSET(teletext_lines),
AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, 0x7LL, DEC, "teletext_lines"},
{ "standard", NULL, 0,
AV_OPT_TYPE_CONST, { .i64 = 0x7fff9fffeLL},
[FFmpeg-devel] [PATCH 1/3 v2] decklink: add format_code of display mode to list_format output
Signed-off-by: Matthias Hunstock
---
libavdevice/decklink_common.cpp | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index 8b499c5..82b3a0c 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -33,6 +33,7 @@ extern "C" {
#include "libavformat/avformat.h"
#include "libavformat/internal.h"
#include "libavutil/imgutils.h"
+#include "libavutil/bswap.h"
}
#include "decklink_common.h"
@@ -276,6 +277,7 @@ int ff_decklink_list_formats(AVFormatContext *avctx,
decklink_direction_t direct
struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
IDeckLinkDisplayModeIterator *itermode;
IDeckLinkDisplayMode *mode;
+BMDDisplayMode format_code;
int i=0;
HRESULT res;
@@ -297,13 +299,14 @@ int ff_decklink_list_formats(AVFormatContext *avctx,
decklink_direction_t direct
return AVERROR(EIO);
}
-av_log(avctx, AV_LOG_INFO, "Supported formats for '%s':\n",
+av_log(avctx, AV_LOG_INFO, "Supported formats for
'%s':\n\tmode\tformat_code\tdescription",
avctx->filename);
while (itermode->Next(&mode) == S_OK) {
BMDTimeValue tb_num, tb_den;
mode->GetFrameRate(&tb_num, &tb_den);
-av_log(avctx, AV_LOG_INFO, "\t%d\t%ldx%ld at %d/%d fps",
-++i,mode->GetWidth(), mode->GetHeight(),
+format_code = av_bswap32(mode->GetDisplayMode());
+av_log(avctx, AV_LOG_INFO, "\n\t%d\t%.4s\t\t%ldx%ld at %d/%d fps",
+++i, (char*) &format_code, mode->GetWidth(), mode->GetHeight(),
(int) tb_den, (int) tb_num);
switch (mode->GetFieldDominance()) {
case bmdLowerFieldFirst:
@@ -311,9 +314,9 @@ int ff_decklink_list_formats(AVFormatContext *avctx,
decklink_direction_t direct
case bmdUpperFieldFirst:
av_log(avctx, AV_LOG_INFO, " (interlaced, upper field first)"); break;
}
-av_log(avctx, AV_LOG_INFO, "\n");
mode->Release();
}
+av_log(avctx, AV_LOG_INFO, "\n");
itermode->Release();
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/3 v2] decklink: new option -format_code to specify video modes with constant fourCCs
This patch series introduces a new option for the decklink devices. Currently, a video mode can be explicitly set via -i "devicename@modenumber", which is a common need for capture and sometimes for playout. The current number based modes are not constant between different cards and sometimes even change with SDK versions. The new option uses constants from the SDK that do not change and are kind of human readable. decklink: add format_code of display mode to list_format output decklink: new option 'format_code' to set video format by fourCC Documentation: update decklink options doc/indevs.texi | 14 ++ doc/outdevs.texi| 15 +++ libavdevice/decklink_common.cpp | 28 libavdevice/decklink_common_c.h | 1 + libavdevice/decklink_dec.cpp| 5 +++-- libavdevice/decklink_dec_c.c| 1 + libavdevice/decklink_enc_c.c| 1 + 7 files changed, 51 insertions(+), 14 deletions(-) -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample/options: enable linear_interp and exact_rational by default
On Fri, 10 Mar 2017 09:19:38 +0700 Muhammad Faiz wrote: > for higher quality resampling > > Signed-off-by: Muhammad Faiz > --- This patch triggers this assertion: Assertion !c->frac && !c->dst_incr_mod && !c->compensation_distance failed at libswresample/resample.c:391 when I use avresample_set_compensation(). Setting exact_rational=0 seems to avoid this. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec, avformat: deprecate anything related to side data merging
On Fri, 17 Mar 2017 00:32:04 +0100 Michael Niedermayer wrote: > On Thu, Mar 16, 2017 at 09:20:55PM +0100, Nicolas George wrote: > > Le sextidi 26 ventôse, an CCXXV, Michael Niedermayer a écrit : > > > Applications which depend on the current default would need > > > > ... to implement a correct structure to carry the data from their > > demuxer to the lavc decoders. > > Is this possible for every application using every framework ? They can invent their own side data merging mechanism if they don't. There are plenty of API mechanisms in FFmpeg that don't map well to other frameworks at all, and this is one of the easiest to sidestep. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec, avformat: deprecate anything related to side data merging
On Thu, Mar 16, 2017 at 09:20:55PM +0100, Nicolas George wrote: > Le sextidi 26 ventôse, an CCXXV, Michael Niedermayer a écrit : > > Applications which depend on the current default would need > > ... to implement a correct structure to carry the data from their > demuxer to the lavc decoders. Is this possible for every application using every framework ? [...] -- 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 2/3] ffplay: convert to new decode API
On Wed, 15 Mar 2017, Marton Balint wrote:
Since subtitles are not yet supported with the new API, CODEC_CAP_DELAY
subtitle codecs (only libzvbi so far) may loose the last few buffered frames in
the end of the stream.
The impact of this is so limited, it seemded better to accept it than losing
the simplification benefits of the new API.
Hi Wallak,
Have you had a chance to test this ffplay patch, and see if it fixes
CrystalHD decoding in ffplay or not?
Thanks,
Marton
Signed-off-by: Marton Balint
---
ffplay.c | 92 +---
1 file changed, 41 insertions(+), 51 deletions(-)
diff --git a/ffplay.c b/ffplay.c
index cf138dc..06d1d22 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -186,13 +186,10 @@ enum {
};
typedef struct Decoder {
-AVPacket pkt;
-AVPacket pkt_temp;
PacketQueue *queue;
AVCodecContext *avctx;
int pkt_serial;
int finished;
-int packet_pending;
SDL_cond *empty_queue_cond;
int64_t start_pts;
AVRational start_pts_tb;
@@ -551,40 +548,24 @@ static void decoder_init(Decoder *d, AVCodecContext
*avctx, PacketQueue *queue,
d->queue = queue;
d->empty_queue_cond = empty_queue_cond;
d->start_pts = AV_NOPTS_VALUE;
+d->pkt_serial = -1;
}
static int decoder_decode_frame(Decoder *d, AVFrame *frame, AVSubtitle *sub) {
-int got_frame = 0;
+int ret = AVERROR(EAGAIN);
-do {
-int ret = -1;
+for (;;) {
+AVPacket pkt;
+if (d->queue->serial == d->pkt_serial) {
+do {
if (d->queue->abort_request)
return -1;
-if (!d->packet_pending || d->queue->serial != d->pkt_serial) {
-AVPacket pkt;
-do {
-if (d->queue->nb_packets == 0)
-SDL_CondSignal(d->empty_queue_cond);
-if (packet_queue_get(d->queue, &pkt, 1, &d->pkt_serial) < 0)
-return -1;
-if (pkt.data == flush_pkt.data) {
-avcodec_flush_buffers(d->avctx);
-d->finished = 0;
-d->next_pts = d->start_pts;
-d->next_pts_tb = d->start_pts_tb;
-}
-} while (pkt.data == flush_pkt.data || d->queue->serial !=
d->pkt_serial);
-av_packet_unref(&d->pkt);
-d->pkt_temp = d->pkt = pkt;
-d->packet_pending = 1;
-}
-
switch (d->avctx->codec_type) {
case AVMEDIA_TYPE_VIDEO:
-ret = avcodec_decode_video2(d->avctx, frame, &got_frame,
&d->pkt_temp);
-if (got_frame) {
+ret = avcodec_receive_frame(d->avctx, frame);
+if (ret >= 0) {
if (decoder_reorder_pts == -1) {
frame->pts = av_frame_get_best_effort_timestamp(frame);
} else if (!decoder_reorder_pts) {
@@ -593,8 +574,8 @@ static int decoder_decode_frame(Decoder *d, AVFrame *frame,
AVSubtitle *sub) {
}
break;
case AVMEDIA_TYPE_AUDIO:
-ret = avcodec_decode_audio4(d->avctx, frame, &got_frame,
&d->pkt_temp);
-if (got_frame) {
+ret = avcodec_receive_frame(d->avctx, frame);
+if (ret >= 0) {
AVRational tb = (AVRational){1, frame->sample_rate};
if (frame->pts != AV_NOPTS_VALUE)
frame->pts = av_rescale_q(frame->pts,
av_codec_get_pkt_timebase(d->avctx), tb);
@@ -606,37 +587,46 @@ static int decoder_decode_frame(Decoder *d, AVFrame
*frame, AVSubtitle *sub) {
}
}
break;
-case AVMEDIA_TYPE_SUBTITLE:
-ret = avcodec_decode_subtitle2(d->avctx, sub, &got_frame,
&d->pkt_temp);
-break;
+}
+if (ret == AVERROR_EOF) {
+d->finished = d->pkt_serial;
+avcodec_flush_buffers(d->avctx);
+return 0;
+}
+if (ret >= 0)
+return 1;
+} while (ret != AVERROR(EAGAIN));
}
-if (ret < 0) {
-d->packet_pending = 0;
+do {
+if (d->queue->nb_packets == 0)
+SDL_CondSignal(d->empty_queue_cond);
+if (packet_queue_get(d->queue, &pkt, 1, &d->pkt_serial) < 0)
+return -1;
+} while (d->queue->serial != d->pkt_serial);
+
+if (pkt.data == flush_pkt.data) {
+avcodec_flush_buffers(d->avctx);
+d->finished = 0;
+d->next_pts = d->start_pts;
+d->next_pts_tb = d->start_pts_tb;
} else {
-d->pkt_temp.dts =
-d->pkt_temp.pts = AV_NOPTS_VALUE;
-if (d->pkt_temp.data) {
-if (d->avctx->codec_type != AVMEDIA_TYPE_AUDIO)
-ret = d->pkt_temp.size;
-d->pkt_temp.data += ret;
-d->pkt_temp.size -= ret;
-
[FFmpeg-devel] [PATCH 14/14] aarch64: vp9itxfm16: Do a simpler half/quarter idct16/idct32 when possible
This work is sponsored by, and copyright, Google. This avoids loading and calculating coefficients that we know will be zero, and avoids filling the temp buffer with zeros in places where we know the second pass won't read. This gives a pretty substantial speedup for the smaller subpartitions. The code size increases from 21512 bytes to 31400 bytes. The idct16/32_end macros are moved above the individual functions; the instructions themselves are unchanged, but since new functions are added at the same place where the code is moved from, the diff looks rather messy. Before: vp9_inv_dct_dct_16x16_sub1_add_10_neon: 284.6 vp9_inv_dct_dct_16x16_sub2_add_10_neon:1902.7 vp9_inv_dct_dct_16x16_sub4_add_10_neon:1903.0 vp9_inv_dct_dct_16x16_sub8_add_10_neon:2201.1 vp9_inv_dct_dct_16x16_sub12_add_10_neon: 2510.0 vp9_inv_dct_dct_16x16_sub16_add_10_neon: 2821.3 vp9_inv_dct_dct_32x32_sub1_add_10_neon:1011.6 vp9_inv_dct_dct_32x32_sub2_add_10_neon:9716.5 vp9_inv_dct_dct_32x32_sub4_add_10_neon:9704.9 vp9_inv_dct_dct_32x32_sub8_add_10_neon: 10641.7 vp9_inv_dct_dct_32x32_sub12_add_10_neon: 11555.7 vp9_inv_dct_dct_32x32_sub16_add_10_neon: 12499.8 vp9_inv_dct_dct_32x32_sub20_add_10_neon: 13403.7 vp9_inv_dct_dct_32x32_sub24_add_10_neon: 14335.8 vp9_inv_dct_dct_32x32_sub28_add_10_neon: 15253.6 vp9_inv_dct_dct_32x32_sub32_add_10_neon: 16179.5 After: vp9_inv_dct_dct_16x16_sub1_add_10_neon: 282.8 vp9_inv_dct_dct_16x16_sub2_add_10_neon:1142.4 vp9_inv_dct_dct_16x16_sub4_add_10_neon:1139.0 vp9_inv_dct_dct_16x16_sub8_add_10_neon:1772.9 vp9_inv_dct_dct_16x16_sub12_add_10_neon: 2515.2 vp9_inv_dct_dct_16x16_sub16_add_10_neon: 2823.5 vp9_inv_dct_dct_32x32_sub1_add_10_neon:1012.7 vp9_inv_dct_dct_32x32_sub2_add_10_neon:6944.4 vp9_inv_dct_dct_32x32_sub4_add_10_neon:6944.2 vp9_inv_dct_dct_32x32_sub8_add_10_neon:7609.8 vp9_inv_dct_dct_32x32_sub12_add_10_neon: 9953.4 vp9_inv_dct_dct_32x32_sub16_add_10_neon: 10770.1 vp9_inv_dct_dct_32x32_sub20_add_10_neon: 13418.8 vp9_inv_dct_dct_32x32_sub24_add_10_neon: 14330.7 vp9_inv_dct_dct_32x32_sub28_add_10_neon: 15257.1 vp9_inv_dct_dct_32x32_sub32_add_10_neon: 16190.6 --- libavcodec/aarch64/vp9itxfm_16bpp_neon.S | 605 --- 1 file changed, 547 insertions(+), 58 deletions(-) diff --git a/libavcodec/aarch64/vp9itxfm_16bpp_neon.S b/libavcodec/aarch64/vp9itxfm_16bpp_neon.S index f30fdd8..0befe38 100644 --- a/libavcodec/aarch64/vp9itxfm_16bpp_neon.S +++ b/libavcodec/aarch64/vp9itxfm_16bpp_neon.S @@ -124,6 +124,17 @@ endconst .endif .endm +// Same as dmbutterfly0 above, but treating the input in in2 as zero, +// writing the same output into both out1 and out2. +.macro dmbutterfly0_h out1, out2, in1, in2, tmp1, tmp2, tmp3, tmp4, tmp5, tmp6 +smull \tmp1\().2d, \in1\().2s, v0.s[0] +smull2 \tmp2\().2d, \in1\().4s, v0.s[0] +rshrn \out1\().2s, \tmp1\().2d, #14 +rshrn2 \out1\().4s, \tmp2\().2d, #14 +rshrn \out2\().2s, \tmp1\().2d, #14 +rshrn2 \out2\().4s, \tmp2\().2d, #14 +.endm + // out1,out2 = in1 * coef1 - in2 * coef2 // out3,out4 = in1 * coef2 + in2 * coef1 // out are 4 x .2d registers, in are 2 x .4s registers @@ -153,6 +164,43 @@ endconst rshrn2 \inout2\().4s, \tmp4\().2d, #14 .endm +// Same as dmbutterfly above, but treating the input in inout2 as zero +.macro dmbutterfly_h1 inout1, inout2, coef1, coef2, tmp1, tmp2, tmp3, tmp4 +smull \tmp1\().2d, \inout1\().2s, \coef1 +smull2 \tmp2\().2d, \inout1\().4s, \coef1 +smull \tmp3\().2d, \inout1\().2s, \coef2 +smull2 \tmp4\().2d, \inout1\().4s, \coef2 +rshrn \inout1\().2s, \tmp1\().2d, #14 +rshrn2 \inout1\().4s, \tmp2\().2d, #14 +rshrn \inout2\().2s, \tmp3\().2d, #14 +rshrn2 \inout2\().4s, \tmp4\().2d, #14 +.endm + +// Same as dmbutterfly above, but treating the input in inout1 as zero +.macro dmbutterfly_h2 inout1, inout2, coef1, coef2, tmp1, tmp2, tmp3, tmp4 +smull \tmp1\().2d, \inout2\().2s, \coef2 +smull2 \tmp2\().2d, \inout2\().4s, \coef2 +smull \tmp3\().2d, \inout2\().2s, \coef1 +smull2 \tmp4\().2d, \inout2\().4s, \coef1 +neg \tmp1\().2d, \tmp1\().2d +neg \tmp2\().2d, \tmp2\().2d +rshrn \inout2\().2s, \tmp3\().2d, #14 +rshrn2 \inout2\().4s, \tmp4\().2d, #14 +rshrn \inout1\().2s, \tmp1\().2d, #14 +rshrn2 \inout1\().4s, \tmp2\().2d, #14 +.endm + +.macro dsmull_h out1, out2, in, coef +smull \out1\().2d, \in\().2s, \coef +smull2 \out2\().2d, \in\().4s, \coef +.endm + +.macro drshrn_h out, in1, in2, shift +rshrn \out\().2s, \in1\().2d, \shift +r
[FFmpeg-devel] [PATCH 10/14] arm: vp9itxfm16: Make the larger core transforms standalone functions
This work is sponsored by, and copyright, Google.
This reduces the code size of libavcodec/arm/vp9itxfm_16bpp_neon.o from
17500 to 14516 bytes.
This gives a small slowdown of a couple tens of cycles, up to around
150 cycles for the full case of the largest transform, but makes
it more feasible to add more optimized versions of these transforms.
Before: Cortex A7 A8 A9 A53
vp9_inv_dct_dct_16x16_sub4_add_10_neon:4237.4 3561.5 3971.8 2525.3
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 6371.9 5452.0 5779.3 3910.5
vp9_inv_dct_dct_32x32_sub4_add_10_neon: 22068.8 17867.5 19555.2 13871.6
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 37268.9 38684.2 32314.2 23969.0
After:
vp9_inv_dct_dct_16x16_sub4_add_10_neon:4375.1 3571.9 4283.8 2567.2
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 6415.6 5578.9 5844.6 3948.3
vp9_inv_dct_dct_32x32_sub4_add_10_neon: 22653.7 18079.7 19603.7 13905.3
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 37593.2 38862.2 32235.8 24070.9
---
libavcodec/arm/vp9itxfm_16bpp_neon.S | 43 ++--
1 file changed, 27 insertions(+), 16 deletions(-)
diff --git a/libavcodec/arm/vp9itxfm_16bpp_neon.S
b/libavcodec/arm/vp9itxfm_16bpp_neon.S
index 29d95ca..8350153 100644
--- a/libavcodec/arm/vp9itxfm_16bpp_neon.S
+++ b/libavcodec/arm/vp9itxfm_16bpp_neon.S
@@ -807,7 +807,7 @@ function idct16x16_dc_add_neon
endfunc
.ltorg
-.macro idct16
+function idct16
mbutterfly0 d16, d24, d16, d24, d8, d10, q4, q5 @ d16 = t0a, d24
= t1a
mbutterfly d20, d28, d1[0], d1[1], q4, q5 @ d20 = t2a, d28 =
t3a
mbutterfly d18, d30, d2[0], d2[1], q4, q5 @ d18 = t4a, d30 =
t7a
@@ -853,9 +853,10 @@ endfunc
vmovd8, d21 @ d8 = t10a
butterfly d20, d27, d10, d27 @ d20 = out[4], d27 =
out[11]
butterfly d21, d26, d26, d8@ d21 = out[5], d26 =
out[10]
-.endm
+bx lr
+endfunc
-.macro iadst16
+function iadst16
movrel r12, iadst16_coeffs
vld1.16 {q0}, [r12,:128]!
vmovl.s16 q1, d1
@@ -933,7 +934,8 @@ endfunc
vmovd16, d2
vmovd30, d4
-.endm
+bx lr
+endfunc
.macro itxfm16_1d_funcs txfm
@ Read a vertical 2x16 slice out of a 16x16 matrix, do a transform on it,
@@ -941,6 +943,8 @@ endfunc
@ r0 = dst (temp buffer)
@ r2 = src
function \txfm\()16_1d_2x16_pass1_neon
+push{lr}
+
mov r12, #64
vmov.s32q4, #0
.irp i, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31
@@ -948,7 +952,7 @@ function \txfm\()16_1d_2x16_pass1_neon
vst1.32 {d8}, [r2,:64], r12
.endr
-\txfm\()16
+bl \txfm\()16
@ Do eight 2x2 transposes. Originally, d16-d31 contain the
@ 16 rows. Afterwards, d16-d17, d18-d19 etc contain the eight
@@ -959,7 +963,7 @@ function \txfm\()16_1d_2x16_pass1_neon
.irp i, 16, 18, 20, 22, 24, 26, 28, 30, 17, 19, 21, 23, 25, 27, 29, 31
vst1.32 {d\i}, [r0,:64]!
.endr
-bx lr
+pop {pc}
endfunc
@ Read a vertical 2x16 slice out of a 16x16 matrix, do a transform on it,
@@ -968,6 +972,8 @@ endfunc
@ r1 = dst stride
@ r2 = src (temp buffer)
function \txfm\()16_1d_2x16_pass2_neon
+push{lr}
+
mov r12, #64
.irp i, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31
vld1.16 {d\i}, [r2,:64], r12
@@ -975,7 +981,7 @@ function \txfm\()16_1d_2x16_pass2_neon
add r3, r0, r1
lsl r1, r1, #1
-\txfm\()16
+bl \txfm\()16
.macro load_add_store coef0, coef1, coef2, coef3
vrshr.s32 \coef0, \coef0, #6
@@ -1019,7 +1025,7 @@ function \txfm\()16_1d_2x16_pass2_neon
load_add_store q12, q13, q14, q15
.purgem load_add_store
-bx lr
+pop {pc}
endfunc
.endm
@@ -1193,7 +1199,7 @@ function idct32x32_dc_add_neon
pop {r4-r9,pc}
endfunc
-.macro idct32_odd
+function idct32_odd
movrel r12, idct_coeffs
@ Overwrite the idct16 coeffs with the stored ones for idct32
@@ -1262,7 +1268,8 @@ endfunc
mbutterfly0 d26, d21, d26, d21, d8, d10, q4, q5 @ d26 = t26a, d21
= t21a
mbutterfly0 d25, d22, d25, d22, d8, d10, q4, q5 @ d25 = t25, d22
= t22
mbutterfly0 d24, d23, d24, d23, d8, d10, q4, q5 @ d24 = t24a, d23
= t23a
-.endm
+bx lr
+endfunc
@ Do an 32-point IDCT of a 2x32 slice out of a 32x32 matrix.
@ We don't have register space to do a single pass IDCT of 2x32 though,
@@ -1274,6 +1281,8 @@ endfunc
@ r1 = unused
@ r2 = src
function idct32_1d_2x32_pass1_neon
[FFmpeg-devel] [PATCH 11/14] aarch64: vp9itxfm16: Make the larger core transforms standalone functions
This work is sponsored by, and copyright, Google.
This reduces the code size of libavcodec/aarch64/vp9itxfm_16bpp_neon.o from
26288 to 21512 bytes.
This gives a small slowdown of a couple of tens of cycles, but makes
it more feasible to add more optimized versions of these transforms.
Before:
vp9_inv_dct_dct_16x16_sub4_add_10_neon:1887.4
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 2801.5
vp9_inv_dct_dct_32x32_sub4_add_10_neon:9691.4
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 16154.9
After:
vp9_inv_dct_dct_16x16_sub4_add_10_neon:1899.5
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 2827.2
vp9_inv_dct_dct_32x32_sub4_add_10_neon:9714.7
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 16175.9
---
libavcodec/aarch64/vp9itxfm_16bpp_neon.S | 45
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/libavcodec/aarch64/vp9itxfm_16bpp_neon.S
b/libavcodec/aarch64/vp9itxfm_16bpp_neon.S
index a97c1b6..de1da55 100644
--- a/libavcodec/aarch64/vp9itxfm_16bpp_neon.S
+++ b/libavcodec/aarch64/vp9itxfm_16bpp_neon.S
@@ -710,7 +710,7 @@ function idct16x16_dc_add_neon
ret
endfunc
-.macro idct16
+function idct16
dmbutterfly0v16, v24, v16, v24, v4, v5, v6, v7, v8, v9 // v16 =
t0a, v24 = t1a
dmbutterfly v20, v28, v0.s[2], v0.s[3], v4, v5, v6, v7 // v20 =
t2a, v28 = t3a
dmbutterfly v18, v30, v1.s[0], v1.s[1], v4, v5, v6, v7 // v18 =
t4a, v30 = t7a
@@ -753,9 +753,10 @@ endfunc
butterfly_4sv19, v28, v5, v28 // v19 = out[3], v28
= out[12]
butterfly_4sv20, v27, v6, v27 // v20 = out[4], v27
= out[11]
butterfly_4sv21, v26, v26, v9// v21 = out[5], v26
= out[10]
-.endm
+ret
+endfunc
-.macro iadst16
+function iadst16
ld1 {v0.8h,v1.8h}, [x11]
sxtlv2.4s, v1.4h
sxtl2 v3.4s, v1.8h
@@ -830,7 +831,8 @@ endfunc
mov v16.16b, v2.16b
mov v30.16b, v4.16b
-.endm
+ret
+endfunc
// Helper macros; we can't use these expressions directly within
// e.g. .irp due to the extra concatenation \(). Therefore wrap
@@ -857,12 +859,14 @@ endfunc
// x9 = input stride
.macro itxfm16_1d_funcs txfm
function \txfm\()16_1d_4x16_pass1_neon
+mov x14, x30
+
moviv4.4s, #0
.irp i, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31
load_clear \i, x2, x9
.endr
-\txfm\()16
+bl \txfm\()16
// Do four 4x4 transposes. Originally, v16-v31 contain the
// 16 rows. Afterwards, v16-v19, v20-v23, v24-v27 and v28-v31
@@ -878,7 +882,7 @@ function \txfm\()16_1d_4x16_pass1_neon
.irp i, 16, 20, 24, 28, 17, 21, 25, 29, 18, 22, 26, 30, 19, 23, 27, 31
store \i, x0, #16
.endr
-ret
+br x14
1:
// Special case: For the last input column (x1 == 12),
// which would be stored as the last row in the temp buffer,
@@ -906,7 +910,7 @@ function \txfm\()16_1d_4x16_pass1_neon
mov v29.16b, v17.16b
mov v30.16b, v18.16b
mov v31.16b, v19.16b
-ret
+br x14
endfunc
// Read a vertical 4x16 slice out of a 16x16 matrix, do a transform on it,
@@ -917,6 +921,8 @@ endfunc
// x3 = slice offset
// x9 = temp buffer stride
function \txfm\()16_1d_4x16_pass2_neon
+mov x14, x30
+
.irp i, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27
load\i, x2, x9
.endr
@@ -928,7 +934,7 @@ function \txfm\()16_1d_4x16_pass2_neon
add x3, x0, x1
lsl x1, x1, #1
-\txfm\()16
+bl \txfm\()16
dup v8.8h, w13
.macro load_add_store coef0, coef1, coef2, coef3, coef4, coef5, coef6, coef7
@@ -983,7 +989,7 @@ function \txfm\()16_1d_4x16_pass2_neon
load_add_store v24.4s, v25.4s, v26.4s, v27.4s, v28.4s, v29.4s,
v30.4s, v31.4s
.purgem load_add_store
-ret
+br x14
endfunc
.endm
@@ -1158,7 +1164,7 @@ function idct32x32_dc_add_neon
ret
endfunc
-.macro idct32_odd
+function idct32_odd
dmbutterfly v16, v31, v10.s[0], v10.s[1], v4, v5, v6, v7 // v16 =
t16a, v31 = t31a
dmbutterfly v24, v23, v10.s[2], v10.s[3], v4, v5, v6, v7 // v24 =
t17a, v23 = t30a
dmbutterfly v20, v27, v11.s[0], v11.s[1], v4, v5, v6, v7 // v20 =
t18a, v27 = t29a
@@ -1209,7 +1215,8 @@ endfunc
dmbutterfly0v26, v21, v26, v21, v4, v5, v6, v7, v8, v9 // v26 =
t26a, v21 = t21a
dmbutterfly0v25, v22, v25, v22, v4, v5, v6, v7, v8, v9 // v25 =
t25, v22 = t22
dmbutterfly0v24, v23, v24, v23, v4, v5, v6, v7, v8, v9 // v24 =
t24a, v23 = t23a
-.endm
+ret
+endfunc
// Do an 32-point IDCT of a 4x32 slice out of a 32x32
[FFmpeg-devel] [PATCH 08/14] aarch64: vp9itxfm16: Avoid .irp when it doesn't save any lines
This makes the code a bit more readable.
---
libavcodec/aarch64/vp9itxfm_16bpp_neon.S | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/libavcodec/aarch64/vp9itxfm_16bpp_neon.S
b/libavcodec/aarch64/vp9itxfm_16bpp_neon.S
index f80604f..86ea29e 100644
--- a/libavcodec/aarch64/vp9itxfm_16bpp_neon.S
+++ b/libavcodec/aarch64/vp9itxfm_16bpp_neon.S
@@ -886,21 +886,21 @@ function \txfm\()16_1d_4x16_pass1_neon
// for the first slice of the second pass (where it is the
// last 4x4 block).
add x0, x0, #16
-.irp i, 20, 24, 28
-store \i, x0, #16
-.endr
+st1 {v20.4s}, [x0], #16
+st1 {v24.4s}, [x0], #16
+st1 {v28.4s}, [x0], #16
add x0, x0, #16
-.irp i, 21, 25, 29
-store \i, x0, #16
-.endr
+st1 {v21.4s}, [x0], #16
+st1 {v25.4s}, [x0], #16
+st1 {v29.4s}, [x0], #16
add x0, x0, #16
-.irp i, 22, 26, 30
-store \i, x0, #16
-.endr
+st1 {v22.4s}, [x0], #16
+st1 {v26.4s}, [x0], #16
+st1 {v30.4s}, [x0], #16
add x0, x0, #16
-.irp i, 23, 27, 31
-store \i, x0, #16
-.endr
+st1 {v23.4s}, [x0], #16
+st1 {v27.4s}, [x0], #16
+st1 {v31.4s}, [x0], #16
mov v28.16b, v16.16b
mov v29.16b, v17.16b
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 03/14] arm/aarch64: vp9: Fix vertical alignment
Align the second/third operands as they usually are.
Due to the wildly varying sizes of the written out operands
in aarch64 assembly, the column alignment is usually not as clear
as in arm assembly.
This is cherrypicked from libav commit
7995ebfad12002033c73feed422a1cfc62081e8f.
---
libavcodec/aarch64/vp9itxfm_neon.S | 36 ++--
libavcodec/arm/vp9itxfm_neon.S | 14 +++---
libavcodec/arm/vp9lpf_neon.S | 2 +-
3 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/libavcodec/aarch64/vp9itxfm_neon.S
b/libavcodec/aarch64/vp9itxfm_neon.S
index 3e5da08..b12890f 100644
--- a/libavcodec/aarch64/vp9itxfm_neon.S
+++ b/libavcodec/aarch64/vp9itxfm_neon.S
@@ -380,7 +380,7 @@ function ff_vp9_\txfm1\()_\txfm2\()_8x8_add_neon, export=1
.ifc \txfm1\()_\txfm2,idct_idct
movrel x4, idct_coeffs
.else
-movrel x4, iadst8_coeffs
+movrel x4, iadst8_coeffs
ld1 {v1.8h}, [x4], #16
.endif
ld1 {v0.8h}, [x4]
@@ -480,23 +480,23 @@ itxfm_func8x8 iadst, iadst
function idct16x16_dc_add_neon
-movrel x4, idct_coeffs
+movrel x4, idct_coeffs
ld1 {v0.4h}, [x4]
-moviv1.4h, #0
+moviv1.4h, #0
ld1 {v2.h}[0], [x2]
-smull v2.4s, v2.4h, v0.h[0]
-rshrn v2.4h, v2.4s, #14
-smull v2.4s, v2.4h, v0.h[0]
-rshrn v2.4h, v2.4s, #14
+smull v2.4s, v2.4h, v0.h[0]
+rshrn v2.4h, v2.4s, #14
+smull v2.4s, v2.4h, v0.h[0]
+rshrn v2.4h, v2.4s, #14
dup v2.8h, v2.h[0]
st1 {v1.h}[0], [x2]
-srshr v2.8h, v2.8h, #6
+srshr v2.8h, v2.8h, #6
-mov x3, x0
-mov x4, #16
+mov x3, x0
+mov x4, #16
1:
// Loop to add the constant from v2 into all 16x16 outputs
subsx4, x4, #2
@@ -869,7 +869,7 @@ function ff_vp9_\txfm1\()_\txfm2\()_16x16_add_neon, export=1
.ifc \txfm1,idct
ld1 {v0.8h,v1.8h}, [x10]
.endif
-mov x9, #32
+mov x9, #32
.ifc \txfm1\()_\txfm2,idct_idct
cmp w3, #10
@@ -1046,10 +1046,10 @@ idct16_partial quarter
idct16_partial half
function idct32x32_dc_add_neon
-movrel x4, idct_coeffs
+movrel x4, idct_coeffs
ld1 {v0.4h}, [x4]
-moviv1.4h, #0
+moviv1.4h, #0
ld1 {v2.h}[0], [x2]
smull v2.4s, v2.4h, v0.h[0]
@@ -1059,10 +1059,10 @@ function idct32x32_dc_add_neon
dup v2.8h, v2.h[0]
st1 {v1.h}[0], [x2]
-srshr v0.8h, v2.8h, #6
+srshr v0.8h, v2.8h, #6
-mov x3, x0
-mov x4, #32
+mov x3, x0
+mov x4, #32
1:
// Loop to add the constant v0 into all 32x32 outputs
subsx4, x4, #2
@@ -1230,7 +1230,7 @@ endfunc
// x9 = double input stride
function idct32_1d_8x32_pass1\suffix\()_neon
mov x14, x30
-moviv2.8h, #0
+moviv2.8h, #0
// v16 = IN(0), v17 = IN(2) ... v31 = IN(30)
.ifb \suffix
@@ -1295,7 +1295,7 @@ function idct32_1d_8x32_pass1\suffix\()_neon
.endif
add x2, x2, #64
-moviv2.8h, #0
+moviv2.8h, #0
// v16 = IN(1), v17 = IN(3) ... v31 = IN(31)
.ifb \suffix
.irp i, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31
diff --git a/libavcodec/arm/vp9itxfm_neon.S b/libavcodec/arm/vp9itxfm_neon.S
index 6d4d765..6c09922 100644
--- a/libavcodec/arm/vp9itxfm_neon.S
+++ b/libavcodec/arm/vp9itxfm_neon.S
@@ -530,7 +530,7 @@ function idct16x16_dc_add_neon
movrel r12, idct_coeffs
vld1.16 {d0}, [r12,:64]
-vmov.i16q2, #0
+vmov.i16q2, #0
vld1.16 {d16[]}, [r2,:16]
vmull.s16 q8, d16, d0[0]
@@ -793,7 +793,7 @@ function \txfm\()16_1d_4x16_pass1_neon
push{lr}
mov r12, #32
-vmov.s16q2, #0
+vmov.s16q2, #0
.irp i, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31
vld1.16 {d\i}, [r2,:64]
vst1.16 {d4}, [r2,:64], r12
@@ -1142,7 +1142,7 @@ function idct32x32_dc_add_neon
movrel r12, idct_coeffs
vld1.16 {d0}, [r12,:64]
-vmov.i16q2, #0
+vmov.i16q2, #0
vld1.16 {d16[]}, [r2,:16]
vmull.s16
[FFmpeg-devel] [PATCH 09/14] aarch64: vp9itxfm16: Restructure the idct32 store macros
This avoids concatenation, which can't be used if the whole macro
is wrapped within another macro.
---
libavcodec/aarch64/vp9itxfm_16bpp_neon.S | 90
1 file changed, 45 insertions(+), 45 deletions(-)
diff --git a/libavcodec/aarch64/vp9itxfm_16bpp_neon.S
b/libavcodec/aarch64/vp9itxfm_16bpp_neon.S
index 86ea29e..a97c1b6 100644
--- a/libavcodec/aarch64/vp9itxfm_16bpp_neon.S
+++ b/libavcodec/aarch64/vp9itxfm_16bpp_neon.S
@@ -1244,27 +1244,27 @@ function idct32_1d_4x32_pass1_neon
.macro store_rev a, b, c, d
// There's no rev128 instruction, but we reverse each 64 bit
// half, and then flip them using an ext with 8 bytes offset.
-rev64 v7.4s, v\d\().4s
-st1 {v\a\().4s}, [x0], #16
+rev64 v7.4s, \d
+st1 {\a}, [x0], #16
ext v7.16b, v7.16b, v7.16b, #8
-st1 {v\b\().4s}, [x0], #16
-rev64 v6.4s, v\c\().4s
-st1 {v\c\().4s}, [x0], #16
+st1 {\b}, [x0], #16
+rev64 v6.4s, \c
+st1 {\c}, [x0], #16
ext v6.16b, v6.16b, v6.16b, #8
-st1 {v\d\().4s}, [x0], #16
-rev64 v5.4s, v\b\().4s
+st1 {\d}, [x0], #16
+rev64 v5.4s, \b
st1 {v7.4s}, [x0], #16
ext v5.16b, v5.16b, v5.16b, #8
st1 {v6.4s}, [x0], #16
-rev64 v4.4s, v\a\().4s
+rev64 v4.4s, \a
st1 {v5.4s}, [x0], #16
ext v4.16b, v4.16b, v4.16b, #8
st1 {v4.4s}, [x0], #16
.endm
-store_rev 16, 20, 24, 28
-store_rev 17, 21, 25, 29
-store_rev 18, 22, 26, 30
-store_rev 19, 23, 27, 31
+store_rev v16.4s, v20.4s, v24.4s, v28.4s
+store_rev v17.4s, v21.4s, v25.4s, v29.4s
+store_rev v18.4s, v22.4s, v26.4s, v30.4s
+store_rev v19.4s, v23.4s, v27.4s, v31.4s
sub x0, x0, #512
.purgem store_rev
@@ -1290,27 +1290,27 @@ function idct32_1d_4x32_pass1_neon
// Store the registers a, b, c, d horizontally,
// adding into the output first, and the mirrored,
// subtracted from the output.
-.macro store_rev a, b, c, d
+.macro store_rev a, b, c, d, a16b, b16b
ld1 {v4.4s}, [x0]
-rev64 v9.4s, v\d\().4s
-add v4.4s, v4.4s, v\a\().4s
+rev64 v9.4s, \d
+add v4.4s, v4.4s, \a
st1 {v4.4s}, [x0], #16
-rev64 v8.4s, v\c\().4s
+rev64 v8.4s, \c
ld1 {v4.4s}, [x0]
ext v9.16b, v9.16b, v9.16b, #8
-add v4.4s, v4.4s, v\b\().4s
+add v4.4s, v4.4s, \b
st1 {v4.4s}, [x0], #16
ext v8.16b, v8.16b, v8.16b, #8
ld1 {v4.4s}, [x0]
-rev64 v\b\().4s, v\b\().4s
-add v4.4s, v4.4s, v\c\().4s
+rev64 \b, \b
+add v4.4s, v4.4s, \c
st1 {v4.4s}, [x0], #16
-rev64 v\a\().4s, v\a\().4s
+rev64 \a, \a
ld1 {v4.4s}, [x0]
-ext v\b\().16b, v\b\().16b, v\b\().16b, #8
-add v4.4s, v4.4s, v\d\().4s
+ext \b16b, \b16b, \b16b, #8
+add v4.4s, v4.4s, \d
st1 {v4.4s}, [x0], #16
-ext v\a\().16b, v\a\().16b, v\a\().16b, #8
+ext \a16b, \a16b, \a16b, #8
ld1 {v4.4s}, [x0]
sub v4.4s, v4.4s, v9.4s
st1 {v4.4s}, [x0], #16
@@ -1318,17 +1318,17 @@ function idct32_1d_4x32_pass1_neon
sub v4.4s, v4.4s, v8.4s
st1 {v4.4s}, [x0], #16
ld1 {v4.4s}, [x0]
-sub v4.4s, v4.4s, v\b\().4s
+sub v4.4s, v4.4s, \b
st1 {v4.4s}, [x0], #16
ld1 {v4.4s}, [x0]
-sub v4.4s, v4.4s, v\a\().4s
+sub v4.4s, v4.4s, \a
st1 {v4.4s}, [x0], #16
.endm
-store_rev 31, 27, 23, 19
-store_rev 30, 26, 22, 18
-store_rev 29, 25, 21, 17
-store_rev 28, 24, 20, 16
+store_rev v31.4s, v27.4s, v23.4s, v19.4s, v31.16b, v27.16b
+store_rev v30.4s, v26.4s, v22.4s, v18.4s, v30.16b, v26.16b
+store_rev v29.4s, v25.4s, v21.4s, v17.4s, v29.16b, v25.16b
+store_rev v28.4s, v24.4s, v20.4s, v16.4s, v28.16b, v24.16b
.purgem store_rev
ret
endfunc
@@ -1370,21 +1370,21 @@ function i
[FFmpeg-devel] [PATCH 12/14] aarch64: vp9itxfm16: Move the load_add_store macro out from the itxfm16 pass2 function
This allows reusing the macro for a separate implementation of the
pass2 function.
---
libavcodec/aarch64/vp9itxfm_16bpp_neon.S | 98
1 file changed, 49 insertions(+), 49 deletions(-)
diff --git a/libavcodec/aarch64/vp9itxfm_16bpp_neon.S
b/libavcodec/aarch64/vp9itxfm_16bpp_neon.S
index de1da55..f30fdd8 100644
--- a/libavcodec/aarch64/vp9itxfm_16bpp_neon.S
+++ b/libavcodec/aarch64/vp9itxfm_16bpp_neon.S
@@ -851,6 +851,55 @@ endfunc
st1 {v4.4s}, [\src], \inc
.endm
+.macro load_add_store coef0, coef1, coef2, coef3, coef4, coef5, coef6, coef7
+srshr \coef0, \coef0, #6
+ld1 {v4.4h}, [x0], x1
+srshr \coef1, \coef1, #6
+ld1 {v4.d}[1], [x3], x1
+srshr \coef2, \coef2, #6
+ld1 {v5.4h}, [x0], x1
+srshr \coef3, \coef3, #6
+uaddw \coef0, \coef0, v4.4h
+ld1 {v5.d}[1], [x3], x1
+srshr \coef4, \coef4, #6
+uaddw2 \coef1, \coef1, v4.8h
+ld1 {v6.4h}, [x0], x1
+srshr \coef5, \coef5, #6
+uaddw \coef2, \coef2, v5.4h
+ld1 {v6.d}[1], [x3], x1
+sqxtun v4.4h, \coef0
+srshr \coef6, \coef6, #6
+uaddw2 \coef3, \coef3, v5.8h
+ld1 {v7.4h}, [x0], x1
+sqxtun2 v4.8h, \coef1
+srshr \coef7, \coef7, #6
+uaddw \coef4, \coef4, v6.4h
+ld1 {v7.d}[1], [x3], x1
+uminv4.8h, v4.8h, v8.8h
+sub x0, x0, x1, lsl #2
+sub x3, x3, x1, lsl #2
+sqxtun v5.4h, \coef2
+uaddw2 \coef5, \coef5, v6.8h
+st1 {v4.4h}, [x0], x1
+sqxtun2 v5.8h, \coef3
+uaddw \coef6, \coef6, v7.4h
+st1 {v4.d}[1], [x3], x1
+uminv5.8h, v5.8h, v8.8h
+sqxtun v6.4h, \coef4
+uaddw2 \coef7, \coef7, v7.8h
+st1 {v5.4h}, [x0], x1
+sqxtun2 v6.8h, \coef5
+st1 {v5.d}[1], [x3], x1
+uminv6.8h, v6.8h, v8.8h
+sqxtun v7.4h, \coef6
+st1 {v6.4h}, [x0], x1
+sqxtun2 v7.8h, \coef7
+st1 {v6.d}[1], [x3], x1
+uminv7.8h, v7.8h, v8.8h
+st1 {v7.4h}, [x0], x1
+st1 {v7.d}[1], [x3], x1
+.endm
+
// Read a vertical 4x16 slice out of a 16x16 matrix, do a transform on it,
// transpose into a horizontal 16x4 slice and store.
// x0 = dst (temp buffer)
@@ -937,57 +986,8 @@ function \txfm\()16_1d_4x16_pass2_neon
bl \txfm\()16
dup v8.8h, w13
-.macro load_add_store coef0, coef1, coef2, coef3, coef4, coef5, coef6, coef7
-srshr \coef0, \coef0, #6
-ld1 {v4.4h}, [x0], x1
-srshr \coef1, \coef1, #6
-ld1 {v4.d}[1], [x3], x1
-srshr \coef2, \coef2, #6
-ld1 {v5.4h}, [x0], x1
-srshr \coef3, \coef3, #6
-uaddw \coef0, \coef0, v4.4h
-ld1 {v5.d}[1], [x3], x1
-srshr \coef4, \coef4, #6
-uaddw2 \coef1, \coef1, v4.8h
-ld1 {v6.4h}, [x0], x1
-srshr \coef5, \coef5, #6
-uaddw \coef2, \coef2, v5.4h
-ld1 {v6.d}[1], [x3], x1
-sqxtun v4.4h, \coef0
-srshr \coef6, \coef6, #6
-uaddw2 \coef3, \coef3, v5.8h
-ld1 {v7.4h}, [x0], x1
-sqxtun2 v4.8h, \coef1
-srshr \coef7, \coef7, #6
-uaddw \coef4, \coef4, v6.4h
-ld1 {v7.d}[1], [x3], x1
-uminv4.8h, v4.8h, v8.8h
-sub x0, x0, x1, lsl #2
-sub x3, x3, x1, lsl #2
-sqxtun v5.4h, \coef2
-uaddw2 \coef5, \coef5, v6.8h
-st1 {v4.4h}, [x0], x1
-sqxtun2 v5.8h, \coef3
-uaddw \coef6, \coef6, v7.4h
-st1 {v4.d}[1], [x3], x1
-uminv5.8h, v5.8h, v8.8h
-sqxtun v6.4h, \coef4
-uaddw2 \coef7, \coef7, v7.8h
-st1 {v5.4h}, [x0], x1
-sqxtun2 v6.8h, \coef5
-st1 {v5.d}[1], [x3], x1
-uminv6.8h, v6.8h, v8.8h
-sqxtun v7.4h, \coef6
-st1 {v6.4h}, [x0], x1
-sqxtun2 v7.8h, \coef7
-st1 {v6.d}[1], [x3], x1
-uminv7.8h, v7.8h, v8.8h
-s
[FFmpeg-devel] [PATCH 06/14] arm: vp9itxfm16: Avoid reloading the idct32 coefficients
Keep the idct32 coefficients in narrow form in q6-q7, and idct16
coefficients in lengthened 32 bit form in q0-q3. Avoid clobbering
q0-q3 in the pass1 function, and squeeze the idct16 coefficients
into q0-q1 in the pass2 function to avoid reloading them.
The idct16 coefficients are clobbered and reloaded within idct32_odd
though, since that turns out to be faster than narrowing them and
swapping them into q6-q7.
Before:Cortex A7A8A9 A53
vp9_inv_dct_dct_32x32_sub4_add_10_neon:22653.8 18268.4 19598.0 14079.0
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 37699.0 38665.2 32542.3 24472.2
After:
vp9_inv_dct_dct_32x32_sub4_add_10_neon:22270.8 18159.3 19531.0 13865.0
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 37523.3 37731.6 32181.7 24071.2
---
libavcodec/arm/vp9itxfm_16bpp_neon.S | 128 +++
1 file changed, 69 insertions(+), 59 deletions(-)
diff --git a/libavcodec/arm/vp9itxfm_16bpp_neon.S
b/libavcodec/arm/vp9itxfm_16bpp_neon.S
index 9c02ed9..29d95ca 100644
--- a/libavcodec/arm/vp9itxfm_16bpp_neon.S
+++ b/libavcodec/arm/vp9itxfm_16bpp_neon.S
@@ -1195,12 +1195,12 @@ endfunc
.macro idct32_odd
movrel r12, idct_coeffs
-add r12, r12, #32
-vld1.16 {q0-q1}, [r12,:128]
-vmovl.s16 q2, d2
-vmovl.s16 q3, d3
-vmovl.s16 q1, d1
-vmovl.s16 q0, d0
+
+@ Overwrite the idct16 coeffs with the stored ones for idct32
+vmovl.s16 q0, d12
+vmovl.s16 q1, d13
+vmovl.s16 q2, d14
+vmovl.s16 q3, d15
mbutterfly d16, d31, d0[0], d0[1], q4, q5 @ d16 = t16a, d31 = t31a
mbutterfly d24, d23, d1[0], d1[1], q4, q5 @ d24 = t17a, d23 = t30a
@@ -1211,15 +1211,19 @@ endfunc
mbutterfly d22, d25, d6[0], d6[1], q4, q5 @ d22 = t22a, d25 = t25a
mbutterfly d30, d17, d7[0], d7[1], q4, q5 @ d30 = t23a, d17 = t24a
-sub r12, r12, #32
-vld1.16 {q0}, [r12,:128]
+@ Reload the idct16 coefficients. We could swap the coefficients
between
+@ q0-q3 and q6-q7 by narrowing/lengthening, but that's slower than just
+@ loading and lengthening.
+vld1.16 {q0-q1}, [r12,:128]
+
+butterfly d8, d24, d16, d24 @ d8 = t16, d24 = t17
+butterfly d9, d20, d28, d20 @ d9 = t19, d20 = t18
+butterfly d10, d26, d18, d26 @ d10 = t20, d26 = t21
+butterfly d11, d22, d30, d22 @ d11 = t23, d22 = t22
+vmovl.s16 q2, d2
+vmovl.s16 q3, d3
vmovl.s16 q1, d1
vmovl.s16 q0, d0
-
-butterfly d4, d24, d16, d24 @ d4 = t16, d24 = t17
-butterfly d5, d20, d28, d20 @ d5 = t19, d20 = t18
-butterfly d6, d26, d18, d26 @ d6 = t20, d26 = t21
-butterfly d7, d22, d30, d22 @ d7 = t23, d22 = t22
butterfly d28, d25, d17, d25 @ d28 = t24, d25 = t25
butterfly d30, d21, d29, d21 @ d30 = t27, d21 = t26
butterfly d29, d23, d31, d23 @ d29 = t31, d23 = t30
@@ -1230,34 +1234,34 @@ endfunc
mbutterfly d21, d26, d3[0], d3[1], q8, q9@ d21 = t21a,
d26 = t26a
mbutterfly d25, d22, d3[0], d3[1], q8, q9, neg=1 @ d25 = t25a,
d22 = t22a
-butterfly d16, d5, d4, d5 @ d16 = t16a, d5 = t19a
+butterfly d16, d9, d8, d9 @ d16 = t16a, d9 = t19a
butterfly d17, d20, d23, d20 @ d17 = t17, d20 = t18
-butterfly d18, d6, d7, d6 @ d18 = t23a, d6 = t20a
+butterfly d18, d10, d11, d10 @ d18 = t23a, d10 = t20a
butterfly d19, d21, d22, d21 @ d19 = t22, d21 = t21
-butterfly d4, d28, d28, d30 @ d4 = t24a, d28 = t27a
+butterfly d8, d28, d28, d30 @ d8 = t24a, d28 = t27a
butterfly d23, d26, d25, d26 @ d23 = t25, d26 = t26
-butterfly d7, d29, d29, d31 @ d7 = t31a, d29 = t28a
+butterfly d11, d29, d29, d31 @ d11 = t31a, d29 = t28a
butterfly d22, d27, d24, d27 @ d22 = t30, d27 = t29
mbutterfly d27, d20, d1[0], d1[1], q12, q15@ d27 = t18a,
d20 = t29a
-mbutterfly d29, d5, d1[0], d1[1], q12, q15@ d29 = t19,
d5 = t28
-mbutterfly d28, d6, d1[0], d1[1], q12, q15, neg=1 @ d28 = t27,
d6 = t20
+mbutterfly d29, d9, d1[0], d1[1], q12, q15@ d29 = t19,
d9 = t28
+mbutterfly d28, d10, d1[0], d1[1], q12, q15, neg=1 @ d28 = t27,
d10 = t20
mbutterfly d26, d21, d1[0], d1[1], q12, q15, neg=1 @ d26 = t26a,
d21 = t21a
-butterfly d31, d24, d7, d4 @ d31 = t31, d24 = t24
+butterfly d31, d24, d11, d8 @ d31 = t31, d24 = t24
butterfly d30, d25, d
[FFmpeg-devel] [PATCH 02/14] arm/aarch64: vp9itxfm: Skip loading the min_eob pointer when it won't be used
In the half/quarter cases where we don't use the min_eob array, defer
loading the pointer until we know it will be needed.
This is cherrypicked from libav commit
3a0d5e206d24d41d87a25ba16a79b2ea04c39d4c.
---
libavcodec/aarch64/vp9itxfm_neon.S | 3 ++-
libavcodec/arm/vp9itxfm_neon.S | 4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/aarch64/vp9itxfm_neon.S
b/libavcodec/aarch64/vp9itxfm_neon.S
index 2c3c002..3e5da08 100644
--- a/libavcodec/aarch64/vp9itxfm_neon.S
+++ b/libavcodec/aarch64/vp9itxfm_neon.S
@@ -1483,7 +1483,6 @@ function ff_vp9_idct_idct_32x32_add_neon, export=1
b.eqidct32x32_dc_add_neon
movrel x10, idct_coeffs
-movrel x12, min_eob_idct_idct_32, 2
mov x15, x30
@@ -1508,6 +1507,8 @@ function ff_vp9_idct_idct_32x32_add_neon, export=1
cmp w3, #135
b.leidct32x32_half_add_neon
+movrel x12, min_eob_idct_idct_32, 2
+
.irp i, 0, 8, 16, 24
add x0, sp, #(\i*64)
.if \i > 0
diff --git a/libavcodec/arm/vp9itxfm_neon.S b/libavcodec/arm/vp9itxfm_neon.S
index adc9896..6d4d765 100644
--- a/libavcodec/arm/vp9itxfm_neon.S
+++ b/libavcodec/arm/vp9itxfm_neon.S
@@ -889,8 +889,6 @@ function ff_vp9_\txfm1\()_\txfm2\()_16x16_add_neon, export=1
push{r4-r8,lr}
.ifnc \txfm1\()_\txfm2,idct_idct
vpush {q4-q7}
-.else
-movrel r8, min_eob_idct_idct_16 + 2
.endif
@ Align the stack, allocate a temp buffer
@@ -914,6 +912,8 @@ A and r7, sp, #15
ble idct16x16_quarter_add_neon
cmp r3, #38
ble idct16x16_half_add_neon
+
+movrel r8, min_eob_idct_idct_16 + 2
.endif
.irp i, 0, 4, 8, 12
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 05/14] arm: vp9itxfm16: Fix vertical alignment
---
libavcodec/arm/vp9itxfm_16bpp_neon.S | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/libavcodec/arm/vp9itxfm_16bpp_neon.S
b/libavcodec/arm/vp9itxfm_16bpp_neon.S
index a92f323..9c02ed9 100644
--- a/libavcodec/arm/vp9itxfm_16bpp_neon.S
+++ b/libavcodec/arm/vp9itxfm_16bpp_neon.S
@@ -1395,25 +1395,25 @@ function idct32_1d_2x32_pass2_neon
vld1.32 {d4}, [r2,:64], r12
vld1.32 {d5}, [r2,:64], r12
.if \neg == 0
-vadd.s32d4, d4, d\a
+vadd.s32d4, d4, d\a
vld1.32 {d6}, [r2,:64], r12
-vadd.s32d5, d5, d\b
+vadd.s32d5, d5, d\b
vld1.32 {d7}, [r2,:64], r12
-vadd.s32d6, d6, d\c
-vadd.s32d7, d7, d\d
+vadd.s32d6, d6, d\c
+vadd.s32d7, d7, d\d
.else
-vsub.s32d4, d4, d\a
+vsub.s32d4, d4, d\a
vld1.32 {d6}, [r2,:64], r12
-vsub.s32d5, d5, d\b
+vsub.s32d5, d5, d\b
vld1.32 {d7}, [r2,:64], r12
-vsub.s32d6, d6, d\c
-vsub.s32d7, d7, d\d
+vsub.s32d6, d6, d\c
+vsub.s32d7, d7, d\d
.endif
vld1.32 {d2[]}, [r0,:32], r1
vld1.32 {d2[1]}, [r0,:32], r1
-vrshr.s32 q2, q2, #6
+vrshr.s32 q2, q2, #6
vld1.32 {d3[]}, [r0,:32], r1
-vrshr.s32 q3, q3, #6
+vrshr.s32 q3, q3, #6
vld1.32 {d3[1]}, [r0,:32], r1
sub r0, r0, r1, lsl #2
vaddw.u16 q2, q2, d2
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 07/14] aarch64: vp9itxfm16: Fix a typo in a comment
--- libavcodec/aarch64/vp9itxfm_16bpp_neon.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/aarch64/vp9itxfm_16bpp_neon.S b/libavcodec/aarch64/vp9itxfm_16bpp_neon.S index f53e94a..f80604f 100644 --- a/libavcodec/aarch64/vp9itxfm_16bpp_neon.S +++ b/libavcodec/aarch64/vp9itxfm_16bpp_neon.S @@ -872,7 +872,7 @@ function \txfm\()16_1d_4x16_pass1_neon transpose_4x4s v24, v25, v26, v27, v4, v5, v6, v7 transpose_4x4s v28, v29, v30, v31, v4, v5, v6, v7 -// Store the transposed 8x8 blocks horizontally. +// Store the transposed 4x4 blocks horizontally. cmp x1, #12 b.eq1f .irp i, 16, 20, 24, 28, 17, 21, 25, 29, 18, 22, 26, 30, 19, 23, 27, 31 -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 13/14] arm: vp9itxfm16: Do a simpler half/quarter idct16/idct32 when possible
This work is sponsored by, and copyright, Google. This avoids loading and calculating coefficients that we know will be zero, and avoids filling the temp buffer with zeros in places where we know the second pass won't read. This gives a pretty substantial speedup for the smaller subpartitions. The code size increases from 14516 bytes to 22484 bytes. The idct16/32_end macros are moved above the individual functions; the instructions themselves are unchanged, but since new functions are added at the same place where the code is moved from, the diff looks rather messy. Before: Cortex A7 A8 A9 A53 vp9_inv_dct_dct_16x16_sub1_add_10_neon: 454.0270.7418.5295.4 vp9_inv_dct_dct_16x16_sub2_add_10_neon:3840.2 3244.8 3700.1 2337.9 vp9_inv_dct_dct_16x16_sub4_add_10_neon:4212.5 3575.4 3996.9 2571.6 vp9_inv_dct_dct_16x16_sub8_add_10_neon:5174.4 4270.5 4615.5 3031.9 vp9_inv_dct_dct_16x16_sub12_add_10_neon: 5676.0 4908.5 5226.5 3491.3 vp9_inv_dct_dct_16x16_sub16_add_10_neon: 6403.9 5589.0 5839.8 3948.5 vp9_inv_dct_dct_32x32_sub1_add_10_neon:1710.7944.7 1582.1 1045.4 vp9_inv_dct_dct_32x32_sub2_add_10_neon: 21040.7 16706.1 18687.7 13193.1 vp9_inv_dct_dct_32x32_sub4_add_10_neon: 22197.7 18282.7 19577.5 13918.6 vp9_inv_dct_dct_32x32_sub8_add_10_neon: 24511.5 20911.5 21472.5 15367.5 vp9_inv_dct_dct_32x32_sub12_add_10_neon: 26939.5 24264.3 23239.1 16830.3 vp9_inv_dct_dct_32x32_sub16_add_10_neon: 29419.5 26845.1 25020.6 18259.9 vp9_inv_dct_dct_32x32_sub20_add_10_neon: 31146.4 29633.5 26803.3 19721.7 vp9_inv_dct_dct_32x32_sub24_add_10_neon: 33376.3 32507.8 28642.4 21174.2 vp9_inv_dct_dct_32x32_sub28_add_10_neon: 35629.4 35439.6 30416.5 22625.7 vp9_inv_dct_dct_32x32_sub32_add_10_neon: 37269.9 37914.9 32271.9 24078.9 After: vp9_inv_dct_dct_16x16_sub1_add_10_neon: 454.0276.0418.5295.1 vp9_inv_dct_dct_16x16_sub2_add_10_neon:2336.2 1886.0 2251.0 1458.6 vp9_inv_dct_dct_16x16_sub4_add_10_neon:2531.0 2054.7 2402.8 1591.1 vp9_inv_dct_dct_16x16_sub8_add_10_neon:3848.6 3491.1 3845.7 2554.8 vp9_inv_dct_dct_16x16_sub12_add_10_neon: 5703.8 4831.6 5230.8 3493.4 vp9_inv_dct_dct_16x16_sub16_add_10_neon: 6399.5 5567.0 5832.4 3951.5 vp9_inv_dct_dct_32x32_sub1_add_10_neon:1722.1938.5 1577.3 1044.5 vp9_inv_dct_dct_32x32_sub2_add_10_neon: 15003.5 11576.8 13105.8 9602.2 vp9_inv_dct_dct_32x32_sub4_add_10_neon: 15768.5 12677.2 13726.0 10138.1 vp9_inv_dct_dct_32x32_sub8_add_10_neon: 17278.8 14825.4 14907.5 11185.7 vp9_inv_dct_dct_32x32_sub12_add_10_neon: 22335.7 21544.5 20379.5 15019.8 vp9_inv_dct_dct_32x32_sub16_add_10_neon: 24165.6 23881.7 21938.6 16308.2 vp9_inv_dct_dct_32x32_sub20_add_10_neon: 31082.2 30860.9 26835.3 19711.3 vp9_inv_dct_dct_32x32_sub24_add_10_neon: 33102.6 31922.8 28638.3 21161.0 vp9_inv_dct_dct_32x32_sub28_add_10_neon: 35104.9 34867.5 30411.7 22621.2 vp9_inv_dct_dct_32x32_sub32_add_10_neon: 37438.1 39103.4 32217.8 24067.6 --- libavcodec/arm/vp9itxfm_16bpp_neon.S | 529 +++ 1 file changed, 469 insertions(+), 60 deletions(-) diff --git a/libavcodec/arm/vp9itxfm_16bpp_neon.S b/libavcodec/arm/vp9itxfm_16bpp_neon.S index 8350153..b4f615e 100644 --- a/libavcodec/arm/vp9itxfm_16bpp_neon.S +++ b/libavcodec/arm/vp9itxfm_16bpp_neon.S @@ -82,6 +82,14 @@ endconst vrshrn.s64 \out2, \tmpq4, #14 .endm +@ Same as mbutterfly0 above, but treating the input in in2 as zero, +@ writing the same output into both out1 and out2. +.macro mbutterfly0_h out1, out2, in1, in2, tmpd1, tmpd2, tmpq3, tmpq4 +vmull.s32 \tmpq3, \in1, d0[0] +vrshrn.s64 \out1, \tmpq3, #14 +vrshrn.s64 \out2, \tmpq3, #14 +.endm + @ out1,out2 = ((in1 + in2) * d0[0] + (1 << 13)) >> 14 @ out3,out4 = ((in1 - in2) * d0[0] + (1 << 13)) >> 14 @ Same as mbutterfly0, but with input being 2 q registers, output @@ -148,6 +156,23 @@ endconst vrshrn.s64 \inout2, \tmp2, #14 .endm +@ Same as mbutterfly above, but treating the input in inout2 as zero +.macro mbutterfly_h1 inout1, inout2, coef1, coef2, tmp1, tmp2 +vmull.s32 \tmp1, \inout1, \coef1 +vmull.s32 \tmp2, \inout1, \coef2 +vrshrn.s64 \inout1, \tmp1, #14 +vrshrn.s64 \inout2, \tmp2, #14 +.endm + +@ Same as mbutterfly above, but treating the input in inout1 as zero +.macro mbutterfly_h2 inout1, inout2, coef1, coef2, tmp1, tmp2 +vmov.s64\tmp1, #0 +vmull.s32 \tmp2, \inout2, \coef1 +vmlsl.s32 \tmp1, \inout2, \coef2 +vrshrn.s64 \inout2, \tmp2, #14 +vrshrn.s64 \inout1, \tmp1, #14 +.endm + @ inout1,inout2 = (inout1,inout2 * coef1 - inout3,inout4 * coef2 + (1 << 13)) >> 14 @ inout3,inout4 = (inout1,inout2 * coef2 + inout3,inout4
[FFmpeg-devel] [PATCH 04/14] arm: vp9itxfm16: Use the right lane size
This makes the code slightly clearer, but doesn't make any functional difference. --- libavcodec/arm/vp9itxfm_16bpp_neon.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/arm/vp9itxfm_16bpp_neon.S b/libavcodec/arm/vp9itxfm_16bpp_neon.S index e6e9440..a92f323 100644 --- a/libavcodec/arm/vp9itxfm_16bpp_neon.S +++ b/libavcodec/arm/vp9itxfm_16bpp_neon.S @@ -1082,8 +1082,8 @@ A and r7, sp, #15 .ifc \txfm1\()_\txfm2,idct_idct b 3f 1: -vmov.i16q14, #0 -vmov.i16q15, #0 +vmov.i32q14, #0 +vmov.i32q15, #0 2: subsr1, r1, #1 @ Unroll for 2 lines -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 01/14] arm: vp9itxfm: Template the quarter/half idct32 function
This reduces the number of lines and reduces the duplication.
Also simplify the eob check for the half case.
If we are in the half case, we know we at least will need to do the
first three slices, we only need to check eob for the fourth one,
so we can hardcode the value to check against instead of loading
from the min_eob array.
Since at most one slice can be skipped in the first pass, we can
unroll the loop for filling zeros completely, as it was done for
the quarter case before.
This allows skipping loading the min_eob pointer when using the
quarter/half cases.
This is cherrypicked from libav commit
98ee855ae0cc118bd1d20921d6bdb14731832462.
---
libavcodec/arm/vp9itxfm_neon.S | 57 +++---
1 file changed, 20 insertions(+), 37 deletions(-)
diff --git a/libavcodec/arm/vp9itxfm_neon.S b/libavcodec/arm/vp9itxfm_neon.S
index ebbbda9..adc9896 100644
--- a/libavcodec/arm/vp9itxfm_neon.S
+++ b/libavcodec/arm/vp9itxfm_neon.S
@@ -1575,7 +1575,6 @@ function ff_vp9_idct_idct_32x32_add_neon, export=1
beq idct32x32_dc_add_neon
push{r4-r8,lr}
vpush {q4-q6}
-movrel r8, min_eob_idct_idct_32 + 2
@ Align the stack, allocate a temp buffer
T mov r7, sp
@@ -1597,6 +1596,8 @@ A and r7, sp, #15
cmp r3, #135
ble idct32x32_half_add_neon
+movrel r8, min_eob_idct_idct_32 + 2
+
.irp i, 0, 4, 8, 12, 16, 20, 24, 28
add r0, sp, #(\i*64)
.if \i > 0
@@ -1634,72 +1635,54 @@ A and r7, sp, #15
pop {r4-r8,pc}
endfunc
-function idct32x32_quarter_add_neon
+.macro idct32_partial size
+function idct32x32_\size\()_add_neon
.irp i, 0, 4
add r0, sp, #(\i*64)
+.ifc \size,quarter
.if \i == 4
cmp r3, #9
ble 1f
.endif
+.endif
add r2, r6, #(\i*2)
-bl idct32_1d_4x32_pass1_quarter_neon
-.endr
-b 3f
-
-1:
-@ Write zeros to the temp buffer for pass 2
-vmov.i16q14, #0
-vmov.i16q15, #0
-.rept 8
-vst1.16 {q14-q15}, [r0,:128]!
-.endr
-3:
-.irp i, 0, 4, 8, 12, 16, 20, 24, 28
-add r0, r4, #(\i)
-mov r1, r5
-add r2, sp, #(\i*2)
-bl idct32_1d_4x32_pass2_quarter_neon
+bl idct32_1d_4x32_pass1_\size\()_neon
.endr
-add sp, sp, r7
-vpop{q4-q6}
-pop {r4-r8,pc}
-endfunc
-
-function idct32x32_half_add_neon
-.irp i, 0, 4, 8, 12
+.ifc \size,half
+.irp i, 8, 12
add r0, sp, #(\i*64)
-.if \i > 0
-ldrh_post r1, r8, #2
-cmp r3, r1
-it le
-movle r1, #(16 - \i)/2
+.if \i == 12
+cmp r3, #70
ble 1f
.endif
add r2, r6, #(\i*2)
-bl idct32_1d_4x32_pass1_half_neon
+bl idct32_1d_4x32_pass1_\size\()_neon
.endr
+.endif
b 3f
1:
@ Write zeros to the temp buffer for pass 2
vmov.i16q14, #0
vmov.i16q15, #0
-2:
-subsr1, r1, #1
-.rept 4
+.rept 8
vst1.16 {q14-q15}, [r0,:128]!
.endr
-bne 2b
+
3:
.irp i, 0, 4, 8, 12, 16, 20, 24, 28
add r0, r4, #(\i)
mov r1, r5
add r2, sp, #(\i*2)
-bl idct32_1d_4x32_pass2_half_neon
+bl idct32_1d_4x32_pass2_\size\()_neon
.endr
add sp, sp, r7
vpop{q4-q6}
pop {r4-r8,pc}
endfunc
+.endm
+
+idct32_partial quarter
+idct32_partial half
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] decklink: add fourCC of display mode to list_format output
On Thu, 16 Mar 2017, Matthias Hunstock wrote:
Am 16.03.2017 um 20:55 schrieb Marton Balint:
On Thu, 16 Mar 2017, Matthias Hunstock wrote:
---
libavdevice/decklink_common.cpp | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/libavdevice/decklink_common.cpp
b/libavdevice/decklink_common.cpp
index 8b499c5..131d186 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -276,6 +276,7 @@ int ff_decklink_list_formats(AVFormatContext
*avctx, decklink_direction_t direct
struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
IDeckLinkDisplayModeIterator *itermode;
IDeckLinkDisplayMode *mode;
+char fourcc[32];
int i=0;
HRESULT res;
@@ -297,13 +298,15 @@ int ff_decklink_list_formats(AVFormatContext
*avctx, decklink_direction_t direct
return AVERROR(EIO);
}
-av_log(avctx, AV_LOG_INFO, "Supported formats for '%s':\n",
+av_log(avctx, AV_LOG_INFO, "Supported formats for
'%s':\n\tmode\tfourCC\tdescription",
avctx->filename);
while (itermode->Next(&mode) == S_OK) {
BMDTimeValue tb_num, tb_den;
mode->GetFrameRate(&tb_num, &tb_den);
-av_log(avctx, AV_LOG_INFO, "\t%d\t%ldx%ld at %d/%d fps",
-++i,mode->GetWidth(), mode->GetHeight(),
+av_get_codec_tag_string(fourcc, sizeof(fourcc),
mode->GetDisplayMode());
+av_log(avctx, AV_LOG_INFO, "\n\t%d\t%c%c%c%c\t%ldx%ld at
%d/%d fps",
+++i, fourcc[3], fourcc[2], fourcc[1], fourcc[0],
+mode->GetWidth(), mode->GetHeight(),
fourcc is a string, is there a reason why you don't simply print it
using "%s"?
Yes, unfortunately the order is reversed then, and I considered 'cstn'
or '05iH' harder to remember and use than 'ntsc' or 'Hi50'. Did not find
any util function that does the fourCC conversion in that reverse order.
Oh, I see. Maybe you can use av_bswap32 to transform the BMDDisplayMode to
the proper byte order before transfroming it to fourcc string.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] decklink: new option 'format' to set video format by fourCC
2017-03-16 21:54 GMT+01:00 Marton Balint : > > On Thu, 16 Mar 2017, Nicolas George wrote: > >> Le sextidi 26 ventôse, an CCXXV, Matthias Hunstock a écrit : >>> >>> I did not find a comparable option for another device in libavdevice, >>> "format" was the initial suggestion of Marton. This is at least >>> consistent with the existing "list_formats" option. >> >> >> I do not know what the option does, and therefore can not propose a >> better name. > > > It selects video standard, field order and frame rate, these fourcc-s are > defined in the BlackMagic SDK. Example: 'Hp50' - HD 1080p50 format. I believe our v4l2 device calls the option "input_format". Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] decklink: new option 'format' to set video format by fourCC
On Thu, 16 Mar 2017, Matthias Hunstock wrote:
---
libavdevice/decklink_common.cpp | 22 ++
libavdevice/decklink_common_c.h | 1 +
libavdevice/decklink_dec.cpp| 2 +-
libavdevice/decklink_dec_c.c| 1 +
4 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index 131d186..548bf3b 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -143,6 +143,18 @@ static DECKLINK_BOOL field_order_eq(enum AVFieldOrder
field_order, BMDFieldDomin
return false;
}
+static DECKLINK_BOOL fourcc_eq(char *fourcc_string, BMDDisplayMode fourcc)
+{
+BMDDisplayMode fourcc_converted = 0;
+if (!fourcc_string) return false;
+if (!strcmp(fourcc_string, "pal") && fourcc == 0x70616C20) return true;
+if (strlen(fourcc_string) < 4) return false;
+fourcc_converted = ((uint8_t) fourcc_string[0] << 24) | ((uint8_t)
fourcc_string[1] << 16) |
+((uint8_t) fourcc_string[2] << 8) | ((uint8_t) fourcc_string[3]);
+if (fourcc_converted == fourcc) return true;
+return false;
+}
I think I'd use a little different approach. Instead of a separate _eq
function, I'd transfrom the fourcc string to an int32 by padding it with 4
spaces, then use AV_RL32(padded_fourcc) to get an actual int32. I can now
simply compare this to BMDDisplayMode.
+
int ff_decklink_set_format(AVFormatContext *avctx,
int width, int height,
int tb_num, int tb_den,
@@ -157,8 +169,8 @@ int ff_decklink_set_format(AVFormatContext *avctx,
int i = 1;
HRESULT res;
-av_log(avctx, AV_LOG_DEBUG, "Trying to find mode for frame size %dx%d, frame
timing %d/%d, field order %d, direction %d, mode number %d\n",
-width, height, tb_num, tb_den, field_order, direction, num);
+av_log(avctx, AV_LOG_DEBUG, "Trying to find mode for frame size %dx%d, frame
timing %d/%d, field order %d, direction %d, mode number %d, mode fourCC %s\n",
+width, height, tb_num, tb_den, field_order, direction, num,
cctx->format);
cctx->format ? cctx->format : "(unset)"
if (ctx->duplex_mode) {
DECKLINK_BOOL duplex_supported = false;
@@ -202,6 +214,7 @@ int ff_decklink_set_format(AVFormatContext *avctx,
int bmd_width = mode->GetWidth();
int bmd_height = mode->GetHeight();
BMDFieldDominance bmd_field_dominance = mode->GetFieldDominance();
+BMDDisplayMode bmd_mode = mode->GetDisplayMode();
mode->GetFrameRate(&bmd_tb_num, &bmd_tb_den);
AVRational mode_tb = av_make_q(bmd_tb_num, bmd_tb_den);
@@ -209,8 +222,9 @@ int ff_decklink_set_format(AVFormatContext *avctx,
if ((bmd_width == width &&
bmd_height == height &&
!av_cmp_q(mode_tb, target_tb) &&
- field_order_eq(field_order, bmd_field_dominance)) || i == num) {
-ctx->bmd_mode = mode->GetDisplayMode();
+ field_order_eq(field_order, bmd_field_dominance))
+ || i == num || fourcc_eq(cctx->format, bmd_mode)) {
+ctx->bmd_mode = bmd_mode;
ctx->bmd_width = bmd_width;
ctx->bmd_height = bmd_height;
ctx->bmd_tb_den = bmd_tb_den;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index d565631..161a48a 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -47,6 +47,7 @@ struct decklink_cctx {
int audio_input;
int video_input;
int draw_bars;
+char *format;
};
#endif /* AVDEVICE_DECKLINK_COMMON_C_H */
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 7df841b..594 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -539,7 +539,7 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
goto error;
}
-if (mode_num > 0) {
+if (mode_num > 0 || cctx->format) {
if (ff_decklink_set_format(avctx, DIRECTION_IN, mode_num) < 0) {
av_log(avctx, AV_LOG_ERROR, "Could not set mode %d for %s\n",
mode_num, fname);
ret = AVERROR(EIO);
diff --git a/libavdevice/decklink_dec_c.c b/libavdevice/decklink_dec_c.c
index 31818d2..07da7cc 100644
--- a/libavdevice/decklink_dec_c.c
+++ b/libavdevice/decklink_dec_c.c
@@ -31,6 +31,7 @@
static const AVOption options[] = {
{ "list_devices", "list available devices" , OFFSET(list_devices),
AV_OPT_TYPE_INT , { .i64 = 0 }, 0, 1, DEC },
{ "list_formats", "list supported formats" , OFFSET(list_formats),
AV_OPT_TYPE_INT , { .i64 = 0 }, 0, 1, DEC },
+{ "format", "set format by fourcc", OFFSET(format),
AV_OPT_TYPE_STRING, { .str = NULL}, 3, 4, DEC },
{ "bm_v210", "v210 10 bit per channel" , OFFSET(v210),
AV_OPT_TYPE_INT , { .i64 = 0 }, 0, 1, DEC },
{ "teletext_lines", "teletext lines bitmask", OFFSET(teletext_lines),
AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, 0
[FFmpeg-devel] [PATCH]lavc/avcodec: Constify AVBitStreamFilter* in AVBitStreamFilterContext struct.
Hi!
Attached patch fixes one of two remaining warnings when compiling
bitstream_filter.c.
Please comment, Carl Eugen
From 7fb60d42ee2137d1181ad0f6e214df87ed06400e Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 16 Mar 2017 22:31:44 +0100
Subject: [PATCH] lavc/avcodec: Constify AVBitStreamFilter* in
AVBitStreamFilterContext struct.
Fixes a gcc warning:
libavcodec/bitstream_filter.c:71:20: warning: assignment discards 'const'
qualifier from pointer target type
---
libavcodec/avcodec.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 1923c96..8774718 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -5764,7 +5764,7 @@ int av_get_audio_frame_duration2(AVCodecParameters *par,
int frame_bytes);
#if FF_API_OLD_BSF
typedef struct AVBitStreamFilterContext {
void *priv_data;
-struct AVBitStreamFilter *filter;
+const struct AVBitStreamFilter *filter;
AVCodecParserContext *parser;
struct AVBitStreamFilterContext *next;
/**
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] decklink: add fourCC of display mode to list_format output
Am 16.03.2017 um 20:55 schrieb Marton Balint:
>
>
> On Thu, 16 Mar 2017, Matthias Hunstock wrote:
>
>> ---
>> libavdevice/decklink_common.cpp | 11 +++
>> 1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavdevice/decklink_common.cpp
>> b/libavdevice/decklink_common.cpp
>> index 8b499c5..131d186 100644
>> --- a/libavdevice/decklink_common.cpp
>> +++ b/libavdevice/decklink_common.cpp
>> @@ -276,6 +276,7 @@ int ff_decklink_list_formats(AVFormatContext
>> *avctx, decklink_direction_t direct
>> struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
>> IDeckLinkDisplayModeIterator *itermode;
>> IDeckLinkDisplayMode *mode;
>> +char fourcc[32];
>> int i=0;
>> HRESULT res;
>>
>> @@ -297,13 +298,15 @@ int ff_decklink_list_formats(AVFormatContext
>> *avctx, decklink_direction_t direct
>> return AVERROR(EIO);
>> }
>>
>> -av_log(avctx, AV_LOG_INFO, "Supported formats for '%s':\n",
>> +av_log(avctx, AV_LOG_INFO, "Supported formats for
>> '%s':\n\tmode\tfourCC\tdescription",
>>avctx->filename);
>> while (itermode->Next(&mode) == S_OK) {
>> BMDTimeValue tb_num, tb_den;
>> mode->GetFrameRate(&tb_num, &tb_den);
>> -av_log(avctx, AV_LOG_INFO, "\t%d\t%ldx%ld at %d/%d fps",
>> -++i,mode->GetWidth(), mode->GetHeight(),
>> +av_get_codec_tag_string(fourcc, sizeof(fourcc),
>> mode->GetDisplayMode());
>> +av_log(avctx, AV_LOG_INFO, "\n\t%d\t%c%c%c%c\t%ldx%ld at
>> %d/%d fps",
>> +++i, fourcc[3], fourcc[2], fourcc[1], fourcc[0],
>> +mode->GetWidth(), mode->GetHeight(),
>
> fourcc is a string, is there a reason why you don't simply print it
> using "%s"?
Yes, unfortunately the order is reversed then, and I considered 'cstn'
or '05iH' harder to remember and use than 'ntsc' or 'Hi50'. Did not find
any util function that does the fourCC conversion in that reverse order.
Matthias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/bitstream_filter: Make a cast explicit
2017-03-01 23:36 GMT+01:00 Carl Eugen Hoyos : > Hi! > > Attached patch silences one of three warnings when compiling > bitstream_filter.o, I suspect this cast is necessary. Ping. This seems to be another patch that does not show up on patchwork.ffmpeg.org (or that I cannot find there). Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] Implement optimal huffman encoding for (M)JPEG.
> ffmpeg | branch: master | Jerry Jiang | Wed Feb > 1 23:23:04 2017 -0800| [884506dfe2e29a5b2bd2905ca4f17e277e32acb1] | > committer: Rostislav Pehlivanov > > Implement optimal huffman encoding for (M)JPEG. > > > seems to break > > make fate-vsynth1-mjpeg-444 > > Fixed. > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=884506dfe2e29a5b2bd2905ca4f17e277e32acb1 > --- > > Changelog| 1 + > doc/encoders.texi| 21 ++ > libavcodec/Makefile | 8 +- > libavcodec/mjpegenc.c| 243 > +-- > libavcodec/mjpegenc.h| 68 ++- > libavcodec/mjpegenc_common.c | 166 +++- > libavcodec/mjpegenc_common.h | 2 + > libavcodec/mjpegenc_huffman.c| 195 ++ > libavcodec/mjpegenc_huffman.h| 74 +++ > libavcodec/mpegvideo.h | 1 + > libavcodec/mpegvideo_enc.c | 17 +- > libavcodec/tests/.gitignore | 1 + > libavcodec/tests/mjpegenc_huffman.c | 163 +++ > tests/fate/libavcodec.mak| 6 + > tests/fate/vcodec.mak| 12 +- > tests/ref/vsynth/vsynth1-mjpeg-huffman | 4 + > tests/ref/vsynth/vsynth1-mjpeg-trell-huffman | 4 + > tests/ref/vsynth/vsynth2-mjpeg-huffman | 4 + > tests/ref/vsynth/vsynth2-mjpeg-trell-huffman | 4 + > tests/ref/vsynth/vsynth3-mjpeg-huffman | 4 + > tests/ref/vsynth/vsynth3-mjpeg-trell-huffman | 4 + > tests/ref/vsynth/vsynth_lena-mjpeg-huffman | 4 + > tests/ref/vsynth/vsynth_lena-mjpeg-trell-huffman | 4 + > 23 files changed, 914 insertions(+), 96 deletions(-) > This broke valgrind/gcc-asan http://fate.ffmpeg.org/report.cgi?time=20170316170150&slot=x86_64-archlinux-gcc-asan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavu/spherical: Make first parameter const
2017-03-16 21:23 GMT+01:00 Carl Eugen Hoyos : > Hi! > > Attached patch silences a gcc warning when compiling ffprobe. Patch applied. Thank you both, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] spherical: Change types of bounding and pad to uint32_t
2017-03-16 22:12 GMT+01:00 Vittorio Giovara : > On Thu, Mar 16, 2017 at 4:16 PM, Lou Logan wrote: >> On Wed, 15 Mar 2017 10:22:23 +0100 >> Carl Eugen Hoyos wrote: >> >>> Sorry if I miss something but could you clarify who the author of this >>> patch is? >> >> CC'ing as Vittorio is not subscribed to the mailing list. Not that you >> should have to know that as there was no CC request in this particular >> message. > > Hi, I'm not sure I understand the question. > I wrote the patch, (This surprises me but this is of course possible.) > and I'll mention it's based on one from Michael. But so far you didn't mention it or did you? Note that if your patch is not based on Michael's patch (which the first paragraph in your email implies) then please do not mention that it is based on Michael's patch (and please accept my apologies for a wrong accusation in this case). Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] spherical: Change types of bounding and pad to uint32_t
On Thu, Mar 16, 2017 at 4:16 PM, Lou Logan wrote: > On Wed, 15 Mar 2017 10:22:23 +0100 > Carl Eugen Hoyos wrote: > >> Sorry if I miss something but could you clarify who the author of this >> patch is? > > CC'ing as Vittorio is not subscribed to the mailing list. Not that you > should have to know that as there was no CC request in this particular > message. Hi, I'm not sure I understand the question. I wrote the patch, and I'll mention it's based on one from Michael. Is there some problem with it? Thanks for the CC. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavu/spherical: Make first parameter const
On Thu, Mar 16, 2017 at 4:26 PM, James Almer wrote: > On 3/16/2017 5:23 PM, Carl Eugen Hoyos wrote: >> Hi! >> >> Attached patch silences a gcc warning when compiling ffprobe. >> >> Please comment, Carl Eugen >> >> >> 0001-lavu-spherical-Make-AVSphericalMapping-pointer-param.patch >> >> >> From 5040ee6f7dd43c8d66a241aa0376839916cd3d9f Mon Sep 17 00:00:00 2001 >> From: Carl Eugen Hoyos >> Date: Thu, 16 Mar 2017 21:19:48 +0100 >> Subject: [PATCH] lavu/spherical: Make AVSphericalMapping pointer parameter >> const. >> >> Reflects the actual code and silences a gcc warning: >> ffprobe.c:1797:42: warning: passing argument 1 of 'av_spherical_tile_bounds' >> discards 'const' qualifier from pointer target type >> --- >> libavutil/spherical.c |2 +- >> libavutil/spherical.h |2 +- >> 2 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/libavutil/spherical.c b/libavutil/spherical.c >> index 0ca2dd3..f0b6221 100644 >> --- a/libavutil/spherical.c >> +++ b/libavutil/spherical.c >> @@ -33,7 +33,7 @@ AVSphericalMapping *av_spherical_alloc(size_t *size) >> return spherical; >> } >> >> -void av_spherical_tile_bounds(AVSphericalMapping *map, >> +void av_spherical_tile_bounds(const AVSphericalMapping *map, >>size_t width, size_t height, >>size_t *left, size_t *top, >>size_t *right, size_t *bottom) >> diff --git a/libavutil/spherical.h b/libavutil/spherical.h >> index db9bdc0..f4e0d60 100644 >> --- a/libavutil/spherical.h >> +++ b/libavutil/spherical.h >> @@ -202,7 +202,7 @@ AVSphericalMapping *av_spherical_alloc(size_t *size); >> * @param right Pixels from the right edge. >> * @param bottom Pixels from the bottom edge. >> */ >> -void av_spherical_tile_bounds(AVSphericalMapping *map, >> +void av_spherical_tile_bounds(const AVSphericalMapping *map, >>size_t width, size_t height, >>size_t *left, size_t *top, >>size_t *right, size_t *bottom); >> -- 1.7.10.4 >> > > LGTM. The AVSphericalMapping struct is not modified by the function > so it should have been const since the beginning. > lgtm too -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] decklink: new option 'format' to set video format by fourCC
Le sextidi 26 ventôse, an CCXXV, Marton Balint a écrit : > It selects video standard, field order and frame rate, these fourcc-s are > defined in the BlackMagic SDK. Example: 'Hp50' - HD 1080p50 format. Then "format_code", "standard_code", "standard_id", etc. > The argument you made is true for a lot of other generic strings, such as > "video_format" or "standard" It is true for all strings, more or less. More for "format", already a lot less for the one you suggest right here. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libswscale/swscale_unscaled: fix DITHER_COPY macro
W dniu 2017-03-16 o 19:17, Michael Niedermayer pisze: > On Wed, Mar 15, 2017 at 10:52:29PM +0100, Mateusz Brzostek wrote: >> Hello! >> >> There are 3 problems with DITHER_COPY macro in libswscale/swscale_unscaled.c: >> 1) there is overflow in dithering from 12-bit to 10-bit (output value > >> 1023); >> 2) for limit range the lower limit is not respected, for example from 10-bit >> to 8-bit value 64 is converted to 15; >> 3) for many iteration of downscale/upscale of the same image the 200th >> iteration is significantly darker. >> >> The first bug is due to wrong dithers table (now it is OK only for 8-bit >> destination), fix is: >> -const uint8_t *dither= dithers[src_depth-9][i&7];\ >> +const uint8_t *dither= dithers[src_depth-dst_depth-1][i&7];\ >> >> For bugs 2) and 3) it is needed formula that do not make images darker (in >> attachment). So please review. > does your code maintain white and black levels ? > with 4 bits white is 15, with 7 bits white is 127 for example > white should stay white > black should stay black > in both directions === short version === Yes, white goes to white, black goes to black. === long version === This DITHER_COPY macro is for case when destination bit-depth >= 8 and source bit-depth > destination bit-depth and the picture type is the same (for example yuv444p12 to yuv444p10). It is replacement for down-shift. For destination bit-depth < 8 it is needed real dither (not simplified like this DITHER_COPY). The formula before the patch was: dst = (src + dither) * scale >> shift where: dst - destination, src - source, dither - constant values from table 8x8, scale and shift are chosen to fulfill formula (in mathematics/floating point arithmetic): (max_value_src + max_value_dither) * scale / (2^shift) < max_value_dst + 1 This is due to lack of clip function (for speed reason). If you consider (scale / (2^shift)) number for example for conversion 10-bit to 8-bit, we have (scale / (2^shift)) < 1/4 because (1023 + 3) * 1/4 = 256.5 and 256.5 >= 255 + 1 (with 1/4 there will be overflow: 1023 go to 256 for dither > 0). So for src > 0 with 2 least significant bits = 0 and dither = 0 we have dst <= (src >> 2) - 1 which is the darker destination effect (it is unavoidable in this model). In my patch the number (scale / (2^shift)) == 1/4 for 10-bit to 8-bit example. This fix the darker destination effect but create possible overflow problem. In my patch the possible overflow go to sign bit of int32_t variable and is clipped to 0x7FFF. In my tests the new DITHER_COPY is a little bit slower than old but is much faster than real dither in x265. Mateusz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] decklink: new option 'format' to set video format by fourCC
On Thu, 16 Mar 2017, Nicolas George wrote: Le sextidi 26 ventôse, an CCXXV, Matthias Hunstock a écrit : I did not find a comparable option for another device in libavdevice, "format" was the initial suggestion of Marton. This is at least consistent with the existing "list_formats" option. I do not know what the option does, and therefore can not propose a better name. It selects video standard, field order and frame rate, these fourcc-s are defined in the BlackMagic SDK. Example: 'Hp50' - HD 1080p50 format. All I know is that we decided not to build an inconvenient infrastructure to avoid the collision between global, format, codecs options, at the cost of having to be careful when adding said options. This is exactly one of these cases: "format" can be added as a global option, as a ffmpeg.c option or anything else, because it is very generic. Then the next guy should worry about this who wants to add a "format" option :) The argument you made is true for a lot of other generic strings, such as "video_format" or "standard", so if I really want to make sure I don't use generic option names, I guess I will end up with a prefixed option name, such as bm_format. Only a few codecs/demuxers/devices do that. So overall, I am not sure it's worth losing the consistency (using a prefixed option name, where almost all other option names are non-prefixed), but I don't really mind either way if we use bm_format instead. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec, avformat: deprecate anything related to side data merging
On Thu, 16 Mar 2017 21:01:04 +0100 Michael Niedermayer wrote: > On Thu, Mar 16, 2017 at 05:20:51AM +0100, wm4 wrote: > > This patch deprecates anything that has to do with merging/splitting > > side data. Automatic side data merging (and splitting), as well as all > > API symbols involved in it, are removed completely. > > > > Two FF_API_ defines are dedicated to deprecating API symbols related to > > this: FF_API_MERGE_SD_API removes av_packet_split/merge_side_data in > > libavcodec, and FF_API_LAVF_KEEPSIDE_FLAG deprecates > > AVFMT_FLAG_KEEP_SIDE_DATA in libavformat. > > > > Since it was claimed that changing the default from merging side data to > > not doing it is an ABI change, there are two additional FF_API_ defines, > > which stop using the side data merging/splitting by default (and remove > > any code in avformat/avcodec doing this): FF_API_MERGE_SD in libavcodec, > > and FF_API_LAVF_MERGE_SD in libavformat. > > > > It is very much intended that FF_API_MERGE_SD and FF_API_LAVF_MERGE_SD > > are quickly defined to 0 in the next ABI bump, while the API symbols are > > retained for a longer time for the sake of compatibility. > > AVFMT_FLAG_KEEP_SIDE_DATA will (very much intentionally) do nothing for > > most of the time it will still be defined. Keep in mind that no code > > exists that actually tries to unset this flag for any reason, nor does > > such code need to exist. Code setting this flag explicitly will work as > > before. Thus it's ok for AVFMT_FLAG_KEEP_SIDE_DATA to do nothing once > > side data merging has been removed from libavformat. > > > > In order to avoid that anyone in the future does this incorrectly, here > > is a small guide how to update the internal code on bumps: > > > > - next ABI bump (probably soon): > > - define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it > > - define FF_API_MERGE_SD to 0, and remove all code covered by it > > - next API bump (typically two years in the future or so): > > - define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it > > - define FF_API_MERGE_SD_API to 0, and remove all code covered by it > > > > This forces anyone who actually wants packet side data to temporarily > > use deprecated API to get it all. If you ask me, this is batshit fucked > > up crazy, but it's how we roll. Making AVFMT_FLAG_KEEP_SIDE_DATA to be > > set by default was rejected as an ABI change, so I'm going all the way > > to get rid of this once and for all. > > --- > > What is the advantage to deprecate the API ? > > Applications which depend on the current default would need the code > provided by the API when the default changes The API deprecation is intentionally decoupled from the ABI bump, so API users which really want to use those functions get enough time to fix their code (I think the "standard" is 2 years). I'll push this on Saturday or Monday then, with the changes suggested by the others. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavu/spherical: Make first parameter const
On 3/16/2017 5:23 PM, Carl Eugen Hoyos wrote: > Hi! > > Attached patch silences a gcc warning when compiling ffprobe. > > Please comment, Carl Eugen > > > 0001-lavu-spherical-Make-AVSphericalMapping-pointer-param.patch > > > From 5040ee6f7dd43c8d66a241aa0376839916cd3d9f Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos > Date: Thu, 16 Mar 2017 21:19:48 +0100 > Subject: [PATCH] lavu/spherical: Make AVSphericalMapping pointer parameter > const. > > Reflects the actual code and silences a gcc warning: > ffprobe.c:1797:42: warning: passing argument 1 of 'av_spherical_tile_bounds' > discards 'const' qualifier from pointer target type > --- > libavutil/spherical.c |2 +- > libavutil/spherical.h |2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavutil/spherical.c b/libavutil/spherical.c > index 0ca2dd3..f0b6221 100644 > --- a/libavutil/spherical.c > +++ b/libavutil/spherical.c > @@ -33,7 +33,7 @@ AVSphericalMapping *av_spherical_alloc(size_t *size) > return spherical; > } > > -void av_spherical_tile_bounds(AVSphericalMapping *map, > +void av_spherical_tile_bounds(const AVSphericalMapping *map, >size_t width, size_t height, >size_t *left, size_t *top, >size_t *right, size_t *bottom) > diff --git a/libavutil/spherical.h b/libavutil/spherical.h > index db9bdc0..f4e0d60 100644 > --- a/libavutil/spherical.h > +++ b/libavutil/spherical.h > @@ -202,7 +202,7 @@ AVSphericalMapping *av_spherical_alloc(size_t *size); > * @param right Pixels from the right edge. > * @param bottom Pixels from the bottom edge. > */ > -void av_spherical_tile_bounds(AVSphericalMapping *map, > +void av_spherical_tile_bounds(const AVSphericalMapping *map, >size_t width, size_t height, >size_t *left, size_t *top, >size_t *right, size_t *bottom); > -- 1.7.10.4 > LGTM. The AVSphericalMapping struct is not modified by the function so it should have been const since the beginning. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavu/spherical: Make first parameter const
Hi! Attached patch silences a gcc warning when compiling ffprobe. Please comment, Carl Eugen From 5040ee6f7dd43c8d66a241aa0376839916cd3d9f Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Thu, 16 Mar 2017 21:19:48 +0100 Subject: [PATCH] lavu/spherical: Make AVSphericalMapping pointer parameter const. Reflects the actual code and silences a gcc warning: ffprobe.c:1797:42: warning: passing argument 1 of 'av_spherical_tile_bounds' discards 'const' qualifier from pointer target type --- libavutil/spherical.c |2 +- libavutil/spherical.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libavutil/spherical.c b/libavutil/spherical.c index 0ca2dd3..f0b6221 100644 --- a/libavutil/spherical.c +++ b/libavutil/spherical.c @@ -33,7 +33,7 @@ AVSphericalMapping *av_spherical_alloc(size_t *size) return spherical; } -void av_spherical_tile_bounds(AVSphericalMapping *map, +void av_spherical_tile_bounds(const AVSphericalMapping *map, size_t width, size_t height, size_t *left, size_t *top, size_t *right, size_t *bottom) diff --git a/libavutil/spherical.h b/libavutil/spherical.h index db9bdc0..f4e0d60 100644 --- a/libavutil/spherical.h +++ b/libavutil/spherical.h @@ -202,7 +202,7 @@ AVSphericalMapping *av_spherical_alloc(size_t *size); * @param right Pixels from the right edge. * @param bottom Pixels from the bottom edge. */ -void av_spherical_tile_bounds(AVSphericalMapping *map, +void av_spherical_tile_bounds(const AVSphericalMapping *map, size_t width, size_t height, size_t *left, size_t *top, size_t *right, size_t *bottom); -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec, avformat: deprecate anything related to side data merging
Le sextidi 26 ventôse, an CCXXV, Michael Niedermayer a écrit : > Applications which depend on the current default would need ... to implement a correct structure to carry the data from their demuxer to the lavc decoders. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/internal: Constify AVPacket* in AVCodecInternal.
2017-03-01 13:04 GMT+01:00 Michael Niedermayer : > On Sun, Feb 26, 2017 at 12:38:14PM +0100, Carl Eugen Hoyos wrote: >> Hi! >> >> Attached patch fixes another warning when compiling libavcodec/utils.o. >> >> Please comment, Carl Eugen > > if it doesnt produce any new warnings elsewere then its probably ok 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] spherical: Change types of bounding and pad to uint32_t
On Wed, 15 Mar 2017 10:22:23 +0100 Carl Eugen Hoyos wrote: > Sorry if I miss something but could you clarify who the author of this > patch is? CC'ing as Vittorio is not subscribed to the mailing list. Not that you should have to know that as there was no CC request in this particular message. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/avpacket: Make pkt parameter of av_packet_get_side_data() const
2017-02-26 12:04 GMT+01:00 Carl Eugen Hoyos : > Anyway, new patch attached. Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] configure: clang -Oz for small size build to reduce size further
2017-03-10 6:26 GMT+01:00 Wang Bin : [...] 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 1/2] avcodec, avformat: deprecate anything related to side data merging
On Thu, Mar 16, 2017 at 05:20:51AM +0100, wm4 wrote: > This patch deprecates anything that has to do with merging/splitting > side data. Automatic side data merging (and splitting), as well as all > API symbols involved in it, are removed completely. > > Two FF_API_ defines are dedicated to deprecating API symbols related to > this: FF_API_MERGE_SD_API removes av_packet_split/merge_side_data in > libavcodec, and FF_API_LAVF_KEEPSIDE_FLAG deprecates > AVFMT_FLAG_KEEP_SIDE_DATA in libavformat. > > Since it was claimed that changing the default from merging side data to > not doing it is an ABI change, there are two additional FF_API_ defines, > which stop using the side data merging/splitting by default (and remove > any code in avformat/avcodec doing this): FF_API_MERGE_SD in libavcodec, > and FF_API_LAVF_MERGE_SD in libavformat. > > It is very much intended that FF_API_MERGE_SD and FF_API_LAVF_MERGE_SD > are quickly defined to 0 in the next ABI bump, while the API symbols are > retained for a longer time for the sake of compatibility. > AVFMT_FLAG_KEEP_SIDE_DATA will (very much intentionally) do nothing for > most of the time it will still be defined. Keep in mind that no code > exists that actually tries to unset this flag for any reason, nor does > such code need to exist. Code setting this flag explicitly will work as > before. Thus it's ok for AVFMT_FLAG_KEEP_SIDE_DATA to do nothing once > side data merging has been removed from libavformat. > > In order to avoid that anyone in the future does this incorrectly, here > is a small guide how to update the internal code on bumps: > > - next ABI bump (probably soon): > - define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it > - define FF_API_MERGE_SD to 0, and remove all code covered by it > - next API bump (typically two years in the future or so): > - define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it > - define FF_API_MERGE_SD_API to 0, and remove all code covered by it > > This forces anyone who actually wants packet side data to temporarily > use deprecated API to get it all. If you ask me, this is batshit fucked > up crazy, but it's how we roll. Making AVFMT_FLAG_KEEP_SIDE_DATA to be > set by default was rejected as an ABI change, so I'm going all the way > to get rid of this once and for all. > --- What is the advantage to deprecate the API ? Applications which depend on the current default would need the code provided by the API when the default changes [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] decklink: add fourCC of display mode to list_format output
On Thu, 16 Mar 2017, Matthias Hunstock wrote:
---
libavdevice/decklink_common.cpp | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index 8b499c5..131d186 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -276,6 +276,7 @@ int ff_decklink_list_formats(AVFormatContext *avctx,
decklink_direction_t direct
struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
IDeckLinkDisplayModeIterator *itermode;
IDeckLinkDisplayMode *mode;
+char fourcc[32];
int i=0;
HRESULT res;
@@ -297,13 +298,15 @@ int ff_decklink_list_formats(AVFormatContext *avctx,
decklink_direction_t direct
return AVERROR(EIO);
}
-av_log(avctx, AV_LOG_INFO, "Supported formats for '%s':\n",
+av_log(avctx, AV_LOG_INFO, "Supported formats for
'%s':\n\tmode\tfourCC\tdescription",
avctx->filename);
while (itermode->Next(&mode) == S_OK) {
BMDTimeValue tb_num, tb_den;
mode->GetFrameRate(&tb_num, &tb_den);
-av_log(avctx, AV_LOG_INFO, "\t%d\t%ldx%ld at %d/%d fps",
-++i,mode->GetWidth(), mode->GetHeight(),
+av_get_codec_tag_string(fourcc, sizeof(fourcc),
mode->GetDisplayMode());
+av_log(avctx, AV_LOG_INFO, "\n\t%d\t%c%c%c%c\t%ldx%ld at %d/%d fps",
+++i, fourcc[3], fourcc[2], fourcc[1], fourcc[0],
+mode->GetWidth(), mode->GetHeight(),
fourcc is a string, is there a reason why you don't simply print it
using "%s"?
(int) tb_den, (int) tb_num);
switch (mode->GetFieldDominance()) {
case bmdLowerFieldFirst:
@@ -311,9 +314,9 @@ int ff_decklink_list_formats(AVFormatContext *avctx,
decklink_direction_t direct
case bmdUpperFieldFirst:
av_log(avctx, AV_LOG_INFO, " (interlaced, upper field first)"); break;
}
-av_log(avctx, AV_LOG_INFO, "\n");
mode->Release();
}
+av_log(avctx, AV_LOG_INFO, "\n");
itermode->Release();
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] spherical: Change types of bounding and pad to uint32_t
2017-03-16 20:18 GMT+01:00 Vittorio Giovara : >> LGTM otherwise. >> > > Ok thank you > > The "other side" will apply this as well at the same time this is committed. Don't forget to fix the patch author! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mpegtsenc: clarify pcr_period unit of measurement
On Wed, 15 Mar 2017 18:47:31 -0800 Lou Logan wrote: > pcr_period is in milliseconds. > > Signed-off-by: Lou Logan > --- > libavformat/mpegtsenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] spherical: Change types of bounding and pad to uint32_t
On Wed, Mar 15, 2017 at 11:31 PM, James Almer wrote:
> On 3/15/2017 6:39 PM, Vittorio Giovara wrote:
>> These values are defined to be 32bit in the specification,
>> so it makes more sense to store them as fixed width.
>>
>> Signed-off-by: Vittorio Giovara
>> ---
>> Updated commit message, changed a couple of internal types.
>> Please CC or I can't see replies.
>> Vittorio
>
> Mention it's based on a patch by Michael Niedermayer.
>
>>
>> libavformat/dump.c| 2 +-
>> libavformat/matroskadec.c | 6 +++---
>> libavformat/mov.c | 7 +++
>> libavutil/spherical.h | 10 +-
>> 4 files changed, 12 insertions(+), 13 deletions(-)
>>
>> diff --git a/libavformat/dump.c b/libavformat/dump.c
>> index 7514aee7ac..c56895628d 100644
>> --- a/libavformat/dump.c
>> +++ b/libavformat/dump.c
>> @@ -339,7 +339,7 @@ static void dump_spherical(void *ctx, AVCodecParameters
>> *par, AVPacketSideData *
>> &l, &t, &r, &b);
>> av_log(ctx, AV_LOG_INFO, "[%zu, %zu, %zu, %zu] ", l, t, r, b);
>> } else if (spherical->projection == AV_SPHERICAL_CUBEMAP) {
>> -av_log(ctx, AV_LOG_INFO, "[pad %zu] ", spherical->padding);
>> +av_log(ctx, AV_LOG_INFO, "[pad %"PRIu32"] ", spherical->padding);
>> }
>> }
>>
>> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
>> index 4fbf4b9a96..c6e1a190a8 100644
>> --- a/libavformat/matroskadec.c
>> +++ b/libavformat/matroskadec.c
>> @@ -1601,8 +1601,8 @@ static int mkv_parse_video_projection(AVStream *st,
>> const MatroskaTrack *track)
>> AVSphericalMapping *spherical;
>> enum AVSphericalProjection projection;
>> size_t spherical_size;
>> -size_t l = 0, t = 0, r = 0, b = 0;
>> -size_t padding = 0;
>> +uint32_t l = 0, t = 0, r = 0, b = 0;
>> +uint32_t padding = 0;
>> int ret;
>> GetByteContext gb;
>>
>> @@ -1627,7 +1627,7 @@ static int mkv_parse_video_projection(AVStream *st,
>> const MatroskaTrack *track)
>> if (b >= UINT_MAX - t || r >= UINT_MAX - l) {
>> av_log(NULL, AV_LOG_ERROR,
>> "Invalid bounding rectangle coordinates "
>> - "%zu,%zu,%zu,%zu\n", l, t, r, b);
>> + "%"PRIu32",%"PRIu32",%"PRIu32",%"PRIu32"\n", l, t,
>> r, b);
>
> This chunk doesn't apply.
>
>> return AVERROR_INVALIDDATA;
>> }
>> } else if (track->video.projection.private.size != 0) {
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index c6e7a38398..1c1857eaf9 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -3237,9 +3237,8 @@ static int mov_read_sv3d(MOVContext *c, AVIOContext
>> *pb, MOVAtom atom)
>> MOVStreamContext *sc;
>> int size, version, layout;
>> int32_t yaw, pitch, roll;
>> -size_t l = 0, t = 0, r = 0, b = 0;
>> -size_t padding = 0;
>> -uint32_t tag;
>> +uint32_t l = 0, t = 0, r = 0, b = 0;
>> +uint32_t tag, padding = 0;
>> enum AVSphericalProjection projection;
>>
>> if (c->fc->nb_streams < 1)
>> @@ -3335,7 +3334,7 @@ static int mov_read_sv3d(MOVContext *c, AVIOContext
>> *pb, MOVAtom atom)
>> if (b >= UINT_MAX - t || r >= UINT_MAX - l) {
>> av_log(c->fc, AV_LOG_ERROR,
>> "Invalid bounding rectangle coordinates "
>> - "%zu,%zu,%zu,%zu\n", l, t, r, b);
>> + "%"PRIu32",%"PRIu32",%"PRIu32",%"PRIu32"\n", l, t, r, b);
>
> Same.
>
>> return AVERROR_INVALIDDATA;
>> }
>>
>> diff --git a/libavutil/spherical.h b/libavutil/spherical.h
>> index e7fc1d69fb..fd662cf676 100644
>> --- a/libavutil/spherical.h
>> +++ b/libavutil/spherical.h
>> @@ -164,10 +164,10 @@ typedef struct AVSphericalMapping {
>> * projection type (@ref AV_SPHERICAL_EQUIRECTANGULAR_TILE),
>> * and should be ignored in all other cases.
>> */
>> -size_t bound_left; ///< Distance from the left edge
>> -size_t bound_top;///< Distance from the top edge
>> -size_t bound_right; ///< Distance from the right edge
>> -size_t bound_bottom; ///< Distance from the bottom edge
>> +uint32_t bound_left; ///< Distance from the left edge
>> +uint32_t bound_top;///< Distance from the top edge
>> +uint32_t bound_right; ///< Distance from the right edge
>> +uint32_t bound_bottom; ///< Distance from the bottom edge
>> /**
>> * @}
>> */
>> @@ -179,7 +179,7 @@ typedef struct AVSphericalMapping {
>> * (@ref AV_SPHERICAL_CUBEMAP), and should be ignored in all other
>> * cases.
>> */
>> -size_t padding;
>> +uint32_t padding;
>> } AVSphericalMapping;
>>
>> /**
>
> LGTM otherwise.
>
Ok thank you
The "other side" will apply this as well at the same time this is committed.
Can you (or someone else) also approve the ffprobe change too please?
I'd like to push these two together.
--
Vittorio
_
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/h264_direct: Fix runtime error: signed integer overflow: -9 - 2147483647 cannot be represented in type 'int'
On Thu, 16 Mar 2017 at 15:37 Michael Niedermayer wrote: > On Thu, Mar 16, 2017 at 11:41:12AM +, Kieran Kunhya wrote: > > > > > > + > > > +if (pocdiff0 != (int)pocdiff0) > > > +avpriv_request_sample(sl->h264->avctx, "pocdiff0 > overflow\n"); > > > + > > > > > > > Do you think this condition will actually happen in the real world apart > > from in glitchy live streams? > > I dont really know, do you prefer a AV_LOG_DEBUG ? > IMO yes Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] lavfi: deprecate AVFilterGraph->resample_lavr_opts
On Mon, 6 Mar 2017 02:46:50 +
Rostislav Pehlivanov wrote:
> Not used by anything at all since we don't auto insert lavr filters.
>
> Signed-off-by: Rostislav Pehlivanov
> ---
> doc/APIchanges | 4
> libavfilter/avfilter.h | 4 +++-
> libavfilter/avfiltergraph.c | 2 ++
> libavfilter/version.h | 5 -
> libavformat/version.h | 1 -
> 5 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 6922ea5268..2275f0da4b 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,10 @@ libavutil: 2015-08-28
>
> API changes, most recent first:
>
> +2017-03-02 - xxx - lavfi 6.75.100 - avfilter.h
> + Deprecate AVFilterGraph.resample_lavr_opts
> + Its never been used by avfilter and never given to anything
It's.
> +
> 2017-03-02 - xxx - lavc 57.81.104 - videotoolbox.h
>AVVideotoolboxContext.cv_pix_fmt_type can now be set to 0 to output the
>native decoder format. (The default value is not changed.)
> diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
> index b56615c98e..ac6dca4fc0 100644
> --- a/libavfilter/avfilter.h
> +++ b/libavfilter/avfilter.h
> @@ -841,7 +841,9 @@ typedef struct AVFilterGraph {
> unsigned nb_filters;
>
> char *scale_sws_opts; ///< sws options to use for the auto-inserted
> scale filters
> -char *resample_lavr_opts; ///< libavresample options to use for the
> auto-inserted resample filters
> +#if FF_API_LAVR_OPTS
> +attribute_deprecated char *resample_lavr_opts; ///< libavresample
> options to use for the auto-inserted resample filters
> +#endif
>
> /**
> * Type of multithreading allowed for filters in this graph. A
> combination
> diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c
> index 534c6701a8..75bd516896 100644
> --- a/libavfilter/avfiltergraph.c
> +++ b/libavfilter/avfiltergraph.c
> @@ -128,7 +128,9 @@ void avfilter_graph_free(AVFilterGraph **graph)
>
> av_freep(&(*graph)->scale_sws_opts);
> av_freep(&(*graph)->aresample_swr_opts);
> +#if FF_API_LAVR_OPTS
> av_freep(&(*graph)->resample_lavr_opts);
> +#endif
> av_freep(&(*graph)->filters);
> av_freep(&(*graph)->internal);
> av_freep(graph);
> diff --git a/libavfilter/version.h b/libavfilter/version.h
> index 11db8d5513..3cd6e24b27 100644
> --- a/libavfilter/version.h
> +++ b/libavfilter/version.h
> @@ -30,7 +30,7 @@
> #include "libavutil/version.h"
>
> #define LIBAVFILTER_VERSION_MAJOR 6
> -#define LIBAVFILTER_VERSION_MINOR 74
> +#define LIBAVFILTER_VERSION_MINOR 75
> #define LIBAVFILTER_VERSION_MICRO 100
>
> #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
> @@ -67,5 +67,8 @@
> #ifndef FF_API_NOCONST_GET_NAME
> #define FF_API_NOCONST_GET_NAME (LIBAVFILTER_VERSION_MAJOR < 7)
> #endif
> +#ifndef FF_API_LAVR_OPTS
> +#define FF_API_LAVR_OPTS(LIBAVFILTER_VERSION_MAJOR < 7)
> +#endif
>
> #endif /* AVFILTER_VERSION_H */
> diff --git a/libavformat/version.h b/libavformat/version.h
> index cd505242ef..4a12d7d947 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@ -89,7 +89,6 @@
> #define FF_API_HLS_WRAP (LIBAVFORMAT_VERSION_MAJOR < 58)
> #endif
>
> -
Stray whitespace change?
> #ifndef FF_API_R_FRAME_RATE
> #define FF_API_R_FRAME_RATE1
> #endif
Otherwise seems ok.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] decklink: new option 'format' to set video format by fourCC
Le sextidi 26 ventôse, an CCXXV, Matthias Hunstock a écrit : > I did not find a comparable option for another device in libavdevice, > "format" was the initial suggestion of Marton. This is at least > consistent with the existing "list_formats" option. I do not know what the option does, and therefore can not propose a better name. All I know is that we decided not to build an inconvenient infrastructure to avoid the collision between global, format, codecs options, at the cost of having to be careful when adding said options. This is exactly one of these cases: "format" can be added as a global option, as a ffmpeg.c option or anything else, because it is very generic. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libswscale/swscale_unscaled: fix DITHER_COPY macro
On Wed, Mar 15, 2017 at 10:52:29PM +0100, Mateusz Brzostek wrote: > Hello! > > There are 3 problems with DITHER_COPY macro in libswscale/swscale_unscaled.c: > 1) there is overflow in dithering from 12-bit to 10-bit (output value > 1023); > 2) for limit range the lower limit is not respected, for example from 10-bit > to 8-bit value 64 is converted to 15; > 3) for many iteration of downscale/upscale of the same image the 200th > iteration is significantly darker. > > The first bug is due to wrong dithers table (now it is OK only for 8-bit > destination), fix is: > -const uint8_t *dither= dithers[src_depth-9][i&7];\ > +const uint8_t *dither= dithers[src_depth-dst_depth-1][i&7];\ > > For bugs 2) and 3) it is needed formula that do not make images darker (in > attachment). So please review. does your code maintain white and black levels ? with 4 bits white is 15, with 7 bits white is 127 for example white should stay white black should stay black in both directions [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample/swresample: do not use s32p internally by default when resampling
On Thu, 16 Mar 2017 17:00:17 +0700
Muhammad Faiz wrote:
> On Thu, Mar 16, 2017 at 1:01 PM, wm4 wrote:
> > On Thu, 16 Mar 2017 12:43:10 +0700
> > Muhammad Faiz wrote:
> >
> >> use fltp when doing s32 -> s32 resampling
> >> because s32p has no simd optimization
> >>
> >> benchmark:
> >> old 17.913s
> >> new 7.584s (use fma3)
> >>
> >> Signed-off-by: Muhammad Faiz
> >> ---
> >> libswresample/swresample.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/libswresample/swresample.c b/libswresample/swresample.c
> >> index f2e6600..74c96dc 100644
> >> --- a/libswresample/swresample.c
> >> +++ b/libswresample/swresample.c
> >> @@ -223,6 +223,8 @@ av_cold int swr_init(struct SwrContext *s){
> >> }else if( av_get_planar_sample_fmt(s-> in_sample_fmt) ==
> >> AV_SAMPLE_FMT_S32P
> >> && av_get_planar_sample_fmt(s->out_sample_fmt) ==
> >> AV_SAMPLE_FMT_S32P
> >> && !s->rematrix
> >> + && s->out_sample_rate == s->in_sample_rate
> >> + && !(s->flags & SWR_FLAG_RESAMPLE)
> >> && s->engine != SWR_ENGINE_SOXR){
> >> s->int_sample_fmt= AV_SAMPLE_FMT_S32P;
> >> }else if(av_get_bytes_per_sample(s->in_sample_fmt) <= 4){
> >
> > Wouldn't going over float lose bits?
>
> Yes, of course. But when resampling with default opt, aliasing happens at
> about -90dB which is only 15 bits. Keeping 32 bits has no point at all.
>
> > I guess most times, s32 is
> > actually 24 bit padded (since we have no 24 bit format). But it could
> > be true 32 bit as well (with all bits used). Or does it use double, or
> > am I missing something else?
>
> Using double is overkill, i think.
From my naive point of view this seems ok, then.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mpegtsenc: clarify pcr_period unit of measurement
On Thu, Mar 16, 2017 at 08:56:54AM -0800, Lou Logan wrote: > On Thu, 16 Mar 2017 16:39:18 +0100 > Michael Niedermayer wrote: > > > i suggested it in the past already, but all time and duration values > > should be changed to use seconds. It would be much cleaner, consistent > > and less confusing. > > Agreed, but this minor commit can be somewhat informative until if/when > the time values are made consistent. sure, didnt mean to stop you > > If someone wants to work on that let me know and I can help deal with > updating the docs. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] swresample/options: enable linear_interp and exact_rational by default
On Thu, Mar 16, 2017 at 12:05 AM, Muhammad Faiz wrote: > On Mon, Mar 13, 2017 at 8:40 PM, Muhammad Faiz wrote: >> better quality without speedloss >> >> Signed-off-by: Muhammad Faiz >> --- >> doc/resampler.texi | 5 +- >> libswresample/options.c | 4 +- >> tests/fate/libswresample.mak | 189 >> --- >> tests/ref/acodec/s302m | 6 +- >> tests/ref/lavf/dv_fmt| 8 +- >> tests/ref/lavf/gxf | 8 +- >> tests/ref/lavf/mxf | 12 +-- >> 7 files changed, 201 insertions(+), 31 deletions(-) > > I'm going to push this tomorrow if no one object > > Thx. Pushed. Thank's ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mpegtsenc: clarify pcr_period unit of measurement
On Thu, 16 Mar 2017 16:39:18 +0100 Michael Niedermayer wrote: > i suggested it in the past already, but all time and duration values > should be changed to use seconds. It would be much cleaner, consistent > and less confusing. Agreed, but this minor commit can be somewhat informative until if/when the time values are made consistent. If someone wants to work on that let me know and I can help deal with updating the docs. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vp56: Require 1 undamaged frame for 5 damaged frames for concealment to be used
On Wed, Mar 15, 2017 at 16:29:22 -0300, James Almer wrote: > Afaik, old flv videos used VP6 (libavcodec reports them as vp6f). There > are some real world files out there, like video game trailers. > I have a Diablo 3 and a Starcraft 2 trailers encoded in VP6 here if you'd > like to check them. VP6 is the (or a) reference video codec for Flash 8, apparently. VP6 encoded Flash 8 video samples can be found with web search, such as: http://www.mediacollege.com/adobe/flash/video/tutorial/example-flv.html I also have some proper (non-sample) videos in VP6 from somewhere on the web (I just found 25 such FLVs), it may have been somewhat widespread at a certain time. Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec, avformat: deprecate anything related to side data merging
On Thu, 16 Mar 2017 11:07:44 -0300 James Almer wrote: > On 3/16/2017 1:20 AM, wm4 wrote: > > This patch deprecates anything that has to do with merging/splitting > > side data. Automatic side data merging (and splitting), as well as all > > API symbols involved in it, are removed completely. > > > > Two FF_API_ defines are dedicated to deprecating API symbols related to > > this: FF_API_MERGE_SD_API removes av_packet_split/merge_side_data in > > libavcodec, and FF_API_LAVF_KEEPSIDE_FLAG deprecates > > AVFMT_FLAG_KEEP_SIDE_DATA in libavformat. > > > > Since it was claimed that changing the default from merging side data to > > not doing it is an ABI change, there are two additional FF_API_ defines, > > which stop using the side data merging/splitting by default (and remove > > any code in avformat/avcodec doing this): FF_API_MERGE_SD in libavcodec, > > and FF_API_LAVF_MERGE_SD in libavformat. > > > > It is very much intended that FF_API_MERGE_SD and FF_API_LAVF_MERGE_SD > > are quickly defined to 0 in the next ABI bump, while the API symbols are > > retained for a longer time for the sake of compatibility. > > AVFMT_FLAG_KEEP_SIDE_DATA will (very much intentionally) do nothing for > > most of the time it will still be defined. Keep in mind that no code > > exists that actually tries to unset this flag for any reason, nor does > > such code need to exist. Code setting this flag explicitly will work as > > before. Thus it's ok for AVFMT_FLAG_KEEP_SIDE_DATA to do nothing once > > side data merging has been removed from libavformat. > > > > In order to avoid that anyone in the future does this incorrectly, here > > is a small guide how to update the internal code on bumps: > > > > - next ABI bump (probably soon): > > - define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it > > - define FF_API_MERGE_SD to 0, and remove all code covered by it > > - next API bump (typically two years in the future or so): > > - define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it > > - define FF_API_MERGE_SD_API to 0, and remove all code covered by it > > I assume you meant to write FF_API_LAVF_KEEPSIDE_FLAG in the API bump part. Yes. > > You should do > > #if FF_API_MERGE_SD > FF_DISABLE_DEPRECATION_WARNINGS > int did_split = av_packet_split_side_data(&tmp); > FF_ENABLE_DEPRECATION_WARNINGS > #endif > > To remove the "deprecated" warning spam during compilation. Same with every > other call to any of the deprecated functions. > > What about the ffmpeg.c calls to av_packet_split_side_data()? You should > also wrap them with one of these new FF_API defines. The deprecated API uses go soon (next ABI bump), so I'm not sure it's worth the trouble. > > +#ifndef FF_API_LAVF_MERGE_SD > > +#define FF_API_LAVF_MERGE_SD(LIBAVFORMAT_VERSION_MAJOR < 58) > > +#endif > > +#ifndef FF_API_LAVF_KEEPSIDE_FLAG > > +#define FF_API_LAVF_KEEPSIDE_FLAG (LIBAVFORMAT_VERSION_MAJOR < 58) > > This one should probably be set as "< 59", much like FF_API_MERGE_SD_API. Well, what we normally do is delaying the bump for certain FF_API symbols when bumping, so this is not all clear. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec, avformat: deprecate anything related to side data merging
On Thu, 16 Mar 2017 13:38:03 + Rostislav Pehlivanov wrote: > On 16 March 2017 at 04:20, wm4 wrote: > > > This patch deprecates anything that has to do with merging/splitting > > side data. Automatic side data merging (and splitting), as well as all > > API symbols involved in it, are removed completely. > > > > Two FF_API_ defines are dedicated to deprecating API symbols related to > > this: FF_API_MERGE_SD_API removes av_packet_split/merge_side_data in > > libavcodec, and FF_API_LAVF_KEEPSIDE_FLAG deprecates > > AVFMT_FLAG_KEEP_SIDE_DATA in libavformat. > > > > Since it was claimed that changing the default from merging side data to > > not doing it is an ABI change, there are two additional FF_API_ defines, > > which stop using the side data merging/splitting by default (and remove > > any code in avformat/avcodec doing this): FF_API_MERGE_SD in libavcodec, > > and FF_API_LAVF_MERGE_SD in libavformat. > > > > It is very much intended that FF_API_MERGE_SD and FF_API_LAVF_MERGE_SD > > are quickly defined to 0 in the next ABI bump, while the API symbols are > > retained for a longer time for the sake of compatibility. > > AVFMT_FLAG_KEEP_SIDE_DATA will (very much intentionally) do nothing for > > most of the time it will still be defined. Keep in mind that no code > > exists that actually tries to unset this flag for any reason, nor does > > such code need to exist. Code setting this flag explicitly will work as > > before. Thus it's ok for AVFMT_FLAG_KEEP_SIDE_DATA to do nothing once > > side data merging has been removed from libavformat. > > > > In order to avoid that anyone in the future does this incorrectly, here > > is a small guide how to update the internal code on bumps: > > > > - next ABI bump (probably soon): > > - define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it > > - define FF_API_MERGE_SD to 0, and remove all code covered by it > > - next API bump (typically two years in the future or so): > > - define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it > > - define FF_API_MERGE_SD_API to 0, and remove all code covered by it > > > > > Isn't a major bump and API bump? So why wait until major 59 when all things > getting deprecated get removed at major 58? There's no reason to keep it > around for longer when it isn't even used. Apparently we're supposed to keep deprecated APIs around for 2 years. So to get this crap dead sooner, I've made separate deprecations for the actual mechanisms, which according to some (michaelni) is an ABI change. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/h264_direct: Fix runtime error: signed integer overflow: -9 - 2147483647 cannot be represented in type 'int'
On Thu, Mar 16, 2017 at 11:41:12AM +, Kieran Kunhya wrote: > > > > + > > +if (pocdiff0 != (int)pocdiff0) > > +avpriv_request_sample(sl->h264->avctx, "pocdiff0 overflow\n"); > > + > > > > Do you think this condition will actually happen in the real world apart > from in glitchy live streams? I dont really know, do you prefer a AV_LOG_DEBUG ? [...] -- 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] lavf/mpegtsenc: clarify pcr_period unit of measurement
On Wed, Mar 15, 2017 at 06:47:31PM -0800, Lou Logan wrote:
> pcr_period is in milliseconds.
>
> Signed-off-by: Lou Logan
> ---
> libavformat/mpegtsenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
> index 0f394c5fe0..3250dde311 100644
> --- a/libavformat/mpegtsenc.c
> +++ b/libavformat/mpegtsenc.c
> @@ -1945,7 +1945,7 @@ static const AVOption options[] = {
> { "omit_video_pes_length", "Omit the PES packet length for video
> packets",
>offsetof(MpegTSWrite, omit_video_pes_length), AV_OPT_TYPE_BOOL,
>{ .i64 = 1 }, 0, 1, AV_OPT_FLAG_ENCODING_PARAM },
> -{ "pcr_period", "PCR retransmission time",
> +{ "pcr_period", "PCR retransmission time in milliseconds",
>offsetof(MpegTSWrite, pcr_period), AV_OPT_TYPE_INT,
i suggested it in the past already, but all time and duration values
should be changed to use seconds. It would be much cleaner, consistent
and less confusing.
using actual common day suffixes to indicate milli and micro instead
of having each option use a different unit
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 1/2] avcodec/mpeg12dec: parse A53 caption data embedded in SCTE-20 user data
On Wed, Mar 15, 2017 at 03:32:22PM -0700, Aman Gupta wrote:
> On Wed, Mar 15, 2017 at 2:06 PM, Michael Niedermayer > wrote:
>
> > On Wed, Mar 15, 2017 at 12:53:03PM -0700, Aman Gupta wrote:
> > > From: Aman Gupta
> > >
> > > includes a fate test, which requires
> > > https://s3.amazonaws.com/tmm1/ccaptions/scte20.ts
> > > to be uploaded as sub/scte20.ts
> >
> > uploaded
> >
> >
> >
> > > ---
> > > libavcodec/mpeg12dec.c | 39 ++
> > +
> > > tests/fate/subtitles.mak | 3 +++
> > > tests/ref/fate/sub-cc-scte20 | 15 +++
> > > 3 files changed, 57 insertions(+)
> > > create mode 100644 tests/ref/fate/sub-cc-scte20
> > >
> > > diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
> > > index e49167f..cea8963 100644
> > > --- a/libavcodec/mpeg12dec.c
> > > +++ b/libavcodec/mpeg12dec.c
> > > @@ -2260,6 +2260,45 @@ static int mpeg_decode_a53_cc(AVCodecContext
> > *avctx,
> > > avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
> > > }
> > > return 1;
> > > +} else if (buf_size >= 2 &&
> > > + p[0] == 0x03 && (p[1]&0x7f) == 0x01) {
> > > +/* extract SCTE-20 CC data */
> > > +GetBitContext gb;
> > > +int cc_count = 0;
> > > +int i;
> > > +
> > > +init_get_bits(&gb, p + 2, buf_size - 2);
> > > +cc_count = get_bits(&gb, 5);
> > > +if (cc_count > 0) {
> >
> > remainig bits or buf_size should be checked to be large enough for
> > cc_count
> >
>
> Good catch. Changing to buf_size>=3 in the outer conditional should be
> sufficient, right?
i think its not
the bitstream is initialized with buf_size - 2 so a buf_size of 3
doesnt seem enough for al that can be read
also see get_bits_left()
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/vf_framerate: Fix frame leak when increasing framerate.
On Sat, Mar 11, 2017 at 08:18:54PM +0100, Alexis Ballier wrote: > --- > Can be reproduced with: ffmpeg -f lavfi -i cellauto,framerate=fps=100 -t 1 -f > null - > (and your favorite memory debugger). > --- > libavfilter/vf_framerate.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) patchset applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus 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] decklink: new option 'format' to set video format by fourCC
Am 16.03.2017 um 15:40 schrieb Nicolas George: > I would advise to use a name much more specific than "format". I did not find a comparable option for another device in libavdevice, "format" was the initial suggestion of Marton. This is at least consistent with the existing "list_formats" option. Other suggestions: video_format video_mode video_standard signal_standard ...? Matthias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Refund request for travelling costs to Chemnitz
On date Tuesday 2017-03-14 22:15:11 +0100, Thilo Borgmann encoded: > Hi, > > > Alexander Strasser, Thilo Borgmann, Thomas Volkert and myself > > represented FFmpeg at the Chemnitzer Linuxtage 2017. We showed > > different filters in action on video screens, talked to guests and > > other projects and as usual answered many user questions. > > we also took some pictures to update our social media stuff, Thomas? ;) > > > > I request the refund of € 162,69 for flying to Germany and back. > > Refund requests for hotel and fuel from others will follow. > > I kindly request refunding of EUR 80.76 for some fuel to go from > Berlin to Chemnitz and back again (something like 270km one > way). This year I had to pickup Carl Eugen on track from Leipzig > because of ground crew on strike in Berlin-Tegel airport. However, > we have to pass by Leipzig on our way to Chemnitz anyway so at least > no extra fuel had to be wasted. > > I'll send the invoices to Stefano privately. LGTM. -- FFmpeg = Forgiving and Forgiving Mystic Pure Evil Generator ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/h264idct_template: fix multiple runtime error: signed integer overflow
On Wed, Mar 15, 2017 at 04:12:50AM +0100, Michael Niedermayer wrote: > Fixes: 857/clusterfuzz-testcase-5319093760557056 > > Benchmark changes from 335->333 (so if its not a random fluctuation then it > would be faster) > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/h264idct_template.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. 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] avcodec/h264_cabac: Fix runtime error: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
On Wed, Mar 15, 2017 at 04:12:51AM +0100, Michael Niedermayer wrote: > Fixes: 858/clusterfuzz-testcase-5168477042114560 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/h264_cabac.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato 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] decklink: new option 'format' to set video format by fourCC
Le sextidi 26 ventôse, an CCXXV, Matthias Hunstock a écrit : > --- > libavdevice/decklink_common.cpp | 22 ++ > libavdevice/decklink_common_c.h | 1 + > libavdevice/decklink_dec.cpp| 2 +- > libavdevice/decklink_dec_c.c| 1 + > 4 files changed, 21 insertions(+), 5 deletions(-) I would advise to use a name much more specific than "format". Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Refund request for Customs fees of donations
On date Thursday 2017-02-23 20:35:21 +0100, Thilo Borgmann encoded: > Hi, > > in the aftermath of ELCE 2016 we recieved a donation of 5 displays from a > company. These went to Michael Niedermayer, Carl Eugen Hoyos, Ronald Bultje, > Clement Boesch and myself. > > Unfortunately, due to lack of experience with that, I had to pay customs for > 4 of 5 of these displays which had to be sent to me for being the only valid > address in Europe the manufacturer could deliver to. I also mailed the > displays further on to Austria and France and payed the corresponding fees > for that, too. Thus I hereby ask for refunding these expenses. > > The numbers are: > > Customs 96,37€ > +92,29€ > +92,29€ > +91,69€ > > Mail+22,99€ > +33,99€ > > Sum 429,62€ > > I'll send a copy of all invoices to Stefano privately. Hi, sorry for the slow reply. LGTM, will forward the expense refund in case Michael approves. Best regards. -- FFmpeg = Fierce Frightening Mortal Pure Energized Gospel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec, avformat: deprecate anything related to side data merging
On 3/16/2017 1:20 AM, wm4 wrote:
> This patch deprecates anything that has to do with merging/splitting
> side data. Automatic side data merging (and splitting), as well as all
> API symbols involved in it, are removed completely.
>
> Two FF_API_ defines are dedicated to deprecating API symbols related to
> this: FF_API_MERGE_SD_API removes av_packet_split/merge_side_data in
> libavcodec, and FF_API_LAVF_KEEPSIDE_FLAG deprecates
> AVFMT_FLAG_KEEP_SIDE_DATA in libavformat.
>
> Since it was claimed that changing the default from merging side data to
> not doing it is an ABI change, there are two additional FF_API_ defines,
> which stop using the side data merging/splitting by default (and remove
> any code in avformat/avcodec doing this): FF_API_MERGE_SD in libavcodec,
> and FF_API_LAVF_MERGE_SD in libavformat.
>
> It is very much intended that FF_API_MERGE_SD and FF_API_LAVF_MERGE_SD
> are quickly defined to 0 in the next ABI bump, while the API symbols are
> retained for a longer time for the sake of compatibility.
> AVFMT_FLAG_KEEP_SIDE_DATA will (very much intentionally) do nothing for
> most of the time it will still be defined. Keep in mind that no code
> exists that actually tries to unset this flag for any reason, nor does
> such code need to exist. Code setting this flag explicitly will work as
> before. Thus it's ok for AVFMT_FLAG_KEEP_SIDE_DATA to do nothing once
> side data merging has been removed from libavformat.
>
> In order to avoid that anyone in the future does this incorrectly, here
> is a small guide how to update the internal code on bumps:
>
> - next ABI bump (probably soon):
> - define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it
> - define FF_API_MERGE_SD to 0, and remove all code covered by it
> - next API bump (typically two years in the future or so):
> - define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it
> - define FF_API_MERGE_SD_API to 0, and remove all code covered by it
I assume you meant to write FF_API_LAVF_KEEPSIDE_FLAG in the API bump part.
>
> This forces anyone who actually wants packet side data to temporarily
> use deprecated API to get it all. If you ask me, this is batshit fucked
> up crazy, but it's how we roll. Making AVFMT_FLAG_KEEP_SIDE_DATA to be
> set by default was rejected as an ABI change, so I'm going all the way
> to get rid of this once and for all.
> ---
> doc/APIchanges | 5 +
> libavcodec/avcodec.h| 4
> libavcodec/avpacket.c | 4
> libavcodec/utils.c | 16
> libavcodec/version.h| 9 -
> libavformat/avformat.h | 4 +++-
> libavformat/mux.c | 6 ++
> libavformat/options_table.h | 2 ++
> libavformat/utils.c | 2 ++
> libavformat/version.h | 8 +++-
> 10 files changed, 57 insertions(+), 3 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index dc36a6bea7..acb67d38e4 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,11 @@ libavutil: 2015-08-28
>
> API changes, most recent first:
>
> +2017-03-16 - xxx - lavf 57.66.105, lavc 57.83.101 - avformat.h, avcodec.h
> + Deprecate AVFMT_FLAG_KEEP_SIDE_DATA. It will be ignored after the next
> major
> + bump, and libavformat will behave as if it were always set.
> + Deprecate av_packet_merge_side_data() and av_packet_split_side_data().
> +
> 2017-02-10 - xxx - lavu 55.48.100 / 55.33.0 - spherical.h
>Add AV_SPHERICAL_EQUIRECTANGULAR_TILE, av_spherical_tile_bounds(),
>and projection-specific properties (bound_left, bound_top, bound_right,
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index e32f57983c..e279dd59ee 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -4575,9 +4575,13 @@ int av_packet_shrink_side_data(AVPacket *pkt, enum
> AVPacketSideDataType type,
> uint8_t* av_packet_get_side_data(AVPacket *pkt, enum AVPacketSideDataType
> type,
> int *size);
>
> +#if FF_API_MERGE_SD_API
> +attribute_deprecated
> int av_packet_merge_side_data(AVPacket *pkt);
>
> +attribute_deprecated
> int av_packet_split_side_data(AVPacket *pkt);
> +#endif
>
> const char *av_packet_side_data_name(enum AVPacketSideDataType type);
>
> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> index 60269aa63d..6af3bb68f1 100644
> --- a/libavcodec/avpacket.c
> +++ b/libavcodec/avpacket.c
> @@ -379,6 +379,8 @@ const char *av_packet_side_data_name(enum
> AVPacketSideDataType type)
> return NULL;
> }
>
> +#if FF_API_MERGE_SD_API
> +
> #define FF_MERGE_MARKER 0x8c4d9d108e25e9feULL
>
> int av_packet_merge_side_data(AVPacket *pkt){
> @@ -460,6 +462,8 @@ int av_packet_split_side_data(AVPacket *pkt){
> return 0;
> }
>
> +#endif
> +
> uint8_t *av_packet_pack_dictionary(AVDictionary *dict, int *size)
> {
> AVDictionaryEntry *t = NULL;
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 4d1b6
[FFmpeg-devel] [PATCH 3/3] Documentation: update decklink options
---
doc/indevs.texi | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 54f270b..92804cd 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -233,6 +233,12 @@ Defaults to @option{false}.
If set to @option{true}, print a list of supported formats and exit.
Defaults to @option{false}.
+@item format
+This sets the input video mode to the mode given by the FourCC. To see
+the supported values of your device(s) use @option{list_formats}.
+Note that there is a fourCC @option{'pal '} that can also be used
+as @option{pal} (3 letters).
+
@item bm_v210
If set to @samp{1}, video is captured in 10 bit v210 instead
of uyvy422. Not all Blackmagic devices support this option.
@@ -296,21 +302,21 @@ ffmpeg -f decklink -list_formats 1 -i 'Intensity Pro'
@end example
@item
-Capture video clip at 1080i50 (format 11):
+Capture video clip at 1080i50:
@example
-ffmpeg -f decklink -i 'Intensity Pro@@11' -acodec copy -vcodec copy output.avi
+ffmpeg -format Hi50 -f decklink -i 'Intensity Pro' -acodec copy -vcodec copy
output.avi
@end example
@item
Capture video clip at 1080i50 10 bit:
@example
-ffmpeg -bm_v210 1 -f decklink -i 'UltraStudio Mini Recorder@@11' -acodec copy
-vcodec copy output.avi
+ffmpeg -bm_v210 1 -format Hi50 -f decklink -i 'UltraStudio Mini Recorder'
-acodec copy -vcodec copy output.avi
@end example
@item
Capture video clip at 1080i50 with 16 audio channels:
@example
-ffmpeg -channels 16 -f decklink -i 'UltraStudio Mini Recorder@@11' -acodec
copy -vcodec copy output.avi
+ffmpeg -channels 16 -format Hi50 -f decklink -i 'UltraStudio Mini Recorder'
-acodec copy -vcodec copy output.avi
@end example
@end itemize
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/3] decklink: new option -format to specify video modes with constant fourCCs
This patch series introduces a new option for the decklink devices. Currently, a video mode can be explicitly set via -i "devicename@modenumber", which is a common need for capture and sometimes for playout. The current number based modes are not constant between different cards and sometimes even change with SDK versions. The new option uses constants from the SDK that do not change and are kind of human readable. decklink: add fourCC of display mode to list_format output decklink: new option 'format' to set video format by fourCC Documentation: update decklink options doc/indevs.texi | 14 ++ libavdevice/decklink_common.cpp | 33 + libavdevice/decklink_common_c.h | 1 + libavdevice/decklink_dec.cpp| 2 +- libavdevice/decklink_dec_c.c| 1 + 5 files changed, 38 insertions(+), 13 deletions(-) -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] decklink: add fourCC of display mode to list_format output
---
libavdevice/decklink_common.cpp | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index 8b499c5..131d186 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -276,6 +276,7 @@ int ff_decklink_list_formats(AVFormatContext *avctx,
decklink_direction_t direct
struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
IDeckLinkDisplayModeIterator *itermode;
IDeckLinkDisplayMode *mode;
+char fourcc[32];
int i=0;
HRESULT res;
@@ -297,13 +298,15 @@ int ff_decklink_list_formats(AVFormatContext *avctx,
decklink_direction_t direct
return AVERROR(EIO);
}
-av_log(avctx, AV_LOG_INFO, "Supported formats for '%s':\n",
+av_log(avctx, AV_LOG_INFO, "Supported formats for
'%s':\n\tmode\tfourCC\tdescription",
avctx->filename);
while (itermode->Next(&mode) == S_OK) {
BMDTimeValue tb_num, tb_den;
mode->GetFrameRate(&tb_num, &tb_den);
-av_log(avctx, AV_LOG_INFO, "\t%d\t%ldx%ld at %d/%d fps",
-++i,mode->GetWidth(), mode->GetHeight(),
+av_get_codec_tag_string(fourcc, sizeof(fourcc),
mode->GetDisplayMode());
+av_log(avctx, AV_LOG_INFO, "\n\t%d\t%c%c%c%c\t%ldx%ld at %d/%d fps",
+++i, fourcc[3], fourcc[2], fourcc[1], fourcc[0],
+mode->GetWidth(), mode->GetHeight(),
(int) tb_den, (int) tb_num);
switch (mode->GetFieldDominance()) {
case bmdLowerFieldFirst:
@@ -311,9 +314,9 @@ int ff_decklink_list_formats(AVFormatContext *avctx,
decklink_direction_t direct
case bmdUpperFieldFirst:
av_log(avctx, AV_LOG_INFO, " (interlaced, upper field first)"); break;
}
-av_log(avctx, AV_LOG_INFO, "\n");
mode->Release();
}
+av_log(avctx, AV_LOG_INFO, "\n");
itermode->Release();
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] decklink: new option 'format' to set video format by fourCC
---
libavdevice/decklink_common.cpp | 22 ++
libavdevice/decklink_common_c.h | 1 +
libavdevice/decklink_dec.cpp| 2 +-
libavdevice/decklink_dec_c.c| 1 +
4 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index 131d186..548bf3b 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -143,6 +143,18 @@ static DECKLINK_BOOL field_order_eq(enum AVFieldOrder
field_order, BMDFieldDomin
return false;
}
+static DECKLINK_BOOL fourcc_eq(char *fourcc_string, BMDDisplayMode fourcc)
+{
+BMDDisplayMode fourcc_converted = 0;
+if (!fourcc_string) return false;
+if (!strcmp(fourcc_string, "pal") && fourcc == 0x70616C20) return true;
+if (strlen(fourcc_string) < 4) return false;
+fourcc_converted = ((uint8_t) fourcc_string[0] << 24) | ((uint8_t)
fourcc_string[1] << 16) |
+((uint8_t) fourcc_string[2] << 8) | ((uint8_t) fourcc_string[3]);
+if (fourcc_converted == fourcc) return true;
+return false;
+}
+
int ff_decklink_set_format(AVFormatContext *avctx,
int width, int height,
int tb_num, int tb_den,
@@ -157,8 +169,8 @@ int ff_decklink_set_format(AVFormatContext *avctx,
int i = 1;
HRESULT res;
-av_log(avctx, AV_LOG_DEBUG, "Trying to find mode for frame size %dx%d,
frame timing %d/%d, field order %d, direction %d, mode number %d\n",
-width, height, tb_num, tb_den, field_order, direction, num);
+av_log(avctx, AV_LOG_DEBUG, "Trying to find mode for frame size %dx%d,
frame timing %d/%d, field order %d, direction %d, mode number %d, mode fourCC
%s\n",
+width, height, tb_num, tb_den, field_order, direction, num,
cctx->format);
if (ctx->duplex_mode) {
DECKLINK_BOOL duplex_supported = false;
@@ -202,6 +214,7 @@ int ff_decklink_set_format(AVFormatContext *avctx,
int bmd_width = mode->GetWidth();
int bmd_height = mode->GetHeight();
BMDFieldDominance bmd_field_dominance = mode->GetFieldDominance();
+BMDDisplayMode bmd_mode = mode->GetDisplayMode();
mode->GetFrameRate(&bmd_tb_num, &bmd_tb_den);
AVRational mode_tb = av_make_q(bmd_tb_num, bmd_tb_den);
@@ -209,8 +222,9 @@ int ff_decklink_set_format(AVFormatContext *avctx,
if ((bmd_width == width &&
bmd_height == height &&
!av_cmp_q(mode_tb, target_tb) &&
- field_order_eq(field_order, bmd_field_dominance)) || i == num) {
-ctx->bmd_mode = mode->GetDisplayMode();
+ field_order_eq(field_order, bmd_field_dominance))
+ || i == num || fourcc_eq(cctx->format, bmd_mode)) {
+ctx->bmd_mode = bmd_mode;
ctx->bmd_width = bmd_width;
ctx->bmd_height = bmd_height;
ctx->bmd_tb_den = bmd_tb_den;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index d565631..161a48a 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -47,6 +47,7 @@ struct decklink_cctx {
int audio_input;
int video_input;
int draw_bars;
+char *format;
};
#endif /* AVDEVICE_DECKLINK_COMMON_C_H */
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 7df841b..594 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -539,7 +539,7 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
goto error;
}
-if (mode_num > 0) {
+if (mode_num > 0 || cctx->format) {
if (ff_decklink_set_format(avctx, DIRECTION_IN, mode_num) < 0) {
av_log(avctx, AV_LOG_ERROR, "Could not set mode %d for %s\n",
mode_num, fname);
ret = AVERROR(EIO);
diff --git a/libavdevice/decklink_dec_c.c b/libavdevice/decklink_dec_c.c
index 31818d2..07da7cc 100644
--- a/libavdevice/decklink_dec_c.c
+++ b/libavdevice/decklink_dec_c.c
@@ -31,6 +31,7 @@
static const AVOption options[] = {
{ "list_devices", "list available devices" , OFFSET(list_devices),
AV_OPT_TYPE_INT , { .i64 = 0 }, 0, 1, DEC },
{ "list_formats", "list supported formats" , OFFSET(list_formats),
AV_OPT_TYPE_INT , { .i64 = 0 }, 0, 1, DEC },
+{ "format", "set format by fourcc", OFFSET(format),
AV_OPT_TYPE_STRING, { .str = NULL}, 3, 4, DEC },
{ "bm_v210", "v210 10 bit per channel" , OFFSET(v210),
AV_OPT_TYPE_INT , { .i64 = 0 }, 0, 1, DEC },
{ "teletext_lines", "teletext lines bitmask", OFFSET(teletext_lines),
AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, 0x7LL, DEC, "teletext_lines"},
{ "standard", NULL, 0,
AV_OPT_TYPE_CONST, { .i64 = 0x7fff9fffeLL}, 0, 0,DEC, "teletext_lines"},
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.o
Re: [FFmpeg-devel] [PATCH v3 1/2] codec: bitpacked: add decoder
On Tue, Feb 28, 2017 at 11:10:23PM +0100, Michael Niedermayer wrote:
> On Tue, Feb 28, 2017 at 01:39:07PM -0500, Damien Riegel wrote:
> > Add a codec capable of decoding some formats of the RFC4175. For now
> > it's only capable of handling YCbCr-4:2:2 with 8-bit or 10-bit depth.
> >
> > For 8-bit it's a simple pass-through, for 10-bit it depacks the stream
> > in the AV_PIX_FMT_YUV422P10 pixel format.
> >
> > Signed-off-by: Damien Riegel
> > ---
> > Changes in v3:
> > - Codec has been renamed bitpacked (instead of vrawdepay)
> > - A decoding function is now chosen at codec init based on the pixel
> >format
> > - Codec marked as experimental
> >
> > libavcodec/Makefile | 1 +
> > libavcodec/allcodecs.c | 1 +
> > libavcodec/avcodec.h| 1 +
> > libavcodec/bitpacked.c | 148
> >
> > libavcodec/codec_desc.c | 7 +++
> > 5 files changed, 158 insertions(+)
> > create mode 100644 libavcodec/bitpacked.c
> >
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index 1bea44ad91..dc5e684f10 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -214,6 +214,7 @@ OBJS-$(CONFIG_BINK_DECODER)+= bink.o
> > binkdsp.o
> > OBJS-$(CONFIG_BINKAUDIO_DCT_DECODER) += binkaudio.o
> > OBJS-$(CONFIG_BINKAUDIO_RDFT_DECODER) += binkaudio.o
> > OBJS-$(CONFIG_BINTEXT_DECODER) += bintext.o cga_data.o
> > +OBJS-$(CONFIG_BITPACKED_DECODER) += bitpacked.o
> > OBJS-$(CONFIG_BMP_DECODER) += bmp.o msrledec.o
> > OBJS-$(CONFIG_BMP_ENCODER) += bmpenc.o
> > OBJS-$(CONFIG_BMV_AUDIO_DECODER) += bmvaudio.o
> > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> > index eee322b2b8..86a8fd56c5 100644
> > --- a/libavcodec/allcodecs.c
> > +++ b/libavcodec/allcodecs.c
> > @@ -366,6 +366,7 @@ void avcodec_register_all(void)
> > REGISTER_DECODER(VP8, vp8);
> > REGISTER_DECODER(VP9, vp9);
> > REGISTER_DECODER(VQA, vqa);
> > +REGISTER_DECODER(BITPACKED, bitpacked);
> > REGISTER_DECODER(WEBP, webp);
> > REGISTER_ENCODER(WRAPPED_AVFRAME, wrapped_avframe);
> > REGISTER_ENCDEC (WMV1, wmv1);
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index 925a8c7277..a0d07c64bc 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -416,6 +416,7 @@ enum AVCodecID {
> > AV_CODEC_ID_SPEEDHQ,
> > AV_CODEC_ID_FMVC,
> > AV_CODEC_ID_SCPR,
> > +AV_CODEC_ID_BITPACKED,
> >
> > /* various PCM "codecs" */
> > AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the
> > start of audio codecs
> > diff --git a/libavcodec/bitpacked.c b/libavcodec/bitpacked.c
> > new file mode 100644
> > index 00..1d935b71a1
> > --- /dev/null
> > +++ b/libavcodec/bitpacked.c
> > @@ -0,0 +1,148 @@
> > +/*
> > + * Unpack bit-packed streams to formats supported by FFmpeg
> > + * Copyright (c) 2017 Savoir-faire Linux, Inc
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with FFmpeg; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > 02110-1301 USA
> > + */
> > +
> > +/* Development sponsored by CBC/Radio-Canada */
> > +
> > +/**
> > + * @file
> > + * Bitpacked
> > + */
> > +
>
> > +#include
>
> wrong directory
>
>
> > +#include "avcodec.h"
> > +#include "internal.h"
> > +#include "get_bits.h"
> > +
> > +struct BitpackedContext {
> > +int (*decode)(AVCodecContext *avctx, AVFrame *frame,
> > + AVPacket *pkt);
> > +};
> > +
>
> > +/* For this format, it's a simple passthrough */
> > +static int bitpacked_decode_uyvy422(AVCodecContext *avctx, AVFrame *frame,
> > +AVPacket *avpkt)
> > +{
> > +int ret;
> > +
> > +/* there is no need to copy as the data already match
> > + * a known pixel format */
> > +frame->buf[0] = av_buffer_ref(avpkt->buf);
> > +ret = av_image_fill_arrays(frame->data, frame->linesize, avpkt->data,
> > + avctx->pix_fmt, avctx->width,
> > avctx->height, 1);
>
> linesize and the initial data pointers have some alignment requirements
>
> they may need to be checked before pass through
I addressed
Re: [FFmpeg-devel] [PATCH 1/2] avcodec, avformat: deprecate anything related to side data merging
On 16 March 2017 at 04:20, wm4 wrote: > This patch deprecates anything that has to do with merging/splitting > side data. Automatic side data merging (and splitting), as well as all > API symbols involved in it, are removed completely. > > Two FF_API_ defines are dedicated to deprecating API symbols related to > this: FF_API_MERGE_SD_API removes av_packet_split/merge_side_data in > libavcodec, and FF_API_LAVF_KEEPSIDE_FLAG deprecates > AVFMT_FLAG_KEEP_SIDE_DATA in libavformat. > > Since it was claimed that changing the default from merging side data to > not doing it is an ABI change, there are two additional FF_API_ defines, > which stop using the side data merging/splitting by default (and remove > any code in avformat/avcodec doing this): FF_API_MERGE_SD in libavcodec, > and FF_API_LAVF_MERGE_SD in libavformat. > > It is very much intended that FF_API_MERGE_SD and FF_API_LAVF_MERGE_SD > are quickly defined to 0 in the next ABI bump, while the API symbols are > retained for a longer time for the sake of compatibility. > AVFMT_FLAG_KEEP_SIDE_DATA will (very much intentionally) do nothing for > most of the time it will still be defined. Keep in mind that no code > exists that actually tries to unset this flag for any reason, nor does > such code need to exist. Code setting this flag explicitly will work as > before. Thus it's ok for AVFMT_FLAG_KEEP_SIDE_DATA to do nothing once > side data merging has been removed from libavformat. > > In order to avoid that anyone in the future does this incorrectly, here > is a small guide how to update the internal code on bumps: > > - next ABI bump (probably soon): > - define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it > - define FF_API_MERGE_SD to 0, and remove all code covered by it > - next API bump (typically two years in the future or so): > - define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it > - define FF_API_MERGE_SD_API to 0, and remove all code covered by it > > Isn't a major bump and API bump? So why wait until major 59 when all things getting deprecated get removed at major 58? There's no reason to keep it around for longer when it isn't even used. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] avformat/rtmpproto: change rtmp_open from url_open to url_open2
use the option set by user
Reported-by: Lancelot Lai
Signed-off-by: Steven Liu
---
libavformat/rtmpproto.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index 5d7ad79..bbafa77 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -2604,14 +2604,14 @@ static int inject_fake_duration_metadata(RTMPContext
*rt)
* and 'playpath' is a file name (the rest of the path,
* may be prefixed with "mp4:")
*/
-static int rtmp_open(URLContext *s, const char *uri, int flags)
+static int rtmp_open(URLContext *s, const char *uri, int flags, AVDictionary
**options)
{
RTMPContext *rt = s->priv_data;
char proto[8], hostname[256], path[1024], auth[100], *fname;
char *old_app, *qmark, *n, fname_buffer[1024];
uint8_t buf[2048];
int port;
-AVDictionary *opts = NULL;
+AVDictionary *opts = *options;
int ret;
if (rt->listen_timeout > 0)
@@ -3141,7 +3141,7 @@ static const AVClass flavor##_class = { \
\
const URLProtocol ff_##flavor##_protocol = { \
.name = #flavor, \
-.url_open = rtmp_open, \
+.url_open2 = rtmp_open, \
.url_read = rtmp_read, \
.url_read_seek = rtmp_seek, \
.url_read_pause = rtmp_pause,\
--
2.10.1 (Apple Git-78)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/h264_direct: Fix runtime error: signed integer overflow: -9 - 2147483647 cannot be represented in type 'int'
> > + > +if (pocdiff0 != (int)pocdiff0) > +avpriv_request_sample(sl->h264->avctx, "pocdiff0 overflow\n"); > + > Do you think this condition will actually happen in the real world apart from in glitchy live streams? Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v7] - Added Turing codec interface for ffmpeg
Dear Mark, Sorry for the long delay in replying. We have now pushed some changes to our main Turing codec repository to address your comments below. Our custom boost libraries should now be correctly installed so there is no need for preserving any additional Turing build folder. These changes are completely transparent to our ffmpeg patch, which remains valid at v7. We would appreciate comments on this. Thanks, All the best, Saverio Blasi, PhD Senior Research Engineer BBC Research & Development Centre House|56 Wood Lane|London|W12 7SB -Original Message- From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark Thompson Sent: 28 February 2017 11:02 To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH v7] - Added Turing codec interface for ffmpeg On 28/02/17 10:27, Saverio Blasi wrote: > Dear Mark, > > We provide our custom Boost libraries. In our tests we are able to build and > run using just "--enable-gpl --enable-libturing". We would prefer to keep the > pkgconfig file. I am not sure I fully understand what is required to be > changed there (if anything), could you please be a bit more specific? Well, where do those libraries end up? I agree the pkgconfig file is the correct way to do this, but it currently points at the libturing build directory which need not exist when building ffmpeg. You should be able to install the library with some prefix (below using the default /usr/local) and then use it in ffmpeg without any other magic: mkdir libturing-build cd libturing-build cmake ../path/to/libturing/source/ make make install cd .. rm -rf libturing-build mkdir ffmpeg-build cd ffmpeg-build ../path/to/ffmpeg/source/configure --enable-gpl --enable-libturing make ./ffmpeg ... -c:v libturing ... make install ffmpeg ... -c:v libturing ... For me, this sequence currently fails to link for the configure test because the custom boost libraries are not found (were not installed anywhere, as far as I can tell). Have you tried this on a vanilla install of a standard distribution? It sounds like you might have more stuff in your development setup which allows it to work. - Mark > -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Mark Thompson > Sent: 27 February 2017 11:14 > To: FFmpeg development discussions and patches > > Subject: Re: [FFmpeg-devel] [PATCH v7] - Added Turing codec interface > for ffmpeg > > On 27/02/17 08:29, Saverio Blasi wrote: >>> Right, I had a bit more of a look at it and was able to "fix" it by adding >>> the boost libraries to the ffmpeg configure line as well. >>> >>> Actually running it it all looks good to me, if as fast as a particularly >>> lethargic snail (like all H.265 encoders targetting quality). >>> >>> valgrind came up with some errors, but they appear to be on the libturing >>> side rather than in the ffmpeg wrapper (i.e. please do fix them, but they >>> don't matter to this patch). >>> >>> Thanks, >>> >>> - Mark >> >> Dear Mark, >> >> Thanks a lot for this, we are very happy to know the patch will be >> integrated. >> Regarding the problems you mention, we will have a look at the output of >> valgrind, and are also working on speeding up the encoder. > > Also the pkgconfig file: > * It refers to the libturing build directory, which need not exist after > installation. > * I think libstdc++ and the boost libraries are always required, not > just when linking statically. (Not sure how this interacts with other > parts, though - it seems to not like the system boost libraries on > Ubuntu 16.04 (1.58): do you need to install your custom boost > libraries as well?) > > It should be possible to build and run with just "--enable-gpl > --enable-libturing" on a clean "make install"ed libturing. > > Thanks, > > - Mark ___ 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] avcodec/vp56: Check avctx->error_concealment before enabling EC
Fixes timeout with 847/clusterfuzz-testcase-5291877358108672
Fixes timeout with 850/clusterfuzz-testcase-5721296509861888
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/vp56.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vp56.c b/libavcodec/vp56.c
index 9d4162bb96..bfc3d3bc7c 100644
--- a/libavcodec/vp56.c
+++ b/libavcodec/vp56.c
@@ -712,7 +712,7 @@ static int ff_vp56_decode_mbs(AVCodecContext *avctx, void
*data,
int ret = vp56_decode_mb(s, mb_row, mb_col, is_alpha);
if (ret < 0) {
damaged = 1;
-if (!s->have_undamaged_frame) {
+if (!s->have_undamaged_frame || !avctx->error_concealment)
{
s->discard_frame = 1;
return AVERROR_INVALIDDATA;
}
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/rtmpproto: change rtmp_open from url_open to url_open2
use the option set by user
Reported-by: Lancelot Lai
Signed-off-by: Steven Liu
---
libavformat/rtmpproto.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index 5d7ad79..e1fb16f 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -2604,14 +2604,13 @@ static int inject_fake_duration_metadata(RTMPContext
*rt)
* and 'playpath' is a file name (the rest of the path,
* may be prefixed with "mp4:")
*/
-static int rtmp_open(URLContext *s, const char *uri, int flags)
+static int rtmp_open(URLContext *s, const char *uri, int flags, AVDictionary
**opts)
{
RTMPContext *rt = s->priv_data;
char proto[8], hostname[256], path[1024], auth[100], *fname;
char *old_app, *qmark, *n, fname_buffer[1024];
uint8_t buf[2048];
int port;
-AVDictionary *opts = NULL;
int ret;
if (rt->listen_timeout > 0)
@@ -3141,7 +3140,7 @@ static const AVClass flavor##_class = { \
\
const URLProtocol ff_##flavor##_protocol = { \
.name = #flavor, \
-.url_open = rtmp_open, \
+.url_open2 = rtmp_open, \
.url_read = rtmp_read, \
.url_read_seek = rtmp_seek, \
.url_read_pause = rtmp_pause,\
--
2.10.1 (Apple Git-78)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavc/aarch64: add simple idct neon functions
On Wed, Mar 15, 2017 at 01:14:42PM +0100, Matthieu Bouron wrote:
> On Mon, Mar 06, 2017 at 03:48:57PM +0100, Matthieu Bouron wrote:
> > On Thu, Feb 23, 2017 at 04:59:16PM +0100, Matthieu Bouron wrote:
> > > Hello,
> > >
> > > The following patchset add the ff_simple_idct function neon functions for
> > > the
> > > aarch64 platform. It's ported from armv7 simple_idct_neon with some
> > > improvements:
> > > * the source idct blocks are now loaded once and kept in v24-v31
> > > * the source idct blocks are no longer overriden in idct_col4_top
> > > * the destination is now written in one pass at the end of
> > >ff_simple_idct{,_put,_add}_neon
> > >
> > > It is bitexact with the armv7 neon implementation.
> > >
> > > Here are some results (reported by {START,STOP}_TIMER) on an Odroid-C2
> > > (Cortex
> > > A53):
> > >
> > > Functions IDCT: simple IDCT: simpleneon
> > > ff_simple_idct_put 9795 units3170 units
> > > ff_simple_idct_add10227 units3302 units
> > >
> >
> > Ping.
>
> I'd like to push the patch tomorrow if there is no objection.
>
> If that helps, here is the output of mjpegdec with simple and simpleneon
> idct methods.
>
> Original: http://0x5c.me/idct/original.jpg
> Simple: http://0x5c.me/idct/simplec.png
> Simpleneon: http://0x5c.me/idct/simpleneon.png
>
> The diff between simple and simpleneon shows off some off by 1
> differences: http://0x5c.me/idct/diff.png (simpleneon aarch64 is bitexact
> with its armv7 counterpart though).
Patchset pushed.
Matthieu
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/vp56: Require 1 undamaged frame for 5 damaged frames for concealment to be used
On Wed, Mar 15, 2017 at 08:44:25PM -0400, Ronald S. Bultje wrote: > Hi, > > On Wed, Mar 15, 2017 at 6:12 PM, Michael Niedermayer > wrote: > > > On Wed, Mar 15, 2017 at 07:18:30PM +, Kieran Kunhya wrote: > > > > > > > > > > I have tons of testcases for h264 that are 1KB and can make error > > > > > > concealment run for ages. > > > > > > > > and how is this related to a fix for th vp* decoder ? > > > > > > > > > > My point is you can spend a lifetime fixing obscure conditions that cause > > > error concealment to take a long time. > > > > the vp56 EC code > > just sets every block to the reference frames content > > > I don't see how this helps the user experience. Like i said previously if there is damage, its better with error concealment than without. Thats true in general not specific to vp56. also without EC we will need to change fate this way: --- ./tests/ref/fate/vp52017-03-13 15:59:01.833910756 +0100 +++ tests/data/fate/vp5 2017-03-16 09:32:21.934865428 +0100 @@ -249,4 +249,3 @@ 0,243,243,1, 233472, 0x6f530ac6 0,244,244,1, 233472, 0x94f7466c 0,245,245,1, 233472, 0xa8c1d365 -0,246,246,1, 233472, 0xbf73f1b7 as the last frame in the sample is damaged, probably truncated we cannot output a partly uninitialzed frame nor can we use it as reference frame afterwards. If there where frames afterwards they would use a wrong/different reference frame or be discarded as well until the next keyframe. > > I once again think you should consider removing the vp56 EC code until we > have a better idea of requirements of and need for such a feature. As the one having implemented it i see both requirement and need. So theres no sense or way i could consider removing it on the basis that these are missing or until they are found. I can remove it becouse people want it removed. also for this specific patch here there is possibly another solution which ill test and if it works submit a patch [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample/swresample: do not use s32p internally by default when resampling
On Thu, Mar 16, 2017 at 1:01 PM, wm4 wrote:
> On Thu, 16 Mar 2017 12:43:10 +0700
> Muhammad Faiz wrote:
>
>> use fltp when doing s32 -> s32 resampling
>> because s32p has no simd optimization
>>
>> benchmark:
>> old 17.913s
>> new 7.584s (use fma3)
>>
>> Signed-off-by: Muhammad Faiz
>> ---
>> libswresample/swresample.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/libswresample/swresample.c b/libswresample/swresample.c
>> index f2e6600..74c96dc 100644
>> --- a/libswresample/swresample.c
>> +++ b/libswresample/swresample.c
>> @@ -223,6 +223,8 @@ av_cold int swr_init(struct SwrContext *s){
>> }else if( av_get_planar_sample_fmt(s-> in_sample_fmt) ==
>> AV_SAMPLE_FMT_S32P
>> && av_get_planar_sample_fmt(s->out_sample_fmt) ==
>> AV_SAMPLE_FMT_S32P
>> && !s->rematrix
>> + && s->out_sample_rate == s->in_sample_rate
>> + && !(s->flags & SWR_FLAG_RESAMPLE)
>> && s->engine != SWR_ENGINE_SOXR){
>> s->int_sample_fmt= AV_SAMPLE_FMT_S32P;
>> }else if(av_get_bytes_per_sample(s->in_sample_fmt) <= 4){
>
> Wouldn't going over float lose bits?
Yes, of course. But when resampling with default opt, aliasing happens at
about -90dB which is only 15 bits. Keeping 32 bits has no point at all.
> I guess most times, s32 is
> actually 24 bit padded (since we have no 24 bit format). But it could
> be true 32 bit as well (with all bits used). Or does it use double, or
> am I missing something else?
Using double is overkill, i think.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] lavfi: deprecate AVFilterGraph->resample_lavr_opts
On 6 March 2017 at 02:46, Rostislav Pehlivanov wrote: > Not used by anything at all since we don't auto insert lavr filters. > > > Ping, I'll push this tomorrow if there are no objections. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] ffmpeg: don't use resample_lavr_opts
On 6 March 2017 at 17:51, Michael Niedermayer wrote: > On Mon, Mar 06, 2017 at 02:46:49AM +, Rostislav Pehlivanov wrote: > > That pointer isn't used by absolutely anything. > > > > Signed-off-by: Rostislav Pehlivanov > > --- > > ffmpeg_filter.c | 1 - > > 1 file changed, 1 deletion(-) > > LGTM > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Many that live deserve death. And some that die deserve life. Can you give > it to them? Then do not be too eager to deal out death in judgement. For > even the very wise cannot see all ends. -- Gandalf > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > Thanks, pushed ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] lavfi: remove af_asynts filter
On 6 March 2017 at 20:47, Marton Balint wrote: > > On Mon, 6 Mar 2017, Rostislav Pehlivanov wrote: > > Long overdue for removal, af_aresample should be used instead. >> >> Signed-off-by: Rostislav Pehlivanov >> --- >> Changelog | 1 + >> configure | 2 - >> doc/filters.texi| 33 - >> libavfilter/Makefile| 1 - >> libavfilter/af_asyncts.c| 323 -- >> -- >> libavfilter/allfilters.c| 1 - >> libavfilter/version.h | 2 +- >> tests/fate/filter-audio.mak | 6 - >> 8 files changed, 2 insertions(+), 367 deletions(-) >> delete mode 100644 libavfilter/af_asyncts.c >> >> diff --git a/Changelog b/Changelog >> index 13628ca28b..88e188bacb 100644 >> --- a/Changelog >> +++ b/Changelog >> @@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to >> youngest within each release, >> releases are sorted from youngest to oldest. >> >> version : >> +- Removed asyncts filter (use af_aresample instead) >> > > Entires are sorted from oldest to youngest :P > > Thanks for the cleanup. > > > Changed locally. I'll push this tomorrow if there are no objections. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
