why NUM_TEXTURES is 2 not 1, and how to reduce the video delay

yanrkchina

New Member
Hi,
I has some question about video delay
question 1:
why NUM_TEXTURES is 2 but not 1
I find NUM_TEXTURES is 2 mean "4 frames time" delay at least,
I change NUM_TEXTURES to 1, it seems work well and feel more real-time than before
question 2:
why still have 300ms delay after change NUM_TEXTURES to 1
I make a timestamp-mark on every packet, from "render_textures/output_textures/copy_surfaces" to "my rgb player",
timestamp show that "render_textures --> output_textures --> copy_surfaces -- frame --> encoder --> network --> decoder --> rgb-show" total use 70ms,
but why the picture seems delay 300ms?

wish your help, thanks!
 

Jim

Jim
Developer
Because if it's set to 1 the graphics card will stall while waiting for the previous stage in the graphics pipeline to complete, where as if it's set to 2, graphics processing will have a full frame worth of time to complete all queued graphics tasks.
 

yanrkchina

New Member
Because if it's set to 1 the graphics card will stall while waiting for the previous stage in the graphics pipeline to complete, where as if it's set to 2, graphics processing will have a full frame worth of time to complete all queued graphics tasks.
OK, thanks, do you know how to reduce the video delay, I find a soft named GameCC(游戏串) which is based on OBS yet, but it is very fast, I do not know how did them do? amazing.
 

yanrkchina

New Member
Today, I change the test flow (NUM_TEXTURES still been changed to 1)
1、only modify obs_render_main_texture()
replace render_textures with output_textures,It seems delay 0~70+ms
2、only add a rgb_callback() function in obs
and in output_video_data(),call rgb_callback(output_frame.data[0]), It seems delay 60~120+ms
Compare the two changes, seems obs-internal-draw [gs_draw_sprite] is faster than windows-draw [BitBlt]
 

R1CH

Forum Admin
Developer
If GameCC has lower latency, then you can look at their source code to see what they have changed.
 

yanrkchina

New Member
I haven't heard back from GameCC yet, but I did more test, this time I test with clock window capture not desktop capture

The original process
[clock window capture] -> [capture convert RGBA] -> [QSV encode] ->
[TCP send encoded H264 data] ->[TCP receives encoded H264 data] ->
[H264 decode] -> [H264 convert RGBA] -> [use BitBlt(RGBA) display image]
Switch to
[clock window capture] -> [capture convert RGBA] -> [QSV encoding] ->
[TCP send original RGBA data] ->[TCP receives original RGBA data] ->
[sleep 10 milliseconds] -> [use BitBlt(RGBA) display image]

In the above modification, the encoding process is retained, but the RGBA data is sent replace H264 data,
which is much larger and time-consuming than the original process.
Also, the sleep time is longer than "H264 decoding + H264 transfer RGBA",
which increases the overall time slightly,
But the overall delay is less than 100 milliseconds for the latter,
and more than 170 milliseconds for the former.

I have tried to change the number of B frames to 0, or send empty data once more when decoding to prevent decoding cache,
but I didn't see any difference
 

Kasey01

New Member
Hi,
I has some question about video delay
question 1:
why NUM_TEXTURES is 2 but not 1
I find NUM_TEXTURES is 2 mean "4 frames time" delay at least,
I change NUM_TEXTURES to 1, it seems work well and feel more real-time than before
question 2:
why still have 300ms delay after change NUM_TEXTURES to 1
I make a timestamp-mark on every packet, from "render_textures/output_textures/copy_surfaces" to "my rgb player",
timestamp show that "render_textures --> output_textures --> copy_surfaces -- frame --> encoder --> network --> decoder --> rgb-show" total use 70ms,
but why the picture seems delay 300ms? chatrandom

wish your help, thanks!
I would like to know how to delay the video. I have been struggling with it all this days.
 
Last edited:
Top