2019-04-20, 17:09
Today I was searching through the code and tried to find the sections where the flush() could be triggered from, and finally I gave up.
What finally brought success was the good old printf-debugging via adding some more trace outputs. Kodi behaves quite strange when decoding musepack (and other audio codecs as well?). When playing a file I can see 2x flush() called before the decodingstarts. After a seek this happens 1x -- as expected. A good workaround is possible via checking amount of already decoded frames within the flush()-function itself. The counter is always =1 for the first frame -- in case of starting a new file from the start. So we can simply avoid flushing in this case.
Tests done for musepack SV7 files:
1. Start new file -> ok
2. Seek within file -> ok
3. Skip back to start of file -> ok
4. Skip to next file -> ok
4. Let Kodi advance to new file -> ok
What finally brought success was the good old printf-debugging via adding some more trace outputs. Kodi behaves quite strange when decoding musepack (and other audio codecs as well?). When playing a file I can see 2x flush() called before the decodingstarts. After a seek this happens 1x -- as expected. A good workaround is possible via checking amount of already decoded frames within the flush()-function itself. The counter is always =1 for the first frame -- in case of starting a new file from the start. So we can simply avoid flushing in this case.
Quote:static void mpc7_decode_flush(AVCodecContext *avctx)
{
MPCContext *c = avctx->priv_data;
av_log(avctx, AV_LOG_DEBUG, "mpc7_decode_flush: frame #: %d\n",
avctx->frame_number);
/* Do not flush first frame, otherwise first 32 frames are dropped */
if (avctx->frame_number !=1 ) {
memset(c->oldDSCF, 0, sizeof(c->oldDSCF));
c->frames_to_skip = 32;
}
}
Tests done for musepack SV7 files:
1. Start new file -> ok
2. Seek within file -> ok
3. Skip back to start of file -> ok
4. Skip to next file -> ok
4. Let Kodi advance to new file -> ok