[Live-devel] what if MultiFramedRTPSource::doGetNextFrame1 get a multiframed packet?

[xiang zou]

+------+------+------------+------+------------+------+------------+------------+-----------------+
    | RTP   |  VP   |Video Packet|  VP    |Video Packet   |  VP   |Video
Packet|
    |header |header|     (1)           |header|    (2)
|header|    (3)            |

+------+------+------------+------+------------+------+------------+------------+------------------+
Just like the figure above(I copy it from RFC3016),can we get timestamp
information of every Video Packet from VP header?As you said,"we don't
actually decode the media data", what does it mean?since in my opinion,most
time we not only get every frame but send them to the decoder,doesn't the
decoder need timestamp information for every frame?And a new question, I
found some figures(like before)in RFC3016 use Video Packet and VOP,but the
expression "Video Packet" can hardly be seen in ISO14496,is there anything
wrong with it?

2008/9/16 Ross Finlayson <finlayson at live555.com>

> At 10:45 PM 9/15/2008, you wrote:
>
>> I read the source code again,yes,"MPEG4GenericRTPSource" indeed implements
>> multiple frames per packet by reimplementation of the virtual function
>> "MPEG4GenericBufferedPacket::nextEnclosedFrameSize()",but it had not update
>> the "fPresentationTime" after the first received frame,since
>> "frameDurationInMicroseconds" is always 0.In that case,from a multiframed
>> packet,we will get several frames with the same timestamp,is it a bug?
>>
>
> In principle, yes.  However, in practice, because we don't actually decode
> the media data, it would be difficult for an implementation to figure out
> the duration of each frame within the packet, so we don't try to do this.
>
>
>
>        Ross Finlayson
>        Live Networks, Inc. (LIVE555.COM)
>        <http://www.live555.com/>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20080916/803b998f/attachment-0001.html>