[FFmpeg-user] Illustration review, Streams and GOP Frame Reordering [was: a couple of things to look at]
Jim DeLaHunt
list+ffmpeg-user at jdlh.com
Mon Mar 4 01:33:07 EET 2024
Mark:
On 2024-03-02 19:51, Mark Filipak wrote:
> I have a couple of things to look at.
>
> https://markfilipak.github.io/Video-Object-Notation/Streams.html
> https://markfilipak.github.io/Video-Object-Notation/GOP%20%26%20Frame%20Reordering.html
>
>
> Comments are welcome. Please be brutal. 'Streams' is crucial.
Good work! I think both of these illustrations are helpful. The Streams
illustration is improved since the draft I saw earlier.
Regarding the Streams illustration
<https://markfilipak.github.io/Video-Object-Notation/Streams.html>:
The macroblock to slice to picdata transition is clear. Showing 45
macroblocks in a horizontal slice works. Good work.
In fact, I think the complete list of 45 macroblocks in a horizontal
slice is not necessary. You could keep, say, blocks 0..11, elide blocks
12..42 with a horizontal ellipsis, and keep blocks 43..44. With the
horizontal space saved, make the block numbers two digits. It is hard to
count out 45 from single-digit numbers. 00..44 would be much clearer.
The complete list of 0..29 slices is visually overwhelming, and not
necessary. I think you could keep slices 0..2, elide slices 3..27 with
a vertical ellipsis, and keep slices 28..29. That would get the slice
structure across.
The slice structure lacks a comment with size, of the sort you included
for macroblock and picdata. The full slice structure does not leave any
room for such a comment. But the vertical ellipsis for slices 3..27 will
be horizontally compact, so you could place a comment with the slice
size next to the ellipsis.
Regarding the GOP & Frame Reordering illustration,
<https://markfilipak.github.io/Video-Object-Notation/GOP%20%26%20Frame%20Reordering.html>:
Time is plastic in illustration space also. You have term definitions
which happen after the first use of those terms. It would be easier to
follow if the term definitions could come at first use.
The opening text, "an I-frame followed by P-frames and optional
B-frames", could be improved by adding term definitions. e.g. "an
I-frame (complete unto itself, sometimes called keyframe) followed by
P-frames (predictive based on differences with the preceding I-frame)
and optional B-frames (bipredictive based on differences with the
preceding P-frame and I-frame)".
The first rectangle, GOP specimen, gives a particular frame order.
Which order is this? Is this the order of frames in the incoming data
stream, before reording? That specimen seems to be in PTS order. Is
this necessary, or coincidental?
What reordering happens in the first step? Is it reordering from
incoming stream order to DTS order?
I don't get how the conveyor belt metaphor and illustrations add value.
You could just show frames in DTS order, and say that the decoder
operates on them in DTS sequence. Maybe show the frames in DTS order,
with arrows from each P-frame to the corresponding I-frame, and from
each B-frame to the corresponding I-frame and P-frame.
Then show arrows from that sequence down to the same frames, in PTS order.
It is not clear to me why the final two B-frames have later DTSs than
the following I-frame, but earlier PTSs. Why would these B-frames not
be relative to the first I-frame? If they are relative to the second
I-frame, why would that I-frame not have an earlier DTS? Are the
B-frames relative to the final P-frame before them? What is going on
visually that the encoder would choose to sequence things this way?
It is great to have a reference to the specification which you are
illustrating, "ITU-T H.262 (02/2012)". It would be even better to have
that at the beginning. The illustration might explain its goal, e.g.
"This illustrates the Group of Pictures and frame reordering operations
as described in ITU-T H.262 (02/2012)."
And, these diagrams are amazing works of character graphics. They would
be even more amazing as works of vector graphics. But drawing them in
vector graphics would require a different skill-set.
Keep up the good work!
More information about the ffmpeg-user
mailing list