Hi Attila Kinali! On 2008.10.17 at 18:47:39 +0200, Attila Kinali wrote next: > > but a/v sync problems is one big > > areas where are I stopped submitting bugs a long time ago, since usually > > no solution is offered > > Because it's the single most difficult field of problems to fix. > A/V sync problems can stem from anything, sound card bugs, sound > card driver bugs, video card driver bugs, too slow cpu, broken > files in various forms and bugs in MPlayer. And with the information Hmm.. I experienced some of the things you're talking about, like sound card and driver bugs in the past, but I'm pretty sure nowadays most sync problems come from broken files, and some from bugs in mplayer. > > (even for the simplest question like "if I found > > correct -mc/-fps/etc options that keep sync, how do I remux file so that > > resulting one can be played in sync without using any special options"). > > Uhm.. because this question is so simple that by looking into the > documentation for a few minutes you could have figured it out yourself? Yes, though unfortunately I still don't have answer for this question. > Beside, why don't you as a fellow user answer those questions if you > know the answer? Having invested quite a time into solving a/v sync problems in varions situations with mplayer and mencoder, I always try to help people on this when I notice question/have time.. > > Unfortunately, mplayer and ffmpeg have a lot of problem areas where bug > > submitting isn't worth it. Well, IMHO mplayer has major problems with bug > > processing anyway - most bugs don't get solved unless some developer is > > interested into fixing it right after bug report appears, > > This is normal with all of the projects i know. If you cannot > get a developer interested in fixing a bug, you either have to > fix it yourself or will never get it fixed at all. Sounds logical, > doesn't it? Yes. Unfortunately, mplayer's bug reporting works much worse than with some other projects. Many reasons for that.. In small projects there are people interested in "making project better" and "fixing any bug, as long as it's annoying enough", but mplayer is big and complex and no one knows everything there in detail enough for fixing obscure bugs; forgive me if I'm wrong, but it looks to me that mplayer hasn't got a team of lead developers who can take on any bug in any of its modules if the person maintaining this module is absent or can't fix the bug. Lack of good, popular among users and developers and useful bug tracking system (yes, I know that there are some), meaning that even most detailed bugreport is lost if the only developer who can fix that wasn't reading list for some time. And, of course, interaction with broken files, hardware and environment, which is a source of many bugs.. > To motivate developers, one way is to make sure they get that > the problem you have is important (aka many users have it) and It's hard. Besides, I think that mplayer loses its users (mainly because unlike 5 years ago, now there are other usable media players based on ffmpeg, less obscure than mplayer). Well, mplayer is still bleeding age of linux players in terms of overall features and performance, and I guess there'll be a lot of users as long as it stays this way. However, simply because of this niche mplayers' users and developers will meet more uncommon and strange bugs and feature requests than users and developers of some other media players; there's simply no way around it. > that it is really a problem of MPlayer and not in the user setup > or a problem of the file. Or for new features, make sure the Arhg, "problem of the file" again. Can "the problem is in the file, but player XYZ somehow managed to work around it" be considered a problem of mplayer? ;) -- Vladimir
