[FFmpeg-devel] [PATCH 1/3] doc/encoders/libx264: review and extend option description
Also, merge x264opts and x264-opts option docs to avoid duplication
and make it even more clearer they provide the same functionality.
---
doc/encoders.texi | 66 ++-
1 file changed, 37 insertions(+), 29 deletions(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 6f8f5e127e..947b0c3320 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2418,6 +2418,10 @@ To get a more accurate and extensive documentation of
the libx264
options, invoke the command @command{x264 --fullhelp} or consult
the libx264 documentation.
+In the list below, note that the @command{x264} option name is shown
+in parentheses after the libavcodec corresponding name, in case there
+is a direct mapping.
+
@table @option
@item b (@emph{bitrate})
Set bitrate in bits/s. Note that FFmpeg's @option{b} option is
@@ -2425,17 +2429,19 @@ expressed in bits/s, while @command{x264}'s
@option{bitrate} is in
kilobits/s.
@item bf (@emph{bframes})
+Number of B-frames between I and P-frames
@item g (@emph{keyint})
+Maximum GOP size
@item qmin (@emph{qpmin})
-Minimum quantizer scale.
+Minimum quantizer scale
@item qmax (@emph{qpmax})
-Maximum quantizer scale.
+Maximum quantizer scale
@item qdiff (@emph{qpstep})
-Maximum difference between quantizer scales.
+Maximum difference between quantizer scales
@item qblur (@emph{qblur})
Quantizer curve blur
@@ -2444,7 +2450,7 @@ Quantizer curve blur
Quantizer curve compression factor
@item refs (@emph{ref})
-Number of reference frames each P-frame can use. The range is from @var{0-16}.
+Number of reference frames each P-frame can use. The allowed range is
@var{0-16}.
@item sc_threshold (@emph{scenecut})
Sets the threshold for the scene change detection.
@@ -2452,7 +2458,8 @@ Sets the threshold for the scene change detection.
@item trellis (@emph{trellis})
Performs Trellis quantization to increase efficiency. Enabled by default.
-@item nr (@emph{nr})
+@item nr (@emph{nr})
+Noise reduction
@item me_range (@emph{merange})
Maximum range of the motion search in pixels.
@@ -2533,6 +2540,7 @@ open GOP by setting it to @code{-cgop}. The result is
similar to
the behavior of @command{x264}'s @option{--open-gop} option.
@item rc_init_occupancy (@emph{vbv-init})
+Initial VBV buffer occupancy
@item preset (@emph{preset})
Set the encoding preset.
@@ -2578,7 +2586,7 @@ Set AQ strength, reduce blocking and blurring in flat and
textured areas.
Use psychovisual optimizations when set to 1. When set to 0, it has the
same effect as @command{x264}'s @option{--no-psy} option.
-@item psy-rd (@emph{psy-rd})
+@item psy-rd (@emph{psy-rd})
Set strength of psychovisual optimization, in
@var{psy-rd}:@var{psy-trellis} format.
@@ -2610,7 +2618,7 @@ to 1.
@item avcintra-class (@emph{class})
Configure the encoder to generate AVC-Intra.
-Valid values are 50,100 and 200
+Valid values are 50, 100 and 200
@item bluray-compat (@emph{bluray-compat})
Configure the encoder to be compatible with the bluray standard.
@@ -2661,8 +2669,8 @@ Set loop filter parameters, in @var{alpha}:@var{beta}
form.
Set fluctuations reduction in QP (before curve compression).
@item partitions (@emph{partitions})
-Set partitions to consider as a comma-separated list of. Possible
-values in the list:
+Set partitions to consider as a comma-separated list of
+values. Possible values in the list:
@table @samp
@item p8x8
@@ -2718,19 +2726,33 @@ Variable bit rate.
Constant bit rate (not allowed in MP4 container).
@end table
-@item x264opts (N.A.)
-Set any x264 option, see @command{x264 --fullhelp} for a list.
+@item x264opts @var{opts}
+@item x264-params @var{opts}
+Override the x264 configuration using a :-separated list of key=value
+options.
-Argument is a list of @var{key}=@var{value} couples separated by
-":". In @var{filter} and @var{psy-rd} options that use ":" as a separator
-themselves, use "," instead. They accept it as well since long ago but this
-is kept undocumented for some reason.
+@option{x264-param} is functionally the same as the @option{x264opts},
+but is duplicated for compatibility with the Libav fork.
+
+The argument for both options is a list of @var{key}=@var{value}
+couples separated by ":". In @var{filter} and @var{psy-rd} options
+that use ":" as a separator themselves, use "," instead. They accept
+it as well since long ago but this is kept undocumented for some
+reason.
+
+For example, the options might be provided as:
+@example
+level=30:bframes=0:weightp=0:cabac=0:ref=1:vbv-maxrate=768:vbv-bufsize=2000:analyse=all:me=umh:no-fast-pskip=1:subq=6:8x8dct=0:trellis=0
+@end example
For example to specify libx264 encoding options with @command{ffmpeg}:
@example
ffmpeg -i foo.mpg -c:v libx264 -x264opts keyint=123:min-keyint=20 -an out.mkv
@end example
+To get the complete list of the libx264 options, invoke the command
+@command{x264 --fullhelp} or consult the libx264 documentation.
+
@item a53cc
[FFmpeg-devel] [PATCH 2/3] lavc: clarify meaning of avctx.level option
---
doc/codecs.texi| 5 -
libavcodec/avcodec.h | 4 +++-
libavcodec/options_table.h | 2 +-
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/doc/codecs.texi b/doc/codecs.texi
index f903dad754..0aa848f62f 100644
--- a/doc/codecs.texi
+++ b/doc/codecs.texi
@@ -697,10 +697,13 @@ profiles are documented in the relevant encoder
documentation.
@item level @var{integer} (@emph{encoding,audio,video})
+Set the encoder level. This level depends on the specific codec, and
+might correspond to the profile level. It is set by default to
+@samp{unknown}.
+
Possible values:
@table @samp
@item unknown
-
@end table
@item lowres @var{integer} (@emph{decoding,audio,video})
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 649411ac79..50d2086c13 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1722,7 +1722,9 @@ typedef struct AVCodecContext {
/**
* level
- * - encoding: Set by user.
+ * - encoding: Set by user, corresponds to a specific level defined by the
+ * codec, usually corresponding to the profile level, if not specified it
+ * set to FF_LEVEL_UNKNOWN
* - decoding: Set by libavcodec.
*/
int level;
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index bb4b894b06..5f0d674dbe 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -226,7 +226,7 @@ static const AVOption avcodec_options[] = {
{"profile", NULL, OFFSET(profile), AV_OPT_TYPE_INT, {.i64 = FF_PROFILE_UNKNOWN
}, INT_MIN, INT_MAX, V|A|E|CC, "avctx.profile"},
{"unknown", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_UNKNOWN }, INT_MIN,
INT_MAX, V|A|E, "avctx.profile"},
{"main10", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_HEVC_MAIN_10 },
INT_MIN, INT_MAX, V|E, "avctx.profile"},
-{"level", NULL, OFFSET(level), AV_OPT_TYPE_INT, {.i64 = FF_LEVEL_UNKNOWN },
INT_MIN, INT_MAX, V|A|E|CC, "avctx.level"},
+{"level", "encoding level, usually corresponding to the profile level,
codec-specific", OFFSET(level), AV_OPT_TYPE_INT, {.i64 = FF_LEVEL_UNKNOWN },
INT_MIN, INT_MAX, V|A|E|CC, "avctx.level"},
{"unknown", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_LEVEL_UNKNOWN }, INT_MIN,
INT_MAX, V|A|E, "avctx.level"},
{"lowres", "decode at 1= 1/2, 2=1/4, 3=1/8 resolutions", OFFSET(lowres),
AV_OPT_TYPE_INT, {.i64 = 0 }, 0, INT_MAX, V|A|D},
{"cmp", "full-pel ME compare function", OFFSET(me_cmp), AV_OPT_TYPE_INT, {.i64
= DEFAULT }, INT_MIN, INT_MAX, V|E, "cmp_func"},
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] doc/encoders/libx264: clarify meaning of level option
Address trac issue:
http://trac.ffmpeg.org/ticket/3947
---
doc/encoders.texi | 8
1 file changed, 8 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 947b0c3320..b7fbc25f92 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2452,6 +2452,14 @@ Quantizer curve compression factor
@item refs (@emph{ref})
Number of reference frames each P-frame can use. The allowed range is
@var{0-16}.
+@item level
+Only when set from the @code{AVCodecContext} API and the value is
+positive, sets the @code{x264_param_t.i_level_idc} value. This is
+overridden when setting the private option @option{level}.
+
+@item level (@emph{level})
+Specify level string (as defined by H.264 Annex A).
+
@item sc_threshold (@emph{scenecut})
Sets the threshold for the scene change detection.
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] doc/developer: Code pushed without patches on ffmpeg-devel must be announced on the ML
Hi, On Fri, Aug 25, 2023 at 1:42 PM Nicolas George wrote: > James Almer (12023-08-25): > > As i said on IRC, > > A medium that can only be accessed by a small fraction of the > contributors due to timeliness constraints. > I suspect you misunderstand IRC. With matrix, a bouncer or a 24/7 client, most of us are online with 24/7 history. Chat logs even provide google searchability. I prefer IRC over mailinglist for most technical discussions. Ronald ___ 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 v6 1/9] libavutil: add hwcontext_d3d12va and AV_PIX_FMT_D3D12
Aug 25, 2023, 10:49 by tong1.wu-at-intel@ffmpeg.org: > V6 major changes > 1. the way d3dlibs created, adding a load function. Added dlclose in free > function. > 2. Simplified the public sync API by only keeping av_d3d12va_wait_idle. > 3. Wrapping data->[0], data[1], data[2] into one single structure. > This hasn't fixed my issues with the previous version. av_d3d12va_wait_idle is in particular looks like a convenience function rather than something that must always be called for valid API usage. Also, we have dlopen/dlclose wrappers that you should be using instead. ___ 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] doc/developer: Code pushed without patches on ffmpeg-devel must be announced on the ML
James Almer (12023-08-25): > As i said on IRC, A medium that can only be accessed by a small fraction of the contributors due to timeliness constraints. > there's a difference between "Unless justified, please > send things to the ML before pushing" and "Everything must have at least two > reviews from long standing developers". > > This is not requiring everything to have been reviewed before being pushed, > it's asking for non trivial things to hit the ML so people have at least a > chance at finding problems. Faire enough. Just let us make it very clear it is the former and not the latter. The I-don't-know-the-code-“LGTM” mandatory review were a disgrace. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] doc/developer: Reviews must be constructive
Leo Izen (12023-08-25): > FWIW I read it the same way Anton did but if it's unclear then perhaps it > could be modified. Essentially, I think what's going on is we don't want > "NAK" without a reason. If you want to say a patch shouldn't make it in, > there should at least be a reason. I agree on this too. > Even if the reason is "this API/module has no place in FFmpeg." But not on this example: what has place in FFmpeg or not is anybody's arbitrary opinion, saying “no place in FFmpeg” alone is just a fancy way of saying “NAK” with no reason. It must be substantiated too, for example “the same feature is already possible [like that]”. And if the same feature is *not* already possible, then it surely means the code *does* belong in FFmpeg. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] doc/developer: Reviews must be constructive
Quoting Vittorio Giovara (2023-08-25 19:26:21) > On Fri, Aug 25, 2023 at 5:24 PM Anton Khirnov wrote: > > > Quoting Rémi Denis-Courmont (2023-08-25 17:09:55) > > > Le perjantaina 25. elokuuta 2023, 17.58.40 EEST Anton Khirnov a écrit : > > > > > And then sometimes an argument has been argued to death previously > > and > > > > > there is really no point to rehash it again and again. If people > > cannot > > > > > agree, they should refer to the TC, not brute force the review > > through > > > > > overwhelming insistance. > > > > > > > > I think we just have different interpretations of the word > > > > 'constructive' here. > > > > I certainly agree that some patches are just not acceptable - I > > certainly > > > > did not mean to imply that there must be a way forward for all patches. > > > > > > I think that you do not agree with the generally accepted meaning of > > > "constructive" in this context. By definition a review cannot be > > constructive, > > > as in helpful or conducive of a way forward, if it argues that there are > > no > > > ways forward. > > > > Explaining why a patch is not acceptable is helpful IMO. > > Saying 'no', on the other hand, is not. > > > > that is true, but saying "no" and preventing some bad code from making it > in the codebase is better than not saying anything If the code is so bad that it should not go in then surely someone can find it in themselves to write two sentences about the reason why it is so bad. Nobody is saying you have to produce a 10-page manifesto. > > Maybe you meant "supported" or "corroborated". > > > > Might as well describe it in more than one word, since apparently it's > > so unclear. Would you be in favor of something along the lines of > > > > Nontrivial (i.e. other than cosmetics or accepting the patch) reviews > > must be based on technical arguments. If the reviewer fails to provide > > arguments for rejecting the patch or requesting changes, then the > > review may be disregarded. > > > > I agree with the text suggested, but I don't understand why it needs to be > set in stone in the first place... There is a persistent problem with certain people rejecting patches for no clear reason, and then refusing to elaborate. -- Anton Khirnov ___ 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] doc/developer: Reviews must be constructive
On 8/25/23 11:09, Rémi Denis-Courmont wrote: Le perjantaina 25. elokuuta 2023, 17.58.40 EEST Anton Khirnov a écrit : And then sometimes an argument has been argued to death previously and there is really no point to rehash it again and again. If people cannot agree, they should refer to the TC, not brute force the review through overwhelming insistance. I think we just have different interpretations of the word 'constructive' here. I certainly agree that some patches are just not acceptable - I certainly did not mean to imply that there must be a way forward for all patches. I think that you do not agree with the generally accepted meaning of "constructive" in this context. By definition a review cannot be constructive, as in helpful or conducive of a way forward, if it argues that there are no ways forward. Maybe you meant "supported" or "corroborated". FWIW I read it the same way Anton did but if it's unclear then perhaps it could be modified. Essentially, I think what's going on is we don't want "NAK" without a reason. If you want to say a patch shouldn't make it in, there should at least be a reason. Even if the reason is "this API/module has no place in FFmpeg." - Leo Izen (Traneptora) ___ 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] doc/developer: Reviews must be constructive
On Fri, Aug 25, 2023 at 5:24 PM Anton Khirnov wrote: > Quoting Rémi Denis-Courmont (2023-08-25 17:09:55) > > Le perjantaina 25. elokuuta 2023, 17.58.40 EEST Anton Khirnov a écrit : > > > > And then sometimes an argument has been argued to death previously > and > > > > there is really no point to rehash it again and again. If people > cannot > > > > agree, they should refer to the TC, not brute force the review > through > > > > overwhelming insistance. > > > > > > I think we just have different interpretations of the word > > > 'constructive' here. > > > I certainly agree that some patches are just not acceptable - I > certainly > > > did not mean to imply that there must be a way forward for all patches. > > > > I think that you do not agree with the generally accepted meaning of > > "constructive" in this context. By definition a review cannot be > constructive, > > as in helpful or conducive of a way forward, if it argues that there are > no > > ways forward. > > Explaining why a patch is not acceptable is helpful IMO. > Saying 'no', on the other hand, is not. > that is true, but saying "no" and preventing some bad code from making it in the codebase is better than not saying anything > Maybe you meant "supported" or "corroborated". > > Might as well describe it in more than one word, since apparently it's > so unclear. Would you be in favor of something along the lines of > > Nontrivial (i.e. other than cosmetics or accepting the patch) reviews > must be based on technical arguments. If the reviewer fails to provide > arguments for rejecting the patch or requesting changes, then the > review may be disregarded. > I agree with the text suggested, but I don't understand why it needs to be set in stone in the first place... -- Vittorio ___ 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] doc/developer: Code pushed without patches on ffmpeg-devel must be announced on the ML
On 8/25/2023 2:16 PM, Nicolas George wrote: Jean-Baptiste Kempf (12023-08-25): So that means mandatory sending to the mailing list :) Trolling is not going to get you anywhere. What trolling? You mean the suggestion to enforce a rule that is known to have caused a fork to wither and die? That was not from me. As i said on IRC, there's a difference between "Unless justified, please send things to the ML before pushing" and "Everything must have at least two reviews from long standing developers". This is not requiring everything to have been reviewed before being pushed, it's asking for non trivial things to hit the ML so people have at least a chance at finding problems. ___ 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] doc/developer: Reviews must be constructive
On Fri, Aug 25, 2023 at 8:46 AM Nicolas George wrote: > Vittorio Giovara (12023-08-25): > > NAK > > we shouldn't put extra burden on reviewers, nor guilt trap them into > > suggesting an alternative approach > > It is hilarious, in a very sad way, that you prefer put extra burden on > people who do things than on people who block them. > I am confused, your email is the epitome of not suggesting any alternative approach, so you're agreeing with it..? -- Vittorio ___ 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] doc/developer: Code pushed without patches on ffmpeg-devel must be announced on the ML
Jean-Baptiste Kempf (12023-08-25): > >> So that means mandatory sending to the mailing list :) > Trolling is not going to get you anywhere. What trolling? You mean the suggestion to enforce a rule that is known to have caused a fork to wither and die? That was not from me. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] OSQ lossless audio format support
On Fri, Aug 25, 2023 at 6:42 PM James Almer wrote:
> On 8/25/2023 1:28 PM, Paul B Mahol wrote:
> > On Fri, Aug 25, 2023 at 5:57 PM James Almer wrote:
> >
> >> On 8/24/2023 7:06 PM, Paul B Mahol wrote:
> >>> On Thu, Aug 24, 2023 at 11:51 PM James Almer
> wrote:
> >>>
> On 8/24/2023 6:11 PM, Paul B Mahol wrote:
> > On Thu, Aug 24, 2023 at 11:00 PM James Almer
> >> wrote:
> >
> >> On 8/24/2023 6:52 AM, Paul B Mahol wrote:
> >>> +static int osq_receive_frame(AVCodecContext *avctx, AVFrame
> *frame)
> >>> +{
> >>> +OSQContext *s = avctx->priv_data;
> >>> +GetBitContext *gb = >gb;
> >>> +int ret, n;
> >>> +
> >>> +while (s->bitstream_size < s->max_framesize) {
> >>> +int size;
> >>> +
> >>> +if (!s->pkt->data) {
> >>> +ret = ff_decode_get_packet(avctx, s->pkt);
> >>> +if (ret == AVERROR_EOF && s->bitstream_size > 0)
> >>> +break;
> >>> +if (ret < 0)
> >>> +return ret;
> >>> +}
> >>> +
> >>> +size = FFMIN(s->pkt->size - s->pkt_offset,
> s->max_framesize
> >> -
> >> s->bitstream_size);
> >>> +memcpy(s->bitstream + s->bitstream_size, s->pkt->data +
> >> s->pkt_offset, size);
> >>> +s->bitstream_size += size;
> >>> +s->pkt_offset += size;
> >>> +
> >>> +if (s->pkt_offset == s->pkt->size) {
> >>> +av_packet_unref(s->pkt);
> >>> +s->pkt_offset = 0;
> >>> +}
> >>
> >> This looks like you're assembling a packet of max_framesize bytes.
> You
> >> should instead do that in a parser, and ensure here that the packets
> >> fed
> >> to this decoder are <= max_framesize.
> >>
> >>> +}
> >>> +
> >>> +frame->nb_samples = FFMIN(s->frame_samples, s->nb_samples);
> >>> +if (frame->nb_samples <= 0)
> >>> +return AVERROR_EOF;
> >>> +
> >>> +if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
> >>> +goto fail;
> >>> +
> >>> +if ((ret = init_get_bits8(gb, s->bitstream,
> s->bitstream_size))
> >> <
> 0)
> >>> +goto fail;
> >>> +
> >>> +if ((ret = osq_decode_block(avctx, frame)) < 0)
> >>> +goto fail;
> >>> +
> >>> +s->nb_samples -= frame->nb_samples;
> >>> +
> >>> +n = get_bits_count(gb) / 8;
> >>> +if (n > s->bitstream_size) {
> >>> +ret = AVERROR_INVALIDDATA;
> >>> +goto fail;
> >>> +}
> >>> +
> >>> +memmove(s->bitstream, >bitstream[n], s->bitstream_size -
> n);
> >>> +s->bitstream_size -= n;
> >>> +
> >>> +return 0;
> >>> +
> >>> +fail:
> >>> +s->bitstream_size = 0;
> >>> +s->pkt_offset = 0;
> >>> +av_packet_unref(s->pkt);
> >>> +
> >>> +return ret;
> >>> +}
> >>> +
> >>> +const AVInputFormat ff_osq_demuxer = {
> >>> +.name = "osq",
> >>> +.long_name = NULL_IF_CONFIG_SMALL("raw OSQ"),
> >>> +.read_probe = osq_probe,
> >>> +.read_header= osq_read_header,
> >>> +.read_packet= ff_raw_read_partial_packet,
> >>
> >> Instead of sending an arbitrarily sized packet (1024 bytes as of
> now),
> >> you should set codecpar->frame_size and propagate packets with that
> >> amount of bytes instead.
> >> A parser is still needed, though, for non seekable input (a pipe).
> And
> >> in case the decoder is fed with non lavf input.
> >>
> >
> > Format is not seekable, packet sizes are nowhere stored in .osq
> files.
>
> Same case as raw formats like H.264. No packet sizes, no seekability
> without having parsed the entire sequence to build a list of seek
> points, etc. A parser has to assemble access units.
>
> >>>
> >>> But there is no any info how to assemble anything here, unless
> >>> you propose decoding inside parser?
> >>>
> >>>
> >>>
>
> >
> > Think of this format like APAC/BONK/WAVARC but just no need to keep
> unused
> > bits from previous decoded data/packet.
> > With this fact, parser makes no sense to do.
>
> You know that frame_size is (frame_samples_per_channel * 16 + 1024) *
> channels. A parser can work with that (Look at gsm parser for example.
> There may be others too).
>
> >>>
> >>> There is reason why variable is called max_framesize.
> >>>
> >>> You should not propagate truncated data in 1024 byte chunks, and the
> decoder should not expect that either.
>
> >>>
> >>> Nothing gets truncated. That is just worst case scenario size for
> packet.
> >>> In another words, size of packet can be anything between 33 and
> >>> max_framesize.
> >>
> >> By truncated i mean the demuxer propagates arbitrary 1024 byte sized
> >> packets. And in the decoder you're
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/apedec: Fix 48khz 24bit below insane level
On Fri, Aug 25, 2023 at 05:27:14PM +0200, Paul B Mahol wrote:
> On Fri, Aug 25, 2023 at 5:13 PM Michael Niedermayer
> wrote:
>
> > Fixes: Ticket9816
> > Fixes: vlc.ape and APE_48K_24bit_2CH_02_01.ape
> >
> > Regression since: ed0001482a74b60f3d5bc5cd7e304c9d65b2fcd5.
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/apedec.c | 15 +++
> > 1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
> > index 7bad8500e1..b1cceb9395 100644
> > --- a/libavcodec/apedec.c
> > +++ b/libavcodec/apedec.c
> > @@ -1184,7 +1184,9 @@ static void predictor_decode_mono_3930(APEContext
> > *ctx, int count)
> > static av_always_inline int predictor_update_filter(APEPredictor64 *p,
> > const int decoded,
> > const int filter,
> > const int delayA,
> > const int delayB,
> > -const int adaptA,
> > const int adaptB)
> > +const int adaptA,
> > const int adaptB,
> > +int compression_level
> > + )
> >
>
> Why on ')' separate line?
I asked the ')' but it doesnt seem to remember
fixed
>
>
> > {
> > int64_t predictionA, predictionB;
> > int32_t sign;
> > @@ -1212,7 +1214,12 @@ static av_always_inline int
> > predictor_update_filter(APEPredictor64 *p,
> >p->buf[delayB - 3] * p->coeffsB[filter][3] +
> >p->buf[delayB - 4] * p->coeffsB[filter][4];
> >
> > -p->lastA[filter] = decoded + ((int64_t)((uint64_t)predictionA +
> > (predictionB >> 1)) >> 10);
> > +if (compression_level < COMPRESSION_LEVEL_INSANE) {
> > +predictionA = (int32_t)predictionA;
> > +predictionB = (int32_t)predictionB;
> > +p->lastA[filter] = decoded + ((int32_t)(predictionA +
> > (predictionB >> 1)) >> 10);
> > +} else
> > +p->lastA[filter] = decoded + ((int64_t)((uint64_t)predictionA +
> > (predictionB >> 1)) >> 10);
> >
>
> Please make {} block.
ok
>
>
> > p->filterA[filter] = p->lastA[filter] + ((int64_t)(p->filterA[filter]
> > * 31ULL) >> 5);
> >
> > sign = APESIGN(decoded);
> > @@ -1240,10 +1247,10 @@ static void
> > predictor_decode_stereo_3950(APEContext *ctx, int count)
> > while (count--) {
> > /* Predictor Y */
> > *decoded0 = predictor_update_filter(p, *decoded0, 0, YDELAYA,
> > YDELAYB,
> > -YADAPTCOEFFSA, YADAPTCOEFFSB);
> > +YADAPTCOEFFSA, YADAPTCOEFFSB,
> > ctx->compression_level);
> > decoded0++;
> > *decoded1 = predictor_update_filter(p, *decoded1, 1, XDELAYA,
> > XDELAYB,
> > -XADAPTCOEFFSA, XADAPTCOEFFSB);
> > +XADAPTCOEFFSA, XADAPTCOEFFSB,
> > ctx->compression_level);
> > decoded1++;
> >
> > /* Combined */
> > --
> > 2.17.1
> >
> >
> OK with that style fixed, assuming it fixes that ticket and is still
> bitexact with both files.
ive fixed the style issues i found, i hope i found all
CRC tests pass on the 3 files i have
will apply with my next git push
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have often repented speaking, but never of holding my tongue.
-- Xenocrates
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] OSQ lossless audio format support
On 8/25/2023 1:28 PM, Paul B Mahol wrote:
On Fri, Aug 25, 2023 at 5:57 PM James Almer wrote:
On 8/24/2023 7:06 PM, Paul B Mahol wrote:
On Thu, Aug 24, 2023 at 11:51 PM James Almer wrote:
On 8/24/2023 6:11 PM, Paul B Mahol wrote:
On Thu, Aug 24, 2023 at 11:00 PM James Almer
wrote:
On 8/24/2023 6:52 AM, Paul B Mahol wrote:
+static int osq_receive_frame(AVCodecContext *avctx, AVFrame *frame)
+{
+OSQContext *s = avctx->priv_data;
+GetBitContext *gb = >gb;
+int ret, n;
+
+while (s->bitstream_size < s->max_framesize) {
+int size;
+
+if (!s->pkt->data) {
+ret = ff_decode_get_packet(avctx, s->pkt);
+if (ret == AVERROR_EOF && s->bitstream_size > 0)
+break;
+if (ret < 0)
+return ret;
+}
+
+size = FFMIN(s->pkt->size - s->pkt_offset, s->max_framesize
-
s->bitstream_size);
+memcpy(s->bitstream + s->bitstream_size, s->pkt->data +
s->pkt_offset, size);
+s->bitstream_size += size;
+s->pkt_offset += size;
+
+if (s->pkt_offset == s->pkt->size) {
+av_packet_unref(s->pkt);
+s->pkt_offset = 0;
+}
This looks like you're assembling a packet of max_framesize bytes. You
should instead do that in a parser, and ensure here that the packets
fed
to this decoder are <= max_framesize.
+}
+
+frame->nb_samples = FFMIN(s->frame_samples, s->nb_samples);
+if (frame->nb_samples <= 0)
+return AVERROR_EOF;
+
+if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
+goto fail;
+
+if ((ret = init_get_bits8(gb, s->bitstream, s->bitstream_size))
<
0)
+goto fail;
+
+if ((ret = osq_decode_block(avctx, frame)) < 0)
+goto fail;
+
+s->nb_samples -= frame->nb_samples;
+
+n = get_bits_count(gb) / 8;
+if (n > s->bitstream_size) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
+
+memmove(s->bitstream, >bitstream[n], s->bitstream_size - n);
+s->bitstream_size -= n;
+
+return 0;
+
+fail:
+s->bitstream_size = 0;
+s->pkt_offset = 0;
+av_packet_unref(s->pkt);
+
+return ret;
+}
+
+const AVInputFormat ff_osq_demuxer = {
+.name = "osq",
+.long_name = NULL_IF_CONFIG_SMALL("raw OSQ"),
+.read_probe = osq_probe,
+.read_header= osq_read_header,
+.read_packet= ff_raw_read_partial_packet,
Instead of sending an arbitrarily sized packet (1024 bytes as of now),
you should set codecpar->frame_size and propagate packets with that
amount of bytes instead.
A parser is still needed, though, for non seekable input (a pipe). And
in case the decoder is fed with non lavf input.
Format is not seekable, packet sizes are nowhere stored in .osq files.
Same case as raw formats like H.264. No packet sizes, no seekability
without having parsed the entire sequence to build a list of seek
points, etc. A parser has to assemble access units.
But there is no any info how to assemble anything here, unless
you propose decoding inside parser?
Think of this format like APAC/BONK/WAVARC but just no need to keep
unused
bits from previous decoded data/packet.
With this fact, parser makes no sense to do.
You know that frame_size is (frame_samples_per_channel * 16 + 1024) *
channels. A parser can work with that (Look at gsm parser for example.
There may be others too).
There is reason why variable is called max_framesize.
You should not propagate truncated data in 1024 byte chunks, and the
decoder should not expect that either.
Nothing gets truncated. That is just worst case scenario size for packet.
In another words, size of packet can be anything between 33 and
max_framesize.
By truncated i mean the demuxer propagates arbitrary 1024 byte sized
packets. And in the decoder you're assembling a buffer of max_framesize
in osq_receive_frame() by requesting packets until you reach that size
or EOF, whatever comes first, before calling osq_decode_block(). So
unless you hit EOF, it will always be max_framesize. That's what i say
should be done in a simple, small parser.
I fully understand you, but your reasoning is critically flawed.
And I have no time to educated an uneducated.
Not insulting people will help your arguments.
For The Last Time:
Even if parser does that what you propose, decoder would need to keep own
internal
buffer again and than memmove() bytes around.
And even if parser is implemented that would effectively break other
possible containers different
than .osq - such containers would properly split data into packets and my
decoder would still work in such scenario but
your proposed way would only force such containers to blacklist your
proposed parser.
You know a parser is doable and the proper approach. With frame_samples
and the first part of osq_decode_block() you can get it going. But do
whatever you want.
___
ffmpeg-devel mailing list
Re: [FFmpeg-devel] [PATCH 2/2] doc/developer: Code pushed without patches on ffmpeg-devel must be announced on the ML
On Fri, 25 Aug 2023, at 18:27, Nicolas George wrote: > Jean-Baptiste Kempf (12023-08-25): >> So that means mandatory sending to the mailing list :) > > And change the name to libav? Trolling is not going to get you anywhere. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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] doc/developer: Code pushed without patches on ffmpeg-devel must be announced on the ML
Jean-Baptiste Kempf (12023-08-25): > So that means mandatory sending to the mailing list :) And change the name to libav? -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] OSQ lossless audio format support
On Fri, Aug 25, 2023 at 5:57 PM James Almer wrote:
> On 8/24/2023 7:06 PM, Paul B Mahol wrote:
> > On Thu, Aug 24, 2023 at 11:51 PM James Almer wrote:
> >
> >> On 8/24/2023 6:11 PM, Paul B Mahol wrote:
> >>> On Thu, Aug 24, 2023 at 11:00 PM James Almer
> wrote:
> >>>
> On 8/24/2023 6:52 AM, Paul B Mahol wrote:
> > +static int osq_receive_frame(AVCodecContext *avctx, AVFrame *frame)
> > +{
> > +OSQContext *s = avctx->priv_data;
> > +GetBitContext *gb = >gb;
> > +int ret, n;
> > +
> > +while (s->bitstream_size < s->max_framesize) {
> > +int size;
> > +
> > +if (!s->pkt->data) {
> > +ret = ff_decode_get_packet(avctx, s->pkt);
> > +if (ret == AVERROR_EOF && s->bitstream_size > 0)
> > +break;
> > +if (ret < 0)
> > +return ret;
> > +}
> > +
> > +size = FFMIN(s->pkt->size - s->pkt_offset, s->max_framesize
> -
> s->bitstream_size);
> > +memcpy(s->bitstream + s->bitstream_size, s->pkt->data +
> s->pkt_offset, size);
> > +s->bitstream_size += size;
> > +s->pkt_offset += size;
> > +
> > +if (s->pkt_offset == s->pkt->size) {
> > +av_packet_unref(s->pkt);
> > +s->pkt_offset = 0;
> > +}
>
> This looks like you're assembling a packet of max_framesize bytes. You
> should instead do that in a parser, and ensure here that the packets
> fed
> to this decoder are <= max_framesize.
>
> > +}
> > +
> > +frame->nb_samples = FFMIN(s->frame_samples, s->nb_samples);
> > +if (frame->nb_samples <= 0)
> > +return AVERROR_EOF;
> > +
> > +if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
> > +goto fail;
> > +
> > +if ((ret = init_get_bits8(gb, s->bitstream, s->bitstream_size))
> <
> >> 0)
> > +goto fail;
> > +
> > +if ((ret = osq_decode_block(avctx, frame)) < 0)
> > +goto fail;
> > +
> > +s->nb_samples -= frame->nb_samples;
> > +
> > +n = get_bits_count(gb) / 8;
> > +if (n > s->bitstream_size) {
> > +ret = AVERROR_INVALIDDATA;
> > +goto fail;
> > +}
> > +
> > +memmove(s->bitstream, >bitstream[n], s->bitstream_size - n);
> > +s->bitstream_size -= n;
> > +
> > +return 0;
> > +
> > +fail:
> > +s->bitstream_size = 0;
> > +s->pkt_offset = 0;
> > +av_packet_unref(s->pkt);
> > +
> > +return ret;
> > +}
> > +
> > +const AVInputFormat ff_osq_demuxer = {
> > +.name = "osq",
> > +.long_name = NULL_IF_CONFIG_SMALL("raw OSQ"),
> > +.read_probe = osq_probe,
> > +.read_header= osq_read_header,
> > +.read_packet= ff_raw_read_partial_packet,
>
> Instead of sending an arbitrarily sized packet (1024 bytes as of now),
> you should set codecpar->frame_size and propagate packets with that
> amount of bytes instead.
> A parser is still needed, though, for non seekable input (a pipe). And
> in case the decoder is fed with non lavf input.
>
> >>>
> >>> Format is not seekable, packet sizes are nowhere stored in .osq files.
> >>
> >> Same case as raw formats like H.264. No packet sizes, no seekability
> >> without having parsed the entire sequence to build a list of seek
> >> points, etc. A parser has to assemble access units.
> >>
> >
> > But there is no any info how to assemble anything here, unless
> > you propose decoding inside parser?
> >
> >
> >
> >>
> >>>
> >>> Think of this format like APAC/BONK/WAVARC but just no need to keep
> >> unused
> >>> bits from previous decoded data/packet.
> >>> With this fact, parser makes no sense to do.
> >>
> >> You know that frame_size is (frame_samples_per_channel * 16 + 1024) *
> >> channels. A parser can work with that (Look at gsm parser for example.
> >> There may be others too).
> >>
> >
> > There is reason why variable is called max_framesize.
> >
> > You should not propagate truncated data in 1024 byte chunks, and the
> >> decoder should not expect that either.
> >>
> >
> > Nothing gets truncated. That is just worst case scenario size for packet.
> > In another words, size of packet can be anything between 33 and
> > max_framesize.
>
> By truncated i mean the demuxer propagates arbitrary 1024 byte sized
> packets. And in the decoder you're assembling a buffer of max_framesize
> in osq_receive_frame() by requesting packets until you reach that size
> or EOF, whatever comes first, before calling osq_decode_block(). So
> unless you hit EOF, it will always be max_framesize. That's what i say
> should be done in a simple, small parser.
>
I fully understand you, but your reasoning is critically flawed.
And I have no time to educated an
Re: [FFmpeg-devel] [PATCH] OSQ lossless audio format support
On 8/24/2023 7:06 PM, Paul B Mahol wrote:
On Thu, Aug 24, 2023 at 11:51 PM James Almer wrote:
On 8/24/2023 6:11 PM, Paul B Mahol wrote:
On Thu, Aug 24, 2023 at 11:00 PM James Almer wrote:
On 8/24/2023 6:52 AM, Paul B Mahol wrote:
+static int osq_receive_frame(AVCodecContext *avctx, AVFrame *frame)
+{
+OSQContext *s = avctx->priv_data;
+GetBitContext *gb = >gb;
+int ret, n;
+
+while (s->bitstream_size < s->max_framesize) {
+int size;
+
+if (!s->pkt->data) {
+ret = ff_decode_get_packet(avctx, s->pkt);
+if (ret == AVERROR_EOF && s->bitstream_size > 0)
+break;
+if (ret < 0)
+return ret;
+}
+
+size = FFMIN(s->pkt->size - s->pkt_offset, s->max_framesize -
s->bitstream_size);
+memcpy(s->bitstream + s->bitstream_size, s->pkt->data +
s->pkt_offset, size);
+s->bitstream_size += size;
+s->pkt_offset += size;
+
+if (s->pkt_offset == s->pkt->size) {
+av_packet_unref(s->pkt);
+s->pkt_offset = 0;
+}
This looks like you're assembling a packet of max_framesize bytes. You
should instead do that in a parser, and ensure here that the packets fed
to this decoder are <= max_framesize.
+}
+
+frame->nb_samples = FFMIN(s->frame_samples, s->nb_samples);
+if (frame->nb_samples <= 0)
+return AVERROR_EOF;
+
+if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
+goto fail;
+
+if ((ret = init_get_bits8(gb, s->bitstream, s->bitstream_size)) <
0)
+goto fail;
+
+if ((ret = osq_decode_block(avctx, frame)) < 0)
+goto fail;
+
+s->nb_samples -= frame->nb_samples;
+
+n = get_bits_count(gb) / 8;
+if (n > s->bitstream_size) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
+
+memmove(s->bitstream, >bitstream[n], s->bitstream_size - n);
+s->bitstream_size -= n;
+
+return 0;
+
+fail:
+s->bitstream_size = 0;
+s->pkt_offset = 0;
+av_packet_unref(s->pkt);
+
+return ret;
+}
+
+const AVInputFormat ff_osq_demuxer = {
+.name = "osq",
+.long_name = NULL_IF_CONFIG_SMALL("raw OSQ"),
+.read_probe = osq_probe,
+.read_header= osq_read_header,
+.read_packet= ff_raw_read_partial_packet,
Instead of sending an arbitrarily sized packet (1024 bytes as of now),
you should set codecpar->frame_size and propagate packets with that
amount of bytes instead.
A parser is still needed, though, for non seekable input (a pipe). And
in case the decoder is fed with non lavf input.
Format is not seekable, packet sizes are nowhere stored in .osq files.
Same case as raw formats like H.264. No packet sizes, no seekability
without having parsed the entire sequence to build a list of seek
points, etc. A parser has to assemble access units.
But there is no any info how to assemble anything here, unless
you propose decoding inside parser?
Think of this format like APAC/BONK/WAVARC but just no need to keep
unused
bits from previous decoded data/packet.
With this fact, parser makes no sense to do.
You know that frame_size is (frame_samples_per_channel * 16 + 1024) *
channels. A parser can work with that (Look at gsm parser for example.
There may be others too).
There is reason why variable is called max_framesize.
You should not propagate truncated data in 1024 byte chunks, and the
decoder should not expect that either.
Nothing gets truncated. That is just worst case scenario size for packet.
In another words, size of packet can be anything between 33 and
max_framesize.
By truncated i mean the demuxer propagates arbitrary 1024 byte sized
packets. And in the decoder you're assembling a buffer of max_framesize
in osq_receive_frame() by requesting packets until you reach that size
or EOF, whatever comes first, before calling osq_decode_block(). So
unless you hit EOF, it will always be max_framesize. That's what i say
should be done in a simple, small parser.
+.extensions = "osq",
+.flags = AVFMT_NOBINSEARCH | AVFMT_NOGENSEARCH |
AVFMT_NO_BYTE_SEEK | AVFMT_NOTIMESTAMPS,
+.raw_codec_id = AV_CODEC_ID_OSQ,
+.priv_data_size = sizeof(FFRawDemuxerContext),
+.priv_class = _raw_demuxer_class,
+};
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link
Re: [FFmpeg-devel] [PATCH 2/2] doc/developer: Code pushed without patches on ffmpeg-devel must be announced on the ML
On Fri, Aug 25, 2023 at 5:36 PM Jean-Baptiste Kempf wrote: > > > On Fri, 25 Aug 2023, at 17:34, Michael Niedermayer wrote: > > On Thu, Aug 24, 2023 at 10:04:16PM +0200, Andreas Rheinhardt wrote: > >> Michael Niedermayer: > >> > Signed-off-by: Michael Niedermayer > >> > --- > >> > doc/developer.texi | 9 + > >> > 1 file changed, 9 insertions(+) > >> > > >> > diff --git a/doc/developer.texi b/doc/developer.texi > >> > index 383120daaa..1c0091fc74 100644 > >> > --- a/doc/developer.texi > >> > +++ b/doc/developer.texi > >> > @@ -856,6 +856,15 @@ way to get everyone's patches reviewed sooner. > >> > Reviews must be constructive and when rejecting a patch the reviewer > must explain > >> > their reasons and ideally suggest an alternative approach. > >> > > >> > +If a change is pushed without being sent to ffmpeg-devel, the > developer > >> > +pushing it must annouce doing so on the ffmpeg-devel mailing list > immedeatly. > >> > +@example > >> > +forgot a semicolon in this patch, pushed a seperate fix > >> > +pushed my new autograd engine and stable diffusion filter. Didnt > want to > >> > +go through the bikeshed if that belongs in FFmpeg, go to the GA if > you want > >> > +it removed. Otherwise Just tell me what i should improve and ill > look into it. > >> > +@end example > >> > >> This encourages pushing patches (even completely new filters) without > >> sending them to the ML. > > > > That was not the intend but if you look at "cvslog" and ffmpeg-devel, > you will > > notice that there are things being pushed that have not been seen on the > > ffmpeg-devel mailing list. > > So that means mandatory sending to the mailing list :) > > So that means I will fork librempeg and stop sending patches/commits here. > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] doc/developer: Code pushed without patches on ffmpeg-devel must be announced on the ML
On Fri, 25 Aug 2023, at 17:34, Michael Niedermayer wrote: > On Thu, Aug 24, 2023 at 10:04:16PM +0200, Andreas Rheinhardt wrote: >> Michael Niedermayer: >> > Signed-off-by: Michael Niedermayer >> > --- >> > doc/developer.texi | 9 + >> > 1 file changed, 9 insertions(+) >> > >> > diff --git a/doc/developer.texi b/doc/developer.texi >> > index 383120daaa..1c0091fc74 100644 >> > --- a/doc/developer.texi >> > +++ b/doc/developer.texi >> > @@ -856,6 +856,15 @@ way to get everyone's patches reviewed sooner. >> > Reviews must be constructive and when rejecting a patch the reviewer must >> > explain >> > their reasons and ideally suggest an alternative approach. >> > >> > +If a change is pushed without being sent to ffmpeg-devel, the developer >> > +pushing it must annouce doing so on the ffmpeg-devel mailing list >> > immedeatly. >> > +@example >> > +forgot a semicolon in this patch, pushed a seperate fix >> > +pushed my new autograd engine and stable diffusion filter. Didnt want to >> > +go through the bikeshed if that belongs in FFmpeg, go to the GA if you >> > want >> > +it removed. Otherwise Just tell me what i should improve and ill look >> > into it. >> > +@end example >> >> This encourages pushing patches (even completely new filters) without >> sending them to the ML. > > That was not the intend but if you look at "cvslog" and ffmpeg-devel, you will > notice that there are things being pushed that have not been seen on the > ffmpeg-devel mailing list. So that means mandatory sending to the mailing list :) -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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] doc/developer: Code pushed without patches on ffmpeg-devel must be announced on the ML
On Thu, Aug 24, 2023 at 10:04:16PM +0200, Andreas Rheinhardt wrote: > Michael Niedermayer: > > Signed-off-by: Michael Niedermayer > > --- > > doc/developer.texi | 9 + > > 1 file changed, 9 insertions(+) > > > > diff --git a/doc/developer.texi b/doc/developer.texi > > index 383120daaa..1c0091fc74 100644 > > --- a/doc/developer.texi > > +++ b/doc/developer.texi > > @@ -856,6 +856,15 @@ way to get everyone's patches reviewed sooner. > > Reviews must be constructive and when rejecting a patch the reviewer must > > explain > > their reasons and ideally suggest an alternative approach. > > > > +If a change is pushed without being sent to ffmpeg-devel, the developer > > +pushing it must annouce doing so on the ffmpeg-devel mailing list > > immedeatly. > > +@example > > +forgot a semicolon in this patch, pushed a seperate fix > > +pushed my new autograd engine and stable diffusion filter. Didnt want to > > +go through the bikeshed if that belongs in FFmpeg, go to the GA if you want > > +it removed. Otherwise Just tell me what i should improve and ill look into > > it. > > +@end example > > This encourages pushing patches (even completely new filters) without > sending them to the ML. That was not the intend but if you look at "cvslog" and ffmpeg-devel, you will notice that there are things being pushed that have not been seen on the ffmpeg-devel mailing list. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-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] doc/developer: Reviews must be constructive
Quoting Rémi Denis-Courmont (2023-08-25 17:09:55) > Le perjantaina 25. elokuuta 2023, 17.58.40 EEST Anton Khirnov a écrit : > > > And then sometimes an argument has been argued to death previously and > > > there is really no point to rehash it again and again. If people cannot > > > agree, they should refer to the TC, not brute force the review through > > > overwhelming insistance. > > > > I think we just have different interpretations of the word > > 'constructive' here. > > I certainly agree that some patches are just not acceptable - I certainly > > did not mean to imply that there must be a way forward for all patches. > > I think that you do not agree with the generally accepted meaning of > "constructive" in this context. By definition a review cannot be > constructive, > as in helpful or conducive of a way forward, if it argues that there are no > ways forward. Explaining why a patch is not acceptable is helpful IMO. Saying 'no', on the other hand, is not. > Maybe you meant "supported" or "corroborated". Might as well describe it in more than one word, since apparently it's so unclear. Would you be in favor of something along the lines of Nontrivial (i.e. other than cosmetics or accepting the patch) reviews must be based on technical arguments. If the reviewer fails to provide arguments for rejecting the patch or requesting changes, then the review may be disregarded. -- Anton Khirnov ___ 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] avcodec/apedec: Fix 48khz 24bit below insane level
On Fri, Aug 25, 2023 at 5:13 PM Michael Niedermayer
wrote:
> Fixes: Ticket9816
> Fixes: vlc.ape and APE_48K_24bit_2CH_02_01.ape
>
> Regression since: ed0001482a74b60f3d5bc5cd7e304c9d65b2fcd5.
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/apedec.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
> index 7bad8500e1..b1cceb9395 100644
> --- a/libavcodec/apedec.c
> +++ b/libavcodec/apedec.c
> @@ -1184,7 +1184,9 @@ static void predictor_decode_mono_3930(APEContext
> *ctx, int count)
> static av_always_inline int predictor_update_filter(APEPredictor64 *p,
> const int decoded,
> const int filter,
> const int delayA,
> const int delayB,
> -const int adaptA,
> const int adaptB)
> +const int adaptA,
> const int adaptB,
> +int compression_level
> + )
>
Why on ')' separate line?
> {
> int64_t predictionA, predictionB;
> int32_t sign;
> @@ -1212,7 +1214,12 @@ static av_always_inline int
> predictor_update_filter(APEPredictor64 *p,
>p->buf[delayB - 3] * p->coeffsB[filter][3] +
>p->buf[delayB - 4] * p->coeffsB[filter][4];
>
> -p->lastA[filter] = decoded + ((int64_t)((uint64_t)predictionA +
> (predictionB >> 1)) >> 10);
> +if (compression_level < COMPRESSION_LEVEL_INSANE) {
> +predictionA = (int32_t)predictionA;
> +predictionB = (int32_t)predictionB;
> +p->lastA[filter] = decoded + ((int32_t)(predictionA +
> (predictionB >> 1)) >> 10);
> +} else
> +p->lastA[filter] = decoded + ((int64_t)((uint64_t)predictionA +
> (predictionB >> 1)) >> 10);
>
Please make {} block.
> p->filterA[filter] = p->lastA[filter] + ((int64_t)(p->filterA[filter]
> * 31ULL) >> 5);
>
> sign = APESIGN(decoded);
> @@ -1240,10 +1247,10 @@ static void
> predictor_decode_stereo_3950(APEContext *ctx, int count)
> while (count--) {
> /* Predictor Y */
> *decoded0 = predictor_update_filter(p, *decoded0, 0, YDELAYA,
> YDELAYB,
> -YADAPTCOEFFSA, YADAPTCOEFFSB);
> +YADAPTCOEFFSA, YADAPTCOEFFSB,
> ctx->compression_level);
> decoded0++;
> *decoded1 = predictor_update_filter(p, *decoded1, 1, XDELAYA,
> XDELAYB,
> -XADAPTCOEFFSA, XADAPTCOEFFSB);
> +XADAPTCOEFFSA, XADAPTCOEFFSB,
> ctx->compression_level);
> decoded1++;
>
> /* Combined */
> --
> 2.17.1
>
>
OK with that style fixed, assuming it fixes that ticket and is still
bitexact with both files.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avcodec/apedec: Fix 48khz 24bit below insane level
Fixes: Ticket9816
Fixes: vlc.ape and APE_48K_24bit_2CH_02_01.ape
Regression since: ed0001482a74b60f3d5bc5cd7e304c9d65b2fcd5.
Signed-off-by: Michael Niedermayer
---
libavcodec/apedec.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
index 7bad8500e1..b1cceb9395 100644
--- a/libavcodec/apedec.c
+++ b/libavcodec/apedec.c
@@ -1184,7 +1184,9 @@ static void predictor_decode_mono_3930(APEContext *ctx,
int count)
static av_always_inline int predictor_update_filter(APEPredictor64 *p,
const int decoded, const
int filter,
const int delayA, const
int delayB,
-const int adaptA, const
int adaptB)
+const int adaptA, const
int adaptB,
+int compression_level
+ )
{
int64_t predictionA, predictionB;
int32_t sign;
@@ -1212,7 +1214,12 @@ static av_always_inline int
predictor_update_filter(APEPredictor64 *p,
p->buf[delayB - 3] * p->coeffsB[filter][3] +
p->buf[delayB - 4] * p->coeffsB[filter][4];
-p->lastA[filter] = decoded + ((int64_t)((uint64_t)predictionA +
(predictionB >> 1)) >> 10);
+if (compression_level < COMPRESSION_LEVEL_INSANE) {
+predictionA = (int32_t)predictionA;
+predictionB = (int32_t)predictionB;
+p->lastA[filter] = decoded + ((int32_t)(predictionA + (predictionB >>
1)) >> 10);
+} else
+p->lastA[filter] = decoded + ((int64_t)((uint64_t)predictionA +
(predictionB >> 1)) >> 10);
p->filterA[filter] = p->lastA[filter] + ((int64_t)(p->filterA[filter] *
31ULL) >> 5);
sign = APESIGN(decoded);
@@ -1240,10 +1247,10 @@ static void predictor_decode_stereo_3950(APEContext
*ctx, int count)
while (count--) {
/* Predictor Y */
*decoded0 = predictor_update_filter(p, *decoded0, 0, YDELAYA, YDELAYB,
-YADAPTCOEFFSA, YADAPTCOEFFSB);
+YADAPTCOEFFSA, YADAPTCOEFFSB,
ctx->compression_level);
decoded0++;
*decoded1 = predictor_update_filter(p, *decoded1, 1, XDELAYA, XDELAYB,
-XADAPTCOEFFSA, XADAPTCOEFFSB);
+XADAPTCOEFFSA, XADAPTCOEFFSB,
ctx->compression_level);
decoded1++;
/* Combined */
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avcodec/apedec: Fix CRC for 24bps and bigendian
Fixes CRC for vlc.ape and APE_48K_24bit_2CH_02_01.ape
Signed-off-by: Michael Niedermayer
---
libavcodec/apedec.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
index 613c76df0b..7bad8500e1 100644
--- a/libavcodec/apedec.c
+++ b/libavcodec/apedec.c
@@ -1625,13 +1625,24 @@ static int ape_decode_frame(AVCodecContext *avctx,
AVFrame *frame,
s->samples -= blockstodecode;
if (avctx->err_recognition & AV_EF_CRCCHECK &&
-s->fileversion >= 3900 && s->bps < 24) {
+s->fileversion >= 3900) {
uint32_t crc = s->CRC_state;
const AVCRC *crc_tab = av_crc_get_table(AV_CRC_32_IEEE_LE);
+int stride = s->bps == 24 ? 4 : (s->bps>>3);
+int offset = s->bps == 24;
+int bytes = s->bps >> 3;
+
for (i = 0; i < blockstodecode; i++) {
for (ch = 0; ch < s->channels; ch++) {
-uint8_t *smp = frame->data[ch] + (i*(s->bps >> 3));
-crc = av_crc(crc_tab, crc, smp, s->bps >> 3);
+#if HAVE_BIGENDIAN
+uint8_t *smp_native = frame->data[ch] + i*stride;
+uint8_t smp[4];
+for(int j = 0; jdata[ch] + i*stride;
+#endif
+crc = av_crc(crc_tab, crc, smp+offset, bytes);
}
}
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] doc/developer: Reviews must be constructive
Le perjantaina 25. elokuuta 2023, 17.58.40 EEST Anton Khirnov a écrit : > > And then sometimes an argument has been argued to death previously and > > there is really no point to rehash it again and again. If people cannot > > agree, they should refer to the TC, not brute force the review through > > overwhelming insistance. > > I think we just have different interpretations of the word > 'constructive' here. > I certainly agree that some patches are just not acceptable - I certainly > did not mean to imply that there must be a way forward for all patches. I think that you do not agree with the generally accepted meaning of "constructive" in this context. By definition a review cannot be constructive, as in helpful or conducive of a way forward, if it argues that there are no ways forward. Maybe you meant "supported" or "corroborated". -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ 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] doc/developer: Reviews must be constructive
Quoting Rémi Denis-Courmont (2023-08-25 16:22:45) > Le torstaina 24. elokuuta 2023, 22.56.14 EEST Michael Niedermayer a écrit : > > Suggested text is from Anton > > > > Signed-off-by: Michael Niedermayer > > --- > > doc/developer.texi | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/doc/developer.texi b/doc/developer.texi > > index 0c2f2cd7d1..383120daaa 100644 > > --- a/doc/developer.texi > > +++ b/doc/developer.texi > > @@ -853,6 +853,9 @@ Everyone is welcome to review patches. Also if you are > > waiting for your patch to be reviewed, please consider helping to review > > other patches, that is a great way to get everyone's patches reviewed > > sooner. > > > > +Reviews must be constructive > > Well, frankly, no. You're really confusing code reviews with teaching here. A > code review is first and foremost meant to find problems and avoid adding > bugs > or bad designs into the code base. It is not meant to solve problems. Of > course, it is preferable for a review to be constructive, but it is not > always > possible or reasonable. > > Sometimes code just does not belong in. > > Sometimes the reviewer can prove or make strong arguments that a patch is > broken or bad, without having constructive feedback to give. This is just > like > mathematical proofs. Some are constructive, some aren't. > > And then sometimes an argument has been argued to death previously and there > is really no point to rehash it again and again. If people cannot agree, they > should refer to the TC, not brute force the review through overwhelming > insistance. I think we just have different interpretations of the word 'constructive' here. I certainly agree that some patches are just not acceptable - I certainly did not mean to imply that there must be a way forward for all patches. The intent is rather that every review (other than OK) should be based on technical arguments and not be a semantic equivalent of 'no'. In case you did not notice, we have a persistent problem with some people who are sending "reviews" of exactly this type. I don't think that should be acceptable. Would you be happier with some reformulation of the text that makes this more clear? -- Anton Khirnov ___ 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] Revert "avcodec/apedec: fix decoding 24bit insane files with recent versions"
On Fri, Aug 25, 2023 at 4:21 PM Michael Niedermayer wrote: > On Fri, Aug 25, 2023 at 11:08:55AM +0200, Paul B Mahol wrote: > > On Fri, Aug 25, 2023 at 2:01 AM Michael Niedermayer < > mich...@niedermayer.cc> > > wrote: > > > > > On Fri, Aug 25, 2023 at 01:37:27AM +0200, Paul B Mahol wrote: > > > > NAK > > > > > > > > Breaks decoding of another sample. > > > > > > please provide the sample > > > > > > if noone provides a sample, i will disregard this objection. > > > Also as a sidenote, iam in contact with Matt Ashland and he also > > > doesnt know what your commit was trying to fix > > > > > > > What to say, monkey see - monkey do. > > > > > Just wasted too much time on running latest MAC converter software in > > virtualbox to confirm > > you break this ticket bellow with your patch set. > > you dont need virtualbox to run ffmpeg to test the samples > if you used virtualbox to generate more samples, please share them so > i can make sure there are no regressions on changes > > MAC is reference Monkey's APEs encoder/decoder Windows only utility. Just make sure that its not also MAC regression somehow... > > > > https://trac.ffmpeg.org/ticket/8918 > > thanks for the testcase, i will make sure my next pachset will not break > that > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > What does censorship reveal? It reveals fear. -- Julian Assange > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] doc/developer: Reviews must be constructive
Le torstaina 24. elokuuta 2023, 22.56.14 EEST Michael Niedermayer a écrit : > Suggested text is from Anton > > Signed-off-by: Michael Niedermayer > --- > doc/developer.texi | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/doc/developer.texi b/doc/developer.texi > index 0c2f2cd7d1..383120daaa 100644 > --- a/doc/developer.texi > +++ b/doc/developer.texi > @@ -853,6 +853,9 @@ Everyone is welcome to review patches. Also if you are > waiting for your patch to be reviewed, please consider helping to review > other patches, that is a great way to get everyone's patches reviewed > sooner. > > +Reviews must be constructive Well, frankly, no. You're really confusing code reviews with teaching here. A code review is first and foremost meant to find problems and avoid adding bugs or bad designs into the code base. It is not meant to solve problems. Of course, it is preferable for a review to be constructive, but it is not always possible or reasonable. Sometimes code just does not belong in. Sometimes the reviewer can prove or make strong arguments that a patch is broken or bad, without having constructive feedback to give. This is just like mathematical proofs. Some are constructive, some aren't. And then sometimes an argument has been argued to death previously and there is really no point to rehash it again and again. If people cannot agree, they should refer to the TC, not brute force the review through overwhelming insistance. Also what Vittorio already pointed out. Ultimately, this is also a question of what to optimise for. And in my 20+ years experience with software development and open-source, I think it's abundantly clear that available skilled reviewers are an ever scarcer resource than skilled available developers, so you should not optimise for the later. So -1 as far as I am concerned. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ 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] Revert "avcodec/apedec: fix decoding 24bit insane files with recent versions"
On Fri, Aug 25, 2023 at 11:08:55AM +0200, Paul B Mahol wrote: > On Fri, Aug 25, 2023 at 2:01 AM Michael Niedermayer > wrote: > > > On Fri, Aug 25, 2023 at 01:37:27AM +0200, Paul B Mahol wrote: > > > NAK > > > > > > Breaks decoding of another sample. > > > > please provide the sample > > > > if noone provides a sample, i will disregard this objection. > > Also as a sidenote, iam in contact with Matt Ashland and he also > > doesnt know what your commit was trying to fix > > > > What to say, monkey see - monkey do. > > Just wasted too much time on running latest MAC converter software in > virtualbox to confirm > you break this ticket bellow with your patch set. you dont need virtualbox to run ffmpeg to test the samples if you used virtualbox to generate more samples, please share them so i can make sure there are no regressions on changes > > https://trac.ffmpeg.org/ticket/8918 thanks for the testcase, i will make sure my next pachset will not break that [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] doc/developer: Reviews must be constructive
Quoting Vittorio Giovara (2023-08-25 03:56:44) > On Thu, Aug 24, 2023 at 9:56 PM Michael Niedermayer > wrote: > > > Suggested text is from Anton > > > > Signed-off-by: Michael Niedermayer > > --- > > doc/developer.texi | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/doc/developer.texi b/doc/developer.texi > > index 0c2f2cd7d1..383120daaa 100644 > > --- a/doc/developer.texi > > +++ b/doc/developer.texi > > @@ -853,6 +853,9 @@ Everyone is welcome to review patches. Also if you are > > waiting for your patch > > to be reviewed, please consider helping to review other patches, that is > > a great > > way to get everyone's patches reviewed sooner. > > > > +Reviews must be constructive and when rejecting a patch the reviewer must > > explain > > +their reasons and ideally suggest an alternative approach. > > > > NAK > we shouldn't put extra burden on reviewers, nor guilt trap them into > suggesting an alternative approach I don't understand this argument at all. First, "ideally suggest an alternative approach" is an aspiration, not a hard requirement. Second, I don't think reviewers should be able to reject patches with no explanation. The author/submitter spent time and effort on writing and submitting the patch - it is only fair that if it's to be rejected, it should be done for a clear reason. > offlist and irc discussion is of course recommended, I absolutely do not recommend offlist discussion, as it is not visible to other developers or preserved in the archives. > but writing this rules in stone will only deter good reviews, in my > opinion Non-constructive reviews without an explanation are never good reviews. -- Anton Khirnov ___ 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 2/2] avformat/rtmpproto: support enhanced rtmp
Steven Liu 于2023年8月25日周五 18:05写道：
>
> Add option named rtmp_enhanced_codec,
> it would support hvc1,av01,vp09 now,
> the fourcc is using Array of strings.
>
> Signed-off-by: Steven Liu
> ---
> doc/protocols.texi | 6 ++
> libavformat/rtmpproto.c | 37 +
> 2 files changed, 43 insertions(+)
>
> diff --git a/doc/protocols.texi b/doc/protocols.texi
> index b3fad55591..bd2b25e502 100644
> --- a/doc/protocols.texi
> +++ b/doc/protocols.texi
> @@ -896,6 +896,12 @@ be named, by prefixing the type with 'N' and specifying
> the name before
> the value (i.e. @code{NB:myFlag:1}). This option may be used multiple
> times to construct arbitrary AMF sequences.
>
> +@item rtmp_enhanced_codecs
> +Specify the list of codecs the client advertises to support in an
> +enhanced RTMP stream. This option should set a string like
> @code{hvc1,av01,vp09}
> +for multiple codecs, or @code{hvc1} for only one codec,
> +set codec fourcc into fourCcLive property into Connect Command Message,
> +
> @item rtmp_flashver
> Version of the Flash plugin used to run the SWF player. The default
> is LNX 9,0,124,2. (When publishing, the default is FMLE/3.0 (compatible;
> diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
> index f0ef223f05..10e0aed539 100644
> --- a/libavformat/rtmpproto.c
> +++ b/libavformat/rtmpproto.c
> @@ -127,6 +127,7 @@ typedef struct RTMPContext {
> int nb_streamid;///< The next stream id to
> return on createStream calls
> doubleduration; ///< Duration of the stream in
> seconds as returned by the server (only valid if non-zero)
> int tcp_nodelay;///< Use TCP_NODELAY to
> disable Nagle's algorithm if set to 1
> +char *enhanced_codecs; ///< codec list in enhanced
> rtmp
> char username[50];
> char password[50];
> char auth_params[500];
> @@ -336,6 +337,41 @@ static int gen_connect(URLContext *s, RTMPContext *rt)
> ff_amf_write_field_name(, "app");
> ff_amf_write_string2(, rt->app, rt->auth_params);
>
> +if (rt->enhanced_codecs) {
> +uint32_t list_len = 0;
> +char *fourcc_data = rt->enhanced_codecs;
> +int fourcc_str_len = strlen(fourcc_data);
> +
> +// check the string, fourcc + ',' + ... + end fourcc correct length
> should be (4+1)*n+4
> +if ((fourcc_str_len + 1) % 5 != 0) {
> +av_log(s, AV_LOG_ERROR, "Malformed rtmp_enhanched_codecs, "
> + "should be of the form hvc1[,av01][,vp09][,...]\n");
> +return AVERROR(EINVAL);
> +}
> +
> +list_len = (fourcc_str_len + 1) / 5;
> +// write the fourCcList field name
> +ff_amf_write_field_name(, "fourCcList");
> +
> +// write the fourcc array length
> +ff_amf_write_array_start(, list_len);
> +
> +while(fourcc_data - rt->enhanced_codecs < fourcc_str_len) {
> +unsigned char fourcc[5];
> +if (!strncasecmp(fourcc_data, "hvc1", 4) ||
> +!strncasecmp(fourcc_data, "av01", 4) ||
> +!strncasecmp(fourcc_data, "vp09", 4)) {
s/strncasecmp/av_strncasecmp/g fix local.
> +av_strlcpy(fourcc, fourcc_data, sizeof(fourcc));
> +ff_amf_write_string(, fourcc);
> +} else {
> +av_log(s, AV_LOG_ERROR, "Unsupported codec fourcc,
> %.*s\n", 4, fourcc_data);
> +return AVERROR_PATCHWELCOME;
> +}
> +
> +fourcc_data += 5;
> +}
> +}
> +
> if (!rt->is_input) {
> ff_amf_write_field_name(, "type");
> ff_amf_write_string(, "nonprivate");
> @@ -3104,6 +3140,7 @@ static const AVOption rtmp_options[] = {
> {"rtmp_conn", "Append arbitrary AMF data to the Connect message",
> OFFSET(conn), AV_OPT_TYPE_STRING, {.str = NULL }, 0, 0, DEC|ENC},
> {"rtmp_flashver", "Version of the Flash plugin used to run the SWF
> player.", OFFSET(flashver), AV_OPT_TYPE_STRING, {.str = NULL }, 0, 0,
> DEC|ENC},
> {"rtmp_flush_interval", "Number of packets flushed in the same request
> (RTMPT only).", OFFSET(flush_interval), AV_OPT_TYPE_INT, {.i64 = 10}, 0,
> INT_MAX, ENC},
> +{"rtmp_enhanced_codecs", "Specify the codec(s) to use in an enhanced
> rtmp live stream", OFFSET(enhanced_codecs), AV_OPT_TYPE_STRING, {.str = NULL
> }, 0, 0, ENC},
> {"rtmp_live", "Specify that the media is a live stream.", OFFSET(live),
> AV_OPT_TYPE_INT, {.i64 = -2}, INT_MIN, INT_MAX, DEC, "rtmp_live"},
> {"any", "both", 0, AV_OPT_TYPE_CONST, {.i64 = -2}, 0, 0, DEC,
> "rtmp_live"},
> {"live", "live stream", 0, AV_OPT_TYPE_CONST, {.i64 = -1}, 0, 0, DEC,
> "rtmp_live"},
> --
> 2.40.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To
Re: [FFmpeg-devel] [PATCH v2 2/2] avformat/rtmpproto: support enhanced rtmp
On Fri, 25 Aug 2023, Steven Liu wrote:
Martin Storsjö 于2023年8月25日周五 17:38写道：
On Fri, 25 Aug 2023, Steven Liu wrote:
>> > +list_len = (fourcc_str_len + 1) / 5;
>> > +// write the fourCcList field name
>> > +ff_amf_write_field_name(, "fourCcList");
>> > +
>> > +// write the fourcc array length
>> > +ff_amf_write_array_start(, list_len);
>> > +
>> > +while(fourcc_data - rt->enhanced_codecs < fourcc_str_len) {
>> > +unsigned char fourcc[5];
>> > +switch (AV_RN32(fourcc_data)) {
>> > +case MKTAG('h', 'v', 'c', '1'):
>>
>> This feels a bit convoluted to use AV_RN32 + MKTAG on data that is already
>> just a string - just using strncmp(fourcc_data, "hvc1", 4) would work just
> I want use strncmp at first, but i think strncmp will slower than
> switch uint32_t value, so i chose use uint32_t. or should i use
> strncmp?
Yes, strncmp will be slower than switching on an uint32_t - but this isn't
really performance sensitive code. We do this once only, on startup, on a
handful of fourccs. So I believe code clarity is more important than
absolute performance here.
Okay, i use strncasecmp next version patch.
I don't see a need for this to be case insensitive?
But i must told you, I think MKTAG is clarity than use if+strncmp to me,
Because there looks like a fourcc codec list align code block.
If you prefer MKTAG for clarity, then I guess the current solution is fine
here for me as well - it's not a hard opinion from me. Let's see if
someone else wants to comment on it first maybe.
// Martin
___
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 v3 2/2] avformat/rtmpproto: support enhanced rtmp
Add option named rtmp_enhanced_codec,
it would support hvc1,av01,vp09 now,
the fourcc is using Array of strings.
Signed-off-by: Steven Liu
---
doc/protocols.texi | 6 ++
libavformat/rtmpproto.c | 37 +
2 files changed, 43 insertions(+)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index b3fad55591..bd2b25e502 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -896,6 +896,12 @@ be named, by prefixing the type with 'N' and specifying
the name before
the value (i.e. @code{NB:myFlag:1}). This option may be used multiple
times to construct arbitrary AMF sequences.
+@item rtmp_enhanced_codecs
+Specify the list of codecs the client advertises to support in an
+enhanced RTMP stream. This option should set a string like
@code{hvc1,av01,vp09}
+for multiple codecs, or @code{hvc1} for only one codec,
+set codec fourcc into fourCcLive property into Connect Command Message,
+
@item rtmp_flashver
Version of the Flash plugin used to run the SWF player. The default
is LNX 9,0,124,2. (When publishing, the default is FMLE/3.0 (compatible;
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index f0ef223f05..10e0aed539 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -127,6 +127,7 @@ typedef struct RTMPContext {
int nb_streamid;///< The next stream id to
return on createStream calls
doubleduration; ///< Duration of the stream in
seconds as returned by the server (only valid if non-zero)
int tcp_nodelay;///< Use TCP_NODELAY to disable
Nagle's algorithm if set to 1
+char *enhanced_codecs; ///< codec list in enhanced rtmp
char username[50];
char password[50];
char auth_params[500];
@@ -336,6 +337,41 @@ static int gen_connect(URLContext *s, RTMPContext *rt)
ff_amf_write_field_name(, "app");
ff_amf_write_string2(, rt->app, rt->auth_params);
+if (rt->enhanced_codecs) {
+uint32_t list_len = 0;
+char *fourcc_data = rt->enhanced_codecs;
+int fourcc_str_len = strlen(fourcc_data);
+
+// check the string, fourcc + ',' + ... + end fourcc correct length
should be (4+1)*n+4
+if ((fourcc_str_len + 1) % 5 != 0) {
+av_log(s, AV_LOG_ERROR, "Malformed rtmp_enhanched_codecs, "
+ "should be of the form hvc1[,av01][,vp09][,...]\n");
+return AVERROR(EINVAL);
+}
+
+list_len = (fourcc_str_len + 1) / 5;
+// write the fourCcList field name
+ff_amf_write_field_name(, "fourCcList");
+
+// write the fourcc array length
+ff_amf_write_array_start(, list_len);
+
+while(fourcc_data - rt->enhanced_codecs < fourcc_str_len) {
+unsigned char fourcc[5];
+if (!strncasecmp(fourcc_data, "hvc1", 4) ||
+!strncasecmp(fourcc_data, "av01", 4) ||
+!strncasecmp(fourcc_data, "vp09", 4)) {
+av_strlcpy(fourcc, fourcc_data, sizeof(fourcc));
+ff_amf_write_string(, fourcc);
+} else {
+av_log(s, AV_LOG_ERROR, "Unsupported codec fourcc,
%.*s\n", 4, fourcc_data);
+return AVERROR_PATCHWELCOME;
+}
+
+fourcc_data += 5;
+}
+}
+
if (!rt->is_input) {
ff_amf_write_field_name(, "type");
ff_amf_write_string(, "nonprivate");
@@ -3104,6 +3140,7 @@ static const AVOption rtmp_options[] = {
{"rtmp_conn", "Append arbitrary AMF data to the Connect message",
OFFSET(conn), AV_OPT_TYPE_STRING, {.str = NULL }, 0, 0, DEC|ENC},
{"rtmp_flashver", "Version of the Flash plugin used to run the SWF
player.", OFFSET(flashver), AV_OPT_TYPE_STRING, {.str = NULL }, 0, 0, DEC|ENC},
{"rtmp_flush_interval", "Number of packets flushed in the same request
(RTMPT only).", OFFSET(flush_interval), AV_OPT_TYPE_INT, {.i64 = 10}, 0,
INT_MAX, ENC},
+{"rtmp_enhanced_codecs", "Specify the codec(s) to use in an enhanced rtmp
live stream", OFFSET(enhanced_codecs), AV_OPT_TYPE_STRING, {.str = NULL }, 0,
0, ENC},
{"rtmp_live", "Specify that the media is a live stream.", OFFSET(live),
AV_OPT_TYPE_INT, {.i64 = -2}, INT_MIN, INT_MAX, DEC, "rtmp_live"},
{"any", "both", 0, AV_OPT_TYPE_CONST, {.i64 = -2}, 0, 0, DEC, "rtmp_live"},
{"live", "live stream", 0, AV_OPT_TYPE_CONST, {.i64 = -1}, 0, 0, DEC,
"rtmp_live"},
--
2.40.0
___
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 v3 1/2] avformat/rtmppkt: add ff_amf_write_array for write
Signed-off-by: Steven Liu
---
libavformat/rtmppkt.c | 6 ++
libavformat/rtmppkt.h | 8
2 files changed, 14 insertions(+)
diff --git a/libavformat/rtmppkt.c b/libavformat/rtmppkt.c
index 4b97c0833f..a602bf6a96 100644
--- a/libavformat/rtmppkt.c
+++ b/libavformat/rtmppkt.c
@@ -40,6 +40,12 @@ void ff_amf_write_number(uint8_t **dst, double val)
bytestream_put_be64(dst, av_double2int(val));
}
+void ff_amf_write_array_start(uint8_t **dst, uint32_t length)
+{
+bytestream_put_byte(dst, AMF_DATA_TYPE_ARRAY);
+bytestream_put_be32(dst, length);
+}
+
void ff_amf_write_string(uint8_t **dst, const char *str)
{
bytestream_put_byte(dst, AMF_DATA_TYPE_STRING);
diff --git a/libavformat/rtmppkt.h b/libavformat/rtmppkt.h
index a15d2a5773..7c580f2224 100644
--- a/libavformat/rtmppkt.h
+++ b/libavformat/rtmppkt.h
@@ -244,6 +244,14 @@ void ff_amf_write_null(uint8_t **dst);
*/
void ff_amf_write_object_start(uint8_t **dst);
+/**
+ * Write marker and length for AMF array to buffer.
+ *
+ * @param dst pointer to the input buffer (will be modified)
+ * @param length value to write
+ */
+void ff_amf_write_array_start(uint8_t **dst, uint32_t length);
+
/**
* Write string used as field name in AMF object to buffer.
*
--
2.40.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/libx264: enable x4->params.analyse.b_fast_pskip if mb_info is set
x4->params.analyse.b_fast_pskip should only be forced in case mb_info
is set.
Fix output change introduced in 418c954e318.
---
libavcodec/libx264.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 1a7dc7bdd5..a2877d7f75 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -1190,7 +1190,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
x4->params.analyse.b_mb_info = x4->mb_info;
-x4->params.analyse.b_fast_pskip = 1;
+if (x4->mb_info) {
+x4->params.analyse.b_fast_pskip = x4->mb_info;
+}
// update AVCodecContext with x264 parameters
avctx->has_b_frames = x4->params.i_bframe ?
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] avformat/rtmpproto: support enhanced rtmp
Martin Storsjö 于2023年8月25日周五 17:38写道：
>
> On Fri, 25 Aug 2023, Steven Liu wrote:
>
> >> > +list_len = (fourcc_str_len + 1) / 5;
> >> > +// write the fourCcList field name
> >> > +ff_amf_write_field_name(, "fourCcList");
> >> > +
> >> > +// write the fourcc array length
> >> > +ff_amf_write_array_start(, list_len);
> >> > +
> >> > +while(fourcc_data - rt->enhanced_codecs < fourcc_str_len) {
> >> > +unsigned char fourcc[5];
> >> > +switch (AV_RN32(fourcc_data)) {
> >> > +case MKTAG('h', 'v', 'c', '1'):
> >>
> >> This feels a bit convoluted to use AV_RN32 + MKTAG on data that is already
> >> just a string - just using strncmp(fourcc_data, "hvc1", 4) would work just
> > I want use strncmp at first, but i think strncmp will slower than
> > switch uint32_t value, so i chose use uint32_t. or should i use
> > strncmp?
>
> Yes, strncmp will be slower than switching on an uint32_t - but this isn't
> really performance sensitive code. We do this once only, on startup, on a
> handful of fourccs. So I believe code clarity is more important than
> absolute performance here.
Okay, i use strncasecmp next version patch. But i must told you, I
think MKTAG is clarity than use if+strncmp to me,
Because there looks like a fourcc codec list align code block.
>
> // Martin
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] avformat/rtmpproto: support enhanced rtmp
On Fri, 25 Aug 2023, Steven Liu wrote:
> +list_len = (fourcc_str_len + 1) / 5;
> +// write the fourCcList field name
> +ff_amf_write_field_name(, "fourCcList");
> +
> +// write the fourcc array length
> +ff_amf_write_array_start(, list_len);
> +
> +while(fourcc_data - rt->enhanced_codecs < fourcc_str_len) {
> +unsigned char fourcc[5];
> +switch (AV_RN32(fourcc_data)) {
> +case MKTAG('h', 'v', 'c', '1'):
This feels a bit convoluted to use AV_RN32 + MKTAG on data that is already
just a string - just using strncmp(fourcc_data, "hvc1", 4) would work just
I want use strncmp at first, but i think strncmp will slower than
switch uint32_t value, so i chose use uint32_t. or should i use
strncmp?
Yes, strncmp will be slower than switching on an uint32_t - but this isn't
really performance sensitive code. We do this once only, on startup, on a
handful of fourccs. So I believe code clarity is more important than
absolute performance here.
// Martin
___
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] avformat/mp3dec: Subtract known padding from duration
Just noticed that there is a ticket
https://trac.ffmpeg.org/ticket/10163 about this, that I believe is
solved with this patch.
Den ons 23 aug. 2023 kl 20:33 skrev Ulrik Mikaelsson
:
>
> When an Info-tag is present, marking initial and trailing samples as
> padding, those samples should not be included in the calculation of track
> duration.
>
> This solves a surprising user experience where converting a WAV->MP3->WAV,
> ffprobe will show the duration of the mp3 as slightly longer than both the
> input and the output.
>
> As a result, the estimated duration and imprecise seek-results of some
> FATE-tests have been updated.
> ---
> libavformat/mp3dec.c | 19 +--
> tests/ref/fate/gapless-mp3-side-data | 4 ++--
> tests/ref/seek/extra-mp3 | 8
> 3 files changed, 19 insertions(+), 12 deletions(-)
>
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index 05c13228bc..24ec4dae06 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -51,6 +51,7 @@ typedef struct {
> int usetoc;
> unsigned frames; /* Total number of frames in file */
> unsigned header_filesize; /* Total number of bytes in the stream */
> +unsigned frame_duration; /* Frame duration in st->time_base */
> int is_cbr;
> } MP3DecContext;
>
> @@ -339,6 +340,7 @@ static int mp3_parse_vbr_tags(AVFormatContext *s,
> AVStream *st, int64_t base)
>
> mp3->frames = 0;
> mp3->header_filesize = 0;
> +mp3->frame_duration = av_rescale_q(spf, (AVRational){1, c.sample_rate},
> st->time_base);
>
> mp3_parse_info_tag(s, st, , spf);
> mp3_parse_vbri_tag(s, st, base);
> @@ -349,11 +351,17 @@ static int mp3_parse_vbr_tags(AVFormatContext *s,
> AVStream *st, int64_t base)
> /* Skip the vbr tag frame */
> avio_seek(s->pb, base + vbrtag_size, SEEK_SET);
>
> -if (mp3->frames)
> -st->duration = av_rescale_q(mp3->frames, (AVRational){spf,
> c.sample_rate},
> +if (mp3->frames) {
> +int64_t full_duration;
> +
> +full_duration = mp3->frames * (int64_t)spf;
> +st->duration = av_rescale_q(full_duration - mp3->start_pad -
> mp3->end_pad,
> +(AVRational){1, c.sample_rate},
> st->time_base);
> -if (mp3->header_filesize && mp3->frames && !mp3->is_cbr)
> -st->codecpar->bit_rate = av_rescale(mp3->header_filesize, 8 *
> c.sample_rate, mp3->frames * (int64_t)spf);
> +
> +if (mp3->header_filesize && !mp3->is_cbr)
> +st->codecpar->bit_rate = av_rescale(mp3->header_filesize, 8 *
> c.sample_rate, full_duration);
> +}
>
> return 0;
> }
> @@ -589,8 +597,7 @@ static int mp3_seek(AVFormatContext *s, int stream_index,
> int64_t timestamp,
> return best_pos;
>
> if (mp3->is_cbr && ie == && mp3->frames) {
> -int frame_duration = av_rescale(st->duration, 1, mp3->frames);
> -ie1.timestamp = frame_duration * av_rescale(best_pos -
> si->data_offset, mp3->frames, mp3->header_filesize);
> +ie1.timestamp = mp3->frame_duration * av_rescale(best_pos -
> si->data_offset, mp3->frames, mp3->header_filesize);
> }
>
> avpriv_update_cur_dts(s, st, ie->timestamp);
> diff --git a/tests/ref/fate/gapless-mp3-side-data
> b/tests/ref/fate/gapless-mp3-side-data
> index caf42068dc..495a5bb865 100644
> --- a/tests/ref/fate/gapless-mp3-side-data
> +++ b/tests/ref/fate/gapless-mp3-side-data
> @@ -596,5 +596,5 @@
> packet|codec_type=audio|stream_index=0|pts=218603520|pts_time=15.490612|dts=2186
>
>
> packet|codec_type=audio|stream_index=0|pts=218972160|pts_time=15.516735|dts=218972160|dts_time=15.516735|duration=368640|duration_time=0.026122|size=418|pos=249718|flags=K__|data_hash=CRC32:3789f3cf|side_data|side_data_type=Skip
> Samples|skip_samples=0|discard_padding=1152|skip_reason=0|discard_reason=0
>
> -stream|index=0|codec_name=mp3|profile=unknown|codec_type=audio|codec_tag_string=[0][0][0][0]|codec_tag=0x|sample_fmt=fltp|sample_rate=44100|channels=2|channel_layout=stereo|bits_per_sample=0|initial_padding=0|id=N/A|r_frame_rate=0/0|avg_frame_rate=0/0|time_base=1/14112000|start_pts=353600|start_time=0.025057|duration_ts=219340800|duration=15.542857|bit_rate=128000|max_bit_rate=N/A|bits_per_raw_sample=N/A|nb_frames=N/A|nb_read_frames=N/A|nb_read_packets=595|disposition:default=0|disposition:dub=0|disposition:original=0|disposition:comment=0|disposition:lyrics=0|disposition:karaoke=0|disposition:forced=0|disposition:hearing_impaired=0|disposition:visual_impaired=0|disposition:clean_effects=0|disposition:attached_pic=0|disposition:timed_thumbnails=0|disposition:captions=0|disposition:descriptions=0|disposition:metadata=0|disposition:dependent=0|disposition:still_image=0|tag:encoder=LAME3.93
> -format|filename=gapless.mp3|nb_streams=1|nb_programs=0|format_name=mp3|start_time=0.025057|duration=15.542857|size=250264|bit_rate=128812|probe_score=51|tag:title=test
>
Re: [FFmpeg-devel] [PATCH 1/2] doc/developer: Reviews must be constructive
On Fri, Aug 25, 2023 at 8:46 AM Nicolas George wrote: > Vittorio Giovara (12023-08-25): > > NAK > > we shouldn't put extra burden on reviewers, nor guilt trap them into > > suggesting an alternative approach > > It is hilarious, in a very sad way, that you prefer put extra burden on > people who do things than on people who block them. > It is easier to post dubious solutions instead of doing proper research or/and review. > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] avformat/rtmpproto: support enhanced rtmp
Martin Storsjö 于2023年8月25日周五 17:04写道：
>
> On Fri, 25 Aug 2023, Steven Liu wrote:
>
> > Add option named rtmp_enhanced_codec,
> > it would support hvc1,av01,vp09 now,
> > the fourcc is using Array of strings.
> >
> > Signed-off-by: Steven Liu
> > ---
> > doc/protocols.texi | 6 ++
> > libavformat/rtmpproto.c | 35 +++
> > 2 files changed, 41 insertions(+)
> >
> > diff --git a/doc/protocols.texi b/doc/protocols.texi
> > index b3fad55591..bd2b25e502 100644
> > --- a/doc/protocols.texi
> > +++ b/doc/protocols.texi
> > @@ -896,6 +896,12 @@ be named, by prefixing the type with 'N' and
> > specifying the name before
> > the value (i.e. @code{NB:myFlag:1}). This option may be used multiple
> > times to construct arbitrary AMF sequences.
> >
> > +@item rtmp_enhanced_codecs
> > +Specify the list of codecs the client advertises to support in an
> > +enhanced RTMP stream. This option should set a string like
> > @code{hvc1,av01,vp09}
> > +for multiple codecs, or @code{hvc1} for only one codec,
> > +set codec fourcc into fourCcLive property into Connect Command Message,
> > +
> > @item rtmp_flashver
> > Version of the Flash plugin used to run the SWF player. The default
> > is LNX 9,0,124,2. (When publishing, the default is FMLE/3.0 (compatible;
> > diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
> > index f0ef223f05..ea25454362 100644
> > --- a/libavformat/rtmpproto.c
> > +++ b/libavformat/rtmpproto.c
> > @@ -127,6 +127,7 @@ typedef struct RTMPContext {
> > int nb_streamid;///< The next stream id to
> > return on createStream calls
> > doubleduration; ///< Duration of the stream
> > in seconds as returned by the server (only valid if non-zero)
> > int tcp_nodelay;///< Use TCP_NODELAY to
> > disable Nagle's algorithm if set to 1
> > +char *enhanced_codecs; ///< codec list in enhanced
> > rtmp
> > char username[50];
> > char password[50];
> > char auth_params[500];
> > @@ -336,6 +337,39 @@ static int gen_connect(URLContext *s, RTMPContext *rt)
> > ff_amf_write_field_name(, "app");
> > ff_amf_write_string2(, rt->app, rt->auth_params);
> >
> > +if (rt->enhanced_codecs) {
> > +uint32_t list_len = 0;
> > +char *fourcc_data = rt->enhanced_codecs;
> > +int fourcc_str_len = strlen(fourcc_data);
> > +
> > +// check the string, fourcc + ',' + ... + end fourcc correct
> > length should be (4+1)*n+4
> > +if ((fourcc_str_len + 1) % 5 != 0)
> > +return AVERROR(EINVAL);
>
> If we trigger this error, we definitely should tell the user what was
> wrong. 'Malformed rtmp_enhanched_codecs, should be of the form
> "fourcc[,fourcc..]"' or something like that? (Would it be better to use
> "frcc" or just "hvc1" or something else there, to show that it needs to be
> exactly a four char string for each element?)
Agreed
>
> > +
> > +list_len = (fourcc_str_len + 1) / 5;
> > +// write the fourCcList field name
> > +ff_amf_write_field_name(, "fourCcList");
> > +
> > +// write the fourcc array length
> > +ff_amf_write_array_start(, list_len);
> > +
> > +while(fourcc_data - rt->enhanced_codecs < fourcc_str_len) {
> > +unsigned char fourcc[5];
> > +switch (AV_RN32(fourcc_data)) {
> > +case MKTAG('h', 'v', 'c', '1'):
>
> This feels a bit convoluted to use AV_RN32 + MKTAG on data that is already
> just a string - just using strncmp(fourcc_data, "hvc1", 4) would work just
I want use strncmp at first, but i think strncmp will slower than
switch uint32_t value, so i chose use uint32_t. or should i use
strncmp?
> as well. That doesn't fit quite as neatly into a switch, but would be a
> more unwieldy if statement though.
>
> > +case MKTAG('a', 'v', '0', '1'):
> > +case MKTAG('v', 'p', '0', '9'):
> > +av_strlcpy(fourcc, fourcc_data, sizeof(fourcc));
> > +ff_amf_write_string(, fourcc);
> > +break;
> > +default:
>
> When this fails, the user definitely needs to know what was wrong, so we
> should print the string that didn't match the expectation. E.g.
> ("unsupported codec fourcc, %.*s", 4, fourcc_data) or something like that?
good suggestion.
>
> // Martin
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] avformat/rtmpproto: support enhanced rtmp
On Fri, 25 Aug 2023, Steven Liu wrote:
Add option named rtmp_enhanced_codec,
it would support hvc1,av01,vp09 now,
the fourcc is using Array of strings.
Signed-off-by: Steven Liu
---
doc/protocols.texi | 6 ++
libavformat/rtmpproto.c | 35 +++
2 files changed, 41 insertions(+)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index b3fad55591..bd2b25e502 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -896,6 +896,12 @@ be named, by prefixing the type with 'N' and specifying
the name before
the value (i.e. @code{NB:myFlag:1}). This option may be used multiple
times to construct arbitrary AMF sequences.
+@item rtmp_enhanced_codecs
+Specify the list of codecs the client advertises to support in an
+enhanced RTMP stream. This option should set a string like
@code{hvc1,av01,vp09}
+for multiple codecs, or @code{hvc1} for only one codec,
+set codec fourcc into fourCcLive property into Connect Command Message,
+
@item rtmp_flashver
Version of the Flash plugin used to run the SWF player. The default
is LNX 9,0,124,2. (When publishing, the default is FMLE/3.0 (compatible;
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index f0ef223f05..ea25454362 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -127,6 +127,7 @@ typedef struct RTMPContext {
int nb_streamid;///< The next stream id to return
on createStream calls
doubleduration; ///< Duration of the stream in
seconds as returned by the server (only valid if non-zero)
int tcp_nodelay;///< Use TCP_NODELAY to disable
Nagle's algorithm if set to 1
+char *enhanced_codecs; ///< codec list in enhanced rtmp
char username[50];
char password[50];
char auth_params[500];
@@ -336,6 +337,39 @@ static int gen_connect(URLContext *s, RTMPContext *rt)
ff_amf_write_field_name(, "app");
ff_amf_write_string2(, rt->app, rt->auth_params);
+if (rt->enhanced_codecs) {
+uint32_t list_len = 0;
+char *fourcc_data = rt->enhanced_codecs;
+int fourcc_str_len = strlen(fourcc_data);
+
+// check the string, fourcc + ',' + ... + end fourcc correct length
should be (4+1)*n+4
+if ((fourcc_str_len + 1) % 5 != 0)
+return AVERROR(EINVAL);
If we trigger this error, we definitely should tell the user what was
wrong. 'Malformed rtmp_enhanched_codecs, should be of the form
"fourcc[,fourcc..]"' or something like that? (Would it be better to use
"frcc" or just "hvc1" or something else there, to show that it needs to be
exactly a four char string for each element?)
+
+list_len = (fourcc_str_len + 1) / 5;
+// write the fourCcList field name
+ff_amf_write_field_name(, "fourCcList");
+
+// write the fourcc array length
+ff_amf_write_array_start(, list_len);
+
+while(fourcc_data - rt->enhanced_codecs < fourcc_str_len) {
+unsigned char fourcc[5];
+switch (AV_RN32(fourcc_data)) {
+case MKTAG('h', 'v', 'c', '1'):
This feels a bit convoluted to use AV_RN32 + MKTAG on data that is already
just a string - just using strncmp(fourcc_data, "hvc1", 4) would work just
as well. That doesn't fit quite as neatly into a switch, but would be a
more unwieldy if statement though.
+case MKTAG('a', 'v', '0', '1'):
+case MKTAG('v', 'p', '0', '9'):
+av_strlcpy(fourcc, fourcc_data, sizeof(fourcc));
+ff_amf_write_string(, fourcc);
+break;
+default:
When this fails, the user definitely needs to know what was wrong, so we
should print the string that didn't match the expectation. E.g.
("unsupported codec fourcc, %.*s", 4, fourcc_data) or something like that?
// Martin
___
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] Revert "avcodec/apedec: fix decoding 24bit insane files with recent versions"
On Fri, Aug 25, 2023 at 2:01 AM Michael Niedermayer wrote: > On Fri, Aug 25, 2023 at 01:37:27AM +0200, Paul B Mahol wrote: > > NAK > > > > Breaks decoding of another sample. > > please provide the sample > > if noone provides a sample, i will disregard this objection. > Also as a sidenote, iam in contact with Matt Ashland and he also > doesnt know what your commit was trying to fix > What to say, monkey see - monkey do. Just wasted too much time on running latest MAC converter software in virtualbox to confirm you break this ticket bellow with your patch set. https://trac.ffmpeg.org/ticket/8918 My patience is lowering by each new day and each new patch(es) from you. > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > If the United States is serious about tackling the national security > threats > related to an insecure 5G network, it needs to rethink the extent to which > it > values corporate profits and government espionage over security.-Bruce > Schneier > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 1/9] libavutil: add hwcontext_d3d12va and AV_PIX_FMT_D3D12
V6 major changes 1. the way d3dlibs created, adding a load function. Added dlclose in free function. 2. Simplified the public sync API by only keeping av_d3d12va_wait_idle. 3. Wrapping data->[0], data[1], data[2] into one single structure. >Subject: [PATCH v6 1/9] libavutil: add hwcontext_d3d12va and >AV_PIX_FMT_D3D12 > >From: Wu Jianhua > >Signed-off-by: Wu Jianhua >Signed-off-by: Tong Wu >--- > configure | 5 + > doc/APIchanges | 7 + > libavutil/Makefile | 3 + > libavutil/hwcontext.c | 4 + > libavutil/hwcontext.h | 1 + > libavutil/hwcontext_d3d12va.c | 693 + > libavutil/hwcontext_d3d12va.h | 155 ++ > libavutil/hwcontext_d3d12va_internal.h | 59 +++ > libavutil/hwcontext_internal.h | 1 + > libavutil/pixdesc.c| 4 + > libavutil/pixfmt.h | 7 + > libavutil/tests/hwdevice.c | 2 + > libavutil/version.h| 2 +- > 13 files changed, 942 insertions(+), 1 deletion(-) > create mode 100644 libavutil/hwcontext_d3d12va.c > create mode 100644 libavutil/hwcontext_d3d12va.h > create mode 100644 libavutil/hwcontext_d3d12va_internal.h > >diff --git a/configure b/configure >index 04bb9fe9dd..b74a668f87 100755 >--- a/configure >+++ b/configure >@@ -338,6 +338,7 @@ External library support: > --disable-cuda-llvm disable CUDA compilation using clang [autodetect] > --disable-cuvid disable Nvidia CUVID support [autodetect] > --disable-d3d11vadisable Microsoft Direct3D 11 video acceleration > code >[autodetect] >+ --disable-d3d12vadisable Microsoft Direct3D 12 video acceleration >code >[autodetect] > --disable-dxva2 disable Microsoft DirectX 9 video acceleration code >[autodetect] > --disable-ffnvcodec disable dynamically linked Nvidia code [autodetect] > --enable-libdrm enable DRM code (Linux) [no] >@@ -1926,6 +1927,7 @@ HWACCEL_AUTODETECT_LIBRARY_LIST=" > cuda_llvm > cuvid > d3d11va >+d3d12va > dxva2 > ffnvcodec > nvdec >@@ -3053,6 +3055,7 @@ crystalhd_deps="libcrystalhd_libcrystalhd_if_h" > cuda_deps="ffnvcodec" > cuvid_deps="ffnvcodec" > d3d11va_deps="dxva_h ID3D11VideoDecoder ID3D11VideoContext" >+d3d12va_deps="dxva_h ID3D12Device ID3D12VideoDecoder" > dxva2_deps="dxva2api_h DXVA2_ConfigPictureDecode ole32 user32" > ffnvcodec_deps_any="libdl LoadLibrary" > mediacodec_deps="android" >@@ -6546,6 +6549,8 @@ check_type "windows.h dxgi1_2.h" "IDXGIOutput1" > check_type "windows.h dxgi1_5.h" "IDXGIOutput5" > check_type "windows.h d3d11.h" "ID3D11VideoDecoder" > check_type "windows.h d3d11.h" "ID3D11VideoContext" >+check_type "windows.h d3d12.h" "ID3D12Device" >+check_type "windows.h d3d12video.h" "ID3D12VideoDecoder" > check_type "windows.h" "DPI_AWARENESS_CONTEXT" - >D_WIN32_WINNT=0x0A00 > check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode - >D_WIN32_WINNT=0x0602 > check_func_headers mfapi.h MFCreateAlignedMemoryBuffer -lmfplat >diff --git a/doc/APIchanges b/doc/APIchanges >index ad1efe708d..37ce29323d 100644 >--- a/doc/APIchanges >+++ b/doc/APIchanges >@@ -2,6 +2,13 @@ The last version increases of all libraries were on 2023-02- >09 > > API changes, most recent first: > >+2023-07-xx - xx - lavu 58.18.100 - pixfmt.h hwcontext.h >hwcontext_d3d12va.h >+ Add AV_HWDEVICE_TYPE_D3D12VA and AV_PIX_FMT_D3D12. >+ Add AVD3D12VADeviceContext, AVD3D12VASyncContext, AVD3D12VAFrame >and >+ AVD3D12VAFramesContext. >+ Add av_d3d12va_map_sw_to_hw_format, av_d3d12va_sync_context_alloc, >+ av_d3d12va_sync_context_free, av_d3d12va_wait_idle. >+ > 2023-08-18 - xx - lavu 58.17.100 - channel_layout.h > All AV_CHANNEL_LAYOUT_* macros are now compatible with C++ 17 and >older. > >diff --git a/libavutil/Makefile b/libavutil/Makefile >index 7828c94dc5..db318534eb 100644 >--- a/libavutil/Makefile >+++ b/libavutil/Makefile >@@ -41,6 +41,7 @@ HEADERS = adler32.h > \ > hwcontext.h \ > hwcontext_cuda.h \ > hwcontext_d3d11va.h \ >+ hwcontext_d3d12va.h \ > hwcontext_drm.h \ > hwcontext_dxva2.h \ > hwcontext_qsv.h \ >@@ -188,6 +189,7 @@ OBJS = adler32.o > \ > > OBJS-$(CONFIG_CUDA) += hwcontext_cuda.o > OBJS-$(CONFIG_D3D11VA) += hwcontext_d3d11va.o >+OBJS-$(CONFIG_D3D12VA) += hwcontext_d3d12va.o > OBJS-$(CONFIG_DXVA2)+= hwcontext_dxva2.o
[FFmpeg-devel] [PATCH v6 8/9] Changelog: D3D12VA hardware accelerated H264, HEVC, VP9, AV1, MPEG-2 and VC1 decoding
From: Wu Jianhua Signed-off-by: Wu Jianhua Signed-off-by: Tong Wu --- Changelog | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Changelog b/Changelog index c010e86159..bdac4cb034 100644 --- a/Changelog +++ b/Changelog @@ -30,7 +30,7 @@ version : - support for the P_SKIP hinting to speed up libx264 encoding - Support HEVC,VP9,AV1 codec in enhanced flv format - apsnr and asisdr audio filters - +- D3D12VA hardware accelerated H264, HEVC, VP9, AV1, MPEG-2 and VC1 decoding version 6.0: - Radiance HDR image support -- 2.41.0.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v6 9/9] avcodec/d3d12va_hevc: enable allow_profile_mismatch flag for d3d12va msp profile
Same as d3d11va, this flag enables main still picture profile for
d3d12va. User should add this flag when decoding main still picture
profile.
Signed-off-by: Tong Wu
---
libavcodec/d3d12va_hevc.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavcodec/d3d12va_hevc.c b/libavcodec/d3d12va_hevc.c
index 4f6640be2f..1894fddb79 100644
--- a/libavcodec/d3d12va_hevc.c
+++ b/libavcodec/d3d12va_hevc.c
@@ -181,8 +181,13 @@ static int d3d12va_hevc_decode_init(AVCodecContext *avctx)
break;
case FF_PROFILE_HEVC_MAIN_STILL_PICTURE:
-av_log(avctx, AV_LOG_ERROR, "D3D12 doesn't support
PROFILE_HEVC_MAIN_STILL_PICTURE!\n");
-return AVERROR(EINVAL);
+if (avctx->hwaccel_flags & AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH) {
+ctx->cfg.DecodeProfile = D3D12_VIDEO_DECODE_PROFILE_HEVC_MAIN;
+break;
+} else {
+av_log(avctx, AV_LOG_ERROR, "D3D12 doesn't support
PROFILE_HEVC_MAIN_STILL_PICTURE!\n");
+return AVERROR(EINVAL);
+}
case FF_PROFILE_HEVC_MAIN:
default:
--
2.41.0.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v6 7/9] avcodec: add D3D12VA hardware accelerated VC1 decoding
From: Wu Jianhua
The command below is how to enable d3d12va:
ffmpeg -hwaccel d3d12va -i input.mp4 output.mp4
Signed-off-by: Wu Jianhua
Signed-off-by: Tong Wu
---
configure | 3 +
libavcodec/Makefile | 1 +
libavcodec/d3d12va_vc1.c| 214
libavcodec/dxva2_internal.h | 4 +
libavcodec/dxva2_vc1.c | 11 +-
libavcodec/hwaccels.h | 2 +
libavcodec/vc1dec.c | 9 ++
7 files changed, 239 insertions(+), 5 deletions(-)
create mode 100644 libavcodec/d3d12va_vc1.c
diff --git a/configure b/configure
index fd950e0a46..41c6912583 100755
--- a/configure
+++ b/configure
@@ -3161,6 +3161,8 @@ vc1_d3d11va_hwaccel_deps="d3d11va"
vc1_d3d11va_hwaccel_select="vc1_decoder"
vc1_d3d11va2_hwaccel_deps="d3d11va"
vc1_d3d11va2_hwaccel_select="vc1_decoder"
+vc1_d3d12va_hwaccel_deps="d3d12va"
+vc1_d3d12va_hwaccel_select="vc1_decoder"
vc1_dxva2_hwaccel_deps="dxva2"
vc1_dxva2_hwaccel_select="vc1_decoder"
vc1_nvdec_hwaccel_deps="nvdec"
@@ -3191,6 +3193,7 @@ vp9_videotoolbox_hwaccel_deps="videotoolbox"
vp9_videotoolbox_hwaccel_select="vp9_decoder"
wmv3_d3d11va_hwaccel_select="vc1_d3d11va_hwaccel"
wmv3_d3d11va2_hwaccel_select="vc1_d3d11va2_hwaccel"
+wmv3_d3d12va_hwaccel_select="vc1_d3d12va_hwaccel"
wmv3_dxva2_hwaccel_select="vc1_dxva2_hwaccel"
wmv3_nvdec_hwaccel_select="vc1_nvdec_hwaccel"
wmv3_vaapi_hwaccel_select="vc1_vaapi_hwaccel"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 30928a4c1d..b1f7dde3da 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1035,6 +1035,7 @@ OBJS-$(CONFIG_MPEG4_VDPAU_HWACCEL)+= vdpau_mpeg4.o
OBJS-$(CONFIG_MPEG4_VIDEOTOOLBOX_HWACCEL) += videotoolbox.o
OBJS-$(CONFIG_VC1_D3D11VA_HWACCEL)+= dxva2_vc1.o
OBJS-$(CONFIG_VC1_DXVA2_HWACCEL) += dxva2_vc1.o
+OBJS-$(CONFIG_VC1_D3D12VA_HWACCEL)+= dxva2_vc1.o d3d12va_vc1.o
OBJS-$(CONFIG_VC1_NVDEC_HWACCEL) += nvdec_vc1.o
OBJS-$(CONFIG_VC1_QSV_HWACCEL)+= qsvdec.o
OBJS-$(CONFIG_VC1_VAAPI_HWACCEL) += vaapi_vc1.o
diff --git a/libavcodec/d3d12va_vc1.c b/libavcodec/d3d12va_vc1.c
new file mode 100644
index 00..73887db602
--- /dev/null
+++ b/libavcodec/d3d12va_vc1.c
@@ -0,0 +1,214 @@
+/*
+ * Direct3D12 WMV3/VC-1 HW acceleration
+ *
+ * copyright (c) 2022-2023 Wu Jianhua
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "config_components.h"
+#include "libavutil/avassert.h"
+#include "libavutil/hwcontext_d3d12va_internal.h"
+#include "mpegutils.h"
+#include "mpegvideodec.h"
+#include "vc1.h"
+#include "vc1data.h"
+#include "d3d12va_decode.h"
+#include "dxva2_internal.h"
+
+#define MAX_SLICES 1024
+#define INVALID_REF 0x
+
+#define REF_RESOURCE(index) if (index != INVALID_REF) { \
+ctx->ref_resources[index] = frames_hwctx->texture_infos[index].texture; \
+}
+
+typedef struct D3D12DecodePictureContext {
+DXVA_PictureParameters pp;
+unsigned slice_count;
+DXVA_SliceInfo slices[MAX_SLICES];
+const uint8_t *bitstream;
+unsigned bitstream_size;
+} D3D12DecodePictureContext;
+
+static int d3d12va_vc1_start_frame(AVCodecContext *avctx, av_unused const
uint8_t *buffer, av_unused uint32_t size)
+{
+const VC1Context *v = avctx->priv_data;
+D3D12VADecodeContext *ctx = D3D12VA_DECODE_CONTEXT(avctx);
+D3D12DecodePictureContext *ctx_pic =
v->s.current_picture_ptr->hwaccel_picture_private;
+
+if (!ctx)
+return -1;
+
+av_assert0(ctx_pic);
+
+ff_dxva2_vc1_fill_picture_parameters(avctx, (AVDXVAContext *)ctx,
_pic->pp);
+ctx_pic->pp.wDeblockedPictureIndex = INVALID_REF;
+
+ctx_pic->bitstream = NULL;
+ctx_pic->bitstream_size = 0;
+ctx_pic->slice_count= 0;
+
+return 0;
+}
+
+static int d3d12va_vc1_decode_slice(AVCodecContext *avctx, const uint8_t
*buffer, uint32_t size)
+{
+const VC1Context *v = avctx->priv_data;
+D3D12DecodePictureContext *ctx_pic =
v->s.current_picture_ptr->hwaccel_picture_private;
+
+if (ctx_pic->slice_count >= MAX_SLICES) {
+return AVERROR(ERANGE);
+}
+
+if (avctx->codec_id == AV_CODEC_ID_VC1 &&
+size >= 4 &&
[FFmpeg-devel] [PATCH v6 6/9] avcodec: add D3D12VA hardware accelerated MPEG-2 decoding
From: Wu Jianhua
The command below is how to enable d3d12va:
ffmpeg -hwaccel d3d12va -i input.mp4 output.mp4
Signed-off-by: Wu Jianhua
Signed-off-by: Tong Wu
---
configure | 2 +
libavcodec/Makefile | 1 +
libavcodec/d3d12va_mpeg2.c | 191
libavcodec/dxva2_internal.h | 6 ++
libavcodec/dxva2_mpeg2.c| 18 ++--
libavcodec/hwaccels.h | 1 +
libavcodec/mpeg12dec.c | 6 ++
7 files changed, 216 insertions(+), 9 deletions(-)
create mode 100644 libavcodec/d3d12va_mpeg2.c
diff --git a/configure b/configure
index 80e9e91b81..fd950e0a46 100755
--- a/configure
+++ b/configure
@@ -3135,6 +3135,8 @@ mpeg2_d3d11va_hwaccel_deps="d3d11va"
mpeg2_d3d11va_hwaccel_select="mpeg2video_decoder"
mpeg2_d3d11va2_hwaccel_deps="d3d11va"
mpeg2_d3d11va2_hwaccel_select="mpeg2video_decoder"
+mpeg2_d3d12va_hwaccel_deps="d3d12va"
+mpeg2_d3d12va_hwaccel_select="mpeg2video_decoder"
mpeg2_dxva2_hwaccel_deps="dxva2"
mpeg2_dxva2_hwaccel_select="mpeg2video_decoder"
mpeg2_nvdec_hwaccel_deps="nvdec"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index fb5ec2ee2d..30928a4c1d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1023,6 +1023,7 @@ OBJS-$(CONFIG_MPEG1_VDPAU_HWACCEL)+=
vdpau_mpeg12.o
OBJS-$(CONFIG_MPEG1_VIDEOTOOLBOX_HWACCEL) += videotoolbox.o
OBJS-$(CONFIG_MPEG2_D3D11VA_HWACCEL) += dxva2_mpeg2.o
OBJS-$(CONFIG_MPEG2_DXVA2_HWACCEL)+= dxva2_mpeg2.o
+OBJS-$(CONFIG_MPEG2_D3D12VA_HWACCEL) += dxva2_mpeg2.o d3d12va_mpeg2.o
OBJS-$(CONFIG_MPEG2_NVDEC_HWACCEL)+= nvdec_mpeg12.o
OBJS-$(CONFIG_MPEG2_QSV_HWACCEL) += qsvdec.o
OBJS-$(CONFIG_MPEG2_VAAPI_HWACCEL)+= vaapi_mpeg2.o
diff --git a/libavcodec/d3d12va_mpeg2.c b/libavcodec/d3d12va_mpeg2.c
new file mode 100644
index 00..fe3636d242
--- /dev/null
+++ b/libavcodec/d3d12va_mpeg2.c
@@ -0,0 +1,191 @@
+/*
+ * Direct3D12 MPEG-2 HW acceleration
+ *
+ * copyright (c) 2022-2023 Wu Jianhua
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "config_components.h"
+#include "libavutil/avassert.h"
+#include "libavutil/hwcontext_d3d12va_internal.h"
+#include "mpegutils.h"
+#include "mpegvideodec.h"
+#include "d3d12va_decode.h"
+#include "dxva2_internal.h"
+
+#define MAX_SLICES 1024
+#define INVALID_REF 0x
+
+#define REF_RESOURCE(index) if (index != INVALID_REF) { \
+ctx->ref_resources[index] = frames_hwctx->texture_infos[index].texture; \
+}
+
+typedef struct D3D12DecodePictureContext {
+DXVA_PictureParameters pp;
+DXVA_QmatrixDataqm;
+unsignedslice_count;
+DXVA_SliceInfo slices[MAX_SLICES];
+const uint8_t *bitstream;
+unsignedbitstream_size;
+} D3D12DecodePictureContext;
+
+static int d3d12va_mpeg2_start_frame(AVCodecContext *avctx, av_unused const
uint8_t *buffer, av_unused uint32_t size)
+{
+const MpegEncContext *s = avctx->priv_data;
+D3D12VADecodeContext *ctx = D3D12VA_DECODE_CONTEXT(avctx);
+D3D12DecodePictureContext *ctx_pic =
s->current_picture_ptr->hwaccel_picture_private;
+DXVA_QmatrixData *qm = _pic->qm;
+
+if (!ctx)
+return -1;
+
+av_assert0(ctx_pic);
+
+ff_dxva2_mpeg2_fill_picture_parameters(avctx, (AVDXVAContext *)ctx,
_pic->pp);
+ff_dxva2_mpeg2_fill_quantization_matrices(avctx, (AVDXVAContext *)ctx,
_pic->qm);
+
+// Post processing operations are not supported in D3D12 Video
+ctx_pic->pp.wDeblockedPictureIndex = INVALID_REF;
+
+ctx_pic->bitstream = NULL;
+ctx_pic->bitstream_size = 0;
+ctx_pic->slice_count= 0;
+
+return 0;
+}
+
+static int d3d12va_mpeg2_decode_slice(AVCodecContext *avctx, const uint8_t
*buffer, uint32_t size)
+{
+const MpegEncContext *s = avctx->priv_data;
+D3D12DecodePictureContext *ctx_pic =
s->current_picture_ptr->hwaccel_picture_private;
+
+int is_field = s->picture_structure != PICT_FRAME;
+
+if (ctx_pic->slice_count >= MAX_SLICES) {
+return AVERROR(ERANGE);
+}
+
+if (!ctx_pic->bitstream)
+ctx_pic->bitstream = buffer;
+ctx_pic->bitstream_size += size;
+
+ff_dxva2_mpeg2_fill_slice(avctx,
[FFmpeg-devel] [PATCH v6 5/9] avcodec: add D3D12VA hardware accelerated AV1 decoding
From: Wu Jianhua
The command below is how to enable d3d12va:
ffmpeg -hwaccel d3d12va -i input.mp4 output.mp4
Signed-off-by: Wu Jianhua
Signed-off-by: Tong Wu
---
configure | 2 +
libavcodec/Makefile | 1 +
libavcodec/av1dec.c | 10 ++
libavcodec/d3d12va_av1.c| 220
libavcodec/dxva2_av1.c | 5 +-
libavcodec/dxva2_internal.h | 4 +
libavcodec/hwaccels.h | 1 +
7 files changed, 241 insertions(+), 2 deletions(-)
create mode 100644 libavcodec/d3d12va_av1.c
diff --git a/configure b/configure
index 756be03af6..80e9e91b81 100755
--- a/configure
+++ b/configure
@@ -3069,6 +3069,8 @@ av1_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_AV1"
av1_d3d11va_hwaccel_select="av1_decoder"
av1_d3d11va2_hwaccel_deps="d3d11va DXVA_PicParams_AV1"
av1_d3d11va2_hwaccel_select="av1_decoder"
+av1_d3d12va_hwaccel_deps="d3d12va DXVA_PicParams_AV1"
+av1_d3d12va_hwaccel_select="av1_decoder"
av1_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_AV1"
av1_dxva2_hwaccel_select="av1_decoder"
av1_nvdec_hwaccel_deps="nvdec CUVIDAV1PICPARAMS"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 9ef49a8da5..fb5ec2ee2d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -992,6 +992,7 @@ OBJS-$(CONFIG_VULKAN) += vulkan.o
vulkan_video.o
OBJS-$(CONFIG_AV1_D3D11VA_HWACCEL)+= dxva2_av1.o
OBJS-$(CONFIG_AV1_DXVA2_HWACCEL) += dxva2_av1.o
+OBJS-$(CONFIG_AV1_D3D12VA_HWACCEL)+= dxva2_av1.o d3d12va_av1.o
OBJS-$(CONFIG_AV1_NVDEC_HWACCEL) += nvdec_av1.o
OBJS-$(CONFIG_AV1_VAAPI_HWACCEL) += vaapi_av1.o
OBJS-$(CONFIG_AV1_VDPAU_HWACCEL) += vdpau_av1.o
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index 03283ab064..96e2c8febb 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -449,6 +449,7 @@ static int get_pixel_format(AVCodecContext *avctx)
enum AVPixelFormat pix_fmt = AV_PIX_FMT_NONE;
#define HWACCEL_MAX (CONFIG_AV1_DXVA2_HWACCEL + \
CONFIG_AV1_D3D11VA_HWACCEL * 2 + \
+ CONFIG_AV1_D3D12VA_HWACCEL + \
CONFIG_AV1_NVDEC_HWACCEL + \
CONFIG_AV1_VAAPI_HWACCEL + \
CONFIG_AV1_VDPAU_HWACCEL + \
@@ -524,6 +525,9 @@ static int get_pixel_format(AVCodecContext *avctx)
*fmtp++ = AV_PIX_FMT_D3D11VA_VLD;
*fmtp++ = AV_PIX_FMT_D3D11;
#endif
+#if CONFIG_AV1_D3D12VA_HWACCEL
+*fmtp++ = AV_PIX_FMT_D3D12;
+#endif
#if CONFIG_AV1_NVDEC_HWACCEL
*fmtp++ = AV_PIX_FMT_CUDA;
#endif
@@ -545,6 +549,9 @@ static int get_pixel_format(AVCodecContext *avctx)
*fmtp++ = AV_PIX_FMT_D3D11VA_VLD;
*fmtp++ = AV_PIX_FMT_D3D11;
#endif
+#if CONFIG_AV1_D3D12VA_HWACCEL
+*fmtp++ = AV_PIX_FMT_D3D12;
+#endif
#if CONFIG_AV1_NVDEC_HWACCEL
*fmtp++ = AV_PIX_FMT_CUDA;
#endif
@@ -1534,6 +1541,9 @@ const FFCodec ff_av1_decoder = {
#if CONFIG_AV1_D3D11VA2_HWACCEL
HWACCEL_D3D11VA2(av1),
#endif
+#if CONFIG_AV1_D3D12VA_HWACCEL
+HWACCEL_D3D12VA(av1),
+#endif
#if CONFIG_AV1_NVDEC_HWACCEL
HWACCEL_NVDEC(av1),
#endif
diff --git a/libavcodec/d3d12va_av1.c b/libavcodec/d3d12va_av1.c
new file mode 100644
index 00..4476f5bd8a
--- /dev/null
+++ b/libavcodec/d3d12va_av1.c
@@ -0,0 +1,220 @@
+/*
+ * Direct3D 12 AV1 HW acceleration
+ *
+ * copyright (c) 2022-2023 Wu Jianhua
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "config_components.h"
+#include "libavutil/avassert.h"
+#include "libavutil/hwcontext_d3d12va_internal.h"
+#include "av1dec.h"
+#include "dxva2_internal.h"
+#include "d3d12va_decode.h"
+
+#define MAX_TILES 256
+
+typedef struct D3D12AV1DecodeContext {
+D3D12VADecodeContext ctx;
+uint8_t *bitstream_buffer;
+} D3D12AV1DecodeContext;
+
+#define D3D12_AV1_DECODE_CONTEXT(avctx) ((D3D12AV1DecodeContext
*)D3D12VA_DECODE_CONTEXT(avctx))
+
+typedef struct AV1DecodePictureContext {
+DXVA_PicParams_AV1 pp;
+unsignedtile_count;
+DXVA_Tile_AV1 tiles[MAX_TILES];
+uint8_t*bitstream;
+unsignedbitstream_size;
+} AV1DecodePictureContext;
+
+static int d3d12va_av1_start_frame(AVCodecContext *avctx,
[FFmpeg-devel] [PATCH v6 4/9] avcodec: add D3D12VA hardware accelerated VP9 decoding
From: Wu Jianhua
The command below is how to enable d3d12va:
ffmpeg -hwaccel d3d12va -i input.mp4 output.mp4
Signed-off-by: Wu Jianhua
Signed-off-by: Tong Wu
---
configure | 2 +
libavcodec/Makefile | 1 +
libavcodec/d3d12va_vp9.c| 176
libavcodec/dxva2_internal.h | 2 +
libavcodec/dxva2_vp9.c | 7 +-
libavcodec/hwaccels.h | 1 +
libavcodec/vp9.c| 7 ++
7 files changed, 193 insertions(+), 3 deletions(-)
create mode 100644 libavcodec/d3d12va_vp9.c
diff --git a/configure b/configure
index 64607a4d9a..756be03af6 100755
--- a/configure
+++ b/configure
@@ -3173,6 +3173,8 @@ vp9_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_VP9"
vp9_d3d11va_hwaccel_select="vp9_decoder"
vp9_d3d11va2_hwaccel_deps="d3d11va DXVA_PicParams_VP9"
vp9_d3d11va2_hwaccel_select="vp9_decoder"
+vp9_d3d12va_hwaccel_deps="d3d12va DXVA_PicParams_VP9"
+vp9_d3d12va_hwaccel_select="vp9_decoder"
vp9_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_VP9"
vp9_dxva2_hwaccel_select="vp9_decoder"
vp9_nvdec_hwaccel_deps="nvdec"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 033bb5d505..9ef49a8da5 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1041,6 +1041,7 @@ OBJS-$(CONFIG_VP8_NVDEC_HWACCEL) += nvdec_vp8.o
OBJS-$(CONFIG_VP8_VAAPI_HWACCEL) += vaapi_vp8.o
OBJS-$(CONFIG_VP9_D3D11VA_HWACCEL)+= dxva2_vp9.o
OBJS-$(CONFIG_VP9_DXVA2_HWACCEL) += dxva2_vp9.o
+OBJS-$(CONFIG_VP9_D3D12VA_HWACCEL)+= dxva2_vp9.o d3d12va_vp9.o
OBJS-$(CONFIG_VP9_NVDEC_HWACCEL) += nvdec_vp9.o
OBJS-$(CONFIG_VP9_VAAPI_HWACCEL) += vaapi_vp9.o
OBJS-$(CONFIG_VP9_VDPAU_HWACCEL) += vdpau_vp9.o
diff --git a/libavcodec/d3d12va_vp9.c b/libavcodec/d3d12va_vp9.c
new file mode 100644
index 00..6ff0c5400d
--- /dev/null
+++ b/libavcodec/d3d12va_vp9.c
@@ -0,0 +1,176 @@
+/*
+ * Direct3D 12 VP9 HW acceleration
+ *
+ * copyright (c) 2022-2023 Wu Jianhua
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "config_components.h"
+
+#include "libavutil/avassert.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/hwcontext_d3d12va_internal.h"
+
+#include "vp9shared.h"
+#include "dxva2_internal.h"
+#include "d3d12va_decode.h"
+
+typedef struct VP9DecodePictureContext {
+DXVA_PicParams_VP9pp;
+DXVA_Slice_VPx_Short slice;
+const uint8_t*bitstream;
+unsigned bitstream_size;
+} VP9DecodePictureContext;
+
+static void fill_slice_short(DXVA_Slice_VPx_Short *slice, unsigned position,
unsigned size)
+{
+memset(slice, 0, sizeof(*slice));
+slice->BSNALunitDataLocation = position;
+slice->SliceBytesInBuffer= size;
+slice->wBadSliceChopping = 0;
+}
+
+static int d3d12va_vp9_start_frame(AVCodecContext *avctx, av_unused const
uint8_t *buffer, av_unused uint32_t size)
+{
+const VP9SharedContext *h = avctx->priv_data;
+D3D12VADecodeContext *ctx = D3D12VA_DECODE_CONTEXT(avctx);
+VP9DecodePictureContext *ctx_pic =
h->frames[CUR_FRAME].hwaccel_picture_private;
+
+if (!ctx)
+return -1;
+
+av_assert0(ctx_pic);
+
+if (ff_dxva2_vp9_fill_picture_parameters(avctx, (AVDXVAContext *)ctx,
_pic->pp) < 0)
+return -1;
+
+ctx_pic->bitstream_size = 0;
+ctx_pic->bitstream = NULL;
+
+return 0;
+}
+
+static int d3d12va_vp9_decode_slice(AVCodecContext *avctx, const uint8_t
*buffer, uint32_t size)
+{
+const VP9SharedContext *h = avctx->priv_data;
+VP9DecodePictureContext *ctx_pic =
h->frames[CUR_FRAME].hwaccel_picture_private;
+unsigned position;
+
+if (!ctx_pic->bitstream)
+ctx_pic->bitstream = buffer;
+ctx_pic->bitstream_size += size;
+
+position = buffer - ctx_pic->bitstream;
+fill_slice_short(_pic->slice, position, size);
+
+return 0;
+}
+
+static int update_input_arguments(AVCodecContext *avctx,
D3D12_VIDEO_DECODE_INPUT_STREAM_ARGUMENTS *input_args, ID3D12Resource *buffer)
+{
+D3D12VADecodeContext *ctx = D3D12VA_DECODE_CONTEXT(avctx);
+AVHWFramesContext *frames_ctx = D3D12VA_FRAMES_CONTEXT(avctx);
+AVD3D12VAFramesContext *frames_hwctx = frames_ctx->hwctx;
+
+const VP9SharedContext
[FFmpeg-devel] [PATCH v6 3/9] avcodec: add D3D12VA hardware accelerated HEVC decoding
From: Wu Jianhua
The command below is how to enable d3d12va:
ffmpeg -hwaccel d3d12va -i input.mp4 output.mp4
Signed-off-by: Wu Jianhua
Signed-off-by: Tong Wu
---
configure | 2 +
libavcodec/Makefile | 1 +
libavcodec/d3d12va_hevc.c | 211
libavcodec/dxva2_hevc.c | 10 +-
libavcodec/dxva2_internal.h | 4 +
libavcodec/hevcdec.c| 10 ++
libavcodec/hwaccels.h | 1 +
7 files changed, 235 insertions(+), 4 deletions(-)
create mode 100644 libavcodec/d3d12va_hevc.c
diff --git a/configure b/configure
index 78511ca54f..64607a4d9a 100755
--- a/configure
+++ b/configure
@@ -3105,6 +3105,8 @@ hevc_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_HEVC"
hevc_d3d11va_hwaccel_select="hevc_decoder"
hevc_d3d11va2_hwaccel_deps="d3d11va DXVA_PicParams_HEVC"
hevc_d3d11va2_hwaccel_select="hevc_decoder"
+hevc_d3d12va_hwaccel_deps="d3d12va DXVA_PicParams_HEVC"
+hevc_d3d12va_hwaccel_select="hevc_decoder"
hevc_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_HEVC"
hevc_dxva2_hwaccel_select="hevc_decoder"
hevc_nvdec_hwaccel_deps="nvdec"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 8d45b02334..033bb5d505 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1009,6 +1009,7 @@ OBJS-$(CONFIG_H264_VIDEOTOOLBOX_HWACCEL) +=
videotoolbox.o
OBJS-$(CONFIG_H264_VULKAN_HWACCEL)+= vulkan_decode.o vulkan_h264.o
OBJS-$(CONFIG_HEVC_D3D11VA_HWACCEL) += dxva2_hevc.o
OBJS-$(CONFIG_HEVC_DXVA2_HWACCEL) += dxva2_hevc.o
+OBJS-$(CONFIG_HEVC_D3D12VA_HWACCEL) += dxva2_hevc.o d3d12va_hevc.o
OBJS-$(CONFIG_HEVC_NVDEC_HWACCEL) += nvdec_hevc.o
OBJS-$(CONFIG_HEVC_QSV_HWACCEL) += qsvdec.o
OBJS-$(CONFIG_HEVC_VAAPI_HWACCEL) += vaapi_hevc.o h265_profile_level.o
diff --git a/libavcodec/d3d12va_hevc.c b/libavcodec/d3d12va_hevc.c
new file mode 100644
index 00..4f6640be2f
--- /dev/null
+++ b/libavcodec/d3d12va_hevc.c
@@ -0,0 +1,211 @@
+/*
+ * Direct3D 12 HEVC HW acceleration
+ *
+ * copyright (c) 2022-2023 Wu Jianhua
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "config_components.h"
+
+#include "libavutil/avassert.h"
+#include "libavutil/hwcontext_d3d12va_internal.h"
+#include "hevc_data.h"
+#include "hevcdec.h"
+#include "dxva2_internal.h"
+#include "d3d12va_decode.h"
+#include
+
+#define MAX_SLICES 256
+
+typedef struct HEVCDecodePictureContext {
+DXVA_PicParams_HEVCpp;
+DXVA_Qmatrix_HEVC qm;
+unsigned slice_count;
+DXVA_Slice_HEVC_Short slice_short[MAX_SLICES];
+const uint8_t *bitstream;
+unsigned bitstream_size;
+} HEVCDecodePictureContext;
+
+static void fill_slice_short(DXVA_Slice_HEVC_Short *slice, unsigned position,
unsigned size)
+{
+memset(slice, 0, sizeof(*slice));
+slice->BSNALunitDataLocation = position;
+slice->SliceBytesInBuffer= size;
+slice->wBadSliceChopping = 0;
+}
+
+static int d3d12va_hevc_start_frame(AVCodecContext *avctx, av_unused const
uint8_t *buffer, av_unused uint32_t size)
+{
+const HEVCContext*h = avctx->priv_data;
+D3D12VADecodeContext *ctx = D3D12VA_DECODE_CONTEXT(avctx);
+HEVCDecodePictureContext *ctx_pic = h->ref->hwaccel_picture_private;
+
+if (!ctx)
+return -1;
+
+av_assert0(ctx_pic);
+
+ff_dxva2_hevc_fill_picture_parameters(avctx, (AVDXVAContext *)ctx,
_pic->pp);
+
+ff_dxva2_hevc_fill_scaling_lists(avctx, (AVDXVAContext *)ctx,
_pic->qm);
+
+ctx_pic->slice_count= 0;
+ctx_pic->bitstream_size = 0;
+ctx_pic->bitstream = NULL;
+
+return 0;
+}
+
+static int d3d12va_hevc_decode_slice(AVCodecContext *avctx, const uint8_t
*buffer, uint32_t size)
+{
+const HEVCContext*h = avctx->priv_data;
+const HEVCFrame *current_picture = h->ref;
+HEVCDecodePictureContext *ctx_pic =
current_picture->hwaccel_picture_private;
+unsigned position;
+
+if (ctx_pic->slice_count >= MAX_SLICES)
+return AVERROR(ERANGE);
+
+if (!ctx_pic->bitstream)
+ctx_pic->bitstream = buffer;
+ctx_pic->bitstream_size += size;
+
+position = buffer - ctx_pic->bitstream;
+
[FFmpeg-devel] [PATCH v6 2/9] avcodec: add D3D12VA hardware accelerated H264 decoding
From: Wu Jianhua
The implementation is based on:
https://learn.microsoft.com/en-us/windows/win32/medfound/direct3d-12-video-overview
With the Direct3D 12 video decoding support, we can render or process
the decoded images by the pixel shaders or compute shaders directly
without the extra copy overhead, which is beneficial especially if you
are trying to render or post-process a 4K or 8K video.
The command below is how to enable d3d12va:
ffmpeg -hwaccel d3d12va -i input.mp4 output.mp4
Signed-off-by: Wu Jianhua
Signed-off-by: Tong Wu
---
configure | 2 +
libavcodec/Makefile | 3 +
libavcodec/d3d11va.h| 3 -
libavcodec/d3d12va_decode.c | 522
libavcodec/d3d12va_decode.h | 176
libavcodec/d3d12va_h264.c | 210 +++
libavcodec/dxva2.c | 27 ++
libavcodec/dxva2.h | 3 -
libavcodec/dxva2_h264.c | 12 +-
libavcodec/dxva2_internal.h | 67 ++---
libavcodec/h264_slice.c | 4 +
libavcodec/h264dec.c| 3 +
libavcodec/hwaccels.h | 1 +
libavcodec/hwconfig.h | 2 +
14 files changed, 993 insertions(+), 42 deletions(-)
create mode 100644 libavcodec/d3d12va_decode.c
create mode 100644 libavcodec/d3d12va_decode.h
create mode 100644 libavcodec/d3d12va_h264.c
diff --git a/configure b/configure
index b74a668f87..78511ca54f 100755
--- a/configure
+++ b/configure
@@ -3087,6 +3087,8 @@ h264_d3d11va_hwaccel_deps="d3d11va"
h264_d3d11va_hwaccel_select="h264_decoder"
h264_d3d11va2_hwaccel_deps="d3d11va"
h264_d3d11va2_hwaccel_select="h264_decoder"
+h264_d3d12va_hwaccel_deps="d3d12va"
+h264_d3d12va_hwaccel_select="h264_decoder"
h264_dxva2_hwaccel_deps="dxva2"
h264_dxva2_hwaccel_select="h264_decoder"
h264_nvdec_hwaccel_deps="nvdec"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3c16b51462..8d45b02334 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -982,6 +982,7 @@ OBJS-$(CONFIG_ADPCM_ZORK_DECODER) += adpcm.o
adpcm_data.o
# hardware accelerators
OBJS-$(CONFIG_D3D11VA)+= dxva2.o
+OBJS-$(CONFIG_D3D12VA)+= dxva2.o d3d12va_decode.o
OBJS-$(CONFIG_DXVA2) += dxva2.o
OBJS-$(CONFIG_NVDEC) += nvdec.o
OBJS-$(CONFIG_VAAPI) += vaapi_decode.o
@@ -999,6 +1000,7 @@ OBJS-$(CONFIG_H263_VAAPI_HWACCEL) += vaapi_mpeg4.o
OBJS-$(CONFIG_H263_VIDEOTOOLBOX_HWACCEL) += videotoolbox.o
OBJS-$(CONFIG_H264_D3D11VA_HWACCEL) += dxva2_h264.o
OBJS-$(CONFIG_H264_DXVA2_HWACCEL) += dxva2_h264.o
+OBJS-$(CONFIG_H264_D3D12VA_HWACCEL) += dxva2_h264.o d3d12va_h264.o
OBJS-$(CONFIG_H264_NVDEC_HWACCEL) += nvdec_h264.o
OBJS-$(CONFIG_H264_QSV_HWACCEL) += qsvdec.o
OBJS-$(CONFIG_H264_VAAPI_HWACCEL) += vaapi_h264.o
@@ -1288,6 +1290,7 @@ SKIPHEADERS+= %_tablegen.h
\
SKIPHEADERS-$(CONFIG_AMF) += amfenc.h
SKIPHEADERS-$(CONFIG_D3D11VA) += d3d11va.h dxva2_internal.h
+SKIPHEADERS-$(CONFIG_D3D12VA) += d3d12va_decode.h
SKIPHEADERS-$(CONFIG_DXVA2)+= dxva2.h dxva2_internal.h
SKIPHEADERS-$(CONFIG_JNI) += ffjni.h
SKIPHEADERS-$(CONFIG_LCMS2)+= fflcms2.h
diff --git a/libavcodec/d3d11va.h b/libavcodec/d3d11va.h
index 6816b6c1e6..27f40e5519 100644
--- a/libavcodec/d3d11va.h
+++ b/libavcodec/d3d11va.h
@@ -45,9 +45,6 @@
* @{
*/
-#define FF_DXVA2_WORKAROUND_SCALING_LIST_ZIGZAG 1 ///< Work around for
Direct3D11 and old UVD/UVD+ ATI video cards
-#define FF_DXVA2_WORKAROUND_INTEL_CLEARVIDEO2 ///< Work around for
Direct3D11 and old Intel GPUs with ClearVideo interface
-
/**
* This structure is used to provides the necessary configurations and data
* to the Direct3D11 FFmpeg HWAccel implementation.
diff --git a/libavcodec/d3d12va_decode.c b/libavcodec/d3d12va_decode.c
new file mode 100644
index 00..b0a5b0987d
--- /dev/null
+++ b/libavcodec/d3d12va_decode.c
@@ -0,0 +1,522 @@
+/*
+ * Direct3D 12 HW acceleration video decoder
+ *
+ * copyright (c) 2022-2023 Wu Jianhua
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+#include
+
+#include
[FFmpeg-devel] [PATCH v6 1/9] libavutil: add hwcontext_d3d12va and AV_PIX_FMT_D3D12
From: Wu Jianhua Signed-off-by: Wu Jianhua Signed-off-by: Tong Wu --- configure | 5 + doc/APIchanges | 7 + libavutil/Makefile | 3 + libavutil/hwcontext.c | 4 + libavutil/hwcontext.h | 1 + libavutil/hwcontext_d3d12va.c | 693 + libavutil/hwcontext_d3d12va.h | 155 ++ libavutil/hwcontext_d3d12va_internal.h | 59 +++ libavutil/hwcontext_internal.h | 1 + libavutil/pixdesc.c| 4 + libavutil/pixfmt.h | 7 + libavutil/tests/hwdevice.c | 2 + libavutil/version.h| 2 +- 13 files changed, 942 insertions(+), 1 deletion(-) create mode 100644 libavutil/hwcontext_d3d12va.c create mode 100644 libavutil/hwcontext_d3d12va.h create mode 100644 libavutil/hwcontext_d3d12va_internal.h diff --git a/configure b/configure index 04bb9fe9dd..b74a668f87 100755 --- a/configure +++ b/configure @@ -338,6 +338,7 @@ External library support: --disable-cuda-llvm disable CUDA compilation using clang [autodetect] --disable-cuvid disable Nvidia CUVID support [autodetect] --disable-d3d11vadisable Microsoft Direct3D 11 video acceleration code [autodetect] + --disable-d3d12vadisable Microsoft Direct3D 12 video acceleration code [autodetect] --disable-dxva2 disable Microsoft DirectX 9 video acceleration code [autodetect] --disable-ffnvcodec disable dynamically linked Nvidia code [autodetect] --enable-libdrm enable DRM code (Linux) [no] @@ -1926,6 +1927,7 @@ HWACCEL_AUTODETECT_LIBRARY_LIST=" cuda_llvm cuvid d3d11va +d3d12va dxva2 ffnvcodec nvdec @@ -3053,6 +3055,7 @@ crystalhd_deps="libcrystalhd_libcrystalhd_if_h" cuda_deps="ffnvcodec" cuvid_deps="ffnvcodec" d3d11va_deps="dxva_h ID3D11VideoDecoder ID3D11VideoContext" +d3d12va_deps="dxva_h ID3D12Device ID3D12VideoDecoder" dxva2_deps="dxva2api_h DXVA2_ConfigPictureDecode ole32 user32" ffnvcodec_deps_any="libdl LoadLibrary" mediacodec_deps="android" @@ -6546,6 +6549,8 @@ check_type "windows.h dxgi1_2.h" "IDXGIOutput1" check_type "windows.h dxgi1_5.h" "IDXGIOutput5" check_type "windows.h d3d11.h" "ID3D11VideoDecoder" check_type "windows.h d3d11.h" "ID3D11VideoContext" +check_type "windows.h d3d12.h" "ID3D12Device" +check_type "windows.h d3d12video.h" "ID3D12VideoDecoder" check_type "windows.h" "DPI_AWARENESS_CONTEXT" -D_WIN32_WINNT=0x0A00 check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0602 check_func_headers mfapi.h MFCreateAlignedMemoryBuffer -lmfplat diff --git a/doc/APIchanges b/doc/APIchanges index ad1efe708d..37ce29323d 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -2,6 +2,13 @@ The last version increases of all libraries were on 2023-02-09 API changes, most recent first: +2023-07-xx - xx - lavu 58.18.100 - pixfmt.h hwcontext.h hwcontext_d3d12va.h + Add AV_HWDEVICE_TYPE_D3D12VA and AV_PIX_FMT_D3D12. + Add AVD3D12VADeviceContext, AVD3D12VASyncContext, AVD3D12VAFrame and + AVD3D12VAFramesContext. + Add av_d3d12va_map_sw_to_hw_format, av_d3d12va_sync_context_alloc, + av_d3d12va_sync_context_free, av_d3d12va_wait_idle. + 2023-08-18 - xx - lavu 58.17.100 - channel_layout.h All AV_CHANNEL_LAYOUT_* macros are now compatible with C++ 17 and older. diff --git a/libavutil/Makefile b/libavutil/Makefile index 7828c94dc5..db318534eb 100644 --- a/libavutil/Makefile +++ b/libavutil/Makefile @@ -41,6 +41,7 @@ HEADERS = adler32.h \ hwcontext.h \ hwcontext_cuda.h \ hwcontext_d3d11va.h \ + hwcontext_d3d12va.h \ hwcontext_drm.h \ hwcontext_dxva2.h \ hwcontext_qsv.h \ @@ -188,6 +189,7 @@ OBJS = adler32.o \ OBJS-$(CONFIG_CUDA) += hwcontext_cuda.o OBJS-$(CONFIG_D3D11VA) += hwcontext_d3d11va.o +OBJS-$(CONFIG_D3D12VA) += hwcontext_d3d12va.o OBJS-$(CONFIG_DXVA2)+= hwcontext_dxva2.o OBJS-$(CONFIG_LIBDRM) += hwcontext_drm.o OBJS-$(CONFIG_MACOS_KPERF) += macos_kperf.o @@ -211,6 +213,7 @@ SKIPHEADERS-$(HAVE_CUDA_H) += hwcontext_cuda.h SKIPHEADERS-$(CONFIG_CUDA) += hwcontext_cuda_internal.h \ cuda_check.h SKIPHEADERS-$(CONFIG_D3D11VA) += hwcontext_d3d11va.h +SKIPHEADERS-$(CONFIG_D3D12VA)
Re: [FFmpeg-devel] [PATCH 1/2] doc/developer: Reviews must be constructive
Vittorio Giovara (12023-08-25): > NAK > we shouldn't put extra burden on reviewers, nor guilt trap them into > suggesting an alternative approach It is hilarious, in a very sad way, that you prefer put extra burden on people who do things than on people who block them. -- Nicolas George ___ 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".
