[FFmpeg-devel] [PATCH] mp4a-latm rtp output & dynamic payload type from URL

[Sergiy]

Luca Abeni ????:
>
> First of all, thanks for the patch; I hope to integrate your MP4A-LATM
> support soon (BTW, how can it be tested? Which clients are able to
> receive/play MP4A-LATM over RTP?).
It's for darwin streaming server, that serve online streams for mobile 
phones. So, handy - is good device to test this stream.
>
> However, I think your patch mixes too many changes together, and it 
> should
> be split in various parts. I am also not convinced that all the 
> modifications
> to avio.*, etc are really needed...
I agree, but by default ffmpeg sets "96" dynamic rtp payload type, even 
when multiple streams exists (but dynamic payload have to be unique for 
every stream: 96, 97, ...). That's why payload _type parameter was added.
> Why cannot this functionality be implemented by only modifying 
> rtp-related
> files?
I think, that ff_rtp_get_payload_type have to return dynamic type that 
not reserved by other streams, that's enough.
> Shouldn't the "max_packet_size = s->max_payload_size - latmhdrsize;" go
> inside the "while (size > 0) {" loop? (since latmhdrsize is modified
> inside the loop).
You're right, we can send more bytes, after header sent.

> According to the RFC (Section 4.1), it seems that the LATM
> stream is directly copied in the packet payload, without
> any payload-specific header... 
We sending AudioMuxElement that consists from PayloadLengthInfo and 
PayloadMux
(as described in ISO/IEC 14496-3:2005)
In this code latmhdrsize - is size in bytes of PayloadLengthInfo element.



So here is fixed patch, related only for mp4a-latm:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff.diff
Type: text/x-diff
Size: 9235 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091009/f6f07d9e/attachment.diff>