Blocking error with gst-discoverer-1.0 // uridecodebin plugin

I’m reposting an old post as I can’t find the original one in the list of questions :frowning:

It’s still related to gstreamer and gst-discoverer-1.0 tool that does not work with some mkv contents whereas it works perfectly on other platforms (linux ubuntu, windows etc).

Example:

 gst-discoverer-1.0 -v http://fmr-dev.net/tmp/the_100.mkv

The expected output should start with:

 Topology:
   container: Matroska
     subtitles: Timed Text
     audio: MPEG-1 Layer 2 (MP2)
     audio: MPEG-1 Layer 2 (MP2)
     video: H.264 (High Profile)
 
 Properties:
   Duration: 0:45:19.800000000
   Seekable: yes
   Live: no
   Tags:
 ...
 ...
 ...

As I asked the question initialy, @alex.tx had tested it on a TDX XWayland platform, but the output below is not from gst-discoverer-1.0 but from the demuxer itself.:

  root@apalis-imx8:~# gst-discoverer-1.0 http://fmr-dev.net/tmp/the_100.mkv
    Analyzing http://fmr-dev.net/tmp/the_100.mkv
    
    ====== AIUR: 4.5.7 build on Nov 13 2020 08:36:18. ======
            Core: MKVPARSER_01.08.08  build on Oct 13 2020 05:39:34
     file: /usr/lib/imx-mm/parser/lib_mkv_parser_arm_elinux.so.3.1
    ------------------------
        Track 00 [video_0] Enabled
            Duration: 0:40:28.584000000
            Language: fre
        Mime:
            video/x-h264, parsed=(boolean)true, alignment=(string)au, stream-format=(string)avc, width=(int)1920, height=(int)1080, framerate=(fraction)25/1, codec_data=(buffer)01640029ffe1001e67640029acd940780227e5c05a810100a0000003002000000651e30632c001000668e938272c8b
    ------------------------
    ------------------------
        Track 01 [audio_0] Enabled
            Duration: 0:40:28.584000000
            Language: fre
        Mime:
            audio/mpeg, mpegversion=(int)1, channels=(int)2, rate=(int)48000, bitrate=(int)192000
    ------------------------

I suspect a bug somewhere…maybe not in gstreamer but maybe in the glib ?
At first glance, it seems that the error would come from uridecodebin plugin.
As we tried with gst-discoverer-1.0, there’s a timeout so we can exit.
But using a pipeline with uridecodebin…it never exits.

I have tried both on Apalis IMX8 Ixoard Board and also on a Colibri IMX8X.
On both platforms, we have tried from the official toradex-reference-multimedia image downloaded from Toradex and we have also tried with a fresh built Yocto image.
The result is the same.

Would you please confirm that you experence the same result ?

Thanks.

Karim

https://www.toradex.com/community/questions/64403/blocking-network-issue-with-gst-discoverer-10-gstr.html

@alex.tx
Thanks, But could you please confirm that you can reproduce this issue on Apalis IMX8 and Colibri IMX8X ?

Unfortunately neither I nor anybody from Toradex R&D team are familiar with gst-dicover. So we don’t know if it’s an issue at all. But if it’s an issue it look like pure SW issue of gst-dicover and it’s not related to Toradex HW or drivers.

hi @alex.tx
I understand.
gst-discoverer used to implement uridecodebin plugin.
At first glance, something is blocking into this plugin,whereas it doesn’t block on other platforms. That’s why I’m wondering if a lib in the distro is disturbing it.

What’s the step beyond ?

The Apalis IMX8 is a key board for us, and this issue is more than annoying :frowning:

To create a reference OS image we are using OpenEmbedded (Yocto) layers. Layer’s recipes and metadata should take care about dependencies and versions. Please check this article and a that one for details. Currently we are using gstreamer layer provided by NXP since it supports HW acceleration.

You can try replace it with generic gstreamer layer and check if gst-discoverer works correctly there.

Please note that our Reference Images for Yocto Project are not ready for deployment in production environment without further customization.

Thanks @alex.tx for your feedback.
Of course we have started customizing the ref. multimedia for own need.
But as we experience this issue, we fall back to the original reference multimedia image in order to find out the problem.

I have also explained my problem in NXP and I’m awaiting an answer…

Just to add to this discussion I don’t think this is a matter of the mkv format. I did a test on a different video source: https://www.freedesktop.org/software/gstreamer-sdk/data/media/sintel_trailer-480p.mkv

With this I didn’t get a timeout and later on in the output I got the topology that you are expecting see logs here.

Perhaps it has to do with the file size of the video (2.2G)? Or maybe the hosting server? I tried setting the timeout to ~10mins (default timeout is ~10s) and it still timed out with “http://fmr-dev.net/tmp/the_100.mkv”.

Though as per my test it doesn’t conclusively seem like it’s an issue with the mkv format. My initial feeling is the size of the video you’re trying to use gst-discoverer-1.0 on is the issue. Though I could be wrong and it’s honestly hard to say without narrowing it down further. Maybe one thing you could try is to use other mkv format videos of larger size and see if it can be reproduced.

Best Regards,
Jeremias

Hi @jeremias.tx ,

sorry my late reply !
No, it is not related to MKV format.
I pust a mkv content in example because it’s main format currently used worldwide.
I’ve started debugging into gstreamer;
The issue comes from the uridecodebin plugin…which one, on IMX8 uses some features implemented by NXP…and obviously badly coded by NXP as it works on platforms owned by the freescale community.
So it’s very disappointing as we’re working for a production project…not for dummy multimedia players.

It concerns the implementation of the v4l2 interface.

Nothing related to the file size, as it works if you read the content from a local file.

And it’s a 4K content, so the file size is about 50 or 60GB and it must not be a problem.

Karim

Could you please open a ticket on NXP support - https://support.nxp.com/s/ ?