[MPlayer-dev-eng] Work on SDP and RTP support

compn tempn at twmi.rr.com
Tue Dec 21 20:05:21 CET 2010


On Tue, 21 Dec 2010 12:14:16 +0100, Reimar Döffinger wrote:
>On 21 dec 2010, at 12:08, Luca Barbato <lu_zero at gentoo.org> wrote:
>
>> On 12/21/2010 11:47 AM, Clément Bœsch wrote:
>>> I'm ok with making it through FFmpeg; the problem is that old MPlayer
>>> broken code still exists and is the default. Should I work on making the
>>> ffmpeg code called by default?
>> 
>> Might be worthy.
>
>If you think it works better, certainly.

reimar knows this code when he added ffmpeg:// stuff. i think he will
make it default after it has been tested. you can look at the commit
that made rtmp:// work to see how it was done.

>>> What do you mean by "in the long term"; should we drop this... now?
>
>No, definitely not now. You can't remove something that is currently the default, the alternative needs proper public testing first.

ffmpeg is still missing playlist support, so .smil and .mov
redirectors arent working. it would be nice to get those into ffmpeg.

rtsp://rm stuff is working better than before in ffmpeg, but needs
extensive testing to fix any remaining problems. also there was the
max_streams limit (was it fixed in the next major bump?) which would
hit the limit on mbr rm files.

if you want to help, you can color-code the wiki for urls that ffmpeg
doesnt play. that will help ffmpeg devs more quickly work on
troublesome urls. add 'fixing up rtsp' to the 'small tasks' page on the
wiki too.

i made one url red to show it wasnt working. use green or lime to
show working samples. i scanned the live555 devel list for rtsp urls,
maybe someone wants to test those as well?

what we are trying to do is stick all network, muxer, codec and
everything else we can into ffmpeg so it can be maintained there and
shared with more projects. after its tested we can start removing
duplicate features from mplayer.

i'm sorry that work has been done to mplayer without this in mind, but
as we only have reimar reviewing patches, he gets to decide what goes
in. maybe we should make a note on news page and mplayer readme about
changing to ffmpeg development ?

-compn


More information about the MPlayer-dev-eng mailing list