-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate adding HLS support. #3
Comments
Heyy I was trying to implement HLS(AAC) support on top of the ExoPlayer implementation and then I realized you are also investigating this. So here is my implementation so far. I have a HLSRendererBuilder and I am creating a HLSAacChunkSource that will have the audio and video representations for different bandwidths. In my case I am interested only in Audio. So this will have only one representation. And the major part I feel is the extractor. (AacChunkExtractor). So it would be great if you can let me know if I am going in the right direction. |
Registering my extreme interest in adding HLS support. @sdhr48 could you put your work online? I'd love to help! |
That sounds about right, except the extractor should be called something like Mpeg2Extractor, since I think it would be extracting from the MPEG-2 transport stream? |
And yes, we are looking at this too. We'll provide an update when we have something to share! |
Nice |
Hi !
What do you think ? |
HLS support would be awesome |
Without HLS support ExoPlayer feels incomplete. Let's hope someday we will get it working! |
@martinbonnin, any luck on your implementation? I need this so bad for a project I am working on. |
ok so now I can have some video rendered except that the stream pauses/rebuffers all the time. It looks like it's coming from chunk.startTimeUs and endTimeUs that I hardcoded to 0 for now. Problem is HLS is not like smoothstreaming and I cannot know the timestamps before parsing the TS file. @ojw28 : any idea how to circumvent this ? |
Aren't there timestamps in the manifest? If there weren't, then it would be impossible to implement seeking? |
HLS has no real 'manifest'. It has 'playlists' with the duration of each chunk in the EXTINF tag so I could use that to guess the timestamps but I am not 100% convinced because:
I'm going to try... |
Yeah. Playlists fundamentally must contain timestamps (or durations from which timestamps can be derived) for seeking to be possible. The timestamps must also not drift as you get further down the list, otherwise seeking would become inaccurate the further down the playlist you get. If there needs to be some timestamp adjustment to the sample timestamps themselves, something similar to sampleOffsetUs in Mp4MediaChunk might do the trick, depending on what exactly is required. I'm hoping to get more up to speed with HLS in the next few weeks, and will be able to provide a slightly more informed opinion as opposed to random thoughts :). |
Ok so at first sight this seems to work but actually the incessant rebuffering problem was somewhere else. It was due to the fact that my TSMediaChunk.read() could return false (if reading an audio sample while a video one is expected for an example). In that case, the renderer stops feeding its input buffers and exoplayer believes it needs to rebuffer. To workaround that, I now discard audio completely but this is not a long-term solution... |
+1 for HLS support. |
@martinbonnin, awesome work so far!! Do you have an ETA for when think you'll have this done? |
@nachtien do you have a test url ? |
@martinbonnin -- It actually gets through the preparing phase, but then jumps to idle. It looks like it is throwing an index out of bounds exception on the getTrackInfo method. I tracked the issue down to the MainPlaylist file lines 55-69 (parse method). The m3u8 file we have has EXTINF:5.0 or 4.0 above every url, so its not loading anything in the playlist. Here is the URL we are using: https://api.beatgasm.com/v1/play/4301.m3u8?type=user&type_id=2190&bitrate=64000&X-Auth-Token=d4328aa4-46e2-452f-90f5-8228dd22a54c Thank you! |
@martinbonnin, I saw the changes you committed today. So awesome. Please let know if you want help with this... If you really think this is possible to get the audio from the URL I attached above to start streaming in under 3 seconds, I could probably dedicate some time to help or allocate some other resources to help. |
@nachtien I must admit I do not focus on audio-only right now as I want our own streams to play first. I gave a quick look at your url and I see at least 3 things missing to playback your stream:
As I am still digging and messing with the source code, I have no real ETA yet. Maybe somewhere next week... If you could think of a nice way to implement AES decryption, that'll definitely be useful ! |
Thanks! I'll see what I can do. |
@nachtien I can now have audio-only working on my hls branch (https://github.com/martinbonnin/ExoPlayer/tree/hls). Making your stream play should not be very difficult from there. It's basically missing AES decryption. But your url seems offline. Can you put it back online or post a new one ? Thanks, |
This is great progress, thanks everyone. As an aside to the earlier seeking discussion here, the Android issue discussed here is causing us a lot of headaches: https://groups.google.com/forum/#!topic/android-developers/JZ9bd5FpsSQ. We (JW Player) have customers who really need granular video seeking (accurate to the second) in HLS, but this segment boundary seeking limitation has left us stuck. @ojw28, it feasible that ExoPlayer w/ HLS could work around it? Thanks-- |
@martinbonnin, wow, thank you so much for getting this done. We were close to purchasing alternatives and this might really save us some serious time. The URL above still works (I just opened it up in quicktime). https://api.beatgasm.com/v1/play/4301.m3u8?type=user&type_id=2190&bitrate=64000&X-Auth-Token=d4328aa4-46e2-452f-90f5-8228dd22a54c. |
Ah, right. It is strange it does not work with 'curl' or 'wget' but opening it with Chrome is OK. Sorry for the false alarm. |
@nachtien I could decrypt the AES stream but then, the audio codec inside is MPEG AUDIO, which is unfortunately not supported at the moment (only AAC is). I'll take a look see if this is easy to add... |
Hey @martinbonnin, we want to send you a gift card or something if you get this working for us. Can you email me? Nachtien at gmail. |
@nachtien got it working :). It should work (tm) if you take the tip of my hls branch (https://github.com/martinbonnin/ExoPlayer/commits/hls) and you should be able to listen to the techno track under the 'Audio only - AES' item. Not sure if this qualifies for a gift though as seeking is not implemented yet and also it's only tested on my nexus5 so far. I'll email you some details. |
@ojw28 I reproduce this many times, when i playback |
You need to provide more information for us to be able to investigate. Which url specifically, so that we can try it ourselves? After how long does the problem occur, on which device? If possible, please also provide a full bugreport captured shortly after the problem is encountered (adb bugreport). Thanks! |
@ojw28 You can try http://itv08.digizuite.dk/tv2b/ngrp:ch1_all/chunklist-b1089536.m3u8?wowzasessionid=1128324428 live streaming, I used Nexus 5, Android 4.4.4, OOM problem not occur, OOM only occur on Samsung i9100. but it can't playback when player buffering a time, it buffering...all the time。 |
@ojw28 I found the buffering error, when buffering ExoPlayer/library/src/main/java/com/google/android/exoplayer/ExoPlayerImplInternal.java Line 336 in 79c2f53
getBufferedPositionUs always return max value, so buffering all the time. see the print log, you can reproduce the problem use http://www.twitch.tv/ home HLS live stream.
|
- The HlsSampleSource now owns the extractor. TsChunk is more or less dumb. The previous model was weird, because you'd end up "reading" samples from TsChunk objects that were actually parsed from the previous chunk (due to the way the extractor was shared and maintained internal queues). - Split out consuming and reading in the extractor. - Make it so we consume 5s ahead. This is a window we allow for uneven interleaving, whilst preventing huge read-ahead (e.g. in the case of sparse ID3 samples). - Avoid flushing the extractor for a discontinuity until it has been fully drained of previously parsed samples. This avoids skipping media shortly before discontinuities. - Also made start-up faster by avoiding double-loading the first segment. Issue: #3
We have implemented the main HLS stack with all the features we have originally targeted. I'm closing this issue. If you'd like to discuss a bug, missing feature, or any idea/suggestion, please open a separate specific issue. |
@AndroidNoob Do you have any sample streams for HLS containing MP3? |
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=124713796
No description provided.
The text was updated successfully, but these errors were encountered: