I'm working on a streaming project.
I have VLC running as a server, streaming mp4 (h264/aac) RTSP stream to Flumotion server (which is based on Gstreamer).
I think it's either a compatibility problem between VLC (which is based on Live555) and Flumotion (which is based on GStreamer) or the pipeline used to receive RTSP stream is mis-written.
Here's the pipeline used by flumotion and needs to be fixed (rtsp.py lines 44-49):
return ("rtspsrc name=src location=%s ! decodebin name=d ! queue "
" ! %s ffmpegcolorspace ! video/x-raw-yuv "
" ! videorate ! video/x-raw-yuv,framerate=%d/%d ! "
" #feeder:video# %s ! #feeder:audio#"
% (location, scaling_template, framerate[0],
framerate[1], audio_template))
Edit:
The problem is that RTSP-Producer component in flumotion can't recieve any data from the VLC stream. no errors, nothing, it just keeps in 'waking' status.
I tried some variations of GStreamer pipeline used by flumotion but couldn't get it to work.
I found many similar unsolved questions in StackOverflow which made me think it's a compatibility issue
I'm not a gst-pipeliner ! so please help me out of this struggle.
Okay now,
since this command is working (usually):
gst-launch playbin uri="rtsp://127.0.0.1:8554/live"
I decided that there can't be compatibility problem!
and the problem was solved by using 'rtspdecodebin' instead of 'rtspsrc' and 'decodebin'
So finally I modified that in rtsp.py::
return ("uridecodebin name=d uri=%s ! queue "
" ! %s ffmpegcolorspace ! video/x-raw-yuv "
" ! videorate ! video/x-raw-yuv,framerate=%d/%d ! "
" #feeder:video# %s ! #feeder:audio#"
% (location, scaling_template, framerate[0],
framerate[1], audio_template))
Now it works! (most of the times) and it's probably something with the stream or QoS ...
Related
I'm using powerline, bash, and iterm2 on mac. I also installed gitstatus, but that didn't work when I installed it two days ago, and powerline worked just fine yesterday without gistatus functioning. Today, when I booted up the terminal, this error showed instead of the prompt.
Any advice? Where can I find the full log of the errors/interpret this message? Alternatively, how can I pinpoint which file has an error on line 55?
There error was in a color config file for the github integration. I was missing a comma at between lines. I believe it was in this file .config/powerline/colorschemes/default.json or another json related to it; see here.
Ultimately, I recommend moving to powerlevel10k. You can configure it to look exactly like powerline, but it a) updates cleanly (compared to powerline where if you update your python it breaks horribly) and b) comes with a really good customization setup and c) lets you use zsh + oh-my-zsh which gives so much additional functionality
I'm trying to run the brilliant Mar I/O artificial intelligence written in Lua (more on this at https://youtu.be/qv6UVOQ0F44)
The AI runs successfully in the Lua (v.5.1) console of the BizHawk emulator (v.2.1.1), but I'm getting an error when trying to reload a previous state of the algorithm.
After opening the file, it seems like file:read("*number") will always return 0, whereas read("*all") and "*line" both read the content correctly. I've also tried "*n" with no luck.
Full script at: https://pastebin.com/ZZmSNaHX
function loadFile(filename)
local file = io.open(filename, "r")
pool = newPool()
pool.generation = file:read("*number")
pool.maxFitness = file:read("*number")
...
function writeFile(filename)
local file = io.open(filename, "w")
file:write(pool.generation .. "\n")
file:write(pool.maxFitness .. "\n")
...
The file generated starts with:
18[LF]
1938[LF]
...
But still, I only see 0s in the console:
console.writeline("Gen " .. pool.generation) --> "Gen 0"
console.writeline("Max Fitness " .. pool.maxFitness) --> "Max Fitness 0"
What's also puzzling is that this script has been discussed in different forums and no one seems to report the same issue.
I found out that the BizHawk emulator is using a customized version of Lua.
This issue appeared in version 2.1.1 of the emulator. Previous releases are working fine.
Thanks for your help community
The format to read a number is 'n', file:read('n'). See https://www.lua.org/manual/5.3/manual.html#pdf-file:read for details on read() format specifiers.
Around that time, BizHawk added an alternate c# lua implementation 'kopilua' in an effort to workaround deep crashy problems. One of kopilua's several shortcomings is noncompliant string parsing and file IO. You must use config > customize > advanced > Lua+LuaInterface in order to use normal lua; it won't have this problem.
I am using CCL Lisp to run batches of experiments in parallel. On my machine, everything is running fine. However, I would like to use this on a server. When I execute this on a server, I always get the following error message:
> Error: on #<BASIC-CHARACTER-OUTPUT-STREAM UTF-8 (PIPE/7) #x302001C2725D> :
> Broken pipe during write
> While executing: #<CCL::STANDARD-KERNEL-METHOD CCL::STREAM-IO-ERROR (STREAM T T)>, in process listener(1).
My code always reaches the same point when trowing this error. An excerpt of the code is given below:
;; ... A really long function
;; write commands to processes
(format t ".. writing commands to process ~a:~%" counter)
(loop for c in commands
do
(format t " ~a~%" c)
(write-string c output-stream)
(princ #\lf output-stream))
(force-output t)
(force-output output-stream)
(finish-output output-stream)
#-lispworks
(close output-stream))
I think this error occurs inside the loop statement, since not all of the commands are written to the output stream.
How can I further debug this and solve this issue?
"Broken pipe" means that the process which is supposed to be reading from the pipe is dead when the Lisp process is writing to the pipe.
IOW, the problem is probably outside of Lisp. You need to see what is happening with the other process.
PS. You can combine your write-string and princ into a single write-line. Also, you don't need force-output if you are calling finish-output immediately.
I'm making a function that can read the metadata of the current song playing in spotify. This is being programmed in lua since it is an implementation for awesome wm. I got the following line to get all the metadata that I can later use.
handle = io.popen('qdbus org.mpris.MediaPlayer2.spotify /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Metadata | awk -F: \'{$1=\"\";$2=\"\";print substr($0,4)}\'')
However when Spotify is not running I don't get the expected information and qdbus writes an error to the stderr stream. I wanted to use the fact that qdbus writes to the error stream to determine a fault and stop the program there. (This should also catch any other errors not related to wheter spotify is running or not)
My understanding is that lua popen uses popen3 that can subdivide between stdout and stderr. but all my efforts so far are fruitless and my error stream is always empty. Is it possible to check for a non nil value in the stderr in order to determine a faulty call to qdbus (or awk)?
thanks!
I think you can redirect stderr to stdout in the call to popen like this:
handle = io.popen("somecommand 2>&1")
If you want to differentiate stderr and stdout, you cannot do it with the io library but you can with luaposix. See this answer for instance.
You can checkout juci.exec which I wrote for JUCI webgui. I struggled with the same problem and I ended up using luaposix for this kind of thing when I really need two separate streams. My implementation also gives you the program exit code which is good for testing for errors: https://github.com/mkschreder/juci/blob/master/juci/lua/core.lua
I'm working on a system to convert a bunch of .mov files to H.264 (using HandBrakeCLI) and webm (using ffmpeg) as the .mov files are created. In general, things are going very well. I'm hung up on a bit of error detection. I want to know if one of the encodings failed so that we can investigate, try again, etc.
To test encoding failure, I copied a text file into a file with a .mov extention, and set the programs about trying to encode it. Naturally, they both fail to encode the file (I'm not sure what "success" would mean in this context...) However, while ffmpeg reports this failure by setting its exit code to 1, HandBrakeCLI sets the exit code to 0, because it exited cleanly. This is consistent with the HandBrakeCLI documentation but it leaves me wondering how I can tell if HandBrakeCLI knows if it failed to encode anything. That same documentation page suggests "If you want to monitor HandBrake's process, you should monitor the standard pipes", so I'm now getting the effect that I want by doing something like this:
HandBrakeCLI --preset 'Normal' --input bad.mov --output out.mv4 2>&1 | grep 'Encode done'
grep then sets its exit code to 0 if it found a match, and 1 if it didn't. But, this seems rather barbaric: for instance, the text "Encode done!" could change in a future release of HandBrake.
So, anyone have a better way to tell if HandBrake encoded something or not?
Some edited shell output is included below for reference...
$ ffmpeg -i 'develqueuedir/B_BH_120409.mov' 'develqueuedir/B_BH_120409.webm'
FFmpeg version 0.6.4-4:0.6.4-0ubuntu0.11.04.1, Copyright (c) 2000-2010 the Libav Developers
[snip]
develqueuedir/B_BH_120409.mov: Invalid data found when processing input
$ echo $?
1
$ HandBrakeCLI --preset 'Normal' --maxWidth 720 --optimize --input 'develqueuedir/B_BH_120409.mov' --output 'develqueuedir/B_BH_120409.mv4'
Output format couldn't be guessed from file name, using default.
[11:45:45] hb_init: starting libhb thread
HandBrake 0.9.6 (2012022900) - Linux x86_64 - http://handbrake.fr
Opening develqueuedir/B_BH_120409.mov...
[snip]
[11:45:45] libhb: scan thread found 0 valid title(s)
No title found.
HandBrake has exited.
$ echo $?
0
Short answer is no , you can find detailed explanation at HandBrake forum https://forum.handbrake.fr/viewtopic.php?f=12&t=18559&p=85529&hilit=return+code#p85529
adddition:
I think that there is a patch from user fonkprop that is rejected by developers , if you really need it contact that guy
Good news! It appears that this feature is about to be implemented in HandBrake-CLI 0.10. As you can read on the roadmap for the 0.10 milestone:
Basic support for return codes from the CLI. (0 = No Error, 1 = Cancelled, 2 = Invalid Input, 3 = Initialization error, 4 = Unknown Error")