-
Notifications
You must be signed in to change notification settings - Fork 18
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
Jerks in HLS when coverted from UDP. #14
Comments
I really need the stream if you want me to help you. That's just not enough information for me to diagnose your issue. A couple things jumped out at me though,
|
I did a bunch of UDP tuning in the new_reader package back in February, that's what x9k3 uses to read UDP. Update new_reader, that will probably help a lot. Sorry, I just remember that.
A guy was using really high bitrate video over UDP and we spent a good bit of time tuning up new_reader specifically for UDP. |
I just tested it over UDP and I get perfect playback, and my bitrate is a bit higher.
Do the stuff I mentioned above and let me know what happens. |
Talk to me Goose, let me know what's happening. We'll figure it out. |
Hey Buddy, this point helped to play smooth stream. but running for long time(approx more than 24hrs) creates the same issue again . |
Hi mate, I am writing on behalf of gaurav. After per your suggestion, we have reduced the chunk duration from 6 to 2 secs and set udp receive buffer max with sysctl as below : Post that HLS(.m3u8) stream is running fine but running for long duration (approx more than 24hrs) creates the same issue again. Is it because it exceeds the udp rx buffer size..just suspecting ? Few Asks:
|
You can detect UDP receive buffer issues (on Linux) with netstat -su In the output, under "Udp:" look at the number of "receive buffer errors". Ideally it is 0, suggesting that's not the problem. If > 0, that might be historical so run netstat -su repeatedly (e.g., use watch) to see if it's increasing. |
Yeah, I am familiar with netstat, and I don't usually need to adjust my receive buffer, but y'all didn't give me much to work with here as far being able diagnose your issue.
I wrote a tool called iframes, it should already be installed with x9k3, iframes udp://1.2.3.4:5000 it will spit out a list of where the iframes are located in terms of PTS. iframes /home/a/mpegts/pcrvid.ts
14648.092267
14648.342511
14648.509344
14648.7596
14649.009844
14649.2601
14649.426933 or you can make a shell script like this #!/bin/sh
ffprobe -loglevel error -skip_frame nokey -select_streams v:0 -show_entries frame=pts_time $1 | grep pts | awk -F"=" '{print $2,","}'
The is the simple explanation.
make sense? How GPU acceleration can be added to this workflow ?
|
How are y'all x9k3? what command line switches? |
x9k3 -i udp://@236.1.2.8:5000 -o /var/www/html/X9k3_hls_scte35/ -t 2 -T x_cue -w 6 -l -d we are using this command and we can see jerks after long run. |
I'm not with those guys. I'm just trying to help them. My other thought was timestamp rollover. This could make sense if the "after 24 hours" was actually 26.51 hours since their clock restarted. |
Rollover can be as pain in the ass, that's for sure, but I've had x9k3 running for months at a time without a problem. Each time it writes a segment it can reset the clock to anything because a lot of times the ads have wildly differing PTS, and I add DISCONTINUITY tags on every ad break. Even if there was a rollover problem, maybe one segment would be off. @gauravv5 I need to see it to help you. Let's try this, After it's been running for 24 hours, pypy3 -mpip install m3ufu OR python3 -mpip install m3ufu run m3ufu -i /var/www/html/X9k3_hls_scte35/index.m3u8 -o x9k3_test.ts let it run for two minutes and then ctrl-C to kill it and put x9k3_test.ts somewhere I can download it. |
Hi @futzu , I used python3 for installing x9k3. i will install m3ufu and share ts file. |
uneven duration when segment duration is set at 4 sec. |
https://we.tl/t-LrgKCPRG8t you can download this file from here |
The glitches and jerks are generally called video artifacts, and I got them when used x9k3 and streamed the video over UDP. I ran the command printf 26214400 > /proc/sys/net/core/rmem_max and then again streamed over UDP to x9k3 and it played perfectly. Here are your options:
For example: ffmpeg -copyts -i udp://1.2.3.4:3535 -map 0 -c copy - | x9k3 -d -w 6
Something like: 35 * * * * printf 26214400 > /proc/sys/net/core/rmem_max and see if that helps. |
hi @futzu, ffmpeg -copyts -i udp://1.2.3.4:3535 -map 0 -c copy - | x9k3 -d -w 6 we are getting this error:- Input #0, mpegts, from 'udp://236.1.2.8:5000': No Stream Found. so we have used and ingested output udp of feed to x9k3 running two different instances. we can still see the video artifacts in the same. Thanks for your extended support |
I'm sorry I gave you an incomplete command for ffmpeg ffmpeg -copyts -i udp://1.2.3.4:3535 -map 0 -c copy -f mpegts - | x9k3 -d -w 6 ffmpeg udp options https://ffmpeg.org/ffmpeg-protocols.html#udp |
@futzu , Thanks for the complete command. Except that part stream looks to run fine. |
@futzu i have recored logs from player when stream stucks i.e scte-35 is injested. [log] > [stream-controller]: Loaded fragment 826 of level 0 |
I really don't think the problem is x9k3,
That's not hls.js is it? |
Try this python3 -mpip install --upgrade threefive then when you run x9k3, turn on Shulga mode with -S (Shulga mode is named after a guy named Shulga who had h264 video but mpeg2 iframes.) |
Without Shulga mode: #EXT-X-X9K3-VERSION:0.1.89
#EXTINF:3.650022,
seg0.ts
#EXTINF:4.000000,
seg1.ts
#EXTINF:2.600000,
seg2.ts
#EXTINF:1.880000,
seg3.ts
#EXT-X-DISCONTINUITY
#EXT-X-CUE-OUT:20.0
#EXTINF:7.560000,
seg4.ts
#EXT-X-CUE-OUT-CONT:7.560000/20.0
#EXTINF:3.960000,
seg5.ts
#EXT-X-CUE-OUT-CONT:11.520000/20.0
#EXTINF:4.000000,
seg6.ts
#EXT-X-CUE-OUT-CONT:15.520000/20.0
#EXTINF:2.600000,
seg7.ts
#EXT-X-CUE-OUT-CONT:18.120000/20.0
#EXTINF:1.880000,
seg8.ts
#EXT-X-DISCONTINUITY
#EXT-X-CUE-OUT:20.0
#EXTINF:7.520000,
seg9.ts
#EXT-X-CUE-OUT-CONT:7.520000/20.0
#EXTINF:3.960000,
seg10.ts With Shulga mode: #EXT-X-X9K3-VERSION:0.1.89
#EXTINF:2.016000,
seg0.ts
#EXTINF:2.154022,
seg1.ts
#EXTINF:2.080000,
seg2.ts
#EXTINF:2.000000,
seg3.ts
#EXTINF:2.000000,
seg4.ts
#EXTINF:1.880000,
seg5.ts
#EXT-X-DISCONTINUITY
#EXT-X-CUE-OUT:20.0
#EXTINF:2.040000,
seg6.ts
#EXT-X-CUE-OUT-CONT:2.040000/20.0
#EXTINF:2.080000,
seg7.ts
#EXT-X-CUE-OUT-CONT:4.120000/20.0
#EXTINF:2.000000,
seg8.ts
#EXT-X-CUE-OUT-CONT:6.120000/20.0
#EXTINF:2.000000,
seg9.ts
#EXT-X-CUE-OUT-CONT:8.120000/20.0
#EXTINF:2.000000,
seg10.ts
#EXT-X-CUE-OUT-CONT:10.120000/20.0
#EXTINF:2.109978, |
can you please brief what Shulga mode do? |
(Shulga mode is named after a guy named Shulga who had h264 video but mpeg2 iframes.) Look man, it's not x9k3.We got the udp sorted by adjusting your system settings, and it worked fine. It works fine for me. Like I said, x9k3 just slices the video, it does not alter anything. |
Thanks Adrian mate, We appreciate your help on the subject and we are working to improve the encoding part so that DVB-Compliant stream will ingest into the X9K3 workflow solution. Thanks much for your support. Regards, |
I wish I had a better answer for you, but I don't. |
No problem Adrian mate. We really appreciate your help and support. |
HI @futzu, we need your assistance we are trying to transcode ts genrated by x9k3 to multi birate ts. I would share my development if needed to check Any help would be appreciated. Thanks |
That's going to be fault of the encoding. I'll tell you this, audio is often out of sync with video, I see it a lot in mpegts. x9k3 is not going to fix that, or make it happen either. |
Hi @futzu, X9K3 works fine with the DVB-Complaint input stream and able to create single profile HLS manifest(index.m3u8) Problem we are facing when we are trying to create a multi-bitrate profiles(1080p, 720p, 576p, 480p, 320p) from the .ts chunks created from X9K3 (UDP to HLS translation) as part of the index.m3u8 We are trying to pickup those .ts chunks for creating master manifest (master.m3u8) along with multi-bitrate profiles, with that we are facing pts alignment problem as mentioned by gaurav we need your help if you can assist us on the same.. |
That is not an x9k3 issue man. |
Hi @futzu mate, Please share your email id and contact details so that we can discuss on the same from commercial perspective |
@futzu mate, As i have mentioned, our solution works fine with single profile & manifest. The problem is with multi-bitrate along with master.m3u8 |
I'm sorry, I keep forgetting to reply to you. I am kind of busy right now, probably for the next month. What are you using to encode the video? If you are using ffmpeg, make sure start with Here's what I would try re-encode with ffmpeg and pipe it to x9k3 (don't set the input for x9k3 if you pipe to it) See if that works better when you encode the chunks |
Now the above is just a way to help you figure out where the problem may be. Another idea, do what you're doing now, but just make two variants and keep the very close in scale, if you scale video up or down more than twice it's size, it can be problematic. Just to test , just encode one variant from the x9k3 chunks and keep it very close in scale. Like if it's 960 , do a variant at 768, and see if that works better. |
No response for 3 weeks so I am closing this. |
when Udp stream contains scte35 stream, hls shows some jerks and glitches. whereas when udp stream without scte35 is used it run smoothly. @futzu please help.
The text was updated successfully, but these errors were encountered: