- 25 Jun, 2024 1 commit
-
-
James Almer authored
av_stereo3d_alloc() is not useful in scenarios where you need to know the runtime size of AVStereo3D. Signed-off-by:
James Almer <jamrial@gmail.com>
-
- 24 Jun, 2024 13 commits
-
-
James Almer authored
Same as every other rational printed in this file. Signed-off-by:
James Almer <jamrial@gmail.com>
-
Timo Rothenpieler authored
-
Lynne authored
This avoids hardcoding any implementation-specific limitiations as part of the API, and allows for future expandability. This also allows API users to more conveniently convert the values into floats without hardcoding specific conversion constants. The API was committed a few days ago, so changing this field now is within the realms of acceptable.
-
Rémi Denis-Courmont authored
Currently, any unrecognised platform is treated as 32-bit. This should detect *most* 64-bit platforms, namely LP64 and LLP64 ones. Unfortunately this will not work for ILP32 ABIs on 64-bit ISAs, but still better than nothing.
-
Cosmin Stejerean authored
now that we are reading ext_mapping_idc as the upper 8 bits of el_bit_depth_minus8 we need to use get_ue_golomb_long rather than get_ue_golomb_31 for reading it
-
Pierre-Anthony Lemieux authored
p0_10.j2k is one of the reference codestreams included in Rec. ITU-T T.803 | ISO/IEC 15444-4. Adding this test was made possible by commit 6f4a95cf.
-
Timo Rothenpieler authored
Fixes for example rtmps streaming over schannel.
-
Ramiro Polla authored
-
Ramiro Polla authored
The C code was silently ignoring the second chroma line on yuv422p input.
-
Ramiro Polla authored
-
Ramiro Polla authored
The C code for some pixel formats (rgb555, rgb565, rgb444, and monob) was not converting the last pixels on widths not aligned to 8. NOTE: the last pixel for odd widths is still not converted for any of the pixel formats in the C code for yuv2rgb except for monob.
-
Martin Storsjö authored
This allows ending up with a normal, non-fragmented file when the file is finished, while keeping the file readable if writing is aborted abruptly at any point. (Normally when writing a mov/mp4 file, the unfinished file is completely useless unless it is finished properly.) This results in a file where the mdat atom contains (and hides) all the moof atoms that were part of the fragmented file structure initially. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 23 Jun, 2024 1 commit
-
-
Lynne authored
Currently, no eSBR features are supported. Thankfully, no encoders exist for it yet.
-
- 22 Jun, 2024 2 commits
-
-
Cosmin Stejerean authored
These two fields are coded together into a single 16 bit integer with upper 8 bits for ext_mapping_idc and lower 8 bits for el_bit_depth_minus8. Furthermore ext_mapping_idc has two components, upper 3 bits and lower 5 bits. Co-authored-by:
Niklas Haas <git@haasn.dev> Signed-off-by:
Niklas Haas <git@haasn.dev>
-
Cosmin Stejerean authored
Co-authored-by:
Niklas Haas <git@haasn.dev> Signed-off-by:
Niklas Haas <git@haasn.dev>
-
- 21 Jun, 2024 6 commits
-
-
James Almer authored
Signed-off-by:
James Almer <jamrial@gmail.com>
-
Lynne authored
m4ac.sampling_index is what aacdec.c uses.
-
Lynne authored
This was a typo.
-
Lynne authored
Fixes reading state->last[i + 1] in ff_aac_ac_get_context for the last array member.
-
Lynne authored
The rate index is a value important to both encoders and decoders. USAC needs it as well, so put it into the shared main header.
-
Lynne authored
-
- 20 Jun, 2024 17 commits
-
-
James Almer authored
It's not part of the libavutil ABI. Signed-off-by:
James Almer <jamrial@gmail.com>
-
James Almer authored
It's not part of the libavutil ABI. Signed-off-by:
James Almer <jamrial@gmail.com>
-
James Almer authored
It's not part of the libavutil ABI. Signed-off-by:
James Almer <jamrial@gmail.com>
-
James Almer authored
Prevent potential divisions by 0 when using them immediately after allocation. Signed-off-by:
James Almer <jamrial@gmail.com>
-
James Almer authored
Prevent potential divisions by 0 when using them immediately after allocation. Signed-off-by:
James Almer <jamrial@gmail.com>
-
James Almer authored
Prevent potential divisions by 0 when using them immediately after allocation. Signed-off-by:
James Almer <jamrial@gmail.com>
-
James Almer authored
ffprobe is meant to generate parseable output, and if a field is present, it should be printed even if it has a default value. Signed-off-by:
James Almer <jamrial@gmail.com>
-
Andreas Rheinhardt authored
These tables are supposed to contain the number of bits needed to encode a given (run, level) pair. Yet the number of bits for pairs needing the escape code was wrong (it only contained the escape code and not the bits needed for run and level). Furthermore, H.261 (a format with explicit end-of-block codes) does not work well together with the RLTable API from rl.c: The EOB code is the first one in ff_h261_rl_tcoeff's VLC table and has a run value of zero. Therefore the result of get_rl_index() is off by one for run == 0 and level values with explicit (run, level) pair. Fixing this necessitated changing the ref files of the vsynth*-h261-trellis tests. Both filesizes as well as PSNR decreased. If one used a qscale value of 11 for this test, one would have received files with about the same size as before this patch (with qscale 12), but with better PSNR. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
The RLTable API in rl.c is not well designed for codecs with an explicit end-of-block code. ff_h261_rl_tcoeff's vlc has the EOB code as first element (presumably so that the decoder can check for it via "if (level == 0)") and this implies that the indices returned by get_rl_index() are off by one for run == 0 which is therefore explicitly checked. This commit changes this by adding a simple LUT for the values not requiring escaping. It is easy to directly include the sign bit into this, so this has also been done. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
This will allow to avoid the indirection via ff_h261_rl_tcoeff in future commits. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
These must not be modified (even when they are initialized at runtime and therefore modifiable). Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
H.261 does not have B-frames. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
It is a better place for it; no non-h263-based decoder needs these functions any more (both H.261 and the error resilience code recently stopped doing so). Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
It is an MPEG-4-only value; it is always five for the MPEG-4 encoder, so just hardcode this value and move the MpegEncContext field to Mpeg4DecContext. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
The RV10 and RV20 decoders use ff_h263_decode_mb() and also the H.263 DSP and VLCs. Despite not calling ff_h263_decode_frame(), it is nevertheless beneficial to call ff_h263_decode_init() to reduce code duplication. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-