[FFmpeg-devel] [PATCH] [WIP] libopusdec: Enable FEC/PLC

[Michael Niedermayer]

On Tue, May 15, 2018 at 12:35:45AM +0200, Steinar H. Gunderson wrote:
> Whenever we detect a discontinuity in the incoming stream, ask libopus
> to make up intermediate frames based on the first one we actually have
> after the discontinuity. If the stream contains FEC data (basically a
> low-quality side stream that is delayed by one packet), libopus will
> decode that. If not, it will activate PLC (packet loss concealment),
> which tries to synthesize some reasonable-sounding frame based on the
> previous audio. It will usually be audible, but it's much better than
> just playing silence.
> 

> Do note that libopus 1.2.1 has a bug that affects PLC for CELT streams,
> so you probably want to use Opus from git if you want to test this.

i guess i did hit this

2nd command segfaults:
./ffmpeg -i fate-suite/lossless-audio/luckynight-partial.wma -acodec libopus test.mkv
./ffmpeg -acodec libopus -i test.mkv -f null -
==31996== Invalid write of size 8
==31996==    at 0xCAFA572: opus_multistream_decode_native (opus_multistream_decoder.c:207)
==31996==  Address 0x7fefff6b0 is not stack'd, malloc'd or (recently) free'd
==31996== 
==31996== Invalid write of size 8
==31996==    at 0xCAFA579: opus_multistream_decode_native (opus_multistream_decoder.c:209)
==31996==  Address 0x7ff001438 is not stack'd, malloc'd or (recently) free'd

subsequent tries seem to produce errors instead of segfault

Error while decoding stream #0:0: Unknown error occurred
[libopus @ 0x2a1edc0] Decoding error: buffer too small
Error while decoding stream #0:0: Unknown error occurred


> 
> This is a work in progress; in particular, I'm unsure about:
> 
>   - Are the samples_to_timebase()/timebase_to_samples() functions
>     correct? I've seen avc->pkt_timebase be 0/1 in certain situations,
>     which indicates it isn't.

>   - Is pts discontinuity the right way of knowing whether packets were
>     lost, or can the RTP demuxer signal this somehow? What if the timebase
>     conversion is inexact; could we get false positives?

i would not trust a +-1 difference from expected pts values as indicating a
discontinuity in general. It may be different specifically here, i dont know



>   - Do we need to worry about pkt->pts == AV_NOPTS_VALUE, or can I delete
>     the tests in question?

i would assume pts can be AV_NOPTS_VALUE, 

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Elect your leaders based on what they did after the last election, not
based on what they say before an election.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180516/c0281414/attachment.sig>