Day 15, Season 2
What should I do next? Possiblities are
- investigate video recording
- investigate wifi power usage.
- test fresh installation from zip file
- investigate init patching to not switch linkerconfig mounts anymore, maybe 5s are gained at boot time
Let’s tinker a bit with video recording.
If you remenber, there was an error “> E Codec2Buffer: GraphicMetadataBuffer does not work on 64-bit arch” that I saw about 10 days ago.
I also said “Jolla camera links to something which includes this 64-bit code.”
Well that something has to be gstreamer droid plugin. A quick strings on /usr/lib64/libgstdroid-1.0.so.1.0.0 shows libdroidmedia, but how is it loaded? (ldd doesn’t work since this is not linked in, as it is an Android library, probably bionic.)
Maybe retrace how droidmedia includes Codec2Buffer, which is in “frameworks/av/media/codec2/sfplugin” ?
Partial drill-down:
external/droidmedia/Android.mk declares for “LOCAL_MODULE := libdroidmedia” dependencies like “libmedia_codeclist” (A11+) or “libmedia_omx” (A9+) or just “libmedia”. This is just me picking stuff by intuition.
frameworks/av/media/libmedia/Android.bp declares “libmedia” as one (of the) cc_library, “libmedia_omx” as one of cc_library_shared (wait the former is not shared?). Also “libmedia_codeclist”.
Drill-“up”:
frameworks/av/media/codec2/sfplugin/Android.bp includes Codec2Buffer.cpp in its build, for cc_library_shared { name: "libsfplugin_ccodec" }.
Find in files inside frameworks/av/media reveals ./libstagefright/Android.bp needing libsfplugin_ccodec for building cc_library { name: "libstagefright" }
I look again at droidmedia and it is indeed using “libstagefright”.
So the dependency is gst-droid(libc) → droidmedia(bionic) → libstagefright → libsfplugin_ccodec
Somewhere across these lines, the code needs to switch from 64-bit to 32 bit, OR it shouldn’t touch libsfplugin_ccodec?
Looking through the Waydroid camera recording “for later study” from three days ago, I do see exactly one reference in that log to “Codec2Buffer”
Codec2Buffer: VideoNativeMetadata contains null buffer
My logcat from Day 4 does not have that line though.
Guess which function has that message above. The same one that has no 64-bit implementation.
Fun fact? it does have 64-bit code in the next android version.
The code is introduced in two commits: one that says “Look, devices that have 64-bit and 64-bit ONLY work.” and the second that says “Well, it works on 32/64 too if you want to set this debug flag to be non-0”. The debug flag is introduced as -1 in a commit I do have on Lineage 18.1
So there is a tiny possibility that I can cherry pick the above two commits. That is, if that “setprop debug.stagefright.c2inputsurface -1” would work.
But… why does it work in Waydroid?
(Mental note: mediaserver process is running, and it should not. I need to add it as override/disabled in disabled_services.rc
In itself, stopping it doesn’t fix the recording problem but still, one process less.)
Waydroid seems to also have a slew of patches, some of them for frameworks/av
Some are “rebase from API 30”, some are “new media stack”. Nothing related to that Codec2Buffer stuff, but maybe some other code path is used.
Looking at the hybris patches for frameworks/av too.
There is the 0002 one that draws my attention: first, because it is related to 32 bit. Second, because I know it fixed video recording on my previous port:) And lastly, because the code is in an #else that follows the #ifndef OMX_ANDROID_COMPILE_AS_32BIT_ON_64BIT_PLATFORMS.
What is curious about that is that OMX_ANDROID_COMPILE_AS_32BIT_ON_64BIT_PLATFORMS is defined above, in the same cpp file, when __LP64__ is. So why wouldn’t it NOT be defined at any point? (that is, for 64-bit machines it should always be, right?)
Also, what’s this build warning every time I call soong (meaning: I build something in HA_BUILD env)?
hardware/qcom-caf/sm8350/audio/configs/lahaina/lahaina.mk:422: warning: “Enabling codec2.0 SW only for non-generic odm build variant”
(This looks benign though, “Rank OMX SW codecs lower than OMX HW codecs”)
About that define. Let’s double-check that the LP64 flag is indeed set.
There is a compiler flag for outputing preprocessor definitions: Clang command line argument reference — Clang 17.0.0git documentation
I add -E and -dM to a small project - let’s use yesterday’s hwcrypt - into its .bp (soong blueprint) file.
The make now gives an error (because preprocessor output is instead of object code) and kindof gets me hunting to where the output is, I find it five minutes later in the last corner of the build, namely “out/soong/.intermediates/hybris/mw/hwcrypt/hwcrypt/android_arm64_armv8-2a/obj/hybris/mw/hwcryp/main.o”
And yes, LP64 is 1
Back to reading logs: waydroid vs host - the SFOS recording calls into QC2Comp/QC2Interface which I believe are “QCOM” “Codec2”. The waydroid does not. Also, there are messages from the service like vendor.qti.media.c2@1.0-service: missing struct descriptor (…)
While searching for errors related to QC2Interface I found a message about a drone that doesnt’ record video. That and then people complain about pixel 2 working but pixel 3a not.
Hmm, wasn’t pixel 3a a device with halium port? It may mean they also use this QC2 stuff.
I find at least two possible leads:
- Changes in media_codecs_c2.xml
- a
setprop debug.stagefright.ccodec 0in a .rc file
Just adding that setprop and rebooting (checking it is still 0) and recording doesn’t work. Log and process analysis for future me: Ubuntu Pastebin
Oh well, the quick trick didn’d do it, we’re in for the long one;)
Hmm wifi tethering does not actually work. The DNS does not respond, otherwise routing seems ok.
if I 
