I have a local server that starts two GStreamer pipelines to my computer, but it needs to stop and start the streams occasionally. I am using a lavfi-complex to stack the streams as well. When the server stops the stream and starts again (to the same IP address and ports) I get a flood of this message:
sdp: RTP: dropping old packet received too late
I start the streams by loadfile then video-add then settings lavfi-filter property to [vid1][vid2] vstack [vo]. If I only have one stream and no filter (just loadfile) I can stop the server, start it again, and run loadfile again and the files load. However with a lavfi-filter, the documentation says:
It's not possible to change the tracks connected to the filter at runtime, unless you explicitly change the lavfi-complex property and set new track assignments. When the graph is changed, the track selection is changed according to the used labels as well.
I can change the lavfi-filter property to an empty string, send a loadfile command again, and then set the lavfi-filter back, but the output stays blank. I tried loadfile and video-reload with id=2 for the second video but the video-reload command fails.
Is there a sequence of commands that can cause mpv to stop and reload the streams? Or even better, some configuration parameters that will make it not drop old packets?
Related
I have a log4cpp implementation in a multiple process environment . Logger is configured once during initialization and then is shared among forked processes which server http requests.
During first minute or so , I see the logs rolls perfectly fine at the query per second load( say it runs at 100qps).
After that, the log slows down dramatically. So, I logged pid as well and notice that only one process gets to write to the log for a time duration ( around 10-15 seconds) and then another process starts writing and so on so forth . Processes don't die. They just don't get a chance to write.
This is different from what happens when the server starts . At that time, every other log line is written by a different process. ( Also, I write one-log-line per process at the end of serving the request. )
At this point, I can't think of what could be going wrong.
This is how my log4cpp conf file looks
log4cpp.rootCategory=DEBUG,rootAppender
log4cpp.appender.rootAppender=org.apache.log4cpp.RollingFileAppender
log4cpp.appender.rootAppender.fileName=/tmp/mylogfile.log
log4cpp.appender.rootAppender.layout=org.apache.log4cpp.PatternLayout
log4cpp.appender.rootAppender.layout.ConversionPattern=%d|%p|%m%n
log4cpp.category.http.server.main=INFO,MAIN
log4cpp.additivity.http.server.main=false
log4cpp.appender.MAIN=org.apache.log4cpp.RollingFileAppender
log4cpp.appender.MAIN.maxBackupIndex=10
log4cpp.appender.MAIN.maxFileAge=1
log4cpp.appender.MAIN.append=true
log4cpp.appender.MAIN.fileName=/tmp/mylogfile.log
log4cpp.appender.MAIN.layout=org.apache.log4cpp.PatternLayout
log4cpp.appender.MAIN.layout.ConversionPattern=%d|%p|%m%n
Edit: more updates : Thanks #Botje for your time.
I see that whenever a new child process is created , it is only that process that gets to write to the log. That tells me that all the reference other processes were holding become invalid.
I also tried setting additive property to true. With that , server starts properly writing into the /tmp/myfile.log and then switches to writing into /tmp/myfile.log.1 withing a minute . And then stops writing after a minute.
At that point logs gets directed to stderr which is directed to another log file.
Also,
I did notice that the log4cpp FileAppender uses seek to determine the file size before writing log entries. If the file handle is shared between processes that will cause writes to end up at the start of the file instead of the end. Even if you fix that, you still have multiple processes that think they are in charge of log file rotation.
I suggest you have all processes write to a common udp/tcp/Unix socket and designate one process that collects all log entries and actually writes it to a file. You don't have to reinvent the wheel, you can use the syslog protocol and either the system syslog or a copy running in userspace.
I am using boost::last_write_time as one of my checks to see if a file has been modified or not.
The call works fine if the file I am using is a local file.
But if I request the same information for a file from a network drive, I get wrong result.
The call I make is : boost::filesystem::last_write_time( file_path )
I am connected to the drive through VPN. The result is wrong only for the first time I make a request after modifying the file. The next call returns the right time.
The wrong time I get is always the old modification time(the one prior to the new change).
It doesn't matter if I wait a while before making the request. The first time is always wrong and the second time I get the correct one.
I am working on a mac. And I see that internally the method makes use of stat function.
I tried passing the error_code struct to see if there was any error. But it held 0 after the call.
Is there any limitation related to getting status of files over a network using stat method?
Is there any function that I could call to ensure that the last_write_method always returns the right time(other than calling the method twice)?
ADDITIONAL INFORMATION:
Found some additional info on: IBM Knowledge Center
In usage notes, bullet 6 on "Network File System Differences" says:
Local access to remote files through the Network File System may produce unexpected results due to conditions at the server...
...The local Network File System also impacts operations that retrieve file attributes. Recent changes at the server may not be available at your client yet, and old values may be returned from operations. (Several options on the Add Mounted File System (ADDMFS) command determine the time between refresh operations of local data.)
But I still don't understand why the call works correctly the second time, even when the call is made immediately after the first one.
And why it doesn't work if I wait for some time before I make the first call.
I have my own MediaSink in Windows Media Foundation with one stream. In the OnClockStart method, I instruct the stream to queue (i) MEStreamStarted and (ii) MEStreamSinkRequestSample on itself. For implementing the queue, I use the IMFMediaEventQueue, and using the mtrace tool, I can also see that someone dequeues the event.
The problem is that ProcessSample of my stream is actually never called. This also has the effect that no further samples are requested, because this is done after processing a sample like in https://github.com/Microsoft/Windows-classic-samples/tree/master/Samples/DX11VideoRenderer.
Is the described approach the right way to implement the sink? If not, what would be the right way? If so, where could I search for the problem?
Some background info: The sink is an RTSP sink based on live555. Since the latter is also sink-driven, I thought it would be a good idea queuing a MEStreamSinkRequestSample whenever live555 requests more data from me. This is working as intended.
However, the solution has the problem that new samples are only requested as long as a client is connected to live555. If I now add a tee before the sink, eg to show a local preview, the system gets out of control, because the tee accumulates samples on the output of my sink which are never fetched. I then started playing around with discardable samples (cf. https://social.msdn.microsoft.com/Forums/sharepoint/en-US/5065a7cd-3c63-43e8-8f70-be777c89b38e/mixing-rate-sink-and-rateless-sink-on-a-tee-node?forum=mediafoundationdevelopment), but the problem is either that the stream does not start, queues are growing or the frame rate of the faster sink is artificially limited depending on which side is discardable.
Therefore, the next idea was rewriting my sink such that it always requests a new sample when it has processed the current one and puts all samples in a ring buffer for live555 such that whenever clients are connected, they can retrieve their data from there, and otherwise, the samples are just discarded. This does not work at all. Now, my sink does not get anything even without the tee.
The observation is: if I just request a lot of samples (as in the original approach), at some point, I get data. However, if I request only one (I also tried moderately larger numbers up to 5), ProcessSample is just not called, so no subsequent requests can be generated. I send MeStreamStarted once the clock is started or restarted exactly as described on https://msdn.microsoft.com/en-us/library/windows/desktop/ms701626, and after that, I request the first sample. In my understanding, MEStreamSinkRequestSample should not get lost, so I should get something even on a single request. Is that a misunderstanding? Should I request until I get something?
I used GetLastInputInfo for check last input info from mouse and keyboard.
On my system on PC is working correctly, but when I run my program on my laptop it does not working.
I see that LASTINPUTINFO changing every 10-15 sec.
Now, I am writing example program for check all input from mouse and keyboard and save last input time from this device but this time not changing if I idle.
How can I check who is generate Activity (device/program) and change struct LASTINPUTINFO?
You can use Raw Input to see if the activity is coming from the actual mouse/keyboard itself. If it is, you might have a faulty device driver, or a driver that is running some kind of internal timer to generate a steady flow of input events.
If GetLastInputInfo() updates without Raw activity being reported, than a running app is most likely using an input injection API like mouse_event(), keybd_event(), or SendInput(). You would have to hook those directly to find out which app is calling them.
On the application I'm working on, which uses Gstreamer 0.10, we receive streaming audio data from a TCP socket (from another process running locally).
We can issue "seek" command to the process, which is working: we start receiving data corresponding the new position we specify.
So far so good.
However, there is delay between the time we issue the seek and the time we start playing the data at the correct position.
I'm pretty sure this is because we buffer data.
So I would like to flush the data buffered in our pipeline when we issue the seek command.
However, I didn't managed to do this: I used gst_pad_push_event (gst_event_new_flush_start()) on the pad, then gst_event_new_flush_stop short after, which both return TRUE.
However, music stops, and never start again.
Using export GST_DEBUG=2 I can see the following warning:
gdpdepay gstgdpdepay.c:429:gst_gdp_depay_chain:<gdpdepay-1> pushing depayloaded buffer returned -2
As the other process continue to push data while flush might be "on" for a short amount of time, that might explain this warning. But I would expect the other process to be able to continue to push data, and our pipeline to be able to continue to read data from this socket and process them in the pipeline, after sending a flush_stop event.
Googling this issue, I found some suggestions like changing the pipeline state, but that didn't help either.
Any help very welcome!