Re: [FFmpeg-devel] [PATCH 1/1] [RFC] ffprobe: report DAR even if SAR is undefined
On 17.04.2018 07:32, Timo Teras wrote: [...] Do note that calculating the reduced DAR requires some mathematics which may not be simple to do from e.g. shell or simple scripting languages. This is the primary reason why I was hoping ffprobe to do this for me. Would it be acceptable to print the reduced "raw" height:width ratio as surface_aspect_ratio (or with some other better name)? The application interpreting the info can then use that instead of display_aspect_ratio when it's N/A. Depending on the application use-case it might be sufficient to use a float DAR, i.e. when comparing to a list of values like 4:3, 16:9, etc (within some "epsilon" delta, of course). Regards, Tobias ___ 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.
> On 11 Apr 2018, at 07:13, Richard Shaffer wrote: > > > > 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. I
Re: [FFmpeg-devel] [PATCH v2] avformat/hls: clean up duplicate option fields
> On 17 Apr 2018, at 03:02, Richard Shaffer wrote:
>
> On Fri, Apr 13, 2018 at 5:14 PM, wrote:
>
>> 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.
>> ---
>> The original patch caused the buffer pointed to by new_cookies in open_url
>> to be
>> leaked. The only thing that buffer is used for is to store the value until
>> it
>> can be passed to av_dict_set. To fix the leak, v2 of the patch simply calls
>> av_dict_set with the AV_DICT_DONT_STRDUP_VAL flag, so that the dictionary
>> takes
>> ownership of the memory instead of copying it again.
>>
>> libavformat/hls.c | 74 +++---
>> -
>> 1 file changed, 9 insertions(+), 65 deletions(-)
>>
>> diff --git a/libavformat/hls.c b/libavformat/hls.c
>> index 1257cd101c..d6158c0ada 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;
>> @@ -267,10 +262,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;
>> }
>>
>> @@ -593,14 +584,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)
>> {
>> @@ -684,12 +667,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,
>> AV_DICT_DONT_STRDUP_VAL);
>> }
>>
>> av_dict_free(&tmp);
>> @@ -736,14 +715,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);
>> @@ -1169,14 +1141,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);
>>
>> @@ -1193,7 +1157,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
Re: [FFmpeg-devel] [PATCH v2] libavformat/dashdec: Avoid multiple HTTP requests for initialization segment that is common among all representations
> On 10 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 | 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->i
Re: [FFmpeg-devel] [PATCH 1/1] [RFC] ffprobe: report DAR even if SAR is undefined
On Tue, 17 Apr 2018 01:02:43 +0200 Michael Niedermayer wrote: > On Mon, Apr 16, 2018 at 07:56:34PM +0200, Marton Balint wrote: > > > > On Mon, 16 Apr 2018, Timo Teras wrote: > > > > >On Sun, 15 Apr 2018 16:42:01 +0200 (CEST) > > >Marton Balint wrote: > > > > > >>On Sun, 15 Apr 2018, Timo Teräs wrote: > > >> > > >>> Calculate DAR with assumed SAR 1:1 when SAR is undefined. Same > > >>> assumption is done in ffplay to create the play window. Usually > > >>> DAR is more useful metadata than SAR when e.g. choosing which > > >>> media of multiple versions to use to fit the display. > > >> > > >>I don't think it's good idea to generally assume 1:1 > > >>display_aspect_ratio for every undefined sample aspect ratio. It > > >>depends heavily on your actual use case. If MOV/MP4 specifies that > > >>1:1 SAR should be used, then maybe you should fix > > >>av_guess_sample_aspect_ratio instead, and return 1:1 there if the > > >>format context is MOV/MP4. You may add a demuxer (AVFMT) flag to > > >>signal that such behaviour should be used, and > > >>av_guess_sample_aspect_ratio can check for that demuxer flag. > > > > > >Looking at code, av_guess_sample_aspect_ratio() is used only in > > >ffplay and ffprobe. > > > > > >ffplay implicitly assumes undefined SAR is 1:1 to create the > > >playback window properly; this happens in calculate_display_rect() > > >when "bad" aspect_ratio is reset to 1.0. > > > > > >I would expect same logic would have been useful in ffprobe. This > > >would help to report back to user what ffplay is going to do with > > >the video. Or at least give a hint on how to categorize the clip. > > >SAR 1:1 is pretty good guess for most formats. > > > > I really don't see why don't you fix your application instead which > > parses ffprobe output? If you see N/A aspect ratio, use 1:1. > > > > To be frank, I am not sure if ffprobe should use > > av_guess_aspect_ratio when it displays stream metadata. It is only > > there now to av_reduce the aspect > > > ratios and to sanitize some invalid aspect ratios to 0/1. FFprobe's > > job is to return stream metadata as is, not to make guesses. > > a very minor somewhat on topic nitpick, 0/0 would be mathamtically > more correct as unknown than 0/1. If one doesnt immedeatly see why, > one can look at width/height vs height/width to see one of many > reasons why See my earlier patch that changes it to report as "N/A". This is what the code thought it was doing earlier, but due to incorrect validity test was not doing in that specific code path (works on other code paths): https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228141.html Do note that calculating the reduced DAR requires some mathematics which may not be simple to do from e.g. shell or simple scripting languages. This is the primary reason why I was hoping ffprobe to do this for me. Would it be acceptable to print the reduced "raw" height:width ratio as surface_aspect_ratio (or with some other better name)? The application interpreting the info can then use that instead of display_aspect_ratio when it's N/A. Timo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hls: remove redundant code
> On 16 Apr 2018, at 08:37, Jun Zhao wrote:
>
>
>
> On 2018/4/13 20:29, Steven Liu wrote:
>> 2018-04-13 16:19 GMT+08:00 Jun Zhao :
>>>
>>> On 2018/4/12 16:48, Steven Liu wrote:
Signed-off-by: Steven Liu
---
libavformat/hls.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index ae0545a086..74f0c2ccc5 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -945,14 +945,8 @@ static struct segment *next_segment(struct playlist
*pls)
return pls->segments[n];
}
-enum ReadFromURLMode {
-READ_NORMAL,
-READ_COMPLETE,
-};
-
static int read_from_url(struct playlist *pls, struct segment *seg,
- uint8_t *buf, int buf_size,
- enum ReadFromURLMode mode)
+ uint8_t *buf, int buf_size)
{
int ret;
@@ -960,12 +954,9 @@ static int read_from_url(struct playlist *pls, struct
segment *seg,
if (seg->size >= 0)
buf_size = FFMIN(buf_size, seg->size - pls->cur_seg_offset);
-if (mode == READ_COMPLETE) {
-ret = avio_read(pls->input, buf, buf_size);
-if (ret != buf_size)
-av_log(NULL, AV_LOG_ERROR, "Could not read complete
segment.\n");
-} else
-ret = avio_read(pls->input, buf, buf_size);
+ret = avio_read(pls->input, buf, buf_size);
+if (ret != buf_size)
+av_log(NULL, AV_LOG_ERROR, "Could not read complete segment.\n");
if (ret > 0)
pls->cur_seg_offset += ret;
@@ -1085,7 +1076,7 @@ static void intercept_id3(struct playlist *pls,
uint8_t *buf,
while (1) {
/* see if we can retrieve enough data for ID3 header */
if (*len < ID3v2_HEADER_SIZE && buf_size >= ID3v2_HEADER_SIZE) {
-bytes = read_from_url(pls, seg, buf + *len, ID3v2_HEADER_SIZE
- *len, READ_COMPLETE);
+bytes = read_from_url(pls, seg, buf + *len, ID3v2_HEADER_SIZE
- *len);
if (bytes > 0) {
if (bytes == ID3v2_HEADER_SIZE - *len)
@@ -1137,7 +1128,7 @@ static void intercept_id3(struct playlist *pls,
uint8_t *buf,
if (remaining > 0) {
/* read the rest of the tag in */
-if (read_from_url(pls, seg, pls->id3_buf + id3_buf_pos,
remaining, READ_COMPLETE) != remaining)
+if (read_from_url(pls, seg, pls->id3_buf + id3_buf_pos,
remaining) != remaining)
break;
id3_buf_pos += remaining;
av_log(pls->ctx, AV_LOG_DEBUG, "Stripped additional %d HLS
ID3 bytes\n", remaining);
@@ -1151,7 +1142,7 @@ static void intercept_id3(struct playlist *pls,
uint8_t *buf,
/* re-fill buffer for the caller unless EOF */
if (*len >= 0 && (fill_buf || *len == 0)) {
-bytes = read_from_url(pls, seg, buf + *len, buf_size - *len,
READ_NORMAL);
+bytes = read_from_url(pls, seg, buf + *len, buf_size - *len);
/* ignore error if we already had some data */
if (bytes >= 0)
@@ -1311,7 +1302,7 @@ static int update_init_section(struct playlist *pls,
struct segment *seg)
av_fast_malloc(&pls->init_sec_buf, &pls->init_sec_buf_size, sec_size);
ret = read_from_url(pls, seg->init_section, pls->init_sec_buf,
-pls->init_sec_buf_size, READ_COMPLETE);
+pls->init_sec_buf_size);
>>> Didn't care ret < pls->init_sec_buf_size ?
>> avio_read is full size read, so it will return error, or
>> init_sec_buf_size, as your question, maybe it will happen then the
>> read_from_url called avio_read_partiall.
> Thanks the clarify, I think the patch is Ok now.
pushed
ff_format_io_close(pls->parent, &pls->input);
if (ret < 0)
@@ -1506,7 +1497,7 @@ reload:
}
seg = current_segment(v);
-ret = read_from_url(v, seg, buf, buf_size, READ_NORMAL);
+ret = read_from_url(v, seg, buf, buf_size);
if (ret > 0) {
if (just_opened && v->is_id3_timestamped != 0) {
/* Intercept ID3 tags here, elementary audio streams are
required
>>> LGTM except one question.
>>> ___
>>> 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
Re: [FFmpeg-devel] [PATCH v2] avformat/movenc: support writing iTunes cover image
On Tue, 17 Apr 2018 00:01:42 +0100
Rostislav Pehlivanov wrote:
> On 16 April 2018 at 15:05, Timo Teras wrote:
>
> > On Mon, 16 Apr 2018 10:53:43 -0300
> > James Almer wrote:
> >
> > > On 4/14/2018 3:32 PM, Timo Teräs wrote:
> > > > 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.
> > >
> > > This is failing when i try to mux a jpg as cover art into m4a
> > > (Ipod muxer). It complains about missing codec tag for mjpeg. Is
> > > the covr atom valid for that format?
> >
> > Yes, it's valid for m4a.
> >
> > > Adding an entry to codec_ipod_tags[] may fix it, but that alone
> > > would probably then allow non cover art video tracks using that
> > > codec, which i assume is undesirable.
> >
> > For audio formats, e.g. mp3, query codec returns MKTAG('A', 'P',
> > 'I', 'C') to indicate that the image works only as attached picture.
> >
> > But even for video formats, it would be nice if query codec can
> > properly tell which image formats it does based on disposition. The
> > codec list for cover images is different from generic video streams.
> >
> > Any suggestions how to do that properly?
>
> What's the problem with doing what mp3 does?
Because mp3 files take only audio. It can give universal reply that the
video codecs are valid for cover images only. Mp4/mov in general takes
also video. avformat_query_codec() or AVOutputFormat.query_codec() (if
we'd define it) does not have stream config info or it's disposition.
Ultimately the problem is that currently codec negotiation assumes the
acceptable codecs are same regardless of disposition. When mp3 started
to support this, a hack was added to query_codec() to return special
code to mean "only as cover art". But in mov/mp4 we cannot do that
because the same video codec can be used for a main stream too.
To me it sounds like we need to introduce new version of
avformat_query_codec() that gets the whole AVStream config, or at least
the stream's disposition information so we can return different codec
matches based on disposition. Or modify AVOutputFormat's codec_tag (or
add something new) that can specify the "attached_pic" video codecs
that get's used properly.
Since the above will likely be ABI change, perhaps the existing patch
can be taken as such, and the above be left a follow up fix. The patch
implements stuff correctly for video enabled mp4/mov, so as it is
now it's a big improvement or works correctly on the mp4/mov file
subtypes it happens to support.
Timo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] ffserver: Implement refcounted segments.
---
segment.c | 161 ++
segment.h | 114
2 files changed, 275 insertions(+)
create mode 100644 segment.c
create mode 100644 segment.h
diff --git a/segment.c b/segment.c
new file mode 100644
index 000..3afe5aa
--- /dev/null
+++ b/segment.c
@@ -0,0 +1,161 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include "segment.h"
+#include
+
+#include
+#include
+
+
+void segment_save(struct Segment *seg, const char *filename)
+{
+AVFormatContext *ofmt_ctx = NULL;
+int ret;
+
+avformat_alloc_output_context2(&ofmt_ctx, NULL, NULL, filename);
+if (!ofmt_ctx) {
+av_log(NULL, AV_LOG_ERROR, "Could not allocate output to save Segment
%d.\n", seg->id);
+return;
+}
+
+if ((ret = avio_open(&ofmt_ctx->pb, filename, AVIO_FLAG_WRITE)) < 0) {
+av_log(ofmt_ctx, AV_LOG_ERROR,
+"Could not open output io context to save Segment %d: %s.\n",
seg->id, av_err2str(ret));
+return;
+}
+
+avio_write(ofmt_ctx->pb, seg->buf, seg->size);
+avio_flush(ofmt_ctx->pb);
+avio_close(ofmt_ctx->pb);
+avformat_free_context(ofmt_ctx);
+}
+
+void segment_free(struct Segment *seg)
+{
+av_log(NULL, AV_LOG_DEBUG, "Freeing segment\n");
+avformat_free_context(seg->fmt_ctx);
+av_free(seg->io_ctx->buffer);
+av_free(seg->io_ctx);
+av_free(seg->buf);
+av_free(seg->ts);
+av_free(seg);
+}
+
+void segment_ref(struct Segment *seg)
+{
+pthread_mutex_lock(&seg->nb_read_lock);
+seg->nb_read++;
+av_log(NULL, AV_LOG_DEBUG, "%04d ref Readers: %d\n", seg->id,
seg->nb_read);
+pthread_mutex_unlock(&seg->nb_read_lock);
+}
+
+void segment_unref(struct Segment *seg)
+{
+pthread_mutex_lock(&seg->nb_read_lock);
+seg->nb_read--;
+pthread_mutex_unlock(&seg->nb_read_lock);
+av_log(NULL, AV_LOG_DEBUG, "%04d unref Readers: %d\n", seg->id,
seg->nb_read);
+if (seg->nb_read == 0) {
+segment_free(seg);
+}
+}
+
+int segment_write(void *opaque, unsigned char *buf, int buf_size)
+{
+struct Segment *seg = (struct Segment*) opaque;
+seg->size += buf_size;
+seg->buf = (char*) av_realloc(seg->buf, seg->size);
+memcpy(seg->buf + seg->size - buf_size, buf, buf_size);
+return buf_size;
+}
+
+int segment_read(void *opaque, unsigned char *buf, int buf_size)
+{
+struct SegmentReadInfo *info = (struct SegmentReadInfo*) opaque;
+buf_size = buf_size < info->left ? buf_size : info->left;
+
+/* copy internal buffer data to buf */
+memcpy(buf, info->buf, buf_size);
+info->buf += buf_size;
+info->left -= buf_size;
+return buf_size ? buf_size : AVERROR_EOF;
+}
+
+
+void segment_close(struct Segment *seg)
+{
+av_write_trailer(seg->fmt_ctx);
+}
+
+void segment_init(struct Segment **seg_p, AVFormatContext *fmt)
+{
+int ret;
+int i;
+AVStream *in_stream, *out_stream;
+struct Segment *seg = (struct Segment*) av_malloc(sizeof(struct Segment));
+
+seg->ifmt = fmt->iformat;
+seg->fmt_ctx = NULL;
+seg->nb_read = 0;
+seg->size = 0;
+seg->ts = NULL;
+seg->ts_len = 0;
+seg->buf = NULL;
+seg->avio_buffer = (unsigned char*) av_malloc(AV_BUFSIZE);
+pthread_mutex_init(&seg->nb_read_lock, NULL);
+seg->io_ctx = avio_alloc_context(seg->avio_buffer, AV_BUFSIZE, 1, seg,
NULL, &segment_write, NULL);
+seg->io_ctx->seekable = 0;
+avformat_alloc_output_context2(&seg->fmt_ctx, NULL, "matroska", NULL);
+if ((ret = av_opt_set_int(seg->fmt_ctx, "flush_packets", 1,
AV_OPT_SEARCH_CHILDREN)) < 0) {
+av_log(seg->fmt_ctx, AV_LOG_WARNING, "Could not set flush_packets!\n");
+}
+
+seg->fmt_ctx->flags |= AVFMT_FLAG_GENPTS;
+seg->fmt_ctx->oformat->flags &= AVFMT_NOFILE;
+
+av_log(seg->fmt_ctx, AV_LOG_DEBUG, "Initializing segment\n");
+
+for (i = 0; i < fmt->nb_streams; i++) {
+in_stream = fmt->streams[i];
+out_stream = avformat_new_stream(seg->fmt_ctx, NULL);
+if (!out_stream) {
+av_log(seg->fmt_ctx, AV_LOG_WARNING, "Failed allocating output
stream\n");
+continue;
+}
+ret = avcodec_parameters_copy(out_stream->co
[FFmpeg-devel] [PATCH 3/4] ffserver: Implement ffserver and add Makefile
---
Makefile | 15 ++
ffserver.c | 477 +
2 files changed, 492 insertions(+)
create mode 100644 Makefile
create mode 100644 ffserver.c
diff --git a/Makefile b/Makefile
new file mode 100644
index 000..b077039
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,15 @@
+all: ffserver
+LAV_FLAGS = $(shell pkg-config --libs --cflags libavformat libavcodec
libavutil)
+# LAV_FLAGS = -L/usr/local/lib -lavcodec -lavformat -lavutil
+
+ffserver: segment.o publisher.o ffserver.c
+ cc -g -Wall $(LAV_FLAGS) -lpthread -o ffserver segment.o publisher.o
ffserver.c
+
+segment.o: segment.c segment.h
+ cc -g -Wall $(LAV_FLAGS) -lpthread -c segment.c
+
+publisher.o: publisher.c publisher.h
+ cc -g -Wall $(LAV_FLAGS) -lpthread -c publisher.c
+
+clean:
+ rm *.o ffserver
diff --git a/ffserver.c b/ffserver.c
new file mode 100644
index 000..b0ff00e
--- /dev/null
+++ b/ffserver.c
@@ -0,0 +1,477 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * multimedia server based on the FFmpeg libraries
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "segment.h"
+#include "publisher.h"
+
+#define BUFFER_SECS 30
+#define LISTEN_TIMEOUT_MSEC 1000
+
+struct ReadInfo {
+struct PublisherContext *pub;
+AVFormatContext *ifmt_ctx;
+char *in_filename;
+};
+
+struct WriteInfo {
+struct PublisherContext *pub;
+int thread_id;
+};
+
+struct AcceptInfo {
+struct PublisherContext *pub;
+AVFormatContext *ifmt_ctx;
+const char *out_uri;
+};
+
+
+void *read_thread(void *arg)
+{
+struct ReadInfo *info = (struct ReadInfo*) arg;
+AVFormatContext *ifmt_ctx = info->ifmt_ctx;
+int ret, i;
+int video_idx = -1;
+int id = 0;
+int64_t pts, now, start;
+int64_t *ts;
+struct Segment *seg = NULL;
+AVPacket pkt;
+AVStream *in_stream;
+AVRational tb;
+tb.num = 1;
+tb.den = AV_TIME_BASE;
+AVStream *stream;
+AVCodecParameters *params;
+enum AVMediaType type;
+
+if ((ret = avformat_find_stream_info(ifmt_ctx, NULL)) < 0) {
+av_log(ifmt_ctx, AV_LOG_ERROR, "Could not get input stream info.\n");
+goto end;
+}
+
+av_log(ifmt_ctx, AV_LOG_INFO, "Finding video stream.\n");
+for (i = 0; i < ifmt_ctx->nb_streams; i++) {
+av_log(ifmt_ctx, AV_LOG_DEBUG, "Checking stream %d\n", i);
+stream = ifmt_ctx->streams[i];
+params = stream->codecpar;
+type = params->codec_type;
+if (type == AVMEDIA_TYPE_VIDEO) {
+video_idx = i;
+break;
+}
+}
+if (video_idx == -1) {
+av_log(ifmt_ctx, AV_LOG_ERROR, "No video stream found.\n");
+goto end;
+}
+
+
+// All information needed to start segmenting the file is gathered now.
+// start BUFFER_SECS seconds "in the past" to "catch up" to real-time. Has
no effect on streamed sources.
+start = av_gettime_relative() - BUFFER_SECS * AV_TIME_BASE;
+
+// segmenting main-loop
+
+for (;;) {
+ret = av_read_frame(ifmt_ctx, &pkt);
+if (ret < 0)
+break;
+
+in_stream = ifmt_ctx->streams[pkt.stream_index];
+if (pkt.pts == AV_NOPTS_VALUE) {
+pkt.pts = 0;
+}
+if (pkt.dts == AV_NOPTS_VALUE) {
+pkt.dts = 0;
+}
+
+// current pts
+pts = av_rescale_q(pkt.pts, in_stream->time_base, tb);
+
+// current stream "uptime"
+now = av_gettime_relative() - start;
+
+// simulate real-time reading
+while (pts > now) {
+usleep(1000);
+now = av_gettime_relative() - start;
+}
+
+// keyframe or first Segment
+if ((pkt.flags & AV_PKT_FLAG_KEY && pkt.stream_index == video_idx) ||
!seg) {
+if (seg) {
+segment_close(seg);
+publisher_push_segment(info->pub, seg);
+av_log(NULL, AV_LOG_DEBUG, "New segment pushed.\n");
+publish(info->pub);
+ av_log(NULL, AV_LOG_DEBUG, "Published new
segment.\n");
+}
+
[FFmpeg-devel] [GSoC] Qualification task, simple ffserver implementation.
I have made the proposed changes: - AVFifoBuffer mutex-locking - Added license header to files - Use avio for segment_save() instead of FILE * - Use av_malloc()/av_free() consistently - Add context to logging (where possible) - Simplified client_log() to print without buffer - Simplified stat counting with enum array I found av_dynarray to be fitting for what i was doing so: - Replace segment_append_ts() by using av_dynarray I am not 100% happy with the state of how things are working right now, but I'm running into some walls I'm having trouble fighting with. - segment_save() does not save a correctly playable file. In my tests mpv stopped playback for each file a little too early. They also report 1000 fps, so I think I might be missing something. However, the http stream has no playback problems, but also reports 1000 fps. - Seemingly random conditions where incorrect dts/pts values are tried to be written with av_write_frame() which then fails. - Seemingly random playback issues where timestamps also seem involved: mpv output during playback: > Invalid audio PTS: 27.593500 -> 32.933500 > [ffmpeg/video] vp9: Not all references are available mpv manages to continue playback, but the image is a corrupted frame until the next keyframe. - Most likely related to above problems is the timestamp handling in general. Right now every segment just stores a dynamic array for these. Using the dts and pts from the muxed in-memory segment does not work, I'd have to do some research again why it doesn't. What would be a better approach for this? - Seemingly random segmentation faults when ungracefully disconnecting clients. To make it more mysterious, the segfaults occur on clients that were not disconnected. If no clients are disconnected no segfaults occur. (See: https://gist.github.com/klaxa/3ddce28d99cab9ca45824af0942bfce3 for a stacktrace) Thanks! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] ffserver: Implement publisher
---
publisher.c | 301
publisher.h | 156 +++
2 files changed, 457 insertions(+)
create mode 100644 publisher.c
create mode 100644 publisher.h
diff --git a/publisher.c b/publisher.c
new file mode 100644
index 000..65dca70
--- /dev/null
+++ b/publisher.c
@@ -0,0 +1,301 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "publisher.h"
+#include "segment.h"
+#include
+
+void client_log(struct Client *c)
+{
+av_log(NULL, AV_LOG_INFO, "State: ");
+switch(c->state) {
+case FREE:
+av_log(NULL, AV_LOG_INFO, "FREE\n");
+break;
+case RESERVED:
+av_log(NULL, AV_LOG_INFO, "RESERVED\n");
+break;
+case WAIT:
+av_log(NULL, AV_LOG_INFO, "WAIT\n");
+break;
+case WRITABLE:
+av_log(NULL, AV_LOG_INFO, "WRITABLE\n");
+break;
+case BUSY:
+av_log(NULL, AV_LOG_INFO, "BUSY\n");
+break;
+case BUFFER_FULL:
+av_log(NULL, AV_LOG_INFO, "BUFFER_FULL\n");
+break;
+default:
+av_log(NULL, AV_LOG_INFO, "UNKOWN\n");
+break;
+}
+}
+
+void client_disconnect(struct Client *c, int write_trailer)
+{
+struct Segment *seg;
+if (write_trailer)
+av_write_trailer(c->ofmt_ctx);
+avio_close(c->ofmt_ctx->pb);
+avformat_free_context(c->ofmt_ctx);
+pthread_mutex_lock(&c->buffer_lock);
+while(av_fifo_size(c->buffer)) {
+av_fifo_generic_read(c->buffer, &seg, sizeof(struct Segment*), NULL);
+segment_unref(seg);
+}
+pthread_mutex_unlock(&c->buffer_lock);
+c->ofmt_ctx = NULL;
+client_set_state(c, FREE);
+c->current_segment_id = -1;
+}
+
+void client_set_state(struct Client *c, enum State state)
+{
+pthread_mutex_lock(&c->state_lock);
+c->state = state;
+pthread_mutex_unlock(&c->state_lock);
+}
+
+void client_push_segment(struct Client *c, struct Segment *seg)
+{
+pthread_mutex_lock(&c->buffer_lock);
+if (av_fifo_space(c->buffer) == 0) {
+av_log(NULL, AV_LOG_WARNING, "Client buffer full, dropping
Segment.\n");
+client_set_state(c, BUFFER_FULL);
+pthread_mutex_unlock(&c->buffer_lock);
+return;
+}
+segment_ref(seg);
+av_fifo_generic_write(c->buffer, &seg, sizeof(struct Segment*), NULL);
+pthread_mutex_unlock(&c->buffer_lock);
+client_set_state(c, WRITABLE);
+}
+
+void publisher_init(struct PublisherContext **pub)
+{
+int i;
+struct PublisherContext *pc = (struct PublisherContext*)
av_malloc(sizeof(struct PublisherContext));
+pc->nb_threads = 4;
+pc->current_segment_id = -1;
+pc->shutdown = 0;
+pc->buffer = av_fifo_alloc_array(sizeof(struct Segment), MAX_SEGMENTS);
+pc->fs_buffer = av_fifo_alloc_array(sizeof(struct Segment), MAX_SEGMENTS);
+pthread_mutex_init(&pc->buffer_lock, NULL);
+pthread_mutex_init(&pc->fs_buffer_lock, NULL);
+for (i = 0; i < MAX_CLIENTS; i++) {
+struct Client *c = &pc->clients[i];
+c->buffer = av_fifo_alloc_array(sizeof(struct Segment), MAX_SEGMENTS);
+c->id = i;
+c->current_segment_id = -1;
+pthread_mutex_init(&c->state_lock, NULL);
+pthread_mutex_init(&c->buffer_lock, NULL);
+client_set_state(c, FREE);
+}
+*pub = pc;
+}
+
+void publisher_push_segment(struct PublisherContext *pub, struct Segment *seg)
+{
+struct Segment *drop;
+pthread_mutex_lock(&pub->buffer_lock);
+pthread_mutex_lock(&pub->fs_buffer_lock);
+av_fifo_generic_write(pub->buffer, &seg, sizeof(struct Segment*), NULL);
+segment_ref(seg);
+if (av_fifo_size(pub->fs_buffer) >= BUFFER_SEGMENTS * sizeof(struct
Segment*)) {
+av_fifo_generic_read(pub->fs_buffer, &drop, sizeof(struct Segment*),
NULL);
+segment_unref(drop);
+}
+av_fifo_generic_write(pub->fs_buffer, &seg, sizeof(struct Segment*), NULL);
+pthread_mutex_unlock(&pub->buffer_lock);
+pthread_mutex_unlock(&pub->fs_buffer_lock);
+segment_ref(seg);
+}
+
+int publisher_reserve_client(struct PublisherContext *pub)
+{
+int i;
+for (i = 0; i < MAX_CLIENTS; i++) {
+switch(pub->clients[i].state) {
+case FREE:
+client_
[FFmpeg-devel] [PATCH 4/4] ffserver: Add basic documentation
--- Documentation.txt | 64 +++ 1 file changed, 64 insertions(+) create mode 100644 Documentation.txt diff --git a/Documentation.txt b/Documentation.txt new file mode 100644 index 000..0f7485c --- /dev/null +++ b/Documentation.txt @@ -0,0 +1,64 @@ +About +- + +In its current for this is a HTTP live-streaming server. A media file can be +streamed to a number of clients with the correct media file being muxed on- +the-fly for each client starting at the current position in the stream. +The stream received by the clients is simply a HTTP response to an HTTP +request. + + +Documentation +- + +The current implementation has three different types of work that is done in +different threads. These types are: reading a stream, accepting HTTP +connections and writing media data to clients. + +The design tries to follow a Publisher-Subscriber-Pattern. The PublisherContext +struct contains buffers of read media data and the list of clients. Clients +themselves contain a buffer of media data that still has to be sent to them. + +The reading thread takes care of segmenting the stream into independent chunks +of data and pushing it to the PublisherContext, which publishes the new Segment +to connected clients. This publishing only adds this Segment to the client's +buffer. + +The writing thread does the actual writing of data over the network. It checks +each client's state and if there is data available that can be written to that +client it is sent. + +The accept thread accepts new clients over HTTP and if not all client slots are +in use, writes the stream-header and adds the client to the PublisherContext. + +A Segment is only stored in memory once and is refcounted. Buffers in the +PublisherContext and clients contain pointers to Segments. + +Buffers are implemented using AVFifoBuffer. + +Client states are protected by pthread-mutex-locks, making it possible to run +multiple write threads. + +Usage +- + +Currently streams can be supplied as a stream through stdin or any ffmpeg- +compatible URI, e.g. files or network locations. Examples: + +cat somefile.mkv | ./ffserver + +./ffserver somefile.mkv + +./ffserver http://somehost/somefile.mkv + +This will start reading the file and open port 8080 for HTTP client connections. +The stream is read in real time from whatever resource it is retrieved. +Currently a maximum of 16 clients is implemented. + +The server responds to any GET request with the mediastream. Any other request +is answered with a HTTP 400 error. +If the maximum number of clients is reached the server responds with a 503 HTTP +error if a new client wants to connect. + +Once the stream ends the server will write all the remaining data to all +connected clients before closing the connections and exiting. -- 2.16.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/5] avcodec/cinepak: Skip empty frames
Speeds up decoding from 3 to 0.1 seconds for
6302/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5626371985375232
Fixes: Timeout
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cinepak.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavcodec/cinepak.c b/libavcodec/cinepak.c
index ba0589582f..17e3afc35c 100644
--- a/libavcodec/cinepak.c
+++ b/libavcodec/cinepak.c
@@ -444,6 +444,7 @@ static int cinepak_decode_frame(AVCodecContext *avctx,
const uint8_t *buf = avpkt->data;
int ret = 0, buf_size = avpkt->size;
CinepakContext *s = avctx->priv_data;
+int num_strips;
s->data = buf;
s->size = buf_size;
@@ -451,6 +452,12 @@ static int cinepak_decode_frame(AVCodecContext *avctx,
if (s->size < 10)
return AVERROR_INVALIDDATA;
+num_strips = AV_RB16 (&s->data[8]);
+
+//Empty frame, do not waste time
+if (!num_strips)
+return buf_size;
+
if ((ret = cinepak_predecode_check(s)) < 0) {
av_log(avctx, AV_LOG_ERROR, "cinepak_predecode_check failed\n");
return ret;
--
2.17.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/5] avcodec/dsicinvideo: Fail if there is only a small fraction of the data available that comprises a full frame
Fixes: Timeout Fixes: 6306/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DSICINVIDEO_fuzzer-5079253549842432 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/dsicinvideo.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/libavcodec/dsicinvideo.c b/libavcodec/dsicinvideo.c index add7afa383..aa080417d2 100644 --- a/libavcodec/dsicinvideo.c +++ b/libavcodec/dsicinvideo.c @@ -158,6 +158,9 @@ static int cin_decode_lzss(const unsigned char *src, int src_size, } } +if (dst_end - dst > dst_size - dst_size/10) +return AVERROR_INVALIDDATA; + return 0; } @@ -184,6 +187,10 @@ static int cin_decode_rle(const unsigned char *src, int src_size, } dst += len; } + +if (dst_end - dst > dst_size - dst_size/10) +return AVERROR_INVALIDDATA; + return 0; } -- 2.17.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/5] avcodec/dsicinvideo: Propagate errors from cin_decode_rle()
Signed-off-by: Michael Niedermayer
---
libavcodec/dsicinvideo.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/libavcodec/dsicinvideo.c b/libavcodec/dsicinvideo.c
index f95cbc74a0..add7afa383 100644
--- a/libavcodec/dsicinvideo.c
+++ b/libavcodec/dsicinvideo.c
@@ -226,27 +226,35 @@ static int cinvideo_decode_frame(AVCodecContext *avctx,
* surface.width = surface.pitch */
switch (bitmap_frame_type) {
case 9:
-cin_decode_rle(buf, bitmap_frame_size,
+res = cin_decode_rle(buf, bitmap_frame_size,
cin->bitmap_table[CIN_CUR_BMP], cin->bitmap_size);
+if (res < 0)
+return res;
break;
case 34:
-cin_decode_rle(buf, bitmap_frame_size,
+res = cin_decode_rle(buf, bitmap_frame_size,
cin->bitmap_table[CIN_CUR_BMP], cin->bitmap_size);
+if (res < 0)
+return res;
cin_apply_delta_data(cin->bitmap_table[CIN_PRE_BMP],
cin->bitmap_table[CIN_CUR_BMP], cin->bitmap_size);
break;
case 35:
bitmap_frame_size = cin_decode_huffman(buf, bitmap_frame_size,
cin->bitmap_table[CIN_INT_BMP], cin->bitmap_size);
-cin_decode_rle(cin->bitmap_table[CIN_INT_BMP], bitmap_frame_size,
+res = cin_decode_rle(cin->bitmap_table[CIN_INT_BMP],
bitmap_frame_size,
cin->bitmap_table[CIN_CUR_BMP], cin->bitmap_size);
+if (res < 0)
+return res;
break;
case 36:
bitmap_frame_size = cin_decode_huffman(buf, bitmap_frame_size,
cin->bitmap_table[CIN_INT_BMP],
cin->bitmap_size);
-cin_decode_rle(cin->bitmap_table[CIN_INT_BMP], bitmap_frame_size,
+res = cin_decode_rle(cin->bitmap_table[CIN_INT_BMP], bitmap_frame_size,
cin->bitmap_table[CIN_CUR_BMP], cin->bitmap_size);
+if (res < 0)
+return res;
cin_apply_delta_data(cin->bitmap_table[CIN_PRE_BMP],
cin->bitmap_table[CIN_CUR_BMP], cin->bitmap_size);
break;
--
2.17.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/5] avcodec/dfa: Check dimension against maximum
The headers from where the dimensions are read in actual files are limited to 16bit per component. Fixes: Timeout Fixes: 6305/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DFA_fuzzer-4824270749302784 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/dfa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/dfa.c b/libavcodec/dfa.c index 536040d65c..970175fb73 100644 --- a/libavcodec/dfa.c +++ b/libavcodec/dfa.c @@ -41,7 +41,7 @@ static av_cold int dfa_decode_init(AVCodecContext *avctx) avctx->pix_fmt = AV_PIX_FMT_PAL8; -if (!avctx->width || !avctx->height) +if (!avctx->width || !avctx->height || FFMAX(avctx->width, avctx->height) >= (1<<16)) return AVERROR_INVALIDDATA; av_assert0(av_image_check_size(avctx->width, avctx->height, 0, avctx) >= 0); -- 2.17.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/5] avcodec/cinepak: move some checks prior to frame allocation
Speeds up decoding from 8 to 3 seconds for
6302/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5626371985375232
Fixes: Timeout
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cinepak.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/libavcodec/cinepak.c b/libavcodec/cinepak.c
index 89e940ae0d..ba0589582f 100644
--- a/libavcodec/cinepak.c
+++ b/libavcodec/cinepak.c
@@ -315,14 +315,11 @@ static int cinepak_decode_strip (CinepakContext *s,
return AVERROR_INVALIDDATA;
}
-static int cinepak_decode (CinepakContext *s)
+static int cinepak_predecode_check (CinepakContext *s)
{
-const uint8_t *eod = (s->data + s->size);
-int i, result, strip_size, frame_flags, num_strips;
-int y0 = 0;
+int num_strips;
int encoded_buf_size;
-frame_flags = s->data[0];
num_strips = AV_RB16 (&s->data[8]);
encoded_buf_size = AV_RB24(&s->data[1]);
@@ -353,6 +350,21 @@ static int cinepak_decode (CinepakContext *s)
s->sega_film_skip_bytes = 0;
}
+if (s->size < 10 + s->sega_film_skip_bytes + num_strips * 12)
+return AVERROR_INVALIDDATA;
+
+return 0;
+}
+
+static int cinepak_decode (CinepakContext *s)
+{
+const uint8_t *eod = (s->data + s->size);
+int i, result, strip_size, frame_flags, num_strips;
+int y0 = 0;
+
+frame_flags = s->data[0];
+num_strips = AV_RB16 (&s->data[8]);
+
s->data += 10 + s->sega_film_skip_bytes;
num_strips = FFMIN(num_strips, MAX_STRIPS);
@@ -439,6 +451,11 @@ static int cinepak_decode_frame(AVCodecContext *avctx,
if (s->size < 10)
return AVERROR_INVALIDDATA;
+if ((ret = cinepak_predecode_check(s)) < 0) {
+av_log(avctx, AV_LOG_ERROR, "cinepak_predecode_check failed\n");
+return ret;
+}
+
if ((ret = ff_reget_buffer(avctx, s->frame)) < 0)
return ret;
--
2.17.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Respect AR and NM overrides for Windows builds.
Necessary for clang-cl cross compiling builds to work on Linux. Signed-off-by: Dale Curtis From caf65ca502f9a38aff3b39f4464af9f071a28167 Mon Sep 17 00:00:00 2001 From: Dale Curtis Date: Mon, 16 Apr 2018 16:26:47 -0700 Subject: [PATCH] Respect AR and NM overrides for Windows builds. Necessary for clang-cl cross compiling builds to work on Linux. Signed-off-by: Dale Curtis --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 535a59b737..28e710618a 100755 --- a/configure +++ b/configure @@ -5161,7 +5161,7 @@ case $target_os in SLIBSUF=".dll" SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)' SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME)-$(LIBMAJOR)$(SLIBSUF)' -SLIB_CREATE_DEF_CMD='EXTERN_PREFIX="$(EXTERN_PREFIX)" $(SRC_PATH)/compat/windows/makedef $(SUBDIR)lib$(NAME).ver $(OBJS) > $$(@:$(SLIBSUF)=.def)' +SLIB_CREATE_DEF_CMD='EXTERN_PREFIX="$(EXTERN_PREFIX)" AR="$(AR_CMD)" NM="$(NM_CMD)" $(SRC_PATH)/compat/windows/makedef $(SUBDIR)lib$(NAME).ver $(OBJS) > $$(@:$(SLIBSUF)=.def)' SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)' SLIB_INSTALL_LINKS= SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib)' -- 2.17.0.484.g0c8726318c-goog ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] ffplay: only use hardware accelerated SDL texture formats
On Mon, 16 Apr 2018, Michael Niedermayer wrote: Hi On Sat, Nov 04, 2017 at 06:28:58PM +, Marton Balint wrote: ffmpeg | branch: master | Marton Balint | Sat Oct 28 22:46:08 2017 +0200| [415038f2bd321a3b41564d4e0c6c17d7a096c397] | committer: Marton Balint ffplay: only use hardware accelerated SDL texture formats This breaks ffplay playing some files like: ./ffplay fate-suite//cvid/catfight-cvid-pal8-partial.mov -noframedrop The output is completely black since this commit Seems like a bug in swscale (pal8 -> bgra conversion), the alpha is 0 instead of 255. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/movenc: support writing iTunes cover image
On 16 April 2018 at 15:05, Timo Teras wrote:
> On Mon, 16 Apr 2018 10:53:43 -0300
> James Almer wrote:
>
> > On 4/14/2018 3:32 PM, 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
> > > ---
> > > v2:
> > > - Store the image in MOVTrack->cover_image instead of
> > > AVStream->attached_pic per review request
> >
> > This is failing when i try to mux a jpg as cover art into m4a (Ipod
> > muxer). It complains about missing codec tag for mjpeg. Is the covr
> > atom valid for that format?
>
> Yes, it's valid for m4a.
>
> > Adding an entry to codec_ipod_tags[] may fix it, but that alone would
> > probably then allow non cover art video tracks using that codec,
> > which i assume is undesirable.
>
> For audio formats, e.g. mp3, query codec returns MKTAG('A', 'P', 'I',
> 'C') to indicate that the image works only as attached picture.
>
> But even for video formats, it would be nice if query codec can
> properly tell which image formats it does based on disposition. The
> codec list for cover images is different from generic video streams.
>
> Any suggestions how to do that properly?
>
> Timo
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
What's the problem with doing what mp3 does?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] [RFC] ffprobe: report DAR even if SAR is undefined
On Mon, Apr 16, 2018 at 07:56:34PM +0200, Marton Balint wrote: > > On Mon, 16 Apr 2018, Timo Teras wrote: > > >On Sun, 15 Apr 2018 16:42:01 +0200 (CEST) > >Marton Balint wrote: > > > >>On Sun, 15 Apr 2018, Timo Teräs wrote: > >> > >>> Calculate DAR with assumed SAR 1:1 when SAR is undefined. Same > >>> assumption is done in ffplay to create the play window. Usually > >>> DAR is more useful metadata than SAR when e.g. choosing which > >>> media of multiple versions to use to fit the display. > >> > >>I don't think it's good idea to generally assume 1:1 > >>display_aspect_ratio for every undefined sample aspect ratio. It > >>depends heavily on your actual use case. If MOV/MP4 specifies that > >>1:1 SAR should be used, then maybe you should fix > >>av_guess_sample_aspect_ratio instead, and return 1:1 there if the > >>format context is MOV/MP4. You may add a demuxer (AVFMT) flag to > >>signal that such behaviour should be used, and > >>av_guess_sample_aspect_ratio can check for that demuxer flag. > > > >Looking at code, av_guess_sample_aspect_ratio() is used only in ffplay > >and ffprobe. > > > >ffplay implicitly assumes undefined SAR is 1:1 to create the playback > >window properly; this happens in calculate_display_rect() when > >"bad" aspect_ratio is reset to 1.0. > > > >I would expect same logic would have been useful in ffprobe. This would > >help to report back to user what ffplay is going to do with the video. > >Or at least give a hint on how to categorize the clip. SAR 1:1 is > >pretty good guess for most formats. > > I really don't see why don't you fix your application instead which parses > ffprobe output? If you see N/A aspect ratio, use 1:1. > > To be frank, I am not sure if ffprobe should use av_guess_aspect_ratio when > it displays stream metadata. It is only there now to av_reduce the aspect > ratios and to sanitize some invalid aspect ratios to 0/1. FFprobe's job is > to return stream metadata as is, not to make guesses. a very minor somewhat on topic nitpick, 0/0 would be mathamtically more correct as unknown than 0/1. If one doesnt immedeatly see why, one can look at width/height vs height/width to see one of many reasons why [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] ffplay: only use hardware accelerated SDL texture formats
Hi On Sat, Nov 04, 2017 at 06:28:58PM +, Marton Balint wrote: > ffmpeg | branch: master | Marton Balint | Sat Oct 28 > 22:46:08 2017 +0200| [415038f2bd321a3b41564d4e0c6c17d7a096c397] | committer: > Marton Balint > > ffplay: only use hardware accelerated SDL texture formats This breaks ffplay playing some files like: ./ffplay fate-suite//cvid/catfight-cvid-pal8-partial.mov -noframedrop The output is completely black since this commit [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample/arm: avoid conditional branch to PLT in THUMB-2.
Hi Michael, While it is true that some linkers support the conditional branch to PLT in Thumb mode, it is of very limited use, since it uses an R_ARM_THM_JUMP19 relocation and does not have a good range. If I switch my linker to ld.bfd for the original issue, it fails for another library with a "relocation truncated to fit" error message because the PLT entry is out of range of the conditional branch and cannot be handled by the R_ARM_THM_JUMP19 relocation. It is cleaner and more stable (for all linkers) to convert the conditional branch to an unconditional one which uses an R_ARM_THM_JUMP24 relocation and has a range of 16MB. Rahul On Mon, Apr 16, 2018 at 2:31 AM, Michael Niedermayer wrote: > On Fri, Apr 13, 2018 at 01:43:44PM -0700, Rahul Chaudhry wrote: >> When compiling for THUMB-2, the conditional branch to PLT results in a >> R_ARM_THM_JUMP19 relocation. Some linkers don't support this relocation >> in THUMB-2 (ld.gold), while others can end up truncating the relocation >> to fit (ld.bfd). > > iam not a arm expert but if its needed only for some linkers, shouldnt > it be conditional and only used for these linkers ? > (checking in configure if a linker suppors it) > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The worst form of inequality is to try to make unequal things equal. > -- Aristotle > > ___ > 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 v2] avformat/hls: clean up duplicate option fields
On Fri, Apr 13, 2018 at 5:14 PM, wrote:
> 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.
> ---
> The original patch caused the buffer pointed to by new_cookies in open_url
> to be
> leaked. The only thing that buffer is used for is to store the value until
> it
> can be passed to av_dict_set. To fix the leak, v2 of the patch simply calls
> av_dict_set with the AV_DICT_DONT_STRDUP_VAL flag, so that the dictionary
> takes
> ownership of the memory instead of copying it again.
>
> libavformat/hls.c | 74 +++---
> -
> 1 file changed, 9 insertions(+), 65 deletions(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 1257cd101c..d6158c0ada 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;
> @@ -267,10 +262,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;
> }
>
> @@ -593,14 +584,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)
> {
> @@ -684,12 +667,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,
> AV_DICT_DONT_STRDUP_VAL);
> }
>
> av_dict_free(&tmp);
> @@ -736,14 +715,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);
> @@ -1169,14 +1141,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);
>
> @@ -1193,7 +1157,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)) {
>
Re: [FFmpeg-devel] [PATCH 1/1] [RFC] ffprobe: report DAR even if SAR is undefined
On Mon, 16 Apr 2018, Timo Teras wrote:
On Sun, 15 Apr 2018 16:42:01 +0200 (CEST)
Marton Balint wrote:
On Sun, 15 Apr 2018, Timo Teräs wrote:
> Calculate DAR with assumed SAR 1:1 when SAR is undefined. Same
> assumption is done in ffplay to create the play window. Usually
> DAR is more useful metadata than SAR when e.g. choosing which
> media of multiple versions to use to fit the display.
I don't think it's good idea to generally assume 1:1
display_aspect_ratio for every undefined sample aspect ratio. It
depends heavily on your actual use case. If MOV/MP4 specifies that
1:1 SAR should be used, then maybe you should fix
av_guess_sample_aspect_ratio instead, and return 1:1 there if the
format context is MOV/MP4. You may add a demuxer (AVFMT) flag to
signal that such behaviour should be used, and
av_guess_sample_aspect_ratio can check for that demuxer flag.
Looking at code, av_guess_sample_aspect_ratio() is used only in ffplay
and ffprobe.
ffplay implicitly assumes undefined SAR is 1:1 to create the playback
window properly; this happens in calculate_display_rect() when
"bad" aspect_ratio is reset to 1.0.
I would expect same logic would have been useful in ffprobe. This would
help to report back to user what ffplay is going to do with the video.
Or at least give a hint on how to categorize the clip. SAR 1:1 is
pretty good guess for most formats.
I really don't see why don't you fix your application instead which parses
ffprobe output? If you see N/A aspect ratio, use 1:1.
To be frank, I am not sure if ffprobe should use av_guess_aspect_ratio
when it displays stream metadata. It is only there now to av_reduce the
aspect ratios and to sanitize some invalid aspect ratios to 0/1. FFprobe's
job is to return stream metadata as is, not to make guesses.
For this reason, my preferred solution was to patch ffprobe so we can
give a guess for all files. If the above patch is not a good idea, how
about adding new "effective_{sample,display}_aspect_ratio" fields? Or
just a flag "aspect_ratio_guessed" to tell if it's not defined in the
file?
Effective is not a good name here. Use best_effort_* or
guessed_* if you have to, but I don't see the much benefit in adding extra
fields to ffprobe output for such simple and trivial heuristics. Like I
said, it's not ffprobe's job. The next guy will want to add a
guessed_color_primaries based on resolution, and I can think of more
complicated guesses :)
I would prefer not to do any file type specific special handling if
possible. However, if that's the only acceptable solution, I'm happy to
implement that too. But then I'd prefer to have a 'no default SAR of
1:1' flags so file formats can inhibit the assumption instead of
explicitly needing to enable it. Is there any formats where this would
be useful? Or how about just making av_guess_sample_aspect_ratio()
return 1:1 in case nothing better exists? It's called "guess" after all
and is used in ffplay/ffprobe only...
Opt in for MOV/MP4 is required because *the specs says* that renderers
should behave this way. So the aspect ratio guess is based on
something, and not a wild guess. I think most of the other format specs
does not say such things.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] [RFC] ffprobe: report DAR even if SAR is undefined
On Mon, Apr 16, 2018 at 09:06:55AM +0300, Timo Teras wrote:
> On Sun, 15 Apr 2018 16:42:01 +0200 (CEST)
> Marton Balint wrote:
>
> > On Sun, 15 Apr 2018, Timo Teräs wrote:
> >
> > > Calculate DAR with assumed SAR 1:1 when SAR is undefined. Same
> > > assumption is done in ffplay to create the play window. Usually
> > > DAR is more useful metadata than SAR when e.g. choosing which
> > > media of multiple versions to use to fit the display.
> >
> > I don't think it's good idea to generally assume 1:1
> > display_aspect_ratio for every undefined sample aspect ratio. It
> > depends heavily on your actual use case. If MOV/MP4 specifies that
> > 1:1 SAR should be used, then maybe you should fix
> > av_guess_sample_aspect_ratio instead, and return 1:1 there if the
> > format context is MOV/MP4. You may add a demuxer (AVFMT) flag to
> > signal that such behaviour should be used, and
> > av_guess_sample_aspect_ratio can check for that demuxer flag.
>
> Looking at code, av_guess_sample_aspect_ratio() is used only in ffplay
> and ffprobe.
>
> ffplay implicitly assumes undefined SAR is 1:1 to create the playback
> window properly; this happens in calculate_display_rect() when
> "bad" aspect_ratio is reset to 1.0.
>
> I would expect same logic would have been useful in ffprobe. This would
> help to report back to user what ffplay is going to do with the video.
> Or at least give a hint on how to categorize the clip. SAR 1:1 is
> pretty good guess for most formats.
>
> For this reason, my preferred solution was to patch ffprobe so we can
> give a guess for all files. If the above patch is not a good idea, how
> about adding new "effective_{sample,display}_aspect_ratio" fields? Or
> just a flag "aspect_ratio_guessed" to tell if it's not defined in the
> file?
>
> I would prefer not to do any file type specific special handling if
> possible. However, if that's the only acceptable solution, I'm happy to
> implement that too. But then I'd prefer to have a 'no default SAR of
> 1:1' flags so file formats can inhibit the assumption instead of
> explicitly needing to enable it. Is there any formats where this would
> be useful? Or how about just making av_guess_sample_aspect_ratio()
> return 1:1 in case nothing better exists? It's called "guess" after all
> and is used in ffplay/ffprobe only...
unknown is not the same as 1:1
the user (of av_guess_sample_aspect_ratio) may want to know if theres
a 1:1 actually stored in some place or just nothing.
applications like ffplay cannot use "unknown" so they have to pick 1:1
but why is "unknown" a problem for ffprobe if thats how it is ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/flacenc: support writing attached pictures
On 4/15/2018 1:45 AM, James Almer wrote: > From: Rodger Combs > > Signed-off-by: James Almer > --- > Changed to not try to mux any kind of video as cover art and instead > only bother with streams marked as attached pictures. > Also using each stream's priv_data to hold the picture instead of > an array in the format's priv_data now. > > Will push tomorrow or Monday, as this has been rotting on the ml for > a while and has also been requested to be in the 4.0 release. Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] mystery revissions
On Mon, Apr 16, 2018 at 01:51:01PM +0200, Moritz Barsnick wrote: > On Mon, Apr 16, 2018 at 12:07:09 +0200, Michael Niedermayer wrote: > > in our APIChanges there are: > > doc/APIchanges:2014-08-13 - afbd4b8 - lavf 56.01.0 - avformat.h > > doc/APIchanges:2014-08-07 - bb78903 - lsws 2.1.3 - swscale.h > > Apparently typos by Anton in 6ca11f7157d0ffd11ea9a4211b04981b46dc75d6. > > A quick glance shows that those should be > afbd4b7 = afbd4b7e093adf6d7a830b32759ca3ba8500363d > and > bb78901 = bb789016d423d2cfacd2904ac66257bdf7f0964e thanks, will fix APIChanges [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 3.5 / 4.0
On Mon, Apr 16, 2018 at 03:14:55PM +0100, Rostislav Pehlivanov wrote: > On 16 April 2018 at 12:40, Timo Teras wrote: > > > On Mon, 16 Apr 2018 13:24:48 +0200 > > Michael Niedermayer wrote: > > > > > release/4.0 branched > > > next is the release in a few days. > > > If theres something i should wait for please say so and CC me > > > also please backport all bugfixes to 4.0 > > > > I was hoping to get my patches in for the release: > > > > - ffprobe: report unavailable SAR correctly in stream info > > * lgtm from Rotislav > > https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228141.html > > > > - avformat/movenc: support writing iTunes cover image > > * Rostislav has reviewed, and wanted it for 4.0 too > > * latest patched updated per his review comments at: > > https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228264.html > > > > - ffprobe: report DAR even if SAR is undefined > > * happy to do alternate fix if the patch solution not acceptable > > https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228284.html > > > > If it's too late that's understandable, but hopefully these could get > > backported to 4.0 branch too. > > > > Thanks for considering, > > Timo > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > I too would like for these patches to make it into the release. well, then please review/apply/backport them thanks [...] -- 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/dxv: add support for "high" quality mode
On Mon, 16 Apr 2018 09:20:09 +0200 Hendrik Leppkes wrote: > On Mon, Apr 16, 2018 at 12:23 AM, Carl Eugen Hoyos wrote: > > 2018-04-15 9:41 GMT+02:00, Paul B Mahol : > >> On 4/14/18, Rostislav Pehlivanov wrote: > >>> On 14 April 2018 at 20:46, Paul B Mahol wrote: > >>> > Signed-off-by: Paul B Mahol > --- > libavcodec/dxv.c | 815 ++ > ++--- > 1 file changed, 780 insertions(+), 35 deletions(-) > > >>> > >>> LGTM > >> > >> Applied. Thanks. > > > > Thank you for working on formats like this one, I consider this > > highly important! > > > > Sorry for not testing your patch earlier... > > > > The committed change is not helpful afaict, if you cannot fix > > the colourspace issue (which I perfectly understand), please > > commit your original hack (with a note), this variant cannot > > help users. > > > > This is not the first decoder to output YCoCg, I have H.264 files with > that as well. Just because swscale cannot convert that doesn't mean we > should be doing anything but non-native output from a decoder. My > playback chain can support that just fine. > Feel free to contribute YCoCg conversion to swscale to resolve this > for "the users". +1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 3.5 / 4.0
On 16 April 2018 at 12:40, Timo Teras wrote: > On Mon, 16 Apr 2018 13:24:48 +0200 > Michael Niedermayer wrote: > > > release/4.0 branched > > next is the release in a few days. > > If theres something i should wait for please say so and CC me > > also please backport all bugfixes to 4.0 > > I was hoping to get my patches in for the release: > > - ffprobe: report unavailable SAR correctly in stream info > * lgtm from Rotislav > https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228141.html > > - avformat/movenc: support writing iTunes cover image > * Rostislav has reviewed, and wanted it for 4.0 too > * latest patched updated per his review comments at: > https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228264.html > > - ffprobe: report DAR even if SAR is undefined > * happy to do alternate fix if the patch solution not acceptable > https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228284.html > > If it's too late that's understandable, but hopefully these could get > backported to 4.0 branch too. > > Thanks for considering, > Timo > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > I too would like for these patches to make it into the release. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/movenc: support writing iTunes cover image
On Mon, 16 Apr 2018 10:53:43 -0300
James Almer wrote:
> On 4/14/2018 3:32 PM, 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
> > ---
> > v2:
> > - Store the image in MOVTrack->cover_image instead of
> > AVStream->attached_pic per review request
>
> This is failing when i try to mux a jpg as cover art into m4a (Ipod
> muxer). It complains about missing codec tag for mjpeg. Is the covr
> atom valid for that format?
Yes, it's valid for m4a.
> Adding an entry to codec_ipod_tags[] may fix it, but that alone would
> probably then allow non cover art video tracks using that codec,
> which i assume is undesirable.
For audio formats, e.g. mp3, query codec returns MKTAG('A', 'P', 'I',
'C') to indicate that the image works only as attached picture.
But even for video formats, it would be nice if query codec can
properly tell which image formats it does based on disposition. The
codec list for cover images is different from generic video streams.
Any suggestions how to do that properly?
Timo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: extend the check for bcrypt
On 4/15/2018 8:34 PM, James Almer wrote: > Some old mingw-w64 builds seem to provide an incomplete implementation > of the API. Add an extra check to make sure it's disabled for those. > > Signed-off-by: James Almer > --- > configure | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/configure b/configure > index d22b93a2d3..83a7648c57 100755 > --- a/configure > +++ b/configure > @@ -5830,7 +5830,8 @@ check_header asm/types.h > check_builtin stdatomic stdatomic.h "atomic_int foo, bar = > ATOMIC_VAR_INIT(-1); atomic_store(&foo, 0); foo += bar" > > check_lib advapi32 "windows.h"RegCloseKey -ladvapi32 > -check_lib bcrypt "windows.h bcrypt.h" BCryptGenRandom -lbcrypt > +check_lib bcrypt "windows.h bcrypt.h" BCryptGenRandom -lbcrypt && > +check_cpp_condition bcrypt bcrypt.h "defined BCRYPT_RNG_ALGORITHM" > check_lib ole32"windows.h"CoTaskMemFree-lole32 > check_lib shell32 "windows.h shellapi.h" CommandLineToArgvW -lshell32 > check_lib psapi"windows.h psapi.h"GetProcessMemoryInfo -lpsapi Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mediacodecdec_common: make stride and slice-height non-mandatory fields
On Wed, Apr 11, 2018 at 3:14 PM, Matthieu Bouron
wrote:
> Fixes decoding on the Samsung Chromebook Pro which do not set the codec
> output format stride and slice-height fields.
> ---
> libavcodec/mediacodecdec_common.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/mediacodecdec_common.c b/libavcodec/mediacodecdec_
> common.c
> index e31adb487c..e59cf19aad 100644
> --- a/libavcodec/mediacodecdec_common.c
> +++ b/libavcodec/mediacodecdec_common.c
> @@ -385,10 +385,10 @@ static int mediacodec_dec_parse_format(AVCodecContext
> *avctx, MediaCodecDecConte
> AMEDIAFORMAT_GET_INT32(s->width, "width", 1);
> AMEDIAFORMAT_GET_INT32(s->height, "height", 1);
>
> -AMEDIAFORMAT_GET_INT32(s->stride, "stride", 1);
> +AMEDIAFORMAT_GET_INT32(s->stride, "stride", 0);
> s->stride = s->stride > 0 ? s->stride : s->width;
>
> -AMEDIAFORMAT_GET_INT32(s->slice_height, "slice-height", 1);
> +AMEDIAFORMAT_GET_INT32(s->slice_height, "slice-height", 0);
> s->slice_height = s->slice_height > 0 ? s->slice_height : s->height;
>
> if (strstr(s->codec_name, "OMX.Nvidia.")) {
> --
> 2.17.0
>
>
Ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/movenc: support writing iTunes cover image
On 4/14/2018 3:32 PM, 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 > --- > v2: > - Store the image in MOVTrack->cover_image instead of > AVStream->attached_pic per review request This is failing when i try to mux a jpg as cover art into m4a (Ipod muxer). It complains about missing codec tag for mjpeg. Is the covr atom valid for that format? Adding an entry to codec_ipod_tags[] may fix it, but that alone would probably then allow non cover art video tracks using that codec, which i assume is undesirable. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/movenc: forbid muxing AV1 streams until the spec is finished
On 4/16/2018 4:57 AM, Tomas Härdin wrote:
> sön 2018-04-15 klockan 21:40 -0300 skrev James Almer:
>> This prevents creating potentially broken files, as both the AV1 and
>> the AV1 in ISOMBFF specs are unfinished.
>>
>>> Signed-off-by: James Almer
>> ---
>> This is mainly so it's effective in ffmpeg 4.0, the first version to
>> support libaom (including pre-bitstream freeze builds). Best to
>> prevent muxing files that may not work anymore a few months from now.
>>
>> libavformat/movenc.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>> index d03d7906a1..dc5c842cb8 100644
>> --- a/libavformat/movenc.c
>> +++ b/libavformat/movenc.c
>> @@ -6081,6 +6081,10 @@ static int mov_init(AVFormatContext *s)
>> av_log(s, AV_LOG_ERROR, "VP9 only supported in MP4.\n");
>> return AVERROR(EINVAL);
>> }
>> +} else if (track->par->codec_id == AV_CODEC_ID_AV1) {
>> +/* spec is not finished, so forbid for now */
>> +av_log(s, AV_LOG_ERROR, "AV1 muxing is currently not
>> supported.\n");
>> +return AVERROR_PATCHWELCOME;
>
> Looks OK, we shouldn't produce broken files of course
>
> /Tomas
Pushed, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] mystery revissions
On Mon, Apr 16, 2018 at 12:07:09 +0200, Michael Niedermayer wrote: > in our APIChanges there are: > doc/APIchanges:2014-08-13 - afbd4b8 - lavf 56.01.0 - avformat.h > doc/APIchanges:2014-08-07 - bb78903 - lsws 2.1.3 - swscale.h Apparently typos by Anton in 6ca11f7157d0ffd11ea9a4211b04981b46dc75d6. A quick glance shows that those should be afbd4b7 = afbd4b7e093adf6d7a830b32759ca3ba8500363d and bb78901 = bb789016d423d2cfacd2904ac66257bdf7f0964e Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 3.5 / 4.0
On Mon, 16 Apr 2018 13:24:48 +0200 Michael Niedermayer wrote: > release/4.0 branched > next is the release in a few days. > If theres something i should wait for please say so and CC me > also please backport all bugfixes to 4.0 I was hoping to get my patches in for the release: - ffprobe: report unavailable SAR correctly in stream info * lgtm from Rotislav https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228141.html - avformat/movenc: support writing iTunes cover image * Rostislav has reviewed, and wanted it for 4.0 too * latest patched updated per his review comments at: https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228264.html - ffprobe: report DAR even if SAR is undefined * happy to do alternate fix if the patch solution not acceptable https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228284.html If it's too late that's understandable, but hopefully these could get backported to 4.0 branch too. Thanks for considering, Timo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 3.5 / 4.0
On Sat, Apr 14, 2018 at 02:04:43PM +0200, Michael Niedermayer wrote: > On Fri, Apr 13, 2018 at 12:53:08AM +0200, Michael Niedermayer wrote: > > On Mon, Feb 19, 2018 at 02:50:08AM +0100, Michael Niedermayer wrote: > > > Hi > > > > > > Its 4 months since 3.4 was branched so its time for a new major release > > > > > > Is 4.0 or 3.5 preferred ? > > > Any name suggestions ? > > > > > > If there are no objections i will likely make that release in the next > > > weeks > > > > more time has passed than intended ... > > > > what issues do remain that need to be fixed before the release ? > > I see fate.ffmpeg.org is not looking that well (compared to most > > releases in the past) i remember this being pretty much green longer ago > > do people want these to be fixed before the release ? > > ok, so, my plan is to create a release/4.0 branch from master in the next > 24-48 hours unless theres some issue brought to my attention (CC me just to > be sure if theres an issue) > > then wait 2 days or so and backport any newly found bugfixes to release/4.0 > and then make the release finally > > delays at any point are possible due to issues, lack of time or other. > > as name i think kierans suggestion of Wu would make sense. IIRC we had > no name suggested by more than 1 developer. Please correct me if i > miscounted i did only briefly re-check the mails in the thread. release/4.0 branched next is the release in a few days. If theres something i should wait for please say so and CC me also please backport all bugfixes to 4.0 If someone wants to write more fancy release notes or other things please do so before the release is made Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] mystery revissions
Hi in our APIChanges there are: doc/APIchanges:2014-08-13 - afbd4b8 - lavf 56.01.0 - avformat.h doc/APIchanges:2014-08-07 - bb78903 - lsws 2.1.3 - swscale.h but git log afbd4b8 fatal: ambiguous argument 'afbd4b8': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git [...] -- [...]' git log bb78903 fatal: ambiguous argument 'bb78903': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git [...] -- [...]' -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates 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
> > You forgot to update color in documentation. > > Patchset OK otherwise. > > Fix doc, and pushed. Thanks Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample/arm: avoid conditional branch to PLT in THUMB-2.
On Fri, Apr 13, 2018 at 01:43:44PM -0700, Rahul Chaudhry wrote: > When compiling for THUMB-2, the conditional branch to PLT results in a > R_ARM_THM_JUMP19 relocation. Some linkers don't support this relocation > in THUMB-2 (ld.gold), while others can end up truncating the relocation > to fit (ld.bfd). iam not a arm expert but if its needed only for some linkers, shouldnt it be conditional and only used for these linkers ? (checking in configure if a linker suppors it) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] make swresample optional for ffmpeg
On 4/12/18, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > configure| 2 +- > fftools/ffmpeg_opt.c | 2 ++ > 2 files changed, 3 insertions(+), 1 deletion(-) > ping ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/movenc: forbid muxing AV1 streams until the spec is finished
sön 2018-04-15 klockan 21:40 -0300 skrev James Almer:
> This prevents creating potentially broken files, as both the AV1 and
> the AV1 in ISOMBFF specs are unfinished.
>
> > Signed-off-by: James Almer
> ---
> This is mainly so it's effective in ffmpeg 4.0, the first version to
> support libaom (including pre-bitstream freeze builds). Best to
> prevent muxing files that may not work anymore a few months from now.
>
> libavformat/movenc.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index d03d7906a1..dc5c842cb8 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -6081,6 +6081,10 @@ static int mov_init(AVFormatContext *s)
> av_log(s, AV_LOG_ERROR, "VP9 only supported in MP4.\n");
> return AVERROR(EINVAL);
> }
> +} else if (track->par->codec_id == AV_CODEC_ID_AV1) {
> +/* spec is not finished, so forbid for now */
> +av_log(s, AV_LOG_ERROR, "AV1 muxing is currently not
> supported.\n");
> +return AVERROR_PATCHWELCOME;
Looks OK, we shouldn't produce broken files of course
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dxv: add support for "high" quality mode
On Mon, Apr 16, 2018 at 12:23 AM, Carl Eugen Hoyos wrote: > 2018-04-15 9:41 GMT+02:00, Paul B Mahol : >> On 4/14/18, Rostislav Pehlivanov wrote: >>> On 14 April 2018 at 20:46, Paul B Mahol wrote: >>> Signed-off-by: Paul B Mahol --- libavcodec/dxv.c | 815 ++ ++--- 1 file changed, 780 insertions(+), 35 deletions(-) >>> >>> LGTM >> >> Applied. Thanks. > > Thank you for working on formats like this one, I consider this > highly important! > > Sorry for not testing your patch earlier... > > The committed change is not helpful afaict, if you cannot fix > the colourspace issue (which I perfectly understand), please > commit your original hack (with a note), this variant cannot > help users. > This is not the first decoder to output YCoCg, I have H.264 files with that as well. Just because swscale cannot convert that doesn't mean we should be doing anything but non-native output from a decoder. My playback chain can support that just fine. Feel free to contribute YCoCg conversion to swscale to resolve this for "the users". - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avformat/mpegts: set AV_DISPOSITION_DESCRIPTIONS for OIPF cases
I agree, AV_LOG_INFO has been changed to AV_LOG_DEBUG.
Regards,
*Łukasz Krzciuk*
Developer
Vewd
ul. Grabarska 2, Pegaz 2A, 50-079 Wrocław, Polska
On Fri, Apr 13, 2018 at 5:50 PM, Michael Niedermayer wrote:
> On Fri, Apr 13, 2018 at 03:44:40PM +0200, Łukasz Krzciuk wrote:
> > Hi,
> >
> > this change is needed according to OIPF spec: 8.4.2 AVComponent,
> > audioDescription case:
> >
> >1. an audio component with an ISO_639_language_descriptor in the PMT
> >with the audio_type field set to 0x03
> >2. a supplementary_audio_descriptor with the editorial_classification
> >field set to 0x01
> >3. an ac-3_descriptor or an enhanced_ac-3_descriptor with a
> >component_type field with the service_type flags set to Visually
> Impaired
> >
> >
> > Regards,
> >
> > *Łukasz Krzciuk*
> > Developer
> >
> > Vewd
> > ul. Grabarska 2, Pegaz 2A, 50-079 Wrocław, Polska
>
> > mpegts.c | 30 ++
> > 1 file changed, 30 insertions(+)
> > 863b7bca7f23f9ea337fde33f5bb9265ef3b4270 0001-avformat-mpegts-set-AV_
> DISPOSITION_DESCRIPTIONS-for-.patch
> > From 12ef5cdd9c443b1601dc98d910feac87233b1040 Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?=C5=81ukasz=20Krzciuk?=
> > Date: Fri, 13 Apr 2018 14:57:57 +0200
> > Subject: [PATCH] avformat/mpegts: set AV_DISPOSITION_DESCRIPTIONS for
> OIPF
> > cases
> >
> > 1. an audio component with an ISO_639_language_descriptor in the PMT
> with the
> > audio_type field set to 0x03
> > 2. a supplementary_audio_descriptor with the editorial_classification
> field set
> > to 0x01
> > 3. an ac-3_descriptor or an enhanced_ac-3_descriptor with a
> component_type field
> > with the service_type flags set to Visually Impaired
> > ---
> > libavformat/mpegts.c | 30 ++
> > 1 file changed, 30 insertions(+)
> >
> > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> > index 37a6aa8..df2b3aa 100644
> > --- a/libavformat/mpegts.c
> > +++ b/libavformat/mpegts.c
> > @@ -1835,6 +1835,7 @@ int ff_parse_mpeg2_descriptor(AVFormatContext
> *fc, AVStream *st, int stream_type
> > break;
> > case 0x03:
> > st->disposition |= AV_DISPOSITION_VISUAL_IMPAIRED;
> > +st->disposition |= AV_DISPOSITION_DESCRIPTIONS;
> > break;
> > }
> > }
> > @@ -1910,6 +1911,7 @@ int ff_parse_mpeg2_descriptor(AVFormatContext
> *fc, AVStream *st, int stream_type
> > switch ((flags >> 2) & 0x1F) { /* editorial_classification
> */
> > case 0x01:
> > st->disposition |= AV_DISPOSITION_VISUAL_IMPAIRED;
> > +st->disposition |= AV_DISPOSITION_DESCRIPTIONS;
> > break;
> > case 0x02:
> > st->disposition |= AV_DISPOSITION_HEARING_IMPAIRED;
> > @@ -1934,6 +1936,34 @@ int ff_parse_mpeg2_descriptor(AVFormatContext
> *fc, AVStream *st, int stream_type
> > }
> > }
> > break;
> > +case 0x6a: /* ac-3_descriptor */
> > +{
> > +int component_type_flag = get8(pp, desc_end) & (1 << 7);
> > +if (component_type_flag) {
> > +int component_type = get8(pp, desc_end);
> > +int service_type_mask = 0x38; // 0b00111000
> > +int service_type = ((component_type &
> service_type_mask) >> 3);
> > +if (service_type == 0x02 /* 0b010 */) {
> > +st->disposition |= AV_DISPOSITION_DESCRIPTIONS;
> > +av_log(ts->stream, AV_LOG_INFO, "New track
> disposition for id %u: %u\n", st->id, st->disposition);
>
> AV_LOG_INFO is likely too noisy for normal usecases
>
> thx
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Rewriting code that is poorly written but fully understood is good.
> Rewriting code that one doesnt understand is a sign that one is less smart
> then the original author, trying to rewrite it will not make it better.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
From fc2e281eb0e0e526fee52944205d6bb3729a17f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C5=81ukasz=20Krzciuk?=
Date: Fri, 13 Apr 2018 14:57:57 +0200
Subject: [PATCH] avformat/mpegts: set AV_DISPOSITION_DESCRIPTIONS for OIPF
cases
1. an audio component with an ISO_639_language_descriptor in the PMT with the
audio_type field set to 0x03
2. a supplementary_audio_descriptor with the editorial_classification field set
to 0x01
3. an ac-3_descriptor or an enhanced_ac-3_descriptor with a component_type field
with the service_type flags set to Visually Impaired
---
libavformat/mpegts.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 37a6aa8..629631f 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -1835,
