On 7/14/2014 8:15 AM, Reimar Döffinger wrote:
> 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.
This is a bad idea. API users d
On Mon, 14 Jul 2014 09:15:20 +0200
Reimar Döffinger wrote:
> 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.
That is true, but even the MJPEG e
On Mon, 14 Jul 2014 01:57:52 +0200
Michael Niedermayer wrote:
> On Sun, Jul 13, 2014 at 07:32:56PM +0100, Derek Buitenhuis wrote:
> > mplayer-specifc hacks should not be in our codebase. mplayer should fix
> > it's own code. It is not our responsibility to work around their broken
> > code.
> >
On 14.07.2014, at 00:15, wm4 wrote:
> On Sun, 13 Jul 2014 22:17:44 +0200
> Reimar Döffinger 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 the
On Sun, Jul 13, 2014 at 07:32:56PM +0100, Derek Buitenhuis wrote:
> mplayer-specifc hacks should not be in our codebase. mplayer should fix
> it's own code. It is not our responsibility to work around their broken
> code.
>
> This reverts commit e8e575633faf19711910cf9caf59f7db300a9ccd.
>
> Signe
On 7/13/2014 11:02 PM, Reimar Döffinger wrote:
> As far as I can tell MPlayer is now no longer affected.
> Unfortunately older versions might be.
> I guess it's up to you to decide the
> "getting rid of awful hack vs. keeping compatibility" importance.
I'd expect people using ffmpeg git HEAD are n
On Sun, 13 Jul 2014 22:17:44 +0200
Reimar Döffinger wrote:
> On Sun, Jul 13, 2014 at 08:38:44PM +0200, wm4 wrote:
> > On Sun, 13 Jul 2014 19:32:56 +0100
> > Derek Buitenhuis wrote:
> >
> > > mplayer-specifc hacks should not be in our codebase. mplayer should fix
> > > it's own code. It is not o
Hi,
On Sun, Jul 13, 2014 at 07:32:56PM +0100, Derek Buitenhuis wrote:
> mplayer-specifc hacks should not be in our codebase. mplayer should fix
> it's own code. It is not our responsibility to work around their broken
> code.
As far as I can tell MPlayer is now no longer affected.
Unfortunately o
On 7/13/2014 9:17 PM, Reimar Döffinger wrote:
> 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.
Indeed there should have been a version bump in
419ade4b6193c6eb626cda01b21e7091f42b2cc2
On Sun, Jul 13, 2014 at 08:38:44PM +0200, wm4 wrote:
> On Sun, 13 Jul 2014 19:32:56 +0100
> Derek Buitenhuis wrote:
>
> > mplayer-specifc hacks should not be in our codebase. mplayer should fix
> > it's own code. It is not our responsibility to work around their broken
> > code.
> >
> > This rev
On Sun, 13 Jul 2014 19:32:56 +0100
Derek Buitenhuis wrote:
> mplayer-specifc hacks should not be in our codebase. mplayer should fix
> it's own code. It is not our responsibility to work around their broken
> code.
>
> This reverts commit e8e575633faf19711910cf9caf59f7db300a9ccd.
>
> Signed-off
On 7/13/2014 7:32 PM, Derek Buitenhuis wrote:
> mplayer-specifc hacks should not be in our codebase. mplayer should fix
> it's own code. It is not our responsibility to work around their broken
> code.
it's -> its
- Derek
___
ffmpeg-devel mailing list
f
mplayer-specifc hacks should not be in our codebase. mplayer should fix
it's own code. It is not our responsibility to work around their broken
code.
This reverts commit e8e575633faf19711910cf9caf59f7db300a9ccd.
Signed-off-by: Derek Buitenhuis
---
libavcodec/utils.c |4 +---
1 files changed
13 matches
Mail list logo
