On 28/08/13 11:10, Martin Storsjö wrote:
> 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.
That's why I'm pondering about adding an avoption, there are some
situations in which you want both a valid sdp and in-band ssp/sps so
switching to non-global isn't an option =/
lu
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
