I am using espeak on BSD to output text as sound. My problem is that I want it to take it as a .mp3 but I am having little luck. I tried piping the output to tee but I guess that only works with stdout not just playing a sound.
Any ideas? My last resort would be recompiling my own version of espeak that allows me to save to a file instead of playing it
you can write it as wave and then convert it with ffmpeg:
espeak "HelloWorld" -w <file>.wav
Or pipe to ffmpeg
espeak "HelloWorld" --stdout | ffmpeg -i pipe:0 output.mp3
From the documentation:
-w < wave file>
Writes the speech output to a file in WAV format, rather than speaking it.
--stdout
Writes the speech output to stdout as it is produced, rather than speaking it. The data starts with a WAV file header which indicates the sample rate and format of the data. The length field is set to zero because the length of the data is unknown when the header is produced.
It looks like both of those options produce WAV files, but you can easily convert those without another program like ffmpeg.
Related
I am writing a C program using FFmpeg libav, and trying to output rawvideo (from file or device) packets to stdin so that they can be picked up by another program running on my system.
Any suggestions on how to do this?
For example, can I relate to stdin like a filename and just use avformat_alloc_output_context2 and avio_open like I would when recording to a file?
I there some code reference which deals with this scenario?
Thanks.
I am using trying to get specific information from a group of MP3 files, currently I am in the main cygwin64 that holds MP3 files and a .C file which simply contains
FILE * fp;
It contains that single line of code because when that line of code is in place and I type and run "thing.c" in the cygwin command line it outputs what seems the be the information of the contents of the folder. For example it outputs,
home: sticky, directory
lib: directory
sbin: directory
setup-x86_64.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB), for MS Windows
song.mp3: Audio file with ID3 version 2.3.0, contains: MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, JntStereo
song1.mp3: Audio file with ID3 version 2.3.0, contains: MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, JntStereo
thing.c: ASCII text, with CRLF line terminators
thing.txt: empty
What I want to do is be able to pull that output into a string that I can then use in my C file and alter and then re print out the new altered information. However I'm not sure where the output really is coming from or how I might be able to get it or save the output as a .txt file or back into a C file.
Any advice is appreciated Thanks!
This file is not really a C file at all. Because you're in Cygwin, you're likely operating on a case-insensitive filesystem (NTFS). As such, Cygwin's file command is running when you run the .c file. The way you've attempted to declare a variable (apparently) just so happens to be doing a 'file * fp' command. I'm sure you're getting fp: Cannot open "fp" or something similar after the rest of your output.
This is not anything C-related at all but is just being interpreted as a script by your shell.
It sounds like you have a lot to learn if you want to do this in C. More likely, you can probably write a shell script to accomplish what you want. While I've never used it, mp3info (https://github.com/jaalto/cygwin-package--mp3info) exists for pulling tag information from MP3 files. You could possibly get the exact information you want from that, or pipe the output into sed, awk, or a number of other tools.
Is it possible to dump a raw RTSP stream to file and then later decode the file to something playable?
Currently I'm using FFmpeg to receive and decode the stream, saving it to an mp4 file. This works perfectly, but is CPU intensive, and will severely limit the number of RTSP streams I can receive simultaneously on my server.
I would like to save the stream to file without decoding it, and delay the decoding part to when the file needs to be opened.
Is this possible?
I have tried VLC, which is even more CPU intensive than FFmpeg. I've also looked at this question where the answer says dumping RTSP to file is not useful, and this question, where the comment below the question says "Raw RTSP content is not well suited for save and replay...", which seems to indicate that there is way.
EDIT
Here is the command I'm using for FFmpeg:
ffmpeg -i rtsp://#192.168.241.1:62159 -r 15 C:/DB_Videos/2013-04-30 17_18_34.703.mp4
If you are reencoding in your ffmpeg command line, that may be the reason why it is CPU intensive. You need to simply copy the streams to the single container. Since I do not have your command line I cannot suggest a specific improvement here. Your acodec and vcodec should be set to copy is all I can say.
EDIT: On seeing your command line and given you have already tried it, this is for the benefit of others who come across the same question. The command:
ffmpeg -i rtsp://#192.168.241.1:62156 -acodec copy -vcodec copy c:/abc.mp4
will not do transcoding and dump the file for you in an mp4. Of course this is assuming the streamed contents are compatible with an mp4 (which in all probability they are).
With this command I had poor image quality
ffmpeg -i rtsp://192.168.XXX.XXX:554/live.sdp -vcodec copy -acodec copy -f mp4 -y MyVideoFFmpeg.mp4
With this, almost without delay, I got good image quality.
ffmpeg -i rtsp://192.168.XXX.XXX:554/live.sdp -b 900k -vcodec copy -r 60 -y MyVdeoFFmpeg.avi
You can use mplayer.
mencoder -nocache -rtsp-stream-over-tcp rtsp://192.168.XXX.XXX/test.sdp -oac copy -ovc copy -o test.avi
The "copy" codec is just a dumb copy of the stream. Mencoder adds a header and stuff you probably want.
In the mplayer source file "stream/stream_rtsp.c" is a prebuffer_size setting of 640k and no option to change the size other then recompile. The result is that writing the stream is always delayed, which can be annoying for things like cameras, but besides this, you get an output file, and can play it back most places without a problem.
I want to read a .gz file (text.gz) with 300MB length and search a pattern in it. I opened the text file in a binary format using fopen with "rb" and stored it in a buffer. When I search a pattern that I know it exists in the text, the result is wrong. When I debug the program, the elements of the buffer are different from what I expect. Do I have to read and store these kind of files in other ways??????
You might try using zlib and gzread to read the file.
http://zlib.net/manual.html
Try this.
gunzip -c file.gz | grep <pattern>
If the program is exiting and failing to read the file, a real common problem is that you don't close the file in Notepad or whatever is using it and the FileIO fails due to not being able to access the file. Make sure you don't have anything with that file open before you test your program.
Just started learning/using pipes and was wondering how to route file output of an application into a pipe so that another application can use it.
To be exact, I want to pipe ffmpeg's output (transcoded video data) into my application to use it. If I create a named pipe like /tmp/out.mp4 and give it to ffmpeg as output filename, ffmpeg is going to try to create this file again, probably overwriting my pipe (Or something like that). How to deal with this kind of situation?
is there any general way to divert File IO of an application transparently?
(I am trying to write a video streaming server (Just for learning and fun) which transcodes formats like avi into streaming friendly format like mpeg4 during streaming, I found ffmpeg to be too slow for this purpose, it was taking like 2 secs to transcode 1 sec video :(
Is it the problem with my setup/PC or ffmpeg is known for sluggishness?
)
PS : I am writing this in C by the way.
ffmpeg can be persuaded to output to a pipe:
ffmpeg -i whatever.avi -f mp4 -
The "-" tells it to output to stdout instead of to a file, and the "-f" tells it what output the output file should be.
You could redirect that to a named pipe, of course, but calling it with popen to get the output as a file descriptor directly seems the way to go to me.
ffmpeg can also read from stdin and write to stdout like this:
ffmpeg -i pipe:0 -f wav pipe:1
where 0 and 1 are the standard POSIX file descriptors.