ffprobe -show_frames values
Hi, I'm trying to decipher what the values are in the info presented. I need to determine how far apart the keyframes are. 3 seconds is what I hear they should be for adaptive bitrate switching. Are these miliseconds and bytes? pkt_pts=754100 pkt_pts_time=251.366667 pkt_dts=754100 pkt_dts_time=251.366667 best_effort_timestamp=754100 best_effort_timestamp_time=251.366667 pkt_duration=100 pkt_duration_time=0.033333 pkt_pos=69183588 pkt_size=140
On Wed, Apr 29, 2015 at 8:36 PM, Joel Lopez <badassmexican@gmail.com> wrote:
Hi,
I'm trying to decipher what the values are in the info presented. I need to determine how far apart the keyframes are. 3 seconds is what I hear they should be for adaptive bitrate switching.
Anything between 2 and 10 seconds is reasonable.
Are these miliseconds and bytes?
PTS_time and DTS_time are in seconds. The size is in Bytes. But this won't tell you how far the keyframes are apart. For that, you'll need to check the "pict_type" field of the -show_frames option. Or, when your container is an MPEG-2 Transport Stream, check the "flags" field of the -show_packets option.
Thanks for the help. It's making a bit of sense now. It looks like my keyframes are 1/3 of a second. Is less than 2 seconds apart ok? In the pict_type field I'm seeing B's and P's with one I. Does that translate to how far apart they are? [FRAME] pkt_pts_time=244.700000 pkt_dts_time=244.700000 pict_type=P [/FRAME] [FRAME] pkt_pts_time=244.733333 pkt_dts_time=244.733333 pict_type=B [/FRAME] [FRAME] pkt_pts_time=244.766667 pkt_dts_time=244.766667 pict_type=P [/FRAME] [FRAME] pkt_pts_time=244.800000 pkt_dts_time=244.800000 pict_type=I [/FRAME] [FRAME] pkt_pts_time=244.833333 pkt_dts_time=244.833333 pict_type=B [/FRAME] [FRAME] pkt_pts_time=244.866667 pkt_dts_time=244.866667 pict_type=P [/FRAME] Here's the unfiltered output of a couple frames. [FRAME] media_type=video key_frame=0 pkt_pts=754000 pkt_pts_time=251.333333 pkt_dts=754000 pkt_dts_time=251.333333 best_effort_timestamp=754000 best_effort_timestamp_time=251.333333 pkt_duration=100 pkt_duration_time=0.033333 pkt_pos=69183172 pkt_size=138 width=1280 height=720 pix_fmt=yuv420p sample_aspect_ratio=N/A pict_type=P coded_picture_number=7539 display_picture_number=0 interlaced_frame=0 top_field_first=0 repeat_pict=0 [/FRAME] [FRAME] media_type=video key_frame=0 pkt_pts=754100 pkt_pts_time=251.366667 pkt_dts=754100 pkt_dts_time=251.366667 best_effort_timestamp=754100 best_effort_timestamp_time=251.366667 pkt_duration=100 pkt_duration_time=0.033333 pkt_pos=69183588 pkt_size=140 width=1280 height=720 pix_fmt=yuv420p sample_aspect_ratio=N/A pict_type=B coded_picture_number=7542 display_picture_number=0 interlaced_frame=0 top_field_first=0 repeat_pict=0 [/FRAME] On Thu, Apr 30, 2015 at 1:24 AM, Werner Robitza <werner.robitza@gmail.com> wrote:
On Wed, Apr 29, 2015 at 8:36 PM, Joel Lopez <badassmexican@gmail.com> wrote:
Hi,
I'm trying to decipher what the values are in the info presented. I need to determine how far apart the keyframes are. 3 seconds is what I hear they should be for adaptive bitrate switching.
Anything between 2 and 10 seconds is reasonable.
Are these miliseconds and bytes?
PTS_time and DTS_time are in seconds. The size is in Bytes.
But this won't tell you how far the keyframes are apart. For that, you'll need to check the "pict_type" field of the -show_frames option. Or, when your container is an MPEG-2 Transport Stream, check the "flags" field of the -show_packets option. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
On Thu, Apr 30, 2015 at 5:26 PM, Joel Lopez <badassmexican@gmail.com> wrote:
Thanks for the help. It's making a bit of sense now. It looks like my keyframes are 1/3 of a second. Is less than 2 seconds apart ok?
For adaptive streaming the keyframes should be at regular intervals. That means, for encoding, you'll have to specify a keyframe interval and disable scene cut detection, if any.
In the pict_type field I'm seeing B's and P's with one I. Does that translate to how far apart they are?
Use this command, which gives you output that's easier to read: ffprobe -select_streams v -show_frames -of csv -show_entries frame=pkt_pts_time, pict_type Now, assuming the PTS time increases in regular intervals, it'll be quite easy to count the distance (in number of frames) between I-frames, and the time interval. Just do the subtraction of the PTS between two consecutive I-frames.
That was definitely easier to read. I did a grep for "I" for my 4 versions of the same video at different bitrates. I can now tell that they keyframes aren't aligned and under 1 second apart. All my research says keyframes must be aligned and a constant separation between 2 - 10 seconds. Should I re-encode these videos or could they still work? I saw that it's be possible to force keyframes on an existing video. video 1 frame,0.000000,I frame,1.200000,I frame,1.266667,I frame,1.333333,I frame,3.000000,I frame,6.000000,I frame,9.000000,I frame,12.000000,I frame,15.000000,I frame,18.000000,I frame,21.000000,I frame,24.000000,I frame,27.000000,I frame,30.000000,I frame,33.000000,I frame,36.000000,I frame,39.000000,I frame,42.000000,I frame,45.000000,I frame,48.000000,I frame,51.000000,I frame,54.000000,I frame,57.000000,I frame,60.000000,I video 2 frame,0.000000,I frame,1.200000,I frame,1.266667,I frame,4.000000,I frame,8.000000,I frame,12.000000,I frame,16.000000,I frame,20.000000,I frame,24.000000,I frame,28.000000,I frame,32.000000,I frame,36.000000,I frame,40.000000,I frame,44.000000,I frame,48.000000,I frame,52.000000,I frame,56.000000,I frame,60.000000,I frame,64.000000,I frame,68.000000,I frame,72.000000,I frame,76.000000,I frame,80.000000,I frame,84.000000,I video 3 frame,0.000000,I frame,4.000000,I frame,8.000000,I frame,12.000000,I frame,16.000000,I frame,20.000000,I frame,24.000000,I frame,28.000000,I frame,32.000000,I frame,36.000000,I frame,40.000000,I frame,44.000000,I frame,48.000000,I frame,52.000000,I frame,56.000000,I frame,60.000000,I frame,64.000000,I frame,68.000000,I frame,72.000000,I frame,76.000000,I frame,80.000000,I frame,84.000000,I frame,88.000000,I frame,92.000000,I video 4 frame,0.000000,I frame,1.200000,I frame,5.200000,I frame,9.200000,I frame,13.200000,I frame,17.200000,I frame,21.200000,I frame,25.200000,I frame,29.200000,I frame,33.200000,I frame,37.200000,I frame,41.200000,I frame,45.200000,I frame,49.200000,I frame,53.200000,I frame,57.200000,I frame,61.200000,I frame,65.200000,I frame,69.200000,I frame,73.200000,I frame,77.200000,I frame,81.200000,I frame,85.200000,I frame,89.200000,I On Fri, May 1, 2015 at 2:13 AM, Werner Robitza <werner.robitza@gmail.com> wrote:
On Thu, Apr 30, 2015 at 5:26 PM, Joel Lopez <badassmexican@gmail.com> wrote:
Thanks for the help. It's making a bit of sense now. It looks like my keyframes are 1/3 of a second. Is less than 2 seconds apart ok?
For adaptive streaming the keyframes should be at regular intervals. That means, for encoding, you'll have to specify a keyframe interval and disable scene cut detection, if any.
In the pict_type field I'm seeing B's and P's with one I. Does that translate to how far apart they are?
Use this command, which gives you output that's easier to read:
ffprobe -select_streams v -show_frames -of csv -show_entries frame=pkt_pts_time, pict_type
Now, assuming the PTS time increases in regular intervals, it'll be quite easy to count the distance (in number of frames) between I-frames, and the time interval. Just do the subtraction of the PTS between two consecutive I-frames. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
On Tue, May 5, 2015 at 12:05 AM, Joel Lopez <badassmexican@gmail.com> wrote:
Should I re-encode these videos or could they still work? I saw that it's be possible to force keyframes on an existing video.
You need to re-encode them with either the force_key_frames option, or by setting the keyframe interval for your encoder, and disabling scene cut detection. For x264 this would be keyint=120:scenecut=-1 if you want a keyframe every 5 seconds for a 24 fps video. That's what's typically done. Please don't top-post on this mailing list; your reply should be below mine. Thanks.
Le sextidi 16 floréal, an CCXXIII, Werner Robitza a écrit :
You need to re-encode them with either the force_key_frames option, or by setting the keyframe interval for your encoder, and disabling scene cut detection. For x264 this would be keyint=120:scenecut=-1 if you want a keyframe every 5 seconds for a 24 fps video. That's what's typically done.
As an additional note, the second solution if by far preferable, because forcing the frame type too frequently ruins x264's bit allocation algorithms. Regards, -- Nicolas George
* Nicolas George on Tuesday, May 05, 2015 at 17:28:33 +0200
As an additional note, the second solution if by far preferable, because forcing the frame type too frequently ruins x264's bit allocation algorithms.
As per this thread elsewhere there are different opinions on that. Others say that no-scenecut is not adviseable because it obviously removes scene detection. Which one is it then: -force_key_frames or -x264opts keyint=xxx:no-scenecut ? Personally I got ok looking results both ways with various material. -- theatre - books - texts - movies Black Trash Productions at home: http://www.blacktrash.org Black Trash Productions on Facebook: http://www.facebook.com/blacktrashproductions
On Tue, May 12, 2015 at 2:45 PM, Christian Ebert <blacktrash@gmx.net> wrote:
* Nicolas George on Tuesday, May 05, 2015 at 17:28:33 +0200
As an additional note, the second solution if by far preferable, because forcing the frame type too frequently ruins x264's bit allocation algorithms.
As per this thread elsewhere there are different opinions on that. Others say that no-scenecut is not adviseable because it obviously removes scene detection.
Which one is it then:
-force_key_frames or -x264opts keyint=xxx:no-scenecut
?
Personally I got ok looking results both ways with various material.
I'm currently involved in ITU-T standardization of a quality model for adaptive streaming, and in our video sequences that we use for (subjective user) tests, we've disabled scene cut detection throughout, with good-looking results. Nothing unexpected.
* Werner Robitza on Tuesday, May 12, 2015 at 15:10:07 +0200
On Tue, May 12, 2015 at 2:45 PM, Christian Ebert <blacktrash@gmx.net> wrote:
* Nicolas George on Tuesday, May 05, 2015 at 17:28:33 +0200
As an additional note, the second solution if by far preferable, because forcing the frame type too frequently ruins x264's bit allocation algorithms.
As per this thread elsewhere there are different opinions on that. Others say that no-scenecut is not adviseable because it obviously removes scene detection.
Which one is it then:
-force_key_frames or -x264opts keyint=xxx:no-scenecut
?
Personally I got ok looking results both ways with various material.
I'm currently involved in ITU-T standardization of a quality model for adaptive streaming, and in our video sequences that we use for (subjective user) tests, we've disabled scene cut detection throughout, with good-looking results. Nothing unexpected.
Thanks for confirming. IIRC I had trouble with (some) older x264 versions and no-scenecut and had therefore worked with -force_key_frames for a while. But I cannot reproduce the problem with current x264, so I switched to x264opts with no-scenecut. -- theatre - books - texts - movies Black Trash Productions at home: http://www.blacktrash.org Black Trash Productions on Facebook: http://www.facebook.com/blacktrashproductions
Werner, can you please shortly explain the no-scenecut issue. Without scenecut detection, if such event occurs in the middle of the GOP, as it usually does, the video quality till the end of the GOP will be rather compromised. It appears as a 'breathing effect'. It is mostly stands out when a high quality video played on a large screen. Is there a way to avoid such effects without scene cut detection? Thanks, Anatol On Tue, May 12, 2015 at 4:45 PM, Christian Ebert <blacktrash@gmx.net> wrote:
* Werner Robitza on Tuesday, May 12, 2015 at 15:10:07 +0200
On Tue, May 12, 2015 at 2:45 PM, Christian Ebert <blacktrash@gmx.net> wrote:
* Nicolas George on Tuesday, May 05, 2015 at 17:28:33 +0200
As an additional note, the second solution if by far preferable, because forcing the frame type too frequently ruins x264's bit allocation algorithms.
As per this thread elsewhere there are different opinions on that. Others say that no-scenecut is not adviseable because it obviously removes scene detection.
Which one is it then:
-force_key_frames or -x264opts keyint=xxx:no-scenecut
?
Personally I got ok looking results both ways with various material.
I'm currently involved in ITU-T standardization of a quality model for adaptive streaming, and in our video sequences that we use for (subjective user) tests, we've disabled scene cut detection throughout, with good-looking results. Nothing unexpected.
Thanks for confirming. IIRC I had trouble with (some) older x264 versions and no-scenecut and had therefore worked with -force_key_frames for a while. But I cannot reproduce the problem with current x264, so I switched to x264opts with no-scenecut.
-- theatre - books - texts - movies Black Trash Productions at home: http://www.blacktrash.org Black Trash Productions on Facebook: http://www.facebook.com/blacktrashproductions _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
On Wed, May 13, 2015 at 7:07 AM, Anatol <anatol2002@gmail.com> wrote:
Werner, can you please shortly explain the no-scenecut issue. Without scenecut detection, if such event occurs in the middle of the GOP, as it usually does, the video quality till the end of the GOP will be rather compromised. It appears as a 'breathing effect'. It is mostly stands out when a high quality video played on a large screen. Is there a way to avoid such effects without scene cut detection?
I haven't seen this in real life but we had pretty short GOPs in our tests. Could it be that the bitrate is generally too low then? Perhaps the qpstep value can be increased to allow the encoder to choose a lower QP for the non-I frames following a scene cut. I still have to test the force_key_frames method to see whether the quality is really noticeably worse compared to disabling scene-cut detection altogether.
Thanks Werner. I believe that u'll find out that disabling scene cut detection might cause a significant quality reduction. Therefore, activating together the forced keyframes and the scene cut detection is probably the most reasonable compromise. On Wed, May 13, 2015 at 12:47 PM, Werner Robitza <werner.robitza@gmail.com> wrote:
On Wed, May 13, 2015 at 7:07 AM, Anatol <anatol2002@gmail.com> wrote:
Werner, can you please shortly explain the no-scenecut issue. Without scenecut detection, if such event occurs in the middle of the GOP, as it usually does, the video quality till the end of the GOP will be rather compromised. It appears as a 'breathing effect'. It is mostly stands out when a high quality video played on a large screen. Is there a way to avoid such effects without scene cut detection?
I haven't seen this in real life but we had pretty short GOPs in our tests. Could it be that the bitrate is generally too low then?
Perhaps the qpstep value can be increased to allow the encoder to choose a lower QP for the non-I frames following a scene cut.
I still have to test the force_key_frames method to see whether the quality is really noticeably worse compared to disabling scene-cut detection altogether. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
participants (5)
-
Anatol -
Christian Ebert -
Joel Lopez -
Nicolas George -
Werner Robitza