[uvch264src in 1.1.1.1] "Got data flow before segment event" warnings until crash

[Robert Krakora]

Hi Peter,

I did some work yesterday on this and enabled logging on uvcvideo.ko and
was able to correlate the buffer sizes reported by it and by the uvch264src
plugin.  Below is the frame that failed...the size in the kernel module was
the same as the size of the buffer once it got back up to the application
to v4l2src and uvch264src.

uvcvideo: Frame complete (EOF found).
uvcvideo: EOF in empty payload.
uvcvideo: uvc_v4l2_poll
uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)
uvcvideo: HD Pro Webcam C920: PTS 1029592232 y 2948.098587 SOF 2948.098587
(x1 2149480048 x2 2179588048 y1 193593344 y2 199426048 SOF offset 39)
uvcvideo: HD Pro Webcam C920: SOF 2948.098587 y 927116325 ts 589.071670 buf
ts 589.232519 (x1 197984256/205/906 x2 204537856/49/995 y1 1000000000 y2
1099975668)
uvcvideo: uvc_dequeue_buffer - buf->bytesused = 220410
uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)

Best Regards,

Rob


On Thu, Jul 25, 2013 at 12:22 PM, Peter Rennert <p.rennert at cs.ucl.ac.uk>wrote:

> A bit of an update today.
>
> To figure out what is going on normally and what is different in the
> diseased frame I printed out the debug line [line 508] that was already in
> the code, augmented with the total size of the buffer. The original line
> was:
>
> GST_DEBUG_OBJECT (self,
>           "Found APP4 marker (%d). JPG: %d-%d - APP4: %d - %d",
> segment_size,
>           last_offset, i, i, i + 2 + segment_size);
>
> I print for each time in the loop (before the sanity test that will fail
> finally):
>
> printf("Found APP4 marker (%d). JPG: %d-%d - APP4: %d - %d - size: %d\n",
> segment_size,
>           last_offset, i, i, i + 2 + segment_size, (int)size);
>
> What I get for a normal frame is about this. The total buffer size changes
> and also the size of the first APP4 chunk, however, I always seem to get 4
> blocks for each frame. The segment size of the first marker differs between
> the individual frames, while the 2nd, 3rd and 4th markers are the same size
> all the time as far as I can tell:
>
> Found APP4 marker (13010). JPG: 0-8 - APP4: 8 - 13020 - size: 166660
>
> Found APP4 marker (65533). JPG: 13020-13020 - APP4: 13020 - 78555 - size:
> 166660
>
> Found APP4 marker (65533). JPG: 78555-78555 - APP4: 78555 - 144090 -
> size: 166660
>
> Found APP4 marker (22566). JPG: 144090-144090 - APP4: 144090 - 166658 -
> size: 166660
>
>
> The frame that causes the failure of the system has the following output:
>
> Found APP4 marker (12084). JPG: 0-8 - APP4: 8 - 12094 - size: 165485
>
> Found APP4 marker (65533). JPG: 12094-12094 - APP4: 12094 - 77629 - size:
> 165485
>
> Found APP4 marker (65533). JPG: 77629-77629 - APP4: 77629 - 143164 - size:
> 165485
>
> Found APP4 marker (22566). JPG: 143164-143164 - APP4: 143164 - 165732 -
> size: 165485
>
>
> As you can see it seems as the last segment reaches out of the total size
> of the buffer. As the last segment seems to be always of a length 22566, I
> think for some reason (that does not happen in gstreamer 0.10) a piece of
> the h264 stream is missing in this particular buffer.
>
> The number of bytes getting lost is not the same for different trials,
> neither is the cut-off. For my second trial I got:
>
> Found APP4 marker (22566). JPG: 144796-144796 - APP4: 144796 - 167364 -
> size: 165815
>
> So where are these bytes? And why are they missing so regularly?
>
> ______________________________**_________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.**freedesktop.org<gstreamer-devel at lists.freedesktop.org>
> http://lists.freedesktop.org/**mailman/listinfo/gstreamer-**devel<http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel>
>



-- 
Rob Krakora
MessageNet Systems
101 East Carmel Dr. Suite 105
Carmel, IN 46032
(317)566-1677 Ext 212
(317)663-0808 Fax
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130725/239a2b9d/attachment.html>