Hi,
On Wed, Oct 20, 2010 at 1:49 AM, Doug Crawford <[hidden email]> wrote:
this, I assume, still happens only when the sink element you use is not synchronising output buffers (sync=false).
I don't see anything wrong with buffer sizes, durations and timestamps. That is, I see no timing issues in the buffers arriving to the sink.
well, as timing appears to be fine, identity shouldn't really have anything to complain about.
So I understand the decoder is buffering a fixed 1.5 MB of data, disregarding the bitrate and actual frame size.. let me say it appears to me more a bug than a feature. This may be a reasonable cause for the sink dropping buffer in case the decoder element is not propagating a right latency info. Just out of curiosity, wouldn't gst-dsp be compatible with your receiver side architecture? Another idea: as BaseSink has a max-lateness property, probably TIDmaiVideoSink has it as well, so you may try to set it to a reasonably high value to get a smooth (but 2 sec in late) video. A simple: gst-inspect TIDmaiVideoSink will tell you whether the property is supported or not. Regards
------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |