I am chasing a command line vlc conversion (mp4 and wav to mp3) . The problem is that vlc creates a zero byte output file.
I have tried the -vv and -vvv options, hoping vlc would give me a hint about what is going on, but the presence of these switches does nothing.
How to get some hints from vlc?
Example command line:
vlc.exe -I -vvv dummy "c:\temp\test\arc\test.aac" --sout=#transcode{acodec=mp3,ab=48,channels=2,samplerate=192000}:standard{access=file,mux=ts,dst="C:\data\personal\test\cardbuilding\audio-files\hinative\test2.mp3"} vlc://quit
OK, found out how to get detailed logging for VLC when it runs from a command line.
Open VLC interactively
Tools | Preferences | All (radio at bottom)
Advanced | Logger
Turn on logging, set file, set detail level
Close VLC
Now when you use the vlc.exe command line, you will get a log.
Alternate method (better, as all control remains on the cmd line, but not yet tested by me):
vlc --file-logging --logfile abc.txt --log-verbose 3
(where 3 = Debug)
That is the good news.
The bad news is... at least in my case, the logged information is not helping me figure out the problem.
Related
I'm trying to capture a video using vlc.
The procedure is standard using the GUI :
enter the url e.g http://some_site_some_video.mp4/playlist.m3u8 in the network protocol capture device tool (ctrl+n) in the next screen enter the path so save the file and that's it.
Tried using VLC docs, and the closest command I found was vlc -I dummy -vvv input_stream --sout
but
vlc -I dummy -vvv http://some_site_some_video.mp4/playlist.m3u8 --sout home/me/videos
Didn't work.
Is it the right command to use?
There's an app I've started working on, that regularly logs to the console a lot of stuff, and it's really not convenient to use the console for additional debug logs. I don't want to erase these logs, because there are a few people that are maintaining these logs, and it might be important to them.
So I actually need to to write my debug stuff to a different place. one option is to write it to a file and watch it in Terminal using tail command, but an iOS app can only write inside its folder which, when using a simulator, is always changing each time I run the app. and I don't want to change the path int the tail command every time - I want a fast process.
Does anyone have an idea for such external log place that I can use easily?
Here's how to make it easier to find and tail your log file when running in Simulator (I use this myself):
1) Add the following code to your home directory's .bashrc then log out and back in again.
xcodelog()
{
find . -name xcode.log -type f -print0 | xargs -0 stat -f "%m %N" | sort -rn | head -1 | cut -f2- -d" "
}
2) Start your app in Xcode's simulator, such that at least something gets logged to your file. Oh, and the file your app is logging to needs to be named "xcode.log" unless you want to change the filename in the above code.
3) Open terminal and switch to your ~/Library/Developer/CoreSimulator directory. Then perform the following command (it displays the last 100 lines of it along with anything new you dump to it).
tail -n 100 -f $(xcodelog)
So the above command hunts for that file among all your simulator devices and their apps, hunting down the most recent "xcode.log" file you've written to (among all apps and devices in entire CoreSimulator subdirectory system).
To clear the most recent xcode.log file, you can do this command:
cat /dev/null > $(xcodelog)
I switched to this approach for all my logging when Xcode 8 lost support for plugins, along with the very fine XcodeColors plugin that would do ANSI color logging into Xcode's console. So I changed my log system to output colors that terminal would support when doing a tail of a file. So I can spot errors in red, warnings in orange, user step logging in yellow, and various degrees of important other info in progressive shades of gray. :)
I have used the following command
vmc info |grep target
I can get the target info exactly. But when I type:
vmc apps |grep running
There is no output.
If I try to redirect the stdout to file like:
vmc apps &> tmplog
I was confused to see that only the first column of the output (appname) was written into the file. Any suggestions?
It may be the case that you need to redirect both unix output streams to see the complete log. There is STDOUT (1) and STDERR (2). To redirect both streams to the same file by using
vmc apps > tmplog 2 &> tmplog
Your last line above only redirected one output stream (STDOUT). The other stream may be written to to console instead.
Additionally, the vmc CLI is pretty much outdated. For the current go implementation of the CF CLI (gcf/cf), I successfully tested the following command to work
cf logs $YOUR_APP_NAME | grep RTR
Why won't this produce a file? It does everything right but saving to an actual file .. I am using Linux, Vlc 1.1.9, compiled without skins2, qt or ncurses interfaces...
vlc :sout=#transcode{vcodec=mp4,acodec=mp4a,vb=800,scale=1}:std{access=file,mux=mp4,dst="~/file.mp4"} screen:// screen-fps=12 screen-caching=100
Note this also does the same thing - shows the screen:// fine, but will not output to a file:
vlc :sout=#transcode{vcodec=h264,acodec=none,vb=800}:std{access=file,mux=avi,dst="/root/file.avi"} screen:// screen-fps=12 screen-caching=100
Try this
vlc -vvv (PORT (UDP, HTTP)) --ts-dump-file video.ts and add more commands
vlc -vvv (PORT (UDP, HTTP)) --sout-all file/ogg,mpg,ts:filename and add more commands
Thats above code shuld work!
Is there a way to run shell commands without output buffering?
For example, hexdump file | ./my_script will only pass input from hexdump to my_script in buffered chunks, not line by line.
Actually I want to know a general solution how to make any command unbuffered?
Try stdbuf, included in GNU coreutils and thus virtually any Linux distro. This sets the buffer length for input, output and error to zero:
stdbuf -i0 -o0 -e0 command
The command unbuffer from the expect package disables the output buffering:
Ubuntu Manpage: unbuffer - unbuffer output
Example usage:
unbuffer hexdump file | ./my_script
AFAIK, you can't do it without ugly hacks. Writing to a pipe (or reading from it) automatically turns on full buffering and there is nothing you can do about it :-(. "Line buffering" (which is what you want) is only used when reading/writing a terminal. The ugly hacks exactly do this: They connect a program to a pseudo-terminal, so that the other tools in the pipe read/write from that terminal in line buffering mode. The whole problem is described here:
http://www.pixelbeat.org/programming/stdio_buffering/
The page has also some suggestions (the aforementioned "ugly hacks") what to do, i.e. using unbuffer or pulling some tricks with LD_PRELOAD.
You could also use the script command to make the output of hexdump line-buffered (hexdump will be run in a pseudo terminal which tricks hexdump into thinking its writing its stdout to a terminal, and not to a pipe).
# cf. http://unix.stackexchange.com/questions/25372/turn-off-buffering-in-pipe/
stty -echo -onlcr
script -q /dev/null hexdump file | ./my_script # FreeBSD, Mac OS X
script -q -c "hexdump file" /dev/null | ./my_script # Linux
stty echo onlcr
One should use grep or egrep "--line-buffered" options to solve this. no other tools needed.