Until now, we would have only attempted to utilize already decrypted
data if it was enough to fill the size of buffer requested, that could
very well be up to 32 kilobytes.
With keep-alive connections this would just lead to recv blocking
until rw_timeout had been reached, as the connection would not be
officially closed after each transfer. This would also lead to a
loop, as such timed out I/O request would just be attempted again.
By just returning the available decrypted data, keep-alive based
connectivity such as HLS playback is fixed with schannel.
The dec_buf seems to be properly managed between read calls,
and we have no logic to decrypt before attempting socket I/O.
Thus - until now - such data would not be decrypted in case of
connections such as HTTP keep-alive, as the recv call would
always get executed first, block until rw_timeout, and then get
retried by retry_transfer_wrapper.
Thus - if data is received - decrypt all of it right away. This way
it is available for the following requests in case they can be
satisfied with it.
Utilizes a subpicture sample with one decodable subpicture for the
test.
Based on a failing test case in reported by Michael in
https://ffmpeg.org/pipermail/ffmpeg-devel/2019-February/240398.html
which at the time had no test case for it.
Additionally, this is the first test case for the presentation
graphics format.
Each time the sub2video structure is initialized, the sub2video
subpicture is initialized together with the first received heartbeat.
The heartbeat's PTS is utilized as the subpicture start time.
Additionally, add some documentation on the stages.
This way re-initializations properly update end_pts, enabling
sub2video_heartbeat to call sub2video_update as expected to re-init
the sub2video AVFrame's contents and to feed a frame into the filter
chain.
This then fixes memory usage ballooning due to framesync waiting
for secondary input in case of no actual subtitle samples being present
for a while in source after a re-init occurs.
Fixes some rather embarrassing mistakes that somehow passed my
eyes.
* Now catches if memory allocation has failed during bprint usage
by checking av_bprint_is_complete().
* Now catches if adding an ASS rectangle into an AVSubtitle failed.
* Returns AVERROR_INVALIDDATA if we get an invalid region buffer
length.
This enables us to read the data coding type utilized for
a specific private data stream, of which we currently are
interested in ARIB caption streams.
The component tag limitations are according to ARIB TR-B14,
and the component IDs are defined in ARIB STD-B10.
* Outputs ASS lines with basic coloring and font scaling for each
given region.
* Sets the default style to the resolution of the subtitle plane
(for example, 960x540 / 36pt font for profile A).
* Has options to:
* Disable ruby text (which is coded as regions which have
half-height text in libaribb24).
Enabled by default as without positioning ruby text only
confuses as it is usually coded in the beginning of the decoded
subtitle line.
* Set the working directory, in which libaribb24 will read
configuration as well as into which it may save broadcast extra
symbols as PNG.
Unset by default.
The unconventional library check can be explained by the library's
current master branch being licensed as LGPLv3, but at the time of
writing the latest official release is still licensed under GPLv3.
Thus, one either has to wait for the following release, or enable
GPLv3.
Fixes issues when a subtitle packet is received before PCR for the
program has been received, leading to wildly jumping timestamps
on the lavf client side as well as in the re-ordering logic.
This usually happens in case of multiplexes where the PCR of a
program is not taken into account with subtitle tracks' DTS/PTS.
Internally in ISOBMFF the FLAC-in-ISOBMFF draft uses "fLaC"
as the identifier for FLACSampleEntry, and there seems to be no
MPEG-DASH specification for the in-manifest identifier for FLAC.
After testing the browsers' implementations, it seems like all of
the major browser vendors have decided to utilize the MIME type for
FLAC ("audio/flac") as the identifier. This change set leads to
that string being utilized for FLAC streams instead of the sample
entry identifier ("fLaC"), which is the default behavior.
Verified by auri_ on IRC to play with the major browsers.
ISMV lacks any sort of edit list support, as well as tfxd is
effectively the PTS of the fragment for most intents and purposes.
Thus, if b-frames are requested without negative CTS offsets you
end up with N frames' worth of delay (tfxd PTS plus the CTS offset
of the first sample). Negative CTS offsets enable the first sample
to have CTS=DTS, and thus a/v desync due to b-frame reorder delay
is avoided.
These files depend on libavformat, and the vf_srcnn filter
currently is the only thing utilizing these dnn_* files and
already happens to have a dependency on libavformat.
This fixes compilation in cases where libavformat is not a
dependency for libavfilter.
Reported by Kam_ on IRC.
Yet another case of forgotten 0 =! EOF translation.
While the documentation for this specific synchronous read
function does not mention it, the documentation for
`sftp_async_read` documents it, as well as looking at the
implementation of this function leads one to find
`if (handle->eof) { return 0; }`.
Reported by stnutt on IRC.
It exists, so why not use it? Helps one get rid of additional
search path related flags in addition to PKG_CONFIG_{PATH,LIBDIR}
when utilizing a cross-prefix separate from the sysroot.
Enables one to test possibly nonstandard formats such as Opus or
FLAC in ISOBMFF, among other things.
This becomes much more useful if output segment format becomes an
option, or if the WebM segment feature gets removed.
It has not ever been working and has not been validated,
Additionally, mention that the segment file names should be changed
to end with webm instead of m4s, which is utilized for ISOBMFF
fragments.
With certain types of input and the filter chain getting re-initialized
or re-configured, multiple nullptr AVSubtitles can get pushed into
sub2video_update() in a row from sub2video_heartbeat.
This causes end_pts, and on the next round pts, to become INT64_MAX,
latter of which signals EOF in framesync, leading to complete loss of
subtitles from that point on.
Thus, check that the sub2video.end_pts is smaller than INT64_MAX
in a similar fashion to sub2video_flush before sending out the
nullptr AVSubtitle. This keeps premature EOFs from happening in
framesync and the subtitle overlay is kept past the filter chain
re-initializations/configurations.
Enables having proper bit rate values being written into the master
playlist in case of hard-constrained VBR where the maximum bit
rate utilized is known before hand.
Does the same thing as movenc.c, for example.
Signed-off-by: Jan Ekström <jan.ekstrom@aminocom.com>
Makes the uninit function re-entrable, which can be a common case
when an API user first tries to initialize its context, fails, and
then finally unrefs the AVHWDevice.
Fixes a crash reported by sm2345 on IRC.
This FFmpeg-specific "fuzzer fix" was never perfect, but now it
stopped encoding of actual content with a big enough DTS shift.
This returns the function to its original state of results
before negative CTS offsets were added.
I remember dealing with this function before, but somehow had
forgotten about it during VDD. The test cases not tripping this
over also didn't help.
This enables having multiple tracks of the same type which would
be treated as different things by the media server (as opposed to
different bit rate versions of the same track). According to the
smooth streaming specification, just setting the systemLanguage
tag is not enough to note that a track with the same attributes
differs from another one.
Reviewed-by: Martin
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Streaming servers appear to ignore all other language metadata.
Signed-off-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Josh de Kock <josh@itanimul.li>
This way, in case of bit rate not being set, max_bitrate will be
used instead. This enables, for example, re-using max_bitrate
information from the input or doing transcoding with a rate
control mode that is not bit rate based.
Signed-off-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Widen the values from limited to full range and use BT.709 where it
should be used according to the video resolution:
SD is BT.601, HD is BT.709
Default to BT.709 due to most observed HDMV content being HD.
BT.709 coefficients were gathered from the first two parts of BT.709
to BT.2020 conversion guide in ARIB STD-B62 (Pt. 1, Chapter 6.2.2).
They were additionally confirmed by manually calculating values.
Functionality used before didn't widen the values from limited to
full range. Additionally, now the decoder uses BT.709 where it
should be used according to the video resolution.
Default for not yet set colorimetry is BT.709 due to most observed
HDMV content being HD.
BT.709 coefficients were gathered from the first two parts of BT.709
to BT.2020 conversion guide in ARIB STD-B62 (Pt. 1, Chapter 6.2.2).
They were additionally confirmed by manually calculating values.
Fixes#4637
With cli usage the decoder might have not set the colorspace during
encoder init, manual colorspace override might be needed in such
cases.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This applies commit 5de64bb3 (the source of the above commit message)
to libutvideoenc as well.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The official Ut Video decoder only threads with slices, thus until
now any files encoded by the libavcodec encoder have only been
decodable with a single thread. The default slice count is now
set to subsampled_height / 120.
Also sets slices to 1 for the Ut Video encoder tests to keep them
green.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The official Ut Video decoder only threads with slices, thus until
now any files encoded by the libavcodec encoder have only been
decodable with a single thread. The default slice count is now
set to subsampled_height / 120.
Also sets slices to 1 for the Ut Video encoder tests to keep them
green.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
With cli usage the decoder might have not set the colorspace during
encoder init, manual colorspace override might be needed in such
cases.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Makes it easier to recreate an AVCodecContext for ATRAC3+ decoding,
which is needed in multimedia frameworks, as well as in general cases
where demuxing and decoding are separate entities.
Put the zero length check in place of code that was never used
during decoding, as zero-length slices were generally refused
in decode_frame().
Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>
The failures on various architectures and compilers on the RGB(A)
tests seem to have been because of one-off YCbCr->RGB conversion
results. This should make the conversion results match on most if
not all code paths.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The failures on various architectures and compilers on the RGB(A)
tests seem to have been because of one-off YCbCr->RGB conversion
results. This should make the conversion results match on most if
not all code paths.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
General cosmetics, such as keeping lines under 80 characters,
fixing a couple of typos (predition -> prediction) and a
general style fix that was pointed out by Derek when I was having
my sliced multithreading patch in review by him.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Jan Ekström
Jan Ekström