search

google / ExoPlayer

This project is deprecated and stale. The latest ExoPlayer code is available in https://github.com/androidx/media
https://developer.android.com/media/media3/exoplayer
Apache License 2.0
21.7k stars 6.02k forks source link

EOF exception comes while running DASH stream with TTML track #10713

Open atkGit opened 1 year ago

atkGit commented 1 year ago

ExoPlayer Version

2.17.1

Devices that reproduce the issue

NVDIA shield with Android 11

Devices that do not reproduce the issue

Not tested any other

Reproducible in the demo app?

No

Reproduction steps

Play the mpd , enable track selection parameters to select the text for eng and also enable the undefined language too

Expected result

Media should play successfully

Actual result

When exo player receives the first ttml segment -{mentioned as d1-1.m4s - in the log }, Following error is getting . video is not playing after the first frame . The segment data d1-1.m4s is uloaded in the 'media ' field below as ttmlDump_org.txt.

MPD is also uploaded in media (renamed as txt in the Media as the xml was not supported)

CM_HttpSendResponse(): Sending AV 1385 Segment Sent =[d1-1.m4s] 963 D NvOsDebugPrintf: NVMEDIA: FrameRate = 59 960 I ACodec : Get OMX_IndexConfigScale: 0x10000/0x10000 960 I ACodec : Scaled Width is 1920, height is 1080 859 E EventLogger: internalError [eventTime=3.74, mediaPos=0.00, window=0, period=0, loadError 859 E EventLogger: java.io.EOFException 859 E EventLogger: at com.google.android.exoplayer2.extractor.DefaultExtractorInput.readFromUpstream(DefaultExtractorInput.java:296) 859 E EventLogger: at com.google.android.exoplayer2.extractor.DefaultExtractorInput.skipFully(DefaultExtractorInput.java:107) 859 E EventLogger: at com.google.android.exoplayer2.extractor.DefaultExtractorInput.skipFully(DefaultExtractorInput.java:115) 859 E EventLogger: at com.google.android.exoplayer2.extractor.mp4.FragmentedMp4Extractor.readAtomPayload(FragmentedMp4Extractor.java:457 859 E EventLogger: at com.google.android.exoplayer2.extractor.mp4.FragmentedMp4Extractor.read(FragmentedMp4Extractor.java:336) 859 E EventLogger: at com.google.android.exoplayer2.source.chunk.BundledChunkExtractor.read(BundledChunkExtractor.java:153) 859 E EventLogger: at com.google.android.exoplayer2.source.chunk.ContainerMediaChunk.load(ContainerMediaChunk.java:127) 859 E EventLogger: at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:412) 859 E EventLogger: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) 859 E EventLogger: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) 859 E EventLogger: at java.lang.Thread.run(Thread.java:923) 859 E EventLogger: ]

Media

ttmlDump_org.txt mpd.txt

Bug Report

atkGit commented 1 year ago

Shared the bugreport by mail

tonihei commented 1 year ago

The segment data d1-1.m4s is uloaded in the 'media ' field below as ttmlDump_org.txt.

Are you saying the attached ttmlDump_org.txt is exactly the same as d1-1.m4s? The TTML data should be contained inside a fMP4 container according to your manifest. If it's just the raw TTML file, the player likely fails trying to parse it as fMP4 (that's what the error above may be).

If you want to load a standalone TTML file, the MIME type needs to be application/ttml+xml (with no codec string). See https://dashif-documents.azurewebsites.net/DASH-IF-IOP/master/DASH-IF-IOP.html#codecs-imsc1

atkGit commented 1 year ago

The segment data d1-1.m4s is uloaded in the 'media ' field below as ttmlDump_org.txt.

Are you saying the attached ttmlDump_org.txt is exactly the same as d1-1.m4s? The TTML data should be contained inside a fMP4 container according to your manifest. If it's just the raw TTML file, the player likely fails trying to parse it as fMP4 (that's what the error above may be).

If you want to load a standalone TTML file, the MIME type needs to be application/ttml+xml (with no codec string). See https://dashif-documents.azurewebsites.net/DASH-IF-IOP/master/DASH-IF-IOP.html#codecs-imsc1

Yes That was issue ..Thanks for the comment. The mp4 container was removed before giving to Exo player by our modules . Now with this container , this exception is gone and we are able to get the successive segment requests .

Now the segment parsing is happening properly itseems but no text is being displayed which we suspect is due to the time . The ttmlDump_org.txt uploaded above is manually edited one to make the begin start at time 00....to see if the text is displaying or not. The original ttml file without modification is attaching again as d1-1_ttmlData.xml. Do I need to open another question or issue to get some help on this ?

tonihei commented 1 year ago

The original ttml file without modification is attaching again as d1-1_ttmlData.xml

I can't see any attachment? In any case, it's worth reading through the specs again to verify the timestamps you set in the fMP4 container and in TTML are as required. If you think they are and we parse them wrongly, please reply here and we can investigate further.

atkGit commented 1 year ago

Hi Tonhei,

I was not able to attach the file . I will paste the contents below . Please note that the video plays in this case but no text is displayed . When I changed the high lighted content to 00 and tried sideloading this xml I could see the text displayed . This was done just to make sure that the ttml content is correct and is able to display. But when we are setting using the MPD and start normal dash stream playback , the requests for successive ttml segments are received in our local web server hosting the dash contents but no text is displayed .

            <body>
                            <div region="Region_955">
                                            <p begin="450909:05:49.098" end="450909:05:50.499">
                                                            <span style="Style_955">That will come in<br></br>under seventy thousand dollars.<br></br>
                                                            </span>
                                            </p>
                            </div>
                            <div region="Region_956">
                                            <p begin="450909:05:50.499" end="450909:05:51.100">
                                                            <span style="Style_955">OK, a lot of these<br></br>new electric vehicle<br></br>
                                                            </span>
                                            </p>
                            </div>
            </body>

Thanks Ambika

tonihei commented 1 year ago

@icbaker I couldn't quickly find a source for this, but do you happen to know if timestamps in chunked TTML files are relative to the chunk start time or absolute in the stream? Based on the observation here I'd guess they have to be relative to the chunk?

icbaker commented 1 year ago

Based on the observation here I'd guess they have to be relative to the chunk?

Not sure I agree, if I understand what's been tested and reported in https://github.com/google/ExoPlayer/issues/10713#issuecomment-1299937553:

When I changed the high lighted content to 00 and tried sideloading this xml I could see the text displayed

By sideloading I assume you mean using MediaItem.setSubtitleConfigurations as described here and then playing against an MP4 file or similar: https://exoplayer.dev/media-items.html#sideloading-subtitle-tracks

In that case what was observed sounds expected - the timestamps would need to start at 0.

However for playback in a DASH stream via manifest, it looks like the timestamps should match that of the media and not be relative to the start of the chunk (based on these examples): https://github.com/rbouqueau/TTML_in_MP4_DASH_statement/wiki/ebuttd_in_isobmff_samples

If you believe ExoPlayer is not parsing things correctly please provide a way for us to reproduce the problem in order to investigate further. That's probably a link to a served DASH stream we can play. Please either upload it here or send it to dev.exoplayer@gmail.com using the subject Issue #10713. Please also update this issue to indicate you’ve done this.

atkGit commented 1 year ago

Not able to attach the files here

atkGit commented 1 year ago

DashSamples.zip

atkGit commented 1 year ago

Dash sample files are added above. Please use the Sample.mpd file (same as the MPD attached above) for starting the play. These samples are from a captured file . the media time is 09 JUN 2021 21:05:52. With this time set in PC , we could see the video with ttml text using a gstreamer . Please help if some setting needs to be done in exo player to make playback with subtitles. Is there any way we can feed a time to Exo player ?

icbaker commented 1 year ago

Thanks for the content, I was able to play it in our demo app by doing two things:

  1. Change the device time to 2021-06-09 21:06 UTC
  2. Hack DashMediaSource to stop it from using an NTP-based time source and use local device time by changing this line: https://github.com/google/ExoPlayer/blob/ab4d37f499ba49bb3cac7938eb03ebf7133ccfe6/library/dash/src/main/java/com/google/android/exoplayer2/source/dash/DashMediaSource.java#L761-L763

To this:

public void onInitialized() {
  onUtcTimestampResolved(System.currentTimeMillis() - SystemClock.elapsedRealtime());
}

I enabled the subtitle track while the content was playing, and saw subtitles appear on the screen.

So it looks like everything is working for me. If you make the same changes to the demo app, do you also see the subtitles?

atkGit commented 1 year ago

Yes with the above change I am able to see the subtitle on screen. One disadvantage is for playing captured content , we need to set the system time to exact time at which the dash stream playback is captured. Is there any way we can set the a reference time (say MPD AST ) instead of taking the system time . We tried changing the Util getNowUnixTimeMs based on an externally set reference time .In this case time does not match and is not playing TTML content

icbaker commented 1 year ago

If you're trying to play live content long after it's aired it should probably be served as VOD content instead? The intricacies of content preparation is out of scope for this issue tracker, but that is generally how I would expect 'no longer live' content to be served.

(I thought you were only trying to override the time in order to test some live behaviour to reliably repro this issue - using actually-live streams for repro can be annoying because they keep changing!)