[FFmpeg-devel] [PATCH] avformat/movenc: remove write_colr flag and write colr by default
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 values for all of color_primaries, color_trc, and color_space. Additionally, this stops guessing the primaries/trc/matrix. Please review. 0001-avformat-movenc-remove-write_colr-flag-and-write-col.patch Description: Binary data ___ 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 subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: remove write_colr flag and write colr by default
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@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: remove write_colr flag and write colr by default
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 set to 2 (Unspecified). In that case this patch is wrong because it will not write the colr atom. The original code doesn't work for this either because it will try to guess the values instead of writing "unspecified". I'm going to abandon this patch for now. [1]: https://developer.apple.com/av-foundation/High-Dynamic-Range-Metadata-for-Apple-Devices.pdf > ___ 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 subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/movenc: stop guessing colr atom values
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
___
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 subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/movenc: write the colr atom by default
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 profile, OR - The user specified +write_colr - Remove the experimental notice from the write_colr flag. - Keep the write_colr flag for situations where the user wants to write the colr atom even if the color info is unspecified (e.g., http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259334.html) This fixes https://trac.ffmpeg.org/ticket/7961 Please review. --Michael 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, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: write the colr atom by default
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. Attached is a patch with an updated commit message that includes this information in the commit message. 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, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: stop guessing colr atom values
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 the wrong thing to do and we should respect "unspecified" since we really don't know. I'd be okay with maybe emitting a warning if we're writing unspecified values. ___ 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 subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: stop guessing colr atom values
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 originally added. Unfortunately I don't see the original patch in the ffmpeg-devel archives so I don't know what discussions there were around it originally. But I would counter with the following: 1. The user can guess if they want using the -color_primaries/-color_trc/-colorspace flags. 2. If ffmpeg does want to guess, this is the wrong place to do it. There are various parts of ffmpeg that deal with color primaries/trc/space. The right way to guess this info is higher up in the pipeline where it can be consistently applied throughout the pipeline and bitstream. Doing it locally here is just begging for one part of ffmpeg to make one assumption and this part to make a different assumption, which would be even worse. 3. Building on point 2, this is an especially bad place to guess this because the color info is a property of the input, not the output. If this really breaks things for people (which I highly doubt it will) they can always send a patch with a better and more robust implementation. But I feel strongly that we should not stabilize the write_colr flag with this auto-guessing logic. We really shouldn't have people depend on it and should encourage them to use the -color_primaries/-color_trc/-colorspace flags themselves for better color guessing. ___ 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 subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/movenc: add write_clli flag to write clli atom
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 can switch this to write the clli atom by default (if the metadata exists) and remove the write_clli flag. [1]: https://aomedia.org/wp-content/uploads/2018/09/AV1-ISO-Base-Media-File-Format-Binding-Specification.pdf [2]: https://developer.apple.com/av-foundation/High-Dynamic-Range-Metadata-for-Apple-Devices.pdf 0001-avformat-movenc-add-write_clli-flag-to-write-clli-at.patch Description: Binary data ___ 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 subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/movenc: use enum values directly for colr atom
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, and ictcp. They also annoyingly remapped the following (which are functionally equivalent but can be treated differently by clients): - smpte240m primaries to smpte170m. - smpte170m TRC to bt709. - bt470bg color space to smpte170m. The enum values in FFmpeg are the same values as ITU-T H.273 and ISO/IEC 23001-8 so we can just use them directly, which is both simpler and preserves the user intent. 0001-avformat-movenc-use-enum-values-directly-for-colr-at.patch Description: Binary data ___ 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 subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/movenc: add write_mdcv flag to write mdcv atom
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 can switch this to write the mdcv atom by default (if the metadata exists) and remove the write_mdcv flag. [1]: https://aomedia.org/wp-content/uploads/2018/09/AV1-ISO-Base-Media-File-Format-Binding-Specification.pdf [2]: https://developer.apple.com/av-foundation/High-Dynamic-Range-Metadata-for-Apple-Devices.pdf 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/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: add write_clli flag to write clli atom
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 ___ 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 subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: add write_clli flag to write clli atom
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 references that I've been able to find about this atom are in the two links in my original email, which isn't satisfactory to me personally. I asked one of the authors of the AV1-ISOBMFF spec, and they said it has > been > standardized in MIAF (23000-22), and should make their way back to > 14496-12 in > the next edition. One idea is to allow it for AV1 by default, but, as > above, it > is perhaps too confusing from a user perspective to do that. > I'm not necessarily opposed to that but I have a (slight) preference for not doing that for the reasons of confusion you mentioned. Aside: Is there an value in also supporting the mdcv box (in general)? Yes, definitely, and I've sent out a patch to do that[1]. Admittedly there's a merge conflict between these two patches because I did them separately but that's simple enough to solve manually. [1]: http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259418.html ___ 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 subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: add write_clli flag to write clli atom
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 BMFF at all). SMPTE ST 2086 defines the mastering metadata at a conceptual level but doesn't specify how it is signaled. Thanks for the review. I pushed the patch. ___ 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 subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: add write_mdcv flag to write mdcv atom
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/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: add write_clli flag to write clli atom
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 have it be opt-in until it's standardized. ___ 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 subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: add write_clli flag to write clli atom
> 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 formally specified. On Wed, Apr 1, 2020 at 2:07 PM James Almer wrote: > If anything, I'd rather have these boxes (clli and mdcv) written when > strict_std_compliance <= experimental than adding a new muxer option. `-strict -2` might have other side effects though. Also I think adding new muxer options are much more discoverable for users because you can see how to enable clli/mdcv with `-h full`. The write_clli/write_mdcv flags are meant to be temporary, anyway. On Wed, Apr 1, 2020 at 2:48 PM Jan Ekström wrote: > If we want to enable possibly-MIAF-specific things in normal MP4, then > we could enable it by default already. If MIAF specifies both clli and mdcv and you can confirm we're writing them correctly then I could be convinced to skip the experimental phase in FFmpeg and just write them by default. I haven't bought a copy of MIAF but I will if it'll help us sort this out. ___ 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 subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: add write_clli flag to write clli atom
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 the box always written if the conditions you > listed in that patch are met, much like every other box in the container. I want to remove the write_colr flag and actually tried to in my first patch but it broke use cases where "unspecified" is valid and intended. If FFmpeg had a way to differentiate between "unspecified" (enum value 2) and "unset" (no enum value) for color primaries/trc/matrix then we could remove the write_colr flag. But the simplest way to deal with this shortcoming was to just use the write_colr flag. If anyone has any bright ideas on how to differentiate between "unspecified" and "unset" for color info, I'm open to suggestions. For example, I've thought of adding a new enum value (e.g., AVCOL_PRI_UNSET = -1) but I've got mixed feelings about that. ___ 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 subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/movenc: remove the write_clli mov flag
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 ___ 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 subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: add write_mdcv flag to write mdcv atom
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-default.patch Description: Binary data ___ 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 subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: stop guessing colr atom values
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, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: use enum values directly for colr atom
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 subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: remove the write_clli mov flag
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. ___ 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 subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: add write_mdcv flag to write mdcv atom
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-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: write the colr atom by default
At the risk of being too non-committal, attached patch is mostly the same
but leaves the write_colr flag as experimental. I would love to remove the
write_colr flag entirely but we should provide some kind of escape hatch to
allow ffmpeg to write "unspecified" (enum value 2) values for the colr atom
(after all, these are legitimate values in H.273). Here are the reasons I'm
not sold on stabilizing write_colr right now:
- It only fixes mov files. mkv has the same problem. It would be nice to
stabilize a solution that isn't per-format.
- I'm not motivated to spend the time exploring and debating alternative
solutions like signaling "unspecified" (enum value 2) values differently
from "unset" (no value from H.273) somehow (e.g., use enum value -1, or add
a separate bool flag to signal whether the values are just ffmpeg defaults
or not).
- This approach solves the use cases with which I'm most familiar. I'm
not as familiar with situations where people want to write "unspecified"
enum values in the colr atom. I'd rather leave this for other people (who
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 years.
It should be safe to enable its behavior by default as follows:
- 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 profile, OR
- The user specified +write_colr
- Keep the write_colr flag for situations where the user wants to
write the colr atom even if the color info is unspecified (e.g.,
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259334.html)
This fixes https://trac.ffmpeg.org/ticket/7961
Signed-off-by: Michael Bradshaw
---
libavformat/movenc.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index bc8d08044e..4a4c9ce481 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -77,7 +77,7 @@ static const AVOption options[] = {
{ "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_colr", "Write colr atom even if the color info is unspecified (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" },
{ "prefer_icc", "If writing colr atom prioritise usage of ICC profile if it exists in stream packet side data", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_PREFER_ICC}, 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" },
@@ -2135,11 +2135,17 @@ static int mov_write_video_tag(AVFormatContext *s, AVIOContext *pb, MOVMuxContex
else
av_log(mov->fc, AV_LOG_WARNING, "Not writing 'gama' atom. Format is not MOV.\n");
}
-if (mov->flags & FF_MOV_FLAG_WRITE_COLR) {
-if (track->mode == MODE_MOV || track->mode == MODE_MP4)
-mov_write_colr_tag(pb, track, mov->flags & FF_MOV_FLAG_PREFER_ICC);
-else
-av_log(mov->fc, AV_LOG_WARNING, "Not writing 'colr' atom. Format is not MOV or MP4.\n");
+if (track->mode == MODE_MOV || track->mode == MODE_MP4) {
+int has_color_info = track->par->color_primaries != AVCOL_PRI_UNSP
Re: [FFmpeg-devel] [PATCH] avformat/movenc: stop guessing colr atom values
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 ___ 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 subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: stop guessing colr atom values
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: Binary data ___ 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 subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: write the colr atom by default
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, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC PATCH] libavcodec/libopenjpeg: pix fmt selection change
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 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
> index 344c5ba5a3..f5f208784e 100644
> --- a/libavcodec/libopenjpegdec.c
> +++ b/libavcodec/libopenjpegdec.c
> @@ -272,11 +272,11 @@ static inline void libopenjpeg_copyto8(AVFrame
> *picture, opj_image_t *image) {
> int *comp_data;
> uint8_t *img_ptr;
> int index, x, y;
> -
> for (index = 0; index < image->numcomps; index++) {
> +int plane = index?index-1:image->numcomps-1;
>
Won't this break things for other pictures (e.g., RGB, YUV, etc.)?
comp_data = image->comps[index].data;
> for (y = 0; y < image->comps[index].h; y++) {
> -img_ptr = picture->data[index] + y * picture->linesize[index];
> +img_ptr = picture->data[plane] + y * picture->linesize[plane];
> for (x = 0; x < image->comps[index].w; x++) {
> *img_ptr = 0x80 * image->comps[index].sgnd + *comp_data;
> img_ptr++;
> @@ -408,6 +408,23 @@ static int libopenjpeg_decode_frame(AVCodecContext
> *avctx,
> if (avctx->pix_fmt == AV_PIX_FMT_NONE)
> avctx->pix_fmt = libopenjpeg_guess_pix_fmt(image);
>
> +if (avctx->pix_fmt == AV_PIX_FMT_NONE) {
> +if (image->numcomps == 4 &&
> +image->comps[0].dx == 1 && image->comps[0].dy == 1 &&
> +image->comps[1].dx == 1 && image->comps[1].dy == 1 &&
> +image->comps[2].dx == image->comps[3].dx &&
> +image->comps[2].dy == image->comps[3].dy) {
> +int maxprec = 0;
> +for (int i = 0; i < 4; i++)
> +maxprec = FFMAX(maxprec, image->comps[i].prec);
> +if (maxprec == 8 &&
> +image->comps[2].dx == 2 &&
> +image->comps[2].dy == 2) {
> +avctx->pix_fmt = AV_PIX_FMT_YUVA420P;
> +}
> +}
> +}
> +
>
Please move this up to libopenjpeg_guess_pix_fmt.
Also, are the planes stored in this image stored in AYUV order?
___
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 subject "unsubscribe".
Re: [FFmpeg-devel] [RFC PATCH] libavcodec/libopenjpeg: pix fmt selection change
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 like a good idea, I could go through > opj_decompress > and try to replicate what it does. I don't think this is a real image. I think it's probably just a synthetic image for the purposes of conformance testing. p1_03.j2k and p0_05.j2k (and others) are too weird. I decoded p1_03.j2k's components into different files (opj_decompress -i p1_03.j2k -split-pnm -o /tmp/p1_03.pgm) and inspected each one. Additionally, I cat'd the raw gray8 pixel values to construct raw yuv420p frames. I created 4 raw yuv420p frames using every valid combination of p1_03.j2k's four planes. All of them looked like garbage. That's not too surprising. Each plane has dark near-zero pixel values in the sky region. A bright region like the sky should have high pixel values for the Y-plane. I highly suspect this j2k file is synthetic and just tests whether or not a decoder can decode the planes, but that doesn't test whether or not they can be sensibly displayed (and I'd argue they can't be sensibly displayed). ___ 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 subject "unsubscribe".
Re: [FFmpeg-devel] [RFC PATCH] libavcodec/libopenjpeg: pix fmt selection change
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 suggestions for that? Does the other file with a ppm marker have a sane pixel format? If not the only the only way I can think of to test this is to hack ffmpeg to remap the planes in libopenjpegdec.c (e.g., remap them to yuva format). You can use that for initial validation but it'll have to be reverted when committing/pushing. Long-term I'm not sure how one would regression test this without having a different file with a sane pixel format. I'm not sure how feasible it is to hack p1_03.j2k to remove a plane while retaining the ppm marker or perhaps hacking opj_compress to add a ppm marker to a new test file. ___ 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 subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/dnxhddec: do not warn if CID == 1271 && CLF == 0 && CLV > 0
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 warn on files that were perfectly valid
(e.g., CID == 1271 && CLF == 0 && CLV == 1).
See SMPTE ST 2019-1:2016, section 7.2.5 ("Coding Control B").
Please review (and double check my interpretation of the standard).
Thanks,
--Michael
0001-lavc-dnxhddec-do-not-warn-if-CID-1271-CLF-0-CLV-0.patch
Description: Binary data
___
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 subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavf: stop filtering side data in mkv
matroskaenc.c currently only allows BlockMore elements if the BlockAddID is
1. Recently YouTube has been using BlockAddID == 4 for HDR10+ dynamic
metadata (see [1]), which FFmpeg drops because of its filtering.
The attached patch changes matroskaenc.c so it stops filtering
by BlockAddID, allowing 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 filtering side data in mkv
---
libavformat/matroskaenc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 42f21eae8b..b561a4538e 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -2147,7 +2147,7 @@ static int mkv_write_block(AVFormatContext *s, AVIOContext *pb,
side_data_size -= 8;
}
-if ((side_data_size && additional_id == 1) || discard_padding) {
+if (side_data_size || discard_padding) {
block_group = start_ebml_master(pb, MATROSKA_ID_BLOCKGROUP, 0);
blockid = MATROSKA_ID_BLOCK;
}
@@ -2171,17 +2171,17 @@ static int mkv_write_block(AVFormatContext *s, AVIOContext *pb,
put_ebml_sint(pb, MATROSKA_ID_DISCARDPADDING, discard_padding);
}
-if (side_data_size && additional_id == 1) {
+if (side_data_size) {
block_additions = start_ebml_master(pb, MATROSKA_ID_BLOCKADDITIONS, 0);
block_more = start_ebml_master(pb, MATROSKA_ID_BLOCKMORE, 0);
-put_ebml_uint(pb, MATROSKA_ID_BLOCKADDID, 1);
+put_ebml_uint(pb, MATROSKA_ID_BLOCKADDID, additional_id);
put_ebml_id(pb, MATROSKA_ID_BLOCKADDITIONAL);
put_ebml_num(pb, side_data_size, 0);
avio_write(pb, side_data, side_data_size);
end_ebml_master(pb, block_more);
end_ebml_master(pb, block_additions);
}
-if ((side_data_size && additional_id == 1) || discard_padding) {
+if (side_data_size || discard_padding) {
end_ebml_master(pb, block_group);
}
--
2.24.0.525.g8f36a354ae-goog
___
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 subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavf: stop filtering side data in mkv
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 currently no check that the size > of the BlockAdditions-side-data is at least eight > That's a pre-existing bug, but yes, it's worth fixing and I'll wait for [2] to be merged. 3. Anyway, your patch would allow to write BlockAdditions with a BlockAddID > of zero, although that value is illegal. I'll update the patch to prevent that, thanks. I'll re-send the patch once [2] is merged. ___ 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 subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fftools/ffplay: 240M matrix is not the same as BT.601
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_JPEG, /**< Full range JPEG */ SDL_YUV_CONVERSION_BT601, /**< BT.601 (the default) */ SDL_YUV_CONVERSION_BT709, /**< BT.709 */ (and automatic, but that's just BT.601 + BT.709) It's probably better to fall back to using BT.709 matrix for SMPTE 240M (with a warning log) since BT.709 is closer to SMPTE 240M than BT.601 is. ___ 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 subject "unsubscribe".
Re: [FFmpeg-devel] [FFmpeg-cvslog] ffmpeg: Add -time_base option to hint the time base
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 each day reminding me to get it done. I just haven't gotten the time to work on it yet, unfortunately. But I'm hoping to be able to carve out some time for this at the end of April. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fate: add test for -time_base option
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/209432.html 0001-fate-add-test-for-time_base-option.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fate: fix source test for sofa2wavs
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 ./tests --- ./tests/ref/fate/source 2017-06-12 10:34:46.0 -0700 +++ tests/data/fate/source 2017-06-12 10:48:27.0 -0700 @@ -12,6 +12,7 @@ libavformat/log2_tab.c libswresample/log2_tab.c libswscale/log2_tab.c +tools/sofa2wavs.c tools/uncoded_frame.c tools/yuvcmp.c Headers without standard inclusion guards: Test source failed. Look at tests/data/fate/source.err for details. make: *** [fate-source] Error 1 Attached patch updates fate to include the sofa2wavs tool. Please review. Thanks, --Michael 0001-fate-fix-source-test-for-sofa2wavs.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: fix source test for sofa2wavs
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 header? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add test for -time_base option
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 muxers of the same name) would be a better > test. Those report the output timebase in a quick and easily readable way. Thanks for pointing that out! I didn't know they reported the time base in addition to the MD5 of the frames. I've attached a patch that changes the fate test to use framemd5. Please review. 0001-fate-use-framemd5-for-time_base-testing.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] configure/libopenjpegdec.c/libopenjpegenc.c: Add support for LibOpenJPEG v2.2/git
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
missing the openjpeg_2_2_openjpeg_h entry in HEADERS_LIST in configure, so
you shouldn't be able to successfully build with OpenJPEG v2.2.
> From df61d7a295bec74c85d37042051e9dc1ef5cdbce Mon Sep 17 00:00:00 2001
> From: Reino17
> Date: Tue, 13 Jun 2017 01:01:07 +0200
> Subject: [PATCH] Add support for LibOpenJPEG v2.2/git
> ---
> configure | 3 ++-
> libavcodec/libopenjpegdec.c | 10 +++---
> libavcodec/libopenjpegenc.c | 12
> 3 files changed, 17 insertions(+), 8 deletions(-)
> diff --git a/configure b/configure
> index e3941f9..003d359 100755
> --- a/configure
> +++ b/configure
> @@ -5831,7 +5831,8 @@ enabled libopencv && { check_header
opencv2/core/core_c.h &&
> require opencv opencv2/core/core_c.h
cvCreateImageHeader -lopencv_core -lopencv_imgproc; } ||
> require_pkg_config opencv opencv/cxcore.h
cvCreateImageHeader; }
> enabled libopenh264 && require_pkg_config openh264
wels/codec_api.h WelsGetCodecVersion
> -enabled libopenjpeg && { { check_lib libopenjpeg
openjpeg-2.1/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags
-DOPJ_STATIC; } ||
> +enabled libopenjpeg && { { check_lib libopenjpeg
openjpeg-2.2/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags
-DOPJ_STATIC; } ||
> + { check_lib libopenjpeg
openjpeg-2.1/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags
-DOPJ_STATIC; } ||
> check_lib libopenjpeg
openjpeg-2.1/openjpeg.h opj_version -lopenjp2 ||
> { check_lib libopenjpeg
openjpeg-2.0/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags
-DOPJ_STATIC; } ||
> { check_lib libopenjpeg
openjpeg-1.5/openjpeg.h opj_version -lopenjpeg -DOPJ_STATIC && add_cppflags
-DOPJ_STATIC; } ||
> diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
> index ce4e2b0..5ed9ce1 100644
> --- a/libavcodec/libopenjpegdec.c
> +++ b/libavcodec/libopenjpegdec.c
> @@ -34,7 +34,9 @@
> #include "internal.h"
> #include "thread.h"
>
> -#if HAVE_OPENJPEG_2_1_OPENJPEG_H
> +#if HAVE_OPENJPEG_2_2_OPENJPEG_H
> +# include
> +#elif HAVE_OPENJPEG_2_1_OPENJPEG_H
> # include
> #elif HAVE_OPENJPEG_2_0_OPENJPEG_H
> # include
> @@ -44,7 +46,7 @@
> # include
> #endif
>
> -#if HAVE_OPENJPEG_2_1_OPENJPEG_H || HAVE_OPENJPEG_2_0_OPENJPEG_H
> +#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H ||
HAVE_OPENJPEG_2_0_OPENJPEG_H
> # define OPENJPEG_MAJOR_VERSION 2
> # define OPJ(x) OPJ_##x
> #else
> @@ -429,7 +431,9 @@ static int libopenjpeg_decode_frame(AVCodecContext
*avctx,
> opj_stream_set_read_function(stream, stream_read);
> opj_stream_set_skip_function(stream, stream_skip);
> opj_stream_set_seek_function(stream, stream_seek);
> -#if HAVE_OPENJPEG_2_1_OPENJPEG_H
> +#if HAVE_OPENJPEG_2_2_OPENJPEG_H
> +opj_stream_set_user_data(stream, &reader, NULL);
> +#elif HAVE_OPENJPEG_2_1_OPENJPEG_H
> opj_stream_set_user_data(stream, &reader, NULL);
Please merge these two into just one #if branch. That is:
#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H
opj_stream_set_user_data(stream, &reader, NULL);
#elif HAVE_OPENJPEG_2_0_OPENJPEG_H
...
> #elif HAVE_OPENJPEG_2_0_OPENJPEG_H
> opj_stream_set_user_data(stream, &reader);
> diff --git a/libavcodec/libopenjpegenc.c b/libavcodec/libopenjpegenc.c
> index 4a12729..d3b9161 100644
> --- a/libavcodec/libopenjpegenc.c
> +++ b/libavcodec/libopenjpegenc.c
> @@ -32,7 +32,9 @@
> #include "avcodec.h"
> #include "internal.h"
>
> -#if HAVE_OPENJPEG_2_1_OPENJPEG_H
> +#if HAVE_OPENJPEG_2_2_OPENJPEG_H
> +# include
> +#elif HAVE_OPENJPEG_2_1_OPENJPEG_H
> # include
> #elif HAVE_OPENJPEG_2_0_OPENJPEG_H
> # include
> @@ -42,7 +44,7 @@
> # include
> #endif
>
> -#if HAVE_OPENJPEG_2_1_OPENJPEG_H || HAVE_OPENJPEG_2_0_OPENJPEG_H
> +#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H ||
HAVE_OPENJPEG_2_0_OPENJPEG_H
> # define OPENJPEG_MAJOR_VERSION 2
> # define OPJ(x) OPJ_##x
> #else
> @@ -305,7 +307,7 @@ static av_cold int
libopenjpeg_encode_init(AVCodecContext *avctx)
>
> opj_set_default_encoder_parameters(&ctx->enc_params);
>
> -#if HAVE_OPENJPEG_2_1_OPENJPEG_H
> +#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H
> switch (ctx->cinema_mode) {
> case OPJ_CINEMA2K_24:
> ctx->enc_params.rsiz = OPJ_PROFILE_CINEMA_2K;
> @@ -769,7 +771,9 @@ static int libopenjpeg_encode_frame(AVCodecContext
*avctx, AVPacket *pkt,
> opj_stream_set_write_function(stream, stream_write);
> opj_
Re: [FFmpeg-devel] configure/libopenjpegdec.c/libopenjpegenc.c: Add support for LibOpenJPEG v2.2/git
> 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/libopenjpegenc.c | 12
> 3 files changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/configure b/configure
> index e3941f9..0190966 100755
> --- a/configure
> +++ b/configure
> @@ -1868,6 +1868,7 @@ HEADERS_LIST="
> machine_ioctl_meteor_h
> malloc_h
> opencv2_core_core_c_h
> +openjpeg_2_2_openjpeg_h
> openjpeg_2_1_openjpeg_h
> openjpeg_2_0_openjpeg_h
> openjpeg_1_5_openjpeg_h
> @@ -5831,7 +5832,8 @@ enabled libopencv && { check_header
opencv2/core/core_c.h &&
> require opencv opencv2/core/core_c.h
cvCreateImageHeader -lopencv_core -lopencv_imgproc; } ||
> require_pkg_config opencv opencv/cxcore.h
cvCreateImageHeader; }
> enabled libopenh264 && require_pkg_config openh264
wels/codec_api.h WelsGetCodecVersion
> -enabled libopenjpeg && { { check_lib libopenjpeg
openjpeg-2.1/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags
-DOPJ_STATIC; } ||
> +enabled libopenjpeg && { { check_lib libopenjpeg
openjpeg-2.2/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags
-DOPJ_STATIC; } ||
> + { check_lib libopenjpeg
openjpeg-2.1/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags
-DOPJ_STATIC; } ||
> check_lib libopenjpeg
openjpeg-2.1/openjpeg.h opj_version -lopenjp2 ||
> { check_lib libopenjpeg
openjpeg-2.0/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags
-DOPJ_STATIC; } ||
> { check_lib libopenjpeg
openjpeg-1.5/openjpeg.h opj_version -lopenjpeg -DOPJ_STATIC && add_cppflags
-DOPJ_STATIC; } ||
> diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
> index ce4e2b0..5ed9ce1 100644
> --- a/libavcodec/libopenjpegdec.c
> +++ b/libavcodec/libopenjpegdec.c
> @@ -34,7 +34,9 @@
> #include "internal.h"
> #include "thread.h"
>
> -#if HAVE_OPENJPEG_2_1_OPENJPEG_H
> +#if HAVE_OPENJPEG_2_2_OPENJPEG_H
> +# include
> +#elif HAVE_OPENJPEG_2_1_OPENJPEG_H
> # include
> #elif HAVE_OPENJPEG_2_0_OPENJPEG_H
> # include
> @@ -44,7 +46,7 @@
> # include
> #endif
>
> -#if HAVE_OPENJPEG_2_1_OPENJPEG_H || HAVE_OPENJPEG_2_0_OPENJPEG_H
> +#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H ||
HAVE_OPENJPEG_2_0_OPENJPEG_H
> # define OPENJPEG_MAJOR_VERSION 2
> # define OPJ(x) OPJ_##x
> #else
> @@ -429,7 +431,9 @@ static int libopenjpeg_decode_frame(AVCodecContext
*avctx,
> opj_stream_set_read_function(stream, stream_read);
> opj_stream_set_skip_function(stream, stream_skip);
> opj_stream_set_seek_function(stream, stream_seek);
> -#if HAVE_OPENJPEG_2_1_OPENJPEG_H
> +#if HAVE_OPENJPEG_2_2_OPENJPEG_H
> +opj_stream_set_user_data(stream, &reader, NULL);
> +#elif HAVE_OPENJPEG_2_1_OPENJPEG_H
> opj_stream_set_user_data(stream, &reader, NULL);
Please merge these two conditions, since both #if conditions are executing
the same code. That is:
#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H
opj_stream_set_user_data(stream, &reader, NULL);
#elif HAVE_OPENJPEG_2_0_OPENJPEG_H
...
> #elif HAVE_OPENJPEG_2_0_OPENJPEG_H
> opj_stream_set_user_data(stream, &reader);
> diff --git a/libavcodec/libopenjpegenc.c b/libavcodec/libopenjpegenc.c
> index 4a12729..d3b9161 100644
> --- a/libavcodec/libopenjpegenc.c
> +++ b/libavcodec/libopenjpegenc.c
> @@ -32,7 +32,9 @@
> #include "avcodec.h"
> #include "internal.h"
>
> -#if HAVE_OPENJPEG_2_1_OPENJPEG_H
> +#if HAVE_OPENJPEG_2_2_OPENJPEG_H
> +# include
> +#elif HAVE_OPENJPEG_2_1_OPENJPEG_H
> # include
> #elif HAVE_OPENJPEG_2_0_OPENJPEG_H
> # include
> @@ -42,7 +44,7 @@
> # include
> #endif
>
> -#if HAVE_OPENJPEG_2_1_OPENJPEG_H || HAVE_OPENJPEG_2_0_OPENJPEG_H
> +#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H ||
HAVE_OPENJPEG_2_0_OPENJPEG_H
> # define OPENJPEG_MAJOR_VERSION 2
> # define OPJ(x) OPJ_##x
> #else
> @@ -305,7 +307,7 @@ static av_cold int
libopenjpeg_encode_init(AVCodecContext *avctx)
>
> opj_set_default_encoder_parameters(&ctx->enc_params);
>
> -#if HAVE_OPENJPEG_2_1_OPENJPEG_H
> +#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H
> switch (ctx->cinema_mode) {
> case OPJ_CINEMA2K_24:
> ctx->enc_params.rsiz = OPJ_PROFILE_CINEMA_2K;
> @@ -769,7 +771,9 @@ static int libopenjpeg_encode_frame(AVCodecContext
*avctx, AVPacket *pkt,
> opj_stream_set_write_function(stream, stream_write);
> opj_stream_set_skip_function(stream, stream_skip);
> opj_stream_set_seek_function(stream, stream_seek);
> -#if HAVE_OPENJPEG_2_1_OPENJPEG_H
> +#if HAVE_OP
Re: [FFmpeg-devel] configure/libopenjpegdec.c/libopenjpegenc.c: Add support for LibOpenJPEG v2.2/git
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 mimic both
of those for v2.2. That is, the configure script diff should be:
...
+enabled libopenjpeg && { { check_lib libopenjpeg
openjpeg-2.2/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags
-DOPJ_STATIC; } ||
+ check_lib libopenjpeg
openjpeg-2.2/openjpeg.h opj_version -lopenjp2 ||
+ { check_lib libopenjpeg
openjpeg-2.1/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags
-DOPJ_STATIC; } ||
check_lib libopenjpeg
openjpeg-2.1/openjpeg.h opj_version -lopenjp2 ||
...
--Michael
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/1] lavc: add support for OpenJPEG 2.3.0
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..77c9a18c3c 100755
--- a/configure
+++ b/configure
@@ -1930,6 +1930,7 @@ HEADERS_LIST="
machine_ioctl_meteor_h
malloc_h
opencv2_core_core_c_h
+openjpeg_2_3_openjpeg_h
openjpeg_2_2_openjpeg_h
openjpeg_2_1_openjpeg_h
openjpeg_2_0_openjpeg_h
@@ -5950,7 +5951,9 @@ enabled libopencv && { check_header
opencv2/core/core_c.h &&
require opencv opencv2/core/core_c.h
cvCreateImageHeader -lopencv_core -lopencv_imgproc; } ||
require_pkg_config libopencv opencv
opencv/cxcore.h cvCreateImageHeader; }
enabled libopenh264 && require_pkg_config libopenh264 openh264
wels/codec_api.h WelsGetCodecVersion
-enabled libopenjpeg && { { check_lib libopenjpeg openjpeg-2.2/openjpeg.h
opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
+enabled libopenjpeg && { { check_lib libopenjpeg openjpeg-2.3/openjpeg.h
opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
+ check_lib libopenjpeg openjpeg-2.3/openjpeg.h
opj_version -lopenjp2 ||
+ { check_lib libopenjpeg openjpeg-2.2/openjpeg.h
opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
check_lib libopenjpeg openjpeg-2.2/openjpeg.h
opj_version -lopenjp2 ||
{ check_lib libopenjpeg openjpeg-2.1/openjpeg.h
opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
check_lib libopenjpeg openjpeg-2.1/openjpeg.h
opj_version -lopenjp2 ||
diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index 1210123265..67d47bd6a0 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
@@ -34,7 +34,9 @@
#include "internal.h"
#include "thread.h"
-#if HAVE_OPENJPEG_2_2_OPENJPEG_H
+#if HAVE_OPENJPEG_2_3_OPENJPEG_H
+# include
+#elif HAVE_OPENJPEG_2_2_OPENJPEG_H
# include
#elif HAVE_OPENJPEG_2_1_OPENJPEG_H
# include
@@ -46,7 +48,7 @@
# include
#endif
-#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H ||
HAVE_OPENJPEG_2_0_OPENJPEG_H
+#if HAVE_OPENJPEG_2_3_OPENJPEG_H || HAVE_OPENJPEG_2_2_OPENJPEG_H ||
HAVE_OPENJPEG_2_1_OPENJPEG_H || HAVE_OPENJPEG_2_0_OPENJPEG_H
# define OPENJPEG_MAJOR_VERSION 2
# define OPJ(x) OPJ_##x
#else
@@ -431,7 +433,7 @@ static int libopenjpeg_decode_frame(AVCodecContext *avctx,
opj_stream_set_read_function(stream, stream_read);
opj_stream_set_skip_function(stream, stream_skip);
opj_stream_set_seek_function(stream, stream_seek);
-#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H
+#if HAVE_OPENJPEG_2_3_OPENJPEG_H || HAVE_OPENJPEG_2_2_OPENJPEG_H ||
HAVE_OPENJPEG_2_1_OPENJPEG_H
opj_stream_set_user_data(stream, &reader, NULL);
#elif HAVE_OPENJPEG_2_0_OPENJPEG_H
opj_stream_set_user_data(stream, &reader);
diff --git a/libavcodec/libopenjpegenc.c b/libavcodec/libopenjpegenc.c
index b67e533d1d..92b4433b04 100644
--- a/libavcodec/libopenjpegenc.c
+++ b/libavcodec/libopenjpegenc.c
@@ -32,7 +32,9 @@
#include "avcodec.h"
#include "internal.h"
-#if HAVE_OPENJPEG_2_2_OPENJPEG_H
+#if HAVE_OPENJPEG_2_3_OPENJPEG_H
+# include
+#elif HAVE_OPENJPEG_2_2_OPENJPEG_H
# include
#elif HAVE_OPENJPEG_2_1_OPENJPEG_H
# include
@@ -44,7 +46,7 @@
# include
#endif
-#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H ||
HAVE_OPENJPEG_2_0_OPENJPEG_H
+#if HAVE_OPENJPEG_2_3_OPENJPEG_H || HAVE_OPENJPEG_2_2_OPENJPEG_H ||
HAVE_OPENJPEG_2_1_OPENJPEG_H || HAVE_OPENJPEG_2_0_OPENJPEG_H
# define OPENJPEG_MAJOR_VERSION 2
# define OPJ(x) OPJ_##x
#else
@@ -307,7 +309,7 @@ static av_cold int libopenjpeg_encode_init(AVCodecContext
*avctx)
opj_set_default_encoder_parameters(&ctx->enc_params);
-#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H
+#if HAVE_OPENJPEG_2_3_OPENJPEG_H || HAVE_OPENJPEG_2_2_OPENJPEG_H ||
HAVE_OPENJPEG_2_1_OPENJPEG_H
switch (ctx->cinema_mode) {
case OPJ_CINEMA2K_24:
ctx->enc_params.rsiz = OPJ_PROFILE_CINEMA_2K;
@@ -771,7 +773,7 @@ static int libopenjpeg_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
opj_stream_set_write_function(stream, stream_write);
opj_stream_set_skip_function(stream, stream_skip);
opj_stream_set_seek_function(stream, stream_seek);
-#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H
+#if HAVE_OPENJPEG_2_3_OPENJPEG_H || HAVE_OPENJPEG_2_2_OPENJPEG_H ||
HAVE_OPENJPEG_2_1_OPENJPEG_H
opj_s
[FFmpeg-devel] [PATCH 0/1] lavc: add support for OpenJPEG 2.3.0
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/libopenjpegenc.c | 10 ++ 3 files changed, 15 insertions(+), 8 deletions(-) -- 2.13.5 (Apple Git-94) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf: add more beep options to sine asrc
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/doc/filters.texi
+++ b/doc/filters.texi
@@ -4624,7 +4624,18 @@ Set the carrier frequency. Default is 440 Hz.
@item beep_factor, b
Enable a periodic beep every second with frequency @var{beep_factor} times
-the carrier frequency. Default is 0, meaning the beep is disabled.
+the carrier frequency. Default is 0, meaning the beep is disabled. If
+@var{frequency} is 0, this value is interpreted as the beep frequency (in
Hertz)
+(rather than a multiplier of the @var{frequency}).
+
+@item beep_delay
+The delay for the first beep, in seconds. Default is 0.
+
+@item beep_period
+The time beriod between two beeps, in seconds. Default is 1.
+
+@item beep_duration
+The duration of a beep, in seconds. Default is 0.04.
@item sample_rate, r
Specify the sample rate, default is 44100.
diff --git a/libavfilter/asrc_sine.c b/libavfilter/asrc_sine.c
index 3a87210b4b..643952792f 100644
--- a/libavfilter/asrc_sine.c
+++ b/libavfilter/asrc_sine.c
@@ -32,6 +32,9 @@ typedef struct SineContext {
const AVClass *class;
double frequency;
double beep_factor;
+double beep_delay;
+double beep_period_opt;
+double beep_duration;
char *samples_per_frame;
AVExpr *samples_per_frame_expr;
int sample_rate;
@@ -71,6 +74,9 @@ static const AVOption sine_options[] = {
OPT_DBL("f", frequency,440, 0, DBL_MAX, "set
the sine frequency",),
OPT_DBL("beep_factor", beep_factor,0, 0, DBL_MAX, "set
the beep frequency factor",),
OPT_DBL("b", beep_factor,0, 0, DBL_MAX, "set
the beep frequency factor",),
+OPT_DBL("beep_delay",beep_delay, 0, 0, DBL_MAX, "set
the delay for the first beep",),
+OPT_DBL("beep_period", beep_period_opt,1, DBL_MIN, DBL_MAX,
"set the gap between beeps",),
+OPT_DBL("beep_duration", beep_duration, 0.04, DBL_MIN, DBL_MAX,
"set the duration of a beep",),
OPT_INT("sample_rate", sample_rate,44100, 1, INT_MAX, "set
the sample rate",),
OPT_INT("r", sample_rate,44100, 1, INT_MAX, "set
the sample rate",),
OPT_DUR("duration", duration, 0, 0, INT64_MAX, "set
the audio duration",),
@@ -152,10 +158,13 @@ static av_cold int init(AVFilterContext *ctx)
make_sin_table(sine->sin);
if (sine->beep_factor) {
-sine->beep_period = sine->sample_rate;
-sine->beep_length = sine->beep_period / 25;
-sine->dphi_beep = ldexp(sine->beep_factor * sine->frequency, 32) /
- sine->sample_rate + 0.5;
+unsigned beep_start = sine->beep_delay * sine->sample_rate;
+double beep_frequency = (sine->frequency ? sine->frequency : 1.0) *
+sine->beep_factor;
+sine->beep_period = sine->beep_period_opt * sine->sample_rate;
+sine->beep_index = (sine->beep_period - beep_start) %
sine->beep_period;
+sine->beep_length = sine->beep_duration * sine->sample_rate;
+sine->dphi_beep = ldexp(beep_frequency, 32) / sine->sample_rate + 0.5;
}
ret = av_expr_parse(&sine->samples_per_frame_expr,
--
2.13.5 (Apple Git-94)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] lavc: add support for OpenJPEG 2.3.0
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/libopenjpegdec.c | 8 +--- > > libavcodec/libopenjpegenc.c | 10 ++ > > 3 files changed, 15 insertions(+), 8 deletions(-) > > > > diff --git a/configure b/configure > > index 391c141e7a..77c9a18c3c 100755 > > --- a/configure > > +++ b/configure > > @@ -1930,6 +1930,7 @@ HEADERS_LIST=" > > machine_ioctl_meteor_h > > malloc_h > > opencv2_core_core_c_h > > +openjpeg_2_3_openjpeg_h > > Is there a reason OpenJPEG uses a different folder to store the header > with each release from the 2.x family? It's really bloating both > configure and the wrappers. Yeah, it's really annoying. Once we drop support for 1.x versions we'll be able to clean up the majority of this garbage (though not all of it, unfortunately). I'd personally like to drop support for OpenJPEG 1.x immediately; the only place where it's still used is in package managers for LTS Linux distros, and I have no qualms about telling users to manually build/install a more recent version of OpenJPEG (especially since there are so many bug fixes in recent OpenJPEG versions, many of which are security related). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add support for libopenjpeg 2.3
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 list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add support for libopenjpeg 2.3
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 both clean-up work. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0
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-drop-support-for-OpenJPEG-1.3-2.0.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0
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 file, so change the second argument to > "libopenjp2 >= 2.1.0". > Thanks for catching that; I didn't realize 2.0.1 included pkg-config support. Fixed. Aside from that LGTM. It's nice to see all the bloat gone and every > future 2.x version being supported without further changes from now on. Yeah, I look forward to the decreased maintenance costs! Attached is an updated patch with the requested changes to configure and Changelog. I plan on pushing this in a few hours (unless, of course, there are additional critiques). 0001-lavc-drop-support-for-OpenJPEG-1.3-2.0.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0
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_CODEC_CAP_EXPERIMENTAL[1], so support for it was already kinda experimental. 2) This doesn't impact old versions of ffmpeg. If people are building ffmpeg 3.5+ on Ubuntu 14.04 on their own, then they can also build OpenJPEG 2.1+ on their own. [1]: https://github.com/FFmpeg/FFmpeg/blob/master/ libavcodec/libopenjpegdec.c#L575 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add more beep options to sine asrc
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, "set the delay for the first beep",),
> > +OPT_DBL("beep_period", beep_period_opt,1, DBL_MIN,
> DBL_MAX, "set the gap between beeps",),
> > +OPT_DBL("beep_duration", beep_duration, 0.04, DBL_MIN,
> DBL_MAX, "set the duration of a beep",),
>
> I think these should use OPT_DUR / AV_OPT_TYPE_DURATION rather than
> doubles. Also, DBL_MIN seems strange: I do not think a negative value
> makes sense.
>
Fixed. DBL_MIN is actually positive. I use it to prevent the user from
setting the beep period or duration to 0. But I've changed it to now use 1.
> OPT_INT("sample_rate", sample_rate,44100, 1, INT_MAX,
> "set the sample rate",),
> > OPT_INT("r", sample_rate,44100, 1,
> INT_MAX, "set the sample rate",),
> > OPT_DUR("duration", duration, 0, 0,
> INT64_MAX, "set the audio duration",),
> > @@ -152,10 +158,13 @@ static av_cold int init(AVFilterContext *ctx)
> > make_sin_table(sine->sin);
> >
> > if (sine->beep_factor) {
> > -sine->beep_period = sine->sample_rate;
> > -sine->beep_length = sine->beep_period / 25;
> > -sine->dphi_beep = ldexp(sine->beep_factor * sine->frequency,
> 32) /
> > - sine->sample_rate + 0.5;
> > +unsigned beep_start = sine->beep_delay * sine->sample_rate;
> > +double beep_frequency = (sine->frequency ? sine->frequency :
> 1.0) *
> > +sine->beep_factor;
>
> > +sine->beep_period = sine->beep_period_opt * sine->sample_rate;
>
> With integer durations, av_rescale() would be better.
>
Fixed.
> +sine->beep_index = (sine->beep_period - beep_start) %
> sine->beep_period;
>
> I think this will produce strange results if beep_start is greater than
> beep_period. Maybe document the limitation, or adjust the arithmetic.
Good point. I fixed the arithmetic so now the beep_start can be greater
than the beep_period.
Attached is an updated patch.
0001-lavf-add-more-beep-options-to-sine-asrc.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0
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.
> With this patch ./configure therefor fails over here with:
> "test.o:test.c:(.text+0x1): undefined reference to `_imp__opj_version@0'".
>
> enabled libopenjpeg && require_pkg_config libopenjpeg "libopenjp2
> >= 2.1.0" openjpeg.h opj_version -DOPJ_STATIC && add_cppflags -DOPJ_STATIC
>
> This line fixes that.
-DOPJ_STATIC was originally added to ffmpeg's configure script for Windows.
Unconditionally adding -DOPJ_STATIC would conflict with people who are
dynamically linking. I'll look into this further. I'll start with the
following:
enabled libopenjpeg && {{require_pkg_config libopenjpeg "libopenjp2
>= 2.1.0" openjpeg.h opj_version -DOPJ_STATIC && add_cppflags
-DOPJ_STATIC;} ||
require_pkg_config libopenjpeg "libopenjp2 >=
2.1.0" openjpeg.h opj_version;}
and see if it works for both static and dynamic builds of OpenJPEG.
Unfortunately, I don't have a Windows system to test on, so if anyone can
validate the above on Windows I'd appreciate it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0
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 suggestion for the -DOPJ_STATIC fix; thanks, James!). 0001-lavc-drop-support-for-OpenJPEG-1.3-2.0.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0
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 support was introduced with *2.0.1*, > not *2.1(.0)*. James's comment: > Indeed. I'm intentionally dropping support for 2.0.x. http://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/218145.html > where his remark was: > > OpenJPEG 2.0.1 ships a pkg-config file, so change the second argument to > > "libopenjp2 >= 2.1.0". > > I consider the second line a typo. James? > > Indeed, this commit here adds the .pc file to openjpeg2: > https://github.com/uclouvain/openjpeg/commit/ > 87e09a09da6493b9e25193173091fd56c2063136#diff- > 20f723280676e973232128ea1ba322ee > and this commit is included in the repo's "version.2.0.1" tag. > > Perhaps you want to relax the check (and the Changelog) - I understand > that was James's original intent. (Not that I care for that version > personally.) There was an API change between 2.0 and 2.1. Since 2.1, the API has been stable. I want to remove all the #if hacks in our code, so dropping 2.0 is a necessary part of that. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0
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 any snags due to this. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: fix detection of libopenjpeg
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 '-DOPJ_STATIC' changes what the included header does.
>
> Also add '-DOPJ_STATIC' to CFLAGS, so that it isn't necessary to
> hardcode this in libavcodec/libopenjpeg{dec,enc}.c.
>
> Finally, check for non-static libopenjpeg, too.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> configure | 9 ++---
> libavcodec/libopenjpegdec.c | 2 --
> libavcodec/libopenjpegenc.c | 2 --
> 3 files changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/configure b/configure
> index 8fc71fb..ff743cb 100755
> --- a/configure
> +++ b/configure
> @@ -5710,9 +5710,12 @@ enabled libopencv && { check_header
> opencv2/core/core_c.h &&
> require opencv opencv2/core/core_c.h
> cvCreateImageHeader -lopencv_core -lopencv_imgproc; } ||
> require_pkg_config opencv opencv/cxcore.h
> cvCreateImageHeader; }
> enabled libopenh264 && require_pkg_config openh264 wels/codec_api.h
> WelsGetCodecVersion
> -enabled libopenjpeg && { check_lib openjpeg-2.1/openjpeg.h
> opj_version -lopenjp2 -DOPJ_STATIC ||
> - check_lib openjpeg-2.0/openjpeg.h
> opj_version -lopenjp2 -DOPJ_STATIC ||
> - check_lib openjpeg-1.5/openjpeg.h
> opj_version -lopenjpeg -DOPJ_STATIC ||
> +enabled libopenjpeg && { { check_lib2 openjpeg-2.1/openjpeg.h
> opj_version -lopenjp2 -DOPJ_STATIC && add_cflags -DOPJ_STATIC; } ||
>
Use add_cppflags instead of add_cflags. The macro isn't needed for linking.
> + check_lib2 openjpeg-2.1/openjpeg.h
> opj_version -lopenjp2 ||
> + { check_lib openjpeg-2.0/openjpeg.h
> opj_version -lopenjp2 -DOPJ_STATIC && add_cflags -DOPJ_STATIC; } ||
>
You can drop the changes for v2.0 and below. Only v2.1 needs the check. The
new OPJ_STATIC behavior was introduced in OpenJPEG v2.1.1.
> + check_lib2 openjpeg-2.0/openjpeg.h
> opj_version -lopenjp2 ||
> + { check_lib openjpeg-1.5/openjpeg.h
> opj_version -lopenjpeg -DOPJ_STATIC && add_cflags -DOPJ_STATIC; } ||
> + check_lib2 openjpeg-1.5/openjpeg.h
> opj_version -lopenjpeg ||
> check_lib openjpeg.h opj_version
> -lopenjpeg -DOPJ_STATIC ||
> die "ERROR: libopenjpeg not found"; }
> enabled libopenmpt&& require_pkg_config "libopenmpt >= 0.2.6557"
> libopenmpt/libopenmpt.h openmpt_module_create
> diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
> index 65167e6..b4ce834 100644
> --- a/libavcodec/libopenjpegdec.c
> +++ b/libavcodec/libopenjpegdec.c
> @@ -24,8 +24,6 @@
> * JPEG 2000 decoder using libopenjpeg
> */
>
> -#define OPJ_STATIC
> -
> #include "libavutil/common.h"
> #include "libavutil/imgutils.h"
> #include "libavutil/intreadwrite.h"
> diff --git a/libavcodec/libopenjpegenc.c b/libavcodec/libopenjpegenc.c
> index 1443551..5042507 100644
> --- a/libavcodec/libopenjpegenc.c
> +++ b/libavcodec/libopenjpegenc.c
> @@ -24,8 +24,6 @@
> * JPEG 2000 encoder using libopenjpeg
> */
>
> -#define OPJ_STATIC
> -
> #include "libavutil/avassert.h"
> #include "libavutil/common.h"
> #include "libavutil/imgutils.h"
> --
> 2.9.3
> ___
> 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] libopenjpegenc: recreate image data buffer after encoding frame
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 steps available? Where are the data pointers being set to NULL
here?
Signed-off-by: Andreas Cadhalpun
> ---
>
> The relevant openjpeg2 code is:
> https://sources.debian.net/src/openjpeg2/2.1.2-1/src/lib/
> openjp2/j2k.c/?hl=10253#L10247
>
> ---
> libavcodec/libopenjpegenc.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/libavcodec/libopenjpegenc.c b/libavcodec/libopenjpegenc.c
> index 023fdf4..2f0ab20 100644
> --- a/libavcodec/libopenjpegenc.c
> +++ b/libavcodec/libopenjpegenc.c
> @@ -776,6 +776,16 @@ static int libopenjpeg_encode_frame(AVCodecContext
> *avctx, AVPacket *pkt,
> goto done;
> }
>
> +// openjpeg 2 sets the data pointers of the image components to NULL.
> +// Thus the image can't be reused.
> +opj_image_destroy(ctx->image);
> +ctx->image = mj2_create_image(avctx, &ctx->enc_params);
> +if (!ctx->image) {
> +av_log(avctx, AV_LOG_ERROR, "Error creating the mj2 image\n");
> +ret = AVERROR(EINVAL);
> +goto done;
> +}
> +
> av_shrink_packet(pkt, writer.pos);
> #endif // OPENJPEG_MAJOR_VERSION == 1
>
> --
> 2.9.3
> ___
> 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] configure: fix detection of libopenjpeg
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.h
>> opj_version -lopenjp2 ||
>> + { check_lib openjpeg-2.0/openjpeg.h
>> opj_version -lopenjp2 -DOPJ_STATIC && add_cflags -DOPJ_STATIC; } ||
>>
>
> You can drop the changes for v2.0 and below. Only v2.1 needs the check.
> The new OPJ_STATIC behavior was introduced in OpenJPEG v2.1.1.
>
Gah, this comment wasn't very clear. I mean that all the checks for v2.0
and below should have -DOPJ_STATIC && add_cppflags -DOPJ_STATIC. Only v2.1
needs to worry about possibly not using OPJ_STATIC.
> + check_lib2 openjpeg-2.0/openjpeg.h
>> opj_version -lopenjp2 ||
>> + { check_lib openjpeg-1.5/openjpeg.h
>> opj_version -lopenjpeg -DOPJ_STATIC && add_cflags -DOPJ_STATIC; } ||
>> + check_lib2 openjpeg-1.5/openjpeg.h
>> opj_version -lopenjpeg ||
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libopenjpegenc: recreate image data buffer after encoding frame
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: > > > >> 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. > > That's strange, as it happens practically always here (on Debian > testing/sid). > > > Is there a particular version of OpenJPEG or > > The OpenJPEG version is 2.1.2, i.e. the latest. > > > reproduction steps available? > > For example: > $ ffmpeg -f lavfi -i testsrc -c:v libopenjpeg -f null /dev/null Thanks for that (and the link back to the OpenJPEG source). Well dang. I think it would be better to change the patch to completely remove the image member from LibOpenJPEGContext, and instead just create a local image (and destroy it) for every call to libopenjpeg_encode_frame. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: fix detection of libopenjpeg
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-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libopenjpegenc: recreate image data buffer after encoding frame
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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libopenjpegenc: fix out-of-bounds reads when filling the edges
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 1461064c1eaabb71661f9ff68b94f35a1b98e3b5 Mon Sep 17 00:00:00 2001 > > From: Andreas Cadhalpun > > Date: Thu, 13 Oct 2016 22:14:46 +0200 > > Subject: [PATCH] libopenjpegenc: fix out-of-bounds reads when filling the > > edges > > > > The calculation of width/height should round up, not round down to > > prevent setting width or height to 0. > > > > Also image->comps[compno].w is unsigned (at least in openjpeg2), so the > > calculation could silently wrap around without the explicit cast to int. > > LGTM, iam not libopenjpegenc maintainer though Looks good to me too. Please feel free to apply it. Thanks! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/libopenjpegenc: don't define OPJ_STATIC with openjpeg 2.1.1
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
> ---
> libavcodec/libopenjpegdec.c | 1 +
> libavcodec/libopenjpegenc.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
> index 65167e6..efc0648 100644
> --- a/libavcodec/libopenjpegdec.c
> +++ b/libavcodec/libopenjpegdec.c
> @@ -37,6 +37,7 @@
> #include "thread.h"
>
> #if HAVE_OPENJPEG_2_1_OPENJPEG_H
> +#undef OPJ_STATIC
> # include
> #elif HAVE_OPENJPEG_2_0_OPENJPEG_H
> # include
> diff --git a/libavcodec/libopenjpegenc.c b/libavcodec/libopenjpegenc.c
> index 1443551..2bc75e2 100644
> --- a/libavcodec/libopenjpegenc.c
> +++ b/libavcodec/libopenjpegenc.c
> @@ -35,6 +35,7 @@
> #include "internal.h"
>
> #if HAVE_OPENJPEG_2_1_OPENJPEG_H
> +#undef OPJ_STATIC
> # include
> #elif HAVE_OPENJPEG_2_0_OPENJPEG_H
> # include
> --
> 2.9.0
>
In addition to what James Almer asked, does this build on Windows with
mingw?
See https://github.com/uclouvain/openjpeg/issues/766
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/matroskaenc: fix Voids with size < 10
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 intended, which will corrupt the file. A simple example to reproduce the issue: $ ffmpeg -f lavfi -i testsrc -vframes 1 -reserve_index_space 38 test.webm $ mkvinfo test.webm [...] test.webm: Error in the Matroska file structure at position 479. Resyncing to the next level 1 element. Resync failed: no valid Matroska level 1 element found. 0001-avformat-matroskaenc-fix-Voids-with-size-10.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/matroskaenc: omit segment UID for webm
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
Re: [FFmpeg-devel] [PATCH] avformat/icodec: Fix crash probing fuzzed file
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.c b/libavformat/icodec.c > index 6ddb901..8f84337 100644 > --- a/libavformat/icodec.c > +++ b/libavformat/icodec.c > @@ -60,7 +60,7 @@ static int probe(AVProbeData *p) > offset = AV_RL32(p->buf + 18 + i * 16); > if (offset < 22) > return FFMIN(i, AVPROBE_SCORE_MAX / 4); > -if (offset + 8 > p->buf_size) > +if (offset > p->buf_size - 8) Is AVProbeData.buf_size guaranteed to be >= 8? > return AVPROBE_SCORE_MAX / 4 + FFMIN(i, 1); > if (p->buf[offset] != 40 && AV_RB64(p->buf + offset) != PNGSIG) > return FFMIN(i, AVPROBE_SCORE_MAX / 4); > -- > 2.7.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg code Attribution
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 think the people who did the work on the FFmpeg codec would readily admit > that they copied a certain amount directly from the other project. > > So, I think that the OpenJPEG BSD license should appear on those files with > copied code from OpenJPEG, to comply with the BSD license. I can list some > of the files (there aren't many) if people are interested. Go ahead and list the files and sections of code you're concerned about (or the commits that introduced the code). Chances are that's going to come up in the thread anyway, so might as well do it from the get-go. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Linking to C++ version of openjpeg
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 more appropriate mailing list to use. On Sun, Mar 27, 2016 at 11:49 AM, Aaron Boxer wrote: > On Sun, Mar 27, 2016 at 2:39 PM, Aaron Boxer wrote: > >> Hello Again, >> >> I have a C++ version of openjpeg that I would like to use with FFmpeg - >> this >> library is going to be statically linked, just like the C version of >> openjpeg. >> >> Are there any special flags I need to set to link with the C++ version, >> which uses the STL and C++11 ? >> > > I tried adding -std=c++0x to the extra c flags, but when I looked at > config.log, I was these flags sent to gcc: > > -std=c++0x -std=c99 > > So, it seems that c99 is over-riding c++0x. You shouldn't be adding C++ flags to C flags (they're different languages, after all). You can use the --extra-cxxflags= parameter in ./configure to pass extra C++ flags to the compiler. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs
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 -0400
> Subject: [PATCH] Support the following jpeg 2000 codecs:
>
> a) latest release of openjpeg (2.1)
> b) master branch of openjpeg
> c) grok (https://github.com/GrokImageCompression/grok)
I'm curious what others think: if Grok requires FFmpeg to use GPLv3,
should an explicit check be added in ./configure to require
--enable-gpl --enable-version3? Or should the check not be added,
since FFmpeg is expecting the OpenJPEG library and the user is
replacing it with something else, so the onus is on them to remember
to add those flags when configuring?
>
> The following changes were made:
>
> 1. Removed bpp (redundant as this information is already stored in precision)
> 2. Removed OPJ_STATIC flag in configure: in master branch of openjpeg and in
> grok, this flag indicates a static build, so codec API functions are marked
> as hidden. This prevents FFmpeg from using a dynamic build of these codecs.
> 3. link to libdl. This is needed by grok, as it supports a plugin
> architecture that allows plugins to be dynamically loaded at runtime.
>
> I have tested these changes with openjpeg 2.1, openjpeg master, and grok
> master.Test was to make sure ./configure and make showed no errors, and then
> to decompress a J2K file. Everything worked for all three configurations,
> with no errors.
> ---
> configure | 2 +-
> libavcodec/libopenjpegdec.c | 2 +-
> libavcodec/libopenjpegenc.c | 3 +--
> 3 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/configure b/configure
> index 94a66d8..4e81385 100755
> --- a/configure
> +++ b/configure
> @@ -5561,7 +5561,7 @@ enabled libopencv && { check_header
> opencv2/core/core_c.h &&
> require opencv opencv2/core/core_c.h
> cvCreateImageHeader -lopencv_core -lopencv_imgproc; } ||
> require_pkg_config opencv opencv/cxcore.h
> cvCreateImageHeader; }
> enabled libopenh264 && require_pkg_config openh264 wels/codec_api.h
> WelsGetCodecVersion
> -enabled libopenjpeg && { check_lib openjpeg-2.1/openjpeg.h opj_version
> -lopenjp2 -DOPJ_STATIC ||
> +enabled libopenjpeg && { check_lib openjpeg-2.1/openjpeg.h opj_version
> -lopenjp2 -ldl ||
> check_lib openjpeg-2.0/openjpeg.h opj_version
> -lopenjp2 -DOPJ_STATIC ||
> check_lib openjpeg-1.5/openjpeg.h opj_version
> -lopenjpeg -DOPJ_STATIC ||
> check_lib openjpeg.h opj_version -lopenjpeg
> -DOPJ_STATIC ||
> diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
> index 65167e6..f116c8b 100644
> --- a/libavcodec/libopenjpegdec.c
> +++ b/libavcodec/libopenjpegdec.c
> @@ -24,7 +24,7 @@
> * JPEG 2000 decoder using libopenjpeg
> */
>
> -#define OPJ_STATIC
> +
>
> #include "libavutil/common.h"
> #include "libavutil/imgutils.h"
> diff --git a/libavcodec/libopenjpegenc.c b/libavcodec/libopenjpegenc.c
> index 56c8219..720eda0 100644
> --- a/libavcodec/libopenjpegenc.c
> +++ b/libavcodec/libopenjpegenc.c
> @@ -24,7 +24,7 @@
> * JPEG 2000 encoder using libopenjpeg
> */
>
> -#define OPJ_STATIC
> +
>
> #include "libavutil/avassert.h"
> #include "libavutil/common.h"
> @@ -276,7 +276,6 @@ static opj_image_t *mj2_create_image(AVCodecContext
> *avctx, opj_cparameters_t *p
>
> for (i = 0; i < numcomps; i++) {
> cmptparm[i].prec = desc->comp[i].depth;
> -cmptparm[i].bpp = desc->comp[i].depth;
bpp is needed by opj_j2k_is_cinema_compliant in OpenJPEG 2.1. I'd
rather not remove this line.
> cmptparm[i].sgnd = 0;
> cmptparm[i].dx = sub_dx[i];
> cmptparm[i].dy = sub_dy[i];
> --
> 2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavformat/matroskaenc: omit segment UID for webm
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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/matroskaenc: omit segment UID for webm
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 file. I concur with Dave's analysis, but parsing may fail if SegmentUID is written and the master element has an unknown size (which will be the case if ffmpeg is writing to an unseakable output, like pipes). This is because master elements with unknown size are terminated by the first unrecognized would-be-child element[1], which would cause the parser to terminate the Info element. This would continue to screw up parsing, because now there could be other children of Info (like DateUTC) after the SegmentUID, and since the Info element has terminated and those aren't valid children of Segment, it would cause the Segment element to terminate. At that point, the file is pretty broken because now there is no Segment element containing the Clusters and other elements. [1]: "The end of a Master-element with unknown size is determined by the beginning of the next element that is not a valid sub-element of that Master-element" (from the current EBML spec) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/libopenjpegdec: Set key frame metadata
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/libopenjpegdec.c @@ -546,6 +546,8 @@ static int libopenjpeg_decode_frame(AVCodecContext *avctx, } *got_frame = 1; +picture->pict_type = AV_PICTURE_TYPE_I; +picture->key_frame = 1; ret= buf_size; done: -- 2.10.1 (Apple Git-78) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/libopenjpegdec: Set key frame metadata
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) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg: Move statement to a single line
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 *new_output_stream(OptionsContext *o, AVFormatContext *oc, e uint32_t tag = strtol(codec_tag, &next, 0); if (*next) tag = AV_RL32(codec_tag); -ost->st->codecpar->codec_tag = -ost->enc_ctx->codec_tag = tag; +ost->st->codecpar->codec_tag = ost->enc_ctx->codec_tag = tag; } MATCH_PER_STREAM_OPT(qscale, dbl, qscale, oc, st); -- 2.10.1 (Apple Git-78) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg: Move statement to a single line
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(+), 2 deletions(-) -- 2.10.1 (Apple Git-78) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/matroskaenc: Accept time base hint
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 current behavior). Please review [1]: https://ffmpeg.org/doxygen/3.2/avformat_8h_source.html#l00910 Michael Bradshaw (1): avformat/matroskaenc: Accept time base hint libavformat/matroskaenc.c | 38 +++--- 1 file changed, 31 insertions(+), 7 deletions(-) -- 2.10.1 (Apple Git-78) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/matroskaenc: Accept time base hint
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/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -117,6 +117,7 @@ typedef struct mkv_attachments {
typedef struct MatroskaMuxContext {
const AVClass *class;
int mode;
+int timecode_scale;
AVIOContext *dyn_bc;
AVIOContext *tags_bc;
ebml_master tags;
@@ -1757,7 +1758,7 @@ static int mkv_write_header(AVFormatContext *s)
return ret;
pb = mkv->info_bc;
-put_ebml_uint(pb, MATROSKA_ID_TIMECODESCALE, 100);
+put_ebml_uint(pb, MATROSKA_ID_TIMECODESCALE, mkv->timecode_scale);
if ((tag = av_dict_get(s->metadata, "title", NULL, 0)))
put_ebml_string(pb, MATROSKA_ID_TITLE, tag->value);
if (!(s->flags & AVFMT_FLAG_BITEXACT)) {
@@ -1799,11 +1800,11 @@ static int mkv_write_header(AVFormatContext *s)
int64_t metadata_duration = get_metadata_duration(s);
if (s->duration > 0) {
-int64_t scaledDuration = av_rescale(s->duration, 1000,
AV_TIME_BASE);
+int64_t scaledDuration = av_rescale(s->duration, 10,
AV_TIME_BASE * (int64_t)mkv->timecode_scale);
put_ebml_float(pb, MATROSKA_ID_DURATION, scaledDuration);
av_log(s, AV_LOG_DEBUG, "Write early duration from recording time
= %" PRIu64 "\n", scaledDuration);
} else if (metadata_duration > 0) {
-int64_t scaledDuration = av_rescale(metadata_duration, 1000,
AV_TIME_BASE);
+int64_t scaledDuration = av_rescale(metadata_duration, 10,
AV_TIME_BASE * (int64_t)mkv->timecode_scale);
put_ebml_float(pb, MATROSKA_ID_DURATION, scaledDuration);
av_log(s, AV_LOG_DEBUG, "Write early duration from metadata = %"
PRIu64 "\n", scaledDuration);
} else {
@@ -1864,12 +1865,12 @@ static int mkv_write_header(AVFormatContext *s)
// after 4k and on a keyframe
if (pb->seekable) {
if (mkv->cluster_time_limit < 0)
-mkv->cluster_time_limit = 5000;
+mkv->cluster_time_limit = av_rescale(5, 10,
mkv->timecode_scale);
if (mkv->cluster_size_limit < 0)
mkv->cluster_size_limit = 5 * 1024 * 1024;
} else {
if (mkv->cluster_time_limit < 0)
-mkv->cluster_time_limit = 1000;
+mkv->cluster_time_limit = 10 / mkv->timecode_scale;
if (mkv->cluster_size_limit < 0)
mkv->cluster_size_limit = 32 * 1024;
}
@@ -2458,6 +2459,7 @@ static int mkv_query_codec(enum AVCodecID codec_id, int
std_compliance)
static int mkv_init(struct AVFormatContext *s)
{
+MatroskaMuxContext *mkv = s->priv_data;
int i;
if (s->avoid_negative_ts < 0) {
@@ -2465,9 +2467,31 @@ static int mkv_init(struct AVFormatContext *s)
s->internal->avoid_negative_ts_use_pts = 1;
}
+// ms precision is the de-facto standard timescale for mkv files
+mkv->timecode_scale = 100;
+
+// If the user has supplied a desired time base, use it if possible
+if (s->nb_streams > 0) {
+ AVRational time_base = s->streams[0]->time_base;
+ for (i = 1; i < s->nb_streams; i++) {
+ if (time_base.num != s->streams[i]->time_base.num ||
+ time_base.den != s->streams[i]->time_base.den) {
+time_base = av_make_q(0, 0);
+break;
+ }
+ }
+ // Make sure the time base is valid, can losslessly be converted to
+ // nanoseconds, and isn't longer than 1 second
+ if (time_base.num > 0 &&
+ time_base.den > 0 &&
+ 10 % time_base.den == 0 &&
+ time_base.num <= time_base.den) {
+ mkv->timecode_scale = (int)av_rescale(time_base.num, 10,
time_base.den);
+ }
+}
+
for (i = 0; i < s->nb_streams; i++) {
-// ms precision is the de-facto standard timescale for mkv files
-avpriv_set_pts_info(s->streams[i], 64, 1, 1000);
+avpriv_set_pts_info(s->streams[i], 64, mkv->timecode_scale,
10);
}
return 0;
--
2.10.1 (Apple Git-78)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg: Add -time_base option to hint the time base
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 to hint the time base ffmpeg.c | 6 -- ffmpeg.h | 2 ++ ffmpeg_opt.c | 16 +++- 3 files changed, 21 insertions(+), 3 deletions(-) -- 2.10.1 (Apple Git-78) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg: Add -time_base option to hint the time base
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
@@ -2910,7 +2910,8 @@ static int init_output_stream_streamcopy(OutputStream
*ost)
return ret;
// copy timebase while removing common factors
-ost->st->time_base = av_add_q(av_stream_get_codec_timebase(ost->st),
(AVRational){0, 1});
+if (ost->st->time_base.num <= 0 || ost->st->time_base.den <= 0)
+ost->st->time_base = av_add_q(av_stream_get_codec_timebase(ost->st),
(AVRational){0, 1});
// copy disposition
ost->st->disposition = ist->st->disposition;
@@ -3335,7 +3336,8 @@ static int init_output_stream(OutputStream *ost, char
*error, int error_len)
}
// copy timebase while removing common factors
-ost->st->time_base = av_add_q(ost->enc_ctx->time_base, (AVRational){0,
1});
+if (ost->st->time_base.num <= 0 || ost->st->time_base.den <= 0)
+ost->st->time_base = av_add_q(ost->enc_ctx->time_base,
(AVRational){0, 1});
ost->st->codec->codec= ost->enc_ctx->codec;
} else if (ost->stream_copy) {
ret = init_output_stream_streamcopy(ost);
diff --git a/ffmpeg.h b/ffmpeg.h
index ebe5bf0..f32d22a 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -224,6 +224,8 @@ typedef struct OptionsContext {
intnb_disposition;
SpecifierOpt *program;
intnb_program;
+SpecifierOpt *time_bases;
+intnb_time_bases;
} OptionsContext;
typedef struct InputFilter {
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 6862456..8f5d3a1 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -1231,7 +1231,7 @@ static OutputStream *new_output_stream(OptionsContext *o,
AVFormatContext *oc, e
OutputStream *ost;
AVStream *st = avformat_new_stream(oc, NULL);
int idx = oc->nb_streams - 1, ret = 0;
-const char *bsfs = NULL;
+const char *bsfs = NULL, *time_base = NULL;
char *next, *codec_tag = NULL;
double qscale = -1;
int i;
@@ -1308,6 +1308,17 @@ static OutputStream *new_output_stream(OptionsContext
*o, AVFormatContext *oc, e
ost->encoder_opts = filter_codec_opts(o->g->codec_opts,
AV_CODEC_ID_NONE, oc, st, NULL);
}
+MATCH_PER_STREAM_OPT(time_bases, str, time_base, oc, st);
+if (time_base) {
+AVRational q;
+if (av_parse_ratio(&q, time_base, INT_MAX, 0, NULL) < 0 ||
+q.num <= 0 || q.den <= 0) {
+av_log(NULL, AV_LOG_FATAL, "Invalid time base: %s\n", time_base);
+exit_program(1);
+}
+st->time_base = q;
+}
+
ost->max_frames = INT64_MAX;
MATCH_PER_STREAM_OPT(max_frames, i64, ost->max_frames, oc, st);
for (i = 0; inb_max_frames; i++) {
@@ -3649,6 +3660,9 @@ const OptionDef options[] = {
{ "sdp_file", HAS_ARG | OPT_EXPERT | OPT_OUTPUT, { .func_arg =
opt_sdp_file },
"specify a file in which to print sdp information", "file" },
+{ "time_base", HAS_ARG | OPT_STRING | OPT_EXPERT | OPT_SPEC | OPT_OUTPUT,
{ .off = OFFSET(time_bases) },
+"set the desired time base hint for output stream (1:24, 1:48000 or
0.04166, 2.0833e-5)", "ratio" },
+
{ "bsf", HAS_ARG | OPT_STRING | OPT_SPEC | OPT_EXPERT | OPT_OUTPUT, { .off
= OFFSET(bitstream_filters) },
"A comma-separated list of bitstream filters", "bitstream_filters" },
{ "absf", HAS_ARG | OPT_AUDIO | OPT_EXPERT| OPT_PERFILE | OPT_OUTPUT, {
.func_arg = opt_old2new },
--
2.10.1 (Apple Git-78)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: Accept time base hint
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 +++--- > > 1 file changed, 31 insertions(+), 7 deletions(-) > > breaks fate > [...] I've looked into this and it's expected behavior. -codec copy is also copying timing information (including time base), and with this patch the Matroska/WebM muxers are respecting that. I could update the fate files, but before doing that I'd like to ensure that this change in behavior for -codec copy is correct and desirable. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: Accept time base hint
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 the user has supplied a desired time base, use it if possible
> > +if (s->nb_streams > 0) {
> > + AVRational time_base = s->streams[0]->time_base;
> > + for (i = 1; i < s->nb_streams; i++) {
>
> inconsistent indention
>
Fixed.
> + if (time_base.num != s->streams[i]->time_base.num ||
> > + time_base.den != s->streams[i]->time_base.den) {
> > +time_base = av_make_q(0, 0);
> > +break;
> > + }
> > + }
>
> This looks just at one stream, what if other streams have other
> timebases ?
> you could pick a common tb so that timestamps in any of the requested
> ones can be represented. While this wont always be possible due to
> bits per int constraint i dont think completely ignoring other streams
> is safe.
>
The other streams aren't completely ignored. They're checked to make sure
they all have the same time base (and if they don't, it falls back to the
default 1/1000 time base).
> + // Make sure the time base is valid, can losslessly be converted to
> > + // nanoseconds, and isn't longer than 1 second
> > + if (time_base.num > 0 &&
> > + time_base.den > 0 &&
> > + 10 % time_base.den == 0 &&
> > + time_base.num <= time_base.den) {
>
> > + mkv->timecode_scale = (int)av_rescale(time_base.num,
> 10, time_base.den);
>
> assuming someone asks for 1001/24000 he would get something else
> and something that is lower precission than what the default would
> have been prior to this patch IIUC
Before this patch the time base was always set to 1/1000, which is what
this patch defaults to if the streams don't have a common time base that
can be losslessly converted to nanoseconds, so this patch should never make
things less precise than before.
I have mixed feelings on changing this patch so that it picks a common time
base between multiple streams or truncates a repeating decimal. Matroska
only stores timestamps as multiples of nanoseconds, and I fear
automatically computing a time base might push the time base closer and
closer to 1/10. Using a tiny timebase like that causes extra
chunking in Matroska, as each block in a Cluster only stores its timestamp
as a 16-bit int.
I'd rather my other patch[1] be used to let the user request a specific
time base than trying to auto-compute a time base.
I've updated the patch to fix the indentation as well as ignore the time
base hint for WebM, since WebM muxers are required to use a time base of
1/1000[2]. Apologies for the gmail attachment; I'm still figuring out git
send-email.
[1]: http://ffmpeg.org/pipermail/ffmpeg-devel/2016-December/205017.html
[2]: http://www.webmproject.org/docs/container/#muxer-guidelines
0001-avformat-matroskaenc-Accept-time-base-hint.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] ffmpeg: Add -time_base option to hint the time base
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 some FATE test too? We have a lot of nasty hack wrt time > bases, and it's likely to break in a merge. I'll work on adding a fate test. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/libopenjpegenc.c
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 have is 1. Small nitpick: please amend the commit message so the first line of the message is a short summary of the overall commit, and move the numbered list to below the first line. That is, the command git log --pretty=short should look something like: commit 440b7cb6abb32e35464c7c86634d655ccb1d7e7c Author: Aaron Boxer The command git log can give the full commit message: commit 440b7cb6abb32e35464c7c86634d655ccb1d7e7c Author: Aaron Boxer 1. limit... 2. encoder... 3. remove... 4. add... 5. set... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/libopenjpegenc.c
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
Re: [FFmpeg-devel] configure/libopenjpegdec.c/libopenjpegenc.c: Add support for LibOpenJPEG v2.2/git
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
Re: [FFmpeg-devel] [PATCH] JPEG2000: SSE optimisation of DWT decoding
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 synchronization). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc: fix option setting for encoding example
In the encoding/decoding example[1], in the video_encode_example() function, av_opt_set() is used to set the option "preset" to "slow" (here, c is a AVCodecContext*): av_opt_set(c->priv_data, "preset", "slow", 0); I presume this is wrong to use priv_data, and instead the codec context should be passed. Attached patch passes the codec context instead of priv_data. [1]: https://ffmpeg.org/pipermail/libav-user/2014-December/007689.html 0001-doc-fix-option-setting-for-encoding-example.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH] libopenjpegdec: check existence of image component data
On Sat, May 30, 2015 at 7:50 AM, Andreas Cadhalpun < andreas.cadhal...@googlemail.com> wrote: > On 30.05.2015 16:41, Luca Barbato wrote: > > Do you happen to know why it does do that? > > It encounters a problem, but only warns about it and returns the image > anyway. The warning is not sent to stdout with libavcodec, but can be seen > with j2k_dump: > [WARNING] 006a: expected a marker instead of 0 Then perhaps a opj_event_mgr_t event handler should be registered. The openjpeg encoder does this to log all warnings with av_log. But if openjpeg is giving back bad data without a warning/error code from the returning function, then perhaps this error check is justified. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?
tl;dr: I've got a patch that updates OpenJPEG to 2.0/2.1. Currently, I've opted to drop OpenJPEG 1.5. Should I proceed with preparing this patch for submission, or should I alter it to keep 1.5 support? The OpenJPEG API went through a bit of an overhaul in the 1.x to 2.x transition. This means that supporting 1.5 and 2.x concurrently in ffmpeg would be possible, but would require some (ugly) macros. Given that v2.0 was released ~19 months ago, I think it's been long enough that users should, most likely, have access to a modern 2.x OpenJPEG on their machine. So I don't think dropping 1.5 would be catastrophic. But, on the other hand, it's nice to be a swiss army knife that works with everything, so I can understand if others think supporting 1.5 is important. I don't want to submit my patch (as is) if I'm just going to be told to go back and keep 1.5 support. If ya'll still want 1.5 support, I'd rather include that from the get-go rather than revising the patch during the review. Opinions on whether 1.5 should be dropped in favor of 2.x? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?
On Sat, Oct 24, 2015 at 11:11 AM, Carl Eugen Hoyos wrote: > James Almer gmail.com> writes: > > > Why does configure even check for 2.x if the actual > > lavc wrappers don't currently support it? > > It is possible to use openjpeg2 with current > FFmpeg (I use it for testing) but it is > everything but user-friendly. > Kind of. The openmj2 library that openjpeg2 comes with hasn't been touched in ~3 years[1] (the only recent commits to that part of the library have been cosmetic/build related, so it's substantially out of date compared to openjp2). This patch updates ffmpeg to use openjp2, not openmj2 (as it currently does). openjp2 has a ton of fixes and improvements. I have no idea why the openmj2 library exists, or why its just sitting there stagnating in the OpenJPEG repo. It'll be nice to get ffmpeg off of it. [1]: https://github.com/uclouvain/openjpeg/commits/master/src/lib/openmj2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?
On Sat, Oct 24, 2015 at 11:28 AM, Timothy Gu wrote: > On Sat, Oct 24, 2015 at 11:03 AM James Almer wrote: > > > Gentoo and Debian both seem to ship it. Arch does as well but on their > > Community repository (ffmpeg adopting it may be incentive enough for them > > to move it to Extra). > > > In fact, at least two of the reverse dependencies (out of 8, not counting > duplicates) of the Arch openjpeg package already support openjpeg2 (poppler > and gst-plugins-bad). > > I would prefer if we keep compat for both since Ubuntu 14.04 LTS doesn't > have openjpeg2 yet, and that's unfortunately not going away any time soon. Crap, you're right. Before I started this I checked if Ubuntu had openjpeg2 and they do[1] but it turns out it's really just openjpeg 1.3 (if anyone knows why they made a separate package named libopenjpeg2 when it's really openjpeg 1.3, I'd be curious to learn why). Well that settles it for me, then. I'll keep compatibility with 1.5. [1]: http://packages.ubuntu.com/trusty/libopenjpeg2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec: add OpenJPEG 2.x compatibility
Hi, Attached patch adds support for OpenJPEG 2.0/2.1. Please review. Thanks, Michael Bradshaw 0001-avcodec-add-OpenJPEG-2.x-compatibility.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add OpenJPEG 2.x compatibility
On Wed, Nov 18, 2015 at 6:21 AM, Derek Buitenhuis < derek.buitenh...@gmail.com> wrote: > On 11/17/2015 3:27 PM, Michael Bradshaw wrote: > > Attached patch adds support for OpenJPEG 2.0/2.1. Please review. > > This seems like quite a large change. Does it perhaps warrant its own > file/decoder name? I thought about it, but it shares a lot of functionality with the 1.x code, including program options (the only difference being the OPJ_ prefix in 2.x). I could rip out all the common functionality into some shared libopenjpeg.h/c files, and replace the program options with custom values that each codec then translates into OpenJPEG's option values, and then have two codecs for 1.x and 2.x. The logic in that case will be simpler to follow because there won't be as many macros, but overall it will be a larger change. Opinions? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add OpenJPEG 2.x compatibility
On Wed, Nov 18, 2015 at 8:00 AM, Michael Niedermayer wrote: > On Tue, Nov 17, 2015 at 07:27:55AM -0800, Michael Bradshaw wrote: > > Hi, > > > > Attached patch adds support for OpenJPEG 2.0/2.1. Please review. > > > > Thanks, > > > > Michael Bradshaw > > > configure |5 > > libavcodec/libopenjpegdec.c | 173 > > libavcodec/libopenjpegenc.c | 269 > +--- > > 3 files changed, 382 insertions(+), 65 deletions(-) > > 4e7c94ca16fa09210c4d74a4cf589ae9db540e9a > 0001-avcodec-add-OpenJPEG-2.x-compatibility.patch > > From 1cdf996b7fdaed429731054e96f9e6b565c9436d Mon Sep 17 00:00:00 2001 > > From: Michael Bradshaw > > Date: Sun, 1 Nov 2015 19:11:12 -0800 > > Subject: [PATCH] avcodec: add OpenJPEG 2.x compatibility > > this seems breaking the decoder > > ./ffmpeg -i matrixbench_mpeg2.mpg -vcodec libopenjpeg -vframes 1 test.j2k > > ./ffmpeg -strict -2 -vcodec libopenjpeg -i test.j2k -f null - > > [libopenjpeg @ 0x28f3220] Error decoding codestream header. > [j2k_pipe @ 0x28d1bc0] decoding for stream 0 failed > [j2k_pipe @ 0x28d1bc0] Could not find codec parameters for stream 0 > (Video: jpeg2000, none): unspecified size > Consider increasing the value for the 'analyzeduration' and 'probesize' > options > test.j2k: could not find codec parameters Oops, misplaced a ! in some last minute cleanup. Fixed patch attached. 0001-avcodec-add-OpenJPEG-2.x-compatibility.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add OpenJPEG 2.x compatibility
On Thu, Nov 19, 2015 at 1:21 AM, Moritz Barsnick wrote:
> On Wed, Nov 18, 2015 at 21:22:57 -0800, Michael Bradshaw wrote:
>
> > if (!dec) {
> > av_log(avctx, AV_LOG_ERROR, "Error initializing decoder.\n");
> > -return AVERROR_UNKNOWN;
> > +ret = AVERROR_EXTERNAL;
> > +goto done;
> > }
> [...]
> > if (!stream) {
> > av_log(avctx, AV_LOG_ERROR,
> > "Codestream could not be opened for reading.\n");
> > -opj_destroy_decompress(dec);
> > -return AVERROR_UNKNOWN;
> > +ret = AVERROR_EXTERNAL;
> > +goto done;
> > }
> [...]
> > -if (!image) {
> > -av_log(avctx, AV_LOG_ERROR, "Error decoding codestream.\n");
> > -opj_destroy_decompress(dec);
> > -return AVERROR_UNKNOWN;
> > +if (ret) {
> > +av_log(avctx, AV_LOG_ERROR, "Error decoding codestream
> header.\n");
> > +ret = AVERROR_EXTERNAL;
> > +goto done;
> > }
> [...]
> > if (avctx->pix_fmt == AV_PIX_FMT_NONE) {
> > -av_log(avctx, AV_LOG_ERROR, "Unable to determine pixel
> format\n");
> > +av_log(avctx, AV_LOG_ERROR, "Unable to determine pixel
> format.\n");
> > +ret = AVERROR_UNKNOWN;
> > goto done;
> > }
> [...]
> > if (!stream) {
> > av_log(avctx, AV_LOG_ERROR,
> > "Codestream could not be opened for reading.\n");
> > -ret = AVERROR_UNKNOWN;
> > +ret = AVERROR_EXTERNAL;
> > goto done;
> > }
> [...]
> > av_log(avctx, AV_LOG_ERROR, "Error decoding codestream.\n");
> > -ret = AVERROR_UNKNOWN;
> > +ret = AVERROR_EXTERNAL;
> [...]
> > LibOpenJPEGContext *ctx = avctx->priv_data;
> > -int err = AVERROR(ENOMEM);
> > +int err = 0;
> [...]
> > if (!compress) {
> > av_log(avctx, AV_LOG_ERROR, "Error creating the compressor\n");
> > -return AVERROR(ENOMEM);
> > +ret = AVERROR(ENOMEM);
> > +goto done;
> > }
> [...]
> > av_log(avctx, AV_LOG_ERROR, "Error creating the cio stream\n");
> > -return AVERROR(ENOMEM);
> > +ret = AVERROR(ENOMEM);
> > +goto done;
> [...]
> > if (!opj_encode(compress, stream, image, NULL)) {
> > av_log(avctx, AV_LOG_ERROR, "Error during the opj encode\n");
> > -return -1;
> > +ret = AVERROR_EXTERNAL;
> > +goto done;
> > }
> [...]
> > len = cio_tell(stream);
> > if ((ret = ff_alloc_packet2(avctx, pkt, len, 0)) < 0) {
> > -return ret;
> > +goto done;
> > }
>
> Are these not unrelated changes (i.e. valid even without integration of
> openjpeg2), which would belong into a separate patch? Just wondering.
>
> (IOW, you're changing the openjpeg1 codepath/behavior as well? Or are
> these changes for compatibility?)
>
It makes it so v1 and v2 can share the cleanup/error/logging code (for the
most part). Removing those changes would require more #ifdefs and duplicate
logging messages so v2 could handle errors, so I don't really consider them
superfluous changes for this patch. The intent was not to change the v1
code path or behavior.
Except a couple changes that are for consistency (i.e. changing
AVERROR_UNKNOWN to AVERROR_EXTERNAL in a couple spots) or correctness (the
change in if (avctx->pix_fmt == AV_PIX_FMT_NONE) that sets ret =
AVERROR_UNKNOWN;). I could separate those changes out into a different
patch, but I don't think either patch would really be complete without the
other, which is why I did it in one patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add OpenJPEG 2.x compatibility
On Thu, Nov 19, 2015 at 6:31 PM, Michael Niedermayer wrote: > On Wed, Nov 18, 2015 at 09:22:57PM -0800, Michael Bradshaw wrote: > > On Wed, Nov 18, 2015 at 8:00 AM, Michael Niedermayer > > > wrote: > > > > > On Tue, Nov 17, 2015 at 07:27:55AM -0800, Michael Bradshaw wrote: > > > > Hi, > > > > > > > > Attached patch adds support for OpenJPEG 2.0/2.1. Please review. > > > > > > > > Thanks, > > > > > > > > Michael Bradshaw > > > > > > > configure |5 > > > > libavcodec/libopenjpegdec.c | 173 > > > > libavcodec/libopenjpegenc.c | 269 > > > +--- > > > > 3 files changed, 382 insertions(+), 65 deletions(-) > > > > 4e7c94ca16fa09210c4d74a4cf589ae9db540e9a > > > 0001-avcodec-add-OpenJPEG-2.x-compatibility.patch > > > > From 1cdf996b7fdaed429731054e96f9e6b565c9436d Mon Sep 17 00:00:00 > 2001 > > > > From: Michael Bradshaw > > > > Date: Sun, 1 Nov 2015 19:11:12 -0800 > > > > Subject: [PATCH] avcodec: add OpenJPEG 2.x compatibility > > > > > > this seems breaking the decoder > > > > > > ./ffmpeg -i matrixbench_mpeg2.mpg -vcodec libopenjpeg -vframes 1 > test.j2k > > > > > > ./ffmpeg -strict -2 -vcodec libopenjpeg -i test.j2k -f null - > > > > > > [libopenjpeg @ 0x28f3220] Error decoding codestream header. > > > [j2k_pipe @ 0x28d1bc0] decoding for stream 0 failed > > > [j2k_pipe @ 0x28d1bc0] Could not find codec parameters for stream 0 > > > (Video: jpeg2000, none): unspecified size > > > Consider increasing the value for the 'analyzeduration' and 'probesize' > > > options > > > test.j2k: could not find codec parameters > > > > > > Oops, misplaced a ! in some last minute cleanup. Fixed patch attached. > > > configure |5 > > libavcodec/libopenjpegdec.c | 173 > > libavcodec/libopenjpegenc.c | 269 > +--- > > 3 files changed, 382 insertions(+), 65 deletions(-) > > dc1ec76dc92d0a03c8fec0d4c14228e14f1c4e1e > 0001-avcodec-add-OpenJPEG-2.x-compatibility.patch > > From 2fff5b8f6832d93ae65a75953db842c3fe6d9e86 Mon Sep 17 00:00:00 2001 > > From: Michael Bradshaw > > Date: Sun, 1 Nov 2015 19:11:12 -0800 > > Subject: [PATCH] avcodec: add OpenJPEG 2.x compatibility > > should i apply this ? > (it seems working, but it seems some people where nt entirely happy > are there objectiosn remaiing after Michael Bradshaws replies?) > No objections from anyone, I assume? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/icodec: Improve probe function
Overall it looks good. I thought it might overflow the buffer but with
AVPROBE_PADDING_SIZE it doesn't.
On Tue, Jan 12, 2016 at 7:09 AM, Carl Eugen Hoyos wrote:
> diff --git a/libavformat/icodec.c b/libavformat/icodec.c
> index 22e2099..9cf3dca 100644
> --- a/libavformat/icodec.c
> +++ b/libavformat/icodec.c
> @@ -27,6 +27,7 @@
> #include "libavutil/intreadwrite.h"
> #include "libavcodec/bytestream.h"
> #include "libavcodec/bmp.h"
> +#include "libavcodec/png.h"
> #include "avformat.h"
> #include "internal.h"
>
> @@ -44,9 +45,30 @@ typedef struct {
>
> static int probe(AVProbeData *p)
> {
> -if (AV_RL16(p->buf) == 0 && AV_RL16(p->buf + 2) == 1 && AV_RL16(p->buf +
> 4))
> -return AVPROBE_SCORE_MAX / 4;
> -return 0;
> +unsigned i, frames = AV_RL16(p->buf + 4);
> +
> +if (AV_RL16(p->buf) || AV_RL16(p->buf + 2) != 1 || !frames)
> +return 0;
> +for (i = 0; i < frames; i++) {
> +unsigned offset;
> +if (AV_RL16(p->buf + 10 + i * 16) & ~1) // color planes
> +return FFMIN(i, AVPROBE_SCORE_MAX / 4);
> +if (p->buf[13 + i * 16])
> +return FFMIN(i, AVPROBE_SCORE_MAX / 4);
> +if (AV_RL32(p->buf + 14 + i * 16) < 40) // size
> +return FFMIN(i, AVPROBE_SCORE_MAX / 4);
> +offset = AV_RL32(p->buf + 18 + i * 16);
> +if (offset < 22)
> +return FFMIN(i, AVPROBE_SCORE_MAX / 4);
> +if (offset + 8 > p->buf_size)
> +return AVPROBE_SCORE_MAX / 4 + FFMIN(i, 1);
> +if (p->buf[offset] != 40 && AV_RB64(p->buf + offset) != PNGSIG)
> +return FFMIN(i, AVPROBE_SCORE_MAX / 4);
> +if (i * 16 + 6 > p->buf_size)
> +return AVPROBE_SCORE_MAX / 4;
> +}
> +
> +return AVPROBE_SCORE_MAX / 4 + 1;
A score of 26 seems low to me, but maybe that's just me.
> }
>
> static int read_header(AVFormatContext *s)
I checked all the various header bytes this would be checking and it
all looks good.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec: fix building without 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_idwt_init2 in libavcodec.a(dirac_dwt.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [ffmpeg_g] Error 1 This is with clang from Apple LLVM 7.0.2 0001-libavcodec-fix-building-without-asm.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
