[gstreamer-bugs] [Bug 541130] [avimux] full and fast recording

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=541130

  GStreamer | gst-plugins-good | Ver: HEAD CVS




------- Comment #6 from Mark Nauwelaerts  2008-07-12 21:20 UTC -------
So, if I understand things right, the result of the first pipeline (recording)
is an avi that is (plays) just fine.  It is then transcoded (off-line) to
another avi (2nd pipeline), where this pipeline runs OK, but the resulting file
is not so nice, as in jerky playback, etc.

That seems very strange; the latter pipeline is a basic transcoding one, and it
should end up with fine output (sync etc) given good input.

In any case, I can not reproduce a problem; I have performed a recording using
similar first pipeline, and transcoded with exactly the same second one, the
result is an avi with raw YUY2 that is just fine (several times).

Unfortunately, there are no properties on filesrc or queue I can imagine that
can affect an off-line transcoding run.  I would only recommend not to put a
queue after filesrc as that will force avidemux in push-mode (which is not so
traditional, though it should work, and it does in this case).  I also tend to
limit queue only in the max-size-time sense, since that is meaningful across
many formats, buffer sizes, audio vs video, etc, but no hard rule here either.

So, I can only suspect something wrong with the first (live) recording ...


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=541130.