This is a follow-up bug from bug 1112438 comment 23. "...the first AudioData->mTime in AudioQueue() (237166 us, recoded by Woodduck) is quite large than the one (21333 us, by flame)."

Is that a problem? Our media stack should handle non-zero start time well no matter what value it is.

(In reply to JW Wang [:jwwang] from comment #1) > Is that a problem? Our media stack should handle non-zero start time well no > matter what value it is. What do you mean by "handle non-zero start time"? Is there more information related to that?

The mTime of the first audio sample could be non-zero which we should have no problem in handling that.

What Blake and I saw the audio frame inforamtion of the clip recorded by woodduck from ffprobe is, =============================== 1st AudioFrame [FRAME] media_type=audio key_frame=1 pkt_pts=0 pkt_pts_time=0.000000 pkt_dts=0 pkt_dts_time=0.000000 pkt_duration=11384 pkt_duration_time=0.237167 pkt_pos=552725 pkt_size=341 sample_fmt=fltp nb_samples=1024 channels=2 channel_layout=stereo [/FRAME] ======================= 2nd AudioFrame [FRAME] media_type=audio key_frame=1 pkt_pts=11384 pkt_pts_time=0.237167 pkt_dts=11384 pkt_dts_time=0.237167 pkt_duration=1024 pkt_duration_time=0.021333 pkt_pos=553066 pkt_size=341 sample_fmt=fltp nb_samples=1024 channels=2 channel_layout=stereo [/FRAME] The pts_time gap between these 2 frames is quite large, and we saw the 2nd AudioFrame is put in the first place of AudioQueue. (The 1st frame is gone) This would be a first issue to be figure out. The second is, if there's no problem about 1st & 2nd Audio frames, then why there's a quite large gap between them ? Also need to figure out.

This should not be a blocker for other bugs although the first two of audio recorded data looks not right. But this should not impact playback side. Playback needs to handle as many kinds of file as possible. I would say it should be a separate bug, no direct dependency on bug 1112438. We should fix this bug and bug 1112438 individually.

Hi Blake, So this is generic bug right? Thanks!

I am not sure whether it is a generic bug or not. But according to Kilik's investigation mentioned in bug 1112438 comment 23, it seems not be found on Flame.

Hi Kilik, Could you please help to mark correct Tracking Flag?(status-b2g)? Thanks!

Hmm, sorry Josh, I'm not quit sure what is the most suitable tracking flag for this issue. Since I only saw this phenomenon on Woodduck(2.0), not on Flame(2.2). Basically, we still don't know if it's related to different b2g version or Hardware. (Didn't do a cross verified, like flashing v2.2 to woodduck, v2.0 to flame) But indeed, according to Blake's Comment 5, this issue is created for tracking a phenomenon we saw, not a blocking to any other issues.

Mass change P3->P4 to align with new Mozilla triage process.

Closing as we are not working on Firefox OS anymore.