Stream #0:7(0x32f) (qaa): Subtitle: dvb_subtitle ( / 0x0006)Īnd this is the output of ffmpeg -i "" (the previous TS converted to HLS):ĭuration: N/A, start: 89434.629367, bitrate: N/A This is the output of ffmpeg -i "" (slightly shorted and adapted to GitHub editor): But this information isn't placed where it should be. As you said, there's EIT info (at least, the current/next events) at HLS fragments. I'm not a huge fan of piping, so making everything with one instance is perfect.Ībout EIT, I think I found the problem. I fixed my command lines to use only one tsp. Hi again, of all, thanks for the quick response and for the notes about piping. Second, if you don't find EIT's in the output HLS segment files, make sure that there are EIT's for that service in the input stream: tsp -I http "" -P tables -pid 18 -tid 0x4E-0圆F -tid-ext 805 -O drop will display all EIT's for service 805. Maybe VLC does not try to read EIT's in HLS streams. EIT's are a DVB concept and HLS is used for OTT. It EIT's are present, then maybe VLC does not read EIT's from HLS input. P zap -eit 0x1392 -O hls test.ts -l 8 on a broadcast capture file what was hanging out somewhere on the disk and I confirm that the EIT's are present in the output segment files for the selected service.įirst, check that EIT's are present in some output HLS segment files: tstables c001_XXX.ts -pid 18. Thant being said, your command preserves EIT's indeed, if there are any for the given service. There is one single tsp common and one single common packet buffer where packets are processed "in place" and are never copied. The transport stream goes through many pipes and packets are copied back and forth all the time. Many thanks in advance, and in any case, congrats for this powerful piece of software.
#How to use ffmpeg to stream mpts via tcp manual#
Tsp -I http "" | tsp -P zap -eit 805 | tsp -v -O hls /var/I read through the manual and I think that, if it's possible to keep EIT when converting from "live" TS to HLS, I tried all the ways.Ĭan you give me some advice or tell me why it seems impossible to keep EIT into HLS output (not only with TSDuck)?Īnd, if EIT can't be "relayed" from Transport Stream, is it possible to inject it from an XML/JSON file at the time of HLS conversion? Tsp -I http "" | tsp -v -O hls /var/Second one "zaps" a specific Service ID (the only one in the HTTP TS, so is a bit redundant) trying to force EIT preservation, then pipes to HLS encoder: First one simply pipes the TS into TSDuck's HLS encoder: I tried two command lines (on Ubuntu 16.04, TSDuck compiled from source). With TSDuck, a/v work, subtitles work and program name is read by client (VLC Media Player, as said before). But, as you all know and TSDuck's manual warns, ffmpeg kills EIT and other TS data (and even has problems simply copying DVB subtitles). Tvheadend doesn't offer HLS output, so we tried with ffmpeg's HLS encoder. VLC opens these HTTP Transport Streams flawlessly, and reads all contents (EPG, subtitles.). We get an MPEG TS of every channel through a Tvheadend server. And the last one is giving us a hard time. We are trying to convert some DVB-T channels difficult to being received here by air from a neighbour region into separate HLS streams with exactly the same capabilities as the original DVB-T services (audio, video, subtitles, EPG.).
0 kommentar(er)
