Closed GoogleCodeExporter closed 9 years ago
Is this on a fresh compile from the trunk or one of the featured downloads?
Original comment by david.g.hoyt
on 1 Dec 2009 at 7:44
This happens in both the fresh compile and in the GStreamerWinBuild-0.10.4.exe.
Good to hear someone is looking into this!
The fresh compile is a few days old - it contains the changes regarding the
separation of ffmpeg components is their own dlls - like avformat-gpl-52.dll...
I am sorry to say it, but this makes the current version of gstreamer unusable
for
receiving h264. I can do the 'receiving' using an old version of oabuild. I
tried a
lot of things, including bringing the old ffmpeg plugin from oabuild into
ossbuild.
It works as well only for a few minutes (2-15...). Although the crash happens
in the
ffmpeg plugin, I suspect something may be wrong with rtph264depay, but I don't
know
what else I could do.
Original comment by ddrago...@gmail.com
on 1 Dec 2009 at 2:21
I'll look into this ASAP.
Original comment by david.g.hoyt
on 1 Dec 2009 at 7:43
Original comment by david.g.hoyt
on 1 Dec 2009 at 7:44
I ran the following pipeline without a problem:
gst-launch-0.10.exe --gst-plugin-path=plugins videotestsrc ! ffmpegcolorspace !
x264enc bitrate=300 bytestream=true ! rtph264pay ! rtph264depay ! ffdec_h264 !
ffmpegcolorspace ! autovideosink
This pipeline ran, but I didn't get anything on the screen (it exited
immediately)
and no crashes:
gst-launch-0.10.exe --gst-plugin-path=plugins videotestsrc ! ffmpegcolorspace !
x264enc bitrate=300 ! rtph264pay ! rtph264depay ! ffdec_h264 ! ffmpegcolorspace
!
glimagesink sync=false
Could it be a problem with ksvideosrc or the video being output by your device
(camera)? It may end up being a problem with the gstreamer code and not our
build in
which case you'll need to submit a patch to the gstreamer folks.
Original comment by david.g.hoyt
on 1 Dec 2009 at 8:28
Let me know if one of the following pipeplines works (adjust as needed for your
setup):
gst-launch-0.10.exe --gst-plugin-path=plugins -v ksvideosrc do-stats=TRUE !
ffmpegcolorspace ! autovideosink
or
gst-launch-0.10.exe --gst-plugin-path=plugins -v ksvideosrc do-stats=TRUE !
image/jpeg, width=640, height=480 ! jpegdec ! ffmpegcolorspace ! autovideosink
Original comment by david.g.hoyt
on 1 Dec 2009 at 8:42
1) My x264 does not have the bytestream=true property. It would be easy if this
was a
versioning issue. Actually I replaced the relevant plugins/dlls from
"GStreamerWinBuild-0.10.4.exe" with the newly compiled ones.
However that pipe (the one with bytestream=true) STARTS working for me without
bytestream=true.
If I use x264 for encoding it never crashes, so it shouldn't be a versioning
issue.
Remember that initially I said that
gst-launch-0.10.exe --gst-plugin-path=. ksvideosrc ! ffmpegcolorspace !
x264enc bitrate=300 ! ffdec_h264 ! ffmpegcolorspace ! glimagesink sync=false
WORKS FINE (for more than one hour)!!!
2) gst-launch-0.10.exe --gst-plugin-path=plugins videotestsrc !
ffmpegcolorspace !
x264enc bitrate=300 ! rtph264pay ! rtph264depay ! ffdec_h264 ! ffmpegcolorspace
!
glimagesink sync=false
crashes
3) gst-launch-0.10.exe --gst-plugin-path=plugins -v ksvideosrc do-stats=TRUE !
ffmpegcolorspace ! autovideosink
works fine
gst-launch-0.10.exe --gst-plugin-path=plugins -v ksvideosrc do-stats=TRUE !
image/jpeg, width=640, height=480 ! jpegdec ! ffmpegcolorspace ! autovideosink
does not start - it says to check my filter caps.
Original comment by ddrago...@gmail.com
on 2 Dec 2009 at 12:04
Yes, take out bytestream=true -- sorry about that -- I found a reference on a
website
to a problem similar to yours and that was suggested, but it appears to have be
deleted in later versions (I checked the source and that property no longer
exists).
I copied the wrong pipeline into my comment -- you did what I intended by
taking out
bytestream=true.
I would make sure you're using entirely the latest builds. You should uninstall
GStreamerWinBuild-0.10.4 completely and make sure the GST_PLUGIN_PATH env. var.
isn't
defined on your machine. Then re-run all the pipelines.
It's difficult to track down the bug if you're using a potential mix of old/new
dlls.
Original comment by david.g.hoyt
on 2 Dec 2009 at 7:11
OK, I'll use ALL the latest builds.
I did not use GStreamerWinBuild-0.10.4 directly. I got rid of the
GST_PLUGIN_PATH
environment variable and the system PATH that included the gstreamer 'bin'
directory.
I copied all the exe's and dll's in one directory - flat structure. This is how
I can
run multiple versions on the same machine. When necessary I deleted the
'.gstreamer-0.10' directory as well and re-registered the plugins (until
gst-inspect
reported the correct thing).
But considering my current environment, how do you explain that the following
pipe
works without crashing:
gst-launch-0.10.exe --gst-plugin-path=. ksvideosrc ! ffmpegcolorspace !
x264enc bitrate=300 ! ffdec_h264 ! ffmpegcolorspace ! glimagesink sync=false
?
It crashes only when I add '!rtph264pay ! rtph264depay'.
If you have a version that does not crash with '!rtph264pay ! rtph264depay',
could
you make a 'zip' (somewhere I can download it) with the flat structure so I can
test
it directly? Or e-mail it to me?
Original comment by ddrago...@gmail.com
on 2 Dec 2009 at 11:55
That doesn't *guarantee* you're using the latest (although, admittedly, you
most
likely are). The system could find one of the dependencies (e.g. libbz2.dll)
somewhere other than the executable's directory because it's in the system path.
The thought is that ksvideosrc is passing up something that the rtp elements
don't
like or is causing the other elements to create something that the rtp elements
don't like. So the bug could be in either the rtp code or the ksvideosrc or any
one
of the elements in the pipeline.
I don't have a camera from which I can test this and pinpoint the problem.
Anyone of
the other devs have one and could help?
Original comment by david.g.hoyt
on 2 Dec 2009 at 10:36
I suppose I should ammend my comment -- Windows will search the executable's
directory before the system path. So you're most likely using the correct
versions.
Original comment by david.g.hoyt
on 2 Dec 2009 at 10:44
I have 2 cameras - Logitech Pro for Notebooks and Pro 9000.
But the pipe crashes even with videotestsrc! So the camera should be irrelevant
in
this case.
Original comment by ddrago...@gmail.com
on 3 Dec 2009 at 1:06
Mine's not crashing on the videotestsrc. So let's sync up -- I uploaded a beta
version of the new installer for v0.10.5 to the downloads section (it's missing
python bindings, dev libs, and farsight2 plugins). Please install it and let me
know
if it continues to crash.
What version of Windows are you running this on, btw? I'm testing on WinXP.
Original comment by david.g.hoyt
on 3 Dec 2009 at 7:57
I installed v0.10.5 and ran:
gst-launch-0.10.exe videotestsrc ! ffmpegcolorspace ! x264enc bitrate=300 !
rtph264pay ! rtph264depay ! ffdec_h264 ! ffmpegcolorspace ! glimagesink
sync=false
It crashes in about 1-2 minutes in module avcodec-
6E9BFA7E 8B01 MOV EAX,DWORD PTR DS:[ECX]
DS:[032BEFFF]=???
EAX=AEF9B344
I have XP [Version 5.1.2600].
P.S. This version uses more of the processor.
Original comment by ddrago...@gmail.com
on 3 Dec 2009 at 1:52
Update: I tried the pipe on another machine and it worked fine for more than 15
minutes - I stopped it at that time. I tried a more complex receiving pipe and
it
also worked fine for 15 min. It is actually a slower Intel Celeron 2.4GHz.
Maybe it crashes if I try longer, or maybe it has something to do with the AMD
processor in my first machine.
By the way, the new version gave me an error on multiudpsink:
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
ERROR: from element /GstPipeline:pipeline0/GstMultiUDPSink:multiudpsink0: Could
not get/set settings from/on resource.
Additional debug info:
..\..\..\Source\gst-plugins-good\gst\udp\gstmultiudpsink.c(790): gst_multiudpsin
k_init_send (): /GstPipeline:pipeline0/GstMultiUDPSink:multiudpsink0:
Original comment by ddrago...@gmail.com
on 3 Dec 2009 at 8:56
Continuation... it crashed on the Intel machine too after more than 20-25 min...
Original comment by ddrago...@gmail.com
on 3 Dec 2009 at 9:13
Let's continue this using the forums:
http://ossbuild.hoytsoft.org/forums/yaf_postsm26_rtph264payrtph264depay-crash.as
px
Please see my comment there.
Original comment by david.g.hoyt
on 3 Dec 2009 at 9:29
I have been trying to take a look a this issue the past week, but I did not find
time... I will retry this week. BTW, can you please reset my forum's password?
(once
more ;) )
Original comment by ylatuya
on 4 Dec 2009 at 12:22
Let's bring ffmpeg (libavcodec...) into ossbuild the same way it was in
oabuild. So
that it could be debugged easier.
Original comment by ddrago...@gmail.com
on 8 Dec 2009 at 1:39
Should be fixed in trunk. Please see SVN r759.
Original comment by david.g.hoyt
on 20 Jul 2010 at 12:05
I checked out r760. I compiled it successfully. I took libx264-104.dll and
libgstx264.dll and put it on top of the release "GStreamer WinBuilds 0.10.6
(GPL)" (I deleted the old dlls). Issue 43 with the x264 incorrect header is
fixed, but it still crashes in XP. You may not agree with my testing procedure
mixing the releases, but I still think the test is valid.
Original comment by ddrago...@gmail.com
on 20 Jul 2010 at 2:18
There are significant changes b/t 0.10.6 and svn trunk (two entire gstreamer
releases, actually). I did not test it extensively on XP, but Windows 7 seemed
happy with it.
If it's still having problems, I'll reopen this.
Original comment by david.g.hoyt
on 20 Jul 2010 at 3:17
OK, I removed "GStreamer WinBuilds 0.10.6 (GPL)" and changed ENV variables to:
GST_PLUGIN_PATH=C:\ossbuild\Build\Windows\Win32\Release\bin\plugins
Path=C:\ossbuild\Shared\Build\Windows\Win32\bin;C:\ossbuild\Build\Windows\Win32\
Release\bin;...
It still crashes after a few seconds (less than 1 minute).
P.S. Even previous versions ran with no crashes in Win 7 64 bits.
Original comment by ddrago...@gmail.com
on 20 Jul 2010 at 5:29
One of our oldest issues seems to be finally resolved. Please checkout and
build the latest from the repo. (trunk) to see if this has been fixed. I've
been running the following pipeline now for a couple of hours with no hiccups:
gst-launch videotestsrc ! ffmpegcolorspace ! x264enc ! rtph264pay !
rtph264depay ! ffdec_h264 ! ffmpegcolorspace ! autovideosink
If it's still not resolved, please let me know and I'll reopen the issue.
Original comment by david.g.hoyt
on 23 Sep 2010 at 10:08
Hi, I have the same exact issue, the problem is not reproducible when running
the pipeline in gdb (rtspsrc .. ! decodebin ! ffmpegcolorspace ! d3dvideosink)
however when running in gdb I have the warning attacched, I can give an public
url to an axis camera to reproduce the issue
Original comment by drakkan1...@gmail.com
on 6 Oct 2010 at 9:01
Attachments:
please note that I haven't the warning (image above) when running outside gdb
(I have the crash) so maybe the warning in gdb are related to the crash outside
gdb
Original comment by drakkan1...@gmail.com
on 6 Oct 2010 at 9:06
Can you attach it to the Visual Studio debugger too?
Original comment by ylatuya
on 6 Oct 2010 at 9:41
Does this happen only in XP or also in Vista or Win7?
Original comment by ddrago...@gmail.com
on 6 Oct 2010 at 10:27
Here is the stack trace from visual studio debugger:
avcodec-lgpl-52.dll!626da287()
[I frame indicati di seguito possono essere errati e/o mancanti, non sono stati caricati simboli per avcodec-lgpl-52.dll]
avcodec-lgpl-52.dll!626da3c8()
> libgstreamer-0.10.dll!gst_pad_chain_data_unchecked(_GstPad * pad=0x01baf9ac,
int is_buffer=31058744, void * data=0x000014c6) Riga 4204 + 0x9 byte C
01baf9b4()
libglib-2.0-0.dll!68612c89()
libgstreamer-0.10.dll!gst_pad_chain_data_unchecked(_GstPad * pad=0x00b628b0, int is_buffer=1, void * data=0x00b22b68) Riga 4182 + 0x7 byte C
libgstreamer-0.10.dll!gst_pad_push_data(_GstPad * pad=0x00b627e8, int is_buffer=1, void * data=0x00b22b68) Riga 4411 + 0x12 byte C
libgstreamer-0.10.dll!gst_pad_push(_GstPad * pad=0x00b627e8, _GstBuffer * buffer=0x00b22b68) Riga 4515 + 0x9 byte C
libgstrtp-0.10.dll!gst_base_rtp_depayload_push_full(_GstBaseRTPDepayload * filter=0x00000000, int do_ts=1, unsigned int rtptime=796324692, _GstBuffer * out_buf=0x00b22b68) Riga 527 + 0xd byte C
libgstrtp-0.10.dll!gst_base_rtp_depayload_chain(_GstPad * pad=0x00b62720, _GstBuffer * in=0x00b61db8) Riga 350 + 0xb byte C
libgstreamer-0.10.dll!gst_pad_chain_data_unchecked(_GstPad * pad=0x00b62720, int is_buffer=1, void * data=0x00b61db8) Riga 4182 + 0x7 byte C
libgstreamer-0.10.dll!gst_pad_push_data(_GstPad * pad=0x00afb0d8, int is_buffer=1, void * data=0x00b61db8) Riga 4411 + 0x12 byte C
libgstreamer-0.10.dll!gst_pad_push(_GstPad * pad=0x00afb0d8, _GstBuffer * buffer=0x00b61db8) Riga 4515 + 0x9 byte C
libgstcoreelements.dll!gst_type_find_element_chain(_GstPad * pad=0x00afb010, _GstBuffer * buffer=0x00b61db8) Riga 765 + 0xd byte C
libgstreamer-0.10.dll!gst_pad_chain_data_unchecked(_GstPad * pad=0x00afb010, int is_buffer=1, void * data=0x00b61db8) Riga 4182 + 0x7 byte C
libgstreamer-0.10.dll!gst_pad_push_data(_GstPad * pad=0x00afd058, int is_buffer=1, void * data=0x00b61db8) Riga 4411 + 0x12 byte C
libgstreamer-0.10.dll!gst_pad_push(_GstPad * pad=0x00afd058, _GstBuffer * buffer=0x00b61db8) Riga 4515 + 0x9 byte C
libgstreamer-0.10.dll!gst_pad_chain_data_unchecked(_GstPad * pad=0x00afc030, int is_buffer=1, void * data=0x00b61db8) Riga 4182 + 0x7 byte C
libgstreamer-0.10.dll!gst_pad_push_data(_GstPad * pad=0x00afc4b8, int is_buffer=1, void * data=0x00b61db8) Riga 4411 + 0x12 byte C
libgstreamer-0.10.dll!gst_pad_push(_GstPad * pad=0x00afc4b8, _GstBuffer * buffer=0x00b61db8) Riga 4515 + 0x9 byte C
libgstreamer-0.10.dll!gst_pad_chain_data_unchecked(_GstPad * pad=0x00afd490, int is_buffer=1, void * data=0x00b61db8) Riga 4182 + 0x7 byte C
libgstreamer-0.10.dll!gst_pad_push_data(_GstPad * pad=0x00afc3d0, int is_buffer=1, void * data=0x00b61db8) Riga 4411 + 0x12 byte C
libgstreamer-0.10.dll!gst_pad_push(_GstPad * pad=0x00afc3d0, _GstBuffer * buffer=0x00b61db8) Riga 4515 + 0x9 byte C
libgstreamer-0.10.dll!gst_pad_chain_data_unchecked(_GstPad * pad=0x00afd3b8, int is_buffer=1, void * data=0x00b61db8) Riga 4182 + 0x7 byte C
libgstreamer-0.10.dll!gst_pad_push_data(_GstPad * pad=0x00b62658, int is_buffer=1, void * data=0x00b61db8) Riga 4411 + 0x12 byte C
libgstreamer-0.10.dll!gst_pad_push(_GstPad * pad=0x00b62658, _GstBuffer * buffer=0x00b61db8) Riga 4515 + 0x9 byte C
libgstrtpmanager.dll!gst_rtp_pt_demux_chain(_GstPad * pad=0x00b62338, _GstBuffer * buf=0x00b61db8) Riga 387 + 0xb byte C
libgstreamer-0.10.dll!gst_pad_chain_data_unchecked(_GstPad * pad=0x00b62338, int is_buffer=1, void * data=0x00b61db8) Riga 4182 + 0x7 byte C
libgstreamer-0.10.dll!gst_pad_push_data(_GstPad * pad=0x00b621a8, int is_buffer=1, void * data=0x00b61db8) Riga 4411 + 0x12 byte C
libgstreamer-0.10.dll!gst_pad_push(_GstPad * pad=0x00b621a8, _GstBuffer * buffer=0x00b61db8) Riga 4515 + 0x9 byte C
libgstrtpmanager.dll!gst_rtp_jitter_buffer_loop(_GstRtpJitterBuffer * jitterbuffer=0x00b630f8) Riga 1865 + 0xe byte C
libgstreamer-0.10.dll!gst_task_func(_GstTask * task=0x00b73aa8) Riga 273 C
libgstreamer-0.10.dll!default_func(TaskData * tdata=0x00923578, _GstTaskPool * pool=0x00925058) Riga 68 + 0x3 byte C
libglib-2.0-0.dll!686147d9()
libglib-2.0-0.dll!6861290b()
msvcrt.dll!77bfc2de()
libgthread-2.0-0.dll!65c4231a()
msvcrt.dll!77c0a3b0()
kernel32.dll!7c80b729()
visual studio interrupted at
GST_PAD_STREAM_UNLOCK (pad);
Original comment by drakkan1...@gmail.com
on 6 Oct 2010 at 12:02
That's weird... 2 calls before the crash in gst_pad_chan_chain_data_unchecked
we have int is_buffer=31058744, that's supposed to be boolean.
Original comment by ylatuya
on 6 Oct 2010 at 12:10
I reopen the issue
Original comment by ylatuya
on 6 Oct 2010 at 12:10
Can you get the line from where this function is called? It should be in
chain_groups, a recursive call in gst_pad_chain_data_unchecked. Maybe " ret =
gst_pad_chain_data_unchecked (pad, TRUE, gst_buffer_new ());" ?
Original comment by ylatuya
on 6 Oct 2010 at 12:15
The line is actually there "Riga 4204":
libgstreamer-0.10.dll!gst_pad_chain_data_unchecked(_GstPad * pad=0x01baf9ac,
int is_buffer=31058744, void * data=0x000014c6) Riga 4204
I didn't see it before :P
Original comment by ylatuya
on 6 Oct 2010 at 1:31
That's weird:
libgstreamer-0.10.dll!gst_pad_chain_data_unchecked(_GstPad * pad=0x01baf9ac,
int is_buffer=31058744, void * data=0x000014c6) Riga 4204 + 0x9 byte C
libglib-2.0-0.dll!68612c89()
libgstreamer-0.10.dll!gst_pad_chain_data_unchecked(_GstPad * pad=0x00b628b0,
int is_buffer=1, void * data=0x00b22b68) Riga 4182 + 0x7 byte C
is_buffer and the data pointer changes in the same call. I don't know how to
interpret it :(
Original comment by ylatuya
on 6 Oct 2010 at 1:40
this seems to happen only on xp, I cannot reproduce on windows 7
Original comment by drakkan1...@gmail.com
on 6 Oct 2010 at 6:02
So maybe it is a memory allocation issue.
Original comment by ddrago...@gmail.com
on 6 Oct 2010 at 6:18
I've run it for a while on my windows 7 box now using the latest build w/ no
problems. If it's only occurring on windows xp, that's definitely fishy.
Have you tried removing elements one or two at a time to isolate the problem?
Try removing the rtp elements and run that pipeline for a while:
gst-launch videotestsrc ! ffmpegcolorspace ! x264enc ! ffdec_h264 !
ffmpegcolorspace ! dshowvideosink
(I'm using dshowvideosink until ylatuya gets d3dvideosink fixed)
Then try changing the sink to fakesink and see how that does. Then glimagesink,
etc.
Original comment by david.g.hoyt
on 6 Oct 2010 at 8:57
If you all remember my original post: it works OK without
rtph264pay/rtph264depay... but you are welcome to try otherwise :-)
Original comment by ddrago...@gmail.com
on 6 Oct 2010 at 9:28
The issue may not necessarily be w/ the rtp elements, but in negotiation w/
other elements, formats, etc.
Original comment by david.g.hoyt
on 6 Oct 2010 at 9:32
True.
Original comment by ddrago...@gmail.com
on 6 Oct 2010 at 9:42
I cannot reproduce the issue with:
gst-launch videotestsrc ! ffmpegcolorspace ! x264enc ! ffdec_h264 ! ffmpegcolorspace ! dshowvideosink
or
gst-launch videotestsrc ! ffmpegcolorspace ! x264enc ! rtph264pay !
rtph264depay ! ffdec_h264 ! ffmpegcolorspace ! dshowvideosink
while the problem arise with:
gst-launch rtspsrc location=... latency=150 ! queue ! rtph264depay ! ffdec_h264
! direct***sink
you can test with this public url if you want:
rtsp://62.123.237.212/axis-media/media.amp
Original comment by drakkan1...@gmail.com
on 7 Oct 2010 at 8:19
sorry the right url is:
rtsp://root:npgadmin@62.123.237.212/axis-media/media.amp
Original comment by drakkan1...@gmail.com
on 7 Oct 2010 at 9:10
maybe this is a better trace:
avcodec-gpl-52.dll!6e8dbbd7()
[I frame indicati di seguito possono essere errati e/o mancanti, non sono stati caricati simboli per avcodec-gpl-52.dll]
avcodec-gpl-52.dll!6e8dbd18()
libgobject-2.0-0.dll!63a46ac5()
> libgstreamer-0.10.dll!gst_pad_chain_data_unchecked(_GstPad * pad=0x0129fb7c,
int is_buffer=29237184, void * data=0x00001040) Riga 4204 + 0x9 byte C
0129fb84()
libgstffmpeg-gpl.dll!gst_ffmpegdec_chain(_GstPad * pad=0x00b394b0, _GstBuffer * inbuf=0x00b7fe28) Riga 2590 + 0x2f byte C
libgstreamer-0.10.dll!gst_pad_chain_data_unchecked(_GstPad * pad=0x00b394b0, int is_buffer=1, void * data=0x00b7fe28) Riga 4182 + 0x7 byte C
libgstreamer-0.10.dll!gst_pad_push_data(_GstPad * pad=0x00b393e8, int is_buffer=1, void * data=0x00b7fe28) Riga 4411 + 0x12 byte C
libgstreamer-0.10.dll!gst_pad_push(_GstPad * pad=0x00b393e8, _GstBuffer * buffer=0x00b7fe28) Riga 4515 + 0x9 byte C
libgsth264parse.dll!gst_h264_parse_push_buffer(_GstH264Parse * h264parse=0x00000000, _GstBuffer * buf=0x00b7fe28) Riga 1723 + 0xd byte C
libgsth264parse.dll!gst_h264_parse_chain_forward(_GstH264Parse * h264parse=0x00000000, int discont=4160, _GstBuffer * buffer=0x00b7f640) Riga 2224 + 0x8 byte C
libgsth264parse.dll!gst_h264_parse_chain(_GstPad * pad=, _GstBuffer * buffer=) Riga 2561 + 0x16 byte C
libgstreamer-0.10.dll!gst_pad_chain_data_unchecked(_GstPad * pad=0x00b39320, int is_buffer=1, void * data=0x00b7f640) Riga 4182 + 0x7 byte C
libgstreamer-0.10.dll!gst_pad_push_data(_GstPad * pad=0x00b39258, int is_buffer=1, void * data=0x00b7f640) Riga 4411 + 0x12 byte C
libgstreamer-0.10.dll!gst_pad_push(_GstPad * pad=0x00b39258, _GstBuffer * buffer=0x00b7f640) Riga 4515 + 0x9 byte C
libgstrtp-0.10.dll!gst_base_rtp_depayload_push_full(_GstBaseRTPDepayload * filter=0x00000000, int do_ts=1, unsigned int rtptime=1252230141, _GstBuffer * out_buf=0x00b7f640) Riga 527 + 0xd byte C
libgstrtp-0.10.dll!gst_base_rtp_depayload_chain(_GstPad * pad=0x00b39190, _GstBuffer * in=0x00bea238) Riga 350 + 0xb byte C
libgstreamer-0.10.dll!gst_pad_chain_data_unchecked(_GstPad * pad=0x00b39190, int is_buffer=1, void * data=0x00bea238) Riga 4182 + 0x7 byte C
libgstreamer-0.10.dll!gst_pad_push_data(_GstPad * pad=0x00b390c8, int is_buffer=1, void * data=0x00bea238) Riga 4411 + 0x12 byte C
libgstreamer-0.10.dll!gst_pad_push(_GstPad * pad=0x00b390c8, _GstBuffer * buffer=0x00bea238) Riga 4515 + 0x9 byte C
libgstcoreelements.dll!gst_queue_push_one(_GstQueue * queue=0x00000000) Riga 1112 C
libgstcoreelements.dll!gst_queue_loop(_GstPad * pad=) Riga 1215 C
libgstreamer-0.10.dll!gst_task_func(_GstTask * task=0x00bd74e0) Riga 273 C
libgstreamer-0.10.dll!default_func(TaskData * tdata=0x00923458, _GstTaskPool * pool=0x00925058) Riga 68 + 0x3 byte C
libglib-2.0-0.dll!686147d9()
libglib-2.0-0.dll!6861290b()
msvcrt.dll!77bfc2de()
libgthread-2.0-0.dll!65c4231a()
msvcrt.dll!77c0a3b0()
kernel32.dll!7c80b729()
Original comment by drakkan1...@gmail.com
on 7 Oct 2010 at 3:19
the last trace was obtanied changing the pipeline in:
gst-launch rtspsrc location= .... ! queue ! rtph264depay ! h264parse !
ffdec_h264 ! ffmpegcolorspace ! **sink sync=false
Original comment by drakkan1...@gmail.com
on 7 Oct 2010 at 3:21
I get a similar crash even if from linux I connect to the source h264 stream
and retrasmit it via udpsink, on windows I use this pipeline:
gst-launch.exe -v udpsrc caps="application/x-rtp, media=(string)video,
payload=(int)96, clock-rate=(int)90000, encoding-name=(string)H264,
packetization-mode=(string)1,
profile-level-id=(string)420029,sprop-parameter-sets=(string)\"Z0IAKeKQGQJvy4C3A
QEBpB4kRUA\\=\\,aM48gA\\=\\=\"" port=8888 ! rtph264depay ! h264parse !
ffdec_h264 ! ffmpegcolorspace ! directdrawsink sync=false
and I get this crash after few minutes:
avcodec-gpl-52.dll!6e8dbbd7()
[I frame indicati di seguito possono essere errati e/o mancanti, non sono stati caricati simboli per avcodec-gpl-52.dll]
avcodec-gpl-52.dll!6e8dbd18()
libgobject-2.0-0.dll!63a46ac5()
> libgstreamer-0.10.dll!gst_pad_chain_data_unchecked(_GstPad * pad=0x0122fb74,
int is_buffer=20598752, void * data=0x00001020) Riga 4204 + 0x9 byte C
0122fb7c()
libgstffmpeg-gpl.dll!gst_ffmpegdec_chain(_GstPad * pad=0x00b38428, _GstBuffer * inbuf=0x00ba95e0) Riga 2590 + 0x2f byte C
libgstreamer-0.10.dll!gst_pad_chain_data_unchecked(_GstPad * pad=0x00b38428, int is_buffer=1, void * data=0x00ba95e0) Riga 4182 + 0x7 byte C
libgstreamer-0.10.dll!gst_pad_push_data(_GstPad * pad=0x00b38360, int is_buffer=1, void * data=0x00ba95e0) Riga 4411 + 0x12 byte C
libgstreamer-0.10.dll!gst_pad_push(_GstPad * pad=0x00b38360, _GstBuffer * buffer=0x00ba95e0) Riga 4515 + 0x9 byte C
libgsth264parse.dll!gst_h264_parse_push_buffer(_GstH264Parse * h264parse=0x00000000, _GstBuffer * buf=0x00ba95e0) Riga 1723 + 0xd byte C
libgsth264parse.dll!gst_h264_parse_chain_forward(_GstH264Parse * h264parse=0x00000000, int discont=4128, _GstBuffer * buffer=0x00ba99a8) Riga 2224 + 0x8 byte C
libgsth264parse.dll!gst_h264_parse_chain(_GstPad * pad=, _GstBuffer * buffer=) Riga 2561 + 0x16 byte C
libgstreamer-0.10.dll!gst_pad_chain_data_unchecked(_GstPad * pad=0x00b38298, int is_buffer=1, void * data=0x00ba99a8) Riga 4182 + 0x7 byte C
libgstreamer-0.10.dll!gst_pad_push_data(_GstPad * pad=0x00b381d0, int is_buffer=1, void * data=0x00ba99a8) Riga 4411 + 0x12 byte C
libgstreamer-0.10.dll!gst_pad_push(_GstPad * pad=0x00b381d0, _GstBuffer * buffer=0x00ba99a8) Riga 4515 + 0x9 byte C
libgstrtp-0.10.dll!gst_base_rtp_depayload_push_full(_GstBaseRTPDepayload * filter=0x00000000, int do_ts=1, unsigned int rtptime=3277811658, _GstBuffer * out_buf=0x00ba99a8) Riga 527 + 0xd byte C
libgstrtp-0.10.dll!gst_base_rtp_depayload_chain(_GstPad * pad=0x00b38108, _GstBuffer * in=0x00bb3010) Riga 350 + 0xb byte C
libgstreamer-0.10.dll!gst_pad_chain_data_unchecked(_GstPad * pad=0x00b38108, int is_buffer=1, void * data=0x00bb3010) Riga 4182 + 0x7 byte C
libgstreamer-0.10.dll!gst_pad_push_data(_GstPad * pad=0x00b38040, int is_buffer=1, void * data=0x00bb3010) Riga 4411 + 0x12 byte C
libgstreamer-0.10.dll!gst_pad_push(_GstPad * pad=0x00b38040, _GstBuffer * buffer=0x00bb3010) Riga 4515 + 0x9 byte C
libgstbase-0.10.dll!gst_base_src_loop(_GstPad * pad=0x00b38040) Riga 2496 + 0xa byte C
libgstreamer-0.10.dll!gst_task_func(_GstTask * task=0x00bd51d8) Riga 273 C
libgstreamer-0.10.dll!default_func(TaskData * tdata=0x00923328, _GstTaskPool * pool=0x00925058) Riga 68 + 0x3 byte C
libglib-2.0-0.dll!686147d9()
libglib-2.0-0.dll!6861290b()
msvcrt.dll!77bfc2de()
libgthread-2.0-0.dll!65c4231a()
msvcrt.dll!77c0a3b0()
kernel32.dll!7c80b729()
Original comment by drakkan1...@gmail.com
on 7 Oct 2010 at 3:30
update to revision 889, no more crash but after few minutes the video freeze
with no errors
Original comment by drakkan1...@gmail.com
on 11 Oct 2010 at 7:27
the problem seems related to rtspsrc/rtph264depay, the same stream served as
http (souphttpsrc) play fine for hours
Original comment by drakkan1...@gmail.com
on 26 Oct 2010 at 11:00
reported upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=633831
Original comment by drakkan1...@gmail.com
on 2 Nov 2010 at 6:53
I have simmilar issue, only on winXP (didn't observed on win7). I seems that
crash happens in call of av_parser_parse.
Original comment by tomasz.l...@gmail.com
on 5 Mar 2011 at 2:48
Ok, I've spent last weekend with this issue, and the solution was closer than I
thought :) Finally I applied the path mentioned here:
http://lists.freedesktop.org/archives/gstreamer-bugs/2009-December/057987.html
After several hours of running no crash happened.
Original comment by tomasz.l...@gmail.com
on 7 Mar 2011 at 11:50
Original issue reported on code.google.com by
ddrago...@gmail.com
on 26 Nov 2009 at 5:00