After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 722129 - mpegtsmux: alignment property does not work as expected for UDP streaming
mpegtsmux: alignment property does not work as expected for UDP streaming
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal major
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2014-01-13 20:02 UTC by pgharios
Modified: 2015-03-15 12:13 UTC
See Also:
GNOME target: ---
GNOME version: ---

Tried to fix to use alignment property (1.31 KB, patch)
2014-05-11 07:07 UTC, Hyunjun Ko
none Details | Review

Description pgharios 2014-01-13 20:02:52 UTC
gst-launch-1.0 videotestsrc ! video/x-raw,width=720,height=576,framerate=10/1 ! x264enc ! mpegtsmux alignment=7 ! fakesink silent=false

WARNING: from element /GstPipeline:pipeline0/GstUDPSink:udpsink0: Attempting to send a UDP packet larger than maximum size (106596 > 65507)

Comment 1 Tim-Philipp Müller 2014-01-13 20:36:15 UTC
Ah, so I think this is my bad really, the alignment property doesn't do what I thought it did, but actually does what is says on the tin. So if you say alignment=7 it will push a *multiple* of 1316 bytes, not exactly 7 packets / 1316 bytes.

You could just use chopmydata or rndbuffersize as workaround, but those probably don't preserve timestamps for syncinc on udpsink (but then you don't need those if you have a live source as input).
Comment 2 Hyunjun Ko 2014-05-11 07:07:17 UTC
Created attachment 276315 [details] [review]
Tried to fix to use alignment property

I just tried to fix to use alignment property. Could you review this?
Comment 3 Tim-Philipp Müller 2015-03-02 13:26:53 UTC
I think the alignment property does exactly what it's supposed to, just that it's not what most people want. It's also rather confusing because it takes a number in packets not bytes.

Looking at bug #651805 which introduced the property I think it does exactly what it was meant to do.

I think what we should do is either add a new "max-output-size" property or somesuch, or add an udpm2tpay element that does this.
Comment 4 Tim-Philipp Müller 2015-03-15 12:13:24 UTC
We decided to change the behaviour of the "alignment" property instead:

commit ab52bfbfa6ba80162204b0b7f89a03f70613423e
Author: Tim-Philipp Müller <>
Date:   Sun Mar 15 12:06:22 2015 +0000

    tests: mpegtsmux: add unit test for "alignment" property

commit 09c05df8896db8859483c3aa70228aab87b5047c
Author: Tim-Philipp Müller <>
Date:   Sat Mar 14 15:27:39 2015 +0000

    mpegtsmux: make "alignment" property more useful for packetisation
    Currently the alignment property just makes sure that we
    output things in multiples of align*packet_size bytes, but
    with no clear maximum size. When streaming MPEG-TS over
    UDP one wants buffers with a maximum packet size of 1316.
    The alignment property so far would just output buffers
    that are a multiple of 1316 then.
    Instead we now make the alignment property output
    individual buffers with the alignment size, which
    is entirely backwards compatible with the expected
    behaviour up until now. For efficiency reason
    collect all those buffers in a buffer list and
    send that downstream.
    Also collect data to push downstream in a buffer
    list from the adapter if we don't align things,
    which is still more efficient because of the
    silly way the muxer currently creates output