Generally, libavformat exports cover art pictures as video streams with
1 packet and AV_DISPOSITION_ATTACHED_PIC set. Only matroskadec exported
it as attachment with codec_id set to AV_CODEC_ID_MJPEG.
Obviously, this should be consistent, so change the Matroska demuxer to
export a AV_DISPOSITION_ATTACHED_PIC pseudo video stream.
Matroska muxing is probably incorrect too. I know that it can create
broken files with an audio track and just 1 video frame when e.g.
remuxing mp3 with APIC to mkv. But for now this commit does not change
anything about muxing, and also continues to write attachments with
AV_CODEC_ID_MJPEG should the muxer application have special knowledge
that the Matroska is broken in this way.
Fixes trac #4423.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Convert the Matroska stereo format to the Stereo3D format, and add a
Stereo3D side data to the stream.
Bump the doctype version supported.
Bug-Id: 728 / https://bugs.debian.org/757185
Removing the /EXPERIMENTAL suffix for codec id field for Opus. Doing this
as the implementation of embedding Opus in Matroska is complete.
Signed-Off By: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
WebM files now support inband text tracks, as described in the
following specification:
http://wiki.webmproject.org/webm-metadata/temporal-metadata/webvtt-in-webm
The Matroska demuxer now detects the presence of WebVTT tracks,
synthesizing WebVTT packets (having codec id AV_CODEC_ID_WEBVTT) and
pushing them downstream in the normal way.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Currently, we have a AV_CODEC_ID_SSA, which matches the way the ASS/SSA
markup is muxed in a standalone .ass/.ssa file. This means the AVPacket
data starts with a "Dialogue:" string, followed by a timing information
(start and end of the event as string) and a trailing CRLF after each
line. One packet can contain several lines. We'll refer to this layout
as "SSA" or "SSA lines".
In matroska, this markup is not stored as such: it has no "Dialogue:"
prefix, it contains a ReadOrder field, the timing information is not in
the payload, and it doesn't contain the trailing CRLF. See [1] for more
info. We'll refer to this layout as "ASS".
Since we have only one common codec for both formats, the matroska
demuxer is constructing an AVPacket following the "SSA lines" format.
This causes several problems, so it was decided to change this into
clean ASS packets.
Some insight about what is changed or unchanged in this commit:
CODECS
------
- the decoding process still writes "SSA lines" markup inside the ass
fields of the subtitles rectangles (sub->rects[n]->ass), which is
still the current common way of representing decoded subtitles
markup. It is meant to change later.
- new ASS codec id: AV_CODEC_ID_ASS (which is different from the
legacy AV_CODEC_ID_SSA)
- lavc/assdec: the "ass" decoder is renamed into "ssa" (instead of
"ass") for consistency with the codec id and allows to add a real
ass decoder. This ass decoder receives clean ASS lines (so it starts
with a ReadOrder, is followed by the Layer, etc). We make sure this
is decoded properly in a new ass-line rectangle of the decoded
subtitles (the ssa decoder OTOH is doing a simple straightforward
copy). Using the packet timing instead of data string makes sure the
ass-line now contains the appropriate timing.
- lavc/assenc: just like the ass decoder, the "ssa" encoder is renamed
into "ssa" (instead of "ass") for consistency with the codec id, and
allows to add a real "ass" encoder.
One important thing about this encoder is that it only supports one
ass rectangle: we could have put several dialogue events in the
AVPacket (separated by a \0 for instance) but this would have cause
trouble for the muxer which needs not only the start time, but also
the duration: typically, you have merged events with the same start
time (stored in the AVPacket->pts) but a different duration. At the
moment, only the matroska do the merge with the SSA-line codec.
We will need to make sure all the decoders in the future can't add
more than one rectangle (and only one Dialogue line in it
obviously).
FORMATS
-------
- lavf/assenc: the .ass/.ssa muxer can take both SSA and ASS packets.
In the case of ASS packets as input, it adds the timing based on the
AVPacket pts and duration, and mux it with "Dialogue:", trailing
CRLF, etc.
- lavf/assdec: unchanged; it currently still only outputs SSA-lines
packets.
- lavf/mkv: the demuxer can now output ASS packets without the need of
any "SSA-lines" reconstruction hack. It will become the default at
next libavformat bump, and the SSA support will be dropped from the
demuxer. The muxer can take ASS packets since it's muxed normally,
and still supports the old SSA packets. All the SSA support and
hacks in Matroska code will be dropped at next lavf bump.
[1]: http://www.matroska.org/technical/specs/subtitles/ssa.html
This reverts 312645e :
"Do not set codec_tag property for matroska muxers."
Also adds dummy codec_tag lists with codecs
supported in mkv but not in wav / avi.
Fixes ticket #2169.
The exact packing of Opus inside Matroska is not finalized.
Use A_OPUS/EXPERIMENTAL as codec name, like mkvtoolnix.
The A_OPUS name stays to let ffmpeg open files it has produced
until now, but newly produced file use the EXPERIMENTAL version.
Once the spec is stabilized it will be possible to consider
options to ensure compatibility with these files.
* commit '3f111804eb5c603a344706b84b7164cbf7b4e0df':
libvpx: make vp8 and vp9 selectable
libvpx: support vp9
nut: support vp9 tag
mkv: support vp9 tag
rtpdec: Make variables that should wrap unsigned
Conflicts:
configure
libavcodec/Makefile
libavcodec/allcodecs.c
libavcodec/avcodec.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '117d8c6d1f1c187ffc6098d9618457e00534e013':
matroska: implement support for ProRes
matroska: implement support for ALAC
Conflicts:
libavformat/matroskaenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Support Matroska native formatting.
On demuxing prepend a Frame container atom (32bit big endian encoded
frame size and 'icpf' string).
On muxing remove it.
While not explicitly stated in the specs, the original author
has stated that S_TEXT/UTF-8 is expected to be text using Subrip
markup, but without Subrip in-band timing.
So, now that we have a decoder that conforms to this expectation,
let's use it.
Note that this change will impact tools that use libavformat. If
they expect srt subtitles to have CODEC_ID_TEXT, they must be
adjusted to expect CODEC_ID_SUBRIP. The actual content is, obviously,
unchanged.
Signed-off-by: Philip Langdale <philipl@overt.org>
