Have you tried with newer versions? (core/base 0.10.36, -good 0.10.31)

Could you attach a (compressed) GST_DEBUG=*:5 log? (A GST_DEBUG=soup*:5 log might do as well if it takes a long time to reproduce the error)

Created attachment 213018 [details]
error log

error log

thanks for your replay。
i have commented error log。

i supplement another information and hope usefule for you：

my network environment： wireless；
parameter configuration：
souphttpsrc：blocksize=1M
queue2：max-size-bytes=20M
        max-size-buffers=0
        max-size-time=0

and if block size is more large and network is more bad，the error will occur more often。

I can't read that log file. How did you create it? You can redirect the GST_DEBUG output into a file using 2>dbg.log , at leasat on linux.

sorry for late response。

I created another log file，please check the attachment。

Created attachment 213258 [details]
error log

Thanks, I can read this log file. However, it's not really very detailed, it's more like a GST_DEBUG=*:2 log than a GST_DEBUG=soup*:5 log.

This seems to be the cause of your problem:

0:00:23.591082900  1225   0x4e2a40 WARN             
GST_BUFFER gstbuffer.c:417:gst_buffer_try_new_and_alloc: failed to allocate 1048576 bytes

You don't seem to have enough memory available. Either soup tries to allocate too large a buffer here, and should be using smaller chunks, or you've run out of memory. Or perhaps you're leaking memory somewhere.

In any case, at first glance I would suspect that the actual issue is not in souphttpsrc.

thanks for your tips.

I just try following command:
GST_DEBUG=2,*queue*:2,*soup*:3 gst-launch souphttpsrc location= http://192.168.10.103:10243/WMPNSSv3/3691493703/1_ezNGMDZFRDQ2LUVGRUItNDEyMi04QTAzLTk1N0Y1MUMxRjYxRX0uMC43RTZFQkY1MA.avi blocksize=10485760 ! queue2 use-buffering=TRUE max-size-bytes=20971520 max-size-buffers=0 max-size-time=0 ! qtdemux name=demux demux.audio_00 ! fakesink

that means I set blocksize 10M, this is a extreme situation.I just want to reproduce the phemomenon.

In fact, the same error occurred and occurred at the beginning when running the command just like following:

Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Prerolled, waiting for buffering to finish...
0:00:04.928456595  1269   0x4cca90 WARN              GST_BUFFER gstbuffer.c:417:gst_buffer_try_new_and_alloc: failed to allocate 10485760 bytes
0:00:04.930265545  1269   0x4cca90 WARN                 basesrc gstbasesrc.c:2574:gst_base_src_loop:<souphttpsrc0> error: Internal data flow error.
0:00:04.931049230  1269   0x4cca90 WARN                 basesrc gstbasesrc.c:2574:gst_base_src_loop:<souphttpsrc0> error: streaming task paused, reason error (-5)
ERROR: from element /GstPipeline:pipeline0/GstSoupHTTPSrc:souphttpsrc0: Internal data flow error.
Additional debug info:
gstbasesrc.c(2574): gst_base_src_loop (): /GstPipeline:pipeline0/GstSoupHTTPSrc:souphttpsrc0:
streaming task paused, reason error (-5)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...



so, would you like to answer my following questions:
1. Is chunk size limited by gstsouphttpsrc?
2. At the beginning of running gst-launch, memory is enough, why  'failed to allocate 10485760 bytes' is reported?

thanks.

I have some other information about the error:

The error occurs more ofter at the following two conditions:
1) the network is bad, such as network speed is about 1M bytes.
2) blocksize is more large, such as 2M bytes, even 10M bytes.

> so, would you like to answer my following questions:
> 1. Is chunk size limited by gstsouphttpsrc?

Not sure I understand the question. Why would it be?


> 2. At the beginning of running gst-launch, memory is enough, why  'failed to
> allocate 10485760 bytes' is reported?

Because at the beginning your 20MB large queue2 is empty. After a while it fills up, so at some point (if it ever gets that far) there's 20MB less space available than there was when gst-launch started, without any memory leaks involved.

You may also be interested in bug #664778, which could be related.


It's still not clear to me there's actually a bug in souphttpsrc here (other than the one mentioned above).

(In reply to comment #10)
> > so, would you like to answer my following questions:
> > 1. Is chunk size limited by gstsouphttpsrc?
> 
> Not sure I understand the question. Why would it be?
> 

Because the blocksize affects the error occurring rate seriously, so I guess if  the blocksize has a range.
  


> > 2. At the beginning of running gst-launch, memory is enough, why  'failed to
> > allocate 10485760 bytes' is reported?
> 
> Because at the beginning your 20MB large queue2 is empty. After a while it
> fills up, so at some point (if it ever gets that far) there's 20MB less space
> available than there was when gst-launch started, without any memory leaks
> involved.
> 
> You may also be interested in bug #664778, which could be related.


  I have read the content in bug #664778 and understood it mostly. 
  In fact at first, I also found the same problem with memory waste(I think it is memory leak, because I do not know intrinsic factor), and found the relationship between blocksize and memory waste:
  the larger the blocksize is, the less the memory waste is.

  So I use larger blocksize, but 'internal data flow error' occurs.
  Now, in the final analysis, it is the memory waste breeding the error.
  
  So I also want to modify gst_soup_http_src_chunk_allocator myself, but I am  newcomer to gstreamer and solving the problem is an urgent thing for me. 

  Could you like to give me some advices?  
 
 
> It's still not clear to me there's actually a bug in souphttpsrc here (other
> than the one mentioned above).

  Is still there a bug in souphttpsrc?
  Could I learn about the 'bug'?
  thanks.

You could ask the person in the other bug report for their modifications/patches.

I'll mark this one as duplicate of the other bug if you don't mind.

*** This bug has been marked as a duplicate of bug 664778 ***

Never mind.

thank you very much for your feedback.