GNOME Bugzilla – Bug 752760
qtdemux: Fix wrong setting of max_buffer_size for LPCM files.
Last modified: 2018-11-03 15:02:27 UTC
Created attachment 307964 [details] This is part of split file with md5sum e476e8c5f12498d1dff4735732900aa5 Overview: The max_buffer_size of LPCM files was set wrongly because qtdemux hardcoded the sampling rate as 4096. Steps to Reproduce: 1) Play the attached MOV file. 2) Then, do Rewind. Actual Results: On Rewind, "Invalid file and cannot be played" error message is triggered. Expected Results: 1) Rewind should not result in error. 2) Frames should move in appropriate play speed. Build Date & Hardware: Build 2014-12-18 on Ubuntu 12.04
Created attachment 307965 [details] This is a part of split file with md5sum e476e8c5f12498d1dff4735732900aa5
Created attachment 307966 [details] This is a part of split file with md5sum e476e8c5f12498d1dff4735732900aa5
Created attachment 307969 [details] [review] This is the diff patch
Created attachment 308280 [details] [review] This is the diff patch
Thanks. Is this the right sample file to reproduce the bug with?
Obviously :)No doubt
Apparently the author of this 4096 hardcode new this was not working well: commit 5bd2864101d837642fe37244aab58ab29dbca37a Author: David Schleef <ds@schleef.org> Date: Tue Mar 5 17:00:17 2013 -0800 qtdemux: split large raw audio samples In order to deal with a file that has samples that are 24 seconds long. Seeking still doesn't work with such files. Though your patch is a little strange, it feels like it hides another bug. bytes_per_frame sound like the frame size which iirc is defined as: framesize = num_channels * rate * sample_size If your framesize is correct, splitting your audio buffers in any multiple of that value should be fine (so 4096 * framesize, should be a valid value, it's complitly arbitrary, but valid). But digging up the code I found this (line 9610): stream->bytes_per_frame = stream->n_channels * stream->bytes_per_sample; Isn't this where the bug is in fact ? (also, don't put indent changes along with patches).
To assembled the stream, and made it available here: https://people.collabora.com/~nicolas/test-lpcm.mov To reproduce, start with gst-play-1.0 and then press 'd'
My memory is bugging me, obviously a frame size is: num_channels * sample_size So basically, instead of picking a random number of samples, you decide to make it at most 1 second ?
Even though it removes the error, that cause huge audio noise here, so something isn't right yet.
The problem is likely elsewhere, as forward playback on tha sample file gets the same 16000 size and yet audio plays fine.
Created attachment 332562 [details] [review] fix reverse playback of large samples (eg, LPCM) That sounds plausibly like backwards playback, and doesn't have any noise. There is a bit of pause at the end/start, so there might be another bug in the area with the timing.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/205.