There does not appear to be any real user. The "broadcast"
functionality can be reproduced more simply with the LibVLC media
player API. The "VoD" functionality does not make much sense outside of
the VLC executable process.

Please write a new one in Rust!

Move to 21st century!

This better matches the naming scheme, as WindowController is typically
used to have one designated window which is controlled.

Most of the code is still the same.

Removes the long unused Winamp/SHOUTcast directory stream filter for
playlist handling, which was mostly useful together with the service
discovery (modules/services_discovery/shout.c) which is not present
anymore.

Too many #ifdef's, not to mention different effective license.

Replaced by the faster i420_nv12 filter.

This is superseded by the compat tdestroy() replacement, which is also
available outside of libvlccore.

Because caca is the future.

Not built and tested since a long time. The good way to go is to use the
openGLES2 vout.

Steve Lhomme authored 7 years ago and Jean-Baptiste Kempf committed 7 years ago

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Steve Lhomme authored 7 years ago and Jean-Baptiste Kempf committed 7 years ago

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Victorien Le Couviour--Tuffet authored 7 years ago and Thomas Guillem committed 7 years ago

Signed-off-by: Thomas Guillem <thomas@gllm.fr>

The GL/GLES2 plugins doesn't depends anymore on X11, WAYLAND, VAAPI or other
hardware libs.

Move all converters (that were built in GL plugins) in separate plugins, with a
"glconv" plugin capability. This new type of module will be loaded by GL
plugins when a video format is opaque. Otherwise, the built-in software
converter (that handle RGB,YUV,YXZ12) will be used.

Each new converters plugins depends only on hardware libs like VAAPI-X11,
VAAPI-WL. These news plugins don't depend on Open GL / GLES2. Therefore, one
glconv plugin can be used by a GL and a GLES2 plugin.

Fixes #18575

Thomas Guillem authored 7 years ago and Hugo Beauzée-Luyssen committed 7 years ago

Signed-off-by: Hugo Beauzée-Luyssen <hugo@beauzee.fr>

The SDL video output has been forcefully disabled on MacOS X for 12
years. It has also been disabled in Windows builds for over 6 years.
Finally, it has been broken on X11 due to lack of windowing
integration, for several years, cannot be fixed without changes to
the SDL API, and is completely useless.

The DirectFB project has been dead for several years, and is ostensibly
not used. If you really need direct access to the Linux frame buffer,
there is still the raw LinuxFB module for the time being.

As most demuxers cannot handle tags at the beginning of their input
streams, the demuxer code has automatically skipped them for a long
time.

Unfortunately, a number of demuxers also assume that the initial stream
byte offset is zero (while some others seem to assume zero in some paths
and not in others). This seems like a reasonable assumption. And even if
it were not, fixing all affected stream filters and demuxers to perform
only relative seeking seems impractical and unpalatable.

This stream filter shifts the stream byte offset so that the tags are
entirely invisible, and the demuxer can assume the start is at offset 0.

Of couse, the tags must still be accessible to the meta extraction
engine(s). The TagLib plugin uses "low-level" vlc_access_NewMRL() so it
is not subject to stream filters, and not affected by this change.
(This change does however remove tags from "demuxdump".)

NOTE: On the one hand, this also enables demuxing a file format with
embedded absolute file offsets, if the tags were prepended after muxing.
On the other hand, it conversely breaks demuxing such a file format if
the tags are added during muxing. As far as I know, tags are normally
appended rather than prepended to avoid this ambiguity.