When checking pix_fmt mapping, some bitstreams are mapped to an
incorrect pix_fmt instead of being rejected (ENOSYS).
Actually, such bitstreams are not supported (FFmpeg encoder does not
produce such bitstream, such bitstream may come only from another
encoder for the moment).
- JPEG 2000 RCT 11/13/15/16 bit depths are mapped to a 8-bit FFmpeg
pix_fmt (e.g. bgr0), which is not expected.
- JPEG 2000 RCT 9/10/12/14 bit depths with alpha are mapped to a
FFmpeg pix_fmt without alpha (e.g. AV_PIX_FMT_GBRP9 for 9-bit with
alpha), which is not expected.
The order for choosing the pix_fmt is changed to the one used by YCbCr
selection (<=8 bit first).
" && !f->transparency" is added to the other lines.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'c8dcff0cdb17d0aa03ac729eba12d1a20f1f59c8':
h264: factor out calculating the POC count into a separate file
Merged-by: Clément Bœsch <u@pkh.me>
* commit '113aeee6aed35cb786a9f6d69b0cb210f498b9da':
h264_parser: move the H264DSPContext to the parser context
H264Context is kept locally as it is currently needed for logging
(h->avctx as log context) and for is_avc and nal_length_size. These
later fields will later be obtained when the extradata parsing is
decoupled from the decoder. This code will be updated accordingly when
that commit is merged.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '3176217c60ca7828712985092d9102d331ea4f3d':
h264: decouple h264_ps from the h264 decoder
Main changes:
- a local GetBitContext is created for the various
ff_h264_decode_seq_parameter_set() attempts
- just like the old code, remove_sps() is adjusted so it doesn't remove
the pps.
Fixes decode with Ticket #631http://ffmpeg.org/pipermail/ffmpeg-user/attachments/20111108/dae58f17/attachment.mp4
but see next point as well.
- ff_h264_update_thread_context() is updated to work even when SPS
isn't set as it breaks current skip_frame code. This makes sure we
can still decode the sample from ticket #631 without the need for
-flags2 +chunks. (Thanks to Michael)
- keep {sps,pps}_ref pointers that stay alive even when the active
pps/sps get removed from the available lists (patch by michaelni with
additionnal frees in ff_h264_free_context() from mateo)
- added a check on sps in avpriv_h264_has_num_reorder_frames() to fix
crashes with mpegts_with_dvbsubs.ts from Ticket #4074http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4074/mpegts_with_dvbsubs.ts
- in h264_parser.c:h264_parse(), after the ff_h264_decode_extradata() is
called, the pps and sps from the local parser context are updated with
the pps and sps from the used h264context. This fixes fate-flv-demux.
- in h264_slice.c, "PPS changed between slices" error is not triggered
anymore in one condition as it makes fate-h264-xavc-4389 fails with
THREADS=N (Thanks to Michael)
Merged-by: Clément Bœsch <clement@stupeflix.com>
Merged-by: Michael Niedermayer <michael@niedermayer.cc>
Merged-by: Matthieu Bouron <matthieu.bouron@stupeflix.com>
VideoToolbox doesn't supply parameter sets until the first frame is done
encoding. This spins up a temporary encoder and encodes a single frame to
get this data.
Signed-off-by: Rick Kern <kernrj@gmail.com>
All HE-AAC samples with an LFE channel make this warning get spammed on
every frame. Turning off SBR for LFE channels makes sense (since it has
much less coefficients than normal channels do), so this error print is
of no value in this case.
It makes sense to keep the error in other cases, hence why it's still
around, degraded to warning severity since the decoder will still
attempt to decode without SBR.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Codec width/height restrictions seem hardcoded at the OMX level and
seem arbitrary. Bypassing those restrictions allows a device to decode
streams at higher resolutions.
For example it allows a Nexus 5 to decode h264 streams with a resolution
higher than 1920x1080.
