mpegtsmux program number bug?

[Jesper Larsen]

gst/mpegtsmux/mpegtsmux.h has a define that limits the program number value
#define MAX_PROG_NUMBER 32

Each program has a TsMuxProgram struct associated, and an array of
MAX_PROG_NUMBER is allocated in the MpegTsMux struct. I don't know if the
limitation has any other cause than the allocation of that array though.

If you run the pipeline with GST_DEBUG=mpegtsmux:5 you get this message
mpegtsmux mpegtsmux.c:730:mpegtsmux_create_streams:<mux> Program number 32
associate with pad sink_200 out of range (max = 32); DEFAULT_PROGRAM = 0 is
used instead

If you need the possibility of using program numbers above 31, you can open
an enhancement bug.

Best Regards
Jesper

On Tue, Jun 9, 2015 at 1:24 PM, Peter Maersk-Moller <pmaersk at gmail.com>
wrote:

> Forgot to mention. The supposedly program-number bug is tested with
> GStreamer 1.4.5.
>
> best regards
> Peter
>
> On Mon, Jun 8, 2015 at 3:41 AM, Peter Maersk-Moller <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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150610/462e997c/attachment.html>