I'd like to take a screenshot of an existing video - either an mp4 or an flv - using GStreamer1.0
I see multifilesink but it looks like that generates a bunch of images. I'd only like 1.
You can use:
gst-launch-1.0 filesrc location=/media/datos/videos/video.mp4 ! decodebin ! videoconvert ! pngenc snapshot=true ! filesink location=frame.png
Related
im trying to construct a pipeline that will read any file (mp3, ogg, flac etc) and updates its tags using the taginject element, but it is not working.
Here are my attempts:
gst-launch-1.0 filesrc location=file.mp3 ! decodebin ! taginject tags="title=bla,artist=blub" ! filesink location=output_file.mp3
Result: The Pipeline runs, but it creates a 50mb file from a 4mb file, and that large file is not playable (and probably not containing tags, also).
gst-launch-1.0 filesrc location=file.mp3 ! taginject tags="title=test,artist=blub" ! filesink location=output_file.mp3
Result: The pipeline runs and creates a playable output file, but it contains no tags.
gst-launch-1.0 filesrc location=file.mp3 ! decodebin ! taginject tags="title=test,artist=blub" ! encodebin ! filesink location=output_file.mp3
Result: The pipeline does not run. It says taginject cannot be linked with encodebin.
I would appreciate any help on this, I just dont know what I am doing wrong (probably using the wrong elements... but I just cant find which are the right ones)
You need to add a muxer after taginject, e.g. something like:
gst-launch-1.0 filesrc location=file.mp3 ! parsebin ! \
taginject tags="title=bla,artist=blub" ! id3v2mux ! \
filesink location=output_file.mp3
Also using parsebin avoids decoding.
i am trying to share an h264 encoded data from gstreamer to another two processes(both are based on gstreamer).After some research only way i found is to use the shm plugin.
this is what i am trying to do
gstreamer--->h264 encoder--->shmsink
shmrc--->process1
shmrc--->process2
i was able to get raw data from videotestsrc and webcam working. But for h264 encoded data it doesn't.
this is my test pipeline
gst-launch-1.0 videotestsrc ! video/x-raw,width=640,height=480,format=YUY2 !
x264enc ! shmsink socket-path=/tmp/foo sync=true wait-for-
connection=false shm-size=10000000
gst-launch-1.0 shmsrc socket-path=/tmp/foo ! avdec_h264 ! video/x-
raw,width=640,height=480,framerate=25/1,format=YUY2 ! autovideosink
have anyone tried shm plugins with h264 encoded data, please help
Iam not aware of the capabilities of your sink used in "autovideosink", but as per my knowledge you either need to use videoconvert if the format supported by the sink (like kmssink or ximagesink) are different than provided by the source (in your case YUY2) or use videoparse if the camera format is supported by the sink. You may check this using gst-inspect-1.0 for the formats supported.
Anyways I am able to run your pipeline with some modifications using videoconvert in my setup :
./gst-launch-1.0 videotestsrc ! x264enc ! shmsink socket-path=/tmp/foo sync=true wait-for-connection=false shm-size=10000000
./gst-launch-1.0 shmsrc socket-path=/tmp/foo ! h264parse ! avdec_h264 ! videoconvert ! ximagesink
You may modify it as per the resolutions you want.
Kindly let me know if you face any issue with above.
I would like to create a non segmented .mp4 video from a matroska source. I have seen this post and created a similar pipeline. My source contains only h264 video and no sound, so my pipeline looks like this:
gst-launch-1.0 filesrc location=x.mkv ! matroskademux ! h264parse ! mp4mux ! filesink location=x.mp4
However running gst-discoverer-1.0 on the result gives a duration of 0:00:00.000000000. Also vlc is not able to play the resulting .mp4 file and it cannot be used in a HTML5 <video> element (which is the final purpose of this conversion).
If I create a segmented .mp4 by adding fragment-duration=1000 to the mp4mux element, then vlc can play the .mp4, but this is not what I want. I need a .mp4 where the total length is known. What am I doing wrong?
Additional information: The length was present in the matroska source, as displayed by gst-discoverer-1.0, and vlc can display that source. I also can replay the non segmented .mp4 with gstreamer (using gst-launch-1.0 filesrc location=x.mp4 ! qtdemux ! h264parse ! avdec_h264 ! videoconvert ! autovideosink). Inspecting the generated .dot file reveals a framerate of 10000/1 coming out of qtdemux which seems quite strange.
The solution was to add disable-passthrough=true to the h264parse element, so the pipeline now looks like this:
gst-launch-1.0 filesrc location=x.mkv ! \
matroskademux ! \
h264parse disable-passthrough=true ! \
mp4mux ! \
filesink location=x.mp4
Now the resulting .mp4 file includes the timing information and can nicely be played with vlc as well as in a <video> tag including forward/backward navigation.
I used the following GStreamer pipeline to store my encoded stream in a binary file:
gst-launch v4l2src ! videorate ! video/x-raw-yuv, framerate=\(fraction\)10/1 \
! videoscale ! video/x-raw-yuv, format=\(fourcc\)I420, width=640, height=480\
! ffmpegcolorspace ! x264enc ! fdsink > vid.bin
Now i want to play previously recorded files in GStreamer using the following pipeline:
cat vid.bin | gst-launch fdsrc ! ffdec_h264 ! autovideosink
But then it gives the following error:
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/ffdec_h264:ffdec_h2640: Internal GStreamer error: negotiation problem. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer.
Additional debug info:
gstffmpegdec.c(2804): gst_ffmpegdec_chain (): /GstPipeline:pipeline0/ffdec_h264:ffdec_h2640:
ffdec_h264: input format was not set before data start
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
I know that the best way to capture video is using Muxers but is there any way to play my previous files?
Thanks
Not sure your pipeline is right.
If you want to write to a file why not simply use filesink and filesrc.
fdsink > vid.bin will not work fine because if you see the prints by gstreamer gst-launch will also go into the file. [Just open vid.bin in an text editor and you will see what I mean].
Also for x264 stream to be stored without a muxer you need to use byte-stream=1 in your x264enc to store it in annexb format so that it is decodable.
To play back raw x264 stream you need to have a color space convertor before the video sink
gst-launch filesrc location=inputfile ! legacyh264parse ! ffdec_h264 ! queue ! ffmpegcolorspace ! autovideosink
plays just fine here at my end
Or, to playback a raw h264 file with gstreamer 1.0:
gst-launch-1.0 filesrc location=/tmp/video.h264 ! h264parse ! avdec_h264 ! autovideosink
I'm having a problem trying to record audio+video from my webcam to a file. If I use videotestsrc and autoaudiosrc I get everything right (read as in I get a file with audio recorded from the webcam's mic, and test-video image), but as soon as I replace videotestsrc with v4l2src (or autovideosrc) I get Error starting streaming on device '/dev/video0'.
The command I'm using:
gst-launch-0.10 videotestsrc ! queue ! ffmpegcolorspace! theoraenc ! queue ! oggmux name=mux autoaudiosrc ! queue ! audioconvert ! vorbisenc ! queue ! mux. mux. ! queue ! filesink location = test.ogg
Why is that happening? What am I doing wrong?
EDIT:
In fact, something as simple as
gst-launch-0.10 autovideosrc ! autovideosink autoaudiosrc ! autoaudiosink
is failing with the same error (Error starting streaming on device '/dev/video0')
Replacing autovideosrc with videotestsrc gives me test image + real audio.
Replacing autoauidosrc with audiotestsrc gives me real image + test audio.
I'm starting to think that this is some kind of limitation of my webcam. Is that possible?
EDIT:
GST_DEBUG=2 log here: http://pastie.org/4755009
EDIT 2:
GST_DEBUG="v4l2*:5" (gstreamer 0.10): http://pastie.org/4810519
GST_DEBUG="v4l2*:5" (gstreamer 1.0): http://pastie.org/4810502
Please do a
gst-launch-1.0 v4l2src ! videoscale ! videoconvert ! autovideosink
Does that run? If not repeat as
GST_DEBUG="v4l2*:5" GST_DEBUG_NO_COLOR=1 gst-launch 2>debug.log ...
and check the log for errors. You also might want to run v4l-info (install v4l-conf under debian/ubuntu) and report what formats your camera supports.