search

ChinnaSuhas / ossbuild

Automatically exported from code.google.com/p/ossbuild
Other
0 stars 1 forks source link

rtph264pay/rtph264depay crash #12

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. gst-launch-0.10.exe --gst-plugin-path=. ksvideosrc ! ffmpegcolorspace !
x264enc bitrate=300 ! rtph264pay ! rtph264depay  ! ffdec_h264 !
ffmpegcolorspace ! glimagesink sync=false
2.
3.

What is the expected output? What do you see instead?
It crashes in avcodec-
6AF4A3CE   8B01             MOV EAX,DWORD PTR DS:[ECX]
after a while.
It runs fine in the dgb debugger!!!

What version of the product are you using? On what operating system?
up-to-date ossbuild

Please provide any additional information below.
The pipe without rtph264pay ! rtph264depay works fine.

Original issue reported on code.google.com by ddrago...@gmail.com on 26 Nov 2009 at 5:00

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
I'll look into this ASAP.

Original comment by david.g.hoyt on 1 Dec 2009 at 7:43

GoogleCodeExporter commented 9 years ago

Original comment by david.g.hoyt on 1 Dec 2009 at 7:44

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
Should be fixed in trunk. Please see SVN r759.

Original comment by david.g.hoyt on 20 Jul 2010 at 12:05

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
Can you attach it to the Visual Studio debugger too?

Original comment by ylatuya on 6 Oct 2010 at 9:41

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
I reopen the issue

Original comment by ylatuya on 6 Oct 2010 at 12:10

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
So maybe it is a memory allocation issue.

Original comment by ddrago...@gmail.com on 6 Oct 2010 at 6:18

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
True.

Original comment by ddrago...@gmail.com on 6 Oct 2010 at 9:42

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
reported upstream:

https://bugzilla.gnome.org/show_bug.cgi?id=633831

Original comment by drakkan1...@gmail.com on 2 Nov 2010 at 6:53

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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