www.makemkv.com

Should I report the issue that makemkv uses a private call somewhere else than this forum ? A hack is to build libmakemkv1 without this avpriv_mpegaudio_decode_header call, bit I am afraid makemkvconv might misbehave randomly. Maybe the private ffmpeg function code could be copied to libmakemkv1 to ...

Necromancy, but might be of help to surfers. Had this on a brand new DVD 21:23:05 cyclope kernel: scsi_io_completion_action: 27 callbacks suppressed juin 04 21:23:05 cyclope kernel: sr 5:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=3s juin 04 21:23:05 cyclope kernel...

EDIT: I miss understood the actual question so, unless the ffmpeg file is replaced before makemkvcon builds against it, it's pointless. I'm also not sure why it is assumed that only this header routine is what requires full ffmpeg. avpriv_...() is a getter function while ff_mpa_...() is a (useless?...

As I reported in https://forum.makemkv.com/forum/viewtopic.php?p=151247#p151247, the use of avpriv_mpegaudio_decode_header in libffabi/src/ffabi.c ffm_mpa_decode_header, make the deb to depends on the full ffmpeg version (ie exactly7:6.1.1-3 hen build against ffmpeg 7:6.1.1-3). I did not investigate...

I'm not a debian packaging expert, but I think the issue is that you have libmakemkv1 depending directly on the upstream reversion of libavcodec60 (=7:6.1.1-1) and not a slightly more generic version (>=7:6.1.1), i.e. drop the -1 so that the dmo package -dmo1 can be used, as you have for libavutil5...

Thanks. It turns out I just rebuilt the packages from your sources against the unstable repository and the dependencies were updated accordingly. Only libssl3t64 dependency has changed so on next upgrade all packages were set back to your repository versions instead of my local builds except libmake...

Could you provide sid/unstable packages taking into account the 64-bit time_t transition (t64 suffix) in sid/unstable currently in progress?