Fail to play few 1080p RTSP clips on compatible platform

RESOLVED DUPLICATE of bug 1056187

Status

()

Core
Audio/Video
RESOLVED DUPLICATE of bug 1056187
3 years ago
3 years ago

People

(Reporter: bhargavg1, Assigned: vchang)

Tracking

unspecified
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(blocking-b2g:2.0+)

Details

(Whiteboard: [caf priority: p2][CR 710872])

Attachments

(3 attachments)

(Reporter)

Description

3 years ago
Created attachment 8475698 [details]
logcat.txt

Fail to play specific RTSP clip while the same passes through LA and VLC player
(Reporter)

Comment 1

3 years ago
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.0?
(Reporter)

Comment 2

3 years ago
Created attachment 8475699 [details]
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+

Updated

3 years ago
Flags: needinfo?(bhargavg1)
(Reporter)

Comment 4

3 years ago
(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)
(Reporter)

Comment 5

3 years ago
(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
(Assignee)

Comment 8

3 years ago
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   }
(Assignee)

Comment 10

3 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

3 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

3 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
(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.
(Reporter)

Comment 16

3 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
(Reporter)

Updated

3 years ago
Summary: Fail to play RTSP clip → Fail to play few 1080p RTSP clips on compatible platform
(Assignee)

Comment 17

3 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

3 years ago
Flags: needinfo?(bhargavg1)
(Reporter)

Comment 18

3 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

3 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

3 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

3 years ago
Flags: needinfo?(vchang)
(Assignee)

Updated

3 years ago
Flags: needinfo?(vchang) → needinfo?(bhargavg1)
(Assignee)

Comment 21

3 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

3 years ago
Whiteboard: [CR 710872] → [caf priority: p2][CR 710872]

Comment 22

3 years ago
Hi Bhargavg, any feedback for Comment 20? Thanks.
Flags: needinfo?(bhargavg1)
(Reporter)

Comment 23

3 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

3 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

3 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

3 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

3 years ago
ni for more information on Comment 26, thanks.
Flags: needinfo?(poojas)
Flags: needinfo?(bhargavg1)
(Assignee)

Comment 28

3 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

3 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

3 years ago
Assignee: nobody → vchang
(Assignee)

Comment 30

3 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

3 years ago
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.
Flags: needinfo?(poojas)
Flags: needinfo?(bhargavg1)

Comment 32

3 years ago
Latest gaia and gecko revisions:

gaia" revision="5bf3b8cdea15e62ce7bf77a15085a18e24e33c44" 
"gecko" revision="f2ab70e9ab18439dae25e6eb21f186708b2888de"
(Reporter)

Comment 33

3 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

3 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

3 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
Last Resolved: 3 years ago
Flags: needinfo?(bhargavg1)
Resolution: --- → DUPLICATE
Duplicate of bug: 1056187

Updated

3 years ago
Flags: needinfo?(bugs)
You need to log in before you can comment on or make changes to this bug.