[flumotion-issues] [Flumotion] #1505: buffer probe to drop streamheaders is sometimes not installed

Flumotion trac at code.bt.bcn.flumotion.net
Wed Mar 30 15:35:21 CEST 2011

#1505: buffer probe to drop streamheaders is sometimes not installed
                 Reporter:  jurbanski  |                Owner:  nobody
                     Type:  defect     |               Status:  new
                 Priority:  normal     |            Milestone:
                Component:  flumotion  |              Version:  master
                 Severity:  normal     |             Keywords:
Estimated Number of Hours:  0          |  Add Hours to Ticket:  0
                Billable?:  1          |          Total Hours:  0
                    Phase:             |
 The attached flow (using https://github.com/zaheerm/flumotion-ugly) causes
 a GStreamer error in the consumer component.

 Steps to reproduce:
  * start a manager with the provided config
  * start worker1
  * just after that start worker2
  * just after that start worker3

 Expected result:
  * all components are happy

  * the consumer component becomes sad with a GStreamer error

 Debugging showed that what happens is:
  * the muxer component starts sending data
  * the multifdsink of the muxer component receives the first buffer, sees
 that the caps have a streamheader and the connected client did not have
 the streamheader sent, sends the streamheader
  * the caps on the flvmux element in the muxer component change, debugging
 showed that the change consists in another buffer appearing in the
 streamheader, which contains the taglist ("taglist, bitrate=(uint)49000")
  * multifdsink in the muxer sees that the streamheader changed, resends it
 to the connected client
  * flvdemux receives the "FLV..." header for the second time which
 provokes an error

 This only happens if the consumer is already connected to the muxer before
 it first receives data.

 There is code in feedcomponent010.py to drop IN_CAPS buffers, but the
 probe to do that is not added if eatFromFD is called when the pipeline is
 not in the playing state.

 Debugging showed that in this configuration call to set the master clock
 happens *after* eatFromFD is received, and so the pipeline is not yet in
 the playing state (because it was missing master clock info when the
 component tried to start it after the setup phase). This results in the
 probe never being installed.

 The attached patch moves the code to attach the streamheader probe to a
 separate function and moves the call to that function to where the other
 eater probes are added.

Ticket URL: <http://code.flumotion.com/trac/ticket/1505>
Flumotion <http://www.flumotion.net/>
Flumotion Streaming Server

More information about the flumotion-issues mailing list