http input issues with ffserver #78
Comments
|
Hello Jan, The plugin So, the solution is probably RTFM as usual. Try with various values of |
|
That would explain the bitrate reported being wrong, but do you think that it's the pcrbitrate's incorrect use causing the issues with http input when the data flow starts and stops? Should TSDuck work with a scenario where a source stops and resumes later? I'm still trying to do merging of streams (http and/or udp) where I'm creating the input streams on an encoder like ffmpeg from files but I'm still having trouble making this work without TSDuck restarts when the source itself restarts. |
|
OK, sorry, I read the report too fast, focused on the bitrate issue and missed the reconnection one. Again, the answer is probably RTFM 😆 with option |
|
Well I'm still not sure if However maybe I've found a workaround: ffmpeg -> ffserver -> mptsd -> TSDuck This way TSDuck output seems quite stable even if ffmpeg stops and starts - mptsd outputs CBR with null packets if ffserver stops sending data. I haven't checked PCRs, AV sync and more channel merging but it's a start. If I remove ffserver, it doesn't work reliably because mptsd loses connection to ffmpeg, which seems to interrupt the output, which causes again TSDuck to get confused somehow by something... I'm sorry that I can't specify the problem exactly, instead I'm only describing symptoms. But I really don't know what the problem is and it's difficult to apply extra parameters from the manual if I have no clue what I'm looking for. |
|
and here's something from debug:
the output is modulated and plays fine the full command looked like this:
after stopping ffmpeg: and the output looks like fast forwarding video (but it must be played from a buffer or something like that, since ffmpeg is stopped the command looked like this
|
|
Hi Jan, |
|
Well maybe I'd just like to ask a question first - is TSDuck's concept OK with a stream source (UDP or HTTP) that's not providing a consistent, 24/7 stream? The input stream (HTTP, UDP) may stop and start or it may remain connected but at times only send null packets or no data at all. Even when I tried ffmpeg -> ffserver -> mptsd -> TSDuck workflow, thus providing TSDuck with CBR input, it didn't work for very long. I was able to stop and start the source streams (ffmpeg) a few times and it was OK during the hour or so I tested this. But then I stopped ffmpeg (so mptsd was only streaming null packets) and 6 hours later, I resumed the source ffmpeg stream but at that point I could only see frozen picture on the output (TSDuck IP output as well as dektec output). Restarting TSDuck solved the issue. |
|
Normally, it should work. The tsp engine is really passive and does not take any action based on time. The input plugin "pushes" packets in the chain. Pushing and pushing from one plugin to another. When nothing "pushes" at input, every plugin is waiting. There is one artifact however : To avoid too many context switches between threads (each plugin executes in its own thread), a plugin thread is woken up only when a significant amount of packets are ready for this plugin (global parameter So, because of this, you may say that Normally, the input plugin can wait for a long time, very patiently, until new packets arrive. There is nothing in That being said, I will not rewrite a complete HTTP implementation myself. It is awfully complicated. You need support for SSL/TLS, proxy management, various procotol specificities, etc. So, we need to find a solution with the existing system libraries. |
I'm testing http input in a way where I'm running ffserver which provides http output, streaming mpeg-ts which it's getting from from ffmpeg. It works like this:
run ffserver with a configuration that waits for data from ffmpeg and whenever it gets it, it streams it out via http to the connected clients. If it's not getting anything from ffmpeg, theren there's no data but the http connection remains open
then I run ffmpeg which feeds a TS file in real time to ffserver
then I run TSDuck which reads the HTTP output and re-streams to UDP or modulates
The problem starts when ffmpeg stops feeding ffserver and there's no data sent out by ffserver. It seems that at this point TSDuck tries to reconnect, which might be OK but what's strange is that when it reconnects, it reports bitrate (since I included -P pcrbitrate) of 2+ Mbps, while there's no data streamed from the http source at that time so it's not possible that it can actually see any real bitrate from PCR since there's no PCR. There's even a fragment of the last played video file on the UDP output from TSDuck. Simply restarting TSDuck fixes the issue. Also when recording the output of ffserver directly, there's nothing, which is correct.
Here's the command and its output:
now I stop ffmpeg (but ffserver connection remains active, there's just no data being sent) - after that, there are constant reconnect attempts
and so on until TSDuck is restarted:
... waits here until ffmpeg starts feeding ffserver again, then the streaming works
What I also notice is that it's very easy to reproduce this issue if the re-started ffmpeg streams from a file with different bitrate. If the same bitrate is streamed with ffmpeg, then TSDuck is likely to survive even ffmpeg restarts.
Here's an example of reconnects and reported bitrates when I tried to stream a file at 10 Mbps, then restart ffmpeg with variable bitrate at approx 3 Mbps:
not only was TSDuck reconnecting all the time, it was also mixing together pcrbitrate messages with various bitrates, while the input was first 10 Mbps and then VBR 2.5-3.5 Mbps, it was never anything else.
The text was updated successfully, but these errors were encountered: