Video playback: frames memory consumption tuning

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Huques,
 
I think there may be some methods.
1. not set queue size by frame number, but time of buffers.
2. change queue implementation to adapt to different codec ( not the best :) )
3. use GstController to control property dynamically.
 
Maybe someone else has better methods.
 
 
________________________________

From: gstreamer-embedded-bounces at lists.sourceforge.net [mailto:gstreamer-embedded-bounces at lists.sourceforge.net] On Behalf Of Hugues Fruchet
Sent: Thursday, March 13, 2008 8:42 PM
To: gstreamer-embedded at lists.sourceforge.net
Subject: Video playback: frames memory consumption tuning


Using playbin to make a video playback will typically use this pipeline:
<decoder> ! queue ! <sink>
This make the decoding threading independent of the rendering threading, which is needed to let the rendering side synchronize on clock to display the frame of time N when the real time reach N, assuming that an amount of frames have been decoded by advance & have been put in the queue.
Gstreamer assumes that if queue is full, the source is blocked till sink has consumed some frames, so when the queue is full, decoder thread is stopped till rendering side as consumed a frame.
The problem is that by default, queue has 200 frames, so if the decoder is fast enough to decode faster than framerate, the queue will goes up to 200 frames !(in fact not because another 2s value limit the queue size).
By evidence, on embedded device, such a consumption is not acceptable, so we must tune the size of the queue.
The problem is that this tuning is at least codec-dependent (stream-dependent also):
1) MPEG4/H263
Decoding time is quite always the same for a given stream, so it is assumed that for a given fixed rendering framerate, decoder will never or rarely decode slower than framerate => small bufferization needed (2-3 frames).
 
2) H264
Decoding time has a big dispersion, some decoding "peaks" maybe there which makes a single decoding takes some framerate periods! => queue size must be larger (10-20 frames) to ensure bufferization. 
This also depends on:
- video dimensions, complexity of video, because this will decrease the decoding duration,
- framerate, because if frame rate is low regarding decoding duration, no pbm
- DPB of SPS header ? size of bufferization needed inside decoder to output 1 frame. Not sure if this must be care of.
=> so stream dependent
 
So we must be able to tune queue max-size-buffers=x, x depending on codec type (@ first approach) or stream infos (@second hand).
 
So the question are:
- Is anybody knows if someting is there in playbin allowing this ?
- If playbin modifications must be made, which type of gst mechanism can we use to get what is the video codec type & infos on video in order to tune the queue size ?
 
 

________________________________

Envoy? avec Yahoo! Mail <http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52423/*http://fr.docs.yahoo.com/mail/overview/index.html> .
Une boite mail plus intelligente. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-embedded/attachments/20080314/f36e8c93/attachment.htm>


[Index of Archives]     [Linux Embedded]     [Linux ARM Kernel]     [Linux for ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux Media]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux