Re: [FFmpeg-devel] [PATCH v2 5/6] avcodec/hevc/sei: dynamically allocate 3D Reference Displays Information SEI messages

[Michael Niedermayer]

Hi

On Wed, Feb 05, 2025 at 11:50:17PM -0300, James Almer wrote:
> Considerably reduces the size of HEVCSEI.
> 
> Signed-off-by: James Almer 
> ---
> Fixed segfaults.
> 
>  libavcodec/hevc/hevcdec.c | 10 +-
>  libavcodec/hevc/refs.c|  4 ++--
>  libavcodec/hevc/sei.c |  6 +-
>  libavcodec/hevc/sei.h |  6 +-
>  4 files changed, 17 insertions(+), 9 deletions(-)

seems not applying on ma local tree, do you have some branch i can just merge
to test this ?

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avformat/hls: fix typo There is an extra space in the original comment

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Jack Lau via ffmpeg-devel
> Sent: Monday, February 10, 2025 1:34 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Jack Lau 
> Subject: [FFmpeg-devel] [PATCH] avformat/hls: fix typo There is an
> extra space in the original comment
> 
> ---
>  libavformat/hls.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 3bdc1bc848..c2130bb883 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -1993,7 +1993,7 @@ static int hls_read_header(AVFormatContext *s)
>  return ret;
> 
>  /* XXX: Some HLS servers don't like being sent the range header,
> -   in this case, need to  setting http_seekable = 0 to disable
> +   in this case, need to setting http_seekable = 0 to disable
> the range header */
>  av_dict_set_int(&c->avio_opts, "seekable", c->http_seekable, 0);
> 
> --
> 2.48.1

Hi Jack,

you're not working on a proof of concept regarding the vulnerability of the GA, 
right? 
(just kidding)

As an idea, you might be able to give that patch a little bit more meaning by 
also fixing the grammar.

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

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

Re: [FFmpeg-devel] [PATCH v2 5/6] avcodec/hevc/sei: dynamically allocate 3D Reference Displays Information SEI messages

[James Almer]

On 2/9/2025 9:53 PM, Michael Niedermayer wrote:

Hi

On Wed, Feb 05, 2025 at 11:50:17PM -0300, James Almer wrote:

Considerably reduces the size of HEVCSEI.

Signed-off-by: James Almer 
---
Fixed segfaults.

  libavcodec/hevc/hevcdec.c | 10 +-
  libavcodec/hevc/refs.c|  4 ++--
  libavcodec/hevc/sei.c |  6 +-
  libavcodec/hevc/sei.h |  6 +-
  4 files changed, 17 insertions(+), 9 deletions(-)


seems not applying on ma local tree, do you have some branch i can just merge
to test this ?

thx


Sure, pushed to https://github.com/jamrial/FFmpeg/commits/tdrdi/



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Captions SCC

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Marth64
> Sent: Sunday, February 9, 2025 8:38 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
> 
> Partial reply:
> FFmpeg's CC decoder is actually pretty decent for pop-on CC
> but produces non-compliant ASS that needs postprocessing.
> 
> ASS can cover and render the pop-ons quite well, but the fundamental
> limitation with representing EIA608 with ASS is that ASS does not
> allow arbitrary positioning AND justification at the same time,
> without making each line its own cue and carefully positioning the
> cues or applying some other complex workarounds. The only alternative
> I can think of within the ASS domain is to use heuristics to
> determine
> numpad positioning of the caption cue and declare justification tags
> without arbitrary positioning, but it needs work and will not be
> exact.
> 
> This is a problem for say, I want to render a cue at position x,y
> but I want it also left justified at that position.

Numpad alignment 7, LeftMargin=x VertMargin=y

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

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

Re: [FFmpeg-devel] [PATCH] avformat/hls: fix typo There is an extra space in the original comment

[Jack Lau]

Hi,

Thanks for your reply.

I'm trying to fix some issues with hls. I happened to see this typo. Since I 
saw in the ffmpeg documentation that cosmetic changes should be kept in 
separate patches, so i submitted it first. 

Thank you for your advice, I will try my best to submit more important patches.

Best wishes
Jack


> On Feb 10, 2025, at 08:54, Soft Works  
> wrote:
> 
> 
> 
>> -Original Message-
>> From: ffmpeg-devel > > On Behalf Of
>> Jack Lau via ffmpeg-devel
>> Sent: Monday, February 10, 2025 1:34 AM
>> To: ffmpeg-devel@ffmpeg.org 
>> Cc: Jack Lau mailto:jacklau1...@qq.com>>
>> Subject: [FFmpeg-devel] [PATCH] avformat/hls: fix typo There is an
>> extra space in the original comment
>> 
>> ---
>> libavformat/hls.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/libavformat/hls.c b/libavformat/hls.c
>> index 3bdc1bc848..c2130bb883 100644
>> --- a/libavformat/hls.c
>> +++ b/libavformat/hls.c
>> @@ -1993,7 +1993,7 @@ static int hls_read_header(AVFormatContext *s)
>> return ret;
>> 
>> /* XXX: Some HLS servers don't like being sent the range header,
>> -   in this case, need to  setting http_seekable = 0 to disable
>> +   in this case, need to setting http_seekable = 0 to disable
>>the range header */
>> av_dict_set_int(&c->avio_opts, "seekable", c->http_seekable, 0);
>> 
>> --
>> 2.48.1
> 
> Hi Jack,
> 
> you're not working on a proof of concept regarding the vulnerability of the 
> GA, right? 
> (just kidding)
> 
> As an idea, you might be able to give that patch a little bit more meaning by 
> also fixing the grammar.
> 
> Best wishes
> sw
> ___
> 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] avformat/unix: Set is_streamed to true

[Michael Niedermayer]

Hi Efrain

On Wed, Feb 05, 2025 at 07:25:23PM -0600, Efrain Torres wrote:
> Currently when a Unix Domain Socket is used as input there is a loss of data
> when data is consumed from the stream. Setting is_streamed to true fixes
> this, since the unix domain socket is now treated like a consumable stream.
> 
> Fixes: #9346
> 
> Signed-off-by: dank074 
> ---
>  libavformat/unix.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/unix.c b/libavformat/unix.c
> index 5704155cf0..2de4023835 100644
> --- a/libavformat/unix.c
> +++ b/libavformat/unix.c
> @@ -89,7 +89,7 @@ static int unix_open(URLContext *h, const char *filename,
> int flags)
>  }

This patch is corrupted by a newline, check your editors word/line wrap settings
OR
attach the patch
OR
use git send-email

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] avformat/hls: fix typo There is an extra space in the original comment

[Jack Lau via ffmpeg-devel]

---
 libavformat/hls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 3bdc1bc848..c2130bb883 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -1993,7 +1993,7 @@ static int hls_read_header(AVFormatContext *s)
 return ret;
 
 /* XXX: Some HLS servers don't like being sent the range header,
-   in this case, need to  setting http_seekable = 0 to disable
+   in this case, need to setting http_seekable = 0 to disable
the range header */
 av_dict_set_int(&c->avio_opts, "seekable", c->http_seekable, 0);
 
-- 
2.48.1

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

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

Re: [FFmpeg-devel] [PATCH] avformat/hls: fix typo There is an extra space in the original comment

[Marth64]

I don't think its fair to shoot this down, its a simple but valid tidy up work.
I find typos and such when browsing code distracting and readability
important down the road.
Not everyone's first language is English and grammar correction may
not come instinctively.

Thank you for the contribution Jack. Unless there is any objection on
grounds of maintaining commit history, I'll adjust the grammar of
"need to setting" -> "we need to set" and push this soon.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avformat/hls: fix typo There is an extra space in the original comment

[Jack Lau]

> On Feb 10, 2025, at 11:08, Marth64  wrote:
> 
> I don't think its fair to shoot this down, its a simple but valid tidy up 
> work.
> I find typos and such when browsing code distracting and readability
> important down the road.
> Not everyone's first language is English and grammar correction may
> not come instinctively.
> 
> Thank you for the contribution Jack. Unless there is any objection on
> grounds of maintaining commit history, I'll adjust the grammar of
> "need to setting" -> "we need to set" and push this soon.
> ___
> 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”.

Hi Marth,

Thanks very much for your reply. I feel the warmth of the open-source 
community. I indeed did not notice this grammar issue, and I will be more 
careful next time.

It's hard to express my gratitude in words.🥹

Best regards,
Jack
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH v2] avfilter/scale*: add option reset_sar

[Gyan Doshi]

For anamorphic videos, enabling this option leads to adjustment of
output dimensions to obtain square pixels when the user requests
proportional scaling through either of the w/h expressions or
force_original_aspect_ratio.

Output SAR is always reset to 1.

Option added to scale, scale_cuda, scale_npp & scale_vaapi.

libplacebo already has a similar option with different semantics,
scale_vt and scale_vulkan don't implement force_oar, so for these
three filters, I've made minimal changes needed to not break building
or change output.
---
v2:
Rewrote doc option description
Added doc examples
w_adj init nit resolved

 doc/filters.texi  | 36 +--
 libavfilter/scale_eval.c  | 13 +++--
 libavfilter/scale_eval.h  |  5 -
 libavfilter/vf_libplacebo.c   |  2 +-
 libavfilter/vf_scale.c| 13 +++--
 libavfilter/vf_scale_cuda.c   | 25 ++--
 libavfilter/vf_scale_npp.c| 13 +++--
 libavfilter/vf_scale_vaapi.c  | 13 +++--
 libavfilter/vf_scale_vt.c |  2 +-
 libavfilter/vf_scale_vulkan.c |  2 +-
 10 files changed, 100 insertions(+), 24 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index a14c7e7e77..bf9a60712f 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -21285,6 +21285,14 @@ This option can be handy if you need to have a video 
fit within or exceed
 a defined resolution using @option{force_original_aspect_ratio} but also have
 encoder restrictions on width or height divisibility.
 
+@item reset_sar
+Enabling this option leads to the output SAR being reset to 1.
+Additionally, if the user requests proportional scaling either
+through the width or height expressions, e.g. @code{w=-4:h=360} or 
@code{w=iw/2:h=-1}
+or by enabling @code{force_original_aspect_ratio}, then the input DAR is taken 
into
+account and the output is scaled to produce square pixels.
+Default is false.
+
 @end table
 
 The values of the @option{w} and @option{h} options are expressions
@@ -21445,10 +21453,28 @@ scale='trunc(ih*dar):ih',setsar=1/1
 @end example
 
 @item
-Make pixels square by combining scale and setsar,
+Make pixels square using reset_sar,
 making sure the resulting resolution is even (required by some codecs):
 @example
-scale='trunc(ih*dar/2)*2:trunc(ih/2)*2',setsar=1/1
+scale='-2:ih-mod(ih,2):reset_sar=1'
+@end example
+
+@item
+Scale to target exactly, however reset SAR to 1:
+@example
+scale='400:300:reset_sar=1'
+@end example
+
+@item
+Scale to even dimensions that fit within 400x300, preserving input SAR:
+@example
+scale='400:300:force_original_aspect_ratio=decrease:force_divisible_by=2'
+@end example
+
+@item
+Scale to produce square pixels with even dimensions that fit within 400x300:
+@example
+scale='400:300:force_original_aspect_ratio=decrease:force_divisible_by=2:reset_sar=1'
 @end example
 
 @item
@@ -21538,6 +21564,9 @@ Affects the curves of the bicubic algorithm.
 @item force_divisible_by
 Work the same as the identical @ref{scale} filter options.
 
+@item reset_sar
+Works the same as the identical @ref{scale} filter option.
+
 @end table
 
 @subsection Examples
@@ -21641,6 +21670,9 @@ This option can be handy if you need to have a video 
fit within or exceed
 a defined resolution using @option{force_original_aspect_ratio} but also have
 encoder restrictions on width or height divisibility.
 
+@item reset_sar
+Works the same as the identical @ref{scale} filter option.
+
 @item eval
 Specify when to evaluate @var{width} and @var{height} expression. It accepts 
the following values:
 
diff --git a/libavfilter/scale_eval.c b/libavfilter/scale_eval.c
index dc8d522b1e..53f5e22b0e 100644
--- a/libavfilter/scale_eval.c
+++ b/libavfilter/scale_eval.c
@@ -112,7 +112,8 @@ fail:
 
 int ff_scale_adjust_dimensions(AVFilterLink *inlink,
 int *ret_w, int *ret_h,
-int force_original_aspect_ratio, int force_divisible_by)
+int force_original_aspect_ratio, int force_divisible_by,
+double w_adj)
 {
 int64_t w, h;
 int factor_w, factor_h;
@@ -132,7 +133,7 @@ int ff_scale_adjust_dimensions(AVFilterLink *inlink,
 }
 
 if (w < 0 && h < 0) {
-w = inlink->w;
+w = inlink->w * w_adj;
 h = inlink->h;
 }
 
@@ -140,18 +141,18 @@ int ff_scale_adjust_dimensions(AVFilterLink *inlink,
  * earlier. If no factor was set, nothing will happen as the default
  * factor is 1 */
 if (w < 0)
-w = av_rescale(h, inlink->w, inlink->h * factor_w) * factor_w;
+w = av_rescale(h, inlink->w * w_adj, inlink->h * factor_w) * factor_w;
 if (h < 0)
-h = av_rescale(w, inlink->h, inlink->w * factor_h) * factor_h;
+h = av_rescale(w, inlink->h, inlink->w * w_adj * factor_h) * factor_h;
 
 /* Note that force_original_aspect_ratio may overwrite the previous set
  * dimensions so that it is not divisible by the set factors anymore
  * unless force_divisible_by is defined as well */
 if (force_original_aspect_ratio)

Re: [FFmpeg-devel] Captions SCC

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Marth64
> Sent: Sunday, February 9, 2025 9:23 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
> 
> On Sun, Feb 9, 2025 at 2:14 PM Soft Works
>  wrote:
> > Numpad alignment 7, LeftMargin=x VertMargin=y
> 
> Yeah, that could work. I forgot about margins. I'll play around with
> it.

That's the elementary way to position ASS text. 
Years ago I had a chat with one the libass developers because I didn't want to 
believe it and thought there must be something else.. 😊

sw
___
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] Captions SCC

[Devlist Archive]

I believe I have sorted out the embed/extract issues I encountered into a
formatting issue with the .scc file and lack of eia-608 codec for embedding
captions.  It is possible this might be a result of an oversight regarding
drop frame or non drop frame time codes with some part of the chain that
handles extracted captions data.  Please discuss the best way to solve
these issues in the appropriate locations.  Once a solution is identified
let me know if I need to go find sponsorship funds to expedite generating
the appropriate patches.

https://trac.ffmpeg.org/ticket/11461

https://trac.ffmpeg.org/ticket/11462

On Sun, Feb 9, 2025 at 12:34 PM Soft Works <
softworkz-at-hotmail@ffmpeg.org> wrote:

>
>
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Marth64
> > Sent: Sunday, February 9, 2025 9:23 PM
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] Captions SCC
> >
> > On Sun, Feb 9, 2025 at 2:14 PM Soft Works
> >  wrote:
> > > Numpad alignment 7, LeftMargin=x VertMargin=y
> >
> > Yeah, that could work. I forgot about margins. I'll play around with
> > it.
>
> That's the elementary way to position ASS text.
> Years ago I had a chat with one the libass developers because I didn't
> want to believe it and thought there must be something else.. 😊
>
> sw
> ___
> 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".

[FFmpeg-devel] [PATCH v5 2/3] avcodec/hevc/ps: Add basic HEVC_SCALABILITY_AUXILIARY support

[Zhao Zhili]

From: Zhao Zhili 

Only implementing what's needed for HEVC with alpha.

Signed-off-by: Zhao Zhili 
---
 libavcodec/hevc/hevc.h |   5 ++
 libavcodec/hevc/ps.c   | 125 +
 libavcodec/hevc/ps.h   |   1 +
 3 files changed, 95 insertions(+), 36 deletions(-)

diff --git a/libavcodec/hevc/hevc.h b/libavcodec/hevc/hevc.h
index b2229fda40..710786a89d 100644
--- a/libavcodec/hevc/hevc.h
+++ b/libavcodec/hevc/hevc.h
@@ -170,4 +170,9 @@ enum HEVCScalabilityMask {
 HEVC_SCALABILITY_MASK_MAX   = 0x,
 };
 
+enum HEVCAuxId {
+HEVC_AUX_ALPHA = 1,
+HEVC_AUX_DEPTH = 2,
+};
+
 #endif /* AVCODEC_HEVC_HEVC_H */
diff --git a/libavcodec/hevc/ps.c b/libavcodec/hevc/ps.c
index 861a6bb0a2..24f4218931 100644
--- a/libavcodec/hevc/ps.c
+++ b/libavcodec/hevc/ps.c
@@ -460,14 +460,17 @@ static int decode_vps_ext(GetBitContext *gb, 
AVCodecContext *avctx, HEVCVPS *vps
   uint64_t layer1_id_included)
 {
 PTL ptl_dummy;
-uint8_t max_sub_layers[HEVC_MAX_LAYERS];
+uint8_t max_sub_layers[HEVC_MAX_LAYERS] = {1, 1};
+uint8_t dimension_id_len[16] = {0};
+uint8_t dimension_id[16] = {0};
+unsigned n;
 
-int splitting_flag, dimension_id_len, view_id_len, num_add_olss, 
num_scalability_types,
+int splitting_flag, view_id_len, num_add_olss, num_scalability_types,
 default_output_layer_idc, direct_dep_type_len, direct_dep_type,
 sub_layers_max_present, sub_layer_flag_info_present_flag, nb_ptl;
 unsigned non_vui_extension_length;
 
-if (vps->vps_max_layers == 1 || vps->vps_num_layer_sets == 1) {
+if (vps->vps_max_layers == 1) {
 av_log(avctx, AV_LOG_VERBOSE, "Ignoring VPS extensions with a single 
layer\n");
 return 0;
 }
@@ -520,6 +523,7 @@ static int decode_vps_ext(GetBitContext *gb, AVCodecContext 
*avctx, HEVCVPS *vps
  */
 vps->nb_layers = 2;
 
+/* vps_base_layer_internal_flag is true has been checked before */
 if (parse_ptl(gb, avctx, 0, &ptl_dummy, vps->vps_max_sub_layers) < 0)
 return AVERROR_INVALIDDATA;
 
@@ -529,20 +533,25 @@ static int decode_vps_ext(GetBitContext *gb, 
AVCodecContext *avctx, HEVCVPS *vps
 if (!num_scalability_types) {
 av_log(avctx, AV_LOG_ERROR, "Missing scalability mask\n");
 return AVERROR_INVALIDDATA;
-} else if (num_scalability_types > 1) {
-av_log(avctx, AV_LOG_ERROR, "Scalability number %d not supported\n",
-   num_scalability_types);
-return AVERROR_PATCHWELCOME;
 }
 
-if (!(vps->scalability_mask_flag & HEVC_SCALABILITY_MULTIVIEW)) {
+if (!(vps->scalability_mask_flag &
+  (HEVC_SCALABILITY_MULTIVIEW | HEVC_SCALABILITY_AUXILIARY))) {
 av_log(avctx, AV_LOG_ERROR, "Scalability type %d not supported\n",
15 - ff_ctz(vps->scalability_mask_flag));
 return AVERROR_PATCHWELCOME;
 }
+// x265 specify MULTIVIEW when the stream really is alpha video only.
+if (num_scalability_types > 1)
+av_log(avctx, AV_LOG_WARNING, "Multiple scalability types 
presented\n");
 
-if (!splitting_flag)
-dimension_id_len = get_bits(gb, 3) + 1;
+n = 0;
+for (int i = 0; i < num_scalability_types - splitting_flag; i++) {
+dimension_id_len[i] = get_bits(gb, 3) + 1;
+n += dimension_id_len[i];
+}
+if (splitting_flag)
+dimension_id_len[num_scalability_types - 1] = 5 - n;
 
 if (get_bits1(gb)) { /* vps_nuh_layer_id_present_flag */
 int layer_id_in_nuh = get_bits(gb, 6);
@@ -559,28 +568,57 @@ static int decode_vps_ext(GetBitContext *gb, 
AVCodecContext *avctx, HEVCVPS *vps
 }
 
 if (!splitting_flag) {
-int view_idx = get_bits(gb, dimension_id_len);
-if (view_idx != 1) {
-av_log(avctx, AV_LOG_ERROR, "Unexpected ViewOrderIdx: %d\n", 
view_idx);
+int index = 0;
+
+for (int i = 0; i < num_scalability_types; i++)
+dimension_id[i] = get_bits(gb, dimension_id_len[i]);
+
+if (vps->scalability_mask_flag & HEVC_SCALABILITY_MULTIVIEW)
+index++;
+
+/* AuxId 1 is alpha, 2 is depth. Only support alpha */
+if (vps->scalability_mask_flag & HEVC_SCALABILITY_AUXILIARY &&
+dimension_id[index] != HEVC_AUX_ALPHA) {
+av_log(avctx, AV_LOG_WARNING,
+   "Unsupported dimension_id %d for 
HEVC_SCALABILITY_AUXILIARY\n",
+   dimension_id[index]);
 return AVERROR_PATCHWELCOME;
 }
 }
 
 view_id_len = get_bits(gb, 4);
-if (view_id_len)
-for (int i = 0; i < 2 /* NumViews */; i++)
+if (view_id_len) {
+n = (vps->scalability_mask_flag & HEVC_SCALABILITY_MULTIVIEW) ? 2 : 1;
+for (int i = 0; i < n; i++)
 vps->view_id[i] = get_bits(gb, view_id_len);
+}
 
-if (!get_bits1(gb) /* direct_dependency_flag */) {
-av_log(avctx, AV_LOG_WARNING, "Independent output layers not 
supported\n");
-   

[FFmpeg-devel] [PATCH v5 3/3] avcodec/hevc: Add alpha layer support

[Zhao Zhili]

From: Zhao Zhili 

Signed-off-by: Zhao Zhili 
---
 libavcodec/hevc/hevcdec.c | 72 ++-
 libavcodec/hevc/hevcdec.h |  2 ++
 libavcodec/hevc/refs.c| 11 +-
 3 files changed, 83 insertions(+), 2 deletions(-)

diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index e9c045f7a1..1cdc28de50 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@ -466,6 +466,24 @@ static int export_multilayer(HEVCContext *s, const HEVCVPS 
*vps)
 return 0;
 }
 
+int ff_hevc_is_alpha_video(const HEVCContext *s) {
+const HEVCVPS *vps = s->vps;
+int ret = 0;
+
+if (vps->nb_layers != 2 || !vps->layer_id_in_nuh[1])
+return 0;
+
+/* decode_vps_ext() guarantees that SCALABILITY_AUXILIARY with AuxId other
+ * than alpha cannot reach here.
+ */
+ret = (s->vps->scalability_mask_flag & HEVC_SCALABILITY_AUXILIARY);
+
+av_log(s->avctx, AV_LOG_DEBUG, "Multi layer video, %s alpha video\n",
+   ret ? "is" : "not");
+
+return ret;
+}
+
 static int setup_multilayer(HEVCContext *s, const HEVCVPS *vps)
 {
 unsigned layers_active_output = 0, highest_layer;
@@ -473,6 +491,18 @@ static int setup_multilayer(HEVCContext *s, const HEVCVPS 
*vps)
 s->layers_active_output = 1;
 s->layers_active_decode = 1;
 
+if (ff_hevc_is_alpha_video(s)) {
+const AVPixFmtDescriptor *desc = 
av_pix_fmt_desc_get(s->avctx->pix_fmt);
+
+if (!(desc->flags & AV_PIX_FMT_FLAG_ALPHA))
+return 0;
+
+s->layers_active_decode = (1 << vps->nb_layers) - 1;
+s->layers_active_output = 1;
+
+return 0;
+}
+
 // nothing requested - decode base layer only
 if (!s->nb_view_ids)
 return 0;
@@ -530,6 +560,34 @@ static int setup_multilayer(HEVCContext *s, const HEVCVPS 
*vps)
 return 0;
 }
 
+static enum AVPixelFormat map_to_alpha_format(HEVCContext *s,
+  enum AVPixelFormat pix_fmt)
+{
+switch (pix_fmt) {
+case AV_PIX_FMT_YUV420P:
+case AV_PIX_FMT_YUVJ420P:
+return AV_PIX_FMT_YUVA420P;
+case AV_PIX_FMT_YUV420P10:
+return AV_PIX_FMT_YUVA420P10;
+case AV_PIX_FMT_YUV444P:
+return AV_PIX_FMT_YUVA444P;
+case AV_PIX_FMT_YUV422P:
+return AV_PIX_FMT_YUVA422P;
+case AV_PIX_FMT_YUV422P10LE:
+return AV_PIX_FMT_YUVA422P10LE;
+case AV_PIX_FMT_YUV444P10:
+return AV_PIX_FMT_YUVA444P10;
+case AV_PIX_FMT_YUV444P12:
+return AV_PIX_FMT_YUVA444P12;
+case AV_PIX_FMT_YUV422P12:
+return AV_PIX_FMT_YUVA422P12;
+default:
+av_log(s->avctx, AV_LOG_WARNING, "No alpha pixel format map for %s\n",
+   av_get_pix_fmt_name(pix_fmt));
+return AV_PIX_FMT_NONE;
+}
+}
+
 static enum AVPixelFormat get_format(HEVCContext *s, const HEVCSPS *sps)
 {
 #define HWACCEL_MAX (CONFIG_HEVC_DXVA2_HWACCEL + \
@@ -540,9 +598,13 @@ static enum AVPixelFormat get_format(HEVCContext *s, const 
HEVCSPS *sps)
  CONFIG_HEVC_VIDEOTOOLBOX_HWACCEL + \
  CONFIG_HEVC_VDPAU_HWACCEL + \
  CONFIG_HEVC_VULKAN_HWACCEL)
-enum AVPixelFormat pix_fmts[HWACCEL_MAX + 2], *fmt = pix_fmts;
+enum AVPixelFormat pix_fmts[HWACCEL_MAX + 3], *fmt = pix_fmts;
+enum AVPixelFormat alpha_fmt = AV_PIX_FMT_NONE;
 int ret;
 
+if (ff_hevc_is_alpha_video(s))
+alpha_fmt = map_to_alpha_format(s, sps->pix_fmt);
+
 switch (sps->pix_fmt) {
 case AV_PIX_FMT_YUV420P:
 case AV_PIX_FMT_YUVJ420P:
@@ -664,6 +726,8 @@ static enum AVPixelFormat get_format(HEVCContext *s, const 
HEVCSPS *sps)
 break;
 }
 
+if (alpha_fmt != AV_PIX_FMT_NONE)
+*fmt++ = alpha_fmt;
 *fmt++ = sps->pix_fmt;
 *fmt = AV_PIX_FMT_NONE;
 
@@ -3194,6 +3258,12 @@ static int hevc_frame_start(HEVCContext *s, 
HEVCLayerContext *l,
 !sps->vui.common.video_signal_type_present_flag)
 pix_fmt = sps_base->pix_fmt;
 
+// Ignore range mismatch between base layer and alpha layer
+if (ff_hevc_is_alpha_video(s) &&
+sps_base->pix_fmt == AV_PIX_FMT_YUV420P &&
+pix_fmt == AV_PIX_FMT_YUVJ420P)
+pix_fmt = sps_base->pix_fmt;
+
 if (pix_fmt != sps_base->pix_fmt ||
 sps->width  != sps_base->width   ||
 sps->height != sps_base->height) {
diff --git a/libavcodec/hevc/hevcdec.h b/libavcodec/hevc/hevcdec.h
index 4e95035688..b2b725b5cd 100644
--- a/libavcodec/hevc/hevcdec.h
+++ b/libavcodec/hevc/hevcdec.h
@@ -714,6 +714,8 @@ void ff_hevc_hls_residual_coding(HEVCLocalContext *lc, 
const HEVCPPS *pps,
 
 void ff_hevc_hls_mvd_coding(HEVCLocalContext *lc, int x0, int y0, int 
log2_cb_size);
 
+int ff_hevc_is_alpha_video(const HEVCContext *s);
+
 extern const uint8_t ff_hevc_qpel_extra_before[4];
 extern const uint8_t ff_hevc_qpel_extra_after[4];
 extern const uint8_t ff_hevc_qpel

[FFmpeg-devel] [PATCH v5 1/3] avcodec/hevc: Rewrite scalability_mask_flag parse in decode_vps_ext

[Zhao Zhili]

From: Zhao Zhili 

Remove a for loop and make it easy to extend to support other types
of scalability. Move ScalabilityMask to hevc header file so it can
be used in hevc decoder.

Signed-off-by: Zhao Zhili 
---
 libavcodec/hevc/hevc.h |  7 +++
 libavcodec/hevc/ps.c   | 33 +++--
 libavcodec/hevc/ps.h   |  2 ++
 3 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/libavcodec/hevc/hevc.h b/libavcodec/hevc/hevc.h
index 8bd59142db..b2229fda40 100644
--- a/libavcodec/hevc/hevc.h
+++ b/libavcodec/hevc/hevc.h
@@ -162,5 +162,12 @@ enum {
 HEVC_MAX_PALETTE_PREDICTOR_SIZE = 128,
 };
 
+enum HEVCScalabilityMask {
+HEVC_SCALABILITY_DEPTH  = 1 << (15 - 0),
+HEVC_SCALABILITY_MULTIVIEW  = 1 << (15 - 1),
+HEVC_SCALABILITY_SPATIAL= 1 << (15 - 2),
+HEVC_SCALABILITY_AUXILIARY  = 1 << (15 - 3),
+HEVC_SCALABILITY_MASK_MAX   = 0x,
+};
 
 #endif /* AVCODEC_HEVC_HEVC_H */
diff --git a/libavcodec/hevc/ps.c b/libavcodec/hevc/ps.c
index 285084685b..861a6bb0a2 100644
--- a/libavcodec/hevc/ps.c
+++ b/libavcodec/hevc/ps.c
@@ -450,14 +450,6 @@ static void hevc_vps_free(AVRefStructOpaque opaque, void 
*obj)
 av_freep(&vps->data);
 }
 
-enum ScalabilityMask {
-HEVC_SCALABILITY_DEPTH  = 0,
-HEVC_SCALABILITY_MULTIVIEW  = 1,
-HEVC_SCALABILITY_SPATIAL= 2,
-HEVC_SCALABILITY_AUXILIARY  = 3,
-HEVC_SCALABILITY_MASK_MAX   = 15,
-};
-
 enum DependencyType {
 HEVC_DEP_TYPE_SAMPLE = 0,
 HEVC_DEP_TYPE_MV = 1,
@@ -532,17 +524,22 @@ static int decode_vps_ext(GetBitContext *gb, 
AVCodecContext *avctx, HEVCVPS *vps
 return AVERROR_INVALIDDATA;
 
 splitting_flag = get_bits1(gb);
-num_scalability_types = 0;
-for (int i = 0; i <= HEVC_SCALABILITY_MASK_MAX; i++) {
-int scalability_mask_flag = get_bits1(gb);
-if (scalability_mask_flag && (i != HEVC_SCALABILITY_MULTIVIEW)) {
-av_log(avctx, AV_LOG_ERROR, "Scalability type %d not supported\n", 
i);
-return AVERROR_PATCHWELCOME;
-}
-num_scalability_types += scalability_mask_flag;
-}
-if (num_scalability_types != 1)
+vps->scalability_mask_flag = get_bits(gb, 16);
+num_scalability_types = av_popcount(vps->scalability_mask_flag);
+if (!num_scalability_types) {
+av_log(avctx, AV_LOG_ERROR, "Missing scalability mask\n");
 return AVERROR_INVALIDDATA;
+} else if (num_scalability_types > 1) {
+av_log(avctx, AV_LOG_ERROR, "Scalability number %d not supported\n",
+   num_scalability_types);
+return AVERROR_PATCHWELCOME;
+}
+
+if (!(vps->scalability_mask_flag & HEVC_SCALABILITY_MULTIVIEW)) {
+av_log(avctx, AV_LOG_ERROR, "Scalability type %d not supported\n",
+   15 - ff_ctz(vps->scalability_mask_flag));
+return AVERROR_PATCHWELCOME;
+}
 
 if (!splitting_flag)
 dimension_id_len = get_bits(gb, 3) + 1;
diff --git a/libavcodec/hevc/ps.h b/libavcodec/hevc/ps.h
index 6f5b1f8755..d3465e3d27 100644
--- a/libavcodec/hevc/ps.h
+++ b/libavcodec/hevc/ps.h
@@ -205,6 +205,8 @@ typedef struct HEVCVPS {
  */
 int nb_layers;
 
+uint16_t scalability_mask_flag;
+
 // LayerIdxInVps[nuh_layer_id], i.e. a mapping of nuh_layer_id to VPS layer
 // indices. Valid values are between 0 and HEVC_VPS_MAX_LAYERS. Entries for
 // unmapped values of nuh_layer_id are set to -1.
-- 
2.46.0

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

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

Re: [FFmpeg-devel] [PATCH v2 2/2] random_seed: Improve behaviour with small timer increments with high precision timers

[Michael Niedermayer]

Hi Martin

On Fri, Feb 07, 2025 at 12:04:53AM +0200, Martin Storsjö wrote:
> On Thu, 6 Feb 2025, Michael Niedermayer wrote:
> 
> > On Thu, Feb 06, 2025 at 02:38:48PM +0200, Martin Storsjö wrote:
> > > On Thu, 6 Feb 2025, Michael Niedermayer wrote:
> > > 
> > > > > +// If the timer resolution is high, and we get the same 
> > > > > timer
> > > > > +// value multiple times, use variances in the number of 
> > > > > repeats
> > > > > +// of each timer value as entropy. If the number of 
> > > > > repeats changed,
> > > > > +// proceed to the next index.
> > > > 
> > > > Does it still work if you check against the last 2 ?
> > > > or does this become too slow ?
> > > > What iam thinking of is this
> > > > 
> > > > 7,8,7,8,8,7,8,7,8,8,7,8,7,8,8,7,8,7,8,8,... and a 9 or 6 or further 
> > > > distant would trigger it
> > > > 
> > > > I assume both the CPU clock and the wall time are quite precisse so if 
> > > > we
> > > > just compare them the entropy could be low even with 2 alternating 
> > > > values
> > > 
> > > Yes, that still works for making it terminate in a reasonable amount of
> > > time. I updated the patch to keep track of 3 numbers of repeats, and we
> > > consider that we got valid entropy once the new number of repeats is
> > > different from the last two.
> > > 
> > > So in the sequence above, e.g. for 7,8,7,8,8,7, at the point of the last
> > > one, we have old repeats 8 and 8, and the new repeat count 7, which in 
> > > that
> > > context looks unique.
> > 
> > I was thinking that in 7,8,8 that 7 and 8 be the 2 least recent used
> > values not 8,8
> 
> Sure, that's probably doable too.
> 
> > that is, something like:
> > 
> > if (old2 == new) {
> >FFSWAP(old,old2);
> 
> I don't see why we'd need to check this if clause at all, it seems to me
> that it's enough to have the "if (old != new)" case.

> If we have old2 == new,
> we'd just end up with old2 = old, and old = (previous old2 value) anyway.

It was intended to be a least recent used check with 2 entries

If we have a clock running and sample that in precise intervalls
lets say the clock runs at 1.9hz and we sample at 10hz we would get

clock:0  0  0  0  0  0  1  1  1  1  1  2  2  2  2  2  3  3  3  3  3  3  4  
4  4  4  4  5  5  5  5  5  6  6  6  6  6  7  7  7  7  7  7  8  8  8  8  8  9  9
difference:  0  0  0  0  0  1  0  0  0  0  1  0  0  0  0  1  0  0  0  0  0  1  
0  0  0  0  1  0  0  0  0  1  0  0  0  0  1  0  0  0  0  0  1  0  0  0  0  1  0

Above adds no entropy after the initial entropy, this can be read forever
it will not improve randomness

here we have runs of repeated clock reads of 5,4,4,5,4,4,4,5,4
again we can read this as long as we want there is no entropy gained
so after a 5,4,4,4 if a 5 happens thats not breaking the pattern and should
not be counted as new entropy (if possible)

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/2] libavcodec: add AV_CODEC_ID_IVTV_VBI

[Marth64]

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

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

Re: [FFmpeg-devel] [PATCH] avformat/dvdvideodec: fix seeking on multi-angle discs

[Marth64]

Will push soon
___
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] aacenc: move to libavcodec/aac/

[Michael Niedermayer]

Hi Lynne

On Sat, Feb 08, 2025 at 06:32:12AM +0100, Lynne wrote:
[...]
> index 70b1dca274..489fa9f67a 100644
> --- a/libavcodec/aac/Makefile
> +++ b/libavcodec/aac/Makefile
> @@ -1,6 +1,8 @@
>  clean::
>   $(RM) $(CLEANSUFFIXES:%=libavcodec/aac/%)
>  
> +OBJS-$(CONFIG_AAC_ENCODER)  +=  aacenc.o aaccoder.o aacenctab.o \
> +aacenc_is.o aacenc_tns.o
>  OBJS-$(CONFIG_AAC_DECODER)  +=  aac/aacdec.o aac/aacdec_tab.o \
>  aac/aacdec_float.o aac/aacdec_usac.o 
> \
>  aac/aacdec_ac.o aac/aacdec_lpd.o

The pathes for the aac encoder look wrong, i think they need a aac/
like the aac decoder

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What is kyc? Its a tool that makes you give out your real ID, while criminals
give out a forged ID card.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Captions SCC

[Marth64]

On Sun, Feb 9, 2025 at 2:14 PM Soft Works
 wrote:
> Numpad alignment 7, LeftMargin=x VertMargin=y

Yeah, that could work. I forgot about margins. I'll play around with it.

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

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

Re: [FFmpeg-devel] [PATCH] avformat/hls: fix typo There is an extra space in the original comment

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Jack Lau
> Sent: Monday, February 10, 2025 2:13 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] avformat/hls: fix typo There is
> an extra space in the original comment
> 
> > On Feb 10, 2025, at 08:54, Soft Works  hotmail@ffmpeg.org> wrote:
> >
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel  > On Behalf Of
> >> Jack Lau via ffmpeg-devel
> >> Sent: Monday, February 10, 2025 1:34 AM
> >> To: ffmpeg-devel@ffmpeg.org 
> >> Cc: Jack Lau mailto:jacklau1...@qq.com>>
> >> Subject: [FFmpeg-devel] [PATCH] avformat/hls: fix typo There is an
> >> extra space in the original comment
> >>
> >> ---
> >> libavformat/hls.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavformat/hls.c b/libavformat/hls.c
> >> index 3bdc1bc848..c2130bb883 100644
> >> --- a/libavformat/hls.c
> >> +++ b/libavformat/hls.c
> >> @@ -1993,7 +1993,7 @@ static int hls_read_header(AVFormatContext
> *s)
> >> return ret;
> >>
> >> /* XXX: Some HLS servers don't like being sent the range
> header,
> >> -   in this case, need to  setting http_seekable = 0 to
> disable
> >> +   in this case, need to setting http_seekable = 0 to disable
> >>the range header */
> >> av_dict_set_int(&c->avio_opts, "seekable", c->http_seekable,
> 0);
> >>
> >> --
> >> 2.48.1
> >
> > Hi Jack,
> >
> > you're not working on a proof of concept regarding the
> vulnerability of the GA, right?
> > (just kidding)
> >
> > As an idea, you might be able to give that patch a little bit more
> meaning by also fixing the grammar.
> >
> > Best wishes
> > sw
> > ___


> 
> Hi,
> 
> Thanks for your reply.
> 
> I'm trying to fix some issues with hls. I happened to see this typo.
> Since I saw in the ffmpeg documentation that cosmetic changes should
> be kept in separate patches, so i submitted it first.
> 
> Thank you for your advice, I will try my best to submit more
> important patches.
> 
> Best wishes
> Jack

Hi,

please do not top-post (ask AI if you don't know what it is). It's a rule here, 
probably because in those plaintext messages without formatting it's hard to 
follow when some are replying at the top and some at the bottom.

Cosmetic changes should be in a separate commit but they can be in the same 
patchset.

Personally, I don't think it's unimportant to fix whitespace, spelling and 
formatting issues. There's value in everything that improves the code, but you 
also need to consider efficiency and think about the time that gets bound for 
others dealing with a single-char non-functional change. 
If I would make such commit(s), then I would go through a large number of code 
files (like all from a lib) looking for similar issues and include all of them 
in my patch, so that a reviewer/maintainer sees that I have really spent effort 
on it, and they feel that the given value is worth their time.

Best
sw



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

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

Re: [FFmpeg-devel] [PATCH] avformat/hls: fix typo There is an extra space in the original comment

[Jack Lau]

> On Feb 10, 2025, at 09:36, Soft Works  
> wrote:
> 
> 
> 
>> -Original Message-
>> From: ffmpeg-devel > > On Behalf Of
>> Jack Lau
>> Sent: Monday, February 10, 2025 2:13 AM
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org >
>> Subject: Re: [FFmpeg-devel] [PATCH] avformat/hls: fix typo There is
>> an extra space in the original comment
>> 
>>> On Feb 10, 2025, at 08:54, Soft Works > hotmail@ffmpeg.org > wrote:
>>> 
>>> 
>>> 
 -Original Message-
 From: ffmpeg-devel >>> 
>> > On Behalf Of
 Jack Lau via ffmpeg-devel
 Sent: Monday, February 10, 2025 1:34 AM
 To: ffmpeg-devel@ffmpeg.org  
 
 Cc: Jack Lau mailto:jacklau1...@qq.com> 
 >
 Subject: [FFmpeg-devel] [PATCH] avformat/hls: fix typo There is an
 extra space in the original comment
 
 ---
 libavformat/hls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/libavformat/hls.c b/libavformat/hls.c
 index 3bdc1bc848..c2130bb883 100644
 --- a/libavformat/hls.c
 +++ b/libavformat/hls.c
 @@ -1993,7 +1993,7 @@ static int hls_read_header(AVFormatContext
>> *s)
return ret;
 
/* XXX: Some HLS servers don't like being sent the range
>> header,
 -   in this case, need to  setting http_seekable = 0 to
>> disable
 +   in this case, need to setting http_seekable = 0 to disable
   the range header */
av_dict_set_int(&c->avio_opts, "seekable", c->http_seekable,
>> 0);
 
 --
 2.48.1
>>> 
>>> Hi Jack,
>>> 
>>> you're not working on a proof of concept regarding the
>> vulnerability of the GA, right?
>>> (just kidding)
>>> 
>>> As an idea, you might be able to give that patch a little bit more
>> meaning by also fixing the grammar.
>>> 
>>> Best wishes
>>> sw
>>> ___
> 
> 
>> 
>> Hi,
>> 
>> Thanks for your reply.
>> 
>> I'm trying to fix some issues with hls. I happened to see this typo.
>> Since I saw in the ffmpeg documentation that cosmetic changes should
>> be kept in separate patches, so i submitted it first.
>> 
>> Thank you for your advice, I will try my best to submit more
>> important patches.
>> 
>> Best wishes
>> Jack
> 
> Hi,
> 
> please do not top-post (ask AI if you don't know what it is). It's a rule 
> here, probably because in those plaintext messages without formatting it's 
> hard to follow when some are replying at the top and some at the bottom.
> 
> Cosmetic changes should be in a separate commit but they can be in the same 
> patchset.
> 
> Personally, I don't think it's unimportant to fix whitespace, spelling and 
> formatting issues. There's value in everything that improves the code, but 
> you also need to consider efficiency and think about the time that gets bound 
> for others dealing with a single-char non-functional change. 
> If I would make such commit(s), then I would go through a large number of 
> code files (like all from a lib) looking for similar issues and include all 
> of them in my patch, so that a reviewer/maintainer sees that I have really 
> spent effort on it, and they feel that the given value is worth their time.
> 
> Best
> sw
> 
> 
> 
> ___
> 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”.


Hi,

Thank you very much for taking the time to point out my mistakes and for 
sharing your perspective—I completely agree.

I will make sure not to encounter these issues again in the future.

Thanks again!

Jack


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

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

[FFmpeg-devel] [PATCH] tools: Add binaries to .gitignore

[Frank Plowman]

Signed-off-by: Frank Plowman 
---
 tools/.gitignore | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/tools/.gitignore b/tools/.gitignore
index 7c45896923..f017fa2343 100644
--- a/tools/.gitignore
+++ b/tools/.gitignore
@@ -3,6 +3,7 @@
 /bisect.need
 /crypto_bench
 /cws2fws
+/enc_recon_frame_test
 /enum_options
 /fourcc2pixfmt
 /ffescape
@@ -15,6 +16,15 @@
 /qt-faststart
 /scale_slice_test
 /sidxindex
+/sofa2wavs
+/target_dec_*_fuzzer
+/target_enc_*_fuzzer
+/target_bsf_*_fuzzer
+/target_dem_*_fuzzer
+/target_dem_fuzzer
+/target_io_dem_fuzzer
+/target_sws_fuzzer
+/target_swr_fuzzer
 /trasher
 /seek_print
 /uncoded_frame
-- 
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".

Re: [FFmpeg-devel] Captions SCC

[Devin Heitmueller]

On Sat, Feb 8, 2025 at 10:39 PM Tom Vaughan  wrote:
>
> I'm excited to see this discussion. There are many leading video distributors 
> (streaming services, etc.) that would love to see solid support in FFMPEG for 
> closed captions. No promises, but my sense is that additional money can be 
> raised to sponsor this development.
>
> WebVTT as a sidecar captions file is the modern way to handle captions. The 
> latest streaming client devices / applications support WebVTT captions. New 
> movies and TV shows are produced with WebVTT captions.

Not to start an argument, but WebVTT is kind of a terrible format.
It's a lowest common denominator and loses most formatting information
available even in 608 (which is now more than 40 years old).  Stuff
like rollup captions for live programming, color (to distinguish
speakers) and caption positioning are pretty important to the hearing
impaired.

Yesterday I watched a DVD I ripped (purely for personal use) of a TV
show with VTT captions for something that I knew what the original 608
looked like, and wow what a difference (the WebVTT looked dramatically
worse than the original 608).

To my point: no, I don't think normalizing everything down to WebVTT
is a good idea.

Much of the goal, at least in the work that I do, is to conform to the
FCC requirements, which generally require that the original 608/708
from the content provider be preserved.

There can be money to support such efforts.  Most of my work in
captioning within ffmpeg was funded by my employer, and most of the
work I did improving 608 captions in VLC was financed by contract work
I did for commercial customers who were embedding VLC into solutions
and needed decent caption support.

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmuel...@ltnglobal.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 2/2] lavc/vvc: Ensure subpictures don't overlap

[Frank Plowman]

This is essentially a re-implementation of
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20241005223955.54158-1-p...@frankplowman.com/

That patch was not applied last time.  Instead we opted to identify
issues which could be caused by invalid subpicture layouts and remedy
those issues where they manifest, either through error detection or code
hardening.  This was primarily implemented in the set
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=13381.

This has worked to some degree, however issues with subpicture layouts
continue to crop up from the fuzzer and I've fixed a number of bugs
related to subpicture layouts since then.  I think it's best to return
to the initial plan and simply check if the subpicture layout is valid
initially.

This implementation is also lighter than the first time -- by doing a
bit more logic in pps_subpic_less_than_one_tile_slice, we are able to
store a tile_in_subpic map rather than a ctu_in_subpic map.  This
reduces the size of the map to the point it becomes possible to allocate
it on the stack.  Similar to 8bd66a8c9587af61c7b46558be3c4ee317c1af5a,
the layout is also validated in the slice map construction code, rather
than in the CBS, which avoids duplicating some logic.

Signed-off-by: Frank Plowman 
---
 libavcodec/vvc/ps.c | 52 -
 1 file changed, 42 insertions(+), 10 deletions(-)

diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index 9480540e03..9af5e1250b 100644
--- a/libavcodec/vvc/ps.c
+++ b/libavcodec/vvc/ps.c
@@ -401,25 +401,47 @@ static void subpic_tiles(int *tile_x, int *tile_y, int 
*tile_x_end, int *tile_y_
 (*tile_y_end)++;
 }
 
-static void pps_subpic_less_than_one_tile_slice(VVCPPS *pps, const VVCSPS 
*sps, const int i, const int tx, const int ty, int *off)
+static int pps_subpic_less_than_one_tile_slice(VVCPPS *pps, const VVCSPS *sps, 
const int i, const int tx, const int ty, int *off, bool *tile_in_subpic)
 {
+const int subpic_right = sps->r->sps_subpic_ctu_top_left_x[i] + 
sps->r->sps_subpic_width_minus1[i];
+const int subpic_bottom = sps->r->sps_subpic_ctu_top_left_y[i] + 
sps->r->sps_subpic_height_minus1[i];
+const int tile_right = pps->col_bd[tx] + pps->r->col_width_val[tx] - 1;
+const int tile_bottom = pps->row_bd[ty] + pps->r->row_height_val[ty] - 1;
+const bool is_final_subpic_in_tile = subpic_right == tile_right && 
subpic_bottom == tile_bottom;
+
+if (is_final_subpic_in_tile) {
+const size_t tile_idx = ty * VVC_MAX_TILE_COLUMNS + tx;
+if (tile_in_subpic[tile_idx])
+return AVERROR_INVALIDDATA;
+tile_in_subpic[tile_idx] = true;
+}
+
 pps->num_ctus_in_slice[i] = pps_add_ctus(pps, off,
 sps->r->sps_subpic_ctu_top_left_x[i], 
sps->r->sps_subpic_ctu_top_left_y[i],
 sps->r->sps_subpic_width_minus1[i] + 1, 
sps->r->sps_subpic_height_minus1[i] + 1);
+
+return 0;
 }
 
-static void pps_subpic_one_or_more_tiles_slice(VVCPPS *pps, const int tile_x, 
const int tile_y, const int x_end, const int y_end, const int i, int *off)
+static int pps_subpic_one_or_more_tiles_slice(VVCPPS *pps, const int tile_x, 
const int tile_y, const int x_end, const int y_end,
+const int i, int *off, bool *tile_in_subpic)
 {
 for (int ty = tile_y; ty < y_end; ty++) {
 for (int tx = tile_x; tx < x_end; tx++) {
+const size_t tile_idx = ty * VVC_MAX_TILE_COLUMNS + tx;
+if (tile_in_subpic[tile_idx])
+return AVERROR_INVALIDDATA;
+tile_in_subpic[tile_idx] = true;
+
 pps->num_ctus_in_slice[i] += pps_add_ctus(pps, off,
 pps->col_bd[tx], pps->row_bd[ty],
 pps->r->col_width_val[tx], pps->r->row_height_val[ty]);
 }
 }
+return 0;
 }
 
-static void pps_subpic_slice(VVCPPS *pps, const VVCSPS *sps, const int i, int 
*off)
+static int pps_subpic_slice(VVCPPS *pps, const VVCSPS *sps, const int i, int 
*off, bool *tile_in_subpic)
 {
 int tx, ty, x_end, y_end;
 
@@ -428,19 +450,30 @@ static void pps_subpic_slice(VVCPPS *pps, const VVCSPS 
*sps, const int i, int *o
 
 subpic_tiles(&tx, &ty, &x_end, &y_end, sps, pps, i);
 if (ty + 1 == y_end && sps->r->sps_subpic_height_minus1[i] + 1 < 
pps->r->row_height_val[ty])
-pps_subpic_less_than_one_tile_slice(pps, sps, i, tx, ty, off);
+return pps_subpic_less_than_one_tile_slice(pps, sps, i, tx, ty, off, 
tile_in_subpic);
 else
-pps_subpic_one_or_more_tiles_slice(pps, tx, ty, x_end, y_end, i, off);
+return pps_subpic_one_or_more_tiles_slice(pps, tx, ty, x_end, y_end, 
i, off, tile_in_subpic);
 }
 
-static void pps_single_slice_per_subpic(VVCPPS *pps, const VVCSPS *sps, int 
*off)
+static int pps_single_slice_per_subpic(VVCPPS *pps, const VVCSPS *sps, int 
*off)
 {
 if (!sps->r->sps_subpic_info_present_flag) {
 pps_single_slice_picture(pps, off);
 } else {
-for (int i = 0; i < pps->r->pps_num_slices_in_pic_minu

[FFmpeg-devel] [PATCH 1/2] lavc/vvc: Fix slice map construction for small subpics

[Frank Plowman]

In the case pps_subpic_less_than_one_tile_slice is called, the
subpicture is smaller than the tile and so there are multiple
subpictures in the tile.  Of course, then, not all the
subpictures can start in the top-left corner as the code before the
patch does.  Patch fixes this, so each subpicture starts at the
signalled location as is specified in section 6.5.1 of H.266(V3).

Signed-off-by: Frank Plowman 
---
 libavcodec/vvc/ps.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index fae6655cc0..9480540e03 100644
--- a/libavcodec/vvc/ps.c
+++ b/libavcodec/vvc/ps.c
@@ -404,8 +404,8 @@ static void subpic_tiles(int *tile_x, int *tile_y, int 
*tile_x_end, int *tile_y_
 static void pps_subpic_less_than_one_tile_slice(VVCPPS *pps, const VVCSPS 
*sps, const int i, const int tx, const int ty, int *off)
 {
 pps->num_ctus_in_slice[i] = pps_add_ctus(pps, off,
-pps->col_bd[tx], pps->row_bd[ty],
-pps->r->col_width_val[tx], sps->r->sps_subpic_height_minus1[i] + 1);
+sps->r->sps_subpic_ctu_top_left_x[i], 
sps->r->sps_subpic_ctu_top_left_y[i],
+sps->r->sps_subpic_width_minus1[i] + 1, 
sps->r->sps_subpic_height_minus1[i] + 1);
 }
 
 static void pps_subpic_one_or_more_tiles_slice(VVCPPS *pps, const int tile_x, 
const int tile_y, const int x_end, const int y_end, const int i, int *off)
-- 
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".

Re: [FFmpeg-devel] Captions SCC

[Devlist Archive]

>
> Not to start an argument, but WebVTT is kind of a terrible format.
> It's a lowest common denominator and loses most formatting information
> available even in 608 (which is now more than 40 years old).  Stuff
> like rollup captions for live programming, color (to distinguish
> speakers) and caption positioning are pretty important to the hearing
> impaired.


From the reading I have done, the WebVTT does support some placement,
italics, and appearance information, but not all players or ripping
programs support those functions.  It does appear that 708 has even more
options for the number of captions windows, font sizes, colors, etc that
can make a big difference in experience.

The new captions standard for ATSC 3.0 is actually ISMC1 profile TTML files
that are a sidecar configuration by default.  I would highly recommend
focusing on 608 and 708 compatibility first, and only then make sure all
possible features of those standards can be exported to webVTT for those
who will sponsor it.  ISMC1 profile TTML won't really be needed until the
majority of TV tuners ship with ATSC 3.0 which is still quite far off.
Implementation of TTML outputs from 708 tracks will require the ability to
extract the entire A/53 Part 4 encoded stream to a sidecar file so
implementing bitstream filters to both mux and demux the captions stream
from the video stream for the full A/53 Part 4 dataset will be required.

Zach


On Sun, Feb 9, 2025 at 6:03 AM Devin Heitmueller <
devin.heitmuel...@ltnglobal.com> wrote:

> On Sat, Feb 8, 2025 at 10:39 PM Tom Vaughan  wrote:
> >
> > I'm excited to see this discussion. There are many leading video
> distributors (streaming services, etc.) that would love to see solid
> support in FFMPEG for closed captions. No promises, but my sense is that
> additional money can be raised to sponsor this development.
> >
> > WebVTT as a sidecar captions file is the modern way to handle captions.
> The latest streaming client devices / applications support WebVTT captions.
> New movies and TV shows are produced with WebVTT captions.
>
> Not to start an argument, but WebVTT is kind of a terrible format.
> It's a lowest common denominator and loses most formatting information
> available even in 608 (which is now more than 40 years old).  Stuff
> like rollup captions for live programming, color (to distinguish
> speakers) and caption positioning are pretty important to the hearing
> impaired.
>
> Yesterday I watched a DVD I ripped (purely for personal use) of a TV
> show with VTT captions for something that I knew what the original 608
> looked like, and wow what a difference (the WebVTT looked dramatically
> worse than the original 608).
>
> To my point: no, I don't think normalizing everything down to WebVTT
> is a good idea.
>
> Much of the goal, at least in the work that I do, is to conform to the
> FCC requirements, which generally require that the original 608/708
> from the content provider be preserved.
>
> There can be money to support such efforts.  Most of my work in
> captioning within ffmpeg was funded by my employer, and most of the
> work I did improving 608 captions in VLC was financed by contract work
> I did for commercial customers who were embedding VLC into solutions
> and needed decent caption support.
>
> Devin
>
> --
> Devin Heitmueller, Senior Software Engineer
> LTN Global Communications
> o: +1 (301) 363-1001
> w: https://ltnglobal.com  e: devin.heitmuel...@ltnglobal.com
> ___
> 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] lavfi: fix undefined ff_vk_shader_print if vulkan filters are disabled

[Wang Bin]

Lynne  于2025年1月16日周四 16:19写道：
>
>> On 16/01/2025 15:24, Wang Bin wrote:
>> >
>> >
>> > ___
>> > 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".
>>
>> The better way would be to
>>
>> ifdef CONFIG_VULKAN
>> ...
>> endif
>>
>> Does the patch I sent fix the issue?
>>
>
> No. I enable vulkan to use vulkan decoders. Also enable libshaderc to test
> ffv1_vulkan encoder. If all vulkan filters are disabled, I get undefined
> ff_vk_shader_print error in libavfilter, which is used by
> libavfilter/vulkan_shaderc.c
>

ping
___
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] Captions SCC

[Tom Vaughan]

I suspect WebVTT became the modern CC format because...
- It is natively supported by the HLS and DASH specifications
- 
https://developer.apple.com/documentation/http-live-streaming/hls-authoring-specification-for-apple-devices
- 
https://reference.dashif.org/dash.js/latest/samples/captioning/caption_vtt.html
- Streaming is HTTP - based, and WebVTT is a W3C specification.
- https://www.w3.org/TR/webvtt1/
- WebVTT is delivered as a component (separate "sidecar" file). As such a 
streaming title can be updated to fix or improve a bad captions track, or to 
add support for additional languages without re-encoding or re-muxing the 
encoded video files. Updated a title to add support for another language only 
requires encoding the additional audio track, then packaging the updated set of 
audio, video and WebVTT files.
- Wide industry support in HLS and DASH packaging libraries (open source and 
commercial)
- Wide industry support in streaming player client platforms - both software 
and device native players
- Better support of dynamic ad insertion (avoids timing errors that cause 
program captions to appear over an ad, or vice versa)

As Zach noted, WebVTT supports setting the font color and background color. It 
also supports cue styling, including bold, underlined and italics.
See https://developer.mozilla.org/en-US/docs/Web/API/WebVTT_API for a live 
example.

Tom

On 2/9/25, 9:42 AM, "ffmpeg-devel on behalf of Devlist Archive" 
mailto:ffmpeg-devel-boun...@ffmpeg.org> on 
behalf of devl...@rlb.org > wrote:


>
> Not to start an argument, but WebVTT is kind of a terrible format.
> It's a lowest common denominator and loses most formatting information
> available even in 608 (which is now more than 40 years old). Stuff
> like rollup captions for live programming, color (to distinguish
> speakers) and caption positioning are pretty important to the hearing
> impaired.

From the reading I have done, the WebVTT does support some placement,
italics, and appearance information, but not all players or ripping
programs support those functions. It does appear that 708 has even more
options for the number of captions windows, font sizes, colors, etc that
can make a big difference in experience.

The new captions standard for ATSC 3.0 is actually ISMC1 profile TTML files
that are a sidecar configuration by default. I would highly recommend
focusing on 608 and 708 compatibility first, and only then make sure all
possible features of those standards can be exported to webVTT for those
who will sponsor it. ISMC1 profile TTML won't really be needed until the
majority of TV tuners ship with ATSC 3.0 which is still quite far off.
Implementation of TTML outputs from 708 tracks will require the ability to
extract the entire A/53 Part 4 encoded stream to a sidecar file so
implementing bitstream filters to both mux and demux the captions stream
from the video stream for the full A/53 Part 4 dataset will be required.

Zach




On Sun, Feb 9, 2025 at 6:03 AM Devin Heitmueller <
devin.heitmuel...@ltnglobal.com > wrote:


> On Sat, Feb 8, 2025 at 10:39 PM Tom Vaughan  > wrote:
> >
> > I'm excited to see this discussion. There are many leading video
> distributors (streaming services, etc.) that would love to see solid
> support in FFMPEG for closed captions. No promises, but my sense is that
> additional money can be raised to sponsor this development.
> >
> > WebVTT as a sidecar captions file is the modern way to handle captions.
> The latest streaming client devices / applications support WebVTT captions.
> New movies and TV shows are produced with WebVTT captions.
>
> Not to start an argument, but WebVTT is kind of a terrible format.
> It's a lowest common denominator and loses most formatting information
> available even in 608 (which is now more than 40 years old). Stuff
> like rollup captions for live programming, color (to distinguish
> speakers) and caption positioning are pretty important to the hearing
> impaired.
>
> Yesterday I watched a DVD I ripped (purely for personal use) of a TV
> show with VTT captions for something that I knew what the original 608
> looked like, and wow what a difference (the WebVTT looked dramatically
> worse than the original 608).
>
> To my point: no, I don't think normalizing everything down to WebVTT
> is a good idea.
>
> Much of the goal, at least in the work that I do, is to conform to the
> FCC requirements, which generally require that the original 608/708
> from the content provider be preserved.
>
> There can be money to support such efforts. Most of my work in
> captioning within ffmpeg was funded by my employer, and most of the
> work I did improving 608 captions in VLC was financed by contract work
> I did for commercial customers who were embedding VLC into solutions
> and needed decent caption support.
>
> Devin
>
> --
> Devin Heitmueller, Senior Software Engineer

Re: [FFmpeg-devel] Captions SCC

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Devlist Archive
> Sent: Sunday, February 9, 2025 6:42 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
> 
> >
> > Not to start an argument, but WebVTT is kind of a terrible format.
> > It's a lowest common denominator and loses most formatting
> information
> > available even in 608 (which is now more than 40 years old).  Stuff
> > like rollup captions for live programming, color (to distinguish
> > speakers) and caption positioning are pretty important to the
> hearing
> > impaired.
> 
> 
> From the reading I have done, the WebVTT does support some placement,
> italics, and appearance information, but not all players or ripping
> programs support those functions.  

Yes, that's right. It also supports colors. The unfortunate part is that colors 
and styles need to be predefined as (CSS) classes. It's not possible to use 
inline styles, which essentially forces doing two passes for precise colors. 
With the 8 colors in case of 608 it's easy though.
During the subtitle filtering work I had actually started adding missing 
features to the webvtt encoder but the requirement for predefined styles 
eventually set me off, making accurate conversions hardly possible. An idea was 
to create a predefined set of some-thousand styles and then always pick the 
closes matching one, but I hadn't followed that.


> On Sun, Feb 9, 2025 at 6:03 AM Devin Heitmueller <
> devin.heitmuel...@ltnglobal.com> wrote:
> 
> >
> > To my point: no, I don't think normalizing everything down to
> WebVTT
> > is a good idea.

Yes, WebVTT is not capable enough. ffmpeg internally uses the SSA/ASS format 
(for all text subs), which is undoubtedly the most capable format that exists.
Any subtitle conversion in ffmpeg goes through this format, so when you convert 
sub title format A to B, it's always 

A => ASS => B


So, when it comes to the question about a normalization, ASS is the way to go 
and ffmpeg made a good choice to do so.
For those who haven't seen it yet:

https://github.com/softworkz/SubtitleFilteringDemos/tree/master/Demo1


In this demo, the input is DVB bitmap subtitles and the output is DVB bitmap 
subtitles as well.
But in-between, the OCR filter takes the bitmap and outputs ASS subs. The next 
filter manipulates the text and afterwards the ASS subs are rendered as bitmaps 
and encoded as DVB subs again.

When you see this, you might think that it's kind-of like taking the source 
bitmaps, and writing new text on them, but that's not the case. Right in the 
middle, there's just the ASS format - which allows you to replicate any text 
subtitle feature that other formats have.

> > Much of the goal, at least in the work that I do, is to conform to
> the
> > FCC requirements, which generally require that the original 608/708
> > from the content provider be preserved.

All the above for getting to this answer: With ASS as storage/intermediate 
format it is possible to preserve the original content very precisely - without 
having to deal with a bitstream that cannot be safely applied to videos with 
different parameters than the original source.

It "just" requires an encoder for 608/708, hopefully it's more clear now why I 
had emphasized that earlier.


PS: Please note that this is not a proposal towards using ASS. The point is 
that ASS already _IS_ the intermediate format in ffmpeg and this won't and 
can't change (without re-implementing all text-subtitle encoders and decoders). 

sw



___
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] Captions SCC

[Marth64]

Partial reply:
FFmpeg's CC decoder is actually pretty decent for pop-on CC
but produces non-compliant ASS that needs postprocessing.

ASS can cover and render the pop-ons quite well, but the fundamental
limitation with representing EIA608 with ASS is that ASS does not
allow arbitrary positioning AND justification at the same time,
without making each line its own cue and carefully positioning the
cues or applying some other complex workarounds. The only alternative
I can think of within the ASS domain is to use heuristics to determine
numpad positioning of the caption cue and declare justification tags
without arbitrary positioning, but it needs work and will not be exact.

This is a problem for say, I want to render a cue at position x,y
but I want it also left justified at that position.

I will share details and an example in my slides.

I am personally not a fan of WebVTT but irrelevant to the advancements
I'm hoping to make. I think baby steps have to come first.

Have a good day,
___
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".