Re: [FFmpeg-devel] [PATCH] avformat/rtsp: Add -first_rtcp_ntp_time_path option to write the first NTP time to a file.
Apologies, here is the patch in text/plain.
On Thu, May 23, 2019 at 4:44 PM Jonathan Viney
wrote:
> Hi,
>
> The NTP time from the first RTCP packet is currently extracted in
> libavformat/rtsp.c and stored in AVFormatContext.start_time_realtime.
> However, there is no way to access this value when using ffmpeg from the
> commandline.
>
> This patch adds an option when using an RTSP input to write the value to a
> file when it is received.
>
> Eg:
> ffmpeg -first_rtcp_ntp_time_path out.mp4.ntp -i rtsp://10.0.0.1/ -c copy
> out.mp4
>
> Regards,
> -Jonathan.
>
From e16826736640f132f0d3a6f170337ab9696e0038 Mon Sep 17 00:00:00 2001
From: Jonathan Viney
Date: Thu, 23 May 2019 14:24:16 +1200
Subject: [PATCH] avformat/rtsp: add -first_rtcp_ntp_time_path option to write
the first NTP time to a file.
Signed-off-by: Jonathan Viney
---
libavformat/rtsp.c | 16
libavformat/rtsp.h | 6 ++
2 files changed, 22 insertions(+)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index c153cac88b..4b048701e2 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -96,6 +96,7 @@ const AVOption ff_rtsp_options[] = {
{ "min_port", "set minimum local UDP port", OFFSET(rtp_port_min),
AV_OPT_TYPE_INT, {.i64 = RTSP_RTP_PORT_MIN}, 0, 65535, DEC|ENC },
{ "max_port", "set maximum local UDP port", OFFSET(rtp_port_max),
AV_OPT_TYPE_INT, {.i64 = RTSP_RTP_PORT_MAX}, 0, 65535, DEC|ENC },
{ "listen_timeout", "set maximum timeout (in seconds) to wait for incoming
connections (-1 is infinite, imply flag listen)", OFFSET(initial_timeout),
AV_OPT_TYPE_INT, {.i64 = -1}, INT_MIN, INT_MAX, DEC },
+{ "first_rtcp_ntp_time_path", "path to write first NTP time (in
microseconds) received in RTCP packet", OFFSET(first_rtcp_ntp_time_path),
AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, DEC },
#if FF_API_OLD_RTSP_OPTIONS
{ "timeout", "set maximum timeout (in seconds) to wait for incoming
connections (-1 is infinite, imply flag listen) (deprecated, use
listen_timeout)", OFFSET(initial_timeout), AV_OPT_TYPE_INT, {.i64 = -1},
INT_MIN, INT_MAX, DEC },
{ "stimeout", "set timeout (in microseconds) of socket TCP I/O
operations", OFFSET(stimeout), AV_OPT_TYPE_INT, {.i64 = 0}, INT_MIN, INT_MAX,
DEC },
@@ -2256,6 +2257,21 @@ redo:
(uint64_t) rtpctx->st->time_base.num *
100,
rtpctx->st->time_base.den);
}
+
+// Write the NTP start time
+if (rt->first_rtcp_ntp_time_path) {
+AVIOContext *ioctx = NULL;
+int ret;
+ret = avio_open(, rt->first_rtcp_ntp_time_path,
AVIO_FLAG_WRITE);
+if (ret < 0) {
+av_log(s, AV_LOG_WARNING, "unable to open %s to
write first rtcp ntp time\n", rt->first_rtcp_ntp_time_path);
+} else {
+char buf[21] = "";
+av_strlcatf(buf, sizeof(buf), "%lld",
s->start_time_realtime);
+avio_write(ioctx, buf, strlen(buf));
+avio_closep();
+}
+}
}
}
if (ret == -RTCP_BYE) {
diff --git a/libavformat/rtsp.h b/libavformat/rtsp.h
index 54a9a30c16..4df24b743a 100644
--- a/libavformat/rtsp.h
+++ b/libavformat/rtsp.h
@@ -408,6 +408,12 @@ typedef struct RTSPState {
*/
char *user_agent;
+/**
+ * Path to write the first RTCP unix time in microseconds, if
+ * it is received as part of the stream.
+ */
+char *first_rtcp_ntp_time_path;
+
char default_lang[4];
int buffer_size;
int pkt_size;
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/rtsp: Add -first_rtcp_ntp_time_path option to write the first NTP time to a file.
Hi, The NTP time from the first RTCP packet is currently extracted in libavformat/rtsp.c and stored in AVFormatContext.start_time_realtime. However, there is no way to access this value when using ffmpeg from the commandline. This patch adds an option when using an RTSP input to write the value to a file when it is received. Eg: ffmpeg -first_rtcp_ntp_time_path out.mp4.ntp -i rtsp://10.0.0.1/ -c copy out.mp4 Regards, -Jonathan. 0001-avformat-rtsp-add-first_rtcp_ntp_time_path-option-to.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavcodec/vp9: fix ref-frame size judging method
Hi, Ronald Sorry to reply late. For you question, “we lack per-block reference validity checks in the block reconstruction code”, I'm little confused about the red word,would you mean encode process need validity checks or there need to check the reference id of each frame? And this patch will act on decode process, all references have already been appointed by the stream. Br Cen Ronald S. Bultje 于2019年5月1日周三 上午7:19写道： > Hi, > > On Mon, Apr 29, 2019 at 10:03 PM Yan Cen wrote: > > > From: Yan Cen > > > > There is no need all reference frame demension is valid in libvpx. > > > I think you're touching on a bigger issue here: libvpx allows having > invalid (or even missing) references, and we don't. Note that this means we > lack per-block reference validity checks in the block reconstruction code, > and your patch is not adding them, thus exposing us to potential security > issues there. > > Ronald > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] native mode in FFmpeg DNN module
> > > > > > Option 2) > > > > > > Write c code in FFmpeg to convert tensorflow file format (format 1) > > directly > > > > > into memory representation (format 3), and so we controls everything > > > > > in > > > > > ffmpeg community. And the conversion can be extended to import more > > file > > > > > formats such as torch, darknet, etc. One example is that OpenCV uses > > this > > > > > method. > > > > > > > > > > > > The in memory representation (format 3) can still be current. > > > > > > > > > > > > > > > > Option 2 would be ideal, as it does not introduce any dependency for > > > > > using the native backend. > > > > > Yet I'm not sure how complex implementing the tf model reader can > be, > > > > > If I remember correctly the student said it was not trivial at the > > > > > time. > > > > > > > > yes, it is not easy, but I think it is worthy to do it. Here is a > > > > reference > > example > > > > for the complexity, see > > > > > > > https://github.com/opencv/opencv/blob/master/modules/dnn/src/tensorflow/ > > > > tf_importer.cpp. > > > > > > > > > > > > > > Is the tf model file stable? if not it will be a maintenance burden to > > > > > keep it working whenever tf releases a new version. This point makes > > > > > me think having control over our file format is good. > > > > > > > > imho, this issue is always there, no matter which method used, unless > > > > our > > > > format could be exported by tensorflow (it has little possibility). > > > > > > > > Whenever tf releases a new version with a new file format, we still have > to > > > > change the python script in phase 1 (convert tf file model to our > > > > format) > > which > > > > is even an external dependency at > > > > https://github.com/HighVoltageRocknRoll/sr, > > > > > > > > As from effort perspective, the current implementation is better since > > python > > > > script is simpler. But I think we are still worth implementing option 2 > > > > as > the > > > > ideal technical direction. > > > > > > I checked a bit more about https://github.com/HighVoltageRocknRoll/sr, it > is > > actually > > > not an converter (from tf model to native model), but hard code for given > > models. > > > And the native model is not exactly the same as tf model, it even changes > the > > behavior > > > of pad parameter of conv layer. > > > > > > If community is open to option 2, I'll try it. > > > > > Option 2 is fine for me. > > that's great, :) looks that option 2 is a bit complex, TF model file is in protocol buffers (protobuf) format and not easy to parse it with simple c code. Since there is no official c support for protobuf, let's first image how the work can be done via official c++ support. 1. get protobuf compiler protoc, .h header files and .so library files (download or build from https://github.com/protocolbuffers/protobuf/tree/master/src). 2. get tensorflow model's .proto files from https://github.com/tensorflow/tensorflow/tree/master/tensorflow/core/framework. 3. generate .cc/.h files from .proto files (see step 2) via protoc (see step 1). 4. let the generated .cc/.h files be part of ffmpeg source tree, and build with protobuf header/library files. 5. at run time, the protobuf libraries are invoked. It means that the system should have installed protobuf dev package. furthermore, there is a compatible problem between the protobuf compiler, header files and library files. So, as a practice to fix it, the method is to make the protobuf source code be part of ffmpeg source tree. (it is a common practice, so we can many other projects contain the protobuf source code). I guess the above method is not acceptable in ffmpeg. I would be glad to continue if the community embrace this change. :) While the current implementation has external dependency, my new suggestion is: - add a python script under .../libavfilter/dnn/ (all other dnn source files will be also moved here later), so ffmpeg has the full control on it. - it is a script to convert tensorflow model file into native model file. (other formats such as caffe, torch can also be supported later if needed) thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2] lavfi/colorlevels: Add slice threading support
On Wed, May 22, 2019 at 12:24 PM Li, Zhong wrote:
>
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Jun Zhao
> > Sent: Tuesday, May 21, 2019 7:21 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Jun Zhao
> > Subject: [FFmpeg-devel] [PATCH V2] lavfi/colorlevels: Add slice threading
> > support
> >
> > From: Jun Zhao
> >
> > Add slice threading support, use the command like:
> >
> > ./ffmpeg -i input -vf colorlevel with 1080p h264 clip, the fps from 39 fps
> > to
> > 79 fps in the local
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavfilter/vf_colorlevels.c | 125
> > +++--
> > 1 files changed, 106 insertions(+), 19 deletions(-)
> >
> > diff --git a/libavfilter/vf_colorlevels.c b/libavfilter/vf_colorlevels.c
> > index
> > 5385a5e..68668e7 100644
> > --- a/libavfilter/vf_colorlevels.c
> > +++ b/libavfilter/vf_colorlevels.c
> > @@ -105,6 +105,83 @@ static int config_input(AVFilterLink *inlink)
> > return 0;
> > }
> >
> > +struct thread_data {
> > +const uint8_t *srcrow;
> > +uint8_t *dstrow;
> > +int dst_linesize;
> > +int src_linesize;
> > +
> > +double coeff;
> > +uint8_t offset;
> > +
> > +int h;
> > +
> > +int imin;
> > +int omin;
> > +};
> > +
> > +static int colorlevel_slice_8(AVFilterContext *ctx, void *arg, int
> > +jobnr, int nb_jobs) {
> > +ColorLevelsContext *s = ctx->priv;
> > +const struct thread_data *td = arg;
> > +
> > +int process_h = td->h;
> > +const int slice_start = (process_h * jobnr ) / nb_jobs;
> > +const int slice_end = (process_h * (jobnr+1)) / nb_jobs;
> > +int x, y;
> > +const uint8_t *srcrow = td->srcrow;
> > +uint8_t *dstrow = td->dstrow;
> > +const int step = s->step;
> > +const uint8_t offset = td->offset;
> > +
> > +int imin = td->imin;
> > +int omin = td->omin;
> > +double coeff = td->coeff;
> > +
> > +for (y = slice_start; y < slice_end; y++) {
> > +const uint8_t *src = srcrow;
> > +uint8_t *dst = dstrow;
> > +
> > +for (x = 0; x < s->linesize; x += step)
> > +dst[x + offset] = av_clip_uint8((src[x + offset] - imin) *
> > coeff
> > + omin);
> > +dstrow += td->dst_linesize;
> > +srcrow += td->src_linesize;
> > +}
> > +
> > +return 0;
> > +}
> > +
> > +static int colorlevel_slice_16(AVFilterContext *ctx, void *arg, int
> > +jobnr, int nb_jobs) {
> > +ColorLevelsContext *s = ctx->priv;
> > +const struct thread_data *td = arg;
> > +
> > +int process_h = td->h;
> > +const int slice_start = (process_h * jobnr ) / nb_jobs;
> > +const int slice_end = (process_h * (jobnr+1)) / nb_jobs;
> > +int x, y;
> > +const uint8_t *srcrow = td->srcrow;
> > +uint8_t *dstrow = td->dstrow;
> > +const int step = s->step;
> > +const uint8_t offset = td->offset;
> > +
> > +int imin = td->imin;
> > +int omin = td->omin;
> > +double coeff = td->coeff;
> > +
> > +for (y = slice_start; y < slice_end; y++) {
> > +const uint16_t *src = (const uint16_t *)srcrow;
> > +uint16_t *dst = (uint16_t *)dstrow;
>
> Function colorlevel_slice_16() is same as colorlevel_slice_8 expect here to
> replace unit8_t to be unit16t.
> Would better to define a template function to be reused.
I don't like to get in C to templates is some ugly macro code for
function overloading, this is the reason use 2 function for
8bits/16bits
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/ffv1dec_template: Optimize common case in run mode
Fixes: Timeout (14sec -> 9sec)
Fixes:
13398/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_fuzzer-5664106709778432
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/ffv1dec_template.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavcodec/ffv1dec_template.c b/libavcodec/ffv1dec_template.c
index 1b7f6c4bf5..0b1d176ba1 100644
--- a/libavcodec/ffv1dec_template.c
+++ b/libavcodec/ffv1dec_template.c
@@ -86,11 +86,19 @@ static av_always_inline int RENAME(decode_line)(FFV1Context
*s, int w,
run_mode = 2;
}
}
+if (sample[1][x - 1] == sample[0][x - 1]) {
+while (run_count > 1 && w-x > 1) {
+sample[1][x] = sample[0][x];
+x++;
+run_count--;
+}
+} else {
while (run_count > 1 && w-x > 1) {
sample[1][x] = RENAME(predict)(sample[1] + x, sample[0] +
x);
x++;
run_count--;
}
+}
run_count--;
if (run_count < 0) {
run_mode = 0;
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [FFMPEG DEVEL] [PATCH v5] fftools/ffprobe: Add S12M Timecode output as side data (such as SEI TC)
---
Change structure to conserve one SEI data=one side data with multiple
timecode elements
---
fftools/ffprobe.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index dea489d02e..c9c15fc205 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -165,6 +165,7 @@ typedef enum {
SECTION_ID_FRAME_TAGS,
SECTION_ID_FRAME_SIDE_DATA_LIST,
SECTION_ID_FRAME_SIDE_DATA,
+SECTION_ID_FRAME_SIDE_DATA_TIMECODE,
SECTION_ID_FRAME_LOG,
SECTION_ID_FRAME_LOGS,
SECTION_ID_LIBRARY_VERSION,
@@ -209,7 +210,8 @@ static struct section sections[] = {
[SECTION_ID_FRAME] = { SECTION_ID_FRAME, "frame", 0, {
SECTION_ID_FRAME_TAGS, SECTION_ID_FRAME_SIDE_DATA_LIST, SECTION_ID_FRAME_LOGS,
-1 } },
[SECTION_ID_FRAME_TAGS] = { SECTION_ID_FRAME_TAGS, "tags",
SECTION_FLAG_HAS_VARIABLE_FIELDS, { -1 }, .element_name = "tag", .unique_name =
"frame_tags" },
[SECTION_ID_FRAME_SIDE_DATA_LIST] ={ SECTION_ID_FRAME_SIDE_DATA_LIST,
"side_data_list", SECTION_FLAG_IS_ARRAY, { SECTION_ID_FRAME_SIDE_DATA, -1 },
.element_name = "side_data", .unique_name = "frame_side_data_list" },
-[SECTION_ID_FRAME_SIDE_DATA] = { SECTION_ID_FRAME_SIDE_DATA,
"side_data", 0, { -1 } },
+[SECTION_ID_FRAME_SIDE_DATA] = { SECTION_ID_FRAME_SIDE_DATA,
"side_data", 0, { SECTION_ID_FRAME_SIDE_DATA_TIMECODE, -1 } },
+[SECTION_ID_FRAME_SIDE_DATA_TIMECODE] = {
SECTION_ID_FRAME_SIDE_DATA_TIMECODE, "timecode", 0, { -1 } },
[SECTION_ID_FRAME_LOGS] = { SECTION_ID_FRAME_LOGS, "logs",
SECTION_FLAG_IS_ARRAY, { SECTION_ID_FRAME_LOG, -1 } },
[SECTION_ID_FRAME_LOG] = { SECTION_ID_FRAME_LOG, "log", 0, { -1
}, },
[SECTION_ID_LIBRARY_VERSIONS] = { SECTION_ID_LIBRARY_VERSIONS,
"library_versions", SECTION_FLAG_IS_ARRAY, { SECTION_ID_LIBRARY_VERSION, -1 } },
@@ -2199,6 +2201,16 @@ static void show_frame(WriterContext *w, AVFrame *frame,
AVStream *stream,
char tcbuf[AV_TIMECODE_STR_SIZE];
av_timecode_make_mpeg_tc_string(tcbuf, *(int64_t *)(sd->data));
print_str("timecode", tcbuf);
+} else if (sd->type == AV_FRAME_DATA_S12M_TIMECODE && sd->size >=
8) {
+uint32_t *tc = (uint32_t*)sd->data;
+int m = FFMIN(tc[0],3);
+for (int j = 1; j <= m ; j++) {
+char tcbuf[AV_TIMECODE_STR_SIZE];
+av_timecode_make_smpte_tc_string(tcbuf, tc[j], 0);
+writer_print_section_header(w,
SECTION_ID_FRAME_SIDE_DATA_TIMECODE);
+print_str("value", tcbuf);
+ writer_print_section_footer(w);
+}
} else if (sd->type == AV_FRAME_DATA_MASTERING_DISPLAY_METADATA) {
AVMasteringDisplayMetadata *metadata =
(AVMasteringDisplayMetadata *)sd->data;
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [FFMPEG DEVEL] [PATCH v4] fftools/ffprobe: Add S12M Timecode output as side data (such as SEI TC)
Hello sorry for the delay. Yes you're right. There is 3 timecodes data for one frame. One SEI data with 3 timecodes would represented by 3 side data. As far as I know there is only one timecode in the SEI data. In order to keep coherence with the schema (No simple element) , we could implement this: Would it be correct ? Le dim. 19 mai 2019 à 19:50, Marton Balint a écrit : > > > On Sun, 19 May 2019, Antonin Gouzer wrote: > > > --- > > Add the index of the timecode in case of multiple timecodes values > > Limit to 3 the number of timecodes > > remove break > > Am I reading this correctly, you'd get XML like > > id="1"/> > id="2"/> > id="3"/> > > right? The problem is that your output now looks as if the frame have 3 > instances of SMPTE 12-1 timecode side data. > > Maybe it's just me, but I'd prefer something like > > > 00:03:25:03 > 00:03:25:03 > 00:03:25:03 > > > What do you think? > > Thanks, > Marton > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCHv4] VP4 video decoder
On Tue, May 21, 2019 at 09:30:54PM +0200, Reimar Döffinger wrote: > > +#define SHIFT(v, shift) ((v) >> (shift)) > > +#define ABS_SHIFT(v, shift) ((v) > 0 ? SHIFT(v, shift) : -SHIFT(-v, shift)) > > Don't we have something like that already? Seems we don't > I think this should rather be: > (v - (v >> 31)) >> shift > ? Not right for shift > 1. But this one according to my testing is equivalent: ((a + (a >> 31)) >> b) - (a >> 31) Not certain it will be fewer instructions, but it is branchless. On some ISAs the simple a / (1 << b) might even be faster, so maybe worth going for that... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 06/11] cbs: Add support functions for handling unit content references
Mark Thompson:
> Use the unit type table to determine what we need to do to clone the
> internals of the unit content when making copies for refcounting or
> writeability. (This will still fail for units with complex content
> if they do not have a defined clone function.)
>
> Setup and naming from a patch by Andreas Rheinhardt
> , but with the implementation
> changed to use the unit type information if possible rather than
> requiring a codec-specific function.
> ---
> libavcodec/cbs.c | 168 ++
> libavcodec/cbs.h | 23 ++
> libavcodec/cbs_internal.h | 1 +
> 3 files changed, 192 insertions(+)
>
> diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
> index 1963d86133..9fc8e1eb47 100644
> --- a/libavcodec/cbs.c
> +++ b/libavcodec/cbs.c
> @@ -816,3 +816,171 @@ int ff_cbs_alloc_unit_content2(CodedBitstreamContext
> *ctx,
>
> return 0;
> }
> +
> +static int cbs_clone_unit_content(AVBufferRef **clone_ref,
> + CodedBitstreamUnit *unit,
> + const CodedBitstreamUnitTypeDescriptor
> *desc)
> +{
> +uint8_t *src, *copy;
> +void **src_ptr, **copy_ptr;
+ 1 to James' remark about the types.
> +AVBufferRef **src_buf, **copy_buf;
> +int err, i;
> +
> +av_assert0(unit->type == desc->unit_type);
> +av_assert0(unit->content);
> +src = unit->content;
> +
> +copy = av_malloc(desc->content_size);
> +if (!copy) {
> +err = AVERROR(ENOMEM);
> +goto fail;
You need to initialize i before going to fail; or even better, simply
return AVERROR(ENOMEM);
> +}
> +memcpy(copy, src, desc->content_size);
> +
> +for (i = 0; i < desc->nb_ref_offsets; i++) {
> +src_ptr = (void**)(src + desc->ref_offsets[i]);
> +src_buf = (AVBufferRef**)(src_ptr + 1);
> +copy_ptr = (void**)(copy + desc->ref_offsets[i]);
> +copy_buf = (AVBufferRef**)(copy_ptr + 1);
> +
> +if (!*src_ptr) {
> +av_assert0(!*src_buf);
> +continue;
> +}
> +if (!*src_buf) {
> +// We can't handle a non-refcounted pointer here - we don't
> +// have enough information to handle whatever structure lies
> +// at the other end of it.
> +err = AVERROR(EINVAL);
> +goto fail;
> +}
> +
> +// src_ptr is required to point somewhere inside src_buf. If it
> +// doesn't, there is a bug somewhere.
> +av_assert0((uint8_t*)*src_ptr >= (*src_buf)->data &&
> + (uint8_t*)*src_ptr < (*src_buf)->data +
> (*src_buf)->size);
> +
Just for completeness: Pointer comparisons on pointers that do not
point inside the same object (or one member past the end of an array)
is undefined behaviour, so the above is not a 100% kosher way to check
for whether src_ptr points inside src_buf. But it will probably work
anyway, so I don't mind.
> +*copy_buf = av_buffer_ref(*src_buf);
> +if (!*copy_buf) {
> +err = AVERROR(ENOMEM);
> +goto fail;
> +}
> +
> +err = av_buffer_make_writable(copy_buf);
> +if (err < 0) {
> +av_buffer_unref(copy_buf);
> +goto fail;
> +}
> +
> +*copy_ptr = (*copy_buf)->data +
> +((uint8_t*)*src_ptr - (*src_buf)->data);
> +}
> +
> +*clone_ref = av_buffer_create(copy, desc->content_size,
> + desc->content_free ? desc->content_free :
> + cbs_default_free_unit_content,
> + (void*)desc, 0);
> +if (!*clone_ref)
> +goto fail;
You forgot to set err to AVERROR(ENOMEM).
> +
> +return 0;
> +
> +fail:
> +for (--i; i >= 0; i--)
> +av_buffer_unref((AVBufferRef**)(copy + desc->ref_offsets[i]));
> +av_freep();
av_free(copy) is enough.
> +*clone_ref = NULL;
> +return err;
> +}
> +
> +int ff_cbs_make_unit_refcounted(CodedBitstreamContext *ctx,
> +CodedBitstreamUnit *unit)
> +{
> +const CodedBitstreamUnitTypeDescriptor *desc;
> +AVBufferRef *ref;
> +int err;
> +
> +if (unit->content_ref)
> +return 0;
> +
> +desc = cbs_find_unit_type_desc(ctx, unit);
> +if (!desc)
> +return AVERROR(ENOSYS);
> +
> +switch (desc->content_type) {
> +case CBS_CONTENT_TYPE_POD:
> +ref = av_buffer_alloc(desc->content_size);
> +if (!ref)
> +return AVERROR(ENOMEM);
> +memcpy(ref->data, unit->content, desc->content_size);
> +err = 0;
> +break;
> +
> +case CBS_CONTENT_TYPE_INTERNAL_REFS:
> +err = cbs_clone_unit_content(, unit, desc);
> +break;
> +
> +case CBS_CONTENT_TYPE_COMPLEX:
> +if (!desc->content_clone)
> +return AVERROR_PATCHWELCOME;
> +err = desc->content_clone(, unit);
> +break;
> +
> +default:
Re: [FFmpeg-devel] [PATCH] avcodec/decode: Do not output subtitle frames if the packet is marked with `AV_PKT_FLAG_DISCARD`.
Good question. The subtitle would be discarded if it overlaps an edit boundary. The root cause is the MOV demuxer currently marks boundary packets for discard. However, due to subtitle frames not being discarded (fixed by this patch), the root cause is hidden. A potential fix for the root cause would be to handle boundary packets by changing their timestamps to fit the edit boundary. (That would be a separate patch though.) > On May 22, 2019, at 10:30 AM, Derek Buitenhuis > wrote: > >> On 29/04/2019 23:45, fumoboy007 wrote: >> One situation where a subtitle packet can be marked for discard is when >> demuxing an MOV file that has an edit list. >> --- >> libavcodec/decode.c | 10 -- >> 1 file changed, 8 insertions(+), 2 deletions(-) > > Will this work properly if a given subtitle overlaps an edit boundary? > > - Derek > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 03/11] cbs: Describe allocate/free methods in tabular form
Mark Thompson:
> Unit types are split into three categories, depending on how their
> content is managed:
> * POD structure - these require no special treatment.
> * Structure containing references to refcounted buffers - these can use
> a common free function when the offsets of all the internal references
> are known.
> * More complex structures - these still require ad-hoc treatment.
>
> For each codec we can then maintain a table of descriptors for each unit
> type, defining the mechanism needed to allocate/free that unit content.
> This is not required to be used immediately - a new alloc function
> supports this, but does not replace the old one which works without
> referring to these tables.
> ---
> libavcodec/cbs.c | 62 +++
> libavcodec/cbs.h | 16 ++
> libavcodec/cbs_internal.h | 36 +++
> 3 files changed, 114 insertions(+)
>
> diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
> index 0260ba6f67..1963d86133 100644
> --- a/libavcodec/cbs.c
> +++ b/libavcodec/cbs.c
> @@ -754,3 +754,65 @@ int ff_cbs_delete_unit(CodedBitstreamContext *ctx,
>
> return 0;
> }
> +
> +static void cbs_default_free_unit_content(void *opaque, uint8_t *data)
> +{
> +const CodedBitstreamUnitTypeDescriptor *desc = opaque;
> +if (desc->content_type == CBS_CONTENT_TYPE_INTERNAL_REFS) {
> +int i;
> +for (i = 0; i < desc->nb_ref_offsets; i++) {
> +void **ptr = (void**)(data + desc->ref_offsets[i]);
> +av_buffer_unref((AVBufferRef**)(ptr + 1));
> +*ptr = NULL;
Why set *ptr to NULL? After all, the buffer that contains *ptr will be
freed anyway.
> +}
> +}
> +av_free(data);
> +}
> +
> +static const CodedBitstreamUnitTypeDescriptor
> +*cbs_find_unit_type_desc(CodedBitstreamContext *ctx,
> + CodedBitstreamUnit *unit)
> +{
> +const CodedBitstreamUnitTypeDescriptor *desc;
> +int i;
> +
> +if (!ctx->codec->unit_types)
> +return NULL;
> +
> +for (i = 0;; i++) {
> +desc = >codec->unit_types[i];
> +if (desc->unit_type == CBS_INVALID_UNIT_TYPE)
> +break;
> +if (desc->unit_type == unit->type)
> +return desc;
> +}
> +return NULL;
> +}
> +
> +int ff_cbs_alloc_unit_content2(CodedBitstreamContext *ctx,
> + CodedBitstreamUnit *unit)
> +{
> +const CodedBitstreamUnitTypeDescriptor *desc;
> +
> +av_assert0(!unit->content && !unit->content_ref);
> +
> +desc = cbs_find_unit_type_desc(ctx, unit);
> +if (!desc)
> +return AVERROR(ENOSYS);
> +
> +unit->content = av_mallocz(desc->content_size);
> +if (!unit->content)
> +return AVERROR(ENOMEM);
> +
> +unit->content_ref =
> +av_buffer_create(unit->content, desc->content_size,
> + desc->content_free ? desc->content_free
> +: cbs_default_free_unit_content,
> + (void*)desc, 0);
> +if (!unit->content_ref) {
> +av_freep(>content);
> +return AVERROR(ENOMEM);
> +}
> +
> +return 0;
> +}
> diff --git a/libavcodec/cbs.h b/libavcodec/cbs.h
> index e8b2d41ecb..8f764905bd 100644
> --- a/libavcodec/cbs.h
> +++ b/libavcodec/cbs.h
> @@ -54,6 +54,13 @@ struct CodedBitstreamType;
> */
> typedef uint32_t CodedBitstreamUnitType;
>
> +/**
> + * Value which is never valid as a unit type.
> + *
> + * This can be used as a sentinel.
> + */
> +#define CBS_INVALID_UNIT_TYPE (UINT32_MAX)
> +
> /**
> * Coded bitstream unit structure.
> *
> @@ -337,6 +344,15 @@ int ff_cbs_alloc_unit_content(CodedBitstreamContext *ctx,
>size_t size,
>void (*free)(void *unit, uint8_t *content));
>
> +/**
> + * Allocate a new internal content buffer matching the type of the unit.
> + *
> + * The content will be zeroed.
> + */
> +int ff_cbs_alloc_unit_content2(CodedBitstreamContext *ctx,
> + CodedBitstreamUnit *unit);
> +
> +
> /**
> * Allocate a new internal data buffer of the given size in the unit.
> *
> diff --git a/libavcodec/cbs_internal.h b/libavcodec/cbs_internal.h
> index dd4babf092..06a8f9b979 100644
> --- a/libavcodec/cbs_internal.h
> +++ b/libavcodec/cbs_internal.h
> @@ -25,11 +25,47 @@
> #include "put_bits.h"
>
>
> +enum {
> +// Unit content is a simple structure.
> +CBS_CONTENT_TYPE_POD,
> +// Unit content contains some references to other structures, but all
> +// managed via buffer reference counting. The descriptor defines the
> +// structure offsets of every buffer reference.
> +CBS_CONTENT_TYPE_INTERNAL_REFS,
> +// Unit content is something more complex. The descriptor defines
> +// special functions to manage the content.
> +CBS_CONTENT_TYPE_COMPLEX,
> +};
> +
> +// Maximum number of reference buffer offsets
Re: [FFmpeg-devel] [PATCH] avcodec/decode: Do not output subtitle frames if the packet is marked with `AV_PKT_FLAG_DISCARD`.
On 29/04/2019 23:45, fumoboy007 wrote: > One situation where a subtitle packet can be marked for discard is when > demuxing an MOV file that has an edit list. > --- > libavcodec/decode.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) Will this work properly if a given subtitle overlaps an edit boundary? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/decode: Do not output subtitle frames if the packet is marked with `AV_PKT_FLAG_DISCARD`.
Bump.
> On Apr 29, 2019, at 3:45 PM, fumoboy007 wrote:
>
> One situation where a subtitle packet can be marked for discard is when
> demuxing an MOV file that has an edit list.
> ---
> libavcodec/decode.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 6c31166ec2..204bd50fa3 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1149,8 +1149,14 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx,
> AVSubtitle *sub,
> }
> }
>
> -if (*got_sub_ptr)
> -avctx->frame_number++;
> +if (*got_sub_ptr) {
> +if (avpkt->flags & AV_PKT_FLAG_DISCARD) {
> +*got_sub_ptr = 0;
> +avsubtitle_free(sub);
> +} else {
> +avctx->frame_number++;
> +}
> +}
> }
>
> return ret;
> --
> 2.21.0
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v5] Fix integer parameters size check in SDP fmtp line
=== PROBLEM ===
I was trying to record h264 + aac streams from an RTSP server to mp4 file.
using this command line:
ffmpeg -v verbose -y -i "rtsp:///my_resources" -codec copy -bsf:a
aac_adtstoasc test.mp4
FFmpeg then fail to record audio and output this logs:
[rtsp @ 0xcda1f0] The profile-level-id field size is invalid (40)
[rtsp @ 0xcda1f0] Error parsing AU headers
...
[rtsp @ 0xcda1f0] Could not find codec parameters for stream 1 (Audio: aac,
48000 Hz, 1 channels): unspecified sample format
In SDP provided by my RTSP server I had this fmtp line:
a=fmtp:98 streamType=5; profile-level-id=40; mode=AAC-hbr; config=1188;
sizeLength=13; indexLength=3; indexDeltaLength=3;
In FFmpeg code, I found a check introduced by commit
24130234cd9dd733116d17b724ea4c8e12ce097a. It disallows values greater than 32
for fmtp line parameters.
However, In RFC-6416 (RTP Payload Format for MPEG-4 Audio/Visual Streams) give
examples of "profile-level-id" values for AAC, up to 55.
Furthermore, RFC-4566 (SDP: Session Description Protocol) do not give any limit
of size on interger parameters given in fmtp line.
=== FIX ===
Instead of prohibit values over 32, I propose to check the possible integer
overflow.
The use of strtol allow to check the string validity and the possible overflow.
To store and check return of strtol I use "long int" type and LONG_MIN/MAX
definitions despite differences on 32/64bits platforms.
It is consistent with the strtol man page, and it is the only way to check if
overflow or underflow is detected by strtol.
As the value is later checked against INT32_MIN and INT32_MAX, the behavior
will finnaly be the same on both type of platform.
This patch fix my problem and I now can record my RTSP AAC stream to mp4.
It has passed the full fate tests suite sucessfully.
Signed-off-by: Olivier Maignial
---
Changes V4 -> V5:
- Check value against INT32_MAX/MIN instead of INT_MAX/MIN which can be
defferent depending on platform
libavformat/rtpdec_mpeg4.c | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/libavformat/rtpdec_mpeg4.c b/libavformat/rtpdec_mpeg4.c
index 4f70599..cf35afb 100644
--- a/libavformat/rtpdec_mpeg4.c
+++ b/libavformat/rtpdec_mpeg4.c
@@ -289,15 +289,33 @@ static int parse_fmtp(AVFormatContext *s,
for (i = 0; attr_names[i].str; ++i) {
if (!av_strcasecmp(attr, attr_names[i].str)) {
if (attr_names[i].type == ATTR_NAME_TYPE_INT) {
-int val = atoi(value);
-if (val > 32) {
+char *end_ptr = NULL;
+errno = 0;
+long int val = strtol(value, _ptr, 10);
+if (value[0] == '\n' || end_ptr[0] != '\0') {
av_log(s, AV_LOG_ERROR,
- "The %s field size is invalid (%d)\n",
- attr, val);
+ "The %s field value is not a number (%s)\n",
+ attr, value);
return AVERROR_INVALIDDATA;
}
+if ((val == LONG_MAX && errno == ERANGE) ||
+val > INT32_MAX) {
+av_log(s, AV_LOG_ERROR,
+ "Value of field %s overflows maximum integer
value.\n",
+ attr);
+return AVERROR_INVALIDDATA;
+}
+if ((val == LONG_MIN && errno == ERANGE) ||
+val < INT32_MIN)
+{
+av_log(s, AV_LOG_ERROR,
+ "Value of field %s underflows minimum integer
value.\n",
+ attr);
+return AVERROR_INVALIDDATA;
+}
+
*(int *)((char *)data+
-attr_names[i].offset) = val;
+attr_names[i].offset) = (int) val;
} else if (attr_names[i].type == ATTR_NAME_TYPE_STR) {
char *val = av_strdup(value);
if (!val)
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/cache - delete cache file after closing handle
On 22-05-2019 06:37 PM, Nicolas George wrote:
Gyan (12019-05-22):
The existing practice of unlinking path immediately after acquiring file
handle was returning (unchecked) EPERM error on Windows. Switched to
deletion after closing handle.
Confirmed that cache protocol temp files are deleted in Windows 7 when
ffmpeg exits.
The cache protocol calls avutil/avpriv_tempfile(), which in turn, calls
mkstemp (for me), so I don't see the provision to append O_TEMPORARY as a
flag while opening. mkstemp only applies
_O_RDWR | _O_CREAT | _O_EXCL | _O_BINARY
Should be tested in other environments. If it works, supersedes
https://patchwork.ffmpeg.org/patch/13242/
Thanks,
Gyan
From f1f17020dd96205a60195e310d8c3b53126c2e00 Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Wed, 22 May 2019 18:05:04 +0530
Subject: [PATCH] avformat/cache - delete cache file after closing handle
Ensures cache file deletion on Windows, when compiled under MinGW.
---
libavformat/cache.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavformat/cache.c b/libavformat/cache.c
index 66bbbf54c9..1db13ceefc 100644
--- a/libavformat/cache.c
+++ b/libavformat/cache.c
@@ -54,6 +54,7 @@ typedef struct CacheEntry {
typedef struct Context {
AVClass *class;
int fd;
+char *filename;
struct AVTreeNode *root;
int64_t logical_pos;
int64_t cache_pos;
@@ -83,7 +84,7 @@ static int cache_open(URLContext *h, const char *arg, int
flags, AVDictionary **
return c->fd;
}
-unlink(buffername);
On systems that allow deleting the file when it is still in use deleting
it immediately is a better idea: it reduces the risk of leaving it if
the application is interrupted prematurely.
+c->filename = av_strdup(buffername);
Missing error check.
av_freep();
return ffurl_open_whitelist(>inner, arg, flags, >interrupt_callback,
@@ -292,11 +293,15 @@ static int enu_free(void *opaque, void *elem)
static int cache_close(URLContext *h)
{
Context *c= h->priv_data;
+int ret;
av_log(h, AV_LOG_INFO, "Statistics, cache hits:%"PRId64" cache misses:%"PRId64"\n",
c->cache_hit, c->cache_miss);
close(c->fd);
+ret = avpriv_io_delete(c->filename);
+if (ret < 0)
+av_log(h, AV_LOG_ERROR, "Could not delete %s. Error is %s\n",
c->filename, av_err2str(ret));
ffurl_close(c->inner);
av_tree_enumerate(c->root, NULL, NULL, enu_free);
av_tree_destroy(c->root);
Revised patch.
Gyan
From 54b24428fcf6b513574f5c1b626ebb505b123d77 Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Wed, 22 May 2019 18:05:04 +0530
Subject: [PATCH v2] avformat/cache - delete cache file after closing handle
Ensures cache file deletion on Windows, when compiled under MinGW.
---
libavformat/cache.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/libavformat/cache.c b/libavformat/cache.c
index 66bbbf54c9..ee1b868157 100644
--- a/libavformat/cache.c
+++ b/libavformat/cache.c
@@ -54,6 +54,7 @@ typedef struct CacheEntry {
typedef struct Context {
AVClass *class;
int fd;
+char *filename;
struct AVTreeNode *root;
int64_t logical_pos;
int64_t cache_pos;
@@ -72,6 +73,7 @@ static int cmp(const void *key, const void *node)
static int cache_open(URLContext *h, const char *arg, int flags, AVDictionary
**options)
{
+int ret;
char *buffername;
Context *c= h->priv_data;
@@ -83,7 +85,18 @@ static int cache_open(URLContext *h, const char *arg, int
flags, AVDictionary **
return c->fd;
}
-unlink(buffername);
+ret = avpriv_io_delete(buffername);
+
+if (ret < 0) {
+c->filename = av_strdup(buffername);
+if (!c->filename) {
+close(c->fd);
+avpriv_io_delete(buffername);
+av_freep();
+return AVERROR(ENOMEM);
+}
+}
+
av_freep();
return ffurl_open_whitelist(>inner, arg, flags, >interrupt_callback,
@@ -292,11 +305,17 @@ static int enu_free(void *opaque, void *elem)
static int cache_close(URLContext *h)
{
Context *c= h->priv_data;
+int ret;
av_log(h, AV_LOG_INFO, "Statistics, cache hits:%"PRId64" cache
misses:%"PRId64"\n",
c->cache_hit, c->cache_miss);
close(c->fd);
+if (c->filename) {
+ret = avpriv_io_delete(c->filename);
+if (ret < 0)
+av_log(h, AV_LOG_ERROR, "Could not delete %s.\n", c->filename);
+}
ffurl_close(c->inner);
av_tree_enumerate(c->root, NULL, NULL, enu_free);
av_tree_destroy(c->root);
--
2.21.0___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavformat/mpegtsenc: adaptive alignment for teletext PES packets
Hi,
Patch to generate aligned Teletext PES packets using the MPEG-TS muxer
when the TS header contains data.
Regards.
A.H.
---From 5b476153e0fcced53afa1b77543c2e386f08c504 Mon Sep 17 00:00:00 2001
From: Andreas Hakon
Date: Wed, 22 May 2019 15:36:50 +0100
Subject: [PATCH] libavformat/mpegtsenc: adaptive alignment for teletext PES
packets
The code that generates the PES packets for Teletext data aligns the PES packets
with the boundaries of the TS packets. The strategy used is to insert padding
stuff into the PES header. The size of this padding alignment currently has a
fixed size of 36 bytes. And this value is correct when all of the Teletext
TS packets have payload only. However, inserting some data into the TS header
breaks this assumption. In this case, the Teletext PES packets are not aligned
and the end of the PES packet is inserted into an additional TS packet with a
large amount of TS padding.
This patch calculates the size of the TS header in order to reduce the size of
the PES padding and thus accommodate the PES packet to the TS boundaries.
In this way no additional TS packets are produced.
Signed-off-by: Andreas Hakon
libavformat/mpegtsenc.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index fc0ea22..f1772ac 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -1328,8 +1328,11 @@ static void mpegts_write_pes(AVFormatContext *s,
AVStream *st,
header_len += 3;
}
if (is_dvb_teletext) {
-pes_header_stuffing_bytes = 0x24 - header_len;
-header_len = 0x24;
+int header_stuff = (get_ts_payload_start(buf) - buf) - 4;
+if (header_stuff - header_len > 0x24)
+header_stuff = 0;
+pes_header_stuffing_bytes = 0x24 - header_len - header_stuff;
+header_len = 0x24 - header_stuff;
}
len = payload_size + header_len + 3;
/* 3 extra bytes should be added to DVB subtitle payload: 0x20
0x00 at the beginning and trailing 0xff */
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH, v2] lavc/qsvenc: Fix the memory leak for enc_ctrl.Payload
> From: Fu, Linjie > Sent: Wednesday, May 22, 2019 1:50 PM > To: Li, Zhong ; FFmpeg development discussions and > patches > Subject: RE: [FFmpeg-devel] [PATCH, v2] lavc/qsvenc: Fix the memory leak > for enc_ctrl.Payload > > > -Original Message- > > From: Li, Zhong > > Sent: Monday, April 29, 2019 17:00 > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Cc: Fu, Linjie > > Subject: RE: [FFmpeg-devel] [PATCH, v2] lavc/qsvenc: Fix the memory > > leak for enc_ctrl.Payload > > > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > > Behalf > > > Of Linjie Fu > > > Sent: Monday, April 15, 2019 9:23 PM > > > To: ffmpeg-devel@ffmpeg.org > > > Cc: Fu, Linjie > > > Subject: [FFmpeg-devel] [PATCH, v2] lavc/qsvenc: Fix the memory leak > > > for enc_ctrl.Payload > > > > > > frame->enc_ctrl.Payload is malloced in get_free_frame, directly > > > frame->memset > > > the whole structure of enc_ctrl to zero will cause the memory leak > > > for enc_ctrl.Payload. > > > > > > frame->enc_ctrl as a structure will be malloc and init to zero by > > > frame->calling > > > frame = av_mallocz(sizeof(*frame)), so the memset is redundant and > > > can > > be > > > removed. > > > > > > Can be reproduced by #7830. > > > > Patch LGTM now, but I can't see strong relationship between this patch > > and tikect #7830. > > IMHO this is a quite common issue even if you use qsv transcoding > pipeline? > > Yes, it's not strongly related with the issue. Remove this would be fine. > Thanks. Applied with commit message modified. Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/nvenc: add master display and light level sei for HDR10
On 22.05.2019 08:59, lance.lmw...@gmail.com wrote: From: Limin Wang The testing command for the HDR10 output with nvenc: $ ./ffmpeg_g -y -i 4K.mp4 -c:v hevc_nvenc -g 7 -color_primaries bt2020 -colorspace bt2020_ncl -color_trc smpte2084 -sei hdr10 \ -master_display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(1000,50)" -max_cll "0, 0" test.ts Please notice it is preferable to use the frame sei side data than master_display and max_cll paramters config --- libavcodec/nvenc.c | 129 libavcodec/nvenc.h | 18 ++ libavcodec/nvenc_hevc.c | 11 3 files changed, 158 insertions(+) diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c index 75dda6d689..3fd0eca4a5 100644 --- a/libavcodec/nvenc.c +++ b/libavcodec/nvenc.c @@ -22,6 +22,9 @@ #include "config.h" #include "nvenc.h" +#include "cbs_h265.h" +#include "hevc_sei.h" +#include "put_bits.h" #include "libavutil/hwcontext_cuda.h" #include "libavutil/hwcontext.h" @@ -30,6 +33,7 @@ #include "libavutil/avassert.h" #include "libavutil/mem.h" #include "libavutil/pixdesc.h" +#include "libavutil/mastering_display_metadata.h" #include "internal.h" #define CHECK_CU(x) FF_CUDA_CHECK_DL(avctx, dl_fn->cuda_dl, x) @@ -1491,6 +1495,46 @@ av_cold int ff_nvenc_encode_init(AVCodecContext *avctx) ctx->data_pix_fmt = avctx->pix_fmt; } +ctx->display_primaries_x[0] = 13250; +ctx->display_primaries_y[0] = 34500; +ctx->display_primaries_x[1] = 7500; +ctx->display_primaries_y[1] = 3000; +ctx->display_primaries_x[2] = 34000; +ctx->display_primaries_y[2] = 16000; +ctx->white_point_x = 15635; +ctx->white_point_y = 16450; +ctx->max_display_mastering_luminance = 1000; +ctx->min_display_mastering_luminance = 500; +ctx->max_content_light_level = 0; +ctx->max_pic_average_light_level = 0; Does all this really belong into an encoder? The command line parameter also looks very arcane. To me, this looks more like a filter or something should add this as extra data, and then multiple encoders can pick it up from there. Same goes for patch 3/3. Patch 1/3 is looks OK to me. Timo smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4] Fix integer parameters size check in SDP fmtp line
On Wed, May 22, 2019 at 12:03:55 +0200, Olivier Maignial wrote: > In SDP provided by my RTSP server I had this fmtp line: > a=fmtp:98 streamType=5; profile-level-id=40; mode=AAC-hbr; config=1188; > sizeLength=13; indexLength=3; indexDeltaLength=3; > > In FFmpeg code, I found a check introduced by commit > 24130234cd9dd733116d17b724ea4c8e12ce097a. It disallow values greater than 32 > for fmtp line parameters. > However, In RFC-6416 (RTP Payload Format for MPEG-4 Audio/Visual Streams) > give examples of "profile-level-id" values for AAC, up to 55. > Furthermore, RFC-4566 (SDP: Session Description Protocol) do not give any > limit of size on interger parameters given in fmtp line. This explanation is much more concise than before. Thanks. Thus, understanding the intent, I can now finally comment on the code: > Using INT_MIN, LONG_MIN, INT_MAX and LON_MAX definitions ensure that it will > work whatever the size of int/long given by compiler. [...] > +long int val = strtol(value, _ptr, 10); According to your comment, you do realize that this depends on the compiler. I actually believe it depends mainly on the platform, but that's an academic discussion. Either way, why not support the same range regardless of compiler or platform? I.e. avoid "long int", which is sometimes 32 bits, sometimes 64. (Anything else could lead to unexpected behavior. In other words, an observation such as: "That's peculiar, my [64 bit] PC handles this stream just fine, but my [32 bit] RaspPi doesn't.") > + "Value of field %s overflow maximum integer > value.\n", Singular: "underflows". > + "Value of field %s underflow minimum integer > value.\n", Ditto. Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Help: Get motion vector value from previous and next frame FFMPEG
On Wed, May 22, 2019 at 16:06:39 +0300, Boris wrote: > Apologize me if this mailing list is not for such questions. > I want help, then I think that here is the best place. No, this is exactly the wrong place. ffmpeg-devel is for discussing the development *of* the ffmpeg tools and libraries. For discussing the use of the libraries, please turn to the list libav-user: https://ffmpeg.org/mailing-list-faq.html#What-type-of-questions-can-I-ask_003f Cheers, Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavfilter/dnn_native: Add support of dilated convolution in dnn_native.
Add dilation parameter in dnn native to support dilated convolution.
Signed-off-by: Xuewei Meng
---
libavfilter/dnn_backend_native.c | 17 +
libavfilter/dnn_backend_native.h | 1 +
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/libavfilter/dnn_backend_native.c b/libavfilter/dnn_backend_native.c
index 3c8465a283..82e900bd8c 100644
--- a/libavfilter/dnn_backend_native.c
+++ b/libavfilter/dnn_backend_native.c
@@ -63,7 +63,7 @@ static DNNReturnType set_input_output_native(void *model,
DNNInputData *input, c
cur_channels = conv_params->output_num;
if (conv_params->padding_method == VALID) {
-int pad_size = conv_params->kernel_size - 1;
+int pad_size = (conv_params->kernel_size - 1) *
conv_params->dilation;
cur_height -= pad_size;
cur_width -= pad_size;
}
@@ -164,6 +164,7 @@ DNNModel *ff_dnn_load_model_native(const char
*model_filename)
ff_dnn_free_model_native();
return NULL;
}
+conv_params->dilation = (int32_t)avio_rl32(model_file_context);
conv_params->padding_method =
(int32_t)avio_rl32(model_file_context);
conv_params->activation = (int32_t)avio_rl32(model_file_context);
conv_params->input_num = (int32_t)avio_rl32(model_file_context);
@@ -171,7 +172,7 @@ DNNModel *ff_dnn_load_model_native(const char
*model_filename)
conv_params->kernel_size = (int32_t)avio_rl32(model_file_context);
kernel_size = conv_params->input_num * conv_params->output_num *
conv_params->kernel_size * conv_params->kernel_size;
-dnn_size += 20 + (kernel_size + conv_params->output_num << 2);
+dnn_size += 24 + (kernel_size + conv_params->output_num << 2);
if (dnn_size > file_size || conv_params->input_num <= 0 ||
conv_params->output_num <= 0 || conv_params->kernel_size <= 0){
avio_closep(_file_context);
@@ -233,7 +234,7 @@ static void convolve(const float *input, float *output,
const ConvolutionalParam
int src_linesize = width * conv_params->input_num;
int filter_linesize = conv_params->kernel_size * conv_params->input_num;
int filter_size = conv_params->kernel_size * filter_linesize;
-int pad_size = (conv_params->padding_method == VALID) ?
(conv_params->kernel_size - 1) / 2 : 0;
+int pad_size = (conv_params->padding_method == VALID) ?
(conv_params->kernel_size - 1) / 2 * conv_params->dilation : 0;
for (int y = pad_size; y < height - pad_size; ++y) {
for (int x = pad_size; x < width - pad_size; ++x) {
@@ -245,12 +246,12 @@ static void convolve(const float *input, float *output,
const ConvolutionalParam
for (int kernel_x = 0; kernel_x <
conv_params->kernel_size; ++kernel_x) {
float input_pel;
if (conv_params->padding_method ==
SAME_CLAMP_TO_EDGE) {
-int y_pos = CLAMP_TO_EDGE(y + kernel_y -
radius, height);
-int x_pos = CLAMP_TO_EDGE(x + kernel_x -
radius, width);
+int y_pos = CLAMP_TO_EDGE(y + (kernel_y -
radius) * conv_params->dilation, height);
+int x_pos = CLAMP_TO_EDGE(x + (kernel_x -
radius) * conv_params->dilation, width);
input_pel = input[y_pos * src_linesize + x_pos
* conv_params->input_num + ch];
} else {
-int y_pos = y + kernel_y - radius;
-int x_pos = x + kernel_x - radius;
+int y_pos = y + (kernel_y - radius) *
conv_params->dilation;
+int x_pos = x + (kernel_x - radius) *
conv_params->dilation;
input_pel = (x_pos < 0 || x_pos >= width ||
y_pos < 0 || y_pos >= height) ? 0.0 :
input[y_pos * src_linesize
+ x_pos * conv_params->input_num + ch];
}
@@ -334,7 +335,7 @@ DNNReturnType ff_dnn_execute_model_native(const DNNModel
*model, DNNData *output
convolve(network->layers[layer - 1].output,
network->layers[layer].output, conv_params, cur_width, cur_height);
cur_channels = conv_params->output_num;
if (conv_params->padding_method == VALID) {
-int pad_size = conv_params->kernel_size - 1;
+int pad_size = (conv_params->kernel_size - 1) *
conv_params->dilation;
cur_height -= pad_size;
cur_width -= pad_size;
}
diff --git a/libavfilter/dnn_backend_native.h b/libavfilter/dnn_backend_native.h
index 7e4e943137..5917955733 100644
--- a/libavfilter/dnn_backend_native.h
+++
[FFmpeg-devel] Help: Get motion vector value from previous and next frame FFMPEG
Apologize me if this mailing list is not for such questions. I want help, then I think that here is the best place. Can you tells me how can I do to get motion vectors values (mvx, mvy) from previous and next Frame during transcoding with MPegEncContext structure, please? For current Frame, s->p_mv_table gives me this values. But I don't know how can I do for next and previous frame in encoding order. Regards ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/cache - delete cache file after closing handle
Gyan (12019-05-22):
>
> The existing practice of unlinking path immediately after acquiring file
> handle was returning (unchecked) EPERM error on Windows. Switched to
> deletion after closing handle.
> Confirmed that cache protocol temp files are deleted in Windows 7 when
> ffmpeg exits.
>
> The cache protocol calls avutil/avpriv_tempfile(), which in turn, calls
> mkstemp (for me), so I don't see the provision to append O_TEMPORARY as a
> flag while opening. mkstemp only applies
> _O_RDWR | _O_CREAT | _O_EXCL | _O_BINARY
>
> Should be tested in other environments. If it works, supersedes
> https://patchwork.ffmpeg.org/patch/13242/
>
> Thanks,
> Gyan
> From f1f17020dd96205a60195e310d8c3b53126c2e00 Mon Sep 17 00:00:00 2001
> From: Gyan Doshi
> Date: Wed, 22 May 2019 18:05:04 +0530
> Subject: [PATCH] avformat/cache - delete cache file after closing handle
>
> Ensures cache file deletion on Windows, when compiled under MinGW.
> ---
> libavformat/cache.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/cache.c b/libavformat/cache.c
> index 66bbbf54c9..1db13ceefc 100644
> --- a/libavformat/cache.c
> +++ b/libavformat/cache.c
> @@ -54,6 +54,7 @@ typedef struct CacheEntry {
> typedef struct Context {
> AVClass *class;
> int fd;
> +char *filename;
> struct AVTreeNode *root;
> int64_t logical_pos;
> int64_t cache_pos;
> @@ -83,7 +84,7 @@ static int cache_open(URLContext *h, const char *arg, int
> flags, AVDictionary **
> return c->fd;
> }
>
> -unlink(buffername);
On systems that allow deleting the file when it is still in use deleting
it immediately is a better idea: it reduces the risk of leaving it if
the application is interrupted prematurely.
> +c->filename = av_strdup(buffername);
Missing error check.
> av_freep();
>
> return ffurl_open_whitelist(>inner, arg, flags,
> >interrupt_callback,
> @@ -292,11 +293,15 @@ static int enu_free(void *opaque, void *elem)
> static int cache_close(URLContext *h)
> {
> Context *c= h->priv_data;
> +int ret;
>
> av_log(h, AV_LOG_INFO, "Statistics, cache hits:%"PRId64" cache
> misses:%"PRId64"\n",
> c->cache_hit, c->cache_miss);
>
> close(c->fd);
> +ret = avpriv_io_delete(c->filename);
> +if (ret < 0)
> +av_log(h, AV_LOG_ERROR, "Could not delete %s. Error is %s\n",
> c->filename, av_err2str(ret));
> ffurl_close(c->inner);
> av_tree_enumerate(c->root, NULL, NULL, enu_free);
> av_tree_destroy(c->root);
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/cache - delete cache file after closing handle
The existing practice of unlinking path immediately after acquiring file
handle was returning (unchecked) EPERM error on Windows. Switched to
deletion after closing handle.
Confirmed that cache protocol temp files are deleted in Windows 7 when
ffmpeg exits.
The cache protocol calls avutil/avpriv_tempfile(), which in turn, calls
mkstemp (for me), so I don't see the provision to append O_TEMPORARY as
a flag while opening. mkstemp only applies
_O_RDWR | _O_CREAT | _O_EXCL | _O_BINARY
Should be tested in other environments. If it works, supersedes
https://patchwork.ffmpeg.org/patch/13242/
Thanks,
Gyan
From f1f17020dd96205a60195e310d8c3b53126c2e00 Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Wed, 22 May 2019 18:05:04 +0530
Subject: [PATCH] avformat/cache - delete cache file after closing handle
Ensures cache file deletion on Windows, when compiled under MinGW.
---
libavformat/cache.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavformat/cache.c b/libavformat/cache.c
index 66bbbf54c9..1db13ceefc 100644
--- a/libavformat/cache.c
+++ b/libavformat/cache.c
@@ -54,6 +54,7 @@ typedef struct CacheEntry {
typedef struct Context {
AVClass *class;
int fd;
+char *filename;
struct AVTreeNode *root;
int64_t logical_pos;
int64_t cache_pos;
@@ -83,7 +84,7 @@ static int cache_open(URLContext *h, const char *arg, int
flags, AVDictionary **
return c->fd;
}
-unlink(buffername);
+c->filename = av_strdup(buffername);
av_freep();
return ffurl_open_whitelist(>inner, arg, flags, >interrupt_callback,
@@ -292,11 +293,15 @@ static int enu_free(void *opaque, void *elem)
static int cache_close(URLContext *h)
{
Context *c= h->priv_data;
+int ret;
av_log(h, AV_LOG_INFO, "Statistics, cache hits:%"PRId64" cache
misses:%"PRId64"\n",
c->cache_hit, c->cache_miss);
close(c->fd);
+ret = avpriv_io_delete(c->filename);
+if (ret < 0)
+av_log(h, AV_LOG_ERROR, "Could not delete %s. Error is %s\n",
c->filename, av_err2str(ret));
ffurl_close(c->inner);
av_tree_enumerate(c->root, NULL, NULL, enu_free);
av_tree_destroy(c->root);
--
2.21.0___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/file_open: log temp filename
On 22-05-2019 06:02 PM, Hendrik Leppkes wrote: On Wed, May 22, 2019 at 12:14 PM Gyan wrote: On 22-05-2019 03:29 PM, Hendrik Leppkes wrote: On Wed, May 22, 2019 at 11:51 AM Gyan wrote: On 22-05-2019 02:29 PM, Hendrik Leppkes wrote: On Wed, May 22, 2019 at 10:53 AM Gyan wrote: On 22-05-2019 01:41 PM, Liu Steven wrote: 在 2019年5月22日，下午3:10，Gyan 写道： Helps users to identify temp files for a given instance. In the longer term, we should aim to clean up all temp files. Gyan <0001-avutil-file_open-log-temp-filename.patch>___ Why don’t use AV_LOG_DEBUG or AV_LOG_TRACE? DEBUG and TRACE are meant to record micro-ops for debugging purposes. This message will be present a handful of times in the log and is essential for end-users so they can delete these files, which ffmpeg won't do, but should since these are meant to be temporary files. Why don't we work on fixing this instead, as users will not know what implications this message has in any case and just consider it spam. 1) A grep of the tree shows only two components make use of this function. The cache protocol, which needs to be expressly invoked by the user, and the xvid encoder in 2-pass mode, which also has to be expressly invoked. No unsuspecting user will be presented with this message. 2) Fixing this is the ideal solution. The above two components already unlink the file after use, but with cache:, the file remains available after ffmpeg has exited. So this has to be looked at by someone acquainted and able to test with all the environments that ffmpeg can be run on. I don't have that knowledge or access. Till then, let's not the perfect be the enemy of the good. This message has absolutely zero indication that the user might need to act on it, nevermind that API users might never see it in the first place, as such I don't see how this is even "good". Why don't you start with collecting information which systems are even affected by this? You must have some systems where you saw this. This patch was prompted by a Windows user who wanted this info. As mentioned above, I can reproduce it with cache protocol on Windows. Don't have access to other systems, except one linux box. I just saw that we do have a file delete function. Will first see if that works. I know that it doesn't work on Windows, because you have to specifically request that a file can be marked for deletion while its still open, which we do not do. I'm working on a patch to see if we can fix this. I've fixed it locally for the cache protocol. Sending it soon. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/file_open: log temp filename
On Wed, May 22, 2019 at 12:14 PM Gyan wrote: > > > > On 22-05-2019 03:29 PM, Hendrik Leppkes wrote: > > On Wed, May 22, 2019 at 11:51 AM Gyan wrote: > >> > >> > >> On 22-05-2019 02:29 PM, Hendrik Leppkes wrote: > >>> On Wed, May 22, 2019 at 10:53 AM Gyan wrote: > > On 22-05-2019 01:41 PM, Liu Steven wrote: > >> 在 2019年5月22日，下午3:10，Gyan 写道： > >> > >> > >> Helps users to identify temp files for a given instance. > >> > >> In the longer term, we should aim to clean up all temp files. > >> > >> Gyan > >> <0001-avutil-file_open-log-temp-filename.patch>___ > > Why don’t use AV_LOG_DEBUG or AV_LOG_TRACE? > > > DEBUG and TRACE are meant to record micro-ops for debugging purposes. > This message will be present a handful of times in the log and is > essential for end-users so they can delete these files, which ffmpeg > won't do, but should since these are meant to be temporary files. > > >>> Why don't we work on fixing this instead, as users will not know what > >>> implications this message has in any case and just consider it spam. > >> 1) A grep of the tree shows only two components make use of this > >> function. The cache protocol, which needs to be expressly invoked by the > >> user, and the xvid encoder in 2-pass mode, which also has to be > >> expressly invoked. No unsuspecting user will be presented with this > >> message. > >> > >> 2) Fixing this is the ideal solution. The above two components already > >> unlink the file after use, but with cache:, the file remains available > >> after ffmpeg has exited. So this has to be looked at by someone > >> acquainted and able to test with all the environments that ffmpeg can be > >> run on. I don't have that knowledge or access. Till then, let's not the > >> perfect be the enemy of the good. > >> > > This message has absolutely zero indication that the user might need > > to act on it, nevermind that API users might never see it in the first > > place, as such I don't see how this is even "good". > > > > Why don't you start with collecting information which systems are even > > affected by this? You must have some systems where you saw this. > This patch was prompted by a Windows user who wanted this info. As > mentioned above, I can reproduce it with cache protocol on Windows. > Don't have access to other systems, except one linux box. > > I just saw that we do have a file delete function. Will first see if > that works. > I know that it doesn't work on Windows, because you have to specifically request that a file can be marked for deletion while its still open, which we do not do. I'm working on a patch to see if we can fix this. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/videotoolboxenc: Fix compilation for IOS < 11.0 and OSX, < 10.13
Am 22.05.19 um 01:41 schrieb Jan Ekström: > Hi, > > On Tue, May 14, 2019 at 4:16 PM Thilo Borgmann wrote: >> >> $Subject >> >> Tested compilation only, sanity test actually using it appreciated. >> > > Thanks for the patch. To be completely fair, this is not to fix > compilation for specific target systems, but rather to fix compilation > on older SDKs (building with newer SDKs you can still build aiming for > macOS starting from 10.9, for example). > > I didn't notice a patch landed on the encoder side that utilized the > defines without further checking/ifdefs. Too bad. I think I > specifically didn't yet merge the full/limited range patch on the > decoder side due to related reasons. > > I did notice that VLC just re-defined these enum values themselves to > stop needing to have ifdefs depending on which SDK is being utilized > (https://github.com/videolan/vlc/commit/1b7e1c4bfcda375e2d4e657135aeaf3732e44af2#diff-a11cdb805d111956af60619d7dfa022bR735). > I wonder if we should have a helper header that would re-define these > enum values with their name. That way the code would look correct, and > the resulting binary has the same features independent of the SDK it > had been built under. > > What would be the opinion of people on a solution like this? Tested with a local definition of the symbols (like a would be header would do). Seems to work for building with -macosx-version-min=XXX. Also checked with VLC, they do these checks via thinks like: #ifndef MAC_OS_X_VERSION_10_13 ... #endif Wich might be a better alternative to what I suggested. Thus I would be fine with a helping header. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavcodec/vp9: fix ref-frame size judging method
Hi, On Wed, May 22, 2019 at 2:12 AM Yan, CenX wrote: > Hi, Ronald > > > > Sorry to reply late. > > > > For you question, “we lack per-block reference validity checks in the > block reconstruction code”, would you mean encode process need validity > checks? > No. The decoder needs validity checks. I understand you're modifying libavcodec/vp9.c because of how its intertwined with the vp9 hw deoders, but it is primarily a software decoder. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 05/11] cbs_h264: Use table-based alloc/free
Mark Thompson:
> ---
> libavcodec/cbs_h2645.c | 156 +
> 1 file changed, 64 insertions(+), 92 deletions(-)
>
> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> index 319202fc48..e10bb2c62b 100644
> --- a/libavcodec/cbs_h2645.c
> +++ b/libavcodec/cbs_h2645.c
> @@ -442,51 +442,6 @@ static int cbs_h2645_read_more_rbsp_data(GetBitContext
> *gbc)
> #undef allocate
>
>
> -static void cbs_h264_free_pps(void *unit, uint8_t *content)
> -{
> -H264RawPPS *pps = (H264RawPPS*)content;
> -av_buffer_unref(>slice_group_id_ref);
> -av_freep();
> -}
> -
> -static void cbs_h264_free_sei_payload(H264RawSEIPayload *payload)
> -{
> -switch (payload->payload_type) {
> -case H264_SEI_TYPE_BUFFERING_PERIOD:
> -case H264_SEI_TYPE_PIC_TIMING:
> -case H264_SEI_TYPE_PAN_SCAN_RECT:
> -case H264_SEI_TYPE_RECOVERY_POINT:
> -case H264_SEI_TYPE_DISPLAY_ORIENTATION:
> -case H264_SEI_TYPE_MASTERING_DISPLAY_COLOUR_VOLUME:
> -break;
> -case H264_SEI_TYPE_USER_DATA_REGISTERED:
> -av_buffer_unref(>payload.user_data_registered.data_ref);
> -break;
> -case H264_SEI_TYPE_USER_DATA_UNREGISTERED:
> -av_buffer_unref(>payload.user_data_unregistered.data_ref);
> -break;
> -default:
> -av_buffer_unref(>payload.other.data_ref);
> -break;
> -}
> -}
> -
> -static void cbs_h264_free_sei(void *unit, uint8_t *content)
> -{
> -H264RawSEI *sei = (H264RawSEI*)content;
> -int i;
> -for (i = 0; i < sei->payload_count; i++)
> -cbs_h264_free_sei_payload(>payload[i]);
> -av_freep();
> -}
> -
> -static void cbs_h264_free_slice(void *unit, uint8_t *content)
> -{
> -H264RawSlice *slice = (H264RawSlice*)content;
> -av_buffer_unref(>data_ref);
> -av_freep();
> -}
> -
> static void cbs_h265_free_vps(void *unit, uint8_t *content)
> {
> H265RawVPS *vps = (H265RawVPS*)content;
> @@ -781,15 +736,14 @@ static int cbs_h264_read_nal_unit(CodedBitstreamContext
> *ctx,
> if (err < 0)
> return err;
>
> +err = ff_cbs_alloc_unit_content2(ctx, unit);
> +if (err < 0)
> +return err;
> +
> switch (unit->type) {
> case H264_NAL_SPS:
> {
> -H264RawSPS *sps;
> -
> -err = ff_cbs_alloc_unit_content(ctx, unit, sizeof(*sps), NULL);
> -if (err < 0)
> -return err;
> -sps = unit->content;
> +H264RawSPS *sps = unit->content;
>
> err = cbs_h264_read_sps(ctx, , sps);
> if (err < 0)
> @@ -803,12 +757,6 @@ static int cbs_h264_read_nal_unit(CodedBitstreamContext
> *ctx,
>
> case H264_NAL_SPS_EXT:
> {
> -err = ff_cbs_alloc_unit_content(ctx, unit,
> -sizeof(H264RawSPSExtension),
> -NULL);
> -if (err < 0)
> -return err;
> -
> err = cbs_h264_read_sps_extension(ctx, , unit->content);
> if (err < 0)
> return err;
> @@ -817,13 +765,7 @@ static int cbs_h264_read_nal_unit(CodedBitstreamContext
> *ctx,
>
> case H264_NAL_PPS:
> {
> -H264RawPPS *pps;
> -
> -err = ff_cbs_alloc_unit_content(ctx, unit, sizeof(*pps),
> -_h264_free_pps);
> -if (err < 0)
> -return err;
> -pps = unit->content;
> +H264RawPPS *pps = unit->content;
>
> err = cbs_h264_read_pps(ctx, , pps);
> if (err < 0)
> @@ -839,15 +781,9 @@ static int cbs_h264_read_nal_unit(CodedBitstreamContext
> *ctx,
> case H264_NAL_IDR_SLICE:
> case H264_NAL_AUXILIARY_SLICE:
> {
> -H264RawSlice *slice;
> +H264RawSlice *slice = unit->content;
> int pos, len;
>
> -err = ff_cbs_alloc_unit_content(ctx, unit, sizeof(*slice),
> -_h264_free_slice);
> -if (err < 0)
> -return err;
> -slice = unit->content;
> -
> err = cbs_h264_read_slice_header(ctx, , >header);
> if (err < 0)
> return err;
> @@ -873,11 +809,6 @@ static int cbs_h264_read_nal_unit(CodedBitstreamContext
> *ctx,
>
> case H264_NAL_AUD:
> {
> -err = ff_cbs_alloc_unit_content(ctx, unit,
> -sizeof(H264RawAUD), NULL);
> -if (err < 0)
> -return err;
> -
> err = cbs_h264_read_aud(ctx, , unit->content);
> if (err < 0)
> return err;
> @@ -886,11 +817,6 @@ static int cbs_h264_read_nal_unit(CodedBitstreamContext
> *ctx,
>
> case H264_NAL_SEI:
> {
> -err = ff_cbs_alloc_unit_content(ctx, unit, sizeof(H264RawSEI),
> -
[FFmpeg-devel] [PATCH] lavu/time.c: Fix check for clock_gettime
According to the documentation [1] when checking for a symbol it
should be explicitly checked against NULL and the function pointer
dereferenced.
[1]
https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html#//apple_ref/doc/uid/20002378-106633
---
libavutil/time.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/time.c b/libavutil/time.c
index afa6658aa6..42a7c1792f 100644
--- a/libavutil/time.c
+++ b/libavutil/time.c
@@ -57,7 +57,7 @@ int64_t av_gettime_relative(void)
{
#if HAVE_CLOCK_GETTIME && defined(CLOCK_MONOTONIC)
#ifdef __APPLE__
-if (clock_gettime)
+if (_gettime != NULL)
#endif
{
struct timespec ts;
@@ -72,7 +72,7 @@ int av_gettime_relative_is_monotonic(void)
{
#if HAVE_CLOCK_GETTIME && defined(CLOCK_MONOTONIC)
#ifdef __APPLE__
-if (!clock_gettime)
+if (_gettime == NULL)
return 0;
#endif
return 1;
--
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 04/11] cbs: Add macros to support defining unit type tables
Mark Thompson:
> ---
> libavcodec/cbs_internal.h | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/libavcodec/cbs_internal.h b/libavcodec/cbs_internal.h
> index 06a8f9b979..439fa7934b 100644
> --- a/libavcodec/cbs_internal.h
> +++ b/libavcodec/cbs_internal.h
> @@ -140,6 +140,27 @@ int ff_cbs_write_signed(CodedBitstreamContext *ctx,
> PutBitContext *pbc,
> #define MIN_INT_BITS(length) (-(INT64_C(1) << ((length) - 1)))
>
>
> +#define CBS_UNIT_TYPE_POD(type, structure) { \
> +.unit_type= type, \
> +.content_type = CBS_CONTENT_TYPE_POD, \
> +.content_size = sizeof(structure), \
> +}
> +#define CBS_UNIT_TYPE_INTERNAL_REFS(type, structure, nb_offsets, offsets) { \
> +.unit_type = type, \
> +.content_type = CBS_CONTENT_TYPE_INTERNAL_REFS, \
> +.content_size = sizeof(structure), \
> +.nb_ref_offsets = nb_offsets, \
> +.ref_offsets= offsets, \
> +}
Wouldn't it be appropriate to also add (and use) a macro for the
common case of a structure with exactly one internal ref? Something like
#define CBS_UNIT_TYPE_INTERNAL_REF(type, structure, offset) \
CBS_UNIT_TYPE_INTERNAL_REFS(type, structure, 1, {
offsetof(structure, offset) })
> +#define CBS_UNIT_TYPE_COMPLEX(type, structure, free_func) { \
> +.unit_type = type, \
> +.content_type = CBS_CONTENT_TYPE_COMPLEX, \
> +.content_size = sizeof(structure), \
> +.content_free = free_func, \
> +}
> +#define CBS_UNIT_TYPE_END_OF_LIST { CBS_INVALID_UNIT_TYPE }
> +
> +
> extern const CodedBitstreamType ff_cbs_type_av1;
> extern const CodedBitstreamType ff_cbs_type_h264;
> extern const CodedBitstreamType ff_cbs_type_h265;
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/file_open: log temp filename
On 22-05-2019 03:29 PM, Hendrik Leppkes wrote: On Wed, May 22, 2019 at 11:51 AM Gyan wrote: On 22-05-2019 02:29 PM, Hendrik Leppkes wrote: On Wed, May 22, 2019 at 10:53 AM Gyan wrote: On 22-05-2019 01:41 PM, Liu Steven wrote: 在 2019年5月22日，下午3:10，Gyan 写道： Helps users to identify temp files for a given instance. In the longer term, we should aim to clean up all temp files. Gyan <0001-avutil-file_open-log-temp-filename.patch>___ Why don’t use AV_LOG_DEBUG or AV_LOG_TRACE? DEBUG and TRACE are meant to record micro-ops for debugging purposes. This message will be present a handful of times in the log and is essential for end-users so they can delete these files, which ffmpeg won't do, but should since these are meant to be temporary files. Why don't we work on fixing this instead, as users will not know what implications this message has in any case and just consider it spam. 1) A grep of the tree shows only two components make use of this function. The cache protocol, which needs to be expressly invoked by the user, and the xvid encoder in 2-pass mode, which also has to be expressly invoked. No unsuspecting user will be presented with this message. 2) Fixing this is the ideal solution. The above two components already unlink the file after use, but with cache:, the file remains available after ffmpeg has exited. So this has to be looked at by someone acquainted and able to test with all the environments that ffmpeg can be run on. I don't have that knowledge or access. Till then, let's not the perfect be the enemy of the good. This message has absolutely zero indication that the user might need to act on it, nevermind that API users might never see it in the first place, as such I don't see how this is even "good". Why don't you start with collecting information which systems are even affected by this? You must have some systems where you saw this. This patch was prompted by a Windows user who wanted this info. As mentioned above, I can reproduce it with cache protocol on Windows. Don't have access to other systems, except one linux box. I just saw that we do have a file delete function. Will first see if that works. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] cbs_mpeg2: Fix parsing of slice headers
1. The extra information in slice headers was parsed incorrectly:
In the first reading pass to derive the length of the extra information,
one should look at bits n, n + 9, n + 18, ... and check whether they
equal one (further extra information) or zero (end of extra information),
but instead bits n, n + 8, n + 16, ... were inspected. The second pass
of reading (where the length is already known and the bytes between the
length-determining bits are copied into a buffer) did not record what
was in bits n, n + 9, n + 18, ..., presuming they equal one. And during
writing, the bytes in the buffer are interleaved with set bits and
written. This means that if the detected length of the extra information
was greater than the real length, the output was corrupted. Fortunately
no sample is known that made use of this mechanism: The extra information
in slices is still marked as reserved in the specifications. cbs_mpeg2
is now ready in case this changes.
2. Furthermore, the buffer is now padded and slightly different, but
very similar code for reading resp. writing has been replaced by code
used for both. This was made possible by a new macro, the equivalent
to cbs_h2645's fixed().
3. These changes also made it possible to remove the extra_bit_slice
element from the MPEG2RawSliceHeader structure. Said element was always
zero except when the detected length of the extra information was less
than the real length.
Signed-off-by: Andreas Rheinhardt
---
There was no merge conflict for me for this commit during the rebase
in reply to James' request despite there being changes in the immediate
vicinity to the changes in this patch. But I don't know if the patch
would apply cleanly to everyone else's repo as my repo contained the
whole history which might have been used to apply the commit.
libavcodec/cbs_mpeg2.c | 18 +++---
libavcodec/cbs_mpeg2.h | 2 --
libavcodec/cbs_mpeg2_syntax_template.c | 16 +---
3 files changed, 12 insertions(+), 24 deletions(-)
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index 07213437dc..eea0186c97 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -51,6 +51,13 @@
#define sis(width, name, subs, ...) \
xsi(width, name, current->name, MIN_INT_BITS(width),
MAX_INT_BITS(width), subs, __VA_ARGS__)
+#define marker_bit() \
+bit(marker_bit, 1)
+#define bit(name, value) do { \
+av_unused uint32_t bit = value; \
+xui(1, name, bit, value, value, 0); \
+} while (0)
+
#define READ
#define READWRITE read
@@ -72,11 +79,6 @@
var = value; \
} while (0)
-#define marker_bit() do { \
-av_unused uint32_t one; \
-CHECK(ff_cbs_read_unsigned(ctx, rw, 1, "marker_bit", NULL, , 1,
1)); \
-} while (0)
-
#define nextbits(width, compare, var) \
(get_bits_left(rw) >= width && \
(var = show_bits(rw, width)) == (compare))
@@ -92,7 +94,6 @@
#undef RWContext
#undef xui
#undef xsi
-#undef marker_bit
#undef nextbits
#undef infer
@@ -113,10 +114,6 @@
range_min, range_max)); \
} while (0)
-#define marker_bit() do { \
-CHECK(ff_cbs_write_unsigned(ctx, rw, 1, "marker_bit", NULL, 1, 1, 1));
\
-} while (0)
-
#define nextbits(width, compare, var) (var)
#define infer(name, value) do { \
@@ -135,7 +132,6 @@
#undef RWContext
#undef xui
#undef xsi
-#undef marker_bit
#undef nextbits
#undef infer
diff --git a/libavcodec/cbs_mpeg2.h b/libavcodec/cbs_mpeg2.h
index 11f93b9df8..db5ebc56ea 100644
--- a/libavcodec/cbs_mpeg2.h
+++ b/libavcodec/cbs_mpeg2.h
@@ -194,8 +194,6 @@ typedef struct MPEG2RawSliceHeader {
uint8_t slice_picture_id_enable;
uint8_t slice_picture_id;
-uint8_t extra_bit_slice;
-
size_t extra_information_length;
uint8_t *extra_information;
AVBufferRef *extra_information_ref;
diff --git a/libavcodec/cbs_mpeg2_syntax_template.c
b/libavcodec/cbs_mpeg2_syntax_template.c
index d9ef480f39..1f2d2497c3 100644
--- a/libavcodec/cbs_mpeg2_syntax_template.c
+++ b/libavcodec/cbs_mpeg2_syntax_template.c
@@ -377,31 +377,25 @@ static int FUNC(slice_header)(CodedBitstreamContext *ctx,
RWContext *rw,
uint8_t bit;
start = *rw;
for (k = 0; nextbits(1, 1, bit); k++)
-skip_bits(rw, 8);
+skip_bits(rw, 1 + 8);
current->extra_information_length = k;
if (k > 0) {
*rw = start;
current->extra_information_ref =
-av_buffer_alloc(current->extra_information_length);
+av_buffer_allocz(k + AV_INPUT_BUFFER_PADDING_SIZE);
if (!current->extra_information_ref)
return AVERROR(ENOMEM);
current->extra_information =
current->extra_information_ref->data;
-for (k = 0; k < current->extra_information_length; k++) {
-xui(1,
Re: [FFmpeg-devel] [PATCH V1 1/2] lavfi/lensfun: Use ff_filter_get_nb_threads() get number of threads
On Wed, May 22, 2019 at 4:20 PM Paul B Mahol wrote:
>
> On 5/22/19, Jun Zhao wrote:
> > From: Jun Zhao
> >
> > ff_filter_get_nb_threads() respect AVFilterContext.nb_threads and
> > graph->nb_threads both, in most case, we perfer this API than using
> > ctx->graph->nb_threads directly.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavfilter/vf_lensfun.c |4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavfilter/vf_lensfun.c b/libavfilter/vf_lensfun.c
> > index 3b723dd..089121e 100644
> > --- a/libavfilter/vf_lensfun.c
> > +++ b/libavfilter/vf_lensfun.c
> > @@ -465,7 +465,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> > *in)
> > vignetting_filter_slice,
> > _thread_data,
> > NULL,
> > - FFMIN(outlink->h, ctx->graph->nb_threads));
> > + FFMIN(outlink->h,
> > ff_filter_get_nb_threads(ctx)));
> > }
> >
> > if (lensfun->mode & (GEOMETRY_DISTORTION | SUBPIXEL_DISTORTION)) {
> > @@ -493,7 +493,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> > *in)
> > distortion_correction_filter_slice,
> > _correction_thread_data,
> > NULL,
> > - FFMIN(outlink->h, ctx->graph->nb_threads));
> > + FFMIN(outlink->h,
> > ff_filter_get_nb_threads(ctx)));
> >
> > av_frame_free();
> > return ff_filter_frame(outlink, out);
> > --
> > 1.7.1
> >
>
> lgtm
>
Pushed, Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V1 2/2] doc/writing_filters: Use ff_filter_get_nb_threads() get number of threads
On Wed, May 22, 2019 at 4:14 PM Paul B Mahol wrote: > > On 5/22/19, Jun Zhao wrote: > > From: Jun Zhao > > > > ff_filter_get_nb_threads() respect AVFilterContext.nb_threads and > > graph->nb_threads both, in most case, we perfer this API than using > > ctx->graph->nb_threads directly. > > --- > > doc/writing_filters.txt |2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/doc/writing_filters.txt b/doc/writing_filters.txt > > index 98b9c6f..2e25cbe 100644 > > --- a/doc/writing_filters.txt > > +++ b/doc/writing_filters.txt > > @@ -389,7 +389,7 @@ distributor with something like this: > > > > td.in = in; > > td.out = out; > > -ctx->internal->execute(ctx, filter_slice, , NULL, FFMIN(outlink->h, > > ctx->graph->nb_threads)); > > +ctx->internal->execute(ctx, filter_slice, , NULL, FFMIN(outlink->h, > > ff_filter_get_nb_threads(ctx))); > > > > // ... > > > > lgtm > Pushed, Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v4] Fix integer parameters size check in SDP fmtp line
=== PROBLEM ===
I was trying to record h264 + aac streams from an RTSP server to mp4 file.
using this command line:
ffmpeg -v verbose -y -i "rtsp:///my_resources" -codec copy -bsf:a
aac_adtstoasc test.mp4
FFmpeg then fail to record audio and output this logs:
[rtsp @ 0xcda1f0] The profile-level-id field size is invalid (40)
[rtsp @ 0xcda1f0] Error parsing AU headers
...
[rtsp @ 0xcda1f0] Could not find codec parameters for stream 1 (Audio: aac,
48000 Hz, 1 channels): unspecified sample format
In SDP provided by my RTSP server I had this fmtp line:
a=fmtp:98 streamType=5; profile-level-id=40; mode=AAC-hbr; config=1188;
sizeLength=13; indexLength=3; indexDeltaLength=3;
In FFmpeg code, I found a check introduced by commit
24130234cd9dd733116d17b724ea4c8e12ce097a. It disallow values greater than 32
for fmtp line parameters.
However, In RFC-6416 (RTP Payload Format for MPEG-4 Audio/Visual Streams) give
examples of "profile-level-id" values for AAC, up to 55.
Furthermore, RFC-4566 (SDP: Session Description Protocol) do not give any limit
of size on interger parameters given in fmtp line.
=== FIX ===
Instead of prohibit values over 32, I propose to check the possible integer
overflow.
The use of strtol allow to check the string validity and the possible overflow.
Using INT_MIN, LONG_MIN, INT_MAX and LON_MAX definitions ensure that it will
work whatever the size of int/long given by compiler.
This patch fix my problem and I now can record my RTSP AAC stream to mp4.
It has passed the full fate tests suite sucessfully.
Signed-off-by: Olivier Maignial
---
Changes v3->v4
- Rebased my patch on master
- Updated comit log to provide better explanation of the problem
- Re-passed fate tests on master
libavformat/rtpdec_mpeg4.c | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/libavformat/rtpdec_mpeg4.c b/libavformat/rtpdec_mpeg4.c
index 4f70599..d40cb5a 100644
--- a/libavformat/rtpdec_mpeg4.c
+++ b/libavformat/rtpdec_mpeg4.c
@@ -289,15 +289,33 @@ static int parse_fmtp(AVFormatContext *s,
for (i = 0; attr_names[i].str; ++i) {
if (!av_strcasecmp(attr, attr_names[i].str)) {
if (attr_names[i].type == ATTR_NAME_TYPE_INT) {
-int val = atoi(value);
-if (val > 32) {
+char *end_ptr = NULL;
+errno = 0;
+long int val = strtol(value, _ptr, 10);
+if (value[0] == '\n' || end_ptr[0] != '\0') {
av_log(s, AV_LOG_ERROR,
- "The %s field size is invalid (%d)\n",
- attr, val);
+ "The %s field value is not a number (%s)\n",
+ attr, value);
return AVERROR_INVALIDDATA;
}
+if ((val == LONG_MAX && errno == ERANGE) ||
+val > INT_MAX) {
+av_log(s, AV_LOG_ERROR,
+ "Value of field %s overflow maximum integer
value.\n",
+ attr);
+return AVERROR_INVALIDDATA;
+}
+if ((val == LONG_MIN && errno == ERANGE) ||
+val < INT_MIN)
+{
+av_log(s, AV_LOG_ERROR,
+ "Value of field %s underflow minimum integer
value.\n",
+ attr);
+return AVERROR_INVALIDDATA;
+}
+
*(int *)((char *)data+
-attr_names[i].offset) = val;
+attr_names[i].offset) = (int) val;
} else if (attr_names[i].type == ATTR_NAME_TYPE_STR) {
char *val = av_strdup(value);
if (!val)
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/file_open: log temp filename
On Wed, May 22, 2019 at 11:51 AM Gyan wrote: > > > > On 22-05-2019 02:29 PM, Hendrik Leppkes wrote: > > On Wed, May 22, 2019 at 10:53 AM Gyan wrote: > >> > >> > >> On 22-05-2019 01:41 PM, Liu Steven wrote: > 在 2019年5月22日，下午3:10，Gyan 写道： > > > Helps users to identify temp files for a given instance. > > In the longer term, we should aim to clean up all temp files. > > Gyan > <0001-avutil-file_open-log-temp-filename.patch>___ > >>> Why don’t use AV_LOG_DEBUG or AV_LOG_TRACE? > >>> > >> DEBUG and TRACE are meant to record micro-ops for debugging purposes. > >> This message will be present a handful of times in the log and is > >> essential for end-users so they can delete these files, which ffmpeg > >> won't do, but should since these are meant to be temporary files. > >> > > Why don't we work on fixing this instead, as users will not know what > > implications this message has in any case and just consider it spam. > > 1) A grep of the tree shows only two components make use of this > function. The cache protocol, which needs to be expressly invoked by the > user, and the xvid encoder in 2-pass mode, which also has to be > expressly invoked. No unsuspecting user will be presented with this message. > > 2) Fixing this is the ideal solution. The above two components already > unlink the file after use, but with cache:, the file remains available > after ffmpeg has exited. So this has to be looked at by someone > acquainted and able to test with all the environments that ffmpeg can be > run on. I don't have that knowledge or access. Till then, let's not the > perfect be the enemy of the good. > This message has absolutely zero indication that the user might need to act on it, nevermind that API users might never see it in the first place, as such I don't see how this is even "good". Why don't you start with collecting information which systems are even affected by this? You must have some systems where you saw this. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] cbs_mpeg2: Fix parsing of picture headers
MPEG-2 picture and slice headers can contain optional extra information;
both use the same syntax for their extra information. And cbs_mpeg2's
implementations of both were buggy until recently; the one for the
picture headers still is and this is fixed in this commit.
The extra information in picture headers has simply been forgotten.
This meant that if this extra information was present, it was discarded
during reading; and unfortunately writing created invalid bitstreams in
this case (an extra_bit_picture - the last set bit of the whole unit -
indicated that there would be a further byte of data, although the output
didn't contain said data).
This has been fixed; both types of extra information are now
parsed via the same code and essentially passed through.
Signed-off-by: Andreas Rheinhardt
---
New version made necessary because of a merge conflict due to James'
request.
libavcodec/cbs_mpeg2.c | 31 +++-
libavcodec/cbs_mpeg2.h | 12 +++--
libavcodec/cbs_mpeg2_syntax_template.c | 66 +++---
3 files changed, 66 insertions(+), 43 deletions(-)
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index eea0186c97..f7283f6363 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -41,18 +41,18 @@
#define SUBSCRIPTS(subs, ...) (subs > 0 ? ((int[subs + 1]){ subs, __VA_ARGS__
}) : NULL)
#define ui(width, name) \
-xui(width, name, current->name, 0, MAX_UINT_BITS(width), 0)
+xui(width, #name, current->name, 0, MAX_UINT_BITS(width), 0)
#define uir(width, name) \
-xui(width, name, current->name, 1, MAX_UINT_BITS(width), 0)
+xui(width, #name, current->name, 1, MAX_UINT_BITS(width), 0)
#define uis(width, name, subs, ...) \
-xui(width, name, current->name, 0, MAX_UINT_BITS(width), subs,
__VA_ARGS__)
+xui(width, #name, current->name, 0, MAX_UINT_BITS(width), subs,
__VA_ARGS__)
#define uirs(width, name, subs, ...) \
-xui(width, name, current->name, 1, MAX_UINT_BITS(width), subs,
__VA_ARGS__)
+xui(width, #name, current->name, 1, MAX_UINT_BITS(width), subs,
__VA_ARGS__)
#define sis(width, name, subs, ...) \
-xsi(width, name, current->name, MIN_INT_BITS(width),
MAX_INT_BITS(width), subs, __VA_ARGS__)
+xsi(width, #name, current->name, MIN_INT_BITS(width),
MAX_INT_BITS(width), subs, __VA_ARGS__)
#define marker_bit() \
-bit(marker_bit, 1)
+bit("marker_bit", 1)
#define bit(name, value) do { \
av_unused uint32_t bit = value; \
xui(1, name, bit, value, value, 0); \
@@ -65,7 +65,7 @@
#define xui(width, name, var, range_min, range_max, subs, ...) do { \
uint32_t value; \
-CHECK(ff_cbs_read_unsigned(ctx, rw, width, #name, \
+CHECK(ff_cbs_read_unsigned(ctx, rw, width, name, \
SUBSCRIPTS(subs, __VA_ARGS__), \
, range_min, range_max)); \
var = value; \
@@ -73,7 +73,7 @@
#define xsi(width, name, var, range_min, range_max, subs, ...) do { \
int32_t value; \
-CHECK(ff_cbs_read_signed(ctx, rw, width, #name, \
+CHECK(ff_cbs_read_signed(ctx, rw, width, name, \
SUBSCRIPTS(subs, __VA_ARGS__), , \
range_min, range_max)); \
var = value; \
@@ -103,13 +103,13 @@
#define RWContext PutBitContext
#define xui(width, name, var, range_min, range_max, subs, ...) do { \
-CHECK(ff_cbs_write_unsigned(ctx, rw, width, #name, \
+CHECK(ff_cbs_write_unsigned(ctx, rw, width, name, \
SUBSCRIPTS(subs, __VA_ARGS__), \
var, range_min, range_max)); \
} while (0)
#define xsi(width, name, var, range_min, range_max, subs, ...) do { \
-CHECK(ff_cbs_write_signed(ctx, rw, width, #name, \
+CHECK(ff_cbs_write_signed(ctx, rw, width, name, \
SUBSCRIPTS(subs, __VA_ARGS__), var, \
range_min, range_max)); \
} while (0)
@@ -136,6 +136,13 @@
#undef infer
+static void cbs_mpeg2_free_picture_header(void *unit, uint8_t *content)
+{
+MPEG2RawPictureHeader *picture = (MPEG2RawPictureHeader*)content;
+av_buffer_unref(>extra_information_picture.extra_information_ref);
+av_free(content);
+}
+
static void cbs_mpeg2_free_user_data(void *unit, uint8_t *content)
{
MPEG2RawUserData *user = (MPEG2RawUserData*)content;
@@ -146,7 +153,7 @@ static void cbs_mpeg2_free_user_data(void *unit, uint8_t
*content)
static void cbs_mpeg2_free_slice(void *unit, uint8_t *content)
{
MPEG2RawSlice *slice = (MPEG2RawSlice*)content;
-av_buffer_unref(>header.extra_information_ref);
+
av_buffer_unref(>header.extra_information_slice.extra_information_ref);
av_buffer_unref(>data_ref);
av_free(content);
}
@@ -249,7 +256,7 @@ static int
[FFmpeg-devel] [PATCH] cbs_mpeg2: Fix storage type for frame_centre_*_offset
The frame_centre_horizontal/vertical_offset values contained in picture
display extensions are actually signed values (i.e. it is possible to
indicate that the display device should add black bars/pillars).
The files sony-ct3.bs and tcela-6.bits (which are both used in fate
tests for mpeg2_metadata) contain picture display extensions; the former
even contains a negative frame_centre_vertical_offset. Fortunately, the
old code did not damage the picture display extensions when one did a
cycle of reading and writing. For the same reason the fate tests needn't
be updated either.
Furthermore these fields now use the trace output for matrices.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_mpeg2.c | 18 ++
libavcodec/cbs_mpeg2.h | 4 ++--
libavcodec/cbs_mpeg2_syntax_template.c | 4 ++--
3 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index 437eac88a3..ba34ace9b4 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -48,6 +48,8 @@
xui(width, name, current->name, 0, MAX_UINT_BITS(width), subs,
__VA_ARGS__)
#define uirs(width, name, subs, ...) \
xui(width, name, current->name, 1, MAX_UINT_BITS(width), subs,
__VA_ARGS__)
+#define sis(width, name, subs, ...) \
+xsi(width, name, current->name, MIN_INT_BITS(width),
MAX_INT_BITS(width), subs, __VA_ARGS__)
#define READ
@@ -62,6 +64,14 @@
var = value; \
} while (0)
+#define xsi(width, name, var, range_min, range_max, subs, ...) do { \
+int32_t value; \
+CHECK(ff_cbs_read_signed(ctx, rw, width, #name, \
+ SUBSCRIPTS(subs, __VA_ARGS__), , \
+ range_min, range_max)); \
+var = value; \
+} while (0)
+
#define marker_bit() do { \
av_unused uint32_t one; \
CHECK(ff_cbs_read_unsigned(ctx, rw, 1, "marker_bit", NULL, , 1,
1)); \
@@ -81,6 +91,7 @@
#undef READWRITE
#undef RWContext
#undef xui
+#undef xsi
#undef marker_bit
#undef nextbits
#undef infer
@@ -96,6 +107,12 @@
var, range_min, range_max)); \
} while (0)
+#define xsi(width, name, var, range_min, range_max, subs, ...) do { \
+CHECK(ff_cbs_write_signed(ctx, rw, width, #name, \
+ SUBSCRIPTS(subs, __VA_ARGS__), var, \
+ range_min, range_max)); \
+} while (0)
+
#define marker_bit() do { \
CHECK(ff_cbs_write_unsigned(ctx, rw, 1, "marker_bit", NULL, 1, 1, 1));
\
} while (0)
@@ -117,6 +134,7 @@
#undef READWRITE
#undef RWContext
#undef xui
+#undef xsi
#undef marker_bit
#undef nextbits
#undef infer
diff --git a/libavcodec/cbs_mpeg2.h b/libavcodec/cbs_mpeg2.h
index 7565695acb..11f93b9df8 100644
--- a/libavcodec/cbs_mpeg2.h
+++ b/libavcodec/cbs_mpeg2.h
@@ -164,8 +164,8 @@ typedef struct MPEG2RawQuantMatrixExtension {
} MPEG2RawQuantMatrixExtension;
typedef struct MPEG2RawPictureDisplayExtension {
-uint16_t frame_centre_horizontal_offset[3];
-uint16_t frame_centre_vertical_offset[3];
+int16_t frame_centre_horizontal_offset[3];
+int16_t frame_centre_vertical_offset[3];
} MPEG2RawPictureDisplayExtension;
typedef struct MPEG2RawExtensionData {
diff --git a/libavcodec/cbs_mpeg2_syntax_template.c
b/libavcodec/cbs_mpeg2_syntax_template.c
index 87db0ad039..e34fa9495f 100644
--- a/libavcodec/cbs_mpeg2_syntax_template.c
+++ b/libavcodec/cbs_mpeg2_syntax_template.c
@@ -303,9 +303,9 @@ static int
FUNC(picture_display_extension)(CodedBitstreamContext *ctx, RWContext
HEADER("Picture Display Extension");
for (i = 0; i < mpeg2->number_of_frame_centre_offsets; i++) {
-ui(16, frame_centre_horizontal_offset[i]);
+sis(16, frame_centre_horizontal_offset[i], 1, i);
marker_bit();
-ui(16, frame_centre_vertical_offset[i]);
+sis(16, frame_centre_vertical_offset[i], 1, i);
marker_bit();
}
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/file_open: log temp filename
On 22-05-2019 02:29 PM, Hendrik Leppkes wrote: On Wed, May 22, 2019 at 10:53 AM Gyan wrote: On 22-05-2019 01:41 PM, Liu Steven wrote: 在 2019年5月22日，下午3:10，Gyan 写道： Helps users to identify temp files for a given instance. In the longer term, we should aim to clean up all temp files. Gyan <0001-avutil-file_open-log-temp-filename.patch>___ Why don’t use AV_LOG_DEBUG or AV_LOG_TRACE? DEBUG and TRACE are meant to record micro-ops for debugging purposes. This message will be present a handful of times in the log and is essential for end-users so they can delete these files, which ffmpeg won't do, but should since these are meant to be temporary files. Why don't we work on fixing this instead, as users will not know what implications this message has in any case and just consider it spam. 1) A grep of the tree shows only two components make use of this function. The cache protocol, which needs to be expressly invoked by the user, and the xvid encoder in 2-pass mode, which also has to be expressly invoked. No unsuspecting user will be presented with this message. 2) Fixing this is the ideal solution. The above two components already unlink the file after use, but with cache:, the file remains available after ffmpeg has exited. So this has to be looked at by someone acquainted and able to test with all the environments that ffmpeg can be run on. I don't have that knowledge or access. Till then, let's not the perfect be the enemy of the good. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/file_open: log temp filename
Hendrik Leppkes 于2019年5月22日周三 下午5:05写道： > > On Wed, May 22, 2019 at 10:53 AM Gyan wrote: > > > > > > > > On 22-05-2019 01:41 PM, Liu Steven wrote: > > > > > >> 在 2019年5月22日，下午3:10，Gyan 写道： > > >> > > >> > > >> Helps users to identify temp files for a given instance. > > >> > > >> In the longer term, we should aim to clean up all temp files. > > >> > > >> Gyan > > >> <0001-avutil-file_open-log-temp-filename.patch>___ > > > Why don’t use AV_LOG_DEBUG or AV_LOG_TRACE? > > > > > DEBUG and TRACE are meant to record micro-ops for debugging purposes. > > This message will be present a handful of times in the log and is > > essential for end-users so they can delete these files, which ffmpeg > > won't do, but should since these are meant to be temporary files. > > > > Why don't we work on fixing this instead, as users will not know what > implications this message has in any case and just consider it spam. +1 > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/file_open: log temp filename
On Wed, May 22, 2019 at 10:53 AM Gyan wrote: > > > > On 22-05-2019 01:41 PM, Liu Steven wrote: > > > >> 在 2019年5月22日，下午3:10，Gyan 写道： > >> > >> > >> Helps users to identify temp files for a given instance. > >> > >> In the longer term, we should aim to clean up all temp files. > >> > >> Gyan > >> <0001-avutil-file_open-log-temp-filename.patch>___ > > Why don’t use AV_LOG_DEBUG or AV_LOG_TRACE? > > > DEBUG and TRACE are meant to record micro-ops for debugging purposes. > This message will be present a handful of times in the log and is > essential for end-users so they can delete these files, which ffmpeg > won't do, but should since these are meant to be temporary files. > Why don't we work on fixing this instead, as users will not know what implications this message has in any case and just consider it spam. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/file_open: log temp filename
On 22-05-2019 01:41 PM, Liu Steven wrote: 在 2019年5月22日，下午3:10，Gyan 写道： Helps users to identify temp files for a given instance. In the longer term, we should aim to clean up all temp files. Gyan <0001-avutil-file_open-log-temp-filename.patch>___ Why don’t use AV_LOG_DEBUG or AV_LOG_TRACE? DEBUG and TRACE are meant to record micro-ops for debugging purposes. This message will be present a handful of times in the log and is essential for end-users so they can delete these files, which ffmpeg won't do, but should since these are meant to be temporary files. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V1 1/2] lavfi/lensfun: Use ff_filter_get_nb_threads() get number of threads
On 5/22/19, Jun Zhao wrote:
> From: Jun Zhao
>
> ff_filter_get_nb_threads() respect AVFilterContext.nb_threads and
> graph->nb_threads both, in most case, we perfer this API than using
> ctx->graph->nb_threads directly.
>
> Signed-off-by: Jun Zhao
> ---
> libavfilter/vf_lensfun.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/vf_lensfun.c b/libavfilter/vf_lensfun.c
> index 3b723dd..089121e 100644
> --- a/libavfilter/vf_lensfun.c
> +++ b/libavfilter/vf_lensfun.c
> @@ -465,7 +465,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *in)
> vignetting_filter_slice,
> _thread_data,
> NULL,
> - FFMIN(outlink->h, ctx->graph->nb_threads));
> + FFMIN(outlink->h,
> ff_filter_get_nb_threads(ctx)));
> }
>
> if (lensfun->mode & (GEOMETRY_DISTORTION | SUBPIXEL_DISTORTION)) {
> @@ -493,7 +493,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *in)
> distortion_correction_filter_slice,
> _correction_thread_data,
> NULL,
> - FFMIN(outlink->h, ctx->graph->nb_threads));
> + FFMIN(outlink->h,
> ff_filter_get_nb_threads(ctx)));
>
> av_frame_free();
> return ff_filter_frame(outlink, out);
> --
> 1.7.1
>
lgtm
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V1 2/2] doc/writing_filters: Use ff_filter_get_nb_threads() get number of threads
On 5/22/19, Jun Zhao wrote: > From: Jun Zhao > > ff_filter_get_nb_threads() respect AVFilterContext.nb_threads and > graph->nb_threads both, in most case, we perfer this API than using > ctx->graph->nb_threads directly. > --- > doc/writing_filters.txt |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/doc/writing_filters.txt b/doc/writing_filters.txt > index 98b9c6f..2e25cbe 100644 > --- a/doc/writing_filters.txt > +++ b/doc/writing_filters.txt > @@ -389,7 +389,7 @@ distributor with something like this: > > td.in = in; > td.out = out; > -ctx->internal->execute(ctx, filter_slice, , NULL, FFMIN(outlink->h, > ctx->graph->nb_threads)); > +ctx->internal->execute(ctx, filter_slice, , NULL, FFMIN(outlink->h, > ff_filter_get_nb_threads(ctx))); > > // ... > lgtm > -- > 1.7.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/file_open: log temp filename
> 在 2019年5月22日，下午3:10，Gyan 写道： > > > Helps users to identify temp files for a given instance. > > In the longer term, we should aim to clean up all temp files. > > Gyan > <0001-avutil-file_open-log-temp-filename.patch>___ Why don’t use AV_LOG_DEBUG or AV_LOG_TRACE? Thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avutil/file_open: log temp filename
Helps users to identify temp files for a given instance. In the longer term, we should aim to clean up all temp files. Gyan From df7ff4b80ef424922236ac991b4664533e40b678 Mon Sep 17 00:00:00 2001 From: Gyan Doshi Date: Wed, 22 May 2019 12:34:19 +0530 Subject: [PATCH] avutil/file_open: log temp filename Helps users to identify temp files for cleanup. --- libavutil/file_open.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavutil/file_open.c b/libavutil/file_open.c index cc302f2f76..75d1c8befd 100644 --- a/libavutil/file_open.c +++ b/libavutil/file_open.c @@ -152,6 +152,8 @@ int avpriv_tempfile(const char *prefix, char **filename, int log_offset, void *l av_freep(filename); return err; } +av_log(_log_ctx, AV_LOG_INFO, "Opened temporary file %s\n", *filename); + return fd; /* success */ } -- 2.21.0___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] avcodec/nvenc: add master display and light level sei for HDR10
From: Limin Wang
The testing command for the HDR10 output with nvenc:
$ ./ffmpeg_g -y -i 4K.mp4 -c:v hevc_nvenc -g 7 -color_primaries bt2020
-colorspace bt2020_ncl -color_trc smpte2084 -sei hdr10 \
-master_display
"G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(1000,50)"
-max_cll "0, 0" test.ts
Please notice it is preferable to use the frame sei side data than
master_display and max_cll paramters config
---
libavcodec/nvenc.c | 129
libavcodec/nvenc.h | 18 ++
libavcodec/nvenc_hevc.c | 11
3 files changed, 158 insertions(+)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 75dda6d689..3fd0eca4a5 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -22,6 +22,9 @@
#include "config.h"
#include "nvenc.h"
+#include "cbs_h265.h"
+#include "hevc_sei.h"
+#include "put_bits.h"
#include "libavutil/hwcontext_cuda.h"
#include "libavutil/hwcontext.h"
@@ -30,6 +33,7 @@
#include "libavutil/avassert.h"
#include "libavutil/mem.h"
#include "libavutil/pixdesc.h"
+#include "libavutil/mastering_display_metadata.h"
#include "internal.h"
#define CHECK_CU(x) FF_CUDA_CHECK_DL(avctx, dl_fn->cuda_dl, x)
@@ -1491,6 +1495,46 @@ av_cold int ff_nvenc_encode_init(AVCodecContext *avctx)
ctx->data_pix_fmt = avctx->pix_fmt;
}
+ctx->display_primaries_x[0] = 13250;
+ctx->display_primaries_y[0] = 34500;
+ctx->display_primaries_x[1] = 7500;
+ctx->display_primaries_y[1] = 3000;
+ctx->display_primaries_x[2] = 34000;
+ctx->display_primaries_y[2] = 16000;
+ctx->white_point_x = 15635;
+ctx->white_point_y = 16450;
+ctx->max_display_mastering_luminance = 1000;
+ctx->min_display_mastering_luminance = 500;
+ctx->max_content_light_level = 0;
+ctx->max_pic_average_light_level = 0;
+if (ctx->master_display) {
+ret = sscanf(ctx->master_display,
"G(%hu,%hu)B(%hu,%hu)R(%hu,%hu)WP(%hu,%hu)L(%u,%u)",
+>display_primaries_x[0], >display_primaries_y[0],
+>display_primaries_x[1], >display_primaries_y[1],
+>display_primaries_x[2], >display_primaries_y[2],
+>white_point_x, >white_point_y,
+>max_display_mastering_luminance,
>min_display_mastering_luminance);
+if (ret != 10) {
+ret = sscanf(ctx->master_display,
"G[%hu,%hu]B[%hu,%hu]R[%hu,%hu]WP[%hu,%hu]L[%u,%u]",
+>display_primaries_x[0], >display_primaries_y[0],
+>display_primaries_x[1], >display_primaries_y[1],
+>display_primaries_x[2], >display_primaries_y[2],
+>white_point_x, >white_point_y,
+>max_display_mastering_luminance,
>min_display_mastering_luminance);
+}
+
+if (ret != 10) {
+av_log(avctx, AV_LOG_INFO, "Failed to parse master display(%s)\n",
ctx->master_display);
+}
+}
+
+if (ctx->max_cll) {
+ret = sscanf(ctx->max_cll, "%hu,%hu", >max_content_light_level,
>max_pic_average_light_level);
+if (ret != 2) {
+av_log(avctx, AV_LOG_INFO, "Failed to parse max cll(%s)\n",
ctx->max_cll);
+}
+}
+
if ((ret = nvenc_load_libraries(avctx)) < 0)
return ret;
@@ -2110,6 +2154,91 @@ int ff_nvenc_send_frame(AVCodecContext *avctx, const
AVFrame *frame)
}
}
+if (ctx->sei & SEI_MASTERING_DISPLAY) {
+AVFrameSideData *sd = av_frame_get_side_data(frame,
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
+H265RawSEIMasteringDisplayColourVolume smd;
+
+if (sd) {
+AVMasteringDisplayMetadata *mdm = (AVMasteringDisplayMetadata
*)sd->data;
+// HEVC uses a g,b,r ordering, which we convert from a more
natural r,g,b
+const int mapping[3] = {2, 0, 1};
+const int chroma_den = 5;
+const int luma_den = 1;
+
+if (mdm->has_primaries && mdm->has_luminance) {
+
+for (i = 0; i < 3; i++) {
+const int j = mapping[i];
+smd.display_primaries_x[i] = chroma_den *
av_q2d(mdm->display_primaries[j][0]);
+smd.display_primaries_y[i] = chroma_den * av_q2d(
mdm->display_primaries[j][1]);
+}
+
+smd.white_point_x = chroma_den *
av_q2d(mdm->white_point[0]);
+smd.white_point_y = chroma_den *
av_q2d(mdm->white_point[1]);
+smd.max_display_mastering_luminance = luma_den *
av_q2d(mdm->max_luminance);
+smd.min_display_mastering_luminance = luma_den *
av_q2d(mdm->min_luminance);
+}
+} else {
+for (i = 0; i < 3; i++) {
+smd.display_primaries_x[i] = ctx->display_primaries_x[i];
+smd.display_primaries_y[i] =
[FFmpeg-devel] [PATCH 1/3] avcodec/nvenc: add more sei data support
From: Limin Wang
---
libavcodec/nvenc.c | 36 ++--
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 3fe64bba8b..75dda6d689 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -1705,7 +1705,8 @@ static int nvenc_upload_frame(AVCodecContext *avctx,
const AVFrame *frame,
static void nvenc_codec_specific_pic_params(AVCodecContext *avctx,
NV_ENC_PIC_PARAMS *params,
-NV_ENC_SEI_PAYLOAD *sei_data)
+NV_ENC_SEI_PAYLOAD *sei_data,
+int sei_count)
{
NvencContext *ctx = avctx->priv_data;
@@ -1715,9 +1716,9 @@ static void
nvenc_codec_specific_pic_params(AVCodecContext *avctx,
ctx->encode_config.encodeCodecConfig.h264Config.sliceMode;
params->codecPicParams.h264PicParams.sliceModeData =
ctx->encode_config.encodeCodecConfig.h264Config.sliceModeData;
-if (sei_data) {
+if (sei_count > 0) {
params->codecPicParams.h264PicParams.seiPayloadArray = sei_data;
-params->codecPicParams.h264PicParams.seiPayloadArrayCnt = 1;
+params->codecPicParams.h264PicParams.seiPayloadArrayCnt =
sei_count;
}
break;
@@ -1726,9 +1727,9 @@ static void
nvenc_codec_specific_pic_params(AVCodecContext *avctx,
ctx->encode_config.encodeCodecConfig.hevcConfig.sliceMode;
params->codecPicParams.hevcPicParams.sliceModeData =
ctx->encode_config.encodeCodecConfig.hevcConfig.sliceModeData;
-if (sei_data) {
+if (sei_count > 0) {
params->codecPicParams.hevcPicParams.seiPayloadArray = sei_data;
-params->codecPicParams.hevcPicParams.seiPayloadArrayCnt = 1;
+params->codecPicParams.hevcPicParams.seiPayloadArrayCnt =
sei_count;
}
break;
@@ -2023,8 +2024,9 @@ int ff_nvenc_send_frame(AVCodecContext *avctx, const
AVFrame *frame)
NVENCSTATUS nv_status;
NvencSurface *tmp_out_surf, *in_surf;
int res, res2;
-NV_ENC_SEI_PAYLOAD *sei_data = NULL;
-size_t sei_size;
+NV_ENC_SEI_PAYLOAD sei_data[8];
+int sei_count = 0;
+int i;
NvencContext *ctx = avctx->priv_data;
NvencDynLoadFunctions *dl_fn = >nvenc_dload_funcs;
@@ -2093,18 +2095,22 @@ int ff_nvenc_send_frame(AVCodecContext *avctx, const
AVFrame *frame)
pic_params.inputTimeStamp = frame->pts;
if (ctx->a53_cc && av_frame_get_side_data(frame,
AV_FRAME_DATA_A53_CC)) {
-if (ff_alloc_a53_sei(frame, sizeof(NV_ENC_SEI_PAYLOAD),
(void**)_data, _size) < 0) {
+void *a53_data = NULL;
+size_t a53_size = 0;
+
+if (ff_alloc_a53_sei(frame, 0, (void**)_data, _size) < 0) {
av_log(ctx, AV_LOG_ERROR, "Not enough memory for closed
captions, skipping\n");
}
-if (sei_data) {
-sei_data->payloadSize = (uint32_t)sei_size;
-sei_data->payloadType = 4;
-sei_data->payload = (uint8_t*)(sei_data + 1);
+if (a53_data) {
+sei_data[sei_count].payloadSize = (uint32_t)a53_size;
+sei_data[sei_count].payloadType = 4;
+sei_data[sei_count].payload = (uint8_t*)a53_data;
+sei_count ++;
}
}
-nvenc_codec_specific_pic_params(avctx, _params, sei_data);
+nvenc_codec_specific_pic_params(avctx, _params, sei_data,
sei_count);
} else {
pic_params.encodePicFlags = NV_ENC_PIC_FLAG_EOS;
ctx->encoder_flushing = 1;
@@ -2115,7 +2121,9 @@ int ff_nvenc_send_frame(AVCodecContext *avctx, const
AVFrame *frame)
return res;
nv_status = p_nvenc->nvEncEncodePicture(ctx->nvencoder, _params);
-av_free(sei_data);
+
+for ( i = 0; i < sei_count; i++)
+av_freep(_data[i].payload);
res = nvenc_pop_context(avctx);
if (res < 0)
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] avcodec/nvenc: add more sei support for SDR HLG
From: Limin Wang
The testing command for the HLG output with nvenc:
./ffmpeg_g -y -i 4K.mp4 -c:v hevc_nvenc -g 7 -color_primaries bt2020
-colorspace bt2020_ncl -color_trc smpte2084 -sei hlg test.ts
---
libavcodec/nvenc.c | 24
libavcodec/nvenc.h | 1 +
libavcodec/nvenc_hevc.c | 3 +++
3 files changed, 28 insertions(+)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 3fd0eca4a5..239788b2d7 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -1019,6 +1019,10 @@ static av_cold int
nvenc_setup_hevc_config(AVCodecContext *avctx)
vui->colourMatrix = avctx->colorspace;
vui->colourPrimaries = avctx->color_primaries;
vui->transferCharacteristics = avctx->color_trc;
+if (ctx->sei & SEI_ALTER_TRANSFER_CHAR) {
+if (IS_10BIT(ctx->data_pix_fmt))
+vui->transferCharacteristics = AVCOL_TRC_BT2020_10;
+}
vui->videoFullRangeFlag = (avctx->color_range == AVCOL_RANGE_JPEG
|| ctx->data_pix_fmt == AV_PIX_FMT_YUVJ420P || ctx->data_pix_fmt ==
AV_PIX_FMT_YUVJ422P || ctx->data_pix_fmt == AV_PIX_FMT_YUVJ444P);
@@ -2239,6 +2243,26 @@ int ff_nvenc_send_frame(AVCodecContext *avctx, const
AVFrame *frame)
}
}
+if (ctx->sei & SEI_ALTER_TRANSFER_CHAR) {
+if (avctx->codec->id == AV_CODEC_ID_HEVC) {
+size_t transfer_sei_size =
sizeof(H265RawSEIAlternativeTransferCharacteristics);
+H265RawSEIAlternativeTransferCharacteristics transfer_data;
+transfer_data.preferred_transfer_characteristics =
AVCOL_TRC_ARIB_STD_B67;
+
+sei_data[sei_count].payloadSize = transfer_sei_size;
+sei_data[sei_count].payloadType =
HEVC_SEI_TYPE_ALTERNATIVE_TRANSFER_CHARACTERISTICS;
+sei_data[sei_count].payload = av_malloc(transfer_sei_size);
+if (sei_data[sei_count].payload) {
+PutBitContext pb;
+init_put_bits(, sei_data[sei_count].payload,
sei_data[sei_count].payloadSize);
+put_bits(, 8,
transfer_data.preferred_transfer_characteristics);
+flush_put_bits();
+
+sei_count ++;
+}
+}
+}
+
nvenc_codec_specific_pic_params(avctx, _params, sei_data,
sei_count);
} else {
pic_params.encodePicFlags = NV_ENC_PIC_FLAG_EOS;
diff --git a/libavcodec/nvenc.h b/libavcodec/nvenc.h
index 583c48d090..8be0d341ea 100644
--- a/libavcodec/nvenc.h
+++ b/libavcodec/nvenc.h
@@ -55,6 +55,7 @@ typedef void ID3D11Device;
#endif
enum {
+SEI_ALTER_TRANSFER_CHAR = 0x04,
SEI_MASTERING_DISPLAY = 0x08,
SEI_CONTENT_LIGHT_LEVEL = 0x10,
};
diff --git a/libavcodec/nvenc_hevc.c b/libavcodec/nvenc_hevc.c
index 74ebd03d8e..23ba593439 100644
--- a/libavcodec/nvenc_hevc.c
+++ b/libavcodec/nvenc_hevc.c
@@ -134,6 +134,9 @@ static const AVOption options[] = {
{ "hdr10","Include HDR metadata for mastering display colour volume and
content light level information",
0,
AV_OPT_TYPE_CONST, { .i64 = SEI_MASTERING_DISPLAY | SEI_CONTENT_LIGHT_LEVEL },
0, 0, VE, "sei" },
+{ "hlg","Include HLG metadata for alternative transfer characteristics",
+0,
AV_OPT_TYPE_CONST, { .i64 = SEI_ALTER_TRANSFER_CHAR },
+0, 0, VE, "sei" },
{ "master_display", "SMPTE ST 2086 master display color volume info
SEI (HDR), the string format is: \"G(x,y)B(x,y)R(x,y)WP(x,y)L(max,min)\"",
OFFSET(master_display), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, VE },
{ "max_cll", "content light level info, the string format is:
\"cll, fall\"",
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
