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

Fri Jul 17 13:37:27 UTC 2020

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 ?

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.

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
>>