20

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?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Robert
  • 37,670
  • 37
  • 171
  • 213
  • It seams there was a few bugs in FFMPEG. A colleague fixed the issue manually in the source and this reduced the muxing overhead significantly (Apple's `mediastreamsegmenter` tools are still better tho). – Robert Jun 07 '13 at 15:12
  • I have a similar issue, I've opened a bug in ffmpeg database https://ffmpeg.org/trac/ffmpeg/ticket/2857 you can upvote it. I'm also considering offering a bounty on this issue – Aviad Rozenhek Aug 13 '13 at 11:15
  • If your stream is audio only you don't need to mux it into a mpeg ts stream. You can leave it in aac and it will still work with HLS. – Robert Aug 20 '13 at 09:18
  • love the diagram, what tool did you use to create it? – fishfood Aug 26 '13 at 12:34
  • @fishfood - Preview on Mac - I screen-shoted a white area and drew text and rectangles over the top. Very low tech :) – Robert Aug 26 '13 at 14:21

2 Answers2

2

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

vbence
  • 20,084
  • 9
  • 69
  • 118
1

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.

mikaraento
  • 1,689
  • 14
  • 12