The four jobs
Any media player, on any platform, does the same four things:
- Open the container — read the file's index, find where each stream starts.
- Demux — split the container into separate video, audio and subtitle streams.
- Decode — turn compressed packets into raw frames or PCM samples.
- Render — put frames on the screen and samples into the audio device, kept in time.
Android's built-in player does all four, but steps 1–3 are delegated to platform components. The platform supports a fixed list of containers and codecs, and it varies by device: a phone without an AC-3 licence simply cannot decode AC-3 in the platform. A player built only on the platform inherits those limits exactly.
What LibVLC brings
LibVLC is the playback core of VLC, packaged as a library. It contains its own demuxers, its own decoders and its own rendering paths — either using Android's hardware decoders when available or falling back to its own software decoders. Concretely:
- More containers: Matroska (MKV), MPEG-TS, Ogg, FLV, ASF and others that Android's framework does not know.
- More codecs: AV1, VP9, MPEG-2, Theora, older MPEG-4 variants — plus audio codecs like AC-3, E-AC-3, DTS and FLAC in every container.
- Consistent behaviour across devices: the same file behaves the same on a cheap phone and a flagship, because the engine is the same.
- Subtitle rendering for ASS/SSA with styling, which the platform does not provide.
Where hardware decoding fits
Software decoding everything would be simple and terrible for battery life. So a modern player asks the device to decode when it can: it checks whether the chipset has a decoder for the codec and profile, hands it the stream, and keeps LibVLC's software decoder as a fallback.
This is why the "hardware decoding" setting matters. Automatic lets the player try the hardware path first; software forces the fallback, which fixes artefacts and incompatibilities at the cost of CPU. The engine does not care which path is used — it outputs the same frames either way.
Why "the engine" is not a magic wand
LibVLC plays virtually any format, but it cannot make an underpowered device decode 4K 10-bit HEVC in real time. It also cannot fix a corrupt file, and it does not remove DRM. What it changes is the shape of the failure mode: instead of "unsupported format", you get playback — possibly with software decoding and higher battery use.
What an application layer adds
The engine is only the bottom half. A usable player also needs a library that finds files, a queue, resume positions, gesture handling, subtitles loading, a foreground service for background audio, and a notification. PurePlay's application layer is written from scratch rather than inherited from VLC's Android app — which is why the interface is small and consistent, while the playback engine is the same mature one.
How to judge a player that claims VLC support
- Does it name the version of LibVLC it bundles?
- Does it expose hardware/software decoding, or silently fail on some files?
- Can it load external subtitles, not only embedded ones?
- Does it handle audio-only playback (background, lock screen) as well as video?
- Does it work offline without an account?
The short version
Android's platform player is fast and battery-friendly but limited by what each device was licensed to decode. LibVLC is a complete playback stack that fills those gaps. A good Android player combines the two: hardware decoding when the device can, the engine's own decoders when it cannot — with an interface that stays out of the way.