Re: [FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway
ons 2022-08-24 klockan 22:54 +0200 skrev Michael Niedermayer: > On Wed, Aug 24, 2022 at 06:35:04PM +0200, Tomas Härdin wrote: > > But for some reason the notion > > that the same applies to *all* parsers, including decoders and > > demuxers, this notion is hard to swallow. And similarly for > > encoders > > and muxers. I have yet to see a justification that is anything but > > cargo culting. > > Its not hard to swallow, it simply is wrong. > Why is there Tesla ? > to build cars ? > no > "Tesla’s mission is to accelerate the world’s transition to > sustainable energy." Tesla's mission is to generate profit, nothing else. > they could outsource everything, from chip design to batteries to > software to > the car seats and so on but they dont because its better to reach > their goal > to do them internally This has everything to do with economics of scale and ultimately economizing on labour, thus lowering the value of Tesla's lithium-ion cells and increasing profit. For software the situation is very different, because the cost of reproducing a program is effectively zero. All labour goes into development. The goal of FFmpeg like every free software project is to create use-values. Any labour spent in excess of what is necessary to say be able to play MXF files is simply make-work. I'm not sure what the bit about censorship has to do with my point. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway
ons 2022-08-24 klockan 23:03 +0200 skrev Michael Niedermayer: > On Wed, Aug 24, 2022 at 06:35:04PM +0200, Tomas Härdin wrote: > [...] > > > > This goes especially for formats like MXF, which I have made the > > case > > on here multiple times that we should not maintain our own decoder > > for, > > but rather pull in bmx. And everytime I have suggested this it has > > been > > made clear that such patches would be rejected. And so MXF > > developer > > effort is split. > > Is there a need for mxf (de) muxing without other containers ? > If the awnser is (mostly) no then the problem is not FFmpeg wanting > its > own but rather that someone maintains mxf code outside ffmpeg. I think you missed my point about subtree merges > > Code is a liability. We should seek to have as little of it as > > possible. > > Look back at tesla, "vertical integration is a liability", that > sounds > wrong. Quite the opposit, companies that split everything out seem to > do > significantly worse. This again has to do with things like economics of scale. When it comes to inter-company exchange, profit acts as a fetter on productivity. Tesla has to pay not just the cost of Samsung's 18650 cells but also Samsung's profit. These are two reasons why vertical integration can make sense. If Tesla could copy Samsung's 18650 production line, Samsung's capital, literally for free then they would have done so from day one. This is what free software is - a kind of commons capital that can be copied gratis. > It doesnt mean everything should be done internally > but simply because some external work exists doesnt mean we need to > use it > and then have to maybe maintain a codebase that we do not know and > that > noone is willing to maintain and that noone from FFmpeg even has > write > access to. Obviously we wouldn't pull in things we have zero access to. We could for example subtree merge specific releases, and set up the build system so that we can either use that or an equivalent shared system version. One limitation of this approach is that new features in say bmx can't be merged immediately but has to wait for the next official release of bmx. But this can be handled by having a branch where changes in our codebase that depend on changes in bmx coexist, and on bmx's next release they are merged into master. Pressure could be applied from our end on bmx to release early if the feature is a pressing one. > Next some platforms may carry old versions of that external > code, some might not carry it at all. Good thing we could build those dependencies ourselves then, if we set up the build system correctly. > Also we have regression tests, external libs make that impossible > as the version of external libs can change the behavior. Again this > is a issue for mxf maybe less so libxml. You can also see that we > have no > tests involving any of the external encoder libs, for that very > reason. > With each external lib that is needed for core features this would > become a quickly growing problem Testing is certainly a challenge, but almost certainly easier than reimplementing certain formats and codecs poorly, especially MXF. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway
On Sat, Aug 27, 2022 at 9:30 AM Tomas Härdin wrote: > ons 2022-08-24 klockan 23:03 +0200 skrev Michael Niedermayer: > > On Wed, Aug 24, 2022 at 06:35:04PM +0200, Tomas Härdin wrote: > > [...] > > > > > > This goes especially for formats like MXF, which I have made the > > > case > > > on here multiple times that we should not maintain our own decoder > > > for, > > > but rather pull in bmx. And everytime I have suggested this it has > > > been > > > made clear that such patches would be rejected. And so MXF > > > developer > > > effort is split. > > > > Is there a need for mxf (de) muxing without other containers ? > > If the awnser is (mostly) no then the problem is not FFmpeg wanting > > its > > own but rather that someone maintains mxf code outside ffmpeg. > > I think you missed my point about subtree merges > > > > Code is a liability. We should seek to have as little of it as > > > possible. > > > > Look back at tesla, "vertical integration is a liability", that > > sounds > > wrong. Quite the opposit, companies that split everything out seem to > > do > > significantly worse. > > This again has to do with things like economics of scale. When it comes > to inter-company exchange, profit acts as a fetter on productivity. > Tesla has to pay not just the cost of Samsung's 18650 cells but also > Samsung's profit. These are two reasons why vertical integration can > make sense. > > If Tesla could copy Samsung's 18650 production line, Samsung's capital, > literally for free then they would have done so from day one. This is > what free software is - a kind of commons capital that can be copied > gratis. > > > It doesnt mean everything should be done internally > > but simply because some external work exists doesnt mean we need to > > use it > > and then have to maybe maintain a codebase that we do not know and > > that > > noone is willing to maintain and that noone from FFmpeg even has > > write > > access to. > > Obviously we wouldn't pull in things we have zero access to. We could > for example subtree merge specific releases, and set up the build > system so that we can either use that or an equivalent shared system > version. One limitation of this approach is that new features in say > bmx can't be merged immediately but has to wait for the next official > release of bmx. But this can be handled by having a branch where > changes in our codebase that depend on changes in bmx coexist, and on > bmx's next release they are merged into master. Pressure could be > applied from our end on bmx to release early if the feature is a > pressing one. > > > Next some platforms may carry old versions of that external > > code, some might not carry it at all. > > Good thing we could build those dependencies ourselves then, if we set > up the build system correctly. > > > Also we have regression tests, external libs make that impossible > > as the version of external libs can change the behavior. Again this > > is a issue for mxf maybe less so libxml. You can also see that we > > have no > > tests involving any of the external encoder libs, for that very > > reason. > > With each external lib that is needed for core features this would > > become a quickly growing problem > > Testing is certainly a challenge, but almost certainly easier than > reimplementing certain formats and codecs poorly, especially MXF. > > Than why you are so called maintainer of thing you do not want to maintain? Looks like some relatively "new" devs are completely failing to see the point of FFmpeg. And they are extremely ignorant of reality they live in all together. If for whatever reason you do not want/like some code in FFmpeg then just leave. > /Tomas > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] External Library Dependencies and Testability
Hi, I don’t want to get involved in the ipfsgateway discussion, but the part about external library version dependencies and testability reminded me of some recent thoughts: I wonder whether it wouldn’t make sense to maintain a version reference for external libraries in a way that at any point in (repo) time there’s a clearly defined set of dependency library versions. This could provide a number of benefits, like: - enable testability where external libs are involved - improve reproducibility of issues with external libs - serve as an orientation for library versions to use for static builds - possibly more It could still be purely informational but provide a defined reference point for dependency library versions whenever needed or useful. The configure script could get an option like 'strict_references' option would cause it to error out when it doesn't find the exact versions of libs. Another use case for this would be for ensuring reproducibility of (static) builds. softworkz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] External Library Dependencies and Testability
On Sat, Aug 27, 2022 at 11:30 AM Soft Works wrote: > Hi, > > I don’t want to get involved in the ipfsgateway discussion, but the part > about > external library version dependencies and testability reminded me of some > recent thoughts: I wonder whether it wouldn’t make sense to maintain a > version > reference for external libraries in a way that at any point in (repo) time > there’s a clearly defined set of dependency library versions. > This could provide a number of benefits, like: > > - enable testability where external libs are involved > - improve reproducibility of issues with external libs > - serve as an orientation for library versions to use > for static builds > - possibly more > > It could still be purely informational but provide a defined reference > point for dependency library versions whenever needed or useful. > > The configure script could get an option like 'strict_references' option > would cause it to error out when it doesn't find the exact versions of > libs. > > Another use case for this would be for ensuring reproducibility of > (static) builds. Its all nice, but there is severe lack of resources to do testing. > > > softworkz > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway
lör 2022-08-27 klockan 09:53 +0200 skrev Paul B Mahol: > On Sat, Aug 27, 2022 at 9:30 AM Tomas Härdin > wrote: > > > ons 2022-08-24 klockan 23:03 +0200 skrev Michael Niedermayer: > > > Also we have regression tests, external libs make that impossible > > > as the version of external libs can change the behavior. Again > > > this > > > is a issue for mxf maybe less so libxml. You can also see that we > > > have no > > > tests involving any of the external encoder libs, for that very > > > reason. > > > With each external lib that is needed for core features this > > > would > > > become a quickly growing problem > > > > Testing is certainly a challenge, but almost certainly easier than > > reimplementing certain formats and codecs poorly, especially MXF. > > > > > Than why you are so called maintainer of thing you do not want to > maintain? Me maintaining mxfdec is precisely why I want to switch to bmx > Looks like some relatively "new" devs are completely failing to see > the > point of FFmpeg. I've been here longer than you /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 12/21] avcodec/roqvideoenc: Remove internal.h inclusion
Andreas Rheinhardt: > Possible since c954cf1e1b766a0d1992d5be0a8be0055a8e1a6a. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/roqvideoenc.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/libavcodec/roqvideoenc.c b/libavcodec/roqvideoenc.c > index 0a418c3b89..9f03107d81 100644 > --- a/libavcodec/roqvideoenc.c > +++ b/libavcodec/roqvideoenc.c > @@ -64,7 +64,6 @@ > #include "codec_internal.h" > #include "elbg.h" > #include "encode.h" > -#include "internal.h" > #include "mathops.h" > > #define CHROMA_BIAS 1 Will apply the rest of this patchset tomorrow. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Discrepancy between comments for AVX512 flags
> On Sat, Aug 27, 2022 at 12:04 AM James Darnley wrote: > I think the feature selection is fine as-is, if you want to clarify > the comments go ahead. AVX512 wouldn't be useful with a subset even > smaller then what the plain AVX512 is looking for (there is also no > CPUs with any smaller set, afaik), and most would even agree that the > ICL set is the minimum they would be developing for. To elaborate a bit further, the base AVX512 set is what Skylake supports, and AVX51ICL is what Ice Lake supports. As far as I know, Zen 4 will also support all the instructions Ice Lake supports, so that should cover most systems. We don't really care about Xeon Phi, so the Skylake subset is the de facto minimum baseline. This was done to get more manageable subsets that groups together useful instructions in a way that maps reasonably well to real-world hardware, in order to avoid having to deal with a dozen different permutations. There exists hardware which have instruction sets that fall outside those two subsets, e.g. some Xeon Skylake-derivatives also has VNNI in addition to the base Skylake subset and Tiger Lake has VP2INTERSECT, but all things considered I consider the current design to be the best compromise. I'm sure Intel and AMD will add more instruction sets over time, so we'll probably add new subsets in the future if/when there's a need for it. Henrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat/imfdec: check track valid before use it
Pierre-Anthony Lemieux 于2022年8月27日周六 00:06写道： > > On Fri, Aug 26, 2022 at 9:01 AM Andreas Rheinhardt > wrote: > > > > Pierre-Anthony Lemieux: > > > On Fri, Aug 26, 2022 at 1:37 AM Andreas Rheinhardt > > > wrote: > > >> > > >> Steven Liu: > > >>> fix CID: 1512414 > > >>> And return AVERROR_INVALIDDATA when > > >>> get_next_track_with_minimum_timestamp > > >>> incorrect in imf_read_packet; > > >>> > > >>> Signed-off-by: Steven Liu > > >>> --- > > >>> libavformat/imfdec.c | 7 +-- > > >>> 1 file changed, 5 insertions(+), 2 deletions(-) > > >>> > > >>> diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c > > >>> index 5bbe7a53f8..08f342bc1a 100644 > > >>> --- a/libavformat/imfdec.c > > >>> +++ b/libavformat/imfdec.c > > >>> @@ -697,8 +697,9 @@ static IMFVirtualTrackPlaybackCtx > > >>> *get_next_track_with_minimum_timestamp(AVForma > > >>> } > > >>> } > > >>> > > >>> -av_log(s, AV_LOG_DEBUG, "Found next track to read: %d (timestamp: > > >>> %lf / %lf)\n", > > >>> - track->index, av_q2d(track->current_timestamp), > > >>> av_q2d(minimum_timestamp)); > > >>> +if (track) > > >>> +av_log(s, AV_LOG_DEBUG, "Found next track to read: %d > > >>> (timestamp: %lf / %lf)\n", > > >>> + track->index, av_q2d(track->current_timestamp), > > >>> av_q2d(minimum_timestamp)); > > >> > > >> Coverity actually complained about track being uninitialized, which this > > >> patch does not address. And the reason it does this is that it doesn't > > >> understand the algorithm: track will always be initialized in the first > > >> iteration of the loop. > > > > > > Is it possible to tell coverity that c->track_count > 0 is a > > > pre-condition, or should we modify the loop/algorithm? > > > > > > > The typical way to do this is to add an av_assert1 or av_assert2; > > but this must only be done if it is indeed ensured that the assert will > > not be triggered. > > > > >> (If there is a first iteration of the loop -- is > > >> this actually guaranteed? A file without tracks seems to be pretty > > >> useless.) > > > > > > imfdec currently assumes that (a) imf_read_packet() is not called if > > > there are no streams/tracks and (b) a track will always be found. > > > > > > (b) will be true for a conformant IMF Composition, but I am not sure > > > it can always be true for a malformed one. > > > > > > > Can't we make it true by adding the relevant checks to read_header? > > Yes. Can imf add or remove track when processing? Looks like the live streaming change resolution or bitrate when playing. > > > > > > I think imf_read_packet() can probably be hardened. Perhaps do this as > > > a patch separately from addressing the coverity issue? > > > > > >> FYI: In Coverity's analysis there are loop iterations, but it just > > >> assumed that track is not initialized in the loop (which boils down to > > >> saying that it presumed the tracks' current_timestamp to be invalid > > >> (denominator 0). I hope this can't happen. > > >> (There is btw another issue: The initialization of minimum_timestamp > > >> presumes that int are 32bit which need not be true.) > > > > > > INT32_MAX -> INT_MAX should fix this right? > > > > > > > Yes. > > > > >> > > >>> return track; > > >>> } > > >>> > > >>> @@ -760,6 +761,8 @@ static int imf_read_packet(AVFormatContext *s, > > >>> AVPacket *pkt) > > >>> AVRational next_timestamp; > > >>> > > >>> track = get_next_track_with_minimum_timestamp(s); > > >>> +if (!track) > > >>> +return AVERROR_INVALIDDATA; > > >>> > > >>> ret = get_resource_context_for_timestamp(s, track, &resource); > > >>> if (ret) > > >> > > >> ___ > > >> ffmpeg-devel mailing list > > >> ffmpeg-devel@ffmpeg.org > > >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > >> > > >> To unsubscribe, visit link above, or email > > >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > > ___ > > > ffmpeg-devel mailing list > > > ffmpeg-devel@ffmpeg.org > > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > To unsubscribe, visit link above, or email > > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-d
[FFmpeg-devel] [PATCH 1/3] fftools/cmdutils: Add function to report error before exit
This is designed to improve and unify error handling for
allocation failures for the many (often small) allocations that we have
in the fftools. These typically either don't return an error message
or an error message that is not really helpful to the user
and can be replaced by a generic error message without loss of
information.
Signed-off-by: Andreas Rheinhardt
---
fftools/cmdutils.c | 6 ++
fftools/cmdutils.h | 11 +++
2 files changed, 17 insertions(+)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 18e768b386..b6f5c01ca3 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -90,6 +90,12 @@ void register_exit(void (*cb)(int ret))
program_exit = cb;
}
+void report_error_then_exit_program(int ret)
+{
+av_log(NULL, AV_LOG_FATAL, "%s\n", av_err2str(ret));
+exit_program(AVUNERROR(ret));
+}
+
void exit_program(int ret)
{
if (program_exit)
diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
index d87e162ccd..358f0a0ef9 100644
--- a/fftools/cmdutils.h
+++ b/fftools/cmdutils.h
@@ -54,6 +54,17 @@ extern int hide_banner;
*/
void register_exit(void (*cb)(int ret));
+/**
+ * Reports an error corresponding to the provided
+ * AVERROR code and calls exit_program() with the
+ * corresponding POSIX error code.
+ * @note ret must be an AVERROR-value of a POSIX error code
+ * (i.e. AVERROR(EFOO) and not AVERROR_FOO).
+ * library functions can return both, so call this only
+ * with AVERROR(EFOO) of your own.
+ */
+void report_error_then_exit_program(int ret) av_noreturn;
+
/**
* Wraps exit with a program-specific cleanup routine.
*/
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] fftools: Use report_error_then_exit_program() for allocation failures
Signed-off-by: Andreas Rheinhardt
---
fftools/cmdutils.c | 21 +
fftools/ffmpeg.c| 25 ++-
fftools/ffmpeg_filter.c | 10 +++---
fftools/ffmpeg_opt.c| 70 -
fftools/ffprobe.c | 6 ++--
fftools/opt_common.c| 6 ++--
6 files changed, 52 insertions(+), 86 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index b6f5c01ca3..47568dcebc 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -656,7 +656,7 @@ static void init_parse_context(OptionParseContext *octx,
octx->nb_groups = nb_groups;
octx->groups= av_calloc(octx->nb_groups, sizeof(*octx->groups));
if (!octx->groups)
-exit_program(1);
+report_error_then_exit_program(AVERROR(ENOMEM));
for (i = 0; i < octx->nb_groups; i++)
octx->groups[i].group_def = &groups[i];
@@ -964,11 +964,8 @@ AVDictionary **setup_find_stream_info_opts(AVFormatContext
*s,
if (!s->nb_streams)
return NULL;
opts = av_calloc(s->nb_streams, sizeof(*opts));
-if (!opts) {
-av_log(NULL, AV_LOG_ERROR,
- "Could not alloc memory for stream options.\n");
-exit_program(1);
-}
+if (!opts)
+report_error_then_exit_program(AVERROR(ENOMEM));
for (i = 0; i < s->nb_streams; i++)
opts[i] = filter_codec_opts(codec_opts,
s->streams[i]->codecpar->codec_id,
s, s->streams[i], NULL);
@@ -983,10 +980,8 @@ void *grow_array(void *array, int elem_size, int *size,
int new_size)
}
if (*size < new_size) {
uint8_t *tmp = av_realloc_array(array, new_size, elem_size);
-if (!tmp) {
-av_log(NULL, AV_LOG_ERROR, "Could not alloc buffer.\n");
-exit_program(1);
-}
+if (!tmp)
+report_error_then_exit_program(AVERROR(ENOMEM));
memset(tmp + *size*elem_size, 0, (new_size-*size) * elem_size);
*size = new_size;
return tmp;
@@ -999,10 +994,8 @@ void *allocate_array_elem(void *ptr, size_t elem_size, int
*nb_elems)
void *new_elem;
if (!(new_elem = av_mallocz(elem_size)) ||
-av_dynarray_add_nofree(ptr, nb_elems, new_elem) < 0) {
-av_log(NULL, AV_LOG_ERROR, "Could not alloc buffer.\n");
-exit_program(1);
-}
+av_dynarray_add_nofree(ptr, nb_elems, new_elem) < 0)
+report_error_then_exit_program(AVERROR(ENOMEM));
return new_elem;
}
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index ef7177fc33..18b91e3ef6 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1094,10 +1094,8 @@ static void do_subtitle_out(OutputFile *of,
return;
ret = av_new_packet(pkt, subtitle_out_max_size);
-if (ret < 0) {
-av_log(NULL, AV_LOG_FATAL, "Failed to allocate subtitle encode
buffer\n");
-exit_program(1);
-}
+if (ret < 0)
+report_error_then_exit_program(AVERROR(ENOMEM));
sub->pts = pts;
// start_display_time is required to be 0
@@ -2345,7 +2343,7 @@ static int transcode_subtitles(InputStream *ist, AVPacket
*pkt, int *got_output,
if (!ist->sub2video.sub_queue)
ist->sub2video.sub_queue = av_fifo_alloc2(8, sizeof(AVSubtitle),
AV_FIFO_FLAG_AUTO_GROW);
if (!ist->sub2video.sub_queue)
-exit_program(1);
+report_error_then_exit_program(AVERROR(ENOMEM));
ret = av_fifo_write(ist->sub2video.sub_queue, &subtitle, 1);
if (ret < 0)
@@ -2874,7 +2872,7 @@ static void set_encoder_id(OutputFile *of, OutputStream
*ost)
encoder_string_len = sizeof(LIBAVCODEC_IDENT) + strlen(ost->enc->name) + 2;
encoder_string = av_mallocz(encoder_string_len);
if (!encoder_string)
-exit_program(1);
+report_error_then_exit_program(AVERROR(ENOMEM));
if (!of->bitexact && !ost->bitexact)
av_strlcpy(encoder_string, LIBAVCODEC_IDENT " ", encoder_string_len);
@@ -2897,10 +2895,8 @@ static void parse_forced_key_frames(char *kf,
OutputStream *ost,
n++;
size = n;
pts = av_malloc_array(size, sizeof(*pts));
-if (!pts) {
-av_log(NULL, AV_LOG_FATAL, "Could not allocate forced key frames
array.\n");
-exit_program(1);
-}
+if (!pts)
+report_error_then_exit_program(AVERROR(ENOMEM));
p = kf;
for (i = 0; i < n; i++) {
@@ -2919,11 +2915,8 @@ static void parse_forced_key_frames(char *kf,
OutputStream *ost,
if (nb_ch > INT_MAX - size ||
!(pts = av_realloc_f(pts, size += nb_ch - 1,
- sizeof(*pts {
-av_log(NULL, AV_LOG_FATAL,
- "Could not allocate forced key frames array.\n");
-exit_program(1);
-}
+ sizeof(*pts
+report_error_then_exit_program(AVERROR(ENOMEM));
t =
[FFmpeg-devel] [PATCH 3/3] fftools/ffmpeg_opt: Check creation of new program
Fixes Coverity issue #1512413.
Signed-off-by: Andreas Rheinhardt
---
fftools/ffmpeg_opt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index b0b8ecc868..74427cf80d 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -2753,6 +2753,8 @@ static void of_add_programs(AVFormatContext *oc, const
OptionsContext *o)
}
program = av_new_program(oc, progid);
+if (!program)
+report_error_then_exit_program(AVERROR(ENOMEM));
p = o->program[i].u.str;
while(*p) {
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] fftools/cmdutils: Add function to report error before exit
On 8/27/2022 10:55 AM, Andreas Rheinhardt wrote:
This is designed to improve and unify error handling for
allocation failures for the many (often small) allocations that we have
in the fftools. These typically either don't return an error message
or an error message that is not really helpful to the user
and can be replaced by a generic error message without loss of
information.
Signed-off-by: Andreas Rheinhardt
---
fftools/cmdutils.c | 6 ++
fftools/cmdutils.h | 11 +++
2 files changed, 17 insertions(+)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 18e768b386..b6f5c01ca3 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -90,6 +90,12 @@ void register_exit(void (*cb)(int ret))
program_exit = cb;
}
+void report_error_then_exit_program(int ret)
Maybe report_and_exit instead. report_error_then_exit_program is IMO too
long.
+{
+av_log(NULL, AV_LOG_FATAL, "%s\n", av_err2str(ret));
+exit_program(AVUNERROR(ret));
+}
+
void exit_program(int ret)
{
if (program_exit)
diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
index d87e162ccd..358f0a0ef9 100644
--- a/fftools/cmdutils.h
+++ b/fftools/cmdutils.h
@@ -54,6 +54,17 @@ extern int hide_banner;
*/
void register_exit(void (*cb)(int ret));
+/**
+ * Reports an error corresponding to the provided
+ * AVERROR code and calls exit_program() with the
+ * corresponding POSIX error code.
+ * @note ret must be an AVERROR-value of a POSIX error code
+ * (i.e. AVERROR(EFOO) and not AVERROR_FOO).
+ * library functions can return both, so call this only
+ * with AVERROR(EFOO) of your own.
+ */
+void report_error_then_exit_program(int ret) av_noreturn;
+
/**
* Wraps exit with a program-specific cleanup routine.
*/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] fftools/cmdutils: Add function to report error before exit
James Almer:
>
>
> On 8/27/2022 10:55 AM, Andreas Rheinhardt wrote:
>> This is designed to improve and unify error handling for
>> allocation failures for the many (often small) allocations that we have
>> in the fftools. These typically either don't return an error message
>> or an error message that is not really helpful to the user
>> and can be replaced by a generic error message without loss of
>> information.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> fftools/cmdutils.c | 6 ++
>> fftools/cmdutils.h | 11 +++
>> 2 files changed, 17 insertions(+)
>>
>> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
>> index 18e768b386..b6f5c01ca3 100644
>> --- a/fftools/cmdutils.c
>> +++ b/fftools/cmdutils.c
>> @@ -90,6 +90,12 @@ void register_exit(void (*cb)(int ret))
>> program_exit = cb;
>> }
>> +void report_error_then_exit_program(int ret)
>
> Maybe report_and_exit instead. report_error_then_exit_program is IMO too
> long.
>
Good suggestion. Will do so.
>> +{
>> + av_log(NULL, AV_LOG_FATAL, "%s\n", av_err2str(ret));
>> + exit_program(AVUNERROR(ret));
>> +}
>> +
>> void exit_program(int ret)
>> {
>> if (program_exit)
>> diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
>> index d87e162ccd..358f0a0ef9 100644
>> --- a/fftools/cmdutils.h
>> +++ b/fftools/cmdutils.h
>> @@ -54,6 +54,17 @@ extern int hide_banner;
>> */
>> void register_exit(void (*cb)(int ret));
>> +/**
>> + * Reports an error corresponding to the provided
>> + * AVERROR code and calls exit_program() with the
>> + * corresponding POSIX error code.
>> + * @note ret must be an AVERROR-value of a POSIX error code
>> + * (i.e. AVERROR(EFOO) and not AVERROR_FOO).
>> + * library functions can return both, so call this only
>> + * with AVERROR(EFOO) of your own.
>> + */
>> +void report_error_then_exit_program(int ret) av_noreturn;
>> +
>> /**
>> * Wraps exit with a program-specific cleanup routine.
>> */
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 1/3] fftools/cmdutils: Add function to report error before exit
This is designed to improve and unify error handling for
allocation failures for the many (often small) allocations that we have
in the fftools. These typically either don't return an error message
or an error message that is not really helpful to the user
and can be replaced by a generic error message without loss of
information.
Reviewed-by: James Almer
Signed-off-by: Andreas Rheinhardt
---
fftools/cmdutils.c | 6 ++
fftools/cmdutils.h | 11 +++
2 files changed, 17 insertions(+)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 18e768b386..da3d391694 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -90,6 +90,12 @@ void register_exit(void (*cb)(int ret))
program_exit = cb;
}
+void report_and_exit(int ret)
+{
+av_log(NULL, AV_LOG_FATAL, "%s\n", av_err2str(ret));
+exit_program(AVUNERROR(ret));
+}
+
void exit_program(int ret)
{
if (program_exit)
diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
index d87e162ccd..4496221983 100644
--- a/fftools/cmdutils.h
+++ b/fftools/cmdutils.h
@@ -54,6 +54,17 @@ extern int hide_banner;
*/
void register_exit(void (*cb)(int ret));
+/**
+ * Reports an error corresponding to the provided
+ * AVERROR code and calls exit_program() with the
+ * corresponding POSIX error code.
+ * @note ret must be an AVERROR-value of a POSIX error code
+ * (i.e. AVERROR(EFOO) and not AVERROR_FOO).
+ * library functions can return both, so call this only
+ * with AVERROR(EFOO) of your own.
+ */
+void report_and_exit(int ret) av_noreturn;
+
/**
* Wraps exit with a program-specific cleanup routine.
*/
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 2/3] fftools: Use report_error_then_exit_program() for allocation failures
Signed-off-by: Andreas Rheinhardt
---
fftools/cmdutils.c | 21 +
fftools/ffmpeg.c| 25 ++-
fftools/ffmpeg_filter.c | 10 +++---
fftools/ffmpeg_opt.c| 70 -
fftools/ffprobe.c | 6 ++--
fftools/opt_common.c| 6 ++--
6 files changed, 52 insertions(+), 86 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index da3d391694..f911c52be2 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -656,7 +656,7 @@ static void init_parse_context(OptionParseContext *octx,
octx->nb_groups = nb_groups;
octx->groups= av_calloc(octx->nb_groups, sizeof(*octx->groups));
if (!octx->groups)
-exit_program(1);
+report_and_exit(AVERROR(ENOMEM));
for (i = 0; i < octx->nb_groups; i++)
octx->groups[i].group_def = &groups[i];
@@ -964,11 +964,8 @@ AVDictionary **setup_find_stream_info_opts(AVFormatContext
*s,
if (!s->nb_streams)
return NULL;
opts = av_calloc(s->nb_streams, sizeof(*opts));
-if (!opts) {
-av_log(NULL, AV_LOG_ERROR,
- "Could not alloc memory for stream options.\n");
-exit_program(1);
-}
+if (!opts)
+report_and_exit(AVERROR(ENOMEM));
for (i = 0; i < s->nb_streams; i++)
opts[i] = filter_codec_opts(codec_opts,
s->streams[i]->codecpar->codec_id,
s, s->streams[i], NULL);
@@ -983,10 +980,8 @@ void *grow_array(void *array, int elem_size, int *size,
int new_size)
}
if (*size < new_size) {
uint8_t *tmp = av_realloc_array(array, new_size, elem_size);
-if (!tmp) {
-av_log(NULL, AV_LOG_ERROR, "Could not alloc buffer.\n");
-exit_program(1);
-}
+if (!tmp)
+report_and_exit(AVERROR(ENOMEM));
memset(tmp + *size*elem_size, 0, (new_size-*size) * elem_size);
*size = new_size;
return tmp;
@@ -999,10 +994,8 @@ void *allocate_array_elem(void *ptr, size_t elem_size, int
*nb_elems)
void *new_elem;
if (!(new_elem = av_mallocz(elem_size)) ||
-av_dynarray_add_nofree(ptr, nb_elems, new_elem) < 0) {
-av_log(NULL, AV_LOG_ERROR, "Could not alloc buffer.\n");
-exit_program(1);
-}
+av_dynarray_add_nofree(ptr, nb_elems, new_elem) < 0)
+report_and_exit(AVERROR(ENOMEM));
return new_elem;
}
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index ef7177fc33..8f53f5c7ef 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1094,10 +1094,8 @@ static void do_subtitle_out(OutputFile *of,
return;
ret = av_new_packet(pkt, subtitle_out_max_size);
-if (ret < 0) {
-av_log(NULL, AV_LOG_FATAL, "Failed to allocate subtitle encode
buffer\n");
-exit_program(1);
-}
+if (ret < 0)
+report_and_exit(AVERROR(ENOMEM));
sub->pts = pts;
// start_display_time is required to be 0
@@ -2345,7 +2343,7 @@ static int transcode_subtitles(InputStream *ist, AVPacket
*pkt, int *got_output,
if (!ist->sub2video.sub_queue)
ist->sub2video.sub_queue = av_fifo_alloc2(8, sizeof(AVSubtitle),
AV_FIFO_FLAG_AUTO_GROW);
if (!ist->sub2video.sub_queue)
-exit_program(1);
+report_and_exit(AVERROR(ENOMEM));
ret = av_fifo_write(ist->sub2video.sub_queue, &subtitle, 1);
if (ret < 0)
@@ -2874,7 +2872,7 @@ static void set_encoder_id(OutputFile *of, OutputStream
*ost)
encoder_string_len = sizeof(LIBAVCODEC_IDENT) + strlen(ost->enc->name) + 2;
encoder_string = av_mallocz(encoder_string_len);
if (!encoder_string)
-exit_program(1);
+report_and_exit(AVERROR(ENOMEM));
if (!of->bitexact && !ost->bitexact)
av_strlcpy(encoder_string, LIBAVCODEC_IDENT " ", encoder_string_len);
@@ -2897,10 +2895,8 @@ static void parse_forced_key_frames(char *kf,
OutputStream *ost,
n++;
size = n;
pts = av_malloc_array(size, sizeof(*pts));
-if (!pts) {
-av_log(NULL, AV_LOG_FATAL, "Could not allocate forced key frames
array.\n");
-exit_program(1);
-}
+if (!pts)
+report_and_exit(AVERROR(ENOMEM));
p = kf;
for (i = 0; i < n; i++) {
@@ -2919,11 +2915,8 @@ static void parse_forced_key_frames(char *kf,
OutputStream *ost,
if (nb_ch > INT_MAX - size ||
!(pts = av_realloc_f(pts, size += nb_ch - 1,
- sizeof(*pts {
-av_log(NULL, AV_LOG_FATAL,
- "Could not allocate forced key frames array.\n");
-exit_program(1);
-}
+ sizeof(*pts
+report_and_exit(AVERROR(ENOMEM));
t = p[8] ? parse_time_or_die("force_key_frames", p + 8, 1) : 0;
t = av_rescale_q(t, AV_TIME_BASE_Q, avctx->time_base);
@@ -3
[FFmpeg-devel] [PATCH v2 3/3] fftools/ffmpeg_opt: Check creation of new program
Fixes Coverity issue #1512413.
Signed-off-by: Andreas Rheinhardt
---
fftools/ffmpeg_opt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index ccb79d920c..eddd421b70 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -2753,6 +2753,8 @@ static void of_add_programs(AVFormatContext *oc, const
OptionsContext *o)
}
program = av_new_program(oc, progid);
+if (!program)
+report_and_exit(AVERROR(ENOMEM));
p = o->program[i].u.str;
while(*p) {
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat/imfdec: check track valid before use it
On Sat, Aug 27, 2022 at 5:25 AM Steven Liu wrote: > > Pierre-Anthony Lemieux 于2022年8月27日周六 00:06写道： > > > > On Fri, Aug 26, 2022 at 9:01 AM Andreas Rheinhardt > > wrote: > > > > > > Pierre-Anthony Lemieux: > > > > On Fri, Aug 26, 2022 at 1:37 AM Andreas Rheinhardt > > > > wrote: > > > >> > > > >> Steven Liu: > > > >>> fix CID: 1512414 > > > >>> And return AVERROR_INVALIDDATA when > > > >>> get_next_track_with_minimum_timestamp > > > >>> incorrect in imf_read_packet; > > > >>> > > > >>> Signed-off-by: Steven Liu > > > >>> --- > > > >>> libavformat/imfdec.c | 7 +-- > > > >>> 1 file changed, 5 insertions(+), 2 deletions(-) > > > >>> > > > >>> diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c > > > >>> index 5bbe7a53f8..08f342bc1a 100644 > > > >>> --- a/libavformat/imfdec.c > > > >>> +++ b/libavformat/imfdec.c > > > >>> @@ -697,8 +697,9 @@ static IMFVirtualTrackPlaybackCtx > > > >>> *get_next_track_with_minimum_timestamp(AVForma > > > >>> } > > > >>> } > > > >>> > > > >>> -av_log(s, AV_LOG_DEBUG, "Found next track to read: %d > > > >>> (timestamp: %lf / %lf)\n", > > > >>> - track->index, av_q2d(track->current_timestamp), > > > >>> av_q2d(minimum_timestamp)); > > > >>> +if (track) > > > >>> +av_log(s, AV_LOG_DEBUG, "Found next track to read: %d > > > >>> (timestamp: %lf / %lf)\n", > > > >>> + track->index, av_q2d(track->current_timestamp), > > > >>> av_q2d(minimum_timestamp)); > > > >> > > > >> Coverity actually complained about track being uninitialized, which > > > >> this > > > >> patch does not address. And the reason it does this is that it doesn't > > > >> understand the algorithm: track will always be initialized in the first > > > >> iteration of the loop. > > > > > > > > Is it possible to tell coverity that c->track_count > 0 is a > > > > pre-condition, or should we modify the loop/algorithm? > > > > > > > > > > The typical way to do this is to add an av_assert1 or av_assert2; > > > but this must only be done if it is indeed ensured that the assert will > > > not be triggered. > > > > > > >> (If there is a first iteration of the loop -- is > > > >> this actually guaranteed? A file without tracks seems to be pretty > > > >> useless.) > > > > > > > > imfdec currently assumes that (a) imf_read_packet() is not called if > > > > there are no streams/tracks and (b) a track will always be found. > > > > > > > > (b) will be true for a conformant IMF Composition, but I am not sure > > > > it can always be true for a malformed one. > > > > > > > > > > Can't we make it true by adding the relevant checks to read_header? > > > > Yes. > Can imf add or remove track when processing? Looks like the live > streaming change resolution or bitrate when playing. The number of tracks is fixed and determined when the Composition Playlist (CPL) is parsed. > > > > > > > > > I think imf_read_packet() can probably be hardened. Perhaps do this as > > > > a patch separately from addressing the coverity issue? > > > > > > > >> FYI: In Coverity's analysis there are loop iterations, but it just > > > >> assumed that track is not initialized in the loop (which boils down to > > > >> saying that it presumed the tracks' current_timestamp to be invalid > > > >> (denominator 0). I hope this can't happen. > > > >> (There is btw another issue: The initialization of minimum_timestamp > > > >> presumes that int are 32bit which need not be true.) > > > > > > > > INT32_MAX -> INT_MAX should fix this right? > > > > > > > > > > Yes. > > > > > > >> > > > >>> return track; > > > >>> } > > > >>> > > > >>> @@ -760,6 +761,8 @@ static int imf_read_packet(AVFormatContext *s, > > > >>> AVPacket *pkt) > > > >>> AVRational next_timestamp; > > > >>> > > > >>> track = get_next_track_with_minimum_timestamp(s); > > > >>> +if (!track) > > > >>> +return AVERROR_INVALIDDATA; > > > >>> > > > >>> ret = get_resource_context_for_timestamp(s, track, &resource); > > > >>> if (ret) > > > >> > > > >> ___ > > > >> ffmpeg-devel mailing list > > > >> ffmpeg-devel@ffmpeg.org > > > >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > >> > > > >> To unsubscribe, visit link above, or email > > > >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > > > ___ > > > > ffmpeg-devel mailing list > > > > ffmpeg-devel@ffmpeg.org > > > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > > > To unsubscribe, visit link above, or email > > > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > > > > > ___ > > > ffmpeg-devel mailing list > > > ffmpeg-devel@ffmpeg.org > > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > To unsubscribe, visit link above, or email > > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > ___ > > ffmpeg
Re: [FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway
On Aug 27, 2022, at 4:30 AM, Tomas Härdin wrote: > > lör 2022-08-27 klockan 09:53 +0200 skrev Paul B Mahol: >> On Sat, Aug 27, 2022 at 9:30 AM Tomas Härdin >> wrote: >> >>> ons 2022-08-24 klockan 23:03 +0200 skrev Michael Niedermayer: Also we have regression tests, external libs make that impossible as the version of external libs can change the behavior. Again this is a issue for mxf maybe less so libxml. You can also see that we have no tests involving any of the external encoder libs, for that very reason. With each external lib that is needed for core features this would become a quickly growing problem >>> >>> Testing is certainly a challenge, but almost certainly easier than >>> reimplementing certain formats and codecs poorly, especially MXF. >>> >>> >> Than why you are so called maintainer of thing you do not want to >> maintain? > > Me maintaining mxfdec is precisely why I want to switch to bmx I strongly oppose to that. Didn’t we just merge IMF support ? That seems to indicate that people are fine with FFmpeg MXF implementation. If the need arises, I will maintain the MXF code, I use it everyday after all :) — Baptiste ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v4] libavcodec: Set hidden visibility on global symbols accessed from AArch64 assembly
The AArch64 assembly accesses those symbols directly, without
indirection via e.g. the GOT on ELF. In order for this not to
require text relocations, those symbols need to be resolved fully
at link time, i.e. those symbols can't be interposable.
Normally, so far, this is achieved when linking shared libraries
in two ways; we have a version script (libavcodec/libavcodec.v) which
marks all symbols that don't start with av* as local. Additionally,
we try to add -Wl,-Bsymbolic to the linker options if supported,
making sure that such symbol references are resolved fully at link
time, instead of making them interposable.
When the libavcodec static library is linked into another shared
library, there's no guarantee that it uses similar options (even though
that would be favourable), which would end up requiring text relocations
in the AArch64 assembly.
Explicitly mark the symbols that are accessed from AArch64 assembly
as hidden, so that they are resolved fully at link time even without
the version script and -Wl,-Bsymbolic.
Signed-off-by: Martin Storsjö
---
v4: Moved the attribute definition to a new, standalone header (which
only depends on libavutil/attributes.h).
---
libavcodec/aacsbrdata.h | 3 ++-
libavcodec/fft.h| 3 ++-
libavcodec/vp9dsp.h | 3 ++-
libavutil/attributes_internal.h | 30 ++
4 files changed, 36 insertions(+), 3 deletions(-)
create mode 100644 libavutil/attributes_internal.h
diff --git a/libavcodec/aacsbrdata.h b/libavcodec/aacsbrdata.h
index 7a11594c9b..7bb45b229e 100644
--- a/libavcodec/aacsbrdata.h
+++ b/libavcodec/aacsbrdata.h
@@ -29,6 +29,7 @@
#define AVCODEC_AACSBRDATA_H
#include
+#include "libavutil/attributes_internal.h"
#include "libavutil/mem_internal.h"
#include "aac_defines.h"
@@ -268,7 +269,7 @@ static const int8_t sbr_offset[6][16] = {
};
/* First eight entries repeated at end to simplify SIMD implementations. */
-const DECLARE_ALIGNED(16, INTFLOAT, AAC_RENAME(ff_sbr_noise_table))[][2] = {
+const attribute_visibility_hidden DECLARE_ALIGNED(16, INTFLOAT,
AAC_RENAME(ff_sbr_noise_table))[][2] = {
{Q31(-0.99948153278296f), Q31(-0.59483417516607f)}, {Q31( 0.97113454393991f),
Q31(-0.67528515225647f)},
{Q31( 0.14130051758487f), Q31(-0.95090983575689f)}, {Q31(-0.47005496701697f),
Q31(-0.37340549728647f)},
{Q31( 0.80705063769351f), Q31( 0.29653668284408f)}, {Q31(-0.38981478896926f),
Q31( 0.89572605717087f)},
diff --git a/libavcodec/fft.h b/libavcodec/fft.h
index 706c9d07f5..d46e5a3f0b 100644
--- a/libavcodec/fft.h
+++ b/libavcodec/fft.h
@@ -29,6 +29,7 @@
#include
#include "config.h"
+#include "libavutil/attributes_internal.h"
#include "libavutil/mem_internal.h"
#if FFT_FLOAT
@@ -114,7 +115,7 @@ void ff_init_ff_cos_tabs(int index);
#endif
#define COSTABLE(size) \
-COSTABLE_CONST DECLARE_ALIGNED(32, FFTSample,
FFT_NAME(ff_cos_##size))[size/2]
+COSTABLE_CONST attribute_visibility_hidden DECLARE_ALIGNED(32, FFTSample,
FFT_NAME(ff_cos_##size))[size/2]
extern COSTABLE(16);
extern COSTABLE(32);
diff --git a/libavcodec/vp9dsp.h b/libavcodec/vp9dsp.h
index 700dd72de8..be0ac0b181 100644
--- a/libavcodec/vp9dsp.h
+++ b/libavcodec/vp9dsp.h
@@ -28,6 +28,7 @@
#include
#include "libavcodec/vp9.h"
+#include "libavutil/attributes_internal.h"
typedef void (*vp9_mc_func)(uint8_t *dst, ptrdiff_t dst_stride,
const uint8_t *ref, ptrdiff_t ref_stride,
@@ -120,7 +121,7 @@ typedef struct VP9DSPContext {
vp9_scaled_mc_func smc[5][N_FILTERS][2];
} VP9DSPContext;
-extern const int16_t ff_vp9_subpel_filters[3][16][8];
+extern const int16_t attribute_visibility_hidden
ff_vp9_subpel_filters[3][16][8];
void ff_vp9dsp_init(VP9DSPContext *dsp, int bpp, int bitexact);
diff --git a/libavutil/attributes_internal.h b/libavutil/attributes_internal.h
new file mode 100644
index 00..9d3d10b63e
--- /dev/null
+++ b/libavutil/attributes_internal.h
@@ -0,0 +1,30 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVUTIL_ATTRIBUTES_INTERNAL_H
+#define AVUTIL_ATTRIBUTES_INTERNAL_H
+
+#include "attributes.h"
+
+#if (AV_GCC_VERSION_AT_LEAST(4,0) || defined(__clang__)) && (defined(__ELF__)
|| defined(__MACH__))
+#define attrib
Re: [FFmpeg-devel] [PATCH] avformat/mov: don't read duration from mvhd atom
On 8/16/2022 4:22 PM, Michael Niedermayer wrote: On Mon, Aug 15, 2022 at 08:14:42PM -0300, James Almer wrote: This duration is equal to the longest duration in all track's tkhd atoms, which may be comprised of the sum of all edit lists in each track. Empty edit lists in tracks represent start_time, and the actual media duration is stored in the mdhd atom. This change lets the generic demux code derive the longest track duration taken from mdhd atoms, so the correct duration and start_time combination will be reported. Should fix ticket #9775. Signed-off-by: James Almer --- libavformat/mov.c| 4 tests/ref/fate/gaplessenc-itunes-to-ipod-aac | 2 +- 2 files changed, 1 insertion(+), 5 deletions(-) No idea if its a bad or good change but this changes the output for: ./ffmpeg -f concat -i ~/tickets/3108/concatfile.txt -codec copy -bitexact /tmp/3108.avi thx I don't see an avi file in that ticket, but for the mov in the zip file, the video track duration is used after this patch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/mov: don't read duration from mvhd atom
On Sat, Aug 27, 2022 at 04:41:39PM -0300, James Almer wrote: > On 8/16/2022 4:22 PM, Michael Niedermayer wrote: > > On Mon, Aug 15, 2022 at 08:14:42PM -0300, James Almer wrote: > > > This duration is equal to the longest duration in all track's tkhd atoms, > > > which > > > may be comprised of the sum of all edit lists in each track. Empty edit > > > lists > > > in tracks represent start_time, and the actual media duration is stored > > > in the > > > mdhd atom. > > > This change lets the generic demux code derive the longest track duration > > > taken > > > from mdhd atoms, so the correct duration and start_time combination will > > > be > > > reported. > > > > > > Should fix ticket #9775. > > > > > > Signed-off-by: James Almer > > > --- > > > libavformat/mov.c| 4 > > > tests/ref/fate/gaplessenc-itunes-to-ipod-aac | 2 +- > > > 2 files changed, 1 insertion(+), 5 deletions(-) > > > > No idea if its a bad or good change but this changes the output for: > > ./ffmpeg -f concat -i ~/tickets/3108/concatfile.txt -codec copy -bitexact > > /tmp/3108.avi > > > > thx > > I don't see an avi file in that ticket, but for the mov in the zip file, the > video track duration is used after this patch. the avi is generated in that command from the concatfile.txt from the tickets zip thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] trac issues
Hi all someone reported issues with disappearing mail and server load for trac Ive setup SPF for trac, which may have been the reason for gmail blocking mails from it ive also increased the number or processes x threads handling trac requests not sure that was the issue but trac/wsgi had significnatly fewer than apache so i guessed that may have been an issue Thanks -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If the United States is serious about tackling the national security threats related to an insecure 5G network, it needs to rethink the extent to which it values corporate profits and government espionage over security.-Bruce Schneier signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
