avformat code produce slightly different output than ffmpeg with same parameters - why?

I would like to achieve the exact same result as this ffmpeg command line call does from code:

ffmpeg -i CAMERARTSPLINK -c:v copy -an -movflags +frag_keyframe+empty_moov -f mp4

When I run the above command it gives this binary result:

got 36 bytes:  0, 0, 0, 36, 102, 116, 121, 112, ..., 111, 54, 109, 112, 52, 49, 
got 512 bytes: 0, 0, 3, 76, 109, 111, 111, 118, 0, 0, 0, ..., 132, 0, 0, 3, 0, 4, 0, 0, 3, 0, 202,

The code can utilize ffmpeg libraries and includes, but I don't want to use ffmpeg as a program call (i.e. exec* functions are not preferred).

I have created a small demonstration code example with avformat for an RTSP H264 to MP4 remux. The code is highly reuses horgh's nice videostreamer library.

I posted the sample code to pastebin.com (400 loc). It builds successfully but you need to link it against avformat, avdevice, avcodec and avutil.

I tried to do my best to reach the same result, however when I run this code, the first few bytes after byte #38 are different (maybe not just those, I did not compare anything after byte #548):

writeOutput: writing 36 bytes: 0, 0, 0, 36, 102, 116, 121, 112, ..., 111, 54, 109, 112, 52, 49, 
writeOutput: writing 512 bytes: 0, 0, 0, 0, 109, 111, 111, 118, 0, 0, 0, ..., 132, 0, 0, 3, 0, 4, 0, 0, 3, 0, 202, 

You can see on the second line of my code's output starts with 0 0 0 0 109,

whereas the ffmpeg gave 0 0 3 76 109.

All the rest (even the bytes are not pasted here) data are totally the same (at least for the first 548 bytes).

What is wrong with my code? These 2 bytes seems super-important for decoding this stream.

1 answer

  • answered 2020-02-14 21:11 szatmary

    102, 116, 121, 112 in ascii is ftyp This is the mp4 format type box. 0, 0, 0, 36 is the size of the box

    109, 111, 111, 118 in ascii is mdat This is the data box. 0, 0, 0, 0 is the size of the box.

    In this case the size of the mdat box is unknown because we don't know the size of all the video and audio frames yet. So a placeholder of zero is used. When the file is finished the size value should be overwritten with the correct size