After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 604394 - unable to create playable media using tcpclientsrc and tcpserversrc filters
unable to create playable media using tcpclientsrc and tcpserversrc filters
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.25
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-12-11 20:56 UTC by rrp702
Modified: 2010-01-27 10:46 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description rrp702 2009-12-11 20:56:06 UTC
Client: gst-launch-0.10 tcpclientsrc port=5000 protocol=1 ! videoscale ! 'video/x-raw-yuv,width=352,height=288' ! videorate ! 'video/x-raw-yuv,framerate=18/1' ! queue ! x264enc byte-stream=true bitrate=200 subme=6 ! matroskamux

Server: gst-launch-0.10 filesrc location=GranTorino2008.avi ! avidemux name=demux demux.video_00 ! xviddec ! ffmpegcolorspace ! video/x-raw-yuv,format=\(fourcc\)I420 ! tcpserversink port=5000 protocol=1


1. if i play the .mkv file using mplayer it will show the 1st frame only for throughout the file duration.

2. But if i remove videoscale and videorate from the pipeline the mkv file becomes perfectly playable. 

3. Also if i modify the client side pipeline to :
gst-launch-0.10 tcpclientsrc do-timestamp=true port=5000 protocol=1 ! queue ! ffmpegcolorspace ! video/x-raw-yuv,format=\(fourcc\)I420 ! videorate ! 'video/x-raw-yuv,framerate=18/1' ! queue ! x264enc byte-stream=true bitrate=200 subme=6 key-int-max=90 ! matroskamux ! filesink location=test.mkv
the file is again playable.
Comment 1 Wim Taymans 2010-01-27 10:46:00 UTC
The reason is because the data you receive in the client is timestamped according to the clock and time base of the sender. You can check this with:

 gst-launch-0.10 tcpclientsrc port=5000 protocol=1 ! fakesink -v

You'll see that timestamps don't start from 0, which makes videorate duplicate the first frame multiple times.

Setting do-timestamp=true does nothing AFAICS to the timestamps so I'm a bit surprised that it generates something useful. Maybe you just started the client sooner...

In general, avoid using videorate in this case.

I'm going to close this, please reopen if this is totally unsatisfactory for you.