YouTube almost fixed for Qt4 version (search & playback work), a minor issue left: advice wanted #776
Comments
|
I have bisected and found the commit which fixes HD streaming: 2f9281b 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: 2eece63 UPD2. No, it is pretty bad, this is pulled in: f0c0ca0 |
|
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? |
You can remove downloader code. Edit: But don't remember how it was in 2017 😅 |
|
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. |
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? |
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. |
|
So I need to compile old code and update it, well... |
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.
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). |
@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.
Old Mac didn't have Cocoa?
Well, I remember these 😄 It was 15 years ago? I can check the YT code, but not today for sure 😄 |
|
I suspect in some case we would have done fine with gcc and ObjC, if only we added |
|
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).
|
NetBSD has.
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.
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-c` flag.
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 ( 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 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: Looks like a commit which moved |
|
So with 19.09.03 most of the code compiles with Qt4 – with huge, but largely mechanical patching (reverting and forward-porting). 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). |
|
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? Also is it possible to run OpenGL in QMPlay2 there? |
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). 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.
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 |
|
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.
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
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. |
|
I will revisit OpenGL issue then. As long as OpenGL 2.1 is sufficient, fixing compilation is likely a matter of reverting some later commits, but the core functionality can be preserved. |
|
I will also go carefully through instances where I added quick hacks initially, and instead forward-port compat code from commits where it was changed to Qt5 syntax. I will share a tree for 19.09.03-qt4 once it is in a usable shape. Hope to sort this out in some hours. |
|
Minimal 19.09.03 is building with Qt4 now, launches with GUI, sound works, playlist works, no video LOL YouTube module (that is, newer one from 19.09.03) does not build, as of now. |
|
It looks like the app is processing the video normally (judging from working audio, info re video in real time and load on CPU), but something just prevents it from being output into the window. @zaps166 Could you say what specifically is responsible for the output of video signal? If I could narrow down the scope of where to look, fixing this will likely be much faster. |
|
BTW, the build finds `mesa`'s GL, not Apple one.
This will require a change in a CMake file. Using Mesa GL entry points into OpenGL is a good way to get crashes or even KPs.
|
|
On Saturday November 23 2024 04:27:52 Sergey Fedorov wrote:
It looks like the app is processing the video normally (judging from working audio, info re video in real time and load on CPU), but something just prevents it from being output into the window.
Is the "Enable Video" item in the Playback menu enabled?
|
I believe so, but I will verify again. I went through my patches to the old version and also searched through the older source for all instances of Qt4-related fallbacks, and perhaps I did not miss anything. But the codebase changes quite a bit, so something may need a fallback which never existed in the first place. Bisecting won’t really work to track the problem here, since I need to patch every version for it to even build, and I am not sure that the issue is not introduced by the patches ) |
|
@RJVB As a quick update: I have built a hacked 19.09.03 with Qt4 on Catalina and there is no video output either. So at least this is not powerpc issue and most likely not an SDK issue either. Video is enabled in settings, so it is either an error in patches or an incompatibility with Qt4 in the original code which patches did not address. |
|
On Saturday November 23 2024 09:40:43 Sergey Fedorov wrote:
Video _is_ enabled in settings, so it is either an error in patches or an incompatibility with Qt4 in the original code which patches did not address.
Do you have a Qt4 version that does play video?
|
Yes, of course. The one I added to MacPorts works fine, and the tree I posted a link here has YT search fixed as well (with offline video working normally). Issues with no video are observed only with a significantly newer version which I am trying to fix in a hope that YouTube HD playback comes as a bonus. This one never even built with Qt4 before. |
|
Hmmm, and what about an amd64 linux, does your hacked v19 show video there?
I don't really have an idea how platform-specific that code is beyond hw-accelerated decoding, but mixing Mesa with native OpenGL can definitely be a reason you're not seeing anything. Actually, you could check the renderer settings. In principle QMPlay2 has a fallback mechanism and I don't know what it would do when it runs out of fallbacks. As I said, I never tried the Qt4 version.
|
|
I.e. if someone fixes just handling of two separate streams (audio and video) which will fix HD playback on YouTube in this branch, issue is resolved. I do not know whether there is much to gain with fixing instead a newer version (given that a lot of code must be patched for compatibility with Qt4 to be restored), I just have no idea about YT protocol and extracting video streams from the web, so can’t really rewrite the old code for that, even if needed change is minimal. So I thought that it may be worth trying instead to take a version where YT was fixed, but Qt4 compatibility broken, and fix compatibility. |
I did not enable OpenGL anywhere in Qt4 builds (whether 18.x or 19.x), as of now, though from looks of things it is possible and perhaps not really hard (but will need to use older code, of course). So this is not something to cause a broken video output in 19.x. Back then I selected a specific commit for 18.x because it was optimal to minimize patching while getting a newer version than Qt4 branch here had. So with that version forward-porting some chunks of code was rather transparent and largely amounted to copy-pasting some ifdefs and getting rid of some bits of unneeded Cocoa. |
@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 barracuda156@176915e fixes search and this barracuda156@85b4e5a 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: deletingyt-dlpbinary from~/.qmplay2and 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).
The text was updated successfully, but these errors were encountered: