Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- The Wise Old Internet Raccoon's Guide to Building Your Own TV Station!
- Are you like me, tired of the boring, unwatchable garbage that the big broadcasters constantly pollute the airwaves with? Do you feel like Bender, from Futurama, saying "Yours stinks. I'll make my OWN TV station!" and wish you actually *could*? Well... YOU CAN! All thanks to a closed-circuit TV "White Space Device" that's perfectly legal and certified and approved by the FCC (under Part 15) and Industry Canada (under ICES-003) for home and small-office use!
- You're just gonna need some hardware and a couple software packages...
- Hardware:
- ChannelMaster CM-1050 ATSC HDMI-to-Coaxial Encoder Box
- HDMI Cable
- Laptop/desktop computer
- Optional: if you're like me and had to place your CM-1050 in another room that was too far to run an HDMI cable, you can use an old Google Chromecast 2 stick
- Software:
- I carefully selected open-source software that runs on Windows, Linux, and Mac OS, so the guide should apply to all three platforms roughly equally.
- OpenBroadcaster Software (OBS) Studio:
- This is going to be your virtual studio
- MediaMTX (formerly RTSP Simple Server): This is the beating heart of the operation and effectively gives an ATSC 1.0 signal internet-reception capability, much like how ATSC 3.0 is proposing (at least, via LAN devices such as cell phones, desktops/laptops/tablets, and so on).
- VLC Player: This is going to be a "bridge" between OBS and MediaMTX
- OPTIONAL: IF you want to fully-automate this and have playlists, consider getting ErsatzTV (http://www.ersatztv.org) for program queuing, insertion of station idents, and so on...
- COPYRIGHT WARNING!: NEVER *EVER* ***EVER*** BROADCAST CONTENT YOU DO NOT OWN OR HAVE PERMISSION FOR! YOU CAN AND LIKELY *WILL* END UP IN SERIOUS LEGAL/FINANCIAL HOT WATER! ONLY BROADCAST CONTENT THAT YOU HAVE MADE!
- BROADCAST WARNING!: THIS IS FOR INTERNAL, CLOSED-CIRCUIT TELEVISION SETUPS *ONLY*! UNLICENSED BROADCASTING TO YOUR NEIGHBOURHOOD IS HIGHLY ILLEGAL AND WILL AT THE *VERY* LEAST GET YOU A VISIT FROM THE FCC OR INDUSTRY CANADA TELLING YOU TO STOP BEFORE THEY HAVE TO SIEZE YOUR EQUIPMENT! IF INTERFERENCE IS CAUSED TO LICENSED OPERATORS SUCH AS RADIO, TV, OR TWO-WAY LAND-MOBILE SERVICES LIKE THOSE USED BY AMBULANCES, YOU WILL LIKELY FACE *VERY* SERIOUS CHARGES! THIS IS SIMPLY A HOME/SMALL OFFICE VERSION OF AN APARTMENT BUILDING'S "LOBBY CAMERA", OR HOW STORES SEND A VIDEO SIGNAL TO MULTIPLE TELEVISION SETS!
- FORMATTING INFORMATION:
- Canada and the United States of America decided to use the Advanced Television Systems Committee (ATSC) standard for Digital Television broadcasting, with version 1.0 of the standard being finalized on December 21, 1997. This tutorial is for ATSC broadcasting. Digital Video Broadcasting (DVB-T, DVB-T2) and ISDB-T/SBTVD are not supported here. Encoders using those two formats will not be viewable here!
- How does ATSC work?
- ATSC is the name for a group of standards that specify what audio codec, video codec, modulation scheme and metadata scheme are used. The Audio Codec is Dolby AC-3. The Video Codec initially specified for the standard was H.262 (MPEG-2), though later amendments to the standard allow for H.264 (MPEG-4/AVC), and most digital tuners/televisions/converter boxes made after 2008 should support MPEG-4 video. The Modulation scheme used in ATSC is 8VSB, or 8-bit Vestigial Sideband with a single carrier signal to lock on to, compared to Coded Orthogonal Frequency-Division Modulation (COFDM), which uses dozens to hundreds of carrier signals for added robustness. The Metadata standard is PSIP, or Program and System Information Protocol, containing such info as the channel number(s), call-sign, and even program title and summary.
- Introduction:
- Why did I do this? Well, I always wanted to run my own TV station. Even as a kid, I dreamed of running my own TV station, with cartoons on Saturday mornings, having news at 5 PM on weekdays, and filling the rest of the schedule with family movies or skits acted out with friends. Fast forward 30 years and through the digital transition.. I thought that dream would become impossible with the cessation of analog broadcasting in the United States and my native Canada. Thankfully, I did see some "pro-sumer" (between consumer and professional-grade) electronics on eBay around 2011, such as the MeldTech MT-300... though that was rare and expensive. I checked out other websites that offered various ATSC encoders, even with Program and System Information Protocol support, but those started at $CAD 900... still too expensive for my taste. Then, I saw the ChannelMaster CM-1050. It fit all my needs. it only cost 400 dollars, It had HDMI-In and Coax Pass-Through (via Coax-In and Coax-Out ports) to pass through an antenna if it was hooked up directly to a TV... This could work. Though, when I went to order it, the device was temporarily sold out. So... I waited. Eventually I saw Tyler the Antenna Guy making a video on YouTube about it, how it worked, and how it became available again! I pounced on it this time, not wanting to be left out again. One week later, my precious CM-1050 arrived from Arizona.
- Now, the trick was figuring out how to get it to work with both my home's rooftop antenna system, and with my laptop... this would prove to be a challenge, but not an insurmountable one. So, I got to work.
- Okay, mister raccoon of the forest, how exactly did you do this?:
- The first thing is, I cracked open English Wikipedia and read up on how ATSC 1.0 works, and how PSIP works, how both VHF and UHF bands propagate radio waves (which is what TV signals are, be they analog or digital!), how solar/space radiation can cause interference like with tropo-skip bringing long-distance stations from the other side of the country to your area for a brief period, and what sorts of adjacent- and co-channel interference I could expect in my area from other local and more-distant stations, how such interference presents itself, and how to best overcome it.
- My next stop was naturally, RabbitEars.Info to see what physical channels in my area (Detroit, Michigan / Windsor, Ontario) were available. There were thankfully a couple of channels still open, even after the 2016 Incentive Auction that removed everything from Channel 38 on up, leaving us with just Channels 2 to 36 to work with. I wanted my channel to have the same virtual channel as its physical channel, so that constrained me greatly. Thankfully, there was a UHF channel in my area that met my requirements (of having both an available physical channel and available virtual channel that matched it). I wanted to avoid VHF band channels (2-13) due to the susceptibility to impulse interference, like from electrical devices, solar flares or lightning, and preferred to stick to the UHF band as a result.
- The very first thing I did was configure the CM-1050's virtual channel and call-sign and frequency it was broadcasting on via hooking an ethernet cable up between it and my laptop (and changing its default IP and netmask to match that of my home network).
- With that initial configuration out of the way, it was then ready to receive, and send stuff on the UHF channel I had specified.
- SECURING THE BROADCAST CHAIN:
- I also wanted to secure and encrypt my broadcast chain so it couldn't be easily hacked or hijacked. This required SSL certificates, and how to update them. This next section is optional but HIGHLY recommended! If you wish to skip this, scroll down to CONFIGURING OBS STUDIO.
- First, I had to learn how to use Let's Encrypt (http://www.letsencrypt.org) and the Electronic Frontier Foundation's CertBot (http://certbot.eff.org) so I could generate my own valid security keys to further protect my streams from hacking.
- Once I generated my security keys, I copied/symlinked them a safe location, such as C:\TOOLS\MediaMTX\ on my Windows computer.
- Next, I downloaded MediaMTX (formerly RTSP Simple Streamer) from https://github.com/bluenviron/mediamtx . This little program is so insanely powerful and configurable that I almost can't even describe it... it listens for Real-Time Media Protocol streams, Real-Time Streaming Protocol streams, Real-time Transport Protocol, and even converts it to HTTP Live Streaming to be viewable (and embeddable) on a web page in a web browser. That last one is an absolute game-changer because that would give my little ATSC 1.0 stream similar capabilities to those new ATSC 3.0 "NextGen TV" streams! Remember, ATSC 1.0 doesn't even know about the internet, beyond it existing, since it was finalized in 1997..
- MediaMTX is also open-source, and has binaries available for a wide variety of platforms, including Windows, Linux, MacOS, and even Linux on ARM and ARM64/aarch64, with xource code available for you to compile for other operating systems.
- So, I extracted MediaMTX to C:\TOOLS\MediaMTX\ and fired it up as a test. It seemed to work just fine... but i wanted security with this thing. I wanted to make sure that only I would be sending video to the CM-1050 (and later on, to all the TVs in my house, and to my Twitch.TV account), so people would only see me playing video games... I didn't want a Broadcast Signal Intrusion like what WGN-TV dealt with in 1987!
- Note: For Windows, the directory I have this in is C:\TOOLS\MediaMTX. I also tested on a Raspberry Pi with the installation in /opt/mediamtx/.
- I opended C:\TOOLS\MediaMTX\mediamtx.yml in my favourite text editor and configured its usernames and passwords for authorized users:
- Scroll down to this part:
- ###############################################
- # Global settings -> Authentication
- # Authentication method. Available values are:
- # * internal: users are stored in the configuration file
- # * http: an external HTTP URL is contacted to perform authentication
- # * jwt: an external identity server provides authentication through JWTs
- authMethod: internal
- # Internal authentication.
- # list of users.
- authInternalUsers:
- # Default unprivileged user.
- # Username. 'any' means any user, including anonymous ones.
- - user: <broadcaster username>
- # Password. Not used in case of 'any' user.
- pass: <broadcaster password>
- # IPs or networks allowed to use this user. An empty list means any IP.
- ips: []
- # List of permissions.
- permissions:
- # Available actions are: publish, read, playback, api, metrics, pprof.
- - action: publish
- # Paths can be set to further restrict access to a specific path.
- # An empty path means any path.
- # Regular expressions can be used by using a tilde as prefix.
- path:
- - action: read
- path:
- - action: playback
- path:
- # Default unprivileged user.
- # Username. 'any' means any user, including anonymous ones.
- - user: <viewer>
- # Password. Not used in case of 'any' user.
- pass: <viewer password>
- # IPs or networks allowed to use this user. An empty list means any IP.
- ips: []
- # List of permissions.
- permissions:
- # Available actions are: publish, read, playback, api, metrics, pprof.
- - action: read
- # Paths can be set to further restrict access to a specific path.
- # An empty path means any path.
- # Regular expressions can be used by using a tilde as prefix.
- path:
- - action: playback
- path:
- Next, I told it where to find the keys in the configuration file, so I would have a fully-SSL-compliant stream, that wuold even support HTTPS (via HTTP Live Streaming... which is the same technology YouTube uses!). The Securtiy Certificate files (.crt and .key) MUST have your domain name on them! In my case, i snagged a .ca domain, but it's not important here, so i'm labelling it mystream.site as an example:
- ###############################################
- # Global settings -> Playback server
- # Enable downloading recordings from the playback server.
- playback: no
- # Address of the playback server listener.
- playbackAddress: :9996
- # Enable TLS/HTTPS on the playback server.
- playbackEncryption: yes
- # Path to the server key. This is needed only when encryption is yes.
- # This can be generated with:
- # openssl genrsa -out mystream.site.key 2048
- # openssl req -new -x509 -sha256 -key mykey.site.key -out mystream.site.crt -days 3650
- playbackServerKey: /<MediaMTX directory>/mystream.site.key
- # Path to the server certificate.
- playbackServerCert: /<MediaMTX directory>/mystream.site.crt
- # Value of the Access-Control-Allow-Origin header provided in every HTTP response.
- playbackAllowOrigin: '*'
- # List of IPs or CIDRs of proxies placed before the HTTP server.
- # If the server receives a request from one of these entries, IP in logs
- # will be taken from the X-Forwarded-For header.
- playbackTrustedProxies: []
- ###############################################
- # Global settings -> RTSP server
- # Enable publishing and reading streams with the RTSP protocol.
- rtsp: yes
- # List of enabled RTSP transport protocols.
- # UDP is the most performant, but doesn't work when there's a NAT/firewall between
- # server and clients, and doesn't support encryption.
- # UDP-multicast allows to save bandwidth when clients are all in the same LAN.
- # TCP is the most versatile, and does support encryption.
- # The handshake is always performed with TCP.
- protocols: [udp, multicast, tcp]
- # Encrypt handshakes and TCP streams with TLS (RTSPS).
- # Available values are "no", "strict", "optional".
- encryption: "optional"
- # Address of the TCP/RTSP listener. This is needed only when encryption is "no" or "optional".
- rtspAddress: :8554
- # Address of the TCP/TLS/RTSPS listener. This is needed only when encryption is "strict" or "optional".
- rtspsAddress: :8322
- # Address of the UDP/RTP listener. This is needed only when "udp" is in protocols.
- rtpAddress: :8500
- # Address of the UDP/RTCP listener. This is needed only when "udp" is in protocols.
- rtcpAddress: :8501
- # IP range of all UDP-multicast listeners. This is needed only when "multicast" is in protocols.
- multicastIPRange: 224.1.0.0/16
- # Port of all UDP-multicast/RTP listeners. This is needed only when "multicast" is in protocols.
- multicastRTPPort: 8502
- # Port of all UDP-multicast/RTCP listeners. This is needed only when "multicast" is in protocols.
- multicastRTCPPort: 8503
- # Path to the server key. This is needed only when encryption is "strict" or "optional".
- # This can be generated with:
- # openssl genrsa -out mystream.site.key 2048
- # openssl req -new -x509 -sha256 -key mystream.site.key -out mystream.site.crt -days 3650
- serverKey: /<MediaMTX directory>/mystream.site.key
- # Path to the server certificate. This is needed only when encryption is "strict" or "optional".
- serverCert: /<MediaMTX directory>/mystream.site.crt
- # Authentication methods. Available are "basic" and "digest".
- # "digest" doesn't provide any additional security and is available for compatibility only.
- rtspAuthMethods: [basic]
- ###############################################
- # Global settings -> RTMP server
- # Enable publishing and reading streams with the RTMP protocol.
- rtmp: yes
- # Address of the RTMP listener. This is needed only when encryption is "no" or "optional".
- rtmpAddress: :1935
- # Encrypt connections with TLS (RTMPS).
- # Available values are "no", "strict", "optional".
- rtmpEncryption: "optional"
- # Address of the RTMPS listener. This is needed only when encryption is "strict" or "optional".
- rtmpsAddress: :1936
- # Path to the server key. This is needed only when encryption is "strict" or "optional".
- # This can be generated with:
- # openssl genrsa -out mystream.site.key 2048
- # openssl req -new -x509 -sha256 -key mystream.site.key -out mystream.site.crt -days 3650
- rtmpServerKey: /<MediaMTX directory>/mystream.site.key
- # Path to the server certificate. This is needed only when encryption is "strict" or "optional".
- rtmpServerCert: /<MediaMTX directory>/mystream.site.crt
- ###############################################
- # Global settings -> HLS server
- # Enable reading streams with the HLS protocol.
- hls: yes
- # Address of the HLS listener.
- hlsAddress: :8588
- # Enable TLS/HTTPS on the HLS server.
- # This is required for Low-Latency HLS.
- hlsEncryption: yes
- # Path to the server key. This is needed only when encryption is yes.
- # This can be generated with:
- # openssl genrsa -out mystream.site.key 2048
- # openssl req -new -x509 -sha256 -key mystream.site.key -out mystream.site.crt -days 3650
- hlsServerKey: /<MediaMTX directory>/privkey.pem
- # Path to the server certificate.
- hlsServerCert: /<MediaMTX directory>/fullchain.pem
- # Value of the Access-Control-Allow-Origin header provided in every HTTP response.
- # This allows to play the HLS stream from an external website.
- hlsAllowOrigin: '*'
- # List of IPs or CIDRs of proxies placed before the HLS server.
- # If the server receives a request from one of these entries, IP in logs
- # will be taken from the X-Forwarded-For header.
- hlsTrustedProxies: []
- # By default, HLS is generated only when requested by a user.
- # This option allows to generate it always, avoiding the delay between request and generation.
- hlsAlwaysRemux: no
- # Variant of the HLS protocol to use. Available options are:
- # * mpegts - uses MPEG-TS segments, for maximum compatibility.
- # * fmp4 - uses fragmented MP4 segments, more efficient.
- # * lowLatency - uses Low-Latency HLS.
- hlsVariant: mpegts
- # Number of HLS segments to keep on the server.
- # Segments allow to seek through the stream.
- # Their number doesn't influence latency.
- hlsSegmentCount: 7
- # Minimum duration of each segment.
- # A player usually puts 3 segments in a buffer before reproducing the stream.
- # The final segment duration is also influenced by the interval between IDR frames,
- # since the server changes the duration in order to include at least one IDR frame
- # in each segment.
- hlsSegmentDuration: 1s
- # Minimum duration of each part.
- # A player usually puts 3 parts in a buffer before reproducing the stream.
- # Parts are used in Low-Latency HLS in place of segments.
- # Part duration is influenced by the distance between video/audio samples
- # and is adjusted in order to produce segments with a similar duration.
- hlsPartDuration: 200ms
- # Maximum size of each segment.
- # This prevents RAM exhaustion.
- hlsSegmentMaxSize: 50M
- # Directory in which to save segments, instead of keeping them in the RAM.
- # This decreases performance, since reading from disk is less performant than
- # reading from RAM, but allows to save RAM.
- hlsDirectory: ''
- # The muxer will be closed when there are no
- # reader requests and this amount of time has passed.
- hlsMuxerCloseAfter: 60s
- ###############################################
- # Global settings -> WebRTC server
- # Enable publishing and reading streams with the WebRTC protocol.
- webrtc: yes
- # Address of the WebRTC HTTP listener.
- webrtcAddress: :8589
- # Enable TLS/HTTPS on the WebRTC server.
- webrtcEncryption: yes
- # Path to the server key.
- # This can be generated with:
- # openssl genrsa -out mystream.site.key 2048
- # openssl req -new -x509 -sha256 -key mystream.site.key -out mystream.site.crt -days 3650
- webrtcServerKey: /<MediaMTX directory>/mystream.site.key
- # Path to the server certificate.
- webrtcServerCert: /<MediaMTX directory>/mystream.site.crt
- # Value of the Access-Control-Allow-Origin header provided in every HTTP response.
- # This allows to play the WebRTC stream from an external website.
- webrtcAllowOrigin: '*'
- # List of IPs or CIDRs of proxies placed before the WebRTC server.
- # If the server receives a request from one of these entries, IP in logs
- # will be taken from the X-Forwarded-For header.
- webrtcTrustedProxies: []
- # Address of a local UDP listener that will receive connections.
- # Use a blank string to disable.
- webrtcLocalUDPAddress: :8189
- # Address of a local TCP listener that will receive connections.
- # This is disabled by default since TCP is less efficient than UDP and
- # introduces a progressive delay when network is congested.
- webrtcLocalTCPAddress: ''
- # WebRTC clients need to know the IP of the server.
- # Gather IPs from interfaces and send them to clients.
- webrtcIPsFromInterfaces: yes
- # List of interfaces whose IPs will be sent to clients.
- # An empty value means to use all available interfaces.
- webrtcIPsFromInterfacesList: []
- # List of additional hosts or IPs to send to clients.
- webrtcAdditionalHosts: []
- # ICE servers. Needed only when local listeners can't be reached by clients.
- # STUN servers allows to obtain and share the public IP of the server.
- # TURN/TURNS servers forces all traffic through them.
- webrtcICEServers2: []
- # - url: stun:stun.l.google.com:19302
- # if user is "AUTH_SECRET", then authentication is secret based.
- # the secret must be inserted into the password field.
- # username: ''
- # password: ''
- # clientOnly: false
- # Time to wait for the WebRTC handshake to complete.
- webrtcHandshakeTimeout: 10s
- # Maximum time to gather video tracks.
- webrtcTrackGatherTimeout: 2s
- NOTICE: The HTTP Live Streaming (HLS) part requires the keys to be in .pem format!
- After this editing is done and the .crt, .key and .pem security keys are in place, fire it up with a test run.
- CONFIGURING OBS STUDIO:
- Next, I fired up OBS Studio and added the Multiple Output Plugin by SoraYuki (located here: https://sorayuki.github.io/obs-multi-rtmp/ ), just in case i wanted to stream to both a local install of MediaMTX, and say, Twitch.TV (remember kids, never stream copyrighted stuff if you don't have permission to do so!) I did this so I could do livestreams of me playing classic video games like Pac-Man, Sonic the Hedgehog 2 and Super Mario World, in case say, MediaMTX choked.. I could have Twitch.TV as a fallback. However, this works even without the Multiple Output Plugin (just use the default Stream Settings).
- The Default System Settings would have things like this:
- Service: Custom...
- Server: rtmp://localhost/
- (if you're running it directly on the same machine, otherwise, select an IP address or domain name like rtmp://192.168.1.1 or rtmp://myserver.whatever)
- Stream Key: mystream?user=<username in mediamtx.yml>&pass=<password in mediamtx.yml>
- If you decided to run the Multiple Output Plugin, it's mostly teh same, with just a couple differnces:
- Name: MediaMTX (localhost)
- (You can name this whatever you'd like, however)
- RTMP Server: rtmp://localhost/
- (if you're running it directly on the same machine, otherwise, select an IP address or domain name like rtmp://192.168.1.1 or rtmp://myserver.whatever)
- Stream Key: mystream?user=<username in mediamtx.yml>&pass=<password in mediamtx.yml>
- You can add multiple destinations this way via selecting [Add new target]. You can even specify which port the remote RTMP daemon is listening on, such as this:
- RTMP Server: rtmp://192.168.1.1:1935
- So, now that we have MediaMTX working, secured with SSL certificates, AND OBS pointed at it.. attempt streaming an image file or brief video clip to it by clicking [Start Streaming] in OBS. If you have the Multiple Output Plugin installed, select either [Start All] or [Start] directly under your preferred destination. You should see your content on your television (via the CM-1050) after a few seconds.
- Okay! So, if everything's correct, we should see the content on your television!
- My next step from here was to re-locate the CM-1050 from the room where one of my TVs was, to next to the antenna splitter to the other two TVs in the house. That would mean it was much too far for even a 60-foot HDMI cable to reach (and at that length, you'd start to see interference just from crosstalk of the various wires within the cable, which is no good!).
- I also figured "if I'm going to stick this into the antenna pre-amplifier, I better be sure this isn't causing any signal leakage throughout the house or the neighbourhood!" because I do *not* want a knock on the door from the FCC or Industry Canada about unauthorized broadcasts!"
- After more studying Wikipedia and the ATSC standards (at http://www.atsc.org), I realized that my current setup was already close to optimal for my exact needs.
- My rooftop antenna fed directly into an amplifier to boost any weak signals (such as the television stations in Toledo, Ohio that I sometimes watch). That amplifier then feeds into my splitter module, which has something like 3.5 to 7 dB of loss. That's roughly 1000x to 10,000x loss of signal strength.
- I also noticed that my Pre-amp was rated for 35 dB. With signal strength being logarithmic, that would be close to 1 million times the loss of signal if it were fed in right after. This meant my pre-amp would act as a crude notch filter to block any signals from radiating back up the cable to the antenna and would be so weak as to be undetectable, even if I was standing right next to it with my portable ATSC television or my laptop with a USB TV Tuner stick. Think of it like trying to swim up Niagara Falls. After swimming up the Niagara River from Lake Ontario. There would be effectively nothing to receive!
- So my system went from:
- Antenna -> Amplifier -> splitter -> TV, TV, TV, (with other unused coax ports capped to stop signal loss via interference)
- to this:
- Antenna -> Amplifier -> splitter -> TV, TV, TV, CM-1050 connected via an output port instead of the input port (occupied by the amplifier), (with other unused coax ports capped to stop signal loss via interference)
- Now, this setup would have worked if I was willing to leave my laptop hooked up next to it in the basement, but... that was definitely a suboptimal environment for streaming!
- So, I needed an option on how to beam my video content from my laptop to the CM-1050. I looked on eBay for "Wireless HDMI transmitters" but they proved a bit pricey and I had concerns about their reliability, and if they'd conflict with my 2.4 GHz Wi-Fi and Bluetooth devices, or even my 5 GHz Wi-Fi. There had to be a better way... Oh boy, was there! I remembered I had an old Google Chromecast 2 HDMI stick lying around in a drawer, unused after my family upgraded their first Digital HDTV to a Smart TV! I thought "I should be able to stick the Chromecast into the CM-1050, right?"
- And yes, the answer was yes! I now saw the default Google Picture Slideshow of various landscapes on all the TVs I tested this with! But there had to be a way to get video from my laptop to the Chromecast stick...
- Yet another case of Open Source To The Rescue (TM)! VLC Player, the popular open-source multi-platform video player that can display almost anything thrown at it... is also somehow able to beam video to a Chromecast stick because both the Chromecast stick and VLC Player support Miracast... Miracast was the way forward!
- I just had to tell VLC to tune in to the MediaMTX network stream.... yes, this was a bit of a feedback loop on a 5-second delay... but that was solved once I went to VLC's menus and selected Playback -> Renderer -> My Chromecast Stick.
- I HAD A VIDEO OF ME PLAYING A VIDEO GAME BROADCASTING ON ALL MY TVs ON THE UHF CHANNEL I SPECIFIED! WOOOOOOO!
- And just in case someone was watching a movie on the main living room TV and the two in the bedrooms were not accessible... we could still watch videos on our computers and phones because I set up a little webpage with the MediaMTX HLS server embedded, complete with playback controls (play, pause, stop)...
- All I had to do was make a simple HTML 5 page with this in the <body> tag:
- <p>
- If your browser is Chrome 39+ for Android or Desktop, Firefox 41+ for
- Android or 42+ for Desktop, Edge for Windows v10, Safari for Mac OS 10.10+
- or Safari for ipadOS 13+, then you can tune in below.
- <br>
- My Internet Simulcast Stream:
- </p>
- <iframe src="https://mystream.site:8588/mystream" width="1280" height="720"></iframe>
- <p>
- You can also tune in via VLC Media Player by instructing it to go to any of the following:
- </p>
- <ul>
- <li>rtmp://mystream.site:1935/mystream</li>
- <li>rtsp://mystream.site:8554/mystream</li>
- <li>https://mystream.site:8588/mystream</li>
- </ul>
- <p>
- If VLC asks you for a username or password, you can either input it there, or use the URL formats below to input directly into VLC:
- </p>
- <ul>
- <li>rtmp://mystream.site:1935/mystream?user=USERNAME&pass=PASSWORD</li>
- <li>rtsp://USERNAME:PASSWORD@mystream.site:8554/mystream</li>
- <li>http://mystream.site:8588/mystream</li>
- </ul>
- <p>
- If that fails, there's always watching in web browsers: http://USERNAME:PASSWORD@mystream.site:8588/mystream
- </p>
- <p>
- Just remember to replace USERNAME with the username provided to you by the admin, and PASSWORD with the password provided to you by the admin!
- </p>
- So now, I can air home videos, or stream me playing video games to my friends at my house, all without needing to worry if Twitch.tv is congested or not!
- With all this insanity, are you even the first to make ATSC 1.0 do stuff it was never intended to? Actually, no. That likely goes to officially-licensed broadcaster K03IM-D in Eugene, Oregon, who broadcasts 4K resolution content on their ATSC 1.0 channel! I'm not sure how many people can view it, however. While ATSC 1.0 does support the use of the MPEG-4 Video Codec, I doubt many MPEG-4-compatible sets can handle decoding 3840x2160p (4K Video) content... even if it's MPEG-4. And they have A DOZEN channels of that, ranging from 720p to 1080p to 2160p, with only the first and last subchannels being regular plain-Jane 720p MPEG-2 Video.
- If you have comments or questions, don't be shy! Contact the wise old internet raccoon at <slycooper1986@yahoo.ca>
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement