GNOME Bugzilla – Bug 639715
amrparse: seek error with EOS
Last modified: 2011-02-07 19:06:49 UTC
I am writing a gstreamer player.But I got prolem here. I use the player to play a 1hs amr wb file , always when I seek to a forward place, the player will block more than 10s and then return, which is not expected. When it abnormally returned, I got the EOS message,but it seemed incorret. The player is with plugins bad_17 amrparse,ugly_16 amrwbdec. This problem is emergency. Is there any resolution ? How can I resolve this problem? Thanks
Could you make the file available somewhere for download? Have you tried with the amrbase from git or the latest pre-release (0.10.20.3) or release (0.10.20)? 0.10.17 is quite old (if that's what you're using).
> Have you tried with the amrbase from... I meant amrparse of course
Thanks very much! I will try it.
(In reply to comment #1) > Could you make the file available somewhere for download? > Have you tried with the amrbase from git or the latest pre-release (0.10.20.3) > or release (0.10.20)? 0.10.17 is quite old (if that's what you're using). I have tried the file using a download player on xp ,also an android player and the Nokia e63 phone player,they all worked well. But I tried the original player on Ubuntu 10.10 64 bit,it has the problem too, and I found the version is 0.10.20. Do you mean it is a bug for the old version and has been solved in latest version? Thanks.
Hi: I've tried your issue with a 2hs amr file and amrparse version is 0.10.20.2. It works well on it. My environment is: Ubuntu 10.10 gstreamer: gst-launch-0.10 version 0.10.31 GStreamer 0.10.31 (prerelease) amrparse: Version: 0.10.20.2 License: LGPL Source module: gst-plugins-bad Source release date: 2011-01-11 05:11 (UTC) Binary package: GStreamer Bad Plug-ins prerelease Thanks.
Hi, Here my test is that playing the file then seek to some places it maybe OK,then continue to seek to a forward place it will block and stop. So you seek to forward or backward places continuely till the end, it all workes well? Did you write the player application or it's the OS's?
I compile the gstreamer-0.10.31.3 and gst-plugins-bad-0.10.20.3 with arm-linux-gcc but it still block at some time while seeking. Is it because the compile configuration not correct? or the test AP's linking option not right? (I link to an old version gstreamer because I can't link to the new one without error.) I'm not sure.
Hi, I tried the latest version,but still fails.I am confused. What is different? What's your test file format ,wb or nb? So you seek to forward places continuously till the end, it all workes well? Thanks Did you write the player application or it's the OS's? (In reply to comment #5) > Hi: > I've tried your issue with a 2hs amr file and amrparse version is 0.10.20.2. > It works well on it. > My environment is: > Ubuntu 10.10 > gstreamer: > gst-launch-0.10 version 0.10.31 > GStreamer 0.10.31 (prerelease) > amrparse: > Version: 0.10.20.2 > License: LGPL > Source module: gst-plugins-bad > Source release date: 2011-01-11 05:11 (UTC) > Binary package: GStreamer Bad Plug-ins prerelease > Thanks.
Created attachment 178689 [details] A testcase for amr file seek testing
Hi: Sorry for late reply :-D I test is by a gstreamer application with a nb file. I have no amrwb encoder on my environment so I don't test wb file yet. Here is my test case in the attachment and can you send your wb encoded wmr file to me for a test? Thanks.
Created attachment 178691 [details] a wb amr file about half an hour
Created attachment 178692 [details] a wb amr file about half an hour,part 2
Created attachment 178693 [details] a wb amr file about half an hour,part3
Created attachment 178694 [details] a wb amr file about half an hour,part4
Created attachment 178695 [details] a wb amr file about half an hour,part5
Created attachment 178696 [details] a wb amr file about half an hour,part6
Created attachment 178697 [details] a wb amr file about half an hour,part7
Because the large file is forbit to submit,so I make it to pieces. You should download all of them.
I test your wb amr file with the test case I sent yesterday,and it works well for me. Maybe you can test it with my test case on your board.(Change amrnbdec to amrwbdec please :-)) BTW,seems that we have the same gstreamer version but only the different platform. Are you running this case on Android? Can you give me more details about your environment ? I have a devkit8000 and maybe I can dig this issue on the same platform as you.
Thanks so much. Here we got the issue (In reply to comment #19) > I test your wb amr file with the test case I sent yesterday,and it works well > for me. > Maybe you can test it with my test case on your board.(Change amrnbdec to > amrwbdec please :-)) > BTW,seems that we have the same gstreamer version but only the different > platform. > Are you running this case on Android? > Can you give me more details about your environment ? > I have a devkit8000 and maybe I can dig this issue on the same platform as you. Thanks so much :). Here we got the issue fixed now. It's the amrwbdec plugin,the adpter buffer was incorrect.
> Here we got the issue fixed now. > It's the amrwbdec plugin, the adapter buffer was incorrect. So what was the fix exactly? Do you have a patch?
Hi We didn't have a patch. But it's just adding one line in the amrwbdec.c of gst-plugins-ugly-0.10.16. 288: if (!block || gst_adapter_available (amrwbdec->adapter) < block) + { + gst_adapter_clear (amrwbdec->adapter); break; + } Because when there are incorrect data, if you don't clear it, the next checking is still incorrect.
So, all in all, a bit of this: commit c85e8e8015b7239df7819fc2eaa0a21158f1e250 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Mon Sep 6 14:10:11 2010 +0200 amrparse: a valid amr-wb frame should not have reserved frame type index See #639715. but mainly this: commit dbdf9761055001f07957353dc0b468fb7e192d40 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Mon Feb 7 19:58:45 2011 +0100 amrwbdec: avoid stalling on invalid frame Skip 1 byte indicating invalid frame type index rather than stalling on it indefinitely until EOS. Fixes #639715.