Playback Issues in Web UI (Mac hardware transcoder)

Channels DVR Server
#15

I think you mean the wording below the playing video that says “Running: 9.955145s @ 1.11x” or similar.

I just tried three different stations. The first, 6.1, played for several minutes without a hiccup, but then the number dropped completely to ‘1x’ by the end.

The other two, 27.1 and 10.1, froze within a few seconds, despite the fact that the transcode factor was still well above 1x (1.18 for one, and the other was similar).

All of these were done with the hardware transcoder, at 720, in Safari.

Are these transcodes being done in ffmpeg? Could I have another outmoded instance of ffmpeg that’s running that’s slowing them down?

2017/01/19 10:31:21 [HLS] Stopping transcoder session 10323CCF-ch6.1
[mpegts @ 0x7ff37c009000] PES packet size mismatch
[mpegts @ 0x7ff37c009000] Dropped corrupted packet (stream = 1)
[mpeg2video @ 0x7ff37c009600] ac-tex damaged at 116 43
[mpeg2video @ 0x7ff37c009600] Warning MVs not available
2017/01/19 10:31:31 [HLS] Starting transcoder for channel 27.1
pipe:: could not seek to position 44864.245
2017/01/19 10:31:57 [HLS] Stopping transcoder session 10323CCF-ch27.1
[mpegts @ 0x7ff8fd008000] PES packet size mismatch
[mpegts @ 0x7ff8fd008000] Dropped corrupted packet (stream = 1)
[mpeg2video @ 0x7ff8fc009600] ac-tex damaged at 3 24
[mpeg2video @ 0x7ff8fc009600] Warning MVs not available
2017/01/19 10:32:06 [HLS] Starting transcoder for channel 10.1
pipe:: could not seek to position 66453.805
2017/01/19 10:33:03 [HLS] Stopping transcoder session 10323CCF-ch10.1
[mpegts @ 0x7fc6bc808000] PES packet size mismatch
[mpegts @ 0x7fc6bc808000] Dropped corrupted packet (stream = 1)
[mpeg2video @ 0x7fc6bca41000] ac-tex damaged at 72 31
[mpeg2video @ 0x7fc6bca41000] Warning MVs not available
2017/01/19 10:34:33 [HLS] Starting transcoder for channel 6.1
pipe:: could not seek to position 94342.470

#16

Those were all done remotely. I’m not at my home computer right now.

And sorry, I misspoke. Those were all software, not hardware transcodes.

#17

I just tried all three of the same channels with it set to hardware, and all three quit locked up within a couple of seconds.

2017/01/19 10:44:42 [HLS] Starting transcoder for channel 6.1
pipe:: could not seek to position 94952.070
2017/01/19 10:45:10 [HLS] Stopping transcoder session 10323CCF-ch6.1
[mpegts @ 0x7f8f54808000] PES packet size mismatch
[mpegts @ 0x7f8f54808000] Dropped corrupted packet (stream = 1)
[mpeg2video @ 0x7f8f54808600] invalid cbp -1 at 34 42
[mpeg2video @ 0x7f8f54808600] Warning MVs not available
2017/01/19 10:45:20 [HLS] Starting transcoder for channel 27.1
pipe:: could not seek to position 45693.443
2017/01/19 10:45:42 [HLS] Stopping transcoder session 10323CCF-ch27.1
[mpegts @ 0x7f7f61809600] PES packet size mismatch
[mpegts @ 0x7f7f61809600] Dropped corrupted packet (stream = 1)
[mpeg2video @ 0x7f7f6388ee00] ac-tex damaged at 27 14
[mpeg2video @ 0x7f7f6388ee00] Warning MVs not available
Error writing trailer of /Users/jcrunch/Movies/Channels/Streaming/10323CCF-ch27.1/stream.m3u8: No such file or directory2017/01/19 10:45:48 [HLS] Starting transcoder for channel 10.1
pipe:: could not seek to position 67276.013
2017/01/19 10:46:16 [HLS] Stopping transcoder session 10323CCF-ch10.1
[mpegts @ 0x7fb58b008000] PES packet size mismatch
[mpegts @ 0x7fb58b008000] Dropped corrupted packet (stream = 1)
[mpeg2video @ 0x7fb58a88f600] ac-tex damaged at 9 29
[mpeg2video @ 0x7fb58a88f600] Warning MVs not available

#18

And when the video locks up, does the timestamp in the text underneath still keep increasing? Or does it freeze too?

#19

The timestamp continues to increase.

#20

Ok great, that means the transcoder is working fine and the “stall” is happening in the browser’s video player. The browser video decoders appear to be very sensitive to errors in the stream, so any little hiccup in the hdhomerun or antenna signal can set it off.

It’s useful to hear that the issue is happening with both the hardware and software transcoders. The software one is generally a little bit more reliable when it comes to fixing errors.

Also surprised to hear you’re seeing the issue in both Chrome and Safari. Safari is generally more sensitive to errors and I’ve seen it stall out easily. Chrome (on desktop) is a bit more resilient since it uses a different decoder stack.

Can you reproduce the stall again, leave the browser window with the stalled out video open, and then grab the streaming files off of your server? In your Recordings folder, there’s a Streaming directory with another sub-directory with the channel number. Zip that up and send it to me: support@getchannels.com

I will need to do some research to see if we can detect and remove any corruption from the video stream during transcoding.

Web GUI playback (Linux/NAS hardware transcoder)
#21

I don’t know if it’s any help, but I also just tried Chrome and Vivaldi, and both run the transcoded video for a time (3 to 5 minutes or so) and then hang up, usually when the transcode rate drops below 1x.

I’m not now at my home computer, and I don’t have file access to it from work, so I’ll have to grab the streaming video file later this evening to send to you.

All of these transcodes on Chrome and Vivaldi seem to be starting out in the mid 1x-2x range (even start out like that on Safari), and then fairly quickly drop to at or near 1x (1.02, 1.01, 1). Is this symptomatic of anything? Shouldn’t the transcode rate be higher than that with my hardware?

#22

As long as the timestamp is still increasing, it should be fine. 1x means its transcoding in real time, i.e. it takes 1s to transcode 1s of video. If your CPU isn’t fast enough to transcode in real time, you’ll see the rate fall to 0.9x or lower, which means it takes longer than 1s to encode 1s of video, which means the transcoder will quickly start to fall behind and never be able to catch up.

When transcoding live tv on capable hardware, 1x is normal because the video data is coming in real time. When transcoding a recording, you’ll see higher rates because the transcoder can read the data as fast as possible off disk, instead of waiting for it to arrive off the tuner.

#23

I’m still trying to figure out why my hardware wouldn’t be able to transcode in real time. I know that the EyeTV transcode can go to right around 2x at 720 on recorded material, so I think the hardware is up to the task.

Would a move to newer system software help at all? I’m on 10.10.5 now. Or is there some other software reason the live TV transcodes could be falling below 1x?

#24

So with hardware transcoder you’re seeing the rate fall below 1x? What does it say?

But the software transcoder is able to stay at 1x?

The hardware transcoder should always be faster… upgrading to a newer macOS would probably help if you’re seeing otherwise.

#25

Don’t recall if it was the software or hardware transcode, but it dropped into the '.9***x range.

I guess I’ll try upgrading to 10.12 to see if that helps.

#26

Okay, made the not-too-painful slog to 10.12, but the video is still stopping after a time, regardless of settings or browser (Safari the worst [it dies almost immediately], Chrome and Vivaldi play some channels for a couple of minutes and then grind to a halt as the rate drops close to or below 1x).

Is there anything else I can try? Is this mostly a function of CPU speed, or are there other major factors? Are there other settings in ffmpg I can manipulate?

Here’s what the player window looks like (often-representative) when it dies (this one is from Vivaldi; similar screens seen in Chrome): Uploading…

#27

Uploading…

Thanks for all your attention to this. You folks are about the most attentive, diligent developers I’ve ever seen.

#28

I use an older 2010 mac mini which hasn’t been able to handle hardware transcode to web ui.

Today, I tested both Live and Recorded files on iPad Safari web ui. I tried both with software, blend and 240p. As I watched the speed start at 2-4+, I was hopeful…however, the speed inexorably crept downward over the next 3-5 min.

Wonder of wonders, the Live seemed to settle at 1.01 after 4 minutes and remain constant until 8 min when I stopped. The recorded speed fell to 1.11, but it took almost 2 hours…then a new recorded file started which caused a drop to 1.05, but when I quit about 10 minutes later, speed was still at 1.05.

Obviously, earlier than the new build above from @tmm1, so hopefully will be even better.

Thanks for moving @tmm1, so I guess we are still watching for improvements on the Mac side?

#29

Latest DVR build has some Mac hardware transcoder improvements too. Mentioned in Playback doesn't work on Safari (Mac and iPad)

#30

Follow up to yesterday’s tests:

Using same options with 1 show being recorded simultaneously…

Live: Watched for 40 min, speed primarily at 1.01, fell to 1.00 at about 20 min.

Recorded: Speed over 1.X, however on 1 show ( playback would stall approx every 10 sec, transcoding didn’t show “paused” during this test. Another show, intermittant pauses, another none. Weird: The worst performance was a 720p, the 2 others 1080i original file format.

#31

When having stall issues but transcoder status seems fine, try pausing video for 15-20s to let the transcoder race ahead of where you are trying to watch.

#32

@DebbieFL I assume this was software again and you’re still not able to use Hardware?

#33

Correction: Transcoding did not show paused.

Yes, SW, blend, 240p, same as prior.

Will be trying HW later.

#34

Hardware, blend, 240p - 1 show recording

Live TV: Playback starts at 1.x and decreases over 2-3 min to <1, then freeze. Other times, freeze will occur with speed at 1.2-1.3.

Recorded: Playback starts at 1-2x and decreases slowly. Usually within 2-4 min the screen freezes, however transcoder time keeps increasing. Usually speed at freeze is 1.2x

Tomorrow: will try same options but…with no other activity running