Re: [FFmpeg-devel] [PATCH 1/2] avformat/movenc: Added an option to disable SIDX atom

[Jeyapal, Karthick]

On 12/4/18, 2:18 PM, "Gyan Doshi"  wrote:

>On 04-12-2018 02:11 PM, Karthick J wrote:
>
>> [...]
>> +@item -movflags no_sidx
>> +Don't write sidx atom.
>
>Append a short note advising when this is required or recommended and 
>when not.
Thanks for your comment. I have added more details in PATCH v2. 
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/237181.html

Regards,
Karthick
>
>Thanks,
>Gyan

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/movenc: Added an option to disable SIDX atom

[Jeyapal, Karthick]

On 12/4/18, 4:25 PM, "Tobias Rapp"  wrote:

>>On 04.12.2018 09:41, Karthick J wrote:
>>[...]
>>   Run a second pass moving the index (moov atom) to the beginning of the 
>> file.
>>   This operation can take a while, and will not work in various situations 
>> such
>
>What about naming the option "skip_sidx" for symmetry with the existing 
>"skip_trailer"? Just my personal thought.
>
>Also it might be worth mentioning in the docs how global_sidx and the 
>new option correlate (which one is preferred if both exists, or is it an 
>error to specify both?).
Thanks for your comments. I have addressed both your feedbacks points in PATCH 
v2 http://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/237181.html

Regards,
Karthick
>
>>
>> [...]
>
>Regards,
>Tobias

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

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

[FFmpeg-devel] [PATCH v2 1/2] avformat/movenc: Added an option to disable SIDX atom

[Karthick J]

---
 doc/muxers.texi  |  4 
 libavformat/movenc.c | 12 ++--
 libavformat/movenc.h |  1 +
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index f1cc6f5fee..ca10741900 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1325,6 +1325,10 @@ more efficient), but with this option set, the muxer 
writes one moof/mdat
 pair for each track, making it easier to separate tracks.
 
 This option is implicitly set when writing ismv (Smooth Streaming) files.
+@item -movflags skip_sidx
+Skip writing of sidx atom. When bitrate overhead due to sidx atom is high,
+this option could be used for cases where sidx atom is not mandatory.
+When global_sidx flag is enabled, this option will be ignored. 
 @item -movflags faststart
 Run a second pass moving the index (moov atom) to the beginning of the file.
 This operation can take a while, and will not work in various situations such
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 6dab5193b0..3781a32895 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -75,6 +75,7 @@ static const AVOption options[] = {
 { "frag_discont", "Signal that the next fragment is discontinuous from 
earlier ones", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_FRAG_DISCONT}, 
INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
 { "delay_moov", "Delay writing the initial moov until the first fragment 
is cut, or until the first fragment flush", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_DELAY_MOOV}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
 { "global_sidx", "Write a global sidx index at the start of the file", 0, 
AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_GLOBAL_SIDX}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
+{ "skip_sidx", "Skip writing of sidx atom", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_SKIP_SIDX}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
 { "write_colr", "Write colr atom (Experimental, may be renamed or changed, 
do not use from scripts)", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_WRITE_COLR}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
 { "write_gama", "Write deprecated gama atom", 0, AV_OPT_TYPE_CONST, {.i64 
= FF_MOV_FLAG_WRITE_GAMA}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
 { "use_metadata_tags", "Use mdta atom for metadata.", 0, 
AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_USE_MDTA}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
@@ -4603,7 +4604,8 @@ static int mov_write_moof_tag(AVIOContext *pb, 
MOVMuxContext *mov, int tracks,
 mov_write_moof_tag_internal(avio_buf, mov, tracks, 0);
 moof_size = ffio_close_null_buf(avio_buf);
 
-if (mov->flags & FF_MOV_FLAG_DASH && !(mov->flags & 
FF_MOV_FLAG_GLOBAL_SIDX))
+if (mov->flags & FF_MOV_FLAG_DASH &&
+!(mov->flags & (FF_MOV_FLAG_GLOBAL_SIDX | FF_MOV_FLAG_SKIP_SIDX)))
 mov_write_sidx_tags(pb, mov, tracks, moof_size + 8 + mdat_size);
 
 if (mov->write_prft > MOV_PRFT_NONE && mov->write_prft < MOV_PRFT_NB)
@@ -5422,7 +5424,8 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
  * the next fragment. This means the cts of the first sample must
  * be the same in all fragments, unless end_pts was updated by
  * the packet causing the fragment to be written. */
-if ((mov->flags & FF_MOV_FLAG_DASH && !(mov->flags & 
FF_MOV_FLAG_GLOBAL_SIDX)) ||
+if ((mov->flags & FF_MOV_FLAG_DASH &&
+!(mov->flags & (FF_MOV_FLAG_GLOBAL_SIDX | 
FF_MOV_FLAG_SKIP_SIDX))) ||
 mov->mode == MODE_ISM)
 pkt->pts = pkt->dts + trk->end_pts - 
trk->cluster[trk->entry].dts;
 } else {
@@ -6067,6 +6070,11 @@ static int mov_init(AVFormatContext *s)
 s->flags &= ~AVFMT_FLAG_AUTO_BSF;
 }
 
+if (mov->flags & FF_MOV_FLAG_GLOBAL_SIDX && s->flags & 
FF_MOV_FLAG_SKIP_SIDX) {
+av_log(s, AV_LOG_WARNING, "Global SIDX enabled; Ignoring skip_sidx 
option\n");
+s->flags &= ~FF_MOV_FLAG_SKIP_SIDX;
+}
+
 if (mov->flags & FF_MOV_FLAG_FASTSTART) {
 mov->reserved_moov_size = -1;
 }
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index fe605d1ad2..68d6f23a5a 100644
--- a/libavformat/movenc.h
+++ b/libavformat/movenc.h
@@ -257,6 +257,7 @@ typedef struct MOVMuxContext {
 #define FF_MOV_FLAG_SKIP_TRAILER  (1 << 18)
 #define FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS  (1 << 19)
 #define FF_MOV_FLAG_FRAG_EVERY_FRAME  (1 << 20)
+#define FF_MOV_FLAG_SKIP_SIDX (1 << 21)
 
 int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt);
 
-- 
2.17.1 (Apple Git-112)

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

[FFmpeg-devel] [PATCH v2 2/2] avformat/dashenc: Used the movenc option skip_sidx instead of global_sidx

[Karthick J]

Anyways the intended behaviour was to disable SIDX atom.
---
 libavformat/dashenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 4d9b564a94..585b34cb97 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1162,7 +1162,7 @@ static int dash_init(AVFormatContext *s)
 
 if (os->segment_type == SEGMENT_TYPE_MP4) {
 if (c->streaming)
-av_dict_set(, "movflags", 
"frag_every_frame+dash+delay_moov+global_sidx", 0);
+av_dict_set(, "movflags", 
"frag_every_frame+dash+delay_moov+skip_sidx", 0);
 else
 av_dict_set(, "movflags", "frag_custom+dash+delay_moov", 
0);
 } else {
-- 
2.17.1 (Apple Git-112)

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

Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: replace assert0 with an error return when pict_type is uninitialized

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Linjie Fu
> Sent: Monday, December 3, 2018 4:34 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie 
> Subject: [FFmpeg-devel] [PATCH] lavc/qsvenc: replace assert0 with an error
> return when pict_type is uninitialized
> 
> pict_type may be uninitialized, and assert on a value coming from an
> external library is not proper.
> 
> Return invalid data error in function ff_qsv_encode to avoid using
> uninitialized value.
> 
> Signed-off-by: Linjie Fu 
> ---
>  libavcodec/qsvenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index
> 7f4592f878..891253be76 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -1338,7 +1338,7 @@ int ff_qsv_encode(AVCodecContext *avctx,
> QSVEncContext *q,
>  else if (bs->FrameType & MFX_FRAMETYPE_B || bs->FrameType
> & MFX_FRAMETYPE_xB)
>  pict_type = AV_PICTURE_TYPE_B;
>  else
> -av_assert0(!"Uninitialized pict_type!");
> +return AVERROR_INVALIDDATA;

Thus will be still a broken issue of ticket # 7593.
As comment in the ticket, I prefer to set the picture type to be 
AV_PICTURE_TYPE_NONE when MSDK return an unknown frame type, 
And also give a warning log message. 

BTW, please give a short and brief subject. There is a guideline about how to 
write commit message can be a reference: 
https://chris.beams.io/posts/git-commit/ 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/rasc: Check input space before reading chunk

[Michael Niedermayer]

Fixes: Timeout
Fixes: 
8/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RASC_fuzzer-5652564066959360

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/rasc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/rasc.c b/libavcodec/rasc.c
index e8e0740ddd..67351dfd19 100644
--- a/libavcodec/rasc.c
+++ b/libavcodec/rasc.c
@@ -680,6 +680,9 @@ static int decode_frame(AVCodecContext *avctx,
 while (bytestream2_get_bytes_left(gb) > 0) {
 unsigned type, size = 0;
 
+if (bytestream2_get_bytes_left(gb) < 8)
+return AVERROR_INVALIDDATA;
+
 type = bytestream2_get_le32(gb);
 if (type == KBND || type == BNDL) {
 intra = type == KBND;
-- 
2.19.2

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

[FFmpeg-devel] [PATCH] add support for ROI-based encoding

[Guo, Yejun]

this patch is not ask for merge, it is more to get a feature feedback.

The encoders such as libx264 support different QPs offset for different MBs,
it makes possible for ROI-based encoding. It makes sense to add support
within ffmpeg to generate/accept ROI infos and pass into encoders.

Typical usage: After AVFrame is decoded, a ffmpeg filter or user's code
generates ROI info for that frame, and the encoder finally does the
ROI-based encoding. And so I choose to maintain the ROI info within
AVFrame struct.

TODO:
- remove code in vf_scale.c, it is just an example to generate ROI info
- use AVBufferRef instead of current implementation within AVFrame struct.
- add other encoders support

Signed-off-by: Guo, Yejun 
---
 libavcodec/libx264.c   | 35 +++
 libavfilter/vf_scale.c |  8 
 libavutil/frame.c  |  9 +
 libavutil/frame.h  | 14 ++
 4 files changed, 66 insertions(+)

diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index a68d0a7..d8cc327 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -26,6 +26,7 @@
 #include "libavutil/pixdesc.h"
 #include "libavutil/stereo3d.h"
 #include "libavutil/intreadwrite.h"
+#include "libavutil/avassert.h"
 #include "avcodec.h"
 #include "internal.h"
 
@@ -345,6 +346,40 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, 
const AVFrame *frame,
 }
 }
 }
+
+if (frame->nb_rois > 0) {
+if (x4->params.rc.i_aq_mode == X264_AQ_NONE) {
+av_log(ctx, AV_LOG_ERROR, "Adaptive quantization must be 
enabled to use ROI encoding, skipping ROI.\n");
+}
+if (frame->interlaced_frame == 0) {
+const static int MBSIZE = 16;
+size_t mbx = (frame->width + MBSIZE - 1) / MBSIZE;
+size_t mby = (frame->height + MBSIZE - 1) / MBSIZE;
+float* qoffsets = (float*)av_malloc(sizeof(float) * mbx * mby);
+memset(qoffsets, 0, sizeof(float) * mbx * mby);
+
+for (size_t roi = 0; roi < frame->nb_rois; ++roi) {
+int starty = FFMIN(mby, frame->rois[roi].top / MBSIZE);
+int endy = FFMIN(mby, (frame->rois[roi].bottom + MBSIZE - 
1)/ MBSIZE);
+int startx = FFMIN(mbx, frame->rois[roi].left / MBSIZE);
+int endx = FFMIN(mbx, (frame->rois[roi].right + MBSIZE - 
1)/ MBSIZE);
+for (int y = starty; y < endy; ++y) {
+for (int x = startx; x < endx; ++x) {
+qoffsets[x + y*mbx] = frame->rois[roi].qoffset;
+}
+}
+}
+
+x4->pic.prop.quant_offsets = qoffsets;
+x4->pic.prop.quant_offsets_free = av_free;
+} else {
+av_log(ctx, AV_LOG_ERROR, "interlaced_frame not supported for 
ROI encoding, skipping ROI.\n");
+}
+} else {
+//to be removed in the final code, it is just for debug usage now.
+printf("ops, frame 0x%p with rois %ld\n", frame, 
frame->nb_rois);
+av_assert0(!"should not reach here");
+}
 }
 
 do {
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index f741419..71def72 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -437,6 +437,14 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 return ret;
 }
 
+// to be removed, just for debug usage temporarily
+in->nb_rois = 1;
+in->rois[0].top = 0;
+in->rois[0].left = 0;
+in->rois[0].bottom = in->height;
+in->rois[0].right = in->width/2;
+in->rois[0].qoffset = 15.0f; // 15.0f, +-5.0f, +-25.0f
+
 if (!scale->sws)
 return ff_filter_frame(outlink, in);
 
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 9b3fb13..9c38bdd 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -425,6 +425,15 @@ FF_DISABLE_DEPRECATION_WARNINGS
 FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 
+dst->nb_rois = src->nb_rois;
+for (int i = 0; i < dst->nb_rois; ++i) {
+dst->rois[i].top = src->rois[i].top;
+dst->rois[i].bottom = src->rois[i].bottom;
+dst->rois[i].left = src->rois[i].left;
+dst->rois[i].right = src->rois[i].right;
+dst->rois[i].qoffset = src->rois[i].qoffset;
+}
+
 av_buffer_unref(>opaque_ref);
 av_buffer_unref(>private_ref);
 if (src->opaque_ref) {
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 66f27f4..b245a90 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -193,6 +193,15 @@ typedef struct AVFrameSideData {
 AVBufferRef *buf;
 } AVFrameSideData;
 
+
+typedef struct AVFrameROI {
+size_t top;
+size_t bottom;
+size_t left;
+size_t right;
+float qoffset;
+} AVFrameROI;
+
 /**
  * This structure describes decoded (raw) audio or video data.
  *
@@ -556,6 +565,11 @@ typedef 

Re: [FFmpeg-devel] [PATCH V2 0/3] Add libsvt HEVC encoder wrapper

[myp...@gmail.com]

On Wed, Dec 5, 2018 at 7:26 AM Carl Eugen Hoyos  wrote:
>
> 2018-12-04 16:23 GMT+01:00, Moritz Barsnick :
> > On Tue, Dec 04, 2018 at 22:25:29 +0800, Jun Zhao wrote:
>
> >>   lavc/svt_hevc: add libsvt hevc encoder wrapper.
> >>   Changelog: Add new entry for svt-hevc encoder
> >
> > I still recommend to merge these two, which is common practice.
>
> +1.
>
> Carl Eugen

Will merge these two, Tks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/ass: Fix a memory leak defect.

[Carl Eugen Hoyos]

2018-02-13 8:51 GMT+01:00, Gang Fan(范刚) :
> Here is the patch.

Ping.

If this gets applied, please mention ticket #7019.

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

Re: [FFmpeg-devel] [PATCH V2 0/3] Add libsvt HEVC encoder wrapper

[myp...@gmail.com]

On Wed, Dec 5, 2018 at 7:42 AM Mark Thompson  wrote:
>
> On 04/12/2018 15:23, Moritz Barsnick wrote:
> > On Tue, Dec 04, 2018 at 22:25:29 +0800, Jun Zhao wrote:
> >> This wrapper work with SVT-HEVC new_api branch, more information can get
> >> from https://github.com/intel/SVT-HEVC/blob/new_api/ffmpeg_plugin/.
> >
> > Is this API stable? (I have heard voices that the external library
> > wrapper shouldn't aim at a moving target.)
> >
> > If so, can the API/version be detected (e.g. vs. the one on master), or
> > will the compile against a build from master just fail? (Or is this
> > branch used only because ffmpeg_plugin exists only on this branch?)
>
> This looks like a big problem currently.  The codebase  appears more like a 
> prototype rather than finished code - the headers are very dirty, and it's 
> leaking all sorts of weird symbols into the global namespace.  Given that, it 
> seems unlikely that the current form of the headers and library will survive 
> to release, and therefore we should probably hold off for now.
>
As far as know, SVT-HEVC come from eBrisk video, more information can
be found by: 
https://www.intel.com/content/www/us/en/processors/xeon/scalable/software-solutions/ebrisk-comms-video.html,
I don't think the SVT-HEVC codebase just as the prototype, I know
SVT-HEVC codebase need to refine and refactoring, and 他his is exactly
what these people are doing on new_api branch.

BTW: If we declined to include the wrapper as part of FFmpeg mainline,
this means SVT-HEVC need to maintain the FFmpeg wrapper patch set for
this, I don't think this is a good idea if some guys want to try
SVT-HEVC encoder from FFmpeg.
> Relatedly, are there any results indicating how good this encoder actually 
> is, especially as compared to libx265 as the main existing software H.265 
> encoder?  FFmpeg previously declined to include a wrapper for the Turing 
> H.265 encoder, due to lack of any clear use case for it at the time (that 
> might have changed by now, I don't know).
>
https://www.intel.com/content/www/us/en/processors/xeon/scalable/software-solutions/ebrisk-comms-video.html
maybe can answer part of the above question. Tks.
> Thanks,
>
> - Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH V2 0/3] Add libsvt HEVC encoder wrapper

[myp...@gmail.com]

On Tue, Dec 4, 2018 at 11:23 PM Moritz Barsnick  wrote:
>
> On Tue, Dec 04, 2018 at 22:25:29 +0800, Jun Zhao wrote:
> > This wrapper work with SVT-HEVC new_api branch, more information can get
> > from https://github.com/intel/SVT-HEVC/blob/new_api/ffmpeg_plugin/.
>
> Is this API stable? (I have heard voices that the external library
> wrapper shouldn't aim at a moving target.)
>
> If so, can the API/version be detected (e.g. vs. the one on master), or
> will the compile against a build from master just fail? (Or is this
> branch used only because ffmpeg_plugin exists only on this branch?)
>
Because new_api is a branch of a refactoring master branch, after all
of done, we will switch the new_api to master.
BTW: the API is stable.

> > For SVT-HEVC build, you can switch the branch to new_api, then run:
> > ./build.sh  in the directory Build/linux.
> >
> > If you want to enable the pkg-config for SVT-HEVC library, the file
> > install_libsvt_hevc_plugin_ffmpeg.sh give a sample for this.
> > (https://github.com/intel/SVT-HEVC/blob/new_api/ffmpeg_plugin/\
> > install_libsvt_hevc_ffmpeg.sh).
>
> But your configure modifications don't use it. Will the pkgconfig file
> go upstream/master any time soon?
We will upstream pkg-config part patch and refine SVT-HEVC install
script to SVT-HEVC new_api branch as soon as possible, this is exactly
what we are doing now.
>
> >   lavc/svt_hevc: add libsvt hevc encoder wrapper.
> >   Changelog: Add new entry for svt-hevc encoder
>
> I still recommend to merge these two, which is common practice.
>
> Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/opusenc: add frame_alloc and frame_count check to quit encode

[Rostislav Pehlivanov]

On Thu, 29 Nov 2018 at 09:14, Linjie Fu  wrote:

> Add frame_alloc and frame_count check in opus_encode_frame to avoid
> the infinite loop issue.
>
> Fix #7578.
>
> Signed-off-by: Linjie Fu 
> ---
>  libavcodec/opusenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/opusenc.c b/libavcodec/opusenc.c
> index 578785f4b4..7146968fc8 100644
> --- a/libavcodec/opusenc.c
> +++ b/libavcodec/opusenc.c
> @@ -543,7 +543,7 @@ static int opus_encode_frame(AVCodecContext *avctx,
> AVPacket *avpkt,
>  ff_bufqueue_add(avctx, >bufqueue, av_frame_clone(frame));
>  } else {
>  ff_opus_psy_signal_eof(>psyctx);
> -if (!s->afq.remaining_samples)
> +if (!s->afq.remaining_samples || (!s->afq.frame_alloc &&
> !s->afq.frame_count))
>  return 0; /* We've been flushed and there's nothing left to
> encode */
>  }
>
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


I don't think that's the correct way to do this, maybe it would be better
to check if the remaning samples are above the initial_padding amount or
decreasing the first frame's duration by the initial_padding amount to make
the count correct.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/mjpeg: don't override color information from demuxer

[Hendrik Leppkes]

On Wed, Dec 5, 2018 at 1:14 AM Steinar H. Gunderson
 wrote:
>
> On Wed, Dec 05, 2018 at 12:57:43AM +0100, Hendrik Leppkes wrote:
> > These comments are not accurate. avformat does not fill these values,
> > because outside of deprecated code it does not expose such a struct to
> > the user.
>
> Hm, I was asked on #ffmpeg-devel to update it :-) But I suppose maybe it sets
> them in AVCodecParameters instead?
>

It would. And that struct is only ever filled by avformat (or a user),
and not avcodec, so there is no overlap there either.

The real problem is that its impossible to know which component to
really trust. Why does a demuxer have more authority on the color
format then a decoder? Or vice-versa?
We don't have a solution for that, and its really something the user
application currently has to solve.

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

Re: [FFmpeg-devel] [PATCH] avcodec/mjpeg: don't override color information from demuxer

[Steinar H. Gunderson]

On Wed, Dec 05, 2018 at 12:57:43AM +0100, Hendrik Leppkes wrote:
> These comments are not accurate. avformat does not fill these values,
> because outside of deprecated code it does not expose such a struct to
> the user.

Hm, I was asked on #ffmpeg-devel to update it :-) But I suppose maybe it sets
them in AVCodecParameters instead?

/* Steinar */
-- 
Homepage: https://www.sesse.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/mjpeg: don't override color information from demuxer

[Hendrik Leppkes]

On Wed, Dec 5, 2018 at 12:35 AM Steinar H. Gunderson
 wrote:
>
> Some demuxers, like Matroska, allow for sending colorspace information
> that override MJPEG defaults when it comes to Y'CbCr coefficients or
> chroma location. Don't override such data if the demuxer already has
> set it; this allows decoding such MJPEG streams correctly.
>
> Also document in avcodec.h that these fields are actually set first by
> libavformat, even if libavcodec is usually the one to set them. This is
> not new behavior; e.g., dnxhd already works this way.
> ---
>  libavcodec/avcodec.h  | 10 +-
>  libavcodec/mjpegdec.c |  8 ++--
>  tests/fate/matroska.mak   |  3 +++
>  tests/ref/fate/matroska-mjpeg-color-space | 22 ++
>  4 files changed, 36 insertions(+), 7 deletions(-)
>  create mode 100644 tests/ref/fate/matroska-mjpeg-color-space
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 3922e89331..b7ea99d8ab 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -2145,35 +2145,35 @@ typedef struct AVCodecContext {
>  /**
>   * Chromaticity coordinates of the source primaries.
>   * - encoding: Set by user
> - * - decoding: Set by libavcodec
> + * - decoding: Set by libavformat and/or libavcodec
>   */
>  enum AVColorPrimaries color_primaries;
>
>  /**
>   * Color Transfer Characteristic.
>   * - encoding: Set by user
> - * - decoding: Set by libavcodec
> + * - decoding: Set by libavformat and/or libavcodec
>   */
>  enum AVColorTransferCharacteristic color_trc;
>
>  /**
>   * YUV colorspace type.
>   * - encoding: Set by user
> - * - decoding: Set by libavcodec
> + * - decoding: Set by libavformat and/or libavcodec
>   */
>  enum AVColorSpace colorspace;
>
>  /**
>   * MPEG vs JPEG YUV range.
>   * - encoding: Set by user
> - * - decoding: Set by libavcodec
> + * - decoding: Set by libavformat and/or libavcodec
>   */
>  enum AVColorRange color_range;
>
>  /**
>   * This defines the location of chroma samples.
>   * - encoding: Set by user
> - * - decoding: Set by libavcodec
> + * - decoding: Set by libavformat and/or libavcodec
>   */
>  enum AVChromaLocation chroma_sample_location;
>

These comments are not accurate. avformat does not fill these values,
because outside of deprecated code it does not expose such a struct to
the user.

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

Re: [FFmpeg-devel] [PATCH 1/1] avcodec/vaapi_encode: add frame-skip func

[Mark Thompson]

On 04/12/2018 01:46, Sun, Jing A wrote:
> Hi Mark,
> 
> Is there any issue that I need to fix for this patch please? 

See comments in the message you quoted below?  I think the most important point 
is that the existing timing information appears to contain all the information 
you want for VFR, so you probably shouldn't need the ad-hoc side-data type.

- Mark


> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Sun, 
> Jing A
> Sent: Friday, November 23, 2018 5:37 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH 1/1] avcodec/vaapi_encode: add frame-skip 
> func
> 
> Hi Mark,
> 
> In some cases, that is useful. For example, an online content distributer, 
> who keeps encoding the captured video frames by ffmpeg and sending them out. 
> At times, there is no update of source, which makes one or several captured 
> source frames are exactly the same as the last one, and the distributer wants 
> to just skip such frames, without stopping the encoding process.
> 
> Regards,
> SUN, Jing
> 
> 
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
> Thompson
> Sent: Tuesday, November 20, 2018 4:07 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/1] avcodec/vaapi_encode: add frame-skip 
> func
> 
> On 19/11/18 09:04, Jing SUN wrote:
>> frame-skip is required to implement network bandwidth self-adaptive 
>> vaapi encoding.
>> To make a frame skipped, allocate its frame side data of 
>> AV_FRAME_DATA_SKIP_FRAME type and set its value to 1.
> 
> So if I'm reading this correctly the idea is to implement partial VFR by 
> having a special new side-data type which indicates where frames would have 
> been had the input actually matched the configured CFR behaviour?
> 
> Why is the user meant to create these special frames?  It seems to me that 
> the existing method of looking at the timestamps would be a better way to 
> find any gaps.
> 
> (Or, even better, add timestamps to VAAPI so that it can support VFR in a 
> sensible way rather than adding hacks like this to allow partial VFR with 
> weird constraints.)
> 
>> Signed-off-by: Jing SUN 
>> ---
>>  libavcodec/vaapi_encode.c | 142 
>> --
>>  libavcodec/vaapi_encode.h |   5 ++
>>  libavutil/frame.c |   1 +
>>  libavutil/frame.h |   5 ++
>>  4 files changed, 149 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c 
>> index 2fe8501..a401d61 100644
>> --- a/libavcodec/vaapi_encode.c
>> +++ b/libavcodec/vaapi_encode.c
>> @@ -23,6 +23,7 @@
>>  #include "libavutil/common.h"
>>  #include "libavutil/log.h"
>>  #include "libavutil/pixdesc.h"
>> +#include "libavutil/intreadwrite.h"
>>  
>>  #include "vaapi_encode.h"
>>  #include "avcodec.h"
>> @@ -103,6 +104,47 @@ static int 
>> vaapi_encode_make_param_buffer(AVCodecContext *avctx,
>>  return 0;
>>  }
>>  
>> +static int vaapi_encode_check_if_skip(AVCodecContext *avctx,
>> +  VAAPIEncodePicture *pic) {
>> +AVFrameSideData *fside = NULL;
>> +VAAPIEncodeContext *ctx = avctx->priv_data;
>> +VAAPIEncodePicture *cur = NULL;
>> +int i = 0;
>> +
>> +if (!pic || !pic->input_image)
>> +return AVERROR(EINVAL);
>> +
>> +fside = av_frame_get_side_data(pic->input_image, 
>> AV_FRAME_DATA_SKIP_FRAME);
>> +if (fside)
>> +pic->skipped_flag = AV_RL8(fside->data);
>> +else
>> +pic->skipped_flag = 0;
>> +
>> +if (0 == pic->skipped_flag)
>> +return 0;
>> +
>> +if ((pic->type == PICTURE_TYPE_IDR) || (pic->type == PICTURE_TYPE_I)) {
>> +av_log(avctx, AV_LOG_INFO, "Can't skip IDR/I pic 
>> %"PRId64"/%"PRId64".\n",
>> +   pic->display_order, pic->encode_order);
>> +pic->skipped_flag = 0;
>> +return 0;
>> +}
>> +
>> +for (cur = ctx->pic_start; cur; cur = cur->next) {
>> +for (i=0; i < cur->nb_refs; ++i) {
>> +if (cur->refs[i] == pic) {
>> +av_log(avctx, AV_LOG_INFO, "Can't skip ref pic 
>> %"PRId64"/%"PRId64".\n",
>> +   pic->display_order, pic->encode_order);
>> +pic->skipped_flag = 0;
>> +return 0;
>> +}
>> +}
>> +}
>> +
>> +return 0;
>> +}
>> +
>>  static int vaapi_encode_wait(AVCodecContext *avctx,
>>   VAAPIEncodePicture *pic)  { @@ -418,6
>> +460,69 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
>>  }
>>  }
>>  
>> +err = vaapi_encode_check_if_skip(avctx, pic);
>> +if (err != 0)
>> +av_log(avctx, AV_LOG_ERROR, "Fail to check if skip.\n");
>> +
>> +#ifdef VAEncMiscParameterSkipFrame
>> +if (pic->skipped_flag) {
>> +av_log(avctx, AV_LOG_INFO, "Skip pic %"PRId64"/%"PRId64" as 
>> requested.\n",
>> +   

Re: [FFmpeg-devel] [PATCH V2 0/3] Add libsvt HEVC encoder wrapper

[Mark Thompson]

On 04/12/2018 15:23, Moritz Barsnick wrote:
> On Tue, Dec 04, 2018 at 22:25:29 +0800, Jun Zhao wrote:
>> This wrapper work with SVT-HEVC new_api branch, more information can get 
>> from https://github.com/intel/SVT-HEVC/blob/new_api/ffmpeg_plugin/.
> 
> Is this API stable? (I have heard voices that the external library
> wrapper shouldn't aim at a moving target.)
> 
> If so, can the API/version be detected (e.g. vs. the one on master), or
> will the compile against a build from master just fail? (Or is this
> branch used only because ffmpeg_plugin exists only on this branch?)

This looks like a big problem currently.  The codebase appears more like a 
prototype rather than finished code - the headers are very dirty, and it's 
leaking all sorts of weird symbols into the global namespace.  Given that, it 
seems unlikely that the current form of the headers and library will survive to 
release, and therefore we should probably hold off for now.

Relatedly, are there any results indicating how good this encoder actually is, 
especially as compared to libx265 as the main existing software H.265 encoder?  
FFmpeg previously declined to include a wrapper for the Turing H.265 encoder, 
due to lack of any clear use case for it at the time (that might have changed 
by now, I don't know).

Thanks,

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/msvideo1: Check for too small dimensions

[Michael Niedermayer]

On Sat, Dec 01, 2018 at 10:16:19PM +0100, Michael Niedermayer wrote:
> Such low resolution would result in empty output as a minimum of 4x4 is needed
> We could also check for multiple of 4 dimensions but that is not needed
> 
> Fixes: Timeout
> Fixes: 
> 11191/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSVIDEO1_fuzzer-5739529588178944
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/msvideo1.c | 3 +++
>  1 file changed, 3 insertions(+)

will apply

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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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

Re: [FFmpeg-devel] [PATCH] avcodec/mjpeg: don't override color information from demuxer

[Steinar H. Gunderson]

On Wed, Dec 05, 2018 at 12:31:10AM +0100, Steinar H. Gunderson wrote:
> Some demuxers, like Matroska, allow for sending colorspace information
> that override MJPEG defaults when it comes to Y'CbCr coefficients or
> chroma location. Don't override such data if the demuxer already has
> set it; this allows decoding such MJPEG streams correctly.
> 
> Also document in avcodec.h that these fields are actually set first by
> libavformat, even if libavcodec is usually the one to set them. This is
> not new behavior; e.g., dnxhd already works this way.

Attaching the FATE test file used (created by myself; it's just a black
MJPEG frame, although with the special CS=ITU601 tag set to get TV range).

/* Steinar */
-- 
Homepage: https://www.sesse.net/


mjpeg-color-space.mkv
Description: video/matroska
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/mjpeg: don't override color information from demuxer

[Steinar H. Gunderson]

Some demuxers, like Matroska, allow for sending colorspace information
that override MJPEG defaults when it comes to Y'CbCr coefficients or
chroma location. Don't override such data if the demuxer already has
set it; this allows decoding such MJPEG streams correctly.

Also document in avcodec.h that these fields are actually set first by
libavformat, even if libavcodec is usually the one to set them. This is
not new behavior; e.g., dnxhd already works this way.
---
 libavcodec/avcodec.h  | 10 +-
 libavcodec/mjpegdec.c |  8 ++--
 tests/fate/matroska.mak   |  3 +++
 tests/ref/fate/matroska-mjpeg-color-space | 22 ++
 4 files changed, 36 insertions(+), 7 deletions(-)
 create mode 100644 tests/ref/fate/matroska-mjpeg-color-space

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 3922e89331..b7ea99d8ab 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2145,35 +2145,35 @@ typedef struct AVCodecContext {
 /**
  * Chromaticity coordinates of the source primaries.
  * - encoding: Set by user
- * - decoding: Set by libavcodec
+ * - decoding: Set by libavformat and/or libavcodec
  */
 enum AVColorPrimaries color_primaries;
 
 /**
  * Color Transfer Characteristic.
  * - encoding: Set by user
- * - decoding: Set by libavcodec
+ * - decoding: Set by libavformat and/or libavcodec
  */
 enum AVColorTransferCharacteristic color_trc;
 
 /**
  * YUV colorspace type.
  * - encoding: Set by user
- * - decoding: Set by libavcodec
+ * - decoding: Set by libavformat and/or libavcodec
  */
 enum AVColorSpace colorspace;
 
 /**
  * MPEG vs JPEG YUV range.
  * - encoding: Set by user
- * - decoding: Set by libavcodec
+ * - decoding: Set by libavformat and/or libavcodec
  */
 enum AVColorRange color_range;
 
 /**
  * This defines the location of chroma samples.
  * - encoding: Set by user
- * - decoding: Set by libavcodec
+ * - decoding: Set by libavformat and/or libavcodec
  */
 enum AVChromaLocation chroma_sample_location;
 
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 2f1635838a..9ee2daadf8 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -158,8 +158,12 @@ av_cold int ff_mjpeg_decode_init(AVCodecContext *avctx)
 s->first_picture = 1;
 s->got_picture   = 0;
 s->org_height= avctx->coded_height;
-avctx->chroma_sample_location = AVCHROMA_LOC_CENTER;
-avctx->colorspace = AVCOL_SPC_BT470BG;
+if (avctx->chroma_sample_location == AVCHROMA_LOC_UNSPECIFIED) {
+avctx->chroma_sample_location = AVCHROMA_LOC_CENTER;
+}
+if (avctx->colorspace == AVCOL_SPC_UNSPECIFIED) {
+avctx->colorspace = AVCOL_SPC_BT470BG;
+}
 s->hwaccel_pix_fmt = s->hwaccel_sw_pix_fmt = AV_PIX_FMT_NONE;
 
 if ((ret = init_default_huffman_tables(s)) < 0)
diff --git a/tests/fate/matroska.mak b/tests/fate/matroska.mak
index 2747496e1e..1768ce6ee2 100644
--- a/tests/fate/matroska.mak
+++ b/tests/fate/matroska.mak
@@ -9,5 +9,8 @@ fate-matroska-remux: REF = 1ed49a4f2b6790357fac268938357353
 FATE_MATROSKA_FFPROBE-$(call ALLYES, MATROSKA_DEMUXER) += 
fate-matroska-spherical-mono
 fate-matroska-spherical-mono: CMD = run ffprobe$(PROGSSUF)$(EXESUF) 
-show_entries stream_side_data_list -select_streams v -v 0 
$(TARGET_SAMPLES)/mkv/spherical.mkv
 
+FATE_MATROSKA_FFPROBE-$(call ALLYES, MATROSKA_DEMUXER) += 
fate-matroska-mjpeg-color-space
+fate-matroska-mjpeg-color-space: CMD = run ffprobe$(PROGSSUF)$(EXESUF) 
-show_entries 
frame=color_range,color_space,color_primaries,color_transfer,chroma_location 
$(TARGET_SAMPLES)/mkv/mjpeg-color-space.mkv
+
 FATE_SAMPLES_AVCONV += $(FATE_MATROSKA-yes)
 FATE_SAMPLES_FFPROBE += $(FATE_MATROSKA_FFPROBE-yes)
diff --git a/tests/ref/fate/matroska-mjpeg-color-space 
b/tests/ref/fate/matroska-mjpeg-color-space
new file mode 100644
index 00..d3cd39f967
--- /dev/null
+++ b/tests/ref/fate/matroska-mjpeg-color-space
@@ -0,0 +1,22 @@
+[FRAME]
+color_range=tv
+color_space=bt709
+color_primaries=bt709
+color_transfer=iec61966-2-1
+chroma_location=left
+[SIDE_DATA]
+[/SIDE_DATA]
+[SIDE_DATA]
+[/SIDE_DATA]
+[/FRAME]
+[FRAME]
+color_range=tv
+color_space=bt709
+color_primaries=bt709
+color_transfer=iec61966-2-1
+chroma_location=left
+[SIDE_DATA]
+[/SIDE_DATA]
+[SIDE_DATA]
+[/SIDE_DATA]
+[/FRAME]
-- 
2.19.1

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

Re: [FFmpeg-devel] [PATCH V2 0/3] Add libsvt HEVC encoder wrapper

[Carl Eugen Hoyos]

2018-12-04 16:23 GMT+01:00, Moritz Barsnick :
> On Tue, Dec 04, 2018 at 22:25:29 +0800, Jun Zhao wrote:

>>   lavc/svt_hevc: add libsvt hevc encoder wrapper.
>>   Changelog: Add new entry for svt-hevc encoder
>
> I still recommend to merge these two, which is common practice.

+1.

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

Re: [FFmpeg-devel] [PATCH 1/1] avcodec/vaapi_encode: add frame-skip func

[Carl Eugen Hoyos]

2018-12-04 2:46 GMT+01:00, Sun, Jing A :
> Hi Mark,
>
> Is there any issue that I need to fix for this patch please?

Did you already send a patch with the version bump?

Please avoid top-posting here, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/ppc/hevcdsp: Fix build failures with powerpc-linux-gnu-gcc-4.8 with --disable-optimizations

[Carl Eugen Hoyos]

2018-12-04 18:02 GMT+01:00, Michael Niedermayer :
> On Tue, Dec 04, 2018 at 04:33:03PM +0100, Carl Eugen Hoyos wrote:
>> 2018-12-04 16:29 GMT+01:00, Michael Niedermayer :
>> > The affected functions could also be changed into macros, this is the
>> > smaller change to fix it though. And avoids (probably) less readable
>> > macros
>>
>> > The extra code should be optimized out when optimizations are done as
>> > all
>> > values are known at build after inlining.
>>
>> Shouldn't this be verified?
>
> ive verified it with the patch below

Thank you!

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

Re: [FFmpeg-devel] [PATCH V2] lavf: add transpose_opencl filter

[Mark Thompson]

On 04/12/2018 07:31, Song, Ruiling wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>> Mark Thompson
>> Sent: Monday, December 3, 2018 8:10 AM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH V2] lavf: add transpose_opencl filter
>>
>> On 28/11/2018 02:27, Ruiling Song wrote:
>>> Signed-off-by: Ruiling Song 
>>> ---
>>>  configure |   1 +
>>>  libavfilter/Makefile  |   1 +
>>>  libavfilter/allfilters.c  |   1 +
>>>  libavfilter/opencl/transpose.cl   |  35 +
>>>  libavfilter/opencl_source.h   |   1 +
>>>  libavfilter/transpose.h   |  34 +
>>>  libavfilter/vf_transpose.c|  14 +-
>>>  libavfilter/vf_transpose_opencl.c | 288
>> ++
>>>  8 files changed, 362 insertions(+), 13 deletions(-)
>>>  create mode 100644 libavfilter/opencl/transpose.cl
>>>  create mode 100644 libavfilter/transpose.h
>>>  create mode 100644 libavfilter/vf_transpose_opencl.c
>>
>> Testing the passthrough option here reveals a slightly unfortunate 
>> interaction
>> with mapping - if this is the only filter in use, then not doing a redundant 
>> copy
>> can fall over.
>>
>> For example, on Rockchip (Mali) decoding with rkmpp then using:
>>
>> -vf
>> hwmap=derive_device=opencl,transpose_opencl=dir=clock:passthrough=landsc
>> ape,hwdownload,format=nv12
>>
>> fails at the download in the passthrough case because it doesn't allow the 
>> read
>> (the extension does explicitly document this constraint -
>> > emory.txt>).
>>
>> VAAPI has a similar problem with a decode followed by:
>>
>> -vf
>> hwmap=derive_device=opencl,transpose_opencl,hwmap=derive_device=vaapi:r
>> everse=1
>>
>> because the reverse mapping tries to replace the inlink hw_frames_ctx in a 
>> way
>> which doesn't actually work.
>>
>> All of these cases do of course work if anything else is in the way - any 
>> additional
>> opencl filter on either side makes it work.  I think it's fine to ignore 
>> this (after all,
>> the hwmap immediately followed by hwdownload case can already fail in the
>> same way), but any thoughts you have on making that better are welcome.
> I also noticed that when I did testing. Currently have no idea on how to fix 
> it.
> But I do have interest to look for a better fix for this issue.
> Right now I am still struggling to understand the source code of hwmap.
> I didn't figure out how the hwmap will be used to map from software to 
> hardware format.
> That is the piece of code starting from line 200 in vf_hwmap.c
> https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_hwmap.c#L200
> Could you show me some example command that would go into this branch?

It's the non-unmap case of the second mode in 
.  An API which offers software 
mapping can provide a mapped frame to the previous component to use as its 
output, which may then be able to avoid a redundant copy that would happen if 
hwupload were used.

For a slightly artificial example where the difference due to the removed copy 
is very visible, compare:

$ ./ffmpeg_g -y -init_hw_device vaapi=v:/dev/dri/renderD128 -filter_hw_device v 
-filter_complex 
'haldclutsrc=level=8:rate=30,format=rgb0,hwupload,scale_vaapi=format=nv12' -c:v 
h264_vaapi -frames:v 1 out.mp4
frame=1 fps=1089
$ ./ffmpeg_g -y -init_hw_device vaapi=v:/dev/dri/renderD128 -filter_hw_device v 
-filter_complex 
'haldclutsrc=level=8:rate=30,format=rgb0,hwmap,scale_vaapi=format=nv12' -c:v 
h264_vaapi -frames:v 1 out.mp4
frame=1 fps=1391

Thanks,

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

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Ronald S. Bultje]

Hi,
On Tue, Dec 4, 2018 at 4:56 PM Martin Vignali 
wrote:

> Le mar. 4 déc. 2018 à 16:12, Jean-Baptiste Kempf  a
> écrit :
>
> > But then, you will get absolutely all the integration from ALL the
> various
> > non-open source multimedia libraries, because it is useful to someone.
> > Including shims for Adobe, Dolby and others.
>
> I'm probably disagree with you on this subject ! :-)
>

https://patchwork.ffmpeg.org/patch/7329/ (see also my response to that [1])

Or just on IRC today (!)
"  JVET VVC just got ready to be built with MSYS/MinGW too ... so I
guess it is not yet in a stage to be considered to be linked into ffmpeg.
What would be your criteria to consider this encoder? How would we get to
know that you start considering it? Looking for a thread in the mailing
list?"

I'm surprised this patch made it in, I've always assumed we were
uncomfortable with closed-source software and that the hardware-support was
a corner-case. Can I submit a wrapper for my closed-source VP9 encoder?

Ronald

[1]
https://ffmpeg-devel.ffmpeg.narkive.com/Ok5y3HXO/patch-0-3-codec-wrapper-for-librv11-and-rmhd-muxer-demuxer#post35
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/msmpeg4dec: Skip frame if its smaller than 1/8 of the minimal size

[Michael Niedermayer]

On Thu, Nov 29, 2018 at 02:32:10AM +0100, Michael Niedermayer wrote:
> Frames that small are not valid and of limited use for error concealment, 
> while
> being very computationally intensive to process.
> 
> Fixes: Timeout
> Fixes: 
> 11318/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSMPEG4V1_fuzzer-5710884555456512
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/msmpeg4dec.c | 8 
>  1 file changed, 8 insertions(+)

will apply this and the othar patch

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Martin Vignali]

Le mar. 4 déc. 2018 à 16:12, Jean-Baptiste Kempf  a écrit :

> Helllo,
>
> On Tue, 4 Dec 2018, at 15:00, Martin Vignali wrote:
> > 1 :
> > Removing features used by people which doesn't respect the licence,
> seems a
> > very bad thing.
>
> I disagree with you.
> Helping people violating open source licenses is not a good idea.
>

It's not just about helping Newtek or not.
My intervention in this discussion is mainly about annoy ndi/ffmpeg user
(including those who respect licence)

Of course Newtek have some interest of having ndi support inside ffmpeg
but some user can also have an interest to have this feature.

It's similar for me to other manufacturer things (for example decklink
device support have a benefit for blackmagic
and for user who need SDI record/playback).



>
> > 3 - Need a proper definition, and a dedicated discussion. To avoid
> > including code that it's not conform to the global policy of this
> project.
> > Reading this thread, it's seems like there is lot of interpretation about
> > acceptable and non acceptable not opensource part.
>
> The thing is, the license is the license, and there are a lot of
> explanations from FSF, FSFE, SFLC, and sooo many others.
>
> > - ok for not open source part from os
> > - ok for not open source part for "hardware thing", because we can think
> > it's like os thing !
>
> Yes, and this is quite documented, as part of all the GPL family of
> licenses, as part of "System Libraries".
>
> > - ok from not open source part, if it's useful ? or not ?
> > What definition of useful ? (and everything related to broadcast is not
> > useless, just because not everyone use it !)
>
> You cannot define usefulness easily.
>

That's exactly what I meant.

For including or not, some not opensource part, there will be two case
- the part which can be included in redistributable build
(i let people who have knowledge on this to decide which part can be in
these builds)

- the part which can not be included in redistributable build, and need
that the user compile himself
to enable some functionnality.
If this is just about having the right (in licence point of view) to
include or not in these kind of build,
here too i will let people with licence knowledge decide.

But if including or not, a not opensource part, it's about opinion on
utility of this part, this need to be better define.
This will avoid discussion about being useful or not, depending of opinion
of each one at the moment of a patch submission.

An impartial way, can be for example, if the component is free (in the
sense without additionnal cost) and provide a functionality not available
in another way.


> > And yes, it's better to have full opensource ndi support, instead of the
> > current situation.
> > But it's not a reason to remove features for users.
>
> But then, you will get absolutely all the integration from ALL the various
> non-open source multimedia libraries, because it is useful to someone.
> Including shims for Adobe, Dolby and others.
>

I'm probably disagree with you on this subject ! :-)



> And what is the incentive to do open source alternatives?
>
>
In a manufacturer point of view : having the functionnality available to a
wider audience, because it can be included in distributable build.

In user/contributor point of view : having more sustainability on a
feature. A full opensource code can still working if some people
have an interest of maintain/improve it.

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

[FFmpeg-devel] [PATCH] avfilter/vf_showinfo: allow checksums calculation to be disabled

[Paul B Mahol]

Fixes #6987.

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi  |  7 +
 libavfilter/vf_showinfo.c | 56 ---
 2 files changed, 47 insertions(+), 16 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 41fbbc5329..a795531584 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -15304,6 +15304,13 @@ Keep the same colorspace property (default).
 Show a line containing various information for each input video frame.
 The input video is not modified.
 
+This filter supports the following options:
+
+@table @option
+@item checksums
+Calculate checksums of each plane. By default enabled.
+@end table
+
 The shown line contains a sequence of key/value pairs of the form
 @var{key}:@var{value}.
 
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 37e73b60aa..9e84197a55 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -28,6 +28,7 @@
 #include "libavutil/display.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/internal.h"
+#include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/spherical.h"
 #include "libavutil/stereo3d.h"
@@ -38,6 +39,21 @@
 #include "internal.h"
 #include "video.h"
 
+typedef struct ShowInfoContext {
+const AVClass *class;
+int calculate_checksums;
+} ShowInfoContext;
+
+#define OFFSET(x) offsetof(ShowInfoContext, x)
+#define VF AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption showinfo_options[] = {
+{ "checksum", "calculate checksums", OFFSET(calculate_checksums), 
AV_OPT_TYPE_BOOL, {.i64=1}, 0, 1, VF },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(showinfo);
+
 static void dump_spherical(AVFilterContext *ctx, AVFrame *frame, 
AVFrameSideData *sd)
 {
 AVSphericalMapping *spherical = (AVSphericalMapping *)sd->data;
@@ -141,13 +157,14 @@ static void update_sample_stats(const uint8_t *src, int 
len, int64_t *sum, int64
 static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
 {
 AVFilterContext *ctx = inlink->dst;
+ShowInfoContext *s = ctx->priv;
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
 uint32_t plane_checksum[4] = {0}, checksum = 0;
 int64_t sum[4] = {0}, sum2[4] = {0};
 int32_t pixelcount[4] = {0};
 int i, plane, vsub = desc->log2_chroma_h;
 
-for (plane = 0; plane < 4 && frame->data[plane] && frame->linesize[plane]; 
plane++) {
+for (plane = 0; plane < 4 && s->calculate_checksums && frame->data[plane] 
&& frame->linesize[plane]; plane++) {
 uint8_t *data = frame->data[plane];
 int h = plane == 1 || plane == 2 ? AV_CEIL_RSHIFT(inlink->h, vsub) : 
inlink->h;
 int linesize = av_image_get_linesize(frame->format, frame->width, 
plane);
@@ -167,8 +184,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 
 av_log(ctx, AV_LOG_INFO,
"n:%4"PRId64" pts:%7s pts_time:%-7s pos:%9"PRId64" "
-   "fmt:%s sar:%d/%d s:%dx%d i:%c iskey:%d type:%c "
-   "checksum:%08"PRIX32" plane_checksum:[%08"PRIX32,
+   "fmt:%s sar:%d/%d s:%dx%d i:%c iskey:%d type:%c ",
inlink->frame_count_out,
av_ts2str(frame->pts), av_ts2timestr(frame->pts, 
>time_base), frame->pkt_pos,
desc->name,
@@ -177,19 +193,25 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
!frame->interlaced_frame ? 'P' : /* Progressive  */
frame->top_field_first   ? 'T' : 'B',/* Top / Bottom */
frame->key_frame,
-   av_get_picture_type_char(frame->pict_type),
-   checksum, plane_checksum[0]);
-
-for (plane = 1; plane < 4 && frame->data[plane] && frame->linesize[plane]; 
plane++)
-av_log(ctx, AV_LOG_INFO, " %08"PRIX32, plane_checksum[plane]);
-av_log(ctx, AV_LOG_INFO, "] mean:[");
-for (plane = 0; plane < 4 && frame->data[plane] && frame->linesize[plane]; 
plane++)
-av_log(ctx, AV_LOG_INFO, "%"PRId64" ", (sum[plane] + 
pixelcount[plane]/2) / pixelcount[plane]);
-av_log(ctx, AV_LOG_INFO, "\b] stdev:[");
-for (plane = 0; plane < 4 && frame->data[plane] && frame->linesize[plane]; 
plane++)
-av_log(ctx, AV_LOG_INFO, "%3.1f ",
-   sqrt((sum2[plane] - 
sum[plane]*(double)sum[plane]/pixelcount[plane])/pixelcount[plane]));
-av_log(ctx, AV_LOG_INFO, "\b]\n");
+   av_get_picture_type_char(frame->pict_type));
+
+if (s->calculate_checksums) {
+av_log(ctx, AV_LOG_INFO,
+   "checksum:%08"PRIX32" plane_checksum:[%08"PRIX32,
+   checksum, plane_checksum[0]);
+
+for (plane = 1; plane < 4 && frame->data[plane] && 
frame->linesize[plane]; plane++)
+av_log(ctx, AV_LOG_INFO, " %08"PRIX32, plane_checksum[plane]);
+av_log(ctx, AV_LOG_INFO, "] mean:[");
+for (plane = 0; plane < 4 && frame->data[plane] && 
frame->linesize[plane]; plane++)
+av_log(ctx, AV_LOG_INFO, "%"PRId64" ", (sum[plane] + 

[FFmpeg-devel] [FFmpeg-trac] #7592(avformat:new): FFmpeg download data twice

[Adrian Trzciński]

In case of data muxed in a way, that video and audio packets for the same
ptses are more than 1 sec distant (so when ff_configure_buffers_for_index
changes size of AVIOContext buffers to 2 *
biggest_distance_between_data_for_1_sec_pts) FFmpeg fetches the same data
twice from the server. This is because in fill_buffer in aviobuf.c when we
need data audio from pts x that we don't currently have in buffer, we drop
the whole buffer and download new range. But afterward, we need video from
pts x, which was in buffer already (before seek caused by audio), so we
drop buffer again and seek to this position.

The patch changes the mechanism of data reading in aviobuf.c/fill_buffer.
If data aren't in buffer new mechanism still leaves one time_unit of data
in a buffer for further seeks to the same pts but in a different stream (it
needs to be within one time_unit, it is calculated in
ff_configure_buffers_for_index).

-- 

Pozdrawiam / Regards
Adrian Trzciński
From 71cadd60a2f71d2d39bd7999e080c206291b55da Mon Sep 17 00:00:00 2001
From: Adrian Trzcinski 
Date: Tue, 4 Dec 2018 19:00:22 +0100
Subject: [PATCH] avformat/avio: fill_buffer drops less data

Signed-off-by: Adrian Trzcinski 
---
 libavformat/avio.h|  1 +
 libavformat/aviobuf.c | 21 -
 libavformat/utils.c   |  1 +
 3 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/libavformat/avio.h b/libavformat/avio.h
index 75912ce6be..c44e1c7e9c 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -225,6 +225,7 @@ typedef struct AVIOContext {
  */
 unsigned char *buffer;  /**< Start of the buffer. */
 int buffer_size;/**< Maximum buffer size */
+int time_units_in_buffer; /**< Number of time units in buffer */
 unsigned char *buf_ptr; /**< Current position in the buffer */
 unsigned char *buf_end; /**< End of the data, may be less than
  buffer+buffer_size if the read function returned
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 5a33f82950..afccc61491 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -92,6 +92,7 @@ int ffio_init_context(AVIOContext *s,
 s->buffer  = buffer;
 s->orig_buffer_size =
 s->buffer_size = buffer_size;
+s->time_units_in_buffer = 0;
 s->buf_ptr = buffer;
 s->buf_ptr_max = buffer;
 s->opaque  = opaque;
@@ -550,9 +551,19 @@ static void fill_buffer(AVIOContext *s)
 {
 int max_buffer_size = s->max_packet_size ?
   s->max_packet_size : IO_BUFFER_SIZE;
-uint8_t *dst= s->buf_end - s->buffer + max_buffer_size < s->buffer_size ?
-  s->buf_end : s->buffer;
-int len = s->buffer_size - (dst - s->buffer);
+int need_erase = !(s->buf_end - s->buffer + max_buffer_size < s->buffer_size);
+uint8_t *dst = need_erase ? s->buffer : s->buf_end;
+int len;
+
+if (need_erase && s->time_units_in_buffer > 1) {
+const int bytes_in_time_unit = (s->buf_end - s->buffer) / s->time_units_in_buffer;
+const int offset = bytes_in_time_unit * (s->time_units_in_buffer - 1);
+memcpy(s->buffer, s->buffer + offset, bytes_in_time_unit);
+dst = s->buf_end = s->buffer + bytes_in_time_unit;
+s->buf_ptr = s->buf_ptr - s->buffer < offset ? s->buffer : s->buf_ptr - offset;
+}
+
+len = s->buffer_size - (dst - s->buffer);
 
 /* can't fill the buffer without read_packet, just set EOF if appropriate */
 if (!s->read_packet && s->buf_ptr >= s->buf_end)
@@ -562,7 +573,7 @@ static void fill_buffer(AVIOContext *s)
 if (s->eof_reached)
 return;
 
-if (s->update_checksum && dst == s->buffer) {
+if (s->update_checksum && need_erase) {
 if (s->buf_end > s->checksum_ptr)
 s->checksum = s->update_checksum(s->checksum, s->checksum_ptr,
  s->buf_end - s->checksum_ptr);
@@ -571,7 +582,7 @@ static void fill_buffer(AVIOContext *s)
 
 /* make buffer smaller in case it ended up large after probing */
 if (s->read_packet && s->orig_buffer_size && s->buffer_size > s->orig_buffer_size) {
-if (dst == s->buffer && s->buf_ptr != dst) {
+if (need_erase  && s->buf_ptr != dst) {
 int ret = ffio_set_buf_size(s, s->orig_buffer_size);
 if (ret < 0)
 av_log(s, AV_LOG_WARNING, "Failed to decrease buffer size\n");
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 93e588ee1e..62deaa710b 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2138,6 +2138,7 @@ void ff_configure_buffers_for_index(AVFormatContext *s, int64_t time_tolerance)
 av_log(s, AV_LOG_VERBOSE, "Reconfiguring buffers to size %"PRId64"\n", pos_delta);
 ffio_set_buf_size(s->pb, pos_delta);
 s->pb->short_seek_threshold = FFMAX(s->pb->short_seek_threshold, pos_delta/2);
+s->pb->time_units_in_buffer = 2;
 }
 
 if (skip < (1<<23)) {
-- 

Re: [FFmpeg-devel] [PATCH] avcodec/ppc/hevcdsp: Fix build failures with powerpc-linux-gnu-gcc-4.8 with --disable-optimizations

[Michael Niedermayer]

On Tue, Dec 04, 2018 at 04:33:03PM +0100, Carl Eugen Hoyos wrote:
> 2018-12-04 16:29 GMT+01:00, Michael Niedermayer :
> > The affected functions could also be changed into macros, this is the
> > smaller change to fix it though. And avoids (probably) less readable macros
> 
> > The extra code should be optimized out when optimizations are done as all
> > values are known at build after inlining.
> 
> Shouldn't this be verified?

ive verified it with the patch below
only SIMD instructions are between the markers, so 
powerpc-linux-gnu-gcc-4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4
seems to optimize all conditional code out.
All bets are off with a different compiler though. That could be
worse or even better after the patch

But i can do more tests if you want me to test something specific ?


> This is speed-critical code, no?

Yes, and the way this code is written depends on the compiler, if the compiler
makes a mistake the function can be alot slower.
Thats one of the reasons we use nasm/yasm on x86, that always produces
the same result.

thx





[...]

diff --git a/libavcodec/ppc/hevcdsp.c b/libavcodec/ppc/hevcdsp.c
index c1d562a409..47246ed42d 100644
--- a/libavcodec/ppc/hevcdsp.c
+++ b/libavcodec/ppc/hevcdsp.c
@@ -57,13 +57,14 @@ static av_always_inline void transform4x4(vec_s16 src_01, 
vec_s16 src_23,
 o0 = vec_msums(src_13, trans4[1], zero);
 e1 = vec_msums(src_02, trans4[2], zero);
 o1 = vec_msums(src_13, trans4[3], zero);
-
+__asm volatile ("MARK\n\t");
 switch(shift) {
 case  7: add = vec_sl(vec_splat_s32(1), vec_splat_u32( 7 - 1)); break;
 case 10: add = vec_sl(vec_splat_s32(1), vec_splat_u32(10 - 1)); break;
 case 12: add = vec_sl(vec_splat_s32(1), vec_splat_u32(12 - 1)); break;
 default: abort();
 }
+__asm volatile ("MARK-E\n\t");
 
 e0 = vec_add(e0, add);
 e1 = vec_add(e1, add);
@@ -79,13 +80,14 @@ static av_always_inline void scale(vec_s32 res[4], vec_s16 
res_packed[2],
 {
 int i;
 vec_u32 v_shift;
-
+__asm volatile ("MARK\n\t");
 switch(shift) {
 case  7: v_shift = vec_splat_u32(7) ; break;
 case 10: v_shift = vec_splat_u32(10); break;
 case 12: v_shift = vec_splat_u32(12); break;
 default: abort();
 }
+__asm volatile ("MARK-E2\n\t");
 
 for (i = 0; i < 4; i++)
 res[i] = vec_sra(res[i], v_shift);

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

Re: [FFmpeg-devel] [FFmpeg-cvslog] doc: chromaprint

[Gyan Doshi]

On 04-12-2018 09:28 PM, Carl Eugen Hoyos wrote:

2018-12-04 16:51 GMT+01:00, Gyan Doshi :

On 04-12-2018 08:44 PM, Carl Eugen Hoyos wrote:

2018-12-04 15:52 GMT+01:00, Gyan Doshi :

On 04-12-2018 08:05 PM, Carl Eugen Hoyos wrote:

2018-12-04 14:53 GMT+01:00, Gyan Doshi :


My commits simply convey that into the docs - it doesn't create
a new judgement or make one where none existed.


It claims something (that may or may not be correct) instead of
leaving the responsibility with the distributor (who alone has this
responsibility).


How does that square with the license mentions for the other libraries I
listed?

e.g.

   x264 is under the GNU Public License Version 2 or later

Gyan

P.S. Mentioned removed from my commits.


Sorry for being - once again! - so unclear:
My true concern is of course the wording about libfdk. Yesterday
several people voiced their opinion that libfdk is not compatible
with the LGPL, which we both do not share. But while I will be
completely relaxed once a judge confirms that I am wrong, I
wonder how you will react...


FDK-AAC was a product developed by an entity for commercial purposes.


Yes. (how is this related?)


The odds of  worries being realized are vastly different.

But this is getting silly, so I'm out of this thread after this.


BTW, FSF deems FDK to be under a free license,


Possible.


https://www.gnu.org/licenses/license-list.html#fdk


even if remaining silent about LGPL compatibility.


Then I am even more impressed that you guarantee this
compatibility!


No guarantees made.

The sentence is,

"To the best of our knowledge, it is compatible with the LGPL."

which is copied from /LICENSE as was pointed out to you in 
http://www.ffmpeg.org/pipermail/ffmpeg-devel/2018-June/231137.html


Gyan

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

Re: [FFmpeg-devel] [PATCH] avcodec/ppc/hevcdsp: Fix build failures with powerpc-linux-gnu-gcc-4.8 with --disable-optimizations

[Carl Eugen Hoyos]

2018-12-04 16:29 GMT+01:00, Michael Niedermayer :
> The affected functions could also be changed into macros, this is the
> smaller change to fix it though. And avoids (probably) less readable macros

> The extra code should be optimized out when optimizations are done as all
> values are known at build after inlining.

Shouldn't this be verified?
This is speed-critical code, no?

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

[FFmpeg-devel] [PATCH] avcodec/ppc/hevcdsp: Fix build failures with powerpc-linux-gnu-gcc-4.8 with --disable-optimizations

[Michael Niedermayer]

The affected functions could also be changed into macros, this is the
smaller change to fix it though. And avoids (probably) less readable macros
The extra code should be optimized out when optimizations are done as all values
are known at build after inlining.

Signed-off-by: Michael Niedermayer 
---
 libavcodec/ppc/hevcdsp.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/libavcodec/ppc/hevcdsp.c b/libavcodec/ppc/hevcdsp.c
index dcae43305a..c1d562a409 100644
--- a/libavcodec/ppc/hevcdsp.c
+++ b/libavcodec/ppc/hevcdsp.c
@@ -58,7 +58,13 @@ static av_always_inline void transform4x4(vec_s16 src_01, 
vec_s16 src_23,
 e1 = vec_msums(src_02, trans4[2], zero);
 o1 = vec_msums(src_13, trans4[3], zero);
 
-add = vec_sl(vec_splat_s32(1), vec_splat_u32(shift - 1));
+switch(shift) {
+case  7: add = vec_sl(vec_splat_s32(1), vec_splat_u32( 7 - 1)); break;
+case 10: add = vec_sl(vec_splat_s32(1), vec_splat_u32(10 - 1)); break;
+case 12: add = vec_sl(vec_splat_s32(1), vec_splat_u32(12 - 1)); break;
+default: abort();
+}
+
 e0 = vec_add(e0, add);
 e1 = vec_add(e1, add);
 
@@ -72,7 +78,14 @@ static av_always_inline void scale(vec_s32 res[4], vec_s16 
res_packed[2],
const int shift)
 {
 int i;
-vec_u32 v_shift = vec_splat_u32(shift);
+vec_u32 v_shift;
+
+switch(shift) {
+case  7: v_shift = vec_splat_u32(7) ; break;
+case 10: v_shift = vec_splat_u32(10); break;
+case 12: v_shift = vec_splat_u32(12); break;
+default: abort();
+}
 
 for (i = 0; i < 4; i++)
 res[i] = vec_sra(res[i], v_shift);
-- 
2.19.2

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

Re: [FFmpeg-devel] [PATCH V2 0/3] Add libsvt HEVC encoder wrapper

[Moritz Barsnick]

On Tue, Dec 04, 2018 at 22:25:29 +0800, Jun Zhao wrote:
> This wrapper work with SVT-HEVC new_api branch, more information can get 
> from https://github.com/intel/SVT-HEVC/blob/new_api/ffmpeg_plugin/.

Is this API stable? (I have heard voices that the external library
wrapper shouldn't aim at a moving target.)

If so, can the API/version be detected (e.g. vs. the one on master), or
will the compile against a build from master just fail? (Or is this
branch used only because ffmpeg_plugin exists only on this branch?)

> For SVT-HEVC build, you can switch the branch to new_api, then run:
> ./build.sh  in the directory Build/linux.
> 
> If you want to enable the pkg-config for SVT-HEVC library, the file
> install_libsvt_hevc_plugin_ffmpeg.sh give a sample for this.
> (https://github.com/intel/SVT-HEVC/blob/new_api/ffmpeg_plugin/\
> install_libsvt_hevc_ffmpeg.sh).

But your configure modifications don't use it. Will the pkgconfig file
go upstream/master any time soon?

>   lavc/svt_hevc: add libsvt hevc encoder wrapper.
>   Changelog: Add new entry for svt-hevc encoder

I still recommend to merge these two, which is common practice.

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

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Jean-Baptiste Kempf]

Helllo,

On Tue, 4 Dec 2018, at 15:00, Martin Vignali wrote:
> 1 :
> Removing features used by people which doesn't respect the licence, seems a
> very bad thing.

I disagree with you.
Helping people violating open source licenses is not a good idea.

> 3 - Need a proper definition, and a dedicated discussion. To avoid
> including code that it's not conform to the global policy of this project.
> Reading this thread, it's seems like there is lot of interpretation about
> acceptable and non acceptable not opensource part.

The thing is, the license is the license, and there are a lot of explanations 
from FSF, FSFE, SFLC, and sooo many others.

> - ok for not open source part from os
> - ok for not open source part for "hardware thing", because we can think
> it's like os thing !

Yes, and this is quite documented, as part of all the GPL family of licenses, 
as part of "System Libraries".

> - ok from not open source part, if it's useful ? or not ?
> What definition of useful ? (and everything related to broadcast is not
> useless, just because not everyone use it !)

You cannot define usefulness easily.

> And yes, it's better to have full opensource ndi support, instead of the
> current situation.
> But it's not a reason to remove features for users.

But then, you will get absolutely all the integration from ALL the various 
non-open source multimedia libraries, because it is useful to someone. 
Including shims for Adobe, Dolby and others.
And what is the incentive to do open source alternatives?


-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] doc: chromaprint

[Gyan Doshi]

On 04-12-2018 08:05 PM, Carl Eugen Hoyos wrote:

2018-12-04 14:53 GMT+01:00, Gyan Doshi :


My commits simply convey that into the docs - it doesn't create
a new judgement or make one where none existed.


It claims something (that may or may not be correct) instead of
leaving the responsibility with the distributor (who alone has this
responsibility).


How does that square with the license mentions for the other libraries I 
listed?


e.g.

x264 is under the GNU Public License Version 2 or later

Gyan

P.S. Mentioned removed from my commits.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] doc: chromaprint

[Carl Eugen Hoyos]

2018-12-04 14:53 GMT+01:00, Gyan Doshi :
> On 04-12-2018 07:10 PM, Carl Eugen Hoyos wrote:
>> 2018-12-04 14:32 GMT+01:00, Gyan Doshi :
>>> On 04-12-2018 06:38 PM, Carl Eugen Hoyos wrote:
 2018-12-04 13:53 GMT+01:00, Gyan Doshi :
> On 04-12-2018 06:15 PM, Carl Eugen Hoyos wrote:
>> 2018-12-04 12:10 GMT+01:00, Gyan Doshi :
>>
>>> +@section Chromaprint
>>> +
>>> +FFmpeg can make use of the Chromaprint library for generating audio
>>> fingerprints.
>>
>>> +It is licensed under LGPL version 2.1.
>>
>> No other library is described like this.
>> Why are you adding legal statements that are unneeded?
>
> I see licensing notes for libxavs2, libdavs2, "OpenCORE, VisualOn, and
> Fraunhofer libraries", x264 & x265.
>
> Is the situation for chromaprint and GME different than for the libs
> above

 Yes, very much so.
>>>
>>> Please explain.
>>
>> The license is only mentioned for projects that are not LGPL-compatible,
>> it is unneeded to mention LGPL-compatibility.
>
> OK, so my licensing mentions are superfluous. But where's the risk?

> The FFmpeg project has to stake a position on licensing of all components,
> internal or external, for the sake of configuration.

Why do we "have" to take a position?
Our configure script intends to help people not violating our copyright,
it does not claim any particular position and it certainly doesn't claim
some library is compatible with some software license.
Otherwise, we would already be in serious trouble as configure in
past did not protest using libraries that are not compatible with the
GPL for binaries based on FFmpeg.

> My commits simply convey that into the docs - it doesn't create
> a new judgement or make one where none existed.

It claims something (that may or may not be correct) instead of
leaving the responsibility with the distributor (who alone has this
responsibility).

> If you continue to feel strongly about this, I'll remove those
> sentences. But for the sake of a sane and consistent policy, can you
> provide a positive reason why their removal is needed?

I feel very strongly about not giving legal advice (where I live, this
is not allowed) and you are continually giving legal advice. Even if
you are a lawyer (or otherwise entitled), I don't think it is a good
idea to guarantee that some libraries are compatible with the LGPL.

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

[FFmpeg-devel] [PATCH V2 1/3] lavc/svt_hevc: add libsvt hevc encoder wrapper.

[Jun Zhao]

base on patch by Huang, Zhengxu from https://github.com/intel/SVT-HEVC

Signed-off-by: Huang, Zhengxu 
Signed-off-by: hassene 
Signed-off-by: Jun Zhao 
---
 configure|4 +
 libavcodec/Makefile  |1 +
 libavcodec/allcodecs.c   |1 +
 libavcodec/libsvt_hevc.c |  440 ++
 4 files changed, 446 insertions(+), 0 deletions(-)
 create mode 100644 libavcodec/libsvt_hevc.c

diff --git a/configure b/configure
index 642c13d..c7ac4d1 100755
--- a/configure
+++ b/configure
@@ -263,6 +263,7 @@ External library support:
   --enable-libspeexenable Speex de/encoding via libspeex [no]
   --enable-libsrt  enable Haivision SRT protocol via libsrt [no]
   --enable-libssh  enable SFTP protocol via libssh [no]
+  --enable-libsvt  enable HEVC encoding via svt [no]
   --enable-libtensorflow   enable TensorFlow as a DNN module backend
for DNN based filters like sr [no]
   --enable-libtesseractenable Tesseract, needed for ocr filter [no]
@@ -1665,6 +1666,7 @@ EXTERNAL_LIBRARY_GPL_LIST="
 libcdio
 libdavs2
 librubberband
+libsvt
 libvidstab
 libx264
 libx265
@@ -3130,6 +3132,7 @@ libshine_encoder_select="audio_frame_queue"
 libspeex_decoder_deps="libspeex"
 libspeex_encoder_deps="libspeex"
 libspeex_encoder_select="audio_frame_queue"
+libsvt_hevc_encoder_deps="libsvt"
 libtheora_encoder_deps="libtheora"
 libtwolame_encoder_deps="libtwolame"
 libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
@@ -6148,6 +6151,7 @@ enabled libsoxr   && require libsoxr soxr.h 
soxr_create -lsoxr
 enabled libssh&& require_pkg_config libssh libssh libssh/sftp.h 
sftp_init
 enabled libspeex  && require_pkg_config libspeex speex speex/speex.h 
speex_decoder_init
 enabled libsrt&& require_pkg_config libsrt "srt >= 1.3.0" 
srt/srt.h srt_socket
+enabled libsvt&& require_pkg_config libsvt  svt  EbApi.h 
EbInitHandle
 enabled libtensorflow && require libtensorflow tensorflow/c/c_api.h 
TF_Version -ltensorflow
 enabled libtesseract  && require_pkg_config libtesseract tesseract 
tesseract/capi.h TessBaseAPICreate
 enabled libtheora && require libtheora theora/theoraenc.h th_info_init 
-ltheoraenc -ltheoradec -logg
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 5feadac..1a2506a 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -983,6 +983,7 @@ OBJS-$(CONFIG_LIBOPUS_ENCODER)+= libopusenc.o 
libopus.o \
 OBJS-$(CONFIG_LIBSHINE_ENCODER)   += libshine.o
 OBJS-$(CONFIG_LIBSPEEX_DECODER)   += libspeexdec.o
 OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
+OBJS-$(CONFIG_LIBSVT_HEVC_ENCODER)+= libsvt_hevc.o
 OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
 OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
 OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) += libvo-amrwbenc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index d70646e..094ee3c 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -699,6 +699,7 @@ extern AVCodec ff_librsvg_decoder;
 extern AVCodec ff_libshine_encoder;
 extern AVCodec ff_libspeex_encoder;
 extern AVCodec ff_libspeex_decoder;
+extern AVCodec ff_libsvt_hevc_encoder;
 extern AVCodec ff_libtheora_encoder;
 extern AVCodec ff_libtwolame_encoder;
 extern AVCodec ff_libvo_amrwbenc_encoder;
diff --git a/libavcodec/libsvt_hevc.c b/libavcodec/libsvt_hevc.c
new file mode 100644
index 000..6ec9e16
--- /dev/null
+++ b/libavcodec/libsvt_hevc.c
@@ -0,0 +1,440 @@
+/*
+* Scalable Video Technology for HEVC encoder library plugin
+*
+* Copyright (c) 2018 Intel Corporation
+*
+* This program is free software; you can redistribute it and/or
+* modify it under the terms of the GNU Lesser General Public
+* License as published by the Free Software Foundation; either
+* version 2.1 of the License, or (at your option) any later version.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+* Lesser General Public License for more details.
+*
+* You should have received a copy of the GNU Lesser General Public
+* License along with this program; if not, write to the Free Software
+* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+*/
+
+#include "EbErrorCodes.h"
+#include "EbTime.h"
+#include "EbApi.h"
+
+#include "libavutil/common.h"
+#include "libavutil/frame.h"
+#include "libavutil/opt.h"
+
+#include "internal.h"
+#include "avcodec.h"
+
+typedef struct SvtEncoder {
+EB_H265_ENC_CONFIGURATION   enc_params;
+EB_COMPONENTTYPE*svt_handle;
+EB_BUFFERHEADERTYPE *in_buf;
+EB_BUFFERHEADERTYPE *out_buf;
+int raw_size;
+} SvtEncoder;
+
+typedef 

[FFmpeg-devel] [PATCH V2 0/3] Add libsvt HEVC encoder wrapper

[Jun Zhao]

The Scalable Video Technology for HEVC Encoder (SVT-HEVC Encoder) is an 
HEVC-compliant encoder library core that achieves excellent density-quality 
tradeoffs, and is highly optimized for Intel Xeon Scalable Processor and 
Xeon D processors. Intel open source SVT-HEVC encoder in: 
https://github.com/intel/SVT-HEVC.

This wrapper work with SVT-HEVC new_api branch, more information can get 
from https://github.com/intel/SVT-HEVC/blob/new_api/ffmpeg_plugin/.

For SVT-HEVC build, you can switch the branch to new_api, then run:
./build.sh  in the directory Build/linux.

If you want to enable the pkg-config for SVT-HEVC library, the file
install_libsvt_hevc_plugin_ffmpeg.sh give a sample for this.
(https://github.com/intel/SVT-HEVC/blob/new_api/ffmpeg_plugin/\
install_libsvt_hevc_ffmpeg.sh).

This patches based on Zhengxu, huang/hassene's hard work.

V2: - Refine the error handle (Tks Steven/James's review).
- Add docs part (Tks Steven/Moritz's review).
- Use named parameters in options.
- Follow FFmpeg coding style and Changelog.

V1: - Add libsvt hevc encoder wrapper and a Changelog entry.

Jun Zhao (3):
  lavc/svt_hevc: add libsvt hevc encoder wrapper.
  doc: Add libsvt_hevc encoder docs
  Changelog: Add new entry for svt-hevc encoder

 Changelog|1 +
 configure|4 +
 doc/encoders.texi|   98 ++
 doc/general.texi |8 +
 libavcodec/Makefile  |1 +
 libavcodec/allcodecs.c   |1 +
 libavcodec/libsvt_hevc.c |  440 ++
 7 files changed, 553 insertions(+), 0 deletions(-)
 create mode 100644 libavcodec/libsvt_hevc.c

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

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Carl Eugen Hoyos]

2018-12-04 15:00 GMT+01:00, Martin Vignali :
> There is a mix of several discussion in this thread, which need to be
> discuss separately.
>
> 1 - Licence violation on a build.

[...]

> 1 :
> Doesn't really understand, how this licence violation can be fix in
> modifying the source code.

Where was this claimed / who thinks so?

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

[FFmpeg-devel] [PATCH V2 3/3] Changelog: Add new entry for svt-hevc encoder

[Jun Zhao]

Signed-off-by: Huang, Zhengxu 
Signed-off-by: hassene 
Signed-off-by: Jun Zhao 
---
 Changelog |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/Changelog b/Changelog
index 1f53ff4..cef444d 100644
--- a/Changelog
+++ b/Changelog
@@ -10,6 +10,7 @@ version :
 - truehd_core bitstream filter
 - dhav demuxer
 - PCM-DVD encoder
+- add SVT(Scalable Video Technology) HEVC encoder
 
 
 version 4.1:
-- 
1.7.1

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

[FFmpeg-devel] [PATCH V2 2/3] doc: Add libsvt_hevc encoder docs

[Jun Zhao]

Signed-off-by: Jun Zhao 
Signed-off-by: Huang, Zhengxu 
Signed-off-by: hassene 
---
 doc/encoders.texi |   98 +
 doc/general.texi  |8 
 2 files changed, 106 insertions(+), 0 deletions(-)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 4db7764..33efbef 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1566,6 +1566,104 @@ Set maximum NAL size in bytes.
 Allow skipping frames to hit the target bitrate if set to 1.
 @end table
 
+@section libsvt_hevc
+
+Intel Scalable Video Technology HEVC encoder wrapper.
+
+This encoder requires the presence of the headers and
+library during configuration. You need to explicitly configure the
+build with @code{--enable-libsvt}. The library is detected using
+@command{pkg-config}.
+
+For more information about the library see
+@url{https://github.com/intel/SVT-HEVC.git}.
+
+@subsection Options
+
+The following FFmpeg global options affect the configurations of the
+libsvt_hevc encoder.
+
+@table @option
+@item vui
+Enables or disables the vui structure in the HEVC elementary
+bitstream. 0 = Off, 1 = On
+
+@item hielevel
+Set hierarchical levels. Can assume one of the following possible values:
+
+@table @samp
+@item flat
+none hierarchy level
+@item 2level
+2-level hierarchy
+@item 3level
+3-level hierarchy
+@item 4level
+4-level hierarchy
+@end table
+
+@item la_depth
+Set look-ahead depth, depending on bit rate control mode @option{rc}, When
+bit rate control mode is set to vbr it's best to set this parameter to be
+equal to the Intra period value (such is the default set by the encoder),
+when cqp is chosen, then a look ahead is recommended.
+
+@item intra_ref_type
+Set intra refesh type. Can assume one of the following possible values:
+
+@table @samp
+@item cra
+open group of pictures
+@item idr
+closed group of pictures
+@end table
+
+@item preset
+A preset defining the quality vs density tradeoff point that the
+encoding is to be performed at.(e.g. 0 is the highest quality mode,
+12 is the highest density mode).
+
+@item profile (@emph{profile})
+Set profile restrictions. Can assume one of the following possible values:
+
+@table @samp
+@item main
+main profile
+@item main10
+main10 profile
+@end table
+
+@item rc
+Set bit rate control mode. Can assume one of the following possible values:
+
+@table @samp
+@item cqp
+cqp mode
+@item vbr
+vbr mode
+@end table
+
+@item qp
+Initial quantization parameter for the intra pictures used when
+@option{rc} is cqp mode.
+
+@item sc_detection
+Enables or disables the scene change detection algorithm.
+
+@item tune
+Set quality mode. Can assume one of the following possible values:
+
+@table @samp
+@item sq
+subjective quality mode
+@item oq
+objective quality mode
+@end table
+
+@item bl_mode
+Enables or disables Random Access Prediction.
+@end table
+
 @section libtheora
 
 libtheora Theora encoder wrapper.
diff --git a/doc/general.texi b/doc/general.texi
index cfab63f..822cf46 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -191,6 +191,14 @@ constrained baseline profile and CABAC.) Using it is 
mostly useful for
 testing and for taking advantage of Cisco's patent portfolio license
 (@url{http://www.openh264.org/BINARY_LICENSE.txt}).
 
+@section SVT-HEVC
+
+FFmpeg can make use of the SVT-HEVC library for HEVC encoding.
+
+Go to @url{https://github.com/intel/SVT-HEVC.git} and follow the instructions
+for installing the library. Then pass @code{--enable-libsvt} to configure to
+enable it.
+
 @section x264
 
 FFmpeg can make use of the x264 library for H.264 encoding.
-- 
1.7.1

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

Re: [FFmpeg-devel] avcodec/proresaw_enc : improvment (vendor and color properties, 4444Xq)

[Martin Vignali]

>
> LGTM
>
> thanks
>
> [...]
> --
> Michael
>

Pushed, thanks.

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] libswscale: Adds conversions from/to float gray format.

[Carl Eugen Hoyos]

2018-08-14 18:24 GMT+02:00, Sergey Lavrushkin :
> ffmpeg | branch: master | Sergey Lavrushkin  | Fri Aug  3
> 18:06:50 2018 +0300| [582bc5a348f5cd12b6ad3be4ecbee71bc082ea32] | committer:
> Michael Niedermayer
>
> libswscale: Adds conversions from/to float gray format.

This breaks fate on x86_32 with "--disable-sse", found by Michael Kostylev:
http://fate.xffm.org/report.cgi?slot=x86_32-linux-gcc-nosse=20181204051956

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

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Martin Vignali]

There is a mix of several discussion in this thread, which need to be
discuss separately.

1 - Licence violation on a build.
2 - Opinion on Newtek behaviour
3 - Inclusion of non open source part
4 - Removal of libndi device

1 :
Doesn't really understand, how this licence violation can be fix in
modifying the source code.
Removing features used by people which doesn't respect the licence, seems a
very bad thing.

2 - Nothing to do in this mailing list. Except trying to influence
technical aspect, with emotional stuff.
"It appears to me that NewTek abused our willingness..."
or "Newtek is a big bully against open source developers, threatening to
sue."
is not really what we can call "a technical argument".
The choice of adding or removing a feature, is (i hope) not link, to the
behaviour of the original creator.

3 - Need a proper definition, and a dedicated discussion. To avoid
including code that it's not conform to the global policy of this project.
Reading this thread, it's seems like there is lot of interpretation about
acceptable and non acceptable not opensource part.
- ok for not open source part from os
- ok for not open source part for "hardware thing", because we can think
it's like os thing !
- ok from not open source part, if it's useful ? or not ?
What definition of useful ? (and everything related to broadcast is not
useless, just because not everyone use it !)

4 - libndi device is part of ffmpeg for now. Removing it without at least a
deprecation period, will just break by surprise every working tools based
on that
even for user who respect the terms of the licence and build themselves
ffmpeg with this support (like mention by Marton Balint).
Bad message send to people who respect the licence ! :-)

And yes, it's better to have full opensource ndi support, instead of the
current situation.
But it's not a reason to remove features for users.


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

Re: [FFmpeg-devel] [FFmpeg-cvslog] doc: chromaprint

[Gyan Doshi]

On 04-12-2018 07:10 PM, Carl Eugen Hoyos wrote:

2018-12-04 14:32 GMT+01:00, Gyan Doshi :

On 04-12-2018 06:38 PM, Carl Eugen Hoyos wrote:

2018-12-04 13:53 GMT+01:00, Gyan Doshi :

On 04-12-2018 06:15 PM, Carl Eugen Hoyos wrote:

2018-12-04 12:10 GMT+01:00, Gyan Doshi :


+@section Chromaprint
+
+FFmpeg can make use of the Chromaprint library for generating audio
fingerprints.



+It is licensed under LGPL version 2.1.


No other library is described like this.
Why are you adding legal statements that are unneeded?


I see licensing notes for libxavs2, libdavs2, "OpenCORE, VisualOn, and
Fraunhofer libraries", x264 & x265.

Is the situation for chromaprint and GME different than for the libs
above


Yes, very much so.


Please explain.


The license is only mentioned for projects that are not LGPL-compatible,
it is unneeded to mention LGPL-compatibility.


OK, so my licensing mentions are superfluous. But where's the risk? The 
FFmpeg project has to stake a position on licensing of all components, 
internal or external, for the sake of configuration. My commits simply 
convey that into the docs - it doesn't create a new judgement or make 
one where none existed.


If you continue to feel strongly about this, I'll remove those 
sentences. But for the sake of a sane and consistent policy, can you 
provide a positive reason why their removal is needed?


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

Re: [FFmpeg-devel] [FFmpeg-cvslog] doc: chromaprint

[Paul B Mahol]

On 12/4/18, Carl Eugen Hoyos  wrote:
> 2018-12-04 14:32 GMT+01:00, Gyan Doshi :
>> On 04-12-2018 06:38 PM, Carl Eugen Hoyos wrote:
>>> 2018-12-04 13:53 GMT+01:00, Gyan Doshi :
 On 04-12-2018 06:15 PM, Carl Eugen Hoyos wrote:
> 2018-12-04 12:10 GMT+01:00, Gyan Doshi :
>
>> +@section Chromaprint
>> +
>> +FFmpeg can make use of the Chromaprint library for generating audio
>> fingerprints.
>
>> +It is licensed under LGPL version 2.1.
>
> No other library is described like this.
> Why are you adding legal statements that are unneeded?

 I see licensing notes for libxavs2, libdavs2, "OpenCORE, VisualOn, and
 Fraunhofer libraries", x264 & x265.

 Is the situation for chromaprint and GME different than for the libs
 above
>>>
>>> Yes, very much so.
>>
>> Please explain.
>
> The license is only mentioned for projects that are not LGPL-compatible,
> it is unneeded to mention LGPL-compatibility.
>
> I start to wonder how good your insurance is...

This is yet another attack from you. How much we need to tolerate this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] doc: chromaprint

[Carl Eugen Hoyos]

2018-12-04 14:32 GMT+01:00, Gyan Doshi :
> On 04-12-2018 06:38 PM, Carl Eugen Hoyos wrote:
>> 2018-12-04 13:53 GMT+01:00, Gyan Doshi :
>>> On 04-12-2018 06:15 PM, Carl Eugen Hoyos wrote:
 2018-12-04 12:10 GMT+01:00, Gyan Doshi :

> +@section Chromaprint
> +
> +FFmpeg can make use of the Chromaprint library for generating audio
> fingerprints.

> +It is licensed under LGPL version 2.1.

 No other library is described like this.
 Why are you adding legal statements that are unneeded?
>>>
>>> I see licensing notes for libxavs2, libdavs2, "OpenCORE, VisualOn, and
>>> Fraunhofer libraries", x264 & x265.
>>>
>>> Is the situation for chromaprint and GME different than for the libs
>>> above
>>
>> Yes, very much so.
>
> Please explain.

The license is only mentioned for projects that are not LGPL-compatible,
it is unneeded to mention LGPL-compatibility.

I start to wonder how good your insurance is...

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] doc: chromaprint

[Gyan Doshi]

On 04-12-2018 06:38 PM, Carl Eugen Hoyos wrote:

2018-12-04 13:53 GMT+01:00, Gyan Doshi :

On 04-12-2018 06:15 PM, Carl Eugen Hoyos wrote:

2018-12-04 12:10 GMT+01:00, Gyan Doshi :


+@section Chromaprint
+
+FFmpeg can make use of the Chromaprint library for generating audio
fingerprints.



+It is licensed under LGPL version 2.1.


No other library is described like this.
Why are you adding legal statements that are unneeded?


I see licensing notes for libxavs2, libdavs2, "OpenCORE, VisualOn, and
Fraunhofer libraries", x264 & x265.

Is the situation for chromaprint and GME different than for the libs
above


Yes, very much so.


Please explain.

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

Re: [FFmpeg-devel] [PATCH] swscale/ppc: Move VSX-using code to its own file

[Michael Niedermayer]

On Tue, Dec 04, 2018 at 11:00:34AM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Tuesday, 04 December 2018 at 08:10, Lauri Kasanen wrote:
> > On Tue, 4 Dec 2018 03:21:30 +0100
> > Michael Niedermayer  wrote:
> > 
> > > On Mon, Dec 03, 2018 at 09:24:47AM +0200, Lauri Kasanen wrote:
> > > > Also ping on "swscale/output: VSX-optimize
> > > > nbps yuv2plane1".
> > > 
> > > This IIUC has not been tested on BE yet
> > > 
> > > my ppc emulation setup is a bit broken and my ppc hw ive not tried using
> > > since years and it was not in good shape last i used it.
> > > So i cant just quickly test this ...
> > 
> > Raptor offers free POWER9 VMs to open source projects. Since you're the
> > leader of ffmpeg, if you asked, I'm sure they'd give one or two for
> > ffmpeg build and fate testing.
> > 
> > Ref
> > https://mobile.twitter.com/RaptorCompSys/status/1067018060777832449?p=v
> > https://mobile.twitter.com/RaptorCompSys/status/1067029086273486848?p=v
> > 
> > "We offer free access to cloud VPS for libre software projects in
> > partnership with @Integricloud, would that help?"
> > 
> > "Contact sa...@integricloud.com and tell them what you want to use a
> > VPS or two for. They will generally grant access to the resources."
> > 
> > (I'm developing on a POWER8 VM intended for devs, but ordered a
> > Blackbird from the cyber monday sale ;))
> 
> Red Hat also offers Power 8 VMs, both BE and LE, to open source projects:
> http://research.redhat.com/powerlinux-openpower-development-hosting/

these are more suggestions than i expected :)
but i just got cross build working again and i also just eliminated a
mysterious ld.so related segfault
ATM iam re rerunning fate with a freshly rebuilt qemu
(the past one had an issue with altivec)

so maybe ill be able to build and test ppc BE locally soon ... or maybe not;)

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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


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

Re: [FFmpeg-devel] [FFmpeg-cvslog] doc: chromaprint

[Carl Eugen Hoyos]

2018-12-04 13:53 GMT+01:00, Gyan Doshi :
> On 04-12-2018 06:15 PM, Carl Eugen Hoyos wrote:
>> 2018-12-04 12:10 GMT+01:00, Gyan Doshi :
>>
>>> +@section Chromaprint
>>> +
>>> +FFmpeg can make use of the Chromaprint library for generating audio
>>> fingerprints.
>>
>>> +It is licensed under LGPL version 2.1.
>>
>> No other library is described like this.
>> Why are you adding legal statements that are unneeded?
>
> I see licensing notes for libxavs2, libdavs2, "OpenCORE, VisualOn, and
> Fraunhofer libraries", x264 & x265.
>
> Is the situation for chromaprint and GME different than for the libs
> above

Yes, very much so.

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] doc: chromaprint

[Gyan Doshi]

On 04-12-2018 06:15 PM, Carl Eugen Hoyos wrote:

2018-12-04 12:10 GMT+01:00, Gyan Doshi :


+@section Chromaprint
+
+FFmpeg can make use of the Chromaprint library for generating audio
fingerprints.



+It is licensed under LGPL version 2.1.


No other library is described like this.
Why are you adding legal statements that are unneeded?


I see licensing notes for libxavs2, libdavs2, "OpenCORE, VisualOn, and 
Fraunhofer libraries", x264 & x265.


Is the situation for chromaprint and GME different than for the libs 
above - other than the specific license?


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

Re: [FFmpeg-devel] [FFmpeg-cvslog] doc: libgme

[Carl Eugen Hoyos]

2018-12-04 13:38 GMT+01:00, Gyan Doshi :

> +@section Game Music Emu
> +
> +FFmpeg can make use of the Game Music Emu library to read audio from
> supported video game
> +music file formats.

> It is licensed under LGPL version 2.1.

Why?

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] doc: chromaprint

[Carl Eugen Hoyos]

2018-12-04 12:10 GMT+01:00, Gyan Doshi :

> +@section Chromaprint
> +
> +FFmpeg can make use of the Chromaprint library for generating audio
> fingerprints.

> +It is licensed under LGPL version 2.1.

No other library is described like this.
Why are you adding legal statements that are unneeded?

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

[FFmpeg-devel] [PATCH v2 1/2] lavf: Add general API for IO buffer synchronization.

[Andrey Semashev]

This commit adds a new set of functions to avio and url subsystems, which
allow users to invoke IO buffer synchronization with the underlying media.
The most obvious target for this extension if the filesystem streams. Invoking
IO synchronization allows user applications to ensure that all written content
has reached the filesystem on the media and can be observed by other processes.

The public API for this is avio_sync() function, which can be called on
AVIOContext. The internal, lower layer API is ffurl_sync(), which works
directly on the underlying URLContext. URLContext backends can add support for
this new API by setting the sync handler to the new url_sync member of
URLProtocol. When no handler is set then the sync operation is a no-op.
Users can distinguish this case from the successful completion by the result
code AVIO_SYNC_NOT_SUPPORTED, which is also considered a successful result
(i.e. >0).
---
 libavformat/avio.c|  7 +++
 libavformat/avio.h| 33 +
 libavformat/aviobuf.c | 17 +
 libavformat/url.h | 13 +
 4 files changed, 70 insertions(+)

diff --git a/libavformat/avio.c b/libavformat/avio.c
index 663789ec02..662d4ed971 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -623,6 +623,13 @@ int64_t ffurl_size(URLContext *h)
 return size;
 }
 
+int ffurl_sync(URLContext *h)
+{
+if (h->prot->url_sync)
+return h->prot->url_sync(h);
+return AVIO_SYNC_NOT_SUPPORTED;
+}
+
 int ffurl_get_file_handle(URLContext *h)
 {
 if (!h || !h->prot || !h->prot->url_get_file_handle)
diff --git a/libavformat/avio.h b/libavformat/avio.h
index 75912ce6be..403ee0fc7b 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -349,6 +349,15 @@ typedef struct AVIOContext {
  * Try to buffer at least this amount of data before flushing it
  */
 int min_packet_size;
+
+/**
+ * A callback for synchronizing buffers with the media state.
+ *
+ * @return AVIO_SYNC_SUCCESS on success, AVIO_SYNC_NOT_SUPPORTED if
+ * the operation is not supported and ignored, an AVERROR < 0
+ * on error.
+ */
+int (*sync)(void *opaque);
 } AVIOContext;
 
 /**
@@ -586,6 +595,30 @@ int avio_printf(AVIOContext *s, const char *fmt, ...) 
av_printf_format(2, 3);
  */
 void avio_flush(AVIOContext *s);
 
+/**
+ * Indicates that the sync operation has been carried out successfully
+ */
+#define AVIO_SYNC_SUCCESS 0
+
+/**
+ * Indicates that the sync operation is not supported by the underlying
+ * resource and has been ignored
+ */
+#define AVIO_SYNC_NOT_SUPPORTED 1
+
+/**
+ * Flush internal buffers and ensure the synchronized state of the
+ * resource associated with the context s. This call may be expensive.
+ * Not all resources support syncing, this operation is a no-op
+ * if sync is not supported or needed.
+ * This function can only be used if s was opened by avio_open().
+ *
+ * @return AVIO_SYNC_SUCCESS on success, AVIO_SYNC_NOT_SUPPORTED if
+ * the operation is a not supported and ignored, an AVERROR < 0
+ * on error.
+ */
+int avio_sync(AVIOContext *s);
+
 /**
  * Read size bytes from AVIOContext into buf.
  * @return number of bytes read or AVERROR
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 5a33f82950..c2aca7c6af 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -243,6 +243,14 @@ void avio_flush(AVIOContext *s)
 avio_seek(s, seekback, SEEK_CUR);
 }
 
+int avio_sync(AVIOContext *s)
+{
+avio_flush(s);
+if (s->sync)
+return s->sync(s->opaque);
+return AVIO_SYNC_NOT_SUPPORTED;
+}
+
 int64_t avio_seek(AVIOContext *s, int64_t offset, int whence)
 {
 int64_t offset1;
@@ -978,6 +986,12 @@ static int64_t io_read_seek(void *opaque, int 
stream_index, int64_t timestamp, i
 return internal->h->prot->url_read_seek(internal->h, stream_index, 
timestamp, flags);
 }
 
+static int io_sync(void *opaque)
+{
+AVIOInternal *internal = opaque;
+return ffurl_sync(internal->h);
+}
+
 int ffio_fdopen(AVIOContext **s, URLContext *h)
 {
 AVIOInternal *internal = NULL;
@@ -1026,6 +1040,9 @@ int ffio_fdopen(AVIOContext **s, URLContext *h)
 
 if (h->prot->url_read_seek)
 (*s)->seekable |= AVIO_SEEKABLE_TIME;
+
+if (h->prot->url_sync)
+(*s)->sync = io_sync;
 }
 (*s)->short_seek_get = io_short_seek;
 (*s)->av_class = _avio_class;
diff --git a/libavformat/url.h b/libavformat/url.h
index 4750bfff82..d032b45b65 100644
--- a/libavformat/url.h
+++ b/libavformat/url.h
@@ -97,6 +97,7 @@ typedef struct URLProtocol {
 int (*url_delete)(URLContext *h);
 int (*url_move)(URLContext *h_src, URLContext *h_dst);
 const char *default_whitelist;
+int (*url_sync)(URLContext *h);
 } URLProtocol;
 
 /**
@@ -228,6 +229,18 @@ int64_t ffurl_seek(URLContext *h, int64_t pos, int whence);
 int ffurl_closep(URLContext **h);
 int ffurl_close(URLContext *h);
 
+/**
+ * 

Re: [FFmpeg-devel] [PATCH] lavf/dashenc: Remove global_sidx from movenc params for live streaming.

[Andrey Semashev]

On 12/4/18 11:49 AM, Jeyapal, Karthick wrote:


On 11/29/18 8:28 PM, Andrey Semashev wrote:

On 11/28/18 7:25 PM, Jeyapal, Karthick wrote:


On 11/28/18 4:41 PM, Andrey Semashev wrote:

The global_sidx flag causes errors like the following in movenc when media
segment removal is enabled via windos_size or remove_at_exit:

Non-consecutive fragments, writing incorrect sidx
Unable to re-open  output file for the second pass (faststart)

Removing global_sidx flag adds sidx atom to each moof fragment adding 
significant bitrate overhead.
Instead I have submitted a patch to handle this case cleanly in movenc. 
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-November/236873.html
Please try the above patch and let me know if that will work for you.


Yes, that patch seems to fix the errors. Thanks.

Hi Andrey,

That patch was not pushed due to some objections. I have submitted a new patch 
set addressing it.
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/237121.html
Could you please try the above patchset and confirm if everything works as 
expected?


I will test the final version. Though, if it doesn't change the effect 
since the last version then it should work as well.

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

[FFmpeg-devel] [PATCH v2 2/2] lavf/file: Add support for file syncing.

[Andrey Semashev]

This commit adds support for IO synchronization API to the file backend.
---
 libavformat/file.c   | 11 +++
 libavformat/os_support.h |  2 ++
 2 files changed, 13 insertions(+)

diff --git a/libavformat/file.c b/libavformat/file.c
index 1d321c4205..58fd55b928 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -254,6 +254,16 @@ static int64_t file_seek(URLContext *h, int64_t pos, int 
whence)
 return ret < 0 ? AVERROR(errno) : ret;
 }
 
+static int file_sync(URLContext *h)
+{
+if (h->flags & AVIO_FLAG_WRITE) {
+FileContext *c = h->priv_data;
+if (fsync(c->fd) < 0)
+return AVERROR(errno);
+}
+return 0;
+}
+
 static int file_close(URLContext *h)
 {
 FileContext *c = h->priv_data;
@@ -353,6 +363,7 @@ const URLProtocol ff_file_protocol = {
 .url_close   = file_close,
 .url_get_file_handle = file_get_handle,
 .url_check   = file_check,
+.url_sync= file_sync,
 .url_delete  = file_delete,
 .url_move= file_move,
 .priv_data_size  = sizeof(FileContext),
diff --git a/libavformat/os_support.h b/libavformat/os_support.h
index 7a56dc9a7c..1864763cb1 100644
--- a/libavformat/os_support.h
+++ b/libavformat/os_support.h
@@ -93,6 +93,8 @@ static inline int is_dos_path(const char *path)
 #ifndef S_IWUSR
 #define S_IWUSR S_IWRITE
 #endif
+
+#define fsync(fd) _commit((fd))
 #endif
 
 #if CONFIG_NETWORK
-- 
2.19.1

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/movenc: Added an option to disable SIDX atom

[Tobias Rapp]

On 04.12.2018 09:41, Karthick J wrote:

---
  doc/muxers.texi  | 2 ++
  libavformat/movenc.c | 7 +--
  libavformat/movenc.h | 1 +
  3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index f1cc6f5fee..6ca27b04a3 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1325,6 +1325,8 @@ more efficient), but with this option set, the muxer 
writes one moof/mdat
  pair for each track, making it easier to separate tracks.
  
  This option is implicitly set when writing ismv (Smooth Streaming) files.

+@item -movflags no_sidx
+Don't write sidx atom.
  @item -movflags faststart
  Run a second pass moving the index (moov atom) to the beginning of the file.
  This operation can take a while, and will not work in various situations such


What about naming the option "skip_sidx" for symmetry with the existing 
"skip_trailer"? Just my personal thought.


Also it might be worth mentioning in the docs how global_sidx and the 
new option correlate (which one is preferred if both exists, or is it an 
error to specify both?).


>
> [...]
>

diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index fe605d1ad2..ee6749bce2 100644
--- a/libavformat/movenc.h
+++ b/libavformat/movenc.h
@@ -257,6 +257,7 @@ typedef struct MOVMuxContext {
  #define FF_MOV_FLAG_SKIP_TRAILER  (1 << 18)
  #define FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS  (1 << 19)
  #define FF_MOV_FLAG_FRAG_EVERY_FRAME  (1 << 20)
+#define FF_MOV_FLAG_NO_SIDX   (1 << 21)
  
  int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt);
  



Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] swscale/ppc: Move VSX-using code to its own file

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 04 December 2018 at 08:10, Lauri Kasanen wrote:
> On Tue, 4 Dec 2018 03:21:30 +0100
> Michael Niedermayer  wrote:
> 
> > On Mon, Dec 03, 2018 at 09:24:47AM +0200, Lauri Kasanen wrote:
> > > Also ping on "swscale/output: VSX-optimize
> > > nbps yuv2plane1".
> > 
> > This IIUC has not been tested on BE yet
> > 
> > my ppc emulation setup is a bit broken and my ppc hw ive not tried using
> > since years and it was not in good shape last i used it.
> > So i cant just quickly test this ...
> 
> Raptor offers free POWER9 VMs to open source projects. Since you're the
> leader of ffmpeg, if you asked, I'm sure they'd give one or two for
> ffmpeg build and fate testing.
> 
> Ref
> https://mobile.twitter.com/RaptorCompSys/status/1067018060777832449?p=v
> https://mobile.twitter.com/RaptorCompSys/status/1067029086273486848?p=v
> 
> "We offer free access to cloud VPS for libre software projects in
> partnership with @Integricloud, would that help?"
> 
> "Contact sa...@integricloud.com and tell them what you want to use a
> VPS or two for. They will generally grant access to the resources."
> 
> (I'm developing on a POWER8 VM intended for devs, but ordered a
> Blackbird from the cyber monday sale ;))

Red Hat also offers Power 8 VMs, both BE and LE, to open source projects:
http://research.redhat.com/powerlinux-openpower-development-hosting/

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/dashenc: Remove global_sidx from movenc params for live streaming.

[Jeyapal, Karthick]

On 11/29/18 8:28 PM, Andrey Semashev wrote:
> On 11/28/18 7:25 PM, Jeyapal, Karthick wrote:
>>
>> On 11/28/18 4:41 PM, Andrey Semashev wrote:
>>> The global_sidx flag causes errors like the following in movenc when media
>>> segment removal is enabled via windos_size or remove_at_exit:
>>>
>>> Non-consecutive fragments, writing incorrect sidx
>>> Unable to re-open  output file for the second pass (faststart) 
>> Removing global_sidx flag adds sidx atom to each moof fragment adding 
>> significant bitrate overhead.
>> Instead I have submitted a patch to handle this case cleanly in movenc. 
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-November/236873.html
>> Please try the above patch and let me know if that will work for you. 
>
> Yes, that patch seems to fix the errors. Thanks.
Hi Andrey,

That patch was not pushed due to some objections. I have submitted a new patch 
set addressing it. 
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/237121.html
Could you please try the above patchset and confirm if everything works as 
expected?

Regards,
Karthick
>
> On a slightly unrelated note, during testing, I've also seen different errors 
> like these:
>
> [AVFormatContext] Application provided duration: -1 / timestamp: 243456 is 
> out of range for mov/mp4 format
> [AVFormatContext] pts has no value
>
> These happen when media segments are rotated and file deletion is enabled. 
> They don't seem to happen on every file rotation, though, and I can't find 
> what could be causing them. These errors are present regardless of the 
> global_sidx flag or your movenc patch. Do you have an idea what could be 
> causing them?
> ___
> 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/2] avformat/movenc: Added an option to disable SIDX atom

[Gyan Doshi]

On 04-12-2018 02:11 PM, Karthick J wrote:


diff --git a/doc/muxers.texi b/doc/muxers.texi
index f1cc6f5fee..6ca27b04a3 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1325,6 +1325,8 @@ more efficient), but with this option set, the muxer 
writes one moof/mdat
  pair for each track, making it easier to separate tracks.
  
  This option is implicitly set when writing ismv (Smooth Streaming) files.

+@item -movflags no_sidx
+Don't write sidx atom.


Append a short note advising when this is required or recommended and 
when not.


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

Re: [FFmpeg-devel] [PATCH v2] avformat/movenc : Don't write sidx for empty urls

[Jeyapal, Karthick]

On 12/1/18 12:01 AM, Michael Niedermayer wrote:
> On Fri, Nov 30, 2018 at 05:52:35AM +, Jeyapal, Karthick wrote:
> > 
> > On 11/29/18 11:08 PM, Michael Niedermayer wrote:
> > > On Wed, Nov 28, 2018 at 09:45:24PM +0530, Karthick J wrote:
> > >> When movenc is used by other segmenting muxers such as dashenc, url 
> > >> field is always empty.
> > >> In such cases it is better to not write sidx, instead of throwing errors.
> > >> ---
> > >>  libavformat/movenc.c | 3 +++
> > >>  1 file changed, 3 insertions(+)
> > >
> > > please correct me if i misunderstand but
> > > dashenc enables global sidx, skiping writing the sidx then always seems a 
> > > bit
> > > odd
> > Your understanding is correct. 
> > But the motive of dashenc is to disable writing of sidx atom for every moof 
> > atom (Let's call this as local sidx for the sake of discussion).
> > We wanted to disable local sidx as it was adding significant bitrate 
> > overhead for chunked streaming(where each frame is a moof).
> > To disable local sidx we enabled global sidx. And global sidx was not 
> > writing any sidx at all from dashenc due to lack of url. 
> > This behavior of not writing any sidx at all is also acceptable for dash. 
> > But we just wanted to remove the error, and hence this patch.
> > Maybe one could add a new option no_sidx in movenc for this functionality. 
> > But since global_sidx was already achieving the same functionality new 
> > option seemed a bit redundant.
>
> I have no real oppinion on how to solve it, adding a more specific option
> could be done.
> but enabling global_sidx and then not doing it silently seems quite hackish
> as the intended behavior.
> I mean please implement this cleanly, whichever way makes most sense.
Thanks for your comments. I have submitted a patch with a specific option to 
disable sidx as you suggested.
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/237121.html

regards,
Karthick
>
> thanks
>
> [...]
>
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Observe your enemies, for they first find out your faults. -- Antisthenes

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

[FFmpeg-devel] [PATCH 1/2] avformat/movenc: Added an option to disable SIDX atom

[Karthick J]

---
 doc/muxers.texi  | 2 ++
 libavformat/movenc.c | 7 +--
 libavformat/movenc.h | 1 +
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index f1cc6f5fee..6ca27b04a3 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1325,6 +1325,8 @@ more efficient), but with this option set, the muxer 
writes one moof/mdat
 pair for each track, making it easier to separate tracks.
 
 This option is implicitly set when writing ismv (Smooth Streaming) files.
+@item -movflags no_sidx
+Don't write sidx atom.
 @item -movflags faststart
 Run a second pass moving the index (moov atom) to the beginning of the file.
 This operation can take a while, and will not work in various situations such
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 6dab5193b0..83278e8bfd 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -75,6 +75,7 @@ static const AVOption options[] = {
 { "frag_discont", "Signal that the next fragment is discontinuous from 
earlier ones", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_FRAG_DISCONT}, 
INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
 { "delay_moov", "Delay writing the initial moov until the first fragment 
is cut, or until the first fragment flush", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_DELAY_MOOV}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
 { "global_sidx", "Write a global sidx index at the start of the file", 0, 
AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_GLOBAL_SIDX}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
+{ "no_sidx", "Don't write sidx atom", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_NO_SIDX}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" 
},
 { "write_colr", "Write colr atom (Experimental, may be renamed or changed, 
do not use from scripts)", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_WRITE_COLR}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
 { "write_gama", "Write deprecated gama atom", 0, AV_OPT_TYPE_CONST, {.i64 
= FF_MOV_FLAG_WRITE_GAMA}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
 { "use_metadata_tags", "Use mdta atom for metadata.", 0, 
AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_USE_MDTA}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
@@ -4603,7 +4604,8 @@ static int mov_write_moof_tag(AVIOContext *pb, 
MOVMuxContext *mov, int tracks,
 mov_write_moof_tag_internal(avio_buf, mov, tracks, 0);
 moof_size = ffio_close_null_buf(avio_buf);
 
-if (mov->flags & FF_MOV_FLAG_DASH && !(mov->flags & 
FF_MOV_FLAG_GLOBAL_SIDX))
+if (mov->flags & FF_MOV_FLAG_DASH &&
+!(mov->flags & (FF_MOV_FLAG_GLOBAL_SIDX | FF_MOV_FLAG_NO_SIDX)))
 mov_write_sidx_tags(pb, mov, tracks, moof_size + 8 + mdat_size);
 
 if (mov->write_prft > MOV_PRFT_NONE && mov->write_prft < MOV_PRFT_NB)
@@ -5422,7 +5424,8 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
  * the next fragment. This means the cts of the first sample must
  * be the same in all fragments, unless end_pts was updated by
  * the packet causing the fragment to be written. */
-if ((mov->flags & FF_MOV_FLAG_DASH && !(mov->flags & 
FF_MOV_FLAG_GLOBAL_SIDX)) ||
+if ((mov->flags & FF_MOV_FLAG_DASH &&
+!(mov->flags & (FF_MOV_FLAG_GLOBAL_SIDX | 
FF_MOV_FLAG_NO_SIDX))) ||
 mov->mode == MODE_ISM)
 pkt->pts = pkt->dts + trk->end_pts - 
trk->cluster[trk->entry].dts;
 } else {
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index fe605d1ad2..ee6749bce2 100644
--- a/libavformat/movenc.h
+++ b/libavformat/movenc.h
@@ -257,6 +257,7 @@ typedef struct MOVMuxContext {
 #define FF_MOV_FLAG_SKIP_TRAILER  (1 << 18)
 #define FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS  (1 << 19)
 #define FF_MOV_FLAG_FRAG_EVERY_FRAME  (1 << 20)
+#define FF_MOV_FLAG_NO_SIDX   (1 << 21)
 
 int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt);
 
-- 
2.17.1 (Apple Git-112)

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

[FFmpeg-devel] [PATCH 2/2] avformat/dashenc: Used the movenc option no_sidx instead of global_sidx

[Karthick J]

Anyways the intended behaviour was to disable SIDX atom.
---
 libavformat/dashenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 4d9b564a94..84bc58d6c1 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1162,7 +1162,7 @@ static int dash_init(AVFormatContext *s)
 
 if (os->segment_type == SEGMENT_TYPE_MP4) {
 if (c->streaming)
-av_dict_set(, "movflags", 
"frag_every_frame+dash+delay_moov+global_sidx", 0);
+av_dict_set(, "movflags", 
"frag_every_frame+dash+delay_moov+no_sidx", 0);
 else
 av_dict_set(, "movflags", "frag_custom+dash+delay_moov", 
0);
 } else {
-- 
2.17.1 (Apple Git-112)

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