[FFmpeg-devel] [PATCH] ffserver rtsp bug fixes

[Luca Abeni]

On 20/05/10 15:30, Howard Chu wrote:
[...]
>>> I don't think the muxer's complexity has been harmed by these
>>> patches. On
>>> the other hand, I've just taken a look at the h264_mp4toannexb filter
>>> source code and it is quite dense. Also, anything that does
>>> "alloc_and_copy" is a bad idea from a memory and CPU resource
>>> perspective.
>>>
>>> If bitstream filters were capable of operating in-place on the data, I
>>> might agree with you. But to me it just looks like a useless pig.
>>
>> if you want bsfs to do something they cant currently, i suggest you
>> fix bsfs
>
> I guess I was looking at it the wrong way. Currently the RTP mux looks
> for the 3-byte start code and strips that off before sending the data.

It's a little bit more than that...
The packetiser needs to split a frame in NALs to correctly distribute 
them in the RTP packets (trying to send one NAL per packet - when 
possible -, generating the proper payload header - which might depend on 
the NAL type -, etc...)

> So in fact, neither the native H264 format nor the AVC1 variant are
> "proper" for it, and there ought to be 2 bsfs available - one to take
> AVC1 input and feed stripped NAL output, and one to take H264 input and
> feed stripped NAL output.

Not sure about this... How can the demuxer split a frame in NALs, then?


				Luca