TEEing the video

Ian Davidson id012c3076 at blueyonder.co.uk
Fri Nov 28 08:48:30 PST 2014


I have done some more investigation.

I modified the pipeline to set the framerate to 5/1 (to make life a bit 
easier for my poor old development machine) and checked that it still 
showed the problem. It did.

Without bothering with the audio, I then replaced filesink with 
fakesink, and worked my way forward until the monitor window began to 
work properly.

When my pipeline looked like this
gst-launch-1.0 -e --gst-debug=4 v4l2src ! tee name=vt ! queue ! 
videorate ! videoscale ! 
"video/x-raw,format=(string)I420,width=480,height=384,framerate=(fraction)5/1" 
! queue ! videoconvert ! x264enc ! fakesink vt. ! queue ! videorate ! 
videoscale ! 
"video/x-raw,format=(string)I420,width=320,height=240,framerate=(fraction)5/1" 
! videoconvert ! autovideosink
The pipeline would still not move fully into the PLAYING state.

When the pipeline looked like this
gst-launch-1.0 -e --gst-debug=4 v4l2src ! tee name=vt ! queue ! 
videorate ! videoscale ! 
"video/x-raw,format=(string)I420,width=480,height=384,framerate=(fraction)5/1" 
! queue ! videoconvert ! fakesink vt. ! queue ! videorate ! videoscale ! 
"video/x-raw,format=(string)I420,width=320,height=240,framerate=(fraction)5/1" 
! videoconvert ! autovideosink
The pipeline would move to PLAYING.  This meant that when I used Ctrl-C, 
the pipeline closed down properly.

It would seem that, for some reason, x264enc is preventing the pipeline 
from going to PLAYING (although I see that x264enc has, itself, made the 
state change).

What should I do to, either, find out what is going wrong, or fix the 
pipeline so that it does what I want?

I have a log of the run with x264enc included here 
https://www.dropbox.com/s/5d4iz06i5sqow6r/x264Fail.txt?dl=0
And a log of the run with x264enc removed here 
https://www.dropbox.com/s/lupapf3wv06jrcw/NOx264Played.txt?dl=0

Ian

On 25/11/2014 17:16, Ian Davidson wrote:
> Using videoconvert has helped me a bit - my test machine now performs 
> in a similar manner to the live machine.
>
> Here is the pipeline I am trying
> gst-launch-1.0 -e v4l2src ! tee name=vt ! queue ! videorate ! 
> videoscale ! 
> "video/x-raw,format=(string)I420,width=480,height=384,framerate=(fraction)25/1" 
> ! queue ! videoconvert ! x264enc ! mp4mux name=mux ! filesink 
> location=test.mp4 alsasrc ! "audio/x-raw,rate=44100,channels=1" ! tee 
> name=at ! queue ! audiorate ! queue ! lamemp3enc ! mux.  at. ! queue ! 
> audioconvert ! queue ! wavenc ! filesink location=test.wav vt. ! queue 
> ! videoscale ! 
> "video/x-raw,format=(string)I420,width=320,height=240,framerate=(fraction)25/1" 
> ! videoconvert ! autovideosink
>
> When I run it the autovideosink does put up a window with a frame 
> displayed in it.  I do not believe that anything useful gets written 
> to the mp4 file nor the wav file.  The frame never changes.
> To stop gst-launch I have to use Ctrl-C 3 times.  After the first I get
> handling interrupt.
> Interrupt: Stopping pipeline ...
> EOS on shutdown enabled -- Forcing EOS on the pipeline
> Waiting for EOS ...
>
> After a while, I give it another Ctrl-C and I got
> handling interrupt.
> Interrupt while waiting for EOS - stopping pipeline...
> Execution ended after 0:00:34.227632246
> Setting pipeline to PAUSED ...
>
> After a while, I give it the third Ctrl-C.
> The window created by autovideosink now disappears and control now 
> returns to the terminal I used to launch the command-line.
>
> I ran with --gst-debug=4 and the trace can be seen here 
> https://www.dropbox.com/s/7bqjsl4i23qqd0e/FullPipelineTrace?dl=0
>
> I attempted to repeat the test with the audio stripped out using the 
> command line
> gst-launch-1.0 -e --gst-debug=4 v4l2src ! tee name=vt ! queue ! 
> videorate ! videoscale ! 
> "video/x-raw,format=(string)I420,width=480,height=384,framerate=(fraction)25/1" 
> ! queue ! videoconvert ! x264enc ! mp4mux name=mux ! filesink 
> location=test.mp4 vt. ! queue ! videorate ! videoscale ! 
> "video/x-raw,format=(string)I420,width=320,height=240,framerate=(fraction)25/1" 
> ! videoconvert ! autovideosink
>
> It behaved in a very similar manner.  The trace can be seen here 
> https://www.dropbox.com/s/x4exu6egg3kndkh/NoAudioTrace?dl=0
>
> I suspect that I don't need quite so many queue elements as I have - 
> but would that cause any problems?
>
> What else might I do?
>
>
> On 22/11/2014 14:46, Ian Davidson wrote:
>> Thanks Tim,
>>
>> That worked on my dev machine.  Tomorrow or Monday, I will see if 
>> that cures my Live machine.
>>
>> Ian
>>
>> On 22/11/2014 14:33, Tim Müller wrote:
>>> On Sat, 2014-11-22 at 14:17 +0000, Ian Davidson wrote:
>>>
>>> Hi,
>>>
>>>
>>> Try adding a 'videoconvert' element before the autovideosink.
>>>
>>>   Cheers
>>>    -Tim
>>>
>>
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



More information about the gstreamer-devel mailing list