[MPlayer-dev-eng] talk on mplayer and xine.

Nico Sabbi nsabbi at email.it
Thu Dec 21 15:10:15 CET 2006


Attila Kinali wrote:

>>   1. Focus and activity - describe the areas that your project is
>>focusing and working on. This will put your goals and contributions in
>>context for other participants.
>>    
>>
>
>Currently, there is not much focus in MPlayer as a project.
>There are some fields where individuals put a lot of work
>into it, but there is no generel direction.
>
indeed, mplayer has been steadily going nowhere for many years,
and it's successfully proceeding in the same direction even now ;)

> Two of these
>are the dvdnav and ass support that Nico and Evgeniy
>are working on.
>
>  
>
>>   2. Problem areas - describe problems that your project has
>>encountered, things that are not working or not available. These items
>>will contribute to a gap analysis and areas for further discussion.
>>    
>>
>
>The biggest problem MPlayer faces is its lack of design.
>MPlayer grew from a 10 minutes hack into a full fledged
>video player application. There were some minor redesigns
>and refactoring of components, but overall we still have
>the same structure with which Arpi started over 5 years ago.
>It's this very same structure that limits us in further
>development in some specific areas becaus changing it
>would mean to rewrite big parts of MPlayer. And because
>the structure is complex (due to lacking design) it is
>also very hard to understand, making refactoring even more
>difficult.
>  
>
>  
>
mplayer's lack of design is a problem, but as far as I'm concerned
often the content to be played is organized in such idiotic manners that
no sane general purpose player can deal it without getting to compromises
with code cleannes; I always had hard times when dealing with contents
that forced stupid dependencies between different layers of the playback 
hyerarchy,
such as mux+codec (e.g. ogg and the few codecs it supports)
or mux+stream (http and many bastardizations of rtsp or mms disguised as 
http that
works/seeks only with certain mux types), stream+input and other 
degenerate cases.
People insist on trying to make mplayer work as a content-specific 
player for some
content types, without realizing that it's simply impossible without 
bastardizing the code
even more than it is now



More information about the MPlayer-dev-eng mailing list