Closed
Bug 1032065
Opened 10 years ago
Closed 10 years ago
RTSP video playback quality is very poor if payload type is "MP4V-ES"
Categories
(Firefox OS Graveyard :: RTSP, defect, P1)
Tracking
(blocking-b2g:2.0+, firefox31 wontfix, firefox32 fixed, firefox33 fixed, b2g-v2.0 fixed, b2g-v2.1 fixed)
People
(Reporter: vasanth, Assigned: ethan)
References
Details
(Whiteboard: [caf priority: p2][CR 686617][p=5])
Attachments
(10 files, 4 obsolete files)
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
video/mp4
|
Details | |
(deleted),
video/mp4
|
Details | |
(deleted),
video/mp4
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
1. Connect device to wifi network. 2. Playback RTSP video by entering (rtsp://..)URL in browser. 3. Playback quality looks poor/lot of tethering as seen in the attached videos 4. Quality of rtsp playback with same device and wifi network in Android build is much better. Not sure if this is expected or what to check further here?
Comment 3•10 years ago
|
||
Unable to reproduce this issue on Flame 2.0 and Buri 2.0. Video plays correctly. I tested with the video here: http://www.wowza.com/html/mobile.html It would help us reproduce this issue if you could provide what device, firefox OS version, and perhaps a RTSP video URL that you used for testing.
Comment 4•10 years ago
|
||
The above comment was tested on the following environment: Device: Flame 2.0 Build ID: 20140701141253 Gaia: 98955263a0e376d8d41b1843b2dcc24108a4f5a0 Gecko: 8f1ae5b70576 Version: 32.0a2 (2.0) Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Device: Buri 2.0 Build ID: 20140701150152 Gaia: 43226cf5c3ad19728a88b3786595670b6d60e5c6 Gecko: 48ead8bc44bb Version: 32.0a2 (2.0) Firmware Version: v1.2device.cfg User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Flags: needinfo?(jmitchell)
(In reply to Pi Wei Cheng from comment #3) > It would help us reproduce this issue if you could provide what device, > firefox OS version, and perhaps a RTSP video URL that you used for testing. I have tried this on 8610 device (similar to Flame) 2.0 builds. Used clips from our internal RTSP server. I will try the clip video you shared. Gaia: 9d2f7bd16a8dc0c74c97c5a40d2f0731f3dfff4b Gecko: 32c226e5a7adbb95e9c4ee003dc9e64699da03e1
Flags: needinfo?(vasanth)
Comment 6•10 years ago
|
||
(In reply to vasanth from comment #5) > (In reply to Pi Wei Cheng from comment #3) > > It would help us reproduce this issue if you could provide what device, > > firefox OS version, and perhaps a RTSP video URL that you used for testing. > > I have tried this on 8610 device (similar to Flame) 2.0 builds. Used clips > from our internal RTSP server. > I will try the clip video you shared. > Gaia: 9d2f7bd16a8dc0c74c97c5a40d2f0731f3dfff4b > Gecko: 32c226e5a7adbb95e9c4ee003dc9e64699da03e1 > I have tried this on 8610 device (similar to Flame) 2.0 builds. Used clips The the chipset of flame device is "Qualcomm MSM8210 Snapdragon 200" So, could I know which device it is? Also, could I have your help? Please help me finish the following actions. - Please check the WIFI network quality and video quality. - Please try to use the other device to reproduce it. - If it still happened, please provide the video. Sorry for any inconvenience.
Flags: needinfo?(whsu) → needinfo?(vasanth)
Comment 7•10 years ago
|
||
(In reply to Pi Wei Cheng from comment #3) > Unable to reproduce this issue on Flame 2.0 and Buri 2.0. Video plays > correctly. > > I tested with the video here: > http://www.wowza.com/html/mobile.html > > It would help us reproduce this issue if you could provide what device, > firefox OS version, and perhaps a RTSP video URL that you used for testing. Good Job, Pi Wei! :) You got that right. Thanks!
(In reply to William Hsu [:whsu] from comment #6) > > I have tried this on 8610 device (similar to Flame) 2.0 builds. Used clips > The the chipset of flame device is "Qualcomm MSM8210 Snapdragon 200" > So, could I know which device it is? > > Also, could I have your help? > Please help me finish the following actions. > - Please check the WIFI network quality and video quality. > - Please try to use the other device to reproduce it. > - If it still happened, please provide the video. > Sorry for any inconvenience. Device is QRD8610 which is pretty close to 8210 device. Also as mentioned in description, RTSP playback of same device with android build is much better so I guess no issue with wifi network/device Please have a look at the videos already shared.
Flags: needinfo?(vasanth)
Comment 9•10 years ago
|
||
>
> Device is QRD8610 which is pretty close to 8210 device.
> Also as mentioned in description, RTSP playback of same device with android
> build is much better so I guess no issue with wifi network/device
> Please have a look at the videos already shared.
Something wrong on the decoder?
Could I have a request?
Is it possible to record the log for us?
If you would like to do that, please try the following command while you play the video.
- $ adb logcat > FILE_NAME
Thanks!
Reporter | ||
Comment 10•10 years ago
|
||
Reporter | ||
Comment 11•10 years ago
|
||
(In reply to William Hsu [:whsu] from comment #9) > Something wrong on the decoder? Not sure whether issue with decoder since we use same decoders with Android and it works fine there. Added logcat.
Comment 12•10 years ago
|
||
(In reply to vasanth from comment #10) > Created attachment 8449240 [details] > logcat_RTSP_FFOS.txt Thanks so much! :)
Comment 13•10 years ago
|
||
Hi, Ethan, Could I borrow your expertise? Do you have any thought regarding this bug?
Flags: needinfo?(ettseng)
Updated•10 years ago
|
Whiteboard: [CR 686617] → [caf priority: p2][CR 686617]
Comment 14•10 years ago
|
||
QA-Wanted report: Issue seems to be specific to a device we don't have - flipping triage flag to +
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Assignee | ||
Comment 15•10 years ago
|
||
(In reply to vasanth from comment #0) > 3. Playback quality looks poor/lot of tethering as seen in the attached What does "tethering" mean here? Do you mean a lot of "tearing"?
Flags: needinfo?(ettseng)
Assignee | ||
Comment 16•10 years ago
|
||
First, I cannot reproduce this bug on Flame 2.0 or 2.1 either (as comment 3 said). Second, I consulted with our colleague in Media team. The abundant "cancelBuffer" messages in the attached adb log cannot be a proof of problem. This message appears in the normal case as well. Meanwhile, by observing the recorded videos in the attachment, it seems media frames were lost during playing. We guess it might be relevant to network/connection quality issues. In order to analyze this issue further, we need to reproduce it first. vasanth, did you play the media in LAN or over Internet? Could you provide the original media file or the URL link?
Flags: needinfo?(vasanth)
Reporter | ||
Comment 17•10 years ago
|
||
(In reply to Ethan Tseng [:ethan] from comment #16) > vasanth, did you play the media in LAN or over Internet? We have an Internal wifi network + RTSP server in that. I played through that. > Could you provide the original media file or the URL link? I see this issue with almost all the files (in different resolutions/types) I tried. Not sure whether I can share them. > Meanwhile, by observing the recorded videos in the attachment, it seems > media frames were lost during playing. We guess it might be relevant to > network/connection quality issues. Is there any additional logs I can enable to debug network/quality issues? I #defined FORCE_PR_LOG here [1] But still didn't get any additional logs [1] http://dxr.mozilla.org/mozilla-central/source/content/media/RtspMediaResource.h#8
Flags: needinfo?(vasanth)
Comment 18•10 years ago
|
||
(In reply to vasanth from comment #17) > (In reply to Ethan Tseng [:ethan] from comment #16) > > vasanth, did you play the media in LAN or over Internet? > We have an Internal wifi network + RTSP server in that. I played through > that. > > > Could you provide the original media file or the URL link? > I see this issue with almost all the files (in different resolutions/types) > I tried. > Not sure whether I can share them. > > > Meanwhile, by observing the recorded videos in the attachment, it seems > > media frames were lost during playing. We guess it might be relevant to > > network/connection quality issues. > > Is there any additional logs I can enable to debug network/quality issues? > I #defined FORCE_PR_LOG here [1] But still didn't get any additional logs > > [1] > http://dxr.mozilla.org/mozilla-central/source/content/media/ > RtspMediaResource.h#8 vasanth, Indra also mentioned offline that he'll get in touch with you to see if you can reproduce this on the flame, may be that's worth a shot to see if this is device specific issue?
Flags: needinfo?(vasanth)
Flags: needinfo?(ikumar)
Comment 19•10 years ago
|
||
> vasanth, Indra also mentioned offline that he'll get in touch with you to
> see if you can reproduce this on the flame, may be that's worth a shot to
> see if this is device specific issue?
bhavana -- i checked internally and unfortunately that won't be possible. Our RTSP server is only WiFi accessible and is in India office and we don't have any flame devices yet in India office. So, we need to rely on adding debug logs to identify the root cause.
Flags: needinfo?(vasanth)
Flags: needinfo?(ikumar)
Comment 20•10 years ago
|
||
Because both QA and ethan can not reproduce this problem through testing it in real network or local network, it seems only be happened in partner's India lab. Therefore, I wonder if this is a network environmental problem. Then how can you guarantee the network conditions are same when we test 2 devices in different time? And do you test this on 2 different OS with the same device?
Assignee | ||
Comment 21•10 years ago
|
||
Hi Inder and vasanth, I suggest to capture packets on your device directly to clarify if the root cause is due to networking or chipset. 1. Push tcpdump-arm into the device. 2. # tcpdump-arm -i wlan0 -s 0 -w <pcap-filename> 3. Pull the pcap file and use Wireshark open the it. 4. Filter RTP packets by typing "rtp" in the Filter field of Wireshark. Observe the "Sequence number" field in RTP packets. Ideally, the sequence number should increase successively. We can determine how many RTP packets are lost by observing this field. If none RTP packets is lost, we could exclude the factor of networking.
Assignee | ||
Comment 22•10 years ago
|
||
> 3. Pull the pcap file and use Wireshark open the it.
Pull the pcap file and use Wireshark to open it.
(Sorry, typing too fast).
Reporter | ||
Comment 23•10 years ago
|
||
I see there is no packet drops for same video. But still video quality is not good
Assignee | ||
Comment 24•10 years ago
|
||
(In reply to vasanth from comment #23) > Created attachment 8450861 [details] > rtsp-pcap-no-rtp-packets-dropped.txt > I see there is no packet drops for same video. But still video quality is > not good Thanks for your investigation! So we can exclude the factor of network issue. :) Could you help to conduct another experiment? If possible, please push the media file into the device and play it through the Video app instead of the Browser app and RTSP protocol. In this way, we can further determine the issue is caused by RTSP component or decoding part.
Reporter | ||
Comment 25•10 years ago
|
||
(In reply to Ethan Tseng [:ethan] from comment #24) > If possible, please push the media file into the device and play it through > the Video app instead of the Browser app and RTSP protocol. Same media file playes well in video app normally. However for RTSP we need to do some hinting, after hinting, the media file fails to enumerate itself in video app. Android is able to play after hinting also. I enabled logs in RtspMediaResource.cpp and attached here. Hope that helps in debugging
Reporter | ||
Comment 26•10 years ago
|
||
Reporter | ||
Comment 27•10 years ago
|
||
Note: FORCE_PR_LOG in RtspMediaResource.cpp didn't work for me. So converted those logs to ALOGE and got them
Comment 28•10 years ago
|
||
blocking for now, given the active investigation and CAF deemed this is a blocker for 2.0 FC. If we end-up determining that its a POVB or resolve works for me, we'll fix the status.
blocking-b2g: 2.0? → 2.0+
Assignee | ||
Comment 29•10 years ago
|
||
(In reply to vasanth from comment #25) > Same media file playes well in video app normally. However for RTSP we need > to do some hinting, after hinting, the media file fails to enumerate itself > in video app. Android is able to play after hinting also. > I enabled logs in RtspMediaResource.cpp and attached here. Hope that helps > in debugging vasanth, Thanks for your help! I will investigate your attached log and see what we can do further.
Comment 30•10 years ago
|
||
Hi vasanth, may I know the tools you use to transfer medial file to mp4 format and add the hint information? In our local test environment, I use HandBrake to transfer media files to mp4 format and add hints using MP4Box in Ubuntu. BTW, how about the test result in below link mentioned in comment 3? rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov
Flags: needinfo?(vasanth)
Assignee | ||
Comment 31•10 years ago
|
||
I asked Benjmain Chen to help look into the log content. It looks normal and we still couldn't find clues. vasanth, Could you attach any of your MP4 file here? We might need it to reproduce this bug.
Reporter | ||
Comment 33•10 years ago
|
||
(In reply to Vincent Chang[:vchang] from comment #30) > Hi vasanth, may I know the tools you use to transfer medial file to mp4 > format and add the hint information? We used QuickTime in windows 7 to hint the video. > BTW, how about the test result in below link mentioned in comment 3? > rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov This link never works for me in India in both FFOS/Android. It always fails with network error. E/RtspMediaResource( 1341): Error in OnDisconnected 0x804b000e (In reply to Ethan Tseng [:ethan] from comment #31) > vasanth, > Could you attach any of your MP4 file here? > We might need it to reproduce this bug. I'm not sure whether I can share our video files. I'm sure this issue is not specific to video clips. Could you please share one of yours to confirm that?
Flags: needinfo?(vasanth)
Assignee | ||
Comment 34•10 years ago
|
||
Video Codec: H264-MPEG-4 AVC (part10) (h264) Resolution: 640x360 Frame date: 23.976024 Decoded format: Planar 4:2:0 YUV Audio Codec: MPEG AAC Audio (mp4a) Sample rate: 44100 Hz
Assignee | ||
Comment 35•10 years ago
|
||
(In reply to vasanth from comment #33) > > BTW, how about the test result in below link mentioned in comment 3? > > rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov > This link never works for me in India in both FFOS/Android. > It always fails with network error. > E/RtspMediaResource( 1341): Error in OnDisconnected 0x804b000e > So the RTSP server is not reachable from your lab. There might exist a firewall between your routes to the server that blocks RTSP or UDP traffic.
Assignee | ||
Comment 36•10 years ago
|
||
(In reply to vasanth from comment #33) > I'm not sure whether I can share our video files. > I'm sure this issue is not specific to video clips. > Could you please share one of yours to confirm that? I attached a MP4 file. Please give a try.
Assignee | ||
Updated•10 years ago
|
Attachment #8451502 -
Attachment description: t-mobile.mp4 → t-mobile-hinted.mp4
Assignee | ||
Comment 37•10 years ago
|
||
An MP4 file without hinting information.
Assignee | ||
Comment 38•10 years ago
|
||
Hi vasanth, I attached two MP4 files. One is hinted (t-mobile-hinted.mp4) and the other is not (t-mobile.mp4). Could you experiment with these two files? 1) Play t-mobile-hinted.mp4 over RTSP and observe the video quality. 2) Download t-mobile.mp4 and hint the file in your way. Then play your hinted t-mobile.mp4 over RTSP and observe it. Should you have any results, please let us know. :)
Reporter | ||
Comment 39•10 years ago
|
||
(In reply to Ethan Tseng [:ethan] from comment #38) > 1) Play t-mobile-hinted.mp4 over RTSP and observe the video quality. Your hinted clip plays well! Quality is good enough. > 2) Download t-mobile.mp4 and hint the file in your way. We hinted this using QuickTime, then its not playing through RTSP, after 8 seconds in all players. But folks here mentioned we use the same way for all clips and this may be clip specific problem. I will see if I can share some other hinted video which works in VLC/Android but not in FFOS. QuickTime hinting ----------------- 1. Open file in QuickTime Player 2. Click File -> Export 3. Choose Export type "Movie to Hinted Movie" 4. Verify output file name and change output file type match to match input file type. 5. Click OK.
Reporter | ||
Comment 40•10 years ago
|
||
Could you please try hinting some other video clip through QuickTime Windows and see if it plays well in RTSP/local playback? Meanwhile I will try to get access and share some of our clips.
Flags: needinfo?(ettseng)
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Reporter | ||
Comment 41•10 years ago
|
||
(In reply to Ethan Tseng [:ethan] from comment #31) > Could you attach any of your MP4 file here? > We might need it to reproduce this bug. I have shared some of the hinted files to you in mail. Please check.
Assignee | ||
Comment 42•10 years ago
|
||
Finally, this bug is reproducible here! This video clip was exported/hinted by QuickTime Player Pro 7.7.4 on Windows 7. The video quality is good on Android and VLC desktop, but terribly bad on FXOS.
Attachment #8451564 -
Attachment is obsolete: true
Flags: needinfo?(ettseng)
Updated•10 years ago
|
Target Milestone: --- → 2.0 S6 (18july)
Assignee | ||
Comment 43•10 years ago
|
||
We identified the root cause. This bug was a side-effect from the patch of bug 877116, which was aimed at fixing a certain audio latency issue. The affected part is AMPEG4ElementaryAssembler, which is used for two media formats: - MP4V-ES (video) - mpeg4-generic (audio/video) We are considering how to fix this bug without the need to re-open bug 877116. If it's urgent and we couldn't work out a solution in time, we could at least reverse the changes in that bug. Vasanth, Can you help to check the video clips you used to reproduce this bug are all in "MP4V-ES" video format?
Flags: needinfo?(vasanth)
Reporter | ||
Comment 44•10 years ago
|
||
(In reply to Ethan Tseng [:ethan] from comment #43) > Vasanth, > Can you help to check the video clips you used to reproduce this bug are all > in "MP4V-ES" video format? Not sure how to check that. ffmpeg shows below output for our clips. Is this what you are looking for? Metadata: major_brand : qt minor_version : 537199360 compatible_brands: qt creation_time : 2014-04-04 12:14:51 Duration: 00:00:45.46, start: 0.000000, bitrate: 135 kb/s Stream #0:0(eng): Video: mpeg4 (Simple Profile) (mp4v / 0x7634706D), yuv420p, 176x144 [SAR 1:1 DAR 11:9], 129 kb/s, 15 fps, 15 tbr, 15 tbn, 15 tbc Metadata: creation_time : 2014-04-04 12:14:51 handler_name : Apple Alias Data Handler Stream #0:1(eng): Data: none (rtp / 0x20707472) Metadata: creation_time : 2014-04-04 12:14:51 handler_name : Apple Alias Data Handler
Flags: needinfo?(vasanth)
Assignee | ||
Comment 45•10 years ago
|
||
You can use VLC player to easily view the Codec details from its media information. This example shows the codec of video is "mp4v".
Assignee | ||
Comment 46•10 years ago
|
||
A more precise way is to capture the streaming packets and open them in Wireshark. Locate to the server response for RTSP DESCRIBE request and expand RTSP > SDP > Media Attribute (a) You can see the "MIME Type" is "MP4V-ES" in this example.
Assignee | ||
Comment 47•10 years ago
|
||
(In reply to vasanth from comment #44) > Metadata: > Stream #0:0(eng): Video: mpeg4 (Simple Profile) (mp4v / 0x7634706D), > yuv420p, 176x144 [SAR 1:1 DAR 11:9], 129 kb/s, 15 fps, 15 tbr, 15 tbn, 15 tbc Anyway, I think this information already reveals it is MP4V. Thanks! :)
Assignee | ||
Comment 48•10 years ago
|
||
BTW, the format we are talking about here, is the "payload format" or "payload type". http://en.wikipedia.org/wiki/RTP_audio_video_profile
Assignee | ||
Comment 49•10 years ago
|
||
As the root cause stated in comment 43, change the bug summary to describe this bug more precisely.
Status: NEW → ASSIGNED
Summary: RTSP video playback quality is very poor → RTSP video playback quality is very poor if payload type is "MP4V-ES"
Whiteboard: [caf priority: p2][CR 686617] → [caf priority: p2][CR 686617][p=5]
Assignee | ||
Comment 50•10 years ago
|
||
Fix the logic to setup Access Unit for MP4V-ES payload format.
Attachment #8453529 -
Flags: review?(sworkman)
Assignee | ||
Comment 51•10 years ago
|
||
Hi Steve, My patch separates the logic of "MP4V-ES" and "mpeg4-generic" in AMPEG4ElementaryAssembler::submitAccessUnit(). For MP4V-ES, I restore its logic as before the patch of bug 877116. For mpeg4-generic, I keep the current logic to divide an RTP packet to several AUs (Access Unit).
Comment 52•10 years ago
|
||
Comment on attachment 8453529 [details] [diff] [review] bug-1032065-fix.patch Review of attachment 8453529 [details] [diff] [review]: ----------------------------------------------------------------- I'm fine with this approach, but I'm not so familiar with the formats here. It looks like MP4V-ES is for video (not for audio only) and the issue in Bug 877116 was for audio only. But can you confirm that we don't need to calculate timestamps for the packets here? It seems like this keeps the fix for Bug 877116 and fixes the scenario in this bug ... but are there other mpeg scenarios that use this code path? Could we end up with the latency issue for non-mp4v generic? Just want to make sure and have it noted here :) ::: netwerk/protocol/rtsp/rtsp/AMPEG4ElementaryAssembler.cpp @@ +358,5 @@ > CHECK(!mPackets.empty()); > > LOGV("Access unit complete (%d nal units)", mPackets.size()); > > + if (!mIsGeneric) { // MP4V-ES Switch the if and else around so it's if(mIsGeneric) first. Please add a couple of comments to the if and else branches to explain why we post one access unit message with multiple packets for mp4v-es and multiple access unit messages for generic. @@ +373,5 @@ > + sp<ABuffer> nal = *it; > + memcpy(accessUnit->data() + offset, nal->data(), nal->size()); > + offset += nal->size(); > + } > + CopyTimes(accessUnit, *mPackets.begin()); So, we definitely won't need (or want) to calculate timestamps for each packet for mp4v-es?
Assignee | ||
Comment 53•10 years ago
|
||
Add code comments.
Attachment #8453529 -
Attachment is obsolete: true
Attachment #8453529 -
Flags: review?(sworkman)
Attachment #8454346 -
Flags: review?(sworkman)
Assignee | ||
Comment 54•10 years ago
|
||
Fix a typo.
Attachment #8454346 -
Attachment is obsolete: true
Attachment #8454346 -
Flags: review?(sworkman)
Attachment #8454347 -
Flags: review?(sworkman)
Assignee | ||
Comment 55•10 years ago
|
||
(In reply to Steve Workman [:sworkman] from comment #52) > I'm fine with this approach, but I'm not so familiar with the formats here. > It looks like MP4V-ES is for video (not for audio only) and the issue in Bug > 877116 was for audio only. But can you confirm that we don't need to > calculate timestamps for the packets here? It seems like this keeps the fix > for Bug 877116 and fixes the scenario in this bug ... but are there other > mpeg scenarios that use this code path? Could we end up with the latency > issue for non-mp4v generic? > > So, we definitely won't need (or want) to calculate timestamps for each > packet for mp4v-es? RFC 6416 defines MP4V-ES (video) and MP4A-LATM (audio). The former is handled by AMPEG4ElementaryAssembler; and the latter is handled by AMPEG4AudioAssembler. http://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/rtsp/rtsp/ARTPSource.cpp?#59 The code path of non-mpeg4-generic audio is not affected by this patch. According to RFC 6416, I think it is fine to assign the timestamp of each Access Unit of MP4V-ES as the one in RTP header. What we should worry about is the video case of mpeg4-generic. mpeg4-generic is defined by RFC 3640 and can be applied to both audio and video. The solution of bug 877116 depends on the assumption that Access Units of audio have a constant time duration, and splits them into smaller AUs and calculates/assigns timestamps according to this assumption. This algorithm might not be appropriate to video. However, so far we don't encounter any case of using mpeg4-generic format for video. We need more time to investigate this issue. Since this bug is a blocker, I suggest to file a follow-up to track this known issue.
Assignee | ||
Comment 56•10 years ago
|
||
Comment on attachment 8454347 [details] [diff] [review] bug-1032065-fix.patch Hi Benjamin, Could you help to review my patch and see those code comments are correct?
Attachment #8454347 -
Flags: review?(bechen)
Comment 57•10 years ago
|
||
Comment on attachment 8454347 [details] [diff] [review] bug-1032065-fix.patch Review of attachment 8454347 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for the confirmation and adding the comments. Looks good to me!
Attachment #8454347 -
Flags: review?(sworkman) → review+
Comment 58•10 years ago
|
||
Vasanth -- can you please try out this patch and see if it fixes the issue?
Flags: needinfo?(vasanth)
Updated•10 years ago
|
Attachment #8454347 -
Flags: review?(bechen) → review+
Assignee | ||
Comment 59•10 years ago
|
||
Update comment "r=sworkman, r=bechen".
Attachment #8454347 -
Attachment is obsolete: true
Assignee | ||
Comment 60•10 years ago
|
||
The result of Try server: https://tbpl.mozilla.org/?tree=Try&rev=a110173ebcb9
Keywords: checkin-needed
Comment 61•10 years ago
|
||
https://hg.mozilla.org/integration/b2g-inbound/rev/0d4079709d5b
Keywords: checkin-needed
Reporter | ||
Comment 62•10 years ago
|
||
(In reply to Inder from comment #58) > Vasanth -- can you please try out this patch and see if it fixes the issue? Works. RTSP MP4V video quality is good with this patch
Flags: needinfo?(vasanth)
Comment 63•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/0d4079709d5b
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 64•10 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/49f3928fe062
status-b2g-v2.0:
--- → fixed
status-b2g-v2.1:
--- → fixed
status-firefox31:
--- → wontfix
status-firefox32:
--- → fixed
status-firefox33:
--- → fixed
Assignee | ||
Comment 65•10 years ago
|
||
I received an email sent from "nobody@cruncher.build.mozilla.org". It seems some automated test system is saying my patch caused a performance regression. However, I don't think our patch will be executed by any automated tests right now. Steve, do you have any idea about this mail? Should I do anything in response to it? --------------------------------------------------------------------------------------------------------- Title: <Regression> Mozilla-Aurora - TResize - Ubuntu HW 12.04 x64 - 10.8% Regression: Mozilla-Aurora - TResize - Ubuntu HW 12.04 x64 - 10.8% increase --------------------------------------------------------------------------- Previous: avg 14.082 stddev 0.635 of 12 runs up to revision a3dce4eedb9a New : avg 15.601 stddev 0.091 of 12 runs since revision 49f3928fe062 Change : +1.519 (10.8% / z=2.393) Graph : http://mzl.la/UcHe9V Changeset range: http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=a3dce4eedb9a&tochange=49f3928fe062 Changesets: * http://hg.mozilla.org/releases/mozilla-aurora/rev/49f3928fe062 : Ethan Tseng <ettseng@mozilla.com> - Bug 1032065 - RTSP video playback quality is poor if payload type is MP4V-ES. r=sworkman. r=bechen, a=2.0+ : http://bugzilla.mozilla.org/show_bug.cgi?id=1032065 Bugs: * http://bugzilla.mozilla.org/show_bug.cgi?id=1032065 ---------------------------------------------------------------------------------------------------------
Flags: needinfo?(sworkman)
Comment 66•10 years ago
|
||
I agree with you - I don't think there's anything in the patch that could have caused this. So, I think it's ok to ignore the email.
Flags: needinfo?(sworkman)
Assignee | ||
Comment 67•10 years ago
|
||
(In reply to Steve Workman [:sworkman] from comment #66) > I agree with you - I don't think there's anything in the patch that could > have caused this. So, I think it's ok to ignore the email. Okie dokie. :)
Updated•10 years ago
|
Flags: in-moztrap?(smiko)
You need to log in
before you can comment on or make changes to this bug.
Description
•