A question for sndwvs concerning vlc: Can you play .ts (mpeg transport stream) files on your system using your vlc? These are how DVB is generally transmitted.
I can get DVB fine using MPV and DVB utils (so not a hardware issue), but not when using VLC or Kaffeine (which is based on libVLC). Trying various locally stored files, I can play mp4, mkv etc with no problems, but vlc flatly refuses to play .ts files. (It works fine on my x86_64 installation) Since DVB is .ts based, this seems to be why I can't use VLC or Kaffeine for DVB. Either I'm missing a dependency, or you have something installed that I don't that is causing a problem with the pre-packaged version. ldd doesn't indicate anything mising for either VLC or Kaffeine. I've tried to rebuild VLC locally using your source files form here: https://gitlab.com/sndwvs/slackbuild...master/xap/vlc but the build fails as follows: Code:
video_filter/opencv_wrapper.cpp:318:51: error: call to 'abs' is ambiguous I want to try and get Kaffeine working (for which I need VLC to work) as it makes a good PVR! TIA, -- Pete |
Quote:
Code:
Format : MPEG-PS for build add Quote:
|
Ah! Your test file is MPEG-PS (Programme stream) not MPEG-TS (Transport stream). PS files are generally used for recording, where TS files are used for transmission. Most DVB apps simply record the TS file as it comes in. I can copy the ts file into a Matroska container - without transcoding - and it plays fine, so its a container issue rather than coding.
I'll try building with your added configs and report back... (Won't be until tomorrow, now) Cheers, -- Pete |
Quote:
-- Pete |
Update: I managed to get it to compile by disabling opencv. However, it still hasn't cured the problem. It looks as if something in the .ts module is incompatible with arm at the moment, though I have no idea why.
(From source code: /modules/demux/mpeg/ts*) My programming skills are not up to debugging that! I have put a post up on the VLC forums, but no response so far... -- Pete |
Quick update: It looks as if the ts demuxer is not getting built for some reason. If you look in the tools dropdown /preferences / (all) / demuxers there is no mpeg-ts demuxer shown. Come to that, there isn't a matroska one either, but it does play some matroska files. There is a PS demuxer shown for mpeg-ps files.
I've tried rebuilding both with and without the ffmpeg-merge option and it makes no difference! On x86_64 this gets built automatically by default. There is an option to force matroska (haven't tried it), but none for TS that I can find. I don't understand why it is not getting built, as I don't see any errors during the compile, and it should just be there! It certainly is in x86(_64). -- Pete |
OK, it looks like the mpeg-ts demuxer is missing. The only place I've been able to find it is in the gst-plugins-bad package, which doesn't seem to be part of slarm64. I've tried building it from Robby Workman's package for x86(_64) - suitably tweaked for aarch64 - but it crashes with a syntax error:
Code:
photography-enumtypes.c:6:1: error: stray '\' in program The file it is complaining about seems to be internally generated, so I have no idea why it should contain a syntax error - or how to prevent it! Anyone any ideas? -- Pete |
Just very distant idea ... maybe ...
Quote:
|
I was under the impression - mistaken, it would seem - that VLC, like many other programs, was heavily reliant on ffmpeg. Whilst this may be true of the various codecs, it appears NOT to be the case for the demuxers.
Ffmpeg handles the ts files quite happily, as does ffplay. However, ffmpeg's demuxers for mpeg-*s files are named "mpeg" (for ps files) and mpeg-ts (for ts files). Looking at VLC's list of demuxers, found under preferences/all, indicates that the ps demuxer is named PS, and the ts demuxer is named MPEG-TS. The former corresponds to the gstreamer demuxer that is part of one of the plugins packages ("good", IIRC). The gstreamer mpeg-ts demuxer is part of the "bad" plugins package, which is not part of the stock slarm64 packages. This is probably why VLC is building without the ability to handle ts files. The only way to prove this one way or the other is to build the "bad" plugins package, and then rebuild VLC. Which is where I am currently stuck! The "bad" plugins package is so named, not because there is necessarily anything wrong with the plugins, just that they haven't either been fully tested, or the documentation is incomplete. A bit like "-current"! What is really puzzling is how an auto-generated script can have a syntax error in it! I don't really know enough about cmake to diagnose the problem any further at present...! Another option would be to try and build AlienBob's mega-VLC on ARM. Unfortunately, I've hit a snag there too! AlienBob's build requires Apache-ant - fair enough - but that requires Java! Unfortunately, to get hold of Java these days, it seems you MUST sign up for an Oracle account - something I prefer not to do! I also don't want to fill up what is essentially a lightweight machine with a lot of unnecessary clutter. So, back to gstreamer... -- Pete |
Finally managed to get the gstreamer-plugins-bad to compile! The latest versions build with meson, so I tweaked the gstreamer-plugins-good slackbuild, and it built like a charm ind includes libgstmpegtsdemux. Great!
So then I re-built VLC. Still no mpegts demuxer! I'm now completely flummoxed! Where does VLC pick up its TS demuxer? What is the missing dependency? :scratch: -- Pete |
Finally cracked this one!
I installed libdvbpsi - something I've never heard of before - and after re-compiling VLC, both VLC and Kaffeine now function as expected with both .ts files and off-air reception! I've no idea why VLC didn't just use the ffmpeg TS demuxers (already available on my system), but there you go. Problem solved, at last! -- Pete |
All times are GMT -5. The time now is 10:42 PM. |