ffmpeg build with libx265; incompatible pointer type

[hydra3333]

Oh dear, looks like something is currently broken/incompatible over at ffmpeg ? I guess all we can do is wait.

Fresh build:

00:18:18 ├ Compiling FFmpeg with Vapoursynth R68 00:18:18 ├ FFmpeg will need vapoursynth.dll and vsscript.dll to run using vapoursynth demuxers! 00:18:19 Running git clone for ffmpeg... 00:20:06 Running git update for ffmpeg... 00:20:09 ┌ ffmpeg git ............................... [Recently updated] 00:20:10 ├ Changing options to comply to nonfree... CUDA_PATH environment variable not set or directory does not exist. 00:20:21 ├ Compiling static FFmpeg... 00:20:22 ├ Running configure... 00:25:23 ├ Running make... Likely error (tail of the failed operation logfile): AR libavfilter/libavfilter.a CC libavcodec/libx265.o src/libavcodec/libx265.c: In function 'libx265_encode_frame': src/libavcodec/libx265.c:802:59: error: passing argument 5 of 'ctx->api->encoder_encode' from incompatible pointer type [-Wincompatible-pointer-types] 802	pic ? &x265pic : NULL, &x265pic_out);	^~~~
x265_picture *

src/libavcodec/libx265.c:802:59: note: expected 'x265_picture ' but argument is of type 'x265_picture ' make: [/build/ffmpeg-git/ffbuild/common.mak:81: libavcodec/libx265.o] Error 1 make failed. Check C:/MABS/build/ffmpeg-git/build-static-64bit/ab-suite.make.log This is required for other packages, so this script will exit. 00:28:17 Creating diagnostics file...

Attach C:\MABS\build\logs.zip to the GitHub issue. Make sure the suite is up-to-date before reporting an issue. It might've been fixed already.

[moob158]

Same error here :(

[OliverMD15]

Sadly same here.

[hydra3333]

reported over at ffmpeg trac. https://trac.ffmpeg.org/ticket/11130 probably the wrong place to do it, if so i'm positive i'll be told, oh well.

[LigH-de]

Happened since x265 added support for Alpha and MultiView, so it needs to handle multiple video streams now, instead of a single one. I reported it in the x265-devel ML, let's see how they will reply.

[L4cache]

This x265_picture is defined in x265 header... so I guess the problem is on the x265's side?

[LigH-de]

The use of this type in a function parameter list changed from a pointer * to that type (pass by reference) to a pointer-of-pointer **; so I assume that ffmpeg needs to get adapted to that change too. https://mailman.videolan.org/pipermail/x265-devel/2024-August/013760.html

[L4cache]

No reply on either side so far? But I guess these new functions are backported from some x266 stuff to x265, so maybe a good sign (about x266)?

[hydra3333]

I checked last night and no response that I saw. Also skimmed this month's ffmpeg-user and ffmpeg-dev lists and zero mention on those that I saw ... I'm tempted to raise it on ffmpeg-user too however have an impression trac is monitored so it seems like there may be a lack of interest which is slightly disconcerting given h.265 is widely known and used around the globe.

[hydra3333]

In the meantime is there a way to choose an x265 commit to affix to and if so ... how :)

[ArtisticTuxedo]

Same problem here sadly.

[L4cache]

In the meantime is there a way to choose an x265 commit to affix to and if so ... how :)

append #commit=<HASH> to SOURCE_REPO_X265 in media-suite_deps.sh and make sure there's a existing local x265_git folder, otherwise you should run it twice. See below.

[LigH-de]

That would clamp x265 to that commit for both the library linked into ffmpeg and the separate encoder. So you may build ffmpeg again but will also be limited to that outdated stage for the x265.exe.

[hydra3333]

Thank you. So perhaps I should do a temporary (local, for me) patch to MABS to apply '#commit=' and then another (somehow) when hopefully separately building x265 to use a URL without that '#commit='. I'll have a look.

[LigH-de]

Running two parallel installations of the suite (one configured for full ffmpeg building, one limited to the needs of x265 only) is easily possible, enough disk space provided.

[hydra3333]

Running two parallel installations of the suite (one configured for full ffmpeg building, one limited to the needs of x265 only) is easily possible, enough disk space provided.

That looks like a good plan. I'll have a gander at it tomorrow !

[moob158]

Noob here, if anyone can help.

I changed the repo in media-suite_deps.sh for SOURCE_REPO_X265=https://bitbucket.org/multicoreware/x265_git/commits/3d808f14db2ea026604ee88bc5012c842de61d0e

the commit before the change in x265, but I get same compiler error.

I need to make other changes to other files as well????

[LigH-de]

Read more attentively: #commit= - not /commit/

[moob158]

commit=

Sorry, I'm new to this... so change to SOURCE_REPO_X265=https://bitbucket.org/multicoreware/x265_git#commit=3d808f14db2ea026604ee88bc5012c842de61d0e right???

[LigH-de]

No. Previously it was:

SOURCE_REPO_X265=https://bitbucket.org/multicoreware/x265_git.git

After the edit it should be:

SOURCE_REPO_X265=https://bitbucket.org/multicoreware/x265_git.git#commit=dd594f59d95198c6d8e4133b6002c18e47e7d6fe

because x265-git commit dd594f5 from 2024-07-24 was the last commit before adding support for multiple video streams.

[moob158]

ohh oki thank you very much, i will try :)

[moob158]

After try I get this error

"rm: unknown option -- g Try 'rm --help' for more information. rm: unknown option -- g Try 'rm --help' for more information. Running git clone for ... git seems to be down Try again later or to continue

if you're sure nothing depends on it."

Running git clone for x265_git... fatal: Not a valid object name

[LigH-de]

So you probably made a mistake editing this file. And seriously ... this issue tracker is not the place to fix it, you are derailing this topic. Better discuss this in a place where you can discuss changes live with an experienced partner and where you are able to exchange files easily, so your whole files can be checked before running a test.

At least I will test the suggested changes now, I did not yet have the time to do it myself.

[moob158]

Oki, I just copied and pasted line you gave me in media-suite_deps.sh replaced the other, I'm compiling ffmpeg right now.

I'll wait a few minutes to see if there are any more errors.

if it keeps giving errors I'll have to wait a few more days.

Thanks for your help anyway :)

I get the same compiler error the download of x265 ignore the commit and download tha lastest.

[LigH-de]

I got a fatal: Not a valid object name too. I wonder if the commit tag has to be formatted differently. From the logs I see that git retrieved the HEAD of master.

@L4cache - please test and be more elaborate.

[L4cache]

Sorry I didn't test it (until now) Remove commit= then it works... So the whole thing looks like this:

SOURCE_REPO_X265=https://bitbucket.org/multicoreware/x265_git.git#dd594f59d95198c6d8e4133b6002c18e47e7d6fe

Despite comment said so... https://github.com/m-ab-s/media-autobuild_suite/blob/03c89bd06f97d7097cdff53dfc5912f2d265038f/build/media-suite_helper.sh#L234-L237 I wonder if it's broken or never actually designed like this, but you can see in the default deps.sh, #branch= and #tag= are working just fine, as well as the one with nothing but "NAME" - #SDL2.

See below.

[LigH-de]

It may be necessary to remove build/x265_git-git/ to force a fresh checkout because the change in the deps is not recognised as up-/downdate.

[LigH-de]

No, it does not work, still fatal: Not a valid object name

[L4cache]

Okay... So this only works on existing git folders somehow (with or without commit=), you can terminate it an run again, or delete local64/lib/libx265.a to force a rebuild.

[LigH-de]

As I already wrote, I removed build/x265_git-git/ (and build/ffmpeg-git/ too) to force a fresh checkout; also I removed local##/lib/libx265.a too.

And x265 was checked out from master/HEAD without respecting the commit hash.

[L4cache]

No, don't remove x265_git-git, remove only libx265.a. The suite will still do the checkout correctly. Might be a bit confusing but please trust me, I actually tested it this time😂

[LigH-de]

OK, I left build/x265_git-git/ there, only deleted local##/lib/libx265.a this time.

ab-suite.git.reset.log reports: dd594f5 fix lowpass dct for high bit depth – that's the commit I wanted to get.

And ffmpeg builds.

I will keep track of it because I want to build both a working ffmpeg and the most recent x265.

[moob158]

Yes it work like @L4cache say.

Thanks you to both for help. i hope it's temporary solution.

thank you ;)

[OliverMD15]

No, don't remove x265_git-git, remove only libx265.a. The suite will still do the checkout correctly.

Talk about confusing, but man does it somehow work. Thanks for the time and effort you two put into this!

[hydra3333]

I will keep track of it because I want to build both a working ffmpeg and the most recent x265.

So do I.

In the thread above it looks as if one needs to

• run MABS and allow it to create the folder and checkout x265
• ?? let it finish at least as far as producing a working x265.exe and copy that ??
• delete local64/lib/libx265.a and the ffmpeg build folder, ffmpeg_git (or whatever)
• change the source to be SOURCE_REPO_X265=https://bitbucket.org/multicoreware/x265_git.git#dd594f59d95198c6d8e4133b6002c18e47e7d6fe
• run it again to build a working ffmpeg with libx265 at the commit level of the last known compatible x265 code

[LigH-de]

Deleting the ffmpeg build folder is probably not required. I only did it to ensure no possibly outdated source files remain. But ffmpeg is almost guaranteed to get rebuilt when any linked library is updated, if that feature is enabled in the suite.

[L4cache]

Some kind of very dumb temporary workaround:

diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 0dc7ab6eeb..846af87c6e 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -798,8 +798,10 @@ static int libx265_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
 #endif
     }

+    x265_picture* x265pic_out_1 = &x265pic_out;
     ret = ctx->api->encoder_encode(ctx->encoder, &nal, &nnal,
-                                   pic ? &x265pic : NULL, &x265pic_out);
+                                   pic ? &x265pic : NULL, &x265pic_out_1);
+

     for (i = 0; i < sei->numPayloads; i++)
         av_free(sei->payloads[i].payload);

[hydra3333]

still no commentary on ffmpeg-dev or ffmpeg-user. a tad surprising, sort of. I guess no one uses it enough for it to be considered important ? gyan did post a comment on trac confirming the issue though, even if no ffmpeg developer has taken ownership yet ... perhaps it's good weather and holiday season in that hemisphere ?

[LigH-de]

Please consider that a majority of ffmpeg might need to be rewritten to support this feature in ffmpeg, instead of just having a workaround to compile while not actually supporting Alpha and MVC in x265.

The x265 CLI only nees to care about itself; ffmpeg needs to care about every other codec too.

[L4cache]

I think the x265's own CLI is also broken ~when new features are enabled (they are default to disabled)~ Even without any new features enabled, it stucks at the last frame and keeps outputing forever. Or maybe I just didn't use it correctly.

It may even more broken than FFmpeg libx265 with my disastrous "patch".

Warning: Trash Tier Codes

```diff diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c index 0dc7ab6eeb..feae884285 100644 --- a/libavcodec/libx265.c +++ b/libavcodec/libx265.c @@ -662,6 +662,7 @@ static int libx265_encode_frame(AVCodecContext *avctx, AVPacket *pkt, libx265Context *ctx = avctx->priv_data; x265_picture x265pic; x265_picture x265pic_out = { 0 }; + x265_picture x265pic_out_sublayer = {0}; x265_nal *nal; x265_sei *sei; uint8_t *dst; @@ -681,7 +682,24 @@ static int libx265_encode_frame(AVCodecContext *avctx, AVPacket *pkt, ReorderedData *rd; int rd_idx; - for (i = 0; i < 3; i++) { + int numPlanes = 3; + + switch(avctx->pix_fmt){ + case AV_PIX_FMT_YUVA420P: + case AV_PIX_FMT_YUVA422P: + case AV_PIX_FMT_YUVA444P: + case AV_PIX_FMT_YUVA420P10LE: + case AV_PIX_FMT_YUVA422P10LE: + case AV_PIX_FMT_YUVA444P10LE: + case AV_PIX_FMT_YUVA422P12LE: + case AV_PIX_FMT_YUVA444P12LE: + numPlanes = 4; + break; + default: + numPlanes = 3; + } + + for (i = 0; i < numPlanes; i++) { x265pic.planes[i] = pic->data[i]; x265pic.stride[i] = pic->linesize[i]; } @@ -798,8 +816,11 @@ static int libx265_encode_frame(AVCodecContext *avctx, AVPacket *pkt, #endif } + + x265_picture *x265pic_out_pointer[2] = {&x265pic_out,&x265pic_out_sublayer}; ret = ctx->api->encoder_encode(ctx->encoder, &nal, &nnal, - pic ? &x265pic : NULL, &x265pic_out); + pic ? &x265pic : NULL, x265pic_out_pointer); + for (i = 0; i < sei->numPayloads; i++) av_free(sei->payloads[i].payload); @@ -886,6 +907,9 @@ static const enum AVPixelFormat x265_csp_eight[] = { AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_GBRP, AV_PIX_FMT_GRAY8, + AV_PIX_FMT_YUVA420P, + AV_PIX_FMT_YUVA422P, + AV_PIX_FMT_YUVA444P, AV_PIX_FMT_NONE }; @@ -903,6 +927,12 @@ static const enum AVPixelFormat x265_csp_ten[] = { AV_PIX_FMT_GBRP10, AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY10, + AV_PIX_FMT_YUVA420P, + AV_PIX_FMT_YUVA422P, + AV_PIX_FMT_YUVA444P, + AV_PIX_FMT_YUVA420P10LE, + AV_PIX_FMT_YUVA422P10LE, + AV_PIX_FMT_YUVA444P10LE, AV_PIX_FMT_NONE }; @@ -925,6 +955,15 @@ static const enum AVPixelFormat x265_csp_twelve[] = { AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY10, AV_PIX_FMT_GRAY12, + AV_PIX_FMT_YUVA420P, + AV_PIX_FMT_YUVA422P, + AV_PIX_FMT_YUVA444P, + AV_PIX_FMT_YUVA420P10LE, + AV_PIX_FMT_YUVA422P10LE, + AV_PIX_FMT_YUVA444P10LE, + // AV_PIX_FMT_YUVA420P12LE, + AV_PIX_FMT_YUVA422P12LE, + AV_PIX_FMT_YUVA444P12LE, AV_PIX_FMT_NONE }; ```

[GyanD]

I've a potential patch for ffmpeg. Can someone test with x265 builds both before and after the breaking change? 0001-lavc-libx265-unbreak-build-for-X265_BUILD-210.patch

[LigH-de]

If I just knew in which line in media-suite_compile.sh I should insert it with a do_patch ... am. Probably before line 2308?

How do I link a source code range with preview?

[GyanD]

This seems like a good place: https://github.com/m-ab-s/media-autobuild_suite/blob/03c89bd06f97d7097cdff53dfc5912f2d265038f/build/media-suite_compile.sh#L2223

[LigH-de]

Testing this:

         enabled vapoursynth && do_patch "https://raw.githubusercontent.com/m-ab-s/mabs-patches/master/ffmpeg/0001-Add-Alternative-VapourSynth-demuxer.patch" am
+        enabled libx265 && do_patch "https://github.com/user-attachments/files/16571967/0001-lavc-libx265-unbreak-build-for-X265_BUILD-210.patch" am

         if enabled openal &&

[L4cache]

it stucks at the last frame and keeps outputing forever

Anyone encountering the same x265 CLI issue I described?

[LigH-de]

Did a very quick test with a small Y4M: Finished gracefully. May behave differently with a filter-heavy script and longer duration, possibly?

x265 [info]: HEVC encoder version 3.6+36-be7b0ac

[L4cache]

OK, maybe it happens only with pipe input?

[LigH-de]

Pipe input can indeed be a risk: The receiving application needs to rely on the sending application to close the pipe correctly. There is no other way for it to know that the input came to an end.

[L4cache]

And your version looks like the checkout to old commit we discussed. That one should have no such problem. The issue I described happens when using current latest commit, or, to be exact, after this one: https://bitbucket.org/multicoreware/x265_git/commits/3a031c4f75269fcbfb4634beabb5a03cc8133a51

Okay... if --frames is specified then it's fine. And of course file based Y4M input have frames calculated from file size so it's fine as well. (If --frames is set to more than actual frames it will gooooooooooooooooooooes forever too) So it's just "slightly" broken then.

[LigH-de]

OK, ffmpeg builds with both x265 generations (master/HEAD and master/dd594f59), and both Win64 EXE work with Y4M input. Output of the last one:

ffmpeg version N-116603-ged388dd4fb-g43cde54fc1+4 Copyright (c) 2000-2024 the FFmpeg developers
  built with gcc 14.2.0 (Rev1, Built by MSYS2 project)
  configuration:  --pkg-config=pkgconf --cc='ccache gcc' --cxx='ccache g++' --ld='ccache g++' --extra-cxxflags=-fpermissive --extra-cflags=-Wno-int-conversion --disable-autodetect --disable-doc --enable-amf --enable-bzlib --enable-cuda --enable-cuvid --enable-d3d11va --enable-dxva2 --enable-iconv --enable-lzma --enable-nvenc --enable-zlib --enable-sdl2 --enable-ffnvcodec --enable-nvdec --enable-cuda-llvm --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libdav1d --enable-libaom --disable-debug --enable-fontconfig --enable-libass --enable-libbluray --enable-libfreetype --enable-libmfx --enable-libmysofa --enable-libopenjpeg --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libwebp --enable-libxml2 --enable-libzimg --enable-libshine --enable-gpl --enable-avisynth --enable-libxvid --enable-libopenmpt --enable-librav1e --enable-libsrt --enable-libgsm --enable-libvmaf --enable-libsvtav1 --enable-chromaprint --enable-frei0r --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfribidi --enable-libgme --enable-libilbc --enable-libsvthevc --enable-libkvazaar --enable-libmodplug --enable-librist --enable-librtmp --enable-librubberband --enable-libtesseract --enable-libxavs --enable-libzmq --enable-libzvbi --enable-openal --enable-libcodec2 --enable-ladspa --enable-vapoursynth --enable-libglslang --enable-vulkan --enable-libdavs2 --enable-libxavs2 --enable-libuavs3d --enable-libplacebo --enable-libjxl --enable-libxeve --enable-libxevd --enable-opencl --enable-opengl --enable-libopenh264 --enable-gnutls --extra-cflags=-DLIBTWOLAME_STATIC --extra-cflags=-DCACA_STATIC --extra-cflags=-DMODPLUG_STATIC --extra-cflags=-DCHROMAPRINT_NODLL --extra-cflags=-DZMQ_STATIC --extra-libs=-lpsapi --extra-cflags=-DLIBXML_STATIC --extra-libs=-liconv --disable-w32threads --extra-cflags=-DKVZ_STATIC_LIB --extra-cflags=-DAL_LIBTYPE_STATIC --extra-cflags='-IG:/MABS/local64/include' --extra-cflags='-IG:/MABS/local64/include/AL'
  libavutil      59. 34.100 / 59. 34.100
  libavcodec     61. 11.100 / 61. 11.100
  libavformat    61.  5.101 / 61.  5.101
  libavdevice    61.  2.100 / 61.  2.100
  libavfilter    10.  2.102 / 10.  2.102
  libswscale      8.  2.100 /  8.  2.100
  libswresample   5.  2.100 /  5.  2.100
  libpostproc    58.  2.100 / 58.  2.100
Input #0, yuv4mpegpipe, from 'foreman_cif_pal.y4m':
  Duration: 00:00:12.00, start: 0.000000, bitrate: 30414 kb/s
  Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p(progressive), 352x288, SAR 128:117 DAR 1408:1053, 25 fps, 25 tbr, 25 tbn
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> hevc (libx265))
Press [q] to stop, [?] for help
x265 [info]: HEVC encoder version 3.6+65-454e551
x265 [info]: build info [Windows][GCC 14.2.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main profile, Level-2 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices                              : 1
x265 [info]: frame threads / pool features       : 4 / wpp(5 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge         : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias  : 25 / 250 / 40 / 5.00 
x265 [info]: Lookahead / bframes / badapt        : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 0
x265 [info]: References / ref-limit  cu / depth  : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-28.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip mode=1 signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing deblock sao
Output #0, hevc, to 'foreman_cif_pal.ffmpeg.265':
  Metadata:
    encoder         : Lavf61.5.101
  Stream #0:0: Video: hevc, yuv420p(progressive), 352x288 [SAR 128:117 DAR 1408:1053], q=2-31, 25 fps, 25 tbn
      Metadata:
        encoder         : Lavc61.11.100 libx265
      Side data:
        cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
frame=  133 fps=0.0 q=35.6 size=     116KiB time=00:00:05.24 bitrate= 181.0kbits/s speed=  10x    
frame=  243 fps=236 q=35.1 size=     256KiB time=00:00:09.64 bitrate= 217.5kbits/s speed=9.36x    
[out#0/hevc @ 000001fea18ec740] video:315KiB audio:0KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 0.000000%
frame=  300 fps=250 q=35.8 Lsize=     315KiB time=00:00:11.92 bitrate= 216.7kbits/s speed=9.92x    
x265 [info]: frame I:      2, Avg QP:26.96  kb/s: 2616.10 
x265 [info]: frame P:     87, Avg QP:28.63  kb/s: 516.33  
x265 [info]: frame B:    211, Avg QP:35.08  kb/s: 62.79   
x265 [info]: Weighted P-Frames: Y:13.8% UV:13.8%

encoded 300 frames in 1.19s (251.89 fps), 211.34 kb/s, Avg QP:33.15

[GyanD]

Thanks. Already posted to devel-ML.