Replies: 17 comments 18 replies
-
So that's how it works... I've been contemplating adding some code to change I don't know where the fourcc tag is stored in mpegts, that probably should set too though. I'm going to make this a discussion, because I just noticed there was a option to do that, Have you ever played with mplex? The information is appreciated man, post anytime you like. Adrian |
Beta Was this translation helpful? Give feedback.
-
NUT container is FFmpeg's native container. It is just a very simplistic container that "tries not to mess with stuff". It has no practical use outside of FFmpeg, but it is a great container for just playing with stuff within FFmpeg.
or just use TS Duck? That's a great tool for PMT mapping and stuff. I use TS Duck and pipe it into threefive... They are very complementary tools. You can do all sorts of TS manipulation.
Your code would make an an amazing base for a plugin to replace TS Duck's "rmsplice". Your code is way more sophisticated on the SCTE-35 side. TS Duck can do any of the TS manipulation rather well, and the dude who writes it seems like a good sort. If you don't know TS Duck, check it out. Your code is also more sophisticated than TS Duck, because you have the basis for manifest-based ad markers. I don't think there are any other open-source projects that do ad marker decoding from HLS manifest.
Yeah, I don't know where that is set either.
I have looked at it in the past. I got scared. I ran away. Having been a big user of threefive for a couple of years, I was amused to see that you are also the author of scc2vtt in a different repo. SCTE-35 & EIA-608/scc in HLS are two areas where I get very involved. ccextractor is my go-to, but I have played with scc2vtt. Thanks for open-sourcing your code. Finally, I'm intrigued by where you got https://futzu.com/xaa.ts from - and don't feel like you have to answer. That particular TS stream was created about 2007-2009 in a proof of concept experiment with Channel 4 in the UK to do realtime replacement of ads for a student-focused IPTV service. I recognize the metadata in the stream. I never thought I would see that TS stream over a decade later. |
Beta Was this translation helpful? Give feedback.
-
All good, Futzu. There was nothing of meaning that warranted a reply. I keep an eye on your work in threefive and regularly update to latest - it is so reassuring to see the level of maintenance and features that you put in (like HLS support and your new SDT tables). On behalf of your anonymous user base who who can't even read a line of Python - thanks for making the tool so usable in a plain command line environment. "Great tool AAAA+++++. Would recommend." |
Beta Was this translation helpful? Give feedback.
-
As a separate comment to the above, which is what I checked back here to share...another kind developer has proposed a patch to FFmpeg for SCTE-35 passthrough. I thought it was relevant to the original topic about 0x86 stream type in MPEG-TS muxer and wanted to share with you http://ffmpeg.org/pipermail/ffmpeg-devel/2021-November/thread.html#287613. Who knows whether the patch will be accepted, but I can be pretty sure that threefive would be the test case for validating that FFmpeg patch. And if it isn't used as the test case, it should be! On inspection, the proposed patch of the FFmpeg maining list may only work with one of There have been many SCTE-35 patches proposed to FFmpeg over the years, but none-of them have made it to stable, but maybe this is the start of something. As ever, thank-you! |
Beta Was this translation helpful? Give feedback.
-
I am surprised too. I was trying to do the same thing with ffmpeg,and driving myself nuts. Updated the cue2vtt.py last night. Mplayer doesnt recognize the webVTT formating, so everything is aligned center. I am thinking about combining it with mpegts.js project so I can play the video in a webpage with formatted webvtt subtitles. |
Beta Was this translation helpful? Give feedback.
-
Lots of great stuff coming from the SoftWorks crew on subtitle rendering in FFmpeg's libav. I have been lurking in ffmpeg-devel and there was a huge amount of activity in Nov around subtitle frame handling and conversion. As far as I read it, it amounts to subtitle frame handling and a -filter:s and I think a subtitle API. http://ffmpeg.org/pipermail/ffmpeg-devel/2021-November/thread.html#288221. It looks to be a pretty substantial overhaul, subject to code review. One to watch. With current stable and a -strict experimental flag you can unlock some of the HLS+webVTT functionality at least to a point that you can see the demuxer acknowledge webVTT in debug, but it is still experimental and non-functional.
If and when anything hits mainstream FFmpeg, I'll let you know. |
Beta Was this translation helpful? Give feedback.
-
kabuki can change the stream type back to 0x86 (scte35) |
Beta Was this translation helpful? Give feedback.
-
I there a way to hack a fix into ffmpeg for this? I'm digging through the code and having trouble finding where this occurs. I've read through kabuki but my python is so rusty. I don't really need to make a durable fix but need to run a live remux to test downstream scte35 haling. Thanks |
Beta Was this translation helpful? Give feedback.
-
https://github.com/futzu/gumd , gumd does multicast, and it's real easy to use. cat pv.ts | pypy3 ./kabuki.py -p 0x105 | gumd -a 127.0.0.1:2000 in another terminal I ran
and it worked just fine. a@debian:~/build/clean/x9k3$ ffplay udp://127.0.0.1:2000
Input #0, mpegts, from 'udp://127.0.0.1:2000':0KB sq= 0B f=0/0
Duration: N/A, start: 1.400000, bitrate: N/A
Program 1
Metadata:
service_name : Service01
service_provider: FFmpeg
Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], Closed Captions, 59.94 fps, 59.94 tbr, 90k tbn
Stream #0:1[0x101]: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 256 kb/s
Stream #0:2[0x102]: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 256 kb/s
Stream #0:3[0x103]: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 256 kb/s
Stream #0:4[0x104]: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 256 kb/s
Stream #0:5[0x105]: Data: scte_35 |
Beta Was this translation helpful? Give feedback.
-
I had to rename kabuki six2scte35 so I could make it a pkg. pip3 install six2scte35 gumd
or
pypy3 -mpip install six2scte35 gumd then you can do something like ffmpeg -re -i http://x.x.x.x:xx/720/funroads720SCTE35.m3u8 -map 0 -c copy -f mpegts - | six2scte35 -p 0x105 | gumd -a 127.0.0.1:2000 That's about as concise I can make it. |
Beta Was this translation helpful? Give feedback.
-
Good God Man, don't leave me in suspense :) |
Beta Was this translation helpful? Give feedback.
-
Worked like charm.
Probe gave me:
|
Beta Was this translation helpful? Give feedback.
-
Hey I got a message about binding to a specific interface, I was thinking that maybe an issue and I should make it so you can specify the interface, I will try update it tonight, but it will probably be tomorrow. |
Beta Was this translation helpful? Give feedback.
-
Some changes I think you'll dig. pypy3 gums.py -i ~/mpegts/udp.livetv.ts -b 192.168.12.160 -u -a 192.168.12.160:4444
Stream: udp://192.168.12.160:4444
Source: 192.168.12.160:43594
usage: gums [-h] [-i INPUT] [-a ADDR] [-u] [-b BIND_ADDR] [-t TTL] [-v]
optional arguments:
-h, --help show this help message and exit
-i INPUT, --input INPUT
like "/home/a/vid.ts" or "udp://@235.35.3.5:3535" or "https://futzu.com/xaa.ts"
-a ADDR, --addr ADDR Destination IP:Port like "227.1.3.10:4310"
-b BIND_ADDR, --bind_addr BIND_ADDR
Local IP to bind to like "192.168.1.34". Default is 0.0.0.0
-t TTL, --ttl TTL Multicast TTL 1 - 255
-u, --unicast Use Unicast instead of Multicast
-v, --version Show version
|
Beta Was this translation helpful? Give feedback.
-
In C we just test if multicast address, no need for extra arg: If you want more optional features to add: SSM we use for backup systems. Some broadcast plants send redundant streams from multiple sources and the client can switch between them as needed (usually for redundancy purposes). RTP is just a re-ordering protocol. It's most edffective in SMPTE 2022-7. Dual identical RTP streams, client reads both and if any ordered packet is missing, is grabbed from the other RTP stream. RTP requires buffering which can introduce unwanted jitter. |
Beta Was this translation helpful? Give feedback.
-
What I have been trying to sort out is adding gums to six2scte35,
it kind of make sense to be able to send the output over a network.
It works, but I have noticed an occasional video artifact with high bit rate streams.
Testing for multicast does make sense, I didn't think of that.
I had to drop the nonblocking,
My sockets kept getting stuck open.
SSM I don't know.
I have been wanting to add srtp to new_reader though.
…On Mar 15, 2023, 3:48 PM, at 3:48 PM, midicase ***@***.***> wrote:
In C we just test if multicast address, no need for extra arg:
`if ((inet_addr(address) & 0x000000F0) == 0x000000E0)
`
Python might have to range compare. Less stuff for users to figure
out, the easier.
If you want more optional features to add:
Source-specific multicast (SSM) receive.
https://en.wikipedia.org/wiki/Source-specific_multicast
RTP handling (sending is easy).
https://en.wikipedia.org/wiki/Real-time_Transport_Protocol
SSM we use for backup systems. Some broadcast plants send redundant
streams from multiple sources and the client can switch between them as
needed (usually for redundancy purposes).
RTP is just a re-ordering protocol. It's most edffective in SMPTE
2022-7. Dual identical RTP streams, client reads both and if any
ordered packet is missing, is grabbed from the other RTP stream. RTP
requires buffering which can introduce unwanted jitter.
--
Reply to this email directly or view it on GitHub:
#33 (comment)
You are receiving this because you are subscribed to this thread.
Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Hi futzu, i had use this .. |
Beta Was this translation helpful? Give feedback.
-
The new tool six2scte35 changes stream type 0x6 back to scte35
futzu wrote.. "I don't know how to stop ffmpeg from changing the SCTE35 stream type to 0x6."
FYI - I did some experiments with this and it seems to be a limitation of FFmpeg's TS muxer.
If I use the NUT container (FFmpeg's proprietary container format), the
-tag:d
can be used to set the type. In theory, this tag should also be capable of setting the type via a fourcc value, but that does not seem to be supported for data streams. Hex or decimal work with a NUT container though.In this case, the stream description was changed from
scte_35
tonone
.If the same command is used with an MPEG-TS container, the FFmpeg muxer overwrites the type to be 0x6. At runtime / console output, it claims it is setting the 0x86, but when probed, the file output is 0x6.
In this case, the stream type was changed from
scte_35
tobin_data
.This is not an issue with threefive, it is purely informational and can be closed. I recognize that threefive successfully works around FFmpeg's limitation. Raising the ticket was just a means of sharing knowledge and narrowing down where FFmpeg was struggling. Neither does the ticket solve the issue because the ultimate goal is setting it in a TS container, not a NUT container. Feel free to close this issue.
Beta Was this translation helpful? Give feedback.
All reactions