gst-plugins-bad: avtp: error on gst_avtp_src_start:<avtpsrc0> Failed to open socket: Operation not permitted

Fri Jul 17 17:09:07 UTC 2020

On Fri, 2020-07-17 at 09:37 -0400, John Rama wrote:
> Thanks Desouza
> 
> > From the log, it appears that no avtp packet arrives with M bit set, so
> > avtpcvfdepay keeps just accumulating nal units.
> > Can you ensure that what is generating the stream is properly setting
> > the M bit on the last access unit ("packet of a frame")? Wireshark can
> > be of help here.
> > 
> 
> Confirmed the cvf stream generated by talker has no "M bit" set at all.
> So, this is a reason. thank you so much for your help for me to reach this conclusion !!
> 
> 
> Now question is does talker really need to set M bit ?

Well, IEEE 1722-2016, Annex F (Protocol Implementation Conformance
Statement), Table F.12, Item H.264-4 says that, *yes*, the talker
really need to set the M bit...

> 
> IEEE1722 section "8.5.2.4 M field" says 
> > The M field shall be set according to RFC6184, Section 5.1.
> 
> And RFC6184, Section 5.1 says 
> https://tools.ietf.org/html/rfc6184
> 
> > Marker bit (M): 1 bit
> > Set for the very last packet of the access unit indicated by the
> > RTP timestamp, in line with the normal use of the M bit in video
> > formats, to allow an efficient playout buffer handling.
> >  Decoders MAY use this bit as
> >  an early indication of the last packet of an access unit but MUST
> >  NOT rely on this property.
> 
> So this implies that it would be great if we can add the feature to the CVF plugin 
> to support the stream without M bit field set.

One source of inspiration here could be the 
gst-plugins-good/gstrtph264depay.c:gst_rtp_h264_depay_handle_nal() - it
has some code to guess where M should be. Look for "marker".

> 
> I can not say which AVB talker I'm using to generate the CVF stream,
> but at least there is such AVB stack in the market.
> 
> 
> John
> 
> On 2020/07/16 18:32, Desouza, Ederson wrote:
> > On Thu, 2020-07-16 at 17:58 -0400, John Rama wrote:
> > > Hello Desounza,
> > > 
> > > Thanks again for your help on this.
> > > 
> > > > > But Followings does not return no data...
> > > > > $gst-launch-1.0 avtpsrc ifname=enp8s0 '!' avtpcvfdepay '!' fakesink dump=true
> > > > > Setting pipeline to PAUSED ...
> > > > > Pipeline is live and does not need PREROLL ...
> > > > > Pipeline is PREROLLED ...
> > > > > Setting pipeline to PLAYING ...
> > > > > New clock: GstSystemClock
> > > > > 
> > > > > Can you think of any reason why ?
> > > > 
> > > > AVTP streams have a streamid - have you tried using:
> > > > 
> > > > ... ! avtpcvfdepay streamid=<stream-id> ! ...
> > > > 
> > > > Also note that you can get debug information from the avtp plugin with:
> > > > 
> > > > GST_DEBUG=avtp*:<debug-level> gst-launch-1.0
> > > > 
> > > > So you can check what the plugin is doing.
> > > 
> > > gst-launch-1.0 --gst-debug-color-mode=off clockselect. '(clock-id=realtime' avtpsrc ifname=enp8s0 address=91:EF:00:00:FE:00 '!' avtpcvfdepay streamid=0x0123456789abcdef '!' fakesink dump=true ')'
> > > 
> > > I put streamid and destination mac address, but I still have no success ( I can not see fakesink receives the data)...
> > > According to the log (I attached whole log), avtpcvfdepay surely receive CVF stream, but does not pass them to the fakesink... 
> > > Any idea ??
> > 
> > From the log, it appears that no avtp packet arrives with M bit set, so
> > avtpcvfdepay keeps just accumulating nal units.
> > Can you ensure that what is generating the stream is properly setting
> > the M bit on the last access unit ("packet of a frame")? Wireshark can
> > be of help here.
> > 
> > > =====================================================
> > > 
> > > + GST_DEBUG='avtp*:7'
> > > + gst-launch-1.0 --gst-debug-color-mode=off clockselect. '(clock-id=realtime' avtpsrc ifname=enp8s0 address=91:EF:00:00:FE:00 '!' avtpcvfdepay streamid=0x0123456789abcdef '!' fakesink dump=true ')'
> > > 0:00:00.021076523  3505 0x5566083a1c00 DEBUG                avtpsrc gstavtpsrc.c:156:gst_avtp_src_set_property:<avtpsrc0> prop_id 1
> > > 0:00:00.021102046  3505 0x5566083a1c00 DEBUG                avtpsrc gstavtpsrc.c:156:gst_avtp_src_set_property:<avtpsrc0> prop_id 2
> > > 0:00:00.021151987  3505 0x5566083a1c00 DEBUG      avtpbasedepayload gstavtpbasedepayload.c:142:gst_avtp_base_depayload_set_property:<avtpcvfdepay0> prop_id 1
> > > Setting pipeline to PAUSED ...
> > > 0:00:00.043151942  3505 0x5566083a1c00 DEBUG                avtpsrc gstavtpsrc.c:248:gst_avtp_src_start:<avtpsrc0> AVTP source started
> > > Pipeline is live and does not need PREROLL ...
> > > Pipeline is PREROLLED ...
> > > Setting pipeline to PLAYING ...
> > > 0:00:00.043562029  3505 0x5566083a1850 DEBUG      avtpbasedepayload gstavtpbasedepayload.c:178:gst_avtp_base_depayload_sink_event:<avtpcvfdepay0> event stream-start
> > > New clock: DebugGstSystemClock
> > > 0:00:00.043681756  3505 0x5566083a1850 DEBUG      avtpbasedepayload gstavtpbasedepayload.c:178:gst_avtp_base_depayload_sink_event:<avtpcvfdepay0> event caps
> > > 0:00:00.069131412  3505 0x5566083a1850 DEBUG      avtpbasedepayload gstavtpbasedepayload.c:178:gst_avtp_base_depayload_sink_event:<avtpcvfdepay0> event segment
> > > 0:00:00.069168990  3505 0x5566083a1850 INFO            avtpcvfdepay gstavtpcvfdepay.c:379:gst_avtp_cvf_depay_validate_avtpdu:<avtpcvfdepay0> Unexpected AVTP header seq num 166, expected 0
> > > 0:00:00.069178877  3505 0x5566083a1850 DEBUG           avtpcvfdepay gstavtpcvfdepay.c:582:gst_avtp_cvf_depay_handle_fu_a:<avtpcvfdepay0> Fragment indicator - NRI: 2
> > > 0:00:00.069188523  3505 0x5566083a1850 DEBUG           avtpcvfdepay gstavtpcvfdepay.c:590:gst_avtp_cvf_depay_handle_fu_a:<avtpcvfdepay0> Fragment header - type: 1 start: 1 end: 0
> > > 0:00:00.069293505  3505 0x5566083a1850 DEBUG           avtpcvfdepay gstavtpcvfdepay.c:582:gst_avtp_cvf_depay_handle_fu_a:<avtpcvfdepay0> Fragment indicator - NRI: 2
> > > 0:00:00.069307743  3505 0x5566083a1850 DEBUG           avtpcvfdepay gstavtpcvfdepay.c:590:gst_avtp_cvf_depay_handle_fu_a:<avtpcvfdepay0> Fragment header - type: 1 start: 0 end: 0
> > > ...
> > > 0:00:00.084477094  3505 0x5566083a1850 DEBUG           avtpcvfdepay gstavtpcvfdepay.c:582:gst_avtp_cvf_depay_handle_fu_a:<avtpcvfdepay0> Fragment indicator - NRI: 2
> > > 0:00:00.084485950  3505 0x5566083a1850 DEBUG           avtpcvfdepay gstavtpcvfdepay.c:590:gst_avtp_cvf_depay_handle_fu_a:<avtpcvfdepay0> Fragment header - type: 1 start: 0 end: 1
> > > 0:00:00.084499930  3505 0x5566083a1850 LOG             avtpcvfdepay gstavtpcvfdepay.c:452:gst_avtp_cvf_depay_internal_push:<avtpcvfdepay0> Adding buffer of size 45829 (nalu size 45825) to out_buffer
> > > ...
> > > =====================================================
> > > 
> > > P.S
> > > You might wonder what's this in the log.... 
> > > > 0:00:00.069168990 3505 0x5566083a1850 INFO avtpcvfdepay gstavtpcvfdepay.c:379:gst_avtp_cvf_depay_validate_avtpdu:<avtpcvfdepay0> Unexpected AVTP header seq num 166, expected 0
> > > This is because there is another AVTP message(AVDECC ADC) in the network.
> > > I do not think this is the problem.
> > > But please let me know if this is the problem..
> > 
> > It is not, you can see them being safely discarded with
> > "Unexpected AVTP header subtype 250, expected 3" message.
> > 
> > Cheers!
> > 
> > > Thanks !!
> > > 
> > > John
> > > 