[FFmpeg-devel] Realmedia patch

[Luca Abeni]

Hi Ronald,

Ronald S. Bultje wrote:
[...]
>> (BTW, I partly missed the previous threads about realmedia...
>> Can you please forward me the relevant emails, or send me
>> links to the ml archives, and point me to a "more split"
>> patchqueue?)
> 
> That doesn't really exist, I'm very old-fashioned and don't use
> anything like git or so. I just use quilt, which is basically an
> elegant diff-script.

quilt is ok; I sometimes use it too... Just point me to a quilt
patchqueue (I assume you posted a split patchqueue in the past,
and something from it has been committed. So, just let me know
where I can find the updated patches).

> Previous threads (google my name and rtsp):
> 
> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-July/033095.html
> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-December/039697.html

Ok, good; I am going to read them. Maybe they'll answer some of
my questions ;-)

[...]
>>>>> +                stream = av_new_stream (s, 0);
>>>>> +                stream->codec->codec_type = orig_stream->codec->codec_type;
>>>> missing stream != NULL check
>>>> besides, this stream creation in parse_sdp_a_line() is something that
>>>> should be commented by one of the lucas. I do not feel confident enough
>>>> that this is the correct approuch ...
>> I also had some doubts about this when looking at the patch (and the need
>> for changing the parse_sdp_a_line() prototype looks suspect too...).
>> Can you post an example SDP for which this code is needed? And a link to
>> some documentation about it?
>> Also, is this code needed for processing a session-level "a=" line, or
>> is it a media-level SDP line?
>> In the second case, I think this is the wrong approach.
> 
> It's session-level

Actually, according to the SDP you posted the OpaqueData, RMFF, and
ASMRuleBook tags seem to be media-level (they come after the "m=" line).
So, I think that the parse_sdp_a_line() function in this case should only
work on a single stream. Anyway, if Michael asked to create an AVStream
per possible configuration, I agree that changing the function's prototype
is the only solution.


> I never found any documentation except for the
> librtsp (LGPL) implementation. Here's the SDP of my test-stream (from
> debugging enabled in sdp_parse_line()), some are real-specific and
> Michael earlier asked for the Real-specific lines to be in rtp_rm.c,
> hence the parse_sdp_a_line() forward. The reason I changed the
> prototype is because the RTSPStream only points to 1 AVStream, which
> this way I have the AVFormatContext and can thus add more AVStreams
> depending on the amount of stream-rules

Yes, I understand this. When I posted my comment I did not know that
you have been asked to create a new AVStream for each stream-rule.

[...]
>> Uhmm... Wouldn't it be possible to have only one AVStream per "m="
>> line, and to add something like an "available_bitrates" array (or
>> similar) to RTSPStream?
>> (I believe that in theory a new AVStream should be created only when
>> processing an "m=" line)
> 
> That's the previous approach, yes. Michael said he'd prefer to have 1
> AVStream per rule, so that the AVStream/CodecContext is filled in and
> we can decide on which stream to select from by using AVStream.discard
> (see ffplay).

Ok; this explains the code... I did not know about this requirement.

[...]
> - if you add a avail-bitrates array, you can only select based on
> bitrates, which isn't very extendible

Ok. I imagined that the possible differences between different
stream configurations were only in the bitrate.

> - the SDP header contains the RM header

That's ok... Is it a "standard" RM header (that can be found also in
"regular" RM files), or a modified version?
Can it be copied in the codec's extradata?

> with which I can give codec
> information per stream-rule (not just bitrate, but CodecID,
> stereo/mono, etc. - it could even help if new codecs arise and we
> don't support all of them, we could skip those based on this
> information, while we may accidently select those if we select just
> based on bitrates)

Sorry, but here I am a little bit confused... I assume the RM header
is somehow encoded in the "OpaqueData" field, right? Does this field
contain a single RM header, or multiple RM headers (one per stream-rule)?
In the first case, wouldn't it be possible to just copy the header in
some buffer, and let the RM demuxer handle it later?

Maybe I am just confused, but it seems to me that the rdt_parse_sdp_line()
function is trying to do something that should be done in the RM demuxer...

> - AVStream.discard was the intended API for stream selection, so this
> approach fits the intended lavf-API

If there actually are N different streams, I agree with this.
My impression was that there is a single stream with N different possible
configurations.


Anyway, I am going to read the previous threads, hoping to get a better
understanding of this RM stuff so that I can provide some real help...



			Thanks,
				Luca