Home - Waterfall Grid T-Grid Console Builders Recent Builds Buildslaves Changesources - JSON API - About

Builder ffmpeg64-solaris10-i386 Build #14150

Results:

Failed

SourceStamp:

Projectffmpeg
Repositoryhttps://git.ffmpeg.org/ffmpeg.git
Branchmaster
Revision8f1e6edbabf811786f63fa0a69f669d88efb7e39
Changes18 changes

BuildSlave:

unstable10x

Reason:

The SingleBranchScheduler scheduler named 'schedule-ffmpeg64-solaris10-i386' triggered this build

Steps and Logfiles:

  1. git updating ( 6 secs )
    1. stdio
  2. shell  
    1. - no logs -
  3. shell_1  
    1. - no logs -
  4. shell_2  
    1. - no logs -
  5. shell_3  
    1. - no logs -
  6. shell_4  
    1. - no logs -
  7. shell_5  
    1. - no logs -

Build Properties:

NameValueSource
branch master Build
builddir /export/home/buildbot/slave/ffmpeg64-solaris10-i386 slave
buildername ffmpeg64-solaris10-i386 Builder
buildnumber 14150 Build
codebase Build
project ffmpeg Build
repository https://git.ffmpeg.org/ffmpeg.git Build
revision 8f1e6edbabf811786f63fa0a69f669d88efb7e39 Build
scheduler schedule-ffmpeg64-solaris10-i386 Scheduler
slavename unstable10x BuildSlave
workdir /export/home/buildbot/slave/ffmpeg64-solaris10-i386 slave (deprecated)

Forced Build Properties:

NameLabelValue

Responsible Users:

  1. Julius Bairaktaris

Timing:

StartWed Sep 16 22:25:19 2026
EndWed Sep 16 22:25:26 2026
Elapsed6 secs

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
BuildBot (0.8.14) working for the OpenCSW Buildbot project.
Page built: Fri 18 Sep 2026 01:39:09 (CEST)