.TS streams never start

[ebr11]

Certain .ts streams (the ones we have are European TV) will appear to start to load in Exo but simply never start playing. If the same stream is re-encoded as h264 and delivered via HLS it will play fine.

Samples:

https://drive.google.com/open?id=1oe4oX9W4JherAWEQ-pAyT_7pkfJxDBOB
https://drive.google.com/open?id=1lTmpEecci5KHiVEHhhgb_LQ1E574-nPB

[AquilesCanta]

This issue is being closed because it does not adhere to our issue template, and/or because it omits information requested in the issue template that is required for us to investigate the problem efficiently. The issue template can be found here.

If you’re able to provide complete information as requested in the issue template, please do so below and we’ll re-open the issue. Thanks!

[ebr11]

Issue description

Certain .ts streams (the ones we have are European TV) will appear to start to load in Exo but simply never start playing. If the same stream is re-encoded as h264 and delivered via HLS it will play fine.

Reproduction steps

Attempt to play one of the included links in ExoPlayer

Link to test content

https://drive.google.com/open?id=1oe4oX9W4JherAWEQ-pAyT_7pkfJxDBOB
https://drive.google.com/open?id=1lTmpEecci5KHiVEHhhgb_LQ1E574-nPB

Version of ExoPlayer being used

2.8.4

Device(s) and version(s) of Android being used

Has happened on every device we've tried all running Android TV anywhere from version 5.1.1 to 8.0. Devices include Nexus Player, Nvidia Shield TV, MiBox 3.

[AquilesCanta]

Still missing the bugreport.

[ebr11]

My device is failing to create one right now so I'll have to get back to you. Just FYI no errors are thrown. Playback simply never starts. Thanks.

[ebr11]

I did also just discover that, if I let the demo app sit long enough trying to load the stream, it does eventually throw an out of memory error.

09-24 15:59:09.454 6019-6069/com.google.android.exoplayer2.demo E/LoadTask: OutOfMemory error loading stream java.lang.OutOfMemoryError: Failed to allocate a 65552 byte allocation with 61248 free bytes and 59KB until OOM, max allowed footprint 182452224, growth limit 182452224 at com.google.android.exoplayer2.upstream.DefaultAllocator.allocate(DefaultAllocator.java:102) at com.google.android.exoplayer2.source.SampleQueue.preAppend(SampleQueue.java:622) at com.google.android.exoplayer2.source.SampleQueue.sampleData(SampleQueue.java:562) at com.google.android.exoplayer2.extractor.ts.H264Reader.consume(H264Reader.java:114) at com.google.android.exoplayer2.extractor.ts.PesReader.consume(PesReader.java:134) at com.google.android.exoplayer2.extractor.ts.TsExtractor.read(TsExtractor.java:304) at com.google.android.exoplayer2.source.ExtractorMediaPeriod$ExtractingLoadable.load(ExtractorMediaPeriod.java:856) at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:320) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636) at java.lang.Thread.run(Thread.java:764) 09-24 15:59:09.457 6019-6019/com.google.android.exoplayer2.demo E/EventLogger: internalError [48.11, 0.00, window=0, period=0, loadError] com.google.android.exoplayer2.upstream.Loader$UnexpectedLoaderException: Unexpected OutOfMemoryError: Failed to allocate a 65552 byte allocation with 61248 free bytes and 59KB until OOM, max allowed footprint 182452224, growth limit 182452224 at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:350) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636) at java.lang.Thread.run(Thread.java:764) Caused by: java.lang.OutOfMemoryError: Failed to allocate a 65552 byte allocation with 61248 free bytes and 59KB until OOM, max allowed footprint 182452224, growth limit 182452224 at com.google.android.exoplayer2.upstream.DefaultAllocator.allocate(DefaultAllocator.java:102) at com.google.android.exoplayer2.source.SampleQueue.preAppend(SampleQueue.java:622) at com.google.android.exoplayer2.source.SampleQueue.sampleData(SampleQueue.java:562) at com.google.android.exoplayer2.extractor.ts.H264Reader.consume(H264Reader.java:114) at com.google.android.exoplayer2.extractor.ts.PesReader.consume(PesReader.java:134) at com.google.android.exoplayer2.extractor.ts.TsExtractor.read(TsExtractor.java:304) at com.google.android.exoplayer2.source.ExtractorMediaPeriod$ExtractingLoadable.load(ExtractorMediaPeriod.java:856) at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:320) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)  at java.lang.Thread.run(Thread.java:764) 

[AquilesCanta]

So I have just noticed that the two files use two different codecs. In the first case, it's possible that some of the devices don't have the required codecs. This can be confirmed by providing a full bugreport after playing the file in the demo app. For the second one, it's likely you'll find the answer in the FAQ.

[ebr11]

What are you seeing that is different? As far as I can tell they are both H264 High profile with AC3 audio (both of which are supported by the device).

[ebr11]

Also, the player reports seeing those codecs and that they are supported.

09-24 15:58:22.637 6019-6019/com.google.android.exoplayer2.demo D/EventLogger: tracksChanged [1.29, 0.00, window=0, period=0, 09-24 15:58:22.637 6019-6019/com.google.android.exoplayer2.demo D/EventLogger: Renderer:0 [ 09-24 15:58:22.637 6019-6019/com.google.android.exoplayer2.demo D/EventLogger: Group:0, adaptive_supported=N/A [ 09-24 15:58:22.662 6019-6019/com.google.android.exoplayer2.demo D/EventLogger: [X] Track:0, id=10355/6551, mimeType=video/avc, res=1280x720, supported=YES 09-24 15:58:22.662 6019-6019/com.google.android.exoplayer2.demo D/EventLogger: ] 09-24 15:58:22.662 6019-6019/com.google.android.exoplayer2.demo D/EventLogger: ] 09-24 15:58:22.662 6019-6019/com.google.android.exoplayer2.demo D/EventLogger: Renderer:1 [ 09-24 15:58:22.662 6019-6019/com.google.android.exoplayer2.demo D/EventLogger: Group:0, adaptive_supported=N/A [ 09-24 15:58:22.662 6019-6019/com.google.android.exoplayer2.demo D/EventLogger: [X] Track:0, id=10355/6552, mimeType=audio/ac3, channels=2, sample_rate=48000, language=deu, supported=YES 09-24 15:58:22.663 6019-6019/com.google.android.exoplayer2.demo D/EventLogger: ] 09-24 15:58:22.663 6019-6019/com.google.android.exoplayer2.demo D/EventLogger: Group:1, adaptive_supported=N/A [ 09-24 15:58:22.663 6019-6019/com.google.android.exoplayer2.demo D/EventLogger: [ ] Track:0, id=10355/6553, mimeType=audio/ac3, channels=2, sample_rate=48000, language=mis, supported=YES 09-24 15:58:22.663 6019-6019/com.google.android.exoplayer2.demo D/EventLogger: ] 09-24 15:58:22.663 6019-6019/com.google.android.exoplayer2.demo D/EventLogger: ] 09-24 15:58:22.663 6019-6019/com.google.android.exoplayer2.demo D/EventLogger: Renderer:2 [ 09-24 15:58:22.663 6019-6019/com.google.android.exoplayer2.demo D/EventLogger: Group:0, adaptive_supported=N/A [ 09-24 15:58:22.663 6019-6019/com.google.android.exoplayer2.demo D/EventLogger: [ ] Track:0, id=10355/14743, mimeType=application/cea-608, supported=YES 09-24 15:58:22.663 6019-6019/com.google.android.exoplayer2.demo D/EventLogger: ] 09-24 15:58:22.663 6019-6019/com.google.android.exoplayer2.demo D/EventLogger: ] 09-24 15:58:22.663 6019-6019/com.google.android.exoplayer2.demo D/EventLogger: ]

Sorry I cannot supply the full bug file you are requesting. My device is failing to create it (actually failing to create the zip) at this time so I'm trying to provide as much other information as I can.

Thanks.

[AquilesCanta]

I think the first one is h.262. For the second one, have you read the FAQ as suggested above?

[ebr11]

What is indicating the first one is mpeg2 to you? This is the output from Exo for that video track:

[X] Track:0, id=10355/6551, mimeType=video/avc, res=1280x720, supported=YES

As for the FAQ, yes I've read it but can you please be more specific as to exactly what you are referring?

Also, are you saying the above behavior (just hanging until an OOM error is thrown) would be an indication of an unsupported format? In my experience, that is not what happens in that case. Exo usually throws a nice exception saying it cannot find an extractor for the format.

Thanks.

[puenktchen]

The first link is false - the 576i file plays flawlessly. The link schould be https://drive.google.com/file/d/1qrpRSzZwf3SXxOVRelIOsxr7KsKrX11O/view?usp=drivesdk

[ebr11]

My apologies. I must have copied the incorrect link. Thanks, puenktchen.

[puenktchen]

@ebr11 i guess @AquilesCanta wants to know if you've already tried this:

Why do some MPEG-TS files fail to play?
Some MPEG-TS files do not contain access unit delimiters (AUDs). By default ExoPlayer relies on AUDs to cheaply detect frame boundaries. Similarly, some MPEG-TS files do not contain IDR keyframes. By default these are the only type of keyframes considered by ExoPlayer.

ExoPlayer will appear to be stuck in the buffering state when asked to play an MPEG-TS file that lacks AUDs or IDR keyframes. If you need to play such files, you can do so using FLAG_DETECT_ACCESS_UNITS and FLAG_ALLOW_NON_IDR_KEYFRAMES respectively. These flags can be set on a DefaultExtractorsFactory using setTsExtractorFlags. Use of FLAG_DETECT_ACCESS_UNITS has no side effects other than being computationally expensive relative to AUD based frame boundary detection. Use of FLAG_ALLOW_NON_IDR_KEYFRAMES may result in temporary visual corruption at the start of playback and immediately after seeks when playing some MPEG-TS files.

[ebr11]

Thanks for ferreting that out. I wonder how we're going to know one of those is the case and which one it is...

[puenktchen]

Only by try and error.
First start with FLAG_DETECT_ACCESS_UNITS because it doesn't lead to visual corruption. If it works okay with both problematic files, put out a new beta version of the so other european users can test it.
If it doesn't work for you, then try FLAG_ALLOW_NON_IDR_KEYFRAMES. Again if it's okay for you, put out a new beta app.
If you get mixed results from your own testing and your beta users, then then just try both flags.
If nothing works, then report it here.

[ebr11]

Yeah, I understand. My point is that all streams may not be like our samples and some may be one and others the other so we need a way for the app to figure it out (or know) on its own.

Anyway, we can take this discussion to our forums.

[AquilesCanta]

We have a pending line of work to automatically solve this issue. We suspect streams like these include metadata (typically SEI messages) which signals IDR-like behavior, which could be used to replace the FLAG_ALLOW_NON_IDR flag. We haven't manage to allocate time for this though. So, if you have time to do it, feel free to contribute. Either with a pull request, or with information to direct the investigation. Thanks @puenktchen, by the way.

[ebr11]

Thanks AquilesCanta.

[ebr11]

One more question if you don't mind... Is there any way to set these flags on an DefaultHlsExtractorsFactory? I can't seem to find one.

We are delivering these TS streams via HLS in order to seek them.

[AquilesCanta]

For the time being, you'll need to provide your own HlsExtractorFactory implementation, probably forking the existing one. Soon we will push a convenience constructor for adding these flags to the default implementation.

[ebr11]

Okay, will do. Thanks again.

[AquilesCanta]

Let me know if you run into any issues with this.