On Thu, 6 Dec 2018 21:47:18 +0100
Michael Niedermayer wrote:
> On Tue, Dec 04, 2018 at 02:27:22PM +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".
> > > >
On 12/11/18, 9:07 AM, "Ronak" wrote:
>
>> On Dec 6, 2018, at 4:47 AM, Tobias Rapp wrote:
>>
>> On 06.12.2018 08:28, Karthick J wrote:
>>> ---
>>> [...]
>>
>> Looks OK now, no more comments from my side.
>
>I actually was going to submit a patch that would remove sidx atoms being
>written
On 12/5/18, 11:49 AM, "Karthick J" wrote:
>
>Anyways the intended behaviour was to disable SIDX atom.
>---
> libavformat/dashenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> [...]
Pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmp
On 12/6/18, 3:18 PM, "Tobias Rapp" wrote:
>
>On 06.12.2018 08:28, Karthick J wrote:
>> ---
>> doc/muxers.texi | 4
>> libavformat/movenc.c | 12 ++--
>> libavformat/movenc.h | 1 +
>> 3 files changed, 15 insertions(+), 2 deletions(-)
>>
>> [...]
>
>Looks OK now, no m
> On Dec 6, 2018, at 4:47 AM, Tobias Rapp wrote:
>
> On 06.12.2018 08:28, Karthick J wrote:
>> ---
>> doc/muxers.texi | 4
>> libavformat/movenc.c | 12 ++--
>> libavformat/movenc.h | 1 +
>> 3 files changed, 15 insertions(+), 2 deletions(-)
>> [...]
>
> Looks OK now, no
On 12/10/2018 9:05 AM, Paul B Mahol wrote:
> +static uint32_t get_v(uint8_t *p)
> +{
> +uint32_t v = 0;
> +
> +do {
> +v <<= 7;
> +v += *p & 0x7f;
> +} while (*p++ & 0x80);
> +
> +return v;
> +}
More than four or so iterations will overflow uint32_t.
> +AVInputForm
2018-12-10 23:41 GMT+01:00, Mark Thompson :
> On 09/12/2018 14:21, Mark Thompson wrote:
>> On 09/12/2018 13:54, Paul B Mahol wrote:
>>> On 12/9/18, Mark Thompson wrote:
On 09/12/2018 08:52, Paul B Mahol wrote:
> On 12/7/18, Paul B Mahol wrote:
>> On 12/7/18, Michael Niedermayer wrot
2018-12-10 17:55 GMT+01:00, Kevin Wheatley :
> I came across a similar discussion here:
>
> https://github.com/OpenImageIO/oiio/pull/1412
So the solution is:
We don't fix it because it is broken elsewhere?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg
Hi!
I suspect attached patch fixes a bug on some platforms, silences a warning.
Please comment, Carl Eugen
From cfc9e3fd1e24d108581bad096a4de987069b2c49 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 11 Dec 2018 03:12:49 +0100
Subject: [PATCH] lavfi/signalstats: Cast the return value
On Mon, Dec 10, 2018 at 01:05:05PM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/vividas.c| 708 +++
> 3 files changed, 710 insertions(+)
> create mode 1
2018-12-11 0:52 GMT+01:00, Carl Hetherington :
> Please review... I have used FFmpeg a lot but never suggested a patch
> before :)
Patch applied.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listi
2018-12-10 3:13 GMT+01:00, Carl Eugen Hoyos :
> 2018-12-07 3:06 GMT+01:00, Carl Eugen Hoyos :
>
>> I believe the Android documentation indicates that gcc will be
>> removed from ndk. Attached patch changes the default to
>> "clang" for --target-os=android.
>>
>> Now with patch.
>
> Any comments?
I
2018-12-10 23:47 GMT+01:00, Mark Thompson :
> On 10/12/2018 00:47, Carl Eugen Hoyos wrote:
>> 2018-12-09 18:50 GMT+01:00, Mark Thompson :
>>> On 06/12/2018 22:37, Carl Eugen Hoyos wrote:
Hi!
Attached patch fixes building with new Android toolchain, used to be a
warning.
>>>
Please review... I have used FFmpeg a lot but never suggested a patch
before :)
Signed-off-by: Carl Hetherington
---
libavcodec/tiff.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 751f23ef33..f71885d156 100644
--- a/libavcodec/tiff.c
+++ b/lib
2018-12-10 23:53 GMT+01:00, Mark Thompson :
> On 10/12/2018 00:57, Carl Eugen Hoyos wrote:
>> 2018-12-09 19:03 GMT+01:00, Mark Thompson :
>>> On 06/12/2018 22:26, Carl Eugen Hoyos wrote:
Hi!
Attached patch silences a new gcc warning, alternative would be to
disable the warning.
On 10/12/2018 01:56, myp...@gmail.com wrote:
> On Mon, Dec 10, 2018 at 2:08 AM Mark Thompson wrote:
>>
>> On 06/12/2018 10:39, Jun Zhao wrote:
>>> Fix slice number check logic. Only when the user setting slices
>>> number more than the driver constraints dump the rounded up warning
>>> message.
>>
On 10/12/2018 00:57, Carl Eugen Hoyos wrote:
> 2018-12-09 19:03 GMT+01:00, Mark Thompson :
>> On 06/12/2018 22:26, Carl Eugen Hoyos wrote:
>>> Hi!
>>>
>>> Attached patch silences a new gcc warning, alternative would be to
>>> disable the warning.
>>>
>>> Please comment, Carl Eugen
>>>
>>>
>>> From
On 10/12/2018 00:47, Carl Eugen Hoyos wrote:
> 2018-12-09 18:50 GMT+01:00, Mark Thompson :
>> On 06/12/2018 22:37, Carl Eugen Hoyos wrote:
>>> Hi!
>>>
>>> Attached patch fixes building with new Android toolchain, used to be a
>>> warning.
>>>
>>> Please comment, Carl Eugen
>>>
>>> From d366c948af08
On 09/12/2018 14:21, Mark Thompson wrote:
> On 09/12/2018 13:54, Paul B Mahol wrote:
>> On 12/9/18, Mark Thompson wrote:
>>> On 09/12/2018 08:52, Paul B Mahol wrote:
On 12/7/18, Paul B Mahol wrote:
> On 12/7/18, Michael Niedermayer wrote:
>> On Fri, Dec 07, 2018 at 10:36:23AM +0100,
2018-12-10 16:49 GMT+01:00, Paul B Mahol :
> On 12/10/18, Carl Eugen Hoyos wrote:
>> 2018-12-06 19:11 GMT+01:00, Carl Eugen Hoyos :
>>
>>> Attached patch fixes decoding the files attached to ticket #6234.
>>>
>>> Please comment, Carl Eugen
>>
>> Ping.
>
> Probably ok.
Patch applied.
Thank you, C
From: Mohammad Izadi
The dynamic metadata contains data for color volume transform - application 4
of SPMTE 2094-40:2016 standard. The data comes from HEVC in the
SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35.
I'll add support to HEVC in a follow-up.
---
libavutil/Makefile | 2 +
li
Hi,,
On 11/21/17, Bjorn Roche wrote:
> Support for transparencies in animated gifs requires modifying both
> libavcodec/gif.c and libavformat/gif.c because both the graphics
> control extension (handled by libavformat/gif.c) and the raw frame data
> (handled by libavcodec/gif.c) must be changed.
I came across a similar discussion here:
https://github.com/OpenImageIO/oiio/pull/1412
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Moritz Barsnick (2018-12-10):
> That was my interpretation. It's a density, if units != 0, otherwise
> the aspect ratio. (Would a density not correspond to the SAR? I.e. not
> make sense with square pixels?)
I did not follow the beginning of the discussion, but just in case it
can help and was not
On Mon, Dec 10, 2018 at 13:19:57 +0100, Carl Eugen Hoyos wrote:
> > units (1 byte) Units for the X and Y densities.
> > units = 0: no units, X and Y specify the pixel aspect ratio
> > units = 1: X and Y are dots per inch
> > units = 2: X and Y are dots per cm
> > Xdensity (2 bytes)
On 12/10/18, Carl Eugen Hoyos wrote:
> 2018-12-06 19:11 GMT+01:00, Carl Eugen Hoyos :
>
>> Attached patch fixes decoding the files attached to ticket #6234.
>>
>> Please comment, Carl Eugen
>
> Ping.
Probably ok.
___
ffmpeg-devel mailing list
ffmpeg-dev
At Michael's suggestion, this patch lets -vn/-an/-sn/-dn work for input
files. Individual streams can still be let through e.g.
ffmpeg -an -discard:a:1 none -i file ...
will let (only) the 2nd audio stream be seen during stream selection and
filtergraph construction.
Thanks,
Gyan
From 98
Maybe we should set a ffprobe variable in the fate Makefile, like done
for ffmpeg on ln 8.
Gyan
From f1cdb3ee993602618bad243df07c0e33263cc211 Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Mon, 10 Dec 2018 20:44:33 +0530
Subject: [PATCH] fate: add prog suffix in fate-mov-mp4-with-mov-in24-ver
On 12/10/18, Tomas Härdin wrote:
> The first in a series of CRYO APC patches
>
> /Tomas
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 12/6/18, Paul B Mahol wrote:
> On 12/6/18, Baptiste Coudurier wrote:
>> On Thu, Dec 6, 2018 at 7:45 AM Paul B Mahol wrote:
>>
>>> On 12/6/18, Baptiste Coudurier wrote:
>>> > Hi Paul,
>>> >
>>> > On Wed, Dec 5, 2018 at 3:18 PM Paul B Mahol wrote:
>>> >
>>> >> On 12/6/18, Baptiste Coudurier
Fixes #6874.
Signed-off-by: Paul B Mahol
---
libavcodec/gifdec.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/libavcodec/gifdec.c b/libavcodec/gifdec.c
index 54f1d4c0ba..0eb1c21d99 100644
--- a/libavcodec/gifdec.c
+++ b/libavcodec/gifdec.c
@@ -179,12 +179
2018-12-10 9:46 GMT+01:00, Gyan :
>
> On 10-12-2018 07:41 AM, Carl Eugen Hoyos wrote:
>> 2018-12-03 17:05 GMT+01:00, Carl Eugen Hoyos :
>>
>>> It appears to me that NewTek abused our willingness to add an optional
>>> external nonfree library, I don't see many better options. See Ticket
>>> #7589 a
2018-12-10 9:29 GMT+01:00, Moritz Barsnick :
> On Mon, Dec 10, 2018 at 02:54:54 +0100, Carl Eugen Hoyos wrote:
>> I hope somebody can prove me wrong!
>
> Not sure, see below.
>
>> This would need a slightly more sophisticated update to the decoder.
>
> Because it is also presumed incorrect?
>
>>
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
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
Signed-off-by: Paul B Mahol
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/vividas.c| 708 +++
3 files changed, 710 insertions(+)
create mode 100644 libavformat/vividas.c
diff --git a/libavformat/Makefile b/libavformat
On Mon, Dec 10, 2018 at 12:33:52PM +0100, Michael Niedermayer wrote:
> On Mon, Dec 10, 2018 at 02:54:54AM +0100, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Reading the specification and Wikipedia, it appears to me that FFmpeg
> > is writing wrong values as aspect ratio for jfif files.
> > I hope some
On Mon, Dec 10, 2018 at 02:54:54AM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> Reading the specification and Wikipedia, it appears to me that FFmpeg
> is writing wrong values as aspect ratio for jfif files.
> I hope somebody can prove me wrong!
>
> This would need a slightly more sophisticated updat
From 32cc6a96f80b5406e8327d912c8fc38812e6a664 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Fri, 23 Nov 2018 15:15:02 +0100
Subject: [PATCH 3/3] Add ADPCM IMA CRYO APC encoder
No trellis quantization yet
---
Changelog | 1 +
libavcodec/adpcmenc.c
From f08c1554f30839c7d42a9c5e677619f2c8b11c11 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Thu, 22 Nov 2018 22:28:30 +0100
Subject: [PATCH 2/3] Add CRYO APC muxer
---
Changelog| 1 +
doc/general.texi | 2 +-
libavformat/Makefile | 1 +
l
The first in a series of CRYO APC patches
/TomasFrom d0988031b97c22a9bda6832eb8871e917335aae6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Fri, 23 Nov 2018 14:12:50 +0100
Subject: [PATCH 1/3] apc: Read duration from file
---
libavformat/apc.c | 3 ++-
1 file changed, 2 i
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Monday, December 10, 2018 01:40
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH, v2] lavc/hevc_parser: add 4 bytes
> startcode condition and update FATE
Given that leading_zero_8bits can be included many times at the beginning
of a NAL unit, blindly taking the startcode as 3 bytes will leave 0x00
in last frame and may lead to some warnings in parse_nal_units when s->flags
is set to PARSER_FLAG_COMPLETE_FRAMES.
Modify to put all of the zeroes betwe
mån 2018-12-10 klockan 10:17 +0100 skrev Paul B Mahol:
> > Signed-off-by: Paul B Mahol
> ---
> libavformat/mxfenc.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 3549b4137d..006a9da1f8 100644
> --- a/libavformat/mxfenc.c
> +++ b
On 12/9/18, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/Makefile | 1 +
> libavcodec/gif_parser.c | 188
> libavcodec/parsers.c| 1 +
> 3 files changed, 190 insertions(+)
> create mode 100644 libavcodec/gif_parser.c
>
Signed-off-by: Paul B Mahol
---
libavformat/mxfenc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 3549b4137d..006a9da1f8 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -2368,6 +2368,11 @@ static int mxf_write_header(AV
Gyan , 10 Ara 2018 Pzt, 11:47 tarihinde şunu yazdı:
>
> On 10-12-2018 07:41 AM, Carl Eugen Hoyos wrote:
> > 2018-12-03 17:05 GMT+01:00, Carl Eugen Hoyos :
> >
> >> It appears to me that NewTek abused our willingness to add an optional
> >> external nonfree library, I don't see many better options.
Hi Mark,
Do you have any comments regarding this patch ?
Best Regards,
Zachary
> -Original Message-
> From: Zhou, Zachary
> Sent: Monday, December 3, 2018 6:56 PM
> To: FFmpeg development discussions and patches
> Cc: Zhou, Zachary
> Subject: RE: [FFmpeg-devel] [PATCH v4] libavfilter:
On 10-12-2018 07:41 AM, Carl Eugen Hoyos wrote:
2018-12-03 17:05 GMT+01:00, Carl Eugen Hoyos :
It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the
On Mon, Dec 10, 2018 at 02:54:54 +0100, Carl Eugen Hoyos wrote:
> I hope somebody can prove me wrong!
Not sure, see below.
> This would need a slightly more sophisticated update to the decoder.
Because it is also presumed incorrect?
> put_bits(p, 16, 0x0102);
> put_bits(p, 8,
50 matches
Mail list logo
