How to debug/fix running error when use rtph264pay?

[Psychesnet Hsieh]

Hi all,

I'm newbie on gstreamer application development, so I need some helps from you(Masters). Thanks.

First, I'm writing appsrc testing tool which access video h264 frames from mmap and send it out via tcpclientsink. Basically, the behavior of my appsrc like "gst-launch-1.0 appsrc name=ringbuf ! tcpclientsink host=192.168.143.102 port=1234".

At server part, I run command on my ubuntu PC, "gst-lanuch-1.0 tcpserversrc host=192.168.143.102 port=7001 ! h264parse ! avdec_h264 ! autovideosink". Anything works well.

Now, I'm going to add rtp feature on my testing tool. So I change a little bit on my server side with "gst-launch-1.0 tcpserversrc host=192.168.143.102 port=7010 ! "application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264" ! rtph264depay ! h264parse ! avdec_h264 ! autovideosink"

At client side, the behavior of my appsrc like "gst-launch-1.0 appsrc name=ringbuf ! rtph264pay ! tcpclientsink host=192.168.143.102 port=1234". It not works.

The log from client side are

0:00:00.160697339  1447       0xded5e0 INFO                 basesrc gstbasesrc.c:2962:gst_base_src_loop:<ringbuf> marking pending DISCONT
0:00:00.161291538  1447       0xded5e0 WARN                 basesrc gstbasesrc.c:3072:gst_base_src_loop:<ringbuf> error: Internal data stream error.
0:00:00.161422968  1447       0xded5e0 WARN                 basesrc gstbasesrc.c:3072:gst_base_src_loop:<ringbuf> error: streaming stopped, reason not-negotiated (-4)
0:00:00.161801902  1447       0xded5e0 INFO        GST_ERROR_SYSTEM gstelement.c:2141:gst_element_message_full_with_details:<ringbuf> posting message: Internal data stream error.
0:00:00.162334318  1447       0xded5e0 INFO        GST_ERROR_SYSTEM gstelement.c:2168:gst_element_message_full_with_details:<ringbuf> posted error message: Internal data stream error.

I don't know how to debug it and need someone to help me to debug.

And basically, the testing tool is referring from https://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/tests/examples/app/appsrc-stream.c

I just change the part of how to access the data. Please help. Thanks.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[gotsring]

When I was streaming H.264 over UDP, I used the following pipelines. You
might need to specify the caps in the receiver so that the rth264depay knows
what it's decoding. I also had the MTU specified in rtph264pay, not sure
why, but it worked (Gstreamer 1.14, I think? I no longer have the hardware).

Server:
gst-launch-1.0 nvcamerasrc ! omxh264enc ! 'video/x-h264,
stream-format=byte-stream' ! queue ! h264parse !  rtph264pay mtu=1400 !
udpsink host=10.0.0.10 port=5000 sync=false async=false

Client:
gst-launch-1.0 udpsrc port=5000 !
application/x-rtp,encoding-name=H264,payload=96 ! rtph264depay ! h264parse !
avdec_h264 ! autovideosink



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Psychesnet Hsieh]

Hi gotsring,

Thanks for reply.

First, I was porting my code to x86 PC and run with

SERVER: gst-launch-1.0 udpsrc port=5000 !

application/x-rtp,encoding-name=H264,payload=96 ! rtph264depay ! h264parse !
avdec_h264 ! autovideosink

CLIENT: gst-launch-1.0 appsrc name=ringbuf ! 'video/x-h264,

stream-format=byte-stream' ! h264parse !  rtph264pay mtu=1400 !
udpsink host=10.0.0.10 port=5000

Above combination is working. Thanks.

I still have a question.

Once I remove h264parse from client, it would NOT work anymore, why?

In the future, more complicate case, how do I know I should add h264parse or not?

Please advise. Thank you.

gotsring <[hidden email]> 於 2020年7月28日 週二 上午3:29寫道：

When I was streaming H.264 over UDP, I used the following pipelines. You
might need to specify the caps in the receiver so that the rth264depay knows
what it's decoding. I also had the MTU specified in rtph264pay, not sure
why, but it worked (Gstreamer 1.14, I think? I no longer have the hardware).

Server:
gst-launch-1.0 nvcamerasrc ! omxh264enc ! 'video/x-h264,
stream-format=byte-stream' ! queue ! h264parse !  rtph264pay mtu=1400 !
udpsink host=10.0.0.10 port=5000 sync=false async=false

Client:
gst-launch-1.0 udpsrc port=5000 !
application/x-rtp,encoding-name=H264,payload=96 ! rtph264depay ! h264parse !
avdec_h264 ! autovideosink



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Thornton, Keith]

Hi,

normally we stream h264 in byte-stream format and we write files using avc format. H264parse converts on the fly between these two formats. I think you will find that default vlc expects avc format so if you stream in byte-stream format and write this to a file without converting it to avc using h264pars, the file will not play

Gruesse

 

Von: gstreamer-devel <[hidden email]> Im Auftrag von Psychesnet Hsieh
Gesendet: Dienstag, 28. Juli 2020 04:52
An: Discussion of the development of and with GStreamer <[hidden email]>
Betreff: Re: How to debug/fix running error when use rtph264pay?

 

Hi gotsring,

 

Thanks for reply.

 

First, I was porting my code to x86 PC and run with

SERVER: gst-launch-1.0 udpsrc port=5000 !

application/x-rtp,encoding-name=H264,payload=96 ! rtph264depay ! h264parse !
avdec_h264 ! autovideosink

CLIENT: gst-launch-1.0 appsrc name=ringbuf ! 'video/x-h264,

stream-format=byte-stream' ! h264parse !  rtph264pay mtu=1400 !
udpsink host=10.0.0.10 port=5000

 

Above combination is working. Thanks.

 

I still have a question.

Once I remove h264parse from client, it would NOT work anymore, why?

In the future, more complicate case, how do I know I should add h264parse or not?

Please advise. Thank you.

 

gotsring <[hidden email]> 於 2020年7月28日 週二 上午3:29寫道：

When I was streaming H.264 over UDP, I used the following pipelines. You
might need to specify the caps in the receiver so that the rth264depay knows
what it's decoding. I also had the MTU specified in rtph264pay, not sure
why, but it worked (Gstreamer 1.14, I think? I no longer have the hardware).

Server:
gst-launch-1.0 nvcamerasrc ! omxh264enc ! 'video/x-h264,
stream-format=byte-stream' ! queue ! h264parse !  rtph264pay mtu=1400 !
udpsink host=10.0.0.10 port=5000 sync=false async=false

Client:
gst-launch-1.0 udpsrc port=5000 !
application/x-rtp,encoding-name=H264,payload=96 ! rtph264depay ! h264parse !
avdec_h264 ! autovideosink



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Psychesnet Hsieh]

Hi Keith,

Thanks. This help me a lot. Since our embedded system did not have h264parse, we need to find a way to have it.

Thanks a lot.

Thornton, Keith <[hidden email]> 於 2020年7月28日 週二 下午2:17寫道：

Hi,

normally we stream h264 in byte-stream format and we write files using avc format. H264parse converts on the fly between these two formats. I think you will find that default vlc expects avc format so if you stream in byte-stream format and write this to a file without converting it to avc using h264pars, the file will not play

Gruesse

 

Von: gstreamer-devel <[hidden email]> Im Auftrag von Psychesnet Hsieh
Gesendet: Dienstag, 28. Juli 2020 04:52
An: Discussion of the development of and with GStreamer <[hidden email]>
Betreff: Re: How to debug/fix running error when use rtph264pay?

 

Hi gotsring,

 

Thanks for reply.

 

First, I was porting my code to x86 PC and run with

SERVER: gst-launch-1.0 udpsrc port=5000 !

application/x-rtp,encoding-name=H264,payload=96 ! rtph264depay ! h264parse !
avdec_h264 ! autovideosink

CLIENT: gst-launch-1.0 appsrc name=ringbuf ! 'video/x-h264,

stream-format=byte-stream' ! h264parse !  rtph264pay mtu=1400 !
udpsink host=10.0.0.10 port=5000

 

Above combination is working. Thanks.

 

I still have a question.

Once I remove h264parse from client, it would NOT work anymore, why?

In the future, more complicate case, how do I know I should add h264parse or not?

Please advise. Thank you.

 

gotsring <[hidden email]> 於 2020年7月28日 週二 上午3:29寫道：

When I was streaming H.264 over UDP, I used the following pipelines. You
might need to specify the caps in the receiver so that the rth264depay knows
what it's decoding. I also had the MTU specified in rtph264pay, not sure
why, but it worked (Gstreamer 1.14, I think? I no longer have the hardware).

Server:
gst-launch-1.0 nvcamerasrc ! omxh264enc ! 'video/x-h264,
stream-format=byte-stream' ! queue ! h264parse !  rtph264pay mtu=1400 !
udpsink host=10.0.0.10 port=5000 sync=false async=false

Client:
gst-launch-1.0 udpsrc port=5000 !
application/x-rtp,encoding-name=H264,payload=96 ! rtph264depay ! h264parse !
avdec_h264 ! autovideosink



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[gotsring]

h264parse is in gstreamer-plugins-bad, so you may just need to install that
package.

I think in Ubuntu 18, this package was listed in the community-maintained
universe repo, not the main one, so make sure that is selected in the
software update options if you are using Ubuntu. I'm not sure if this is the
case for other package managers, but just FYI.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Psychesnet Hsieh]

Hi Gotsring,

I'm working on openwrt, gst version is 1.16.2. At source code folder, there is no videoparsesbad folder, something weird. Thanks.

gst-plugins-base-1.16.2$ ls gst/video* videoconvert/ videorate/ videoscale/ videotestsrc/

gotsring <[hidden email]> 於 2020年7月28日 週二 下午10:37寫道：

h264parse is in gstreamer-plugins-bad, so you may just need to install that
package.

I think in Ubuntu 18, this package was listed in the community-maintained
universe repo, not the main one, so make sure that is selected in the
software update options if you are using Ubuntu. I'm not sure if this is the
case for other package managers, but just FYI.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[gotsring]

It looks like you're looking in gst-plugins-*base*. If you're trying to get
h264parse, it's in a different git repo entirely: gst-plugins-*bad*. Also,
be aware that some files are in the gst/ directory, and some are in the
gst-libs/ directory. However, you should just be able to build everything
without too much hassle using the autogen script, see the README file.

See here:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/tree/1.16
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/tree/1.16/gst/videoparsers

Past that, I don't think I can help much, I haven't built gstreamer from
source in a while.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Psychesnet Hsieh]

Hi Gostring,

Thanks. I success to enable h264parse via change makefile.

Looks like there are more dependency on plugin-bad, I fix it.

By the way, I check the license on h264parse plugin.

Library is LGPL, tool is GPL, right? Thanks.

gotsring <[hidden email]> 於 2020年7月29日 週三 下午10:56寫道：

It looks like you're looking in gst-plugins-*base*. If you're trying to get
h264parse, it's in a different git repo entirely: gst-plugins-*bad*. Also,
be aware that some files are in the gst/ directory, and some are in the
gst-libs/ directory. However, you should just be able to build everything
without too much hassle using the autogen script, see the README file.

See here:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/tree/1.16
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/tree/1.16/gst/videoparsers

Past that, I don't think I can help much, I haven't built gstreamer from
source in a while.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le jeudi 30 juillet 2020 à 16:20 +0800, Psychesnet Hsieh a écrit :
> Hi Gostring,
>
> Thanks. I success to enable h264parse via change makefile.
> Looks like there are more dependency on plugin-bad, I fix it.
>
> By the way, I check the license on h264parse plugin.
> Library is LGPL, tool is GPL, right? Thanks.

All code in the GStreamer repository should be LGPL v2+ or compatible.
The code that isn't compatible or patent encumbered would be placed in
gst-plugins-ugly.

The h264parse element is part of libgstvideoparsers.so plugin, and
depends on libgstcodecparsers.so library. This is all LGPL.

regards,
Nicolas

>
>
>
> gotsring <[hidden email]> 於 2020年7月29日 週三 下午10:56寫道：
> > It looks like you're looking in gst-plugins-*base*. If you're trying to get
> > h264parse, it's in a different git repo entirely: gst-plugins-*bad*. Also,
> > be aware that some files are in the gst/ directory, and some are in the
> > gst-libs/ directory. However, you should just be able to build everything
> > without too much hassle using the autogen script, see the README file.
> >
> > See here:
> > https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/tree/1.16
> > https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/tree/1.16/gst/videoparsers
> >
> > Past that, I don't think I can help much, I haven't built gstreamer from
> > source in a while.
> >
> >
> >
> > --
> > Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> > _______________________________________________
> > gstreamer-devel mailing list
> > [hidden email]
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[gotsring]

I think that's true for gst-plugins-base and gst-plugins-good, but anything
from gst-plugins-bad or gst-plugins-ugly don't necessarily follow this,
which is why they were separated out.

You might want to check the license for each plugin you use, usually listed
in the source file headers.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Psychesnet Hsieh]

Hi Gotsring,

Thanks. I will check it later.

For me, we only enable h264parse on gst-plugins-bad and I doubled the header of gsth264parse.

It is LGPL. Thanks a lot.

gotsring <[hidden email]> 於 2020年7月30日 週四 下午9:01寫道：

I think that's true for gst-plugins-base and gst-plugins-good, but anything
from gst-plugins-bad or gst-plugins-ugly don't necessarily follow this,
which is why they were separated out.

You might want to check the license for each plugin you use, usually listed
in the source file headers.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Psychesnet Hsieh]

Hi Gotsring,

I still have a question on rtph264pay after checking the sink's capability.

For rtph264pay,

Pad Templates:
  SINK template: 'sink'
    Availability: Always
    Capabilities:
      video/x-h264
          stream-format: avc
              alignment: au
      video/x-h264
          stream-format: byte-stream
              alignment: { (string)nal, (string)au }

The input of rtph264pay could be avc:au or byte-stream:nal/au.

Since my H264 frame is coming from ISP, each h264 frame has complete NAL header.

And at each callback, I will put a complete H264 frame to pipeline.

So, I try to set appsrc's capability with byte-stream:au without h264parse, I can see h264 frame can be display on server side.

But, the appsrc program keep showing

(process:1113): GStreamer-CRITICAL **: 08:21:56.048: gst_segment_to_running_time: assertion 'segment->format == format' failed

Questions are

1. set appsrc's capability with byte-stream:au without h264parse, is it make sense?

2. if 1 is yes, how can I fix critical issue?

Thanks.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le vendredi 31 juillet 2020 à 16:39 +0800, Psychesnet Hsieh a écrit :

> Hi Gotsring,
>
> I still have a question on rtph264pay after checking the sink's capability.
> For rtph264pay,
> Pad Templates:
>   SINK template: 'sink'
>     Availability: Always
>     Capabilities:
>       video/x-h264
>           stream-format: avc
>               alignment: au
>       video/x-h264
>           stream-format: byte-stream
>               alignment: { (string)nal, (string)au }
>
> The input of rtph264pay could be avc:au or byte-stream:nal/au.
> Since my H264 frame is coming from ISP, each h264 frame has complete NAL header.
> And at each callback, I will put a complete H264 frame to pipeline.
> So, I try to set appsrc's capability with byte-stream:au without h264parse, I can see h264 frame can be display on server side.
> But, the appsrc program keep showing
> (process:1113): GStreamer-CRITICAL **: 08:21:56.048: gst_segment_to_running_time: assertion 'segment->format == format' failed

You like forgot to set the property "format" on appsrc
to GST_FORMAT_TIME. The RTP elements only works well with time format.
Make sure to setup some decent timestamp if you want smoother network
streaming.

>
> Questions are
> 1. set appsrc's capability with byte-stream:au without h264parse, is it make sense?
> 2. if 1 is yes, how can I fix critical issue?
>
> Thanks.
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[gotsring]

1.
If you are putting a complete H.264 byte-stream frame to the pipeline, it
makes sense that your appsrc caps should be
stream-format: byte-stream
alignment: au

This is something you can easily try to see if it works, and it sounds like
it is, for the most part.

2.
I don't have that much experience with GStreamer, so I don't know what could
be causing that error. What is the pipeline you're using to test this? Do
you know where the error is happening? I recommend adding a fakesink in
places to find which element is producing the error. Log files would also
help.

 





--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Psychesnet Hsieh]

Hi all,

Thanks. And I already test "GST_FORMAT_TIME", anything pause there, even I can not kill the pipeline.

Hi Gotsring,

The pipeline should like "appsrc name=ringbuf ! video/x-h264,stream-format=byte-stream,alignment=au ! rtph264pay ! udpsink host=ip port=1234". I can make sure appsrc can output complete H264 frame at each callback.

I will try to grab more log for you. Thanks.

gotsring <[hidden email]> 於 2020年8月1日 週六 上午1:41寫道：

1.
If you are putting a complete H.264 byte-stream frame to the pipeline, it
makes sense that your appsrc caps should be
stream-format: byte-stream
alignment: au

This is something you can easily try to see if it works, and it sounds like
it is, for the most part.

2.
I don't have that much experience with GStreamer, so I don't know what could
be causing that error. What is the pipeline you're using to test this? Do
you know where the error is happening? I recommend adding a fakesink in
places to find which element is producing the error. Log files would also
help.







--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Psychesnet Hsieh]

Hi all,

Please check the attachment. Thanks.

Psychesnet Hsieh <[hidden email]> 於 2020年8月1日 週六 上午5:46寫道：

Hi all,

Thanks. And I already test "GST_FORMAT_TIME", anything pause there, even I can not kill the pipeline.

Hi Gotsring,

The pipeline should like "appsrc name=ringbuf ! video/x-h264,stream-format=byte-stream,alignment=au ! rtph264pay ! udpsink host=ip port=1234". I can make sure appsrc can output complete H264 frame at each callback.

I will try to grab more log for you. Thanks.

gotsring <[hidden email]> 於 2020年8月1日 週六 上午1:41寫道：

1.
If you are putting a complete H.264 byte-stream frame to the pipeline, it
makes sense that your appsrc caps should be
stream-format: byte-stream
alignment: au

This is something you can easily try to see if it works, and it sounds like
it is, for the most part.

2.
I don't have that much experience with GStreamer, so I don't know what could
be causing that error. What is the pipeline you're using to test this? Do
you know where the error is happening? I recommend adding a fakesink in
places to find which element is producing the error. Log files would also
help.







--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Psychesnet Hsieh]

Hi Gotsring and Defresne,

I don't add GST_FORMAT_TIME and remove following code at reading callback. Anything works.

-        GST_BUFFER_PTS(buffer) = GST_TIMEVAL_TO_TIME(hdr->fpts);
-        GST_BUFFER_DURATION(buffer) = gst_util_uint64_scale_int(1, GST_SECOND, app->extra_hdr.fps);

Do you know why? Interesting!!! Thanks.

Psychesnet Hsieh <[hidden email]> 於 2020年8月2日 週日 下午8:52寫道：

Hi all,

Please check the attachment. Thanks.

Psychesnet Hsieh <[hidden email]> 於 2020年8月1日 週六 上午5:46寫道：

Hi all,

Thanks. And I already test "GST_FORMAT_TIME", anything pause there, even I can not kill the pipeline.

Hi Gotsring,

The pipeline should like "appsrc name=ringbuf ! video/x-h264,stream-format=byte-stream,alignment=au ! rtph264pay ! udpsink host=ip port=1234". I can make sure appsrc can output complete H264 frame at each callback.

I will try to grab more log for you. Thanks.

gotsring <[hidden email]> 於 2020年8月1日 週六 上午1:41寫道：

1.
If you are putting a complete H.264 byte-stream frame to the pipeline, it
makes sense that your appsrc caps should be
stream-format: byte-stream
alignment: au

This is something you can easily try to see if it works, and it sounds like
it is, for the most part.

2.
I don't have that much experience with GStreamer, so I don't know what could
be causing that error. What is the pipeline you're using to test this? Do
you know where the error is happening? I recommend adding a fakesink in
places to find which element is producing the error. Log files would also
help.







--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel