This broke packed_maindata.mp3.mp4
Its unknown to me what this commit would have fixed
Reviewed-by: James Almer <jamrial@gmail.com>
This reverts commit 79127dbbeffa87243c92af2befc09ad63bcbd1a1, reversing
changes made to 9fad1ce7c95adeec440f51af77f730340a6d27b8.
* commit '0d1229f1d2b8f26dd50c6be7917bb8ed8cb95364':
voc: Split ff_voc_get_packet into a separate file
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit 'b92962436bdcfae478c8598dca397a397762eef8':
mov: Fix the format specifier type for size
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This allows to copy information related to the stream ID from the demuxer
to the muxer, thus allowing for example to retain information related to
synchronous and asynchronous KLV data packets. This information is used
in the muxer when remuxing to distinguish the two kind of packets (if the
information is lacking, data packets are considered synchronous).
The fate reference changes are due to the use of
av_packet_merge_side_data(), which increases the size of the output
packet size, since side data is merged into the packet data.
Currently, AVStream contains an embedded AVCodecContext instance, which
is used by demuxers to export stream parameters to the caller and by
muxers to receive stream parameters from the caller. It is also used
internally as the codec context that is passed to parsers.
In addition, it is also widely used by the callers as the decoding (when
demuxer) or encoding (when muxing) context, though this has been
officially discouraged since Libav 11.
There are multiple important problems with this approach:
- the fields in AVCodecContext are in general one of
* stream parameters
* codec options
* codec state
However, it's not clear which ones are which. It is consequently
unclear which fields are a demuxer allowed to set or a muxer allowed to
read. This leads to erratic behaviour depending on whether decoding or
encoding is being performed or not (and whether it uses the AVStream
embedded codec context).
- various synchronization issues arising from the fact that the same
context is used by several different APIs (muxers/demuxers,
parsers, bitstream filters and encoders/decoders) simultaneously, with
there being no clear rules for who can modify what and the different
processes being typically delayed with respect to each other.
- avformat_find_stream_info() making it necessary to support opening
and closing a single codec context multiple times, thus
complicating the semantics of freeing various allocated objects in the
codec context.
Those problems are resolved by replacing the AVStream embedded codec
context with a newly added AVCodecParameters instance, which stores only
the stream parameters exported by the demuxers or read by the muxers.
Instead of a linked list constructed at av_register_all(), store them
in a constant array of pointers.
Since no registration is necessary now, this removes some global state
from lavf. This will also allow the urlprotocol layer caller to limit
the available protocols in a simple and flexible way in the following
commits.
Improves streaming compatibility with Windows Media Services. Also tested for
compatilbility in Windows Media Player, Windows Media ASF Viewer and VLC.
This version of the patch only writes exclusion among audio streams, therefore
choosing a subtitle language should be possible independently of audio language.
Signed-off-by: Marton Balint <cus@passwd.hu>
I discovered that ffserver streaming was broken (it seems like it has been since 20th November) and I opened a ticket for this (https://trac.ffmpeg.org/ticket/5250 <https://trac.ffmpeg.org/ticket/5250>).
I spent yesterday learning git bisect (with the kind help of cehoyos) to painstakingly track down the cause. This was made more difficult due to the presence of a segfault in ffserver during the period where the bug was introduced so I first had to identify when and how that was fixed and then retrospectively apply that fix again for each step of the second git bisect to find the actual bug.
Anyway, the fruits of my labour are the innocent looking patch below to correct a couple of typos and define a valid range for two variables.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fix cases where unknown data (data beyond p->buf_size) could produce a
higher ico probe score than if the unknown data was known and valid.
For example:
Header: OK, 2 frames
Frame 0: Unknown (offset points beyond end of probe buffer)
Frame 1: Invalid
Previously this example had a score of 25, even though the score would
be 1 if the unknown frame was known to be valid or 0 if it was known
to be invalid. For this example the score is now 1.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some muxer might or might not fit incomplete mp3 frames in
their packets.
Bug-Id: 899
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This can be made more efficient, but first and the main goal of this change is to
store it at all
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
