Hi,
On Sat, Sep 3, 2011 at 5:17 AM, Felipe Contreras
wrote:
> On Tue, Aug 30, 2011 at 1:09 PM, Luca Barbato wrote:
>> On 8/30/11 6:41 AM, Uoti Urpala wrote:
>>>
>>> Note that it isn't "this code" (as in the reverted code) that sets it to
>>> a wrong value. The code setting it is in avcodec_open2
On Tue, Aug 30, 2011 at 1:09 PM, Luca Barbato wrote:
> On 8/30/11 6:41 AM, Uoti Urpala wrote:
>>
>> Note that it isn't "this code" (as in the reverted code) that sets it to
>> a wrong value. The code setting it is in avcodec_open2(), which
>> initially sets width to equal coded_width; this is prob
"Ronald S. Bultje" writes:
> Hi,
>
> On Mon, Aug 29, 2011 at 8:16 PM, Uoti Urpala wrote:
>> On Mon, 2011-08-29 at 19:48 -0700, Ronald S. Bultje wrote:
>>> On Mon, Aug 29, 2011 at 7:06 PM, Uoti Urpala
>>> wrote:
>>
>>> > The actual problem here was that an application was using avctx->height
>>
On 8/30/11 6:41 AM, Uoti Urpala wrote:
Note that it isn't "this code" (as in the reverted code) that sets it to
a wrong value. The code setting it is in avcodec_open2(), which
initially sets width to equal coded_width; this is probably currently
needed for codecs like raw that do not themselves i
On Mon, 2011-08-29 at 21:04 -0700, Ronald S. Bultje wrote:
> Libavcodec expects values to be set as they would be by libavformat,
> be that in practice done by mplayer or libavformat or whatever the
> demuxer-of-the-day is. It's probably underdocumented, but that doesn't
> make it any less true.
W
Hi,
On Mon, Aug 29, 2011 at 8:16 PM, Uoti Urpala wrote:
> On Mon, 2011-08-29 at 19:48 -0700, Ronald S. Bultje wrote:
>> On Mon, Aug 29, 2011 at 7:06 PM, Uoti Urpala wrote:
>
>> > The actual problem here was that an application was using avctx->height
>> > immediately after avcodec_open2(). The h
On Mon, 2011-08-29 at 19:48 -0700, Ronald S. Bultje wrote:
> On Mon, Aug 29, 2011 at 7:06 PM, Uoti Urpala wrote:
> > The actual problem here was that an application was using avctx->height
> > immediately after avcodec_open2(). The h264 decoder and others do not
> > set width/height until after a
Hi,
On Mon, Aug 29, 2011 at 7:06 PM, Uoti Urpala wrote:
> On Mon, 2011-08-29 at 03:15 +0300, Uoti Urpala wrote:
>> On Mon, 2011-08-29 at 01:13 +0200, Luca Barbato wrote:
>> > Currently we are misreporting the uncropped/multiple-of-macroblocks h264
>> > dimensions as the image dimensions. That is
On Mon, 2011-08-29 at 03:15 +0300, Uoti Urpala wrote:
> On Mon, 2011-08-29 at 01:13 +0200, Luca Barbato wrote:
> > Currently we are misreporting the uncropped/multiple-of-macroblocks h264
> > dimensions as the image dimensions. That is bogus and wrong.
>
> I think it's quite a stretch to claim th
On Mon, 2011-08-29 at 01:13 +0200, Luca Barbato wrote:
> On 8/29/11 12:59 AM, Uoti Urpala wrote:
> > So you want to delete any indication of cropping (keep cropped width
> > only)? I think the width before cropping is meaningful information.
>
> Currently we are misreporting the uncropped/multiple
Hi,
On Sun, Aug 28, 2011 at 3:59 PM, Uoti Urpala wrote:
> On Sun, 2011-08-28 at 23:47 +0200, Luca Barbato wrote:
>> On 8/21/11 6:27 PM, Luca Barbato wrote:
>> > This reverts commit b47904d158709bdec1a9d40e83d1abadf50081dc.
>> >
>> > coded_{width, height} overwrites width and height in avcodec_ope
On 8/29/11 12:59 AM, Uoti Urpala wrote:
So you want to delete any indication of cropping (keep cropped width
only)? I think the width before cropping is meaningful information.
Currently we are misreporting the uncropped/multiple-of-macroblocks h264
dimensions as the image dimensions. That is
On Sun, 2011-08-28 at 23:47 +0200, Luca Barbato wrote:
> On 8/21/11 6:27 PM, Luca Barbato wrote:
> > This reverts commit b47904d158709bdec1a9d40e83d1abadf50081dc.
> >
> > coded_{width, height} overwrites width and height in avcodec_open
> > ---
> >
> > I'm not sure if the avcodec_open behaviour is
Hi,
On Sun, Aug 28, 2011 at 2:47 PM, Luca Barbato wrote:
> On 8/21/11 6:27 PM, Luca Barbato wrote:
>>
>> This reverts commit b47904d158709bdec1a9d40e83d1abadf50081dc.
>>
>> coded_{width, height} overwrites width and height in avcodec_open
>> ---
>>
>> I'm not sure if the avcodec_open behaviour is
On 8/21/11 6:27 PM, Luca Barbato wrote:
This reverts commit b47904d158709bdec1a9d40e83d1abadf50081dc.
coded_{width, height} overwrites width and height in avcodec_open
---
I'm not sure if the avcodec_open behaviour is the expected one or not,
but seems correct according our doxy on width,height
On 8/28/11 9:47 AM, aviad rozenhek wrote:
ok, here's same patch without public api
That makes me think there are cases in which we are calling this
function twice. Looks like the logic issue we are trying to address is
hiding a larger fault.
lu
__
On Fri, Aug 26, 2011 at 00:47, Luca Barbato wrote:
> On 8/25/11 6:04 PM, aviad rozenhek wrote:
>
>> On Wed, Aug 24, 2011 at 11:42, aviad rozenhek wrote:
>>
>> On Mon, Aug 22, 2011 at 23:39, Luca Barbato wrote:
>>>
>>> On 8/22/11 9:05 PM, Måns Rullgård wrote:
Luca Barbato writes:
On 8/25/11 6:04 PM, aviad rozenhek wrote:
On Wed, Aug 24, 2011 at 11:42, aviad rozenhek wrote:
On Mon, Aug 22, 2011 at 23:39, Luca Barbato wrote:
On 8/22/11 9:05 PM, Måns Rullgård wrote:
Luca Barbato writes:
On 8/22/11 4:04 PM, Måns Rullgård wrote:
Luca Barbatowrites:
On 8/
On Wed, Aug 24, 2011 at 11:42, aviad rozenhek wrote:
> On Mon, Aug 22, 2011 at 23:39, Luca Barbato wrote:
>
>> On 8/22/11 9:05 PM, Måns Rullgård wrote:
>>
>>> Luca Barbato writes:
>>>
>>> On 8/22/11 4:04 PM, Måns Rullgård wrote:
> Luca Barbato writes:
>
> On 8/22/11 11:54 A
Luca Barbato writes:
> On 8/24/11 12:43 PM, Måns Rullgård wrote:
>> Luca Barbato writes:
>>
>>> On 8/24/11 10:42 AM, aviad rozenhek wrote:
On Mon, Aug 22, 2011 at 23:39, Luca Barbato wrote:
>>>
>>> That might be a good idea, btw, what are we doing regarding lowres?
>>
>> I still want to d
On 8/24/11 12:43 PM, Måns Rullgård wrote:
Luca Barbato writes:
On 8/24/11 10:42 AM, aviad rozenhek wrote:
On Mon, Aug 22, 2011 at 23:39, Luca Barbato wrote:
That might be a good idea, btw, what are we doing regarding lowres?
I still want to delete it, and I have still not heard of anyon
Luca Barbato writes:
> On 8/24/11 10:42 AM, aviad rozenhek wrote:
>> On Mon, Aug 22, 2011 at 23:39, Luca Barbato wrote:
>
> That might be a good idea, btw, what are we doing regarding lowres?
I still want to delete it, and I have still not heard of anyone actually
using it (speculations regardi
On 8/24/11 10:42 AM, aviad rozenhek wrote:
On Mon, Aug 22, 2011 at 23:39, Luca Barbato wrote:
That might be a good idea, btw, what are we doing regarding lowres?
lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/
On Mon, Aug 22, 2011 at 23:39, Luca Barbato wrote:
> On 8/22/11 9:05 PM, Måns Rullgård wrote:
>
>> Luca Barbato writes:
>>
>> On 8/22/11 4:04 PM, Måns Rullgård wrote:
>>>
Luca Barbato writes:
On 8/22/11 11:54 AM, Måns Rullgård wrote:
>
>> But that *is* the coded width/
Tomas Härdin writes:
> Måns Rullgård skrev 2011-08-22 18:05:
>> Tomas Härdin writes:
>>
>>> Måns Rullgård skrev 2011-08-22 16:04:
Luca Barbato writes:
> On 8/22/11 11:54 AM, Måns Rullgård wrote:
>> But that *is* the coded width/height. Using those as display
>> width/hei
Måns Rullgård skrev 2011-08-22 18:05:
Tomas Härdin writes:
Måns Rullgård skrev 2011-08-22 16:04:
Luca Barbato writes:
On 8/22/11 11:54 AM, Måns Rullgård wrote:
But that *is* the coded width/height. Using those as display
width/height is broken.
then we have a documentation hole, which
On 8/22/11 9:05 PM, Måns Rullgård wrote:
Luca Barbato writes:
On 8/22/11 4:04 PM, Måns Rullgård wrote:
Luca Barbato writes:
On 8/22/11 11:54 AM, Måns Rullgård wrote:
But that *is* the coded width/height. Using those as display
width/height is broken.
then we have a documentation hole,
Luca Barbato writes:
> On 8/22/11 4:04 PM, Måns Rullgård wrote:
>> Luca Barbato writes:
>>
>>> On 8/22/11 11:54 AM, Måns Rullgård wrote:
But that *is* the coded width/height. Using those as display
width/height is broken.
>>>
>>> then we have a documentation hole, which field contains
On 8/22/11 4:04 PM, Måns Rullgård wrote:
Luca Barbato writes:
On 8/22/11 11:54 AM, Måns Rullgård wrote:
But that *is* the coded width/height. Using those as display
width/height is broken.
then we have a documentation hole, which field contains the correct values?
Both are correct but fo
Tomas Härdin writes:
> Måns Rullgård skrev 2011-08-22 16:04:
>> Luca Barbato writes:
>>
>>> On 8/22/11 11:54 AM, Måns Rullgård wrote:
But that *is* the coded width/height. Using those as display
width/height is broken.
>>>
>>> then we have a documentation hole, which field contains th
Måns Rullgård skrev 2011-08-22 16:04:
Luca Barbato writes:
On 8/22/11 11:54 AM, Måns Rullgård wrote:
But that *is* the coded width/height. Using those as display
width/height is broken.
then we have a documentation hole, which field contains the correct values?
Both are correct but for d
Luca Barbato writes:
> On 8/22/11 11:54 AM, Måns Rullgård wrote:
>> But that *is* the coded width/height. Using those as display
>> width/height is broken.
>
> then we have a documentation hole, which field contains the correct values?
Both are correct but for different things. coded_{width,he
On 8/22/11 11:54 AM, Måns Rullgård wrote:
But that *is* the coded width/height. Using those as display
width/height is broken.
then we have a documentation hole, which field contains the correct values?
lu
___
libav-devel mailing list
libav-devel@
Luca Barbato writes:
> This reverts commit b47904d158709bdec1a9d40e83d1abadf50081dc.
>
> coded_{width, height} overwrites width and height in avcodec_open
> ---
>
> I'm not sure if the avcodec_open behaviour is the expected one or not,
> but seems correct according our doxy on width,height and co
On Sun, Aug 21, 2011 at 19:27, Luca Barbato wrote:
> This reverts commit b47904d158709bdec1a9d40e83d1abadf50081dc.
>
> coded_{width, height} overwrites width and height in avcodec_open
> ---
>
> I'm not sure if the avcodec_open behaviour is the expected one or not,
> but seems correct according o
This reverts commit b47904d158709bdec1a9d40e83d1abadf50081dc.
coded_{width, height} overwrites width and height in avcodec_open
---
I'm not sure if the avcodec_open behaviour is the expected one or not,
but seems correct according our doxy on width,height and coded_ variant.
libavcodec/h264.c |
36 matches
Mail list logo
