m4a files w/ audio + mjpeg stream

[dwcarder]

In running 2.0.0-rc1 for a while now I get the occasional disconnect to icecast with a message like:

2021/09/23 15:53:54 [playlist_0:3] Prepared "/file.m4a" (RID 4).
2021/09/23 15:53:55 [crossfade_0:3] Analysis: -29.756220dB / -21.172590dB (4.96s / 4.96s)
2021/09/23 15:53:55 [clock.main:2] Source icecast-mp3 failed while streaming: (Invalid_argument "String.sub / Bytes.sub")!
2021/09/23 15:53:55 [icecast-mp3:3] Closing connection...

First question: is that the actual error message, or is that a printf formatting issue in clock.ml? Sadly, I am not fluent in ocaml.

But more more to the point, this has happened enough that I think I have correlated all of the instances to m4a files that have two streams, such as this example below where there is both alac and mjpeg (presumably album art).

> ffprobe file.m4a
ffprobe version 4.4-5 Copyright (c) 2007-2021 the FFmpeg developers
<snip>
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x55db88121b40] stream 0, timescale not set
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'file.m4a':
  Metadata:
    major_brand     : M4A
    minor_version   : 512
    compatible_brands: M4A isomiso2
    track           : 10
    date            : 2021
    encoder         : Lavf58.45.100
    replaygain_track_peak: 0.79351807
    replaygain_track_gain: -3.76000000 dB
  Duration: 00:03:25.00, start: 0.000000, bitrate: 779 kb/s
  Stream #0:0(und): Audio: alac (alac / 0x63616C61), 44100 Hz, stereo, s16p, 773 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]
    Side data:
      replaygain: track gain - -3.760000, track peak - 0.000018, album gain - unknown, album peak - unknown,
  Stream #0:1: Video: mjpeg (Baseline), yuvj444p(pc, bt470bg/unknown/unknown), 700x700 [SAR 72:72 DAR 1:1], 90k tbr, 90k tbn, 90k tbc (attached pic)

Is there a setting I can put in my config script that would say, hey let's only consider the audio stream for sending to icecast, assuming that's the issue?

[toots]

Hi!

Thanks for the report. I think you should try the latest v2.0.0 🙂

I believe this is all due to some files having covert art tags. The cover art tag show up in the list of the file's metadata. We recently worked on our internal support for utf8 strings and had an issue where we were trying to quote/escape strings that didn't contain utf8 encoded data (like a cover art), which would make the whole thing raise an exception: #1960

This should be fixed now. The reason this is confusing with ffmpeg is that I believe adding a video stream is ffmpeg's way of reporting the cover art and allowing the user to manipulate. It's a bit hacky and certainly confusing.. 🙂

[dwcarder]

Interesting, I had read through the git history and wouldn't have come to that conclusion that it could be related. I'll grab the 2.0.0 docker image now! ;-)

[dwcarder]

well, related question, d5b2f91 is in the 2.0.0 branch, but should this be 2.0.1, or what would trigger a docker build?

(I could try main, I guess)

[toots]

The string quoting/escaping fix should be in both main and v2.0.0

[dwcarder]

I confirmed it's fixed in 2.0.0-rc1+git@f6093a18, which is what it reports in the current docker build of main I pulled.

For what it's worth, the docker image for v2.0.0 which a few days older is still affected and does not appear to have that commit.

[toots]

Great, thanks! I think the v2.0.0 docker image has failed to build for a minute, gonna have a look at it and also bump the version in main.. 🙂