-
Notifications
You must be signed in to change notification settings - Fork 4
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
relative urls or absolute urls (variant m3u8 url resolving) #3
Comments
I'm not entirely sure why that's happening. Just to be clear, this is far from stable. |
Though, if you think about it, you really want to run this on the same machine, or else you're downloading all the variants at the same time, that's a lot of bandwidth, there is no way that can stay in sync. |
Hey man, I'm thinking what if umzz doesn't redo the segments and instead just rewrites the manifests with SCTE-35. The only problem is that if ad breaks don't start on segments, I'd have to round up to the next segment or something, what do you think? If I don't resegment, I only need to parse one variant. |
I think that resegmenting(rewriting) every segment for every variant is not neccesary... What do you think : If we say that ads are limited to for example 12 minutes/hour that it makes sense to do CPU operation only on 12/60 of segments at most. Than for reality you'd only have to resegment -update only first and last file of that adbreak to really resegment. That would than make CPU operation on 2 files per hour * #of variants. If operation is too cpu intensive you could also add app option --filterstreams=1,2,3 that would only take 3 variants from master file (when you run app and you know that variant with "4K" is too intensive). In that case above app option -w WINDOW_SIZE could be easily removed. btw: I really enjoy looking at what you can do with python. Great job! |
It's not CPU, it's the downloading. If the input is over the network, umzz is downloading all the variants at the same time, it's like playing all the variants at the same time, that's a lot of bandwidth, and a lot of I/O, I didn't realize all this until you started testing stuff. The big problem with NOT re-segmenting is that if there is a SCTE-35 splice point in the middle of a segment, it will have to be rounded up to the next segment, that's why God invented all black frames, to smooth out such things. The big gain is that I can parse one variant and determine where to add the SCTE-35 for all the other variants, So umzz would output just a master.m3u8 and the variant index.m3u8s, no new segments. |
Just my 2 cents :) Bandwidth should not be a problem... An app like this (umzz) is running normally in datacenter with Gigabit connection... If you look at my stream above you see that app will have total dl 352+.......=18691200bps = 18.5Mbps.... That's only 1/50 of total 1Gbps bandwidth available. And if you optimize - the truth is that you have to dl all segments of only minimal resolution stream to get info where to put scte split in (as we assume that all resolution files are aligned).. And than just wait for that "begin" and "end" .ts file that would have to be rewritten (shorten for first) , remove start for last - in this case for all resolutions. All other files are best just left on original hls segment url. Hope I got my idea right. Anorther problem I see with this cutting is that PTS will jump.. But if you insert HLS discontinuity player should handle that. |
that's a good point about the data centers. |
a@debian:~/build/clean/umzz$ umzz -v
umzz 0.0.3
New Version is up. |
I'm checking.. regarding my idea of getting iframe position only in 1st variant... I might be wrong... I'm looking at stream (rbmn-live) from above and PTSs were NOT aligned. umzz -i https://rbmn-live.akamaized.net/hls/live/590964/BoRB-AT/master.m3u8 -t 3 -p -s sidecar.txt -o /home/uporabnik/umzzoutput
|
Fix for resolving url @0.0.3 looks ok.. Above stream is playing. |
some progress..... |
ffrprobe https://rbmn-live.akamaized.net/hls/live/590964/BoRB-AT/master_578.m3u8 .....
[hls @ 0x55b73b3fda00] Opening 'https://rbmn-live.akamaized.net/hls/live/590964/BoRB-AT/20230404T122017/master_578/00095/master_578_01329.ts' for reading
Input #0, hls, from 'https://rbmn-live.akamaized.net/hls/live/590964/BoRB-AT/master_578.m3u8':
Duration: N/A, start: -10.425867, bitrate: N/A
Program 0 |
Just started testing v 0.0.1 .. When I tried example below it looks like it is wrong in resolving urls. Master.m3u8 below has full urls (non relative) for variants.
umzz -i https://rbmn-live.akamaized.net/hls/live/590964/BoRB-AT/master.m3u8 -s sidecar.txt -o /home/uporabnik/umzzoutput
however this in logs looks strange:
https://rbmn-live.akamaized.net/hls/live/590964/BoRB-AT/https://rbmn-live.akamaized.net/hls/live/590964/BoRB-AT/master_6660.m3u8 ...........Failed
Full repetable example:
The text was updated successfully, but these errors were encountered: