Re: [FFmpeg-devel] Log level of message "Increasing reorder buffer to ..."

2016-08-23 Thread Robert Krüger
On Tue, Aug 23, 2016 at 3:09 PM, Carl Eugen Hoyos 
wrote:

> Hi!
>
> 2016-08-04 13:50 GMT+02:00 Robert Krüger :
> > the log level of INFO does not seem appropriate for the message
> (h264dec.c,
>
> This should be fixed now: The level is below default now if the buffer
> is increased when decoding the first frame (nothing lost), the level
> is warning if the increasing happens later (lost frame).
>
> Thank you, Carl Eugen
>

Great, thanks a lot!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Log level of message "Increasing reorder buffer to ..."

2016-08-23 Thread Carl Eugen Hoyos
Hi!

2016-08-04 13:50 GMT+02:00 Robert Krüger :
> the log level of INFO does not seem appropriate for the message (h264dec.c,

This should be fixed now: The level is below default now if the buffer
is increased when decoding the first frame (nothing lost), the level
is warning if the increasing happens later (lost frame).

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


Re: [FFmpeg-devel] Log level of message "Increasing reorder buffer to ..."

2016-08-08 Thread Carl Eugen Hoyos
2016-08-04 14:41 GMT+02:00 Robert Krüger :
> On Thu, Aug 4, 2016 at 1:55 PM, Carl Eugen Hoyos  wrote:
>
>> 2016-08-04 13:50 GMT+02:00 Robert Krüger :
>> > the log level of INFO does not seem appropriate for the message
>> > (h264dec.c, line 531). If it is a condition that shouldn't really happen,
>> > it should be
>>
>> It does happen, see at least two related tickets iirc.
>
> Yes, of course, I am observing it all the time (see below). This was rather
> a (redundant) explanation what my understanding of the purpose of log level
> WARNING usually is. Our logs are full of this

That surprises me a little because I thought no public encoder produces
such streams - see my questions in the related tickets.

>> > a warning, otherwise it should be debug (especially for library
>> > users this floods the logs as this seems to happen for many files.
>> >
>> > Would a patch, setting this to DEBUG be accepted?
>>
>> I don't think so: It was intentionally increased to allow users to

(I am of course not the h264 maintainer.)

>> understand why libavcodec eat a frame.
>
> "Eats a frame" means what exactly? Does the decoder then miss a frame?

Yes, except if I misunderstand the issue.

> If so, I haven't observed this and need to check again as that would
> be serious. So far, I thought this warning was harmless.

I believe in most use cases, a dropped (B-) frame is harmless.

> If the library logging is designed for the command line then I can, of
> course, always patch locally. Just thought I'd ask to better understand.

I don't understand: Isn't this at most one warning per stream to inform
you about -strict 1? And don't you get many warnings for many kind
of streams (mpegts)?

> Do you remember the related tickets?

As git blame would have told you:
https://trac.ffmpeg.org/ticket/5138
https://trac.ffmpeg.org/ticket/5439

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


Re: [FFmpeg-devel] Log level of message "Increasing reorder buffer to ..."

2016-08-04 Thread Robert Krüger
On Thu, Aug 4, 2016 at 1:55 PM, Carl Eugen Hoyos  wrote:

> 2016-08-04 13:50 GMT+02:00 Robert Krüger :
> > the log level of INFO does not seem appropriate for the message
> (h264dec.c,
> > line 531). If it is a condition that shouldn't really happen, it should
> be
>
> It does happen, see at least two related tickets iirc.
>

Yes, of course, I am observing it all the time (see below). This was rather
a (redundant) explanation what my understanding of the purpose of log level
WARNING usually is. Our logs are full of this

>
> > a warning, otherwise it should be debug (especially for library users
> this
> > floods the logs as this seems to happen for many files.
> >
> > Would a patch, setting this to DEBUG be accepted?
>
> I don't think so: It was intentionally increased to allow users to
> understand
> why libavcodec eat a frame.
>

"Eats a frame" means what exactly? Does the decoder then miss a frame? If
so, I haven't observed this and need to check again as that would be
serious. So far, I thought this warning was harmless.

If the library logging is designed for the command line then I can, of
course, always patch locally. Just thought I'd ask to better understand. Do
you remember the related tickets?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Log level of message "Increasing reorder buffer to ..."

2016-08-04 Thread Carl Eugen Hoyos
2016-08-04 13:50 GMT+02:00 Robert Krüger :
> the log level of INFO does not seem appropriate for the message (h264dec.c,
> line 531). If it is a condition that shouldn't really happen, it should be

It does happen, see at least two related tickets iirc.

> a warning, otherwise it should be debug (especially for library users this
> floods the logs as this seems to happen for many files.
>
> Would a patch, setting this to DEBUG be accepted?

I don't think so: It was intentionally increased to allow users to understand
why libavcodec eat a frame.

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