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
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].
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
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
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:
>
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
