GNOME Bugzilla – Bug 784254
rtp: vrawdepay: add support for 8-bit monochrome along with UK DEF STAN 00-82 compliant scan lines
Last modified: 2018-11-03 15:20:31 UTC
Created attachment 354575 [details] [review] Patch file including modified versions of rtpvrawdepay .c and .h modified rtpvrawdepay.c + .h to allow 8-bit monochrome sampling as per section 5 figure 12 in UK DEF STAN 00-82 Part 1 Issue 2. Also added scan line modification for DEF STAN 00-82 compliant feeds.
Thanks for the patch. Where in the spec are these custom sampling strings with the DEFSTAN prefix defined? Or did you just make those up for the automatic sample line offset?
figure 12 in section 5 (cant remember the page) has the sample 8 bit mono packet, the DEFSTAN prefix sampling strings are just for the offset as the video input stream is one line offset which was resulting in a green or black line at the top depending on what sampling was used. They should both just default to the GRAY8 and UYVY formats after applying the offset. Sorry for the late reply I got caught up in other work.
To Clarify on the line offset - DEF STAN 00-82 starts from line 1 and is based on BT656. This is discussed in section B.1.1 in both issue 1 and 2 of DEF STAN 00-82. RFC4175 starts from line 0 and if I'm right thats what g-streamer conforms to ? It might be an idea going forward to add a cap for the line spacing as I imagine I'm not the first to encounter this variation though the patch I have submitted will work for my purposes.
Created attachment 354699 [details] [review] rtpvrawpay, rtpvrawdepay: add "line-offset" property Craig, could you check if this patch works for you for the scan line offset adjustment? I don't think we want to add UK DefStan-specific sampling names upstream. Do you feel like updating your patch to just add the grayscale format without any of the other changes (unrelated fixups, scanline things, dstan formats)? I might have an existing patch somewhere that adds this as well - but I'd have to find it first, so up to you :) You call the grayscale sampling name in the caps GRAY8 in your patch, but according to the spec it should be GRAYSCALE, so I think we should probably go for that? Was the "GRAY8" based on the GStreamer video format name?
Ill get this tested today and get back to you hopefully today or monday. Yeah the GRAY8 was just based on some format I found online I'll get that changed to GRAYSCALE as I think I could do with adding support for 10, 12, 14 and 16 bit. Is the patch you're wanting just the GRAYSCALE changes then and nothing else then ?
> Is the patch you're wanting just the GRAYSCALE changes then > and nothing else then ? Yes. If you would like to propose additional changes like clean-ups or such, please put them into separate commits.
The line offset patch doesn't fix the issue as the packets being received do not believe they have an offset. The line number itself starts at 1 as opposed to 0. using warning messages I have output this to the command line. 0:00:03.925780801 23177 0x7f9540 WARN rtpvrawdepay gstrtpvrawdepay.c:398:gst_rtp_vraw_depay_process_packet:<rtpvrawdepay0> offset value 0 0:00:03.925787860 23177 0x7f9540 WARN rtpvrawdepay gstrtpvrawdepay.c:524:gst_rtp_vraw_depay_process_packet:<rtpvrawdepay0> skipping line 768: out of range 0:00:03.927379987 23177 0x7f9540 WARN rtpvrawdepay gstrtpvrawdepay.c:398:gst_rtp_vraw_depay_process_packet:<rtpvrawdepay0> offset value 0 0:00:03.927417099 23177 0x7f9540 WARN rtpvrawdepay gstrtpvrawdepay.c:502:gst_rtp_vraw_depay_process_packet:<rtpvrawdepay0> line number 1 0:00:03.927442795 23177 0x7f9540 WARN rtpvrawdepay gstrtpvrawdepay.c:398:gst_rtp_vraw_depay_process_packet:<rtpvrawdepay0> offset value 0 0:00:03.927454233 23177 0x7f9540 WARN rtpvrawdepay gstrtpvrawdepay.c:502:gst_rtp_vraw_depay_process_packet:<rtpvrawdepay0> line number 1 0:00:03.927475784 23177 0x7f9540 WARN rtpvrawdepay gstrtpvrawdepay.c:398:gst_rtp_vraw_depay_process_packet:<rtpvrawdepay0> offset value 0 using if (line < 2) GST_WARNING_OBJECT (depayload, "line number %u", line); and scan_line_offset = rtpvrawdepay->line_offset; GST_WARNING_OBJECT (depayload, "offset value %u", scan_line_offset); I think the best way to fix this is to check what line number the payload starts and go from there though I'm not sure how you feel about this as only BT656 video would have this issue.
Thanks for testing. I should add that I may have messed something up when I rewrote some parts of the original patch. Can you make available a short pcap or gdp file with a few frames by any chance?
Sure ill upload one now
Created attachment 354829 [details] pcap file with 60 packets theres 7 feeds on this connection 3 YCbCr and 4 8-bit grayscale all of which conform to the standard I mentioned earlier.
if you would like a larger file with complete frames let me know and ill get that to you.
Created attachment 354833 [details] [review] rtpvrawdepay: added GRAYSCALE support for 8 and 10 bit depth GRAYSCALE only patch for rtpvrawdepay
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/385.