How "really" to separate thread in GStreamer

[ivan zoli-2]

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

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Stefan Sauer]

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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel