After some time stream via multipart/x-mixed-replace is stop working
Reported by
lendlor...@gmail.com,
Aug 22 2016
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Transfer images with multipart/x-mixed-replace; 2. Wait some time(from some seconds to some minutes) 3. Image(video) is dissapeared What is the expected behavior? Image(video) still showing. chrome version 51.0.2704.106 work well What went wrong? Chrome show that data are transfer and connection isnt closed, but image(video) isn't shown. Did this work before? N/A Chrome version: 52.0.2743.116 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 22.0 r0 In chrome version 51.0.2704.106 there isn't any problem with image(video)
,
Aug 22 2016
Could you provide an image-file along with a sample HTML page that reproduces the problem?
,
Aug 22 2016
,
Aug 23 2016
http://173.70.220.233:81/videostream.cgi?loginuse=admin&loginpas= you can wath here or any other camera just after some time image is dissaper
,
Aug 23 2016
Sry, bad example, will try to find better. Here is problem with login.
,
Aug 23 2016
http://www.insecam.org/en/view/330289/ http://77.43.144.59:8081/mjpg/video.mjpg?COUNTER this is better example
,
Aug 30 2016
Thank you for providing more feedback. Adding requester "junov@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 13 2016
I verified that the image does in fact disappear, although it took a long time to do so.
,
Oct 4 2016
the image is live captured motion jpeg, shouldn't it belongs to WebRTC? I don't see why it is media bug. Please correct me if I am wrong.
,
Oct 5 2016
Under the assumption that this is related to multipart content - which is handled by stuff in core/fetch/ (MultipartImageResourceParser and ImageResource in some form of harmony.)
,
Oct 5 2016
,
Oct 5 2016
As far as I can see there is no bug in Chrome version 53.0.2785.116
,
Oct 5 2016
,
Oct 6 2016
I couldn't reproduce the issue with r423075 on Linux. Waiting for 30min. > schenney@ How long did it take in your case?
,
Oct 6 2016
Failed to reproduce: Waited 4 hours.
,
Oct 6 2016
Bug only in chrome version 52
,
Oct 6 2016
Ah, sorry, I misunderstood. As Chrmoe 53 is now stable I think we don't have to fix it.
,
Oct 6 2016
IN reply to comment #14, I have no idea how long it took beyond "more than an hour". But that's not important now. WontFix is good. |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by mmenke@chromium.org
, Aug 22 2016