HEVC/H.265 offers roughly double the compression efficiency of H.264 but carries licensing costs that keep many browsers from supporting it natively. This demo demuxes the MP4 container with isobmff_1, decodes the HEVC stream with libde265_1 and re-encodes it to H.264 with libx264_1 so that the native <video> element can play it back.
The source and the filter chain are the ones covered by the #libde265 functional test: a video-only sequence. Keeping the AAC audio track (and adding libfaad_1 to the pipeline) makes the muxer abort - "PID(s) configuration unknown on one or more inputs" - because the decoded audio has no encoder in this chain.
Known issue: with the current build this pipeline still produces an empty MP4 - libde265_1 emits no frames, so libx264_1 encodes none and the muxer writes a header-only file. The #libde265 test does not catch it: it only waits for the decoding promise to settle and never inspects the file it produced. If your browser happens to support HEVC natively, the <video> tag may still start playing the source directly - that's the browser's own built-in decoder, not this pipeline.
<video is="universal-video_1" src="hevcds_720p30_2M.mp4" using="solver_1" with="libde265_1;isobmff_1;libx264_1" controls> </video>
The specifications of the test sequence are :
| Format | MP4 (HEVC, video only) |
| FileSize | 30.5 Mo |
| Solver | solver_1 |