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
Patch by Ronald S. Bultje rsbultje gmail com
Original thread: [FFmpeg-devel] [PATCH] Realmedia / RTSP (RDT)
Date: 12/28/2007 10:19 PM
Originally committed as revision 11392 to svn://svn.ffmpeg.org/ffmpeg/trunk