Streaming via DLNA is smooth, but same video via browser is unenjoyable

Question

I manage and stream my videos with a self-hosted web application. The web application also offers DLNA based streaming.

When I stream the videos via the browser (latest Raspberry PI OS and default Chromium browser), it jerks massively. This is not a good way to watch.

But if I stream the same video over DLNA with VLC, it runs performant and you can enjoy it.

No DRM in the files.

Why this behavior with the same video?

moreover:

• the same web app runs smoothly on LG 4K NanoCell TV (55NANO867NA) which has an α7 Gen3 processor 4K CPU (never heard of it).

Why is it so much better with SmartTV compared to PI?

I do not want to stream with a proprietary SmartTV, how can I explain the performance differences and how can I fix them?

Answer 1

DVLA uses UDP (user datagram packets) and multicast (which is also packet based) to stream video over the network and its significantly faster than TCP (sockets). That's because the overhead of maintaining a TCP socket is so much greater in terms of overhead and latancy.

Detailed reasons for this are:-

• TCP buffers the unacknowledged segments for every client. In some cases this is undesirable, such as TCP streaming for very popular live events: your list of simultaneous clients (and buffering requirements) are large in this case. Pre-recorded video-casts typically don't have as much of a problem with this because viewers tend to stagger their replay activity.

• TCP's delivery guarantees are a blocking function which isn't helpful in interactive conversations. Assume your network connection drops for 15 seconds. When we miss part of a conversation, we naturally ask the person to repeat (or the other party will proactively repeat if it seems like you missed something). UDP doesn't care if you missed part of a conversation for the last 15 seconds; it keeps working as if nothing happened. On the other hand, the app could be designed for

• TCP to replay the last 15 seconds (and the person on the other end may not want or know about that). Such a replay by TCP aggravates the problem, and makes it more difficult to stay in sync with other parties in the conversation. Comparing TCP and UDP’s behavior in the face of packet loss, one could say that it’s easier for UDP to stay in sync with the state of an interactive conversation.

• IP multicast significantly reduces video bandwidth requirements for large audiences; multicast requires UDP (and is incompatible with TCP). Note - multicast is generally restricted to private networks. Please note that multicast over the internet is not common. I would also point out that operating multicast networks is more complicated than operating typical unicast networks.