Re: [FFmpeg-devel] [PATCH v4] area changed: scdet filter
On 13/06/2024 20:16, radu.taraib...@gmail.com wrote: Update as discussed The mode options are fine to me, will leave the implementation check and final push to Michael. (Only if you update the patch anyway I'd suggest rewording the commit message to rephrase the "legacy" mode there, too, and maybe a more common patch title line like "avfilter/scdet: add improved detection modes". But no need to resend the patch for such cosmetics only.) Regards, Tobias ___ 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] area changed: scdet filter
On 13/06/2024 13:21, radu.taraib...@gmail.com wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Tobias
Rapp
Sent: joi, 13 iunie 2024 12:52
To:ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v3] area changed: scdet filter
On 12/06/2024 21:51,radu.taraib...@gmail.com wrote:
[...]
diff --git a/doc/filters.texi b/doc/filters.texi index
bfa8ccec8b..53814e003b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -21797,6 +21797,22 @@ Default value is @code{10.}.
@item sc_pass, s
Set the flag to pass scene change frames to the next filter. Default
value is @code{0}
You can enable it if you want to get snapshot of scene change frames
only.
+
+@item mode
+Set the scene change detection method. Default value is @code{-1}
+Available values are:
+
+@table @samp
+@item -1
+Legacy mode for sum of absolute linear differences. Compare frame
with previous only and no delay.
+
+@item 0
+Sum of absolute linear differences. Compare frame with both previous
and next which introduces a 1 frame delay.
+
+@item 1
+Sum of mean of cubic root differences. Compare frame with both
previous and next which introduces a 1 frame delay.
+
+@end table
@end table
@anchor{selectivecolor}
Out of curiosity: How do these three modes roughly compare (CPU)
performance wise?
Mode -1 is virtually equal with mode 0 (no frame clone speedup of mode 0 is
mostly theoretical). Mode 1 is roughly 40% slower, depending on input, it could
benefit from ASM.
I'd prefer if mode "-1" could be used for the default case, and the three modes
get explicit values 0/1/2.
So you want four possible values for mode where the default -1 is the same as
one of the others?
Yes. This pattern is also used for the "shaping" option of the ass
filter, for example.It allows users to make it explicit that the filter
should choose a default (which may vary between versions).
Regarding naming I think that the "Legacy" mode still
has its usecases in the future. Naming it something like "simple" would not
imply that it is deprecated in general, but rather that it has lower precision
(and is possibly faster).
OK, I will rename "Legacy" mode so it doesn't look deprecated to somebody that
can't allow 1 frame delay. Otherwise it shouldn't be used.
Thanks.
Regards, Tobias
___
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] area changed: scdet filter
On 12/06/2024 21:51, radu.taraib...@gmail.com wrote:
[...]
diff --git a/doc/filters.texi b/doc/filters.texi
index bfa8ccec8b..53814e003b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -21797,6 +21797,22 @@ Default value is @code{10.}.
@item sc_pass, s
Set the flag to pass scene change frames to the next filter. Default
value is @code{0}
You can enable it if you want to get snapshot of scene change frames
only.
+
+@item mode
+Set the scene change detection method. Default value is @code{-1}
+Available values are:
+
+@table @samp
+@item -1
+Legacy mode for sum of absolute linear differences. Compare frame
with previous only and no delay.
+
+@item 0
+Sum of absolute linear differences. Compare frame with both previous
and next which introduces a 1 frame delay.
+
+@item 1
+Sum of mean of cubic root differences. Compare frame with both
previous and next which introduces a 1 frame delay.
+
+@end table
@end table
@anchor{selectivecolor}
Out of curiosity: How do these three modes roughly compare (CPU)
performance wise?
I'd prefer if mode "-1" could be used for the default case, and the
three modes get explicit values 0/1/2. Regarding naming I think that the
"Legacy" mode still has its usecases in the future. Naming it something
like "simple" would not imply that it is deprecated in general, but
rather that it has lower precision (and is possibly faster).
Best regards,
Tobias
___
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] Massive memory leak in 6.1.1 (fixed on master)
On 01/05/2024 18:52, Ville Syrjälä wrote: [...] So those should be cherry-picked to the next 6.1 release (assuming there will be one). Both cherry-pick cleanly, and afterwards the leak is gone from the 6.1 branch as well. From the release/6.1 branch it seems that a 6.1.2 release has been prepared by Michael in commit 9593b727e2751e5a79be86a7327a98f3422fa505 but not tagged yet. Regards, Tobias ___ 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] Inconsistent usage of AVFieldOrder values
On 25/04/2024 00:42, Marton Balint wrote: On Mon, 22 Apr 2024, Devin Heitmueller wrote: Hello, I suspect this topic has been visited a number of times over the years, but I figured I should re-raise it. In the compressed domain, field ordering is represented by the AVFieldOrder enumeration. Among the interlaced possibilities, you've got four combinations: AV_FIELD_TT, AV_FIELD_BB, AV_FIELD_TB, AV_FIELD_BT. The last two characters indicate the coding and display order respectively. That is how it is documented, but likely it is not how it actually works. The whole mess is originated from the QuickTime specification which contradicts with an Apple technical note. See this discussion: https://sourceforge.net/p/mediainfo/bugs/841/ Recently I also stumbled over this when using the FFmpeg Matroska muxer. Found some discussion around the interpretation of the QuickTime spec in https://github.com/amiaopensource/vrecord/issues/170#issuecomment-321937668 and http://trac.ffmpeg.org/ticket/6577#ticket. Long story short, AV_FIELD_TB means top field first in practice, AV_FIELD_BT means bottom field first in practice. I think most of the code follows this interpretation, and not the actual documentation. AV_FIELD_BB and AV_FIELD_TT tries to signal field order for separate field encodings, but quite possibly sometimes (mis)used for ordinary field order signalling as well... As I understand it the FFmpeg enum definitions follow the original (wrong) QuickTime spec wording. The actual usage in code then sometimes follows the documentation text (coded vs. displayed timing), and in other cases uses the enum to indicate field storage (interlaced vs. separate). I guess my question is: if I submit patches which fix such cases where I find them, will they be rejected because they are a change in behavior and might very well break existing applications that expect the incorrect values? I would like the libraries to report the correct values in a consistent manner, but I recognize this may cause some breakage in existing applications. Making changes out of the blue likely won't be acceptable. If a justified plan is presented to untangle this, then maybe *some* breakage is acceptable, but I don't honestly know. Some random ideas: - Consider fixing the documentation (and the textual description of the field orders) instead of changing behaviour. - Try to collect commercial samples and see what they contain for TFF/BFF content, separete fields or interleaved, compressed or uncompressed. - Go over the codebase and see which component is using which interpretation in practice, make a list, see if there is a significant majority... I agree that fixing the mess would require some effort to clarify for each context (codec, muxer) where the AVFieldOrder enum is used what the interpretation is with different third-party applications, and whether it matches its own spec or not. Only relying on specs would not be enough, as the incorrect wording from QuickTime could be copied (see Matroska) but not used in practice. It would be nice, though, to get the confusing "bottom coded first (swapped)" log message fixed into "top first (interlaced)"! Regards, Tobias ___ 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 2/2] examples/decode_filter_video: Add loop for draining the filtergraph
On 27/03/2024 14:04, Tobias Rapp wrote:
On 27/03/2024 13:53, Anton Khirnov wrote:
Quoting Tobias Rapp (2024-03-27 13:46:40)
On 27/03/2024 13:06, Stefano Sabatini wrote:
On date Wednesday 2024-03-27 11:51:31 +0100, Tobias Rapp wrote:
Depending on the filters used the filtergraph can produce trailing
data
after feeding it the last input frame. Update the example to
include the
necessary loop for draining the filtergrap.
Signed-off-by: Tobias Rapp
---
doc/examples/decode_filter_video.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/doc/examples/decode_filter_video.c
b/doc/examples/decode_filter_video.c
index 454c192..a57e6df 100644
--- a/doc/examples/decode_filter_video.c
+++ b/doc/examples/decode_filter_video.c
@@ -276,6 +276,25 @@ int main(int argc, char **argv)
}
av_packet_unref(packet);
}
+ if (ret == AVERROR_EOF) {
+ /* signal EOF to the filtergraph */
+ if (av_buffersrc_add_frame_flags(buffersrc_ctx, NULL, 0)
< 0) {
+ av_log(NULL, AV_LOG_ERROR, "Error while closing the
filtergraph\n");
+ goto end;
+ }
+
+ /* pull remaining frames from the filtergraph */
+ while (1) {
+ ret = av_buffersink_get_frame(buffersink_ctx,
filt_frame);
+ if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
+ break;
how are we supposed to handle the EAGAIN case? Shouldn't this be a
sleep and retry?
Good suggestion. I could add something like usleep(100) upon EAGAIN.
No, EAGAIN from a filter after EOF on all inputs is a bug.
Ok. Also from a second look at the example all the other locations
where EAGAIN is handled do not perform a retry. So adding that would
be orthogonal to this patch, IMHO.
Applied both patches. Thanks for the feedback!
Regards, Tobias
___
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] tests/audiogen: Fix total RIFF chunk size
On 26/03/2024 13:33, Tobias Rapp wrote: On 15/03/2024 09:53, Tobias Rapp wrote: The "RIFF" identifier and chunk size fields should not be included within the size value. --- tests/audiogen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/audiogen.c b/tests/audiogen.c index c43bb70..df1dea6 100644 --- a/tests/audiogen.c +++ b/tests/audiogen.c @@ -109,7 +109,7 @@ static void put32(uint32_t v) fputc((v >> 24) & 0xff, outfile); } -#define HEADER_SIZE 46 +#define HEADER_SIZE 38 #define FMT_SIZE 18 #define SAMPLE_SIZE 2 #define WFORMAT_PCM 0x0001 Will apply in two days if there are no objections. Applied. Regards, Tobias ___ 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 2/2] examples/decode_filter_video: Add loop for draining the filtergraph
On 27/03/2024 13:53, Anton Khirnov wrote:
Quoting Tobias Rapp (2024-03-27 13:46:40)
On 27/03/2024 13:06, Stefano Sabatini wrote:
On date Wednesday 2024-03-27 11:51:31 +0100, Tobias Rapp wrote:
Depending on the filters used the filtergraph can produce trailing data
after feeding it the last input frame. Update the example to include the
necessary loop for draining the filtergrap.
Signed-off-by: Tobias Rapp
---
doc/examples/decode_filter_video.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/doc/examples/decode_filter_video.c
b/doc/examples/decode_filter_video.c
index 454c192..a57e6df 100644
--- a/doc/examples/decode_filter_video.c
+++ b/doc/examples/decode_filter_video.c
@@ -276,6 +276,25 @@ int main(int argc, char **argv)
}
av_packet_unref(packet);
}
+if (ret == AVERROR_EOF) {
+/* signal EOF to the filtergraph */
+if (av_buffersrc_add_frame_flags(buffersrc_ctx, NULL, 0) < 0) {
+av_log(NULL, AV_LOG_ERROR, "Error while closing the
filtergraph\n");
+goto end;
+}
+
+/* pull remaining frames from the filtergraph */
+while (1) {
+ret = av_buffersink_get_frame(buffersink_ctx, filt_frame);
+if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
+break;
how are we supposed to handle the EAGAIN case? Shouldn't this be a
sleep and retry?
Good suggestion. I could add something like usleep(100) upon EAGAIN.
No, EAGAIN from a filter after EOF on all inputs is a bug.
Ok. Also from a second look at the example all the other locations where
EAGAIN is handled do not perform a retry. So adding that would be
orthogonal to this patch, IMHO.
Regards, Tobias
___
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 2/2] examples/decode_filter_video: Add loop for draining the filtergraph
On 27/03/2024 13:06, Stefano Sabatini wrote:
On date Wednesday 2024-03-27 11:51:31 +0100, Tobias Rapp wrote:
Depending on the filters used the filtergraph can produce trailing data
after feeding it the last input frame. Update the example to include the
necessary loop for draining the filtergrap.
Signed-off-by: Tobias Rapp
---
doc/examples/decode_filter_video.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/doc/examples/decode_filter_video.c
b/doc/examples/decode_filter_video.c
index 454c192..a57e6df 100644
--- a/doc/examples/decode_filter_video.c
+++ b/doc/examples/decode_filter_video.c
@@ -276,6 +276,25 @@ int main(int argc, char **argv)
}
av_packet_unref(packet);
}
+if (ret == AVERROR_EOF) {
+/* signal EOF to the filtergraph */
+if (av_buffersrc_add_frame_flags(buffersrc_ctx, NULL, 0) < 0) {
+av_log(NULL, AV_LOG_ERROR, "Error while closing the
filtergraph\n");
+goto end;
+}
+
+/* pull remaining frames from the filtergraph */
+while (1) {
+ret = av_buffersink_get_frame(buffersink_ctx, filt_frame);
+if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
+break;
how are we supposed to handle the EAGAIN case? Shouldn't this be a
sleep and retry?
Good suggestion. I could add something like usleep(100) upon EAGAIN.
Will post an updated 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".
[FFmpeg-devel] [PATCH 2/2] examples/decode_filter_video: Add loop for draining the filtergraph
Depending on the filters used the filtergraph can produce trailing data
after feeding it the last input frame. Update the example to include the
necessary loop for draining the filtergrap.
Signed-off-by: Tobias Rapp
---
doc/examples/decode_filter_video.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/doc/examples/decode_filter_video.c
b/doc/examples/decode_filter_video.c
index 454c192..a57e6df 100644
--- a/doc/examples/decode_filter_video.c
+++ b/doc/examples/decode_filter_video.c
@@ -276,6 +276,25 @@ int main(int argc, char **argv)
}
av_packet_unref(packet);
}
+if (ret == AVERROR_EOF) {
+/* signal EOF to the filtergraph */
+if (av_buffersrc_add_frame_flags(buffersrc_ctx, NULL, 0) < 0) {
+av_log(NULL, AV_LOG_ERROR, "Error while closing the
filtergraph\n");
+goto end;
+}
+
+/* pull remaining frames from the filtergraph */
+while (1) {
+ret = av_buffersink_get_frame(buffersink_ctx, filt_frame);
+if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
+break;
+if (ret < 0)
+goto end;
+display_frame(filt_frame, buffersink_ctx->inputs[0]->time_base);
+av_frame_unref(filt_frame);
+}
+}
+
end:
avfilter_graph_free(_graph);
avcodec_free_context(_ctx);
--
2.7.4
___
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 1/2] examples/decode_filter_audio: Add loop for draining the filtergraph
Depending on the filters used the filtergraph can produce trailing data
after feeding it the last input frame. Update the example to include the
necessary loop for draining the filtergrap.
Signed-off-by: Tobias Rapp
---
doc/examples/decode_filter_audio.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/doc/examples/decode_filter_audio.c
b/doc/examples/decode_filter_audio.c
index 2046419..196f080 100644
--- a/doc/examples/decode_filter_audio.c
+++ b/doc/examples/decode_filter_audio.c
@@ -279,6 +279,25 @@ int main(int argc, char **argv)
}
av_packet_unref(packet);
}
+if (ret == AVERROR_EOF) {
+/* signal EOF to the filtergraph */
+if (av_buffersrc_add_frame_flags(buffersrc_ctx, NULL, 0) < 0) {
+av_log(NULL, AV_LOG_ERROR, "Error while closing the
filtergraph\n");
+goto end;
+}
+
+/* pull remaining frames from the filtergraph */
+while (1) {
+ret = av_buffersink_get_frame(buffersink_ctx, filt_frame);
+if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
+break;
+if (ret < 0)
+goto end;
+print_frame(filt_frame);
+av_frame_unref(filt_frame);
+}
+}
+
end:
avfilter_graph_free(_graph);
avcodec_free_context(_ctx);
--
2.7.4
___
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] tests/audiogen: Fix total RIFF chunk size
On 15/03/2024 09:53, Tobias Rapp wrote: The "RIFF" identifier and chunk size fields should not be included within the size value. --- tests/audiogen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/audiogen.c b/tests/audiogen.c index c43bb70..df1dea6 100644 --- a/tests/audiogen.c +++ b/tests/audiogen.c @@ -109,7 +109,7 @@ static void put32(uint32_t v) fputc((v >> 24) & 0xff, outfile); } -#define HEADER_SIZE 46 +#define HEADER_SIZE 38 #define FMT_SIZE 18 #define SAMPLE_SIZE 2 #define WFORMAT_PCM 0x0001 Will apply in two days if there are no objections. Regards, Tobias ___ 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 2/2] avformat/riffdec: follow the MS docs more strictly for setting wav channel layouts
On 21/03/2024 10:40, Marton Balint wrote: On Thu, 21 Mar 2024, Tobias Rapp wrote: On 19/03/2024 20:14, Marton Balint wrote: On Tue, 19 Mar 2024, Michael Niedermayer wrote: On Sun, Mar 17, 2024 at 08:57:29PM +0100, Marton Balint wrote: - Only parse the defined masks in dwChannelMask, unless strict_std_compliance is less than normal. This matches with the behaviour of the wav muxer. - Ignore additional bits in dwChannelMasks as the MS documentation suggests [1] - Assume UNKNOWN channels for missing bits as the MS documentation suggests [1] [1] https://learn.microsoft.com/en-us/previous-versions/windows/hardware/design/dn653308(v=vs.85)#details-about-dwchannelmask Signed-off-by: Marton Balint --- libavformat/riffdec.c | 28 +--- 1 file changed, 25 insertions(+), 3 deletions(-) breaks: ./ffmpeg -i ~/tickets/2859/5.1plusdownmix.wav -ac 2 -t 100 -bitexact -c:a aac -y /tmp/2859-frenchspeack-nolibfaac.mp4 After the patch this is file will need -strict unofficial to work, since the downmix channels are not officially recognized in the dwChannelMask. I think downmix channels are part of the RF64 specification, see EBU Tech 3306 section 3.1: """ 3.1 Enhancement for a PCM stereo down mix No PCM stereo signal is included in the basic Wave Format Extensible. To include a stereo channel the following is added: #define SPEAKER_STEREO_LEFT 0x2000 #define SPEAKER_STEREO_RIGHT 0x4000 """ I was reluctant to add these, because the recommendation which superseded this, ITU BS.2088 does not mention these masks. Nevertheless, you are right, these should be recognized to support historical RF64 files. Or we should not even make the distinction of RF64? WAV files smaller than 2/4GiB could start with the usual "RIFF" bytes but still contain these mask bits. From a quick glance at ITU BS.2088 it seems it could use the "chna" chunk to achieve a mapping like "5.1 + downmix". Having said that, I have not stumbled over "X plus downmix" WAVE files in production yet. So no strong opinion from my side on whether this should work without "-strict unofficial", or not. Regards, Tobias ___ 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 2/2] avformat/riffdec: follow the MS docs more strictly for setting wav channel layouts
On 19/03/2024 20:14, Marton Balint wrote: On Tue, 19 Mar 2024, Michael Niedermayer wrote: On Sun, Mar 17, 2024 at 08:57:29PM +0100, Marton Balint wrote: - Only parse the defined masks in dwChannelMask, unless strict_std_compliance is less than normal. This matches with the behaviour of the wav muxer. - Ignore additional bits in dwChannelMasks as the MS documentation suggests [1] - Assume UNKNOWN channels for missing bits as the MS documentation suggests [1] [1] https://learn.microsoft.com/en-us/previous-versions/windows/hardware/design/dn653308(v=vs.85)#details-about-dwchannelmask Signed-off-by: Marton Balint --- libavformat/riffdec.c | 28 +--- 1 file changed, 25 insertions(+), 3 deletions(-) breaks: ./ffmpeg -i ~/tickets/2859/5.1plusdownmix.wav -ac 2 -t 100 -bitexact -c:a aac -y /tmp/2859-frenchspeack-nolibfaac.mp4 After the patch this is file will need -strict unofficial to work, since the downmix channels are not officially recognized in the dwChannelMask. I think downmix channels are part of the RF64 specification, see EBU Tech 3306 section 3.1: """ 3.1 Enhancement for a PCM stereo down mix No PCM stereo signal is included in the basic Wave Format Extensible. To include a stereo channel the following is added: #define SPEAKER_STEREO_LEFT 0x2000 #define SPEAKER_STEREO_RIGHT 0x4000 """ Regards, Tobias ___ 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] tests/audiogen: Fix total RIFF chunk size
The "RIFF" identifier and chunk size fields should not be included within the size value. --- tests/audiogen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/audiogen.c b/tests/audiogen.c index c43bb70..df1dea6 100644 --- a/tests/audiogen.c +++ b/tests/audiogen.c @@ -109,7 +109,7 @@ static void put32(uint32_t v) fputc((v >> 24) & 0xff, outfile); } -#define HEADER_SIZE 46 +#define HEADER_SIZE 38 #define FMT_SIZE 18 #define SAMPLE_SIZE 2 #define WFORMAT_PCM 0x0001 -- 2.7.4 ___ 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 9/9] avformat/pcm: decrease target audio frame per sec to 10
On 14/03/2024 23:04, Marton Balint wrote: On Thu, 14 Mar 2024, Tobias Rapp wrote: On 08/03/2024 01:53, Marton Balint wrote: This makes the wav and pcm demuxer demux bigger packets, which is more efficient. [...] +0, 136000, 136000, 2000, 24000, f952be1e1c7d48acd73d652ef4ea3aad +0, 138000, 138000, 2000, 24000, e42cbabef9d9675429dcb6fa28ce39f4 +0, 14, 14, 2000, 24000, 9c6613b980bcbe9ebacbb6a492f53b16 +0, 142000, 142000, 2000, 24000, 1882d1ae4b08fa7cc848eba60d645463 +0, 144000, 144000, 2000, 24000, a361b56ba31c90557689631f0e7afc63 +0, 146000, 146000, 2000, 24000, 341fbe24112c4060bb643750895a9041 +0, 148000, 148000, 2000, 24000, 38340ef2ef764bb8007efe9cd0af54d7 +0, 15, 15, 2000, 24000, 9b013a00bbedad211ba33326a3cfaa6e +0, 152000, 152000, 2000, 24000, 9d3469da4442cdfd2b8a5beacb789701 +0, 154000, 154000, 2000, 24000, cf8e3880ecb46011328135dba1015044 +0, 156000, 156000, 2000, 24000, 3be9fa7d0e0541269339ee032bda4021 +0, 158000, 158000, 2000, 24000, ffd2646acf86524651416bc412afd846 +0, 16, 16, 2000, 24000, 715163d8f82f007b1b6c42b06bd08b5a +0, 162000, 162000, 1840, 22080, c2079a237d021d7aa27e44acf979b1f0 Noob question: Isn't a much larger total number of samples produced here? The command line which generates the daud file specifies -frames:a 20, and 20 from bigger packets will cause a longer output file. Ah ok, I was just wondering because the packet count changes from 4 to 65 while the packet size stays at 24000. Didn't notice that a two-step process (encoding with limited frame-count into file, then separate decoding to get the framemd5) is performed here in contrast to other tests with frame-count limit. Also it might be good to mention in the commit that the audio duration is less exact when using commands like "ffmpeg -i $INPUT -c:a copy -t 1.0 $OUTPUT". Ok, will add this to the commit message. Thanks, Tobias ___ 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 9/9] avformat/pcm: decrease target audio frame per sec to 10
On 08/03/2024 01:53, Marton Balint wrote: This makes the wav and pcm demuxer demux bigger packets, which is more efficient. Signed-off-by: Marton Balint --- libavformat/pcm.c | 2 +- tests/ref/acodec/pcm-s16be| 2 +- tests/ref/acodec/pcm-s16be_planar | 4 +- tests/ref/acodec/pcm-s16le_planar | 4 +- tests/ref/acodec/pcm-s24be| 2 +- tests/ref/acodec/pcm-s24le_planar | 4 +- tests/ref/acodec/pcm-s32be| 2 +- tests/ref/acodec/pcm-s32le_planar | 4 +- tests/ref/acodec/pcm-s8_planar| 4 +- tests/ref/acodec/pcm-u16be| 4 +- tests/ref/acodec/pcm-u16le| 4 +- tests/ref/acodec/pcm-u24be| 4 +- tests/ref/acodec/pcm-u24le| 4 +- tests/ref/acodec/pcm-u32be| 4 +- tests/ref/acodec/pcm-u32le| 4 +- tests/ref/acodec/s302m| 8 +- tests/ref/fate/dcinema-encode | 63 +- tests/ref/fate/filter-acrossfade | 623 -- tests/ref/fate/filter-adelay | 324 ++--- tests/ref/fate/filter-aecho | 324 ++--- tests/ref/fate/filter-aemphasis-50fm | 324 ++--- tests/ref/fate/filter-aemphasis-75kf | 324 ++--- tests/ref/fate/filter-afade-esin | 324 ++--- tests/ref/fate/filter-afade-exp | 324 ++--- tests/ref/fate/filter-afade-hsin | 324 ++--- tests/ref/fate/filter-afade-iqsin | 324 ++--- tests/ref/fate/filter-afade-log | 324 ++--- tests/ref/fate/filter-afade-qsin | 324 ++--- tests/ref/fate/filter-agate | 324 ++--- tests/ref/fate/filter-alimiter| 324 ++--- tests/ref/fate/filter-amerge | 324 ++--- tests/ref/fate/filter-anequalizer | 324 ++--- tests/ref/fate/filter-apad| 324 ++--- .../ref/fate/filter-asegment-samples-absolute | 324 ++--- .../ref/fate/filter-asegment-samples-relative | 324 ++--- .../fate/filter-asegment-timestamps-absolute | 326 ++--- .../fate/filter-asegment-timestamps-relative | 326 ++--- tests/ref/fate/filter-asetrate| 40 +- tests/ref/fate/filter-atrim-mixed | 4 +- tests/ref/fate/filter-atrim-time | 5 +- tests/ref/fate/filter-chorus | 20 +- tests/ref/fate/filter-compand | 40 +- tests/ref/fate/filter-crystalizer | 324 ++--- tests/ref/fate/filter-dcshift | 40 +- tests/ref/fate/filter-earwax | 40 +- tests/ref/fate/filter-extrastereo | 40 +- tests/ref/fate/filter-pan-downmix1| 40 +- tests/ref/fate/filter-pan-downmix2| 40 +- tests/ref/fate/filter-pan-mono1 | 40 +- tests/ref/fate/filter-pan-mono2 | 40 +- tests/ref/fate/filter-pan-stereo1 | 40 +- tests/ref/fate/filter-pan-stereo2 | 40 +- tests/ref/fate/filter-pan-stereo3 | 40 +- tests/ref/fate/filter-pan-stereo4 | 40 +- tests/ref/fate/filter-pan-upmix1 | 40 +- tests/ref/fate/filter-pan-upmix2 | 40 +- tests/ref/fate/filter-stereotools | 40 +- tests/ref/fate/flcl1905 | 612 - tests/ref/fate/g722-encode| 282 +++- tests/ref/fate/g726-encode-2bit | 282 +++- tests/ref/fate/g726-encode-3bit | 282 +++- tests/ref/fate/g726-encode-4bit | 282 +++- tests/ref/fate/g726-encode-5bit | 282 +++- tests/ref/fate/matroska-move-cues-to-front| 18 +- tests/ref/fate/mov-channel-description| 4 +- tests/ref/fate/mov-mp4-pcm| 4 +- tests/ref/fate/mov-mp4-pcm-float | 2 +- tests/ref/lavf/ast| 4 +- tests/ref/lavf/mov| 12 +- tests/ref/lavf/mov_rtphint| 4 +- tests/ref/lavf/s16.voc| 4 +- tests/ref/lavf/smjpeg | 6 +- tests/ref/lavf/voc| 4 +- tests/ref/seek/acodec-adpcm-ima_wav | 54 +- tests/ref/seek/acodec-adpcm-ima_wav-trellis | 54 +- tests/ref/seek/acodec-adpcm-ms| 54 +- tests/ref/seek/acodec-adpcm-ms-trellis| 54 +- tests/ref/seek/acodec-adpcm-yamaha| 54 +- tests/ref/seek/acodec-adpcm-yamaha-trellis| 54 +- tests/ref/seek/acodec-pcm-alaw| 54 +- tests/ref/seek/acodec-pcm-f32be | 54 +-
Re: [FFmpeg-devel] [PATCH 02/18] fftools/ffmpeg_filter: refactor setting input timebase
On 11/03/2024 14:28, Anton Khirnov wrote: Quoting Martin Storsjö (2024-03-11 13:29:15) On Mon, 11 Mar 2024, Anton Khirnov wrote: Quoting Tobias Rapp (2024-03-11 11:12:38) On 10/03/2024 23:49, Anton Khirnov wrote: Quoting James Almer (2024-03-10 23:29:27) On 3/10/2024 7:24 PM, Anton Khirnov wrote: Quoting Michael Niedermayer (2024-03-10 20:21:47) On Sun, Mar 10, 2024 at 07:13:18AM +0100, Anton Khirnov wrote: Quoting Michael Niedermayer (2024-03-10 04:36:29) why not automatically choose a supported timebase ? "[mpeg4 @ 0x55973c869f00] timebase 1/100 not supported by MPEG 4 standard, the maximum admitted value for the timebase denominator is 65535" Because I don't want ffmpeg CLI to have codec-specific code for a codec that's been obsolete for 15+ years. One could also potentially do it inside the encoder itself, but it is nontrivial since the computations are spread across a number of places in mpeg4videoenc.c and mpegvideo_enc.c. And again, it seems like a waste of time - there is no reason to encode mpeg4 today. This is not mpeg4 specific, its just a new additional case that fails The case you reported is mpeg4 specific. ./ffmpeg -i mm-small.mpg test.dv [dvvideo @ 0x7f868800f100] Found no DV profile for 80x60 yuv420p video. Valid DV profiles are: There is no mechanism for an encoder to export supported time bases. Could it be added as an extension to AVProfile, or AVCodec? The two cases are actually pretty different: * mpeg4 has a constraint on the range of timebases, and actually does some perverted computations with the timestamps * DV just needs your video to be CFR, with a list of supported framerates; dvenc should probably read AVCodecContext.framerate instead of time_base But most importantly, is there an actual current use case for either of those encoders? They have both been obsolete for close to two decades. It seems silly to add new API that won't actually be useful to anyone. Hardware doesn't get outdated as quickly as software. And there are people that do not switch their full environment to a new codec every decade just to be "in line". And your point is...? I think the point is, that one can't just dismiss that anybody would want to encode mpeg4 video any longer, even if it is obsolete. I also would like to keep being able to do that. That capability is not going away though, and I'm not arguing that it should. That said, I haven't followed the discussion closely enough about what to do with the time bases. The only change is that in some rare cases the automatically selected timebase no longer fits into mpeg4 constraints, so the user has to specify either the framerate or the timebase explicitly. [...] If this is just about having to add some extra parametersin rare use-cases then its fine. I got the impression that encoding into MPEG4 or DV was considered deprecated (or unimportant of additional consideration) in general. Regards, Tobias ___ 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 02/18] fftools/ffmpeg_filter: refactor setting input timebase
On 10/03/2024 23:49, Anton Khirnov wrote: Quoting James Almer (2024-03-10 23:29:27) On 3/10/2024 7:24 PM, Anton Khirnov wrote: Quoting Michael Niedermayer (2024-03-10 20:21:47) On Sun, Mar 10, 2024 at 07:13:18AM +0100, Anton Khirnov wrote: Quoting Michael Niedermayer (2024-03-10 04:36:29) why not automatically choose a supported timebase ? "[mpeg4 @ 0x55973c869f00] timebase 1/100 not supported by MPEG 4 standard, the maximum admitted value for the timebase denominator is 65535" Because I don't want ffmpeg CLI to have codec-specific code for a codec that's been obsolete for 15+ years. One could also potentially do it inside the encoder itself, but it is nontrivial since the computations are spread across a number of places in mpeg4videoenc.c and mpegvideo_enc.c. And again, it seems like a waste of time - there is no reason to encode mpeg4 today. This is not mpeg4 specific, its just a new additional case that fails The case you reported is mpeg4 specific. ./ffmpeg -i mm-small.mpg test.dv [dvvideo @ 0x7f868800f100] Found no DV profile for 80x60 yuv420p video. Valid DV profiles are: There is no mechanism for an encoder to export supported time bases. Could it be added as an extension to AVProfile, or AVCodec? The two cases are actually pretty different: * mpeg4 has a constraint on the range of timebases, and actually does some perverted computations with the timestamps * DV just needs your video to be CFR, with a list of supported framerates; dvenc should probably read AVCodecContext.framerate instead of time_base But most importantly, is there an actual current use case for either of those encoders? They have both been obsolete for close to two decades. It seems silly to add new API that won't actually be useful to anyone. Hardware doesn't get outdated as quickly as software. And there are people that do not switch their full environment to a new codec every decade just to be "in line". Regards, Tobias ___ 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] [ANNOUNCE] upcoming vote: extra members for GA
On 09/11/2023 12:55, Michael Niedermayer wrote: On Thu, Nov 09, 2023 at 10:44:12AM +0100, Anton Khirnov wrote: As nobody expressed a preference, the vote will start next Monday (2023-11-13). It should run for a week, and will be followed by TC/CC elections. The only extra GA candidate I see proposed so far is Ronald. If anyone wants to suggest further people, please do so in this thread ASAP. IMHO the question of the relation of the list of people who could vote in the last GA vote and the people who where in the general assembly in 2020 should be awnsered before further votes. https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316609.html If the current GA stays as it is, then i propose the following people (this list was quickly made and certainly has omisions and possibly errors, check anything thats important to you!) [...] Tobias Rapp(vf_readvitc mainatiner, last commit in Jul 2023, 88 commits in FFmpeg) I only do small, trivial contributions, with large time gaps in between. Will not propose myself as an extra member of the GA for this vote. Regards, Tobias ___ 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] ffprobe: fix XML rendering, review XML layout
On 15/10/2023 04:59, Stefano Sabatini wrote: On date Sunday 2023-10-15 03:09:14 +0200, Timo Rothenpieler wrote: Isn't a change like that practically an ABI break, and thus would need to happen on a major bump? Yes, but in practice we are not tracking changes in the XML format, and major bumps are more related to ABI changes rather than to application level functionality, and probably there are not so many users using the XML format anyway. I'm processing XML-formatted output of ffprobe in some of my applications, including tags but not side_data.From my side it feels ok to update these elements with a minor bump only. Regards, Tobias ___ 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] avfilter/vf_overlay: Add support for yuv444p10 pixel format
On 17/07/2023 08:47, Tobias Rapp wrote: On 07/07/2023 14:44, Tobias Rapp wrote: --- doc/filters.texi | 3 +++ libavfilter/vf_overlay.c | 36 +++- libavfilter/vf_overlay.h | 1 + 3 files changed, 39 insertions(+), 1 deletion(-) [...] Would like to apply this patch-set in a few days from now if there are no objections. Applied. Regards, Tobias ___ 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] avfilter/vf_overlay: Add support for yuv444p10 pixel format
On 07/07/2023 14:44, Tobias Rapp wrote: --- doc/filters.texi | 3 +++ libavfilter/vf_overlay.c | 36 +++- libavfilter/vf_overlay.h | 1 + 3 files changed, 39 insertions(+), 1 deletion(-) [...] Would like to apply this patch-set in a few days from now if there are no objections. Regards, Tobias ___ 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 3/3] doc/filters: Extend description of overlay filter format option values
--- doc/filters.texi | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/filters.texi b/doc/filters.texi index 3b82edf..b57bb5a 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -18591,28 +18591,28 @@ Set the format for the output video. It accepts the following values: @table @samp @item yuv420 -force YUV420 output +force YUV 4:2:0 8-bit planar output @item yuv420p10 -force YUV420p10 output +force YUV 4:2:0 10-bit planar output @item yuv422 -force YUV422 output +force YUV 4:2:2 8-bit planar output @item yuv422p10 -force YUV422p10 output +force YUV 4:2:2 10-bit planar output @item yuv444 -force YUV444 output +force YUV 4:4:4 8-bit planar output @item yuv444p10 -force YUV444p10 output +force YUV 4:4:4 10-bit planar output @item rgb -force packed RGB output +force RGB 8-bit packed output @item gbrp -force planar RGB output +force RGB 8-bit planar output @item auto automatically pick format -- 2.7.4 ___ 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] tests/fate: Add test for overlay filter using yuv444p10 output format
--- tests/fate/filter-video.mak | 2 +- tests/filtergraphs/overlay_yuv444p10| 5 + tests/ref/fate/filter-overlay_yuv444p10 | 8 3 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 tests/filtergraphs/overlay_yuv444p10 create mode 100644 tests/ref/fate/filter-overlay_yuv444p10 diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak index e6de7de..789ec64 100644 --- a/tests/fate/filter-video.mak +++ b/tests/fate/filter-video.mak @@ -213,7 +213,7 @@ fate-filter-vstack: CMD = framecrc -c:v pgmyuv -i $(SRC) -c:v pgmyuv -i $(SRC) - FATE_FILTER_OVERLAY-$(call FILTERDEMDEC, SCALE OVERLAY, IMAGE2, PGMYUV) += fate-filter-overlay fate-filter-overlay: CMD = framecrc -c:v pgmyuv -i $(SRC) -c:v pgmyuv -i $(SRC) -filter_complex_script $(FILTERGRAPH) -FATE_FILTER_OVERLAY-$(call FILTERDEMDEC, SPLIT SCALE PAD OVERLAY, IMAGE2, PGMYUV) += $(addprefix fate-filter-overlay_, rgb yuv420 yuv420p10 nv12 nv21 yuv422 yuv422p10 yuv444) +FATE_FILTER_OVERLAY-$(call FILTERDEMDEC, SPLIT SCALE PAD OVERLAY, IMAGE2, PGMYUV) += $(addprefix fate-filter-overlay_, rgb yuv420 yuv420p10 nv12 nv21 yuv422 yuv422p10 yuv444 yuv444p10) fate-filter-overlay_%: CMD = framecrc -auto_conversion_filters -c:v pgmyuv -i $(SRC) -filter_complex_script $(FILTERGRAPH) fate-filter-overlay_yuv420: CMD = framecrc -c:v pgmyuv -i $(SRC) -filter_complex_script $(FILTERGRAPH) fate-filter-overlay_%p10: CMD = framecrc -auto_conversion_filters -c:v pgmyuv -i $(SRC) -filter_complex_script $(FILTERGRAPH) -pix_fmt $(@:fate-filter-overlay_%=%)le -frames:v 3 diff --git a/tests/filtergraphs/overlay_yuv444p10 b/tests/filtergraphs/overlay_yuv444p10 new file mode 100644 index 000..b184277 --- /dev/null +++ b/tests/filtergraphs/overlay_yuv444p10 @@ -0,0 +1,5 @@ +sws_flags=+accurate_rnd+bitexact; +split [main][over]; +[over] scale=88:72, format=yuv444p10, pad=96:80:4:4 [overf]; +[main] format=yuv444p10 [mainf]; +[mainf][overf] overlay=240:16:format=yuv444p10 diff --git a/tests/ref/fate/filter-overlay_yuv444p10 b/tests/ref/fate/filter-overlay_yuv444p10 new file mode 100644 index 000..b74dbcc --- /dev/null +++ b/tests/ref/fate/filter-overlay_yuv444p10 @@ -0,0 +1,8 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 352x288 +#sar 0: 0/1 +0, 0, 0,1, 608256, 0xc5ba4285 +0, 1, 1,1, 608256, 0x3066fd50 +0, 2, 2,1, 608256, 0xdb8e68a8 -- 2.7.4 ___ 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 1/3] avfilter/vf_overlay: Add support for yuv444p10 pixel format
---
doc/filters.texi | 3 +++
libavfilter/vf_overlay.c | 36 +++-
libavfilter/vf_overlay.h | 1 +
3 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index f17488c..3b82edf 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -18605,6 +18605,9 @@ force YUV422p10 output
@item yuv444
force YUV444 output
+@item yuv444p10
+force YUV444p10 output
+
@item rgb
force packed RGB output
diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
index 36c04ac..fa39abb 100644
--- a/libavfilter/vf_overlay.c
+++ b/libavfilter/vf_overlay.c
@@ -156,7 +156,7 @@ static int process_command(AVFilterContext *ctx, const char
*cmd, const char *ar
static const enum AVPixelFormat alpha_pix_fmts[] = {
AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUVA444P,
-AV_PIX_FMT_YUVA420P10, AV_PIX_FMT_YUVA422P10,
+AV_PIX_FMT_YUVA420P10, AV_PIX_FMT_YUVA422P10, AV_PIX_FMT_YUVA444P10,
AV_PIX_FMT_ARGB, AV_PIX_FMT_ABGR, AV_PIX_FMT_RGBA,
AV_PIX_FMT_BGRA, AV_PIX_FMT_GBRAP, AV_PIX_FMT_NONE
};
@@ -204,6 +204,13 @@ static int query_formats(AVFilterContext *ctx)
AV_PIX_FMT_YUVA444P, AV_PIX_FMT_NONE
};
+static const enum AVPixelFormat main_pix_fmts_yuv444p10[] = {
+AV_PIX_FMT_YUV444P10, AV_PIX_FMT_YUVA444P10, AV_PIX_FMT_NONE
+};
+static const enum AVPixelFormat overlay_pix_fmts_yuv444p10[] = {
+AV_PIX_FMT_YUVA444P10, AV_PIX_FMT_NONE
+};
+
static const enum AVPixelFormat main_pix_fmts_gbrp[] = {
AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP, AV_PIX_FMT_NONE
};
@@ -248,6 +255,10 @@ static int query_formats(AVFilterContext *ctx)
main_formats= main_pix_fmts_yuv444;
overlay_formats = overlay_pix_fmts_yuv444;
break;
+case OVERLAY_FORMAT_YUV444P10:
+main_formats= main_pix_fmts_yuv444p10;
+overlay_formats = overlay_pix_fmts_yuv444p10;
+break;
case OVERLAY_FORMAT_RGB:
main_formats= main_pix_fmts_rgb;
overlay_formats = overlay_pix_fmts_rgb;
@@ -759,6 +770,22 @@ static int blend_slice_yuva444(AVFilterContext *ctx, void
*arg, int jobnr, int n
return 0;
}
+static int blend_slice_yuv444p10(AVFilterContext *ctx, void *arg, int jobnr,
int nb_jobs)
+{
+OverlayContext *s = ctx->priv;
+ThreadData *td = arg;
+blend_slice_yuv_16_10bits(ctx, td->dst, td->src, 0, 0, 0, s->x, s->y, 1,
jobnr, nb_jobs);
+return 0;
+}
+
+static int blend_slice_yuva444p10(AVFilterContext *ctx, void *arg, int jobnr,
int nb_jobs)
+{
+OverlayContext *s = ctx->priv;
+ThreadData *td = arg;
+blend_slice_yuv_16_10bits(ctx, td->dst, td->src, 0, 0, 1, s->x, s->y, 1,
jobnr, nb_jobs);
+return 0;
+}
+
static int blend_slice_gbrp(AVFilterContext *ctx, void *arg, int jobnr, int
nb_jobs)
{
OverlayContext *s = ctx->priv;
@@ -902,6 +929,9 @@ static int config_input_main(AVFilterLink *inlink)
case OVERLAY_FORMAT_YUV444:
s->blend_slice = s->main_has_alpha ? blend_slice_yuva444 :
blend_slice_yuv444;
break;
+case OVERLAY_FORMAT_YUV444P10:
+s->blend_slice = s->main_has_alpha ? blend_slice_yuva444p10 :
blend_slice_yuv444p10;
+break;
case OVERLAY_FORMAT_RGB:
s->blend_slice = s->main_has_alpha ? blend_slice_rgba :
blend_slice_rgb;
break;
@@ -925,6 +955,9 @@ static int config_input_main(AVFilterLink *inlink)
case AV_PIX_FMT_YUVA444P:
s->blend_slice = blend_slice_yuva444;
break;
+case AV_PIX_FMT_YUVA444P10:
+s->blend_slice = blend_slice_yuva444p10;
+break;
case AV_PIX_FMT_ARGB:
case AV_PIX_FMT_RGBA:
case AV_PIX_FMT_BGRA:
@@ -1084,6 +1117,7 @@ static const AVOption overlay_options[] = {
{ "yuv422", "", 0, AV_OPT_TYPE_CONST, {.i64=OVERLAY_FORMAT_YUV422},
.flags = FLAGS, .unit = "format" },
{ "yuv422p10", "", 0, AV_OPT_TYPE_CONST,
{.i64=OVERLAY_FORMAT_YUV422P10}, .flags = FLAGS, .unit = "format" },
{ "yuv444", "", 0, AV_OPT_TYPE_CONST, {.i64=OVERLAY_FORMAT_YUV444},
.flags = FLAGS, .unit = "format" },
+{ "yuv444p10", "", 0, AV_OPT_TYPE_CONST,
{.i64=OVERLAY_FORMAT_YUV444P10}, .flags = FLAGS, .unit = "format" },
{ "rgb","", 0, AV_OPT_TYPE_CONST, {.i64=OVERLAY_FORMAT_RGB},
.flags = FLAGS, .unit = "format" },
{ "gbrp", "", 0, AV_OPT_TYPE_CONST, {.i64=OVERLAY_FORMAT_GBRP},
.flags = FLAGS, .unit = "format" },
{ "auto", "", 0, AV_OPT_TYPE_CONST, {.i64=OVERLAY_FORMAT_AUTO},
.flags = FLAGS, .unit = "format" },
diff --git a/libavfilter/vf_overlay.h b/libavfilter/vf_overlay.h
index 7e65095..5974964 100644
--- a/libavfilter/vf_overlay.h
+++ b/libavfilter/vf_overlay.h
@@ -47,6 +47,7 @@ enum OverlayFormat {
OVERLAY_FORMAT_YUV422,
OVERLAY_FORMAT_YUV422P10,
OVERLAY_FORMAT_YUV444,
+OVERLAY_FORMAT_YUV444P10,
OVERLAY_FORMAT_RGB,
Re: [FFmpeg-devel] [PATCH] doc/ffmpeg: Extend documentation for sws_flags option
On 17/05/2023 15:15, Gyan Doshi wrote: On 2023-05-17 05:22 pm, Tobias Rapp wrote: Clarify that -sws_flags are only applied to simple filtergraphs as a default, not complex filtergraphs. Add a reference to the scaler options. LGTM Regards, Gyan Applied. Thanks for review, Tobias ___ 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] doc/ffmpeg: Extend documentation for sws_flags option
Clarify that -sws_flags are only applied to simple filtergraphs as a
default, not complex filtergraphs. Add a reference to the scaler
options.
---
doc/ffmpeg.texi | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index a12700e..c0fa90f 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1023,7 +1023,12 @@ If @var{pix_fmt} is a single @code{+}, ffmpeg selects
the same pixel format
as the input (or graph output) and automatic conversions are disabled.
@item -sws_flags @var{flags} (@emph{input/output})
-Set SwScaler flags.
+Set default flags for the libswscale library. These flags are used by
+automatically inserted @code{scale} filters and those within simple
+filtergraphs, if not overridden within the filtergraph definition.
+
+See the @ref{scaler_options,,ffmpeg-scaler manual,ffmpeg-scaler} for a list
+of scaler options.
@item -rc_override[:@var{stream_specifier}] @var{override}
(@emph{output,per-stream})
Rate control override for specific intervals, formatted as "int,int,int"
--
2.7.4
___
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] avformat/dashdec: fail on probing non mpd file extension
On 09/05/2023 22:44, Michael Niedermayer wrote: On Tue, May 09, 2023 at 08:19:36AM +0200, Anton Khirnov wrote: Quoting Michael Niedermayer (2023-05-09 00:35:08) [...] would anyone be opposed to return 0 from dash_probe() when both the mime_type and the extension are wrong ? I would. probe() is for probing, not implementing security policies. IMO trying to fix security issues at the wrong layer will only lead to more confusion, more complexity, and LESS security. YES i agree, probe is not for security policies Its for probing but IMHO If you have a taxreport.pdf that parses correctly as jar and installs jRAT if you execute it Then it would be valid for probe() to identify this as type exploit instead of type jar. And doing so would be more secure. This is really more along the line of thought here for hls too. a file with avi/mkv/mov/mxf/mpg/mp4 extension is not a hls playlist Could someone have added that extension by mistake, yes similarly your jar file could be named .pdf by mistake. But thats not a good default assumtation and i dont think anyone would assume that by default. thx [...] But if the application expects a HLS playlist would it really be a problem if the input file ends with .avi or some other extension? The probe function just doesn't know what the application expects. Expectation and actual input type are aligned after probe. Regards, Tobias ___ 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] avformat/dashdec: fail on probing non mpd file extension
On 09/05/2023 08:19, Anton Khirnov wrote: Quoting Michael Niedermayer (2023-05-09 00:35:08) On Mon, May 08, 2023 at 04:05:40PM +0200, Tobias Rapp wrote: [...] DASH is usually transferred over HTTP where file extensions are of minor interest, the relevant type information is in the Mime-Type header. would anyone be opposed to return 0 from dash_probe() when both the mime_type and the extension are wrong ? I would. probe() is for probing, not implementing security policies. IMO trying to fix security issues at the wrong layer will only lead to more confusion, more complexity, and LESS security. I agree that probing should be unrelated to the actual format selection policy. example: a crafted image.jpeg uploaded somewhere is played as dash. or am i missing something that would stop that ? The player application could exclude the dash format (and other playlist formats) from the format_whitelist I guess? The alternative for the player application if it doesn't need to depend on the system installation of FFmpeg libraries would be to exclude unwanted formats at compilation time. Regards, Tobias ___ 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] avformat/dashdec: fail on probing non mpd file extension
On 08/05/2023 14:00, James Almer wrote:
On 5/6/2023 10:25 AM, Michael Niedermayer wrote:
Its unexpected that a .avi or other "standard" file turns into a
playlist.
The goal of this patch is to avoid this unexpected behavior and possible
privacy or security differences.
This is similar to the same change to hls
Signed-off-by: Michael Niedermayer
---
libavformat/dashdec.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 29d4680c68..294e14150d 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -2336,10 +2336,13 @@ static int dash_probe(const AVProbeData *p)
av_stristr(p->buf, "dash:profile:isoff-live:2011") ||
av_stristr(p->buf, "dash:profile:isoff-live:2012") ||
av_stristr(p->buf, "dash:profile:isoff-main:2011") ||
- av_stristr(p->buf, "3GPP:PSS:profile:DASH1")) {
- return AVPROBE_SCORE_MAX;
- }
- if (av_stristr(p->buf, "dash:profile")) {
+ av_stristr(p->buf, "3GPP:PSS:profile:DASH1") ||
+ av_stristr(p->buf, "dash:profile")) {
+ if (!av_match_ext(p->filename, "mpd")) {
+ av_log(NULL, AV_LOG_ERROR, "Not detecting dash with non
standard extension\n");
+ return 0;
+ }
+
return AVPROBE_SCORE_MAX;
}
Failing because it didn't match an extensions sort of goes against the
point of probing, which even has a low score return value that's
basically "it matched extension" as a sort of last resort.
I'd say wrap this in a FF_COMPLIANCE_STRICT check (since i assume the
spec does state mpd must be the extension), but i think we have no
access to the AVFormatContext here?
DASH is usually transferred over HTTP where file extensions are of minor
interest, the relevant type information is in the Mime-Type header.
I think we already have the "format_whitelist" API for applications that
want to restrict the list of formats when loading a file from untrusted
sources?
Regards, Tobias
___
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] lavc/libx265: flag as experimental
On 15/03/2023 15:45, Anton Khirnov wrote:
This encoder leaks and overreads, as can be seen e.g. by running an
encode under valgrind with default encoder parameters. This was known
upstream since at least 2019 (e.g. bitbucket issue #482) but never fixed
until now.
Since upstream does not seem to practice basic code hygiene, make sure
people do not use this encoder without knowing what they are getting
into.
---
libavcodec/libx265.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 420d0953af..d4511251a5 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -895,7 +895,8 @@ FFCodec ff_libx265_encoder = {
.p.id = AV_CODEC_ID_HEVC,
.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY |
AV_CODEC_CAP_OTHER_THREADS |
-AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
+AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE |
+AV_CODEC_CAP_EXPERIMENTAL,
.p.priv_class = ,
.p.wrapper_name = "libx265",
.init = libx265_encode_init,
My understanding of this flag for encoders is that it indicates some
possible experimental/non-standard bitstream features contained in
output data, not that the implementation itself is considered sub-par.
Regards, Tobias
___
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] tests/fate: add simple tests for libx264 and libx265
On 11/03/2023 18:05, Anton Khirnov wrote: Since these are external encoders not under our control, we cannot test the encoded output exactly as is done for internal encoders. We can still test however that the output is decodable and produces the expected number of frames with expected dimensions, pixel formats, and timestamps. --- A minimal proof of concept, more tests for these and other external encoders are welcome. Samples were picked at a whim, better suggestions also welcome. --- tests/Makefile| 1 + tests/fate-run.sh | 16 +++ tests/fate/enc_external.mak | 10 + tests/ref/fate/libx264-simple | 85 +++ tests/ref/fate/libx265-simple | 25 +++ 5 files changed, 137 insertions(+) create mode 100644 tests/fate/enc_external.mak create mode 100644 tests/ref/fate/libx264-simple create mode 100644 tests/ref/fate/libx265-simple [...] I think your approach for testing external (video) encoders is meaningful. Regards, Tobias ___ 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] libavutil/log: Support for logging timestamps in the log
On 19/01/2023 00:20, Prakash wrote: The problem with int milliseconds is you lose the microseconds precision. Sometimes there are multiple log lines within the same millisecond. If you want to do performance profiling like comparing between assembler and C versions of a routine in my opinion there are better ways to do that than using log timestamps. But I also have nothing against adding more positions after the decimal point, if you prefer that. The usecase I see for log timestamps is more to find out whether a warning message appeared at the begin, middle, or end of the transcoding process. I can definitely move the timestamp as the first field of the log line. Let me fix the patch file. -Prakash. Regards, Tobias ___ 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] libavutil/log: Support for logging timestamps in the log
On 17/01/2023 22:52, Prakash wrote:
libavutil/log: Support for logging timestamps in the log.
Add 'time' flag to the -loglevel option to turn on timestamp logging.
Useful for troubleshooting where time is spent from the log files.
Signed-off-by: Prakash Duggaraju
The commit message seems to be lacking a blank line between headline and
body in the attached patch file.
---
doc/fftools-common-opts.texi | 4
fftools/opt_common.c | 6 ++
libavutil/log.c | 14 ++
libavutil/log.h | 8
4 files changed, 32 insertions(+)
diff --git a/doc/fftools-common-opts.texi b/doc/fftools-common-opts.texi
index d9145704d6..a3cf9eb57d 100644
--- a/doc/fftools-common-opts.texi
+++ b/doc/fftools-common-opts.texi
@@ -201,6 +201,10 @@ and the "Last message repeated n times" line will be
omitted.
Indicates that log output should add a @code{[level]} prefix to each
message
line. This can be used as an alternative to log coloring, e.g. when
dumping the
log to file.
+@item time
+Indicates that log output should add a @code{[time]} prefix to each message
+line. The time is the relative time in microseconds precision. This can be
+useful for troubleshooting where time is spent from the logs.
Maybe you should mention here that adding the "time" flag practically
disables any "repeated" flag if given.
@end table
Flags can also be used alone by adding a '+'/'-' prefix to set/reset a
single
flag without affecting other @var{flags} or changing @var{loglevel}. When
diff --git a/fftools/opt_common.c b/fftools/opt_common.c
index 8a06df82df..a081ad6b08 100644
--- a/fftools/opt_common.c
+++ b/fftools/opt_common.c
@@ -1269,6 +1269,12 @@ int opt_loglevel(void *optctx, const char *opt,
const char *arg)
} else {
flags |= AV_LOG_PRINT_LEVEL;
}
+} else if (av_strstart(token, "time", )) {
+if (cmd == '-') {
+flags &= ~AV_LOG_PRINT_TIME;
+} else {
+flags |= AV_LOG_PRINT_TIME;
+}
} else {
break;
}
diff --git a/libavutil/log.c b/libavutil/log.c
index 5948e50467..cc16427178 100644
--- a/libavutil/log.c
+++ b/libavutil/log.c
@@ -42,6 +42,7 @@
#include "internal.h"
#include "log.h"
#include "thread.h"
+#include "time.h"
static AVMutex mutex = AV_MUTEX_INITIALIZER;
@@ -319,6 +320,19 @@ static void format_line(void *avcl, int level, const
char *fmt, va_list vl,
if (*print_prefix && (level > AV_LOG_QUIET) && (flags &
AV_LOG_PRINT_LEVEL))
av_bprintf(part+2, "[%s] ", get_level_str(level));
+if (*print_prefix && (level > AV_LOG_QUIET) && (flags &
AV_LOG_PRINT_TIME)) {
+int secs, mins;
+int64_t hours;
+int64_t time = av_gettime_relative();
+float millis = (time % 10) / 1000.0f;
Should be modulo one million, instead one hundred thousand. But see
comment regarding formatting below.
+time /= 100;
+secs = time % 60;
+time /= 60;
+mins = time % 60;
+hours = time / 60;
+av_bprintf(part+2, "[%ldh:%02dm:%02ds:%07.03fms] ", hours, mins,
secs, millis);
Adding it to part[2] will colorize time according to the log message
level. Maybe add an own AVBPrint buffer for it?
+}
+
av_vbprintf(part+3, fmt, vl);
if(*part[0].str || *part[1].str || *part[2].str || *part[3].str) {
diff --git a/libavutil/log.h b/libavutil/log.h
index ab7ceabe22..2e2d83f6d0 100644
--- a/libavutil/log.h
+++ b/libavutil/log.h
@@ -377,6 +377,14 @@ int av_log_format_line2(void *ptr, int level, const
char *fmt, va_list vl,
*/
#define AV_LOG_PRINT_LEVEL 2
+/**
+ * Include the system time with each log message.
+ * Useful for troubleshooting where the time was spent.
+ * Results in messages such as:
+ * [rawvideo @ 0xDEADBEEF] [01h:03m:05s:3.112ms] [error] encode did not
produce valid pts
In my personal opinion I find formatting the timestamp with integer
seconds and float milliseconds a bit weird. Using float seconds (like
HH:MM:SS.mmm) would look more familiar to me.
And maybe add the timestamp at the very front of the formatted log
message? That way it should be easier to scroll through the log file and
spot time jumps.
+ */
+#define AV_LOG_PRINT_TIME 4
+
void av_log_set_flags(int arg);
int av_log_get_flags(void);
Regards, Tobias
___
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] trailing padding
On 12/01/2023 10:41, Paul B Mahol wrote: Patches attached, ffmpeg.c should really not ignore initial padding and trailing padding. I guess ffprobe.xsd should be updated, too. Did you run FATE? Regards, Tobias ___ 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] libswresample: avoid s16p internal processing format
On 08/01/2023 15:45, Michael Niedermayer wrote: On Fri, Jan 06, 2023 at 07:01:06PM +0100, Paul B Mahol wrote: On Fri, Jan 6, 2023 at 6:25 PM Michael Niedermayer wrote: On Thu, Jan 05, 2023 at 11:08:25PM +0100, Paul B Mahol wrote: On Thu, Jan 5, 2023 at 9:53 PM Michael Niedermayer < mich...@niedermayer.cc> wrote: On Thu, Jan 05, 2023 at 01:44:10PM +0100, Paul B Mahol wrote: Patch attached. swresample.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) eee7a0685b44aa867562138a2e2437ecb8844612 0001-libswresample-swresample-avoid-s16p-internal-transfe.patch From 9c4cd60e2dd41cf98d693c8251f4cfade0807073 Mon Sep 17 00:00:00 2001 From: Paul B Mahol Date: Thu, 5 Jan 2023 13:40:12 +0100 Subject: [PATCH] libswresample/swresample: avoid s16p internal transfer format Instead use float one by default for sample rate conversions. The s16p internal transfer format produces visible and hearable quantization artifacts. When does this occur and why? It occurs always. Just compare output with 16bit and int32/float/double. Look at other people report on internet. Look at src.infinitewave.ca src.infinitewave.ca uses 32bit none of what it shows should touch the codepath you change. if we look at src.infinitewave.ca for swr we see 2 types of artifacts 1. Aliassing which is at maybe -120db with the actual signal at 0db i would like to see some evidence that a human can hear this For s16p<->s16p it is much lower, around -78dB thus this patch. ok but you pointed to the website that apparently uses >=32bit if i trust what they write. And even if they test this i cannot use that website to replicate the issue and the fix I just wanted to know how i can test this. You are testing it too ... so i can see what you see Id like to make sure this is the correct fix for the problem and Id like to make sure its used when it makes sense and not when not. IIRC a similar sweep graph can be created with "Spek" from http://spek.cc/ but haven't used that application for a while. The SRC comparison website apparently provides the input files for testing, see the instructions at http://src.infinitewave.ca/faq.html. Regards, Tobias ___ 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 v4 0/2] use av_fopen_utf8() instead of plain fopen()
On 17/05/2022 14:29, ffmpegagent wrote: Unify file access operations by replacing usages of direct calls to posix fopen() v2: Remove changes to fftools for now v3: Add some additional replacements v4: Fix and improve commit messages softworkz (2): avfilter: use av_fopen_utf8() instead of plain fopen() avcodec/dvdsubdec: use av_fopen_utf8() instead of plain fopen() libavcodec/dvdsubdec.c| 2 +- libavfilter/af_firequalizer.c | 2 +- libavfilter/vf_deshake.c | 2 +- libavfilter/vf_psnr.c | 2 +- libavfilter/vf_signature.c| 4 ++-- libavfilter/vf_ssim.c | 2 +- libavfilter/vf_vidstabdetect.c| 2 +- libavfilter/vf_vidstabtransform.c | 2 +- libavfilter/vf_vmafmotion.c | 2 +- 9 files changed, 10 insertions(+), 10 deletions(-) [...] Commit messages look fine to me now. I will leave the decision to others about the order of changes -- whether this patch-set comes first, or the fix for the CRT linking issue (possibly replacing this public function with a private copy). Regards, Tobias ___ 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 0/2] use av_fopen_utf8() instead of plain fopen()
On 17/05/2022 02:39, ffmpegagent wrote: Unify file access operations by replacing usages of direct calls to posix fopen() As the cover letter will be gone after commit I think it would be a good idea to add the reason for the change also in the commit messages directly. Is this in preparation for the long filename support on Windows? Then maybe this could be mentioned, too. v2: Remove changes to fftools for now v3: Add some additional replacements softworkz (2): avfilter: use av_fopen_utf8() instead of plain fopen() avfilter/dvdsubdec: use av_fopen_utf8() instead of plain fopen() Patch #2 title should start with "avcodec/dvdsubdec: ..." I guess. libavcodec/dvdsubdec.c| 2 +- libavfilter/af_firequalizer.c | 2 +- libavfilter/vf_deshake.c | 2 +- libavfilter/vf_psnr.c | 2 +- libavfilter/vf_signature.c| 4 ++-- libavfilter/vf_ssim.c | 2 +- libavfilter/vf_vidstabdetect.c| 2 +- libavfilter/vf_vidstabtransform.c | 2 +- libavfilter/vf_vmafmotion.c | 2 +- 9 files changed, 10 insertions(+), 10 deletions(-) [...] Regards, Tobias ___ 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 v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi
On 11/05/2022 09:57, Soft Works wrote: [...] I'm not sure how much you had followed, so please excuse in case you had already read it: the manifest approach does not work on a default Windows installation. To activate long path support, the users needs to opt-in to a behavior that is probably deactivated by default for some reason. Also it requires administrative privileges to make this change. For me - and probably for others as well - that approach is useless, as it would be the same as if there would be no long path support. (when you cannot rely on that feature being always working, you cannot use it) For me an analogous case is the usage of the "--large-address-aware" linker flag. It enables FFmpeg to use more than 2GiB of memory on Win32. That feature is useless to users having <= 2GiB of total system memory available, and it makes no guarantee that an OOM error is avoided. Still it allows to exceed a limit for those that match the requirements -- knowingly or by pure coincidence. Regards, Tobias ___ 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 v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi
On 11/05/2022 01:32, Soft Works wrote: [...] The prefixing can be implemented as a function and then be used in file_open.c. Other file system related functions like mkdir, rename, rmdir, etc. are already intercepted in os_support.h, and the prefixing can be applied there. Maybe I missed some cases, I have not fully analyzed the situation, but surely there are just a small number of places that need to be changed and not 587. For the procedure of prefixing I would take a look at how it's done in .NET. This is probably the most mature code for handling this and might save us from dealing with issues and regressions until we got it right. The logic they use is here: https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/IO/PathHelper.Windows.cs Probably it can be simplified a bit. Out of curiosity I searched for some automatic path prefixing code and the author of this file claims that it should be handling most corner cases: https://github.com/JFLarvoire/SysToolsLib/blob/master/C/MsvcLibX/src/mb2wpath.c That amount of logic inside CorrectWidePath() does not look appealing to me. And even if we simplify that now I guess it will grow once the corner cases drop in via bug reports. So I'm in favor of removing the MAX_PATH limit, converting needed Win32 function calls from ANSI to WideChar, and adding the longPathAware manifest flag. I think the activeCodePage=UTF-8 patch could break Windows applications that expect the system-wide ANSI codepage to be used for FFmpeg text output, though. Regards, Tobias ___ 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 v11 5/6] fftools: Enable long path support on Windows (fixes #8885)
On 26/04/2022 09:29, Hendrik Leppkes wrote: On Tue, Apr 26, 2022 at 9:08 AM Tobias Rapp wrote: On 23/04/2022 22:56, Nil Admirari wrote: Newer versions of Windows (Windows 10 1607 and newer) can support path names longer than MAX_PATH (260 characters). To take advantage of that, an application needs to opt in, by including a small manifest as a resource. Application must be prepared to handle filenames greater than MAX_PATH. Additionally, the path length limitation is only lifted for file APIs that pass paths as wchar_t. Therefore, the preceding patches have refactored a few remaining cases where: 1. filename length was restricted to MAX_PATH 2. files were opened using ANSI functions. On older versions of Windows, the newly added manifest has no effect. --- fftools/Makefile | 5 + fftools/fftools.manifest | 10 ++ fftools/manifest.rc | 3 +++ 3 files changed, 18 insertions(+) create mode 100644 fftools/fftools.manifest create mode 100644 fftools/manifest.rc diff --git a/fftools/Makefile b/fftools/Makefile index 81ad6c4f..105ae5cc 100644 --- a/fftools/Makefile +++ b/fftools/Makefile @@ -15,6 +15,11 @@ OBJS-ffmpeg += \ fftools/ffmpeg_mux.o\ fftools/ffmpeg_opt.o\ +# Windows resource files +OBJS-ffmpeg-$(HAVE_GNU_WINDRES) += fftools/manifest.o +OBJS-ffplay-$(HAVE_GNU_WINDRES) += fftools/manifest.o +OBJS-ffprobe-$(HAVE_GNU_WINDRES) += fftools/manifest.o + define DOFFTOOL OBJS-$(1) += fftools/cmdutils.o fftools/opt_common.o fftools/$(1).o $(OBJS-$(1)-yes) $(1)$(PROGSSUF)_g$(EXESUF): $$(OBJS-$(1)) diff --git a/fftools/fftools.manifest b/fftools/fftools.manifest new file mode 100644 index ..30b7d8fe --- /dev/null +++ b/fftools/fftools.manifest @@ -0,0 +1,10 @@ + + + + What is the effect of the version attribute here? Would it be meaningful to replace the static dummy value with something more realistic like "5.1.n" or similar? Just asking as I'm not very familiar with manifest resources. The assembly version does not have any important meaning, not for assemblies used in this manner. It would only matter if you were to reference other assemblies across files, which is not done for these application settings - and even then the only real importance would be to increment it when its changed in an incompatible manner, not necessarily linked to the application version, which is stored in a resource file instead of the assembly. Alright then, thanks for the clarification. Regards, Tobias ___ 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 v11 5/6] fftools: Enable long path support on Windows (fixes #8885)
On 23/04/2022 22:56, Nil Admirari wrote: Newer versions of Windows (Windows 10 1607 and newer) can support path names longer than MAX_PATH (260 characters). To take advantage of that, an application needs to opt in, by including a small manifest as a resource. Application must be prepared to handle filenames greater than MAX_PATH. Additionally, the path length limitation is only lifted for file APIs that pass paths as wchar_t. Therefore, the preceding patches have refactored a few remaining cases where: 1. filename length was restricted to MAX_PATH 2. files were opened using ANSI functions. On older versions of Windows, the newly added manifest has no effect. --- fftools/Makefile | 5 + fftools/fftools.manifest | 10 ++ fftools/manifest.rc | 3 +++ 3 files changed, 18 insertions(+) create mode 100644 fftools/fftools.manifest create mode 100644 fftools/manifest.rc diff --git a/fftools/Makefile b/fftools/Makefile index 81ad6c4f..105ae5cc 100644 --- a/fftools/Makefile +++ b/fftools/Makefile @@ -15,6 +15,11 @@ OBJS-ffmpeg += \ fftools/ffmpeg_mux.o\ fftools/ffmpeg_opt.o\ +# Windows resource files +OBJS-ffmpeg-$(HAVE_GNU_WINDRES) += fftools/manifest.o +OBJS-ffplay-$(HAVE_GNU_WINDRES) += fftools/manifest.o +OBJS-ffprobe-$(HAVE_GNU_WINDRES) += fftools/manifest.o + define DOFFTOOL OBJS-$(1) += fftools/cmdutils.o fftools/opt_common.o fftools/$(1).o $(OBJS-$(1)-yes) $(1)$(PROGSSUF)_g$(EXESUF): $$(OBJS-$(1)) diff --git a/fftools/fftools.manifest b/fftools/fftools.manifest new file mode 100644 index ..30b7d8fe --- /dev/null +++ b/fftools/fftools.manifest @@ -0,0 +1,10 @@ + + + + What is the effect of the version attribute here? Would it be meaningful to replace the static dummy value with something more realistic like "5.1.n" or similar? Just asking as I'm not very familiar with manifest resources. + +http://schemas.microsoft.com/SMI/2016/WindowsSettings;> + true + + + diff --git a/fftools/manifest.rc b/fftools/manifest.rc new file mode 100644 index ..e436fa73 --- /dev/null +++ b/fftools/manifest.rc @@ -0,0 +1,3 @@ +#include + +CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "fftools.manifest" Regards, Tobias ___ 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 1/8] fate/filter-refcmp-*: make refcmp_metadata fail on empty or truncated input
On 31/03/2022 23:30, Marton Balint wrote:
On empty input the awk script was always successful which caused the
filter-refcmp tests to always succeed.
Also fix the command lines for refcmp_metadata compare function because it
needs auto conversion filters, and update reference of test
filter-refcmp-psnr-rgb because it was missed in
a7fc78c1a638a32c3695c06f727774c740d675c2 but was never noticed due to the
original issue...
Signed-off-by: Marton Balint
---
tests/fate-run.sh | 2 +-
tests/ref/fate/filter-refcmp-psnr-rgb | 80 +--
tests/refcmp-metadata.awk | 5 +-
3 files changed, 45 insertions(+), 42 deletions(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index fbfc0a925d..5e8d607d88 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -377,7 +377,7 @@ refcmp_metadata(){
refcmp=$1
pixfmt=$2
fuzz=${3:-0.001}
-ffmpeg $FLAGS $ENC_OPTS \
+ffmpeg -auto_conversion_filters $FLAGS $ENC_OPTS \
-lavfi
"testsrc2=size=300x200:rate=1:duration=5,format=${pixfmt},split[ref][tmp];[tmp]avgblur=4[enc];[enc][ref]${refcmp},metadata=print:file=-"
\
-f null /dev/null | awk -v ref=${ref} -v fuzz=${fuzz} -f
${base}/refcmp-metadata.awk -
}
diff --git a/tests/ref/fate/filter-refcmp-psnr-rgb
b/tests/ref/fate/filter-refcmp-psnr-rgb
index f06db575ac..20abd3dc5a 100644
--- a/tests/ref/fate/filter-refcmp-psnr-rgb
+++ b/tests/ref/fate/filter-refcmp-psnr-rgb
@@ -1,45 +1,45 @@
frame:0pts:0 pts_time:0
-lavfi.psnr.mse.r=1381.80
-lavfi.psnr.psnr.r=16.73
-lavfi.psnr.mse.g=896.00
-lavfi.psnr.psnr.g=18.61
-lavfi.psnr.mse.b=277.38
-lavfi.psnr.psnr.b=23.70
-lavfi.psnr.mse_avg=851.73
-lavfi.psnr.psnr_avg=18.83
+lavfi.psnr.mse.r=1367.642090
+lavfi.psnr.psnr.r=16.771078
+lavfi.psnr.mse.g=885.804382
+lavfi.psnr.psnr.g=18.657425
+lavfi.psnr.mse.b=274.825073
+lavfi.psnr.psnr.b=23.740240
+lavfi.psnr.mse_avg=842.757202
+lavfi.psnr.psnr_avg=18.873779
frame:1pts:1 pts_time:1
-lavfi.psnr.mse.r=1380.37
-lavfi.psnr.psnr.r=16.73
-lavfi.psnr.mse.g=975.91
-lavfi.psnr.psnr.g=18.24
-lavfi.psnr.mse.b=435.72
-lavfi.psnr.psnr.b=21.74
-lavfi.psnr.mse_avg=930.67
-lavfi.psnr.psnr_avg=18.44
+lavfi.psnr.mse.r=1356.681152
+lavfi.psnr.psnr.r=16.806026
+lavfi.psnr.mse.g=958.161560
+lavfi.psnr.psnr.g=18.316416
+lavfi.psnr.mse.b=428.238312
+lavfi.psnr.psnr.b=21.813948
+lavfi.psnr.mse_avg=914.360352
+lavfi.psnr.psnr_avg=18.519630
frame:2pts:2 pts_time:2
-lavfi.psnr.mse.r=1403.20
-lavfi.psnr.psnr.r=16.66
-lavfi.psnr.mse.g=954.05
-lavfi.psnr.psnr.g=18.34
-lavfi.psnr.mse.b=494.22
-lavfi.psnr.psnr.b=21.19
-lavfi.psnr.mse_avg=950.49
-lavfi.psnr.psnr_avg=18.35
+lavfi.psnr.mse.r=1387.254883
+lavfi.psnr.psnr.r=16.709242
+lavfi.psnr.mse.g=939.230957
+lavfi.psnr.psnr.g=18.403080
+lavfi.psnr.mse.b=493.913757
+lavfi.psnr.psnr.b=21.194292
+lavfi.psnr.mse_avg=940.133179
+lavfi.psnr.psnr_avg=18.398911
frame:3pts:3 pts_time:3
-lavfi.psnr.mse.r=1452.80
-lavfi.psnr.psnr.r=16.51
-lavfi.psnr.mse.g=1001.02
-lavfi.psnr.psnr.g=18.13
-lavfi.psnr.mse.b=557.39
-lavfi.psnr.psnr.b=20.67
-lavfi.psnr.mse_avg=1003.74
-lavfi.psnr.psnr_avg=18.11
+lavfi.psnr.mse.r=1433.291260
+lavfi.psnr.psnr.r=16.567459
+lavfi.psnr.mse.g=990.005859
+lavfi.psnr.psnr.g=18.174425
+lavfi.psnr.mse.b=550.512329
+lavfi.psnr.psnr.b=20.723133
+lavfi.psnr.mse_avg=991.269836
+lavfi.psnr.psnr_avg=18.168884
frame:4pts:4 pts_time:4
-lavfi.psnr.mse.r=1401.25
-lavfi.psnr.psnr.r=16.67
-lavfi.psnr.mse.g=1009.80
-lavfi.psnr.psnr.g=18.09
-lavfi.psnr.mse.b=602.42
-lavfi.psnr.psnr.b=20.33
-lavfi.psnr.mse_avg=1004.49
-lavfi.psnr.psnr_avg=18.11
+lavfi.psnr.mse.r=1385.949341
+lavfi.psnr.psnr.r=16.713329
+lavfi.psnr.mse.g=997.065796
+lavfi.psnr.psnr.g=18.143566
+lavfi.psnr.mse.b=601.962952
+lavfi.psnr.psnr.b=20.335106
+lavfi.psnr.mse_avg=994.992676
+lavfi.psnr.psnr_avg=18.152605
diff --git a/tests/refcmp-metadata.awk b/tests/refcmp-metadata.awk
index fa21aad0e0..850aaac5a3 100644
--- a/tests/refcmp-metadata.awk
+++ b/tests/refcmp-metadata.awk
@@ -50,13 +50,16 @@ BEGIN {
}
END {
+result = result && (NR == ref_nr);
if (result) {
for (i = 1; i <= ref_nr; i++)
print ref_lines[i];
} else {
for (i = 1; i <= NR; i++)
print cmp_lines[i];
-if (NR != ref_nr)
+if (NR == 0)
+print "[refcmp] no input" > "/dev/stderr";
+else if (NR != ref_nr)
print "[refcmp] lines: " NR " != " ref_nr > "/dev/stderr";
if (delta_max >= fuzz)
print "[refcmp] delta_max: " delta_max " >= " fuzz >
"/dev/stderr";
Looks good to me.
Regards,
Tobias
___
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/8] fate/filter-refcmp-*: make refcmp_metadata fail on empty input
On 30/03/2022 22:31, Marton Balint wrote:
On empty input the awk script was always successful which caused the
filter-refcmp tests to always succeed.
Also fix the command lines for refcmp_metadata compare function because it
needs auto conversion filters, and update reference of test
filter-refcmp-psnr-rgb because it was missed in
a7fc78c1a638a32c3695c06f727774c740d675c2 but was never noticed due to the
original issue...
Signed-off-by: Marton Balint
---
tests/fate-run.sh | 2 +-
tests/ref/fate/filter-refcmp-psnr-rgb | 80 +--
tests/refcmp-metadata.awk | 3 +
3 files changed, 44 insertions(+), 41 deletions(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index fbfc0a925d..5e8d607d88 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -377,7 +377,7 @@ refcmp_metadata(){
refcmp=$1
pixfmt=$2
fuzz=${3:-0.001}
-ffmpeg $FLAGS $ENC_OPTS \
+ffmpeg -auto_conversion_filters $FLAGS $ENC_OPTS \
-lavfi
"testsrc2=size=300x200:rate=1:duration=5,format=${pixfmt},split[ref][tmp];[tmp]avgblur=4[enc];[enc][ref]${refcmp},metadata=print:file=-"
\
-f null /dev/null | awk -v ref=${ref} -v fuzz=${fuzz} -f
${base}/refcmp-metadata.awk -
}
diff --git a/tests/ref/fate/filter-refcmp-psnr-rgb
b/tests/ref/fate/filter-refcmp-psnr-rgb
index f06db575ac..20abd3dc5a 100644
--- a/tests/ref/fate/filter-refcmp-psnr-rgb
+++ b/tests/ref/fate/filter-refcmp-psnr-rgb
@@ -1,45 +1,45 @@
frame:0pts:0 pts_time:0
-lavfi.psnr.mse.r=1381.80
-lavfi.psnr.psnr.r=16.73
-lavfi.psnr.mse.g=896.00
-lavfi.psnr.psnr.g=18.61
-lavfi.psnr.mse.b=277.38
-lavfi.psnr.psnr.b=23.70
-lavfi.psnr.mse_avg=851.73
-lavfi.psnr.psnr_avg=18.83
+lavfi.psnr.mse.r=1367.642090
+lavfi.psnr.psnr.r=16.771078
+lavfi.psnr.mse.g=885.804382
+lavfi.psnr.psnr.g=18.657425
+lavfi.psnr.mse.b=274.825073
+lavfi.psnr.psnr.b=23.740240
+lavfi.psnr.mse_avg=842.757202
+lavfi.psnr.psnr_avg=18.873779
frame:1pts:1 pts_time:1
-lavfi.psnr.mse.r=1380.37
-lavfi.psnr.psnr.r=16.73
-lavfi.psnr.mse.g=975.91
-lavfi.psnr.psnr.g=18.24
-lavfi.psnr.mse.b=435.72
-lavfi.psnr.psnr.b=21.74
-lavfi.psnr.mse_avg=930.67
-lavfi.psnr.psnr_avg=18.44
+lavfi.psnr.mse.r=1356.681152
+lavfi.psnr.psnr.r=16.806026
+lavfi.psnr.mse.g=958.161560
+lavfi.psnr.psnr.g=18.316416
+lavfi.psnr.mse.b=428.238312
+lavfi.psnr.psnr.b=21.813948
+lavfi.psnr.mse_avg=914.360352
+lavfi.psnr.psnr_avg=18.519630
frame:2pts:2 pts_time:2
-lavfi.psnr.mse.r=1403.20
-lavfi.psnr.psnr.r=16.66
-lavfi.psnr.mse.g=954.05
-lavfi.psnr.psnr.g=18.34
-lavfi.psnr.mse.b=494.22
-lavfi.psnr.psnr.b=21.19
-lavfi.psnr.mse_avg=950.49
-lavfi.psnr.psnr_avg=18.35
+lavfi.psnr.mse.r=1387.254883
+lavfi.psnr.psnr.r=16.709242
+lavfi.psnr.mse.g=939.230957
+lavfi.psnr.psnr.g=18.403080
+lavfi.psnr.mse.b=493.913757
+lavfi.psnr.psnr.b=21.194292
+lavfi.psnr.mse_avg=940.133179
+lavfi.psnr.psnr_avg=18.398911
frame:3pts:3 pts_time:3
-lavfi.psnr.mse.r=1452.80
-lavfi.psnr.psnr.r=16.51
-lavfi.psnr.mse.g=1001.02
-lavfi.psnr.psnr.g=18.13
-lavfi.psnr.mse.b=557.39
-lavfi.psnr.psnr.b=20.67
-lavfi.psnr.mse_avg=1003.74
-lavfi.psnr.psnr_avg=18.11
+lavfi.psnr.mse.r=1433.291260
+lavfi.psnr.psnr.r=16.567459
+lavfi.psnr.mse.g=990.005859
+lavfi.psnr.psnr.g=18.174425
+lavfi.psnr.mse.b=550.512329
+lavfi.psnr.psnr.b=20.723133
+lavfi.psnr.mse_avg=991.269836
+lavfi.psnr.psnr_avg=18.168884
frame:4pts:4 pts_time:4
-lavfi.psnr.mse.r=1401.25
-lavfi.psnr.psnr.r=16.67
-lavfi.psnr.mse.g=1009.80
-lavfi.psnr.psnr.g=18.09
-lavfi.psnr.mse.b=602.42
-lavfi.psnr.psnr.b=20.33
-lavfi.psnr.mse_avg=1004.49
-lavfi.psnr.psnr_avg=18.11
+lavfi.psnr.mse.r=1385.949341
+lavfi.psnr.psnr.r=16.713329
+lavfi.psnr.mse.g=997.065796
+lavfi.psnr.psnr.g=18.143566
+lavfi.psnr.mse.b=601.962952
+lavfi.psnr.psnr.b=20.335106
+lavfi.psnr.mse_avg=994.992676
+lavfi.psnr.psnr_avg=18.152605
diff --git a/tests/refcmp-metadata.awk b/tests/refcmp-metadata.awk
index fa21aad0e0..e7ed5ae809 100644
--- a/tests/refcmp-metadata.awk
+++ b/tests/refcmp-metadata.awk
@@ -50,12 +50,15 @@ BEGIN {
}
END {
+result = result && (NR != 0);
Checking for "NR == ref_nr" would additionally catch truncated input.
if (result) {
for (i = 1; i <= ref_nr; i++)
print ref_lines[i];
} else {
for (i = 1; i <= NR; i++)
print cmp_lines[i];
+if (NR == 0)
+print "[refcmp] no input";
Output should go to stderr here.
if (NR != ref_nr)
print "[refcmp] lines: " NR " != " ref_nr > "/dev/stderr";
Maybe add an "else" before the "if" to avoid that both lines are printed
for empty input.
if (delta_max >= fuzz)
Otherwise looks good to me. Thanks for catching the issue!
Regards,
Tobias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
Re: [FFmpeg-devel] [PATCH v2] avcodec: Add dv marker bsf
On 09/03/2022 19:18, Michael Niedermayer wrote:
Signed-off-by: Michael Niedermayer
---
doc/bitstream_filters.texi | 30
libavcodec/Makefile | 1 +
libavcodec/bitstream_filters.c | 1 +
libavcodec/dv_error_marker_bsf.c | 127 +++
4 files changed, 159 insertions(+)
create mode 100644 libavcodec/dv_error_marker_bsf.c
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index a0092878c8..8c5d84dceb 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -132,6 +132,36 @@ the header stored in extradata to the key packets:
ffmpeg -i INPUT -map 0 -flags:v +global_header -c:v libx264 -bsf:v dump_extra
out.ts
@end example
+@section dv_error_marker
+
+Blocks in DV which are marked as damaged are replaced by blocks of the
specified color.
+
+@table @option
+@item color
+The color to replace damaged blocks by
+@item sta
+A 16 bit mask which specifies which of the 16 possible error status values are
+to be replaced by colored blocks. 0xFFFE is the default which replaces all non 0
+error status values.
+@table @samp
+@item ok
+No error, no concealment
+@item err
+Error, No concealment
+@item res
+Reserved
+@item notok
+Error or concealment
+@item notres
+Not reserved
+@item Aa, Ba, Ca, Ab, Bb, Cb, A, B, C, a, b, erri, erru
+The specific error status code
+@end table
+see page 44-46 or section 5.5 of
+@url{http://web.archive.org/web/20060927044735/http://www.smpte.org/smpte_store/standards/pdf/s314m.pdf}
+
+@end table
+
@section eac3_core
[...]
The filter options look nice to me now. Have not actually tested the
bitstream filter on DV files, though.
Regards,
Tobias
___
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] avcodec: Add dv marker bsf
On 08/03/2022 00:17, Michael Niedermayer wrote: Signed-off-by: Michael Niedermayer --- doc/bitstream_filters.texi | 15 libavcodec/Makefile | 1 + libavcodec/bitstream_filters.c | 1 + libavcodec/dv_error_marker_bsf.c | 117 +++ 4 files changed, 134 insertions(+) create mode 100644 libavcodec/dv_error_marker_bsf.c diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi index a0092878c8..6a882ade97 100644 --- a/doc/bitstream_filters.texi +++ b/doc/bitstream_filters.texi @@ -132,6 +132,21 @@ the header stored in extradata to the key packets: ffmpeg -i INPUT -map 0 -flags:v +global_header -c:v libx264 -bsf:v dump_extra out.ts @end example +@section dv_error_marker + +Blocks in DV which are marked as damaged are replaced by blocks of the specified color. + +@table @option +@item color +The color to replace damaged blocks by +@item sta +The error status to replace. If -1 then the stamask is used. -1 is the default. +@item stamask +A 16 bit mask which specifies which of the 16 possible error status values are +to be replaced by colored blocks. 0xFFFE is the default which replaces all non 0 +error status values. +@end table + @section eac3_core [...] In my opinion it would be more user-friendly to use a single "status" option of AV_OPT_TYPE_FLAGS with "s0" ... "s15" constants, instead of the "sta"/"stamask" option pair. Maybe there also could be constants for hard errors (STA = 0111 / ) and error concealment types A/B/C to make the option value readable. Also it would be nice to add the link to S314M documentation pages also in the option documentation. Regards, Tobias ___ 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/6] lavf: improve AV_DISPOSITION_* doxy
On 12/11/2021 17:32, Anton Khirnov wrote:
Also switch the values definition to the (1 << N) style, which is easier
to read.
---
libavformat/avformat.h | 96 +-
1 file changed, 77 insertions(+), 19 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index a2af7e9f89..7d8ad08f07 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -803,22 +803,56 @@ typedef struct AVIndexEntry {
int min_distance; /**< Minimum distance between this and the
previous keyframe, used to avoid unneeded searching. */
} AVIndexEntry;
-#define AV_DISPOSITION_DEFAULT 0x0001
-#define AV_DISPOSITION_DUB 0x0002
-#define AV_DISPOSITION_ORIGINAL 0x0004
-#define AV_DISPOSITION_COMMENT 0x0008
-#define AV_DISPOSITION_LYRICS0x0010
-#define AV_DISPOSITION_KARAOKE 0x0020
+/**
+ * The stream should be chosen by default among other streams of the same time,
+ * unless the user has explicitly specified otherwise.
+ */
+#define AV_DISPOSITION_DEFAULT (1 << 0)
+/**
+ * The stream is not in original language.
+ *
+ * @note AV_DISPOSITION_ORIGINAL is the inverse of this disposition. At most of
+ * them should be set in properly tagged streams.
+ * @note This disposition may apply to any stream type, not just audio.
+ */
+#define AV_DISPOSITION_DUB (1 << 1)
"At most of them" -> "At most one of them ..."?
Regards,
Tobias
___
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/1] Print bit depth when executing 'ffmpeg -pix_fmts'
On 13/10/2021 06:58, Soft Works wrote: New output looks like this: Pixel formats: I = Supported Input format for conversion .O... = Supported Output format for conversion ..H.. = Hardware accelerated format ...P. = Paletted format B = Bitstream format FLAGS NAMENB_COMPONENTS BITS_PER_PIXEL BIT_DEPTH - IO... yuv420p3 12 8 IO... yuyv4223 16 8 IO... rgb24 3 24 8 IO... bgr24 3 24 8 [...] @@ -1772,7 +1772,8 @@ int show_pix_fmts(void *optctx, const char *opt, const char *arg) pix_desc->flags & AV_PIX_FMT_FLAG_BITSTREAM ? 'B' : '.', pix_desc->name, pix_desc->nb_components, - av_get_bits_per_pixel(pix_desc)); + av_get_bits_per_pixel(pix_desc), + pix_desc->comp[0].depth); } return 0; } I think it is misleading to only print the bit-depth of the first component. You can already get bit-depth information for all components in different data formats with "ffprobe -show_pixel_formats". Regards, Tobias ___ 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] fftools/ffprobe: Don't access AVProgram.(start|end)_time
On 14.09.2021 15:05, Andreas Rheinhardt wrote: These are internal fields. Signed-off-by: Andreas Rheinhardt --- Thanks, Tobias. I guess this version is fine, isn't it? doc/ffprobe.xsd | 4 fftools/ffprobe.c | 4 2 files changed, 8 deletions(-) Changes in ffprobe.c and ffprobe.xsd do match now, so should be fine. Regards, Tobias ___ 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 07/18] fftools/play, probe: Adjust for subtitle format type change
On 11.09.2021 08:02, Soft Works wrote:
Signed-off-by: softworkz
---
fftools/ffplay.c | 2 +-
fftools/ffprobe.c | 23 ++-
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 46758b9f55..f6a4d242c3 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -2250,7 +2250,7 @@ static int subtitle_thread(void *arg)
pts = 0;
-if (got_subtitle && sp->sub.format == 0) {
+if (got_subtitle && sp->sub.format == AV_SUBTITLE_FMT_BITMAP) {
if (sp->sub.pts != AV_NOPTS_VALUE)
pts = sp->sub.pts / (double)AV_TIME_BASE;
sp->pts = pts;
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index acfec09656..fb55f3b292 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2212,6 +2212,7 @@ static void show_subtitle(WriterContext *w, AVSubtitle
*sub, AVStream *stream,
AVFormatContext *fmt_ctx)
{
AVBPrint pbuf;
+const char *s;
av_bprint_init(, 1, AV_BPRINT_SIZE_UNLIMITED);
@@ -2220,7 +2221,27 @@ static void show_subtitle(WriterContext *w, AVSubtitle *sub, AVStream *stream,
print_str ("media_type", "subtitle");
print_ts ("pts", sub->pts);
print_time("pts_time",sub->pts, _TIME_BASE_Q);
-print_int ("format", sub->format);
+
+// Remain compatible with previous outputs?
+switch (sub->format) {
+case AV_SUBTITLE_FMT_BITMAP:
+print_int ("format", 0);
+break;
+case AV_SUBTITLE_FMT_TEXT:
+print_int ("format", 1);
+break;
+case AV_SUBTITLE_FMT_ASS:
+print_int ("format", 1);
+break;
+default:
+print_int ("format", -1);
+break;
+}
+
+s = av_get_subtitle_fmt_name(sub->format);
+if (s) print_str("format_str", s);
+else print_str_opt("format_str", "unknown");
+
print_int ("start_display_time", sub->start_display_time);
print_int ("end_display_time",sub->end_display_time);
print_int ("num_rects", sub->num_rects);
In any case the new attribute should be added to the "subtitle" element
type definition in doc/ffprobe.xsd.
Regards,
Tobias
___
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/14] fftools/ffprobe: Don't access AVProgram.(start|end)_time
On 09.09.2021 17:57, Andreas Rheinhardt wrote:
These are internal fields.
Signed-off-by: Andreas Rheinhardt
---
show_program() is only entered by three tests: mpegts-probe-pmt-merge,
mpegts-probe-program and mpegts-probe-latm. Even mpegts-probe-latm does
not print detailed information about programs, hence the lack of
FATE-updates.
fftools/ffprobe.c | 4
1 file changed, 4 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index acfec09656..d8e968321e 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2844,10 +2844,6 @@ static int show_program(WriterContext *w, InputFile
*ifile, AVProgram *program)
print_int("nb_streams", program->nb_stream_indexes);
print_int("pmt_pid", program->pmt_pid);
print_int("pcr_pid", program->pcr_pid);
-print_ts("start_pts", program->start_time);
-print_time("start_time", program->start_time, _TIME_BASE_Q);
-print_ts("end_pts", program->end_time);
-print_time("end_time", program->end_time, _TIME_BASE_Q);
if (do_show_program_tags)
ret = show_tags(w, program->metadata, SECTION_ID_PROGRAM_TAGS);
if (ret < 0)
The "program" element type definition in doc/ffprobe.xsd should be
adjusted accordingly.
Regards,
Tobias
___
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] ffprobe: use quotation marks in the xml header output
On 14.07.2021 16:57, James Almer wrote:
xmllint (silently) replaces the ' with " when fixing and validating the output
of ffprobe in fate-ffprobe_xsd.
Signed-off-by: James Almer
---
fftools/ffprobe.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 2d452c212e..94c73fd32c 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -1682,9 +1682,9 @@ static void xml_print_section_header(WriterContext *wctx)
wctx->section[wctx->level-1] : NULL;
if (wctx->level == 0) {
-const char *qual = " xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
"
-"xmlns:ffprobe='http://www.ffmpeg.org/schema/ffprobe' "
-"xsi:schemaLocation='http://www.ffmpeg.org/schema/ffprobe
ffprobe.xsd'";
+const char *qual = "
xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\; "
+"xmlns:ffprobe=\"http://www.ffmpeg.org/schema/ffprobe\; "
+"xsi:schemaLocation=\"http://www.ffmpeg.org/schema/ffprobe
ffprobe.xsd\"";
printf("\n");
printf("<%sffprobe%s>\n",
Both, single and double quotes are technically valid for XML attributes.
But I agree that it is better to use double quotes here as they are used
for attributes throughout the ffprobe XML writer.
Regards,
Tobias
___
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/2] avfilter/af_astats: Only print header lines when values are to be printed
On 08.04.2021 08:41, Tobias Rapp wrote: On 07.04.2021 19:25, Paul B Mahol wrote: Please ask someone else to apply it. I can technically commit the patches but would prefer if some second pair of eyes could take a look. So will apply them in a week from now if nobody objects. Applied this first part of the patch-set as it seemed non-controversial. Regards, Tobias ___ 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] fate/ffprobe: Verify ffprobe XML output against schema file
On 30.06.2021 10:20, Tobias Rapp wrote: On 16.04.2021 10:58, Tobias Rapp wrote: Adds schema validation for ffprobe XML output so that updating the ffprobe.xsd file upon changes to ffprobe is not forgotten. This was suggested by Marton Balint in: http://ffmpeg.org/pipermail/ffmpeg-devel/2021-March/278428.html The schema FATE test is only run if xmllint command is available. Signed-off-by: Tobias Rapp --- configure | 3 +++ tests/fate/ffprobe.mak | 6 + tests/ref/fate/ffprobe_xsd | 57 ++ 3 files changed, 66 insertions(+) create mode 100644 tests/ref/fate/ffprobe_xsd [...] Would like to push this in a week or so, if there are no objections. Patch applied. Regards, Tobias ___ 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] fate/ffprobe: Verify ffprobe XML output against schema file
On 16.04.2021 10:58, Tobias Rapp wrote: Adds schema validation for ffprobe XML output so that updating the ffprobe.xsd file upon changes to ffprobe is not forgotten. This was suggested by Marton Balint in: http://ffmpeg.org/pipermail/ffmpeg-devel/2021-March/278428.html The schema FATE test is only run if xmllint command is available. Signed-off-by: Tobias Rapp --- configure | 3 +++ tests/fate/ffprobe.mak | 6 + tests/ref/fate/ffprobe_xsd | 57 ++ 3 files changed, 66 insertions(+) create mode 100644 tests/ref/fate/ffprobe_xsd [...] Would like to push this in a week or so, if there are no objections. Regards, Tobias ___ 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] avfilter/select: add metadata detection function
On 18.06.2021 14:50, Timo Rothenpieler wrote:
> [...]
>
> +@item detected(kind)
> +Evaluates the metadata added to frames by various detection filters.
> +Returns -1 if the respective filter has detected what it was looking
for,
> +0 otherwise.
> +
> +Possible values for the @var{kind} parameter:
> +@table @option
> +@item SILENCE (audio only)
> +Looks for metadata added by @ref{silencedetect}.
> +@item FREEZE (video only)
> +Looks for metadata added by @ref{freezedetect}.
> +@item BLACK (video only)
> +Looks for metadata added by @ref{blackdetect}.
> +@end table
> +
> @end table
If I understand that description correctly a filter line like
"aselect=detected(SILENCE)" kill keep the silence and remove the rest?
So for most use cases a wrapping not() shall be used? Adding an example
in the docs might clarify this.
I think it is a bit unfortunate that the new syntax differs from the
existing "concatdec_select" which is similar in concept. In my very
personal opinion using variables like "silence_detected" would have been
more consistent, but take this as a suggestion - not objection.
Regards,
Tobias
___
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] ffprobe: add decode_error_flags
On 27.05.2021 20:09, Marton Balint wrote: [...] An alternative approach is to print the meaning of the actually used flags: concealment_active="0" decode_slices="0" /> This is the most readable, but maybe too verbose for the default use? This would match how pixfmt flags are currently printed by ffprobe. I agree that this is readable and avoids duplicating the flag constants on the parsing side. But as it would be printed for each frame and takes up multiple lines for some output formats I think its quite verbose. The current output of AVPacket flags takes another approach by printing a single-letter character for each flag bit, like 'K' for keyframe and 'D' for discard. That might be a good compromise, in my opinion. Regards, Tobias ___ 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] ffprobe: add decode_error_flags
On 25.05.2021 13:27, Nicolas George wrote:
Michael Niedermayer (12021-05-25):
Signed-off-by: Michael Niedermayer
---
doc/ffprobe.xsd| 1 +
fftools/ffprobe.c | 2 +
tests/ref/fate/exif-image-embedded | 22 ++
tests/ref/fate/exif-image-jpg | 1 +
tests/ref/fate/exif-image-tiff | 1 +
tests/ref/fate/exif-image-webp | 1 +
tests/ref/fate/ffprobe_compact | 28 +--
tests/ref/fate/ffprobe_csv | 28 +--
tests/ref/fate/ffprobe_default | 14 ++
tests/ref/fate/ffprobe_flat| 14 ++
tests/ref/fate/ffprobe_ini | 14 ++
tests/ref/fate/flcl1905| 352 ++---
tests/ref/fate/h264-dts_5frames| 5 +
tests/ref/fate/mov-zombie | 130 +--
tests/ref/fate/png-side-data | 1 +
15 files changed, 345 insertions(+), 269 deletions(-)
diff --git a/doc/ffprobe.xsd b/doc/ffprobe.xsd
index 250de8cd5c..370d68374c 100644
--- a/doc/ffprobe.xsd
+++ b/doc/ffprobe.xsd
@@ -96,6 +96,7 @@
+
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 88e82a4195..37aec0564a 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2259,6 +2259,8 @@ static void show_frame(WriterContext *w, AVFrame *frame,
AVStream *stream,
else print_str_opt("pkt_pos", "N/A");
if (frame->pkt_size != -1) print_val("pkt_size", frame->pkt_size,
unit_byte_str);
else print_str_opt("pkt_size", "N/A");
+if (frame->decode_error_flags) print_fmt("decode_error_flags", "0x%x",
frame->decode_error_flags);
+else print_str_opt("decode_error_flags", "0");
Since the value is an int, I think it would be better to have it
declared as a number, even if it cannot be in hex.
IMHO for bit-fields an hexadecimal number may be more readable. My
improvement suggestion would be to use some zero-padded formatting like
"0x%02x" and also use a hexadecimal value "0x00" for the default case
for consistency.
Just my 2ct,
Tobias
___
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] ffprobe as library rather than CLI
On 12.05.2021 15:52, Timo Rothenpieler wrote: On 12.05.2021 15:19, Samuel Marks wrote: Started hacking around to make it work. So I changed the `main` to a: extern int ffprobe(int argc, char **argv); Then I added a header with a prototype of the same, and started messing with vcpkg + CMake to try and get it to build correctly. That's not going to work. The whole thing is not designed to be called more than once, and you can be close to certain that it's going to fail miserably and in unexpected ways. Use the libraries if you want to integrate ffmpeg functionality into your own application. Another alternative would be to run ffprobe as a separate process using fork() and execv() on Linux, or CreateProcessW() on Windows. Optionally you can use pipes to redirect the stdout of ffprobe to your parent application. A quick online search finds this code example for C (have not tested it but the general concept looks fine to me): https://stackoverflow.com/a/83456 Good luck, Tobias ___ 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 2/2] avfilter/af_astats: Remove fraction part of integer metadata entries
On 09.04.2021 09:58, Tobias Rapp wrote: On 08.04.2021 11:34, Nicolas George wrote: Anton Khirnov (12021-04-08): Does this mean that there are no stability guarantees for metadata exported by filters? We can have stability for the components that are good enough to be stable, and no stability yet for components that need enhancing. Indeed I should at least increment the minor (or micro?) version for libavfilter. And for the metadata changes my goal was to make some obvious things like "lavfi.astats.Bit_depth=24.00" less weird. I didn't dare to touch other things. As the astats filter metadata is not tested by FATE my guess was that stability is not yet a high priority. BTW: After the change metadata key names match what is documented in http://ffmpeg.org/ffmpeg-filters.html#astats-1 regarding underscores and the "Overall" prefix. Have added an increment of the minor version in libavfilter/version.h locally. So I guess this patch should be fine now? Regards, Tobias ___ 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] fate/ffprobe: Verify ffprobe XML output against schema file
Adds schema validation for ffprobe XML output so that updating the
ffprobe.xsd file upon changes to ffprobe is not forgotten. This was
suggested by Marton Balint in:
http://ffmpeg.org/pipermail/ffmpeg-devel/2021-March/278428.html
The schema FATE test is only run if xmllint command is available.
Signed-off-by: Tobias Rapp
---
configure | 3 +++
tests/fate/ffprobe.mak | 6 +
tests/ref/fate/ffprobe_xsd | 57 ++
3 files changed, 66 insertions(+)
create mode 100644 tests/ref/fate/ffprobe_xsd
diff --git a/configure b/configure
index d7a3f50..b8ad7f9 100755
--- a/configure
+++ b/configure
@@ -2341,6 +2341,7 @@ HAVE_LIST="
perl
pod2man
texi2html
+xmllint
"
# options emitted with CONFIG_ prefix but not available on the command line
@@ -6599,6 +6600,7 @@ disabled makeinfo_html && texi2html --help 2> /dev/null |
grep -q 'init-file' &&
perl -v> /dev/null 2>&1 && enable perl || disable perl
pod2man --help > /dev/null 2>&1 && enable pod2man || disable pod2man
rsync --help 2> /dev/null | grep -q 'contimeout' && enable rsync_contimeout ||
disable rsync_contimeout
+xmllint --version > /dev/null 2>&1 && enable xmllint || disable xmllint
# check V4L2 codecs available in the API
if enabled v4l2_m2m; then
@@ -7365,6 +7367,7 @@ echo "perl enabled ${perl-no}"
echo "pod2man enabled ${pod2man-no}"
echo "makeinfo enabled ${makeinfo-no}"
echo "makeinfo supports HTML${makeinfo_html-no}"
+echo "xmllint enabled ${xmllint-no}"
test -n "$random_seed" &&
echo "random seed ${random_seed}"
echo
diff --git a/tests/fate/ffprobe.mak b/tests/fate/ffprobe.mak
index c867beb..d2abe8a 100644
--- a/tests/fate/ffprobe.mak
+++ b/tests/fate/ffprobe.mak
@@ -29,6 +29,12 @@ FATE_FFPROBE-$(CONFIG_AVDEVICE) += fate-ffprobe_xml
fate-ffprobe_xml: $(FFPROBE_TEST_FILE)
fate-ffprobe_xml: CMD = run $(FFPROBE_COMMAND) -of xml
+FATE_FFPROBE_SCHEMA-$(CONFIG_AVDEVICE) += fate-ffprobe_xsd
+fate-ffprobe_xsd: $(FFPROBE_TEST_FILE)
+fate-ffprobe_xsd: CMD = run $(FFPROBE_COMMAND) -noprivate -of xml=q=1:x=1 | \
+ xmllint --schema $(SRC_PATH)/doc/ffprobe.xsd -
+
+FATE_FFPROBE-$(HAVE_XMLLINT) += $(FATE_FFPROBE_SCHEMA-yes)
FATE_FFPROBE += $(FATE_FFPROBE-yes)
fate-ffprobe: $(FATE_FFPROBE)
diff --git a/tests/ref/fate/ffprobe_xsd b/tests/ref/fate/ffprobe_xsd
new file mode 100644
index 000..cb3413e
--- /dev/null
+++ b/tests/ref/fate/ffprobe_xsd
@@ -0,0 +1,57 @@
+
+http://www.w3.org/2001/XMLSchema-instance;
xmlns:ffprobe="http://www.ffmpeg.org/schema/ffprobe;
xsi:schemaLocation="http://www.ffmpeg.org/schema/ffprobe ffprobe.xsd">
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
--
2.7.4
___
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/2] fftools/ffprobe: Remove check on show_frames and show_packets in XML writer
On 13.04.2021 08:54, Tobias Rapp wrote: On 31.03.2021 12:13, Tobias Rapp wrote: The "packets_and_frames" element has been added to ffprobe.xsd in 0c9f0da0f7656059e9bd41931d250aafddf35ea3 but apparently removing the check in ffprobe.c has been forgotten. Signed-off-by: Tobias Rapp --- fftools/ffprobe.c | 7 --- 1 file changed, 7 deletions(-) [..] BTW, this can be tested using a command-line like: ffprobe -show_streams -show_packets -show_format -show_frames \ tests/data/ffprobe-test.nut -noprivate -of xml=q=1:x=1 | \ xmllint --noout --schema doc/ffprobe.xsd - If there are no objections I'd like to apply both patches at the end of this week. Applied both patches. Regards, Tobias ___ 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/2] fftools/ffprobe: Remove check on show_frames and show_packets in XML writer
On 31.03.2021 12:13, Tobias Rapp wrote: The "packets_and_frames" element has been added to ffprobe.xsd in 0c9f0da0f7656059e9bd41931d250aafddf35ea3 but apparently removing the check in ffprobe.c has been forgotten. Signed-off-by: Tobias Rapp --- fftools/ffprobe.c | 7 --- 1 file changed, 7 deletions(-) [..] BTW, this can be tested using a command-line like: ffprobe -show_streams -show_packets -show_format -show_frames \ tests/data/ffprobe-test.nut -noprivate -of xml=q=1:x=1 | \ xmllint --noout --schema doc/ffprobe.xsd - If there are no objections I'd like to apply both patches at the end of this week. Regards, Tobias ___ 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 2/2] avfilter/af_astats: Remove fraction part of integer metadata entries
On 08.04.2021 11:34, Nicolas George wrote: Anton Khirnov (12021-04-08): Does this mean that there are no stability guarantees for metadata exported by filters? We can have stability for the components that are good enough to be stable, and no stability yet for components that need enhancing. Indeed I should at least increment the minor (or micro?) version for libavfilter. And for the metadata changes my goal was to make some obvious things like "lavfi.astats.Bit_depth=24.00" less weird. I didn't dare to touch other things. As the astats filter metadata is not tested by FATE my guess was that stability is not yet a high priority. Regards, Tobias ___ 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/2] avfilter/af_astats: Only print header lines when values are to be printed
On 07.04.2021 19:25, Paul B Mahol wrote: Please ask someone else to apply it. I can technically commit the patches but would prefer if some second pair of eyes could take a look. So will apply them in a week from now if nobody objects. Regards, Tobias ___ 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/2] avfilter/af_astats: Only print header lines when values are to be printed
On 26.03.2021 13:58, Tobias Rapp wrote: Avoids empty "Channel" or "Overall" header lines added to log output when measurement is restricted to one scope using "measure_perchannel=none" or "measure_overall=none". Signed-off-by: Tobias Rapp --- libavfilter/af_astats.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) [...] A gentle ping for both patches. I'm putting Paul on CC as he seems to be the author of the most recent changes. Regards, Tobias ___ 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/2] doc/ffprobe.xsd: Clean-up choice indicator definitions
Remove the unneeded wrapping sequence element. Also the minOccurs/maxOccurs occurrence inicators on the inner element definitions can be removed. Signed-off-by: Tobias Rapp --- doc/ffprobe.xsd | 22 +- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git a/doc/ffprobe.xsd b/doc/ffprobe.xsd index a9ffe57..250de8c 100644 --- a/doc/ffprobe.xsd +++ b/doc/ffprobe.xsd @@ -29,22 +29,18 @@ - - - - - - + + + + - - - - - - - + + + + + -- 2.7.4 ___ 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 1/2] fftools/ffprobe: Remove check on show_frames and show_packets in XML writer
The "packets_and_frames" element has been added to ffprobe.xsd in
0c9f0da0f7656059e9bd41931d250aafddf35ea3 but apparently removing the
check in ffprobe.c has been forgotten.
Signed-off-by: Tobias Rapp
---
fftools/ffprobe.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 38462e1..1bfc144 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -1660,13 +1660,6 @@ static av_cold int xml_init(WriterContext *wctx)
CHECK_COMPLIANCE(show_private_data, "private");
CHECK_COMPLIANCE(show_value_unit, "unit");
CHECK_COMPLIANCE(use_value_prefix, "prefix");
-
-if (do_show_frames && do_show_packets) {
-av_log(wctx, AV_LOG_ERROR,
- "Interleaved frames and packets are not allowed in XSD. "
- "Select only one between the -show_frames and the
-show_packets options.\n");
-return AVERROR(EINVAL);
-}
}
return 0;
--
2.7.4
___
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/2] fftools/ffprobe: Add missing dispositions
On 30.03.2021 19:51, Marton Balint wrote: [...] I wonder if a fate test testing the XML output of ffprobe can be extended to do a validation of the XML via the XSD so this does not gets forgatten... I agree that would be great. But I guess we cannot depend on a tool like xmllint being available on all platforms where FATE is running. Even when writing an own test tool based on libxml2 directly this might not get good coverage as this library is currently only used for dashdec and not auto-detected. But maybe it would at least get _some_ testing. Regards, Tobias ___ 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/2] avfilter/af_astats: Remove fraction part of integer metadata entries
Using integer format makes the metadata display similar to the log output.
Fix missing "Overall" metadata key name prefix where necessary. Also
replace whitespace in some metadata key names with underscore character
for consistency.
Signed-off-by: Tobias Rapp
---
libavfilter/af_astats.c | 56 +++--
1 file changed, 31 insertions(+), 25 deletions(-)
diff --git a/libavfilter/af_astats.c b/libavfilter/af_astats.c
index c13df62..3b248b9 100644
--- a/libavfilter/af_astats.c
+++ b/libavfilter/af_astats.c
@@ -390,18 +390,24 @@ static inline void update_double_stat(AudioStatsContext
*s, ChannelStats *p, dou
p->nb_denormals += type == FP_SUBNORMAL;
}
-static void set_meta(AVDictionary **metadata, int chan, const char *key,
- const char *fmt, double val)
+static av_printf_format(4, 5) void set_meta(AVDictionary **metadata, int chan,
+const char *key, const char *value, ...)
{
-uint8_t value[128];
-uint8_t key2[128];
-
-snprintf(value, sizeof(value), fmt, val);
-if (chan)
-snprintf(key2, sizeof(key2), "lavfi.astats.%d.%s", chan, key);
-else
-snprintf(key2, sizeof(key2), "lavfi.astats.%s", key);
-av_dict_set(metadata, key2, value, 0);
+va_list argument_list;
+
+va_start(argument_list, value);
+if (value) {
+char keybuf[128];
+char valbuf[128];
+if (chan) {
+snprintf(keybuf, sizeof(keybuf), "lavfi.astats.%d.%s", chan, key);
+} else {
+snprintf(keybuf, sizeof(keybuf), "lavfi.astats.%s", key);
+}
+vsnprintf(valbuf, sizeof(valbuf), value, argument_list);
+av_dict_set(metadata, keybuf, valbuf, 0);
+}
+va_end(argument_list);
}
#define LINEAR_TO_DB(x) (log10(x) * 20)
@@ -484,28 +490,28 @@ static void set_metadata(AudioStatsContext *s,
AVDictionary **metadata)
if (s->measure_perchannel & MEASURE_FLAT_FACTOR)
set_meta(metadata, c + 1, "Flat_factor", "%f",
LINEAR_TO_DB((p->min_runs + p->max_runs) / (p->min_count + p->max_count)));
if (s->measure_perchannel & MEASURE_PEAK_COUNT)
-set_meta(metadata, c + 1, "Peak_count", "%f", (float)(p->min_count
+ p->max_count));
+set_meta(metadata, c + 1, "Peak_count", "%"PRId64, p->min_count +
p->max_count);
if (s->measure_perchannel & MEASURE_NOISE_FLOOR)
set_meta(metadata, c + 1, "Noise_floor", "%f",
LINEAR_TO_DB(p->noise_floor));
if (s->measure_perchannel & MEASURE_NOISE_FLOOR_COUNT)
-set_meta(metadata, c + 1, "Noise_floor_count", "%f",
p->noise_floor_count);
+set_meta(metadata, c + 1, "Noise_floor_count", "%"PRId64,
p->noise_floor_count);
if (s->measure_perchannel & MEASURE_BIT_DEPTH) {
bit_depth(s, p->mask, p->imask, );
-set_meta(metadata, c + 1, "Bit_depth", "%f", depth.num);
-set_meta(metadata, c + 1, "Bit_depth2", "%f", depth.den);
+set_meta(metadata, c + 1, "Bit_depth", "%u", depth.num);
+set_meta(metadata, c + 1, "Bit_depth2", "%u", depth.den);
}
if (s->measure_perchannel & MEASURE_DYNAMIC_RANGE)
set_meta(metadata, c + 1, "Dynamic_range", "%f", LINEAR_TO_DB(2 *
FFMAX(FFABS(p->min), FFABS(p->max))/ p->min_non_zero));
if (s->measure_perchannel & MEASURE_ZERO_CROSSINGS)
-set_meta(metadata, c + 1, "Zero_crossings", "%f", p->zero_runs);
+set_meta(metadata, c + 1, "Zero_crossings", "%"PRId64,
p->zero_runs);
if (s->measure_perchannel & MEASURE_ZERO_CROSSINGS_RATE)
set_meta(metadata, c + 1, "Zero_crossings_rate", "%f",
p->zero_runs/(double)p->nb_samples);
if ((s->is_float || s->is_double) && s->measure_perchannel &
MEASURE_NUMBER_OF_NANS)
-set_meta(metadata, c + 1, "Number of NaNs", "%f", p->nb_nans);
+set_meta(metadata, c + 1, "Number_of_NaNs", "%"PRId64, p->nb_nans);
if ((s->is_float || s->is_double) && s->measure_perchannel &
MEASURE_NUMBER_OF_INFS)
-set_meta(metadata, c + 1, "Number of Infs", "%f", p->nb_infs);
+set_meta(metadata, c + 1, "Number_of_Infs", "%"PRId64, p->nb_infs);
if ((s->is_float || s->is_double) && s->measure_perchannel &
MEASURE_NUMBER_OF_DENORMALS)
-set_meta(metadata, c + 1, "Number of
[FFmpeg-devel] [PATCH 1/2] avfilter/af_astats: Only print header lines when values are to be printed
Avoids empty "Channel" or "Overall" header lines added to log output when measurement is restricted to one scope using "measure_perchannel=none" or "measure_overall=none". Signed-off-by: Tobias Rapp --- libavfilter/af_astats.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/libavfilter/af_astats.c b/libavfilter/af_astats.c index f50cbe1..c13df62 100644 --- a/libavfilter/af_astats.c +++ b/libavfilter/af_astats.c @@ -705,7 +705,8 @@ static void print_stats(AVFilterContext *ctx) if (fabs(p->sigma_x) > fabs(max_sigma_x)) max_sigma_x = p->sigma_x; -av_log(ctx, AV_LOG_INFO, "Channel: %d\n", c + 1); +if (s->measure_perchannel != MEASURE_NONE) +av_log(ctx, AV_LOG_INFO, "Channel: %d\n", c + 1); if (s->measure_perchannel & MEASURE_DC_OFFSET) av_log(ctx, AV_LOG_INFO, "DC offset: %f\n", p->sigma_x / p->nb_samples); if (s->measure_perchannel & MEASURE_MIN_LEVEL) @@ -757,7 +758,8 @@ static void print_stats(AVFilterContext *ctx) av_log(ctx, AV_LOG_INFO, "Number of denormals: %"PRId64"\n", p->nb_denormals); } -av_log(ctx, AV_LOG_INFO, "Overall\n"); +if (s->measure_overall != MEASURE_NONE) +av_log(ctx, AV_LOG_INFO, "Overall\n"); if (s->measure_overall & MEASURE_DC_OFFSET) av_log(ctx, AV_LOG_INFO, "DC offset: %f\n", max_sigma_x / (nb_samples / s->nb_channels)); if (s->measure_overall & MEASURE_MIN_LEVEL) -- 2.7.4 ___ 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] doc/encoders: remove text about single bit-depth libx264 support
On 15.03.2021 17:19, Gyan Doshi wrote: On 2021-03-15 18:54, Tobias Rapp wrote: In the meanwhile libx264 allows to be configured for including both 8/10 bit support within a single library. The new libx264 interface was enabled in 2f96190732d15510ba29471fa45d66841c0c3df1. Signed-off-by: Tobias Rapp --- doc/encoders.texi | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/doc/encoders.texi b/doc/encoders.texi index c9c8785a..a92eb0e 100644 --- a/doc/encoders.texi +++ b/doc/encoders.texi @@ -2305,9 +2305,7 @@ pixel formats as input instead of YUV. @subsection Supported Pixel Formats x264 supports 8- to 10-bit color spaces. The exact bit depth is controlled at -x264's configure time. FFmpeg only supports one bit depth in one particular -build. In other words, it is not possible to build one FFmpeg with multiple -versions of x264 with different bit depths. +x264's configure time. @subsection Options LGTM. Pushed, thanks for review. Tobias ___ 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] doc/encoders: remove text about single bit-depth libx264 support
In the meanwhile libx264 allows to be configured for including both 8/10 bit support within a single library. The new libx264 interface was enabled in 2f96190732d15510ba29471fa45d66841c0c3df1. Signed-off-by: Tobias Rapp --- doc/encoders.texi | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/doc/encoders.texi b/doc/encoders.texi index c9c8785a..a92eb0e 100644 --- a/doc/encoders.texi +++ b/doc/encoders.texi @@ -2305,9 +2305,7 @@ pixel formats as input instead of YUV. @subsection Supported Pixel Formats x264 supports 8- to 10-bit color spaces. The exact bit depth is controlled at -x264's configure time. FFmpeg only supports one bit depth in one particular -build. In other words, it is not possible to build one FFmpeg with multiple -versions of x264 with different bit depths. +x264's configure time. @subsection Options -- 2.7.4 ___ 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 v4 3/3] avformat/mxfenc: prefer to use the configured metadta
On 26.01.2021 16:39, Tomas Härdin wrote: tis 2021-01-26 klockan 00:34 +0100 skrev Marton Balint: Maybe they should post patches instead of having workarounds? And I explained, libavformat MXF muxer will still be identifiable, but the proper field will be used for identifying the SDK used, not Company/Product but Toolkit/Platform. I'll just add that I've read the updated version of S377m from 2007 and this sounds like the best solution. In short something like this: CompanyName: FFmpeg Product: OP1a Muxer Platform: libavformat x.y.z (Debian GNU/Linux 10 (buster)) If we delete the metadata in ffmpeg_opt.c like the original patch does here, and have Platform be the only hardcoded string, then hopefully everyone should be relatively happy. So CompanyName and Product can be changed from the command line/API but Platform cannot. Sounds reasonable to me. Regards, Tobias ___ 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 v4 3/3] avformat/mxfenc: prefer to use the configured metadta
On 25.01.2021 20:40, emco...@ffastrans.com wrote: [...] What you can do instead is to push both identifications, the old one and the one from the current program into the identification array, this way the processing chain can be reconstructed. Unforutnately i have never seen anyone doing this besides Opencube. This might work when your whole chain is built on a single container format (MXF). As soon as there is a mix of formats it is easier to store the processing chain information as a separate file. PREMIS is some standard for doing this, but it has quite some overhead: http://www.loc.gov/standards/premis/premis-mets.html Not sure how popular it is. Regards, Tobias ___ 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 v4 3/3] avformat/mxfenc: prefer to use the configured metadta
On 18.01.2021 23:53, Tomas Härdin wrote: lör 2021-01-16 klockan 08:43 +0800 skrev lance.lmw...@gmail.com: On Fri, Jan 15, 2021 at 09:43:58PM +0100, Marton Balint wrote: On Fri, 15 Jan 2021, Tomas Härdin wrote: Again, why? If you have a company that maintains a fork of FFmpeg then compile that info in here instead. Compare with FFmbc which always puts "FFmbc" as CompanyName. And how can a product based on libavformat set the company name, product name and product version? It seems a valid use case for me that these are overridable. Also note that this product version is only the "user friendly" version string, for the numeric version still LIBAVFORMAT_VERSION values are used. Yes, my use case is the product is using libavformat as library, so it's prefer to have way to override these information as requirements. What I'm worried about here is that we're going to get files which claim to have been written by something other than libavformat. I've had situations like this before, and it is a source of headache. For example, if mxfenc writes some field incorrectly then this might cause us to hack mxfdec to accept that field instead of fixing mxfenc. I agree that especially for the MXF format with its flexible structure it is more relevant to know the muxing library rather than the hosting application. Have seen MXF output files of other commercial products that also contain library identifiers like "libMXF" or "MXFtk" here. Other formats in FFmpeg use the "encoder" metadata key for embedding library information in the output file. A quick test with AVI output shows that this metadata is generated internally and cannot be overridden on the command-line. Regards, Tobias ___ 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 3/3] avformat/mxfenc: prefer to use the existing metadata
On 08.01.2021 11:01, lance.lmw...@gmail.com wrote: On Fri, Jan 08, 2021 at 09:09:34AM +0100, Tobias Rapp wrote: On 08.01.2021 07:32, lance.lmw...@gmail.com wrote: From: Limin Wang Please check metadata with below command: ./ffmpeg -i ../fate-suite/mxf/Sony-1.mxf -c:v copy -c:a copy out.mxf ./ffmpeg -i out.mxf company_name: FFmpeg product_name: OP1a Muxer product_version : 58.65.101o => company_name: SONY product_name: eVTR product_version : 1.00 So need to update fate-mxf fate test. Signed-off-by: Limin Wang --- [...] In my opinion the MXF identification set should contain data about the application that wrote the current version of a file, not some previous file version. The example command shows what's change for the fate testing, if you want to update to use your own product version, please use -metadata product_version="x". It looks wrong that a MXF file that is muxed by FFmpeg pretends to be written by a SONY application. I see that with "-codec copy" you can avoid re-encoding of the video and audio streams, and thus might want to indicate the A/V encoder software info somewhere separate from the container format writer software. But this patch overrides both information. Regards, Tobias ___ 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 3/3] avformat/mxfenc: prefer to use the existing metadata
On 08.01.2021 07:32, lance.lmw...@gmail.com wrote: From: Limin Wang Please check metadata with below command: ./ffmpeg -i ../fate-suite/mxf/Sony-1.mxf -c:v copy -c:a copy out.mxf ./ffmpeg -i out.mxf company_name: FFmpeg product_name: OP1a Muxer product_version : 58.65.101o => company_name: SONY product_name: eVTR product_version : 1.00 So need to update fate-mxf fate test. Signed-off-by: Limin Wang --- [...] In my opinion the MXF identification set should contain data about the application that wrote the current version of a file, not some previous file version. Regards, Tobias ___ 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] Bundling ffmpeg into windows application
On 11.11.2020 17:15, Carl Eugen Hoyos wrote: Not necessarily related: In no way whatsoever does the LGPL mandate dynamic linking (this was claimed several times lately). The "License Compliance Checklist" on http://ffmpeg.org/legal.html lists dynamic linking under point 2. I know that in theory you could link proprietary applications with LGPL libraries statically. But this is not very practical, neither for the application publisher nor for the user that wants to relink the library. Regards, Tobias ___ 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] Bundling ffmpeg into windows application
On 11.11.2020 06:50, Brian D. Pemberton wrote: Hi, I am thinking about writing an app that bundles or includes FFmpeg to do some video processing. Is this allowed? If so, where can I read about the constraints or requirements of doing this? Also, is there anything I should know upfront to prepare my app licensing standpoint ahead of time? You might want to take a look at http://ffmpeg.org/legal.html first. The page gives details about using FFmpeg under LGPL. Note that if you license your app under GPL you also have the possibility for linking FFmpeg libraries statically. Regards, Tobias ___ 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] libavutil: add clean aperture (CLAP) side data.
On 30.05.2020 12:41, Kieran O Leary wrote: Hi, On Fri 29 May 2020, 22:47 Neil Birkbeck, wrote: [...] I've changed the side data to be PixelCrop (instead of CleanAperture) given the intent to reuse as cropping elsewhere. -For now, I've kept the rational representation--although CLAP seems to be the only required case of it. Maybe Kieran could comment on the requirement of having maintaining the rationals for CLAP (only works on mov to mov transmuxing). I'm no expert, but I think a lot of this just comes from video standards that stipulate those rational numbers? I've cc'd tobias Rapp and Christoph Gerstbauer of NOA just to bring this to their attention, as I'm pretty sure that they use cropping values in AVI, so perhaps all of this could be useful to them in some way. Hi Kieran, when digitizing SD video carriers we indeed store some offset information in case VBI is preverved (i.e. PAL 720x608). But these offset values are currently not stored in the AVI container itself. The OpenDML "vprp" chunk defines some offset values but for the purpose of compressed image data where the codec implies some multiple-of-N height/width dimension on the data. So it did not seem to match our use-case. Besides AVI and the mentioned MKV and MOV formats I remember some display offset/cropping information being stored in MXF with the Display X/Y-Offset values. Regardless whether the frame crop/offset values are stored as frame fields or side data: how would this information be affected by filters like "crop" or "scale"? Regards, Tobias ___ 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] avcodec/dvdec: add frame threads
On 18.04.2019 11:40, Michael Niedermayer wrote: On Thu, Apr 18, 2019 at 10:30:49AM +0200, Paul B Mahol wrote: On 4/18/19, Michael Niedermayer wrote: On Thu, Apr 18, 2019 at 01:19:58AM +0200, Michael Niedermayer wrote: On Wed, Apr 17, 2019 at 06:16:39PM +0200, Paul B Mahol wrote: Signed-off-by: Paul B Mahol --- libavcodec/dvdec.c | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) Is this intended to be 100% same output ? I have a few cases that produce differences. Dont have a good testcase though ./ffmpeg -i ~/tickets/1589/A1590.dv avi-b.avi produces different output. oddly -f framecrc produces the same output not sure this is a problem or not the input file may have issues heres another testcase: ./ffmpeg -i ~/tickets/2390/dv_cut.dv aviavi2.avi [...] This is because audio is muxed differently. This bug have nothing to do with this patch. iam not sure thats the case. Looking at this again now in the morning VPRP is different and the muxer receives a different par->field_order (0 vs. 5). I dont think audio should afect the video field_order That might be caused by frame-threading in general and not explicitly by the dv decoder. Have experienced field_order information not being reliably forwarded to the muxer in ffmpeg before. Seems sometimes the encoder settings are updated too late to be picked up by the muxer when writing header information. Regards, Tobias ___ 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] avfilter/af_asetnsamples: fix sample queuing.
On 06.04.2019 02:11, Nikolas Bowe via ffmpeg-devel wrote: When asetnsamples uses output samples < input samples, remaining samples build up in the fifo over time. Fix this by marking the filter as ready again if there are enough samples. Regression since ef3babb2c70f564dc1634b3f29c6e35a2b2dc239 [...] Do you have a FFmpeg command-line at hand that triggers this bug? Maybe extending FATE tests would be a good idea. Regards, Tobias ___ 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]download: Fix the release link
On 28.03.2019 15:02, Carl Eugen Hoyos wrote: 2019-03-28 15:00 GMT+01:00, Tobias Rapp : On 28.03.2019 12:00, Carl Eugen Hoyos wrote: Attached patch also simplifies the release process. Personally I'd prefer to keep the link to the latest release. Why? Such a link is already listed below. I always found it extremely disturbing and I realize now that it also was a (useless) maintenance burden. I don't want to start a snapshot-vs-release discussion. Merging the prominent "Download" button with "Download Snapshot" is also fine for me. Regards, Tobias ___ 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]download: Fix the release link
On 28.03.2019 12:00, Carl Eugen Hoyos wrote: Hi! Attached patch also simplifies the release process. Please comment, Carl Eugen Personally I'd prefer to keep the link to the latest release. There is already a "Download Snapshot" button on the "Get the Sources" panel. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [FFmpeg-cvslog] [ffmpeg-web] branch master updated. 2505968 web/download: Add FFmpeg 4.1.2
On 23.03.2019 01:03, ffmpeg-...@ffmpeg.org wrote: The branch, master has been updated via 2505968f485fae32d7a68881eff0187f346adb61 (commit) from b971570feed92970138b9234403d2ef213cf877e (commit) - Log - commit 2505968f485fae32d7a68881eff0187f346adb61 Author: Michael Niedermayer AuthorDate: Sat Mar 23 01:00:34 2019 +0100 Commit: Michael Niedermayer CommitDate: Sat Mar 23 01:01:26 2019 +0100 web/download: Add FFmpeg 4.1.2 Signed-off-by: Michael Niedermayer [...] It looks like the big download button on http://ffmpeg.org/download.html still points to ffmpeg-4.1.tar.bz2 instead of ffmpeg-4.1.2.tar.bz2 . Regards, Tobias ___ 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] Fix loss of precision for silencedetecton large files
On 27.03.2019 23:13, Allan Cady via ffmpeg-devel wrote: On Tue, Mar 26, 2019 at 10:07:10PM +, Allan Cady via ffmpeg-devel wrote: When the silencedetect filter is run against very large files, the output timestamps gradually lose precision as the scan proceeds further into the file. This is because the output is formatted (in libavutil/timestamp.h) as "%.6g", which limits the total field length. Eventually, for offsets greater than 10 seconds (about 28 hours), fractions of a second disappear altogether, and the timestamps are logged as whole integers. This is insufficient precision for my purposes. I propose changing the format to "%.3f", which will give millisecond precision for all timestamps regardless of offset. I think it would be nice if some of this description would be included into the patch commit message. The header line is misleading in focusing on silencedetect when the change is actually done in (a)metadata filter. Also usual commit header line convention is to start with the affected module (like "avutil/timestamp: ..."). First glance it looks like there are pre-built reference output files in the tests that may need to be re-generated, and that may be all that's required. I'll continue digging to try to understand what's going on. You might want to look into "make fate GEN=1". See http://ffmpeg.org/fate.html#FATE-makefile-targets-and-variables for details. Regards, Tobias ___ 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] News: Removal of libndi
On 25.03.2019 18:02, Jean-Baptiste Kempf wrote: On Mon, 25 Mar 2019, at 08:32, Tobias Rapp wrote: Most of those hardware libraries are glorified ioctls around the driver and shipped with the drivers. And I see this with nVidia, Intel MFX and Decklink (lots of "acquire C++ interface, set param" there, release the C++ interface). Matrox seems to do something else, though, introducing a special library for FFmpeg consumption, and I doubt that feels like a driver... The GPL is mentioned a lot in this thread. Maybe it would make sense to distinguish the two cases where FFmpeg is compiled with --enable-gpl and without it -- as the LGPL applies in that case. That does not change a thing, sorry. The section 6 of the LGPLv2.1 is similar to the section 3 of the GPL, and mentions exactly the same limitations and exceptions for major components of the OS. The fact that you can combine the library with a 3rd party library inside your program does not allow you to ship non-LGPL-compatible code inside the library. (The library must be changeable + redistributable by the user). I know that means that you can do more or less the same feature, but that means the architecture must be different. I thought that section 7 would allow to combine a 3rd party library with a LGPL library to create a new library but now when reading it again I stumble over the word "side-by-side" which indicates that the two parts should not interact with each other. So yes, your interpretation looks correct to me (IANAL). Regards, Tobias ___ 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] News: Removal of libndi
On 24.03.2019 21:14, Jean-Baptiste Kempf wrote: On Sun, 24 Mar 2019, at 20:10, Ronald S. Bultje wrote: The GPL does not mention hardware (instead, they use the word "system library"). Going from here, I don't consider enterprise-level hardware like Matrox $$$ priced stuff to be a system library at all. My system certainly has no hardware or drivers or system-level libraries that are API+ABI+functionally compatible with Matrox' tools and wares - under any license, not open-source and not closed-source. How can the system library exception possibly apply here? Drivers have always been considered part of the OS, whatever the price of the hardware. The Linux kernel has drivers for pieces of hardware that are way more expensive than Matrox hardware. So, if the library is part of the driver (installed at the same time), it is considered part of the "major components of the OS", because if you don't install the driver, you cannot use the hardware. This is the opinion of the Linux Foundation, the FSF, FSFE and so many others. Usually, the "major components" (as mentioned in the GPL and not "system libraries", which is the shortcut) explicitly mention 3 parts: kernel, compiler and "others." The common understanding is that everything that runs in Kernel-Land, aka kernel + drivers is the kernel part of the "major components". libc, compiler and libraries linked by compilers, if distributed with the OS, are the second part of the "major components"; and the last part, "others" cover the other core parts of the OS (usually the "base" in linux distributions), and covers init and the shell, and the basic services normally installed by default (at, cron, etc..). Yes, this meaning is very dated, but GPLv2 is from 1991. Most of those hardware libraries are glorified ioctls around the driver and shipped with the drivers. And I see this with nVidia, Intel MFX and Decklink (lots of "acquire C++ interface, set param" there, release the C++ interface). Matrox seems to do something else, though, introducing a special library for FFmpeg consumption, and I doubt that feels like a driver... The GPL is mentioned a lot in this thread. Maybe it would make sense to distinguish the two cases where FFmpeg is compiled with --enable-gpl and without it -- as the LGPL applies in that case. Regards, Tobias ___ 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] How to filter private folders from GIT patch
On 08.03.2019 10:49, Ulf Zibis wrote: [...] Can some other developer please give me a practical hint how to deal with private folders not to appear in GIT patches? I'm using .git/info/exclude to ignore files that are only found within my private developing environment. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] configure: Add an explicit check and option for nvcc
On 26.02.2019 21:36, Soft Works wrote: From: Jean-Baptiste Kempf Sent: Dienstag, 26. Februar 2019 15:01 [...] I don't think nvcc fit the"normally distributed with the operating system". I'm not sure if the role of nvcc has been fully understood. nvcc is some kind of 'pre-compiler' which is not distributed or linked to. Distributing GPL code that was compiled with MSVC doesn't require the MSVC compiler to be open source as well. Yes, but there are alternative OSS compilers that implement the same programming language (at least to a very large extent). This doesn't seem to be the case here. So even if this scenario is not explicitly excluded in the GPL, if doesn't feel very free to me, too. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc: add missing hyphen prefix
On 22.02.2019 14:57, Nicolas George wrote: Gyan (12019-02-22): '-key' will be easier to search for these users as well. It's also a low-cost arrangement. I trust adept API users will quickly suss out that the hyphen represents CLI. GUI users won't be entering the key string, only the values*, and casual CLI users will immediately recognize which entries pertain to options. That would be an argument for using something way more specific than a dash. Anyway, that kind of marking would belong in the definition of the macro @option, not in the body of the documentation. Yeah, that would be helpful. Prior art for adding an invisible prefix to HTML markup for exactly this use-case: https://duktape.org/api.html Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc: add missing hyphen prefix
On 22.02.2019 12:43, Hendrik Leppkes wrote: On Fri, Feb 22, 2019 at 12:29 PM Nicolas George wrote: Lou Logan (12019-02-21): For consistency. Fixes #7740. Signed-off-by: Lou Logan I do not think this is correct: the dash is not part of the option name, it is part of the Unix command-line tradition. For consistency, it should be removed when it is there, possibly replaced by the word "option" if necessary. I agree. You don't pass the dash when yo use avoptions through API, for example, so this would only add to the confusion. In my understanding the main source of documentation for API users are the Doxygen HTML output files while the Texinfo output is for both, command-line and API users -- with a slight bias towards command-line, at least from looking at all the ffmpeg/ffplay examples. The current dash prefixes allow me to jump to specific options more easily (Ctrl+F "-b" for example). I agree that this is not a strong argument, but wanted to mention it anyway :-) Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add astretch filter
On 21.01.2019 17:43, Paul B Mahol wrote: On 11/10/18, Paul B Mahol wrote: Signed-off-by: Paul B Mahol --- libavfilter/Makefile | 1 + libavfilter/af_astretch.c | 330 ++ libavfilter/allfilters.c | 1 + 3 files changed, 332 insertions(+) create mode 100644 libavfilter/af_astretch.c will apply ASAP! Please add some (short) documentation. Also FATE tests are welcome. Best regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.
On 14.01.2019 17:20, Nicolas George wrote: Tobias Rapp (12019-01-14): Writing good code requires time. I don't see how being sponsored for development should have a negative correlation (in general) to the time invested on a specific topic/patch. Let us say somebody worked one day on a sponsored patch. They now have two choices: - spend another day refactoring the code, designing functions API so that they can be shared with existing code; - submit as is and start working on a new patch for a new sponsorship. Which one will be more attractive? I would assume that a sponsor's interest in sustainability is at least equal to the interest of somebody doing development in free time. At least I don't see an evident point why the interest should be different per se. To me the more helpful discussion would be around how to resolve conflicts during code review and improve patch quality, rather than the influence of sponsorship. Best regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.
On 13.01.2019 16:24, Nicolas George wrote: James Almer (12019-01-13): How is that related to sponsored work? If a patch was ignored, then the extra line in the commit message would have been ignored as much as the actual code. Without sponsoring, most reasons for developing code are positively correlated with code quality. Not perfectly, but at least some. Sponsorship, on the other hand, is a motivation for developing code that has little to do with code quality. For that reason, sponsored code should be examined much more carefully. Writing good code requires time. I don't see how being sponsored for development should have a negative correlation (in general) to the time invested on a specific topic/patch. Patch review intensity should be based on the content of the patch itself (e.g. complexity and long-term maintenance factor) and not based on some disclosure requirement that has the potential to support prejudice. Best regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.
On 13.01.2019 15:07, Gyan wrote: On 13-01-2019 06:39 PM, Ronald S. Bultje wrote: Hi, On Sun, Jan 13, 2019 at 4:39 AM Gyan wrote: When someone submits a patch, it is implicit, unless stated otherwise, that it is of their own initiative (and their own work), and thus they are free to assign copyright. When work is performed for hire, the copyright may belong to the employer. Such sponsored work cannot be 'donated' to the project But we don't do copyright assignment. No, the patch submitter (implicitly) does. Which is not a problem when the copyright holder and submitter are the same person. For sponsored code, they may not be. Analogy: Scenario 1 A 'vlogger' makes a video and uploads it as public to Youtube. Youtube then lets everyone see that video. No problem. Scenario 2 Someone pays the vlogger to make a video. Vlogger uploads it to YT as public. There's a problem if the client did not allow that which makes it copyright infringement, Which is why YT has this clause in their T "You affirm, represent, and warrant that you own or have the necessary licenses, rights, consents, and permissions to publish Content you submit; and you license to YouTube all patent, trademark, trade secret, copyright or other proprietary rights in and to such Content for publication on the Service pursuant to these Terms of Service." So, we are YT in this case and the Content is the patch(es). The concern would be that the submitter doesn't have the right to license the code into ffmpeg, if the contract with the client doesn't allow them to do it. Only way to be sure is for the sponsor to affirm to it. And for that, we would have to know that there is a sponsor, to start with. Isn't this what the "Signed-off-by" line in a commit already states? So to solve this (if actually deemed necessary) it would be better to request the commit author to signal that the copyright status has been clarified by always adding this Signed-off-by line instead. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add dumpwave filter.
On 07.01.2019 15:31, Dmitry Humeniuk wrote:
Signed-off-by: Dmitry Humeniuk
---
Changelog|1 +
doc/filters.texi | 23 +
libavfilter/Makefile |1 +
libavfilter/af_dumpwave.c| 234
libavfilter/allfilters.c |1 +
libavfilter/version.h|4 +-
tests/fate-run.sh|9 +
tests/fate/filter-audio.mak | 12 +
tests/ref/fate/filter-dumpwave | 1800 ++
tests/ref/fate/filter-dumpwave-24bit | 1800 ++
tests/ref/fate/filter-dumpwave-fltp | 1800 ++
11 files changed, 5683 insertions(+), 2 deletions(-)
create mode 100644 libavfilter/af_dumpwave.c
create mode 100644 tests/ref/fate/filter-dumpwave
create mode 100644 tests/ref/fate/filter-dumpwave-24bit
create mode 100644 tests/ref/fate/filter-dumpwave-fltp
diff --git a/Changelog b/Changelog
index f135fa56b6..1eb337796b 100644
--- a/Changelog
+++ b/Changelog
@@ -13,6 +13,7 @@ version :
- GIF parser
- vividas demuxer
- hymt decoder
+- dumpwave filter
version 4.1:
diff --git a/doc/filters.texi b/doc/filters.texi
index 98858c5356..66c2961fd8 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2912,6 +2912,29 @@ Set window length in seconds used to split audio into
segments of equal length.
Default is 3 seconds.
@end table
+@section dumpwave
+Dump RMS envelope to a file.
+Convert samples to decibels and calculates RMS (Root-Mean-Square) audio power
in 0 to 1.0 floats.
+
+@table @option
+@item w, width
+Number of data values.
+The default value is @var{1800}
+
+@item n, nb_samples
+Samples count per value per channel, default 128
+
+@item f, file
+Path to a file ``-'' is a shorthand
+for standard output.
+@end table
+
+For example, to generate RMS envelope for 44.1 kHz 6 seconds length audio
+with dimensions @var{1800x140}, samples count @code{44100*6/1800=147} and
store it to @var{/tmp/out.csv}, you might use:
+@example
+dumpwave=w=1800:n=147:f=/tmp/out.csv
+@end example
+
@section dynaudnorm
Dynamic Audio Normalizer.
[...]
I appreciate the completeness of the proposed patch (documentation,
tests, version bump) but it seems that the functionality overlaps with
existing filters. Besides the different output format I think the same
can be achieved by using a command like:
ffmpeg -i input.wav -f null -filter:a
"asetnsamples=147,astats=metadata=on,ametadata=print:key=lavfi.astats.Overall.RMS_peak:file=/tmp/out.dat"
/dev/null
So if it is only about the output format, it would be better to add CSV
support to the ametadata filter, IMHO. That way other filters with frame
metadata output will also gain CSV support.
Best regards,
Tobias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4] avformat/movenc: Added an option to disable SIDX atom
On 06.12.2018 08:28, Karthick J wrote: --- doc/muxers.texi | 4 libavformat/movenc.c | 12 ++-- libavformat/movenc.h | 1 + 3 files changed, 15 insertions(+), 2 deletions(-) [...] Looks OK now, no more comments from my side. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
