[Bug 776983] opusenc does not discard silence if DTX enabled

[GStreamer (GNOME Bugzilla)]

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

--- Comment #2 from Nubosch <andreas.kling at gmail.com> ---
(In reply to Nubosch from comment #0)
> if dtx is enabled and silence is detected opusenc should only encode 1 frame
> each 400ms, as stated in RFC 6716, 2.1.9.
> 
> in function gst_opus_enc_encode() 1 is returned from
> opus_multistream_encode(), signaling the frame should be discarded cause of
> detected silence.
> Each 400ms a value != 1 is returned from opus_multistream_encode().
> 
> I use the attached patch to discard the frame.
> can you tell me why this might be a bad idea?

gathering enough information is not as easy as I thought.
there was some discussion touching this topic here
https://patches.libav.org/patch/27718/

in fact the non multi stream api tells:
"If the return value is 2 bytes or less, then the packet does not need to be
transmitted (DTX)"

I was not able to find a reasonable information about the multi stream api.
so I played around with the amount of channels and encoding parameters.

It looks like, if opus is able to actually perform dtx it adds a TOC and a 0
length octet, skipping the length octet for the last stream.

- is checking for dtx property enough?
- does it make sense to check for
  outsize > (2*(enc->n_channels - enc->n_stereo_streams))

imo >= should not be needed, as adding another length octet would require a
payload to exists.

> I use this pipeline for testing
> gst-launch-1.0 pulsesrc ! "audio/x-raw,channels=1,rate=48000" ! opusenc
> audio-type=2048 bandwidth=1103 bitrate=20000 bitrate-type=1 inband-fec=TRUE
> packet-loss-percentage=1 dtx=TRUE ! fakesink
> 
> I came across this while measuring network bandwidth using opusenc with dtx
> and rtpopuspay.
> The packet rate was constant, one packet each 20ms.
> There where packets containing only one single RTP payload byte.
> With the attached patch the packet rate is irregular with a minimum of one
> packet each 400ms, always containing multiple bytes.

RFC 7587 does not include multiple streams as also rtpopuspay does not include
it

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.