Opened 4 years ago
Closed 3 years ago
#8657 closed defect (fixed)
read_intervals parameter in ffprobe skips comma separated intervals
Reported by: | zeco | Owned by: | |
---|---|---|---|
Priority: | important | Component: | ffprobe |
Version: | git-master | Keywords: | regression |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Summary of the bug:
As of current versions (tested with ffmpeg 4.2.2), giving ffprobe a comma-separated list of intervals using the -read_intervals parameter will only yield results for the first given interval, while the rest of the list is skipped.
In earlier versions (tested with 3.2.14) ffprobe -read_intervals did process all the given intervals, conforming with the parameter's current documentation.
I can try to pinpoint the first affected version between 3.2.14 and 4.2.2 closer if requested.
How to reproduce:
% ffmpeg-3.2.14/ffprobe -read_intervals 10%+#1,20%+#1,30%+#1 -show_entries frame=pkt_pts_time -v error test.mp4 [FRAME] pkt_pts_time=8.000000 [/FRAME] [FRAME] pkt_pts_time=20.000000 [/FRAME] [FRAME] pkt_pts_time=28.000000 [/FRAME] % ffmpeg-4.2.2/ffprobe -read_intervals 10%+#1,20%+#1,30%+#1 -show_entries frame=pkt_pts_time -v error test.mp4 [FRAME] pkt_pts_time=8.000000 [/FRAME]
Built on intel + arm.
Specifying time codes as end positions instead of a packet count (+#1) has no effect on the issue either.
Change History (4)
comment:1 by , 4 years ago
Keywords: | regression added; read_intervals removed |
---|---|
Priority: | normal → important |
Version: | 4.2 → unspecified |
comment:2 by , 4 years ago
The issue is reproducible with the current FFmpeg git head (commit #ba0d785).
Here is the unabridged output from the same command as above (minus -v error for default log level) given to the current git head's version of ffprobe:
% ffprobe -read_intervals 10%+#1,20%+#1,30%+#1 -show_entries frame=pkt_pts_time test.mp4 ffprobe version N-97645-gba0d785 Copyright (c) 2007-2020 the FFmpeg developers built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.11) 20160609 configuration: libavutil 56. 43.100 / 56. 43.100 libavcodec 58. 82.100 / 58. 82.100 libavformat 58. 43.100 / 58. 43.100 libavdevice 58. 9.103 / 58. 9.103 libavfilter 7. 80.100 / 7. 80.100 libswscale 5. 6.101 / 5. 6.101 libswresample 3. 6.100 / 3. 6.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf57.83.100 Duration: 01:09:56.00, start: 0.000000, bitrate: 7565 kb/s Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 7560 kb/s, 50 fps, 50 tbr, 16k tbn, 100 tbc (default) Metadata: handler_name : VideoHandler [FRAME] pkt_pts_time=8.000000 [/FRAME]
The output should resemble what was shown with FFmpeg 3.2.14 above, i.e. there should be data for 3 frames.
comment:3 by , 4 years ago
Version: | unspecified → git-master |
---|
Regression since 2a88ebd096f3c748a2d99ed1b60b22879b3c567c
comment:4 by , 3 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed in 26cce232d7eb6bb07e6fb2883d4c52c9edf3e3d9.
Is the issue you see reproducible with current FFmpeg git head, the only version supported on this bug tracker?
Please provide the command line you tested with default or higher log level together with the complete, uncut console output to make this a valid ticket.