experiments in VLC (linux)

[tperry2x]

Following on from:
https://www.openxtalk.org/forum/viewtop ... 5602#p5602

I've also just updated my vlc player tests, so that playing back audio is non-blocking.

I've tested with the file:
https://api.modarchive.org/downloads.ph ... ne_work.it

Seems to work well. Need to test on MacOS and Windows if anyone has VLC installed, otherwise - don't worry, I'll test when I get a moment. (This will only initially be to replace the player command in Linux with a vlc alternative), so Windows and Mac support isn't really needed - (unless we want to switch away from mplayer at any point in the future).

non-blocking audio test

vlc-test-2.oxtstack

(3.92 KiB) Downloaded 190 times

demo vid:
https://www.tsites.co.uk/otherstuff/vlc-audio.m4v

[richmond62]

I install VLC as a matter of course whatever OS I am using (had it working on Haiku OS once), along with my standard "shopping list":

VLC
GIMP
Inkscape
LibreOffice
Audacity
LC Open

Whether you can, however, rely on end-users having VLC installed on a Mac is a bit of a moot point.

[richmond62]

So . . . Not at work today, it being, in Bulgaria, the Spring holiday this week . . . MacOS 12 with VLC and OXTL 1.03:
-

Screenshot 2024-04-02 at 11.41.13.png (46.84 KiB) Viewed 7495 times

-
No joy, I am afraid.

At the risk of . . . if I select a video file do I ALSO have to select the same file as my audio file to hear the sound?

Here is my test movie:

[richmond62]

If it is any comfort (OK: NO it's not) the player object delivers on MacOS:
-

Screenshot 2024-04-02 at 11.47.13.png (263.58 KiB) Viewed 7493 times

-
Something that is [odd] is that, inwith the Dictionar of OXT Lite I can find no listing for the player object.
-

Screenshot 2024-04-02 at 11.50.29.png (40.04 KiB) Viewed 7493 times

-
And I [suppose] that 'Linux' might just be a "mistake".

[tperry2x]

I'm sure Linux did play at one point, but mplayer is a bit 'old hat' on Linux, as far as the formats it can support. VLC is by far more compatible on Linux.

There should be no reason why mac and windows folks can't carry on using the built in player control. As I mention, this is really for the benefit of Linux users to give consistent behaviours across all distros. Doesn't really apply to Mac and Win until one day it stops working.

Just experimental really, always good to have a plan B and not rely solely on one thing.

[richmond62]

until one day it stops working

Who got out the wrong side of bed this morning?

One day everything will stop working: Thee and Me alike.

Oh, and why is there no mention of the player object in the OXT Lite Dictionar?

[richmond62]

I'm sure Linux did play at one point, but mplayer is a bit 'old hat' on Linux

Aye, well that is what happens when you're dependent on something external; and, just as mplayer is external, so is VLC . . .

[tperry2x]

until one day it stops working

Who got out the wrong side of bed this morning?

One day everything will stop working: Thee and Me alike.

Oh, and why is there no mention of the player object in the OXT Lite Dictionar[y]?

I wasn't getting snarky, or getting out of the wrong side of bed or anything - I just meant exactly that.

Everything stops working if not maintained.

mplayer isn't being updated and maintained as regularly as vlc, and vlc supports far far more formats (codecs), than mplayer. But then it should, as VLC is included in many Linux distros and is rapidly becoming the 'play anything, anywhere' kind of essential utility you mention.

I'll have to check the dictionary when I get a chance, but I was sure it contained information about the 'player' 'classic control' object.

[richmond62]

Personally I am always very careful to get out of the middle of the bed: like driving down the middle of the road, I don't have to worry if I'm in Britain or Europe.

Everything stops working if not maintained.

Just so: potted out 72 tomato seedlings this morning.

mplayer isn't being updated and maintained as regularly as vlc

I think that is a very polite way of putting things:

"2022-02-27, Sunday :: MPlayer 1.5 released"

http://www.mplayerhq.hu/design7/news.html

Mind you, as the situation in Hungary is 'sticky' at best at the moment, I wouldn't blame those people if they thought there were more pressing things to worry about at the morning. After all, the ONLY software that came out of a repressive regime of any (doubtful) utility was Tetris.

If you want to get into cross-dressing (sorry; strike that:) cross-platform MPV might be worth a look:

https://linuxreviews.org/Mpv

https://mpv.io/

Certainly does good job "over here" on MacOS 12.

I don't know if you could somehow 'internalise' MPV:
-

Screenshot 2024-04-02 at 15.14.21.png (51.48 KiB) Viewed 7462 times

[richmond62]

Embeddable MPV:

https://github.com/mpv-player/mpv/blob/ ... v/client.h
-

watson.jpg (488.39 KiB) Viewed 7460 times

[tperry2x]

Hmmm... all the entries for 'player' seem to be part of the dictionary as far as I can tell.

player-dictionary.png (98.37 KiB) Viewed 7456 times

[richmond62]

Hmmm... all the entries for 'player' seem to be part of the dictionary

Guilty as charged: did NOT scroll down the list far enough.

BUT, pardon my naivety; but if I search for 'player' shouldn't 'player' plain-and-simple be the first to pop up in the list?

[richmond62]

AND, to MVP?

Certainly very interesting, although the latest MacOS build seems NOT to have its own volume control.

[tperry2x]

BUT, pardon my naivety; but if I search for 'player' shouldn't 'player' plain-and-simple be the first to pop up in the list?

Depends really, on how you choose to sort the list with the column headings.

dictionary-validate-richmond.gif (49.04 KiB) Viewed 7450 times

However, Android player appears first, being alphabetical. If you sort by 'kind' then you may get closer to 'player' being at the top. It's a wildcard search from what I understand, but I didn't make that dictionary stack.

[tperry2x]

AND, to MVP?
Certainly very interesting, although the latest MacOS build seems NOT to have its own volume control.

I think mplayer on MacOS and Win can probably stay as they are, I'm only interested in tweaking the linux version as that's non-functional at the moment.

It can be forced to work with mplayer on linux, by forcefully downgrading the mplayer libraries to older versions with synaptic package manager, but not recommended as that approach could easily break something else that someone might rely on. (and cause dependency hell)

Edit: Experiments in VLC, in Linux (command line) #2
(link here)

Think I'm getting closer to a working method of playing video back, just can't hide the window decorations reliably on the video window. (still get a close, maximise, minimise box)

Edit 3: got it. No window border, plays like a normal video - and I should be able to add all the options on the inspector I'm building for this, like options to show controller, mirror video, loop, sound volume, even make greyscale if I wanted.

Screenshot.png (61.53 KiB) Viewed 7392 times

[OpenXTalkPaul]

Windows and Mac support isn't really needed - (unless we want to switch away from mplayer at any point in the future).

The play command and player control do not use mplayer at all on MacOS or Windows, post-Quicktime's demise they use AVMedia APIs on macOS/iOS and Direct Play on Windows.
The play pAudiofile command on macOS does not work properly, for example with mp3 files it tries to play them, but produces horrible noise instead, even though the AVMedia APIs support mp3 (and a bunch of other audio formats), and there's no way to end the playback, play stop doesn't work.
These are some of the reasons I was doing experiments with making an FFMPEG / FFPLAY wrapper library, also tried MPV a bit (which is actually a fork of MPlayer2), which under the hood use some of the same libraries that VLC uses. FFMPEG allows for doing all sorts of recording, editing, and converting so that is desirable to me.

[OpenXTalkPaul]

I've occasionally been looking at the engine C++ source code, saw this:

Code: Select all

#define C_PLAYER_ARG "/usr/bin/mplayer -vo x11 -slave -wid %d" 

and thought we'll probably want to modify this Linux specific file at some point:
https://github.com/OpenXTalk-org/OpenXT ... er.cpp#L44

[tperry2x]

That is certainly a very good find. Imagine if it was just this one line that was preventing video and audio playback on linux. I'd be very happy to see that working.

So far, the only change I've made to the linux engine (aside from modernising the linked dependencies), was to delete the registration dialog requirement.

I'm certainly open to making more changes. However, I wonder what the exact equivalent command in VLC would be? It's not easily something you can debug - because a recompile takes about 20 minutes. (This is also why I'm keen to externalise as much as possible outside of the engine).

I suppose though, for something like this - I could put together a simple C++ program that runs the vlc command only. Once we know that works, it could potentially replace that command in the engine source.

[OpenXTalkPaul]

That is certainly a very good find. Imagine if it was just this one line that was preventing video and audio playback on linux. I'd be very happy to see that working.

So far, the only change I've made to the linux engine (aside from modernising the linked dependencies), was to delete the registration dialog requirement.

I'm certainly open to making more changes. However, I wonder what the exact equivalent command in VLC would be? It's not easily something you can debug - because a recompile takes about 20 minutes. (This is also why I'm keen to externalise as much as possible outside of the engine).

I suppose though, for something like this - I could put together a simple C++ program that runs the vlc command only. Once we know that works, it could potentially replace that command in the engine source.

I can get a semi-working video playing on Linux, but I have to the set the filename repeatedly, like before every time I issue a 'play' command, and there's no transport/controller UI from in the IDE control, so you have to make your own controller buttons, but other than those issues I could play the sample video in the IDE (on Ubuntu Studio), there's a button that plays that video on a card in my 'Start Center" redo stack.

I really like the idea of having this point to a call a 'playvideo' CLI or '.sh' shell commands or something like that, because then we can easily swap it out for something else with no recompiling of the engine needed.

You know I agree to the point about externalizing all of the non-base-xTalk-language-interpreter stuff. What I would like to go along with that idea is some sort of library layer of obfuscation of the underlying implementations, at least for certain things like Text to Speech where the underlying speech engine could be NSSPpeech, AVSpeech, Web HTML5 Speech API, Android's Speech API, eSpeak for Linux, etc., similar my goal in how I've modified the 'PlayPMD' (PlaySentence MIDI out) library to search-out and use whatever MIDI playing API and default sound bank is available for playback. Similarly I'd like to implement a media (Audio,Video) playback AND Recording library that could use whatever is available Apple's APIs or FFMPEG's APIs or some Windows API, and on mobile too if possible. But relevant point here is that it would be set-up so it would be easy to change out the underlying implementations. You would write scripts that call the handlers in the obfuscating library (that delegates it to an available API) and not have those scripts become broken in the future if say AVSpeech goes extinct like QuickTime has.