Container — 3GP
One H.264 elementary stream wrapped in 3GP. Every file in this group was produced from the SAME encode with a stream copy, so the compressed video bytes are identical and the container is genuinely the only difference. The mobile profile of MP4, from the feature-phone era. Still emitted by some Android capture paths, so it turns up in user uploads.
Rendered preview of the 3gp file (23 KB). Download above for the original.
Specifications
- Resolution
- 480x270
- Fps
- 24
- Duration
- 1s
- Container
- 3GP
- Codec
- H.264 (libx264) — identical across this group
- Remux
- stream copy — video bytes are unchanged
- Audio
- none
Testing contract
Reference control- Scenario
- Demux the video stream out of the container and compare the extracted elementary stream against the one from any other member of this group.
- Expected result
- The container is 3GP and the video is H.264 (libx264) — identical across this group. Every member of this group was produced by a stream copy, so the encoded video bytes are unchanged across all seven - the extracted elementary streams must be identical, and only the container framing differs. 480x270 at 24 fps, 1s, no audio.
What is a .3gp file?
3GP is the mobile profile of the ISO base media file format, defined by 3GPP for 3G handsets and for video sent over MMS. It shares MP4's box structure and announces itself with an `ftyp` brand such as `3gp4` or `3gp6`, but wraps H.263, MPEG-4 Part 2, or H.264 video with AMR-NB, AMR-WB, or AAC audio at bitrates a 2000s cellular link could sustain. Almost every .3gp file in the wild is an old camera-phone capture; the near-identical .3g2 is 3GPP2's version for CDMA2000 networks.
How to use this file
Use an example .3gp clip to test mobile-video players, ISOBMFF demuxers, and 3GP-to-MP4 transcoding, confirming that the 3GP brands are recognized as valid MP4 relatives, and that AMR audio is decoded rather than dropped, which is the usual reason a converted clip plays silently.
How to use this file for testing
“Container — 3GP” is a deterministic Novus Examples fixture for Video codecs, Conversion testing, Video QA. One source encoded as H.264, HEVC, AV1, VP9, MJPEG, and a ProRes-compatible mezzanine, across 8/10/12-bit and 4:2:0/4:2:2/4:4:4, for testing decoder support, transcode pipelines, and container remuxing.
Documented properties for this file: 1s · 24 fps. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such, expect parsers to fail loudly rather than silently accept them.
Media fixtures are short and synthetic by design. Prefer waveform or transcript ground truth in the same group when measuring ASR, trim, upscale, or sync tools; do not assume broadcast-quality masters.
Related files
- webmAlpha Channel — Opaque VP9 TwinThe same codec and container with NO alpha plane, as the control for the alpha clip in this group. Useful for checking that alpha detection reads the pixel format rather than assuming every WebM is transparent — and for confirming a compositing bug is in the alpha handling rather than in the player.
- webmAlpha Channel — VP9 in WebMVideo with a real per-pixel alpha channel: VP9 yuva420p in WebM, the one alpha path browsers decode natively. Composite it over a page background and the transparency is genuine, not a chroma key. Roughly 90% of each frame is fully transparent. Two traps this file exists to expose. First, auto-alt-ref must be disabled at encode time or libvpx silently drops the alpha plane, producing a valid file with no transparency and no error. Second, WebM stores VP9 alpha in BlockAdditional and signals it with AlphaMode=1, so FFmpeg's NATIVE vp9 decoder reports pix_fmt yuv420p and decodes fully opaque — you must force `-c:v libvpx-vp9` to see the alpha at all. Probing this file with default settings and concluding it has no alpha is the expected mistake.
- mp4Bitstream — All-Intra (Every Frame a Keyframe)Every frame is an I-frame, so any frame is an independent cut point. Much larger, and the shape editing and frame-accurate seeking want. Same picture and same codec as every other clip in this group — only the GOP and frame-type structure differ, so the effect on size and seekability is directly attributable.
- mp4Bitstream — Heavy B-Frames (8 Consecutive)Eight consecutive B-frames with a B-pyramid, so decode order and display order diverge sharply and DTS runs well behind PTS. The case that breaks naive timestamp handling and any code that assumes frames arrive in display order. Same picture and same codec as every other clip in this group — only the GOP and frame-type structure differ, so the effect on size and seekability is directly attributable.
- mp4Bitstream — Long GOP (24 Frames, One Per Second)One keyframe per second — the delivery default, and the setting that determines HLS/DASH segment boundaries, since a segment must start on a keyframe. Same picture and same codec as every other clip in this group — only the GOP and frame-type structure differ, so the effect on size and seekability is directly attributable.
- mp4Bitstream — No B-FramesI and P frames only. Required by some low-latency and legacy decoders, and it removes the reordering that makes decode order differ from display order. Same picture and same codec as every other clip in this group — only the GOP and frame-type structure differ, so the effect on size and seekability is directly attributable.
Generated by generation/video_codecs_wave.py. Free for any use, no attribution required, license.