We see frame drops while streaming RTSP video even though from tcpdump we see all the RTP packets have been received
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.0?
Component: Gaia::Video → RTSP
NI ethan to help here.
I will look into this issue to see what we can do.
Assignee: nobody → ettseng
I tested using the video clip shared in comment 3. Although the video can be played well locally (such as using QuickTime Player), it cannot be played smoothly any longer while it was turned into streaming. Let me define two terms here (just for clarification, not standard terms) - Frozen frame: While playback is still running, a frame stops because the successive frame is not coming. - Broken frame: A frame(picture) is not complete because some parts of it were missing or malformed. We've tested playing the same media source using Flame v2.1, Android phone and VLC desktop (2.1.5). All of them suffer either frozen frames or broken frames. On Android, we see more broken frames; while on FFOS, we see more frozen frames instead. I also captured packets by tcpdump, and as bhargavg1 said, there is no packet dropped by the network side. It seems there are malformed packets which were dropped by RTP assembler or certain decoder.
For now I think the problem seems to be the media source. We could spend more time to identify the root cause of frame drops. However since this clip cannot played well on VLC and Android either, I don't think we should block on this.
Bhavana, according to comment 7, can you talk with partner to remove this bug from CAF blocker list.
Hi Bhargavg, I recorded a video to show how the clip is played on my Flame v2.1. http://youtu.be/b-jFvPuKqkw The video is set as non-public and only visible to who has this link. If you still have concern, let me know and I'll remove it. As I said in comment 6, we don't see many broken frames on FFOS but some frozen frames. What strange is, the playback quality is not stable and changes rapidly every time (even using VLC player). In other trials, I saw much worse quality on both VLC and Flame. Could you share the symptom that you treat as frame drops? Did you also see frozen frames, or it was broken frames?
Whiteboard: [caf priority: p2][CR 706114] → [caf priority: p2][CR 706114] [p=5]
Target Milestone: --- → 2.1 S4 (12sep)
Thanks ethan, I'll try to get more info from CAF for android perf on the same platform.
(In reply to Ethan Tseng [:ethan] from comment #6) > We've tested playing the same media source using Flame v2.1, Android phone > and VLC desktop (2.1.5). > All of them suffer either frozen frames or broken frames. > On Android, we see more broken frames; while on FFOS, we see more frozen > frames instead. Ethan, what is the android version being tested here is it 4.3 ? Can we test on 4.4 to make sure the issue isnt seen there
(In reply to bhargavg1 from comment #11) > Ethan, what is the android version being tested here is it 4.3 ? Can we test > on 4.4 to make sure the issue isnt seen there Yes. I used Android 4.3. My colleague tried 4.4 and he reported the same situation. Android has a little broken frames (due to frame drops) but the overall playback is more smooth than Flame.
Considering all the above information: both VLC player, Android 4.3 & 4.4 have the same issue and problem seems to be the media source, I'd suggest we do not make this as CAF blocker. thanks.
Confirmed offline with mvines that this isn't a blocker, so setting the flag accordingly.
blocking-b2g: 2.0? → -
Looks like we care about it for 2.1 at least.
Youtube videos concerned are removed.
Ethan, one general concern that CAF test teams are reporting is frame drops compared to LA for RTSP streaming. Wondering have you tried to do any testing/comparison in that direction. Will create a new bug to take this further
Adding NI for ethan to get back in comment #20 so we know here this is heading for 2.1 as CAF is expecting to be resolved in that timeframe.
We are already working on bug 1056187. Do I need to do anything else here?
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.