I'm using 'vlc/ffmpeg' package to grab the screen and convert it to H.264 file.
The problem arises when the host is heavily loaded. I need to maintain correct time stamps and use the 5 fps (relatively low frame rate). Yet sometimes the resulting file jumps few seconds forward, apparently due to frame loss.
I can deal with the frame loss, it's OK, but I need to duplicate lost frames to maintain correct timing.
My configuration file:
vlc.exe screen:// -I dummy --verbose=2 --one-instance :screen-fps=5 :screen-caching=10000 :sout=#transcode{venc=x264{preset=ultrafast,tune=zerolatency},vcodec=h264,fps=5,vb=3000,width=1024,height=576,acodec=none}:file{dst="C:\tmp\output.mp4"}
What should I add/config to preserve proper time stamps and clip duration?
Many thanks for your help.
OK, I found adding 'copyts' option does exactly what I need.
Related
Hi there I am aiming to record 1 hr videos at 500x375) from a raspberry pi (running 64-bit bullseye) which need to be recorded in such a way that they can endure unexpected program termination or system shutdown.
Currently I am using a bash script utilising libcamera-vid and libav:
libcamera-vid -t $filmDuration --framerate 5 --width 500 --height 375 --nopreview --codec libav --libav-format avi -o "$(date +%Y%m%d_%H%M.avi)" --tuning-file /usr/share/libcamera/ipa/raspberrypi/imx219_noir.json
I initially encoded h.264 as mp4 but found that any interruption of the script would corrupt the file and I lack the understanding to work around this (though I suspect a method exists). The avi format on the other hand seems more robust and so I moved to using it but I am having a fairly serious issue by which the file appears to think the video is running at 600fps, rather than 5.
As far as I can tell this is not the case and there has been no loss in video duration that I would expect if the frames were being condensed but the machine learning toolkit (utilising openCV) these videos are recorded for takes the fps information as part of its novel video analysis effectively making it unable to analyse them.
I am not sure why exactly this is occurring or how to fix it but any advice would be very welcome; including any suggestions for other encoding software or solutions to recording to mp4 in a way that avoids corruption.
Not resolved as such but after opening an issue at the libcamera-apps repo this behaviour has been replicated and confirmed to be unintended.
While a similar issue that was effecting the mkv format incorrectly reporting its fps (as 30 according ffprobe) has been fixed, currently the issue with avi files incorrectly reporting fps has not.
Edit: New update to the libcamera-apps has now fixed the avi issue as well according to latest commit.
I'm writing a player for an RTMP stream using the ffmpeg API. I know the usual way to get the stream info into an input format is with avformat_find_stream_info. And that works. However, because it's RTMP it takes a long time for it to scan enough of the stream to pick up the info. I've played with max_analyze_duration and probesize and it's a bit better, but it still takes 10-15 seconds to load. That's way too long for my application.
But I'm the one making the stream on the other end, so I know exactly what's in it. It seems like it would make more sense for me to tell the input format what the stream info is rather than asking it to search for it. But I can't find any examples of this, and my attempts to use avformat_new_stream with an input format aren't working.
Does anyone know if this is possible? And if so, could you point me in the direction of how?
Thanks!
This is what is known as an XY problem
Yes, you can spoof the sequence header (assuming h.264/aac). But it won't accomplish what you want. What is happening is your RTMP server (reflector) is eating the first GOP. So even if the analyze was done faster, you must first wait for the first video key frame anyway.
You need to configure your RTMP server to send the full GOP (in nginx+rtmp the setting is wait_key on)
I've unsuccessfully mucked around with this on my own and need help.
Given the public Web camera feed at https://itsvideo.arlingtonva.us:8011/live/cam58.stream/playlist.m3u8 I'd like to be able to be able to capture the video feed into an MP4 or MPG file with a reasonably accurate timestamp using the Windows command line (so I can put it into a batch script, etc.).
This is probably easy for someone who is already a wiz with VLC or FFmpeg or some such tool.
Additional wish list items would be to call up a higher resolution stream for a shorter duration (so as to balance I/O impact) and/or to just get still images instead of the video offered.
For instance, the m3u file has the following parameters:
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=214105,CODECS="avc1.100.40",RESOLUTION=352x288
chunklist_w977413411.m3u8
Would there be a way to substitute any of these to increase the resolution and reduce the video duration in a corresponding way so that net I/O is the same? Or even to just get a still image, whether higher res or not?
First problem is with audio rescaling. I'm trying to redo doc/examples/transcode_aac.c so that it also resamples from 41100 to 48000, it contained a warning that it can't do it.
Using doc/examples/resampling_audio.c as a reference, I saw that before doing swr_convert, I need to find the number of audio samples at the output with the code like this:
int dst_nb_samples = av_rescale_rnd( input_frame->nb_samples + swr_get_delay(resampler_context, 41100),
48000, 41100, AV_ROUND_UP);
Problem is, when I just set int dst_nb_samples = input_frame->nb_samples (which is 1024), it encodes and plays normally, but when I do that av_rescale_rnd thing (which results in 1196), audio is slowed down and distorted, like there are skips in the audio.
Second problem is with trying to mux webm with opus audio.
When I set AVStream->time_base to 1/48000, and increase AVFrame->pts by 960, the resulted file is played in the player as a file that is much bigger. 17 seconds audio shows as 16m11s audio, but it plays normally.
When I increase pts by 20, it displays normally, but has a lot of [libopus # 00ffa660] Queue input is backward in time messages during the encoding. Same for pts 30, still has those messages.
Should I try time_scale 1/1000? webm always have timecodes in milliseconds, and opus have packet size of 20ms (960 samples at 48000 Hz).
Search for pts += 20;
Here is the whole file, all modification I did are marked with //MINE: http://www.mediafire.com/file/jlgo7x4hiz7bw64/transcode_aac.c
Here is the file I tested it on http://www.mediafire.com/file/zdy0zarlqw3qn6s/480P_600K_71149981_soundonly.mkv
The easiest way to achieve that is by using swr_convert_frame which take a frame and resample it to a completely different one.
You can read more about it here: https://ffmpeg.org/doxygen/3.2/swresample_8h_source.html
dst_nb_samples can be calculated as this:
dst_nb_samples = 48000.0 / audio_stream->codec->sample_rate * inputAudioFrame->nb_samples;
Yours probably correct too, I didn't check, but this one I used before, confirm with yours but the number you gave check out. So real problem is probably somewhere else. Try to supply 960 samples in sync with video frames, to do this you need to store audio frames to an additional liner buffer. See if problem fixes.
And/or:
2ndly my experiences says audio pts increase as number of samples per frame (i.e. 960 for 50fps video for 48000hz (48000/50)), not by ms. If you supply 1196 samples, use pts += 1196 (if not used additional buffer I mentioned above). This is different then video frame pts. Hope that helps.
You are definitely in right path. I'll examine the source code if I have time. Anyway hope that helps.
I am using ffmpeg to save live streams with an .m3u8 url. Regularly I see the following message. This results in the output video freezing.
skipping 5 segments ahead, expired from playlists
How can I tell ffmpeg to just write the frames and ignore that they are expired? I would rather see a choppy video than having it just freeze.
Old question, but WTH... maybe it helps somebody.
If I understand the situation correctly, that message means that ffmpeg is skipping the download of 5 entire chunks ("segments").
It's not about "expired frames", but "chunks that I have scheduled for download, but are no longer published on the playlists".
5 chunks/segments may be several seconds long, and not just 5 frames. That's why you see a freeze.
Perhaps you could try using some filter with the input, so the output muxer may fill the segments gap. Take a look at the overlay filter, for example: https://ffmpeg.org/ffmpeg-filters.html#Examples-82