[Bug 666545] New: [playbin2] Number of samples read from MP3/AAC files is less than expected

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=666545
  GStreamer | gst-plugins | 0.10.30

           Summary: [playbin2] Number of samples read from MP3/AAC files
                    is less than expected
    Classification: Platform
           Product: GStreamer
           Version: 0.10.30
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: dsi.maillist at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=203896)
 --> (https://bugzilla.gnome.org/attachment.cgi?id=203896)
Relevant files to reproduce/highlight this issue

When attempting to read MP3 or AAC files using playbin2, the amount of data
returned is one buffer short. For AAC files, the buffer of data that is not
read is at the start of the audio (first audio buffer). For MP3 files, the
buffer of data that is not read is at the end of the audio (last audio buffer).
The "audio-sink" property of playbin2 is attached to an appsink from which the
data is retrieved. No such issues are observed when reading a WAV file. 

The default buffer size supplied by playbin2 has been used. During testing the
buffer sizes were 1152 samples for MP3 and 1024 samples for AAC. 

Attached are audio files using which I have tested:
sine_noisy_both_ends.m4a: 1 second of sine wave of 800 Hz frequency which
contains 1024 samples of random noise at the start and 1024 samples of random
noise at the end. The noise can be heard when using Windows Media Player. This
file was created on Windows 7 using Media Foundation.
sine_noisy_both_ends.mp3: Output of converting sine_noisy_both_ends.m4a using a
utility called AAC to MP3 converter. This conversion was also done on Windows
7.

Execute the following gst-launch command:
gst-launch-0.10 -v playbin2 uri=file:///tmp/sine_noisy_both_ends.m4a
video-sink=fakesink text-sink=fakesink

You will NOT hear the noise at the beginning but you will hear the noise at the
end.

When testing with the mp3 file, this issue cannot be clearly observed using
gst-launch because the MP3 file generated by the converter contains a lot of
zero padding both at the start and end of the signal. I am attaching the plot
mf_gst_for_mp3.tif" to illustrate this. The data read in from linux (in red)
has been padded with 1152 zero samples at the end to make it have the same
length as the data read in using media foundation. The signals overlap exatly
for the last 1152 samples. 

The workflow being used is:
1. Create playbin2 and appsink elements and assign the appsink to the
"audio-sink" property of playbin2.
2. Move the state of the pipeline(playbin2) to PAUSED. I do this so that I can
query the negotiated caps for properties such as numchannels, bit depth, which
I report to the user.
3. Seek to the desired location in the stream using gst_element_seek_simple. I
use the flags GST_SEEK_FLAG_FLUSH and GST_SEEK_FLAG_ACCURATE.
4. Move the state of the pipeline(appsink) to PLAYING. Use the GstAppSink API
functions to retrieve pull the buffers.

No such issues are observed when attempting to read WAV files.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.