Skip to content

F
ffmpeg.wasm-core
Switch branch/tag
  1. 21 Apr, 2020 2 commits
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Redo handling of FlagDefault · e3c54b54
      Andreas Rheinhardt authored 
      Up until now, the Matroska muxer would mark a track as default if it had
the disposition AV_DISPOSITION_DEFAULT or if there was no track with
AV_DISPOSITION_DEFAULT set; in the latter case even more than one track
of a kind (audio, video, subtitles) was marked as default which is not
sensible.

This commit changes the logic used to mark tracks as default. There are
now three modes for this:
a) In the "infer" mode the first track of every type (audio, video,
subtitles) with default disposition set will be marked as default; if
there is no such track (for a given type), then the first track of this
type (if existing) will be marked as default. This behaviour is inspired
by mkvmerge. It ensures that the default flags will be set in a sensible
way even if the input comes from containers that lack the concept of
default flags. This mode is the default mode.
b) The "infer_no_subs" mode is similar to the "infer" mode; the
difference is that if no subtitle track with default disposition exists,
no subtitle track will be marked as default at all.
c) The "passthrough" mode: Here the track will be marked as default if
and only the corresponding input stream had disposition default.

This fixes ticket #8173 (the passthrough mode is ideal for this) as
well as ticket #8416 (the "infer_no_subs" mode leads to the desired
output).
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      e3c54b54
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Don't waste bytes on length fields · 5b6e164b
      Andreas Rheinhardt authored 
      Several EBML Master elements for which a good upper bound of the final
length was available were nevertheless written without giving an
upper bound of the final length to start_ebml_master(), so that their
length fields were eight bytes long. This has been changed.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      5b6e164b
  3. 20 Apr, 2020 3 commits
  5. 18 Apr, 2020 3 commits
  7. 13 Apr, 2020 5 commits
    • Michael Bradshaw's avatar
      tests/ref/vsynth: fix fate colr changes (again) · 05039c13
      Michael Bradshaw authored 
      Signed-off-by: 's avatarMichael Bradshaw <mjbshaw@google.com>
      05039c13
    • Michael Bradshaw's avatar
      tests/ref/vsynth: fix fate colr changes · 19a16330
      Michael Bradshaw authored 
      Commit 9842fd3a stopped guessing colr
values.
Signed-off-by: 's avatarMichael Bradshaw <mjbshaw@google.com>
      19a16330
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Make output more deterministic · ccadd00a
      Andreas Rheinhardt authored 
      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: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      ccadd00a
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Remove allocations for Attachments · 358b58cb
      Andreas Rheinhardt authored 
      If there are Attachments to write, the Matroska muxer currently
allocates two objects: An array that contains an entry for each
AttachedFile containing just the stream index of the corresponding
stream and the FileUID used for this AttachedFile; and a structure with
a pointer to said array and a counter for said array. These uids are
generated via code special to Attachments: It uses an AVLFG in the
normal and a sha of the attachment data in the bitexact case. (Said sha
requires an allocation, too.)

But now that an uid is generated for each stream in mkv_init(), there is
no need any more to use special code for generating the FileUIDs of
AttachedFiles: One can simply use the uid already generated for the
corresponding stream. And this makes the whole allocations of the
structures for AttachedFiles as well as the structures itself superfluous.
They have been removed.

In case AVFMT_FLAG_BITEXACT is set, the uids will be different from the
old ones which is the reason why the FATE-test lavf-mkv_attachment
needed to be updated. The old method had the drawback that two
AttachedFiles with the same data would have the same FileUID.
The new one doesn't.

Also notice that the dynamic buffer used to write the Attachments leaks
if an error happens when writing the buffer. By removing the
allocations potential sources of errors have been removed.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      358b58cb
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Don't waste bytes writing durations · bd7dea3f
      Andreas Rheinhardt authored 
      Tags in the Matroska file format can be summarized as follows: There is
a level 1-element called Tags containing one or many Tag elements each
of which in turn contain a Targets element and one or many SimpleTags.
Each SimpleTag roughly corresponds to a single key-value pair similar to
an AVDictionaryEntry. The Targets meanwhile contains information to what
the metadata contained in the SimpleTags contained in the containing Tag
applies (i.e. to the file as a whole or to an individual track).

The Matroska muxer writes such metadata. It puts the metadata of every
stream into a Tag whose Targets makes it point to the corresponding
track. And if the output is seekable, then it also adds another Tag for
each track whose Targets corresponds to the track and where it reserves
space in a SimpleTag to write the duration at the end of the muxing
process into.

Yet there is no reason to write two Tag elements for a track and a few
bytes (typically 24 bytes per track) can be saved by adding the duration
SimpleTag to the other Tag of the same track (if it exists).

FATE has been updated because the output files changed. (Tests that
write to unseekable output (pipes) needn't be updated (no duration tag
has ever been written for them) and the same applies to tests without
further metadata.)
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      bd7dea3f
  9. 10 Apr, 2020 2 commits
  11. 07 Apr, 2020 1 commit
  13. 04 Apr, 2020 1 commit
  15. 02 Apr, 2020 3 commits
  17. 27 Mar, 2020 2 commits
    • Linjie Fu's avatar
      tests/checkasm: add overflow test for hevc_add_res · ddf6ca3a
      Linjie Fu authored 
      Add overflow test for hevc_add_res when int16_t coeff = -32768.

The result of C is good, while ASM is not.

To verify:
    make fate-checkasm-hevc_add_res
    ffmpeg/tests/checkasm/checkasm --test=hevc_add_res

./checkasm --test=hevc_add_res
checkasm: using random seed 679391863
MMXEXT:
    hevc_add_res_4x4_8_mmxext (hevc_add_res.c:69)
  - hevc_add_res.add_residual [FAILED]
SSE2:
    hevc_add_res_8x8_8_sse2 (hevc_add_res.c:69)
    hevc_add_res_16x16_8_sse2 (hevc_add_res.c:69)
    hevc_add_res_32x32_8_sse2 (hevc_add_res.c:69)
  - hevc_add_res.add_residual [FAILED]
AVX:
    hevc_add_res_8x8_8_avx (hevc_add_res.c:69)
    hevc_add_res_16x16_8_avx (hevc_add_res.c:69)
    hevc_add_res_32x32_8_avx (hevc_add_res.c:69)
  - hevc_add_res.add_residual [FAILED]
AVX2:
    hevc_add_res_32x32_8_avx2 (hevc_add_res.c:69)
  - hevc_add_res.add_residual [FAILED]
checkasm: 8 of 14 tests have failed
Signed-off-by: 's avatarXu Guangxin <guangxin.xu@intel.com>
Signed-off-by: 's avatarLinjie Fu <linjie.fu@intel.com>
Signed-off-by: 's avatarAnton Khirnov <anton@khirnov.net>
      ddf6ca3a
    • Linjie Fu's avatar
      checkasm/hevc_add_res: prepare test data only if the fuction is not tested · 69b9548d
      Linjie Fu authored 
      check_func will return NULL for functions that have already been tested. If
the func is tested and skipped (which happens several times), there is no
need to prepare data(randomize_buffers and memcpy).

Move relative code in compare_add_res(), prepare data and do check only if
the function is not tested.
Signed-off-by: 's avatarLinjie Fu <linjie.fu@intel.com>
Signed-off-by: 's avatarAnton Khirnov <anton@khirnov.net>
      69b9548d
  19. 26 Mar, 2020 1 commit
    • Andreas Rheinhardt's avatar
      avformat/matroskaenc: Avoid allocations for SeekHead · dc2f6b54
      Andreas Rheinhardt authored 
      Up until e7ddafd5, the Matroska muxer wrote two SeekHeads: One at the
beginning referencing the main level 1 elements (i.e. not the Clusters)
and one at the end, referencing the Clusters. This second SeekHead was
useless and has therefore been removed. Yet the SeekHead-related
functions and structures are still geared towards this usecase: They
are built around an allocated array of variable size that gets
reallocated every time an element is added to it although the maximum
number of Seek entries is a small compile-time constant, so that one should
rather include the array in the SeekHead structure itself; and said
structure should be contained in the MatroskaMuxContext instead of being
allocated separately.

The earlier code reserved space for a SeekHead with 10 entries, although
we currently write at most 6. Reducing said number implied that every
Matroska/Webm file will be 84 bytes smaller and required to adapt
several FATE tests; furthermore, the reserved amount overestimated the
amount needed for for the SeekHead's length field and how many bytes
need to be reserved to write a EBML Void element, bringing the total
reduction to 89 bytes.

This also fixes a potential segfault: If !mkv->is_live and if the
AVIOContext is initially unseekable when writing the header, the
SeekHead is already written when writing the header and this used to
free the SeekHead-related structures that have been allocated. But if
the AVIOContext happens to be seekable when writing the trailer, it will
be attempted to write the SeekHead again which will lead to segfaults
because the corresponding structures have already been freed.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      dc2f6b54
  21. 25 Mar, 2020 1 commit
    • Andreas Rheinhardt's avatar
      avformat/webmdashenc: Don't use custom option for bitexactness · 00d0934f
      Andreas Rheinhardt authored 
      The WebM DASH Manifest muxer can write manifests for live streams and
these contain an entry that depends on the time the manifest is written;
an AVOption to make the output reproducible has been added for tests.
But this is unnecessary, as there already is a method for reproducible
output: The AVFMT_FLAG_BITEXACT-flag of the AVFormatContext. Therefore
this commit removes the custom option.

Given that the description of said option contained "private option -
users should never set this" and that it was not documented in
muxers.texi, no deprecation period for this option seemed necessary.

The commands of the FATE-tests for this muxer have been changed to no
longer use this option.
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      00d0934f
  23. 20 Mar, 2020 1 commit
  25. 16 Mar, 2020 2 commits
  27. 11 Mar, 2020 1 commit
  29. 10 Mar, 2020 1 commit
  31. 05 Mar, 2020 1 commit
    • Andreas Rheinhardt's avatar
      h264_mp4toannexb: Try to avoid four byte startcodes · 518bbe9e
      Andreas Rheinhardt authored 
      According to the H.264 specifications, the only NAL units that need to
have four byte startcodes in H.264 Annex B format are SPS/PPS units and
units that start a new access unit. Before af7e953a, the first of these
conditions wasn't upheld as already existing in-band parameter sets
would not automatically be written with a four byte startcode, but only
when they already were at the beginning of their input packets. But it
made four byte startcodes be used too often as every unit that is written
together with a parameter set that is inserted from extradata received a
four byte startcode although a three byte start code would suffice
unless the unit itself were a parameter set.

FATE has been updated to reflect the changes. Although the patch leaves
the extradata unchanged, the size of the extradata according to the FATE
reports changes. This is due to a quirk in ff_h2645_packet_split which
is used by extract_extradata: If the input is Annex B, the first zero of
a four byte startcode is considered a part of the last unit (if any).
Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      518bbe9e
  33. 02 Mar, 2020 1 commit
  35. 24 Feb, 2020 1 commit
  37. 23 Feb, 2020 1 commit
  39. 22 Feb, 2020 1 commit
  41. 15 Feb, 2020 3 commits
  43. 08 Feb, 2020 1 commit
  45. 07 Feb, 2020 1 commit
  47. 04 Feb, 2020 1 commit