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 8 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 299 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 297 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 297 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 266 times

[richmond62]

Embeddable MPV:

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

watson.jpg (488.39 KiB) Viewed 264 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 260 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 254 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 196 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.