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