Re: [FFmpeg-devel] FFmpeg 3.4.1

[Michael Niedermayer]

On Fri, Dec 08, 2017 at 01:25:16PM +0100, Marton Balint wrote:
> 
> 
> On Fri, 8 Dec 2017, wm4 wrote:
> 
> >On Fri, 8 Dec 2017 06:52:20 +0100
> >Michael Niedermayer  wrote:
> >
> >>On Fri, Dec 08, 2017 at 01:09:50AM -0300, James Almer wrote:
> >>> On 12/8/2017 12:26 AM, wm4 wrote: > > On Thu, 7 Dec 2017
> >>23:23:51 +0100
> >>> > Michael Niedermayer  wrote:
> >>> > > >> On Tue, Nov 21, 2017 at 07:58:18PM +0100, Michael
> >>Niedermayer wrote: > >>> On Sat, Nov 18, 2017 at 09:11:17PM
> >>+0100, Michael Niedermayer wrote: >  On Sat, Nov 18, 2017 at
> >>09:50:33AM +0100, Hendrik Leppkes wrote: > > On Sat, Nov 18,
> >>2017 at 3:05 AM, Michael Niedermayer
> >>> >  wrote: > >> On Fri, Nov 17,
> >>2017 at 09:55:47AM +0100, Hendrik Leppkes wrote: > >>> On
> >>Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
> >>> >>>  wrote: >  On Thu, Nov
> >>16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote: >
> >>> 2017-11-16 13:44 GMT+01:00 Michael Niedermayer
> >>: > >> On Thu, Nov 16, 2017 at
> >>01:04:27AM +0100, Carl Eugen Hoyos wrote: > >>>
> >>2017-11-15 13:34 GMT+01:00 Michael Niedermayer
> >>: >  Hi all
> >>> 
> >>>  I intend to make 3.4.1 very soon > >>>
> >>> >>> Shouldn't we first decide on how to proceed with
> >>#6775? > >>
> >>> >> This would be ideal.
> >>> >>
> >>> >> IIUC this is a regression from
> >>bddb2343b6e594e312dadb5d21b408702929ae04 > >
> >>> > This was confirmed by more than one developer, yes.
> >>> > > >> I see a patch that is said to improve
> >>6775, can that be applied and
> >>> >> would that resolve this ? > >
> >>> > Iiuc, it would not completely resolve the issue, see:
> >>> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
> >>> > > >> If so why was it not applied yet ? >
> >>>
> >>> > The patch did not get support here, see:
> >>> > [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet 
> >>> > after EOF
> >>> > in compat_decode > 
> >>> 
> >>>  Is someone working on fixing this better than with the available 
> >>>  patch ?
> >>>  > >>>
> >>> >>> I don't even agree this needs fixing. Those projects
> >>use the API wrong. > >>
> >>> >> Had we documented the correct/wrong use precissely in the past when
> >>> >> these wrong uses where written ?
> >>> >>
> >>> >> Because if it was documented then few should have made the mistake.
> >>> >> But it seems this affects multiple projects, so i wonder if our API
> >>> >> really excluded the use
> >>> >> > >
> >>> > Apparently not well enough, but I also don't even understand why you
> >>> > would *want* to drain in the middle of decoding.
> >>> >
> >>> > The only mention of sending NULL/0 packets (in 3.0 docs, before the
> >>> > new API was introduced) do include the "at the end", however.
> >>> >
> >>> > From CODEC_CAP_DELAY:
> >>> >  * Decoders:
> >>> >  * The decoder has a non-zero delay and needs to be fed with 
> >>> > avpkt->data=NULL,
> >>> >  * avpkt->size=0 at the end to get the delayed data until the 
> >>> > decoder no longer
> >>> >  * returns frames.
> >>> >
> >>> > From avcodec_decode_video2
> >>> > * @note Codecs which have the AV_CODEC_CAP_DELAY capability set 
> >>> > have a delay
> >>> > * between input and output, these need to be fed with 
> >>> > avpkt->data=NULL,
> >>> > * avpkt->size=0 at the end to return the remaining frames.
> >>> >
> >>> > There is a few more mentions of the same concept, but as far as I 
> >>> > can
> >>> > see all include the key words "at the end".
> >>> > >  > > For the suggested patch, draining and
> >>flushing in the middle of a
> >>> > bitstream is still going to result in problems, though, since it
> >>> > removes all reference frames, for example.
> >>> > The original behavior cannot really be stored, which was to just 
> >>> > keep
> >>> > feeding frames into the decoder after a drain without a flush.
> >>> > However, some decoders actually crashed when you did this, so this 
> >>> > was
> >>> > a rather unsafe action to begin with (not an issue any longer, since
> >>> > this pattern is now blocked). > 
> >>>  Did the previous code really work if the frame after a flush was not 
> >>>  a
> >>>  new keyframe or there was some use of previous references
> >>? > >>>
> >>> >>> ping
> >>> >>>
> >>> >>> so what is the status of this?
> >>> >>>
> >>> >>> Ticket 6775 is still open, neither a workaround was applied nor was
> >>> >>> it closed as 

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Carl Eugen Hoyos]

2017-12-08 5:42 GMT+01:00 James Almer :
> On 12/8/2017 1:33 AM, Carl Eugen Hoyos wrote:
>> 2017-12-08 5:09 GMT+01:00 James Almer :
>>
>>> When the old decode API was turned into a wrapper for the
>>> new, some applications using said API this way started to
>>> experience issues/crashes that did not happen before.
>>
>> Where was a crash reported?

> I said issues/crashes because i wasn't sure which kind was reported.
> Looking at the ticket, i guess it was the former.

Thank you!

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Marton Balint]

On Fri, 8 Dec 2017, wm4 wrote:


On Fri, 8 Dec 2017 06:52:20 +0100
Michael Niedermayer  wrote:


On Fri, Dec 08, 2017 at 01:09:50AM -0300, James Almer wrote:
> On 12/8/2017 12:26 AM, wm4 wrote: 
> > On Thu, 7 Dec 2017 23:23:51 +0100

> > Michael Niedermayer  wrote:
> > 
> >> On Tue, Nov 21, 2017 at 07:58:18PM +0100, Michael Niedermayer wrote: 
> >>> On Sat, Nov 18, 2017 at 09:11:17PM +0100, Michael Niedermayer wrote: 
>  On Sat, Nov 18, 2017 at 09:50:33AM +0100, Hendrik Leppkes wrote: 
> > On Sat, Nov 18, 2017 at 3:05 AM, Michael Niedermayer
> >  wrote: 
> >> On Fri, Nov 17, 2017 at 09:55:47AM +0100, Hendrik Leppkes wrote: 
> >>> On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
> >>>  wrote: 
>  On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote: 
> > 2017-11-16 13:44 GMT+01:00 Michael Niedermayer : 
> >> On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote: 
> >>> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer : 
>  Hi all

> 
>  I intend to make 3.4.1 very soon 
> >>>
> >>> Shouldn't we first decide on how to proceed with #6775? 
> >>

> >> This would be ideal.
> >>
> >> IIUC this is a regression from bddb2343b6e594e312dadb5d21b408702929ae04 
> >

> > This was confirmed by more than one developer, yes.
> > 
> >> I see a patch that is said to improve 6775, can that be applied and
> >> would that resolve this ? 
> >

> > Iiuc, it would not completely resolve the issue, see:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
> > 
> >> If so why was it not applied yet ? 
> >

> > The patch did not get support here, see:
> > [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after 
EOF
> > in compat_decode 
> 

> 
>  Is someone working on fixing this better than with the available 
patch ?
>  
> >>>
> >>> I don't even agree this needs fixing. Those projects use the API wrong. 
> >>

> >> Had we documented the correct/wrong use precissely in the past when
> >> these wrong uses where written ?
> >>
> >> Because if it was documented then few should have made the mistake.
> >> But it seems this affects multiple projects, so i wonder if our API
> >> really excluded the use
> >> 
> >

> > Apparently not well enough, but I also don't even understand why you
> > would *want* to drain in the middle of decoding.
> >
> > The only mention of sending NULL/0 packets (in 3.0 docs, before the
> > new API was introduced) do include the "at the end", however.
> >
> > From CODEC_CAP_DELAY:
> >  * Decoders:
> >  * The decoder has a non-zero delay and needs to be fed with 
avpkt->data=NULL,
> >  * avpkt->size=0 at the end to get the delayed data until the decoder 
no longer
> >  * returns frames.
> >
> > From avcodec_decode_video2
> > * @note Codecs which have the AV_CODEC_CAP_DELAY capability set have a 
delay
> > * between input and output, these need to be fed with avpkt->data=NULL,
> > * avpkt->size=0 at the end to return the remaining frames.
> >
> > There is a few more mentions of the same concept, but as far as I can
> > see all include the key words "at the end".
> > 
>  
> > For the suggested patch, draining and flushing in the middle of a

> > bitstream is still going to result in problems, though, since it
> > removes all reference frames, for example.
> > The original behavior cannot really be stored, which was to just keep
> > feeding frames into the decoder after a drain without a flush.
> > However, some decoders actually crashed when you did this, so this was
> > a rather unsafe action to begin with (not an issue any longer, since
> > this pattern is now blocked). 
> 

>  Did the previous code really work if the frame after a flush was not a
>  new keyframe or there was some use of previous references ? 
> >>>

> >>> ping
> >>>
> >>> so what is the status of this?
> >>>
> >>> Ticket 6775 is still open, neither a workaround was applied nor was
> >>> it closed as invalid. Only one workaround was proposed which was
> >>> claimed to be worse than the code before.
> >>> It seems the discussion died down.
> >>> If theres no activity on this in the next days then i intend to make
> >>> the release with whats in release/3.4 at the time. I dont think
> >>> blind waiting will do any good, id rather release early and often ...
> >>>
> >>> Also if someone wants to write some release notes about this issue,
> >>> that is IMO a good idea ... 
> >>

> >> So this code is completely 

Re: [FFmpeg-devel] FFmpeg 3.4.1

[wm4]

On Fri, 8 Dec 2017 06:52:20 +0100
Michael Niedermayer  wrote:

> On Fri, Dec 08, 2017 at 01:09:50AM -0300, James Almer wrote:
> > On 12/8/2017 12:26 AM, wm4 wrote:  
> > > On Thu, 7 Dec 2017 23:23:51 +0100
> > > Michael Niedermayer  wrote:
> > >   
> > >> On Tue, Nov 21, 2017 at 07:58:18PM +0100, Michael Niedermayer wrote:  
> > >>> On Sat, Nov 18, 2017 at 09:11:17PM +0100, Michael Niedermayer wrote:
> >  On Sat, Nov 18, 2017 at 09:50:33AM +0100, Hendrik Leppkes wrote:
> > > On Sat, Nov 18, 2017 at 3:05 AM, Michael Niedermayer
> > >  wrote:
> > >> On Fri, Nov 17, 2017 at 09:55:47AM +0100, Hendrik Leppkes wrote:
> > >>> On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
> > >>>  wrote:
> >  On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:  
> >    
> > > 2017-11-16 13:44 GMT+01:00 Michael Niedermayer 
> > > :
> > >> On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos 
> > >> wrote:
> > >>> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer 
> > >>> :
> >  Hi all
> > 
> >  I intend to make 3.4.1 very soon
> > >>>
> > >>> Shouldn't we first decide on how to proceed with #6775?
> > >>
> > >> This would be ideal.
> > >>
> > >> IIUC this is a regression from 
> > >> bddb2343b6e594e312dadb5d21b408702929ae04
> > >
> > > This was confirmed by more than one developer, yes.
> > >
> > >> I see a patch that is said to improve 6775, can that be applied 
> > >> and
> > >> would that resolve this ?
> > >
> > > Iiuc, it would not completely resolve the issue, see:
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
> > >
> > >> If so why was it not applied yet ?
> > >
> > > The patch did not get support here, see:
> > > [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet 
> > > after EOF
> > > in compat_decode
> > 
> > 
> >  Is someone working on fixing this better than with the available 
> >  patch ?
> > 
> > >>>
> > >>> I don't even agree this needs fixing. Those projects use the API 
> > >>> wrong.
> > >>
> > >> Had we documented the correct/wrong use precissely in the past when
> > >> these wrong uses where written ?
> > >>
> > >> Because if it was documented then few should have made the mistake.
> > >> But it seems this affects multiple projects, so i wonder if our API
> > >> really excluded the use
> > >>
> > >
> > > Apparently not well enough, but I also don't even understand why you
> > > would *want* to drain in the middle of decoding.
> > >
> > > The only mention of sending NULL/0 packets (in 3.0 docs, before the
> > > new API was introduced) do include the "at the end", however.
> > >
> > > From CODEC_CAP_DELAY:
> > >  * Decoders:
> > >  * The decoder has a non-zero delay and needs to be fed with 
> > > avpkt->data=NULL,
> > >  * avpkt->size=0 at the end to get the delayed data until the decoder 
> > > no longer
> > >  * returns frames.
> > >
> > > From avcodec_decode_video2
> > > * @note Codecs which have the AV_CODEC_CAP_DELAY capability set have 
> > > a delay
> > > * between input and output, these need to be fed with 
> > > avpkt->data=NULL,
> > > * avpkt->size=0 at the end to return the remaining frames.
> > >
> > > There is a few more mentions of the same concept, but as far as I can
> > > see all include the key words "at the end".
> > > 
> >  
> > > For the suggested patch, draining and flushing in the middle of a
> > > bitstream is still going to result in problems, though, since it
> > > removes all reference frames, for example.
> > > The original behavior cannot really be stored, which was to just keep
> > > feeding frames into the decoder after a drain without a flush.
> > > However, some decoders actually crashed when you did this, so this was
> > > a rather unsafe action to begin with (not an issue any longer, since
> > > this pattern is now blocked).
> > 
> >  Did the previous code really work if the frame after a flush was not a
> >  new keyframe or there was some use of previous references ?
> > >>>
> > >>> ping
> > >>>
> > >>> so what is the status of this?
> > >>>
> > >>> Ticket 6775 is still open, neither a workaround was applied nor was
> > >>> it closed as invalid. Only one workaround was proposed which was
> > >>> claimed to be worse than the code before.
> > >>> It seems the 

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Michael Niedermayer]

On Fri, Dec 08, 2017 at 01:09:50AM -0300, James Almer wrote:
> On 12/8/2017 12:26 AM, wm4 wrote:
> > On Thu, 7 Dec 2017 23:23:51 +0100
> > Michael Niedermayer  wrote:
> > 
> >> On Tue, Nov 21, 2017 at 07:58:18PM +0100, Michael Niedermayer wrote:
> >>> On Sat, Nov 18, 2017 at 09:11:17PM +0100, Michael Niedermayer wrote:  
>  On Sat, Nov 18, 2017 at 09:50:33AM +0100, Hendrik Leppkes wrote:  
> > On Sat, Nov 18, 2017 at 3:05 AM, Michael Niedermayer
> >  wrote:  
> >> On Fri, Nov 17, 2017 at 09:55:47AM +0100, Hendrik Leppkes wrote:  
> >>> On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
> >>>  wrote:  
>  On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:  
> > 2017-11-16 13:44 GMT+01:00 Michael Niedermayer 
> > :  
> >> On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:  
> >>> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer 
> >>> :  
>  Hi all
> 
>  I intend to make 3.4.1 very soon  
> >>>
> >>> Shouldn't we first decide on how to proceed with #6775?  
> >>
> >> This would be ideal.
> >>
> >> IIUC this is a regression from 
> >> bddb2343b6e594e312dadb5d21b408702929ae04  
> >
> > This was confirmed by more than one developer, yes.
> >  
> >> I see a patch that is said to improve 6775, can that be applied and
> >> would that resolve this ?  
> >
> > Iiuc, it would not completely resolve the issue, see:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
> >  
> >> If so why was it not applied yet ?  
> >
> > The patch did not get support here, see:
> > [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after 
> > EOF
> > in compat_decode  
> 
> 
>  Is someone working on fixing this better than with the available 
>  patch ?
>   
> >>>
> >>> I don't even agree this needs fixing. Those projects use the API 
> >>> wrong.  
> >>
> >> Had we documented the correct/wrong use precissely in the past when
> >> these wrong uses where written ?
> >>
> >> Because if it was documented then few should have made the mistake.
> >> But it seems this affects multiple projects, so i wonder if our API
> >> really excluded the use
> >>  
> >
> > Apparently not well enough, but I also don't even understand why you
> > would *want* to drain in the middle of decoding.
> >
> > The only mention of sending NULL/0 packets (in 3.0 docs, before the
> > new API was introduced) do include the "at the end", however.
> >
> > From CODEC_CAP_DELAY:
> >  * Decoders:
> >  * The decoder has a non-zero delay and needs to be fed with 
> > avpkt->data=NULL,
> >  * avpkt->size=0 at the end to get the delayed data until the decoder 
> > no longer
> >  * returns frames.
> >
> > From avcodec_decode_video2
> > * @note Codecs which have the AV_CODEC_CAP_DELAY capability set have a 
> > delay
> > * between input and output, these need to be fed with avpkt->data=NULL,
> > * avpkt->size=0 at the end to return the remaining frames.
> >
> > There is a few more mentions of the same concept, but as far as I can
> > see all include the key words "at the end".
> >   
>    
> > For the suggested patch, draining and flushing in the middle of a
> > bitstream is still going to result in problems, though, since it
> > removes all reference frames, for example.
> > The original behavior cannot really be stored, which was to just keep
> > feeding frames into the decoder after a drain without a flush.
> > However, some decoders actually crashed when you did this, so this was
> > a rather unsafe action to begin with (not an issue any longer, since
> > this pattern is now blocked).  
> 
>  Did the previous code really work if the frame after a flush was not a
>  new keyframe or there was some use of previous references ?  
> >>>
> >>> ping
> >>>
> >>> so what is the status of this?
> >>>
> >>> Ticket 6775 is still open, neither a workaround was applied nor was
> >>> it closed as invalid. Only one workaround was proposed which was
> >>> claimed to be worse than the code before.
> >>> It seems the discussion died down.
> >>> If theres no activity on this in the next days then i intend to make
> >>> the release with whats in release/3.4 at the time. I dont think
> >>> blind waiting will do any good, id rather release early and often ...
> >>>
> >>> Also if someone wants to write some release notes about this issue,
> >>> that is IMO a good idea ...  
> >>
> >> So this code is completely unmaintained ?
> 

Re: [FFmpeg-devel] FFmpeg 3.4.1

[James Almer]

On 12/8/2017 1:33 AM, Carl Eugen Hoyos wrote:
> 2017-12-08 5:09 GMT+01:00 James Almer :
> 
>> When the old decode API was turned into a wrapper for the
>> new, some applications using said API this way started to
>> experience issues/crashes that did not happen before.
> 
> Where was a crash reported?
> 
> Carl Eugen

I said issues/crashes because i wasn't sure which kind was reported.
Looking at the ticket, i guess it was the former.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Carl Eugen Hoyos]

2017-12-08 5:09 GMT+01:00 James Almer :

> When the old decode API was turned into a wrapper for the
> new, some applications using said API this way started to
> experience issues/crashes that did not happen before.

Where was a crash reported?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.4.1

[James Almer]

On 12/8/2017 12:26 AM, wm4 wrote:
> On Thu, 7 Dec 2017 23:23:51 +0100
> Michael Niedermayer  wrote:
> 
>> On Tue, Nov 21, 2017 at 07:58:18PM +0100, Michael Niedermayer wrote:
>>> On Sat, Nov 18, 2017 at 09:11:17PM +0100, Michael Niedermayer wrote:  
 On Sat, Nov 18, 2017 at 09:50:33AM +0100, Hendrik Leppkes wrote:  
> On Sat, Nov 18, 2017 at 3:05 AM, Michael Niedermayer
>  wrote:  
>> On Fri, Nov 17, 2017 at 09:55:47AM +0100, Hendrik Leppkes wrote:  
>>> On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
>>>  wrote:  
 On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:  
> 2017-11-16 13:44 GMT+01:00 Michael Niedermayer 
> :  
>> On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:  
>>> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer 
>>> :  
 Hi all

 I intend to make 3.4.1 very soon  
>>>
>>> Shouldn't we first decide on how to proceed with #6775?  
>>
>> This would be ideal.
>>
>> IIUC this is a regression from 
>> bddb2343b6e594e312dadb5d21b408702929ae04  
>
> This was confirmed by more than one developer, yes.
>  
>> I see a patch that is said to improve 6775, can that be applied and
>> would that resolve this ?  
>
> Iiuc, it would not completely resolve the issue, see:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
>  
>> If so why was it not applied yet ?  
>
> The patch did not get support here, see:
> [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF
> in compat_decode  


 Is someone working on fixing this better than with the available patch 
 ?
  
>>>
>>> I don't even agree this needs fixing. Those projects use the API wrong. 
>>>  
>>
>> Had we documented the correct/wrong use precissely in the past when
>> these wrong uses where written ?
>>
>> Because if it was documented then few should have made the mistake.
>> But it seems this affects multiple projects, so i wonder if our API
>> really excluded the use
>>  
>
> Apparently not well enough, but I also don't even understand why you
> would *want* to drain in the middle of decoding.
>
> The only mention of sending NULL/0 packets (in 3.0 docs, before the
> new API was introduced) do include the "at the end", however.
>
> From CODEC_CAP_DELAY:
>  * Decoders:
>  * The decoder has a non-zero delay and needs to be fed with 
> avpkt->data=NULL,
>  * avpkt->size=0 at the end to get the delayed data until the decoder no 
> longer
>  * returns frames.
>
> From avcodec_decode_video2
> * @note Codecs which have the AV_CODEC_CAP_DELAY capability set have a 
> delay
> * between input and output, these need to be fed with avpkt->data=NULL,
> * avpkt->size=0 at the end to return the remaining frames.
>
> There is a few more mentions of the same concept, but as far as I can
> see all include the key words "at the end".
>   
   
> For the suggested patch, draining and flushing in the middle of a
> bitstream is still going to result in problems, though, since it
> removes all reference frames, for example.
> The original behavior cannot really be stored, which was to just keep
> feeding frames into the decoder after a drain without a flush.
> However, some decoders actually crashed when you did this, so this was
> a rather unsafe action to begin with (not an issue any longer, since
> this pattern is now blocked).  

 Did the previous code really work if the frame after a flush was not a
 new keyframe or there was some use of previous references ?  
>>>
>>> ping
>>>
>>> so what is the status of this?
>>>
>>> Ticket 6775 is still open, neither a workaround was applied nor was
>>> it closed as invalid. Only one workaround was proposed which was
>>> claimed to be worse than the code before.
>>> It seems the discussion died down.
>>> If theres no activity on this in the next days then i intend to make
>>> the release with whats in release/3.4 at the time. I dont think
>>> blind waiting will do any good, id rather release early and often ...
>>>
>>> Also if someone wants to write some release notes about this issue,
>>> that is IMO a good idea ...  
>>
>> So this code is completely unmaintained ?
>> Noone cares about pushing a workaround ?
>> Noone cares about closing the ticket as wont fix ?
>> Noone cares about explaining why neither should be done ?
>>
>> I intend to make the release tomorrow or as soon as i have time, we
>> have waited too long already. I can of course wait more if 

Re: [FFmpeg-devel] FFmpeg 3.4.1

[wm4]

On Thu, 7 Dec 2017 23:23:51 +0100
Michael Niedermayer  wrote:

> On Tue, Nov 21, 2017 at 07:58:18PM +0100, Michael Niedermayer wrote:
> > On Sat, Nov 18, 2017 at 09:11:17PM +0100, Michael Niedermayer wrote:  
> > > On Sat, Nov 18, 2017 at 09:50:33AM +0100, Hendrik Leppkes wrote:  
> > > > On Sat, Nov 18, 2017 at 3:05 AM, Michael Niedermayer
> > > >  wrote:  
> > > > > On Fri, Nov 17, 2017 at 09:55:47AM +0100, Hendrik Leppkes wrote:  
> > > > >> On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
> > > > >>  wrote:  
> > > > >> > On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:  
> > > > >> >> 2017-11-16 13:44 GMT+01:00 Michael Niedermayer 
> > > > >> >> :  
> > > > >> >> > On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos 
> > > > >> >> > wrote:  
> > > > >> >> >> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer 
> > > > >> >> >> :  
> > > > >> >> >> > Hi all
> > > > >> >> >> >
> > > > >> >> >> > I intend to make 3.4.1 very soon  
> > > > >> >> >>
> > > > >> >> >> Shouldn't we first decide on how to proceed with #6775?  
> > > > >> >> >
> > > > >> >> > This would be ideal.
> > > > >> >> >
> > > > >> >> > IIUC this is a regression from 
> > > > >> >> > bddb2343b6e594e312dadb5d21b408702929ae04  
> > > > >> >>
> > > > >> >> This was confirmed by more than one developer, yes.
> > > > >> >>  
> > > > >> >> > I see a patch that is said to improve 6775, can that be applied 
> > > > >> >> > and
> > > > >> >> > would that resolve this ?  
> > > > >> >>
> > > > >> >> Iiuc, it would not completely resolve the issue, see:
> > > > >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
> > > > >> >>  
> > > > >> >> > If so why was it not applied yet ?  
> > > > >> >>
> > > > >> >> The patch did not get support here, see:
> > > > >> >> [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet 
> > > > >> >> after EOF
> > > > >> >> in compat_decode  
> > > > >> >
> > > > >> >
> > > > >> > Is someone working on fixing this better than with the available 
> > > > >> > patch ?
> > > > >> >  
> > > > >>
> > > > >> I don't even agree this needs fixing. Those projects use the API 
> > > > >> wrong.  
> > > > >
> > > > > Had we documented the correct/wrong use precissely in the past when
> > > > > these wrong uses where written ?
> > > > >
> > > > > Because if it was documented then few should have made the mistake.
> > > > > But it seems this affects multiple projects, so i wonder if our API
> > > > > really excluded the use
> > > > >  
> > > > 
> > > > Apparently not well enough, but I also don't even understand why you
> > > > would *want* to drain in the middle of decoding.
> > > > 
> > > > The only mention of sending NULL/0 packets (in 3.0 docs, before the
> > > > new API was introduced) do include the "at the end", however.
> > > > 
> > > > From CODEC_CAP_DELAY:
> > > >  * Decoders:
> > > >  * The decoder has a non-zero delay and needs to be fed with 
> > > > avpkt->data=NULL,
> > > >  * avpkt->size=0 at the end to get the delayed data until the decoder 
> > > > no longer
> > > >  * returns frames.
> > > > 
> > > > From avcodec_decode_video2
> > > > * @note Codecs which have the AV_CODEC_CAP_DELAY capability set have a 
> > > > delay
> > > > * between input and output, these need to be fed with avpkt->data=NULL,
> > > > * avpkt->size=0 at the end to return the remaining frames.
> > > > 
> > > > There is a few more mentions of the same concept, but as far as I can
> > > > see all include the key words "at the end".
> > > >   
> > >   
> > > > For the suggested patch, draining and flushing in the middle of a
> > > > bitstream is still going to result in problems, though, since it
> > > > removes all reference frames, for example.
> > > > The original behavior cannot really be stored, which was to just keep
> > > > feeding frames into the decoder after a drain without a flush.
> > > > However, some decoders actually crashed when you did this, so this was
> > > > a rather unsafe action to begin with (not an issue any longer, since
> > > > this pattern is now blocked).  
> > > 
> > > Did the previous code really work if the frame after a flush was not a
> > > new keyframe or there was some use of previous references ?  
> > 
> > ping
> > 
> > so what is the status of this?
> > 
> > Ticket 6775 is still open, neither a workaround was applied nor was
> > it closed as invalid. Only one workaround was proposed which was
> > claimed to be worse than the code before.
> > It seems the discussion died down.
> > If theres no activity on this in the next days then i intend to make
> > the release with whats in release/3.4 at the time. I dont think
> > blind waiting will do any good, id rather release early and often ...
> > 
> > Also if someone wants to write some release notes about this issue,
> > that is IMO a good idea ...  
> 
> So this code is completely unmaintained ?
> Noone 

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Michael Niedermayer]

On Tue, Nov 21, 2017 at 07:58:18PM +0100, Michael Niedermayer wrote:
> On Sat, Nov 18, 2017 at 09:11:17PM +0100, Michael Niedermayer wrote:
> > On Sat, Nov 18, 2017 at 09:50:33AM +0100, Hendrik Leppkes wrote:
> > > On Sat, Nov 18, 2017 at 3:05 AM, Michael Niedermayer
> > >  wrote:
> > > > On Fri, Nov 17, 2017 at 09:55:47AM +0100, Hendrik Leppkes wrote:
> > > >> On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
> > > >>  wrote:
> > > >> > On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:
> > > >> >> 2017-11-16 13:44 GMT+01:00 Michael Niedermayer 
> > > >> >> :
> > > >> >> > On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:
> > > >> >> >> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer 
> > > >> >> >> :
> > > >> >> >> > Hi all
> > > >> >> >> >
> > > >> >> >> > I intend to make 3.4.1 very soon
> > > >> >> >>
> > > >> >> >> Shouldn't we first decide on how to proceed with #6775?
> > > >> >> >
> > > >> >> > This would be ideal.
> > > >> >> >
> > > >> >> > IIUC this is a regression from 
> > > >> >> > bddb2343b6e594e312dadb5d21b408702929ae04
> > > >> >>
> > > >> >> This was confirmed by more than one developer, yes.
> > > >> >>
> > > >> >> > I see a patch that is said to improve 6775, can that be applied 
> > > >> >> > and
> > > >> >> > would that resolve this ?
> > > >> >>
> > > >> >> Iiuc, it would not completely resolve the issue, see:
> > > >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
> > > >> >>
> > > >> >> > If so why was it not applied yet ?
> > > >> >>
> > > >> >> The patch did not get support here, see:
> > > >> >> [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after 
> > > >> >> EOF
> > > >> >> in compat_decode
> > > >> >
> > > >> >
> > > >> > Is someone working on fixing this better than with the available 
> > > >> > patch ?
> > > >> >
> > > >>
> > > >> I don't even agree this needs fixing. Those projects use the API wrong.
> > > >
> > > > Had we documented the correct/wrong use precissely in the past when
> > > > these wrong uses where written ?
> > > >
> > > > Because if it was documented then few should have made the mistake.
> > > > But it seems this affects multiple projects, so i wonder if our API
> > > > really excluded the use
> > > >
> > > 
> > > Apparently not well enough, but I also don't even understand why you
> > > would *want* to drain in the middle of decoding.
> > > 
> > > The only mention of sending NULL/0 packets (in 3.0 docs, before the
> > > new API was introduced) do include the "at the end", however.
> > > 
> > > From CODEC_CAP_DELAY:
> > >  * Decoders:
> > >  * The decoder has a non-zero delay and needs to be fed with 
> > > avpkt->data=NULL,
> > >  * avpkt->size=0 at the end to get the delayed data until the decoder no 
> > > longer
> > >  * returns frames.
> > > 
> > > From avcodec_decode_video2
> > > * @note Codecs which have the AV_CODEC_CAP_DELAY capability set have a 
> > > delay
> > > * between input and output, these need to be fed with avpkt->data=NULL,
> > > * avpkt->size=0 at the end to return the remaining frames.
> > > 
> > > There is a few more mentions of the same concept, but as far as I can
> > > see all include the key words "at the end".
> > > 
> > 
> > > For the suggested patch, draining and flushing in the middle of a
> > > bitstream is still going to result in problems, though, since it
> > > removes all reference frames, for example.
> > > The original behavior cannot really be stored, which was to just keep
> > > feeding frames into the decoder after a drain without a flush.
> > > However, some decoders actually crashed when you did this, so this was
> > > a rather unsafe action to begin with (not an issue any longer, since
> > > this pattern is now blocked).
> > 
> > Did the previous code really work if the frame after a flush was not a
> > new keyframe or there was some use of previous references ?
> 
> ping
> 
> so what is the status of this?
> 
> Ticket 6775 is still open, neither a workaround was applied nor was
> it closed as invalid. Only one workaround was proposed which was
> claimed to be worse than the code before.
> It seems the discussion died down.
> If theres no activity on this in the next days then i intend to make
> the release with whats in release/3.4 at the time. I dont think
> blind waiting will do any good, id rather release early and often ...
> 
> Also if someone wants to write some release notes about this issue,
> that is IMO a good idea ...

So this code is completely unmaintained ?
Noone cares about pushing a workaround ?
Noone cares about closing the ticket as wont fix ?
Noone cares about explaining why neither should be done ?

I intend to make the release tomorrow or as soon as i have time, we
have waited too long already. I can of course wait more if people want
but then please have a plan on resolving the issue that the release is
delayed for

Thanks

[...]

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Michael Niedermayer]

On Sat, Nov 18, 2017 at 09:11:17PM +0100, Michael Niedermayer wrote:
> On Sat, Nov 18, 2017 at 09:50:33AM +0100, Hendrik Leppkes wrote:
> > On Sat, Nov 18, 2017 at 3:05 AM, Michael Niedermayer
> >  wrote:
> > > On Fri, Nov 17, 2017 at 09:55:47AM +0100, Hendrik Leppkes wrote:
> > >> On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
> > >>  wrote:
> > >> > On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:
> > >> >> 2017-11-16 13:44 GMT+01:00 Michael Niedermayer 
> > >> >> :
> > >> >> > On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:
> > >> >> >> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer 
> > >> >> >> :
> > >> >> >> > Hi all
> > >> >> >> >
> > >> >> >> > I intend to make 3.4.1 very soon
> > >> >> >>
> > >> >> >> Shouldn't we first decide on how to proceed with #6775?
> > >> >> >
> > >> >> > This would be ideal.
> > >> >> >
> > >> >> > IIUC this is a regression from 
> > >> >> > bddb2343b6e594e312dadb5d21b408702929ae04
> > >> >>
> > >> >> This was confirmed by more than one developer, yes.
> > >> >>
> > >> >> > I see a patch that is said to improve 6775, can that be applied and
> > >> >> > would that resolve this ?
> > >> >>
> > >> >> Iiuc, it would not completely resolve the issue, see:
> > >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
> > >> >>
> > >> >> > If so why was it not applied yet ?
> > >> >>
> > >> >> The patch did not get support here, see:
> > >> >> [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF
> > >> >> in compat_decode
> > >> >
> > >> >
> > >> > Is someone working on fixing this better than with the available patch 
> > >> > ?
> > >> >
> > >>
> > >> I don't even agree this needs fixing. Those projects use the API wrong.
> > >
> > > Had we documented the correct/wrong use precissely in the past when
> > > these wrong uses where written ?
> > >
> > > Because if it was documented then few should have made the mistake.
> > > But it seems this affects multiple projects, so i wonder if our API
> > > really excluded the use
> > >
> > 
> > Apparently not well enough, but I also don't even understand why you
> > would *want* to drain in the middle of decoding.
> > 
> > The only mention of sending NULL/0 packets (in 3.0 docs, before the
> > new API was introduced) do include the "at the end", however.
> > 
> > From CODEC_CAP_DELAY:
> >  * Decoders:
> >  * The decoder has a non-zero delay and needs to be fed with 
> > avpkt->data=NULL,
> >  * avpkt->size=0 at the end to get the delayed data until the decoder no 
> > longer
> >  * returns frames.
> > 
> > From avcodec_decode_video2
> > * @note Codecs which have the AV_CODEC_CAP_DELAY capability set have a delay
> > * between input and output, these need to be fed with avpkt->data=NULL,
> > * avpkt->size=0 at the end to return the remaining frames.
> > 
> > There is a few more mentions of the same concept, but as far as I can
> > see all include the key words "at the end".
> > 
> 
> > For the suggested patch, draining and flushing in the middle of a
> > bitstream is still going to result in problems, though, since it
> > removes all reference frames, for example.
> > The original behavior cannot really be stored, which was to just keep
> > feeding frames into the decoder after a drain without a flush.
> > However, some decoders actually crashed when you did this, so this was
> > a rather unsafe action to begin with (not an issue any longer, since
> > this pattern is now blocked).
> 
> Did the previous code really work if the frame after a flush was not a
> new keyframe or there was some use of previous references ?

ping

so what is the status of this?

Ticket 6775 is still open, neither a workaround was applied nor was
it closed as invalid. Only one workaround was proposed which was
claimed to be worse than the code before.
It seems the discussion died down.
If theres no activity on this in the next days then i intend to make
the release with whats in release/3.4 at the time. I dont think
blind waiting will do any good, id rather release early and often ...

Also if someone wants to write some release notes about this issue,
that is IMO a good idea ...

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Michael Niedermayer]

On Sat, Nov 18, 2017 at 09:50:33AM +0100, Hendrik Leppkes wrote:
> On Sat, Nov 18, 2017 at 3:05 AM, Michael Niedermayer
>  wrote:
> > On Fri, Nov 17, 2017 at 09:55:47AM +0100, Hendrik Leppkes wrote:
> >> On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
> >>  wrote:
> >> > On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:
> >> >> 2017-11-16 13:44 GMT+01:00 Michael Niedermayer :
> >> >> > On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:
> >> >> >> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer 
> >> >> >> :
> >> >> >> > Hi all
> >> >> >> >
> >> >> >> > I intend to make 3.4.1 very soon
> >> >> >>
> >> >> >> Shouldn't we first decide on how to proceed with #6775?
> >> >> >
> >> >> > This would be ideal.
> >> >> >
> >> >> > IIUC this is a regression from 
> >> >> > bddb2343b6e594e312dadb5d21b408702929ae04
> >> >>
> >> >> This was confirmed by more than one developer, yes.
> >> >>
> >> >> > I see a patch that is said to improve 6775, can that be applied and
> >> >> > would that resolve this ?
> >> >>
> >> >> Iiuc, it would not completely resolve the issue, see:
> >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
> >> >>
> >> >> > If so why was it not applied yet ?
> >> >>
> >> >> The patch did not get support here, see:
> >> >> [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF
> >> >> in compat_decode
> >> >
> >> >
> >> > Is someone working on fixing this better than with the available patch ?
> >> >
> >>
> >> I don't even agree this needs fixing. Those projects use the API wrong.
> >
> > Had we documented the correct/wrong use precissely in the past when
> > these wrong uses where written ?
> >
> > Because if it was documented then few should have made the mistake.
> > But it seems this affects multiple projects, so i wonder if our API
> > really excluded the use
> >
> 
> Apparently not well enough, but I also don't even understand why you
> would *want* to drain in the middle of decoding.
> 
> The only mention of sending NULL/0 packets (in 3.0 docs, before the
> new API was introduced) do include the "at the end", however.
> 
> From CODEC_CAP_DELAY:
>  * Decoders:
>  * The decoder has a non-zero delay and needs to be fed with avpkt->data=NULL,
>  * avpkt->size=0 at the end to get the delayed data until the decoder no 
> longer
>  * returns frames.
> 
> From avcodec_decode_video2
> * @note Codecs which have the AV_CODEC_CAP_DELAY capability set have a delay
> * between input and output, these need to be fed with avpkt->data=NULL,
> * avpkt->size=0 at the end to return the remaining frames.
> 
> There is a few more mentions of the same concept, but as far as I can
> see all include the key words "at the end".
> 

> For the suggested patch, draining and flushing in the middle of a
> bitstream is still going to result in problems, though, since it
> removes all reference frames, for example.
> The original behavior cannot really be stored, which was to just keep
> feeding frames into the decoder after a drain without a flush.
> However, some decoders actually crashed when you did this, so this was
> a rather unsafe action to begin with (not an issue any longer, since
> this pattern is now blocked).

Did the previous code really work if the frame after a flush was not a
new keyframe or there was some use of previous references ?


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott



signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Hendrik Leppkes]

On Sat, Nov 18, 2017 at 3:05 AM, Michael Niedermayer
 wrote:
> On Fri, Nov 17, 2017 at 09:55:47AM +0100, Hendrik Leppkes wrote:
>> On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
>>  wrote:
>> > On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:
>> >> 2017-11-16 13:44 GMT+01:00 Michael Niedermayer :
>> >> > On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:
>> >> >> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer 
>> >> >> :
>> >> >> > Hi all
>> >> >> >
>> >> >> > I intend to make 3.4.1 very soon
>> >> >>
>> >> >> Shouldn't we first decide on how to proceed with #6775?
>> >> >
>> >> > This would be ideal.
>> >> >
>> >> > IIUC this is a regression from bddb2343b6e594e312dadb5d21b408702929ae04
>> >>
>> >> This was confirmed by more than one developer, yes.
>> >>
>> >> > I see a patch that is said to improve 6775, can that be applied and
>> >> > would that resolve this ?
>> >>
>> >> Iiuc, it would not completely resolve the issue, see:
>> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
>> >>
>> >> > If so why was it not applied yet ?
>> >>
>> >> The patch did not get support here, see:
>> >> [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF
>> >> in compat_decode
>> >
>> >
>> > Is someone working on fixing this better than with the available patch ?
>> >
>>
>> I don't even agree this needs fixing. Those projects use the API wrong.
>
> Had we documented the correct/wrong use precissely in the past when
> these wrong uses where written ?
>
> Because if it was documented then few should have made the mistake.
> But it seems this affects multiple projects, so i wonder if our API
> really excluded the use
>

Apparently not well enough, but I also don't even understand why you
would *want* to drain in the middle of decoding.

The only mention of sending NULL/0 packets (in 3.0 docs, before the
new API was introduced) do include the "at the end", however.

From CODEC_CAP_DELAY:
 * Decoders:
 * The decoder has a non-zero delay and needs to be fed with avpkt->data=NULL,
 * avpkt->size=0 at the end to get the delayed data until the decoder no longer
 * returns frames.

From avcodec_decode_video2
* @note Codecs which have the AV_CODEC_CAP_DELAY capability set have a delay
* between input and output, these need to be fed with avpkt->data=NULL,
* avpkt->size=0 at the end to return the remaining frames.

There is a few more mentions of the same concept, but as far as I can
see all include the key words "at the end".

For the suggested patch, draining and flushing in the middle of a
bitstream is still going to result in problems, though, since it
removes all reference frames, for example.
The original behavior cannot really be stored, which was to just keep
feeding frames into the decoder after a drain without a flush.
However, some decoders actually crashed when you did this, so this was
a rather unsafe action to begin with (not an issue any longer, since
this pattern is now blocked).

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Michael Niedermayer]

On Fri, Nov 17, 2017 at 09:55:47AM +0100, Hendrik Leppkes wrote:
> On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
>  wrote:
> > On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:
> >> 2017-11-16 13:44 GMT+01:00 Michael Niedermayer :
> >> > On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:
> >> >> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer :
> >> >> > Hi all
> >> >> >
> >> >> > I intend to make 3.4.1 very soon
> >> >>
> >> >> Shouldn't we first decide on how to proceed with #6775?
> >> >
> >> > This would be ideal.
> >> >
> >> > IIUC this is a regression from bddb2343b6e594e312dadb5d21b408702929ae04
> >>
> >> This was confirmed by more than one developer, yes.
> >>
> >> > I see a patch that is said to improve 6775, can that be applied and
> >> > would that resolve this ?
> >>
> >> Iiuc, it would not completely resolve the issue, see:
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
> >>
> >> > If so why was it not applied yet ?
> >>
> >> The patch did not get support here, see:
> >> [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF
> >> in compat_decode
> >
> >
> > Is someone working on fixing this better than with the available patch ?
> >
> 
> I don't even agree this needs fixing. Those projects use the API wrong.

Had we documented the correct/wrong use precissely in the past when
these wrong uses where written ?

Because if it was documented then few should have made the mistake.
But it seems this affects multiple projects, so i wonder if our API
really excluded the use


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Hendrik Leppkes]

On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
 wrote:
> On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:
>> 2017-11-16 13:44 GMT+01:00 Michael Niedermayer :
>> > On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:
>> >> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer :
>> >> > Hi all
>> >> >
>> >> > I intend to make 3.4.1 very soon
>> >>
>> >> Shouldn't we first decide on how to proceed with #6775?
>> >
>> > This would be ideal.
>> >
>> > IIUC this is a regression from bddb2343b6e594e312dadb5d21b408702929ae04
>>
>> This was confirmed by more than one developer, yes.
>>
>> > I see a patch that is said to improve 6775, can that be applied and
>> > would that resolve this ?
>>
>> Iiuc, it would not completely resolve the issue, see:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
>>
>> > If so why was it not applied yet ?
>>
>> The patch did not get support here, see:
>> [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF
>> in compat_decode
>
>
> Is someone working on fixing this better than with the available patch ?
>

I don't even agree this needs fixing. Those projects use the API wrong.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Michael Niedermayer]

On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:
> 2017-11-16 13:44 GMT+01:00 Michael Niedermayer :
> > On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:
> >> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer :
> >> > Hi all
> >> >
> >> > I intend to make 3.4.1 very soon
> >>
> >> Shouldn't we first decide on how to proceed with #6775?
> >
> > This would be ideal.
> >
> > IIUC this is a regression from bddb2343b6e594e312dadb5d21b408702929ae04
> 
> This was confirmed by more than one developer, yes.
> 
> > I see a patch that is said to improve 6775, can that be applied and
> > would that resolve this ?
> 
> Iiuc, it would not completely resolve the issue, see:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
> 
> > If so why was it not applied yet ?
> 
> The patch did not get support here, see:
> [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF
> in compat_decode


Is someone working on fixing this better than with the available patch ?

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Carl Eugen Hoyos]

2017-11-16 13:44 GMT+01:00 Michael Niedermayer :
> On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:
>> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer :
>> > Hi all
>> >
>> > I intend to make 3.4.1 very soon
>>
>> Shouldn't we first decide on how to proceed with #6775?
>
> This would be ideal.
>
> IIUC this is a regression from bddb2343b6e594e312dadb5d21b408702929ae04

This was confirmed by more than one developer, yes.

> I see a patch that is said to improve 6775, can that be applied and
> would that resolve this ?

Iiuc, it would not completely resolve the issue, see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536

> If so why was it not applied yet ?

The patch did not get support here, see:
[FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF
in compat_decode

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Michael Niedermayer]

On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:
> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer :
> > Hi all
> >
> > I intend to make 3.4.1 very soon
> 
> Shouldn't we first decide on how to proceed with #6775?

This would be ideal.

IIUC this is a regression from bddb2343b6e594e312dadb5d21b408702929ae04

I see a patch that is said to improve 6775, can that be applied and
would that resolve this ?
If so why was it not applied yet ?


Thanks

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Carl Eugen Hoyos]

2017-11-15 13:34 GMT+01:00 Michael Niedermayer :
> Hi all
>
> I intend to make 3.4.1 very soon

Shouldn't we first decide on how to proceed with #6775?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] FFmpeg 3.4.1

[Michael Niedermayer]

Hi all

I intend to make 3.4.1 very soon, if you want something in it, please
backport to release/3.4

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel