- 04 Nov, 2022 5 commits
-
-
James Darnley authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Ruijing Dong authored
In av1_spec.pdf page 38/669, there is a sentence below: if ( frame_type == KEY_FRAME && show_frame ) { for ( i = 0; i < NUM_REF_FRAMES; i++) { RefValid[ i ] = 0 ...... } ...... } This shows that the condition of invalidating current DPB frames should be the coming frame_type is KEY_FRAME plus show_frame is equal to 1. Otherwise, some of the frames in sequence after KEY_FRAME still refer to the reference frames before KEY_FRAME, and if these before KEY_FRAME reference frames were invalidated, these frames could not find their reference frames, and it could cause image corruption. Mesa fix is in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19386Reviewed-by: Fei Wang <fei.w.wang@intel.com> Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
-
- 03 Nov, 2022 14 commits
-
-
James Almer authored
The order in which the channels are coded in the bitstream do not always follow the native, bitmask-based order of channels both signaled by the WAV container and forced by this same decoder. This is the case with layouts containing an LFE channel, as it's always coded last. Fixes ticket #9964. Signed-off-by: James Almer <jamrial@gmail.com>
-
James Almer authored
Generalize the checks for channels in all positions, and properly support the three height groups (normal, top, bottom) instead of manually setting the relevant channels for the latter two after the normal height tags were parsed. Signed-off-by: James Almer <jamrial@gmail.com>
-
James Almer authored
If PCE defines channels not covered by those in the standard configurations then don't try to come up with some made up layout and just return them in the coded order. Fixes al08_44.mp4 from the conformance suite, now reporting and decoding all 48 channels instead of 10. Signed-off-by: James Almer <jamrial@gmail.com>
-
James Almer authored
It corresponds to the 7.1(top) layout. Signed-off-by: James Almer <jamrial@gmail.com>
-
James Almer authored
Signed-off-by: James Almer <jamrial@gmail.com>
-
James Almer authored
Signed-off-by: James Almer <jamrial@gmail.com>
-
James Almer authored
Set the correct amount of tags in tags_per_config[]. Also, there are no channels that correspond to a side element in this configuration, so reflect this in the list of known/supported channel layouts. Signed-off-by: James Almer <jamrial@gmail.com>
-
Paul B Mahol authored
-
Timo Rothenpieler authored
-
Pierre-Anthony Lemieux authored
-
Pierre-Anthony Lemieux authored
-
Pierre-Anthony Lemieux authored
The IMF CPL contains an optional timecode start address. This patch reads the latter, if present, into the context's timecode metadata parameter. This addresses https://trac.ffmpeg.org/ticket/9842.
-
Gyan Doshi authored
The current adjustment of input start times just adjusts the tsoffset. And it does so, by resetting the tsoffset to nullify the new start time. This leads to breakage of -copyts, ignoring of input_ts_offset, breaking of -isync as well as breaking wrap correction. Fixed by taking cognizance of these parameters, and by correcting start times just before sync offsets are applied.
-
Gyan Doshi authored
In preparation for applying start time correction that accounts for all factors such as copyts, input_ts_offset ..etc
-
- 02 Nov, 2022 2 commits
-
-
Paul B Mahol authored
-
Peter Ross authored
Fixes ticket #5387
-
- 01 Nov, 2022 4 commits
-
-
Timo Rothenpieler authored
-
Hubert Mazur authored
Provide arm64 neon optimized implementations for hscale16To19 with filter sizes 4, 8 and X4. The tests and benchmarks run on AWS Graviton 2 instances. The results from a checkasm tool are shown below. hscale_16_to_19__fs_4_dstW_512_c: 6216.0 hscale_16_to_19__fs_4_dstW_512_neon: 2257.0 hscale_16_to_19__fs_8_dstW_512_c: 10417.7 hscale_16_to_19__fs_8_dstW_512_neon: 3112.5 hscale_16_to_19__fs_12_dstW_512_c: 14890.5 hscale_16_to_19__fs_12_dstW_512_neon: 3899.0 hscale_16_to_19__fs_16_dstW_512_c: 19006.5 hscale_16_to_19__fs_16_dstW_512_neon: 5341.2 hscale_16_to_19__fs_32_dstW_512_c: 36629.5 hscale_16_to_19__fs_32_dstW_512_neon: 9502.7 hscale_16_to_19__fs_40_dstW_512_c: 45477.5 hscale_16_to_19__fs_40_dstW_512_neon: 11552.0 (Note, the checkasm tests for these functions haven't been merged since they fail on x86.) Signed-off-by: Hubert Mazur <hum@semihalf.com> Signed-off-by: Martin Storsjö <martin@martin.st>
-
Hubert Mazur authored
Add arm64 neon implementations for hscale 16 to 15 with filter sizes 4, 8 and X4. The tests and benchmarks run on AWS Graviton 2 instances. The results from a checkasm tool are shown below. hscale_16_to_15__fs_4_dstW_512_c: 6703.5 hscale_16_to_15__fs_4_dstW_512_neon: 2298.0 hscale_16_to_15__fs_8_dstW_512_c: 10983.0 hscale_16_to_15__fs_8_dstW_512_neon: 3216.5 hscale_16_to_15__fs_12_dstW_512_c: 15526.0 hscale_16_to_15__fs_12_dstW_512_neon: 3993.0 hscale_16_to_15__fs_16_dstW_512_c: 20183.5 hscale_16_to_15__fs_16_dstW_512_neon: 5369.7 hscale_16_to_15__fs_32_dstW_512_c: 39315.2 hscale_16_to_15__fs_32_dstW_512_neon: 9511.2 hscale_16_to_15__fs_40_dstW_512_c: 48995.7 hscale_16_to_15__fs_40_dstW_512_neon: 11570.0 (Note, the checkasm tests for these functions haven't been merged since they fail on x86.) Signed-off-by: Hubert Mazur <hum@semihalf.com> Signed-off-by: Martin Storsjö <martin@martin.st>
-
Hubert Mazur authored
Add arm64 neon implementations for hscale 8 to 19 with filter sizes 4, 4X and 8. Both implementations are based on very similar ones dedicated to hscale 8 to 15. The major changes refer to saving the data - instead of writing the result as int16_t it is done with int32_t. These functions are heavily inspired on patches provided by J. Swinney and M. Storsjö for hscale8to15 which were slightly adapted for hscale8to19. The tests and benchmarks run on AWS Graviton 2 instances. The results from a checkasm tool shown below. hscale_8_to_19__fs_4_dstW_512_c: 5663.2 hscale_8_to_19__fs_4_dstW_512_neon: 1259.7 hscale_8_to_19__fs_8_dstW_512_c: 9306.0 hscale_8_to_19__fs_8_dstW_512_neon: 2020.2 hscale_8_to_19__fs_12_dstW_512_c: 12932.7 hscale_8_to_19__fs_12_dstW_512_neon: 2462.5 hscale_8_to_19__fs_16_dstW_512_c: 16844.2 hscale_8_to_19__fs_16_dstW_512_neon: 4671.2 hscale_8_to_19__fs_32_dstW_512_c: 32803.7 hscale_8_to_19__fs_32_dstW_512_neon: 5474.2 hscale_8_to_19__fs_40_dstW_512_c: 40948.0 hscale_8_to_19__fs_40_dstW_512_neon: 6669.7 Signed-off-by: Hubert Mazur <hum@semihalf.com> Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 31 Oct, 2022 12 commits
-
-
Peter Ross authored
The FFmpeg encoder does not increment the temporal reference field, so use that knowledge plus the extradata field to detect buggy versions of the encoder.
-
Peter Ross authored
Fixes ticket #128. The SVQ1 interframe mean VLC symbols -128 and 128 are incorrectly swapped in our SVQ1 implementation, resulting in visible artifacts for some videos. This patch unswaps the order of these two symbols. The most noticable example of the artiacts caused by this error can be observed in https://trac.ffmpeg.org/attachment/ticket/128/svq1_set.7z '352_288_k_50.mov'. The artifacts are not observed when using the reference decoder (QuickTime 7.7.9 x86 binary). As a result of this patch, the reference data for the fate-svq1 test ($SAMPLES/svq1/marymary-shackles.mov) must be modified. For this file, our decoder output is now bitwise identical to the reference decoder. I have tested patch with various other samples and they are all now bitwise identical.
-
Peter Ross authored
This will enable the acurate identification of FFmpeg produced SVQ1 streams, should there be new bugs found in the encoder.
-
Peter Ross authored
Don't emit interframe mean symbols -128 and 128.
-
Peter Ross authored
initialised to -1 which indicates wmv9 mask not present
-
Timo Rothenpieler authored
-
James Zern authored
Signed-off-by: James Zern <jzern@google.com> Reviewed-by: Vignesh Venkatasubramanian <vigneshv@google.com>
-
Andreas Rheinhardt authored
low_delay is always zero for rv34. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
ff_mpeg1_dc_scale_table is the default value for [yc]_dc_scale_table (as set by ff_mpv_common_defaults()). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
This e.g. allows compilers to bake the offset implied by using ff_mpeg12_dc_scale_table[3] (as the SpeedHQ encoder does) into the general offset; for certain arches this is also necessary in order to avoid building suboptimal code. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Avoids relocations. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
These tables are only accessed in ff_set_qscale() which only accesses values 1..31 as well as in encode_picture() in mpegvideo_enc.c, accessing the value with index 8. So make these tables smaller. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
- 30 Oct, 2022 3 commits
-
-
Andreas Rheinhardt authored
For encoders, mpeg_quant is an option of the MPEG-4 encoder and therefore constant. This implies that one can set the dct_unquantize_(intra|inter) function pointers during init. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
James Almer authored
Signed-off-by: James Almer <jamrial@gmail.com>
-
James Almer authored
Signed-off-by: James Almer <jamrial@gmail.com>
-