incomplete keyframes on motion

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

incomplete keyframes on motion

ricky-27
Hi all,
I'm trying to add H263 video support in my win32 VoIP client project using precompiled dlls of avcodec (avcodec-51.dll, avformat-51.dll, avutil-49.dll). When the sender A encode the video streaming with AVFrame.quality >= 900 and send it via RTP to B, the receiver B decode the streaming very well, but if the sender A encode with AVFrame.quality < 900 (ie. 200) the receiver B displays incomplete keyframes when there's some motion in the captured image (it's hard to explain!). This dll files works fine on another VoIP software client (OpenWengo).

Please see the decoded screenshots: http://www.sendspace.com/file/rpspwq

where i'm wrong?

thanks... and sorry for my english
Ricky
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
_______________________________________________
libav-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
Reply | Threaded
Open this post in threaded view
|

Re: incomplete keyframes on motion

Luca Abeni
Hi Ricky,

[hidden email] wrote:
[...]
 > When the sender A encode the video streaming with AVFrame.quality >= 900
> and  send it via RTP to B, the receiver B decode the streaming very well,
 > but if the sender A encode with AVFrame.quality < 900 (ie. 200) the
> receiver  B displays incomplete keyframes when there's some motion in the
> captured image  (it's hard to explain!). This dll files works fine on
 > another VoIP software client (OpenWengo).
>
> Please see the decoded screenshots: http://www.sendspace.com/file/rpspwq
>
> where i'm wrong?

Since you are not providing any information about the RTP code you are using,
it's hard to say... Anyway, my guess is that there is a bug in your RTP
packetization code for H.263 video.
In particular, it is very likely that your code doesn't correctly cope with
large frames, which should be split in different RTP packets: when you set a
large AVFrame.quality value, small frames are generated, and they probably
fit in a single RTP packet; when you decrease AVFrame.quality, the frame size
becomes larger than a single network packet, and your packetization code does
something wrong in splitting the frame.

I would suggest to avoid using your own RTP code, and to use libavformat for
sending RTP packets... You just need to implement support for H.263 video in
RTP (but since you are currently able to send some H.263 video over RTP, you
probably already have some almost-working code...).

If you implement support for H.263 video in libavformat (you'll have to write
an ff_rtp_send_h263() function in libavformat/rtpenc_h263.c and to properly call
it from libavformat/rtpenc.c) and post your modifications to ffmpeg-devel, the
code can be reviewed, and ffmpeg's developers can be able to give hints and to
help you in fixing your bug.


                                Luca
_______________________________________________
libav-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
Reply | Threaded
Open this post in threaded view
|

Re: incomplete keyframes on motion

ricky-27
Many thanks Luca,

I will try....







Ricky



> ----- Original Message -----
> From: Luca Abeni
> Sent: 17/06/08 09:55 am
> To: Libav* user questions and discussions
> Subject: Re: [libav-user] incomplete keyframes on motion
>
> Hi Ricky,
>
> [hidden email] wrote:
> [...]
>  > When the sender A encode the video streaming with AVFrame.quality >=
> 900
> > and  send it via RTP to B, the receiver B decode the streaming very
> well,
>  > but if the sender A encode with AVFrame.quality < 900 (ie. 200) the
> > receiver  B displays incomplete keyframes when there's some motion in
> the
> > captured image  (it's hard to explain!). This dll files works fine on
>  > another VoIP software client (OpenWengo).
> >
> > Please see the decoded screenshots:
> http://www.sendspace.com/file/rpspwq
> >
> > where i'm wrong?
>
> Since you are not providing any information about the RTP code you are
> using,
> it's hard to say... Anyway, my guess is that there is a bug in your RTP
> packetization code for H.263 video.
> In particular, it is very likely that your code doesn't correctly cope
> with
> large frames, which should be split in different RTP packets: when you
> set a
> large AVFrame.quality value, small frames are generated, and they
> probably
> fit in a single RTP packet; when you decrease AVFrame.quality, the frame
> size
> becomes larger than a single network packet, and your packetization code
> does
> something wrong in splitting the frame.
>
> I would suggest to avoid using your own RTP code, and to use libavformat
> for
> sending RTP packets... You just need to implement support for H.263 video
> in
> RTP (but since you are currently able to send some H.263 video over RTP,
> you
> probably already have some almost-working code...).
>
> If you implement support for H.263 video in libavformat (you'll have to
> write
> an ff_rtp_send_h263() function in libavformat/rtpenc_h263.c and to
> properly call
> it from libavformat/rtpenc.c) and post your modifications to
> ffmpeg-devel, the
> code can be reviewed, and ffmpeg's developers can be able to give hints
> and to
> help you in fixing your bug.
>
>
> Luca
> _______________________________________________
> libav-user mailing list
> [hidden email]
> https://lists.mplayerhq.hu/mailman/listinfo/libav-user
>

_______________________________________________
libav-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user