Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit c0aa89eeee2af2a4898258b29badea2f935a4836)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit a47bd1cd1c714ac94cea9d3a26b58de521a7debc)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 0f176bb8e0896f233b35054530f76c4a778b968f)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 34dbdcfc20d69b7b67fd13112445cd05b9b5d979)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: signed integer overflow: 2147483637 + 128 cannot be represented in type 'int'
Fixes: 6701/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVPACK_fuzzer-5358324934508544
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 6e95d80e6fae978f8a44afc24b0c5097a062719f)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: signed integer overflow: 2147483531 + 16384 cannot be represented in type 'int'
Fixes: 6615/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVPACK_fuzzer-5165715515506688
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit da038c07f02dfc10380001c11b3d047eca7cb8c9)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: signed integer overflow: 197710 * 10923 cannot be represented in type 'int'
Fixes: 7010/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-5667127596941312
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 1c97035e3b1677d6f0c5b6161ebfeffcf7bb638d)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 6798/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G2M_fuzzer-5135899701542912
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 0bd0401336df4e4ca7f3da6a7e226904fd7d5add)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
also fixes: runtime error: index 1456 out of bounds for type 'int16_t [16]'
Found-by: durandal_1707
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit d06b01fc2d4f5e031d45f9460d1eea610d23d6c5)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The crc flag is only stored since version 3 thus before this crcs do not
work. We increase the version as needed same as we do with pix_fmts
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit d9706f79c17a33bf97e51a7d6ab211ce83a463ee)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Yet another case of forgotten 0 =! EOF translation.
While the documentation for this specific synchronous read
function does not mention it, the documentation for
`sftp_async_read` documents it, as well as looking at the
implementation of this function leads one to find
`if (handle->eof) { return 0; }`.
Reported by stnutt on IRC.
(cherry picked from commit 26892c7615395f331f6143535f03a2957973e2e0)
Fixes PMT parsing in some mpegts streams which contain
multiple tables within the PMT pid. Previously, the parser
assumed only one table was present in each packet, and discarded
the rest of the section data after attempting to parse the first
table.
A similar issue was documented in the BeyondTV software[1], which
helped me diagnose the same bug in the ffmpeg mpegts demuxer. I also
tried DVBInspector, libdvbpsi's dvbinfo, and tstools' tsinfo to
help debug. The former two properly read PMTs with multiple tables,
whereas the last has the same bug as ffmpeg.
I've created a minimal sample[2] which contains the combined PMT.
Here's what ffmpeg probe shows before and after this patch:
Before:
Input #0, mpegts, from 'combined-pmt-tids.ts':
Duration: 00:00:01.08, start: 4932.966167, bitrate: 741 kb/s
Program 1
No Program
Stream #0:0[0xf9d]: Audio: ac3, 48000 Hz, mono, fltp, 96 kb/s
Stream #0:1[0xf9b]: Audio: mp3, 0 channels, fltp
Stream #0:2[0xf9c]: Unknown: none
After:
Input #0, mpegts, from 'combined-pmt-tids.ts':
Duration: 00:00:01.11, start: 4932.966167, bitrate: 718 kb/s
Program 1
Stream #0:0[0xf9b]: Video: mpeg2video ([2][0][0][0] / 0x0002), none(tv, top first), 29.97 fps, 29.97 tbr, 90k tbn, 90k tbc
Stream #0:1[0xf9c](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 384 kb/s
Stream #0:2[0xf9d](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, mono, fltp, 96 kb/s
With the patch, the PMT is parsed correctly so the streams are
created in the correct order, are associated with "Program 1",
and their codecs are set correctly.
[1] http://forums.snapstream.com/vb/showpost.php?p=343816&postcount=201
[2] https://s3.amazonaws.com/tmm1/combined-pmt-tids.ts
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 9152c1e495551535886cfd7a8d7c0a206691443e)
This mimics the logic flow in all the other callbacks
(pat_cb, sdt_cb, m4sl_cb), and avoids calling skip_identical()
for non PMT_TID packets.
Since skip_identical modifies internal state like
MpegTSSectionFilter.last_ver, this change prevents unnecessary
reprocessing on some streams which contain multiple tables in
the PMT pid. This can be observed with streams from certain US
cable providers, which include both tid=0x2 and another unspecified
tid=0xc0.
Signed-off-by: Aman Gupta <aman@tmm1.net>
(cherry picked from commit 2c500f50972c19f25ebca783ba9374d6a0c23efb)
I tested the previous mediacodec changes on seven different Android
TV devices, with both mpeg2 and h264 content. All except one worked
as expected. The exception was the MiBox3 running Android 6.0.1,
where playback would freeze on a frame every few seconds. I tested
two other AMLogic devices with newer Android versions that did not
show the same problem. H264 decoding on the MiBox3 was also not affected,
so this workaround applies only to OMX.amlogic.mpeg2.decoder.awesome
on Android API22.
There is a rumor that Xiaomi is planning to release Android Oreo for
the MiBox3, so I will revisit in a few months to confirm whether this
is specific to os/driver version or the chipset used in that device.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>
(cherry picked from commit 9b563f6584b5ba2292975f0917268ac7b37497eb)
The output_buffer_count==0 special case is no longer required, and
can cause spurious EAGAIN to surface to the user when input buffers
are filled up. Since the caller now knows if the decoder is accepting
new input (via current_input_buffer>=0), let the wait parameter
control whether we block or not.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>
(cherry picked from commit a75bb5496ac6e7e194f1c6fd3b87f02a52e74adb)
The new logic follows a recommendation by @rcombs to use
dequeueInputBuffer with a timeout of 0 as a way to detect
whether the codec wants more data. The dequeued buffer index is
kept in MediaCodecDecContext until it can be used next.
A similar technique is also used by the Google's official media
player Exoplayer: see MediaCodecRenderer.feedInputBuffer().
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>
(cherry picked from commit f6681feda641c026d84f6d207f661bf9b87d9d70)
Also fixes a bug where EOS buffer was sent with incorrect
pts when not using surface generation.
Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Signed-off-by: Aman Gupta <aman@tmm1.net>
(cherry picked from commit d8e92a89edd8e73cdc7f125f078c576df10b66f2)
As of 2a0eb8685, ff_mediacodec_dec_is_flushing() only returns
true in delay_flush mode. Make this more obvious by adding
delay_flush to the if statement.
Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Signed-off-by: Aman Gupta <aman@tmm1.net>
(cherry picked from commit 6a7a84b2d11e6c5e2ca2023a6886ca75b8b10030)
In a normal hwaccel, the AVHWFramesContext sets AVFrame.hw_frames_ctx
when it initializes a new AVFrame in av_hwframe_get_buffer().
But the VT hwaccel doesn't know what hw_frames_ctx to assign when
the AVFrame is first created, because it depends on the format of
the pixbuf that the decoder eventually decides to return. Thus
newly created AVFrames always have a NULL hw_frames_ctx, and the
hwaccel would only assign the ctx once a frame was done decoding.
This worked fine with the H264 decoder, but with the HEVC decoder
the frame's data may be moved to another empty AVFrame. Since the
empty AVFrame never had hw_frames_ctx set, a frame with a NULL
ctx could be returned to the API user.
This patch works around the issue by moving the derived
hw_frames_ctx from the AVFrame to a new VTHWFrame which now holds
both the CVPixelBufferRef and the AVBuffer. The hw_frames_ctx
is only copied to the AVFrame right before it is about to be
returned to the user in videotoolbox_postproc_frame() (since
in the case of VT, the hw_frames_ctx is only there for the API
user anyway).
Fixes playback on macOS and iOS of some hevc videos like
https://s3.amazonaws.com/tmm1/videotoolbox/germany-hevc-zdf.ts
Signed-off-by: Aman Gupta <aman@tmm1.net>
(cherry picked from commit 8f146b526ff8d63adc02e1c5db15850f4589230b)
No longer required since 63d875772d. The equivalent hack
for h264 was removed in that commit, but this one was missed.
Signed-off-by: Aman Gupta <aman@tmm1.net>
(cherry picked from commit a19bac8fc8b6a8df4030f79a6192b20492b02cef)
Previously the shared callbacks were trying to interpret
avctx->priv_data as H264Context*
Signed-off-by: Aman Gupta <aman@tmm1.net>
(cherry picked from commit 07d175d0b0b22912784f35d29e139cf025a03221)
Older iOS devices don't have a hardware HEVC decoder, but the
software decoder offered by VideoToolbox is well-optimized and
performs much better than the ffmpeg decoder.
Signed-off-by: Aman Gupta <aman@tmm1.net>
(cherry picked from commit bcff983dc340e76518935111146c0e1daf4cb37b)
My conversation from AVFormatContext->filename to AVFormatContext->url was
wrong in this case because get_chunk_filename uses filename as an output
buffer, and not as an input buffer.
Fixes ticket #7188.
Signed-off-by: Marton Balint <cus@passwd.hu>
(cherry picked from commit 2dbe936bf7f9e0fe7e8f05e5c3b78fb1afbff164)
This should be included as `<lilv/lilv.h>`, same as is done in af_lv2.c.
Forcing the extra lilv-0 breaks platforms where the include dir is
`/usr/include/lilv/lilv.h` rather than
`/usr/include/lilv-0/lilv/lilv.h`.
The new include path works for both, because the `pkg-config --cflags`
includes `-I/usr/include/lilv-0`.
(cherry picked from commit 32234e03a792e3ceca58359d6f2b7244ceb6b77f)
The main issue here was the use of [i] instead of [i * 3] for the 32x32
matrix. As part of fixing this, I changed the code to match that used
in vdpau_hevc, which I spent a lot of time verifying.
I also changed to calculating NumPocTotalCurr using the existing helper,
which is what vdpau does.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
(cherry picked from commit 1261003700322789d62a892e3325f8b58349d051)
Yet another case of forgotten 0 =! EOF translation. The libbluray
documentation specifically mentions that a read of 0 is EOF.
Reported by Fyr on IRC.
(cherry picked from commit b995ec078f42bac95eda18fbd1b4387477b55d0d)
The specs says that the the first color component in the color array is
not alpha, but simply 0.
Fixes 0 alpha of fate-suite/cvid/catfight-cvid-pal8-partial.mov
Signed-off-by: Marton Balint <cus@passwd.hu>
(cherry picked from commit c60a824ee87ae3b15ed1cb92b780bec9b642b019)
SDL_QueryTexture and SDL_DestroyTexture require that the input texture
pointer be non-null. Debug builds of SDL will correctly check for this
and break program execution. This patch fixes this by checking the
status of the texture pointer.
Signed-off-by: Matt Oliver <protogonoi@gmail.com>
(cherry picked from commit 6be690685a8876a61f87b2b8bf30547e09030a96)
For filters based on framesync, the input frame was managed
by framesync, so we should not directly keep and destroy it,
instead we make a clone of it here, or else double-free will occur.
But for other filters not based on framesync, we still need to
free the input frame inside filter_frame.
Signed-off-by: Ruiling Song <ruiling.song@intel.com>
(cherry picked from commit d865783b6c8d4f96f5094ed72eff0f5a4a4908af)
The existing version which was cherry-picked from Libav does not work
with FFmpeg framework, because ff_request_frame() was totally
different between Libav (recursive) and FFmpeg (non-recursive).
The existing overlay_qsv implementation depends on the recursive version
of ff_request_frame to trigger immediate call to request_frame() on input pad.
But this has been removed in FFmpeg since "lavfi: make request_frame() non-recursive."
Now that we have handy framesync support in FFmpeg, so I make it work
based on framesync. Some other fixing which is also needed to make
overlay_qsv work are put in a separate patch.
Signed-off-by: Ruiling Song <ruiling.song@intel.com>
(cherry picked from commit f3341a0452419c57faf4d28aebb24be5d41312f3)