On Thu, Feb 24, 2022 at 2:44 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Will apply this tomorrow unless there are objections.
>
No objections from me. Thanks for the improvement!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.or
I'll just chime in and say:
FIXME comments aren't that helpful. It would be more helpful to av_log when
you detect you've hit an unsupported situation.
As for SMPTE 240M vs BT.601 Y'CbCr matrices: yes, they're different. But
SDL doesn't support SMPTE 240M. It only supports:
SDL_YUV_CONVERSION_JP
On Thu, Aug 20, 2020 at 10:45 AM Michael Bradshaw
wrote:
> On Wed, Aug 19, 2020 at 9:23 PM zhilizhao wrote:
>
>> > -static const int valid_trc[4]= { AVCOL_TRC_RESERVED0,
>> AVCOL_TRC_BT709, AVCOL_TRC_UNSPECIFIED, INT_MAX };
>> >
Signed-off-by: Michael Bradshaw
---
libavcodec/proresenc_anatoliy.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/proresenc_anatoliy.c
index 1128978330..d1623e142c 100644
--- a/libavcodec/proresenc_anatoliy.c
On Wed, Aug 19, 2020 at 2:19 PM Paul B Mahol wrote:
> On 8/19/20, Michael Bradshaw wrote:
> > I completely forgot about this patch. If no one objects over the next few
> > days I plan on pushing this. FATE still passes.
>
> Fine by
On Wed, Aug 19, 2020 at 9:23 PM zhilizhao wrote:
> > -static const int valid_trc[4]= { AVCOL_TRC_RESERVED0,
> AVCOL_TRC_BT709, AVCOL_TRC_UNSPECIFIED, INT_MAX };
> > +static const int valid_trc[6]= { AVCOL_TRC_RESERVED0,
> AVCOL_TRC_BT709, AVCOL_TRC_UNSPECIFIED, AVCOL_TRC_SMPTE2084
Signed-off-by: Michael Bradshaw
---
libavcodec/proresenc_anatoliy.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/proresenc_anatoliy.c
index 1128978330..3005db0bb4 100644
--- a/libavcodec/proresenc_anatoliy.c
+++ b/libavcodec
On Wed, Aug 19, 2020 at 8:24 PM Michael Bradshaw wrote:
> Signed-off-by: Michael Bradshaw
> ---
> libavcodec/proresenc_anatoliy.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/proresenc_anatoliy.c
> b/libavcodec/proresenc_anatoliy
Signed-off-by: Michael Bradshaw
---
libavcodec/proresenc_anatoliy.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/proresenc_anatoliy.c
index 1128978330..3aa18a3ca4 100644
--- a/libavcodec/proresenc_anatoliy.c
+++ b/libavcodec
On Mon, Apr 13, 2020 at 4:14 PM Michael Bradshaw wrote:
> Attached is an updated patch that passes fate.
>
I completely forgot about this patch. If no one objects over the next few
days I plan on pushing this. FATE still passes.
___
ffmpeg
On Thu, Jun 11, 2020 at 9:42 AM Gautam Ramakrishnan
wrote:
> Got it. In that case we can safely ignore the patch to fix libopenjpeg.
> However, p1_03.j2k is one of the 2 files to have ppm marker. How could I
> validate a patch to add ppm marker? I need something to cross validate.
> Any suggestio
On Wed, Jun 10, 2020 at 9:35 PM Gautam Ramakrishnan
wrote:
> The reference file has 4 components, Whereas all the Bayer formats
> have 3 components. Are we missing any Bayer pixel format in ffmpeg?
> Also, any other ideas on what has to be done for the 2 reference files
> mentioned? If this seems
On Tue, Jun 9, 2020 at 6:07 AM wrote:
> From: Gautam Ramakrishnan
>
> This patch makes selection of pix_fmt similar to
> that in the native decoder. This makes samples such
> as p0_05.j2k and p1_03.j2k decodable by libopenjpeg.
> ---
> libavcodec/libopenjpegdec.c | 21 +++--
> 1
Attached is an updated patch that passes fate.
0001-avformat-movenc-write-the-colr-atom-by-default.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, vis
On Mon, Apr 13, 2020 at 2:01 PM Michael Bradshaw wrote:
> Sorry about that. I should have been more thorough. Attached patch fixes
> fate.
>
And another that got missed.
0001-tests-ref-vsynth-fix-fate-colr-changes-again.patch
Description: Bi
On Mon, Apr 13, 2020 at 1:24 PM Andriy Gelman
wrote:
> seems to break fate
> make fate-vsynth1-dnxhd-1080i-colr
Sorry about that. I should have been more thorough. Attached patch fixes
fate.
0001-tests-ref-vsynth-fix-fate-colr-changes.patch
Description: Binary data
___
hopefully have more experience (and opinions) on this than I do).
From d6fcb5705d2c451b9ec1146b4fe66517f9eb6692 Mon Sep 17 00:00:00 2001
From: Michael Bradshaw
Date: Mon, 13 Apr 2020 11:11:38 -0600
Subject: [PATCH] avformat/movenc: write the colr atom by default
The write_colr flag has been marked as experimental for over 5
On Mon, Apr 13, 2020 at 10:26 AM Michael Bradshaw
wrote:
> Attached patch is updated to do that.
>
Pushed to master, but with a change to use AV_LOG_VERBOSE logging (to be
consistent with the clli atom).
___
ffmpeg-devel mailing list
ffmpeg
On Mon, Apr 13, 2020 at 10:32 AM James Almer wrote:
> Should be AV_LOG_VERBOSE, or just removed. Otherwise every muxing
> process where there's no CLL side data will print this, and that'll be
> the vast majority of cases.
>
Okay, I switched it to verbose.
LGTM otherwise.
Thanks. Pushed.
Given the lack of objections I've pushed this to the master branch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with sub
On Tue, Mar 31, 2020 at 6:23 AM Derek Buitenhuis
wrote:
> I agree strongly with Michael's points.
I've pushed the patch to master.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe,
On Wed, Apr 1, 2020 at 1:18 PM Carl Eugen Hoyos wrote:
> Same here: If this helps, it should not be optional imo.
Based on Jan's email I'm fine with removing the flag and just writing this
atom by default. Attached patch is updated to do that.
0001-avformat-movenc-write-the-mdcv-atom-by-defau
The clli atom is expected to be standardized soon. See
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/259529.html
This patch will write the clli atom by default.
Please review.
0001-avformat-movenc-remove-the-write_clli-mov-flag.patch
Description: Binary data
__
On Wed, Apr 1, 2020 at 3:34 PM James Almer wrote:
> Your patch to write the colr box by default is an example of this. You
> didn't remove the option like one would expect, but made it "official"
> and left for users the ability to disable the atom's presence. It should
> instead be removed and th
> On 4/1/2020 4:54 PM, Carl Eugen Hoyos wrote:
> If there already are devices that support it, it should not be optional.
There are, but these boxes aren't technically standardized for mp4/mov
as far as I can tell. I'm reluctant (but not entirely opposed) to
enable something by default that isn't
On Wed, Apr 1, 2020 at 1:18 PM Carl Eugen Hoyos wrote:
>
> If this patch is a good idea (if it fixes playback visually on some devices -
> do I understand that correctly?), it should not be optional imo.
It won't be optional once it's standardized in ISO/IEC 14496-12. But I
think it's good to hav
Attached is an updated patch that resolves merge conflicts against the
latest master.
0001-avformat-movenc-add-write_mdcv-flag-to-write-mdcv-at.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailm
On Wed, Apr 1, 2020 at 7:21 AM Derek Buitenhuis
wrote:
> I might have mistakenly be thinking of mdcv, which the PDf you linked from
> Apple
> lists as being in SMPTE 2084 (I don't have a copy of that spec on hand
> currently...).
>
I just checked SMPTE ST 2084 and it doesn't mention mdcv (or ISO
On Wed, Apr 1, 2020 at 6:04 AM Derek Buitenhuis
wrote:
> Would it make sense to allow it by default for QTFF only, since it is
> properly
> defined in it? OR would that perhaps be a little confusing from a user
> perspective?
>
Do you know where it's properly defined for QTFF? The only reference
I just realized the patch contained some stray UTF-8 characters. Sorry
about that. Attached is a patch with an updated commit message without the
annoying characters. The code is unchanged.
>
0001-avformat-movenc-add-write_clli-flag-to-write-clli-at.patch
Description: Binary data
___
The mdcv atom isn't in ISO/IEC 14496-12:2015 so the flag is marked as
experimental and the mdcv atom is not written by default.
The mdcv atom is referenced by e.g., [1][2] and is already parsed in FFmpeg
in mov.c.
Once ISO/IEC 14496-12 standardizes the mdcv atom (which I assume it will?)
then we
The switch cases were missing:
- Primaries: bt470m, film, smpte428, and ebu3213.
- TRCs: gamma22, gamma28, linear, log, log_sqrt, iec61966_2_4, bt1361,
iec61966_2_1, bt2020_10bit, and bt2020_12bit.
- Space: rgb, fcc, ycgco, bt2020_cl, smpte2085, chroma-derived-nc,
chroma-derived-c,
The clli atom isn't in ISO/IEC 14496-12:2015 so the flag is marked as
experimental and the clli atom is not written by default.
The clli atom is referenced by e.g., [1][2] and is already parsed in FFmpeg
in mov.c.
Once ISO/IEC 14496-12 standardizes the clli atom (which I assume it will?)
then we
On Mon, Mar 30, 2020 at 4:48 PM Carl Eugen Hoyos wrote:
> I believe there is some historical evidence that this guessing is needed
> to get visually correct output in many cases.
I haven't found any evidence of that. This guessing has been part of the
code since the write_colr flag was original
On Mon, Mar 30, 2020 at 4:23 PM Carl Eugen Hoyos wrote:
> But not every call of the mov muxer is done for Dolby Vision
> samples or do I misunderstand?
You're right that most muxing doesn't involve Dolby Vision. However, even
for cases that don't involve Dolby Vision I still think guessing is t
On Mon, Mar 30, 2020 at 3:46 PM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Why is all this information not in the commit message? (In commit
> message style of course, i.e. no "I propose".)
For reasons that I'm happy to discuss in a separate thread to avoid
derailing this one. A
The write_colr flag has been marked as experimental for over 5 years. I
propose we do the following (as implemented by the attached patch):
- Write the colr atom by default for mp4/mov if any of the following:
- The primaries/trc/matrix are all specified, OR
- There is an ICC profil
See [1]. Apple requests that colr atom values be 2 ("unspecified") for
Dolby Vision.
Please review.
--Michael
[1]:
https://developer.apple.com/av-foundation/High-Dynamic-Range-Metadata-for-Apple-Devices.pdf
0001-avformat-movenc-stop-guessing-colr-atom-values.patch
Description: Binary data
_
Looking at this further, Apple's HDR requirements[1] say for Dolby Vision:
The color (‘colr’) atom with these values shall be present.
- Color Primaries shall be set to 2 (Unspecified).
- Color Transfer Function Index shall be set to 2 (Unspecified).
- Color Matrix Index shall be se
Updated patch attached. I forgot to remove the FF_MOV_FLAG_WRITE_COLR macro
in the original patch. My apologies.
>
0001-avformat-movenc-remove-write_colr-flag-and-write-col.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpe
The write_colr flag has been marked as "experimental, may be renamed or
changed, do not use from scripts" for over 5(!) years. I think it's time we
decide how to handle the colr atom.
I propose that we write the colr atom by default if the stream either has
an ICC color profile or has specified va
On Mon, Feb 10, 2020 at 1:22 PM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> 1. This partially overlaps and partially conflicts with [2].
>
Thanks. I'll wait for [2] to be merged and then will update the patch to be
WebM-specific.
2. The patch as-is is dangerous: There is currentl
FFmpeg to retain metadata from WebM and Matroska
streams when remuxing.
[1]: https://www.webmproject.org/docs/container/#BlockAddID
From c4f6f8e0f9669938970416ff3ac159ecc1aa344f Mon Sep 17 00:00:00 2001
From: Michael Bradshaw
Date: Mon, 10 Feb 2020 12:33:32 -0800
Subject: [PATCH] lavf: stop
The original code requires CID to be 1256 or 1270 if CLV or CLF are set.
This is unnecessarily restrictive. If CLF is 1, then CID must be 1256 or
1270. But if CLF is 0, then CID may be different. If CLV is 1 or 2, then
CID must be in the range 1270-1274 (inclusive).
Thus, the original code would w
Hey, Carl Eugen! Thanks for the patch.
On Thu, Jun 21, 2018 at 3:12 AM, Carl Eugen Hoyos
wrote:
>
> Attached patch allows to create (and read) gray1x samples with libopenjpeg.
Looks good to me. I have a few very small nits below. I won't block the
patch based on these small nits, so feel free t
On Wed, Oct 18, 2017 at 8:21 PM, Michael Bradshaw <
mjbshaw-at-google@ffmpeg.org> wrote:
>
> Updated patch attached (which contains James Almer's suggestion for the
> -DOPJ_STATIC fix; thanks, James!).
Patch pushed. Thanks, all. Please let me know if anyone hits a
On Thu, Oct 19, 2017 at 2:28 AM, Moritz Barsnick wrote:
> On Wed, Oct 18, 2017 at 20:21:21 -0700, Michael Bradshaw wrote:
> > I've added a note to the Changelog. Let me know if there are additional
> > notices that should be made.
>
> It was remarked that pkg-config s
On Wed, Oct 18, 2017 at 5:04 PM, Michael Niedermayer wrote:
>
> i think the patch should add some note to the release notes or
> changelog
>
I've added a note to the Changelog. Let me know if there are additional
notices that should be made.
Updated patch attached (which contains James Almer's
On Wed, Oct 18, 2017 at 2:44 PM, Reino Wijnsma wrote:
>
> Is there a reason you left out -DOPJ_STATIC?
>
I assumed OpenJPEG's pkgconfig file would be smart enough to add it in if
needed. Apparently that's not the case. Dang.
'openjpeg_git/src/lib/openjp2/libopenjp2.pc.cmake.in' doesn't put it in
Sorry for the long delay in my response!
On Sun, Oct 8, 2017 at 11:14 AM, Nicolas George wrote:
>
> Le quintidi 15 vendémiaire, an CCXXVI, Michael Bradshaw a écrit :
> > +OPT_DBL("beep_delay",beep_delay, 0, 0,
> DBL_MAX, "se
On Wed, Oct 18, 2017 at 1:26 PM, Michael Niedermayer wrote:
>
> correction, xenial and zesty have 2.1.* under the name libopenjp2-7
>
> trusty does not though
Yeah, Ubuntu 14.04 is stuck on the ancient OpenJPEG 1.3. I think it's fine
to proceed with this patch since:
1) OpenJPEG 1.3 sets AV_COD
Thanks for the review!
On Wed, Oct 18, 2017 at 12:26 PM, James Almer wrote:
>
> Add a line to Changelog about dropping support for OpenJPEG <= 2.0.
>
Done.
> +enabled libopenjpeg && require_pkg_config libopenjpeg libopenjp2
> openjpeg.h opj_version
>
> OpenJPEG 2.0.1 ships a pkg-config fi
Hi,
Attached patch drops support for OpenJPEG 1.3, 1.4, 1.5, and 2.0. After
this patch, only versions 2.1 and above will be supported (and will require
pkg-config).
Tested locally on macOS with OpenJPEG 2.3 by both encoding and decoding a
jp2 file.
Please review.
Thanks,
--Michael
0001-lavc-
On Sun, Oct 8, 2017 at 8:34 AM, Derek Buitenhuis wrote:
>
> Is there anything that precludes switching 2.X to pkg-config and leaving
> 1.X as is?
No, switching 2.x to pkg-config isn't dependent on dropping 1.x. But since
I plan to do both, I figure I might as well do them together since they're
I can clean these up as part of the patch that drops OpenJPEG 1.x support,
which I plan on making after the next release (though of course someone
else is welcome to beat me to it; it seems there's a race for OpenJPEG
patches!).
___
ffmpeg-devel mailing l
On Thu, Oct 5, 2017 at 9:55 AM, James Almer wrote:
> On 10/5/2017 10:45 AM, Michael Bradshaw wrote:
> > From: Michael Bradshaw
> >
> > Signed-off-by: Michael Bradshaw
> > ---
> > configure | 5 -
> > libavcodec/libopen
From: Michael Bradshaw
Signed-off-by: Michael Bradshaw
---
doc/filters.texi| 13 -
libavfilter/asrc_sine.c | 17 +
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 57189c77b0..ec1c335950 100644
--- a
From: Michael Bradshaw
This adds support for OpenJPEG 2.3.0, which was just released and contains many
security-related fixes.
Michael Bradshaw (1):
lavc: add support for OpenJPEG 2.3.0
configure | 5 -
libavcodec/libopenjpegdec.c | 8 +---
libavcodec
From: Michael Bradshaw
Signed-off-by: Michael Bradshaw
---
configure | 5 -
libavcodec/libopenjpegdec.c | 8 +---
libavcodec/libopenjpegenc.c | 10 ++
3 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/configure b/configure
index 391c141e7a
On Tue, Aug 8, 2017 at 2:09 AM, maxime taisant
wrote:
>
> [...]
> +void (*dwt_decode)(DWTContext *s, void *t);
Why the global variable? It seems unnecessary, and as Clément pointed out,
is unsafe and should not be used in the FFmpeg code base (at least not
without a very good justification and s
On Fri, Jun 23, 2017 at 2:57 PM, Reino Wijnsma wrote:
>
> Like this?
Yup, just like that. Thanks for the patch! I've applied it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Wed, Jun 21, 2017 at 3:43 PM, Reino Wijnsma wrote:
>
> New patch included. Thanks.
Almost done! The OPJ_STATIC change that was introduced in OpenJPEG 2.1+
means FFmepg's configure script has to do some extra work. You'll see that
there are two check_lib calls for openjpeg-2.1. You'll need to
> From 70b53c1ea5a56a03cfef24d5b551b983ba2473b2 Mon Sep 17 00:00:00 2001
> From: Reino17
> Date: Wed, 14 Jun 2017 00:19:12 +0200
> Subject: [PATCH] Add support for LibOpenJPEG v2.2/git
>
> ---
> configure | 4 +++-
> libavcodec/libopenjpegdec.c | 10 +++---
> libavcodec/lib
On Mon, Jun 12, 2017 at 4:36 PM, Reino Wijnsma wrote:
> This patch adds support for LibOpenJPEG v2.2/git. At the moment v2.1 is
> the highest version FFmpeg supports. I've successfully cross-compiled
> FFmpeg this way.
Are you sure you built ffmpeg using OpenJPEG v2.2? Because your patch is
mis
On Sat, Jun 10, 2017 at 8:19 AM, James Almer wrote:
> Is mxf as output needed for this?
mxf was one of the (relatively few) number of muxers I knew of that
would utilize the provided time base. It's not strictly needed.
> If not, the framemd5() or framecrc()
> fate functions (which use the muxer
On Mon, Jun 12, 2017 at 11:14 AM, James Almer wrote:
> On 6/12/2017 3:07 PM, Paul B Mahol wrote:
>> OK, please apply.
>
> Wouldn't it be better/proper to add the license header to the file instead?
Yeah. Paul, as the proper copyright holder of the sofa2wavs.c file,
could you add the license heade
commit 1a30bf60be9243830b68e8fe2e20539f08a85926 added the sofa2wavs
tool, which breaks fate:
$ make fate V=1
TESTsource
./tests/fate-run.sh fate-source "samples" "" "/Users/mjbshaw/ffmpeg"
'runlocal fate/source-check.sh' '' '' '' '1' '' '' '' '' '' '' '' ''
''
./tests/fate/source-check.sh ./tes
Hi,
Attached patch adds a FATE test for the -time_base option, as
promised[1] (months ago). This is my first FATE patch, so please be
sure to check for stupid mistakes and whatnot. I'm happy to revise it
as needed.
Thanks,
--Michael
[1]: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/20943
On Thu, Mar 30, 2017 at 10:17 AM, Clément Bœsch wrote:
>
> How about the documentation (and the promised FATE test to prevent a break
> in a random merge)?
I haven't forgotten about it. It's still on my radar and TODO list. This
email thread has been sitting in my inbox staring me in the face ea
On Thu, Mar 9, 2017 at 8:09 PM, Aaron Boxer wrote:
>
> Thanks, Michael. Here are those changes.
Applied. Thanks for the patch!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Wed, Mar 8, 2017 at 5:19 AM, Aaron Boxer wrote:
> Final version of simple patch to :
>
> limit encoder to single layer
> add lossless option
> set better defaults for a few encoding parameters.
I think I'd prefer to remove the numlayers option altogether if the only
possible value it can hav
On Sat, Jan 14, 2017 at 1:12 PM, Clément Bœsch wrote:
>
> erm. We have at least a codec option with that same name. How much does it
> conflict with this?
>
The only use of a "time_base" option I'm aware of is in buffer/abuffer in
libavfilter. Is there another one somewhere else?
Can we have som
On Sat, Jan 14, 2017 at 3:57 AM, Michael Niedermayer
wrote:
> On Tue, Dec 27, 2016 at 09:47:47PM -0800, Michael Bradshaw wrote:
> > +// ms precision is the de-facto standard timescale for mkv files
> > +mkv->timecode_scale = 100;
> > +
> > +// If t
On Wed, Dec 28, 2016 at 5:03 AM, Michael Niedermayer wrote:
> On Tue, Dec 27, 2016 at 09:47:47PM -0800, Michael Bradshaw wrote:
> > From: Michael Bradshaw
> >
> > Signed-off-by: Michael Bradshaw
> > ---
> > libavformat/matroskaenc.c | 38 +
From: Michael Bradshaw
Signed-off-by: Michael Bradshaw
---
ffmpeg.c | 6 --
ffmpeg.h | 2 ++
ffmpeg_opt.c | 16 +++-
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index ec9da3e..9ad9535 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
From: Michael Bradshaw
Hi,
Attached patch adds a -time_base parameter to ffmpeg output streams. This
parameter sets the initial AVStream.time_base value for the output streams,
thus providing a time base hint to the muxer.
Please review.
Michael Bradshaw (1):
ffmpeg: Add -time_base option
From: Michael Bradshaw
Signed-off-by: Michael Bradshaw
---
libavformat/matroskaenc.c | 38 +++---
1 file changed, 31 insertions(+), 7 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 827d755..2c2c930 100644
--- a/libavformat
From: Michael Bradshaw
Hi,
Attached match makes the MKV/WebM muxer accept the time_base hint as specified
in AVStream[1]. If the time_base of all the streams are the same and can be
represented in Matroska, then the time_base hint is used. Otherwise, it
defaults to milliseconds (which is the
From: Michael Bradshaw
Hi,
Attached patch condenses a statement from two lines to one. It's purely
cosmetic, but I find it makes the code easier to read. Please review.
Michael Bradshaw (1):
ffmpeg: Move statement to a single line
ffmpeg_opt.c | 3 +--
1 file changed, 1 insertion(
From: Michael Bradshaw
Signed-off-by: Michael Bradshaw
---
ffmpeg_opt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 6862456..af71604 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -1384,8 +1384,7 @@ static OutputStream
From: Michael Bradshaw
Hi,
Attached patch sets key frame/picture type for decoded frames. Please review.
Michael Bradshaw (1):
avcodec/libopenjpegdec: Set key frame metadata
libavcodec/libopenjpegdec.c | 2 ++
1 file changed, 2 insertions(+)
--
2.10.1 (Apple Git-78
From: Michael Bradshaw
Signed-off-by: Michael Bradshaw
---
libavcodec/libopenjpegdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index b4ce834..f09f4ba 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec
On Thu, Oct 13, 2016 at 6:49 PM, Michael Niedermayer wrote:
>
> > libopenjpegenc.c | 18 +-
> > 1 file changed, 9 insertions(+), 9 deletions(-)
> > 17061aee3e88729993c9581f688cbfda01fccaac 0001-libopenjpegenc-fix-out-
> of-bounds-reads-when-filling-.patch
> > From 1461064c1eaab
On Thu, Oct 13, 2016 at 12:21 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
>
> OK. Attached patch does that for openjpeg 2.
> I didn't change the behavior for openjpeg 1, as reusing the image works
> there.
Looks good to me. Thanks! Please feel free to apply it.
__
On Wed, Oct 12, 2016 at 8:30 AM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
>
> Updated patch attached.
New patch looks good to me (though I don't have push privileges so can't
commit it).
Thanks!
___
ffmpeg-devel mailing list
ffmpeg-
On Wed, Oct 12, 2016 at 8:45 AM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> On 12.10.2016 03:42, Michael Bradshaw wrote:
> > On Tue, Oct 11, 2016 at 9:57 AM, Andreas Cadhalpun <
> > andreas.cadhal...@googlemail.com> wrote:
> >
> >>
On Tue, Oct 11, 2016 at 6:35 PM, Michael Bradshaw wrote:
>
> On Tue, Oct 11, 2016 at 11:37 AM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>>
>> + check_lib2 openjpeg-2.1/openjpeg
On Tue, Oct 11, 2016 at 9:57 AM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> openjpeg 2 sets the data pointers of the image components to NULL,
> causing segfaults if the image is reused.
>
I've never seen this issue. Is there a particular version of OpenJPEG or
reproduction st
Oh man, I literally just wrote a patch for this today. You beat me by 6
hours. Anyway, thanks for the patch!
On Tue, Oct 11, 2016 at 11:37 AM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> Use check_lib2 to test the header together with the function. This is
> necessary, because
Could this patch please be reapplied? It seems like it was accidentally
reverted in commit 5d48e4eafa6c4559683892b8638d10508125f3cf
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi,
Attached patch fixes the MKV muxer when trying to write Void elements that
have a size < 10. The current code subtracts 1 from the size, which
accounts for the element ID byte, but it doesn't account for the additional
size byte. This causes the Void element to take up 1 more byte than
intende
On Sun, Jul 24, 2016 at 10:09 PM, Kia wrote:
> This fixes bug #5694 and builds with libopenjpeg 2.1.1.
>
> openjpeg commit 3ed5858902055d3500a6ab183f1395686921d026 hides all
> symbols with __attribute__ ((visibility ("hidden"))) if OPJ_STATIC is
> defined
>
> Signed-off-by: Kia
> ---
> libavcod
On Tue, Jun 21, 2016 at 12:22 PM, Michael Niedermayer
wrote:
> what does "supported" / "unsupported" mean, is this defined somewhere ?
As far as WebM is concerned, SegmentUID doesn't exist.
In this situation, writing SegmentUID is Undefined-Ignore or
Optional-Fail/Forbidden, depending on the fil
Hi,
Attached patch removes SegmentUID element from WebM files, as it's
unsupported in WebM[1].
Please review/apply.
Thanks,
Michael
[1]: https://www.webmproject.org/docs/container/#SegmentUID
0001-libavformat-matroskaenc-omit-segment-UID-for-webm.patch
Description: Binary data
__
Tested with OpenJPEG 1.5, 2.0, and 2.1 on OS X with clang. Correctly
decoded and re-encoded the balloon.jp2 sample.
On Sun, Apr 3, 2016 at 2:34 PM, Aaron Boxer wrote:
> From d12c685578f21b403f6c03505edd84db367306c5 Mon Sep 17 00:00:00 2001
> From: Aaron Boxer
> Date: Sun, 27 Mar 2016 00:15:20 -0
Hi Aaron,
This mailing list is intended for the development of FFmpeg itself. It
sounds like you're working on your own project or personal
customizations (without the plan of trying to upstream the changes
into the mainline FFmpeg code), in which case the libav-user mailing
list sounds like the m
On Wed, Mar 23, 2016 at 12:24 PM, Aaron Boxer wrote:
> Hello Again,
>
> I took a look at the FFmpeg j2k code. Now, I've worked with OpenJPEG for
> many years, and I would say at least 20% of the code in FFmpeg was either
> directly copied from OpenJPEG, or is very similar to OpenJPEG code.
>
> I t
On Mon, Feb 15, 2016 at 9:57 AM, Mark Harris wrote:
> Avoid invalid memory read/crash when ico offset >= 0xfff8.
> Base64-encoded example: AAABADAwMDAwMAAAMAAwMDAw/P///w==
> ---
> libavformat/icodec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/icodec.
On Friday, February 5, 2016, Hendrik Leppkes wrote:
> On Fri, Feb 5, 2016 at 9:33 PM, Michael Bradshaw > wrote:
> > Hi,
> >
> > Attached patch fixes building ffmpeg on OS X with the following
> > configuration: --disable-optimizations --disable-asm
>
> >
Hi,
Attached patch fixes building ffmpeg on OS X with the following
configuration: --disable-optimizations --disable-asm
Without this patch the following error is observed:
LD ffmpeg_g
Undefined symbols for architecture x86_64:
"_ff_spatial_idwt_init_mmx", referenced from:
_ff_spatial_id
1 - 100 of 118 matches
Mail list logo
