User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36 Steps to reproduce: Execute web browser and play RTSP Streaming link. 1. To play RTSP link, connect "rtsp://184.108.40.206:554/QE/Coverage20130826/R006_3GP_H.263(qCIF@541Kbps@15fps)_AAC-LC(96Kbps@22.05kHz@2ch).3gp" Actual results: (This case is separated from Bug 1043024.) If you try to reproduce, link will be not played. When I play it using android device, playback was worked well. And to check other codec type for RTSP Streaming, could you let me know RTSP supported type(codec/container)?
[Blocking Requested - why for this release]:
QA Wanted to see if we can reproduce this on Flame.
Issue is reproducible on Flame 2.0. When attempting to access the provided link via Browser, it displays an error message saying: Video can't be played because the file is corrupt. Tested on: Device: Flame BuildID: 20140805164926 Gaia: 5ba22d458fdb63bd72c59de53c701d0efe35c1e2 Gecko: 6fbc60a80c6d Version: 32.0 (2.0) Firmware V122 User Agent Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
qa-wanted for branch checks
Issue is reproducible on Buri 2.0, and Flame 2.1. Observed behavior: Same as comment 3. Device: Buri BuildID: 20140806084615 Gaia: 47fa0ba8197e71cc7034943ff037642e7f35cdfe Gecko: 4feed2803746 Version: 32.0 (2.0) Firmware: v1.2device.cfg User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Device: Flame BuildID: 20140806054320 Gaia: 5e6ef81cb9e917657ce050f598229dfc83c58b8f Gecko: bdf301b20cab Version: 34.0a1 (Master) Firmware: V123 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 ----------------- On Flame 1.4 this file type is NOT supported in browser. When the link is accessed, device pops a notification from status bar saying 'Download started' but no download progress is shown, and when Downloads section in Settings app is accessed, nothing is being listed there. Device: Flame BuildID: 20140806081546 Gaia: e9dce1f60f729e228810f751417681b5ff937b6b Gecko: d281a3bdfea6 Version: 30.0 (1.4) Firmware: V122 User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
not a regression
NI :ethan for input here.
(In reply to Jaemin Song from comment #0) > Steps to reproduce: > > Execute web browser and play RTSP Streaming link. > 1. To play RTSP link, connect > "rtsp://220.127.116.11:554/QE/Coverage20130826/R006_3GP_H. > 263(qCIF@541Kbps@15fps)_AAC-LC(96Kbps@22.05kHz@2ch).3gp" > If you try to reproduce, link will be not played. > When I play it using android device, playback was worked well. > > And to check other codec type for RTSP Streaming, could you let me know RTSP > supported type(codec/container)? 1. The codecs of this video are: Video: H263 Audio: MPEG ACC (mp4a) Theoretically they should be supported by our RTSP framework. But I cannot play this clip on my Flame v2.1 either. I will look into the cause. 2. The codes (payload formats) supported by B2G RTSP are listed here: https://wiki.mozilla.org/Networking/RTSP#Supported_RTP_Payload_Formats_.28Codecs.29
Triage: not a certification nor a release blocker.
Hi Benjamin, This clip cannot be played because OmxDecoder::TryLoad() returns false at this line: http://dxr.mozilla.org/mozilla-central/source/content/media/omx/OmxDecoder.cpp#378 The error code returned by mAudioSource->read() is -110. Could you help to see what's wrong?
(In reply to Ethan Tseng [:ethan] from comment #10) > Hi Benjamin, > > This clip cannot be played because OmxDecoder::TryLoad() returns false at > this line: > http://dxr.mozilla.org/mozilla-central/source/content/media/omx/OmxDecoder. > cpp#378 > > The error code returned by mAudioSource->read() is -110. > Could you help to see what's wrong? I'll check the return value later, it seems the audio codec we can't support. Regardless the return value, it is normal that we get an error number when trying to DecodeMetadata. Then the code flow go into "error handling". So we should focus on the "error handling" that causes b2g process crash.
We found a potential risk of crash while debugging on this bug. Bug 1054230 was filed to track the crash issue. Jaemin, Can you send me the clip by email? It might be helpful to analyze the original media file. :)
(In reply to Ethan Tseng [:ethan] from comment #12) > We found a potential risk of crash while debugging on this bug. > Bug 1054230 was filed to track the crash issue. > > Jaemin, > Can you send me the clip by email? It might be helpful to analyze the > original media file. :) I have sent video file. Please confirm your email. Thanks.
(In reply to Jaemin Song from comment #13) > I have sent video file. > Please confirm your email. I've got the video clip. Thanks a lot!
Created attachment 8482715 [details] [diff] [review] Fix error in AMPEG4AudioAssembler (for MP4A-LATM) Fix an error in AMPEG4AudioAssembler::submitAccessUnit().
Comment on attachment 8482715 [details] [diff] [review] Fix error in AMPEG4AudioAssembler (for MP4A-LATM) Hi Steve, Could you help to review this patch? AMPEG4AudioAssembler::submitAccessUnit() reads from a packet queue, and compose an access unit by multiple NAL units in the packet. The second while loop in this function forgets to increase the offset by the size of NAL unit. This logical error results in malformed access unit that will be parsed by the decoder. That's why OmxDecoder::TryLoad() failed. (Stated in https://bugzilla.mozilla.org/show_bug.cgi?id=1049241#c10) Meanwhile, two assertions in AMPEG4AudioAssembler::removeLATMFraming() are dangerous that have the potential to cause system crash (A) CHECK_LT(offset, buffer->size()); (B) CHECK_LE(offset + payloadLength, buffer->size()); While reaching the end of packet, offset could be equal to buffer->size(), and payloadLength is 0. In this case, assertion (B) does not fail, but when the for-loop iterates to the next run, assertion (A) fails (and causes system crash). I replace them by error handle.
This patch could also fix the other two bugs: Bug 1054230 - [RTSP] Potential crash happens if decode error when reading meta data Bug 1055949 - [MADIA][Multimedia] When RTSP Streaming playback, detected reboot symptom
Created attachment 8483222 [details] [diff] [review] Fix error in AMPEG4AudioAssembler (for MP4A-LATM) Refresh comment "r=sworkman".
The result of Try server: https://tbpl.mozilla.org/?tree=Try&rev=7068eea0f11d
Comment on attachment 8483222 [details] [diff] [review] Fix error in AMPEG4AudioAssembler (for MP4A-LATM) [Approval Request Comment] Bug caused by (feature/regressing bug #): N/A User impact if declined: Some video format (MP4A-LATM) cannot be played over RTSP Testing completed: On m-c Risk to taking this patch (and alternatives if risky): None String or UUID changes made by this patch: N/A
This patch fixes a serious error while parsing MP4 audio from RTSP streaming. The code change is few and would not impact any other components. We hope it can be uplifted to v1.4, v2.0 and v1.2. Thanks.
https://hg.mozilla.org/releases/mozilla-aurora/rev/342f0868bc7e https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/fab53d0ea5e4 https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/b00e345c05d9
Verify passed, this issue can't be repro on Woodduck 2.0;Flame2.0&2.1&2.2 Attached: Verify_Woodduck_RTSP.mp4 Reproducing rate: 0/5 Woodduck build: Gaia-Rev 3a98f1287fa7b604891220ba5d86982ae8f9971e Gecko-Rev 03d3ab62d5b07b915434f2d1d68495ad5915ecd2 Build-ID 20141120103003 Version 32.0 Flame2.0 build: Gaia-Rev 1ede2666f1e6c1b3fd3b282011caf0cbc59544b0 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/54f1b0ee07a6 Build-ID 20141120000206 Version 32.0 Flame 2.1 build: Gaia-Rev f8d3bf44029e0afc0124600a4bb34dba8fc1ad21 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/f70a67a7f846 Build-ID 20141120001207 Version 34.0 FLame2.2 build: Gaia-Rev 1abe09b4925547699dfdb2d358aed019137c3aa6 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/6ce1b906c690 Build-ID 20141120040205 Version 36.0a1