Talk:Dynamic Adaptive Streaming over HTTP

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Networking / Websites (Rated Start-class, Low-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.
Taskforce icon
This article is supported by Networking task force (marked as Low-importance).
Taskforce icon
This article is supported by WikiProject Websites (marked as Low-importance).
 
WikiProject Internet (Rated Start-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
 

Clarify wording in server section[edit]

It says "Note that no specific support is required from server for DASH content, with the exception of _Live Streaming_" but it's not clear what "Live Streaming" is in this context. There's no part of the HTTP protocol currently defined as "Live Streaming" that I could find. 172.2.203.49 (talk) 16:32, 6 May 2015 (UTC) Ron J

This is a term specific to streaming media rather than to HTTP itself. In terms of MPEG-DASH, live streaming requires on-the-fly generation of segments and re-generation of manifest file just because of the nature of the media (it just happens "right now", it's not pre-recorded). Common web server cannot handle that. Hence the note about exception of live streaming. Perhaps "Live Streaming" should not be started with capital letters though. Yurriq (talk) 00:40, 8 May 2015 (UTC)

DASH in title?[edit]

Should "DASH" be included as part of the page's name? BambelB (talk) 15:54, 9 December 2011 (UTC)

Perhaps. I've anyway created a redirect from MPEG-DASH The Seventh Taylor (talk) 08:14, 1 May 2012 (UTC)

Link to Adaptive bitrate streaming[edit]

Shouldn't this link to: Adaptive bitrate streaming? BambelB (talk) 15:54, 9 December 2011 (UTC)

I agree. Done now. The Seventh Taylor (talk) 08:14, 1 May 2012 (UTC)

Link to MPEG[edit]

Shouldn't the navigation boxes {{Compression Formats}} and {{Compression Methods}} be added here? And where should MPEG-DASH fit into these? The Seventh Taylor (talk) 23:58, 12 April 2012 (UTC)

DASH 264[edit]

I noticed the DASH Industry Forum published the v0.9 standard for 'DASH264' [1]. Is this the same as MPEG-DASH or something different? The Seventh Taylor (talk) 10:50, 17 January 2013 (UTC)

I started reading the standard for 'DASH264' [2] and I found on page 7, line 16 that it mentions, as a separate standard, the 'MPEG-DASH' standard. (MoreOrLezFun (talk) 19:57, 23 January 2013 (UTC))
I think MPEG-DASH standard link need to be updated to [3] — Preceding unsigned comment added by 207.253.7.190 (talk) 21:38, 4 August 2014 (UTC)

Is DASH patent encumbered?[edit]

It would be good to clarify this information in the article — Bahaltener (talk) 02:47, 18 December 2014 (UTC)

Should HLS be mentioned in Introduction?[edit]

There is no need to mention MPEG-DASH is similar to Apples HLS. — Preceding unsigned comment added by Rushikesh90 (talkcontribs) 04:56, 11 May 2016 (UTC)

Also, the introduction states that "MPEG-DASH is the first adaptive bit-rate HTTP-based streaming solution that is an international standard.[1]" (introduced 2012). But HLS has been available as an Internet Engineering Task Force standard since May 2009 (see https://en.wikipedia.org/wiki/HTTP_Live_Streaming).

External links modified[edit]

Hello fellow Wikipedians,

I have just modified one external link on Dynamic Adaptive Streaming over HTTP. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

You may set the |checked=, on this template, to true or failed to let other editors know you reviewed the change. If you find any errors, please use the tools below to fix them or call an editor by setting |needhelp= to your help request.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

If you are unable to use these tools, you may set |needhelp=<your help request> on this template to request help from an experienced user. Please include details about your problem, to help other editors.

Cheers.—InternetArchiveBot (Report bug) 05:26, 18 December 2016 (UTC)

Incorrect to claim that the media is necessarily segmented[edit]

In the intro, there's this claim that DASH involves "breaking the content into a sequence of small HTTP-based file segments." I have a 48 minute counter-example I'm looking at, and each video bitrate has one file (no breaking up by time segment). Maybe this should be removed or qualified.

Seamlessly[edit]

I intensely dislike the word 'seamlessly' in the lead. If only it were true. Not long ago, I was watching a paddling event from Tahiti, using Chromium/YouTube. The film crew was instructed not to interfere with the race by leaving wake behind that might affect the next boat, so until a large separation developed, the coverage was restricted to long shots with a lot of compression and not much detail worth having. But then a woman's boat from Tahiti did get a huge separation, and they elected to cut back to this boat every second minute—or so it seemed—and there would be a sudden change to a much closer shot, and the complexity of the image and the detail available would spike up. Chromium got itself into a resolution switching loop where it managed to sputter every darn time. During the close ups, where you could actually seem the form and technique, Chromium would glitch for hundreds of milliseconds at a time during the crucial mechanics. It did this over and over again, for hours. Then you'd go back to a long shot, where there wasn't much detail worthy seeing, and everything would become fluid again. I gave on the race, and spent my time monkeying around with Chromium's buffer settings to try to figure the problem out.

From a CS perspective, DASH is attempting to solve a problem where latency in fully receiving a request is a function of network congestion. In this model, lower bandwidth involves serving up smaller packets, which will predictably reduce latency. But this is just one element of the real world.

Consider that your ISP is saturated, and that it has an algorithm to allocate a fixed share to each customer (if you double your monthly fee, they'll allocate you a share ten times larger than a basic customer, but that's another story). When 720p goes from high compression (boring, somewhat stationary scene) to low compression (intricate, fluid, detailed scene) the network bandwidth requirement shoots up, beyond your ISP cap, and your packets begin to stack up in network buffers (buffer lag) like cars in rush hour traffic. Reception latency rises continuously, until packets begin to fall on the floor (you have finally exhausted buffer lag) and now TCP/IP is negotiating retransmission (I assumed this was still in the mix, but didn't check). As Chromium's 5 s forward buffering begins to deplete, Chromium switches to a lower resolution. But the lower resolution needs just as much data for the detailed scene as high resolution needed for the static scene, and you're still operating dangerously close to your ISP cap, and TCP/IP is still recovering dropped packets from both the original stream and the new resolution.

The problem for Chromium was that reducing the resolution request did not have the immediate effect on reception latency that its model requires in order to deliver seamless flow.

I'm not even getting into your ISP incorporating an adaptive burst bandwidth term in their cap calculation (they'll give you a bit more than your share, briefly, if you've earned some bandwidth "credit" by not constantly downloading the Wayback Machine).

The word 'seamless' would apply if this were a one dimensional problem, but in real life, the problem has many complexities.

If stupid Chromium/YouTube had increased my browser buffering from 5 s to 30 s after the tenth multi-second stall in ten minutes at exactly the worst time, playback would have been smooth. I eventually tricked it into doing so (can't recall whether this test was Chromium or Firefox) by pressing "pause" for a long time, and when I came back I had many minutes of preloaded data, and basically DASH was no longer in effect (my resolution was effectively locked in over short time periods, unless Chromium wanted to spill minutes of prefetched data onto the floor).

I also see this all the time in hockey videos on YouTube where there's a frenzy of activity and camera angle changes right as the goal is scored, as the intensity of action ramps up, the encoder sheds resolution from the high-frequency components until the puck becomes exceptionally blurry if not outright invisible, and it takes six replays just to figure out which players actually touched the puck in the crucial moments. I've had experiences where replay after replay, you see the defenseman loading up for the break-out pass, then the video stalls and stutters as the camera angle breaks up ice, and the next thing you get a good look at is Connor McDavid is skating past the crease with his arms in the air.

Someone please tell me where this 'seamless' DASH experience exists, so I can enjoy it, too. — MaxEnt 17:12, 13 July 2017 (UTC)

External links modified[edit]

Hello fellow Wikipedians,

I have just modified 3 external links on Dynamic Adaptive Streaming over HTTP. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

You may set the |checked=, on this template, to true or failed to let other editors know you reviewed the change. If you find any errors, please use the tools below to fix them or call an editor by setting |needhelp= to your help request.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

If you are unable to use these tools, you may set |needhelp=<your help request> on this template to request help from an experienced user. Please include details about your problem, to help other editors.

Cheers.—InternetArchiveBot (Report bug) 06:57, 15 September 2017 (UTC)