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:
- The IP address has been modified. I am not trying to access an impossible server.
- The problem occurs regardless of whether or not I am using hardware transcoding. The results and logs are the same irrespective of encoding options.
- 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.)