MPEG-TS
Locked
MPEG-TS
 
|
Hi,
Another question after "Why is there no gstreamer_mpegts_sys::GstMpegtsShortEventDescriptor struct definition in the Rust sys binding to GStreamer MPEG-TS library": Does anyone have any knowledge of what the text and items fields actually are in GstMpegtsExtendedEventDescriptor in the C implementation of the GStreamer MPEG-TS library are – and hence what they are in the Rust wrapper. The documentation at https://gstreamer.freedesktop.org/documentation/mpegts/gst-atsc-descriptor.html?gi-language=c#GstMpegtsExtendedEventDescriptor says nothing directly but refers to the standard EN 300 468 v.1.13.1 which says a lot but tells you nothing. I am trying to construct some test data but have no idea what the result should be! -- Russel. =========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
signature.asc (849 bytes)
Re: MPEG-TS
|
|
Section 6.2.15 of
https://www.etsi.org/deliver/etsi_en/300400_300499/300468/01.13.01_40/en_300468v011301o.pdf
does
get into some details on these two fields, basically items is a dictionary of metadata (eg: {"Producer": "Some Guy In Hollywood"}), and text is a simple string, could be the summary of the program, no example is provided for that field however. On 7/8/19 7:09 PM, Russel Winder wrote:
Hi, Another question after "Why is there no gstreamer_mpegts_sys::GstMpegtsShortEventDescriptor struct definition in the Rust sys binding to GStreamer MPEG-TS library": Does anyone have any knowledge of what the text and items fields actually are in GstMpegtsExtendedEventDescriptor in the C implementation of the GStreamer MPEG-TS library are – and hence what they are in the Rust wrapper. The documentation at https://gstreamer.freedesktop.org/documentation/mpegts/gst-atsc-descriptor.html?gi-language=c#GstMpegtsExtendedEventDescriptor says nothing directly but refers to the standard EN 300 468 v.1.13.1 which says a lot but tells you nothing. I am trying to construct some test data but have no idea what the result should be! _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: MPEG-TS
|
|
On Mon, 2019-07-08 at 19:27 +0200, Mathieu Duponchelle wrote:
> Section 6.2.15 of > https://www.etsi.org/deliver/etsi_en/300400_300499/300468/01.13.01_40/en_300468v011301o.pdf > does > get into some details on these two fields, basically items is a dictionary > of metadata > (eg: {"Producer": "Some Guy In Hollywood"}), and text is a simple string, > could be the summary of the program, no > example is provided for that field however. After having bashed my head against the documentation, I spotted the "this is a dictionary implemented in C" bit. To have your confirmation of this interpretation is most useful so thanks for that confirmation. I then found a "parsing the original byte sequence" example on the Web that shows that the text is just a partial text (implying the dictionary is potentially just a partial dictionary due to the fixed byte length of a packet) and that you have to process the full sequence of extended event descriptors to get the full text (and dictionary). Now I have to worry about how to do this, options being a state machine or making assumptions about the sequence of packets. My current problem is though whether fields of type *gchar are actually nul terminate C strings or not. I believe they should be but CStr::from_ptr is failing to terminate indicating they are not. This would seem bad design of the parsing in the library if it is the case. I cannot believe the parsing algorithm would be bad, that nul terminated string would not be what is there. So I am in a circle of frustration. :-( Of course this is all based on test data rather than actual real packets, I guess I should just get some real packets from Freeview and see what the result is. -- Russel. =========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: MPEG-TS
|
|
On Tue, 2019-07-09 at 11:20 +0100, Russel Winder wrote:
> […] > > My current problem is though whether fields of type *gchar are actually nul > terminate C strings or not. I believe they should be but CStr::from_ptr is > failing to terminate indicating they are not. This would seem bad design of > the parsing in the library if it is the case. I cannot believe the parsing > algorithm would be bad, that nul terminated string would not be what is > there. > So I am in a circle of frustration. :-( […] It seems that I was failing to do enough indirection, I added another level of indirection and it now all works as it should – oh the joys of *GPtrArray. So my test code now agrees with the GStreamer MPEG-TS library, which is good. :-) -- Russel. =========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: MPEG-TS
|
|
OK, not sure what the problem was exactly, but glad you fixed it :)
Also I just noted that the example in tests/examples/mpegts/ts-parser.c handles extended events, if you have reference data and time to spare it would be nice to add an actual unit test as well in tests/check/libs/mpegts.c :) On 7/9/19 2:18 PM, Russel Winder wrote:
On Tue, 2019-07-09 at 11:20 +0100, Russel Winder wrote:[…] My current problem is though whether fields of type *gchar are actually nul terminate C strings or not. I believe they should be but CStr::from_ptr is failing to terminate indicating they are not. This would seem bad design of the parsing in the library if it is the case. I cannot believe the parsing algorithm would be bad, that nul terminated string would not be what is there. So I am in a circle of frustration. :-([…] It seems that I was failing to do enough indirection, I added another level of indirection and it now all works as it should – oh the joys of *GPtrArray. So my test code now agrees with the GStreamer MPEG-TS library, which is good. :-) _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: MPEG-TS
|
|
Re: MPEG-TS
|
|
In reply to this post by Mathieu Duponchelle
On Tue, 2019-07-09 at 15:28 +0200, Mathieu Duponchelle wrote:
> OK, not sure what the problem was exactly, but glad you fixed it :) :-) > Also I just noted that the example in tests/examples/mpegts/ts-parser.c > handles extended events, > if you have reference data and time to spare it would be nice to add an > actual unit test as well > in tests/check/libs/mpegts.c :) That is part of the parser of byte sequences that creates instances of the structs. I am dealing with element messages off the GStreamer bus – all the parsing has already been done under the covers (not nowing this was my first failure!). -- Russel. =========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: MPEG-TS
|
|
In reply to this post by Tim-Philipp Müller-2
On Tue, 2019-07-09 at 14:32 +0100, Tim-Philipp Müller wrote:
> […] > I'm a bit lost what exactly you're talking about here now, but if you > find a gchar * in our API that is always a 0-terminated string, unless > explicitly indicated otherwise. If it was not, it would be a gchar > foo[3] or somesuch. No need to worry, I had assumed what you say was true, which is why I was confident the fault was in my code and test data! The things people responded on the email was all very helpful and got me to the answer. The difficulty for me is that the GStreamer structs are, in places, not quite what the standards talk about because they are talking about the unparsed byte sequences whereas GStreamer bus message elements are pre-parsed struct instances. So referring to the standard is often not helpful in the documentation for the structs. In the end the single biggest problem at the moment is that there appears to be no gstreamer_mpegts_sys::GstMpegtsShortEventDescriptor and I cannot work out why not. -- Russel. =========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
| Free forum by Nabble | Edit this page |