Can you elaborate on what is bad about the quality? Also are you using official Google CHrome? Those github links are not official.

I am not using Chrome. I compile Chromium source code myself.

GN build configuration is:
proprietary_codecs=true
ffmpeg_branding="Chrome"

Do you see issues with official Google Chrome? Sorry we don't provide support for custom builds. Can you detail what's bad about the quality though? If it's something that happens in official builds I can help out.

Even I use official build of Chromium (Version 69.0.3497.100) the issue is there. To reproduce the issue play live stream "iVysílání" on "https://www.ceskatelevize.cz/ivysilani".

Deleted: 889405_a.png 17.4 KB

	889405_a.png 17.4 KB View Download

Deleted: 889405_b.png 322 KB

	889405_b.png 322 KB View Download

Deleted: 889405_c.png 569 KB

	889405_c.png 569 KB View Download

That's still Chromium, can you try the official Google _Chrome_ build. I unfortunately can't play a lot of the content on that site and the content I can play works fine. Can you also provide the chrome://media-internals log for the player on that page? I wonder if you're actually getting h264.

Your issue is most likely related to https://bugs.chromium.org/p/chromium/issues/detail?id=879734 , incorrectly encoded content by Ceska Televize and recent change to decoding by PTS timestamps in Chrome 69 as I can confirm this to be an issue with official Chrome 69 as well when decoding by PTS is enabled and mind you, not all Chrome 69 users have this method currently enabled. The rollout to all users is supposed to be done in phases over subsequent Chrome 69 updates from what I remember.

Michal, can you confirm your instance using PTS decoding by starting the stream and going to chrome://media-internals/ in separate tab and looking for ChunkDemuxer: buffering by PTS in the last streaming session highlighted in blue?
If this is present, try to start your compiled Chrome by adding --enable-features=MseBufferByDts flag to shortcut startup parameters, which switches back to previous decoding method of using DTS timestamps instead.

If that helps, Chrome developers are seemingly preparing workaround for such incorrectly encoded content while decoding by PTS as per that mentioned issue above, so you simply need to wait for stable version 70 and then remove the startup flag.
That is also likely why dev version 71 is working for you.

Yeah 70+ should all have those fixes now. Stable shouldn't have this enabled at all; especially in Chromium builds since I don't think those pickup experiments.

I experience the same issue and I think it was introduced in this commit:
https://chromium.googlesource.com/chromium/src.git/+/04b4b465d879de468d3c2dbed32130926c2da0cd

And to me as a workaround worked just to turn it off with:
--disable-features=MseBufferByPts

Which is opposite of what is written in collapsi (#8) comment (if I understand it correctly). But it seems that in version 71 it is fixed and works with this switch on.

Both --enable-features=MseBufferByDts and --disable-features=MseBufferByPts should achieve the same result. Either way it is not using new decoding method based on PTS timestamps, it reverts to previous method based on DTS instead.

But yes, from semantical point of view, --disable-features=MseBufferByPts makes more sense.

My mistake I overlooked the difference Dts vs Pts (MseBufferByDts vs MseBufferByPts)

 michalvasek@Thanks for the issue..

Unable to reproduce the issue on reported chrome and chromium 69.0.3497.100 using Windows 10.Attaching screen-cast for reference.
Steps: 
---------
1. Launched reported chrome 
2. Navigated the URL ""https://www.ceskatelevize.cz/ivysilani"."
3. played some videos 
As we are observed that Video quality is not watchable.

@Reporter: Request you to retry this issue with fresh profile without any extensions  & apps or reset all the flags and let us know if issue still persists.

Thanks.!

Deleted: 889405.mp4 8.9 MB

	889405.mp4 8.9 MB View Download