Investigate adding HLS support.

[ojw28]

[sdhr48]

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.

[OnlyInAmerica]

Registering my extreme interest in adding HLS support. @sdhr48 could you put your work online? I'd love to help!

[ojw28]

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?

[ojw28]

And yes, we are looking at this too. We'll provide an update when we have something to share!

[crossle]

Nice

[martinbonnin]

Hi !
I'm also very interested in HLS. We need that badly for our app so I started looking into it. Right now my plan is:

• focus on video-only first as HLS has audio/video interleaved inside chunks and it looks like it is not supported with the existing codebase.
• add HLSRendererBuilder, HLSChunkSource, TSMediaChunk, TSExtractor all in java and all for video-only.
• shoehorn audio support.
• test performance, possibly implement the TSExtractor in native code.
• add more features (live, multi-track audio, subtitles, etc...)

What do you think ?
My fork is at https://github.com/martinbonnin/ExoPlayer/commits/hls. It is 100% work in progress and it does not even compile but I don't want to duplicate effort so I figure out it is better to share progress. Please tell me if you believe what I'm doing is useful. If not, just tell me what could be more useful and I'll be happy to work on whatever can make this project move faster !

[4ntoine]

HLS support would be awesome

[akavrt]

Without HLS support ExoPlayer feels incomplete. Let's hope someday we will get it working!

[nachtien]

@martinbonnin, any luck on your implementation? I need this so bad for a project I am working on.

[martinbonnin]

@nachtien I'll post an update when I get stuff working.

@crossle I was a bit worried to add a big dependency such as ffmpeg requiring jni and stuff but I guess if it works it'll be more efficient than java.

[martinbonnin]

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 ?

[ojw28]

Aren't there timestamps in the manifest? If there weren't, then it would be impossible to implement seeking?

[martinbonnin]

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:

• the timestamps inside the TS might not start at offset 0.
• the chunk durations might be imprecise. I am not sure if this is a problem or not.

I'm going to try...

[ojw28]

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 :).