I have a raw video that I can play through gstreamer:
gst-launch-1.0 ... autovideoconvert ! autovideosink
I can encode this video:
gst-launch-1.0 ... ! autovideoconvert ! x264enc ! h264parse ! mp4mux ! filesink location=a.mp4
I would like now to put this raw video in a mp4 container "lossless", without any compression. How can I do that?
You answered in your question. Don't do compression
gst-launch-1.0 ... ! autovideoconvert ! mp4mux ! filesink location=a.mp4
But you know, without compression this file will be large (GBytes.)
I don't think I can use mp4mux but qtmux accept raw-uyvy. The following works:
gst-launch-1.0 ... ! autovideoconvert ! "video/x-raw,format=(string)UYVY" ! qtmux ! filesink location=a.mov
Sometimes the source data won't be suitable for re-muxing, but if it is a pipeline such as this should work:
gst-launch-1.0 filesrc location=... ! [DEMUX] ! h264parse ! qtmux !
filesink location=...
h264 data has different "stream formats" and "alignments" that it can be in. The stream formats are avc, avc3, and byte-stream. The possible alignments are au and nal. Different muxers take different combinations of these. h264parse will make that transformation if necessary.
And to re-iterate, sometimes the source data just won't be re-muxable into the desired container. It depends on a lot of factors.
Related
I am a beginner with gstreamer so bear with me.
I have a working pipeline where audio and video from a test source is sent to the webrtcbin element used to send out offer. Pipeline is as follows:
PIPELINE_DESC = '''
webrtcbin name=sendrecv stun-server=stun://stun.l.google.com:19302
audiotestsrc is-live=true wave=red-noise ! audioconvert ! audioresample ! queue ! opusenc ! rtpopuspay !
queue ! application/x-rtp,media=audio,encoding-name=OPUS,payload=96 ! sendrecv.
videotestsrc is-live=true pattern=ball ! video/x-raw,width=320,height=240 ! videoconvert ! queue ! x264enc ! rtph264pay !
queue ! application/x-rtp,media=video,encoding-name=H264,payload=97 ! sendrecv.
'''
However doing this consumes a lot of CPU/Memory as gstreamer has to encode audio/video. Hence I was to use a pre-recorded file to lower the resource usage.
I want to use a sample file (sample.mp4) to send audio and video to the webRTCbin element. The mp4 file has H264 video and AAC audio. I have tried a lot of combinations of elements but it is not working. Could you please help me correct my pipeline?
PIPELINE_DESC = '''
webrtcbin name=sendrecv stun-server=stun://stun.l.google.com:19302
filesrc location=sample.mp4 ! decodebin ! audioconvert ! sendrecv.
filesrc location=sample.mp4 ! decodebin ! videoconvert ! sendrecv.
'''
Many thanks in advance.
mp4 file is a container file format and it needs to be demultiplexed to get video and audio. For that purpose, you can use GStreamer's qtdemux element.
Considering above, example pipeline could be something like this
PIPELINE_DESC = '''
filesrc location=test.mp4 ! qtdemux name=demux
webrtcbin name=sendrecv stun-server=stun://stun.l.google.com:19302
demux.audio_%u ! aacparse ! rtpmp4apay !
queue ! application/x-rtp,media=audio,encoding-name=MP4A-LATM,payload=96 ! sendrecv.
demux.video_%u ! h264parse ! rtph264pay !
queue ! application/x-rtp,media=video,encoding-name=H264,payload=97 ! sendrecv.
'''
I have a gstreamer pipeline that streams using :
v4l2src ! x264enc ! rtph264pay pt=96 ! udpsink host=ip port=8554
And this pipeline that receives this stream :
/ queue ! avdec_h264 ! appsink
udpsrc ! capsfilter ! rtpjitterbuffer ! rtph264depay ! tee !
\ queue ! h264parse ! mp4mux ! filesink
Simplified receiver pipeline without the tee is :
gst-launch-1.0 udpsrc port=8080 caps="lots-of-caps" ! rtpjitterbuffer ! rtph264depay ! h264parse ! mp4mux ! filesink location=/home/rish/Desktop/recorded.264 -e
Question :
Is there a way to save the H264 encoded stream received from udpsrc without having to re-encode it? How do I correctly close the filesink?
What I've tried so far : The discussion from this thread suggests the pipeline I've tried above but file is still corrupt. (not correctly closed).
This question asks a similar question. However I do not want to decode and re-encode. Another answer in the thread suggests using matroskamux element instead of mp4mux. This works, but I'd rather prefer using mp4mux (no particular reason, but I'd like to know why matroskamux works and mp4mux doesn't).
Your pipeline is already muxing without re-encoding, there is no encoder on your pipeline. h264parse is just a parser.
you've already got an answer on how to close the stream here: Sending EoS to filesink while removing branch from tee
I have a requirement where I need to encode a v4l2src source in H.264 while using a Matroska container. If I have .mkv file with embedded subtitles it is easy to extract subtitles with
gst-launch-1.0 filesrc location=test.mkv ! matroskademux ! "text/x-raw" ! filesink location=subtitles
From what I understand and assuming I understand correctly, during the encoding process the "subtitle_%u" pad needs to be linked to text/x-raw source using textoverlay.
gst-launch-1.0 textoverlay text="Video 1" valignment=top halignment=left font-desc="Sans, 60" ! mux. imxv4l2src device=/dev/video0 ! timeoverlay ! videoconvert ! queue ! vpuenc_h264 ! capsfilter
caps="video/x-h264" ! matroskamux name=mux ! filesink location=sub.mkv
I use the above pipeline but I do not get the overlay in the .mkv video. What is the correct way to encode a subtitle/text overlay while encoding a source in H.264 in a matroska container and then also later be able to extract it using the first pipeline?
Sanchayan.
You may try this:
gst-launch-1.0 \
filesrc location=subtitles.srt ! subparse ! kateenc category=SUB ! mux.subtitle_0 \
imxv4l2src device=/dev/video0 ! timeoverlay ! videoconvert ! queue ! vpuenc_h264 ! \
capsfilter caps="video/x-h264" ! matroskamux name=mux ! filesink location=sub.mkv
And the subtitles.srt file may be like this:
1
00:00:00,500 --> 00:00:05,000
CAM 1
2
00:00:05,500 --> 00:00:10,000
That's all folks !
I have accidentally write a H264 data without any container using gstreamer by using following pipeline:
gst-launch-1.0 filesrc location=input.avi ! image/jpeg,width=672,height=378,framerate=15/1 ! jpegdec ! videoconvert ! x264enc ! filesink location=output.mkv
The correct pipeline should have been as follows:
gst-launch-1.0 filesrc location=input.avi ! image/jpeg,width=672,height=378,framerate=15/1 ! jpegdec ! videoconvert ! x264enc ! matroskamuxer ! filesink location=output.mkv
Now I have been trying to correct these streaming files, but I cannot find any appropriate solution yet.
Could you please give me suggestions on solution to this problem?
Regards.
I would start by seeing if you can just extract the data and play it. Then try and mux it. Something like this:
gst-launch-1.0 filesrc location=output.mkv ! video/x-h264,framerate=30/1 ! h264parse ! avdec_h264 ! ximagesink
You may have to tweak the caps, but then once you get it playing you can mux it.
gst-launch-1.0 filesrc location=output.mkv ! video/x-h264,framerate=30/1 ! h264parse ! matroskamux ! filesink location=good.mkv
I'm trying to record stream from m3u8 file.
This pipeline works:
gst-launch-0.10 -e souphttpsrc location=(mysrc.m3u8) ! queue ! hlsdemux ! queue ! mpegtsparse ! queue ! mpegtsdemux ! queue ! audio/mpeg ! queue ! filesink location=test.ts
and (sometimes) record audio stream.
But i can't record video, whatever i do it crashes.
I tried something like this:
gst-launch-0.10 souphttpsrc location=(mysrc.m3u8) ! queue ! hlsdemux ! queue ! mpegtsparse ! queue ! mpegtsdemux ! queue ! video/x-264 ! queue ! filesink location=test.ts
But it does nothing.
You are using gstreamer 0.10 which is obsolete and unmantained, all users should upgrade to the 1.x series.
Given that warning, it is not clear whether you want to save the mpegts stream or the streams inside it.
To save the mpegts stream you can just do:
gst-launch-1.0 http://path/to/your/stream.m3u8 ! hlsdemux ! filesink
Be aware that if the HLS playlist contains multiple bitrates hlsdemux might switch bitrate and it will fail as gst-launch-1.0 isn't capable of handling this. (it is a debugging and testing tool). You can likely set a fixed "connection-speed" to make it always use the same bitrate you desire to overcome this issue.
If you want to get only the video stream and you know it is H264, try:
gst-launch-1.0 http://path/to/your/stream.m3u8 ! hlsdemux ! tsdemux ! queue ! video/x-h264 ! filesink
It might be a better idea to save it to a container format to allow easier use later, with something like:
gst-launch-1.0 http://path/to/your/stream.m3u8 ! hlsdemux ! tsdemux ! queue ! video/x-h264 ! h264parse ! qtmux ! filesink
But, as I said, please move to 1.x, HLS is much better at 1.x than it was in 0.10 and it should work.