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

Michael Niedermayer michaelni
Wed May 19 14:53:25 CEST 2010

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


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100519/b6be43e4/attachment.pgp>

More information about the ffmpeg-devel mailing list