<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Ohh. Thank you but it seems I don't have access to gst_buffer_new_memdup since I am using 1.18</div><div dir="ltr"><br></div><div>The other option to not copy I guess is not suitable for me because encoded_frame will be freed by another component (the encoded data is part of a bigger object that is free when the object call its destructor)</div><div><br></div><div>So finally I opted for this</div><div><br></div><div><div style="color:rgb(212,212,212);background-color:rgb(30,30,30);font-family:Consolas,"Courier New",monospace;font-size:14px;line-height:19px;white-space:pre"><div>buffer = <span style="color:rgb(220,220,170)">gst_buffer_new_allocate</span> (<span style="color:rgb(86,156,214)">NULL</span>, frame_size, <span style="color:rgb(86,156,214)">NULL</span>);</div><div> <span style="color:rgb(220,220,170)">gst_buffer_map</span> (buffer, &map, GST_MAP_WRITE);</div><div> <span style="color:rgb(220,220,170)">memcpy</span>((guchar *)<span style="color:rgb(156,220,254)">map</span>.<span style="color:rgb(156,220,254)">data</span>, encoded_frame, <span style="color:rgb(220,220,170)">gst_buffer_get_size</span>( buffer ) );</div><div> <span style="color:rgb(220,220,170)">gst_buffer_unmap</span>(buffer, &map);</div><div><br></div></div></div></div></div></div></div><div><br></div><div>Now I don't see those <b>broken/invalid nal Type: 0</b> messages but currently I still don't see that the raw file is receiving bytes.</div><div>Do you think it is possible to use the decoder with this configuration? Maybe I need to follow the approach of need-data to feed the decoder or How Can I check if the decoder is actually processing everything?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 7, 2023 at 4:50 PM Michael Gruner <<a href="mailto:michael.gruner@ridgerun.com" target="_blank">michael.gruner@ridgerun.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hi Israel<div><br></div><div>This assignment is invalid:</div><div><br></div><div><div style="color:rgb(0,0,0)">gst_buffer_map(buffer, &map, GST_MAP_WRITE);</div><div style="color:rgb(0,0,0)"><b> map.data = encoded_frame;</b></div><div style="color:rgb(0,0,0)"> gst_buffer_unmap(buffer, &map);</div><div><br></div>You need to copy the data using a plain memcpy or </div><div>by creating the new buffer directly as a copy using gst_buffer_new_memdup.</div><div><br></div><div>If you would like to avoid the copy, then you can use gst_buffer_new_wrapped or gst_buffer_new_wrapped_full but you need to be careful that: 1. The pointer remains valid the while the buffer is alive and 2. The pointer is freed when the buffer is unreffed.</div><div><br></div><div><div dir="ltr">Michael</div><div dir="ltr"><br><blockquote type="cite">On 7 Jul 2023, at 04:02, Israel Díaz via gstreamer-devel <<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Dear GStreamer community,<br></div><div><br></div><div>I am currently facing an issue while attempting to decode H264 frames using the appsrc element in GStreamer. I have constructed the following pipeline within my application:</div><div><br></div><div>appsrc name=mysource ! video/x-h264, alignment=au, stream-format=byte-stream ! h264parse ! video/x-h264, alignment=au, stream-format=byte-stream ! omxh264dec ! video/x-raw, format=NV16_10LE32, width=1920, height=1080, framerate=30/1 ! filesink location=ball.raw</div><div><br></div><div>To feed the appsrc with frames, I am reading an H264 file frame by frame since I store each frame in a structure along with its size. Then, I push the frames into the appsrc using the following function:</div><div><br></div><div>void VDRE2GStreamerDecodingDisplaySinkTask::PushBufferToGStreamer(uint8_t* encoded_frame, uint32_t frame_size)</div><div>{</div><div> GstFlowReturn ret;</div><div> GstMapInfo map;</div><div> GstBuffer *buffer = gst_buffer_new_and_alloc(frame_size);</div><div> gst_buffer_map(buffer, &map, GST_MAP_WRITE);</div><div> map.data = encoded_frame;</div><div> gst_buffer_unmap(buffer, &map);</div><div><br></div><div> /* Push the buffer into the appsrc */</div><div> g_signal_emit_by_name(m_appsrc, "push-buffer", buffer, &ret);</div><div><br></div><div> /* Free the buffer now that we are done with it */</div><div> gst_buffer_unref(buffer);</div><div><br></div><div> if (ret != GST_FLOW_OK) {</div><div> g_print("PushBufferToGStreamer: Error!\n");</div><div> }</div><div>}</div><div><br></div><div>However, when I execute the pipeline and set GST_DEBUG=4, I encounter the following error messages:</div><div><br></div><div>Decode Thread: Frame to Process : 1 :s 246</div><div>Decode Thread: Frame to Process : 2 :s 232</div><div>Decode Thread: Frame to Process : 3 :s 854</div><div>Decode Thread: Frame to Process : 4 :s 952</div><div>Decode Thread: Frame to Process : 5 :s 350</div><div>Decode Thread: Frame to Process : 6 :s 1038</div><div>Decode Thread: Frame to Process : 7 :s 1447</div><div>Decode Thread: Frame to Process : 8 :s 1316</div><div>Decode Thread: Frame to Process : 9 :s 1297</div><div>Decode Thread: Frame to Process : 10 :s 1205</div><div>0:00:02.370465675 6548 0xffff8c01ff60 WARN h264parse gsth264parse.c:1562:gst_h264_parse_handle_frame:<myparser> broken/invalid nal Type: 0 Unknown, Size: 29 will be dropped</div><div>0:00:02.370549896 6548 0xffff8c01ff60 WARN h264parse gsth264parse.c:1562:gst_h264_parse_handle_frame:<myparser> broken/invalid nal Type: 0 Unknown, Size: 1140 will be dropped</div><div>Decode Thread: Frame to Process : 11 :s 1222</div><div>Decode Thread: Frame to Process : 12 :s 1189</div><div>Decode Thread: Frame to Process : 13 :s 1094</div><div>Decode Thread: Frame to Process : 14 :s 930</div><div>Decode Thread: Frame to Process : 15 :s 1000</div><div>Decode Thread: Frame to Process : 16 :s 888</div><div>Decode Thread: Frame to Process : 17 :s 901</div><div>Decode Thread: Frame to Process : 18 :s 788</div><div>Decode Thread: Frame to Process : 19 :s 833</div><div>Decode Thread: Frame to Process : 20 :s 764</div><div>Decode Thread: Frame to Process : 21 :s 727</div><div>Decode Thread: Frame to Process : 22 :s 616</div><div>Decode Thread: Frame to Process : 23 :s 728</div><div>Decode Thread: Frame to Process : 24 :s 622</div><div>Decode Thread: Frame to Process : 25 :s 609</div><div>Decode Thread: Frame to Process : 26 :s 657</div><div>Decode Thread: Frame to Process : 27 :s 651</div><div>Decode Thread: Frame to Process : 28 :s 621</div><div>Decode Thread: Frame to Process : 29 :s 534</div><div>Decode Thread: Frame to Process : 30 :s 2989</div><div>0:00:03.033182378 6548 0xffff8c01ff60 WARN h264parse gsth264parse.c:1562:gst_h264_parse_handle_frame:<myparser> broken/invalid nal Type: 0 Unknown, Size: 29 will be dropped</div><div>0:00:03.033258709 6548 0xffff8c01ff60 WARN h264parse gsth264parse.c:1562:gst_h264_parse_handle_frame:<myparser> broken/invalid nal Type: 0 Unknown, Size: 117 will be dropped</div><div>0:00:03.033309439 6548 0xffff8c01ff60 WARN h264parse gsth264parse.c:1562:gst_h264_parse_handle_frame:<myparser> broken/invalid nal Type: 0 Unknown, Size: 29 will be dropped</div><div>0:00:03.033369800 6548 0xffff8c01ff60 WARN h264parse gsth264parse.c:1562:gst_h264_parse_handle_frame:<myparser> broken/invalid nal Type: 0 Unknown, Size: 1468 will be dropped</div><div>Decode Thread: Frame to Process : 31 :s 411</div><div>Decode Thread: Frame to Process : 32 :s 465</div><div>Decode Thread: Frame to Process : 33 :s 514</div><div>Decode Thread: Frame to Process : 34 :s 520</div><div>Decode Thread: Frame to Process : 35 :s 519</div><div>Decode Thread: Frame to Process : 36 :s 476</div><div>Decode Thread: Frame to Process : 37 :s 448</div><div>Decode Thread: Frame to Process : 38 :s 544</div><div>Decode Thread: Frame to Process : 39 :s 523</div><div>Decode Thread: Frame to Process : 40 :s 454</div><div>Decode Thread: Frame to Process : 41 :s 561</div><div>Decode Thread: Frame to Process : 42 :s 409</div><div>Decode Thread: Frame to Process : 43 :s 506</div><div>Decode Thread: Frame to Process : 44 :s 330</div><div>Decode Thread: Frame to Process : 45 :s 2180</div><div>0:00:03.530095934 6548 0xffff8c01ff60 WARN h264parse gsth264parse.c:1562:gst_h264_parse_handle_frame:<myparser> broken/invalid nal Type: 0 Unknown, Size: 29 will be dropped</div><div>0:00:03.530192075 6548 0xffff8c01ff60 WARN h264parse gsth264parse.c:1562:gst_h264_parse_handle_frame:<myparser> broken/invalid nal Type: 0 Unknown, Size: 117 will be dropped</div><div>0:00:03.530251666 654</div><div><br></div><div><br></div><div>So then I analyzed the encoded_data to check if there are valid NAL units:</div><div><br></div><div><div>have analyzed the encoded_frame data to determine if it contains valid NAL units. Here's a summary of your findings for the first five data sets:</div><div><br></div><div>Encoded data values in hexadecimal: 0, size: 3241</div><div>00 00 00 01 27 7A 00 28 B6 D0 0C E8 07 80 22 7E 27 01 6A 02 04 04 80 00 00 03 00 80 00 00 1E 19 A8 00 3D 09 00 01 6E 37 FF FE 05 00 00 00 01 28 EE 3C</div><div><br></div><div>Encoded data values in hexadecimal: 1, size: 246</div><div>00 00 00 01 21 E2 01 08 42 DF 00 00 03 00 00 03 00 00 03 00 00 03 00 00 03 00 00 03 00 00 03 00 00 09 36 B5 84 05 B0 C9 8C DA C9 6F 9D F0 00</div><div><br></div><div>Encoded data values in hexadecimal: 2, size: 232</div><div>00 00 00 01 21 E4 02 08 42 DF 00 00 03 00 00 03 00 00 03 00 00 03 00 00 03 00 00 03 00 00 03 00 00 03 00 16 D0 00 00 01 21 00 1F E3 90 08 21</div><div><br></div><div>Encoded data values in hexadecimal: 3, size: 854</div><div>00 00 00 01 21 E6 03 08 8B 7F 00 00 03 00 00 03 00 00 03 00 00 03 00 00 03 00 00 03 00 00 03 00 00 03 00 06 2C 00 00 01 21 00 1F E3 98 0C 22</div><div><br></div><div>Encoded data values in hexadecimal: 4, size: 952</div><div>00 00 00 01 21 E8 04 0E DF 00 00 03 00 00 03 00 00 03 00 00 03 00 00 03 00 00 03 00 00 03 00 00 03 00 00 97 80 00 00 01 21 00 1F E3 A0 10 3B</div></div><div><br></div><div><div>It seems that the analyzed data contains valid NAL units, as expected. I have attempted a similar test using a file source and launching the pipeline with gst-launch as follows:</div><div><br></div><div>gst-launch-1.0 -e filesrc location=ball2.h264 ! video/x-h264, alignment=au, width=1920, height=1080, framerate=30/1 ! h264parse ! omxh264dec ! video/x-raw, format=NV16_10LE32, width=1920, height=1080, framerate=30/1 ! filesink location=ball_gst.raw</div><div><br></div><div>During this test, I did not encounter any issues or error messages with GST_DEBUG=4. Additionally, the raw file was populated with bytes, unlike the appsrc version where the content always appears empty (presumably because it is not being decoded at any point).</div></div><div><br></div><div>I even tried with a identity dump=true element between filesrc and h264parse and I also have the same bytes I am injecting to appsrc So I don't know what can be the difference </div><div><br></div><div>Thank you in advance.</div><div>Best regards.</div><div>Israel.</div><div><br></div></div></div></div></div> </div></blockquote></div></div></blockquote></div> </div></div>