Re: [FFmpeg-devel] root access voting
On Wed, Nov 6, 2024 at 2:27 PM Michael Niedermayer wrote: > > * you cannot expect a community of tens of people to make it their top > > priority to bend over backwards to accommodate one person > > "one for all and all for one" seems a interresting concept for a team, > but thats just my oppinion. > That already falls apart if the one in question already violates that, repeatedly, and over years, without consequences. - Hendrik ___ 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] Patch to add interlaced HEVC decoding to HEVCDEC
On Wed, Oct 30, 2024 at 4:52 PM Jose Santiago wrote:
> +static int interlaced_frame_from_fields(AVFrame *dst,
> +const AVFrame *field1,
> +const AVFrame *field2)
> +{
> +int i, ret = 0;
> +
> +av_frame_unref(dst);
> +
> +dst->format = field1->format;
> +dst->width = field1->width;
> +dst->height = field1->height * 2;
> +dst->nb_samples = field1->nb_samples;
> +ret = av_channel_layout_copy(&dst->ch_layout, &field1->ch_layout);
> +if (ret < 0)
> +return ret;
> +
> +ret = av_frame_copy_props(dst, field1);
> +if (ret < 0)
> +return ret;
> +if (field1->duration > 0 && field1->duration != AV_NOPTS_VALUE)
> +dst->duration = field2->duration * 2;
> +else if (field2->duration > 0 && field2->duration != AV_NOPTS_VALUE)
> +dst->duration = field2->duration * 2;
> +
> +for (i = 0; i < field2->nb_side_data; i++) {
> +const AVFrameSideData *sd_src = field2->side_data[i];
> +AVFrameSideData *sd_dst;
> +AVBufferRef *ref = av_buffer_ref(sd_src->buf);
> +sd_dst = av_frame_new_side_data_from_buf(dst, sd_src->type, ref);
> +if (!sd_dst) {
> +av_buffer_unref(&ref);
> +return AVERROR(ENOMEM);
> +}
> +}
> +
> +for (i = 0; i < AV_NUM_DATA_POINTERS; i++)
> +dst->linesize[i] = field1->linesize[i]*2;
> +
> +ret = av_frame_get_buffer(dst, 0);
> +if (ret < 0)
> +return ret;
> +
> +ret = av_frame_copy(dst, field1);
> +if (ret < 0)
> +av_frame_unref(dst);
> +
> +copy_field2(dst, field2);
> +
> +for (i = 0; i < AV_NUM_DATA_POINTERS; i++)
> +dst->linesize[i] = field1->linesize[i];
> +
> +return ret;
> +}
Copying the entire frame is slow, inefficient and fundamentally
incompatible with hardware acceleration.
A correct approach would be doing what other field-based interlaced
codecs do - that is allocate a full frame picture from the start, and
decode both fields into the same frame. This then even has a chance to
work with hardware acceleration, at least in theory, at the very least
it avoids the copy overhead of the software decoder.
- Hendrik
___
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 PATCH 2/2] fate: Make it possible to have alternative reference files
On Fri, Oct 18, 2024 at 5:09 PM Alexander Strasser via ffmpeg-devel wrote: > > On 2024-10-18 16:36 +0200, Lynne via ffmpeg-devel wrote: > > On 18/10/2024 14:41, Hendrik Leppkes wrote: > > > On Fri, Oct 18, 2024 at 2:09 PM Alexander Strasser via ffmpeg-devel > > > wrote: > > > > This caused differences > > > > with 2 fate tests depending on the zlib version used. > > > > > > 2 fate tests? > > > https://fate.ffmpeg.org/report.cgi?time=20241016173824&slot=x86_32-msvc14-dll-md-windows-native > > > > > > This entire approach feels extremely brittle for the future. > > > > > > - Hendrik > > > > Yeah, definitely. > > These days, other libraries like miniz are getting used as well, so > > hardcoding each case separately is no better than what we have currently. > > Hmm not sure about the build from Hendrik. This was with a build with > zlib and compression level 0? > Its a pretty old version of zlib, yes. I never bothered to update the msvc library I use, since its just for FATE, so its from 2012, and the build is from 31b5b3badc, a few commits before the compression=0 change was reverted. - Hendrik ___ 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 PATCH 2/2] fate: Make it possible to have alternative reference files
On Fri, Oct 18, 2024 at 2:09 PM Alexander Strasser via ffmpeg-devel wrote: > This caused differences > with 2 fate tests depending on the zlib version used. 2 fate tests? https://fate.ffmpeg.org/report.cgi?time=20241016173824&slot=x86_32-msvc14-dll-md-windows-native This entire approach feels extremely brittle for the future. - Hendrik ___ 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] configure: add spirv_compiler to avfilter_suggest as well
On Mon, Oct 7, 2024 at 9:15 AM Lynne via ffmpeg-devel wrote: > > If someone were to enable libglslang/libshaderc, and then disable > all Vulkan filters, they would have the same issue as the earlier > fix for libavcodec. If you run such a setup, shouldn't the code that uses this then be excluded? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/nvdec: support resizing while decoding
On Fri, Sep 20, 2024 at 1:24 AM Carlos Ruiz wrote:
>
> Hi!
>
> This is my first contribution to the project so please excuse any bad
> etiquette, I tried to read all the FAQs before posting. Would love to start
> by thanking everyone for such an amazing framework you've built!
>
> Anyway, here's my proposed patch to support video resizing when using NVDEC
> hwaccel to decode hevc video (I could look into a similar patch for h264,
> av1, etc if this looks useful). There's a bit more context/explanation in
> the commit description in the patch, but please let me know if the use case
> isn't clear.
>
We don't really leverage these extra functions of NVDEC because it
breaks many assumptions about hwaccels, which are meant to be exact
decoders.
If anything, just fudging the width/height is certainly an API
violation and will likely not be possible as it breaks many
assumptions in the code otherwise, see below.
> ---
> libavcodec/hevc/hevcdec.c | 8 ++--
> libavcodec/nvdec.c| 21 +
> 2 files changed, 23 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
> index d915d74d22..d63fc5875f 100644
> --- a/libavcodec/hevc/hevcdec.c
> +++ b/libavcodec/hevc/hevcdec.c
> @@ -351,8 +351,12 @@ static void export_stream_params(HEVCContext *s, const
> HEVCSPS *sps)
> avctx->pix_fmt = sps->pix_fmt;
> avctx->coded_width = sps->width;
> avctx->coded_height= sps->height;
> -avctx->width = sps->width - ow->left_offset -
> ow->right_offset;
> -avctx->height = sps->height - ow->top_offset -
> ow->bottom_offset;
> +if (avctx->width <= 0 || avctx->height <= 0) {
> +avctx->width = sps->width;
> +avctx->height = sps->height;
> +}
> +avctx->width = avctx->width - ow->left_offset -
> ow->right_offset;
> +avctx->height = avctx->height - ow->top_offset -
> ow->bottom_offset;
You cannot do that here. The frame size can change mid-stream, and
this would suppress any such change.
Additionally, if this code runs more then once, then the offset is
applied repeatedly without actually resetting width/height.
- Hendrik
___
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] hevc/sei: return INVALIDDATA when a referenced SPS is not available
On Fri, Aug 30, 2024 at 11:09 PM Jan Ekström wrote:
>
> On Fri, Aug 30, 2024 at 8:40 PM Hendrik Leppkes wrote:
> >
> > The code previously returned ENOMEM, despite this not being an
> > allocation problem, but rather a bitstream problem referring to data not
> > currently available.
> >
> > Fixes playback of such streams, as it allows further processing of NAL
> > units after skipping the broken SEI NAL.
> > ---
> > libavcodec/hevc/sei.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/hevc/sei.c b/libavcodec/hevc/sei.c
> > index e39ac0c38a..b55ba71a8d 100644
> > --- a/libavcodec/hevc/sei.c
> > +++ b/libavcodec/hevc/sei.c
> > @@ -56,7 +56,7 @@ static int decode_nal_sei_pic_timing(HEVCSEI *s,
> > GetBitContext *gb,
> > const HEVCSPS *sps = ps->sps_list[s->active_seq_parameter_set_id];
> >
> > if (!sps)
> > -return(AVERROR(ENOMEM));
> > +return AVERROR_INVALIDDATA;
> >
> > if (sps->vui.frame_field_info_present_flag) {
> > int pic_struct = get_bits(gb, 4);
> > --
> > 2.42.0.windows.2
>
> LGTM.
>
> Verified that FATE still passes and that the sample linked in
> https://github.com/mpv-player/mpv/issues/14764 once again decodes.
>
Will apply tomorrow if there are no further comments.
- Hendrik
___
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] hevc/sei: return INVALIDDATA when a referenced SPS is not available
The code previously returned ENOMEM, despite this not being an
allocation problem, but rather a bitstream problem referring to data not
currently available.
Fixes playback of such streams, as it allows further processing of NAL
units after skipping the broken SEI NAL.
---
libavcodec/hevc/sei.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hevc/sei.c b/libavcodec/hevc/sei.c
index e39ac0c38a..b55ba71a8d 100644
--- a/libavcodec/hevc/sei.c
+++ b/libavcodec/hevc/sei.c
@@ -56,7 +56,7 @@ static int decode_nal_sei_pic_timing(HEVCSEI *s,
GetBitContext *gb,
const HEVCSPS *sps = ps->sps_list[s->active_seq_parameter_set_id];
if (!sps)
-return(AVERROR(ENOMEM));
+return AVERROR_INVALIDDATA;
if (sps->vui.frame_field_info_present_flag) {
int pic_struct = get_bits(gb, 4);
--
2.42.0.windows.2
___
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] use proper macro to avoid issue with prior avutil/timestamp.c
On Sat, Aug 17, 2024 at 3:27 PM Mike Lieman wrote: > > > > > FP_INFINITE is a return value from fpclassify(), not a double. > > > > Does maybe using av_int2double(UINT64_C(0xFFF) << 52) help your slow > > startup? > > > > Sadly, no. > > double log = (fpclassify(val) == FP_ZERO ? av_int2double(UINT64_C(0xFFF) << > 52) : floor(log10(fabs(val; > For the logic in this particular function - even if not accurate, any non-negative value will result in the same outcome as using -INFINITY. So using even the value 0 would work. My simple guess would be that the infinity check fails for some reason (maybe -ffast-math?), thus treating the infinite as a finite value, and using an extreme amount of precision that almost breaks printf? We could avoid the infinity entirely here without any downsides, really. Or you could check if your build uses ffast-math, not sure we support that. - Hendrik ___ 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] Make H.274 film grain support optional for H.264. Saves ~779kb.
On Tue, Aug 13, 2024 at 9:32 PM Dale Curtis wrote: > > Film grain support adds a huge amount of overhead to the H264Context > structure for a feature that is rarely used. On low end devices or > pages that have lots of media this bloats memory usage rapidly. > > This introduces a --disable-h264-film-grain option which makes > these fields optional and reduces the H264Context size from > 851808 bytes to 53444 bytes. > > Bug: https://crbug.com/359358875 > Signed-off-by: Dale Curtis > Disabling random codec features seems like an anti-feature to me, in the future it'll make every feature be questioned and compile-time conditional, and make everything terrible. If the context size is the major concern, maybe large structures should be allocated when in use, rather than always? - Hendrik ___ 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] libavformat/vapoursynth: Update to API version 4, load library at runtime
On Mon, Jul 22, 2024 at 2:14 PM Ramiro Polla wrote: > > On Mon, Jul 22, 2024 at 12:15 AM Hendrik Leppkes wrote: > > On Mon, Jul 22, 2024 at 12:08 AM Stefan Oltmanns via ffmpeg-devel > > wrote: > > > > > > Am 18.07.24 um 17:23 schrieb epira...@gmail.com: > > > > > > > >>> > > > >>> Well, the DLL directory is added to PATH by the VapourSynth installer, > > > >>> but for safety reasons ffmpeg explictly tells the LoadLibrary function > > > >>> to only search the application directory and system32, quote from > > > >>> w32dlfcn.h: > > > >>> > > > >>>> /** > > > >>>> * Safe function used to open dynamic libs. This attempts to > > > >>>> improve program security > > > >>>> * by removing the current directory from the dll search path. Only > > > >>>> dll's found in the > > > >>>> * executable or system directory are allowed to be loaded. > > > >>>> * @param name The dynamic lib name. > > > >>>> * @return A handle to the opened lib. > > > >>>> */ > > > >>> So ffmpeg prevents that solution on purpose. Or should that behavior > > > >>> be > > > >>> changed in the w32dlfcn.h? > > > >> > > > >> Oh, bummer. I would expect that overriding the PATH environment > > > >> variable would work kind of like how LD_LIBRARY_PATH works on Linux. I > > > >> don't know why that was changed. I don't really follow what goes on in > > > >> Windowsland anymore. Does anyone else care to comment on this? Martin, > > > >> maybe? > > > > > > > > IIRC this is done to prevent DLL injection attacks > > > > > > > > https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-security > > > > > > > > > > So what's your proposal how to continue? > > > > > > I see different options with pros&cons: > > > > > > > > > 1. > > > Read the DLL path from registry, function for that could be located > > > outside the VapourSynth module. > > > > > > Pro: Safest method to protect from DLL-injection > > > Con: A lot of custom code/functionality for Windows > > > > > > > Relaxing security considerations to avoid a 10 line function seems not > > worth it to me. So go with actually finding the correct path. > > I would prefer changing w32dlfcn.h to allow loading DLLs from PATH. > Limiting to only the directory of the executable and system32 seems > too excessive to me. Removing the current working directory is more > understandable, but it's perfectly fine to expect PATH to be searched. > This is common and largely expected DLL loading behavior on Windows. Changing that to avoid 10 lines of code is rather ill advised. - Hendrik ___ 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] libavformat/vapoursynth: Update to API version 4, load library at runtime
On Mon, Jul 22, 2024 at 2:43 AM Stefan Oltmanns via ffmpeg-devel wrote: > > Am 22.07.24 um 00:15 schrieb Hendrik Leppkes: > > On Mon, Jul 22, 2024 at 12:08 AM Stefan Oltmanns via ffmpeg-devel > > wrote: > >> > >> Am 18.07.24 um 17:23 schrieb epira...@gmail.com: > >>> > >>>>> > >>>>> Well, the DLL directory is added to PATH by the VapourSynth installer, > >>>>> but for safety reasons ffmpeg explictly tells the LoadLibrary function > >>>>> to only search the application directory and system32, quote from > >>>>> w32dlfcn.h: > >>>>> > >>>>>> /** > >>>>>>* Safe function used to open dynamic libs. This attempts to improve > >>>>>> program security > >>>>>>* by removing the current directory from the dll search path. Only > >>>>>> dll's found in the > >>>>>>* executable or system directory are allowed to be loaded. > >>>>>>* @param name The dynamic lib name. > >>>>>>* @return A handle to the opened lib. > >>>>>>*/ > >>>>> So ffmpeg prevents that solution on purpose. Or should that behavior be > >>>>> changed in the w32dlfcn.h? > >>>> > >>>> Oh, bummer. I would expect that overriding the PATH environment > >>>> variable would work kind of like how LD_LIBRARY_PATH works on Linux. I > >>>> don't know why that was changed. I don't really follow what goes on in > >>>> Windowsland anymore. Does anyone else care to comment on this? Martin, > >>>> maybe? > >>> > >>> IIRC this is done to prevent DLL injection attacks > >>> > >>> https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-security > >>> > >> > >> So what's your proposal how to continue? > >> > >> I see different options with pros&cons: > >> > >> > >> 1. > >> Read the DLL path from registry, function for that could be located > >> outside the VapourSynth module. > >> > >> Pro: Safest method to protect from DLL-injection > >> Con: A lot of custom code/functionality for Windows > >> > > > > Relaxing security considerations to avoid a 10 line function seems not > > worth it to me. So go with actually finding the correct path. > > > > Ok, should that function remain in the vapoursynth module, or should > handling the registry be done in a header like "compat/w32registry.h"? > > An external file with a universal function would of course require more > code. > Just have it in vapoursynth. Compat would be the wrong place for it, but in general I don't think we're going to need a lot of registry access in the future. - Hendrik ___ 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] libavformat/vapoursynth: Update to API version 4, load library at runtime
On Mon, Jul 22, 2024 at 12:08 AM Stefan Oltmanns via ffmpeg-devel wrote: > > Am 18.07.24 um 17:23 schrieb epira...@gmail.com: > > > >>> > >>> Well, the DLL directory is added to PATH by the VapourSynth installer, > >>> but for safety reasons ffmpeg explictly tells the LoadLibrary function > >>> to only search the application directory and system32, quote from > >>> w32dlfcn.h: > >>> > /** > * Safe function used to open dynamic libs. This attempts to improve > program security > * by removing the current directory from the dll search path. Only > dll's found in the > * executable or system directory are allowed to be loaded. > * @param name The dynamic lib name. > * @return A handle to the opened lib. > */ > >>> So ffmpeg prevents that solution on purpose. Or should that behavior be > >>> changed in the w32dlfcn.h? > >> > >> Oh, bummer. I would expect that overriding the PATH environment > >> variable would work kind of like how LD_LIBRARY_PATH works on Linux. I > >> don't know why that was changed. I don't really follow what goes on in > >> Windowsland anymore. Does anyone else care to comment on this? Martin, > >> maybe? > > > > IIRC this is done to prevent DLL injection attacks > > > > https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-security > > > > So what's your proposal how to continue? > > I see different options with pros&cons: > > > 1. > Read the DLL path from registry, function for that could be located > outside the VapourSynth module. > > Pro: Safest method to protect from DLL-injection > Con: A lot of custom code/functionality for Windows > Relaxing security considerations to avoid a 10 line function seems not worth it to me. So go with actually finding the correct path. - Hendrik ___ 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]] swscale modernization proposal
On Sat, Jul 6, 2024 at 6:42 PM Michael Niedermayer
wrote:
>
> On Sat, Jul 06, 2024 at 02:11:30AM +0200, Hendrik Leppkes wrote:
> > On Fri, Jul 5, 2024 at 11:34 PM Michael Niedermayer
> > wrote:
> > > > /**
> > > > * The exact interpretation of these quality presets depends on the
> > > > backend
> > > > * used, but the backend-invariant common settings are derived as
> > > > follows:
> > > > */
> > > > enum AVScaleQuality {
> > > > AV_SCALE_ULTRAFAST = 1, /* no dither, nearest+nearest */
> > > > AV_SCALE_SUPERFAST = 2, /* no dither, bilinear+nearest*/
> > > > AV_SCALE_VERYFAST = 3, /* no dither, bilinear+bilinear */
> > > > AV_SCALE_FASTER= 4, /* bayer dither, bilinear+bilinear */
> > > > AV_SCALE_FAST = 5, /* bayer dither, bicubic+bilinear*/
> > > > AV_SCALE_MEDIUM= 6, /* bayer dither, bicubic+bicubic */
> > > > AV_SCALE_SLOW = 7, /* bayer dither, lanczos+bicubic */
> > > > AV_SCALE_SLOWER= 8, /* full dither,lanczos+bicubic */
> > > > AV_SCALE_VERYSLOW = 9, /* full dither,lanczos+lanczos */
> > > > AV_SCALE_PLACEBO = 10, /* full dither,lanczos+lanczos */
> > >
> > > I dont think its a good idea to hardcode dither and the "FIR" filter to
> > > the quality level in the API
> > >
> >
> > The entire point of presets is to have them provide a predefined set
> > of parameters, easy for users to pick one value, rather than a bunch.
> > And what a preset actually means should be documented.
> > How do you define "presets" if they don't hardcode a list of choices
> > for all the relevant options?
> >
> > Advanced settings exist for a user to select any particular detail, if
> > they so desire.
>
> The problem is if new features are added and you have a hardcoded list in
> the API what each quality corresponds to change it you have to bump major
>
> also, do we really have or want to have optimized nearest neighbor scaler
> code ?
> If not the AV_SCALE_ULTRAFAST could be slower than AV_SCALE_VERYFAST
> simply because it now "has to" do something we actually have not optimized
>
So.. you object to the comments that explain what it does?
Someone that uses presets will never have a guarantee to the selected
algorithms and options, if thats your desire - set what you want. That
doesn't mean you can't inform users what they are at this time. Its a
comment indicating a behavior, we don't make any stability guarantees
about that, and no API linkage occurs.
- Hendrik
___
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]] swscale modernization proposal
On Fri, Jul 5, 2024 at 11:34 PM Michael Niedermayer
wrote:
> > /**
> > * The exact interpretation of these quality presets depends on the backend
> > * used, but the backend-invariant common settings are derived as follows:
> > */
> > enum AVScaleQuality {
> > AV_SCALE_ULTRAFAST = 1, /* no dither, nearest+nearest */
> > AV_SCALE_SUPERFAST = 2, /* no dither, bilinear+nearest*/
> > AV_SCALE_VERYFAST = 3, /* no dither, bilinear+bilinear */
> > AV_SCALE_FASTER= 4, /* bayer dither, bilinear+bilinear */
> > AV_SCALE_FAST = 5, /* bayer dither, bicubic+bilinear*/
> > AV_SCALE_MEDIUM= 6, /* bayer dither, bicubic+bicubic */
> > AV_SCALE_SLOW = 7, /* bayer dither, lanczos+bicubic */
> > AV_SCALE_SLOWER= 8, /* full dither,lanczos+bicubic */
> > AV_SCALE_VERYSLOW = 9, /* full dither,lanczos+lanczos */
> > AV_SCALE_PLACEBO = 10, /* full dither,lanczos+lanczos */
>
> I dont think its a good idea to hardcode dither and the "FIR" filter to the
> quality level in the API
>
The entire point of presets is to have them provide a predefined set
of parameters, easy for users to pick one value, rather than a bunch.
And what a preset actually means should be documented.
How do you define "presets" if they don't hardcode a list of choices
for all the relevant options?
Advanced settings exist for a user to select any particular detail, if
they so desire.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/avformat: Added codec_name to AVCodecContext and AVCodecParameters
On Wed, Jul 3, 2024 at 9:48 AM Bernardo Pilarz via ffmpeg-devel
wrote:
>
> Added the codec_name field, in which the unprocessed, not-interpreted codec
> name is stored.
> This is useful when codecs that are not handled by the libav
> (i.e. AV_CODEC_ID_NONE) are encountered, since the application might still
> want to handle them.
> Having this field allows the application to determine the codec type.
>
> As of this commit, the codec_name field is only filled when opening an RTSP
> stream, during the parsing of the SDP.
>
> Signed-off-by: bpilarz
> ---
> libavcodec/avcodec.h | 10 ++
> libavcodec/codec_par.c | 19 +++
> libavcodec/codec_par.h | 10 ++
> libavcodec/options.c | 1 +
> libavformat/rtsp.c | 5 +
> 5 files changed, 45 insertions(+)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 2da63c87ea..464b4078fc 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -451,6 +451,16 @@ typedef struct AVCodecContext {
> int log_level_offset;
>
> enum AVMediaType codec_type; /* see AVMEDIA_TYPE_xxx */
> +/**
> + * Generic codec name of the encoded data.
> + *
> + * Null-terminated string, can be NULL.
> + * Contents may vary depending on the source of the data stream.
> + * This is typically the string that's interpreted to determine
> 'codec_id'.
> + * Must be allocated with av_malloc() or av_strdup() and will be
> freed by
> + * avcodec_free_context().
> + */
> +char *codec_name;
> const struct AVCodec *codec;
> enum AVCodecID codec_id; /* see AV_CODEC_ID_xxx */
>
Adding a new field here is an ABI break, it would need to go at the
end of the struct.
In general, I feel like this might be better served to go into
metadata though, especially as very few containers have a string codec
identifier to begin with.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 2/2] lavc/hevcdec: Update slice index before hwaccel decode slice
On Mon, Jun 24, 2024 at 8:32 AM wrote:
>
> From: Fei Wang
>
> Otherwise, slice index will never update for hwaccel decode, and slice
> RPL will be always overlap into first one which use slice index to construct.
>
> Fixes hwaccel decoding after 47d34ba7fbb81
>
> Signed-off-by: Fei Wang
> ---
> 1. Update commit message.
>
> libavcodec/hevc/hevcdec.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
> index 39beb7e4dc..8bb564f1b3 100644
> --- a/libavcodec/hevc/hevcdec.c
> +++ b/libavcodec/hevc/hevcdec.c
> @@ -2770,6 +2770,9 @@ static int decode_slice_data(HEVCContext *s, const
> H2645NAL *nal, GetBitContext
> const HEVCPPS *pps = s->pps;
> int ret;
>
> +if (!s->sh.first_slice_in_pic_flag)
> +s->slice_idx += !s->sh.dependent_slice_segment_flag;
> +
> if (!s->sh.dependent_slice_segment_flag && s->sh.slice_type !=
> HEVC_SLICE_I) {
> ret = ff_hevc_slice_rpl(s);
> if (ret < 0) {
> @@ -2807,8 +2810,6 @@ static int decode_slice_data(HEVCContext *s, const
> H2645NAL *nal, GetBitContext
> s->local_ctx[0].tu.cu_qp_offset_cb = 0;
> s->local_ctx[0].tu.cu_qp_offset_cr = 0;
>
> -s->slice_idx += !s->sh.dependent_slice_segment_flag;
> -
> if (s->avctx->active_thread_type == FF_THREAD_SLICE &&
> s->sh.num_entry_point_offsets > 0&&
> pps->num_tile_rows == 1 && pps->num_tile_columns == 1)
> --
> 2.34.1
I can confirm that this set fixes hwaccel with slices, LGTM from me.
Hopefully Anton can also quickly look over it, its his changes
afterall.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/2] avutil/timestamp: introduce av_ts_make_time_string2 for better precision
On Sat, Mar 23, 2024 at 12:14 PM Marton Balint wrote:
> +char *av_ts_make_time_string2(char *buf, int64_t ts, AVRational tb)
> +{
> +if (ts == AV_NOPTS_VALUE) {
> +snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
> +} else {
> +double val = av_q2d(tb) * ts;
> +double log = floor(log10(fabs(val)));
This causes a floating point exception on some systems (div by zero)
if val ends up zero. Can we introduce a check to avoid the FPE?
log10(0) seems to be implementation defined, and may raise a FPE,
which we should avoid.
- Hendrik
___
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/executor: Allowing thread_count be zero
On Mon, Jun 17, 2024 at 10:03 AM Zhao Zhili wrote: > > > > > On Jun 17, 2024, at 15:05, Anton Khirnov wrote: > > > > Quoting Zhao Zhili (2024-06-17 07:19:26) > >> From: Zhao Zhili > >> > >> When thread_count be zero, it will be run on current thread like > >> !HAVE_THREADS. > > > > Other APIs treat zero to mean "auto". > > executor don’t detect cpu cores by itself. It’s more low level than > libavcodec. > > Zero thread is zero thread, literally. If we use thread_count one to mean > run on current thread, how to create a single thread then? Whats the point of creating a single thread? Does the main thread ever do something else in the meantime, or does it just wait for the job anyway? - Hendrik ___ 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] avformat/mpegts: correctly skip TP_extra_header in m2ts
On Fri, Jun 7, 2024 at 9:47 AM Hendrik Leppkes wrote: > > On Mon, May 27, 2024 at 3:47 PM llyyr wrote: > > > > instead of just resyncing and skipping a bunch of TS packets, leading to > > a loss of frames. > > > > Before this, a stray byte with the value of 0x47 in TP_extra_header > > would throw off the detection of where TS packets start. > > > > A typical file that could cause issues would look like this: > > > > 0300: 238f 4780 4750 1110 01e0 84c0 > >^^ ^^ > > The first four bytes here are TP_extra_header and the actual TS packet > > starts at offset 0x304 > > > > FFmpeg would try to read a packet at 0x300 but since nothing skips the > > 4 byte TP_extra_header, find that the first byte is not 0x47 and > > immediately go into mpegts_resync, and incorrectly detect the stray 0x47 > > in the TP_extra_header at 0x302 as the new sync byte. > > > > Fix this by correctly skipping the first 4 bytes if the source packet > > is 192 bytes. > > > > Signed-off-by: llyyr > > --- > > libavformat/mpegts.c | 12 +++- > > 1 file changed, 11 insertions(+), 1 deletion(-) > > > > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c > > index c66a1ea6ede0..0d80ad80f1aa 100644 > > --- a/libavformat/mpegts.c > > +++ b/libavformat/mpegts.c > > @@ -2944,6 +2944,12 @@ static int read_packet(AVFormatContext *s, uint8_t > > *buf, int raw_packet_size, > > AVIOContext *pb = s->pb; > > int len; > > > > +// 192 bytes source packet that start with a 4 bytes TP_extra_header > > +// followed by 188 bytes of TS packet. The sync byte is at offset 4, > > so skip > > +// the first 4 bytes otherwise we'll end up syncing to the wrong > > packet. > > +if (raw_packet_size == TS_DVHS_PACKET_SIZE) > > +avio_skip(pb, 4); > > + > > I think this doesn't work with mpegts_resync, since it always resyncs > for the packet start to be on the 0x47 marker, not 4 bytes before it. > So if sync is lost, it would never recover, if I read this right. > Since we're dealing with a special case for 192 byte packets here anyway, maybe a special case in mpegts_resync that just checks if raw size = 192 && [4] = 0x47 would handle this with less potential fallout? - Hendrik ___ 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] avformat/mpegts: correctly skip TP_extra_header in m2ts
On Mon, May 27, 2024 at 3:47 PM llyyr wrote: > > instead of just resyncing and skipping a bunch of TS packets, leading to > a loss of frames. > > Before this, a stray byte with the value of 0x47 in TP_extra_header > would throw off the detection of where TS packets start. > > A typical file that could cause issues would look like this: > > 0300: 238f 4780 4750 1110 01e0 84c0 >^^ ^^ > The first four bytes here are TP_extra_header and the actual TS packet > starts at offset 0x304 > > FFmpeg would try to read a packet at 0x300 but since nothing skips the > 4 byte TP_extra_header, find that the first byte is not 0x47 and > immediately go into mpegts_resync, and incorrectly detect the stray 0x47 > in the TP_extra_header at 0x302 as the new sync byte. > > Fix this by correctly skipping the first 4 bytes if the source packet > is 192 bytes. > > Signed-off-by: llyyr > --- > libavformat/mpegts.c | 12 +++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c > index c66a1ea6ede0..0d80ad80f1aa 100644 > --- a/libavformat/mpegts.c > +++ b/libavformat/mpegts.c > @@ -2944,6 +2944,12 @@ static int read_packet(AVFormatContext *s, uint8_t > *buf, int raw_packet_size, > AVIOContext *pb = s->pb; > int len; > > +// 192 bytes source packet that start with a 4 bytes TP_extra_header > +// followed by 188 bytes of TS packet. The sync byte is at offset 4, so > skip > +// the first 4 bytes otherwise we'll end up syncing to the wrong packet. > +if (raw_packet_size == TS_DVHS_PACKET_SIZE) > +avio_skip(pb, 4); > + I think this doesn't work with mpegts_resync, since it always resyncs for the packet start to be on the 0x47 marker, not 4 bytes before it. So if sync is lost, it would never recover, if I read this right. - Hendrik ___ 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/5] lavu/intmath.h: Fix UB in ff_ctz_c() and ff_ctzll_c()
On Thu, May 30, 2024 at 11:50 AM Tomas Härdin wrote: > > tor 2024-05-30 klockan 10:54 +0300 skrev Rémi Denis-Courmont: > > Can't we just use the compiler built-ins here? AFAIK, they (GCC, > > LLVM) use the same algorithm if the CPU doesn't support native CTZ. > > And they will pick the right instruction if CPU does have CTZ. > > > > I get it that maybe it wasn't working so well 20 years ago, but we've > > increased compiler version requirements since then. > > I think we still support MSVC, but maybe we shouldn't? It's possible to > cross-compile for Windows either way. > This is not going to happen. - Hendrik ___ 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] lavc/vp9: reset segmentation fields when segmentation isn't enabled
On Thu, May 23, 2024 at 10:38 AM wrote:
>
> From: llyyr
>
> Fields under the segmentation switch are never reset on a new frame, and
> retain the value from the previous frame. This bugs out a bunch of
> hwaccel drivers when segmentation is disabled but update_map isn't
> reset because they don't ignore values behind switches. This commit also
> resets the temporal field, though it may not be required.
>
> We also do this for vp8 [1] so this commit is just mirroring the vp8
> logic.
>
> This fixes an issue with certain samples [2] that causes blocky
> artifacts with vaapi, d3d11va and cuda (and possibly others).
> Mesa worked around [3] this by ignoring these fields if
> segmentation.enabled is 0, but d3d11va still displays blocky artifacts.
>
> [1] https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavcodec/vp8.c#l811
> [2] https://github.com/mpv-player/mpv/issues/13533
> [3] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27816
>
> Signed-off-by: llyyr
> ---
> libavcodec/vp9.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index 6e2d18bf9595..8ede2e2eb358 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -709,6 +709,12 @@ static int decode_frame_header(AVCodecContext *avctx,
> s->s.h.segmentation.feat[i].skip_enabled = get_bits1(&s->gb);
> }
> }
> +} else {
> +// Reset fields under segmentation switch if segmentation is
> disabled.
> +// This is necessary because some hwaccels don't ignore these fields
> +// if segmentation is disabled.
> +s->s.h.segmentation.temporal = 0;
> +s->s.h.segmentation.update_map = 0;
> }
>
> // set qmul[] based on Y/UV, AC/DC and segmentation Q idx deltas
> --
> 2.45.1
Last call for comments. Otherwise will apply on the weekend with the
updated Git URL.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/vp9: set update_map to 0 when segmentation.enabled is 0
On Wed, May 22, 2024 at 7:16 PM Lynne via ffmpeg-devel
wrote:
>
> On 22/05/2024 18:17, Philip Langdale via ffmpeg-devel wrote:
> > On Wed, 22 May 2024 11:10:31 -0400
> > "Ronald S. Bultje" wrote:
> >
> >> Hi,
> >>
> >> On Wed, May 22, 2024 at 10:36 AM Hendrik Leppkes
> >> wrote:
> >>
> >>> On Thu, Feb 29, 2024 at 7:19 AM llyyr wrote:
> >>>>
> >>>> segmentation.update_map is never reset to 0 on a new frame, and
> >>>> retains the value from the previous frame. This bugs out a bunch
> >>>> of hwaccel drivers when segmentation.enabled is 0 but update_map
> >>>> isn't because they don't ignore values behind switches. We also
> >>>> do this for vp8* so this commit is just mirroring the vp8 logic.
> >>>>
> >>>> This fixes an issue with certain samples** that causes blocky
> >>>> artifacts with vaapi and d3d11va (as far as known hwaccel drivers
> >>>> go). Mesa worked around*** this by ignoring this field if
> >>>> segmentation.enabled is 0, but d3d11va still doesn't work.
> >>>>
> >>>> *
> >>> https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavcodec/vp8.c#l811
> >>>
> >>>> ** https://github.com/mpv-player/mpv/issues/13533
> >>>> ***
> >>>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27816
> >>>>
> >>>> Signed-off-by: llyyr
> >>>> ---
> >>>> libavcodec/vp9.c | 2 ++
> >>>> 1 file changed, 2 insertions(+)
> >>>>
> >>>> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> >>>> index 855936cdc1c7..4a628625131e 100644
> >>>> --- a/libavcodec/vp9.c
> >>>> +++ b/libavcodec/vp9.c
> >>>> @@ -717,6 +717,8 @@ static int decode_frame_header(AVCodecContext
> >>>> *avctx, s->s.h.segmentation.feat[i].skip_enabled =
> >>> get_bits1(&s->gb);
> >>>> }
> >>>> }
> >>>> +} else {
> >>>> +s->s.h.segmentation.update_map = 0;
> >>>> }
> >>>>
> >>>> // set qmul[] based on Y/UV, AC/DC and segmentation Q idx
> >>>> deltas
> >>>>
> >>>> base-commit: d263fce2b209e86a5a1e8f1b6aa33430ecc2c187
> >>>> --
> >>>
> >>> Change LGTM.
> >>> I was debugging the same issue today, and found the same problem
> >>> with some hwaccels not properly ignoring update_map when
> >>> segmentation is disabled.
> >>>
> >>> Will apply soon if there are no further comments.
> >>>
> >>
> >> Is fine, please apply.
> >>
> >
> > Another LGTM. We've been seeing this reported on the mpv side as well.
> >
> > --phil
> > ___
> > 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".
>
> Can't this get fixed by hwaccel code rather than globally?
> I'd hate to apply fixes with no information in shared code. This can get
> removed with no information about what relies on it.
Changing 5 different hwaccel modules to avoid one line here seems
rather silly, doesn't it?
We can add a comment, if that helps.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/vp9: set update_map to 0 when segmentation.enabled is 0
On Thu, Feb 29, 2024 at 7:19 AM llyyr wrote:
>
> segmentation.update_map is never reset to 0 on a new frame, and retains
> the value from the previous frame. This bugs out a bunch of hwaccel
> drivers when segmentation.enabled is 0 but update_map isn't because
> they don't ignore values behind switches. We also do this for vp8* so
> this commit is just mirroring the vp8 logic.
>
> This fixes an issue with certain samples** that causes blocky
> artifacts with vaapi and d3d11va (as far as known hwaccel drivers go).
> Mesa worked around*** this by ignoring this field if
> segmentation.enabled is 0, but d3d11va still doesn't work.
>
> * https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavcodec/vp8.c#l811
> ** https://github.com/mpv-player/mpv/issues/13533
> *** https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27816
>
> Signed-off-by: llyyr
> ---
> libavcodec/vp9.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index 855936cdc1c7..4a628625131e 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -717,6 +717,8 @@ static int decode_frame_header(AVCodecContext *avctx,
> s->s.h.segmentation.feat[i].skip_enabled = get_bits1(&s->gb);
> }
> }
> +} else {
> +s->s.h.segmentation.update_map = 0;
> }
>
> // set qmul[] based on Y/UV, AC/DC and segmentation Q idx deltas
>
> base-commit: d263fce2b209e86a5a1e8f1b6aa33430ecc2c187
> --
Change LGTM.
I was debugging the same issue today, and found the same problem with
some hwaccels not properly ignoring update_map when segmentation is
disabled.
Will apply soon if there are no further comments.
- Hendrik
___
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 8/8] aacdec: add a decoder for AAC USAC (xHE-AAC)
On Tue, May 21, 2024 at 9:52 PM Lynne via ffmpeg-devel wrote: > > > It should be the case here, we shouldn't need reordering as NATIVE just > lets you specify what order the elements appear in the bitstream. NATIVE means "the FFmpeg native ordering", not "bitstream order". CUSTOM lets you specify an arbitrary order but requires metadata to that effect, but it makes it particularly hard to map to any standard when playing or transcoding, so some efforts to try to unify it into a NATIVE format is always appreciated if possible. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Always set ret before goto end
On Thu, May 2, 2024 at 10:22 AM Andreas Rheinhardt
wrote:
>
> Before 0f8763fbea4e8816cd54c2a481d4c048fec58394, av1_frame_ref()
> and update_reference_list() could fail and therefore needed to
> be checked, which incidentally set ret. This is no longer happening,
> leading to a potential use of an uninitialized value which is
> also the subject of Coverity ticket #1596605.
>
> Fix this by always setting ret before goto end; do not return
> some random ancient value.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/av1dec.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> index 79a30a114d..c3f255a29a 100644
> --- a/libavcodec/av1dec.c
> +++ b/libavcodec/av1dec.c
> @@ -1335,6 +1335,12 @@ static int av1_receive_frame_internal(AVCodecContext
> *avctx, AVFrame *frame)
> ret = set_output_frame(avctx, frame);
> if (ret < 0)
> av_log(avctx, AV_LOG_ERROR, "Set output frame
> error.\n");
> +} else {
> +// CBS checks for us that the frame to be shown actually
> existed
> +// in the bitstream; if it doesn't it could be e.g. due
> to
> +// skip_frame setting. Return EAGAIN to indicate that we
> are
> +// currently unable to produce output.
> +ret = AVERROR(EAGAIN);
> }
>
In the vein of this comment, set_output_frame will also return 0
without returning a frame in some cases - eg. with multiple layers.
Should this equally return EAGAIN rather than claiming success without
a frame?
- Hendrik
___
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] 5 year plan & Inovation
On Tue, Apr 30, 2024 at 8:49 PM Ondřej Fiala wrote: > > On Tue Apr 30, 2024 at 2:11 AM CEST, Hendrik Leppkes wrote: > > On Mon, Apr 29, 2024 at 6:44 PM Ondřej Fiala wrote: > > > > > > I would really suggest you look at SourceHut. > > > > While SourceHut might be a slight improvement over the current > > situation (and only slight), it being fundamentally still based on > > email makes it inherit a lot of limitations and problems, and the > > functionality of the web interface is severely lacking, as key > > functions like commenting on patches are relegated back to your email > > client. > I think that's sort of the point, that you don't need a modern web > browser to do code review. The web interface is meant to supplement > email in the process, not replace it. I will take the replacement instead, thanks. Email is archaic. The entire point is to get away from email, not dress it up. SourceHut usage would likely make me even less interested then today. - Hendrik ___ 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] 5 year plan & Inovation
On Mon, Apr 29, 2024 at 6:44 PM Ondřej Fiala wrote: > > I would really suggest you look at SourceHut. While SourceHut might be a slight improvement over the current situation (and only slight), it being fundamentally still based on email makes it inherit a lot of limitations and problems, and the functionality of the web interface is severely lacking, as key functions like commenting on patches are relegated back to your email client. Patch display functionality isn't any better then a mail client with a bit of syntax highlighting, nevermind bespoke review tools that are entirely absent, as it just sends you to your email client to respond. At least thats what I see when checking the SourceHut instance of SourceHut itself. As far as solutions go, this isn't one that I would imagine, I'm afraid. It's essentially a mailing list with patchwork. We have that now. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/libx264: bump minimum required version to 160
On Wed, Apr 10, 2024 at 3:19 PM Michael Niedermayer wrote: > > On Tue, Apr 09, 2024 at 02:53:28PM +0200, Niklas Haas wrote: > > On Sat, 06 Apr 2024 22:28:26 +0200 Michael Niedermayer > > wrote: > > > On Fri, Apr 05, 2024 at 07:44:52PM +0200, Niklas Haas wrote: > > > > From: Niklas Haas > > > > > > > > This version is four years old, and present in Debian oldstable, Ubuntu > > > > 22.04 and Leap 15.1. > > > > > > Ubuntu 20.04 has general support till 2025-05-29 > > > Ubuntu 18.04 has security support (ESM) till 2028-04 > > > > I'll relax it from 160 back down to version 155 then. That covers Ubuntu > > 20.04 and Debian oldoldstable. > > 18.04 has 152 > > libx264-dev/bionic,now 2:0.152.2854+gite9a5903-2 amd64 [installed] > > Ubuntu 18.04 still has security support in ESM and ubuntu pro IIUC till > 2028-04 > Then they can use security updates from old release branches. The assumption that people will run Git ffmpeg but distribution provided x264 seems flawed. They can update dependencies that are important for them. The distribution itself is certainly never going to update. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fix typo(1),style(1),nit(4) issue
On Wed, Apr 3, 2024 at 10:50 AM 정지우 | Eugene wrote:
>
> - typo(1) : Line 242 : RFIC7616 ->RFC7616
> - style(1) : make_digest_auth() , make_digest_auth_sha() : A1hash-> a1_hash
> and A2hash -> a2_hash
> - nit(3) : httpauth.c: Line 245,265,389:
> - nit(1) : httpauth.h: Line 85
>
> Signed-off-by: Eugene-bitsensing
>
> @@ -386,7 +386,7 @@ char *ff_http_auth_create_response(HTTPAuthState *state,
> const char *auth,
> if ((password = strchr(username, ':'))) {
> *password++ = 0;
> /* add digest algorithm SHA-256 */
> -if (!strcmp(state->digest_params.algorithm, "SHA-256")) {
> +if (!strcmp(state->digest_params.algorithm, "SHA256")) {
This is not a "nit", "SHA-256" with a dash is how RFC 7616 specifies
the algorithm token to be spelled.
> authstr = make_digest_auth_sha(state, username, password,
> path, method,"SHA256");
> } else {
> authstr = make_digest_auth(state, username, password, path,
> method);
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
On Thu, Mar 28, 2024 at 10:12 AM wrote: > > From: Tong Wu > > HEVCHdrParams* receives a pointer which points to a dynamically > allocated memory block. It causes the memcmp always returning 1. > Add a function to do the comparision. A condition is also added to > avoid malloc(0). > > Signed-off-by: Tong Wu I've been looking into some playback glitches after 456c8ebe7c7dcd766d36cd0296815d89fd1166b5 and I can confirm that this patch fixes those as well. Using the fixed position of the *hdr member and its offset seems a bit icky though, and _at least_ could use a comment so future changes keep it last. - Hendrik ___ 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] Remove struct named initializer from aac profile option.
On Tue, Mar 26, 2024 at 9:42 AM Muiz Yusuff wrote: > > From: Muiz > > All fields of the stuct use unnamed struct initialization. > Also omit the field name for `AVOption::unit` to maintain consistency. "unit" intentionally uses designated initializers, so that adding new fields before it is more robust and less prone to errors. See 1e7d2007c3aca1cc1cd3b1ca409f4ded6c885f86 - Hendrik ___ 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] Add support d3d11va Intel Hevc Rext decoder.
On Sun, Feb 25, 2024 at 11:36 AM Mark Thompson wrote: > > On 25/02/2024 02:22, Водянников А.В. via ffmpeg-devel wrote: > > From ed8fda62bbdbc62f7565891c935966c931d001ca Mon Sep 17 00:00:00 2001 > > From: Aleksoid > > Date: Thu, 22 Feb 2024 19:15:48 +1000 > > Subject: [PATCH 1/2] Add support d3d11va Intel Hevc Rext decoder. > > > > Signed-off-by: Aleksoid > > --- > > libavcodec/d3d12va_hevc.c | 2 +- > > libavcodec/dxva2.c| 68 +-- > > libavcodec/dxva2_hevc.c | 41 ++--- > > libavcodec/dxva2_internal.h | 38 +++- > > libavcodec/hevcdec.c | 16 + > > libavutil/hwcontext_d3d11va.c | 26 +++--- > > 6 files changed, 178 insertions(+), 13 deletions(-) > > What elements are Intel-specific about this? > > Presumably there will be an official rext mode for D3D in future; are there > any possible problems with having this vendor extension in that case? > The next Windows SDK is presumably supposed to contain RExt support, but so far only partial information is present in the pre-release SDKs. It might be wise to wait for that. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket
On Mon, Feb 19, 2024 at 12:44 AM Marton Balint wrote: > > > > On Fri, 16 Feb 2024, Anton Khirnov wrote: > > > Quoting Tomas Härdin (2024-02-03 20:58:20) > >> I think people with knowledge how interlacing is handled in other > >> formats and codecs might want to chime in. > > > > For MPEG codecs our decoders always output (properly signalled) > > interlaced content as two interleaved fields in a single AVFrame flagged > > with AV_FRAME_FLAG_INTERLACED. Its height is the height of the whole > > frame, so double the number of lines in each field. > > > > So IIUC this patch is taking the correct approach. > > I believe interlaced HEVC has the same issue, the decoder generates field > pictures and not frames. Would changing the HEVC decoder be acceptable to > generate frames with interleaved fields? > Absolutely. There have been WIP patches in the past that tried to do this, but resorting to memcpy instead of updating the decoder to write to every second line, and that should of course be avoided. HEVC also has HWAccel, which should work as well in the same manner, if possible. - Hendrik ___ 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] avcodec/s302m: enable non-PCM decoding
On Sun, Feb 18, 2024 at 11:34 PM Michael Niedermayer wrote: > > * A disagreement implies that there are 2 parties > * And we assume here that what one party wants is better for FFmpeg than what > the other wants. > * The TC needs to find out which partys choice is better or suggest a 3rd > choice. > * If one but not the other party is a member of the TC then this decission > becomes biased if that member votes > > Your interpretation suggests that the TC members are "above" everyone and > should > prevail in arguments they have with others. > Noone is above the rules, but just because someone has an opinion and shared it shouldn't disqualify them, because they were specifically voted into the TC for their opinions on technical matters. Would their opinion, and therefore their vote, change if someone else was seen as the person "blocking"? What if multiple people had expressed disagreement with a patch, and most of the TC was involved in the public discussion already? Do the remaining "uninvolved" people on the TC get all the decision power? Or do we consider most of the TC already opposing it publicly as perhaps an indicator that the patch might not be the way to go? Thats what the TC was voted in for, to give their opinion on technical matters and decide if needed, so why deprive them of their opinion, just because they already stated it publicly? That makes no sense to me. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/assenc: normalize line endings to \n
On Mon, Feb 12, 2024 at 11:22 AM Martin Storsjö wrote: > > > > diff --git a/.gitattributes b/.gitattributes > > index 5a19b963b6..a900528e47 100644 > > --- a/.gitattributes > > +++ b/.gitattributes > > @@ -1,2 +1 @@ > > *.pnm -diff -text > > -tests/ref/fate/sub-scc eol=crlf > > This change seems to have had a tricky effect on the > tests/ref/fate/sub-scc file. Previously, when checked out, users got the > file with CRLF newlines. When updating to this git commit, or past it, > that file remains untouched, with CRLF still present, and the > fate-sub-scc test fails. If one does "rm tests/ref/fate/sub-scc; git > checkout tests/ref/fate/sub-scc", then the file does get restored with LR > newlines, and the test passes. > > It's easy to do this change manually in the source checkout of a fate > runner, but I'm not sure how easily we get all fate instances fixed that > way - currently this test is failing in most of them. > Can this be fixed by restoring the .gitattribute entry but with eol=lf? Not sure if Git would reset the file then. - Hendrik ___ 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 v9 13/13] vvcdec: add vvc decoder
On Mon, Jan 1, 2024 at 3:54 PM Lynne wrote: > > Jan 1, 2024, 15:16 by nuomi2...@gmail.com: > > > vvc decoder plug-in to avcodec. > > split frames into slices/tiles and send them to vvc_thread for further > > decoding > > reorder and wait for the frame decoding to be done and output the frame > > > > Features: > > + Support I, P, B frames > > + Support 8/10/12 bits, chroma 400, 420, 422, and 444 and range extension > > + Support VVC new tools like MIP, CCLM, AFFINE, GPM, DMVR, PROF, BDOF, > > LMCS, ALF > > + 295 conformace clips passed > > - Not support RPR, IBC, PALETTE, and other minor features yet > > > > IBC == Intra-block copy? > Palette == palette (screen content) coding? Yes; Both IBC and PALETTE modes are alternate block coding modes, with these two primarily optimized for screen content. - Hendrik ___ 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/decode: guard against NULL hw_frames_ctx
On Fri, Nov 17, 2023 at 6:04 PM Dmitry Rogozhkin
wrote:
>
> Guard against segfault running VLC decoding under msys2 [1]:
>
> Thread 33 received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 37728.0xadd0]
> ff_hwaccel_frame_priv_alloc (avctx=0x6447b00,
> hwaccel_picture_private=0x65dfd00)
> at libavcodec/decode.c:1848
> 1848frames_ctx = (AVHWFramesContext *)avctx->hw_frames_ctx->data;
> (gdb) bt
> at libavcodec/decode.c:1848
> at libavcodec/h264_slice.c:208
> first_slice=1) at libavcodec/h264_slice.c:1599
> at libavcodec/h264_slice.c:2130
> at libavcodec/h264dec.c:652
> got_frame=0x646e4b0, avpkt=0x64522c0) at libavcodec/h264dec.c:1048
>
> (gdb) p avctx
> $1 = (AVCodecContext *) 0x6447b00
> (gdb) p avctx->hw_frames_ctx
> $2 = (AVBufferRef *) 0x0
>
> v2: check for free_frame_priv (Hendrik)
> v3: return EINVAL (Christoph Reiter)
>
> See[1]: https://github.com/msys2/MINGW-packages/pull/19050
> Fixes: be07145109 ("avcodec: add AVHWAccel.free_frame_priv callback")
> CC: Lynne
> CC: Christoph Reiter
> Signed-off-by: Dmitry Rogozhkin
> ---
The latest change itself looks fine to me, I would however prefer if
the commit message would contain a bit more text and a bit less gdb
dump.
Maybe something like this (quick suggestion, for title and body):
avcodec: validate hw_frames_ctx is available when
AVHWAccel.free_frame_priv is used
Validate that a hw_frames_ctx is available before using it for the
AVHWAccel.free_frame_priv callback, and don't require it to be present when
the callback is not in use by the HWAccel.
---
Feel free to augment and reword, but I don't think the gdb dump offers
much info that couldn't be conveyed more clearly in a few words that
mention the absence of hw_frame_ctx.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/decode: guard against NULL hw_frames_ctx
On Tue, Nov 14, 2023 at 7:23 PM Dmitry Rogozhkin
wrote:
>
> Gurd against segfault running VLC decoding under msys2 [1]:
>
> Thread 33 received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 37728.0xadd0]
> ff_hwaccel_frame_priv_alloc (avctx=0x6447b00,
> hwaccel_picture_private=0x65dfd00)
> at libavcodec/decode.c:1848
> 1848frames_ctx = (AVHWFramesContext *)avctx->hw_frames_ctx->data;
> (gdb) bt
> at libavcodec/decode.c:1848
> at libavcodec/h264_slice.c:208
> first_slice=1) at libavcodec/h264_slice.c:1599
> at libavcodec/h264_slice.c:2130
> at libavcodec/h264dec.c:652
> got_frame=0x646e4b0, avpkt=0x64522c0) at libavcodec/h264dec.c:1048
>
> (gdb) p avctx
> $1 = (AVCodecContext *) 0x6447b00
> (gdb) p avctx->hw_frames_ctx
> $2 = (AVBufferRef *) 0x0
>
> See[1]: https://github.com/msys2/MINGW-packages/pull/19050
> Fixes: be07145109 ("avcodec: add AVHWAccel.free_frame_priv callback")
> CC: Lynne
> CC: Christoph Reiter
> Signed-off-by: Dmitry Rogozhkin
> ---
> libavcodec/decode.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index ad39021..3caaeec 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1845,9 +1845,9 @@ int ff_hwaccel_frame_priv_alloc(AVCodecContext *avctx,
> void **hwaccel_picture_pr
>
> av_assert0(!*hwaccel_picture_private);
>
> -frames_ctx = (AVHWFramesContext *)avctx->hw_frames_ctx->data;
> +frames_ctx = (AVHWFramesContext *) avctx->hw_frames_ctx ?
> avctx->hw_frames_ctx->data : NULL;
> *hwaccel_picture_private =
> ff_refstruct_alloc_ext(hwaccel->frame_priv_data_size, 0,
> - frames_ctx->device_ctx,
> + frames_ctx ?
> frames_ctx->device_ctx : NULL,
>
> hwaccel->free_frame_priv);
The free_frame_priv callback is not usable when no context is
available. The code should be updated to check if the hwaccel has a
free_frame_priv callback and then require a frames_ctx to be set and
otherwise error out (instead of crashing), and if free_frame_priv is
not set, then it can allocate a buffer without these requirements.
- Hendrik
___
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/6] avcodec/h264: keep track of which frames used gray references
On Tue, Nov 14, 2023 at 6:21 PM Michael Niedermayer
wrote:
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/h264_picture.c | 1 +
> libavcodec/h264_slice.c | 19 ++-
> libavcodec/h264dec.c | 1 +
> libavcodec/h264dec.h | 4
> 4 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
> index 691c61eea23..3234141dbd6 100644
> --- a/libavcodec/h264_picture.c
> +++ b/libavcodec/h264_picture.c
> @@ -96,6 +96,7 @@ static void h264_copy_picture_params(H264Picture *dst,
> const H264Picture *src)
> dst->field_picture = src->field_picture;
> dst->reference = src->reference;
> dst->recovered = src->recovered;
> +dst->gray = src->gray;
> dst->invalid_gap = src->invalid_gap;
> dst->sei_recovery_frame_cnt = src->sei_recovery_frame_cnt;
> dst->mb_width = src->mb_width;
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index 4861a2cabba..2c4ab89dae1 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -457,6 +457,7 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
> h->poc.prev_frame_num= h->poc.frame_num;
>
> h->recovery_frame= h1->recovery_frame;
> +h->non_gray = h1->non_gray;
>
> return err;
> }
> @@ -1544,11 +1545,14 @@ static int h264_field_start(H264Context *h, const
> H264SliceContext *sl,
> if (ret < 0)
> return ret;
> h->short_ref[0]->poc = prev->poc + 2U;
> +h->short_ref[0]->gray = prev->gray;
> ff_thread_report_progress(&h->short_ref[0]->tf, INT_MAX, 0);
> if (h->short_ref[0]->field_picture)
> ff_thread_report_progress(&h->short_ref[0]->tf, INT_MAX,
> 1);
> -} else if (!h->frame_recovered && !h->avctx->hwaccel)
> +} else if (!h->frame_recovered && !h->avctx->hwaccel) {
> color_frame(h->short_ref[0]->f, c);
> +h->short_ref[0]->gray = 1;
> +}
While we can't color invalid frames for hwaccels easily, the flag
should perhaps still be applied, as they are equally invalid.
Thinking about this, maybe the name should be less the color we
happened to use for it, and more like "placeholder" or "invalid" or
anything like that?
> h->short_ref[0]->frame_num = h->poc.prev_frame_num;
> }
> }
> @@ -2007,6 +2011,19 @@ static int h264_slice_init(H264Context *h,
> H264SliceContext *sl,
> (sl->ref_list[j][i].reference & 3);
> }
>
> +if (sl->slice_type_nos == AV_PICTURE_TYPE_I) {
> +h->cur_pic_ptr->gray = 0;
> +h->non_gray = 1;
> +} else {
> +int gray = 0;
> +for (j = 0; j < sl->list_count; j++) {
> +for (i = 0; i < sl->ref_count[j]; i++) {
> +gray |= sl->ref_list[j][i].parent->gray;
> +}
> +}
> +h->cur_pic_ptr->gray = gray;
> +}
> +
> if (h->avctx->debug & FF_DEBUG_PICT_INFO) {
> av_log(h->avctx, AV_LOG_DEBUG,
> "slice:%d %c mb:%d %c%s%s frame:%d poc:%d/%d ref:%d/%d qp:%d
> loop:%d:%d:%d weight:%d%s %s\n",
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index ef9e60bbf33..7ea55db75dd 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -492,6 +492,7 @@ static void h264_decode_flush(AVCodecContext *avctx)
> ff_h264_unref_picture(&h->cur_pic);
>
> h->mb_y = 0;
> +h->non_gray = 0;
>
> ff_h264_free_tables(h);
> h->context_initialized = 0;
> diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
> index ede51951727..366626c056c 100644
> --- a/libavcodec/h264dec.h
> +++ b/libavcodec/h264dec.h
> @@ -154,6 +154,8 @@ typedef struct H264Picture {
>
> /// RefStruct reference; its pointee is shared between decoding threads.
> atomic_int *decode_error_flags;
> +
> +int gray;
> } H264Picture;
>
> typedef struct H264Ref {
> @@ -567,6 +569,8 @@ typedef struct H264Context {
> struct FFRefStructPool *ref_index_pool;
> struct FFRefStructPool *decode_error_flags_pool;
> int ref2frm[MAX_SLICES][2][64]; ///< reference to frame number
> lists, used in the loop filter, the first 2 are for -2,-1
> +
> +int non_gray; ///< Did we encounter a intra frame
> after a gray gap frame
> } H264Context;
>
> extern const uint16_t ff_h264_mb_sizes[4];
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above,
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
On Thu, Nov 9, 2023 at 1:24 PM James Almer wrote: > > On 11/9/2023 9:21 AM, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2023-11-09 12:55:25) > >> On Thu, Nov 09, 2023 at 10:44:12AM +0100, Anton Khirnov wrote: > >>> As nobody expressed a preference, the vote will start next Monday > >>> (2023-11-13). It should run for a week, and will be followed by TC/CC > >>> elections. > >>> > >>> The only extra GA candidate I see proposed so far is Ronald. If anyone > >>> wants to suggest further people, please do so in this thread ASAP. > >> > >> IMHO the question of the relation of the list of people who could vote > >> in the last GA vote and the people who where in the general assembly > >> in 2020 should be awnsered before further votes. > >> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316609.html > > > > As far as I can tell, the voter list in the last vote should be the same > > as the GA from 2020, except for the extra members whose voting rights > > expire after 2 years. > > > > Do you dispute that? > > > >> If the current GA stays as it is, then i propose the following people > >> (this list was quickly made and certainly has omisions and possibly errors, > >> check anything thats important to you!) > >> > >> The presumed 2020 General assembly as well as people who have subtantial > >> contributions over the lifetime of the project where the source of this > >> list > > > >> Ting Fu(last active in April 2023, 24 commits in 2021-2023, ) > > > > He actually is in the GA, but his Intel mailbox bounces. > > > >> Fabrice Bellard(Founder of the project over 600 commits in FFmpeg) > >> Aman Karmani (17 authored commits in 2020-2023, recently active in > >> 2023-June and work all over the codebase) > >> Baptiste Coudurier (Pays for our fate server since forever, maintains 15 > >> things in MAINTAINERs, is the the copyright of 56 files, over 1900 commits > >> in FFmpeg) > >> Moritz Barsnick(Member of the 2020 GA but was not on jbs list) > >> Lauri Kasanen (Linux / PowerPC maintainer) > >> Dale Curtis(14 commits in 2020 was in the 2020-GA) > >> Alexander Strasser (Root admin, just recently reported that he could not > >> vote even though he was in teh 2020-GA, 3 things in MAINTAINERs) > >> foo86 (maintainer and author of dca*, dolby_e*, dtsdec, s337m) > >> Huiwen Ren (8 matches in the codebase of his name, avs2* and > >> related things maintainer) > >> Martin Vignali (over 200 commits in FFmpeg, left in 2019 because of > >> hostility) > >> Lou Logan (over 100 commits in FFmpeg, left in 2020, also in the > >> 2020-GA but not on jbs list) > >> Matthieu Bouron(over 200 commits in FFmpeg, recently active in 2022, 5 > >> entries in MAINTAINERs, 25 in copyrights) > >> Ruiling Song (vf_tonemap_opencl maintainer, added SIMD code to > >> various bits of code, last active in git in 2020) > >> John Stebbins (over 100 commits in FFmpeg, last active in git in > >> 2020, 1 copyright match) > >> Tobias Rapp(vf_readvitc mainatiner, last commit in Jul 2023, 88 > >> commits in FFmpeg) > >> Shiyou Yin (MIPS & LoongArch maintainer, 24 matches for his name > >> in the source, last commit May 2023) > >> Reimar Döffinger (over 1400 commits in FFmpeg, root admin and last > >> commit in Oct 2023, 49 matches for his name in the codebase) > >> Aurelien Jacobs(over 1000 commits in FFmpeg, 13 entries in > >> MAINTAINERs, 70 copyright line matches) > >> Hendrik Leppkes(over 900 commits in FFmpeg, 2 entries in MAINTAINERs, > >> 4 copyrights, last commit in Jul 2023) > >> Vitor Sessak (over 900 commits in FFmpeg, 28 copyright matches) > >> Kostya Shishkov(over 900 commits in FFmpeg, 162 copyright matches) > >> Ramiro Polla (over 600 commits in FFmpeg, 5 matches in MAINTAINERs, > >> 22 copyright matches) > >> Alex Converse (over 500 commits in FFmpeg, 32 copyright matches) > >> Janne Grunau (over 500 commits in FFmpeg, 24 copyright matches) > >> Andreas Cadhalpun (over 400 commits in FFmpeg, 2 copyright matches) > > > > Sending voting emails to people who have not had any contact with the > > project for years, can be regarded as spamming. I think there should be > > some confirmation that these peop
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
On Thu, Nov 9, 2023 at 6:04 PM Rémi Denis-Courmont wrote: > > Le torstaina 9. marraskuuta 2023, 18.50.52 EET Michael Niedermayer a écrit : > > that said, i checked ML subscribers and found > > 16 of the people above to be currently subscribed with email addresses > > that i found by greping their name. (not posting the list due to privacy > > concerns) > > Thing is, if they are subscribed and still don't ask to be added to the GA, I > don't think they should be "volunteered" by someone else. They are of course > welcome to apply. > I don't see the big difference here for people that meet an arbitrary commit threshold, they get automatically added and not asked, but if you are slightly under you don't. By that logic, everyone should step forward and not be "volunteered" by a script of all things. - Hendrik ___ 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] financial sustainability Plan A (SPI)
On Tue, Oct 31, 2023 at 6:31 PM Michael Niedermayer wrote: > > On Tue, Oct 31, 2023 at 07:19:41PM +0200, Rémi Denis-Courmont wrote: > > Le tiistaina 31. lokakuuta 2023, 18.58.57 EET Michael Niedermayer a écrit : > > > > That's not a credible solution for a library. All reverse dependency > > > > developers would disable that before they ship affected FFmpeg versions, > > > > or worse, just stop updating their vendored FFmpeg. > > > > > > If its announced and we point to the commit, maybe half the minor users > > > will remove it, maybe most of the bigger ones. If its not announced > > > noone would remove it. companies do not audit the FFmpeg commits. > > > They would remove it after seeing it but at that point it did what it > > > intended to to, inform users again, like i said thats hypothetical and > > > controversal. But basically doing the same as companies which put > > > advertisements in without asking either creator nor viewer. > > > > How do you show ads without a GUI? Hijack the video signal from the decoder? > > In this very very hypothetical idea ... > it would not be a add, but a simple information box shown briefly that says > something like "decoded with ffmpeg.org, donate if you enjoy" / "encoded with > ffmpeg.org, donate if you enjoy" > If as a professional user of a decoder library, it starts putting in an ad or a watermark or whatever you want to call it, even if briefly, i'm looking for a new decoder library, or will venture to remove the message instantly. And if that wasn't enough to completely destroy the projects reputation, if you then try to hide it by randomizing or whatever, so that testing before deployment doesn't see it, that definitely will. This is not acceptable behavior for a decoder. And no "exposure" due to bad press will actually yield you a benefit. Companies won't pay you, because that doesn't get rid of the message. They'll pay an engineer to disable it. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avutil/channel_layout: rename 7.1(top) channel layout to 5.1.2
On Tue, Oct 24, 2023 at 1:57 AM James Almer wrote:
>
> On 10/23/2023 8:49 PM, Hendrik Leppkes wrote:
> > On Tue, Oct 24, 2023 at 1:46 AM Hendrik Leppkes wrote:
> >>
> >> On Tue, Oct 24, 2023 at 1:24 AM James Almer wrote:
> >>>
> >>> This layout maps to ITU-R BS.2051-3 "Sound System C" and ITU-R BS.1196-8
> >>> "Channel
> >>> Configuration 14", and it being the first layout with top layer channels,
> >>> it's
> >>> best to use a different scheme to properly convey the presence and amount
> >>> of said
> >>> channels.
> >>> The new name will also be a better fit for the additions in the following
> >>> commits.
> >>>
> >>> Signed-off-by: James Almer
> >>> ---
> >>> diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
> >>> index ac2ddfa022..8c40c81b44 100644
> >>> --- a/libavutil/channel_layout.h
> >>> +++ b/libavutil/channel_layout.h
> >>> @@ -232,13 +232,15 @@ enum AVChannelOrder {
> >>> #define AV_CH_LAYOUT_7POINT1
> >>> (AV_CH_LAYOUT_5POINT1|AV_CH_BACK_LEFT|AV_CH_BACK_RIGHT)
> >>> #define AV_CH_LAYOUT_7POINT1_WIDE
> >>> (AV_CH_LAYOUT_5POINT1|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
> >>> #define AV_CH_LAYOUT_7POINT1_WIDE_BACK
> >>> (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
> >>> -#define AV_CH_LAYOUT_7POINT1_TOP_BACK
> >>> (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
> >>> +#define AV_CH_LAYOUT_5POINT1POINT2
> >>> (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
> >>
> >> Looking at the specs and the naming of the thing, I don't think it
> >> should be using AV_CH_LAYOUT_5POINT1_BACK as the base layer, but
> >> rather AV_CH_LAYOUT_5POINT1. "5.1" is that, and 5.1.2 should extend
> >> that, and not swap the base layer speakers.
> >> Looking at the specifications, they don't map properly to our speaker
> >> definitions, as they assign it a generic "surround" title (at 100-120
> >> degrees azimuth), while a rear/back speaker should be at 135 degrees,
> >> and a side speaker at 90 (as is the standard for 7.1 setups).
> >>
> >> Yes, this doesn't match the one you are renaming, but I think
> >> consistency within our own defined formats is important here. 5.1 ->
> >> 5.1.2 should just add two.
> >>
> >> The renamed one could be 5.1.2(back) or whatever we want to name those.
> >>
> >> Or we do it properly and actually include a proper "surround" speaker
> >> definition and get rid of the confusion between side and back. But
> >> that breaks compat with WAVEFORMATEXTENSIBLE that our channel
> >> definitions are mostly sourced from, so might not be worth it.
> >
> > Actually I got confused by our terrible naming. The define
> > AV_CHANNEL_LAYOUT_5POINT1 maps to "5.1(side)", but the define
> > AV_CHANNEL_LAYOUT_5POINT1_BACK maps to "5.1"? What is up with that?
> > Regardless, rather see consistency within those as well, so while the
> > name of the format is fine, rename the define to include the _BACK
> > maybe?
>
> Yes, it's a mess.
>
> Do i use "5.1.2" alongside AV_CH_LAYOUT_5POINT1POINT2_BACK, then?
That works for me.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avutil/channel_layout: rename 7.1(top) channel layout to 5.1.2
On Tue, Oct 24, 2023 at 1:46 AM Hendrik Leppkes wrote:
>
> On Tue, Oct 24, 2023 at 1:24 AM James Almer wrote:
> >
> > This layout maps to ITU-R BS.2051-3 "Sound System C" and ITU-R BS.1196-8
> > "Channel
> > Configuration 14", and it being the first layout with top layer channels,
> > it's
> > best to use a different scheme to properly convey the presence and amount
> > of said
> > channels.
> > The new name will also be a better fit for the additions in the following
> > commits.
> >
> > Signed-off-by: James Almer
> > ---
> > diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
> > index ac2ddfa022..8c40c81b44 100644
> > --- a/libavutil/channel_layout.h
> > +++ b/libavutil/channel_layout.h
> > @@ -232,13 +232,15 @@ enum AVChannelOrder {
> > #define AV_CH_LAYOUT_7POINT1
> > (AV_CH_LAYOUT_5POINT1|AV_CH_BACK_LEFT|AV_CH_BACK_RIGHT)
> > #define AV_CH_LAYOUT_7POINT1_WIDE
> > (AV_CH_LAYOUT_5POINT1|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
> > #define AV_CH_LAYOUT_7POINT1_WIDE_BACK
> > (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
> > -#define AV_CH_LAYOUT_7POINT1_TOP_BACK
> > (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
> > +#define AV_CH_LAYOUT_5POINT1POINT2
> > (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
>
> Looking at the specs and the naming of the thing, I don't think it
> should be using AV_CH_LAYOUT_5POINT1_BACK as the base layer, but
> rather AV_CH_LAYOUT_5POINT1. "5.1" is that, and 5.1.2 should extend
> that, and not swap the base layer speakers.
> Looking at the specifications, they don't map properly to our speaker
> definitions, as they assign it a generic "surround" title (at 100-120
> degrees azimuth), while a rear/back speaker should be at 135 degrees,
> and a side speaker at 90 (as is the standard for 7.1 setups).
>
> Yes, this doesn't match the one you are renaming, but I think
> consistency within our own defined formats is important here. 5.1 ->
> 5.1.2 should just add two.
>
> The renamed one could be 5.1.2(back) or whatever we want to name those.
>
> Or we do it properly and actually include a proper "surround" speaker
> definition and get rid of the confusion between side and back. But
> that breaks compat with WAVEFORMATEXTENSIBLE that our channel
> definitions are mostly sourced from, so might not be worth it.
Actually I got confused by our terrible naming. The define
AV_CHANNEL_LAYOUT_5POINT1 maps to "5.1(side)", but the define
AV_CHANNEL_LAYOUT_5POINT1_BACK maps to "5.1"? What is up with that?
Regardless, rather see consistency within those as well, so while the
name of the format is fine, rename the define to include the _BACK
maybe?
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avutil/channel_layout: rename 7.1(top) channel layout to 5.1.2
On Tue, Oct 24, 2023 at 1:24 AM James Almer wrote:
>
> This layout maps to ITU-R BS.2051-3 "Sound System C" and ITU-R BS.1196-8
> "Channel
> Configuration 14", and it being the first layout with top layer channels, it's
> best to use a different scheme to properly convey the presence and amount of
> said
> channels.
> The new name will also be a better fit for the additions in the following
> commits.
>
> Signed-off-by: James Almer
> ---
> diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
> index ac2ddfa022..8c40c81b44 100644
> --- a/libavutil/channel_layout.h
> +++ b/libavutil/channel_layout.h
> @@ -232,13 +232,15 @@ enum AVChannelOrder {
> #define AV_CH_LAYOUT_7POINT1
> (AV_CH_LAYOUT_5POINT1|AV_CH_BACK_LEFT|AV_CH_BACK_RIGHT)
> #define AV_CH_LAYOUT_7POINT1_WIDE
> (AV_CH_LAYOUT_5POINT1|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
> #define AV_CH_LAYOUT_7POINT1_WIDE_BACK
> (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
> -#define AV_CH_LAYOUT_7POINT1_TOP_BACK
> (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
> +#define AV_CH_LAYOUT_5POINT1POINT2
> (AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
Looking at the specs and the naming of the thing, I don't think it
should be using AV_CH_LAYOUT_5POINT1_BACK as the base layer, but
rather AV_CH_LAYOUT_5POINT1. "5.1" is that, and 5.1.2 should extend
that, and not swap the base layer speakers.
Looking at the specifications, they don't map properly to our speaker
definitions, as they assign it a generic "surround" title (at 100-120
degrees azimuth), while a rear/back speaker should be at 135 degrees,
and a side speaker at 90 (as is the standard for 7.1 setups).
Yes, this doesn't match the one you are renaming, but I think
consistency within our own defined formats is important here. 5.1 ->
5.1.2 should just add two.
The renamed one could be 5.1.2(back) or whatever we want to name those.
Or we do it properly and actually include a proper "surround" speaker
definition and get rid of the confusion between side and back. But
that breaks compat with WAVEFORMATEXTENSIBLE that our channel
definitions are mostly sourced from, so might not be worth it.
- Hendrik
- Hendrik
___
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] libavcodec/dxva2.c: fix dxva2 does not support H264 baseline profile
On Sat, Oct 14, 2023 at 6:02 AM xyz1001 wrote:
>
> dxva2 fail to init when decode h264 with baseline profile becase
> `prof_h264_high` does not contains `AV_PROFILE_H264_BASELINE` and
> `dxva_check_codec_compatibility` will return error
> ---
> libavcodec/dxva2.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
> index d7bc587562..e6b83f89cc 100644
> --- a/libavcodec/dxva2.c
> +++ b/libavcodec/dxva2.c
> @@ -61,7 +61,8 @@ typedef struct dxva_mode {
> static const int prof_mpeg2_main[] = {AV_PROFILE_MPEG2_SIMPLE,
> AV_PROFILE_MPEG2_MAIN,
> AV_PROFILE_UNKNOWN};
> -static const int prof_h264_high[]= {AV_PROFILE_H264_CONSTRAINED_BASELINE,
> +static const int prof_h264_high[]= {AV_PROFILE_H264_BASELINE,
> +AV_PROFILE_H264_CONSTRAINED_BASELINE,
> AV_PROFILE_H264_MAIN,
> AV_PROFILE_H264_HIGH,
> AV_PROFILE_UNKNOWN};
Baseline is not compatible with main/high profile accelerators.
There is only one profile defined by DXVA2 that supports Baseline
completely, and I have never seen a GPU expose it - and we don't
support it.
- Hendrik
___
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/hwcontext_cuda: check that the SDK defines cuCtxGetCurrent()
On Fri, Oct 6, 2023 at 3:47 PM Timo Rothenpieler wrote: > I'm quite confused why this specific instance suddenly causes so much upset. Because its bad form to break compilation of master, if all it took to avoid that is change the order of pushing a tag to one repo and a patch to another. - Hendrik ___ 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/hwcontext_cuda: check that the SDK defines cuCtxGetCurrent()
On Fri, Oct 6, 2023 at 3:07 PM Timo Rothenpieler wrote: > > On 06/10/2023 14:29, Hendrik Leppkes wrote: > > On Sun, Oct 1, 2023 at 1:39 PM Timo Rothenpieler > > wrote: > >> > >> On 01.10.2023 04:06, James Almer wrote: > >>> Fixes compilation after 05f8b2ca0f7e28775837a572c65ce9218f534ee2 > >> > >> It's expected behaviour to break compilation with random inter-release > >> versions of ffnvcodec. > >> It's only reliable exactly on release versions. > >> > > > > But isn't the point that there is no release version of ffnvcodec that > > I can use to build this? > > And that it has no check to limit building it, and will always fail > > with release versions? > > I don't understand what you mean. > Right now, it only works with nv-codec-headers master. > I will make a new release there very soon. You say that its expected to break with inter-release versions of ffnvcodec, but this is the opposite, it breaks with the release version and works with git versions. So I'm not sure I understand what you are saying. Requiring a non-released version of a dependency was obviously a gigantic oversight with the original patch, and as a result master is currently broken for any reasonable setup avoiding those "inter-release versions". - Hendrik ___ 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/hwcontext_cuda: check that the SDK defines cuCtxGetCurrent()
On Sun, Oct 1, 2023 at 1:39 PM Timo Rothenpieler wrote: > > On 01.10.2023 04:06, James Almer wrote: > > Fixes compilation after 05f8b2ca0f7e28775837a572c65ce9218f534ee2 > > It's expected behaviour to break compilation with random inter-release > versions of ffnvcodec. > It's only reliable exactly on release versions. > But isn't the point that there is no release version of ffnvcodec that I can use to build this? And that it has no check to limit building it, and will always fail with release versions? - Hendrik ___ 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] configure: disable vulkan if min version insufficient
On Fri, Sep 29, 2023 at 3:55 PM Tristan Matthews wrote: > > Fixes: https://trac.ffmpeg.org/ticket/10596 > --- > configure | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/configure b/configure > index 20db1801ed..50ba6f772f 100755 > --- a/configure > +++ b/configure > @@ -7154,7 +7154,8 @@ enabled crystalhd && check_lib crystalhd "stdint.h > libcrystalhd/libcrystalhd_if. > > if enabled vulkan; then > check_pkg_config_header_only vulkan "vulkan >= 1.3.255" > "vulkan/vulkan.h" "defined VK_VERSION_1_3" || > -check_cpp_condition vulkan "vulkan/vulkan.h" > "defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= > 255)" > +check_cpp_condition vulkan "vulkan/vulkan.h" > "defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= > 255)" || > +warn "Disabling vulkan" && disable vulkan > fi > This change doesn't seem right. If a feature is explicitly requested, we generally fail the build and don't just disable the feature (afterall the user wanted it to be on). If the feature is not explicitly requested, then it should not print a message. - Hendrik ___ 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] TRAC Spam
On Fri, Sep 22, 2023 at 11:14 AM Michael Koch wrote: > > Is it ok if I remove the dead link to Python syntax, and replace it by > this link to Wikipedia? > https://en.wikipedia.org/wiki/Regular_expression > A more accurate page would probably to just point to the correct python regex docs, eg: https://docs.python.org/2.7/library/re.html ___ 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] configure: don't force specific C++ standard library linking
On Wed, Sep 6, 2023 at 12:14 AM Kacper Michajłow wrote:
>
> Other C++ standard libraries exist. Also, this is not a proper way to
> link the standard library anyway. Instead when a C++ dependency is
> detected, switch to the C++ compiler driver to properly link everything.
>
> Signed-off-by: Kacper Michajłow
> ---
> configure | 27 ++-
> 1 file changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/configure b/configure
> index bd7f7697c8..90ee6e4f7d 100755
> --- a/configure
> +++ b/configure
> @@ -3584,11 +3584,9 @@ bktr_indev_deps_any="dev_bktr_ioctl_bt848_h
> machine_ioctl_bt848_h dev_video_bktr
> caca_outdev_deps="libcaca"
> decklink_deps_any="libdl LoadLibrary"
> decklink_indev_deps="decklink threads"
> -decklink_indev_extralibs="-lstdc++"
> decklink_indev_suggest="libzvbi"
> decklink_outdev_deps="decklink threads"
> decklink_outdev_suggest="libklvanc"
> -decklink_outdev_extralibs="-lstdc++"
> dshow_indev_deps="IBaseFilter"
> dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32
> -lshlwapi"
> fbdev_indev_deps="linux_fb_h"
> @@ -4684,7 +4682,6 @@ msvc_common_flags(){
> -march=*) ;;
> -lz) echo zlib.lib ;;
> -lx264) echo libx264.lib ;;
> --lstdc++) ;;
> -l*) echo ${flag#-l}.lib ;;
> -LARGEADDRESSAWARE) echo $flag ;;
> -L*) echo -libpath:${flag#-L} ;;
Should probably keep this one, it may come from a pkg-config file or
some other source, and you don't want it forwarded to cl.exe
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avfilter/avfilter: Make functions only used here static
On Tue, Aug 1, 2023 at 5:05 PM Andreas Rheinhardt
wrote:
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/avfilter.c | 44 +++---
> libavfilter/internal.h | 8
> 2 files changed, 24 insertions(+), 28 deletions(-)
>
> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> index b8e1523bdb..df6f1ab3de 100644
> --- a/libavfilter/avfilter.c
> +++ b/libavfilter/avfilter.c
> @@ -201,6 +201,17 @@ void avfilter_link_free(AVFilterLink **link)
> av_freep(link);
> }
>
> +static void update_link_current_pts(AVFilterLink *link, int64_t pts)
> +{
> +if (pts == AV_NOPTS_VALUE)
> +return;
> +link->current_pts = pts;
> +link->current_pts_us = av_rescale_q(pts, link->time_base,
> AV_TIME_BASE_Q);
> +/* TODO use duration */
> +if (link->graph && link->age_index >= 0)
> +ff_avfilter_graph_update_heap(link->graph, link);
> +}
> +
> void ff_filter_set_ready(AVFilterContext *filter, unsigned priority)
> {
> filter->ready = FFMAX(filter->ready, priority);
> @@ -232,13 +243,17 @@ void ff_avfilter_link_set_in_status(AVFilterLink *link,
> int status, int64_t pts)
> ff_filter_set_ready(link->dst, 200);
> }
>
> -void ff_avfilter_link_set_out_status(AVFilterLink *link, int status, int64_t
> pts)
> +/**
> + * Set the status field of a link from the destination filter.
> + * The pts should probably be left unset (AV_NOPTS_VALUE).
> + */
> +static void avfilter_link_set_out_status(AVFilterLink *link, int status,
> int64_t pts)
Having the function named avfilter_* seems slightly confusing, as
thats the public namespace of exported avfilter functions.
Its of course not going to show up in other files, being static and
all, but in the functions below that use it, a reader might get the
wrong idea about a function call.
Maybe just remove the avfilter prefix? It seems unnecessary here.
> {
> av_assert0(!link->frame_wanted_out);
> av_assert0(!link->status_out);
> link->status_out = status;
> if (pts != AV_NOPTS_VALUE)
> -ff_update_link_current_pts(link, pts);
> +update_link_current_pts(link, pts);
> filter_unblock(link->dst);
> ff_filter_set_ready(link->src, 200);
> }
> @@ -428,7 +443,7 @@ int ff_request_frame(AVFilterLink *link)
> /* Acknowledge status change. Filters using ff_request_frame()
> will
> handle the change automatically. Filters can also check the
> status directly but none do yet. */
> -ff_avfilter_link_set_out_status(link, link->status_in,
> link->status_in_pts);
> +avfilter_link_set_out_status(link, link->status_in,
> link->status_in_pts);
> return link->status_out;
> }
> }
> @@ -537,17 +552,6 @@ static int set_enable_expr(AVFilterContext *ctx, const
> char *expr)
> return 0;
> }
>
> -void ff_update_link_current_pts(AVFilterLink *link, int64_t pts)
> -{
> -if (pts == AV_NOPTS_VALUE)
> -return;
> -link->current_pts = pts;
> -link->current_pts_us = av_rescale_q(pts, link->time_base,
> AV_TIME_BASE_Q);
> -/* TODO use duration */
> -if (link->graph && link->age_index >= 0)
> -ff_avfilter_graph_update_heap(link->graph, link);
> -}
> -
> int avfilter_process_command(AVFilterContext *filter, const char *cmd, const
> char *arg, char *res, int res_len, int flags)
> {
> if(!strcmp(cmd, "ping")){
> @@ -1117,7 +1121,7 @@ static int ff_filter_frame_to_filter(AVFilterLink *link)
> link->frame_count_out--;
> ret = ff_filter_frame_framed(link, frame);
> if (ret < 0 && ret != link->status_out) {
> -ff_avfilter_link_set_out_status(link, ret, AV_NOPTS_VALUE);
> +avfilter_link_set_out_status(link, ret, AV_NOPTS_VALUE);
> } else {
> /* Run once again, to see if several frames were available, or if
> the input status has also changed, or any other reason. */
> @@ -1147,7 +1151,7 @@ static int forward_status_change(AVFilterContext
> *filter, AVFilterLink *in)
> if (!progress) {
> /* Every output already closed: input no longer interesting
> (example: overlay in shortest mode, other input closed).
> */
> -ff_avfilter_link_set_out_status(in, in->status_in,
> in->status_in_pts);
> +avfilter_link_set_out_status(in, in->status_in,
> in->status_in_pts);
> return 0;
> }
> progress = 0;
> @@ -1249,7 +1253,7 @@ static int ff_filter_activate_default(AVFilterContext
> *filter)
> change is considered having already happened.
>
> It is set by the destination filter using
> - ff_avfilter_link_set_out_status().
> + avfilter_link_set_out_status().
>
> Filters are activated according to the ready field, set using the
> ff_filter_set_ready(). Eventually, a priority queue will be used.
> @@ -1339,7 +1343,7 @@ int ff_inlink_acknowledge_st
Re: [FFmpeg-devel] [PATCH v3] avformat/flvdec: move read fourcc output before flv_same_video_codec
On Sat, Jul 29, 2023 at 11:54 AM Hendrik Leppkes wrote: > > On Sat, Jul 29, 2023 at 10:46 AM Marton Balint wrote: > > > > > > > > On Sat, 29 Jul 2023, Hendrik Leppkes wrote: > > > > > On Sat, Jul 29, 2023 at 2:26 AM Steven Liu wrote: > > >> > > >> read fourcc for video codec after VideoTagHeader read. > > >> passed as parameter to flv_same_video_codec. > > >> > > > > > > Add the same parameter to flv_set_video_codec, and then you can remove > > > the entire backwards seek and just read it and adjust the size like > > > all other parameters. > > > > As far as I see flv_set_video_codec should not read a binary fourcc in the > > first place when it is called from amf_parse_object. > > Yeah probably not, so moving it to a parameter would fix that as well, > and make the entire parsing flow less opaque. > In fact the actual value will carry the FourCC then, which is not handled at all. Definitely very broken here. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avformat/flvdec: move read fourcc output before flv_same_video_codec
On Sat, Jul 29, 2023 at 10:46 AM Marton Balint wrote: > > > > On Sat, 29 Jul 2023, Hendrik Leppkes wrote: > > > On Sat, Jul 29, 2023 at 2:26 AM Steven Liu wrote: > >> > >> read fourcc for video codec after VideoTagHeader read. > >> passed as parameter to flv_same_video_codec. > >> > > > > Add the same parameter to flv_set_video_codec, and then you can remove > > the entire backwards seek and just read it and adjust the size like > > all other parameters. > > As far as I see flv_set_video_codec should not read a binary fourcc in the > first place when it is called from amf_parse_object. Yeah probably not, so moving it to a parameter would fix that as well, and make the entire parsing flow less opaque. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avformat/flvdec: move read fourcc output before flv_same_video_codec
On Sat, Jul 29, 2023 at 2:26 AM Steven Liu wrote: > > read fourcc for video codec after VideoTagHeader read. > passed as parameter to flv_same_video_codec. > Add the same parameter to flv_set_video_codec, and then you can remove the entire backwards seek and just read it and adjust the size like all other parameters. - Hendrik ___ 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] avformat/flvdec: use avio operation instead of pb->buf_ptr use
On Thu, Jul 27, 2023 at 4:38 AM Steven Liu wrote:
>
> fix segfaults:
> READ of size 1 at 0x610003b7 thread T0
> #0 0x7f928d in flv_same_video_codec ffmpeg/libavformat/flvdec.c:317:29
> #1 0x7f928d in flv_read_packet ffmpeg/libavformat/flvdec.c:1177
> #2 0x6ff32f in ff_read_packet ffmpeg/libavformat/demux.c:575:15
> #3 0x70a2fd in read_frame_internal ffmpeg/libavformat/demux.c:1263:15
> #4 0x71d158 in avformat_find_stream_info
> ffmpeg/libavformat/demux.c:2634:15
> #5 0x4c821b in LLVMFuzzerTestOneInput
> ffmpeg/tools/target_dem_fuzzer.c:206:11
>
> Signed-off-by: Steven Liu
> ---
> libavformat/flvdec.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index 3fe21622f7..003e4d7691 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -313,8 +313,9 @@ static int flv_same_video_codec(AVFormatContext *s,
> AVCodecParameters *vpar, int
> return 1;
>
> if (flv->exheader) {
> -uint8_t *codec_id_str = (uint8_t *)s->pb->buf_ptr;
> -uint32_t codec_id = codec_id_str[3] | codec_id_str[2] << 8 |
> codec_id_str[1] << 16 | codec_id_str[0] << 24;
> +int64_t pos = avio_tell(s->pb);
> +uint32_t codec_id = avio_rb32(s->pb);
> +avio_seek(s->pb, pos, SEEK_SET);
> switch(codec_id) {
> case MKBETAG('h', 'v', 'c', '1'):
> return vpar->codec_id == AV_CODEC_ID_HEVC;
You don't need to store the position, just do a relative seek
backwards by 4 bytes.
I would also recommend to include a call to ffio_ensure_seekback so it
works with streams.
eg. something like this:
ffio_ensure_seekback(s->pb, 4);
avio_rb32(s->pb);
avio_seek(s->pb, -4, SEEK_CUR);
Add appropriate error checking, in particular for ffio_ensure_seekback, etc.
- Hendrik
___
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] flvdec: fix size desync when reading timestamp offsets
The size offset was previously being accounted for in flv_set_video_codec for h264 and mpeg4, instead of being directly accounted for in the spot where its read, which desynced on HEVC streams. For clarity, move the size offset directly to the parsing, similar to how its done for all other header fields. --- libavformat/flvdec.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c index a6a94a4021..3fe21622f7 100644 --- a/libavformat/flvdec.c +++ b/libavformat/flvdec.c @@ -407,11 +407,9 @@ static int flv_set_video_codec(AVFormatContext *s, AVStream *vstream, case FLV_CODECID_H264: par->codec_id = AV_CODEC_ID_H264; vstreami->need_parsing = AVSTREAM_PARSE_HEADERS; -ret = 3; // not 4, reading packet type will consume one byte break; case FLV_CODECID_MPEG4: par->codec_id = AV_CODEC_ID_MPEG4; -ret = 3; break; default: avpriv_request_sample(s, "Video codec (%x)", flv_codecid); @@ -1321,6 +1319,7 @@ retry_duration: "invalid timestamps %"PRId64" %"PRId64"\n", dts, pts); dts = pts = AV_NOPTS_VALUE; } +size -= 3; } if (type == 0 && (!st->codecpar->extradata || st->codecpar->codec_id == AV_CODEC_ID_AAC || st->codecpar->codec_id == AV_CODEC_ID_H264 || st->codecpar->codec_id == AV_CODEC_ID_HEVC || -- 2.40.1.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 v2 1/2] avutil/random_seed: add av_random()
On Tue, Jul 4, 2023 at 10:41 PM James Almer wrote:
>
> Uses the existing code for av_get_random_seed() to return a buffer with
> cryptographically secure random data, or an error if none could be generated.
>
> Signed-off-by: James Almer
> ---
> libavutil/random_seed.c | 54 -
> libavutil/random_seed.h | 12 +
> 2 files changed, 49 insertions(+), 17 deletions(-)
>
> diff --git a/libavutil/random_seed.c b/libavutil/random_seed.c
> index 66dd504ef0..0ed8f89cc6 100644
> --- a/libavutil/random_seed.c
> +++ b/libavutil/random_seed.c
> @@ -46,20 +46,22 @@
> #define TEST 0
> #endif
>
> -static int read_random(uint32_t *dst, const char *file)
> -{
> #if HAVE_UNISTD_H
> +static int read_random(uint8_t *dst, size_t len, const char *file)
> +{
> int fd = avpriv_open(file, O_RDONLY);
> -int err = -1;
> +ssize_t err = -1;
>
> +if (len > SSIZE_MAX)
> +return -1;
> if (fd == -1)
> return -1;
> -err = read(fd, dst, sizeof(*dst));
> +err = read(fd, dst, len);
> close(fd);
> +if (err == -1)
> +return AVERROR(errno);
>
> -return err;
> -#else
> -return -1;
> +return err == len;
> #endif
> }
>
> @@ -118,29 +120,47 @@ static uint32_t get_generic_seed(void)
> return AV_RB32(digest) + AV_RB32(digest + 16);
> }
>
> -uint32_t av_get_random_seed(void)
> +int av_random(uint8_t* buf, size_t len)
> {
> -uint32_t seed;
> +int err = AVERROR_UNKNOWN;
>
> #if HAVE_BCRYPT
> BCRYPT_ALG_HANDLE algo_handle;
> NTSTATUS ret = BCryptOpenAlgorithmProvider(&algo_handle,
> BCRYPT_RNG_ALGORITHM,
> MS_PRIMITIVE_PROVIDER, 0);
> if (BCRYPT_SUCCESS(ret)) {
> -NTSTATUS ret = BCryptGenRandom(algo_handle, (UCHAR*)&seed,
> sizeof(seed), 0);
> +NTSTATUS ret = BCryptGenRandom(algo_handle, (PUCHAR)buf, len, 0);
> BCryptCloseAlgorithmProvider(algo_handle, 0);
> if (BCRYPT_SUCCESS(ret))
> -return seed;
> +return 0;
> }
> #endif
>
> #if HAVE_ARC4RANDOM
> -return arc4random();
> +arc4random_buf(buf, len);
> +return 0;
> +#endif
> +
> +#if HAVE_UNISTD_H
> +err = read_random(buf, len, "/dev/urandom");
> +if (err == 1)
> +return 0;
> +err = read_random(buf, len, "/dev/random");
> +if (err == 1)
> +return 0;
> +if (err == 0)
> + err = AVERROR_UNKNOWN;
> #endif
>
> -if (read_random(&seed, "/dev/urandom") == sizeof(seed))
> -return seed;
> -if (read_random(&seed, "/dev/random") == sizeof(seed))
> -return seed;
> -return get_generic_seed();
> +return err;
> +}
> +
> +uint32_t av_get_random_seed(void)
> +{
> +uint32_t seed;
> +
> +if (av_random((uint8_t *)&seed, sizeof(seed)) < 0)
> +return get_generic_seed();
> +
> +return seed;
> }
> diff --git a/libavutil/random_seed.h b/libavutil/random_seed.h
> index 0462a048e0..ce982bb82f 100644
> --- a/libavutil/random_seed.h
> +++ b/libavutil/random_seed.h
> @@ -36,6 +36,18 @@
> */
> uint32_t av_get_random_seed(void);
>
> +/**
> + * Generate cryptographically secure random data, i.e. suitable for use as
> + * encryption keys and similar.
> + *
> + * @param buf buffer into which the random data will be written
> + * @param len size of buf in bytes
> + *
> + * @retval 0 success, and len bytes of random data was written into buf, or
> + * a negative AVERROR code if random data could not be generated.
> + */
> +int av_random(uint8_t* buf, size_t len);
av_random seems like a pretty generic name for something thats
requiring to be cryptographically secure and otherwise fail. I would
expect a more specific name for that purpose. There is plenty other
uses of randomness in multimedia, noise, dithering, etc, which don't
need crypto security. The function doesn't have to handle those, but
maybe it should be specific in what it does handle?
- Hendrik
___
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 5/5] avformat: add sdr support
On Sun, Jun 18, 2023 at 2:59 PM Lynne wrote: > > Jun 17, 2023, 20:37 by mich...@niedermayer.cc: > > > On Sat, Jun 17, 2023 at 08:08:11PM +0200, Paul B Mahol wrote: > > [...] > > > >> Which library handles compressed stuff? > >> > > > > For digital stuff like DAB/DVB/... > > > > sdrdemux in libavformat will demodulate, do error correction then return > > AVPacket > > with H.264 / Mpeg2 video or AAC or wahetever > > That then will get passed to libavcodec, same as with any other demuxer. > > > > This code is not written yet. There is just analog AM demodulation. I posted > > this patch as soon as the first usecase worked > > > > usecase was "listen to random AM radio stations in ffplay" :) > > and it can also grab all AM stations in a 10Mhz window and demodulate all > > (that 10mhz is what my hw and usb bandwidth can do max) > > > > I intend to add FM demodulation, because it seems a fun thing to try to do. > > > > someone will need to add DAB/DVB support, I would be happy if someone else > > comes forth to do that. If noone does ill think about if i want to do it > > or not once FM is done and once this is in git. > > > > The initial reaction from some was a bit spicy, so i need to think > > how much fun this is in FFmpeg. > > But one thing i can say for sure, is, if i cannot use this in ffplay > > then it makes no sense for me to put more time into it > > > > We could implement seeking to next/previous stations differently but > > it seems a bit like creating extra work for everyone. > > I mean a new API in sdrdemux then ffplay needs to support that and then > > other players would need to support it and so on. While really the > > seeking on a realtime input has no other use > > > > I like the new functionality, but I too think that libavformat > should just source the data from a device, and that libavfilter > should demodulate. And how do you deal with the prospect of future digital audio, outputting a compressed bitstream? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: Align AVFrame memory to page size for access via Apple Metal
On Thu, Jun 15, 2023 at 4:16 AM Iskandar Safarov wrote:
>
> ---
> libavcodec/get_buffer.c | 52 -
> 1 file changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/get_buffer.c b/libavcodec/get_buffer.c
> index a04fd878de..b18af3be4a 100644
> --- a/libavcodec/get_buffer.c
> +++ b/libavcodec/get_buffer.c
> @@ -33,6 +33,11 @@
> #include "avcodec.h"
> #include "internal.h"
>
> +#if __APPLE__
> +#import
> +#import
> +#endif
> +
> typedef struct FramePool {
> /**
> * Pools for each data plane. For audio all the planes have the same
> size,
> @@ -81,6 +86,51 @@ static AVBufferRef *frame_pool_alloc(void)
> return buf;
> }
>
> +#if __APPLE__
> +/*
> +When compiling for Apple platform the frame buffer data pointers need to
> be
> +page-aligned for cases when in-place GPU processing may be required
> +
> https://developer.apple.com/documentation/metal/mtldevice/1433382-newbufferwithbytesnocopy
> + */
> +#define POOL_BUFFER_ALLOCZ aapl_buffer_allocz
> +
> +static void aapl_buffer_free(void *opaque, uint8_t *data)
> +{
> +vm_deallocate((vm_map_t) mach_task_self(), (vm_address_t)data,
> (size_t)opaque);
> +}
> +
> +static AVBufferRef *aapl_buffer_alloc(size_t size)
> +{
> +AVBufferRef *ret = NULL;
> +uint8_t*data = NULL;
> +
> +kern_return_t err;
> +err = vm_allocate( (vm_map_t) mach_task_self(),
> +(vm_address_t*) &data, size, VM_FLAGS_ANYWHERE);
> +if (err != KERN_SUCCESS || !data)
> +return NULL;
> +
> +ret = av_buffer_create(data, size, aapl_buffer_free, (void*)size, 0);
> +if (!ret)
> +free(data);
> +
> +return ret;
> +}
> +
> +static AVBufferRef *aapl_buffer_allocz(size_t size)
> +{
> +AVBufferRef *ret = aapl_buffer_alloc(size);
> +if (!ret)
> +return NULL;
> +
> +memset(ret->data, 0, size);
> +return ret;
> +}
> +
> +#else
> +#define POOL_BUFFER_ALLOCZ av_buffer_allocz
> +#endif
> +
> static int update_frame_pool(AVCodecContext *avctx, AVFrame *frame)
> {
> FramePool *pool = avctx->internal->pool ?
> @@ -155,7 +205,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
> pool->pools[i] = av_buffer_pool_init(size[i] + 16 +
> STRIDE_ALIGN - 1,
> CONFIG_MEMORY_POISONING
> ?
> NULL :
> -av_buffer_allocz);
> +POOL_BUFFER_ALLOCZ);
> if (!pool->pools[i]) {
> ret = AVERROR(ENOMEM);
> goto fail;
> --
> 2.39.2 (Apple Git-143)
>
This is most definitely the wrong place to do this. Frames can be
allocated through various means and in various locations, and randomly
sprinkling new allocators all over is not how this should be
approached.
I don't believe FFmpeg itself shares this requirement, so maybe your
application should just use a custom get_buffer2 callback to fullfill
it?
If others agree that FFmpeg should create frames with this property by
default (which I can't answer without knowing if those special
allocation functions have any other downsides etc), it should be done
more centrally, rather then only in the avcodec pool.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] lavu/frame: add av_frame_get_buffer2
On Tue, May 16, 2023 at 4:07 AM Xiang, Haihao wrote: > > From: Haihao Xiang > > Intel MediaSDK and oneVPL expect contiguous allocation for data[i], > however there are mandatory padding bytes between data[i] and data[i+1]. > when calling av_frame_get_buffer. So adding av_frame_get_buffer2 to > allow caller to specify the length of padding bytes. > get_video_buffer will also pad the height to a multiple of 32, won't that again cause issues? I don't think the API even necessarily guarantees that its going to be one contiguous buffer, it just happens to be the way its made right now. If a new API is introduced, maybe it should be very tailor designed to offer these guarantees, and named appropriate, not introducing any padding - padded height or extra padding, or otherwise. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/nvdec_mpeg2: fix order of quant matrix coefficients
On Mon, May 15, 2023 at 1:30 PM Hendrik Leppkes wrote: > > Apparently mpeg4 and VDPAU have the same issue. I can test and fix > mpeg4, but do not have VDPAU setup, so .. untested commits incoming? > Tested and confirmed mpeg2 and mpeg4 are fixed for NVDEC, and elenril tested VDPAU with the same result. OK'ed by BtbN on IRC. Going to push later today. - Hendrik ___ 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/4] avcodec/vdpau_mpeg4: fix order of quant matrix coefficients
The matrix coefficients are stored permutated for the IDCT,
rather then in plain raster order, and need to be un-permutated
for the hardware.
---
libavcodec/vdpau_mpeg4.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vdpau_mpeg4.c b/libavcodec/vdpau_mpeg4.c
index 6e082eefc6..1211b1df2c 100644
--- a/libavcodec/vdpau_mpeg4.c
+++ b/libavcodec/vdpau_mpeg4.c
@@ -74,8 +74,9 @@ static int vdpau_mpeg4_start_frame(AVCodecContext *avctx,
info->alternate_vertical_scan_flag = s->alternate_scan;
info->top_field_first = s->top_field_first;
for (i = 0; i < 64; ++i) {
-info->intra_quantizer_matrix[i] = s->intra_matrix[i];
-info->non_intra_quantizer_matrix[i] = s->inter_matrix[i];
+int n = s->idsp.idct_permutation[i];
+info->intra_quantizer_matrix[i] = s->intra_matrix[n];
+info->non_intra_quantizer_matrix[i] = s->inter_matrix[n];
}
ff_vdpau_common_start_frame(pic_ctx, buffer, size);
--
2.40.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/4] avcodec/vdpau_mpeg12: fix order of quant matrix coefficients
The matrix coefficients are stored permutated for the IDCT,
rather then in plain raster order, and need to be un-permutated
for the hardware.
---
libavcodec/vdpau_mpeg12.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vdpau_mpeg12.c b/libavcodec/vdpau_mpeg12.c
index 354239cad5..79007aa1a8 100644
--- a/libavcodec/vdpau_mpeg12.c
+++ b/libavcodec/vdpau_mpeg12.c
@@ -75,8 +75,9 @@ static int vdpau_mpeg_start_frame(AVCodecContext *avctx,
info->f_code[1][0] = s->mpeg_f_code[1][0];
info->f_code[1][1] = s->mpeg_f_code[1][1];
for (i = 0; i < 64; ++i) {
-info->intra_quantizer_matrix[i] = s->intra_matrix[i];
-info->non_intra_quantizer_matrix[i] = s->inter_matrix[i];
+int n = s->idsp.idct_permutation[i];
+info->intra_quantizer_matrix[i] = s->intra_matrix[n];
+info->non_intra_quantizer_matrix[i] = s->inter_matrix[n];
}
return ff_vdpau_common_start_frame(pic_ctx, buffer, size);
--
2.40.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/4] avcodec/nvdec_mpeg4: fix order of quant matrix coefficients
The matrix coefficients are stored permutated for the IDCT,
rather then in plain raster order, and need to be un-permutated
for the hardware.
---
libavcodec/nvdec_mpeg4.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/nvdec_mpeg4.c b/libavcodec/nvdec_mpeg4.c
index eac138cc38..c193f6b6e4 100644
--- a/libavcodec/nvdec_mpeg4.c
+++ b/libavcodec/nvdec_mpeg4.c
@@ -88,8 +88,9 @@ static int nvdec_mpeg4_start_frame(AVCodecContext *avctx,
const uint8_t *buffer,
};
for (i = 0; i < 64; ++i) {
-ppc->QuantMatrixIntra[i] = s->intra_matrix[i];
-ppc->QuantMatrixInter[i] = s->inter_matrix[i];
+int n = s->idsp.idct_permutation[i];
+ppc->QuantMatrixIntra[i] = s->intra_matrix[n];
+ppc->QuantMatrixInter[i] = s->inter_matrix[n];
}
// We need to pass the full frame buffer and not just the slice
--
2.40.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/4] avcodec/nvdec_mpeg2: fix order of quant matrix coefficients
The matrix coefficients are stored permutated for the IDCT,
rather then in plain raster order, and need to be un-permutated
for the hardware.
---
libavcodec/nvdec_mpeg12.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/nvdec_mpeg12.c b/libavcodec/nvdec_mpeg12.c
index e10735587d..3b9ff60734 100644
--- a/libavcodec/nvdec_mpeg12.c
+++ b/libavcodec/nvdec_mpeg12.c
@@ -83,8 +83,9 @@ static int nvdec_mpeg12_start_frame(AVCodecContext *avctx,
const uint8_t *buffer
};
for (i = 0; i < 64; ++i) {
-ppc->QuantMatrixIntra[i] = s->intra_matrix[i];
-ppc->QuantMatrixInter[i] = s->inter_matrix[i];
+int n = s->idsp.idct_permutation[i];
+ppc->QuantMatrixIntra[i] = s->intra_matrix[n];
+ppc->QuantMatrixInter[i] = s->inter_matrix[n];
}
return 0;
--
2.40.1.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] avcodec/nvdec_mpeg2: fix order of quant matrix coefficients
On Mon, May 15, 2023 at 12:51 PM Hendrik Leppkes wrote:
>
> mpeg2dec stores them permutated for the IDCT, nvdec expects them in
> plain raster order.
> ---
> libavcodec/nvdec_mpeg12.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/nvdec_mpeg12.c b/libavcodec/nvdec_mpeg12.c
> index e10735587d..3b9ff60734 100644
> --- a/libavcodec/nvdec_mpeg12.c
> +++ b/libavcodec/nvdec_mpeg12.c
> @@ -83,8 +83,9 @@ static int nvdec_mpeg12_start_frame(AVCodecContext *avctx,
> const uint8_t *buffer
> };
>
> for (i = 0; i < 64; ++i) {
> -ppc->QuantMatrixIntra[i] = s->intra_matrix[i];
> -ppc->QuantMatrixInter[i] = s->inter_matrix[i];
> +int n = s->idsp.idct_permutation[i];
> +ppc->QuantMatrixIntra[i] = s->intra_matrix[n];
> +ppc->QuantMatrixInter[i] = s->inter_matrix[n];
> }
>
> return 0;
> --
> 2.40.1.windows.1
>
Apparently mpeg4 and VDPAU have the same issue. I can test and fix
mpeg4, but do not have VDPAU setup, so .. untested commits incoming?
- Hendrik
___
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/nvdec_mpeg2: fix order of quant matrix coefficients
mpeg2dec stores them permutated for the IDCT, nvdec expects them in
plain raster order.
---
libavcodec/nvdec_mpeg12.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/nvdec_mpeg12.c b/libavcodec/nvdec_mpeg12.c
index e10735587d..3b9ff60734 100644
--- a/libavcodec/nvdec_mpeg12.c
+++ b/libavcodec/nvdec_mpeg12.c
@@ -83,8 +83,9 @@ static int nvdec_mpeg12_start_frame(AVCodecContext *avctx,
const uint8_t *buffer
};
for (i = 0; i < 64; ++i) {
-ppc->QuantMatrixIntra[i] = s->intra_matrix[i];
-ppc->QuantMatrixInter[i] = s->inter_matrix[i];
+int n = s->idsp.idct_permutation[i];
+ppc->QuantMatrixIntra[i] = s->intra_matrix[n];
+ppc->QuantMatrixInter[i] = s->inter_matrix[n];
}
return 0;
--
2.40.1.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] lavc/qsv: fallback to the default mfx implementation for internal session on Windows
On Mon, May 15, 2023 at 8:04 AM Xiang, Haihao wrote: > > From: Haihao Xiang > > The mfx implementation based on D3D11 is expected for an internal > session on Windows, however sometimes this implemntation is not > supported [1]. A fallback to the default mfx implementation is added in > this patch. > > [1] https://github.com/intel/cartwheel-ffmpeg/issues/246 > From the issue description, the user is trying to use it a as software library, not a hardware one? I don't think software fallback, especially an automatic one, is really quite appropriate. When someone requests a "qsv" encoder, they expect hardware. - Hendrik ___ 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] lavfi/vf_libplacebo: add vulkan device import fallback
On Thu, May 11, 2023 at 11:32 AM Lynne wrote: > > May 11, 2023, 10:39 by ffm...@haasn.xyz: > > > From: Niklas Haas > > > > Recent versions of libplacebo have required Vulkan versions incompatible > > with lavu Vulkan hwcontexts. While this is expected to change > > eventually, breaking vf_libplacebo every time there is such a transition > > period is obviously undesired behavior, as the following sea of bug > > reports shows. > > > > This commit adds a fallback path for pl_vulkan_import failures which > > simply creates an internal device instead. Also useful when no interop > > with lavu vulkan hwframes is needed or desired. > > > > Fixes: https://github.com/haasn/libplacebo/issues/170 > > Fixes: https://github.com/mpv-player/mpv/issues/9589#issuecomment-1535432185 > > Fixes: https://code.videolan.org/videolan/libplacebo/-/issues/270 > > > > NAK. The whole point of the hwcontext infrastructure is to be > explicit, and creating a new device behind the scenes is anything but that. > > This is not a native vulkan filter, it is an external library not married to our vulkan infrastructure - it merely has compatibility for it. Ensuring it works, as it might have separate requirements or a different development cycle, is hardly a bad thing. And it greatly simplifies the usability for users that only want a quick GPU processing. - Hendrik ___ 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] av_mallocz_array
On Thu, May 4, 2023 at 11:06 AM Christophe GARNIER
wrote:
>
> Hello,
>
> To build makemkv version 1.17.3 (makemkv-oss), I retreived he sources of
> ffmpeg from the git repository (git clone
> https://git.ffmpeg.org/ffmpeg.git ffmpeg).It appeared that the function
> av_mallocz_array is not present into libavutil/mem.c and libavutil/mem.h.
>
> I had the following code into libavutil/mem.c :
>
> void *av_mallocz_array(size_t nmemb, size_t size)
> {
> size_t result;
> if (size_mult(nmemb, size, &result) < 0)
> return NULL;
> return av_mallocz(result);
> }
>
> and into libavutil/mem.h :
>
> /**
> * Allocate a memory block for an array with av_mallocz().
> *
> * The allocated memory will have size `size * nmemb` bytes.
> *
> * @param nmemb Number of elements
> * @param size Size of the single element
> * @return Pointer to the allocated block, or `NULL` if the block cannot
> * be allocated
> *
> * @see av_mallocz()
> * @see av_malloc_array()
> */
> av_alloc_size(1, 2) void *av_mallocz_array(size_t nmemb, size_t size);
>
> After these modifications, I have been able to generate makemkv-oss.
>
>
av_mallocz_array has been deprecated over 2 years ago and removed in
the latest version. The replacement is av_calloc.
The code you are trying to compile needs to be updated for the latest
version of FFmpeg, not the function returned.
- Hendrik
___
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] [RFC] avformat: Add basic same origin check
On Wed, May 3, 2023 at 12:49 PM Michael Niedermayer
wrote:
>
> On Wed, May 03, 2023 at 12:05:54PM +0200, Hendrik Leppkes wrote:
> > On Tue, May 2, 2023 at 10:57 PM James Almer wrote:
> > > >
> > > > added
> > > > +{"same_none" , "same origin check off" , 0 ,
> > > > AV_OPT_TYPE_CONST, { .i64 = AVFMT_SAME_ORIGIN_CHECK_NONE }, 0, INT_MAX,
> > > > D|E, "same_origin"},
> > >
> > > "none" sounds more natural.
> > >
> > > >
> > > >
> > > >> And do we want check_path to be default? It's a change
> > > >> in behavior.
> > > >
> > > > is it usefull if its not enabled by default ?
> > >
> > > It is, since it can be enabled, like the whitelists and blacklists, but
> > > the question is if it's preferable to have it enabled. If you consider
> > > it so, then it's good and i wont oppose it.
> > >
> >
> > Is there any estimation how many legitimate streams would be broken by
> > these options?
> > If any major streams don't work with this, then its not a good option,
> > and eg. library users will likely just turn it off or to a lower
> > setting, as proper streams just have to work - and log output is
> > pretty much useless for API usage cases.
> >
> > A quick check for example shows that even something as simple as the
> > HLS BBC Radio streams will fail _all_ checks, since the playlists are
> > hosted on another host entirely as the media, thanks to akamai live
> > streaming.
> > Playlist here, as an example:
> > http://a.files.bbci.co.uk/media/live/manifesto/audio/simulcast/hls/nonuk/sbr_low/ak/bbc_radio_one.m3u8
>
> yes, thats why it says RFC in the subject, i had expected that a bit already
>
> still OTOH, blocking these by default is the safer option, i mean if a user
> does a
> ./ffplay http://trustedfoobar.org/cutevideo.avi
>
> would she expect that video to access http://127.0.0.1/ and later
> http://evilhost/localwebscan-success
> I think this should not be possible by default settings, its unexpected
>
Coming from the other side -- If the user needs to set the flag for
nearly all streams, then they are not going to check in the future and
just set it, defeating the purpose of them. At which point we might as
well not burden them.
- Hendrik
___
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] [RFC] avformat: Add basic same origin check
On Tue, May 2, 2023 at 10:57 PM James Almer wrote:
> >
> > added
> > +{"same_none" , "same origin check off" , 0 ,
> > AV_OPT_TYPE_CONST, { .i64 = AVFMT_SAME_ORIGIN_CHECK_NONE }, 0, INT_MAX,
> > D|E, "same_origin"},
>
> "none" sounds more natural.
>
> >
> >
> >> And do we want check_path to be default? It's a change
> >> in behavior.
> >
> > is it usefull if its not enabled by default ?
>
> It is, since it can be enabled, like the whitelists and blacklists, but
> the question is if it's preferable to have it enabled. If you consider
> it so, then it's good and i wont oppose it.
>
Is there any estimation how many legitimate streams would be broken by
these options?
If any major streams don't work with this, then its not a good option,
and eg. library users will likely just turn it off or to a lower
setting, as proper streams just have to work - and log output is
pretty much useless for API usage cases.
A quick check for example shows that even something as simple as the
HLS BBC Radio streams will fail _all_ checks, since the playlists are
hosted on another host entirely as the media, thanks to akamai live
streaming.
Playlist here, as an example:
http://a.files.bbci.co.uk/media/live/manifesto/audio/simulcast/hls/nonuk/sbr_low/ak/bbc_radio_one.m3u8
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] lavu/avassert: include config.h
On Wed, Apr 26, 2023 at 2:32 PM Nicolas George wrote: > > Fix setting the assert level. > > Signed-off-by: Nicolas George > --- > libavutil/avassert.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavutil/avassert.h b/libavutil/avassert.h > index 51e462bbae..8f3f72c80c 100644 > --- a/libavutil/avassert.h > +++ b/libavutil/avassert.h > @@ -28,6 +28,7 @@ > #define AVUTIL_AVASSERT_H > > #include > +#include "config.h" > #include "log.h" > #include "macros.h" > This is an installed header, it cannot depend on config.h - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffprobe/eac3/mlp/dca: add detection of spatial audio extensions
On Fri, Mar 10, 2023 at 3:18 AM Marth64 wrote: > > Hi, > > If there is still interest I can refine this to match the latest ffmpeg > branch. Thank you! > > Your patches have already been merged to git master. - Hendrik ___ 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] PRIx64 and msvc
On Wed, Mar 8, 2023 at 5:34 PM wrote: > > Le 2023-03-08 09:10, Hendrik Leppkes a écrit : > > On Wed, Mar 8, 2023 at 4:02 PM wrote: > >> > >> I'm compiling with msvc and get some errors with PRIx64 and similars. > >> For example: > >> snprintf(name, sizeof(name), "0x%"PRIx64, ch_layout); > >> > >> won't compile, but this work (with the extra space): > >> snprintf(name, sizeof(name), "0x%" PRIx64, ch_layout); > >> > >> Can this be included in the sources without introducing problems for > >> other platforms? > > > > You'll have to provide more information. We have automated builds with > > MSVC which are running just fine right now. > > > > - Hendrik > > ___ > > 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". > > For example, in ffplay.c sample (ffmpeg version 5.0.2): > > if (is->audio_filter_src.channel_layout) > snprintf(asrc_args + ret, sizeof(asrc_args) - ret, > ":channel_layout=0x%"PRIx64, > is->audio_filter_src.channel_layout); > > gives the following error: > error C3688: invalid literal suffix 'PRIx64'; literal operator or > literal operator template 'operator ""PRIx64' not found > > The error is gone when adding a space before PRIx64. > > Note that I'm mixing C and C++ in my projet. Compiling in plain C seems > to work. This is C code, it has to be compiled as C. You can set this for every individual file in MSVC if you have to. We cannot support modifications or custom projects, of course. - Hendrik ___ 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] PRIx64 and msvc
On Wed, Mar 8, 2023 at 4:02 PM wrote: > > I'm compiling with msvc and get some errors with PRIx64 and similars. > For example: > snprintf(name, sizeof(name), "0x%"PRIx64, ch_layout); > > won't compile, but this work (with the extra space): > snprintf(name, sizeof(name), "0x%" PRIx64, ch_layout); > > Can this be included in the sources without introducing problems for > other platforms? You'll have to provide more information. We have automated builds with MSVC which are running just fine right now. - Hendrik ___ 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] avcodec: add D3D12VA hardware accelerated H264, HEVC, VP9, and AV1 decoding
On Fri, Dec 23, 2022 at 7:01 PM Wu Jianhua wrote: > > [PATCH v2] avcodec: add D3D12VA hardware accelerated H264, HEVC, VP9, and AV1 > decoding > > Patches attached. > The naming scheme on this seems to be rather inconsistent. Both "d3d12dec" and "d3d12va" seem to be used in different places - please standardize it all on "d3d12va", it matches d3d11va and remains consistent with itself. Additionally, why are you not supporting all codecs that D3D11 supports? Are there any limitations on what it supports, for some reason? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/4] avcodec/eac3dec: add detection of Atmos spatial extension profile
On Sat, Feb 18, 2023 at 8:43 PM Marth64 wrote: > > Signed-off-by: Marth64 The entire set looks good to me now. If there are no further objections or comments, I'll apply it in a day or two. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Fix broken build on Android due to broken asm-generic/termbits.h include
On Thu, Feb 23, 2023 at 3:37 PM copypaste wrote: > It gets included because this platform does indeed have Video4Linux so some > of the aarch64 stuff is relevant. Furthermore I think that the HEVC stuff > includes it. > If its relevant for V4L or other hardware integration is fine and all ... but the real question is, how does it end up in aaccoder.c and other files entirely unrelated to video or hardware? And can we just get it out of those? - Hendrik ___ 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] Chromium 110 and ffmpeg 5.1.2
On Wed, Feb 22, 2023 at 9:42 PM Drew Abbott wrote: > > Hello, > > I am trying to build Chromium 110 with ffmpeg version 5.1.2. One of > the errors I get while building has to do with the API for accessing > first_dts. It looks like previously it was just a member of AVStream, > but now it can only be accessed with av_stream_get_first_dts: > https://github.com/chromium/chromium/commit/b94755e4633045be96ab5e0bdde0db7e16a804bd > I can see now first_dts is a member of FFStream, but I don't know how > to go from an AVStream to an FFStream without using internals of > libavformat, if that is even possible. How was first_dts accessed in > 5.1.2 from an AVStream? Chrome hacks their ffmpeg rather then fixing their code. You can't build it with anything but their canned version. - Hendrik ___ 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 00/72] Implement support for Vulkan multiplane images and video decoding
On Mon, Feb 20, 2023 at 12:50 AM Neal Gompa wrote: > > On Sun, Feb 19, 2023 at 5:00 PM Kieran Kunhya wrote: > > > > On Sun, 19 Feb 2023 at 18:46, Lynne wrote: > > > > > Feb 19, 2023, 18:43 by kier...@obe.tv: > > > > > > > On Sun, 19 Feb 2023 at 17:36, Kieran Kunhya wrote: > > > > > > > >> Obviously, if we merge it now, and big enough issues are found > > > >> > > > >>> which we couldn't fix immediately, I'd have no problem reverting > > > >>> the Vulkan patches from the 6.0 branch. > > > >>> > > > >> > > > >> > > > >> A major LTS release is not your development sandbox. > > > >> > > > >> Kieran > > > >> > > > > > > > > Correction, 6.0 is not an LTS. Nonetheless, it's not your sandbox. > > > > > > > > > > If new features don't go in, the project dies. > > > Everyone but seems to dislike new features. > > > > > > > Sure, then put your features in early in the dev cycle, not days before a > > major release. > > > > This is not a reasonable response, especially to someone who is > volunteering their time to develop features for a project. If it > misses 6.0, it sucks. > I think its quite reasonable to think of the stability and quality of the release. If a feature is rushed into a release and you get a buggy version of it in 6.0, that also sucks - in fact it may suck more for those people that were using those features this is going to replace. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/4] avcodec/eac3dec: add detection of Atmos spatial extension profile
On Sat, Feb 18, 2023 at 6:50 PM Marth64 wrote:
>
> Signed-off-by: Marth64
> ---
> - Missed adding the profiles to actual codec descriptor in ac3dec_float
> - Formatting tidyness
>
> libavcodec/ac3dec.c | 3 +++
> libavcodec/ac3dec.h | 1 +
> libavcodec/ac3dec_float.c | 2 ++
> libavcodec/avcodec.h | 2 ++
> libavcodec/codec_desc.c | 1 +
> libavcodec/eac3dec.c | 11 ++-
> libavcodec/profiles.c | 5 +
> libavcodec/profiles.h | 1 +
> 8 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
> index 0b120e6140..b5f4b166d3 100644
> --- a/libavcodec/ac3dec.c
> +++ b/libavcodec/ac3dec.c
> @@ -1714,6 +1714,9 @@ skip:
> if (!err) {
> avctx->sample_rate = s->sample_rate;
> avctx->bit_rate= s->bit_rate + s->prev_bit_rate;
> +
> +if (s->eac3_extension_type_a == 1)
> +avctx->profile = s->eac3_extension_type_a == 1 ?
> FF_PROFILE_EAC3_DDP_ATMOS : FF_PROFILE_UNKNOWN;
> }
You have to leave out the if(..) for this to make sense. :)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/4] avcodec/mlpdec: add detection of Atmos spatial extension profile in TrueHD
On Sat, Feb 18, 2023 at 2:15 AM Marth64 wrote:
>
> Signed-off-by: Marth64
> ---
> libavcodec/avcodec.h| 2 ++
> libavcodec/codec_desc.c | 1 +
> libavcodec/mlpdec.c | 11 +++
> libavcodec/profiles.c | 5 +
> libavcodec/profiles.h | 1 +
> 5 files changed, 20 insertions(+)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 0e85dd50a4..3feab75741 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1593,6 +1593,8 @@ typedef struct AVCodecContext {
>
> #define FF_PROFILE_EAC3_DDP_ATMOS 30
>
> +#define FF_PROFILE_TRUEHD_ATMOS 30
> +
> #define FF_PROFILE_MPEG2_4220
> #define FF_PROFILE_MPEG2_HIGH 1
> #define FF_PROFILE_MPEG2_SS 2
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 4098d4f5a5..e80ac07700 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -2960,6 +2960,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
> .name = "truehd",
> .long_name = NULL_IF_CONFIG_SMALL("TrueHD"),
> .props = AV_CODEC_PROP_LOSSLESS,
> +.profiles = NULL_IF_CONFIG_SMALL(ff_truehd_profiles),
> },
> {
> .id= AV_CODEC_ID_MP4ALS,
> diff --git a/libavcodec/mlpdec.c b/libavcodec/mlpdec.c
> index 0ee1f0982c..85d6207b9c 100644
> --- a/libavcodec/mlpdec.c
> +++ b/libavcodec/mlpdec.c
> @@ -42,6 +42,7 @@
> #include "mlpdsp.h"
> #include "mlp.h"
> #include "config.h"
> +#include "profiles.h"
>
> /** number of bits used for VLC lookup - longest Huffman code is 9 */
> #if ARCH_ARM
> @@ -392,6 +393,15 @@ static int read_major_sync(MLPDecodeContext *m,
> GetBitContext *gb)
> m->num_substreams= mh.num_substreams;
> m->substream_info= mh.substream_info;
>
> +/* If there is a 4th substream and the MSB of substream_info is set,
> + * there is a 16-channel spatial presentation (Atmos in TrueHD).
> + */
> +if (m->avctx->codec_id == AV_CODEC_ID_TRUEHD
> +&& m->num_substreams == 4
> +&& m->substream_info >> 7 == 1) {
> +m->avctx->profile = FF_PROFILE_TRUEHD_ATMOS;
> +}
> +
Nit: maybe put the if into two lines instead of three? The two
substream checks look like they should fit in one line quite well. But
this is just a style question, so feel free to ignore.
Otherwise LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 3/4] avcodec/dca_xll: add detection of DTS:X and DTS:X IMAX
On Sat, Feb 18, 2023 at 2:15 AM Marth64 wrote: > > Signed-off-by: Marth64 > --- > libavcodec/avcodec.h | 15 +-- > libavcodec/dca_syncwords.h | 3 +++ > libavcodec/dca_xll.c | 26 +- > libavcodec/dca_xll.h | 3 +++ > libavcodec/profiles.c | 14 -- > 5 files changed, 48 insertions(+), 13 deletions(-) > LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/4] avcodec/eac3dec: add detection of Atmos spatial extension profile
On Sat, Feb 18, 2023 at 2:15 AM Marth64 wrote: > > Signed-off-by: Marth64 > --- Another thing I noticed, you should add the profiles to the eac3 decoder AVCodec in ac3_float.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 v2 1/4] avcodec/eac3dec: add detection of Atmos spatial extension profile
On Sat, Feb 18, 2023 at 2:15 AM Marth64 wrote:
>
> Signed-off-by: Marth64
> ---
> libavcodec/ac3dec.c | 3 +++
> libavcodec/ac3dec.h | 1 +
> libavcodec/avcodec.h| 2 ++
> libavcodec/codec_desc.c | 1 +
> libavcodec/eac3dec.c| 11 ++-
> libavcodec/profiles.c | 5 +
> libavcodec/profiles.h | 1 +
> 7 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
> index 0b120e6140..8cede139b8 100644
> --- a/libavcodec/ac3dec.c
> +++ b/libavcodec/ac3dec.c
> @@ -1714,6 +1714,9 @@ skip:
> if (!err) {
> avctx->sample_rate = s->sample_rate;
> avctx->bit_rate= s->bit_rate + s->prev_bit_rate;
> +
> +if (s->eac3_extension_type_a == 1)
> +avctx->profile = FF_PROFILE_EAC3_DDP_ATMOS;
> }
This should probably be something like:
avctx->profile = s->eac3_extension_type_a == 1 ?
FF_PROFILE_EAC3_DDP_ATMOS : FF_PROFILE_UNKNOWN;
This way the profile is properly reset when there is no extension (anymore).
>
> if (!avctx->sample_rate) {
> diff --git a/libavcodec/ac3dec.h b/libavcodec/ac3dec.h
> index 138b462abb..0829f4b40d 100644
> --- a/libavcodec/ac3dec.h
> +++ b/libavcodec/ac3dec.h
> @@ -102,6 +102,7 @@ typedef struct AC3DecodeContext {
> int eac3; ///< indicates if current frame
> is E-AC-3
> int eac3_frame_dependent_found; ///< bitstream has E-AC-3
> dependent frame(s)
> int eac3_subsbtreamid_found;///< bitstream has E-AC-3
> additional substream(s)
> +int eac3_extension_type_a; ///< bitstream has E-AC-3
> extension type A enabled frame(s)
> int dolby_surround_mode;///< dolby surround mode
>(dsurmod)
> int dolby_surround_ex_mode; ///< dolby surround ex mode
>(dsurexmod)
> int dolby_headphone_mode; ///< dolby headphone mode
>(dheadphonmod)
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 39881a1d2b..0e85dd50a4 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1591,6 +1591,8 @@ typedef struct AVCodecContext {
> #define FF_PROFILE_DTS_HD_MA 60
> #define FF_PROFILE_DTS_EXPRESS 70
>
> +#define FF_PROFILE_EAC3_DDP_ATMOS 30
> +
> #define FF_PROFILE_MPEG2_4220
> #define FF_PROFILE_MPEG2_HIGH 1
> #define FF_PROFILE_MPEG2_SS 2
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 199f62df15..4098d4f5a5 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -2931,6 +2931,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
> .name = "eac3",
> .long_name = NULL_IF_CONFIG_SMALL("ATSC A/52B (AC-3, E-AC-3)"),
> .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
> +.profiles = NULL_IF_CONFIG_SMALL(ff_eac3_profiles),
> },
> {
> .id= AV_CODEC_ID_SIPR,
> diff --git a/libavcodec/eac3dec.c b/libavcodec/eac3dec.c
> index deca51dd3d..5c71751a0c 100644
> --- a/libavcodec/eac3dec.c
> +++ b/libavcodec/eac3dec.c
> @@ -464,7 +464,16 @@ static int ff_eac3_parse_header(AC3DecodeContext *s)
> if (get_bits1(gbc)) {
> int addbsil = get_bits(gbc, 6);
> for (i = 0; i < addbsil + 1; i++) {
> -skip_bits(gbc, 8); // skip additional bit stream info
> +if (i == 0) {
> +/* In this 8 bit chunk, the LSB is equal to
> flag_ec3_extension_type_a
> + which can be used to detect Atmos presence */
> +skip_bits(gbc, 7);
> +if (get_bits1(gbc)) {
> +s->eac3_extension_type_a = 1;
> +}
> +} else {
> +skip_bits(gbc, 8); // skip additional bit stream info
> +}
> }
> }
>
> diff --git a/libavcodec/profiles.c b/libavcodec/profiles.c
> index 7af7fbeb13..343b08f363 100644
> --- a/libavcodec/profiles.c
> +++ b/libavcodec/profiles.c
> @@ -45,6 +45,11 @@ const AVProfile ff_dca_profiles[] = {
> { FF_PROFILE_UNKNOWN },
> };
>
> +const AVProfile ff_eac3_profiles[] = {
> + { FF_PROFILE_EAC3_DDP_ATMOS, "Dolby Digital Plus + Dolby Atmos"},
> + { FF_PROFILE_UNKNOWN },
> +};
> +
> const AVProfile ff_dnxhd_profiles[] = {
>{ FF_PROFILE_DNXHD, "DNXHD"},
>{ FF_PROFILE_DNXHR_LB, "DNXHR LB"},
> diff --git a/libavcodec/profiles.h b/libavcodec/profiles.h
> index 41a19aa9ad..6ebedbd03f 100644
> --- a/libavcodec/profiles.h
> +++ b/libavcodec/profiles.h
> @@ -58,6 +58,7 @@
>
> extern const AVProfile ff_aac_profiles[];
> extern const AVProfile ff_dca_profiles[];
> +extern const AVProfile ff_eac3_profiles[];
> extern const AVProfile ff_dnxhd_profiles[];
> extern const AVProfile ff_h264_profiles[];
> extern const AVProfile ff_hevc_profiles[];
> --
> 2.25.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc: deprecate avcodec_dct, av_fft, av_dct, av_rdft and av_mdct
On Fri, Feb 17, 2023 at 7:45 PM Lynne wrote: > > Feb 17, 2023, 18:08 by jamr...@gmail.com: > > > On 2/17/2023 1:54 PM, Lynne wrote: > > > >> This reverts commit 26cb36f35746fe6ef53688b119852bfa6d555f62. > >> > >> All filters and all codecs (except wmavoice) have been ported for the > >> lavu/tx API. > >> > >> The noise should be minimal. > >> > > > > It isn't. I'm getting more than two thousand lines of warnings after > > applying this patch from > > > > libavfilter/vf_spp.c > > libavfilter/x86/vf_spp.c > > libavcodec/asvenc.c > > libavcodec/avdct.c > > libavcodec/avfft.c > > libavcodec/dct.c > > libavcodec/fdctdsp.c > > libavcodec/fft_float.c > > libavcodec/fft_init_table.c > > libavcodec/idctdsp.c > > libavcodec/jfdctfst.c > > libavcodec/jfdctint.c > > libavcodec/jrevdct.c > > libavcodec/mpegaudiodsp.c > > libavcodec/mpegvideo_enc.c > > libavcodec/rdft.c > > libavcodec/wmavoice.c > > libavcodec/x86/dct_init.c > > libavcodec/x86/fft_init.c > > libavcodec/x86/mpegvideoenc.c > > > > It's not just wmavoice, there's also mpeg and jpeg stuff, and one filter. > > For the actual fft/dct/rdft/mdct source files, you should use the > > deprecation warning pragmas to silence them, but the other modules need to > > be ported. > > This patch is also missing the schedule FF_API deprecation wrapper. > > > > Is the noise acceptable if I just deprecate the functions? > It wasn't before, but it should be much less now. An API we still use internally doesn't seem very deprecated to me. Should get rid of it, then there won't be any warnings. - Hendrik ___ 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 00/72] Implement support for Vulkan multiplane images and video decoding
On Fri, Feb 17, 2023 at 10:09 AM Jean-Baptiste Kempf wrote: > > Hello, > > On Fri, 17 Feb 2023, at 04:43, Lynne wrote: > > This small patchset mostly rewrites Vulkan to enable using multiplane > > images, > > This is not small. We're talking about thousands of lines of code; > > And this changes numerous h264 and hevc headers, and adds callback to the > make AVHWAccel. > > And that is besides the full rewrite of some Vulkan files... > > This will take a long time to review. > I would agree, this set is too large to try to skirt it in just under the deadline of a new release, with the potential of needing to fix stuff later. Just have it land on master after the branch, and there is no time pressure to review it, or make numerous fixes on the release branch. PS: Can you please send it as a proper patchset? Reviewing 72 patches off of one mail is not really fitting the workflow at all. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffprobe/eac3/mlp/dca: add detection of spatial audio extensions
On Sun, Feb 12, 2023 at 1:53 AM Marth64 wrote:
> diff --git a/libavcodec/dca_syncwords.h b/libavcodec/dca_syncwords.h
> index 4d2cd5f56d..200702f89e 100644
> --- a/libavcodec/dca_syncwords.h
> +++ b/libavcodec/dca_syncwords.h
> @@ -33,4 +33,7 @@
> #defineDCA_SYNCWORD_SUBSTREAM_CORE 0x02B09261U
> #defineDCA_SYNCWORD_REV1AUX 0x9A1105A0U
>
> +#defineDCA_SYNCWORD_XLL_X0x00020008U
> +#defineDCA_SYNCWORD_XLL_X_IMAX 0x00F14000U
> +
> #endif /* AVCODEC_DCA_SYNCWORDS_H */
> diff --git a/libavcodec/dca_xll.c b/libavcodec/dca_xll.c
> index fe2c766d98..efbbae67f8 100644
> --- a/libavcodec/dca_xll.c
> +++ b/libavcodec/dca_xll.c
> @@ -19,6 +19,7 @@
> */
>
> #include "libavutil/channel_layout.h"
> +#include "avcodec.h"
> #include "dcadec.h"
> #include "dcadata.h"
> #include "dcamath.h"
> @@ -1043,6 +1044,7 @@ static int parse_band_data(DCAXllDecoder *s)
> static int parse_frame(DCAXllDecoder *s, const uint8_t *data, int size,
> DCAExssAsset *asset)
> {
> int ret;
> +int extradata_peek_pos;
>
> if ((ret = init_get_bits8(&s->gb, data, size)) < 0)
> return ret;
> @@ -1054,10 +1056,23 @@ static int parse_frame(DCAXllDecoder *s, const
> uint8_t *data, int size, DCAExssA
> return ret;
> if ((ret = parse_band_data(s)) < 0)
> return ret;
> +
> +extradata_peek_pos = (get_bits_count(&s->gb) + 31) & ~31;
> +if (s->frame_size * 8 > extradata_peek_pos) {
> +unsigned int extradata_syncword = show_bits_long(&s->gb, 32);
> +
> +if (extradata_syncword == DCA_SYNCWORD_XLL_X) {
> +s->x_syncword_present = 1;
> +} else if (extradata_syncword == DCA_SYNCWORD_XLL_X_IMAX) {
> +s->x_imax_syncword_present = 1;
> +}
> +}
> +
I was testing this, and the DTS detections were not very reliable for
me. This is what I came up with instead:
#defineDCA_SYNCWORD_XLL_X0x02000850U
#defineDCA_SYNCWORD_XLL_X_IMAX 0xF14000D0U
if (s->frame_size * 8 > FFALIGN(get_bits_count(&s->gb), 32)) {
unsigned int extradata_syncword;
// align to dword
skip_bits_long(&s->gb, -get_bits_count(&s->gb) & 31);
// get sync code
extradata_syncword = show_bits_long(&s->gb, 32);
if (extradata_syncword == DCA_SYNCWORD_XLL_X) {
s->x_syncword_present = 1;
} else if ((extradata_syncword >> 1) ==
(DCA_SYNCWORD_XLL_X_IMAX >> 1)) {
s->x_imax_syncword_present = 1;
}
}
I don't have many DTS:X discs, but this worked on them, the old code did not.
Aligning to DWORD for a new section is a typical DTS thing to do,
which then also resulted in the syncwords to shift a bit, and actually
include more digits.
The IMAX case is a bit weird, there seems to be an extra bit in there
thats not stable, so shifting it out improves the detection (or it
could be masked out, but same difference).
- Hendrik
___
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] mswindres: Use '-' instead of '/' for rc.exe options
On Thu, Feb 9, 2023 at 10:02 PM Ziemowit Laski wrote: > > > FWIW, this setup is definitely being used by lots of others already - so > > whenever there's such an issue, the main question to ask is why others > > haven't run into the issue before. But improvements are definitely > > welcome! > > You have to have PATH set up so that rc.exe is found inside the Windows SDK. > This is NOT the default behavior. Usually, you would have to invoke the > 'Developer Command Prompt' from the start menu to get the correct environment. > > But I have my system set up so that the Microsoft tools are ALWAYS found, > regardless of which shell you are running. That could explain the different > behavior that I'm seeing. > > > You should probably talk about the option '/nologo' here, there's no > > '/logo' option afaik. > > Yes, good catch, thanks. > > > These changes seem fine, but you're apparently not touching the case at > > the top, used for --version, where it is calling 'rc.exe /?'. For me, this > > That's an interesting point. I guess MinGW is "smart enough" not to rewrite > "/?" because it doesn't represent a valid path to begin with. I will change > it to "-?" as you suggest. > You would think so, but attempting to run rc.exe /? straight from a msys bash prompt over here does come up with an invalid file error, so definitely better to fix it. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffprobe/eac3/mlp/dca: add detection of spatial audio extensions
On Thu, Feb 9, 2023 at 5:42 AM Marth64 wrote: > > Signed-off-by: Marth64 > --- > Adds detection of spatial/object-based audio extensions in E-AC-3, > TrueHD, and DCA XLL (DTS). This includes Atmos, DTS:X, and IMAX formats. > Please let me know what I could improve, I'm learning still. > Thank you. > The detection itself seems fine to me, however we should talk about how the presence is communicated back to the user. A new flag in AVCodecContext goes against a variety of designs we try to avoid - namely having codec-specific things in a global struct, as well as having only one value, rather then per-frame values. So options that present themself to me: (a) Use "profile". At least for DTS that would fit quite nicely, as it already has profiles, and it seems like a logical extension. TrueHD and eac3 do not have profiles, but it might still be sensible to put it there. The advantage here is that it also automatically is conveyed in AVCodecParameters after avformat opens a stream, so the information is available early and lets players decide how to handle the stream. (b) Use per-frame side data. The early-availability advantage is not present here, so its not my favorite. side-data could be used in the future to transport the actual object metadata, if needed. So from where I'm standing we should maybe define profiles to use for these. In the past profiles were at least suggested for TrueHD Atmos before, but there were some objections, so maybe a good time to revisit and see where we go from here. - Hendrik ___ 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] Request for assistance with adding new pixel format (NV12_8L128) in FFmpeg
On Wed, Feb 8, 2023 at 2:08 PM Jean-Baptiste Kempf wrote: > > On Wed, 8 Feb 2023, at 10:47, Le Bao Tin Ha wrote: > > Hello, you can found the explanation here: > > > > https://docs.kernel.org/userspace-api/media/v4l/pixfmt-yuv-planar.html > > > > "V4L2_PIX_FMT_NV12M_8L128 is similar to V4L2_PIX_FMT_NV12M but stores > > pixels in 2D 8x128 tiles, and stores tiles linearly in memory. The > > image height must be aligned to a multiple of 128. The layouts of the > > luma and chroma planes are identical. > > > > V4L2_PIX_FMT_NV12_8L128 is similar to V4L2_PIX_FMT_NV12M_8L128 but > > stores two planes in one memory." > > Do we really need those PIX_FMT in FFmpeg public API? > Tiled formats also really don't fit into our format definitions, and would not work with any generic pixel format handling code, as far as I can tell. - Hendrik ___ 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] configure: add --disable-he-aac option
On Wed, Feb 1, 2023 at 3:33 PM Kristofer Björkström wrote: > > From 6828ea418f0209dface9fbb23ff4657f66988f5e Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Kristofer=20Bj=C3=B6rkstr=C3=B6m?= > Date: Wed, 1 Feb 2023 15:15:14 +0100 > Subject: [PATCH] configure: add --disable-he-aac option > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > Make it possible to disable HE and HEv2 support for AAC. To avoid > patents in HE-AAC. > I don't feel like this adds a good precedence to our codebase. We generally ignore patents, because every codec is littered with them. Having options to cherry-pick which patents are enabled and which are not is not only very ugly, but also impossible to track or make any guarantees on, so I think we should not even start. - Hendrik ___ 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 00/26] Major library version bump
On Sat, Jan 21, 2023 at 10:30 PM Marvin Scholz wrote: > > Or do you mean that there should be a public devel branch where API/ABI > breaking patches can be proposed for that will eventually be merged into > master at a defined point in time together with major bump? > Yes, I'm talking about one centrally managed branch that contributors can merge their breaking changes to, and we can test it all in one piece, and then when the time comes, that one branch would get merged into master. - Hendrik ___ 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 00/26] Major library version bump
On Sat, Jan 21, 2023 at 8:33 PM Marvin Scholz wrote: > > > > Alternatively, we could just not have an instability period at all. > > > > Not having any instability period at all seems like a bad idea. > Actually that sounds like the best idea. You would just have to prepare the bump in a branch and all unstable changes ready to merge in an instant. Miss it? Tough. Having months long periods so people can get their stuff sorted is way too long. Ideally it should be prepared ahead of time and only a "soft instability" period of maybe two weeks reserved for bug fixes (don't want to sit on issues for ever), rather then big changes or new features. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: Use preprocessors conditions
On Tue, Jan 17, 2023 at 3:36 PM wrote:
>
> From: Pawday
>
> Thank you Andreas Rheinhardt for review
>
> Here the fixes for runtime "else" conditions
>
> ---
> libavcodec/avcodec.c | 16 +++-
> libavcodec/decode.c | 11 ---
> libavcodec/encode.c | 13 -
> libavcodec/h264dec.c | 14 +++---
> 4 files changed, 34 insertions(+), 20 deletions(-)
>
> diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
> index a85d3c2309..0e792aead9 100644
> --- a/libavcodec/avcodec.c
> +++ b/libavcodec/avcodec.c
> @@ -403,10 +403,13 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
> av_frame_unref(avci->buffer_frame);
> av_packet_unref(avci->buffer_pkt);
>
> -if (HAVE_THREADS && avctx->active_thread_type & FF_THREAD_FRAME)
> +#if HAVE_THREADS
> +if (avctx->active_thread_type & FF_THREAD_FRAME)
> ff_thread_flush(avctx);
> -else if (ffcodec(avctx->codec)->flush)
> +#else
> +if (ffcodec(avctx->codec)->flush)
> ffcodec(avctx->codec)->flush(avctx);
> +#endif
> }
>
The before and after behavior are not identical. Just because threads
are supported does not imply they are always used.
> void avsubtitle_free(AVSubtitle *sub)
> @@ -441,12 +444,15 @@ av_cold int avcodec_close(AVCodecContext *avctx)
> if (avcodec_is_open(avctx)) {
> AVCodecInternal *avci = avctx->internal;
>
> -if (CONFIG_FRAME_THREAD_ENCODER &&
> -avci->frame_thread_encoder && avctx->thread_count > 1) {
> +#if CONFIG_FRAME_THREAD_ENCODER
> +if (avci->frame_thread_encoder && avctx->thread_count > 1) {
> ff_frame_thread_encoder_free(avctx);
> }
> -if (HAVE_THREADS && avci->thread_ctx)
> +#endif
> +#if HAVE_THREADS
> +if (avci->thread_ctx)
> ff_thread_free(avctx);
> +#endif
> if (avci->needs_close && ffcodec(avctx->codec)->close)
> ffcodec(avctx->codec)->close(avctx);
> avci->byte_buffer_size = 0;
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 6be2d3d6ed..54ffd0f203 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -300,10 +300,14 @@ static inline int decode_simple_internal(AVCodecContext
> *avctx, AVFrame *frame,
> return AVERROR_EOF;
>
> got_frame = 0;
> -
> -if (HAVE_THREADS && avctx->active_thread_type & FF_THREAD_FRAME) {
> +#if HAVE_THREADS
> +if (avctx->active_thread_type & FF_THREAD_FRAME) {
> ret = ff_thread_decode_frame(avctx, frame, &got_frame, pkt);
> -} else {
> +}
> +#endif
> +
> +#if !HAVE_THREADS
> +if (!(avctx->active_thread_type & FF_THREAD_FRAME)) {
Same issue here. Threads are not always active even if supported.
> ret = codec->cb.decode(avctx, frame, &got_frame, pkt);
>
> if (!(codec->caps_internal & FF_CODEC_CAP_SETS_PKT_DTS))
> @@ -321,6 +325,7 @@ static inline int decode_simple_internal(AVCodecContext
> *avctx, AVFrame *frame,
> }
> }
> }
> +#endif
> emms_c();
> actual_got_frame = got_frame;
>
> diff --git a/libavcodec/encode.c b/libavcodec/encode.c
> index fbe2c97cd6..b19599e67e 100644
> --- a/libavcodec/encode.c
> +++ b/libavcodec/encode.c
> @@ -269,17 +269,20 @@ static int encode_simple_internal(AVCodecContext
> *avctx, AVPacket *avpkt)
> got_packet = 0;
>
> av_assert0(codec->cb_type == FF_CODEC_CB_TYPE_ENCODE);
> -
> -if (CONFIG_FRAME_THREAD_ENCODER && avci->frame_thread_encoder)
> +#if CONFIG_FRAME_THREAD_ENCODER
> +if (avci->frame_thread_encoder)
> /* This will unref frame. */
> ret = ff_thread_video_encode_frame(avctx, avpkt, frame, &got_packet);
> -else {
> +#endif
> +#if !CONFIG_FRAME_THREAD_ENCODER
> +if (!avci->frame_thread_encoder) {
> ret = ff_encode_encode_cb(avctx, avpkt, frame, &got_packet);
And here..
> #if FF_API_THREAD_SAFE_CALLBACKS
> if (frame)
> av_frame_unref(frame);
> #endif
> }
> +#endif // !CONFIG_FRAME_THREAD_ENCODER
>
> if (avci->draining && !got_packet)
> avci->draining_done = 1;
> @@ -670,11 +673,11 @@ int ff_encode_preinit(AVCodecContext *avctx)
> return AVERROR(ENOMEM);
> }
>
> -if (CONFIG_FRAME_THREAD_ENCODER) {
> +#if CONFIG_FRAME_THREAD_ENCODER
> ret = ff_frame_thread_encoder_init(avctx);
> if (ret < 0)
> return ret;
> -}
> +#endif
>
> return 0;
> }
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index 6ede4e8c9f..4538974dab 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -933,13 +933,13 @@ static int finalize_frame(H264Context *h, AVFrame *dst,
> H264Picture *out, int *g
>
> *got_frame = 1;
>
> -if (CONFIG_MPEGVIDEODEC) {
> -ff_print_debug_info2(h->avctx, dst, NULL,
> - out->mb_type,
> - out->qscale_table,
> - out->motion_val,
> -
