mpegtsmux, high overhead for a small aac bitrate

[Vincent Génieux-2]

Hi all,

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


Do you have any idea on how I could reduce the bitrate of the ts stream
in my pipeline ?

--
vincent.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Vincent Génieux-2]

Le 18/05/2016 11:13, Vincent Génieux a écrit :
>
> 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 :
>

I am talking about the tsmuxer, not the demux, sorry for the mistake

> 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
>
>
> Do you have any idea on how I could reduce the bitrate of the ts
> stream in my pipeline ?
>

--
vincent.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Mi, 2016-05-18 at 11:13 +0200, Vincent Génieux wrote:

> Hi all,
>
> 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
>
>
> Do you have any idea on how I could reduce the bitrate of the ts stream 
> in my pipeline ?

Can you file a bug about this at
  https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer
?

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.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Vincent Génieux-2]

Le 18/05/2016 14:26, Sebastian Dröge a écrit :
> Can you file a bug about this at
>   https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer
> ?
>
> 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.

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

I am going to work on a patch, do you have any advice for resolving this
issue ?

--
vincent.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Baby Octopus]

I enc ountered this issue a while ago. Found the issue to be due to padding bytes at the end of each access units. You need to introduce some buffering logic inside the muxer by holding the last packet of each AU and combining it with first packet of next AU. Also, its quite possible for low bitrate audio that you'll have more than 2AUs in the same packet :)

[Sebastian Dröge-3]

On Mi, 2016-05-18 at 20:09 +0200, Vincent Génieux wrote:

> Le 18/05/2016 14:26, Sebastian Dröge a écrit :
> >
> > Can you file a bug about this at
> >   https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer
> > ?
> >
> > 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.
> https://bugzilla.gnome.org/show_bug.cgi?id=766618
>
> I am going to work on a patch, do you have any advice for resolving
> this issue ?

I would recommend looking at the ffmpeg MPEG-TS muxer and trying to map
their heuristics when to merge multiple ES packets into one PES packet
with our muxer.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Vincent Génieux-2]

Le 19/05/2016 05:48, Baby Octopus a écrit :
> I enc ountered this issue a while ago. Found the issue to be due to padding
> bytes at the end of each access units. You need to introduce some buffering
> logic inside the muxer by holding the last packet of each AU and combining
> it with first packet of next AU. Also, its quite possible for low bitrate
> audio that you'll have more than 2AUs in the same packet :)
>

okay, thank you for the advices, I will also check what is done in ffmpeg.

--
vincent.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel