[Ffmpeg-devel] Decode a RTP stream in H.263

[Cool_Zer0]

Ryan Martell wrote:
>
> On Nov 30, 2006, at 10:38 AM, Cool_Zer0 wrote:
>
>> On 11/30/06, Ryan Martell <rdm4 at martellventures.com> wrote:
>>>
>>> Hi-
>>>
>>> On Nov 30, 2006, at 4:42 AM, Michael Niedermayer wrote:
>>> > Hi
>>> >
>>> > On Thu, Nov 30, 2006 at 10:05:22AM +0000, Cool_Zer0 wrote:
>>> >> Hi there!
>>> >>
>>> >> I have a question. I've look on the documentation sectional of
>>> >> FFMpeg page
>>> >> and check the code but I can't figured it out.
>>> >>
>>> >>
>>> >> My main purpose, for now, is decode H.263, that I receive by RTP,
>>> >> and then
>>> >> show it on my PDA screen.
>>> >>
>>> >> So... I already have the RTP stack and I can extract the encoded
>>> >> H.263packet.
>>> >>
>>> >> My main question when I look through "libavcodec/h263dec.c" is
>>> >> that you have
>>> >> a decode_init(), a decode_end() and then a decode_frame(). (I
>>> >> think I'm
>>> >> right!!!)
>>> >>
>>> >>
>>> >> And now the ultimate question:
>>> >> - Can I call decode_frame() for each packet that I receive?
>>> >> - What will happen if the packet that I received doesn't contain the
>>> >> complete frame?
>>> >
>>> > you will have to use a AVParser
>>> >
>>> >>
>>> >>
>>> >> Another question:
>>> >>
>>> >> On decode_init() you have:
>>> >>
>>> >> /* select sub codec */
>>> >> switch(avctx->codec->id) {
>>> >>   case CODEC_ID_H263: ...
>>> >>   case CODEC_ID_MPEG4: ...
>>> >>   case CODEC_ID_MSMPEG4V1: ...
>>> >>   ...
>>> >>   case CODEC_ID_FLV1: ...
>>> >>
>>> >> I'm wondering if that switch is to say: "The result of the
>>> >> decoding process
>>> >> will be a [MPEG4, WMV3, ...]".... Can't I say that I want the
>>> >> result on YUV
>>> >> or RGB?
>>> >
>>> > go and read apiexample.c
>>>
>>> Have you just tried it yet?
>>
>>
>>
>> I just finished the building (it gives some fight on Windows Mobile).
>>
>>
>> rtp.c has the H263 codec in it for a non-
>>> dynamic transport protocol type.  It might just work:
>>
>> ./ffplay rtsp://blahblahblah/file.sdp
>>
>>
>>
>> Hummm... But I don't have RTSP... I don't know the RTSP specification
>> but in
>> my case I have a Desktop client that make a "video call" to my VoIP
>> application (that I'm developing)... The desktop client sends me
>> H.263packets generated with Microsoft RTC. In my PDA application I
>> want to
>> receive that packets and the decode in order to show them.
>
> Well, ffmpeg has the rtsp stuff built into it too, if you can compile
> it with the networking enabled.  RTSP is the session protocol, which
> sets up the rtp streams, which (generally) you have two of- an audio
> and a video.  So if it's a standard rtsp type stream, ffmpeg will
> handle the audio and the video, and the syncing for you.
>
> Now, if you CAN"T do that, I think you will have a difficult time of
> syncing the audio and video.
>

Hummm.. I think that I don't have problems with syncing... That problem
appears if we have the entire video on the server and then we stream it
to the client... In my case I'll receive the packets and then show it at
the same time...


> But the answer to your question:
>
>> I could use the stack of FFMPeg but since I'm already using other RTP
>> stack
>> (because I have sound too) I think is better to use only one stack,
>> instead
>> of using 2 different stacks.
>
>> So... What you are saying is that I can't use directly the h263dec.c,
>> right?
>
> No, you could do that, but I'm not sure how much stuff you would have
> to modify.  Go back to Michael's answer and check out apiexample.c. 
> You would want to put the packets you got into an AVParser, and let it
> do the right thing with figuring out complete frames though.
>

OK... In this weekend I'll try to do some tests and see if AVParser can
be used in my case.


>> It's better for me to use the entire RTP stack of ffmpeg? I imagine
>> that the
>> RTP stack do the assembling of packets and other interessing stuff,
>> right?
>> If I don't use the rtp of ffmpeg I have to do by myself, right?
>
> Yes; also it does the a/v syncing (or at least keeping the timestamps
> right).
>
> The problem is that if you have audio coming from one source, and
> video from another, and you were handing the video to ffmpeg to
> decode, when you get ready to display the video, you'll have to figure
> out what the timestamps are, how they have been adjusted, and then
> figure out the audio syncing.  Since ffmpeg can handle audio as well,
> you could let it handle it all for you.
>
> Now, if you absolutely have to let someone else hand you the packets
> for both the audio and video, you could (someone else jump in here if
> this is a bad idea) setup an AVInputFormat.  The input format could
> take whatever packets you get over the wire, and massage them into the
> form that the decoder needs.  This is how ffmpeg handles things like
> http:, file:, etc.  It's not really the best way to do it, but it
> might be the easiest to implement.
>

It may be a solution... I'll test it too :)


Thanks for your support.


> HtH,
> -Ryan
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>