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)

ARM
Gonk (Firefox OS)
defect
Not set
normal

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)

Attached file logcat.txt
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?
Attached file kernelLogs.txt
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+
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
Ethan - Can you try to reproduce with the clip?
Flags: needinfo?(ettseng)
(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)
Assignee: nobody → ettseng
I'll help on this bug.
Assignee: ettseng → vchang
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   }
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)
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.
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
(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)
:jet, can you please help find an assignee here given its a core audio/video issue?
Flags: needinfo?(bugs)
(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.
(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
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?
Flags: needinfo?(bhargavg1)
(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)
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
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
Flags: needinfo?(vchang)
Flags: needinfo?(vchang) → needinfo?(bhargavg1)
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).
Whiteboard: [CR 710872] → [caf priority: p2][CR 710872]
Hi Bhargavg, any feedback for Comment 20? Thanks.
Flags: needinfo?(bhargavg1)
(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)
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?
(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
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.
ni for more information on Comment 26, thanks.
Flags: needinfo?(poojas)
Flags: needinfo?(bhargavg1)
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);
(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
Assignee: nobody → vchang
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.
Attached file 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.
Flags: needinfo?(poojas)
Flags: needinfo?(bhargavg1)
Latest gaia and gecko revisions:

gaia" revision="5bf3b8cdea15e62ce7bf77a15085a18e24e33c44" 
"gecko" revision="f2ab70e9ab18439dae25e6eb21f186708b2888de"
(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?
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)
(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
Flags: needinfo?(bugs)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: