Re: [FFmpeg-devel] [PATCH 1/2] compat/cuda/ptx2c: remove shell loop

[Ridley Combs]

> On May 23, 2020, at 06:47, Carl Eugen Hoyos  wrote:
> 
> Am Sa., 23. Mai 2020 um 06:01 Uhr schrieb rcombs :
>> 
>> This improves build times dramatically
>> ---
>> compat/cuda/ptx2c.sh | 8 +++-
>> 1 file changed, 3 insertions(+), 5 deletions(-)
>> 
>> diff --git a/compat/cuda/ptx2c.sh b/compat/cuda/ptx2c.sh
>> index 0750e7a3b7..435a9b4b6c 100755
>> --- a/compat/cuda/ptx2c.sh
>> +++ b/compat/cuda/ptx2c.sh
>> @@ -27,10 +27,8 @@ IN="$2"
>> NAME="$(basename "$IN" | sed 's/\..*//')"
>> 
>> printf "const char %s_ptx[] = \\" "$NAME" > "$OUT"
>> -while IFS= read -r LINE
>> -do
>> -printf "\n\t\"%s\\\n\"" "$(printf "%s" "$LINE" | sed -e 's/\r//g' -e 
>> 's/["\\]/\\&/g')" >> "$OUT"
>> -done < "$IN"
>> -printf ";\n" >> "$OUT"
>> +echo >> "$OUT"
> 
>> +sed -e 's/\r//g' -e 's/["\\]/\\&/g' -e 's/^[[:space:]]*/\t"/' -e 
>> 's/$/\\n"/' < "$IN" >> "$OUT"
> 
> Is there a reason why you did not merge the two patches?
> 
> Carl Eugen

Just that I wrote them several months apart from one another, and they 
conceptually serve different purposes (perf in one, compatibility in the other).

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/3] lavf/dashdec: avoid reading the first data segment in read_header

[Ridley Combs]

> On May 25, 2020, at 08:43, Gorilla Maguila  wrote:
> 
> These lines:
> 
> +if (pls->init_sec_data_len > 0)
> +pls->ctx->probesize = FFMIN(pls->ctx->probesize,
> pls->init_sec_data_len);
> pls->ctx->max_analyze_duration = s->max_analyze_duration > 0 ?
> s->max_analyze_duration : 4 * AV_TIME_BASE;
> -ret = av_probe_input_buffer(&pls->pb, &in_fmt, "", NULL, 0, 0);
> +ret = av_probe_input_buffer(&pls->pb, &in_fmt, "", NULL, 0,
> pls->ctx->probesize);
> 
> 
> cause an Error in av_probe_input_buffer when pls->init_sec_data_len
> or pls->ctx->probesize are < 2048 due to the following line in
> av_probe_input_buffer:
> 
> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/format.c#L236

Apply the patch series in the order it was sent: 
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/263099.html 

> 
> El vie., 22 may. 2020 a las 9:22, Steven Liu ()
> escribió:
> 
>> 
>> 
>>> 2020年5月22日 下午1:42，rcombs  写道：
>>> 
>>> This reduces the number of requests that have to be made during startup.
>>> ---
>>> libavformat/dashdec.c | 41 ++---
>>> 1 file changed, 26 insertions(+), 15 deletions(-)
>>> 
>>> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
>>> index ec2aadcee3..1bd070c7cb 100644
>>> --- a/libavformat/dashdec.c
>>> +++ b/libavformat/dashdec.c
>>> @@ -1798,6 +1798,19 @@ static int read_data(void *opaque, uint8_t *buf,
>> int buf_size)
>>>DASHContext *c = v->parent->priv_data;
>>> 
>>> restart:
>>> +/* load/update Media Initialization Section, if any */
>>> +if ((ret = update_init_section(v)) < 0)
>>> +goto end;
>>> +
>>> +if (v->init_sec_buf_read_offset < v->init_sec_data_len) {
>>> +/* Push init section out first before first actual fragment */
>>> +int copy_size = FFMIN(v->init_sec_data_len -
>> v->init_sec_buf_read_offset, buf_size);
>>> +memcpy(buf, v->init_sec_buf, copy_size);
>>> +v->init_sec_buf_read_offset += copy_size;
>>> +ret = copy_size;
>>> +goto end;
>>> +}
>>> +
>>>if (!v->input) {
>>>free_fragment(&v->cur_seg);
>>>v->cur_seg = get_current_fragment(v);
>>> @@ -1806,11 +1819,6 @@ restart:
>>>goto end;
>>>}
>>> 
>>> -/* load/update Media Initialization Section, if any */
>>> -ret = update_init_section(v);
>>> -if (ret)
>>> -goto end;
>>> -
>>>ret = open_input(c, v, v->cur_seg);
>>>if (ret < 0) {
>>>if (ff_check_interrupt(c->interrupt_callback)) {
>>> @@ -1823,15 +1831,6 @@ restart:
>>>}
>>>}
>>> 
>>> -if (v->init_sec_buf_read_offset < v->init_sec_data_len) {
>>> -/* Push init section out first before first actual fragment */
>>> -int copy_size = FFMIN(v->init_sec_data_len -
>> v->init_sec_buf_read_offset, buf_size);
>>> -memcpy(buf, v->init_sec_buf, copy_size);
>>> -v->init_sec_buf_read_offset += copy_size;
>>> -ret = copy_size;
>>> -goto end;
>>> -}
>>> -
>>>/* check the v->cur_seg, if it is null, get current and double check
>> if the new v->cur_seg*/
>>>if (!v->cur_seg) {
>>>v->cur_seg = get_current_fragment(v);
>>> @@ -1940,10 +1939,19 @@ static int
>> reopen_demux_for_component(AVFormatContext *s, struct representation
>>>if ((ret = ff_copy_whiteblacklists(pls->ctx, s)) < 0)
>>>goto fail;
>>> 
>>> +
>>> +if (pls->init_sec_data_len <= 0) {
>>> +/* load/update Media Initialization Section, if any */
>>> +if ((ret = update_init_section(pls)) < 0)
>>> +goto fail;
>>> +}
>>> +
>>>pls->ctx->flags = AVFMT_FLAG_CUSTOM_IO;
>>>pls->ctx->probesize = s->probesize > 0 ? s->probesize : 1024 * 4;
>>> +if (pls->init_sec_data_len > 0)
>>> +pls->ctx->probesize = FFMIN(pls->ctx->probesize,
>> pls->init_sec_data_len);
>>>pls->ctx->max_analyze_duration = s->max_analyze_duration > 0 ?
>> s->max_analyze_duration : 4 * AV_TIME_BASE;
>>> -ret = av_probe_input_buffer(&pls->pb, &in_fmt, "", NULL, 0, 0);
>>> +ret = av_probe_input_buffer(&pls->pb, &in_fmt, "", NULL, 0,
>> pls->ctx->probesize);
>>>if (ret < 0) {
>>>av_log(s, AV_LOG_ERROR, "Error when loading first fragment,
>> playlist %d\n", (int)pls->rep_idx);
>>>avformat_free_context(pls->ctx);
>>> @@ -1954,6 +1962,9 @@ static int
>> reopen_demux_for_component(AVFormatContext *s, struct representation
>>>pls->ctx->pb = &pls->pb;
>>>pls->ctx->io_open  = nested_io_open;
>>> 
>>> +if (pls->init_sec_data_len > 0)
>>> +av_dict_set_int(&in_fmt_opts, "header_size",
>> pls->init_sec_data_len, 0);
>>> +
>>>// provide additional information from mpd if available
>>>ret = avformat_open_input(&pls->ctx, "", in_fmt, &in_fmt_opts);
>> //pls->init_section->url
>>>av_dict_free(&in_fmt_opts);
>>> --
>>> 2.26.2
>>> 
>>> ___

Re: [FFmpeg-devel] [PATCH 1/4] lavf: matroska subtitle muxer

[Ridley Combs]

> On May 28, 2020, at 03:26, Nicolas George  wrote:
> 
> rcombs (12020-05-28):
>> ---
>> configure |  1 +
>> libavformat/allformats.c  |  1 +
>> libavformat/matroskaenc.c | 30 ++
>> libavformat/version.h |  2 +-
>> 4 files changed, 33 insertions(+), 1 deletion(-)
> 
> Was this not rejected two months ago as doing nothing useful?

Dunno; I added it because an output file named .mks wasn't autoselecting the 
matroska muxer, and it seemed like if we're going to have an mka muxer (rather 
than just an additional extension on the main one) we might as well have an mks 
muxer as well. If we don't think it's useful, it might make sense to get rid of 
the mka muxer as well and just add all the extensions (including mk3d) to the 
mkv one; I don't feel strongly either way.

> 
> Regards,
> 
> -- 
>  Nicolas George
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/4] lavf/tls: verify TLS connections by default whenever possible

[Ridley Combs]

> On Jun 3, 2020, at 02:32, Moritz Barsnick  wrote:
> 
> On Fri, May 29, 2020 at 22:57:53 -0500, rcombs wrote:
>> {"cafile", "Certificate Authority database file", offsetof(pstruct, 
>> options_field . ca_file),   AV_OPT_TYPE_STRING, .flags = TLS_OPTFL }, \
>> -{"tls_verify", "Verify the peer certificate", offsetof(pstruct, 
>> options_field . verify),AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, .flags = 
>> TLS_OPTFL }, \
>> +{"tls_verify", "Verify the peer certificate", offsetof(pstruct, 
>> options_field . verify),AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1, .flags = 
>> TLS_OPTFL }, \
>> {"cert_file",  "Certificate file",offsetof(pstruct, 
>> options_field . cert_file), AV_OPT_TYPE_STRING, .flags = TLS_OPTFL }, \
> 
> Strictly speaking, this is a change in behavior, so I would at least
> appreciate a version bump.
> 
> The reasoning is that some hosts which used to work will stop doing so,
> namely those with self-signed (untrusted) certificates, expired
> certificates, and for clients with an outdated CA certificates store.
> Yes, this new behavior is desired, but it suddenly "breaks stuff".

Reasonable; what level should it be? I'd guess a minor bump? Though 
traditionally AVOption changes are micro.

> 
> Cheers,
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/4] lavf/tls_openssl: add support for verifying the server hostname on >=1.1.0

[Ridley Combs]

> On Jun 3, 2020, at 02:29, Moritz Barsnick  wrote:
> 
> On Fri, May 29, 2020 at 22:57:50 -0500, rcombs wrote:
>> +#else
>> +av_log(h, AV_LOG_WARNING, "ffmpeg was built against an old 
>> version of OpenSSL\n"
>> +  "which doesn't provide peer name 
>> verification, so this connection\n"
>> +  "will be made insecurely. To make 
>> this connection securely,\n"
>> +  "upgrade to a newer OpenSSL version, 
>> or use GNUTLS instead.\n");
> 
> Aren't there also other options than just GnuTLS? From a quick check,
> it looks like most of ffmpeg's TLS implementations support
> verification, but I don't know the internals. (Perhaps the same
> misconception as with openssl.)

Ahh, this patch dates back to when the only other multiplatform option was 
GNUTLS. I can say "or use a different TLS implementation." if you like?

> 
> Furthermore, is that the official spelling/capitalization of GnuTLS?
> 
> Cheers,
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/5] lavf/dashdec: improve memory handling

[Ridley Combs]

> On Jun 11, 2020, at 10:19, Andreas Rheinhardt  
> wrote:
> 
> rcombs:
>> - Fixes a couple leaks
>> - Adds an av_freep equivalent for libxml buffers
>> - Avoids some redundant copying
>> ---
>> libavformat/dashdec.c | 44 +++
>> 1 file changed, 24 insertions(+), 20 deletions(-)
>> 
>> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
>> index c94ce2caca..378c892b87 100644
>> --- a/libavformat/dashdec.c
>> +++ b/libavformat/dashdec.c
>> @@ -147,9 +147,6 @@ typedef struct DASHContext {
>> uint64_t period_duration;
>> uint64_t period_start;
>> 
>> -/* AdaptationSet Attribute */
>> -char *adaptationset_lang;
>> -
>> int is_live;
>> AVIOInterruptCB *interrupt_callback;
>> char *allowed_extensions;
>> @@ -162,6 +159,15 @@ typedef struct DASHContext {
>> 
>> } DASHContext;
>> 
>> +static void xml_freep(void* arg)
>> +{
>> +void *val;
>> +
>> +memcpy(&val, arg, sizeof(val));
>> +memcpy(arg, &(void *){ NULL }, sizeof(val));
>> +xmlFree(val);
>> +}
>> +
> 
> libxml2 allows to use custom memory allocation functions. Have you tried
> to just use our allocation functions which would allow to use av_freep
> directly?

This would work in theory, but it's not library-safe: if any other library (or 
the main application) also overrode the libxml2 allocation functions, then this 
could fail (and if some other code relied on that functionality, we could break 
that). I'd rather not rely on global state in a dependency lib like that if not 
absolutely necessary.

> 
>> static int ishttp(char *url)
>> {
>> const char *proto_name = avio_find_protocol_name(url);
>> @@ -362,6 +368,8 @@ static void free_representation(struct representation 
>> *pls)
>> avformat_close_input(&pls->ctx);
>> }
>> 
>> +xml_freep(&pls->lang);
>> +
>> av_freep(&pls->url_template);
>> av_freep(&pls);
>> }
>> @@ -878,15 +886,9 @@ static int 
>> parse_manifest_representation(AVFormatContext *s, const char *url,
>> ret = AVERROR(ENOMEM);
>> goto end;
>> }
>> -if (c->adaptationset_lang) {
>> -rep->lang = av_strdup(c->adaptationset_lang);
>> -if (!rep->lang) {
>> -av_log(s, AV_LOG_ERROR, "alloc language memory failure\n");
>> -av_freep(&rep);
>> -ret = AVERROR(ENOMEM);
>> -goto end;
>> -}
>> -}
>> +
>> +rep->lang = xmlGetProp(adaptationset_node, "lang");
>> +
>> rep->parent = s;
>> representation_segmenttemplate_node = 
>> find_child_node_by_name(representation_node, "SegmentTemplate");
>> representation_baseurl_node = 
>> find_child_node_by_name(representation_node, "BaseURL");
>> @@ -965,7 +967,8 @@ static int parse_manifest_representation(AVFormatContext 
>> *s, const char *url,
>> xmlFree(startnumber_val);
>> }
>> if (adaptationset_supplementalproperty_node) {
>> -if 
>> (!av_strcasecmp(xmlGetProp(adaptationset_supplementalproperty_node,"schemeIdUri"),
>>  "http://dashif.org/guidelines/last-segment-number";)) {
>> +char *schemeIdUri = 
>> xmlGetProp(adaptationset_supplementalproperty_node, "schemeIdUri");
>> +if (!av_strcasecmp(schemeIdUri, 
>> "http://dashif.org/guidelines/last-segment-number";)) {
>> val = 
>> xmlGetProp(adaptationset_supplementalproperty_node,"value");
>> if (!val) {
>> av_log(s, AV_LOG_ERROR, "Missing value attribute in 
>> adaptationset_supplementalproperty_node\n");
>> @@ -974,6 +977,7 @@ static int parse_manifest_representation(AVFormatContext 
>> *s, const char *url,
>> xmlFree(val);
>> }
>> }
>> +xmlFree(schemeIdUri);
>> }
>> 
>> fragment_timeline_node = 
>> find_child_node_by_name(representation_segmenttemplate_node, 
>> "SegmentTimeline");
>> @@ -1120,13 +1124,10 @@ end:
>> 
>> static int parse_manifest_adaptationset_attr(AVFormatContext *s, xmlNodePtr 
>> adaptationset_node)
>> {
>> -DASHContext *c = s->priv_data;
>> -
>> if (!adaptationset_node) {
>> av_log(s, AV_LOG_WARNING, "Cannot get AdaptationSet\n");
>> return AVERROR(EINVAL);
>> }
>> -c->adaptationset_lang = xmlGetProp(adaptationset_node, "lang");
>> 
>> return 0;
>> }
>> @@ -1139,7 +1140,6 @@ static int 
>> parse_manifest_adaptationset(AVFormatContext *s, const char *url,
>> xmlNodePtr period_segmentlist_node)
>> {
>> int ret = 0;
>> -DASHContext *c = s->priv_data;
>> xmlNodePtr fragment_template_node = NULL;
>> xmlNodePtr content_component_node = NULL;
>> xmlNodePtr adaptationset_baseurl_node = NULL;
>> @@ -1182,7 +1182,6 @@ static int 
>> parse_manifest_adaptationset(AVFormatContext *s, const char *url,
>> }
>> 
>> err:
>> -

Re: [FFmpeg-devel] [PATCH 3/5] lavc/h264dec: loosen new-extradata check

[Ridley Combs]

> On Jun 11, 2020, at 07:53, James Almer  wrote:
> 
> On 6/11/2020 1:43 AM, rcombs wrote:
>> ---
>> libavcodec/h264dec.c | 13 ++---
>> 1 file changed, 6 insertions(+), 7 deletions(-)
>> 
>> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
>> index 6270ea80df..0d7492cfad 100644
>> --- a/libavcodec/h264dec.c
>> +++ b/libavcodec/h264dec.c
>> @@ -988,6 +988,8 @@ static int h264_decode_frame(AVCodecContext *avctx, void 
>> *data,
>> AVFrame *pict  = data;
>> int buf_index;
>> int ret;
>> +const uint8_t *new_extra;
>> +int new_extra_size;
>> 
>> h->flags = avctx->flags;
>> h->setup_finished = 0;
>> @@ -999,13 +1001,10 @@ static int h264_decode_frame(AVCodecContext *avctx, 
>> void *data,
>> if (buf_size == 0)
>> return send_next_delayed_frame(h, pict, got_frame, 0);
>> 
>> -if (h->is_avc && av_packet_get_side_data(avpkt, 
>> AV_PKT_DATA_NEW_EXTRADATA, NULL)) {
>> -int side_size;
>> -uint8_t *side = av_packet_get_side_data(avpkt, 
>> AV_PKT_DATA_NEW_EXTRADATA, &side_size);
>> -if (is_extra(side, side_size))
>> -ff_h264_decode_extradata(side, side_size,
>> - &h->ps, &h->is_avc, 
>> &h->nal_length_size,
>> - avctx->err_recognition, avctx);
>> +if ((new_extra = av_packet_get_side_data(avpkt, 
>> AV_PKT_DATA_NEW_EXTRADATA, &new_extra_size))) {
>> +ff_h264_decode_extradata(new_extra, new_extra_size,
>> + &h->ps, &h->is_avc, &h->nal_length_size,
>> + avctx->err_recognition, avctx);
>> }
>> if (h->is_avc && buf_size >= 9 && buf[0]==1 && buf[2]==0 && 
>> (buf[4]&0xFC)==0xFC) {
>> if (is_extra(buf, buf_size))
> 
> This looks similar to
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200508020929.68603-1-ollywood...@gmail.com/

Heh, yeah it's ultimately functionally the same, but has an entirely different 
purpose. The streams I'm working with _are_ avcC-formatted, but don't have 
extradata yet at init-time, so the is_avc flag isn't set when this code runs. 
The is_extra check was failing because some files have stub avcC extradata that 
doesn't contain any SPS/PPS arrays (they're sent inline instead).
Sounds like this change is a win/win, then?

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] mailmap: add entry for myself

[Ridley Combs]

> On Jun 17, 2020, at 12:16, Josh de Kock  wrote:
> 
> On 17/06/2020 15:16, Zhong Li wrote:
>> Signed-off-by: Zhong Li 
>> ---
>>  .mailmap | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>> diff --git a/.mailmap b/.mailmap
>> index d1925bfab0..f14770d800 100644
>> --- a/.mailmap
>> +++ b/.mailmap
>> @@ -15,7 +15,8 @@
>>   
>>   
>>   
>> - 
>> + 
>> + 
>   
> 
> Is better if you would like the last two emails to be displayed as 
> lizhong1...@gmail.com.

No, you can't have 2 old addresses on a single line. You need a separate line 
for each one.

>>   
>>  rcombs  
>>   
> -- 
> Josh
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/5] lavf/matroskaenc: mux WebVTT using standard (non-WebM) formatting

[Ridley Combs]

> On Jun 20, 2020, at 04:12, Andreas Rheinhardt  
> wrote:
> 
> rcombs:
>> ---
>> libavformat/matroskaenc.c | 30 --
>> 1 file changed, 24 insertions(+), 6 deletions(-)
>> 
>> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
>> index 63d6b50e6a..94e6cc542a 100644
>> --- a/libavformat/matroskaenc.c
>> +++ b/libavformat/matroskaenc.c
>> @@ -2117,22 +2117,25 @@ static int mkv_write_vtt_blocks(AVFormatContext *s, 
>> AVIOContext *pb, const AVPac
>> MatroskaMuxContext *mkv = s->priv_data;
>> mkv_track *track = &mkv->tracks[pkt->stream_index];
>> ebml_master blockgroup;
>> -int id_size, settings_size, size;
>> -const char *id, *settings;
>> +int id_size = 0, settings_size = 0, comment_size = 0, size = pkt->size;
>> +const char *id, *settings, *comment;
>> int64_t ts = track->write_dts ? pkt->dts : pkt->pts;
>> const int flags = 0;
>> 
>> -id_size = 0;
>> id = av_packet_get_side_data(pkt, AV_PKT_DATA_WEBVTT_IDENTIFIER,
>>  &id_size);
>> id = id ? id : "";
>> 
>> -settings_size = 0;
>> settings = av_packet_get_side_data(pkt, AV_PKT_DATA_WEBVTT_SETTINGS,
>>&settings_size);
>> settings = settings ? settings : "";
>> 
>> -size = id_size + 1 + settings_size + 1 + pkt->size;
>> +comment = av_packet_get_side_data(pkt, AV_PKT_DATA_WEBVTT_COMMENT,
>> +  &comment_size);
>> +comment = comment ? comment : "";
>> +
>> +if (mkv->mode == MODE_WEBM)
>> +size += id_size + 1 + settings_size + 1;
>> 
>> /* The following string is identical to the one in mkv_write_block so 
>> that
>>  * only one copy needs to exist in binaries. */
>> @@ -2151,7 +2154,22 @@ static int mkv_write_vtt_blocks(AVFormatContext *s, 
>> AVIOContext *pb, const AVPac
>> put_ebml_num(pb, track->track_num, track->track_num_size);
>> avio_wb16(pb, ts - mkv->cluster_pts);
>> avio_w8(pb, flags);
>> -avio_printf(pb, "%.*s\n%.*s\n%.*s", id_size, id, settings_size, 
>> settings, pkt->size, pkt->data);
>> +if (mkv->mode == MODE_WEBM)
>> +avio_printf(pb, "%.*s\n%.*s\n", id_size, id, settings_size, 
>> settings);
>> +avio_write(pb, pkt->data, pkt->size);
>> +
>> +if (mkv->mode != MODE_WEBM && (id_size || settings_size || 
>> comment_size)) {
>> +ebml_master block_additions = start_ebml_master(pb, 
>> MATROSKA_ID_BLOCKADDITIONS, 0);
>> +ebml_master block_more  = start_ebml_master(pb, 
>> MATROSKA_ID_BLOCKMORE,  0);
>> +/* Until dbc50f8a our demuxer used a wrong default value
>> + * of BlockAddID, so we write it unconditionally. */
>> +put_ebml_uint  (pb, MATROSKA_ID_BLOCKADDID, 1);
>> +put_ebml_id(pb, MATROSKA_ID_BLOCKADDITIONAL);
>> +put_ebml_length(pb, id_size + 1 + settings_size + 1 + comment_size, 
>> 0);
>> +avio_printf(pb, "%.*s\n%.*s\n%.*s", id_size, id, settings_size, 
>> settings, comment_size, comment);
>> +end_ebml_master(pb, block_more);
>> +end_ebml_master(pb, block_additions);
>> +}
>> 
>> put_ebml_uint(pb, MATROSKA_ID_BLOCKDURATION, pkt->duration);
>> end_ebml_master(pb, blockgroup);
> 
> Did you test this? Did it work? It shouldn't. The initial guess for the
> size of blockgroup is based solely on pkt->size (and TrackNumber); it
> does not take the size of the side data into account and therefore may
> underestimate the amount of bytes needed for the blockgroup length
> field. And this leads to an assert.

I tested and it did work, but I see where the problem you mentioned comes from. 
Just, it'd only cause an assert failure (or observable output issue) if the 
BlockAdditions was large enough (and the size close enough to a byte boundary) 
that it would've made the length take up an additional byte, which didn't come 
up in my tests. Will fix, thanks.

> 
> - Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 02/15] lavc/codec_desc: add additional JPEG and BMP MIME types

[Ridley Combs]

> On Sep 9, 2020, at 08:23, Oneric  wrote:
> 
> On Wed, Sep 09, 2020 at 01:02:04 -0500, rcombs wrote:
>> ---
>> libavcodec/codec_desc.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
>> index 3dee640360..49a00ad264 100644
>> --- a/libavcodec/codec_desc.c
>> +++ b/libavcodec/codec_desc.c
>> @@ -82,7 +82,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
>> .name  = "mjpeg",
>> .long_name = NULL_IF_CONFIG_SMALL("Motion JPEG"),
>> .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
>> -.mime_types= MT("image/jpeg"),
>> +.mime_types= MT("image/jpeg", "image/jpg"),
> 
> "image/jpg" doesn't seeem to be an official IANA MIME type ("image/jpeg" is).
> That ofc doesn't mean it isn't being used, but after a quick search I can't 
> find a reference for "image/jpg" anywhere.
> Did you encounter a program using "image/jpg"? If not it may be better to 
> stick with "image/jpeg" only.

It was in ff_id3v2_mime_tags, and the commits adding indicate that some files
used it, so I added it here for compatibility with that.

> 
> 
>> .profiles  = NULL_IF_CONFIG_SMALL(ff_mjpeg_profiles),
>> },
>> {
>> @@ -588,7 +588,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
>> .name  = "bmp",
>> .long_name = NULL_IF_CONFIG_SMALL("BMP (Windows and OS/2 bitmap)"),
>> .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
>> -.mime_types= MT("image/x-ms-bmp"),
>> +.mime_types= MT("image/x-ms-bmp", "image/bmp"),
>> },
>> {
>> .id= AV_CODEC_ID_CSCD,
>> -- 
>> 2.27.0
>> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org 
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel 
> 
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org  with 
> subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 02/15] lavc/codec_desc: add additional JPEG and BMP MIME types

[Ridley Combs]

> On Sep 9, 2020, at 04:40, Andreas Rheinhardt  
> wrote:
> 
> rcombs:
>> ---
>> libavcodec/codec_desc.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
>> index 3dee640360..49a00ad264 100644
>> --- a/libavcodec/codec_desc.c
>> +++ b/libavcodec/codec_desc.c
>> @@ -82,7 +82,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
>> .name  = "mjpeg",
>> .long_name = NULL_IF_CONFIG_SMALL("Motion JPEG"),
>> .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
>> -.mime_types= MT("image/jpeg"),
>> +.mime_types= MT("image/jpeg", "image/jpg"),
>> .profiles  = NULL_IF_CONFIG_SMALL(ff_mjpeg_profiles),
>> },
>> {
>> @@ -588,7 +588,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
>> .name  = "bmp",
>> .long_name = NULL_IF_CONFIG_SMALL("BMP (Windows and OS/2 bitmap)"),
>> .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
>> -.mime_types= MT("image/x-ms-bmp"),
>> +.mime_types= MT("image/x-ms-bmp", "image/bmp"),
>> },
>> {
>> .id= AV_CODEC_ID_CSCD,
>> 
> The mime types should be sorted by "best match first". Is x-ms-bmp
> really better than just bmp?

For some (pseudo-)codecs it might be better to prefer an older type name
for compatibility (e.g. TTFs should be muxed in MKV as 
application/x-truetype-font rather than font/ttf for compatibility with
players that don't yet handle font/ttf as a font), but yeah in this case 
image/bmp
is better-supported and should go first; fixed.

> 
> - Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org 
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel 
> 
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org  with 
> subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/3] lavc/codec.h: add AV_CODEC_CAP_SINGLE_SUB_RECT

[Ridley Combs]

> On Feb 21, 2023, at 01:42, Nicolas George  wrote:
> 
> rcombs (12023-02-20):
>> ---
>> doc/APIchanges   | 3 +++
>> libavcodec/codec.h   | 5 +
>> libavcodec/version.h | 2 +-
>> 3 files changed, 9 insertions(+), 1 deletion(-)
> 
> And... No change to the framework to make use of this flag? Like, return
> AVERROR(EINVAL) if the flag is present but several rectangles are given?

I didn't want to break existing applications further, though I don't feel 
strongly about it either way (since the existing behavior is already very poor).

> 
> Regards,
> 
> -- 
>  Nicolas George
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/3] ffmpeg: respect AV_CODEC_CAP_SINGLE_SUB_RECT

[Ridley Combs]

> On Feb 21, 2023, at 01:45, Nicolas George  wrote:
> 
> rcombs (12023-02-20):
>> Fixes ASS output when multiple rects are present.
>> ---
>> fftools/ffmpeg.c | 28 ++--
>> 1 file changed, 18 insertions(+), 10 deletions(-)
> 
> Does this not belong to the framework?

I don't see a way it could be? avcodec_encode_subtitle takes an AVSubtitle and 
writes to a single caller-provided buffer; there's no way for it to generate 
multiple outputs for a single input.

> 
>> 
>> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
>> index 9884e0c6c6..23eac52438 100644
>> --- a/fftools/ffmpeg.c
>> +++ b/fftools/ffmpeg.c
>> @@ -1021,6 +1021,7 @@ static void do_subtitle_out(OutputFile *of,
>> AVCodecContext *enc;
>> AVPacket *pkt = ost->pkt;
>> int64_t pts;
>> +int single_rect;
>> 
>> if (sub->pts == AV_NOPTS_VALUE) {
>> av_log(ost, AV_LOG_ERROR, "Subtitle packets must have a pts\n");
>> @@ -1031,11 +1032,15 @@ static void do_subtitle_out(OutputFile *of,
>> 
>> enc = ost->enc_ctx;
>> 
>> +single_rect = !!(enc->codec->capabilities & 
>> AV_CODEC_CAP_SINGLE_SUB_RECT);
>> +
>> /* Note: DVB subtitle need one packet to draw them and one other
>>packet to clear them */
>> /* XXX: signal it in the codec context ? */
>> if (enc->codec_id == AV_CODEC_ID_DVB_SUBTITLE)
>> nb = 2;
>> +else if (single_rect)
>> +nb = FFMAX(sub->num_rects, 1);
>> else
>> nb = 1;
>> 
>> @@ -1044,7 +1049,7 @@ static void do_subtitle_out(OutputFile *of,
>> if (output_files[ost->file_index]->start_time != AV_NOPTS_VALUE)
>> pts -= output_files[ost->file_index]->start_time;
>> for (i = 0; i < nb; i++) {
>> -unsigned save_num_rects = sub->num_rects;
>> +AVSubtitle local_sub = *sub;
>> 
>> if (!check_recording_time(ost, pts, AV_TIME_BASE_Q))
>> return;
>> @@ -1053,19 +1058,22 @@ static void do_subtitle_out(OutputFile *of,
>> if (ret < 0)
>> report_and_exit(AVERROR(ENOMEM));
>> 
>> -sub->pts = pts;
>> +local_sub.pts = pts;
>> // start_display_time is required to be 0
>> -sub->pts   += av_rescale_q(sub->start_display_time, 
>> (AVRational){ 1, 1000 }, AV_TIME_BASE_Q);
>> -sub->end_display_time  -= sub->start_display_time;
>> -sub->start_display_time = 0;
>> -if (i == 1)
>> -sub->num_rects = 0;
>> +local_sub.pts   += 
>> av_rescale_q(sub->start_display_time, (AVRational){ 1, 1000 }, 
>> AV_TIME_BASE_Q);
>> +local_sub.end_display_time  -= sub->start_display_time;
>> +local_sub.start_display_time = 0;
>> +
>> +if (enc->codec_id == AV_CODEC_ID_DVB_SUBTITLE && i == 1)
>> +local_sub.num_rects = 0;
>> +else if (single_rect && sub->num_rects > 0) {
>> +local_sub.num_rects = 1;
>> +local_sub.rects += i;
>> +}
>> 
>> ost->frames_encoded++;
>> 
>> -subtitle_out_size = avcodec_encode_subtitle(enc, pkt->data, 
>> pkt->size, sub);
>> -if (i == 1)
>> -sub->num_rects = save_num_rects;
>> +subtitle_out_size = avcodec_encode_subtitle(enc, pkt->data, 
>> pkt->size, &local_sub);
>> if (subtitle_out_size < 0) {
>> av_log(ost, AV_LOG_FATAL, "Subtitle encoding failed\n");
>> exit_program(1);
> 
> Regards,
> 
> -- 
>  Nicolas George
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org 
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org  with 
> subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] lavc/assenc: set AV_CODEC_CAP_SINGLE_SUB_RECT

[Ridley Combs]

> On Feb 21, 2023, at 01:48, Nicolas George  wrote:
> 
> rcombs (12023-02-20):
>> This already gave garbled output when multiple rects were present,
>> so this is simply documenting an existing requirement.
>> ---
>> libavcodec/assenc.c | 2 ++
>> 1 file changed, 2 insertions(+)
> 
> NAK: the code has provisions for multiple rectangles, if you enforce a
> single rectangle you need to remove the code that is now useless.

Fair enough, if we're fine with breaking the existing case further. Should I 
simply drop rectangles after a first, or return an error?

> 
> But I do not think pushing the issue onto the applications is a good way
> to fix the problem. Or even pushing the issue onto the framework, since
> the framework does not know the specifics. Better fix the code in ASS
> that handles multiple rectangles than inventing yet another annoying
> flag. A single frame can be encoded into multiple packets, so that
> should not be hard.

This is only true for audio/video encoders; subtitle encoders still use a 
different API, which does not have M:N support. There's some long-ongoing work 
to change that, but for now, this seems like the only way to deal with this 
case before that API overhaul.

> 
> Regards,
> 
> -- 
>  Nicolas George
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v7 0/4] add ARIB caption decoder using libaribcaption

[Ridley Combs]

> On Feb 23, 2023, at 04:17, TADANO Tokumei  wrote:
> 
> Ping with rebased patch set.
> Some chages are added to reflect review results from outside of this ML.
> 
> ---
> This patch set add another ARIB caption decoder using libaribcaption
> external library: https://github.com/xqq/libaribcaption
> The library decodes subtitles of ISDB-based TV broadcasting.
> It is not only for Japanese ARIB STD-B24 caption, but also for
> Brazilian ABNT NBR 15606-1 and Philippines version of ISDB-T.
> 
> Unlike libaribb24, it supports 3 types of subtitle outputs:
> * text: plain text
> * ass: ASS formatted text
> * bitmap: bitmap image
> 
> Default subtitle type is ASS as same as libaribb24.
> Advantages compared with libaribb24 on ASS subtitle are:
> * Subtitle positioning.
> * Multi-rect subtitle: some captions are displayed at different
>  position at a time.
> * More stability and reproducibility.
> 
> Subtitle type can be changed by `-sub_type` option.
> You can see ARIB caption with ffplay tool:
>  ffplay -sub_type bitmap MPEG.TS
> 
> Sample files exist under:
>  https://streams.videolan.org/streams/ts/ARIB/
> Some of them are encrypted and some don't contain ARIB caption data.
> Good samples for ARIB caption are:
>  brazil/07-25_20-33-35_UCV - HD_.ts
>  japan/channel2[137]_clear.ts
>  japan/osaka_15.ts
> 
> ---
> v7: reflect review results from outside of this ML
>  - rename -ass_workaround option to -ass_single_rect and default to
>false (latest mpv supports multiple ASS rectangle)
>  - add -canvas_size option to specify frame size to render bitmap subtitle
>  - add -caption_encoding option to specify encoding of subtitle text
>  - change behavior of profile C ARIB caption
>  - some cosmetic changes
> v6: reflect review results from outside of this ML
>  - check clut table overflow
>  - do not adjust vertical position of ruby for ASS format
> v5: reflect review comments from Mao Hata
>  - reset correct variable in aribcaption_close()
>  - add aribcaption_close() to some places in aribcaption_init()
>  - check if av_strdup() returns NULL in set_ass_header()
> v4: reflect review results from outside of this ML.
>  - resize bitmap subtitle image to display fonts with correct aspect ratio
>  - multiple font families can be specified by '-font' option
>  - remove 'rendering_backend' option
>  - add document
>  - minor bug fixes
> v3: combine former 1/4 and 2/4 due to the patchwork shows build error.
>  - fix help option content which incorrectly separated to 2 lines in 2/4.
>  - amend commit message of 4/4.
> 
> TADANO Tokumei (4):
>  lavc/libaribcaption.c: add ARIB caption decoder using libaribcaption
>  lavc/codec_desc.c: remove AV_CODEC_PROP_TEXT_SUB property
>  lavf/mpegts.c: set some properties for ARIB caption
>  doc/decoders.texi: add document of aribcaption decoder
> 
> configure   |4 +
> doc/decoders.texi   |  150 +
> libavcodec/Makefile |1 +
> libavcodec/allcodecs.c  |1 +
> libavcodec/codec_desc.c |1 -
> libavcodec/libaribb24.c |1 +
> libavcodec/libaribcaption.c | 1171 +++
> libavformat/mpegts.c|6 +-
> 8 files changed, 1333 insertions(+), 2 deletions(-)
> create mode 100644 libavcodec/libaribcaption.c
> 
> -- 
> 2.30.2
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

This set looks reasonable to me at this point; the one thing blocking it is the 
issue with assenc.c muxing for AVSubtitles with multiple rects, which needs a 
decision on this question: 
http://ffmpeg.org/pipermail/ffmpeg-devel/2023-February/306850.html

Once that's resolved, I'm happy to merge this.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] fftools: enable long path support on Windows

[Ridley Combs]

> On Mar 8, 2023, at 15:35, Martin Storsjö  wrote:
> 
> On Wed, 8 Mar 2023, rcombs wrote:
> 
>> This allows use of filesystem paths longer than MAX_PATH (260 characters)
>> on Windows 10 version 1607 and later.
>> 
>> This _may_ be a no-op if a "LongPathsEnabled" isn't set in the registry.
>> ---
>> fftools/fftools.manifest | 1 +
>> 1 file changed, 1 insertion(+)
> 
> Are you aware of the changes in c5aba39a041fdaac267fc8c6a2ef745a94a2b0da last 
> year? That was supposed to make this change redundant, and make long paths 
> usable even on versions of Windows older than that.
> 
> // Martin

I hadn't seen that change, but I do think it's still worth signaling our 
support for long paths explicitly.

> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Add functions to identify devices in more ways

[Ridley Combs]

> On May 9, 2023, at 12:16, Timo Rothenpieler  wrote:
> 
> On 09/05/2023 12:11, rcombs wrote:
>> - cuDeviceGetUuid_v2, giving distinct IDs for different MIG instances
>> - cuDeviceGetLuid, giving a Win32 LUID to match with DXGI and other APIs
>> - cuDeviceGetByPCIBusId, retrieving a device that matches a PCI bus ID string
>> - cuDeviceGetPCIBusId, giving a PCI bus ID string for a device
> 
> Looks good to me. What do you need those for?
> Interop with D3D1x/Vulkan?

I'm fetching device lists with DXGI (windows) or libdrm (linux); these 
functions seem to be the best way to correlate devices with those APIs. 
Probably also useful for D3D/Vk interop, though; particularly the v2 UUID 
function, as my guess is that the Vk interop code is probably broken in MIG 
mode right now.

Would appreciate seeing this backported to the 11.x branches; it applies 
cleanly.

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [ANNOUNCE] upcoming GA vote

[Ridley Combs via ffmpeg-devel]

Received.

> On Oct 25, 2023, at 07:22, Rémi Denis-Courmont  wrote:
> 
> Hi,
> 
> I am not on the GA, but there are probably people with my locale on the GA. 
> And it seems that the voting system hits a Perl syntax error if your browser 
> locale is set to French.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/assenc: normalize line endings to \n

[Ridley Combs via ffmpeg-devel]

> On Feb 13, 2024, at 01:28, Anton Khirnov  wrote:
> 
> Quoting Martin Storsjö (2024-02-12 12:31:29)
>> On Mon, 12 Feb 2024, Hendrik Leppkes wrote:
>> 
>>> On Mon, Feb 12, 2024 at 11:22 AM Martin Storsjö  wrote:
> 
> diff --git a/.gitattributes b/.gitattributes
> index 5a19b963b6..a900528e47 100644
> --- a/.gitattributes
> +++ b/.gitattributes
> @@ -1,2 +1 @@
> *.pnm -diff -text
> -tests/ref/fate/sub-scc eol=crlf
 
 This change seems to have had a tricky effect on the
 tests/ref/fate/sub-scc file. Previously, when checked out, users got the
 file with CRLF newlines. When updating to this git commit, or past it,
 that file remains untouched, with CRLF still present, and the
 fate-sub-scc test fails. If one does "rm tests/ref/fate/sub-scc; git
 checkout tests/ref/fate/sub-scc", then the file does get restored with LR
 newlines, and the test passes.
 
 It's easy to do this change manually in the source checkout of a fate
 runner, but I'm not sure how easily we get all fate instances fixed that
 way - currently this test is failing in most of them.
 
>>> 
>>> Can this be fixed by restoring the .gitattribute entry but with eol=lf?
>>> Not sure if Git would reset the file then.
>> 
>> No, that doesn't seem to make any difference. Not sure if there are any 
>> other straightforward/elegant fixes, short of renaming the file, which I 
>> guess would require renaming the test itself.
> 
> I'm fine with renaming the test, unless anyone has a better fix.

We could probably tweak the fate runner script to make sure this gets fixed up; 
can anyone try this patch on one of the affected machines? 
https://gist.github.com/rcombs/c2ad470bf36c5cbd3fc33e699330eb15

Alternately, we could set -text on all fate ref files, or explicitly set eol=of 
for them, to ensure their line endings never get rewritten like this regardless 
of git config. I think either of these solutions would fix this in fate, but 
only after the fix commit gets checked out *followed by* at least one other 
commit.

> 
> -- 
> Anton Khirnov
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org 
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org  with 
> subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/assenc: normalize line endings to \n

[Ridley Combs via ffmpeg-devel]

> On Feb 13, 2024, at 04:33, Martin Storsjö  wrote:
> 
> On Tue, 13 Feb 2024, Ridley Combs via ffmpeg-devel wrote:
> 
>>> On Feb 13, 2024, at 01:28, Anton Khirnov  wrote:
>>> Quoting Martin Storsjö (2024-02-12 12:31:29)
>>>> On Mon, 12 Feb 2024, Hendrik Leppkes wrote:
>>>>> On Mon, Feb 12, 2024 at 11:22 AM Martin Storsjö  wrote:
>>>>>>> diff --git a/.gitattributes b/.gitattributes
>>>>>>> index 5a19b963b6..a900528e47 100644
>>>>>>> --- a/.gitattributes
>>>>>>> +++ b/.gitattributes
>>>>>>> @@ -1,2 +1 @@
>>>>>>> *.pnm -diff -text
>>>>>>> -tests/ref/fate/sub-scc eol=crlf
>>>>>> This change seems to have had a tricky effect on the
>>>>>> tests/ref/fate/sub-scc file. Previously, when checked out, users got the
>>>>>> file with CRLF newlines. When updating to this git commit, or past it,
>>>>>> that file remains untouched, with CRLF still present, and the
>>>>>> fate-sub-scc test fails. If one does "rm tests/ref/fate/sub-scc; git
>>>>>> checkout tests/ref/fate/sub-scc", then the file does get restored with LR
>>>>>> newlines, and the test passes.
>>>>>> It's easy to do this change manually in the source checkout of a fate
>>>>>> runner, but I'm not sure how easily we get all fate instances fixed that
>>>>>> way - currently this test is failing in most of them.
>>>>> Can this be fixed by restoring the .gitattribute entry but with eol=lf?
>>>>> Not sure if Git would reset the file then.
>>>> No, that doesn't seem to make any difference. Not sure if there are any 
>>>> other straightforward/elegant fixes, short of renaming the file, which I 
>>>> guess would require renaming the test itself.
>>> I'm fine with renaming the test, unless anyone has a better fix.
>> 
>> We could probably tweak the fate runner script to make sure this gets fixed 
>> up; can anyone try this patch on one of the affected machines? 
>> https://gist.github.com/rcombs/c2ad470bf36c5cbd3fc33e699330eb15
> 
> That doesn't seem to make any difference.
> 
> Also, updating fate.sh doesn't necessarily propagate automatically to runners 
> - in order to run fate, one needs to run fate.sh before it even clones/checks 
> out the directory where it fetches the latest source. So unless one later has 
> changed one's setup, to invoke a fate.sh from the checkout, most fate runners 
> just use whatever copy of fate.sh they had when it was set up.
> 
>> Alternately, we could set -text on all fate ref files, or explicitly set 
>> eol=of for them, to ensure their line endings never get rewritten like this 
>> regardless of git config. I think either of these solutions would fix this 
>> in fate, but only after the fix commit gets checked out *followed by* at 
>> least one other commit.
> 
> Neither of those seem to make any difference either.
> 
> It's quite easy to test for one self:
> 
> $ git checkout -b experiment
> $ 
> $ 
> 
> $ git checkout 7bf1b9b3576~ # Reset original state, for testing
> $ rm tests/ref/fate/sub-scc; git checkout tests/ref/fate/sub-scc
> $ vi tests/ref/fate/sub-scc # inspect that the file originally has CRLF
> $ git checkout experiment~ # check out the commit setting attributes
> $ git checkout experiment # check out the next commit, with the new 
> attributes set
> $ vi tests/ref/fate/sub-scc # observe that the file still has CRLF
> 
> $ git checkout --detach
> $ git -c core.autocrlf=false reset --hard 7bf1b9b3576
> $ vi tests/ref/fate/sub-scc # observe that the file still has CRLF

It looks like checkout has different behavior from reset, and fate uses a hard 
reset.
To test, I committed the change adding tests/ref/** -text, unix2dos'd 
tests/ref/fate/sub-scc, then ran git -c core.autocrlf=true reset --quiet 
--hard; this dos2unix'd the file as expected when run with a working tree 
containing the .gitattributes change (but not otherwise).

> 
> 
> It seems to me (I haven't trid to dig into manuals) that the attribute gets 
> stuck in whatever form it was when the file was first created in the workdir. 
> E.g. doing a "git checkout d1df72a702~" (the commit before the file was 
> originally added) followed by "git checkout 7bf1b9b3576" does fix it. This is 
> at least observed with git 2.25.1. Not sure if this is intended behaviour or 
> a bug from git's side.

Git doesn't have any "memory" of the CRLFiness of a file beyond the content of 
the file itself (whether in the working tree or in committed blobs). It just 
doesn't necessarily replace every file in checkout invocations when they differ 
only in line endings. Windows was a mistake.

> 
> // Martin

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avdevice/v4l2: Switch to wrapped AVFrames and implement strides

[Ridley Combs via ffmpeg-devel]

> On Sep 29, 2023, at 00:52, Asahi Lina via ffmpeg-devel 
>  wrote:
> 
> V4L2 provides a line stride to the client for hardware that has
> alignment requirements. rawvideo cannot represent this, so switch to
> wrapped_avframe for raw video formats and calculate the plane strides
> manually.
> 
> This is slightly messy because the existing helper APIs expect
> dimensions and an alignment value, while v4l2 provides the stride of
> plane 0 and the subsequent plane strides are implied, so we need to
> open-code the logic to calculate the plane strides.
> 
> This makes vertical video work properly on Apple Macs with "1080p"
> cameras, which are actually square and can support resolutions like
> 1080x1920, which require stride padding to a multiple of 64 bytes.
> 
> In principle, this could be extended to support the V4L2 multiplanar
> API, though there seem to be practically no capture (not M2M) drivers
> that support this, so it's not terribly useful right now.
> 
> Signed-off-by: Asahi Lina 
> ---
> libavdevice/v4l2-common.c |  68 +++
> libavdevice/v4l2.c| 138 +++---
> 2 files changed, 151 insertions(+), 55 deletions(-)
> 
> diff --git a/libavdevice/v4l2-common.c b/libavdevice/v4l2-common.c
> index b5b4448a3154..944ffe3d87e1 100644
> --- a/libavdevice/v4l2-common.c
> +++ b/libavdevice/v4l2-common.c
> @@ -19,53 +19,53 @@
> #include "v4l2-common.h"
> 
> const struct fmt_map ff_fmt_conversion_table[] = {
> -//ff_fmt  codec_id  v4l2_fmt
> -{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV420  },
> -{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU420  },
> -{ AV_PIX_FMT_YUV422P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV422P },
> -{ AV_PIX_FMT_YUYV422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUYV},
> -{ AV_PIX_FMT_UYVY422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_UYVY},
> -{ AV_PIX_FMT_YUV411P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV411P },
> -{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV410  },
> -{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU410  },
> -{ AV_PIX_FMT_RGB555LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555  },
> -{ AV_PIX_FMT_RGB555BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555X },
> -{ AV_PIX_FMT_RGB565LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565  },
> -{ AV_PIX_FMT_RGB565BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565X },
> -{ AV_PIX_FMT_BGR24,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR24   },
> -{ AV_PIX_FMT_RGB24,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB24   },
> +//ff_fmt  codec_id v4l2_fmt
> +{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_YUV420  
> },
> +{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_YVU420  
> },
> +{ AV_PIX_FMT_YUV422P, AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_YUV422P 
> },
> +{ AV_PIX_FMT_YUYV422, AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_YUYV
> },
> +{ AV_PIX_FMT_UYVY422, AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_UYVY
> },
> +{ AV_PIX_FMT_YUV411P, AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_YUV411P 
> },
> +{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_YUV410  
> },
> +{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_YVU410  
> },
> +{ AV_PIX_FMT_RGB555LE,AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_RGB555  
> },
> +{ AV_PIX_FMT_RGB555BE,AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_RGB555X 
> },
> +{ AV_PIX_FMT_RGB565LE,AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_RGB565  
> },
> +{ AV_PIX_FMT_RGB565BE,AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_RGB565X 
> },
> +{ AV_PIX_FMT_BGR24,   AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_BGR24   
> },
> +{ AV_PIX_FMT_RGB24,   AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_RGB24   
> },
> #ifdef V4L2_PIX_FMT_XBGR32
> -{ AV_PIX_FMT_BGR0,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_XBGR32  },
> -{ AV_PIX_FMT_0RGB,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_XRGB32  },
> -{ AV_PIX_FMT_BGRA,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_ABGR32  },
> -{ AV_PIX_FMT_ARGB,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_ARGB32  },
> +{ AV_PIX_FMT_BGR0,AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_XBGR32  
> },
> +{ AV_PIX_FMT_0RGB,AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_XRGB32  
> },
> +{ AV_PIX_FMT_BGRA,AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_ABGR32  
> },
> +{ AV_PIX_FMT_ARGB,AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_ARGB32  
> },
> #endif
> -{ AV_PIX_FMT_BGR0,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR32   },
> -{ AV_PIX_FMT_0RGB,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB32   },
> -{ AV_PIX_FMT_GRAY8,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_GREY},
> +{ AV_PIX_FMT_BGR0,AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_BGR32   
> },
> +{ AV_PIX_FMT_0RGB,AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_RGB32   
> },
> +{ AV_PIX_FMT_GRAY8,   AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX

Re: [FFmpeg-devel] [PATCH v1 2/5] avformat: add muxer support for H266/VVC

[Ridley Combs via ffmpeg-devel]

> On Jan 4, 2024, at 16:31, James Almer  wrote:
> 
> On 11/3/2023 6:57 AM, Thomas Siedel wrote:
>> Add muxer for vvcc byte stream format.
>> Add AV_CODEC_ID_VVC to ff_mp4_obj_type.
>> Add AV_CODEC_ID_VVC to ISO Media codec (VvcConfigurationBox vvi1,
>> vvc1 defined in ISO/IEC 14496-15:2021).
>> Add VvcConfigurationBox vvcC which extends FullBox type in
>> ISO/IEC 14496-15:2021.
>> Add ff_vvc_muxer to RAW muxers.
>> Signed-off-by: Thomas Siedel 
>> ---
>>  libavformat/Makefile|   6 +-
>>  libavformat/isom.c  |   1 +
>>  libavformat/isom_tags.c |   3 +
>>  libavformat/mov.c   |   6 +
>>  libavformat/movenc.c|  41 +-
>>  libavformat/vvc.c   | 998 
>>  libavformat/vvc.h   |  99 
>>  7 files changed, 1150 insertions(+), 4 deletions(-)
>>  create mode 100644 libavformat/vvc.c
>>  create mode 100644 libavformat/vvc.h
>> diff --git a/libavformat/Makefile b/libavformat/Makefile
>> index 329055ccfd..595f6bdf08 100644
>> --- a/libavformat/Makefile
>> +++ b/libavformat/Makefile
>> @@ -341,7 +341,7 @@ OBJS-$(CONFIG_MATROSKA_DEMUXER)  += 
>> matroskadec.o matroska.o  \
>>  oggparsevorbis.o 
>> vorbiscomment.o \
>>  qtpalette.o replaygain.o 
>> dovi_isom.o
>>  OBJS-$(CONFIG_MATROSKA_MUXER)+= matroskaenc.o matroska.o \
>> -av1.o avc.o hevc.o \
>> +av1.o avc.o hevc.o vvc.o\
>>  flacenc_header.o avlanguage.o \
>>  vorbiscomment.o wv.o dovi_isom.o
>>  OBJS-$(CONFIG_MCA_DEMUXER)   += mca.o
>> @@ -363,7 +363,7 @@ OBJS-$(CONFIG_MODS_DEMUXER)  += mods.o
>>  OBJS-$(CONFIG_MOFLEX_DEMUXER)+= moflex.o
>>  OBJS-$(CONFIG_MOV_DEMUXER)   += mov.o mov_chan.o mov_esds.o \
>>  qtpalette.o replaygain.o 
>> dovi_isom.o
>> -OBJS-$(CONFIG_MOV_MUXER) += movenc.o av1.o avc.o hevc.o 
>> vpcc.o \
>> +OBJS-$(CONFIG_MOV_MUXER) += movenc.o av1.o avc.o hevc.o 
>> vvc.o vpcc.o \
>>  movenchint.o mov_chan.o rtp.o \
>>  movenccenc.o movenc_ttml.o 
>> rawutils.o \
>>  dovi_isom.o evc.o
>> @@ -516,7 +516,7 @@ OBJS-$(CONFIG_RTP_MUXER) += rtp.o
>>  \
>>  rtpenc_vp8.o  \
>>  rtpenc_vp9.o\
>>  rtpenc_xiph.o \
>> -avc.o hevc.o
>> +avc.o hevc.o vvc.o
>>  OBJS-$(CONFIG_RTSP_DEMUXER)  += rtsp.o rtspdec.o httpauth.o \
>>  urldecode.o
>>  OBJS-$(CONFIG_RTSP_MUXER)+= rtsp.o rtspenc.o httpauth.o \
>> diff --git a/libavformat/isom.c b/libavformat/isom.c
>> index 6d019881e5..9fbccd4437 100644
>> --- a/libavformat/isom.c
>> +++ b/libavformat/isom.c
>> @@ -36,6 +36,7 @@ const AVCodecTag ff_mp4_obj_type[] = {
>>  { AV_CODEC_ID_MPEG4   , 0x20 },
>>  { AV_CODEC_ID_H264, 0x21 },
>>  { AV_CODEC_ID_HEVC, 0x23 },
>> +{ AV_CODEC_ID_VVC , 0x33 },
>>  { AV_CODEC_ID_AAC , 0x40 },
>>  { AV_CODEC_ID_MP4ALS  , 0x40 }, /* 14496-3 ALS */
>>  { AV_CODEC_ID_MPEG2VIDEO  , 0x61 }, /* MPEG-2 Main */
>> diff --git a/libavformat/isom_tags.c b/libavformat/isom_tags.c
>> index a575b7c160..705811e950 100644
>> --- a/libavformat/isom_tags.c
>> +++ b/libavformat/isom_tags.c
>> @@ -123,6 +123,9 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
>>  { AV_CODEC_ID_HEVC, MKTAG('d', 'v', 'h', 'e') }, /* HEVC-based Dolby 
>> Vision derived from hev1 */
>>   /* dvh1 is handled 
>> within mov.c */
>>  +{ AV_CODEC_ID_VVC, MKTAG('v', 'v', 'i', '1') },  /* VVC/H.266 which 
>> indicates parameter sets may be in ES */
>> +{ AV_CODEC_ID_VVC, MKTAG('v', 'v', 'c', '1') },  /* VVC/H.266 which 
>> indicates parameter shall not be in ES */
>> +
>>  { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '1') }, /* AVC-1/H.264 */
>>  { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '2') },
>>  { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '3') },
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index e8efccf6eb..11b43ac135 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -2117,6 +2117,11 @@ static int mov_read_glbl(MOVContext *c, AVIOContext 
>> *pb, MOVAtom atom)
>>  if ((uint64_t)atom.size > (1<<30))
>>  return AVERROR_INVALIDDATA;
>>  +if (atom.type == MKTAG('v','v','c','C')) {
>> +avio_rb32(pb);
> 
> avio_skip(pb, 4);
> 
>> + 

Re: [FFmpeg-devel] [PATCH] avfilter/vf_subtitles: Respect YCbCr Matrix header

[Ridley Combs via ffmpeg-devel]

> On Oct 13, 2024, at 05:45, arch1t3cht  wrote:
> 
> As specified in libass's ass_types.h, the colors or ASS_Images
> should be converted to YCbCr using the matrix/range specified in
> the track's YCbCrMatrix field (unless that field is set to YCBCR_NONE,
> and defaulting to TV.601 if the header is missing).
> 
> This does not affect any subtitles generated or transcoded by ffmpeg,
> since these contain a 'YCbCrMatrix: None' header.
> 
> Signed-off-by: arch1t3cht 
> ---
> libavfilter/vf_subtitles.c | 38 +-
> 1 file changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git a/libavfilter/vf_subtitles.c b/libavfilter/vf_subtitles.c
> index de1cfa7d9e..ed1d12ca76 100644
> --- a/libavfilter/vf_subtitles.c
> +++ b/libavfilter/vf_subtitles.c
> @@ -88,6 +88,40 @@ static const int ass_libavfilter_log_level_map[] = {
> [7] = AV_LOG_DEBUG, /* MSGL_DBG2 */
> };
> 
> +static enum AVColorSpace ass_get_color_space(ASS_YCbCrMatrix ass_matrix, 
> enum AVColorSpace inlink_space) {
> +switch (ass_matrix) {
> +case YCBCR_NONE:return inlink_space;
> +case YCBCR_SMPTE240M_TV:
> +case YCBCR_SMPTE240M_PC:return AVCOL_SPC_SMPTE240M;
> +case YCBCR_FCC_TV:
> +case YCBCR_FCC_PC:  return AVCOL_SPC_FCC;
> +case YCBCR_BT709_TV:
> +case YCBCR_BT709_PC:return AVCOL_SPC_BT709;
> +case YCBCR_BT601_TV:
> +case YCBCR_BT601_PC:
> +case YCBCR_DEFAULT:
> +case YCBCR_UNKNOWN:
> +default:return AVCOL_SPC_SMPTE170M;
> +}
> +}
> +
> +static enum AVColorRange ass_get_color_range(ASS_YCbCrMatrix ass_matrix, 
> enum AVColorRange inlink_range) {
> +switch (ass_matrix) {
> +case YCBCR_NONE:return inlink_range;
> +case YCBCR_SMPTE240M_PC:
> +case YCBCR_FCC_PC:
> +case YCBCR_BT709_PC:
> +case YCBCR_BT601_PC:return AVCOL_RANGE_JPEG;
> +case YCBCR_SMPTE240M_TV:
> +case YCBCR_FCC_TV:
> +case YCBCR_BT709_TV:
> +case YCBCR_BT601_TV:
> +case YCBCR_DEFAULT:
> +case YCBCR_UNKNOWN:
> +default:return AVCOL_RANGE_MPEG;
> +}
> +}
> +
> static void ass_log(int ass_level, const char *fmt, va_list args, void *ctx)
> {
> const int ass_level_clip = av_clip(ass_level, 0,
> @@ -147,7 +181,9 @@ static int config_input(AVFilterLink *inlink)
> {
> AssContext *ass = inlink->dst->priv;
> 
> -ff_draw_init2(&ass->draw, inlink->format, inlink->colorspace, 
> inlink->color_range,
> +ff_draw_init2(&ass->draw, inlink->format,
> +  ass_get_color_space(ass->track->YCbCrMatrix, 
> inlink->colorspace),
> +  ass_get_color_range(ass->track->YCbCrMatrix, 
> inlink->color_range),
>   ass->alpha ? FF_DRAW_PROCESS_ALPHA : 0);
> 
> ass_set_frame_size  (ass->renderer, inlink->w, inlink->h);
> -- 
> 2.47.0
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

LGTM; will push on Friday if nobody objects.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that decode_str() did advance

[Ridley Combs via ffmpeg-devel]

> On Apr 15, 2025, at 08:59, softworkz .  
> wrote:
> 
> 
> 
>> -Original Message-
>> From: ffmpeg-devel > > On Behalf Of
>> Michael Niedermayer
>> Sent: Dienstag, 15. April 2025 01:20
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org >
>> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
>> decode_str() did advance
>> 
>> On Sat, Apr 12, 2025 at 01:49:53AM +, softworkz . wrote:
>>> 
>>> 
 -Original Message-
 From: ffmpeg-devel  On Behalf Of
 Michael Niedermayer
 Sent: Samstag, 12. April 2025 00:27
 To: FFmpeg development discussions and patches > de...@ffmpeg.org>
 Subject: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
 decode_str() did advance
 
 Fixes infinite loop with unknown encodings
 
 We could alternatively error out from decode_str() or consume all
>> of
 taglen
 this would affect other callers though.
 
 Fixes: 409819224/clusterfuzz-testcase-minimized-
>> ffmpeg_dem_H261_fuzzer-
 6003527535362048
 Signed-off-by: Michael Niedermayer 
 ---
 libavformat/id3v2.c | 3 +++
 1 file changed, 3 insertions(+)
 
 diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
 index 90314583a74..e3f7f9e2a90 100644
 --- a/libavformat/id3v2.c
 +++ b/libavformat/id3v2.c
 @@ -341,10 +341,13 @@ static void read_ttag(AVFormatContext *s,
 AVIOContext *pb, int taglen,
 taglen--; /* account for encoding type byte */
 
 while (taglen > 1) {
 +int current_taglen = taglen;
 if (decode_str(s, pb, encoding, &dst, &taglen) < 0) {
 av_log(s, AV_LOG_ERROR, "Error reading frame %s,
 skipped\n", key);
 return;
 }
 +if (current_taglen == taglen)
 +return;
 
 count++;
 
 --
 2.49.0
 
 ___
>>> 
>>> Hi Michael,
>>> 
>>> this kind of conflicts with this patch that I had submitted
>> recently:
>>> 
>>> 
>> https://patchwork.ffmpeg.org/project/ffmpeg/patch/pull.54.ffstaging.FF
>> mpeg.1740873449247.ffmpegag...@gmail.com/
>>> 
>>> 
>>> I wonder whether my patch would still be prone to the issue your
>> patch is addressing -
>> 
>> This already conflicts with rcombs patch in git master, i think
>> Applying: Fixes Trac ticket https://trac.ffmpeg.org/ticket/6949
>> Using index info to reconstruct a base tree...
>> Mlibavformat/id3v2.c
>> Falling back to patching base and 3-way merge...
>> Auto-merging libavformat/id3v2.c
>> CONFLICT (content): Merge conflict in libavformat/id3v2.c
>> error: Failed to merge in the changes.
>> Patch failed at 0001 Fixes Trac ticket
>> https://trac.ffmpeg.org/ticket/6949
>> 
>> 
>>> do you have a test file perhaps?
>> 
>> Will email you one, but the loop with a function that doesnt advance
>> is an issue even if the specific file doesnt trigger it in a different
>> implementation
>> 
>> also probaly a good idea if you contact rcombs as you seemed to work
>> on
>> the same code
>> 
>> I was looking at teh ticket and saw a link to rcombs patch, looked at
>> the patch and applied it. I did not realize there where 2 patches
> 
> 
> Hi Michael,
> 
> I know the rcombs patch, but it has a - let's say - different behavior.
> Let's look at an example where artist and genre have multiple values:
> 
> 
> This was ffmpeg output unpatched:
> 
>  Metadata:
>title   : Infinite (Original Mix)
>artist  : B-Front
>track   : 1
>album   : Infinite
>date: 2017
>genre   : Hardstyle
>TBPM: 150
>compilation : 0
>album_artist: B-Front
>publisher   : Roughstate
> 
> 
> This is what the rcombs patch does:
> 
>  Metadata:
>title   : Infinite (Original Mix)
>artist  : B-Front
>artist  : Second Artist Example
>track   : 1
>album   : Infinite
>date: 2017
>genre   : Hardstyle
>genre   : Test
>genre   : Example
>genre   : Hard Dance
>TBPM: 150
>compilation : 0
>album_artist: B-Front
>publisher   : Roughstate
> 
> 
> 
> My path does that:
> 
>  Metadata:
>title   : Infinite (Original Mix)
>artist  : B-Front;Second Artist Example
>track   : 1
>album   : Infinite
>date: 2017
>genre   : Hardstyle;Test;Example;Hard Dance
>TBPM: 150
>compilation : 0
>album_artist: B-Front
>publisher   : Roughstate
> 
> 
> 
> I'm not sure whether it is even allowed or intended that there are 
> multiple metadata entries with the same key?

It is indeed an intended feature of the AVDictionary system, and the metadata 
feature in particular.

> 
> B

Re: [FFmpeg-devel] [PATCH] swscale/options: use accurate rounding and full chroma by default

[Ridley Combs via ffmpeg-devel]

--- Begin Message ---


> On Jun 9, 2025, at 05:17, Michael Niedermayer  wrote:
> 
> Hi
> 
> On Sun, Jun 08, 2025 at 04:52:35PM -0700, rcombs via ffmpeg-devel wrote:
>> Date: Sun,  8 Jun 2025 16:52:35 -0700
>> From: rcombs 
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: [PATCH] swscale/options: use accurate rounding and full chroma by 
>> default
>> 
>> This has been causing quality degradation for people since the dawn of sws,
>> and the performance concerns that originally led to this default have been
>> soundly defeated by the march of time.
>> ---
> [...]
> 
> Do we know why the cases below become worse ?

I'm not sure; it seems like similar numbers of cases moved in each direction, 
and I'm kinda inclined to chalk it up to noise. It does look like a lot of them 
are cases where we round-trip yuv420 -> rgb -> yuv420, and it's possible that 
the current code path just happens to give better PSNR on that some of the time?

> 
> 
>> --- a/tests/ref/vsynth/vsynth1-jpeg2000
>> +++ b/tests/ref/vsynth/vsynth1-jpeg2000
>> @@ -1,4 +1,4 @@
>> -95add005faf68fcf8f16e86eab079ca2 *tests/data/fate/vsynth1-jpeg2000.avi
>> -2263192 tests/data/fate/vsynth1-jpeg2000.avi
>> -b7f48a8965f78011c76483277befc6fc 
>> *tests/data/fate/vsynth1-jpeg2000.out.rawvideo
>> -stddev:5.35 PSNR: 33.56 MAXDIFF:   59 bytes:  7603200/  7603200
>> +2ce46a92e9cc399b79c22534d8ae8350 *tests/data/fate/vsynth1-jpeg2000.avi
>> +2250458 tests/data/fate/vsynth1-jpeg2000.avi
>> +7980403710bc90ccb5c8d016581df711 
>> *tests/data/fate/vsynth1-jpeg2000.out.rawvideo
>> +stddev:5.57 PSNR: 33.21 MAXDIFF:   54 bytes:  7603200/  7603200
>> diff --git a/tests/ref/vsynth/vsynth1-jpeg2000-97 
>> b/tests/ref/vsynth/vsynth1-jpeg2000-97
>> index 820249c6c0..698b619442 100644
>> --- a/tests/ref/vsynth/vsynth1-jpeg2000-97
>> +++ b/tests/ref/vsynth/vsynth1-jpeg2000-97
>> @@ -1,4 +1,4 @@
>> -803c2e8a4d054c5d603eed4c77abe492 *tests/data/fate/vsynth1-jpeg2000-97.avi
>> -4466514 tests/data/fate/vsynth1-jpeg2000-97.avi
>> -c9cf5a4580f10b00056c8d8731d21395 
>> *tests/data/fate/vsynth1-jpeg2000-97.out.rawvideo
>> -stddev:3.82 PSNR: 36.49 MAXDIFF:   49 bytes:  7603200/  7603200
>> +558aede84e4792596595dfa15729c730 *tests/data/fate/vsynth1-jpeg2000-97.avi
>> +4303250 tests/data/fate/vsynth1-jpeg2000-97.avi
>> +a1ff0cdd46f6f3ed2646fd47874aa405 
>> *tests/data/fate/vsynth1-jpeg2000-97.out.rawvideo
>> +stddev:4.08 PSNR: 35.90 MAXDIFF:   48 bytes:  7603200/  7603200
>> diff --git a/tests/ref/vsynth/vsynth1-jpeg2000-gbrp12 
>> b/tests/ref/vsynth/vsynth1-jpeg2000-gbrp12
>> index 0c6d47778f..8d15116b0b 100644
>> --- a/tests/ref/vsynth/vsynth1-jpeg2000-gbrp12
>> +++ b/tests/ref/vsynth/vsynth1-jpeg2000-gbrp12
>> @@ -1,4 +1,4 @@
>> 78b35a445001d2879386fdad16a2f0be *tests/data/fate/vsynth1-jpeg2000-gbrp12.avi
>> 8163968 tests/data/fate/vsynth1-jpeg2000-gbrp12.avi
>> -e934632ff63a00b4f2c9b3061f9c410e 
>> *tests/data/fate/vsynth1-jpeg2000-gbrp12.out.rawvideo
>> -stddev:3.51 PSNR: 37.21 MAXDIFF:   43 bytes:  7603200/  7603200
>> +d8969ef75c8ba574512730b5e9bea980 
>> *tests/data/fate/vsynth1-jpeg2000-gbrp12.out.rawvideo
>> +stddev:3.71 PSNR: 36.72 MAXDIFF:   47 bytes:  7603200/  7603200
>> diff --git a/tests/ref/vsynth/vsynth1-mov-bgr24 
>> b/tests/ref/vsynth/vsynth1-mov-bgr24
>> index 6639d0d544..0c6a8461ae 100644
>> --- a/tests/ref/vsynth/vsynth1-mov-bgr24
>> +++ b/tests/ref/vsynth/vsynth1-mov-bgr24
>> @@ -1,4 +1,4 @@
>> -ba9d5cbc4b432db076fb501b1d5fa536 *tests/data/fate/vsynth1-mov-bgr24.mov
>> +87c924fb0a492bebfbb2afc594414efa *tests/data/fate/vsynth1-mov-bgr24.mov
>> 15207169 tests/data/fate/vsynth1-mov-bgr24.mov
>> -93695a27c24a61105076ca7b1f010bbd 
>> *tests/data/fate/vsynth1-mov-bgr24.out.rawvideo
>> -stddev:3.42 PSNR: 37.44 MAXDIFF:   48 bytes:  7603200/  7603200
>> +36e56ffc4ef51b8185a8b04c7a756c3e 
>> *tests/data/fate/vsynth1-mov-bgr24.out.rawvideo
>> +stddev:3.72 PSNR: 36.71 MAXDIFF:   48 bytes:  7603200/  7603200
>> diff --git a/tests/ref/vsynth/vsynth1-mov-bpp15 
>> b/tests/ref/vsynth/vsynth1-mov-bpp15
>> index d42c40b19a..ee50a2a896 100644
>> --- a/tests/ref/vsynth/vsynth1-mov-bpp15
>> +++ b/tests/ref/vsynth/vsynth1-mov-bpp15
>> @@ -1,4 +1,4 @@
>> dfd88a906ae744caf3c455224fa3 *tests/data/fate/vsynth1-mov-bpp15.mov
>> 10138329 tests/data/fate/vsynth1-mov-bpp15.mov
>> -99bece160cfb0da47f446b60d42fa3ae 
>> *tests/data/fate/vsynth1-mov-bpp15.out.rawvideo
>> -stddev:4.06 PSNR: 35.94 MAXDIFF:   47 bytes:  7603200/  7603200
>> +23d89c693d78c049c6029c1e70b37e6f 
>> *tests/data/fate/vsynth1-mov-bpp15.out.rawvideo
>> +stddev:4.37 PSNR: 35.31 MAXDIFF:   47 bytes:  7603200/  7603200
>> diff --git a/tests/ref/vsynth/vsynth1-mov-bpp16 
>> b/tests/ref/vsynth/vsynth1-mov-bpp16
>> index bdafbf14ce..32cbf60854 100644
>> --- a/tests/ref/vsynth/vsynth1-mov-bpp16
>> +++ b/tests/ref/vsynth/vsynth1-mov-bpp16
>> @@ -1,4 +1,4 @@
>> 3d7e3f8bd238c341b0b4d55a30d8f5a2 *tests/data/fate/vsynth1-mov-bpp16.mov
>> 10138329 tests/data/fate/vsynth1-mov-bpp16.mov
>> -0cea38