Closed
Bug 1055936
Opened 10 years ago
Closed 10 years ago
Fail to play few 1080p RTSP clips on compatible platform
Categories
(Core :: Audio/Video, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1056187
blocking-b2g | 2.0+ |
People
(Reporter: bhargavg1, Assigned: vchang)
References
Details
(Whiteboard: [caf priority: p2][CR 710872])
Attachments
(3 files)
Fail to play specific RTSP clip while the same passes through LA and VLC player
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.0?
Comment 3•10 years ago
|
||
Can you email myself (jsmith@mozilla.com) & Bhavana (bbajaj@mozilla.com) with the test clip here so we can investigate this bug?
blocking-b2g: 2.0? → 2.0+
Updated•10 years ago
|
Flags: needinfo?(bhargavg1)
(In reply to Jason Smith [:jsmith] from comment #3) > Can you email myself (jsmith@mozilla.com) & Bhavana (bbajaj@mozilla.com) > with the test clip here so we can investigate this bug? Yes waiting for the clips to load
Flags: needinfo?(bhargavg1)
(In reply to bhargavg1 from comment #4) > (In reply to Jason Smith [:jsmith] from comment #3) > > Can you email myself (jsmith@mozilla.com) & Bhavana (bbajaj@mozilla.com) > > with the test clip here so we can investigate this bug? > > Yes waiting for the clips to load Sent the link, let me know if you haven't received or having issues in accessing
Comment 7•10 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #6) > Ethan - Can you try to reproduce with the clip? Sure. I already got those clips from email. I will debug with them ASAP.
Flags: needinfo?(ettseng)
Updated•10 years ago
|
Assignee: nobody → ettseng
Comment 9•10 years ago
|
||
All these 3 clips failed at this line in OmxDecoder::TryLoad(). http://dxr.mozilla.org/mozilla-central/source/content/media/omx/OmxDecoder.cpp#367 364 // read video metadata 365 if (mVideoSource.get() && !SetVideoFormat()) { 366 NS_WARNING("Couldn't set OMX video format"); 367 return false; 368 }
Assignee | ||
Comment 10•10 years ago
|
||
I saw the log below when trying to load the video clip, I/OMXCodec( 1691): [OMX.qcom.video.decoder.avc] video dimensions are 1920 x 1080 I/OMXCodec( 1691): [OMX.qcom.video.decoder.avc] Crop rect is 1920 x 1080 @ (0, 0) I/Gecko ( 1691): Failed to get video size, or it was too large for HW decoder (<w=1920, h=1080> but <maxW=1280, maxH=720>) According to comment 2 in bug 1020980, hardware decoder seems not support 1080p video. Not sure if this is hardware limitation. Michael, can I have your comments?
Flags: needinfo?(mvines)
Assignee | ||
Comment 11•10 years ago
|
||
We have a dimension check here. http://dxr.mozilla.org/mozilla-central/source/content/media/omx/OMXCodecProxy.cpp#177 It read width and height properties to decide capability of hardware decoder. ro.moz.omx.hw.max_width=1280 ro.moz.omx.hw.max_height=720 I would say that this should be hardware limitation or we don't set the properties properly when porting the flame device.
Assignee | ||
Comment 12•10 years ago
|
||
It's not the RTSP bug. Changing the component to audio/video, feel free to change to others component if I am wrong.
Assignee: vchang → nobody
Component: RTSP → Video/Audio
Product: Firefox OS → Core
Comment 13•10 years ago
|
||
(In reply to Vincent Chang[:vchang] from comment #11) > We have a dimension check here. > http://dxr.mozilla.org/mozilla-central/source/content/media/omx/ > OMXCodecProxy.cpp#177 > It read width and height properties to decide capability of hardware > decoder. > ro.moz.omx.hw.max_width=1280 > ro.moz.omx.hw.max_height=720 > > I would say that this should be hardware limitation or we don't set the > properties properly when porting the flame device. This looks fair, the Flame only supports up to 720p HW video decode.
Flags: needinfo?(mvines)
Comment 14•10 years ago
|
||
:jet, can you please help find an assignee here given its a core audio/video issue?
Flags: needinfo?(bugs)
Comment 15•10 years ago
|
||
(In reply to bhavana bajaj [:bajaj] from comment #14) > :jet, can you please help find an assignee here given its a core audio/video > issue? Or after going through the comments again and chatting to jesup here is what we have :per above comments we are trying to play a 1920x1080 video on hardware that only supports 1280x720 max so not sure if there is anything to be done here.
Reporter | ||
Comment 16•10 years ago
|
||
(In reply to bhavana bajaj [:bajaj] from comment #15) > (In reply to bhavana bajaj [:bajaj] from comment #14) > > :jet, can you please help find an assignee here given its a core audio/video > > issue? > > Or after going through the comments again and chatting to jesup here is what > we have :per above comments we are trying to play a 1920x1080 video on > hardware that only supports 1280x720 max so not sure if there is anything to > be done here. This issue was reported on 8x26 device where we don't have these limitations. Let me know if you need any specific logs
Summary: Fail to play RTSP clip → Fail to play few 1080p RTSP clips on compatible platform
Assignee | ||
Comment 17•10 years ago
|
||
Hi bhargavg1, I just get one QRD8X26 device today. My test result for these three clips are 1. H264_1080P_HP_4Mbps_30fps_AAC.mp4 => successful, video/audio are smooth. 2. H264_1080P_HP_8Mbps_24fps_AAC.mp4 => successful, video/audio are smooth. 3. MPEG4_FPS_1080P_AAC_ASP_30fps_AAC_192kbps.mp4 => can hear the audio but video is not smooth. I am trying the video clip in Nexus 5 and Note3(Both running the Android). But the video is not smooth, too. Do we have the same behavior in LA as well?
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(bhargavg1)
Reporter | ||
Comment 18•10 years ago
|
||
(In reply to Vincent Chang[:vchang] from comment #17) > Hi bhargavg1, I just get one QRD8X26 device today. My test result for these > three clips are > 1. H264_1080P_HP_4Mbps_30fps_AAC.mp4 => successful, video/audio are smooth. > 2. H264_1080P_HP_8Mbps_24fps_AAC.mp4 => successful, video/audio are smooth. > 3. MPEG4_FPS_1080P_AAC_ASP_30fps_AAC_192kbps.mp4 => can hear the audio but > video is not smooth. > > I am trying the video clip in Nexus 5 and Note3(Both running the Android). > But the video is not smooth, too. Do we have the same behavior in LA as well? Our test team confirmed the issue isnt seen on LA & VLC player. Can you confirm the SHA1s that you tested for the gecko/gaia? I believe they are from v2.0 branch only
Flags: needinfo?(bhargavg1)
Assignee | ||
Comment 19•10 years ago
|
||
Here is the version I used to test these clips. They should be v2.0 branch. Gaia 4c8b5ced1966079086d86dec3098ecf340881306 Gecko aef285e913ddb4a91ee36250bb737bc6b9c1c47f BuildID 20140826133711 Version 32.0
Assignee | ||
Comment 20•10 years ago
|
||
Hi bhargavg1, I use the caf_AU_LINUX_GECKO_B2G_KK_3.5.01.04.00.113.185.xml repo file with gecko/gaia v2.0 branch. I can play 1080p video clips with the QRD8X26 device. But I found the content process(browser tab) is crashed in OMXCodec.cpp if I replay the MPEG4_FPS_1080P_AAC_ASP_30fps_AAC_192kbps.mp4 video file when the video is ended. Still trying to figure out why..... Do you find similar test results? #0 tgkill () at bionic/libc/arch-arm/bionic/tgkill.S:46 #1 0xb6e5813c in pthread_kill (t=<optimized out>, sig=6) at bionic/libc/bionic/pthread_kill.cpp:49 #2 0xb6e58350 in raise (sig=6) at bionic/libc/bionic/raise.cpp:32 #3 0xb6e57086 in __libc_android_abort () at bionic/libc/bionic/abort.cpp:55 #4 0xb6e669b8 in abort () at bionic/libc/arch-arm/bionic/abort_arm.S:41 #5 0xb4e1991e in __android_log_assert ( cond=0xb4f2b932 "!(lastBufferTimeUs >= 0)", tag=0xb4f27cc0 "OMXCodec", fmt=0xb4f148df "%s") at system/core/liblog/logd_write.c:261 #6 0xb4ec8066 in android::OMXCodec::drainInputBuffer ( this=this@entry=0xb45a3d00, info=<optimized out>) at frameworks/av/media/libstagefright/OMXCodec.cpp:3269 #7 0xb4ec9b7e in drainInputBuffers (this=0xb45a3d00) at frameworks/av/media/libstagefright/OMXCodec.cpp:3181 #8 android::OMXCodec::drainInputBuffers (this=0xb45a3d00) at frameworks/av/media/libstagefright/OMXCodec.cpp:3161 #9 0xb4ecb4a4 in android::OMXCodec::onCmdComplete (this=this@entry=0xb45a3d00, cmd=<optimized out>, data=data@entry=1) at frameworks/av/media/libstagefright/OMXCodec.cpp:2839
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(vchang)
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(vchang) → needinfo?(bhargavg1)
Assignee | ||
Comment 21•10 years ago
|
||
BTW, I switch gaia/gecko from v1.4 to v2.0 branch manually after repo sync(caf_AU_LINUX_GECKO_B2G_KK_3.5.01.04.00.113.185.xml).
Updated•10 years ago
|
Whiteboard: [CR 710872] → [caf priority: p2][CR 710872]
Comment 22•10 years ago
|
||
Hi Bhargavg, any feedback for Comment 20? Thanks.
Flags: needinfo?(bhargavg1)
Reporter | ||
Comment 23•10 years ago
|
||
(In reply to howie [:howie] from comment #22) > Hi Bhargavg, any feedback for Comment 20? Thanks. Howie, our test teams are unable to play the clips and see a n/w error, so really cant comment on if they see any issues Can you let me know if you need any specific logs to proceed on this further
Flags: needinfo?(bhargavg1)
Assignee | ||
Comment 24•10 years ago
|
||
Are you in the v1.4 branch? We don't support RTSP video in v1.4. It shows up n/w error if you play RTSP video in v1.4 branch. Can you confirm this first?
Reporter | ||
Comment 25•10 years ago
|
||
(In reply to Vincent Chang[:vchang] from comment #24) > Are you in the v1.4 branch? We don't support RTSP video in v1.4. It shows up > n/w error if you play RTSP video in v1.4 branch. Can you confirm this first? We are using v2.0 + KK combo build
Assignee | ||
Comment 26•10 years ago
|
||
Hi Pooja, can I have the following information 1. Repositories you used for gecko/gaia? 2. tcpdump for RTSP/RTSP packets. 3. test link for 1080p clips(We use darwin server with 1080p clips in our local test environment). 4. help to confirm if media.rtsp.video.enabled is true/false. I will try to find out if we can dump this value in runtime or I will provide a test patch to dump this value.
Comment 27•10 years ago
|
||
ni for more information on Comment 26, thanks.
Flags: needinfo?(poojas)
Flags: needinfo?(bhargavg1)
Assignee | ||
Comment 28•10 years ago
|
||
One way to dump preference is "adb pull /system/b2g/omni.ja" "unzip omni.ja" "vi ./defaults/pref/b2g.js" And check the value for "media.rtsp.video.enabled". It should be true. pref("media.rtsp.enabled",true); pref("media.rtsp.video.enabled", true);
Comment 29•10 years ago
|
||
(In reply to Vincent Chang[:vchang] from comment #26) I apologies for the delay. > 1. Repositories you used for gecko/gaia? gaia" revision="de28796a8956a48bb98ca67df6a33e0622d642d1" "gecko" revision="2b27becae85092d46bfadcd4fb5605e82e1e1093" > 2. tcpdump for RTSP/RTSP packets. Need some more time. Will provide you shortly > 3. test link for 1080p clips(We use darwin server with 1080p clips in our will update you shortly > local test environment). > 4. help to confirm if media.rtsp.video.enabled is true/false. I will try to Both the prefs were true
Updated•10 years ago
|
Assignee: nobody → vchang
Assignee | ||
Comment 30•10 years ago
|
||
Just for your information, I used the same gecko/gaia repo below. But I don't find network error message when playing rtsp clips. Gaia de28796a8956a48bb98ca67df6a33e0622d642d1 Gecko 2b27becae85092d46bfadcd4fb5605e82e1e1093 BuildID 20140903121637 Version 32.0 I need the tcpdump to do further investigation.
Comment 31•10 years ago
|
||
Hi Chang, Our test team again tried the same clip on latest build. On latest build they dont see network issue but during playback video stops and audio continues .we also observe huge frame drop logs and tcpdumps attached. Sent test clips over email. Please let me know if you received the same.
Flags: needinfo?(poojas)
Flags: needinfo?(bhargavg1)
Comment 32•10 years ago
|
||
Latest gaia and gecko revisions: gaia" revision="5bf3b8cdea15e62ce7bf77a15085a18e24e33c44" "gecko" revision="f2ab70e9ab18439dae25e6eb21f186708b2888de"
Reporter | ||
Comment 33•10 years ago
|
||
(In reply to Pooja from comment #31) > Created attachment 8483405 [details] > tcp dumps and logs > > Hi Chang, > > Our test team again tried the same clip on latest build. > On latest build they dont see network issue but during playback video stops > and audio continues .we also observe huge frame drop > logs and tcpdumps attached. > > Sent test clips over email. Please let me know if you received the same. Vincent, can you let Pooja know if you want to enable any extra logging. Would logs from https://bugzilla.mozilla.org/show_bug.cgi?id=1058022#c16 be sufficient?
Assignee | ||
Comment 34•10 years ago
|
||
Hi there, according to comment 31, I think we should focus on Bug 1056187 to smooth video playback on high resolution video and mark this as duplicated bug. Or maybe we can track crash problem I am encountering here and rename the bug title. How do you guys think?
Flags: needinfo?(bhargavg1)
Reporter | ||
Comment 35•10 years ago
|
||
(In reply to Vincent Chang[:vchang] from comment #34) > Hi there, according to comment 31, I think we should focus on Bug 1056187 to > smooth video playback on high resolution video and mark this as duplicated > bug. Or maybe we can track crash problem I am encountering here and rename > the bug title. How do you guys think? Ok, lets followup on Bug 1056187. Closing this one as Dup
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(bhargavg1)
Resolution: --- → DUPLICATE
Updated•10 years ago
|
Flags: needinfo?(bugs)
You need to log in
before you can comment on or make changes to this bug.
Description
•