[FFmpeg-devel] [PATCH] Revert "lavc/utils: Do not require dimensions for PNG."
Reimar.Doeffinger at gmx.de
Mon Jul 14 09:15:20 CEST 2014
On 14.07.2014, at 00:15, wm4 <nfxjfg at googlemail.com> wrote:
> On Sun, 13 Jul 2014 22:17:44 +0200
> Reimar Döffinger <Reimar.Doeffinger at 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
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.
More information about the ffmpeg-devel