3 ms·

Why should you have to encode twice for HLS and RTMP? The only reason to encode twice or more would be if you wish to have different movie properties (i.e. bit

by jgh 12y ago

Why should you have to encode twice for HLS and RTMP? The only reason to encode twice or more would be if you wish to have different movie properties (i.e. bitrate, fps, resolution, etc) For example, for h.264, once you get the NAL units from the encoder (which in the case of iOS is a chip provided by PowerVR) you can encapsulate them in whatever format you need...mpeg-ts, MP4, RTMP, RTP, it doesn't matter... I only support one simultaneous encode in my SDK, and I'm not actually sure how many the hardware would support as an upper limit.

chrisballinger 12y ago
I've done simultaneous hardware encoding before (two 640x480 videos) but I haven't pushed the boundaries yet. I have a hunch that newer phones might be able to do a few bitrates at the same time, but at that point we will do re-encoding server side because end users will have more limited upload bandwidth than our servers.
- jgh 12y ago
  Interesting... I should do an experiment to see how many encodes I can do at once and what ends up happening.
lucasgonze 12y ago
jgh, it's a completely different stack for HLS publishing vs. Flash. Different media, different upstreams, different endpoints. Looks at any encoding/pushing tools. It's possible to perform a single encode per bitrate, then split it between Flash and HLS on the server side, but then again that already exists in the form of cloud-based transcoders. It's also possible to take that single encode - h.264, for example - and wrap it twice, once for MP4 and once for HLS, but that would be software, which is CPU intensive. If it's in software, it's not in hardware.
- jgh 12y ago
  You don't need to do that though. The container or packet format is completely independent from the encoder format and they're all fairly simple, so packetizing compressed audio and video data and sending multiple streams, while not ideal due to bandwidth concerns, is most definitely not limited by CPU resources.

by jgh 12y ago

chrisballinger 12y ago

I've done simultaneous hardware encoding before (two 640x480 videos) but I haven't pushed the boundaries yet. I have a hunch that newer phones might be able to do a few bitrates at the same time, but at that point we will do re-encoding server side because end users will have more limited upload bandwidth than our servers.

jgh 12y ago
Interesting... I should do an experiment to see how many encodes I can do at once and what ends up happening.

lucasgonze 12y ago

jgh, it's a completely different stack for HLS publishing vs. Flash. Different media, different upstreams, different endpoints. Looks at any encoding/pushing tools. It's possible to perform a single encode per bitrate, then split it between Flash and HLS on the server side, but then again that already exists in the form of cloud-based transcoders. It's also possible to take that single encode - h.264, for example - and wrap it twice, once for MP4 and once for HLS, but that would be software, which is CPU intensive. If it's in software, it's not in hardware.

jgh 12y ago
You don't need to do that though. The container or packet format is completely independent from the encoder format and they're all fairly simple, so packetizing compressed audio and video data and sending multiple streams, while not ideal due to bandwidth concerns, is most definitely not limited by CPU resources.