drgreen/scrcpy
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
scrcpy/app/src/video_buffer.h

77 lines
1.6 KiB
C
Raw Normal View History

Rename video_buffer to sc_video_buffer Add a scrcpy-specific prefix.
2021-06-26 15:02:18 +02:00
#ifndef SC_VIDEO_BUFFER_H
#define SC_VIDEO_BUFFER_H
Initial commit Start a new clean history from here.
2017-12-12 15:12:07 +01:00
Define feature test macros in common.h This enables necessary functions once for all. As a consequence, define common.h before any other header.
2021-01-08 19:24:51 +01:00
#include "common.h"
Replace SDL types by C99 standard types Scrcpy is a C11 project. Use the C99 standard types instead of the SDL-specific types: SDL_bool -> bool SintXX -> intXX_t UintXX -> uintXX_t
2019-03-02 23:52:22 +01:00
#include <stdbool.h>
Initial commit Start a new clean history from here.
2017-12-12 15:12:07 +01:00
Implement buffering To minimize latency (at the cost of jitter), scrcpy always displays a frame as soon as it available, without waiting. However, when recording (--record), it still writes the captured timestamps to the output file, so that the recorded file can be played correctly without jitter. Some real-time use cases might benefit from adding a small latency to compensate for jitter too. For example, few tens of seconds of latency for live-streaming are not important, but jitter is noticeable. Therefore, implement a buffering mechanism (disabled by default) to add a configurable latency delay. PR #2417 <https://github.com/Genymobile/scrcpy/issues/2417>
2021-07-04 15:24:51 +02:00
#include "clock.h"
Extract current video_buffer to frame_buffer The current video buffer only stores one pending frame. In order to add a new buffering feature, move this part to a separate "frame buffer". Keep the video_buffer, which currently delegates all its calls to the frame_buffer.
2021-07-04 12:39:03 +02:00
#include "frame_buffer.h"
Implement buffering To minimize latency (at the cost of jitter), scrcpy always displays a frame as soon as it available, without waiting. However, when recording (--record), it still writes the captured timestamps to the output file, so that the recorded file can be played correctly without jitter. Some real-time use cases might benefit from adding a small latency to compensate for jitter too. For example, few tens of seconds of latency for live-streaming are not important, but jitter is noticeable. Therefore, implement a buffering mechanism (disabled by default) to add a configurable latency delay. PR #2417 <https://github.com/Genymobile/scrcpy/issues/2417>
2021-07-04 15:24:51 +02:00
#include "util/queue.h"
#include "util/thread.h"
#include "util/tick.h"
Make SKIP_FRAMES a compilation flag The skip_frames flag was a non-configurable runtime flag. Since it is not exposed to the user, there is no need for a (possible) runtime cost. For testing purpose, we still want it to be configurable, so make it a compilation flag.
2018-02-07 12:25:52 +01:00
Initial commit Start a new clean history from here.
2017-12-12 15:12:07 +01:00
// forward declarations
typedef struct AVFrame AVFrame;
Implement buffering To minimize latency (at the cost of jitter), scrcpy always displays a frame as soon as it available, without waiting. However, when recording (--record), it still writes the captured timestamps to the output file, so that the recorded file can be played correctly without jitter. Some real-time use cases might benefit from adding a small latency to compensate for jitter too. For example, few tens of seconds of latency for live-streaming are not important, but jitter is noticeable. Therefore, implement a buffering mechanism (disabled by default) to add a configurable latency delay. PR #2417 <https://github.com/Genymobile/scrcpy/issues/2417>
2021-07-04 15:24:51 +02:00
struct sc_video_buffer_frame {
AVFrame *frame;
struct sc_video_buffer_frame *next;
Add buffering debugging tools Output buffering and clock logs by disabling a compilation flag.
2021-07-13 22:32:05 +02:00
#ifndef NDEBUG
sc_tick push_date;
#endif
Implement buffering To minimize latency (at the cost of jitter), scrcpy always displays a frame as soon as it available, without waiting. However, when recording (--record), it still writes the captured timestamps to the output file, so that the recorded file can be played correctly without jitter. Some real-time use cases might benefit from adding a small latency to compensate for jitter too. For example, few tens of seconds of latency for live-streaming are not important, but jitter is noticeable. Therefore, implement a buffering mechanism (disabled by default) to add a configurable latency delay. PR #2417 <https://github.com/Genymobile/scrcpy/issues/2417>
2021-07-04 15:24:51 +02:00
};
struct sc_video_buffer_frame_queue SC_QUEUE(struct sc_video_buffer_frame);
Rename video_buffer to sc_video_buffer Add a scrcpy-specific prefix.
2021-06-26 15:02:18 +02:00
struct sc_video_buffer {
Extract current video_buffer to frame_buffer The current video buffer only stores one pending frame. In order to add a new buffering feature, move this part to a separate "frame buffer". Keep the video_buffer, which currently delegates all its calls to the frame_buffer.
2021-07-04 12:39:03 +02:00
struct sc_frame_buffer fb;
Notify new frames via callbacks Currently, a frame is available to the consumer as soon as it is pushed by the producer (which can detect if the previous frame is skipped). Notify the new frames (and frame skipped) via callbacks instead. This paves the way to add (optional) buffering, which will introduce a delay between the time when the frame is produced and the time it is available to be consumed.
2021-07-04 12:42:22 +02:00
Implement buffering To minimize latency (at the cost of jitter), scrcpy always displays a frame as soon as it available, without waiting. However, when recording (--record), it still writes the captured timestamps to the output file, so that the recorded file can be played correctly without jitter. Some real-time use cases might benefit from adding a small latency to compensate for jitter too. For example, few tens of seconds of latency for live-streaming are not important, but jitter is noticeable. Therefore, implement a buffering mechanism (disabled by default) to add a configurable latency delay. PR #2417 <https://github.com/Genymobile/scrcpy/issues/2417>
2021-07-04 15:24:51 +02:00
sc_tick buffering_time;
// only if buffering_time > 0
struct {
sc_thread thread;
sc_mutex mutex;
sc_cond queue_cond;
sc_cond wait_cond;
struct sc_clock clock;
struct sc_video_buffer_frame_queue queue;
bool stopped;
} b; // buffering
Notify new frames via callbacks Currently, a frame is available to the consumer as soon as it is pushed by the producer (which can detect if the previous frame is skipped). Notify the new frames (and frame skipped) via callbacks instead. This paves the way to add (optional) buffering, which will introduce a delay between the time when the frame is produced and the time it is available to be consumed.
2021-07-04 12:42:22 +02:00
const struct sc_video_buffer_callbacks *cbs;
void *cbs_userdata;
};
struct sc_video_buffer_callbacks {
void (*on_new_frame)(struct sc_video_buffer *vb, bool previous_skipped,
void *userdata);
Initial commit Start a new clean history from here.
2017-12-12 15:12:07 +01:00
};
Replace SDL types by C99 standard types Scrcpy is a C11 project. Use the C99 standard types instead of the SDL-specific types: SDL_bool -> bool SintXX -> intXX_t UintXX -> uintXX_t
2019-03-02 23:52:22 +01:00
bool
Implement buffering To minimize latency (at the cost of jitter), scrcpy always displays a frame as soon as it available, without waiting. However, when recording (--record), it still writes the captured timestamps to the output file, so that the recorded file can be played correctly without jitter. Some real-time use cases might benefit from adding a small latency to compensate for jitter too. For example, few tens of seconds of latency for live-streaming are not important, but jitter is noticeable. Therefore, implement a buffering mechanism (disabled by default) to add a configurable latency delay. PR #2417 <https://github.com/Genymobile/scrcpy/issues/2417>
2021-07-04 15:24:51 +02:00
sc_video_buffer_init(struct sc_video_buffer *vb, sc_tick buffering_time,
Notify new frames via callbacks Currently, a frame is available to the consumer as soon as it is pushed by the producer (which can detect if the previous frame is skipped). Notify the new frames (and frame skipped) via callbacks instead. This paves the way to add (optional) buffering, which will introduce a delay between the time when the frame is produced and the time it is available to be consumed.
2021-07-04 12:42:22 +02:00
const struct sc_video_buffer_callbacks *cbs,
void *cbs_userdata);
Update code style Limit source code to 80 chars, and declare functions return type and modifiers on a separate line. This allows to avoid very long lines, and all function names are aligned. (We do this on VLC, and I like it.)
2019-03-02 20:09:56 +01:00
Implement buffering To minimize latency (at the cost of jitter), scrcpy always displays a frame as soon as it available, without waiting. However, when recording (--record), it still writes the captured timestamps to the output file, so that the recorded file can be played correctly without jitter. Some real-time use cases might benefit from adding a small latency to compensate for jitter too. For example, few tens of seconds of latency for live-streaming are not important, but jitter is noticeable. Therefore, implement a buffering mechanism (disabled by default) to add a configurable latency delay. PR #2417 <https://github.com/Genymobile/scrcpy/issues/2417>
2021-07-04 15:24:51 +02:00
bool
sc_video_buffer_start(struct sc_video_buffer *vb);
void
sc_video_buffer_stop(struct sc_video_buffer *vb);
void
sc_video_buffer_join(struct sc_video_buffer *vb);
Update code style Limit source code to 80 chars, and declare functions return type and modifiers on a separate line. This allows to avoid very long lines, and all function names are aligned. (We do this on VLC, and I like it.)
2019-03-02 20:09:56 +01:00
void
Rename video_buffer to sc_video_buffer Add a scrcpy-specific prefix.
2021-06-26 15:02:18 +02:00
sc_video_buffer_destroy(struct sc_video_buffer *vb);
Initial commit Start a new clean history from here.
2017-12-12 15:12:07 +01:00
Make video_buffer more generic The video buffer took ownership of the producer frame (so that it could swap frames quickly). In order to support multiple sinks plugged to the decoder, the decoded frame must not be consumed by the display video buffer. Therefore, move the producer and consumer frames out of the video buffer, and use FFmpeg AVFrame refcounting to share ownership while avoiding copies.
2021-04-11 15:01:05 +02:00
bool
Notify new frames via callbacks Currently, a frame is available to the consumer as soon as it is pushed by the producer (which can detect if the previous frame is skipped). Notify the new frames (and frame skipped) via callbacks instead. This paves the way to add (optional) buffering, which will introduce a delay between the time when the frame is produced and the time it is available to be consumed.
2021-07-04 12:42:22 +02:00
sc_video_buffer_push(struct sc_video_buffer *vb, const AVFrame *frame);
Move frame swapping logic to frame.c Expose frames_offer_decoded_frame() and frames_consume_rendered_frame() so that callers are not exposed to frame swapping (between the decoding and rendering frames) details.
2018-02-08 19:23:24 +01:00
Make video_buffer more generic The video buffer took ownership of the producer frame (so that it could swap frames quickly). In order to support multiple sinks plugged to the decoder, the decoded frame must not be consumed by the display video buffer. Therefore, move the producer and consumer frames out of the video buffer, and use FFmpeg AVFrame refcounting to share ownership while avoiding copies.
2021-04-11 15:01:05 +02:00
void
Rename video_buffer to sc_video_buffer Add a scrcpy-specific prefix.
2021-06-26 15:02:18 +02:00
sc_video_buffer_consume(struct sc_video_buffer *vb, AVFrame *dst);
Initial commit Start a new clean history from here.
2017-12-12 15:12:07 +01:00
#endif
Reference in New Issue Copy Permalink