Rank: Advanced Member
Groups: Registered
Joined: 9/2/2015(UTC)
Posts: 35
Thanks: 5 times
Was thanked: 2 time(s) in 1 post(s)
|
When using a Transport Stream Pull input with 300ms caching, if the input video does a fade to black, the stream stutters badly. If I use VLC to do this the problem is "solved" but adds a lot of buffering, which other users has already stated here, and they don't think that this is a problem so don't seem they are going to fix it: https://forum.videolan.o...mp;t=154922&p=508727Here is a video example: vMix will output to a RTMP server, which gets the RTMP stream and serves it as a mpegts TCP stream, with some delay (SRT involved). When I change to a part of the video where the fade-to-black happens, you can see the stutter: https://femto.pw/m8h9.mp4I guess is because of bitrate fluctuations (the stream is created with constant bitrate by vMix itself, but with pitch-black frames the bitrate is still dropped). If I increase the buffering to ~2000ms, it somehow works as expected, but this is more a workaround than a solution. Also sometimes during the normal non-pitch black stream, it stutters, I guess because of the same problem.
|
|
|
|
|
|
Rank: Administration
Groups: Administrators
Joined: 1/13/2010(UTC) Posts: 5,211  Location: Gold Coast, Australia Was thanked: 4301 time(s) in 1523 post(s)
|
Hi,
Encoding for low latency purposes is a difficult process and converting a RTMP stream to do this is not likely to work.
Reason being, it is not designed to evenly space frames, and can often buffer smaller data together leading to the issues you noted.
So unless you use a different encoding solution, one that is designed for low latency (such as SRT), then you are going to have a tough time
getting consistent results at 300ms.
Regards,
Martin
vMix
|
|
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 9/2/2015(UTC)
Posts: 35
Thanks: 5 times
Was thanked: 2 time(s) in 1 post(s)
|
But SRT also creates a mpegts stream, the same thing that I'm doing with ffmpeg, and ffmpeg is creating a consistent output of frames. The only difference is the size of the frames, not the frames per second.
I also tried converting vMix dshow input (the same way vMix does when working with ffmpeg) and outputting it against tcp, having the exact same problem. You can test it yourselves.
Command line:
ffmpeg -rtbufsize 128M -f dshow -i video="vMix Video YV12":audio="vMix Audio" -codec:v libx264 -s:v 1920x1080 -pix_fmt:v yuv420p -threads 4 -bufsize:v 5000k -g:v 30 -preset:v veryfast -profile:v main -level:v 4.0 -x264opts:v keyint=30:min-keyint=30:scenecut=-1 -b:v 5000k -maxrate:v 5500k -codec:a aac -b:a 128k -strict -2 -f mpegts tcp://0.0.0.0:15000?listen
And then open a TCP PULL pointing to localhost:15000 and see what happens. Not RTMP involved, not anything. Just directly from vMix to vMix itself, and the bug happens.
I'm pretty sure in a vMix problem, as other mpegts players don't have this problem :-/
|
|
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 9/2/2015(UTC)
Posts: 35
Thanks: 5 times
Was thanked: 2 time(s) in 1 post(s)
|
Originally Posted by: admin  Hi,
Encoding for low latency purposes is a difficult process and converting a RTMP stream to do this is not likely to work.
Reason being, it is not designed to evenly space frames, and can often buffer smaller data together leading to the issues you noted.
So unless you use a different encoding solution, one that is designed for low latency (such as SRT), then you are going to have a tough time
getting consistent results at 300ms.
Regards,
Martin
vMix Yep, definitely is a vMix bug. VLC nightly works nice with 700ms delay and vMix with 700ms delay has stuttering, with the exact same input video: https://forum.videolan.o...mp;t=154922&p=509167
|
|
|
|
|
|
Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.
Important Information:
The vMix Forums uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
