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 731206 - shmsrc: 64bit system has problems with timestamps
shmsrc: 64bit system has problems with timestamps
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins
1.2.4
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-06-04 13:37 UTC by Krzysztof Borowczyk
Modified: 2014-06-06 19:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
timestamp error log with scheduling debug info (545.89 KB, application/octet-stream)
2014-06-06 10:21 UTC, Krzysztof Borowczyk
Details

Description Krzysztof Borowczyk 2014-06-04 13:37:08 UTC
Operatig system: Ubuntu 14.04
GStreamer: custom built 1.2.4 release (only difference in code is application of 2-line fix for bug 702842)

The test commands are:

1. The video source:
/rtcs/bin/gst-launch-1.0 filesrc location=~/Downloads/big_buck_bunny_720p_surround.avi ! decodebin ! shmsink socket-path=/tmp/gstShm shm-size=10000000 max-lateness=1

2. The encoding part (which fails):
/rtcs/bin/gst-launch-1.0 shmsrc socket-path=/tmp/gstShm is-live=true do-timestamp=true ! "video/x-raw, format=I420, width=1280, height=720, pixel-aspect-ratio=1/1, interlace-mode=progressive, colorimetry=bt709, framerate=5000000/208333" ! avenc_flv ! flvmux streamable=true ! rtmpsink location="rtmp://192.168.0.2/oflaDemo/stream live=1"


What fails?
avenc_flv does not encode video and complains about wrong timestamps (which are generated by shmsrc):

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
0:00:00.051209180  7988       0xec29e0 FIXME                default gstutils.c:3648:gst_pad_create_stream_id_printf_valist:<shmsrc0:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id
Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:00:00.062946317  7988       0xec29e0 FIXME               basesink gstbasesink.c:3022:gst_base_sink_default_event:<rtmpsink0> stream-start event without group-id. Consider implementing group-id handling in the upstream elements
0:00:00.190466700  7988       0xec29e0 ERROR                  libav :0:: Error, Invalid timestamp=3, last=3
0:00:00.190541565  7988       0xec29e0 ERROR                  libav gstavvidenc.c:655:gst_ffmpegvidenc_handle_frame:<avenc_flv0> avenc_flv: failed to encode buffer
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:00:06.217776854
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
Comment 1 Olivier Crête 2014-06-04 19:16:21 UTC
This works fine with git master for me. 
I assume the bug was fixed somewhere else...
Comment 2 Krzysztof Borowczyk 2014-06-05 13:44:25 UTC
Currently I cannot retest with git version (I have git port blocked on company's firewall, waiting for unblocking), but I did the test on 1.3.2 release and I can confirm, that the bug is still there - I get the "failed to encode buffer" errors.

In both cases (1.2.4, 1.3.2) I get logs from red5 server, that the stream is published, but I can't fetch it for playback.
Comment 3 Nicolas Dufresne (ndufresne) 2014-06-05 14:43:21 UTC
(In reply to comment #2)
> Currently I cannot retest with git version (I have git port blocked on
> company's firewall, waiting for unblocking), but I did the test on 1.3.2
> release and I can confirm, that the bug is still there - I get the "failed to
> encode buffer" errors.
> 
> In both cases (1.2.4, 1.3.2) I get logs from red5 server, that the stream is
> published, but I can't fetch it for playback.

Yes, the same reason why our server also serve git through HTTP ;-P

http://anongit.freedesktop.org/git/gstreamer/gst*.git
Comment 4 Olivier Crête 2014-06-05 19:49:50 UTC
Btw, can you do a log with GST_DEBUG=GST_SCHEDULING:6, that will print the timestamp of every buffer. That said, for you use-case, using the timestamps from shmsrc is probably not what you want. You probably want to use videoparse to set timestamps based on the framerate.
Comment 5 Krzysztof Borowczyk 2014-06-06 10:21:45 UTC
Created attachment 278006 [details]
timestamp error log with scheduling debug info
Comment 6 Krzysztof Borowczyk 2014-06-06 10:23:49 UTC
@Nicolas - thanks for the link, it helped much ;)
(although, the .gitmodules has git: links, so autogen.sh fails by default)


@Oliver - are you sure you tested in the 64bit environment?
I compiled the git version (gstreamer, plugins-base, good, bad, libav) and still have the timestamp / encoding error. I attached the log in comment 5 (sorry, i tried to link it with this comment, but somehow it didn't work ;) )

I noticed that sometimes the playback from red5 works, even with those errors.
The videoparse that you suggested helps with the errors and encoding - thanks, that will solve my problem.

If you need more info to track this timestamp problem, I will try to provide whatever I can.
Comment 7 Olivier Crête 2014-06-06 19:24:50 UTC
This isn't shmsrc's fault. You're telling avenc_flv that you will have a fixed framerate, but you don't really because shmsinkl/shmsink don't carry timestamp information. You should probably instead add a videorate to force a fixed framerate, something like:

shmsrc socket-path=/tmp/gstShm is-live=true
do-timestamp=true ! "video/x-raw, format=I420, width=1280, height=720,
pixel-aspect-ratio=1/1, interlace-mode=progressive, colorimetry=bt709,
framerate=5000000/208333" ! videorate ! avenc_flv ! flvmux streamable=true ! rtmpsink
location="rtmp://192.168.0.2/oflaDemo/stream live=1"
Comment 8 Olivier Crête 2014-06-06 19:26:59 UTC
Or if you want to assume that no frames are lost, you can videoparse too as you certain to never lose a frame.