Beijing-IPTV: what the four M3U playlists for Beijing Unicom and China Mobile actually contain
The best Beijing Unicom and Beijing Mobile IPTV channel list. https://bjiptv.gq/
At a glance
- What is it?
- A data repository rather than a program, with one file that the README presents in two different roles and an EPG feed served over plain HTTP.
- Who is it for?
- Beijing-IPTV is worth adopting if you are on Beijing Unicom or China Mobile and want a maintained channel list without configuring a provider's own app. Two things decide whether it works for you, and neither is in the repository's control.
- Can I use it commercially?
- Yes. CC0-1.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 14 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 28, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A playlist repository that the platform files as Go code
The repository has 2291 stars and 355 forks, and GitHub classifies its primary language as Go. The tree tells a different story about where the work is. There are eight .m3u files, a README, a LICENSE, an index.html, a 404.html, a CNAME, a howto.md, and exactly one .go file, iptvscanner.go. There is no go.mod, no build script, no test and no CI configuration. The product is a set of text files, and the Go entry exists because the maintainer keeps a scanner alongside them.
IPTV-Unicom.m3uThat file is the permanent address for the Beijing Unicom unicast list, which is the one the README recommends. Two more permanent addresses sit at the top of the same page for the other three combinations: IPTV-Unicom-Multicast.m3u for Unicom multicast, IPTV-Mobile.m3u for Mobile unicast, and IPTV-Mobile-Multicast.m3u for Mobile multicast.
https://raw.githubusercontent.com/qwerttvv/Beijing-IPTV/master/IPTV-Unicom-Multicast.m3uThe licence is CC0-1.0, which is the right choice for a data set and worth naming explicitly: public domain dedication means you can take the addresses, repack them, and redistribute them without crediting anyone. That sits in mild tension with the README itself, which credits four sources and two external repositories by name and links them. Nothing obliges you to keep those credits, but they are the only record of how the addresses were obtained, so they are worth reading before you assume a channel is original.
The issue tracker is closed by policy, not by neglect. Open issues are zero, and note nine in the README states that the maintainer turned them off and invites readers to find another way to make contact. That means a broken playlist cannot be reported through GitHub, so you have to detect breakage yourself.
Two delivery paths with different requirements
The four playlists are not four flavours of the same thing. They are two delivery mechanisms, one per carrier, and the README is clear that they fail in different ways.
The multicast lists stay inside the carrier network. Note three says the operator's multicast list is universally usable on that operator's network and plays in any environment that supports multicast, with no internet connection required. The addresses come from two IPv4 multicast ranges the maintainer found, 239.3.1.X and 239.2.1.X, which is why the repository ships raw scan output for them.
The unicast lists route over your ordinary home internet, which is what makes them the recommended default. The cost of that convenience is stated in note two: the unicast list may add high-definition and ultra-high-definition channels that come from neither Beijing Unicom nor Beijing Mobile, these are tagged as unofficial, and they need an internet connection and may need IPv6. A player that ignores the unofficial tag cannot tell you which stream is which.
Note one also points at the specific place to point a relay at. If you want to carry the multicast streams over your LAN instead of to the set-top box directly, the README recommends msd_lite, or udpxy, and gives the address it expects.
192.168.123.1:23234That address is one user's LAN, not a general constant. Treat it as the shape of the value rather than the value itself.
The practical test before you commit to either path is which of the two your network can carry, and that is not answerable from the repository. It depends on your router, whether it passes IGMP, and whether your set-top box is on the same segment as the relay.
One filename doing two jobs on the China Mobile side
The Unicom side separates the general multicast list from the scan output. IPTV-Unicom-Multicast.m3u is the permanent address, and note eight presents IPTV-Unicom-Scan-A.m3u and IPTV-Unicom-Scan-B.m3u separately, describing them as the original scanned listings for ranges 239.3.1.X and 239.2.1.X and marking all three as reference material only.
IPTV-Unicom-Scan-A.m3u
IPTV-Unicom-Scan-B.m3uThe China Mobile side does not make that separation. At the top of the README, IPTV-Mobile-Multicast.m3u is presented as the permanent address for the general multicast list, one of the four addresses the whole project exists to distribute. In note eight, the same filename is presented as the raw Mobile scan output, again among files described as reference only.
Both statements are in the README at the same time, and they describe different kinds of file. A curated list drops duplicate and low-quality entries, while a scan dump is whatever answered on the address range at the moment of the scan.
You do not have to take either description on trust. Diff the file against the unicast list and against a fresh copy of the Unicom multicast file to see which side of the split it falls on.
IPTV-Mobile.m3uIf IPTV-Mobile-Multicast.m3u shares most of its entries with the Unicom multicast file in terms of channel naming and ordering, it has been promoted to the curated role. If it carries raw scan artefacts such as unnamed entries, malformed attributes or a large volume of duplicates, note eight is the accurate description and you should treat it as a source rather than as something to load into a player.
Where the addresses came from, and the scanner you actually run
The README lists four sources, and they differ in how much work each requires. The first is packet capture from a set-top box, which yields the unicast addresses because those are what the box is handed during a normal session. The second is multicast scanning. The third and fourth are cross-references to two other people's lists, which means this repository is not the only attempt at the same data and is worth comparing against when a channel is missing.
The scanner is a separate matter, because the repository ships it in three forms and credits it to someone else. The tree contains iptvscanner.7z, iptvscanner.go, and iptvscanner_win64_qwerttvv.zip. Note ten credits the scanner to zzl360, known as sdhzdmzzl, describes the archive as a Windows x64 build, and gives the argument order as start IP, end IP and a timeout in milliseconds, defaulting to 1500.
iptvscanner.exe 239.3.1.1 239.3.1.255 2000So the 7z is someone else's tool, the zip carries the maintainer's own name, and the .go file is source you can read but cannot build from this repository alone, since there is no module definition. If you want to run a scan, take the archive and treat the .go file as reference rather than as a build target.
If none of this is familiar, the repository also carries howto.md, which the README links as the place to start when you do not know how to use the lists at all. That is the first file to read before touching the playlists.
Unlocked paid channels, and a guide over plain HTTP
Note four is short and worth reading carefully: channels that were separately charged on the official service are all unlocked and free to watch here. That is the feature most people come for, and it is also the point at which the repository stops being a playlist and becomes a question about your relationship with your provider. Nothing in the repository discusses the operator's terms of service, so whether that is acceptable in your situation is not something the project can answer for you.
The programme guide is a separate system with its own characteristics. The M3U files carry an x-tvg-url tag pointing at a single host, so a player that honours that tag loads the guide on its own with no extra configuration.
http://epg.51zmt.top:8000/e.xmlThree things are worth knowing about that endpoint. It is plain HTTP on a non-standard port, not HTTPS, so the guide fetch is neither authenticated nor encrypted while every playlist URL in the project is served over HTTPS from a CDN. It is a third-party host that the project depends on but does not control, and if it disappears the lists keep working while the programme guide silently disappears with it. And note six concedes the data is often wrong, describing the source as sometimes inaccurate and advising you to treat it as approximate.
Players differ here more than anywhere else in this project. If yours ignores the x-tvg-url tag, you get no error at all, just an empty programme column, and the natural conclusion is that the list is broken when it is only the tag. Check your player's guide settings before concluding anything about the repository.
Eleven mirrors, a versionless release tag, and a repository that is also a website
The mirror list is long, and the README warns you about it in one line: every mirror shown uses the Unicom unicast URL as its worked example, and getting the other three lists or working out whether a given mirror is alive is left to you. The list covers a self-hosted site, Cloudflare Pages, three jsDelivr regions, GitHub release assets, and several independent GitHub proxies.
https://cdn.jsdelivr.net/gh/qwerttvv/Beijing-IPTV@master/IPTV-Unicom.m3uThe self-hosted entries are explained by the tree, which contains CNAME, index.html and 404.html alongside the playlists. The repository root is the website, so bjiptv.gq and the GitHub Pages URL are two views of the same commit rather than a separate deployment.
There is one GitHub release, tagged iptv, published on 2025-09-23, with a body of one word. Several mirrors point into releases/download/iptv/, which is why the tag is not a version but a stable slot: it names the location that mirror consumers read from, and it will not be superseded by a new tag when the lists change. When you pin a mirror URL, you are pinning to that slot rather than to a version of the data.
The proxy hosts deserve a separate thought. Each one you use is a party you are routing your requests through, and the paid channels the lists carry are the reason to be deliberate about which one you pick rather than picking whichever responds fastest.
The trimming rules that shape what you receive
The lists are curated, and the rules are stated. Note five removes test channels, lecture-style channels and the large volume of shopping channels. Note seven collapses duplicates, keeping only the higher specification when the same channel exists in high-definition and non-high-definition form. Note six is the honest one about quality, warning that the guide data is often slightly off.
These rules are sensible and they change what a channel count means. A list of this repository's channels is not the operator's full lineup, and it is not a raw dump of everything that answered on the carrier network. If you want the closest thing to complete, the scan files are the better starting point, and note eight marks all three of them as reference material rather than as recommended lists.
This is where the two paths part ways for good. The unicast lists are where the curation and the unofficial additions live, so they are the more convenient and the more opinionated choice. The multicast lists are closer to the carrier network, which makes them the more predictable one and also the more fragile, since they depend on IGMP reaching your device.
The last push was on 2026-09-28, so the data is being refreshed. Given that issue reporting is switched off, the currency of the file is the only health signal you get, so an old-looking channel count is worth investigating rather than assuming.
Editorial conclusion
Beijing-IPTV is worth adopting if you are on Beijing Unicom or China Mobile and want a maintained channel list without configuring a provider's own app. Two things decide whether it works for you, and neither is in the repository's control. First, which of the two delivery paths your network can actually carry, since the unicast list needs your home internet and possibly IPv6 while the multicast list needs only the carrier network. Second, whether your player reads the embedded x-tvg-url tag, because the guide is served from an unauthenticated HTTP endpoint and players that ignore the tag show an empty programme list with no error. Before trusting the file, diff IPTV-Mobile-Multicast.m3u against IPTV-Mobile.m3u: the README describes it both as the recommended general multicast list and as a raw scan dump kept for reference, and the two descriptions cannot both describe the same contents. Skip this repository if you need the operator's full paid lineup, since the list is curated rather than complete.
Frequently asked questions
Which Beijing-IPTV playlist should I use, the unicast list or the multicast list?
The README recommends the unicast list, which routes over your home internet and may include unofficial high-definition channels tagged as such. The multicast list for your carrier works without an internet connection but only inside that carrier's network, and it needs a router and device that pass multicast.
How do I scan for Beijing IPTV multicast addresses myself?
The repository ships iptvscanner.7z, a Windows x64 tool credited to zzl360. Run it as iptvscanner.exe with a start IP, an end IP and a timeout in milliseconds, for example against the 239.3.1.1 to 239.3.1.255 range the maintainer used, where the default timeout is 1500.
Why does Beijing-IPTV show no programme guide in my player?
The playlists embed an x-tvg-url tag, so the guide only loads if your player honours that tag. The guide itself is served from a plain HTTP endpoint on port 8000 that the README describes as often inaccurate, so an empty programme column can mean either an unsupported tag or unavailable guide data rather than a broken playlist.
Can I report a broken channel to the Beijing-IPTV maintainer?
Not through GitHub. The repository has its issue tracker closed by policy, and note nine in the README says so directly and asks readers to find another way to make contact. A playlist that has gone stale has to be detected by comparing it against your own channel list.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/qwerttvv-beijing-iptv)