2019-04-18, 23:59
Hi all,
today I played around with building Kodi (kodi 17.6, ffmpeg 3.1.11) and also reviewed the ffmpeg source code for musepack. I now found a way to work around the issue, but this needs some more debugging and deeper understanding of how the codec API is used.
Workaround: Comment the code within function mpc7_decode_flush() in libavcodec/mpc7.c, in detail only the line "c->frames_to_skip = 32;" must be commented.
Pro: No loss of the first 32 frames when decoding musepack SV7 files.
Con: Weird noise for 32 frames when jumping to another position within a SV7 file.
Reason: Musepack SV7 uses differential coding of scalefactors. Each 32 frames the bitstream is providing an absolute value again. So, when seeking/jumping to a specific time position you need to decode 32 frames before you have the proper scalefactors for synthesizing the signal. I assume the "flush()" function was added to mute the signal for 32 frames when jumping to time positions. This type of muting must not be used when simply starting to decode a file from start. In the current Kodi implementation it seems that flush() is also called when starting to decode a file at position 0.
Solution:
1. If target frame pos <=first 32 frames: do not reset dscf data, frames_to_skip = target frame pos.
2. If target frame pos > first 32 frames: reset dscf data, frames_to_skip = 32.
Question: How is kodi making use of flush()? Is kodi using something like "jump-to-0 and flush" before starting to decode each file? Can you point me to the file where the calling function is implemented?
Regards,
Buschel
today I played around with building Kodi (kodi 17.6, ffmpeg 3.1.11) and also reviewed the ffmpeg source code for musepack. I now found a way to work around the issue, but this needs some more debugging and deeper understanding of how the codec API is used.
Workaround: Comment the code within function mpc7_decode_flush() in libavcodec/mpc7.c, in detail only the line "c->frames_to_skip = 32;" must be commented.
Pro: No loss of the first 32 frames when decoding musepack SV7 files.
Con: Weird noise for 32 frames when jumping to another position within a SV7 file.
Reason: Musepack SV7 uses differential coding of scalefactors. Each 32 frames the bitstream is providing an absolute value again. So, when seeking/jumping to a specific time position you need to decode 32 frames before you have the proper scalefactors for synthesizing the signal. I assume the "flush()" function was added to mute the signal for 32 frames when jumping to time positions. This type of muting must not be used when simply starting to decode a file from start. In the current Kodi implementation it seems that flush() is also called when starting to decode a file at position 0.
Solution:
1. If target frame pos <=first 32 frames: do not reset dscf data, frames_to_skip = target frame pos.
2. If target frame pos > first 32 frames: reset dscf data, frames_to_skip = 32.
Question: How is kodi making use of flush()? Is kodi using something like "jump-to-0 and flush" before starting to decode each file? Can you point me to the file where the calling function is implemented?
Regards,
Buschel
