zaps166
YouTube almost fixed for Qt4 version (search & playback work), a minor issue left: advice wanted
@zaps166 I resurrect the topic, since I found a faster way to debug what was broken (building on Sonoma with Qt5 allowed to reproduce identical failures: turned out, the problem was unrelated to Qt version) and more or less fixed YouTube: searching and playback work.
This branch https://github.com/barracuda156/QMPlay2/commits/18.12.08-qt4/ has the current fixes on top of the last commit which was building with Qt4. (This commit https://github.com/barracuda156/QMPlay2/commit/176915efac285fe23935db666771af3b93f3bbfc fixes search and this https://github.com/barracuda156/QMPlay2/commit/85b4e5a2a18c3db8e6919ea4572a8d59f2d17b1b fixes playback, but need a working yt-dlp, see below. Largely these two are trivial backports; the problem was to find them.)
One issue left to solve is support for HD playback (which YouTube has broken recently, and by default everything is 360p). QMPlay2 had is fixed around 21.x.x versions, but related commits are huge and seem to pull in a lot of changes, since they do not apply cleanly. Could you suggest a minimal change needed to address specifically this issue? AFAIU, already old versions of QMPlay2 can separate video and audio streams, so it boils down to being able to force HD. (Just pointing to the code which needs to be backported is sufficient, I do not ask to make a patch for me.)
It would be nice to get rid of downloaded yt-dlp (which invokes non-existing python3 and therefore fails) and use instead a regular externally-provided dependency, but for this at least an ugly solution is readily available: deleting yt-dlp binary from ~/.qmplay2 and making a symlink to MacPorts one works fine and fixes fetching videos.
P. S. @RJVB Did you have an earlier prototype of your fix for bit-perfect Core Audio which did not use blocks? libdispatch as such is feasible, blocks are no-go at the moment (until GCC addresses the problem, if ever).
I have bisected and found the commit which fixes HD streaming: https://github.com/zaps166/QMPlay2/commit/2f9281bb1026afd55650f4c33fdd3f3b91deee85
Unfortunately, it does not apply, not even dirtily, I need to see what it takes to backport previous changes.
UPD. May be easier than I thought: https://github.com/zaps166/QMPlay2/commit/2eece6353a66f4f95c646478b0ecac727850e71b
UPD2. No, it is pretty bad, this is pulled in: https://github.com/zaps166/QMPlay2/commit/f0c0ca05d837942eaadf935ce19ce142ba2dd518 And it also does not apply cleanly.
Do you really need Qt4? What platform are you targeting? Qt 5.6.3 is the last supporting Windows XP (23 years old OS), so maybe this'll be simpler to maintain?
It would be nice to get rid of downloaded yt-dlp (which invokes non-existing python3 and therefore fails) and use instead a regular externally-provided dependency, but for this at least an ugly solution is readily available: deleting yt-dlp binary from ~/.qmplay2 and making a symlink to MacPorts one works fine and fixes fetching videos.
You can remove downloader code.
Edit: But don't remember how it was in 2017 :sweat_smile:
MacOS on PowerPC, Qt5 was badly broken by its upstream on several levels (carbon removed, 32-bit support removed, from 5.4 they began using SDK which had no support for the architecture). Add to that they never bothered to test builds with gcc on Apple, so that is also broken here and there.
I would probably consider fixing Qt6 which finally uses a coherent build system, but with X11 backend. This should work, but currently broken even on the latest macOS (again, no testing done).
Qt4 works more or less robustly. Aside of occasional weirdity when it can’t find own plugins nothing really to complain about. And Qt4 apps have better gui and typically more stable than GTK-based ones.
MacOS on PowerPC
That's old machine, wine is also not an option, Linux on PPC probably bad idea, too.
IIRC Qt5 was very good on 5.6.3 (Windows and Linux/X11).
Are you able to build Qt6 with C++17 on PPC MacOS? Does it have up-to-date compilers?
Edit: But don't remember how it was in 2017 :sweat_smile:
Yeah, this can be sorted by patching out whatever tries to fetch it. No big deal. And I can write portfile code which will install symlinks wherever needed.
So my primary concern is that misleadingly small commit, which allows HD video streaming. If the same change could be applied onto Qt4 branch without rewriting hundreds of LoC, it would be a win. Two other fixes worked fine for every version I tried to build (almost no rebasing even). This last one looks non-trivial.
MacOS on PowerPC That's old machine,
It is still pretty fast in fact. My only regret is that I cannot have G5 Quad in the laptop form )
OpenBSD has Qt5 on ppc (thanks to using X11 and not a broken cocoa), but then it does not have other stuff which Mac has.
Are you able to build Qt6 with C++17 on PPC MacOS? Does it have up-to-date compilers?
Compilers are there. The problem is Qt quality of code: they in effect hardcode Cocoa-based build on macOS and do not test with gcc. One would think that it should take no more than a configure flag to build Qt against a chosen backend; in reality it fails. With some hacks I fixed building it on Sonoma as +x11 (that is broken atm), but only of the qtbase. PowerPC should be doable, but Apple headers pose a problem there (also no testing with GCC).
So I need to compile old code and update it, well...
@zaps166 It is either start from the branch I referred and backport minimal necessary fix on top of it. Or, as @RJVB suggested, try reverse: borrow YouTube modules from the modern code base, use them in place of old, see if they can be blended into the older version of other components.
What do you think, which approach makes better sense?
The problem now is very localized, up to a specific commit. Does it have a localized solution?
On Tuesday November 19 2024 15:04:01 Błażej Szczygieł wrote:
Are you able to build Qt6 with C++17 on PPC MacOS? Does it have up-to-date compilers?
Running a recent GCC (12+) with its libstdc++ is apparently not a big problem on PPC so the question is how to get Qt6 to build the XCB instead of the Cocoa backend on Mac and how to handle the odd bits and pieces outside the QPA where ObjC++ is used to access platform SDKs or features that may not exist on 10.5 (or possibly 10.6) or use ObjC constructs that GCC doesn't support.
Sergey knows a lot more about the state of PPC support in new enough clang compilers - MacPorts has patched these for a while so they can be told to use the MacPorts libstdc++ (-stdlib=macports-libstdc++) - which might be enough to get decent C++17 support in a clang version that works correctly on PPC?
As you may remember, I myself build QMPlay2 with GCC except for the few ObjC++ files that get compiled with clang++ .
Btw. I never supported big-endian in QMPlay2, so some part of code might not work properly... x86 is always little-endian, ARM is always set to use little-endian (anybody know big-endian OS for ARM?). Modern PPC also can run in little-endian mode.
how to get Qt6 to build the XCB instead of the Cocoa
Old Mac didn't have Cocoa?
10.5 (or possibly 10.6)
Well, I remember these :smile: It was 15 years ago?
I can check the YT code, but not today for sure :smile:
I suspect in some case we would have done fine with gcc and ObjC, if only we added -xobjective-c flag. That was a fix for the recent gegl, suggested by gcc upstream, and it worked normally.
On Tuesday November 19 2024 15:24:50 Sergey Fedorov wrote:
With some hacks I fixed building it on Sonoma as +x11 (that is broken atm), but only of the qtbase.
Qtbase and QtX11Extras are the only components that have backend-specific code that I know of; the other components should all build on these two. This is definitely the case in Qt5; there you can in fact patch and build an X11 version of QtBase, and then install only the libraries, plugins, headers and whatnots that you do not already have from the Cocoa build. With that (and having QtX11Extras built) you (I) can choose the platform plugin to use. The fun part is that the Aqua/Mac theme continues to work with the xcb QPA, meaning you can display applications with that look on a remote X11 server :)
My concern with Qt6 would be whether EGL is still optional, and OpenGL 2.1 enough. No Mac has hardware support for EGL, or for newer OpenGL versions.
And yes, those PowerPCs were fast at the time, and the AltiVec SIMD unit quite a bit more efficient than its Intel counterpart (esp. in the IBM-made G5 chips).
anybody know big-endian OS for ARM?
NetBSD has. Linux can support it, but perhaps one will need its own distro.
Old Mac didn't have Cocoa?
Well, the OS has a framework on this name, but SDK does not support a lot of later features, and the version of ObjC Apple uses is designed with an aim to undermine compatibility. Certain parts of the code cannot be compiled with gcc at all.
I can check the YT code, but not today for sure :smile:
That would be super-helpful! Thank you 🙏
(And I am also off for today now.)
On Tuesday November 19 2024 15:41:52 Błażej Szczygieł wrote:
Old Mac didn't have Cocoa?
They did (I think!!), but in a much more rudimentary form so backporting complex, intricate code like the Cocoa platform plugin is going to be practically (if not downright) impossible.
I suspect in some case we would have done fine with gcc and ObjC, if only we added
-xobjective-cflag.
That wouldn't be enough for the constructs GCC doesn't support, like @.***, ***@***.*** (or whatever it's called again). Does GCC implement ARC (automatic reference counting)? If not you'd be looking at hacking in a lot of manual reference counting, I fear.
I would say that the good news is that most of the ObjC++ files I've seen outside of the Cocoa plugin are minimum implementations providing just the bits that can't be done in "pure" C++, but they'll still include the same headerfiles (and with C++ that's often where the venom lies).
@zaps166 @RJVB Okay, so just sticking in YT-related components from 21.12.07 into 18.12.08 did not work, since it assumes some new stuff which did not exits (Frame, for example), and it is unclear whether it is sensible to pull over some random components in this manner.
I wonder if it makes a better sense just to fix 21.12.07 (or even a later version) to build with Qt4 instead of trying to backport a lot of later changes into 18.12.08. Apparently QML can be turned off. QJson we got a substitute via QJson4 library, which seems to work just fine.
Are there any major stoppers here? I expect some functionality not to have fallbacks, but as long as it is not essential, it can be just disabled. If some components (say, Mac-specific) cannot be built in their present shape but are more or less independent, those can be forward-ported from 18.12.08.
Alternatives are either @RJVB suggestion to borrow modern YT modules, but perhaps cutting some parts out to avoid backporting a lot of additional stuff, or my initial idea to use my 18.12.08-qt4 branch (which currently has YT fixed, but without HD streaming) and try to fix HD streaming there with as little changes as possible.
After some trial & error, I came to a conclusion that a better candidate would be a version close to those huge changes to the code which are hard to backport. Later ones introduce more incompatibilities and are unneeded to fix YouTube issue anyway.
So I am trying to build 19.09.03.
Initial errors were fixed, then I got stuck at this:
[ 27%] Building CXX object src/qmplay2/CMakeFiles/libqmplay2.dir/qrc_languages.cxx.o
cd /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_multimedia_QMPlay2/QMPlay2/work/build/src/qmplay2 && /opt/local/bin/ccache /opt/local/bin/g++-mp-14 -DQMPLAY2SHAREDLIB_LIBRARY -DQMPLAY2_LIBASS -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_USE_FAST_OPERATOR_PLUS -DQ_OS_MACOS -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -Dlibqmplay2_EXPORTS -I/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_multimedia_QMPlay2/QMPlay2/work/build/src/qmplay2 -I/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_multimedia_QMPlay2/QMPlay2/work/QMPlay2-19.09.03/src/qmplay2 -I/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_multimedia_QMPlay2/QMPlay2/work/build/src/qmplay2/libqmplay2_autogen/include -I/opt/local/include -I/opt/local/include/harfbuzz -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include/fribidi -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 -I/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_multimedia_QMPlay2/QMPlay2/work/QMPlay2-19.09.03/src/qmplay2/headers -isystem /opt/local/libexec/qt4/include -isystem /opt/local/libexec/qt4/include/QtGui -isystem /opt/local/libexec/qt4/include/QtCore -isystem /opt/local/libexec/qt4/share/mkspecs/default -Wall -Wno-deprecated-declarations -pipe -Os -std=gnu++11 -DNDEBUG -I/opt/local/include -D_GLIBCXX_USE_CXX11_ABI=0 -std=gnu++11 -arch ppc -mmacosx-version-min=10.6 -fPIC -I/opt/local/include/QJson4 -MD -MT src/qmplay2/CMakeFiles/libqmplay2.dir/qrc_languages.cxx.o -MF CMakeFiles/libqmplay2.dir/qrc_languages.cxx.o.d -o CMakeFiles/libqmplay2.dir/qrc_languages.cxx.o -c /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_multimedia_QMPlay2/QMPlay2/work/build/src/qmplay2/qrc_languages.cxx
[ 28%] Linking CXX shared library libqmplay2.dylib
cd /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_multimedia_QMPlay2/QMPlay2/work/build/src/qmplay2 && /opt/local/bin/cmake -E cmake_link_script CMakeFiles/libqmplay2.dir/link.txt --verbose=ON
Undefined symbols:
"__ZN12NetworkReply8finishedEv", referenced from:
__ZN16NetworkReplyPriv3runEv in NetworkAccess.cpp.o
"__ZTV12NetworkReply", referenced from:
__ZTV12NetworkReply$non_lazy_ptr in NetworkAccess.cpp.o
(maybe you meant: __ZTV12NetworkReply$non_lazy_ptr)
"__ZN7InDockW7resizedEii", referenced from:
__ZN7InDockW11resizeEventEP12QResizeEvent in InDockW.cpp.o
"__ZTV6Slider", referenced from:
__ZTV6Slider$non_lazy_ptr in Slider.cpp.o
(maybe you meant: __ZTV6Slider$non_lazy_ptr)
"__ZTV8LineEdit", referenced from:
__ZTV8LineEdit$non_lazy_ptr in LineEdit.cpp.o
(maybe you meant: __ZTV8LineEdit$non_lazy_ptr)
"__ZN14LineEditButton16staticMetaObjectE", referenced from:
__ZN14LineEditButton16staticMetaObjectE$non_lazy_ptr in LineEdit.cpp.o
(maybe you meant: __ZN14LineEditButton16staticMetaObjectE$non_lazy_ptr)
"__ZN12NetworkReply16downloadProgressEii", referenced from:
__ZN16NetworkReplyPriv3runEv in NetworkAccess.cpp.o
"__ZN6Slider13mousePositionEi", referenced from:
__ZN6Slider14mouseMoveEventEP11QMouseEvent in Slider.cpp.o
"__ZN9IPCServer13newConnectionEP9IPCSocket", referenced from:
__ZN9IPCServer18socketAcceptActiveEv in IPC_Unix.cpp.o
"__ZTV11ColorButton", referenced from:
__ZTV11ColorButton$non_lazy_ptr in ColorButton.cpp.o
(maybe you meant: __ZTV11ColorButton$non_lazy_ptr)
"__ZTV9IPCSocket", referenced from:
__ZTV9IPCSocket$non_lazy_ptr in IPC_Unix.cpp.o
(maybe you meant: __ZTV9IPCSocket$non_lazy_ptr)
"__ZN11ColorButton12colorChangedEv", referenced from:
__ZN11ColorButton15openColorDialogEv in ColorButton.cpp.o
"__ZTV14LineEditButton", referenced from:
__ZTV14LineEditButton$non_lazy_ptr in LineEdit.cpp.o
(maybe you meant: __ZTV14LineEditButton$non_lazy_ptr)
"__ZN14LineEditButton7clickedEv", referenced from:
__ZN14LineEditButton15mousePressEventEP11QMouseEvent in LineEdit.cpp.o
"__ZTV7InDockW", referenced from:
__ZTV7InDockW$non_lazy_ptr in InDockW.cpp.o
(maybe you meant: __ZTV7InDockW$non_lazy_ptr)
"__ZN7InDockW13hasCoverImageEb", referenced from:
__ZN7InDockW15setCustomPixmapERK7QPixmap in InDockW.cpp.o
"__ZN8LineEdit18clearButtonClickedEv", referenced from:
__ZN8LineEdit9clearTextEv in LineEdit.cpp.o
"__ZTV9IPCServer", referenced from:
__ZTV9IPCServer$non_lazy_ptr in IPC_Unix.cpp.o
(maybe you meant: __ZTV9IPCServer$non_lazy_ptr)
ld: symbol(s) not found
collect2: error: ld returned 1 exit status
/opt/local/bin/g++-mp-14 -Wall -Wno-deprecated-declarations -pipe -Os -std=gnu++11 -DNDEBUG -I/opt/local/include -D_GLIBCXX_USE_CXX11_ABI=0 -arch ppc -mmacosx-version-min=10.6 -dynamiclib -Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names -o libqmplay2.dylib -install_name /opt/local/lib/libqmplay2.dylib CMakeFiles/libqmplay2.dir/libqmplay2_autogen/mocs_compilation.cpp.o CMakeFiles/libqmplay2.dir/QMPlay2Core.cpp.o CMakeFiles/libqmplay2.dir/Functions.cpp.o CMakeFiles/libqmplay2.dir/Settings.cpp.o CMakeFiles/libqmplay2.dir/Module.cpp.o CMakeFiles/libqmplay2.dir/ModuleParams.cpp.o CMakeFiles/libqmplay2.dir/ModuleCommon.cpp.o CMakeFiles/libqmplay2.dir/Playlist.cpp.o CMakeFiles/libqmplay2.dir/Reader.cpp.o CMakeFiles/libqmplay2.dir/Demuxer.cpp.o CMakeFiles/libqmplay2.dir/Decoder.cpp.o CMakeFiles/libqmplay2.dir/VideoFilters.cpp.o CMakeFiles/libqmplay2.dir/VideoFilter.cpp.o CMakeFiles/libqmplay2.dir/DeintFilter.cpp.o CMakeFiles/libqmplay2.dir/AudioFilter.cpp.o CMakeFiles/libqmplay2.dir/Writer.cpp.o CMakeFiles/libqmplay2.dir/QMPlay2Extensions.cpp.o CMakeFiles/libqmplay2.dir/LineEdit.cpp.o CMakeFiles/libqmplay2.dir/Slider.cpp.o CMakeFiles/libqmplay2.dir/QMPlay2OSD.cpp.o CMakeFiles/libqmplay2.dir/InDockW.cpp.o CMakeFiles/libqmplay2.dir/LibASS.cpp.o CMakeFiles/libqmplay2.dir/ColorButton.cpp.o CMakeFiles/libqmplay2.dir/ImgScaler.cpp.o CMakeFiles/libqmplay2.dir/SndResampler.cpp.o CMakeFiles/libqmplay2.dir/VideoWriter.cpp.o CMakeFiles/libqmplay2.dir/SubsDec.cpp.o CMakeFiles/libqmplay2.dir/VideoFrame.cpp.o CMakeFiles/libqmplay2.dir/StreamInfo.cpp.o CMakeFiles/libqmplay2.dir/DockWidget.cpp.o CMakeFiles/libqmplay2.dir/PacketBuffer.cpp.o CMakeFiles/libqmplay2.dir/Buffer.cpp.o CMakeFiles/libqmplay2.dir/NetworkAccess.cpp.o CMakeFiles/libqmplay2.dir/Version.cpp.o CMakeFiles/libqmplay2.dir/PixelFormats.cpp.o CMakeFiles/libqmplay2.dir/YouTubeDL.cpp.o CMakeFiles/libqmplay2.dir/Notifies.cpp.o CMakeFiles/libqmplay2.dir/NotifiesTray.cpp.o CMakeFiles/libqmplay2.dir/MkvMuxer.cpp.o CMakeFiles/libqmplay2.dir/IPC_Unix.cpp.o CMakeFiles/libqmplay2.dir/qrc_languages.cxx.o -Wl,-rpath,/opt/local/lib /opt/local/libexec/qt4/lib/libQtCore.dylib /opt/local/libexec/qt4/lib/libQtGui.dylib -lQJson4 -lavformat -lavcodec -lswscale -lavutil -lswresample -lass /opt/local/libexec/qt4/lib/libQtCore.dylib
make[2]: *** [src/qmplay2/libqmplay2.dylib] Error 1
Looks like a commit which moved final from inside classes to classes has broken linking.
Will try reverting that.
So with 19.09.03 most of the code compiles with Qt4 – with huge, but largely mechanical patching (reverting and forward-porting).
It starts breaking badly towards the end of the build, and ironically exactly on what we need: Downloader and YouTube. And here, I am afraid, reverting the an older version cannot work, since that will undo fixes that are required for YouTube to work.
So whether backporting later changes onto otherwise functional Qt4 version is attempted or reverse, forward-porting compat code into the version where YT was largely fixed for Qt5, the core problem is the YouTube module itself.
I give up for today, it took many hours -_-
Just to show that something actually works LOL
This is the archaic version with backported fixes, but broken HD streaming. (Offline HD playback works normally.)
19.x.x can still be built, I believe, but needs YouTube module syntax adapted for Qt4. (Not hoping to get later ones building.)
P. S. AFAICT, there are no powerpc-specific issues with this, everything should be reproducible and testable on x86 (in fact even arm64, but Qt4 does not build for it). OS version is likely irrelevant as well.
On Thursday November 21 2024 07:08:39 Sergey Fedorov wrote:
This is the archaic version with backported fixes, but broken HD streaming. (Offline HD playback works normally.)
Is that only HD streaming from YT or also from other sites? Things to check would be videos from news sites (get the links via VideoDownloadHelper; or pirated TV show/movies sites ;)), but also try the various YT stream links that you should be able to obtain from yt-dlp .
If you can get things to work for LD/SD streams, maybe @zaps166 would be willing and able to re-implement the changes required for HD streaming on top of that?
@RJVB I will try. I think there is no issue in handling HD streams as long as QMPlay is able to extract those from the web. For example, HD playback worked for YT via Smtube earlier (without my recent fixes), until YT broken that from their end (from what i understand, now it is required to handle video and audio streams separately, and that is broken at the moment). What did not work earlier was YouTube searching, which now works.
On Thursday November 21 2024 07:48:39 Sergey Fedorov wrote:
(from what i understand, now it is required to handle video and audio streams separately
Indeed, and yt-dlp will give you those separate links. If your QMPlay2 version doesn't yet have the code to play back 2 different streams then it follows that YT streaming doesn't work.
That said, it has had support for chapters and chosing from multiple substreams/channels and my guess would be that playing back separate audio and video streams is implemented as an extension of that functionality. Hopefully it will be relatively trivial to re-implement that for someone who's done it before!
@RJVB I got an idea, let me try building 19.09.03 with problematic stuff disabled first. If that works and I get a functional app, then it arguably makes a better sense to fix YT there (in that case the problem is different in fact, though with the same module: it is trivial to backport 1–2 commits onto 19.09.03, since it postdates the major rewrite of the code, but it is needed to make it build with Qt4 – just that one module, the rest I can handle). If 19.09.03 without optional modules remains unusable or less stable than my early Qt4 version, then perhaps rather backport YT-specific fixes onto that and leave everything else as is.
On Thursday November 21 2024 08:25:37 Sergey Fedorov wrote:
@RJVB I got an idea
Which looks like what I suggested, whichever version you pick in the end.
No big-endian issues?
At least nothing obvious (which likely implies nothing serous). With multimedia apps, in my experience, incorrect handling of endianness makes them defunct (hiss instead of audio output, visibly wrong colors with video). No complaints of this sort in regard of QMPlay2. For the playback QMPlay2 works amazingly well (even the archaic version built with Qt4) – unlike vlc, mpv and a few other players which I tried.
I did not test it yet with high-res audio (largely because of a habit to use different apps with video and audio), but I will try it shortly.
The only issue with a general functionality which I observe on my powerpc system is a crash on quit (i.e. when I quit the app, it crashes instead; but not otherwise). I do not think this is anything about powerpc; most likely my patches have an issue, or otherwise the SDK of 10a190. It also could be that it was a passing issue with QMPlay2 back then, since I picked the commit to start from based on what worked better for the build, which may not coincide with better stability.
Also is it possible to run OpenGL in QMPlay2 there?
Do you mean build QMPlay2 itself with OpenGL enabled? It may be tricky to test, since the last time we discussed the matter here, the build was failing on OpenGL components, so I just disabled it since then.
Will it be sensible to build it against mesa? I suspect Apple-provided OpenGL is just too old, and nothing much can be done about that.
On Thursday November 21 2024 10:09:43 Błażej Szczygieł wrote:
No big-endian issues?
Where would you expect them?
Would there be any, as long as FFmpeg does the demuxing and decoding?
Will it be sensible to build it against
mesa?
No. Mesa is strictly for X11, and AFAIK it does use the Apple GL library/ies behind the scenes. Using Mesa to for "native" OpenGL is asking for trouble and a likely cause of KPs on such an early version of the OS (I've had enough of those related to GL back in the day).
Good that it works with big-endian. I don't do many operations on bytes directly.
Will it be sensible to build it against mesa? I suspect Apple-provided OpenGL is just too old, and nothing much can be done about that
If system and driver can't handle OpenGL 2.x, there's nothing you can do. Very old QMPlay2 supported older OpenGL 1.x, but if it doesn't have non-power-of-2 and doesn't have multi-texturing extensions, the performance will be very bad.
If system and driver can't handle OpenGL 2.x, there's nothing you can do. Very old QMPlay2 supported older OpenGL 1.x, but if it doesn't have non-power-of-2 and doesn't have multi-texturing extensions, the performance will be very bad.
@zaps166 Perhaps OpenGL 1 is still better than no OpenGL at all? Not sure how intertwined is OpenGL module with the rest of the codebase, but if not much, I can probably restore v. 1 into Qt4-based branch.
UPD. Wait, Leopard should support OpenGL 2.1: https://en.wikipedia.org/wiki/Mac_OS_X_Leopard
Leopard’s OpenGL stack has been updated to version 2.1
On 10.6 it will be roughly the same, since later updates are not available, and forward-ported version from Leopard works better than the original.