After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 324064 - [vorbisenc] First vorbis buffer is dropped in some situations
[vorbisenc] First vorbis buffer is dropped in some situations
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: 0.10.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-12-14 14:11 UTC by Michal Benes
Modified: 2006-02-17 19:30 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michal Benes 2005-12-14 14:11:03 UTC
Duration for a vorbis buffer is comuped as  
GST_BUFFER_DURATION (outbuf) =
      GST_BUFFER_TIMESTAMP (outbuf) - vorbisenc->prev_ts;
what results in 0 for the first buffer.

This is a problem since gst_segment_clip returs FALSE when clipping to the
segment [0,-1)
Note that there is a condition
  if (stop != -1 && stop <= segment->start)
    return FALSE;
in the gst_segment_clip method.

I do not know if this is vorbisenc problem or if the gst_segment_clip condition
should be changed to
  if (stop != -1 && start != stop && stop <= segment->start)
    return FALSE;
Comment 1 Michal Benes 2005-12-14 14:18:24 UTC
Sorry, I have checked this once again and gst_segment_clip is correct. It is
vorbis encoder that should be fixed. Probably
if (vorbisenc->prev_ts > 0)
  GST_BUFFER_DURATION (outbuf) =
    GST_BUFFER_TIMESTAMP (outbuf) - vorbisenc->prev_ts;
Comment 2 Tim-Philipp Müller 2006-01-10 11:05:31 UTC
Isn't there another problem as well? It looks to me like vorbisenc happily timestamps the first three buffers it sends out (and puts durations on them), even though those are header buffers. That's not right either, is it?

Maybe there should be a

  if (vorbisenc->header_sent) {
   .... set duration and timestamp and offset_end
  } else {
   offset_end = -1;
  }

in gst_vorbisenc_buffer_from_packet() as well?
Comment 3 Michal Benes 2006-01-10 12:33:43 UTC
Vorbisenc used to put the three header buffers only to its source pad caps. As I am examining the code now, there is a recent hack by msmith that push the header buffers to source pad too (I do not think this is a systematic approach), in every case the header buffers do not go through gst_vorbisenc_buffer_from_packet(). Michal
Comment 4 Tim-Philipp Müller 2006-01-10 12:53:45 UTC
My vorbisenc.c has this ...

953   /* create header buffers */
954   buf1 = gst_vorbisenc_buffer_from_packet (vorbisenc, &header);
955   buf2 = gst_vorbisenc_buffer_from_packet (vorbisenc, &header_comm);
956   buf3 = gst_vorbisenc_buffer_from_packet (vorbisenc, &header_code);

Comment 5 Michal Benes 2006-01-10 13:28:27 UTC
Sorry Tim, yes, You are right. This should be fixed. The condition in gst_vorbisenc_buffer_from_packet() is good. Another possibility is to create the three header buffers by another functtion which do not set timestamps and offsets.
Comment 6 Wim Taymans 2006-02-17 19:30:03 UTC
patch 1.100 to vorbisenc fixed this logic, this was shipped in 0.10.3