3

The following commands generate two H.264 video clips, 10 seconds each, with different preset parameters (veryslow vs veryfast), and join them into one single MP4 container.

$ ffmpeg -loglevel quiet -f rawvideo -pix_fmt rgba -s 1920x1080 -r 30 -i /dev/zero -pix_fmt yuv420p -c:v libx264 -preset:v veryslow -t 10 part1.mp4
$ ffmpeg -loglevel quiet -f rawvideo -pix_fmt rgba -s 1920x1080 -r 30 -i /dev/zero -pix_fmt yuv420p -c:v libx264 -preset:v veryfast -t 10 part2.mp4
$ cat list
file part1.mp4
file part2.mp4
$ ffmpeg -f concat -i list -c copy join.mp4

So far so good. But if I try to play that file with ffplay, I get a lot of errors like "decode_slice_header error", "illegal reordering_of_pic_nums_idc".

If two clips are both encoded with the same preset there is no problem.

Does that mean I cannot join two H.264 streams if they have different encoding parameters, even if their sizes, frame rates and pixel formats are all the same?

2 Answers 2

1

In general, you can't.

The preset doesn't result in a different video, unless your constrain is bandwidth, then a slower preset will give you better efficiency. But it will affect some of the parameters that the decoder needs to initialize itself, which is why it probably can't deal with mixing different bitstreams.

There might be a possibility to still concatenate the files in the decoded domain (e.g. by using the concat filter), but definitely not on a raw bitstream level. Which means you have to re-encode after concatenation.

What you could try to do is concatenate the raw bytestreams:

ffmpeg -i part1.mp4 -c:v copy -an -f h264 part1.264
ffmpeg -i part2.mp4 -c:v copy -an -f h264 part2.264
cat part1.264 part2.s264 concat.264
ffmpeg -i concat.264 -c:v copy output.mp4

But I couldn't try this now, so your mileage may vary.

0

While the H.264 spec and ISOBMFF have syntax to permit changing the VPS/SPS/PPS during a stream, it is likely that either or both

  • ffmpeg is not expecting this and is not constructing the mp4 file correctly
  • the playback software isn't capable of decoding an mp4 file containing more than one SPS/PPS set.

If you are able to use an MPEG TS instead of an MP4 then see if you can mux the parts to mpegts and then concatenate the two transport streams to form the final (cat part1.ts part2.ts > join.ts) . MPEG TS decoders are much more likely to include logic to parse a change of SPS/PPS.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .