On 18.11.2016 00:48, James Almer wrote:
> On 11/1/2016 12:54 PM, Andreas Cadhalpun wrote:
> I'll apply this patch later tonight or tomorrow morning and revert yours to
> restore the original proper behavior of making extradata available at init
> when possible, and signaling new one as needed on pa
On 11/17/2016 8:48 PM, James Almer wrote:
> On 11/1/2016 12:54 PM, Andreas Cadhalpun wrote:
>> On 01.11.2016 05:09, James Almer wrote:
>>> On 10/31/2016 11:32 PM, James Almer wrote:
Fixes remuxing apng streams coming from the apng demuxer.
This is a regression since 97792e85c338d129342f58
On 11/1/2016 12:54 PM, Andreas Cadhalpun wrote:
> On 01.11.2016 05:09, James Almer wrote:
>> On 10/31/2016 11:32 PM, James Almer wrote:
>>> Fixes remuxing apng streams coming from the apng demuxer.
>>> This is a regression since 97792e85c338d129342f5812e2a52048373e57d6.
>>>
>>> Signed-off-by: James
On 03.11.2016 20:03, James Almer wrote:
> On 11/3/2016 4:00 PM, Andreas Cadhalpun wrote:
>> On 03.11.2016 19:53, Hendrik Leppkes wrote:
>>> Since you want docs, I even found one extremely specific to this
>>> particular case:
>>> https://ffmpeg.org/ffmpeg-formats.html#apng
>>>
>>> "All headers, but
On 11/3/2016 4:00 PM, Andreas Cadhalpun wrote:
> On 03.11.2016 19:53, Hendrik Leppkes wrote:
>> Since you want docs, I even found one extremely specific to this
>> particular case:
>> https://ffmpeg.org/ffmpeg-formats.html#apng
>>
>> "All headers, but the PNG signature, up to (but not including) th
On 03.11.2016 19:53, Hendrik Leppkes wrote:
> Since you want docs, I even found one extremely specific to this
> particular case:
> https://ffmpeg.org/ffmpeg-formats.html#apng
>
> "All headers, but the PNG signature, up to (but not including) the
> first fcTL chunk are transmitted as extradata."
>
On Thu, Nov 3, 2016 at 7:39 PM, Andreas Cadhalpun
wrote:
> On 03.11.2016 09:52, Hendrik Leppkes wrote:
>> Hence my point about trying to stick to a common behavior scheme
>> without looking at what *OUR* decoder needs - there could be others,
>> after all.
>> Its common to write extradata into cod
On 03.11.2016 09:52, Hendrik Leppkes wrote:
> Hence my point about trying to stick to a common behavior scheme
> without looking at what *OUR* decoder needs - there could be others,
> after all.
> Its common to write extradata into codecpar if its present. You can
> try to dispute that as long as y
On Wed, Nov 2, 2016 at 9:20 PM, Andreas Cadhalpun
wrote:
> On 02.11.2016 21:10, Hendrik Leppkes wrote:
>> On Wed, Nov 2, 2016 at 8:13 PM, Andreas Cadhalpun
>> wrote:
>>> On 01.11.2016 23:10, Hendrik Leppkes wrote:
Am 01.11.2016 17:17 schrieb "Andreas Cadhalpun" <
andreas.cadhal...@googl
On 02.11.2016 21:10, Hendrik Leppkes wrote:
> On Wed, Nov 2, 2016 at 8:13 PM, Andreas Cadhalpun
> wrote:
>> On 01.11.2016 23:10, Hendrik Leppkes wrote:
>>> Am 01.11.2016 17:17 schrieb "Andreas Cadhalpun" <
>>> andreas.cadhal...@googlemail.com>:
Not again, but instead, as the extradata is then
On Wed, Nov 2, 2016 at 8:13 PM, Andreas Cadhalpun
wrote:
> On 01.11.2016 23:10, Hendrik Leppkes wrote:
>> Am 01.11.2016 17:17 schrieb "Andreas Cadhalpun" <
>> andreas.cadhal...@googlemail.com>:
>>> Not again, but instead, as the extradata is then only transferred as side
>>> data.
>>> That way it
On 01.11.2016 23:10, Hendrik Leppkes wrote:
> Am 01.11.2016 17:17 schrieb "Andreas Cadhalpun" <
> andreas.cadhal...@googlemail.com>:
>> Not again, but instead, as the extradata is then only transferred as side
>> data.
>> That way it is again consistent between demuxer/decoder and encoder/muxer.
>
On 11/1/2016 7:10 PM, Hendrik Leppkes wrote:
> Am 01.11.2016 17:17 schrieb "Andreas Cadhalpun" <
> andreas.cadhal...@googlemail.com>:
>>
>> On 01.11.2016 17:06, James Almer wrote:
>>> On 11/1/2016 12:54 PM, Andreas Cadhalpun wrote:
What I like about the approach of using the private extra_data
Am 01.11.2016 17:17 schrieb "Andreas Cadhalpun" <
andreas.cadhal...@googlemail.com>:
>
> On 01.11.2016 17:06, James Almer wrote:
> > On 11/1/2016 12:54 PM, Andreas Cadhalpun wrote:
> >> What I like about the approach of using the private extra_data context
buffer is
> >> that is is quite obvious wh
On 01.11.2016 17:06, James Almer wrote:
> On 11/1/2016 12:54 PM, Andreas Cadhalpun wrote:
>> What I like about the approach of using the private extra_data context
>> buffer is
>> that is is quite obvious where it is set. On the other hand the codecpar
>> extradata can be set anywhere, which makes
On 11/1/2016 12:54 PM, Andreas Cadhalpun wrote:
> On 01.11.2016 05:09, James Almer wrote:
>> On 10/31/2016 11:32 PM, James Almer wrote:
>>> Fixes remuxing apng streams coming from the apng demuxer.
>>> This is a regression since 97792e85c338d129342f5812e2a52048373e57d6.
>>>
>>> Signed-off-by: James
On 01.11.2016 05:09, James Almer wrote:
> On 10/31/2016 11:32 PM, James Almer wrote:
>> Fixes remuxing apng streams coming from the apng demuxer.
>> This is a regression since 97792e85c338d129342f5812e2a52048373e57d6.
>>
>> Signed-off-by: James Almer
>> ---
>> libavformat/apngenc.c | 7 +++
>>
On 10/31/2016 11:32 PM, James Almer wrote:
> Fixes remuxing apng streams coming from the apng demuxer.
> This is a regression since 97792e85c338d129342f5812e2a52048373e57d6.
>
> Signed-off-by: James Almer
> ---
> libavformat/apngenc.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --gi
On 10/31/2016 11:32 PM, James Almer wrote:
> Fixes remuxing apng streams coming from the apng demuxer.
> This is a regression since 97792e85c338d129342f5812e2a52048373e57d6.
Should be 940b8908b94404a65f9f55e33efb4ccc6c81383c, sorry.
>
> Signed-off-by: James Almer
> ---
> libavformat/apngenc.c
Fixes remuxing apng streams coming from the apng demuxer.
This is a regression since 97792e85c338d129342f5812e2a52048373e57d6.
Signed-off-by: James Almer
---
libavformat/apngenc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavformat/apngenc.c b/libavformat/apngenc.c
index e5e8a
20 matches
Mail list logo
