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>
By using ff_avc_write_annexb_extradata instead of the h264_mp4toannexb
BSF, the code for doing the conversion itself is kept much shorter,
there's less state to restore at the end, we don't risk leaving the
AVCodecContext in an inconsistent state if returning early due to
errors, etc.
Also add a missing free if the base64 encoding fails.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids a memory leak (or having to worry about freeing the
config string) if the colorspace isn't accepted.
Signed-off-by: Martin Storsjö <martin@martin.st>
This packetization scheme simply places the full packets into the
RTP packet without any extra header bytes.
Signed-off-by: Martin Storsjö <martin@martin.st>
This requires all NAL units to fit within single RTP packets. It
doesn't change the actual packetization for packets that fit, but
errors out and gives a helpful hint if the NAL units would have to
be split, and signals the right packetization mode in the SDP.
Signed-off-by: Martin Storsjö <martin@martin.st>
According to newer RFCs, this packetization scheme should only
be used for interfacing with legacy systems.
Implementing this packetization mode properly requires parsing
the full H263 bitstream to find macroblock boundaries (and knowing
their macroblock and gob numbers and motion vector predictors).
This implementation tries to look for GOB headers (which
can be inserted by using -ps <small number>), but if the GOBs
aren't small enough to fit into the MTU, the packetizer blindly
splits packets at any offset and claims it to be a GOB boundary
(by using Mode A from the RFC). While not correct, this seems
to work with some receivers.
Signed-off-by: Martin Storsjö <martin@martin.st>
If the sdp is generated before the rtp muxer is initialized
(e.g. as when called from the rtsp muxer), this has to be done,
otherwise the rtp muxer doesn't know that the input really is
in mp4 format.
Signed-off-by: Martin Storsjö <martin@martin.st>
Specifying the payload type is useful when the type number has
already been negotiated before creating the stream, for example
in SIP protocol.
Signed-off-by: Martin Storsjö <martin@martin.st>
Move the identical code in rtp_write_header() and
ff_sdp_write_media() inside ff_rtp_get_payload_type()
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This is enabled with an AVOption on the RTP muxer. The SDP
generator looks for a latm flag in the rtpflags field.
Signed-off-by: Martin Storsjö <martin@martin.st>
While not mentioned in RFC 4629, this is required for H.263 in
3GPP TS 26.234. It is in practice required for playback with
Android stagefright and on Samsung bada phones.
Originally committed as revision 26062 to svn://svn.ffmpeg.org/ffmpeg/trunk
