Since d607861c, service can not be NULL, only "0".
An UDP address with neither local port nor address leaves both
service and node to their default value, and POSIX specifies
that they are not allowed to be both NULL; "0" is equivalent
to an unspecified port for all currently known protocols.

Fix CID 1341570.

Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

(Ticket 4389)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Lou Logan <lou@lrcd.com>

Fixes invalid read.
Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Fixes Ticket5467 "Lossless j2k information no longer shown"

Based on suggestion by Hendrik Leppkes
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Found-by: ubitux
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Found-by: ubitux
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This isnt really needed on most platforms but
fixes CID1362183
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

improve quality on axis drawing with yuv422p and yuv420p format
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Missing docs found by: nevcairiel

RFC: should we add support so that the C field names always work as av option names/keys ?
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Missing docs found by: nevcairiel

RFC: should we add support so that the C field names always work as av option names/keys ?
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Missing docs found by: nevcairiel
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes build on mingw32 with SDL

reverts one line from 96d61605Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Adding hybrid log-gamma (https://en.wikipedia.org/wiki/Hybrid_Log-Gamma)
based on the standardization in ARIB STD-B67:
http://www.arib.or.jp/english/html/overview/doc/2-STD-B67v1_0.pdf

The choice of enum value of 18 is consistent with HEVC:
http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=10481

And also with latest proposal for color format in mkv:
https://mailarchive.ietf.org/arch/search/?email_list=cellar&gbt=1&q=Colour+Format+proposal

The implementation assumes a nominal input range of [0, 1], which is
consistent with HEVC.
Signed-off-by: Neil Birkbeck <neil.birkbeck@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Fixes Ticket5598
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Directly adapted from libav

The CONSTQP enum value is 0, so this check failed for it.

Otherwise timestamps/pending FIFOs would go out of sync if nvEncodePicture ever fails.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

Padding before the first sync word can be very large for DTS-in-WAV
streams. There is no reason to include this padding in parsed packet.
Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

This is now required by dcadec_decode_frame(). All remaining users of
avpriv_dca_convert_bitstream() have been updated to expect EXSS marker.
Signed-off-by: James Almer <jamrial@gmail.com>

Remove half-working attempt at supporting unchecked bitstream reader by
always copying input data into intermediate buffer with large amount of
padding at the end.

Convert LBR decoder to checked bitstream reader. Convert
dcadec_decode_frame() to parse input data directly if possible.
Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

Use explicit nvenc capability checks instead to determine usable devices
instead of SM versions.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>