1032065 - RTSP video playback quality is very poor if payload type is "MP4V-ES"

Status: RESOLVED FIXED

(Firefox OS Graveyard :: RTSP, defect, P1)

Description

[vasanth]

Attachment: Poor RTSP video playback

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 1

[howie [:howie]]

Hi QA, can we take a look if it's the case? Thanks.

Comment 2

[bhavana bajaj [:bajaj]]

NI William to help test/confirm this.

Comment 3

[Pi Wei Cheng [:piwei] (inactive)]

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

[Pi Wei Cheng [:piwei] (inactive)]

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

Comment 5

[vasanth]

(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

Comment 6

[William Hsu [:whsu]]

(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.

Comment 7

[William Hsu [:whsu]]

(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!

Comment 8

[vasanth]

(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.

Comment 9

[William Hsu [:whsu]]

> 
> 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!

Comment 10

[vasanth]

Attachment: logcat_RTSP_FFOS.txt

Comment 11

[vasanth]

(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

[William Hsu [:whsu]]

(In reply to vasanth from comment #10)
> Created attachment 8449240 [details]
> logcat_RTSP_FFOS.txt

Thanks so much! :)

Comment 13

[William Hsu [:whsu]]

Hi, Ethan,

Could I borrow your expertise?
Do you have any thought regarding this bug?

Comment 14

[Joshua Mitchell (Inactive)]

QA-Wanted report: Issue seems to be specific to a device we don't have - flipping triage flag to +

Comment 15

[Ethan Tseng [:ethan]]

(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"?

Comment 16

[Ethan Tseng [:ethan]]

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?

Comment 17

[vasanth]

(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

Comment 18

[bhavana bajaj [:bajaj]]

(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?

Comment 19

[Inder]

> 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.

Comment 20

[Ken Chang[:kenkai]]

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?

Comment 21

[Ethan Tseng [:ethan]]

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.

Comment 22

[Ethan Tseng [:ethan]]

> 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).

Comment 23

[vasanth]

Attachment: rtsp-pcap-no-rtp-packets-dropped.txt

I see there is no packet drops for same video. But still video quality is not good

Comment 24

[Ethan Tseng [:ethan]]

(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.

Comment 25

[vasanth]

(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

Comment 26

[vasanth]

Attachment: rtsp-debug-logcat-fullscreen.txt

Comment 27

[vasanth]

Note: FORCE_PR_LOG in RtspMediaResource.cpp didn't work for me. So converted those logs to ALOGE and got them

Comment 28

[bhavana bajaj [:bajaj]]

 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.

Comment 29

[Ethan Tseng [:ethan]]

(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

[Vincent Chang[:vchang][changyihsin]]

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

Comment 31

[Ethan Tseng [:ethan]]

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.

Comment 32

[howie [:howie]]

assign Ethan as owner for this.

Comment 33

[vasanth]

(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?

Comment 34

[Ethan Tseng [:ethan]]

Attachment: t-mobile-hinted.mp4

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

Comment 35

[Ethan Tseng [:ethan]]

(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.

Comment 36

[Ethan Tseng [:ethan]]

(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.

Comment 37

[Ethan Tseng [:ethan]]

Attachment: t-mobile.mp4

An MP4 file without hinting information.

Comment 38

[Ethan Tseng [:ethan]]

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. :)

Comment 39

[vasanth]

Attachment: t-mobile_quicktime_hinted.mp4

(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.

Comment 40

[vasanth]

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.

Comment 41

[vasanth]

(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.

Comment 42

[Ethan Tseng [:ethan]]

Attachment: t-mobile-hinted-byqt.mp4

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.

Comment 43

[Ethan Tseng [:ethan]]

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?

Comment 44

[vasanth]

(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

Comment 45

[Ethan Tseng [:ethan]]

Attachment: Codec details from VLC player

You can use VLC player to easily view the Codec details from its media information. This example shows the codec of video is "mp4v".

Comment 46

[Ethan Tseng [:ethan]]

Attachment: MIME type from Wireshark

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.

Comment 47

[Ethan Tseng [:ethan]]

(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! :)

Comment 48

[Ethan Tseng [:ethan]]

BTW, the format we are talking about here, is the "payload format" or "payload type".
http://en.wikipedia.org/wiki/RTP_audio_video_profile

Comment 49

[Ethan Tseng [:ethan]]

As the root cause stated in comment 43, change the bug summary to describe this bug more precisely.

Comment 50

[Ethan Tseng [:ethan]]

Attachment: bug-1032065-fix.patch

Fix the logic to setup Access Unit for MP4V-ES payload format.

Comment 51

[Ethan Tseng [:ethan]]

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

[Steve Workman [:sworkman] (INACTIVE)]

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?

Comment 53

[Ethan Tseng [:ethan]]

Attachment: bug-1032065-fix.patch

Add code comments.

Comment 54

[Ethan Tseng [:ethan]]

Attachment: bug-1032065-fix.patch

Fix a typo.

Comment 55

[Ethan Tseng [:ethan]]

(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.

Comment 56

[Ethan Tseng [:ethan]]

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?

Comment 57

[Steve Workman [:sworkman] (INACTIVE)]

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!

Comment 58

[Inder]

Vasanth -- can you please try out this patch and see if it fixes the issue?

Comment 59

[Ethan Tseng [:ethan]]

Attachment: bug-1032065-fix.patch

Update comment "r=sworkman, r=bechen".

Comment 60

[Ethan Tseng [:ethan]]

The result of Try server:
https://tbpl.mozilla.org/?tree=Try&rev=a110173ebcb9

Comment 61

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/integration/b2g-inbound/rev/0d4079709d5b

Comment 62

[vasanth]

(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

Comment 63

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/0d4079709d5b

Comment 64

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/49f3928fe062

Comment 65

[Ethan Tseng [:ethan]]

I received an email sent from "[e-mail]".
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 <[e-mail]> - 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
---------------------------------------------------------------------------------------------------------

Comment 66

[Steve Workman [:sworkman] (INACTIVE)]

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.

Comment 67

[Ethan Tseng [:ethan]]

(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. :)