Re: [FFmpeg-devel] [PATCH, v3] avcodec/amfenc: increase precision of Sleep() on Windows
If there are no comments, I plan to merge this patch at the end of the week. I will update the title and description to match the current version of the patch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] libavutil split out
Hi On Thu, Oct 31, 2024 at 10:12:57AM +0100, Tomas Härdin wrote: > tor 2024-10-31 klockan 01:08 +0100 skrev Michael Niedermayer: [...] > > , well iam sure > > you see this doesnt work > > build ffmpeg first, theres no libmycodec, > > build libmycodec first, theres no libavutil > > now of course this can be worked around by building ffmpeg twice > > But this is not documented, not suggested, not tested and not > > considered > > > > of course myself spliting out libpostproc made me realize this issue. > > But > > its a much broader problem than libpostproc. For libpostproc i can > > just > > copy everything and remove all libavutil dependancies > > And even without that it builds and works fine and all but only > > because i had > > a prior build libavutil installed from before. > > Are you trying to make libpostproc into a standalone library in a > separate source tree? Why? Surely the build system can be improved to > only building it and libavutil if someone wants that iam also curious why, but several people asked for libpostproc to be removed from ffmpeg over the years. If the consensus is now, to keep it in ffmpeg iam perfectly ok with that. But id like to know which way it is :) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Whats the most studid thing your enemy could do ? Blow himself up Whats the most studid thing you could do ? Give up your rights and freedom because your enemy blew himself up. 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] fftools/ffplay: fix crash when vk renderer is null
On Thu, Oct 31, 2024 at 02:40:57PM +0100, Leandro Santiago wrote:
> When vulkan rendering is requested by the user and fails, ffplay should
> exit graciously instead of crash due to a null pointer deref.
>
> Signed-off-by: Leandro Santiago
> ---
> fftools/ffplay.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> index a596972769..56d0a36ca1 100644
> --- a/fftools/ffplay.c
> +++ b/fftools/ffplay.c
> @@ -2612,6 +2612,11 @@ static int create_hwaccel(AVBufferRef **device_ctx)
> if (type == AV_HWDEVICE_TYPE_NONE)
> return AVERROR(ENOTSUP);
> +if (!vk_renderer) {
> +av_log(NULL, AV_LOG_ERROR, "Vulkan renderer is not available\n");
there is something wrong with this patch
the "+" shouldnt be in teh 2nd column
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/amfenc: Color information update
Processing of transfer characteristic SMPTE2084 and 8-bit depth added on AMF
side and will appear in one of upcoming releases.
---
libavcodec/amfenc_av1.c | 13 -
libavcodec/amfenc_hevc.c | 13 -
2 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/libavcodec/amfenc_av1.c b/libavcodec/amfenc_av1.c
index b40d54f70c..fc28287a48 100644
--- a/libavcodec/amfenc_av1.c
+++ b/libavcodec/amfenc_av1.c
@@ -252,15 +252,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_COLOR_BIT_DEPTH, color_depth);
AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_COLOR_PROFILE, color_profile);
-if (color_depth == AMF_COLOR_BIT_DEPTH_8) {
-/// Color Transfer Characteristics (AMF matches ISO/IEC)
-AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_TRANSFER_CHARACTERISTIC,
AMF_COLOR_TRANSFER_CHARACTERISTIC_BT709);
-/// Color Primaries (AMF matches ISO/IEC)
-AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_COLOR_PRIMARIES, AMF_COLOR_PRIMARIES_BT709);
-} else {
-AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_TRANSFER_CHARACTERISTIC,
AMF_COLOR_TRANSFER_CHARACTERISTIC_SMPTE2084);
-AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_COLOR_PRIMARIES, AMF_COLOR_PRIMARIES_BT2020);
-}
+/// Color Transfer Characteristics (AMF matches ISO/IEC)
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_TRANSFER_CHARACTERISTIC, avctx->color_trc);
+/// Color Primaries (AMF matches ISO/IEC)
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_COLOR_PRIMARIES, avctx->color_primaries);
profile_level = avctx->level;
if (profile_level == AV_LEVEL_UNKNOWN) {
diff --git a/libavcodec/amfenc_hevc.c b/libavcodec/amfenc_hevc.c
index f9f6f8adb3..8ceaee0851 100644
--- a/libavcodec/amfenc_hevc.c
+++ b/libavcodec/amfenc_hevc.c
@@ -254,15 +254,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
color_depth = AMF_COLOR_BIT_DEPTH_10;
}
AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_COLOR_BIT_DEPTH, color_depth);
-if (color_depth == AMF_COLOR_BIT_DEPTH_8) {
-/// Color Transfer Characteristics (AMF matches ISO/IEC)
-AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_OUTPUT_TRANSFER_CHARACTERISTIC,
AMF_COLOR_TRANSFER_CHARACTERISTIC_BT709);
-/// Color Primaries (AMF matches ISO/IEC)
-AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_OUTPUT_COLOR_PRIMARIES, AMF_COLOR_PRIMARIES_BT709);
-} else {
-AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_OUTPUT_TRANSFER_CHARACTERISTIC,
AMF_COLOR_TRANSFER_CHARACTERISTIC_SMPTE2084);
-AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_OUTPUT_COLOR_PRIMARIES, AMF_COLOR_PRIMARIES_BT2020);
-}
+/// Color Transfer Characteristics (AMF matches ISO/IEC)
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_OUTPUT_TRANSFER_CHARACTERISTIC, avctx->color_trc);
+/// Color Primaries (AMF matches ISO/IEC)
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_OUTPUT_COLOR_PRIMARIES, avctx->color_primaries);
// Picture control properties
AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_NUM_GOPS_PER_IDR, ctx->gops_per_idr);
--
2.45.2.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] Patch to add interlaced HEVC decoding to HEVCDEC
On Wed, Oct 30, 2024 at 01:31:35PM -0500, Jose Santiago wrote:
> From d55b49766d5e0256685c4874568db002d3dd7889 Mon Sep 17 00:00:00 2001
> From: Jose Santiago
> Date: Wed, 30 Oct 2024 12:28:35 -0500
> Subject: [PATCH] [PATCH V3] Patch to add interlaced HEVC decoding to
> HEVCDEC
>
> ---
> libavcodec/hevc/hevcdec.c | 24 ++-
> libavcodec/hevc/hevcdec.h | 13 ++
> libavcodec/hevc/refs.c| 412 +-
> libavcodec/hevc/sei.c | 16 +-
> libavcodec/hevc/sei.h | 129 +++-
> 5 files changed, 569 insertions(+), 25 deletions(-)
>
> diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
> index 1ea8df0fa0..d7179bdcf7 100644
> --- a/libavcodec/hevc/hevcdec.c
> +++ b/libavcodec/hevc/hevcdec.c
> @@ -359,7 +359,18 @@ static void export_stream_params(HEVCContext *s,
> const HEVCSPS *sps)
> avctx->profile = sps->ptl.general_ptl.profile_idc;
> avctx->level = sps->ptl.general_ptl.level_idc;
>
> -ff_set_sar(avctx, sps->vui.common.sar);
> +// There are some streams in the wild that were encode field pitcures
> +//and set double height aspect ratio so that some players that
> do not
> +//support interlaced HEVC display the field pictures with
> double height.
> +// Since we are now combining the field pictures into a single
> interlaced
> +//frame, fix the sample aspect ratio to restore the correct
> shape for the
> +//reconstructed interlaced frames.
> +if
> (ff_hevc_sei_pict_struct_is_field_picture(s->sei.picture_timing.picture_struct)
> &&
> +sps->vui.common.sar.num == 1 && sps->vui.common.sar.den ==
> 2) {
this patch is corrupted by linebreaks, please check your word/line wrap settings
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
You can kill me, but you cannot change the truth.
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 3/7] swscale/output: add XV48 output support
On Tue, Oct 29, 2024 at 04:50:47PM -0300, James Almer wrote: > On 10/29/2024 4:29 PM, Michael Niedermayer wrote: > > On Tue, Oct 29, 2024 at 01:03:21PM +0100, Michael Niedermayer wrote: > > > On Fri, Oct 25, 2024 at 07:56:29PM -0300, James Almer wrote: > > > > On 10/25/2024 7:18 PM, Michael Niedermayer wrote: > > > > > On Wed, Oct 23, 2024 at 04:36:44PM -0300, James Almer wrote: > > > > > > Signed-off-by: James Almer > > > > > > --- > > > > > >libswscale/output.c | 37 > > > > > > +++- > > > > > >libswscale/utils.c | 4 +-- > > > > > >tests/ref/fate/filter-pixdesc-xv48be | 1 + > > > > > >tests/ref/fate/filter-pixdesc-xv48le | 1 + > > > > > >tests/ref/fate/filter-pixfmts-copy | 2 ++ > > > > > >tests/ref/fate/filter-pixfmts-crop | 2 ++ > > > > > >tests/ref/fate/filter-pixfmts-field | 2 ++ > > > > > >tests/ref/fate/filter-pixfmts-fieldorder | 2 ++ > > > > > >tests/ref/fate/filter-pixfmts-hflip | 2 ++ > > > > > >tests/ref/fate/filter-pixfmts-il | 2 ++ > > > > > >tests/ref/fate/filter-pixfmts-null | 2 ++ > > > > > >tests/ref/fate/filter-pixfmts-scale | 2 ++ > > > > > >tests/ref/fate/filter-pixfmts-transpose | 2 ++ > > > > > >tests/ref/fate/filter-pixfmts-vflip | 2 ++ > > > > > >14 files changed, 48 insertions(+), 15 deletions(-) > > > > > >create mode 100644 tests/ref/fate/filter-pixdesc-xv48be > > > > > >create mode 100644 tests/ref/fate/filter-pixdesc-xv48le > > > > > > > > > > didnt apply cleanly so no test but LGTM > > > > > > > > > > thx > > > > > > > > It was Niklas recent renaming patch. You can try a rebased version in > > > > > > > https://github.com/jamrial/FFmpeg/commits/pixdesc/ > > > > > > thanks, that helped, swscale patches seem turning stale within the 500ms > > > transit time to the ML > > > > > > the swscale changes in that branch look good > > > tests seems passing on mingw32/64 linux x86-32/64 and mips > > > > i had to leave before qemu arm tests finished and of course arm faild :) > > > > make fate-pixfmt-x2bgr10le fate-pixfmt-x2rgb10le -k > > TESTpixfmt-x2bgr10le > > --- src/tests/ref/fate/pixfmt-x2bgr10le 2024-10-29 20:26:42.011219228 > > +0100 > > +++ tests/data/fate/pixfmt-x2bgr10le2024-10-29 20:28:11.519912980 > > +0100 > > @@ -1,2 +1,2 @@ > > -028652e885aef68639341bbc8415be57 *tests/data/pixfmt/x2bgr10le.yuv > > +040ceb964e1401b964d72f97c44ca596 *tests/data/pixfmt/x2bgr10le.yuv > > 15206400 tests/data/pixfmt/x2bgr10le.yuv > > Test pixfmt-x2bgr10le failed. Look at tests/data/fate/pixfmt-x2bgr10le.err > > for details. > > make: *** [src/tests/Makefile:311: fate-pixfmt-x2bgr10le] Error 1 > > TESTpixfmt-x2rgb10le > > --- src/tests/ref/fate/pixfmt-x2rgb10le 2024-10-29 20:26:42.011219228 > > +0100 > > +++ tests/data/fate/pixfmt-x2rgb10le2024-10-29 20:28:12.371919593 > > +0100 > > @@ -1,2 +1,2 @@ > > -028652e885aef68639341bbc8415be57 *tests/data/pixfmt/x2rgb10le.yuv > > +040ceb964e1401b964d72f97c44ca596 *tests/data/pixfmt/x2rgb10le.yuv > > 15206400 tests/data/pixfmt/x2rgb10le.yuv > > Test pixfmt-x2rgb10le failed. Look at tests/data/fate/pixfmt-x2rgb10le.err > > for details. > > make: *** [src/tests/Makefile:311: fate-pixfmt-x2rgb10le] Error 1 > > > > thx > > That is a test from a patch i didn't push, so not a problem in git head at > least. > > Is that a BE arm machine? no > The only thing i can think about is the check in > swscale/output.c for AV_PIX_FMT_X2RGB10, which for that target would become > AV_PIX_FMT_X2RGB10BE, and thus not trigger with this test. > This is IMO wrong because the yuv2packed* pointers are in turn set for both > LE and BE. arm has some funny behavior with misaligned 32bit access that is IIRC, if you cast a uint8_t * to int * and it was not an address thats a multiple of 4 and derefernce you can get results that you dont expect IIRC. if that makes no sense then i dont know, but tell me and ill just retest thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The smallest minority on earth is the individual. Those who deny individual rights cannot claim to be defenders of minorities. - Ayn Rand signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavfi/vf_drawtext: fix double free when destroying font face
Ref https://trac.ffmpeg.org/ticket/11152
According to harfbuzz docs, hb_ft_font_set_funcs() does not need to be
called, as, quoted:
```
An #hb_font_t object created with hb_ft_font_create()
is preconfigured for FreeType font functions and does not
require this function to be used.
```
Using this function seems to cause memory management issues between
harfbuzz and freetype, and could be eliminated.
This commit also call hb_ft_font_changed() when the underlying FC_Face
changes size, as stated on hardbuzz:
```
HarfBuzz also provides a utility function called hb_ft_font_changed()
that you should call whenever you have altered the properties of your
underlying FT_Face, as well as a hb_ft_get_face() that you can call on
an hb_font_t font object to fetch its underlying FT_Face.
```
Finally, the execution order between hb_font_destroy() and
hb_buffer_destroy() is inverted to match the order of creation of
the respective objects.
Signed-off-by: Leandro Santiago
---
libavfilter/vf_drawtext.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index 2b0a21a4b4..cf99b4e59e 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -445,6 +445,7 @@ static int glyph_cmp(const void *key, const void *b)
static av_cold int set_fontsize(AVFilterContext *ctx, unsigned int
fontsize)
{
int err;
+int line;
DrawTextContext *s = ctx->priv;
if ((err = FT_Set_Pixel_Sizes(s->face, 0, fontsize))) {
@@ -453,6 +454,12 @@ static av_cold int set_fontsize(AVFilterContext
*ctx, unsigned int fontsize)
return AVERROR(EINVAL);
}
+// Whenever the underlying FT_Face changes, harfbuzz has to be
notified of the change.
+for (line = 0; line < s->line_count; line++) {
+ TextLine *cur_line = &s->lines[line];
+ hb_ft_font_changed(cur_line->hb_data.font);
+}
+
s->fontsize = fontsize;
return 0;
@@ -1365,15 +1372,17 @@ static int shape_text_hb(DrawTextContext *s,
HarfbuzzData* hb, const char* text,
if(!hb_buffer_allocation_successful(hb->buf)) {
return AVERROR(ENOMEM);
}
+
hb_buffer_set_direction(hb->buf, HB_DIRECTION_LTR);
hb_buffer_set_script(hb->buf, HB_SCRIPT_LATIN);
hb_buffer_set_language(hb->buf, hb_language_from_string("en", -1));
hb_buffer_guess_segment_properties(hb->buf);
-hb->font = hb_ft_font_create(s->face, NULL);
+
+hb->font = hb_ft_font_create_referenced(s->face);
if(hb->font == NULL) {
return AVERROR(ENOMEM);
}
-hb_ft_font_set_funcs(hb->font);
+
hb_buffer_add_utf8(hb->buf, text, textLen, 0, -1);
hb_shape(hb->font, hb->buf, NULL, 0);
hb->glyph_info = hb_buffer_get_glyph_infos(hb->buf, &hb->glyph_count);
@@ -1384,8 +1393,8 @@ static int shape_text_hb(DrawTextContext *s,
HarfbuzzData* hb, const char* text,
static void hb_destroy(HarfbuzzData *hb)
{
-hb_buffer_destroy(hb->buf);
hb_font_destroy(hb->font);
+hb_buffer_destroy(hb->buf);
hb->buf = NULL;
hb->font = NULL;
hb->glyph_info = NULL;
--
2.46.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V5] Patch to add interlaced HEVC decoding to HEVCDEC
From 6cbe272375c746905238020f861633562c8b465e Mon Sep 17 00:00:00 2001
From: Jose Santiago
Date: Thu, 31 Oct 2024 13:17:16 -0500
Subject: [PATCH V5] Patch to add interlaced HEVC decoding to HEVCDEC
This version fixes a memory leak and does some code cleanup.
---
libavcodec/hevc/hevcdec.c | 24 ++-
libavcodec/hevc/hevcdec.h | 13 ++
libavcodec/hevc/refs.c| 417 +-
libavcodec/hevc/sei.c | 16 +-
libavcodec/hevc/sei.h | 129 +++-
5 files changed, 574 insertions(+), 25 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index 1ea8df0fa0..d7179bdcf7 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@ -359,7 +359,18 @@ static void export_stream_params(HEVCContext *s, const
HEVCSPS *sps)
avctx->profile = sps->ptl.general_ptl.profile_idc;
avctx->level = sps->ptl.general_ptl.level_idc;
-ff_set_sar(avctx, sps->vui.common.sar);
+// There are some streams in the wild that were encode field pitcures
+//and set double height aspect ratio so that some players that do not
+//support interlaced HEVC display the field pictures with double
height.
+// Since we are now combining the field pictures into a single interlaced
+//frame, fix the sample aspect ratio to restore the correct shape for
the
+//reconstructed interlaced frames.
+if
(ff_hevc_sei_pict_struct_is_field_picture(s->sei.picture_timing.picture_struct)
&&
+sps->vui.common.sar.num == 1 && sps->vui.common.sar.den == 2) {
+ff_set_sar(avctx, (AVRational){1, 1});
+} else {
+ff_set_sar(avctx, sps->vui.common.sar);
+}
if (sps->vui.common.video_signal_type_present_flag)
avctx->color_range = sps->vui.common.video_full_range_flag ?
AVCOL_RANGE_JPEG
@@ -3821,6 +3832,7 @@ static int hevc_ref_frame(HEVCFrame *dst, const HEVCFrame
*src)
dst->rpl = ff_refstruct_ref(src->rpl);
dst->nb_rpl_elems = src->nb_rpl_elems;
+dst->sei_pic_struct = src->sei_pic_struct;
dst->poc= src->poc;
dst->ctb_count = src->ctb_count;
dst->flags = src->flags;
@@ -3851,6 +3863,8 @@ static av_cold int hevc_decode_free(AVCodecContext *avctx)
av_freep(&s->md5_ctx);
av_freep(&s->h274db);
+ff_hevc_output_frame_construction_ctx_unref(s);
+
ff_container_fifo_free(&s->output_fifo);
for (int layer = 0; layer < FF_ARRAY_ELEMS(s->layers); layer++) {
@@ -3895,6 +3909,11 @@ static av_cold int hevc_init_context(AVCodecContext
*avctx)
s->local_ctx[0].logctx = avctx;
s->local_ctx[0].common_cabac_state = &s->cabac;
+if (ff_hevc_output_frame_construction_ctx_alloc(s) != 0 ||
+!s->output_frame_construction_ctx) {
+return AVERROR(ENOMEM);
+}
+
s->output_fifo = ff_container_fifo_alloc_avframe(0);
if (!s->output_fifo)
return AVERROR(ENOMEM);
@@ -3949,6 +3968,8 @@ static int hevc_update_thread_context(AVCodecContext *dst,
}
}
+ff_hevc_output_frame_construction_ctx_replace(s, s0);
+
for (int i = 0; i < FF_ARRAY_ELEMS(s->ps.vps_list); i++)
ff_refstruct_replace(&s->ps.vps_list[i], s0->ps.vps_list[i]);
@@ -4012,6 +4033,7 @@ static int hevc_update_thread_context(AVCodecContext *dst,
s->sei.common.content_light= s0->sei.common.content_light;
s->sei.common.aom_film_grain = s0->sei.common.aom_film_grain;
s->sei.tdrdi = s0->sei.tdrdi;
+s->sei.picture_timing = s0->sei.picture_timing;
return 0;
}
diff --git a/libavcodec/hevc/hevcdec.h b/libavcodec/hevc/hevcdec.h
index 73b792c880..4ce764f287 100644
--- a/libavcodec/hevc/hevcdec.h
+++ b/libavcodec/hevc/hevcdec.h
@@ -369,6 +369,10 @@ typedef struct HEVCFrame {
int ctb_count;
int poc;
+// SEI Picture Timing Picture Structure Type.
+// HEVC_SEI_PicStructType.
+int sei_pic_struct;
+
const HEVCPPS *pps;///< RefStruct reference
RefPicListTab *rpl;///< RefStruct reference
int nb_rpl_elems;
@@ -484,6 +488,8 @@ typedef struct HEVCLayerContext {
struct FFRefStructPool *rpl_tab_pool;
} HEVCLayerContext;
+struct HEVCOutputFrameConstructionContext;
+
typedef struct HEVCContext {
const AVClass *c; // needed by private avoptions
AVCodecContext *avctx;
@@ -502,6 +508,9 @@ typedef struct HEVCContext {
/** 1 if the independent slice segment header was successfully parsed */
uint8_t slice_initialized;
+// Interlaced Frame Construction Context.
+struct HEVCOutputFrameConstructionContext *output_frame_construction_ctx;
///< RefStruct reference
+
struct ContainerFifo *output_fifo;
HEVCParamSets ps;
@@ -664,6 +673,10 @@ static av_always_inline int ff_hevc_nal_is_nonref(enum
HEVCNALUnitType type)
return 0;
}
+int ff_hevc_output_frame_construction_ctx_alloc(HEVCContex
Re: [FFmpeg-devel] [PATCH V6] Patch to add interlaced HEVC decoding to HEVCDEC
From 14b950ad54a6b4ba9274769328fc32dc29e6efae Mon Sep 17 00:00:00 2001
From: Jose Santiago
Date: Thu, 31 Oct 2024 13:38:57 -0500
Subject: [PATCH V6] Patch to add interlaced HEVC decoding to HEVCDEC
Fixes repeat field for non-interlaced frame pictures.
---
libavcodec/hevc/hevcdec.c | 24 ++-
libavcodec/hevc/hevcdec.h | 13 ++
libavcodec/hevc/refs.c| 417 +-
libavcodec/hevc/sei.c | 16 +-
libavcodec/hevc/sei.h | 129 +++-
5 files changed, 574 insertions(+), 25 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index 1ea8df0fa0..d7179bdcf7 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@ -359,7 +359,18 @@ static void export_stream_params(HEVCContext *s, const
HEVCSPS *sps)
avctx->profile = sps->ptl.general_ptl.profile_idc;
avctx->level = sps->ptl.general_ptl.level_idc;
-ff_set_sar(avctx, sps->vui.common.sar);
+// There are some streams in the wild that were encode field pitcures
+//and set double height aspect ratio so that some players that do not
+//support interlaced HEVC display the field pictures with double
height.
+// Since we are now combining the field pictures into a single interlaced
+//frame, fix the sample aspect ratio to restore the correct shape for
the
+//reconstructed interlaced frames.
+if
(ff_hevc_sei_pict_struct_is_field_picture(s->sei.picture_timing.picture_struct)
&&
+sps->vui.common.sar.num == 1 && sps->vui.common.sar.den == 2) {
+ff_set_sar(avctx, (AVRational){1, 1});
+} else {
+ff_set_sar(avctx, sps->vui.common.sar);
+}
if (sps->vui.common.video_signal_type_present_flag)
avctx->color_range = sps->vui.common.video_full_range_flag ?
AVCOL_RANGE_JPEG
@@ -3821,6 +3832,7 @@ static int hevc_ref_frame(HEVCFrame *dst, const HEVCFrame
*src)
dst->rpl = ff_refstruct_ref(src->rpl);
dst->nb_rpl_elems = src->nb_rpl_elems;
+dst->sei_pic_struct = src->sei_pic_struct;
dst->poc= src->poc;
dst->ctb_count = src->ctb_count;
dst->flags = src->flags;
@@ -3851,6 +3863,8 @@ static av_cold int hevc_decode_free(AVCodecContext *avctx)
av_freep(&s->md5_ctx);
av_freep(&s->h274db);
+ff_hevc_output_frame_construction_ctx_unref(s);
+
ff_container_fifo_free(&s->output_fifo);
for (int layer = 0; layer < FF_ARRAY_ELEMS(s->layers); layer++) {
@@ -3895,6 +3909,11 @@ static av_cold int hevc_init_context(AVCodecContext
*avctx)
s->local_ctx[0].logctx = avctx;
s->local_ctx[0].common_cabac_state = &s->cabac;
+if (ff_hevc_output_frame_construction_ctx_alloc(s) != 0 ||
+!s->output_frame_construction_ctx) {
+return AVERROR(ENOMEM);
+}
+
s->output_fifo = ff_container_fifo_alloc_avframe(0);
if (!s->output_fifo)
return AVERROR(ENOMEM);
@@ -3949,6 +3968,8 @@ static int hevc_update_thread_context(AVCodecContext *dst,
}
}
+ff_hevc_output_frame_construction_ctx_replace(s, s0);
+
for (int i = 0; i < FF_ARRAY_ELEMS(s->ps.vps_list); i++)
ff_refstruct_replace(&s->ps.vps_list[i], s0->ps.vps_list[i]);
@@ -4012,6 +4033,7 @@ static int hevc_update_thread_context(AVCodecContext *dst,
s->sei.common.content_light= s0->sei.common.content_light;
s->sei.common.aom_film_grain = s0->sei.common.aom_film_grain;
s->sei.tdrdi = s0->sei.tdrdi;
+s->sei.picture_timing = s0->sei.picture_timing;
return 0;
}
diff --git a/libavcodec/hevc/hevcdec.h b/libavcodec/hevc/hevcdec.h
index 73b792c880..4ce764f287 100644
--- a/libavcodec/hevc/hevcdec.h
+++ b/libavcodec/hevc/hevcdec.h
@@ -369,6 +369,10 @@ typedef struct HEVCFrame {
int ctb_count;
int poc;
+// SEI Picture Timing Picture Structure Type.
+// HEVC_SEI_PicStructType.
+int sei_pic_struct;
+
const HEVCPPS *pps;///< RefStruct reference
RefPicListTab *rpl;///< RefStruct reference
int nb_rpl_elems;
@@ -484,6 +488,8 @@ typedef struct HEVCLayerContext {
struct FFRefStructPool *rpl_tab_pool;
} HEVCLayerContext;
+struct HEVCOutputFrameConstructionContext;
+
typedef struct HEVCContext {
const AVClass *c; // needed by private avoptions
AVCodecContext *avctx;
@@ -502,6 +508,9 @@ typedef struct HEVCContext {
/** 1 if the independent slice segment header was successfully parsed */
uint8_t slice_initialized;
+// Interlaced Frame Construction Context.
+struct HEVCOutputFrameConstructionContext *output_frame_construction_ctx;
///< RefStruct reference
+
struct ContainerFifo *output_fifo;
HEVCParamSets ps;
@@ -664,6 +673,10 @@ static av_always_inline int ff_hevc_nal_is_nonref(enum
HEVCNALUnitType type)
return 0;
}
+int ff_hevc_output_frame_construction_ctx_alloc(HEVCContext *s);
Re: [FFmpeg-devel] [PATCH 1/2] avutil/channel_layout: add Binaural channels and layout
On Sun, 27 Oct 2024, James Almer wrote:
Signed-off-by: James Almer
---
doc/utils.texi| 2 ++
libavutil/channel_layout.c| 3 +++
libavutil/channel_layout.h| 7 +++
tests/ref/fate/channel_layout | 1 +
4 files changed, 13 insertions(+)
diff --git a/doc/utils.texi b/doc/utils.texi
index 9968725d2a..eb5ccc8355 100644
--- a/doc/utils.texi
+++ b/doc/utils.texi
@@ -733,6 +733,8 @@ FL+FR+FC+LFE+BL+BR+SL+SR+TFL+TFR+TBC+LFE2
FL+FR+FC+LFE+BL+BR+FLC+FRC+SL+SR+TFL+TFR+TBL+TBR
@item hexadecagonal
FL+FR+FC+BL+BR+BC+SL+SR+WL+WR+TBL+TBR+TBC+TFC+TFL+TFR
+@item binaural
+BIL+BIR
@item downmix
DL+DR
@item 22.2
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 2d6963b6df..dd97e167c7 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -79,6 +79,8 @@ static const struct channel_name channel_names[] = {
[AV_CHAN_SIDE_SURROUND_RIGHT ] = { "SSR", "side surround right" },
[AV_CHAN_TOP_SURROUND_LEFT] = { "TTL", "top surround left" },
[AV_CHAN_TOP_SURROUND_RIGHT ] = { "TTR", "top surround right"},
+[AV_CHAN_BINAURAL_LEFT] = { "BIL", "binaural left" },
+[AV_CHAN_BINAURAL_RIGHT ] = { "BIR", "binaural right"},
};
void av_channel_name_bprint(AVBPrint *bp, enum AVChannel channel_id)
@@ -220,6 +222,7 @@ static const struct channel_layout_name
channel_layout_map[] = {
{ "7.2.3", AV_CHANNEL_LAYOUT_7POINT2POINT3 },
{ "9.1.4", AV_CHANNEL_LAYOUT_9POINT1POINT4_BACK },
{ "hexadecagonal", AV_CHANNEL_LAYOUT_HEXADECAGONAL },
+{ "binaural", AV_CHANNEL_LAYOUT_BINAURAL},
{ "downmix",AV_CHANNEL_LAYOUT_STEREO_DOWNMIX, },
{ "22.2", AV_CHANNEL_LAYOUT_22POINT2, },
};
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index 3a96c2d9b8..23fbc90606 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -84,6 +84,9 @@ enum AVChannel {
AV_CHAN_TOP_SURROUND_LEFT, ///< +110 degrees, Lvs, TpLS
AV_CHAN_TOP_SURROUND_RIGHT, ///< -110 degrees, Rvs, TpRS
+AV_CHAN_BINAURAL_LEFT = 61,
+AV_CHAN_BINAURAL_RIGHT,
Why 61 instead of simply continuing the enum?
Thanks,
Marton
___
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] avutil/channel_layout: add Binaural channels and layout
On 10/31/2024 3:53 PM, Marton Balint wrote:
On Sun, 27 Oct 2024, James Almer wrote:
Signed-off-by: James Almer
---
doc/utils.texi | 2 ++
libavutil/channel_layout.c | 3 +++
libavutil/channel_layout.h | 7 +++
tests/ref/fate/channel_layout | 1 +
4 files changed, 13 insertions(+)
diff --git a/doc/utils.texi b/doc/utils.texi
index 9968725d2a..eb5ccc8355 100644
--- a/doc/utils.texi
+++ b/doc/utils.texi
@@ -733,6 +733,8 @@ FL+FR+FC+LFE+BL+BR+SL+SR+TFL+TFR+TBC+LFE2
FL+FR+FC+LFE+BL+BR+FLC+FRC+SL+SR+TFL+TFR+TBL+TBR
@item hexadecagonal
FL+FR+FC+BL+BR+BC+SL+SR+WL+WR+TBL+TBR+TBC+TFC+TFL+TFR
+@item binaural
+BIL+BIR
@item downmix
DL+DR
@item 22.2
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 2d6963b6df..dd97e167c7 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -79,6 +79,8 @@ static const struct channel_name channel_names[] = {
[AV_CHAN_SIDE_SURROUND_RIGHT ] = { "SSR", "side surround
right" },
[AV_CHAN_TOP_SURROUND_LEFT ] = { "TTL", "top surround
left" },
[AV_CHAN_TOP_SURROUND_RIGHT ] = { "TTR", "top surround
right" },
+ [AV_CHAN_BINAURAL_LEFT ] = { "BIL", "binaural
left" },
+ [AV_CHAN_BINAURAL_RIGHT ] = { "BIR", "binaural
right" },
};
void av_channel_name_bprint(AVBPrint *bp, enum AVChannel channel_id)
@@ -220,6 +222,7 @@ static const struct channel_layout_name
channel_layout_map[] = {
{ "7.2.3", AV_CHANNEL_LAYOUT_7POINT2POINT3 },
{ "9.1.4", AV_CHANNEL_LAYOUT_9POINT1POINT4_BACK },
{ "hexadecagonal", AV_CHANNEL_LAYOUT_HEXADECAGONAL },
+ { "binaural", AV_CHANNEL_LAYOUT_BINAURAL },
{ "downmix", AV_CHANNEL_LAYOUT_STEREO_DOWNMIX, },
{ "22.2", AV_CHANNEL_LAYOUT_22POINT2, },
};
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index 3a96c2d9b8..23fbc90606 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -84,6 +84,9 @@ enum AVChannel {
AV_CHAN_TOP_SURROUND_LEFT, ///< +110 degrees, Lvs, TpLS
AV_CHAN_TOP_SURROUND_RIGHT, ///< -110 degrees, Rvs, TpRS
+ AV_CHAN_BINAURAL_LEFT = 61,
+ AV_CHAN_BINAURAL_RIGHT,
Why 61 instead of simply continuing the enum?
There are other "standard" speaker location channels not yet added, like
more bottom height ones, and I'd rather have them next to the rest once
added.
Thanks,
Marton
___
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".
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] swscale/swscale_unscaled: add unscaled rgb to planar rgba
The fate test reference changes are due to the conversion being a simple
lossless deinterleave, instead of going through a RGB -> YUV -> RGB roundtrip.
Signed-off-by: James Almer
---
libswscale/swscale_unscaled.c | 85 +++
tests/ref/fate/filter-overlay_gbrap_gbrap | 2 +-
tests/ref/fate/filter-overlay_gbrp_gbrap | 2 +-
tests/ref/fate/vbn-dxt1 | 8 +--
4 files changed, 91 insertions(+), 6 deletions(-)
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index a1930b9132..5ba0d1600a 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -1260,6 +1260,87 @@ static int rgbToPlanarRgbWrapper(SwsInternal *c, const
uint8_t *const src[],
return srcSliceH;
}
+static void packedtogbrap(const uint8_t *src, int srcStride,
+ uint8_t *const dst[], const int dstStride[], int
srcSliceH,
+ int alpha_first, int inc_size, int width)
+{
+uint8_t *dest[4];
+int x, h, A = 3;
+
+dest[0] = dst[0];
+dest[1] = dst[1];
+dest[2] = dst[2];
+dest[3] = dst[3];
+
+if (alpha_first) {
+src++;
+A = -1;
+}
+
+for (h = 0; h < srcSliceH; h++) {
+for (x = 0; x < width; x++) {
+dest[0][x] = src[0];
+dest[1][x] = src[1];
+dest[2][x] = src[2];
+dest[3][x] = inc_size == 4 ? src[A] : 255;
+
+src += inc_size;
+}
+src += srcStride - width * inc_size;
+dest[0] += dstStride[0];
+dest[1] += dstStride[1];
+dest[2] += dstStride[2];
+dest[3] += dstStride[3];
+}
+}
+
+static int rgbToPlanarRgbaWrapper(SwsInternal *c, const uint8_t *const src[],
+ const int srcStride[], int srcSliceY, int
srcSliceH,
+ uint8_t *const dst[], const int dstStride[])
+{
+int alpha_first = 0;
+int stride102[] = { dstStride[1], dstStride[0], dstStride[2], dstStride[3]
};
+int stride201[] = { dstStride[2], dstStride[0], dstStride[1], dstStride[3]
};
+uint8_t *dst102[] = { dst[1] + srcSliceY * dstStride[1],
+ dst[0] + srcSliceY * dstStride[0],
+ dst[2] + srcSliceY * dstStride[2],
+ dst[3] + srcSliceY * dstStride[3] };
+uint8_t *dst201[] = { dst[2] + srcSliceY * dstStride[2],
+ dst[0] + srcSliceY * dstStride[0],
+ dst[1] + srcSliceY * dstStride[1],
+ dst[3] + srcSliceY * dstStride[3] };
+
+switch (c->srcFormat) {
+case AV_PIX_FMT_RGB24:
+packedtogbrap((const uint8_t *) src[0], srcStride[0], dst201,
+ stride201, srcSliceH, alpha_first, 3, c->srcW);
+break;
+case AV_PIX_FMT_BGR24:
+packedtogbrap((const uint8_t *) src[0], srcStride[0], dst102,
+ stride102, srcSliceH, alpha_first, 3, c->srcW);
+break;
+case AV_PIX_FMT_ARGB:
+alpha_first = 1;
+case AV_PIX_FMT_RGBA:
+packedtogbrap((const uint8_t *) src[0], srcStride[0], dst201,
+ stride201, srcSliceH, alpha_first, 4, c->srcW);
+break;
+case AV_PIX_FMT_ABGR:
+alpha_first = 1;
+case AV_PIX_FMT_BGRA:
+packedtogbrap((const uint8_t *) src[0], srcStride[0], dst102,
+ stride102, srcSliceH, alpha_first, 4, c->srcW);
+break;
+default:
+av_log(c, AV_LOG_ERROR,
+ "unsupported planar RGB conversion %s -> %s\n",
+ av_get_pix_fmt_name(c->srcFormat),
+ av_get_pix_fmt_name(c->dstFormat));
+}
+
+return srcSliceH;
+}
+
#define BAYER_GBRG
#define BAYER_8
#define BAYER_RENAME(x) bayer_gbrg8_to_##x
@@ -2144,6 +2225,10 @@ void ff_get_unscaled_swscale(SwsInternal *c)
isPackedRGB(srcFormat) && dstFormat == AV_PIX_FMT_GBRP)
c->convert_unscaled = rgbToPlanarRgbWrapper;
+if (av_pix_fmt_desc_get(srcFormat)->comp[0].depth == 8 &&
+isPackedRGB(srcFormat) && dstFormat == AV_PIX_FMT_GBRAP)
+c->convert_unscaled = rgbToPlanarRgbaWrapper;
+
if (isBayer(srcFormat)) {
c->dst_slice_align = 2;
if (dstFormat == AV_PIX_FMT_RGB24)
diff --git a/tests/ref/fate/filter-overlay_gbrap_gbrap
b/tests/ref/fate/filter-overlay_gbrap_gbrap
index 5048a346ae..49e14c643c 100644
--- a/tests/ref/fate/filter-overlay_gbrap_gbrap
+++ b/tests/ref/fate/filter-overlay_gbrap_gbrap
@@ -3,4 +3,4 @@
#codec_id 0: rawvideo
#dimensions 0: 128x128
#sar 0: 1/1
-0, 0, 0,1,65536, 0x821bcb9b
+0, 0, 0,1,65536, 0xbac99946
diff --git a/tests/ref/fate/filter-overlay_gbrp_gbrap
b/tests/ref/fate/filter-overlay_gbrp_gbrap
index 99524c3355..204c9d0625 100644
--- a/tests/ref/fate/filter-overlay_gbrp_gbrap
+++ b/tests/ref/fate/filter-overlay_gbrp_gbrap
@@ -3,4 +3,4 @@
#codec_i
Re: [FFmpeg-devel] [PATCH] libavutil/hwcontext_d3d11va: Support Y212/XV36 pixel format
On 10/31/2024 9:45 AM, fei.w.wang-at-intel@ffmpeg.org wrote:
From: Fei Wang
Use DXGI 16bit pixel format to compatible with 12bit Y212/XV36 since
there is no 12bit pixel defined in D3D11.
Fix cmdline on Windows:
$ ffmpeg.exe -hwaccel qsv -i input_12bit.bin -f null -
Signed-off-by: Fei Wang
---
libavutil/hwcontext_d3d11va.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 9d81effe5e..2cde44af8e 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -104,6 +104,10 @@ static const struct {
{ DXGI_FORMAT_P016, AV_PIX_FMT_P012 },
{ DXGI_FORMAT_Y216, AV_PIX_FMT_Y216 },
{ DXGI_FORMAT_Y416, AV_PIX_FMT_XV48 },
+// There is no 12bit pixel format defined in D3D11, use 16bit to compatible
+// with 12 bit AV_PIX_FMT* formats.
+{ DXGI_FORMAT_Y216, AV_PIX_FMT_Y212 },
+{ DXGI_FORMAT_Y416, AV_PIX_FMT_XV36 },
Should the same be added to dxva2?
OpenPGP_signature.asc
Description: OpenPGP digital 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] fftools/ffplay: fix crash when vk renderer is null
> On Oct 31, 2024, at 21:40, Leandro Santiago wrote:
>
> When vulkan rendering is requested by the user and fails, ffplay should
> exit graciously instead of crash due to a null pointer deref.
>
> Signed-off-by: Leandro Santiago
> ---
> fftools/ffplay.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> index a596972769..56d0a36ca1 100644
> --- a/fftools/ffplay.c
> +++ b/fftools/ffplay.c
> @@ -2612,6 +2612,11 @@ static int create_hwaccel(AVBufferRef **device_ctx)
> if (type == AV_HWDEVICE_TYPE_NONE)
> return AVERROR(ENOTSUP);
> +if (!vk_renderer) {
> +av_log(NULL, AV_LOG_ERROR, "Vulkan renderer is not available\n");
> +return AVERROR(EINVAL);
> +}
> +
OK. Maybe return AVERROR(ENOTSUP)?
> ret = vk_renderer_get_hw_dev(vk_renderer, &vk_dev);
> if (ret < 0)
> return ret;
> --
> 2.46.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] AVFilter
On Sat, Oct 19, 2024 at 4:39 AM Rémi Denis-Courmont wrote: > > Le perjantaina 18. lokakuuta 2024, 14.42.46 EEST Nicolas George a écrit : > > That might be true if you only consider commercial projects. For > > community projects and hobby projects, that is certainly not true at > > all. > > > > And I want to emphasize that community projects and hobby projects > > deserve our consideration as much as commercial projects. > > Community and hobby projects can just as well patch FFmpeg. In fact, they can > more easily do so as they don't have to go through corporate compliance > theatrics on how to (not) patch external projects or OSS code. > > > > Debian is rather the exception than the rule as far as providing usable > > > FFmpeg shared libraries in the system. > > > > Debian and its derivatives make already a significant part of the > > available distros. > > > But it is quite easy to check that most other distros do have shared > > FFmpeg on the system. > > Well no, it is quite hard to check something false. > > Red Hat and most enterprise distros do not. > Fedora does not. > Ubuntu ships a cut-down version in their main repositories. > What? Fedora has been shipping FFmpeg in the repositories since Fedora Linux 36 as shared libraries. It has been available for RHEL through EPEL since RHEL 9 as well. It's even documented in the FFmpeg tracker: https://trac.ffmpeg.org/wiki/Downstreams SUSE Linux Enterprise has shipped FFmpeg for a very long time too. It's at least present in SLE 15, and will be present in the upcoming SLE 16. Nearly all Linux distribution families now ship FFmpeg as shared libraries. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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] avcodec/amfenc: increase precision of Sleep() on Windows
On Thu, Oct 31, 2024 at 6:54 PM Dmitrii Ovchinnikov wrote: > > If there are no comments, I plan to merge this patch at the end of the > week. I will update the title and description to match the current version > of the patch. IMO patches like this playing with sleep() are completely unacceptable. This might be acceptable in your binary blob but it's completely unacceptable in FFmpeg. Kieran ___ 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] avcodec/amfenc: increase precision of Sleep() on Windows
This patch does not touch the sleep . The description remains from the old version and I will correct it. ___ 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] fftools/ffplay: fix crash when vk renderer is null
When vulkan rendering is requested by the user and fails, ffplay should
exit graciously instead of crash due to a null pointer deref.
Signed-off-by: Leandro Santiago
---
fftools/ffplay.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index a596972769..56d0a36ca1 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -2612,6 +2612,11 @@ static int create_hwaccel(AVBufferRef **device_ctx)
if (type == AV_HWDEVICE_TYPE_NONE)
return AVERROR(ENOTSUP);
+if (!vk_renderer) {
+av_log(NULL, AV_LOG_ERROR, "Vulkan renderer is not available\n");
+return AVERROR(EINVAL);
+}
+
ret = vk_renderer_get_hw_dev(vk_renderer, &vk_dev);
if (ret < 0)
return ret;
--
2.46.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] fftools/ffplay: fix crash when vk renderer is null
When vulkan rendering is requested by the user and fails, ffplay should
exit graciously instead of crash due to a null pointer deref.
Signed-off-by: Leandro Santiago
---
fftools/ffplay.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index a596972769..56d0a36ca1 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -2612,6 +2612,11 @@ static int create_hwaccel(AVBufferRef **device_ctx)
if (type == AV_HWDEVICE_TYPE_NONE)
return AVERROR(ENOTSUP);
+if (!vk_renderer) {
+av_log(NULL, AV_LOG_ERROR, "Vulkan renderer is not available\n");
+return AVERROR(ENOTSUP);
+}
+
ret = vk_renderer_get_hw_dev(vk_renderer, &vk_dev);
if (ret < 0)
return ret;
--
2.46.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] swscale/swscale: prevent integer overflow in chrRangeToJpeg16_c
Same as it's done in lumRangeToJpeg16_c(). Plenty of allowed input values can
overflow here.
Fixes: src/libswscale/swscale.c:198:47: runtime error: signed integer overflow:
475328 * 4663 cannot be represented in type 'int'
Signed-off-by: James Almer
---
libswscale/swscale.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 3402d3eb56..edd7698e59 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -194,8 +194,8 @@ static void chrRangeToJpeg16_c(int16_t *_dstU, int16_t
*_dstV, int width)
int32_t *dstU = (int32_t *) _dstU;
int32_t *dstV = (int32_t *) _dstV;
for (i = 0; i < width; i++) {
-dstU[i] = (FFMIN(dstU[i], 30775 << 4) * 4663 - (9289992 << 4)) >> 12;
// -264
-dstV[i] = (FFMIN(dstV[i], 30775 << 4) * 4663 - (9289992 << 4)) >> 12;
// -264
+dstU[i] = (FFMIN(dstU[i], 30775 << 4) * 4663U - (9289992 << 4)) >> 12;
// -264
+dstV[i] = (FFMIN(dstV[i], 30775 << 4) * 4663U - (9289992 << 4)) >> 12;
// -264
}
}
--
2.47.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] lavfi/vf_drawtext: use INT_(MIN|MAX) instead of hardcoded values
The values +-32000 smell like something that will break in the future.
Signed-off-by: Leandro Santiago
---
libavfilter/vf_drawtext.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index 2b0a21a4b4..96a8a59f0e 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -1399,9 +1399,9 @@ static int measure_text(AVFilterContext *ctx,
TextMetrics *metrics)
char *textdup = NULL, *start = NULL;
int num_chars = 0;
int width64 = 0, w64 = 0;
-int cur_min_y64 = 0, first_max_y64 = -32000;
-int first_min_x64 = 32000, last_max_x64 = -32000;
-int min_y64 = 32000, max_y64 = -32000, min_x64 = 32000, max_x64 =
-32000;
+int cur_min_y64 = 0, first_max_y64 = INT_MIN;
+int first_min_x64 = INT_MAX, last_max_x64 = INT_MIN;
+int min_y64 = INT_MAX, max_y64 = INT_MIN, min_x64 = INT_MAX,
max_x64 = INT_MIN;
int line_count = 0;
uint32_t code = 0;
Glyph *glyph = NULL;
@@ -1465,7 +1465,7 @@ continue_on_failed2:
goto done;
}
w64 = 0;
-cur_min_y64 = 32000;
+cur_min_y64 = INT_MAX;
for (int t = 0; t < hb->glyph_count; ++t) {
uint8_t is_tab = last_tab_idx < s->tab_count &&
hb->glyph_info[t].cluster ==
s->tab_clusters[last_tab_idx] - line_offset;
--
2.46.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] doc/examples: unify approach for get_format on hwaccel related examples
This adds lots of copy&paste, but introducing ways to reuse the code would
find the examples harder to read.
Signed-off-by: Leandro Santiago
---
doc/examples/hw_decode.c | 10 --
doc/examples/qsv_decode.c | 11 ---
doc/examples/qsv_transcode.c | 11 ---
doc/examples/vaapi_transcode.c | 10 --
4 files changed, 16 insertions(+), 26 deletions(-)
diff --git a/doc/examples/hw_decode.c b/doc/examples/hw_decode.c
index ac4e445505..dc40c864a2 100644
--- a/doc/examples/hw_decode.c
+++ b/doc/examples/hw_decode.c
@@ -60,17 +60,15 @@ static int hw_decoder_init(AVCodecContext *ctx, const enum
AVHWDeviceType type)
return err;
}
-static enum AVPixelFormat get_hw_format(AVCodecContext *ctx,
-const enum AVPixelFormat *pix_fmts)
+static enum AVPixelFormat get_format(AVCodecContext *ctx, const enum
AVPixelFormat *p)
{
-const enum AVPixelFormat *p;
-
-for (p = pix_fmts; *p != -1; p++) {
+for (; *p != AV_PIX_FMT_NONE; p++) {
if (*p == hw_pix_fmt)
return *p;
}
fprintf(stderr, "Failed to get HW surface format.\n");
+
return AV_PIX_FMT_NONE;
}
@@ -218,7 +216,7 @@ int main(int argc, char *argv[])
if (avcodec_parameters_to_context(decoder_ctx, video->codecpar) < 0)
return -1;
-decoder_ctx->get_format = get_hw_format;
+decoder_ctx->get_format = get_format;
if (hw_decoder_init(decoder_ctx, type) < 0)
return -1;
diff --git a/doc/examples/qsv_decode.c b/doc/examples/qsv_decode.c
index 5a6f3625aa..9f5ddf31a7 100644
--- a/doc/examples/qsv_decode.c
+++ b/doc/examples/qsv_decode.c
@@ -41,14 +41,11 @@
#include
#include
-static int get_format(AVCodecContext *avctx, const enum AVPixelFormat
*pix_fmts)
+static enum AVPixelFormat get_format(AVCodecContext *avctx, const enum
AVPixelFormat *p)
{
-while (*pix_fmts != AV_PIX_FMT_NONE) {
-if (*pix_fmts == AV_PIX_FMT_QSV) {
-return AV_PIX_FMT_QSV;
-}
-
-pix_fmts++;
+for (; *p != AV_PIX_FMT_NONE; p++) {
+if (*p == AV_PIX_FMT_QSV)
+return *p;
}
fprintf(stderr, "The QSV pixel format not offered in get_format()\n");
diff --git a/doc/examples/qsv_transcode.c b/doc/examples/qsv_transcode.c
index 665a76af2e..d8b959967a 100644
--- a/doc/examples/qsv_transcode.c
+++ b/doc/examples/qsv_transcode.c
@@ -115,14 +115,11 @@ fail:
return ret;
}
-static int get_format(AVCodecContext *avctx, const enum AVPixelFormat
*pix_fmts)
+static enum AVPixelFormat get_format(AVCodecContext *avctx, const enum
AVPixelFormat *p)
{
-while (*pix_fmts != AV_PIX_FMT_NONE) {
-if (*pix_fmts == AV_PIX_FMT_QSV) {
-return AV_PIX_FMT_QSV;
-}
-
-pix_fmts++;
+for (; *p != AV_PIX_FMT_NONE; p++) {
+if (*p == AV_PIX_FMT_QSV)
+return *p;
}
fprintf(stderr, "The QSV pixel format not offered in get_format()\n");
diff --git a/doc/examples/vaapi_transcode.c b/doc/examples/vaapi_transcode.c
index e1b7a43883..06358624a3 100644
--- a/doc/examples/vaapi_transcode.c
+++ b/doc/examples/vaapi_transcode.c
@@ -42,17 +42,15 @@ static int video_stream = -1;
static AVStream *ost;
static int initialized = 0;
-static enum AVPixelFormat get_vaapi_format(AVCodecContext *ctx,
- const enum AVPixelFormat *pix_fmts)
+static enum AVPixelFormat get_format(AVCodecContext *ctx, const enum
AVPixelFormat *p)
{
-const enum AVPixelFormat *p;
-
-for (p = pix_fmts; *p != AV_PIX_FMT_NONE; p++) {
+for (; *p != AV_PIX_FMT_NONE; p++) {
if (*p == AV_PIX_FMT_VAAPI)
return *p;
}
fprintf(stderr, "Unable to decode this file using VA-API.\n");
+
return AV_PIX_FMT_NONE;
}
@@ -97,7 +95,7 @@ static int open_input_file(const char *filename)
fprintf(stderr, "A hardware device reference create failed.\n");
return AVERROR(ENOMEM);
}
-decoder_ctx->get_format= get_vaapi_format;
+decoder_ctx->get_format= get_format;
if ((ret = avcodec_open2(decoder_ctx, decoder, NULL)) < 0)
fprintf(stderr, "Failed to open codec for decoding. Error code: %s\n",
--
2.46.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] lavfi/vf_drawtext: use INT_(MIN|MAX) instead of hardcoded values
The values +-32000 smell like something that will break in the future.
Signed-off-by: Leandro Santiago
---
libavfilter/vf_drawtext.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index 2b0a21a4b4..96a8a59f0e 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -1399,9 +1399,9 @@ static int measure_text(AVFilterContext *ctx, TextMetrics
*metrics)
char *textdup = NULL, *start = NULL;
int num_chars = 0;
int width64 = 0, w64 = 0;
-int cur_min_y64 = 0, first_max_y64 = -32000;
-int first_min_x64 = 32000, last_max_x64 = -32000;
-int min_y64 = 32000, max_y64 = -32000, min_x64 = 32000, max_x64 = -32000;
+int cur_min_y64 = 0, first_max_y64 = INT_MIN;
+int first_min_x64 = INT_MAX, last_max_x64 = INT_MIN;
+int min_y64 = INT_MAX, max_y64 = INT_MIN, min_x64 = INT_MAX, max_x64 =
INT_MIN;
int line_count = 0;
uint32_t code = 0;
Glyph *glyph = NULL;
@@ -1465,7 +1465,7 @@ continue_on_failed2:
goto done;
}
w64 = 0;
-cur_min_y64 = 32000;
+cur_min_y64 = INT_MAX;
for (int t = 0; t < hb->glyph_count; ++t) {
uint8_t is_tab = last_tab_idx < s->tab_count &&
hb->glyph_info[t].cluster == s->tab_clusters[last_tab_idx]
- line_offset;
--
2.46.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] libavfi/vf_drawtext: fix memory management when destroying font face
Ref https://trac.ffmpeg.org/ticket/11152
According to harfbuzz docs, hb_ft_font_set_funcs() does not need to be
called, as, quoted:
```
An #hb_font_t object created with hb_ft_font_create()
is preconfigured for FreeType font functions and does not
require this function to be used.
```
Using this function seems to cause memory management issues between
harfbuzz and freetype, and could be eliminated.
This commit also call hb_ft_font_changed() when the underlying FC_Face
changes size, as stated on hardbuzz:
```
HarfBuzz also provides a utility function called hb_ft_font_changed() that you
should call
whenever you have altered the properties of your underlying FT_Face, as well as
a hb_ft_get_face()
that you can call on an hb_font_t font object to fetch its underlying FT_Face.
```
Finally, the execution order between hb_font_destroy() and
hb_buffer_destroy() is flipped to match the order of creation of
the respective objects.
Signed-off-by: Leandro Santiago
---
libavfilter/vf_drawtext.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index 2b0a21a4b4..cf99b4e59e 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -445,6 +445,7 @@ static int glyph_cmp(const void *key, const void *b)
static av_cold int set_fontsize(AVFilterContext *ctx, unsigned int fontsize)
{
int err;
+int line;
DrawTextContext *s = ctx->priv;
if ((err = FT_Set_Pixel_Sizes(s->face, 0, fontsize))) {
@@ -453,6 +454,12 @@ static av_cold int set_fontsize(AVFilterContext *ctx,
unsigned int fontsize)
return AVERROR(EINVAL);
}
+// Whenever the underlying FT_Face changes, harfbuzz has to be notified of
the change.
+for (line = 0; line < s->line_count; line++) {
+ TextLine *cur_line = &s->lines[line];
+ hb_ft_font_changed(cur_line->hb_data.font);
+}
+
s->fontsize = fontsize;
return 0;
@@ -1365,15 +1372,17 @@ static int shape_text_hb(DrawTextContext *s,
HarfbuzzData* hb, const char* text,
if(!hb_buffer_allocation_successful(hb->buf)) {
return AVERROR(ENOMEM);
}
+
hb_buffer_set_direction(hb->buf, HB_DIRECTION_LTR);
hb_buffer_set_script(hb->buf, HB_SCRIPT_LATIN);
hb_buffer_set_language(hb->buf, hb_language_from_string("en", -1));
hb_buffer_guess_segment_properties(hb->buf);
-hb->font = hb_ft_font_create(s->face, NULL);
+
+hb->font = hb_ft_font_create_referenced(s->face);
if(hb->font == NULL) {
return AVERROR(ENOMEM);
}
-hb_ft_font_set_funcs(hb->font);
+
hb_buffer_add_utf8(hb->buf, text, textLen, 0, -1);
hb_shape(hb->font, hb->buf, NULL, 0);
hb->glyph_info = hb_buffer_get_glyph_infos(hb->buf, &hb->glyph_count);
@@ -1384,8 +1393,8 @@ static int shape_text_hb(DrawTextContext *s,
HarfbuzzData* hb, const char* text,
static void hb_destroy(HarfbuzzData *hb)
{
-hb_buffer_destroy(hb->buf);
hb_font_destroy(hb->font);
+hb_buffer_destroy(hb->buf);
hb->buf = NULL;
hb->font = NULL;
hb->glyph_info = NULL;
--
2.46.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] avcodec/vaapi_encode: skip AVBR if HRD parameters are set
AVBR does not use VAEncMiscParameterTypeHRD, so attempting to set
rc_buffer_size and bit_rate together will cause the rc_buffer_size
to be ignored if the VAAPI driver supports AVBR. We should prefer
regular VBR for that case.
Signed-off-by: Cameron Gutman
---
libavcodec/vaapi_encode.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 16a9a364f0..2ff5cf15fb 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1276,7 +1276,10 @@ static av_cold int
vaapi_encode_init_rate_control(AVCodecContext *avctx)
TRY_RC_MODE(RC_MODE_CBR, 0);
if (avctx->bit_rate > 0) {
-TRY_RC_MODE(RC_MODE_AVBR, 0);
+// AVBR does not enforce RC buffer constraints
+if (!avctx->rc_buffer_size && !avctx->rc_initial_buffer_occupancy)
+TRY_RC_MODE(RC_MODE_AVBR, 0);
+
TRY_RC_MODE(RC_MODE_VBR, 0);
TRY_RC_MODE(RC_MODE_CBR, 0);
} else {
--
2.43.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] lavf/mxfenc: Use nb_components, not av_pix_fmt_count_planes()
tis 2024-10-29 klockan 08:48 -0700 skrev Pierre-Anthony Lemieux: > LGTM Will push later today /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] libavutil split out
tor 2024-10-31 klockan 01:08 +0100 skrev Michael Niedermayer: > Hi > > Theres a problem with libavutil, or maybe more than one > > a library implementing a codec that tries do use libavutil and itself > is > used by libavcodec. Creates a (build) dependancy like this > libavutil -> libmycodec -> libavcodec > Thats ok if libavutil is a seperate source but if libavutil and > libavcodec > are in the same source package and are build together This sounds like you want to avoid having to clone the repo twice. Disk space is cheaper than developer time > , well iam sure > you see this doesnt work > build ffmpeg first, theres no libmycodec, > build libmycodec first, theres no libavutil > now of course this can be worked around by building ffmpeg twice > But this is not documented, not suggested, not tested and not > considered > > of course myself spliting out libpostproc made me realize this issue. > But > its a much broader problem than libpostproc. For libpostproc i can > just > copy everything and remove all libavutil dependancies > And even without that it builds and works fine and all but only > because i had > a prior build libavutil installed from before. Are you trying to make libpostproc into a standalone library in a separate source tree? Why? Surely the build system can be improved to only building it and libavutil if someone wants that /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavutil/hwcontext_d3d11va: Support Y212/XV36 pixel format
From: Fei Wang
Use DXGI 16bit pixel format to compatible with 12bit Y212/XV36 since
there is no 12bit pixel defined in D3D11.
Fix cmdline on Windows:
$ ffmpeg.exe -hwaccel qsv -i input_12bit.bin -f null -
Signed-off-by: Fei Wang
---
libavutil/hwcontext_d3d11va.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 9d81effe5e..2cde44af8e 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -104,6 +104,10 @@ static const struct {
{ DXGI_FORMAT_P016, AV_PIX_FMT_P012 },
{ DXGI_FORMAT_Y216, AV_PIX_FMT_Y216 },
{ DXGI_FORMAT_Y416, AV_PIX_FMT_XV48 },
+// There is no 12bit pixel format defined in D3D11, use 16bit to compatible
+// with 12 bit AV_PIX_FMT* formats.
+{ DXGI_FORMAT_Y216, AV_PIX_FMT_Y212 },
+{ DXGI_FORMAT_Y416, AV_PIX_FMT_XV36 },
// Special opaque formats. The pix_fmt is merely a place holder, as the
// opaque format cannot be accessed directly.
{ DXGI_FORMAT_420_OPAQUE, AV_PIX_FMT_YUV420P },
--
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 v4 1/8] lavc/vaapi_dec: Create VA parameters dynamically
On Wo, 2024-10-30 at 01:15 +, Xiang, Haihao wrote:
> On Ma, 2024-10-28 at 16:55 +0800, fei.w.wang-at-intel@ffmpeg.org wrote:
> > From: Fei Wang
> >
> > Signed-off-by: Fei Wang
> > ---
> > libavcodec/vaapi_decode.c | 34 +-
> > libavcodec/vaapi_decode.h | 7 ++-
> > 2 files changed, 27 insertions(+), 14 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> > index a59194340f..709699dcaf 100644
> > --- a/libavcodec/vaapi_decode.c
> > +++ b/libavcodec/vaapi_decode.c
> > @@ -39,12 +39,24 @@ int ff_vaapi_decode_make_param_buffer(AVCodecContext
> > *avctx,
> > {
> > VAAPIDecodeContext *ctx = avctx->internal->hwaccel_priv_data;
> > VAStatus vas;
> > - VABufferID buffer;
> >
> > - av_assert0(pic->nb_param_buffers + 1 <= MAX_PARAM_BUFFERS);
> > + av_assert0(pic->nb_param_buffers <= pic->nb_param_buffers_allocated);
> > + if (pic->nb_param_buffers == pic->nb_param_buffers_allocated) {
> > + VABufferID *tmp =
> > + av_realloc_array(pic->param_buffers,
> > + pic->nb_param_buffers_allocated + 16,
> > + sizeof(*pic->param_buffers));
> > + if (!tmp)
> > + return AVERROR(ENOMEM);
> > +
> > + pic->param_buffers = tmp;
> > + pic->nb_param_buffers_allocated += 16;
> > + }
> > + av_assert0(pic->nb_param_buffers + 1 <= pic-
> > >nb_param_buffers_allocated);
> >
> > vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
> > - type, size, 1, (void*)data, &buffer);
> > + type, size, 1, (void*)data,
> > + &pic->param_buffers[pic->nb_param_buffers]);
> > if (vas != VA_STATUS_SUCCESS) {
> > av_log(avctx, AV_LOG_ERROR, "Failed to create parameter "
> > "buffer (type %d): %d (%s).\n",
> > @@ -52,14 +64,14 @@ int ff_vaapi_decode_make_param_buffer(AVCodecContext
> > *avctx,
> > return AVERROR(EIO);
> > }
> >
> > - pic->param_buffers[pic->nb_param_buffers++] = buffer;
> > -
> > av_log(avctx, AV_LOG_DEBUG, "Param buffer (type %d, %zu bytes) "
> > - "is %#x.\n", type, size, buffer);
> > + "is %#x.\n", type, size, pic->param_buffers[pic-
> > > nb_param_buffers]);
> > +
> > + ++pic->nb_param_buffers;
> > +
> > return 0;
> > }
> >
> > -
> > int ff_vaapi_decode_make_slice_buffer(AVCodecContext *avctx,
> > VAAPIDecodePicture *pic,
> > const void *params_data,
> > @@ -222,7 +234,9 @@ fail:
> > ff_vaapi_decode_destroy_buffers(avctx, pic);
> > fail_at_end:
> > exit:
> > - pic->nb_param_buffers = 0;
> > + pic->nb_param_buffers = 0;
> > + pic->nb_param_buffers_allocated = 0;
> > + av_freep(&pic->param_buffers);
> > pic->nb_slices = 0;
> > pic->slices_allocated = 0;
> > av_freep(&pic->slice_buffers);
> > @@ -235,7 +249,9 @@ int ff_vaapi_decode_cancel(AVCodecContext *avctx,
> > {
> > ff_vaapi_decode_destroy_buffers(avctx, pic);
> >
> > - pic->nb_param_buffers = 0;
> > + pic->nb_param_buffers = 0;
> > + pic->nb_param_buffers_allocated = 0;
> > + av_freep(&pic->param_buffers);
> > pic->nb_slices = 0;
> > pic->slices_allocated = 0;
> > av_freep(&pic->slice_buffers);
> > diff --git a/libavcodec/vaapi_decode.h b/libavcodec/vaapi_decode.h
> > index 702171e108..a373eb5d6b 100644
> > --- a/libavcodec/vaapi_decode.h
> > +++ b/libavcodec/vaapi_decode.h
> > @@ -32,15 +32,12 @@ static inline VASurfaceID
> > ff_vaapi_get_surface_id(AVFrame
> > *pic)
> > return (uintptr_t)pic->data[3];
> > }
> >
> > -enum {
> > - MAX_PARAM_BUFFERS = 16,
> > -};
> > -
> > typedef struct VAAPIDecodePicture {
> > VASurfaceID output_surface;
> >
> > int nb_param_buffers;
> > - VABufferID param_buffers[MAX_PARAM_BUFFERS];
> > + VABufferID *param_buffers;
> > + int nb_param_buffers_allocated;
> >
> > int nb_slices;
> > VABufferID *slice_buffers;
>
>
> The patchset looks good and works well for me. I'll push it if there is no
> objection in a few days.
>
Pushed,
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 3/7] swscale/output: add XV48 output support
On 10/31/2024 3:34 PM, Michael Niedermayer wrote: On Tue, Oct 29, 2024 at 04:50:47PM -0300, James Almer wrote: On 10/29/2024 4:29 PM, Michael Niedermayer wrote: On Tue, Oct 29, 2024 at 01:03:21PM +0100, Michael Niedermayer wrote: On Fri, Oct 25, 2024 at 07:56:29PM -0300, James Almer wrote: On 10/25/2024 7:18 PM, Michael Niedermayer wrote: On Wed, Oct 23, 2024 at 04:36:44PM -0300, James Almer wrote: Signed-off-by: James Almer --- libswscale/output.c | 37 +++- libswscale/utils.c | 4 +-- tests/ref/fate/filter-pixdesc-xv48be | 1 + tests/ref/fate/filter-pixdesc-xv48le | 1 + tests/ref/fate/filter-pixfmts-copy | 2 ++ tests/ref/fate/filter-pixfmts-crop | 2 ++ tests/ref/fate/filter-pixfmts-field | 2 ++ tests/ref/fate/filter-pixfmts-fieldorder | 2 ++ tests/ref/fate/filter-pixfmts-hflip | 2 ++ tests/ref/fate/filter-pixfmts-il | 2 ++ tests/ref/fate/filter-pixfmts-null | 2 ++ tests/ref/fate/filter-pixfmts-scale | 2 ++ tests/ref/fate/filter-pixfmts-transpose | 2 ++ tests/ref/fate/filter-pixfmts-vflip | 2 ++ 14 files changed, 48 insertions(+), 15 deletions(-) create mode 100644 tests/ref/fate/filter-pixdesc-xv48be create mode 100644 tests/ref/fate/filter-pixdesc-xv48le didnt apply cleanly so no test but LGTM thx It was Niklas recent renaming patch. You can try a rebased version in https://github.com/jamrial/FFmpeg/commits/pixdesc/ thanks, that helped, swscale patches seem turning stale within the 500ms transit time to the ML the swscale changes in that branch look good tests seems passing on mingw32/64 linux x86-32/64 and mips i had to leave before qemu arm tests finished and of course arm faild :) make fate-pixfmt-x2bgr10le fate-pixfmt-x2rgb10le -k TESTpixfmt-x2bgr10le --- src/tests/ref/fate/pixfmt-x2bgr10le 2024-10-29 20:26:42.011219228 +0100 +++ tests/data/fate/pixfmt-x2bgr10le2024-10-29 20:28:11.519912980 +0100 @@ -1,2 +1,2 @@ -028652e885aef68639341bbc8415be57 *tests/data/pixfmt/x2bgr10le.yuv +040ceb964e1401b964d72f97c44ca596 *tests/data/pixfmt/x2bgr10le.yuv 15206400 tests/data/pixfmt/x2bgr10le.yuv Test pixfmt-x2bgr10le failed. Look at tests/data/fate/pixfmt-x2bgr10le.err for details. make: *** [src/tests/Makefile:311: fate-pixfmt-x2bgr10le] Error 1 TESTpixfmt-x2rgb10le --- src/tests/ref/fate/pixfmt-x2rgb10le 2024-10-29 20:26:42.011219228 +0100 +++ tests/data/fate/pixfmt-x2rgb10le2024-10-29 20:28:12.371919593 +0100 @@ -1,2 +1,2 @@ -028652e885aef68639341bbc8415be57 *tests/data/pixfmt/x2rgb10le.yuv +040ceb964e1401b964d72f97c44ca596 *tests/data/pixfmt/x2rgb10le.yuv 15206400 tests/data/pixfmt/x2rgb10le.yuv Test pixfmt-x2rgb10le failed. Look at tests/data/fate/pixfmt-x2rgb10le.err for details. make: *** [src/tests/Makefile:311: fate-pixfmt-x2rgb10le] Error 1 thx That is a test from a patch i didn't push, so not a problem in git head at least. Is that a BE arm machine? no The only thing i can think about is the check in swscale/output.c for AV_PIX_FMT_X2RGB10, which for that target would become AV_PIX_FMT_X2RGB10BE, and thus not trigger with this test. This is IMO wrong because the yuv2packed* pointers are in turn set for both LE and BE. arm has some funny behavior with misaligned 32bit access that is IIRC, if you cast a uint8_t * to int * and it was not an address thats a multiple of 4 and derefernce you can get results that you dont expect IIRC. if that makes no sense then i dont know, but tell me and ill just retest I tried applying the patch adding this test and running it under gcc-ubsan and it didn't complain about unaligned accesses, so i don't know what could be happening if that target is not BE. OpenPGP_signature.asc Description: OpenPGP digital 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] lavf/mxfenc: Use nb_components, not av_pix_fmt_count_planes()
On Tue, 29 Oct 2024, Tomas Härdin wrote:
tis 2024-10-29 klockan 12:21 -0300 skrev James Almer:
From ce4b1dfb97530b242f899e5d1686f98fa83a7698 Mon Sep 17 00:00:00
2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Tue, 29 Oct 2024 16:13:04 +0100
Subject: [PATCH] lavf/mxfenc: Use nb_components, not
av_pix_fmt_count_planes()
This fixed https://trac.ffmpeg.org/ticket/11267
---
libavformat/mxfenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 57be9e6ef6..e66df0fba2 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1488,7 +1488,7 @@ static void
mxf_write_jpeg2000_subdesc(AVFormatContext *s, AVStream *st)
MXFStreamContext *sc = st->priv_data;
AVIOContext *pb = s->pb;
int64_t pos;
- int component_count = av_pix_fmt_count_planes(st->codecpar-
format);
+ int component_count = av_pix_fmt_desc_get(st->codecpar-
format)->nb_components;
I don't think anything ensures that av_pix_fmt_desc_get() here will
not
return NULL, so maybe instead do:
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(st->codecpar-
format);
int component_count;
if (!desc)
return AVERROR(EINVAL);
component_count = desc->nb_components;
I can't really see how that would happen, but I suppose it doesn't
hurt.
I see elsewhere in the code an assert that the returned pointer is not
NULL (mxf_write_ffv1_desc()), and explicit checks for it
There is a similar check in your patch:
-int component_count = av_pix_fmt_count_planes(st->codecpar->format);
+const AVPixFmtDescriptor *pix_desc =
av_pix_fmt_desc_get(st->codecpar->format);
+
+if (!pix_desc) {
+av_log(s, AV_LOG_ERROR, "Pixel format not set - not writing
JPEG2000SubDescriptor\n");
+return;
+}
You should propagate back the error, not just silently ignore it. Or if
this cannot happen, make this an assert instead.
Thanks,
Marton
___
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".
