This avoids one redundant load per row; pix3 from the previous
iteration can be used as pix2 in the next one.
Before: Cortex A53 A72 A73
pix_abs_0_2_neon: 138.0 59.7 48.0
After:
pix_abs_0_2_neon: 109.7 50.2 39.5
Signed-off-by: Martin Storsjö <martin@martin.st>
This matches a similar cap on the number of automatic threads
in libavcodec/pthread_slice.c.
On systems with lots of cores, this fixes a couple fate failures
in 32 bit mode on such machines (where spawning a huge number of
threads runs out of address space).
Signed-off-by: Martin Storsjö <martin@martin.st>
The AArch64 assembly accesses those symbols directly, without
indirection via e.g. the GOT on ELF. In order for this not to
require text relocations, those symbols need to be resolved fully
at link time, i.e. those symbols can't be interposable.
Normally, so far, this is achieved when linking shared libraries
in two ways; we have a version script (libavcodec/libavcodec.v) which
marks all symbols that don't start with av* as local. Additionally,
we try to add -Wl,-Bsymbolic to the linker options if supported,
making sure that such symbol references are resolved fully at link
time, instead of making them interposable.
When the libavcodec static library is linked into another shared
library, there's no guarantee that it uses similar options (even though
that would be favourable), which would end up requiring text relocations
in the AArch64 assembly.
Explicitly mark the symbols that are accessed from AArch64 assembly
as hidden, so that they are resolved fully at link time even without
the version script and -Wl,-Bsymbolic.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids triggering overflows in the filters, and avoids stray
test failures in the approximate functions on x86; due to rounding
differences, one implementation might overflow while another one
doesn't.
Signed-off-by: Martin Storsjö <martin@martin.st>
This directory dependency is normally added implicitly by rules
in ffbuild/common.mak; for tools it's created by a rule for TOOLOBJS.
TOOLOBJS is populated implicitly from TOOLS, and decode_simple.o
doesn't end up there because it's an odd occurrance of a lone
object file in the tools subdirectory, not belonging to any other
tool.
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously, the checkasm test always passed h=8, so no other cases
were tested.
Out of the me_cmp functions, in practice, some functions are hardcoded
to always assume a 8x8 block (ignoring the h parameter), while others
do use the parameter. For those with hardcoded height, both the
reference C function and the assembly implementations ignore the
parameter similarly.
The documentation for the functions indicate that heights between
w/2 and 2*w, within the range of 4 to 16, should be supported. This
patch just tests random heights in that range, without knowing what
width the current function actually uses.
Signed-off-by: Martin Storsjö <martin@martin.st>
The height is hardcoded in some of the me_cmp functions, but not
in all of them. But in the case of all other functions, it's hardcoded
in the same place in SIMD functions as in the C reference functions,
while this one function differs from the behaviour of the C code.
(Before 542765ce3e, there were a
couple other sad8_*_mmx functions with similar hardcoded height.)
Signed-off-by: Martin Storsjö <martin@martin.st>
This codepath is enabled by default on arm, if the linux perf API
is available, unless disabled with --disable-linux-perf.
Signed-off-by: Martin Storsjö <martin@martin.st>
The DXGI_OUTDUPL_FRAME_INFO type isn't available in Windows API
subsets other than "desktop", while the IDXGIOutput1 interface is
available for all API subsets.
This fixes compilation for UWP/"Windows Store" configurations (and
older API subsets like Windows Phone).
Signed-off-by: Martin Storsjö <martin@martin.st>
The max height is currently documented as 16; the max difference per
pixel is 255, and a .8h element can easily contain 16*255, thus keep
accumulating in two .8h vectors, and just do the final accumulationat the
end. This should work for heights up to 256.
This requires a minor register renumbering in ff_pix_abs16_xy2_neon.
Before: Cortex A53 A72 A73 Graviton 3
pix_abs_0_0_neon: 97.7 47.0 37.5 22.7
pix_abs_0_1_neon: 154.0 59.0 52.0 25.0
pix_abs_0_3_neon: 179.7 96.7 87.5 41.2
After:
pix_abs_0_0_neon: 96.0 39.2 31.2 22.0
pix_abs_0_1_neon: 150.7 59.7 46.2 23.7
pix_abs_0_3_neon: 175.7 83.7 81.7 38.2
Signed-off-by: Martin Storsjö <martin@martin.st>
Using absolute-difference-accumulate does use twice the amount of
absolute-difference instructions, but avoids the need for the
uaddl and add instructions, reducing the total number of instructions
by 3.
These can be interleaved in the rest of the calculation, to avoid
tight dependencies at the end. Unfortunately, this is marginally
slower on Cortex A53, but faster on A72 and A73.
Before: Cortex A53 A72 A73 Graviton 3
pix_abs_0_3_neon: 175.7 109.2 92.0 41.2
After:
pix_abs_0_3_neon: 179.7 96.7 87.5 41.2
Signed-off-by: Martin Storsjö <martin@martin.st>
The dlopen wrapper contains code to make loading libraries safer,
to avoid loading a potentially malicious DLL with the same name.
Signed-off-by: Martin Storsjö <martin@martin.st>
Since every DLL can use an individual CRT on Windows, having
an exported function that opens a FILE* won't work if that
FILE* is going to be used from a different DLL (or from user
application code).
Internally within the libraries, the issue can be worked around
by duplicating the function in all libraries (this already happened
implicitly because the function resided in file_open.c) and renaming
the function to ff_fopen_utf8 (so that it doesn't end up exported from
the DLLs) and duplicating it in all libraries that use it.
This makes the avpriv_fopen_utf8 / ff_fopen_utf8 function work in
the exact same way as the existing avpriv_open / ff_open, with the
same setup as introduced in e743e7ae6e.
That mechanism doesn't work for external users, thus deprecate the
existing function.
Signed-off-by: Martin Storsjö <martin@martin.st>
Provide a header based inline reimplementation of it.
Using av_fopen_utf8 doesn't work outside of the libraries when built
with MSVC as shared libraries (in the default configuration, where
each DLL gets a separate statically linked CRT).
Signed-off-by: Martin Storsjö <martin@martin.st>
The test also requires a png decoder, which often can be disabled in
cross building setups, where zlib might be missing.
Signed-off-by: Martin Storsjö <martin@martin.st>
tiny_ssim is built for the build host, not for the target platform.
Therefore, it mustn't include the config.h header, which is set up
specifically for the target platform and compiler.
This fixes cross building for older WinStore platforms, where
config.h contains "#define getenv(x) NULL".
Signed-off-by: Martin Storsjö <martin@martin.st>
The existing x86 assembly for loop filters uses the stride as a
full register without clearing/sign extending the upper half
of the registers on x86_64.
This avoids crashes if the caller would have passed nonzero bits
in the previously undefined upper 32 bits of the parameters.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids unnecessary churn and build breakage for users, by
making sure the whole version.h is included like it has been so far,
while keeping the benefit of not needing to rebuild most files in
the ffmpeg tree on minor/micro bumps.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids unnecessary rebuilds of most source files if only the
list of enabled components has changed, but not the other properties
of the build, set in config.h.
Signed-off-by: Martin Storsjö <martin@martin.st>
Also bump the minor versions of all libraries, to signify the
API change of splitting the version.h headers and adding the
new version_major.h header.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids including version.h in all source files, avoiding
unnecessary rebuilds when the version number is bumped. Only
version_major.h is included by the main header, which defines
availability of e.g. FF_API_* macros, and which is bumped much
less often.
This isn't done for libavutil/version.h, because that header needs
to be included essentially everywhere due to LIBAVUTIL_VERSION_INT
being used wherever an AVClass is constructed.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids build errors if such features are enabled while targeting
another binary format. (Using such features on other platforms
might require some other form of signaling/setup though, but
the ELF specific .note section isn't applicable at least.)
Signed-off-by: Martin Storsjö <martin@martin.st>
The muxer seems to have had one seemingly accidental use of
LIBAVCODEC_IDENT, while LIBAVFORMAT_IDENT probably is the
relevant one (which is used multiple times in the same file).
Signed-off-by: Martin Storsjö <martin@martin.st>
While swscale can be reconfigured with sws_setColorspaceDetails,
the in/out ranges also need to be set before calling
sws_init_context, otherwise the initialization might choose
fastpaths that don't take the ranges into account.
Therefore, look at in->color_range too, when deciding on whether
the scaler needs to be reconfigured.
Add a new member variable for keeping track of this, for being
able to differentiate between whether the scale filter parameter
"in_range" has been set (which should override whatever the input
frame has set) or whether it has been configured based on the
latest frame (which should trigger reconfiguring the scaler if
the input frame ranges change).
Fixes: Ticket #9576
Signed-off-by: Martin Storsjö <martin@martin.st>
The range parameters need to be set up before calling
sws_init_context (which selects which fastpaths can be used;
this gets called by sws_getContext); solely passing them via
sws_setColorspaceDetails isn't enough.
This fixes producing full range YUV range output when doing
YUV->YUV conversions between different YUV color spaces.
Signed-off-by: Martin Storsjö <martin@martin.st>
xvmc.h used FF_API_* macros before, but they were removed in
1c63aed232, leaving the include
unused.
The ones in android_camera.c and mediacodec_wrapper.c have been
added due to a misunderstanding, fixed in
c0bce367e4 and
13b77af2f0.
The one in mediacodec.c seems to never have been used at all.
Signed-off-by: Martin Storsjö <martin@martin.st>
The fdk-aac decoder can return decoded audio data with a delay.
(Whether it does this or not depends on the options set; by default
it does add some delay.) Previously, this delay was handled by
adjusting the timestamps of the decoded frames, but the last delayed
samples weren't returned.
Set the AV_CODEC_CAP_DELAY flag to indicate that the caller should
flush remaining samples at the end. Also trim off the corresponding
amount of samples at the start instead of adjusting timestamps.
Signed-off-by: Martin Storsjö <martin@martin.st>
While this function on its own passes all of fate-hevc, there's
indications that the function might need to handle widths that
aren't a multiple of 8 (noted in commit
f63f9be37c, which later was
reverted).
Signed-off-by: Martin Storsjö <martin@martin.st>
Passing an uninitialized variable as argument to a function is
undefined behaviour (UB). The compiler can assume that UB does not
happen.
Hence, the compiler can assume that the variables are never
uninitialized when passed as argument, which means that the codepaths
that initializes them must be taken.
In ff_seek_frame_binary, this means that the compiler can assume
that the codepaths that initialize pos_min and pos_max are taken,
which means that the conditions "if (sti->index_entries)" and
"if (index >= 0)" can be optimized out.
Current Clang git versions (upcoming Clang 14) enabled an optimization
that does this, which broke the current version of this function
(which intentionally left the variables uninitialized, but silencing
warnings about being uninitialized). See [1] for discussion on
the matter.
[1] https://reviews.llvm.org/D105169#3069555
Signed-off-by: Martin Storsjö <martin@martin.st>
Don't use the loaded registers directly, avoiding stalls on in
order cores. Use vrhadd.u8 with q registers where easily possible.
Signed-off-by: Martin Storsjö <martin@martin.st>
The refactoring in 844890b1bc caused
fate-source to point out that this could be av_clip_uintp2 (or
rather av_clip_uint8).
Signed-off-by: Martin Storsjö <martin@martin.st>
If no --cpu= option was passed to configure, we detect what the
compiler defaults to. This detected value was then fed back to the
rest of the configure logic, as if it was an explicit choice.
This breaks on Ubuntu 21.10 with GCC 11.1.
Since GCC 8, it's possible to add configure extra features via the
-march option, like e.g. -march=armv7-a+neon. If the -mfpu= option
is configured to default to 'auto', the fpu setting gets taken
from the -march option.
GCC 11.1 in Ubuntu seems to be configured to use -mfpu=auto. This
has the effect of breaking any compilation command that specifies
-march=armv7-a, because the driver implicitly also adds -mfloat-abi=hard,
and that combination results in this error:
cc1: error: ‘-mfloat-abi=hard’: selected processor lacks an FPU
One can compile successfully by passing e.g. -march=armv7-a+fp.
Therefore, restructure configure. If no specific preference was set
(and the 'cpu' configure variable was set as the output of
probe_arm_arch), the value we tried to set via -march= was the same
value that we just tried to detect as the compiler default.
So instead, just try to detect what the compiler defaults to, with
to allow setting other configure settings (such as 'fast_unaligned'),
but don't try to spell out the compiler's default via the -march flag.
Signed-off-by: Martin Storsjö <martin@martin.st>
This unbreaks the fate-checkasm-hevc_pel test on arm targets.
The assembly assumed that the width passed to the DSP functions is
a multiple of 8, while the checkasm test used other widths too.
This wasn't noticed before, because the hevc_pel checkasm tests
(that were added in 9c513edb79 in
January) weren't run as part of fate until in
b492cacffd in August.
As this hasn't been an issue in practice with actual full decoding
tests, it seems like the actual decoder doesn't call these functions
with such widths. Therefore, we could alternatively fix the test
to only test things that the real decoder does, and this modification
could be reverted.
Signed-off-by: Martin Storsjö <martin@martin.st>
If autoflushing on a new packet (e.g. due to the frag_every_frame
flag being set), there's no samples to be written in the new fragment,
so we can't overwrite the track duration in order to make it line
up with the next packet to be written.
Signed-off-by: Martin Storsjö <martin@martin.st>
Instead use --preprocessor-arg; in binutils 2.36, the --preprocessor
flag was changed so that it no longer accepts a string containing
multiple arguments, but the whole --preprocessor argument is
treated as the path to the preprocessor executable (where the path
can contain spaces).
It's currently unclear whether this behaviour will stay or if it
is going to be reverted in the future, see discussion at [1]. Just
to be safe, avoid using the --preprocessor argument. Don't redeclare
the full preprocessing command, but just add the $(CC_DEPFLAGS) options.
Based on a patch by Kyle Schwartz.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=27594
Signed-off-by: Martin Storsjö <martin@martin.st>
This is marginally slower, but correct for all input values.
The previous implementation failed with certain input seeds, e.g.
"checkasm --test=hevc_idct 98".
Signed-off-by: Martin Storsjö <martin@martin.st>
Move the loop counter decrement further from the branch instruction,
this hides the latency of the decrement.
In loops that first load, then store (the horizontal prediction cases),
do the decrement after the load (where the next instruction would
stall a bit anyway, waiting for the result of the load).
In loops that store twice using the same destination register,
also do the decrement between the two stores (as the second store
would need to wait for the updated destination register from the
first instruction).
In loops that store twice to two different destination registers,
do the decrement before both stores, to do it as soon before the
branch as possible.
This gives minor (1-2 cycle) speedups in most cases (modulo measurement
noise), but the horizontal prediction functions get a rather notable
speedup on the Cortex A53.
Before: Cortex A53 A72 A73
pred8x8_dc_8_neon: 60.7 46.2 39.2
pred8x8_dc_128_8_neon: 30.7 18.0 14.0
pred8x8_horizontal_8_neon: 42.2 29.2 18.5
pred8x8_left_dc_8_neon: 52.7 36.2 32.2
pred8x8_mad_cow_dc_0l0_8_neon: 48.2 27.7 25.7
pred8x8_mad_cow_dc_0lt_8_neon: 52.5 33.2 34.7
pred8x8_mad_cow_dc_l0t_8_neon: 52.5 31.7 33.2
pred8x8_mad_cow_dc_l00_8_neon: 43.2 27.0 25.5
pred8x8_plane_8_neon: 112.2 86.2 88.2
pred8x8_top_dc_8_neon: 40.7 23.0 21.2
pred8x8_vertical_8_neon: 27.2 15.5 14.0
pred16x16_dc_8_neon: 91.0 73.2 70.5
pred16x16_dc_128_8_neon: 43.0 34.7 30.7
pred16x16_horizontal_8_neon: 86.0 49.7 44.7
pred16x16_left_dc_8_neon: 87.0 67.2 67.5
pred16x16_plane_8_neon: 236.0 175.7 173.0
pred16x16_top_dc_8_neon: 53.2 39.0 41.7
pred16x16_vertical_8_neon: 41.7 29.7 31.0
After:
pred8x8_dc_8_neon: 59.0 46.7 42.5
pred8x8_dc_128_8_neon: 28.2 18.0 14.0
pred8x8_horizontal_8_neon: 34.2 29.2 18.5
pred8x8_left_dc_8_neon: 51.0 38.2 32.7
pred8x8_mad_cow_dc_0l0_8_neon: 46.7 28.2 26.2
pred8x8_mad_cow_dc_0lt_8_neon: 55.2 33.7 37.5
pred8x8_mad_cow_dc_l0t_8_neon: 51.2 31.7 37.2
pred8x8_mad_cow_dc_l00_8_neon: 41.7 27.5 26.0
pred8x8_plane_8_neon: 111.5 86.5 89.5
pred8x8_top_dc_8_neon: 39.0 23.2 21.0
pred8x8_vertical_8_neon: 27.2 16.0 14.0
pred16x16_dc_8_neon: 85.0 70.2 70.5
pred16x16_dc_128_8_neon: 42.0 30.0 30.7
pred16x16_horizontal_8_neon: 66.5 49.5 42.5
pred16x16_left_dc_8_neon: 81.0 66.5 67.5
pred16x16_plane_8_neon: 235.0 175.7 173.0
pred16x16_top_dc_8_neon: 52.0 39.0 41.7
pred16x16_vertical_8_neon: 40.2 33.2 31.0
Despite this, a number of these functions still are slower than
what e.g. GCC 7 generates - this shows the relative speedup of the
neon codepaths over the compiler generated ones:
Cortex A53 A72 A73
pred8x8_dc_8_neon: 0.86 0.65 1.04
pred8x8_dc_128_8_neon: 0.59 0.44 0.62
pred8x8_horizontal_8_neon: 1.51 0.58 1.30
pred8x8_left_dc_8_neon: 0.72 0.56 0.89
pred8x8_mad_cow_dc_0l0_8_neon: 0.93 0.93 1.37
pred8x8_mad_cow_dc_0lt_8_neon: 1.37 1.41 1.68
pred8x8_mad_cow_dc_l0t_8_neon: 1.21 1.17 1.32
pred8x8_mad_cow_dc_l00_8_neon: 1.24 1.19 1.60
pred8x8_plane_8_neon: 3.36 3.58 3.76
pred8x8_top_dc_8_neon: 0.97 0.99 1.43
pred8x8_vertical_8_neon: 0.86 0.78 1.18
pred16x16_dc_8_neon: 1.20 1.06 1.49
pred16x16_dc_128_8_neon: 0.83 0.95 0.99
pred16x16_horizontal_8_neon: 1.78 0.96 1.59
pred16x16_left_dc_8_neon: 1.06 0.96 1.32
pred16x16_plane_8_neon: 5.78 6.49 7.19
pred16x16_top_dc_8_neon: 1.48 1.53 1.94
pred16x16_vertical_8_neon: 1.39 1.34 1.98
In particular, on Cortex A72, many of these functions are slower
than the compiler generated code, while they're more beneficial on
e.g. the Cortex A73.
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes building with MSVC after
a2a38b1606.
Remove the stray semicolon, and add casts for the input argument
(which is an intptr_t*) to the right type (PVOID volatile *).
Signed-off-by: Martin Storsjö <martin@martin.st>
Print every error in the stack, if more than one, and don't print
bogus errors if there's none logged within OpenSSL.
Retain the underlying IO error code, print an error message out of
it, and pass the error code on to the caller.
Signed-off-by: Martin Storsjö <martin@martin.st>
If b-frames were enabled implicitly (if max_b_frames wasn't set by
the caller at all, since a0949d0bcb),
we wouldn't offset dts at all, producing invalid pts/dts combinations
(causing loud warnings by ffmpeg, or muxer errors if passed without
an extra cleanup pass).
Instead use frameIntervalP for offsetting, which should always be
accurate.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This is much less precise than the cycle counter register, but
the cycle counter register is not available on apple platforms
(and on linux, it requires a kernel module for allowing user mode
access).
Signed-off-by: Martin Storsjö <martin@martin.st>
If the edit lists remove parts of the output timeline, or add a
delay to it, this should be included in the mvhd/tkhd/mdhd durations,
which should correspond to the edit lists.
For tracks starting with pts < 0, the edit list trims out the segment
before pts=0. For tracks starting with pts > 0, a delay element is
added in the edit list, delaying the start of the track data.
In both cases, the practical effect is that the post-edit output
is as if the track had started with pts = 0. Thus calculate the range
from pts=0 to end_pts, for the purposes of mvhd/tkhd/mdhd, unless
edit lists explicitly are disabled.
mov_write_edts_tag needs to operate on the actual pts duration of
the track samples, not the duration that already takes the edit
list effect into account.
Signed-off-by: Martin Storsjö <martin@martin.st>
When the check was added (in 3668701f96, in 2015), some IO
functions returned 0 on EOF (in particular, the TCP protocol
did, but the TLS protocol returned AVERROR_EOF). Since
0e1f771d22 in 2017, the TCP protocol also returns AVERROR_EOF
instead of 0, making the check for premature end never have the
intended effect.
Signed-off-by: Martin Storsjö <martin@martin.st>
The previous threshold, 4 KB, maybe was reasonable when it was set
(in 2010), but in today's settings and with typical network speeds
and data sizes, it's pretty small. 32 KB probably is a more reasonable
default now, regardless of input.
This changes the test references for two seek tests.
When using the normal seek function, which boils down to the lseek(2)
function, a seek to an out of bounds position doesn't return an error,
but that condition is only reported when doing the subsequent read
(which returns EOF). When doing more seeks by fast forwarding, the
fact that the seeked to destination is out of bounds is noticed and
reported sooner in these cases.
Signed-off-by: Martin Storsjö <martin@martin.st>
In listen mode with UDP transport, once the sender has sent
the TEARDOWN and closed the connection, poll will indicate that
one can read from the connection (indicating that the socket has
reached EOF and should be closed by the receiver as well). In this
case, parse_rtsp_message won't try to parse the command (because
it's no longer in state STREAMING), but previously just returned
zero.
Prior to f6161fccf8, this caused
udp_read_packet to return zero, which is treated as EOF by
read_packet. But after that commit, udp_read_packet would continue
if parse_rtsp_message didn't return an explicit error code.
To keep the original behaviour from before that commit, more
explicitly return an error in parse_rtsp_message when in the wrong
state.
Fixes: #8840
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously, the hls-fmp4 and hls-fmp4_ac3 tests used the same file
names for init and segment files, which occasionally could cause
corruption and failed tests, if the input files for both tests are
generated in parallel, as they could overwrite each other.
This happened to work some of the time, as the fmp4_ac3 test actually
only checked the init segment file (which the fmp4 test case never
wrote, due to using the incorrect hls_segment_type option) and the
fmp4 test case always regenerated the input files due to mismatched
target and file names.
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously, with the file name not matching the target, the files
were regenerated every time fate is rerun - contrary to the other
test targets in the same file. (While regenerating it every time
might be desireable, as that's what the test is about, the file
at least has a dependency on the ffmpeg executable, making them
regenerated every time the executable is updated - and this change
at least makes it consistent with the rest.)
Signed-off-by: Martin Storsjö <martin@martin.st>
Including codecapi.h and uuids.h in UWP mode doesn't define all defines
properly, ending up with constructs that MSVC silently tolerates, but
that clang errors out on, like this:
DEFINE_GUIDEX(CODECAPI_AVEncCommonFormatConstraint);
Just avoid including codecapi.h completely and hardcode the last few
enum values we use from there. We already use local versions of most
enums from there, due to older mingw-w64 headers being incomplete.
Signed-off-by: Martin Storsjö <martin@martin.st>
This might have been used originally for the decoder parts of
the MediaFoundation wrapper, which aren't merged yet.
Signed-off-by: Martin Storsjö <martin@martin.st>
Just including icodecapi.h + codecapi.h apparently misses some bits,
that MSVC doesn't complain about, but Clang does. Thus add a missing
header to the custom hacky include path (required for keeping
ICodecAPI visible when building in UWP mode, as it is intended to).
The issue in Windows SDK headers about ICodecAPI availability in
UWP/app mode has been reported upstream at
https://developercommunity.visualstudio.com/content/problem/1037125/icodecapi-not-visible-when-compiling-in-uwp-mode.html,
and later also filed in Feedback Hub (which can't be linked to
externally).
Signed-off-by: Martin Storsjö <martin@martin.st>
The framerate field is the one users are supposed to set, but not
all users might be setting it, so it might be good to fall back
time_base in that case.
Signed-off-by: Martin Storsjö <martin@martin.st>
Move the copying of the frame to vos_data further up in the function,
so that when writing the actual frame data for the first frame, it's
clear that the stream really is in annex b format, for the cases where
we create extradata from the first frame.
Alternatively - we could invert the checks for bitstream format. If
extradata is missing, we can't pretend that the bitstream is in
mp4 form, because we can't even know the NAL unit length prefix size
in that case.
Also avoid creating extradata for AVC intra. If the track tag is
an AVC intra tag, don't copy the frame into vos_data - this matches
other existing cases of how vos_data and TAG_IS_AVCI interact in
other places.
Signed-off-by: Martin Storsjö <martin@martin.st>
Sticking a full frame in the extradata works, as the code for writing
the avcC/hvcC extracts the relevant parameter set NAL units - provided
that they actually exist in the frame.
Some encoders don't provide split out extradata directly on init (or
at all). In particular, the MediaFoundation encoder wrapper doesn't
always (depending on the actual encoder device) - this is the case for
Qualcomm's HEVC encoder on SD835, and also on some QSV H264 encoders).
This only works for cases where the moov hasn't already been written
(e.g. when not writing fragmented mp4 with empty_moov, unless using
the delay_moov option).
Signed-off-by: Martin Storsjö <martin@martin.st>
Martin Storsjö