webm file garbled

[funkju]

All of my recordings end up progressively glitching until they look like this. Any ideas to the cause?

Running on Debian 4.9.168-1+deb9u4 (2019-07-19) x86_64 GStreamer version: GStreamer Core Library version 1.10.4

[ethand91]

Hello,

All of my recordings end up progressively glitching until they look like this. Any ideas to the cause?

This may be caused by a large amount of packet loss. Could you call "getStats" on the producer and consumer at an interval and check the packet loss?

[funkju]

What is a tolerable level of packet loss?

I have a 4 minute recording with the following stats:

PRODUCER STATS:  [
  {
    bitrate: 1756310,
    byteCount: 57136825,
    firCount: 0,
    fractionLost: 0,
    jitter: 0,
    kind: 'video',
    mimeType: 'video/VP8',
    nackCount: 147,
    nackPacketCount: 1058,
    packetCount: 49649,
    packetsDiscarded: 0,
    packetsLost: 343,
    packetsRepaired: 343,
    packetsRetransmitted: 532,
    pliCount: 1,
    roundTripTime: 57.952880859375,
    rtxSsrc: 407097086,
    score: 10,
    ssrc: 556314332,
    timestamp: 88748181,
    type: 'inbound-rtp'
  }
]
PRODUCER STATS:  [
  {
    bitrate: 37987,
    byteCount: 1402619,
    firCount: 0,
    fractionLost: 1,
    jitter: 0,
    kind: 'audio',
    mimeType: 'audio/opus',
    nackCount: 0,
    nackPacketCount: 0,
    packetCount: 13393,
    packetsDiscarded: 0,
    packetsLost: 104,
    packetsRepaired: 0,
    packetsRetransmitted: 0,
    pliCount: 0,
    roundTripTime: 57.4951171875,
    score: 9,
    ssrc: 3065440649,
    timestamp: 88748214,
    type: 'inbound-rtp'
  }
]
CONSUMER STATS:  [
  {
    bitrate: 1734198,
    byteCount: 53826632,
    firCount: 0,
    fractionLost: 0,
    kind: 'video',
    mimeType: 'video/VP8',
    nackCount: 0,
    nackPacketCount: 0,
    packetCount: 46736,
    packetsDiscarded: 0,
    packetsLost: 0,
    packetsRepaired: 0,
    packetsRetransmitted: 0,
    pliCount: 0,
    score: 9,
    ssrc: 507485967,
    timestamp: 88748492,
    type: 'outbound-rtp'
  },
  {
    bitrate: 1734198,
    byteCount: 57203999,
    firCount: 0,
    fractionLost: 0,
    jitter: 0,
    kind: 'video',
    mimeType: 'video/VP8',
    nackCount: 147,
    nackPacketCount: 1058,
    packetCount: 49708,
    packetsDiscarded: 0,
    packetsLost: 343,
    packetsRepaired: 343,
    packetsRetransmitted: 532,
    pliCount: 1,
    roundTripTime: 58.502197265625,
    rtxSsrc: 407097086,
    score: 10,
    ssrc: 556314332,
    timestamp: 88748492,
    type: 'inbound-rtp'
  }
]
CONSUMER STATS:  [
  {
    bitrate: 36771,
    byteCount: 1244972,
    firCount: 0,
    fractionLost: 1,
    kind: 'audio',
    mimeType: 'audio/opus',
    nackCount: 0,
    nackPacketCount: 0,
    packetCount: 12347,
    packetsDiscarded: 0,
    packetsLost: 103,
    packetsRepaired: 0,
    packetsRetransmitted: 0,
    pliCount: 0,
    roundTripTime: 1.007080078125,
    score: 9,
    ssrc: 690202909,
    timestamp: 88748493,
    type: 'outbound-rtp'
  },
  {
    bitrate: 38371,
    byteCount: 1404218,
    firCount: 0,
    fractionLost: 1,
    jitter: 0,
    kind: 'audio',
    mimeType: 'audio/opus',
    nackCount: 0,
    nackPacketCount: 0,
    packetCount: 13407,
    packetsDiscarded: 0,
    packetsLost: 104,
    packetsRepaired: 0,
    packetsRetransmitted: 0,
    pliCount: 0,
    roundTripTime: 57.4951171875,
    score: 9,
    ssrc: 3065440649,
    timestamp: 88748493,
    type: 'inbound-rtp'
  }
]

Packet loss seems pretty low.

First "artifacts" start about 9 seconds in.

[ethand91]

Your right, packet loss is not too bad..

Could you try the following: update GStreamer to version 1.16.0 (which is the version I used making this) also does gstreamer print any WARN logs to the console? You could try setting GSTREAMER_DEBUG_LEVEL to 4/5 to get more info.

[funkju]

Sorry for the delayed response. It took a while to get an updated version gstreamer running. Still producing similar results:

GStreamer Core Library version 1.17.0.1 mediasoup 3.4.8 mediasoup-client 3.3.12

The only WARN that gets logged to the console is: WARN opusdec gstopusdec.c:526:opus_dec_chain_parse_data:<opusdec0> Phase inversion request is not support by this version of the Opus Library.

This doesn't seem related.

There is one log about a group id: FIXME basesink gstbasesink.c:3379:gst_base_sink_default_event:<filesink0> stream-start event without group-id. Consider implementing group-id handling in the upstream elements

Googling indicates to me that this probably isn't the cause, but maybe it is?

I'm thinking that the gstreamer pipeline may need to be tweaked.

[ethand91]

Thanks I'll look into it.

[ethand91]

Hello would it be possible for you to provide the webm file?

[funkju]

Here is a link to it: https://we.tl/t-NrMdLQWZpx

Github wont accept the file because it's too large. If you don't trust the random websharing link - I can record a smaller one to provide.

[ethand91]

Hello could you please create and share a smaller one

[ethand91]

closed due to inactivity