-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Success, almost! #3
Comments
The TVs I've tested on did not require VCT or any of the changes in my ffmpeg patches. They don't display the virtual channel number or the channel name, but they play video just fine irregardless. The ffmpeg patches shouldn't be strictly necessary as much as it is a nicety. That being said, what SDR are you using and how are you getting the signal to the receiver? If you are direct wiring, are you using an attenuator? Without an attenuator you risk overloading the receiver to the point you could cause damage it or at least to the point it won't decode. I typically use a 30db attenuator. Is there any indication on either the tv or the linux tuner you're using that indicates that it has a signal lock? |
My TVs are too rigid! They require that I scan to add channels, which is needed to not only find the active frequencies but also the virtual channel numbers and pids. I can see the TV clearly stop at the correct frequency and pause, so it does detect something. w_scan also reports that it detects an 8VSB signal on the correct frequency, so that is good as well. In an abundance of concern, I switched back to the house coax feed and can still pickup the various local OTA signals. azap output: tuned to OTA TV Signal: Exciter off: Exciter on: With azap running and the exciter on but not feeding the exciter a stream, I have a lock but no data to capture. As soon as I started feeding an mpegts to the exciter, the receiver can capture a valid mpegts, so I am pretty confident that the hardware is working correctly. Thanks for your thoughts, at least pushed me to double check the hardware. Next step is for me to find an mpegts validator/dump and see what I need still. With all the troubles with getting patches into ffmpeg (I've tried in the past with a Decklink patch), I'm considering a utility that adds the data to the stream via pipes. Then I don't have to worry about ffmpeg patches Thanks again, |
Success! The problem boiled down to a malformed TVCT. This simple patch fixed the issue. I'm still having some quality of service issues and such, but it is a start.
|
Not sure you care much about this, but thought I would try and connect. Just compiled this on Linux (I've used ffmpeg for many years, so easy first step). However, neither w_scan on Linux nor a TV can find a usable stream. The signal is there, but with your version of ffmpeg and -metadata atsc_name and -metadata atsc_channel, w_scan concludes with:
tune to: 8VSB f=473000 kHz (0:0:0) (time: 03:35.506)
Info: no data from PAT after 2 seconds
Info: no data from VCT(terr) after 6 seconds
So before I start tearing into what PAT and VCT should contain that it doesn't, is this expected or something I'm not doing right? Either way, thanks for this project. Got me thinking about what is possible and playing.
The text was updated successfully, but these errors were encountered: