Unable to remote stream because of audio issues

I have been having problems remote streaming, and all of the problems seem to relate to Channels version of ffmpeg having issues starting the transcoder because of issues with the audio stream. The logs look like:

2019/03/17 09:00:28 [HLS] Starting transcoder for file932-ee8ed69c1531 at 19s from 123.456.789.012 (encoder=h264_vaapi, resolution=480, deinterlacer=hardware, bitrate=2000)
[mpegts @ 0x3f62140] start time for stream 2 is not set in estimate_timings_from_pts
[mpegts @ 0x3f62140] Dropped corrupted packet (stream = 1)
[mpegts @ 0x3f62140] Could not find codec parameters for stream 2 (Audio: ac3 ([129][0][0][0] / 0x0081), 0 channels, fltp): unspecified sample rate
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Too many packets buffered for output stream 0:1.
[aac @ 0x3fc6600] 2 frames left in the queue on closing
2019/03/17 09:00:29 [HLS] Stopping transcoder for file932-ee8ed69c1531 after seek to 20s (out=19.000001s, finished=true)

I'm trying to track down the source of the problem. It appears to be problems with ffmpeg being unable to properly get a read on the audio stream, which causes the transcoder to error out. Additionally, it's difficult to see if it is related to transcoding in general or more specifically just the audio because where I am streaming to has such poor internet bandwidth that checking with just a remux isn't really an option.

I did just notice that the DVR was recently updated, including its version of ffmpeg. However, since the version of ffmpeg that is bundled with Channels DVR isn't a version-tagged build, it's difficult to see from when the ffmpeg sources came from, to help track down the issues.

I'm curious if anyone else has had a similar problem. These particular problems all seem to be on a single channel that has given me some problems in the past, so there being a problem with the source stream isn't a far leap. (For the record, the problem channel is KTLA-DT (5.1) in Southern California, on Spectrum (Riverside) (705).)

My next step in troubleshooting is to throw one of the trouble files into a Plex library and see how their transcoder handles it. (I had previously manually transcoded a trouble file with ffmpeg and then streamed it through Plex, and my native/local ffmpeg did not have problems with the transcode; this is what led me to the idea that the problem might be Channels' build of ffmpeg.)

(I would also like to note a few things about the log:

  1. The IP address has been modified. I am not trying to access an impossible server.
  2. The problem occurs regardless of whether or not I am using hardware transcoding. The results and logs are the same irrespective of encoding options.
  3. No, that is not a complete log. However, the only thing that differs are the seek times of the encoder. Otherwise, the log lines are nearly identical.)

What does the View Details on the DVR web UI show about that recording?

Track #0: MPEG-2 video
1920x1080   16:9   yuv420p   interlaced

Track #1: ATSC A/52A (AC-3)
5.1(side)   eng   384kbps

Track #2: ATSC A/52A (AC-3)
  eng   0kbps

For good measure, here is what the current Channels' version of ffprobe says:

[mpegts @ 0x2e1c300] start time for stream 2 is not set in estimate_timings_from_pts
[mpegts @ 0x2e1c300] Could not find codec parameters for stream 2 (Audio: ac3 ([129][0][0][0] / 0x0081), 0 channels, fltp): unspecified sample rate
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Input #0, mpegts, from 'The Flash S05E11 2019-01-22 Seeing Red 2019-01-22-2000.mpg':
  Duration: 01:00:00.60, start: 32741.398967, bitrate: 8378 kb/s
  Program 421 
    Stream #0:0[0x621]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x623](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, 5.1(side), fltp, 384 kb/s
    Stream #0:2[0x622](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 0 channels, fltp

My native ffprobe also produces those same results, so I guess it's not a problem with your ffmpeg versus mine. It is interesting that comskip was able to run through the episode, as its commerical data is present. Also, the second (and missing) audio channel is the Spanish SAP I believe. The reason it is probably showing as nothing at the moment is because the recording starts between programs when that audio stream is probably empty.

Looks like the SAP track is corrupted or missing.

I assume you can play back in Channels at home?

Can you upload a recording to google drive and email me a link to [email protected]

To be honest, I'm not sure if I can play directly on the local network. I've played a "corrupted" file through VLC and mpv, but not through Channels. (Due to a confluence of "things", nearly all of my interactions with my local network are remote. I don't frequently have the ability to troubleshoot issues "on site", and unfortunately that isn't going to change in the immediate future.)

I'll upload a copy of the file and send a message to the support address.

Is there any difference with Software transcoding?

The warnings about the secondary audio track are a red herring and can be ignored.

Same results with software transcoding. I have yet to check with Plex. Also, I'll try a manual transcode using the same settings as Channels DVR to various clients and see how they handle it.

Never mind the audio track is the issue. I'm poking at it some more.

Thanks for the confirmation.

A new DVR pre-release build is uploading now with a fix.

I'll give that a try and report back.

1 Like

I updated to build 1953, and it seems to work fine with those troublesome recordings. One side effect I noticed, though, is that the secondary audio track is no longer present on the transcoded stream. (Personally this does not bother me as I don't really care about the SAP track on these particular recordings; however I thought the trade-off to this fix should be noted.)

In any case, thank you much for the fix.

1 Like

The secondary track does not contain any audio data and is now being ignored.

I'm not sure if it's related, but streams now seem to be a bit more pixelated (or rather, I'm seeing macro blocking in the images). I haven't done any real debugging or investigating to see what might be different, but I've noticed this on a couple of different recordings since the update.

(The macroblocking is so bad to make it seem like my 720p stream is a badly upconverted 320p stream.)

Does Channels DVR monitor the recording files for changes? The reason I ask is to see about remuxing the problem file without the problem audio stream.

(As a point of reference, Tvheadend would monitor its recordings, and if a file was changed, moved or removed it would modify its database in real-time; an API call was needed to "teach" Tvheadend about the new file you would want it to use.)

The only thing I changed was ignoring the audio stream header when no data was present. Don't see how it could affect video transcoding.

The DVR does not watch files. If you swap one out you can use the web UI to Refresh it.

Interesting. I figured that's all that was done, but I noticed an immediate improvement when I restarted the DVR with latest pointing to the previous stable release. I'll give it another try, as maybe it was just a weird situation.

Hmm okay, what versions exactly?

There have been some other transcoder changes very recently, and there's a new build from yesterday which may fix any issues in the previous test build.

Also which encoder are you using?

The beta version that had the macroblocking was 2019.03.20.1953. The version I reverted to was 2019.03.12.0544. This was using the hardware encoder h264_vaapi. Maybe I'll give a newer beta a try ...

Thanks for all your effort.

1 Like