[FFmpeg-devel] RTP/SVQ3 payload parser
Ronald S. Bultje
rsbultje
Wed Aug 5 01:55:48 CEST 2009
Hi,
On Tue, Aug 4, 2009 at 7:42 PM, Michael Niedermayer<michaelni at gmx.at> wrote:
> On Tue, Aug 04, 2009 at 06:00:42PM -0400, Ronald S. Bultje wrote:
> [...]
>> +/** return 0 on packet, no more left, 1 on packet, 1 on partial packet... */
>
> am i the only one who has difficulty understanding this sentance?
> also as we are already a this, maybe a enum would be better than 0,1,1
Attached is a fix for the typo, the last 1 would have to be a -1.
In general, yes I'm in favour of an enum or some other form of
providing better return values. One of the things I don't like about
the current system for RTP is that I have to cache packets; I can't
tell the caller to re-send the same (input) packet next time. What I
would like:
- have the return value tell me how many bytes of input has been
consumed, like avcodec_decode_*(). A negative value would imply error,
and a value of 0 for the next packet would imply that we didn't use
the current input (which is achieved by returning 1 now) and the same
input should be re-sent.
- At the end, this requires rtsp.c/rtpdec.c to call with buf=NULL to
flush the payload parser.
- The value of pkt->size (or a new integer pointer *data_filled,
similar to avcodec_decode_audio()) would then specify whether we
generated any output data.
So instead of rtp_parse_payload(..., AVPacket *pkt, const uint8_t buf, int len)
{
return 0 on success, 1 on success and more data available, -1 on
more data needed;
}
We'd get:
int rtp parse_payload(..., AVPacket *pkt, const uint8_t *buf, int len)
{
pkt->size = 0; ///< we could also require the caller to do this
if (still_had_data_available) {
fill_pkt(pkt);
return 0; ///< no data consumed
}
// parse buf/len
if (error_while_parsing)
return some_negative_value;
if (have_data)
fill_pkt(pkt);
return len;
}
Let me know what you think of this.
Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtp-x_s3v_es.patch
Type: text/x-diff
Size: 7587 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090804/82eee5b4/attachment.patch>
More information about the ffmpeg-devel
mailing list