[FFmpeg-devel] [PATCH] avformat/mpegts: parse large PMTs with multiple tables
From: Aman Gupta
In 9152c1e4955, the mpegts parser was taught how to parse
PMT sections which contained multiple tables. That commit
fixed parsing of PMT packets from some cable providers,
which included a special SCTE table (0xc0) before the
standard program map table (0x2).
Sometimes, however, the combined 0xc0 and 0x2 tables are
larger than a single TS packet (188 bytes). The mpegts parser
already attempts to parse sections which span multiple packets,
but still assumed that the split section only contained one
table.
This patch fixes parsing of such a sample[1].
Before:
Input #0, mpegts, from 'combined-pmt-tids-split.ts':
Duration: 00:00:01.26, start: 39188.931756, bitrate: 597 kb/s
Program 1
No Program
Stream #0:0[0xeff]: Audio: ac3, 48000 Hz, mono, fltp, 64 kb/s
Stream #0:1[0xefd]: Audio: mp3, 0 channels, fltp
Stream #0:2[0xefe]: Unknown: none
After:
Input #0, mpegts, from 'combined-pmt-tids-split.ts':
Duration: 00:00:01.27, start: 39188.931756, bitrate: 589 kb/s
Program 1
Stream #0:0[0xefd]: Video: h264 ([27][0][0][0] / 0x001B), none, 59.94
fps, 59.94 tbr, 90k tbn, 180k tbc
Stream #0:1[0xefe](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 48000
Hz, stereo, fltp, 384 kb/s
Stream #0:2[0xeff](spa): Audio: ac3 ([129][0][0][0] / 0x0081), 48000
Hz, mono, fltp, 64 kb/s
Stream #0:3[0xf00]: Data: scte_35
Stream #0:4[0xf01]: Unknown: none (ETV1 / 0x31565445)
Stream #0:5[0xf02]: Unknown: none (ETV1 / 0x31565445)
Stream #0:6[0xf03]: Unknown: none ([192][0][0][0] / 0x00C0)
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] https://s3.amazonaws.com/tmm1/combined-pmt-tids-split.ts
Signed-off-by: Aman Gupta
---
libavformat/mpegts.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 5f53f77d89..a5cb17ac16 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -465,6 +465,7 @@ static void write_section_data(MpegTSContext *ts,
MpegTSFilter *tss1,
offset += tss->section_h_size;
tss->section_h_size = -1;
} else {
+tss->section_h_size = -1;
tss->end_of_section_reached = 0;
break;
}
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] examples/vaapi_dec_scaling: init export
add a vaapi decoding/scaling sample.
Signed-off-by: Jun Zhao
---
configure| 2 +
doc/examples/Makefile| 1 +
doc/examples/vaapi_dec_scaling.c | 375 +++
3 files changed, 378 insertions(+)
create mode 100644 doc/examples/vaapi_dec_scaling.c
diff --git a/configure b/configure
index 473be31..d28dc37 100755
--- a/configure
+++ b/configure
@@ -1610,6 +1610,7 @@ EXAMPLE_LIST="
scaling_video_example
transcode_aac_example
transcoding_example
+vaapi_dec_scaling_example
vaapi_encode_example
vaapi_transcode_example
"
@@ -3445,6 +3446,7 @@ resampling_audio_example_deps="avutil swresample"
scaling_video_example_deps="avutil swscale"
transcode_aac_example_deps="avcodec avformat swresample"
transcoding_example_deps="avfilter avcodec avformat avutil"
+vaapi_dec_scaling_example_deps="avfilter avcodec avformat avutil"
vaapi_encode_example_deps="avcodec avutil h264_vaapi_encoder"
vaapi_transcode_example_deps="avcodec avformat avutil h264_vaapi_encoder"
diff --git a/doc/examples/Makefile b/doc/examples/Makefile
index 928ff30..3ea6899 100644
--- a/doc/examples/Makefile
+++ b/doc/examples/Makefile
@@ -19,6 +19,7 @@ EXAMPLES-$(CONFIG_RESAMPLING_AUDIO_EXAMPLE) +=
resampling_audio
EXAMPLES-$(CONFIG_SCALING_VIDEO_EXAMPLE) += scaling_video
EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE) += transcode_aac
EXAMPLES-$(CONFIG_TRANSCODING_EXAMPLE) += transcoding
+EXAMPLES-$(CONFIG_VAAPI_DEC_SCALING_EXAMPLE) += vaapi_dec_scaling
EXAMPLES-$(CONFIG_VAAPI_ENCODE_EXAMPLE) += vaapi_encode
EXAMPLES-$(CONFIG_VAAPI_TRANSCODE_EXAMPLE) += vaapi_transcode
diff --git a/doc/examples/vaapi_dec_scaling.c b/doc/examples/vaapi_dec_scaling.c
new file mode 100644
index 000..6ec65da
--- /dev/null
+++ b/doc/examples/vaapi_dec_scaling.c
@@ -0,0 +1,375 @@
+/*
+ * Copyright (c) 2018 Jun Zhao
+ *
+ * VA-API Acceleration API (video decoding/scaling) sample
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * VA-API-Accelerated decoding/scaling example.
+ *
+ * @example vaapi_dec_scaling.c
+ * This example shows how to do VA-API-accelerated decoding/scaling with output
+ * frames from the HW video surfaces.
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static AVBufferRef *hw_device_ctx = NULL;
+static enum AVPixelFormat hw_pix_fmt;
+static FILE *output_file = NULL;
+AVFilterContext *buffersink_ctx;
+AVFilterContext *buffersrc_ctx;
+AVFilterGraph *filter_graph;
+const char *filter_descr =
+"format=vaapi,scale_vaapi=w=iw/2:h=ih/2,hwdownload,format=nv12";
+int init_filter = 0;
+
+static int init_hw_decode(AVCodecContext *ctx, const enum AVHWDeviceType type)
+{
+int err = 0;
+
+if ((err = av_hwdevice_ctx_create(&hw_device_ctx, type,
+ NULL, NULL, 0)) < 0) {
+fprintf(stderr, "Failed to create specified HW device.\n");
+return err;
+}
+ctx->hw_device_ctx = av_buffer_ref(hw_device_ctx);
+
+return err;
+}
+
+static int init_filters(AVFormatContext *fmt_ctx, AVCodecContext *dec_ctx,
+int video_stream_index, const char *filters_descr)
+{
+char args[512];
+int ret = 0;
+const AVFilter *buffersrc = avfilter_get_by_name("buffer");
+const AVFilter *buffersink = avfilter_get_by_name("buffersink");
+AVFilterInOut *outputs = avfilter_inout_alloc();
+AVFilterInOut *inputs = avfilter_inout_alloc();
+AVRational time_base = fmt_ctx->streams[video_stream_index]->time_base;
+AVBufferSrcParameters *par = av_buffersrc_parameters_alloc();
+
+filter_graph = avfilter_graph_alloc();
+if (!outputs || !inputs || !filter_graph || !par) {
+ret = AVERROR(ENOMEM);
+goto end;
+}
+
+/* buffer video source: the decoded frames from the decoder will be
inserted here. */
+snprintf(args, sizeof(args),
+"video_size=%dx%d:pix_fmt=%d:time_base=%d/%d:pixel_aspect=%d/%d",
+dec_ctx->width, dec_ctx->height, AV_PIX_FMT_VAAPI,
+time_base.num, time_base.den,
+dec_ctx->sample_aspect_ratio.num,
dec_ctx->sample_aspect_ratio.den);
+
+ret = avfilter_g
Re: [FFmpeg-devel] qt-faststart bug near 4GB
> On Sun, Jun 10, 2018 at 01:20:10PM +, Eran Kornblau wrote:
> > >
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > Behalf Of Michael Niedermayer
> > > Sent: Saturday, June 9, 2018 9:17 PM
> > > To: FFmpeg development discussions and patches
> > >
> > > Subject: Re: [FFmpeg-devel] qt-faststart bug near 4GB
> > >
> > > > +
> > > > +if (atom.size < atom.header_size) {
> > >
> > > > +printf("atom size %"PRIu64" too small\n", atom.size);
> > >
> > > errors should go to stderr if av_log() is not used i see this is not
> > > introduced by the patch but was that way before so its more a comment
> > > about the code in git than the patch ...
> > > but ideally this should be fixed in a seperate patch either before
> > > or after this one
> >
> > I agree, had the same thought when I wrote the patch, but left it as it was
> > - only the usage error is printed to stderr.
> > Will submit a patch for this after we finalize the discussion on this one.
> >
> > >
> > > some self test for the newly added feature would also be a good idea
> >
> > Since a real MP4 with this problem is going to be large (4GB), I'm
> > thinking about taking a small MP4, and patch some stco offset to
> > UINT_MAX. Naturally, it will break the file, but faststart won't care - it
> > should still upgrade the stco to co64, and we can just compare the
> > cksum/md5sum of the result to some fixed value.
> > What do you think?
>
> hmm, thats probably the most practical, yes
>
> you could also simply compress the file a 4gb file thats 99.99% 0 bytes is
> not large but the problem would be that to test this it would need to be
> decompressed and the space requirements seems too problematic for fate clients
>
Ok, took the 'fake offset' approach - created the attached mp4 with -
ffmpeg -f lavfi -i anullsrc=sample_rate=48000 -t 1 faststart-4gb-overflow.mov
python
d = file('faststart-4gb-overflow.mov','rb').read()
p = d.find('stco')
d = d[:(p+12)] + '\xff' * 4 + d[(p+16):]
file('faststart-4gb-overflow.mov','wb').write(d)
I added a fate test for this under 'mov' (that seemed the closest match...).
For the faststart output, I'm using a temp file, I tried to avoid it with -
qt-faststart input.mov >(md5sum -)
But for some reason, this didn't work from 'make fate' (it did work in bash).
Another option to avoid the temp file, is that I'll add support for passing '-'
as the qt-faststart output file name, and have it write to stdout.
Since all writes there are sequential (no seeks) it should be easy.
Let me know what you prefer... anyway, current patch + sample file are attached.
>
> >
> > Btw, the tests we ran on this change internally are - 1. compared the
> > result of the new version to the previous one on more than 1k files
> > (incl small files and large >4gb files) and verified the result was
> > exactly the same (the edge case this solves is extremely rare, and "normal"
> > files are not expected to change) 2. checked the specific file that had
> > this issue, and verified it was fixed.
> >
> > >
>
> > > also, was the new code tested with a fuzzer ?
> >
> > No, can you provide some guidance on this - is there some fuzzing framework
> > that you're using?
>
> hmm, you can probably add qt-faststart to:
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Foss-fuzz%2Ftree%2Fmaster%2Fprojects%2Fffmpeg&data=02%7C01%7Ceran.kornblau%40kaltura.com%7C439d2ebbc07940dc5cda08d5cf345a9b%7C0c503748de3f4e2597e26819d53a42b6%7C0%7C0%7C636642746144001154&sdata=8N9HpfHJ6atTGmtwHmr0Vuccw39W7RzMM%2BLw%2F4Ptj0g%3D&reserved=0
>
> this is probably a bit effort though.
>
> using some arbitrary choosen fuzzer, AFL, zzuf or anything else is probably
> simpler. adding it to oss-fuzz has the advantage that google will in the
> future automatically do the fuzzing for qt-faststart in ffmpeg.
> to add it to oss-fuzz you probably would have to submit changes both to the
> oss-fuzz ffmpeg repo as well as to ffmpeg ...
>
Is this mandatory? :) it may be because I'm not familiar with these frameworks,
but indeed sounds like
a significant effort to do it...
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> It is what and why we do it that matters, not just one of them.
>
Thanks!
Eran
0001-qt-faststart-add-fate-test-for-stco-overflow.patch
Description: 0001-qt-faststart-add-fate-test-for-stco-overflow.patch
faststart-4gb-overflow.mov
Description: faststart-4gb-overflow.mov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avcodec/videotoolboxenc: split initialization
Split vtenc_init() into vtenc_init() (VTEncContext initialization) and
vtenc_configure_encoder() (creates the vt session).
This commit will allow to restart the vt session while encoding.
---
libavcodec/videotoolboxenc.c | 48 +---
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index 9f2a71b15d..1060055ba5 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -1262,19 +1262,16 @@ static int vtenc_create_encoder(AVCodecContext *avctx,
return 0;
}
-static av_cold int vtenc_init(AVCodecContext *avctx)
+static int vtenc_configure_encoder(AVCodecContext *avctx)
{
CFMutableDictionaryRef enc_info;
CFMutableDictionaryRef pixel_buffer_info;
CMVideoCodecType codec_type;
VTEncContext *vtctx = avctx->priv_data;
CFStringRefprofile_level;
-CFBooleanRef has_b_frames_cfbool;
CFNumberRefgamma_level = NULL;
intstatus;
-pthread_once(&once_ctrl, loadVTEncSymbols);
-
codec_type = get_cm_codec_type(avctx->codec_id);
if (!codec_type) {
av_log(avctx, AV_LOG_ERROR, "Error: no mapping for AVCodecID %d\n",
avctx->codec_id);
@@ -1304,8 +1301,6 @@ static av_cold int vtenc_init(AVCodecContext *avctx)
if (!get_vt_hevc_profile_level(avctx, &profile_level)) return
AVERROR(EINVAL);
}
-vtctx->session = NULL;
-
enc_info = CFDictionaryCreateMutable(
kCFAllocatorDefault,
20,
@@ -1335,8 +1330,6 @@ static av_cold int vtenc_init(AVCodecContext *avctx)
pixel_buffer_info = NULL;
}
-pthread_mutex_init(&vtctx->lock, NULL);
-pthread_cond_init(&vtctx->cv_sample_sent, NULL);
vtctx->dts_delta = vtctx->has_b_frames ? -1 : 0;
get_cv_transfer_function(avctx, &vtctx->transfer_function, &gamma_level);
@@ -1363,8 +1356,32 @@ static av_cold int vtenc_init(AVCodecContext *avctx)
pixel_buffer_info,
&vtctx->session);
-if (status < 0)
-goto init_cleanup;
+init_cleanup:
+if (gamma_level)
+CFRelease(gamma_level);
+
+if (pixel_buffer_info)
+CFRelease(pixel_buffer_info);
+
+CFRelease(enc_info);
+
+return status;
+}
+
+static av_cold int vtenc_init(AVCodecContext *avctx)
+{
+VTEncContext*vtctx = avctx->priv_data;
+CFBooleanRefhas_b_frames_cfbool;
+int status;
+
+pthread_once(&once_ctrl, loadVTEncSymbols);
+
+pthread_mutex_init(&vtctx->lock, NULL);
+pthread_cond_init(&vtctx->cv_sample_sent, NULL);
+
+vtctx->session = NULL;
+status = vtenc_configure_encoder(avctx);
+if (status) return status;
status = VTSessionCopyProperty(vtctx->session,
kVTCompressionPropertyKey_AllowFrameReordering,
@@ -1378,16 +1395,7 @@ static av_cold int vtenc_init(AVCodecContext *avctx)
}
avctx->has_b_frames = vtctx->has_b_frames;
-init_cleanup:
-if (gamma_level)
-CFRelease(gamma_level);
-
-if (pixel_buffer_info)
-CFRelease(pixel_buffer_info);
-
-CFRelease(enc_info);
-
-return status;
+return 0;
}
static void vtenc_get_frame_info(CMSampleBufferRef buffer, bool *is_key_frame)
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avcodec/videotoolboxenc: fix mutex/cond leak in error path
The leak could happen when the vtenc_create_encoder() function failed.
---
libavcodec/videotoolboxenc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index 7796a685c2..9f2a71b15d 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -2473,13 +2473,14 @@ static av_cold int vtenc_close(AVCodecContext *avctx)
{
VTEncContext *vtctx = avctx->priv_data;
+pthread_cond_destroy(&vtctx->cv_sample_sent);
+pthread_mutex_destroy(&vtctx->lock);
+
if(!vtctx->session) return 0;
VTCompressionSessionCompleteFrames(vtctx->session,
kCMTimeIndefinite);
clear_frame_queue(vtctx);
-pthread_cond_destroy(&vtctx->cv_sample_sent);
-pthread_mutex_destroy(&vtctx->lock);
CFRelease(vtctx->session);
vtctx->session = NULL;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avcodec/videotoolboxenc: fix invalid session on iOS
Cf. comment. Restart the VT session when the APP goes from foreground to
background and vice versa.
---
libavcodec/videotoolboxenc.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index 1060055ba5..4b79fca45e 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -2175,8 +2175,29 @@ static int create_cv_pixel_buffer(AVCodecContext
*avctx,
#if TARGET_OS_IPHONE
pix_buf_pool = VTCompressionSessionGetPixelBufferPool(vtctx->session);
if (!pix_buf_pool) {
-av_log(avctx, AV_LOG_ERROR, "Could not get pixel buffer pool.\n");
-return AVERROR_EXTERNAL;
+/* On iOS, the VT session is invalidated when the APP switches from
+ * foreground to background and vice versa. Fetch the actual error code
+ * of the VT session to detect that case and restart the VT session
+ * accordingly. */
+OSStatus vtstatus =
+VTCompressionSessionPrepareToEncodeFrames(vtctx->session);
+
+if (vtstatus == kVTInvalidSessionErr)
+{
+CFRelease(vtctx->session);
+vtctx->session = NULL;
+status = vtenc_configure_encoder(avctx);
+if (status == 0)
+pix_buf_pool =
VTCompressionSessionGetPixelBufferPool(vtctx->session);
+}
+if (!pix_buf_pool)
+{
+av_log(avctx, AV_LOG_ERROR, "Could not get pixel buffer pool.\n");
+return AVERROR_EXTERNAL;
+}
+else
+av_log(avctx, AV_LOG_WARNING, "VT session restarted because of a "
+ "kVTInvalidSessionErr error.\n");
}
status = CVPixelBufferPoolCreatePixelBuffer(NULL,
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/movenc: fix recognization of cover image streams
On Mon, 4 Jun 2018 17:36:19 +0300 Timo Teräs wrote: > For chapter images, the mov demux produces streams with disposition > set to attached_pic+timed_thumbnails. This patch fixes to properly > recognize streams that should be encoded as cover image (ones with > only and only attached_pic disposition set). > > Signed-off-by: Timo Teräs > --- > > ffmpeg should act close to what a inteligent user expects. > > For example a simple ffmpeg -i inputfile outputfile > > should produce a outputfile that results in similar presentation as > > the input when played. > >... > > It may be good to minimize the amount of exceptions for how streams > > are handled. > > Agree. My question was more about the details how the disposition > flags should be handled, because there seems to be no accurate > documentation. Apparently the logic is to handle based on what > demuxers produce. > > This patch addresses how the cover image is detected, and should > restore earlier behaviour on copying files where demuxer supports > more features than current muxer. > > This applies on top of the "[v2] avformat/movenc: properly handle > cover image codecs" patch. I can rebase the order if wanted, but > it'll require little work. > > Hopefully just the above mentioned patch, and this one could be > applied in the order. Ping. Any feedback for this or the other patch? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][PATCH][Type 2] Revert "doc/developer.texi: Add a code of conduct"
On 6/10/18, Josh de Kock wrote: > On 2018/05/14 17:50, Derek Buitenhuis wrote: >> It was never enforced, and there is no documented way to enforce it, >> rendering it useless. >> >> [...] > > I think this is the best thing to do first. We could always re-add a > more 'proper' CoC later, but for now there's no point creating more > confusion. I stated this on IRC but saying this on the ML so it is > documented more publicly. > > Also, it has been more than a month since this was posted with no > resolution, when do you intend to take, or expect others to take, actual > action with regards to this? If I remember correctly, the CoC has been voted, so it would need another vote to remove it. I do not see any immediate problem that compels messing with CoC and the politics associated with it. The less people are involved in politics, the more work on code could be done. Keep Calm and Carry On. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_opt: Add -toeof option to stop writing relative to EOF
2018-06-10 22:07 GMT+02:00 Jan Ekström : > > Yes, programmatic things for things like these are often better. That > said, the question regarding sseof can be answered by "the person who > merged this stuff was OK with all the asterisks/caveats around it". > > Think of MPEG-TS, for example. I think - quite a bit simplified - it > basically parses the timestamps until it finishes probing, and then > extrapolates according to the size/bit rate of the file. That might be > close, or that might be not close at all. At the end of the day, the > libraries in FFmpeg are very much based on A->B access, not > frame-exactness in access or figuring out the full length of a media > file with any sort of precision. Of course, this doesn't mean that > this base feature set cannot be utilized to gain such features - ffms2 > (https://github.com/FFMS/ffms2/) is one example of this, which is a > wrapper around FFmpeg's libraries that indexes the file, and then > provides you (unless you hit a bug or special case) frame-exact access > to the contents. > > Many people have their own use cases for various things and have > enough leverage to get things that specifically work for their use > case into the code base, which is why in the end we have three > different ways of doing concatenation in the libraries (instead of > implementing it in the API client), each with their own caveats > (protocol, demuxer, filter). And the users will trust these features, > and attempt to utilize them for their own use cases. That, in various > cases, can lead to things just not working, as often the caveats are > not mentioned and the attempted use cases are different from what > those features were originally designed for. > > > Best regards, > Jan > I can see what you mean, but this is such a trivial little addition, I really fail to see how any big problems would arise from this. Perhaps a disclaimer that file duration can be inaccurate and should not be relied upon should be added to sseof and also toeof then? The options already fail if duration is completely unknown. Anyway, since I'm not really sure how to update the patch with git send-email without creating another patch on the tracker (I changed the commit message to "stop reading"), here is the revised patch attached. If I should add it as a new patch, please let me know and I will do so. Regards, Morten 0001-fftools-ffmpeg_opt-Add-toeof-option-to-stop-reading-.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_opt: Add -toeof option to stop writing relative to EOF
On 12-06-2018 12:48 AM, Morten With wrote: commit message to "stop reading"), here is the revised patch attached. Maybe I missed it, but in the new patch, you don't vet ss against toeof i.e. for a 10-second file, -ss 7 -toeof -4 should be declared invalid. Also, this isn't an issue with your patch but ss / sseof dual setting isn't checked nor is the validity of the sseof value. Let me get a patch in first to rectify that. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_opt: Add -toeof option to stop writing relative to EOF
Yeah, I was thinking that there seemed to be very little validation of -sseof combinations. That's why I initially didn't add any of those for -toeof. You are correct, that is missing, I'll add that once your patch is done then. Also, was this the correct way to send in a revised patch? I'm completely new to this. Regards, Morten 2018-06-11 22:23 GMT+02:00 Gyan Doshi : > > > On 12-06-2018 12:48 AM, Morten With wrote: > > commit message to "stop reading"), here is the revised patch attached. >> > > Maybe I missed it, but in the new patch, you don't vet ss against toeof > i.e. for a 10-second file, -ss 7 -toeof -4 should be declared invalid. > > Also, this isn't an issue with your patch but ss / sseof dual setting > isn't checked nor is the validity of the sseof value. > > Let me get a patch in first to rectify that. > > Regards, > Gyan > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]ffplay: Don't crash if stream_cycle_channel() is called before initialization
On Mon, 11 Jun 2018, Carl Eugen Hoyos wrote:
Hi!
Attached patch fixes a crash if SDL sends a keydown event before
stream and window initialization is finished, ticket #7252.
Wow, current ffplay code assumes that no keypress or mouse events will
come before the window is shown. Strange thing that SDL2 on IOS
is forwarding input events even without a window...
So in order to fix this more thoroughly, I suggest the attached patch
instead. Supporting keypresses without a window (e.g. -nodisp mode) might
be possible, but that requires bigger changes...
Regards,
MartonFrom 23ec72e867f3f25f422d6c1c7298cfcf79b4f113 Mon Sep 17 00:00:00 2001
From: Marton Balint
Date: Mon, 11 Jun 2018 23:19:37 +0200
Subject: [PATCH] ffplay: ignore keypress events before a window is created
Current ffplay code assumes that the read thread is in its main loop before any
key events are captured, but apparently on IOS even keypresses without a window
are forwared.
Fixes ticket #7252.
Signed-off-by: Marton Balint
---
fftools/ffplay.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 84ba6673dc..55cea32cae 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -3251,15 +3251,14 @@ static void event_loop(VideoState *cur_stream)
refresh_loop_wait_event(cur_stream, &event);
switch (event.type) {
case SDL_KEYDOWN:
-if (exit_on_keydown) {
+if (exit_on_keydown || event.key.keysym.sym == SDLK_ESCAPE || event.key.keysym.sym == SDLK_q) {
do_exit(cur_stream);
break;
}
+// If we don't yet have a window, skip all key events, because read_thread might still be initializing...
+if (!cur_stream->width)
+continue;
switch (event.key.keysym.sym) {
-case SDLK_ESCAPE:
-case SDLK_q:
-do_exit(cur_stream);
-break;
case SDLK_f:
toggle_full_screen(cur_stream);
cur_stream->force_refresh = 1;
--
2.16.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_opt: Add -toeof option to stop writing relative to EOF
On Mon, Jun 11, 2018, at 1:00 PM, Morten With wrote: > > Also, was this the correct way to send in a revised patch? I'm completely > new to this. Yes, that is acceptable. We are not too picky about that. It can be helpful to rename the subject, such as [PATCH v2], if desired: especially if multiple iterations are to be expected. Also see the "-v" and "--in-reply-to" options in "git format-patch". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavfilter/opencl.h: Add macro for setting opencl kernel
---
libavfilter/opencl.h| 15 ++
libavfilter/vf_convolution_opencl.c | 43
libavfilter/vf_overlay_opencl.c | 44 +++-
libavfilter/vf_unsharp_opencl.c | 57 ++---
4 files changed, 46 insertions(+), 113 deletions(-)
diff --git a/libavfilter/opencl.h b/libavfilter/opencl.h
index c0a4519..7441b11 100644
--- a/libavfilter/opencl.h
+++ b/libavfilter/opencl.h
@@ -46,6 +46,21 @@ typedef struct OpenCLFilterContext {
intoutput_height;
} OpenCLFilterContext;
+
+/**
+ * set argument to specific Kernel.
+ * This macro relies on usage of local label "fail" and variables:
+ * avctx, cle and err.
+ */
+#define CL_SET_KERNEL_ARG(kernel, arg_num, type, arg) \
+cle = clSetKernelArg(kernel, arg_num, sizeof(type), arg); \
+if (cle != CL_SUCCESS) { \
+av_log(avctx, AV_LOG_ERROR, "Failed to set kernel "\
+ "argument %d: error %d.\n", arg_num, cle); \
+err = AVERROR(EIO);\
+goto fail; \
+}
+
/**
* Return that all inputs and outputs support only AV_PIX_FMT_OPENCL.
*/
diff --git a/libavfilter/vf_convolution_opencl.c
b/libavfilter/vf_convolution_opencl.c
index 2df51e0..4d0ecf8 100644
--- a/libavfilter/vf_convolution_opencl.c
+++ b/libavfilter/vf_convolution_opencl.c
@@ -204,43 +204,12 @@ static int convolution_opencl_filter_frame(AVFilterLink
*inlink, AVFrame *input)
if (!dst)
break;
-cle = clSetKernelArg(ctx->kernel, 0, sizeof(cl_mem), &dst);
-if (cle != CL_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Failed to set kernel "
- "destination image argument: %d.\n", cle);
-goto fail;
-}
-cle = clSetKernelArg(ctx->kernel, 1, sizeof(cl_mem), &src);
-if (cle != CL_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Failed to set kernel "
- "source image argument: %d.\n", cle);
-goto fail;
-}
-cle = clSetKernelArg(ctx->kernel, 2, sizeof(cl_int), &ctx->dims[p]);
-if (cle != CL_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Failed to set kernel "
- "matrix size argument: %d.\n", cle);
-goto fail;
-}
-cle = clSetKernelArg(ctx->kernel, 3, sizeof(cl_mem), &ctx->matrix[p]);
-if (cle != CL_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Failed to set kernel "
- "matrix argument: %d.\n", cle);
-goto fail;
-}
-cle = clSetKernelArg(ctx->kernel, 4, sizeof(cl_float), &ctx->rdivs[p]);
-if (cle != CL_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Failed to set kernel "
- "rdiv argument: %d.\n", cle);
-goto fail;
-}
-cle = clSetKernelArg(ctx->kernel, 5, sizeof(cl_float),
&ctx->biases[p]);
-if (cle != CL_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Failed to set kernel "
- "bias argument: %d.\n", cle);
-goto fail;
-}
-
+CL_SET_KERNEL_ARG(ctx->kernel, 0, cl_mem, &dst);
+CL_SET_KERNEL_ARG(ctx->kernel, 1, cl_mem, &src);
+CL_SET_KERNEL_ARG(ctx->kernel, 2, cl_int, &ctx->dims[p]);
+CL_SET_KERNEL_ARG(ctx->kernel, 3, cl_mem, &ctx->matrix[p]);
+CL_SET_KERNEL_ARG(ctx->kernel, 4, cl_float, &ctx->rdivs[p]);
+CL_SET_KERNEL_ARG(ctx->kernel, 5, cl_float, &ctx->biases[p]);
err = ff_opencl_filter_work_size_from_image(avctx, global_work,
output, p, 0);
if (err < 0)
diff --git a/libavfilter/vf_overlay_opencl.c b/libavfilter/vf_overlay_opencl.c
index b43050d..556ce35 100644
--- a/libavfilter/vf_overlay_opencl.c
+++ b/libavfilter/vf_overlay_opencl.c
@@ -167,47 +167,39 @@ static int overlay_opencl_blend(FFFrameSync *fs)
kernel_arg = 0;
mem = (cl_mem)output->data[plane];
-cle = clSetKernelArg(ctx->kernel, kernel_arg++, sizeof(cl_mem), &mem);
-if (cle != CL_SUCCESS)
-goto fail_kernel_arg;
+CL_SET_KERNEL_ARG(ctx->kernel, kernel_arg, cl_mem, &mem);
+kernel_arg++;
mem = (cl_mem)input_main->data[plane];
-cle = clSetKernelArg(ctx->kernel, kernel_arg++, sizeof(cl_mem), &mem);
-if (cle != CL_SUCCESS)
-goto fail_kernel_arg;
+CL_SET_KERNEL_ARG(ctx->kernel, kernel_arg, cl_mem, &mem);
+kernel_arg++;
mem = (cl_mem)input_overlay->data[plane];
-cle = clSetKernelArg(ctx->kernel, kernel_arg++, sizeof(cl_mem), &mem);
-if (cle != CL_SUCCESS)
-goto fail_kernel_arg;
+CL_SET_KERNEL_ARG(ctx->kernel, kernel_arg, cl_mem, &mem);
+kernel_arg++;
if (ctx->alpha_separate) {
mem = (cl_mem)input_overlay->data[ctx->nb_planes];
-
[FFmpeg-devel] [PATCH] smc: check for frame dimensions
---
libavcodec/smc.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/libavcodec/smc.c b/libavcodec/smc.c
index 3cb4834..fc1d308 100644
--- a/libavcodec/smc.c
+++ b/libavcodec/smc.c
@@ -421,6 +421,13 @@ static av_cold int smc_decode_init(AVCodecContext *avctx)
s->avctx = avctx;
avctx->pix_fmt = AV_PIX_FMT_PAL8;
+if (!avctx->width || !avctx->height ||
+(avctx->width & 1) || (avctx->height & 1)) {
+av_log(avctx, AV_LOG_ERROR, "Invalid video dimensions: %dx%d\n",
+ avctx->width, avctx->height);
+return AVERROR(EINVAL);
+}
+
s->frame = av_frame_alloc();
if (!s->frame)
return AVERROR(ENOMEM);
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] seqvideo_decode_init:check frame dimensions
---
libavcodec/tiertexseqv.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/libavcodec/tiertexseqv.c b/libavcodec/tiertexseqv.c
index af39f74..2d0fa98 100644
--- a/libavcodec/tiertexseqv.c
+++ b/libavcodec/tiertexseqv.c
@@ -222,6 +222,13 @@ static av_cold int seqvideo_decode_init(AVCodecContext
*avctx)
if (ret < 0)
return ret;
+if (!avctx->width || !avctx->height ||
+(avctx->width & 1) || (avctx->height & 1)) {
+av_log(avctx, AV_LOG_ERROR, "Invalid video dimensions: %dx%d\n",
+ avctx->width, avctx->height);
+return AVERROR(EINVAL);
+}
+
seq->frame = av_frame_alloc();
if (!seq->frame)
return AVERROR(ENOMEM);
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] smc: check for frame dimensions
sms: check for frame dimensions 0001-smc-check-for-frame-dimensions.patch Description: 0001-smc-check-for-frame-dimensions.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 09/12] avformat/mxfdec: add support for clip wrapped essences
On Sun, Jun 10, 2018 at 12:36:47PM +0200, Marton Balint wrote: > Also use common code with opAtom. > > Fixes ticket #2776. > Partially fixes ticket #5671. > Fixes ticket #5866. > > Signed-off-by: Marton Balint > --- > libavformat/mxfdec.c | 281 > --- > 1 file changed, 130 insertions(+), 151 deletions(-) causes a segfault: ==23735== Invalid read of size 8 ==23735==at 0x75A627: mxf_set_pts (mxfdec.c:3277) ==23735==by 0x75ACAD: mxf_read_packet_old (mxfdec.c:3396) ==23735==by 0x7E099D: ff_read_packet (utils.c:856) ==23735==by 0x7E39FF: read_frame_internal (utils.c:1581) ==23735==by 0x7EB82B: avformat_find_stream_info (utils.c:3773) ==23735==by 0x415534: open_input_file (ffmpeg_opt.c:1091) ==23735==by 0x41EB11: open_files (ffmpeg_opt.c:3206) ==23735==by 0x41ECA3: ffmpeg_parse_options (ffmpeg_opt.c:3246) ==23735==by 0x43D1A3: main (ffmpeg.c:4832) ==23735== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==23735== ==23735== ==23735== Process terminating with default action of signal 11 (SIGSEGV) ==23735== Access not within mapped region at address 0x0 ==23735==at 0x75A627: mxf_set_pts (mxfdec.c:3277) ==23735==by 0x75ACAD: mxf_read_packet_old (mxfdec.c:3396) ==23735==by 0x7E099D: ff_read_packet (utils.c:856) ==23735==by 0x7E39FF: read_frame_internal (utils.c:1581) ==23735==by 0x7EB82B: avformat_find_stream_info (utils.c:3773) ==23735==by 0x415534: open_input_file (ffmpeg_opt.c:1091) ==23735==by 0x41EB11: open_files (ffmpeg_opt.c:3206) ==23735==by 0x41ECA3: ffmpeg_parse_options (ffmpeg_opt.c:3246) ==23735==by 0x43D1A3: main (ffmpeg.c:4832) ==23735== If you believe this happened as a result of a stack ==23735== overflow in your program's main thread (unlikely but ==23735== possible), you can try to increase the size of the ==23735== main thread stack using the --main-stacksize= flag. ==23735== The main thread stack size used in this run was 8388608. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 09/36] vaapi_encode: Allocate picture-private data in generic code
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> ---
> libavcodec/vaapi_encode.c | 15 ---
> libavcodec/vaapi_encode.h | 4
> 2 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index cedf3d3549..ed6d289c6b 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -528,14 +528,23 @@ static int vaapi_encode_discard(AVCodecContext *avctx,
> return 0;
> }
>
> -static VAAPIEncodePicture *vaapi_encode_alloc(void)
> +static VAAPIEncodePicture *vaapi_encode_alloc(AVCodecContext *avctx)
> {
> +VAAPIEncodeContext *ctx = avctx->priv_data;
> VAAPIEncodePicture *pic;
>
> pic = av_mallocz(sizeof(*pic));
> if (!pic)
> return NULL;
>
> +if (ctx->codec->picture_priv_data_size > 0) {
> +pic->priv_data = av_mallocz(ctx->codec->picture_priv_data_size);
> +if (!pic->priv_data) {
> +av_freep(&pic);
> +return NULL;
> +}
> +}
> +
> pic->input_surface = VA_INVALID_ID;
> pic->recon_surface = VA_INVALID_ID;
> pic->output_buffer = VA_INVALID_ID;
> @@ -668,7 +677,7 @@ static int vaapi_encode_get_next(AVCodecContext *avctx,
> }
> }
>
> -pic = vaapi_encode_alloc();
> +pic = vaapi_encode_alloc(avctx);
> if (!pic)
> return AVERROR(ENOMEM);
>
> @@ -697,7 +706,7 @@ static int vaapi_encode_get_next(AVCodecContext *avctx,
>
> for (i = 0; i < ctx->b_per_p &&
> ctx->gop_counter < avctx->gop_size; i++) {
> -pic = vaapi_encode_alloc();
> +pic = vaapi_encode_alloc(avctx);
> if (!pic)
> goto fail;
>
> diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
> index c7370a17e2..54dc4a475e 100644
> --- a/libavcodec/vaapi_encode.h
> +++ b/libavcodec/vaapi_encode.h
> @@ -211,6 +211,10 @@ typedef struct VAAPIEncodeType {
> // add any necessary global parameters).
> int (*configure)(AVCodecContext *avctx);
>
> +// The size of any private data structure associated with each
> +// picture (can be zero if not required).
> +size_t picture_priv_data_size;
> +
I didn't see this field is set in the existent vaapi codecs, is the private data
structure really needed for a picture? If not, I'd like to remove the field of
priv_data from VAAPIEncodePicture instead.
> // The size of the parameter structures:
> // sizeof(VAEnc{type}ParameterBuffer{codec}).
> size_t sequence_params_size;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: remove unused MP4A_LATM flag
Will push tomorrow. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
