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)
Keyframe detection was inverted in cfe1a9d311 in order to fix keyframe
flags set for the sample attached to trac #7091. However, that sample is
errantly muxed.
As noted at
https://web.archive.org/web/20020803104640/http://www.pcisys.net:80/~melanson/codecs/film-format.txt,
the original keyframe detection logic is correct, and this patch
restores it.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 9f9f56e6791f6c44ac8e4b97a8da5816ed542332)
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 7b8daa771cbdafa6775e476c65afa659cc1afaac)
Similar to 4c9c4fe8b21, but for durations. This fixes#7151, where
the report duration and bitrate on a mpegts stream is wildly off
due to the dvb_teletext stream's timings.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit fd6e89586c01d068fc8d2cea24292bf8ae836f74)
Signed-off-by: Stephan Holljes <klaxa1337@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 7b6b8c92652d6683d97515352e4a9a4147b7da7c)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 13b77af2f0b56d6c87bb147947337981c21f4245)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit c0bce367e4932f0fb09195e6978ac1a5a60480a4)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 3dfe3436ac78607d7baf6f1f7f48691343d9d929)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 9f1b99e7d076c9de1fefe971f1c70c96ebcf071b)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit f8b17fe33233237eea304d4fb0636539a131c1b2)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 942217b153a9bff2d17463957abd772fcd72b400)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The headers from where the dimensions are read in actual files
are limited to 16bit per component.
Fixes: Timeout
Fixes: 6305/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DFA_fuzzer-4824270749302784
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 9d5a4fcfbb51edc871bdb1c67a88223cbfb1c0e4)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Speeds up decoding from 3 to 0.1 seconds for 6302/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5626371985375232
Fixes: Timeout
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 9033920bec9ccf17de205fc17c2b330906b200f5)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Speeds up decoding from 8 to 3 seconds for 6302/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5626371985375232
Fixes: Timeout
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 2324ef1ff32e5effd6f295bca80580ae4816be0b)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Branch to global symbol results in reference to PLT, and when compiling
for THUMB-2 - in a R_ARM_THM_JUMP19 relocation. Some linkers don't
support this relocation (ld.gold), while others can end up truncating
the relocation to fit (ld.bfd).
Convert this branch through PLT into a direct branch that the assembler
can resolve locally.
See https://github.com/android-ndk/ndk/issues/337 for background.
The current workaround is to disable neon during gstreamer build,
which is not optimal and can be reverted after this patch:
41556c4157
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit b22db4f465c9adb2cf1489e04f7b65ef6bb55b8b)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Thanks-to: Moritz Barsnick <barsnick@gmx.net> for finding the correct ones
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit ec8a5262b03f85158d722dbc8b8f30cb6bd67e0f)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes decoding on the Samsung Chromebook Pro which do not set the codec
output format stride and slice-height fields.
(cherry picked from commit 67d0911f27e29d551865dbca3af5c49abe029885)
