On 2019-03-18 23:26 +0100, Alexander Strasser wrote:
> On 2019-03-18 00:24 +0100, Nicolas George wrote:
> > Alexander Strasser (12019-03-18):
> > > I tested the EAGAIN version and it worked. I also tested returning a
> >
> > ffmpeg.c uses the non-blocking mode.
>
> That would explain it. I now
Hi Nicolas!
On 2019-03-18 00:24 +0100, Nicolas George wrote:
> Alexander Strasser (12019-03-18):
> > I tested the EAGAIN version and it worked. I also tested returning a
>
> ffmpeg.c uses the non-blocking mode.
That would explain it. I now tested, the FFERROR_REDO approach,
and I think it works
Alexander Strasser (12019-03-18):
> I tested the EAGAIN version and it worked. I also tested returning a
ffmpeg.c uses the non-blocking mode.
> zero-sized packet, like in the case where V4L flags the data as corrupt,
> that worked too. See commit 28f20d2ff487aa589643d8f70eaf614b78839685
>
> Do
On 2019-03-17 18:25 +0100, Nicolas George wrote:
> Alexander Strasser (12019-03-17):
> > I had found that when capturing video for some hours from
> > USB Camera-B4.09.24.1 (Manufacturer: OmniVision Technologies, Inc.),
> > sometimes when invoking the ioctl DQBUF, the returned buffer is not
> >
Alexander Strasser (12019-03-17):
> I had found that when capturing video for some hours from
> USB Camera-B4.09.24.1 (Manufacturer: OmniVision Technologies, Inc.),
> sometimes when invoking the ioctl DQBUF, the returned buffer is not
> filled with the size we expect for the raw video frame.
I had found that when capturing video for some hours from
USB Camera-B4.09.24.1 (Manufacturer: OmniVision Technologies, Inc.),
sometimes when invoking the ioctl DQBUF, the returned buffer is not
filled with the size we expect for the raw video frame.
Here are two examples for such occurrences:
