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,
---
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
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 suc
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
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
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 bee
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
+++
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/fi
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
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
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?
C
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
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 a
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 vers
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
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 i
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 us
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
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
+
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 wi
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
mo
>
> LGTM
>
> thanks
>
> [...]
> --
> Michael
>
Pushed, thanks.
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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 bits
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
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 wa
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.c
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 +
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-
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 w
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
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 mo
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
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
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
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 shoul
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 bec
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
---
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 sourc
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_MSMPEG
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 shim
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
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 (pro
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
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
_
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 tha
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
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
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 tha
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, s
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
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 set
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,
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/libav
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 he
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/ffm
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
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 recomme
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 ins
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 us
> 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
>
>
---
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 +132
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,
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
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
64 matches
Mail list logo
