I am playing video streams using RTSP over TCP using FFPLAY and it plays fine when the vq value increases, but stops after 5-6 seconds when only the value before M-V increases.
nan M-V: nan fd= 0 aq= 0KB vq= 0KB sq= 0B f=0/0
......
......
Duration: N/A, start: 2.133467, bitrate: N/A
Stream #0:0: Video: h264 (Main), yuvj420p(pc), 1280x1024, 15 fps, 25 tbr, 90k tbn, 30 tbc
[swscaler @ 0x7fd9502403c0] deprecated pixel format used, make sure you did set range correctly
"76.81" M-V: -5.409 fd= 0 aq= 0KB vq= 0KB sq= 0B f=2/2 `
Can someone please explain what these M-V, fd, aq, vq, f are, as well as the value before M-V ("76.81")?
I had the same question and by looking in ffplay
source found this:
av_log(NULL, AV_LOG_INFO,
"%7.2f %s:%7.3f fd=%4d aq=%5dKB vq=%5dKB sq=%5dB f=%"PRId64"/%"PRId64" \r",
get_master_clock(is),
(is->audio_st && is->video_st) ? "A-V" : (is->video_st ? "M-V" : (is->audio_st ? "M-A" : " ")),
av_diff,
is->frame_drops_early + is->frame_drops_late,
aqsize / 1024,
vqsize / 1024,
sqsize,
is->video_st ? is->viddec.avctx->pts_correction_num_faulty_dts : 0,
is->video_st ? is->viddec.avctx->pts_correction_num_faulty_pts : 0)
Playing a sample video got a sample of the output:
7.11 A-V: 0.003 fd= 1 aq= 21KB vq= 321KB sq= 0B f=0/0
7.11 (master clock)
is the time from start of the stream/video
A-V (avdiff)
Difference between audio and video timestamps
fd
Number of frames dropped
aq
size of audio frame
vq
size of video frame
sq
size of subtitle frame
f
Timestamp error correction rate (Not 100% sure)
M-V
, M-A
means video stream only, audio stream only respectively.
I want to clarify that aq, vq
are "audio queue size" and "video queue size" respectively, not "size of audio/video frame" as in Marware answer.
Sorry for posting an incomplete answer but this thread is #1 result in google search for ffmpeg vq
and I hope that my clarification will be helpful for those who will happen to be here looking for what vq
means.
Here's some practical (but niche) example of what vq
(video queue size) means in a practical sense.
Let's say you are using ffplay to show a video from a security camera. In this particular case that vq
number (together with a camera stream bandwidth) will define a delay from the 'real-time' to the picture seen in ffplay.
For example, if a security camera delivers a high-quality 10Mbps stream and vq
is somewhere around 300K, then the latency/delay about 1/4 of a second. A quarter of a second delay is almost unnoticeable.
delay (seconds) = vq_number * 8 * 1024 / video_stream_bits_per_second
Now if the camera streams at 2Mbps and vq
is 1000K (not uncommon) the latency (delay) is about four seconds. That means what you see in ffplay right now was happening four seconds ago.
In any other case - the more vq
, the better. Larger vq
means there's enough data queued (buffered) for smooth video playback.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With