Hi, on the commandline I call ffprobe -loglevel quiet -of compact=s=_ -select_streams v -show_entries stream=refs video.mp4 and get the result stream_refs=1 When I add an argument, I'm presented with a different result ffprobe -loglevel quiet -of compact=s=_ -select_streams v -show_entries stream=refs -analyze_frames video.mp4 returns stream_refs=16 I took some time and a step debugger. ffprobe calls a function avformat_find_stream_info from its open_input_file Deep down there is a variable avctx that says refs=16 That information is lost. Later, under certain conditions, - if (do_read_frames || do_read_packets) { - the video is read and decoded. Only then, refs is populated with the correct value. I'm wondering why it is output, at all, if I call ffprobe without analyze_frames, when the value is wrong. I saw there's the function codec_close in demux.c that calls ret = avcodec_parameters_from_context(par_tmp, sti->avctx); ret = avcodec_parameters_to_context(avctx_new, par_tmp); avctx_new->pkt_timebase = sti->avctx->pkt_timebase; This looks to me, like you are saving the timebase. Can refs be saved in a similar manner and output as the correct value without analyzing frames? Best, Bernhard
Am 23.12.2025 um 02:08 schrieb Bernhard Döbler:
When I add an argument, I'm presented with a different result ffprobe -loglevel quiet -of compact=s=_ -select_streams v -show_entries stream=refs -analyze_frames video.mp4
returns stream_refs=16
The thing goes a bit further I call ffprobe -loglevel debug -of compact=s=_ -select_streams v -show_entries stream=refs -analyze_frames Stinkstiefel.mp4 >ffprobe.out 2>ffprobe.err Again, the .out file reads stream_refs=16 In the .err file there is this line Stream #0:0[0x1](deu), 2, 1/12800: Video: h264 (High), 1 reference frame (avc1 / 0x31637661), yuv420p(tv, bt709, progressive, left), 768x576 [SAR 1:1 DAR 4:3], 0/1, 1474 kb/s, 25 fps, 25 tbr, 12800 tbn (default) I guess this can easily be fixed. File libavformat\dump.c creates its own AVCodecContext for dumping and can simply access the correct refs number like avctx->refs = sti->avctx->refs; in line 628, maybe. In file libavformat\avformat.c there's this wonderful function av_stream_get_codec_timebase This was deprecated and it's not in use but I guess this solved a similar problem I'm facing - accessing the extended information of the AVStream/FFStream in a CLI program that does not access internal.h
On 12/23/25 02:08, Bernhard Döbler via ffmpeg-user wrote:
Later, under certain conditions, - if (do_read_frames || do_read_packets) { - the video is read and decoded. Only then, refs is populated with the correct value.
I'm wondering why it is output, at all, if I call ffprobe without analyze_frames, when the value is wrong.
"refs" does not belong to AVCodecParameters, so the logic actually is to require a further analysis with ffprobe's own decoder, that is by design (note that, in general, a decoder is not always required to populate AVCodecParameters fields). I think you are right, "refs" should not be displayed here, the information is always wrong if not reading frames ; maybe it should be moved to side data or simply hidden. I go talk this with devel... Anyway, maybe I miss the point, but you can simply combine analyze_frames with "-read_intervals %+0.1" to your command line to keep it lightweight, so it should be no big deal for your use case. Nicolas
Am 06.01.2026 um 17:03 schrieb Nicolas Gaullier via ffmpeg-user:
"refs" does not belong to AVCodecParameters, so the logic actually is to require a further analysis with ffprobe's own decoder, that is by design (note that, in general, a decoder is not always required to populate AVCodecParameters fields).
I think you are right, "refs" should not be displayed here, the information is always wrong if not reading frames ; maybe it should be moved to side data or simply hidden. I go talk this with devel...
Anyway, maybe I miss the point, but you can simply combine analyze_frames with "-read_intervals %+0.1" to your command line to keep it lightweight, so it should be no big deal for your use case.
Thanks for the reply, I didn't forget this subject. I just didn't find time to return to this subject after the holidays. However, thank you for the hint regarding "read-intervals" which makes the reading of the file quicker. Thank you for the confirmation of my impression, that the "refs" information is always wrong, maybe you can tyke it out, so it does not confuse other users. Best, Bernhard
On 1/25/26 21:33, Bernhard Döbler via ffmpeg-user wrote:
Thank you for the confirmation of my impression, that the "refs" information is always wrong, maybe you can tyke it out, so it does not confuse other users.
It is well on track: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21398 Nicolas
participants (2)
-
Bernhard Döbler -
Nicolas Gaullier