Re: [FFmpeg-devel] The log level of "co located POCs unavailable" should not be ERROR
On Sun, Mar 03, 2019 at 12:35:11PM +0800, Yukun Guo wrote: > On Sun, 3 Mar 2019 at 00:41, Michael Niedermayer wrote: > > > If the frame is copied, its copy would be at a different point in > > time so it may need a different poc and simply copying it might > > cause issues > > Sorry I didn't state it clearly. What I meant is POC = previous POC + > 2, not copied [1]. This is correct, since the frame is missing you > don't have better choices. I just wonder why not set field_poc? If I > add these two lines: > > h->short_ref[0]->field_poc[0] = prev->field_poc[0] + 2; > h->short_ref[0]->field_poc[1] = prev->field_poc[1] + 2; setting field_poc to a "best effort" value should be better than not setting it, yes [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] The log level of "co located POCs unavailable" should not be ERROR
On Sun, 3 Mar 2019 at 00:41, Michael Niedermayer wrote: > If the frame is copied, its copy would be at a different point in > time so it may need a different poc and simply copying it might > cause issues Sorry I didn't state it clearly. What I meant is POC = previous POC + 2, not copied [1]. This is correct, since the frame is missing you don't have better choices. I just wonder why not set field_poc? If I add these two lines: h->short_ref[0]->field_poc[0] = prev->field_poc[0] + 2; h->short_ref[0]->field_poc[1] = prev->field_poc[1] + 2; I find the error message is gone (only test videos that use frame coding throughout). [1]: https://github.com/FFmpeg/FFmpeg/blob/n4.1.1/libavcodec/h264_slice.c#L1599) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] The log level of "co located POCs unavailable" should not be ERROR
On Sat, Mar 02, 2019 at 01:23:17PM +0800, Yukun Guo wrote: > On Fri, 1 Mar 2019 at 05:30, Michael Niedermayer wrote: > > When data is missing (in live streaming or otherwise) it under > > almost all cases cannot be losslessly recovered. So this use matches > > the definition > > Yes, this is reasonable. But then "Frame num gap" should be of ERROR > level too. H.264 standard states if there is a frame num gap, the > decoder should infer an unintentional loss of pictures, assuming > gaps_in_frame_num_value_allowed_flag = 0. But it is possible that > FFmpeg encounters a frame loss but does not print any error messages, > because the error concealment procedure > (https://github.com/FFmpeg/FFmpeg/blob/n4.1.1/libavcodec/h264_slice.c#L1577) > will clone the previous frame in place of the missing one. Yes, if this ends up not printing anything then that would be unexpected > > Also, regarding to the error concealment, why isn't > `short_ref[0].field_poc` copied for cloned frames? The unset field_poc > causes "co located POCs unavailable" error, despite > `ref_list[1][0].poc` is valid when doing spatial direct predition. If the frame is copied, its copy would be at a different point in time so it may need a different poc and simply copying it might cause issues thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Take away the freedom of one citizen and you will be jailed, take away the freedom of all citizens and you will be congratulated by your peers in Parliament. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] The log level of "co located POCs unavailable" should not be ERROR
On Fri, 1 Mar 2019 at 05:30, Michael Niedermayer wrote: > When data is missing (in live streaming or otherwise) it under > almost all cases cannot be losslessly recovered. So this use matches > the definition Yes, this is reasonable. But then "Frame num gap" should be of ERROR level too. H.264 standard states if there is a frame num gap, the decoder should infer an unintentional loss of pictures, assuming gaps_in_frame_num_value_allowed_flag = 0. But it is possible that FFmpeg encounters a frame loss but does not print any error messages, because the error concealment procedure (https://github.com/FFmpeg/FFmpeg/blob/n4.1.1/libavcodec/h264_slice.c#L1577) will clone the previous frame in place of the missing one. Also, regarding to the error concealment, why isn't `short_ref[0].field_poc` copied for cloned frames? The unset field_poc causes "co located POCs unavailable" error, despite `ref_list[1][0].poc` is valid when doing spatial direct predition. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] The log level of "co located POCs unavailable" should not be ERROR
On Thu, Feb 28, 2019 at 11:33:50AM +0800, Yukun Guo wrote: > The error message "co located POCs unavailable" is reported when the > co-located picture of an H.264 B frame is missing during spatial direct > predition. It comes from this line: > https://github.com/FFmpeg/FFmpeg/blob/n4.1.1/libavcodec/h264_direct.c#L156 > and was originally commited for solving an issue found by fuzzing: > https://bugzilla.mozilla.org/show_bug.cgi?id=1230286. > > I think the condition is quite normal for live streaming, 1) when the > player first connects to the streaming server, it may receive B frames > whose reference frames have never been sent; 2) when the bandwidth is > limited, the server purposely drops packets due to buffer overflow. > IMHO the log level should be on par with "Frame num gap" (if > `gaps_in_frame_num_value_allowed_flag` is false) and "no picture" > (both are found in h264_slice.c and use DEBUG level). /** * Something went wrong and cannot losslessly be recovered. * However, not all future data is affected. */ #define AV_LOG_ERROR16 When data is missing (in live streaming or otherwise) it under almost all cases cannot be losslessly recovered. So this use matches the definition [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] The log level of "co located POCs unavailable" should not be ERROR
The error message "co located POCs unavailable" is reported when the co-located picture of an H.264 B frame is missing during spatial direct predition. It comes from this line: https://github.com/FFmpeg/FFmpeg/blob/n4.1.1/libavcodec/h264_direct.c#L156 and was originally commited for solving an issue found by fuzzing: https://bugzilla.mozilla.org/show_bug.cgi?id=1230286. I think the condition is quite normal for live streaming, 1) when the player first connects to the streaming server, it may receive B frames whose reference frames have never been sent; 2) when the bandwidth is limited, the server purposely drops packets due to buffer overflow. IMHO the log level should be on par with "Frame num gap" (if `gaps_in_frame_num_value_allowed_flag` is false) and "no picture" (both are found in h264_slice.c and use DEBUG level). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
