Also adds a lot of infrastructure necessary for it.
Some of it is a bit ugly though.
Increases binary size for hardcoded tables by about 12 kB,
which is about 15 kB from qdm2_table minus data and code
saved that was only used for creating it.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This is the order that the caller uses in the rest of the file. The
same operation is applied to both parameters, so this change is only
done for consistency, it doesn't change the actual behaviour.
Bug-Id: CID 732285 / CID 732286
The pts and the corresponding duration is written in sidx
atoms, thus make sure these match up correctly.
Signed-off-by: Martin Storsjö <martin@martin.st>
Since this structurally is quite different from normal RTP
(multiple streams are muxed into one single mpegts stream,
which is packetized into one single RTP session), it is kept
as a separate muxer.
Since this structurally also behaves differently than normal
RTP, all of the other muxers that do chained RTP muxing
(rtsp, sap, mp4) would need to be updated similarly to handle
this - in particular, creating one single rtp_mpegts muxer
for the whole presentation instead of one rtp muxer per stream.
Signed-off-by: Martin Storsjö <martin@martin.st>
The packetizer only supports splitting at GOB headers - if
such aren't available frequently enough, it splits at any
random byte offset (not at a macroblock boundary either, which
would be allowed by the spec) and sends a payload header pretend
that it starts with a GOB header.
As long as a receiver doesn't try to handle such cases cleverly
but just drops broken frames, this shouldn't matter too much
in practice.
Signed-off-by: Martin Storsjö <martin@martin.st>
Instead explicitly jump to the default case in the cases where
it is wanted, and avoid fallthrough between different codecs,
which could easily introduce bugs if people editing the code
aren't careful.
Signed-off-by: Martin Storsjö <martin@martin.st>
ff_mpv_common_init sets s->context_initialized.
This fixes decoding of h261 in the cases where the demuxer
hasn't already set the frame size.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
For rgb, with a 1080p source, 69 to 74fps on core i5(2 core, 1.8GHz),
and 136 to 160 fps on an core i7(4770R, 3.2Ghz)
Changed the yuv code for consistency, even though the performance
increase is not as obvious as rgb
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'df07c07b3de0a5e8890078944de1eb5cb8372ef8':
rtpdec_h263_rfc2190: Clear the stored bits if discarding buffered data
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '01f251c44d83eedc819625d2caac9ff9697a085d':
rtpenc: Set the timestamp properly when sending mpegts data, too
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This avoids trying to do sliced encoding, even if a slice/packet
size is requested (via the -ps option or the rtp_payload_size
field), since the encoder currently doesn't support it (or at least
our decoder can't decode it, even if the h261_encode_gob_header
function is hooked up to be called from the slicing part in
mpegvideo_enc.c).
Signed-off-by: Martin Storsjö <martin@martin.st>
If we throw away the buffered incomplete frame, make sure to also
throw away the buffered bits of an incomplete byte at the same
time.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
In particular, when packetizing mpegts into rtp, the input packet
timestamp may come from more than one stream, which could cause
multiple packets be written with the same timestamp.
Signed-off-by: Martin Storsjö <martin@martin.st>
