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.

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

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

This set of "helpers" is only used by the libmpeg2 plugin, and was not
exposed to out-of-tree-plugins. There is apparently no point keeping it
inside the core.

VLC needs a list of errors as multiple errors can occur at the
same time.
This revives the existing error panel from
e3f2ec3e.

refs #17262

It does not make sense anymore

Filip Roséen authored 8 years ago and Jean-Baptiste Kempf committed 8 years ago

zip extraction is now handled by the libarchive based
modules/stream_extractor/archive.c, as such these files/modules are no
longer needed.

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

Filip Roséen authored 8 years ago and Jean-Baptiste Kempf committed 8 years ago

Archive extraction is now handled by the libarchive based
modules/stream_extractor/archive.c, as such these files/modules are no
longer needed.

Filip Roséen authored 8 years ago and Jean-Baptiste Kempf committed 8 years ago

rar extraction is now handled by the libarchive based
modules/stream_extractor/archive.c, as such these files/modules are no
longer needed.

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

Filip Roséen authored 8 years ago and Jean-Baptiste Kempf committed 8 years ago

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