Re: FluTSmux performance

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: FluTSmux performance

arnabsamanta
gstreamer-devel Digest, Vol 36, Issue 64

Hi Favila,

I am not sure of  flutsmux / flutsdemux element for streaming but please let me put forward my understanding to find the problem.

About the performance of the fluts muxer / demuxer....,

Data in the receiver side is corrupted and one possible reason for this could be that the output from either the muxer or the demuxer is corrupted. In this case you can bit-wise compare the input file and the output file.

1.On the sender side,  dump the file after encoder using filesink. This becomes your input file.

2. On the receiver side , dump the file after demuxer. This becomes your output file. 

3.  Compare the files and see if the two files are bit exact. 

About the pipelines.....

I could see the absence of packetiser in your pipeline. Is the fluts muxer /demuxer internally handles the packetisation / depacketisation  ? In case its Not handling , my understanding is its better to use the packetiser , even though a frame can directly be streamed, provided the size is much smaller.

In this case, the pipeline could be some what like this ....

Sender : src ! caps ! encoder ! queue ! xxmuxer ! xxparser ! xxpay ! n/wsink

Receiver : n/wsrc ! queue ! xxdemuxer ! xxdepay ! bin.

where, xx is the container format.

when you are streaming using packetiser with no muxer , you are actually streaming the elementary streams and in case you are using a muxer , you are sending data in a container format. And both these scenarios are different.

  Hope this has been of little help to you.

Regards,

Arnab.

 

 

The information contained in this electronic message and any attachments to this message are intended for the exclusive 
use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended
 recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy
 all copies of this message and any attachments contained in it.


------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: FluTSmux performance

Favila Deba

    Hello and thanks for your help. I really need to overcome this problem.

    I have tried with the parser element  (mpegtsparse) and with the rtpmp2tpay/rtpmp2tdepay elements but it does not improve.

    File after the encoder in the sender and file after the demuxer in the receiver part are not identical, but should they be identical bitwise? But they are pretty similar files, it is hard to compare but maybe only first headers are differents. 

    One more annoying/curious thing. If I do this:
        sender: videosrc ! x264enc ! queue ! flutsmux ! udpsink host=192.168.0.2 port=8000
        receiver: gst-launch-0.10 udpsrc port=8000 ! queue ! filesink location=test.ts
and I play the file (vlc test.ts), it plays perfectly!!!!!!!!!!!!!!! ???????????????????, but if I try to play it alive, it is a mess!!! (and the CPU load is not a problem at all) (using: gst-launch-0.10 udpsrc port=8434 ! queue ! flutsdemux ! 'video/x-h264,width=640,height=480' ! decodebin ! xvimagesink).

    I am completely lost with this!  ;-)

    Thank you very much.
    All the best.
    Favila.

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: FluTSmux performance

Wim Taymans
On Wed, 2009-05-20 at 11:54 +0200, Favila Deba wrote:

>
>     Hello and thanks for your help. I really need to overcome this
> problem.
>
>     I have tried with the parser element  (mpegtsparse) and with the
> rtpmp2tpay/rtpmp2tdepay elements but it does not improve.
>
>     File after the encoder in the sender and file after the demuxer in
> the receiver part are not identical, but should they be identical
> bitwise? But they are pretty similar files, it is hard to compare but
> maybe only first headers are differents.  
>
>     One more annoying/curious thing. If I do this:
>         sender: videosrc ! x264enc ! queue ! flutsmux ! udpsink
> host=192.168.0.2 port=8000
>         receiver: gst-launch-0.10 udpsrc port=8000 ! queue ! filesink
> location=test.ts
> and I play the file (vlc test.ts), it plays
> perfectly!!!!!!!!!!!!!!! ???????????????????, but if I try to play it
> alive, it is a mess!!! (and the CPU load is not a problem at all)
> (using: gst-launch-0.10 udpsrc port=8434 ! queue ! flutsdemux !
> 'video/x-h264,width=640,height=480' ! decodebin ! xvimagesink).
>

You need a queue in that pipeline (before xvimagesink). This works fine
for me:

gst-launch-0.10 udpsrc port=8434 ! mpegtsdemux ! queue ! ffdec_h264 !
xvimagesink

Wim


>     I am completely lost with this!  ;-)
>
>     Thank you very much.
>     All the best.
>     Favila.
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
> _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel


------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: FluTSmux performance

Favila Deba

    Hi Wim, thank you very much.

    You are right ... just a simple queue ... >:o

    Would you mind to read a new post that I have written an hour ago named "Flutsmux wrong TS headers?". Even with the queue, the flutsdemux at the receiver reports errors, and also the error can be displayed when you analyze with wireshark the sender output flow.

    If it is a bug in the flutsmux element, how should I fix it? (I am using gst-fluendo-mpegmux version 0.10.4).

    Thank you very much! I really appreciate your help.
    All the best.
    Favila.


Wim Taymans wrote:
On Wed, 2009-05-20 at 11:54 +0200, Favila Deba wrote:
  
    Hello and thanks for your help. I really need to overcome this
problem.

    I have tried with the parser element  (mpegtsparse) and with the
rtpmp2tpay/rtpmp2tdepay elements but it does not improve.

    File after the encoder in the sender and file after the demuxer in
the receiver part are not identical, but should they be identical
bitwise? But they are pretty similar files, it is hard to compare but
maybe only first headers are differents.  

    One more annoying/curious thing. If I do this:
        sender: videosrc ! x264enc ! queue ! flutsmux ! udpsink
host=192.168.0.2 port=8000
        receiver: gst-launch-0.10 udpsrc port=8000 ! queue ! filesink
location=test.ts
and I play the file (vlc test.ts), it plays
perfectly!!!!!!!!!!!!!!! ???????????????????, but if I try to play it
alive, it is a mess!!! (and the CPU load is not a problem at all)
(using: gst-launch-0.10 udpsrc port=8434 ! queue ! flutsdemux !
'video/x-h264,width=640,height=480' ! decodebin ! xvimagesink).

    

You need a queue in that pipeline (before xvimagesink). This works fine
for me:

gst-launch-0.10 udpsrc port=8434 ! mpegtsdemux ! queue ! ffdec_h264 !
xvimagesink

Wim


  
    I am completely lost with this!  ;-) 

    Thank you very much.
    All the best.
    Favila.
------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
    


------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
  


------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel