appsrc vs filesrc problem

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

appsrc vs filesrc problem

Richard123
Hi,

Using an identity element, I have compared buffer data file dumps of both appsrc and filesrc elements.
(filesrc, - appears to have repeated several pre-roll GstBuffers).

Can anyone explain why appsrc (only works if I use very large buffer sizes), or perhaps provide suggestions on why filesrc repeats buffers?

Many thanks,
Richard

Reply | Threaded
Open this post in threaded view
|

Re: appsrc vs filesrc problem

Thiago Sousa Santos-2


On Tue, Jul 6, 2010 at 12:01 PM, Richard123 <[hidden email]> wrote:

Hi,

Using an identity element, I have compared buffer data file dumps of both
appsrc and filesrc elements.
(filesrc, - appears to have repeated several pre-roll GstBuffers).

Can anyone explain why appsrc (only works if I use very large buffer sizes),
or perhaps provide suggestions on why filesrc repeats buffers?

It's hard to know unless you give us more context, you could start by telling us what pipelines are you using or any other information you might find relevant.
 

Many thanks,
Richard


--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/appsrc-vs-filesrc-problem-tp2279694p2279694.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel



--
Thiago Sousa Santos

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: appsrc vs filesrc problem

Richard123

<quote author="thiagossantos@gmail.com">
On Tue, Jul 6, 2010 at 12:01 PM, Richard123 <buteo.rg@googlemail.com> wrote:

>
> Hi,
>
> Using an identity element, I have compared buffer data file dumps of both
> appsrc and filesrc elements.
> (filesrc, - appears to have repeated several pre-roll GstBuffers).
>
> Can anyone explain why appsrc (only works if I use very large buffer
> sizes),
> or perhaps provide suggestions on why filesrc repeats buffers?
>

It's hard to know unless you give us more context, you could start by
telling us what pipelines are you using or any other information you might
find relevant.


>
> Many thanks,
> Richard
>
Hi,

Thanks for your reply.

I am trying to write an application which decodes live TS data using a capture card, (appsrc to push buffers into my pipeline). I noticed a correlation between buffer size and decode errors; (using default 4096 bytes produces huge amounts of errors)

In an effort to understand the difference between filesrc and appsrc, I have written two small similar programs, to compare buffer dumps. The pipeline I am using is as follows:

Prog 1) filesink ! identity ! decodebin2 ! xvimagesink (produces no decode errors)
Prog 2) appsrc ! identity ! decodebin2 ! xvimagesink (produces decode errors depending on buffer size)

I then connect to the handoff signal to dump GstBuffers, (out of identity element) to a file.

Comparing buffer dumps, I noticed the following:
1) During the pre-roll phase, filesrc sends the same buffers more than once; (approx sixty buffers)
2) Again during pre-roll, filesrc buffer sizes changed; ie. buff1=4096 bytes, buff2=32bytes, buff3=128bytes, buff4=4096 bytes.
3) After the pre-roll phase both files are identical

So my question is; how can I pre-roll the pipeline in a manner consistent with filesrc?

Kind regards,

Richard