What's inside a video file
Open an .mp4 file expecting to find pixels and you'll find boxes instead: a container format, holding one or more streams, each stream holding a sequence of compressed data that only means something once it's decoded. None of that structure is visible from a media player's UI. All of it is why the file behaves the way it does.
A container holds streams
The container is the outer format, .mp4, .mkv, .ts, and its job is to hold and synchronize one or more streams. A typical video file has at least two: a video stream and an audio stream, sometimes a subtitle stream alongside them. The container interleaves data from each stream so a player can read a little video, a little audio, a little video, and keep both in sync without loading the whole file first.
Each stream carries exactly one kind of media, and only one codec's worth of compressed data. A video stream encoded with H.264 knows nothing about the audio stream sitting next to it in the same container. The two only share a timeline.
Streams are packets, packets become frames
Inside a stream, the data is a sequence of packets: chunks of compressed bytes, each one tagged with a timestamp and belonging to one stream. A decoder reads packets in order and turns them into frames, the actual pictures a video stream produces, or samples in the case of audio.
Packets arrive in decoding order, which isn't always the order frames are shown. With B-frames, decoding order and display order differ, so a decoder has to hold several frames before it can output them in the right sequence. Running ffprobe -show_frames against a real file makes both layers visible at once:
[FRAME]
key_frame=1
pts_time=0.000000
pict_type=I
[/FRAME]
[FRAME]
key_frame=0
pts_time=0.160000
pict_type=P
[/FRAME]
pict_type=I is a keyframe: a full picture that decodes on its own. pict_type=P depends on an earlier frame to fill in what changed. pts_time is when the frame should be shown, which is a separate question from the order it arrived in the stream.
NAL units inside H.264 and H.265
Within a compressed video stream, H.264 and H.265 break their data into NAL units, the basic packaging format both codecs use to store and transmit encoded video. Every frame's compressed data is split across one or more of them, and a NAL unit carries a type that tells a decoder what kind of data is inside: a slice of picture data, or something else entirely.
Two of those types matter more than the rest: the sequence parameter set (SPS) and the picture parameter set (PPS). Neither one carries picture data. Both carry the decoder configuration, resolution, profile, reference-frame settings, that every other NAL unit in the stream depends on to decode correctly. A decoder that hasn't seen the SPS and PPS yet can't make sense of the picture data that follows, no matter how well-formed that data is on its own.
Showing each layer instead of describing it
What The FFMPEG is BeemMeUp's answer to the fact that none of this is visible anywhere in a normal player. It takes an uploaded file through each layer in order: an overview of the container and its streams, a packet and frame timeline for the video stream specifically, and, underneath that, bitstream-level views for H.264 and H.265 content: a hex viewer, a NAL unit timeline, and a parameter-set viewer that reads the actual SPS and PPS out of the stream instead of just reporting "H.264" and stopping there.
Most tools tell you a file is H.264. Showing the SPS turns that into the exact profile an encoder chose and the exact settings a client would need to support to decode it, which is the question that actually matters when a video doesn't play the way it's supposed to.
A file that fails to play somewhere is rarely a mystery once you can see all four layers at once: the container that claims to hold it, the stream inside that container, the packets that stream is made of, and the parameter sets those packets depend on to mean anything at all.