1118090 - [FFOS2.0][Video]The first recorded audio timestamp is quite large.

Status: RESOLVED WONTFIX

(Core :: Audio/Video: Recording, defect, P4)

Description

[Blake Wu [:bwu][:blakewu]]

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

Comment 1

[JW Wang [:jwwang] [:jw_wang]]

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

Comment 2

[Blake Wu [:bwu][:blakewu]]

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

Comment 3

[JW Wang [:jwwang] [:jw_wang]]

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

Comment 4

[Kilik Kuo [:kikuo] (inactive)]

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.

Comment 5

[Blake Wu [:bwu][:blakewu]]

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.

Comment 6

[Josh Cheng [:josh]]

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

Comment 7

[Blake Wu [:bwu][:blakewu]]

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.

Comment 8

[Josh Cheng [:josh]]

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

Comment 9

[Kilik Kuo [:kikuo] (inactive)]

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.

Comment 10

[Bulk Bug Changes for mreavy's org]

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

Comment 11

[Sylvestre Ledru [:Sylvestre]]

Closing as we are not working on Firefox OS anymore.