On Wed, 28 Aug 2013, Luca Barbato wrote:
Some devices expect it this way. ---Not sure if it worthy an option. libavformat/rtpenc.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/libavformat/rtpenc.c b/libavformat/rtpenc.c index d330607..c501870 100644 --- a/libavformat/rtpenc.c +++ b/libavformat/rtpenc.c @@ -187,8 +187,11 @@ static int rtp_write_header(AVFormatContext *s1) break; case AV_CODEC_ID_H264: /* check for H.264 MP4 syntax */ - if (st->codec->extradata_size > 4 && st->codec->extradata[0] == 1) { - s->nal_length_size = (st->codec->extradata[4] & 0x03) + 1; + if (st->codec->extradata_size > 4) { + if (st->codec->extradata[0] == 1) + s->nal_length_size = (st->codec->extradata[4] & 0x03) + 1; + ff_rtp_send_h264(s1, st->codec->extradata, + st->codec->extradata_size); } break; case AV_CODEC_ID_VORBIS: -- 1.8.3.2
Umm... If the extradata is in mp4 format, I'm not sure if any receiver ever would be able to parse what you send (and ff_rtp_send_h264 expects data in either annex b format or with mp4 format nal units, but it wouldn't make any sense of avcC format data).
If, on the other hand, the extradata is in annex-b format, then yes it might make sense. But then you could just as well disable the global header flag to make the encoder inject it into the stream instead of storing it in extradata (or use the appropriate bitstream filter for doing the same).
So I might be reluctantly ok with this if you'd make it only do it for annexb format, not blindly as right now. But I'd prefer to have users just not use global headers if they want such a h264/rtp stream.
// Martin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
