[FFmpeg-devel] Apply misc doc/muxers fixes and extensions

[FFmpeg-devel] Apply misc doc/muxers fixes and extensions

[Stefano Sabatini]

Apply misc doc/muxers fixes and extensions.


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

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

[FFmpeg-devel] [PATCH 1/6] doc/muxers/matroskaenc: add missing options, apply misc style fixes

[Stefano Sabatini]

---
 doc/muxers.texi | 44 +++++++++++++++++++++++++++++++++++++-------
 1 file changed, 37 insertions(+), 7 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index a77472ef1b..a162ab4075 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2846,8 +2846,44 @@ the initially reserved space turns out to be insufficient.
 
 This option is ignored if the output is unseekable.
 
+@item cluster_size_limit @var{size}
+Store at most the provided amount of bytes in a cluster.
+
+If not specified, the limit is set automatically to a sensible
+hardcoded fixed value.
+
+@item cluster_time_limit @var{duration}
+Store at most the provided number of milliseconds in a cluster.
+
+If not specified, the limit is set automatically to a sensible
+hardcoded fixed value.
+
+@item dash @var{bool}
+Create a WebM file conforming to WebM DASH specification. By default
+it is set to @code{false}.
+
+@item dash_track_number @var{index}
+Track number for the DASH stream. By default it is set to @code{1}.
+
+@item live @var{bool}
+Write files assuming it is a live stream. By default it is set to
+@code{false}.
+
+@item allow_raw_vfw @var{bool}
+Allow raw VFW mode. By default it is set to @code{false}.
+
+@item flipped_raw_rgb @var{bool}
+If set to @code{true}, store positive height for raw RGB bitmaps, which indicates
+bitmap is stored bottom-up. Note that this option does not flip the bitmap
+which has to be done manually beforehand, e.g. by using the @samp{vflip} filter.
+Default is @code{false} and indicates bitmap is stored top down.
+
+@item write_crc32 @var{bool}
+Write a CRC32 element inside every Level 1 element. By default it is
+set to @code{true}.
+
 @item default_mode @var{mode}
-This option controls how the FlagDefault of the output tracks will be set.
+Control how the FlagDefault of the output tracks will be set.
 It influences which tracks players should play by default. The default mode
 is @samp{passthrough}.
 @table @samp
@@ -2865,12 +2901,6 @@ disposition default exists, no subtitle track will be marked as default.
 In this mode the FlagDefault is set if and only if the AV_DISPOSITION_DEFAULT
 flag is set in the disposition of the corresponding stream.
 @end table
-
-@item flipped_raw_rgb @var{bool}
-If set to true, store positive height for raw RGB bitmaps, which indicates
-bitmap is stored bottom-up. Note that this option does not flip the bitmap
-which has to be done manually beforehand, e.g. by using the vflip filter.
-Default is @var{false} and indicates bitmap is stored top down.
 @end table
 
 @anchor{md5}
-- 
2.34.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-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/6] doc/muxers/md5: apply misc consistency fixes

[Stefano Sabatini]

---
 doc/muxers.texi | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index a162ab4075..710fc27eec 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2905,26 +2905,28 @@ flag is set in the disposition of the corresponding stream.
 
 @anchor{md5}
 @section md5
-
 MD5 testing format.
 
 This is a variant of the @ref{hash} muxer. Unlike that muxer, it
 defaults to using the MD5 hash function.
 
-@subsection Examples
+See also the @ref{hash} and @ref{framemd5} muxers.
 
+@subsection Examples
+@itemize
+@item
 To compute the MD5 hash of the input converted to raw
 audio and video, and store it in the file @file{out.md5}:
 @example
 ffmpeg -i INPUT -f md5 out.md5
 @end example
 
-You can print the MD5 to stdout with the command:
+@item
+To print the MD5 to stdout:
 @example
 ffmpeg -i INPUT -f md5 -
 @end example
-
-See also the @ref{hash} and @ref{framemd5} muxers.
+@end itemize
 
 @section mp3
 
-- 
2.34.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-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/6] doc/muxers: add microdvd

[Stefano Sabatini]

---
 doc/muxers.texi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 710fc27eec..f94513527d 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2928,6 +2928,11 @@ ffmpeg -i INPUT -f md5 -
 @end example
 @end itemize
 
+@section microdvd
+MicroDVD subtitle format muxer.
+
+This muxer accepts a single @samp{microdvd} subtitles stream.
+
 @section mp3
 
 The MP3 muxer writes a raw MP3 stream with the following optional features:
-- 
2.34.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-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 4/6] doc/muxers: add mkvtimestamp_v2

[Stefano Sabatini]

---
 doc/muxers.texi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index f94513527d..490d5557bf 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2933,6 +2933,14 @@ MicroDVD subtitle format muxer.
 
 This muxer accepts a single @samp{microdvd} subtitles stream.
 
+@section mkvtimestamp_v2
+mkvtoolnix v2 timecode format muxer.
+
+Write the PTS rawvideo frame to the output, as supported by the
+@command{mkvextact} tool from the @command{mkvtoolnix} suite.
+
+This muxer accepts a single @samp{rawvideo} stream.
+
 @section mp3
 
 The MP3 muxer writes a raw MP3 stream with the following optional features:
-- 
2.34.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-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 5/6] lavf/mkvtimestamp_v2: use name in place of description in long name

[Stefano Sabatini]

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

diff --git a/libavformat/mkvtimestamp_v2.c b/libavformat/mkvtimestamp_v2.c
index dde431ab7d..1eb2daf10a 100644
--- a/libavformat/mkvtimestamp_v2.c
+++ b/libavformat/mkvtimestamp_v2.c
@@ -43,7 +43,7 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
 
 const FFOutputFormat ff_mkvtimestamp_v2_muxer = {
     .p.name        = "mkvtimestamp_v2",
-    .p.long_name   = NULL_IF_CONFIG_SMALL("extract pts as timecode v2 format, as defined by mkvtoolnix"),
+    .p.long_name   = NULL_IF_CONFIG_SMALL("mkvtoolnix v2 timecode format"),
     .p.audio_codec = AV_CODEC_ID_NONE,
     .p.video_codec = AV_CODEC_ID_RAWVIDEO,
     .write_header = write_header,
-- 
2.34.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-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 6/6] doc/muxers: add mmf

[Stefano Sabatini]

---
 doc/muxers.texi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 490d5557bf..43c4865292 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2941,6 +2941,15 @@ Write the PTS rawvideo frame to the output, as supported by the
 
 This muxer accepts a single @samp{rawvideo} stream.
 
+@section mmf
+Synthetic music Mobile Application Format (SMAF) format muxer.
+
+SMAF is a music data format specified by Yamaha for portable
+electronic devices, such as cell phones and PDAs. It is common as
+ringtones for mobile phones with one of five sound chips.
+
+This muxer accepts a single @samp{adpcm_yamaha} audio stream.
+
 @section mp3
 
 The MP3 muxer writes a raw MP3 stream with the following optional features:
-- 
2.34.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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/6] doc/muxers: add mkvtimestamp_v2

[Andreas Rheinhardt]

Stefano Sabatini:
> ---
>  doc/muxers.texi | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index f94513527d..490d5557bf 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -2933,6 +2933,14 @@ MicroDVD subtitle format muxer.
>  
>  This muxer accepts a single @samp{microdvd} subtitles stream.
>  
> +@section mkvtimestamp_v2
> +mkvtoolnix v2 timecode format muxer.
> +
> +Write the PTS rawvideo frame to the output, as supported by the
> +@command{mkvextact} tool from the @command{mkvtoolnix} suite.
> +
> +This muxer accepts a single @samp{rawvideo} stream.
> +
>  @section mp3
>  
>  The MP3 muxer writes a raw MP3 stream with the following optional features:

This is wrong: MKVToolNix switched to "# timestamp format v2" a long
time ago (we still write the old "# timecode format v2" header);
furthermore, MKVToolNix actually uses pts (which it reorders to be
ascending), not dts like our muxer. Furthermore MKVToolNix does not
force a 1ms precision on timestamps.

- Andreas

PS: mkvextract, not mkvextact.

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

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

Re: [FFmpeg-devel] [PATCH 4/6] doc/muxers: add mkvtimestamp_v2

[Stefano Sabatini]

On date Tuesday 2024-04-16 12:50:19 +0200, Andreas Rheinhardt wrote:
> Stefano Sabatini:
> > ---
> >  doc/muxers.texi | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/doc/muxers.texi b/doc/muxers.texi
> > index f94513527d..490d5557bf 100644
> > --- a/doc/muxers.texi
> > +++ b/doc/muxers.texi
> > @@ -2933,6 +2933,14 @@ MicroDVD subtitle format muxer.
> >  
> >  This muxer accepts a single @samp{microdvd} subtitles stream.
> >  
> > +@section mkvtimestamp_v2
> > +mkvtoolnix v2 timecode format muxer.
> > +
> > +Write the PTS rawvideo frame to the output, as supported by the
> > +@command{mkvextact} tool from the @command{mkvtoolnix} suite.
> > +
> > +This muxer accepts a single @samp{rawvideo} stream.
> > +
> >  @section mp3
> >  
> >  The MP3 muxer writes a raw MP3 stream with the following optional features:
> 

> This is wrong: MKVToolNix switched to "# timestamp format v2" a long
> time ago (we still write the old "# timecode format v2" header);
> furthermore, MKVToolNix actually uses pts (which it reorders to be
> ascending), not dts like our muxer. Furthermore MKVToolNix does not
> force a 1ms precision on timestamps.

Correct.

I compared the output of the muxer and of mkvtoolnix extract
timestamp_v2 and I'm not yet clear about the timestamp differences I'm
observing (the muxer output maps with the timestamps, the mkvtoolnix
timestamps differ by a few ms). But I think also mkvtoolnix use a 1ms
timebase.

Also, IIRC there is no generic way to reorder PTSs, so this might
account for another difference which might be difficult to implement
generically.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 4/6] doc/muxers: add mkvtimestamp_v2

[Andreas Rheinhardt]

Stefano Sabatini:
> On date Tuesday 2024-04-16 12:50:19 +0200, Andreas Rheinhardt wrote:
>> Stefano Sabatini:
>>> ---
>>>  doc/muxers.texi | 8 ++++++++
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>>> index f94513527d..490d5557bf 100644
>>> --- a/doc/muxers.texi
>>> +++ b/doc/muxers.texi
>>> @@ -2933,6 +2933,14 @@ MicroDVD subtitle format muxer.
>>>  
>>>  This muxer accepts a single @samp{microdvd} subtitles stream.
>>>  
>>> +@section mkvtimestamp_v2
>>> +mkvtoolnix v2 timecode format muxer.
>>> +
>>> +Write the PTS rawvideo frame to the output, as supported by the
>>> +@command{mkvextact} tool from the @command{mkvtoolnix} suite.
>>> +
>>> +This muxer accepts a single @samp{rawvideo} stream.
>>> +
>>>  @section mp3
>>>  
>>>  The MP3 muxer writes a raw MP3 stream with the following optional features:
>>
> 
>> This is wrong: MKVToolNix switched to "# timestamp format v2" a long
>> time ago (we still write the old "# timecode format v2" header);
>> furthermore, MKVToolNix actually uses pts (which it reorders to be
>> ascending), not dts like our muxer. Furthermore MKVToolNix does not
>> force a 1ms precision on timestamps.
> 
> Correct.
> 
> I compared the output of the muxer and of mkvtoolnix extract
> timestamp_v2 and I'm not yet clear about the timestamp differences I'm
> observing (the muxer output maps with the timestamps, the mkvtoolnix
> timestamps differ by a few ms). But I think also mkvtoolnix use a 1ms
> timebase.

The accuracy of the timestamps output by mkvextract is determined by the
TimestampScale of the file in question; it is most often 1ms when the
file has video.
You need to provide more details if you want these discrepancies to be
analyzed.

> 
> Also, IIRC there is no generic way to reorder PTSs, so this might
> account for another difference which might be difficult to implement
> generically.

Write them into a buffer and reorder them at the end?
(No, I have no intention to actually implement this. I am rather leaning
to "this muxer should not exist".)

- 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/6] doc/muxers: add mkvtimestamp_v2

[Stefano Sabatini]

On date Tuesday 2024-04-16 20:09:19 +0200, Andreas Rheinhardt wrote:
> Stefano Sabatini:
> > On date Tuesday 2024-04-16 12:50:19 +0200, Andreas Rheinhardt wrote:
> >> Stefano Sabatini:
> >>> ---
> >>>  doc/muxers.texi | 8 ++++++++
> >>>  1 file changed, 8 insertions(+)
> >>>
> >>> diff --git a/doc/muxers.texi b/doc/muxers.texi
> >>> index f94513527d..490d5557bf 100644
> >>> --- a/doc/muxers.texi
> >>> +++ b/doc/muxers.texi
> >>> @@ -2933,6 +2933,14 @@ MicroDVD subtitle format muxer.
> >>>  
> >>>  This muxer accepts a single @samp{microdvd} subtitles stream.
> >>>  
> >>> +@section mkvtimestamp_v2
> >>> +mkvtoolnix v2 timecode format muxer.
> >>> +
> >>> +Write the PTS rawvideo frame to the output, as supported by the
> >>> +@command{mkvextact} tool from the @command{mkvtoolnix} suite.
> >>> +
> >>> +This muxer accepts a single @samp{rawvideo} stream.
> >>> +
> >>>  @section mp3
> >>>  
> >>>  The MP3 muxer writes a raw MP3 stream with the following optional features:
> >>
> > 
> >> This is wrong: MKVToolNix switched to "# timestamp format v2" a long
> >> time ago (we still write the old "# timecode format v2" header);
> >> furthermore, MKVToolNix actually uses pts (which it reorders to be
> >> ascending), not dts like our muxer. Furthermore MKVToolNix does not
> >> force a 1ms precision on timestamps.
> > 
> > Correct.
> > 
> > I compared the output of the muxer and of mkvtoolnix extract
> > timestamp_v2 and I'm not yet clear about the timestamp differences I'm
> > observing (the muxer output maps with the timestamps, the mkvtoolnix
> > timestamps differ by a few ms). But I think also mkvtoolnix use a 1ms
> > timebase.
> 
> The accuracy of the timestamps output by mkvextract is determined by the
> TimestampScale of the file in question; it is most often 1ms when the
> file has video.

> You need to provide more details if you want these discrepancies to be
> analyzed.

Probably not worth the effort.

> > Also, IIRC there is no generic way to reorder PTSs, so this might
> > account for another difference which might be difficult to implement
> > generically.
> 

> Write them into a buffer and reorder them at the end?
> (No, I have no intention to actually implement this. I am rather leaning
> to "this muxer should not exist".)

I also think we have better tools at this point (one being ffprobe
-show_packets) but we should not drop it before deprecating it.

Plan: av_tree to insert elements in a constant-size buffer or store in
a buffer sorted once at the end. We probably should skip PTS=NA
elements.

Dropping the doc patch as the implementation is broken. 

Will apply the rest of the patchset 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/6] doc/muxers/matroskaenc: add missing options, apply misc style fixes

[Andreas Rheinhardt]

Stefano Sabatini:
> ---
>  doc/muxers.texi | 44 +++++++++++++++++++++++++++++++++++++-------
>  1 file changed, 37 insertions(+), 7 deletions(-)
> 
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index a77472ef1b..a162ab4075 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -2846,8 +2846,44 @@ the initially reserved space turns out to be insufficient.
>  
>  This option is ignored if the output is unseekable.
>  
> +@item cluster_size_limit @var{size}
> +Store at most the provided amount of bytes in a cluster.
> +
> +If not specified, the limit is set automatically to a sensible
> +hardcoded fixed value.
> +
> +@item cluster_time_limit @var{duration}
> +Store at most the provided number of milliseconds in a cluster.
> +
> +If not specified, the limit is set automatically to a sensible
> +hardcoded fixed value.
> +
> +@item dash @var{bool}
> +Create a WebM file conforming to WebM DASH specification. By default
> +it is set to @code{false}.
> +
> +@item dash_track_number @var{index}
> +Track number for the DASH stream. By default it is set to @code{1}.
> +
> +@item live @var{bool}
> +Write files assuming it is a live stream. By default it is set to
> +@code{false}.
> +
> +@item allow_raw_vfw @var{bool}
> +Allow raw VFW mode. By default it is set to @code{false}.
> +
> +@item flipped_raw_rgb @var{bool}
> +If set to @code{true}, store positive height for raw RGB bitmaps, which indicates
> +bitmap is stored bottom-up. Note that this option does not flip the bitmap
> +which has to be done manually beforehand, e.g. by using the @samp{vflip} filter.
> +Default is @code{false} and indicates bitmap is stored top down.
> +
> +@item write_crc32 @var{bool}
> +Write a CRC32 element inside every Level 1 element. By default it is
> +set to @code{true}.
> +

State that this option is ignored fro WebM.

>  @item default_mode @var{mode}
> -This option controls how the FlagDefault of the output tracks will be set.
> +Control how the FlagDefault of the output tracks will be set.
>  It influences which tracks players should play by default. The default mode
>  is @samp{passthrough}.
>  @table @samp
> @@ -2865,12 +2901,6 @@ disposition default exists, no subtitle track will be marked as default.
>  In this mode the FlagDefault is set if and only if the AV_DISPOSITION_DEFAULT
>  flag is set in the disposition of the corresponding stream.
>  @end table
> -
> -@item flipped_raw_rgb @var{bool}
> -If set to true, store positive height for raw RGB bitmaps, which indicates
> -bitmap is stored bottom-up. Note that this option does not flip the bitmap
> -which has to be done manually beforehand, e.g. by using the vflip filter.
> -Default is @var{false} and indicates bitmap is stored top down.
>  @end table
>  
>  @anchor{md5}

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

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