Duplicate frames on one camera but not the other?

pisymbol . pisymbol at gmail.com
Wed Jul 24 22:08:30 UTC 2019


Btw, GST_DEBUG=4 leaves no clues:

0:01:36.957303020  4665      0x1480c50 INFO               baseparse
gstbaseparse.c:3985:gst_base_parse_set_latency:<h264parse0> min/max latency
0:00:00.033333333, 0:00:00.033333333
0:01:37.497142093  4665      0x1483770 INFO               baseparse
gstbaseparse.c:3985:gst_base_parse_set_latency:<h264parse1> min/max latency
0:00:00.033333333, 0:00:00.033333333
0:01:38.173694420  4665      0x1483770 INFO               baseparse
gstbaseparse.c:3985:gst_base_parse_set_latency:<h264parse1> min/max latency
0:00:00.033333333, 0:00:00.033333333
0:01:38.832638770  4665      0x1480c50 INFO               baseparse
gstbaseparse.c:3985:gst_base_parse_set_latency:<h264parse0> min/max latency
0:00:00.033333333, 0:00:00.033333333
0:01:39.560875744  4665      0x1480c50 INFO               baseparse
gstbaseparse.c:3985:gst_base_parse_set_latency:<h264parse0> min/max latency
0:00:00.033333333, 0:00:00.033333333
0:01:40.072591779  4665      0x1483770 INFO               baseparse
gstbaseparse.c:3985:gst_base_parse_set_latency:<h264parse1> min/max latency
0:00:00.033333333, 0:00:00.033333333
0:01:40.731023764  4665      0x1483770 INFO               baseparse
gstbaseparse.c:3985:gst_base_parse_set_latency:<h264parse1> min/max latency
0:00:00.033333333, 0:00:00.033333333
0:01:41.460566833  4665      0x1480c50 INFO               baseparse
gstbaseparse.c:3985:gst_base_parse_set_latency:<h264parse0> min/max latency
0:00:00.033333333, 0:00:00.033333333

-aps

On Wed, Jul 24, 2019 at 5:56 PM pisymbol . <pisymbol at gmail.com> wrote:

> My glorious pipeline;
>
> matroskamux name=muxer streamable=true ! multifilesink name=mfsink
> post-messages=true next-file=5 max-file-duration=\"{}\" location=\"{}\"
> nvcamerasrc queue-size=50 do-timestamp=true enable-meta=true
> fpsRange="30.0 30.0" auto-exposure=1 aeLock=true sensor_id=0 name=nvcam0 !
> queue ! identity name=tap0
> ! video/x-raw(memory:NVMM), width=(int)4104, height=(int)3046,
> format=(string)I420, framerate=(fraction)30/1
> ! nvvidconv flip-method=2 ! video/x-raw(memory:NVMM), width=(int)3840,
> height=(int)2160, format=(string)I420
> ! omxh264enc bitrate=30000000 ! video/x-h264,
> stream-format=(string)byte-stream ! h264parse ! muxer.video_0
> nvcamerasrc queue-size=50 do-timestamp=true enable-meta=true
> fpsRange="30.0 30.0" auto-exposure=1 aeLock=true sensor_id=1 name=nvcam1 !
> queue ! identity name=tap1
> ! video/x-raw(memory:NVMM), width=(int)4104, height=(int)3046,
> format=(string)I420, framerate=(fraction)30/1
> ! nvvidconv flip-method=2 ! video/x-raw(memory:NVMM), width=(int)3840,
> height=(int)2160, format=(string)I420
> ! omxh264enc bitrate=30000000 ! video/x-h264,
> stream-format=(string)byte-stream ! h264parse ! muxer.video_1
>
> Normally it's configured for minute intervals (max-file-duration etc.).
>
> Can someone speculate on why sensor_id=1's stream would be choppy on
> playback but sensor_id=0's is super smooth? Person is claiming that
> sensor_id=1 is getting duplicate frames in the stream while on sensor_id=0
> everything looks fine. And it's ALWAYS sensor_id=1 never 0.
>
> I don't see actual frame drops per se (i.e. my identity plugin is
> timestamping and looking at the hardware frame number). I can remove
> timestamping the sensor_id=1 stream but it still sees choppiness.
>
> Is this a clocking issue with the stream? I'm at a loss on why this would
> be and why always sensor_id=1???
>
> Cheers!
>
> -aps
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190724/1d19ebaf/attachment-0001.html>


More information about the gstreamer-devel mailing list