We don't currently support values 1 (centimeters), 2 (inches) or 3 (DAR),
only the default value 0 (pixels) which doesn't need to be written.

The fate refs are updated as unknown SAR is now signaled in the output
files with the addition of the new element.
Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

A missing DisplayUnit element or one with the default value of 0 means
DisplayWidth and DisplayHeight should be interpreted as pixels.

The current code setting st->sample_aspect_ratio is wrong when DisplayUnit
is anything else.
Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>

Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>

Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>

from colorspace filter
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Tested functions: av_fifo_generic_peek(), av_fifo_grow()
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

since:
3e5e5bdf Merge commit '398f015f'
Signed-off-by: James Zern <jzern@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The calculation of width/height should round up, not round down to
prevent setting width or height to 0.

Also image->comps[compno].w is unsigned (at least in openjpeg2), so the
calculation could silently wrap around without the explicit cast to int.
Reviewed-by: Michael Bradshaw <mjbshaw@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

openjpeg 2 sets the data pointers of the image components to NULL,
causing segfaults if the image is reused.
Reviewed-by: Michael Bradshaw <mjbshaw@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

This is a similar filter to f_metadata, only it works on side data. Since
adding side data from a user provided arbitrary binary string is unsafe,
because current code assumes that a side data of a certain kind has the proper
size, this filter only implements selection and deletion. Also, no value
matching support is implemented yet, because there is no uniform way to specify
a side data textually.
Signed-off-by: Marton Balint <cus@passwd.hu>

Use check_lib2 to test the header together with the function. This is
necessary, because '-DOPJ_STATIC' changes what the included header does.

Also add '-DOPJ_STATIC' to CPPFLAGS, so that it isn't necessary to
hardcode this in libavcodec/libopenjpeg{dec,enc}.c.

Finally, check for non-static openjpeg 2.1, too.
Reviewed-by: Michael Bradshaw <mjbshaw@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

This fixes a build problem for MIPS architecture that looks like this:

libavcodec/mips/h264dsp_msa.c:2498:6: error: conflicting types for
‘ff_weight_h264_pixels16_8_msa’
 void ff_weight_h264_pixels16_8_msa(uint8_t *src, int stride,

This bug was introduced by commit bc26fe89:

  avcodec/h264: Use ptrdiff_t for (bi)weight functions

That commit changed the data type of some function parameters in some
function definitions. However, the implementation of those functions in
libavcodec/mips/h264dsp_msa.c wasn't changed accordingly.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: James Almer <jamrial@gmail.com>

The spec says

9: Interlaced with bottom field displayed first and top field stored first
14: Interlaced with top field displayed first and bottom field stored first

And avcodec.h states

AV_FIELD_TB,          //< Top coded first, bottom displayed first
AV_FIELD_BT,          //< Bottom coded first, top displayed first
Reviewed-by: Dave Rice <dave@dericed.com>
Signed-off-by: James Almer <jamrial@gmail.com>

Avoids detecting libraries that are not compatible with ldexeflags.

The hardware handling of packed bframes was always questionable but
it used to ok with my workaround. Today, not so much. But today we
have a bsf to unpack the bframes, so let's just use that and be
done with it.

With all the various refactorings that have happened over the years,
the current pts logic is very broken for non-trivial cases (ie: ones
where not every frame/field has a meaningful pts assocated with it).

Generally, we do not want to write AV_NOPTS_VALUE as the output
timestamp, regardless of anything else. It's better to pass zero
if there's no other information.

Additionally, interlaced content where the decoder returns each field
separately can result in the first field carrying the timestamp and
the second having AV_NOPTS_VALUE. It's clearly wrong to overwrite
the valid timestamp.

So, let's just never write AV_NOPTS_VALUE into an output frame.

Empirically, this fixed playback of interlaced mpeg2 and h.264 and
mpeg4-asp with packed b-frames in an avi container.

Allows to write arbitrary channel masks also for 16bit 48kHz pcm.

Using lfg was an overkill in this case where the random numbers
were only used for encoder descisions. Should increase result
uniformity between different FPUs and gives a slight speedup.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>

The spec says:
"Mandatory elements with a default value may be left out of the file. In the absence
of a mandatory element, the element's default value is used."
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

Suggested-by: ronald
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes ticket #5872.

Fixes ticket #4009.

Fixes decoding of the output file from ticket #4009.

The option d10_channelcount only exists for mxf_d10.

Attachment tags were being written targeting non-existent streams in the
output file.
Also filter filename and mimetype entries, as they are standard elements
in the Attachment master.
Signed-off-by: James Almer <jamrial@gmail.com>