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

[Howard Chu]

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.

> In my opinion, a muxer (or a demuxer) should accept (or produce) only one
> bitstream syntax per codec. If the application wants to use a different
> bitstream syntax, then it should use a bitstream filter for the conversion.

How does the application know that it needs to use a filter? How does it know 
that the syntaxes are different? Why should the application author worry about 
details like this that are otherwise hidden under several layers of binary 
encoding?

>> And if it is, then why hasn't it already been done
>
> This, I do not know.

>> so that libavcodec/h264.c doesn't have to do exactly these
>> same steps (after all, that's where I lifted this code from) ?
>
> This smells like code duplication... :)

Indeed. These functions ought to be collected into a single place. I believe 
the "clean split" between decoder, muxer, and network layer you're alluding to 
is a distinct disadvantage here. Anything that touches H264 has to understand 
how to parse NALUs; that code belongs in a single place usable from all of 
those layers.

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