From: Farah A. <far...@ya...> - 2010-05-30 15:55:46
|
Hi I am trying to transmit an H264 file over a network using RTP streaming of gstreamer. My pipeline is: Sender: gst-launch-0.10 filesrc location=akiyo_qcif.264 ! h264parse ! rtph264pay pt=96 ! udpsink host=127.0.0.1 port=42050 sync=false Receiver: gst-launch-0.10 udpsrc port=42050 ! rtph264depay ! filesink location=/home/mrplus/Desktop/June/test.264 Please note that I am using the loopback address and there should be no packet loss. To verify if my pipeline is working fine and there should be no encoding loss, I used the following pipeline: gst-launch-0.10 filesrc location=akiyo_qcif.264 ! h264parse ! rtph264pay pt=96 ! rtph264depay ! h264parse ! filesink location=/home/mrplus/Desktop/June/test2.264 Now, in the first scenario, the sender finishes playing after a time on its own. I have to close the receiver using a Ctrl+C. I get an output file at the receiver that is significantly smaller than the sent file, runs a couple of seconds lesser than the sent file and has worse quality (boxes, blur etc) visually, when played. In the case of the second pipeline, however, the file is the perfect copy of the sent file as expected. I dont understand where is the loss taking place in a loopback address!!! Or else, what am I doing wrong? Is it because of the Ctrl+C and no EOS element on the receiever? What to do? Is it fine to stream and H264 file like that or do I have to have it in a container like mp4, avi etc. to stream properly? I attach the output of gst-launch -v for both sender and receiver. Both seem ok to me, no errors. --------------------------------------------------------------------------------------------------------------------------- Sender: gst-launch-0.10 -v filesrc location=akiyo_qcif.264 ! h264parse ! rtph264pay pt=96 ! udpsink host=127.0.0.1 port=42050 sync=false Setting pipeline to PAUSED ... Pipeline is PREROLLING ... /pipeline0/h264parse0.src: caps = video/x-h264 /pipeline0/rtph264pay0.sink: caps = video/x-h264 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock /pipeline0/rtph264pay0.src: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, profile-level-id=(string)900033, sprop-parameter-sets=(string)\"Z5AAM64ZGoLE6EAAAAMAQAAADKPGDKg\\=\", payload=(int)96, ssrc=(guint)2945604081, clock-base=(guint)1436723394, seqnum-base=(guint)52331 /pipeline0/udpsink0.sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, profile-level-id=(string)900033, sprop-parameter-sets=(string)\"Z5AAM64ZGoLE6EAAAAMAQAAADKPGDKg\\=\", payload=(int)96, ssrc=(guint)2945604081, clock-base=(guint)1436723394, seqnum-base=(guint)52331 Got EOS from element "pipeline0". Execution ended after 24871606 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... /pipeline0/udpsink0.sink: caps = NULL /pipeline0/rtph264pay0.sink: caps = NULL /pipeline0/rtph264pay0.src: caps = NULL /pipeline0/h264parse0.src: caps = NULL Setting pipeline to NULL ... FREEING pipeline ... ------------------------------------------------------------------------------------------------------------------------------- Receiver: (Interrupt is the Ctrl+C) gst-launch-0.10 -v udpsrc port=42050 ! rtph264depay ! filesink location=/home/mrplus/Desktop/June/test11.264 Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock Caught interrupt -- handling interrupt. Interrupt: Stopping pipeline ... Execution ended after 1403396440 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... ---------------------------------------------------------------------------------------------------------------------- |
From: Marco B. <gib...@gm...> - 2010-05-31 06:40:21
|
On Sun, May 30, 2010 at 6:55 PM, Farah Akhtar <far...@ya...> wrote: > > Hi > > I am trying to transmit an H264 file over a network using RTP streaming of > gstreamer. My pipeline is: > > Sender: > gst-launch-0.10 filesrc location=akiyo_qcif.264 ! h264parse ! rtph264pay > pt=96 ! udpsink host=127.0.0.1 port=42050 sync=false > > Receiver: > gst-launch-0.10 udpsrc port=42050 ! rtph264depay ! filesink > location=/home/mrplus/Desktop/June/test.264 looks like gsth264parse (function gst_h264_parse_update_src_caps) is converting the codec configuration data to a "codec-data" field for the caps. Relying on a signalling/control protocol (very often outside GStreamer scope) the payloader is not transmitting them again and thus your decoding side looses essential data. A quick fix is to manually set the codec configuration data in the "config" field of the receiving side caps between depayloader and decoder. Being the codec-data not bound to a particular format, the same value will not work for all the raw files you may want to test (but it should for the ones similar to this particular file). I think it's possible to modify the payloader so that the whole Gstreamer could become a little more network streaming friendly.. we'd just need an option which will enable converting the codec data of the caps into a buffer: we wouldn't then need any signalling/control protocols to setup a simple streaming test. Regards |
From: Marc L. <mar...@gm...> - 2010-05-31 07:46:35
|
> > I am trying to transmit an H264 file over a network using RTP streaming of > > gstreamer. My pipeline is: > > > > Sender: > > gst-launch-0.10 filesrc location=akiyo_qcif.264 ! h264parse ! rtph264pay > > pt=96 ! udpsink host=127.0.0.1 port=42050 sync=false > > > > Receiver: > > gst-launch-0.10 udpsrc port=42050 ! rtph264depay ! filesink > > location=/home/mrplus/Desktop/June/test.264 > > looks like gsth264parse (function gst_h264_parse_update_src_caps) is > converting the codec configuration data to a "codec-data" field for > the caps. Relying on a signalling/control protocol (very often outside > GStreamer scope) the payloader is not transmitting them again and thus > your decoding side looses essential data. A quick fix is to manually The fix is since quite some time in SVN; you need to enable config-interval on the rtph264pay element to multiplex NAL7/NAL8 into the stream. This fix has been in a couple of releases; but there was a minor issue in the last good that got fixed again in svn. > I think it's possible to modify the payloader so that the whole > Gstreamer could become a little more network streaming friendly.. we'd > just need an option which will enable converting the codec data of the > caps into a buffer: we wouldn't then need any signalling/control > protocols to setup a simple streaming test. Sending this in the RTP payloader (same problem for h264 and mpeg4); is working prefectly as long as you use RTP/ES. If you switch to something else; you're still not care free. Therefore, I am planning to move/copy this re-multiplexing into the parser elements {mpeg4|h264}parse. This would allow RTP/TS, TS and ES streams to work perfectly. -- greetz, marc In specifications, Murphy's Law supersedes Ohm's. crichton 2.6.26 #1 PREEMPT Tue Jul 29 21:17:59 CDT 2008 GNU/Linux |
From: Farah A. <far...@ya...> - 2010-06-05 20:50:35
|
Hi Thanks for the earlier advice. I figured I had to install a later release of gstreamer than Hardy would let me do. So, I updated my ubuntu to 10.04 Lucid and now have the latest gstreamer libraries. (The rtph264pay element does have a config-interval property that I couldnt find earlier.) I am now able to run the pipe fine. I still have to give a Ctrl+C at the receiver for the pipe to stop playing. Is that fine? My working pipeline: Sender: gst-launch-0.10 -v filesrc location=June/akiyo_qcif.264 ! h264parse ! video/x-h264 ! rtph264pay pt=96 config-interval=5 ! udpsink host=127.0.0.1 port=42050 sync=false Receiver: gst-launch-0.10 udpsrc port=42050 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96, ssrc=(guint)4091714163, clock-base=(guint)4007889851, seqnum-base=(guint)31909" ! rtph264depay ! filesink location=June/test6.264 I give the sender caps in the receiver pipe obviously. Thanks for help. |
From: Farah <far...@ya...> - 2010-06-06 02:24:44
|
Hi Things are not as good as they seemed. I have two identical computers set up to do streaming between them. Both have: OS: ubuntu 10.04 LTS gstreamer0.10-plugins-base : 0.10.28-1 gstreamer0.10-plugins-good : 0.10.21-1ubuntu2 gstreamer0.10-plugins-bad : 0.10.18-1ubuntu1 gstreamer0.10-plugins-bad (multiverse) : 0.10.18-0ubuntu1 Now, I use the same pipeline from my previous post. I use two gstreamer instances on the loopback address to stream from one gstreamer instance to the other. It works perfectly on one of my computers. File transfers perfectly and (obviously) the resultant size is always the same for the output file. However, on the other computer which has a faster processor, it doesnt work fine. I thought this might be something wrong with the config-interval parameter value I give. I tried changing the value from 1 to 10 but there seems to be no pattern in how the data is lost each time. However, each time, the output file is different in size and still has noise, blocks etc, showing data loss. I am completely at loss about what it could be. I hope you guys can help. The same pipeline that I use for both computers is as follows: Please note: The system that has loss is an open IP system. Could that be a problem? Sender: gst-launch-0.10 -v filesrc location=June/akiyo_qcif.264 ! h264parse ! video/x-h264 ! rtph264pay pt=96 config-interval=5 ! udpsink host=127.0.0.1 port=42050 sync=false Receiver: gst-launch-0.10 udpsrc port=42050 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96, ssrc=(guint)4091714163, clock-base=(guint)4007889851, seqnum-base=(guint)31909" ! rtph264depay ! filesink location=June/test6.264 I changed the receiver caps to ""application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264" with the same result. Thanks. Farah Akhtar. -- View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Using-gstreamer-to-transmit-H264-file-over-RTP-tp2236364p2244715.html Sent from the GStreamer-devel mailing list archive at Nabble.com. |
From: Farah <far...@ya...> - 2010-06-06 03:56:36
|
Another update, just so you know! I even updated my system to the latest gstreamer releases 0.10.29 from this ppa: https://launchpad.net/~gstreamer-developers/+archive/ppa That hasnt changed the situation much and that worries me more. This means that it may not actually be a gstreamer bug. Please help! Thanks. Farah Akhtar. -- View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Using-gstreamer-to-transmit-H264-file-over-RTP-tp2236364p2244738.html Sent from the GStreamer-devel mailing list archive at Nabble.com. |
From: Marco B. <gib...@gm...> - 2010-06-11 19:58:45
|
Hi, as I pointed out in the previous mail (I'm sorry if I've not been clear enough) you need to explicitly set the codec_data parameter in the receiving side caps. I also suggest you to mux the depayloaded h264 (even if you're using annex B it's not a container format, only a codec). The easiest way is to put the muxer between the h264 depayloader and the filesink. Regards On Sun, Jun 6, 2010 at 6:56 AM, Farah <far...@ya...> wrote: > > > Another update, just so you know! > > I even updated my system to the latest gstreamer releases 0.10.29 from this > ppa: > > https://launchpad.net/~gstreamer-developers/+archive/ppa > > That hasnt changed the situation much and that worries me more. This means > that it may not actually be a gstreamer bug. Please help! > > Thanks. > > Farah Akhtar. > -- > View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Using-gstreamer-to-transmit-H264-file-over-RTP-tp2236364p2244738.html > Sent from the GStreamer-devel mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > gstreamer-devel mailing list > gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > |
From: Farah <far...@ya...> - 2010-06-12 00:47:58
|
Thanks Marco. I think you were very clear on the previous mail too but I dint understand you well. The problem is: The h264 file that I am using is not encoded by one of the gstreamer elements. I encode the yuv file using another encoder which I want to evaluate. Then, I stream the file with gstreamer using the pipe from my post, receive it over udpsrc and want to store it in the x-264 format in a .264 file without any multiplexing (raw h264 stream) so I can decode and process it later. I have an h264 stream from the h264 reference encoder so it must be h264 compatible. I have made sure it does have SEI messages in it. However, it doesnt have SPS/PPS messages since it needs to be compatible with the baseline profile of h264. I thought (from your earlier mail) that setting the property "config-interval" should solve my problem but it hasnt. Obviously! Since I HAVE no SPS/PPS in my stream. Also, I need a raw .264 file at the output to evaluate and decode using another decoder element, not part of gstreamer. That's why I dont care about muxing it into a file format like mp4 and avi. Yet, I tried that. I see that there is no muxer for h264 files (ffmux_ipod also tries to mux the stream as an mpegts stream if I am right). Still, I tried using avimux/mp4mux to mux the stream into avi/mp4 container. I get this error: ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: Internal data flow error. Additional debug info: gstbasesrc.c(2543): gst_base_src_loop (): /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: streaming task paused, reason not-negotiated (-4) Execution ended after 3772400353 ns. I think this is because the incoming stream from udpsrc does not have mp4 hint information or other SPS/PPS information it is supposed to have. Of that, I cant seem to find a solution. I think the crux of my problem is that I am using an external encoder. That is why 'h264parse' gives me no "codec-data" field in caps as expected from the sender side. Only this: /GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:src: caps = video/x-h264, stream-format=(string)byte-stream As a result, I dont have a suitable value to set in the "codec-data" field in the receiver capsfilter I put between depayloader and filesink. You think I understand it right? There is something that can be done to solve this? ________________________________ From: Marco Ballesio [via GStreamer-devel] <ml-...@n4...> To: Farah <far...@ya...> Sent: Sat, June 12, 2010 1:00:28 AM Subject: Re: Using gstreamer to transmit H264 file over RTP Hi, as I pointed out in the previous mail (I'm sorry if I've not been clear enough) you need to explicitly set the codec_data parameter in the receiving side caps. I also suggest you to mux the depayloaded h264 (even if you're using annex B it's not a container format, only a codec). The easiest way is to put the muxer between the h264 depayloader and the filesink. Regards On Sun, Jun 6, 2010 at 6:56 AM, Farah <[hidden email]> wrote: > > > Another update, just so you know! > > I even updated my system to the latest gstreamer releases 0.10.29 from this > ppa: > > https://launchpad.net/~gstreamer-developers/+archive/ppa > > That hasnt changed the situation much and that worries me more. This means > that it may not actually be a gstreamer bug. Please help! > > Thanks. > > Farah Akhtar. > -- > View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Using-gstreamer-to-transmit-H264-file-over-RTP-tp2236364p2244738.html?by-user=t > Sent from the GStreamer-devel mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel ________________________________ View message @ http://gstreamer-devel.966125.n4.nabble.com/Using-gstreamer-to-transmit-H264-file-over-RTP-tp2236364p2252222.html To unsubscribe from Re: Using gstreamer to transmit H264 file over RTP, click here. -- View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Using-gstreamer-to-transmit-H264-file-over-RTP-tp2236364p2252445.html Sent from the GStreamer-devel mailing list archive at Nabble.com. |
From: Farah <far...@ya...> - 2010-06-12 00:51:30
|
Also, I thought to ask you... If I try and multiplex this h264 file into an mp4 using some other tool like mp4box etc. , then you think it should help? I have tried doing that but there are errors. I think I'll still have to use rtph264pay/depay and muxers, so I dint invest too much time in it. ________________________________ From: Marco Ballesio [via GStreamer-devel] <ml-...@n4...> To: Farah <far...@ya...> Sent: Sat, June 12, 2010 1:00:28 AM Subject: Re: Using gstreamer to transmit H264 file over RTP Hi, as I pointed out in the previous mail (I'm sorry if I've not been clear enough) you need to explicitly set the codec_data parameter in the receiving side caps. I also suggest you to mux the depayloaded h264 (even if you're using annex B it's not a container format, only a codec). The easiest way is to put the muxer between the h264 depayloader and the filesink. Regards On Sun, Jun 6, 2010 at 6:56 AM, Farah <[hidden email]> wrote: > > > Another update, just so you know! > > I even updated my system to the latest gstreamer releases 0.10.29 from this > ppa: > > https://launchpad.net/~gstreamer-developers/+archive/ppa > > That hasnt changed the situation much and that worries me more. This means > that it may not actually be a gstreamer bug. Please help! > > Thanks. > > Farah Akhtar. > -- > View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Using-gstreamer-to-transmit-H264-file-over-RTP-tp2236364p2244738.html?by-user=t > Sent from the GStreamer-devel mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel ________________________________ View message @ http://gstreamer-devel.966125.n4.nabble.com/Using-gstreamer-to-transmit-H264-file-over-RTP-tp2236364p2252222.html To unsubscribe from Re: Using gstreamer to transmit H264 file over RTP, click here. -- View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Using-gstreamer-to-transmit-H264-file-over-RTP-tp2236364p2252448.html Sent from the GStreamer-devel mailing list archive at Nabble.com. |
From: Marc L. <mar...@gm...> - 2010-06-11 20:19:06
|
> as I pointed out in the previous mail (I'm sorry if I've not been > clear enough) you need to explicitly set the codec_data parameter in > the receiving side caps. No, this is no longer required. If you order the rtp payloader to remultiplex the config data in the stream; you are fine (config-interval). IIRC, the version of the good plugins mentioned above has a bug that basically makes the config-interval inert. You should have the latest release for this (tested and verified, 0.10.23). We are currently working on patches to re-multiplex these parameters in the ES without going through RTP; but the bottom line would be the same (patches are in bugzilla). With these patches and using the config-interval parameter will allow you to stream mpeg4 and h264 in rtp, es, ts/es or rtp/ts and still be able to pick in on the stream at any arbitrary moment. -- greetz, marc God made the integers; all else is the work of Man. -- Kronecker crichton 2.6.26 #1 PREEMPT Tue Jul 29 21:17:59 CDT 2008 GNU/Linux |
From: Marc L. <mar...@gm...> - 2010-06-11 20:49:37
|
> We are currently working on patches to re-multiplex these parameters in > the ES without going through RTP; but the bottom line would be the same > (patches are in bugzilla). The functionality is in the parser elements (mpeg4videoparse; h264parse). -- greetz, marc The aim of science is to seek the simplest explanations of complex facts. Seek simplicity and distrust it. -- Whitehead. crichton 2.6.26 #1 PREEMPT Tue Jul 29 21:17:59 CDT 2008 GNU/Linux |
From: Farah <far...@ya...> - 2010-06-12 01:55:30
|
One correction: I rechecked. My stream does have SPS/PPS information necessary for the h264 baseline profile. No, this is no longer required. If you order the rtp payloader to remultiplex the config data in the stream; you are fine (config-interval). IIRC, the version of the good plugins mentioned above has a bug that basically makes the config-interval inert. You should have the latest release for this (tested and verified, 0.10.23). >> I do have the latest release (0.10.23-4) and I add config-interval=1. >> Still, it makes no difference. I also add h264parse between the >> rtph264depay and filesink. Do I have to add those patches you mention >> below? You see, I already passing the caps from sender to receiver. >> Shouldnt that solve the problem? If only I knew why h264parse doesnt give a 'codec-data' field in caps using this file while it does give them when I encode a raw yuv file using x264enc. -- View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Using-gstreamer-to-transmit-H264-file-over-RTP-tp2236364p2252463.html Sent from the GStreamer-devel mailing list archive at Nabble.com. |
From: Farah <far...@ya...> - 2010-06-12 08:22:33
|
Ok, there are things in my previous posts that are misleading so I thought to correct them. I checked my h264 file and it seemed the encoder configuration that I had used did add SPS/PPS information but only the one required for h264 baseline profile. This one had only one IDR picture and SPS information was sent for IDR picture only. Now, I tried several other encoder configurations with different frequency of SPS/PPS information. I tried a file that resends PPS for every coded Frame/Field pair. This has resulted in better looking video with no noise artifacts on the picture. However, it still loses last several packets but ONLY AT THE END of the file. The last second or so of the file doesnt play. I am also using another machine with all the same software but it is a slower machine. There, loss is less and almost the whole file gets transmitted especially if I use config-interval=1 (the smallest value). However, the last several bytes are still not stored. May be, this has something to do with how frequently the SPS/PPS info gets multiplexed in the stream. I still have to end the receiver pipeline with an interrupt. I hope you have something to say about this. -- View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Using-gstreamer-to-transmit-H264-file-over-RTP-tp2236364p2252566.html Sent from the GStreamer-devel mailing list archive at Nabble.com. |
From: Marco B. <gib...@gm...> - 2010-06-29 03:23:43
|
Hi, sorry for replying so late, I hope this will help.. On Sat, Jun 12, 2010 at 11:22 AM, Farah <far...@ya...> wrote: > > > Ok, there are things in my previous posts that are misleading so I thought > to correct them. > > I checked my h264 file and it seemed the encoder configuration that I had > used did add SPS/PPS information but only the one required for h264 baseline > profile. This one had only one IDR picture and SPS information was sent for > IDR picture only. Now, I tried several other encoder configurations with > different frequency of SPS/PPS information. I tried a file that resends PPS > for every coded Frame/Field pair. I don't exactly know how your encoder is working, but this may mean you're re-sending a key frame each time. > This has resulted in better looking video > with no noise artifacts on the picture. However, it still loses last several > packets but ONLY AT THE END of the file. The last second or so of the file > doesnt play. I know you already made this check previously, but was the received file truncated? > > I am also using another machine with all the same software but it is a > slower machine. There, loss is less and almost the whole file gets > transmitted especially if I use config-interval=1 (the smallest value). > However, the last several bytes are still not stored. looks like this is replying to my former question, but maybe you can explicitly confirm. > May be, this has > something to do with how frequently the SPS/PPS info gets multiplexed in the > stream. I still have to end the receiver pipeline with an interrupt. I suggest you to try and terminate it nicely from an application as explained in: http://www.gstreamer.net/data/doc/gstreamer/head/manual/html/chapter-helloworld.html To build a gst-launch style pipeline in your C application, use the following: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstParse.html#gst-parse-launch Indeed you won't get an EOS here, but maybe you can simply terminate the g_main_loop after a stdin event (e.g. pressing "ENTER"). More evolved methods based on probes and I/O stats are still possible but imho useless so far. Regards. > > I hope you have something to say about this. > > > -- > View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Using-gstreamer-to-transmit-H264-file-over-RTP-tp2236364p2252566.html > Sent from the GStreamer-devel mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > gstreamer-devel mailing list > gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > |