[gst-devel] How "really" to separate thread in GStreamer

[Stefan Kost]

Am 25.08.2010 15:06, schrieb ivan zoli:
> Hello,
> 
> I'm writing a AV recorder on an ambedded system
> using GStreamer. Unfortunally the kernel used is old
> 2.6.22 and therefore the handlig of the SD/MMC subsystem
> is very poor. I can't upgrade to a new kernel becuse the
> porting is too expensive in time. But with it I can write
> to an SD @ 1.5MByte/s that is enought for me.
> But the system has some latency that causes
> loss of video. I'm recording using a pipe like:
> 
> video4lsrc ! myencoder ! queue name=video \
> alsasrc ! queue name=audio \
> qtmux name=mux ! queue ! filesink location=/mnt/sd/my.mov \
> buffer-mode=0 buffer-size=262144 blocksize=262144 sync=0 async=0 \
> video.src ! mux.video_0 \
> audio.src ! mux.audio_0

the queu is definitely creating a new thread for the filesink. Although if your
system is a single core cpu and spending too much time in kernel space a thread
won't help. Does it work better when you lower the bitrates (and thus write
less)? Also specifying blocksize, async and sync on filesink is not needed.

Stefan

> 
> Anything is working properly but I have a queue of 10
> raw video frame captured @ 30 fps. When the latency
> of the write-back of the dirty cache are over 3/10 of second
> my raw video queue drops frame. It seems that the
> latency on SD writing locks the machine and didn't let
> the pipeline flow. If I use /dev/null like filesink location I have no
> problem. If I use another process running togheter with my
> pipeline that wrotes on the SD I have no video drops too.
> So it seems that the queue I use don't really separate
> the thread and when the write of the filesink is locked
> (I don't really well understand why) all the pipeline is locked
> and the processing of the video frames can't go on.
> The queue in the pipeline are sized in order to keep
> 10 seconds of compressed video.
> 
> Is there a way to have the filesink thread really separated
> from the rest of the pipeline?
> 
> I also think to use appsink instead of filesink
> and another application to read the data from RAM and
> save on SD in order to truly separate the thread.
> 
> It seems to work
> 
> Thank you
> 
> Ivan
> 
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users 
> worldwide. Take advantage of special opportunities to increase revenue and 
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel