# LiveRoomDemo Server: a 2017 live streaming room rebuilt with its old stack intact

> The server half of a live streaming demo, with HLS and RTMP playback, a STOMP over WebSocket chat room, a danmaku overlay synced to the chat and live viewer counts kept in Redis, serving a Thymeleaf desktop page and a Vue mobile SPA. It runs on Spring Boot 1.5.4 and Java 8, and the project says plainly that it should not be exposed to the internet.

**jack-hoo/LiveRoomDemo_Server** — 自己动手打造一个直播间（视频直播、聊天室、弹幕、多端适配）

- Repository: https://github.com/jack-hoo/LiveRoomDemo_Server
- Stars: 557 · Forks: 275
- Language: JavaScript
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/jack-hoo-liveroomdemo-server

## What the server actually provides

This is the server side of a live-streaming room demo, covering HLS and RTMP playback, a STOMP-over-WebSocket chat room, a bullet-screen overlay and real-time viewer statistics.

The five features are worth taking one at a time, because each solves a different problem that a live room has.

It pulls a live stream from a media server, with HLS on mobile and RTMP on desktop. That split is the delivery decision: HLS is the one that survives on a phone, and RTMP was the one that worked in a desktop browser. It provides a WebSocket chat room built on STOMP and SockJS, which is a framing protocol for WebSocket rather than a raw socket protocol, and it is what lets the same server push messages to browsers that need a fallback transport. Bullet-screen comments, the danmaku overlay that scrolls across the video, are synced with the chat. There is a live online-viewer count and a visitor history, backed by Redis. And it serves both a desktop page, using Thymeleaf and jQuery, and a mobile SPA, which is the prebuilt bundle from a separate LiveRoomDemo_Client repository.

The split between the two front ends is the design decision with the most consequence. The desktop side is server-rendered, so the page is a Thymeleaf template with jQuery on top, and the mobile side is a Vue 2 single page application built separately and served as static assets. That means the server does not build the mobile bundle, it ships a prebuilt one, and the two front ends are updated on different schedules.

The project is MIT licensed and the author is jack-hoo. There is a Chinese README, and it is described as the primary documentation, covering setup, configuration and deployment in detail, so the English one is the shorter document.

## The stack, and why it is frozen on purpose

The technology table is short and specific, and the reason it looks dated is stated rather than implied.

The framework is Spring Boot 1.5.4 on Java 8. The primary store is MySQL through the spring-boot-starter-data-jpa module, and the real-time store is Redis through spring-boot-starter-data-redis. Messaging is STOMP over WebSocket with an optional RabbitMQ relay. The desktop front end is Thymeleaf with jQuery, Bootstrap and video.js, and the mobile front end is a Vue 2 SPA built separately and served as static assets.

Then the project status section, which is the most useful paragraph in the README. This is a 2017 demo project that was cleaned up and re-released as a proper open-source project. Bugs were fixed and personal data removed, but the framework versions were deliberately left untouched.

Deliberately is the operative word, and the reason is stated next. Spring Boot 1.5.4 reached end of life in August 2019 and has known CVEs, and the instruction is not to expose this to the public internet as-is, with a pointer to the SECURITY.md file.

That combination, a project that has been made presentable and safe to read but deliberately not upgraded, is a legitimate and rather unusual choice. The alternative would have been to bump the framework, which would have meant rewriting the WebSocket configuration, the SockJS setup and the Spring Data layer, and the author wanted the historical shape preserved instead. It also means the code is a snapshot of how this was done in 2017 rather than a recommendation for how to do it now.

The repository layout is a conventional Maven project with a pom.xml, a src/ directory, a docs/ directory, the two READMEs, a SECURITY.md, a CONTRIBUTING.md and a CODE_OF_CONDUCT.md, plus a .github/ directory.

## Running it, and the two things that are already broken

The quick start is a single block, and it needs JDK 8, because Spring Boot 1.5 does not compile on newer JDKs, along with Maven 3.x, MySQL 5.7 or newer and Redis 3.2 or newer.

```bash
# 1. create the schema
mysql -u root -p < docs/sql/schema.sql

# 2. point the app at your services and start it
export MYSQL_USERNAME=root MYSQL_PASSWORD=yourpassword
export BROKER_RELAY_ENABLED=false          # skip RabbitMQ, use the in-memory broker
mvn spring-boot:run

# 3. open http://localhost:8085/LiveDemo/live_room
```

Three things are worth noting in that sequence. The schema comes from a file in the docs directory rather than from a migration tool, which is consistent with a project that predates Flyway or Liquibase. The credentials are passed as environment variables, so the same JAR runs against different databases without a rebuild. And the quick start sets BROKER_RELAY_ENABLED=false, so the in-memory broker takes over, which means you can run the whole thing with nothing but MySQL and Redis.

The application path is under a context, with the live room page at the LiveDemo path under port 8085, which suggests a configured port with a context path set on top.

The second broken thing is stated after the status section. RTMP playback in the browser no longer works, because it depends on Flash, which every major browser removed in 2021, and the instruction is to use an HLS source instead. That is the reason the mobile path uses HLS and the desktop path used RTMP, and it means a deployment today has to feed HLS to both.

The fuller instructions, including nginx-rtmp setup, RabbitMQ STOMP and WAR deployment to an external Tomcat, are in the deployment document, which is in Chinese, and every configuration key is documented separately in the configuration document.

## Why a chat and a danmaku overlay are the interesting part

The bit of this design that generalises beyond live streaming is the relationship between the chat channel and the comment overlay.

Bullet-screen comments are synced with the chat, which sounds like a small statement and is actually the whole mechanism. In a danmaku interface the comments are not an annotation layer on the video, they are the chat messages themselves, rendered as moving text over the player. So a message sent in the chat room and a comment scrolling across the video are the same object, and the synchronisation is not a copy step but a consequence of the design.

That has an immediate consequence for the transport. The chat is STOMP over WebSocket with SockJS, and STOMP is a message framing protocol with headers, destinations and bodies. Carrying the comment metadata, so that the server knows which message is a danmaku comment and where it should appear, is a natural fit for a protocol with a header section, rather than something bolted on to a raw JSON payload.

The optional RabbitMQ relay then makes sense in the same light. With the relay off, the in-memory broker serves the chat. With it on, the messages are published to RabbitMQ, which means the same server can be one participant among several, or the room can be fed by something other than a browser. For a demo that is a single room, the relay is unnecessary complexity, and the project lets you leave it off.

The viewer count is the other piece of state worth noting, and it is where Redis earns its place. A live count and a visitor history are both read far more often than they are written, and both are ephemeral in the sense that a stale count does no harm. Keeping them in Redis rather than in MySQL means the count does not generate database writes every time a viewer joins or leaves, which on a busy room would be the dominant source of load in an otherwise trivial application.

The desktop and mobile split follows the same logic in a different dimension. A desktop page with Thymeleaf and jQuery is fine on a wide screen, and a Vue SPA is the right call on a phone where the video is the primary object. The server does not try to serve one interface to both.

## What a 2017 snapshot is good for, and what it is not

The project status section tells you what this repository is for, and the honest answer is a teaching artefact rather than a starting point.

It is a 2017 demo that was cleaned up and re-released as a proper open-source project, with bugs fixed and personal data removed, and with the framework versions deliberately left alone. What you get is a complete, coherent example of how a live streaming room is assembled, with every layer named and separated, and a codebase that has been made safe to read by a stranger.

The value of that is real, and it is the value of the reference implementation rather than the production dependency. The layers are documented in the technology table, so you can see at a glance which job is done by which component: JPA over MySQL for the durable records, Redis for the live counters, STOMP for the message framing, Thymeleaf and jQuery for the server-rendered desktop page, and a separately built Vue bundle for mobile. Seeing those choices side by side, with the reasoning in the README, is worth something that a modern rewrite would lose.

What the project is not is a foundation. Spring Boot 1.5.4 reached end of life in August 2019 and has known CVEs, and the instruction is not to expose it to the public internet as-is. The JDK 8 requirement is the same statement from a different angle, because that is a consequence of the framework generation and not a preference. And the Flash removal in 2021 means part of the original design no longer functions, so even a local demo needs a different stream source than the one the code was written against.

The sensible uses are therefore three. Reading it to understand the shape of the problem, copying the structure of a piece of it into a system you control, and using it locally to see the mechanism work. Anything beyond that means upgrading the framework, which is exactly what the author chose not to do, and which you should budget for if you take that route.

The Chinese documentation is the primary one and covers setup, configuration and deployment in detail, including the nginx-rtmp configuration and the RabbitMQ STOMP relay setup. So the deployment details exist, they are simply written in the other language, which is a mild barrier for an English-only reader and a reasonable thing to point at before you commit to the project.

## Conclusion

LiveRoomDemo Server suits someone learning how a live streaming room is put together, or a team that needs the shape of the solution rather than the code, since the chat, the danmaku sync and the viewer count are all readable and separately replaceable. It does not suit you as something to deploy, because the framework is Spring Boot 1.5.4 which reached end of life in August 2019, it has known CVEs, and the project says so itself in its SECURITY.md. Before you run it, plan around the two broken pieces, the browser RTMP path depends on Flash and the mobile SPA is a prebuilt bundle from a separate repository, and if you need a maintained stack, use the structure rather than the code.

## FAQ

### What does the LiveRoomDemo Server provide?

It pulls a live stream from a media server with HLS on mobile and RTMP on desktop, provides a WebSocket chat room built on STOMP and SockJS, syncs bullet-screen comments with the chat, keeps a live online-viewer count and visitor history in Redis, and serves both a desktop page using Thymeleaf and jQuery and a mobile Vue 2 SPA served as static assets.

### What does it take to run the LiveRoomDemo Server?

JDK 8, because Spring Boot 1.5 does not compile on newer JDKs, Maven 3.x, MySQL 5.7 or newer and Redis 3.2 or newer. You create the schema from the SQL file in the docs directory, export the MySQL credentials, set BROKER_RELAY_ENABLED=false to use the in-memory broker instead of RabbitMQ, and run mvn spring-boot:run.

### Is it safe to put the LiveRoomDemo Server on the public internet?

No. The project states that the framework versions were deliberately left untouched, so it runs on Spring Boot 1.5.4, which reached end of life in August 2019 and has known CVEs, and the README says not to expose it to the public internet as-is. There is a SECURITY.md with the details.

### Does RTMP playback still work in the LiveRoomDemo Server?

No. RTMP playback in the browser depends on Flash, which every major browser removed in 2021, so the project tells you to use an HLS source instead. The mobile path already used HLS and the desktop path was the one that broke.

## Sources

- [Issues](https://github.com/jack-hoo/LiveRoomDemo_Server/issues)
- [jack-hoo/LiveRoomDemo_Server on GitHub](https://github.com/jack-hoo/LiveRoomDemo_Server)
- [License: MIT](https://github.com/jack-hoo/LiveRoomDemo_Server/blob/master/LICENSE)
- [README](https://github.com/jack-hoo/LiveRoomDemo_Server/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jack-hoo-liveroomdemo-server