mpegtsmux program number bug?

Jan Schmidt thaytan at noraisin.net
Tue Jun 9 23:24:15 PDT 2015


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
>


More information about the gstreamer-devel mailing list