Tag Archives: vlc

A new Raspbian update: multimedia, Python and more

Post Syndicated from Simon Long original https://www.raspberrypi.org/blog/raspbian-update-november-2018/

Today we’re releasing a new update for Raspbian, including a multimedia player, updated Thonny, and more. Here’s Simon with everything you need to know.

Updating Raspbian on your Raspberry Pi || Raspberry Pi Foundation

How to update to the latest version of Raspbian on your Raspberry Pi.

VLC Media Player

When I first joined Raspberry Pi, back in the dim and distant past (in reality 2014, but it does seem a long time ago now…), and I started looking at Raspbian, I made a list of the additional features and applications that I thought it needed to be a “complete” modern desktop operating system. Over the years, we’ve managed to tick off most of the items on that list, but one glaring omission has been nagging at me all this time: a decent media player. Windows has Windows Media Player; MacOS has QuickTime Player and iTunes; but we’ve had a big hole where something similar ought to be for Raspbian. It’s been a common request on the forums, and while we’ve had bits and pieces that do some of the job, like the command line OMXPlayer application, we really wanted a nice GUI-based media player.

VLC is one of those programs that “just works” for media playback; it is cross-platform, it has a nice interface, and it plays back pretty much anything you throw at it. It was the player I really wanted to use in Raspbian — but it was unable to access VideoCore’s video decoding hardware, and the software video codecs in VLC were too slow to be anything more than irritating when running on Raspberry Pi, so it really wasn’t worth shipping it. Until now.

After a lot of work (by people far cleverer than me), we are now able to announce that Raspbian includes a fully hardware-accelerated version of VLC. It plays most audio file formats; it uses software codecs for many video formats, and it uses VideoCore’s video engine to accelerate playback of H.264, MPEG-2 and VC-1 video. (Note that you will need to buy additional codec licences for MPEG and VC-1; if you’ve already bought a licence to enable hardware acceleration in OMXPlayer and Kodi, this licence will also enable these codecs for VLC.)

Raspbian update screenshot

This is still a work in progress — we’ve got most of the major bugs out, but there will most likely be the odd glitch, and you’ll probably find that Pi Zero and Pi 1 will still struggle with some content. But once you’ve updated your Pi, you should find that double-clicking on a video file will open it in VLC and play it back with decent quality.

Thonny 3

A couple of years ago, as part of the list of additional features mentioned above, we looked for a nicer Python development environment than IDLE, and we found Thonny — a really elegant combination of a user-friendly IDE with features that are also useful to expert developers. It’s been our standard IDE shipped with Raspbian ever since, and Aivar Annamaa, the developer, has been very responsive to our feedback and requests for new features.

He’s recently released version 3 of Thonny, and this is now the version in Raspbian. Version 3 offers a lot of useful new debugging features, such as breakpoints and an Assistant feature that analyses your code to find bugs that Python’s syntax checker misses. There is a lot more information about Thonny 3 on Aivar’s website — it’s well worth a read.

Raspbian update screenshot

We’ve also made one user interface change this time. We’ve always offered the choice between running Thonny in its regular mode, and a cut-down “simple” mode for beginners, which removes the menus and gives a fixed screen layout. Up until now, switching between the two has happened via different entries in the main Raspberry Pi menu, but that was a bit clumsy. In the new version, simple mode is the default, and you can switch Thonny into regular mode by clicking the link in the top right-hand corner of the window; if you want to switch back to simple mode, select it on the General tab of the Thonny options dialogue, which is available in the Tools menu. (Thonny will always start in the last mode you selected.)

Desktop configuration

One of the other changes we’ve made this time is one that hopefully most people won’t notice!

The configuration of the Raspberry Pi desktop has always been a bit of a mess. Due to the fact that the underlying LXDE desktop environment is made up of a bunch of different programs all running together, trying to set up something like the system font or the highlight colour involves making changes to several configuration files at once. This is why pretty much the first thing I did was to write the Appearance Settings application to try to make this easier than digging around in multiple config files.

Linux desktop applications are supposed to have a global configuration file (usually in the directory /etc/xdg/) that takes effect unless overridden by a local configuration file (in the hidden .config subdirectory of the user’s home directory). Unfortunately, not all the desktop components adhered to this specification. As a result, getting the Appearance Settings application to work involved quite a bit of kludging things about under the hood, and one of these kludges was to always keep a local copy of each of the configuration files and to ignore the global versions.

This worked, but it had the undesirable side effect that any time we wanted to update the appearance of the desktop, we had to delete all the local configuration files so they could be replaced by the new ones, and this meant that any changes the user had made to the configuration were lost. This was quite annoying for many people, so with this release, we’ve tried to stop doing that!

Most of the desktop components have now been modified so that they correctly read the global configuration files, and for future releases, we are going to try to just modify the global versions of these files and not touch the local ones. If we update the configuration, you will see a message informing you that this has happened, but your local files will be left unchanged. To make sure you get the latest configuration, launch Appearance Settings and choose one of the buttons on the “Defaults” tab; doing this will set your desktop to our currently recommended defaults. But if you want to stick with what you’ve already got, just don’t do that! You can even try the new defaults out: press one of the defaults buttons, and if you don’t like the results, just hit Cancel, and your previous configuration will be restored.

Raspbian update screenshot

One final point on this: in order to get this all to work properly in future, we have had to delete a few local files on this occasion. These are files that most people will never have modified anyway, so this will hopefully not present any problems. But just in case, they have been backed up in the oldconffiles subdirectory of the user’s home directory.

Multiple images

When I first started working on Raspbian, the desktop image file was just under 1GB in size. This has gradually crept up over the years, and now it’s around 1.75GB. While downloading a file of this size isn’t a significant problem for someone with fibre broadband, many people are on slower connections where such large downloads can take hours.

In order to try and address this, for all future releases we will now release two separate images. The default Raspbian release is now a minimal install — it gives you the desktop, the Chromium browser, the VLC media player, Python, and some accessory programs. Running alongside this is the “Raspbian Full” image, which also includes all our recommended programs: LibreOffice, Scratch, SonicPi, Thonny, Mathematica, and various others.

The Recommended Software program that we launched in the last release can be used to install or uninstall any of the additional programs that are in the full image; if you download the minimal image and check all the options in Recommended Software, you will end up with the full image, and vice versa.

Raspbian update screenshot

Hopefully, this means that downloading Raspbian will be easier for people on slower connections, and that you can easily add just the programs you want. The full image is provided for everyone who wants to get everything in one go, or who won’t have access to the internet to download additional programs once their Pi is up and running.

We’ll also continue to produce the existing Raspbian Lite image for people who only want a command-line version with no desktop.

Update Raspbian

Both the new images are available to download from the usual place on our site.

To update an existing image, open a terminal window and use the usual commands:

sudo apt-get update
sudo apt-get dist-upgrade

To install the new VLC media player from a terminal, enter:

sudo apt-get update
sudo apt-get install vlc

As ever, all feedback is welcome, so please leave a comment below!

The post A new Raspbian update: multimedia, Python and more appeared first on Raspberry Pi.

Security updates for Friday

Post Syndicated from jake original https://lwn.net/Articles/740997/rss

Security updates have been issued by Arch Linux (chromium and vlc), Debian (erlang), Mageia (ffmpeg, tor, and wireshark), openSUSE (chromium, opensaml, openssh, openvswitch, and php7), Oracle (postgresql), Red Hat (chromium-browser, postgresql, rh-postgresql94-postgresql, rh-postgresql95-postgresql, and rh-postgresql96-postgresql), SUSE (firefox, java-1_6_0-ibm, opensaml, and xen), and Ubuntu (kernel, linux, linux-aws, linux-kvm, linux-raspi2, linux-snapdragon, linux, linux-raspi2, linux-azure, linux-gcp, linux-hwe, linux-lts-trusty, linux-lts-xenial, linux-aws, and rsync).

Security updates for Monday

Post Syndicated from ris original https://lwn.net/Articles/740044/rss

Security updates have been issued by Arch Linux (varnish), Debian (libofx and python-werkzeug), Fedora (fedpkg, mediawiki, qt5-qtwebengine, and rpkg), Mageia (apr-util, bchunk, chromium-browser-stable, vlc, and webkit2), openSUSE (backintime, konversation, perl, tboot, and tnef), Oracle (samba), Red Hat (curl and samba), Scientific Linux (samba), and SUSE (kvm and samba).

Security updates for Wednesday

Post Syndicated from jake original https://lwn.net/Articles/739858/rss

Security updates have been issued by Arch Linux (roundcubemail), Debian (optipng, samba, and vlc), Fedora (compat-openssl10, fedpkg, git, jbig2dec, ldns, memcached, openssl, perl-Net-Ping-External, python-copr, python-XStatic-jquery-ui, rpkg, thunderbird, and xen), SUSE (tomcat), and Ubuntu (db, db4.8, db5.3, linux, linux-raspi2, linux-aws, linux-azure, linux-gcp, and samba).

Security updates for Friday

Post Syndicated from jake original https://lwn.net/Articles/735121/rss

Security updates have been issued by Arch Linux (ffmpeg2.8, nvidia, and openvpn), Fedora (git, mercurial, moodle, php-horde-Horde-Image, poppler, and pure-ftpd), openSUSE (fmpeg and vlc), Oracle (firefox, kernel, and nss), Red Hat (firefox and nss), Slackware (mozilla), and SUSE (firefox).

Security updates for Monday

Post Syndicated from ris original https://lwn.net/Articles/727485/rss

Security updates have been issued by Debian (bind9, jetty, mpg123, phpldapadmin, sqlite3, and xorg-server), Fedora (bind, bind99, dhcp, drupal7, GraphicsMagick, httpd, irssi, jetty, jetty-alpn, jetty-test-helper, libdb, libgcrypt, mosquitto, ocaml, pius, qt5-qtwebkit, tomcat, xen, and zabbix), Gentoo (feh, gajim, game-music-emu, jasper, libcroco, libsndfile, man-db, nm-applet, openslp, phpmyadmin, roundcube, virglrenderer, and vlc), openSUSE (irssi, kernel, libgcrypt, and xen), Slackware (irssi and php), and Ubuntu (poppler).

Burner laptops for DEF CON

Post Syndicated from Robert Graham original http://blog.erratasec.com/2017/07/burner-laptops-for-def-con.html

Hacker summer camp (Defcon, Blackhat, BSidesLV) is upon us, so I thought I’d write up some quick notes about bringing a “burner” laptop. Chrome is your best choice in terms of security, but I need Windows/Linux tools, so I got a Windows laptop.

I chose the Asus e200ha for $199 from Amazon with free (and fast) shipping. There are similar notebooks with roughly the same hardware and price from other manufacturers (HP, Dell, etc.), so I’m not sure how this compares against those other ones. However, it fits my needs as a “burner” laptop, namely:

  • cheap
  • lasts 10 hours easily on battery
  • weighs 2.2 pounds (1 kilogram)
  • 11.6 inch and thin

Some other specs are:

  • 4 gigs of RAM
  • 32 gigs of eMMC flash memory
  • quad core 1.44 GHz Intel Atom CPU
  • Windows 10
  • free Microsoft Office 365 for one year
  • good, large keyboard
  • good, large touchpad
  • USB 3.0
  • microSD
  • WiFi ac
  • no fans, completely silent

There are compromises, of course.

  • The Atom CPU is slow, thought it’s only noticeable when churning through heavy webpages. Adblocking addons or Brave are a necessity. Most things are usably fast, such as using Microsoft Word.
  • Crappy sound and video, though VLC does a fine job playing movies with headphones on the airplane. Using in bright sunlight will be difficult.
  • micro-HDMI, keep in mind if intending to do presos from it, you’ll need an HDMI adapter
  • It has limited storage, 32gigs in theory, about half that usable.
  • Does special Windows 10 compressed install that you can’t actually upgrade without a completely new install. It doesn’t have the latest Windows 10 Creators update. I lost a gig thinking I could compress system files.

Copying files across the 802.11ac WiFi to the disk was quite fast, several hundred megabits-per-second. The eMMC isn’t as fast as an SSD, but its a lot faster than typical SD card speeds.

The first thing I did once I got the notebook was to install the free VeraCrypt full disk encryption. The CPU has AES acceleration, so it’s fast. There is a problem with the keyboard driver during boot that makes it really hard to enter long passwords — you have to carefully type one key at a time to prevent extra keystrokes from being entered.

You can’t really install Linux on this computer, but you can use virtual machines. I installed VirtualBox and downloaded the Kali VM. I had some problems attaching USB devices to the VM. First of all, VirtualBox requires a separate downloaded extension to get USB working. Second, it conflicts with USBpcap that I installed for Wireshark.

It comes with one year of free Office 365. Obviously, Microsoft is hoping to hook the user into a longer term commitment, but in practice next year at this time I’d get another burner $200 laptop rather than spend $99 on extending the Office 365 license.

Let’s talk about the CPU. It’s Intel’s “Atom” processor, not their mainstream (Core i3 etc.) processor. Even though it has roughly the same GHz as the processor in a 11inch MacBook Air and twice the cores, it’s noticeably and painfully slower. This is especially noticeable on ad-heavy web pages, while other things seem to work just fine. It has hardware acceleration for most video formats, though I had trouble getting Netflix to work.

The tradeoff for a slow CPU is phenomenal battery life. It seems to last forever on battery. It’s really pretty cool.


A Chromebook is likely more secure, but for my needs, this $200 is perfect.

Security updates for Tuesday

Post Syndicated from ris original https://lwn.net/Articles/726568/rss

Security updates have been issued by Arch Linux (expat and poppler), Debian (unrar-nonfree and vlc), Fedora (chromium and mercurial), Gentoo (freeradius, kauth, and libreoffice), Mageia (glibc, irssi, kernel, kernel-linus, kernel-tmb, and rpcbind/libtirpc), openSUSE (libgcrypt, netpbm, and sudo), Oracle (sudo), Scientific Linux (mercurial), Slackware (kernel), SUSE (jakarta-taglibs-standard, kernel, and kernel-source), and Ubuntu (apache2).

Security updates for Tuesday

Post Syndicated from ris original https://lwn.net/Articles/724150/rss

Security updates have been issued by Arch Linux (lib32-nss), Debian (bind9, exiv2, fop, imagemagick, libical, libonig, libsndfile, mosquitto, openjdk-7, rzip, strongswan, and tnef), Fedora (git, kernel, lynis, moodle, mupdf, samba, systemd, and webkitgtk4), Mageia (perl-Image-Info and vlc), openSUSE (ffmpeg2, git, java-1_7_0-openjdk, libplist, libsndfile, and samba), Oracle (kernel and samba3x), Red Hat (nss), Scientific Linux (nss), and Ubuntu (imagemagick, juju-core, libtiff, strongswan, and webkit2gtk).

Check Point: Hacked in Translation

Post Syndicated from corbet original https://lwn.net/Articles/723696/rss

Check Point has issued an
that a number of video-player applications can be compromised
via specially crafted subtitles. “By crafting malicious subtitle
files, which are then downloaded by a victim’s media player, attackers can
take complete control over any type of device via vulnerabilities found in
many popular streaming platforms, including VLC, Kodi (XBMC), Popcorn-Time
and strem.io. We estimate there are approximately 200 million video players
and streamers that currently run the vulnerable software, making this one
of the most widespread, easily accessed and zero-resistance vulnerability
reported in recent years.

Security updates for Monday

Post Syndicated from ris original https://lwn.net/Articles/723472/rss

Security updates have been issued by Arch Linux (fop), Debian (dropbear, icu, and openjdk-7), Fedora (chicken, cinnamon-settings-daemon, jbig2dec, libtirpc, sane-backends, and smb4k), Mageia (flash-player-plugin, vlc, and webmin), Oracle (libtirpc and rpcbind), Red Hat (kdelibs, libtirpc, rpcbind, and samba), and SUSE (kernel).

PulseAudio and Jack

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/when-pa-and-when-not.html

#nocomments yes

One thing became very clear to me during my trip to the Linux Audio Conference 2010
in Utrecht: even many pro audio folks are not sure what Jack does that PulseAudio doesn’t do and what
PulseAudio does that Jack doesn’t do; why they are not competing, why
you cannot replace one by the other, and why merging them (at least in
the short term) might not make immediate sense. In other words, why
millions of phones on this world run PulseAudio and not Jack, and why
a music studio running PulseAudio is crack.

To light this up a bit and for future reference I’ll try to explain in the
following text why there is this seperation between the two systems and why this isn’t
necessarily bad. This is mostly a written up version of (parts of) my slides
from LAC
, so if you attended that event you might find little new, but I hope
it is interesting nonetheless.

This is mostly written from my perspective as a hacker working on
consumer audio stuff (more specifically having written most of
PulseAudio), but I am sure most pro audio folks would agree with the
points I raise here, and have more things to add. What I explain below
is in no way comprehensive, just a list of a couple of points I think
are the most important, as they touch the very core of both
systems (and we ignore all the toppings here, i.e. sound effects, yadda, yadda).

First of all let’s clear up the background of the sound server use cases here:

Consumer Audio (i.e. PulseAudio)Pro Audio (i.e. Jack)
Reducing power usage is a defining requirement, most systems are battery powered (Laptops, Cell Phones).Power usage usually not an issue, power comes out of the wall.
Must support latencies low enough for telephony and
games. Also covers high latency uses, such as movie and music playback
(2s of latency is a good choice).
Minimal latencies are a
definining requirement.
System is highly dynamic, with applications starting/stopping, hardware added and removed all the time.System is usually static in its configuration during operation.
User is usually not proficient in the technologies used.[1]User is usually a professional and knows audio technology and computers well.
User is not necessarily the administrator of his machine, might have limited access.User usually administrates his own machines, has root privileges.
Audio is just one use of the system among many, and often just a background job.Audio is the primary purpose of the system.
Hardware tends to have limited resources and be crappy and cheap.Hardware is powerful, expensive and high quality.

Of course, things are often not as black and white like this, there are uses
that fall in the middle of these two areas.

From the table above a few conclusions may be drawn:

  • A consumer sound system must support both low and high latency operation.
    Since low latencies mean high CPU load and hence high power
    consumption[2] (Heisenberg…), a system should always run with the
    highest latency latency possible, but the lowest latency necessary.
  • Since the consumer system is highly dynamic in its use latencies must be
    adjusted dynamically too. That makes a design such as PulseAudio’s timer-based scheduling important.
  • A pro audio system’s primary optimization target is low latency. Low
    power usage, dynamic changeble configuration (i.e. a short drop-out while you
    change your pipeline is acceptable) and user-friendliness may be sacrificed for
  • For large buffer sizes a zero-copy design suggests itself: since data
    blocks are large the cache pressure can be considerably reduced by zero-copy
    designs. Only for large buffers the cost of passing pointers around is
    considerable smaller than the cost of passing around the data itself (or the
    other way round: if your audio data has the same size as your pointers, then
    passing pointers around is useless extra work).
  • On a resource constrained system the ideal audio pipeline does not touch
    and convert the data passed along it unnecessarily. That makes it important to
    support natively the sample types and interleaving modes of the audio source or
  • A consumer system needs to simplify the view on the hardware, hide the its
    complexity: hide redundant mixer elements, or merge them while making use of
    the hardware capabilities, and extending it in software so that the same
    functionality is provided on all hardware. A production system should not hide
    or simplify the hardware functionality.
  • A consumer system should not drop-out when a client misbehaves or the
    configuration changes (OTOH if it happens in exceptions it is not disastrous
    either). A synchronous pipeline is hence not advisable, clients need to supply
    their data asynchronously.
  • In a pro audio system a drop-out during reconfiguration is acceptable,
    during operation unacceptable.
  • In consumer audio we need to make compromises on resource usage,
    which pro audio does not have to commit to. Example: a pro audio
    system can issue memlock() with little limitations since the
    hardware is powerful (i.e. a lot of RAM available) and audio is the
    primary purpose. A consumer audio system cannot do that because that
    call practically makes memory unavailable to other applications,
    increasing their swap pressure. And since audio is not the primary
    purpose of the system and resources limited we hence need to find a
    different way.

Jack has been designed for low latencies, where synchronous
operation is advisable, meaning that a misbehaving client call stall
the entire pipeline. Changes of the pipeline or latencies usually
result in drop-outs in one way or the other, since the entire pipeline
is reconfigured, from the hardware to the various clients. Jack only
supports FLOAT32 samples and non-interleaved audio channels (and that
is a good thing). Jack does not employ reference-counted zero-copy
buffers. It does not try to simplify the hardware mixer in any

PulseAudio OTOH can deal with varying latancies, dynamically
adjusting to the lowest latencies any of the connected clients
. Client communication is fully asynchronous, a single client
cannot stall the entire pipeline. PulseAudio supports a variety of PCM
formats and channel setups. PulseAudio’s design is heavily based on
reference-counted zero-copy buffers that are passed around, even
between processes, instead of the audio data itself. PulseAudio tries
to simplify the hardware mixer as suggested above.

Now, the two paragraphs above hopefully show how Jack is more
suitable for the pro audio use case and PulseAudio more for the
consumer audio use case. One question asks itself though: can we marry
the two approaches? Yes, we probably can, MacOS has a unified approach
for both uses. However, it is not clear this would be a good
idea. First of all, a system with the complexities introduced by
sample format/channel mapping conversion, as well as dynamically
changing latencies and pipelines, and asynchronous behaviour would
certainly be much less attractive to pro audio developers. In fact,
that Jack limits itself to synchronous, FLOAT32-only,
non-interleaved-only audio streams is one of the big features of its
design. Marrying the two approaches would corrupt that. A merged
solution would probably not have a good stand in the community.

But it goes even further than this: what would the use case for
this be? After all, most of the time, you don’t want your event
sounds, your Youtube, your VoIP and your Rhythmbox mixed into the new
record you are producing. Hence a clear seperation between the two
worlds might even be handy?

Also, let’s not forget that we lack the manpower to even create
such an audio chimera.

So, where to from here? Well, I think we should put the focus on
cooperation instead of amalgamation: teach PulseAudio to go out of the
way as soon as Jack needs access to the device, and optionally make
PulseAudio a normal JACK client while both are running. That way, the
user has the option to use the PulseAudio supplied streams, but
normally does not see them in his pipeline. The first part of this has
already been implemented: Jack2 and PulseAudio do not fight for the
audio device, a friendly handover takes place. Jack takes precedence,
PulseAudio takes the back seat. The second part is still missing: you
still have to manually hookup PulseAudio to Jack if you are interested
in its streams. If both are implemented starting Jack basically has
the effect of replacing PulseAudio’s core with the Jack core, while
still providing full compatibility with PulseAudio clients.

And that I guess is all I have to say on the entire Jack and
PulseAudio story.

Oh, one more thing, while we are at clearing things up: some news
sites claim that PulseAudio’s not necessarily stellar reputation in
some parts of the community comes from Ubuntu and other distributions
having integrated it too early. Well, let me stress here explicitly,
that while they might have made a mistake or two in packaging
PulseAudio and I publicly pointed that out (and probably not in a too
friendly way), I do believe that the point in time they adopted it was
right. Why? Basically, it’s a chicken and egg problem. If it is not
used in the distributions it is not tested, and there is no pressure
to get fixed what then turns out to be broken: in PulseAudio itself,
and in both the layers on top and below of it. Don’t forget that
pushing a new layer into an existing stack will break a lot of
assumptions that the neighboring layers made. Doing this must
break things. Most Free Software projects could probably use more
developers, and that is particularly true for Audio on Linux. And
given that that is how it is, pushing the feature in at that point in
time was the right thing to do. Or in other words, if the features are
right, and things do work correctly as far as the limited test base
the developers control shows, then one day you need to push into the
distributions, even if this might break setups and software that
previously has not been tested, unless you want to stay stuck in your
development indefinitely. So yes, Ubuntu, I think you did well with
adopting PulseAudio when you did.


[1] Side note: yes, consumers tend not to know what dB is, and expect
volume settings in “percentages”, a mostly meaningless unit in
audio. This even spills into projects like VLC or Amarok which expose
linear volume controls (which is a really bad idea).

[2] In case you are wondering why that is the case: if the latency is
low the buffers must be sized smaller. And if the buffers are sized smaller
then the CPU will have to wake up more often to fill them up for the same
playback time. This drives up the CPU load since less actual payload can be
processed for the amount of housekeeping that the CPU has to do during each
buffer iteration. Also, frequent wake-ups make it impossible for the CPU to go
to deeper sleep states. Sleep states are the primary way for modern CPUs
to save power.