[FFmpeg-devel] [PATCH] ffserver rtsp bug fixes
Wed May 19 09:10:33 CEST 2010
Luca Abeni wrote:
> On 05/19/2010 08:44 AM, Howard Chu wrote:
>> Luca Abeni wrote:
>>> 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
>>> 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
> 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
>> 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
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
More information about the ffmpeg-devel