In the name of consistency:
get_byte -> avio_r8
get_<type> -> avio_r<type>
get_buffer -> avio_read
get_partial_buffer will be made private later
get_strz is left out becase I want to change it later to return
something useful.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
(cherry picked from commit b7effd4e83)
In the name of consistency:
get_byte -> avio_r8
get_<type> -> avio_r<type>
get_buffer -> avio_read
get_partial_buffer will be made private later
get_strz is left out becase I want to change it later to return
something useful.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This also lists the objects from those two libraries as internal (by adding
the ff_ prefix) so that they can then be hidden via linker scripts.
(cherry picked from commit c6610a216e)
in its place.
av_metadata_set() is going to be dropped at the next major bump.
Originally committed as revision 22961 to svn://svn.ffmpeg.org/ffmpeg/trunk
AVERROR(ENOMEM).
AVERROR_NOMEM is deprecated and will be dropped at the next libavutil
major bump.
Originally committed as revision 22791 to svn://svn.ffmpeg.org/ffmpeg/trunk
word, so treat it this way instead of extracting different parts from 32-bit
value.
Originally committed as revision 20820 to svn://svn.ffmpeg.org/ffmpeg/trunk
instead of many strcmp() on always four-byte strings.
Idea borrowed from RM demuxer in FFmbc by Baptiste Coudurier.
Originally committed as revision 20819 to svn://svn.ffmpeg.org/ffmpeg/trunk
This avoids a crash when the next slice is not a start slice and thus
pkt->data is still NULL.
This probably only happens with broken or unsupported files like
http://samples.mplayerhq.hu/real/multirate/JustaSpa1937_64kb.rm
that need further fixes, but keeping vst state consistent is still a good idea.
Originally committed as revision 19830 to svn://svn.ffmpeg.org/ffmpeg/trunk
used to return packet data, which might update the flags/timestamp to be
used for the next packet data returned by the demuxer. However, that was
separated out into a new function, and the flags/timestamp are thus never
updated within ff_rm_parse_packet() anymore, and thus do not need to be
a pointer.
Originally committed as revision 19539 to svn://svn.ffmpeg.org/ffmpeg/trunk
Has been tested against streamed / non-seekable input and passes make
seektest. See "[PATCH] rmdec.c: parse INDX chunk" thread on mailinglist.
Originally committed as revision 18013 to svn://svn.ffmpeg.org/ffmpeg/trunk
as requested by Kostya). See "[PATCH] rmdec.c: remove cache access
duplication".
Originally committed as revision 18010 to svn://svn.ffmpeg.org/ffmpeg/trunk
cache, since this can already be accessed through ff_rm_retrieve_cache().
See "[PATCH] rmdec.c: remove cache access duplication" thread.
Originally committed as revision 18009 to svn://svn.ffmpeg.org/ffmpeg/trunk
the newer (.rm, audio/video) files. See "[PATCH] rmdec.c: merge old/new
packet reading code" thread on mailinglist.
Originally committed as revision 18005 to svn://svn.ffmpeg.org/ffmpeg/trunk
discussion in the ML thread "[PATCH] rmdec.c: merge old/new packet reading
code".
Over time, this code broke somewhat, e.g. seq was never actually written
into (and was thus always 1, therefore the seq condition was always true),
whereas it was supposed to be set to the sequence number of the video slice
in case the video frame is divided over multiple RM packets (slices). The
problem of this is that packets other than those containing the beginning
of a video frame would be indexed as well.
Secondly, flags&2 is supposed to be true for video keyframes and for these
audio packets containing the start of a block. For some codecs (e.g. AAC),
that is every single packet, whereas for others (e.g. cook), that is the
packet containing the first of a series of scrambled packets that are to be
descrambled together. Indexing any of the following would lead to incomplete
and thus useless frames. Problem here is that flags would be reset to 2 to
indicate that the first packet is ready to be returned, and in addition if
no data was left to be returned (which is always true for the first packet),
then we wouldn't actually write the index entry anyway.
All in all, the idea was good and it probably worked at some point, but that
is long ago. This patch should at the very least make it likely for this code
to be executed again at the right times, i.e. the way it was originally
intended to be used.
Originally committed as revision 17993 to svn://svn.ffmpeg.org/ffmpeg/trunk
and if the size is broken (20 bytes, header-only), calculate the expected
size and skip the index entries anyway. See "[PATCH] rmdec.c: correctly
skip indexes" thread.
Originally committed as revision 17924 to svn://svn.ffmpeg.org/ffmpeg/trunk
has two possible outcomes: either len and rm->remaining_len are the same, in
which case we care about the outcome and it is zero, or rm->remaining_len is
currently not in use and we don't care about the outcome. In that case, len
is positive and rm->remaining_len is zero, which leads to a negative result.
This is confusing and could eventually lead to a sign-flip if we skip a lot
of packets (unlikely, but still). Therefore, just always set it to zero.
Originally committed as revision 17919 to svn://svn.ffmpeg.org/ffmpeg/trunk
has two possible outcomes: either len and rm->remaining_len are the same, in
which case we care about the outcome and it is zero, or rm->remaining_len is
currently not in use and we don't care about the outcome. In that case, len
is positive and rm->remaining_len is zero, which leads to a negative result.
This is confusing and could eventually lead to a sign-flip if we skip a lot
of packets (unlikely, but still). Therefore, just always set it to zero.
Originally committed as revision 17910 to svn://svn.ffmpeg.org/ffmpeg/trunk
ff_rm_parse_packet(). See "[PATCH] Make RM demuxer behave better with -an
option" thread, which sort-of turned into an aggregate of unrelated rmdec.c
cleanups.
Originally committed as revision 17909 to svn://svn.ffmpeg.org/ffmpeg/trunk
rm->audio_pkt_cnt in case multiple packets should be read before the next
syncpoint in the file, so that ffplay -an on a file containing AAC audio
works. See "[PATCH] Make RM demuxer behave better with -an option" thread
on mailinglist.
Originally committed as revision 17908 to svn://svn.ffmpeg.org/ffmpeg/trunk
libavformat/rmdec.c:550: warning: assignment makes pointer from integer
Patch by Dominique Leuenberger (dominique-ffmpeg-devel A leuenberger D net)
Originally committed as revision 16489 to svn://svn.ffmpeg.org/ffmpeg/trunk
the (larger) allocated size. (prevents segfaults due to later failures
from 900MB-sized packets, yes fuzzed file not a valid one)
Originally committed as revision 16404 to svn://svn.ffmpeg.org/ffmpeg/trunk
of allocated slices matches the actual.
Audio still does a copy (marked with FIXME in the code so this is not missed).
Originally committed as revision 16402 to svn://svn.ffmpeg.org/ffmpeg/trunk
"rmdec.c: double free" discussion on mailinglist, patch with suggestions
from Reimar Doffinger.
Originally committed as revision 16378 to svn://svn.ffmpeg.org/ffmpeg/trunk
AVStreams can be used to call these public rmdec.c functions as well, as is
the case for RDT/RTSP streams. See mailinglist discussion in "[PATCH] rdt.c:
don't reuse the same AVStream in both RTSP and RM demuxer" thread.
Originally committed as revision 16366 to svn://svn.ffmpeg.org/ffmpeg/trunk
This allows multiple video or audio streams per .rm file. See mailinglist
thread "[PATCH] rmdec.c: implement RMVideo/AudioStream".
Originally committed as revision 16365 to svn://svn.ffmpeg.org/ffmpeg/trunk
"[PATCH] rmdec.c: use get_buffer and skip_bytes instead of loops of get_byte".
Originally committed as revision 16139 to svn://svn.ffmpeg.org/ffmpeg/trunk
Reason for this is that there are no shared entries in the demuxer/muxer
context, making it a mystery as to why it was shared between the two. See
"[PATCH] clean rmdemux/muxcontext" patch on mailinglist.
Originally committed as revision 16111 to svn://svn.ffmpeg.org/ffmpeg/trunk
ff_rm_parse_packet() to indicate whether more audio packets are available
in the demuxer from the last RM frame, and save that in the RDT parsing
context. See patch/discussion in "[PATCH] rdt.c: don't access RMContext"
on ML.
Originally committed as revision 16110 to svn://svn.ffmpeg.org/ffmpeg/trunk
specify the data source as function argument instead of in s->pb before
calling the function. Discussed in ML thread "[PATCH] fix small memleak
in rdt.c".
Originally committed as revision 15849 to svn://svn.ffmpeg.org/ffmpeg/trunk
in rtpdec.c, so that they can be shared and used in the same way in rtsp.c.
The handlers, since they are specific for RDT, are registered in rdt.c and
a new registration function is thus called from allformats.c.
The dynamic payload handler also implements RDT-specific SDP-line parsing for
OpaqueData and StartTime, which are specific for RDT and needed for proper
playback. OpaqueData contains one or a list ("MLTI") of "MDPR" chunks that
can be parsed by the rmdec.c function ff_rm_read_mdpr_codecdata(). To use
this function, we create a new rdt_demuxer, which has the same private data
as the rm_demuxer. The resulting AVFormatContext created with _open_stream()
can thus be used to call functions in the RM demuxer.
See discussion in "Realmedia patch" thread on ML.
Originally committed as revision 15234 to svn://svn.ffmpeg.org/ffmpeg/trunk
shared between the RM demuxer and the RTSP/RDT parser; both use the same
timebase. See discussion in "[PATCH] rmdec.c: move av_set_pts_info()" on ML.
Originally committed as revision 15164 to svn://svn.ffmpeg.org/ffmpeg/trunk
function itself. This way, old-style (.ra4) RTSP/RDT OpaqueData chunks can
be parsed using this function as well (they don't have the size bits). See
discussion on ML in "[PATCH] rmdec.c - small read_mdpr_codecdata() API
modification".
Originally committed as revision 15163 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Stefano Sabatini, stefano.sabatini-lala poste.it
along with some spelling/consistency fixes for the long names by me
Originally committed as revision 13649 to svn://svn.ffmpeg.org/ffmpeg/trunk
