Re: [FFmpeg-devel] [PATCH] ffmpeg options: Enable trailing ? for map_channel
On Thu, Aug 24, 2017 at 08:17:58AM +0200, pkv.stream wrote: > Le 24/08/2017 à 2:30 AM, Michael Niedermayer a écrit : > >On Wed, Aug 23, 2017 at 06:48:14PM +0200, pkv.stream wrote: > >>Hello, > >> > >>the following patch allows one to add a trailing ? to -map_channel > >>as in -map option. > >> > >>E.g: -map_channel 0.0.2? so that if the channel does not exist, the > >>command does not stop. > >> > >>This is similar to what one can do with -map. > >> > >>Thanks for any input. > >> > >> > >> ffmpeg_opt.c | 24 > >> 1 file changed, 20 insertions(+), 4 deletions(-) > >>28689933986d73050286e700752ace032df6dc1b > >>0001-ffmpeg-options-Enable-trailing-for-map_channel.patch > >> From 07959dfe79816d03c30b8027f45b41d60078b3fa Mon Sep 17 00:00:00 2001 > >>From: pkviet > >>Date: Tue, 22 Aug 2017 11:30:45 +0200 > >>Subject: [PATCH] ffmpeg options: Enable trailing ? for map_channel > >> > >>The -map option allows for a trailing ? so that an error is not thrown if > >>the input stream does not exist. > >>This capability is extended to the map_channel option. > >>This allows a ffmpeg command not to break if an input channel does not > >>exist, which can be of use (for instance, scripts processing audio > >>channels with sources having unset number of audio channels). > >>--- > >> ffmpeg_opt.c | 24 > >> 1 file changed, 20 insertions(+), 4 deletions(-) > >the patch contains tabs (cannot be pushed to git master) > >and this is missing an update to the documentation > > thanks Michael. > Patch corrected per your instructions. > Updated doc , provided an example and removed all tabs ! ok, thanks can you also add a self test to "make fate" ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg options: Enable trailing ? for map_channel
Yes I did a make fate. Went ok. Is there a log to attach ? Or stdout ? Le 24 août 2017 10:34 AM, "Michael Niedermayer" a écrit : On Thu, Aug 24, 2017 at 08:17:58AM +0200, pkv.stream wrote: > Le 24/08/2017 à 2:30 AM, Michael Niedermayer a écrit : > >On Wed, Aug 23, 2017 at 06:48:14PM +0200, pkv.stream wrote: > >>Hello, > >> > >>the following patch allows one to add a trailing ? to -map_channel > >>as in -map option. > >> > >>E.g: -map_channel 0.0.2? so that if the channel does not exist, the > >>command does not stop. > >> > >>This is similar to what one can do with -map. > >> > >>Thanks for any input. > >> > >> > >> ffmpeg_opt.c | 24 > >> 1 file changed, 20 insertions(+), 4 deletions(-) > >>28689933986d73050286e700752ace032df6dc1b 0001-ffmpeg-options-Enable- trailing-for-map_channel.patch > >> From 07959dfe79816d03c30b8027f45b41d60078b3fa Mon Sep 17 00:00:00 2001 > >>From: pkviet > >>Date: Tue, 22 Aug 2017 11:30:45 +0200 > >>Subject: [PATCH] ffmpeg options: Enable trailing ? for map_channel > >> > >>The -map option allows for a trailing ? so that an error is not thrown if > >>the input stream does not exist. > >>This capability is extended to the map_channel option. > >>This allows a ffmpeg command not to break if an input channel does not > >>exist, which can be of use (for instance, scripts processing audio > >>channels with sources having unset number of audio channels). > >>--- > >> ffmpeg_opt.c | 24 > >> 1 file changed, 20 insertions(+), 4 deletions(-) > >the patch contains tabs (cannot be pushed to git master) > >and this is missing an update to the documentation > > thanks Michael. > Patch corrected per your instructions. > Updated doc , provided an example and removed all tabs ! ok, thanks can you also add a self test to "make fate" ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch ___ 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] ffmpeg options: Enable trailing ? for map_channel
On Thu, Aug 24, 2017 at 10:36:20AM +0200, Kv Pham wrote: > Yes I did a make fate. Went ok. > Is there a log to attach ? Or stdout ? i meant can you add a test that tests the new feature when one runs make fate that is if the user runs "make fate" it would execute ffmpeg with map and "trailing ?" > > > Le 24 août 2017 10:34 AM, "Michael Niedermayer" a > écrit : > > On Thu, Aug 24, 2017 at 08:17:58AM +0200, pkv.stream wrote: > > Le 24/08/2017 à 2:30 AM, Michael Niedermayer a écrit : > > >On Wed, Aug 23, 2017 at 06:48:14PM +0200, pkv.stream wrote: > > >>Hello, > > >> > > >>the following patch allows one to add a trailing ? to -map_channel > > >>as in -map option. > > >> > > >>E.g: -map_channel 0.0.2? so that if the channel does not exist, the > > >>command does not stop. > > >> > > >>This is similar to what one can do with -map. > > >> > > >>Thanks for any input. > > >> > > >> > > >> ffmpeg_opt.c | 24 > > >> 1 file changed, 20 insertions(+), 4 deletions(-) > > >>28689933986d73050286e700752ace032df6dc1b 0001-ffmpeg-options-Enable- > trailing-for-map_channel.patch > > >> From 07959dfe79816d03c30b8027f45b41d60078b3fa Mon Sep 17 00:00:00 2001 > > >>From: pkviet > > >>Date: Tue, 22 Aug 2017 11:30:45 +0200 > > >>Subject: [PATCH] ffmpeg options: Enable trailing ? for map_channel > > >> > > >>The -map option allows for a trailing ? so that an error is not thrown > if > > >>the input stream does not exist. > > >>This capability is extended to the map_channel option. > > >>This allows a ffmpeg command not to break if an input channel does not > > >>exist, which can be of use (for instance, scripts processing audio > > >>channels with sources having unset number of audio channels). > > >>--- > > >> ffmpeg_opt.c | 24 > > >> 1 file changed, 20 insertions(+), 4 deletions(-) > > >the patch contains tabs (cannot be pushed to git master) > > >and this is missing an update to the documentation > > > > thanks Michael. > > Patch corrected per your instructions. > > Updated doc , provided an example and removed all tabs ! > > ok, thanks > can you also add a self test to "make fate" ? > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Let us carefully observe those good qualities wherein our enemies excel us > and endeavor to excel them, by avoiding what is faulty, and imitating what > is excellent in them. -- Plutarch > > ___ > 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 -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] all: avoid data imports across DLL boundaries
On Wed, 23 Aug 2017 19:23:12 -0300 James Almer wrote: > On 8/21/2017 2:51 PM, wm4 wrote: > > From: Pedro Pombeiro > > > > DLL data imports cause problems on Windows. They normally require > > each variable to be correctly marked with dllimport/dllexport > > declspecs. For MSVC, we define av_export to dllimport declspec. This > > is not entirely correct - depending on which sub-lib is built, they > > should be marked to dllexport instead. It happens to work with MSVC, > > because it supports exports incorrectly marked as imports. Trying to > > use this breaks on MinGW and results in linker errors. > > > > On MinGW, not using any import/export specifiers happens to work, > > because binutils and the MinGW runtime provide "pseudo relocations", > > which manually fix these imports at load time. This does not work with > > MinGW WinRT builds: the relocations cannot be performed because this > > would require writing to the code section, which is not allowed. > > > > Get rid of all these issues by not using data exports/imports. The > > public API is already free of them, but avpriv_ symbols make extensive > > use of them. Replace them all with getters. > > Should be good i think, but it can't be applied as is until the next > major bump as it breaks ABI (Tons of avpriv_ symbols are removed). Well, I call bullshit. We've never taken ABI compatibility between FFmpeg libs seriously, especially not if it was about avpriv functions. And guess what? You didn't either. Commit 7c9d2ad45f4e46ad2c3b2 is authored and committed by you, and changes an avpriv function in an incompatible way, without even minor version bumps. > Speaking of which, do you or anyone else want to help with applying the > bump right now instead of waiting until the merges are resumed? > Finding what deprecated APIs are two years or older, removing them and > seeing if any further changes are needed to ensure compilation after the > bump (I bet a lot will require changes since deprecations imported from > libav aren't given much attention here outside of making sure warnings > are silenced). > ABI changes, like moving fields around within a struct or into an opaque > internal struct, removing/modifying avpriv_ functions, etc, are things > that can be done during several weeks after the bump and not necessarily > as preparation for it. > > Certain deprecated APIs that are two years or older could be kept in > place if removing them takes too much work at the moment, but the bump > is pretty overdue by now due to the amount of crap some structs are > currently dealing with (public vs private fields, offsets, etc). > We've had enough ABI breakages with this set of major versions so it > would be great if we can move on from it before a new release is tagged. That sounds good, but I don't think I want to fight this fight (because it's going to be a fight). Libav already bumped recently. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.
On Wed, Aug 23, 2017 at 03:39:01PM -0700, Dale Curtis wrote: > On Sat, Aug 19, 2017 at 3:50 PM, Michael Niedermayer > wrote: > > > On Sun, Aug 20, 2017 at 12:48:30AM +0200, Michael Niedermayer wrote: > > > On Fri, Aug 18, 2017 at 03:57:45PM -0700, Dale Curtis wrote: > > > > Anything else here? It'd be nice to get this landed soon if no one has > > any > > > > other comments. > > > > > > it appears to not apply cleanly anymore > > > > seems caused by f4544163b27615ecfff1b42d6acdb3672ac92399. > > > > Thanks rebased on ToT after chatting with Jacob to ensure my patch didn't > regress his issue. > > - dale > libavformat/isom.h |1 > libavformat/mov.c| 92 +++- > tests/fate/seek.mak |3 + > tests/ref/seek/extra-mp4 | 134 > +++ > 4 files changed, 195 insertions(+), 35 deletions(-) > 98449b2f1a0464b474c3b17ee29850daa1b0081a ctts_fix_v9.patch > From b4b49b6b584b33e1da95a5d72b05fd9134ab28f9 Mon Sep 17 00:00:00 2001 > From: Dale Curtis > Date: Mon, 17 Jul 2017 17:38:09 -0700 > Subject: [PATCH] Fix trampling of ctts during seeks when sidx support is > enabled. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/rtpdec_h264: Fix heap-buffer-overflow
On Wed, Aug 23, 2017 at 10:50:42PM +0200, Michael Niedermayer wrote: > Fixes: rtp_sdp/poc.sdp > > Found-by: Bingchang > Signed-off-by: Michael Niedermayer > --- > libavformat/rtpdec_h264.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg options: Enable trailing ? for map_channel
Ah ok! Sure, I will do that. I need first to acquaint myself more with fate. Le 24 août 2017 10:52 AM, "Michael Niedermayer" a écrit : On Thu, Aug 24, 2017 at 10:36:20AM +0200, Kv Pham wrote: > Yes I did a make fate. Went ok. > Is there a log to attach ? Or stdout ? i meant can you add a test that tests the new feature when one runs make fate that is if the user runs "make fate" it would execute ffmpeg with map and "trailing ?" > > > Le 24 août 2017 10:34 AM, "Michael Niedermayer" a > écrit : > > On Thu, Aug 24, 2017 at 08:17:58AM +0200, pkv.stream wrote: > > Le 24/08/2017 à 2:30 AM, Michael Niedermayer a écrit : > > >On Wed, Aug 23, 2017 at 06:48:14PM +0200, pkv.stream wrote: > > >>Hello, > > >> > > >>the following patch allows one to add a trailing ? to -map_channel > > >>as in -map option. > > >> > > >>E.g: -map_channel 0.0.2? so that if the channel does not exist, the > > >>command does not stop. > > >> > > >>This is similar to what one can do with -map. > > >> > > >>Thanks for any input. > > >> > > >> > > >> ffmpeg_opt.c | 24 > > >> 1 file changed, 20 insertions(+), 4 deletions(-) > > >>28689933986d73050286e700752ace032df6dc1b 0001-ffmpeg-options-Enable- > trailing-for-map_channel.patch > > >> From 07959dfe79816d03c30b8027f45b41d60078b3fa Mon Sep 17 00:00:00 2001 > > >>From: pkviet > > >>Date: Tue, 22 Aug 2017 11:30:45 +0200 > > >>Subject: [PATCH] ffmpeg options: Enable trailing ? for map_channel > > >> > > >>The -map option allows for a trailing ? so that an error is not thrown > if > > >>the input stream does not exist. > > >>This capability is extended to the map_channel option. > > >>This allows a ffmpeg command not to break if an input channel does not > > >>exist, which can be of use (for instance, scripts processing audio > > >>channels with sources having unset number of audio channels). > > >>--- > > >> ffmpeg_opt.c | 24 > > >> 1 file changed, 20 insertions(+), 4 deletions(-) > > >the patch contains tabs (cannot be pushed to git master) > > >and this is missing an update to the documentation > > > > thanks Michael. > > Patch corrected per your instructions. > > Updated doc , provided an example and removed all tabs ! > > ok, thanks > can you also add a self test to "make fate" ? > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Let us carefully observe those good qualities wherein our enemies excel us > and endeavor to excel them, by avoiding what is faulty, and imitating what > is excellent in them. -- Plutarch > > ___ > 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 -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] all: avoid data imports across DLL boundaries
On Thu, Aug 24, 2017 at 10:52:55AM +0200, wm4 wrote: > On Wed, 23 Aug 2017 19:23:12 -0300 > James Almer wrote: > > > On 8/21/2017 2:51 PM, wm4 wrote: > > > From: Pedro Pombeiro > > > > > > DLL data imports cause problems on Windows. They normally require > > > each variable to be correctly marked with dllimport/dllexport > > > declspecs. For MSVC, we define av_export to dllimport declspec. This > > > is not entirely correct - depending on which sub-lib is built, they > > > should be marked to dllexport instead. It happens to work with MSVC, > > > because it supports exports incorrectly marked as imports. Trying to > > > use this breaks on MinGW and results in linker errors. > > > > > > On MinGW, not using any import/export specifiers happens to work, > > > because binutils and the MinGW runtime provide "pseudo relocations", > > > which manually fix these imports at load time. This does not work with > > > MinGW WinRT builds: the relocations cannot be performed because this > > > would require writing to the code section, which is not allowed. > > > > > > Get rid of all these issues by not using data exports/imports. The > > > public API is already free of them, but avpriv_ symbols make extensive > > > use of them. Replace them all with getters. > > > > Should be good i think, but it can't be applied as is until the next > > major bump as it breaks ABI (Tons of avpriv_ symbols are removed). > > Well, I call bullshit. We've never taken ABI compatibility between > FFmpeg libs seriously, especially not if it was about avpriv functions. We did take ABI compatibility between FFmpeg libs serious. And we must to be shiped by distributions that package the libs based on our ABI versions. > > And guess what? You didn't either. Commit 7c9d2ad45f4e46ad2c3b2 is > authored and committed by you, and changes an avpriv function in an > incompatible way, without even minor version bumps. This commit did not break ABI no release contains the removed symbol: git grep avpriv_dca_parse_core_frame_header release/3.3 git grep avpriv_dca_parse_core_frame_header release/3.2 git grep avpriv_dca_parse_core_frame_header release/3.1 git grep avpriv_dca_parse_core_frame_header release/3.0 git grep avpriv_dca_parse_core_frame_header release/2.4 git grep avpriv_dca_parse_core_frame_header release/2.8 The symbol was added 9 days before it was removed, it was in no release commit 7c9d2ad45f4e46ad2c3b2e93051efbe1e0d0529e Author: James Almer Date: Wed Jul 19 01:53:22 2017 -0300 avcodec/dca: remove GetBitContext usage from avpriv_dca_parse_core_frame_header() commit 2123ddb4251bf39bde8b38a1307a0f6154d260e6 Author: foo86 Date: Mon Jul 10 17:11:33 2017 +0300 avcodec: add avpriv_dca_parse_core_frame_header() [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.
On Wed, Aug 23, 2017 at 03:39:01PM -0700, Dale Curtis wrote: > On Sat, Aug 19, 2017 at 3:50 PM, Michael Niedermayer > wrote: > > > On Sun, Aug 20, 2017 at 12:48:30AM +0200, Michael Niedermayer wrote: > > > On Fri, Aug 18, 2017 at 03:57:45PM -0700, Dale Curtis wrote: > > > > Anything else here? It'd be nice to get this landed soon if no one has > > any > > > > other comments. > > > > > > it appears to not apply cleanly anymore > > > > seems caused by f4544163b27615ecfff1b42d6acdb3672ac92399. > > > > Thanks rebased on ToT after chatting with Jacob to ensure my patch didn't > regress his issue. > > - dale > libavformat/isom.h |1 > libavformat/mov.c| 92 +++- > tests/fate/seek.mak |3 + > tests/ref/seek/extra-mp4 | 134 > +++ > 4 files changed, 195 insertions(+), 35 deletions(-) > 98449b2f1a0464b474c3b17ee29850daa1b0081a ctts_fix_v9.patch > From b4b49b6b584b33e1da95a5d72b05fd9134ab28f9 Mon Sep 17 00:00:00 2001 > From: Dale Curtis > Date: Mon, 17 Jul 2017 17:38:09 -0700 > Subject: [PATCH] Fix trampling of ctts during seeks when sidx support is > enabled. > > When sidx box support is enabled, the code will skip reading all > trun boxes (each containing ctts entries for samples inthat box). > > If seeks are attempted before all ctts values are known, the old > code would dump ctts entries into the wrong location. These are > then used to compute pts values which leads to out of order and > incorrectly timestamped packets. > > This patch fixes ctts processing by always using the index returned > by av_add_index_entry() as the ctts_data index. When the index gains > new entries old values are reshuffled as appropriate. > > This approach makes sense since the mov demuxer is already relying > on the mapping of AVIndex entries to samples for correct demuxing. > > As a result of this all ctts entries are now 1-count. A followup > change will be submitted to remove support for > 1 count entries > which will simplify seeking. > > Notes for future improvement: > Probably there are other boxes (stts, stsc, etc) that are impacted > by this issue... this patch only attempts to fix ctts since it > completely breaks packet timestamping. > > This patch continues using an array for the ctts data, which is not > the most ideal given the rearrangement that needs to happen (via > memmove as new entries are read in). Ideally AVIndex and the ctts > data would be set-type structures so addition is always worst case > O(lg(n)) instead of the O(n^2) that exists now; this slowdown is > noticeable during seeks. can the insertions be done in groups instead of one at a time ? so that it basically merges 2 lists (O(n)) instead of inserting one at a time O(n^2) ? This would significantly improve the worst case while not needing to change the data structures (of course iam not against changing the data structures if someone wants to do the work) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/hevc_ps: Check delta_pocs in ff_hevc_decode_short_term_rps()
On Mon, Aug 21, 2017 at 02:15:50AM +0200, Michael Niedermayer wrote: > Fixes: integer overflow > Fixes: 2893/clusterfuzz-testcase-minimized-5809330567774208 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/hevc_ps.c | 12 > 1 file changed, 12 insertions(+) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] all: avoid data imports across DLL boundaries
On Thu, Aug 24, 2017 at 10:52 AM, wm4 wrote: > On Wed, 23 Aug 2017 19:23:12 -0300 > James Almer wrote: > >> On 8/21/2017 2:51 PM, wm4 wrote: >> > From: Pedro Pombeiro >> > >> > DLL data imports cause problems on Windows. They normally require >> > each variable to be correctly marked with dllimport/dllexport >> > declspecs. For MSVC, we define av_export to dllimport declspec. This >> > is not entirely correct - depending on which sub-lib is built, they >> > should be marked to dllexport instead. It happens to work with MSVC, >> > because it supports exports incorrectly marked as imports. Trying to >> > use this breaks on MinGW and results in linker errors. >> > >> > On MinGW, not using any import/export specifiers happens to work, >> > because binutils and the MinGW runtime provide "pseudo relocations", >> > which manually fix these imports at load time. This does not work with >> > MinGW WinRT builds: the relocations cannot be performed because this >> > would require writing to the code section, which is not allowed. >> > >> > Get rid of all these issues by not using data exports/imports. The >> > public API is already free of them, but avpriv_ symbols make extensive >> > use of them. Replace them all with getters. >> >> Should be good i think, but it can't be applied as is until the next >> major bump as it breaks ABI (Tons of avpriv_ symbols are removed). > > Well, I call bullshit. We've never taken ABI compatibility between > FFmpeg libs seriously, especially not if it was about avpriv functions. > > And guess what? You didn't either. Commit 7c9d2ad45f4e46ad2c3b2 is > authored and committed by you, and changes an avpriv function in an > incompatible way, without even minor version bumps. > That function was added 2 days earlier, clearly still falling into the grace period of new functions. If you try to find cheap excuses, at least put some effort into it. :p avpriv is part of the public ABI and as such cannot be blindly removed. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg options: Enable trailing ? for map_channel
2017-08-24 11:03 GMT+02:00 Kv Pham : > Ah ok! > Sure, I will do that. I need first to acquaint myself more with fate. > > > Hello, You can take a look at ./tests/fate/ffmpeg.mak (begin of the file seems to have test for map_channel) I think you need to add two test, one when the channel is found, and one when the channel is not found. The idea is to find an ffmpeg cmd, using generator (as input file), or input file already in the fate-suite if possible and use framecrc for example, as output, (with a minimal log level) Then you add the result as a txt file in \tests\ref\fate (with a naming consistent with the name of the test) Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] ffprobe: Fix null pointer dereference with color primaries
On Tue, Aug 22, 2017 at 06:34:35PM +0200, Michael Niedermayer wrote: > Found-by: AD-lab of venustech > Signed-off-by: Michael Niedermayer > --- > ffprobe.c | 20 > 1 file changed, 12 insertions(+), 8 deletions(-) patchet applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg options: Enable trailing ? for map_channel
Thanks a lot Martin. I had spotted ffmpeg.mak but your input is very helpful Le 24 août 2017 11:32 AM, "Martin Vignali" a écrit : 2017-08-24 11:03 GMT+02:00 Kv Pham : > Ah ok! > Sure, I will do that. I need first to acquaint myself more with fate. > > > Hello, You can take a look at ./tests/fate/ffmpeg.mak (begin of the file seems to have test for map_channel) I think you need to add two test, one when the channel is found, and one when the channel is not found. The idea is to find an ffmpeg cmd, using generator (as input file), or input file already in the fate-suite if possible and use framecrc for example, as output, (with a minimal log level) Then you add the result as a txt file in \tests\ref\fate (with a naming consistent with the name of the test) Martin ___ 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]lsws/rgb2rgb: Add unscaled 48 to 64bit conversion
2017-08-24 2:27 GMT+02:00 Michael Niedermayer : > On Wed, Aug 23, 2017 at 02:21:40PM +0200, Carl Eugen Hoyos wrote: >> Hi! >> > >> Attached patch fixes ticket #6608. > > iam not sure thats the correct fix for the ticket but the patch is a > good idea none the less > thus LGTM Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/g726: Add a raw little-endian G.726 demuxer
2017-08-21 17:24 GMT+02:00 Carl Eugen Hoyos : > 2017-08-18 19:25 GMT+02:00 Carl Eugen Hoyos : >> Hi! >> >> Attached patch allows to read files produced by the "ITU compatible >> binary G726 encoder" attached to ticket #6596. > > New patch attached that also allows reading an old sample found on > ubuntuusers.de containing big-endian G.726 from "SEG Mp3-Player". Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/put_bits: Remove usage of BITSTREAM_WRITER_LE.
2017-08-23 0:56 GMT+02:00 Ivan Kalvachev : > On 8/22/17, Ronald S. Bultje wrote: >> Hi, >> >> On Mon, Aug 21, 2017 at 11:16 AM, Carl Eugen Hoyos >> wrote: >> >>> Hi! >>> >>> Attached patch tries to slightly simplify and clean up the usage of >>> put_bits* in libavcodec: put_bits_le() functions exist for the >>> little-endian G.726 encoder, so the define makes less sense now. >>> >>> Fate passes here, please review, Carl Eugen >> >> I have to agree with Paul here, I can't say I'm a big fan of this... > > People, > As developers you are required > not only to give ultimate final verdicts, > but also give (nice technical) reasoning for them. > > Here is my list of pro and cons: > > - If it ain't broken, don't change it. No objection here - on the contrary, I wish this argument would count here more often... > + Bytesteam already uses explicit _le/be and it looks good. > > + Makes the code more clear. It is obvious that the given encoder > writes BE stream. Something that could easily be missed with the > single define. > - The type of bitstream however is not really important for the codec > working. Aka, there is no confusing, because no codec writes BE and LE > at the same time.(yet) Not at the same time but in the same encoder file (G.726). > + Removes messy defines that obfuscate put_bits code, by separating > the big and little ending code. > - Duplicates put_bits.h code. It would probably make reworking harder, > as changes have to be synced in 2 places. I don't think this is correct (and not what the diffstats show afair) but it doesn't matter: I was under the impression this patch was a requirement after a previous commit, I am not particularly keen on it, see above. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavf/rawenc: Add G.726 muxers
Hi!
Attached patch makes creating G.726 files slightly easier.
Please comment, Carl Eugen
From 9c6effa57ba37d8881a213da66e23e6c25c46665 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 24 Aug 2017 13:06:06 +0200
Subject: [PATCH] lavf/rawenc: Add little- and big-endian G.726 muxers.
---
libavformat/Makefile |2 ++
libavformat/allformats.c |4 ++--
libavformat/rawenc.c | 24
libavformat/version.h|2 +-
4 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 8e2afb7..9f8cdb5 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -189,7 +189,9 @@ OBJS-$(CONFIG_GXF_DEMUXER) += gxf.o
OBJS-$(CONFIG_GXF_MUXER) += gxfenc.o audiointerleave.o
OBJS-$(CONFIG_G722_DEMUXER) += g722.o rawdec.o
OBJS-$(CONFIG_G726_DEMUXER) += g726.o
+OBJS-$(CONFIG_G726_MUXER)+= rawenc.o
OBJS-$(CONFIG_G726LE_DEMUXER)+= g726.o
+OBJS-$(CONFIG_G726LE_MUXER) += rawenc.o
OBJS-$(CONFIG_G722_MUXER)+= rawenc.o
OBJS-$(CONFIG_G723_1_DEMUXER)+= g723_1.o
OBJS-$(CONFIG_G723_1_MUXER) += rawenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 78ff2eb..2f25e59 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -132,8 +132,8 @@ static void register_all(void)
REGISTER_DEMUXER (FRM, frm);
REGISTER_DEMUXER (FSB, fsb);
REGISTER_MUXDEMUX(G722, g722);
-REGISTER_DEMUXER (G726, g726);
-REGISTER_DEMUXER (G726LE, g726le);
+REGISTER_MUXDEMUX(G726, g726);
+REGISTER_MUXDEMUX(G726LE, g726le);
REGISTER_MUXDEMUX(G723_1, g723_1);
REGISTER_DEMUXER (G729, g729);
REGISTER_DEMUXER (GDV, gdv);
diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index 26baa85..aa491a4 100644
--- a/libavformat/rawenc.c
+++ b/libavformat/rawenc.c
@@ -196,6 +196,30 @@ AVOutputFormat ff_g723_1_muxer = {
};
#endif
+#if CONFIG_G726_MUXER
+AVOutputFormat ff_g726_muxer = {
+.name = "g726",
+.long_name = NULL_IF_CONFIG_SMALL("raw big-endian G.726 (\"left-justified\")"),
+.audio_codec = AV_CODEC_ID_G726,
+.video_codec = AV_CODEC_ID_NONE,
+.write_header = force_one_stream,
+.write_packet = ff_raw_write_packet,
+.flags = AVFMT_NOTIMESTAMPS,
+};
+#endif
+
+#if CONFIG_G726LE_MUXER
+AVOutputFormat ff_g726_lemuxer = {
+.name = "g726le",
+.long_name = NULL_IF_CONFIG_SMALL("raw little-endian G.726 (\"right-justified\")"),
+.audio_codec = AV_CODEC_ID_G726LE,
+.video_codec = AV_CODEC_ID_NONE,
+.write_header = force_one_stream,
+.write_packet = ff_raw_write_packet,
+.flags = AVFMT_NOTIMESTAMPS,
+};
+#endif
+
#if CONFIG_GSM_MUXER
AVOutputFormat ff_gsm_muxer = {
.name = "gsm",
diff --git a/libavformat/version.h b/libavformat/version.h
index a8cf4c1..94081ac 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
// Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
// Also please add any ticket numbers that you believe might be affected here
#define LIBAVFORMAT_VERSION_MAJOR 57
-#define LIBAVFORMAT_VERSION_MINOR 77
+#define LIBAVFORMAT_VERSION_MINOR 78
#define LIBAVFORMAT_VERSION_MICRO 100
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mjpeg: Add support for ICC side data
On 8/24/2017 1:22 AM, Michael Niedermayer wrote: > should be ok i think Rostislav asked me on IRC to try with MJPEG, so I am going to try and synthesize such a file and work on a v2. I don't suppose you, or anyone else has an MJPEG file with ICC profiles embedded? :) - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] mjpeg: Add support for ICC side data
JPEGs store embedded profiles under the APP2 marker, signified
with a "ICC_PROFILE" null-terminated string header, and can be
split across multiple APP2 markers, out of order.
Signed-off-by: Derek Buitenhuis
---
libavcodec/mjpegdec.c | 104 ++
libavcodec/mjpegdec.h | 5 +++
2 files changed, 109 insertions(+)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 387ceadf..b08ae0a 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1901,6 +1901,67 @@ static int mjpeg_decode_app(MJpegDecodeContext *s)
}
}
+if (s->start_code == APP2 && id == AV_RB32("ICC_") && len >= 10) {
+int id2;
+unsigned seqno;
+unsigned nummarkers;
+
+id = get_bits_long(&s->gb, 32);
+id2 = get_bits_long(&s->gb, 24);
+len -= 7;
+if (id != AV_RB32("PROF") || id2 != AV_RB24("ILE")) {
+av_log(s->avctx, AV_LOG_WARNING, "Invalid ICC_PROFILE header in
APP2\n");
+goto out;
+}
+
+skip_bits(&s->gb, 8);
+seqno = get_bits(&s->gb, 8);
+len -= 2;
+if (seqno == 0) {
+av_log(s->avctx, AV_LOG_WARNING, "Invalid sequence number in
APP2\n");
+goto out;
+}
+
+nummarkers = get_bits(&s->gb, 8);
+len-= 1;
+if (nummarkers == 0) {
+av_log(s->avctx, AV_LOG_WARNING, "Invalid number of markers coded
in APP2\n");
+goto out;
+} else if (s->iccnum != 0 && nummarkers != s->iccnum) {
+av_log(s->avctx, AV_LOG_WARNING, "Mistmatch in coded number of ICC
markers between markers\n");
+goto out;
+} else if (seqno > nummarkers) {
+av_log(s->avctx, AV_LOG_WARNING, "Mismatching sequence number and
coded number of ICC markers\n");
+goto out;
+}
+
+/* Allocate if this is the first APP2 we've seen. */
+if (s->iccnum == 0) {
+s->iccdata = av_mallocz(nummarkers * sizeof(*(s->iccdata)));
+s->iccdatalens = av_mallocz(nummarkers *
sizeof(*(s->iccdatalens)));
+if (!s->iccdata || !s->iccdatalens) {
+av_log(s->avctx, AV_LOG_ERROR, "Could not allocate ICC data
arrays\n");
+return AVERROR(ENOMEM);
+}
+s->iccnum = nummarkers;
+}
+
+s->iccdatalens[seqno - 1] = len;
+s->iccdata[seqno - 1] = av_malloc(len);
+if (!s->iccdata[seqno - 1]) {
+av_log(s->avctx, AV_LOG_ERROR, "Could not allocate ICC data
buffer\n");
+return AVERROR(ENOMEM);
+}
+
+memcpy(s->iccdata[seqno - 1], align_get_bits(&s->gb), len);
+skip_bits(&s->gb, len << 3);
+len = 0;
+s->iccread++;
+
+if (s->iccread > s->iccnum)
+av_log(s->avctx, AV_LOG_WARNING, "Read more ICC markers than are
supposed to be coded\n");
+}
+
out:
/* slow but needed for extreme adobe jpegs */
if (len < 0)
@@ -2097,6 +2158,20 @@ int ff_mjpeg_find_marker(MJpegDecodeContext *s,
return start_code;
}
+static void reset_icc_profile(MJpegDecodeContext *s)
+{
+int i;
+
+if (s->iccdata)
+for (i = 0; i < s->iccnum; i++)
+av_freep(&s->iccdata[i]);
+av_freep(&s->iccdata);
+av_freep(&s->iccdatalens);
+
+s->iccread = 0;
+s->iccnum = 0;
+}
+
int ff_mjpeg_decode_frame(AVCodecContext *avctx, void *data, int *got_frame,
AVPacket *avpkt)
{
@@ -2117,6 +2192,9 @@ int ff_mjpeg_decode_frame(AVCodecContext *avctx, void
*data, int *got_frame,
av_freep(&s->stereo3d);
s->adobe_transform = -1;
+if (s->iccnum != 0)
+reset_icc_profile(s);
+
buf_ptr = buf;
buf_end = buf + buf_size;
while (buf_ptr < buf_end) {
@@ -2509,6 +2587,29 @@ the_end:
av_freep(&s->stereo3d);
}
+if (s->iccnum != 0 && s->iccnum == s->iccread) {
+AVFrameSideData *sd;
+size_t offset = 0;
+int total_size = 0;
+int i;
+
+/* Sum size of all parts. */
+for (i = 0; i < s->iccnum; i++)
+total_size += s->iccdatalens[i];
+
+sd = av_frame_new_side_data(data, AV_FRAME_DATA_ICC_PROFILE,
total_size);
+if (!sd) {
+av_log(s->avctx, AV_LOG_ERROR, "Could not allocate frame side
data\n");
+return AVERROR(ENOMEM);
+}
+
+/* Reassemble the parts, which are now in-order. */
+for (i = 0; i < s->iccnum; i++) {
+memcpy(sd->data + offset, s->iccdata[i], s->iccdatalens[i]);
+offset += s->iccdatalens[i];
+}
+}
+
av_dict_copy(&((AVFrame *) data)->metadata, s->exif_metadata, 0);
av_dict_free(&s->exif_metadata);
@@ -2548,6 +2649,9 @@ av_cold int ff_mjpeg_decode_end(AVCodecContext *avctx)
av_freep(&s->last_nnz[i]);
}
av_dict_free(&s->exif_metadata);
+
+reset_icc_profile(s);
+
return
Re: [FFmpeg-devel] [PATCH] all: avoid data imports across DLL boundaries
On 8/24/2017 5:52 AM, wm4 wrote: > On Wed, 23 Aug 2017 19:23:12 -0300 > James Almer wrote: > >> On 8/21/2017 2:51 PM, wm4 wrote: >>> From: Pedro Pombeiro >>> >>> DLL data imports cause problems on Windows. They normally require >>> each variable to be correctly marked with dllimport/dllexport >>> declspecs. For MSVC, we define av_export to dllimport declspec. This >>> is not entirely correct - depending on which sub-lib is built, they >>> should be marked to dllexport instead. It happens to work with MSVC, >>> because it supports exports incorrectly marked as imports. Trying to >>> use this breaks on MinGW and results in linker errors. >>> >>> On MinGW, not using any import/export specifiers happens to work, >>> because binutils and the MinGW runtime provide "pseudo relocations", >>> which manually fix these imports at load time. This does not work with >>> MinGW WinRT builds: the relocations cannot be performed because this >>> would require writing to the code section, which is not allowed. >>> >>> Get rid of all these issues by not using data exports/imports. The >>> public API is already free of them, but avpriv_ symbols make extensive >>> use of them. Replace them all with getters. >> >> Should be good i think, but it can't be applied as is until the next >> major bump as it breaks ABI (Tons of avpriv_ symbols are removed). > > Well, I call bullshit. We've never taken ABI compatibility between > FFmpeg libs seriously, especially not if it was about avpriv functions. This is not true. I even mentioned how the current set of major versions had to deal with a bunch of accidental breakages between releases (mostly in avcodec and avfilter back in the 3.0 and 3.1 days), all related to ABI. We had to compromise and release a point version to put fields back in their original offset. > > And guess what? You didn't either. Commit 7c9d2ad45f4e46ad2c3b2 is > authored and committed by you, and changes an avpriv function in an > incompatible way, without even minor version bumps. Michael and Hendrik already explained why this is not a good example. > >> Speaking of which, do you or anyone else want to help with applying the >> bump right now instead of waiting until the merges are resumed? >> Finding what deprecated APIs are two years or older, removing them and >> seeing if any further changes are needed to ensure compilation after the >> bump (I bet a lot will require changes since deprecations imported from >> libav aren't given much attention here outside of making sure warnings >> are silenced). >> ABI changes, like moving fields around within a struct or into an opaque >> internal struct, removing/modifying avpriv_ functions, etc, are things >> that can be done during several weeks after the bump and not necessarily >> as preparation for it. >> >> Certain deprecated APIs that are two years or older could be kept in >> place if removing them takes too much work at the moment, but the bump >> is pretty overdue by now due to the amount of crap some structs are >> currently dealing with (public vs private fields, offsets, etc). >> We've had enough ABI breakages with this set of major versions so it >> would be great if we can move on from it before a new release is tagged. > > That sounds good, but I don't think I want to fight this fight (because > it's going to be a fight). Libav already bumped recently. Not sure why you call it a fight, but that's the point. The merges are currently on hold, and I don't know when they will resume (Clément was waiting for someone to answer about some dash merges, i think), so just like how we're cherry picking certain commits in the queue I'd very much like to do the same with the bump related commits. We're already in the three digit minor version with some libraries, there are four releases using this set of major version, and a lot of ABI crap that needs to be cleaned asap. All the "public until this point, private from this point until this one where things are public again" crap in some headers, old avpriv_ symbols using GetBitContext like the one i fixed in 7c9d2ad45f, oversized tables, the ABI part of the side data split stuff, etc. Not to mention the deprecated APIs like the old resampler in avcodec. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Merge all libraries (was: all: avoid data imports across DLL) boundaries
Le sextidi 6 fructidor, an CCXXV, James Almer a écrit : > Speaking of which, do you or anyone else want to help with applying the > bump right now instead of waiting until the merges are resumed? If we are requesting help for a bump, I would like to propose seriously and request help for the attached patch. With this change, it builds a single libffmpeg.so.* instead of separate libav*.so.*. At this point, the library builds, and the command-line tools can be built against it and work, but I did not manage to get the build system to add -lffmpeg at the proper time. And all the extra stuff (make clean, make install, pkg-config file) is still completely unchanged. There are many benefits to merging the libraries: - Easier to share code between components without compatibility issues (exactly what James complains about here). - Less clueless users not managing to link their applications because they do not know that the linking order matters. - Opens the road to getting rid of the global state. I did not manage to find a real drawback. If somebody finds it a bad idea, then please explain to me what benefit we get from having several separate libraries. This is not a rhetorical question, I really would like an explanation. But I do not agree with the obvious argument of file size, because almost nobody would use lavu without the rest, because lavc dwarves all other libraries, and because people who care about file size do not use pre-built binaries and can disable components with much more control than library per library. Regards, -- Nicolas George From fcf7b622135a845e66bfa164447adb5fecacb1f6 Mon Sep 17 00:00:00 2001 From: Nicolas George Date: Mon, 31 Jul 2017 16:41:08 +0200 Subject: [PATCH] all: merge all libraries. Signed-off-by: Nicolas George --- Makefile | 6 +++- configure| 2 +- ffbuild/common.mak | 13 --- ffbuild/library.mak | 63 +- libavcodec/Makefile | 1 - libavcodec/log2_tab.c| 1 - libavcodec/reverse.c | 1 - libavdevice/Makefile | 1 - libavdevice/reverse.c| 1 - libavfilter/Makefile | 2 -- libavfilter/log2_tab.c | 1 - libavformat/Makefile | 1 - libavformat/golomb_tab.c | 1 - libavformat/log2_tab.c | 1 - libffmpeg/Makefile | 88 libffmpeg/libffmpeg.v| 23 + libswresample/Makefile | 1 - libswresample/log2_tab.c | 1 - libswscale/Makefile | 2 -- libswscale/log2_tab.c| 1 - 20 files changed, 126 insertions(+), 85 deletions(-) delete mode 100644 libavcodec/log2_tab.c delete mode 100644 libavcodec/reverse.c delete mode 100644 libavdevice/reverse.c delete mode 100644 libavfilter/log2_tab.c delete mode 100644 libavformat/golomb_tab.c delete mode 100644 libavformat/log2_tab.c create mode 100644 libffmpeg/Makefile create mode 100644 libffmpeg/libffmpeg.v delete mode 100644 libswresample/log2_tab.c delete mode 100644 libswscale/log2_tab.c diff --git a/Makefile b/Makefile index 29870d7710..4aaa966f4a 100644 --- a/Makefile +++ b/Makefile @@ -118,6 +118,10 @@ endef $(foreach D,$(FFLIBS),$(eval $(call DOSUBDIR,lib$(D +SUBDIR := libffmpeg/ +include $(SRC_PATH)/$(SUBDIR)Makefile +SUBDIR := diediedie + include $(SRC_PATH)/doc/Makefile define DOPROG @@ -208,7 +212,7 @@ check: all alltools examples testprogs fate include $(SRC_PATH)/tests/Makefile -$(sort $(OBJDIRS)): +$(sort $(OBJDIRS)) libffmpeg/: $(Q)mkdir -p $@ # Dummy rule to stop make trying to rebuild removed or renamed headers diff --git a/configure b/configure index 66c7b948e4..e3d18ff226 100755 --- a/configure +++ b/configure @@ -6226,7 +6226,7 @@ EOF # add some linker flags check_ldflags -Wl,--warn-common -check_ldflags -Wl,-rpath-link=libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample +check_ldflags -Wl,-rpath-link=libffmpeg enabled rpath && add_ldexeflags -Wl,-rpath,$libdir enabled rpath && add_ldlibflags -Wl,-rpath,$libdir test_ldflags -Wl,-Bsymbolic && append SHFLAGS -Wl,-Bsymbolic diff --git a/ffbuild/common.mak b/ffbuild/common.mak index e168fb2cfd..7499db0865 100644 --- a/ffbuild/common.mak +++ b/ffbuild/common.mak @@ -41,7 +41,7 @@ X86ASMFLAGS += $(IFLAGS:%=%/) -I$( $$@ - -$(SUBDIR)lib$(FULLNAME).pc: $(SUBDIR)version.h | $(SUBDIR) - $$(M) $$(SRC_PATH)/ffbuild/pkgconfig_generate.sh $(NAME) "$(DESC)" - -$(SUBDIR)lib$(NAME).ver: $(SUBDIR)lib$(NAME).v $(OBJS) - $$(M)sed 's/MAJOR/$(lib$(NAME)_VERSION_MAJOR)/' $$< | $(VERSION_SCRIPT_POSTPROCESS_CMD) > $$@ - -$(SUBDIR)$(SLIBNAME): $(SUBDIR)$(SLIBNAME_WITH_MAJOR) - $(Q)cd ./$(SUBDIR) && $(LN_S) $(SLIBNAME_WITH_MAJOR) $(SLIBNAME) - -$(SUBDIR)$(SLIBNAME_WITH_MAJOR): $(OBJS) $(SLIBOBJS) $(SUBDIR)lib$(NAME).ver - $(SLIB_CREATE_DEF_CMD) - $$(LD) $(SHFLAGS) $(LDFLAGS) $(LDLIBFLAGS) $$(LD_O) $$(filter %.o,$$^) $(FFEXTRALIBS) - $(SLIB_EXTRA_CMD) - -ifdef SUBDIR -$(SUBDIR)$(SLIBNA
Re: [FFmpeg-devel] Merge all libraries (was: all: avoid data imports across DLL) boundaries
> > I did not manage to find a real drawback. If somebody finds it a bad > idea, then please explain to me what benefit we get from having several > separate libraries. This is not a rhetorical question, I really would > like an explanation. But I do not agree with the obvious argument of > file size, because almost nobody would use lavu without the rest, > because lavc dwarves all other libraries, and because people who care > about file size do not use pre-built binaries and can disable components > with much more control than library per library. You clearly are not aware how much random junk in all libs is still enabled with --disable-everything. I don't use avformat, why should it be linked into my code. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] all: avoid data imports across DLL boundaries
On Thu, 24 Aug 2017 11:20:17 +0200 Michael Niedermayer wrote: > On Thu, Aug 24, 2017 at 10:52:55AM +0200, wm4 wrote: > > On Wed, 23 Aug 2017 19:23:12 -0300 > > James Almer wrote: > > > > > On 8/21/2017 2:51 PM, wm4 wrote: > > > > From: Pedro Pombeiro > > > > > > > > DLL data imports cause problems on Windows. They normally require > > > > each variable to be correctly marked with dllimport/dllexport > > > > declspecs. For MSVC, we define av_export to dllimport declspec. This > > > > is not entirely correct - depending on which sub-lib is built, they > > > > should be marked to dllexport instead. It happens to work with MSVC, > > > > because it supports exports incorrectly marked as imports. Trying to > > > > use this breaks on MinGW and results in linker errors. > > > > > > > > On MinGW, not using any import/export specifiers happens to work, > > > > because binutils and the MinGW runtime provide "pseudo relocations", > > > > which manually fix these imports at load time. This does not work with > > > > MinGW WinRT builds: the relocations cannot be performed because this > > > > would require writing to the code section, which is not allowed. > > > > > > > > Get rid of all these issues by not using data exports/imports. The > > > > public API is already free of them, but avpriv_ symbols make extensive > > > > use of them. Replace them all with getters. > > > > > > Should be good i think, but it can't be applied as is until the next > > > major bump as it breaks ABI (Tons of avpriv_ symbols are removed). > > > > Well, I call bullshit. We've never taken ABI compatibility between > > FFmpeg libs seriously, especially not if it was about avpriv functions. > > We did take ABI compatibility between FFmpeg libs serious. > And we must to be shiped by distributions that package the libs based > on our ABI versions. > > > > > > And guess what? You didn't either. Commit 7c9d2ad45f4e46ad2c3b2 is > > authored and committed by you, and changes an avpriv function in an > > incompatible way, without even minor version bumps. > > This commit did not break ABI > no release contains the removed symbol: > > git grep avpriv_dca_parse_core_frame_header release/3.3 > git grep avpriv_dca_parse_core_frame_header release/3.2 > git grep avpriv_dca_parse_core_frame_header release/3.1 > git grep avpriv_dca_parse_core_frame_header release/3.0 > git grep avpriv_dca_parse_core_frame_header release/2.4 > git grep avpriv_dca_parse_core_frame_header release/2.8 > > The symbol was added 9 days before it was removed, it was in no > release > > commit 7c9d2ad45f4e46ad2c3b2e93051efbe1e0d0529e > Author: James Almer > Date: Wed Jul 19 01:53:22 2017 -0300 > > avcodec/dca: remove GetBitContext usage from > avpriv_dca_parse_core_frame_header() > > commit 2123ddb4251bf39bde8b38a1307a0f6154d260e6 > Author: foo86 > Date: Mon Jul 10 17:11:33 2017 +0300 > > avcodec: add avpriv_dca_parse_core_frame_header() > [...] We keep ABI stability even within git master, not just within releases. Otherwise, our lives would be so much easier whenever ABI problems come up. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Merge all libraries (was: all: avoid data imports across DLL) boundaries
Le septidi 7 fructidor, an CCXXV, Kieran Kunhya a écrit : > You clearly are not aware how much random junk in all libs is still enabled > with --disable-everything. > I don't use avformat, why should it be linked into my code. Why should it not, if it makes things simpler for everybody? That is exactly what a library is: a collection of code, grouped for convenience; no application ever uses all of a non-trivial library. If you oppose to this, please explain an actual scenario where it makes things actually worse based on objective criteria. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] all: avoid data imports across DLL boundaries
On 8/24/2017 12:01 PM, wm4 wrote: > On Thu, 24 Aug 2017 11:20:17 +0200 > Michael Niedermayer wrote: > >> On Thu, Aug 24, 2017 at 10:52:55AM +0200, wm4 wrote: >>> On Wed, 23 Aug 2017 19:23:12 -0300 >>> James Almer wrote: >>> On 8/21/2017 2:51 PM, wm4 wrote: > From: Pedro Pombeiro > > DLL data imports cause problems on Windows. They normally require > each variable to be correctly marked with dllimport/dllexport > declspecs. For MSVC, we define av_export to dllimport declspec. This > is not entirely correct - depending on which sub-lib is built, they > should be marked to dllexport instead. It happens to work with MSVC, > because it supports exports incorrectly marked as imports. Trying to > use this breaks on MinGW and results in linker errors. > > On MinGW, not using any import/export specifiers happens to work, > because binutils and the MinGW runtime provide "pseudo relocations", > which manually fix these imports at load time. This does not work with > MinGW WinRT builds: the relocations cannot be performed because this > would require writing to the code section, which is not allowed. > > Get rid of all these issues by not using data exports/imports. The > public API is already free of them, but avpriv_ symbols make extensive > use of them. Replace them all with getters. Should be good i think, but it can't be applied as is until the next major bump as it breaks ABI (Tons of avpriv_ symbols are removed). >>> >>> Well, I call bullshit. We've never taken ABI compatibility between >>> FFmpeg libs seriously, especially not if it was about avpriv functions. >> >> We did take ABI compatibility between FFmpeg libs serious. >> And we must to be shiped by distributions that package the libs based >> on our ABI versions. >> >> >>> >>> And guess what? You didn't either. Commit 7c9d2ad45f4e46ad2c3b2 is >>> authored and committed by you, and changes an avpriv function in an >>> incompatible way, without even minor version bumps. >> >> This commit did not break ABI >> no release contains the removed symbol: >> >> git grep avpriv_dca_parse_core_frame_header release/3.3 >> git grep avpriv_dca_parse_core_frame_header release/3.2 >> git grep avpriv_dca_parse_core_frame_header release/3.1 >> git grep avpriv_dca_parse_core_frame_header release/3.0 >> git grep avpriv_dca_parse_core_frame_header release/2.4 >> git grep avpriv_dca_parse_core_frame_header release/2.8 >> >> The symbol was added 9 days before it was removed, it was in no >> release >> >> commit 7c9d2ad45f4e46ad2c3b2e93051efbe1e0d0529e >> Author: James Almer >> Date: Wed Jul 19 01:53:22 2017 -0300 >> >> avcodec/dca: remove GetBitContext usage from >> avpriv_dca_parse_core_frame_header() >> >> commit 2123ddb4251bf39bde8b38a1307a0f6154d260e6 >> Author: foo86 >> Date: Mon Jul 10 17:11:33 2017 +0300 >> >> avcodec: add avpriv_dca_parse_core_frame_header() >> [...] > > We keep ABI stability even within git master, not just within releases. > Otherwise, our lives would be so much easier whenever ABI problems come > up. Yes, that's why the fix was committed two or three days after the symbol was introduced, and not weeks after (Ignore the above dates, those are authoring dates). It was in any case a change that could have waited until the major bump. I hurried to replace it because i thought it was becoming the only GetBitContext usage in a libavcodec exported function, thus effectively making it part of the ABI, something that plays against any attempt to replace it with the new bitstream reader. Turns out that no, there were other avpriv_ symbols alredy using it, so a major bump is nonetheless required to fix GetBitContext's ABI dependency in other existing avpriv_ symbols. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg options: Enable trailing ? for map_channel
Hi working on creating a fate test. I am stumbling on probably a dumb issue; I want to re-use a file already used for mapchan test: FATE_MAPCHAN-$(CONFIG_CHANNELMAP_FILTER) += fate-mapchan-6ch-extract-2 fate-mapchan-6ch-extract-2: tests/data/asynth-22050-6.wav (first two lines in ffmpeg.mak) But I can't get a hold of this file. I have no data folder from git; after running a fate test, I get a fate-suite folder but this file is not included. Thanks for any hint. Le 24/08/2017 à 11:24 AM, Martin Vignali a écrit : 2017-08-24 11:03 GMT+02:00 Kv Pham : Ah ok! Sure, I will do that. I need first to acquaint myself more with fate. Hello, You can take a look at ./tests/fate/ffmpeg.mak (begin of the file seems to have test for map_channel) I think you need to add two test, one when the channel is found, and one when the channel is not found. The idea is to find an ffmpeg cmd, using generator (as input file), or input file already in the fate-suite if possible and use framecrc for example, as output, (with a minimal log level) Then you add the result as a txt file in \tests\ref\fate (with a naming consistent with the name of the test) Martin ___ 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] ffmpeg options: Enable trailing ? for map_channel
2017-08-24 21:16 GMT+02:00 pkv.stream : > Hi > working on creating a fate test. > I am stumbling on probably a dumb issue; I want to re-use a file already > used for mapchan test: > > FATE_MAPCHAN-$(CONFIG_CHANNELMAP_FILTER) += fate-mapchan-6ch-extract-2 > fate-mapchan-6ch-extract-2: tests/data/asynth-22050-6.wav > (first two lines in ffmpeg.mak) > > But I can't get a hold of this file. I have no data folder from git; after > running a fate test, I get a fate-suite folder but this file is not > included. > > Thanks for any hint. > > run make fate and take a look at ./tests/data/ the file is generated by make fate. Did you download samples files ? if not take a look here https://www.ffmpeg.org/fate.html So you can run a fate with all the tests. Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] utils: Do not expand a macro with 'defined' in it
Fixes:
libswscale/utils.c:1632:5: warning: macro expansion producing 'defined' has
undefined behavior [-Wexpansion-to-defined]
#if USE_MMAP
^
libswscale/utils.c:1577:49: note: expanded from macro 'USE_MMAP'
#define USE_MMAP (HAVE_MMAP && HAVE_MPROTECT && defined MAP_ANONYMOUS)
^
Signed-off-by: Derek Buitenhuis
---
libswscale/utils.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index b75510d..dcab707 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -1574,7 +1574,11 @@ av_cold int sws_init_context(SwsContext *c, SwsFilter
*srcFilter,
}
}
-#define USE_MMAP (HAVE_MMAP && HAVE_MPROTECT && defined MAP_ANONYMOUS)
+#if HAVE_MMAP && HAVE_MPROTECT && defined(MAP_ANONYMOUS)
+#define USE_MMAP 1
+#else
+#define USE_MMAP 0
+#endif
/* precalculate horizontal scaler filter coefficients */
{
--
1.8.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] utils: Do not expand a macro with 'defined' in it
On 8/24/2017 9:02 PM, Derek Buitenhuis wrote: > Fixes: > > libswscale/utils.c:1632:5: warning: macro expansion producing 'defined' > has undefined behavior [-Wexpansion-to-defined] > #if USE_MMAP > ^ > libswscale/utils.c:1577:49: note: expanded from macro 'USE_MMAP' > #define USE_MMAP (HAVE_MMAP && HAVE_MPROTECT && defined MAP_ANONYMOUS) > ^ > Signed-off-by: Derek Buitenhuis > --- > libswscale/utils.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) s#utils#swscale/utils# - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Implement NewTek NDI support
On Wed, 23 Aug 2017, Maksym Veremeyenko wrote: 22.08.2017 23:14, Maksym Veremeyenko пише: [...] One more thing I noticed testing, maybe you can take a look: rgba and rgb0 format is not working (I used the V1 SDK), only audio frames are received, but no apparent error is shown. On the other hand, bgr0 and bgra formats do work. If you can't fix it then rgba and rgb0 formats should be removed from the supported formats. Also please make the docs in sync with the format support changes, I think it now only mentions uyvy422. i think it is related to: + /* Create receiver description */ + recv_create_desc.color_format = NDIlib_recv_color_format_e_UYVY_RGBA; + recv_create_desc.bandwidth = NDIlib_recv_bandwidth_highest; + recv_create_desc.allow_video_fields = ctx->allow_video_fields; i will try to check against v1 and v3 SDK... it is not related to code above. it seems a bug in v1. not working with v1: ffmpeg -loop 1 -r 25 -i /usr/local/src/NDI/NDI.Image.png -vf "format=pix_fmts=bgr0" -f libndi_newtek -y png_bgr0 ffmpeg -loop 1 -r 25 -i /usr/local/src/NDI/NDI.Image.png -vf "format=pix_fmts=bgra" -f libndi_newtek -y png_bgra ffmpeg -f lavfi -i "testsrc=size=1920x1080:rate=25" -vf "format=pix_fmts=rgb0" -f libndi_newtek -y testsrc_rgb0 ffmpeg -f lavfi -i "testsrc=size=1920x1080:rate=25" -vf "format=pix_fmts=rgba" -f libndi_newtek -y testsrc_rgba Ok. If it works in v3, then I guess it is OK to apply as is. Let me know when you want me to do that. Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg options: Enable trailing ? for map_channel
Thanks a lot Martin !!! all sorted out thanks to your kind help.
I had run fate previously but obviously missed something; so re-run and
it's ok.
I created two tests per your advice testing for a third channel in a
stereo file and then in a 2.1 file.
Instead of CRC, I've used MD5 because the extant mapchan fate tests were
using it.
Updated patch in attachment.
Michael: would that be OK or do you see other changes to make ?
From 5c3b0fed39b713b19ed53b5704b1fce63b2742ad Mon Sep 17 00:00:00 2001
From: pkviet
Date: Tue, 22 Aug 2017 11:30:45 +0200
Subject: [PATCH] ffmpeg options: Enable trailing ? for map_channel
The -map option allows for a trailing ? so that an error is not thrown if
the input stream does not exist.
This capability is extended to the map_channel option.
This allows a ffmpeg command not to break if an input channel does not
exist, which can be of use (for instance, scripts processing audio
channels with sources having unset number of audio channels).
---
doc/ffmpeg.texi | 13 -
ffmpeg_opt.c| 21 ++---
tests/fate/ffmpeg.mak | 8
tests/ref/fate/mapchan-2ch-extract-ch0-ch2-trailing | 1 +
tests/ref/fate/mapchan-3ch-extract-ch0-ch2-trailing | 1 +
5 files changed, 40 insertions(+), 4 deletions(-)
create mode 100644 tests/ref/fate/mapchan-2ch-extract-ch0-ch2-trailing
create mode 100644 tests/ref/fate/mapchan-3ch-extract-ch0-ch2-trailing
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 4616a42..de6d3f1 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -996,7 +996,7 @@ such streams is attempted.
Allow input streams with unknown type to be copied instead of failing if
copying
such streams is attempted.
-@item -map_channel
[@var{input_file_id}.@var{stream_specifier}.@var{channel_id}|-1][:@var{output_file_id}.@var{stream_specifier}]
+@item -map_channel
[@var{input_file_id}.@var{stream_specifier}.@var{channel_id}|-1][?][:@var{output_file_id}.@var{stream_specifier}]
Map an audio channel from a given input to an output. If
@var{output_file_id}.@var{stream_specifier} is not set, the audio channel will
be mapped on all the audio streams.
@@ -1005,6 +1005,10 @@ Using "-1" instead of
@var{input_file_id}.@var{stream_specifier}.@var{channel_id} will map a muted
channel.
+A trailing @code{?} will allow the map_channel to be
+optional: if the map_channel matches no channel the map_channel will be
ignored instead
+of failing.
+
For example, assuming @var{INPUT} is a stereo audio file, you can switch the
two audio channels with the following command:
@example
@@ -1052,6 +1056,13 @@ video stream), you can use the following command:
ffmpeg -i input.mkv -filter_complex "[0:1] [0:2] amerge" -c:a pcm_s16le -c:v
copy output.mkv
@end example
+To map the first two audio channels from the first input, and using the
+trailing @code{?}, ignore the audio channel mapping if the first input is
+mono instead of stereo:
+@example
+ffmpeg -i INPUT -map_channel 0.0.0 -map_channel 0.0.1? OUTPUT
+@end example
+
@item -map_metadata[:@var{metadata_spec_out}]
@var{infile}[:@var{metadata_spec_in}] (@emph{output,per-metadata})
Set metadata information of the next output file from @var{infile}. Note that
those are file indices (zero-based), not filenames.
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 1c4a11e..2f6bfc9 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -405,6 +405,11 @@ static int opt_map_channel(void *optctx, const char *opt,
const char *arg)
int n;
AVStream *st;
AudioChannelMap *m;
+char *allow_unused;
+char *mapchan;
+mapchan = av_strdup(arg);
+if (!mapchan)
+return AVERROR(ENOMEM);
GROW_ARRAY(o->audio_channel_maps, o->nb_audio_channel_maps);
m = &o->audio_channel_maps[o->nb_audio_channel_maps - 1];
@@ -450,10 +455,20 @@ static int opt_map_channel(void *optctx, const char *opt,
const char *arg)
m->file_idx, m->stream_idx);
exit_program(1);
}
+/* allow trailing ? to map_channel */
+if (allow_unused = strchr(mapchan, '?'))
+*allow_unused = 0;
if (m->channel_idx < 0 || m->channel_idx >= st->codecpar->channels) {
-av_log(NULL, AV_LOG_FATAL, "mapchan: invalid audio channel
#%d.%d.%d\n",
- m->file_idx, m->stream_idx, m->channel_idx);
-exit_program(1);
+if (allow_unused) {
+av_log(NULL, AV_LOG_VERBOSE, "mapchan: invalid audio channel
#%d.%d.%d\n",
+m->file_idx, m->stream_idx, m->channel_idx);
+} else {
+av_log(NULL, AV_LOG_FATAL, "mapchan: invalid audio channel
#%d.%d.%d\n"
+"To ignore this, add a trailing '?' to the map_channel.\n",
+m->file_idx, m->stream_idx, m->channel_idx);
+exit_program(1);
+}
+
}
return 0;
}
diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
[FFmpeg-devel] [PATCH 4/6] avformat/mvdec: Fix DoS due to lack of eof check
Fixes: loop.mv Found-by: Xiaohei and Wangchu from Alibaba Security Team Signed-off-by: Michael Niedermayer --- libavformat/mvdec.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavformat/mvdec.c b/libavformat/mvdec.c index 0e12c8c6c1..f7aa4cbaec 100644 --- a/libavformat/mvdec.c +++ b/libavformat/mvdec.c @@ -342,6 +342,8 @@ static int mv_read_header(AVFormatContext *avctx) uint32_t pos = avio_rb32(pb); uint32_t asize = avio_rb32(pb); uint32_t vsize = avio_rb32(pb); +if (avio_feof(pb)) +return AVERROR_INVALIDDATA; avio_skip(pb, 8); av_add_index_entry(ast, pos, timestamp, asize, 0, AVINDEX_KEYFRAME); av_add_index_entry(vst, pos + asize, i, vsize, 0, AVINDEX_KEYFRAME); -- 2.14.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/6] avformat/cinedec: Fix DoS due to lack of eof check
From: 孙浩 and 张洪亮(望初)
Fixes: loop.cine
Found-by: Xiaohei and Wangchu from Alibaba Security Team
Signed-off-by: Michael Niedermayer
---
libavformat/cinedec.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavformat/cinedec.c b/libavformat/cinedec.c
index 763b93ba2e..de34fb9638 100644
--- a/libavformat/cinedec.c
+++ b/libavformat/cinedec.c
@@ -267,8 +267,12 @@ static int cine_read_header(AVFormatContext *avctx)
/* parse image offsets */
avio_seek(pb, offImageOffsets, SEEK_SET);
-for (i = 0; i < st->duration; i++)
+for (i = 0; i < st->duration; i++) {
+if (avio_feof(pb))
+return AVERROR_INVALIDDATA;
+
av_add_index_entry(st, avio_rl64(pb), i, 0, 0, AVINDEX_KEYFRAME);
+}
return 0;
}
--
2.14.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/6] avformat/rmdec: Fix DoS due to lack of eof check
From: 孙浩 and 张洪亮(望初)
Fixes: loop.ivr
Found-by: Xiaohei and Wangchu from Alibaba Security Team
Signed-off-by: Michael Niedermayer
---
libavformat/rmdec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
index 178eaea57d..d6d7d9cd84 100644
--- a/libavformat/rmdec.c
+++ b/libavformat/rmdec.c
@@ -1223,8 +1223,11 @@ static int ivr_read_header(AVFormatContext *s)
av_log(s, AV_LOG_DEBUG, "%s = '%s'\n", key, val);
} else if (type == 4) {
av_log(s, AV_LOG_DEBUG, "%s = '0x", key);
-for (j = 0; j < len; j++)
+for (j = 0; j < len; j++) {
+if (avio_feof(pb))
+return AVERROR_INVALIDDATA;
av_log(s, AV_LOG_DEBUG, "%X", avio_r8(pb));
+}
av_log(s, AV_LOG_DEBUG, "'\n");
} else if (len == 4 && type == 3 && !strncmp(key, "StreamCount",
tlen)) {
nb_streams = value = avio_rb32(pb);
--
2.14.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 6/6] avformat/hls: Fix DoS due to infinite loop
Fixes: loop.m3u
The max iteration count of 1 is arbitrary and ideas for a better solution
are welcome
Found-by: Xiaohei and Wangchu from Alibaba Security Team
Signed-off-by: Michael Niedermayer
---
libavformat/hls.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 01731bd36b..26f4ebd965 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -1263,6 +1263,7 @@ static int read_data(void *opaque, uint8_t *buf, int
buf_size)
HLSContext *c = v->parent->priv_data;
int ret, i;
int just_opened = 0;
+int reload_count = 0;
restart:
if (!v->needed)
@@ -1294,6 +1295,9 @@ restart:
reload_interval = default_reload_interval(v);
reload:
+reload_count++;
+if (reload_count > 1)
+return AVERROR_EOF;
if (!v->finished &&
av_gettime_relative() - v->last_load_time >= reload_interval) {
if ((ret = parse_playlist(c, v->url, v, NULL)) < 0) {
--
2.14.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/6] avformat/rl2: Fix DoS due to lack of eof check
From: 孙浩 and 张洪亮(望初)
Fixes: loop.rl2
Found-by: Xiaohei and Wangchu from Alibaba Security Team
Signed-off-by: Michael Niedermayer
---
libavformat/rl2.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/libavformat/rl2.c b/libavformat/rl2.c
index 0bec8f1d9a..eb1682dfcb 100644
--- a/libavformat/rl2.c
+++ b/libavformat/rl2.c
@@ -170,12 +170,21 @@ static av_cold int rl2_read_header(AVFormatContext *s)
}
/** read offset and size tables */
-for(i=0; i < frame_count;i++)
+for(i=0; i < frame_count;i++) {
+if (avio_feof(pb))
+return AVERROR_INVALIDDATA;
chunk_size[i] = avio_rl32(pb);
-for(i=0; i < frame_count;i++)
+}
+for(i=0; i < frame_count;i++) {
+if (avio_feof(pb))
+return AVERROR_INVALIDDATA;
chunk_offset[i] = avio_rl32(pb);
-for(i=0; i < frame_count;i++)
+}
+for(i=0; i < frame_count;i++) {
+if (avio_feof(pb))
+return AVERROR_INVALIDDATA;
audio_size[i] = avio_rl32(pb) & 0x;
+}
/** build the sample index */
for(i=0;ihttp://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/6] avformat/asfdec: Fix DoS due to lack of eof check
From: 孙浩 and 张洪亮(望初)
Fixes: loop.asf
Found-by: Xiaohei and Wangchu from Alibaba Security Team
Signed-off-by: Michael Niedermayer
---
libavformat/asfdec_f.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavformat/asfdec_f.c b/libavformat/asfdec_f.c
index be09a92bd1..00dd5ec41d 100644
--- a/libavformat/asfdec_f.c
+++ b/libavformat/asfdec_f.c
@@ -749,13 +749,20 @@ static int asf_read_marker(AVFormatContext *s, int64_t
size)
count = avio_rl32(pb);// markers count
avio_rl16(pb);// reserved 2 bytes
name_len = avio_rl16(pb); // name length
-for (i = 0; i < name_len; i++)
+for (i = 0; i < name_len; i++) {
+if (avio_feof(pb))
+return AVERROR_INVALIDDATA;
avio_r8(pb); // skip the name
+}
+
for (i = 0; i < count; i++) {
int64_t pres_time;
int name_len;
+if (avio_feof(pb))
+return AVERROR_INVALIDDATA;
+
avio_rl64(pb); // offset, 8 bytes
pres_time = avio_rl64(pb); // presentation time
pres_time -= asf->hdr.preroll * 1;
--
2.14.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Autotools full recompilation
High! I'm using latest ffmpeg from this mirror (https://github.com/FFmpeg) I was building it with different options: ./configure ./configure --libdir=$dev/FFmpeg/libavcodec/ ./configure --enable-shared ./configure --enable-shared --enable-pic And after each time the whole project got recompiled. I guess you cook autotools wrong. (Personally I hate this build system cause it's ugly and slw) After all I still didn't manage to build shared libraries, I had to build 4 files by myself, they needed fPIC option ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] all: avoid data imports across DLL boundaries
On 8/24/17, James Almer wrote: > On 8/24/2017 12:01 PM, wm4 wrote: >> On Thu, 24 Aug 2017 11:20:17 +0200 >> Michael Niedermayer wrote: >> >>> On Thu, Aug 24, 2017 at 10:52:55AM +0200, wm4 wrote: On Wed, 23 Aug 2017 19:23:12 -0300 James Almer wrote: > On 8/21/2017 2:51 PM, wm4 wrote: >> From: Pedro Pombeiro >> >> DLL data imports cause problems on Windows. They normally require >> each variable to be correctly marked with dllimport/dllexport >> declspecs. For MSVC, we define av_export to dllimport declspec. This >> is not entirely correct - depending on which sub-lib is built, they >> should be marked to dllexport instead. It happens to work with MSVC, >> because it supports exports incorrectly marked as imports. Trying to >> use this breaks on MinGW and results in linker errors. >> >> On MinGW, not using any import/export specifiers happens to work, >> because binutils and the MinGW runtime provide "pseudo relocations", >> which manually fix these imports at load time. This does not work with >> MinGW WinRT builds: the relocations cannot be performed because this >> would require writing to the code section, which is not allowed. >> >> Get rid of all these issues by not using data exports/imports. The >> public API is already free of them, but avpriv_ symbols make extensive >> use of them. Replace them all with getters. > > Should be good i think, but it can't be applied as is until the next > major bump as it breaks ABI (Tons of avpriv_ symbols are removed). Well, I call bullshit. We've never taken ABI compatibility between FFmpeg libs seriously, especially not if it was about avpriv functions. >>> >>> We did take ABI compatibility between FFmpeg libs serious. >>> And we must to be shiped by distributions that package the libs based >>> on our ABI versions. >>> >>> And guess what? You didn't either. Commit 7c9d2ad45f4e46ad2c3b2 is authored and committed by you, and changes an avpriv function in an incompatible way, without even minor version bumps. >>> >>> This commit did not break ABI >>> no release contains the removed symbol: >>> >>> git grep avpriv_dca_parse_core_frame_header release/3.3 >>> git grep avpriv_dca_parse_core_frame_header release/3.2 >>> git grep avpriv_dca_parse_core_frame_header release/3.1 >>> git grep avpriv_dca_parse_core_frame_header release/3.0 >>> git grep avpriv_dca_parse_core_frame_header release/2.4 >>> git grep avpriv_dca_parse_core_frame_header release/2.8 >>> >>> The symbol was added 9 days before it was removed, it was in no >>> release >>> >>> commit 7c9d2ad45f4e46ad2c3b2e93051efbe1e0d0529e >>> Author: James Almer >>> Date: Wed Jul 19 01:53:22 2017 -0300 >>> >>> avcodec/dca: remove GetBitContext usage from >>> avpriv_dca_parse_core_frame_header() >>> >>> commit 2123ddb4251bf39bde8b38a1307a0f6154d260e6 >>> Author: foo86 >>> Date: Mon Jul 10 17:11:33 2017 +0300 >>> >>> avcodec: add avpriv_dca_parse_core_frame_header() >>> [...] >> >> We keep ABI stability even within git master, not just within releases. >> Otherwise, our lives would be so much easier whenever ABI problems come >> up. > > Yes, that's why the fix was committed two or three days after the symbol > was introduced, and not weeks after (Ignore the above dates, those are > authoring dates). > > It was in any case a change that could have waited until the major bump. > I hurried to replace it because i thought it was becoming the only > GetBitContext usage in a libavcodec exported function, thus effectively > making it part of the ABI, something that plays against any attempt to > replace it with the new bitstream reader. > Turns out that no, there were other avpriv_ symbols alredy using it, so > a major bump is nonetheless required to fix GetBitContext's ABI > dependency in other existing avpriv_ symbols. Digging the past won't help with the current issues. Can we keep the avpriv_* export of constants, (aka not remove them) but still apply the portion where avpriv_get_*() are used? This should keep the ABI and should not cause problems unless libraries from different builds are mixed. Probably a minor version bump for the getters and major for removing the exports. Since the symbols to constants would no longer be used by the ffmpeg libraries, the mingw linking problem should be solved. Best Regards. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] all: avoid data imports across DLL boundaries
On 8/24/2017 8:26 PM, Ivan Kalvachev wrote: > On 8/24/17, James Almer wrote: >> On 8/24/2017 12:01 PM, wm4 wrote: >>> On Thu, 24 Aug 2017 11:20:17 +0200 >>> Michael Niedermayer wrote: >>> On Thu, Aug 24, 2017 at 10:52:55AM +0200, wm4 wrote: > On Wed, 23 Aug 2017 19:23:12 -0300 > James Almer wrote: > >> On 8/21/2017 2:51 PM, wm4 wrote: >>> From: Pedro Pombeiro >>> >>> DLL data imports cause problems on Windows. They normally require >>> each variable to be correctly marked with dllimport/dllexport >>> declspecs. For MSVC, we define av_export to dllimport declspec. This >>> is not entirely correct - depending on which sub-lib is built, they >>> should be marked to dllexport instead. It happens to work with MSVC, >>> because it supports exports incorrectly marked as imports. Trying to >>> use this breaks on MinGW and results in linker errors. >>> >>> On MinGW, not using any import/export specifiers happens to work, >>> because binutils and the MinGW runtime provide "pseudo relocations", >>> which manually fix these imports at load time. This does not work with >>> MinGW WinRT builds: the relocations cannot be performed because this >>> would require writing to the code section, which is not allowed. >>> >>> Get rid of all these issues by not using data exports/imports. The >>> public API is already free of them, but avpriv_ symbols make extensive >>> use of them. Replace them all with getters. >> >> Should be good i think, but it can't be applied as is until the next >> major bump as it breaks ABI (Tons of avpriv_ symbols are removed). > > Well, I call bullshit. We've never taken ABI compatibility between > FFmpeg libs seriously, especially not if it was about avpriv functions. > We did take ABI compatibility between FFmpeg libs serious. And we must to be shiped by distributions that package the libs based on our ABI versions. > > And guess what? You didn't either. Commit 7c9d2ad45f4e46ad2c3b2 is > authored and committed by you, and changes an avpriv function in an > incompatible way, without even minor version bumps. This commit did not break ABI no release contains the removed symbol: git grep avpriv_dca_parse_core_frame_header release/3.3 git grep avpriv_dca_parse_core_frame_header release/3.2 git grep avpriv_dca_parse_core_frame_header release/3.1 git grep avpriv_dca_parse_core_frame_header release/3.0 git grep avpriv_dca_parse_core_frame_header release/2.4 git grep avpriv_dca_parse_core_frame_header release/2.8 The symbol was added 9 days before it was removed, it was in no release commit 7c9d2ad45f4e46ad2c3b2e93051efbe1e0d0529e Author: James Almer Date: Wed Jul 19 01:53:22 2017 -0300 avcodec/dca: remove GetBitContext usage from avpriv_dca_parse_core_frame_header() commit 2123ddb4251bf39bde8b38a1307a0f6154d260e6 Author: foo86 Date: Mon Jul 10 17:11:33 2017 +0300 avcodec: add avpriv_dca_parse_core_frame_header() [...] >>> >>> We keep ABI stability even within git master, not just within releases. >>> Otherwise, our lives would be so much easier whenever ABI problems come >>> up. >> >> Yes, that's why the fix was committed two or three days after the symbol >> was introduced, and not weeks after (Ignore the above dates, those are >> authoring dates). >> >> It was in any case a change that could have waited until the major bump. >> I hurried to replace it because i thought it was becoming the only >> GetBitContext usage in a libavcodec exported function, thus effectively >> making it part of the ABI, something that plays against any attempt to >> replace it with the new bitstream reader. >> Turns out that no, there were other avpriv_ symbols alredy using it, so >> a major bump is nonetheless required to fix GetBitContext's ABI >> dependency in other existing avpriv_ symbols. > > Digging the past won't help with the current issues. > > Can we keep the avpriv_* export of constants, (aka not remove them) > but still apply the portion where avpriv_get_*() are used? > > This should keep the ABI and should not cause problems > unless libraries from different builds are mixed. > > Probably a minor version bump for the getters > and major for removing the exports. > > Since the symbols to constants would no longer be used > by the ffmpeg libraries, the mingw linking problem should > be solved. > > Best Regards. Martin sent a patchset that deals with wm4's issue in a different way, so this patch might not be necessary after all. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/imgconvert: remove deprecation guards for a function that's not declared as such
Signed-off-by: James Almer
---
The deprecation seems to have been imported from libav but never made effective.
libavcodec/imgconvert.c | 2 --
libavcodec/version.h| 3 ---
2 files changed, 5 deletions(-)
diff --git a/libavcodec/imgconvert.c b/libavcodec/imgconvert.c
index 1547f18966..a349e2a083 100644
--- a/libavcodec/imgconvert.c
+++ b/libavcodec/imgconvert.c
@@ -34,7 +34,6 @@
#include "libavutil/internal.h"
#include "libavutil/imgutils.h"
-#if FF_API_GETCHROMA
void avcodec_get_chroma_sub_sample(enum AVPixelFormat pix_fmt, int *h_shift,
int *v_shift)
{
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
@@ -42,7 +41,6 @@ void avcodec_get_chroma_sub_sample(enum AVPixelFormat
pix_fmt, int *h_shift, int
*h_shift = desc->log2_chroma_w;
*v_shift = desc->log2_chroma_h;
}
-#endif
int avcodec_get_pix_fmt_loss(enum AVPixelFormat dst_pix_fmt,
enum AVPixelFormat src_pix_fmt,
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 7473000579..f41b9caa2d 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -60,9 +60,6 @@
#ifndef FF_API_AVCODEC_RESAMPLE
#define FF_API_AVCODEC_RESAMPLE FF_API_AUDIO_CONVERT
#endif
-#ifndef FF_API_GETCHROMA
-#define FF_API_GETCHROMA (LIBAVCODEC_VERSION_MAJOR < 58)
-#endif
#ifndef FF_API_MISSING_SAMPLE
#define FF_API_MISSING_SAMPLE(LIBAVCODEC_VERSION_MAJOR < 58)
#endif
--
2.13.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Autotools full recompilation
On 8/24/2017 7:19 PM, Yan wrote: High! I'm using latest ffmpeg from this mirror (https://github.com/FFmpeg) I was building it with different options: ./configure ./configure --libdir=$dev/FFmpeg/libavcodec/ ./configure --enable-shared ./configure --enable-shared --enable-pic And after each time the whole project got recompiled. I guess you cook autotools wrong. (Personally I hate this build system cause it's ugly and slw) After all I still didn't manage to build shared libraries, I had to build 4 files by myself, they needed fPIC option A) FFmpeg-devel is the wrong mailing list for bug reports. FFmpeg-user or trac.ffmpeg.org is where those should go. B) FFmpeg doesn't use autotools. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [mov] Bail when invalid sample data is present.
+michael This patch is also necessary now that you've applied the ctts fixes in the previous patch. Thanks. - dale On Fri, Aug 4, 2017 at 4:04 PM, Dale Curtis wrote: > Sample sent privately. I didn't find any non-fuzzer samples that no longer > demux in our Chrome test corpus or in fate. > > - dale > > On Wed, Aug 2, 2017 at 1:43 PM, Carl Eugen Hoyos > wrote: > >> 2017-07-31 23:40 GMT+02:00 Dale Curtis : >> > [mov] Bail when invalid sample data is present. >> >> Could you provide such a sample? >> >> Could the patch stop demuxing samples that are >> supported so far? >> >> Carl Eugen >> ___ >> 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] [mov] Fix trampling of ctts during seeks when sidx support is enabled.
On Thu, Aug 24, 2017 at 2:27 AM, Michael Niedermayer wrote: > > can the insertions be done in groups instead of one at a time ? > so that it basically merges 2 lists (O(n)) instead of inserting > one at a time O(n^2) > ? > This would significantly improve the worst case while not needing > to change the data structures > (of course iam not against changing the data structures if someone wants > to do the work) > Unfortunately this is hard / impossible to do if I understand what you're asking for correctly. Here's my response to the same suggestion from Rodger above: "We could speculatively move all entries based on the first insert and total entries count, but their are several conditionals in av_add_index_entry() which may cause a bail out and such failure would be unrecoverable (maybe painfully?) if we moved everything ahead of time." - dale ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/6] avformat/hls: Fix DoS due to infinite loop
2017-08-25 7:15 GMT+08:00 Michael Niedermayer :
> Fixes: loop.m3u
>
> The max iteration count of 1 is arbitrary and ideas for a better solution
> are welcome
Why not give a option to user for set the reload_count and limit from 1 - 1?
>
> Found-by: Xiaohei and Wangchu from Alibaba Security Team
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/hls.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 01731bd36b..26f4ebd965 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -1263,6 +1263,7 @@ static int read_data(void *opaque, uint8_t *buf, int
> buf_size)
> HLSContext *c = v->parent->priv_data;
> int ret, i;
> int just_opened = 0;
> +int reload_count = 0;
>
> restart:
> if (!v->needed)
> @@ -1294,6 +1295,9 @@ restart:
> reload_interval = default_reload_interval(v);
>
> reload:
> +reload_count++;
> +if (reload_count > 1)
> +return AVERROR_EOF;
> if (!v->finished &&
> av_gettime_relative() - v->last_load_time >= reload_interval) {
> if ((ret = parse_playlist(c, v->url, v, NULL)) < 0) {
> --
> 2.14.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] [PATCH] utils: Do not expand a macro with 'defined' in it
On Thu, Aug 24, 2017 at 09:02:33PM +0100, Derek Buitenhuis wrote: > Fixes: > > libswscale/utils.c:1632:5: warning: macro expansion producing 'defined' > has undefined behavior [-Wexpansion-to-defined] > #if USE_MMAP > ^ > libswscale/utils.c:1577:49: note: expanded from macro 'USE_MMAP' > #define USE_MMAP (HAVE_MMAP && HAVE_MPROTECT && defined MAP_ANONYMOUS) > ^ > Signed-off-by: Derek Buitenhuis > --- > libswscale/utils.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) should be ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] all: avoid data imports across DLL boundaries
On 8/25/17, James Almer wrote: > On 8/24/2017 8:26 PM, Ivan Kalvachev wrote: >> On 8/24/17, James Almer wrote: >>> On 8/24/2017 12:01 PM, wm4 wrote: On Thu, 24 Aug 2017 11:20:17 +0200 Michael Niedermayer wrote: > On Thu, Aug 24, 2017 at 10:52:55AM +0200, wm4 wrote: >> On Wed, 23 Aug 2017 19:23:12 -0300 >> James Almer wrote: >> >>> On 8/21/2017 2:51 PM, wm4 wrote: From: Pedro Pombeiro DLL data imports cause problems on Windows. They normally require each variable to be correctly marked with dllimport/dllexport declspecs. For MSVC, we define av_export to dllimport declspec. This is not entirely correct - depending on which sub-lib is built, they should be marked to dllexport instead. It happens to work with MSVC, because it supports exports incorrectly marked as imports. Trying to use this breaks on MinGW and results in linker errors. On MinGW, not using any import/export specifiers happens to work, because binutils and the MinGW runtime provide "pseudo relocations", which manually fix these imports at load time. This does not work with MinGW WinRT builds: the relocations cannot be performed because this would require writing to the code section, which is not allowed. Get rid of all these issues by not using data exports/imports. The public API is already free of them, but avpriv_ symbols make extensive use of them. Replace them all with getters. >>> >>> Should be good i think, but it can't be applied as is until the next >>> major bump as it breaks ABI (Tons of avpriv_ symbols are removed). >> >> Well, I call bullshit. We've never taken ABI compatibility between >> FFmpeg libs seriously, especially not if it was about avpriv >> functions. >> > > We did take ABI compatibility between FFmpeg libs serious. > And we must to be shiped by distributions that package the libs based > on our ABI versions. > > >> >> And guess what? You didn't either. Commit 7c9d2ad45f4e46ad2c3b2 is >> authored and committed by you, and changes an avpriv function in an >> incompatible way, without even minor version bumps. > > This commit did not break ABI > no release contains the removed symbol: > > git grep avpriv_dca_parse_core_frame_header release/3.3 > git grep avpriv_dca_parse_core_frame_header release/3.2 > git grep avpriv_dca_parse_core_frame_header release/3.1 > git grep avpriv_dca_parse_core_frame_header release/3.0 > git grep avpriv_dca_parse_core_frame_header release/2.4 > git grep avpriv_dca_parse_core_frame_header release/2.8 > > The symbol was added 9 days before it was removed, it was in no > release > > commit 7c9d2ad45f4e46ad2c3b2e93051efbe1e0d0529e > Author: James Almer > Date: Wed Jul 19 01:53:22 2017 -0300 > > avcodec/dca: remove GetBitContext usage from > avpriv_dca_parse_core_frame_header() > > commit 2123ddb4251bf39bde8b38a1307a0f6154d260e6 > Author: foo86 > Date: Mon Jul 10 17:11:33 2017 +0300 > > avcodec: add avpriv_dca_parse_core_frame_header() > [...] We keep ABI stability even within git master, not just within releases. Otherwise, our lives would be so much easier whenever ABI problems come up. >>> >>> Yes, that's why the fix was committed two or three days after the symbol >>> was introduced, and not weeks after (Ignore the above dates, those are >>> authoring dates). >>> >>> It was in any case a change that could have waited until the major bump. >>> I hurried to replace it because i thought it was becoming the only >>> GetBitContext usage in a libavcodec exported function, thus effectively >>> making it part of the ABI, something that plays against any attempt to >>> replace it with the new bitstream reader. >>> Turns out that no, there were other avpriv_ symbols alredy using it, so >>> a major bump is nonetheless required to fix GetBitContext's ABI >>> dependency in other existing avpriv_ symbols. >> >> Digging the past won't help with the current issues. >> >> Can we keep the avpriv_* export of constants, (aka not remove them) >> but still apply the portion where avpriv_get_*() are used? >> >> This should keep the ABI and should not cause problems >> unless libraries from different builds are mixed. >> >> Probably a minor version bump for the getters >> and major for removing the exports. >> >> Since the symbols to constants would no longer be used >> by the ffmpeg libraries, the mingw linking problem should >> be solved. >> >> Best Regards. > > Martin sent a patchset that deals with wm4's issue in a different way, > so this patch might not be necessary after all. I don't see it on the maillist. ___ ffmpeg-devel ma
Re: [FFmpeg-devel] [PATCH v2] mjpeg: Add support for ICC side data
On Thu, Aug 24, 2017 at 02:33:33PM +0100, Derek Buitenhuis wrote: > JPEGs store embedded profiles under the APP2 marker, signified > with a "ICC_PROFILE" null-terminated string header, and can be > split across multiple APP2 markers, out of order. > > Signed-off-by: Derek Buitenhuis > --- > libavcodec/mjpegdec.c | 104 > ++ > libavcodec/mjpegdec.h | 5 +++ > 2 files changed, 109 insertions(+) should be ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] all: avoid data imports across DLL boundaries
On 8/24/2017 9:36 PM, Ivan Kalvachev wrote: > On 8/25/17, James Almer wrote: >> On 8/24/2017 8:26 PM, Ivan Kalvachev wrote: >>> On 8/24/17, James Almer wrote: On 8/24/2017 12:01 PM, wm4 wrote: > On Thu, 24 Aug 2017 11:20:17 +0200 > Michael Niedermayer wrote: > >> On Thu, Aug 24, 2017 at 10:52:55AM +0200, wm4 wrote: >>> On Wed, 23 Aug 2017 19:23:12 -0300 >>> James Almer wrote: >>> On 8/21/2017 2:51 PM, wm4 wrote: > From: Pedro Pombeiro > > DLL data imports cause problems on Windows. They normally require > each variable to be correctly marked with dllimport/dllexport > declspecs. For MSVC, we define av_export to dllimport declspec. This > is not entirely correct - depending on which sub-lib is built, they > should be marked to dllexport instead. It happens to work with MSVC, > because it supports exports incorrectly marked as imports. Trying to > use this breaks on MinGW and results in linker errors. > > On MinGW, not using any import/export specifiers happens to work, > because binutils and the MinGW runtime provide "pseudo relocations", > which manually fix these imports at load time. This does not work > with > MinGW WinRT builds: the relocations cannot be performed because this > would require writing to the code section, which is not allowed. > > Get rid of all these issues by not using data exports/imports. The > public API is already free of them, but avpriv_ symbols make > extensive > use of them. Replace them all with getters. Should be good i think, but it can't be applied as is until the next major bump as it breaks ABI (Tons of avpriv_ symbols are removed). >>> >>> Well, I call bullshit. We've never taken ABI compatibility between >>> FFmpeg libs seriously, especially not if it was about avpriv >>> functions. >>> >> >> We did take ABI compatibility between FFmpeg libs serious. >> And we must to be shiped by distributions that package the libs based >> on our ABI versions. >> >> >>> >>> And guess what? You didn't either. Commit 7c9d2ad45f4e46ad2c3b2 is >>> authored and committed by you, and changes an avpriv function in an >>> incompatible way, without even minor version bumps. >> >> This commit did not break ABI >> no release contains the removed symbol: >> >> git grep avpriv_dca_parse_core_frame_header release/3.3 >> git grep avpriv_dca_parse_core_frame_header release/3.2 >> git grep avpriv_dca_parse_core_frame_header release/3.1 >> git grep avpriv_dca_parse_core_frame_header release/3.0 >> git grep avpriv_dca_parse_core_frame_header release/2.4 >> git grep avpriv_dca_parse_core_frame_header release/2.8 >> >> The symbol was added 9 days before it was removed, it was in no >> release >> >> commit 7c9d2ad45f4e46ad2c3b2e93051efbe1e0d0529e >> Author: James Almer >> Date: Wed Jul 19 01:53:22 2017 -0300 >> >> avcodec/dca: remove GetBitContext usage from >> avpriv_dca_parse_core_frame_header() >> >> commit 2123ddb4251bf39bde8b38a1307a0f6154d260e6 >> Author: foo86 >> Date: Mon Jul 10 17:11:33 2017 +0300 >> >> avcodec: add avpriv_dca_parse_core_frame_header() >> [...] > > We keep ABI stability even within git master, not just within releases. > Otherwise, our lives would be so much easier whenever ABI problems come > up. Yes, that's why the fix was committed two or three days after the symbol was introduced, and not weeks after (Ignore the above dates, those are authoring dates). It was in any case a change that could have waited until the major bump. I hurried to replace it because i thought it was becoming the only GetBitContext usage in a libavcodec exported function, thus effectively making it part of the ABI, something that plays against any attempt to replace it with the new bitstream reader. Turns out that no, there were other avpriv_ symbols alredy using it, so a major bump is nonetheless required to fix GetBitContext's ABI dependency in other existing avpriv_ symbols. >>> >>> Digging the past won't help with the current issues. >>> >>> Can we keep the avpriv_* export of constants, (aka not remove them) >>> but still apply the portion where avpriv_get_*() are used? >>> >>> This should keep the ABI and should not cause problems >>> unless libraries from different builds are mixed. >>> >>> Probably a minor version bump for the getters >>> and major for removing the exports. >>> >>> Since the symbols to constants would no longer be used >>> by the ffmpeg libraries, the mingw linking problem should >>> be solved. >>> >>> Best Regards. >> >> Martin sent a patchset that deals with wm4's issue in a di
Re: [FFmpeg-devel] [PATCH] avfilter/af_firequalizer: add min_phase option
On Wed, Aug 23, 2017 at 1:38 AM, Muhammad Faiz wrote: > Signed-off-by: Muhammad Faiz > --- > doc/filters.texi | 3 + > libavfilter/af_firequalizer.c | 147 > +- > 2 files changed, 147 insertions(+), 3 deletions(-) Applied Thank's ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Implement NewTek NDI support
25.08.2017 0:17, Marton Balint пише: [...] Ok. If it works in v3, then I guess it is OK to apply as is. Let me know when you want me to do that. please apply -- Maksym Veremeyenko ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/imgconvert: remove deprecation guards for a function that's not declared as such
On 8/25/17, James Almer wrote: > Signed-off-by: James Almer > --- > The deprecation seems to have been imported from libav but never made > effective. > > libavcodec/imgconvert.c | 2 -- > libavcodec/version.h| 3 --- > 2 files changed, 5 deletions(-) > OK ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
