CODEWITHSUNDEEP
audiovideoffmpeghttp-live-streamingtransport-stream
Robert
Robert

Reputation: 38213

How do I alter my FFMPEG command to make my HTTP Live Streams more efficient?

I want to reduce the muxing overhead when creating .ts files using FFMPEG.

Im using FFMPEG to create a series of transport stream files used for HTTP live streaming. 

./ffmpeg -i myInputFile.ismv \
         -vcodec copy \
         -acodec copy \
         -bsf h264_mp4toannexb \
         -map 0 \
         -f segment \
         -segment_time 10\
         -segment_list_size 999999 \
         -segment_list output/myVarientPlaylist.m3u8 \
         -segment_format mpegts \
         output/myAudioVideoFile-%04d.ts

My input is in ismv format and contains a video and audio stream:

Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 320x240, 348 kb/s, 29.97 tbr, 10000k tbn, 59.94 tbc
Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 63 kb/s

There is an issues related to muxing that is causing a large amout of overhead to be added to the streams. This is how the issue was described to me for the audio:

enter image description here

So for a given aac stream, the overhead will be 88% (since 200 bytes will map to 2 x 188 byte packets).

For video, the iframe packets are quite large, so they translate nicely into .ts packets, however, the diffs can be as small as an audio packet, therefore they suffer from the same issue.

The solution is to combine several aac packets into one larger stream before packaging them into .ts. Is this possible out of the box with FFMPEG?

Upvotes: 20

Views: 3391

Answers (2)

mikaraento
mikaraento

Reputation: 1714

I've fixed the worst problem of syncing the TS output on each frame in http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=75c8d7c2b4972f6ba2cef605949f57322f7c0361 - please try a version after that.

Upvotes: 1

vbence
vbence

Reputation: 20333

It is not possible. Codecs rely on the encapsulating container for framing, which means to signal the start and length of a frame.

Your graphic actually misses an element, which is the PES packet. Your audio frame will be put into a PES packet first (which indicates its length), then the PES packet will be cut into smaller chunks which will be TS packets.

By design you can not start a new PES packet (containing an audio frame in your case) in a TS packet which already contains data. A new PES packet will always start in a new TS packet. Otherwise it would be impossible to start playing mid-stream (broadcast sitation) - it would be impossible to know on which byte in the TS the new PES begins (remember you have missed the beginning of the current PES).

There are some mitigating factors, the FF FF FF padding will probably be compressed by the networking hardware. Also if you are using HTTP (instead of UDP or RDP), gzip compression can be enabled (but I doubt it would help much).

Upvotes: 2

Related Questions