Buffered streams unplayable

[davidclaeysquinones]

I've a m3u generated by threadfin with a buffer through VLC.
Logically it takes some time for the stream to buffer, this makes the playback to time out.

[lkenner]

Damn. I'll try recreate it over the weekend and take a look at the problem.

[JohnTrabusca]

Having the same behavior with Streamfin, as a suggestion (since you're only using M3U8 Playlists) I recommend using HLS.js as will most likely cover all this issues (https://github.com/video-dev/hls.js/)

[lkenner]

Having the same behavior with Streamfin, as a suggestion (since you're only using M3U8 Playlists) I recommend using HLS.js as will most likely cover all this issues (https://github.com/video-dev/hls.js/)

You are right! I have my first tests ready with HLS.js and it feels way more compatible with everything..
I'm on it, please give me some time.

[lkenner]

Sorry for taking so long to respond. I’ve made a lot of changes and tried my best to improve things.

There’s a new development build available for testing, which includes two significant updates:

• It uses HLS.js, as mentioned by @JohnTrabusca.
• It supports transcoding with hardware acceleration.

Here’s an example configuration:

services:
  streamdock:
    image: ghcr.io/limmer55/streamdock:dev
    container_name: streamdock
    ports:
      - "6050:6050" 
    environment:
      - M3U_URL=https://iptv-org.github.io/iptv/index.m3u
      - HW_ACCEL=vaapi
      - HW_DEVICE=/dev/dri/renderD128
    restart: unless-stopped
    devices:
      - /dev/dri/renderD128:/dev/dri/renderD128
    depends_on:
      redis:
        condition: service_healthy

  redis:
    container_name: redis
    image: redis:alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5

Theoretically, VAAPI, CUDA, QSV, Vulkan, and AMF should all be supported.
Practically, I’ve only been able to test with two nearly identical Intel GPUs. 😅

If you don’t set HW_ACCEL and HW_DEVICE, transcoding will be skipped, and HLS.js will handle playback as best it can.

Aside from this, there are some other changes under the hood, which I’ll describe later in the release notes.

I’d really appreciate your feedback—whether you’re using transcoding or not!

[davidclaeysquinones]

I'm not sure why there is need for an extra container. I would like to not need an extra container, but if it's necessary the redis address should be available for setup through an environment variable.

In my case I'm not using any hardware transcoding device.
My compose file is looking like this:

services:
  streamdock:
    image: ghcr.io/limmer55/streamdock:dev
    ports:
      - 6050:6050
    environment:
      M3U_URL: http://192.168.0.46:34400/m3u/threadfin.m3u
    restart: unless-stopped
  redis:
    container_name: redis
    image: redis:alpine
    healthcheck:
      test:
        - CMD
        - redis-cli
        - ping
      interval: 10s
      timeout: 5s
      retries: 5

When trying to open a stream I see the following:

For reference currently I'm using Firefox as a browser.

Furthermore the channel icons are weirdly stretched out.

[Sonny-Crockett]

o7 This looks great! Take your time. The wait will be worth it!

[sm0kingm4n]

same error for me. it would be nice to keep up the good working on the app to get something similar to this in the next releases -> https://tvit.leicaflorianrobert.dev/channels