Hi,
On Fri, Mar 17, 2017 at 11:43 AM, Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:
> On Tue, Mar 7, 2017 at 7:17 PM, Vittorio Giovara
> wrote:
> > This should address the mismatch between different archs
> > Please CC.
> > --
> > Vittorio
>
> ping
No objections issues after 24hrs mean
On Tue, Mar 7, 2017 at 7:17 PM, Vittorio Giovara
wrote:
> This should address the mismatch between different archs
> Please CC.
> --
> Vittorio
ping
Please CC.
--
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman
On Thu, 9 Mar 2017 20:48:51 +0100
Michael Niedermayer wrote:
> On Thu, Mar 09, 2017 at 07:48:53AM +0100, wm4 wrote:
> > On Thu, 9 Mar 2017 02:20:03 +0100
> > Michael Niedermayer wrote:
> >
> > > On Wed, Mar 08, 2017 at 11:54:59PM +0100, Hendrik Leppkes wrote:
> > > > On Wed, Mar 8, 2017 at
On Thu, Mar 09, 2017 at 07:48:53AM +0100, wm4 wrote:
> On Thu, 9 Mar 2017 02:20:03 +0100
> Michael Niedermayer wrote:
>
> > On Wed, Mar 08, 2017 at 11:54:59PM +0100, Hendrik Leppkes wrote:
> > > On Wed, Mar 8, 2017 at 3:42 PM, Ronald S. Bultje
> > > wrote:
> > > > Hi,
> > > >
> > > > On Wed,
Le nonidi 19 ventôse, an CCXXV, Michael Niedermayer a écrit :
> it is a property of the file in multiple cases
>
> through the split side data code but even if this is removed
> for example
> AV_PKT_DATA_NEW_EXTRADATA is just binary data from the file the
> length is from the file
>
> or AV_PKT_D
On Thu, 9 Mar 2017 02:20:03 +0100
Michael Niedermayer wrote:
> On Wed, Mar 08, 2017 at 11:54:59PM +0100, Hendrik Leppkes wrote:
> > On Wed, Mar 8, 2017 at 3:42 PM, Ronald S. Bultje
> > wrote:
> > > Hi,
> > >
> > > On Wed, Mar 8, 2017 at 9:31 AM, wm4 wrote:
> > >
> > >> On Wed, 8 Mar 2017 1
On Thu, 9 Mar 2017 01:45:29 +0100
Michael Niedermayer wrote:
> On Wed, Mar 08, 2017 at 11:54:59PM +0100, Hendrik Leppkes wrote:
> > On Wed, Mar 8, 2017 at 3:42 PM, Ronald S. Bultje
> > wrote:
> > > Hi,
> > >
> > > On Wed, Mar 8, 2017 at 9:31 AM, wm4 wrote:
> > >
> > >> On Wed, 8 Mar 2017 1
On Wed, Mar 8, 2017 at 8:15 PM, James Almer wrote:
> On 3/8/2017 9:45 PM, Michael Niedermayer wrote:
>> On Wed, Mar 08, 2017 at 11:54:59PM +0100, Hendrik Leppkes wrote:
>>> On Wed, Mar 8, 2017 at 3:42 PM, Ronald S. Bultje wrote:
Hi,
On Wed, Mar 8, 2017 at 9:31 AM, wm4 wrote:
On Wed, Mar 08, 2017 at 11:54:59PM +0100, Hendrik Leppkes wrote:
> On Wed, Mar 8, 2017 at 3:42 PM, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Wed, Mar 8, 2017 at 9:31 AM, wm4 wrote:
> >
> >> On Wed, 8 Mar 2017 14:09:53 +0100
> >> Michael Niedermayer wrote:
> >>
> >> If the size printing is remov
On 3/8/2017 1:27 PM, Nicolas George wrote:
> L'octidi 18 ventôse, an CCXXV, Vittorio Giovara a écrit :
>> I'm just going to say that for the case at hand
>> sizeof(AVSphericalMapping) is not part of the ABI, and so it is
>> allowed to have different sizes on different architectures.
>
> I am not s
On 3/8/2017 9:45 PM, Michael Niedermayer wrote:
> On Wed, Mar 08, 2017 at 11:54:59PM +0100, Hendrik Leppkes wrote:
>> On Wed, Mar 8, 2017 at 3:42 PM, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Wed, Mar 8, 2017 at 9:31 AM, wm4 wrote:
>>>
On Wed, 8 Mar 2017 14:09:53 +0100
Michael Niederma
On Thu, Mar 09, 2017 at 12:07:38AM +0100, Nicolas George wrote:
> L'octidi 18 ventôse, an CCXXV, Hendrik Leppkes a écrit :
> > So how do we fix fate now? Change the datatypes to uint32_t, remove
> > the size print out?
> > Shouldn't keep all 32-bit fate clients broken for much longer.
>
> Changing
On Wed, Mar 08, 2017 at 11:54:59PM +0100, Hendrik Leppkes wrote:
> On Wed, Mar 8, 2017 at 3:42 PM, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Wed, Mar 8, 2017 at 9:31 AM, wm4 wrote:
> >
> >> On Wed, 8 Mar 2017 14:09:53 +0100
> >> Michael Niedermayer wrote:
> >>
> >> If the size printing is remov
L'octidi 18 ventôse, an CCXXV, Hendrik Leppkes a écrit :
> So how do we fix fate now? Change the datatypes to uint32_t, remove
> the size print out?
> Shouldn't keep all 32-bit fate clients broken for much longer.
Changing the types like that will not guarantee that all architectures
have have the
On Wed, Mar 8, 2017 at 3:42 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Wed, Mar 8, 2017 at 9:31 AM, wm4 wrote:
>
>> On Wed, 8 Mar 2017 14:09:53 +0100
>> Michael Niedermayer wrote:
>>
>> If the size printing is removed then other code should be added
>> > to test for the size to match the correct v
L'octidi 18 ventôse, an CCXXV, Vittorio Giovara a écrit :
> I'm just going to say that for the case at hand
> sizeof(AVSphericalMapping) is not part of the ABI, and so it is
> allowed to have different sizes on different architectures.
I am not sure exactly what you are asserting here, but just fo
On Wed, Mar 8, 2017 at 6:51 AM, Michael Niedermayer
wrote:
>> Removing the side_data_size from output should be fine, as its a
>> implementation detail and as seen here can even vary between
>> architecture or possibly even compiler.
>> Maybe someone that uses that ffprobe output more often can co
Hi,
On Wed, Mar 8, 2017 at 9:31 AM, wm4 wrote:
> On Wed, 8 Mar 2017 14:09:53 +0100
> Michael Niedermayer wrote:
>
> If the size printing is removed then other code should be added
> > to test for the size to match the correct value
>
> Then it would be more reasonable to make av_packet_add_side
On Wed, 8 Mar 2017 14:09:53 +0100
Michael Niedermayer wrote:
> On Wed, Mar 08, 2017 at 01:12:04PM +0100, wm4 wrote:
> > On Wed, 8 Mar 2017 13:04:11 +0100
> > Michael Niedermayer wrote:
> >
> > > On Wed, Mar 08, 2017 at 12:56:31PM +0100, wm4 wrote:
> > > > On Wed, 8 Mar 2017 12:51:06 +0100
>
On Wed, Mar 08, 2017 at 01:12:04PM +0100, wm4 wrote:
> On Wed, 8 Mar 2017 13:04:11 +0100
> Michael Niedermayer wrote:
>
> > On Wed, Mar 08, 2017 at 12:56:31PM +0100, wm4 wrote:
> > > On Wed, 8 Mar 2017 12:51:06 +0100
> > > Michael Niedermayer wrote:
> > >
> > > > On Wed, Mar 08, 2017 at 12:28
On Wed, 8 Mar 2017 13:04:11 +0100
Michael Niedermayer wrote:
> On Wed, Mar 08, 2017 at 12:56:31PM +0100, wm4 wrote:
> > On Wed, 8 Mar 2017 12:51:06 +0100
> > Michael Niedermayer wrote:
> >
> > > On Wed, Mar 08, 2017 at 12:28:17PM +0100, Hendrik Leppkes wrote:
> > > > On Wed, Mar 8, 2017 at
On Wed, Mar 08, 2017 at 12:56:31PM +0100, wm4 wrote:
> On Wed, 8 Mar 2017 12:51:06 +0100
> Michael Niedermayer wrote:
>
> > On Wed, Mar 08, 2017 at 12:28:17PM +0100, Hendrik Leppkes wrote:
> > > On Wed, Mar 8, 2017 at 1:17 AM, Vittorio Giovara
> > > wrote:
> > > > This should address the misma
On Wed, 8 Mar 2017 12:51:06 +0100
Michael Niedermayer wrote:
> On Wed, Mar 08, 2017 at 12:28:17PM +0100, Hendrik Leppkes wrote:
> > On Wed, Mar 8, 2017 at 1:17 AM, Vittorio Giovara
> > wrote:
> > > This should address the mismatch between different archs
>
> iam not in favor of this solutio
On Wed, Mar 08, 2017 at 12:28:17PM +0100, Hendrik Leppkes wrote:
> On Wed, Mar 8, 2017 at 1:17 AM, Vittorio Giovara
> wrote:
> > This should address the mismatch between different archs
iam not in favor of this solution
>
> Removing the side_data_size from output should be fine, as its a
> imp
On Wed, Mar 8, 2017 at 1:17 AM, Vittorio Giovara
wrote:
> This should address the mismatch between different archs
Removing the side_data_size from output should be fine, as its a
implementation detail and as seen here can even vary between
architecture or possibly even compiler.
Maybe someone th
This should address the mismatch between different archs
Please CC.
--
Vittorio
0001-fate-Do-not-report-side-data-size.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
26 matches
Mail list logo