X-Git-Url: http://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/d0e6c74516e146b40ca220347a91b6c96d0fa332..bb38026f1c7da4cc23680c02a66d2912d2925a58:/blog/index.html diff --git a/blog/index.html b/blog/index.html index 52094993de..2bdeeec807 100644 --- a/blog/index.html +++ b/blog/index.html @@ -19,6 +19,361 @@ +
+
Streaming the Linux desktop to Kodi using VLC and RTSP
+
12th July 2018
+

A while back, I was asked by a friend how to stream the desktop to +my projector connected to Kodi. I sadly had to admit that I had no +idea, as it was a task I never had tried. Since then, I have been +looking for a way to do so, preferable without much extra software to +install on either side. Today I found a way that seem to kind of +work. Not great, but it is a start.

+ +

I had a look at several approaches, for example +using uPnP +DLNA as described in 2011, but it required a uPnP server, fuse and +local storage enough to store the stream locally. This is not going +to work well for me, lacking enough free space, and it would +impossible for my friend to get working.

+ +

Next, it occurred to me that perhaps I could use VLC to create a +video stream that Kodi could play. Preferably using +broadcast/multicast, to avoid having to change any setup on the Kodi +side when starting such stream. Unfortunately, the only recipe I +could find using multicast used the rtp protocol, and this protocol +seem to not be supported by Kodi.

+ +

On the other hand, the rtsp protocol is working! Unfortunately I +have to specify the IP address of the streaming machine in both the +sending command and the file on the Kodi server. But it is showing my +desktop, and thus allow us to have a shared look on the big screen at +the programs I work on.

+ +

I did not spend much time investigating codeces. I combined the +rtp and rtsp recipes from +the +VLC Streaming HowTo/Command Line Examples, and was able to get +this working on the desktop/streaming end.

+ +
+vlc screen:// --sout \
+  '#transcode{vcodec=mp4v,acodec=mpga,vb=800,ab=128}:rtp{dst=projector.local,port=1234,sdp=rtsp://192.168.11.4:8080/test.sdp}'
+
+ +

I ssh-ed into my Kodi box and created a file like this with the +same IP address:

+ +
+echo rtsp://192.168.11.4:8080/test.sdp \
+  > /storage/videos/screenstream.m3u
+
+ +

Note the 192.168.11.4 IP address is my desktops IP address. As far +as I can tell the IP must be hardcoded for this to work. In other +words, if someone elses machine is going to do the steaming, you have +to update screenstream.m3u on the Kodi machine and adjust the vlc +recipe. To get started, locate the file in Kodi and select the m3u +file while the VLC stream is running. The desktop then show up in my +big screen. :)

+ +

When using the same technique to stream a video file with audio, +the audio quality is really bad. No idea if the problem is package +loss or bad parameters for the transcode. I do not know VLC nor Kodi +enough to tell.

+ +

Update 2018-07-12: Johannes Schauer send me a few +succestions and reminded me about an important step. The "screen:" +input source is only available once the vlc-plugin-access-extra +package is installed on Debian. Without it, you will see this error +message: "VLC is unable to open the MRL 'screen://'. Check the log +for details." He further found that it is possible to drop some parts +of the VLC command line to reduce the amount of hardcoded information. +It is also useful to consider using cvlc to avoid having the VLC +window in the desktop view. In sum, this give us this command line on +the source end + +

+cvlc screen:// --sout \
+  '#transcode{vcodec=mp4v,acodec=mpga,vb=800,ab=128}:rtp{sdp=rtsp://:8080/}'
+
+ +

and this on the Kodi end

+ +

+echo rtsp://192.168.11.4:8080/ \
+  > /storage/videos/screenstream.m3u
+
+ +

Still bad image quality, though. But I did discover that streaming +a DVD using dvdsimple:///dev/dvd as the source had excellent video and +audio quality, so I guess the issue is in the input or transcoding +parts, not the rtsp part. I've tried to change the vb and ab +parameters to use more bandwidth, but it did not make a +difference.

+ +

I further received a suggestion from Einar Haraldseid to try using +gstreamer instead of VLC, and this proved to work great! He also +provided me with the trick to get Kodi to use a multicast stream as +its source. By using this monstrous oneliner, I can stream my desktop +with good video quality in reasonable framerate to the 239.255.0.1 +multicast address on port 1234: + +

+gst-launch-1.0 ximagesrc use-damage=0 ! video/x-raw,framerate=30/1 ! \
+  videoconvert ! queue2 ! \
+  x264enc bitrate=8000 speed-preset=superfast tune=zerolatency qp-min=30 \
+  key-int-max=15 bframes=2 ! video/x-h264,profile=high ! queue2 ! \
+  mpegtsmux alignment=7 name=mux ! rndbuffersize max=1316 min=1316 ! \
+  udpsink host=239.255.0.1 port=1234 ttl-mc=1 auto-multicast=1 sync=0 \
+  pulsesrc device=$(pactl list | grep -A2 'Source #' | \
+    grep 'Name: .*\.monitor$' |  cut -d" " -f2|head -1) ! \
+  audioconvert ! queue2 ! avenc_aac ! queue2 ! mux.
+
+ +

and this on the Kodi end

+ +

+echo udp://@239.255.0.1:1234 \
+  > /storage/videos/screenstream.m3u
+
+ +

Note the trick to pick a valid pulseaudio source. It might not +pick the one you need. This approach will of course lead to trouble +if more than one source uses the same multicast port and address. +Note the ttl-mc=1 setting, which limit the multicast packages to the +local network. If the value is increased, your screen will be +broadcasted further, one network "hop" for each increase (read up on +multicast to learn more. :)!

+ +

Having cracked how to get Kodi to receive multicast streams, I +could use this VLC command to stream to the same multicast address. +The image quality is way better than the rtsp approach, but gstreamer +seem to be doing a better job.

+ +
+cvlc screen:// --sout '#transcode{vcodec=mp4v,acodec=mpga,vb=800,ab=128}:rtp{mux=ts,dst=239.255.0.1,port=1234,sdp=sap}'
+
+ +

As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

+
+
+ + + Tags: debian, english, video. + + +
+
+
+ +
+
What is the most supported MIME type in Debian in 2018?
+
9th July 2018
+

Five years ago, +I +measured what the most supported MIME type in Debian was, by +analysing the desktop files in all packages in the archive. Since +then, the DEP-11 AppStream system has been put into production, making +the task a lot easier. This made me want to repeat the measurement, +to see how much things changed. Here are the new numbers, for +unstable only this time: + +

Debian Unstable:

+ +
+  count MIME type
+  ----- -----------------------
+     56 image/jpeg
+     55 image/png
+     49 image/tiff
+     48 image/gif
+     39 image/bmp
+     38 text/plain
+     37 audio/mpeg
+     34 application/ogg
+     33 audio/x-flac
+     32 audio/x-mp3
+     30 audio/x-wav
+     30 audio/x-vorbis+ogg
+     29 image/x-portable-pixmap
+     27 inode/directory
+     27 image/x-portable-bitmap
+     27 audio/x-mpeg
+     26 application/x-ogg
+     25 audio/x-mpegurl
+     25 audio/ogg
+     24 text/html
+
+ +

The list was created like this using a sid chroot: "cat +/var/lib/apt/lists/*sid*_dep11_Components-amd64.yml.gz| zcat | awk '/^ +- \S+\/\S+$/ {print $2 }' | sort | uniq -c | sort -nr | head -20"

+ +

It is interesting to see how image formats have passed text/plain +as the most announced supported MIME type. These days, thanks to the +AppStream system, if you run into a file format you do not know, and +want to figure out which packages support the format, you can find the +MIME type of the file using "file --mime <filename>", and then +look up all packages announcing support for this format in their +AppStream metadata (XML or .desktop file) using "appstreamcli +what-provides mimetype <mime-type>. For example if you, like +me, want to know which packages support inode/directory, you can get a +list like this:

+ +

+% appstreamcli what-provides mimetype inode/directory | grep Package: | sort
+Package: anjuta
+Package: audacious
+Package: baobab
+Package: cervisia
+Package: chirp
+Package: dolphin
+Package: doublecmd-common
+Package: easytag
+Package: enlightenment
+Package: ephoto
+Package: filelight
+Package: gwenview
+Package: k4dirstat
+Package: kaffeine
+Package: kdesvn
+Package: kid3
+Package: kid3-qt
+Package: nautilus
+Package: nemo
+Package: pcmanfm
+Package: pcmanfm-qt
+Package: qweborf
+Package: ranger
+Package: sirikali
+Package: spacefm
+Package: spacefm
+Package: vifm
+%
+

+ +

Using the same method, I can quickly discover that the Sketchup file +format is not yet supported by any package in Debian:

+ +

+% appstreamcli what-provides mimetype  application/vnd.sketchup.skp
+Could not find component providing 'mimetype::application/vnd.sketchup.skp'.
+%
+

+ +

Yesterday I used it to figure out which packages support the STL 3D +format:

+ +

+% appstreamcli what-provides mimetype  application/sla|grep Package
+Package: cura
+Package: meshlab
+Package: printrun
+%
+

+ +

PS: A new version of Cura was uploaded to Debian yesterday.

+ +

As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

+
+
+ + + Tags: debian, english, isenkram. + + +
+
+
+ +
+
Debian APT upgrade without enough free space on the disk...
+
8th July 2018
+

Quite regularly, I let my Debian Sid/Unstable chroot stay untouch +for a while, and when I need to update it there is not enough free +space on the disk for apt to do a normal 'apt upgrade'. I normally +would resolve the issue by doing 'apt install <somepackages>' to +upgrade only some of the packages in one batch, until the amount of +packages to download fall below the amount of free space available. +Today, I had about 500 packages to upgrade, and after a while I got +tired of trying to install chunks of packages manually. I concluded +that I did not have the spare hours required to complete the task, and +decided to see if I could automate it. I came up with this small +script which I call 'apt-in-chunks':

+ +

+#!/bin/sh
+#
+# Upgrade packages when the disk is too full to upgrade every
+# upgradable package in one lump.  Fetching packages to upgrade using
+# apt, and then installing using dpkg, to avoid changing the package
+# flag for manual/automatic.
+
+set -e
+
+ignore() {
+    if [ "$1" ]; then
+	grep -v "$1"
+    else
+	cat
+    fi
+}
+
+for p in $(apt list --upgradable | ignore "$@" |cut -d/ -f1 | grep -v '^Listing...'); do
+    echo "Upgrading $p"
+    apt clean
+    apt install --download-only -y $p
+    for f in /var/cache/apt/archives/*.deb; do
+	if [ -e "$f" ]; then
+	    dpkg -i /var/cache/apt/archives/*.deb
+	    break
+	fi
+    done
+done
+

+ +

The script will extract the list of packages to upgrade, try to +download the packages needed to upgrade one package, install the +downloaded packages using dpkg. The idea is to upgrade packages +without changing the APT mark for the package (ie the one recording of +the package was manually requested or pulled in as a dependency). To +use it, simply run it as root from the command line. If it fail, try +'apt install -f' to clean up the mess and run the script again. This +might happen if the new packages conflict with one of the old +packages. dpkg is unable to remove, while apt can do this.

+ +

It take one option, a package to ignore in the list of packages to +upgrade. The option to ignore a package is there to be able to skip +the packages that are simply too large to unpack. Today this was +'ghc', but I have run into other large packages causing similar +problems earlier (like TeX).

+ +

Update 2018-07-08: Thanks to Paul Wise, I am aware of two +alternative ways to handle this. The "unattended-upgrades +--minimal-upgrade-steps" option will try to calculate upgrade sets for +each package to upgrade, and then upgrade them in order, smallest set +first. It might be a better option than my above mentioned script. +Also, "aptutude upgrade" can upgrade single packages, thus avoiding +the need for using "dpkg -i" in the script above.

+ +

As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

+
+
+ + + Tags: debian, english. + + +
+
+
+
The worlds only stone power plant?
30th June 2018
@@ -37,6 +392,10 @@ according to its own statements it is producing more power than it is using, and selling the surplus electricity to the Norwegian power grid. I find the concept truly amazing. Is this the worlds only stone power plant?

+ +

As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

@@ -355,192 +714,6 @@ messages with strangers like Facebook and Google.

-
-
H, Ap, Frp og Venstre går for DNA-innsamling av hele befolkningen
-
14th March 2018
-

I går kom det nok et argument for å holde seg unna det norske -helsevesenet. Da annonserte et stortingsflertall, bestående av Høyre, -Arbeiderpartiet, Fremskrittspartiet og Venstre, at de går inn for å -samle inn og lagre DNA-prøver fra hele befolkningen i Norge til evig -tid. Endringen gjelder innsamlede blodprøver fra nyfødte i Norge. -Det vil dermed ta litt tid før en har hele befolkningen, men det er -dit vi havner gitt nok tid. I dag er det nesten hundre prosent -oppslutning om undersøkelsen som gjøres like etter fødselen, på -bakgrunn av blodprøven det er snakk om å lagre, for å oppdage endel -medfødte sykdommer. Blodprøven lagres i dag i inntil seks år. -Stortingets -flertallsinnstilling er at tidsbegrensingen skal fjernes, og mener -at tidsubegrenset lagring ikke vil påvirke oppslutningen om -undersøkelsen.

- -

Datatilsynet har ikke akkurat applaudert forslaget:

- -

- -

«Datatilsynet mener forslaget ikke i tilstrekkelig grad - synliggjør hvilke etiske og personvernmessige utfordringer som må - diskuteres før en etablerer en nasjonal biobank med blodprøver fra - hele befolkningen.»

- -

- -

Det er flere historier om hvordan innsamlet biologisk materiale har -blitt brukt til andre formål enn de ble innsamlet til, og historien om -folkehelseinstituttets -lagring på vegne av politiet (Kripos) av innsamlet biologisk materiale -og DNA-informasjon i strid med loven viser at en ikke kan være -trygg på at lover og intensjoner beskytter de som blir berørt mot -misbruk av slik privat og personlig informasjon.

- -

Det er verdt å merke seg at det kan forskes på de innsamlede -blodprøvene uten samtykke fra den det gjelder (eller foreldre når det -gjelder barn), etter en lovendring for en stund tilbake, med mindre -det er sendt inn skjema der en reserverer seg mot forskning uten -samtykke. Skjemaet er tilgjengelig fra -folkehelseinstituttets -websider, og jeg anbefaler, uavhengig av denne saken, varmt alle å -sende inn skjemaet for å dokumentere hvor mange som ikke synes det er -greit å fjerne krav om samtykke.

- -

I tillegg bør en kreve destruering av alt biologisk materiale som -er samlet inn om en selv, for å redusere eventuelle negative -konsekvenser i fremtiden når materialet kommer på avveie eller blir -brukt uten samtykke, men det er så vidt jeg vet ikke noe system for -dette i dag.

- -

Som vanlig, hvis du bruker Bitcoin og ønsker å vise din støtte til -det jeg driver med, setter jeg pris på om du sender Bitcoin-donasjoner -til min adresse -15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

-
-
- - - Tags: norsk, personvern, surveillance. - - -
-
-
- -
-
First rough draft Norwegian and Spanish edition of the book Made with Creative Commons
-
13th March 2018
-

I am working on publishing yet another book related to Creative -Commons. This time it is a book filled with interviews and histories -from those around the globe making a living using Creative -Commons.

- -

Yesterday, after many months of hard work by several volunteer -translators, the first draft of a Norwegian Bokmål edition of the book -Made with Creative Commons from 2017 -was complete. The Spanish translation is also complete, while the -Dutch, Polish, German and Ukraine edition need a lot of work. Get in -touch if you want to help make those happen, or would like to -translate into your mother tongue.

- -

The whole book project started when -Gunnar Wolf announced that he -was going to make a Spanish edition of the book. I noticed, and -offered some input on how to make a book, based on my experience with -translating the -Free -Culture and -The Debian -Administrator's Handbook books to Norwegian Bokmål. To make a -long story short, we ended up working on a Bokmål edition, and now the -first rough translation is complete, thanks to the hard work of -Ole-Erik Yrvin, Ingrid Yrvin, Allan Nordhøy and myself. The first -proof reading is almost done, and only the second and third proof -reading remains. We will also need to translate the 14 figures and -create a book cover. Once it is done we will publish the book on -paper, as well as in PDF, ePub and possibly Mobi formats.

- -

The book itself originates as a manuscript on Google Docs, is -downloaded as ODT from there and converted to Markdown using pandoc. -The Markdown is modified by a script before is converted to DocBook -using pandoc. The DocBook is modified again using a script before it -is used to create a Gettext POT file for translators. The translated -PO file is then combined with the earlier mentioned DocBook file to -create a translated DocBook file, which finally is given to dblatex to -create the final PDF. The end result is a set of editions of the -manuscript, one English and one for each of the translations.

- -

The translation is conducted using -the -Weblate web based translation system. Please have a look there -and get in touch if you would like to help out with proof -reading. :)

- -

As usual, if you use Bitcoin and want to show your support of my -activities, please send Bitcoin donations to my address -15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

-
-
- - - Tags: docbook, english. - - -
-
-
- -
-
Debian used in the subway info screens in Oslo, Norway
-
2nd March 2018
-

Today I was pleasantly surprised to discover my operating system of -choice, Debian, was used in the info screens on the subway stations. -While passing Nydalen subway station in Oslo, Norway, I discovered the -info screen booting with some text scrolling. I was not quick enough -with my camera to be able to record a video of the scrolling boot -screen, but I did get a photo from when the boot got stuck with a -corrupt file system: - -

[photo of subway info screen]

- -

While I am happy to see Debian used more places, some details of the -content on the screen worries me.

- -

The image show the version booting is 'Debian GNU/Linux lenny/sid', -indicating that this is based on code taken from Debian Unstable/Sid -after Debian Etch (version 4) was released 2007-04-08 and before -Debian Lenny (version 5) was released 2009-02-14. Since Lenny Debian -has released version 6 (Squeeze) 2011-02-06, 7 (Wheezy) 2013-05-04, 8 -(Jessie) 2015-04-25 and 9 (Stretch) 2017-06-15, according to -a Debian -version history on Wikpedia. This mean the system is running -around 10 year old code, with no security fixes from the vendor for -many years.

- -

This is not the first time I discover the Oslo subway company, -Ruter, running outdated software. In 2012, -I -discovered the ticket vending machines were running Windows 2000, -and this was -still -the case in 2016. Given the response from the responsible people -in 2016, I would assume the machines are still running unpatched -Windows 2000. Thus, an unpatched Debian setup come as no surprise.

- -

The photo is made available under the license terms -Creative Commons -4.0 Attribution International (CC BY 4.0).

- -

As usual, if you use Bitcoin and want to show your support of my -activities, please send Bitcoin donations to my address -15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

-
-
- - - Tags: english, ruter. - - -
-
-
-

RSS feed