The issue reproduces when playing through the network and locally from the hard disk.

Tested in chrome # 60.0.3112.50 and Canary #61.0.3153.0 on Ubuntu 14.04 and not able to reproduce the issue.Please find the screen shot for more information.

1@crownet.ru: Could you please let me know if i have missed anything and if possible,Please create new profile without extensions and apps.Re-check once and let us know the observations of the issue which would help us to triage the issue further.

Thanks in Advance.

Deleted: 740138.png 103 KB

	740138.png 103 KB View Download

I created new profile. The issue reproduces.

The video is quickly buffered to 17 minutes and then the buffering stops.
If I seek to nonbuffered position then:
00:06:42 304	debug	FFmpegDemuxer: av_read_frame(): End of file
00:07:41 327	event	PAUSE
00:07:41 328	seek_target	930.116567

Video of buffering: https://drive.google.com/file/d/0B8p5fhrZDlHha2V3bVl3UURicEk/view?usp=sharing

Tested in chrome 59.0.3071.115, 60.0.3112.40, and 61.0.3141.7: exactly the same effect.

If I seek close to the end of the buffer, the playback does not stop, but another buffer is created ( https://drive.google.com/file/d/0B8p5fhrZDlHhdXl3VjdJWmhxWWc/view?usp=sharing ).

Deleted: 1.png 112 KB

	1.png 112 KB View Download

Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Unable to reproduce the issue using #60.0.3112.40 on Linux Ubuntu 14.04 as per the steps mentioned in comment #0.

Please find the log report from chrome://media-internals/ 

Requesting Blink>Media>Video team for further triaging of the issue.

Thanks!!

Deleted: media-internals.txt 31.8 KB

media-internals.txt 31.8 KB View Download

It seems I understood why you can not reproduce the problem. I set a throttling to 5 MB/s and my problem also disappeared. 
The file is in Siberia of Russia, so it's logical that you have lower speed than me. Try to download the file and view locally.

Deleted: media-internals-no-throttling.txt 8.0 KB

media-internals-no-throttling.txt 8.0 KB View Download

Deleted: media-internals-throttling-5mb.txt 7.5 KB

media-internals-throttling-5mb.txt 7.5 KB View Download

Ok, I've been able to repro and debugged this and I believe I understand the root cause of the issue.
The problem here is that FFmpegDemuxer memory consumption grows unbounded when the input file has an extra audio/video tracks, because FFmpegDemuxer::StreamsHaveAvailableCapacity currently doesn't exclude disabled streams. Previously, when multiple tracks were not supported, we would release all unnecessary demuxer streams and thus FFmpegDemuxer::StreamsHaveAvailableCapacity would skip them. But now that we allow multiple tracks/streams, the unused audio/video streams are disabled, instead of being released. But we always drop packets for disabled demuxer streams, and thus those disabled streams always have available capacity, which causes FFmpegDemuxer::StreamsHaveAvailableCapacity to always return true and as a result FFmpegDemuxer keeps buffering more and more data until it eventually reaches memory usage limit.

This CL should fix it:
https://chromium-review.googlesource.com/c/572231/

This bug was introduced in 59.0.3069.0, I'll merge the fix into M60 ASAP (after verifying it for a couple of days in canary, of course), I'm not sure if we'll have an opportunity to fix it in M59.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e08f39a041f2b288403fa7c36ee43f5afe89c5c7

commit e08f39a041f2b288403fa7c36ee43f5afe89c5c7
Author: Sergey Volk <servolk@google.com>
Date: Sat Jul 15 01:00:29 2017

Fix excessive memory consumption in FFmpegDemuxer

Previously FFmpegDemuxer would release all unnecessary audio/video
streams. But with multi-track support unused a/v streams are disabled
instead of being released. So now we need to exclude disabled streams
in FFmpegDemuxer::StreamsHaveAvailableCapacity, otherwise it will
always return true (since disabled streams always have available
capacity), causing FFmpegDemuxer memory usage to grow unbounded.

BUG= 740138 

Change-Id: I4f2c990232a01988f66ff475bbb8b9970aff742f
Reviewed-on: https://chromium-review.googlesource.com/572231
Commit-Queue: Sergey Volk <servolk@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#486957}
[modify] https://crrev.com/e08f39a041f2b288403fa7c36ee43f5afe89c5c7/media/filters/ffmpeg_demuxer.cc

Requesting a merge to M60. I know it's going to stable very soon, but I believe this fix is trivial and safe enough to be included.
Unit test coverage is coming in a separate CL:
https://chromium-review.googlesource.com/c/575390/

If the merge is approved, I'll merge both the fix and the test to M60 branch.
The fix has been in canary branch since Friday.

bustamante@ for M6-Merge Review.

This bug requires manual review: We are only 7 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9fc07690fae0d86390ea7302b481f1f2d87e1375

commit 9fc07690fae0d86390ea7302b481f1f2d87e1375
Author: Sergey Volk <servolk@google.com>
Date: Tue Jul 18 00:11:16 2017

Add a test for FFmpegDemuxer memory usage in the multi-track case

We had a bug where FFmpegDemuxer usage was too high due to excessive
buffering caused by not taking into account enabled/disabled stream
status. This unit test should provide test coverage for that.

BUG= 740138 

Change-Id: Ia29175a8c90be4465aeffe189d7d8e48e738ef68
Reviewed-on: https://chromium-review.googlesource.com/575390
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Sergey Volk <servolk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#487306}
[modify] https://crrev.com/9fc07690fae0d86390ea7302b481f1f2d87e1375/media/filters/ffmpeg_demuxer_unittest.cc

My recommendation is to wait until M61. We are only few days away from M60 stable promotion, and our focus is to ensure that the branch is stable and only taking truly critical bug fixes. If this is truly critical, please provide clear justification for why this should be included in M60, it's full impact, and how safe this merge is. Rejecting merge, but please re-apply Merge-Requet-60 label if you think otherwise. 

Well, I don't know if this meets the bar of critical bug fix, probably not. But this bug is causing excessive memory usage (up to 150MB per media element) when there are extra media tracks and failure to play media files larger than ~150MB when playback is done via direct URL playback (i.e. non-MSE) code path. And I believe the fix is really simple and very safe, so I thought it was worth including into M60.

We got a few bug reports for Chromecast where people encountered this issue when playing large media files via Plex app. But since Chromecast is built from downstream code I can simply cherry-pick the fix directly into Chromecast release branch, so we can live without this fix in M60.

I think this is fairly serious and we should pick it up; if not for our first M60 promotion, at least a subsequent one.