On 14.07.2014, at 00:15, wm4 <nfx...@googlemail.com> wrote:
> On Sun, 13 Jul 2014 22:17:44 +0200
> Reimar Döffinger <reimar.doeffin...@gmx.de> wrote:
> 
>> On Sun, Jul 13, 2014 at 08:38:44PM +0200, wm4 wrote
>> 
>>> A project specific hack for
>>> something that used the API incorrectly. I surely hope mplayer fixed
>>> this in the meantime on their side, they had time enough to do that.
>> 
>> Well, IMHO if this is a requirement that was added, I would say
>> it was an API change, and MPlayer might just be the first where
>> the API change was detected.
> 
> No. It just happened to work with the PNG format. In general, setting
> the dimensions before opening was required. When the error check was
> added, someone noticed that it broke mplayer, and added this
> "exception".

I actually think it worked with a lot of formats, not just PNG (which is not an 
argument for the hack though). This is also related to encoders which can in 
principle support resolution changes.
I also believe setting dimensions before open was never a documented 
requirement, and someone only using PNG (as in these MPlayer code parts) would 
never have noticed what "all other encoders" require.
So from my point of view, it's not obvious earlier behaviour was by chance and 
not a feature.
There is also the issue about how much sense the check makes: while I decided 
to do it (slightly) more properly, a "fix" would be to just set width/height to 
320x240 no matter what you actually encode in the end.
So that check doesn't actually prevent any wrong use.
Which would allow for a different "solution": when no width/height is set, 
print warning and set some dummy values.
I repeat: I believe it's a question of how much we want compatibility with 
programs using "misfeatures" that IMHO were not necessarily/trivially 
recognizable as such. I am always assuming there are likely more programs with 
the same issues, if I was sure it was only MPlayer I'd care a lot less.
Either way, I guess I stated my point and leave the deciding to others less 
potentially biased.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to