I have a test pipeline, using gst-launch:
gst-launch -t --gst-debug=ffmpeg:0,videorate:4 --gst-debug-no-color \
dvbsrc modulation="QAM 256" frequency=${FREQ} ! queue
max-size-buffers=0 max-size-time=0 ! \
mpegtsdemux name=ts program-number=${PROGRAM} ts.video_${HVID} ! \
queue max-size-buffers=0 max-size-time=0 ! ffdec_mpeg2video ! \
queue max-size-buffers=0 max-size-time=0 ! videorate ! \
queue max-size-buffers=0 max-size-time=0 ! ffvideoscale method=3 ! \
video/x-raw-rgb, height=608 ! queue max-size-buffers=0 max-size-time=0
! \
ximagesink force-aspect-ratio=true
When I run it, I see a lot of messages from video rate, which has only
been added
to the pipeline to try to find my video problem, that buffers are out of
order
(more on some frequencies/program numbers than on others), and, at first
glance,
there's a positive correlation between jerky video (with the debugs set
to 0) and
the channels that generate more messages with the debug set to 4. This
is true with
more sinks than ximagesink, with the audio portion of the stream
enabled, ...
I'm using all of the latest releases (but not pre-releases).
I wonder if anyone knows how the buffers could be out of order (MPEG-2
artefact?).
Would it make sense for me to reorder them, either with a new element or
an
additional feature of the queue element?
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial.
http://p.sf.net/sfu/www-adobe-com_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Locked
