[FFmpeg-devel] [PATCH v2] libavformat/dashdec: Avoid multiple HTTP requests for initialization segment that is common among all representations
Hi,
The following patch avoid multiple HTTP requests for initialization segment
that is common among all representations.
---
libavformat/dashdec.c | 82 ---
1 file changed, 71 insertions(+), 11 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 8bfde4d..6304ad9 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -149,6 +149,11 @@ typedef struct DASHContext {
char *allowed_extensions;
AVDictionary *avio_opts;
int max_url_size;
+
+/* Flags for init section*/
+int is_init_section_common_video;
+int is_init_section_common_audio;
+
} DASHContext;
static int ishttp(char *url)
@@ -416,9 +421,9 @@ static int open_url(AVFormatContext *s, AVIOContext **pb,
const char *url,
if (av_strstart(proto_name, "file", NULL)) {
if (strcmp(c->allowed_extensions, "ALL") && !av_match_ext(url,
c->allowed_extensions)) {
av_log(s, AV_LOG_ERROR,
-"Filename extension of \'%s\' is not a common multimedia
extension, blocked for security reasons.\n"
-"If you wish to override this adjust allowed_extensions, you
can set it to \'ALL\' to allow all\n",
-url);
+ "Filename extension of \'%s\' is not a common multimedia
extension, blocked for security reasons.\n"
+ "If you wish to override this adjust allowed_extensions,
you can set it to \'ALL\' to allow all\n",
+ url);
return AVERROR_INVALIDDATA;
}
} else if (av_strstart(proto_name, "http", NULL)) {
@@ -931,7 +936,7 @@ static int parse_manifest_representation(AVFormatContext
*s, const char *url,
rep->last_seq_no =(int64_t) strtoll(val, NULL, 10) - 1;
xmlFree(val);
}
- }
+}
}
fragment_timeline_node =
find_child_node_by_name(representation_segmenttemplate_node, "SegmentTimeline");
@@ -1160,7 +1165,7 @@ static int parse_manifest(AVFormatContext *s, const char
*url, AVIOContext *in)
} else {
LIBXML_TEST_VERSION
-doc = xmlReadMemory(buffer, filesize, c->base_url, NULL, 0);
+doc = xmlReadMemory(buffer, filesize, c->base_url, NULL, 0);
root_element = xmlDocGetRootElement(doc);
node = root_element;
@@ -1396,14 +1401,14 @@ static int refresh_manifest(AVFormatContext *s)
if (c->n_videos != n_videos) {
av_log(c, AV_LOG_ERROR,
-"new manifest has mismatched no. of video representations, %d ->
%d\n",
-n_videos, c->n_videos);
+ "new manifest has mismatched no. of video representations, %d
-> %d\n",
+ n_videos, c->n_videos);
return AVERROR_INVALIDDATA;
}
if (c->n_audios != n_audios) {
av_log(c, AV_LOG_ERROR,
-"new manifest has mismatched no. of audio representations, %d ->
%d\n",
-n_audios, c->n_audios);
+ "new manifest has mismatched no. of audio representations, %d
-> %d\n",
+ n_audios, c->n_audios);
return AVERROR_INVALIDDATA;
}
@@ -1862,6 +1867,45 @@ fail:
return ret;
}
+static int init_section_compare_video(DASHContext *c)
+{
+int i = 0;
+char *url = c->videos[0]->init_section->url;
+int64_t url_offset = c->videos[0]->init_section->url_offset;
+int64_t size = c->videos[0]->init_section->size;
+for (i=0;in_videos;i++) {
+if (av_strcasecmp(c->videos[i]->init_section->url,url) ||
c->videos[i]->init_section->url_offset != url_offset ||
c->videos[i]->init_section->size != size) {
+return 0;
+}
+}
+return 1;
+}
+
+static int init_section_compare_audio(DASHContext *c)
+{
+int i = 0;
+char *url = c->audios[0]->init_section->url;
+int64_t url_offset = c->audios[0]->init_section->url_offset;
+int64_t size = c->audios[0]->init_section->size;
+for (i=0;in_audios;i++) {
+if (av_strcasecmp(c->audios[i]->init_section->url,url) ||
c->audios[i]->init_section->url_offset != url_offset ||
c->audios[i]->init_section->size != size) {
+return 0;
+}
+}
+return 1;
+}
+
+static void copy_init_section(struct representation *rep_dest, struct
representation *rep_src)
+{
+memcpy(rep_dest->init_section, rep_src->init_section,
sizeof(rep_src->init_section));
+rep_dest->init_sec_buf = av_mallocz(rep_src->init_sec_buf_size);
+memcpy(rep_dest->init_sec_buf, rep_src->init_sec_buf,
rep_src->init_sec_data_len);
+rep_dest->init_sec_buf_size = rep_src->init_sec_buf_size;
+rep_dest->init_sec_data_len = rep_src->init_sec_data_len;
+rep_dest->cur_timestamp = rep_src->cur_timestamp;
+}
+
+
static int dash_read_header(AVFormatContext *s)
{
void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
@@ -1890,19 +1934,35 @@ static int dash_read_header(AVFormat
Re: [FFmpeg-devel] [PATCH] libavformat/dashdec: Avoid multiple HTTP requests for initialization segment that is common among all representations
Hi Steven,
The changes mentioned have the same logic. I have re-submitted the patch.
Thanks,
Sanil
On Mon, Apr 9, 2018 at 2:52 AM, Steven Liu wrote:
>
>
> > On 9 Apr 2018, at 15:02, sanilraut wrote:
> >
> > Hi,
> >
> > The following patch avoid multiple HTTP requests for initialization
> segment that is common among all representations.
> >
> > ---
> > libavformat/dashdec.c | 96 ++
> ++---
> > 1 file changed, 83 insertions(+), 13 deletions(-)
> >
> > diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> > index 8bfde4d..4d0445f 100644
> > --- a/libavformat/dashdec.c
> > +++ b/libavformat/dashdec.c
> > @@ -149,6 +149,11 @@ typedef struct DASHContext {
> > char *allowed_extensions;
> > AVDictionary *avio_opts;
> > int max_url_size;
> > +
> > +/* Flags for init section*/
> > +int is_init_section_common_video;
> > +int is_init_section_common_audio;
> > +
> > } DASHContext;
> >
> > static int ishttp(char *url)
> > @@ -416,9 +421,9 @@ static int open_url(AVFormatContext *s, AVIOContext
> **pb, const char *url,
> > if (av_strstart(proto_name, "file", NULL)) {
> > if (strcmp(c->allowed_extensions, "ALL") && !av_match_ext(url,
> c->allowed_extensions)) {
> > av_log(s, AV_LOG_ERROR,
> > -"Filename extension of \'%s\' is not a common
> multimedia extension, blocked for security reasons.\n"
> > -"If you wish to override this adjust
> allowed_extensions, you can set it to \'ALL\' to allow all\n",
> > -url);
> > + "Filename extension of \'%s\' is not a common
> multimedia extension, blocked for security reasons.\n"
> > + "If you wish to override this adjust
> allowed_extensions, you can set it to \'ALL\' to allow all\n",
> > + url);
> > return AVERROR_INVALIDDATA;
> > }
> > } else if (av_strstart(proto_name, "http", NULL)) {
> > @@ -931,7 +936,7 @@ static int parse_manifest_representation(AVFormatContext
> *s, const char *url,
> > rep->last_seq_no =(int64_t) strtoll(val, NULL,
> 10) - 1;
> > xmlFree(val);
> > }
> > - }
> > +}
> > }
> >
> > fragment_timeline_node = find_child_node_by_name(
> representation_segmenttemplate_node, "SegmentTimeline");
> > @@ -1160,7 +1165,7 @@ static int parse_manifest(AVFormatContext *s,
> const char *url, AVIOContext *in)
> > } else {
> > LIBXML_TEST_VERSION
> >
> > -doc = xmlReadMemory(buffer, filesize, c->base_url, NULL, 0);
> > +doc = xmlReadMemory(buffer, filesize, c->base_url, NULL, 0);
> > root_element = xmlDocGetRootElement(doc);
> > node = root_element;
> >
> > @@ -1396,14 +1401,14 @@ static int refresh_manifest(AVFormatContext *s)
> >
> > if (c->n_videos != n_videos) {
> > av_log(c, AV_LOG_ERROR,
> > -"new manifest has mismatched no. of video representations,
> %d -> %d\n",
> > -n_videos, c->n_videos);
> > + "new manifest has mismatched no. of video
> representations, %d -> %d\n",
> > + n_videos, c->n_videos);
> > return AVERROR_INVALIDDATA;
> > }
> > if (c->n_audios != n_audios) {
> > av_log(c, AV_LOG_ERROR,
> > -"new manifest has mismatched no. of audio representations,
> %d -> %d\n",
> > -n_audios, c->n_audios);
> > + "new manifest has mismatched no. of audio
> representations, %d -> %d\n",
> > + n_audios, c->n_audios);
> > return AVERROR_INVALIDDATA;
> > }
> >
> > @@ -1862,6 +1867,45 @@ fail:
> > return ret;
> > }
> >
> > +static int init_section_compare_video(DASHContext *c)
> > +{
> > +int i = 0;
> > +char *url = c->videos[0]->init_section->url;
> > +int64_t url_offset = c->videos[0]->init_section->url_offset;
> > +int64_t size = c->videos[0]->init_section->size;
> > +for (i=0;in_videos;i++) {
> > +if (av_strcasecmp(c->videos[i]->init_section->url,url) ||
> c->videos[i]->init_section->url_offset != url_offset ||
> c->videos[i]->init_section->size != size) {
> > +return 0;
> > +}
> > +}
> > +return 1;
> > +}
> > +
> > +static int init_section_compare_audio(DASHContext *c)
> > +{
> > +int i = 0;
> > +char *url = c->audios[0]->init_section->url;
> > +int64_t url_offset = c->audios[0]->init_section->url_offset;
> > +int64_t size = c->audios[0]->init_section->size;
> > +for (i=0;in_audios;i++) {
> > +if (av_strcasecmp(c->audios[i]->init_section->url,url) ||
> c->audios[i]->init_section->url_offset != url_offset ||
> c->audios[i]->init_section->size != size) {
> > +return 0;
> > +}
> > +}
> > +return 1;
> > +}
> > +
> > +static void copy_init_section(struct representation *rep_dest, struct
> representation *rep_src)
> > +{
[FFmpeg-devel] [PATCH] avformat/hlsenc: add option hls_out_list_size
when use hls_list_size and hls_flags delete_segments, there will saving
hls_list_size * 2 +- segments, so this option can control the segments
numbers.
fix ticket: #7131
Signed-off-by: Steven Liu
---
doc/muxers.texi | 4
libavformat/hlsenc.c | 13 +
2 files changed, 17 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index cb75c261c5..21ef786bcf 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -513,6 +513,10 @@ Segment will be cut on the next key frame after this time
has passed.
Set the maximum number of playlist entries. If set to 0 the list file
will contain all the segments. Default value is 5.
+@item hls_out_list_size @var{size}
+Set the maximum number out of playlist entries. Default value is 1.
+This option should be used with @code{hls_flags delete_segments}.
+
@item hls_ts_options @var{options_list}
Set output format options using a :-separated list of key=value
parameters. Values containing @code{:} special characters must be
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 2a54b4342e..ff4c88d798 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -171,6 +171,7 @@ typedef struct HLSContext {
float time;// Set by a private option.
float init_time; // Set by a private option.
int max_nb_segments; // Set by a private option.
+int hls_out_list_size; // Set by a private option.
#if FF_API_HLS_WRAP
int wrap; // Set by a private option.
#endif
@@ -443,6 +444,7 @@ static int hls_delete_old_segments(AVFormatContext *s,
HLSContext *hls,
HLSSegment *segment, *previous_segment = NULL;
float playlist_duration = 0.0f;
int ret = 0, path_size, sub_path_size;
+int segment_cnt = 0;
char *dirname = NULL, *p, *sub_path;
char *path = NULL;
AVDictionary *options = NULL;
@@ -456,14 +458,24 @@ static int hls_delete_old_segments(AVFormatContext *s,
HLSContext *hls,
}
segment = vs->old_segments;
+segment_cnt = 0;
while (segment) {
playlist_duration -= segment->duration;
previous_segment = segment;
segment = previous_segment->next;
+segment_cnt++;
if (playlist_duration <= -previous_segment->duration) {
previous_segment->next = NULL;
break;
}
+
+if (!hls->hls_out_list_size) {
+av_log(s, AV_LOG_WARNING, "the hls_out_list_size value is 0,
that's wrong, so turn it to default value 1.\n");
+}
+if (segment_cnt >= hls->hls_out_list_size) {
+previous_segment->next = NULL;
+break;
+}
}
if (segment && !hls->use_localtime_mkdir) {
@@ -2779,6 +2791,7 @@ static const AVOption options[] = {
{"hls_time", "set segment length in seconds", OFFSET(time),
AV_OPT_TYPE_FLOAT, {.dbl = 2}, 0, FLT_MAX, E},
{"hls_init_time", "set segment length in seconds at init list",
OFFSET(init_time),AV_OPT_TYPE_FLOAT, {.dbl = 0}, 0, FLT_MAX, E},
{"hls_list_size", "set maximum number of playlist entries",
OFFSET(max_nb_segments),AV_OPT_TYPE_INT,{.i64 = 5}, 0, INT_MAX, E},
+{"hls_out_list_size", "set maximum number of out to playlist entries",
OFFSET(hls_out_list_size),AV_OPT_TYPE_INT,{.i64 = 1}, 0, INT_MAX,
E},
{"hls_ts_options","set hls mpegts list of options for the container format
used for hls", OFFSET(format_options_str), AV_OPT_TYPE_STRING, {.str = NULL},
0, 0,E},
{"hls_vtt_options","set hls vtt list of options for the container format
used for hls", OFFSET(vtt_format_options_str), AV_OPT_TYPE_STRING, {.str =
NULL}, 0, 0,E},
#if FF_API_HLS_WRAP
--
2.15.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding
I just tested this patch non packed to 16-bit gbrp12le DPX from DaVinci Resolve. Encoding to FFV1 and back again to DPX produced the same framemd5 values. Does any more testing need to happen before this can be merged? Best, Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding
On 4/10/18, Kieran O Leary wrote: > I just tested this patch non packed to 16-bit gbrp12le DPX from DaVinci > Resolve. Encoding to FFV1 and back again to DPX produced the same framemd5 > values. > > Does any more testing need to happen before this can be merged? > > Best, > > Kieran > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Does this patch decodes to gbrp12 pixel format? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding
2018-04-10 12:28 GMT+02:00, Kieran O Leary : > I just tested this patch non packed to 16-bit gbrp12le DPX from DaVinci > Resolve. Testing is good, apart from more brackets (and less comments) it would be better if Jerome sends his public keys to Michael and pushes the patch. > Encoding to FFV1 and back again to DPX produced the same > framemd5 values. (I believe we already discussed in public that testing FFmpeg's bugs with FFmpeg makes limited sense.) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding
2018-04-10 12:41 GMT+02:00, Paul B Mahol : > On 4/10/18, Kieran O Leary wrote: >> I just tested this patch non packed to 16-bit gbrp12le DPX from DaVinci >> Resolve. Encoding to FFV1 and back again to DPX produced the same framemd5 >> values. >> >> Does any more testing need to happen before this can be merged? > Does this patch decodes to gbrp12 pixel format? Looking at this block of the patch, it appears so: > +*dst[2]++ = read12in32(&buf, &rgbBuffer, > + &n_datum, endian); > +*dst[0]++ = read12in32(&buf, &rgbBuffer, > + &n_datum, endian); > +*dst[1]++ = read12in32(&buf, &rgbBuffer, > + &n_datum, endian); (Above are "& 0xFFF") Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding
Hi On Tue, Apr 10, 2018 at 11:34 AM, Carl Eugen Hoyos wrote: > 2018-04-10 12:28 GMT+02:00, Kieran O Leary : >> I just tested this patch non packed to 16-bit gbrp12le DPX from DaVinci >> Resolve. > > Testing is good, apart from more brackets (and less comments) it would > be better if Jerome sends his public keys to Michael and pushes the patch. > >> Encoding to FFV1 and back again to DPX produced the same >> framemd5 values. > > (I believe we already discussed in public that testing FFmpeg's bugs > with FFmpeg makes limited sense.) > Yes, and at the risk of making a fool of myself, here's some slightly different testing sing the graphicsmagick dpx encoder: The following console outputs have 4 steps: 1. Use gm convert to decode 12-bit DPX to 12-bit DPX (padded to 16-bit DPX) 2. Use ffmpeg convert to decode 12-bit DPX to 12-bit DPX (padded to 16-bit DPX) 3. Use ffmpeg to decode the graphicsmagick file with the md5 muxer 4. Use ffmpeg to decode the ffmpeg file with the md5 muxer The same md5 values are produced in steps 3 and 4- not sure what it proves exactly, maybe that even if the ffmpeg decoder is buggy, at least it decodes the files produced by Jerome's patch and the existing GM decoder in the same way? $ gm convert -verbose 6e0edc3b-7d89-4710-8b9a-66c8c990f9dc_1_00094787.dpx gm_dpx_to_dpx.dpx 6e0edc3b-7d89-4710-8b9a-66c8c990f9dc_1_00094787.dpx DPX 1600x1168+0+0 DirectClass 12-bit 8.0Mi 0.030u 0m:0.05s 6e0edc3b-7d89-4710-8b9a-66c8c990f9dc_1_00094787.dpx=>gm_dpx_to_dpx.dpx DPX 1600x1168+0+0 DirectClass 12-bit 10.7Mi 0.040u 0m:0.15s (11.9Mi pixels/s) $ ./ffmpeg -i 6e0edc3b-7d89-4710-8b9a-66c8c990f9dc_1_00094787.dpx ffmpeg_dpx_to_dpx.dpx ffmpeg version N-90642-gd64183e Copyright (c) 2000-2018 the FFmpeg developers built with Apple LLVM version 8.0.0 (clang-800.0.42.1) configuration: libavutil 56. 13.100 / 56. 13.100 libavcodec 58. 17.100 / 58. 17.100 libavformat58. 11.101 / 58. 11.101 libavdevice58. 2.100 / 58. 2.100 libavfilter 7. 14.100 / 7. 14.100 libswscale 5. 0.102 / 5. 0.102 libswresample 3. 0.101 / 3. 0.101 [dpx_pipe @ 0x7f80db809000] Stream #0: not enough frames to estimate rate; consider increasing probesize Input #0, dpx_pipe, from '6e0edc3b-7d89-4710-8b9a-66c8c990f9dc_1_00094787.dpx': Duration: N/A, bitrate: N/A Stream #0:0: Video: dpx, gbrp12le, 1600x1168 [SAR 1:1 DAR 100:73], 24 tbr, 25 tbn, 24 tbc Stream mapping: Stream #0:0 -> #0:0 (dpx (native) -> dpx (native)) Press [q] to stop, [?] for help Output #0, image2, to 'ffmpeg_dpx_to_dpx.dpx': Metadata: encoder : Lavf58.11.101 Stream #0:0: Video: dpx, gbrp12le, 1600x1168 [SAR 1:1 DAR 100:73], q=2-31, 200 kb/s, 24 fps, 24 tbn, 24 tbc Metadata: encoder : Lavc58.17.100 dpx frame=1 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A speed=0.286x video:10952kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown $ ./ffmpeg -i ffmpeg_dpx_to_dpx.dpx -f md5 - ffmpeg version N-90642-gd64183e Copyright (c) 2000-2018 the FFmpeg developers built with Apple LLVM version 8.0.0 (clang-800.0.42.1) configuration: libavutil 56. 13.100 / 56. 13.100 libavcodec 58. 17.100 / 58. 17.100 libavformat58. 11.101 / 58. 11.101 libavdevice58. 2.100 / 58. 2.100 libavfilter 7. 14.100 / 7. 14.100 libswscale 5. 0.102 / 5. 0.102 libswresample 3. 0.101 / 3. 0.101 [dpx_pipe @ 0x7ff76b009000] Stream #0: not enough frames to estimate rate; consider increasing probesize Input #0, dpx_pipe, from 'ffmpeg_dpx_to_dpx.dpx': Duration: N/A, bitrate: N/A Stream #0:0: Video: dpx, gbrp12le, 1600x1168 [SAR 1:1 DAR 100:73], 25 tbr, 25 tbn, 25 tbc Stream mapping: Stream #0:0 -> #0:0 (dpx (native) -> rawvideo (native)) Press [q] to stop, [?] for help Output #0, md5, to 'pipe:': Metadata: encoder : Lavf58.11.101 Stream #0:0: Video: rawvideo (G3[0][12] / 0xC003347), gbrp12le, 1600x1168 [SAR 1:1 DAR 100:73], q=2-31, 1681920 kb/s, 25 fps, 25 tbn, 25 tbc Metadata: encoder : Lavc58.17.100 rawvideo MD5=aa43e3ec1c2a8e4499b3bc796a35185b frame=1 fps=0.0 q=-0.0 Lsize= 0kB time=00:00:00.04 bitrate= 7.4kbits/s speed=1.25x video:10950kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown $ ./ffmpeg -i gm_dpx_to_dpx.dpx -f md5 - ffmpeg version N-90642-gd64183e Copyright (c) 2000-2018 the FFmpeg developers built with Apple LLVM version 8.0.0 (clang-800.0.42.1) configuration: libavutil 56. 13.100 / 56. 13.100 libavcodec 58. 17.100 / 58. 17.100 libavformat58. 11.101 / 58. 11.101 libavdevice58. 2.100 / 58. 2.100 libavfilter 7. 14.100 / 7. 14.100 libswscale 5. 0.102 / 5. 0.102 libswresample 3. 0.101 / 3. 0.101 [dpx_pipe @ 0x7fe9d2809000] Stream #0: not enough frames to estimate rate; consider increasing
Re: [FFmpeg-devel] avfilter/showvolume : add new options and minor clean
2018-03-31 16:21 GMT+02:00 Martin Vignali : > Hello, > > In attach new patchs for showvolume filter > > 001 : Move the clear picture part to a new func, and use it if fade option > == 0. > (no need to calculate it in float) > > 002/003 : Move "height" condition for draw volume at the start of the loop > and indent > > 004 : add a new option for choosing the display scale > currently, the filter use linear display, > most audio meter use some kind of log display > > > 005 : WIP : > The idea is to add an option to draw a line for the max level for a given > duration. > Several audio meter have this kind of display, and its help user, to check > peak level (even > if the "peak" happen during a very short time. > > I'm not entirely sure, this is the best way to add this. > > For now, i store the max value for each channel, update it, if a new peak > is bigger than the store value > And count the number of frame for display. If a given display duration is > exceed, update the max value to the current max value. > > Missing docs and probably code reorganization to reduce code duplication. > > I also have had very few inspiration for option naming and variable naming > (and i don't know the "official name" of this little line in audio meter). > So i'm open to better naming suggestion. > > This display need to be enable using dm=1 > and the duration during the max value is still display can be set with > dm_duration (in seconds) > > Ping for patch 004 and 005 Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] ffplay: Fix realloc_texture when input texture is NULL.
SDL_QueryTexture and SDL_DestroyTexture require that the input texture
pointer be non-null. Debug builds of SDL will correctly check for this
and break program execution. This patch fixes this by checking the
status of the texture pointer.
Signed-off-by: Matt Oliver
---
fftools/ffplay.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index bc9ddb8885..dcca9c26d8 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -834,10 +834,11 @@ static int realloc_texture(SDL_Texture **texture,
Uint32 new_format, int new_wid
{
Uint32 format;
int access, w, h;
-if (SDL_QueryTexture(*texture, &format, &access, &w, &h) < 0 ||
new_width != w || new_height != h || new_format != format) {
+if (!*texture || SDL_QueryTexture(*texture, &format, &access, &w, &h)
< 0 || new_width != w || new_height != h || new_format != format) {
void *pixels;
int pitch;
-SDL_DestroyTexture(*texture);
+if (*texture)
+SDL_DestroyTexture(*texture);
if (!(*texture = SDL_CreateTexture(renderer, new_format,
SDL_TEXTUREACCESS_STREAMING, new_width, new_height)))
return -1;
if (SDL_SetTextureBlendMode(*texture, blendmode) < 0)
--
ffplay-Fix-realloc_texture-when-input-texture-is-NUL.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding
Actually, here's another test that might be a bit more meaningful. This is using graphicksmagic and the identify/signature command in order to generate sha256 hashes for the image data only. It is producing identical hashes for: 1. The original 12-bit DPX from Da Vinci Resolve (not packed to 16-bit) 2. The graphicsmagick 12-bit DPX to 12-bit DPX (padded to 16-bit DPX) file 3. The ffmpeg convert 12-bit DPX to 12-bit DPX (padded to 16-bit DPX) which uses the ffmpeg decoder with Jerome's patch. $ gm identify -verbose 6e0edc3b-7d89-4710-8b9a-66c8c990f9dc_1_00094787.dpx |grep -i signature Signature: 3fb67059dca860c483b1deac912973b76d48fa9f0114d63e8116cff69d55bb4c $ gm identify -verbose gm_dpx_to_dpx.dpx |grep -i signature Signature: 3fb67059dca860c483b1deac912973b76d48fa9f0114d63e8116cff69d55bb4c $ gm identify -verbose ffmpeg_dpx_to_dpx.dpx |grep -i signature Signature: 3fb67059dca860c483b1deac912973b76d48fa9f0114d63e8116cff69d55bb4c Hopefully this is a bit better than just using ffmpeg? Best, Kieran. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/rawenc: check stream type
On 4/10/2018 4:49 AM, Michael Niedermayer wrote: To implement generic "codec supported" checks, muxers would have to list what they support. There are 3 ways i know how this can be done in the current API 1. the audio_codec / video_codec / ... fields 2. the codec_tag array (this was in fact IIRC one of the intended uses of it) 3. the querry_format callback These are raw single stream muxers - most only dump packets and _should_ accept exactly one codec_id. A couple may insert bitstream filters. Only one writes a trailer. So none of them have a codec_tag member or a query_codec callback. Personally, I agree that the current method is inelegant but these "muxers" are stable and these tests shouldn't need changes. But I can go the query_codec route if you advise it. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] lavf/aviobuf: add ff_get_chomp_line
On Tue, 10 Apr 2018, Jun Zhao wrote: Maybe you should use ff_read_line_to_bprint instead? It already chops the trailing line endings, not any whitespace though. Generally I think we should deprecate ff_get_line, because line length limits always pop here or there... Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding
On 4/10/18, Kieran O Leary wrote: > Actually, here's another test that might be a bit more meaningful. > This is using graphicksmagic and the identify/signature command in > order to generate sha256 hashes for the image data only. > > It is producing identical hashes for: > 1. The original 12-bit DPX from Da Vinci Resolve (not packed to 16-bit) > 2. The graphicsmagick 12-bit DPX to 12-bit DPX (padded to 16-bit DPX) file > 3. The ffmpeg convert 12-bit DPX to 12-bit DPX (padded to 16-bit DPX) > which uses the ffmpeg decoder with Jerome's patch. > > $ gm identify -verbose > 6e0edc3b-7d89-4710-8b9a-66c8c990f9dc_1_00094787.dpx |grep -i > signature > > Signature: > 3fb67059dca860c483b1deac912973b76d48fa9f0114d63e8116cff69d55bb4c > > $ gm identify -verbose gm_dpx_to_dpx.dpx |grep -i signature > > Signature: > 3fb67059dca860c483b1deac912973b76d48fa9f0114d63e8116cff69d55bb4c > > > $ gm identify -verbose ffmpeg_dpx_to_dpx.dpx |grep -i signature > > Signature: > 3fb67059dca860c483b1deac912973b76d48fa9f0114d63e8116cff69d55bb4c > > Hopefully this is a bit better than just using ffmpeg? No, you must not use tragic software ever. Besides ffmpeg also can give you checksums for image only. See framehash muxer, and it can give you sha512 hash. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding
On Tue, Apr 10, 2018 at 3:16 PM, Paul B Mahol wrote: > On 4/10/18, Kieran O Leary wrote: >> >> Hopefully this is a bit better than just using ffmpeg? > > No, you must not use tragic software ever. > > Besides ffmpeg also can give you checksums for image only. > See framehash muxer, and it can give you sha512 hash. Yes, I've used framehash but we use framemd5 internally in the Irish Film Institute. I was just using another DPX decoder as Carl is sceptical about using framemd5, or ffmpeg in general to determine losslessness of files created by ffmpeg. This was one of the only times I've ever used Image/GraphicsMagick to be honest. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: add option hls_out_list_size
On Tue, Apr 10, 2018 at 1:28 AM, Steven Liu wrote:
> when use hls_list_size and hls_flags delete_segments, there will saving
> hls_list_size * 2 +- segments, so this option can control the segments
> numbers.
>
> fix ticket: #7131
>
> Signed-off-by: Steven Liu
> ---
> doc/muxers.texi | 4
> libavformat/hlsenc.c | 13 +
> 2 files changed, 17 insertions(+)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index cb75c261c5..21ef786bcf 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -513,6 +513,10 @@ Segment will be cut on the next key frame after this
> time has passed.
> Set the maximum number of playlist entries. If set to 0 the list file
> will contain all the segments. Default value is 5.
>
> +@item hls_out_list_size @var{size}
> +Set the maximum number out of playlist entries. Default value is 1.
> +This option should be used with @code{hls_flags delete_segments}.
>
I don't understand why a new option is required. Why can't the value of
hls_list_size be re-used?
> +
> @item hls_ts_options @var{options_list}
> Set output format options using a :-separated list of key=value
> parameters. Values containing @code{:} special characters must be
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 2a54b4342e..ff4c88d798 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -171,6 +171,7 @@ typedef struct HLSContext {
> float time;// Set by a private option.
> float init_time; // Set by a private option.
> int max_nb_segments; // Set by a private option.
> +int hls_out_list_size; // Set by a private option.
> #if FF_API_HLS_WRAP
> int wrap; // Set by a private option.
> #endif
> @@ -443,6 +444,7 @@ static int hls_delete_old_segments(AVFormatContext
> *s, HLSContext *hls,
> HLSSegment *segment, *previous_segment = NULL;
> float playlist_duration = 0.0f;
> int ret = 0, path_size, sub_path_size;
> +int segment_cnt = 0;
> char *dirname = NULL, *p, *sub_path;
> char *path = NULL;
> AVDictionary *options = NULL;
> @@ -456,14 +458,24 @@ static int hls_delete_old_segments(AVFormatContext
> *s, HLSContext *hls,
> }
>
> segment = vs->old_segments;
> +segment_cnt = 0;
> while (segment) {
> playlist_duration -= segment->duration;
> previous_segment = segment;
> segment = previous_segment->next;
> +segment_cnt++;
> if (playlist_duration <= -previous_segment->duration) {
> previous_segment->next = NULL;
> break;
> }
> +
> +if (!hls->hls_out_list_size) {
> +av_log(s, AV_LOG_WARNING, "the hls_out_list_size value is 0,
> that's wrong, so turn it to default value 1.\n");
>
If 0 is invalid value, it should be disallowed instead of showing a warning.
> +}
> +if (segment_cnt >= hls->hls_out_list_size) {
> +previous_segment->next = NULL;
> +break;
> +}
> }
>
> if (segment && !hls->use_localtime_mkdir) {
> @@ -2779,6 +2791,7 @@ static const AVOption options[] = {
> {"hls_time", "set segment length in seconds",
> OFFSET(time),AV_OPT_TYPE_FLOAT, {.dbl = 2}, 0, FLT_MAX, E},
> {"hls_init_time", "set segment length in seconds at init list",
> OFFSET(init_time),AV_OPT_TYPE_FLOAT, {.dbl = 0}, 0, FLT_MAX,
> E},
> {"hls_list_size", "set maximum number of playlist entries",
> OFFSET(max_nb_segments),AV_OPT_TYPE_INT,{.i64 = 5}, 0, INT_MAX,
> E},
> +{"hls_out_list_size", "set maximum number of out to playlist
> entries", OFFSET(hls_out_list_size),AV_OPT_TYPE_INT,{.i64 = 1},
> 0, INT_MAX, E},
>
I think you can change this to 1, INT_MAX to disallow 0 values.
> {"hls_ts_options","set hls mpegts list of options for the container
> format used for hls", OFFSET(format_options_str), AV_OPT_TYPE_STRING, {.str
> = NULL}, 0, 0,E},
> {"hls_vtt_options","set hls vtt list of options for the container
> format used for hls", OFFSET(vtt_format_options_str), AV_OPT_TYPE_STRING,
> {.str = NULL}, 0, 0,E},
> #if FF_API_HLS_WRAP
> --
> 2.15.1
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: add option hls_out_list_size
2018.04.10. 17:41 keltezéssel, Aman Gupta írta:
On Tue, Apr 10, 2018 at 1:28 AM, Steven Liu wrote:
when use hls_list_size and hls_flags delete_segments, there will saving
hls_list_size * 2 +- segments, so this option can control the segments
numbers.
fix ticket: #7131
Signed-off-by: Steven Liu
---
doc/muxers.texi | 4
libavformat/hlsenc.c | 13 +
2 files changed, 17 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index cb75c261c5..21ef786bcf 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -513,6 +513,10 @@ Segment will be cut on the next key frame after this
time has passed.
Set the maximum number of playlist entries. If set to 0 the list file
will contain all the segments. Default value is 5.
+@item hls_out_list_size @var{size}
+Set the maximum number out of playlist entries. Default value is 1.
+This option should be used with @code{hls_flags delete_segments}.
I don't understand why a new option is required. Why can't the value of
hls_list_size be re-used?
as I understand this is a totally different option:
nb_existing_segments = hls_list_size + hls_out_list_size
currently:
nb_existing_segments = hls_list_size + 1
I think this is a usefull new option. e.g. when network speed is very
fluctuating and your client want to save all the segments.
+
@item hls_ts_options @var{options_list}
Set output format options using a :-separated list of key=value
parameters. Values containing @code{:} special characters must be
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 2a54b4342e..ff4c88d798 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -171,6 +171,7 @@ typedef struct HLSContext {
float time;// Set by a private option.
float init_time; // Set by a private option.
int max_nb_segments; // Set by a private option.
+int hls_out_list_size; // Set by a private option.
#if FF_API_HLS_WRAP
int wrap; // Set by a private option.
#endif
@@ -443,6 +444,7 @@ static int hls_delete_old_segments(AVFormatContext
*s, HLSContext *hls,
HLSSegment *segment, *previous_segment = NULL;
float playlist_duration = 0.0f;
int ret = 0, path_size, sub_path_size;
+int segment_cnt = 0;
char *dirname = NULL, *p, *sub_path;
char *path = NULL;
AVDictionary *options = NULL;
@@ -456,14 +458,24 @@ static int hls_delete_old_segments(AVFormatContext
*s, HLSContext *hls,
}
segment = vs->old_segments;
+segment_cnt = 0;
while (segment) {
playlist_duration -= segment->duration;
previous_segment = segment;
segment = previous_segment->next;
+segment_cnt++;
if (playlist_duration <= -previous_segment->duration) {
previous_segment->next = NULL;
break;
}
+
+if (!hls->hls_out_list_size) {
+av_log(s, AV_LOG_WARNING, "the hls_out_list_size value is 0,
that's wrong, so turn it to default value 1.\n");
If 0 is invalid value, it should be disallowed instead of showing a warning.
+}
+if (segment_cnt >= hls->hls_out_list_size) {
+previous_segment->next = NULL;
+break;
+}
}
if (segment && !hls->use_localtime_mkdir) {
@@ -2779,6 +2791,7 @@ static const AVOption options[] = {
{"hls_time", "set segment length in seconds",
OFFSET(time),AV_OPT_TYPE_FLOAT, {.dbl = 2}, 0, FLT_MAX, E},
{"hls_init_time", "set segment length in seconds at init list",
OFFSET(init_time),AV_OPT_TYPE_FLOAT, {.dbl = 0}, 0, FLT_MAX,
E},
{"hls_list_size", "set maximum number of playlist entries",
OFFSET(max_nb_segments),AV_OPT_TYPE_INT,{.i64 = 5}, 0, INT_MAX,
E},
+{"hls_out_list_size", "set maximum number of out to playlist
entries", OFFSET(hls_out_list_size),AV_OPT_TYPE_INT,{.i64 = 1},
0, INT_MAX, E},
I think you can change this to 1, INT_MAX to disallow 0 values.
{"hls_ts_options","set hls mpegts list of options for the container
format used for hls", OFFSET(format_options_str), AV_OPT_TYPE_STRING, {.str
= NULL}, 0, 0,E},
{"hls_vtt_options","set hls vtt list of options for the container
format used for hls", OFFSET(vtt_format_options_str), AV_OPT_TYPE_STRING,
{.str = NULL}, 0, 0,E},
#if FF_API_HLS_WRAP
--
2.15.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/mpegpicture: guard "stride changed" failures against unknown uvlinesize
From: Aman Gupta
Before adding uvlinesize check, I was seeing failures decoding
some samples (shown with extra logging added):
[mpeg2video @ 0x7fa193818c00] get_buffer() failed (stride changed:
linesize=1280/1280 uvlinesize=0/640)
[mpeg2video @ 0x7fa193818c00] get_buffer() failed (stride changed:
linesize=1280/1280 uvlinesize=0/640)
---
libavcodec/mpegpicture.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index 2be670cdbc..80898c161c 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -148,10 +148,13 @@ static int alloc_frame_buffer(AVCodecContext *avctx,
Picture *pic,
}
}
-if (linesize && (linesize != pic->f->linesize[0] ||
- uvlinesize != pic->f->linesize[1])) {
+if (linesize && uvlinesize &&
+(linesize != pic->f->linesize[0] ||
+ uvlinesize != pic->f->linesize[1])) {
av_log(avctx, AV_LOG_ERROR,
- "get_buffer() failed (stride changed)\n");
+ "get_buffer() failed (stride changed: linesize=%d/%d
uvlinesize=%d/%d)\n",
+ linesize, pic->f->linesize[0],
+ uvlinesize, pic->f->linesize[1]);
ff_mpeg_unref_picture(avctx, pic);
return -1;
}
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: add option hls_out_list_size
On Tue, Apr 10, 2018 at 9:49 AM, Bodecs Bela wrote:
>
>
> 2018.04.10. 17:41 keltezéssel, Aman Gupta írta:
>
>> On Tue, Apr 10, 2018 at 1:28 AM, Steven Liu wrote:
>>
>> when use hls_list_size and hls_flags delete_segments, there will saving
>>> hls_list_size * 2 +- segments, so this option can control the segments
>>> numbers.
>>>
>>> fix ticket: #7131
>>>
>>> Signed-off-by: Steven Liu
>>> ---
>>> doc/muxers.texi | 4
>>> libavformat/hlsenc.c | 13 +
>>> 2 files changed, 17 insertions(+)
>>>
>>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>>> index cb75c261c5..21ef786bcf 100644
>>> --- a/doc/muxers.texi
>>> +++ b/doc/muxers.texi
>>> @@ -513,6 +513,10 @@ Segment will be cut on the next key frame after this
>>> time has passed.
>>> Set the maximum number of playlist entries. If set to 0 the list file
>>> will contain all the segments. Default value is 5.
>>>
>>> +@item hls_out_list_size @var{size}
>>> +Set the maximum number out of playlist entries. Default value is 1.
>>> +This option should be used with @code{hls_flags delete_segments}.
>>>
>>> I don't understand why a new option is required. Why can't the value of
>> hls_list_size be re-used?
>>
> as I understand this is a totally different option:
> nb_existing_segments = hls_list_size + hls_out_list_size
> currently:
> nb_existing_segments = hls_list_size + 1
>
According to #7131, the current behavior is to keep hls_list_size*2 + 1
segments on disk.
>
> I think this is a usefull new option. e.g. when network speed is very
> fluctuating and your client want to save all the segments.
I don't follow.. if the m3u8 only advertises the last hls_list_size
segments, then why does keeping the older ones help? How would the client
even know they exist?
Aman
>
>
>
>>
>> +
>>> @item hls_ts_options @var{options_list}
>>> Set output format options using a :-separated list of key=value
>>> parameters. Values containing @code{:} special characters must be
>>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>>> index 2a54b4342e..ff4c88d798 100644
>>> --- a/libavformat/hlsenc.c
>>> +++ b/libavformat/hlsenc.c
>>> @@ -171,6 +171,7 @@ typedef struct HLSContext {
>>> float time;// Set by a private option.
>>> float init_time; // Set by a private option.
>>> int max_nb_segments; // Set by a private option.
>>> +int hls_out_list_size; // Set by a private option.
>>> #if FF_API_HLS_WRAP
>>> int wrap; // Set by a private option.
>>> #endif
>>> @@ -443,6 +444,7 @@ static int hls_delete_old_segments(AVFormatContext
>>> *s, HLSContext *hls,
>>> HLSSegment *segment, *previous_segment = NULL;
>>> float playlist_duration = 0.0f;
>>> int ret = 0, path_size, sub_path_size;
>>> +int segment_cnt = 0;
>>> char *dirname = NULL, *p, *sub_path;
>>> char *path = NULL;
>>> AVDictionary *options = NULL;
>>> @@ -456,14 +458,24 @@ static int hls_delete_old_segments(AVFormatContext
>>> *s, HLSContext *hls,
>>> }
>>>
>>> segment = vs->old_segments;
>>> +segment_cnt = 0;
>>> while (segment) {
>>> playlist_duration -= segment->duration;
>>> previous_segment = segment;
>>> segment = previous_segment->next;
>>> +segment_cnt++;
>>> if (playlist_duration <= -previous_segment->duration) {
>>> previous_segment->next = NULL;
>>> break;
>>> }
>>> +
>>> +if (!hls->hls_out_list_size) {
>>> +av_log(s, AV_LOG_WARNING, "the hls_out_list_size value is 0,
>>> that's wrong, so turn it to default value 1.\n");
>>>
>>> If 0 is invalid value, it should be disallowed instead of showing a
>> warning.
>>
>>
>> +}
>>> +if (segment_cnt >= hls->hls_out_list_size) {
>>> +previous_segment->next = NULL;
>>> +break;
>>> +}
>>> }
>>>
>>> if (segment && !hls->use_localtime_mkdir) {
>>> @@ -2779,6 +2791,7 @@ static const AVOption options[] = {
>>> {"hls_time", "set segment length in seconds",
>>> OFFSET(time),AV_OPT_TYPE_FLOAT, {.dbl = 2}, 0, FLT_MAX, E},
>>> {"hls_init_time", "set segment length in seconds at init list",
>>> OFFSET(init_time),AV_OPT_TYPE_FLOAT, {.dbl = 0}, 0,
>>> FLT_MAX,
>>> E},
>>> {"hls_list_size", "set maximum number of playlist entries",
>>> OFFSET(max_nb_segments),AV_OPT_TYPE_INT,{.i64 = 5}, 0,
>>> INT_MAX,
>>> E},
>>> +{"hls_out_list_size", "set maximum number of out to playlist
>>> entries", OFFSET(hls_out_list_size),AV_OPT_TYPE_INT,{.i64 = 1},
>>> 0, INT_MAX, E},
>>>
>>> I think you can change this to 1, INT_MAX to disallow 0 values.
>>
>>
>> {"hls_ts_options","set hls mpegts list of options for the container
>>> format used for hls", OFFSET(format_options_str), AV_OPT_TYPE_STRING,
>>> {.str
>>> = NULL}, 0, 0,E},
>>> {"hls_vtt_options","set hls vtt list of options for
Re: [FFmpeg-devel] backport request: AV_PKT_FLAG_DISPOSABLE
On Monday, 09 April 2018 at 14:29, Carl Eugen Hoyos wrote: > 2018-04-09 14:25 GMT+02:00, Dominik 'Rathann' Mierzejewski > : > > Hello, > > could someone backport these commits: > > 00d454ed2ca3f8b4d454a837e95931afe604c53f > > 79a744768aa6f498e4f46fca4ff01cd04eade9a5 > > to 3.4 and 3.3 branches? > > This is an API change, we try not to backport > such changes. Understood, thank you. Regards, Dominik -- Fedora https://getfedora.org | RPMFusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: add option hls_out_list_size
2018.04.10. 19:23 keltezéssel, Aman Gupta írta:
On Tue, Apr 10, 2018 at 9:49 AM, Bodecs Bela wrote:
2018.04.10. 17:41 keltezéssel, Aman Gupta írta:
On Tue, Apr 10, 2018 at 1:28 AM, Steven Liu wrote:
when use hls_list_size and hls_flags delete_segments, there will saving
hls_list_size * 2 +- segments, so this option can control the segments
numbers.
fix ticket: #7131
Signed-off-by: Steven Liu
---
doc/muxers.texi | 4
libavformat/hlsenc.c | 13 +
2 files changed, 17 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index cb75c261c5..21ef786bcf 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -513,6 +513,10 @@ Segment will be cut on the next key frame after this
time has passed.
Set the maximum number of playlist entries. If set to 0 the list file
will contain all the segments. Default value is 5.
+@item hls_out_list_size @var{size}
+Set the maximum number out of playlist entries. Default value is 1.
+This option should be used with @code{hls_flags delete_segments}.
I don't understand why a new option is required. Why can't the value of
hls_list_size be re-used?
as I understand this is a totally different option:
nb_existing_segments = hls_list_size + hls_out_list_size
currently:
nb_existing_segments = hls_list_size + 1
According to #7131, the current behavior is to keep hls_list_size*2 + 1
segments on disk.
sorry, you are right.
I think this is a usefull new option. e.g. when network speed is very
fluctuating and your client want to save all the segments.
I don't follow.. if the m3u8 only advertises the last hls_list_size
segments, then why does keeping the older ones help? How would the client
even know they exist?
a currently joining client of course won't be aware about the earlier
but still available segments,
but a client, joinig eearlier and continouosly following m3u8 but
temporarily having slower than realtime net connection speed
may have benefit to successfully download these earlier segments.
it is not so usefull when realtime displaying the live stream, but it is
usefull if you archive the live stream.
bb
Aman
+
@item hls_ts_options @var{options_list}
Set output format options using a :-separated list of key=value
parameters. Values containing @code{:} special characters must be
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 2a54b4342e..ff4c88d798 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -171,6 +171,7 @@ typedef struct HLSContext {
float time;// Set by a private option.
float init_time; // Set by a private option.
int max_nb_segments; // Set by a private option.
+int hls_out_list_size; // Set by a private option.
#if FF_API_HLS_WRAP
int wrap; // Set by a private option.
#endif
@@ -443,6 +444,7 @@ static int hls_delete_old_segments(AVFormatContext
*s, HLSContext *hls,
HLSSegment *segment, *previous_segment = NULL;
float playlist_duration = 0.0f;
int ret = 0, path_size, sub_path_size;
+int segment_cnt = 0;
char *dirname = NULL, *p, *sub_path;
char *path = NULL;
AVDictionary *options = NULL;
@@ -456,14 +458,24 @@ static int hls_delete_old_segments(AVFormatContext
*s, HLSContext *hls,
}
segment = vs->old_segments;
+segment_cnt = 0;
while (segment) {
playlist_duration -= segment->duration;
previous_segment = segment;
segment = previous_segment->next;
+segment_cnt++;
if (playlist_duration <= -previous_segment->duration) {
previous_segment->next = NULL;
break;
}
+
+if (!hls->hls_out_list_size) {
+av_log(s, AV_LOG_WARNING, "the hls_out_list_size value is 0,
that's wrong, so turn it to default value 1.\n");
If 0 is invalid value, it should be disallowed instead of showing a
warning.
+}
+if (segment_cnt >= hls->hls_out_list_size) {
+previous_segment->next = NULL;
+break;
+}
}
if (segment && !hls->use_localtime_mkdir) {
@@ -2779,6 +2791,7 @@ static const AVOption options[] = {
{"hls_time", "set segment length in seconds",
OFFSET(time),AV_OPT_TYPE_FLOAT, {.dbl = 2}, 0, FLT_MAX, E},
{"hls_init_time", "set segment length in seconds at init list",
OFFSET(init_time),AV_OPT_TYPE_FLOAT, {.dbl = 0}, 0,
FLT_MAX,
E},
{"hls_list_size", "set maximum number of playlist entries",
OFFSET(max_nb_segments),AV_OPT_TYPE_INT,{.i64 = 5}, 0,
INT_MAX,
E},
+{"hls_out_list_size", "set maximum number of out to playlist
entries", OFFSET(hls_out_list_size),AV_OPT_TYPE_INT,{.i64 = 1},
0, INT_MAX, E},
I think you can change this to 1, INT_MAX to disallow 0 values.
{"hls_ts_options","set hls mpegts list of options for the container
format used for hls", OFFSET(format_options_str), AV_
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: add option hls_out_list_size
On Tue, Apr 10, 2018 at 10:36 AM, Bodecs Bela wrote:
>
>
> 2018.04.10. 19:23 keltezéssel, Aman Gupta írta:
>
>> On Tue, Apr 10, 2018 at 9:49 AM, Bodecs Bela wrote:
>>
>>
>>> 2018.04.10. 17:41 keltezéssel, Aman Gupta írta:
>>>
>>> On Tue, Apr 10, 2018 at 1:28 AM, Steven Liu wrote:
when use hls_list_size and hls_flags delete_segments, there will saving
> hls_list_size * 2 +- segments, so this option can control the segments
> numbers.
>
> fix ticket: #7131
>
> Signed-off-by: Steven Liu
> ---
>doc/muxers.texi | 4
>libavformat/hlsenc.c | 13 +
>2 files changed, 17 insertions(+)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index cb75c261c5..21ef786bcf 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -513,6 +513,10 @@ Segment will be cut on the next key frame after
> this
> time has passed.
>Set the maximum number of playlist entries. If set to 0 the list
> file
>will contain all the segments. Default value is 5.
>
> +@item hls_out_list_size @var{size}
> +Set the maximum number out of playlist entries. Default value is 1.
> +This option should be used with @code{hls_flags delete_segments}.
>
> I don't understand why a new option is required. Why can't the value of
>
hls_list_size be re-used?
as I understand this is a totally different option:
>>> nb_existing_segments = hls_list_size + hls_out_list_size
>>> currently:
>>> nb_existing_segments = hls_list_size + 1
>>>
>>> According to #7131, the current behavior is to keep hls_list_size*2 + 1
>> segments on disk.
>>
> sorry, you are right.
>
>>
>> I think this is a usefull new option. e.g. when network speed is very
>>> fluctuating and your client want to save all the segments.
>>>
>>
>> I don't follow.. if the m3u8 only advertises the last hls_list_size
>> segments, then why does keeping the older ones help? How would the client
>> even know they exist?
>>
> a currently joining client of course won't be aware about the earlier but
> still available segments,
> but a client, joinig eearlier and continouosly following m3u8 but
> temporarily having slower than realtime net connection speed
> may have benefit to successfully download these earlier segments.
>
Okay I understand now. You're right, this is a valid use-case. Thanks for
the clarification.
Aman
>
> it is not so usefull when realtime displaying the live stream, but it is
> usefull if you archive the live stream.
>
> bb
>
>
>
>> Aman
>>
>>
>>
>>>
>>> +
>@item hls_ts_options @var{options_list}
>Set output format options using a :-separated list of key=value
>parameters. Values containing @code{:} special characters must be
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 2a54b4342e..ff4c88d798 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -171,6 +171,7 @@ typedef struct HLSContext {
>float time;// Set by a private option.
>float init_time; // Set by a private option.
>int max_nb_segments; // Set by a private option.
> +int hls_out_list_size; // Set by a private option.
>#if FF_API_HLS_WRAP
>int wrap; // Set by a private option.
>#endif
> @@ -443,6 +444,7 @@ static int hls_delete_old_segments(AVFormatContext
> *s, HLSContext *hls,
>HLSSegment *segment, *previous_segment = NULL;
>float playlist_duration = 0.0f;
>int ret = 0, path_size, sub_path_size;
> +int segment_cnt = 0;
>char *dirname = NULL, *p, *sub_path;
>char *path = NULL;
>AVDictionary *options = NULL;
> @@ -456,14 +458,24 @@ static int hls_delete_old_segments(AVForm
> atContext
> *s, HLSContext *hls,
>}
>
>segment = vs->old_segments;
> +segment_cnt = 0;
>while (segment) {
>playlist_duration -= segment->duration;
>previous_segment = segment;
>segment = previous_segment->next;
> +segment_cnt++;
>if (playlist_duration <= -previous_segment->duration) {
>previous_segment->next = NULL;
>break;
>}
> +
> +if (!hls->hls_out_list_size) {
> +av_log(s, AV_LOG_WARNING, "the hls_out_list_size value is
> 0,
> that's wrong, so turn it to default value 1.\n");
>
> If 0 is invalid value, it should be disallowed instead of showing a
>
warning.
+}
> +if (segment_cnt >= hls->hls_out_list_size) {
> +previous_segment->next = NULL;
> +break;
> +}
>}
>
>if (segment && !hls->use_localtime_mkdir) {
> @@ -2779,6 +2791,7 @@ static const
[FFmpeg-devel] [PATCH] avformat/hls: clean up duplicate option fields
From: Richard Shaffer
The HLSContext struct contains fields which duplicate the data stored in the
avio_opts field. This change removes those fields in favor of avio_opts, and
updates the code accordingly.
---
libavformat/hls.c | 74 +++
1 file changed, 9 insertions(+), 65 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index ef731c27ac..d5563e76b1 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -202,11 +202,6 @@ typedef struct HLSContext {
int64_t first_timestamp;
int64_t cur_timestamp;
AVIOInterruptCB *interrupt_callback;
-char *referer; ///< holds HTTP referer set as an
AVOption to the HTTP protocol context
-char *user_agent;///< holds HTTP user agent set as an
AVOption to the HTTP protocol context
-char *cookies; ///< holds HTTP cookie values set in
either the initial response or as an AVOption to the HTTP protocol context
-char *headers; ///< holds HTTP headers set as an
AVOption to the HTTP protocol context
-char *http_proxy;///< holds the address of the HTTP
proxy server
AVDictionary *avio_opts;
int strict_std_compliance;
char *allowed_extensions;
@@ -275,10 +270,6 @@ static void free_playlist_list(HLSContext *c)
av_free(pls);
}
av_freep(&c->playlists);
-av_freep(&c->cookies);
-av_freep(&c->user_agent);
-av_freep(&c->headers);
-av_freep(&c->http_proxy);
c->n_playlists = 0;
}
@@ -601,14 +592,6 @@ static int ensure_playlist(HLSContext *c, struct playlist
**pls, const char *url
return 0;
}
-static void update_options(char **dest, const char *name, void *src)
-{
-av_freep(dest);
-av_opt_get(src, name, AV_OPT_SEARCH_CHILDREN, (uint8_t**)dest);
-if (*dest && !strlen(*dest))
-av_freep(dest);
-}
-
static int open_url_keepalive(AVFormatContext *s, AVIOContext **pb,
const char *url)
{
@@ -692,12 +675,8 @@ static int open_url(AVFormatContext *s, AVIOContext **pb,
const char *url,
if (!(s->flags & AVFMT_FLAG_CUSTOM_IO))
av_opt_get(*pb, "cookies", AV_OPT_SEARCH_CHILDREN,
(uint8_t**)&new_cookies);
-if (new_cookies) {
-av_free(c->cookies);
-c->cookies = new_cookies;
-}
-
-av_dict_set(&opts, "cookies", c->cookies, 0);
+if (new_cookies)
+av_dict_set(&opts, "cookies", new_cookies, 0);
}
av_dict_free(&tmp);
@@ -744,14 +723,7 @@ static int parse_playlist(HLSContext *c, const char *url,
if (!in) {
AVDictionary *opts = NULL;
-/* Some HLS servers don't like being sent the range header */
-av_dict_set(&opts, "seekable", "0", 0);
-
-// broker prior HTTP options that should be consistent across requests
-av_dict_set(&opts, "user_agent", c->user_agent, 0);
-av_dict_set(&opts, "cookies", c->cookies, 0);
-av_dict_set(&opts, "headers", c->headers, 0);
-av_dict_set(&opts, "http_proxy", c->http_proxy, 0);
+av_dict_copy(&opts, c->avio_opts, 0);
if (c->http_persistent)
av_dict_set(&opts, "multiple_requests", "1", 0);
@@ -1177,14 +1149,6 @@ static int open_input(HLSContext *c, struct playlist
*pls, struct segment *seg,
int ret;
int is_http = 0;
-// broker prior HTTP options that should be consistent across requests
-av_dict_set(&opts, "user_agent", c->user_agent, 0);
-av_dict_set(&opts, "referer", c->referer, 0);
-av_dict_set(&opts, "cookies", c->cookies, 0);
-av_dict_set(&opts, "headers", c->headers, 0);
-av_dict_set(&opts, "http_proxy", c->http_proxy, 0);
-av_dict_set(&opts, "seekable", "0", 0);
-
if (c->http_persistent)
av_dict_set(&opts, "multiple_requests", "1", 0);
@@ -1201,7 +1165,6 @@ static int open_input(HLSContext *c, struct playlist
*pls, struct segment *seg,
if (seg->key_type == KEY_NONE) {
ret = open_url(pls->parent, in, seg->url, c->avio_opts, opts,
&is_http);
} else if (seg->key_type == KEY_AES_128) {
-AVDictionary *opts2 = NULL;
char iv[33], key[33], url[MAX_URL_SIZE];
if (strcmp(seg->key, pls->key_url)) {
AVIOContext *pb = NULL;
@@ -1226,14 +1189,10 @@ static int open_input(HLSContext *c, struct playlist
*pls, struct segment *seg,
else
snprintf(url, sizeof(url), "crypto:%s", seg->url);
-av_dict_copy(&opts2, c->avio_opts, 0);
-av_dict_set(&opts2, "key", key, 0);
-av_dict_set(&opts2, "iv", iv, 0);
-
-ret = open_url(pls->parent, in, url, opts2, opts, &is_http);
-
-av_dict_free(&opts2);
+av_dict_set(&opts, "key", key, 0);
+av_dict_set(&opts, "iv", iv, 0);
+ret = open_url(pls->parent, in, url, c->avio_opts, opts, &is_http);
if (ret < 0) {
goto clea
Re: [FFmpeg-devel] [PATCH] avformat/hls: copy rw_timeout from parent to child AVIOContexts.
On Tue, Apr 3, 2018 at 5:11 PM, Steven Liu wrote: > 2018-04-04 7:53 GMT+08:00 Steven Liu : > >>> > >>> Look at the code: > >>> > >>> 205 char *referer; ///< holds HTTP referer > set > >>> as an AVOption to the HTTP protocol context > >>> 206 char *user_agent;///< holds HTTP user > agent > >>> set as an AVOption to the HTTP protocol context > >>> 207 char *cookies; ///< holds HTTP cookie > >>> values set in either the initial response or as an AVOption to the HTTP > >>> protocol context > >>> 208 char *headers; ///< holds HTTP headers > set > >>> as an AVOption to the HTTP protocol context > >>> 209 char *http_proxy;///< holds the address of > >>> the HTTP proxy server > >>> > >>> There have some comment for the options. > >>> and reference the code in: hls_read_header / open_input and use the > >>> options. > >>> > >>> > >> That's pretty clear. What I was asking is why the options are stored > both > >> in these fields as well as avio_opts, and this doesn't answer my > question. > >> I was also asking why you object to storing the timeout option in > >> avio_opts, but I'm not understanding the logic in your responses. > > > > no logic problem, just that option be used to HTTP, is that ok? > This is a logic problem for me, because I'm not understanding your logic. What is the reason that avio_opts should only be used for HTTP options? > > > > BTW, how should i reproduce the problem you said? > If you pass the rw_timeout option to either the command-line or to avformat_open_input, it will be applied only to the URL passed on the command line or to the function. When the HLS demuxer tries to open other URLs, such as keying URIs, media playlists or segments, it will not apply the rw_timeout option. As a result, if we fail to receive data from the remote server, it can block the process instead of returning the expected AVERROR(ETIMEDOUT) error. > > > > " > > The rw_timeout option is currently not applied when opening media > playlist, > > segment, or encryption key URLs. This can cause the HLS demuxer to block > > indefinitely, even when the rw_timeout option has been specified. This > change > > simply enables carrying over the rw_timeout option when the demuxer > opens these > > URLs. > > " > > So i think add option timeout to do it maybe better than this way. you > can find another formats do it like this. > I think the HLS demuxer is pretty unique. Except for dash, I don't know which other demuxers have to open additional avio to do their work. If there is an example you can show me that illustrates your point, that would be appreciated. > > > >> > >> > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Hi Steven, I apologize for the late response. I have been traveling. I understand that you might be busy, and that English is not everyone's first language. However, if you could take the time to give a more thorough response, I'd really appreciate it. It's a little bit frustrating for me: I'm asking why avio_opts needs to be restricted to HTTP options, and the answer I seem to keep getting back is "because it's for HTTP options." That answer isn't very satisfying, and doesn't help me understand /why/ you think it should only be used for HTTP options. It may be that you have a good reason, but if I can't understand what it is, I'm not going to be able to provide a better fix. I can't force anyone to accept my changes or provide more detailed feedback. However, if we can't understand each other, then at some point I will have to give up. I'll apply a patch that fixes my problem to a local fork of ffmpeg. Other people outside of my company won't benefit from the fix. My company will also have to maintain our own copy of ffmpeg. This could make it less likely for us to share our changes with the community, and it will also make it harder for us to benefit from improvements and fixes to ffmpeg. I don't want to do that, because nobody wins in that scenario. That is why I'm asking for your help to understand your objection and suggestion. Thanks, -Richard ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding
On 10/04/2018 12:34, Carl Eugen Hoyos wrote:
2018-04-10 12:28 GMT+02:00, Kieran O Leary :
I just tested this patch non packed to 16-bit gbrp12le DPX from DaVinci
Resolve.
Testing is good, apart
I thought the patch was "technically" OK, as I answered to all change
requests and there was no additional feedback IIRC.
from more brackets
Not sure I understand, as the only "missing" brackets I see are for the
1 line code after a "if", and I see that 1 line code has no brackets in
other parts of the file.
Anyway, I added more brackets, except for "if (*n_datum) (*n_datum)--;"
as I copied/pasted it from another part of the file.
Did I miss something else?
(and less comments)
I thought it would be better for someone willing to add alpha support in
the future, as the alpha support was tested and "just" rejected for the
moment.
Anyway, I removed the commented code.
Modified patch attached.
Note that I personally prefer to use the previous patch (or this patch
without the additional brackets).
it would
be better if Jerome sends his public keys to Michael and pushes the patch.
If it is the only solution for having the patch pushed, I'll do that,
even if I am not convinced that I deserve for the moment write rights on
FFmpeg repository (especially because Git and me are not good friends :) ).
Jérôme
From 02286a07f920b8d15bf5f031a21fc9080fc4fa32 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?=
Date: Tue, 10 Apr 2018 18:20:23 +0200
Subject: [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding
Limited to widths multiple of 8 (RGB) due to lack of test files for such corner
case
This partially fixes ticket #5639
---
libavcodec/dpx.c | 67 +---
1 file changed, 64 insertions(+), 3 deletions(-)
diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 1aa2cbd1c8..026fb10e90 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -65,6 +65,38 @@ static uint16_t read10in32(const uint8_t **ptr, uint32_t *
lbuf,
return *lbuf & 0x3FF;
}
+static uint16_t read12in32(const uint8_t **ptr, uint32_t * lbuf,
+ int * n_datum, int is_big)
+{
+if (*n_datum)
+(*n_datum)--;
+else {
+*lbuf = read32(ptr, is_big);
+*n_datum = 7;
+}
+
+switch (*n_datum){
+case 7: return *lbuf & 0xFFF;
+case 6: return (*lbuf >> 12) & 0xFFF;
+case 5: {
+uint32_t c = *lbuf >> 24;
+*lbuf = read32(ptr, is_big);
+c |= *lbuf << 8;
+return c & 0xFFF;
+}
+case 4: return (*lbuf >> 4) & 0xFFF;
+case 3: return (*lbuf >> 16) & 0xFFF;
+case 2: {
+uint32_t c = *lbuf >> 28;
+*lbuf = read32(ptr, is_big);
+c |= *lbuf << 4;
+return c & 0xFFF;
+}
+case 1: return (*lbuf >> 8) & 0xFFF;
+default: return *lbuf >> 20;
+}
+}
+
static int decode_frame(AVCodecContext *avctx,
void *data,
int *got_frame,
@@ -201,10 +233,27 @@ static int decode_frame(AVCodecContext *avctx,
break;
case 12:
if (!packing) {
-av_log(avctx, AV_LOG_ERROR, "Packing to 16bit required\n");
-return -1;
+int tested = 0;
+if (descriptor == 50 && endian && (avctx->width%8) == 0) { //
Little endian and widths not a multiple of 8 need tests
+tested = 1;
+}
+if (!tested) {
+av_log(avctx, AV_LOG_ERROR, "Packing to 16bit required\n");
+return -1;
+}
+}
+stride = avctx->width * elements;
+if (packing) {
+stride *= 2;
+} else {
+stride *= 3;
+if (stride % 8) {
+stride /= 8;
+stride++;
+stride *= 8;
+}
+stride /= 2;
}
-stride = 2 * avctx->width * elements;
break;
case 16:
stride = 2 * avctx->width * elements;
@@ -349,6 +398,7 @@ static int decode_frame(AVCodecContext *avctx,
(uint16_t*)ptr[2],
(uint16_t*)ptr[3]};
for (y = 0; y < avctx->width; y++) {
+if (packing) {
if (elements >= 3)
*dst[2]++ = read16(&buf, endian) >> 4;
*dst[0] = read16(&buf, endian) >> 4;
@@ -357,6 +407,17 @@ static int decode_frame(AVCodecContext *avctx,
*dst[1]++ = read16(&buf, endian) >> 4;
if (elements == 4)
*dst[3]++ = read16(&buf, endian) >> 4;
+} else {
+*dst[2]++ = read12in32(&buf, &rgbBuffer,
+ &n_datum, endian);
+*dst[0]++ = read12in32(&buf, &rgbBuffer,
+ &n_datum, endian);
+
Re: [FFmpeg-devel] [PATCH] avformat/movenc: use correct iTunes copyright atom
On Tue, 3 Apr 2018 09:05:18 +0300 Timo Teräs wrote: > Support for writing copyright metadata was added in commit bed4fc54c9 > for 3GP, MOV and iTunes metadata. 3GP and MOV cases are formally > specified. However, iTunes format does not have specification, and > it seems to have been assumed that it would use the same atom as > MOV (both being Apple formats). >[snip] Ping? It's been 2 weeks since the original mail + inquiry. And one week since this. What's the usual time for waiting feedback? Would this be soon good to go in? Timo > diff --git a/libavformat/movenc.c b/libavformat/movenc.c > index 97327f739d..54f19c3a73 100644 > --- a/libavformat/movenc.c > +++ b/libavformat/movenc.c > @@ -3484,7 +3484,7 @@ static int mov_write_ilst_tag(AVIOContext *pb, > MOVMuxContext *mov, } > mov_write_string_metadata(s, pb, "\251cmt", "comment" , 1); > mov_write_string_metadata(s, pb, "\251gen", "genre", 1); > -mov_write_string_metadata(s, pb, "\251cpy", "copyright", 1); > +mov_write_string_metadata(s, pb, "cprt","copyright", 1); > mov_write_string_metadata(s, pb, "\251grp", "grouping" , 1); > mov_write_string_metadata(s, pb, "\251lyr", "lyrics" , 1); > mov_write_string_metadata(s, pb, "desc","description",1); ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] doc: update loglevel option documentation
On Mon, Apr 9, 2018, at 10:59 PM, Tobias Rapp wrote:
>
> +For example to enable repeated log output and set @var{loglevel} to
> +@code{verbose}:
> +@example
> +ffmpeg -loglevel repeat+verbose -i input output
> +@end example
Just to show all current flags and the loglevel I prefer:
For example to enable repeated log output, add the @code{level} prefix, and set
@var{loglevel} to
@code{verbose}:
@example
ffmpeg -loglevel repeat+level+verbose -i input output
@end example
> +Another example that disables the @code{level} prefix without affecting the
> +current state of @code{repeat} flag or @var{loglevel}:
> +@example
> +ffmpeg [...] -loglevel -level
> +@end example
I'm not sure how useful this example is. Sure, it displays how to use "-", but
is there an actual use case for using "-loglevel -level" since the level prefix
is not shown by default anyway?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/6] reitnerlace - tinterlace-like filter under LGPL
Hello,
This is the first part of the first patch. I added interlace options to
tinterlace. On the next patch I will delete vf_interlace.
Thank you,
Vasile Toncu
From b2be4e949e071f9017d8a9d6fbd1fbb56505ac50 Mon Sep 17 00:00:00 2001
From: Vasile Toncu
Date: Tue, 10 Apr 2018 23:28:32 +0300
Subject: [PATCH] Added interlace options to tinterlace
---
libavfilter/Makefile | 2 +-
libavfilter/vf_tinterlace.c | 9 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index a90ca30..586d9c7 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -231,7 +231,7 @@ OBJS-$(CONFIG_HYSTERESIS_FILTER) += vf_hysteresis.o
framesync.o
OBJS-$(CONFIG_IDET_FILTER) += vf_idet.o
OBJS-$(CONFIG_IL_FILTER) += vf_il.o
OBJS-$(CONFIG_INFLATE_FILTER) += vf_neighbor.o
-OBJS-$(CONFIG_INTERLACE_FILTER) += vf_interlace.o
+OBJS-$(CONFIG_INTERLACE_FILTER) += vf_tinterlace.o
OBJS-$(CONFIG_INTERLEAVE_FILTER) += f_interleave.o
OBJS-$(CONFIG_KERNDEINT_FILTER) += vf_kerndeint.o
OBJS-$(CONFIG_LENSCORRECTION_FILTER) += vf_lenscorrection.o
diff --git a/libavfilter/vf_tinterlace.c b/libavfilter/vf_tinterlace.c
index f13791d..5bf384d 100644
--- a/libavfilter/vf_tinterlace.c
+++ b/libavfilter/vf_tinterlace.c
@@ -53,6 +53,15 @@ static const AVOption tinterlace_options[] = {
{"complex_filter", "enable complex vertical low-pass
filter", 0, AV_OPT_TYPE_CONST, {.i64 =
TINTERLACE_FLAG_CVLPF},INT_MIN, INT_MAX, FLAGS, "flags" },
{"cvlpf", "enable complex vertical low-pass
filter", 0, AV_OPT_TYPE_CONST, {.i64 =
TINTERLACE_FLAG_CVLPF},INT_MIN, INT_MAX, FLAGS, "flags" },
{"exact_tb", "force a timebase which can represent
timestamps exactly", 0, AV_OPT_TYPE_CONST, {.i64 =
TINTERLACE_FLAG_EXACT_TB}, INT_MIN, INT_MAX, FLAGS, "flags" },
+
+ {"scan", "scanning
mode", 0, AV_OPT_TYPE_CONST, {.i64 =
MODE_INTERLEAVE_TOP}, INT_MIN, INT_MAX, FLAGS, "mode"},
+ {"tff", "top field
first", 0, AV_OPT_TYPE_CONST, {.i64 =
MODE_INTERLEAVE_TOP}, INT_MIN, INT_MAX, FLAGS, "mode"},
+ {"bff", "bottom field
first", 0, AV_OPT_TYPE_CONST, {.i64 =
MODE_INTERLEAVE_BOTTOM}, INT_MIN, INT_MAX, FLAGS, "mode"},
+
+ {"lowpass", "set vertical low-pass
filter", 0, AV_OPT_TYPE_CONST, {.i64 =
TINTERLACE_FLAG_VLPF}, INT_MIN, INT_MAX, FLAGS, "flags"},
+ {"off", "disable low-pass
filter", 0, AV_OPT_TYPE_CONST, {.i64 =
0}, INT_MIN, INT_MAX, FLAGS, "flags" },
+ {"linear", "linear vertical low-pass
filter", 0, AV_OPT_TYPE_CONST, {.i64 =
TINTERLACE_FLAG_VLPF}, INT_MIN, INT_MAX, FLAGS, "flags" },
+ {"complex", "complex vertical low-pass
filter", 0, AV_OPT_TYPE_CONST, {.i64 =
TINTERLACE_FLAG_CVLPF},INT_MIN, INT_MAX, FLAGS, "flags" },
{NULL}
};
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/libopusdec: Allow avcodec_open2 to call .close
From 031e96bd481b7b8d0c11e5353f74fafc69e37f09 Mon Sep 17 00:00:00 2001
From: Matt Wolenetz
Date: Tue, 10 Apr 2018 13:59:25 -0700
Subject: [PATCH] lavc/libopusdec: Allow avcodec_open2 to call .close
If there is a decoder initialization failure detected in avcodec_open2
after .init is called, allow graceful decoder .close to prevent leaking
libopus decoder allocations.
BUG=828526
---
libavcodec/libopusdec.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libopusdec.c b/libavcodec/libopusdec.c
index 3d2ee5b61b..2a97811d18 100644
--- a/libavcodec/libopusdec.c
+++ b/libavcodec/libopusdec.c
@@ -160,7 +160,10 @@ static av_cold int libopus_decode_close(AVCodecContext *avc)
{
struct libopus_context *opus = avc->priv_data;
-opus_multistream_decoder_destroy(opus->dec);
+if (opus->dec) {
+opus_multistream_decoder_destroy(opus->dec);
+opus->dec = NULL;
+}
return 0;
}
@@ -252,6 +255,7 @@ AVCodec ff_libopus_decoder = {
.decode = libopus_decode,
.flush = libopus_flush,
.capabilities = AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
.sample_fmts= (const enum AVSampleFormat[]){ AV_SAMPLE_FMT_FLT,
AV_SAMPLE_FMT_S16,
AV_SAMPLE_FMT_NONE },
--
2.17.0.484.g0c8726318c-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/truemotion2: Propagate out of bounds error from GET_TOK()
Fixes: Timeout
Fixes:
6389/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEMOTION2_fuzzer-5695918121680896
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/truemotion2.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/truemotion2.c b/libavcodec/truemotion2.c
index 97c38f7f08..f7dbe047c7 100644
--- a/libavcodec/truemotion2.c
+++ b/libavcodec/truemotion2.c
@@ -63,6 +63,7 @@ typedef struct TM2Context {
AVFrame *pic;
GetBitContext gb;
+int error;
BswapDSPContext bdsp;
uint8_t *buffer;
@@ -398,6 +399,7 @@ static inline int GET_TOK(TM2Context *ctx,int type)
{
if (ctx->tok_ptrs[type] >= ctx->tok_lens[type]) {
av_log(ctx->avctx, AV_LOG_ERROR, "Read token from stream %i out of
bounds (%i>=%i)\n", type, ctx->tok_ptrs[type], ctx->tok_lens[type]);
+ctx->error = 1;
return 0;
}
if (type <= TM2_MOT) {
@@ -809,6 +811,8 @@ static int tm2_decode_blocks(TM2Context *ctx, AVFrame *p)
default:
av_log(ctx->avctx, AV_LOG_ERROR, "Skipping unknown block type
%i\n", type);
}
+if (ctx->error)
+return AVERROR_INVALIDDATA;
}
}
@@ -889,6 +893,8 @@ static int decode_frame(AVCodecContext *avctx,
int offset = TM2_HEADER_SIZE;
int i, t, ret;
+l->error = 0;
+
av_fast_padded_malloc(&l->buffer, &l->buffer_size, buf_size);
if (!l->buffer) {
av_log(avctx, AV_LOG_ERROR, "Cannot allocate temporary buffer\n");
--
2.17.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/mjpegdec: Check input buffer size.
Fixes: Timeout
Fixes:
6381/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEGLS_fuzzer-5665032743419904
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/mjpegdec.c | 4
libavcodec/mjpegdec.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index beef174618..22ca69f841 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -335,6 +335,8 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
av_log(s->avctx, AV_LOG_DEBUG, "sof0: picture: %dx%d\n", width, height);
if (av_image_check_size(width, height, 0, s->avctx) < 0)
return AVERROR_INVALIDDATA;
+if (s->buf_size && (width + 7) / 8 * ((height + 7) / 8) > s->buf_size *
4LL)
+return AVERROR_INVALIDDATA;
nb_components = get_bits(&s->gb, 8);
if (nb_components <= 0 ||
@@ -2247,6 +2249,8 @@ int ff_mjpeg_decode_frame(AVCodecContext *avctx, void
*data, int *got_frame,
int ret = 0;
int is16bit;
+s->buf_size = buf_size;
+
av_dict_free(&s->exif_metadata);
av_freep(&s->stereo3d);
s->adobe_transform = -1;
diff --git a/libavcodec/mjpegdec.h b/libavcodec/mjpegdec.h
index ff301bcb93..653fe7cae6 100644
--- a/libavcodec/mjpegdec.h
+++ b/libavcodec/mjpegdec.h
@@ -47,6 +47,7 @@ typedef struct MJpegDecodeContext {
AVClass *class;
AVCodecContext *avctx;
GetBitContext gb;
+int buf_size;
int start_code; /* current start code */
int buffer_size;
--
2.17.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding
On Tue, Apr 10, 2018 at 09:41:05PM +0200, Jerome Martinez wrote: > On 10/04/2018 12:34, Carl Eugen Hoyos wrote: > >2018-04-10 12:28 GMT+02:00, Kieran O Leary : > >>I just tested this patch non packed to 16-bit gbrp12le DPX from DaVinci > >>Resolve. > >Testing is good, apart > > I thought the patch was "technically" OK, as I answered to all change > requests and there was no additional feedback IIRC. > > > from more brackets > > Not sure I understand, as the only "missing" brackets I see are for the 1 > line code after a "if", and I see that 1 line code has no brackets in other > parts of the file. > Anyway, I added more brackets, except for "if (*n_datum) (*n_datum)--;" as I > copied/pasted it from another part of the file. > Did I miss something else? > > > (and less comments) > > I thought it would be better for someone willing to add alpha support in the > future, as the alpha support was tested and "just" rejected for the moment. > Anyway, I removed the commented code. > > Modified patch attached. > Note that I personally prefer to use the previous patch (or this patch > without the additional brackets). > > > it would > >be better if Jerome sends his public keys to Michael and pushes the patch. > > If it is the only solution for having the patch pushed, I'll do that, even > if I am not convinced that I deserve for the moment write rights on FFmpeg > repository (especially because Git and me are not good friends :) ). what do you mean by "Git and me are not good friends" ? If git hates you and sometimes does things that you didnt intend at all then that would be a problem with direct pushes as theres no way to undo. But maybe i misunderstand. Also to get git write access, post a patch that adds yourself to the MAINTAINERs file. When noone objects then ill add your key and apply the MAINTAINER patch. thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avfilter/showvolume : add new options and minor clean
On Sat, Mar 31, 2018 at 04:21:36PM +0200, Martin Vignali wrote:
> Hello,
>
> In attach new patchs for showvolume filter
>
> 001 : Move the clear picture part to a new func, and use it if fade option
> == 0.
> (no need to calculate it in float)
>
> 002/003 : Move "height" condition for draw volume at the start of the loop
> and indent
>
> 004 : add a new option for choosing the display scale
> currently, the filter use linear display,
> most audio meter use some kind of log display
>
>
> 005 : WIP :
> The idea is to add an option to draw a line for the max level for a given
> duration.
> Several audio meter have this kind of display, and its help user, to check
> peak level (even
> if the "peak" happen during a very short time.
>
> I'm not entirely sure, this is the best way to add this.
>
> For now, i store the max value for each channel, update it, if a new peak
> is bigger than the store value
> And count the number of frame for display. If a given display duration is
> exceed, update the max value to the current max value.
>
> Missing docs and probably code reorganization to reduce code duplication.
>
> I also have had very few inspiration for option naming and variable naming
> (and i don't know the "official name" of this little line in audio meter).
> So i'm open to better naming suggestion.
>
> This display need to be enable using dm=1
> and the duration during the max value is still display can be set with
> dm_duration (in seconds)
[...]
> doc/filters.texi |4
> libavfilter/avf_showvolume.c | 22 +++---
> 2 files changed, 23 insertions(+), 3 deletions(-)
> 727228fe3128595cad5a00f9370b63c1c3c06273
> 0004-avfilter-showvolume-add-display-scale-option.patch
> From 06b19cff28558885b8c4a987d27f56a3a90528f7 Mon Sep 17 00:00:00 2001
> From: Martin Vignali
> Date: Sat, 31 Mar 2018 15:52:20 +0200
> Subject: [PATCH 4/5] avfilter/showvolume : add display scale option
>
> linear (current behaviour) or log display (more close to classic audio meter)
> ---
> doc/filters.texi | 4
> libavfilter/avf_showvolume.c | 22 +++---
> 2 files changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index bf2b94e240..764abd4be7 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -19974,6 +19974,10 @@ Set background opacity, allowed range is [0, 1].
> Default is 0.
> @item m
> Set metering mode, can be peak: @code{p} or rms: @code{r},
> default is @code{p}.
> +
> +@item ds
> +Set display scale, can be linear: @code{lin} or log: @code{log},
> +default is @code{lin}.
> @end table
>
> @section showwaves
> diff --git a/libavfilter/avf_showvolume.c b/libavfilter/avf_showvolume.c
> index 7fe3916855..50ff80e022 100644
> --- a/libavfilter/avf_showvolume.c
> +++ b/libavfilter/avf_showvolume.c
> @@ -54,6 +54,7 @@ typedef struct ShowVolumeContext {
> uint32_t *color_lut;
> float *max;
> float rms_factor;
> +int display_scale; /* 0 for linear, 1 for log */
please use #define or values from a enum.
self explanatory code is better than comments.
also leave the type of display_scale int dont change it to enum if you
use a enum, (generic code like AVOptions cannot support arbitrary enum types)
i like the idea of this patch though
[...]
> avf_showvolume.c | 63
> +++
> 1 file changed, 63 insertions(+)
> e256cdd9a6d44f721f19aab6eedba48be089ad03
> 0005-avfilter-showvolume-add-persistent-max-display.patch
> From 1cac1a13e5142b0eff4acd17aecaac596ae359d4 Mon Sep 17 00:00:00 2001
> From: Martin Vignali
> Date: Sat, 31 Mar 2018 15:53:04 +0200
> Subject: [PATCH 5/5] avfilter/showvolume : add persistent max display
>
> WIP
> ---
> libavfilter/avf_showvolume.c | 63
>
> 1 file changed, 63 insertions(+)
didnt review as its still WIP but i think the idea is good as well
you could combine the dm and dm_duration options though making the interface
simpler
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mpegpicture: guard "stride changed" failures against unknown uvlinesize
On Tue, Apr 10, 2018 at 10:20:07AM -0700, Aman Gupta wrote:
> From: Aman Gupta
>
> Before adding uvlinesize check, I was seeing failures decoding
> some samples (shown with extra logging added):
>
> [mpeg2video @ 0x7fa193818c00] get_buffer() failed (stride changed:
> linesize=1280/1280 uvlinesize=0/640)
> [mpeg2video @ 0x7fa193818c00] get_buffer() failed (stride changed:
> linesize=1280/1280 uvlinesize=0/640)
> ---
> libavcodec/mpegpicture.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
> index 2be670cdbc..80898c161c 100644
> --- a/libavcodec/mpegpicture.c
> +++ b/libavcodec/mpegpicture.c
> @@ -148,10 +148,13 @@ static int alloc_frame_buffer(AVCodecContext *avctx,
> Picture *pic,
> }
> }
>
> -if (linesize && (linesize != pic->f->linesize[0] ||
> - uvlinesize != pic->f->linesize[1])) {
> +if (linesize && uvlinesize &&
> +(linesize != pic->f->linesize[0] ||
> + uvlinesize != pic->f->linesize[1])) {
without checking if this can be reached with grayscale.
If it can then uvlinesize may be 0 in which case this change would be
wrong
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Observe your enemies, for they first find out your faults. -- Antisthenes
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding
On Tue, Apr 10, 2018, at 2:05 PM, Michael Niedermayer wrote: > > what do you mean by "Git and me are not good friends" ? > If git hates you and sometimes does things that you didnt intend at all then > that would be a problem with direct pushes as theres no way to undo. > But maybe i misunderstand. > > Also to get git write access, post a patch that adds yourself to the > MAINTAINERs file. When noone objects then ill add your key and apply > the MAINTAINER patch. Also, if you're uncomfortable pushing to the repository that's fine too. It is not a problem, but you may have to prod and remind us, perhaps a few times (or more), to push stuff. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/rawenc: check stream type
On Tue, Apr 10, 2018 at 07:21:29PM +0530, Gyan Doshi wrote: > > > On 4/10/2018 4:49 AM, Michael Niedermayer wrote: > > >To implement generic "codec supported" checks, muxers would have to > >list what they support. > >There are 3 ways i know how this can be done in the current API > >1. the audio_codec / video_codec / ... fields > >2. the codec_tag array (this was in fact IIRC one of the intended uses of it) > >3. the querry_format callback > > These are raw single stream muxers - most only dump packets and _should_ > accept exactly one codec_id. A couple may insert bitstream filters. Only one > writes a trailer. So none of them have a codec_tag member or a query_codec > callback. Personally, I agree that the current method is inelegant but these > "muxers" are stable and these tests shouldn't need changes. But I can go the > query_codec route if you advise it. yes please do note query_codec is only needed for the few special cases that do more than one codec_id thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSOC] [PATCH] SRCNN filter
Thanks! Please send it to the same mailing list thread where it was being reviewd. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/movenc: use correct iTunes copyright atom
On Tue, Apr 10, 2018 at 10:38:30PM +0300, Timo Teras wrote: > On Tue, 3 Apr 2018 09:05:18 +0300 > Timo Teräs wrote: > > > Support for writing copyright metadata was added in commit bed4fc54c9 > > for 3GP, MOV and iTunes metadata. 3GP and MOV cases are formally > > specified. However, iTunes format does not have specification, and > > it seems to have been assumed that it would use the same atom as > > MOV (both being Apple formats). > >[snip] > > Ping? > > It's been 2 weeks since the original mail + inquiry. And one week since > this. What's the usual time for waiting feedback? Would this be soon > good to go in? will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mpegpicture: guard "stride changed" failures against unknown uvlinesize
On Tue, Apr 10, 2018 at 3:15 PM, Michael Niedermayer wrote:
> On Tue, Apr 10, 2018 at 10:20:07AM -0700, Aman Gupta wrote:
> > From: Aman Gupta
> >
> > Before adding uvlinesize check, I was seeing failures decoding
> > some samples (shown with extra logging added):
> >
> > [mpeg2video @ 0x7fa193818c00] get_buffer() failed (stride changed:
> linesize=1280/1280 uvlinesize=0/640)
> > [mpeg2video @ 0x7fa193818c00] get_buffer() failed (stride changed:
> linesize=1280/1280 uvlinesize=0/640)
> > ---
> > libavcodec/mpegpicture.c | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
> > index 2be670cdbc..80898c161c 100644
> > --- a/libavcodec/mpegpicture.c
> > +++ b/libavcodec/mpegpicture.c
> > @@ -148,10 +148,13 @@ static int alloc_frame_buffer(AVCodecContext
> *avctx, Picture *pic,
> > }
> > }
> >
> > -if (linesize && (linesize != pic->f->linesize[0] ||
> > - uvlinesize != pic->f->linesize[1])) {
> > +if (linesize && uvlinesize &&
> > +(linesize != pic->f->linesize[0] ||
> > + uvlinesize != pic->f->linesize[1])) {
>
> without checking if this can be reached with grayscale.
> If it can then uvlinesize may be 0 in which case this change would be
> wrong
>
I forgot to mention that I was only seeing this bug with gray mode
(--enable-gray + AV_CODEC_FLAG_GRAY), and that after this patch it works as
expected.
Aman
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Observe your enemies, for they first find out your faults. -- Antisthenes
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/libopusdec: Allow avcodec_open2 to call .close
On Tue, Apr 10, 2018 at 02:13:28PM -0700, Matthew Wolenetz wrote: > > libopusdec.c |6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > a62bece9f45c68d93e138cb021a533fbc242ddc3 > 0001-lavc-libopusdec-Allow-avcodec_open2-to-call-.close.patch > From 031e96bd481b7b8d0c11e5353f74fafc69e37f09 Mon Sep 17 00:00:00 2001 > From: Matt Wolenetz > Date: Tue, 10 Apr 2018 13:59:25 -0700 > Subject: [PATCH] lavc/libopusdec: Allow avcodec_open2 to call .close > > If there is a decoder initialization failure detected in avcodec_open2 > after .init is called, allow graceful decoder .close to prevent leaking > libopus decoder allocations. > > BUG=828526 > --- > libavcodec/libopusdec.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) Doesnt apply, also the NULL check already exists in git master FF_CODEC_CAP_INIT_CLEANUP is missing in master though can you update the patch ? thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mpegpicture: guard "stride changed" failures against unknown uvlinesize
On Tue, Apr 10, 2018 at 03:25:33PM -0700, Aman Gupta wrote:
> On Tue, Apr 10, 2018 at 3:15 PM, Michael Niedermayer > wrote:
>
> > On Tue, Apr 10, 2018 at 10:20:07AM -0700, Aman Gupta wrote:
> > > From: Aman Gupta
> > >
> > > Before adding uvlinesize check, I was seeing failures decoding
> > > some samples (shown with extra logging added):
> > >
> > > [mpeg2video @ 0x7fa193818c00] get_buffer() failed (stride changed:
> > linesize=1280/1280 uvlinesize=0/640)
> > > [mpeg2video @ 0x7fa193818c00] get_buffer() failed (stride changed:
> > linesize=1280/1280 uvlinesize=0/640)
> > > ---
> > > libavcodec/mpegpicture.c | 9 ++---
> > > 1 file changed, 6 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
> > > index 2be670cdbc..80898c161c 100644
> > > --- a/libavcodec/mpegpicture.c
> > > +++ b/libavcodec/mpegpicture.c
> > > @@ -148,10 +148,13 @@ static int alloc_frame_buffer(AVCodecContext
> > *avctx, Picture *pic,
> > > }
> > > }
> > >
> > > -if (linesize && (linesize != pic->f->linesize[0] ||
> > > - uvlinesize != pic->f->linesize[1])) {
> > > +if (linesize && uvlinesize &&
> > > +(linesize != pic->f->linesize[0] ||
> > > + uvlinesize != pic->f->linesize[1])) {
> >
> > without checking if this can be reached with grayscale.
> > If it can then uvlinesize may be 0 in which case this change would be
> > wrong
> >
>
> I forgot to mention that I was only seeing this bug with gray mode
> (--enable-gray + AV_CODEC_FLAG_GRAY), and that after this patch it works as
> expected.
The patch looks like it skips the linesize check in grayscale then.
This seems not correct
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] avcodec/mpegpicture: fix "stride changed" failures in gray mode
From: Aman Gupta
Before adding uvlinesize check, I was seeing failures decoding
some video with ffmpeg compiled with --enable-gray and using AV_CODEC_FLAG_GRAY.
[mpeg2video @ 0x7fa193818c00] get_buffer() failed (stride changed:
linesize=1280/1280 uvlinesize=0/640)
[mpeg2video @ 0x7fa193818c00] get_buffer() failed (stride changed:
linesize=1280/1280 uvlinesize=0/640)
---
libavcodec/mpegpicture.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index 2be670cdbc..c0e06900fe 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -148,10 +148,12 @@ static int alloc_frame_buffer(AVCodecContext *avctx,
Picture *pic,
}
}
-if (linesize && (linesize != pic->f->linesize[0] ||
- uvlinesize != pic->f->linesize[1])) {
+if ((linesize && linesize != pic->f->linesize[0]) ||
+(uvlinesize && uvlinesize != pic->f->linesize[1])) {
av_log(avctx, AV_LOG_ERROR,
- "get_buffer() failed (stride changed)\n");
+ "get_buffer() failed (stride changed: linesize=%d/%d
uvlinesize=%d/%d)\n",
+ linesize, pic->f->linesize[0],
+ uvlinesize, pic->f->linesize[1]);
ff_mpeg_unref_picture(avctx, pic);
return -1;
}
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hls: copy rw_timeout from parent to child AVIOContexts.
> 在 2018年4月11日，上午3:14，Richard Shaffer 写道： > > On Tue, Apr 3, 2018 at 5:11 PM, Steven Liu wrote: > >> 2018-04-04 7:53 GMT+08:00 Steven Liu : > > Look at the code: > > 205 char *referer; ///< holds HTTP referer >> set > as an AVOption to the HTTP protocol context > 206 char *user_agent;///< holds HTTP user >> agent > set as an AVOption to the HTTP protocol context > 207 char *cookies; ///< holds HTTP cookie > values set in either the initial response or as an AVOption to the HTTP > protocol context > 208 char *headers; ///< holds HTTP headers >> set > as an AVOption to the HTTP protocol context > 209 char *http_proxy;///< holds the address of > the HTTP proxy server > > There have some comment for the options. > and reference the code in: hls_read_header / open_input and use the > options. > > That's pretty clear. What I was asking is why the options are stored >> both in these fields as well as avio_opts, and this doesn't answer my >> question. I was also asking why you object to storing the timeout option in avio_opts, but I'm not understanding the logic in your responses. >>> >>> no logic problem, just that option be used to HTTP, is that ok? >> > > This is a logic problem for me, because I'm not understanding your logic. > What is the reason that avio_opts should only be used for HTTP options? > > >>> >>> BTW, how should i reproduce the problem you said? >> > > If you pass the rw_timeout option to either the command-line or to > avformat_open_input, it will be applied only to the URL passed on the > command line or to the function. When the HLS demuxer tries to open other > URLs, such as keying URIs, media playlists or segments, it will not apply > the rw_timeout option. As a result, if we fail to receive data from the > remote server, it can block the process instead of returning the expected > AVERROR(ETIMEDOUT) error. > > >>> >>> " >>> The rw_timeout option is currently not applied when opening media >> playlist, >>> segment, or encryption key URLs. This can cause the HLS demuxer to block >>> indefinitely, even when the rw_timeout option has been specified. This >> change >>> simply enables carrying over the rw_timeout option when the demuxer >> opens these >>> URLs. >>> " >> >> So i think add option timeout to do it maybe better than this way. you >> can find another formats do it like this. >> > > I think the HLS demuxer is pretty unique. Except for dash, I don't know > which other demuxers have to open additional avio to do their work. If > there is an example you can show me that illustrates your point, that would > be appreciated. > > >>> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > > Hi Steven, > > I apologize for the late response. I have been traveling. > > I understand that you might be busy, and that English is not everyone's > first language. However, if you could take the time to give a more thorough > response, I'd really appreciate it. It's a little bit frustrating for me: > I'm asking why avio_opts needs to be restricted to HTTP options, and the > answer I seem to keep getting back is "because it's for HTTP options." That > answer isn't very satisfying, and doesn't help me understand /why/ you > think it should only be used for HTTP options. It may be that you have a > good reason, but if I can't understand what it is, I'm not going to be able > to provide a better fix. > > I can't force anyone to accept my changes or provide more detailed > feedback. However, if we can't understand each other, then at some point I > will have to give up. I'll apply a patch that fixes my problem to a local > fork of ffmpeg. Other people outside of my company won't benefit from the > fix. My company will also have to maintain our own copy of ffmpeg. This > could make it less likely for us to share our changes with the community, > and it will also make it harder for us to benefit from improvements and > fixes to ffmpeg. I don't want to do that, because nobody wins in that > scenario. That is why I'm asking for your help to understand your objection > and suggestion. Sorry for my poor English, English is not my first language, thanks, you can contribute. After the last patch you submit(https://patchwork.ffmpeg.org/patch/8378/), i think i can understand this patch. > > Thanks, > > -Richard > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/amfenc: Retain a reference to D3D frames used as input during the encoding process
On 09/04/18 17:48, Alexander Kravchenko wrote:
> Hi, could you please review updated patch?
>
> Fixes according on Mark's review:
> * Macroses changed to functions
> * error level of AMF_RETURN_IF_FALSE changed to fatal (all cases it returns
> are fatal according on fatal error level description)
> * used AMF_RETURN_IF_FALSE for case if a frame reference has been completely
> lost (was just warning before)
>
> Hopefully this patch is ok enough to be applied :).
Two minor points below, not enough to merit another cycle so I fixed them and
pushed.
> FYI, near time I am going to send the following patches
> * cosmetic fixes
> * hwcontext_amf (to be reused in encoder and color space converter)
> * AMF colors space converter (input memory types: opencl, dx9, dx11, host;
> output memory types: opencl, dx9, dx11)
>
>
> ---
^
(When adding commentary which isn't part of the commit message to an email
please place it after this line so that it doesn't end up in the commit
message.)
> libavcodec/amfenc.c | 94
> -
> libavcodec/amfenc.h | 5 ++-
> 2 files changed, 97 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
> index 89a10ff253..ea2c5acbbf 100644
> --- a/libavcodec/amfenc.c
> +++ b/libavcodec/amfenc.c
> @@ -157,6 +157,9 @@ static int amf_init_context(AVCodecContext *avctx)
> AmfContext *ctx = avctx->priv_data;
> AMF_RESULT res = AMF_OK;
>
> +ctx->hwsurfaces_in_queue = 0;
> +ctx->hwsurfaces_in_queue_max = 16;
> +
> // configure AMF logger
> // the return of these functions indicates old state and do not affect
> behaviour
> ctx->trace->pVtbl->EnableWriter(ctx->trace,
> AMF_TRACE_WRITER_DEBUG_OUTPUT, ctx->log_to_dbg != 0 );
> @@ -187,6 +190,7 @@ static int amf_init_context(AVCodecContext *avctx)
> if (!ctx->hw_frames_ctx) {
> return AVERROR(ENOMEM);
> }
> +ctx->hwsurfaces_in_queue_max =
> device_ctx->initial_pool_size - 1;
initial_pool_size need not be set to a positive value. It will be set for all
internally-created frames contexts (since the setup code there is intended for
use with the decoder), but it need not be for externally-created one which
might not use array textures and therefore need not have fixed size.
Changed to only update the queue size if initial_pool_size is positive (i.e.
use the 16 length if the pool isn't of fixed size).
> } else {
> if(res == AMF_NOT_SUPPORTED)
> av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx
> has D3D11 device which doesn't have D3D11VA interface, switching to
> default\n");
> @@ -443,6 +447,75 @@ int ff_amf_encode_init(AVCodecContext *avctx)
> return ret;
> }
>
> +static AMF_RESULT amf_set_property_buffer(AMFSurface *object, const wchar_t
> *name, AMFBuffer *val)
> +{
> +AMF_RESULT res;
> +AMFVariantStruct var;
> +res = AMFVariantInit(&var);
> +if (res == AMF_OK) {
> +AMFGuid guid_AMFInterface = IID_AMFInterface();
> +AMFInterface *amf_interface;
> +res = val->pVtbl->QueryInterface(val, &guid_AMFInterface,
> (void**)&amf_interface);
> +
> +if (res == AMF_OK) {
> +res = AMFVariantAssignInterface(&var, amf_interface);
> +amf_interface->pVtbl->Release(amf_interface);
> +}
> +if (res == AMF_OK) {
> +res = object->pVtbl->SetProperty(object, name, var);
> +}
> +AMFVariantClear(&var);
> +}
> +return res;
> +}
> +
> +static AMF_RESULT amf_get_property_buffer(AMFData *object, const wchar_t
> *name, AMFBuffer **val)
> +{
> +AMF_RESULT res;
> +AMFVariantStruct var;
> +res = AMFVariantInit(&var);
> +if (res == AMF_OK) {
> +res = object->pVtbl->GetProperty(object, name, &var);
> +if (res == AMF_OK) {
> +if (var.type == AMF_VARIANT_INTERFACE) {
> +AMFGuid guid_AMFBuffer = IID_AMFBuffer();
> +AMFInterface *amf_interface = AMFVariantInterface(&var);
> +res = amf_interface->pVtbl->QueryInterface(amf_interface,
> &guid_AMFBuffer, (void**)val);
> +} else {
> +res = AMF_INVALID_DATA_TYPE;
> +}
> +}
> +AMFVariantClear(&var);
> +}
> +return res;
> +}
> +
> +static AMFBuffer *amf_create_buffer_with_frame_ref(const AVFrame *frame,
> AMFContext *context)
> +{
> +AVFrame *frame_ref;
> +AMFBuffer *frame_ref_storage_buffer = NULL;
> +AMF_RESULT res;
> +
> +res = context->pVtbl->AllocBuffer(context, AMF_MEMORY_HOST,
> sizeof(frame_ref), &frame_ref_storage_buffer);
> +if (res == AMF_OK) {
> +frame_ref = av_frame_clone(frame);
> +if (frame_ref) {
> +
> memcpy(frame_ref_storage_buffer->pVtbl->GetNative(frame_ref_sto
Re: [FFmpeg-devel] [PATCH] avformat/hls: copy rw_timeout from parent to child AVIOContexts.
On Tue, Apr 10, 2018 at 4:00 PM, Liu Steven wrote: > > > 在 2018年4月11日，上午3:14，Richard Shaffer 写道： > > > > On Tue, Apr 3, 2018 at 5:11 PM, Steven Liu > wrote: > > > >> 2018-04-04 7:53 GMT+08:00 Steven Liu : > > > > Look at the code: > > > > 205 char *referer; ///< holds HTTP referer > >> set > > as an AVOption to the HTTP protocol context > > 206 char *user_agent;///< holds HTTP user > >> agent > > set as an AVOption to the HTTP protocol context > > 207 char *cookies; ///< holds HTTP cookie > > values set in either the initial response or as an AVOption to the > HTTP > > protocol context > > 208 char *headers; ///< holds HTTP headers > >> set > > as an AVOption to the HTTP protocol context > > 209 char *http_proxy;///< holds the address > of > > the HTTP proxy server > > > > There have some comment for the options. > > and reference the code in: hls_read_header / open_input and use the > > options. > > > > > That's pretty clear. What I was asking is why the options are stored > >> both > in these fields as well as avio_opts, and this doesn't answer my > >> question. > I was also asking why you object to storing the timeout option in > avio_opts, but I'm not understanding the logic in your responses. > >>> > >>> no logic problem, just that option be used to HTTP, is that ok? > >> > > > > This is a logic problem for me, because I'm not understanding your logic. > > What is the reason that avio_opts should only be used for HTTP options? > > > > > >>> > >>> BTW, how should i reproduce the problem you said? > >> > > > > If you pass the rw_timeout option to either the command-line or to > > avformat_open_input, it will be applied only to the URL passed on the > > command line or to the function. When the HLS demuxer tries to open other > > URLs, such as keying URIs, media playlists or segments, it will not apply > > the rw_timeout option. As a result, if we fail to receive data from the > > remote server, it can block the process instead of returning the expected > > AVERROR(ETIMEDOUT) error. > > > > > >>> > >>> " > >>> The rw_timeout option is currently not applied when opening media > >> playlist, > >>> segment, or encryption key URLs. This can cause the HLS demuxer to > block > >>> indefinitely, even when the rw_timeout option has been specified. This > >> change > >>> simply enables carrying over the rw_timeout option when the demuxer > >> opens these > >>> URLs. > >>> " > >> > >> So i think add option timeout to do it maybe better than this way. you > >> can find another formats do it like this. > >> > > > > I think the HLS demuxer is pretty unique. Except for dash, I don't know > > which other demuxers have to open additional avio to do their work. If > > there is an example you can show me that illustrates your point, that > would > > be appreciated. > > > > > >>> > > > >> ___ > >> ffmpeg-devel mailing list > >> ffmpeg-devel@ffmpeg.org > >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > > > > Hi Steven, > > > > I apologize for the late response. I have been traveling. > > > > I understand that you might be busy, and that English is not everyone's > > first language. However, if you could take the time to give a more > thorough > > response, I'd really appreciate it. It's a little bit frustrating for me: > > I'm asking why avio_opts needs to be restricted to HTTP options, and the > > answer I seem to keep getting back is "because it's for HTTP options." > That > > answer isn't very satisfying, and doesn't help me understand /why/ you > > think it should only be used for HTTP options. It may be that you have a > > good reason, but if I can't understand what it is, I'm not going to be > able > > to provide a better fix. > > > > I can't force anyone to accept my changes or provide more detailed > > feedback. However, if we can't understand each other, then at some point > I > > will have to give up. I'll apply a patch that fixes my problem to a local > > fork of ffmpeg. Other people outside of my company won't benefit from the > > fix. My company will also have to maintain our own copy of ffmpeg. This > > could make it less likely for us to share our changes with the community, > > and it will also make it harder for us to benefit from improvements and > > fixes to ffmpeg. I don't want to do that, because nobody wins in that > > scenario. That is why I'm asking for your help to understand your > objection > > and suggestion. > > Sorry for my poor English, English is not my first language, thanks, you > can contribute. > After the last patch you submit(https://patchwork.ffmpeg.org/patch/8378/), > i think i can understand this patch. > > Thanks, Steven. I will wait a few days. If there are no additional comments, I will ask yo
[FFmpeg-devel] [PATCH v1 1/3] avcodec/bitpacked: move ff_get_buffer
From: Damien Riegel
ff_get_buffer is used to allocate a buffer to hold frame's content. This
function was called in the function in charge of decoding an AVPacket
containing raw video with the yuv422 pixel format and a depth of 10-bit.
RFC4175 supports both progressive and interlaced mode. But the
interlaced mode doesn't consist of interlaced frames, only of fields.
FFmpeg cannot handle fields on their own, so the codec has to recreate
interlaced frames based on two consecutive fields.
As the function `bitpacked_decode_yuv422p10` will need to be called
twice to do that, it cannot be in charge of the buffer allocation, so
move it into its caller.
Signed-off-by: Damien Riegel
---
libavcodec/bitpacked.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/libavcodec/bitpacked.c b/libavcodec/bitpacked.c
index f0b417d..85d4bdd 100644
--- a/libavcodec/bitpacked.c
+++ b/libavcodec/bitpacked.c
@@ -64,9 +64,6 @@ static int bitpacked_decode_yuv422p10(AVCodecContext *avctx,
AVFrame *frame,
uint16_t *y, *u, *v;
int ret, i, j;
-ret = ff_get_buffer(avctx, frame, 0);
-if (ret < 0)
-return ret;
if (frame_size > packet_size)
return AVERROR_INVALIDDATA;
@@ -128,6 +125,12 @@ static int bitpacked_decode(AVCodecContext *avctx, void
*data, int *got_frame,
frame->pict_type = AV_PICTURE_TYPE_I;
frame->key_frame = 1;
+if (avctx->pix_fmt == AV_PIX_FMT_YUV422P10) {
+res = ff_get_buffer(avctx, frame, 0);
+if (res < 0)
+return res;
+}
+
res = bc->decode(avctx, frame, avpkt);
if (res)
return res;
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v1 3/3] avformat/rtpdec_rfc4175: handle interlace format
From: Damien Riegel
In order to handle the interlaced formats, the demuxer has only a few
things to do:
- parse the SDP correctly and propagate the information
- check the field bit in the RFC4175 header, and pass that information
to the decoder
In interlaced mode, received data only consist of fields, and their
heights are half of the frame size, so some adjustments must be done
here and there to take that into account.
Signed-off-by: Damien Riegel
---
libavformat/rtpdec_rfc4175.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c
index e9c62c1..55a36eb 100644
--- a/libavformat/rtpdec_rfc4175.c
+++ b/libavformat/rtpdec_rfc4175.c
@@ -31,6 +31,8 @@ struct PayloadContext {
int depth;
int width;
int height;
+int interlaced;
+int field;
uint8_t *frame;
unsigned int frame_size;
@@ -65,10 +67,18 @@ static int rfc4175_parse_format(AVStream *stream,
PayloadContext *data)
return AVERROR_INVALIDDATA;
}
+if (data->interlaced)
+stream->codecpar->field_order = AV_FIELD_TT;
+else
+stream->codecpar->field_order = AV_FIELD_PROGRESSIVE;
+
stream->codecpar->format = pixfmt;
stream->codecpar->codec_tag = tag;
stream->codecpar->bits_per_coded_sample = bits_per_sample;
-data->frame_size = data->width * data->height * data->pgroup / data->xinc;
+if (data->interlaced)
+data->frame_size = data->width * (data->height / 2) * data->pgroup /
data->xinc;
+else
+data->frame_size = data->width * data->height * data->pgroup /
data->xinc;
return 0;
}
@@ -85,6 +95,8 @@ static int rfc4175_parse_fmtp(AVFormatContext *s, AVStream
*stream,
data->sampling = av_strdup(value);
else if (!strncmp(attr, "depth", 5))
data->depth = atoi(value);
+else if (!strncmp(attr, "interlace", 9))
+data->interlaced = 1;
return 0;
}
@@ -131,7 +143,11 @@ static int rfc4175_finalize_packet(PayloadContext *data,
AVPacket *pkt,
av_freep(&data->frame);
}
+ /* In the packet header, the field is set to 0 for top field
+* and 1 for bottom */
+ pkt->flags |= data->field ? 0 : AV_PKT_FLAG_TOP_FIELD;
data->frame = NULL;
+ data->field = 0;
return ret;
}
@@ -141,7 +157,7 @@ static int rfc4175_handle_packet(AVFormatContext *ctx,
PayloadContext *data,
const uint8_t * buf, int len,
uint16_t seq, int flags)
{
-int length, line, offset, cont;
+int length, line, offset, cont, field;
const uint8_t *headers = buf + 2; /* skip extended seqnum */
const uint8_t *payload = buf + 2;
int payload_len = len - 2;
@@ -194,11 +210,14 @@ static int rfc4175_handle_packet(AVFormatContext *ctx,
PayloadContext *data,
return AVERROR_INVALIDDATA;
length = (headers[0] << 8) | headers[1];
+field = (headers[2] & 0x80);
line = ((headers[2] & 0x7f) << 8) | headers[3];
offset = ((headers[4] & 0x7f) << 8) | headers[5];
cont = headers[4] & 0x80;
headers += 6;
+data->field = field;
+
if (length % data->pgroup)
return AVERROR_INVALIDDATA;
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: check for INIT_ONCE before enabling w32threads
On 4/8/2018 2:00 PM, James Almer wrote: > Should fix compilation wiht some old mingw-w64 builds that > don't seem to define it. > > Signed-off-by: James Almer > --- > configure | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configure b/configure > index 08d6fc5983..3bae584ab0 100755 > --- a/configure > +++ b/configure > @@ -5883,6 +5883,7 @@ check_cpp_condition winrt windows.h > "!WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_D > if ! disabled w32threads && ! enabled pthreads; then > check_func_headers "windows.h process.h" _beginthreadex && > check_type "windows.h" CONDITION_VARIABLE && > +check_type "windows.h" INIT_ONCE && > enable w32threads || disable w32threads > if ! enabled w32threads && enabled winrt; then > check_func_headers "windows.h" CreateThread && > Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v1 2/3] avcodec/bitpacked: add interlace support
From: Damien Riegel
This codec is already capable of depacking some combinations of pixel
formats and depth as defined in the RFC4175. The only difference between
progressive and interlace is that either a packet will contain the whole
frame, or only a field of the frame.
As FFmpeg is not capable of handling fields only and recompose an
interlaced frame from that, it has to be done by the codec. To achieve
that, it must use two AVPacket: one for each field (top and bottom).
Signed-off-by: Damien Riegel
Signed-off-by: Patrick Keroulas
---
libavcodec/avcodec.h | 4 +++
libavcodec/bitpacked.c | 76 ++
2 files changed, 68 insertions(+), 12 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index fb0c6fa..350e8d9 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1480,6 +1480,10 @@ typedef struct AVPacket {
*/
#define AV_PKT_FLAG_DISPOSABLE 0x0010
+/**
+ * The packet contains a top field.
+ */
+#define AV_PKT_FLAG_TOP_FIELD 0x0010
enum AVSideDataParamChangeFlags {
AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT = 0x0001,
diff --git a/libavcodec/bitpacked.c b/libavcodec/bitpacked.c
index 85d4bdd..d81703d 100644
--- a/libavcodec/bitpacked.c
+++ b/libavcodec/bitpacked.c
@@ -33,15 +33,19 @@
struct BitpackedContext {
int (*decode)(AVCodecContext *avctx, AVFrame *frame,
- AVPacket *pkt);
+ AVPacket *pkt, int top_field);
+AVPacket *first_field_pkt;
};
/* For this format, it's a simple passthrough */
static int bitpacked_decode_uyvy422(AVCodecContext *avctx, AVFrame *frame,
-AVPacket *avpkt)
+AVPacket *avpkt, int top_field)
{
int ret;
+if (frame->interlaced_frame)
+return AVERROR_PATCHWELCOME;
+
/* there is no need to copy as the data already match
* a known pixel format */
frame->buf[0] = av_buffer_ref(avpkt->buf);
@@ -56,17 +60,22 @@ static int bitpacked_decode_uyvy422(AVCodecContext *avctx,
AVFrame *frame,
}
static int bitpacked_decode_yuv422p10(AVCodecContext *avctx, AVFrame *frame,
- AVPacket *avpkt)
+ AVPacket *avpkt, int top_field)
{
uint64_t frame_size = (uint64_t)avctx->width * (uint64_t)avctx->height *
20;
uint64_t packet_size = (uint64_t)avpkt->size * 8;
+int interlaced = frame->interlaced_frame;
GetBitContext bc;
uint16_t *y, *u, *v;
int ret, i, j;
-
-if (frame_size > packet_size)
+/* check packet size depending on the interlaced/progressive format */
+if (interlaced) {
+if ((frame_size >> 1) > packet_size)
+return AVERROR_INVALIDDATA;
+} else if (frame_size > packet_size) {
return AVERROR_INVALIDDATA;
+}
if (avctx->width % 2)
return AVERROR_PATCHWELCOME;
@@ -75,7 +84,18 @@ static int bitpacked_decode_yuv422p10(AVCodecContext *avctx,
AVFrame *frame,
if (ret)
return ret;
-for (i = 0; i < avctx->height; i++) {
+/*
+ * if the frame is interlaced, the avpkt we are getting is either the top
+ * or the bottom field. If it's the bottom field, it contains all the odd
+ * lines of the recomposed frame, so we start at offset 1.
+ */
+i = (interlaced && !top_field) ? 1 : 0;
+
+/*
+ * Packets from interlaced frames contain either even lines, or odd
+ * lines, so increment by two in that case.
+ */
+for (; i < avctx->height; interlaced ? i += 2 : i++) {
y = (uint16_t*)(frame->data[0] + i * frame->linesize[0]);
u = (uint16_t*)(frame->data[1] + i * frame->linesize[1]);
v = (uint16_t*)(frame->data[2] + i * frame->linesize[2]);
@@ -100,13 +120,20 @@ static av_cold int bitpacked_init_decoder(AVCodecContext
*avctx)
if (avctx->codec_tag == MKTAG('U', 'Y', 'V', 'Y')) {
if (avctx->bits_per_coded_sample == 16 &&
-avctx->pix_fmt == AV_PIX_FMT_UYVY422)
+avctx->pix_fmt == AV_PIX_FMT_UYVY422) {
+
+if (avctx->field_order > AV_FIELD_PROGRESSIVE) {
+av_log(avctx, AV_LOG_ERROR, "interlaced not yet supported for
8-bit\n");
+return AVERROR_PATCHWELCOME;
+}
+
bc->decode = bitpacked_decode_uyvy422;
-else if (avctx->bits_per_coded_sample == 20 &&
- avctx->pix_fmt == AV_PIX_FMT_YUV422P10)
+} else if (avctx->bits_per_coded_sample == 20 &&
+ avctx->pix_fmt == AV_PIX_FMT_YUV422P10) {
bc->decode = bitpacked_decode_yuv422p10;
-else
+} else {
return AVERROR_INVALIDDATA;
+}
} else {
return AVERROR_INVALIDDATA;
}
@@ -120,24 +147,49 @@ static int bitpacked_decode(AVCodecContext *avctx, void
*data, int *got_frame,
struct BitpackedContext *bc = avctx->priv_data;
int buf_size = avpkt->size;
AVFrame
Re: [FFmpeg-devel] [PATCH] configure: check that the required header for Linux Perf is available
On 4/8/2018 1:30 PM, James Almer wrote: > Should fix compilation on targets like some old Android NDK versions. > > Signed-off-by: James Almer > --- > configure | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/configure b/configure > index 08d6fc5983..4ea30762f4 100755 > --- a/configure > +++ b/configure > @@ -2016,6 +2016,7 @@ HEADERS_LIST=" > ES2_gl_h > gsm_h > io_h > +linux_perf_event_h > machine_ioctl_bt848_h > machine_ioctl_meteor_h > malloc_h > @@ -2478,6 +2479,7 @@ simd_align_32_if_any="avx" > simd_align_64_if_any="avx512" > > # system capabilities > +linux_perf_deps="linux_perf_event_h" > symver_if_any="symver_asm_label symver_gnu_asm" > valgrind_backtrace_conflict="optimizations" > valgrind_backtrace_deps="valgrind_valgrind_h" > @@ -5800,6 +5802,7 @@ check_header dxgidebug.h > check_header dxva.h > check_header dxva2api.h -D_WIN32_WINNT=0x0600 > check_header io.h > +check_header linux/perf_event.h > check_header libcrystalhd/libcrystalhd_if.h > check_header malloc.h > check_header net/udplite.h Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: disable direct stripping in OpenBSD
On 4/9/2018 11:35 AM, Derek Buitenhuis wrote: > On 4/9/2018 3:32 PM, James Almer wrote: >> Maybe they already know and it was fixed at some point, seeing the >> OpenBSD fate client we have has software from 2007 (gcc 4.2, and safe to >> assume equally outdated binutils). > > OpenBSD doesn't update their toolchain AFAIK, but maintains their own forks, > so probably still useful. > Looking at the packages shipped by OpenBSD in its latest version, they are using GCC 4.9, so I'm going to assume this was fixed long ago. Does anyone use a recent OpenBSD to confirm this, in any case? I may be able to add a GCC version check depending on that to this patch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/libopusdec: Allow avcodec_open2 to call .close
On Wed, Apr 11, 2018 at 12:43:21AM +0200, Michael Niedermayer wrote: > On Tue, Apr 10, 2018 at 02:13:28PM -0700, Matthew Wolenetz wrote: > > > > > libopusdec.c |6 +- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > a62bece9f45c68d93e138cb021a533fbc242ddc3 > > 0001-lavc-libopusdec-Allow-avcodec_open2-to-call-.close.patch > > From 031e96bd481b7b8d0c11e5353f74fafc69e37f09 Mon Sep 17 00:00:00 2001 > > From: Matt Wolenetz > > Date: Tue, 10 Apr 2018 13:59:25 -0700 > > Subject: [PATCH] lavc/libopusdec: Allow avcodec_open2 to call .close > > > > If there is a decoder initialization failure detected in avcodec_open2 > > after .init is called, allow graceful decoder .close to prevent leaking > > libopus decoder allocations. > > > > BUG=828526 > > --- > > libavcodec/libopusdec.c | 6 +- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > Doesnt apply, also the NULL check already exists in git master > FF_CODEC_CAP_INIT_CLEANUP is missing in master though > > can you update the patch ? forget this, will apply your patch i had this applied locally and didnt realize, i even checked what patches i had on the changed file, somehow i must have done something silly commit 4614d94f049319353f6c9deba1079009dd85594c Author: Andrew Allen Date: Wed Mar 28 14:48:46 2018 -0700 Support for Ambisonics and OpusProjection* API. Signed-off-by: Michael Niedermayer [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] lavf/aviobuf: add ff_get_chomp_line
On 2018/4/10 21:54, Marton Balint wrote: > > > On Tue, 10 Apr 2018, Jun Zhao wrote: > >> >> > > Maybe you should use ff_read_line_to_bprint instead? It already chops > the trailing line endings, not any whitespace though. Generally I > think we should deprecate ff_get_line, because line length limits > always pop here or there... > ff_read_line_to_bprint usually use when we don't know the length limits and need to the caller free the AVBPrint resource, in hls case, I think this is a simple case, the other reason is I don't want to mix the AVBPrint and c native char * in hls. Thanks. > Regards, > Marton > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.
On Wed, Mar 28, 2018 at 09:59:00PM +, Drew Allen wrote:
> Hello all,
>
> My name is Andrew Allen and I'm a contributor to Opus, supporting new
> channel mappings 2 and 3 for ambisonics compression. I've attached a patch
> to support the new OpusProjectionEncoder and OpusProjectionDecoder APIs for
> handling the new channel mapping 3 in OPUS.
>
> Please let me know of any changes I should make or if there are any
> questions I can help answer.
>
> Cheers,
> Drew
> libopusdec.c | 160 ++--
> libopusenc.c | 257
> ++-
> opus.c | 18 +---
> 3 files changed, 358 insertions(+), 77 deletions(-)
> 1f1fae1e93478880b50cd5432bb7479bc816f659 ffmpeg-Support-Ambisonics.patch
> From a897b4d9b1ebe9031b98a9e507c28355ef9a44ba Mon Sep 17 00:00:00 2001
> From: Andrew Allen
> Date: Wed, 28 Mar 2018 14:48:46 -0700
> Subject: [PATCH] Support for Ambisonics and OpusProjection* API.
>
> ---
> libavcodec/libopusdec.c | 160 -
> libavcodec/libopusenc.c | 257 ++--
> libavcodec/opus.c | 18 ++-
> 3 files changed, 358 insertions(+), 77 deletions(-)
>
> diff --git a/libavcodec/libopusdec.c b/libavcodec/libopusdec.c
> index 3d2ee5b61b..d4b5a459b9 100644
> --- a/libavcodec/libopusdec.c
> +++ b/libavcodec/libopusdec.c
> @@ -21,6 +21,9 @@
>
> #include
> #include
> +#ifdef OPUS_HAVE_OPUS_PROJECTION_H
> +#include
> +#endif
>
> #include "libavutil/internal.h"
> #include "libavutil/intreadwrite.h"
> @@ -33,9 +36,93 @@
> #include "mathops.h"
> #include "libopus.h"
>
> +typedef struct OpusGenericDecoder {
> +#ifdef OPUS_HAVE_OPUS_PROJECTION_H
> +OpusProjectionDecoder *pr;
> +#endif
> +OpusMSDecoder *ms;
> +} OpusGenericDecoder;
> +
> +static int libopus_generic_decoder_init(OpusGenericDecoder *st, int Fs,
> +int channels, int nb_streams,
> +int nb_coupled, uint8_t *mapping,
> +uint8_t *dmatrix) {
> +int err;
> +if (dmatrix != NULL) {
> +#ifdef OPUS_HAVE_OPUS_PROJECTION_H
> +opus_int32 size;
> +size = 2 * channels * (nb_streams + nb_coupled);
> +st->pr = opus_projection_decoder_create(Fs, channels, nb_streams,
> +nb_coupled, dmatrix, size, &err);
> +#else
> +err = OPUS_UNIMPLEMENTED;
> +#endif
> +st->ms = NULL;
> +return err;
> +}
> +#ifdef OPUS_HAVE_OPUS_PROJECTION_H
> +st->pr = NULL;
> +#endif
> +st->ms = opus_multistream_decoder_create(Fs, channels, nb_streams,
> +nb_coupled, mapping, &err);
> +return err;
> +}
> +
> +static void libopus_generic_decoder_cleanup(OpusGenericDecoder *st)
> +{
> +#ifdef OPUS_HAVE_OPUS_PROJECTION_H
> +if (st->pr) opus_projection_decoder_destroy(st->pr);
> +#endif
> +if (st->ms) opus_multistream_decoder_destroy(st->ms);
> +}
> +
> +static int libopus_generic_decode(OpusGenericDecoder *st,
> +const unsigned char *data, opus_int32 len, opus_int16 *pcm,
> +int frame_size, int decode_fec) {
> +int ret;
> +
> +#if defined(OPUS_HAVE_OPUS_PROJECTION_H)
inconsistent comapred to previous #ifdef
> +if (st->pr){
> +ret=opus_projection_decode(st->pr, data, len, pcm, frame_size,
> +decode_fec);
> +return ret;
> +}
> +#endif
> +ret=opus_multistream_decode(st->ms, data, len, pcm, frame_size,
> +decode_fec);
> +return ret;
> +}
> +
> +static int libopus_generic_decode_float(OpusGenericDecoder *st,
> +const unsigned char *data, opus_int32 len, float *pcm, int
> frame_size,
> +int decode_fec) {
> +int ret;
> +
> +#if defined(OPUS_HAVE_OPUS_PROJECTION_H)
> +if (st->pr){
> +ret=opus_projection_decode_float(st->pr, data, len, pcm, frame_size,
> +decode_fec);
> +return ret;
> +}
> +#endif
> +ret=opus_multistream_decode_float(st->ms, data, len, pcm, frame_size,
> +decode_fec);
> +return ret;
> +}
> +
> +#ifdef OPUS_HAVE_OPUS_PROJECTION_H
> +# define libopus_generic_decoder_ctl(st, request) \
> +((st)->pr != NULL ? \
> +opus_projection_decoder_ctl((st)->pr, request) : \
> +opus_multistream_decoder_ctl((st)->ms, request))
> +#else
> +# define libopus_generic_decoder_ctl(st, request) \
> +opus_multistream_decoder_ctl((st)->ms, request)
> +#endif
> +
> struct libopus_context {
> AVClass *class;
> -OpusMSDecoder *dec;
> +OpusGenericDecoder dec;
> int pre_skip;
> #ifndef OPUS_SET_GAIN
> union { int i; double d; } gain;
> @@ -46,12 +133,17 @@ struct libopus_context {
> };
>
> #define OPUS_HEAD_SIZE 19
> +#ifdef OPUS_HAVE_OPUS_PROJECTION_H
> +# define OPUS_MAX_CHANNELS 18
> +#else
> +# define OPUS_MAX_CHANNELS 8
> +#endif
>
> static av_cold int libopus_decode_init(AVCodecContext *avc)
> {
> struct libopus_context *opus = avc->priv_
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix handling of delete_segments when %v is present
> On 6 Apr 2018, at 18:27, Bodecs Bela wrote: > > Dear All, > > when var_stream_map option is used, %v must appear either in segment name > template or in the directory path. This latter case currently is not handled > and using delete_segments flag of hls_flags is broken now. This patch fixes > this issue. > The root cause of the bug was that HLSSegment struct only stores the final > filename part, but not the final directory path. Most of the cases, final > path info is unneded, It only necessary when you want to delete old segments > (e.g in case of live streaming). > Without variant streams it was unnecessary to store the final directory path, > because all segment were stored into the same directory. But introducing %v > in directory names either require to store the final directory path into > HLSSegment or associate segments with their variant streams to be able > deleting them later. I have choosen the second solution and introduced a > variant index data member into the segment struct. > > please review this patch. > > thank you in advance, > > Bela Bodecs > > > <0001-avformat-hlsenc-fix-handling-of-delete_segments-when.patch>___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel pushed Thanks Steven ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat/movenc: support writing iTunes cover image
Ping.
Any comments on this?
There was also recently the flacenc support for cover images, and the
question if some of this code should be moved to generic code in mux.c so
both can share it: e.g. storing the image packets to attached_pic - or if
that should be moved to the muxer private structs.
Thanks
Timo
On Mon, Apr 2, 2018 at 11:36 AM, Timo Teräs wrote:
> Fixes https://trac.ffmpeg.org/ticket/2798
>
> This makes movenc handle AV_DISPOSITION_ATTACHED_PIC and write
> the associated pictures in iTunes cover atom. This corresponds
> to how 'mov' demuxer parses and exposes the cover images when
> reading.
>
> Most of the existing track handling loops properly ignore
> these 'virtual streams' as MOVTrack->entry is never incremented
> for them. However, additional tests are added as needed to ignore
> them.
>
> Tested to produce valid output with:
> ffmpeg -i movie.mp4 -i thumb.jpg -disposition:v:1 attached_pic \
> -map 0 -map 1 -c copy movie-with-cover.mp4
>
> The cover image is also copied correctly with:
> ffmpeg -i movie-with-cover.mp4 -map 0 -c copy out.mp4
>
> AtomicParseley says that the attached_pic stream is properly
> not visible in the main tracks of the file.
>
> Signed-off-by: Timo Teräs
> ---
> libavformat/avformat.h | 2 +-
> libavformat/movenc.c | 77 ++
> ++--
> 2 files changed, 75 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index a2fe7c6bb2..b0e6092a35 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -941,7 +941,7 @@ typedef struct AVStream {
> * will contain the attached picture.
> *
> * decoding: set by libavformat, must not be modified by the caller.
> - * encoding: unused
> + * encoding: may be set by muxer to store the image until time of
> writing.
> */
> AVPacket attached_pic;
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index f6a314894c..69201c4092 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -143,7 +143,9 @@ static int co64_required(const MOVTrack *track)
>
> static int rtp_hinting_needed(const AVStream *st)
> {
> -/* Add hint tracks for each audio and video stream */
> +/* Add hint tracks for each real audio and video stream */
> +if (st->disposition & AV_DISPOSITION_ATTACHED_PIC)
> +return 0;
> return st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO ||
> st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO;
> }
> @@ -3421,6 +3423,49 @@ static int mov_write_int8_metadata(AVFormatContext
> *s, AVIOContext *pb,
> return size;
> }
>
> +static int mov_write_covr(AVIOContext *pb, AVFormatContext *s)
> +{
> +int64_t pos = 0;
> +int i, type;
> +
> +for (i = 0; i < s->nb_streams; i++) {
> +AVStream *st = s->streams[i];
> +
> +if (!(st->disposition & AV_DISPOSITION_ATTACHED_PIC) ||
> +st->attached_pic.size <= 0)
> +continue;
> +
> +switch (st->codecpar->codec_id) {
> +case AV_CODEC_ID_MJPEG:
> +type = 0xD;
> +break;
> +case AV_CODEC_ID_PNG:
> +type = 0xE;
> +break;
> +case AV_CODEC_ID_BMP:
> +type = 0x1B;
> +break;
> +default:
> +av_log(s, AV_LOG_ERROR, "unsupported codec_id (0x%x) for
> cover",
> + st->codecpar->codec_id);
> +continue;
> +}
> +
> +if (!pos) {
> +pos = avio_tell(pb);
> +avio_wb32(pb, 0);
> +ffio_wfourcc(pb, "covr");
> +}
> +avio_wb32(pb, 16 + st->attached_pic.size);
> +ffio_wfourcc(pb, "data");
> +avio_wb32(pb, type);
> +avio_wb32(pb , 0);
> +avio_write(pb, st->attached_pic.data, st->attached_pic.size);
> +}
> +
> +return pos ? update_size(pb, pos) : 0;
> +}
> +
> /* iTunes meta data list */
> static int mov_write_ilst_tag(AVIOContext *pb, MOVMuxContext *mov,
>AVFormatContext *s)
> @@ -3458,6 +3503,7 @@ static int mov_write_ilst_tag(AVIOContext *pb,
> MOVMuxContext *mov,
> mov_write_int8_metadata (s, pb, "hdvd","hd_video", 1);
> mov_write_int8_metadata (s, pb, "pgap","gapless_playback",1);
> mov_write_int8_metadata (s, pb, "cpil","compilation", 1);
> +mov_write_covr(pb, s);
> mov_write_trkn_tag(pb, mov, s, 0); // track number
> mov_write_trkn_tag(pb, mov, s, 1); // disc number
> mov_write_tmpo_tag(pb, s);
> @@ -3955,6 +4001,8 @@ static int mov_write_isml_manifest(AVIOContext *pb,
> MOVMuxContext *mov, AVFormat
> } else {
> continue;
> }
> +if (st->disposition & AV_DISPOSITION_ATTACHED_PIC)
> +continue;
>
> props = (AVCPBProperties*)av_stream_get_side_data(track->st,
> AV_PKT_DATA_CPB_PROPERTIES, NULL);
>
> @@ -4568,6 +4616,8 @@ static int mov_write_ftyp_tag(AVIOCont
Re: [FFmpeg-devel] [PATCH v1 2/3] avcodec/bitpacked: add interlace support
On 4/10/18, Patrick Keroulas wrote:
> From: Damien Riegel
>
> This codec is already capable of depacking some combinations of pixel
> formats and depth as defined in the RFC4175. The only difference between
> progressive and interlace is that either a packet will contain the whole
> frame, or only a field of the frame.
>
> As FFmpeg is not capable of handling fields only and recompose an
> interlaced frame from that, it has to be done by the codec. To achieve
> that, it must use two AVPacket: one for each field (top and bottom).
This is lie, FFmpeg handle fields only just fine.
>
> Signed-off-by: Damien Riegel
> Signed-off-by: Patrick Keroulas
> ---
> libavcodec/avcodec.h | 4 +++
> libavcodec/bitpacked.c | 76
> ++
> 2 files changed, 68 insertions(+), 12 deletions(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index fb0c6fa..350e8d9 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1480,6 +1480,10 @@ typedef struct AVPacket {
> */
> #define AV_PKT_FLAG_DISPOSABLE 0x0010
>
> +/**
> + * The packet contains a top field.
> + */
> +#define AV_PKT_FLAG_TOP_FIELD 0x0010
>
> enum AVSideDataParamChangeFlags {
> AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT = 0x0001,
> diff --git a/libavcodec/bitpacked.c b/libavcodec/bitpacked.c
> index 85d4bdd..d81703d 100644
> --- a/libavcodec/bitpacked.c
> +++ b/libavcodec/bitpacked.c
> @@ -33,15 +33,19 @@
>
> struct BitpackedContext {
> int (*decode)(AVCodecContext *avctx, AVFrame *frame,
> - AVPacket *pkt);
> + AVPacket *pkt, int top_field);
> +AVPacket *first_field_pkt;
> };
>
> /* For this format, it's a simple passthrough */
> static int bitpacked_decode_uyvy422(AVCodecContext *avctx, AVFrame *frame,
> -AVPacket *avpkt)
> +AVPacket *avpkt, int top_field)
> {
> int ret;
>
> +if (frame->interlaced_frame)
> +return AVERROR_PATCHWELCOME;
> +
> /* there is no need to copy as the data already match
> * a known pixel format */
> frame->buf[0] = av_buffer_ref(avpkt->buf);
> @@ -56,17 +60,22 @@ static int bitpacked_decode_uyvy422(AVCodecContext
> *avctx, AVFrame *frame,
> }
>
> static int bitpacked_decode_yuv422p10(AVCodecContext *avctx, AVFrame
> *frame,
> - AVPacket *avpkt)
> + AVPacket *avpkt, int top_field)
> {
> uint64_t frame_size = (uint64_t)avctx->width * (uint64_t)avctx->height
> * 20;
> uint64_t packet_size = (uint64_t)avpkt->size * 8;
> +int interlaced = frame->interlaced_frame;
> GetBitContext bc;
> uint16_t *y, *u, *v;
> int ret, i, j;
>
> -
> -if (frame_size > packet_size)
> +/* check packet size depending on the interlaced/progressive format */
> +if (interlaced) {
> +if ((frame_size >> 1) > packet_size)
> +return AVERROR_INVALIDDATA;
> +} else if (frame_size > packet_size) {
> return AVERROR_INVALIDDATA;
> +}
>
> if (avctx->width % 2)
> return AVERROR_PATCHWELCOME;
> @@ -75,7 +84,18 @@ static int bitpacked_decode_yuv422p10(AVCodecContext
> *avctx, AVFrame *frame,
> if (ret)
> return ret;
>
> -for (i = 0; i < avctx->height; i++) {
> +/*
> + * if the frame is interlaced, the avpkt we are getting is either the
> top
> + * or the bottom field. If it's the bottom field, it contains all the
> odd
> + * lines of the recomposed frame, so we start at offset 1.
> + */
> +i = (interlaced && !top_field) ? 1 : 0;
> +
> +/*
> + * Packets from interlaced frames contain either even lines, or odd
> + * lines, so increment by two in that case.
> + */
> +for (; i < avctx->height; interlaced ? i += 2 : i++) {
> y = (uint16_t*)(frame->data[0] + i * frame->linesize[0]);
> u = (uint16_t*)(frame->data[1] + i * frame->linesize[1]);
> v = (uint16_t*)(frame->data[2] + i * frame->linesize[2]);
> @@ -100,13 +120,20 @@ static av_cold int
> bitpacked_init_decoder(AVCodecContext *avctx)
>
> if (avctx->codec_tag == MKTAG('U', 'Y', 'V', 'Y')) {
> if (avctx->bits_per_coded_sample == 16 &&
> -avctx->pix_fmt == AV_PIX_FMT_UYVY422)
> +avctx->pix_fmt == AV_PIX_FMT_UYVY422) {
> +
> +if (avctx->field_order > AV_FIELD_PROGRESSIVE) {
> +av_log(avctx, AV_LOG_ERROR, "interlaced not yet supported
> for 8-bit\n");
> +return AVERROR_PATCHWELCOME;
> +}
> +
> bc->decode = bitpacked_decode_uyvy422;
> -else if (avctx->bits_per_coded_sample == 20 &&
> - avctx->pix_fmt == AV_PIX_FMT_YUV422P10)
> +} else if (avctx->bits_per_coded_sample == 20 &&
> + avctx->pix_fmt == AV_PIX_FMT_YUV422P10) {
> bc->decode = bitpacked_decode_yuv422p10;
> -else
> +
