[Bug 766618] New: mpegtsmux, high overhead for a small aac bitrate

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=766618

            Bug ID: 766618
           Summary: mpegtsmux, high overhead for a small aac bitrate
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: vincent.genieux at startigen.fr
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

I am facing an issue with the following pipeline :

audiotestsrc num-buffers=100000 ! audio/x-raw,channels=2 !  voaacenc 
bitrate=32000 ! mpegtsmux ! filesink location=test.ts

The tsdemux generate a stream with a huge bitrate compared to other 
containers, such as mp4mux :

audiotestsrc num-buffers=100000 ! audio/x-raw,channels=2 !  voaacenc 
bitrate=32000 ! mp4mux ! filesink location=test.mp4

$ ls -lh test.*
-rw-r--r-- 1 vincent vincent 9.6M May 18 10:56 test.mp4
-rw-r--r-- 1 vincent vincent  26M May 18 10:57 test.ts

I think there is a misconfiguration somewhere which leads the demux to 
create very small chunk with many headers. I also noticed we can reduce 
the size of the ts file with libav :

$ avconv -i test.ts -codec copy test2.ts
$ ls -lh *.ts
-rw-r--r-- 1 vincent vincent  26M May 18 10:57 test.ts
-rw-r--r-- 1 vincent vincent 9.8M May 18 11:03 test2.ts


The problem is most likely that we don't combine multiple AAC packets
into a single PES packet, and thus have a lot of overhead for each of
them. ffmpeg does this for audio at least if I remember the muxer code
correctly.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.