date:20170829

[FFmpeg-devel] [PATCH] avfilter/lavfutils: remove usage of AVStream->codec

2017-08-29 Thread James Almer

Signed-off-by: James Almer 
---
 libavfilter/lavfutils.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/libavfilter/lavfutils.c b/libavfilter/lavfutils.c
index 35878b3d50..b6319cf027 100644
--- a/libavfilter/lavfutils.c
+++ b/libavfilter/lavfutils.c
@@ -29,6 +29,7 @@ int ff_load_image(uint8_t *data[4], int linesize[4],
 AVFormatContext *format_ctx = NULL;
 AVCodec *codec;
 AVCodecContext *codec_ctx;
+AVCodecParameters *par;
 AVFrame *frame;
 int frame_decoded, ret = 0;
 AVPacket pkt;
@@ -50,14 +51,27 @@ int ff_load_image(uint8_t *data[4], int linesize[4],
 return ret;
 }
 
-codec_ctx = format_ctx->streams[0]->codec;
-codec = avcodec_find_decoder(codec_ctx->codec_id);
+par = format_ctx->streams[0]->codecpar;
+codec = avcodec_find_decoder(par->codec_id);
 if (!codec) {
 av_log(log_ctx, AV_LOG_ERROR, "Failed to find codec\n");
 ret = AVERROR(EINVAL);
 goto end;
 }
 
+codec_ctx = avcodec_alloc_context3(codec);
+if (!codec_ctx) {
+av_log(log_ctx, AV_LOG_ERROR, "Failed to alloc video decoder 
context\n");
+ret = AVERROR(ENOMEM);
+goto end;
+}
+
+ret = avcodec_parameters_to_context(codec_ctx, par);
+if (ret < 0) {
+av_log(log_ctx, AV_LOG_ERROR, "Failed to copy codec parameters to 
decoder context\n");
+goto end;
+}
+
 av_dict_set(, "thread_type", "slice", 0);
 if ((ret = avcodec_open2(codec_ctx, codec, )) < 0) {
 av_log(log_ctx, AV_LOG_ERROR, "Failed to open codec\n");
@@ -96,7 +110,7 @@ int ff_load_image(uint8_t *data[4], int linesize[4],
 
 end:
 av_packet_unref();
-avcodec_close(codec_ctx);
+avcodec_free_context(_ctx);
 avformat_close_input(_ctx);
 av_frame_free();
 av_dict_free();
-- 
2.13.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter: remove duplicate and disabled trace log function

2017-08-29 Thread James Almer

It's already defined and actually enabled depending on configure options
elsewhere.
---
 libavfilter/internal.h | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/libavfilter/internal.h b/libavfilter/internal.h
index 2ff75aa778..f9679ed1d7 100644
--- a/libavfilter/internal.h
+++ b/libavfilter/internal.h
@@ -33,6 +33,7 @@
 #include "version.h"
 #include "video.h"
 #include "libavcodec/avcodec.h"
+#include "libavcodec/internal.h"
 
 typedef struct AVFilterCommand {
 double time;///< time expressed in seconds
@@ -246,14 +247,6 @@ void ff_command_queue_pop(AVFilterContext *filter);
 
 /* misc trace functions */
 
-/* #define FF_AVFILTER_TRACE */
-
-#ifdef FF_AVFILTER_TRACE
-#define ff_tlog(pctx, ...) av_log(pctx, AV_LOG_DEBUG, __VA_ARGS__)
-#else
-#define ff_tlog(pctx, ...) do { if (0) av_log(pctx, AV_LOG_DEBUG, 
__VA_ARGS__); } while (0)
-#endif
-
 #define FF_TPRINTF_START(ctx, func) ff_tlog(NULL, "%-16s: ", #func)
 
 char *ff_get_ref_perms_string(char *buf, size_t buf_size, int perms);
-- 
2.13.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [Patch] CUDA Thumbnail Filter

2017-08-29 Thread Yogender Gupta

Attached is a CUDA version of the thumbnail filter, this helps accelerate 
thumbnails generations significantly, when using the GPU pipeline.

Regards,
Yogender

---
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-thumnail_cuda-CUDA-Thumbnail-Filter.patch
Description: 0001-thumnail_cuda-CUDA-Thumbnail-Filter.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v17] avformat/dashdec: add dash demuxer base version

2017-08-29 Thread Steven Liu

updated, remove modify of avformat/utils, that is wrong operation

ffmpeg need a dash demuxer for demux the dash formats base on
https://github.com/samsamsam-iptvplayer/exteplayer3/blob/master/tmp/ffmpeg/patches/3.2.2/01_add_dash_demux.patch

TODO:
1. support multi bitrate dash

v2 fixed:
1. from autodetect to disabled
2. from camelCase code style to ffmpeg code style
3. from RepType to AVMediaType
4. fix variable typo
5. change time value from uint32_t to uint64_t
6. removed be used once API
7. change 'time(NULL)`, except it is not 2038-safe.' to av_gettime and av_timegm
8. merge complex free operation to free_fragment
9. use API from snprintf to av_asprintf

v3 fixed:
1. fix typo from --enabled-xml2 to --enable-xml2

v4 fixed:
1. from --enable-xml2 to --enable-libxml2
2. move system includes to top
3. remove nouse includes
4. rename enum name
5. add a trailing comma for the last entry enum
6. fix comment typo
7. add const to DASHContext class front
8. check sscanf if return arguments and give warning message when error
9. check validity before free seg->url and seg
10. check if the val is null, before use atoll

v5 fixed:
1. fix typo from mainifest to manifest

v6 fixed:
1. from realloc to av_realloc
2. from free to av_free

v7 fixed:
1. remove the -lxml2 from configure when require_pkg_config

v8 fixed:
1. fix replace filename template by av_asprintf secure problem

v9 modified:
1. make manifest parser clearly

v10 fixed:
1. fix function API name code style
2. remove redundant strreplace call
3. remove redundant memory operation and check return value from 
get_content_url()
4. add space between ) and {
5. remove no need to log the value for print

v11 fixed:
1. from atoll to strtoll
Suggested-by: Michael Niedermayer 

v12 fixed:
1. remove strreplace and instead by av_strreplace
Suggested-by: Nicolas George 

v13 fixed:
1. fix bug: cannot play:
http://dash.edgesuite.net/akamai/bbb_30fps/bbb_30fps.mpd
Reported-by: Andy Furniss 

v14 fixed:
1. fix bug: TLS connection was non-properly terminated
2. fix bug: No trailing CRLF found in HTTP header
Reported-by: Andy Furniss 

v15 fixed:
1. play youtube link: ffmpeg -i $(youtube-dl -J 
"https://www.youtube.com/watch?v=XmL19DOP_Ls; | jq -r 
".requested_formats[0].manifest_url")
2. code refine for timeline living stream
Reported-by: Ricardo Constantino 

v16 fixed:
1. remove the snprintf and instead by get_segment_filename make safety
2. remove unnecessary loops
3. updated xmlStrcmp and xmlFree to av_* functions
4. merge code repeat into one function
5. add memory alloc faild check
6. update update_init_section and open_url
7. output safety error message when filename template not safe
Suggested-by : wm4 

v17 fixed:
1. add memory alloc faild check
2. fix resource space error at free_representation

Signed-off-by: Steven Liu 
Signed-off-by: samsamsam 
---
 configure|4 +
 libavformat/Makefile |1 +
 libavformat/allformats.c |2 +-
 libavformat/dashdec.c| 2026 ++
 4 files changed, 2032 insertions(+), 1 deletion(-)
 create mode 100644 libavformat/dashdec.c

diff --git a/configure b/configure
index 61d8160491..c03ff02297 100755
--- a/configure
+++ b/configure
@@ -272,6 +272,7 @@ External library support:
   --enable-libxcb-shapeenable X11 grabbing shape rendering [autodetect]
   --enable-libxvid enable Xvid encoding via xvidcore,
native MPEG-4/Xvid encoder exists [no]
+  --enable-libxml2 enable XML parsing using the C library libxml2 [no]
   --enable-libzimg enable z.lib, needed for zscale filter [no]
   --enable-libzmq  enable message passing via libzmq [no]
   --enable-libzvbi enable teletext support via libzvbi [no]
@@ -1578,6 +1579,7 @@ EXTERNAL_LIBRARY_LIST="
 libvpx
 libwavpack
 libwebp
+libxml2
 libzimg
 libzmq
 libzvbi
@@ -2939,6 +2941,7 @@ avi_muxer_select="riffenc"
 caf_demuxer_select="iso_media riffdec"
 caf_muxer_select="iso_media"
 dash_muxer_select="mp4_muxer"
+dash_demuxer_deps="libxml2"
 dirac_demuxer_select="dirac_parser"
 dts_demuxer_select="dca_parser"
 dtshd_demuxer_select="dca_parser"
@@ -6005,6 +6008,7 @@ enabled openssl   && { use_pkg_config openssl 
openssl/ssl.h OPENSSL_init
check_lib openssl openssl/ssl.h 
SSL_library_init -lssl -lcrypto -lws2_32 -lgdi32 ||
die "ERROR: openssl not found"; }
 enabled qtkit_indev  && { check_header_objcc QTKit/QTKit.h || disable 
qtkit_indev; }
+enabled libxml2  && require_pkg_config libxml-2.0 
libxml2/libxml/xmlversion.h xmlCheckVersion
 
 if enabled gcrypt; then
 GCRYPT_CONFIG="${cross_prefix}libgcrypt-config"
diff --git a/libavformat/Makefile b/libavformat/Makefile
index

[FFmpeg-devel] [PATCH v17] avformat/dashdec: add dash demuxer base version

2017-08-29 Thread Steven Liu

ffmpeg need a dash demuxer for demux the dash formats base on
https://github.com/samsamsam-iptvplayer/exteplayer3/blob/master/tmp/ffmpeg/patches/3.2.2/01_add_dash_demux.patch

TODO:
1. support multi bitrate dash

v2 fixed:
1. from autodetect to disabled
2. from camelCase code style to ffmpeg code style
3. from RepType to AVMediaType
4. fix variable typo
5. change time value from uint32_t to uint64_t
6. removed be used once API
7. change 'time(NULL)`, except it is not 2038-safe.' to av_gettime and av_timegm
8. merge complex free operation to free_fragment
9. use API from snprintf to av_asprintf

v3 fixed:
1. fix typo from --enabled-xml2 to --enable-xml2

v4 fixed:
1. from --enable-xml2 to --enable-libxml2
2. move system includes to top
3. remove nouse includes
4. rename enum name
5. add a trailing comma for the last entry enum
6. fix comment typo
7. add const to DASHContext class front
8. check sscanf if return arguments and give warning message when error
9. check validity before free seg->url and seg
10. check if the val is null, before use atoll

v5 fixed:
1. fix typo from mainifest to manifest

v6 fixed:
1. from realloc to av_realloc
2. from free to av_free

v7 fixed:
1. remove the -lxml2 from configure when require_pkg_config

v8 fixed:
1. fix replace filename template by av_asprintf secure problem

v9 modified:
1. make manifest parser clearly

v10 fixed:
1. fix function API name code style
2. remove redundant strreplace call
3. remove redundant memory operation and check return value from 
get_content_url()
4. add space between ) and {
5. remove no need to log the value for print

v11 fixed:
1. from atoll to strtoll
Suggested-by: Michael Niedermayer 

v12 fixed:
1. remove strreplace and instead by av_strreplace
Suggested-by: Nicolas George 

v13 fixed:
1. fix bug: cannot play:
http://dash.edgesuite.net/akamai/bbb_30fps/bbb_30fps.mpd
Reported-by: Andy Furniss 

v14 fixed:
1. fix bug: TLS connection was non-properly terminated
2. fix bug: No trailing CRLF found in HTTP header
Reported-by: Andy Furniss 

v15 fixed:
1. play youtube link: ffmpeg -i $(youtube-dl -J 
"https://www.youtube.com/watch?v=XmL19DOP_Ls; | jq -r 
".requested_formats[0].manifest_url")
2. code refine for timeline living stream
Reported-by: Ricardo Constantino 

v16 fixed:
1. remove the snprintf and instead by get_segment_filename make safety
2. remove unnecessary loops
3. updated xmlStrcmp and xmlFree to av_* functions
4. merge code repeat into one function
5. add memory alloc faild check
6. update update_init_section and open_url
7. output safety error message when filename template not safe
Suggested-by : wm4 

v17 fixed:
1. add memory alloc faild check
2. fix resource space error at free_representation

Signed-off-by: Steven Liu 
Signed-off-by: samsamsam 
---
 configure|4 +
 libavformat/Makefile |1 +
 libavformat/allformats.c |2 +-
 libavformat/dashdec.c| 2026 ++
 libavformat/utils.c  |6 +
 5 files changed, 2038 insertions(+), 1 deletion(-)
 create mode 100644 libavformat/dashdec.c

diff --git a/configure b/configure
index 61d8160491..c03ff02297 100755
--- a/configure
+++ b/configure
@@ -272,6 +272,7 @@ External library support:
   --enable-libxcb-shapeenable X11 grabbing shape rendering [autodetect]
   --enable-libxvid enable Xvid encoding via xvidcore,
native MPEG-4/Xvid encoder exists [no]
+  --enable-libxml2 enable XML parsing using the C library libxml2 [no]
   --enable-libzimg enable z.lib, needed for zscale filter [no]
   --enable-libzmq  enable message passing via libzmq [no]
   --enable-libzvbi enable teletext support via libzvbi [no]
@@ -1578,6 +1579,7 @@ EXTERNAL_LIBRARY_LIST="
 libvpx
 libwavpack
 libwebp
+libxml2
 libzimg
 libzmq
 libzvbi
@@ -2939,6 +2941,7 @@ avi_muxer_select="riffenc"
 caf_demuxer_select="iso_media riffdec"
 caf_muxer_select="iso_media"
 dash_muxer_select="mp4_muxer"
+dash_demuxer_deps="libxml2"
 dirac_demuxer_select="dirac_parser"
 dts_demuxer_select="dca_parser"
 dtshd_demuxer_select="dca_parser"
@@ -6005,6 +6008,7 @@ enabled openssl   && { use_pkg_config openssl 
openssl/ssl.h OPENSSL_init
check_lib openssl openssl/ssl.h 
SSL_library_init -lssl -lcrypto -lws2_32 -lgdi32 ||
die "ERROR: openssl not found"; }
 enabled qtkit_indev  && { check_header_objcc QTKit/QTKit.h || disable 
qtkit_indev; }
+enabled libxml2  && require_pkg_config libxml-2.0 
libxml2/libxml/xmlversion.h xmlCheckVersion
 
 if enabled gcrypt; then
 GCRYPT_CONFIG="${cross_prefix}libgcrypt-config"
diff --git a/libavformat/Makefile b/libavformat/Makefile
index f2b465cfa2..3d478749d0 100644
---

[FFmpeg-devel] [PATCH] avfilter/interlace: prevent over-sharpening with the complex low-pass filter

2017-08-29 Thread Thomas Mundt

Hi,

we did a transcoding cascade test at work were over-sharpening became
visible with the complex low-pass filter. This patch rectifies the
behaviour.

Please comment...


0001-avfilter-interlace-prevent-over-sharpening-with-the-.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/vf_overlay: Restore shorthand option order

2017-08-29 Thread Michael Niedermayer

Signed-off-by: Michael Niedermayer 
---
 libavfilter/framesync2.c | 6 --
 libavfilter/framesync2.h | 6 ++
 libavfilter/vf_overlay.c | 8 
 3 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/libavfilter/framesync2.c b/libavfilter/framesync2.c
index fae06aa1f5..aea9937ce9 100644
--- a/libavfilter/framesync2.c
+++ b/libavfilter/framesync2.c
@@ -28,12 +28,6 @@
 #define OFFSET(member) offsetof(FFFrameSync, member)
 #define FLAGS AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM
 
-enum EOFAction {
-EOF_ACTION_REPEAT,
-EOF_ACTION_ENDALL,
-EOF_ACTION_PASS
-};
-
 static const char *framesync_name(void *ptr)
 {
 return "framesync";
diff --git a/libavfilter/framesync2.h b/libavfilter/framesync2.h
index 745e896bc8..63a0eabbeb 100644
--- a/libavfilter/framesync2.h
+++ b/libavfilter/framesync2.h
@@ -23,6 +23,12 @@
 
 #include "bufferqueue.h"
 
+enum EOFAction {
+EOF_ACTION_REPEAT,
+EOF_ACTION_ENDALL,
+EOF_ACTION_PASS
+};
+
 /*
  * TODO
  * Export convenient options.
diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
index 4166e7c095..619a5a6354 100644
--- a/libavfilter/vf_overlay.c
+++ b/libavfilter/vf_overlay.c
@@ -817,9 +817,16 @@ static int activate(AVFilterContext *ctx)
 static const AVOption overlay_options[] = {
 { "x", "set the x expression", OFFSET(x_expr), AV_OPT_TYPE_STRING, {.str = 
"0"}, CHAR_MIN, CHAR_MAX, FLAGS },
 { "y", "set the y expression", OFFSET(y_expr), AV_OPT_TYPE_STRING, {.str = 
"0"}, CHAR_MIN, CHAR_MAX, FLAGS },
+{ "eof_action", "Action to take when encountering EOF from secondary input 
",
+OFFSET(fs.opt_eof_action), AV_OPT_TYPE_INT, { .i64 = EOF_ACTION_REPEAT 
},
+EOF_ACTION_REPEAT, EOF_ACTION_PASS, .flags = FLAGS, "eof_action" },
+{ "repeat", "Repeat the previous frame.",   0, AV_OPT_TYPE_CONST, { 
.i64 = EOF_ACTION_REPEAT }, .flags = FLAGS, "eof_action" },
+{ "endall", "End both streams.",0, AV_OPT_TYPE_CONST, { 
.i64 = EOF_ACTION_ENDALL }, .flags = FLAGS, "eof_action" },
+{ "pass",   "Pass through the main input.", 0, AV_OPT_TYPE_CONST, { 
.i64 = EOF_ACTION_PASS },   .flags = FLAGS, "eof_action" },
 { "eval", "specify when to evaluate expressions", OFFSET(eval_mode), 
AV_OPT_TYPE_INT, {.i64 = EVAL_MODE_FRAME}, 0, EVAL_MODE_NB-1, FLAGS, "eval" },
  { "init",  "eval expressions once during initialization", 0, 
AV_OPT_TYPE_CONST, {.i64=EVAL_MODE_INIT},  .flags = FLAGS, .unit = "eval" },
  { "frame", "eval expressions per-frame",  0, 
AV_OPT_TYPE_CONST, {.i64=EVAL_MODE_FRAME}, .flags = FLAGS, .unit = "eval" },
+{ "shortest", "force termination when the shortest input terminates", 
OFFSET(fs.opt_shortest), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, FLAGS },
 { "format", "set output format", OFFSET(format), AV_OPT_TYPE_INT, 
{.i64=OVERLAY_FORMAT_YUV420}, 0, OVERLAY_FORMAT_NB-1, FLAGS, "format" },
 { "yuv420", "", 0, AV_OPT_TYPE_CONST, {.i64=OVERLAY_FORMAT_YUV420}, 
.flags = FLAGS, .unit = "format" },
 { "yuv422", "", 0, AV_OPT_TYPE_CONST, {.i64=OVERLAY_FORMAT_YUV422}, 
.flags = FLAGS, .unit = "format" },
@@ -827,6 +834,7 @@ static const AVOption overlay_options[] = {
 { "rgb","", 0, AV_OPT_TYPE_CONST, {.i64=OVERLAY_FORMAT_RGB},
.flags = FLAGS, .unit = "format" },
 { "gbrp",   "", 0, AV_OPT_TYPE_CONST, {.i64=OVERLAY_FORMAT_GBRP},   
.flags = FLAGS, .unit = "format" },
 { "auto",   "", 0, AV_OPT_TYPE_CONST, {.i64=OVERLAY_FORMAT_AUTO},   
.flags = FLAGS, .unit = "format" },
+{ "repeatlast", "repeat overlay of the last overlay frame", 
OFFSET(fs.opt_repeatlast), AV_OPT_TYPE_BOOL, {.i64=1}, 0, 1, FLAGS },
 { NULL }
 };
 
-- 
2.14.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avformat/mxfenc: Replace literal numbers by named enum values.

2017-08-29 Thread Michael Niedermayer

On Tue, Aug 29, 2017 at 02:13:21AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mxfenc.c | 83 
> ++--
>  1 file changed, 61 insertions(+), 22 deletions(-)

applied

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2

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] avformat/mxfdec: Fix Sign error in mxf_read_primer_pack()

2017-08-29 Thread Michael Niedermayer

From: 孙浩(晓黑) 

Fixes: 20170829B.mxf

Co-Author: 张洪亮(望初)" 
Found-by: Xiaohei and Wangchu from Alibaba Security Team
Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 6adb77d81f..91731a7533 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -500,7 +500,7 @@ static int mxf_read_primer_pack(void *arg, AVIOContext *pb, 
int tag, int size, U
 avpriv_request_sample(pb, "Primer pack item length %d", item_len);
 return AVERROR_PATCHWELCOME;
 }
-if (item_num > 65536) {
+if (item_num > 65536 || item_num < 0) {
 av_log(mxf->fc, AV_LOG_ERROR, "item_num %d is too large\n", item_num);
 return AVERROR_INVALIDDATA;
 }
-- 
2.14.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/3] avformat/nsvdec: Fix DoS due to lack of eof check in nsvs_file_offset loop.

2017-08-29 Thread Michael Niedermayer

From: 孙浩(晓黑) <tony...@alibaba-inc.com>

Fixes: 20170829.nsv

Co-Author: 张洪亮(望初)" <wangchu@alibaba-inc.com>
Found-by: Xiaohei and Wangchu from Alibaba Security Team
Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc>
---
 libavformat/nsvdec.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavformat/nsvdec.c b/libavformat/nsvdec.c
index c6ddb67bbd..d8ce656817 100644
--- a/libavformat/nsvdec.c
+++ b/libavformat/nsvdec.c
@@ -335,8 +335,11 @@ static int nsv_parse_NSVf_header(AVFormatContext *s)
 if (!nsv->nsvs_file_offset)
 return AVERROR(ENOMEM);
 
-for(i=0;i<table_entries_used;i++)
+for(i=0;i<table_entries_used;i++) {
+if (avio_feof(pb))
+return AVERROR_INVALIDDATA;
 nsv->nsvs_file_offset[i] = avio_rl32(pb) + size;
+}
 
 if(table_entries > table_entries_used &&
avio_rl32(pb) == MKTAG('T','O','C','2')) {
-- 
2.14.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/3] avformat/mxfdec: Fix DoS issues in mxf_read_index_entry_array()

2017-08-29 Thread Michael Niedermayer

From: 孙浩(晓黑) 

Fixes: 20170829A.mxf

Co-Author: 张洪亮(望初)" 
Found-by: Xiaohei and Wangchu from Alibaba Security Team
Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfdec.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index f8d0f9e057..6adb77d81f 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -899,6 +899,8 @@ static int mxf_read_index_entry_array(AVIOContext *pb, 
MXFIndexTableSegment *seg
 segment->nb_index_entries = avio_rb32(pb);
 
 length = avio_rb32(pb);
+if(segment->nb_index_entries && length < 11)
+return AVERROR_INVALIDDATA;
 
 if 
(!(segment->temporal_offset_entries=av_calloc(segment->nb_index_entries, 
sizeof(*segment->temporal_offset_entries))) ||
 !(segment->flag_entries  = 
av_calloc(segment->nb_index_entries, sizeof(*segment->flag_entries))) ||
@@ -909,6 +911,8 @@ static int mxf_read_index_entry_array(AVIOContext *pb, 
MXFIndexTableSegment *seg
 }
 
 for (i = 0; i < segment->nb_index_entries; i++) {
+if(avio_feof(pb))
+return AVERROR_INVALIDDATA;
 segment->temporal_offset_entries[i] = avio_r8(pb);
 avio_r8(pb);/* KeyFrameOffset 
*/
 segment->flag_entries[i] = avio_r8(pb);
-- 
2.14.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v15] avformat/dashdec: add dash demuxer base version

2017-08-29 Thread Liu Steven


> 在 2017年8月30日，上午3:30，samsamsam  写道：
> 
> and think about the safety :
> %02c%lld
> %s%d%d%d%d
> 
> What? With my solution this is not problem.
> Why you think %s%d%d%d%d or %02c%lld give any problem?

localhost:dash StevenLiu$ ./ffmpeg -i /tmp/dash.mpd
ffmpeg version N-87079-g257f0d09f7 Copyright (c) 2000-2017 the FFmpeg developers
  built with Apple LLVM version 8.1.0 (clang-802.0.42)
  configuration: --enable-libass --enable-opengl --enable-libx264 
--enable-libmp3lame --enable-gpl --enable-nonfree --prefix=/usr/local 
--enable-libopencv --enable-libtesseract --enable-libspeex --enable-libfreetype 
--enable-libfontconfig --enable-libfdk-aac --enable-videotoolbox 
--enable-libxml2
  libavutil  55. 74.100 / 55. 74.100
  libavcodec 57.103.101 / 57.103.101
  libavformat57. 78.100 / 57. 78.100
  libavdevice57.  7.101 / 57.  7.101
  libavfilter 6.100.100 /  6.100.100
  libswscale  4.  7.103 /  4.  7.103
  libswresample   2.  8.100 /  2.  8.100
  libpostproc54.  6.100 / 54.  6.100
[dash @ 0x7ffb76802a00] 11
Segmentation fault: 11ted 1 times
localhost:dash StevenLiu$ grep -r "%s%05d" /tmp/dash.mpd
/tmp/dash.mpd:  
localhost:dash StevenLiu$

reproduce:
ffmpeg -i input -c copy -f dash /tmp/dash.mpd
vim /tmp/dash.mpd
seek to `media="chunk-stream$RepresentationID`
the context is `  `"%0*"PRId64`"?
> 
> Dnia 28 sierpnia 2017 03:30 Rodger Combs  napisał(a):
> 
> If you know of such a vulnerability, report it to ffmpeg-secur...@ffmpeg.org. 
> New code with known vulnerabilities will not be accepted.
> 
> Sent from my iPhone
> 
> On Aug 27, 2017, at 14:04, samsamsam  wrote:
> get_repl_pattern_and_format, you should have a fixed value of something like 
> `"%0*"PRId64`
> 
> If you afraid about safety then the only thing which need to be added to 
> get_repl_pattern_and_format is validation of format.
> Simple loop to validate format will be enough. Do you agree?
> 
> Anyway we are talking about safety but parser for mp4 atoms missing checking 
> and there is quite easy to make segfault of the libavformat when try to 
> prepared mp4 file.
> 
> I understand that you want to have maximum safety with new code but I hope 
> you know that ffmpeg at all is not safety.
> 
> Regards,
> SSS
> 
> Dnia 27 sierpnia 2017 16:34 Rodger Combs  napisał(a):
> 
> You're still calling snprintf with a string derived from the XML, which is 
> still not safe. Rather than having a format copied from the source in 
> get_repl_pattern_and_format, you should have a fixed value of something like 
> `"%0*"PRId64`, and specify an additional "precision" argument you parse from 
> the XML yourself. I can't reiterate this enough: _never pass data from the 
> XML into the format-string arg of a printf-family function_.
> 
> Also, rather than calling snprintf() twice with an av_malloc() in between, 
> you can just call av_asprintf(). That's what it does internally anyway.
> 
> On Aug 27, 2017, at 09:19, Steven Liu  wrote:
> 
> ffmpeg need a dash demuxer for demux the dash formats base on
> https://github.com/samsamsam-iptvplayer/exteplayer3/blob/master/tmp/ffmpeg/patches/3.2.2/01_add_dash_demux.patch
> 
> TODO:
> 1. support multi bitrate dash
> 
> v2 fixed:
> 1. from autodetect to disabled
> 2. from camelCase code style to ffmpeg code style
> 3. from RepType to AVMediaType
> 4. fix variable typo
> 5. change time value from uint32_t to uint64_t
> 6. removed be used once API
> 7. change 'time(NULL)`, except it is not 2038-safe.' to av_gettime and 
> av_timegm
> 8. merge complex free operation to free_fragment
> 9. use API from snprintf to av_asprintf
> 
> v3 fixed:
> 1. fix typo from --enabled-xml2 to --enable-xml2
> 
> v4 fixed:
> 1. from --enable-xml2 to --enable-libxml2
> 2. move system includes to top
> 3. remove nouse includes
> 4. rename enum name
> 5. add a trailing comma for the last entry enum
> 6. fix comment typo
> 7. add const to DASHContext class front
> 8. check sscanf if return arguments and give warning message when error
> 9. check validity before free seg->url and seg
> 10. check if the val is null, before use atoll
> 
> v5 fixed:
> 1. fix typo from mainifest to manifest
> 
> v6 fixed:
> 1. from realloc to av_realloc
> 2. from free to av_free
> 
> v7 fixed:
> 1. remove the -lxml2 from configure when require_pkg_config
> 
> v8 fixed:
> 1. fix replace filename template by av_asprintf secure problem
> 
> v9 modified:
> 1. make manifest parser clearly
> 
> v10 fixed:
> 1. fix function API name code style
> 2. remove redundant strreplace call
> 3. remove redundant memory operation and check return value from 
> get_content_url()
> 4. add space between ) and {
> 5. remove no need to log the value for print
> 
> v11 fixed:
> 1. from atoll to strtoll
> 
> v12 fixed:
> 1. remove strreplace and instead by av_strreplace
> 
> v13 fixed:
> 1. fix bug: cannot play:
>

[FFmpeg-devel] [PATCH] avformat/mpegts: opus muxing & demuxing expanded

2017-08-29 Thread pkv.stream


Hello again (patch attached this time),

this patch expands support for mapping_family 255 (and part of 1) for 
mpegts muxer and demuxer.


(Ambisonics family 2 & 3 not covered).

See commit commentary.

My case use (as an example) is that I needed to broadcast in mpeg-ts 
with 16 audio channels coming from SDI, corresponding to 16 different 
languages. Opus supports up to 255 channels but the mpegts muxer and 
demuxer allowed only up to 8 channels.


Thanks for all reviews and opinion.

From e0e8edb1173539deb653081209d6b7e4bf94b1c1 Mon Sep 17 00:00:00 2001
From: pkviet 
Date: Tue, 29 Aug 2017 01:24:12 +0200
Subject: [PATCH] avformat/mpegts: opus muxing & demuxing expanded

Support for opus in mpegts demuxer was brought by commit
9cfa68c560bdec82d2d5ec079f9c5b0f9ca37af0 (Kieran Kunhya).
Support for opus in mpegts muxer was then added by commit
01509cdf9287b975eced1fd609a8201fbd1438e3 (S. Droge).
Later commit 37941878f193a2316c514bd5ba55bfe9d2dfdfcf by Michael Graczyk
added support of mapping_family encoder parameter which allows for up to 255
audio channels (for family 255).
While matroska muxer & demuxer readily accepts mapping_family, it is not the
case for mpegts muxer & demuxer for all the range of the parameter (family 255
and also part of family 1 with channel_config_code > 0x81 unsupported).
This commit brings such a support.
---
 libavcodec/libopusenc.c |  2 +-
 libavformat/mpegts.c| 54 ++---
 libavformat/mpegtsenc.c | 19 +++--
 3 files changed, 65 insertions(+), 10 deletions(-)

diff --git a/libavcodec/libopusenc.c b/libavcodec/libopusenc.c
index c40fcde..77d8310 100644
--- a/libavcodec/libopusenc.c
+++ b/libavcodec/libopusenc.c
@@ -368,7 +368,7 @@ static av_cold int libopus_encode_init(AVCodecContext 
*avctx)
 goto fail;
 }
 
-/* Header includes channel mapping table if and only if mapping family is 
0 */
+/* Header includes channel mapping table if and only if mapping family is 
NOT 0 */
 header_size = 19 + (mapping_family == 0 ? 0 : 2 + avctx->channels);
 avctx->extradata = av_malloc(header_size + AV_INPUT_BUFFER_PADDING_SIZE);
 if (!avctx->extradata) {
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 4d2f5c6..8c2349b 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -1633,7 +1633,7 @@ static const uint8_t opus_stream_cnt[9] = {
 1, 1, 1, 2, 2, 3, 4, 4, 5,
 };
 
-static const uint8_t opus_channel_map[8][8] = {
+static const uint8_t opus_channel_map_a[8][8] = {
 { 0 },
 { 0,1 },
 { 0,2,1 },
@@ -1644,6 +1644,17 @@ static const uint8_t opus_channel_map[8][8] = {
 { 0,6,1,2,3,4,5,7 },
 };
 
+static const uint8_t opus_channel_map_b[8][8] = {
+{ 0 },
+{ 0,1 },
+{ 0,1,2 },
+{ 0,1,2,3 },
+{ 0,1,2,3,4 },
+{ 0,1,2,3,4,5 },
+{ 0,1,2,3,4,5,6 },
+{ 0,1,2,3,4,5,6,7 },
+};
+
 int ff_parse_mpeg2_descriptor(AVFormatContext *fc, AVStream *st, int 
stream_type,
   const uint8_t **pp, const uint8_t *desc_list_end,
   Mp4Descr *mp4_descr, int mp4_descr_count, int 
pid,
@@ -1887,9 +1898,46 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
AVStream *st, int stream_type
 st->codecpar->extradata[18] = channel_config_code ? 
(channels > 2) : /* Dual Mono */ 255;
 st->codecpar->extradata[19] = 
opus_stream_cnt[channel_config_code];
 st->codecpar->extradata[20] = 
opus_coupled_stream_cnt[channel_config_code];
-memcpy(>codecpar->extradata[21], 
opus_channel_map[channels - 1], channels);
+memcpy(>codecpar->extradata[21], 
opus_channel_map_a[channels - 1], channels);
 } else {
-avpriv_request_sample(fc, "Opus in MPEG-TS - 
channel_config_code > 0x8");
+if (channel_config_code == 0x81) {
+channels = get8(pp, desc_end);
+st->codecpar->extradata_size = 22 + channels;
+int *extradata = av_malloc((22 + channels) * 
sizeof(int));
+for (int i = 0; i <= (22+channels); i++) {
+if (i < 9) {
+extradata[i] = opus_default_extradata[i];
+}
+else {
+extradata[i] = 0;
+}
+}
+memcpy(st->codecpar->extradata, extradata, 
sizeof(extradata));
+av_free(extradata);
+st->codecpar->extradata[9] = channels;
+st->codecpar->extradata[18] = 255;
+st->codecpar->extradata[19] = channels;
+st->codecpar->extradata[20] = 0;
+int *opus_channel_map255 = av_malloc(channels * 
sizeof(int));
+

[FFmpeg-devel] [PATCH] avformat/mpegts: opus muxing & demuxing expanded

2017-08-29 Thread pkv.stream


Hello,

this patch expands support for mapping_family 255 (and part of 1) for 
mpegts muxer and demuxer.


(Ambisonics family 2 & 3 not covered).

See commit commentary.

My case use (as an example) is that I needed to broadcast in mpeg-ts 
with 16 audio channels coming from SDI, corresponding to 16 different 
languages. Opus supports up to 255 channels but the mpegts muxer and 
demuxer allowed only up to 8 channels.


Thanks for all reviews and opinion.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/hevc_ps: Fix undefined shift in pcm code

2017-08-29 Thread Michael Niedermayer

On Mon, Aug 28, 2017 at 01:33:49AM +0200, Michael Niedermayer wrote:
> Fixes: runtime error: shift exponent -1 is negative
> Fixes: 3091/clusterfuzz-testcase-minimized-6229767969832960
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/hevc_ps.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

applied

[...]
-- 
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 2/2] avcodec/snowdec: Fix integer overflow in decode_subband_slice_buffered()

2017-08-29 Thread Michael Niedermayer

On Mon, Aug 28, 2017 at 01:33:50AM +0200, Michael Niedermayer wrote:
> Fixes: runtime error: signed integer overflow: 267 * 8388608 cannot be 
> represented in type 'int'
> Fixes: 2743/clusterfuzz-testcase-minimized-5820652076400640
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/snowdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/h264idct_template: Fix integer overflow in ff_h264_idct8_add()

2017-08-29 Thread Michael Niedermayer

On Thu, Aug 17, 2017 at 03:54:57AM +0200, Michael Niedermayer wrote:
> Fixes: 2891/clusterfuzz-testcase-minimized-5881795457318912
> Fixes: runtime error: signed integer overflow: 1551827968 - -775913984 cannot 
> be represented in type 'int'
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/h264idct_template.c | 28 ++--
>  1 file changed, 14 insertions(+), 14 deletions(-)

applied

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.


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] avformat/mxfenc: Check that the video codec in D-10 is MPEG-2

2017-08-29 Thread Michael Niedermayer

On Tue, Aug 29, 2017 at 10:10:36AM +0200, Matthieu Bouron wrote:
> On Tue, Aug 29, 2017 at 02:13:20AM +0200, Michael Niedermayer wrote:
> > Others do not work, but nothing rejects them prior to this patch if the
> > parameters otherwise match
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/mxfenc.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > index ccfa0d6341..71f4b5b905 100644
> > --- a/libavformat/mxfenc.c
> > +++ b/libavformat/mxfenc.c
> > @@ -2104,6 +2104,10 @@ static int mxf_write_header(AVFormatContext *s)
> >  
> >  sc->video_bit_rate = st->codecpar->bit_rate;
> >  if (s->oformat == _mxf_d10_muxer) {
> > +if (st->codecpar->codec_id != AV_CODEC_ID_MPEG2VIDEO) {
> > +av_log(s, AV_LOG_ERROR, "error MXF D-10 only support 
> > MPEG-2 Video\n");
> > +return -1;
> > +}
> 
> Shouldn't it be AVERROR(EINVAL) instead of -1 ? Otherwise LGTM.

EINVAL is more correct i will change to that, i used -1 because thats
what most of the function uses

will apply with that change

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avformat/flvdec: Set need_context_update when setting the initial extradata

2017-08-29 Thread Alex Converse

Fixes ticket 6398.

Debugged with the help of James Almer and Hendrik Leppkes.
---
 libavformat/flvdec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 94c9e28334..2e70352c53 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -754,6 +754,7 @@ static int flv_get_extradata(AVFormatContext *s, AVStream 
*st, int size)
 av_freep(>codecpar->extradata);
 if (ff_get_extradata(s, st->codecpar, s->pb, size) < 0)
 return AVERROR(ENOMEM);
+st->internal->need_context_update = 1;
 return 0;
 }
 
-- 
2.13.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] avformat: Handle AV_CODEC_CAP_CHANNEL_CONF when first frame fails to decode

2017-08-29 Thread Alex Converse

Fixes probing the stream from ticket 6398.

Noticed by James Almer.
---
 libavformat/utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 23865c88c4..68ba8aa85b 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2997,7 +2997,7 @@ static int try_decode_frame(AVFormatContext *s, AVStream 
*st, AVPacket *avpkt,
 while ((pkt.size > 0 || (!pkt.data && got_picture)) &&
ret >= 0 &&
(!has_codec_parameters(st, NULL) || 
!has_decode_delay_been_guessed(st) ||
-(!st->codec_info_nb_frames &&
+(!st->nb_decoded_frames &&
  (avctx->codec->capabilities & AV_CODEC_CAP_CHANNEL_CONF {
 got_picture = 0;
 if (avctx->codec_type == AVMEDIA_TYPE_VIDEO ||
-- 
2.13.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: add support for libnpp* from cuda sdk 9

2017-08-29 Thread Ricardo Constantino

On 29 August 2017 at 13:38, Timo Rothenpieler  wrote:

> Signed-off-by: Timo Rothenpieler 
> ---
>  configure | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 61d8160491..172ff3fc07 100755
> --- a/configure
> +++ b/configure
> @@ -5875,7 +5875,9 @@ enabled libmfx&& { use_pkg_config libmfx
> "mfx/mfxvideo.h" MFXInit ||
>  enabled libmodplug&& require_pkg_config libmodplug
> libmodplug/modplug.h ModPlug_Load
>  enabled libmp3lame&& require "libmp3lame >= 3.98.3" lame/lame.h
> lame_set_VBR_quality -lmp3lame
>  enabled libmysofa && require libmysofa "mysofa.h" mysofa_load
> -lmysofa
> -enabled libnpp&& require libnpp npp.h nppGetLibVersion -lnppi
> -lnppc
> +enabled libnpp&& { check_lib libnpp npp.h nppGetLibVersion
> -lnppig -lnppicc -lnppc ||
> +   check_lib libnpp npp.h nppGetLibVersion
> -lnppi -lnppc ||
> +   die "ERROR: libnpp not found"; }
>  enabled libopencore_amrnb && require libopencore_amrnb
> opencore-amrnb/interf_dec.h Decoder_Interface_init -lopencore-amrnb
>  enabled libopencore_amrwb && require libopencore_amrwb
> opencore-amrwb/dec_if.h D_IF_init -lopencore-amrwb
>  enabled libopencv && { check_header opencv2/core/core_c.h &&
> --
> 2.14.1
>
>
Tested on Windows with 64-bit MinGW, working fine.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 13/16] lavfi/vf_psnr: convert to framesync2.

2017-08-29 Thread Nicolas George

Le duodi 12 fructidor, an CCXXV, Paul B Mahol a écrit :
> Now I get stupid and useless:
> 
> libavfilter/vf_psnr.c: In function ***do_psnr***:
> libavfilter/vf_psnr.c:149:14: warning: ***main*** is usually a function 
> [-Wmain]
>  AVFrame *main, *ref;

I noticed them; there are a few others. Changing them belonged in a
separate patch, and I did not want to clutter the patch series with
cosmetics.

I will change them all in lavfi if we consider this is worth fixing, bit
personally I consider gcc is wrong to report this as a warning.

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 13/16] lavfi/vf_psnr: convert to framesync2.

2017-08-29 Thread Paul B Mahol

On 8/10/17, Nicolas George  wrote:
> Signed-off-by: Nicolas George 
> ---
>  libavfilter/Makefile  |  2 +-
>  libavfilter/vf_psnr.c | 50
> +++---
>  2 files changed, 28 insertions(+), 24 deletions(-)
>
>

Now I get stupid and useless:

libavfilter/vf_psnr.c: In function ***do_psnr***:
libavfilter/vf_psnr.c:149:14: warning: ***main*** is usually a function [-Wmain]
 AVFrame *main, *ref;


gcc 6.2.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] fate/pixlet : add test for rgb

2017-08-29 Thread Paul B Mahol

On 8/28/17, Martin Vignali  wrote:
> 2017-04-03 2:21 GMT+02:00 Michael Niedermayer :
>
>> On Sun, Apr 02, 2017 at 11:29:38PM +0200, Martin Vignali wrote:
>> > Hello,
>> >
>> > In attach patch to add a fate test for pixlet decoder
>> >
>> > Sample can be found here :
>> > https://we.tl/HYuFmmmfIe
>>
>> file uploaded
>>
>
> Ping for the patch
>
> Martin
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Michael?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3] fate: add tests for some video source filters

2017-08-29 Thread Tobias Rapp


On 25.07.2017 11:11, Tobias Rapp wrote:

Adds FATE tests for the previously untested allrgb, allyuv, rgbtestsrc,
smptebars, smptehdbars and yuvtestsrc filters.

Also adds a test for testsrc2 filter with rgb+alpha.

Signed-off-by: Tobias Rapp 
---
  tests/fate/filter-video.mak| 24 ++
  tests/ref/fate/filter-allrgb   | 10 
  tests/ref/fate/filter-allyuv   | 10 
  tests/ref/fate/filter-rgbtestsrc   | 10 
  tests/ref/fate/filter-smptebars| 10 
  tests/ref/fate/filter-smptehdbars  | 10 
  tests/ref/fate/filter-testsrc2-rgba| 75 ++
  tests/ref/fate/filter-yuvtestsrc-yuv444p   | 10 
  tests/ref/fate/filter-yuvtestsrc-yuv444p12 | 10 
  9 files changed, 169 insertions(+)
  create mode 100644 tests/ref/fate/filter-allrgb
  create mode 100644 tests/ref/fate/filter-allyuv
  create mode 100644 tests/ref/fate/filter-rgbtestsrc
  create mode 100644 tests/ref/fate/filter-smptebars
  create mode 100644 tests/ref/fate/filter-smptehdbars
  create mode 100644 tests/ref/fate/filter-testsrc2-rgba
  create mode 100644 tests/ref/fate/filter-yuvtestsrc-yuv444p
  create mode 100644 tests/ref/fate/filter-yuvtestsrc-yuv444p12

[...]


Ping.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avformat/mxfenc: Allow overriding numerical color_siting value.

2017-08-29 Thread wm4

On Tue, 29 Aug 2017 15:02:49 +0200
Michael Niedermayer  wrote:

> On Tue, Aug 29, 2017 at 12:02:18PM +0200, wm4 wrote:
> > On Tue, 29 Aug 2017 11:59:05 +0200
> > Michael Niedermayer  wrote:
> >   
> > > On Tue, Aug 29, 2017 at 11:02:32AM +0200, wm4 wrote:  
> > > > On Tue, 29 Aug 2017 02:13:19 +0200
> > > > Michael Niedermayer  wrote:
> > > > 
> > > > > Signed-off-by: Michael Niedermayer 
> > > > > ---
> > > > >  libavformat/mxfenc.c | 7 ++-
> > > > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > > > > index 12fc9abbc6..ccfa0d6341 100644
> > > > > --- a/libavformat/mxfenc.c
> > > > > +++ b/libavformat/mxfenc.c
> > > > > @@ -322,6 +322,7 @@ typedef struct MXFContext {
> > > > >  uint8_t umid[16];///< unique material identifier
> > > > >  int channel_count;
> > > > >  int signal_standard;
> > > > > +int color_siting;
> > > > >  uint32_t tagged_value_count;
> > > > >  AVRational audio_edit_rate;
> > > > >  int store_user_comments;
> > > > > @@ -2085,6 +2086,8 @@ static int mxf_write_header(AVFormatContext *s)
> > > > >  case AVCHROMA_LOC_TOP: sc->color_siting = 1; break;
> > > > >  case AVCHROMA_LOC_CENTER:  sc->color_siting = 3; break;
> > > > >  }
> > > > > +if (mxf->color_siting >= 0)
> > > > > +sc->color_siting = mxf->color_siting;
> > > > >  
> > > > >  mxf->timecode_base = (tbc.den + tbc.num/2) / tbc.num;
> > > > >  spf = ff_mxf_get_samples_per_frame(s, tbc);
> > > > > @@ -2668,7 +2671,9 @@ static int mxf_interleave(AVFormatContext *s, 
> > > > > AVPacket *out, AVPacket *pkt, int
> > > > >  { "smpte349m", "SMPTE 349M (1485 Mbps mappings)",\
> > > > >0, AV_OPT_TYPE_CONST, {.i64 = 6}, -1, 7, 
> > > > > AV_OPT_FLAG_ENCODING_PARAM, "signal_standard"},\
> > > > >  { "smpte428", "SMPTE 428-1 DCDM",\
> > > > > -  0, AV_OPT_TYPE_CONST, {.i64 = 7}, -1, 7, 
> > > > > AV_OPT_FLAG_ENCODING_PARAM, "signal_standard"},
> > > > > +  0, AV_OPT_TYPE_CONST, {.i64 = 7}, -1, 7, 
> > > > > AV_OPT_FLAG_ENCODING_PARAM, "signal_standard"},\
> > > > > +{ "color_siting", "Force/set Color siting",\
> > > > > +  offsetof(MXFContext, color_siting), AV_OPT_TYPE_INT, {.i64 = 
> > > > > -1}, -1, 7, AV_OPT_FLAG_ENCODING_PARAM, "color_siting"},\
> > > > >  
> > > > >  
> > > > >  
> > > > 
> > > > What an absurd patch. This should be done by generic code overriding
> > > > the chroma_location field on AVFrames sent to the encoders. We don't
> > > > need inconsistent private options for an inconsistent set of encoders
> > > > to override generic parameters in an inconsistent way. What's even the
> > > > point?
> > > 
> > > The point of this change is to be able to set any color siting value.
> > > MXF has some redundant values. The fields from AVFrame are not enough
> > > to choose this unless we want MXF specific information in AVFrames
> > > 
> > > [...]  
> > 
> > You probably want to use some specialized MXF tool then.  
> 
> It should be possible to generate mxf files with just one tool not 2.
> In fact this change is for someone else not me, i probably wont be
> using it much.

MXF is such a complex format that FFmpeg can't hope it can generate all
possible MXF variants and use all of its possible features. There are
plenty of mp4/mkv/other features that FFmpeg can't write. So that's no
justification on its own.

I could probably send 100s of patches adding tiny unneeded features for
writing obscure mkv elements using private options.

Sometimes, such features have a real justification because either a
feature doesn't fit into FFmpeg's abstractions, or because it's needed
as a workaround to deal with multiple broken MXF readers, but I've not
seen that from you either.

> Do you object to this patch ?
> If you veto it, i will not apply it of course.

Yes.

> 
> if not i will apply it with the lines reordered to avoid the \ issue
> raised by paul

> as FFmpeg is intended to be a universal multimedia tool and requiring
> a 2nd tool is cumbersome.

Oh, that's a great reason to dump unneeded crap into FFmpeg.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

2017-08-29 Thread wm4

On Tue, 29 Aug 2017 15:11:55 +0200
Jorge Ramirez  wrote:

> On 08/25/2017 05:35 PM, wm4 wrote:
> >> +static inline void set_pts(V4L2Buffer *out, int64_t pts)
> >> +{
> >> +if (pts == AV_NOPTS_VALUE) {
> >> +/* invalid timestamp: not sure how to handle this case */
> >> +out->timestamp.tv_sec  = 0;
> >> +out->timestamp.tv_usec = 0;
> >> +} else {
> >> +AVRational v4l2_timebase = { 1, 100 };
> >> +int64_t v4l2_pts = av_rescale_q(pts, out->context->time_base, 
> >> v4l2_timebase);
> >> +out->timestamp.tv_sec  = v4l2_pts / INT64_C(100);
> >> +out->timestamp.tv_usec = v4l2_pts % INT64_C(100);
> >> +}
> >> +}  
> > Why does it require a fixed timebase? A decoder shouldn't even look at
> > the timestamps, it should only pass them though. Also, not using DTS
> > will make it a nightmare to support containers like avi.
> >
> > I suspect the decoder tries to "fix" timestamps, or maybe even does
> > something particularly bad like reordering frames by timestamps. This
> > is NOT something that should be in a kernel API.
> >
> > (FFmpeg native decoders_and_  hwaccels pass through both PTS and DTS,
> > and don't touch their values.)
> >  
> 
> ok I will just pass through the dts/pts and return them unmodified for 
> decoding and retest.
> 
> what about for encoding? should I just read the pts from the driver, 
> rescale it back to time_base and set both pts& on the returned 
> packet to the this same value?
> 
> after this I think I am ready to post v7 with all the review comments 
> addressed so thanks a lot for all the responses!

Things are different from encoders. These should synthesize correct pts
and dts from the pts set on input frames.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2] ffprobe: use consistent string for unspecified color_range value

2017-08-29 Thread Tobias Rapp

Makes the handling of unspecified/unknown color_range values on stream
level consistent to the value used on frame level.

Signed-off-by: Tobias Rapp 
---
 ffprobe.c  | 8 
 tests/ref/fate/ffprobe_compact | 4 ++--
 tests/ref/fate/ffprobe_csv | 4 ++--
 tests/ref/fate/ffprobe_default | 4 ++--
 tests/ref/fate/ffprobe_flat| 4 ++--
 tests/ref/fate/ffprobe_ini | 4 ++--
 tests/ref/fate/mxf-probe-dnxhd | 2 +-
 tests/ref/fate/mxf-probe-dv25  | 2 +-
 8 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/ffprobe.c b/ffprobe.c
index ba10563..b2e8949 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -1925,11 +1925,11 @@ static void print_pkt_side_data(WriterContext *w,
 writer_print_section_footer(w);
 }
 
-static void print_color_range(WriterContext *w, enum AVColorRange color_range, 
const char *fallback)
+static void print_color_range(WriterContext *w, enum AVColorRange color_range)
 {
 const char *val = av_color_range_name(color_range);
 if (!val || color_range == AVCOL_RANGE_UNSPECIFIED) {
-print_str_opt("color_range", fallback);
+print_str_opt("color_range", "unknown");
 } else {
 print_str("color_range", val);
 }
@@ -2157,7 +2157,7 @@ static void show_frame(WriterContext *w, AVFrame *frame, 
AVStream *stream,
 print_int("top_field_first",frame->top_field_first);
 print_int("repeat_pict",frame->repeat_pict);
 
-print_color_range(w, frame->color_range, "unknown");
+print_color_range(w, frame->color_range);
 print_color_space(w, frame->colorspace);
 print_primaries(w, frame->color_primaries);
 print_color_trc(w, frame->color_trc);
@@ -2534,7 +2534,7 @@ static int show_stream(WriterContext *w, AVFormatContext 
*fmt_ctx, int stream_id
 else   print_str_opt("pix_fmt", "unknown");
 print_int("level",   par->level);
 
-print_color_range(w, par->color_range, "N/A");
+print_color_range(w, par->color_range);
 print_color_space(w, par->color_space);
 print_color_trc(w, par->color_trc);
 print_primaries(w, par->color_primaries);
diff --git a/tests/ref/fate/ffprobe_compact b/tests/ref/fate/ffprobe_compact
index 910837d..4a0f4ee 100644
--- a/tests/ref/fate/ffprobe_compact
+++ b/tests/ref/fate/ffprobe_compact
@@ -27,6 +27,6 @@ 
frame|media_type=video|stream_index=1|key_frame=1|pkt_pts=6144|pkt_pts_time=0.12
 
packet|codec_type=video|stream_index=2|pts=6144|pts_time=0.12|dts=6144|dts_time=0.12|duration=2048|duration_time=0.04|convergence_duration=N/A|convergence_duration_time=N/A|size=3|pos=1023544|flags=K_
 
frame|media_type=video|stream_index=2|key_frame=1|pkt_pts=6144|pkt_pts_time=0.12|pkt_dts=6144|pkt_dts_time=0.12|best_effort_timestamp=6144|best_effort_timestamp_time=0.12|pkt_duration=2048|pkt_duration_time=0.04|pkt_pos=1023544|pkt_size=3|width=100|height=100|pix_fmt=rgb24|sample_aspect_ratio=1:1|pict_type=I|coded_picture_number=0|display_picture_number=0|interlaced_frame=0|top_field_first=0|repeat_pict=0|color_range=unknown|color_space=unknown|color_primaries=unknown|color_transfer=unknown|chroma_location=unspecified
 
stream|index=0|codec_name=pcm_s16le|profile=unknown|codec_type=audio|codec_time_base=1/44100|codec_tag_string=PSD[16]|codec_tag=0x10445350|sample_fmt=s16|sample_rate=44100|channels=1|channel_layout=unknown|bits_per_sample=16|id=N/A|r_frame_rate=0/0|avg_frame_rate=0/0|time_base=1/44100|start_pts=0|start_time=0.00|duration_ts=N/A|duration=N/A|bit_rate=705600|max_bit_rate=N/A|bits_per_raw_sample=N/A|nb_frames=N/A|nb_read_frames=6|nb_read_packets=6|disposition:default=0|disposition:dub=0|disposition:original=0|disposition:comment=0|disposition:lyrics=0|disposition:karaoke=0|disposition:forced=0|disposition:hearing_impaired=0|disposition:visual_impaired=0|disposition:clean_effects=0|disposition:attached_pic=0|disposition:timed_thumbnails=0|tag:E=mc²|tag:encoder=Lavc
 pcm_s16le

Re: [FFmpeg-devel] [PATCH] libavcodec: fix field_order labelling

2017-08-29 Thread Tobias Rapp


On 27.08.2017 19:13, Marton Balint wrote:



On Sat, 12 Aug 2017, Dave Rice wrote:

[..]

Also utils.c associates these field order values with the following 
labels:



AV_FIELD_TB  -> "top coded first (swapped)";
AV_FIELD_BT -> "bottom coded first (swapped)";


From my reading, I infer that "top coded first (swapped)” means "top 
coded first, bottom displayed first”; however in practice from files 
generated by QuickTime and FFmpeg files with a value of TB have the 
top field displayed first, so I think the labels are swapped. In the 
patch below I suggest using “top first (interleaved)” for TB and 
“bottom first (interleaved)” for BT.


Comments?


From de871b3fa891fa0ae6856461c1f8305cc889cde7 Mon Sep 17 00:00:00 2001
From: Dave Rice 
Date: Sat, 12 Aug 2017 12:30:43 -0400
Subject: [PATCH] libavcodec: fix field_order labelling

---
libavcodec/avcodec.h | 4 ++--
libavcodec/utils.c   | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index c594993766..37c39072b3 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1726,8 +1726,8 @@ enum AVFieldOrder {
    AV_FIELD_PROGRESSIVE,
    AV_FIELD_TT,  //< Top coded_first, top displayed first
    AV_FIELD_BB,  //< Bottom coded first, bottom displayed first
-    AV_FIELD_TB,  //< Top coded first, bottom displayed first
-    AV_FIELD_BT,  //< Bottom coded first, top displayed first
+    AV_FIELD_TB,  //< Interleaved coding, top displayed first
+    AV_FIELD_BT,  //< Interleaved coding, bottom displayed first
};


I agree that a lot of stuff in the codebase is consistent with the 
updated descriptions. However, as far as I see libavformat/mxfdec.c 
seems to follow the existing docs, so I think that needs changing as well.


In mxfdec.c the value of field_order is constructed from VideoLineMap 
and FieldDominance. The VideoLineMap property indicates coded field 
order and the FieldDominance property indicated whether display field 
order is flipped compared to the coded order or not.


So yes, mxfdec.c is following the current documentation of AVFieldOrder 
and applying the patch would conflict with the MXF specs, AFAICS.


CC-ing Jérôme Martinez as he has much more experience with MXF 
real-world file variations.


Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/exr : add SSE SIMD for reorder_pixels v2 (WIP)

2017-08-29 Thread Ivan Kalvachev

On 8/26/17, Martin Vignali  wrote:
> Hello,
>
> in attach new patch for SSE simd of reorder pixels in exr decoder (use by
> zip and rle uncompress),
> after comments on the previous patch by Ivan Kalvachev.
>
> After testing only on a small buffer, i fix the overread problem of the
> previous patch (who hid the last loop trouble)
>
> pass fate test for me (on Mac Os X)
>
>
> Tested with the decoding of a sequence of 150 HD Exr images (CGI render
> with 17 layers per file in float pixel, ZIP16 compression)
>
> SSE :
> 349190 decicycles in reorder_pixels_zip,  130716 runs,356 skips
> bench: utime=109.222s
> bench: maxrss=607002624kB
>
> Scalar :
> 3039686 decicycles in reorder_pixels_zip,  130395 runs,677 skips
> bench: utime=123.042s
> bench: maxrss=607019008kB

That's impressive. :)

> Comments Welcome

Since you asked ;)
---
> [...]
> +;**
> +
> +%include "libavutil/x86/x86util.asm"

Still missing explicit x86inc.asm

> +SECTION .text
> +
> +;--
> +; void ff_reorder_pixels_sse2(uint8_t *src, uint8_t *dst, int size)
> +;--
> +
> +
> +INIT_XMM sse2
> +cglobal reorder_pixels, 3,6,3, src, dst, size

You do use r5, but not r4. Change r5 to r4 and decrease the usage above.

> +
> +shrsizeq, 1;   sizeq = half_size
> +mov   r3, sizeq
> +shr   r3, 4;   r3 = half_size/16 -> loop_simd count
> +
> +loop_simd:
> +;initial condition loop
> +jle  after_loop_simd;  jump to scalar part if loop_simd 
> count(r3) is 0
> +
> +movdqam0, [srcq];   load first part
> +movdqum1, [srcq + sizeq];   load second part

Would you test if moving the movdqu first makes any difference in speed?
I had a similar case and I think that makes it faster,
since movdqu has bigger latency.
Might not matter on newer cpu.

(If you can't tell the difference, leave it as it is.)

> +movdqam2, m0;   copy m0
> +
> +punpcklbw m2, m1;   interleaved part 1

Both instructions could be combined as
 punpcklbw m2, m0, m1
And the movdqa would be inserted by the x86inc macro.

> +movdqa[dstq], m2;   copy to dst array
> +
> +punpckhbw m0, m1;   interleaved part 2
> +movdqa [dstq+mmsize], m0;   copy to dst array
> +add dstq, 2*mmsize; inc dst
> +add srcq, mmsize;   inc src
> +sub   r3, 1
> +jmploop_simd

I think there is a way to remove some of these arithmetics.
x86 allows a bit more complicated addressing in the form of
[const+r1+r2*x] where x could be power of two -> 1, 2, 4, 8.

If you use r3 as address offset (aka r3+=mmsize)
you can do:
mov  [dsrq+r3*2+mmsize], m3

This however would mean that you'd need
src2 as separate pointer/register, because
[src1q+sizeq+r3] uses 3 different registers.

You'll also need 2 instruction "add" and "cmp"
at the end of the loop.

Well, there are (at least) 2 ways to combine the add+cmp.

1. If you start with r3=aligned(sizeq)-mmsize ,
and you make descending loop with single "sub r3, mmsize",
until you go negative.

2. A trick used in x264.
You start with r3=-1*aligned(sizeq) and you use "add r3,mmsize"
until you reach zero.
Since r3 is used as offset, you'd have to correct all the pointers too
(aka, add aligned sizeq to src1, src2 and double to dst).

In my tests, on my machine #2 was always slower
(and that's without second scalar loop,
that has to deal with "corrected" pointers).

I also found that accessing memory in descending order
is no worse than ascending, so I've been using
descending loops unless I needed increasing
positive index for some other reason.

I do not request that you use any of these methods,
but you might want to test and see
if any of them is faster for you.

> +after_loop_simd:
> +;scalar part
> +mov   r3, sizeq;r3 = half_size
> +and   r3, 15;   r3 = half_size % 16

mmsize-1 , instead of 15.

> +loop_scalar:
> +;initial condition loop
> +cmp   r3, 0
> +jleend
> +
> +mov  r5b, [srcq];   load byte first part
> +mov   [dstq], r5b;  copy first byte to dst
> +
> +mov  r5b, [srcq + sizeq];   load byte second part
> +mov [dstq+1], r5b;  copy byte second part

In theory doing one write instead of two should be faster.

You can do some evil code here, using high and low byte register access
available from the 16 bit days of x86 (ax={ah,al}). Doing so is not better,

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

2017-08-29 Thread Jorge Ramirez


On 08/25/2017 05:35 PM, wm4 wrote:

+static inline void set_pts(V4L2Buffer *out, int64_t pts)
+{
+if (pts == AV_NOPTS_VALUE) {
+/* invalid timestamp: not sure how to handle this case */
+out->timestamp.tv_sec  = 0;
+out->timestamp.tv_usec = 0;
+} else {
+AVRational v4l2_timebase = { 1, 100 };
+int64_t v4l2_pts = av_rescale_q(pts, out->context->time_base, 
v4l2_timebase);
+out->timestamp.tv_sec  = v4l2_pts / INT64_C(100);
+out->timestamp.tv_usec = v4l2_pts % INT64_C(100);
+}
+}

Why does it require a fixed timebase? A decoder shouldn't even look at
the timestamps, it should only pass them though. Also, not using DTS
will make it a nightmare to support containers like avi.

I suspect the decoder tries to "fix" timestamps, or maybe even does
something particularly bad like reordering frames by timestamps. This
is NOT something that should be in a kernel API.

(FFmpeg native decoders_and_  hwaccels pass through both PTS and DTS,
and don't touch their values.)



ok I will just pass through the dts/pts and return them unmodified for 
decoding and retest.


what about for encoding? should I just read the pts from the driver, 
rescale it back to time_base and set both pts& on the returned 
packet to the this same value?


after this I think I am ready to post v7 with all the review comments 
addressed so thanks a lot for all the responses!



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avformat/mxfenc: Allow overriding numerical color_siting value.

2017-08-29 Thread Michael Niedermayer

On Tue, Aug 29, 2017 at 12:02:18PM +0200, wm4 wrote:
> On Tue, 29 Aug 2017 11:59:05 +0200
> Michael Niedermayer  wrote:
> 
> > On Tue, Aug 29, 2017 at 11:02:32AM +0200, wm4 wrote:
> > > On Tue, 29 Aug 2017 02:13:19 +0200
> > > Michael Niedermayer  wrote:
> > >   
> > > > Signed-off-by: Michael Niedermayer 
> > > > ---
> > > >  libavformat/mxfenc.c | 7 ++-
> > > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > > > index 12fc9abbc6..ccfa0d6341 100644
> > > > --- a/libavformat/mxfenc.c
> > > > +++ b/libavformat/mxfenc.c
> > > > @@ -322,6 +322,7 @@ typedef struct MXFContext {
> > > >  uint8_t umid[16];///< unique material identifier
> > > >  int channel_count;
> > > >  int signal_standard;
> > > > +int color_siting;
> > > >  uint32_t tagged_value_count;
> > > >  AVRational audio_edit_rate;
> > > >  int store_user_comments;
> > > > @@ -2085,6 +2086,8 @@ static int mxf_write_header(AVFormatContext *s)
> > > >  case AVCHROMA_LOC_TOP: sc->color_siting = 1; break;
> > > >  case AVCHROMA_LOC_CENTER:  sc->color_siting = 3; break;
> > > >  }
> > > > +if (mxf->color_siting >= 0)
> > > > +sc->color_siting = mxf->color_siting;
> > > >  
> > > >  mxf->timecode_base = (tbc.den + tbc.num/2) / tbc.num;
> > > >  spf = ff_mxf_get_samples_per_frame(s, tbc);
> > > > @@ -2668,7 +2671,9 @@ static int mxf_interleave(AVFormatContext *s, 
> > > > AVPacket *out, AVPacket *pkt, int
> > > >  { "smpte349m", "SMPTE 349M (1485 Mbps mappings)",\
> > > >0, AV_OPT_TYPE_CONST, {.i64 = 6}, -1, 7, 
> > > > AV_OPT_FLAG_ENCODING_PARAM, "signal_standard"},\
> > > >  { "smpte428", "SMPTE 428-1 DCDM",\
> > > > -  0, AV_OPT_TYPE_CONST, {.i64 = 7}, -1, 7, 
> > > > AV_OPT_FLAG_ENCODING_PARAM, "signal_standard"},
> > > > +  0, AV_OPT_TYPE_CONST, {.i64 = 7}, -1, 7, 
> > > > AV_OPT_FLAG_ENCODING_PARAM, "signal_standard"},\
> > > > +{ "color_siting", "Force/set Color siting",\
> > > > +  offsetof(MXFContext, color_siting), AV_OPT_TYPE_INT, {.i64 = 
> > > > -1}, -1, 7, AV_OPT_FLAG_ENCODING_PARAM, "color_siting"},\
> > > >  
> > > >  
> > > >
> > > 
> > > What an absurd patch. This should be done by generic code overriding
> > > the chroma_location field on AVFrames sent to the encoders. We don't
> > > need inconsistent private options for an inconsistent set of encoders
> > > to override generic parameters in an inconsistent way. What's even the
> > > point?  
> > 
> > The point of this change is to be able to set any color siting value.
> > MXF has some redundant values. The fields from AVFrame are not enough
> > to choose this unless we want MXF specific information in AVFrames
> > 
> > [...]
> 
> You probably want to use some specialized MXF tool then.

It should be possible to generate mxf files with just one tool not 2.
In fact this change is for someone else not me, i probably wont be
using it much.

Do you object to this patch ?
If you veto it, i will not apply it of course.

if not i will apply it with the lines reordered to avoid the \ issue
raised by paul
as FFmpeg is intended to be a universal multimedia tool and requiring
a 2nd tool is cumbersome.

Thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] configure: add support for libnpp* from cuda sdk 9

2017-08-29 Thread Timo Rothenpieler

Signed-off-by: Timo Rothenpieler 
---
 configure | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 61d8160491..172ff3fc07 100755
--- a/configure
+++ b/configure
@@ -5875,7 +5875,9 @@ enabled libmfx&& { use_pkg_config libmfx 
"mfx/mfxvideo.h" MFXInit ||
 enabled libmodplug&& require_pkg_config libmodplug 
libmodplug/modplug.h ModPlug_Load
 enabled libmp3lame&& require "libmp3lame >= 3.98.3" lame/lame.h 
lame_set_VBR_quality -lmp3lame
 enabled libmysofa && require libmysofa "mysofa.h" mysofa_load -lmysofa
-enabled libnpp&& require libnpp npp.h nppGetLibVersion -lnppi 
-lnppc
+enabled libnpp&& { check_lib libnpp npp.h nppGetLibVersion -lnppig 
-lnppicc -lnppc ||
+   check_lib libnpp npp.h nppGetLibVersion -lnppi 
-lnppc ||
+   die "ERROR: libnpp not found"; }
 enabled libopencore_amrnb && require libopencore_amrnb 
opencore-amrnb/interf_dec.h Decoder_Interface_init -lopencore-amrnb
 enabled libopencore_amrwb && require libopencore_amrwb opencore-amrwb/dec_if.h 
D_IF_init -lopencore-amrwb
 enabled libopencv && { check_header opencv2/core/core_c.h &&
-- 
2.14.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

2017-08-29 Thread Jorge Ramirez


On 08/29/2017 01:50 PM, wm4 wrote:

If you want to support direct FD/dmabuf export, adapting to
AVHWFramesContext now would probably be easier in total. Especially
because of the implied API change. But I'd wait for Mark Thompson's
comments on that before making any big changes. AFAIK he posted a
proposal patch for a DRM AVHWFramesContext too.

why not just add a FD to the AVBufferRef and let the user decide whether
to use it or not?

Because there's too much framework-y stuff in ffmpeg that expects
AVHWFramesContext. It's basically needed to do anything with it, and
avoids ad-hoc approaches the old hwaccel API was full of.


understood...so at some point I will have to use the AVHWFramesContext 
(to integrate dmabuf)...will add it to my list.

thanks

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

2017-08-29 Thread Jorge Ramirez


On 08/29/2017 01:50 PM, wm4 wrote:

static void free_v4l2buf_cb(void *opaque, uint8_t *unused)
{
  V4L2Buffer* avbuf = opaque;
  V4L2m2mContext *s = container_of(avbuf->context, V4L2m2mContext,
capture);

  atomic_fetch_sub_explicit(>refcount, 1, memory_order_acq_rel);

  if (s->reinit) {
  if (!atomic_load(>refcount))
  sem_post(>refsync);
  return;
  }

  if (avbuf->context->streamon) {
  avbuf->context->ops.enqueue(avbuf);
  return;
  }

  if (!atomic_load(>refcount))
  avpriv_v4l2m2m_end(s);
}

The only case where I can't get away without waiting for the AVBufferRef
to be released is when re-initializing the frame dimensions (ie,
resolution changes/format)_during_  streaming since I need to release
_all_  hardware buffers and queue them again.

will this be acceptable?
I have just tested these changes and works as expected.

The implementation seems rather roundabout and complex - why not use
AVBufferRef? But apart from that, yes.



I thought about using an AVBufferRef for this but really all I need are 
an atomic_uint (refcount), the atomic operations and a sem_t (refsync).

then it is pretty straight forward.

I'll post it like it is in v7 and if you still believe an AVBufferRef is 
a more maintainable solution I'll change it, is not a big deal (although 
I'll still need the sem_t).

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

2017-08-29 Thread wm4

On Tue, 29 Aug 2017 12:03:42 +0200
Jorge Ramirez  wrote:

> On 08/29/2017 10:56 AM, wm4 wrote:
> > On Mon, 28 Aug 2017 23:36:08 +0200
> > Jorge Ramirez  wrote:
> >  
> >> On 08/28/2017 09:53 PM, wm4 wrote:  
> >>> On Mon, 28 Aug 2017 21:24:26 +0200
> >>> Jorge Ramirez  wrote:
> >>> 
>  On 08/28/2017 02:16 PM, Jorge Ramirez wrote:  
> > On 08/28/2017 12:47 PM, wm4 wrote:  
> >>> I guess that instead of polling for the AVBufferRef to be 
> >>> unreferenced,
> >>> I can associate a sync (ie a sempahore) to each buffer, take it on
> >>> release and post the semaphore on the AVBufferRefs being unreferenced.
> >>> that is actually pretty clean in terms of cpu usage.  
> >> That would just freeze an API user calling avcodec_close(), when it
> >> keeps around decoded AVFrames for later use.  
> > yes I understand, but it does avoid using the CPU to poll for the
> > buffer release (an incremental improvement)
> >
> > but yes I think that the message is that even though this proposal
> > might suffice for simple video players (my tests) is not good enough
> > for other users requiring the decoded frame for post processing.
> >
> > is this a blocker to upstream or could I continue working with it
> > flagging the encoder/decoder as EXPERIMENTAL? the current situation at
> > least keeps video players happy.  
> >>> I'd say yes this is a blocker. We usually try to avoid committing
> >>> half-finished code, because it often means it will be never finished.  
> >> hi, I forgot to say earlier, thanks for all the review over the past
> >> couple of days (it has been of much help).
> >>
> >> on the half finished matter, the issue that I face is that the current
> >> code doesn't cover the use case where _all_ the processed frames have to
> >> be kept available indefinitely (this is why I thought that perhaps
> >> setting .capabilities to AV_CODEC_CAP_EXPERIMENTAL could be an option to
> >> upstream and get more exposure to other users;
> >>
> >> I do plan to continue supporting v4l2 ffmpeg integration - mmaped
> >> filters, DRM and so on...having invested this long I do want to see this
> >> through; and since I can't guaranteed that some "force majeure" wont
> >> happen I think the sooner the code I have been working on can get
> >> exposure the sooner we will start seeing contributions.
> >>
> >> Anyhow, the current code does support the typical use case of most video
> >> players so it would benefit a considerable amount of users.
> >>
> >> does it have to be an all or nothing at this point or could we flag the
> >> v4l2 m2m as experimental codecs?  
> > You could just copy the frames before returning them to the user to
> > avoid breaking refcounting.  
> 
> thinking again about this I'd rather not do that (it will impact 
> performance too much) and Hendrik gave me some pointers yesterday in 
> line with what you said as well.
> I implemented reference counting delegating the closing of _some_ 
> resources needed to keep the buffers alive.
> 
> closing the codec now doesnt wait or leave dangling buffers.
> 
> the AVBufferRef free callback looks just like this
> 
> static void free_v4l2buf_cb(void *opaque, uint8_t *unused)
> {
>  V4L2Buffer* avbuf = opaque;
>  V4L2m2mContext *s = container_of(avbuf->context, V4L2m2mContext, 
> capture);
> 
>  atomic_fetch_sub_explicit(>refcount, 1, memory_order_acq_rel);
> 
>  if (s->reinit) {
>  if (!atomic_load(>refcount))
>  sem_post(>refsync);
>  return;
>  }
> 
>  if (avbuf->context->streamon) {
>  avbuf->context->ops.enqueue(avbuf);
>  return;
>  }
> 
>  if (!atomic_load(>refcount))
>  avpriv_v4l2m2m_end(s);
> }
> 
> The only case where I can't get away without waiting for the AVBufferRef 
> to be released is when re-initializing the frame dimensions (ie, 
> resolution changes/format) _during_ streaming since I need to release 
> _all_ hardware buffers and queue them again.
> 
> will this be acceptable?
> I have just tested these changes and works as expected.

The implementation seems rather roundabout and complex - why not use
AVBufferRef? But apart from that, yes.

> >  
> >>> 
> >
>  just wondering, if the AVBufferRefs must live for ever (ie, after the
>  codecs have been closed), what do other codecs dequeuing from a limited
>  number of re-usable hardware allocated buffers do?
>  do they use the CPU allocate and copy the data from those buffers to the
>  heap?
>  
> >>> Like I wrote before: hwaccels use AVHWFramesContext, which was made
> >>> more or less for this situation. If you want FD support later (for
> >>> something like zero-copy transcoding or playback), AVHWFramesContext
> >>> will probably be mandatory anyway. But I guess it's a big change for
> >>> someone not

[FFmpeg-devel] [PATCH v2] avcodec/arm: Fix SIGBUS on ARM when compiled with binutils 2.29

2017-08-29 Thread James Cowgill

In binutils 2.29, the behavior of the ADR instruction changed so that 1 is
added to the address of a Thumb function (previously nothing was added). This
allows the loaded address to be passed to a BLX instruction and the correct
mode change will occur.

So that the behavior matches in binutils 2.29 and pre-2.29, use .eqv to
pre-calculate the function address without the automatic +1 fixup. Then use
these new symbols as the function addresses to be loaded.

Fixes ticket 6571.
Related binutils bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21458

Signed-off-by: James Cowgill 
---
v2:
 Forgot to include the "avcodec/arm" commit message prefix.

 libavcodec/arm/h264idct_neon.S | 28 
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/libavcodec/arm/h264idct_neon.S b/libavcodec/arm/h264idct_neon.S
index 4f68bdb9f5..04b1ea583b 100644
--- a/libavcodec/arm/h264idct_neon.S
+++ b/libavcodec/arm/h264idct_neon.S
@@ -20,6 +20,18 @@
 
 #include "libavutil/arm/asm.S"
 
+# In binutils 2.29, the behavior of the ADR instruction changed so that 1 is
+# added to the address of a Thumb function (previously nothing was added).
+#
+# These .eqv are used to pre-calculate the correct address with +CONFIG_THUMB 
so
+# that ADR will work with both old and new versions binutils.
+#
+# See: https://sourceware.org/bugzilla/show_bug.cgi?id=21458
+.eqv eqv_ff_h264_idct_add_neon, X(ff_h264_idct_add_neon) + CONFIG_THUMB
+.eqv eqv_ff_h264_idct_dc_add_neon,  X(ff_h264_idct_dc_add_neon) + CONFIG_THUMB
+.eqv eqv_ff_h264_idct8_add_neon,X(ff_h264_idct8_add_neon) + CONFIG_THUMB
+.eqv eqv_ff_h264_idct8_dc_add_neon, X(ff_h264_idct8_dc_add_neon) + CONFIG_THUMB
+
 function ff_h264_idct_add_neon, export=1
 vld1.64 {d0-d3},  [r1,:128]
 vmov.i16q15, #0
@@ -113,8 +125,8 @@ function ff_h264_idct_add16_neon, export=1
 movne   lr,  #0
 cmp lr,  #0
 ite ne
-adrne   lr,  X(ff_h264_idct_dc_add_neon) + CONFIG_THUMB
-adreq   lr,  X(ff_h264_idct_add_neon)+ CONFIG_THUMB
+adrne   lr,  eqv_ff_h264_idct_dc_add_neon
+adreq   lr,  eqv_ff_h264_idct_add_neon
 blx lr
 2:  subsip,  ip,  #1
 add r1,  r1,  #32
@@ -138,8 +150,8 @@ function ff_h264_idct_add16intra_neon, export=1
 cmp r8,  #0
 ldrsh   r8,  [r1]
 iteet   ne
-adrne   lr,  X(ff_h264_idct_add_neon)+ CONFIG_THUMB
-adreq   lr,  X(ff_h264_idct_dc_add_neon) + CONFIG_THUMB
+adrne   lr,  eqv_ff_h264_idct_add_neon
+adreq   lr,  eqv_ff_h264_idct_dc_add_neon
 cmpeq   r8,  #0
 blxne   lr
 subsip,  ip,  #1
@@ -166,8 +178,8 @@ function ff_h264_idct_add8_neon, export=1
 cmp r8,  #0
 ldrsh   r8,  [r1]
 iteet   ne
-adrne   lr,  X(ff_h264_idct_add_neon)+ CONFIG_THUMB
-adreq   lr,  X(ff_h264_idct_dc_add_neon) + CONFIG_THUMB
+adrne   lr,  eqv_ff_h264_idct_add_neon
+adreq   lr,  eqv_ff_h264_idct_dc_add_neon
 cmpeq   r8,  #0
 blxne   lr
 add r12, r12, #1
@@ -388,8 +400,8 @@ function ff_h264_idct8_add4_neon, export=1
 movne   lr,  #0
 cmp lr,  #0
 ite ne
-adrne   lr,  X(ff_h264_idct8_dc_add_neon) + CONFIG_THUMB
-adreq   lr,  X(ff_h264_idct8_add_neon)+ CONFIG_THUMB
+adrne   lr,  eqv_ff_h264_idct8_dc_add_neon
+adreq   lr,  eqv_ff_h264_idct8_add_neon
 blx lr
 2:  subsr12, r12, #4
 add r1,  r1,  #128
-- 
2.14.1


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/dv : read dv audio as BE

2017-08-29 Thread Carl Eugen Hoyos

2017-08-29 11:31 GMT+02:00 Александр Слободенюк
:
> sending patch with bumped micro version.

Your patch breaks fate, this has to be fixed in the same commit.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

2017-08-29 Thread Jorge Ramirez


On 08/29/2017 10:56 AM, wm4 wrote:

On Mon, 28 Aug 2017 23:36:08 +0200
Jorge Ramirez  wrote:


On 08/28/2017 09:53 PM, wm4 wrote:

On Mon, 28 Aug 2017 21:24:26 +0200
Jorge Ramirez  wrote:
  

On 08/28/2017 02:16 PM, Jorge Ramirez wrote:

On 08/28/2017 12:47 PM, wm4 wrote:

I guess that instead of polling for the AVBufferRef to be unreferenced,
I can associate a sync (ie a sempahore) to each buffer, take it on
release and post the semaphore on the AVBufferRefs being unreferenced.
that is actually pretty clean in terms of cpu usage.

That would just freeze an API user calling avcodec_close(), when it
keeps around decoded AVFrames for later use.

yes I understand, but it does avoid using the CPU to poll for the
buffer release (an incremental improvement)

but yes I think that the message is that even though this proposal
might suffice for simple video players (my tests) is not good enough
for other users requiring the decoded frame for post processing.

is this a blocker to upstream or could I continue working with it
flagging the encoder/decoder as EXPERIMENTAL? the current situation at
least keeps video players happy.

I'd say yes this is a blocker. We usually try to avoid committing
half-finished code, because it often means it will be never finished.

hi, I forgot to say earlier, thanks for all the review over the past
couple of days (it has been of much help).

on the half finished matter, the issue that I face is that the current
code doesn't cover the use case where _all_ the processed frames have to
be kept available indefinitely (this is why I thought that perhaps
setting .capabilities to AV_CODEC_CAP_EXPERIMENTAL could be an option to
upstream and get more exposure to other users;

I do plan to continue supporting v4l2 ffmpeg integration - mmaped
filters, DRM and so on...having invested this long I do want to see this
through; and since I can't guaranteed that some "force majeure" wont
happen I think the sooner the code I have been working on can get
exposure the sooner we will start seeing contributions.

Anyhow, the current code does support the typical use case of most video
players so it would benefit a considerable amount of users.

does it have to be an all or nothing at this point or could we flag the
v4l2 m2m as experimental codecs?

You could just copy the frames before returning them to the user to
avoid breaking refcounting.


thinking again about this I'd rather not do that (it will impact 
performance too much) and Hendrik gave me some pointers yesterday in 
line with what you said as well.
I implemented reference counting delegating the closing of _some_ 
resources needed to keep the buffers alive.


closing the codec now doesnt wait or leave dangling buffers.

the AVBufferRef free callback looks just like this

static void free_v4l2buf_cb(void *opaque, uint8_t *unused)
{
V4L2Buffer* avbuf = opaque;
V4L2m2mContext *s = container_of(avbuf->context, V4L2m2mContext, 
capture);


atomic_fetch_sub_explicit(>refcount, 1, memory_order_acq_rel);

if (s->reinit) {
if (!atomic_load(>refcount))
sem_post(>refsync);
return;
}

if (avbuf->context->streamon) {
avbuf->context->ops.enqueue(avbuf);
return;
}

if (!atomic_load(>refcount))
avpriv_v4l2m2m_end(s);
}

The only case where I can't get away without waiting for the AVBufferRef 
to be released is when re-initializing the frame dimensions (ie, 
resolution changes/format) _during_ streaming since I need to release 
_all_ hardware buffers and queue them again.


will this be acceptable?
I have just tested these changes and works as expected.



  
 

just wondering, if the AVBufferRefs must live for ever (ie, after the
codecs have been closed), what do other codecs dequeuing from a limited
number of re-usable hardware allocated buffers do?
do they use the CPU allocate and copy the data from those buffers to the
heap?
  

Like I wrote before: hwaccels use AVHWFramesContext, which was made
more or less for this situation. If you want FD support later (for
something like zero-copy transcoding or playback), AVHWFramesContext
will probably be mandatory anyway. But I guess it's a big change for
someone not familiar with the codebase.

Yes I had a look and it seems not an easy change to integrate.

Still I'd like to make sure we are talking about the same requirement
because if AVHWFramesContext works around the issue [1] , I can probably
do the same with a few more lines of code (including the FD support for
v4l2 which is pretty straight forward)

[1]  When:
a) there is a limited number of buffers allocated by the hardware and
b) these buffers are mapped to the process address space and
c) the application can choose to keep _all_ decoded buffers for post
processing,

then there is no other option than copying each of the processed buffers
to newly allocated areas in the heap (there can be no magic on

Re: [FFmpeg-devel] [PATCH 1/3] avformat/mxfenc: Allow overriding numerical color_siting value.

2017-08-29 Thread wm4

On Tue, 29 Aug 2017 11:59:05 +0200
Michael Niedermayer  wrote:

> On Tue, Aug 29, 2017 at 11:02:32AM +0200, wm4 wrote:
> > On Tue, 29 Aug 2017 02:13:19 +0200
> > Michael Niedermayer  wrote:
> >   
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavformat/mxfenc.c | 7 ++-
> > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > > index 12fc9abbc6..ccfa0d6341 100644
> > > --- a/libavformat/mxfenc.c
> > > +++ b/libavformat/mxfenc.c
> > > @@ -322,6 +322,7 @@ typedef struct MXFContext {
> > >  uint8_t umid[16];///< unique material identifier
> > >  int channel_count;
> > >  int signal_standard;
> > > +int color_siting;
> > >  uint32_t tagged_value_count;
> > >  AVRational audio_edit_rate;
> > >  int store_user_comments;
> > > @@ -2085,6 +2086,8 @@ static int mxf_write_header(AVFormatContext *s)
> > >  case AVCHROMA_LOC_TOP: sc->color_siting = 1; break;
> > >  case AVCHROMA_LOC_CENTER:  sc->color_siting = 3; break;
> > >  }
> > > +if (mxf->color_siting >= 0)
> > > +sc->color_siting = mxf->color_siting;
> > >  
> > >  mxf->timecode_base = (tbc.den + tbc.num/2) / tbc.num;
> > >  spf = ff_mxf_get_samples_per_frame(s, tbc);
> > > @@ -2668,7 +2671,9 @@ static int mxf_interleave(AVFormatContext *s, 
> > > AVPacket *out, AVPacket *pkt, int
> > >  { "smpte349m", "SMPTE 349M (1485 Mbps mappings)",\
> > >0, AV_OPT_TYPE_CONST, {.i64 = 6}, -1, 7, 
> > > AV_OPT_FLAG_ENCODING_PARAM, "signal_standard"},\
> > >  { "smpte428", "SMPTE 428-1 DCDM",\
> > > -  0, AV_OPT_TYPE_CONST, {.i64 = 7}, -1, 7, 
> > > AV_OPT_FLAG_ENCODING_PARAM, "signal_standard"},
> > > +  0, AV_OPT_TYPE_CONST, {.i64 = 7}, -1, 7, 
> > > AV_OPT_FLAG_ENCODING_PARAM, "signal_standard"},\
> > > +{ "color_siting", "Force/set Color siting",\
> > > +  offsetof(MXFContext, color_siting), AV_OPT_TYPE_INT, {.i64 = -1}, 
> > > -1, 7, AV_OPT_FLAG_ENCODING_PARAM, "color_siting"},\
> > >  
> > >  
> > >
> > 
> > What an absurd patch. This should be done by generic code overriding
> > the chroma_location field on AVFrames sent to the encoders. We don't
> > need inconsistent private options for an inconsistent set of encoders
> > to override generic parameters in an inconsistent way. What's even the
> > point?  
> 
> The point of this change is to be able to set any color siting value.
> MXF has some redundant values. The fields from AVFrame are not enough
> to choose this unless we want MXF specific information in AVFrames
> 
> [...]

You probably want to use some specialized MXF tool then.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avformat/mxfenc: Allow overriding numerical color_siting value.

2017-08-29 Thread Michael Niedermayer

On Tue, Aug 29, 2017 at 11:02:32AM +0200, wm4 wrote:
> On Tue, 29 Aug 2017 02:13:19 +0200
> Michael Niedermayer  wrote:
> 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/mxfenc.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > index 12fc9abbc6..ccfa0d6341 100644
> > --- a/libavformat/mxfenc.c
> > +++ b/libavformat/mxfenc.c
> > @@ -322,6 +322,7 @@ typedef struct MXFContext {
> >  uint8_t umid[16];///< unique material identifier
> >  int channel_count;
> >  int signal_standard;
> > +int color_siting;
> >  uint32_t tagged_value_count;
> >  AVRational audio_edit_rate;
> >  int store_user_comments;
> > @@ -2085,6 +2086,8 @@ static int mxf_write_header(AVFormatContext *s)
> >  case AVCHROMA_LOC_TOP: sc->color_siting = 1; break;
> >  case AVCHROMA_LOC_CENTER:  sc->color_siting = 3; break;
> >  }
> > +if (mxf->color_siting >= 0)
> > +sc->color_siting = mxf->color_siting;
> >  
> >  mxf->timecode_base = (tbc.den + tbc.num/2) / tbc.num;
> >  spf = ff_mxf_get_samples_per_frame(s, tbc);
> > @@ -2668,7 +2671,9 @@ static int mxf_interleave(AVFormatContext *s, 
> > AVPacket *out, AVPacket *pkt, int
> >  { "smpte349m", "SMPTE 349M (1485 Mbps mappings)",\
> >0, AV_OPT_TYPE_CONST, {.i64 = 6}, -1, 7, AV_OPT_FLAG_ENCODING_PARAM, 
> > "signal_standard"},\
> >  { "smpte428", "SMPTE 428-1 DCDM",\
> > -  0, AV_OPT_TYPE_CONST, {.i64 = 7}, -1, 7, AV_OPT_FLAG_ENCODING_PARAM, 
> > "signal_standard"},
> > +  0, AV_OPT_TYPE_CONST, {.i64 = 7}, -1, 7, AV_OPT_FLAG_ENCODING_PARAM, 
> > "signal_standard"},\
> > +{ "color_siting", "Force/set Color siting",\
> > +  offsetof(MXFContext, color_siting), AV_OPT_TYPE_INT, {.i64 = -1}, 
> > -1, 7, AV_OPT_FLAG_ENCODING_PARAM, "color_siting"},\
> >  
> >  
> >  
> 
> What an absurd patch. This should be done by generic code overriding
> the chroma_location field on AVFrames sent to the encoders. We don't
> need inconsistent private options for an inconsistent set of encoders
> to override generic parameters in an inconsistent way. What's even the
> point?

The point of this change is to be able to set any color siting value.
MXF has some redundant values. The fields from AVFrame are not enough
to choose this unless we want MXF specific information in AVFrames

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/dashdec: add dash demuxer base version

2017-08-29 Thread Steven Liu

ffmpeg need a dash demuxer for demux the dash formats base on
https://github.com/samsamsam-iptvplayer/exteplayer3/blob/master/tmp/ffmpeg/patches/3.2.2/01_add_dash_demux.patch

TODO:
1. support multi bitrate dash

v2 fixed:
1. from autodetect to disabled
2. from camelCase code style to ffmpeg code style
3. from RepType to AVMediaType
4. fix variable typo
5. change time value from uint32_t to uint64_t
6. removed be used once API
7. change 'time(NULL)`, except it is not 2038-safe.' to av_gettime and av_timegm
8. merge complex free operation to free_fragment
9. use API from snprintf to av_asprintf

v3 fixed:
1. fix typo from --enabled-xml2 to --enable-xml2

v4 fixed:
1. from --enable-xml2 to --enable-libxml2
2. move system includes to top
3. remove nouse includes
4. rename enum name
5. add a trailing comma for the last entry enum
6. fix comment typo
7. add const to DASHContext class front
8. check sscanf if return arguments and give warning message when error
9. check validity before free seg->url and seg
10. check if the val is null, before use atoll

v5 fixed:
1. fix typo from mainifest to manifest

v6 fixed:
1. from realloc to av_realloc
2. from free to av_free

v7 fixed:
1. remove the -lxml2 from configure when require_pkg_config

v8 fixed:
1. fix replace filename template by av_asprintf secure problem

v9 modified:
1. make manifest parser clearly

v10 fixed:
1. fix function API name code style
2. remove redundant strreplace call
3. remove redundant memory operation and check return value from 
get_content_url()
4. add space between ) and {
5. remove no need to log the value for print

v11 fixed:
1. from atoll to strtoll
Suggested-by: Michael Niedermayer 

v12 fixed:
1. remove strreplace and instead by av_strreplace
Suggested-by: Nicolas George 

v13 fixed:
1. fix bug: cannot play:
http://dash.edgesuite.net/akamai/bbb_30fps/bbb_30fps.mpd
Reported-by: Andy Furniss 

v14 fixed:
1. fix bug: TLS connection was non-properly terminated
2. fix bug: No trailing CRLF found in HTTP header
Reported-by: Andy Furniss 

v15 fixed:
1. play youtube link: ffmpeg -i $(youtube-dl -J 
"https://www.youtube.com/watch?v=XmL19DOP_Ls; | jq -r 
".requested_formats[0].manifest_url")
2. code refine for timeline living stream
Reported-by: Ricardo Constantino 

v16 fixed:
1. remove the snprintf and instead by get_segment_filename make safety
2. remove unnecessary loops
3. updated xmlStrcmp and xmlFree to av_* functions
4. merge code repeat into one function
5. add memory alloc faild check
6. update update_init_section and open_url
7. output safety error message when filename template not safe
Suggested-by : wm4 

Signed-off-by: Steven Liu 
Signed-off-by: samsamsam 
---
 configure|4 +
 libavformat/Makefile |1 +
 libavformat/allformats.c |2 +-
 libavformat/dashdec.c| 2015 ++
 4 files changed, 2021 insertions(+), 1 deletion(-)
 create mode 100644 libavformat/dashdec.c

diff --git a/configure b/configure
index 61d8160..c03ff02 100755
--- a/configure
+++ b/configure
@@ -272,6 +272,7 @@ External library support:
   --enable-libxcb-shapeenable X11 grabbing shape rendering [autodetect]
   --enable-libxvid enable Xvid encoding via xvidcore,
native MPEG-4/Xvid encoder exists [no]
+  --enable-libxml2 enable XML parsing using the C library libxml2 [no]
   --enable-libzimg enable z.lib, needed for zscale filter [no]
   --enable-libzmq  enable message passing via libzmq [no]
   --enable-libzvbi enable teletext support via libzvbi [no]
@@ -1578,6 +1579,7 @@ EXTERNAL_LIBRARY_LIST="
 libvpx
 libwavpack
 libwebp
+libxml2
 libzimg
 libzmq
 libzvbi
@@ -2939,6 +2941,7 @@ avi_muxer_select="riffenc"
 caf_demuxer_select="iso_media riffdec"
 caf_muxer_select="iso_media"
 dash_muxer_select="mp4_muxer"
+dash_demuxer_deps="libxml2"
 dirac_demuxer_select="dirac_parser"
 dts_demuxer_select="dca_parser"
 dtshd_demuxer_select="dca_parser"
@@ -6005,6 +6008,7 @@ enabled openssl   && { use_pkg_config openssl 
openssl/ssl.h OPENSSL_init
check_lib openssl openssl/ssl.h 
SSL_library_init -lssl -lcrypto -lws2_32 -lgdi32 ||
die "ERROR: openssl not found"; }
 enabled qtkit_indev  && { check_header_objcc QTKit/QTKit.h || disable 
qtkit_indev; }
+enabled libxml2  && require_pkg_config libxml-2.0 
libxml2/libxml/xmlversion.h xmlCheckVersion
 
 if enabled gcrypt; then
 GCRYPT_CONFIG="${cross_prefix}libgcrypt-config"
diff --git a/libavformat/Makefile b/libavformat/Makefile
index f2b465c..3d47874 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -133,6 +133,7 @@ OBJS-$(CONFIG_CRC_MUXER) += crcenc.o

Re: [FFmpeg-devel] [PATCH 1/3] avformat/mxfenc: Allow overriding numerical color_siting value.

2017-08-29 Thread Michael Niedermayer

On Tue, Aug 29, 2017 at 11:05:25AM +0200, Paul B Mahol wrote:
> On 8/29/17, Michael Niedermayer  wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/mxfenc.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > index 12fc9abbc6..ccfa0d6341 100644
> > --- a/libavformat/mxfenc.c
> > +++ b/libavformat/mxfenc.c
> > @@ -322,6 +322,7 @@ typedef struct MXFContext {
> >  uint8_t umid[16];///< unique material identifier
> >  int channel_count;
> >  int signal_standard;
> > +int color_siting;
> >  uint32_t tagged_value_count;
> >  AVRational audio_edit_rate;
> >  int store_user_comments;
> > @@ -2085,6 +2086,8 @@ static int mxf_write_header(AVFormatContext *s)
> >  case AVCHROMA_LOC_TOP: sc->color_siting = 1; break;
> >  case AVCHROMA_LOC_CENTER:  sc->color_siting = 3; break;
> >  }
> > +if (mxf->color_siting >= 0)
> > +sc->color_siting = mxf->color_siting;
> >
> >  mxf->timecode_base = (tbc.den + tbc.num/2) / tbc.num;
> >  spf = ff_mxf_get_samples_per_frame(s, tbc);
> > @@ -2668,7 +2671,9 @@ static int mxf_interleave(AVFormatContext *s, AVPacket
> > *out, AVPacket *pkt, int
> >  { "smpte349m", "SMPTE 349M (1485 Mbps mappings)",\
> >0, AV_OPT_TYPE_CONST, {.i64 = 6}, -1, 7, AV_OPT_FLAG_ENCODING_PARAM,
> > "signal_standard"},\
> >  { "smpte428", "SMPTE 428-1 DCDM",\
> > -  0, AV_OPT_TYPE_CONST, {.i64 = 7}, -1, 7, AV_OPT_FLAG_ENCODING_PARAM,
> > "signal_standard"},
> > +  0, AV_OPT_TYPE_CONST, {.i64 = 7}, -1, 7, AV_OPT_FLAG_ENCODING_PARAM,
> > "signal_standard"},\
> 
> Above change is unneeded.

The multiline macro needs the added \
if more is added at the end
I could add the new option at the top if you prefer ?

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v16] avformat/dashdec: add dash demuxer base version

2017-08-29 Thread Steven Liu

ffmpeg need a dash demuxer for demux the dash formats base on
https://github.com/samsamsam-iptvplayer/exteplayer3/blob/master/tmp/ffmpeg/patches/3.2.2/01_add_dash_demux.patch

TODO:
1. support multi bitrate dash

v2 fixed:
1. from autodetect to disabled
2. from camelCase code style to ffmpeg code style
3. from RepType to AVMediaType
4. fix variable typo
5. change time value from uint32_t to uint64_t
6. removed be used once API
7. change 'time(NULL)`, except it is not 2038-safe.' to av_gettime and av_timegm
8. merge complex free operation to free_fragment
9. use API from snprintf to av_asprintf

v3 fixed:
1. fix typo from --enabled-xml2 to --enable-xml2

v4 fixed:
1. from --enable-xml2 to --enable-libxml2
2. move system includes to top
3. remove nouse includes
4. rename enum name
5. add a trailing comma for the last entry enum
6. fix comment typo
7. add const to DASHContext class front
8. check sscanf if return arguments and give warning message when error
9. check validity before free seg->url and seg
10. check if the val is null, before use atoll

v5 fixed:
1. fix typo from mainifest to manifest

v6 fixed:
1. from realloc to av_realloc
2. from free to av_free

v7 fixed:
1. remove the -lxml2 from configure when require_pkg_config

v8 fixed:
1. fix replace filename template by av_asprintf secure problem

v9 modified:
1. make manifest parser clearly

v10 fixed:
1. fix function API name code style
2. remove redundant strreplace call
3. remove redundant memory operation and check return value from 
get_content_url()
4. add space between ) and {
5. remove no need to log the value for print

v11 fixed:
1. from atoll to strtoll
Suggested-by: Michael Niedermayer 

v12 fixed:
1. remove strreplace and instead by av_strreplace
Suggested-by: Nicolas George 

v13 fixed:
1. fix bug: cannot play:
http://dash.edgesuite.net/akamai/bbb_30fps/bbb_30fps.mpd
Reported-by: Andy Furniss 

v14 fixed:
1. fix bug: TLS connection was non-properly terminated
2. fix bug: No trailing CRLF found in HTTP header
Reported-by: Andy Furniss 

v15 fixed:
1. play youtube link: ffmpeg -i $(youtube-dl -J 
"https://www.youtube.com/watch?v=XmL19DOP_Ls; | jq -r 
".requested_formats[0].manifest_url")
2. code refine for timeline living stream
Reported-by: Ricardo Constantino 

v16 fixed:
1. remove the snprintf and instead by get_segment_filename make safety
2. remove unnecessary loops
3. updated xmlStrcmp and xmlFree to av_* functions
4. merge code repeat into one function
5. add memory alloc faild check
6. update update_init_section and open_url
Suggested-by : wm4 

Signed-off-by: Steven Liu 
Signed-off-by: samsamsam 
---
 configure|4 +
 libavformat/Makefile |1 +
 libavformat/allformats.c |2 +-
 libavformat/dashdec.c| 2011 ++
 4 files changed, 2017 insertions(+), 1 deletion(-)
 create mode 100644 libavformat/dashdec.c

diff --git a/configure b/configure
index 61d8160..c03ff02 100755
--- a/configure
+++ b/configure
@@ -272,6 +272,7 @@ External library support:
   --enable-libxcb-shapeenable X11 grabbing shape rendering [autodetect]
   --enable-libxvid enable Xvid encoding via xvidcore,
native MPEG-4/Xvid encoder exists [no]
+  --enable-libxml2 enable XML parsing using the C library libxml2 [no]
   --enable-libzimg enable z.lib, needed for zscale filter [no]
   --enable-libzmq  enable message passing via libzmq [no]
   --enable-libzvbi enable teletext support via libzvbi [no]
@@ -1578,6 +1579,7 @@ EXTERNAL_LIBRARY_LIST="
 libvpx
 libwavpack
 libwebp
+libxml2
 libzimg
 libzmq
 libzvbi
@@ -2939,6 +2941,7 @@ avi_muxer_select="riffenc"
 caf_demuxer_select="iso_media riffdec"
 caf_muxer_select="iso_media"
 dash_muxer_select="mp4_muxer"
+dash_demuxer_deps="libxml2"
 dirac_demuxer_select="dirac_parser"
 dts_demuxer_select="dca_parser"
 dtshd_demuxer_select="dca_parser"
@@ -6005,6 +6008,7 @@ enabled openssl   && { use_pkg_config openssl 
openssl/ssl.h OPENSSL_init
check_lib openssl openssl/ssl.h 
SSL_library_init -lssl -lcrypto -lws2_32 -lgdi32 ||
die "ERROR: openssl not found"; }
 enabled qtkit_indev  && { check_header_objcc QTKit/QTKit.h || disable 
qtkit_indev; }
+enabled libxml2  && require_pkg_config libxml-2.0 
libxml2/libxml/xmlversion.h xmlCheckVersion
 
 if enabled gcrypt; then
 GCRYPT_CONFIG="${cross_prefix}libgcrypt-config"
diff --git a/libavformat/Makefile b/libavformat/Makefile
index f2b465c..3d47874 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -133,6 +133,7 @@ OBJS-$(CONFIG_CRC_MUXER) += crcenc.o
 OBJS-$(CONFIG_DATA_DEMUXER)  += rawdec.o
 OBJS-$(CONFIG_DATA_MUXER)

Re: [FFmpeg-devel] [PATCH] libavformat/dv : read dv audio as BE

2017-08-29 Thread Александр Слободенюк

sending patch with bumped micro version.

> 2017-08-28 18:42 GMT+02:00 Carl Eugen Hoyos :
>> 2017-08-28 18:22 GMT+02:00 Александр Слободенюк
>> :
>>> Fixing the FIXME issue, where BE audio inside the dv codec reads as LE
>>> after swapping it's bytes. It's was not very clear, because if we read
>>> it on BE machine we'll swap it twice.
>>
>>> -static int dv_extract_audio(const uint8_t *frame, uint8_t **ppcm,
>>> +static int dv_extract_audio(const uint8_t *frame, uint16_t **ppcm,
>>
>> Is this change necessary?

> It is necessary, the cast should be unnecessary though.

> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



-- 
С уважением,
 Александр  mailto:alexander.sloboden...@bramtech.ru

0001-libavformat-dv-read-dv-audio-as-BE.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avformat/mxfenc: Allow overriding numerical color_siting value.

2017-08-29 Thread Paul B Mahol

On 8/29/17, Michael Niedermayer  wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mxfenc.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 12fc9abbc6..ccfa0d6341 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -322,6 +322,7 @@ typedef struct MXFContext {
>  uint8_t umid[16];///< unique material identifier
>  int channel_count;
>  int signal_standard;
> +int color_siting;
>  uint32_t tagged_value_count;
>  AVRational audio_edit_rate;
>  int store_user_comments;
> @@ -2085,6 +2086,8 @@ static int mxf_write_header(AVFormatContext *s)
>  case AVCHROMA_LOC_TOP: sc->color_siting = 1; break;
>  case AVCHROMA_LOC_CENTER:  sc->color_siting = 3; break;
>  }
> +if (mxf->color_siting >= 0)
> +sc->color_siting = mxf->color_siting;
>
>  mxf->timecode_base = (tbc.den + tbc.num/2) / tbc.num;
>  spf = ff_mxf_get_samples_per_frame(s, tbc);
> @@ -2668,7 +2671,9 @@ static int mxf_interleave(AVFormatContext *s, AVPacket
> *out, AVPacket *pkt, int
>  { "smpte349m", "SMPTE 349M (1485 Mbps mappings)",\
>0, AV_OPT_TYPE_CONST, {.i64 = 6}, -1, 7, AV_OPT_FLAG_ENCODING_PARAM,
> "signal_standard"},\
>  { "smpte428", "SMPTE 428-1 DCDM",\
> -  0, AV_OPT_TYPE_CONST, {.i64 = 7}, -1, 7, AV_OPT_FLAG_ENCODING_PARAM,
> "signal_standard"},
> +  0, AV_OPT_TYPE_CONST, {.i64 = 7}, -1, 7, AV_OPT_FLAG_ENCODING_PARAM,
> "signal_standard"},\

Above change is unneeded.

> +{ "color_siting", "Force/set Color siting",\
> +  offsetof(MXFContext, color_siting), AV_OPT_TYPE_INT, {.i64 = -1}, -1,
> 7, AV_OPT_FLAG_ENCODING_PARAM, "color_siting"},\
>
>
>
> --
> 2.14.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avformat/mxfenc: Allow overriding numerical color_siting value.

2017-08-29 Thread wm4

On Tue, 29 Aug 2017 02:13:19 +0200
Michael Niedermayer  wrote:

> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mxfenc.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 12fc9abbc6..ccfa0d6341 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -322,6 +322,7 @@ typedef struct MXFContext {
>  uint8_t umid[16];///< unique material identifier
>  int channel_count;
>  int signal_standard;
> +int color_siting;
>  uint32_t tagged_value_count;
>  AVRational audio_edit_rate;
>  int store_user_comments;
> @@ -2085,6 +2086,8 @@ static int mxf_write_header(AVFormatContext *s)
>  case AVCHROMA_LOC_TOP: sc->color_siting = 1; break;
>  case AVCHROMA_LOC_CENTER:  sc->color_siting = 3; break;
>  }
> +if (mxf->color_siting >= 0)
> +sc->color_siting = mxf->color_siting;
>  
>  mxf->timecode_base = (tbc.den + tbc.num/2) / tbc.num;
>  spf = ff_mxf_get_samples_per_frame(s, tbc);
> @@ -2668,7 +2671,9 @@ static int mxf_interleave(AVFormatContext *s, AVPacket 
> *out, AVPacket *pkt, int
>  { "smpte349m", "SMPTE 349M (1485 Mbps mappings)",\
>0, AV_OPT_TYPE_CONST, {.i64 = 6}, -1, 7, AV_OPT_FLAG_ENCODING_PARAM, 
> "signal_standard"},\
>  { "smpte428", "SMPTE 428-1 DCDM",\
> -  0, AV_OPT_TYPE_CONST, {.i64 = 7}, -1, 7, AV_OPT_FLAG_ENCODING_PARAM, 
> "signal_standard"},
> +  0, AV_OPT_TYPE_CONST, {.i64 = 7}, -1, 7, AV_OPT_FLAG_ENCODING_PARAM, 
> "signal_standard"},\
> +{ "color_siting", "Force/set Color siting",\
> +  offsetof(MXFContext, color_siting), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 
> 7, AV_OPT_FLAG_ENCODING_PARAM, "color_siting"},\
>  
>  
>  

What an absurd patch. This should be done by generic code overriding
the chroma_location field on AVFrames sent to the encoders. We don't
need inconsistent private options for an inconsistent set of encoders
to override generic parameters in an inconsistent way. What's even the
point?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hls: Fix DoS due to infinite loop

2017-08-29 Thread wm4

On Tue, 29 Aug 2017 03:07:45 +0200
Michael Niedermayer  wrote:

> On Mon, Aug 28, 2017 at 11:21:39AM +0200, wm4 wrote:
> > On Sun, 27 Aug 2017 19:16:03 +0200
> > Michael Niedermayer  wrote:
> >   
> > > On Sat, Aug 26, 2017 at 01:26:58AM +0200, Michael Niedermayer wrote:  
> > > > Fixes: loop.m3u
> > > > 
> > > > The default max iteration count of 1000 is arbitrary and ideas for a 
> > > > better solution are welcome
> > > > 
> > > > Found-by: Xiaohei and Wangchu from Alibaba Security Team
> > > > Signed-off-by: Michael Niedermayer 
> > > > ---
> > > >  doc/demuxers.texi | 18 ++
> > > >  libavformat/hls.c |  7 +++
> > > >  2 files changed, 25 insertions(+)
> > > 
> > > applied
> > > 
> > > [...]  
> > 
> > I rejected this approach, but I guess patch reviews are ignored anyway.  
> 
> I explicitly asked if you veto this patch, you did not veto it.
> It is extreemly inpolite, to ignore an explicit question about
> you objecting and afterwards claim your rejection was ignored.

I don't think a patch comment needs to be honored only if it was done
as an explicit veto. I didn't understand it this way either.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

2017-08-29 Thread wm4

On Mon, 28 Aug 2017 23:36:08 +0200
Jorge Ramirez  wrote:

> On 08/28/2017 09:53 PM, wm4 wrote:
> > On Mon, 28 Aug 2017 21:24:26 +0200
> > Jorge Ramirez  wrote:
> >  
> >> On 08/28/2017 02:16 PM, Jorge Ramirez wrote:  
> >>> On 08/28/2017 12:47 PM, wm4 wrote:  
> > I guess that instead of polling for the AVBufferRef to be unreferenced,
> > I can associate a sync (ie a sempahore) to each buffer, take it on
> > release and post the semaphore on the AVBufferRefs being unreferenced.
> > that is actually pretty clean in terms of cpu usage.  
>  That would just freeze an API user calling avcodec_close(), when it
>  keeps around decoded AVFrames for later use.  
> >>> yes I understand, but it does avoid using the CPU to poll for the
> >>> buffer release (an incremental improvement)
> >>>
> >>> but yes I think that the message is that even though this proposal
> >>> might suffice for simple video players (my tests) is not good enough
> >>> for other users requiring the decoded frame for post processing.
> >>>
> >>> is this a blocker to upstream or could I continue working with it
> >>> flagging the encoder/decoder as EXPERIMENTAL? the current situation at
> >>> least keeps video players happy.  
> > I'd say yes this is a blocker. We usually try to avoid committing
> > half-finished code, because it often means it will be never finished.  
> 
> hi, I forgot to say earlier, thanks for all the review over the past 
> couple of days (it has been of much help).
> 
> on the half finished matter, the issue that I face is that the current 
> code doesn't cover the use case where _all_ the processed frames have to 
> be kept available indefinitely (this is why I thought that perhaps 
> setting .capabilities to AV_CODEC_CAP_EXPERIMENTAL could be an option to 
> upstream and get more exposure to other users;
> 
> I do plan to continue supporting v4l2 ffmpeg integration - mmaped 
> filters, DRM and so on...having invested this long I do want to see this 
> through; and since I can't guaranteed that some "force majeure" wont 
> happen I think the sooner the code I have been working on can get 
> exposure the sooner we will start seeing contributions.
> 
> Anyhow, the current code does support the typical use case of most video 
> players so it would benefit a considerable amount of users.
> 
> does it have to be an all or nothing at this point or could we flag the 
> v4l2 m2m as experimental codecs?

You could just copy the frames before returning them to the user to
avoid breaking refcounting.

> >  
> >>> 
> >> just wondering, if the AVBufferRefs must live for ever (ie, after the
> >> codecs have been closed), what do other codecs dequeuing from a limited
> >> number of re-usable hardware allocated buffers do?
> >> do they use the CPU allocate and copy the data from those buffers to the
> >> heap?
> >>  
> > Like I wrote before: hwaccels use AVHWFramesContext, which was made
> > more or less for this situation. If you want FD support later (for
> > something like zero-copy transcoding or playback), AVHWFramesContext
> > will probably be mandatory anyway. But I guess it's a big change for
> > someone not familiar with the codebase.  
> 
> Yes I had a look and it seems not an easy change to integrate.
> 
> Still I'd like to make sure we are talking about the same requirement 
> because if AVHWFramesContext works around the issue [1] , I can probably 
> do the same with a few more lines of code (including the FD support for 
> v4l2 which is pretty straight forward)
> 
> [1]  When:
> a) there is a limited number of buffers allocated by the hardware and
> b) these buffers are mapped to the process address space and
> c) the application can choose to keep _all_ decoded buffers for post 
> processing,
> 
> then there is no other option than copying each of the processed buffers 
> to newly allocated areas in the heap (there can be no magic on this 
> since the hardware buffers are always limited and have to be reused).

The semantics of AVHWFramesContext are such that if the user keeps
enough AVFrames references to exhaust the frame pool, trying to continue
decoding will result in an error. The whole point is to make the
limited and fixed buffer allocation visible to the API user.

We are also thinking about adding an API that lets the decoder
communicate to the user how many references are required (inherently,
and due to codec reference frame requirements).

> I had a look a AVHWFRamesContext and it seems to me  that under the 
> transfer frames semantics it performs some sort of memcpy in/out 
> (something I could do on every capture buffer dequeue if this is the 
> requirement). I could be wrong and therefore would appreciate the 
> clarification if the previous comment is incorrect.

The AVFrames in the context pool would be opaque frames (using FDs),
and there are entry points for temporary and permanent mapping of
opaque frames, which

Re: [FFmpeg-devel] [PATCH] compat/cuda/ptx2c: strip CR from each line

2017-08-29 Thread Timo Rothenpieler


Am 29.08.2017 um 02:46 schrieb Ricardo Constantino:

Windows nvcc + cl.exe produce a .ctx file with CR+LF newlines which
need to be stripped to work with gcc.
---
  compat/cuda/ptx2c.sh | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/compat/cuda/ptx2c.sh b/compat/cuda/ptx2c.sh
index 1f37023290..44b08b6ea2 100755
--- a/compat/cuda/ptx2c.sh
+++ b/compat/cuda/ptx2c.sh
@@ -29,7 +29,7 @@ NAME="$(basename "$IN" | sed 's/\..*//')"
  printf "const char %s_ptx[] = \\" "$NAME" > "$OUT"
  while read LINE
  do
-printf "\n\t\"%s\\\n\"" "$(printf "%s" "$LINE" | sed 's/["\\]/\\&/g')" >> 
"$OUT"
+printf "\n\t\"%s\\\n\"" "$(printf "%s" "$LINE"  | sed -e 's/\r//g' -e 's/["\\]/\\&/g')" 
>> "$OUT"
  done < "$IN"
  printf ";\n" >> "$OUT"
  



seems fine to me.



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

2017-08-29 Thread Jorge Ramirez


On 08/29/2017 12:18 AM, Hendrik Leppkes wrote:

On Tue, Aug 29, 2017 at 12:07 AM, Jorge Ramirez
 wrote:

On 08/28/2017 11:42 PM, Hendrik Leppkes wrote:

On Mon, Aug 28, 2017 at 11:36 PM, Jorge Ramirez
 wrote:

But manually "nesting" AVBufferRefs to make any underlying state
refcounted would also work.


I think so, context release now looks like this (it raises an ERROR to
the
user) but will not lock or poll.


Thats not really what he was referring to, but to avoid the "blocking"
entirely.

Basically, what you would do is have an AVBufferRef that basically
"holds" your v4l2 context, and every frame holds a reference on this
AVBufferRef - and only when all frames are released, the "free"
function on your context AVBufferRef is called, and you can then
release all its resources - without having to block the avcodec_close
function.


I see, thanks for the info

still, with the current v4l2 buffer design (previous thread in the
discussion), I can't allow avcodec_close to complete - so I have to block or
at least timeblock- when AVBuffersRefs pointing to v4l2 buffers have not
been released by the ffmpeg user (if the user tried to access that memory it
would result in bus errors since the mmaped addresses would not be valid)


The entire point here is that avcodec_close would basically not close
much (only things that can be free'ed without consequences) as long as
buffers are still referenced, and the actual closing of hardware
resources would happen in the free callback fired once all AVBufferRef
are unused.



ok will try to delegate closing the hardware and doing any operations 
that might invalidate any of the buffers that are on the fly to the last 
reference being released (avcodec_close will probably not be doing much 
then)







This is basically what AVHWFramesContext does, just with more frills
around it.


ah!
but what about memcpies (do you know if the AVHWFramesContext framework
copies to the hardware buffers before processing and then back to user
buffers? because I see no alternative if the AVBufferRefs must be kept alive
for ever...

Most hardware formats cannot be accessed by "software" without some
sort of conversion, thats where those memcpys come in - they download
the frame from special gpu memory to ordinary memory so they can be
further processed by any ordinary code.
This is handy for plugging hardware decoding into any old workflow
that already exists.

However, it is not required - you can have a fully optimized path and
keep everything in gpu memory at all times, assuming all components in
between support any special access requirements imposed by the gpu.


ok. makes sense. thanks a lot Hendrik.




- Hendrik


[apologies, it seems I took the thread out of the ML when I initally 
replied. bringing it back]



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

51 matches

Mail list logo