[FFmpeg-devel] Realmedia patch
Ronald S. Bultje
Sun Aug 31 23:06:56 CEST 2008
On Sun, Aug 31, 2008 at 3:46 PM, Luca Abeni <lucabe72 at email.it> wrote:
> Ronald S. Bultje wrote:
>>>> I'll first try to get in what works, is that OK?)
>>> Ok for me (if an explicit error message is generated when unsupported
>>> streams are found... Right now, the rtsp demuxer seems to continuously
>>> parse incoming packets, silently failing without generating any output...
>>> As a result, ffplay stalls).
>>> Of course, we need Michael's and Luca B's opinions about this.
>> Just wanted to get back to this one.
>> I tested several of the streams that originally failed and now work.
>> There's two reasons why it would fail:
>> 1: the OpaqueData can apparently have two layouts:
> Until support for this is in svn, we should have an error message
> and the parse function failing (so that a user can easily understand
> that a stream is unsupported, and why)
I'll add an error message if we fail to parse the OpaqueData chunk.
>> In these cases, ffplay tries to play it anyway and stalls, I think
>> that's an ffplay bug.
> I am not sure about this... When I try to play a file containing
> unsupported audio or video, ffplay complains and exits with an error.
> So, this issue needs to be better investigated (why is ffplay not
> receiving an error when trying to open an unknown codec? Maybe the
> RM demuxer is creating the stream with a wrong codec type?)
For files, yes. But for streams, if codec == CODEC_ID_NONE (or
anything that makes has_codec_parameters() in utils.c fail), it
basically hangs for a long time (~forever) in av_find_stream_info(),
this is probably because network reading is slow at lowbitrate
More information about the ffmpeg-devel