assistance request - build some gst binaries for pw4

dhdurgee · 05-15-2020, 12:47 PM

Looking over my Sox extension for KUAL the messy and problemic part of the code is in the pw4 support working around the lack of two Gstreamer libraries that they did not bother to provide, specifically libgstaudioconvert.so and libgstwavparse.so are missing.

With my limited understanding of Gstreamer I beleive I could simplify my support for the kt4/pw4 to:

sox <input> -t wav | gst-launch filesrc /dev/stdin ! wavparse ! audioconvert ! mixersink

This would eliminate the need to make use of soxi to determine the characteristics of the input stream to the pipelne as wavparse would detect them dynamically from the sox output stream. This would allow files of varying formats to be passed in a playlist and be dealt with individually as opposed to the current restrictions. The audioconvert element would then handle providing mixersink what it wants from the sox output.

When I run gst-launch --version on the pw4 I am told 0.10.25 is the version number. Going to https://gstreamer.freedesktop.org/src/ I find that source is available for this version and that the source for these two libraries are in gst-plugins-base and gst-plugins-good respectively.

My problem is I have built very few projects from source and have never done so for a target other than the system I am running. There is also no need to build the entire project, only the two particular binary libraries are needed.

Can I interest one of you who have experience in building for the kt4/pw4 in building these two gst libraries for me?

Dave

NiLuJe · 05-15-2020, 01:28 PM

Hard pass.

Multimedia, it's a deptree nightmare.

Code:

[ media-libs/gstreamer-1.16.2 stats: packages (3496), max depth (302) ]

If there weren't custom bits in the middle with an ABI issue, I'd say go with a current version and let BuildRoot do the hard work for you, but there are, so you can't.

NiLuJe · 05-15-2020, 01:32 PM

Hmm, in their infinite wisdom, the BR guys had managed to keep gstreamer-0 in the tree up until the 2020.x branches, so, eeeh, might work.

(It's 0.10.36 though).

dhdurgee · 05-15-2020, 01:58 PM

Quote:

Originally Posted by NiLuJe

Hmm, in their infinite wisdom, the BR guys had managed to keep gstreamer-0 in the tree up until the 2020.x branches, so, eeeh, might work.

(It's 0.10.36 though).

Debian Jessie makes the 0.10.36 binaries available and they yield that missing symbol and are thus not compatible.

Would it be possible to strip back the required tree through some judicious code editing? For the application I am thinking of audioconvert would only need to go from wav to raw as sox will handle the original format to wav conversion. And of course wavparse only needs the wav support.

As I noted this will simplify the kt4/pw4 support substantially, making it similar to the much simpler pw3 support where ALSA is available. The messy and problemic code is that required to provide the stream characteristics to the mixersink element.

Dave

dhdurgee · 05-15-2020, 02:33 PM

Just had another thought, how hard would it be to build our own custom plugin element? All I would need is a "wav2raw" element that would accept a wav stream, set the characteristics and output a raw stream. This of course would need to be compatible with 0.10.25 to work on the kt4/pw4.

Dave

dhdurgee · 06-01-2020, 01:43 PM

A few weeks ago I thought to post to the appropriate gstreamer mailing lists to see if anyone there would be interested in assisting me with this project. Unfortunately it appears that nobody there had any interest in replying to my post.

So it appears that if this is going to be done it will need to be with my own effort and resources.

I have three possible platforms to work with here, my pw4 itself, a Raspberry Pi 0 and my laptop.

As the target platform the pw4 would be ideal if it is possible to do so. Unfortunately the tools required to do so are unavailable as provided by Amazon. Has anyone put together a package to allow building software on the pw4 that can be used by a novice? I have built occasional, simple programs on my linux laptop, so I am not totally without experience.

My Raspberry Pi 0 has the advantage of also being arm based, albeit armv6l as opposed to the armv7l of the pw4. It is also armhf versus armel and running buster versus jessie.

My laptop is x86_64 running mint sylvia, but is certainly a more powerful processor with more memory than either of the other options.

Can anyone point me to the current recommendations for building software for the pw4 in one or more of these?

The source code is available and I have downloaded it for the "good" plugins, which contains the desired wavparse element. Hopefully there is a way to build only that element once the environment is prepared.

Thank you in advance for any guidance.

Dave

NiLuJe · 06-01-2020, 02:18 PM

Since the deptree is so insane, I'd go with the latest buildroot release that supported gst-0 (I already forgot the tag ^^).

(Build, then) feed it the PW2 TC from koxtoolchain.

c.f., https://github.com/koreader/koreader...2020.02-config for an (unrelated) example of using a Kindle TC w/ BR.

Then, either you fudge the BR package directly to build the right gst version, or you build it manually inside BR's sysroot (after having let BR build the full deptree for the "new" version).

----

EDIT: To be clear: that's the "cross-compilation" approach. Doing it on-device wouldn't be any fun (but you'd essentially need to chroot into a real distro in there to do it), both for the CPU, the storage, your sanity, and it'd take a ridiculous amount of time to build stuff.

Same general idea on the Pi, with the same constraints, if not worse on a zero. You just gain possibly not having to deal with a chroot. And you'd probably have to deal with most of the same quirks as if actually cross-compiling, so, eh.

(Yeah, I'm the wrong guy to ask about the "build it on arm" approaches).

NiLuJe · 06-01-2020, 02:25 PM

After that, I have no actual experience with gst itself, but the modular "everything is a plugin" approach makes it that much more annoying to deal with (one, because it's split in a billion little pieces, and, two, you'll probably have to double-check baked-in search paths devised at compile-time so that it actually behaves at runtime).

Also, ltdl. Libtool is the worst.

05-15-2020, 12:47 PM	#1
dhdurgee Guru Posts: 829 Karma: 2525050 Join Date: Jun 2010 Device: K3W, PW4	assistance request - build some gst binaries for pw4 Looking over my Sox extension for KUAL the messy and problemic part of the code is in the pw4 support working around the lack of two Gstreamer libraries that they did not bother to provide, specifically libgstaudioconvert.so and libgstwavparse.so are missing. With my limited understanding of Gstreamer I beleive I could simplify my support for the kt4/pw4 to: sox <input> -t wav \| gst-launch filesrc /dev/stdin ! wavparse ! audioconvert ! mixersink This would eliminate the need to make use of soxi to determine the characteristics of the input stream to the pipelne as wavparse would detect them dynamically from the sox output stream. This would allow files of varying formats to be passed in a playlist and be dealt with individually as opposed to the current restrictions. The audioconvert element would then handle providing mixersink what it wants from the sox output. When I run gst-launch --version on the pw4 I am told 0.10.25 is the version number. Going to https://gstreamer.freedesktop.org/src/ I find that source is available for this version and that the source for these two libraries are in gst-plugins-base and gst-plugins-good respectively. My problem is I have built very few projects from source and have never done so for a target other than the system I am running. There is also no need to build the entire project, only the two particular binary libraries are needed. Can I interest one of you who have experience in building for the kt4/pw4 in building these two gst libraries for me? Dave

05-15-2020, 01:28 PM	#2
NiLuJe BLAM! Posts: 13,477 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	Hard pass. Multimedia, it's a deptree nightmare. Code: [ media-libs/gstreamer-1.16.2 stats: packages (3496), max depth (302) ] If there weren't custom bits in the middle with an ABI issue, I'd say go with a current version and let BuildRoot do the hard work for you, but there are, so you can't.

05-15-2020, 01:32 PM	#3
NiLuJe BLAM! Posts: 13,477 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	Hmm, in their infinite wisdom, the BR guys had managed to keep gstreamer-0 in the tree up until the 2020.x branches, so, eeeh, might work. (It's 0.10.36 though). Last edited by NiLuJe; 05-15-2020 at 01:35 PM.

06-01-2020, 02:18 PM	#7
NiLuJe BLAM! Posts: 13,477 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	Since the deptree is so insane, I'd go with the latest buildroot release that supported gst-0 (I already forgot the tag ^^). (Build, then) feed it the PW2 TC from koxtoolchain. c.f., https://github.com/koreader/koreader...2020.02-config for an (unrelated) example of using a Kindle TC w/ BR. Then, either you fudge the BR package directly to build the right gst version, or you build it manually inside BR's sysroot (after having let BR build the full deptree for the "new" version). ---- EDIT: To be clear: that's the "cross-compilation" approach. Doing it on-device wouldn't be any fun (but you'd essentially need to chroot into a real distro in there to do it), both for the CPU, the storage, your sanity, and it'd take a ridiculous amount of time to build stuff. Same general idea on the Pi, with the same constraints, if not worse on a zero. You just gain possibly not having to deal with a chroot. And you'd probably have to deal with most of the same quirks as if actually cross-compiling, so, eh. (Yeah, I'm the wrong guy to ask about the "build it on arm" approaches). Last edited by NiLuJe; 06-01-2020 at 02:29 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Request: template-making assistance for column built from other columns	iienderii	Library Management	9	04-04-2016 10:27 PM
New Zealand GST could soon be charged on ebooks	GeoffR	News	39	11-18-2015 12:26 PM
Australian GST on ebook from overseas.	RCR	General Discussions	10	08-31-2012 02:21 AM
Regex assistance request - importing books.	Belfaborac	Library Management	2	10-24-2011 08:03 AM
Question for Canadians about Kobo and GST	ficbot	General Discussions	8	03-27-2010 03:16 AM

05-15-2020, 02:33 PM	#5
dhdurgee Guru Posts: 829 Karma: 2525050 Join Date: Jun 2010 Device: K3W, PW4	Just had another thought, how hard would it be to build our own custom plugin element? All I would need is a "wav2raw" element that would accept a wav stream, set the characteristics and output a raw stream. This of course would need to be compatible with 0.10.25 to work on the kt4/pw4. Dave

06-01-2020, 01:43 PM	#6
dhdurgee Guru Posts: 829 Karma: 2525050 Join Date: Jun 2010 Device: K3W, PW4	A few weeks ago I thought to post to the appropriate gstreamer mailing lists to see if anyone there would be interested in assisting me with this project. Unfortunately it appears that nobody there had any interest in replying to my post. So it appears that if this is going to be done it will need to be with my own effort and resources. I have three possible platforms to work with here, my pw4 itself, a Raspberry Pi 0 and my laptop. As the target platform the pw4 would be ideal if it is possible to do so. Unfortunately the tools required to do so are unavailable as provided by Amazon. Has anyone put together a package to allow building software on the pw4 that can be used by a novice? I have built occasional, simple programs on my linux laptop, so I am not totally without experience. My Raspberry Pi 0 has the advantage of also being arm based, albeit armv6l as opposed to the armv7l of the pw4. It is also armhf versus armel and running buster versus jessie. My laptop is x86_64 running mint sylvia, but is certainly a more powerful processor with more memory than either of the other options. Can anyone point me to the current recommendations for building software for the pw4 in one or more of these? The source code is available and I have downloaded it for the "good" plugins, which contains the desired wavparse element. Hopefully there is a way to build only that element once the environment is prepared. Thank you in advance for any guidance. Dave

06-01-2020, 02:25 PM	#8
NiLuJe BLAM! Posts: 13,477 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	After that, I have no actual experience with gst itself, but the modular "everything is a plugin" approach makes it that much more annoying to deal with (one, because it's split in a billion little pieces, and, two, you'll probably have to double-check baked-in search paths devised at compile-time so that it actually behaves at runtime). Also, ltdl. Libtool is the worst.

Advert

Advert