Re: [FFmpeg-devel] [PATCH v2] cbs_av1: Fill tile width/height values when uniform_tile_spacing_flag is set
> -Original Message-
> From: ffmpeg-devel On Behalf Of Mark
> Thompson
> Sent: Tuesday, September 1, 2020 5:01 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2] cbs_av1: Fill tile width/height values when
> uniform_tile_spacing_flag is set
>
> They are not explicitly in the bitstream in this case, but it is helpful to
> be able to
> use these values without always needing to check the flag beforehand.
> ---
> On 31/08/2020 08:31, Wang, Fei W wrote:>> -Original Message-
> >> From: ffmpeg-devel On Behalf Of
> >> Mark Thompson
> >> Sent: Sunday, August 23, 2020 6:26 AM
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: [FFmpeg-devel] [PATCH] cbs_av1: Fill tile width/height
> >> values when uniform_tile_spacing_flag is set
> >>
> >> They are not explicitly in the bitstream in this case, but it is
> >> helpful to be able to use these values without always needing to check the
> flag beforehand.
> >> ---
> >>libavcodec/cbs_av1_syntax_template.c | 9 +
> >>1 file changed, 9 insertions(+)
> >>
> >> diff --git a/libavcodec/cbs_av1_syntax_template.c
> >> b/libavcodec/cbs_av1_syntax_template.c
> >> index a315e8868a..2c976a9574 100644
> >> --- a/libavcodec/cbs_av1_syntax_template.c
> >> +++ b/libavcodec/cbs_av1_syntax_template.c
> >> @@ -624,6 +624,15 @@ static int FUNC(tile_info)(CodedBitstreamContext
> >> *ctx, RWContext *rw,
> >>current->tile_rows_log2;
> >>current->tile_rows = (sb_rows + tile_height_sb - 1) /
> >> tile_height_sb;
> >>
> >> +for (i = 0; i < current->tile_cols - 1; i++)
> >> +infer(width_in_sbs_minus_1[i], tile_width_sb);
> >> +infer(width_in_sbs_minus_1[i],
> >> + sb_cols - (current->tile_cols - 1) * tile_width_sb);
> > Should this by using "tile_width_sb -1" and "sb_cols - (current->tile_cols
> > - 1) *
> tile_width_sb - 1" ? And same for height_in_sbs_minus_1.
>
> Oops, yeah (just looking at the numbers to check means you don't notice the
> minus_1).
>
> >> +for (i = 0; i < current->tile_rows - 1; i++)
> >> +infer(height_in_sbs_minus_1[i], tile_height_sb);
> >> +infer(height_in_sbs_minus_1[i],
> >> + sb_rows - (current->tile_rows - 1) * tile_height_sb);
> >> +
> >>} else {
> >>int widest_tile_sb, start_sb, size_sb, max_width,
> >> max_height;
> >>
>
> New version enclosing.
>
> Thanks,
>
> - Mark
>
> libavcodec/cbs_av1_syntax_template.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/libavcodec/cbs_av1_syntax_template.c
> b/libavcodec/cbs_av1_syntax_template.c
> index 19b82bc3f8..2d2e240e3e 100644
> --- a/libavcodec/cbs_av1_syntax_template.c
> +++ b/libavcodec/cbs_av1_syntax_template.c
> @@ -636,6 +636,15 @@ static int FUNC(tile_info)(CodedBitstreamContext *ctx,
> RWContext *rw,
> current->tile_rows_log2;
> current->tile_rows = (sb_rows + tile_height_sb - 1) /
> tile_height_sb;
>
> +for (i = 0; i < current->tile_cols - 1; i++)
> +infer(width_in_sbs_minus_1[i], tile_width_sb - 1);
> +infer(width_in_sbs_minus_1[i],
> + sb_cols - (current->tile_cols - 1) * tile_width_sb - 1);
> +for (i = 0; i < current->tile_rows - 1; i++)
> +infer(height_in_sbs_minus_1[i], tile_height_sb - 1);
> +infer(height_in_sbs_minus_1[i],
> + sb_rows - (current->tile_rows - 1) * tile_height_sb - 1);
> +
LGTM, could you help to merge this patch? I will submit 2nd version of VAAPI AV1
decoder patch base on this change. Thanks.
> } else {
> int widest_tile_sb, start_sb, size_sb, max_width, max_height;
>
> --
> 2.28.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 1/8] avcodec/magicyuv: Don't invert Huffman table symbols twice
Paul B Mahol: > On 8/31/20, Andreas Rheinhardt wrote: >> When the MagicYUV decoder builds Huffman tables from an array of code >> lengths, it proceeds as follows: First it copies the entries of the >> array of lengths into an array of HuffEntries (a struct which contains >> a length and a symbol field); it also sets the symbol field in >> descending order from nb_elem - 1 to 0, where nb_elem is the common number >> of elements of the length and HuffEntry arrays. Then the HuffEntry array >> is sorted lexicographically: a > b iff a.len > b.len or a.len == b.len and >> a.sym > b.sym. Afterwards the symbols of the so sorted array are >> inverted again (i.e. each symbol sym is replaced by nb_elem - sym). >> >> Yet inverting can easily be avoided altogether: Just modify the order so >> that smaller symbols correspond to bigger HuffEntries. This leads to the >> same permutation as the current code does and given that the two >> inversions just cancel each other out, the result is the same. >> >> Signed-off-by: Andreas Rheinhardt >> --- >> libavcodec/magicyuv.c | 18 +- >> 1 file changed, 9 insertions(+), 9 deletions(-) >> > > LGTM whole patch set. > Applied. Thanks for testing and reviewing. - 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".
Re: [FFmpeg-devel] libopenjpeg decoder not correctly setting the pixel format for cinema JP2K wrapped MXF
> Do you have a sample that does not work with the native decoder?
According to my tests, the native decoder detect pixel format just fine,
I'm talking about the libopenjpeg wrapper here (ie. libopenjpegdec.c).
As for sample materials, I guess you can check this link
https://github.com/Ymagis/ClairMeta_Data
Specifically, we made DCP in various configurations with MXF video track
that last 1sec (minimum allowed by the SMPTE), let me know if that works
for you.
* 2D Interop MXF
https://github.com/Ymagis/ClairMeta_Data/blob/master/DCP/ECL-SET/ECL01-SINGLE-CPL_TST_S_EN-XX_UK-U_71_2K_DI_20171218_ECL_IOP_OV/ECL01-SINGLE-CPL_TST_S_EN-XX_UK-U_71_2K_DI_20171218_ECL_IOP_OV_01.mxf
* 3D SMPTE MXF
https://github.com/Ymagis/ClairMeta_Data/blob/master/DCP/ECL-SET/ECL09-SINGLE-CPL_TST_S_EN-XX_UK-U_51-ATMOS_2K_DI_20171220_ECL_SMPTE_OV/ECL-SINGLE-CPL_TST_S_EN-XX_UK-U_51_2K_DI_20171220_ECL_SMPTE_OV_01.mxf
> If you want the IS_KLV_KEY() check to be more lenient then you should
> make mxf_jp2k_rsiz[] shorter, not replace the end of it with NULs
This UL come straight from SMPTE ST 422M, not sure what you mean but I
didn't replace it with arbitrary NULs values.
Looking at mxfdec.c some more, I found that the pixel format is
supposed to be passed to the AVStream codecpar later on, but there is
some issues with that, that I don't found a solution yet:
* The JPEG2000PictureSubDescriptor live in it's own "MetadatSet" and
the pixel_format assigned is from a different Descriptor structure
than the one used for eg. width and height parameters
* Currently the pixel_format is only passed on for RAWVIDEO codec, so
it would require doing that for JP2K and potentially others as well
Le dim. 30 août 2020 à 18:22, Rémi Achard a écrit :
> Hi,
>
> As you are probably aware, the libopenjpeg decoder is not able to
> interpret cinema jp2k mxf correctly, the pixel format being assigned as
> rgb48 instead of xyz12 as it should. Note that ffmpeg native jp2k decoder
> parse the RSIZ descriptor from the jp2k bitstream and is able to correctly
> assign the pixel format, but libopenjpeg currently don't read the
> RSIZ marker so that ffmpeg wrapper has no simple mean of doing this at the
> moment (a pull request on libopenjpeg is still in progress to try to fix
> that).
>
> Someone recently pointed me to this commit from 2015
> https://github.com/FFmpeg/FFmpeg/commit/2af260e3a85ef2a9fadcac4f4fa652cee53e591e
> .
> According to my tests, it doesn't work because of a wrong RSIZ key and
> missing JP2KEssenceSubDescriptor lookup group. I made a patch I made to fix
> that, mxfdec is now able to correctly assign the descriptor->pix_fmt field.
> Note that these keys can be found in SMPTE ST 429-4 or discovered through
> asdcplib with asdcp-info command line tool parsing a cinema mxf video track.
>
> Then, even with that patch, the pixel format detected by the demuxer is
> not communicated to the decoder, as far as I'm aware. Which makes me
> wonder, what was the original goal of that commit and what I'm missing to
> communicate this information to libopenjpeg decoder ?
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index 6f6e8d586c..cd85fbedff 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -325,7 +325,7 @@ static const uint8_t mxf_encrypted_essence_container[]
> = { 0x06,0x0e,0x2b,0x
> static const uint8_t mxf_random_index_pack_key[] = {
> 0x06,0x0e,0x2b,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x11,0x01,0x00
> };
> static const uint8_t mxf_sony_mpeg4_extradata[]= {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0e,0x06,0x06,0x02,0x02,0x01,0x00,0x00
> };
> static const uint8_t mxf_avid_project_name[] = {
> 0xa5,0xfb,0x7b,0x25,0xf6,0x15,0x94,0xb9,0x62,0xfc,0x37,0x17,0x49,0x2d,0x42,0xbf
> };
> -static const uint8_t mxf_jp2k_rsiz[] = {
> 0x06,0x0e,0x2b,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x02,0x01,0x00
> };
> +static const uint8_t mxf_jp2k_rsiz[] = {
> 0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x01,0x00,0x00,0x00
> };
> static const uint8_t mxf_indirect_value_utf16le[] = {
> 0x4c,0x00,0x02,0x10,0x01,0x00,0x00,0x00,0x00,0x06,0x0e,0x2b,0x34,0x01,0x04,0x01,0x01
> };
> static const uint8_t mxf_indirect_value_utf16be[] = {
> 0x42,0x01,0x10,0x02,0x00,0x00,0x00,0x00,0x00,0x06,0x0e,0x2b,0x34,0x01,0x04,0x01,0x01
> };
>
> @@ -2746,6 +2746,7 @@ static const MXFMetadataReadTableEntry
> mxf_metadata_read_table[] = {
> { {
> 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x42,0x00
> }, mxf_read_generic_descriptor, sizeof(MXFDescriptor), Descriptor }, /*
> Generic Sound */
> { {
> 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x28,0x00
> }, mxf_read_generic_descriptor, sizeof(MXFDescriptor), Descriptor }, /*
> CDCI */
> { {
> 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x29,0x00
> }, mxf_read_generic_
Re: [FFmpeg-devel] libopenjpeg decoder not correctly setting the pixel format for cinema JP2K wrapped MXF
> * 3D SMPTE MXF
Typo, this is 2D SMPTE MXF, there are 3D versions in that same repo
however, but it probably don't matter much here.
Le mar. 1 sept. 2020 à 11:06, Rémi Achard a écrit :
> > Do you have a sample that does not work with the native decoder?
>
> According to my tests, the native decoder detect pixel format just fine,
> I'm talking about the libopenjpeg wrapper here (ie. libopenjpegdec.c).
>
> As for sample materials, I guess you can check this link
> https://github.com/Ymagis/ClairMeta_Data
>
> Specifically, we made DCP in various configurations with MXF video track
> that last 1sec (minimum allowed by the SMPTE), let me know if that works
> for you.
> * 2D Interop MXF
> https://github.com/Ymagis/ClairMeta_Data/blob/master/DCP/ECL-SET/ECL01-SINGLE-CPL_TST_S_EN-XX_UK-U_71_2K_DI_20171218_ECL_IOP_OV/ECL01-SINGLE-CPL_TST_S_EN-XX_UK-U_71_2K_DI_20171218_ECL_IOP_OV_01.mxf
> * 3D SMPTE MXF
> https://github.com/Ymagis/ClairMeta_Data/blob/master/DCP/ECL-SET/ECL09-SINGLE-CPL_TST_S_EN-XX_UK-U_51-ATMOS_2K_DI_20171220_ECL_SMPTE_OV/ECL-SINGLE-CPL_TST_S_EN-XX_UK-U_51_2K_DI_20171220_ECL_SMPTE_OV_01.mxf
>
> > If you want the IS_KLV_KEY() check to be more lenient then you should
> > make mxf_jp2k_rsiz[] shorter, not replace the end of it with NULs
>
> This UL come straight from SMPTE ST 422M, not sure what you mean but I didn't
> replace it with arbitrary NULs values.
>
>
> Looking at mxfdec.c some more, I found that the pixel format is supposed to
> be passed to the AVStream codecpar later on, but there is some issues with
> that, that I don't found a solution yet:
>
> * The JPEG2000PictureSubDescriptor live in it's own "MetadatSet" and the
> pixel_format assigned is from a different Descriptor structure than the one
> used for eg. width and height parameters
> * Currently the pixel_format is only passed on for RAWVIDEO codec, so it
> would require doing that for JP2K and potentially others as well
>
>
> Le dim. 30 août 2020 à 18:22, Rémi Achard a écrit :
>
>> Hi,
>>
>> As you are probably aware, the libopenjpeg decoder is not able to
>> interpret cinema jp2k mxf correctly, the pixel format being assigned as
>> rgb48 instead of xyz12 as it should. Note that ffmpeg native jp2k decoder
>> parse the RSIZ descriptor from the jp2k bitstream and is able to correctly
>> assign the pixel format, but libopenjpeg currently don't read the
>> RSIZ marker so that ffmpeg wrapper has no simple mean of doing this at the
>> moment (a pull request on libopenjpeg is still in progress to try to fix
>> that).
>>
>> Someone recently pointed me to this commit from 2015
>> https://github.com/FFmpeg/FFmpeg/commit/2af260e3a85ef2a9fadcac4f4fa652cee53e591e
>> .
>> According to my tests, it doesn't work because of a wrong RSIZ key and
>> missing JP2KEssenceSubDescriptor lookup group. I made a patch I made to fix
>> that, mxfdec is now able to correctly assign the descriptor->pix_fmt field.
>> Note that these keys can be found in SMPTE ST 429-4 or discovered through
>> asdcplib with asdcp-info command line tool parsing a cinema mxf video track.
>>
>> Then, even with that patch, the pixel format detected by the demuxer is
>> not communicated to the decoder, as far as I'm aware. Which makes me
>> wonder, what was the original goal of that commit and what I'm missing to
>> communicate this information to libopenjpeg decoder ?
>>
>> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
>> index 6f6e8d586c..cd85fbedff 100644
>> --- a/libavformat/mxfdec.c
>> +++ b/libavformat/mxfdec.c
>> @@ -325,7 +325,7 @@ static const uint8_t
>> mxf_encrypted_essence_container[] = { 0x06,0x0e,0x2b,0x
>> static const uint8_t mxf_random_index_pack_key[] = {
>> 0x06,0x0e,0x2b,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x11,0x01,0x00
>> };
>> static const uint8_t mxf_sony_mpeg4_extradata[]= {
>> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0e,0x06,0x06,0x02,0x02,0x01,0x00,0x00
>> };
>> static const uint8_t mxf_avid_project_name[] = {
>> 0xa5,0xfb,0x7b,0x25,0xf6,0x15,0x94,0xb9,0x62,0xfc,0x37,0x17,0x49,0x2d,0x42,0xbf
>> };
>> -static const uint8_t mxf_jp2k_rsiz[] = {
>> 0x06,0x0e,0x2b,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x02,0x01,0x00
>> };
>> +static const uint8_t mxf_jp2k_rsiz[] = {
>> 0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x01,0x00,0x00,0x00
>> };
>> static const uint8_t mxf_indirect_value_utf16le[] = {
>> 0x4c,0x00,0x02,0x10,0x01,0x00,0x00,0x00,0x00,0x06,0x0e,0x2b,0x34,0x01,0x04,0x01,0x01
>> };
>> static const uint8_t mxf_indirect_value_utf16be[] = {
>> 0x42,0x01,0x10,0x02,0x00,0x00,0x00,0x00,0x00,0x06,0x0e,0x2b,0x34,0x01,0x04,0x01,0x01
>> };
>>
>> @@ -2746,6 +2746,7 @@ static const MXFMetadataReadTableEntry
>> mxf_metadata_read_table[] = {
>> { {
>> 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x42,0x00
>> }, mxf_read_generic_descriptor, sizeof(MXFDescriptor), Descriptor },
Re: [FFmpeg-devel] [PATCH] avcodec/qpeg: speed-up copy of bytes
Quoting Paul B Mahol (2020-08-31 23:37:07)
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/qpeg.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/qpeg.c b/libavcodec/qpeg.c
> index 40931e3bdc..8bc710acfd 100644
> --- a/libavcodec/qpeg.c
> +++ b/libavcodec/qpeg.c
> @@ -101,8 +101,11 @@ static void qpeg_decode_intra(QpegContext *qctx, uint8_t
> *dst,
> } else {
> if (bytestream2_get_bytes_left(&qctx->buffer) < copy)
> copy = bytestream2_get_bytes_left(&qctx->buffer);
> -for(i = 0; i < copy; i++) {
> -dst[filled++] = bytestream2_get_byte(&qctx->buffer);
> +while (copy > 0) {
> +int step = FFMIN(copy, width - filled);
> +bytestream2_get_bufferu(&qctx->buffer, dst + filled, step);
> +filled += step;
> +copy -= step;
> if (filled >= width) {
> filled = 0;
> dst -= stride;
> --
> 2.17.1
Looks ok.
--
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] [PATCH 2/5] avcodec: add FastAudio decoder
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/codec_desc.c | 7 ++
libavcodec/codec_id.h | 1 +
libavcodec/fastaudio.c | 200
libavcodec/utils.c | 2 +
6 files changed, 212 insertions(+)
create mode 100644 libavcodec/fastaudio.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 191c4e0a7c..6f75f26c84 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -317,6 +317,7 @@ OBJS-$(CONFIG_ESCAPE124_DECODER) += escape124.o
OBJS-$(CONFIG_ESCAPE130_DECODER) += escape130.o
OBJS-$(CONFIG_EVRC_DECODER)+= evrcdec.o acelp_vectors.o lsp.o
OBJS-$(CONFIG_EXR_DECODER) += exr.o exrdsp.o
+OBJS-$(CONFIG_FASTAUDIO_DECODER) += fastaudio.o
OBJS-$(CONFIG_FFV1_DECODER)+= ffv1dec.o ffv1.o
OBJS-$(CONFIG_FFV1_ENCODER)+= ffv1enc.o ffv1.o
OBJS-$(CONFIG_FFWAVESYNTH_DECODER) += ffwavesynth.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 084a289c9e..3920eb37ce 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -430,6 +430,7 @@ extern AVCodec ff_dst_decoder;
extern AVCodec ff_eac3_encoder;
extern AVCodec ff_eac3_decoder;
extern AVCodec ff_evrc_decoder;
+extern AVCodec ff_fastaudio_decoder;
extern AVCodec ff_ffwavesynth_decoder;
extern AVCodec ff_flac_encoder;
extern AVCodec ff_flac_decoder;
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index b5bc5c3c71..9a3eaf7d98 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -3130,6 +3130,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("CRI HCA"),
.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
},
+{
+.id= AV_CODEC_ID_FASTAUDIO,
+.type = AVMEDIA_TYPE_AUDIO,
+.name = "fastaudio",
+.long_name = NULL_IF_CONFIG_SMALL("MobiClip FastAudio"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
+},
/* subtitle codecs */
{
diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index aac1174f28..aac7f63eb6 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -504,6 +504,7 @@ enum AVCodecID {
AV_CODEC_ID_MPEGH_3D_AUDIO,
AV_CODEC_ID_SIREN,
AV_CODEC_ID_HCA,
+AV_CODEC_ID_FASTAUDIO,
/* subtitle codecs */
AV_CODEC_ID_FIRST_SUBTITLE = 0x17000, ///< A dummy ID pointing at
the start of subtitle codecs.
diff --git a/libavcodec/fastaudio.c b/libavcodec/fastaudio.c
new file mode 100644
index 00..bd9e28ec0f
--- /dev/null
+++ b/libavcodec/fastaudio.c
@@ -0,0 +1,200 @@
+/*
+ * MOFLEX Fast Audio decoder
+ * Copyright (c) 2020 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/intreadwrite.h"
+
+#include "avcodec.h"
+#include "bytestream.h"
+#include "internal.h"
+#include "mathops.h"
+
+typedef struct ChannelItems {
+float f[8];
+float last;
+} ChannelItems;
+
+typedef struct FastAudioContext {
+float table[8][64];
+
+ChannelItems *ch;
+} FastAudioContext;
+
+static av_cold int fastaudio_init(AVCodecContext *avctx)
+{
+FastAudioContext *s = avctx->priv_data;
+
+avctx->sample_fmt = AV_SAMPLE_FMT_FLTP;
+
+for (int i = 0; i < 8; i++)
+s->table[0][i] = (i - 159.5f) / 160.f;
+for (int i = 0; i < 11; i++)
+s->table[0][i + 8] = (i - 37.5f) / 40.f;
+for (int i = 0; i < 27; i++)
+s->table[0][i + 8 + 11] = (i - 13.f) / 20.f;
+for (int i = 0; i < 11; i++)
+s->table[0][i + 8 + 11 + 27] = (i + 27.5f) / 40.f;
+for (int i = 0; i < 7; i++)
+s->table[0][i + 8 + 11 + 27 + 11] = (i + 152.5f) / 160.f;
+
+memcpy(s->table[1], s->table[0], sizeof(s->table[0]));
+
+for (int i = 0; i < 7; i++)
+s->table[2][i] = (i - 33.5f) / 40.f;
+for (int i = 0; i < 25; i++)
+s->table[2][i + 7] = (i - 13.f) / 20.f;
+
+for (int i = 0; i < 32; i++)
+s->table[3][i] = -s->table[2][31 - i];
+
+for (int i = 0; i < 16; i++)
+s->table[4][i] = i * 0.22f / 3.f - 0.6f;
+
+for (int i = 0; i < 16; i++)
+s->table[5][i] = i * 0.20f / 3.f - 0.3f;
+
+for (int
[FFmpeg-devel] [PATCH 3/5] avcodec: add MobiClip video decoder
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile |1 +
libavcodec/allcodecs.c |1 +
libavcodec/codec_desc.c |7 +
libavcodec/codec_id.h |1 +
libavcodec/mobiclip.c | 1427 +++
5 files changed, 1437 insertions(+)
create mode 100644 libavcodec/mobiclip.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 6f75f26c84..97fbe6b7a9 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -453,6 +453,7 @@ OBJS-$(CONFIG_MJPEG_VAAPI_ENCODER) +=
vaapi_encode_mjpeg.o
OBJS-$(CONFIG_MLP_DECODER) += mlpdec.o mlpdsp.o
OBJS-$(CONFIG_MLP_ENCODER) += mlpenc.o mlp.o
OBJS-$(CONFIG_MMVIDEO_DECODER) += mmvideo.o
+OBJS-$(CONFIG_MOBICLIP_DECODER)+= mobiclip.o
OBJS-$(CONFIG_MOTIONPIXELS_DECODER)+= motionpixels.o
OBJS-$(CONFIG_MOVTEXT_DECODER) += movtextdec.o ass.o
OBJS-$(CONFIG_MOVTEXT_ENCODER) += movtextenc.o ass_split.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 3920eb37ce..8a4b3fb178 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -186,6 +186,7 @@ extern AVCodec ff_mjpeg_encoder;
extern AVCodec ff_mjpeg_decoder;
extern AVCodec ff_mjpegb_decoder;
extern AVCodec ff_mmvideo_decoder;
+extern AVCodec ff_mobiclip_decoder;
extern AVCodec ff_motionpixels_decoder;
extern AVCodec ff_mpeg1video_encoder;
extern AVCodec ff_mpeg1video_decoder;
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 9a3eaf7d98..ceef244ebf 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1784,6 +1784,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("PFM (Portable FloatMap) image"),
.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
},
+{
+.id= AV_CODEC_ID_MOBICLIP,
+.type = AVMEDIA_TYPE_VIDEO,
+.name = "mobiclip",
+.long_name = NULL_IF_CONFIG_SMALL("MobiClip Video"),
+.props = AV_CODEC_PROP_LOSSY,
+},
/* various PCM "codecs" */
{
diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index aac7f63eb6..19d5014bb4 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -296,6 +296,7 @@ enum AVCodecID {
AV_CODEC_ID_MV30,
AV_CODEC_ID_NOTCHLC,
AV_CODEC_ID_PFM,
+AV_CODEC_ID_MOBICLIP,
/* various PCM "codecs" */
AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the
start of audio codecs
diff --git a/libavcodec/mobiclip.c b/libavcodec/mobiclip.c
new file mode 100644
index 00..175c5b86ae
--- /dev/null
+++ b/libavcodec/mobiclip.c
@@ -0,0 +1,1427 @@
+/*
+ * MobiClip Video decoder
+ * Copyright (c) 2017 Adib Surani
+ * Copyright (c) 2020 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+
+#include "libavutil/avassert.h"
+
+#include "avcodec.h"
+#include "bytestream.h"
+#include "bswapdsp.h"
+#include "get_bits.h"
+#include "golomb.h"
+#include "internal.h"
+
+static const uint8_t zigzag8x8_tab[] =
+{
+0x00, 0x01, 0x08, 0x10, 0x09, 0x02, 0x03, 0x0A, 0x11, 0x18, 0x20, 0x19,
+0x12, 0x0B, 0x04, 0x05, 0x0C, 0x13, 0x1A, 0x21, 0x28, 0x30, 0x29, 0x22,
+0x1B, 0x14, 0x0D, 0x06, 0x07, 0x0E, 0x15, 0x1C, 0x23, 0x2A, 0x31, 0x38,
+0x39, 0x32, 0x2B, 0x24, 0x1D, 0x16, 0x0F, 0x17, 0x1E, 0x25, 0x2C, 0x33,
+0x3A, 0x3B, 0x34, 0x2D, 0x26, 0x1F, 0x27, 0x2E, 0x35, 0x3C, 0x3D, 0x36,
+0x2F, 0x37, 0x3E, 0x3F
+};
+
+static const uint8_t zigzag4x4_tab[] =
+{
+0x00, 0x04, 0x01, 0x02, 0x05, 0x08, 0x0C, 0x09, 0x06, 0x03, 0x07, 0x0A,
+0x0D, 0x0E, 0x0B, 0x0F
+};
+
+static const uint8_t quant4x4_tab[][16] =
+{
+{ 10, 13, 13, 10, 16, 10, 13, 13, 13, 13, 16, 10, 16, 13, 13, 16 },
+{ 11, 14, 14, 11, 18, 11, 14, 14, 14, 14, 18, 11, 18, 14, 14, 18 },
+{ 13, 16, 16, 13, 20, 13, 16, 16, 16, 16, 20, 13, 20, 16, 16, 20 },
+{ 14, 18, 18, 14, 23, 14, 18, 18, 18, 18, 23, 14, 23, 18, 18, 23 },
+{ 16, 20, 20, 16, 25, 16, 20, 20, 20, 20, 25, 16, 25, 20, 20, 25 },
+{ 18, 23, 23, 18, 29, 18, 23, 23, 23, 23, 29, 18, 29, 23, 23, 29 },
+};
+
+static const uint8_t quant8x8_tab[][64] =
+{
+{ 20, 19, 19, 25, 18, 25, 19, 24, 24, 19, 20, 18, 32, 18, 20, 19, 19, 24,
[FFmpeg-devel] [PATCH 1/5] avcodec: add ADPCM IMA MOFLEX decoder
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/adpcm.c | 26 ++
libavcodec/allcodecs.c | 1 +
libavcodec/codec_desc.c | 7 +++
libavcodec/codec_id.h | 1 +
libavcodec/utils.c | 2 ++
6 files changed, 38 insertions(+)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index ca2e8a2530..191c4e0a7c 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -866,6 +866,7 @@ OBJS-$(CONFIG_ADPCM_IMA_DK4_DECODER) += adpcm.o
adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_EA_EACS_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_EA_SEAD_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_ISS_DECODER) += adpcm.o adpcm_data.o
+OBJS-$(CONFIG_ADPCM_IMA_MOFLEX_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_MTF_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_OKI_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_QT_DECODER) += adpcm.o adpcm_data.o
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index 1366932352..71e37efde7 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -210,6 +210,7 @@ static av_cold int adpcm_decode_init(AVCodecContext * avctx)
case AV_CODEC_ID_ADPCM_PSX:
case AV_CODEC_ID_ADPCM_MTAF:
case AV_CODEC_ID_ADPCM_ARGO:
+case AV_CODEC_ID_ADPCM_IMA_MOFLEX:
avctx->sample_fmt = AV_SAMPLE_FMT_S16P;
break;
case AV_CODEC_ID_ADPCM_IMA_WS:
@@ -774,6 +775,7 @@ static int get_nb_samples(AVCodecContext *avctx,
GetByteContext *gb,
case AV_CODEC_ID_ADPCM_4XM:
case AV_CODEC_ID_ADPCM_AGM:
case AV_CODEC_ID_ADPCM_IMA_DAT4:
+case AV_CODEC_ID_ADPCM_IMA_MOFLEX:
case AV_CODEC_ID_ADPCM_IMA_ISS: header_size = 4 * ch; break;
case AV_CODEC_ID_ADPCM_IMA_AMV: header_size = 8; break;
case AV_CODEC_ID_ADPCM_IMA_SMJPEG: header_size = 4 * ch; break;
@@ -1298,6 +1300,29 @@ static int adpcm_decode_frame(AVCodecContext *avctx,
void *data,
*samples++ = adpcm_ima_expand_nibble(&c->status[st], v2, 3);
}
break;
+case AV_CODEC_ID_ADPCM_IMA_MOFLEX:
+for (channel = 0; channel < avctx->channels; channel++) {
+cs = &c->status[channel];
+cs->step_index = sign_extend(bytestream2_get_le16u(&gb), 16);
+cs->predictor = sign_extend(bytestream2_get_le16u(&gb), 16);
+if (cs->step_index > 88u){
+av_log(avctx, AV_LOG_ERROR, "ERROR: step_index[%d] = %i\n",
+ channel, cs->step_index);
+return AVERROR_INVALIDDATA;
+}
+}
+
+for (int subframe = 0; subframe < nb_samples / 256; subframe++) {
+for (channel = 0; channel < avctx->channels; channel++) {
+samples = samples_p[channel] + 256 * subframe;
+for (n = 0; n < 256; n += 2) {
+int v = bytestream2_get_byteu(&gb);
+*samples++ = adpcm_ima_expand_nibble(&c->status[channel],
v & 0x0F, 3);
+*samples++ = adpcm_ima_expand_nibble(&c->status[channel],
v >> 4 , 3);
+}
+}
+}
+break;
case AV_CODEC_ID_ADPCM_IMA_DAT4:
for (channel = 0; channel < avctx->channels; channel++) {
cs = &c->status[channel];
@@ -2107,6 +2132,7 @@ ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_DK4,
sample_fmts_s16, adpcm_ima_dk4,
ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_EA_EACS, sample_fmts_s16,
adpcm_ima_ea_eacs, "ADPCM IMA Electronic Arts EACS");
ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_EA_SEAD, sample_fmts_s16,
adpcm_ima_ea_sead, "ADPCM IMA Electronic Arts SEAD");
ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_ISS, sample_fmts_s16, adpcm_ima_iss,
"ADPCM IMA Funcom ISS");
+ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_MOFLEX, sample_fmts_s16p,
adpcm_ima_moflex, "ADPCM IMA MobiClip MOFLEX");
ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_MTF, sample_fmts_s16, adpcm_ima_mtf,
"ADPCM IMA Capcom's MT Framework");
ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_OKI, sample_fmts_s16, adpcm_ima_oki,
"ADPCM IMA Dialogic OKI");
ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_QT, sample_fmts_s16p, adpcm_ima_qt,
"ADPCM IMA QuickTime");
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 729d2fd9ad..084a289c9e 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -619,6 +619,7 @@ extern AVCodec ff_adpcm_ima_dk4_decoder;
extern AVCodec ff_adpcm_ima_ea_eacs_decoder;
extern AVCodec ff_adpcm_ima_ea_sead_decoder;
extern AVCodec ff_adpcm_ima_iss_decoder;
+extern AVCodec ff_adpcm_ima_moflex_decoder;
extern AVCodec ff_adpcm_ima_mtf_decoder;
extern AVCodec ff_adpcm_ima_oki_decoder;
extern AVCodec ff_adpcm_ima_qt_encoder;
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 0ae6aee63b..b5bc5c3c71 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -2376,6 +2376,13 @@ static const AVCodecD
[FFmpeg-devel] [PATCH 4/5] avformat: add moflex demuxer
Signed-off-by: Paul B Mahol
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/moflex.c | 360 +++
3 files changed, 362 insertions(+)
create mode 100644 libavformat/moflex.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index cbb33fe37c..1e0ac317e5 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -319,6 +319,7 @@ OBJS-$(CONFIG_MLV_DEMUXER) += mlvdec.o
riffdec.o
OBJS-$(CONFIG_MM_DEMUXER)+= mm.o
OBJS-$(CONFIG_MMF_DEMUXER) += mmf.o
OBJS-$(CONFIG_MMF_MUXER) += mmf.o rawenc.o
+OBJS-$(CONFIG_MOFLEX_DEMUXER)+= moflex.o
OBJS-$(CONFIG_MOV_DEMUXER) += mov.o mov_chan.o mov_esds.o
replaygain.o
OBJS-$(CONFIG_MOV_MUXER) += movenc.o av1.o avc.o hevc.o vpcc.o
\
movenchint.o mov_chan.o rtp.o \
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0aa9dd7198..28331facb9 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -249,6 +249,7 @@ extern AVInputFormat ff_mlv_demuxer;
extern AVInputFormat ff_mm_demuxer;
extern AVInputFormat ff_mmf_demuxer;
extern AVOutputFormat ff_mmf_muxer;
+extern AVInputFormat ff_moflex_demuxer;
extern AVInputFormat ff_mov_demuxer;
extern AVOutputFormat ff_mov_muxer;
extern AVOutputFormat ff_mp2_muxer;
diff --git a/libavformat/moflex.c b/libavformat/moflex.c
new file mode 100644
index 00..989623396f
--- /dev/null
+++ b/libavformat/moflex.c
@@ -0,0 +1,360 @@
+/*
+ * MOFLEX demuxer
+ * Copyright (c) 2020 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavcodec/bytestream.h"
+
+#include "avformat.h"
+#include "internal.h"
+
+typedef struct BitReader {
+unsigned last;
+unsigned pos;
+} BitReader;
+
+typedef struct MOFLEXDemuxContext {
+unsigned size;
+int64_t pos;
+int64_t ts;
+int flags;
+int in_block;
+
+BitReader br;
+} MOFLEXDemuxContext;
+
+static int pop(BitReader *br, AVIOContext *pb)
+{
+if (avio_feof(pb))
+return AVERROR_EOF;
+
+if ((br->pos & 7) == 0)
+br->last = (unsigned)avio_r8(pb) << 24U;
+else
+br->last <<= 1;
+
+br->pos++;
+return !!(br->last & 0x8000);
+}
+
+static int pop_int(BitReader *br, AVIOContext *pb, int n)
+{
+int value = 0;
+
+for (int i = 0; i < n; i++) {
+int ret = pop(br, pb);
+
+if (ret < 0)
+return ret;
+value = 2 * value + ret;
+}
+
+return value;
+}
+
+static int pop_length(BitReader *br, AVIOContext *pb)
+{
+int ret, n = 1;
+
+while ((ret = pop(br, pb)) == 0)
+n++;
+
+if (ret < 0)
+return ret;
+return n;
+}
+
+static int read_var_byte(AVFormatContext *s, unsigned *out)
+{
+AVIOContext *pb = s->pb;
+unsigned value = 0, data;
+
+data = avio_r8(pb);
+if (!(data & 0x80)) {
+*out = data;
+return 0;
+}
+
+value = (data & 0x7F) << 7;
+data = avio_r8(pb);
+if (!(data & 0x80)) {
+value |= data;
+*out = value;
+return 0;
+}
+
+value = ((data & 0x7F) | value) << 7;
+data = avio_r8(pb);
+if (!(data & 0x80)) {
+value |= data;
+*out = value;
+return 0;
+}
+
+value = (((data & 0x7F) | value) << 7) | avio_r8(pb);
+*out = value;
+
+return 0;
+}
+
+static int moflex_probe(const AVProbeData *p)
+{
+GetByteContext gb;
+int score = 0;
+
+bytestream2_init(&gb, p->buf, p->buf_size);
+
+if (bytestream2_get_be16(&gb) != 0x4C32)
+return 0;
+score += 10;
+
+bytestream2_skip(&gb, 10);
+if (bytestream2_get_be16(&gb) == 0)
+return 0;
+score += 5;
+
+while (bytestream2_get_bytes_left(&gb) > 0) {
+int type = bytestream2_get_byte(&gb);
+int size = bytestream2_get_byte(&gb);
+
+if (type == 0) {
+score += 5 * (size == 0);
+break;
+}
+if ((type == 1 && size == 12) ||
+(type == 2 && size == 6) ||
+(type == 3 && size == 13) ||
+(type == 4 && size == 2))
+score += 20;
+bytestream2_skip(&gb, size)
[FFmpeg-devel] [PATCH 5/5] avformat: add MODS demuxer
Signed-off-by: Paul B Mahol
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/mods.c | 100 +++
3 files changed, 102 insertions(+)
create mode 100644 libavformat/mods.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 1e0ac317e5..7f852c05ff 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -319,6 +319,7 @@ OBJS-$(CONFIG_MLV_DEMUXER) += mlvdec.o
riffdec.o
OBJS-$(CONFIG_MM_DEMUXER)+= mm.o
OBJS-$(CONFIG_MMF_DEMUXER) += mmf.o
OBJS-$(CONFIG_MMF_MUXER) += mmf.o rawenc.o
+OBJS-$(CONFIG_MODS_DEMUXER) += mods.o
OBJS-$(CONFIG_MOFLEX_DEMUXER)+= moflex.o
OBJS-$(CONFIG_MOV_DEMUXER) += mov.o mov_chan.o mov_esds.o
replaygain.o
OBJS-$(CONFIG_MOV_MUXER) += movenc.o av1.o avc.o hevc.o vpcc.o
\
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 28331facb9..8a733b3f4d 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -249,6 +249,7 @@ extern AVInputFormat ff_mlv_demuxer;
extern AVInputFormat ff_mm_demuxer;
extern AVInputFormat ff_mmf_demuxer;
extern AVOutputFormat ff_mmf_muxer;
+extern AVInputFormat ff_mods_demuxer;
extern AVInputFormat ff_moflex_demuxer;
extern AVInputFormat ff_mov_demuxer;
extern AVOutputFormat ff_mov_muxer;
diff --git a/libavformat/mods.c b/libavformat/mods.c
new file mode 100644
index 00..4f093cdf0c
--- /dev/null
+++ b/libavformat/mods.c
@@ -0,0 +1,100 @@
+/*
+ * MODS demuxer
+ * Copyright (c) 2020 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/intreadwrite.h"
+
+#include "avformat.h"
+#include "internal.h"
+
+static int mods_probe(const AVProbeData *p)
+{
+if (memcmp(p->buf, "MODSN3\x0a\x00", 8))
+return 0;
+if (AV_RB32(p->buf + 8) == 0)
+return 0;
+if (AV_RB32(p->buf + 12) == 0)
+return 0;
+if (AV_RB32(p->buf + 16) == 0)
+return 0;
+return AVPROBE_SCORE_MAX;
+}
+
+static int mods_read_header(AVFormatContext *s)
+{
+AVIOContext *pb = s->pb;
+AVRational fps;
+int64_t pos;
+
+AVStream *st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+
+avio_skip(pb, 8);
+
+st->nb_frames= avio_rl32(pb);
+st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
+st->codecpar->codec_id = AV_CODEC_ID_MOBICLIP;
+st->codecpar->width = avio_rl32(pb);
+st->codecpar->height = avio_rl32(pb);
+
+fps.num = avio_rl32(pb);
+fps.den = 0x100;
+avpriv_set_pts_info(st, 64, fps.den, fps.num);
+
+avio_skip(pb, 16);
+
+pos = avio_rl32(pb) + 4;
+avio_seek(pb, pos, SEEK_SET);
+pos = avio_rl32(pb);
+avio_seek(pb, pos, SEEK_SET);
+
+return 0;
+}
+
+static int mods_read_packet(AVFormatContext *s, AVPacket *pkt)
+{
+AVIOContext *pb = s->pb;
+unsigned size;
+int64_t pos;
+int ret;
+
+if (avio_feof(pb))
+return AVERROR_EOF;
+
+pos = avio_tell(pb);
+size = avio_rl32(pb) >> 14;
+ret = av_get_packet(pb, pkt, size);
+pkt->pos = pos;
+pkt->stream_index = 0;
+pkt->flags |= AV_PKT_FLAG_KEY;
+
+return ret;
+}
+
+AVInputFormat ff_mods_demuxer = {
+.name = "mods",
+.long_name = NULL_IF_CONFIG_SMALL("MobiClip MODS"),
+.read_probe = mods_probe,
+.read_header= mods_read_header,
+.read_packet= mods_read_packet,
+.extensions = "mods",
+.flags = AVFMT_GENERIC_INDEX,
+};
--
2.17.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/wavdec: add support for chapters
Quoting Paul B Mahol (2020-08-31 14:20:11)
> Support parsing 'cue ' and 'adtl' chunks.
>
> Signed-off-by: Paul B Mahol
> ---
> libavformat/wavdec.c | 50
> 1 file changed, 50 insertions(+)
Looks ok beyond some nits.
>
> diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
> index 5b3c481421..545f04c742 100644
> --- a/libavformat/wavdec.c
> +++ b/libavformat/wavdec.c
> @@ -500,6 +500,7 @@ static int wav_read_header(AVFormatContext *s)
> wav->smv_cur_pt = 0;
> goto break_loop;
> case MKTAG('L', 'I', 'S', 'T'):
> +case MKTAG('l', 'i', 's', 't'):
> if (size < 4) {
> av_log(s, AV_LOG_ERROR, "too short LIST tag\n");
> return AVERROR_INVALIDDATA;
> @@ -507,6 +508,37 @@ static int wav_read_header(AVFormatContext *s)
> switch (avio_rl32(pb)) {
> case MKTAG('I', 'N', 'F', 'O'):
> ff_read_riff_info(s, size - 4);
> +break;
> +case MKTAG('a', 'd', 't', 'l'):
> +if (s->nb_chapters > 0) {
> +while (avio_tell(pb) < next_tag_ofs) {
> +AVChapter *chapter = NULL;
> +char cue_label[512];
> +unsigned id, sub_size;
> +
> +if (avio_feof(pb))
> +break;
nit: would look better in the loop condition
> +if (avio_rl32(pb) != MKTAG('l', 'a', 'b', 'l'))
> +break;
> +
> +sub_size = avio_rl32(pb);
> +if (sub_size < 5)
> +break;
> +id = avio_rl32(pb);
> +avio_get_str(pb, sub_size - 4, cue_label,
> sizeof(cue_label));
> +avio_skip(pb, avio_tell(pb) & 1);
> +
> +for (int i = 0; i < s->nb_chapters; i++) {
> +if (s->chapters[i]->id == id) {
> +chapter = s->chapters[i];
> +break;
> +}
> +}
> +if (chapter)
> +av_dict_set(&chapter->metadata, "title",
> cue_label, 0);
nit: could be merged into the loop above
--
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".
Re: [FFmpeg-devel] [PATCH] avformat/wavdec: add support for chapters
Quoting Paul B Mahol (2020-08-31 14:20:11) > Support parsing 'cue ' and 'adtl' chunks. > > Signed-off-by: Paul B Mahol > --- > libavformat/wavdec.c | 50 > 1 file changed, 50 insertions(+) Also, FATE tests would be nice. -- 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".
Re: [FFmpeg-devel] [PATCH] avcodec/encode: unref the packet on AVCodec.receive_packet() failure
Quoting James Almer (2020-08-31 04:59:54) > Fixes memleaks with some encoders that don't unref the packet before > returning. > This is consistent with the behavior of AVCodec.encode() > implementations in encode_simple_internal(). > > Found-by: mkver > Signed-off-by: James Almer > --- > libavcodec/encode.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Looks ok. -- 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".
Re: [FFmpeg-devel] [PATCH] avformat/wavdec: add support for chapters
On 9/1/20, Anton Khirnov wrote:
> Quoting Paul B Mahol (2020-08-31 14:20:11)
>> Support parsing 'cue ' and 'adtl' chunks.
>>
>> Signed-off-by: Paul B Mahol
>> ---
>> libavformat/wavdec.c | 50
>> 1 file changed, 50 insertions(+)
>
> Looks ok beyond some nits.
>
>>
>> diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
>> index 5b3c481421..545f04c742 100644
>> --- a/libavformat/wavdec.c
>> +++ b/libavformat/wavdec.c
>> @@ -500,6 +500,7 @@ static int wav_read_header(AVFormatContext *s)
>> wav->smv_cur_pt = 0;
>> goto break_loop;
>> case MKTAG('L', 'I', 'S', 'T'):
>> +case MKTAG('l', 'i', 's', 't'):
>> if (size < 4) {
>> av_log(s, AV_LOG_ERROR, "too short LIST tag\n");
>> return AVERROR_INVALIDDATA;
>> @@ -507,6 +508,37 @@ static int wav_read_header(AVFormatContext *s)
>> switch (avio_rl32(pb)) {
>> case MKTAG('I', 'N', 'F', 'O'):
>> ff_read_riff_info(s, size - 4);
>> +break;
>> +case MKTAG('a', 'd', 't', 'l'):
>> +if (s->nb_chapters > 0) {
>> +while (avio_tell(pb) < next_tag_ofs) {
>> +AVChapter *chapter = NULL;
>> +char cue_label[512];
>> +unsigned id, sub_size;
>> +
>> +if (avio_feof(pb))
>> +break;
>
> nit: would look better in the loop condition
Done.
>
>> +if (avio_rl32(pb) != MKTAG('l', 'a', 'b', 'l'))
>> +break;
>> +
>> +sub_size = avio_rl32(pb);
>> +if (sub_size < 5)
>> +break;
>> +id = avio_rl32(pb);
>> +avio_get_str(pb, sub_size - 4, cue_label,
>> sizeof(cue_label));
>> +avio_skip(pb, avio_tell(pb) & 1);
>> +
>> +for (int i = 0; i < s->nb_chapters; i++) {
>> +if (s->chapters[i]->id == id) {
>> +chapter = s->chapters[i];
>> +break;
>> +}
>> +}
>> +if (chapter)
>> +av_dict_set(&chapter->metadata, "title",
>> cue_label, 0);
>
> nit: could be merged into the loop above
Done.
Also fixed size check to not ignore 4 read bytes, and applied.
Thanks.
>
> --
> 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] [PATCH] avcodec/encode: unref the packet on AVCodec.receive_packet() failure
On 9/1/2020 9:14 AM, Anton Khirnov wrote: > Quoting James Almer (2020-08-31 04:59:54) >> Fixes memleaks with some encoders that don't unref the packet before >> returning. >> This is consistent with the behavior of AVCodec.encode() >> implementations in encode_simple_internal(). >> >> Found-by: mkver >> Signed-off-by: James Almer >> --- >> libavcodec/encode.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) > > Looks ok. Applied, 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] Support HDR10+ metadata for HEVC.
> On 12 Aug 2020, at 21:58, Vittorio Giovara wrote: > > On Wed, Aug 12, 2020 at 6:40 PM Mohammad Izadi wrote: > >> Vittorio, >> >> What is the next step for me? >> >> Thanks, >> Mohammad >> > > Hi, I don't have any more comments for the patch, except that it would be > nice if there were some kind of fate testing. > See for example cf1cae58b015427918ecfa507a045aae4cf398fd, which is > similarly exporting metadata information from an input file to stdout. > The test will make sure that future changes won't break this functionality. So are we waiting on a small file size example to be added to fate? Or is there something else required here? I am also interested in HDR10+ and could help trying patches out. Harry ___ 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] request to upload sample
Hi. Please upload this file to FATE servers. http://trac.ffmpeg.org/raw-attachment/ticket/8872/200828-005.wav Will add chapter/cue test later. ___ 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][GSoC] Add mutithread function for dnn_backend_native_layer_conv2d.c
Hi, Mark - Original Message - > From: "Mark Thompson" > To: "FFmpeg development discussions and patches" > Sent: Tuesday, September 1, 2020 4:41:06 AM > Subject: Re: [FFmpeg-devel] [PATCH 1/3][GSoC] Add mutithread function for > dnn_backend_native_layer_conv2d.c > On 31/08/2020 18:03, xuju...@sjtu.edu.cn wrote: >> From: Xu Jun >> >> Use pthread to multithread dnn_execute_layer_conv2d. >> Can be tested with command "./ffmpeg_g -i input.png -vf \ >> format=yuvj420p,dnn_processing=dnn_backend=native:model= \ >> espcn.model:input=x:output=y -y sr_native.jpg -benchmark" >> >> before patch: utime=11.238s stime=0.005s rtime=11.248s >> after patch: utime=20.817s stime=0.047s rtime=1.051s > > Can you explain why it uses almost twice as much total CPU time after the > patch? > That seems rather more than can be explained away as scheduling overhead. > > If it's actually doing significantly more then maybe you want to document > somewhere that enabling threading will improve latency at the cost of > throughput. I have done some test and find that utime is strongly correlated with CPU HyperThreading technology. When I turn off my CPU HyperThreading technology using command "echo off > /sys/devices/system/cpu/smt/control" in root user, the utime gets stable whatever the number of threads I have created, and is same to that before patch. When CPU HyperThreading technology is on, once the number of threads I create gets close to physical cores' number my cpu has, or even bigger, the utime will get bigger simultaneously. When I use as many threads as the logical cores' number of my cpu, the utime will be twice of that before patch. Therefore, I think HyperThreading technology make the logical cores twice the physical cores while the counting power is not twiced. And for ffmpeg utime, it sums all logical cores' runtime. So it seems to be twice of that before patch. In the next version, I will open an API for user to choose how many threads to use in native backend. And I'm going to set the default threads number to physical cores' number - 1 in order to get better performance while not increasing utime much on the plantforms which support HyperThreading. As for the rtime, setting threads' number to logical cores - 1 will get about 20%-30% performance improvement over setting threads' number to physical cores - 1 in my test. - Xu Jun > > - Mark > ___ > 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] Support HDR10+ metadata for HEVC.
On Tue, Sep 1, 2020 at 5:22 PM Harry Mallon wrote: > > > > > > On 12 Aug 2020, at 21:58, Vittorio Giovara > > wrote: > > > > On Wed, Aug 12, 2020 at 6:40 PM Mohammad Izadi wrote: > > > >> Vittorio, > >> > >> What is the next step for me? > >> > >> Thanks, > >> Mohammad > >> > > > > Hi, I don't have any more comments for the patch, except that it would be > > nice if there were some kind of fate testing. > > See for example cf1cae58b015427918ecfa507a045aae4cf398fd, which is > > similarly exporting metadata information from an input file to stdout. > > The test will make sure that future changes won't break this functionality. > > So are we waiting on a small file size example to be added to fate? Or is > there something else required here? I am also interested in HDR10+ and could > help trying patches out. > > Harry > Hi, I think the steps would be: - Generate a FATE sample & test for the parsing (dumping the side data for a couple of packets) - Any final review. I will also attempt to take a look at the patch set itself during the week-end at the latest. It's been on my go-to list for a while but unfortunately I've not been able to dedicate it time yet. Jan ___ 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][GSoC] Add mutithread function for dnn_backend_native_layer_conv2d.c
On 9/1/20, Xu Jun wrote: > Hi, Mark > > - Original Message - >> From: "Mark Thompson" >> To: "FFmpeg development discussions and patches" >> Sent: Tuesday, September 1, 2020 4:41:06 AM >> Subject: Re: [FFmpeg-devel] [PATCH 1/3][GSoC] Add mutithread function for >> dnn_backend_native_layer_conv2d.c > >> On 31/08/2020 18:03, xuju...@sjtu.edu.cn wrote: >>> From: Xu Jun >>> >>> Use pthread to multithread dnn_execute_layer_conv2d. >>> Can be tested with command "./ffmpeg_g -i input.png -vf \ >>> format=yuvj420p,dnn_processing=dnn_backend=native:model= \ >>> espcn.model:input=x:output=y -y sr_native.jpg -benchmark" >>> >>> before patch: utime=11.238s stime=0.005s rtime=11.248s >>> after patch: utime=20.817s stime=0.047s rtime=1.051s >> >> Can you explain why it uses almost twice as much total CPU time after the >> patch? >> That seems rather more than can be explained away as scheduling overhead. >> >> If it's actually doing significantly more then maybe you want to document >> somewhere that enabling threading will improve latency at the cost of >> throughput. > > I have done some test and find that utime is strongly correlated with CPU > HyperThreading technology. > > When I turn off my CPU HyperThreading technology using command "echo off > > /sys/devices/system/cpu/smt/control" in root user, the utime gets stable > whatever the number of threads I have created, and is same to that before > patch. > > When CPU HyperThreading technology is on, once the number of threads I > create gets close to physical cores' number my cpu has, or even bigger, the > utime will get bigger simultaneously. When I use as many threads as the > logical cores' number of my cpu, the utime will be twice of that before > patch. > > Therefore, I think HyperThreading technology make the logical cores twice > the physical cores while the counting power is not twiced. And for ffmpeg > utime, it sums all logical cores' runtime. So it seems to be twice of that > before patch. > > In the next version, I will open an API for user to choose how many threads > to use in native backend. And I'm going to set the default threads number to > physical cores' number - 1 in order to get better performance while not > increasing utime much on the plantforms which support HyperThreading. -threads option is already available for filters that use slice threads. Make sure that your threads do not share same memory for reading/writting. > > As for the rtime, setting threads' number to logical cores - 1 will get > about 20%-30% performance improvement over setting threads' number to > physical cores - 1 in my test. > > - Xu Jun > >> >> - Mark >> ___ >> 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 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 4/4] avformat/mov: Stash mfra size if we're reading it anyway
This also changes a check for mfra_size from < 0 to == 0, since
it was always wrong, as avio_rb32 returns an unsigned integer.
Signed-off-by: Derek Buitenhuis
---
libavformat/mov.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index e33031f158..e901eb527f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -7499,22 +7499,22 @@ static int mov_read_mfra(MOVContext *c, AVIOContext *f)
int64_t stream_size = avio_size(f);
int64_t original_pos = avio_tell(f);
int64_t seek_ret;
-int32_t mfra_size;
int ret = -1;
if ((seek_ret = avio_seek(f, stream_size - 4, SEEK_SET)) < 0) {
ret = seek_ret;
goto fail;
}
-mfra_size = avio_rb32(f);
-if (mfra_size < 0 || mfra_size > stream_size) {
+c->mfra_size = avio_rb32(f);
+c->have_read_mfra_size = 1;
+if (c->mfra_size == 0 || c->mfra_size > stream_size) {
av_log(c->fc, AV_LOG_DEBUG, "doesn't look like mfra (unreasonable
size)\n");
goto fail;
}
-if ((seek_ret = avio_seek(f, -mfra_size, SEEK_CUR)) < 0) {
+if ((seek_ret = avio_seek(f, -c->mfra_size, SEEK_CUR)) < 0) {
ret = seek_ret;
goto fail;
}
-if (avio_rb32(f) != mfra_size) {
+if (avio_rb32(f) != c->mfra_size) {
av_log(c->fc, AV_LOG_DEBUG, "doesn't look like mfra (size
mismatch)\n");
goto fail;
}
--
2.28.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] [PATCH 2/4] avformat/mov: Do not try and seek to an mfra if the reader can't seek
Signed-off-by: Derek Buitenhuis
---
libavformat/mov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index f0b4edc2ed..49c2d05d21 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5094,7 +5094,7 @@ static int mov_read_sidx(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
// See if the remaining bytes are just an mfra which we can ignore.
is_complete = offset == stream_size;
-if (!is_complete) {
+if (!is_complete && (pb->seekable & AVIO_SEEKABLE_NORMAL)) {
int64_t ret;
int64_t original_pos = avio_tell(pb);
int32_t mfra_size;
--
2.28.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] [PATCH 3/4] avformat/mov: Only read the mfra size once during sidx parsing
On files with more than one sidx box, like live fragmented MP4
files, it was previously re-reading and seeking on every singl
sidx box, leading to extremely poor performance on larger files,
especially over the network.
Only do it on the first one, and stash its result.
Signed-off-by: Derek Buitenhuis
---
libavformat/isom.h | 2 ++
libavformat/mov.c | 16 +---
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 41a9c64c11..78495fd336 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -291,6 +291,8 @@ typedef struct MOVContext {
int decryption_key_len;
int enable_drefs;
int32_t movie_display_matrix[3][3]; ///< display matrix from mvhd
+int have_read_mfra_size;
+uint32_t mfra_size;
} MOVContext;
int ff_mp4_read_descr_len(AVIOContext *pb);
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 49c2d05d21..e33031f158 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5097,14 +5097,16 @@ static int mov_read_sidx(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
if (!is_complete && (pb->seekable & AVIO_SEEKABLE_NORMAL)) {
int64_t ret;
int64_t original_pos = avio_tell(pb);
-int32_t mfra_size;
-if ((ret = avio_seek(pb, stream_size - 4, SEEK_SET)) < 0)
-return ret;
-mfra_size = avio_rb32(pb);
-if (offset + mfra_size == stream_size)
+if (!c->have_read_mfra_size) {
+if ((ret = avio_seek(pb, stream_size - 4, SEEK_SET)) < 0)
+return ret;
+c->mfra_size = avio_rb32(pb);
+c->have_read_mfra_size = 1;
+if ((ret = avio_seek(pb, original_pos, SEEK_SET)) < 0)
+return ret;
+}
+if (offset + c->mfra_size == stream_size)
is_complete = 1;
-if ((ret = avio_seek(pb, original_pos, SEEK_SET)) < 0)
-return ret;
}
if (is_complete) {
--
2.28.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 0/2] avcodec/decode: use a packet list for last_pkt_props
On 8/18/2020 4:53 PM, James Almer wrote: > More details within each patch. > > James Almer (2): > avcodec/packet: move AVPacketList definition and function helpers over > from libavformat > avcodec/decode: use a packet list to store copies of packets fed to > the decoder > > libavcodec/avpacket.c| 64 ++ > libavcodec/decode.c | 34 ++ > libavcodec/internal.h| 2 + > libavcodec/packet.h | 5 ++ > libavcodec/packet_internal.h | 45 ++ > libavcodec/utils.c | 3 ++ > libavformat/aiffenc.c| 5 +- > libavformat/avformat.h | 6 --- > libavformat/flacenc.c| 7 +-- > libavformat/internal.h | 42 - > libavformat/matroskadec.c| 11 +++-- > libavformat/mp3enc.c | 7 +-- > libavformat/ttaenc.c | 7 +-- > libavformat/utils.c | 88 ++-- > 14 files changed, 178 insertions(+), 148 deletions(-) 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".
[FFmpeg-devel] [PATCH 1/4] avformat/mov: Fix return type used for av_seek in mfra code
It should be a 64-bit integer, otherwise it overflows and fails
on files greater than 2GB on some systems like x86_64 Linux.
Signed-off-by: Derek Buitenhuis
---
libavformat/mov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index dcec74662d..f0b4edc2ed 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5095,7 +5095,7 @@ static int mov_read_sidx(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
// See if the remaining bytes are just an mfra which we can ignore.
is_complete = offset == stream_size;
if (!is_complete) {
-int ret;
+int64_t ret;
int64_t original_pos = avio_tell(pb);
int32_t mfra_size;
if ((ret = avio_seek(pb, stream_size - 4, SEEK_SET)) < 0)
--
2.28.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 4/4] avformat/mov: Stash mfra size if we're reading it anyway
On 9/1/2020 12:03 PM, Derek Buitenhuis wrote:
> This also changes a check for mfra_size from < 0 to == 0, since
> it was always wrong, as avio_rb32 returns an unsigned integer.
mfra_size in this function was an int32_t, so storing the output of
avio_rb32() could end up with a negative value.
It'll no longer be the case now that you made mfra_size in MOVContext an
uint32_t.
>
> Signed-off-by: Derek Buitenhuis
> ---
> libavformat/mov.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index e33031f158..e901eb527f 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -7499,22 +7499,22 @@ static int mov_read_mfra(MOVContext *c, AVIOContext
> *f)
> int64_t stream_size = avio_size(f);
> int64_t original_pos = avio_tell(f);
> int64_t seek_ret;
> -int32_t mfra_size;
> int ret = -1;
> if ((seek_ret = avio_seek(f, stream_size - 4, SEEK_SET)) < 0) {
> ret = seek_ret;
> goto fail;
> }
> -mfra_size = avio_rb32(f);
> -if (mfra_size < 0 || mfra_size > stream_size) {
> +c->mfra_size = avio_rb32(f);
> +c->have_read_mfra_size = 1;
> +if (c->mfra_size == 0 || c->mfra_size > stream_size) {
nit: !c->mfra_size.
> av_log(c->fc, AV_LOG_DEBUG, "doesn't look like mfra (unreasonable
> size)\n");
> goto fail;
> }
> -if ((seek_ret = avio_seek(f, -mfra_size, SEEK_CUR)) < 0) {
> +if ((seek_ret = avio_seek(f, -c->mfra_size, SEEK_CUR)) < 0) {
You may have to cast c->mfra_size to int64_t before negating it, or use
a local int64_t variable.
> ret = seek_ret;
> goto fail;
> }
> -if (avio_rb32(f) != mfra_size) {
> +if (avio_rb32(f) != c->mfra_size) {
> av_log(c->fc, AV_LOG_DEBUG, "doesn't look like mfra (size
> mismatch)\n");
> goto fail;
> }
>
___
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] avformat/mov: Stash mfra size if we're reading it anyway
On 01/09/2020 16:36, James Almer wrote: > mfra_size in this function was an int32_t, so storing the output of > avio_rb32() could end up with a negative value. > It'll no longer be the case now that you made mfra_size in MOVContext an > uint32_t. How was that ever valid in the first place, considering avio_rb32 returns an unsigned 32-bit integer? - Derek ___ 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/4] avformat/mov: Do not try and seek to an mfra if the reader can't seek
On 9/1/2020 12:03 PM, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis
> ---
> libavformat/mov.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index f0b4edc2ed..49c2d05d21 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -5094,7 +5094,7 @@ static int mov_read_sidx(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
>
> // See if the remaining bytes are just an mfra which we can ignore.
> is_complete = offset == stream_size;
> -if (!is_complete) {
> +if (!is_complete && (pb->seekable & AVIO_SEEKABLE_NORMAL)) {
LGTM.
> int64_t ret;
> int64_t original_pos = avio_tell(pb);
> int32_t mfra_size;
>
___
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] avformat/mov: Stash mfra size if we're reading it anyway
On 9/1/2020 12:49 PM, Derek Buitenhuis wrote: > On 01/09/2020 16:36, James Almer wrote: >> mfra_size in this function was an int32_t, so storing the output of >> avio_rb32() could end up with a negative value. >> It'll no longer be the case now that you made mfra_size in MOVContext an >> uint32_t. > > How was that ever valid in the first place, considering avio_rb32 returns an > unsigned 32-bit integer? How else would you read 32bit signed integers using AVIOContext function helpers if not with avio_rb32()? > > - Derek > ___ > 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] avformat/mov: Stash mfra size if we're reading it anyway
On 01/09/2020 17:02, James Almer wrote:
> How else would you read 32bit signed integers using AVIOContext function
> helpers if not with avio_rb32()?
The mfra size is not signed. It is an unsigned 32-bit integer.
Spec (mfro is the last part of the mfra):
aligned(8) class MovieFragmentRandomAccessOffsetBox
extends FullBox(‘mfro’, version, 0) {
unsigned int(32) size;
}
- Derek
___
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] avformat/mov: Stash mfra size if we're reading it anyway
On 9/1/2020 1:06 PM, Derek Buitenhuis wrote:
> On 01/09/2020 17:02, James Almer wrote:
>> How else would you read 32bit signed integers using AVIOContext function
>> helpers if not with avio_rb32()?
>
> The mfra size is not signed. It is an unsigned 32-bit integer.
>
> Spec (mfro is the last part of the mfra):
>
> aligned(8) class MovieFragmentRandomAccessOffsetBox
> extends FullBox(‘mfro’, version, 0) {
> unsigned int(32) size;
> }
>
> - Derek
Oh, you mean how it worked with mfra_size being declared as an int32_t.
I was just mentioning why there was a <= 0 check for it. And I guess
because no mfra box parsed by lavf was ever bigger than ~2gb, so it
never failed.
But yes, it was a bug that you're fixing in this set.
(For that matter, size could in theory also be a 64bit integer according
to the spec).
___
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] avformat/mov: Stash mfra size if we're reading it anyway
On 01/09/2020 17:11, James Almer wrote: > Oh, you mean how it worked with mfra_size being declared as an int32_t. > I was just mentioning why there was a <= 0 check for it. And I guess > because no mfra box parsed by lavf was ever bigger than ~2gb, so it > never failed. > But yes, it was a bug that you're fixing in this set. Yep, apologies if I was not clear. > (For that matter, size could in theory also be a 64bit integer according > to the spec). It cannot, as far as I can tell. The 'size' entry in the mfra box is a separate member from the normal box size, and is always 32-bits, so that you know to seek to END-4. - Derek ___ 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] avformat/mov: Stash mfra size if we're reading it anyway
On 9/1/2020 1:14 PM, Derek Buitenhuis wrote: > On 01/09/2020 17:11, James Almer wrote: >> Oh, you mean how it worked with mfra_size being declared as an int32_t. >> I was just mentioning why there was a <= 0 check for it. And I guess >> because no mfra box parsed by lavf was ever bigger than ~2gb, so it >> never failed. >> But yes, it was a bug that you're fixing in this set. > > Yep, apologies if I was not clear. > >> (For that matter, size could in theory also be a 64bit integer according >> to the spec). > > It cannot, as far as I can tell. The 'size' entry in the mfra box is a > separate > member from the normal box size, and is always 32-bits, so that you know to > seek to END-4. Right, this is a field in mfro and not the mfra Box size. Nevermind then. > > - Derek > > ___ > 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 4/4 v2] avformat/mov: Stash mfra size if we're reading it anyway
This also changes a check for mfra_size from < 0 to == 0, since
it was always wrong, as avio_rb32 returns an unsigned integer.
Signed-off-by: Derek Buitenhuis
---
Applied both of James' review comments.
---
libavformat/mov.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index e33031f158..690beb10ce 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -7499,22 +7499,22 @@ static int mov_read_mfra(MOVContext *c, AVIOContext *f)
int64_t stream_size = avio_size(f);
int64_t original_pos = avio_tell(f);
int64_t seek_ret;
-int32_t mfra_size;
int ret = -1;
if ((seek_ret = avio_seek(f, stream_size - 4, SEEK_SET)) < 0) {
ret = seek_ret;
goto fail;
}
-mfra_size = avio_rb32(f);
-if (mfra_size < 0 || mfra_size > stream_size) {
+c->mfra_size = avio_rb32(f);
+c->have_read_mfra_size = 1;
+if (!c->mfra_size || c->mfra_size > stream_size) {
av_log(c->fc, AV_LOG_DEBUG, "doesn't look like mfra (unreasonable
size)\n");
goto fail;
}
-if ((seek_ret = avio_seek(f, -mfra_size, SEEK_CUR)) < 0) {
+if ((seek_ret = avio_seek(f, -((int64_t) c->mfra_size), SEEK_CUR)) < 0) {
ret = seek_ret;
goto fail;
}
-if (avio_rb32(f) != mfra_size) {
+if (avio_rb32(f) != c->mfra_size) {
av_log(c->fc, AV_LOG_DEBUG, "doesn't look like mfra (size
mismatch)\n");
goto fail;
}
--
2.28.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 1/2][RFC] avcodec/packet: move AVPacketList definition and function helpers over from libavformat
James Almer:
> Signed-off-by: James Almer
> ---
> Not making these public because someone mentioned that the current signature
> for these helpers was ugly (two AVPacketList pointers the caller needs to keep
> around to track the list), and changing it would either require modifying a
> public struct, introducing a new one, or making incredibly inefficient
> function
> helpers that navigate the entire list to reach the end every time a new entry
> is
> added.
>
> A possible approach could be something like:
>
> [libavcodec/packet.h]
> typedef struct AVPacketList AVPacketList; // Opaque struct, API change
>
> [libavcodec/packet_internal.h]
> typedef struct PacketListEntry {
> AVPacket pkt;
> struct PacketListEntry *next;
> } PacketListEntry; // Essentially what's currently AVPacketList
>
> struct AVPacketList {
> PacketListEntry *head;
> PacketListEntry *tail;
> };
>
> AVPacketList *avpriv_packet_list_alloc(void);
> int av_packet_list_put(AVPacketList *pktl, AVPacket *pkt, int flags);
> int av_packet_list_get(AVPacketList *pktl, AVPacket *pkt);
> int av_packet_list_peek(AVPacketList *pktl, AVPacket *pkt);
> void av_packet_list_free(AVPacketList **pktl);
>
> But special care would need to be given to some lists used in
> libavformat/mux.c and libavformat/utils.c, one of which is even exposed in
> avformat.h
The last_in_packet_buffer is not part of the public API and could be
moved to AVStreamInternal (AVStream is currently kind of broken: ffmpeg
(the cli tool) accesses several of its internal fields (pts_wrap_bits,
first_dts, cur_dts, codec_info_nb_frames), so that one can not even add
new public fields to it; yet last_in_packet_buffer is after these three
elemts, so it could be moved); yet this very pointer to an AVPacketList
is special because it is not one of a heads+tails combination, but just
a pointer in the middle of this list; so it just doesn't work with your
proposal.
(The muxing queue itself is special because (afaik) it is the only queue
where new elements are added in the middle. (Has it actually ever been
tested whether it would be advantageouos to have one list for each
stream and just inspect each of these lists every time one wants to mux
a packet?))
>
> Also, I'd rather not bikeshed too much about this API for the sake of the
> following patch.
>
> libavcodec/avpacket.c| 64 ++
> libavcodec/packet.h | 5 ++
> libavcodec/packet_internal.h | 45 ++
> libavformat/aiffenc.c| 5 +-
> libavformat/avformat.h | 6 ---
> libavformat/flacenc.c| 7 +--
> libavformat/internal.h | 42 -
> libavformat/matroskadec.c| 11 +++--
> libavformat/mp3enc.c | 7 +--
> libavformat/ttaenc.c | 7 +--
> libavformat/utils.c | 88 ++--
> 11 files changed, 148 insertions(+), 139 deletions(-)
>
> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> index 4801163227..473ce01227 100644
> --- a/libavcodec/avpacket.c
> +++ b/libavcodec/avpacket.c
> @@ -726,6 +726,70 @@ FF_ENABLE_DEPRECATION_WARNINGS
> #endif
> }
>
> +int avpriv_packet_list_put(AVPacketList **packet_buffer,
> + AVPacketList **plast_pktl,
> + AVPacket *pkt, int flags)
> +{
> +AVPacketList *pktl = av_mallocz(sizeof(AVPacketList));
> +int ret;
> +
> +if (!pktl)
> +return AVERROR(ENOMEM);
> +
> +if (flags & FF_PACKETLIST_FLAG_REF_PACKET) {
> +if ((ret = av_packet_ref(&pktl->pkt, pkt)) < 0) {
> +av_free(pktl);
> +return ret;
> +}
> +} else {
> +ret = av_packet_make_refcounted(pkt);
> +if (ret < 0) {
> +av_free(pktl);
> +return ret;
> +}
> +av_packet_move_ref(&pktl->pkt, pkt);
> +}
> +
> +if (*packet_buffer)
> +(*plast_pktl)->next = pktl;
> +else
> +*packet_buffer = pktl;
> +
> +/* Add the packet in the buffered packet list. */
> +*plast_pktl = pktl;
> +return 0;
> +}
> +
> +int avpriv_packet_list_get(AVPacketList **pkt_buffer,
> + AVPacketList **pkt_buffer_end,
> + AVPacket *pkt)
> +{
> +AVPacketList *pktl;
> +if (!*pkt_buffer)
> +return AVERROR(EAGAIN);
> +pktl= *pkt_buffer;
> +*pkt= pktl->pkt;
> +*pkt_buffer = pktl->next;
> +if (!pktl->next)
> +*pkt_buffer_end = NULL;
> +av_freep(&pktl);
> +return 0;
> +}
> +
> +void avpriv_packet_list_free(AVPacketList **pkt_buf, AVPacketList
> **pkt_buf_end)
> +{
> +AVPacketList *tmp = *pkt_buf;
> +
> +while (tmp) {
> +AVPacketList *pktl = tmp;
> +tmp = pktl->next;
> +av_packet_unref(&pktl->pkt);
> +av_freep(&pktl);
> +}
> +*pkt_buf = NULL;
> +*pkt_buf_end = NULL;
> +}
> +
> int ff_side_data_set_encoder_stats(AVPacket *pkt, int
Re: [FFmpeg-devel] libopenjpeg decoder not correctly setting the pixel format for cinema JP2K wrapped MXF
Am Di., 1. Sept. 2020 um 12:14 Uhr schrieb Rémi Achard : > > > Do you have a sample that does not work with the native decoder? > > According to my tests, the native decoder detect pixel format just fine So what problem do you see? Yes, we prefer using the native codecs over external dependencies. You can force the pix_fmt, Carl Eugen ___ 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][RFC] avcodec/packet: move AVPacketList definition and function helpers over from libavformat
On 9/1/2020 2:00 PM, Andreas Rheinhardt wrote: > James Almer: >> diff --git a/libavcodec/packet_internal.h b/libavcodec/packet_internal.h >> index cdb9a27f2f..387b63169a 100644 >> --- a/libavcodec/packet_internal.h >> +++ b/libavcodec/packet_internal.h >> @@ -23,6 +23,51 @@ >> >> #include "packet.h" >> >> + >> +/** Create a new reference for the packet instead of >> + * transferring the ownership of the existing one to the >> + * list. >> + */ >> +#define FF_PACKETLIST_FLAG_REF_PACKET (1 << 0) >> + >> +/** >> + * Append an AVPacket to the list. >> + * >> + * @param head List head element >> + * @param tail List tail element >> + * @param pkt The packet being appended. The data described in it will >> + * be made reference counted if it isn't already. >> + * @param flags Any combination of FF_PACKETLIST_FLAG_* flags >> + * @return 0 on success, negative AVERROR value on failure. On failure, >> + the list is unchanged >> + */ >> +int avpriv_packet_list_put(AVPacketList **head, AVPacketList **tail, >> + AVPacket *pkt, int flags); >> + >> +/** >> + * Remove the oldest AVPacket in the list and return it. >> + * >> + * @note The pkt will be overwritten completely on success. The caller >> + * owns the packet and must unref it by itself. >> + * >> + * @param head List head element >> + * @param tail List tail element >> + * @param pkt Pointer to an AVPacket struct >> + * @return 0 on success. AVERROR(EAGAIN) if nothing is returned. Another >> + * negative AVERROR code on failure. On failure, the list is >> + * unchanged > > I really dislike that you are removing the guarantee that one can always > remove a packet from a list if the list is not empty. This means that > one would now have to add unnecessary checks to several existing callers > of this function. > > Furthermore, your wording is weird: If nothing is returned, the return > value is AVERROR(EAGAIN). This implies that if some other AVERROR code > were to be returned, something is returned, i.e. the packet will be changed. I can remove the "another negative AVERROR" part. Just added it for the sake of being extensible, but since it's private it doesn't matter. And sure, can also change the EAGAIN part so it's clear what it means. ___ 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] libopenjpeg decoder not correctly setting the pixel format for cinema JP2K wrapped MXF
> So what problem do you see? > Yes, we prefer using the native codecs over external dependencies. ffmpeg -v debug -vcodec libopenjpeg -i ~/Projects/ClairMeta/tests/resources/DCP/ECL-SET/ECL07-SINGLE-CPL_TST-3D-48_S_EN-XX_UK-U_71-ATMOS_2K_ECL_20180301_ECL_SMPTE-3D_OV/ECL07SingleCPL_TST-3D-48_S_EN-XX_UK-U_71-ATMOS_2K_ECL_20180301_ECL_SMPTE-3D_OV_01.mxf ... Stream #0:0, 1, 1/48: Video: jpeg2000, 1 reference frame, rgb48le(12 bpc, progressive), 2048x858, 0/1, SAR 1:1 DAR 1024:429, 48 tbr, 48 tbn, 48 tbc ... rgb48le is not correct as this file is xyz12 We can use the native decoder yes, not sure what the state is right now though, because I heard that some work was ongoing on that decoder, but back then (approx. 1 year ago) it was not really an option due to its poor performance, even for offline jobs. > You can force the pix_fmt, Carl Eugen How can I do that ? I'll continue to work on trying to fix mxfdec.c anyway, thanks. Le mar. 1 sept. 2020 à 18:18, Carl Eugen Hoyos a écrit : > Am Di., 1. Sept. 2020 um 12:14 Uhr schrieb Rémi Achard < > remiach...@gmail.com>: > > > > > Do you have a sample that does not work with the native decoder? > > > > According to my tests, the native decoder detect pixel format just fine > > So what problem do you see? > Yes, we prefer using the native codecs over external dependencies. > > You can force the pix_fmt, Carl Eugen > ___ > 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] libopenjpeg decoder not correctly setting the pixel format for cinema JP2K wrapped MXF
Am Di., 1. Sept. 2020 um 19:32 Uhr schrieb Rémi Achard : > We can use the native decoder yes, not sure what the state is right now > though, because I heard that some work was ongoing on that decoder, but > back then (approx. 1 year ago) it was not really an option due to its poor > performance, even for offline jobs. Please elaborate! Carl Eugen ___ 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] avformat/dashdec: bump maximum manifest size to 4 megabytes
This is absurdly large, but unfortunately a ~2 hour Youtube
live stream archive can still be around 3.2 megabytes when
requested as MPEG-DASH.
---
libavformat/dashdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index bea9616f4a..a7729e6380 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -29,7 +29,7 @@
#include "dash.h"
#define INITIAL_BUFFER_SIZE 32768
-#define MAX_MANIFEST_SIZE 50 * 1024
+#define MAX_MANIFEST_SIZE (4 * 1024 * 1024)
#define DEFAULT_MANIFEST_SIZE 8 * 1024
struct fragment {
--
2.26.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".
Re: [FFmpeg-devel] [PATCH 1/2] avformat/dashdec: enable overriding of the maximum manifest size
On Tue, Sep 1, 2020 at 8:45 PM Jan Ekström wrote:
>
> This enables people to override the sanity check without compiling
> a new binary.
> ---
> libavformat/dashdec.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index c5a5ff607b..bea9616f4a 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -160,6 +160,7 @@ typedef struct DASHContext {
> int is_init_section_common_video;
> int is_init_section_common_audio;
>
> +uint64_t maximum_manifest_size;
> } DASHContext;
>
> static int ishttp(char *url)
> @@ -1256,14 +1257,17 @@ static int parse_manifest(AVFormatContext *s, const
> char *url, AVIOContext *in)
> }
>
> filesize = avio_size(in);
> -if (filesize > MAX_MANIFEST_SIZE) {
> -av_log(s, AV_LOG_ERROR, "Manifest too large: %"PRId64"\n", filesize);
> +if (c->maximum_manifest_size && filesize > c->maximum_manifest_size) {
> +av_log(s, AV_LOG_ERROR,
> + "Manifest size too large: %"PRId64" (this sanity check can be
> "
> + "adjusted by using the option 'maximum_manifest_size')\n",
> + filesize);
> return AVERROR_INVALIDDATA;
> }
>
> av_bprint_init(&buf, (filesize > 0) ? filesize + 1 :
> DEFAULT_MANIFEST_SIZE, AV_BPRINT_SIZE_UNLIMITED);
>
> -if ((ret = avio_read_to_bprint(in, &buf, MAX_MANIFEST_SIZE)) < 0 ||
> +if ((ret = avio_read_to_bprint(in, &buf, c->maximum_manifest_size)) < 0
> ||
Yes, I noticed this just after I hit enter to send the first version
of this patch out :)
If zero, utilize file size. If filesize is zero, utilize
MAX_MANIFEST_SIZE, I guess :)
Jan
___
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 1/2] avformat/dashdec: enable overriding of the maximum manifest size
This enables people to override the sanity check without compiling
a new binary.
---
libavformat/dashdec.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index c5a5ff607b..bea9616f4a 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -160,6 +160,7 @@ typedef struct DASHContext {
int is_init_section_common_video;
int is_init_section_common_audio;
+uint64_t maximum_manifest_size;
} DASHContext;
static int ishttp(char *url)
@@ -1256,14 +1257,17 @@ static int parse_manifest(AVFormatContext *s, const
char *url, AVIOContext *in)
}
filesize = avio_size(in);
-if (filesize > MAX_MANIFEST_SIZE) {
-av_log(s, AV_LOG_ERROR, "Manifest too large: %"PRId64"\n", filesize);
+if (c->maximum_manifest_size && filesize > c->maximum_manifest_size) {
+av_log(s, AV_LOG_ERROR,
+ "Manifest size too large: %"PRId64" (this sanity check can be "
+ "adjusted by using the option 'maximum_manifest_size')\n",
+ filesize);
return AVERROR_INVALIDDATA;
}
av_bprint_init(&buf, (filesize > 0) ? filesize + 1 :
DEFAULT_MANIFEST_SIZE, AV_BPRINT_SIZE_UNLIMITED);
-if ((ret = avio_read_to_bprint(in, &buf, MAX_MANIFEST_SIZE)) < 0 ||
+if ((ret = avio_read_to_bprint(in, &buf, c->maximum_manifest_size)) < 0 ||
!avio_feof(in) ||
(filesize = buf.len) == 0) {
av_log(s, AV_LOG_ERROR, "Unable to read to manifest '%s'\n", url);
@@ -2409,6 +2413,9 @@ static const AVOption dash_options[] = {
OFFSET(allowed_extensions), AV_OPT_TYPE_STRING,
{.str = "aac,m4a,m4s,m4v,mov,mp4,webm,ts"},
INT_MIN, INT_MAX, FLAGS},
+{"maximum_manifest_size", "Maximum allowed size of the MPEG-DASH manifest
to read in bytes",
+ OFFSET(maximum_manifest_size), AV_OPT_TYPE_UINT64, {.i64 =
MAX_MANIFEST_SIZE},
+ 0, UINT64_MAX, FLAGS},
{NULL}
};
--
2.26.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".
Re: [FFmpeg-devel] libopenjpeg decoder not correctly setting the pixel format for cinema JP2K wrapped MXF
> Sure, here are some comparisons I just made, please note the huge difference in speed between current master and n4.0 that I picked as a representative of the state of the decoder back then. Also worth noting that the n4.0 decoder was not even able to transcode the full sequence properly and output a huge amount of warnings / errors. > ___ 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] libopenjpeg decoder not correctly setting the pixel format for cinema JP2K wrapped MXF
> Please elaborate! Sure, here are some comparisons I just made, please note the huge difference in speed between current master and n4.0 that I picked as a representative of the state of the decoder back then. There are great improvements being made for sure, I still think there could be some benefit having the libopenjpeg decoder work out of the box for cinema j2k (one of the big user of that format probably). libopenjpeg (master) frame= 96 fps= 14 q=-0.0 Lsize= 59514kB time=00:00:01.97 bitrate=246323.9kbits/s speed=0.279x jpeg2000 (master) frame= 96 fps=8.8 q=-0.0 Lsize= 70102kB time=00:00:01.97 bitrate=290149.4kbits/s speed=0.182x jpeg2000 (n4.0) frame= 50 fps=3.0 q=-0.0 Lsize= 36176kB time=00:00:01.02 bitrate=290281.1kbits/s dup=0 drop=46 speed=0.0605x Le mar. 1 sept. 2020 à 18:39, Carl Eugen Hoyos a écrit : > Am Di., 1. Sept. 2020 um 19:32 Uhr schrieb Rémi Achard < > remiach...@gmail.com>: > > > We can use the native decoder yes, not sure what the state is right now > > though, because I heard that some work was ongoing on that decoder, but > > back then (approx. 1 year ago) it was not really an option due to its > poor > > performance, even for offline jobs. > > Please elaborate! > > Carl Eugen > ___ > 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 1/2 v2] avformat/dashdec: enable overriding of the maximum manifest size
This enables people to override the sanity check without compiling
a new binary.
---
libavformat/dashdec.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index c5a5ff607b..4080b9b650 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -160,6 +160,7 @@ typedef struct DASHContext {
int is_init_section_common_video;
int is_init_section_common_audio;
+uint64_t maximum_manifest_size;
} DASHContext;
static int ishttp(char *url)
@@ -1256,14 +1257,21 @@ static int parse_manifest(AVFormatContext *s, const
char *url, AVIOContext *in)
}
filesize = avio_size(in);
-if (filesize > MAX_MANIFEST_SIZE) {
-av_log(s, AV_LOG_ERROR, "Manifest too large: %"PRId64"\n", filesize);
+if (c->maximum_manifest_size && filesize > c->maximum_manifest_size) {
+av_log(s, AV_LOG_ERROR,
+ "Manifest size too large: %"PRId64" (this sanity check can be "
+ "adjusted by using the option 'maximum_manifest_size')\n",
+ filesize);
return AVERROR_INVALIDDATA;
}
av_bprint_init(&buf, (filesize > 0) ? filesize + 1 :
DEFAULT_MANIFEST_SIZE, AV_BPRINT_SIZE_UNLIMITED);
-if ((ret = avio_read_to_bprint(in, &buf, MAX_MANIFEST_SIZE)) < 0 ||
+if ((ret = avio_read_to_bprint(in, &buf,
+ c->maximum_manifest_size > 0 ?
+ c->maximum_manifest_size :
+ (filesize > MAX_MANIFEST_SIZE ?
+filesize : MAX_MANIFEST_SIZE))) < 0 ||
!avio_feof(in) ||
(filesize = buf.len) == 0) {
av_log(s, AV_LOG_ERROR, "Unable to read to manifest '%s'\n", url);
@@ -2409,6 +2417,9 @@ static const AVOption dash_options[] = {
OFFSET(allowed_extensions), AV_OPT_TYPE_STRING,
{.str = "aac,m4a,m4s,m4v,mov,mp4,webm,ts"},
INT_MIN, INT_MAX, FLAGS},
+{"maximum_manifest_size", "Maximum allowed size of the MPEG-DASH manifest
to read in bytes",
+ OFFSET(maximum_manifest_size), AV_OPT_TYPE_UINT64, {.i64 =
MAX_MANIFEST_SIZE},
+ 0, UINT64_MAX, FLAGS},
{NULL}
};
--
2.26.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".
Re: [FFmpeg-devel] [PATCH 1/2] avformat/dashdec: enable overriding of the maximum manifest size
Jan Ekström:
> This enables people to override the sanity check without compiling
> a new binary.
> ---
> libavformat/dashdec.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index c5a5ff607b..bea9616f4a 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -160,6 +160,7 @@ typedef struct DASHContext {
> int is_init_section_common_video;
> int is_init_section_common_audio;
>
> +uint64_t maximum_manifest_size;
> } DASHContext;
>
> static int ishttp(char *url)
> @@ -1256,14 +1257,17 @@ static int parse_manifest(AVFormatContext *s, const
> char *url, AVIOContext *in)
> }
>
> filesize = avio_size(in);
> -if (filesize > MAX_MANIFEST_SIZE) {
> -av_log(s, AV_LOG_ERROR, "Manifest too large: %"PRId64"\n", filesize);
> +if (c->maximum_manifest_size && filesize > c->maximum_manifest_size) {
> +av_log(s, AV_LOG_ERROR,
> + "Manifest size too large: %"PRId64" (this sanity check can be
> "
> + "adjusted by using the option 'maximum_manifest_size')\n",
> + filesize);
> return AVERROR_INVALIDDATA;
> }
>
> av_bprint_init(&buf, (filesize > 0) ? filesize + 1 :
> DEFAULT_MANIFEST_SIZE, AV_BPRINT_SIZE_UNLIMITED);
>
> -if ((ret = avio_read_to_bprint(in, &buf, MAX_MANIFEST_SIZE)) < 0 ||
> +if ((ret = avio_read_to_bprint(in, &buf, c->maximum_manifest_size)) < 0
> ||
avio_read_to_bprint() uses size_t for its size parameter; the underlying
AVBPrint API uses unsigned. So using an uint64_t (or rather: allowing
something beyond UINT_MAX) seems wrong.
(Even with maximum_manifest_size and filesize <= UINT_MAX, filesize + 1
can already be outside the range of unsigned.)
Btw: Why not use a shorter name for the variable like max_manifest_size?
> !avio_feof(in) ||
> (filesize = buf.len) == 0) {
> av_log(s, AV_LOG_ERROR, "Unable to read to manifest '%s'\n", url);
> @@ -2409,6 +2413,9 @@ static const AVOption dash_options[] = {
> OFFSET(allowed_extensions), AV_OPT_TYPE_STRING,
> {.str = "aac,m4a,m4s,m4v,mov,mp4,webm,ts"},
> INT_MIN, INT_MAX, FLAGS},
> +{"maximum_manifest_size", "Maximum allowed size of the MPEG-DASH
> manifest to read in bytes",
> + OFFSET(maximum_manifest_size), AV_OPT_TYPE_UINT64, {.i64 =
> MAX_MANIFEST_SIZE},
> + 0, UINT64_MAX, FLAGS},
> {NULL}
> };
>
>
___
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 v2] avformat/dashdec: enable overriding of the maximum manifest size
Jan Ekström:
> This enables people to override the sanity check without compiling
> a new binary.
> ---
> libavformat/dashdec.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index c5a5ff607b..4080b9b650 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -160,6 +160,7 @@ typedef struct DASHContext {
> int is_init_section_common_video;
> int is_init_section_common_audio;
>
> +uint64_t maximum_manifest_size;
> } DASHContext;
>
> static int ishttp(char *url)
> @@ -1256,14 +1257,21 @@ static int parse_manifest(AVFormatContext *s, const
> char *url, AVIOContext *in)
> }
>
> filesize = avio_size(in);
> -if (filesize > MAX_MANIFEST_SIZE) {
> -av_log(s, AV_LOG_ERROR, "Manifest too large: %"PRId64"\n", filesize);
> +if (c->maximum_manifest_size && filesize > c->maximum_manifest_size) {
> +av_log(s, AV_LOG_ERROR,
> + "Manifest size too large: %"PRId64" (this sanity check can be
> "
> + "adjusted by using the option 'maximum_manifest_size')\n",
> + filesize);
> return AVERROR_INVALIDDATA;
> }
>
> av_bprint_init(&buf, (filesize > 0) ? filesize + 1 :
> DEFAULT_MANIFEST_SIZE, AV_BPRINT_SIZE_UNLIMITED);
>
> -if ((ret = avio_read_to_bprint(in, &buf, MAX_MANIFEST_SIZE)) < 0 ||
> +if ((ret = avio_read_to_bprint(in, &buf,
> + c->maximum_manifest_size > 0 ?
> + c->maximum_manifest_size :
You are treating zero as "no limit", despite this not being documented.
> + (filesize > MAX_MANIFEST_SIZE ?
> +filesize : MAX_MANIFEST_SIZE))) < 0 ||
Would be clearer as FFMAX(filesize, MAX_MANIFEST_SIZE). But honestly I
have trouble understanding why you are not just using filesize here
(presuming it is >= 0, which is not checked here or anywhere).
> !avio_feof(in) ||
> (filesize = buf.len) == 0) {
> av_log(s, AV_LOG_ERROR, "Unable to read to manifest '%s'\n", url);
> @@ -2409,6 +2417,9 @@ static const AVOption dash_options[] = {
> OFFSET(allowed_extensions), AV_OPT_TYPE_STRING,
> {.str = "aac,m4a,m4s,m4v,mov,mp4,webm,ts"},
> INT_MIN, INT_MAX, FLAGS},
> +{"maximum_manifest_size", "Maximum allowed size of the MPEG-DASH
> manifest to read in bytes",
> + OFFSET(maximum_manifest_size), AV_OPT_TYPE_UINT64, {.i64 =
> MAX_MANIFEST_SIZE},
> + 0, UINT64_MAX, FLAGS},
> {NULL}
> };
>
>
___
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] avformat/dashdec: enable overriding of the maximum manifest size
On Tue, Sep 1, 2020 at 9:19 PM Andreas Rheinhardt
wrote:
>
> Jan Ekström:
> > This enables people to override the sanity check without compiling
> > a new binary.
> > ---
> > libavformat/dashdec.c | 13 ++---
> > 1 file changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> > index c5a5ff607b..bea9616f4a 100644
> > --- a/libavformat/dashdec.c
> > +++ b/libavformat/dashdec.c
> > @@ -160,6 +160,7 @@ typedef struct DASHContext {
> > int is_init_section_common_video;
> > int is_init_section_common_audio;
> >
> > +uint64_t maximum_manifest_size;
> > } DASHContext;
> >
> > static int ishttp(char *url)
> > @@ -1256,14 +1257,17 @@ static int parse_manifest(AVFormatContext *s, const
> > char *url, AVIOContext *in)
> > }
> >
> > filesize = avio_size(in);
> > -if (filesize > MAX_MANIFEST_SIZE) {
> > -av_log(s, AV_LOG_ERROR, "Manifest too large: %"PRId64"\n",
> > filesize);
> > +if (c->maximum_manifest_size && filesize > c->maximum_manifest_size) {
> > +av_log(s, AV_LOG_ERROR,
> > + "Manifest size too large: %"PRId64" (this sanity check can
> > be "
> > + "adjusted by using the option 'maximum_manifest_size')\n",
> > + filesize);
> > return AVERROR_INVALIDDATA;
> > }
> >
> > av_bprint_init(&buf, (filesize > 0) ? filesize + 1 :
> > DEFAULT_MANIFEST_SIZE, AV_BPRINT_SIZE_UNLIMITED);
> >
> > -if ((ret = avio_read_to_bprint(in, &buf, MAX_MANIFEST_SIZE)) < 0 ||
> > +if ((ret = avio_read_to_bprint(in, &buf, c->maximum_manifest_size)) <
> > 0 ||
>
> avio_read_to_bprint() uses size_t for its size parameter; the underlying
> AVBPrint API uses unsigned. So using an uint64_t (or rather: allowing
> something beyond UINT_MAX) seems wrong.
> (Even with maximum_manifest_size and filesize <= UINT_MAX, filesize + 1
> can already be outside the range of unsigned.)
>
Alright. Will remove the option to not limit with zero, as well as
putting the maximum to UINT_MAX - 1. Would that sound good?
> Btw: Why not use a shorter name for the variable like max_manifest_size?
>
Just what initially popped into my mind like this. Can rename to make
it shorter.
Jan
___
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 v2] avformat/dashdec: enable overriding of the maximum manifest size
On Tue, Sep 1, 2020 at 9:31 PM Andreas Rheinhardt
wrote:
>
> Jan Ekström:
> > This enables people to override the sanity check without compiling
> > a new binary.
> > ---
> > libavformat/dashdec.c | 17 ++---
> > 1 file changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> > index c5a5ff607b..4080b9b650 100644
> > --- a/libavformat/dashdec.c
> > +++ b/libavformat/dashdec.c
> > @@ -160,6 +160,7 @@ typedef struct DASHContext {
> > int is_init_section_common_video;
> > int is_init_section_common_audio;
> >
> > +uint64_t maximum_manifest_size;
> > } DASHContext;
> >
> > static int ishttp(char *url)
> > @@ -1256,14 +1257,21 @@ static int parse_manifest(AVFormatContext *s, const
> > char *url, AVIOContext *in)
> > }
> >
> > filesize = avio_size(in);
> > -if (filesize > MAX_MANIFEST_SIZE) {
> > -av_log(s, AV_LOG_ERROR, "Manifest too large: %"PRId64"\n",
> > filesize);
> > +if (c->maximum_manifest_size && filesize > c->maximum_manifest_size) {
> > +av_log(s, AV_LOG_ERROR,
> > + "Manifest size too large: %"PRId64" (this sanity check can
> > be "
> > + "adjusted by using the option 'maximum_manifest_size')\n",
> > + filesize);
> > return AVERROR_INVALIDDATA;
> > }
> >
> > av_bprint_init(&buf, (filesize > 0) ? filesize + 1 :
> > DEFAULT_MANIFEST_SIZE, AV_BPRINT_SIZE_UNLIMITED);
> >
> > -if ((ret = avio_read_to_bprint(in, &buf, MAX_MANIFEST_SIZE)) < 0 ||
> > +if ((ret = avio_read_to_bprint(in, &buf,
> > + c->maximum_manifest_size > 0 ?
> > + c->maximum_manifest_size :
>
> You are treating zero as "no limit", despite this not being documented.
>
Yes. I just wanted to see how people would respond to the idea. But it
seems like due to the underlying bprint api I would in any case have
to limit it to UINT_MAX, thus making an option of "don't limit the
size" not really feasible.
> > + (filesize > MAX_MANIFEST_SIZE ?
> > +filesize : MAX_MANIFEST_SIZE))) < 0 ||
>
> Would be clearer as FFMAX(filesize, MAX_MANIFEST_SIZE). But honestly I
> have trouble understanding why you are not just using filesize here
> (presuming it is >= 0, which is not checked here or anywhere).
True, that would be clearer. I think I just utilized it this way
because if file size is larger than MAX_MANIFEST_SIZE, it should
definitely be larger than zero :) .
Jan
___
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 v2] avformat/dashdec: enable overriding of the maximum manifest size
Jan Ekström:
> On Tue, Sep 1, 2020 at 9:31 PM Andreas Rheinhardt
> wrote:
>>
>> Jan Ekström:
>>> This enables people to override the sanity check without compiling
>>> a new binary.
>>> ---
>>> libavformat/dashdec.c | 17 ++---
>>> 1 file changed, 14 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
>>> index c5a5ff607b..4080b9b650 100644
>>> --- a/libavformat/dashdec.c
>>> +++ b/libavformat/dashdec.c
>>> @@ -160,6 +160,7 @@ typedef struct DASHContext {
>>> int is_init_section_common_video;
>>> int is_init_section_common_audio;
>>>
>>> +uint64_t maximum_manifest_size;
>>> } DASHContext;
>>>
>>> static int ishttp(char *url)
>>> @@ -1256,14 +1257,21 @@ static int parse_manifest(AVFormatContext *s, const
>>> char *url, AVIOContext *in)
>>> }
>>>
>>> filesize = avio_size(in);
>>> -if (filesize > MAX_MANIFEST_SIZE) {
>>> -av_log(s, AV_LOG_ERROR, "Manifest too large: %"PRId64"\n",
>>> filesize);
>>> +if (c->maximum_manifest_size && filesize > c->maximum_manifest_size) {
>>> +av_log(s, AV_LOG_ERROR,
>>> + "Manifest size too large: %"PRId64" (this sanity check can
>>> be "
>>> + "adjusted by using the option 'maximum_manifest_size')\n",
>>> + filesize);
>>> return AVERROR_INVALIDDATA;
>>> }
>>>
>>> av_bprint_init(&buf, (filesize > 0) ? filesize + 1 :
>>> DEFAULT_MANIFEST_SIZE, AV_BPRINT_SIZE_UNLIMITED);
>>>
>>> -if ((ret = avio_read_to_bprint(in, &buf, MAX_MANIFEST_SIZE)) < 0 ||
>>> +if ((ret = avio_read_to_bprint(in, &buf,
>>> + c->maximum_manifest_size > 0 ?
>>> + c->maximum_manifest_size :
>>
>> You are treating zero as "no limit", despite this not being documented.
>>
>
> Yes. I just wanted to see how people would respond to the idea. But it
> seems like due to the underlying bprint api I would in any case have
> to limit it to UINT_MAX, thus making an option of "don't limit the
> size" not really feasible.
>
>>> + (filesize > MAX_MANIFEST_SIZE ?
>>> +filesize : MAX_MANIFEST_SIZE))) < 0 ||
>>
>> Would be clearer as FFMAX(filesize, MAX_MANIFEST_SIZE). But honestly I
>> have trouble understanding why you are not just using filesize here
>> (presuming it is >= 0, which is not checked here or anywhere).
>
> True, that would be clearer. I think I just utilized it this way
> because if file size is larger than MAX_MANIFEST_SIZE, it should
> definitely be larger than zero :) .
>
My thinking was this: If filesize is >= 0 and if it passed all checks
already, then just use avio_read_to_bprint(in, &buf, filesize). After
all, we know the filesize or is there some reason to believe it to be wrong?
> Jan
> ___
> 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/2 v2] avformat/dashdec: enable overriding of the maximum manifest size
On Tue, Sep 1, 2020 at 9:56 PM Andreas Rheinhardt
wrote:
>
> Jan Ekström:
> > On Tue, Sep 1, 2020 at 9:31 PM Andreas Rheinhardt
> > wrote:
> >>
> >> Jan Ekström:
> >>> This enables people to override the sanity check without compiling
> >>> a new binary.
> >>> ---
> >>> libavformat/dashdec.c | 17 ++---
> >>> 1 file changed, 14 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> >>> index c5a5ff607b..4080b9b650 100644
> >>> --- a/libavformat/dashdec.c
> >>> +++ b/libavformat/dashdec.c
> >>> @@ -160,6 +160,7 @@ typedef struct DASHContext {
> >>> int is_init_section_common_video;
> >>> int is_init_section_common_audio;
> >>>
> >>> +uint64_t maximum_manifest_size;
> >>> } DASHContext;
> >>>
> >>> static int ishttp(char *url)
> >>> @@ -1256,14 +1257,21 @@ static int parse_manifest(AVFormatContext *s,
> >>> const char *url, AVIOContext *in)
> >>> }
> >>>
> >>> filesize = avio_size(in);
> >>> -if (filesize > MAX_MANIFEST_SIZE) {
> >>> -av_log(s, AV_LOG_ERROR, "Manifest too large: %"PRId64"\n",
> >>> filesize);
> >>> +if (c->maximum_manifest_size && filesize > c->maximum_manifest_size)
> >>> {
> >>> +av_log(s, AV_LOG_ERROR,
> >>> + "Manifest size too large: %"PRId64" (this sanity check
> >>> can be "
> >>> + "adjusted by using the option 'maximum_manifest_size')\n",
> >>> + filesize);
> >>> return AVERROR_INVALIDDATA;
> >>> }
> >>>
> >>> av_bprint_init(&buf, (filesize > 0) ? filesize + 1 :
> >>> DEFAULT_MANIFEST_SIZE, AV_BPRINT_SIZE_UNLIMITED);
> >>>
> >>> -if ((ret = avio_read_to_bprint(in, &buf, MAX_MANIFEST_SIZE)) < 0 ||
> >>> +if ((ret = avio_read_to_bprint(in, &buf,
> >>> + c->maximum_manifest_size > 0 ?
> >>> + c->maximum_manifest_size :
> >>
> >> You are treating zero as "no limit", despite this not being documented.
> >>
> >
> > Yes. I just wanted to see how people would respond to the idea. But it
> > seems like due to the underlying bprint api I would in any case have
> > to limit it to UINT_MAX, thus making an option of "don't limit the
> > size" not really feasible.
> >
> >>> + (filesize > MAX_MANIFEST_SIZE ?
> >>> +filesize : MAX_MANIFEST_SIZE))) < 0
> >>> ||
> >>
> >> Would be clearer as FFMAX(filesize, MAX_MANIFEST_SIZE). But honestly I
> >> have trouble understanding why you are not just using filesize here
> >> (presuming it is >= 0, which is not checked here or anywhere).
> >
> > True, that would be clearer. I think I just utilized it this way
> > because if file size is larger than MAX_MANIFEST_SIZE, it should
> > definitely be larger than zero :) .
> >
>
> My thinking was this: If filesize is >= 0 and if it passed all checks
> already, then just use avio_read_to_bprint(in, &buf, filesize). After
> all, we know the filesize or is there some reason to believe it to be wrong?
>
That would work with filesize > 0, as avio_read_to_bprint would just
return 0 without any data read in case it was zero.
As for HTTP and such, I'm actually not sure how libavformat handles
file sizes. I would expect it to trust the HTTP header value if
available, but what happens when it's either not available, or if
there is compression being applied over the wire (gzip compression
etc, although I have not checked if the libavformat HTTP
implementation implements this).
Thus an unset (either zero or negative) file size could be a reality,
which is why I would expect the current code to have utilized the
maximum manifest size as the size to read, as opposed to the file size
itself.
Jan
___
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 v2] avformat/dashdec: enable overriding of the maximum manifest size
Jan Ekström:
> On Tue, Sep 1, 2020 at 9:56 PM Andreas Rheinhardt
> wrote:
>>
>> Jan Ekström:
>>> On Tue, Sep 1, 2020 at 9:31 PM Andreas Rheinhardt
>>> wrote:
Jan Ekström:
> This enables people to override the sanity check without compiling
> a new binary.
> ---
> libavformat/dashdec.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index c5a5ff607b..4080b9b650 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -160,6 +160,7 @@ typedef struct DASHContext {
> int is_init_section_common_video;
> int is_init_section_common_audio;
>
> +uint64_t maximum_manifest_size;
> } DASHContext;
>
> static int ishttp(char *url)
> @@ -1256,14 +1257,21 @@ static int parse_manifest(AVFormatContext *s,
> const char *url, AVIOContext *in)
> }
>
> filesize = avio_size(in);
> -if (filesize > MAX_MANIFEST_SIZE) {
> -av_log(s, AV_LOG_ERROR, "Manifest too large: %"PRId64"\n",
> filesize);
> +if (c->maximum_manifest_size && filesize > c->maximum_manifest_size)
> {
> +av_log(s, AV_LOG_ERROR,
> + "Manifest size too large: %"PRId64" (this sanity check
> can be "
> + "adjusted by using the option 'maximum_manifest_size')\n",
> + filesize);
> return AVERROR_INVALIDDATA;
> }
>
> av_bprint_init(&buf, (filesize > 0) ? filesize + 1 :
> DEFAULT_MANIFEST_SIZE, AV_BPRINT_SIZE_UNLIMITED);
>
> -if ((ret = avio_read_to_bprint(in, &buf, MAX_MANIFEST_SIZE)) < 0 ||
> +if ((ret = avio_read_to_bprint(in, &buf,
> + c->maximum_manifest_size > 0 ?
> + c->maximum_manifest_size :
You are treating zero as "no limit", despite this not being documented.
>>>
>>> Yes. I just wanted to see how people would respond to the idea. But it
>>> seems like due to the underlying bprint api I would in any case have
>>> to limit it to UINT_MAX, thus making an option of "don't limit the
>>> size" not really feasible.
>>>
> + (filesize > MAX_MANIFEST_SIZE ?
> +filesize : MAX_MANIFEST_SIZE))) < 0
> ||
Would be clearer as FFMAX(filesize, MAX_MANIFEST_SIZE). But honestly I
have trouble understanding why you are not just using filesize here
(presuming it is >= 0, which is not checked here or anywhere).
>>>
>>> True, that would be clearer. I think I just utilized it this way
>>> because if file size is larger than MAX_MANIFEST_SIZE, it should
>>> definitely be larger than zero :) .
>>>
>>
>> My thinking was this: If filesize is >= 0 and if it passed all checks
>> already, then just use avio_read_to_bprint(in, &buf, filesize). After
>> all, we know the filesize or is there some reason to believe it to be wrong?
>>
>
> That would work with filesize > 0, as avio_read_to_bprint would just
> return 0 without any data read in case it was zero.
>
> As for HTTP and such, I'm actually not sure how libavformat handles
> file sizes. I would expect it to trust the HTTP header value if
> available, but what happens when it's either not available, or if
> there is compression being applied over the wire (gzip compression
> etc, although I have not checked if the libavformat HTTP
> implementation implements this).
>
> Thus an unset (either zero or negative) file size could be a reality,
> which is why I would expect the current code to have utilized the
> maximum manifest size as the size to read, as opposed to the file size
> itself.
>
Ok, if the file size might be wrong, your code makes sense.
Yet there is a catch in your check: filesize > c->maximum_manifest_size.
filesize will be promoted to uint64_t here.
- 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".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/decode: use a packet list to store packet properties
James Almer:
> Keeping only the latest packet fed to the decoder works only for decoders that
> return a frame immediately after every consumed packet. Decoders that consume
> several packets before they return a frame will fill said frame with
> properties
> taken from the last consumed packet instead of the earliest.
>
Then why does this patch not restrict usage of this list to decoders
with AV_CODEC_CAP_DELAY?
> Signed-off-by: James Almer
> ---
> This essentially enables decoders implementing the AVCodec.receive_frame API
> to
> not require having to deal with timestamps and such properties internally, and
> letting ff_decode_frame_props() do all the work instead (See libdav1d, which
> i'll adapt once this goes in).
>
> As an example, this fixes the timestamps for the audio track in
> bink/binkaudio_rdft.bik from the FATE suite, where the decoder wrongly assumed
> ff_decode_frame_props() alone would handle them right.
> The reason the relevant fate test is unaffected is because it just compares
> the
> decoded output with a reference pcm file.
>
> Haven't looked too much into it, but i assume this change could simplify some
> AV_CODEC_CAP_DELAY decoders that keep track of timestamps, even those using
> the
> old AVCodec.decode() API.
>
> libavcodec/decode.c | 34 +-
> libavcodec/internal.h | 2 ++
> libavcodec/utils.c| 3 +++
> 3 files changed, 30 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index da587ac1f6..de36e28d3c 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -43,6 +43,7 @@
> #include "decode.h"
> #include "hwconfig.h"
> #include "internal.h"
> +#include "packet_internal.h"
> #include "thread.h"
>
> typedef struct FramePool {
> @@ -142,15 +143,22 @@ fail2:
> return 0;
> }
>
> -static int extract_packet_props(AVCodecInternal *avci, const AVPacket *pkt)
> +#define IS_EMPTY(pkt) (!(pkt)->data && !(pkt)->side_data_elems)
> +
> +static int extract_packet_props(AVCodecInternal *avci, AVPacket *pkt)
> {
> int ret = 0;
>
> -av_packet_unref(avci->last_pkt_props);
> -if (pkt) {
> -ret = av_packet_copy_props(avci->last_pkt_props, pkt);
> -if (!ret)
> -avci->last_pkt_props->size = pkt->size; // HACK: Needed for
> ff_decode_frame_props().
> +ret = avpriv_packet_list_put(&avci->pkt_props, &avci->pkt_props_tail,
> pkt,
> + FF_PACKETLIST_FLAG_REF_PACKET);
This will make a reference to the pkt's data and therefore potentially
(probably?) increase its lifetime. Maybe one should add a new
FF_PACKETLIST_FLAG that says that only non-data fields should be copied?
(Ideally, the new flag together with FF_PACKETLIST_FLAG_REF_PACKET would
amount to av_packet_copy_props, whereas the new flag without it would
amount to moving the side data to the list packet and resetting the
non-data fields of src; but we have no function and no need for the
latter, so this can remain unimplemented).
> +if (ret < 0)
> +return ret;
> +
> +if (IS_EMPTY(avci->last_pkt_props)) {
> +ret = avpriv_packet_list_get(&avci->pkt_props,
> + &avci->pkt_props_tail,
> + avci->last_pkt_props);
> +av_assert0(ret != AVERROR(EAGAIN));
> }
> return ret;
> }
> @@ -512,6 +520,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>
> if (ret >= pkt->size || ret < 0) {
> av_packet_unref(pkt);
> +av_packet_unref(avci->last_pkt_props);
> } else {
> int consumed = ret;
>
> @@ -550,9 +559,11 @@ static int decode_receive_frame_internal(AVCodecContext
> *avctx, AVFrame *frame)
>
> av_assert0(!frame->buf[0]);
>
> -if (avctx->codec->receive_frame)
> +if (avctx->codec->receive_frame) {
> ret = avctx->codec->receive_frame(avctx, frame);
> -else
> +if (ret != AVERROR(EAGAIN))
> +av_packet_unref(avci->last_pkt_props);
> +} else
> ret = decode_simple_receive_frame(avctx, frame);
>
> if (ret == AVERROR_EOF)
> @@ -1683,7 +1694,7 @@ static int add_metadata_from_side_data(const AVPacket
> *avpkt, AVFrame *frame)
>
> int ff_decode_frame_props(AVCodecContext *avctx, AVFrame *frame)
> {
> -const AVPacket *pkt = avctx->internal->last_pkt_props;
> +AVPacket *pkt = avctx->internal->last_pkt_props;
> int i;
> static const struct {
> enum AVPacketSideDataType packet;
> @@ -1701,6 +1712,11 @@ int ff_decode_frame_props(AVCodecContext *avctx,
> AVFrame *frame)
> { AV_PKT_DATA_S12M_TIMECODE,
> AV_FRAME_DATA_S12M_TIMECODE },
> };
>
> +if (IS_EMPTY(pkt))
> +avpriv_packet_list_get(&avctx->internal->pkt_props,
> + &avctx->internal->pkt_props_tail,
> + pkt);
> +
> if (pkt) {
> frame->pts = pkt->pts;
> #if FF_API_PKT_PTS
> diff --gi
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/decode: use a packet list to store packet properties
On 9/1/2020 4:16 PM, Andreas Rheinhardt wrote:
> James Almer:
>> Keeping only the latest packet fed to the decoder works only for decoders
>> that
>> return a frame immediately after every consumed packet. Decoders that consume
>> several packets before they return a frame will fill said frame with
>> properties
>> taken from the last consumed packet instead of the earliest.
>>
>
> Then why does this patch not restrict usage of this list to decoders
> with AV_CODEC_CAP_DELAY?
To avoid adding extra checks, since the list works for all cases.
>
>> Signed-off-by: James Almer
>> ---
>> This essentially enables decoders implementing the AVCodec.receive_frame API
>> to
>> not require having to deal with timestamps and such properties internally,
>> and
>> letting ff_decode_frame_props() do all the work instead (See libdav1d, which
>> i'll adapt once this goes in).
>>
>> As an example, this fixes the timestamps for the audio track in
>> bink/binkaudio_rdft.bik from the FATE suite, where the decoder wrongly
>> assumed
>> ff_decode_frame_props() alone would handle them right.
>> The reason the relevant fate test is unaffected is because it just compares
>> the
>> decoded output with a reference pcm file.
>>
>> Haven't looked too much into it, but i assume this change could simplify some
>> AV_CODEC_CAP_DELAY decoders that keep track of timestamps, even those using
>> the
>> old AVCodec.decode() API.
>>
>> libavcodec/decode.c | 34 +-
>> libavcodec/internal.h | 2 ++
>> libavcodec/utils.c| 3 +++
>> 3 files changed, 30 insertions(+), 9 deletions(-)
>>
>> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
>> index da587ac1f6..de36e28d3c 100644
>> --- a/libavcodec/decode.c
>> +++ b/libavcodec/decode.c
>> @@ -43,6 +43,7 @@
>> #include "decode.h"
>> #include "hwconfig.h"
>> #include "internal.h"
>> +#include "packet_internal.h"
>> #include "thread.h"
>>
>> typedef struct FramePool {
>> @@ -142,15 +143,22 @@ fail2:
>> return 0;
>> }
>>
>> -static int extract_packet_props(AVCodecInternal *avci, const AVPacket *pkt)
>> +#define IS_EMPTY(pkt) (!(pkt)->data && !(pkt)->side_data_elems)
>> +
>> +static int extract_packet_props(AVCodecInternal *avci, AVPacket *pkt)
>> {
>> int ret = 0;
>>
>> -av_packet_unref(avci->last_pkt_props);
>> -if (pkt) {
>> -ret = av_packet_copy_props(avci->last_pkt_props, pkt);
>> -if (!ret)
>> -avci->last_pkt_props->size = pkt->size; // HACK: Needed for
>> ff_decode_frame_props().
>> +ret = avpriv_packet_list_put(&avci->pkt_props, &avci->pkt_props_tail,
>> pkt,
>> + FF_PACKETLIST_FLAG_REF_PACKET);
>
> This will make a reference to the pkt's data and therefore potentially
> (probably?) increase its lifetime. Maybe one should add a new
> FF_PACKETLIST_FLAG that says that only non-data fields should be copied?
> (Ideally, the new flag together with FF_PACKETLIST_FLAG_REF_PACKET would
> amount to av_packet_copy_props, whereas the new flag without it would
> amount to moving the side data to the list packet and resetting the
> non-data fields of src; but we have no function and no need for the
> latter, so this can remain unimplemented).
I don't think it's an issue since the amount of packets that would be
queued by this list is minimal, but yes, i can add that flag, if
anything to reduce the overhead from unnecessary AVBufferRef allocations
when we only want the props.
>
>> +if (ret < 0)
>> +return ret;
>> +
>> +if (IS_EMPTY(avci->last_pkt_props)) {
>> +ret = avpriv_packet_list_get(&avci->pkt_props,
>> + &avci->pkt_props_tail,
>> + avci->last_pkt_props);
>> +av_assert0(ret != AVERROR(EAGAIN));
>> }
>> return ret;
>> }
>> @@ -512,6 +520,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>>
>> if (ret >= pkt->size || ret < 0) {
>> av_packet_unref(pkt);
>> +av_packet_unref(avci->last_pkt_props);
>> } else {
>> int consumed = ret;
>>
>> @@ -550,9 +559,11 @@ static int decode_receive_frame_internal(AVCodecContext
>> *avctx, AVFrame *frame)
>>
>> av_assert0(!frame->buf[0]);
>>
>> -if (avctx->codec->receive_frame)
>> +if (avctx->codec->receive_frame) {
>> ret = avctx->codec->receive_frame(avctx, frame);
>> -else
>> +if (ret != AVERROR(EAGAIN))
>> +av_packet_unref(avci->last_pkt_props);
>> +} else
>> ret = decode_simple_receive_frame(avctx, frame);
>>
>> if (ret == AVERROR_EOF)
>> @@ -1683,7 +1694,7 @@ static int add_metadata_from_side_data(const AVPacket
>> *avpkt, AVFrame *frame)
>>
>> int ff_decode_frame_props(AVCodecContext *avctx, AVFrame *frame)
>> {
>> -const AVPacket *pkt = avctx->internal->last_pkt_props;
>> +AVPacket *pkt = avctx->internal->last_pkt_props;
>> int i;
>> static const struct {
>> enum AVPacketSid
Re: [FFmpeg-devel] libopenjpeg decoder not correctly setting the pixel format for cinema JP2K wrapped MXF
> I'll continue to work on trying to fix mxfdec.c anyway, thanks.
Update to the patch proposal, seems to be working ok (as far as pixel
format is concerned) for both SMPTE & INTEROP DCP.
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 6f6e8d586c..4c146a152d 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -325,9 +325,11 @@ static const uint8_t mxf_encrypted_essence_container[]
= { 0x06,0x0e,0x2b,0x
static const uint8_t mxf_random_index_pack_key[] = {
0x06,0x0e,0x2b,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x11,0x01,0x00
};
static const uint8_t mxf_sony_mpeg4_extradata[]= {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0e,0x06,0x06,0x02,0x02,0x01,0x00,0x00
};
static const uint8_t mxf_avid_project_name[] = {
0xa5,0xfb,0x7b,0x25,0xf6,0x15,0x94,0xb9,0x62,0xfc,0x37,0x17,0x49,0x2d,0x42,0xbf
};
-static const uint8_t mxf_jp2k_rsiz[] = {
0x06,0x0e,0x2b,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x02,0x01,0x00
};
+static const uint8_t mxf_jp2k_rsiz[] = {
0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x01,0x00,0x00,0x00
};
static const uint8_t mxf_indirect_value_utf16le[] = {
0x4c,0x00,0x02,0x10,0x01,0x00,0x00,0x00,0x00,0x06,0x0e,0x2b,0x34,0x01,0x04,0x01,0x01
};
static const uint8_t mxf_indirect_value_utf16be[] = {
0x42,0x01,0x10,0x02,0x00,0x00,0x00,0x00,0x00,0x06,0x0e,0x2b,0x34,0x01,0x04,0x01,0x01
};
+static const uint8_t mxf_subdescriptor_array_smpte[] = {
0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x09,0x06,0x01,0x01,0x04,0x06,0x10,0x00,0x00
};
+static const uint8_t mxf_subdescriptor_array_interop[] = {
0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x02,0x06,0x01,0x01,0x04,0x06,0x10,0x00,0x00
};
#define IS_KLV_KEY(x, y) (!memcmp(x, y, sizeof(y)))
@@ -1272,6 +1274,11 @@ static int mxf_read_generic_descriptor(void *arg,
AVIOContext *pb, int tag, int
rsiz == FF_PROFILE_JPEG2000_DCINEMA_4K)
descriptor->pix_fmt = AV_PIX_FMT_XYZ12;
}
+if (IS_KLV_KEY(uid, mxf_subdescriptor_array_smpte)
+ || IS_KLV_KEY(uid, mxf_subdescriptor_array_interop)) {
+mxf_read_strong_ref_array(pb,
&descriptor->sub_descriptors_refs,
+
&descriptor->sub_descriptors_count);
+}
break;
}
return 0;
@@ -2498,6 +2505,16 @@ static int mxf_parse_structural_metadata(MXFContext
*mxf)
}
}
+if (st->codecpar->codec_id == AV_CODEC_ID_JPEG2000) {
+MXFDescriptor *desc = NULL;
+for (k = 0; k < descriptor->sub_descriptors_count; k++) {
+if ((desc = mxf_resolve_strong_ref(mxf,
&descriptor->sub_descriptors_refs[k], SubDescriptor))) {
+st->codecpar->format = desc->pix_fmt;
+break;
+}
+}
+}
+
if (st->codecpar->codec_id == AV_CODEC_ID_RAWVIDEO) {
st->codecpar->format = descriptor->pix_fmt;
if (st->codecpar->format == AV_PIX_FMT_NONE) {
@@ -2753,6 +2770,7 @@ static const MXFMetadataReadTableEntry
mxf_metadata_read_table[] = {
{ {
0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x5c,0x00
}, mxf_read_generic_descriptor, sizeof(MXFDescriptor), Descriptor }, /*
VANC/VBI - SMPTE 436M */
{ {
0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x5e,0x00
}, mxf_read_generic_descriptor, sizeof(MXFDescriptor), Descriptor }, /*
MPEG2AudioDescriptor */
{ {
0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x64,0x00
}, mxf_read_generic_descriptor, sizeof(MXFDescriptor), Descriptor }, /* DC
Timed Text Descriptor */
+{ {
0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x5a,0x00
}, mxf_read_generic_descriptor, sizeof(MXFDescriptor), SubDescriptor }, /*
JPEG2000PictureSubDescriptor */
{ {
0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x3A,0x00
}, mxf_read_track, sizeof(MXFTrack), Track }, /* Static Track */
{ {
0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x3B,0x00
}, mxf_read_track, sizeof(MXFTrack), Track }, /* Generic Track */
{ {
0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x14,0x00
}, mxf_read_timecode_component, sizeof(MXFTimecodeComponent),
TimecodeComponent },
Le mar. 1 sept. 2020 à 18:59, Rémi Achard a écrit :
> > Sure, here are some comparisons I just made, please note the huge
> difference in speed between current master and n4.0 that I picked as a
> representative of the state of the decoder back then.
>
> Also worth noting that the n4.0 decoder was not even able to transcode the
> full sequence properly and output a huge amount of warnings / errors.
>
>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat: add mca demuxer
From: Zixing Liu
Signed-off-by: liushuyu
---
Changelog| 1 +
doc/general.texi | 2 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/mca.c| 240 +++
libavformat/version.h| 4 +-
6 files changed, 247 insertions(+), 2 deletions(-)
create mode 100644 libavformat/mca.c
diff --git a/Changelog b/Changelog
index 7467e73..ae4219f 100644
--- a/Changelog
+++ b/Changelog
@@ -15,6 +15,7 @@ version :
- Argonaut Games ASF muxer
- AV1 Low overhead bitstream format demuxer
- RPZA video encoder
+- MCA demuxer
version 4.3:
diff --git a/doc/general.texi b/doc/general.texi
index d618565..fa76ed4 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -524,6 +524,8 @@ library:
@tab Metadata in text format.
@item MAXIS XA @tab @tab X
@tab Used in Sim City 3000; file extension .xa.
+@item MCA @tab @tab X
+@tab Used in some games from Capcom; file extension .mca.
@item MD Studio @tab @tab X
@item Metal Gear Solid: The Twin Snakes @tab @tab X
@item Megalux Frame @tab @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index cbb33fe..7f5ab21 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -305,6 +305,7 @@ OBJS-$(CONFIG_MATROSKA_MUXER)+= matroskaenc.o
matroska.o \
av1.o avc.o hevc.o \
flacenc_header.o avlanguage.o \
vorbiscomment.o wv.o
+OBJS-$(CONFIG_MCA_DEMUXER) += mca.o
OBJS-$(CONFIG_MCC_DEMUXER) += mccdec.o subtitles.o
OBJS-$(CONFIG_MD5_MUXER) += hashenc.o
OBJS-$(CONFIG_MGSTS_DEMUXER) += mgsts.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0aa9dd7..8a71de6 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -232,6 +232,7 @@ extern AVInputFormat ff_lvf_demuxer;
extern AVInputFormat ff_lxf_demuxer;
extern AVInputFormat ff_m4v_demuxer;
extern AVOutputFormat ff_m4v_muxer;
+extern AVInputFormat ff_mca_demuxer;
extern AVInputFormat ff_mcc_demuxer;
extern AVOutputFormat ff_md5_muxer;
extern AVInputFormat ff_matroska_demuxer;
diff --git a/libavformat/mca.c b/libavformat/mca.c
new file mode 100644
index 000..e51d3fb
--- /dev/null
+++ b/libavformat/mca.c
@@ -0,0 +1,240 @@
+/*
+ * MCA demuxer
+ * Copyright (c) 2020 Zixing Liu
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/intreadwrite.h"
+#include "libavcodec/bytestream.h"
+#include "avformat.h"
+#include "internal.h"
+
+typedef struct MCADemuxContext {
+uint32_t block_count;
+uint16_t block_size;
+uint32_t coef_offset;
+uint32_t current_block;
+uint32_t data_start;
+uint32_t samples_per_block;
+} MCADemuxContext;
+
+static int probe(const AVProbeData *p)
+{
+if (AV_RL32(p->buf) == MKTAG('M', 'A', 'D', 'P') &&
+(AV_RL16(p->buf + 4) > 0x00 || AV_RL16(p->buf + 4) <= 0xff))
+return AVPROBE_SCORE_MAX / 3 * 2;
+return 0;
+}
+
+static int read_header(AVFormatContext *s)
+{
+AVStream *st;
+MCADemuxContext *m = s->priv_data;
+int16_t version = 0;
+int64_t file_size = 0;
+uint32_t header_size, data_size, data_offset, loop_start, loop_end,
+nb_samples, nb_metadata = 0;
+int ch;
+int ret = AVERROR_EOF;
+
+st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
+
+// parse file headers
+avio_skip(s->pb, 0x4); // skip the file magic
+version = avio_rl16(s->pb); // offset 0x4
+avio_skip(s->pb, 0x2); // padding
+st->codecpar->channels = avio_r8(s->pb);// offset 0x8
+avio_skip(s->pb, 0x1); // padding
+m->block_size = avio_rl16(s->pb); // offset 0xa
+nb_samples = avio_rl32(s->pb); // offset 0xc
+st->codecpar->sample_rate = avio_rl32(s->pb); // offset 0x10
+loop_start = avio_rl32(s->pb); // offset 0x14
+loop_end = avio_rl32(s->pb);// offset 0x18
+header_size = avio_rl32(s->pb); // offset 0x1c
+data_s
[FFmpeg-devel] [PATCH 0/1] avformat: add mca demuxer
From: Zixing Liu This patch adds the MCA demuxer to FFmpeg. MCA is a format used by Capcom in some of their games, the audio format is always ADPCM_THP_LE in these files. This MCA demuxer implementation currently supports MCA version 1-5 and can partially handle some of the version 5 files with minor damages to the file header. There are some sample files I have prepared that you can try: * (version 4) https://streams.videolan.org/ffmpeg/incoming/bgm18_1632b.mca * (version 5) https://streams.videolan.org/ffmpeg/incoming/bgm020_1632.mca N.B. Files using version 1 to 3 are harder to find, I don't seem to find any to test. As required by https://ffmpeg.org/developer.html#New-codecs-or-formats-checklist, the minor version of libavformat is updated to 52. Zixing Liu (1): avformat: add mca demuxer Changelog| 1 + doc/general.texi | 2 + libavformat/Makefile | 1 + libavformat/allformats.c | 1 + libavformat/mca.c| 228 +++ libavformat/version.h| 4 +- 6 files changed, 235 insertions(+), 2 deletions(-) create mode 100644 libavformat/mca.c -- 2.28.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] avformat: add mca demuxer
Am Mi., 2. Sept. 2020 um 00:58 Uhr schrieb :
> +static int probe(const AVProbeData *p)
> +{
> +if (AV_RL32(p->buf) == MKTAG('M', 'A', 'D', 'P') &&
> +(AV_RL16(p->buf + 4) > 0x00 || AV_RL16(p->buf + 4) <= 0xff))
> +return AVPROBE_SCORE_MAX / 3 * 2;
> +return 0;
At least add the version check from read_header(),
you could also add the "sanity checks" you do
there to this function.
Carl Eugen
___
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/8] cbs: Implement common parts of cbs-based bitstream filters separately
On 23/08/2020 23:33, Mark Thompson wrote: --- This series depends on the CBS unit table rewrite and following cleanups. Since comments on that series seem to have dried up, I will apply it in a few days if nothing further comes up. Applied the first half. I'm going to look into adding some fate tests to go with the second half, since currently none of the metadata editing behaviour is covered. Thanks, - Mark ___ 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: add mca demuxer
On 2020-09-01 17:07, Carl Eugen Hoyos wrote:
Am Mi., 2. Sept. 2020 um 00:58 Uhr schrieb :
+static int probe(const AVProbeData *p)
+{
+if (AV_RL32(p->buf) == MKTAG('M', 'A', 'D', 'P') &&
+(AV_RL16(p->buf + 4) > 0x00 || AV_RL16(p->buf + 4) <= 0xff))
+return AVPROBE_SCORE_MAX / 3 * 2;
+return 0;
At least add the version check from read_header(),
you could also add the "sanity checks" you do
there to this function.
Carl Eugen
___
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".
Thanks for the extremely quick response! I agree I can probably move the
version check to `probe()`.
However the other checks require reading far into the header, I don't
know if it's appropriate to do that in `probe()`.
Thanks,
Zixing
___
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] cbs_av1: Fill tile width/height values when uniform_tile_spacing_flag is set
On 01/09/2020 08:16, Wang, Fei W wrote: -Original Message- From: ffmpeg-devel On Behalf Of Mark Thompson Sent: Tuesday, September 1, 2020 5:01 AM To: ffmpeg-devel@ffmpeg.org Subject: [FFmpeg-devel] [PATCH v2] cbs_av1: Fill tile width/height values when uniform_tile_spacing_flag is set They are not explicitly in the bitstream in this case, but it is helpful to be able to use these values without always needing to check the flag beforehand. --- ... libavcodec/cbs_av1_syntax_template.c | 9 + 1 file changed, 9 insertions(+) diff --git a/libavcodec/cbs_av1_syntax_template.c b/libavcodec/cbs_av1_syntax_template.c index 19b82bc3f8..2d2e240e3e 100644 --- a/libavcodec/cbs_av1_syntax_template.c +++ b/libavcodec/cbs_av1_syntax_template.c @@ -636,6 +636,15 @@ static int FUNC(tile_info)(CodedBitstreamContext *ctx, RWContext *rw, current->tile_rows_log2; current->tile_rows = (sb_rows + tile_height_sb - 1) / tile_height_sb; +for (i = 0; i < current->tile_cols - 1; i++) +infer(width_in_sbs_minus_1[i], tile_width_sb - 1); +infer(width_in_sbs_minus_1[i], + sb_cols - (current->tile_cols - 1) * tile_width_sb - 1); +for (i = 0; i < current->tile_rows - 1; i++) +infer(height_in_sbs_minus_1[i], tile_height_sb - 1); +infer(height_in_sbs_minus_1[i], + sb_rows - (current->tile_rows - 1) * tile_height_sb - 1); + LGTM, could you help to merge this patch? I will submit 2nd version of VAAPI AV1 decoder patch base on this change. Thanks. Applied - thank you for the review! - Mark ___ 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: add mca demuxer
On 2020-09-01 17:21, Carl Eugen Hoyos wrote:
Am Mi., 2. Sept. 2020 um 01:17 Uhr schrieb :
On 2020-09-01 17:07, Carl Eugen Hoyos wrote:
> Am Mi., 2. Sept. 2020 um 00:58 Uhr schrieb :
>
>> +static int probe(const AVProbeData *p)
>> +{
>> +if (AV_RL32(p->buf) == MKTAG('M', 'A', 'D', 'P') &&
>> +(AV_RL16(p->buf + 4) > 0x00 || AV_RL16(p->buf + 4) <= 0xff))
>> +return AVPROBE_SCORE_MAX / 3 * 2;
>> +return 0;
>
> At least add the version check from read_header(),
> you could also add the "sanity checks" you do
> there to this function.
Thanks for the extremely quick response! I agree I can probably move
the
version check to `probe()`.
You can copy it.
However the other checks require reading far into the header, I don't
know if it's appropriate to do that in `probe()`.
You can check the size.
Carl Eugen
Thanks for the advice! However, I discovered I made a mistake that led
to this issue: the version field should be a `uint16_t` instead of
`int16_t`. Also, I actually checked the version in `probe()` with
`AV_RL16(p->buf + 4) <= 0xff`.
For the other checks, I have referenced other demuxers that decode
similar formats (namely `fsb` and `brstm`), and I found that they didn't
do these checks in `probe` but rather in `read_header`.
I am very sorry for the confusion. I have fixed these issues in my local
repository and I will send a new version of the patch if no further
issues are discovered.
Thanks,
Zixing
___
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 0/1] avformat: add mca demuxer
From: Zixing Liu This patch adds the MCA demuxer to FFmpeg. MCA is a format used by Capcom in some of their games, the audio format is always ADPCM_THP_LE in these files. This MCA demuxer implementation currently supports MCA version 1-5 and can partially handle some of the version 5 files with minor damages to the file header. There are some sample files I have prepared that you can try: * (version 4) https://streams.videolan.org/ffmpeg/incoming/bgm18_1632b.mca * (version 5) https://streams.videolan.org/ffmpeg/incoming/bgm020_1632.mca N.B. Files using version 1 to 3 are harder to find, I don't seem to find any to test. As required by https://ffmpeg.org/developer.html#New-codecs-or-formats-checklist, the minor version of libavformat is updated to 52. Patch version 2 changes: * changed version field to uint16_t and remove redundant compares Zixing Liu (1): avformat: add mca demuxer Changelog| 1 + doc/general.texi | 2 + libavformat/Makefile | 1 + libavformat/allformats.c | 1 + libavformat/mca.c| 228 +++ libavformat/version.h| 4 +- 6 files changed, 235 insertions(+), 2 deletions(-) create mode 100644 libavformat/mca.c -- 2.28.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] [PATCH v2 1/1] avformat: add mca demuxer
From: Zixing Liu
Signed-off-by: liushuyu
---
Changelog| 1 +
doc/general.texi | 2 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/mca.c| 240 +++
libavformat/version.h| 4 +-
6 files changed, 247 insertions(+), 2 deletions(-)
create mode 100644 libavformat/mca.c
diff --git a/Changelog b/Changelog
index 7467e73..ae4219f 100644
--- a/Changelog
+++ b/Changelog
@@ -15,6 +15,7 @@ version :
- Argonaut Games ASF muxer
- AV1 Low overhead bitstream format demuxer
- RPZA video encoder
+- MCA demuxer
version 4.3:
diff --git a/doc/general.texi b/doc/general.texi
index d618565..fa76ed4 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -524,6 +524,8 @@ library:
@tab Metadata in text format.
@item MAXIS XA @tab @tab X
@tab Used in Sim City 3000; file extension .xa.
+@item MCA @tab @tab X
+@tab Used in some games from Capcom; file extension .mca.
@item MD Studio @tab @tab X
@item Metal Gear Solid: The Twin Snakes @tab @tab X
@item Megalux Frame @tab @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index cbb33fe..7f5ab21 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -305,6 +305,7 @@ OBJS-$(CONFIG_MATROSKA_MUXER)+= matroskaenc.o
matroska.o \
av1.o avc.o hevc.o \
flacenc_header.o avlanguage.o \
vorbiscomment.o wv.o
+OBJS-$(CONFIG_MCA_DEMUXER) += mca.o
OBJS-$(CONFIG_MCC_DEMUXER) += mccdec.o subtitles.o
OBJS-$(CONFIG_MD5_MUXER) += hashenc.o
OBJS-$(CONFIG_MGSTS_DEMUXER) += mgsts.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0aa9dd7..8a71de6 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -232,6 +232,7 @@ extern AVInputFormat ff_lvf_demuxer;
extern AVInputFormat ff_lxf_demuxer;
extern AVInputFormat ff_m4v_demuxer;
extern AVOutputFormat ff_m4v_muxer;
+extern AVInputFormat ff_mca_demuxer;
extern AVInputFormat ff_mcc_demuxer;
extern AVOutputFormat ff_md5_muxer;
extern AVInputFormat ff_matroska_demuxer;
diff --git a/libavformat/mca.c b/libavformat/mca.c
new file mode 100644
index 000..dbbb374
--- /dev/null
+++ b/libavformat/mca.c
@@ -0,0 +1,240 @@
+/*
+ * MCA demuxer
+ * Copyright (c) 2020 Zixing Liu
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/intreadwrite.h"
+#include "libavcodec/bytestream.h"
+#include "avformat.h"
+#include "internal.h"
+
+typedef struct MCADemuxContext {
+uint32_t block_count;
+uint16_t block_size;
+uint32_t coef_offset;
+uint32_t current_block;
+uint32_t data_start;
+uint32_t samples_per_block;
+} MCADemuxContext;
+
+static int probe(const AVProbeData *p)
+{
+if (AV_RL32(p->buf) == MKTAG('M', 'A', 'D', 'P') &&
+AV_RL16(p->buf + 4) <= 0xff)
+return AVPROBE_SCORE_MAX / 3 * 2;
+return 0;
+}
+
+static int read_header(AVFormatContext *s)
+{
+AVStream *st;
+MCADemuxContext *m = s->priv_data;
+int64_t file_size = 0;
+uint16_t version = 0;
+uint32_t header_size, data_size, data_offset, loop_start, loop_end,
+nb_samples, nb_metadata = 0;
+int ch;
+int ret = AVERROR_EOF;
+
+st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
+
+// parse file headers
+avio_skip(s->pb, 0x4); // skip the file magic
+version = avio_rl16(s->pb); // offset 0x4
+avio_skip(s->pb, 0x2); // padding
+st->codecpar->channels = avio_r8(s->pb);// offset 0x8
+avio_skip(s->pb, 0x1); // padding
+m->block_size = avio_rl16(s->pb); // offset 0xa
+nb_samples = avio_rl32(s->pb); // offset 0xc
+st->codecpar->sample_rate = avio_rl32(s->pb); // offset 0x10
+loop_start = avio_rl32(s->pb); // offset 0x14
+loop_end = avio_rl32(s->pb);// offset 0x18
+header_size = avio_rl32(s->pb); // offset 0x1c
+data_size = avio_rl32(s->pb); /
[FFmpeg-devel] bug report in QSV's QVBR rate control
Hi,
I found a bug in libavcodec/qsvenc.c. You know, QSV has several
bitrate control modes (CBR, VBR, .. and so on). The bug is bitrate
setting in QVBR.
In the original code, bitrate value is set in "mfx.MaxKbps". Actually,
it must be "mfx.TargetKbps". As a result, FFmpeg's QVBR always works
in quite low bitrate (ignoring user set bitrate value).
Here is the patch for ffmpeg-4.3.1. (Since MaxKbos has no effects or
side-effects in QVBR, we can leave it as is.)
Best regards
diff --strip-trailing-cr -uNr ffmpeg-4.3.1.orig/libavcodec/qsvenc.c
ffmpeg-4.3.1/libavcodec/qsvenc.c
--- ffmpeg-4.3.1.orig/libavcodec/qsvenc.c 2020-07-11 19:39:30.0 +0900
+++ ffmpeg-4.3.1/libavcodec/qsvenc.c2020-08-03 19:29:41.317275300 +0900
@@ -616,8 +616,10 @@
q->param.mfx.MaxKbps = max_bitrate_kbps /
brc_param_multiplier;
q->param.mfx.BRCParamMultiplier = brc_param_multiplier;
#if QSV_HAVE_QVBR
-if (q->param.mfx.RateControlMethod == MFX_RATECONTROL_QVBR)
+if (q->param.mfx.RateControlMethod == MFX_RATECONTROL_QVBR) {
+q->param.mfx.TargetKbps = q->param.mfx.MaxKbps;
q->extco3.QVBRQuality = av_clip(avctx->global_quality, 0, 51);
+}
#endif
break;
case MFX_RATECONTROL_CQP:
@@ -652,6 +654,10 @@
#endif
}
--
Makoto KIMURA
email : makoto.kim...@gmail.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] lavc/qsvdec: allow qsv decoders to use initialized device
qsv decoders did not allow to use devices explicitly initialized on
the command line and actually were using default device. This starts
to cause confusion with intel discrete GPUs since in this case decoder
might run on default integrated GPU device (/dev/dri/renderD128) and
encoder on the device specified on the command line (/dev/dri/renderD129).
Example:
ffmpeg -init_hw_device vaapi=va:/dev/dri/renderD129 -init_hw_device qsv=hw@va \
-c:v h264_qsv -i input.h264 -c:v hevc_qsv -y output.h264
Signed-off-by: Dmitry Rogozhkin
---
libavcodec/qsvdec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index fc25dc7..f2fac17 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -47,7 +47,8 @@ const AVCodecHWConfigInternal *ff_qsv_hw_configs[] = {
&(const AVCodecHWConfigInternal) {
.public = {
.pix_fmt = AV_PIX_FMT_QSV,
-.methods = AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX |
+.methods = AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX |
+ AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX |
AV_CODEC_HW_CONFIG_METHOD_AD_HOC,
.device_type = AV_HWDEVICE_TYPE_QSV,
},
--
1.8.3.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] lavc/qsvdec: allow qsv decoders to use initialized device
> -Original Message- > From: ffmpeg-devel On Behalf Of > Dmitry Rogozhkin > Sent: Wednesday, September 2, 2020 4:44 AM > To: ffmpeg-devel@ffmpeg.org > Cc: Dmitry Rogozhkin > Subject: [FFmpeg-devel] [PATCH] lavc/qsvdec: allow qsv decoders to use > initialized device > > qsv decoders did not allow to use devices explicitly initialized on the > command line and actually were using default device. This starts to cause > confusion with intel discrete GPUs since in this case decoder might run on > default integrated GPU device (/dev/dri/renderD128) and encoder on the > device specified on the command line (/dev/dri/renderD129). > > Example: > ffmpeg -init_hw_device vaapi=va:/dev/dri/renderD129 -init_hw_device > qsv=hw@va \ > -c:v h264_qsv -i input.h264 -c:v hevc_qsv -y output.h264 > Hi Dmitry, How about this: -init_hw_device qsv=vad:hw_any,child_device=/dev/dri/renderD128 Unfortunately I do not have one of the new Intel discrete GPUs so I wasn't able to test, but the above parameter is working at least in a way that it fails when the specified child_device is wrong (e.g. Nvidia GPU)). Kind regards, softworkz ___ 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] ffmpeg_qsv: use -hwaccel_device to specify a device for VAAPI backend
According to the FFmpeg documentation, -hwaccel_device can be used to
select a device for hardware acceleration
Example:
ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD129 -c:v h264_qsv \
-i in.h264 -c:v hevc_qsv out.h265
---
fftools/ffmpeg_qsv.c | 8
1 file changed, 8 insertions(+)
diff --git a/fftools/ffmpeg_qsv.c b/fftools/ffmpeg_qsv.c
index 960c88b69d..b7e7ab0e53 100644
--- a/fftools/ffmpeg_qsv.c
+++ b/fftools/ffmpeg_qsv.c
@@ -55,6 +55,14 @@ static int qsv_device_init(InputStream *ist)
return err;
}
+#if CONFIG_VAAPI
+else if (ist->hwaccel_device && !strncmp(ist->hwaccel_device, "/dev/dri/",
9)) {
+err = av_dict_set(&dict, "child_device", ist->hwaccel_device, 0);
+if (err < 0)
+return err;
+}
+#endif
+
err = av_hwdevice_ctx_create(&hw_device_ctx, AV_HWDEVICE_TYPE_QSV,
ist->hwaccel_device, dict, 0);
if (err < 0) {
--
2.25.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] lavc/qsvdec: allow qsv decoders to use initialized device
> -Original Message- > From: ffmpeg-devel On Behalf Of > Soft Works > Sent: Wednesday, September 2, 2020 5:33 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvdec: allow qsv decoders to use > initialized device > > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Dmitry Rogozhkin > > Sent: Wednesday, September 2, 2020 4:44 AM > > To: ffmpeg-devel@ffmpeg.org > > Cc: Dmitry Rogozhkin > > Subject: [FFmpeg-devel] [PATCH] lavc/qsvdec: allow qsv decoders to use > > initialized device > > > > qsv decoders did not allow to use devices explicitly initialized on > > the command line and actually were using default device. This starts > > to cause confusion with intel discrete GPUs since in this case decoder > > might run on default integrated GPU device (/dev/dri/renderD128) and > > encoder on the device specified on the command line > (/dev/dri/renderD129). > > > > Example: > > ffmpeg -init_hw_device vaapi=va:/dev/dri/renderD129 -init_hw_device > > qsv=hw@va \ > > -c:v h264_qsv -i input.h264 -c:v hevc_qsv -y output.h264 > > > > Hi Dmitry, > > How about this: > > -init_hw_device qsv=vad:hw_any,child_device=/dev/dri/renderD128 > I apologize, I picked the wrong thing. The qsv_device parameter is what allows setting the device for a QSV decoder: fmpeg -qsv_device /dev/dri/renderD128 -c:v:0 h264_qsv -hwaccel:v:0 qsv -i INPUT Kind regards, softworkz ___ 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] ffmpeg_qsv: use -hwaccel_device to specify a device for VAAPI backend
> -Original Message- > From: ffmpeg-devel On Behalf Of > Haihao Xiang > Sent: Wednesday, September 2, 2020 6:01 AM > To: ffmpeg-devel@ffmpeg.org > Cc: Haihao Xiang > Subject: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device to > specify a device for VAAPI backend > > According to the FFmpeg documentation, -hwaccel_device can be used to > select a device for hardware acceleration > > Example: > ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD129 -c:v h264_qsv \ -i > in.h264 -c:v hevc_qsv out.h265 No. The docs say about hwaccel_device It can either refer to an existing device created with -init_hw_device by name, => /dev/dri/renderD129 is not an existing device name or it can create a new device as if ‘-init_hw_device’ type:hwaccel_device were called immediately before. => /dev/dri/renderD129 is not a valid string for init_hw_device Hence, the patch doesn't make sense. Kind regards, softworkz ___ 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] ffmpeg_qsv: use -hwaccel_device to specify a device for VAAPI backend
On Wed, 2020-09-02 at 04:20 +, Soft Works wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Haihao Xiang > > Sent: Wednesday, September 2, 2020 6:01 AM > > To: ffmpeg-devel@ffmpeg.org > > Cc: Haihao Xiang > > Subject: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device to > > specify a device for VAAPI backend > > > > According to the FFmpeg documentation, -hwaccel_device can be used to > > select a device for hardware acceleration > > > > Example: > > ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD129 -c:v h264_qsv \ -i > > in.h264 -c:v hevc_qsv out.h265 > > No. The docs say about hwaccel_device > > It can either refer to an existing device created with > -init_hw_device by name, > > => /dev/dri/renderD129 is not an existing device name > > or it can create a new device as if ‘-init_hw_device’ > type:hwaccel_device were called immediately before. > > => /dev/dri/renderD129 is not a valid string for init_hw_device > > > Hence, the patch doesn't make sense. in https://trac.ffmpeg.org/wiki/Hardware/VAAPI, If only one stream is being used, -hwaccel_device can also accept a device path directly ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i ... I think it can be applied to qsv too. > > Kind regards, > softworkz > ___ > 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] SCTE-35 implementation already (bounty)
Looking for SCTE-35 pass through implementation: 1. Extract SCTE-35 from MPEG-TS. 2. Translate timing of the original SCTE-35 events to match timing in the output file appropriately or keep timing as is. 3. Signal encoder to force key frames at the boundaries of the SCTE-35 event. 4. Inject SCTE-35 messaging into output MP4 files as emsg and into MPD and M3U8 manifests if/as needed. More info: https://www.w3.org/TR/media-timed-events/#scte-35 https://www.tvtechnology.com/opinions/scte10435-and-beyond-a-look-at-ad-insertion-in-an-ott-world source TS file with SCTE-35 also saved as ES and XML: https://www.mediafire.com/folder/zv20csqeo1ixt/ Bounty of $2,500.00 USD (up to Oct 2020) ___ 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] lavc/qsvdec: allow qsv decoders to use initialized device
> -Original Message- > From: ffmpeg-devel On Behalf Of > Soft Works > Sent: Wednesday, September 2, 2020 6:13 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvdec: allow qsv decoders to use > initialized device > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Dmitry Rogozhkin > > > Sent: Wednesday, September 2, 2020 4:44 AM > > > To: ffmpeg-devel@ffmpeg.org > > > Cc: Dmitry Rogozhkin > > > Subject: [FFmpeg-devel] [PATCH] lavc/qsvdec: allow qsv decoders to > > > use initialized device > > > > > > qsv decoders did not allow to use devices explicitly initialized on > > > the command line and actually were using default device. This starts > > > to cause confusion with intel discrete GPUs since in this case > > > decoder might run on default integrated GPU device > > > (/dev/dri/renderD128) and encoder on the device specified on the > > > command line > > (/dev/dri/renderD129). > > > > > > Example: > > > ffmpeg -init_hw_device vaapi=va:/dev/dri/renderD129 -init_hw_device > > > qsv=hw@va \ > > > -c:v h264_qsv -i input.h264 -c:v hevc_qsv -y output.h264 > I apologize, I picked the wrong thing. The qsv_device parameter is what > allows setting the device for a QSV decoder: > > fmpeg -qsv_device /dev/dri/renderD128 -c:v:0 h264_qsv -hwaccel:v:0 qsv -i > INPUT > > Kind regards, > softworkz Here's the commit where the parameter had been added: https://github.com/FFmpeg/FFmpeg/commit/1a79b8f8d2b5d26c60c237d6e585873238e46914 ___ 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 1/1] avformat: add mca demuxer
liush...@aosc.io:
> From: Zixing Liu
>
> Signed-off-by: liushuyu
> ---
> Changelog| 1 +
> doc/general.texi | 2 +
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/mca.c| 240 +++
> libavformat/version.h| 4 +-
> 6 files changed, 247 insertions(+), 2 deletions(-)
> create mode 100644 libavformat/mca.c
>
> diff --git a/Changelog b/Changelog
> index 7467e73..ae4219f 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -15,6 +15,7 @@ version :
> - Argonaut Games ASF muxer
> - AV1 Low overhead bitstream format demuxer
> - RPZA video encoder
> +- MCA demuxer
>
>
> version 4.3:
> diff --git a/doc/general.texi b/doc/general.texi
> index d618565..fa76ed4 100644
> --- a/doc/general.texi
> +++ b/doc/general.texi
> @@ -524,6 +524,8 @@ library:
> @tab Metadata in text format.
> @item MAXIS XA @tab @tab X
> @tab Used in Sim City 3000; file extension .xa.
> +@item MCA @tab @tab X
> +@tab Used in some games from Capcom; file extension .mca.
> @item MD Studio @tab @tab X
> @item Metal Gear Solid: The Twin Snakes @tab @tab X
> @item Megalux Frame @tab @tab X
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index cbb33fe..7f5ab21 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -305,6 +305,7 @@ OBJS-$(CONFIG_MATROSKA_MUXER)+= matroskaenc.o
> matroska.o \
> av1.o avc.o hevc.o \
> flacenc_header.o avlanguage.o \
> vorbiscomment.o wv.o
> +OBJS-$(CONFIG_MCA_DEMUXER) += mca.o
> OBJS-$(CONFIG_MCC_DEMUXER) += mccdec.o subtitles.o
> OBJS-$(CONFIG_MD5_MUXER) += hashenc.o
> OBJS-$(CONFIG_MGSTS_DEMUXER) += mgsts.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 0aa9dd7..8a71de6 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -232,6 +232,7 @@ extern AVInputFormat ff_lvf_demuxer;
> extern AVInputFormat ff_lxf_demuxer;
> extern AVInputFormat ff_m4v_demuxer;
> extern AVOutputFormat ff_m4v_muxer;
> +extern AVInputFormat ff_mca_demuxer;
> extern AVInputFormat ff_mcc_demuxer;
> extern AVOutputFormat ff_md5_muxer;
> extern AVInputFormat ff_matroska_demuxer;
> diff --git a/libavformat/mca.c b/libavformat/mca.c
> new file mode 100644
> index 000..dbbb374
> --- /dev/null
> +++ b/libavformat/mca.c
> @@ -0,0 +1,240 @@
> +/*
> + * MCA demuxer
> + * Copyright (c) 2020 Zixing Liu
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include "libavutil/intreadwrite.h"
> +#include "libavcodec/bytestream.h"
You don't seem to be using anything from this header.
> +#include "avformat.h"
> +#include "internal.h"
> +
> +typedef struct MCADemuxContext {
> +uint32_t block_count;
> +uint16_t block_size;
> +uint32_t coef_offset;
> +uint32_t current_block;
> +uint32_t data_start;
> +uint32_t samples_per_block;
> +} MCADemuxContext;
> +
> +static int probe(const AVProbeData *p)
> +{
> +if (AV_RL32(p->buf) == MKTAG('M', 'A', 'D', 'P') &&
> +AV_RL16(p->buf + 4) <= 0xff)
> +return AVPROBE_SCORE_MAX / 3 * 2;
> +return 0;
> +}
> +
> +static int read_header(AVFormatContext *s)
> +{
> +AVStream *st;
> +MCADemuxContext *m = s->priv_data;
> +int64_t file_size = 0;
> +uint16_t version = 0;
> +uint32_t header_size, data_size, data_offset, loop_start, loop_end,
> +nb_samples, nb_metadata = 0;
> +int ch;
> +int ret = AVERROR_EOF;
This value is never used.
> +
> +st = avformat_new_stream(s, NULL);
> +if (!st)
> +return AVERROR(ENOMEM);
> +st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
If you used a dedicated variable (common name would be par) to access
st->codecpar, the lengths of the lines below would not have outliers.
> +
> +// parse file headers
> +avio_skip(s->pb, 0x4); // skip the file magic
> +version = avio_rl16(s->pb); // offset 0x4
> +avio_skip(s->pb, 0x2);
Re: [FFmpeg-devel] [PATCH] lavc/qsvdec: allow qsv decoders to use initialized device
On Wed, 2020-09-02 at 04:32 +, Soft Works wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Soft Works > > Sent: Wednesday, September 2, 2020 6:13 AM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvdec: allow qsv decoders > > to use > > initialized device > > > > > > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf > > > > Of > > > > Dmitry Rogozhkin > > > > Sent: Wednesday, September 2, 2020 4:44 AM > > > > To: ffmpeg-devel@ffmpeg.org > > > > Cc: Dmitry Rogozhkin > > > > Subject: [FFmpeg-devel] [PATCH] lavc/qsvdec: allow qsv decoders > > > > to > > > > use initialized device > > > > > > > > qsv decoders did not allow to use devices explicitly > > > > initialized on > > > > the command line and actually were using default device. This > > > > starts > > > > to cause confusion with intel discrete GPUs since in this case > > > > decoder might run on default integrated GPU device > > > > (/dev/dri/renderD128) and encoder on the device specified on > > > > the > > > > command line > > > > > > (/dev/dri/renderD129). > > > > > > > > Example: > > > > ffmpeg -init_hw_device vaapi=va:/dev/dri/renderD129 > > > > -init_hw_device > > > > qsv=hw@va \ > > > > -c:v h264_qsv -i input.h264 -c:v hevc_qsv -y output.h264 > > I apologize, I picked the wrong thing. The qsv_device parameter is > > what > > allows setting the device for a QSV decoder: > > > > fmpeg -qsv_device /dev/dri/renderD128 -c:v:0 h264_qsv -hwaccel:v:0 > > qsv -i > > INPUT > > > > Kind regards, > > softworkz > > Here's the commit where the parameter had been added: > https://github.com/FFmpeg/FFmpeg/commit/1a79b8f8d2b5d26c60c237d6e585873238e46914 I am aware of this option. > -qsv_device /dev/dri/renderD129 By itself this don’t work. Both decoder and encoder will run on /dev/dri/renderD128 instead. > -hwaccel qsv -qsv_device /dev/dri/renderD129 Adding -hwaccel helps. This works. However, to me this is non- intuitive: why qsv_device should be used instead of hwaccel_device while ffmpeg help gives a different hint: -hwaccel hwaccel name use HW accelerated decoding -hwaccel_device devicename select a device for HW acceleration From this perspective Haihao’s patch which is currently on the mailing list makes sense to me it just simplifies things. Unfortunately ffmpeg device selection options are quite confusing. One of the problems with -qsv_device is that the following pure encoding won’t work: ffmpeg -hwaccel qsv -qsv_device /dev/dri/renderD129 -f rawvideo -pix_fmt yuv420p -s:v 1920x1080 -r 30 -i a.yuv -c:v h264_qsv out.h264 Execution will happen on /dev/dri/renderD128 instead. To make it work on 129 you will need to run something like the following: ffmpeg -init_hw_device vaapi=va:/dev/dri/renderD129 -init_hw_device qsv=hw@va -f rawvideo -pix_fmt yuv420p -s:v 1920x1080 -r 30 -i a.yuv -c:v h264_qsv out.h264 This will work. But returning back to transcoding case: there are 2 significantly different command lines which should be used for transcoding and encoding to make things run on /dev/dri/renderD129. This is inconvenient to handle… And additionally there is also -filter_hw_device which also contributes to the complication. Also there are special marks in documentation for the qsv “Unlike most other values, this option does not enable accelerated decoding (that is used automatically whenever a qsv decoder is selected), but accelerated transcoding, without copying the frames into the system memory. For it to work, both the decoder and the encoder must support QSV acceleration and no filters must be used.” One missing thing seems to be documentation on the scope of -init_hw_device option applicability. This seems to be a global option, but in the example from the commit message encoder actually takes device from it, but decoder just ignores it and goes with default device. Why? This does not seem to be right. Can someone, please, shine the light on how all these device selection options were supposed to work? /Eventually my patch tries to fix behavior in accordance with my understanding of the supposed behavior./ > > ___ > 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".
