avcodec | of encoder/decoder/render/player | Messaging library

*.mjpeg is a raw stream format. FFmpeg documentation states of raw muxers: "They do not store timestamps or metadata." So, instead try storing the data in an mp4 container:

The problem with my approach above was that it was based on the ffmpeg example encode_video.c with some bits for stream output borrowed from google.

Thanks to @rotem I started putting together a standalone executable and stumbled on the example muxing.c in the ffmpeg examples.

This let me find the steps I was missing: set the stream index on the packet, and rescale the time:

To try to reproduce your problem, I actually discarded all CMake stuff and just compiled main.cpp from the command line. I think you'll agree that the root of the issue is in the ffmpeg build.

The numbers 56..etc refer to the version number of the individual libraries that are a part of the FFmpeg project. So, avcodec-59 is major version 59 of libavcodec.

1. Yes, you can have parallel installations without issue, provided you can set custom search paths for the client application.

2. I suspect these clients are using libavcodec to export to major codecs. Those are generally mature, so older versions should be fine.

3. That's correct. Across major versions, the API and ABI will likely have changed.

4. Depends on what API calls they're using. A new decode/encode API was introduced some years ago but the old one was kept for compatibility, so clients could transition over gradually. In v59, those old calls were removed. So, if they did transition, then yes.

I do decoding like below:

It looks like the slicing feature works only when the same SwsContext is used for both slices.

In case we want to use individual context for each slice, we have to configure each SwsContext as if there are two individual images.

The fist context may "scale" the top half, and the second context may "scale" the bottom half.

• The image size for both contexts applies height/2.
• The fist context gets pointers to source and destination data of the top half.
• The second context gets pointers to source and destination data of the bottom half (both source and destination pointers are advanced).

For YUV420p input, the solution is going to work only if height is a multiple of 4.

Here is the relevant part of the code:

I found out it has been resolved in

https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=a74428921f8bfb33cbe0340bfd810b6945e432d2#patch1

and it works fine in ffmpeg 5.0. You can also apply this patch to 4.4.

Did you check data for INVALID_DATA?
You can check it according to RFC

RFC3640 (3.2 RTP Payload Structure)

AAC Payload can be seperated like below
AU-Header | Size Info | ADTS | Data

Example payload 00 10 0c 00 ff f1 60 40 30 01 7c 01 30 35 ac

According to configs that u shared
AU-size (SizeLength=13)
AU-Index / AU-Index-delta (IndexLength=3/IndexDeltaLength=3)

The length in bits of AU-Header is 13(SizeLength) + 3(IndexLength/IndexDeltaLength) = 16.
AU-Header 00 10

You should use AU-size(SizeLength) value for Size Info

AU-size: Indicates the size in octets of the associated Access Unit in the Access Unit Data Section in the same RTP packet.

First 13 (SizeLength) bits 0000000000010 equals to 2. So read 2 octets for size info.
Size Info 0c 00

ADTS ff f1 60 40 30 01 7c
ADTS Parser

ID MPEG-4
MPEG Layer 0
CRC checksum absent 1
Profile Low Complexity profile (AAC LC)
Sampling frequency 16000
Private bit 0 Channel configuration 1
Original/copy 0
Home 0
Copyright identification bit 0
Copyright identification start 0
AAC frame length 384
ADTS buffer fullness 95
No raw data blocks in frame 0

Data starts with 01 30 35 ac.

The green video is a result of encoding frames filled by zeros in YUV color space (pixel with Y,U,V value equals 0,0,0 is displayed as green colored pixel).

You are configuring sws_getContext, but you are not using it.

After decoding the grabbed video frame, the result is a frame with BGRA pixel format.
We should convert the frame from BGRA to YUV420p pixel format, and write the result to the output encoder.

When executing your code sample, I have encountered some strange behavior.
I tried to fix the code, using code snippets from the following post.

Note:

• I am still learning how to use the C interface of FFmpeg.
  There are implementation details that I am not sure about.
  Some polishing is still required...

Updated code: