For example bitdepth should be printed as 10 instead of 0A. Thanks to Hendrik Leppkes for pointing this out
Signed-off-by: James Almer <jamrial@gmail.com>
byte 8 of dnxhr codec ul should be 0x0D
Signed-off-by: Jason Stevens <jay@wizardofthenet.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '8c76bfacf663ff71cee5264a74d0f9c86addd325':
tcp: Use ff_connect_parallel for RFC 8305 style connecting
Merged-by: James Almer <jamrial@gmail.com>
* commit '6a9c00c09d2bc50c0ea64ba092b2f4afc46aa978':
tls_openssl: Fix checks for SSL_ERROR_WANT_WRITE in nonblocking operation
Merged-by: James Almer <jamrial@gmail.com>
Fixes bug id #7386
Muxer overhead calculations was intented for HLS playlist as Apple's mediastreamvalidator tests were failing.
But applying the same fix for DASH manifest proved counterproductive, as Bandwidth can be used for segment name templates.
Add missing dnxhr mxf container essence ULs to the mxf encoder.
This fixes dnxhr mxf files being quarantined by Avid Media Composer.
Signed-off-by: Jason Stevens <jay@wizardofthenet.com>
Reviewed-by: Baptiste Coudurier
ISOBMFF does not allow AudioSampleEntryV1 in stsd version 0, so
assume the descriptor format is QTFF SoundDescriptionV1. ISOBMFF does
not define a version 2.
This fixes audio decoding for some MP4 files generated with Apple
tools. The additional fields present in SoundDescriptionV1/V2 need to
be read in order to correctly read additional boxes that contain
information required for decoding the stream.
Fixes#7376.
Also see: https://github.com/HandBrake/HandBrake/issues/1555
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
It refers to the uncompressed quantization, therefore is not correct for AAC.
Also change mxf_set_pts to work based on current edit unit if
bits_per_coded_sample is not available.
Fixes error messages in the sample of ticket #7366.
Signed-off-by: Marton Balint <cus@passwd.hu>
Also make sure we set the URL context max packet size accordingly.
Based on a patch by Tudor Suciu <tudor.suciu@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Entries are always at least 8 bytes per the parsing code, so if we
see an impossible entry count avoid massive allocations. This is
similar to an existing check in mov_read_stsc().
Since ff_mov_read_stsd_entries() does eof checks, an alternative
approach could be to clamp the entry count to atom.size / 8.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For cases with dual stack (IPv4 + IPv6) connectivity, but where one
stack potentially is less reliable, strive to trying to connect over
both protocols in parallel, using whichever address connected first.
In cases with a hostname resolving to multiple IPv4 and IPv6
addresses, the current connection mechanism would try all addresses
in the order returned by getaddrinfo (with all IPv6 addresses ordered
before the IPv4 addresses normally). If connection attempts to the
IPv6 addresses return quickly with an error, this was no problem, but
if they were unsuccessful leading up to timeouts, the connection process
would have to wait for timeouts on all IPv6 target addresses before
attempting any IPv4 address.
Similar to what RFC 8305 suggests, reorder the list of addresses to
try connecting to, interleaving address families. After starting one
connection attempt, start another one in parallel after a small delay
(200 ms as suggested by the RFC).
For cases with unreliable IPv6 but reliable IPv4, this should make
connection attempts work as reliably as with plain IPv4, with only an
extra 200 ms of connection delay.
Signed-off-by: Martin Storsjö <martin@martin.st>
