mpegtsmux program number bug?

[Jesper Larsen]

There's actually already a bug with a proposed fix for this.

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

On Wed, Jun 10, 2015 at 8:24 AM, Jan Schmidt <thaytan at noraisin.net> wrote:

> On 09/06/15 21:24, Peter Maersk-Moller wrote:
>
> Hi Peter,
>
>  Forgot to mention. The supposedly program-number bug is tested with
>> GStreamer 1.4.5.
>>
>
> The restricted range of the program number field is a limitation of the
> way the MPEG-TS muxer is implemented - storing all programs in a fixed
> array of 32 entries. As you've noted, any request for a higher program
> number is ignored.
>
> I didn't realise any mapping uses explicit program numbers for anything
> specific, so I'm interested to hear you mention ATSC there. I've always
> thought of them as an arbitrary identifier that just has to be unique.
>
> If you have a real need for higher program numbers, it'll require some
> enhancement of the mpeg-ts muxer - a task that's arguably long overdue for
> other reasons too.
>
> - Jan.
>
>
>> best regards
>> Peter
>>
>> On Mon, Jun 8, 2015 at 3:41 AM, Peter Maersk-Moller <pmaersk at gmail.com
>> <mailto:pmaersk at gmail.com>> wrote:
>>
>>     Hi
>>
>>     When I try to set the program number for the mpegtsmux using the
>>     pipeline, it all works quite well until I try to set a program
>>     number above 31. Using a program number above 31, makes the mux set
>>     the program number to 1. It furthermore creates complications, if I
>>     have two streams and they both have a program number above 31. Then
>>     I only get one program with the number 1 possibly with both pes pids
>>     (not verified)
>>
>>     The pipelines used for test are these:
>>
>>     pid1=300
>>     pnum1=31
>>     # (works)
>>     pnum1=32
>>     # (program gets number 1)
>>
>>     gst-launch-1.0 videotestsrc is-live=1  !
>>     'video/x-raw,framerate=15/1' ! videoconvert ! x264enc speed-preset=2
>>     ! h264parse ! queue ! mux.sink_$pid1 mpegtsmux name=mux
>>     prog-map=program_map,sink_$pid1=$pnum1 ! chopmydata max-size=1316
>>     min-size=1316 ! udpsink host=127.0.0.1 port=10074
>>
>>     pid1=300
>>     pid2=301
>>     pnum1=32
>>     pnum2=33
>>     # both pid1 and pid2 are associated with program 1 and not 32 and 33
>>
>>     gst-launch-1.0 videotestsrc is-live=1  !
>>     'video/x-raw,framerate=15/1' ! videoconvert ! x264enc speed-preset=2
>>     ! queue ! tee name=t ! h264parse ! queue ! mux.sink_$pid1 mpegtsmux
>>     name=mux prog-map=program_map,sink_$pid1=$pnum1,sink_$pid2=$pnum2 !
>>     chopmydata max-size=1316 min-size=1316 ! tcpserversink
>>     host=127.0.0.1 port=10074 t. ! h264parse ! queue ! mux.sink_$pid2
>>
>>     pid1=300
>>     pid2=301
>>     pnum1=31 (works)
>>     pnum1=32 (program gets number 1)
>>
>>     As far as I can read in the standard, the 16 bit field for program
>>     number in the PAT packet and in the PMT packet allows for program
>>     number between 1-2^16-1 although ATSC reserves 2^16-1 for some
>>     analogue stuff.
>>
>>     So is this a bug?
>>
>>     Best regards
>>     Peter Maersk-Moller
>>
>>
>>
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>  _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150610/7f2f9e66/attachment-0001.html>