Re: [FFmpeg-devel] [PATCH] avutil/pixfmt: fix AV_PIX_FMT_RGB8 description
On date Monday 2024-01-08 09:53:37 -0500, Jeffrey Knockel wrote:
> Previously the description was partially mistaken, explaining the format
> as RGB 3:3:2, (msb)2R 3G 3B(lsb). While the RGB 3:3:2 part is correct,
> the latter part should be: (msb)3R 3G 2B(lsb). The corresponding bit
> masks are red: 0xE0, green: 0x1C, blue: 0x03.
>
> Signed-off-by: Jeffrey Knockel
> ---
> libavutil/pixfmt.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> index 58f9ad28bd..9c87571f49 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -83,7 +83,7 @@ enum AVPixelFormat {
> AV_PIX_FMT_BGR8, ///< packed RGB 3:3:2, 8bpp, (msb)2B 3G 3R(lsb)
> AV_PIX_FMT_BGR4, ///< packed RGB 1:2:1 bitstream, 4bpp, (msb)1B 2G
> 1R(lsb), a byte contains two pixels, the first pixel in the byte is the one
> composed by the 4 msb bits
> AV_PIX_FMT_BGR4_BYTE, ///< packed RGB 1:2:1, 8bpp, (msb)1B 2G 1R(lsb)
> -AV_PIX_FMT_RGB8, ///< packed RGB 3:3:2, 8bpp, (msb)2R 3G 3B(lsb)
> +AV_PIX_FMT_RGB8, ///< packed RGB 3:3:2, 8bpp, (msb)3R 3G 2B(lsb)
This is not consistent with pixdesc definition:
[AV_PIX_FMT_RGB8] = {
.name = "rgb8",
.nb_components = 3,
.log2_chroma_w = 0,
.log2_chroma_h = 0,
.comp = {
{ 0, 1, 0, 6, 2 },/* R */
{ 0, 1, 0, 3, 3 },/* G */
{ 0, 1, 0, 0, 3 },/* B */
},
.flags = AV_PIX_FMT_FLAG_RGB,
},
so either the documentation or the pixdesc description is wrong.
Do you confirm "(msb)3R 3G 2B(lsb)" is the correct definition?
In this case pixdesc should be fixed accordingly.
Thanks.
___
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] libavformat/adxdec: remove erroneous whitespace
On date Thursday 2024-01-11 15:55:05 -0600, Marth64 wrote: > 25th anniversary of the Dreamcast this year. Will follow up with FATE test. > > Signed-off-by: Marth64 > --- > libavformat/adxdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/adxdec.c b/libavformat/adxdec.c > index b6bd3303a7..55eabceef0 100644 > --- a/libavformat/adxdec.c > +++ b/libavformat/adxdec.c > @@ -105,7 +105,7 @@ static int adx_read_header(AVFormatContext *s) > av_log(s, AV_LOG_ERROR, "Invalid extradata size.\n"); > return AVERROR_INVALIDDATA; > } > -channels = AV_RB8 (par->extradata + 7); > +channels = AV_RB8(par->extradata + 7); > par->sample_rate = AV_RB32(par->extradata + 8); Will apply, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fate/audio: add ADX demux and decode test
On date Thursday 2024-01-11 16:01:57 -0600, Marth64 wrote: > Necessary samples to fate-samples/adx : > https://ufile.io/f/v306q > > Samples are re-encodes of luckynight from FATE suite. > d3a67e1d21bbaa7afc8e3bd089545ad44685e0c7a4212a75f7d115b0b8d656eb > luckynight.adx > f994367773da8cadc5a41d7eab680a3f24685211d3564d8a806857cab47bdf25 > luckynight.pcm > > Signed-off-by: Marth64 > --- > tests/fate/audio.mak | 5 + > 1 file changed, 5 insertions(+) Not sure if this needs a fate upload to be committed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavutil/timecode: fix parameter order in documentation
On date Friday 2024-01-12 17:47:02 -0600, Marth64 wrote: > Signed-off-by: Marth64 > --- > libavutil/timecode.h | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) Will apply, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/codecs: -channel_layout -> should be -ch_layout
On date Friday 2024-01-12 17:51:26 -0600, Marth64 wrote:
> Signed-off-by: Marth64
> ---
> doc/codecs.texi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/codecs.texi b/doc/codecs.texi
> index 6bdeb664e7..ca8c08a59f 100644
> --- a/doc/codecs.texi
> +++ b/doc/codecs.texi
> @@ -766,7 +766,7 @@ Set rate-distortion optimal quantization.
> @item mv0_threshold @var{integer} (@emph{encoding,video})
> @item compression_level @var{integer} (@emph{encoding,audio,video})
> @item bits_per_raw_sample @var{integer}
> -@item channel_layout @var{integer} (@emph{decoding/encoding,audio})
> +@item ch_layout @var{integer} (@emph{decoding/encoding,audio})
> See @ref{channel layout syntax,,the Channel Layout section in the
> ffmpeg-utils(1) manual,ffmpeg-utils}
> for the required syntax.
This is not correct, this is referencing the deprecated channel_layout
API (which should be kept while we should document the new one), the
new option takes a string.
Check options_table.c.
___
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 4/4] doc/muxers/avi: apply misc changes
On date Wednesday 2024-01-10 15:58:42 -0600, Marth64 wrote: > LGTM Thanks, applied this and the other doc/muxers pending patches. ___ 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] avutil/eval: Use even better PRNG
On date Saturday 2024-01-13 04:51:06 +0100, Michael Niedermayer wrote:
> This is the 64bit version of Chris Doty-Humphreys SFC64
>
> Compared to the LCGs these produce much better quality numbers.
> Compared to LFGs this needs less state. (our LFG has 224 byte
> state for its 32bit version) this has 32byte state
> Also the initialization for our LFG is slower.
> This is also much faster than KISS or PCG.
>
> This commit replaces the broken LCG used before.
> (broken as it had only a period ~200M due to being put in a double)
>
> This changes the output from random() which is why libswresample.mak
> is updated, update was done using the command in libswresample.mak
>
> Signed-off-by: Michael Niedermayer
> ---
> libavutil/eval.c | 24 +++-
> libavutil/sfc64.h| 85 ++
> tests/fate/libswresample.mak | 208 +--
> tests/ref/fate/eval | 2 +-
> 4 files changed, 210 insertions(+), 109 deletions(-)
> create mode 100644 libavutil/sfc64.h
>
> diff --git a/libavutil/eval.c b/libavutil/eval.c
> index dc6b3697bc2..349015d4fa3 100644
> --- a/libavutil/eval.c
> +++ b/libavutil/eval.c
> @@ -35,6 +35,7 @@
> #include "internal.h"
> #include "log.h"
> #include "mathematics.h"
> +#include "sfc64.h"
> #include "time.h"
> #include "avstring.h"
> #include "timer.h"
> @@ -55,6 +56,7 @@ typedef struct Parser {
> void *log_ctx;
> #define VARS 10
> double *var;
> +FFSFC64 *prng_state;
> } Parser;
>
> static const AVClass eval_class = {
> @@ -173,6 +175,7 @@ struct AVExpr {
> } a;
> struct AVExpr *param[3];
> double *var;
> +FFSFC64 *prng_state;
> };
>
> static double etime(double v)
> @@ -231,8 +234,14 @@ static double eval_expr(Parser *p, AVExpr *e)
>
> #define COMPUTE_NEXT_RANDOM()\
> int idx = av_clip(eval_expr(p, e->param[0]), 0, VARS-1); \
> -uint64_t r = isnan(p->var[idx]) ? 0 : p->var[idx]; \
> -r = r * 1664525 + 1013904223;\
> +FFSFC64 *s = p->prng_state + idx;\
> +uint64_t r; \
> + \
> +if (!s->counter) { \
> +r = isnan(p->var[idx]) ? 0 : p->var[idx];\
> +ff_sfc64_init(s, r, r, r, 12); \
> +}\
> +r = ff_sfc64_get(s); \
> p->var[idx] = r; \
>
> case e_random: {
> @@ -329,7 +338,11 @@ static double eval_expr(Parser *p, AVExpr *e)
> case e_div: return e->value * (d2 ? (d / d2) : d * INFINITY);
> case e_add: return e->value * (d + d2);
> case e_last:return e->value * d2;
> -case e_st : return e->value * (p->var[av_clip(d, 0,
> VARS-1)]= d2);
> +case e_st : {
> +int index = av_clip(d, 0, VARS-1);
> +p->prng_state[index].counter = 0;
> +return e->value * (p->var[index]= d2);
> +}
> case e_hypot:return e->value * hypot(d, d2);
> case e_atan2:return e->value * atan2(d, d2);
> case e_bitand: return isnan(d) || isnan(d2) ? NAN : e->value
> * ((long int)d & (long int)d2);
> @@ -349,6 +362,7 @@ void av_expr_free(AVExpr *e)
> av_expr_free(e->param[1]);
> av_expr_free(e->param[2]);
> av_freep(&e->var);
> +av_freep(&e->prng_state);
> av_freep(&e);
> }
>
> @@ -736,7 +750,8 @@ int av_expr_parse(AVExpr **expr, const char *s,
> goto end;
> }
> e->var= av_mallocz(sizeof(double) *VARS);
> -if (!e->var) {
> +e->prng_state = av_mallocz(sizeof(*e->prng_state) *VARS);
> +if (!e->var || !e->prng_state) {
> ret = AVERROR(ENOMEM);
> goto end;
> }
> @@ -778,6 +793,7 @@ double av_expr_eval(AVExpr *e, const double
> *const_values, void *opaque)
> {
> Parser p = { 0 };
> p.var= e->var;
> +p.prng_state= e->prng_state;
>
> p.const_values = const_values;
> p.opaque = opaque;
> diff --git a/libavutil/sfc64.h b/libavutil/sfc64.h
> new file mode 100644
> index 000..05f1e84cc68
> --- /dev/null
> +++ b/libavutil/sfc64.h
> @@ -0,0 +1,85 @@
> +/*
> + * Copyright (c) 2024 Michael Niedermayer
> + *
> + * 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
Re: [FFmpeg-devel] [PATCH v3] libavformat: add RCWT closed caption muxer
On date Sunday 2024-01-07 16:24:07 +0100, Stefano Sabatini wrote: > On date Sunday 2024-01-07 09:07:01 -0600, Marth64 wrote: > > Thanks, long night. Should come together nicer now. > > > > Signed-off-by: Marth64 > > --- > > Changelog| 1 + > > doc/muxers.texi | 22 + > > libavformat/Makefile | 1 + > > libavformat/allformats.c | 1 + > > libavformat/rcwtenc.c| 202 +++ > > tests/fate/subtitles.mak | 3 + > > tests/ref/fate/sub-rcwt | 1 + > > 7 files changed, 231 insertions(+) > > create mode 100644 libavformat/rcwtenc.c > > create mode 100644 tests/ref/fate/sub-rcwt > > LGTM, I'll wait a few days to see if there are more comments before > pushing (if I forget please ping). Applied, thanks. (BTW for the future when updating a patch, generate the patch with git format-patch and attach it to the email, in order to avoid manual editing on the committer side). ___ 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] avutil/pixfmt: fix AV_PIX_FMT_RGB8 description
On 1/14/24 6:32 AM, Stefano Sabatini wrote:
> On date Monday 2024-01-08 09:53:37 -0500, Jeffrey Knockel wrote:
>> Previously the description was partially mistaken, explaining the format
>> as RGB 3:3:2, (msb)2R 3G 3B(lsb). While the RGB 3:3:2 part is correct,
>> the latter part should be: (msb)3R 3G 2B(lsb). The corresponding bit
>> masks are red: 0xE0, green: 0x1C, blue: 0x03.
>>
>> Signed-off-by: Jeffrey Knockel
>> ---
>> libavutil/pixfmt.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
>> index 58f9ad28bd..9c87571f49 100644
>> --- a/libavutil/pixfmt.h
>> +++ b/libavutil/pixfmt.h
>> @@ -83,7 +83,7 @@ enum AVPixelFormat {
>> AV_PIX_FMT_BGR8, ///< packed RGB 3:3:2, 8bpp, (msb)2B 3G 3R(lsb)
>> AV_PIX_FMT_BGR4, ///< packed RGB 1:2:1 bitstream, 4bpp, (msb)1B
>> 2G 1R(lsb), a byte contains two pixels, the first pixel in the byte is the
>> one composed by the 4 msb bits
>> AV_PIX_FMT_BGR4_BYTE, ///< packed RGB 1:2:1, 8bpp, (msb)1B 2G 1R(lsb)
>
>> -AV_PIX_FMT_RGB8, ///< packed RGB 3:3:2, 8bpp, (msb)2R 3G 3B(lsb)
>> +AV_PIX_FMT_RGB8, ///< packed RGB 3:3:2, 8bpp, (msb)3R 3G 2B(lsb)
>
> This is not consistent with pixdesc definition:
> [AV_PIX_FMT_RGB8] = {
> .name = "rgb8",
> .nb_components = 3,
> .log2_chroma_w = 0,
> .log2_chroma_h = 0,
> .comp = {
> { 0, 1, 0, 6, 2 },/* R */
> { 0, 1, 0, 3, 3 },/* G */
> { 0, 1, 0, 0, 3 },/* B */
> },
> .flags = AV_PIX_FMT_FLAG_RGB,
> },
>
> so either the documentation or the pixdesc description is wrong.
>
> Do you confirm "(msb)3R 3G 2B(lsb)" is the correct definition?
Yes, I created three solid-colored RGBA raw samples filled with either
#ffff, #00ff00ff, or #, and converted them using `ffmpeg ...
-pix_fmt rgba ... -pix_fmt rgb8 ...` and inspected the output. I also tested
with `ffmpeg ... -pix_fmt rgba ... -pix_fmt yuv420p ...` followed by `ffmpeg
... -pix_fmt yuv420p ... -pix_fmt rgb8 ...`. In these tests the outputs were
consistent with "(msb)3R 3G 2B(lsb)".
> In this case pixdesc should be fixed accordingly.
Got it, will send an updated patch!
Thanks,
Jeff
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avutil/pixfmt: fix AV_PIX_FMT_RGB8 description
Previously AV_PIX_FMT_RGB8 was documented as "RGB 3:3:2,
(msb)2R 3G 3B(lsb)". While the RGB 3:3:2 part is correct, the latter
part should be: (msb)3R 3G 2B(lsb). This commit also updates the
format's pixdesc description to be (msb)3R 3G 2B(lsb).
Signed-off-by: Jeffrey Knockel
---
libavutil/pixdesc.c | 6 +++---
libavutil/pixfmt.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 0db4167934..f6d4d01460 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -530,9 +530,9 @@ static const AVPixFmtDescriptor
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
.log2_chroma_w = 0,
.log2_chroma_h = 0,
.comp = {
-{ 0, 1, 0, 6, 2 },/* R */
-{ 0, 1, 0, 3, 3 },/* G */
-{ 0, 1, 0, 0, 3 },/* B */
+{ 0, 1, 0, 5, 3 },/* R */
+{ 0, 1, 0, 2, 3 },/* G */
+{ 0, 1, 0, 0, 2 },/* B */
},
.flags = AV_PIX_FMT_FLAG_RGB,
},
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 58f9ad28bd..9c87571f49 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -83,7 +83,7 @@ enum AVPixelFormat {
AV_PIX_FMT_BGR8, ///< packed RGB 3:3:2, 8bpp, (msb)2B 3G 3R(lsb)
AV_PIX_FMT_BGR4, ///< packed RGB 1:2:1 bitstream, 4bpp, (msb)1B 2G
1R(lsb), a byte contains two pixels, the first pixel in the byte is the one
composed by the 4 msb bits
AV_PIX_FMT_BGR4_BYTE, ///< packed RGB 1:2:1, 8bpp, (msb)1B 2G 1R(lsb)
-AV_PIX_FMT_RGB8, ///< packed RGB 3:3:2, 8bpp, (msb)2R 3G 3B(lsb)
+AV_PIX_FMT_RGB8, ///< packed RGB 3:3:2, 8bpp, (msb)3R 3G 2B(lsb)
AV_PIX_FMT_RGB4, ///< packed RGB 1:2:1 bitstream, 4bpp, (msb)1R 2G
1B(lsb), a byte contains two pixels, the first pixel in the byte is the one
composed by the 4 msb bits
AV_PIX_FMT_RGB4_BYTE, ///< packed RGB 1:2:1, 8bpp, (msb)1R 2G 1B(lsb)
AV_PIX_FMT_NV12, ///< planar YUV 4:2:0, 12bpp, 1 plane for Y and 1
plane for the UV components, which are interleaved (first byte U and the
following byte V)
--
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/6] doc/muxers: add avif
---
doc/muxers.texi | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 1636f16cab..0d163a1629 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -835,6 +835,33 @@ compatibility with software that only supports a single
audio stream in AVI
(see @ref{amerge,,the "amerge" section in the ffmpeg-filters
manual,ffmpeg-filters}).
@end table
+@section avif
+AV1 (Alliance for Open Media Video codec 1) image format muxer.
+
+This muxers stores images encoded using the AV1 codec.
+
+It accepts one or two video streams. In case two video streams are
+provided, the second one shall contain a single plane storing the
+alpha mask.
+
+In case more than one image is provided, the generated output is
+considered an animated AVIF and the number of loops can be specified
+with the @option{loop} option.
+
+This is based on the specification by Alliance for Open Media at url
+@url{https://aomediacodec.github.io/av1-avif}.
+
+@subsection Options
+@table @option
+@item loop @var{count}
+number of times to loop an animated AVIF, @code{0} specify an infinite
+loop, default is @code{0}
+
+@item movie_timescale @var{timescale}
+Set the timescale written in the movie header box (@code{mvhd}).
+Range is 1 to INT_MAX. Default is @code{1000}.
+@end table
+
@anchor{chromaprint}
@section chromaprint
@@ -2048,7 +2075,6 @@ If a PNG image is used, it must use the rgba pixel format
@anchor{image2}
@section image2
-
Image file muxer.
The image file muxer writes video frames to image files.
--
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 4/6] doc/muxers: add avm2
---
doc/muxers.texi | 5 +
1 file changed, 5 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 0d163a1629..77d1b2983f 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -862,6 +862,11 @@ Set the timescale written in the movie header box
(@code{mvhd}).
Range is 1 to INT_MAX. Default is @code{1000}.
@end table
+@section avm2
+ShockWave Flash (SWF) / ActionScript Virtual Machine 2 (AVM2) format muxer.
+
+It accepts one audio stream, one video stream, or both.
+
@anchor{chromaprint}
@section chromaprint
--
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 5/6] doc/muxers: document avs3, expand AVS acronyms
---
doc/muxers.texi | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 77d1b2983f..1caf41ee4a 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -49,10 +49,15 @@ aptX (Audio Processing Technology for Bluetooth)
aptX HD (Audio Processing Technology for Bluetooth) audio
@item avs2 @emph{video} (avs, avs2)
-AVS2-P2/IEEE1857.4 video.
+AVS2-P2 (Audio Video Standard - Second generation - Part 2) /
+IEEE 1857.4 video
+
+@item @avs3 @emph{video} (avs3)
+AVS3-P2 (Audio Video Standard - Third generation - Part 2) /
+IEEE 1857.10 video
@item cavsvideo @emph{video} (cavs)
-Chinese AVS (Audio Video Standard)
+Chinese AVS (Audio Video Standard - First generation)
@item codec2raw @emph{audio}
Codec 2 audio.
--
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 6/6] doc/muxers: add bit
---
doc/muxers.texi | 5 +
1 file changed, 5 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 1caf41ee4a..d1e80d6582 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -872,6 +872,11 @@ ShockWave Flash (SWF) / ActionScript Virtual Machine 2
(AVM2) format muxer.
It accepts one audio stream, one video stream, or both.
+@section bit
+G.729 (.bit) file format muxer.
+
+It accepts a single G.279 audio stream.
+
@anchor{chromaprint}
@section chromaprint
--
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 v3] libavformat: add RCWT closed caption muxer
Thank you, Stefano. I had thought I did , but next time I will also test applying the patch too on local : ) On Sun, Jan 14, 2024 at 08:16 Stefano Sabatini wrote: > On date Sunday 2024-01-07 16:24:07 +0100, Stefano Sabatini wrote: > > On date Sunday 2024-01-07 09:07:01 -0600, Marth64 wrote: > > > Thanks, long night. Should come together nicer now. > > > > > > Signed-off-by: Marth64 > > > --- > > > Changelog| 1 + > > > doc/muxers.texi | 22 + > > > libavformat/Makefile | 1 + > > > libavformat/allformats.c | 1 + > > > libavformat/rcwtenc.c| 202 +++ > > > tests/fate/subtitles.mak | 3 + > > > tests/ref/fate/sub-rcwt | 1 + > > > 7 files changed, 231 insertions(+) > > > create mode 100644 libavformat/rcwtenc.c > > > create mode 100644 tests/ref/fate/sub-rcwt > > > > > LGTM, I'll wait a few days to see if there are more comments before > > pushing (if I forget please ping). > > Applied, thanks. > > (BTW for the future when updating a patch, generate the patch with git > format-patch and attach it to the email, in order to avoid manual > editing on the committer side). > ___ 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] Hardware purchase request: AVX512-capable laptop
Jan 9, 2024, 19:57 by d...@lynne.ee: > Jan 3, 2024, 04:30 by d...@lynne.ee: > >> Jan 3, 2024, 04:04 by d...@lynne.ee: >> >>> Jan 3, 2024, 02:22 by jamr...@gmail.com: >>> On 1/2/2024 9:56 PM, Lynne wrote: > As some of you know, my laptop died nearly 2 years ago, and > I've been working on a desktop machine, which is currently a Zen 3. > AVX512 has become more popular in the meantime, with Zen 4 > and future AMD CPUs shipping with it, but currently, we have very > little AVX512. > In short, I'd like a machine which runs an AVX512-capable > AMD CPU, and as the world is opening up more and more, I'd > like for it to be portable. > > I've looked around a lot, but as Intel still has a firm monopoly, > the options are limited (7940H(S), 7945HX, 7845HX, 8945HS). > What I think I've settled for is an ASUS Vivobook Pro 15, with a > 7940HS CPU (the second least powerful Zen 4 mobile CPU), > 7940HS is the highest Ryzen 9 model from the 7040 series. Not sure where you got second least powerful from. https://en.wikipedia.org/wiki/List_of_AMD_Ryzen_processors#Phoenix_(7040_series,_Zen_4/RDNA3_based) >>> >>> Was reading Wikipedia, and thought it was a Zen 3, my mistake >>> (and AMD's mistake for making 4 versioning formats): >>> https://en.wikipedia.org/wiki/List_of_AMD_Ryzen_processors >>> >>> > currently trading for 1999.0 EUR on amazon.de. > > https://www.amazon.de/-/en/Vivobook-Display-R9-7940HS-Windows-Keyboard/dp/B0BRYTS8MR > > The other alternative I've found is a Lenovo Legion 7 Pro, but > it's more expensive at 2399 EUR (currently seems temporarily > discounted due to the holidays). > I see a Lenovo Yoga Pro 7 available for 1099 EUR. https://www.amazon.de/-/en/Lenovo-Display-Graphics-Blue-Green-Premium/dp/B0CGLPVQHK/ Same amount of RAM, screen resolution and storage, and a Ryzen 7. >>> >>> It's a good suggestion, but I have a better one, that's somewhat more >>> expensive, >>> but has a better screen, better build quality, and is cheaper than the >>> Vivobook: >>> >>> A Lenovo ThinkPad P14s Gen 4 with the following options: >>> - Windows 14 Home (if you don't pick Windows, the OLED display is not >>> available for no reason) >>> - 32Gb of RAM >>> - 1Tb "performance" SSD (it's 70 EUR more, but twice the size) >>> - 2880x1800 OLED monitor >>> - 4-cell battery (only 10 EUR more) >>> - English (EU) keyboard, without backlighting >>> >>> https://www.lenovo.com/de/de/configurator/cto/index.html?bundleId=21K9CTO1WWDE2 >>> >> >> Correction: link I pasted was for the P16s, not the P14s, this is the >> correct link: >> https://www.lenovo.com/de/de/configurator/cto/index.html?bundleId=21K5CTO1WWDE2 >> > > Ping. So far I have one approval from Michael. > Ping. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] doc/utils: fix atan2 parameter order
The C library function double atan2(double y, double x) takes y as the first
parameter and x as the second parameter.
Signed-off-by: Haixia Shi
---
doc/utils.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/utils.texi b/doc/utils.texi
index 0c4f146f4f..76e704fc3c 100644
--- a/doc/utils.texi
+++ b/doc/utils.texi
@@ -815,7 +815,7 @@ Compute arcsine of @var{x}.
@item atan(x)
Compute arctangent of @var{x}.
-@item atan2(x, y)
+@item atan2(y, x)
Compute principal value of the arc tangent of @var{y}/@var{x}.
@item between(x, min, max)
--
2.31.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/4] avcodec/mdec: DC reading for STRv1 is like STRv2
Hi aybe On Sat, Jan 13, 2024 at 02:28:52AM +, aybe aybe wrote: > Here are the two STR files I have used when writing this patch: > https://github.com/aybe/FFmpeg-PSX-STR-tests ok, i can confirm the version patch fixes these, i will apply it > Fanatics would probably say that 30 FPS for NTSC is wrong (i.e. should be > 29.97)... > However, as the reversed-engineered docs in jpsxdec mentions, it is sort of > impossible to figure out which value to snap to from how frames spans across > CD-ROM sectors. > The sector count per video frame always seem to juggle between two values, > e.g. 6 sectors, then 7 sectors, rinse/repeat. i.e. it's never constant. > > Also, as one can see in the various code samples online on writing a PSX > program that plays MDEC videos, it is the responsibility of the coder to > present the frames on screen. > i.e. there is not definitive way on how to do so, and even if there was, you > can be sure some folks did not play by the rules back then. > The only way to figure out how a movie was intended to be played is to > reverse engineer a game to see what values they did cram in. > In short, the computed frame rate is 99% good, not 100%. But for mere > mortals, they are unlikely to notice it at all. Well, with the subset of samples i have, i dont feel confident that i could write and test timestamping/fps. The docuemnt you linked says "Data is read from the disc one sector at a time at either 75 sectors per second (single speed) or 150 sectors per second (double speed). The video and audio are spaced out over these sectors so they can be delivered at the appropriate times." what i would suggest to try is: avpriv_set_pts_info(st, 64, 1, 150); (or 75 for single speed) and then set AVPacket->pts to the sector number you never set fps, leave it to libavformat to figure it out. can you try that ? (i assume you have many samples to easily check) > > As for the movies in the samples repository, they are corrupt and FFmpeg > fails at them, obviously. > I figured these ones were by checking them in a hex-editor but also by > loading them in https://github.com/m35/jpsxdec which has great > logging. > Not sure why these samples were corrupt in first instance, maybe it was > intentional for testing? I can't tell. Thats very strange, anyone remembers where these samples are from originally ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: 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 v2] avutil/pixfmt: fix AV_PIX_FMT_RGB8 description
On Sun, Jan 14, 2024 at 4:15 PM Jeffrey Knockel wrote:
>
> Previously AV_PIX_FMT_RGB8 was documented as "RGB 3:3:2,
> (msb)2R 3G 3B(lsb)". While the RGB 3:3:2 part is correct, the latter
> part should be: (msb)3R 3G 2B(lsb). This commit also updates the
> format's pixdesc description to be (msb)3R 3G 2B(lsb).
>
> Signed-off-by: Jeffrey Knockel
> ---
> libavutil/pixdesc.c | 6 +++---
> libavutil/pixfmt.h | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
> index 0db4167934..f6d4d01460 100644
> --- a/libavutil/pixdesc.c
> +++ b/libavutil/pixdesc.c
> @@ -530,9 +530,9 @@ static const AVPixFmtDescriptor
> av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
> .log2_chroma_w = 0,
> .log2_chroma_h = 0,
> .comp = {
> -{ 0, 1, 0, 6, 2 },/* R */
> -{ 0, 1, 0, 3, 3 },/* G */
> -{ 0, 1, 0, 0, 3 },/* B */
> +{ 0, 1, 0, 5, 3 },/* R */
> +{ 0, 1, 0, 2, 3 },/* G */
> +{ 0, 1, 0, 0, 2 },/* B */
> },
> .flags = AV_PIX_FMT_FLAG_RGB,
> },
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> index 58f9ad28bd..9c87571f49 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -83,7 +83,7 @@ enum AVPixelFormat {
> AV_PIX_FMT_BGR8, ///< packed RGB 3:3:2, 8bpp, (msb)2B 3G 3R(lsb)
> AV_PIX_FMT_BGR4, ///< packed RGB 1:2:1 bitstream, 4bpp, (msb)1B 2G
> 1R(lsb), a byte contains two pixels, the first pixel in the byte is the one
> composed by the 4 msb bits
> AV_PIX_FMT_BGR4_BYTE, ///< packed RGB 1:2:1, 8bpp, (msb)1B 2G 1R(lsb)
> -AV_PIX_FMT_RGB8, ///< packed RGB 3:3:2, 8bpp, (msb)2R 3G 3B(lsb)
> +AV_PIX_FMT_RGB8, ///< packed RGB 3:3:2, 8bpp, (msb)3R 3G 2B(lsb)
> AV_PIX_FMT_RGB4, ///< packed RGB 1:2:1 bitstream, 4bpp, (msb)1R 2G
> 1B(lsb), a byte contains two pixels, the first pixel in the byte is the one
> composed by the 4 msb bits
> AV_PIX_FMT_RGB4_BYTE, ///< packed RGB 1:2:1, 8bpp, (msb)1R 2G 1B(lsb)
> AV_PIX_FMT_NV12, ///< planar YUV 4:2:0, 12bpp, 1 plane for Y and 1
> plane for the UV components, which are interleaved (first byte U and the
> following byte V)
> --
> 2.34.1
LGTM.
Tested. Without this patch, the output of avutil av_read_image_line2()
is all wrong, with it applied it is correct.
All the best,
Dee
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 1/2] lavc/d3d12va: remove unused variables
From: Tong Wu
Signed-off-by: Tong Wu
---
libavcodec/d3d12va_av1.c| 18 +-
libavcodec/d3d12va_decode.c | 9 ++---
libavcodec/d3d12va_h264.c | 4
libavcodec/d3d12va_hevc.c | 5 -
libavcodec/d3d12va_vc1.c| 3 ---
libavcodec/d3d12va_vp9.c| 4
6 files changed, 7 insertions(+), 36 deletions(-)
diff --git a/libavcodec/d3d12va_av1.c b/libavcodec/d3d12va_av1.c
index 6a3543353f..5f96f7da04 100644
--- a/libavcodec/d3d12va_av1.c
+++ b/libavcodec/d3d12va_av1.c
@@ -108,11 +108,8 @@ static int d3d12va_av1_decode_slice(AVCodecContext *avctx,
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 AV1DecContext *h= avctx->priv_data;
-AV1DecodePictureContext *ctx_pic =
h->cur_frame.hwaccel_picture_private;
+const AV1DecContext *h = avctx->priv_data;
+AV1DecodePictureContext *ctx_pic = h->cur_frame.hwaccel_picture_private;
uint8_t *mapped_data;
D3D12_VIDEO_DECODE_FRAME_ARGUMENT *args =
&input_args->FrameArguments[input_args->NumFrameArguments++];
@@ -142,7 +139,6 @@ static int d3d12va_av1_end_frame(AVCodecContext *avctx)
{
int ret;
const AV1DecContext *h = avctx->priv_data;
-D3D12VADecodeContext*ctx = D3D12VA_DECODE_CONTEXT(avctx);
AV1DecodePictureContext *ctx_pic = h->cur_frame.hwaccel_picture_private;
if (ctx_pic->tiles <= 0 || ctx_pic->bitstream_size <= 0)
@@ -156,10 +152,8 @@ static int d3d12va_av1_end_frame(AVCodecContext *avctx)
static int d3d12va_av1_decode_init(AVCodecContext *avctx)
{
-const AV1DecContext *h = avctx->priv_data;
-D3D12VADecodeContext*ctx = D3D12VA_DECODE_CONTEXT(avctx);
-D3D12AV1DecodeContext *av1_ctx = D3D12_AV1_DECODE_CONTEXT(avctx);
-AV1DecodePictureContext *ctx_pic = h->cur_frame.hwaccel_picture_private;
+D3D12VADecodeContext *ctx = D3D12VA_DECODE_CONTEXT(avctx);
+D3D12AV1DecodeContext *av1_ctx = D3D12_AV1_DECODE_CONTEXT(avctx);
DXVA_PicParams_AV1 pp;
int ret;
@@ -186,9 +180,7 @@ static int d3d12va_av1_decode_init(AVCodecContext *avctx)
static int d3d12va_av1_decode_uninit(AVCodecContext *avctx)
{
-const AV1DecContext *h = avctx->priv_data;
-D3D12AV1DecodeContext *ctx = D3D12_AV1_DECODE_CONTEXT(avctx);
-AV1DecodePictureContext *ctx_pic = h->cur_frame.hwaccel_picture_private;
+D3D12AV1DecodeContext *ctx = D3D12_AV1_DECODE_CONTEXT(avctx);
if (ctx->bitstream_buffer)
av_freep(&ctx->bitstream_buffer);
diff --git a/libavcodec/d3d12va_decode.c b/libavcodec/d3d12va_decode.c
index c5c599675e..ae2f577e25 100644
--- a/libavcodec/d3d12va_decode.c
+++ b/libavcodec/d3d12va_decode.c
@@ -265,8 +265,7 @@ fail:
int ff_d3d12va_common_frame_params(AVCodecContext *avctx, AVBufferRef
*hw_frames_ctx)
{
-AVHWFramesContext *frames_ctx = (AVHWFramesContext
*)hw_frames_ctx->data;
-AVHWDeviceContext *device_ctx = frames_ctx->device_ctx;
+AVHWFramesContext *frames_ctx = (AVHWFramesContext *)hw_frames_ctx->data;
frames_ctx->format= AV_PIX_FMT_D3D12;
frames_ctx->sw_format = avctx->sw_pix_fmt == AV_PIX_FMT_YUV420P10 ?
AV_PIX_FMT_P010 : AV_PIX_FMT_NV12;
@@ -407,9 +406,7 @@ int ff_d3d12va_decode_uninit(AVCodecContext *avctx)
static inline int d3d12va_update_reference_frames_state(AVCodecContext *avctx,
D3D12_RESOURCE_BARRIER *barriers,
ID3D12Resource
*current_resource, int state_before, int state_end)
{
-D3D12VADecodeContext *ctx = D3D12VA_DECODE_CONTEXT(avctx);
-AVHWFramesContext *frames_ctx = D3D12VA_FRAMES_CONTEXT(avctx);
-AVD3D12VAFramesContext *frames_hwctx = frames_ctx->hwctx;
+D3D12VADecodeContext *ctx = D3D12VA_DECODE_CONTEXT(avctx);
int num_barrier = 0;
for (int i = 0; i < ctx->max_num_ref; i++) {
@@ -436,8 +433,6 @@ int ff_d3d12va_common_end_frame(AVCodecContext *avctx,
AVFrame *frame,
{
int ret;
D3D12VADecodeContext *ctx = D3D12VA_DECODE_CONTEXT(avctx);
-AVHWFramesContext *frames_ctx= D3D12VA_FRAMES_CONTEXT(avctx);
-AVD3D12VAFramesContext *frames_hwctx = frames_ctx->hwctx;
ID3D12Resource *buffer= NULL;
ID3D12CommandAllocator *command_allocator = NULL;
AVD3D12VAFrame *f = (AVD3D12VAFrame
*)frame->data[0];
diff --git a/libavcodec/d3d12va_h264.c b/libavcodec/d3d12va_h264.c
index 24e1c523fa..e89c90995c 100644
--- a/libavcodec/d3d12va_h264.c
+++ b/libavcodec/d3d12va_h264.c
@@ -104,10 +104,6 @@ static int d3d12va_h264_decode_slice(AVCodecContext
*avctx, const uint8_t *buffe
#d
[FFmpeg-devel] [PATCH v2 2/2] d3d12va_av1|h264|hevc|vc1|vp9: input void** for ID3D12Resource_Map
From: Tong Wu
Fixes -Wincompatible-pointer-types warnings.
Signed-off-by: Tong Wu
---
libavcodec/d3d12va_av1.c | 2 +-
libavcodec/d3d12va_h264.c | 2 +-
libavcodec/d3d12va_hevc.c | 2 +-
libavcodec/d3d12va_vc1.c | 2 +-
libavcodec/d3d12va_vp9.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/d3d12va_av1.c b/libavcodec/d3d12va_av1.c
index 5f96f7da04..05cebc3148 100644
--- a/libavcodec/d3d12va_av1.c
+++ b/libavcodec/d3d12va_av1.c
@@ -110,7 +110,7 @@ static int update_input_arguments(AVCodecContext *avctx,
D3D12_VIDEO_DECODE_INPU
{
const AV1DecContext *h = avctx->priv_data;
AV1DecodePictureContext *ctx_pic = h->cur_frame.hwaccel_picture_private;
-uint8_t *mapped_data;
+void *mapped_data;
D3D12_VIDEO_DECODE_FRAME_ARGUMENT *args =
&input_args->FrameArguments[input_args->NumFrameArguments++];
args->Type = D3D12_VIDEO_DECODE_ARGUMENT_TYPE_SLICE_CONTROL;
diff --git a/libavcodec/d3d12va_h264.c b/libavcodec/d3d12va_h264.c
index e89c90995c..b2fe2955c8 100644
--- a/libavcodec/d3d12va_h264.c
+++ b/libavcodec/d3d12va_h264.c
@@ -113,7 +113,7 @@ static int update_input_arguments(AVCodecContext *avctx,
D3D12_VIDEO_DECODE_INPU
DXVA_Slice_H264_Short *slice;
D3D12_VIDEO_DECODE_FRAME_ARGUMENT *args;
-if (FAILED(ID3D12Resource_Map(buffer, 0, NULL, &mapped_data))) {
+if (FAILED(ID3D12Resource_Map(buffer, 0, NULL, (void **)&mapped_data))) {
av_log(avctx, AV_LOG_ERROR, "Failed to map D3D12 Buffer resource!\n");
return AVERROR(EINVAL);
}
diff --git a/libavcodec/d3d12va_hevc.c b/libavcodec/d3d12va_hevc.c
index a6a3b802f9..ca345c845f 100644
--- a/libavcodec/d3d12va_hevc.c
+++ b/libavcodec/d3d12va_hevc.c
@@ -107,7 +107,7 @@ static int update_input_arguments(AVCodecContext *avctx,
D3D12_VIDEO_DECODE_INPU
DXVA_Slice_HEVC_Short *slice;
D3D12_VIDEO_DECODE_FRAME_ARGUMENT *args;
-if (FAILED(ID3D12Resource_Map(buffer, 0, NULL, &mapped_data))) {
+if (FAILED(ID3D12Resource_Map(buffer, 0, NULL, (void **)&mapped_data))) {
av_log(avctx, AV_LOG_ERROR, "Failed to map D3D12 Buffer resource!\n");
return AVERROR(EINVAL);
}
diff --git a/libavcodec/d3d12va_vc1.c b/libavcodec/d3d12va_vc1.c
index b39b03ab45..8d8834b1cc 100644
--- a/libavcodec/d3d12va_vc1.c
+++ b/libavcodec/d3d12va_vc1.c
@@ -105,7 +105,7 @@ static int update_input_arguments(AVCodecContext *avctx,
D3D12_VIDEO_DECODE_INPU
static const uint8_t start_code[] = { 0, 0, 1, 0x0d };
-if (FAILED(ID3D12Resource_Map(buffer, 0, NULL, &mapped_data))) {
+if (FAILED(ID3D12Resource_Map(buffer, 0, NULL, (void **)&mapped_data))) {
av_log(avctx, AV_LOG_ERROR, "Failed to map D3D12 Buffer resource!\n");
return AVERROR(EINVAL);
}
diff --git a/libavcodec/d3d12va_vp9.c b/libavcodec/d3d12va_vp9.c
index 5a1cb0187d..8c54c97f5b 100644
--- a/libavcodec/d3d12va_vp9.c
+++ b/libavcodec/d3d12va_vp9.c
@@ -88,7 +88,7 @@ static int update_input_arguments(AVCodecContext *avctx,
D3D12_VIDEO_DECODE_INPU
const VP9SharedContext *h = avctx->priv_data;
VP9DecodePictureContext *ctx_pic =
h->frames[CUR_FRAME].hwaccel_picture_private;
-uint8_t *mapped_data;
+void *mapped_data;
D3D12_VIDEO_DECODE_FRAME_ARGUMENT *args;
if (FAILED(ID3D12Resource_Map(buffer, 0, NULL, &mapped_data))) {
--
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".
Re: [FFmpeg-devel] [PATCH v3] libavformat: add RCWT closed caption muxer
On So, 2024-01-14 at 15:16 +0100, Stefano Sabatini wrote: > On date Sunday 2024-01-07 16:24:07 +0100, Stefano Sabatini wrote: > > On date Sunday 2024-01-07 09:07:01 -0600, Marth64 wrote: > > > Thanks, long night. Should come together nicer now. > > > > > > Signed-off-by: Marth64 > > > --- > > > Changelog | 1 + > > > doc/muxers.texi | 22 + > > > libavformat/Makefile | 1 + > > > libavformat/allformats.c | 1 + > > > libavformat/rcwtenc.c | 202 +++ > > > tests/fate/subtitles.mak | 3 + > > > tests/ref/fate/sub-rcwt | 1 + > > > 7 files changed, 231 insertions(+) > > > create mode 100644 libavformat/rcwtenc.c > > > create mode 100644 tests/ref/fate/sub-rcwt > > > > > LGTM, I'll wait a few days to see if there are more comments before > > pushing (if I forget please ping). > > Applied, thanks. > > (BTW for the future when updating a patch, generate the patch with git > format-patch and attach it to the email, in order to avoid manual > editing on the committer side). $ make fate-sub-rcwt KEEP=1 V=2 [...] reference file './tests/ref/fate/sub-rcwt' not found Thanks Haihao ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] libavformat: add RCWT closed caption muxer
Hello, seems this file didn't make it during merge. Patch coming very shortly. Thank you, On Sun, Jan 14, 2024 at 10:25 PM Xiang, Haihao wrote: > On So, 2024-01-14 at 15:16 +0100, Stefano Sabatini wrote: > > On date Sunday 2024-01-07 16:24:07 +0100, Stefano Sabatini wrote: > > > On date Sunday 2024-01-07 09:07:01 -0600, Marth64 wrote: > > > > Thanks, long night. Should come together nicer now. > > > > > > > > Signed-off-by: Marth64 > > > > --- > > > > Changelog| 1 + > > > > doc/muxers.texi | 22 + > > > > libavformat/Makefile | 1 + > > > > libavformat/allformats.c | 1 + > > > > libavformat/rcwtenc.c| 202 > +++ > > > > tests/fate/subtitles.mak | 3 + > > > > tests/ref/fate/sub-rcwt | 1 + > > > > 7 files changed, 231 insertions(+) > > > > create mode 100644 libavformat/rcwtenc.c > > > > create mode 100644 tests/ref/fate/sub-rcwt > > > > > > > > LGTM, I'll wait a few days to see if there are more comments before > > > pushing (if I forget please ping). > > > > Applied, thanks. > > > > (BTW for the future when updating a patch, generate the patch with git > > format-patch and attach it to the email, in order to avoid manual > > editing on the committer side). > > $ make fate-sub-rcwt KEEP=1 V=2 > [...] > reference file './tests/ref/fate/sub-rcwt' not found > > Thanks > Haihao > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] rcwtenc: add sub-rcwt fate test ref
Resolves the issue. Patch generated with git format-patch and validated to apply. I reget any inconvenience this may have caused. Respectfully, Signed-off-by: Marth64 --- tests/ref/fate/sub-rcwt | 1 + 1 file changed, 1 insertion(+) create mode 100644 tests/ref/fate/sub-rcwt diff --git a/tests/ref/fate/sub-rcwt b/tests/ref/fate/sub-rcwt new file mode 100644 index 00..722cbe1c5b --- /dev/null +++ b/tests/ref/fate/sub-rcwt @@ -0,0 +1 @@ +d86f179094a5752d68aa97d82cf887b0 -- 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] rcwtenc: add sub-rcwt fate test ref
On So, 2024-01-14 at 22:38 -0600, Marth64 wrote: > Resolves the issue. Patch generated with git format-patch and validated to > apply. > I reget any inconvenience this may have caused. Respectfully, > > Signed-off-by: Marth64 > --- > tests/ref/fate/sub-rcwt | 1 + > 1 file changed, 1 insertion(+) > create mode 100644 tests/ref/fate/sub-rcwt > > diff --git a/tests/ref/fate/sub-rcwt b/tests/ref/fate/sub-rcwt > new file mode 100644 > index 00..722cbe1c5b > --- /dev/null > +++ b/tests/ref/fate/sub-rcwt > @@ -0,0 +1 @@ > +d86f179094a5752d68aa97d82cf887b0 Thanks for your quick fix, it works well for me. BRs Haihao ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] rcwtenc: add sub-rcwt fate test ref
Great, thank you for the confirmation. On Sun, Jan 14, 2024 at 11:06 PM Xiang, Haihao wrote: > On So, 2024-01-14 at 22:38 -0600, Marth64 wrote: > > Resolves the issue. Patch generated with git format-patch and validated > to > > apply. > > I reget any inconvenience this may have caused. Respectfully, > > > > Signed-off-by: Marth64 > > --- > > tests/ref/fate/sub-rcwt | 1 + > > 1 file changed, 1 insertion(+) > > create mode 100644 tests/ref/fate/sub-rcwt > > > > diff --git a/tests/ref/fate/sub-rcwt b/tests/ref/fate/sub-rcwt > > new file mode 100644 > > index 00..722cbe1c5b > > --- /dev/null > > +++ b/tests/ref/fate/sub-rcwt > > @@ -0,0 +1 @@ > > +d86f179094a5752d68aa97d82cf887b0 > > Thanks for your quick fix, it works well for me. > > BRs > Haihao > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
