RTP streaming of H.264 with bitrates around 600kBit/s

by hayate » Thu, 10 Sep 2009 01:09:11 GMT

Sponsored Links
 I've got a problem when streaming H.264 with bitrates of about 600kBit/
s and a resolution
of 480x320 over RTP to an Android device (HTC Magic).  When playing
the stream, the device
shows decoding artefacts and even gets stuck at some times (in this
case the phone won't play
any streams unless it gets restarted).
The stream actually works well for bitrates up to 500kBits/s. Also the
local playback of the file (with 600kBits/s)
in a mp4 container seems to work without showing artefacts.

For encoding the video file i used mencoder with the following

mencoder version: MEncoder SVN-r29411-4.4.0

mencoder input.flv -nosound -vf scale=480:320 -ovc x264 -x264encopts
decimate=1 -ofps 30 -of rawvideo -o test.h264

I tired playing with the the vbv-bufsize parameter of x264encopts,
setting it to 10-200 which resulted therein
that the phone didn't got stuck during playback, but still showing

The question is if there are any options which would make the video
play without artefacts, because the
site about supported media formats ( http://developer.android.com/guide/ 
says that average bitrates up to 600kBits/s should work fine, or is
the processing overhead for RTP simply
to much to handle for the CPU of the device?


RTP streaming of H.264 with bitrates around 600kBit/s

by RaviY » Thu, 10 Sep 2009 11:58:09 GMT

 My immediate reaction would be to go with the thought that "RTP
processing overhead is higher" compared to progressive streaming or
local playback of a similar file.

One experiment that you could try is to reduce the frame rate (which
would reduce the RTP packets throughput) to see if that helps.

Usually artifacts are because of dropped packets. If you like to get
your hands dirty, you could look into the code to find out if there
are any packets being dropped.



Sponsored Links

Other Threads

1. Which Intent Flags when setting PendingIntents in multiple app widget scenario?

I have one WidgetProvider but expect the user to have multiple
instances of the widget on the home screen.

When the user clicks on the widget, an intent is fired to start an
activity A passing a String extra (which is specific to that instance
of the app widget).

Everything works fine unless the activity is already running, in which
case the activity is shown in its previous state (and so the intent
extra data is ignored).

I've tried using various Intent flags (like FLAG_ACTIVITY_NEW_TASK)
but they don't seem to help.

I suppose I could implement something in onResume() but that seems
like a hack.

Any tips?

Note: I'm testing on a Nexus One.


2. Smarter widget updates


I have a widget that displays detailed WiFi state (SSID, signal, etc).

It registers in the manifest to receive various android.net.wifi.*
notifications. So far so good.

However, these notifications are not sent if the home screen is side-
scrolled, or phone is locked. This is good - Android framework
notifying only visible widgets improves battery time and performance.

The bad side of this, though, is that since WiFi state can change when
the widget is not visible, I have to request frequent scheduled
updates in my <appwidget-provider> xml descriptor to bring the widget
up to date when it's scrolled into view or screen is unlocked.

After the widget comes into view and is updated, further updates could
be driven by android.net.wifi.* notifications, {*filter*}scheduled
onUpdate()'s continue to run, which is a waste.

Is there a way to register my AppWidgetProvider for a smart one-tme
update when it's becomes visible, either after side-scrolling, or
after the screen is unlocked?


3. Review CM5 on G1

4. adp1/N1 & Eclair

5. OpenID for Android?

6. How to custom option menu to arrange four menu items at the one line??

7. OOT:pejing bos yopie suryadi...