Unseekable mkv when recording MJPEG from V4L

[Daniel Gnoutcheff]

I have a few USB uvcvideo devices capable of generating MJPEG video. I'd
like to dump video from these devices and, if possible, avoid burning
CPU cycles on transcoding.

If I run this:

  gst-launch-1.0 -e v4l2src device=/dev/video1 ! image/jpeg ! \
    matroskamux ! filesink location=camera.mkv

... I get a pipeline that runs, and I can even play back the resulting
file.  However, none of the media players I tried are able to seek
properly.  If I try to seek forward in gst123, it hangs and spins CPU
until I kill -9 it.  VLC hangs for several seconds and squawks:

> [00007eff80000178] clock decoder error: Timestamp conversion failed (delay 300000, buffering 100000, bound 9000000)
> [00007eff80000178] core decoder error: Could not convert timestamp 1060486159

... while mpv just quits with:

> [mkv] no target for seek found
> [mkv] Corrupt file detected. Trying to resync starting from position 36816083...
> (...) V: 00:00:09 / 00:01:36 (10%)
> [mkv] Cluster found at 214146677.
> (...) V: 00:00:09 / 00:01:36 (10%)
>
>
> Exiting... (End of file)

However, if I add a "jpegdec ! jpegenc" to the pipeline:

  gst-launch-1.0 -e v4l2src device=/dev/video1 ! image/jpeg ! \
    jpegdec ! jpegenc ! \
    matroskamux ! filesink location=camera.re-encoded.mkv

... then all of those errors disappear.

I'm quite puzzled.  I thought that "seekability" was a muxer concern, so
I'd think that the JPEG decode-encode cycle would be a (expensive)
no-op.  What's wrong with this pipeline, and what on earth is "jpegdec !
jpegenc" doing to fix it?

I've reproduced this behavior on two uvcvideo devices (my laptop's
camera and an HDMI grabber).  I'm running Debian stretch, with gstreamer
1.10.4, gstreamer-plugins-good 1.10.4, gst123 0.3.3, mpv 0.23.0, and VLC
2.2.6 (all as shipped from Debian).

Thanks,
Daniel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Which GStreamer version is this ? There was a recent fix in v4l2src that fixes jpeg buffer to be marked as keyframes. The index in matroskamux is set to point to keyframes (media agnostic code). This is fixed in 1.12.3 stable release.

https://bugzilla.gnome.org/show_bug.cgi?id=785990

Le 12 oct. 2017 3:30 PM, "Daniel Gnoutcheff" <[hidden email]> a écrit :

I have a few USB uvcvideo devices capable of generating MJPEG video. I'd
like to dump video from these devices and, if possible, avoid burning
CPU cycles on transcoding.

If I run this:

  gst-launch-1.0 -e v4l2src device=/dev/video1 ! image/jpeg ! \
    matroskamux ! filesink location=camera.mkv

... I get a pipeline that runs, and I can even play back the resulting
file.  However, none of the media players I tried are able to seek
properly.  If I try to seek forward in gst123, it hangs and spins CPU
until I kill -9 it.  VLC hangs for several seconds and squawks:

> [00007eff80000178] clock decoder error: Timestamp conversion failed (delay 300000, buffering 100000, bound 9000000)
> [00007eff80000178] core decoder error: Could not convert timestamp 1060486159

... while mpv just quits with:

> [mkv] no target for seek found
> [mkv] Corrupt file detected. Trying to resync starting from position 36816083...
> (...) V: 00:00:09 / 00:01:36 (10%)
> [mkv] Cluster found at 214146677.
> (...) V: 00:00:09 / 00:01:36 (10%)
>
>
> Exiting... (End of file)

However, if I add a "jpegdec ! jpegenc" to the pipeline:

  gst-launch-1.0 -e v4l2src device=/dev/video1 ! image/jpeg ! \
    jpegdec ! jpegenc ! \
    matroskamux ! filesink location=camera.re-encoded.mkv

... then all of those errors disappear.

I'm quite puzzled.  I thought that "seekability" was a muxer concern, so
I'd think that the JPEG decode-encode cycle would be a (expensive)
no-op.  What's wrong with this pipeline, and what on earth is "jpegdec !
jpegenc" doing to fix it?

I've reproduced this behavior on two uvcvideo devices (my laptop's
camera and an HDMI grabber).  I'm running Debian stretch, with gstreamer
1.10.4, gstreamer-plugins-good 1.10.4, gst123 0.3.3, mpv 0.23.0, and VLC
2.2.6 (all as shipped from Debian).

Thanks,
Daniel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Daniel Gnoutcheff]

On 10/12/2017 07:51 PM, Nicolas Dufresne wrote:>
https://bugzilla.gnome.org/show_bug.cgi?id=785990

That was it exactly.  I was on gstreamer 1.10.4.  Upgrading to 1.12.3
fixed my problem.

Thanks much!


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le vendredi 13 octobre 2017 à 12:00 -0400, Daniel Gnoutcheff a écrit :
> On 10/12/2017 07:51 PM, Nicolas Dufresne wrote:>
> https://bugzilla.gnome.org/show_bug.cgi?id=785990
>
> That was it exactly.  I was on gstreamer 1.10.4.  Upgrading to 1.12.3
> fixed my problem.

Thanks for confirming, it felt slightly familiar.

regards,
Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel