[FFmpeg-devel] [PATCH v3 1/2] avformat: refactor ff_stream_encode_params_copy() to ff_stream_params_copy()
From: Pierre-Anthony Lemieux
As discussed at https://ffmpeg.org/pipermail/ffmpeg-devel/2022-July/298491.html.
Note that ff_stream_params_copy() does not copy the index field, which is
usually set by avformat_new_stream().
---
libavformat/avformat.c | 37 +
libavformat/fifo.c | 2 +-
libavformat/internal.h | 10 ++
libavformat/mux.h| 9 -
libavformat/mux_utils.c | 28
libavformat/segment.c| 2 +-
libavformat/tee.c| 2 +-
libavformat/webm_chunk.c | 2 +-
8 files changed, 51 insertions(+), 41 deletions(-)
diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index 30d6ea6a49..c426dbfa45 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -235,6 +235,43 @@ int ff_stream_side_data_copy(AVStream *dst, const AVStream
*src)
return 0;
}
+int ff_stream_params_copy(AVStream *dst, const AVStream *src)
+{
+int ret;
+
+dst->id = src->id;
+dst->time_base = src->time_base;
+dst->start_time = src->start_time;
+dst->duration= src->duration;
+dst->nb_frames = src->nb_frames;
+dst->disposition = src->disposition;
+dst->discard = src->discard;
+dst->sample_aspect_ratio = src->sample_aspect_ratio;
+dst->avg_frame_rate = src->avg_frame_rate;
+dst->event_flags = src->event_flags;
+dst->r_frame_rate= src->r_frame_rate;
+dst->pts_wrap_bits = src->pts_wrap_bits;
+
+av_dict_free(&dst->metadata);
+ret = av_dict_copy(&dst->metadata, src->metadata, 0);
+if (ret < 0)
+return ret;
+
+ret = avcodec_parameters_copy(dst->codecpar, src->codecpar);
+if (ret < 0)
+return ret;
+
+ret = ff_stream_side_data_copy(dst, src);
+if (ret < 0)
+return ret;
+
+ret = av_packet_ref(&dst->attached_pic, &src->attached_pic);
+if (ret < 0)
+return ret;
+
+return 0;
+}
+
AVProgram *av_new_program(AVFormatContext *ac, int id)
{
AVProgram *program = NULL;
diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index ead2bdc5cf..fef116d040 100644
--- a/libavformat/fifo.c
+++ b/libavformat/fifo.c
@@ -509,7 +509,7 @@ static int fifo_mux_init(AVFormatContext *avf, const
AVOutputFormat *oformat,
if (!st)
return AVERROR(ENOMEM);
-ret = ff_stream_encode_params_copy(st, avf->streams[i]);
+ret = ff_stream_params_copy(st, avf->streams[i]);
if (ret < 0)
return ret;
}
diff --git a/libavformat/internal.h b/libavformat/internal.h
index b6b8fbf56f..774ff57698 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -625,6 +625,16 @@ enum AVCodecID ff_get_pcm_codec_id(int bps, int flt, int
be, int sflags);
*/
int ff_stream_side_data_copy(AVStream *dst, const AVStream *src);
+/**
+ * Copy all stream parameters from source to destination stream, with the
+ * exception of the index field, which is usually set by
avformat_new_stream().
+ *
+ * @param dst pointer to destination AVStream
+ * @param src pointer to source AVStream
+ * @return >=0 on success, AVERROR code on error
+ */
+int ff_stream_params_copy(AVStream *dst, const AVStream *src);
+
/**
* Wrap ffurl_move() and log if error happens.
*
diff --git a/libavformat/mux.h b/libavformat/mux.h
index c01da82194..1bfcaf795f 100644
--- a/libavformat/mux.h
+++ b/libavformat/mux.h
@@ -113,15 +113,6 @@ int ff_format_shift_data(AVFormatContext *s, int64_t
read_start, int shift_size)
*/
int ff_format_output_open(AVFormatContext *s, const char *url, AVDictionary
**options);
-/**
- * Copy encoding parameters from source to destination stream
- *
- * @param dst pointer to destination AVStream
- * @param src pointer to source AVStream
- * @return >=0 on success, AVERROR code on error
- */
-int ff_stream_encode_params_copy(AVStream *dst, const AVStream *src);
-
/**
* Parse creation_time in AVFormatContext metadata if exists and warn if the
* parsing fails.
diff --git a/libavformat/mux_utils.c b/libavformat/mux_utils.c
index eb8ea3d560..2fa2ab5b0f 100644
--- a/libavformat/mux_utils.c
+++ b/libavformat/mux_utils.c
@@ -121,34 +121,6 @@ int ff_format_output_open(AVFormatContext *s, const char
*url, AVDictionary **op
return 0;
}
-int ff_stream_encode_params_copy(AVStream *dst, const AVStream *src)
-{
-int ret;
-
-dst->id = src->id;
-dst->time_base = src->time_base;
-dst->nb_frames = src->nb_frames;
-dst->disposition = src->disposition;
-dst->sample_aspect_ratio = src->sample_aspect_ratio;
-dst->avg_frame_rate = src->avg_frame_rate;
-dst->r_frame_rate= src->r_frame_rate;
-
-av_dict_free(&dst->metadata);
-ret = av_dict_copy(&dst->metadata, src->metadata, 0);
-if (ret < 0)
-return ret;
-
-ret = avcodec_parameters_copy(dst->codecpar, src->codecpar);
[FFmpeg-devel] [PATCH v3 2/2] avformat/imfdec: preserve stream information
From: Pierre-Anthony Lemieux
As discussed at https://trac.ffmpeg.org/ticket/9818, the IMF demuxer does not
currently preserve stream information such as language in the case of audio
streams.
---
libavformat/imfdec.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
index 71dfb26958..4cd6a56a09 100644
--- a/libavformat/imfdec.c
+++ b/libavformat/imfdec.c
@@ -579,12 +579,15 @@ static int
set_context_streams_from_tracks(AVFormatContext *s)
av_log(s, AV_LOG_ERROR, "Could not create stream\n");
return AVERROR(ENOMEM);
}
-asset_stream->id = i;
-ret = avcodec_parameters_copy(asset_stream->codecpar,
first_resource_stream->codecpar);
+
+ret = ff_stream_params_copy(asset_stream, first_resource_stream);
if (ret < 0) {
av_log(s, AV_LOG_ERROR, "Could not copy stream parameters\n");
return ret;
}
+
+asset_stream->id = i;
+asset_stream->nb_frames = 0;
avpriv_set_pts_info(asset_stream,
first_resource_stream->pts_wrap_bits,
first_resource_stream->time_base.num,
--
2.25.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] avformat/riffdec: fix support for WAVEFORMAT
WAVEFORMAT can be used for 16-bit PCM as well.
Signed-off-by: Tom Yan
---
libavformat/riffdec.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavformat/riffdec.c b/libavformat/riffdec.c
index 3946ecb72f..8289438f08 100644
--- a/libavformat/riffdec.c
+++ b/libavformat/riffdec.c
@@ -94,7 +94,7 @@ static void parse_waveformatex(AVFormatContext *s,
AVIOContext *pb, AVCodecParam
int ff_get_wav_header(AVFormatContext *s, AVIOContext *pb,
AVCodecParameters *par, int size, int big_endian)
{
-int id, channels;
+int id, channels = 0;
uint64_t bitrate = 0;
if (size < 14) {
@@ -118,15 +118,15 @@ int ff_get_wav_header(AVFormatContext *s, AVIOContext *pb,
bitrate= avio_rb32(pb) * 8LL;
par->block_align = avio_rb16(pb);
}
-if (size == 14) { /* We're dealing with plain vanilla WAVEFORMAT */
-par->bits_per_coded_sample = 8;
-} else {
+if (size >= 16) { /* We're dealing with PCMWAVEFORMAT */
if (!big_endian) {
par->bits_per_coded_sample = avio_rl16(pb);
} else {
par->bits_per_coded_sample = avio_rb16(pb);
}
-}
+} else if (channels && par->sample_rate) { /* We're dealing with
WAVEFORMAT */
+par->bits_per_coded_sample = bitrate / channels / par->sample_rate;
+} /* Apparently size would be >= 32 if id == 0x0165; see below */
if (id == 0xFFFE) {
par->codec_tag = 0;
} else {
--
2.37.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 v5 00/25] Subtitle Filtering 2022
On Sun, Jul 24, 2022 at 05:10:17PM +0200, Nicolas George wrote: > I hesitated a long time before replying, but all considering, at this > point expressing what is weighing on my heart cannot make things worse. > > > Michael Niedermayer (12022-07-03): > > What is the timeline for the audio+video merge ? > > I cannot give a timeline because I do not work on FFmpeg on a schedule, > I work on FFmpeg in my free time, for fun. And lately, working on FFmpeg > has been really un-fun. Recently, my contributions have been met with I think many if us, myself included have had un-fun periods in ffmpeg. This on its own is already bad and we should strive to make project contributions more fun to all. > indifference at best (see when I proposed a XML parser six months ago: > nobody cared), outright hostility at worst. Under these circumstances, > whenever I am considering working on something FFmpeg-related, I usually > find something else more fun to do. If we add a XML parser to FFmpeg. Such a thing would be used by several bits and we need to ensure it has redundant maintainership. So i think a xml parser needs broad support by developers otherwise we run the risk that if it has a single maintainer only and that maintainer stops maintaining it that could be annoying to more than just the parser itself. I cannot remember exactly without re-reading the old thread what the issues people had with the xml parser. If it was some component of it or in general. But i think its mostly a question if theres more than one person who wants to maintain it. [...] > It illustrates what it means to be a maintainer. It does not only mean > the task of reviewing and applying bug fixes. The maintainer holds in > their head a knowledge of the code that cannot be fully shared in > writing. The maintainer also holds in their head plans to evolve and > extend the code. > > I have plans for libavfilter. Not just vague ideas, but precise plans on > how to reach the goal. I have plans for subtitles filtering, of course. > But not only. > > I have plans for filtering data packets, so that bistream filters do not > need to have a separate and redundant API and ffmpeg does not need a > separate code path for -c copy. > > I have plans for threading, or more precisely integrating filters in a > global parallelized task and I/O scheduler. > > I have plans for seeking, with the seek target going back from the > output to the input(s). > > I have plans for partial graph reconfiguration, to accommodate format > changes mid-stream and let applications alter filtering in the middle. > > All of this is exciting. I am eager to work on any of this. > > Unfortunately, before it can happen, boring things need to be done. > Parts of the framework of libavfilter are very fragile. Working on any > of these is likely to break cases that were specifically fixed in the > past. > > I can work on boring things if they are necessary to reach the exciting > parts. > > What I cannot do is motivate myself to work on the boring things with > the threat that the exciting things will be snatched under me by an > inferior version from somebody who just refuses to engage with the > boring necessary things. If you work on libavfilter, noone will snatch it from you. If you dont work on it, eventually someone else will attempt to take over and push libavfilter in the direction he feels best which may or may not match what you want. If theres something i can do to make libavfilter work more fun for you please tell me. I think it would be best if people worked a bit more together on this. The current situation where work is split between your vission and this patchset is kind of a bad thing. Its a bit unfortunate noone involved seems to have the carismatic leader skills to pull everyone on his side and then get that side to the point that everyone is happy with the code and neither has a consensus emerged based on technical arguments. I think maybe more a "what is best for the project to move forward" and a less "how can i get my hard work in first" approuch might help but we can also try the technical commiitee of course but iam not sure how much that would really help, it would be better if some consensus would be reached and everyone would then work together on implementing that theres of course also the fork and merge approuch. Each side does whatever they like in their repository and then we at some point compare and merge one or both into ffmpeg. Iam not sure thats a good idea or not. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-deve
Re: [FFmpeg-devel] [PATCH] avcodec/x86/pngdsp: Remove obsolete ff_add_bytes_l2_mmx()
On Mon, Jul 25, 2022 at 5:43 AM Andreas Rheinhardt wrote: > > It is overridden by ff_add_bytes_l2_sse2() on any non-ancient CPU. > > Signed-off-by: Andreas Rheinhardt Lgtm ___ 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] qsv: Update ffmpeg qsv_errors to recognize GPU hang
On Mon, 2022-07-25 at 01:21 +, Xiang, Haihao wrote:
> On Fri, 2022-07-22 at 11:06 -0700, Dmitry Rogozhkin wrote:
> > GPU hang is one of the most typical errors on Intel GPUs in
> > case something goes wrong. It's important to recognize it
> > explicitly for easier bugs triage. Also, this error code
> > can be used to trigger GPU recovery path in self-written
> > applications.
> >
> > Signed-off-by: Hon Wai Chow
> > Signed-off-by: Dmitry Rogozhkin
> > ---
> > libavcodec/qsv.c | 1 +
> > libavfilter/qsvvpp.c | 1 +
> > 2 files changed, 2 insertions(+)
> >
> > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> > index 385b43b..55bcb6e 100644
> > --- a/libavcodec/qsv.c
> > +++ b/libavcodec/qsv.c
> > @@ -125,6 +125,7 @@ static const struct {
> > { MFX_ERR_INVALID_VIDEO_PARAM, AVERROR(EINVAL), "invalid
> > video
> > parameters" },
> > {
> > MFX_ERR_UNDEFINED_BEHAVIOR, AVERROR_BUG, "undefined
> > behavior" },
> > { MFX_ERR_DEVICE_FAILED,AVERROR(EIO),"device
> > failed"},
> > +{ MFX_ERR_GPU_HANG, AVERROR(EIO),"GPU
> > Hang" },
> > { MFX_ERR_INCOMPATIBLE_AUDIO_PARAM, AVERROR(EINVAL),
> > "incompatible audio
> > parameters"},
> > { MFX_ERR_INVALID_AUDIO_PARAM, AVERROR(EINVAL), "invalid
> > audio
> > parameters" },
> >
> > diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
> > index 954f882..7504906 100644
> > --- a/libavfilter/qsvvpp.c
> > +++ b/libavfilter/qsvvpp.c
> > @@ -100,6 +100,7 @@ static const struct {
> > { MFX_ERR_INVALID_VIDEO_PARAM, AVERROR(EINVAL), "invalid
> > video
> > parameters" },
> > {
> > MFX_ERR_UNDEFINED_BEHAVIOR, AVERROR_BUG, "undefined
> > behavior" },
> > { MFX_ERR_DEVICE_FAILED,AVERROR(EIO),"device
> > failed"},
> > +{ MFX_ERR_GPU_HANG, AVERROR(EIO),"GPU
> > Hang" },
> > { MFX_ERR_INCOMPATIBLE_AUDIO_PARAM, AVERROR(EINVAL),
> > "incompatible audio
> > parameters"},
> > { MFX_ERR_INVALID_AUDIO_PARAM, AVERROR(EINVAL), "invalid
> > audio
> > parameters" },
> >
>
> Could you add other missing qsv video errors or warnings too ?
Yes, sure. For what I see we are missing 3 statuses returnable by
mediasdk library implementations: MFX_ERR_GPU_HANG,
MFX_ERR_NONE_PARTIAL_OUTPUT, MFX_ERR_REALLOC_SURFACE. Other statuses
defined in mfxdefs.h are not returnable to ffmpeg level (they are
internal or plugin specific stuff).
I will resubmit the patch under other name with added stuff.
>
> Thanks
> Haihao
>
>
___
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] qsv: Update ffmpeg qsv_errors to recognize GPU hang and other statuses
GPU hang is one of the most typical errors on Intel GPUs in
case something goes wrong. It's important to recognize it
explicitly for easier bugs triage. Also, this error code
can be used to trigger GPU recovery path in self-written
applications.
There were 2 other statuses which MediaSDK can ppotentially return,
MFX_ERR_NONE_PARTIAL_OUTPUT and MFX_ERR_REALLOC_SURFACE. Adding
them as well.
Signed-off-by: Hon Wai Chow
Signed-off-by: Dmitry Rogozhkin
---
libavcodec/qsv.c | 5 +
libavfilter/qsvvpp.c | 5 +
2 files changed, 10 insertions(+)
diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 385b43b..70918b1 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -105,6 +105,9 @@ static const struct {
const char *desc;
} qsv_errors[] = {
{ MFX_ERR_NONE, 0, "success"
},
+#if QSV_VERSION_ATLEAST(1, 31)
+{ MFX_ERR_NONE_PARTIAL_OUTPUT, 0, "partial output"
},
+#endif
{ MFX_ERR_UNKNOWN, AVERROR_UNKNOWN, "unknown error"
},
{ MFX_ERR_NULL_PTR, AVERROR(EINVAL), "NULL pointer"
},
{ MFX_ERR_UNSUPPORTED, AVERROR(ENOSYS), "unsupported"
},
@@ -125,6 +128,8 @@ static const struct {
{ MFX_ERR_INVALID_VIDEO_PARAM, AVERROR(EINVAL), "invalid video
parameters" },
{ MFX_ERR_UNDEFINED_BEHAVIOR, AVERROR_BUG, "undefined behavior"
},
{ MFX_ERR_DEVICE_FAILED,AVERROR(EIO),"device failed"
},
+{ MFX_ERR_GPU_HANG, AVERROR(EIO),"GPU Hang"
},
+{ MFX_ERR_REALLOC_SURFACE, AVERROR_UNKNOWN, "need bigger surface
for output" },
{ MFX_ERR_INCOMPATIBLE_AUDIO_PARAM, AVERROR(EINVAL), "incompatible audio
parameters"},
{ MFX_ERR_INVALID_AUDIO_PARAM, AVERROR(EINVAL), "invalid audio
parameters" },
diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
index 954f882..2f0613f 100644
--- a/libavfilter/qsvvpp.c
+++ b/libavfilter/qsvvpp.c
@@ -80,6 +80,9 @@ static const struct {
const char *desc;
} qsv_errors[] = {
{ MFX_ERR_NONE, 0, "success"
},
+#if QSV_VERSION_ATLEAST(1, 31)
+{ MFX_ERR_NONE_PARTIAL_OUTPUT, 0, "partial output"
},
+#endif
{ MFX_ERR_UNKNOWN, AVERROR_UNKNOWN, "unknown error"
},
{ MFX_ERR_NULL_PTR, AVERROR(EINVAL), "NULL pointer"
},
{ MFX_ERR_UNSUPPORTED, AVERROR(ENOSYS), "unsupported"
},
@@ -100,6 +103,8 @@ static const struct {
{ MFX_ERR_INVALID_VIDEO_PARAM, AVERROR(EINVAL), "invalid video
parameters" },
{ MFX_ERR_UNDEFINED_BEHAVIOR, AVERROR_BUG, "undefined behavior"
},
{ MFX_ERR_DEVICE_FAILED,AVERROR(EIO),"device failed"
},
+{ MFX_ERR_GPU_HANG, AVERROR(EIO),"GPU Hang"
},
+{ MFX_ERR_REALLOC_SURFACE, AVERROR_UNKNOWN, "need bigger surface
for output" },
{ MFX_ERR_INCOMPATIBLE_AUDIO_PARAM, AVERROR(EINVAL), "incompatible audio
parameters"},
{ MFX_ERR_INVALID_AUDIO_PARAM, AVERROR(EINVAL), "invalid audio
parameters" },
--
1.8.3.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] avdevice/xcbgrab: allow window resizing
Problem: While grabbing a window, if that window is resized the pipeline does not follow the new size. Solution: Make xbcgrab follow the windows geometry by reinitializing the stream. The stream reinit asked for the SHM removal due to memory leak. Aline Gondim Santos, Software Developer - Montreal, QC Savoir-faire Linux inc. Contactez moi sur [ https://jami.net/ | Jami ] : alinegsantos ou au (514) 276-5468 ext. 138 0001-avdevice-xcbgrab-allow-window-resizing.patch Description: application/mbox ___ 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 v5 00/25] Subtitle Filtering 2022
Ronald S. Bultje (12022-07-25): > We still do this, but currently outside FFmpeg (dav1d). So sadly, it's a > bit more out of the sphere of this mailinglist. So we take risks, and if > AV2-9 comes around, we might again. But we still consider ourselves part of > the FFmpeg community, and I still try to review ffvp9 patches when they > come up every once in a while. Don't lose hope, just find the positive > things and work on them. Ignore the rest. I know I did. I'm having fun > again. > > I don't know if I should offer advice, but my $.02: maybe adding tests (I > don't mean ffmpeg invocations; some people would call this desired > outcomes) might help here. You probably remember how Michael tested patches > pre-FATE: for a particular patch, he'd send an FFmpeg commandline that > either A) gives (undesirable) different output before vs. after patch, or > B) should give some correct/desired output after the patch but (still) > doesn't (and this second would be what I'm inviting you to do). Tests don't > have to be scripted, they can simply be a list of features or behaviors > desired in the new design. It's true that perfection is the enemy of > progress, but I think you're right that we should try to strive for further > improvement if it is within reach, especially for base design or things > with API implications. (FFmpeg's API is a testament to poor design in some > places.) You're likely better at making a comprehensive list than anyone > else. Making the list public/explicit means other people can help > accomplish the full list of features. Thank you for these kind and encouraging words. The fact that the new developments happen in separate project kinds of confirms my impression that the project has become afraid of taking risks. It makes me think of these artists who found a rich patron and, dazzled by the money and luxury, become afraid of offending them and have their art lose its edge. FFmpeg is so eager to please our corporate users, to look “serious”, to look “professional” that sometimes it almost feels like grovelling, and it stifles novelty. Another symptom of this I see is that Michael spends most of his time managing releases and fuzzing and fixing trivial bugs, tasks that are way below his skills and talent, instead of writing new code. Or maybe I am just wrong and that is what he likes to do most. As for me… I am not good at shaving cycles from inner loops, which is the heart of FFmpeg's superiority, I cannot contribute to it. What I think I can contribute (and thank you for suggesting I am not wrong) is in areas of API and architecture. Unfortunately, while support for a new codec or optimization on an existing one will receive no objection on principle, work on API or architecture affect everybody and therefore is subject to much more discussion, possibly to the point of deadly bikeshedding or outright rejection. That makes it hard to invest time in it without some kind of a-priori assurance. Unfortunately my attempts to spark discussions have been met with indifference: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274167.html https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/thread.html#274167 (I realize I could probably work on internal error messages. As for event loop, the other one that has received positive feedback, I was trying to find a more efficient way out of a small quandary, I should probably go back to it.) Or even worse: https://ffmpeg.org/pipermail/ffmpeg-devel/2021-December/290226.html https://ffmpeg.org/pipermail/ffmpeg-devel/2021-December/thread.html#290226 (A good string API is a pre-requisite for several other projects.) What I think this project need is a leader, or a leading committee: somebody who can decide beforehand if a change in API or architecture is worth it, and therefore worth the time of the developer, with a decision that is binding to the project: when the code is written, other developers may discuss technical details but not reject the change itself. Maybe the technical committee could endorse this role, even though it was not exactly why it was elected. Thanks, -- Nicolas George 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".
Re: [FFmpeg-devel] [PATCH v1] ffmpeg: add optional JSON output of inputs, outputs, mapping, and progress
> On 9 Jun 2022, at 14:47, Ingo Oppermann wrote:
>
> In order to make a running ffmpeg process easier to monitor and parse by
> programs that call the ffmpeg binary and process its output, this patch adds
> the command line option -jsonstats. This option is a modifier for the
> (no)stats option which provides a more verbose output in JSON format than the
> default output. It enables the additional output of the input streams,
> their mapping to the outputs (including the filter graphs), and the output
> streams as JSON. Each output is on a single line and is prefixed with
> "json.inputs:", "json.mapping:", and "json.outputs:" respectively, followed by
> the JSON data. The -jsonstats option is disabled by default.
>
> The inputs and outputs are arrays and for each input and output stream, the
> information in the JSON is similar to the default dump of the inputs and
> outputs.
>
> The stream mapping includes an array of the filter graphs and a mapping
> representation similar to the output from to graph2dot.c program.
>
> The current progress report is replaced by a JSON representation which is
> prefixed with "json.progress:" followed by JSON data, and each report will be
> on a new line. The progress data contains values similar to the default data
> for each input and output stream and a summary.
>
> Together with the -progress option, the described JSON data instead of the
> default data will be written to the provided target.
>
> Signed-off-by: Ingo Oppermann
> ---
> doc/ffmpeg.texi | 10 ++
> fftools/ffmpeg.c | 198 +++-
> fftools/ffmpeg.h | 1 +
> fftools/ffmpeg_mux.c | 307 +++
> fftools/ffmpeg_opt.c | 115
> 5 files changed, 629 insertions(+), 2 deletions(-)
>
> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> index 0d7e1a479d..16fcd9970a 100644
> --- a/doc/ffmpeg.texi
> +++ b/doc/ffmpeg.texi
> @@ -784,6 +784,13 @@ disable it you need to specify @code{-nostats}.
> @item -stats_period @var{time} (@emph{global})
> Set period at which encoding progress/statistics are updated. Default is 0.5
> seconds.
>
> +@item -jsonstats (@emph{global})
> +Print inputs, outputs, stream mapping, and encoding progress/statistics. It
> is off by
> +default. It modifies the output of @code{-stats} to be JSON. The inputs,
> outputs,
> +stream mapping, and progress information are written on one line and are
> prefixed
> +with @var{json.inputs:}, @var{json.outputs:}, @var{json.mapping:}, and
> @var{json.progress:}
> +respectively followed by the JSON data.
> +
> @item -progress @var{url} (@emph{global})
> Send program-friendly progress information to @var{url}.
>
> @@ -792,6 +799,9 @@ the encoding process. It is made of
> "@var{key}=@var{value}" lines. @var{key}
> consists of only alphanumeric characters. The last key of a sequence of
> progress information is always "progress".
>
> +If @code{-jsonstats} is enabled, the progress information is written as JSON
> with
> +the prefixes and data
> +
> The update period is set using @code{-stats_period}.
>
> @anchor{stdin option}
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 5ed287c522..eea1491ed1 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -1505,7 +1505,7 @@ static void print_final_stats(int64_t total_size)
> }
> }
>
> -static void print_report(int is_last_report, int64_t timer_start, int64_t
> cur_time)
> +static void print_default_report(int is_last_report, int64_t timer_start,
> int64_t cur_time)
> {
> AVBPrint buf, buf_script;
> OutputStream *ost;
> @@ -1695,7 +1695,7 @@ static void print_report(int is_last_report, int64_t
> timer_start, int64_t cur_ti
> }
> av_bprint_finalize(&buf, NULL);
>
> -if (progress_avio) {
> +if (progress_avio && !print_jsonstats) {
> av_bprintf(&buf_script, "progress=%s\n",
>is_last_report ? "end" : "continue");
> avio_write(progress_avio, buf_script.str,
> @@ -1715,6 +1715,200 @@ static void print_report(int is_last_report, int64_t
> timer_start, int64_t cur_ti
> print_final_stats(total_size);
> }
>
> +/**
> + * Print progress report in JSON format
> + *
> + * @param is_last_report Whether this is the last report
> + * @param timer_start Time when the processing started
> + * @param cur_time Current processing time of the stream
> + */
> +static void print_json_report(int is_last_report, int64_t timer_start,
> int64_t cur_time)
> +{
> +AVBPrint buf;
> +InputStream *ist;
> +OutputStream *ost;
> +uint64_t stream_size, total_packets = 0, total_size = 0;
> +AVCodecContext *enc;
> +int i, j;
> +double speed;
> +int64_t pts = INT64_MIN + 1;
> +static int first_report = 1;
> +static int64_t last_time = -1;
> +int hours, mins, secs, us;
> +const char *hours_sign;
> +float t, q;
> +
> +if (!is_last_report) {
> +if (last_time == -1) {
> +last_time = cur_time;
Re: [FFmpeg-devel] [PATCH v5 00/25] Subtitle Filtering 2022
Michael Niedermayer (12022-07-25): > I think many if us, myself included have had un-fun periods in ffmpeg. > This on its own is already bad and we should strive to make project > contributions more fun to all. In my opinion, it would require at least two things: - That the members of the Community Committee step in more proactively in budding conflicts. And take sides: not “both be nice” but “you started it, shut up”. - A person or group of person capable of deciding ahead if a change that will affect every body is worth investing time implementing it. > If we add a XML parser to FFmpeg. Such a thing would be used by several > bits and we need to ensure it has redundant maintainership. > So i think a xml parser needs broad support by developers otherwise we > run the risk that if it has a single maintainer only and that maintainer > stops maintaining it that could be annoying to more than just the parser > itself. > I cannot remember exactly without re-reading the old thread what the issues > people had with the xml parser. If it was some component of it or in general. > But i think its mostly a question if theres more than one person who wants > to maintain it. There is nothing to re-read: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/thread.html#296107 Nobody answered. Even to send files to make sure they would be supported. We would need reliable maintainers, you are right. But right now, we rely on libxml2, and that is not ideal: it is not a standard library on non-Linux systems, and even if it seems better nowadays, it used to be a “security issue of the week” kind of library. > If you work on libavfilter, noone will snatch it from you. If you > dont work on it, eventually someone else will attempt to take over and > push libavfilter in the direction he feels best which may or may not > match what you want. I will try to motivate myself to advance the FATE coverage, which is the blocking issue. Thanks, -- Nicolas George 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".
Re: [FFmpeg-devel] [PATCH v5 00/25] Subtitle Filtering 2022
On Mon, Jul 25, 2022 at 09:01:03PM +0200, Nicolas George wrote: [...] > > If we add a XML parser to FFmpeg. Such a thing would be used by several > > bits and we need to ensure it has redundant maintainership. > > So i think a xml parser needs broad support by developers otherwise we > > run the risk that if it has a single maintainer only and that maintainer > > stops maintaining it that could be annoying to more than just the parser > > itself. > > I cannot remember exactly without re-reading the old thread what the issues > > people had with the xml parser. If it was some component of it or in > > general. > > But i think its mostly a question if theres more than one person who wants > > to maintain it. > > There is nothing to re-read: > > https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/thread.html#296107 > > Nobody answered. Even to send files to make sure they would be > supported. that says "WIP" in the subject. I think some people when they see WIP they skip it and wait for a final version to review. thx [...] -- 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: 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".
Re: [FFmpeg-devel] [PATCH 14/18] avcodec/hevcdec: Don't allocate redundant HEVCContexts
On Sun, Jul 24, 2022 at 11:26:37PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Sat, Jul 23, 2022 at 11:42:23PM +0200, Andreas Rheinhardt wrote:
> >> Michael Niedermayer:
> >>> On Sat, Jul 23, 2022 at 07:44:40AM +0200, Andreas Rheinhardt wrote:
> Andreas Rheinhardt:
> > Michael Niedermayer:
> >> On Sat, Jul 02, 2022 at 08:32:06AM +0200, Andreas Rheinhardt wrote:
> >>> Michael Niedermayer:
> On Fri, Jul 01, 2022 at 12:29:45AM +0200, Andreas Rheinhardt wrote:
> > The HEVC decoder has both HEVCContext and HEVCLocalContext
> > structures. The latter is supposed to be the structure
> > containing the per-slicethread state.
> >
> > Yet up until now that is not how it is handled in practice:
> > Each HEVCLocalContext has a unique HEVCContext allocated for it
> > and each of these coincides except in exactly one field: The
> > corresponding HEVCLocalContext. This makes it possible to pass
> > the HEVCContext everywhere where logically a HEVCLocalContext
> > should be used. And up until recently, this is how it has been done.
> >
> > Yet the preceding patches changed this, making it possible
> > to avoid allocating redundant HEVCContexts.
> >
> > Signed-off-by: Andreas Rheinhardt
> > ---
> > libavcodec/hevcdec.c | 40
> > libavcodec/hevcdec.h | 2 --
> > 2 files changed, 16 insertions(+), 26 deletions(-)
> >
> > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> > index 9d1241f293..048fcc76b4 100644
> > --- a/libavcodec/hevcdec.c
> > +++ b/libavcodec/hevcdec.c
> > @@ -2548,13 +2548,12 @@ static int
> > hls_decode_entry_wpp(AVCodecContext *avctxt, void *hevc_lclist,
> > {
> > HEVCLocalContext *lc =
> > ((HEVCLocalContext**)hevc_lclist)[self_id];
> > const HEVCContext *const s = lc->parent;
> > -HEVCContext *s1 = avctxt->priv_data;
> > -int ctb_size= 1<< s1->ps.sps->log2_ctb_size;
> > +int ctb_size= 1 << s->ps.sps->log2_ctb_size;
> > int more_data = 1;
> > int ctb_row = job;
> > -int ctb_addr_rs = s1->sh.slice_ctb_addr_rs + ctb_row *
> > ((s1->ps.sps->width + ctb_size - 1) >> s1->ps.sps->log2_ctb_size);
> > -int ctb_addr_ts = s1->ps.pps->ctb_addr_rs_to_ts[ctb_addr_rs];
> > -int thread = ctb_row % s1->threads_number;
> > +int ctb_addr_rs = s->sh.slice_ctb_addr_rs + ctb_row *
> > ((s->ps.sps->width + ctb_size - 1) >> s->ps.sps->log2_ctb_size);
> > +int ctb_addr_ts = s->ps.pps->ctb_addr_rs_to_ts[ctb_addr_rs];
> > +int thread = ctb_row % s->threads_number;
> > int ret;
> >
> > if(ctb_row) {
> > @@ -2572,7 +2571,7 @@ static int
> > hls_decode_entry_wpp(AVCodecContext *avctxt, void *hevc_lclist,
> >
> > ff_thread_await_progress2(s->avctx, ctb_row, thread,
> > SHIFT_CTB_WPP);
> >
> > -if (atomic_load(&s1->wpp_err)) {
> > +if (atomic_load(&s->wpp_err)) {
> > ff_thread_report_progress2(s->avctx, ctb_row , thread,
> > SHIFT_CTB_WPP);
>
> the consts in "const HEVCContext *const " make clang version
> 6.0.0-1ubuntu2 unhappy
> (this was building shared libs)
>
>
> CC libavcodec/hevcdec.o
> src/libavcodec/hevcdec.c:2574:13: error: address argument to atomic
> operation must be a pointer to non-const _Atomic type ('const
> atomic_int *' (aka 'const _Atomic(int) *') invalid)
> if (atomic_load(&s->wpp_err)) {
> ^ ~~~
> /usr/lib/llvm-6.0/lib/clang/6.0.0/include/stdatomic.h:134:29: note:
> expanded from macro 'atomic_load'
> #define atomic_load(object) __c11_atomic_load(object,
> __ATOMIC_SEQ_CST)
> ^ ~~
> 1 error generated.
> src/ffbuild/common.mak:81: recipe for target 'libavcodec/hevcdec.o'
> failed
> make: *** [libavcodec/hevcdec.o] Error 1
>
> thx
>
> >>>
> >>> Thanks for testing this. atomic_load is indeed declared without const
> >>> in
> >>> 7.17.7.2:
> >>>
> >>> C atomic_load(volatile A *object);
> >>>
> >>> Upon reflection this makes sense, because if atomics are implemented
> >>> via
> >>> mutexes, even a read may involve a preceding write. So I'll cast const
> >>> away here, too, and add a comment. (It works when casting const away,
> >>> doesn't it?)
> >>
> >> This doesnt feel "right". These pointers s
Re: [FFmpeg-devel] [PATCH 14/18] avcodec/hevcdec: Don't allocate redundant HEVCContexts
Michael Niedermayer:
> On Sun, Jul 24, 2022 at 11:26:37PM +0200, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> On Sat, Jul 23, 2022 at 11:42:23PM +0200, Andreas Rheinhardt wrote:
Michael Niedermayer:
> On Sat, Jul 23, 2022 at 07:44:40AM +0200, Andreas Rheinhardt wrote:
>> Andreas Rheinhardt:
>>> Michael Niedermayer:
On Sat, Jul 02, 2022 at 08:32:06AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
>> On Fri, Jul 01, 2022 at 12:29:45AM +0200, Andreas Rheinhardt wrote:
>>> The HEVC decoder has both HEVCContext and HEVCLocalContext
>>> structures. The latter is supposed to be the structure
>>> containing the per-slicethread state.
>>>
>>> Yet up until now that is not how it is handled in practice:
>>> Each HEVCLocalContext has a unique HEVCContext allocated for it
>>> and each of these coincides except in exactly one field: The
>>> corresponding HEVCLocalContext. This makes it possible to pass
>>> the HEVCContext everywhere where logically a HEVCLocalContext
>>> should be used. And up until recently, this is how it has been done.
>>>
>>> Yet the preceding patches changed this, making it possible
>>> to avoid allocating redundant HEVCContexts.
>>>
>>> Signed-off-by: Andreas Rheinhardt
>>> ---
>>> libavcodec/hevcdec.c | 40
>>> libavcodec/hevcdec.h | 2 --
>>> 2 files changed, 16 insertions(+), 26 deletions(-)
>>>
>>> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
>>> index 9d1241f293..048fcc76b4 100644
>>> --- a/libavcodec/hevcdec.c
>>> +++ b/libavcodec/hevcdec.c
>>> @@ -2548,13 +2548,12 @@ static int
>>> hls_decode_entry_wpp(AVCodecContext *avctxt, void *hevc_lclist,
>>> {
>>> HEVCLocalContext *lc =
>>> ((HEVCLocalContext**)hevc_lclist)[self_id];
>>> const HEVCContext *const s = lc->parent;
>>> -HEVCContext *s1 = avctxt->priv_data;
>>> -int ctb_size= 1<< s1->ps.sps->log2_ctb_size;
>>> +int ctb_size= 1 << s->ps.sps->log2_ctb_size;
>>> int more_data = 1;
>>> int ctb_row = job;
>>> -int ctb_addr_rs = s1->sh.slice_ctb_addr_rs + ctb_row *
>>> ((s1->ps.sps->width + ctb_size - 1) >> s1->ps.sps->log2_ctb_size);
>>> -int ctb_addr_ts = s1->ps.pps->ctb_addr_rs_to_ts[ctb_addr_rs];
>>> -int thread = ctb_row % s1->threads_number;
>>> +int ctb_addr_rs = s->sh.slice_ctb_addr_rs + ctb_row *
>>> ((s->ps.sps->width + ctb_size - 1) >> s->ps.sps->log2_ctb_size);
>>> +int ctb_addr_ts = s->ps.pps->ctb_addr_rs_to_ts[ctb_addr_rs];
>>> +int thread = ctb_row % s->threads_number;
>>> int ret;
>>>
>>> if(ctb_row) {
>>> @@ -2572,7 +2571,7 @@ static int
>>> hls_decode_entry_wpp(AVCodecContext *avctxt, void *hevc_lclist,
>>>
>>> ff_thread_await_progress2(s->avctx, ctb_row, thread,
>>> SHIFT_CTB_WPP);
>>>
>>> -if (atomic_load(&s1->wpp_err)) {
>>> +if (atomic_load(&s->wpp_err)) {
>>> ff_thread_report_progress2(s->avctx, ctb_row , thread,
>>> SHIFT_CTB_WPP);
>>
>> the consts in "const HEVCContext *const " make clang version
>> 6.0.0-1ubuntu2 unhappy
>> (this was building shared libs)
>>
>>
>> CC libavcodec/hevcdec.o
>> src/libavcodec/hevcdec.c:2574:13: error: address argument to atomic
>> operation must be a pointer to non-const _Atomic type ('const
>> atomic_int *' (aka 'const _Atomic(int) *') invalid)
>> if (atomic_load(&s->wpp_err)) {
>> ^ ~~~
>> /usr/lib/llvm-6.0/lib/clang/6.0.0/include/stdatomic.h:134:29: note:
>> expanded from macro 'atomic_load'
>> #define atomic_load(object) __c11_atomic_load(object,
>> __ATOMIC_SEQ_CST)
>> ^ ~~
>> 1 error generated.
>> src/ffbuild/common.mak:81: recipe for target 'libavcodec/hevcdec.o'
>> failed
>> make: *** [libavcodec/hevcdec.o] Error 1
>>
>> thx
>>
>
> Thanks for testing this. atomic_load is indeed declared without const
> in
> 7.17.7.2:
>
> C atomic_load(volatile A *object);
>
> Upon reflection this makes sense, because if atomics are implemented
> via
> mutexes, even a read may involve a preceding write. So I'll cast const
> away here, too, and add a comment. (It works when casting const away,
> doesn't it?)
This doesnt feel "
Re: [FFmpeg-devel] [PATCH] fate/imf: Rename IMF fate-target
LGTM. On Sun, Jul 24, 2022 at 9:43 PM Andreas Rheinhardt wrote: > > It conflicts with the name of the test using the testtool > in libavformat.mak. > > Fixes ticket #9841. > > Signed-off-by: Andreas Rheinhardt > --- > Other naming suggestions welcome. > > tests/fate/imf.mak | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/fate/imf.mak b/tests/fate/imf.mak > index 70a3efdfbd..feb54d1361 100644 > --- a/tests/fate/imf.mak > +++ b/tests/fate/imf.mak > @@ -3,4 +3,4 @@ fate-imf-cpl-with-repeat: CMD = framecrc -f imf -i > $(TARGET_SAMPLES)/imf/countdo > > FATE_SAMPLES_FFMPEG-$(CONFIG_IMF_DEMUXER) += $(FATE_IMF) > > -fate-imf: $(FATE_IMF) > +fate-imfdec: $(FATE_IMF) > -- > 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 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 v3 1/2] avformat: refactor ff_stream_encode_params_copy() to ff_stream_params_copy()
p...@sandflow.com:
> From: Pierre-Anthony Lemieux
>
> As discussed at
> https://ffmpeg.org/pipermail/ffmpeg-devel/2022-July/298491.html.
> Note that ff_stream_params_copy() does not copy the index field, which is
> usually set by avformat_new_stream().
>
> ---
> libavformat/avformat.c | 37 +
> libavformat/fifo.c | 2 +-
> libavformat/internal.h | 10 ++
> libavformat/mux.h| 9 -
> libavformat/mux_utils.c | 28
> libavformat/segment.c| 2 +-
> libavformat/tee.c| 2 +-
> libavformat/webm_chunk.c | 2 +-
> 8 files changed, 51 insertions(+), 41 deletions(-)
>
> diff --git a/libavformat/avformat.c b/libavformat/avformat.c
> index 30d6ea6a49..c426dbfa45 100644
> --- a/libavformat/avformat.c
> +++ b/libavformat/avformat.c
> @@ -235,6 +235,43 @@ int ff_stream_side_data_copy(AVStream *dst, const
> AVStream *src)
> return 0;
> }
>
> +int ff_stream_params_copy(AVStream *dst, const AVStream *src)
> +{
> +int ret;
> +
> +dst->id = src->id;
> +dst->time_base = src->time_base;
> +dst->start_time = src->start_time;
> +dst->duration= src->duration;
> +dst->nb_frames = src->nb_frames;
> +dst->disposition = src->disposition;
> +dst->discard = src->discard;
> +dst->sample_aspect_ratio = src->sample_aspect_ratio;
> +dst->avg_frame_rate = src->avg_frame_rate;
> +dst->event_flags = src->event_flags;
> +dst->r_frame_rate= src->r_frame_rate;
> +dst->pts_wrap_bits = src->pts_wrap_bits;
> +
> +av_dict_free(&dst->metadata);
> +ret = av_dict_copy(&dst->metadata, src->metadata, 0);
> +if (ret < 0)
> +return ret;
> +
> +ret = avcodec_parameters_copy(dst->codecpar, src->codecpar);
> +if (ret < 0)
> +return ret;
> +
> +ret = ff_stream_side_data_copy(dst, src);
> +if (ret < 0)
> +return ret;
> +
> +ret = av_packet_ref(&dst->attached_pic, &src->attached_pic);
This will allocate a buffer of size AV_INPUT_BUFFER_PADDING_SIZE in
dst->attached_pic (and set the size of the data of said packet to 0) if
the size of the data of src->attached_pic is zero (in particular, if it
is truely blank). This is not desired.
> +if (ret < 0)
> +return ret;
> +
> +return 0;
> +}
> +
> AVProgram *av_new_program(AVFormatContext *ac, int id)
> {
> AVProgram *program = NULL;
> diff --git a/libavformat/fifo.c b/libavformat/fifo.c
> index ead2bdc5cf..fef116d040 100644
> --- a/libavformat/fifo.c
> +++ b/libavformat/fifo.c
> @@ -509,7 +509,7 @@ static int fifo_mux_init(AVFormatContext *avf, const
> AVOutputFormat *oformat,
> if (!st)
> return AVERROR(ENOMEM);
>
> -ret = ff_stream_encode_params_copy(st, avf->streams[i]);
> +ret = ff_stream_params_copy(st, avf->streams[i]);
> if (ret < 0)
> return ret;
> }
> diff --git a/libavformat/internal.h b/libavformat/internal.h
> index b6b8fbf56f..774ff57698 100644
> --- a/libavformat/internal.h
> +++ b/libavformat/internal.h
> @@ -625,6 +625,16 @@ enum AVCodecID ff_get_pcm_codec_id(int bps, int flt, int
> be, int sflags);
> */
> int ff_stream_side_data_copy(AVStream *dst, const AVStream *src);
>
> +/**
> + * Copy all stream parameters from source to destination stream, with the
> + * exception of the index field, which is usually set by
> avformat_new_stream().
> + *
> + * @param dst pointer to destination AVStream
> + * @param src pointer to source AVStream
> + * @return >=0 on success, AVERROR code on error
> + */
> +int ff_stream_params_copy(AVStream *dst, const AVStream *src);
> +
> /**
> * Wrap ffurl_move() and log if error happens.
> *
> diff --git a/libavformat/mux.h b/libavformat/mux.h
> index c01da82194..1bfcaf795f 100644
> --- a/libavformat/mux.h
> +++ b/libavformat/mux.h
> @@ -113,15 +113,6 @@ int ff_format_shift_data(AVFormatContext *s, int64_t
> read_start, int shift_size)
> */
> int ff_format_output_open(AVFormatContext *s, const char *url, AVDictionary
> **options);
>
> -/**
> - * Copy encoding parameters from source to destination stream
> - *
> - * @param dst pointer to destination AVStream
> - * @param src pointer to source AVStream
> - * @return >=0 on success, AVERROR code on error
> - */
> -int ff_stream_encode_params_copy(AVStream *dst, const AVStream *src);
> -
> /**
> * Parse creation_time in AVFormatContext metadata if exists and warn if the
> * parsing fails.
> diff --git a/libavformat/mux_utils.c b/libavformat/mux_utils.c
> index eb8ea3d560..2fa2ab5b0f 100644
> --- a/libavformat/mux_utils.c
> +++ b/libavformat/mux_utils.c
> @@ -121,34 +121,6 @@ int ff_format_output_open(AVFormatContext *s, const char
> *url, AVDictionary **op
> return 0;
> }
>
> -int ff_stream_encode_params_copy(AVStream *dst, const AVStream *src)
> -{
> -int ret;
> -
>
