* commit '1509c018bd5b054a2354e20021ccbac9c934d213':
mpegts: relax restrictions on matching the packet start in read_header
Conflicts:
libavformat/mpegts.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
analyze() is currently called both when probing and from read_header().
It determines the packet start by looking for the sync byte, followed by
unset Transport Error Indicator and valid adaptation_field_control.
This makes sense to do when probing, but once we already know the format
is MPEG-TS, it is counterproductive to be so strict -- e.g. in some
files the TEI might be set and analyze() might get called with a smaller
buffer than the one used for probing, resulting in a failure.
Avid prefers mpeg range [16-235] by default this change brings
ffmpeg into line with that. To obtain the old behaviour use
'-color_range jpeg' on the command line prior to the ouput
filename.
Signed-off-by: Kevin Wheatley <kevin.j.wheatley@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Matroska is an extensible format - unknown elements must be expected. It
shouldn't complain about such elements to the user either; it'll just
generate noise. The "error_recognition & AV_EF_EXPLODE" is completely,
wrong why would it explode on valid files?
It's still useful for debugging, so the message is left in place with a
higher log level.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Nothing uses it, and it provides no public API.
Archeological finds:
Commit 101036adb9 added the API.
Commit a8dd8dc6e9 made mpegts.c use it.
Commit af8aae3fa3 disabled it by default in mpegts.c.
Commit ae2bb52cd2 removed all uses of this from mpegts.c.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Reviewed-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Reviewed-by: Carl Eugen Hoyos <cehoyos@ag.or.at>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
ff_avc_write_annexb_extradata() allocates extradata, but don't add
FF_INPUT_BUFFER_PADDING_SIZE value
Signed-off-by: Lukasz Marek <lukasz.m.luki2@gmail.com>
This could overflow and crash at least on 32 bit systems.
Reviewed-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This can lead to an endless loop by seeking back a few bytes after each
attempted chunk read. Assuming negative sizes are always invalid, this
is easy to fix. Other code in this demuxer treats negative sizes as
invalid as well.
Fixes ticket #4262.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e3528d2a7bf29ba148d7ac1678552ce0089cd14f':
mov: Implement parsing of the "HandlerName" from the MP4 HDLR atom
Conflicts:
libavformat/mov.c
See: b76bc01034
Merged-by: Michael Niedermayer <michaelni@gmx.at>
industrial cameras usually mark the trigger frame as frame number 0
all frames saved before trigger frame receive a negative sequence number
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This atom typically is used for a track title. The handler name is stored
as a Pascal string in the QT specs (first byte is the length of the string),
so do not export it.
A second length check based on the first character is added to avoid
overwriting an already specified handler_name (it happens with YouTube
videos for instance, the handler_name get masked), or specifying an
empty string metadata.
The Pascal string fix and the second length check are written
by Clément Bœsch <clement.boesch@smartjog.com>.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
av_add_index_entry() can fail, for example because the parameters are
invalid, or because memory allocation fails. Check this; it can actually
happen with corrupted files.
The second hunk is just for robustness. Just in case functions like
ff_reduce_index() remove entries. (Not sure if this can actually
happen.)
Fixes ticket #4294.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This adds an option to set the service type in mpegts as defined in ETSI 300 468.
I added what I believe are the most useful service types as pre defined values,
the others can be sent by using their hexdecimal form directly (e.g. -mpegts_service_type digital_radio, -mpegts_service_type 0x07).
I've been using this patch in order to pipe internet radio stream (originally as HLS/m3u8) from ffmpeg to tvheadend,
when the service type set right tvheadend recognize the mpegts stream as a radio channel.
The patch in its original form was written by linuxstb from freenode's hts channel which allowed me pushing it upstream.
This close issue 4118.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'f726fc21ef76a8ba3445448066f7b2a687fbca16':
ogg: Provide an option to offset the serial number
Conflicts:
libavformat/oggenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '3c18a7b18807de81566381a1bcbe9f6103c0296b':
avio: Do not consider the end-of-buffer position valid
Conflicts:
libavformat/aviobuf.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Trigger a refill if the seek action moves the pointer
at the end of the buffer.
Before this patch the read action following the seek would trigger
the refill, while write action would write outside the buffer.
In the Libav codebase few muxers seek forward outside of what
already has been written so it is quite unlikely to experience
the problem with the default buffer size.
CC: libav-stable@libav.org
* commit '4227e4fe7443733fb906f6fb6c265105e8269c74':
lavf: add a convenience function for adding side data to a stream
Conflicts:
libavformat/internal.h
libavformat/replaygain.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '80a11de7dca315505bf203ce9c8c016e71724fd2':
nutenc: do not use has_b_frames
Conflicts:
libavformat/nutenc.c
tests/ref/lavf/nut
tests/ref/seek/lavf-nut
Mostly not merged, this is simply not correct
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'f771b3ab5d3c0b763ee356152be550f4121babd0':
avidec: do not export stream_codec_tag
Conflicts:
libavformat/avidec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The frames are said to contain a higher bit-depth but
users report that our decoder shows visually correct output.
Requested by forum user gregba and Christoph Gerstbauer.
* commit '7915e6741dbe1cf3a8781cead3e68a7666de14f4':
hlsproto: Properly close avio buffer in case of error
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This partially reverts cf70ba37ba, since
it didn't take into account when rotation is 0, but there is another
valid operation (eg. translation) in the matrix.
Found-by: Michael Niedermayer <michaelni@gmx.at>
When the timecode value is in counter mode then it is important to use
the timescale and frameduration to calculate the timecode fps.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '9108967513fcaff3d55514a7bca4c9fbba128c71':
rtspdec: Consistently use rtsp_hd_out for writing
Merged-by: Michael Niedermayer <michaelni@gmx.at>
In addition to .h264, .264 is also commonly used by people to name raw H.264
streams. Enables automatic recognition of the h264 format for the .264
extension.
Signed-off-by: Werner Robitza <werner.robitza@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '3a724a7f3ba7fa766c6a6f0924a15cc742031b8d':
dashenc: Use inttypes.h macros for format strings instead of %lld
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This goto wasn't necessary originally, but it should have been
added when the write_manifest call was added in 8e276378.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '024e5a2d5ff8a94adce48abb15ce2fb471f9d18e':
rtmppkt: Repeat the full 32 bit timestamp for chunking continuation packets
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '932788be5af8dee062c77851b573ea47dd6d047a':
id3v2: add names to the parameters of ID3v2EMFunc.read
Conflicts:
libavformat/id3v2.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '8809c974a3fb51f96e498a5556a4a5bbacc581ce':
id3v2: constify the 'tag' parameter to special metadata parsing callback
Conflicts:
libavformat/id3v2.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This fixes sending chunked packets (packets larger than the output
chunk size, which often can be e.g. 4096 bytes) with a timestamp delta
(or absolute timstamp, if it's a timestamp step backwards, or the
first packet of the stream) larger than 0xffffffff.
The RTMP spec explicitly says (in section 5.3.1.3.) that packets of
type 3 (continuation packets) should include this field, if the
previous non-continuation packet had it included.
The receiving code handles these packets correctly.
Pointed out by Cheolho Park.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
The original code was intended purely for rotation == 0
In cf70ba37ba the condition was
changed to use it only for rotation != 0
which broke the cases for which it was intended to be used
as well as breaking cases for which it was not intended to be
used.
This changes the code so it could work for the more general
case and fixes the regressions
If you have sample files that are not handled correctly
please open tickets or mail me!
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'cf70ba37ba74089a18295b29e77dead0a3222c9e':
mov: Check angle rather than full matrix when updating SAR
Merged-by: Michael Niedermayer <michaelni@gmx.at>
When the display matrix is not the identity one, but the rotation angle
is zero, there is no need to update the sample aspect ratio.
Otherwise, it is possible to obtain negative values which interferes
with transcoding in later stages. This kind of behaviour is reproducible
on mov files with "major_brand: MSNV".
CC: libav-stable@libav.org
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
