[FFmpeg-user] ffprobe -show_frames values

[Joel Lopez]

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

[Werner Robitza]

Post by Joel Lopez
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.

Post by Joel Lopez
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.

[Joel Lopez]

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]

Post by Werner Robitza

Post by Joel Lopez
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.

Post by Joel Lopez
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
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Werner Robitza]

Post by Joel Lopez
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.

Post by Joel Lopez
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.

[Joel Lopez]

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

Post by Werner Robitza

Post by Joel Lopez
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.

Post by Joel Lopez
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?

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
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Werner Robitza]

Post by Joel Lopez
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.

[Nicolas George]

Post by Werner Robitza
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,

[Christian Ebert]

* Nicolas George on Tuesday, May 05, 2015 at 17:28:33 +0200

Post by Nicolas George
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.

[Werner Robitza]

Post by Christian Ebert
* Nicolas George on Tuesday, May 05, 2015 at 17:28:33 +0200

Post by Nicolas George
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.
-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.

[Christian Ebert]

* Werner Robitza on Tuesday, May 12, 2015 at 15:10:07 +0200

Post by Werner Robitza

Post by Christian Ebert
* Nicolas George on Tuesday, May 05, 2015 at 17:28:33 +0200

Post by Nicolas George
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.
-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.

[Anatol]

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

Post by Christian Ebert
* Werner Robitza on Tuesday, May 12, 2015 at 15:10:07 +0200

Post by Werner Robitza

Post by Christian Ebert
* Nicolas George on Tuesday, May 05, 2015 at 17:28:33 +0200

Post by Nicolas George
As an additional note, the second solution if by far preferable,

because

Post by Werner Robitza

Post by Christian Ebert

Post by Nicolas George
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.
-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
http://www.facebook.com/blacktrashproductions
_______________________________________________
ffmpeg-user mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Werner Robitza]

Post by Anatol
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.

[Anatol]

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.

Post by Anatol

Post by Anatol
Werner, can you please shortly explain the no-scenecut issue.
Without scenecut detection, if such event occurs in the middle of the

GOP,

Post by Anatol
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.

Post by Anatol
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
http://ffmpeg.org/mailman/listinfo/ffmpeg-user