6ecbfc3cb1
stopping video recording is asynchronous. Aan EOS event gets sent from camera source, travels across the whole pipeline until it reaches the muxer which then finalizes the file by writing the mov atom and friends and then pushes the EOS event farther downstream until it reaches our file writer (multifilesink in our case). The sink sends an EOS _message_ which is then caught by camerabin and causes it to flip the idle property from FALSE to TRUE. Any attempt to stop the pipeline before this property gets flipped will cause corrupted videos. Probably because the muxer gets shut down before it gets the EOS event so it does not write the needed header. When we are unloading camera we stop video recording and immediately switch camera bin to NULL state. This can lead to corrupted files. A more proper solution would be to postpone this pipeline tear down until we are idle. Since an application can attempt to start the pipeline again before it's completely unloaded, I have added a check to make sure we never tear down the pipeline if we are not in unloaded state. This check is also needed because we will be notified about the idle property change while we are loading the camera and we should not unload it when that happens. This also required removing the pipeline state change to NULL when we are loading camera.