Builder ffmpegsos-solaris10-sparc Build #14027

Results:

Failed shell_2 shell_3 shell_4 shell_5

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-ffmpegsos-solaris10-sparc' triggered this build

Steps and Logfiles:

1. git update ( 18 secs )
   1. stdio
2. shell 'gsed -i ...' ( 0 secs )
   1. stdio
3. shell_1 'gsed -i ...' ( 0 secs )
   1. stdio
4. shell_2 'gsed -i ...' failed ( 0 secs )
   1. stdio
5. shell_3 './configure --samples="../../../ffmpeg/fate-suite" ...' failed ( 10 secs )
   1. stdio
   2. config.log
6. shell_4 'gmake fate-rsync' failed ( 0 secs )
   1. stdio
7. shell_5 '../../../ffmpeg/fate.sh ../../../ffmpeg/fate_config_sos.sh' failed ( 0 secs )
   1. stdio
   2. configure.log
   3. compile.log
   4. test.log

Build Properties:

Forced Build Properties:

Responsible Users:

1. Julius Bairaktaris

   juliusohnoyoudont@bairaktaris.de

Timing:

All Changes:

:

1. Change #281977

   Category	ffmpeg
   Changed by	Julius Bairaktaris <juliusohnoyoudont@bairaktaris.de>
   Changed at	Thu 17 Sep 2026 00:05:28
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	7f9391b76a13e0628a7757079dc3b39d75ea54f4

   Comments

   avfilter/vf_sr_amf: fix solid green frame with algorithm=sr1-1
   Per AMD's AMF_HQ_Scaler_API.md, the HQ Scaler's VideoSR1.1 algorithm is
   only supported on a DX11/DX12 engine and with input/output formats other
   than NV12 or P010 (it accepts packed RGB: BGRA, RGBA, R10G10B10A2 or
   RGBA_F16). The filter however advertised NV12/P010 as valid input and
   passed the input format straight to AMFHQScaler::Init(), which returns
   AMF_OK even for the unsupported format. The existing result check
   therefore never fired and the filter silently emitted a solid green
   frame.
   
   When algorithm=sr1-1, restrict the negotiated formats to the packed 8-bit
   RGB formats RGBA and BGRA, which round-trip cleanly through the AMF
   hwcontext (both upload and hwdownload), so a converter is auto-inserted
   for YUV input, and reject an unsupported hardware surface explicitly in
   config_output instead of producing green. The other SR1.1-capable formats
   (R10G10B10A2, RGBA_F16) are not exposed: they are absent from the AMF
   hwcontext's supported_formats[]/supported_transfer_formats[], so an AMF
   frames context cannot use them and hwdownload would fail with ENOSYS;
   exposing them belongs in a separate hwcontext_amf change.
   
   Note that AMF's VideoSR algorithms (sr1-0 and sr1-1) leave the alpha
   channel zeroed and expose no property to control it; drop alpha
   downstream, e.g. with format=rgb24, for an opaque result.
   
   Refs AMD AMF_HQ_Scaler_API.md and mpv-player/mpv#18068.
   
   Assisted-by: Claude Opus 5
   Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>

   Changed files

   • doc/filters.texi
   • libavfilter/vf_sr_amf.c

2. Change #281978

   Category	ffmpeg
   Changed by	Julius Bairaktaris <juliusohnoyoudont@bairaktaris.de>
   Changed at	Thu 17 Sep 2026 00:05:28
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	3409e8060cf1a74a82432842e69bbf88b4954a0c

   Comments

   avfilter/vf_sr_amf: fix solid green frame with algorithm=point
   AMF returns an unwritten surface for AMF_HQ_SCALER_ALGORITHM_POINT when
   the surface format is NV12 or P010, exactly as it does for VideoSR1.1 on
   YUV: Init(), SubmitInput() and QueryOutput() all report AMF_OK and the
   output is a solid green frame. Unlike VideoSR1.1 this is not a documented
   limitation - point is listed as a plain scaling algorithm with no format
   restriction - and it has been open on AMD's tracker since 2023.
   
   Reuse the sr1-1 handling: negotiate the packed 8-bit RGB formats for
   point as well, so a converter is auto-inserted for YUV input, and reject
   an NV12/P010-backed hardware surface in config_output instead of emitting
   green.
   
   Reproduced with:
   
     ffmpeg -init_hw_device amf -f lavfi -i testsrc2=size=1280x720 \
       -vf "format=nv12,hwupload,sr_amf=w=2560:h=1440:algorithm=point,\
   hwdownload,format=nv12,format=rgb24" -frames:v 1 out.png
   
   Before this patch the output is a single flat green frame. After it that
   hardware NV12 input is rejected at configuration with an error naming
   the formats point accepts; a later commit converts it on the GPU
   instead. Software YUV input goes through the converter negotiation
   inserts and matches bilinear, bicubic and sr1-0:
   
     ffmpeg -init_hw_device amf -f lavfi -i testsrc2=size=1280x720 \
       -vf "format=nv12,sr_amf=w=2560:h=1440:algorithm=point,\
   hwdownload,format=rgba,format=rgb24" -frames:v 1 out.png
   
   Tested on Windows 11, RX 9070 XT, driver 32.0.31041.1004.
   
   Refs https://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues/427
   
   Assisted-by: Claude Opus 5
   Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>

   Changed files

   • doc/filters.texi
   • libavfilter/vf_sr_amf.c

3. Change #281979

   Category	ffmpeg
   Changed by	Julius Bairaktaris <juliusohnoyoudont@bairaktaris.de>
   Changed at	Thu 17 Sep 2026 00:05:28
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	de15c3678b28968d34ea461950d9af7018cfe015

   Comments

   avutil/hwcontext_amf: allow X2BGR10 and RGBAF16 frames contexts
   Both formats are already in format_map[] and map to AMF_SURFACE_R10G10B10A2
   and AMF_SURFACE_RGBA_F16, but they were missing from supported_formats[]
   and supported_transfer_formats[]. An AMF frames context could therefore
   not use them as sw_format, and hwupload/hwdownload rejected them, which
   in turn kept the AMF filters from offering the two formats AMF's HQ
   Scaler needs for HDR.
   
   Both are single-plane packed formats, so the existing transfer paths
   handle them unchanged: amf_transfer_data_to/from derive plane count from
   the surface and copy with av_image_copy2().
   
   Verified on Windows 11, RX 9070 XT, driver 32.0.31035.1003:
   
     ffmpeg -init_hw_device amf -f lavfi -i testsrc2=size=640x360 \
       -vf "format=x2bgr10le,hwupload,hwdownload,format=x2bgr10le" -f null -
   
   passes where it previously failed with "Invalid output format x2bgr10le
   for hwframe download", and a rawvideo rgbaf16le round-trip through
   hwupload,hwdownload comes back bit-exact.
   
   Assisted-by: Claude Opus 5
   Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>

   Changed files

   • libavutil/hwcontext_amf.c

4. Change #281980

   Category	ffmpeg
   Changed by	Julius Bairaktaris <juliusohnoyoudont@bairaktaris.de>
   Changed at	Thu 17 Sep 2026 00:05:28
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	7a1a02fa0368c8d1f42e5030505b52e127fe0853

   Comments

   avfilter/vf_sr_amf: offer 10-bit and f16 packed RGB
   AMF's HQ Scaler accepts R10G10B10A2 and RGBA_F16 for the algorithms that
   require packed RGB, but the filter only offered RGBA and BGRA because an
   AMF frames context could not carry the other two. Now that
   hwcontext_amf supports them, add them to the negotiated list so a 10-bit
   or half-float source is no longer forced down to 8-bit RGB.
   
   Tested on Windows 11, RX 9070 XT, driver 32.0.31035.1003: sr1-1, point,
   sr1-0 and bilinear all produce correct output for x2bgr10le and
   rgbaf16le input at 1280x720 -> 2560x1440.
   
   Assisted-by: Claude Opus 5
   Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>

   Changed files

   • doc/filters.texi
   • libavfilter/vf_sr_amf.c

5. Change #281981

   Category	ffmpeg
   Changed by	Julius Bairaktaris <juliusohnoyoudont@bairaktaris.de>
   Changed at	Thu 17 Sep 2026 00:05:28
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	7db554bacfe56e001885baf5873956a7bccae89b

   Comments

   avfilter/vf_sr_amf: convert YUV input on the GPU for sr1-1 and point
   sr1-1 and point need a packed RGB surface. Software input was handled by
   restricting the negotiated formats so libavfilter inserts a converter,
   but a hardware surface backed by NV12 or P010 could only be rejected,
   which made both algorithms unusable with any AMF or D3D11VA producer
   upstream - including every player that hands libavfilter its decoder
   frames.
   
   Chain an AMFVideoConverter ahead of the scaler in that case instead. The
   conversion stays on the GPU, so no download is introduced, and the
   component is driven from the shared filter_frame path through a new
   pre_converter field.
   
   The HQ scaler has no output format property and emits the format it was
   initialised with, so one packed RGB target drives the converter output
   format, AMFHQScaler::Init() and the output frames context alike. P010
   converts to X2BGR10 and NV12 to RGBA by default; an explicit format= is
   kept when it names a packed RGB format and rejected otherwise. Where no
   conversion is needed the scaler cannot change the format at all, so an
   explicit format= differing from the input is rejected and the target is
   pinned to the input format, rather than letting the output link negotiate
   a frames context that disagrees with the surface the scaler produces.
   
   AMD's Video Converter programming guide has the caller poll for output and
   stop submitting while the component reports AMF_INPUT_FULL, so both calls
   are retried instead of turning a valid asynchronous state into a dropped
   frame or an error. The component runs synchronously on the tested device
   and the retry never triggers there.
   
   The converter is asked for full range output, and the converted frame is
   tagged AVCOL_SPC_RGB with AVCOL_RANGE_JPEG rather than inheriting the
   input's YUV matrix.
   
   The output frames context follows the converted format, so the filter
   emits packed RGB where it previously emitted NV12; with format=same this
   is only reachable for the two algorithms that cannot produce YUV anyway.
   
   Tested on Windows 11, RX 9070 XT, driver 32.0.31041.1004, with
   -hwaccel amf -hwaccel_output_format amf: point and sr1-1 measure
   YMIN=YAVG=YMAX=0 before this change and match the plain decode to within
   0.6/255 after, while bilinear, bicubic and sr1-0 keep their NV12 output.
   point at 2x scores 36.5 dB PSNR against a software neighbour reference,
   the converted frame is tagged pc/gbr, P010 reaches X2BGR10, the accepted
   and rejected format= values behave as described, and 300 frames run
   through the converter for both algorithms.
   
   Assisted-by: Claude Opus 5
   Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>

   Changed files

   • doc/filters.texi
   • libavfilter/vf_amf_common.c
   • libavfilter/vf_amf_common.h
   • libavfilter/vf_sr_amf.c

6. Change #281982

   Category	ffmpeg
   Changed by	Julius Bairaktaris <juliusohnoyoudont@bairaktaris.de>
   Changed at	Thu 17 Sep 2026 00:05:28
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	1c2794eb2225948a29275bd2cc16108e966bd0a0

   Comments

   avfilter/amf: fix leaks and a NULL dereference in the filter frame path
   amf_filter_filter_frame() overwrote out->hw_frames_ctx with a second
   reference to the output frames context. av_hwframe_get_buffer(), called
   from amf_amfsurface_to_avframe() for every output, has already attached
   one, so each frame leaked a reference and the frames context never
   reached zero. Its AMF surface pool therefore survived filter teardown,
   which matters to anything that rebuilds a filter graph. vf_frc_amf.c had
   the same line.
   
   The function also takes ownership of the input frame but returned without
   freeing it on two paths, the QueryInterface() failure after QueryOutput()
   and the case with no output, and it passed the result of
   amf_amfsurface_to_avframe() to av_frame_copy_props() unchecked, so an
   allocation failure or an unsupported surface memory type dereferenced
   NULL. Route those through the existing fail label.
   
   amf_amfsurface_to_avframe() only takes ownership of the surface once it
   is attached to the frame, so its fail path and its frame allocation
   failure leaked the surface for both callers; release it in both, and
   check the av_buffer_create() that performs the attach.
   
   amf_setup_input_output_formats() leaked the input list when allocating
   the output list failed, and the output list when referencing the input
   list failed.
   
   Assisted-by: Claude Opus 5
   Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>

   Changed files

   • libavfilter/vf_amf_common.c
   • libavfilter/vf_frc_amf.c

7. Change #281983

   Category	ffmpeg
   Changed by	Julius Bairaktaris <juliusohnoyoudont@bairaktaris.de>
   Changed at	Thu 17 Sep 2026 00:05:28
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	f736784a52eeab4bdf7a8c2ed645a4b8e27dfeca

   Comments

   avfilter/amf: make the input format lists describe what AMF accepts
   amf_setup_input_output_formats() builds both negotiated lists from
   output_pix_fmts and ignores its input_pix_fmts argument, so the input
   lists have never been used and have drifted from what the filters handle.
   
   None of them lists AV_PIX_FMT_D3D11 or AV_PIX_FMT_DXVA2_VLD even though
   amf_avframe_to_amfsurface() wraps both. sr_amf and vpp_amf carry the two
   in their output lists, so they accept such input today only because the
   input list is dead; vqe_amf and frc_amf carry them nowhere and gain the
   input here. vpp_amf meanwhile lists three formats AMF will not take:
   YUV420P10 and 0RGB have no format_map[] entry at all, and the video
   converter rejects GRAY8 with AMF_NOT_SUPPORTED. Those three only appear
   to work today because the dead input list leaves libavfilter converting
   them in software first.
   
   vpp_amf also loses BGR0, RGB0 and YUYV422. The converter takes them as
   input, but with the default format=same the output frames context is
   created in the input format, and hwcontext_amf cannot back an AMF frames
   context with RGB0 or YUYV422, nor download BGR0. Once the list is live,
   each of the three would fail at configuration or at hwdownload where
   libavfilter converts it in software today, so they stay out until
   hwcontext_amf supports them.
   
   Correct the lists in both directions so they describe reality before the
   helper is made to use them. No functional change on its own.
   
   Assisted-by: Claude Opus 5
   Assisted-by: Claude Fable 5.1
   Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>

   Changed files

   • libavfilter/vf_frc_amf.c
   • libavfilter/vf_sr_amf.c
   • libavfilter/vf_vpp_amf.c
   • libavfilter/vf_vqe_amf.c

8. Change #281984

   Category	ffmpeg
   Changed by	Julius Bairaktaris <juliusohnoyoudont@bairaktaris.de>
   Changed at	Thu 17 Sep 2026 00:05:28
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	42cd61a1548e905a08289e0438d12c5e37b957c1

   Comments

   avfilter/amf: negotiate the input link from the input format list
   amf_setup_input_output_formats() built both negotiated lists from
   output_pix_fmts, so every filter's input_pix_fmts argument was dead and
   the input link only ever offered what the filter could output.
   
   For vpp_amf, whose input list is deliberately wider than its output list,
   libavfilter therefore inserted a software conversion in front of the
   filter for any input format missing from the output list. P010 is the
   damaging case: 10-bit software input was silently reduced to 8-bit
   YUV420P before being uploaded, and the filter was then asked to convert
   that back to P010.
   
   Build input_formats from input_pix_fmts, and apply the D3D11VA and DXVA2
   device overrides to both lists, which the old code got for free by
   sharing one list.
   
   Fixes the FFmpeg side of #21620. With
     -f lavfi -i "smptehdbars=d=1,format=p010le" -vf "vpp_amf=format=p010le"
   signalstats YAVG moves from 432.141 to 413.631, matching the untouched
   P010 source exactly, and the p010le -> yuv420p conversion no longer
   appears in the filter graph. The 8-bit-to-P010 half of that report is an
   AMF limitation and is unaffected.
   
   Tested on Windows 11, RX 9070 XT, driver 32.0.31041.1004: vpp_amf,
   vqe_amf, frc_amf and every sr_amf algorithm, with AMF hardware surfaces
   and with NV12, YUV420P, YUV420P10, YUYV422, GRAY8, 0RGB, RGB0, BGR0,
   P010, RGBA and BGRA software input. No case that worked before stopped
   working; software P010 and RGBA into vpp_amf now work where they
   previously failed.
   
   Assisted-by: Claude Opus 5
   Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>

   Changed files

   • libavfilter/vf_amf_common.c

9. Change #281985

   Category	ffmpeg
   Changed by	Julius Bairaktaris <juliusohnoyoudont@bairaktaris.de>
   Changed at	Thu 17 Sep 2026 00:05:28
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	29b5a4f52d8dab4c2fae963582d84bc091c78f3f

   Comments

   avfilter/amf: pin the output format for components that cannot convert
   amf_init_filter_config() falls back to outlink->format for the output
   frames context when no format is requested. That is right for vpp_amf,
   whose converter is initialised from hwframes_out->sw_format and therefore
   makes the frames context true. The HQ scaler, the VQ enhancer and the
   frame rate converter have no output format property at all and emit the
   format they were initialised with, so whatever the output link happened
   to negotiate was attached to a surface that never had that layout.
   
     ffmpeg -init_hw_device amf -f lavfi -i testsrc2 \
       -vf "format=nv12,hwupload,sr_amf=w=2560:h=1440,format=rgba"
   
   is enough to reach it: the link negotiates RGBA, the scaler emits NV12,
   and hwdownload then reads a two-plane surface as one packed plane.
   
   Take the input software format as the output format for those three
   filters. sr_amf keeps its explicit format= handling: a packed RGB target
   is still selectable for the algorithms that convert, and anything the
   scaler cannot emit is rejected rather than silently mislabelled.
   
   amf_inlink_sw_format() moves to vf_amf_common.c so all three can use it.
   sr_amf compares against the format the user asked for rather than the one
   a previous configuration resolved, so reconfiguring the graph with a
   different input format does not reject itself.
   
   Tested on Windows 11, RX 9070 XT, driver 32.0.31041.1004: for every
   sr_amf algorithm and for vqe_amf and frc_amf, with NV12, P010 and RGBA
   input, hwdownload now accepts exactly the format the component emits and
   rejects every other, where before the frames context could claim any
   format the output link negotiated.
   
   Assisted-by: Claude Opus 5
   Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>

   Changed files

   • libavfilter/vf_amf_common.c
   • libavfilter/vf_amf_common.h
   • libavfilter/vf_frc_amf.c
   • libavfilter/vf_sr_amf.c
   • libavfilter/vf_vqe_amf.c

10. Change #281986

    Category	ffmpeg
    Changed by	Julius Bairaktaris <juliusohnoyoudont@bairaktaris.de>
    Changed at	Thu 17 Sep 2026 00:05:28
    Repository	https://git.ffmpeg.org/ffmpeg.git
    Project	ffmpeg
    Branch	master
    Revision	23e21331dfc21cb2ad344751fb6941e803546ca5

    Comments

    avfilter/vf_amf_common: drain the component and tolerate AMF_REPEAT
    amf_filter_filter_frame() read the component output exactly once and
    treated anything but AMF_OK as fatal, so a component that had no output
    ready yet, which AMD's Video Converter programming guide documents as
    AMF_REPEAT, produced an error instead of simply consuming the frame.
    
    Poll until the component stops returning data, and accept AMF_REPEAT.
    A component that produces one output per input, which is what the scaler,
    the enhancer and the converter do today, behaves as before: one iteration
    with data, one without. Timestamps now come from the output surface, as
    vf_frc_amf.c already does, so a second output of the same submission does
    not inherit the first one's.
    
    Returning AVERROR(EAGAIN) from a filter_frame callback was wrong and is
    dropped. filter_frame_to_filter() latches a negative return into the
    link's status_out, which stalls a pull driven graph and stops EOF from
    crossing the filter; a frame that yields no output is simply consumed.
    
    AMF_INPUT_FULL on submission stays fatal. It means the frame was not
    accepted, so tolerating it would silently drop it, and the queue is
    already drained after every submission, so it cannot be reached by
    feeding the component faster than it produces.
    
    The input frame is kept until the loop ends, since its properties are
    copied onto every output, and freed once at the end.
    
    Tested on Windows 11, RX 9070 XT, driver 32.0.31041.1004: identical
    output and timestamps for every sr_amf algorithm, vpp_amf, vqe_amf and
    frc_amf, with software, AMF and D3D11VA input.
    
    Assisted-by: Claude Opus 5
    Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>

    Changed files

    • libavfilter/vf_amf_common.c

11. Change #281987

    Category	ffmpeg
    Changed by	Julius Bairaktaris <juliusohnoyoudont@bairaktaris.de>
    Changed at	Thu 17 Sep 2026 00:05:28
    Repository	https://git.ffmpeg.org/ffmpeg.git
    Project	ffmpeg
    Branch	master
    Revision	6fde766f19851a29da1fb2090c38154199bb00b0

    Comments

    avfilter/vf_vqe_amf: only offer the formats the VQ enhancer accepts
    vqe_amf advertised BGRA, RGBA, RGBAF16 and X2BGR10 alongside NV12 and
    P010, but AMFVQEnhancer::Init() rejects all four with AMF_INVALID_ARG.
    Now that the input list is used for negotiation, a packed RGB source
    reaches the filter and fails at configuration time instead of being
    converted to a format the component takes.
    
    Drop the four from both lists. libavfilter then converts such a source to
    NV12 in software and the filter works, where before it aborted. A
    hardware frames context is not covered by format negotiation, so reject
    an unsupported sw_format explicitly rather than leaving the user with
    AMF_INVALID_ARG from Init().
    
    The component's own capability query cannot be used to build this list.
    AMFVQEnhancer enumerates NV12, BGRA, ARGB, RGBA, P010, RGBA_F16 and
    R10G10B10A2 through GetCaps()/GetInputCaps(), each flagged native and
    stable across runs, but Init() accepts only NV12 and P010 and rejects the
    other five. AMFHQScaler and AMFVideoConverter do not have this problem,
    so the list cannot simply follow the query for every component. Reported
    as GPUOpen-LibrariesAndSDKs/AMF#610.
    
    Tested on Windows 11, RX 9070 XT, driver 32.0.31041.1004.
    
    Assisted-by: Claude Opus 5
    Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>

    Changed files

    • libavfilter/vf_vqe_amf.c

12. Change #281988

    Category	ffmpeg
    Changed by	Julius Bairaktaris <juliusohnoyoudont@bairaktaris.de>
    Changed at	Thu 17 Sep 2026 00:05:28
    Repository	https://git.ffmpeg.org/ffmpeg.git
    Project	ffmpeg
    Branch	master
    Revision	6896ab9eebe6397712560e806bc2cca19d5fc143

    Comments

    avfilter/amf: log CreateComponent failures on the filter context
    These four call sites pass the filter's private context to av_log() while
    every other call around them passes the AVFilterContext. Both happen to
    start with an AVClass, so nothing misbehaves, but the private class has
    no parent set, so the message loses the "[Parsed_sr_amf_0 @ ...]" prefix
    that identifies which filter instance failed.
    
    Assisted-by: Claude Opus 5
    Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>

    Changed files

    • libavfilter/vf_sr_amf.c
    • libavfilter/vf_vpp_amf.c
    • libavfilter/vsrc_amf.c

13. Change #281989

    Category	ffmpeg
    Changed by	Julius Bairaktaris <juliusohnoyoudont@bairaktaris.de>
    Changed at	Thu 17 Sep 2026 00:05:28
    Repository	https://git.ffmpeg.org/ffmpeg.git
    Project	ffmpeg
    Branch	master
    Revision	27afe04c3d2c119629517aa8ac3a4476b1c76fd9

    Comments

    avfilter/amf: copy D3D11 decoder textures the components can read
    The AMF filter components read their input with a shader and reject a
    texture created without D3D11_BIND_SHADER_RESOURCE, which is what a
    D3D11VA decoder pool provides. Every AMF filter therefore fails on
    
      ffmpeg -hwaccel d3d11va -hwaccel_output_format d3d11 \
             -i in.mp4 -vf vpp_amf ...
    
    with AMF_DIRECTX_FAILED from the first QueryOutput(), while frc_amf and
    the AMF encoders consume the same surfaces. The only way out was the
    device option SHADER=1, which the usual command lines do not set.
    
    Copy the slice into an AMF allocated surface, which carries the flags the
    components need. CopySubresourceRegion() runs on the copy engine, so it
    can read a decoder texture that a shader cannot. AMFSurface::Duplicate(),
    suggested upstream for this, returns AMF_OK but yields a surface that
    fails in exactly the same way, for AMF_MEMORY_DX11 and AMF_MEMORY_HOST
    alike.
    
    Only a frame whose texture lacks the flag is copied, so a pool created
    with SHADER=1 keeps the zero copy path, and only the components that need
    a shader readable input ask for the copy. The frame rate converter reads
    the decoder texture as it is, so it is left on the zero copy path through
    a flag on the shared filter context.
    
    Tested on Windows 11, RX 9070 XT, driver 32.0.31041.1004, with
    -hwaccel d3d11va -hwaccel_output_format d3d11: vpp_amf, vqe_amf and every
    sr_amf algorithm produce output matching the plain decode where they
    previously failed, and frc_amf is unchanged.
    
    Refs https://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues/605
    
    Assisted-by: Claude Opus 5
    Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>

    Changed files

    • libavfilter/vf_amf_common.c
    • libavfilter/vf_amf_common.h
    • libavfilter/vf_vqe_amf.c

14. Change #281990

    Category	ffmpeg
    Changed by	Julius Bairaktaris <juliusohnoyoudont@bairaktaris.de>
    Changed at	Thu 17 Sep 2026 00:05:28
    Repository	https://git.ffmpeg.org/ffmpeg.git
    Project	ffmpeg
    Branch	master
    Revision	25055dfba69847ba8bae60b7288f91628c73df43

    Comments

    avfilter/vf_sr_amf: let format= choose the packed format the scaler runs on
    For point and sr1-1 the input link offered all four packed RGB formats
    regardless of format=, so a software producer was converted to whichever
    one libavfilter picked, RGBA for NV12 and X2BGR10 for P010. The input was
    then already packed, no GPU conversion was set up, and a different
    explicit target was rejected as a format the scaler cannot produce:
    
      ffmpeg -f lavfi -i testsrc2,format=nv12 \
             -vf sr_amf=w=2560:h=1440:algorithm=point:format=bgra ...
    
    failed with "The HQ scaler does not convert formats" for a format the
    documentation advertises.
    
    Offer only the requested format on the input link when format= names one
    the filter accepts, next to the hardware formats, so libavfilter converts
    software input to that format directly. The hardware path reaches the
    same target through the GPU converter, which now also runs when a
    hardware surface is packed RGB but not the requested one, instead of
    being limited to NV12 and P010 sources.
    
    Tested on Windows 11, RX 9070 XT, driver 32.0.31041.1004: software and
    AMF surface NV12 and P010 input crossed with format=rgba, bgra and
    x2bgr10le, and hardware input for rgbaf16le, all produce a frame matching
    the source. rgbaf16le from software input stays unreachable because
    libswscale has no conversion to it, from any format.
    
    Assisted-by: Claude Opus 5
    Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>

    Changed files

    • doc/filters.texi
    • libavfilter/vf_sr_amf.c

15. Change #281991

    Category	ffmpeg
    Changed by	Julius Bairaktaris <juliusohnoyoudont@bairaktaris.de>
    Changed at	Thu 17 Sep 2026 00:05:28
    Repository	https://git.ffmpeg.org/ffmpeg.git
    Project	ffmpeg
    Branch	master
    Revision	35660a244de7b9a26bbaaf2cd2bd2ab95d3169c7

    Comments

    avfilter/amf: advertise only AMF surfaces on the output link
    amf_init_filter_config() always creates an AV_PIX_FMT_AMF_SURFACE frames
    context and amf_amfsurface_to_avframe() allocates every output frame from
    it, so an AMF filter returns an AMF surface no matter what the output link
    negotiated. The output format lists offered software formats and, for a
    D3D11VA or DXVA2 device, the foreign hardware format, so a downstream
    filter that takes one of them made the link agree on a format the filter
    never produces:
    
      ffmpeg -f lavfi -i testsrc2,format=nv12 \
             -vf vpp_amf=w=320:h=180:format=nv12,signalstats -f null -
    
    crashes, because signalstats reads an AMFSurface pointer as an NV12 plane.
    The frame carries the right format, so it is only the link that lies, but
    nothing downstream looks at that.
    
    Offer AV_PIX_FMT_AMF_SURFACE alone, which is what the hardware filters in
    the tree do. A software consumer now needs an explicit hwdownload, which
    was already the only way to get a correct software frame out of these
    filters, and negotiation fails at configuration time instead of handing
    out a mislabelled surface. The device type still selects the input format,
    where D3D11 and DXVA2 surfaces really are what the filter is handed.
    
    The documentation examples and the sr_amf note on the zeroed alpha channel
    followed the filter with a software format directly, which no longer forms
    a valid chain; they now name the download and the frames context format
    first.
    
    Tested on Windows 11, RX 9070 XT, driver 32.0.31041.1004: the case above
    now fails to configure instead of crashing, and vpp_amf, vqe_amf, frc_amf
    and sr_amf keep working with software, AMF, D3D11VA and DXVA2 input, into
    hwdownload and into h264_amf and hevc_amf.
    
    Assisted-by: Claude Opus 5
    Assisted-by: Claude Fable 5.1
    Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>

    Changed files

    • doc/filters.texi
    • libavfilter/vf_amf_common.c
    • libavfilter/vf_amf_common.h
    • libavfilter/vf_frc_amf.c
    • libavfilter/vf_sr_amf.c
    • libavfilter/vf_vpp_amf.c
    • libavfilter/vf_vqe_amf.c

16. Change #281992

    Category	ffmpeg
    Changed by	Julius Bairaktaris <juliusohnoyoudont@bairaktaris.de>
    Changed at	Thu 17 Sep 2026 00:05:28
    Repository	https://git.ffmpeg.org/ffmpeg.git
    Project	ffmpeg
    Branch	master
    Revision	3a8c1f29b7a154bf5cfc9600e8d58d3adeda4f44

    Comments

    avfilter/amf: flush the component at EOF with an activate callback
    The AMF filters ran off a filter_frame callback, which has no way to tell
    a component that no more input is coming. Anything a component still held
    when the input link ended was lost, and there was nowhere to call
    AMFComponent::Drain(). The output side also assumed that every submission
    completes before the next one: the component was queried once per input,
    AMF_INPUT_FULL was fatal for the scaler, the enhancer and the converter
    and accepted as success by the frame rate converter, which released the
    surface and lost the frame, and every output produced during a call was
    given the properties of the frame submitted in that call.
    
    Convert all four filters to an activate callback that follows the
    component contract from AMD's programming guides. Every activation first
    polls the component for output that is already waiting, so output that
    arrives after the activation that submitted it is delivered without
    another input; then one input frame is consumed, and a submission that
    produces nothing forwards the request for input upstream instead of
    waiting for the sink to ask again. A submission that returns
    AMF_INPUT_FULL is repeated after the output side has been emptied, and
    the same surface is kept until the component accepts it. On EOF the
    pre-converter is drained first, with every surface it still returns
    handed to the scaler, then the component, and the status is forwarded
    only once QueryOutput() reports AMF_EOF; an empty AMF_REPEAT in between
    means the component is still working and is polled again. Drain() itself
    is repeated on AMF_INPUT_FULL the same way.
    
    Output frames take their properties from a queue of property copies of
    the submitted frames, so an output that arrives a submission late or
    during the drain still carries the right metadata and side data. The
    scaler, the converter and the enhancer return one output per input in
    submission order, so each output takes the oldest queued entry, and
    repeated or missing timestamps cannot pair it with another input. The
    frame rate converter emits two outputs per input, so it matches by pts,
    taking the newest queued input not after the output; its interpolated
    frame inherits from the preceding input and halves its duration as
    before. The copies keep the input dimensions, since
    av_frame_copy_props() drops pan-scan side data when they differ; the
    copy onto the output frame then drops it only when the filter resizes.
    
    vf_frc_amf.c moves onto the shared submission and output path instead of
    duplicating it. The FRC mode is set once after Init() rather than before
    every submission, and the output frame rate is doubled only when the
    converter is enabled; it was doubled unconditionally before, so enable=0
    advertised twice the rate it emitted. color_profile is set to unknown so
    the shared path leaves its output untagged, as before.
    
    Tested on Windows 11, RX 9070 XT, driver 32.0.31041.1004. Every
    component answers Drain() with AMF_OK and the next QueryOutput() with
    AMF_EOF, and the frame rate converter returns its interpolated frame with
    AMF_REPEAT and data attached, so data has to be checked independently of
    the result code. sr_amf with every algorithm, with and without the
    pre-converter, vpp_amf and vqe_amf are byte identical by framecrc to the
    previous revision over AMF, D3D11VA and DXVA2 surfaces and with software
    input; frc_amf returns the same 2N-1 frames with the same timestamps,
    durations and sizes, with colour tags present on every frame including
    the interpolated ones, and its pixels are not comparable because the
    component is not deterministic between runs. Pan-scan side data from an
    MPEG-2 decode is present on every frame out of vqe_amf, vpp_amf and
    frc_amf and dropped by a resizing sr_amf. A truncated read with -frames:v
    still terminates. AMF_INPUT_FULL and output delayed past the submitting
    activation do not occur on this device, so those paths are exercised by
    inspection only.
    
    Assisted-by: Claude Opus 5
    Assisted-by: Claude Fable 5.1
    Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>

    Changed files

    • libavfilter/vf_amf_common.c
    • libavfilter/vf_amf_common.h
    • libavfilter/vf_frc_amf.c
    • libavfilter/vf_sr_amf.c
    • libavfilter/vf_vpp_amf.c
    • libavfilter/vf_vqe_amf.c

17. Change #281993

    Category	ffmpeg
    Changed by	Julius Bairaktaris <juliusohnoyoudont@bairaktaris.de>
    Changed at	Thu 17 Sep 2026 00:05:28
    Repository	https://git.ffmpeg.org/ffmpeg.git
    Project	ffmpeg
    Branch	master
    Revision	a71ffc5700d02b37e59506aa91e135c9ac3b1544

    Comments

    avfilter/vf_vqe_amf: leave the output colorspace untouched
    The shared output path retags every frame from the filter's
    color_profile unless that is AMF_VIDEO_CONVERTER_COLOR_PROFILE_UNKNOWN,
    which is -1. vqe_amf never set it, so the zero-initialized field read as
    AMF_VIDEO_CONVERTER_COLOR_PROFILE_601 and every enhanced frame came out
    tagged SMPTE 170M, whatever the input said. The enhancer does no colour
    conversion and has no colour option, so set the profile to unknown at
    init, as frc_amf already does, and the copied colorspace stays.
    
    Tested on Windows 11, RX 9070 XT, driver 32.0.31041.1004: BT.709 input
    through vqe_amf is reported as smpte170m by showinfo before and as bt709
    after.
    
    Assisted-by: Claude Fable 5.1
    Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>

    Changed files

    • libavfilter/vf_vqe_amf.c

18. Change #281994

    Category	ffmpeg
    Changed by	Julius Bairaktaris <juliusohnoyoudont@bairaktaris.de>
    Changed at	Thu 17 Sep 2026 00:05:28
    Repository	https://git.ffmpeg.org/ffmpeg.git
    Project	ffmpeg
    Branch	master
    Revision	8f1e6edbabf811786f63fa0a69f669d88efb7e39

    Comments

    avfilter/amf: hold the wrapped D3D11 and DXVA2 frame until AMF releases it
    CreateSurfaceFromDX11Native() and CreateSurfaceFromDX9Native() wrap the
    texture without taking a reference on anything FFmpeg owns. The input
    AVFrame was freed at the end of the activation that submitted it, which
    hands its pool entry back to the decoder while the component may still
    hold the surface, so the decoder could write the next picture into a
    texture the component has not finished reading. Nothing pinned the
    frame for the surface's lifetime; the AMF encoder retains a clone of its
    input for the same reason.
    
    Pass an AMFSurfaceObserver that carries a clone of the frame and free
    both from OnSurfaceDataRelease(), which AMF calls when the wrapped
    surface is destroyed. The pool entry stays checked out for exactly as
    long as AMF references the surface. The copy path for D3D11VA decoder
    textures is unaffected: its copy is queued on the immediate context
    before the frame is released, so it is ordered ahead of any later write.
    
    Tested on Windows 11, RX 9070 XT, driver 32.0.31041.1004 with a probe
    counting the callbacks: every wrapped frame is released exactly once,
    for D3D11VA decoder textures into frc_amf, the path that wraps without
    copying, and for DXVA2 surfaces into all four filters. On this device
    the release arrives before the next frame is submitted, so the
    components consume the texture within the submitting activation and
    the hold changes nothing observable there: framecrc output is identical
    to the previous revision and decodes of 300 frames over DXVA2 and 600
    over D3D11VA complete.
    
    Assisted-by: Claude Fable 5.1
    Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>

    Changed files

    • libavfilter/vf_amf_common.c