because of #2249 (closed) I again looked a bit into the handling of extradata (SPS/PPS) by mkvmerge. And I have found two things:
- The fix for #1711 (closed) had an unintended side-consequence: It moved the SPS and PPS directly before the first slice after the SEI messages (or in case there was no SPS/PPS in front of a keyframe before . This is against the 22.214.171.124.1 of the spec: "Any sequence parameter set NAL unit containing the value of seq_parameter_set_id for the active sequence parameter set RBSP for a coded video sequence shall have the same content as that of the active sequence parameter set RBSP for the coded video sequence unless it follows the last access unit of the coded video sequence and precedes the first VCL NAL unit and the first SEI NAL unit containing a buffering period SEI message (when present) of another coded video sequence." Blurays usually contain said buffering period SEI messages (I think they have to). Hopefully one just has to replace the
std::front_inserter. ins.264 is a sample for this.
- I have also uploaded Two.SPS.PPS.264 to your server. About half-way through the movie, the used SPS and PPS change to another SPS/PPS pair with different sps-id and pps-id (and mkvmerge could put both of them in the CodecPrivate if it knew about them in advance=. Each SPS and PPS is only once in the file and therefore all the keyframes after the middle of the file can't be seeked to.