Jump to content

Talk:Dynamic Adaptive Streaming over HTTP

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

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[reply]

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)[reply]

DASH in title?

[edit]

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

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

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

I agree. Done now. The Seventh Taylor (talk) 08:14, 1 May 2012 (UTC)[reply]
[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)[reply]

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)[reply]

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))[reply]
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)[reply]

Is DASH patent encumbered?

[edit]

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

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 (talk • contribs) 04:56, 11 May 2016 (UTC)[reply]

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

[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}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • 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.

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

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)[reply]

[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.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • 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.

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

Add VideoJS to list of DASH Implementations

[edit]

Please note: I have contributed to the VideoJS project in the past and work for a company (Brightcove) that continues to contribute to that project. — Preceding unsigned comment added by Dlapalomento (talk • contribs) 23:14, 22 January 2019 (UTC)[reply]

Reply 22-JAN-2019

[edit]

  Edit request declined  

  1. The section that the COI edit request is attempting to add information to contains a maintenance template which states that it contains "information of unclear or questionable importance or relevance to the article's subject matter".
  2. As such, the COI editor should attempt to garner a consensus for this change with local editor's interested in the subject before making an edit request.

Regards,  Spintendo  23:26, 22 January 2019 (UTC)[reply]

Ericej johnson 73.209.172.43 (talk) 04:45, 22 August 2023 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Dynamic_Adaptive_Streaming_over_HTTP&oldid=1201539469"