Use the UTF-16 BOM to detect UTF-16 encoding. Convert the file contents
to UTF-8 on the fly using FFTextReader, which acts as converting wrapper
around AVIOContext. It also can work on a static buffer, needed for
format probing. The FFTextReader wrapper now also takes care of skipping
the UTF-8 BOM.
Fix Ticket #3496.
The read_packet callback passes a pointer to a stack-allocated AVPacket.
Attempting to free it with av_free() makes no sense.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The most interesting parts are initialization in ff_MPV_common_init() and
uninitialization in ff_MPV_common_end().
ff_mpeg_unref_picture and ff_thread_release_buffer have additional NULL
checks for Picture.f, because these functions can be called on
uninitialized or partially initialized Pictures.
NULL pointer checks are added to ff_thread_release_buffer() stub function.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The memory allocation for f->diffs was freed multiple times in some
corner cases. Simplify the code so that this doesn't happen.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The authstr memory allocations make it annoying to error in the middle
of the header setup code, so apply the usual C error handling idiom to
make it easier to error at any point.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If a domain has some cookies set, but matching the cookie fails due to
the port being different, get_cookies() succeeds, but sets cookies to
NULL. The caller of get_cookies() didn't check for the NULL value.
This also avoids passing NULL to libc string functions, which is
undefined behavior
Fixes Ticket2180
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This gets rid of aliasing completely unrelated structs to Picture.
Fixes the remaining compilation warnings in the vdpau code.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The code passed H264Picture* and Picture*, and assumed the
hwaccel_picture_private field was in the same place in both
structs. Somehow this happened to work in Libav, but broke in
FFmpeg (and probably subtly breaks in Libav too).
Signed-off-by: Anton Khirnov <anton@khirnov.net>
mp4 files embedding DVD subtitles do not use the same extradata format
as the rest of Libav expects. The subtitle decoder in libavcodec in
particular does not understand this format.
Convert the extradata to the vobsub .idx format. mp4 stores the palette
as binary 32 bit ints in YUV. The subtitle resolution is stored
separately in the track header, which we access through AVStream.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Some http servers send an ICY stream in combination with chunked
transfer encoding. This case was handled incorrectly by the ICY code:
instead of handling chunked encoding before anything ICY related, both
were mixed.
Fix this by separating the ICY code from normal http reading. Move the
normal http reading to a new function http_read_stream(), while
http_read() handles ICY on top of http_read_stream().
The server identified itself as: cloudflare-nginx
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
MicroDVD files are normally frame-based (i.e. there are no absolute
timestamps), but can have an optional frame rate header. If this
header is missing, the timestamps depend on the frame rate of the
video they were created for.
The demuxer will use a fallback frame rate if it's missing from the
header. Currently, applications using libavformat can't know whether
the time base is based on the fallback value, or if a frame rate
header was present.
This commit introduces a subfps AVOption for MicroDVD, and the
demuxer sets it if and only if a frame rate header was present.
Signed-off-by: Clément Bœsch <u@pkh.me>
The BOM is already skipped in the probe function, but not the header
read function. This could cause the header to be misparsed, such as
not interpreting the FPS line.
This is useful for debugging.
Reference and ffprobe.xsd changes done and tested by Stefano Sabatini.
Signed-off-by: Stefano Sabatini <stefasab@gmail.com>
These streams are reported as seekable, but all tests show they are not,
and the server merely pretends the streams are seekable. The server
responds with:
content-range: bytes 0-1999999999/2000000000
Range requests seem to be correctly answered, but the actual data
returned at the same offset is different. Assume this is a bug in the
server software. The server identifies itself as:
Server: MediaGateway 3.5.2-001
Add a hack that checks the server name, and disables seeking in this
case.
Test URL: http://8283.live.streamtheworld.com:80/CBC_R1_VCR_H_SC
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Before this commit, sws_init_context() failed with an error if no scaler
was explicitly set.
Defaulting to something reasonable is better behavior.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Skip the "\r" as normal text. Otherwise it will be the first character
of the string passed to sscanf(), which then fill fail to match the
timestamps.
Signed-off-by: Clément Bœsch <u@pkh.me>
There is no reason why this should copy the audio data in a very
complicated way. Also, strictly write the first plane, instead of
writing the whole buffer. This is more helpful in context of the
example. This way a user can clearly confirm that it works by playing
the written data as raw audio.
This assumes one audio packet is decoded one time. This is not true:
packets can be partially decoded. Then you have to "adjust" the packet
and pass the undecoded part of the packet to the decode function again.
Allow applications to request reading streamcast metadata. This uses
AVOptions as API, and requires the application to explicitly request
and read metadata. Metadata can be updated mid-stream; if an
application is interested in that, it has to poll for the data by
reading the "icy_metadata_packet" option in regular intervals.
There doesn't seem to be a nice way to transfer the metadata in a nicer
way. Converting the metadata to ID3v2 tags might be a nice idea, but
the libavformat mp3 demuxer doesn't seem to read these tags mid-stream,
and even then we couldn't guarantee that tags are not inserted in the
middle of mp3 packet data.
This commit provides the minimum to enable applications to retrieve
this information at all.
Signed-off-by: Stefano Sabatini <stefasab@gmail.com>
This is part of normal operation with some formats. A warning should
indicate that something is wrong, and the documentation for AV_LOG_WARNING
says: "Something somehow does not look correct."
Since this message is most likely useful for debugging only, raise the
log level accordingly.
Plus-one-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
wm4andClément Bœsch
