search

marierose147 / ffmpeg_windows_exe_with_fdk_aac

An automated build based on https://github.com/rdp/ffmpeg-windows-build-helpers
Other
78 stars 7 forks source link

No possibility to (selectively?) trigger "ffmpeg_win32_with_fdk_aac" workflow... #2

Closed Vangelis66 closed 3 years ago

Vangelis66 commented 3 years ago

Hi there :smiley:; as I can't write in Chinese :wink:, I hope plain English is OK by you... :smile_cat:

I ended up here through GitHub's own search engine; my older laptop is running Vista SP2 32-bit (yes, one of my hobbies is retrocomputing!); after the demise :cry: of the Zeranoe sites (both Windows-binary repos and forums), the Windows binary providers linked to in the official FFmpeg site, https://www.ffmpeg.org/download.html#build-windows only compile for the 64-bit architecture :-1: ; while I understand 64-bit is the way to go, 32-bit isn't dead yet, as there exist many people running even Win10 32-bit, especially on lower-end hardware that used to come initially with previous, 32-bit, Windows versions... Another tough issue for me is Vista-compatibility; Vista is the minimum Windows OS vanilla (no-libs) FFmpeg supports, but many third-party libs commonly included with FFmpeg have either abandonned Vista in their default configuration (e.g. libx265) or compile only in 64-bit mode...

Up until ca. 2018, I was still able to compile myself ffmpeg-win32 builds on that very Vista laptop with the aid of media-autobuild_suite, but, sadly, msys2 started removing support for Vista as a host OS, then msys2 itself, as well as the suite's maintainer, dropped completely support for compiling on 32-bit hosts, limiting support to, practically, only Win10 64-bit; additionally, if one compiled a 32-bit ffmpeg.exe there, the toolchain/compilers would've optimised it for Win7 and higher, thus it would not run under Vista... :disappointed:

Roger Pack's FFmpeg-Windows-Build-Helpers is currently (quite possibly) the only one building solution that generates Vista-compatible binaries, both 32/64-bit, so it's win32 FFmpeg builds compiled by it I'm really after... :stuck_out_tongue_winking_eye:

If my translator was right, by fixing issue #1 I already have the ability to trigger the compilation of both gpl+lgpl win32 FFmpeg builds in this spendid :+1: project of yours, in fact I have already done so: 

ffmpeg version N-102605-g4c705a2775-ffmpeg-windows-build-helpers Copyright (c) 2
000-2021 the FFmpeg developers
  built with gcc 10.2.0 (GCC)
  configuration: --pkg-config=pkg-config --pkg-config-flags=--static --extra-ver
sion=ffmpeg-windows-build-helpers --enable-version3 --disable-debug --disable-w3
2threads --arch=x86 --target-os=mingw32 --cross-prefix=/home/runner/ffmpeg-windo
ws-build-helpers/sandbox/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32- --
enable-libcaca --enable-gray --enable-libtesseract --enable-fontconfig --enable-
gmp --enable-gnutls --enable-libass --enable-libbluray --enable-libbs2b --enable
-libflite --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libg
sm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore
-amrnb --enable-libopencore-amrwb --enable-libopus --enable-libsnappy --enable-l
ibsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvo-a
mrwbenc --enable-libvorbis --enable-libwebp --enable-libzimg --enable-libzvbi --
enable-libmysofa --enable-libopenjpeg --enable-libopenh264 --enable-liblensfun -
-enable-libvmaf --enable-libsrt --enable-demuxer=dash --enable-libxml2 --enable-
opengl --enable-libdav1d --enable-cuda-llvm --enable-libaom --enable-libvpx --en
able-nvenc --enable-nvdec --extra-libs=-lharfbuzz --extra-libs=-lm --extra-libs=
-lpthread --extra-cflags=-DLIBTWOLAME_STATIC --extra-cflags=-DMODPLUG_STATIC --e
xtra-cflags=-DCACA_STATIC --enable-amf --enable-libmfx --extra-cflags='-mtune=ge
neric' --extra-cflags=-O3 --enable-static --disable-shared --prefix=/home/runner
/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-i686/i686-w64-mi
ngw32
  libavutil      57.  0.100 / 57.  0.100
  libavcodec     59.  1.100 / 59.  1.100
  libavformat    59.  2.101 / 59.  2.101
  libavdevice    59.  0.100 / 59.  0.100
  libavfilter     8.  0.101 /  8.  0.101
  libswscale      6.  0.100 /  6.  0.100
  libswresample   4.  0.100 /  4.  0.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfi
le}...

However, when "starring" this repo, one triggers the compilation of multiple builds (GitHub Actions Workflows), namely: 

ffmpeg_win32_gpl
ffmpeg_win32_lgpl
ffmpeg_win64_with_fdk_aac
ffmpeg_win64_with_fdk_aac_shared

Being currently on a 32-bit OS, I have no need for the win64 builds that are also compiled in parallel, so I consider this a waste of resources... OTOH, I would have strongly wished for a "ffmpeg_win32_with_fdk_aac" static compilation to take place, but, alas, this is not currently the case... :sob:

In conclusion, I'm kindly asking you to consider enabling the fmpeg_win32_with_fdk_aac workflow upon user request, for those of us still on a 32-bit WinOS... Also, it would be great if you found a way for a user to selectively enable specific workflows only, e.g. based on architecture, saving that way GitHub Actions resources and/or disk space...

Lastly, currently one has to fetch the whole "working directory" for a workflow run in order to just grab one to three binaries (ffmpeg.exe/ffprobe.exe/ffplay.exe) per run; this amounts to ca. 0.5GB per run, which is, IMHO, needless bandwidth consumption... If you could streamline further the workflows to produce as artifacts only the non-debug executables, I think it would be much beneficial to the project... But I suppose this is material for another "issue"...

My most heartfelt thanks for this project of yours, may you be blessed for life! :heart: :1st_place_medal:

marierose147 commented 3 years ago

I am glad that my work can help you. I will try to improve my project as much as possible to achieve the goals in your suggestion.😎

Vangelis66 commented 3 years ago

Many thanks for your most kind reply and attention to reported issue/requests. 👍 Your willingness to accommodate is very much appreciated! ❤️

I'll be monitoring the repo and issue tracker for planned improvements... 😄 Sadly, I'm sorry 😢 to report that, after your most recent changes, all workflow runs fail:

https://github.com/marierose147/ffmpeg_windows_exe_with_fdk_aac/actions, e.g.

https://github.com/marierose147/ffmpeg_windows_exe_with_fdk_aac/actions/runs/909282970

fails trying to compile harfbuzz_git due to path (?) issues (from log): 

2021-06-05T13:26:57.7082029Z make[1]: Leaving directory '/home/runner/ffmpeg-windows-build-helpers/sandbox/win32/libwebp_git'
2021-06-05T13:26:57.7107012Z Downloading (via git clone) harfbuzz_git from https://github.com/harfbuzz/harfbuzz.git
2021-06-05T13:26:57.7134823Z Cloning into 'harfbuzz_git.tmp'...
2021-06-05T13:27:11.9464467Z done git cloning to harfbuzz_git
2021-06-05T13:27:11.9485561Z doing git checkout origin/master
2021-06-05T13:27:11.9509807Z error: pathspec 'origin/master' did not match any file(s) known to git
2021-06-05T13:27:12.4308114Z HEAD is now at cf9538e80 Removal remaining uses of "blacklist" terminology
2021-06-05T13:27:12.4420573Z error: pathspec 'origin/master' did not match any file(s) known to git
2021-06-05T13:27:12.4444963Z fatal: ambiguous argument 'origin/master': unknown revision or path not in the working tree.
2021-06-05T13:27:12.4446055Z Use '--' to separate paths from revisions, like this:
2021-06-05T13:27:12.4446819Z 'git <command> [<revision>...] -- [<file>...]'
2021-06-05T13:27:12.4455334Z ##[error]Process completed with exit code 1.

Unfortunately, I have very few coding skills (if any 😉 ) to troubleshoot further/help in a meaningful way, I hope, though, you can still find the cure for this latest breakage...

Best wishes 😃

Vangelis66 commented 3 years ago

As much feared, it seems I now find myself in a situation much worse than before submitting this issue... 😭

Twelve days ago, by "starring" this repo, I triggered and successfully compiled both ffmpeg_win32_lgpl and ffmpeg_win32_gpl,

https://github.com/marierose147/ffmpeg_windows_exe_with_fdk_aac/actions/runs/872932184

https://github.com/marierose147/ffmpeg_windows_exe_with_fdk_aac/actions/runs/872932181

(but not ffmpeg_win32_with_fdk_aac, which was the reason for filing this issue...).

Today, when I starred the repo, ONLY ffmpeg_win64_with_fdk_aac was triggered (but I needed myself ffmpeg_win32_with_fdk_aac), which itself failed after half an hour:

https://github.com/marierose147/ffmpeg_windows_exe_with_fdk_aac/actions/runs/910377192

GAF

What to do now? Please help if you can...

Thanks for your time and efforts, despite this outcome... 😉

marierose147 commented 3 years ago
Vangelis66 commented 3 years ago

@marierose147:

Thanks for your swift response/analysis/explanations... 👍 Please read below:

because the name of the master branch of harfbuzz has been changed from master to main. This problem needs to be fixed by the upstream build script.

Culprit change probably being:

https://github.com/harfbuzz/harfbuzz/commit/fa432a121e3c409de77cd2e2b1085b31b93be4c6

Well, do you want me to submit an issue upstream, i.e. to https://github.com/rdp/ffmpeg-windows-build-helpers/issues , will you be doing it at your own convenience or should "we" wait for some third party reporting it? I am aware of several other GitHub projects using FWBH through GitHub Actions, they're bound to also notice the breakage eventually... 😉

The new trigger method is to 1) first click on the action(s) tab, and
2) then click on the left to open the branch you want to build. 3) Then, there'll be a small banner on the right side of the page, with a trigger button. This is a new trigger method from GitHub.

Let me first show you how things look on my side:

marierose

... so no sign of what you described in "3)" 😢 😞 I then did my own search and in https://github.com/marierose147/ffmpeg_windows_exe_with_fdk_aac/commit/1ac775daabc61a9e2be9302536c9e91bf22026ed#diff-aa9375f3893db88b361778e812f6e3acf9b39f8175b6620777115adf763495b1 you configured the workflow to run on the workflow_dispatch event, so it could be triggered manually... The relevant (I think) GitHub documentation can be found on:

https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow

and I suppose what you were talking about is demonstrated by:

actions-select-workflow

However, the documentation dictates that:

To trigger the workflow_dispatch event on GitHub, your workflow must be in the default branch. Follow these steps to manually trigger a workflow run.

Write access to the repository is required to perform these steps.

so the "Run workflow" button will only appear on GitHub members with write privileges to this repo, in practice this should limit it to only yourself... And granting write access to anyone (like myself) wishing to just compile ffmpeg.exe isn't a smart/recommended move... In conclusion, unless I'm awfully mistaken in my assessments, you'll have to rethink the way a workflow is selectively triggered by a person other than you... 😜

Looking forward to any additional insight, kindest regards 😃

marierose147 commented 3 years ago