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

[Howard Chu]

Michael Niedermayer wrote:
> On Wed, May 19, 2010 at 12:10:33AM -0700, Howard Chu wrote:
>> Luca Abeni wrote:
>>> On 05/19/2010 08:44 AM, Howard Chu wrote:
>>>> Luca Abeni wrote:
>>>>> Hi,
>>>>>
>>>>> On 05/19/2010 08:24 AM, Howard Chu wrote:
>>>>> [...]
>>>>>>> Note that I still haven't gotten ffserver to successfully stream
>>>>>>> anything from
>>>>>>> a file, there are plenty more problems left to chase down.
>>>>>>
>>>>>> It turns out that streaming just audio from FLV files was working fine.
>>>>>> But the H264 video was encoded as the AVC1 subtype, and none of the sdp
>>>>>> or rtp code handled this. This patch gets RTP working for me from an
>>>>>> FLV
>>>>>> (AVC1) file source.
>>>>>
>>>>> I think this is the wrong solution. The (IMHO) correct one would be to
>>>>> use
>>>>> a bitstream filter to convert the NAL syntax.
>>>>
>>>> Why is that a better solution?
>>>
>>> Because in this way we can separate different functionalities (converting
>>> the bitstream syntax - in the bitstream filter - and packetising the
>>> bitstream - in the rtp mixer) in different parts of the code. And we can
>>> avoid code duplication (and we can reduce the complexity of the rtp muxer
>>> code).
>>> AFAIR, the needed bitstream filter is already there, it just needs to be
>>> used (I used this solution in one of my programs, some time ago... If I
>>> remember well, I just needed to fix some minor issue. But then it worked).
>>
>> 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. 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. Both of 
those could be written in-place, without need for any malloc-and-copy overhead.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/