BtbN changed the topic of #ffmpeg to: Welcome to the FFmpeg USER support channel | Development channel: #ffmpeg-devel | Bug reports: https://ffmpeg.org/bugreports.html | Wiki: https://trac.ffmpeg.org/ | This channel is publically logged | FFmpeg 7.0 is released
lucasta has joined #ffmpeg
iive has quit [Quit: They came for me...]
cmc has quit [Ping timeout: 260 seconds]
lec_thege8042726 has quit [Read error: Connection reset by peer]
lucasta has quit [Remote host closed the connection]
<travisghansen>
what would be the best way to approach capturing a series of images (unknown/sporadic fps) and provide those as a secondary input to an ffmpeg instance with the absolute lowest latency possible? I have tried capturing the images and writing to an shm file location and then doing a rename with something like -f image2 -loop 1 -i
<travisghansen>
/dev/shm/overlay.jpg...it seems to work pretty solidly, but has about 1s delay
<travisghansen>
alternatively, I tried writing the data to a 2nd ffmpeg instance over stdin and then having that instance write to a udp port..which in turn was a raw udp input to my primary ffmpeg instance. That seemed to choke due to irregular rate of images :(
cmc has joined #ffmpeg
<DeHackEd>
what is the second instance of ffmpeg doing? it's entirely possible one ffmpeg instance can do both jobs
<Marth64>
^
<travisghansen>
DeHackEd: I'll use the term secondary..it was taking the input of raw images over stdin and pushing to udp://localhost:xxx
<travisghansen>
then the primary ffmpeg instance was setup with some logic like: OPTIONS.push('-f', 'mpegts', '-i', 'udp://localhost:20000');
<travisghansen>
if I rather pointed the input to a static video file all worked great, but when using that it was really a problem and as I recall would just crash (been a few weeks since I messed with it)
Marth64 has quit [Quit: Leaving]
<travisghansen>
currently I'm using an image file as the input to the primary ffmpeg and then have an out-of-band process which simply overwrites the file as quickly as the data comes through...but to make it function well, I have to write the file data as an atomic action so I capture the new image data, write it to a tmp fine, then rename (all of which I think
<travisghansen>
is attributing to the 1+s delay)
YuGiOhJCJ has joined #ffmpeg
kasper93 has quit [Ping timeout: 265 seconds]
Unit641 has quit [Quit: Leaving]
kasper93 has joined #ffmpeg
<travisghansen>
for context, I am using puppeteer screen capture api to collect screenshots of a headless browser image (I would love for ffmpeg to have a built-in feature using the cef btw) and trying to overlay a 'browser' over the top of a video in real-time
<travisghansen>
I'm dealing with sports related content so latency/timing are critical for the best experience
x_x has quit [Ping timeout: 260 seconds]
Marth64 has joined #ffmpeg
kasper93_ has joined #ffmpeg
kasper93 has quit [Ping timeout: 265 seconds]
kasper93_ has quit [Ping timeout: 260 seconds]
Tano has joined #ffmpeg
kasper93 has joined #ffmpeg
Suchiman has quit [Quit: Connection closed for inactivity]
rex has quit [Read error: Connection reset by peer]
rex has joined #ffmpeg
kasper93 has quit [Ping timeout: 260 seconds]
<Marth64>
Lynne: fixed truehd
<Marth64>
ended up being simple issue. mpeg-ts demuxer adds ac3 core substream as stream with same pid and i wasn't setting one up
<Lynne>
oh, right, compatibility streams
<Lynne>
really needs seeking though
<Marth64>
working on it
<Marth64>
:)
<ZLima12>
Marth64: oh hi, how has the DVD demuxer been working? (I reported the early EOF issue a few months ago)
<Marth64>
Marth64: Hi, sorry I never saw the report. but it's fixed
<Marth64>
well, I have a patchset up
<ZLima12>
Oh no, I just meant I emailed you. I didn't make a proper report
lavaball has quit [Remote host closed the connection]
<Marth64>
Ohhh, the DVD_WAIT issue?
<Marth64>
DVDNAV_WAIT*
<ZLima12>
yep
<Marth64>
that's fixed and merged in latest version! thanks again for the report
<Marth64>
there is a different more subtle early EOF issue which is also fixed but in review (impacting 1-4 frames at the end of the demux)
<ZLima12>
Interesting, well I'm glad all the quirks of the format are getting worked out in the demuxer
<Marth64>
yes it is maturing
<ZLima12>
I haven't been ripping much lately so I haven't been able to test
<Marth64>
i want to add automated test some day
evilscreww has joined #ffmpeg
TheSilentLink has quit [Quit: Good Bye! My bouncer has probably crashed or lost connection to the internet...]
luna- has quit [Remote host closed the connection]
luna- has joined #ffmpeg
Unit640 has quit [Ping timeout: 265 seconds]
zsoltiv_ has joined #ffmpeg
x_x has quit [Quit: upgrading kernel, goodbye everyone]
Suchiman has joined #ffmpeg
x_x has joined #ffmpeg
lavaball has quit [Remote host closed the connection]
Unit640 has joined #ffmpeg
Bertl has joined #ffmpeg
<Bertl>
greetings! I've been working on a problem I considered simple for some time but so far failed to find a proper solution. here is a short description what I'm trying to do
<Bertl>
I have a capture card (magewell) which acquires HDMI video data from various devices (e.g. a raspberry pi) and I would like to display the captured data on my screen with minimal latency and reasonably high framerate (e.g. 60 FPS) like picture in picture just more comfortable :)
<Bertl>
the capture card is designed for low latency and the monitor is working at 60Hz (can do up to 144Hz) so the input and output should not be a limitation
<Bertl>
I also do not need to record anything so any encoding/decoding is limited to color space transformations and even that should not matter as the capture card can provide RGB data and the display is obviously able to handle RGB as well
<Bertl>
when I use ffplay (version 5.1.6 from my distribution) without special options, I get a picture, but it has two issues
<Bertl>
first, it is choppy, i.e. a blinking cursor does not blink as it would on actual picture in picture (which the monitor can do) so sometimes you see the cursor blink really fast and sometimes it slows down to almost a halt
<StephenLynx>
i wonder if it's being able to go through hardware acceleration.
<Bertl>
secondly, the delay between the actual output and the display on screen seems to continuously increase, i.e. in the beginning, it is in sync, but after a couple of minutes, the delay is several seconds
<Bertl>
StephenLynx: how can I check?
<StephenLynx>
i got no idea. was just the first thing that went through my mind.
<Bertl>
ah, okay, well, I found a number of recipies online how to get very low latency and whatnot and tried a lot of them with partial improvements
<Bertl>
first, there was turning off audio (I don't use/have audio on that) with -an
<Bertl>
then there was tuning for low latency with "-tune zerolatency"
<Bertl>
but I think that only works with network streams ...
<Bertl>
then there is turning off the buffering with "-fflags nobuffer"
<Bertl>
and some more options like "-maxdelay 0" or "-sync video" or "-flags +low_delay"
<Bertl>
the only option which changed the result significantly was the "-sync video" which made the cursor mostly blink as expected, but using that one results in constantly increasing delays between the actual image and the display (up to minutes)
<Bertl>
so I was wondering, is there an option which tells ffplay to 'simply' grab the most recent frame and display it as fast as possible without buffering or resynchronizing? ideally, can this be done at the capture/display frequency to avoid tearing?
Sakura`Kinomoto has quit [Remote host closed the connection]
Juest has quit [Ping timeout: 248 seconds]
coldfeet has joined #ffmpeg
Juest has joined #ffmpeg
Sakura`Kinomoto has joined #ffmpeg
Juest has quit [Ping timeout: 264 seconds]
Juest has joined #ffmpeg
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #ffmpeg
Sketch has quit [Ping timeout: 248 seconds]
makidoll has quit [Ping timeout: 260 seconds]
Juest has quit [Ping timeout: 252 seconds]
l4yer has joined #ffmpeg
l4yer has quit [Max SendQ exceeded]
l4yer has joined #ffmpeg
Sl4yer has quit [Ping timeout: 252 seconds]
Juest has joined #ffmpeg
Nact has quit [Quit: Konversation terminated!]
Sketch has joined #ffmpeg
Marth64 has joined #ffmpeg
jtgd has quit [Quit: WeeChat 4.4.2]
jtgd has joined #ffmpeg
lavaball has joined #ffmpeg
FlorianBad has quit [Remote host closed the connection]
FlorianBad has joined #ffmpeg
makidoll has joined #ffmpeg
coldfeet has quit [Remote host closed the connection]
rv1sr has quit []
drew has quit [Ping timeout: 244 seconds]
drew has joined #ffmpeg
luna- has quit [Ping timeout: 252 seconds]
lucasta has joined #ffmpeg
Juesto has joined #ffmpeg
Juest has quit [Ping timeout: 260 seconds]
Juesto is now known as Juest
Sakura`Kinomoto has quit [Remote host closed the connection]
SuicideShow has quit [Ping timeout: 246 seconds]
Sakura`Kinomoto has joined #ffmpeg
SuicideShow has joined #ffmpeg
Unit640 has quit [Quit: Leaving]
Juest has quit [Ping timeout: 260 seconds]
Juest has joined #ffmpeg
kasper93 has quit [Remote host closed the connection]