[FFmpeg-devel] [PATCH] w32pthread: fix signature of WinRT version of thread worker
The callback passed to CreateThread is not the same as with _beginthreadex().
This WinRT check could be removed if Win8 WinRT is not maintained
as _beginthreadex() is now available [1]
[1]
https://learn.microsoft.com/en-us/cpp/cppcx/crt-functions-not-supported-in-universal-windows-platform-apps?view=msvc-160#windows-8x-store-apps-and-windows-phone-8x-apps
---
compat/w32pthreads.h | 4
1 file changed, 4 insertions(+)
diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
index 6405e72b64..364eebfe4e 100644
--- a/compat/w32pthreads.h
+++ b/compat/w32pthreads.h
@@ -66,7 +66,11 @@ typedef CONDITION_VARIABLE pthread_cond_t;
#define PTHREAD_CANCEL_ENABLE 1
#define PTHREAD_CANCEL_DISABLE 0
+#if HAVE_WINRT
+static av_unused DWORD WINAPI attribute_align_arg win32thread_worker(void *arg)
+#else
static av_unused unsigned __stdcall attribute_align_arg
win32thread_worker(void *arg)
+#endif
{
pthread_t *h = (pthread_t*)arg;
h->ret = h->func(h->arg);
--
2.39.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".
[FFmpeg-devel] [PATCH 12/12] avformat/matroska: add missing elements
They are not mapped into structures but the IDs and their allowed position is set properly. --- libavformat/matroska_ids.h | 93 ++ libavformat/matroskasem.c | 58 +--- libavformat/matroskasem.h | 2 +- 3 files changed, 145 insertions(+), 8 deletions(-) diff --git a/libavformat/matroska_ids.h b/libavformat/matroska_ids.h index 59dda4da9d..365ee05ad6 100644 --- a/libavformat/matroska_ids.h +++ b/libavformat/matroska_ids.h @@ -41,6 +41,13 @@ /* IDs in the info master */ #define MATROSKA_ID_TIMECODESCALE 0x2AD7B1 +#define MATROSKA_ID_SEGMENTFILENAME 0x7384 +#define MATROSKA_ID_PREVUID 0x3CB923 +#define MATROSKA_ID_PREVFILENAME0x3C83AB +#define MATROSKA_ID_NEXTUID 0x3EB923 +#define MATROSKA_ID_NEXTFILENAME0x3E83BB +#define MATROSKA_ID_SEGMENTFAMILY 0x +#define MATROSKA_ID_CHAPTERTRANSLATE0x6924 #define MATROSKA_ID_DURATION0x4489 #define MATROSKA_ID_TITLE 0x7BA9 #define MATROSKA_ID_WRITINGAPP 0x5741 @@ -48,6 +55,11 @@ #define MATROSKA_ID_DATEUTC 0x4461 #define MATROSKA_ID_SEGMENTUID 0x73A4 +/* IDs in the chaptertranslate master */ +#define MATROSKA_ID_CHAPTERTRANSLATEID 0x69A5 +#define MATROSKA_ID_CHAPTERTRANSLATECODEC 0x69BF +#define MATROSKA_ID_CHAPTERTRANSLATEEDITIONUID 0x69FC + /* IDs in the tracks master */ #define MATROSKA_ID_TRACKENTRY 0xAE @@ -63,19 +75,31 @@ #define MATROSKA_ID_TRACKFLAGTEXTDESCRIPTIONS 0x55AD #define MATROSKA_ID_TRACKFLAGORIGINAL 0x55AE #define MATROSKA_ID_TRACKFLAGCOMMENTARY 0x55AF +#define MATROSKA_ID_TRACKDEFAULTDECODEDFIELDDURATION 0x234E7A #define MATROSKA_ID_TRACKTIMECODESCALE 0x23314F +#define MATROSKA_ID_TRACKOFFSET 0x537F #define MATROSKA_ID_TRACKMAXBLKADDID0x55EE #define MATROSKA_ID_TRACKBLKADDMAPPING 0x41E4 #define MATROSKA_ID_TRACKNAME 0x536E #define MATROSKA_ID_TRACKLANGUAGE 0x22B59C +#define MATROSKA_ID_TRACKLANGUAGEIETF 0x22B59D #define MATROSKA_ID_CODECID 0x86 #define MATROSKA_ID_CODECPRIVATE0x63A2 #define MATROSKA_ID_CODECNAME 0x258688 +#define MATROSKA_ID_TRACKATTACHMENTLINK 0x7446 +#define MATROSKA_ID_CODECSETTINGS 0x3A9697 #define MATROSKA_ID_CODECINFOURL0x3B4040 #define MATROSKA_ID_CODECDOWNLOADURL0x26B240 #define MATROSKA_ID_CODECDECODEALL 0xAA +#define MATROSKA_ID_TRACKOVERLAY0x6FAB #define MATROSKA_ID_CODECDELAY 0x56AA #define MATROSKA_ID_SEEKPREROLL 0x56BB +#define MATROSKA_ID_TRACKTRANSLATE 0x6624 +#define MATROSKA_ID_TRICKTRACKUID 0xC0 +#define MATROSKA_ID_TRICKTRACKSEGMENTUID 0xC1 +#define MATROSKA_ID_TRICKTRACKFLAG 0xC6 +#define MATROSKA_ID_TRICKMASTERTRACKUID 0xC7 +#define MATROSKA_ID_TRICKMASTERTRACKSEGMENTUID 0xC4 #define MATROSKA_ID_TRACKFLAGENABLED0xB9 #define MATROSKA_ID_TRACKFLAGDEFAULT0x88 #define MATROSKA_ID_TRACKFLAGFORCED 0x55AA @@ -115,9 +139,11 @@ #define MATROSKA_ID_ENCODINGSIGNATURE 0x47E3 /* IDs in the contentencaessettings master */ +#define MATROSKA_ID_TRACKAESSETTINGSCIPHERMODE 0x47E8 /* IDs in the trackoperation master */ #define MATROSKA_ID_TRACKCOMBINEPLANES 0xE3 +#define MATROSKA_ID_TRACKJOINBLOCKS 0xE9 /* IDs in the trackcombineplanes master */ #define MATROSKA_ID_TRACKPLANE 0xE4 @@ -126,6 +152,14 @@ #define MATROSKA_ID_TRACKPLANEUID 0xE5 #define MATROSKA_ID_TRACKPLANETYPE 0xE6 +/* IDs in the trackjoinblocks master */ +#define MATROSKA_ID_TRACKJOINUID0xED + +/* IDs in the tracktranslate master */ +#define MATROSKA_ID_TRACKTRANSLATETRACKID 0x66A5 +#define MATROSKA_ID_TRACKTRANSLATECODEC 0x66BF +#define MATROSKA_ID_TRACKTRANSLATEEDITIONUID 0x66FC + /* IDs in the trackvideo master */ #define MATROSKA_ID_VIDEOFRAMERATE 0x2383E3 #define MATROSKA_ID_VIDEODISPLAYWIDTH 0x54B0 @@ -141,8 +175,10 @@ #define MATROSKA_ID_VIDEOFIELDORDER 0x9D #define MATROSKA_ID_VIDEOSTEREOMODE 0x53B8 #define MATROSKA_ID_VIDEOALPHAMODE 0x53C0 +#define MATROSKA_ID_VIDEOOLDSTEREOMODE 0x53B9 #define MATROSKA_ID_VIDEOASPECTRATIO0x54B3 #define MATROSKA_ID_VIDEOCOLORSPACE 0x2EB524 +#define MATROSKA_ID_VIDEOGAMMAVALUE 0x2FB523 #define MATROSKA_ID_VIDEOCOLOR 0x55B0 #define MATROSKA_ID_VIDEOPROJECTION 0x7670 @@ -184,6 +220,7 @@ /* IDs in the trackaudio master */ #define MATROSKA_ID_AUDIOSAMPLINGFREQ 0xB5 #define MATROSKA_ID_AUDIOOUTSAMPLINGFREQ 0x78B5 +#define MATROSKA_ID_AUDIOCHANNELPOSITIONS 0x7D7B #define MATROSKA_ID_AUDIOBITDEPTH 0x6264 #define MATROSKA_ID_AUDIOCHANNELS 0x9F @@ -200,6 +237,14 @@ #define MATROSKA_ID_CUERELATIVEPOSITION 0xF0 #define MATROSKA_ID_CUEDURATION 0xB2 #define MATROSKA_ID_CUEBLOCKNUMBER 0x5378 +#define MATROSKA_ID_CUECODECSTATE 0xEA +#define MATROSKA_ID_CUEREFERENCE0xDB + +/* IDs in the cuereference master */
[FFmpeg-devel] [PATCH 11/12] avformat/matroska: only export a few elements.
---
libavformat/matroskasem.c | 69 +++
libavformat/matroskasem.h | 7 +---
2 files changed, 50 insertions(+), 26 deletions(-)
diff --git a/libavformat/matroskasem.c b/libavformat/matroskasem.c
index 0f4455058a..cdef0dbff4 100644
--- a/libavformat/matroskasem.c
+++ b/libavformat/matroskasem.c
@@ -37,6 +37,35 @@
#define CHILD_OF(parent) { .def = { .n = parent } }
+// The following forward declarations need their size because
+// a tentative definition with internal linkage must not be an
+// incomplete type (6.7.2 in C90, 6.9.2 in C99).
+// Removing the sizes breaks MSVC.
+static EbmlSyntax matroska_seekhead[2];
+static EbmlSyntax matroska_info[8];
+static EbmlSyntax matroska_blockadditions[2];
+// static EbmlSyntax matroska_blockgroup[8];
+// static EbmlSyntax matroska_cluster_parsing[8];
+static EbmlSyntax matroska_track_video_color[15];
+static EbmlSyntax matroska_track_video[19];
+static EbmlSyntax matroska_track_combine_planes[2];
+static EbmlSyntax matroska_track_operation[2];
+static EbmlSyntax matroska_track_encoding_encryption[8];
+static EbmlSyntax matroska_track_encoding[6];
+static EbmlSyntax matroska_track_encodings[2];
+static EbmlSyntax matroska_track[33];
+static EbmlSyntax matroska_tracks[2];
+static EbmlSyntax matroska_index_pos[6];
+static EbmlSyntax matroska_index_entry[3];
+static EbmlSyntax matroska_index[2];
+static EbmlSyntax matroska_attachments[2];
+static EbmlSyntax matroska_chapter_entry[9];
+static EbmlSyntax matroska_chapter[6];
+static EbmlSyntax matroska_chapters[2];
+static EbmlSyntax matroska_tag[3];
+static EbmlSyntax matroska_tags[2];
+
+
static EbmlSyntax ebml_header[] = {
{ EBML_ID_EBMLREADVERSION,EBML_UINT, 0, 0, offsetof(Ebml, version),
{ .u = EBML_VERSION } },
{ EBML_ID_EBMLMAXSIZELENGTH, EBML_UINT, 0, 0, offsetof(Ebml, max_size),
{ .u = 8 } },
@@ -77,7 +106,7 @@ static EbmlSyntax matroska_mastering_meta[] = {
CHILD_OF(matroska_track_video_color)
};
-EbmlSyntax matroska_track_video_color[] = {
+static EbmlSyntax matroska_track_video_color[] = {
{ MATROSKA_ID_VIDEOCOLORMATRIXCOEFF, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoColor, matrix_coefficients), { .u =
AVCOL_SPC_UNSPECIFIED } },
{ MATROSKA_ID_VIDEOCOLORBITSPERCHANNEL, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoColor, bits_per_channel) },
{ MATROSKA_ID_VIDEOCOLORCHROMASUBHORZ,EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoColor, chroma_sub_horz) },
@@ -95,7 +124,7 @@ EbmlSyntax matroska_track_video_color[] = {
CHILD_OF(matroska_track_video)
};
-EbmlSyntax matroska_track_video[] = {
+static EbmlSyntax matroska_track_video[] = {
{ MATROSKA_ID_VIDEOFRAMERATE, EBML_FLOAT, 0, 0,
offsetof(MatroskaTrackVideo, frame_rate) },
{ MATROSKA_ID_VIDEODISPLAYWIDTH, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideo, display_width), { .u = -1 } },
{ MATROSKA_ID_VIDEODISPLAYHEIGHT, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideo, display_height), { .u = -1 } },
@@ -117,18 +146,18 @@ EbmlSyntax matroska_track_video[] = {
CHILD_OF(matroska_track)
};
-EbmlSyntax matroska_track_plane[] = {
+static EbmlSyntax matroska_track_plane[] = {
{ MATROSKA_ID_TRACKPLANEUID, EBML_UINT, 0, 0,
offsetof(MatroskaTrackPlane, uid) },
{ MATROSKA_ID_TRACKPLANETYPE, EBML_UINT, 0, 0,
offsetof(MatroskaTrackPlane, type) },
CHILD_OF(matroska_track_combine_planes)
};
-EbmlSyntax matroska_track_combine_planes[] = {
+static EbmlSyntax matroska_track_combine_planes[] = {
{ MATROSKA_ID_TRACKPLANE, EBML_NEST, 0,
sizeof(MatroskaTrackPlane), offsetof(MatroskaTrackOperation, combine_planes), {
.n = matroska_track_plane } },
CHILD_OF(matroska_track_operation)
};
-EbmlSyntax matroska_track_operation[] = {
+static EbmlSyntax matroska_track_operation[] = {
{ MATROSKA_ID_TRACKCOMBINEPLANES, EBML_NEST, 0, 0, 0, { .n =
matroska_track_combine_planes } },
CHILD_OF(matroska_track)
};
@@ -150,7 +179,7 @@ static EbmlSyntax matroska_track_encoding_compression[] = {
CHILD_OF(matroska_track_encoding)
};
-EbmlSyntax matroska_track_encoding[] = {
+static EbmlSyntax matroska_track_encoding[] = {
{ MATROSKA_ID_ENCODINGSCOPE, EBML_UINT, 0, 0,
offsetof(MatroskaTrackEncoding, scope), { .u = 1 } },
{ MATROSKA_ID_ENCODINGTYPE, EBML_UINT, 0, 0,
offsetof(MatroskaTrackEncoding, type) },
{ MATROSKA_ID_ENCODINGCOMPRESSION,EBML_NEST, 0, 0,
offsetof(MatroskaTrackEncoding, compression), { .n =
matroska_track_encoding_compression } },
@@ -159,12 +188,12 @@ EbmlSyntax matroska_track_encoding[] = {
CHILD_OF(matroska_track_encodings)
};
-EbmlSyntax matroska_track_encodings[] = {
+static EbmlSyntax matroska_track_encodings[] = {
{ MATROSKA_ID_TRACKCONTENTENCODING, EBML_NEST, 0,
sizeof(MatroskaTrackEncoding), offsetof(MatroskaTrack, encodings), { .n =
[FFmpeg-devel] [PATCH 09/12] avformat/matroskasem: reorder some EbmlSyntax elements
So it's easier to match with the XSLT ordering which has limited possibilities
(15 max criteria for all the syntax tables).
No functional changes.
---
libavformat/matroskasem.c | 40 +++
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/libavformat/matroskasem.c b/libavformat/matroskasem.c
index f1afe4d570..b54328796d 100644
--- a/libavformat/matroskasem.c
+++ b/libavformat/matroskasem.c
@@ -101,10 +101,6 @@ EbmlSyntax matroska_track_video[] = {
{ MATROSKA_ID_VIDEODISPLAYHEIGHT, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideo, display_height), { .u=-1 } },
{ MATROSKA_ID_VIDEOPIXELWIDTH, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideo, pixel_width) },
{ MATROSKA_ID_VIDEOPIXELHEIGHT,EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideo, pixel_height) },
-{ MATROSKA_ID_VIDEOCOLORSPACE, EBML_BIN, 0, 0,
offsetof(MatroskaTrackVideo, color_space) },
-{ MATROSKA_ID_VIDEOALPHAMODE, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideo, alpha_mode) },
-{ MATROSKA_ID_VIDEOCOLOR, EBML_NEST, 0,
sizeof(MatroskaTrackVideoColor), offsetof(MatroskaTrackVideo, color), { .n =
matroska_track_video_color } },
-{ MATROSKA_ID_VIDEOPROJECTION, EBML_NEST, 0, 0,
offsetof(MatroskaTrackVideo, projection), { .n =
matroska_track_video_projection } },
{ MATROSKA_ID_VIDEOPIXELCROPB, EBML_NONE },
{ MATROSKA_ID_VIDEOPIXELCROPT, EBML_NONE },
{ MATROSKA_ID_VIDEOPIXELCROPL, EBML_NONE },
@@ -112,6 +108,10 @@ EbmlSyntax matroska_track_video[] = {
{ MATROSKA_ID_VIDEODISPLAYUNIT,EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideo, display_unit), { .u=
MATROSKA_VIDEO_DISPLAYUNIT_PIXELS } },
{ MATROSKA_ID_VIDEOFLAGINTERLACED, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideo, interlaced), { .u =
MATROSKA_VIDEO_INTERLACE_FLAG_UNDETERMINED } },
{ MATROSKA_ID_VIDEOFIELDORDER, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideo, field_order), { .u =
MATROSKA_VIDEO_FIELDORDER_UNDETERMINED } },
+{ MATROSKA_ID_VIDEOALPHAMODE, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideo, alpha_mode) },
+{ MATROSKA_ID_VIDEOCOLORSPACE, EBML_BIN, 0, 0,
offsetof(MatroskaTrackVideo, color_space) },
+{ MATROSKA_ID_VIDEOCOLOR, EBML_NEST, 0,
sizeof(MatroskaTrackVideoColor), offsetof(MatroskaTrackVideo, color), { .n =
matroska_track_video_color } },
+{ MATROSKA_ID_VIDEOPROJECTION, EBML_NEST, 0, 0,
offsetof(MatroskaTrackVideo, projection), { .n =
matroska_track_video_projection } },
{ MATROSKA_ID_VIDEOSTEREOMODE, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideo, stereo_mode), { .u =
MATROSKA_VIDEO_STEREOMODE_TYPE_NB } },
{ MATROSKA_ID_VIDEOASPECTRATIO,EBML_NONE },
CHILD_OF(matroska_track)
@@ -165,10 +165,10 @@ EbmlSyntax matroska_track_encodings[] = {
};
EbmlSyntax matroska_block_addition_mapping[] = {
-{ MATROSKA_ID_BLKADDIDVALUE, EBML_UINT, 0, 0,
offsetof(MatroskaBlockAdditionMapping, value) },
{ MATROSKA_ID_BLKADDIDNAME, EBML_STR, 0, 0,
offsetof(MatroskaBlockAdditionMapping, name) },
{ MATROSKA_ID_BLKADDIDTYPE, EBML_UINT, 0, 0,
offsetof(MatroskaBlockAdditionMapping, type) },
{ MATROSKA_ID_BLKADDIDEXTRADATA, EBML_BIN, 0, 0,
offsetof(MatroskaBlockAdditionMapping, extradata) },
+{ MATROSKA_ID_BLKADDIDVALUE, EBML_UINT, 0, 0,
offsetof(MatroskaBlockAdditionMapping, value) },
CHILD_OF(matroska_track)
};
@@ -191,28 +191,28 @@ EbmlSyntax matroska_track[] = {
{ MATROSKA_ID_TRACKLANGUAGE, EBML_STR, 0, 0,
offsetof(MatroskaTrack, language), { .s = "eng" } },
{ MATROSKA_ID_TRACKDEFAULTDURATION, EBML_UINT, 0, 0,
offsetof(MatroskaTrack, default_duration) },
{ MATROSKA_ID_TRACKTIMECODESCALE,EBML_FLOAT, 0, 0,
offsetof(MatroskaTrack, time_scale), { .f = 1.0 } },
-{ MATROSKA_ID_TRACKFLAGCOMMENTARY, EBML_UINT, 0, 0,
offsetof(MatroskaTrack, flag_comment) },
{ MATROSKA_ID_TRACKFLAGDEFAULT, EBML_UINT, 0, 0,
offsetof(MatroskaTrack, flag_default), { .u = 1 } },
{ MATROSKA_ID_TRACKFLAGFORCED, EBML_UINT, 0, 0,
offsetof(MatroskaTrack, flag_forced) },
+{ MATROSKA_ID_TRACKVIDEO,EBML_NEST, 0, 0,
offsetof(MatroskaTrack, video),{ .n = matroska_track_video } },
+{ MATROSKA_ID_TRACKAUDIO,EBML_NEST, 0, 0,
offsetof(MatroskaTrack, audio),{ .n = matroska_track_audio } },
+{ MATROSKA_ID_TRACKFLAGENABLED, EBML_NONE },
{ MATROSKA_ID_TRACKFLAGHEARINGIMPAIRED, EBML_UINT, 0, 0,
offsetof(MatroskaTrack, flag_hearingimpaired) },
{ MATROSKA_ID_TRACKFLAGVISUALIMPAIRED, EBML_UINT, 0, 0,
offsetof(MatroskaTrack, flag_visualimpaired) },
{ MATROSKA_ID_TRACKFLAGTEXTDESCRIPTIONS, EBML_UINT, 0, 0,
offsetof(MatroskaTrack, flag_textdescriptions) },
{ MATROSKA_ID_TRACKFLAGORIGINAL, EBML_UINT, 1, 0,
offsetof(MatroskaTrack, flag_original) },
-{ MATROSKA_ID_TRACKVIDEO,EBML_NEST, 0, 0,
[FFmpeg-devel] [PATCH 05/12] avformat/matroskadec: move the elements semantic in a separate file
PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Matroska file semantic element definitions
+ * @author Ronald Bultje
+ * @author with a little help from Moritz Bunkus
+ * @author totally reworked by Aurelien Jacobs
+ * @author Split from decoder by Steve Lhomme
+ * @see specs available on the Matroska project page: http://www.matroska.org/
+ */
+
+#include "config.h"
+
+#include
+
+#include "matroskasem.h"
+
+#define CHILD_OF(parent) { .def = { .n = parent } }
+
+static EbmlSyntax ebml_header[] = {
+{ EBML_ID_EBMLREADVERSION,EBML_UINT, 0, 0, offsetof(Ebml, version),
{ .u = EBML_VERSION } },
+{ EBML_ID_EBMLMAXSIZELENGTH, EBML_UINT, 0, 0, offsetof(Ebml, max_size),
{ .u = 8 } },
+{ EBML_ID_EBMLMAXIDLENGTH,EBML_UINT, 0, 0, offsetof(Ebml, id_length),
{ .u = 4 } },
+{ EBML_ID_DOCTYPE,EBML_STR, 0, 0, offsetof(Ebml, doctype),
{ .s = "(none)" } },
+{ EBML_ID_DOCTYPEREADVERSION, EBML_UINT, 0, 0, offsetof(Ebml,
doctype_version), { .u = 1 } },
+{ EBML_ID_EBMLVERSION,EBML_NONE },
+{ EBML_ID_DOCTYPEVERSION, EBML_NONE },
+CHILD_OF(ebml_syntax)
+};
+
+EbmlSyntax ebml_syntax[] = {
+{ EBML_ID_HEADER, EBML_NEST, 0, 0, 0, { .n = ebml_header } },
+{ MATROSKA_ID_SEGMENT, EBML_STOP },
+{ 0 }
+};
+
+static EbmlSyntax matroska_info[] = {
+{ MATROSKA_ID_TIMECODESCALE, EBML_UINT, 0, 0,
offsetof(MatroskaDemuxContext, time_scale), { .u = 100 } },
+{ MATROSKA_ID_DURATION, EBML_FLOAT, 0, 0,
offsetof(MatroskaDemuxContext, duration) },
+{ MATROSKA_ID_TITLE, EBML_UTF8, 0, 0,
offsetof(MatroskaDemuxContext, title) },
+{ MATROSKA_ID_WRITINGAPP,EBML_NONE },
+{ MATROSKA_ID_MUXINGAPP, EBML_UTF8, 0, 0,
offsetof(MatroskaDemuxContext, muxingapp) },
+{ MATROSKA_ID_DATEUTC, EBML_BIN, 0, 0,
offsetof(MatroskaDemuxContext, date_utc) },
+{ MATROSKA_ID_SEGMENTUID,EBML_NONE },
+CHILD_OF(matroska_segment)
+};
+
+static EbmlSyntax matroska_mastering_meta[] = {
+{ MATROSKA_ID_VIDEOCOLOR_RX, EBML_FLOAT, 0, 0,
offsetof(MatroskaMasteringMeta, r_x) },
+{ MATROSKA_ID_VIDEOCOLOR_RY, EBML_FLOAT, 0, 0,
offsetof(MatroskaMasteringMeta, r_y) },
+{ MATROSKA_ID_VIDEOCOLOR_GX, EBML_FLOAT, 0, 0,
offsetof(MatroskaMasteringMeta, g_x) },
+{ MATROSKA_ID_VIDEOCOLOR_GY, EBML_FLOAT, 0, 0,
offsetof(MatroskaMasteringMeta, g_y) },
+{ MATROSKA_ID_VIDEOCOLOR_BX, EBML_FLOAT, 0, 0,
offsetof(MatroskaMasteringMeta, b_x) },
+{ MATROSKA_ID_VIDEOCOLOR_BY, EBML_FLOAT, 0, 0,
offsetof(MatroskaMasteringMeta, b_y) },
+{ MATROSKA_ID_VIDEOCOLOR_WHITEX, EBML_FLOAT, 0, 0,
offsetof(MatroskaMasteringMeta, white_x) },
+{ MATROSKA_ID_VIDEOCOLOR_WHITEY, EBML_FLOAT, 0, 0,
offsetof(MatroskaMasteringMeta, white_y) },
+{ MATROSKA_ID_VIDEOCOLOR_LUMINANCEMIN, EBML_FLOAT, 1, 0,
offsetof(MatroskaMasteringMeta, min_luminance) },
+{ MATROSKA_ID_VIDEOCOLOR_LUMINANCEMAX, EBML_FLOAT, 0, 0,
offsetof(MatroskaMasteringMeta, max_luminance) },
+CHILD_OF(matroska_track_video_color)
+};
+
+EbmlSyntax matroska_track_video_color[] = {
+{ MATROSKA_ID_VIDEOCOLORMATRIXCOEFF, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoColor, matrix_coefficients), { .u =
AVCOL_SPC_UNSPECIFIED } },
+{ MATROSKA_ID_VIDEOCOLORBITSPERCHANNEL, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoColor, bits_per_channel) },
+{ MATROSKA_ID_VIDEOCOLORCHROMASUBHORZ,EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoColor, chroma_sub_horz) },
+{ MATROSKA_ID_VIDEOCOLORCHROMASUBVERT,EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoColor, chroma_sub_vert) },
+{ MATROSKA_ID_VIDEOCOLORCBSUBHORZ,EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoColor, cb_sub_horz) },
+{ MATROSKA_ID_VIDEOCOLORCBSUBVERT,EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoColor, cb_sub_vert) },
+{ MATROSKA_ID_VIDEOCOLORCHROMASITINGHORZ, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoColor, chroma_siting_horz), { .u =
MATROSKA_COLOUR_CHROMASITINGHORZ_UNDETERMINED } },
+{ MATROSKA_ID_VIDEOCOLORCHROMASITINGVERT, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoColor, chroma_siting_vert), { .u =
MATROSKA_COLOUR_CHROMASITINGVERT_UNDETERMINED } },
+{ MATROSKA_ID_VIDEOCOLORRANGE,EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoColor, range), { .u = AVCOL_RANGE_UNSPECIFIED } },
+{ MATROSKA_ID_VIDEOCOLORTRANSFERCHARACTERISTICS, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoColor, transfer_characteristics), { .u =
AVCOL_TRC_UNSPECIFIED } },
+{ MATROSKA_ID_VIDEOCOLORPRIMARIES,EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoColor, primaries), { .u = AVCOL_PRI_UNSPECIFIED } },
+{ M
[FFmpeg-devel] [PATCH 07/12] avformat/matroska_ids: reorder some IDs to match the generated order
The XSLT scripts produces a similar file to this one, minus some spacing differences. No value added/removed. --- libavformat/matroska_ids.h | 106 ++--- 1 file changed, 53 insertions(+), 53 deletions(-) diff --git a/libavformat/matroska_ids.h b/libavformat/matroska_ids.h index 09579052c4..ab1d84337a 100644 --- a/libavformat/matroska_ids.h +++ b/libavformat/matroska_ids.h @@ -58,9 +58,16 @@ #define MATROSKA_ID_TRACKVIDEO 0xE0 #define MATROSKA_ID_TRACKAUDIO 0xE1 #define MATROSKA_ID_TRACKOPERATION 0xE2 +#define MATROSKA_ID_TRACKFLAGHEARINGIMPAIRED 0x55AB +#define MATROSKA_ID_TRACKFLAGVISUALIMPAIRED 0x55AC +#define MATROSKA_ID_TRACKFLAGTEXTDESCRIPTIONS 0x55AD +#define MATROSKA_ID_TRACKFLAGORIGINAL 0x55AE +#define MATROSKA_ID_TRACKFLAGCOMMENTARY 0x55AF #define MATROSKA_ID_TRACKTIMECODESCALE 0x23314F #define MATROSKA_ID_TRACKMAXBLKADDID 0x55EE #define MATROSKA_ID_TRACKBLKADDMAPPING 0x41E4 +#define MATROSKA_ID_TRACKNAME 0x536E +#define MATROSKA_ID_TRACKLANGUAGE 0x22B59C #define MATROSKA_ID_CODECID0x86 #define MATROSKA_ID_CODECPRIVATE 0x63A2 #define MATROSKA_ID_CODECNAME 0x258688 @@ -69,25 +76,44 @@ #define MATROSKA_ID_CODECDECODEALL 0xAA #define MATROSKA_ID_CODECDELAY 0x56AA #define MATROSKA_ID_SEEKPREROLL 0x56BB -#define MATROSKA_ID_TRACKNAME 0x536E -#define MATROSKA_ID_TRACKLANGUAGE 0x22B59C #define MATROSKA_ID_TRACKFLAGENABLED 0xB9 #define MATROSKA_ID_TRACKFLAGDEFAULT 0x88 #define MATROSKA_ID_TRACKFLAGFORCED 0x55AA -#define MATROSKA_ID_TRACKFLAGHEARINGIMPAIRED 0x55AB -#define MATROSKA_ID_TRACKFLAGVISUALIMPAIRED 0x55AC -#define MATROSKA_ID_TRACKFLAGTEXTDESCRIPTIONS 0x55AD -#define MATROSKA_ID_TRACKFLAGORIGINAL 0x55AE -#define MATROSKA_ID_TRACKFLAGCOMMENTARY 0x55AF #define MATROSKA_ID_TRACKFLAGLACING 0x9C #define MATROSKA_ID_TRACKMINCACHE 0x6DE7 #define MATROSKA_ID_TRACKMAXCACHE 0x6DF8 #define MATROSKA_ID_TRACKDEFAULTDURATION 0x23E383 #define MATROSKA_ID_TRACKCONTENTENCODINGS 0x6D80 +/* IDs in the block addition mapping master */ +#define MATROSKA_ID_BLKADDIDNAME 0x41A4 +#define MATROSKA_ID_BLKADDIDTYPE 0x41E7 +#define MATROSKA_ID_BLKADDIDEXTRADATA 0x41ED +#define MATROSKA_ID_BLKADDIDVALUE 0x41F0 + /* IDs in the contentencodings master */ #define MATROSKA_ID_TRACKCONTENTENCODING 0x6240 +/* IDs in the content encoding master */ +#define MATROSKA_ID_ENCODINGORDER 0x5031 +#define MATROSKA_ID_ENCODINGSCOPE 0x5032 +#define MATROSKA_ID_ENCODINGTYPE 0x5033 +#define MATROSKA_ID_ENCODINGCOMPRESSION 0x5034 +#define MATROSKA_ID_ENCODINGENCRYPTION 0x5035 + +/* IDs in the contentcompression master */ +#define MATROSKA_ID_ENCODINGCOMPALGO 0x4254 +#define MATROSKA_ID_ENCODINGCOMPSETTINGS 0x4255 + +/* IDs in the contentencryption master */ +#define MATROSKA_ID_ENCODINGENCAESSETTINGS 0x47E7 +#define MATROSKA_ID_ENCODINGENCALGO 0x47E1 +#define MATROSKA_ID_ENCODINGENCKEYID 0x47E2 +#define MATROSKA_ID_ENCODINGSIGALGO 0x47E5 +#define MATROSKA_ID_ENCODINGSIGHASHALGO 0x47E6 +#define MATROSKA_ID_ENCODINGSIGKEYID 0x47E4 +#define MATROSKA_ID_ENCODINGSIGNATURE 0x47E3 + /* IDs in the trackoperation master */ #define MATROSKA_ID_TRACKCOMBINEPLANES 0xE3 @@ -162,32 +188,6 @@ #define MATROSKA_ID_AUDIOBITDEPTH 0x6264 #define MATROSKA_ID_AUDIOCHANNELS 0x9F -/* IDs in the content encoding master */ -#define MATROSKA_ID_ENCODINGORDER 0x5031 -#define MATROSKA_ID_ENCODINGSCOPE 0x5032 -#define MATROSKA_ID_ENCODINGTYPE 0x5033 -#define MATROSKA_ID_ENCODINGCOMPRESSION 0x5034 -#define MATROSKA_ID_ENCODINGENCRYPTION 0x5035 - -/* IDs in the contentcompression master */ -#define MATROSKA_ID_ENCODINGCOMPALGO 0x4254 -#define MATROSKA_ID_ENCODINGCOMPSETTINGS 0x4255 - -/* IDs in the contentencryption master */ -#define MATROSKA_ID_ENCODINGENCAESSETTINGS 0x47E7 -#define MATROSKA_ID_ENCODINGENCALGO 0x47E1 -#define MATROSKA_ID_ENCODINGENCKEYID 0x47E2 -#define MATROSKA_ID_ENCODINGSIGALGO 0x47E5 -#define MATROSKA_ID_ENCODINGSIGHASHALGO 0x47E6 -#define MATROSKA_ID_ENCODINGSIGKEYID 0x47E4 -#define MATROSKA_ID_ENCODINGSIGNATURE 0x47E3 - -/* IDs in the block addition mapping master */ -#define MATROSKA_ID_BLKADDIDVALUE 0x41F0 -#define MATROSKA_ID_BLKADDIDNAME 0x41A4 -#define MATROSKA_ID_BLKADDIDTYPE 0x41E7 -#define MATROSKA_ID_BLKADDIDEXTRADATA 0x41ED - /* IDs in the cues master */ #define MATROSKA_ID_POINTENTRY 0xBB @@ -223,19 +223,15 @@ #define MATROSKA_ID_TAGTARGETS_CHAPTERUID 0x63C4 #define MATROSKA_ID_TAGTARGETS_ATTACHUID 0x63C6 -/* IDs in the blockadditions master */ -#define MATROSKA_ID_BLOCKMORE 0xA6 - -/* IDs in the blockmore master */ -#define MATROSKA_ID_BLOCKADDID 0xEE -#define MATROSKA_ID_BLOCKADDITIONAL 0xA5 - -/* IDs in the seekhead master */ -#define MATROSKA_ID_SEEKENTRY 0x4DBB +/* IDs in the attachments master */ +#define MATROSKA_ID_ATTACHEDFILE0x61A7 -/* IDs in the seekpoint master */ -#define MATROSKA_ID_SEEKID 0x53AB -#define MATROSKA_ID_SEEKPOSITION 0x53AC +/* IDs in the attachedfile master */ +#define
[FFmpeg-devel] [PATCH 06/12] avformat/matroska_ids: move some IDs in separate sections
According grouped with their parent's elements. No value added/removed. Some IDs have been moved to match their parent section. Use a consistent wording in all sections. --- libavformat/matroska_ids.h | 83 ++ 1 file changed, 58 insertions(+), 25 deletions(-) diff --git a/libavformat/matroska_ids.h b/libavformat/matroska_ids.h index ddd20d6036..09579052c4 100644 --- a/libavformat/matroska_ids.h +++ b/libavformat/matroska_ids.h @@ -48,7 +48,7 @@ #define MATROSKA_ID_DATEUTC0x4461 #define MATROSKA_ID_SEGMENTUID 0x73A4 -/* ID in the tracks master */ +/* IDs in the tracks master */ #define MATROSKA_ID_TRACKENTRY 0xAE /* IDs in the trackentry master */ @@ -58,10 +58,9 @@ #define MATROSKA_ID_TRACKVIDEO 0xE0 #define MATROSKA_ID_TRACKAUDIO 0xE1 #define MATROSKA_ID_TRACKOPERATION 0xE2 -#define MATROSKA_ID_TRACKCOMBINEPLANES 0xE3 -#define MATROSKA_ID_TRACKPLANE 0xE4 -#define MATROSKA_ID_TRACKPLANEUID 0xE5 -#define MATROSKA_ID_TRACKPLANETYPE 0xE6 +#define MATROSKA_ID_TRACKTIMECODESCALE 0x23314F +#define MATROSKA_ID_TRACKMAXBLKADDID 0x55EE +#define MATROSKA_ID_TRACKBLKADDMAPPING 0x41E4 #define MATROSKA_ID_CODECID0x86 #define MATROSKA_ID_CODECPRIVATE 0x63A2 #define MATROSKA_ID_CODECNAME 0x258688 @@ -85,10 +84,19 @@ #define MATROSKA_ID_TRACKMAXCACHE 0x6DF8 #define MATROSKA_ID_TRACKDEFAULTDURATION 0x23E383 #define MATROSKA_ID_TRACKCONTENTENCODINGS 0x6D80 + +/* IDs in the contentencodings master */ #define MATROSKA_ID_TRACKCONTENTENCODING 0x6240 -#define MATROSKA_ID_TRACKTIMECODESCALE 0x23314F -#define MATROSKA_ID_TRACKMAXBLKADDID 0x55EE -#define MATROSKA_ID_TRACKBLKADDMAPPING 0x41E4 + +/* IDs in the trackoperation master */ +#define MATROSKA_ID_TRACKCOMBINEPLANES 0xE3 + +/* IDs in the trackcombineplanes master */ +#define MATROSKA_ID_TRACKPLANE 0xE4 + +/* IDs in the trackplane master */ +#define MATROSKA_ID_TRACKPLANEUID 0xE5 +#define MATROSKA_ID_TRACKPLANETYPE 0xE6 /* IDs in the trackvideo master */ #define MATROSKA_ID_VIDEOFRAMERATE 0x2383E3 @@ -108,7 +116,9 @@ #define MATROSKA_ID_VIDEOASPECTRATIO 0x54B3 #define MATROSKA_ID_VIDEOCOLORSPACE 0x2EB524 #define MATROSKA_ID_VIDEOCOLOR 0x55B0 +#define MATROSKA_ID_VIDEOPROJECTION 0x7670 +/* IDs in the colour master */ #define MATROSKA_ID_VIDEOCOLORMATRIXCOEFF 0x55B1 #define MATROSKA_ID_VIDEOCOLORBITSPERCHANNEL 0x55B2 #define MATROSKA_ID_VIDEOCOLORCHROMASUBHORZ 0x55B3 @@ -125,6 +135,8 @@ #define MATROSKA_ID_VIDEOCOLORMAXFALL 0x55BD #define MATROSKA_ID_VIDEOCOLORMASTERINGMETA 0x55D0 + +/* IDs in the masteringmetadata master */ #define MATROSKA_ID_VIDEOCOLOR_RX 0x55D1 #define MATROSKA_ID_VIDEOCOLOR_RY 0x55D2 #define MATROSKA_ID_VIDEOCOLOR_GX 0x55D3 @@ -136,7 +148,7 @@ #define MATROSKA_ID_VIDEOCOLOR_LUMINANCEMAX 0x55D9 #define MATROSKA_ID_VIDEOCOLOR_LUMINANCEMIN 0x55DA -#define MATROSKA_ID_VIDEOPROJECTION 0x7670 +/* IDs in the projection master */ #define MATROSKA_ID_VIDEOPROJECTIONTYPE 0x7671 #define MATROSKA_ID_VIDEOPROJECTIONPRIVATE 0x7672 #define MATROSKA_ID_VIDEOPROJECTIONPOSEYAW 0x7673 @@ -155,10 +167,13 @@ #define MATROSKA_ID_ENCODINGSCOPE 0x5032 #define MATROSKA_ID_ENCODINGTYPE 0x5033 #define MATROSKA_ID_ENCODINGCOMPRESSION 0x5034 +#define MATROSKA_ID_ENCODINGENCRYPTION 0x5035 + +/* IDs in the contentcompression master */ #define MATROSKA_ID_ENCODINGCOMPALGO 0x4254 #define MATROSKA_ID_ENCODINGCOMPSETTINGS 0x4255 -#define MATROSKA_ID_ENCODINGENCRYPTION 0x5035 +/* IDs in the contentencryption master */ #define MATROSKA_ID_ENCODINGENCAESSETTINGS 0x47E7 #define MATROSKA_ID_ENCODINGENCALGO 0x47E1 #define MATROSKA_ID_ENCODINGENCKEYID 0x47E2 @@ -173,7 +188,7 @@ #define MATROSKA_ID_BLKADDIDTYPE 0x41E7 #define MATROSKA_ID_BLKADDIDEXTRADATA 0x41ED -/* ID in the cues master */ +/* IDs in the cues master */ #define MATROSKA_ID_POINTENTRY 0xBB /* IDs in the pointentry master */ @@ -189,19 +204,32 @@ /* IDs in the tags master */ #define MATROSKA_ID_TAG 0x7373 + +/* IDs in the tag master */ #define MATROSKA_ID_SIMPLETAG 0x67C8 -#define MATROSKA_ID_TAGNAME 0x45A3 -#define MATROSKA_ID_TAGSTRING 0x4487 +#define MATROSKA_ID_TAGTARGETS 0x63C0 + +/* IDs in the simpletag master */ #define MATROSKA_ID_TAGLANG 0x447A #define MATROSKA_ID_TAGDEFAULT 0x4484 +#define MATROSKA_ID_TAGSTRING 0x4487 #define MATROSKA_ID_TAGDEFAULT_BUG 0x44B4 -#define MATROSKA_ID_TAGTARGETS 0x63C0 +#define MATROSKA_ID_TAGNAME 0x45A3 + +/* IDs in the targets master */ #define MATROSKA_ID_TAGTARGETS_TYPE 0x63CA #define MATROSKA_ID_TAGTARGETS_TYPEVALUE 0x68CA #define MATROSKA_ID_TAGTARGETS_TRACKUID 0x63C5 #define MATROSKA_ID_TAGTARGETS_CHAPTERUID 0x63C4 #define MATROSKA_ID_TAGTARGETS_ATTACHUID 0x63C6 +/* IDs in the blockadditions master */ +#define MATROSKA_ID_BLOCKMORE 0xA6 + +/* IDs in the blockmore master */ +#define
[FFmpeg-devel] [PATCH 10/12] avformat/matroska: use the generated semantic files
No functional value/added removed, only more regular spacing. --- libavformat/matroska_ids.h | 303 +++--- libavformat/matroskasem.c | 370 ++--- 2 files changed, 336 insertions(+), 337 deletions(-) diff --git a/libavformat/matroska_ids.h b/libavformat/matroska_ids.h index ab1d84337a..59dda4da9d 100644 --- a/libavformat/matroska_ids.h +++ b/libavformat/matroska_ids.h @@ -30,177 +30,176 @@ #define MATROSKA_ID_SEGMENT0x18538067 /* Matroska top-level master IDs */ -#define MATROSKA_ID_INFO 0x1549A966 -#define MATROSKA_ID_TRACKS 0x1654AE6B -#define MATROSKA_ID_CUES 0x1C53BB6B -#define MATROSKA_ID_TAGS 0x1254C367 -#define MATROSKA_ID_SEEKHEAD 0x114D9B74 -#define MATROSKA_ID_ATTACHMENTS 0x1941A469 -#define MATROSKA_ID_CLUSTER0x1F43B675 -#define MATROSKA_ID_CHAPTERS 0x1043A770 +#define MATROSKA_ID_INFO0x1549A966 +#define MATROSKA_ID_TRACKS 0x1654AE6B +#define MATROSKA_ID_CUES0x1C53BB6B +#define MATROSKA_ID_TAGS0x1254C367 +#define MATROSKA_ID_SEEKHEAD0x114D9B74 +#define MATROSKA_ID_ATTACHMENTS 0x1941A469 +#define MATROSKA_ID_CLUSTER 0x1F43B675 +#define MATROSKA_ID_CHAPTERS0x1043A770 /* IDs in the info master */ -#define MATROSKA_ID_TIMECODESCALE 0x2AD7B1 -#define MATROSKA_ID_DURATION 0x4489 -#define MATROSKA_ID_TITLE 0x7BA9 -#define MATROSKA_ID_WRITINGAPP 0x5741 -#define MATROSKA_ID_MUXINGAPP 0x4D80 -#define MATROSKA_ID_DATEUTC0x4461 -#define MATROSKA_ID_SEGMENTUID 0x73A4 +#define MATROSKA_ID_TIMECODESCALE 0x2AD7B1 +#define MATROSKA_ID_DURATION0x4489 +#define MATROSKA_ID_TITLE 0x7BA9 +#define MATROSKA_ID_WRITINGAPP 0x5741 +#define MATROSKA_ID_MUXINGAPP 0x4D80 +#define MATROSKA_ID_DATEUTC 0x4461 +#define MATROSKA_ID_SEGMENTUID 0x73A4 /* IDs in the tracks master */ -#define MATROSKA_ID_TRACKENTRY 0xAE +#define MATROSKA_ID_TRACKENTRY 0xAE /* IDs in the trackentry master */ -#define MATROSKA_ID_TRACKNUMBER 0xD7 -#define MATROSKA_ID_TRACKUID 0x73C5 -#define MATROSKA_ID_TRACKTYPE 0x83 -#define MATROSKA_ID_TRACKVIDEO 0xE0 -#define MATROSKA_ID_TRACKAUDIO 0xE1 -#define MATROSKA_ID_TRACKOPERATION 0xE2 +#define MATROSKA_ID_TRACKNUMBER 0xD7 +#define MATROSKA_ID_TRACKUID0x73C5 +#define MATROSKA_ID_TRACKTYPE 0x83 +#define MATROSKA_ID_TRACKVIDEO 0xE0 +#define MATROSKA_ID_TRACKAUDIO 0xE1 +#define MATROSKA_ID_TRACKOPERATION 0xE2 #define MATROSKA_ID_TRACKFLAGHEARINGIMPAIRED 0x55AB -#define MATROSKA_ID_TRACKFLAGVISUALIMPAIRED 0x55AC -#define MATROSKA_ID_TRACKFLAGTEXTDESCRIPTIONS 0x55AD -#define MATROSKA_ID_TRACKFLAGORIGINAL 0x55AE -#define MATROSKA_ID_TRACKFLAGCOMMENTARY 0x55AF -#define MATROSKA_ID_TRACKTIMECODESCALE 0x23314F -#define MATROSKA_ID_TRACKMAXBLKADDID 0x55EE -#define MATROSKA_ID_TRACKBLKADDMAPPING 0x41E4 -#define MATROSKA_ID_TRACKNAME 0x536E -#define MATROSKA_ID_TRACKLANGUAGE 0x22B59C -#define MATROSKA_ID_CODECID0x86 -#define MATROSKA_ID_CODECPRIVATE 0x63A2 -#define MATROSKA_ID_CODECNAME 0x258688 -#define MATROSKA_ID_CODECINFOURL 0x3B4040 -#define MATROSKA_ID_CODECDOWNLOADURL 0x26B240 -#define MATROSKA_ID_CODECDECODEALL 0xAA -#define MATROSKA_ID_CODECDELAY 0x56AA -#define MATROSKA_ID_SEEKPREROLL 0x56BB -#define MATROSKA_ID_TRACKFLAGENABLED 0xB9 -#define MATROSKA_ID_TRACKFLAGDEFAULT 0x88 -#define MATROSKA_ID_TRACKFLAGFORCED 0x55AA -#define MATROSKA_ID_TRACKFLAGLACING 0x9C -#define MATROSKA_ID_TRACKMINCACHE 0x6DE7 -#define MATROSKA_ID_TRACKMAXCACHE 0x6DF8 -#define MATROSKA_ID_TRACKDEFAULTDURATION 0x23E383 -#define MATROSKA_ID_TRACKCONTENTENCODINGS 0x6D80 +#define MATROSKA_ID_TRACKFLAGVISUALIMPAIRED 0x55AC +#define MATROSKA_ID_TRACKFLAGTEXTDESCRIPTIONS 0x55AD +#define MATROSKA_ID_TRACKFLAGORIGINAL 0x55AE +#define MATROSKA_ID_TRACKFLAGCOMMENTARY 0x55AF +#define MATROSKA_ID_TRACKTIMECODESCALE 0x23314F +#define MATROSKA_ID_TRACKMAXBLKADDID0x55EE +#define MATROSKA_ID_TRACKBLKADDMAPPING 0x41E4 +#define MATROSKA_ID_TRACKNAME 0x536E +#define MATROSKA_ID_TRACKLANGUAGE 0x22B59C +#define MATROSKA_ID_CODECID 0x86 +#define MATROSKA_ID_CODECPRIVATE0x63A2 +#define MATROSKA_ID_CODECNAME 0x258688 +#define MATROSKA_ID_CODECINFOURL0x3B4040 +#define MATROSKA_ID_CODECDOWNLOADURL0x26B240 +#define MATROSKA_ID_CODECDECODEALL 0xAA +#define MATROSKA_ID_CODECDELAY 0x56AA +#define MATROSKA_ID_SEEKPREROLL 0x56BB +#define MATROSKA_ID_TRACKFLAGENABLED0xB9 +#define MATROSKA_ID_TRACKFLAGDEFAULT0x88 +#define MATROSKA_ID_TRACKFLAGFORCED 0x55AA +#define MATROSKA_ID_TRACKFLAGLACING 0x9C +#define MATROSKA_ID_TRACKMINCACHE 0x6DE7 +#define MATROSKA_ID_TRACKMAXCACHE 0x6DF8 +#define MATROSKA_ID_TRACKDEFAULTDURATION 0x23E383 +#define
[FFmpeg-devel] [PATCH 08/12] avformat/matroskasem: reorder EbmlSyntax tables
So they are sorted by their EBML path, in reverse order so we don't extra
declarations.
No functional changes.
---
libavformat/matroskasem.c | 263 +++---
1 file changed, 132 insertions(+), 131 deletions(-)
diff --git a/libavformat/matroskasem.c b/libavformat/matroskasem.c
index 978d7f0281..f1afe4d570 100644
--- a/libavformat/matroskasem.c
+++ b/libavformat/matroskasem.c
@@ -54,15 +54,13 @@ EbmlSyntax ebml_syntax[] = {
{ 0 }
};
-static EbmlSyntax matroska_info[] = {
-{ MATROSKA_ID_TIMECODESCALE, EBML_UINT, 0, 0,
offsetof(MatroskaDemuxContext, time_scale), { .u = 100 } },
-{ MATROSKA_ID_DURATION, EBML_FLOAT, 0, 0,
offsetof(MatroskaDemuxContext, duration) },
-{ MATROSKA_ID_TITLE, EBML_UTF8, 0, 0,
offsetof(MatroskaDemuxContext, title) },
-{ MATROSKA_ID_WRITINGAPP,EBML_NONE },
-{ MATROSKA_ID_MUXINGAPP, EBML_UTF8, 0, 0,
offsetof(MatroskaDemuxContext, muxingapp) },
-{ MATROSKA_ID_DATEUTC, EBML_BIN, 0, 0,
offsetof(MatroskaDemuxContext, date_utc) },
-{ MATROSKA_ID_SEGMENTUID,EBML_NONE },
-CHILD_OF(matroska_segment)
+static EbmlSyntax matroska_track_video_projection[] = {
+{ MATROSKA_ID_VIDEOPROJECTIONTYPE,EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoProjection, type), { .u =
MATROSKA_VIDEO_PROJECTION_TYPE_RECTANGULAR } },
+{ MATROSKA_ID_VIDEOPROJECTIONPRIVATE, EBML_BIN, 0, 0,
offsetof(MatroskaTrackVideoProjection, private) },
+{ MATROSKA_ID_VIDEOPROJECTIONPOSEYAW, EBML_FLOAT, 0, 0,
offsetof(MatroskaTrackVideoProjection, yaw), { .f = 0.0 } },
+{ MATROSKA_ID_VIDEOPROJECTIONPOSEPITCH, EBML_FLOAT, 0, 0,
offsetof(MatroskaTrackVideoProjection, pitch), { .f = 0.0 } },
+{ MATROSKA_ID_VIDEOPROJECTIONPOSEROLL,EBML_FLOAT, 0, 0,
offsetof(MatroskaTrackVideoProjection, roll), { .f = 0.0 } },
+CHILD_OF(matroska_track_video)
};
static EbmlSyntax matroska_mastering_meta[] = {
@@ -97,15 +95,6 @@ EbmlSyntax matroska_track_video_color[] = {
CHILD_OF(matroska_track_video)
};
-static EbmlSyntax matroska_track_video_projection[] = {
-{ MATROSKA_ID_VIDEOPROJECTIONTYPE,EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoProjection, type), { .u =
MATROSKA_VIDEO_PROJECTION_TYPE_RECTANGULAR } },
-{ MATROSKA_ID_VIDEOPROJECTIONPRIVATE, EBML_BIN, 0, 0,
offsetof(MatroskaTrackVideoProjection, private) },
-{ MATROSKA_ID_VIDEOPROJECTIONPOSEYAW, EBML_FLOAT, 0, 0,
offsetof(MatroskaTrackVideoProjection, yaw), { .f = 0.0 } },
-{ MATROSKA_ID_VIDEOPROJECTIONPOSEPITCH, EBML_FLOAT, 0, 0,
offsetof(MatroskaTrackVideoProjection, pitch), { .f = 0.0 } },
-{ MATROSKA_ID_VIDEOPROJECTIONPOSEROLL,EBML_FLOAT, 0, 0,
offsetof(MatroskaTrackVideoProjection, roll), { .f = 0.0 } },
-CHILD_OF(matroska_track_video)
-};
-
EbmlSyntax matroska_track_video[] = {
{ MATROSKA_ID_VIDEOFRAMERATE, EBML_FLOAT, 0, 0,
offsetof(MatroskaTrackVideo, frame_rate) },
{ MATROSKA_ID_VIDEODISPLAYWIDTH, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideo, display_width), { .u=-1 } },
@@ -128,18 +117,20 @@ EbmlSyntax matroska_track_video[] = {
CHILD_OF(matroska_track)
};
-static EbmlSyntax matroska_track_audio[] = {
-{ MATROSKA_ID_AUDIOSAMPLINGFREQ,EBML_FLOAT, 0, 0,
offsetof(MatroskaTrackAudio, samplerate), { .f = 8000.0 } },
-{ MATROSKA_ID_AUDIOOUTSAMPLINGFREQ, EBML_FLOAT, 0, 0,
offsetof(MatroskaTrackAudio, out_samplerate) },
-{ MATROSKA_ID_AUDIOBITDEPTH,EBML_UINT, 0, 0,
offsetof(MatroskaTrackAudio, bitdepth) },
-{ MATROSKA_ID_AUDIOCHANNELS,EBML_UINT, 0, 0,
offsetof(MatroskaTrackAudio, channels), { .u = 1 } },
-CHILD_OF(matroska_track)
+static EbmlSyntax matroska_track_plane[] = {
+{ MATROSKA_ID_TRACKPLANEUID, EBML_UINT, 0, 0,
offsetof(MatroskaTrackPlane,uid) },
+{ MATROSKA_ID_TRACKPLANETYPE, EBML_UINT, 0, 0,
offsetof(MatroskaTrackPlane,type) },
+CHILD_OF(matroska_track_combine_planes)
};
-static EbmlSyntax matroska_track_encoding_compression[] = {
-{ MATROSKA_ID_ENCODINGCOMPALGO, EBML_UINT, 0, 0,
offsetof(MatroskaTrackCompression, algo), { .u =
MATROSKA_TRACK_ENCODING_COMP_ZLIB } },
-{ MATROSKA_ID_ENCODINGCOMPSETTINGS, EBML_BIN, 0, 0,
offsetof(MatroskaTrackCompression, settings) },
-CHILD_OF(matroska_track_encoding)
+EbmlSyntax matroska_track_combine_planes[] = {
+{ MATROSKA_ID_TRACKPLANE, EBML_NEST, 0, sizeof(MatroskaTrackPlane),
offsetof(MatroskaTrackOperation,combine_planes), {.n = matroska_track_plane} },
+CHILD_OF(matroska_track_operation)
+};
+
+EbmlSyntax matroska_track_operation[] = {
+{ MATROSKA_ID_TRACKCOMBINEPLANES, EBML_NEST, 0, 0, 0, {.n =
matroska_track_combine_planes} },
+CHILD_OF(matroska_track)
};
static EbmlSyntax matroska_track_encoding_encryption[] = {
@@ -152,6 +143,13 @@ static EbmlSyntax matroska_track_encoding_encryption[] = {
{ MATROSKA_ID_ENCODINGSIGNATURE, EBML_NONE },
[FFmpeg-devel] [PATCH 04/12] avformat/matroska: move Matroska IDs and enums in a separate header
So the file can be generated from the EBML Schema. No functional change. --- libavformat/matroska.h | 314 +- libavformat/matroska_ids.h | 339 + 2 files changed, 340 insertions(+), 313 deletions(-) create mode 100644 libavformat/matroska_ids.h diff --git a/libavformat/matroska.h b/libavformat/matroska.h index 1e8a91295f..174af130de 100644 --- a/libavformat/matroska.h +++ b/libavformat/matroska.h @@ -24,6 +24,7 @@ #include "libavcodec/codec_id.h" #include "avformat.h" +#include "matroska_ids.h" #include "metadata.h" /* EBML version supported */ @@ -45,319 +46,6 @@ #define EBML_ID_VOID 0xEC #define EBML_ID_CRC32 0xBF -/* - * Matroska element IDs, max. 32 bits - */ - -/* toplevel segment */ -#define MATROSKA_ID_SEGMENT0x18538067 - -/* Matroska top-level master IDs */ -#define MATROSKA_ID_INFO 0x1549A966 -#define MATROSKA_ID_TRACKS 0x1654AE6B -#define MATROSKA_ID_CUES 0x1C53BB6B -#define MATROSKA_ID_TAGS 0x1254C367 -#define MATROSKA_ID_SEEKHEAD 0x114D9B74 -#define MATROSKA_ID_ATTACHMENTS 0x1941A469 -#define MATROSKA_ID_CLUSTER0x1F43B675 -#define MATROSKA_ID_CHAPTERS 0x1043A770 - -/* IDs in the info master */ -#define MATROSKA_ID_TIMECODESCALE 0x2AD7B1 -#define MATROSKA_ID_DURATION 0x4489 -#define MATROSKA_ID_TITLE 0x7BA9 -#define MATROSKA_ID_WRITINGAPP 0x5741 -#define MATROSKA_ID_MUXINGAPP 0x4D80 -#define MATROSKA_ID_DATEUTC0x4461 -#define MATROSKA_ID_SEGMENTUID 0x73A4 - -/* ID in the tracks master */ -#define MATROSKA_ID_TRACKENTRY 0xAE - -/* IDs in the trackentry master */ -#define MATROSKA_ID_TRACKNUMBER 0xD7 -#define MATROSKA_ID_TRACKUID 0x73C5 -#define MATROSKA_ID_TRACKTYPE 0x83 -#define MATROSKA_ID_TRACKVIDEO 0xE0 -#define MATROSKA_ID_TRACKAUDIO 0xE1 -#define MATROSKA_ID_TRACKOPERATION 0xE2 -#define MATROSKA_ID_TRACKCOMBINEPLANES 0xE3 -#define MATROSKA_ID_TRACKPLANE 0xE4 -#define MATROSKA_ID_TRACKPLANEUID 0xE5 -#define MATROSKA_ID_TRACKPLANETYPE 0xE6 -#define MATROSKA_ID_CODECID0x86 -#define MATROSKA_ID_CODECPRIVATE 0x63A2 -#define MATROSKA_ID_CODECNAME 0x258688 -#define MATROSKA_ID_CODECINFOURL 0x3B4040 -#define MATROSKA_ID_CODECDOWNLOADURL 0x26B240 -#define MATROSKA_ID_CODECDECODEALL 0xAA -#define MATROSKA_ID_CODECDELAY 0x56AA -#define MATROSKA_ID_SEEKPREROLL 0x56BB -#define MATROSKA_ID_TRACKNAME 0x536E -#define MATROSKA_ID_TRACKLANGUAGE 0x22B59C -#define MATROSKA_ID_TRACKFLAGENABLED 0xB9 -#define MATROSKA_ID_TRACKFLAGDEFAULT 0x88 -#define MATROSKA_ID_TRACKFLAGFORCED 0x55AA -#define MATROSKA_ID_TRACKFLAGHEARINGIMPAIRED 0x55AB -#define MATROSKA_ID_TRACKFLAGVISUALIMPAIRED 0x55AC -#define MATROSKA_ID_TRACKFLAGTEXTDESCRIPTIONS 0x55AD -#define MATROSKA_ID_TRACKFLAGORIGINAL 0x55AE -#define MATROSKA_ID_TRACKFLAGCOMMENTARY 0x55AF -#define MATROSKA_ID_TRACKFLAGLACING 0x9C -#define MATROSKA_ID_TRACKMINCACHE 0x6DE7 -#define MATROSKA_ID_TRACKMAXCACHE 0x6DF8 -#define MATROSKA_ID_TRACKDEFAULTDURATION 0x23E383 -#define MATROSKA_ID_TRACKCONTENTENCODINGS 0x6D80 -#define MATROSKA_ID_TRACKCONTENTENCODING 0x6240 -#define MATROSKA_ID_TRACKTIMECODESCALE 0x23314F -#define MATROSKA_ID_TRACKMAXBLKADDID 0x55EE -#define MATROSKA_ID_TRACKBLKADDMAPPING 0x41E4 - -/* IDs in the trackvideo master */ -#define MATROSKA_ID_VIDEOFRAMERATE 0x2383E3 -#define MATROSKA_ID_VIDEODISPLAYWIDTH 0x54B0 -#define MATROSKA_ID_VIDEODISPLAYHEIGHT 0x54BA -#define MATROSKA_ID_VIDEOPIXELWIDTH 0xB0 -#define MATROSKA_ID_VIDEOPIXELHEIGHT 0xBA -#define MATROSKA_ID_VIDEOPIXELCROPB 0x54AA -#define MATROSKA_ID_VIDEOPIXELCROPT 0x54BB -#define MATROSKA_ID_VIDEOPIXELCROPL 0x54CC -#define MATROSKA_ID_VIDEOPIXELCROPR 0x54DD -#define MATROSKA_ID_VIDEODISPLAYUNIT 0x54B2 -#define MATROSKA_ID_VIDEOFLAGINTERLACED 0x9A -#define MATROSKA_ID_VIDEOFIELDORDER 0x9D -#define MATROSKA_ID_VIDEOSTEREOMODE 0x53B8 -#define MATROSKA_ID_VIDEOALPHAMODE 0x53C0 -#define MATROSKA_ID_VIDEOASPECTRATIO 0x54B3 -#define MATROSKA_ID_VIDEOCOLORSPACE 0x2EB524 -#define MATROSKA_ID_VIDEOCOLOR 0x55B0 - -#define MATROSKA_ID_VIDEOCOLORMATRIXCOEFF 0x55B1 -#define MATROSKA_ID_VIDEOCOLORBITSPERCHANNEL 0x55B2 -#define MATROSKA_ID_VIDEOCOLORCHROMASUBHORZ 0x55B3 -#define MATROSKA_ID_VIDEOCOLORCHROMASUBVERT 0x55B4 -#define MATROSKA_ID_VIDEOCOLORCBSUBHORZ 0x55B5 -#define MATROSKA_ID_VIDEOCOLORCBSUBVERT 0x55B6 -#define MATROSKA_ID_VIDEOCOLORCHROMASITINGHORZ 0x55B7 -#define MATROSKA_ID_VIDEOCOLORCHROMASITINGVERT 0x55B8 -#define MATROSKA_ID_VIDEOCOLORRANGE 0x55B9 -#define MATROSKA_ID_VIDEOCOLORTRANSFERCHARACTERISTICS 0x55BA - -#define MATROSKA_ID_VIDEOCOLORPRIMARIES 0x55BB -#define MATROSKA_ID_VIDEOCOLORMAXCLL 0x55BC -#define MATROSKA_ID_VIDEOCOLORMAXFALL 0x55BD - -#define MATROSKA_ID_VIDEOCOLORMASTERINGMETA 0x55D0 -#define MATROSKA_ID_VIDEOCOLOR_RX 0x55D1 -#define MATROSKA_ID_VIDEOCOLOR_RY 0x55D2 -#define MATROSKA_ID_VIDEOCOLOR_GX 0x55D3 -#define MATROSKA_ID_VIDEOCOLOR_GY 0x55D4 -#define
[FFmpeg-devel] [PATCH 03/12] avformat/matroska: use more consistent spacing in enums
---
libavformat/matroska.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavformat/matroska.h b/libavformat/matroska.h
index 45077ed33f..1e8a91295f 100644
--- a/libavformat/matroska.h
+++ b/libavformat/matroska.h
@@ -296,18 +296,18 @@ typedef enum {
} MatroskaTrackEncodingCompAlgo;
typedef enum {
-MATROSKA_VIDEO_INTERLACE_FLAG_UNDETERMINED = 0,
-MATROSKA_VIDEO_INTERLACE_FLAG_INTERLACED = 1,
-MATROSKA_VIDEO_INTERLACE_FLAG_PROGRESSIVE = 2,
+ MATROSKA_VIDEO_INTERLACE_FLAG_UNDETERMINED = 0,
+ MATROSKA_VIDEO_INTERLACE_FLAG_INTERLACED = 1,
+ MATROSKA_VIDEO_INTERLACE_FLAG_PROGRESSIVE = 2,
} MatroskaVideoInterlaceFlag;
typedef enum {
-MATROSKA_VIDEO_FIELDORDER_PROGRESSIVE = 0,
-MATROSKA_VIDEO_FIELDORDER_TT = 1,
-MATROSKA_VIDEO_FIELDORDER_UNDETERMINED = 2,
-MATROSKA_VIDEO_FIELDORDER_BB = 6,
-MATROSKA_VIDEO_FIELDORDER_TB = 9,
-MATROSKA_VIDEO_FIELDORDER_BT = 14,
+ MATROSKA_VIDEO_FIELDORDER_PROGRESSIVE = 0,
+ MATROSKA_VIDEO_FIELDORDER_TT = 1,
+ MATROSKA_VIDEO_FIELDORDER_UNDETERMINED = 2,
+ MATROSKA_VIDEO_FIELDORDER_BB = 6,
+ MATROSKA_VIDEO_FIELDORDER_TB = 9,
+ MATROSKA_VIDEO_FIELDORDER_BT = 14,
} MatroskaVideoFieldOrder;
typedef enum {
--
2.20.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".
[FFmpeg-devel] [PATCH 01/12] avformat/matroskadec: fix the default of the TagDefault element
By default a tag is the default one.
---
libavformat/matroskadec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index d582f566a2..9e756bb030 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -703,8 +703,8 @@ static EbmlSyntax matroska_simpletag[] = {
{ MATROSKA_ID_TAGNAME,EBML_UTF8, 0, 0,
offsetof(MatroskaTag, name) },
{ MATROSKA_ID_TAGSTRING, EBML_UTF8, 0, 0,
offsetof(MatroskaTag, string) },
{ MATROSKA_ID_TAGLANG,EBML_STR, 0, 0,
offsetof(MatroskaTag, lang), { .s = "und" } },
-{ MATROSKA_ID_TAGDEFAULT, EBML_UINT, 0, 0,
offsetof(MatroskaTag, def) },
-{ MATROSKA_ID_TAGDEFAULT_BUG, EBML_UINT, 0, 0,
offsetof(MatroskaTag, def) },
+{ MATROSKA_ID_TAGDEFAULT, EBML_UINT, 0, 0,
offsetof(MatroskaTag, def), { .u = 1 } },
+{ MATROSKA_ID_TAGDEFAULT_BUG, EBML_UINT, 0, 0,
offsetof(MatroskaTag, def), { .u = 1 } },
{ MATROSKA_ID_SIMPLETAG, EBML_NEST, 0, sizeof(MatroskaTag),
offsetof(MatroskaTag, sub), { .n = matroska_simpletag } },
CHILD_OF(matroska_tag)
};
--
2.20.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".
[FFmpeg-devel] [PATCH 02/12] avformat/matroskadec: remove some implicit default value
All integers should be initialized to 0. Make the tables more consistent by
only setting non zero values, so they stand out.
---
libavformat/matroskadec.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 9e756bb030..5a083acd75 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -482,7 +482,7 @@ static EbmlSyntax matroska_mastering_meta[] = {
static EbmlSyntax matroska_track_video_color[] = {
{ MATROSKA_ID_VIDEOCOLORMATRIXCOEFF, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoColor, matrix_coefficients), { .u =
AVCOL_SPC_UNSPECIFIED } },
-{ MATROSKA_ID_VIDEOCOLORBITSPERCHANNEL, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoColor, bits_per_channel), { .u = 0 } },
+{ MATROSKA_ID_VIDEOCOLORBITSPERCHANNEL, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoColor, bits_per_channel) },
{ MATROSKA_ID_VIDEOCOLORCHROMASUBHORZ,EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoColor, chroma_sub_horz) },
{ MATROSKA_ID_VIDEOCOLORCHROMASUBVERT,EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoColor, chroma_sub_vert) },
{ MATROSKA_ID_VIDEOCOLORCBSUBHORZ,EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideoColor, cb_sub_horz) },
@@ -514,7 +514,7 @@ static EbmlSyntax matroska_track_video[] = {
{ MATROSKA_ID_VIDEOPIXELWIDTH, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideo, pixel_width) },
{ MATROSKA_ID_VIDEOPIXELHEIGHT,EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideo, pixel_height) },
{ MATROSKA_ID_VIDEOCOLORSPACE, EBML_BIN, 0, 0,
offsetof(MatroskaTrackVideo, color_space) },
-{ MATROSKA_ID_VIDEOALPHAMODE, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideo, alpha_mode), { .u = 0 } },
+{ MATROSKA_ID_VIDEOALPHAMODE, EBML_UINT, 0, 0,
offsetof(MatroskaTrackVideo, alpha_mode) },
{ MATROSKA_ID_VIDEOCOLOR, EBML_NEST, 0,
sizeof(MatroskaTrackVideoColor), offsetof(MatroskaTrackVideo, color), { .n =
matroska_track_video_color } },
{ MATROSKA_ID_VIDEOPROJECTION, EBML_NEST, 0, 0,
offsetof(MatroskaTrackVideo, projection), { .n =
matroska_track_video_projection } },
{ MATROSKA_ID_VIDEOPIXELCROPB, EBML_NONE },
@@ -544,7 +544,7 @@ static EbmlSyntax matroska_track_encoding_compression[] = {
};
static EbmlSyntax matroska_track_encoding_encryption[] = {
-{ MATROSKA_ID_ENCODINGENCALGO,EBML_UINT, 0, 0,
offsetof(MatroskaTrackEncryption,algo), {.u = 0} },
+{ MATROSKA_ID_ENCODINGENCALGO,EBML_UINT, 0, 0,
offsetof(MatroskaTrackEncryption,algo) },
{ MATROSKA_ID_ENCODINGENCKEYID, EBML_BIN, 0, 0,
offsetof(MatroskaTrackEncryption,key_id) },
{ MATROSKA_ID_ENCODINGENCAESSETTINGS, EBML_NONE },
{ MATROSKA_ID_ENCODINGSIGALGO,EBML_NONE },
@@ -555,7 +555,7 @@ static EbmlSyntax matroska_track_encoding_encryption[] = {
};
static EbmlSyntax matroska_track_encoding[] = {
{ MATROSKA_ID_ENCODINGSCOPE, EBML_UINT, 0, 0,
offsetof(MatroskaTrackEncoding, scope), { .u = 1 } },
-{ MATROSKA_ID_ENCODINGTYPE,EBML_UINT, 0, 0,
offsetof(MatroskaTrackEncoding, type),{ .u = 0 } },
+{ MATROSKA_ID_ENCODINGTYPE,EBML_UINT, 0, 0,
offsetof(MatroskaTrackEncoding, type) },
{ MATROSKA_ID_ENCODINGCOMPRESSION, EBML_NEST, 0, 0,
offsetof(MatroskaTrackEncoding, compression), { .n =
matroska_track_encoding_compression } },
{ MATROSKA_ID_ENCODINGENCRYPTION, EBML_NEST, 0, 0,
offsetof(MatroskaTrackEncoding, encryption), { .n =
matroska_track_encoding_encryption } },
{ MATROSKA_ID_ENCODINGORDER, EBML_NONE },
@@ -598,24 +598,24 @@ static EbmlSyntax matroska_track[] = {
{ MATROSKA_ID_TRACKTYPE, EBML_UINT, 0, 0,
offsetof(MatroskaTrack, type) },
{ MATROSKA_ID_CODECID, EBML_STR, 0, 0,
offsetof(MatroskaTrack, codec_id) },
{ MATROSKA_ID_CODECPRIVATE, EBML_BIN, 0, 0,
offsetof(MatroskaTrack, codec_priv) },
-{ MATROSKA_ID_CODECDELAY,EBML_UINT, 0, 0,
offsetof(MatroskaTrack, codec_delay), { .u = 0 } },
+{ MATROSKA_ID_CODECDELAY,EBML_UINT, 0, 0,
offsetof(MatroskaTrack, codec_delay) },
{ MATROSKA_ID_TRACKLANGUAGE, EBML_STR, 0, 0,
offsetof(MatroskaTrack, language), { .s = "eng" } },
{ MATROSKA_ID_TRACKDEFAULTDURATION, EBML_UINT, 0, 0,
offsetof(MatroskaTrack, default_duration) },
{ MATROSKA_ID_TRACKTIMECODESCALE,EBML_FLOAT, 0, 0,
offsetof(MatroskaTrack, time_scale), { .f = 1.0 } },
-{ MATROSKA_ID_TRACKFLAGCOMMENTARY, EBML_UINT, 0, 0,
offsetof(MatroskaTrack, flag_comment), { .u = 0 } },
+{ MATROSKA_ID_TRACKFLAGCOMMENTARY, EBML_UINT, 0, 0,
offsetof(MatroskaTrack, flag_comment) },
{ MATROSKA_ID_TRACKFLAGDEFAULT, EBML_UINT, 0, 0,
offsetof(MatroskaTrack, flag_default), { .u = 1 } },
-{ MATROSKA_ID_TRACKFLAGFORCED, EBML_UINT, 0, 0,
offsetof(MatroskaTrack, flag_forced),
[FFmpeg-devel] [PATCH 00/12] Use generated semantic for Matroska demuxer
From: robux4 Following an earlier version of the generated code, I reworked to code and move the generator outside of the FFmpeg source tree. The XSLT code to generate this code from the EBML Schema for Matroska can be found at https://github.com/Matroska-Org/foundation-source/pull/116 Steve Lhomme (12): avformat/matroskadec: fix the default of the TagDefault element avformat/matroskadec: remove some implicit default value avformat/matroska: use more consistent spacing in enums avformat/matroska: move Matroska IDs and enums in a separate header avformat/matroskadec: move the elements semantic in a separate file avformat/matroska_ids: move some IDs in separate sections avformat/matroska_ids: reorder some IDs to match the generated order avformat/matroskasem: reorder EbmlSyntax tables avformat/matroskasem: reorder some EbmlSyntax elements avformat/matroska: use the generated semantic files avformat/matroska: only export a few elements. avformat/matroska: add missing elements libavformat/Makefile | 2 +- libavformat/matroska.h | 314 +--- libavformat/matroska_ids.h | 464 libavformat/matroskadec.c | 712 + libavformat/matroskasem.c | 471 libavformat/matroskasem.h | 389 6 files changed, 1327 insertions(+), 1025 deletions(-) create mode 100644 libavformat/matroska_ids.h create mode 100644 libavformat/matroskasem.c create mode 100644 libavformat/matroskasem.h -- 2.20.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/pthread_frame: avoid leaving stale hwaccel state in worker threads
Hi Anton,
On 2022-09-02 22:59, Anton Khirnov wrote:
This state is not refcounted, so make sure it always has a well-defined
owner.
---
Steve, could you please test this?
I can confirm it doesn't leak the context and plays correctly. It also
doesn't crash ;)
---
libavcodec/pthread_frame.c | 37 -
1 file changed, 32 insertions(+), 5 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 08a6f98898..9b44e2e698 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -148,6 +148,10 @@ typedef struct FrameThreadContext {
* Set for the first N packets, where N is
the number of threads.
* While it is set,
ff_thread_en/decode_frame won't return any results.
*/
+
+const AVHWAccel *stash_hwaccel;
+void*stash_hwaccel_context;
+void*stash_hwaccel_priv;
} FrameThreadContext;
#if FF_API_THREAD_SAFE_CALLBACKS
@@ -228,9 +232,17 @@ FF_ENABLE_DEPRECATION_WARNINGS
ff_thread_finish_setup(avctx);
if (p->hwaccel_serializing) {
+/* wipe hwaccel state to avoid stale pointers lying around;
+ * the state was transferred to FrameThreadContext in
+ * ff_thread_finish_setup(), so nothing is leaked */
+avctx->hwaccel = NULL;
+avctx->hwaccel_context = NULL;
+avctx->internal->hwaccel_priv_data = NULL;
+
p->hwaccel_serializing = 0;
pthread_mutex_unlock(>parent->hwaccel_mutex);
}
+av_assert0(!avctx->hwaccel);
if (p->async_serializing) {
p->async_serializing = 0;
@@ -294,9 +306,6 @@ static int update_context_from_thread(AVCodecContext *dst,
AVCodecContext *src,
dst->color_range = src->color_range;
dst->chroma_sample_location = src->chroma_sample_location;
-dst->hwaccel = src->hwaccel;
-dst->hwaccel_context = src->hwaccel_context;
-
dst->sample_rate= src->sample_rate;
dst->sample_fmt = src->sample_fmt;
#if FF_API_OLD_CHANNEL_LAYOUT
@@ -309,8 +318,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (err < 0)
return err;
-dst->internal->hwaccel_priv_data = src->internal->hwaccel_priv_data;
-
if (!!dst->hw_frames_ctx != !!src->hw_frames_ctx ||
(dst->hw_frames_ctx && dst->hw_frames_ctx->data !=
src->hw_frames_ctx->data)) {
av_buffer_unref(>hw_frames_ctx);
@@ -450,6 +457,12 @@ static int submit_packet(PerThreadContext *p,
AVCodecContext *user_avctx,
pthread_mutex_unlock(>mutex);
return err;
}
+
+/* transfer hwaccel state stashed from previous thread, if any */
+av_assert0(!p->avctx->hwaccel);
+FFSWAP(const AVHWAccel*, p->avctx->hwaccel,
fctx->stash_hwaccel);
+FFSWAP(void*,p->avctx->hwaccel_context,
fctx->stash_hwaccel_context);
+FFSWAP(void*,p->avctx->internal->hwaccel_priv_data,
fctx->stash_hwaccel_priv);
}
av_packet_unref(p->avpkt);
@@ -655,6 +668,13 @@ void ff_thread_finish_setup(AVCodecContext *avctx) {
async_lock(p->parent);
}
+/* save hwaccel state for passing to the next thread;
+ * this is done here so that this worker thread can wipe its own hwaccel
+ * state after decoding, without requiring synchronization */
+p->parent->stash_hwaccel = avctx->hwaccel;
+p->parent->stash_hwaccel_context = avctx->hwaccel_context;
+p->parent->stash_hwaccel_priv= avctx->internal->hwaccel_priv_data;
+
pthread_mutex_lock(>progress_mutex);
if(atomic_load(>state) == STATE_SETUP_FINISHED){
av_log(avctx, AV_LOG_WARNING, "Multiple ff_thread_finish_setup()
calls\n");
@@ -761,6 +781,13 @@ void ff_frame_thread_free(AVCodecContext *avctx, int
thread_count)
av_freep(>threads);
ff_pthread_free(fctx, thread_ctx_offsets);
+/* if we have stashed hwaccel state, move it to the user-facing context,
+ * so it will be freed in avcodec_close() */
+av_assert0(!avctx->hwaccel);
+FFSWAP(const AVHWAccel*, avctx->hwaccel,
fctx->stash_hwaccel);
+FFSWAP(void*,avctx->hwaccel_context,
fctx->stash_hwaccel_context);
+FFSWAP(void*,avctx->internal->hwaccel_priv_data,
fctx->stash_hwaccel_priv);
+
av_freep(>internal->thread_ctx);
}
--
2.35.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] avcodec/pthread_frame: update the main avctx from the current, ThreadContext
Hi, On 2022-08-02 16:19, Anton Khirnov wrote: Why are you not resubmitting your original patch that stops copying hwaccel_priv_data to the user-facing context? It seemed more correct to me, since the user-facing context should never see any hwaccel data. Or does it not fix the issue fully? The original patch is not fixing it properly. With that patch and avcodec-threads > 1, the uninit of the hardware decoder is not called anymore. So it will replace a crash fix with a (big) resource leak. For reference, this it the patch we're talking about https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg94274.html For a more proper fix, we probably want to bundle hwaccel+state+uninit to a single refcounted thing. -- 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".
[FFmpeg-devel] [PATCH] avcodec/pthread_frame: update the main avctx from the current, ThreadContext
Patch attached in the email. In some cases, the submit packet can result in configurations changes of the hardware decoders. The previous HW context is then freed and a new one created. That context is supposed to move up to the main context and the other threads. It appears that when more than 2 frame threads are involved, the new context doesn't move in the right place (or rather at the right time). And it can create a crash when reusing the old HW context. This patch fixes the issue I could reproduce in VLC with DXVA decoding. I have no idea if this is correct or the side effects induced by this. It seems the right thing to do. Keeping the previous call exhibits the issue. It seems odd the other existing thread context are not updated with the current hwaccel_priv_data. But maybe they are updated later from the "main" thread context, in which case this patch seems solid.From e8abeeff92f5d7b3b553acdb7595d40153cbec1e Mon Sep 17 00:00:00 2001 From: Steve Lhomme Date: Fri, 8 Jul 2022 11:49:27 +0200 Subject: [PATCH] avcodec/pthread_frame: update the main avctx from the current ThreadContext After a submit_decoder() the hwaccel_priv_data may have changed in that avctx. Doing it after the "next available frame" loop will likely point to the hwaccel_priv_data from another PerThreadContext which had the old value which might have been freed, if the submit_decoder() resulting in a format change. --- libavcodec/pthread_frame.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c index 8faea75a49..eff09c3510 100644 --- a/libavcodec/pthread_frame.c +++ b/libavcodec/pthread_frame.c @@ -529,6 +529,8 @@ int ff_thread_decode_frame(AVCodecContext *avctx, if (err) goto finish; +update_context_from_thread(avctx, p->avctx, 1); + /* * If we're still receiving the initial packets, don't return a frame. */ @@ -578,8 +580,6 @@ int ff_thread_decode_frame(AVCodecContext *avctx, if (finished >= avctx->thread_count) finished = 0; } while (!avpkt->size && !*got_picture_ptr && err >= 0 && finished != fctx->next_finished); -update_context_from_thread(avctx, p->avctx, 1); - if (fctx->next_decoding >= avctx->thread_count) fctx->next_decoding = 0; fctx->next_finished = finished; -- 2.27.0.windows.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] Request For Comment no Matroska specs
On 2022-04-01 14:33, Steve Lhomme wrote: Hi ffmmpeg developers, As you may know, we are working hard on the Matroska specifications at the IETF. We already got EBML as an RFC [1]. We are in the process of finalizing the main Matroska document. Before we submit the document for formal review before "final" publishing, we would like people who know a bit about Matroska to review the current draft in case there are parts missing, hard to decipher or, even worse, bugs. This is a 200 pages document, so it may take a while. You can find draft 09 at [2]. It should explain what is found in Matroska 1 to 4. Some unused elements have been deprecated since the original informal specifications. These elements can be found in Annex A. I forgot to mention you can reply here or on the GitHub repository of the specs [3] by creating an issue or even a Pull Request. [3] https://github.com/ietf-wg-cellar/matroska-specification Thanks [1] https://datatracker.ietf.org/doc/rfc8794/ [2] https://datatracker.ietf.org/doc/draft-ietf-cellar-matroska/ ___ 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] Request For Comment no Matroska specs
Hi ffmmpeg developers, As you may know, we are working hard on the Matroska specifications at the IETF. We already got EBML as an RFC [1]. We are in the process of finalizing the main Matroska document. Before we submit the document for formal review before "final" publishing, we would like people who know a bit about Matroska to review the current draft in case there are parts missing, hard to decipher or, even worse, bugs. This is a 200 pages document, so it may take a while. You can find draft 09 at [2]. It should explain what is found in Matroska 1 to 4. Some unused elements have been deprecated since the original informal specifications. These elements can be found in Annex A. Thanks [1] https://datatracker.ietf.org/doc/rfc8794/ [2] https://datatracker.ietf.org/doc/draft-ietf-cellar-matroska/ ___ 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] dxva2_hevc: don't use frames as reference if they are not marked as such
This makes my previous path "avcodec/dxva2: don't call GetDesc on a NULL ID3D11VideoDecoderOutputView" unnecessary. While it avoids a crash in release builds, it should still assert because a bogus reference is used. With this patch no bogus reference is used for that sample file, and playback seems correct. On 2022-03-23 14:54, Steve Lhomme wrote: Similar to how a frame is considered for referencing for the RefPicList array. This will do the same for RefPicSetStCurrBefore, RefPicSetStCurrAfter and RefPicSetLtCurr. Fixes playback of http://www.gbbsoft.pl/!download/!/Film1.mp4 Ref. VLC issue https://code.videolan.org/videolan/vlc/-/issues/26738 Signed-off-by: Steve Lhomme --- libavcodec/dxva2_hevc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/dxva2_hevc.c b/libavcodec/dxva2_hevc.c index c91bcf3eeb..6b239d9917 100644 --- a/libavcodec/dxva2_hevc.c +++ b/libavcodec/dxva2_hevc.c @@ -184,7 +184,7 @@ static void fill_picture_parameters(const AVCodecContext *avctx, AVDXVAContext * const HEVCFrame *frame = NULL; \ while (!frame && j < rpl->nb_refs) \ frame = rpl->ref[j++]; \ -if (frame) \ +if (frame && frame->flags & (HEVC_FRAME_FLAG_LONG_REF | HEVC_FRAME_FLAG_SHORT_REF)) \ pp->ref_list[i] = get_refpic_index(pp, ff_dxva2_get_surface_index(avctx, ctx, frame->frame)); \ else \ pp->ref_list[i] = 0xff; \ -- 2.29.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". ___ 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] dxva2_hevc: don't use frames as reference if they are not marked as such
Similar to how a frame is considered for referencing for the RefPicList array. This will do the same for RefPicSetStCurrBefore, RefPicSetStCurrAfter and RefPicSetLtCurr. Fixes playback of http://www.gbbsoft.pl/!download/!/Film1.mp4 Ref. VLC issue https://code.videolan.org/videolan/vlc/-/issues/26738 Signed-off-by: Steve Lhomme --- libavcodec/dxva2_hevc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/dxva2_hevc.c b/libavcodec/dxva2_hevc.c index c91bcf3eeb..6b239d9917 100644 --- a/libavcodec/dxva2_hevc.c +++ b/libavcodec/dxva2_hevc.c @@ -184,7 +184,7 @@ static void fill_picture_parameters(const AVCodecContext *avctx, AVDXVAContext * const HEVCFrame *frame = NULL; \ while (!frame && j < rpl->nb_refs) \ frame = rpl->ref[j++]; \ -if (frame) \ +if (frame && frame->flags & (HEVC_FRAME_FLAG_LONG_REF | HEVC_FRAME_FLAG_SHORT_REF)) \ pp->ref_list[i] = get_refpic_index(pp, ff_dxva2_get_surface_index(avctx, ctx, frame->frame)); \ else \ pp->ref_list[i] = 0xff; \ -- 2.29.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".
[FFmpeg-devel] [PATCH] avcodec/dxva2: don't call GetDesc on a NULL ID3D11VideoDecoderOutputView
We should return 0 and assert there's something wrong. This is how it's done
with the other DXVA variants.
It fixes bad reference usage in http://www.gbbsoft.pl/!download/!/Film1.mp4
It's using a frame that doesn't have any data[] fields set (yet?).
Signed-off-by: Steve Lhomme
---
libavcodec/dxva2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 568d686f39..043497b74f 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -777,7 +777,7 @@ unsigned ff_dxva2_get_surface_index(const AVCodecContext
*avctx,
#if CONFIG_D3D11VA
if (avctx->pix_fmt == AV_PIX_FMT_D3D11)
return (intptr_t)frame->data[1];
-if (avctx->pix_fmt == AV_PIX_FMT_D3D11VA_VLD) {
+if (avctx->pix_fmt == AV_PIX_FMT_D3D11VA_VLD && surface) {
D3D11_VIDEO_DECODER_OUTPUT_VIEW_DESC viewDesc;
ID3D11VideoDecoderOutputView_GetDesc((ID3D11VideoDecoderOutputView*)
surface, );
return viewDesc.Texture2D.ArraySlice;
--
2.29.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 12/13] avcodec/omx: Check initializing mutexes/conditions
On 2021-09-02 17:41, Andreas Rheinhardt wrote:
The earlier code did not properly check these initializations:
It only recorded whether the part of init where these initializations
are has been reached, but it did not check whether the initializations
were successful, although destroying them would be undefined behaviour
if they had not been initialized successfully.
Furthermore cleanup() always locked a mutex regardless of whether there
was any attempt to initialize these mutexes at all.
Signed-off-by: Andreas Rheinhardt
---
This is mostly untested: I only tested whether it compiles.
libavcodec/omx.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/libavcodec/omx.c b/libavcodec/omx.c
index 9597c60057..7086ddd3a4 100644
--- a/libavcodec/omx.c
+++ b/libavcodec/omx.c
@@ -43,6 +43,7 @@
#include "avcodec.h"
#include "h264.h"
#include "internal.h"
+#include "pthread_internal.h"
#ifdef OMX_SKIP64BIT
static OMX_TICKS to_omx_ticks(int64_t value)
@@ -218,7 +219,7 @@ typedef struct OMXCodecContext {
OMX_STATETYPE state;
OMX_ERRORTYPE error;
-int mutex_cond_inited;
+unsigned mutex_cond_inited_cnt;
int eos_sent, got_eos;
@@ -229,6 +230,12 @@ typedef struct OMXCodecContext {
int profile;
} OMXCodecContext;
+#define NB_MUTEX_CONDS 6
+#define OFF(field) offsetof(OMXCodecContext, field)
+DEFINE_OFFSET_ARRAY(OMXCodecContext, omx_codec_context, mutex_cond_inited_cnt,
+(OFF(input_mutex), OFF(output_mutex), OFF(state_mutex)),
+(OFF(input_cond), OFF(output_cond), OFF(state_cond)));
+
static void append_buffer(pthread_mutex_t *mutex, pthread_cond_t *cond,
int* array_size, OMX_BUFFERHEADERTYPE **array,
OMX_BUFFERHEADERTYPE *buffer)
@@ -591,6 +598,9 @@ static av_cold void cleanup(OMXCodecContext *s)
{
int i, executing;
+/* If the mutexes/condition variables have not been properly initialized,
+ * nothing has been initialized and locking the mutex might be unsafe. */
+if (s->mutex_cond_inited_cnt == NB_MUTEX_CONDS) {
pthread_mutex_lock(>state_mutex);
executing = s->state == OMX_StateExecuting;
pthread_mutex_unlock(>state_mutex);
@@ -620,20 +630,13 @@ static av_cold void cleanup(OMXCodecContext *s)
omx_deinit(s->omx_context);
s->omx_context = NULL;
-if (s->mutex_cond_inited) {
-pthread_cond_destroy(>state_cond);
-pthread_mutex_destroy(>state_mutex);
-pthread_cond_destroy(>input_cond);
-pthread_mutex_destroy(>input_mutex);
-pthread_cond_destroy(>output_cond);
-pthread_mutex_destroy(>output_mutex);
-s->mutex_cond_inited = 0;
-}
av_freep(>in_buffer_headers);
av_freep(>out_buffer_headers);
av_freep(>free_in_buffers);
av_freep(>done_out_buffers);
av_freep(>output_buf);
+}
+ff_pthread_free(s, omx_codec_context_offsets);
}
static av_cold int omx_encode_init(AVCodecContext *avctx)
@@ -644,17 +647,14 @@ static av_cold int omx_encode_init(AVCodecContext *avctx)
OMX_BUFFERHEADERTYPE *buffer;
OMX_ERRORTYPE err;
+/* cleanup relies on the mutexes/conditions being initialized first. */
+ret = ff_pthread_init(s, omx_codec_context_offsets);
+if (ret < 0)
+return ret;
s->omx_context = omx_init(avctx, s->libname, s->libprefix);
if (!s->omx_context)
Shouldn't you call ff_pthread_free() here ?
return AVERROR_ENCODER_NOT_FOUND;
-pthread_mutex_init(>state_mutex, NULL);
-pthread_cond_init(>state_cond, NULL);
-pthread_mutex_init(>input_mutex, NULL);
-pthread_cond_init(>input_cond, NULL);
-pthread_mutex_init(>output_mutex, NULL);
-pthread_cond_init(>output_cond, NULL);
-s->mutex_cond_inited = 1;
s->avctx = avctx;
s->state = OMX_StateLoaded;
s->error = OMX_ErrorNone;
--
2.30.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
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 01/13] avcodec/vp9: Do not destroy uninitialized mutexes/conditions
On 2021-09-02 17:34, Andreas Rheinhardt wrote:
Also do not destroy and reinitialize mutexes and conditions when
certain input parameters change. Given that the decoder did not
create these variables at all during init, uninitialized mutexes
and conditions are destroyed before the very first initialization.
This is undefined behaviour and certain threading implementations
like pthreadGC2 crash when it is attempted.
Fix this by initializing these objects once during init and freeing
them in close.
Works for me.
Reported-by: Steve Lhomme
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp9.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 874005a5ae..5c20a7ec5d 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -43,8 +43,6 @@ static void vp9_free_entries(AVCodecContext *avctx) {
VP9Context *s = avctx->priv_data;
if (avctx->active_thread_type & FF_THREAD_SLICE) {
-pthread_mutex_destroy(>progress_mutex);
-pthread_cond_destroy(>progress_cond);
av_freep(>entries);
}
}
@@ -66,9 +64,6 @@ static int vp9_alloc_entries(AVCodecContext *avctx, int n) {
for (i = 0; i < n; i++)
atomic_init(>entries[i], 0);
-
-pthread_mutex_init(>progress_mutex, NULL);
-pthread_cond_init(>progress_cond, NULL);
}
return 0;
}
@@ -1252,6 +1247,12 @@ static av_cold int vp9_decode_free(AVCodecContext *avctx)
free_buffers(s);
vp9_free_entries(avctx);
+#if HAVE_THREADS
+if (avctx->active_thread_type & FF_THREAD_SLICE) {
+pthread_mutex_destroy(>progress_mutex);
+pthread_cond_destroy(>progress_cond);
+}
+#endif
av_freep(>td);
return 0;
}
@@ -1797,6 +1798,13 @@ static av_cold int vp9_decode_init(AVCodecContext *avctx)
s->last_bpp = 0;
s->s.h.filter.sharpness = -1;
+#if HAVE_THREADS
+if (avctx->active_thread_type & FF_THREAD_SLICE) {
+pthread_mutex_init(>progress_mutex, NULL);
+pthread_cond_init(>progress_cond, NULL);
+}
+#endif
+
for (int i = 0; i < 3; i++) {
s->s.frames[i].tf.f = av_frame_alloc();
if (!s->s.frames[i].tf.f)
--
2.30.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/vp9: avoid using uninitialized mutex/condition
On 2021-09-02 11:27, Andreas Rheinhardt wrote:
Steve Lhomme:
When using slice decoding vp9_free_entries is called before vp9_alloc_entries
is ever called. It should destroy properly initialized variables (or check it
was never called before).
It usually works undetected as pthread implementations allows NULL as a special
value (and should return EINVAL but doesn't). But pthreadGC2 doesn't allow NULL
in pthread_mutex_destroy() and crashes when that's the case.
---
libavcodec/vp9.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 874005a5ae..d40e90b70e 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -1796,6 +1796,10 @@ static av_cold int vp9_decode_init(AVCodecContext *avctx)
s->last_bpp = 0;
s->s.h.filter.sharpness = -1;
+if (avctx->active_thread_type & FF_THREAD_SLICE) {
+pthread_mutex_init(>progress_mutex, NULL);
+pthread_cond_init(>progress_cond, NULL);
+}
for (int i = 0; i < 3; i++) {
s->s.frames[i].tf.f = av_frame_alloc();
1. progress_mutex and progress_cond don't exist if compiled without
threading support, so your patch will lead to compilation failures in
this case.
Ah yes, I missed that the 2 functions are conditionally compiled.
2. I don't see a reason why these mutexes need to be initialized and
destroyed when the dimensions/number of tile cols change at all. They
should be initialized once during init (if slice threading is used) and
freed during close (if they have been successfully initialized).
Yes, it makes total sense.
3. Initializing this condition and mutex is currently not checked.
I can fix this if you want.
Sure. This is currently leading to a crash in VLC 3.0 because we use a
pthread implementation that doesn't like this case (the only lib
compatible with XP).
https://code.videolan.org/videolan/vlc/-/issues/26017
___
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 v3] avcodec/vp9: avoid using uninitialized mutex/condition
When using slice decoding vp9_free_entries() is called before
vp9_alloc_entries() is ever called. It should destroy properly
initialized variables (or check it was never called before).
It usually works undetected as pthread implementations allows NULL as a
special value (and should return EINVAL but doesn't). But pthreadGC2
doesn't allow NULL in pthread_mutex_destroy() and crashes when that's
the case.
---
libavcodec/vp9.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 874005a5ae..f4af90eaec 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -1796,6 +1796,10 @@ static av_cold int vp9_decode_init(AVCodecContext *avctx)
s->last_bpp = 0;
s->s.h.filter.sharpness = -1;
+if (avctx->active_thread_type & FF_THREAD_SLICE) {
+pthread_mutex_init(>progress_mutex, NULL);
+pthread_cond_init(>progress_cond, NULL);
+}
for (int i = 0; i < 3; i++) {
s->s.frames[i].tf.f = av_frame_alloc();
--
2.29.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 v2] avcodec/vp9: avoid using uninitialized mutex/condition
v2: shorter commit lines and removed an extra space, now I realize it's
the wrong one, the original being also wrong...
On 2021-09-02 11:19, Steve Lhomme wrote:
When using slice decoding vp9_free_entries() is called before
vp9_alloc_entries() is ever called. It should destroy properly
initialized variables (or check it was never called before).
It usually works undetected as pthread implementations allows NULL as a
special value (and should return EINVAL but doesn't). But pthreadGC2
doesn't allow NULL in pthread_mutex_destroy() and crashes when that's
the case.
---
libavcodec/vp9.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 874005a5ae..8a3d82da09 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -42,7 +42,7 @@
static void vp9_free_entries(AVCodecContext *avctx) {
VP9Context *s = avctx->priv_data;
-if (avctx->active_thread_type & FF_THREAD_SLICE) {
+if (avctx->active_thread_type & FF_THREAD_SLICE) {
pthread_mutex_destroy(>progress_mutex);
pthread_cond_destroy(>progress_cond);
av_freep(>entries);
@@ -1796,6 +1796,10 @@ static av_cold int vp9_decode_init(AVCodecContext *avctx)
s->last_bpp = 0;
s->s.h.filter.sharpness = -1;
+if (avctx->active_thread_type & FF_THREAD_SLICE) {
+pthread_mutex_init(>progress_mutex, NULL);
+pthread_cond_init(>progress_cond, NULL);
+}
for (int i = 0; i < 3; i++) {
s->s.frames[i].tf.f = av_frame_alloc();
--
2.29.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".
___
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] avcodec/vp9: avoid using uninitialized mutex/condition
When using slice decoding vp9_free_entries() is called before
vp9_alloc_entries() is ever called. It should destroy properly
initialized variables (or check it was never called before).
It usually works undetected as pthread implementations allows NULL as a
special value (and should return EINVAL but doesn't). But pthreadGC2
doesn't allow NULL in pthread_mutex_destroy() and crashes when that's
the case.
---
libavcodec/vp9.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 874005a5ae..8a3d82da09 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -42,7 +42,7 @@
static void vp9_free_entries(AVCodecContext *avctx) {
VP9Context *s = avctx->priv_data;
-if (avctx->active_thread_type & FF_THREAD_SLICE) {
+if (avctx->active_thread_type & FF_THREAD_SLICE) {
pthread_mutex_destroy(>progress_mutex);
pthread_cond_destroy(>progress_cond);
av_freep(>entries);
@@ -1796,6 +1796,10 @@ static av_cold int vp9_decode_init(AVCodecContext *avctx)
s->last_bpp = 0;
s->s.h.filter.sharpness = -1;
+if (avctx->active_thread_type & FF_THREAD_SLICE) {
+pthread_mutex_init(>progress_mutex, NULL);
+pthread_cond_init(>progress_cond, NULL);
+}
for (int i = 0; i < 3; i++) {
s->s.frames[i].tf.f = av_frame_alloc();
--
2.29.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".
[FFmpeg-devel] [PATCH] avcodec/vp9: avoid using uninitialized mutex/condition
When using slice decoding vp9_free_entries is called before vp9_alloc_entries
is ever called. It should destroy properly initialized variables (or check it
was never called before).
It usually works undetected as pthread implementations allows NULL as a special
value (and should return EINVAL but doesn't). But pthreadGC2 doesn't allow NULL
in pthread_mutex_destroy() and crashes when that's the case.
---
libavcodec/vp9.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 874005a5ae..d40e90b70e 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -1796,6 +1796,10 @@ static av_cold int vp9_decode_init(AVCodecContext *avctx)
s->last_bpp = 0;
s->s.h.filter.sharpness = -1;
+if (avctx->active_thread_type & FF_THREAD_SLICE) {
+pthread_mutex_init(>progress_mutex, NULL);
+pthread_cond_init(>progress_cond, NULL);
+}
for (int i = 0; i < 3; i++) {
s->s.frames[i].tf.f = av_frame_alloc();
--
2.29.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".
[FFmpeg-devel] [PATCH] avformat/matroskadec: avoid warning on duration conversion
Do the conversion from double to uint64_t explicitly and only once.
The comparison to UINT64_MAX is not correct.
---
libavformat/matroskadec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 8a5bc4018a..4ff472005e 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2328,8 +2328,8 @@ static int matroska_parse_tracks(AVFormatContext *s)
if (track->type == MATROSKA_TRACK_TYPE_VIDEO) {
if (!track->default_duration && track->video.frame_rate > 0) {
-double default_duration = 10 / track->video.frame_rate;
-if (default_duration > UINT64_MAX || default_duration < 0) {
+uint64_t default_duration = (double)10 /
track->video.frame_rate;
+if (default_duration > UINT64_MAX) {
av_log(matroska->ctx, AV_LOG_WARNING,
"Invalid frame rate %e. Cannot calculate default
duration.\n",
track->video.frame_rate);
--
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".
[FFmpeg-devel] [PATCH 2/2] avformat/matroskadec: adjust the cluster time to the track timebase
The Block timestamp read in matroska_parse_block() is in track timebase and is
passed on as such to the AVPacket which uses this timebase.
In the normal case the Cluster and Track timebases are the same because the
track->time_scale is 1.0. But when it is not the case, the values in Cluster
timebase need to be transformed in Track timebase so they can be added
together.
---
libavformat/matroskadec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index ba0e2956df..137674c068 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3581,7 +3581,8 @@ static int matroska_parse_block(MatroskaDemuxContext
*matroska, AVBufferRef *buf
if (cluster_time != (uint64_t) -1 &&
(block_time >= 0 || cluster_time >= -block_time)) {
-timecode = cluster_time + block_time - track->codec_delay_in_track_tb;
+uint64_t timecode_cluster_in_track_tb = (double) cluster_time /
track->time_scale;
+timecode = timecode_cluster_in_track_tb + block_time -
track->codec_delay_in_track_tb;
if (track->type == MATROSKA_TRACK_TYPE_SUBTITLE &&
timecode < track->end_timecode)
is_keyframe = 0; /* overlapping subtitles are not key frame */
--
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".
[FFmpeg-devel] [PATCH] avformat/matroskadec: only use the track duration if it exists
No need to multiplying/dividing when we know it's zero.
---
libavformat/matroskadec.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 4ff472005e..25b22afebe 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3547,7 +3547,7 @@ static int matroska_parse_block(MatroskaDemuxContext
*matroska, AVBufferRef *buf
uint32_t lace_size[256];
int n, flags, laces = 0;
uint64_t num;
-int trust_default_duration = 1;
+int trust_default_duration;
ffio_init_context(, data, size, 0, NULL, NULL, NULL, NULL);
@@ -3615,7 +3615,8 @@ static int matroska_parse_block(MatroskaDemuxContext
*matroska, AVBufferRef *buf
return res;
}
-if (track->audio.samplerate == 8000) {
+trust_default_duration = track->default_duration != 0;
+if (track->audio.samplerate == 8000 && trust_default_duration) {
// If this is needed for more codecs, then add them here
if (st->codecpar->codec_id == AV_CODEC_ID_AC3) {
if (track->audio.samplerate != st->codecpar->sample_rate ||
!st->codecpar->frame_size)
--
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".
[FFmpeg-devel] [PATCH] avformat/matroskadec: update the end timestamp when there is a timestamp
No need to check if the cluster has a timestamp or not. If we found a timestamp for this block, then it's usable. This is actually the same condition to decide if we can use the timestamp or not. --- libavformat/matroskadec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c index 137674c068..8a5bc4018a 100644 --- a/libavformat/matroskadec.c +++ b/libavformat/matroskadec.c @@ -3626,7 +3626,7 @@ static int matroska_parse_block(MatroskaDemuxContext *matroska, AVBufferRef *buf if (!block_duration && trust_default_duration) block_duration = track->default_duration * laces / matroska->time_scale; -if (cluster_time != (uint64_t)-1 && (block_time >= 0 || cluster_time >= -block_time)) +if (timecode != AV_NOPTS_VALUE) track->end_timecode = FFMAX(track->end_timecode, timecode + block_duration); -- 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".
[FFmpeg-devel] [PATCH 1/2] avformat/matroskadec: add a warning when the track TimestampScale won't be used
---
libavformat/matroskadec.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 981e044263..ba0e2956df 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2672,8 +2672,12 @@ static int matroska_parse_tracks(AVFormatContext *s)
av_log(matroska->ctx, AV_LOG_INFO,
"Unknown/unsupported AVCodecID %s.\n", track->codec_id);
-if (track->time_scale < 0.01)
+if (track->time_scale < 0.01) {
+av_log(matroska->ctx, AV_LOG_WARNING,
+ "Track TimestampScale too small %f, assuming 1.0.\n",
+ track->time_scale);
track->time_scale = 1.0;
+}
avpriv_set_pts_info(st, 64, matroska->time_scale * track->time_scale,
1000 * 1000 * 1000);/* 64 bit pts in ns */
--
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 v3 1/2] dxva: wait until D3D11 buffer copies are done before submitting them
On 2020-08-13 1:01, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of Steve Lhomme Sent: Wednesday, August 12, 2020 2:05 PM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer copies are done before submitting them On 2020-08-11 12:43, Steve Lhomme wrote: Sorry if you seem to know all the answers already, but I don't and so I have to investigate. Last year, I had literally worked this down to death. I followed every slightest hint from countless searches, read through hundreds of discussions, driven because I was unwilling to believe that up-/downloading of video textures with D3D11 can't be done equally fast as with D3D9. (the big picture was the implementation of D3D11 support for QuickSync where the slowdown played a much bigger role than with D3D11VA decoders only). Eventually I landed at some internal Nvidia presentation, some talks with MS guys and some source code discussion deep inside a 3D game engine (not a no-name). It really bugs me that I didn't properly note the references, but from somewhere in between I was able to gather solid evidence about what is legal to do and what Is not. Based on that, followed several iterations to find the optimal way for doing the texture transfer. As I had implemented D3D11 support for QuickSync, this got pretty complicated because with a full transcoding pipeline, all parts (decoder, encoder and filters) can (and usually will) request textures. Only the latest Intel Drivers can work with array textures everywhere (e.g. VPP), so I also needed to add support for non-array texture allocation. The patch you've seen is the result of weeks of intensive work (a small but crucial part of it) - even when it may not look like that. Sorry if you seem to know all the answers already Obviously, I don't know all the answers, but all the answers I have given were correct. And when I didn't have an answer I always respectfully said that your situation might be different. And I didn't reply by implying that you would have done your work by trial-and-error or most likely invalid assumptions or deductions. I still don't know how you are actually operating this and thus I also cannot tell what might or might not work in your case. All I can tell is that the procedure that I have described (1-2-3-4) can work rock-solid for multi-threaded DX11 texture transfer when it's done in the same way as I've shown. And believe it or not - I would still be happy when it would be of any use for you... Even though the discussion is heated (fitting with the weather here) I don't mind. I learned some stuff and it pushed me to dig deeper. I can't just accept your word for it. I need something solid if I'm going to remove a lock that helped me so far. So I'm currently tooling VLC to be able to bring the decoder to its knees and find out what it can and cannot do safely. So far I can still see decoding artifacts when I don't a lock, which would mean I still need the mutex, for the reasons given in the previous mail. A follow-up on this. Using ID3D10Multithread seems to be enough to have mostly thread safe ID3D11Device/ID3D11DeviceContext/etc. Even the decoding with its odd API seem to know what to do when submitted different buffers. I did not manage to saturate the GPU but I much bigger decoding speed/throughput to validate the errors I got before. Many of them were due to VLC dropping data because of odd timing. Now I still have some threading issues. For example for deinterlacing we create a ID3D11VideoProcessor to handle the deinterlacing. And we create it after the decoding started (as the deinterlacing can be enabled/disabled dynamically). Without the mutex in the decoder it crashes on ID3D11VideoDevice::CreateVideoProcessor() and ID3D11VideoContext::SubmitDecoderBuffers() as they are being called simultaneously. If I add the mutex between the decoder and just this filter (not the rendering side) it works fine. So I guess I'm stuck with the mutex for the time being. At an earlier stage I had considered the idea of adding those video processors as ffmpeg hardware filters, but due to the vast amount of different use cases, platforms and hw accelerations we support, I had made the decision that we do all filtering either by CPU or in the hw context of the en-coder, but never in the hw context of the de-coder, so I don't have any experience with DX11 video processors. Maybe a too obvious idea: How about activating the mutex use only for a short time during the process of adding the video processor? This doesn't seem feasable, even with a callback system. You don't know when it's safe to enable/disable it. By the way the origin of the mutex was on Windows Phones. It's probably related to the fact that some phones only decode to DXGI_FORMAT_I420_OPAQUE which cannot be used for rendering. The only way to use the decoded surface is to convert it (to NV12) via a VideoProcessor. So
Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer copies are done before submitting them
On 2020-08-11 12:43, Steve Lhomme wrote: Sorry if you seem to know all the answers already, but I don't and so I have to investigate. Last year, I had literally worked this down to death. I followed every slightest hint from countless searches, read through hundreds of discussions, driven because I was unwilling to believe that up-/downloading of video textures with D3D11 can't be done equally fast as with D3D9. (the big picture was the implementation of D3D11 support for QuickSync where the slowdown played a much bigger role than with D3D11VA decoders only). Eventually I landed at some internal Nvidia presentation, some talks with MS guys and some source code discussion deep inside a 3D game engine (not a no-name). It really bugs me that I didn't properly note the references, but from somewhere in between I was able to gather solid evidence about what is legal to do and what Is not. Based on that, followed several iterations to find the optimal way for doing the texture transfer. As I had implemented D3D11 support for QuickSync, this got pretty complicated because with a full transcoding pipeline, all parts (decoder, encoder and filters) can (and usually will) request textures. Only the latest Intel Drivers can work with array textures everywhere (e.g. VPP), so I also needed to add support for non-array texture allocation. The patch you've seen is the result of weeks of intensive work (a small but crucial part of it) - even when it may not look like that. Sorry if you seem to know all the answers already Obviously, I don't know all the answers, but all the answers I have given were correct. And when I didn't have an answer I always respectfully said that your situation might be different. And I didn't reply by implying that you would have done your work by trial-and-error or most likely invalid assumptions or deductions. I still don't know how you are actually operating this and thus I also cannot tell what might or might not work in your case. All I can tell is that the procedure that I have described (1-2-3-4) can work rock-solid for multi-threaded DX11 texture transfer when it's done in the same way as I've shown. And believe it or not - I would still be happy when it would be of any use for you... Even though the discussion is heated (fitting with the weather here) I don't mind. I learned some stuff and it pushed me to dig deeper. I can't just accept your word for it. I need something solid if I'm going to remove a lock that helped me so far. So I'm currently tooling VLC to be able to bring the decoder to its knees and find out what it can and cannot do safely. So far I can still see decoding artifacts when I don't a lock, which would mean I still need the mutex, for the reasons given in the previous mail. A follow-up on this. Using ID3D10Multithread seems to be enough to have mostly thread safe ID3D11Device/ID3D11DeviceContext/etc. Even the decoding with its odd API seem to know what to do when submitted different buffers. I did not manage to saturate the GPU but I much bigger decoding speed/throughput to validate the errors I got before. Many of them were due to VLC dropping data because of odd timing. Now I still have some threading issues. For example for deinterlacing we create a ID3D11VideoProcessor to handle the deinterlacing. And we create it after the decoding started (as the deinterlacing can be enabled/disabled dynamically). Without the mutex in the decoder it crashes on ID3D11VideoDevice::CreateVideoProcessor() and ID3D11VideoContext::SubmitDecoderBuffers() as they are being called simultaneously. If I add the mutex between the decoder and just this filter (not the rendering side) it works fine. So I guess I'm stuck with the mutex for the time being. Here is the stack trace on an Intel 630 GPU: igd11dxva64.dll!7ffc384a8d24() (Unknown Source:0) igd11dxva64.dll!7ffc38452030() (Unknown Source:0) igd11dxva64.dll!7ffc3845a081() (Unknown Source:0) igd11dxva64.dll!7ffc38465a27() (Unknown Source:0) igd11dxva64.dll!7ffc386067d2() (Unknown Source:0) igd11dxva64.dll!7ffc3883c9f3() (Unknown Source:0) igd11dxva64.dll!7ffc3867145a() (Unknown Source:0) igd11dxva64.dll!7ffc3866ea23() (Unknown Source:0) igd11dxva64.dll!7ffc3881b4ac() (Unknown Source:0) igd11dxva64.dll!7ffc384f7bdc() (Unknown Source:0) igd11dxva64.dll!7ffc384fa2a5() (Unknown Source:0) igd11dxva64.dll!7ffc3847a334() (Unknown Source:0) d3d11.dll!7ffcabc33e8d() (Unknown Source:0) d3d11.dll!7ffcabc3389d() (Unknown Source:0) d3d11_3SDKLayers.dll!7ffc3184fa6b() (Unknown Source:0) calling ID3D11VideoContext::SubmitDecoderBuffers() libavcodec_plugin.dll!ff_dxva2_common_end_frame(AVCodecContext * avctx, AVFrame * frame, const void * pp, unsigned int pp_size, const void * qm, unsigned int qm_size, int(*)(AVCodecContext *, void *, void *) commit_bs_si) Line 1085 (c:\Users\robux\Documents\Programs\Videolabs\build\win64
Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer copies are done before submitting them
On 2020-08-11 13:08, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of Steve Lhomme Sent: Tuesday, August 11, 2020 12:44 PM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer copies are done before submitting them Even though the discussion is heated (fitting with the weather here) I don't mind. I learned some stuff and it pushed me to dig deeper. I can't just accept your word for it. I need something solid if I'm going to remove a lock that helped me so far. You're not supposed to accept my word. I wouldn’t do either. You could have just valued it as a possibility..that's all. So I'm currently tooling VLC to be able to bring the decoder to its knees and find out what it can and cannot do safely. So far I can still see decoding artifacts when I don't a lock, which would mean I still need the mutex, for the reasons given in the previous mail. Are you actually using D3D11 staging textures? I'm still not clear about that "old-api" way. No. I render the texture slices on the screen straight from the decoder. In a separate thread from the libavcodec thread(s). I'm curious: what's your motivation for using D3D11 over D3D9? At first for UWP apps (no other way except for D3D12). But now also because it supports HDR. I mean, we are always transcoding without rendering a video to any surface. Our reasons to use D3D11 are these two: 1. Works headless (without connected display) 2. Works without user session (like inside a Windows service) What's yours? When implementing D3D11 for QuickSync I managed to get very close to DXVA2 performance eventually, but I hardly ever have been able to exceed it.. Same here, especially because I never managed to make it work without copying first to another texture. But I might give it another try in light of all this. PS: Yes, it's damn hot here as well! :-) 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".
Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer copies are done before submitting them
Sorry if you seem to know all the answers already, but I don't and so I have to investigate. Last year, I had literally worked this down to death. I followed every slightest hint from countless searches, read through hundreds of discussions, driven because I was unwilling to believe that up-/downloading of video textures with D3D11 can't be done equally fast as with D3D9. (the big picture was the implementation of D3D11 support for QuickSync where the slowdown played a much bigger role than with D3D11VA decoders only). Eventually I landed at some internal Nvidia presentation, some talks with MS guys and some source code discussion deep inside a 3D game engine (not a no-name). It really bugs me that I didn't properly note the references, but from somewhere in between I was able to gather solid evidence about what is legal to do and what Is not. Based on that, followed several iterations to find the optimal way for doing the texture transfer. As I had implemented D3D11 support for QuickSync, this got pretty complicated because with a full transcoding pipeline, all parts (decoder, encoder and filters) can (and usually will) request textures. Only the latest Intel Drivers can work with array textures everywhere (e.g. VPP), so I also needed to add support for non-array texture allocation. The patch you've seen is the result of weeks of intensive work (a small but crucial part of it) - even when it may not look like that. Sorry if you seem to know all the answers already Obviously, I don't know all the answers, but all the answers I have given were correct. And when I didn't have an answer I always respectfully said that your situation might be different. And I didn't reply by implying that you would have done your work by trial-and-error or most likely invalid assumptions or deductions. I still don't know how you are actually operating this and thus I also cannot tell what might or might not work in your case. All I can tell is that the procedure that I have described (1-2-3-4) can work rock-solid for multi-threaded DX11 texture transfer when it's done in the same way as I've shown. And believe it or not - I would still be happy when it would be of any use for you... Even though the discussion is heated (fitting with the weather here) I don't mind. I learned some stuff and it pushed me to dig deeper. I can't just accept your word for it. I need something solid if I'm going to remove a lock that helped me so far. So I'm currently tooling VLC to be able to bring the decoder to its knees and find out what it can and cannot do safely. So far I can still see decoding artifacts when I don't a lock, which would mean I still need the mutex, for the reasons given in the previous mail. ___ 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 v3 1/2] dxva: wait until D3D11 buffer copies are done before submitting them
On 2020-08-11 8:58, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of Steve Lhomme Sent: Tuesday, August 11, 2020 6:35 AM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer copies are done before submitting them [...] But SetMultithreadProtected in fact has the effect of protecting the methods from ID3D11DeviceContext (not device). Like I explained several times already. Luckily I've just seen that there has been a change meanwhile. The undocumented behavior has finally been made public by adding a DX11 version of SetMultithreadProtected (which does the same as what happens when you use the DX10 version with DX11) https://docs.microsoft.com/en-us/windows/win32/api/d3d11_4/nn- d3d11_4- id3d11multithread OK, this is very interesting. It certainly clarifies that it's ID3D11DeviceContext related. The documentation is still sketchy though. For example ::Enter() [1] says that it enters a device critical section, not a device context critical section. So if you have multiple device context everything is blocked. This kinda defeats the use of multiple threads. Also this interface is not available until Windows 10 Creator Update. So for example it cannot be used on Windows 7. Maybe the D3D10 version has the same effect but there's no guarantee. Still playing "the doubtful" is not a sincere reaction after having been proven wrong. Sorry if you seem to know all the answers already, but I don't and so I have to investigate. I'll try without the mutex (old API) on Windows 7 and see the effect. I did some more test on Win10 before trying Win7. And removing the mutex is not an option. There's a lot of bogus frames. It makes sense, as the API is not meant to be thread-safe. The SubmitDecoderBuffers() has no way of knowing exactly which buffers you are providing. Each buffer is tied to an index of the slice so it could be called without a lock, as long as 2 threads don't try to use the same slice at the same time. But when you submit the buffers you only give the type. I suppose D3D11 takes the last buffer of each type that was released (which is pretty much an unmap, so should have similar internal synchronization). But if 2 threads release a buffer of the same type and submit it right after, D3D11 has no way to know which to use. Here's an example: - thread A releases a D3D11_VIDEO_DECODER_BUFFER_BITSTREAM for slice 0 - thread B releases a D3D11_VIDEO_DECODER_BUFFER_BITSTREAM for slice 1 - thread A submit a buffer of type D3D11_VIDEO_DECODER_BUFFER_BITSTREAM - thread B submit a buffer of type D3D11_VIDEO_DECODER_BUFFER_BITSTREAM D3D11 doesn't seem to keep track of which thread submitted what (and in single thread you could also release 2 buffer of the same type and submit them, I'm not sure what would happen). And so the Thread A submit is likely using the buffer from Thread B. I'm not even sure what Thread B would be using. The mutex/lock groups the buffer get/release and submit together, so that no other thread can do the same thing at the same time. D3D11 cannot do it by itself, even with multithread turned on. (D3D12 doesn't have this problem as you submit the actual buffer, not just the type [1][2]) None of that happens if you use a single thread for decoding. My patch requires feature level 11_1: > https://github.com/softworkz/ffmpeg_dx11/commit/c09cc37ce7f513717493e060df740aa0e7374257#diff-08dfe4cade908944fd2815bf36309d7bR591-R592 Windows 7 does not have DX11.1 (there's a 11.1 platform update for Win 7 but it doesn't provide full 11.1) For Win7 and below we're using D3D9 with DXVA2 only. Kind regards, softworkz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel [1] https://docs.microsoft.com/en-us/windows/win32/api/d3d12video/nf-d3d12video-id3d12videodecodecommandlist-decodeframe [2] https://docs.microsoft.com/en-us/windows/win32/api/d3d12video/ns-d3d12video-d3d12_video_decode_frame_argument ___ 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 v3 1/2] dxva: wait until D3D11 buffer copies are done before submitting them
On 2020-08-11 3:52, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of Steve Lhomme Sent: Monday, August 10, 2020 2:15 PM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer copies are done before submitting them @Steven My name is Steve. I apologize for that. My change in e3d4784eb31b3ea4a97f2d4c698a75fab9bf3d86 is optional. So much that it even requires to use the creator helper function to make sure the mutex is properly initialized to an empty value and retain backward compatibility. If you don't want to use many threads you can safely ignore this field. I thought you had reviewed my code, because you said that it was you who had added the locks that I have removed. I just took a look at your commit I said "This is how I ended up adding the mutex to the old API (e3d4784eb31b3ea4a97f2d4c698a75fab9bf3d86)." I never claimed I added the locks. e3d4784eb31b3ea4a97f2d4c698a75fab9bf3d86 and I can say that those are not the locks that I have removed. So you are actually the wrong address for the lock removal, you've just thrown yourself in the line ;-) No. You misread what I said. I was explaining that my experience on multiple devices lead me to add this mutex otherwise it would not work properly or even crash. But the DX11 subject still needs some clarification... The documentation for ID3D11DeviceContext is very clear about that [2]: "Because each ID3D11DeviceContext is single threaded, only one thread can call a ID3D11DeviceContext at a time. If multiple threads must access a single ID3D11DeviceContext, they must use some synchronization mechanism, such as critical sections, to synchronize access to that ID3D11DeviceContext." Yes, but this doesn't apply to accessing staging textures IIRC. It does. To copy to a staging texture you need to use ID3D11DeviceContext::CopySubresourceRegion(). Correct. And with DX11 and using SetMultithreadProtected it is legal to call this from multiple threads without synchronization. No. I already explained it and pointed to the Microsoft documentation [1]. SetMultithreadProtected relates to ID3D11Device. No, that's exactly wrong. You need to re-read. ID3D11Device is thread-safe by default. You can read that everywhere throughout the documentation. I read the documentation. That's not how I understood it. ID3D11Device is safe "by default" meaning it can be turned off. I assumed SetMultithreadProtected() is the way to do that. It seems D3D11_CREATE_DEVICE_SINGLETHREADED is the way to make it not thread safe. SetMultithreadProtected initially didn't even have a D3D11 interface. The documentation also didn't tell anything about it. There was only the DX10 documentation for this. But SetMultithreadProtected in fact has the effect of protecting the methods from ID3D11DeviceContext (not device). Like I explained several times already. Luckily I've just seen that there has been a change meanwhile. The undocumented behavior has finally been made public by adding a DX11 version of SetMultithreadProtected (which does the same as what happens when you use the DX10 version with DX11) https://docs.microsoft.com/en-us/windows/win32/api/d3d11_4/nn-d3d11_4-id3d11multithread OK, this is very interesting. It certainly clarifies that it's ID3D11DeviceContext related. The documentation is still sketchy though. For example ::Enter() [1] says that it enters a device critical section, not a device context critical section. So if you have multiple device context everything is blocked. This kinda defeats the use of multiple threads. Also this interface is not available until Windows 10 Creator Update. So for example it cannot be used on Windows 7. Maybe the D3D10 version has the same effect but there's no guarantee. In fact it wasn't sufficient on mobile devices. I'll try without the mutex (old API) on Windows 7 and see the effect. Anyway this thread/patch is about waiting for data to be fully copied between the CPU and the GPU before submitting the decoding command. Not about thread/command synchronization. Now: Read the docs! PS: I need to say that your way of discrediting my statements was not very respectful. Likewise. 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". [1] https://docs.microsoft.com/en-us/windows/win32/api/d3d11_4/nf-d3d11_4-id3d11multithread-enter ___ 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 v3 1/2] dxva: wait until D3D11 buffer copies are done before submitting them
On 2020-08-10 12:04, Soft Works wrote: the very least the locks are needed inside libavcodec to avoid setting DXVA buffers concurrently from different threads. It will most likely result in very bad distortions if not crashes. Maybe you're only using 1 decoding thread with DXVA (which a lot of people do) so you don't have this issue, but this is not my case. I see no point in employing multiple threads for hw accelerated decoding. To be honest I never looked into or tried whether ffmpeg even supports multiple threads with dva2 or d3d11va hw acceleration. Maybe you're in an ideal situation where all the files you play through libavcodec are hardware accelerated (so also with matching hardware). In this case you don't need to care about the case where it will fallback to software decoding. Using a single thread in that case would have terrible performance. I think we need to clarify the use cases we're talking about. There is no "my case". All I'm talking about is using D3D11VA hardware acceleration using the ffmpeg.exe CLI. You seem to have a rather special case where you are using parts of the ffmpeg DXVA/D3D11VA code from another application (VLC?) I don't think there is anything special about using libavcodec in another application. That's where the code we're discussing is, not the ffmpeg CLI or ffplay. The API has to be designed to work in all host apps, not just these simpler use cases. Did I understand that correctly? The documentation for ID3D11DeviceContext is very clear about that [2]: "Because each ID3D11DeviceContext is single threaded, only one thread can call a ID3D11DeviceContext at a time. If multiple threads must access a single ID3D11DeviceContext, they must use some synchronization mechanism, such as critical sections, to synchronize access to that ID3D11DeviceContext." Yes, but this doesn't apply to accessing staging textures IIRC. It does. To copy to a staging texture you need to use ID3D11DeviceContext::CopySubresourceRegion(). Correct. And with DX11 and using SetMultithreadProtected it is legal to call this from multiple threads without synchronization. No. I already explained it and pointed to the Microsoft documentation [1]. SetMultithreadProtected relates to ID3D11Device. ID3D11DeviceContext needs to be managed as non-thread safe resource. If you want, you can even create one ID3D11DeviceContext per thread [2]. I'd be curious to see the effect on multithreaded decoding. Also it seems SetMultithreadProtected() is not even needed by default. It enables the "thread-safe layer" [3]. But in d3d11 that's the default behavior. See [4] "Use this flag if your application will only call methods of Direct3D 11 interfaces from a single thread. By default, the ID3D11Device object is thread-safe." SetMultithreadProtected() only made sense for D3D10: "Direct3D 11 has been designed from the ground up to support multithreading. Direct3D 10 implements limited support for multithreading using the thread-safe layer." You probably don't have any synchronization issues in your pipeline because it seems you copy from GPU to CPU. In that case it forces the ID3D11DeviceContext::GetData() internally to make sure all the commands to produce your source texture on that video context are finished processing. You may not see it, but there's a wait happening there. I've looked back into my work history and gladly most memory came back. Yes, it's correct, there's a "wait happening". From your wording I would assume that you've already realized that I was right in stating that there's no need for an external locking: - Not for uploading - Not for downloading (at least not for the regular ffmpeg use case) There is still some locking applied: Internally inside the DX11 runtime (because we are using SetMultithreadProtected). And there's also the "wait happening". As the doc says, you have to use some synchronization. It may work in your case (FFmpeg CLI I suppose). As you mentioned you only use one thread. There's less chance that it can fail. But copying memory to/from CPU/GPU is probably the slowest part of the whole decoding (hence we don't do any in VLC in normal playback). So if you have one decoding thread doing that copy and another thread reading on the same ID3D11DeviceContext you're likely going to race-condition issues. I don't know what FFmpeg CLI does, so I can't tell. Let's go through an example: Downloading of a texture 1. Context_CopySubresourceRegion: Copy GPU texture to staging texture CopySubresourceRegion is asynchronous anyway. It just puts the copy request into the DX11 processing queue. Using SetMultithreadProtected avoids any race conditions, but this call always returns immediately. 2. Context_Map: Make the staging texture accessible for the CPU When called without MapFlags, this call blocks until the texture is mapped (and we can be sure that CopySubresourceRegion is executed by then). => This is the 'wait' you've been
Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer copies are done before submitting them
On 2020-08-08 8:24, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of Steve Lhomme Sent: Saturday, August 8, 2020 7:10 AM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer copies are done before submitting them [...] Hi Steven, Hi, A while ago I had extended D3D11VA implementation to support single (non-array textures) for interoperability with Intel QSV+DX11. Looking at your code, it seems you are copying from an array texture to a single slice texture to achieve this. With double the amount of RAM. It may be a design issue with the new D3D11 API, which forces you to do With D3D11, it's mandatory to use a staging texture, which is not only done in my code but also in the original implementation (hwcontext_d3d11va.c) https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/hwcontext_d3d11va.c that, but I'm not using that API. I'm using the old API. I'm not sure whether I understand what you mean by this. To my knowledge there are two DX hw context implementations in ffmpeg: - DXVA2 - D3D11VA I'm not aware of a variant like "D3D11 with old API". Could you please elaborate? There is AV_PIX_FMT_D3D11VA_VLD (old) and AV_PIX_FMT_D3D11 (new). Hence, I don't think that your patch is the best possible way . Removing locks and saying "it works for me" is neither a correct solution. How did you come to the conclusion that I might be working like this? The commented out "hwctx->lock" lines in your code. the very least the locks are needed inside libavcodec to avoid setting DXVA buffers concurrently from different threads. It will most likely result in very bad distortions if not crashes. Maybe you're only using 1 decoding thread with DXVA (which a lot of people do) so you don't have this issue, but this is not my case. I see no point in employing multiple threads for hw accelerated decoding. To be honest I never looked into or tried whether ffmpeg even supports multiple threads with dva2 or d3d11va hw acceleration. Maybe you're in an ideal situation where all the files you play through libavcodec are hardware accelerated (so also with matching hardware). In this case you don't need to care about the case where it will fallback to software decoding. Using a single thread in that case would have terrible performance. Even then, there's still a chance using multiple threads might improve performance. All the code that is run to prepare the buffers that are fed into the hardware decoder can be run in parallel for multiple frames. If you have an insanely fast hardware decoder that would be the bottleneck. In a transcoding scenario that could have an impact. Also ID3D10Multithread::SetMultithreadProtected means that the resources can be accessed from multiple threads. It doesn't mean that calls to ID3D11DeviceContext are safe from multithreading. And my experience shows that it is not. In fact if you have the Windows SDK installed and you have concurrent accesses, you'll get a big warning in your debug logs that you are doing something fishy. On WindowsPhone it would even crash. This is how I ended up adding the mutex to the old API (e3d4784eb31b3ea4a97f2d4c698a75fab9bf3d86). The documentation for ID3D11DeviceContext is very clear about that [1]: "Because each ID3D11DeviceContext is single threaded, only one thread can call a ID3D11DeviceContext at a time. If multiple threads must access a single ID3D11DeviceContext, they must use some synchronization mechanism, such as critical sections, to synchronize access to that ID3D11DeviceContext." Yes, but this doesn't apply to accessing staging textures IIRC. It does. To copy to a staging texture you need to use ID3D11DeviceContext::CopySubresourceRegion(). You probably don't have any synchronization issues in your pipeline because it seems you copy from GPU to CPU. In that case it forces the ID3D11DeviceContext::GetData() internally to make sure all the commands to produce your source texture on that video context are finished processing. You may not see it, but there's a wait happening there. In my case there's nothing happening between the decoder and the rendering of the texture. In fact, I had researched this in-depth, but I can't tell much more without looking into it again. The patch I referenced is working in production on thousands of installations and tested with many different hardware and driver versions from Nvidia, Intel and AMD. And I added the lock before, as the specs say, it's necessary. That solved some issues on the hundred of millions of VLC running on Windows on all the hardware you can think of. Decoding 8K 60 fps HEVC was also a good stress test of the code. The ID3D11DeviceContext::GetData() in the rendering side ensured that we had the frames displayed in the right time and not whenever the pipeline is done processing the device context commands.
Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer copies are done before submitting them
On 2020-08-07 23:59, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of Steve Lhomme Sent: Friday, August 7, 2020 3:05 PM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer copies are done before submitting them I experimented a bit more with this. Here are the 3 scenarii in other of least frame late: - GetData waiting for 1/2s and releasing the lock - No use of GetData (current code) - GetData waiting for 1/2s and keeping the lock The last option has horrible perfomance issues and should not be used. The first option gives about 50% less late frames compared to the current code. *But* it requires to unlock the Video Context. There are 2 problems with this: - the same ID3D11Asynchronous is used to wait on multiple concurrent thread. This can confuse D3D11 which emits a warning in the logs. - another thread might Get/Release some buffers and submit them before this thread is finished processing. That can result in distortions, for example if the second thread/frame depends on the first thread/frame which is not submitted yet. The former issue can be solved by using a ID3D11Asynchronous per thread. That requires some TLS storage which FFmpeg doesn't seem to support yet. With this I get virtually no frame late. The latter issue only occur if the wait is too long. For example waiting by increments of 10ms is too long in my test. Using increments of 1ms or 2ms works fine in the most stressing sample I have (Sony Camping HDR HEVC high bitrate). But this seems hackish. There's still potentially a quick frame (alt frame in VPx/AV1 for example) that might get through to the decoder too early. (I suppose that's the source of the distortions I see) It's also possible to change the order of the buffer sending, by starting with the bigger one (D3D11_VIDEO_DECODER_BUFFER_BITSTREAM). But it seems to have little influence, regardless if we wait for buffer submission or not. The results are consistent between integrated GPU and dedicated GPU. Hi Steven, Hi, A while ago I had extended D3D11VA implementation to support single (non-array textures) for interoperability with Intel QSV+DX11. Looking at your code, it seems you are copying from an array texture to a single slice texture to achieve this. With double the amount of RAM. It may be a design issue with the new D3D11 API, which forces you to do that, but I'm not using that API. I'm using the old API. In my case I directly render the texture slices coming out of the decoder with no copying (and no extra memory allocation). It is happening in a different thread than the decoder thread(s). Also in VLC we also support direct D3D11 to QSV encoding. It does require a copy to "shadow" textures to feed QSV. I never managed to make it work without a copy. I noticed a few bottlenecks making D3D11VA significantly slower than DXVA2. The solution was to use ID3D10Multithread_SetMultithreadProtected and remove all the locks which are currently applied. I am also using that. Hence, I don't think that your patch is the best possible way . Removing locks and saying "it works for me" is neither a correct solution. At the very least the locks are needed inside libavcodec to avoid setting DXVA buffers concurrently from different threads. It will most likely result in very bad distortions if not crashes. Maybe you're only using 1 decoding thread with DXVA (which a lot of people do) so you don't have this issue, but this is not my case. Also ID3D10Multithread::SetMultithreadProtected means that the resources can be accessed from multiple threads. It doesn't mean that calls to ID3D11DeviceContext are safe from multithreading. And my experience shows that it is not. In fact if you have the Windows SDK installed and you have concurrent accesses, you'll get a big warning in your debug logs that you are doing something fishy. On WindowsPhone it would even crash. This is how I ended up adding the mutex to the old API (e3d4784eb31b3ea4a97f2d4c698a75fab9bf3d86). The documentation for ID3D11DeviceContext is very clear about that [1]: "Because each ID3D11DeviceContext is single threaded, only one thread can call a ID3D11DeviceContext at a time. If multiple threads must access a single ID3D11DeviceContext, they must use some synchronization mechanism, such as critical sections, to synchronize access to that ID3D11DeviceContext." The DXVA documentation is a lot less clearer on the subject. But given the ID3D11VideoContext derives from a ID3D11DeviceContext (but is not a ID3D11DeviceContext) it's seem correct to assume it has the same restrictions. [1] https://docs.microsoft.com/en-us/windows/win32/direct3d11/overviews-direct3d-11-render-multi-thread-intro ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit lin
Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer copies are done before submitting them
I experimented a bit more with this. Here are the 3 scenarii in other of
least frame late:
- GetData waiting for 1/2s and releasing the lock
- No use of GetData (current code)
- GetData waiting for 1/2s and keeping the lock
The last option has horrible perfomance issues and should not be used.
The first option gives about 50% less late frames compared to the
current code. *But* it requires to unlock the Video Context. There are 2
problems with this:
- the same ID3D11Asynchronous is used to wait on multiple concurrent
thread. This can confuse D3D11 which emits a warning in the logs.
- another thread might Get/Release some buffers and submit them before
this thread is finished processing. That can result in distortions, for
example if the second thread/frame depends on the first thread/frame
which is not submitted yet.
The former issue can be solved by using a ID3D11Asynchronous per thread.
That requires some TLS storage which FFmpeg doesn't seem to support yet.
With this I get virtually no frame late.
The latter issue only occur if the wait is too long. For example waiting
by increments of 10ms is too long in my test. Using increments of 1ms or
2ms works fine in the most stressing sample I have (Sony Camping HDR
HEVC high bitrate). But this seems hackish. There's still potentially a
quick frame (alt frame in VPx/AV1 for example) that might get through to
the decoder too early. (I suppose that's the source of the distortions I
see)
It's also possible to change the order of the buffer sending, by
starting with the bigger one (D3D11_VIDEO_DECODER_BUFFER_BITSTREAM). But
it seems to have little influence, regardless if we wait for buffer
submission or not.
The results are consistent between integrated GPU and dedicated GPU.
On 2020-08-05 12:07, Steve Lhomme wrote:
When used aggressively, calling SubmitDecoderBuffers() just after
ReleaseDecoderBuffer() may have the buffers not used properly and creates
decoding artifacts.
It's likely due to the time to copy the submitted buffer in CPU mapped memory
to GPU memory. SubmitDecoderBuffers() doesn't appear to wait for the state
of the buffer submitted to become "ready".
For now it's not supported in the legacy API using AVD3D11VAContext, we need to
add a ID3D11DeviceContext in there as it cannot be derived from the other
interfaces we provide (ID3D11VideoContext is not a kind of ID3D11DeviceContext).
---
libavcodec/dxva2.c | 33 +
libavcodec/dxva2_internal.h | 2 ++
2 files changed, 35 insertions(+)
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 32416112bf..1a0e5b69b2 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -692,6 +692,12 @@ int ff_dxva2_decode_init(AVCodecContext *avctx)
d3d11_ctx->surface = sctx->d3d11_views;
d3d11_ctx->workaround= sctx->workaround;
d3d11_ctx->context_mutex = INVALID_HANDLE_VALUE;
+
+D3D11_QUERY_DESC query = { 0 };
+query.Query = D3D11_QUERY_EVENT;
+if (FAILED(ID3D11Device_CreateQuery(device_hwctx->device, ,
+
(ID3D11Query**)>wait_copies)))
+sctx->wait_copies = NULL;
}
#endif
@@ -729,6 +735,8 @@ int ff_dxva2_decode_uninit(AVCodecContext *avctx)
av_buffer_unref(>decoder_ref);
#if CONFIG_D3D11VA
+if (sctx->wait_copies)
+ID3D11Asynchronous_Release(sctx->wait_copies);
for (i = 0; i < sctx->nb_d3d11_views; i++) {
if (sctx->d3d11_views[i])
ID3D11VideoDecoderOutputView_Release(sctx->d3d11_views[i]);
@@ -932,6 +940,12 @@ int ff_dxva2_common_end_frame(AVCodecContext *avctx,
AVFrame *frame,
#if CONFIG_D3D11VA
if (ff_dxva2_is_d3d11(avctx)) {
+if (sctx->wait_copies) {
+AVHWFramesContext *frames_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
+AVD3D11VADeviceContext *device_hwctx =
frames_ctx->device_ctx->hwctx;
+ID3D11DeviceContext_Begin(device_hwctx->device_context,
sctx->wait_copies);
+}
+
buffer = [buffer_count];
type = D3D11_VIDEO_DECODER_BUFFER_PICTURE_PARAMETERS;
}
@@ -1005,9 +1019,28 @@ int ff_dxva2_common_end_frame(AVCodecContext *avctx,
AVFrame *frame,
#if CONFIG_D3D11VA
if (ff_dxva2_is_d3d11(avctx))
+{
+int maxWait = 10;
+/* wait until all the buffer release is done copying data to the GPU
+ * before doing the submit command */
+if (sctx->wait_copies) {
+AVHWFramesContext *frames_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
+AVD3D11VADeviceContext *device_hwctx =
frames_ctx->device_ctx->hwctx;
+ID3D11DeviceContext_End(device_hwctx->device_context,
sctx->wait_copies);
+
+while (maxWait-- && S_FALSE ==
+ ID3D11DeviceContext_GetData
Re: [FFmpeg-devel] [PATCH v3 2/2] dxva: add a ID3D11DeviceContext to the old D3D11VA API
v3 with support for the old API as well.
On 2020-08-05 12:07, Steve Lhomme wrote:
This way it's possible to use the wait_copy feature with the old API as well.
If it's NULL, wait_copies remains NULL and is not used.
---
doc/APIchanges | 3 +++
libavcodec/d3d11va.h | 6 ++
libavcodec/dxva2.c | 38 +++---
libavcodec/version.h | 2 +-
4 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index a9bf1afd4c..11a10ddb16 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
API changes, most recent first:
+2020-08-05 - xx - lavu 56.100.100 - d3d11va.h
+ Add a ID3D11VideoContext to AVD3D11VAContext matching the ID3D11VideoContext.
+
2020-08-04 - xx - lavu 56.58.100 - channel_layout.h
Add AV_CH_LAYOUT_22POINT2 together with its newly required pieces:
AV_CH_TOP_SIDE_LEFT, AV_CH_TOP_SIDE_RIGHT, AV_CH_BOTTOM_FRONT_CENTER,
diff --git a/libavcodec/d3d11va.h b/libavcodec/d3d11va.h
index 6816b6c1e6..134dee388c 100644
--- a/libavcodec/d3d11va.h
+++ b/libavcodec/d3d11va.h
@@ -96,6 +96,12 @@ typedef struct AVD3D11VAContext {
* Mutex to access video_context
*/
HANDLE context_mutex;
+
+/**
+ * Device Context on which to send the D3D11VA commands.
+ * It should be the same used to get the ID3D11VideoDecoder or NULL.
+ */
+ID3D11DeviceContext *device_context;
} AVD3D11VAContext;
/**
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 1a0e5b69b2..fd4685305e 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -656,7 +656,27 @@ int ff_dxva2_decode_init(AVCodecContext *avctx)
// Old API.
if (avctx->hwaccel_context)
+{
+#if CONFIG_D3D11VA
+if (avctx->hwaccel->pix_fmt == AV_PIX_FMT_D3D11VA_VLD) {
+AVDXVAContext *ctx = DXVA_CONTEXT(avctx);
+
+if (D3D11VA_CONTEXT(ctx)->device_context) {
+ID3D11Device *d3ddevice;
+
ID3D11DeviceContext_GetDevice(D3D11VA_CONTEXT(ctx)->device_context, );
+
+D3D11_QUERY_DESC query = { 0 };
+query.Query = D3D11_QUERY_EVENT;
+if (FAILED(ID3D11Device_CreateQuery(d3ddevice, ,
+
(ID3D11Query**)>wait_copies)))
+sctx->wait_copies = NULL;
+
+ID3D11Device_Release(d3ddevice);
+}
+}
+#endif
return 0;
+}
// (avctx->pix_fmt is not updated yet at this point)
sctx->pix_fmt = avctx->hwaccel->pix_fmt;
@@ -896,6 +916,7 @@ int ff_dxva2_common_end_frame(AVCodecContext *avctx,
AVFrame *frame,
unsigned buffer_count = 0;
#if CONFIG_D3D11VA
D3D11_VIDEO_DECODER_BUFFER_DESC buffer11[4];
+ID3D11DeviceContext *device_context;
#endif
#if CONFIG_DXVA2
DXVA2_DecodeBufferDesc buffer2[4];
@@ -941,9 +962,14 @@ int ff_dxva2_common_end_frame(AVCodecContext *avctx,
AVFrame *frame,
#if CONFIG_D3D11VA
if (ff_dxva2_is_d3d11(avctx)) {
if (sctx->wait_copies) {
-AVHWFramesContext *frames_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
-AVD3D11VADeviceContext *device_hwctx =
frames_ctx->device_ctx->hwctx;
-ID3D11DeviceContext_Begin(device_hwctx->device_context,
sctx->wait_copies);
+if (avctx->hwaccel_context)
+device_context = D3D11VA_CONTEXT(ctx)->device_context;
+else {
+AVHWFramesContext *frames_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
+AVD3D11VADeviceContext *device_hwctx =
frames_ctx->device_ctx->hwctx;
+device_context = device_hwctx->device_context;
+}
+ID3D11DeviceContext_Begin(device_context, sctx->wait_copies);
}
buffer = [buffer_count];
@@ -1024,12 +1050,10 @@ int ff_dxva2_common_end_frame(AVCodecContext *avctx,
AVFrame *frame,
/* wait until all the buffer release is done copying data to the GPU
* before doing the submit command */
if (sctx->wait_copies) {
-AVHWFramesContext *frames_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
-AVD3D11VADeviceContext *device_hwctx =
frames_ctx->device_ctx->hwctx;
-ID3D11DeviceContext_End(device_hwctx->device_context,
sctx->wait_copies);
+ID3D11DeviceContext_End(device_context, sctx->wait_copies);
while (maxWait-- && S_FALSE ==
- ID3D11DeviceContext_GetData(device_hwctx->device_context,
+ ID3D11DeviceContext_GetData(device_context,
sctx->wait_copies, NULL, 0,
0)) {
ff_dxva2_unlock(avctx);
SleepEx(2,
[FFmpeg-devel] [PATCH v3 2/2] dxva: add a ID3D11DeviceContext to the old D3D11VA API
This way it's possible to use the wait_copy feature with the old API as well.
If it's NULL, wait_copies remains NULL and is not used.
---
doc/APIchanges | 3 +++
libavcodec/d3d11va.h | 6 ++
libavcodec/dxva2.c | 38 +++---
libavcodec/version.h | 2 +-
4 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index a9bf1afd4c..11a10ddb16 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
API changes, most recent first:
+2020-08-05 - xx - lavu 56.100.100 - d3d11va.h
+ Add a ID3D11VideoContext to AVD3D11VAContext matching the ID3D11VideoContext.
+
2020-08-04 - xx - lavu 56.58.100 - channel_layout.h
Add AV_CH_LAYOUT_22POINT2 together with its newly required pieces:
AV_CH_TOP_SIDE_LEFT, AV_CH_TOP_SIDE_RIGHT, AV_CH_BOTTOM_FRONT_CENTER,
diff --git a/libavcodec/d3d11va.h b/libavcodec/d3d11va.h
index 6816b6c1e6..134dee388c 100644
--- a/libavcodec/d3d11va.h
+++ b/libavcodec/d3d11va.h
@@ -96,6 +96,12 @@ typedef struct AVD3D11VAContext {
* Mutex to access video_context
*/
HANDLE context_mutex;
+
+/**
+ * Device Context on which to send the D3D11VA commands.
+ * It should be the same used to get the ID3D11VideoDecoder or NULL.
+ */
+ID3D11DeviceContext *device_context;
} AVD3D11VAContext;
/**
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 1a0e5b69b2..fd4685305e 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -656,7 +656,27 @@ int ff_dxva2_decode_init(AVCodecContext *avctx)
// Old API.
if (avctx->hwaccel_context)
+{
+#if CONFIG_D3D11VA
+if (avctx->hwaccel->pix_fmt == AV_PIX_FMT_D3D11VA_VLD) {
+AVDXVAContext *ctx = DXVA_CONTEXT(avctx);
+
+if (D3D11VA_CONTEXT(ctx)->device_context) {
+ID3D11Device *d3ddevice;
+
ID3D11DeviceContext_GetDevice(D3D11VA_CONTEXT(ctx)->device_context, );
+
+D3D11_QUERY_DESC query = { 0 };
+query.Query = D3D11_QUERY_EVENT;
+if (FAILED(ID3D11Device_CreateQuery(d3ddevice, ,
+
(ID3D11Query**)>wait_copies)))
+sctx->wait_copies = NULL;
+
+ID3D11Device_Release(d3ddevice);
+}
+}
+#endif
return 0;
+}
// (avctx->pix_fmt is not updated yet at this point)
sctx->pix_fmt = avctx->hwaccel->pix_fmt;
@@ -896,6 +916,7 @@ int ff_dxva2_common_end_frame(AVCodecContext *avctx,
AVFrame *frame,
unsigned buffer_count = 0;
#if CONFIG_D3D11VA
D3D11_VIDEO_DECODER_BUFFER_DESC buffer11[4];
+ID3D11DeviceContext *device_context;
#endif
#if CONFIG_DXVA2
DXVA2_DecodeBufferDesc buffer2[4];
@@ -941,9 +962,14 @@ int ff_dxva2_common_end_frame(AVCodecContext *avctx,
AVFrame *frame,
#if CONFIG_D3D11VA
if (ff_dxva2_is_d3d11(avctx)) {
if (sctx->wait_copies) {
-AVHWFramesContext *frames_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
-AVD3D11VADeviceContext *device_hwctx =
frames_ctx->device_ctx->hwctx;
-ID3D11DeviceContext_Begin(device_hwctx->device_context,
sctx->wait_copies);
+if (avctx->hwaccel_context)
+device_context = D3D11VA_CONTEXT(ctx)->device_context;
+else {
+AVHWFramesContext *frames_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
+AVD3D11VADeviceContext *device_hwctx =
frames_ctx->device_ctx->hwctx;
+device_context = device_hwctx->device_context;
+}
+ID3D11DeviceContext_Begin(device_context, sctx->wait_copies);
}
buffer = [buffer_count];
@@ -1024,12 +1050,10 @@ int ff_dxva2_common_end_frame(AVCodecContext *avctx,
AVFrame *frame,
/* wait until all the buffer release is done copying data to the GPU
* before doing the submit command */
if (sctx->wait_copies) {
-AVHWFramesContext *frames_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
-AVD3D11VADeviceContext *device_hwctx =
frames_ctx->device_ctx->hwctx;
-ID3D11DeviceContext_End(device_hwctx->device_context,
sctx->wait_copies);
+ID3D11DeviceContext_End(device_context, sctx->wait_copies);
while (maxWait-- && S_FALSE ==
- ID3D11DeviceContext_GetData(device_hwctx->device_context,
+ ID3D11DeviceContext_GetData(device_context,
sctx->wait_copies, NULL, 0, 0))
{
ff_dxva2_unlock(avctx);
SleepEx(2, TRUE);
diff --git a/libavcodec/version.h b/libavcodec/version.h
index f66919617a..a3f9f828ee 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,7 +28,7 @@
#include "libavutil/version.h"
#define LIBAVCODEC_VERSION_MAJOR 58
-#define
[FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer copies are done before submitting them
When used aggressively, calling SubmitDecoderBuffers() just after
ReleaseDecoderBuffer() may have the buffers not used properly and creates
decoding artifacts.
It's likely due to the time to copy the submitted buffer in CPU mapped memory
to GPU memory. SubmitDecoderBuffers() doesn't appear to wait for the state
of the buffer submitted to become "ready".
For now it's not supported in the legacy API using AVD3D11VAContext, we need to
add a ID3D11DeviceContext in there as it cannot be derived from the other
interfaces we provide (ID3D11VideoContext is not a kind of ID3D11DeviceContext).
---
libavcodec/dxva2.c | 33 +
libavcodec/dxva2_internal.h | 2 ++
2 files changed, 35 insertions(+)
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 32416112bf..1a0e5b69b2 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -692,6 +692,12 @@ int ff_dxva2_decode_init(AVCodecContext *avctx)
d3d11_ctx->surface = sctx->d3d11_views;
d3d11_ctx->workaround= sctx->workaround;
d3d11_ctx->context_mutex = INVALID_HANDLE_VALUE;
+
+D3D11_QUERY_DESC query = { 0 };
+query.Query = D3D11_QUERY_EVENT;
+if (FAILED(ID3D11Device_CreateQuery(device_hwctx->device, ,
+
(ID3D11Query**)>wait_copies)))
+sctx->wait_copies = NULL;
}
#endif
@@ -729,6 +735,8 @@ int ff_dxva2_decode_uninit(AVCodecContext *avctx)
av_buffer_unref(>decoder_ref);
#if CONFIG_D3D11VA
+if (sctx->wait_copies)
+ID3D11Asynchronous_Release(sctx->wait_copies);
for (i = 0; i < sctx->nb_d3d11_views; i++) {
if (sctx->d3d11_views[i])
ID3D11VideoDecoderOutputView_Release(sctx->d3d11_views[i]);
@@ -932,6 +940,12 @@ int ff_dxva2_common_end_frame(AVCodecContext *avctx,
AVFrame *frame,
#if CONFIG_D3D11VA
if (ff_dxva2_is_d3d11(avctx)) {
+if (sctx->wait_copies) {
+AVHWFramesContext *frames_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
+AVD3D11VADeviceContext *device_hwctx =
frames_ctx->device_ctx->hwctx;
+ID3D11DeviceContext_Begin(device_hwctx->device_context,
sctx->wait_copies);
+}
+
buffer = [buffer_count];
type = D3D11_VIDEO_DECODER_BUFFER_PICTURE_PARAMETERS;
}
@@ -1005,9 +1019,28 @@ int ff_dxva2_common_end_frame(AVCodecContext *avctx,
AVFrame *frame,
#if CONFIG_D3D11VA
if (ff_dxva2_is_d3d11(avctx))
+{
+int maxWait = 10;
+/* wait until all the buffer release is done copying data to the GPU
+ * before doing the submit command */
+if (sctx->wait_copies) {
+AVHWFramesContext *frames_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
+AVD3D11VADeviceContext *device_hwctx =
frames_ctx->device_ctx->hwctx;
+ID3D11DeviceContext_End(device_hwctx->device_context,
sctx->wait_copies);
+
+while (maxWait-- && S_FALSE ==
+ ID3D11DeviceContext_GetData(device_hwctx->device_context,
+ sctx->wait_copies, NULL, 0, 0))
{
+ff_dxva2_unlock(avctx);
+SleepEx(2, TRUE);
+ff_dxva2_lock(avctx);
+}
+}
+
hr =
ID3D11VideoContext_SubmitDecoderBuffers(D3D11VA_CONTEXT(ctx)->video_context,
D3D11VA_CONTEXT(ctx)->decoder,
buffer_count, buffer11);
+}
#endif
#if CONFIG_DXVA2
if (avctx->pix_fmt == AV_PIX_FMT_DXVA2_VLD) {
diff --git a/libavcodec/dxva2_internal.h b/libavcodec/dxva2_internal.h
index b822af59cd..c44e8e09b0 100644
--- a/libavcodec/dxva2_internal.h
+++ b/libavcodec/dxva2_internal.h
@@ -81,6 +81,8 @@ typedef struct FFDXVASharedContext {
ID3D11VideoDecoderOutputView **d3d11_views;
int nb_d3d11_views;
ID3D11Texture2D*d3d11_texture;
+
+ID3D11Asynchronous *wait_copies;
#endif
#if CONFIG_DXVA2
--
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 v2] dxva: wait until D3D11 buffer copies are done before submitting them
On 2020-08-05 9:55, Marton Balint wrote:
On Wed, 5 Aug 2020, Steve Lhomme wrote:
When used aggressively, calling SubmitDecoderBuffers() just after
ReleaseDecoderBuffer() may have the buffers not used properly and created
decoding artifacts.
It's likely due to the time to copy the submitted buffer in CPU mapped
memory
to GPU memory. SubmitDecoderBuffers() doesn't appear to wait for the
state
of the buffer submitted to become "ready".
Is this an API bug or the code is not using the API properly? Please
clarify this in the commit message if you can.
I do not know. The documentation on SubmitDecoderBuffers or
ReleaseDecoderBuffer doesn't say anything about that. Maybe the driver
documentation that manufacturers use have more information, but I don't
have it.
For now it's not supported in the legacy API using AVD3D11VAContext,
we need to
add a ID3D11DeviceContext in there as it cannot be derived from the other
interfaces we provide (ID3D11VideoContext is not a kind of
ID3D11DeviceContext).
---
libavcodec/dxva2.c | 33 +
libavcodec/dxva2_internal.h | 2 ++
2 files changed, 35 insertions(+)
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 32416112bf..1a0e5b69b2 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -692,6 +692,12 @@ int ff_dxva2_decode_init(AVCodecContext *avctx)
d3d11_ctx->surface = sctx->d3d11_views;
d3d11_ctx->workaround = sctx->workaround;
d3d11_ctx->context_mutex = INVALID_HANDLE_VALUE;
+
+ D3D11_QUERY_DESC query = { 0 };
+ query.Query = D3D11_QUERY_EVENT;
+ if (FAILED(ID3D11Device_CreateQuery(device_hwctx->device,
,
+
(ID3D11Query**)>wait_copies)))
+ sctx->wait_copies = NULL;
}
#endif
@@ -729,6 +735,8 @@ int ff_dxva2_decode_uninit(AVCodecContext *avctx)
av_buffer_unref(>decoder_ref);
#if CONFIG_D3D11VA
+ if (sctx->wait_copies)
+ ID3D11Asynchronous_Release(sctx->wait_copies);
for (i = 0; i < sctx->nb_d3d11_views; i++) {
if (sctx->d3d11_views[i])
ID3D11VideoDecoderOutputView_Release(sctx->d3d11_views[i]);
@@ -932,6 +940,12 @@ int ff_dxva2_common_end_frame(AVCodecContext
*avctx, AVFrame *frame,
#if CONFIG_D3D11VA
if (ff_dxva2_is_d3d11(avctx)) {
+ if (sctx->wait_copies) {
+ AVHWFramesContext *frames_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
+ AVD3D11VADeviceContext *device_hwctx =
frames_ctx->device_ctx->hwctx;
+ ID3D11DeviceContext_Begin(device_hwctx->device_context,
sctx->wait_copies);
+ }
+
buffer = [buffer_count];
type = D3D11_VIDEO_DECODER_BUFFER_PICTURE_PARAMETERS;
}
@@ -1005,9 +1019,28 @@ int ff_dxva2_common_end_frame(AVCodecContext
*avctx, AVFrame *frame,
#if CONFIG_D3D11VA
if (ff_dxva2_is_d3d11(avctx))
+ {
coding style, same line opening brackets
+ int maxWait = 10;
You can push this initialization (and maybe the comment below) one block
down as far as I see.
+ /* wait until all the buffer release is done copying data to
the GPU
+ * before doing the submit command */
+ if (sctx->wait_copies) {
+ AVHWFramesContext *frames_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
+ AVD3D11VADeviceContext *device_hwctx =
frames_ctx->device_ctx->hwctx;
+ ID3D11DeviceContext_End(device_hwctx->device_context,
sctx->wait_copies);
+
+ while (maxWait-- && S_FALSE ==
+
ID3D11DeviceContext_GetData(device_hwctx->device_context,
+ sctx->wait_copies,
NULL, 0, 0)) {
+ ff_dxva2_unlock(avctx);
+ SleepEx(2, TRUE);
+ ff_dxva2_lock(avctx);
+ }
+ }
+
hr =
ID3D11VideoContext_SubmitDecoderBuffers(D3D11VA_CONTEXT(ctx)->video_context,
D3D11VA_CONTEXT(ctx)->decoder,
buffer_count,
buffer11);
+ }
#endif
#if CONFIG_DXVA2
if (avctx->pix_fmt == AV_PIX_FMT_DXVA2_VLD) {
diff --git a/libavcodec/dxva2_internal.h b/libavcodec/dxva2_internal.h
index b822af59cd..c44e8e09b0 100644
--- a/libavcodec/dxva2_internal.h
+++ b/libavcodec/dxva2_internal.h
@@ -81,6 +81,8 @@ typedef struct FFDXVASharedContext {
ID3D11VideoDecoderOutputView **d3d11_views;
int nb_d3d11_views;
ID3D11Texture2D *d3d11_texture;
+
+ ID3D11Asynchronous *wait_copies;
#endif
Regards,
Marton
___
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
[FFmpeg-devel] [PATCH v2] dxva: wait until D3D11 buffer copies are done before submitting them
When used aggressively, calling SubmitDecoderBuffers() just after
ReleaseDecoderBuffer() may have the buffers not used properly and created
decoding artifacts.
It's likely due to the time to copy the submitted buffer in CPU mapped memory
to GPU memory. SubmitDecoderBuffers() doesn't appear to wait for the state
of the buffer submitted to become "ready".
For now it's not supported in the legacy API using AVD3D11VAContext, we need to
add a ID3D11DeviceContext in there as it cannot be derived from the other
interfaces we provide (ID3D11VideoContext is not a kind of ID3D11DeviceContext).
---
libavcodec/dxva2.c | 33 +
libavcodec/dxva2_internal.h | 2 ++
2 files changed, 35 insertions(+)
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 32416112bf..1a0e5b69b2 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -692,6 +692,12 @@ int ff_dxva2_decode_init(AVCodecContext *avctx)
d3d11_ctx->surface = sctx->d3d11_views;
d3d11_ctx->workaround= sctx->workaround;
d3d11_ctx->context_mutex = INVALID_HANDLE_VALUE;
+
+D3D11_QUERY_DESC query = { 0 };
+query.Query = D3D11_QUERY_EVENT;
+if (FAILED(ID3D11Device_CreateQuery(device_hwctx->device, ,
+
(ID3D11Query**)>wait_copies)))
+sctx->wait_copies = NULL;
}
#endif
@@ -729,6 +735,8 @@ int ff_dxva2_decode_uninit(AVCodecContext *avctx)
av_buffer_unref(>decoder_ref);
#if CONFIG_D3D11VA
+if (sctx->wait_copies)
+ID3D11Asynchronous_Release(sctx->wait_copies);
for (i = 0; i < sctx->nb_d3d11_views; i++) {
if (sctx->d3d11_views[i])
ID3D11VideoDecoderOutputView_Release(sctx->d3d11_views[i]);
@@ -932,6 +940,12 @@ int ff_dxva2_common_end_frame(AVCodecContext *avctx,
AVFrame *frame,
#if CONFIG_D3D11VA
if (ff_dxva2_is_d3d11(avctx)) {
+if (sctx->wait_copies) {
+AVHWFramesContext *frames_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
+AVD3D11VADeviceContext *device_hwctx =
frames_ctx->device_ctx->hwctx;
+ID3D11DeviceContext_Begin(device_hwctx->device_context,
sctx->wait_copies);
+}
+
buffer = [buffer_count];
type = D3D11_VIDEO_DECODER_BUFFER_PICTURE_PARAMETERS;
}
@@ -1005,9 +1019,28 @@ int ff_dxva2_common_end_frame(AVCodecContext *avctx,
AVFrame *frame,
#if CONFIG_D3D11VA
if (ff_dxva2_is_d3d11(avctx))
+{
+int maxWait = 10;
+/* wait until all the buffer release is done copying data to the GPU
+ * before doing the submit command */
+if (sctx->wait_copies) {
+AVHWFramesContext *frames_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
+AVD3D11VADeviceContext *device_hwctx =
frames_ctx->device_ctx->hwctx;
+ID3D11DeviceContext_End(device_hwctx->device_context,
sctx->wait_copies);
+
+while (maxWait-- && S_FALSE ==
+ ID3D11DeviceContext_GetData(device_hwctx->device_context,
+ sctx->wait_copies, NULL, 0, 0))
{
+ff_dxva2_unlock(avctx);
+SleepEx(2, TRUE);
+ff_dxva2_lock(avctx);
+}
+}
+
hr =
ID3D11VideoContext_SubmitDecoderBuffers(D3D11VA_CONTEXT(ctx)->video_context,
D3D11VA_CONTEXT(ctx)->decoder,
buffer_count, buffer11);
+}
#endif
#if CONFIG_DXVA2
if (avctx->pix_fmt == AV_PIX_FMT_DXVA2_VLD) {
diff --git a/libavcodec/dxva2_internal.h b/libavcodec/dxva2_internal.h
index b822af59cd..c44e8e09b0 100644
--- a/libavcodec/dxva2_internal.h
+++ b/libavcodec/dxva2_internal.h
@@ -81,6 +81,8 @@ typedef struct FFDXVASharedContext {
ID3D11VideoDecoderOutputView **d3d11_views;
int nb_d3d11_views;
ID3D11Texture2D*d3d11_texture;
+
+ID3D11Asynchronous *wait_copies;
#endif
#if CONFIG_DXVA2
--
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] dxva: wait until D3D11 buffer copies are done before submitting them
On 2020-08-05 9:07, Steve Lhomme wrote:
When used aggressively, calling SubmitDecoderBuffers() just after
ReleaseDecoderBuffer() may have the buffers not used properly and created
*creates
decoding artifacts.
It's likely due to the time to copy the submitted buffer in CPU mapped memory
to GPU memory. SubmitDecoderBuffers() doesn't appear to wait for the state
of the buffer submitted to become "ready".
I noticed this behaviour on a 48 threads machine. In VLC we use a lot of
threads for lavc, even with D3D11. And the more threads I added, the
more artifacts I got. Adding this code solved the issue. The decoder is
now guaranteed to have all the buffers in the GPU when submitting them
for decoding.
For now it's not supported in the legacy API using AVD3D11VAContext, we need to
add a ID3D11DeviceContext in there as it cannot be derived from the other
interfaces we provide (ID3D11VideoContext is not a kind of ID3D11DeviceContext).
---
libavcodec/dxva2.c | 32
libavcodec/dxva2_internal.h | 2 ++
2 files changed, 34 insertions(+)
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 32416112bf..dbbad8ed00 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -692,6 +692,12 @@ int ff_dxva2_decode_init(AVCodecContext *avctx)
d3d11_ctx->surface = sctx->d3d11_views;
d3d11_ctx->workaround= sctx->workaround;
d3d11_ctx->context_mutex = INVALID_HANDLE_VALUE;
+
+D3D11_QUERY_DESC query = { 0 };
+query.Query = D3D11_QUERY_EVENT;
+if (FAILED(ID3D11Device_CreateQuery(device_hwctx->device, ,
+
(ID3D11Query**)>wait_copies)))
+sctx->wait_copies = NULL;
}
#endif
@@ -729,6 +735,8 @@ int ff_dxva2_decode_uninit(AVCodecContext *avctx)
av_buffer_unref(>decoder_ref);
#if CONFIG_D3D11VA
+if (sctx->wait_copies)
+ID3D11Asynchronous_Release(sctx->wait_copies);
for (i = 0; i < sctx->nb_d3d11_views; i++) {
if (sctx->d3d11_views[i])
ID3D11VideoDecoderOutputView_Release(sctx->d3d11_views[i]);
@@ -932,6 +940,13 @@ int ff_dxva2_common_end_frame(AVCodecContext *avctx,
AVFrame *frame,
#if CONFIG_D3D11VA
if (ff_dxva2_is_d3d11(avctx)) {
+if (sctx->wait_copies)
+{
+AVHWFramesContext *frames_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
+AVD3D11VADeviceContext *device_hwctx =
frames_ctx->device_ctx->hwctx;
+ID3D11DeviceContext_Begin(device_hwctx->device_context,
sctx->wait_copies);
+}
+
buffer = [buffer_count];
type = D3D11_VIDEO_DECODER_BUFFER_PICTURE_PARAMETERS;
}
@@ -1005,9 +1020,26 @@ int ff_dxva2_common_end_frame(AVCodecContext *avctx,
AVFrame *frame,
#if CONFIG_D3D11VA
if (ff_dxva2_is_d3d11(avctx))
+{
+int maxWait = 10;
+/* wait until all the buffer release is done copying data to the GPU
+ * before doing the submit command */
+if (sctx->wait_copies)
+{
+AVHWFramesContext *frames_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
+AVD3D11VADeviceContext *device_hwctx =
frames_ctx->device_ctx->hwctx;
+ID3D11DeviceContext_End(device_hwctx->device_context,
sctx->wait_copies);
+
+while (maxWait-- && S_FALSE ==
+ ID3D11DeviceContext_GetData(device_hwctx->device_context,
+ sctx->wait_copies, NULL, 0, 0))
+SleepEx(2, TRUE);
And just as I submit this I realize it should be unlocking the device
context while waiting.
+}
+
hr =
ID3D11VideoContext_SubmitDecoderBuffers(D3D11VA_CONTEXT(ctx)->video_context,
D3D11VA_CONTEXT(ctx)->decoder,
buffer_count, buffer11);
+}
#endif
#if CONFIG_DXVA2
if (avctx->pix_fmt == AV_PIX_FMT_DXVA2_VLD) {
diff --git a/libavcodec/dxva2_internal.h b/libavcodec/dxva2_internal.h
index b822af59cd..c44e8e09b0 100644
--- a/libavcodec/dxva2_internal.h
+++ b/libavcodec/dxva2_internal.h
@@ -81,6 +81,8 @@ typedef struct FFDXVASharedContext {
ID3D11VideoDecoderOutputView **d3d11_views;
int nb_d3d11_views;
ID3D11Texture2D*d3d11_texture;
+
+ID3D11Asynchronous *wait_copies;
#endif
#if CONFIG_DXVA2
--
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".
___
ffmpeg-devel mailing list
ffmp
[FFmpeg-devel] [PATCH] dxva: wait until D3D11 buffer copies are done before submitting them
When used aggressively, calling SubmitDecoderBuffers() just after
ReleaseDecoderBuffer() may have the buffers not used properly and created
decoding artifacts.
It's likely due to the time to copy the submitted buffer in CPU mapped memory
to GPU memory. SubmitDecoderBuffers() doesn't appear to wait for the state
of the buffer submitted to become "ready".
For now it's not supported in the legacy API using AVD3D11VAContext, we need to
add a ID3D11DeviceContext in there as it cannot be derived from the other
interfaces we provide (ID3D11VideoContext is not a kind of ID3D11DeviceContext).
---
libavcodec/dxva2.c | 32
libavcodec/dxva2_internal.h | 2 ++
2 files changed, 34 insertions(+)
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 32416112bf..dbbad8ed00 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -692,6 +692,12 @@ int ff_dxva2_decode_init(AVCodecContext *avctx)
d3d11_ctx->surface = sctx->d3d11_views;
d3d11_ctx->workaround= sctx->workaround;
d3d11_ctx->context_mutex = INVALID_HANDLE_VALUE;
+
+D3D11_QUERY_DESC query = { 0 };
+query.Query = D3D11_QUERY_EVENT;
+if (FAILED(ID3D11Device_CreateQuery(device_hwctx->device, ,
+
(ID3D11Query**)>wait_copies)))
+sctx->wait_copies = NULL;
}
#endif
@@ -729,6 +735,8 @@ int ff_dxva2_decode_uninit(AVCodecContext *avctx)
av_buffer_unref(>decoder_ref);
#if CONFIG_D3D11VA
+if (sctx->wait_copies)
+ID3D11Asynchronous_Release(sctx->wait_copies);
for (i = 0; i < sctx->nb_d3d11_views; i++) {
if (sctx->d3d11_views[i])
ID3D11VideoDecoderOutputView_Release(sctx->d3d11_views[i]);
@@ -932,6 +940,13 @@ int ff_dxva2_common_end_frame(AVCodecContext *avctx,
AVFrame *frame,
#if CONFIG_D3D11VA
if (ff_dxva2_is_d3d11(avctx)) {
+if (sctx->wait_copies)
+{
+AVHWFramesContext *frames_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
+AVD3D11VADeviceContext *device_hwctx =
frames_ctx->device_ctx->hwctx;
+ID3D11DeviceContext_Begin(device_hwctx->device_context,
sctx->wait_copies);
+}
+
buffer = [buffer_count];
type = D3D11_VIDEO_DECODER_BUFFER_PICTURE_PARAMETERS;
}
@@ -1005,9 +1020,26 @@ int ff_dxva2_common_end_frame(AVCodecContext *avctx,
AVFrame *frame,
#if CONFIG_D3D11VA
if (ff_dxva2_is_d3d11(avctx))
+{
+int maxWait = 10;
+/* wait until all the buffer release is done copying data to the GPU
+ * before doing the submit command */
+if (sctx->wait_copies)
+{
+AVHWFramesContext *frames_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
+AVD3D11VADeviceContext *device_hwctx =
frames_ctx->device_ctx->hwctx;
+ID3D11DeviceContext_End(device_hwctx->device_context,
sctx->wait_copies);
+
+while (maxWait-- && S_FALSE ==
+ ID3D11DeviceContext_GetData(device_hwctx->device_context,
+ sctx->wait_copies, NULL, 0, 0))
+SleepEx(2, TRUE);
+}
+
hr =
ID3D11VideoContext_SubmitDecoderBuffers(D3D11VA_CONTEXT(ctx)->video_context,
D3D11VA_CONTEXT(ctx)->decoder,
buffer_count, buffer11);
+}
#endif
#if CONFIG_DXVA2
if (avctx->pix_fmt == AV_PIX_FMT_DXVA2_VLD) {
diff --git a/libavcodec/dxva2_internal.h b/libavcodec/dxva2_internal.h
index b822af59cd..c44e8e09b0 100644
--- a/libavcodec/dxva2_internal.h
+++ b/libavcodec/dxva2_internal.h
@@ -81,6 +81,8 @@ typedef struct FFDXVASharedContext {
ID3D11VideoDecoderOutputView **d3d11_views;
int nb_d3d11_views;
ID3D11Texture2D*d3d11_texture;
+
+ID3D11Asynchronous *wait_copies;
#endif
#if CONFIG_DXVA2
--
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 v2 3/4] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair
Mostly the same remarks as for 2/4 regarding the uneeded loop and
uninitialized handle_type, plus comments below.
On 2020-04-15 15:07, artem.ga...@gmail.com wrote:
From: Artem Galin
Adding DX11 relevant device type checks and adjusting callbacks with
proper MediaSDK pair type support.
Extending structure for proper MediaSDK pair type support.
Signed-off-by: Artem Galin
---
libavcodec/qsv.c | 52 ---
libavcodec/qsv_internal.h | 1 +
2 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index db98c75073..ceef1b7fd9 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -36,6 +36,8 @@
#include "avcodec.h"
#include "qsv_internal.h"
+#define MFX_IMPL_VIA_MASK(impl) (0x0f00 & (impl))
+
#if QSV_VERSION_ATLEAST(1, 12)
#include "mfx/mfxvp8.h"
#endif
@@ -221,8 +223,15 @@ int ff_qsv_find_surface_idx(QSVFramesContext *ctx,
QSVFrame *frame)
int i;
for (i = 0; i < ctx->nb_mids; i++) {
QSVMid *mid = >mids[i];
+#if CONFIG_VAAPI
if (mid->handle == frame->surface.Data.MemId)
return i;
+#else
+mfxHDLPair *pair = (mfxHDLPair*)frame->surface.Data.MemId;
+if ((mid->handle_pair.first == pair->first) &&
+(mid->handle_pair.second == pair->second))
+return i;
+#endif
}
return AVERROR_BUG;
}
@@ -362,7 +371,11 @@ static int ff_qsv_set_display_handle(AVCodecContext
*avctx, QSVSession *qs)
int ff_qsv_init_internal_session(AVCodecContext *avctx, QSVSession *qs,
const char *load_plugins, int gpu_copy)
{
+#ifdef AVCODEC_QSV_LINUX_SESSION_HANDLE
mfxIMPL impl = MFX_IMPL_AUTO_ANY;
+#else
+mfxIMPL impl = MFX_IMPL_AUTO_ANY | MFX_IMPL_VIA_D3D11;
Why is this needed ? If D3D11 is available it should pick it, no ? Does
it mean you can favor D3D11 over D3D9 ?
+#endif
mfxVersionver = { { QSV_VERSION_MINOR, QSV_VERSION_MAJOR } };
mfxInitParam init_par = { MFX_IMPL_AUTO_ANY };
@@ -449,11 +462,19 @@ static AVBufferRef *qsv_create_mids(AVBufferRef *hw_frames_ref)
return NULL;
}
+#if CONFIG_VAAPI
for (i = 0; i < nb_surfaces; i++) {
QSVMid *mid = [i];
mid->handle= frames_hwctx->surfaces[i].Data.MemId;
mid->hw_frames_ref = hw_frames_ref1;
}
+#else
+for (i = 0; i < nb_surfaces; i++) {
+QSVMid *mid = [i];
+mid->handle_pair =
*((mfxHDLPair*)frames_hwctx->surfaces[i].Data.MemId);
+mid->hw_frames_ref = hw_frames_ref1;
+}
+#endif
return mids_buf;
}
@@ -628,7 +649,11 @@ static mfxStatus qsv_frame_lock(mfxHDL pthis, mfxMemId
mid, mfxFrameData *ptr)
goto fail;
qsv_mid->surf.Info = hw_frames_hwctx->surfaces[0].Info;
+#if CONFIG_VAAPI
qsv_mid->surf.Data.MemId = qsv_mid->handle;
+#else
+qsv_mid->surf.Data.MemId = _mid->handle_pair;
+#endif
/* map the data to the system memory */
ret = av_hwframe_map(qsv_mid->locked_frame, qsv_mid->hw_frame,
@@ -661,7 +686,17 @@ static mfxStatus qsv_frame_unlock(mfxHDL pthis, mfxMemId
mid, mfxFrameData *ptr)
static mfxStatus qsv_frame_get_hdl(mfxHDL pthis, mfxMemId mid, mfxHDL *hdl)
{
QSVMid *qsv_mid = (QSVMid*)mid;
+#if CONFIG_VAAPI
*hdl = qsv_mid->handle;
+#else
+mfxHDLPair *pair_dst = (mfxHDLPair*)hdl;
+mfxHDLPair *pair_src = (mfxHDLPair*)_mid->handle_pair;
+
+pair_dst->first = pair_src->first;
+
+if (pair_src->second != (mfxMemId)MFX_INFINITE)
+pair_dst->second = pair_src->second;
+#endif
return MFX_ERR_NONE;
}
@@ -695,11 +730,20 @@ int ff_qsv_init_session_device(AVCodecContext *avctx, mfxSession *psession,
return ff_qsv_print_error(avctx, err,
"Error querying the session attributes");
+if (MFX_IMPL_VIA_D3D11 == MFX_IMPL_VIA_MASK(impl)) {
+handle_type = MFX_HANDLE_D3D11_DEVICE;
+} else if (MFX_IMPL_VIA_D3D9 == MFX_IMPL_VIA_MASK(impl)) {
+handle_type = MFX_HANDLE_D3D9_DEVICE_MANAGER;
+} else if (MFX_IMPL_VIA_VAAPI == MFX_IMPL_VIA_MASK(impl)) {
+handle_type = MFX_HANDLE_VA_DISPLAY;
+}
+
for (i = 0; i < FF_ARRAY_ELEMS(handle_types); i++) {
-err = MFXVideoCORE_GetHandle(parent_session, handle_types[i], );
-if (err == MFX_ERR_NONE) {
-handle_type = handle_types[i];
-break;
+if (handle_types[i] == handle_type) {
+err = MFXVideoCORE_GetHandle(parent_session, handle_types[i],
);
+if (err == MFX_ERR_NONE) {
+break;
+}
}
handle = NULL;
}
diff --git a/libavcodec/qsv_internal.h b/libavcodec/qsv_internal.h
index 6489836a67..7a4a66e9d6 100644
--- a/libavcodec/qsv_internal.h
+++ b/libavcodec/qsv_internal.h
@@ -61,6 +61,7 @@
typedef struct QSVMid {
AVBufferRef *hw_frames_ref;
mfxHDL
Re: [FFmpeg-devel] [PATCH v2 2/4] libavfilter/qsvvpp: enabling d3d11va support
Comments below.
On 2020-04-15 15:07, artem.ga...@gmail.com wrote:
From: Artem Galin
Adding DX11 relevant device type checks and adjusting callback with
proper MediaSDK pair type support.
Signed-off-by: Artem Galin
---
libavfilter/qsvvpp.c | 40 ++--
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
index 8d5ff2eb65..8c6c878bac 100644
--- a/libavfilter/qsvvpp.c
+++ b/libavfilter/qsvvpp.c
@@ -32,10 +32,11 @@
#include "qsvvpp.h"
#include "video.h"
-#define IS_VIDEO_MEMORY(mode) (mode & (MFX_MEMTYPE_VIDEO_MEMORY_DECODER_TARGET | \
+#define IS_VIDEO_MEMORY(mode) (mode &
(MFX_MEMTYPE_VIDEO_MEMORY_DECODER_TARGET | \
MFX_MEMTYPE_VIDEO_MEMORY_PROCESSOR_TARGET))
-#define IS_OPAQUE_MEMORY(mode) (mode & MFX_MEMTYPE_OPAQUE_FRAME)
-#define IS_SYSTEM_MEMORY(mode) (mode & MFX_MEMTYPE_SYSTEM_MEMORY)
+#define IS_OPAQUE_MEMORY(mode) (mode & MFX_MEMTYPE_OPAQUE_FRAME)
+#define IS_SYSTEM_MEMORY(mode) (mode & MFX_MEMTYPE_SYSTEM_MEMORY)
Not sure changing these lines just to add a space is worth.
+#define MFX_IMPL_VIA_MASK(impl) (0x0f00 & (impl))
typedef struct QSVFrame {
AVFrame *frame;
@@ -129,7 +130,17 @@ static mfxStatus frame_unlock(mfxHDL pthis, mfxMemId mid,
mfxFrameData *ptr)
static mfxStatus frame_get_hdl(mfxHDL pthis, mfxMemId mid, mfxHDL *hdl)
{
+#if CONFIG_VAAPI
*hdl = mid;
+#else
+mfxHDLPair *pair_dst = (mfxHDLPair*)hdl;
+mfxHDLPair *pair_src = (mfxHDLPair*)mid;
+
+pair_dst->first = pair_src->first;
+
+if (pair_src->second != (mfxMemId)MFX_INFINITE)
+pair_dst->second = pair_src->second;
+#endif
return MFX_ERR_NONE;
}
@@ -451,7 +462,7 @@ static int init_vpp_session(AVFilterContext *avctx, QSVVPPContext *s)
s->out_mem_mode = IS_OPAQUE_MEMORY(s->in_mem_mode) ?
MFX_MEMTYPE_OPAQUE_FRAME :
- MFX_MEMTYPE_VIDEO_MEMORY_DECODER_TARGET;
+ MFX_MEMTYPE_VIDEO_MEMORY_DECODER_TARGET |
MFX_MEMTYPE_FROM_VPPOUT;
What's the effect of this flag on VAAPI ?
out_frames_ctx = (AVHWFramesContext *)out_frames_ref->data;
out_frames_hwctx = out_frames_ctx->hwctx;
@@ -497,15 +508,24 @@ static int init_vpp_session(AVFilterContext *avctx,
QSVVPPContext *s)
return AVERROR_UNKNOWN;
}
+if (MFX_IMPL_VIA_D3D11 == MFX_IMPL_VIA_MASK(impl)) {
+handle_type = MFX_HANDLE_D3D11_DEVICE;
+} else if (MFX_IMPL_VIA_D3D9 == MFX_IMPL_VIA_MASK(impl)) {
+handle_type = MFX_HANDLE_D3D9_DEVICE_MANAGER;
+} else if (MFX_IMPL_VIA_VAAPI == MFX_IMPL_VIA_MASK(impl)) {
+handle_type = MFX_HANDLE_VA_DISPLAY;
+}
handle_type is potentially used initialized after that. You probably
want to return an error is the handle type is unknown.
+
for (i = 0; i < FF_ARRAY_ELEMS(handle_types); i++) {
-ret = MFXVideoCORE_GetHandle(device_hwctx->session, handle_types[i],
);
-if (ret == MFX_ERR_NONE) {
-handle_type = handle_types[i];
-break;
+if (handle_types[i] == handle_type) {
You're losing the possibility to pick whichever the system provides.
Although in real life it may not be an issue if you can only have VAAPI
or D3D9/D3D11 separately.
Also you don't need to do the for() loop since you only want to read the
handle of the type you want.
The title of the patch is misleading. MFX_HANDLE_D3D11_DEVICE was
already supported in the list of handles.
+ret = MFXVideoCORE_GetHandle(device_hwctx->session, handle_types[i],
);
+if (ret == MFX_ERR_NONE) {
+break;
+}
}
+handle = NULL;
}
-
-if (ret != MFX_ERR_NONE) {
+if (!handle) {
av_log(avctx, AV_LOG_ERROR, "Error getting the session handle\n");
return AVERROR_UNKNOWN;
}
--
2.26.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 v2 4/4] libavutil/qsv: enabling d3d11va support
On 2020-04-15 15:07, artem.ga...@gmail.com wrote:
From: Artem Galin
Makes selection of d3d11va device type by default and over DirectX 9,
which is still supported but requires explicit selection.
This enables usage of non-powered/headless GPU, better HDR support.
Pool of resources is allocated as one texture with array of slices.
I'm all for it ;)
Added d3d11va device selection by vendor id.
Example: --init_hw_device d3d11va:,vendor=0x8086
DirectX 9 usage.
Example: --init_hw_device qsv:hw,child_device_type=dxva2
Same remark as before on the possible uninitialized handle_type.
Signed-off-by: Artem Galin
---
libavutil/hwcontext_d3d11va.c | 82 +++-
libavutil/hwcontext_d3d11va.h | 8 +
libavutil/hwcontext_qsv.c | 339 +-
3 files changed, 371 insertions(+), 58 deletions(-)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index c8ae58f908..9d7615eb55 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -72,7 +72,7 @@ static av_cold void load_functions(void)
}
typedef struct D3D11VAFramesContext {
-int nb_surfaces_used;
+int nb_surfaces;
Probably better as a size_t
DXGI_FORMAT format;
@@ -112,6 +112,8 @@ static void d3d11va_frames_uninit(AVHWFramesContext *ctx)
if (s->staging_texture)
ID3D11Texture2D_Release(s->staging_texture);
s->staging_texture = NULL;
+
+av_freep(_hwctx->texture_infos);
}
static int d3d11va_frames_get_constraints(AVHWDeviceContext *ctx,
@@ -152,8 +154,9 @@ static void free_texture(void *opaque, uint8_t *data)
av_free(data);
}
-static AVBufferRef *wrap_texture_buf(ID3D11Texture2D *tex, int index)
+static AVBufferRef *wrap_texture_buf(AVHWFramesContext *ctx, ID3D11Texture2D
*tex, int index)
{
+AVD3D11VAFramesContext *frames_hwctx = ctx->hwctx;
AVBufferRef *buf;
AVD3D11FrameDescriptor *desc = av_mallocz(sizeof(*desc));
if (!desc) {
@@ -161,6 +164,10 @@ static AVBufferRef *wrap_texture_buf(ID3D11Texture2D *tex,
int index)
return NULL;
}
+frames_hwctx->texture_infos[frames_hwctx->nb_surfaces_used].texture = tex;
+frames_hwctx->texture_infos[frames_hwctx->nb_surfaces_used].index = index;
+frames_hwctx->nb_surfaces_used++;
+
desc->texture = tex;
desc->index = index;
@@ -199,13 +206,12 @@ static AVBufferRef *d3d11va_alloc_single(AVHWFramesContext *ctx)
return NULL;
}
-return wrap_texture_buf(tex, 0);
+return wrap_texture_buf(ctx, tex, 0);
}
static AVBufferRef *d3d11va_pool_alloc(void *opaque, int size)
{
AVHWFramesContext*ctx = (AVHWFramesContext*)opaque;
-D3D11VAFramesContext *s = ctx->internal->priv;
AVD3D11VAFramesContext *hwctx = ctx->hwctx;
D3D11_TEXTURE2D_DESC texDesc;
@@ -214,13 +220,13 @@ static AVBufferRef *d3d11va_pool_alloc(void *opaque, int size)
ID3D11Texture2D_GetDesc(hwctx->texture, );
-if (s->nb_surfaces_used >= texDesc.ArraySize) {
+if (hwctx->nb_surfaces_used >= texDesc.ArraySize) {
av_log(ctx, AV_LOG_ERROR, "Static surface pool size exceeded.\n");
return NULL;
}
ID3D11Texture2D_AddRef(hwctx->texture);
-return wrap_texture_buf(hwctx->texture, s->nb_surfaces_used++);
+return wrap_texture_buf(ctx, hwctx->texture, hwctx->nb_surfaces_used);
}
static int d3d11va_frames_init(AVHWFramesContext *ctx)
@@ -267,7 +273,7 @@ static int d3d11va_frames_init(AVHWFramesContext *ctx)
av_log(ctx, AV_LOG_ERROR, "User-provided texture has mismatching
parameters\n");
return AVERROR(EINVAL);
}
-} else if (texDesc.ArraySize > 0) {
+} else if (!(texDesc.BindFlags & D3D11_BIND_RENDER_TARGET) &&
texDesc.ArraySize > 0) {
hr = ID3D11Device_CreateTexture2D(device_hwctx->device, , NULL,
>texture);
if (FAILED(hr)) {
av_log(ctx, AV_LOG_ERROR, "Could not create the texture (%lx)\n",
(long)hr);
@@ -275,6 +281,12 @@ static int d3d11va_frames_init(AVHWFramesContext *ctx)
}
}
+hwctx->texture_infos = av_mallocz_array(ctx->initial_pool_size, sizeof(*hwctx->texture_infos));
+if (!hwctx->texture_infos)
+return AVERROR(ENOMEM);
+
+s->nb_surfaces = ctx->initial_pool_size;
+
ctx->internal->pool_internal =
av_buffer_pool_init2(sizeof(AVD3D11FrameDescriptor),
ctx,
d3d11va_pool_alloc, NULL);
if (!ctx->internal->pool_internal)
@@ -511,15 +523,56 @@ static void d3d11va_device_uninit(AVHWDeviceContext
*hwdev)
}
}
+static int d3d11va_device_find_adapter_by_vendor_id(AVHWDeviceContext *ctx, UINT creationFlags, char *vendor)
+{
+HRESULT hr;
+IDXGIAdapter *adapter = NULL;
+int adapter_id = 0;
+IDXGIFactory2 *factory;
+long int vendor_id = strtol(vendor, NULL, 0);
+hr =
Re: [FFmpeg-devel] [PATCH v2 1/4] fftools/qsv: enabling d3d11va/dxva2 device selection
Hi,
On 2020-04-15 15:07, artem.ga...@gmail.com wrote:
From: Artem Galin
child_device_type argument is responsible for selection.
Usage examples: -init_hw_device qsv:hw,child_device_type=d3d11va
-init_hw_device qsv:hw,child_device_type=dxva2
Signed-off-by: Artem Galin
---
fftools/ffmpeg_opt.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 95001a963f..82232c60b3 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -568,7 +568,17 @@ static int opt_init_hw_device(void *optctx, const char
*opt, const char *arg)
printf("\n");
exit_program(0);
} else {
-return hw_device_init_from_string(arg, NULL);
+HWDevice *dev;
+int err;
+if (!arg)
+return AVERROR(ENOMEM);
+err = hw_device_init_from_string(arg, );
+if (err < 0)
+return err;
+hw_device_ctx = av_buffer_ref(dev->device_ref);
+if (!hw_device_ctx)
+return AVERROR(ENOMEM);
+return 0;
This is very similar to what is done in opt_vaapi_device().
Maybe you could modify the "qsv_device" handling to support this ? It
will be ifdef'ed out when QSV is not enabled.
There might also be some side effects for other hardware devices.
Especially the hw_device_ctx reference doesn't seem to be released (but
it's the same in opt_vaapi_device so I might be missing something).
}
}
--
2.26.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] avformat/matroskaenc: Don't write elements with their default value
LGTM.
In general it would be nice if this was "automatic". In other words when
writing any element the value is automatically checked against the default
value. Maybe using a macro that would also check the default value like this
PUT_EBML_VALUE(cp, EDITIONFLAGHIDDEN, value)
doing :
if (value != MATROSKA_DEFAULT_EDITIONFLAGHIDDEN)
put_ebml_uint(cp, MATROSKA_ID_EDITIONFLAGHIDDEN, value)
even better :
#ifdef MATROSKA_DEFAULT_EDITIONFLAGHIDDEN
if (value != MATROSKA_DEFAULT_EDITIONFLAGHIDDEN)
#endif
put_ebml_uint(cp, MATROSKA_ID_EDITIONFLAGHIDDEN, value)
I could easily generate all the default values from the specs.
> On April 14, 2020 3:46 AM Andreas Rheinhardt
> wrote:
>
>
> This has happened when writing chapters: Both editions as well as
> chapters are by default not hidden and given that we don't support
> writing hidden chapters at all, we don't need to write said elements at
> all. The same goes for ChapterFlagEnabled.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> This is supposed to get applied before the cosmetics patch.
>
> libavformat/matroskaenc.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index d0a02c0f5d..d3256d8f5d 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -1400,7 +1400,6 @@ static int mkv_write_chapters(AVFormatContext *s)
> editionentry = start_ebml_master(dyn_cp, MATROSKA_ID_EDITIONENTRY, 0);
> if (mkv->mode != MODE_WEBM) {
> put_ebml_uint(dyn_cp, MATROSKA_ID_EDITIONFLAGDEFAULT, 1);
> -put_ebml_uint(dyn_cp, MATROSKA_ID_EDITIONFLAGHIDDEN , 0);
> }
> for (i = 0; i < s->nb_chapters; i++) {
> ebml_master chapteratom, chapterdisplay;
> @@ -1420,10 +1419,6 @@ static int mkv_write_chapters(AVFormatContext *s)
>(uint32_t)c->id + (uint64_t)mkv->chapter_id_offset);
> put_ebml_uint(dyn_cp, MATROSKA_ID_CHAPTERTIMESTART, chapterstart);
> put_ebml_uint(dyn_cp, MATROSKA_ID_CHAPTERTIMEEND, chapterend);
> -if (mkv->mode != MODE_WEBM) {
> -put_ebml_uint(dyn_cp, MATROSKA_ID_CHAPTERFLAGHIDDEN , 0);
> -put_ebml_uint(dyn_cp, MATROSKA_ID_CHAPTERFLAGENABLED, 1);
> -}
> if ((t = av_dict_get(c->metadata, "title", NULL, 0))) {
> chapterdisplay = start_ebml_master(dyn_cp,
> MATROSKA_ID_CHAPTERDISPLAY, 0);
> put_ebml_string(dyn_cp, MATROSKA_ID_CHAPSTRING, t->value);
> --
> 2.20.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".
___
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 04/20] avformat/matroskaenc: Reuse random seed
> On April 19, 2020 9:11 AM Andreas Rheinhardt
> wrote:
>
>
> Steve Lhomme:
> > Wouldn't it be better to set the AVLFG in the MatroskaMuxContext in
> > mkv_init and keep using it when needed ?
> >
> > Then you can still update UIDs in the location you really need to create
> > them.
> >
> What other UIDs do I need? UIDs for tracks and attachments are created
> in init as is the SegmentUID. The EditionUID is not written as we only
> support ordinary chapters for now (FFmpeg does not have nested chapters
> or multiple editions or hierarchical metadata -- I really don't know how
> this could be supported). And the ChapterUIDs are not created randomly.
That's a general rule so you don't need to adapt everytime you need a new UIDs.
And it's easier/cleaner to generate UIDs when the item they relate to is
created.
Anyway, it's not a blocker, just a general remark.
As for other UIDs they should be randomized (hence the Unique in UIDs) unless
you're remuxing or taking the values from other sources which is sometimes
needed for advanced chapter handling or referencing a part of the same mux via
a UID.
> - Andreas
>
> >> On April 5, 2020 5:59 PM Andreas Rheinhardt
> >> wrote:
> >>
> >>
> >> This commit reuses the random seed generated in mkv_init() (to determine
> >> the TrackUIDs) for the SegmentUID in order to avoid a potentially
> >> expensive call to av_get_random_seed().
> >>
> >> Signed-off-by: Andreas Rheinhardt
> >> ---
> >> libavformat/matroskaenc.c | 19 +--
> >> 1 file changed, 9 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> >> index d2046193ee..b93c50cb01 100644
> >> --- a/libavformat/matroskaenc.c
> >> +++ b/libavformat/matroskaenc.c
> >> @@ -161,6 +161,8 @@ typedef struct MatroskaMuxContext {
> >> int wrote_chapters;
> >>
> >> int allow_raw_vfw;
> >> +
> >> +uint32_t segment_uid[4];
> >> } MatroskaMuxContext;
> >>
> >> /** 2 bytes * 7 for EBML IDs, 7 1-byte EBML lengths, 6 1-byte uint,
> >> @@ -1821,15 +1823,7 @@ static int mkv_write_header(AVFormatContext *s)
> >> put_ebml_string(pb, MATROSKA_ID_WRITINGAPP,
> >> LIBAVFORMAT_IDENT);
> >>
> >> if (mkv->mode != MODE_WEBM) {
> >> -uint32_t segment_uid[4];
> >> -AVLFG lfg;
> >> -
> >> -av_lfg_init(, av_get_random_seed());
> >> -
> >> -for (i = 0; i < 4; i++)
> >> -segment_uid[i] = av_lfg_get();
> >> -
> >> -put_ebml_binary(pb, MATROSKA_ID_SEGMENTUID, segment_uid, 16);
> >> +put_ebml_binary(pb, MATROSKA_ID_SEGMENTUID, mkv->segment_uid,
> >> 16);
> >> }
> >> } else {
> >> const char *ident = "Lavf";
> >> @@ -2661,9 +2655,14 @@ static int mkv_init(struct AVFormatContext *s)
> >> return AVERROR(ENOMEM);
> >> }
> >>
> >> -if (!(s->flags & AVFMT_FLAG_BITEXACT))
> >> +if (!(s->flags & AVFMT_FLAG_BITEXACT)) {
> >> av_lfg_init(, av_get_random_seed());
> >>
> >> +// Calculate the SegmentUID now in order not to waste our random
> >> seed.
> >> +for (i = 0; i < 4; i++)
> >> +mkv->segment_uid[i] = av_lfg_get();
> >> +}
> >> +
> >> for (i = 0; i < s->nb_streams; i++) {
> >> mkv_track *track = >tracks[i];
> >>
> >> --
> >> 2.20.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".
___
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 12/20] avformat/matroskaenc: Improve Cues in case of no video
> On April 5, 2020 5:59 PM Andreas Rheinhardt
> wrote:
>
>
> The Matroska muxer currently only adds CuePoints in three cases:
> a) For video keyframes. b) For the first audio frame in a new Cluster if
> in DASH-mode. c) For subtitles. This means that ordinary Matroska audio
> files won't have any Cues which impedes seeking.
>
> This commit changes this. For every track in a file without video track
> it is checked and tracked whether a Cue entry has already been added
> for said track for the current Cluster. This is used to add a Cue entry
> for each first packet of each track in each Cluster.
>
> Implements #3149.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/matroskaenc.c | 21 +++
> tests/ref/fate/aac-autobsf-adtstoasc | 4 ++--
> tests/ref/fate/matroska-flac-extradata-update | 4 ++--
> tests/ref/lavf/mka| 4 ++--
> 4 files changed, 18 insertions(+), 15 deletions(-)
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index b9bfd34756..a469d48cc0 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -2120,6 +2120,10 @@ static void mkv_end_cluster(AVFormatContext *s)
> MatroskaMuxContext *mkv = s->priv_data;
>
> end_ebml_master_crc32(s->pb, >cluster_bc, mkv, MATROSKA_ID_CLUSTER,
> 0, 1);
> +if (!mkv->have_video) {
You could initialize it even for video. In case in the future you want a Cue
only on the first video keyframe of the Cluster.
> +for (unsigned i = 0; i < s->nb_streams; i++)
> +mkv->tracks[i].has_cue = 0;
> +}
> mkv->cluster_pos = -1;
> avio_write_marker(s->pb, AV_NOPTS_VALUE, AVIO_DATA_MARKER_FLUSH_POINT);
> }
> @@ -,7 +2226,7 @@ static int mkv_check_new_extra_data(AVFormatContext *s,
> AVPacket *pkt)
> return 0;
> }
>
> -static int mkv_write_packet_internal(AVFormatContext *s, AVPacket *pkt, int
> add_cue)
> +static int mkv_write_packet_internal(AVFormatContext *s, AVPacket *pkt)
> {
> MatroskaMuxContext *mkv = s->priv_data;
> AVIOContext *pb;
> @@ -2268,10 +2272,12 @@ static int mkv_write_packet_internal(AVFormatContext
> *s, AVPacket *pkt, int add_
> ret = mkv_write_block(s, pb, MATROSKA_ID_SIMPLEBLOCK, pkt, keyframe);
> if (ret < 0)
> return ret;
> -if ((s->pb->seekable & AVIO_SEEKABLE_NORMAL) && (par->codec_type ==
> AVMEDIA_TYPE_VIDEO && keyframe || add_cue)) {
> +if ((s->pb->seekable & AVIO_SEEKABLE_NORMAL) && keyframe &&
> +(par->codec_type == AVMEDIA_TYPE_VIDEO || !mkv->have_video &&
> !track->has_cue)) {
You may restrict this to Audio/Subtitles. Other streams/tracks may not create a
cue entry.
> ret = mkv_add_cuepoint(mkv, pkt->stream_index, ts,
> mkv->cluster_pos, relative_packet_pos,
> -1);
> if (ret < 0) return ret;
> +track->has_cue = 1;
> }
> } else {
> if (par->codec_id == AV_CODEC_ID_WEBVTT) {
> @@ -2336,8 +2342,7 @@ static int mkv_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> // on seeing key frames.
> start_new_cluster = keyframe;
> } else if (mkv->is_dash && codec_type == AVMEDIA_TYPE_AUDIO &&
> - (mkv->cluster_pos == -1 ||
> -cluster_time > mkv->cluster_time_limit)) {
> + cluster_time > mkv->cluster_time_limit) {
Is this related to this patch ? It currently means that if the Cluster did not
write any Block then a new cluster is not needed.
> // For DASH audio, we create a Cluster based on cluster_time_limit
> start_new_cluster = 1;
> } else if (!mkv->is_dash &&
> @@ -2361,9 +2366,7 @@ static int mkv_write_packet(AVFormatContext *s,
> AVPacket *pkt)
>
> // check if we have an audio packet cached
> if (mkv->cur_audio_pkt.size > 0) {
> -// for DASH audio, a CuePoint has to be added when there is a new
> cluster.
> -ret = mkv_write_packet_internal(s, >cur_audio_pkt,
> -mkv->is_dash ? start_new_cluster :
> 0);
> +ret = mkv_write_packet_internal(s, >cur_audio_pkt);
> av_packet_unref(>cur_audio_pkt);
> if (ret < 0) {
> av_log(s, AV_LOG_ERROR,
> @@ -2378,7 +2381,7 @@ static int mkv_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> if (pkt->size > 0)
> ret = av_packet_ref(>cur_audio_pkt, pkt);
> } else
> -ret = mkv_write_packet_internal(s, pkt, 0);
> +ret = mkv_write_packet_internal(s, pkt);
> return ret;
> }
>
> @@ -2406,7 +2409,7 @@ static int mkv_write_trailer(AVFormatContext *s)
>
> // check if we have an audio packet cached
> if (mkv->cur_audio_pkt.size > 0) {
> -ret = mkv_write_packet_internal(s, >cur_audio_pkt, 0);
> +ret = mkv_write_packet_internal(s, >cur_audio_pkt);
> if (ret < 0) {
>
Re: [FFmpeg-devel] [PATCH 06/20] avformat/matroskaenc: Make output more deterministic
Not sure how FATE works but I suppose the pseudo-random becomes deterministic ?
In that case the size should always be the same. And if not having a fixed size
will make no difference.
If FATE can skip random parts of a file (which your patch would solve) it will
miss inconsitencies of UIDs that should be the same in two places of the file.
So IMO it's not good. I suggest to have a flag in the muxer to force the seed
to a fixed value when using FATE.
> On April 5, 2020 5:59 PM Andreas Rheinhardt
> wrote:
>
>
> Using random values for TrackUID and FileUID (as happens when the
> AVFMT_FLAG_BITEXACT flag is not set) has the obvious downside of making
> the output indeterministic. This commit mitigates this by writing the
> potentially random values with a fixed size of eight byte, even if their
> actual values would fit into less than eight bytes. This ensures that
> even in non-bitexact mode, the differences between two files generated
> with the same settings are restricted to a few bytes in the header.
> (Namely the SegmentUID, the TrackUIDs (in Tracks as well as when
> referencing them via TagTrackUID), the FileUIDs (in Attachments as
> well as in TagAttachmentUID) as well as the CRC-32 checksums of the
> Info, Tracks, Attachments and Tags level-1-elements.) Without this
> patch, there might be an offset/a size difference between two such
> files.
>
> The FATE-tests had to be updated because the fixed-sized UIDs are also
> used in bitexact mode.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/matroskaenc.c | 16 +--
> tests/fate/matroska.mak | 2 +-
> tests/fate/wavpack.mak| 4 +-
> tests/ref/fate/aac-autobsf-adtstoasc | 4 +-
> tests/ref/fate/binsub-mksenc | 2 +-
> tests/ref/fate/matroska-flac-extradata-update | 4 +-
> tests/ref/fate/rgb24-mkv | 4 +-
> tests/ref/lavf-fate/av1.mkv | 4 +-
> tests/ref/lavf/mka| 4 +-
> tests/ref/lavf/mkv| 4 +-
> tests/ref/lavf/mkv_attachment | 4 +-
> tests/ref/seek/lavf-mkv | 44 +--
> 12 files changed, 53 insertions(+), 43 deletions(-)
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index 135d5e3abd..cf2bb7b933 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -226,6 +226,16 @@ static void put_ebml_num(AVIOContext *pb, uint64_t num,
> int bytes)
> avio_w8(pb, (uint8_t)(num >> i * 8));
> }
>
> +/**
> + * Write a (random) UID with fixed size to make the output more deterministic
> + */
> +static void put_ebml_uid(AVIOContext *pb, uint32_t elementid, uint64_t uid)
> +{
> +put_ebml_id(pb, elementid);
> +put_ebml_num(pb, 8, 0);
> +avio_wb64(pb, uid);
> +}
> +
> static void put_ebml_uint(AVIOContext *pb, uint32_t elementid, uint64_t val)
> {
> int i, bytes = 1;
> @@ -1104,7 +1114,7 @@ static int mkv_write_track(AVFormatContext *s,
> MatroskaMuxContext *mkv,
> track = start_ebml_master(pb, MATROSKA_ID_TRACKENTRY, 0);
> put_ebml_uint (pb, MATROSKA_ID_TRACKNUMBER,
> mkv->is_dash ? mkv->dash_track_number : i + 1);
> -put_ebml_uint (pb, MATROSKA_ID_TRACKUID, mkv->tracks[i].uid);
> +put_ebml_uid (pb, MATROSKA_ID_TRACKUID, mkv->tracks[i].uid);
> put_ebml_uint (pb, MATROSKA_ID_TRACKFLAGLACING , 0);// no lacing
> (yet)
>
> if ((tag = av_dict_get(st->metadata, "title", NULL, 0)))
> @@ -1485,7 +1495,7 @@ static int mkv_write_tag_targets(AVFormatContext *s,
> uint32_t elementid,
> *tag= start_ebml_master(pb, MATROSKA_ID_TAG,0);
> targets = start_ebml_master(pb, MATROSKA_ID_TAGTARGETS, 0);
> if (elementid)
> -put_ebml_uint(pb, elementid, uid);
> +put_ebml_uid(pb, elementid, uid);
> end_ebml_master(pb, targets);
> return 0;
> }
> @@ -1684,7 +1694,7 @@ static int mkv_write_attachments(AVFormatContext *s)
>
> put_ebml_string(dyn_cp, MATROSKA_ID_FILEMIMETYPE, mimetype);
> put_ebml_binary(dyn_cp, MATROSKA_ID_FILEDATA,
> st->codecpar->extradata, st->codecpar->extradata_size);
> -put_ebml_uint(dyn_cp, MATROSKA_ID_FILEUID, track->uid);
> +put_ebml_uid(dyn_cp, MATROSKA_ID_FILEUID, track->uid);
> end_ebml_master(dyn_cp, attached_file);
> }
> end_ebml_master_crc32(pb, _cp, mkv, MATROSKA_ID_ATTACHMENTS, 0, 0);
> diff --git a/tests/fate/matroska.mak b/tests/fate/matroska.mak
> index 4b9ee7a872..8cc35d52da 100644
> --- a/tests/fate/matroska.mak
> +++ b/tests/fate/matroska.mak
> @@ -12,7 +12,7 @@ fate-matroska-prores-header-insertion-bz2: CMD = framecrc
> -i $(TARGET_SAMPLES)/m
> FATE_MATROSKA-$(call DEMMUX, MATROSKA, MATROSKA) += fate-matroska-remux
> fate-matroska-remux: CMD = md5pipe -i
> $(TARGET_SAMPLES)/vp9-test-vectors/vp90-2-2pass-akiyo.webm -color_trc 4 -c:v
Re: [FFmpeg-devel] [PATCH 04/20] avformat/matroskaenc: Reuse random seed
Wouldn't it be better to set the AVLFG in the MatroskaMuxContext in mkv_init
and keep using it when needed ?
Then you can still update UIDs in the location you really need to create them.
> On April 5, 2020 5:59 PM Andreas Rheinhardt
> wrote:
>
>
> This commit reuses the random seed generated in mkv_init() (to determine
> the TrackUIDs) for the SegmentUID in order to avoid a potentially
> expensive call to av_get_random_seed().
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/matroskaenc.c | 19 +--
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index d2046193ee..b93c50cb01 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -161,6 +161,8 @@ typedef struct MatroskaMuxContext {
> int wrote_chapters;
>
> int allow_raw_vfw;
> +
> +uint32_t segment_uid[4];
> } MatroskaMuxContext;
>
> /** 2 bytes * 7 for EBML IDs, 7 1-byte EBML lengths, 6 1-byte uint,
> @@ -1821,15 +1823,7 @@ static int mkv_write_header(AVFormatContext *s)
> put_ebml_string(pb, MATROSKA_ID_WRITINGAPP, LIBAVFORMAT_IDENT);
>
> if (mkv->mode != MODE_WEBM) {
> -uint32_t segment_uid[4];
> -AVLFG lfg;
> -
> -av_lfg_init(, av_get_random_seed());
> -
> -for (i = 0; i < 4; i++)
> -segment_uid[i] = av_lfg_get();
> -
> -put_ebml_binary(pb, MATROSKA_ID_SEGMENTUID, segment_uid, 16);
> +put_ebml_binary(pb, MATROSKA_ID_SEGMENTUID, mkv->segment_uid,
> 16);
> }
> } else {
> const char *ident = "Lavf";
> @@ -2661,9 +2655,14 @@ static int mkv_init(struct AVFormatContext *s)
> return AVERROR(ENOMEM);
> }
>
> -if (!(s->flags & AVFMT_FLAG_BITEXACT))
> +if (!(s->flags & AVFMT_FLAG_BITEXACT)) {
> av_lfg_init(, av_get_random_seed());
>
> +// Calculate the SegmentUID now in order not to waste our random
> seed.
> +for (i = 0; i < 4; i++)
> +mkv->segment_uid[i] = av_lfg_get();
> +}
> +
> for (i = 0; i < s->nb_streams; i++) {
> mkv_track *track = >tracks[i];
>
> --
> 2.20.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".
___
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 01/20] avformat/matroskaenc: Ensure that ChapterUID are != 0
> On April 5, 2020 5:59 PM Andreas Rheinhardt
> wrote:
>
>
> AVChapters have an int as id field and therefore this value can appear
> <= 0. When remuxing from Matroska, this value actually contains
> the lower 32 bits of the original ChapterUID (which can be 64 bits).
>
> In order to ensure that the ChapterUID is always > 0, they were offset
> as follows (since 07704c61): First max(0, 1LL - chapter[i].id) was computed
> and stored in an uint32_t. And then the IDs were offset using this value.
>
> This has two downsides:
> 1. It does not ensure that the UID is actually != 0: Namely if there is
> a chapter with id == INT_MIN, then the offset will be 2^31 + 1 and a
> chapter with id == INT_MAX will become 2^31 - 1 + 2^31 + 1 = 2^32 = 0,
> because the actual calculation was performed in 32 bits.
> 2. As soon as a chapter id appears to be negative, a nontrivial offset
> is used, so that not even a ChapterUID that only uses 32 bits is
> preserved.
>
> So change this by treating the id as an unsigned value internally and
> only offset (by 1) if an id vanishes. The actual offsetting then has to
> be performed in 64 bits in order to make sure that no UINT32_MAX wraps
> around.
That means you are changing the chapter UIDs of the source when remuxing (if
for some reason a chapter with no id was added in the process). If tags were
referencing the chapter UIDs (TagChapterUID) they don't match the chapter
anymore.
I think silently changing the IDs is wrong. But its was already like that
before, so that's not breaking your patch. If anything your patch is less
likely to break remuxing.
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/matroskaenc.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index 060e8b7816..a377d092df 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -1422,7 +1422,8 @@ static int mkv_write_chapters(AVFormatContext *s)
> }
>
> chapteratom = start_ebml_master(dyn_cp, MATROSKA_ID_CHAPTERATOM, 0);
> -put_ebml_uint(dyn_cp, MATROSKA_ID_CHAPTERUID, c->id +
> mkv->chapter_id_offset);
> +put_ebml_uint(dyn_cp, MATROSKA_ID_CHAPTERUID,
> + (uint32_t)c->id + (uint64_t)mkv->chapter_id_offset);
> put_ebml_uint(dyn_cp, MATROSKA_ID_CHAPTERTIMESTART, chapterstart);
> put_ebml_uint(dyn_cp, MATROSKA_ID_CHAPTERTIMEEND, chapterend);
> if (mkv->mode != MODE_WEBM) {
> @@ -1479,7 +1480,7 @@ static int mkv_write_simpletag(AVIOContext *pb,
> AVDictionaryEntry *t)
> }
>
> static int mkv_write_tag_targets(AVFormatContext *s, uint32_t elementid,
> - unsigned int uid, ebml_master *tag)
> + uint64_t uid, ebml_master *tag)
> {
> AVIOContext *pb;
> MatroskaMuxContext *mkv = s->priv_data;
> @@ -1518,7 +1519,7 @@ static int mkv_check_tag_name(const char *name,
> uint32_t elementid)
> }
>
> static int mkv_write_tag(AVFormatContext *s, AVDictionary *m, uint32_t
> elementid,
> - unsigned int uid)
> + uint64_t uid)
> {
> MatroskaMuxContext *mkv = s->priv_data;
> ebml_master tag;
> @@ -1612,7 +1613,8 @@ static int mkv_write_tags(AVFormatContext *s)
> if (!mkv_check_tag(ch->metadata,
> MATROSKA_ID_TAGTARGETS_CHAPTERUID))
> continue;
>
> -ret = mkv_write_tag(s, ch->metadata,
> MATROSKA_ID_TAGTARGETS_CHAPTERUID, ch->id + mkv->chapter_id_offset);
> +ret = mkv_write_tag(s, ch->metadata,
> MATROSKA_ID_TAGTARGETS_CHAPTERUID,
> +(uint32_t)ch->id +
> (uint64_t)mkv->chapter_id_offset);
> if (ret < 0)
> return ret;
> }
> @@ -1882,7 +1884,10 @@ static int mkv_write_header(AVFormatContext *s)
> return ret;
>
> for (i = 0; i < s->nb_chapters; i++)
> -mkv->chapter_id_offset = FFMAX(mkv->chapter_id_offset, 1LL -
> s->chapters[i]->id);
> +if (!s->chapters[i]->id) {
> +mkv->chapter_id_offset = 1;
> +break;
> +}
>
> ret = mkv_write_chapters(s);
> if (ret < 0)
> --
> 2.20.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".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 02/14] avformat/matroska: clean the structure formatting
On 2020-03-25 23:24, Andreas Rheinhardt wrote:
Steve Lhomme:
From: Steve Lhomme
Always use a comma at the end, order elements by value.
---
libavformat/matroska.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroska.h b/libavformat/matroska.h
index 9e33e51c94..e177cd027f 100644
--- a/libavformat/matroska.h
+++ b/libavformat/matroska.h
@@ -286,13 +286,13 @@ typedef enum {
typedef enum {
MATROSKA_VIDEO_INTERLACE_FLAG_UNDETERMINED = 0,
MATROSKA_VIDEO_INTERLACE_FLAG_INTERLACED = 1,
-MATROSKA_VIDEO_INTERLACE_FLAG_PROGRESSIVE = 2
+MATROSKA_VIDEO_INTERLACE_FLAG_PROGRESSIVE = 2,
} MatroskaVideoInterlaceFlag;
typedef enum {
MATROSKA_VIDEO_FIELDORDER_PROGRESSIVE = 0,
-MATROSKA_VIDEO_FIELDORDER_UNDETERMINED = 2,
MATROSKA_VIDEO_FIELDORDER_TT = 1,
+MATROSKA_VIDEO_FIELDORDER_UNDETERMINED = 2,
MATROSKA_VIDEO_FIELDORDER_BB = 6,
MATROSKA_VIDEO_FIELDORDER_TB = 9,
MATROSKA_VIDEO_FIELDORDER_BT = 14,
Would it actually be allowed to add new values to the range of
FlagInterlaced (to which the MatroskaVideoInterlaceFlag enum
corresponds)? If no, then we should not add a comma, as this signals
extensibility.
The reordering looks good either way.
Yes, dependending on the DocType version it might be possible that some
new values are added to enums (not just this one).
Also I'm not sure I can tell an element in the last of an "list" in XSLT
so that would be more trouble to generate the code.
___
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 10/14] avformat/matroskadec: move the elements semantic in a separate file
On 2020-03-25 3:09, Andreas Rheinhardt wrote: Steve Lhomme: From: Steve Lhomme So the file can be generated from the Matroska Schema. The EbmlSyntax structures are not shared between files. matroska_segments and matroska_cluster_enter also have their size predefined. No functional changes. --- libavformat/Makefile | 2 +- libavformat/matroskadec.c | 668 +- libavformat/matroskasem.c | 384 ++ libavformat/matroskasem.h | 362 + 4 files changed, 748 insertions(+), 668 deletions(-) create mode 100644 libavformat/matroskasem.c create mode 100644 libavformat/matroskasem.h [...] diff --git a/libavformat/matroskasem.h b/libavformat/matroskasem.h new file mode 100644 index 00..8171982abf --- /dev/null +++ b/libavformat/matroskasem.h @@ -0,0 +1,362 @@ +/* + * Matroska file semantic definition + * Copyright (c) 2003-2020 The FFmpeg project + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/** + * @file + * Matroska file demuxer + * @author Ronald Bultje + * @author with a little help from Moritz Bunkus + * @author totally reworked by Aurelien Jacobs + * @see specs available on the Matroska project page: http://www.matroska.org/ + */ + +#ifndef AVFORMAT_MATROSKASEM_H +#define AVFORMAT_MATROSKASEM_H + +#include + +#include "matroska.h" +#include "avformat.h" +#include "libavutil/frame.h" Is it possible that you just included this for AVBufferRef (which is defined in libavutil/buffer.h)? Sure, I'll give it a try. ___ 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 13/14] tools: add XLSTs script to generate matroska semantic files
> On 22 Mar 2020, at 11:34, Carl Eugen Hoyos wrote: > > Am So., 22. März 2020 um 10:02 Uhr schrieb Steve Lhomme : >> >> From: Steve Lhomme >> >> Usage: >> xsltproc -o matroska_ids.h schema_2_lavf_h.xsl ebml_matroska.xml >> xsltproc -o matroskasem.c schema_2_lavf_sem_c.xsl ebml_matroska.xml >> >> The ebml_matroska.xml file comes from >> https://github.com/cellar-wg/matroska-specification/blob/master/ebml_matroska.xml >> With an extra TagDefault_Bug element to parse an old invalid tag ID. > >> tools/ebml_matroska.xml | 1344 + > > I would have expected that this file is not part of the FFmpeg source code. I'm ok with that, although the original file is modified to add a bogus element still supported by lavf. If at some point the files are generated (before building or making a source package) the file should be down and patched to generate the files. It seems FFmpeg doesn't have generated source files yet so I'm not sure what is the best/recommended way. > >> tools/schema_2_lavf_h.xsl | 741 ++ >> tools/schema_2_lavf_sem_c.xsl | 1163 >> 3 files changed, 3248 insertions(+) >> create mode 100644 tools/ebml_matroska.xml >> create mode 100644 tools/schema_2_lavf_h.xsl >> create mode 100644 tools/schema_2_lavf_sem_c.xsl > > 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 10/14] avformat/matroskadec: move the elements semantic in a separate file
From: Steve Lhomme
So the file can be generated from the Matroska Schema.
The EbmlSyntax structures are not shared between files.
matroska_segments and matroska_cluster_enter also have their size predefined.
No functional changes.
---
libavformat/Makefile | 2 +-
libavformat/matroskadec.c | 668 +-
libavformat/matroskasem.c | 384 ++
libavformat/matroskasem.h | 362 +
4 files changed, 748 insertions(+), 668 deletions(-)
create mode 100644 libavformat/matroskasem.c
create mode 100644 libavformat/matroskasem.h
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 8fd0d43721..09cd0d49ce 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -294,7 +294,7 @@ OBJS-$(CONFIG_LVF_DEMUXER) += lvfdec.o
OBJS-$(CONFIG_LXF_DEMUXER) += lxfdec.o
OBJS-$(CONFIG_M4V_DEMUXER) += m4vdec.o rawdec.o
OBJS-$(CONFIG_M4V_MUXER) += rawenc.o
-OBJS-$(CONFIG_MATROSKA_DEMUXER) += matroskadec.o matroska.o \
+OBJS-$(CONFIG_MATROSKA_DEMUXER) += matroskadec.o matroskasem.o
matroska.o \
rmsipr.o flac_picture.o \
oggparsevorbis.o vorbiscomment.o \
flac_picture.o replaygain.o
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index b021a4cce0..8aa2cbda61 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -54,6 +54,7 @@
#include "internal.h"
#include "isom.h"
#include "matroska.h"
+#include "matroskasem.h"
#include "oggdec.h"
/* For ff_codec_get_id(). */
#include "riff.h"
@@ -80,673 +81,6 @@
* to this many bytes of unknown data
for the
* SKIP_THRESHOLD check. */
-typedef enum {
-EBML_NONE,
-EBML_UINT,
-EBML_SINT,
-EBML_FLOAT,
-EBML_STR,
-EBML_UTF8,
-EBML_BIN,
-EBML_NEST,
-EBML_LEVEL1,
-EBML_STOP,
-EBML_TYPE_COUNT
-} EbmlType;
-
-typedef const struct EbmlSyntax {
-uint32_t id;
-EbmlType type;
-size_t list_elem_size;
-size_t data_offset;
-union {
-int64_t i;
-uint64_tu;
-double f;
-const char *s;
-const struct EbmlSyntax *n;
-} def;
-} EbmlSyntax;
-
-typedef struct EbmlList {
-int nb_elem;
-unsigned int alloc_elem_size;
-void *elem;
-} EbmlList;
-
-typedef struct EbmlBin {
-int size;
-AVBufferRef *buf;
-uint8_t *data;
-int64_t pos;
-} EbmlBin;
-
-typedef struct Ebml {
-uint64_t version;
-uint64_t max_size;
-uint64_t id_length;
-char*doctype;
-uint64_t doctype_version;
-} Ebml;
-
-typedef struct MatroskaTrackCompression {
-uint64_t algo;
-EbmlBin settings;
-} MatroskaTrackCompression;
-
-typedef struct MatroskaTrackEncryption {
-uint64_t algo;
-EbmlBin key_id;
-} MatroskaTrackEncryption;
-
-typedef struct MatroskaTrackEncoding {
-uint64_t scope;
-uint64_t type;
-MatroskaTrackCompression compression;
-MatroskaTrackEncryption encryption;
-} MatroskaTrackEncoding;
-
-typedef struct MatroskaMasteringMeta {
-double r_x;
-double r_y;
-double g_x;
-double g_y;
-double b_x;
-double b_y;
-double white_x;
-double white_y;
-double max_luminance;
-double min_luminance;
-} MatroskaMasteringMeta;
-
-typedef struct MatroskaTrackVideoColor {
-uint64_t matrix_coefficients;
-uint64_t bits_per_channel;
-uint64_t chroma_sub_horz;
-uint64_t chroma_sub_vert;
-uint64_t cb_sub_horz;
-uint64_t cb_sub_vert;
-uint64_t chroma_siting_horz;
-uint64_t chroma_siting_vert;
-uint64_t range;
-uint64_t transfer_characteristics;
-uint64_t primaries;
-uint64_t max_cll;
-uint64_t max_fall;
-MatroskaMasteringMeta mastering_meta;
-} MatroskaTrackVideoColor;
-
-typedef struct MatroskaTrackVideoProjection {
-uint64_t type;
-EbmlBin private;
-double yaw;
-double pitch;
-double roll;
-} MatroskaTrackVideoProjection;
-
-typedef struct MatroskaTrackVideo {
-double frame_rate;
-uint64_t display_width;
-uint64_t display_height;
-uint64_t pixel_width;
-uint64_t pixel_height;
-EbmlBin color_space;
-uint64_t display_unit;
-uint64_t interlaced;
-uint64_t field_order;
-uint64_t stereo_mode;
-uint64_t alpha_mode;
-EbmlList color;
-MatroskaTrackVideoProjection projection;
-} MatroskaTrackVideo;
-
-typedef struct MatroskaTrackAudio {
-double samplerate;
-double out_samplerate;
-uint64_t bitdepth;
-uint64_t channels;
-
-/* real audio header (extracted from extradata) */
-int coded_framesize;
-int sub_packet_h;
-int frame_size;
-int sub_packet_size;
-i
[FFmpeg-devel] [PATCH 12/14] avformat/matroskasem: reorder some EbmlSyntax elements
From: Steve Lhomme
So it's easier to match with the XSLT ordering which has limited possibilities
(15 max criteria for all the syntax tables).
No functional changes.
---
libavformat/matroskasem.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/libavformat/matroskasem.c b/libavformat/matroskasem.c
index 27aa6d9c4e..aca506b943 100644
--- a/libavformat/matroskasem.c
+++ b/libavformat/matroskasem.c
@@ -101,10 +101,6 @@ EbmlSyntax matroska_track_video[] = {
{ MATROSKA_ID_VIDEODISPLAYHEIGHT, EBML_UINT, 0,
offsetof(MatroskaTrackVideo, display_height), { .u=-1 } },
{ MATROSKA_ID_VIDEOPIXELWIDTH, EBML_UINT, 0,
offsetof(MatroskaTrackVideo, pixel_width) },
{ MATROSKA_ID_VIDEOPIXELHEIGHT,EBML_UINT, 0,
offsetof(MatroskaTrackVideo, pixel_height) },
-{ MATROSKA_ID_VIDEOCOLORSPACE, EBML_BIN, 0,
offsetof(MatroskaTrackVideo, color_space) },
-{ MATROSKA_ID_VIDEOALPHAMODE, EBML_UINT, 0,
offsetof(MatroskaTrackVideo, alpha_mode) },
-{ MATROSKA_ID_VIDEOCOLOR, EBML_NEST,
sizeof(MatroskaTrackVideoColor), offsetof(MatroskaTrackVideo, color), { .n =
matroska_track_video_color } },
-{ MATROSKA_ID_VIDEOPROJECTION, EBML_NEST, 0,
offsetof(MatroskaTrackVideo, projection), { .n =
matroska_track_video_projection } },
{ MATROSKA_ID_VIDEOPIXELCROPB, EBML_NONE },
{ MATROSKA_ID_VIDEOPIXELCROPT, EBML_NONE },
{ MATROSKA_ID_VIDEOPIXELCROPL, EBML_NONE },
@@ -112,6 +108,10 @@ EbmlSyntax matroska_track_video[] = {
{ MATROSKA_ID_VIDEODISPLAYUNIT,EBML_UINT, 0,
offsetof(MatroskaTrackVideo, display_unit), { .u=
MATROSKA_VIDEO_DISPLAYUNIT_PIXELS } },
{ MATROSKA_ID_VIDEOFLAGINTERLACED, EBML_UINT, 0,
offsetof(MatroskaTrackVideo, interlaced), { .u =
MATROSKA_VIDEO_INTERLACE_FLAG_UNDETERMINED } },
{ MATROSKA_ID_VIDEOFIELDORDER, EBML_UINT, 0,
offsetof(MatroskaTrackVideo, field_order), { .u =
MATROSKA_VIDEO_FIELDORDER_UNDETERMINED } },
+{ MATROSKA_ID_VIDEOALPHAMODE, EBML_UINT, 0,
offsetof(MatroskaTrackVideo, alpha_mode) },
+{ MATROSKA_ID_VIDEOCOLORSPACE, EBML_BIN, 0,
offsetof(MatroskaTrackVideo, color_space) },
+{ MATROSKA_ID_VIDEOCOLOR, EBML_NEST,
sizeof(MatroskaTrackVideoColor), offsetof(MatroskaTrackVideo, color), { .n =
matroska_track_video_color } },
+{ MATROSKA_ID_VIDEOPROJECTION, EBML_NEST, 0,
offsetof(MatroskaTrackVideo, projection), { .n =
matroska_track_video_projection } },
{ MATROSKA_ID_VIDEOSTEREOMODE, EBML_UINT, 0,
offsetof(MatroskaTrackVideo, stereo_mode), { .u =
MATROSKA_VIDEO_STEREOMODE_TYPE_NB } },
{ MATROSKA_ID_VIDEOASPECTRATIO,EBML_NONE },
CHILD_OF(matroska_track)
@@ -187,18 +187,18 @@ EbmlSyntax matroska_track[] = {
{ MATROSKA_ID_TRACKFLAGFORCED, EBML_UINT, 0,
offsetof(MatroskaTrack, flag_forced) },
{ MATROSKA_ID_TRACKVIDEO,EBML_NEST, 0,
offsetof(MatroskaTrack, video),{ .n = matroska_track_video } },
{ MATROSKA_ID_TRACKAUDIO,EBML_NEST, 0,
offsetof(MatroskaTrack, audio),{ .n = matroska_track_audio } },
-{ MATROSKA_ID_TRACKOPERATION,EBML_NEST, 0,
offsetof(MatroskaTrack, operation),{ .n = matroska_track_operation } },
-{ MATROSKA_ID_TRACKCONTENTENCODINGS, EBML_NEST, 0, 0,
{ .n = matroska_track_encodings } },
-{ MATROSKA_ID_TRACKMAXBLKADDID, EBML_UINT, 0,
offsetof(MatroskaTrack, max_block_additional_id) },
-{ MATROSKA_ID_SEEKPREROLL, EBML_UINT, 0,
offsetof(MatroskaTrack, seek_preroll) },
{ MATROSKA_ID_TRACKFLAGENABLED, EBML_NONE },
{ MATROSKA_ID_TRACKFLAGLACING, EBML_NONE },
+{ MATROSKA_ID_TRACKMINCACHE, EBML_NONE },
+{ MATROSKA_ID_TRACKMAXCACHE, EBML_NONE },
+{ MATROSKA_ID_TRACKMAXBLKADDID, EBML_UINT, 0,
offsetof(MatroskaTrack, max_block_additional_id) },
{ MATROSKA_ID_CODECNAME, EBML_NONE },
-{ MATROSKA_ID_CODECDECODEALL,EBML_NONE },
{ MATROSKA_ID_CODECINFOURL, EBML_NONE },
{ MATROSKA_ID_CODECDOWNLOADURL, EBML_NONE },
-{ MATROSKA_ID_TRACKMINCACHE, EBML_NONE },
-{ MATROSKA_ID_TRACKMAXCACHE, EBML_NONE },
+{ MATROSKA_ID_CODECDECODEALL,EBML_NONE },
+{ MATROSKA_ID_SEEKPREROLL, EBML_UINT, 0,
offsetof(MatroskaTrack, seek_preroll) },
+{ MATROSKA_ID_TRACKOPERATION,EBML_NEST, 0,
offsetof(MatroskaTrack, operation),{ .n = matroska_track_operation } },
+{ MATROSKA_ID_TRACKCONTENTENCODINGS, EBML_NEST, 0, 0,
{ .n = matroska_track_encodings } },
CHILD_OF(matroska_tracks)
};
@@ -307,10 +307,10 @@ EbmlSyntax matroska_cluster_parsing[] = {
{ MATROSKA_ID_SIMPLEBLOCK, EBML_BIN, 0, offsetof(MatroskaBlock, bin)
},
{ MATROSKA_ID_BLOCKGROUP, EBML_NEST, 0, 0, { .n = matroska_blockgroup
[FFmpeg-devel] [PATCH 14/14] avformat/matroska: use the generated semantic files
From: Steve Lhomme No functional value/added removed, only more regular spacing. --- libavformat/matroska_ids.h | 290 +++--- libavformat/matroskasem.c | 356 +++-- 2 files changed, 326 insertions(+), 320 deletions(-) diff --git a/libavformat/matroska_ids.h b/libavformat/matroska_ids.h index 321e555bec..f8e7cc927e 100644 --- a/libavformat/matroska_ids.h +++ b/libavformat/matroska_ids.h @@ -1,5 +1,7 @@ /* * Matroska Semantic constants + * DO NOT EDIT, GENERATED WITH schema_2_lavf_h.xsl + * * Copyright (c) 2003-2020 The FFmpeg Project * * This file is part of FFmpeg. @@ -30,162 +32,164 @@ #define MATROSKA_ID_SEGMENT0x18538067 /* Matroska top-level master IDs */ -#define MATROSKA_ID_INFO 0x1549A966 -#define MATROSKA_ID_TRACKS 0x1654AE6B -#define MATROSKA_ID_CUES 0x1C53BB6B -#define MATROSKA_ID_TAGS 0x1254C367 -#define MATROSKA_ID_SEEKHEAD 0x114D9B74 -#define MATROSKA_ID_ATTACHMENTS 0x1941A469 -#define MATROSKA_ID_CLUSTER0x1F43B675 -#define MATROSKA_ID_CHAPTERS 0x1043A770 +#define MATROSKA_ID_INFO0x1549A966 +#define MATROSKA_ID_TRACKS 0x1654AE6B +#define MATROSKA_ID_CUES0x1C53BB6B +#define MATROSKA_ID_TAGS0x1254C367 +#define MATROSKA_ID_SEEKHEAD0x114D9B74 +#define MATROSKA_ID_ATTACHMENTS 0x1941A469 +#define MATROSKA_ID_CLUSTER 0x1F43B675 +#define MATROSKA_ID_CHAPTERS0x1043A770 /* IDs in the info master */ -#define MATROSKA_ID_TIMECODESCALE 0x2AD7B1 -#define MATROSKA_ID_DURATION 0x4489 -#define MATROSKA_ID_TITLE 0x7BA9 -#define MATROSKA_ID_WRITINGAPP 0x5741 -#define MATROSKA_ID_MUXINGAPP 0x4D80 -#define MATROSKA_ID_DATEUTC0x4461 -#define MATROSKA_ID_SEGMENTUID 0x73A4 +#define MATROSKA_ID_TIMECODESCALE 0x2AD7B1 +#define MATROSKA_ID_DURATION0x4489 +#define MATROSKA_ID_TITLE 0x7BA9 +#define MATROSKA_ID_WRITINGAPP 0x5741 +#define MATROSKA_ID_MUXINGAPP 0x4D80 +#define MATROSKA_ID_DATEUTC 0x4461 +#define MATROSKA_ID_SEGMENTUID 0x73A4 -/* ID in the tracks master */ -#define MATROSKA_ID_TRACKENTRY 0xAE +/* IDs in the tracks master */ +#define MATROSKA_ID_TRACKENTRY 0xAE /* IDs in the trackentry master */ -#define MATROSKA_ID_TRACKNUMBER 0xD7 -#define MATROSKA_ID_TRACKUID 0x73C5 -#define MATROSKA_ID_TRACKTYPE 0x83 -#define MATROSKA_ID_TRACKVIDEO 0xE0 -#define MATROSKA_ID_TRACKAUDIO 0xE1 -#define MATROSKA_ID_TRACKOPERATION 0xE2 -#define MATROSKA_ID_TRACKTIMECODESCALE 0x23314F -#define MATROSKA_ID_TRACKMAXBLKADDID 0x55EE -#define MATROSKA_ID_TRACKNAME 0x536E -#define MATROSKA_ID_TRACKLANGUAGE 0x22B59C -#define MATROSKA_ID_CODECID0x86 -#define MATROSKA_ID_CODECPRIVATE 0x63A2 -#define MATROSKA_ID_CODECNAME 0x258688 -#define MATROSKA_ID_CODECINFOURL 0x3B4040 -#define MATROSKA_ID_CODECDOWNLOADURL 0x26B240 -#define MATROSKA_ID_CODECDECODEALL 0xAA -#define MATROSKA_ID_CODECDELAY 0x56AA -#define MATROSKA_ID_SEEKPREROLL 0x56BB -#define MATROSKA_ID_TRACKFLAGENABLED 0xB9 -#define MATROSKA_ID_TRACKFLAGDEFAULT 0x88 -#define MATROSKA_ID_TRACKFLAGFORCED 0x55AA -#define MATROSKA_ID_TRACKFLAGLACING 0x9C -#define MATROSKA_ID_TRACKMINCACHE 0x6DE7 -#define MATROSKA_ID_TRACKMAXCACHE 0x6DF8 -#define MATROSKA_ID_TRACKDEFAULTDURATION 0x23E383 -#define MATROSKA_ID_TRACKCONTENTENCODINGS 0x6D80 +#define MATROSKA_ID_TRACKNUMBER 0xD7 +#define MATROSKA_ID_TRACKUID0x73C5 +#define MATROSKA_ID_TRACKTYPE 0x83 +#define MATROSKA_ID_TRACKVIDEO 0xE0 +#define MATROSKA_ID_TRACKAUDIO 0xE1 +#define MATROSKA_ID_TRACKOPERATION 0xE2 +#define MATROSKA_ID_TRACKTIMECODESCALE 0x23314F +#define MATROSKA_ID_TRACKMAXBLKADDID0x55EE +#define MATROSKA_ID_TRACKNAME 0x536E +#define MATROSKA_ID_TRACKLANGUAGE 0x22B59C +#define MATROSKA_ID_CODECID 0x86 +#define MATROSKA_ID_CODECPRIVATE0x63A2 +#define MATROSKA_ID_CODECNAME 0x258688 +#define MATROSKA_ID_CODECINFOURL0x3B4040 +#define MATROSKA_ID_CODECDOWNLOADURL0x26B240 +#define MATROSKA_ID_CODECDECODEALL 0xAA +#define MATROSKA_ID_CODECDELAY 0x56AA +#define MATROSKA_ID_SEEKPREROLL 0x56BB +#define MATROSKA_ID_TRACKFLAGENABLED0xB9 +#define MATROSKA_ID_TRACKFLAGDEFAULT0x88 +#define MATROSKA_ID_TRACKFLAGFORCED 0x55AA +#define MATROSKA_ID_TRACKFLAGLACING 0x9C +#define MATROSKA_ID_TRACKMINCACHE 0x6DE7 +#define MATROSKA_ID_TRACKMAXCACHE 0x6DF8 +#define MATROSKA_ID_TRACKDEFAULTDURATION 0x23E383 +#define MATROSKA_ID_TRACKCONTENTENCODINGS 0x6D80 /* IDs in the contentencodings master */ -#define MATROSKA_ID_TRACKCONTENTENCODING 0x6240 +#define MATROSKA_ID_TRACKCONTENTENCODING 0x6240 /* IDs in the content encoding master */ -#define MATROSKA_ID_ENCODINGORDER 0x5031 -#define MATROSKA_ID_ENCODINGSCOPE 0x5032 -#define MATROSKA_ID_ENCODINGTYPE 0x5033
[FFmpeg-devel] [PATCH 11/14] avformat/matroskasem: reorder EbmlSyntax tables
From: Steve Lhomme
So they are sorted by their EBML path, in reverse order so we don't extra
declarations.
No functional changes.
---
libavformat/matroskasem.c | 256 +++---
1 file changed, 128 insertions(+), 128 deletions(-)
diff --git a/libavformat/matroskasem.c b/libavformat/matroskasem.c
index ce9331e044..27aa6d9c4e 100644
--- a/libavformat/matroskasem.c
+++ b/libavformat/matroskasem.c
@@ -54,15 +54,13 @@ EbmlSyntax ebml_syntax[] = {
{ 0 }
};
-static EbmlSyntax matroska_info[] = {
-{ MATROSKA_ID_TIMECODESCALE, EBML_UINT, 0, offsetof(MatroskaDemuxContext,
time_scale), { .u = 100 } },
-{ MATROSKA_ID_DURATION, EBML_FLOAT, 0, offsetof(MatroskaDemuxContext,
duration) },
-{ MATROSKA_ID_TITLE, EBML_UTF8, 0, offsetof(MatroskaDemuxContext,
title) },
-{ MATROSKA_ID_WRITINGAPP,EBML_NONE },
-{ MATROSKA_ID_MUXINGAPP, EBML_UTF8, 0, offsetof(MatroskaDemuxContext,
muxingapp) },
-{ MATROSKA_ID_DATEUTC, EBML_BIN, 0, offsetof(MatroskaDemuxContext,
date_utc) },
-{ MATROSKA_ID_SEGMENTUID,EBML_NONE },
-CHILD_OF(matroska_segment)
+static EbmlSyntax matroska_track_video_projection[] = {
+{ MATROSKA_ID_VIDEOPROJECTIONTYPE,EBML_UINT, 0,
offsetof(MatroskaTrackVideoProjection, type), { .u =
MATROSKA_VIDEO_PROJECTION_TYPE_RECTANGULAR } },
+{ MATROSKA_ID_VIDEOPROJECTIONPRIVATE, EBML_BIN, 0,
offsetof(MatroskaTrackVideoProjection, private) },
+{ MATROSKA_ID_VIDEOPROJECTIONPOSEYAW, EBML_FLOAT, 0,
offsetof(MatroskaTrackVideoProjection, yaw), { .f=0.0 } },
+{ MATROSKA_ID_VIDEOPROJECTIONPOSEPITCH, EBML_FLOAT, 0,
offsetof(MatroskaTrackVideoProjection, pitch), { .f=0.0 } },
+{ MATROSKA_ID_VIDEOPROJECTIONPOSEROLL,EBML_FLOAT, 0,
offsetof(MatroskaTrackVideoProjection, roll), { .f=0.0 } },
+CHILD_OF(matroska_track_video)
};
static EbmlSyntax matroska_mastering_meta[] = {
@@ -97,15 +95,6 @@ EbmlSyntax matroska_track_video_color[] = {
CHILD_OF(matroska_track_video)
};
-static EbmlSyntax matroska_track_video_projection[] = {
-{ MATROSKA_ID_VIDEOPROJECTIONTYPE,EBML_UINT, 0,
offsetof(MatroskaTrackVideoProjection, type), { .u =
MATROSKA_VIDEO_PROJECTION_TYPE_RECTANGULAR } },
-{ MATROSKA_ID_VIDEOPROJECTIONPRIVATE, EBML_BIN, 0,
offsetof(MatroskaTrackVideoProjection, private) },
-{ MATROSKA_ID_VIDEOPROJECTIONPOSEYAW, EBML_FLOAT, 0,
offsetof(MatroskaTrackVideoProjection, yaw), { .f=0.0 } },
-{ MATROSKA_ID_VIDEOPROJECTIONPOSEPITCH, EBML_FLOAT, 0,
offsetof(MatroskaTrackVideoProjection, pitch), { .f=0.0 } },
-{ MATROSKA_ID_VIDEOPROJECTIONPOSEROLL,EBML_FLOAT, 0,
offsetof(MatroskaTrackVideoProjection, roll), { .f=0.0 } },
-CHILD_OF(matroska_track_video)
-};
-
EbmlSyntax matroska_track_video[] = {
{ MATROSKA_ID_VIDEOFRAMERATE, EBML_FLOAT, 0,
offsetof(MatroskaTrackVideo, frame_rate) },
{ MATROSKA_ID_VIDEODISPLAYWIDTH, EBML_UINT, 0,
offsetof(MatroskaTrackVideo, display_width), { .u=-1 } },
@@ -128,18 +117,20 @@ EbmlSyntax matroska_track_video[] = {
CHILD_OF(matroska_track)
};
-static EbmlSyntax matroska_track_audio[] = {
-{ MATROSKA_ID_AUDIOSAMPLINGFREQ,EBML_FLOAT, 0,
offsetof(MatroskaTrackAudio, samplerate), { .f = 8000.0 } },
-{ MATROSKA_ID_AUDIOOUTSAMPLINGFREQ, EBML_FLOAT, 0,
offsetof(MatroskaTrackAudio, out_samplerate) },
-{ MATROSKA_ID_AUDIOBITDEPTH,EBML_UINT, 0,
offsetof(MatroskaTrackAudio, bitdepth) },
-{ MATROSKA_ID_AUDIOCHANNELS,EBML_UINT, 0,
offsetof(MatroskaTrackAudio, channels), { .u = 1 } },
-CHILD_OF(matroska_track)
+EbmlSyntax matroska_track_plane[] = {
+{ MATROSKA_ID_TRACKPLANEUID, EBML_UINT, 0,
offsetof(MatroskaTrackPlane,uid) },
+{ MATROSKA_ID_TRACKPLANETYPE, EBML_UINT, 0,
offsetof(MatroskaTrackPlane,type) },
+CHILD_OF(matroska_track_combine_planes)
};
-static EbmlSyntax matroska_track_encoding_compression[] = {
-{ MATROSKA_ID_ENCODINGCOMPALGO, EBML_UINT, 0,
offsetof(MatroskaTrackCompression, algo) },
-{ MATROSKA_ID_ENCODINGCOMPSETTINGS, EBML_BIN, 0,
offsetof(MatroskaTrackCompression, settings) },
-CHILD_OF(matroska_track_encoding)
+EbmlSyntax matroska_track_combine_planes[] = {
+{ MATROSKA_ID_TRACKPLANE, EBML_NEST, sizeof(MatroskaTrackPlane),
offsetof(MatroskaTrackOperation,combine_planes), {.n = matroska_track_plane} },
+CHILD_OF(matroska_track_operation)
+};
+
+EbmlSyntax matroska_track_operation[] = {
+{ MATROSKA_ID_TRACKCOMBINEPLANES, EBML_NEST, 0, 0, {.n =
matroska_track_combine_planes} },
+CHILD_OF(matroska_track)
};
static EbmlSyntax matroska_track_encoding_encryption[] = {
@@ -153,6 +144,12 @@ static EbmlSyntax matroska_track_encoding_encryption[] = {
CHILD_OF(matroska_track_encoding)
};
+static EbmlSyntax matroska_track_encoding_compression[] = {
+{ MATROSKA_ID_ENCODINGCOMPALGO, EBML_UINT, 0,
offsetof(MatroskaTrackCompression, algo
[FFmpeg-devel] [PATCH 09/14] avformat/matroskadec: remove some implicit default value
From: Steve Lhomme
All integers should be initialized to 0. Make the tables more consistent by
only setting non zero values.
---
libavformat/matroskadec.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 3640dd76d9..b021a4cce0 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -445,18 +445,18 @@ static EbmlSyntax matroska_mastering_meta[] = {
static EbmlSyntax matroska_track_video_color[] = {
{ MATROSKA_ID_VIDEOCOLORMATRIXCOEFF, EBML_UINT, 0,
offsetof(MatroskaTrackVideoColor, matrix_coefficients), { .u =
AVCOL_SPC_UNSPECIFIED } },
-{ MATROSKA_ID_VIDEOCOLORBITSPERCHANNEL, EBML_UINT, 0,
offsetof(MatroskaTrackVideoColor, bits_per_channel), { .u=0 } },
-{ MATROSKA_ID_VIDEOCOLORCHROMASUBHORZ,EBML_UINT, 0,
offsetof(MatroskaTrackVideoColor, chroma_sub_horz), { .u=0 } },
-{ MATROSKA_ID_VIDEOCOLORCHROMASUBVERT,EBML_UINT, 0,
offsetof(MatroskaTrackVideoColor, chroma_sub_vert), { .u=0 } },
-{ MATROSKA_ID_VIDEOCOLORCBSUBHORZ,EBML_UINT, 0,
offsetof(MatroskaTrackVideoColor, cb_sub_horz), { .u=0 } },
-{ MATROSKA_ID_VIDEOCOLORCBSUBVERT,EBML_UINT, 0,
offsetof(MatroskaTrackVideoColor, cb_sub_vert), { .u=0 } },
+{ MATROSKA_ID_VIDEOCOLORBITSPERCHANNEL, EBML_UINT, 0,
offsetof(MatroskaTrackVideoColor, bits_per_channel) },
+{ MATROSKA_ID_VIDEOCOLORCHROMASUBHORZ,EBML_UINT, 0,
offsetof(MatroskaTrackVideoColor, chroma_sub_horz) },
+{ MATROSKA_ID_VIDEOCOLORCHROMASUBVERT,EBML_UINT, 0,
offsetof(MatroskaTrackVideoColor, chroma_sub_vert) },
+{ MATROSKA_ID_VIDEOCOLORCBSUBHORZ,EBML_UINT, 0,
offsetof(MatroskaTrackVideoColor, cb_sub_horz) },
+{ MATROSKA_ID_VIDEOCOLORCBSUBVERT,EBML_UINT, 0,
offsetof(MatroskaTrackVideoColor, cb_sub_vert) },
{ MATROSKA_ID_VIDEOCOLORCHROMASITINGHORZ, EBML_UINT, 0,
offsetof(MatroskaTrackVideoColor, chroma_siting_horz), { .u =
MATROSKA_COLOUR_CHROMASITINGHORZ_UNDETERMINED } },
{ MATROSKA_ID_VIDEOCOLORCHROMASITINGVERT, EBML_UINT, 0,
offsetof(MatroskaTrackVideoColor, chroma_siting_vert), { .u =
MATROSKA_COLOUR_CHROMASITINGVERT_UNDETERMINED } },
{ MATROSKA_ID_VIDEOCOLORRANGE,EBML_UINT, 0,
offsetof(MatroskaTrackVideoColor, range), { .u = AVCOL_RANGE_UNSPECIFIED } },
{ MATROSKA_ID_VIDEOCOLORTRANSFERCHARACTERISTICS, EBML_UINT, 0,
offsetof(MatroskaTrackVideoColor, transfer_characteristics), { .u =
AVCOL_TRC_UNSPECIFIED } },
{ MATROSKA_ID_VIDEOCOLORPRIMARIES,EBML_UINT, 0,
offsetof(MatroskaTrackVideoColor, primaries), { .u = AVCOL_PRI_UNSPECIFIED } },
-{ MATROSKA_ID_VIDEOCOLORMAXCLL, EBML_UINT, 0,
offsetof(MatroskaTrackVideoColor, max_cll), { .u=0 } },
-{ MATROSKA_ID_VIDEOCOLORMAXFALL, EBML_UINT, 0,
offsetof(MatroskaTrackVideoColor, max_fall), { .u=0 } },
+{ MATROSKA_ID_VIDEOCOLORMAXCLL, EBML_UINT, 0,
offsetof(MatroskaTrackVideoColor, max_cll) },
+{ MATROSKA_ID_VIDEOCOLORMAXFALL, EBML_UINT, 0,
offsetof(MatroskaTrackVideoColor, max_fall) },
{ MATROSKA_ID_VIDEOCOLORMASTERINGMETA,EBML_NEST, 0,
offsetof(MatroskaTrackVideoColor, mastering_meta), { .n =
matroska_mastering_meta } },
CHILD_OF(matroska_track_video)
};
@@ -501,13 +501,13 @@ static EbmlSyntax matroska_track_audio[] = {
};
static EbmlSyntax matroska_track_encoding_compression[] = {
-{ MATROSKA_ID_ENCODINGCOMPALGO, EBML_UINT, 0,
offsetof(MatroskaTrackCompression, algo), { .u = 0 } },
+{ MATROSKA_ID_ENCODINGCOMPALGO, EBML_UINT, 0,
offsetof(MatroskaTrackCompression, algo) },
{ MATROSKA_ID_ENCODINGCOMPSETTINGS, EBML_BIN, 0,
offsetof(MatroskaTrackCompression, settings) },
CHILD_OF(matroska_track_encoding)
};
static EbmlSyntax matroska_track_encoding_encryption[] = {
-{ MATROSKA_ID_ENCODINGENCALGO,EBML_UINT, 0,
offsetof(MatroskaTrackEncryption,algo), {.u = 0} },
+{ MATROSKA_ID_ENCODINGENCALGO,EBML_UINT, 0,
offsetof(MatroskaTrackEncryption,algo) },
{ MATROSKA_ID_ENCODINGENCKEYID, EBML_BIN, 0,
offsetof(MatroskaTrackEncryption,key_id) },
{ MATROSKA_ID_ENCODINGENCAESSETTINGS, EBML_NONE },
{ MATROSKA_ID_ENCODINGSIGALGO,EBML_NONE },
@@ -518,7 +518,7 @@ static EbmlSyntax matroska_track_encoding_encryption[] = {
};
static EbmlSyntax matroska_track_encoding[] = {
{ MATROSKA_ID_ENCODINGSCOPE, EBML_UINT, 0,
offsetof(MatroskaTrackEncoding, scope), { .u = 1 } },
-{ MATROSKA_ID_ENCODINGTYPE,EBML_UINT, 0,
offsetof(MatroskaTrackEncoding, type),{ .u = 0 } },
+{ MATROSKA_ID_ENCODINGTYPE,EBML_UINT, 0,
offsetof(MatroskaTrackEncoding, type) },
{ MATROSKA_ID_ENCODINGCOMPRESSION, EBML_NEST, 0,
offsetof(MatroskaTrackEncoding, compression), { .n =
matroska_track_encoding_compression } },
{ MATROSKA_ID_ENCODINGENCRYPTION, EBML_NEST, 0,
offsetof(MatroskaTrackEncoding
[FFmpeg-devel] [PATCH 08/14] avformat/matroskadec: fix the default of the TagDefault element
From: Steve Lhomme
By default a tag is the default one.
---
libavformat/matroskadec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 383869bced..3640dd76d9 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -652,8 +652,8 @@ static EbmlSyntax matroska_simpletag[] = {
{ MATROSKA_ID_TAGNAME,EBML_UTF8, 0,
offsetof(MatroskaTag, name) },
{ MATROSKA_ID_TAGSTRING, EBML_UTF8, 0,
offsetof(MatroskaTag, string) },
{ MATROSKA_ID_TAGLANG,EBML_STR, 0,
offsetof(MatroskaTag, lang), { .s = "und" } },
-{ MATROSKA_ID_TAGDEFAULT, EBML_UINT, 0,
offsetof(MatroskaTag, def) },
-{ MATROSKA_ID_TAGDEFAULT_BUG, EBML_UINT, 0,
offsetof(MatroskaTag, def) },
+{ MATROSKA_ID_TAGDEFAULT, EBML_UINT, 0,
offsetof(MatroskaTag, def), { .u = 1 } },
+{ MATROSKA_ID_TAGDEFAULT_BUG, EBML_UINT, 0,
offsetof(MatroskaTag, def), { .u = 1 } },
{ MATROSKA_ID_SIMPLETAG, EBML_NEST, sizeof(MatroskaTag),
offsetof(MatroskaTag, sub), { .n = matroska_simpletag } },
CHILD_OF(matroska_tag)
};
--
2.18.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 05/14] avformat:matroska_ids: move some IDs in separate sections
From: Steve Lhomme According grouped with their parent's elements. No value added/removed. --- libavformat/matroska_ids.h | 78 ++ 1 file changed, 54 insertions(+), 24 deletions(-) diff --git a/libavformat/matroska_ids.h b/libavformat/matroska_ids.h index 063dae5f94..ab77228da5 100644 --- a/libavformat/matroska_ids.h +++ b/libavformat/matroska_ids.h @@ -58,10 +58,8 @@ #define MATROSKA_ID_TRACKVIDEO 0xE0 #define MATROSKA_ID_TRACKAUDIO 0xE1 #define MATROSKA_ID_TRACKOPERATION 0xE2 -#define MATROSKA_ID_TRACKCOMBINEPLANES 0xE3 -#define MATROSKA_ID_TRACKPLANE 0xE4 -#define MATROSKA_ID_TRACKPLANEUID 0xE5 -#define MATROSKA_ID_TRACKPLANETYPE 0xE6 +#define MATROSKA_ID_TRACKTIMECODESCALE 0x23314F +#define MATROSKA_ID_TRACKMAXBLKADDID 0x55EE #define MATROSKA_ID_CODECID0x86 #define MATROSKA_ID_CODECPRIVATE 0x63A2 #define MATROSKA_ID_CODECNAME 0x258688 @@ -80,9 +78,19 @@ #define MATROSKA_ID_TRACKMAXCACHE 0x6DF8 #define MATROSKA_ID_TRACKDEFAULTDURATION 0x23E383 #define MATROSKA_ID_TRACKCONTENTENCODINGS 0x6D80 + +/* IDs in the contentencodings master */ #define MATROSKA_ID_TRACKCONTENTENCODING 0x6240 -#define MATROSKA_ID_TRACKTIMECODESCALE 0x23314F -#define MATROSKA_ID_TRACKMAXBLKADDID 0x55EE + +/* IDs in the trackoperation master */ +#define MATROSKA_ID_TRACKCOMBINEPLANES 0xE3 + +/* IDs in the trackcombineplanes master */ +#define MATROSKA_ID_TRACKPLANE 0xE4 + +/* IDs in the trackplane master */ +#define MATROSKA_ID_TRACKPLANEUID 0xE5 +#define MATROSKA_ID_TRACKPLANETYPE 0xE6 /* IDs in the trackvideo master */ #define MATROSKA_ID_VIDEOFRAMERATE 0x2383E3 @@ -102,7 +110,9 @@ #define MATROSKA_ID_VIDEOASPECTRATIO 0x54B3 #define MATROSKA_ID_VIDEOCOLORSPACE 0x2EB524 #define MATROSKA_ID_VIDEOCOLOR 0x55B0 +#define MATROSKA_ID_VIDEOPROJECTION 0x7670 +/* IDs in the colour master */ #define MATROSKA_ID_VIDEOCOLORMATRIXCOEFF 0x55B1 #define MATROSKA_ID_VIDEOCOLORBITSPERCHANNEL 0x55B2 #define MATROSKA_ID_VIDEOCOLORCHROMASUBHORZ 0x55B3 @@ -113,12 +123,12 @@ #define MATROSKA_ID_VIDEOCOLORCHROMASITINGVERT 0x55B8 #define MATROSKA_ID_VIDEOCOLORRANGE 0x55B9 #define MATROSKA_ID_VIDEOCOLORTRANSFERCHARACTERISTICS 0x55BA - #define MATROSKA_ID_VIDEOCOLORPRIMARIES 0x55BB #define MATROSKA_ID_VIDEOCOLORMAXCLL 0x55BC #define MATROSKA_ID_VIDEOCOLORMAXFALL 0x55BD - #define MATROSKA_ID_VIDEOCOLORMASTERINGMETA 0x55D0 + +/* IDs in the masteringmetadata master */ #define MATROSKA_ID_VIDEOCOLOR_RX 0x55D1 #define MATROSKA_ID_VIDEOCOLOR_RY 0x55D2 #define MATROSKA_ID_VIDEOCOLOR_GX 0x55D3 @@ -130,7 +140,7 @@ #define MATROSKA_ID_VIDEOCOLOR_LUMINANCEMAX 0x55D9 #define MATROSKA_ID_VIDEOCOLOR_LUMINANCEMIN 0x55DA -#define MATROSKA_ID_VIDEOPROJECTION 0x7670 +/* IDs in the projection master */ #define MATROSKA_ID_VIDEOPROJECTIONTYPE 0x7671 #define MATROSKA_ID_VIDEOPROJECTIONPRIVATE 0x7672 #define MATROSKA_ID_VIDEOPROJECTIONPOSEYAW 0x7673 @@ -140,7 +150,6 @@ /* IDs in the trackaudio master */ #define MATROSKA_ID_AUDIOSAMPLINGFREQ 0xB5 #define MATROSKA_ID_AUDIOOUTSAMPLINGFREQ 0x78B5 - #define MATROSKA_ID_AUDIOBITDEPTH 0x6264 #define MATROSKA_ID_AUDIOCHANNELS 0x9F @@ -149,10 +158,13 @@ #define MATROSKA_ID_ENCODINGSCOPE 0x5032 #define MATROSKA_ID_ENCODINGTYPE 0x5033 #define MATROSKA_ID_ENCODINGCOMPRESSION 0x5034 +#define MATROSKA_ID_ENCODINGENCRYPTION 0x5035 + +/* IDs in the contentcompression master */ #define MATROSKA_ID_ENCODINGCOMPALGO 0x4254 #define MATROSKA_ID_ENCODINGCOMPSETTINGS 0x4255 -#define MATROSKA_ID_ENCODINGENCRYPTION 0x5035 +/* IDs in the contentencryption master */ #define MATROSKA_ID_ENCODINGENCAESSETTINGS 0x47E7 #define MATROSKA_ID_ENCODINGENCALGO 0x47E1 #define MATROSKA_ID_ENCODINGENCKEYID 0x47E2 @@ -177,13 +189,19 @@ /* IDs in the tags master */ #define MATROSKA_ID_TAG 0x7373 + +/* IDs in the tag master */ #define MATROSKA_ID_SIMPLETAG 0x67C8 -#define MATROSKA_ID_TAGNAME 0x45A3 -#define MATROSKA_ID_TAGSTRING 0x4487 +#define MATROSKA_ID_TAGTARGETS 0x63C0 + +/* IDs in the simpletag master */ #define MATROSKA_ID_TAGLANG 0x447A #define MATROSKA_ID_TAGDEFAULT 0x4484 +#define MATROSKA_ID_TAGSTRING 0x4487 #define MATROSKA_ID_TAGDEFAULT_BUG 0x44B4 -#define MATROSKA_ID_TAGTARGETS 0x63C0 +#define MATROSKA_ID_TAGNAME 0x45A3 + +/* IDs in the targets master */ #define MATROSKA_ID_TAGTARGETS_TYPE 0x63CA #define MATROSKA_ID_TAGTARGETS_TYPEVALUE 0x68CA #define MATROSKA_ID_TAGTARGETS_TRACKUID 0x63C5 @@ -202,21 +220,27 @@ #define MATROSKA_ID_CLUSTERPOSITION 0xA7 #define MATROSKA_ID_CLUSTERPREVSIZE 0xAB #define MATROSKA_ID_BLOCKGROUP 0xA0 -#define MATROSKA_ID_BLOCKADDITIONS 0x75A1 -#define MATROSKA_ID_BLOCKMORE 0xA6 -#define MATROSKA_ID_BLOCKADDID 0xEE -#define MATROSKA_ID_BLOCKADDITIONAL 0xA5 #define MATROSKA_ID_SIMPLEBLOCK 0xA3 /* IDs in the blockgroup master */ #define
[FFmpeg-devel] [PATCH 04/14] avformat/matroska: move Matroska IDs and enums in a separate header
From: Steve Lhomme So the file can be generated from the EBML Schema. No functional change. --- libavformat/matroska.h | 302 +- libavformat/matroska_ids.h | 327 + 2 files changed, 328 insertions(+), 301 deletions(-) create mode 100644 libavformat/matroska_ids.h diff --git a/libavformat/matroska.h b/libavformat/matroska.h index 5520e9ce8f..10140dea48 100644 --- a/libavformat/matroska.h +++ b/libavformat/matroska.h @@ -23,6 +23,7 @@ #define AVFORMAT_MATROSKA_H #include "libavcodec/avcodec.h" +#include "matroska_ids.h" #include "metadata.h" #include "internal.h" @@ -45,307 +46,6 @@ #define EBML_ID_VOID 0xEC #define EBML_ID_CRC32 0xBF -/* - * Matroska element IDs, max. 32 bits - */ - -/* toplevel segment */ -#define MATROSKA_ID_SEGMENT0x18538067 - -/* Matroska top-level master IDs */ -#define MATROSKA_ID_INFO 0x1549A966 -#define MATROSKA_ID_TRACKS 0x1654AE6B -#define MATROSKA_ID_CUES 0x1C53BB6B -#define MATROSKA_ID_TAGS 0x1254C367 -#define MATROSKA_ID_SEEKHEAD 0x114D9B74 -#define MATROSKA_ID_ATTACHMENTS 0x1941A469 -#define MATROSKA_ID_CLUSTER0x1F43B675 -#define MATROSKA_ID_CHAPTERS 0x1043A770 - -/* IDs in the info master */ -#define MATROSKA_ID_TIMECODESCALE 0x2AD7B1 -#define MATROSKA_ID_DURATION 0x4489 -#define MATROSKA_ID_TITLE 0x7BA9 -#define MATROSKA_ID_WRITINGAPP 0x5741 -#define MATROSKA_ID_MUXINGAPP 0x4D80 -#define MATROSKA_ID_DATEUTC0x4461 -#define MATROSKA_ID_SEGMENTUID 0x73A4 - -/* ID in the tracks master */ -#define MATROSKA_ID_TRACKENTRY 0xAE - -/* IDs in the trackentry master */ -#define MATROSKA_ID_TRACKNUMBER 0xD7 -#define MATROSKA_ID_TRACKUID 0x73C5 -#define MATROSKA_ID_TRACKTYPE 0x83 -#define MATROSKA_ID_TRACKVIDEO 0xE0 -#define MATROSKA_ID_TRACKAUDIO 0xE1 -#define MATROSKA_ID_TRACKOPERATION 0xE2 -#define MATROSKA_ID_TRACKCOMBINEPLANES 0xE3 -#define MATROSKA_ID_TRACKPLANE 0xE4 -#define MATROSKA_ID_TRACKPLANEUID 0xE5 -#define MATROSKA_ID_TRACKPLANETYPE 0xE6 -#define MATROSKA_ID_CODECID0x86 -#define MATROSKA_ID_CODECPRIVATE 0x63A2 -#define MATROSKA_ID_CODECNAME 0x258688 -#define MATROSKA_ID_CODECINFOURL 0x3B4040 -#define MATROSKA_ID_CODECDOWNLOADURL 0x26B240 -#define MATROSKA_ID_CODECDECODEALL 0xAA -#define MATROSKA_ID_CODECDELAY 0x56AA -#define MATROSKA_ID_SEEKPREROLL 0x56BB -#define MATROSKA_ID_TRACKNAME 0x536E -#define MATROSKA_ID_TRACKLANGUAGE 0x22B59C -#define MATROSKA_ID_TRACKFLAGENABLED 0xB9 -#define MATROSKA_ID_TRACKFLAGDEFAULT 0x88 -#define MATROSKA_ID_TRACKFLAGFORCED 0x55AA -#define MATROSKA_ID_TRACKFLAGLACING 0x9C -#define MATROSKA_ID_TRACKMINCACHE 0x6DE7 -#define MATROSKA_ID_TRACKMAXCACHE 0x6DF8 -#define MATROSKA_ID_TRACKDEFAULTDURATION 0x23E383 -#define MATROSKA_ID_TRACKCONTENTENCODINGS 0x6D80 -#define MATROSKA_ID_TRACKCONTENTENCODING 0x6240 -#define MATROSKA_ID_TRACKTIMECODESCALE 0x23314F -#define MATROSKA_ID_TRACKMAXBLKADDID 0x55EE - -/* IDs in the trackvideo master */ -#define MATROSKA_ID_VIDEOFRAMERATE 0x2383E3 -#define MATROSKA_ID_VIDEODISPLAYWIDTH 0x54B0 -#define MATROSKA_ID_VIDEODISPLAYHEIGHT 0x54BA -#define MATROSKA_ID_VIDEOPIXELWIDTH 0xB0 -#define MATROSKA_ID_VIDEOPIXELHEIGHT 0xBA -#define MATROSKA_ID_VIDEOPIXELCROPB 0x54AA -#define MATROSKA_ID_VIDEOPIXELCROPT 0x54BB -#define MATROSKA_ID_VIDEOPIXELCROPL 0x54CC -#define MATROSKA_ID_VIDEOPIXELCROPR 0x54DD -#define MATROSKA_ID_VIDEODISPLAYUNIT 0x54B2 -#define MATROSKA_ID_VIDEOFLAGINTERLACED 0x9A -#define MATROSKA_ID_VIDEOFIELDORDER 0x9D -#define MATROSKA_ID_VIDEOSTEREOMODE 0x53B8 -#define MATROSKA_ID_VIDEOALPHAMODE 0x53C0 -#define MATROSKA_ID_VIDEOASPECTRATIO 0x54B3 -#define MATROSKA_ID_VIDEOCOLORSPACE 0x2EB524 -#define MATROSKA_ID_VIDEOCOLOR 0x55B0 - -#define MATROSKA_ID_VIDEOCOLORMATRIXCOEFF 0x55B1 -#define MATROSKA_ID_VIDEOCOLORBITSPERCHANNEL 0x55B2 -#define MATROSKA_ID_VIDEOCOLORCHROMASUBHORZ 0x55B3 -#define MATROSKA_ID_VIDEOCOLORCHROMASUBVERT 0x55B4 -#define MATROSKA_ID_VIDEOCOLORCBSUBHORZ 0x55B5 -#define MATROSKA_ID_VIDEOCOLORCBSUBVERT 0x55B6 -#define MATROSKA_ID_VIDEOCOLORCHROMASITINGHORZ 0x55B7 -#define MATROSKA_ID_VIDEOCOLORCHROMASITINGVERT 0x55B8 -#define MATROSKA_ID_VIDEOCOLORRANGE 0x55B9 -#define MATROSKA_ID_VIDEOCOLORTRANSFERCHARACTERISTICS 0x55BA - -#define MATROSKA_ID_VIDEOCOLORPRIMARIES 0x55BB -#define MATROSKA_ID_VIDEOCOLORMAXCLL 0x55BC -#define MATROSKA_ID_VIDEOCOLORMAXFALL 0x55BD - -#define MATROSKA_ID_VIDEOCOLORMASTERINGMETA 0x55D0 -#define MATROSKA_ID_VIDEOCOLOR_RX 0x55D1 -#define MATROSKA_ID_VIDEOCOLOR_RY 0x55D2 -#define MATROSKA_ID_VIDEOCOLOR_GX 0x55D3 -#define MATROSKA_ID_VIDEOCOLOR_GY 0x55D4 -#define MATROSKA_ID_VIDEOCOLOR_BX 0x55D5 -#define MATROSKA_ID_VIDEOCOLOR_BY 0x55D6 -#define MATROSKA_ID_VIDEOCOLOR_WHITEX 0x55D7 -#define MATROSKA_ID_VIDEOCOLOR_WHITEY 0x55D8 -#define MATROSKA_ID_VIDEOCOLOR_LUMINANCEMAX 0x55D9 -#define MATROSKA_ID_VIDEOCOLOR_LUMINANCEMIN 0x55D
[FFmpeg-devel] [PATCH 07/14] avformat/matroskadec: fix the type of the TrackLanguage
From: Steve Lhomme
It's an ASCII string, not a UTF-8 string.
---
libavformat/matroskadec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 4d7fdab99f..383869bced 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -554,7 +554,7 @@ static EbmlSyntax matroska_track[] = {
{ MATROSKA_ID_CODECID, EBML_STR, 0,
offsetof(MatroskaTrack, codec_id) },
{ MATROSKA_ID_CODECPRIVATE, EBML_BIN, 0,
offsetof(MatroskaTrack, codec_priv) },
{ MATROSKA_ID_CODECDELAY,EBML_UINT, 0,
offsetof(MatroskaTrack, codec_delay) },
-{ MATROSKA_ID_TRACKLANGUAGE, EBML_UTF8, 0,
offsetof(MatroskaTrack, language), { .s = "eng" } },
+{ MATROSKA_ID_TRACKLANGUAGE, EBML_STR, 0,
offsetof(MatroskaTrack, language), { .s = "eng" } },
{ MATROSKA_ID_TRACKDEFAULTDURATION, EBML_UINT, 0,
offsetof(MatroskaTrack, default_duration) },
{ MATROSKA_ID_TRACKTIMECODESCALE,EBML_FLOAT, 0,
offsetof(MatroskaTrack, time_scale), { .f = 1.0 } },
{ MATROSKA_ID_TRACKFLAGDEFAULT, EBML_UINT, 0,
offsetof(MatroskaTrack, flag_default), { .u = 1 } },
--
2.18.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 06/14] avformat:matroska_ids: reorder some IDs to match the generated order
From: Steve Lhomme The XSLT scripts produces a similar file to this one, minus some spacing differences. No value added/removed. --- libavformat/matroska_ids.h | 70 +++--- 1 file changed, 35 insertions(+), 35 deletions(-) diff --git a/libavformat/matroska_ids.h b/libavformat/matroska_ids.h index ab77228da5..321e555bec 100644 --- a/libavformat/matroska_ids.h +++ b/libavformat/matroska_ids.h @@ -60,6 +60,8 @@ #define MATROSKA_ID_TRACKOPERATION 0xE2 #define MATROSKA_ID_TRACKTIMECODESCALE 0x23314F #define MATROSKA_ID_TRACKMAXBLKADDID 0x55EE +#define MATROSKA_ID_TRACKNAME 0x536E +#define MATROSKA_ID_TRACKLANGUAGE 0x22B59C #define MATROSKA_ID_CODECID0x86 #define MATROSKA_ID_CODECPRIVATE 0x63A2 #define MATROSKA_ID_CODECNAME 0x258688 @@ -68,8 +70,6 @@ #define MATROSKA_ID_CODECDECODEALL 0xAA #define MATROSKA_ID_CODECDELAY 0x56AA #define MATROSKA_ID_SEEKPREROLL 0x56BB -#define MATROSKA_ID_TRACKNAME 0x536E -#define MATROSKA_ID_TRACKLANGUAGE 0x22B59C #define MATROSKA_ID_TRACKFLAGENABLED 0xB9 #define MATROSKA_ID_TRACKFLAGDEFAULT 0x88 #define MATROSKA_ID_TRACKFLAGFORCED 0x55AA @@ -82,6 +82,26 @@ /* IDs in the contentencodings master */ #define MATROSKA_ID_TRACKCONTENTENCODING 0x6240 +/* IDs in the content encoding master */ +#define MATROSKA_ID_ENCODINGORDER 0x5031 +#define MATROSKA_ID_ENCODINGSCOPE 0x5032 +#define MATROSKA_ID_ENCODINGTYPE 0x5033 +#define MATROSKA_ID_ENCODINGCOMPRESSION 0x5034 +#define MATROSKA_ID_ENCODINGENCRYPTION 0x5035 + +/* IDs in the contentcompression master */ +#define MATROSKA_ID_ENCODINGCOMPALGO 0x4254 +#define MATROSKA_ID_ENCODINGCOMPSETTINGS 0x4255 + +/* IDs in the contentencryption master */ +#define MATROSKA_ID_ENCODINGENCAESSETTINGS 0x47E7 +#define MATROSKA_ID_ENCODINGENCALGO 0x47E1 +#define MATROSKA_ID_ENCODINGENCKEYID 0x47E2 +#define MATROSKA_ID_ENCODINGSIGALGO 0x47E5 +#define MATROSKA_ID_ENCODINGSIGHASHALGO 0x47E6 +#define MATROSKA_ID_ENCODINGSIGKEYID 0x47E4 +#define MATROSKA_ID_ENCODINGSIGNATURE 0x47E3 + /* IDs in the trackoperation master */ #define MATROSKA_ID_TRACKCOMBINEPLANES 0xE3 @@ -153,26 +173,6 @@ #define MATROSKA_ID_AUDIOBITDEPTH 0x6264 #define MATROSKA_ID_AUDIOCHANNELS 0x9F -/* IDs in the content encoding master */ -#define MATROSKA_ID_ENCODINGORDER 0x5031 -#define MATROSKA_ID_ENCODINGSCOPE 0x5032 -#define MATROSKA_ID_ENCODINGTYPE 0x5033 -#define MATROSKA_ID_ENCODINGCOMPRESSION 0x5034 -#define MATROSKA_ID_ENCODINGENCRYPTION 0x5035 - -/* IDs in the contentcompression master */ -#define MATROSKA_ID_ENCODINGCOMPALGO 0x4254 -#define MATROSKA_ID_ENCODINGCOMPSETTINGS 0x4255 - -/* IDs in the contentencryption master */ -#define MATROSKA_ID_ENCODINGENCAESSETTINGS 0x47E7 -#define MATROSKA_ID_ENCODINGENCALGO 0x47E1 -#define MATROSKA_ID_ENCODINGENCKEYID 0x47E2 -#define MATROSKA_ID_ENCODINGSIGALGO 0x47E5 -#define MATROSKA_ID_ENCODINGSIGHASHALGO 0x47E6 -#define MATROSKA_ID_ENCODINGSIGKEYID 0x47E4 -#define MATROSKA_ID_ENCODINGSIGNATURE 0x47E3 - /* ID in the cues master */ #define MATROSKA_ID_POINTENTRY 0xBB @@ -208,12 +208,15 @@ #define MATROSKA_ID_TAGTARGETS_CHAPTERUID 0x63C4 #define MATROSKA_ID_TAGTARGETS_ATTACHUID 0x63C6 -/* IDs in the seekhead master */ -#define MATROSKA_ID_SEEKENTRY 0x4DBB +/* IDs in the attachments master */ +#define MATROSKA_ID_ATTACHEDFILE0x61A7 -/* IDs in the seekpoint master */ -#define MATROSKA_ID_SEEKID 0x53AB -#define MATROSKA_ID_SEEKPOSITION 0x53AC +/* IDs in the attachedfile master */ +#define MATROSKA_ID_FILEDESC0x467E +#define MATROSKA_ID_FILENAME0x466E +#define MATROSKA_ID_FILEMIMETYPE0x4660 +#define MATROSKA_ID_FILEDATA0x465C +#define MATROSKA_ID_FILEUID 0x46AE /* IDs in the cluster master */ #define MATROSKA_ID_CLUSTERTIMECODE 0xE7 @@ -237,15 +240,12 @@ #define MATROSKA_ID_BLOCKADDID 0xEE #define MATROSKA_ID_BLOCKADDITIONAL 0xA5 -/* IDs in the attachments master */ -#define MATROSKA_ID_ATTACHEDFILE0x61A7 +/* IDs in the seekhead master */ +#define MATROSKA_ID_SEEKENTRY 0x4DBB -/* IDs in the attachedfile master */ -#define MATROSKA_ID_FILEDESC0x467E -#define MATROSKA_ID_FILENAME0x466E -#define MATROSKA_ID_FILEMIMETYPE0x4660 -#define MATROSKA_ID_FILEDATA0x465C -#define MATROSKA_ID_FILEUID 0x46AE +/* IDs in the seekpoint master */ +#define MATROSKA_ID_SEEKID 0x53AB +#define MATROSKA_ID_SEEKPOSITION 0x53AC /* IDs in the chapters master */ #define MATROSKA_ID_EDITIONENTRY0x45B9 -- 2.18.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 02/14] avformat/matroska: clean the structure formatting
From: Steve Lhomme
Always use a comma at the end, order elements by value.
---
libavformat/matroska.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroska.h b/libavformat/matroska.h
index 9e33e51c94..e177cd027f 100644
--- a/libavformat/matroska.h
+++ b/libavformat/matroska.h
@@ -286,13 +286,13 @@ typedef enum {
typedef enum {
MATROSKA_VIDEO_INTERLACE_FLAG_UNDETERMINED = 0,
MATROSKA_VIDEO_INTERLACE_FLAG_INTERLACED = 1,
-MATROSKA_VIDEO_INTERLACE_FLAG_PROGRESSIVE = 2
+MATROSKA_VIDEO_INTERLACE_FLAG_PROGRESSIVE = 2,
} MatroskaVideoInterlaceFlag;
typedef enum {
MATROSKA_VIDEO_FIELDORDER_PROGRESSIVE = 0,
-MATROSKA_VIDEO_FIELDORDER_UNDETERMINED = 2,
MATROSKA_VIDEO_FIELDORDER_TT = 1,
+MATROSKA_VIDEO_FIELDORDER_UNDETERMINED = 2,
MATROSKA_VIDEO_FIELDORDER_BB = 6,
MATROSKA_VIDEO_FIELDORDER_TB = 9,
MATROSKA_VIDEO_FIELDORDER_BT = 14,
--
2.18.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 03/14] avformat/matroska: use more consistent spacing in enums
From: Steve Lhomme
---
libavformat/matroska.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavformat/matroska.h b/libavformat/matroska.h
index e177cd027f..5520e9ce8f 100644
--- a/libavformat/matroska.h
+++ b/libavformat/matroska.h
@@ -284,18 +284,18 @@ typedef enum {
} MatroskaTrackEncodingCompAlgo;
typedef enum {
-MATROSKA_VIDEO_INTERLACE_FLAG_UNDETERMINED = 0,
-MATROSKA_VIDEO_INTERLACE_FLAG_INTERLACED = 1,
-MATROSKA_VIDEO_INTERLACE_FLAG_PROGRESSIVE = 2,
+ MATROSKA_VIDEO_INTERLACE_FLAG_UNDETERMINED = 0,
+ MATROSKA_VIDEO_INTERLACE_FLAG_INTERLACED = 1,
+ MATROSKA_VIDEO_INTERLACE_FLAG_PROGRESSIVE = 2,
} MatroskaVideoInterlaceFlag;
typedef enum {
-MATROSKA_VIDEO_FIELDORDER_PROGRESSIVE = 0,
-MATROSKA_VIDEO_FIELDORDER_TT = 1,
-MATROSKA_VIDEO_FIELDORDER_UNDETERMINED = 2,
-MATROSKA_VIDEO_FIELDORDER_BB = 6,
-MATROSKA_VIDEO_FIELDORDER_TB = 9,
-MATROSKA_VIDEO_FIELDORDER_BT = 14,
+ MATROSKA_VIDEO_FIELDORDER_PROGRESSIVE = 0,
+ MATROSKA_VIDEO_FIELDORDER_TT = 1,
+ MATROSKA_VIDEO_FIELDORDER_UNDETERMINED = 2,
+ MATROSKA_VIDEO_FIELDORDER_BB = 6,
+ MATROSKA_VIDEO_FIELDORDER_TB = 9,
+ MATROSKA_VIDEO_FIELDORDER_BT = 14,
} MatroskaVideoFieldOrder;
typedef enum {
--
2.18.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 01/14] avformat/matroska: add missing Buttons track type
From: Steve Lhomme
---
libavformat/matroska.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/matroska.h b/libavformat/matroska.h
index 86968a8de1..9e33e51c94 100644
--- a/libavformat/matroska.h
+++ b/libavformat/matroska.h
@@ -271,6 +271,7 @@ typedef enum {
MATROSKA_TRACK_TYPE_COMPLEX = 0x3,
MATROSKA_TRACK_TYPE_LOGO = 0x10,
MATROSKA_TRACK_TYPE_SUBTITLE = 0x11,
+ MATROSKA_TRACK_TYPE_BUTTONS = 0x12,
MATROSKA_TRACK_TYPE_CONTROL = 0x20,
MATROSKA_TRACK_TYPE_METADATA = 0x21,
} MatroskaTrackType;
--
2.18.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/3] avcodec/dxva2_hevc: add support for parsing HEVC Range Extension data
On 2020-03-15 13:05, Hendrik Leppkes wrote: On Sun, Mar 15, 2020 at 8:12 AM Steve Lhomme wrote: Where is this struct specified? I don't see it in the latest released Windows SDK. It is not. It is reversed engineered from the existing structure and wild guessing based on the HEVC Range Extension specs. The bits/fields are in the same order as the specs. Then I tested some GUIDs that output non 4:2:0 pixel formats on an Intel GPU that is known to decoder HEVC Range Extension. Apparently NVIDIA doesn't provide DXVA GUIDs that output non 4:2:0 pixel formats on GPUs that supposedly decode HEVC 444 (likley nvdec only). AMD doesn't have such GPUs AFAIK. So for now it's Intel only. That seems very hackish for something thats otherwise cleanly based on official specifications only. Maybe try to get them to release specs for this instead? From what I understand only MS publishes DXVA specs and it seems they have no intention on doing one for HEVC Range Extension. That may be why NVIDIA has not implemented it. I don't know if Intel is planning to release a documentation. ___ 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] avcodec/dxva2_hevc: add support for parsing HEVC Range Extension data
> On March 13, 2020 3:46 PM Hendrik Leppkes wrote:
>
>
> On Fri, Mar 13, 2020 at 11:25 AM Steve Lhomme wrote:
> >
> > Mimick the existing structure and add the extra fields from the Range
> > Extension
> > in a wrapping structure.
> >
> > The FF_DXVA2_WORKAROUND_HEVC_REXT is set by the decoder user to signal the
> > selected decoder is expecting this extended structure rather than the
> > default
> > one.
> > ---
> > libavcodec/d3d11va.h| 1 +
> > libavcodec/dxva2.h | 1 +
> > libavcodec/dxva2_hevc.c | 79 ++---
> > 3 files changed, 76 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavcodec/d3d11va.h b/libavcodec/d3d11va.h
> > index 6816b6c1e6..68a69c372d 100644
> > --- a/libavcodec/d3d11va.h
> > +++ b/libavcodec/d3d11va.h
> > @@ -47,6 +47,7 @@
> >
> > #define FF_DXVA2_WORKAROUND_SCALING_LIST_ZIGZAG 1 ///< Work around for
> > Direct3D11 and old UVD/UVD+ ATI video cards
> > #define FF_DXVA2_WORKAROUND_INTEL_CLEARVIDEO2 ///< Work around for
> > Direct3D11 and old Intel GPUs with ClearVideo interface
> > +#define FF_DXVA2_WORKAROUND_HEVC_REXT 4 ///< Signal the D3D11VA
> > decoder is using the HEVC Rext picture structure
> >
> > /**
> > * This structure is used to provides the necessary configurations and data
> > diff --git a/libavcodec/dxva2.h b/libavcodec/dxva2.h
> > index 22c93992f2..024999239d 100644
> > --- a/libavcodec/dxva2.h
> > +++ b/libavcodec/dxva2.h
> > @@ -47,6 +47,7 @@
> >
> > #define FF_DXVA2_WORKAROUND_SCALING_LIST_ZIGZAG 1 ///< Work around for
> > DXVA2 and old UVD/UVD+ ATI video cards
> > #define FF_DXVA2_WORKAROUND_INTEL_CLEARVIDEO2 ///< Work around for
> > DXVA2 and old Intel GPUs with ClearVideo interface
> > +#define FF_DXVA2_WORKAROUND_HEVC_REXT 4 ///< Signal the DXVA2
> > decoder is using the HEVC Rext picture structure
> >
> > /**
> > * This structure is used to provides the necessary configurations and data
> > diff --git a/libavcodec/dxva2_hevc.c b/libavcodec/dxva2_hevc.c
> > index dbb701fb1c..98b3e74bd7 100644
> > --- a/libavcodec/dxva2_hevc.c
> > +++ b/libavcodec/dxva2_hevc.c
> > @@ -26,10 +26,47 @@
> > #include "hevc_data.h"
> > #include "hevcdec.h"
> >
> > +#pragma pack(push, 1)
> > +typedef struct
> > +{
> > +DXVA_PicParams_HEVC main;
> > +
> > +// HEVC Range Extension
> > +__C89_NAMELESS union {
> > +__C89_NAMELESS struct {
> > +UINT32 transform_skip_rotation_enabled_flag : 1;
> > +UINT32 transform_skip_context_enabled_flag : 1;
> > +UINT32 implicit_rdpcm_enabled_flag : 1;
> > +UINT32 explicit_rdpcm_enabled_flag : 1;
> > +UINT32 extended_precision_processing_flag : 1;
> > +UINT32 intra_smoothing_disabled_flag : 1;
> > +UINT32 high_precision_offsets_enabled_flag : 1;
> > +UINT32 persistent_rice_adaptation_enabled_flag : 1;
> > +UINT32 cabac_bypass_alignment_enabled_flag : 1;
> > +UINT32 cross_component_prediction_enabled_flag : 1;
> > +UINT32 chroma_qp_offset_list_enabled_flag : 1;
> > +UINT32 BitDepthLuma16 : 1; // TODO merge in ReservedBits5 if
> > not needed
> > +UINT32 BitDepthChroma16 : 1; // TODO merge in ReservedBits5 if
> > not needed
> > +UINT32 ReservedBits8 : 19;
> > +};
> > +UINT32 dwRangeExtensionFlags;
> > +};
> > +
> > +UCHAR diff_cu_chroma_qp_offset_depth;
> > +UCHAR chroma_qp_offset_list_len_minus1;
> > +UCHAR log2_sao_offset_scale_luma;
> > +UCHAR log2_sao_offset_scale_chroma;
> > +UCHAR log2_max_transform_skip_block_size_minus2;
> > +CHAR cb_qp_offset_list[6];
> > +CHAR cr_qp_offset_list[6];
> > +
> > +} DXVA_PicParams_HEVC_Rext;
> > +#pragma pack(pop)
> > +
>
> Where is this struct specified? I don't see it in the latest released
> Windows SDK.
It is not. It is reversed engineered from the existing structure and wild
guessing based on the HEVC Range Extension specs. The bits/fields are in the
same order as the specs. Then I tested some GUIDs that output non 4:2:0 pixel
formats on an Intel GPU that is known to decoder HEVC Range Extension.
Apparently NVIDIA doesn't provide DXVA GUIDs that output non 4:2:0 pixel
formats on GPUs that supposedly decode HEVC 444 (likley nvdec only). AMD
doesn't have such GPUs AFAIK.
So for now it's Intel only.
___
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/3] avcodec/dxva2_hevc: add support for parsing HEVC Range Extension data
Mimick the existing structure and add the extra fields from the Range Extension
in a wrapping structure.
The FF_DXVA2_WORKAROUND_HEVC_REXT is set by the decoder user to signal the
selected decoder is expecting this extended structure rather than the default
one.
---
libavcodec/d3d11va.h| 1 +
libavcodec/dxva2.h | 1 +
libavcodec/dxva2_hevc.c | 79 ++---
3 files changed, 76 insertions(+), 5 deletions(-)
diff --git a/libavcodec/d3d11va.h b/libavcodec/d3d11va.h
index 6816b6c1e6..68a69c372d 100644
--- a/libavcodec/d3d11va.h
+++ b/libavcodec/d3d11va.h
@@ -47,6 +47,7 @@
#define FF_DXVA2_WORKAROUND_SCALING_LIST_ZIGZAG 1 ///< Work around for
Direct3D11 and old UVD/UVD+ ATI video cards
#define FF_DXVA2_WORKAROUND_INTEL_CLEARVIDEO2 ///< Work around for
Direct3D11 and old Intel GPUs with ClearVideo interface
+#define FF_DXVA2_WORKAROUND_HEVC_REXT 4 ///< Signal the D3D11VA
decoder is using the HEVC Rext picture structure
/**
* This structure is used to provides the necessary configurations and data
diff --git a/libavcodec/dxva2.h b/libavcodec/dxva2.h
index 22c93992f2..024999239d 100644
--- a/libavcodec/dxva2.h
+++ b/libavcodec/dxva2.h
@@ -47,6 +47,7 @@
#define FF_DXVA2_WORKAROUND_SCALING_LIST_ZIGZAG 1 ///< Work around for DXVA2
and old UVD/UVD+ ATI video cards
#define FF_DXVA2_WORKAROUND_INTEL_CLEARVIDEO2 ///< Work around for DXVA2
and old Intel GPUs with ClearVideo interface
+#define FF_DXVA2_WORKAROUND_HEVC_REXT 4 ///< Signal the DXVA2
decoder is using the HEVC Rext picture structure
/**
* This structure is used to provides the necessary configurations and data
diff --git a/libavcodec/dxva2_hevc.c b/libavcodec/dxva2_hevc.c
index dbb701fb1c..98b3e74bd7 100644
--- a/libavcodec/dxva2_hevc.c
+++ b/libavcodec/dxva2_hevc.c
@@ -26,10 +26,47 @@
#include "hevc_data.h"
#include "hevcdec.h"
+#pragma pack(push, 1)
+typedef struct
+{
+DXVA_PicParams_HEVC main;
+
+// HEVC Range Extension
+__C89_NAMELESS union {
+__C89_NAMELESS struct {
+UINT32 transform_skip_rotation_enabled_flag : 1;
+UINT32 transform_skip_context_enabled_flag : 1;
+UINT32 implicit_rdpcm_enabled_flag : 1;
+UINT32 explicit_rdpcm_enabled_flag : 1;
+UINT32 extended_precision_processing_flag : 1;
+UINT32 intra_smoothing_disabled_flag : 1;
+UINT32 high_precision_offsets_enabled_flag : 1;
+UINT32 persistent_rice_adaptation_enabled_flag : 1;
+UINT32 cabac_bypass_alignment_enabled_flag : 1;
+UINT32 cross_component_prediction_enabled_flag : 1;
+UINT32 chroma_qp_offset_list_enabled_flag : 1;
+UINT32 BitDepthLuma16 : 1; // TODO merge in ReservedBits5 if not
needed
+UINT32 BitDepthChroma16 : 1; // TODO merge in ReservedBits5 if not
needed
+UINT32 ReservedBits8 : 19;
+};
+UINT32 dwRangeExtensionFlags;
+};
+
+UCHAR diff_cu_chroma_qp_offset_depth;
+UCHAR chroma_qp_offset_list_len_minus1;
+UCHAR log2_sao_offset_scale_luma;
+UCHAR log2_sao_offset_scale_chroma;
+UCHAR log2_max_transform_skip_block_size_minus2;
+CHAR cb_qp_offset_list[6];
+CHAR cr_qp_offset_list[6];
+
+} DXVA_PicParams_HEVC_Rext;
+#pragma pack(pop)
+
#define MAX_SLICES 256
struct hevc_dxva2_picture_context {
-DXVA_PicParams_HEVC pp;
+DXVA_PicParams_HEVC_Rext pp;
DXVA_Qmatrix_HEVC qm;
unsigned slice_count;
DXVA_Slice_HEVC_Short slice_short[MAX_SLICES];
@@ -55,18 +92,48 @@ static int get_refpic_index(const DXVA_PicParams_HEVC *pp,
int surface_index)
}
static void fill_picture_parameters(const AVCodecContext *avctx, AVDXVAContext
*ctx, const HEVCContext *h,
-DXVA_PicParams_HEVC *pp)
+DXVA_PicParams_HEVC_Rext *ppext)
{
const HEVCFrame *current_picture = h->ref;
const HEVCSPS *sps = h->ps.sps;
const HEVCPPS *pps = h->ps.pps;
int i, j;
+DXVA_PicParams_HEVC *pp = >main;
-memset(pp, 0, sizeof(*pp));
+memset(ppext, 0, sizeof(*ppext));
pp->PicWidthInMinCbsY = sps->min_cb_width;
pp->PicHeightInMinCbsY = sps->min_cb_height;
+if (sps->sps_range_extension_flag) {
+ppext->dwRangeExtensionFlags |=
(sps->transform_skip_rotation_enabled_flag << 0) |
+
(sps->transform_skip_context_enabled_flag << 1) |
+(sps->implicit_rdpcm_enabled_flag
<< 2) |
+(sps->explicit_rdpcm_enabled_flag
<< 3) |
+
(sps->extended_precision_processing_flag << 4) |
+(sps->intra_smoothing_disabled_flag
<< 5) |
+
[FFmpeg-devel] [PATCH 3/3] avcodec/hevcdec: allow HEVC 422 10/12 bits decoding with DXVA2/D3D11VA
--- libavcodec/hevcdec.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c index 04496a002b..4c1650c416 100644 --- a/libavcodec/hevcdec.c +++ b/libavcodec/hevcdec.c @@ -432,6 +432,16 @@ static enum AVPixelFormat get_format(HEVCContext *s, const HEVCSPS *sps) #endif #if CONFIG_HEVC_NVDEC_HWACCEL *fmt++ = AV_PIX_FMT_CUDA; +#endif +break; +case AV_PIX_FMT_YUV422P10: +case AV_PIX_FMT_YUV422P12: +#if CONFIG_HEVC_DXVA2_HWACCEL +*fmt++ = AV_PIX_FMT_DXVA2_VLD; +#endif +#if CONFIG_HEVC_D3D11VA_HWACCEL +*fmt++ = AV_PIX_FMT_D3D11VA_VLD; +*fmt++ = AV_PIX_FMT_D3D11; #endif break; case AV_PIX_FMT_YUV420P12: -- 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".
[FFmpeg-devel] [PATCH 2/3] avcodec/hevcdec: allow HEVC 444 8/10/12 bits decoding with DXVA2/D3D11VA
And 4:2:0 12 bits as well. --- libavcodec/hevcdec.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c index 8f1c162ace..04496a002b 100644 --- a/libavcodec/hevcdec.c +++ b/libavcodec/hevcdec.c @@ -420,6 +420,13 @@ static enum AVPixelFormat get_format(HEVCContext *s, const HEVCSPS *sps) #endif break; case AV_PIX_FMT_YUV444P: +#if CONFIG_HEVC_DXVA2_HWACCEL +*fmt++ = AV_PIX_FMT_DXVA2_VLD; +#endif +#if CONFIG_HEVC_D3D11VA_HWACCEL +*fmt++ = AV_PIX_FMT_D3D11VA_VLD; +*fmt++ = AV_PIX_FMT_D3D11; +#endif #if CONFIG_HEVC_VDPAU_HWACCEL *fmt++ = AV_PIX_FMT_VDPAU; #endif @@ -430,6 +437,13 @@ static enum AVPixelFormat get_format(HEVCContext *s, const HEVCSPS *sps) case AV_PIX_FMT_YUV420P12: case AV_PIX_FMT_YUV444P10: case AV_PIX_FMT_YUV444P12: +#if CONFIG_HEVC_DXVA2_HWACCEL +*fmt++ = AV_PIX_FMT_DXVA2_VLD; +#endif +#if CONFIG_HEVC_D3D11VA_HWACCEL +*fmt++ = AV_PIX_FMT_D3D11VA_VLD; +*fmt++ = AV_PIX_FMT_D3D11; +#endif #if CONFIG_HEVC_NVDEC_HWACCEL *fmt++ = AV_PIX_FMT_CUDA; #endif -- 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".
[FFmpeg-devel] [PATCH] dxva2: debug the mismatching buffer sizes
---
libavcodec/dxva2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 32416112bf..6add893f3e 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -840,7 +840,7 @@ int ff_dxva2_commit_buffer(AVCodecContext *avctx,
result = 0;
} else {
-av_log(avctx, AV_LOG_ERROR, "Buffer for type %u was too small\n",
type);
+av_log(avctx, AV_LOG_ERROR, "Buffer for type %u was too small (got %u,
need %u)\n", type, dxva_size, size);
result = -1;
}
--
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".
[FFmpeg-devel] [PATCH] avcodec/pthread_frame: do not give the hardware context internals to the user
The internal data should not leak to the user. It can potentially be destroyed
twice since the hwaccel uninit was also copied back to the user.
This behaviour may only be found in VLC which uses frame threading with hardware
decoding.
---
libavcodec/pthread_frame.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 36ac0ac1e5..2150b4e048 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -275,14 +275,17 @@ static int update_context_from_thread(AVCodecContext
*dst, AVCodecContext *src,
dst->color_range = src->color_range;
dst->chroma_sample_location = src->chroma_sample_location;
-dst->hwaccel = src->hwaccel;
-dst->hwaccel_context = src->hwaccel_context;
+if (!for_user) {
+dst->hwaccel = src->hwaccel;
+dst->hwaccel_context = src->hwaccel_context;
+}
dst->channels = src->channels;
dst->sample_rate= src->sample_rate;
dst->sample_fmt = src->sample_fmt;
dst->channel_layout = src->channel_layout;
-dst->internal->hwaccel_priv_data = src->internal->hwaccel_priv_data;
+if (!for_user)
+dst->internal->hwaccel_priv_data =
src->internal->hwaccel_priv_data;
if (!!dst->hw_frames_ctx != !!src->hw_frames_ctx ||
(dst->hw_frames_ctx && dst->hw_frames_ctx->data !=
src->hw_frames_ctx->data)) {
--
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 NV HEADERS] Add cuCtxGetDevice
On 2019-09-13 11:56, Timo Rothenpieler wrote: On 12/09/2019 15:19, Steve Lhomme wrote: It can be useful to determine if the decoder context is the same as the display context. It's used in some samples at https://github.com/NVIDIA/video-sdk-samples --- include/ffnvcodec/dynlink_cuda.h | 1 + include/ffnvcodec/dynlink_loader.h | 2 ++ 2 files changed, 3 insertions(+) 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". ___ 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 NV HEADERS] allow overriding the PREFIX from the environment
Ah yes, it works (TIL). Forget about this patch. On 2019-09-12 16:26, Timo Rothenpieler wrote: On 12/09/2019 15:17, Steve Lhomme wrote: --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index a51c2c9..c3a9209 100644 --- a/Makefile +++ b/Makefile @@ -1,4 +1,4 @@ -PREFIX = /usr/local +PREFIX ?= /usr/local Overriding the prefix worked just fine last time I tested it. You do make install PREFIX=... LIBDIR = lib INSTALL = install SED = sed ___ 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 NV HEADERS] Add cuCtxGetDevice
This is for this repo:
https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git
On 2019-09-12 15:19, Steve Lhomme wrote:
It can be useful to determine if the decoder context is the same as the display
context.
It's used in some samples at https://github.com/NVIDIA/video-sdk-samples
---
include/ffnvcodec/dynlink_cuda.h | 1 +
include/ffnvcodec/dynlink_loader.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/include/ffnvcodec/dynlink_cuda.h b/include/ffnvcodec/dynlink_cuda.h
index ad5da7c..cc1cc00 100644
--- a/include/ffnvcodec/dynlink_cuda.h
+++ b/include/ffnvcodec/dynlink_cuda.h
@@ -329,6 +329,7 @@ typedef CUresult CUDAAPI tcuMemcpy2D_v2(const CUDA_MEMCPY2D
*pcopy);
typedef CUresult CUDAAPI tcuMemcpy2DAsync_v2(const CUDA_MEMCPY2D *pcopy,
CUstream hStream);
typedef CUresult CUDAAPI tcuGetErrorName(CUresult error, const char** pstr);
typedef CUresult CUDAAPI tcuGetErrorString(CUresult error, const char** pstr);
+typedef CUresult CUDAAPI tcuCtxGetDevice(CUdevice *device);
typedef CUresult CUDAAPI tcuStreamCreate(CUstream *phStream, unsigned int flags);
typedef CUresult CUDAAPI tcuStreamQuery(CUstream hStream);
diff --git a/include/ffnvcodec/dynlink_loader.h
b/include/ffnvcodec/dynlink_loader.h
index 358acd5..a1fa323 100644
--- a/include/ffnvcodec/dynlink_loader.h
+++ b/include/ffnvcodec/dynlink_loader.h
@@ -156,6 +156,7 @@ typedef struct CudaFunctions {
tcuMemcpy2DAsync_v2 *cuMemcpy2DAsync;
tcuGetErrorName *cuGetErrorName;
tcuGetErrorString *cuGetErrorString;
+tcuCtxGetDevice *cuCtxGetDevice;
tcuStreamCreate *cuStreamCreate;
tcuStreamQuery *cuStreamQuery;
@@ -280,6 +281,7 @@ static inline int cuda_load_functions(CudaFunctions
**functions, void *logctx)
LOAD_SYMBOL(cuMemcpy2DAsync, tcuMemcpy2DAsync_v2, "cuMemcpy2DAsync_v2");
LOAD_SYMBOL(cuGetErrorName, tcuGetErrorName, "cuGetErrorName");
LOAD_SYMBOL(cuGetErrorString, tcuGetErrorString, "cuGetErrorString");
+LOAD_SYMBOL(cuCtxGetDevice, tcuCtxGetDevice, "cuCtxGetDevice");
LOAD_SYMBOL(cuStreamCreate, tcuStreamCreate, "cuStreamCreate");
LOAD_SYMBOL(cuStreamQuery, tcuStreamQuery, "cuStreamQuery");
--
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".
___
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 NV HEADERS] allow overriding the PREFIX from the environment
This is for this repo: https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git On 2019-09-12 15:17, Steve Lhomme wrote: --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index a51c2c9..c3a9209 100644 --- a/Makefile +++ b/Makefile @@ -1,4 +1,4 @@ -PREFIX = /usr/local +PREFIX ?= /usr/local LIBDIR = lib INSTALL = install SED = sed -- 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". ___ 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 NV HEADERS] Add cuCtxGetDevice
It can be useful to determine if the decoder context is the same as the display
context.
It's used in some samples at https://github.com/NVIDIA/video-sdk-samples
---
include/ffnvcodec/dynlink_cuda.h | 1 +
include/ffnvcodec/dynlink_loader.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/include/ffnvcodec/dynlink_cuda.h b/include/ffnvcodec/dynlink_cuda.h
index ad5da7c..cc1cc00 100644
--- a/include/ffnvcodec/dynlink_cuda.h
+++ b/include/ffnvcodec/dynlink_cuda.h
@@ -329,6 +329,7 @@ typedef CUresult CUDAAPI tcuMemcpy2D_v2(const CUDA_MEMCPY2D
*pcopy);
typedef CUresult CUDAAPI tcuMemcpy2DAsync_v2(const CUDA_MEMCPY2D *pcopy,
CUstream hStream);
typedef CUresult CUDAAPI tcuGetErrorName(CUresult error, const char** pstr);
typedef CUresult CUDAAPI tcuGetErrorString(CUresult error, const char** pstr);
+typedef CUresult CUDAAPI tcuCtxGetDevice(CUdevice *device);
typedef CUresult CUDAAPI tcuStreamCreate(CUstream *phStream, unsigned int
flags);
typedef CUresult CUDAAPI tcuStreamQuery(CUstream hStream);
diff --git a/include/ffnvcodec/dynlink_loader.h
b/include/ffnvcodec/dynlink_loader.h
index 358acd5..a1fa323 100644
--- a/include/ffnvcodec/dynlink_loader.h
+++ b/include/ffnvcodec/dynlink_loader.h
@@ -156,6 +156,7 @@ typedef struct CudaFunctions {
tcuMemcpy2DAsync_v2 *cuMemcpy2DAsync;
tcuGetErrorName *cuGetErrorName;
tcuGetErrorString *cuGetErrorString;
+tcuCtxGetDevice *cuCtxGetDevice;
tcuStreamCreate *cuStreamCreate;
tcuStreamQuery *cuStreamQuery;
@@ -280,6 +281,7 @@ static inline int cuda_load_functions(CudaFunctions
**functions, void *logctx)
LOAD_SYMBOL(cuMemcpy2DAsync, tcuMemcpy2DAsync_v2, "cuMemcpy2DAsync_v2");
LOAD_SYMBOL(cuGetErrorName, tcuGetErrorName, "cuGetErrorName");
LOAD_SYMBOL(cuGetErrorString, tcuGetErrorString, "cuGetErrorString");
+LOAD_SYMBOL(cuCtxGetDevice, tcuCtxGetDevice, "cuCtxGetDevice");
LOAD_SYMBOL(cuStreamCreate, tcuStreamCreate, "cuStreamCreate");
LOAD_SYMBOL(cuStreamQuery, tcuStreamQuery, "cuStreamQuery");
--
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".
[FFmpeg-devel] [PATCH NV HEADERS] allow overriding the PREFIX from the environment
--- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index a51c2c9..c3a9209 100644 --- a/Makefile +++ b/Makefile @@ -1,4 +1,4 @@ -PREFIX = /usr/local +PREFIX ?= /usr/local LIBDIR = lib INSTALL = install SED = sed -- 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".
[FFmpeg-devel] [PATCH] avcodec/h264_slice: set the SEI parameters early on the AVCodecContext
It's better to do it before the buffers are actually created. At least in VLC
we currently don't support changing some parameters dynamically easily so we
don't use the information if it comes after the buffer are created.
Co-authored-by: James Almer
---
libavcodec/h264_slice.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 1c9a270fb6..5ceee107a0 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1092,6 +1092,12 @@ static int h264_init_ps(H264Context *h, const
H264SliceContext *sl, int first_sl
h->avctx->colorspace = sps->colorspace;
}
}
+
+if (h->sei.alternative_transfer.present &&
+
av_color_transfer_name(h->sei.alternative_transfer.preferred_transfer_characteristics)
&&
+h->sei.alternative_transfer.preferred_transfer_characteristics !=
AVCOL_TRC_UNSPECIFIED) {
+h->avctx->color_trc =
h->sei.alternative_transfer.preferred_transfer_characteristics;
+}
}
if (!h->context_initialized || must_reinit || needs_reinit) {
@@ -1332,12 +1338,6 @@ static int h264_export_frame_props(H264Context *h)
h->sei.picture_timing.timecode_cnt = 0;
}
-if (h->sei.alternative_transfer.present &&
-
av_color_transfer_name(h->sei.alternative_transfer.preferred_transfer_characteristics)
&&
-h->sei.alternative_transfer.preferred_transfer_characteristics !=
AVCOL_TRC_UNSPECIFIED) {
-h->avctx->color_trc = cur->f->color_trc =
h->sei.alternative_transfer.preferred_transfer_characteristics;
-}
-
return 0;
}
--
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".
[FFmpeg-devel] [PATCH v2] avcodec/hevcdec: set the SEI parameters early on the AVCodecContext
It's better to do it before the buffers are actually created. At least in VLC
we currently don't support changing some parameters dynamically easily so we
don't use the information if it comes after the buffer are created.
Co-authored-by: James Almer
---
The same problem may exist with H264 alternative_transfer but I don't have a
sample to test with and the code seems a bit different.
Compared to previous version:
- no handling of the cpation flag
- pass the HEVCContext to export_stream_params()
---
libavcodec/hevcdec.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 515b346535..f1934975d5 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -310,9 +310,10 @@ static int decode_lt_rps(HEVCContext *s, LongTermRPS *rps,
GetBitContext *gb)
return 0;
}
-static void export_stream_params(AVCodecContext *avctx, const HEVCParamSets
*ps,
- const HEVCSPS *sps)
+static void export_stream_params(HEVCContext *s, const HEVCSPS *sps)
{
+AVCodecContext *avctx = s->avctx;
+const HEVCParamSets *ps = >ps;
const HEVCVPS *vps = (const HEVCVPS*)ps->vps_list[sps->vps_id]->data;
const HEVCWindow *ow = >output_window;
unsigned int num = 0, den = 0;
@@ -355,6 +356,12 @@ static void export_stream_params(AVCodecContext *avctx,
const HEVCParamSets *ps,
if (num != 0 && den != 0)
av_reduce(>framerate.den, >framerate.num,
num, den, 1 << 30);
+
+if (s->sei.alternative_transfer.present &&
+
av_color_transfer_name(s->sei.alternative_transfer.preferred_transfer_characteristics)
&&
+s->sei.alternative_transfer.preferred_transfer_characteristics !=
AVCOL_TRC_UNSPECIFIED) {
+avctx->color_trc =
s->sei.alternative_transfer.preferred_transfer_characteristics;
+}
}
static enum AVPixelFormat get_format(HEVCContext *s, const HEVCSPS *sps)
@@ -447,7 +454,7 @@ static int set_sps(HEVCContext *s, const HEVCSPS *sps,
if (ret < 0)
goto fail;
-export_stream_params(s->avctx, >ps, sps);
+export_stream_params(s, sps);
s->avctx->pix_fmt = pix_fmt;
@@ -2778,12 +2785,6 @@ static int set_side_data(HEVCContext *s)
s->avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
}
-if (s->sei.alternative_transfer.present &&
-
av_color_transfer_name(s->sei.alternative_transfer.preferred_transfer_characteristics)
&&
-s->sei.alternative_transfer.preferred_transfer_characteristics !=
AVCOL_TRC_UNSPECIFIED) {
-s->avctx->color_trc = out->color_trc =
s->sei.alternative_transfer.preferred_transfer_characteristics;
-}
-
return 0;
}
@@ -3179,7 +3180,7 @@ static int hevc_decode_extradata(HEVCContext *s, uint8_t
*buf, int length, int f
for (i = 0; i < FF_ARRAY_ELEMS(s->ps.sps_list); i++) {
if (first && s->ps.sps_list[i]) {
const HEVCSPS *sps = (const HEVCSPS*)s->ps.sps_list[i]->data;
-export_stream_params(s->avctx, >ps, sps);
+export_stream_params(s, sps);
break;
}
}
--
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".
[FFmpeg-devel] [PATCH] avcodec/hevcdec: set the SEI parameters early on the AVCodecContext
It's better to do it before the buffers are actually created. At least in VLC
we currently don't support changing some parameters dynamically easily so we
don't use the information if it comes after the buffer are created.
Co-authored-by: James Almer
---
The same problem may exist with H264 alternative_transfer but I don't have a
sample to test with and the code seems a bit different.
---
libavcodec/hevcdec.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 515b346535..f54f46aa5d 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -313,6 +313,7 @@ static int decode_lt_rps(HEVCContext *s, LongTermRPS *rps,
GetBitContext *gb)
static void export_stream_params(AVCodecContext *avctx, const HEVCParamSets
*ps,
const HEVCSPS *sps)
{
+const HEVCContext *s = avctx->priv_data;
const HEVCVPS *vps = (const HEVCVPS*)ps->vps_list[sps->vps_id]->data;
const HEVCWindow *ow = >output_window;
unsigned int num = 0, den = 0;
@@ -355,6 +356,16 @@ static void export_stream_params(AVCodecContext *avctx,
const HEVCParamSets *ps,
if (num != 0 && den != 0)
av_reduce(>framerate.den, >framerate.num,
num, den, 1 << 30);
+
+if (s->sei.a53_caption.a53_caption) {
+avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
+}
+
+if (s->sei.alternative_transfer.present &&
+
av_color_transfer_name(s->sei.alternative_transfer.preferred_transfer_characteristics)
&&
+s->sei.alternative_transfer.preferred_transfer_characteristics !=
AVCOL_TRC_UNSPECIFIED) {
+avctx->color_trc =
s->sei.alternative_transfer.preferred_transfer_characteristics;
+}
}
static enum AVPixelFormat get_format(HEVCContext *s, const HEVCSPS *sps)
@@ -2775,13 +2786,6 @@ static int set_side_data(HEVCContext *s)
memcpy(sd->data, s->sei.a53_caption.a53_caption,
s->sei.a53_caption.a53_caption_size);
av_freep(>sei.a53_caption.a53_caption);
s->sei.a53_caption.a53_caption_size = 0;
-s->avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
-}
-
-if (s->sei.alternative_transfer.present &&
-
av_color_transfer_name(s->sei.alternative_transfer.preferred_transfer_characteristics)
&&
-s->sei.alternative_transfer.preferred_transfer_characteristics !=
AVCOL_TRC_UNSPECIFIED) {
-s->avctx->color_trc = out->color_trc =
s->sei.alternative_transfer.preferred_transfer_characteristics;
}
return 0;
--
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 00/21] New Version
> On April 7, 2019 at 8:56 PM Andreas Rheinhardt via ffmpeg-devel > wrote: > > > Hello, > > thanks for taking the time to review this. Much appreciated. > > Steve Lhomme: > > Hi, > > > > On 3/27/2019 12:18 PM, Andreas Rheinhardt wrote: > >> This also changed the handling of unknown-sized elements: They are now > >> ended whenever an element not known to be allowed in them is > >> encountered. If we are already on level 1 and encounter an element not > >> known to be allowed in an unknown-sized segment, this is treated as an > >> indication that an error might have occured. I hope this is fine. > > > > I haven't looked at the code yet, but an unknown element doesn't mean > > it's an upper level element. I think it should be either skipped or > > considered as bad data. If it's a known element but complitely > > misplaced it should not be going upper in the hierarchy. Only when a > > valid upper element it should go up in the hierarchy. > > > 1. Actually the current approach is equivalent to considering unknown > elements in an unknown-sized element as bad data: If a new ID isn't in > the current syntax list, then we treat this as an indication that the > current level ended and test with the next higher level and so on > until we arrive at level 1. If it then isn't a valid level 1 element, > then it is being treated as an error. > > 2. But as you have said (in your last mail), this approach won't work > with extensions like RAWCooked. So a check for whether an element is > from a higher level needs to be implemented and unknown elements with > finite size should be skipped. > > 3. But there are practical complications: > a) If an error occurred, then it is possible that we encounter garbage > that looks like a very big unknown element. I'd image that trying to > skip it might very well lead to problems, in particular in case of > livestreaming. So there should be a sanity check for this, i.e. very > big unknown elements should be considered as errors. In libebml when we read an element we read the ID and length at once and verify that the length is valid for that ID (based on its type) and its parent (doesn't go over the boundary if there is one). If an element is unknown (known at a different level is considered unknown) with a valid size then we either keep it as such or consider it's an error (that's a flag when reading telling which behavior we want). That's basically like choosing between a strict respect of the specs or allow extensions/customization. By default the more relaxed approach should be used in a reader, so keeping the elements as unknown. If the direct parent (Cluster) doesn't have a known size and you encounter some unknown IDs, you have no way to know if the data are correct or not. Given unknown length/live streaming already imposes restrictions on what elements are allowed, it would be OK to assume that anything outside of known elements is an error. But considering it's bad data and wait for known data would work as well. In any case you're not going to make use of the data (unlike libebml which may be used to track/report such cases) it doesn't really matter which way you decide to use. > b) And it is also possible that we encounter quite a few possibly > legal unknown elements (that are skipped) in a row. I think it's > reasonable to view this as an indication that an error occurred, too. > How long should these chains of unknown elements be for it to trigger > this error? Three? Four? Five? > c) In both cases, resyncing should begin at the last known good > position, not at the current position. You can't resync during live streaming which is what the unknown length feature is for. But then I don't know if the current demuxer code is ready for that. In VLC I had to use a stream filter disabling seeking to make sure we never try to seek during live streaming. > Do you agree with me regarding 2. and 3.? Yes, with my additional remarks. > 4. Would it actually be legal for an extension like RAWCooked to > implement new potentially unknown-sized elements? I haven't found > anything on this topic that says it is illegal, so I presume it is > legal. But it shouldn't be IMO if it wants to be an extension that can > be played by normal players (that don't know these extra elements), as > unknown-sized elements simply can't be skipped. I wouldn't know how to > handle them other than resyncing to the next known level 1 element, so > it would be nice not to have to worry about unknown master elements > with unknown size. That's probably something to discuss on the CELLAR mailing list. I don't have a strong opinion on this. As said above it shouldn't impact much playback since in both cases you'd drop the data and
Re: [FFmpeg-devel] [PATCH 13/21] avformat/matroskadec: Improve length check
> On April 7, 2019 at 12:54 PM Andreas Rheinhardt via ffmpeg-devel
> wrote:
>
>
> Steve Lhomme:
> > On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
> >> The earlier code had three flaws:
> >>
> >> 1. The case of an unknown-sized element inside a finite-sized element
> >> (which is against the specifications) was not caught.
> >>
> >> 2. The error message wasn't helpful: It compared the length of the
> >> child
> >> with the offset of the end of the parent and claimed that the first
> >> exceeds the latter, although that is not necessarily true.
> >>
> >> 3. Unknown-sized elements that are not parsed can't be skipped. Given
> >> that according to the Matroska specifications only the segment and the
> >> clusters can be of unknown-size, this is handled by not allowing any
> >
> > This restriction is rather new. There might be old files that use
> > infinite sizes in other places.
> >
> Indeed there are. The file mentioned by Dale
> (https://ffmpeg.org/pipermail/ffmpeg-devel/2019-February/240376.html;
> https://cs.chromium.org/chromium/src/media/test/data/bear-320x240-live.webm)
> has cues where every master element (even CueTrackPositions) are
> written as unknown-sized element (with length fields coded on eight
> bytes). The Cues aren't referenced in a Seekhead at the beginning
> though, so that FFmpeg doesn't try to read them. If they were
> referenced, neither current nor patched FFmpeg would be able to
> properly parse them and patched FFmpeg would furthermore give an error
> message.
>
> When exactly has this restriction been enacted?
That would be 35e0909ef4fc34ca7cb15adba5e7c7ebf5daeacb in the Matroska
specifications (2016/10/31). Before that any master element was allowed to use
the unknown length feature. Now only Segment and Cluster are. Given WebM is
based on the Matroska specifications on matroska.org I would assume they don't
have this restriction yet.
> I'll see if I find a way to support such elements (although I am not
> sure whether it is worthwhile).
>
> >> other units to have infinite size whereas the earlier code would seek
> >> back by 1 byte upon encountering an infinite-size element that ought
> >> to be skipped.
> >>
> >> Signed-off-by: Andreas Rheinhardt
> >> ---
> >> libavformat/matroskadec.c | 26 ++
> >> 1 file changed, 22 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> >> index 6fa324c0cc..0179e5426e 100644
> >> --- a/libavformat/matroskadec.c
> >> +++ b/libavformat/matroskadec.c
> >> @@ -1180,11 +1180,29 @@ static int
> >> ebml_parse_elem(MatroskaDemuxContext *matroska,
> >> if (matroska->num_levels > 0) {
> >> MatroskaLevel *level =
> >> >levels[matroska->num_levels - 1];
> >> int64_t pos = avio_tell(pb);
> >> - if (level->length != EBML_UNKNOWN_LENGTH &&
> >> - (pos + length) > (level->start + level->length)) {
> >> +
> >> + if (length != EBML_UNKNOWN_LENGTH &&
> >> + level->length != EBML_UNKNOWN_LENGTH) {
> >> + uint64_t elem_end = pos + length,
> >> + level_end = level->start + level->length;
> >> +
> >> + if (level_end < elem_end) {
> >> + av_log(matroska->ctx, AV_LOG_ERROR,
> >> + "Element at 0x%"PRIx64" ending at
> >> 0x%"PRIx64" exceeds "
> >> + "containing master element ending at
> >> 0x%"PRIx64"\n",
> >> + pos, elem_end, level_end);
> >> + return AVERROR_INVALIDDATA;
> >> + }
> >> + } else if (level->length != EBML_UNKNOWN_LENGTH) {
> >> + av_log(matroska->ctx, AV_LOG_ERROR, "Unknown-sized
> >> element "
> >> + "at 0x%"PRIx64" inside parent with finite
> >> size\n", pos);
> >> + return AVERROR_INVALIDDATA;
> >
> > IMO there's no reason to return an error here. You can log the error
> > and still parse the data, it should end up fine (if the code is done
> > as such that you can never read past your parents boundaries). At
> > least libebml can deal w
Re: [FFmpeg-devel] [PATCH 10/21] avformat/matroskadec: Don't keep old blocks
> On April 7, 2019 at 11:38 AM Andreas Rheinhardt via ffmpeg-devel
> wrote:
>
>
> Steve Lhomme:
> > On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
> >> Before this commit, the Matroska muxer would read a block when required
> >> to do so, parse the block, create and return the necessary AVPackets
> >> and
> >> yet keep the blocks (in a dynamically allocated list), although they
> >> aren't used at all any more. This has been changed. There is no list
> >> any
> >> more and the block is immediately discarded after parsing.
> >
> > My understanding of the code is that the blocks are put in a queue,
>
> Yes, the parsed blocks are put in a queue of their own; so we don't
> need to keep all the raw data of all the already parsed blocks of the
> current cluster around. (Refcounting means that some of this data
> might be keep a little longer though, but even in this case this patch
> eliminates e.g. the constant reallocation of the list of blocks.)
>
> > that's whatwebm_clusters_start_with_keyframe() uses to check that the
> > first frame is a keyframe
>
> Yes.
>
> > (it doesn't check the type of the frame though...).
>
> I see a "if (!(pkt->flags & AV_PKT_FLAG_KEY))" in there.
By type I meant audio/video/subtitle. Although in WebM originally the audio was
supposed to be put before the corresponding audio. So this code checks if the
first audio packet is a keyframe. I don't think that's the intention of this
code. But that's not related to your patch.
> > But since there's only one read
> > inmatroska_parse_cluster_incremental()there's only one kept in memory.
> >
> > So LGTM.
> >
> >>
> >> Signed-off-by: Andreas Rheinhardt
> >> ---
> >> libavformat/matroskadec.c | 87
> >> +--
> >> 1 file changed, 38 insertions(+), 49 deletions(-)
> >>
> >> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> >> index 9198fa1bea..997c96d78f 100644
> >> --- a/libavformat/matroskadec.c
> >> +++ b/libavformat/matroskadec.c
> >> @@ -304,9 +304,20 @@ typedef struct MatroskaLevel {
> >> uint64_t length;
> >> } MatroskaLevel;
> >> +typedef struct MatroskaBlock {
> >> + uint64_t duration;
> >> + int64_t reference;
> >> + uint64_t non_simple;
> >> + EbmlBin bin;
> >> + uint64_t additional_id;
> >> + EbmlBin additional;
> >> + int64_t discard_padding;
> >> +} MatroskaBlock;
> >> +
> >> typedef struct MatroskaCluster {
> >> + MatroskaBlock block;
> >> uint64_t timecode;
> >> - EbmlList blocks;
> >> + int64_t pos;
> >> } MatroskaCluster;
> >> typedef struct MatroskaLevel1Element {
> >> @@ -356,8 +367,6 @@ typedef struct MatroskaDemuxContext {
> >> MatroskaLevel1Element level1_elems[64];
> >> int num_level1_elems;
> >> - int current_cluster_num_blocks;
> >> - int64_t current_cluster_pos;
> >> MatroskaCluster current_cluster;
> >> /* WebM DASH Manifest live flag */
> >> @@ -367,16 +376,6 @@ typedef struct MatroskaDemuxContext {
> >> int bandwidth;
> >> } MatroskaDemuxContext;
> >> -typedef struct MatroskaBlock {
> >> - uint64_t duration;
> >> - int64_t reference;
> >> - uint64_t non_simple;
> >> - EbmlBin bin;
> >> - uint64_t additional_id;
> >> - EbmlBin additional;
> >> - int64_t discard_padding;
> >> -} MatroskaBlock;
> >> -
> >> static const EbmlSyntax ebml_header[] = {
> >> { EBML_ID_EBMLREADVERSION, EBML_UINT, 0, offsetof(Ebml,
> >> version), { .u = EBML_VERSION } },
> >> { EBML_ID_EBMLMAXSIZELENGTH, EBML_UINT, 0, offsetof(Ebml,
> >> max_size), { .u = 8 } },
> >> @@ -705,9 +704,9 @@ static const EbmlSyntax matroska_blockgroup[] = {
> >> };
> >> static const EbmlSyntax matroska_cluster_parsing[] = {
> >> - { MATROSKA_ID_CLUSTERTIMECODE, EBML_UINT,
> >> 0, offsetof(MatroskaCluster, timecode) },
> >> - { MATROSKA_ID_BLOCKGROUP, EBML_NEST,
> >> sizeof(MatroskaBlock), offsetof(MatroskaCluster, blocks), { .n =
> >> matroska_blockgroup } },
> >> - { MATROSKA_ID_SIMPLEBLOCK, EBML_PASS,
> >> sizeof(MatroskaBlock), offsetof(MatroskaCluster, blocks), { .n =
> >> ma
Re: [FFmpeg-devel] [PATCH 08/21] avformat/matroskadec: Improve error messages
> On April 7, 2019 at 11:24 AM Andreas Rheinhardt via ffmpeg-devel
> wrote:
>
>
> Steve Lhomme:
> > On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
> >> ebml_read_num had a number of flaws:
> >>
> >> 1. The check for read errors/EOF was totally wrong. E.g. an EBML number
> >> beginning with the invalid 0x00 would be considered a read error,
> >> although it is just invalid data.
> >> 2. The check for read errors/EOF was done just once, after reading the
> >> first byte of the EBML number. But errors/EOF can happen inbetween, of
> >> course, and this wasn't checked.
> >> 3. There was no way to distinguish when EOF should be an error (because
> >> the data has to be there) for which an error message should be emitted
> >> and when it is not necessarily an error (namely during parsing of EBML
> >> IDs). Such a possibility has been added and used.
> >
> > Maybe the title of the patch should rather mention that it's fixing
> > the EOF handling when reading EBML ID/Length. The changed error
> > messages is a less important consequence.
> >
> How about "avformat/matroskadec: Improve (in particular) EOF checks"?
> >
> >>
> >> Some useless initializations were also fixed.
> >>
> >> Signed-off-by: Andreas Rheinhardt
> >> ---
> >> libavformat/matroskadec.c | 61
> >> ++-
> >> 1 file changed, 34 insertions(+), 27 deletions(-)
> >>
> >> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> >> index a6617a607b..aa2266384a 100644
> >> --- a/libavformat/matroskadec.c
> >> +++ b/libavformat/matroskadec.c
> >> @@ -820,29 +820,19 @@ static int ebml_level_end(MatroskaDemuxContext
> >> *matroska)
> >> * Returns: number of bytes read, < 0 on error
> >> */
> >> static int ebml_read_num(MatroskaDemuxContext *matroska,
> >> AVIOContext *pb,
> >> - int max_size, uint64_t *number)
> >> + int max_size, uint64_t *number, int
> >> eof_forbidden)
> >> {
> >> - int read = 1, n = 1;
> >> - uint64_t total = 0;
> >> + int read, n = 1;
> >> + uint64_t total;
> >> + int64_t pos;
> >> - /* The first byte tells us the length in bytes - avio_r8()
> >> can normally
> >> - * return 0, but since that's not a valid first ebmlID byte, we
> >> can
> >> - * use it safely here to catch EOS. */
> >> - if (!(total = avio_r8(pb))) {
> >> - /* we might encounter EOS here */
> >> - if (!avio_feof(pb)) {
> >> - int64_t pos = avio_tell(pb);
> >> - av_log(matroska->ctx, AV_LOG_ERROR,
> >> - "Read error at pos. %"PRIu64" (0x%"PRIx64")\n",
> >> - pos, pos);
> >> - return pb->error ? pb->error : AVERROR(EIO);
> >> - }
> >> - return AVERROR_EOF;
> >> - }
> >> + /* The first byte tells us the length in bytes - except when it
> >> is zero. */
> >> + total = avio_r8(pb);
> >> + if (avio_feof(pb))
> >> + goto err;
> >> /* get the length of the EBML number */
> >> - read = 8 - ff_log2_tab[total];
> >> - if (read > max_size) {
> >> + if (!total || (read = 8 - ff_log2_tab[total]) > max_size) {
> >> int64_t pos = avio_tell(pb) - 1;
> >> av_log(matroska->ctx, AV_LOG_ERROR,
> >> "Invalid EBML number size tag 0x%02x at pos
> >> %"PRIu64" (0x%"PRIx64")\n",
> >> @@ -855,9 +845,27 @@ static int ebml_read_num(MatroskaDemuxContext
> >> *matroska, AVIOContext *pb,
> >> while (n++ < read)
> >> total = (total << 8) | avio_r8(pb);
> >> + if (avio_feof(pb)) {
> >> + eof_forbidden = 1;
> >> + goto err;
> >> + }
> >
> > You're forcing an error if the data ends after reading a number ?
> > Ending a Matroska file with a number should be fine. It could also be
> > an element with a size of 0. It doesn't contain any data but it's
> > still valid (depending on the semantic of the element).
> >
> > So this forced error seem wrong. Let the next read catch the EOF if it
> > finds one.
> >
> avio_feof doesn't indicate an er
Re: [FFmpeg-devel] [PATCH 19/21] avformat/matroskadec: Add SilentTracks to cluster syntax
On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
This is important as unknown-sized elements end upon encountering an
unknown EBML ID.
That's the problem with this approach. Noone is allowed to use their own
custom tags (RAWCooked for example) and the unknown length feature. You
have to know every element in the world for this not to break.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroska.h| 1 +
libavformat/matroskadec.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/libavformat/matroska.h b/libavformat/matroska.h
index 86968a8de1..43fea595b6 100644
--- a/libavformat/matroska.h
+++ b/libavformat/matroska.h
@@ -224,6 +224,7 @@
#define MATROSKA_ID_CLUSTERTIMECODE 0xE7
#define MATROSKA_ID_CLUSTERPOSITION 0xA7
#define MATROSKA_ID_CLUSTERPREVSIZE 0xAB
+#define MATROSKA_ID_SILENTTRACKS 0x5854
#define MATROSKA_ID_BLOCKGROUP 0xA0
#define MATROSKA_ID_BLOCKADDITIONS 0x75A1
#define MATROSKA_ID_BLOCKMORE 0xA6
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 60f58cefa9..c1feb3f0a1 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -711,6 +711,7 @@ static const EbmlSyntax matroska_cluster_parsing[] = {
{ MATROSKA_ID_BLOCKGROUP, EBML_STOP },
{ MATROSKA_ID_CLUSTERPOSITION, EBML_NONE },
{ MATROSKA_ID_CLUSTERPREVSIZE, EBML_NONE },
+{ MATROSKA_ID_SILENTTRACKS,EBML_NONE },
{ 0 }
};
--
2.19.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".
___
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 18/21] avformat/matroskadec: Combine two arrays
On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
By including SimpleBlocks and Blocksgroups twice in the same EbmlSyntax
array (with different semantics), one can reduce the duplication of the
other values.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 3adcb3e86d..60f58cefa9 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -704,25 +704,18 @@ static const EbmlSyntax matroska_blockgroup[] = {
};
static const EbmlSyntax matroska_cluster_parsing[] = {
-{ MATROSKA_ID_CLUSTERTIMECODE, EBML_UINT, 0, offsetof(MatroskaCluster,
timecode) },
-{ MATROSKA_ID_BLOCKGROUP, EBML_NEST, 0, 0, { .n = matroska_blockgroup
} },
{ MATROSKA_ID_SIMPLEBLOCK, EBML_BIN, 0, offsetof(MatroskaBlock, bin)
},
-{ MATROSKA_ID_CLUSTERPOSITION, EBML_NONE },
-{ MATROSKA_ID_CLUSTERPREVSIZE, EBML_NONE },
-{ 0 }
-};
-
-static const EbmlSyntax matroska_cluster_initial[] = {
+{ MATROSKA_ID_BLOCKGROUP, EBML_NEST, 0, 0, { .n = matroska_blockgroup
} },
{ MATROSKA_ID_CLUSTERTIMECODE, EBML_UINT, 0, offsetof(MatroskaCluster,
timecode) },
-{ MATROSKA_ID_BLOCKGROUP, EBML_STOP },
{ MATROSKA_ID_SIMPLEBLOCK, EBML_STOP },
+{ MATROSKA_ID_BLOCKGROUP, EBML_STOP },
{ MATROSKA_ID_CLUSTERPOSITION, EBML_NONE },
{ MATROSKA_ID_CLUSTERPREVSIZE, EBML_NONE },
{ 0 }
};
static const EbmlSyntax matroska_cluster_enter[] = {
-{ MATROSKA_ID_CLUSTER, EBML_NEST, 0, 0, { .n =
matroska_cluster_initial } },
+{ MATROSKA_ID_CLUSTER, EBML_NEST, 0, 0, { .n =
_cluster_parsing[2] } },
To avoid breaking this optimisation when the code is changed you might
use some static_assert to make sure that matroska_cluster_parsing[2].id
is MATROSKA_ID_CLUSTERTIMECODE
{ 0 }
};
--
2.19.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".
___
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 15/21] avformat/matroskadec: Redo level handling
On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
This commit changes how levels are handled: If the level used for
ebml_parse ends directly after an element that has been consumed, then
ebml_parse ends the level itself (and any finite-sized levels that end
there as well) and informs the caller via the return value; if the
current level is unknown-sized, then the level is ended as soon as
an element that is not valid on the current level is encountered.
This is designed for situations where one wants to parse master elements
incrementally, i.e. not in one go via ebml_parse_nest.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 104 +++---
1 file changed, 85 insertions(+), 19 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 42f1c21042..32cf57685f 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -69,6 +69,8 @@
#include "qtpalette.h"
#define EBML_UNKNOWN_LENGTH UINT64_MAX /* EBML unknown length, in uint64_t */
+#define LEVEL_ENDED 2 /* return value of ebml_parse when the
+ * syntax level used for parsing
ended. */
typedef enum {
EBML_NONE,
@@ -1041,16 +1043,32 @@ static int ebml_parse_id(MatroskaDemuxContext
*matroska, EbmlSyntax *syntax,
uint32_t id, void *data)
{
int i;
+
for (i = 0; syntax[i].id; i++)
if (id == syntax[i].id)
break;
-if (!syntax[i].id && id == MATROSKA_ID_CLUSTER &&
-matroska->num_levels > 0 &&
-matroska->levels[matroska->num_levels - 1].length ==
EBML_UNKNOWN_LENGTH)
-return 0; // we reached the end of an unknown size cluster
+
if (!syntax[i].id && id != EBML_ID_VOID && id != EBML_ID_CRC32) {
-av_log(matroska->ctx, AV_LOG_DEBUG, "Unknown entry 0x%"PRIX32"\n", id);
+if (!matroska->num_levels || matroska->levels[matroska->num_levels -
1].length
+!=
EBML_UNKNOWN_LENGTH) {
+av_log(matroska->ctx, AV_LOG_DEBUG, "Unknown entry 0x%"PRIX32"\n",
id);
Would this mean a Segment with unknown length would produce this log ?
Or Segments are not part of the levels at all ? If so, same question
with level 1 elements which have an unknown length.
+} else if (matroska->num_levels > 1) {
+// Unknown-sized master elements (except root elements) end
+// when an id not known to be allowed in them is encountered.
+matroska->num_levels--;
+return LEVEL_ENDED;
+} else if (matroska->num_levels == 1) {
+AVIOContext *pb = matroska->ctx->pb;
+int64_t pos = avio_tell(pb);
+// An unkown level 1 element inside an unknown-sized segment
+// is considered an error.
+av_log(matroska->ctx, AV_LOG_ERROR, "Found unknown element id
0x%"PRIX32
+ " at pos. %"PRIu64" (0x%"PRIx64") in an unknown-sized segment.
"
+ "Will be treated as error.\n", id, pos, pos);
+return AVERROR_INVALIDDATA;
+}
}
+
return ebml_parse_elem(matroska, [i], data);
}
@@ -1061,9 +1079,24 @@ static int ebml_parse(MatroskaDemuxContext *matroska, EbmlSyntax *syntax,
uint64_t id;
int res = ebml_read_num(matroska, matroska->ctx->pb, 4, , 0);
if (res < 0) {
-// in live mode, finish parsing if EOF is reached.
-return (matroska->is_live && matroska->ctx->pb->eof_reached &&
-res == AVERROR_EOF) ? 1 : res;
+if (matroska->ctx->pb->eof_reached && res == AVERROR_EOF) {
+if (matroska->is_live)
+// in live mode, finish parsing if EOF is reached.
+return 1;
+if (matroska->num_levels) {
+MatroskaLevel *level =
>levels[matroska->num_levels - 1];
+
+if (level->length == EBML_UNKNOWN_LENGTH) {
+// Unknown-sized elements automatically end at EOF.
+matroska->num_levels = 0;
+return LEVEL_ENDED;
+} else if (avio_tell(matroska->ctx->pb) < level->start +
level->length) {
+av_log(matroska->ctx, AV_LOG_ERROR, "File ended before
"
+ "its declared end\n");
+}
+}
+}
+return res;
}
matroska->current_id = id | 1 << 7 * res;
}
@@ -1098,10 +1131,15 @@ static int ebml_parse_nest(MatroskaDemuxContext
*matroska, EbmlSyntax *syntax,
break;
}
-while (!res && !ebml_level_end(matroska))
+if (!matroska->levels[matroska->num_levels - 1].length) {
+matroska->num_levels--;
+return 0;
+}
+
+
