HarshK23 has quit [Quit: Connection closed for inactivity]
rvalue has quit [Ping timeout: 246 seconds]
fossdd has quit [Ping timeout: 256 seconds]
rvalue has joined #ffmpeg
fossdd has joined #ffmpeg
kasper93 has joined #ffmpeg
bibble has joined #ffmpeg
fossdd has quit [Ping timeout: 272 seconds]
fossdd has joined #ffmpeg
Kruppt has quit [Quit: Leaving]
Jhonny2x4 has quit [Read error: Connection reset by peer]
fossdd has quit [Ping timeout: 268 seconds]
fossdd has joined #ffmpeg
Marth64 has quit [Remote host closed the connection]
fossdd has quit [Ping timeout: 256 seconds]
fossdd has joined #ffmpeg
bitbinge has quit [Ping timeout: 255 seconds]
<FlorianBad>
I played around with `-sc_threshold` to see which keyframes it would pick as I go higher and higher, but after a certain point it refuses to pick more. Is there another way to force it to pick more (but not a fixed interval) so that I can see what it would pick?
Vonter has quit [Ping timeout: 264 seconds]
Vonter has joined #ffmpeg
<aaabbb>
FlorianBad: if scenecut detection is off then keyframes will always be put every keyframe intervals
<FlorianBad>
aaabbb, yeah but I don't want that for what I'm doing right now
<FlorianBad>
I'm just look at what keyframes x264 would pick as I tell it to be more and more, but -sc_threshold quick reaches a point where I would just not pick more so I can't find out
<aaabbb>
i misunderstood you then. -sc_threshold is the same as scenecut= iirc
<aaabbb>
and the keyint_min is also relevant
<FlorianBad>
no, that's if you set it to 0
<aaabbb>
i know but i mean -sc_threshold 0 is the same as scenecut=0 i believe
<FlorianBad>
otherwise it's a threshold that is supposed to determine how many scene-changes are detected (turned into keyframes)
<aaabbb>
if the threshold is so aggressive that it thinks everything is a scenecut, it will place a keyframe every keyint_min frames
<FlorianBad>
aaabbb, how would you set it that aggressive? I'd love to be able to do that, but it doesn't work
fossdd has quit [Ping timeout: 260 seconds]
<FlorianBad>
basically I tried with absurdly high values like -sc_threshold and I still get exactly the same keyframes as with -sc_threshold 500. There's a point where it stops becoming more sensitive even if I want it to
<FlorianBad>
sorry, like like -sc_threshold 30000
fossdd has joined #ffmpeg
<aaabbb>
FlorianBad: the top is INT_MAX
<FlorianBad>
which is 2^64?
<aaabbb>
2147483647
crmur__ is now known as orthoplex64
<FlorianBad>
oh, 2^31
<aaabbb>
from -2147483648 to 2147483647
<FlorianBad>
a sign integer
<FlorianBad>
signed
<aaabbb>
it's from INT_MIN to INT_MAX
<FlorianBad>
I know, I saw that, so you think I should try much much higher than 30000 ?
<aaabbb>
did you try -2147483648?
<FlorianBad>
negative?
<aaabbb>
because threshold implies that higher is less senitive
<FlorianBad>
hmmmmm!
<FlorianBad>
well, then that would explain it, hold on let me try negative... :)
bitbinge has joined #ffmpeg
<aaabbb>
on a random video, i got IPIPPPBPIPPPPBPBPPPPPPPBBPBPIPBPPPBBPPIPIPIP with -2147483648
fossdd has quit [Ping timeout: 256 seconds]
<FlorianBad>
ok lol
fossdd has joined #ffmpeg
<FlorianBad>
aaabbb, nope, I can't seem to get that. Can you copy your command?
<FlorianBad>
When I use 232 I get something different (41 keyframes in my video instead of 30) but that's pretty much the only among a few values that do anything. -2147483647 and 2147483647 both also result in 30 keyframes total just like value 1
<aaabbb>
i just used -sc_threshold -2147483648 and -g 300
<aaabbb>
when i used -sc_threshold 2147483647 and -g 300, i only got 1 keyframe for every 300 frames
fossdd has quit [Ping timeout: 272 seconds]
<FlorianBad>
hmm, so maybe it's only when it combination with -g ?
<aaabbb>
i don't think so, i just changed it from 250 to 300
<FlorianBad>
YES! it does need a -g, maybe as a reference point or something
<aaabbb>
i didn't see any difference when i removed that (also i used keyint= but it's the same thing)
<FlorianBad>
That's strange, that doesn't do it for me
<FlorianBad>
Is there A LOT of action in your video?
lexano has quit [Ping timeout: 252 seconds]
fossdd has joined #ffmpeg
<aaabbb>
no, it's awful 240p, very simple, was just an example
bitbinge has quit [Ping timeout: 255 seconds]
<FlorianBad>
If you use the exact same command I use, does it do the same?
<FlorianBad>
Because there might be something about my command that prevents that from working
lemourin has quit [Read error: Connection reset by peer]
Vonter has joined #ffmpeg
lemourin has joined #ffmpeg
<aaabbb>
FlorianBad: i think -sc_threshold passes all non-zero integers to scenecut= and everything negative just sets the default
<aaabbb>
so i went on a wild goose chase, it's just that -sc_threshold doesn't check == -1 to set the default, just checks < 0
<FlorianBad>
ok, but how come >0 values still give me the same thing even when I use all the way to 2147483647 ?
<FlorianBad>
There are only a few values that vaguely do something, like 232 e.g. for some reasons
<FlorianBad>
but generally speaking I always get about 1 keyframe every 6-9 sec no matter what I use
<FlorianBad>
My goal was to purposely set it higher and higher all the way to absurd values where everything becomes a keyframe, just so I can analyze what it would prefer as keyframes
Wenbin_Chen_ has joined #ffmpeg
<FlorianBad>
So maybe -sc_threshold is not the way to do that, I don't know, but I thought it would be
<aaabbb>
that doom9 thread talks a lot about it
HarshK23 has joined #ffmpeg
<aaabbb>
it sets an i frame if (100 * (bit size of P-frame) / (bit size of I-frame) < scenecut * (distance from previous keyframe) / keyint)
Wenbin_Chen has quit [Read error: Connection reset by peer]
<FlorianBad>
hmm, so would changing the ip ratio to make P crappy on purpose do the trick?
<aaabbb>
i mean maybe, but then you're tweaking something else and probably butching quality
<aaabbb>
why not just adjust keyint and keyint-min?
<FlorianBad>
Because I'm coding something for analysis purposes, not for actually encoding
<aaabbb>
oh, what is it you're trying to do?
<FlorianBad>
Basically I want to end up putting keyframes manually with -force_key_frames when I do the final encodings. That way if I ever re-encode a video to offer more resolutions/bitrates I will keep what was already encoded because the keyframes will be the same. So -f dash will slice these newly encoded segments at the same spot as the old ones.
<FlorianBad>
So now if I do that I'd better find out where are the best places to put these keyframes, but I do have my own constraints.
<aaabbb>
oh, i think there are better ways to do that than using scenecut
<aaabbb>
i think for your purposes, it would be better to just have a fixed interval
<FlorianBad>
So what I want to do ideally is to look at where would be the best spots, and then in my program I pick the best while still targeting an average keyint
<aaabbb>
why don't you just want one keyframe for each segment?
<FlorianBad>
Maybe another way to phrase what I want to do is: Is there a good way to give a score value to each frame as "difference between previous frames"? Because that's exactly what my program takes as input for that
<aaabbb>
like a difference metric? like getting the internal value of "difference" that scenecut detection uses?
<FlorianBad>
It's already 1 keyframe for each segment, but where is the question, and I don't want just a regular keyint, it's just silly to put an I frame right before changing the whole picture...
<FlorianBad>
YES! exactly
<FlorianBad>
I want that
<FlorianBad>
I already wrote all my program around it, so if I have that it's already ready for my code
<aaabbb>
tbh x264's scenecut detection isn't very good, if you're developing your own thing, you might want to use x265's which has much more advanced detection
<aaabbb>
but if you want something really simple, mpdecimate can drop frames that are "too similar" and i guess you could use the output of that as a sort of hacky way to detect frame differences
<FlorianBad>
hmmm! excellent. Would the parameters be the same?
<FlorianBad>
hmm, ok wonderful too
<aaabbb>
no its parameters are more complex, it also has several different types of scenecut detection
<aaabbb>
but i don't think it exposes that directly, you might be able to do stats-write to get its keyframe placement or something, but that's kinda hacky
<FlorianBad>
ok
<aaabbb>
FlorianBad: btw simply checking differences in frame isn't the best way to know where to place i frames
<aaabbb>
i'm still quite confused why you don't just place one keyframe every segment no matter what resolution/bitrate you use
<FlorianBad>
It IS one keyframe every segment, but segments will have different lengths
<aaabbb>
why?
<FlorianBad>
so I can slice where it's best
<aaabbb>
that seems like a really useless micro-optimization, and the overhead of sending smaller segments will probably be worse than the overhead of non-ideal keyframe placement
<FlorianBad>
no, there won't be that because my protocol can send multiple segments in the same request. Plus my encoder program doesn't just take anything, it also uses contraints, so it will pick the best keyframes but still approximately at a certain keyint
<aaabbb>
then the optimal number of keyframes is 1 per request
<FlorianBad>
what do you call a "request" ?
<aaabbb>
whatever the size of your segment is (ie where no frames need to reference frames that haven't yet been sent by your server)
<aaabbb>
s/segment/chunk of data you are sending at once/
<FlorianBad>
ok but that's just not how my player works
<aaabbb>
then your player is making non-ideal decisions. fewer keyframes is always better and the only reason you want a new keyframe is when you are sending a new segment
minimal has quit [Quit: Leaving]
<FlorianBad>
the amount of data sent in each request will be determined by many factors, including latency (and bandwidth) so if you just use a long or moderately long and one-size-fits-all keyint then this could never happen
<aaabbb>
ah
<aaabbb>
ok that makes sense. in that case then it'll be whatever the segment size is (that explains why you can't just sent one big segment for each request)
<FlorianBad>
yes. If my segments are reasonably small then I can choose to send 1, 2, 3, 4, depending on what's been happening lately in the stats
<aaabbb>
hmm
<aaabbb>
you want them to be as large as reasonable
<FlorianBad>
but it's these segments are all 10s I can't play with that at all
fossdd has quit [Ping timeout: 256 seconds]
<aaabbb>
what about 2s?
<FlorianBad>
Well, what my program does is first calculate an ideal target_keyint which it will try to stay around as much as possible. And that's dependent on what I passed as {action} parameter that determines how much action there is in that video to encode. So e.g. it might say target_keyint is about every 3s.
<FlorianBad>
From there what it does is find the best places to put these keyframes. It might be every 2.5s, then the next is 3.8s later, then 2.4, etc.
<FlorianBad>
And since I've already went through the pain of coding these micro-optimizations, then I'd be an idiot not to pick the best frame to do that each point in time
fossdd has joined #ffmpeg
<aaabbb>
so you basically want variable-sized segments that correspond to the gop, so that you can get the benefits of scenecut detection despite streaming?
<FlorianBad>
Which is why what I was doing here was trying to see where x264 would, by itself, put keyframes if I tell it to put more and more, but... I can't seem to be able to do that
<FlorianBad>
yes :)
<aaabbb>
ah!
<FlorianBad>
And another benefit of forcing these keyframes w/ -force_key_frames is that if I ever offer more resolutions/bitartes later I only have to encode the new ones, and it will be the same keyframes because my program saves that in a text file
<aaabbb>
then what you want to do is make a constraint between keyint-min and keyint, and only then use scenecut to vary between that
<FlorianBad>
hmm, let me try on that same png stuff to see what happens
epony has quit [Remote host closed the connection]
epony has joined #ffmpeg
Marth64 has joined #ffmpeg
Corroddity has quit [Changing host]
Corroddity has joined #ffmpeg
<FlorianBad>
aaabbb, nope, same thing. I just tried -x264-params "keyint=600:min-keyint=5:scenecut=$THRES" with $THRES from 1 to 2147483647 and I get the same nb of keyframes (which is keyint)
<FlorianBad>
(I mean the total nb of keyframes corresponds to that keyint interval of 600)
<aaabbb>
You should never ever set min-keyint that low
<FlorianBad>
aaabbb, yeah but that's the point, to find out what it would pick, not to actually encode
rvalue has joined #ffmpeg
<aaabbb>
FlorianBad: maybe try using x265 for that since it has more advanced scenecut detection
<FlorianBad>
ok, will check this out then, that sounds like a really good option actually
<FlorianBad>
well, I will find out because I'm testing it
epony has quit [Remote host closed the connection]
<FlorianBad>
yeah that seems to work REALLY well based on a few tests I've made
<FlorianBad>
a value of 1 is when all pixels change, then something like 0.3 is already clearly a scene change visually
wyatt8750 has joined #ffmpeg
<aaabbb>
nice
wyatt8740 has quit [Ping timeout: 272 seconds]
<FlorianBad>
then for keyframe considerations the values can still be pretty low, like in this confetti video, at ~10s when the confetti come out of the thing it's a value of 0.049 https://www.youtube.com/watch?v=THXqDUOpuJg
<FlorianBad>
one frame is the tube with nothing around, the next frame is blowing up above it (because it's so fast) so that would clearly be a good I-frame
<FlorianBad>
I sorted them and then look at the frames individually and it's obvious. e.g. during the confetti fallout every time there's a higher score it's when a huge confetti suddenly comes in the frame in front of the camera, making a lot of pixels change
<FlorianBad>
but we're still talking about 0.01 - 0.02 range... so it's always tiny numbers
<FlorianBad>
Only problem is that I don't really understand the command lol
<FlorianBad>
Not sure why he needs to input things via echo
<aaabbb>
just make sure your keyframe-min isn't too small
<aaabbb>
never more than 1s in most cases
<FlorianBad>
I won't have any, I use -force_key_frames
<FlorianBad>
with the list of all times that correspond to each frame that my program selected to become keyframes
<aaabbb>
then you should choose one manually
<aaabbb>
otherwise you might end up with keyframes too close to each other
<FlorianBad>
ah! his echo "" was just a label... I was wondering how the hack it gets passed to ffmpeg... it doesn't :)
<FlorianBad>
aaabbb, won't happen, my algorithm will just never do that
<aaabbb>
ah ok
<aaabbb>
i'm skeptical that your algorithm would make better scenecut decisions than x264 or x265 tho
<FlorianBad>
it's not so much better, it's that 1. It will stay within certain constraints that x264 wouldn't respect unless it's a fixed keyint. 2. Because I force them I can re-encode later if I ever decide to offer more resolutions/bitrates and keep the same ones (meaning I don't have to redo the whole dash and all files that were already encoded
<aaabbb>
FlorianBad: i think there are ways to save the frame type choices for later encoding
<aaabbb>
i know stats-write can do that but i don't think that would work well with very diffrent bitrates
<FlorianBad>
yeah but the choices just suck, it's either fixed keyint or it's super long and doesn't respect much what you want
<FlorianBad>
aaabbb, you helped me a lot so I'll share my program when I done. Not really useful for most people as it is but can be easily modified to make it work for what you might want
<aaabbb>
thanks :)
<FlorianBad>
aaabbb, basically it goes like this:
<FlorianBad>
1. Select the most obvious scenecuts as original keyframes by going through them by highest score first, but don't pick one if it is closer than target_keyin * 3 from another one already picked
<FlorianBad>
(so after 1 you end up with very approximately 3x your target keyint, all confiugrable)
<aaabbb>
there are some research papers that go into scenecut detection btw
nrg has joined #ffmpeg
<FlorianBad>
2. go through each already picked keyframe in order (so frame 0 first), and look at all possible best scores target_keyint later, but boost their score based on how close they are from that target (and if you're keyint*0.5 from that target your score basically goes to nothing so it won't pick that)
<FlorianBad>
x is how close that supposedly good scenecut frame is from the next target, 0 being exactly 1 keyint after the previous keyframe selected, and 0.5 being target_keyint/2
<FlorianBad>
So basically you end up with scores and probabilities, and naturally it will be an average of target_keyint, but still on the best spots
Marth64 has quit [Remote host closed the connection]
<aaabbb>
FlorianBad: are you going to test the ssim scores at a fixed bitrate with your technique to see what provides the best quality?
Vonter has quit [Ping timeout: 252 seconds]
Vonter has joined #ffmpeg
<FlorianBad>
aaabbb, no because I already want an average specific target_keyint, so if e.g. target_keyint is 90 for ever 3s, the question is really "Do I put that second I-frame at frame 89 or frame 102?" And the answer is quite obvious, whichever has the greatest SSIM score while being the closest to 90 (so multiplying both scores)
<FlorianBad>
s/for ever/for every/
<aaabbb>
FlorianBad: you have to test more than just a few frames for the ssim score to matter
<FlorianBad>
"both scores" meaning "SSIM x proximity"
<FlorianBad>
what do you mean?
<FlorianBad>
It looks at all frames individually
<FlorianBad>
and calculates all scores
<aaabbb>
ah ok i thought you meant only frames 89-102
Suchiman has quit [Quit: Connection closed for inactivity]
Marth64 has joined #ffmpeg
AbleBacon has quit [Read error: Connection reset by peer]
JanC has quit [Ping timeout: 255 seconds]
<FlorianBad>
aaabbb, BTW, is that the best way to force dash to slice at each I-frame? -adaptation_sets "id=0,seg_duration=0.001,frag_type=pframes,streams=0 ..."
<FlorianBad>
around line 500 you can see how it picks the best keyframes, the comments explain that
jagannatharjun has joined #ffmpeg
<FlorianBad>
It's a bit dirty and I need to test better, but so far it seems to work very well
fling has quit [Remote host closed the connection]
fling has joined #ffmpeg
<FlorianBad>
aaabbb, also I have to warn you, this is all VERY slow. I designed that for running it overnight and let it copy to server when it's done, so I wake up the next morning and it's all ready. Definitely not something for user-experience
sss1 has quit [Ping timeout: 252 seconds]
Marth64 has quit [Ping timeout: 260 seconds]
Marth64 has joined #ffmpeg
ivanich has joined #ffmpeg
<aaabbb>
oh it's perl, nice :)
<FlorianBad>
aaabbb, will finish it over the next few days and re-organize it a bit to make it cleaner too. Will let you know
<FlorianBad>
1.22am here... :/ Time to go, tomorrow will be DASH and if I have time I'll test the options you suggested: aq-mode, aq-strength and psy-rd
<FlorianBad>
Good night!
<FlorianBad>
And thanks again for your help :)
<aaabbb>
no worries! aq-mode is pretty easy btw, aq-mode=2 for low bitrate 10 bit or "not very high bitrate 8 bit", aq-mode=3 otherwise
Tinos has joined #ffmpeg
Tinos has quit [Quit: Client closed]
Tinos has joined #ffmpeg
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #ffmpeg
kasper93_ has joined #ffmpeg
kasper93 has quit [Ping timeout: 264 seconds]
Vonter has quit [Read error: Connection reset by peer]
Vonter has joined #ffmpeg
YuGiOhJCJ has joined #ffmpeg
Tinos has quit [Quit: Client closed]
Kroko has joined #ffmpeg
Kroko has quit [Remote host closed the connection]
Blacker47 has joined #ffmpeg
Tinos has joined #ffmpeg
billchenchina has joined #ffmpeg
junaid_ has joined #ffmpeg
lexano has joined #ffmpeg
bitbinge has joined #ffmpeg
Jhonny2x4 has joined #ffmpeg
Tinos has quit [Quit: Client closed]
NaviTheFairy has joined #ffmpeg
foul_owl has quit [Ping timeout: 260 seconds]
junaid_ has quit [Remote host closed the connection]
LionEagle has joined #ffmpeg
lec_thege80 has quit [Ping timeout: 268 seconds]
lec_thege80 has joined #ffmpeg
FlorianBad has quit [Remote host closed the connection]
foul_owl has joined #ffmpeg
lec_thege80 has quit [Client Quit]
Marth64 has quit [Ping timeout: 272 seconds]
lec_thege80 has joined #ffmpeg
lec_thege80 has quit [Client Quit]
lec_thege80 has joined #ffmpeg
lec_thege80 has quit [Client Quit]
lec_thege80 has joined #ffmpeg
lec_thege80 has quit [Client Quit]
lec_thege80 has joined #ffmpeg
lec_thege80 has quit [Client Quit]
lec_thege80 has joined #ffmpeg
omegatron has joined #ffmpeg
Captain_Haddock has joined #ffmpeg
navi has joined #ffmpeg
squeaktoy has quit [Ping timeout: 256 seconds]
squeaktoy has joined #ffmpeg
waleee has joined #ffmpeg
Ox7C5_ has quit [Ping timeout: 264 seconds]
Jhonny2x4 has quit [Read error: Connection reset by peer]
Jhonny2x4 has joined #ffmpeg
lavaball has joined #ffmpeg
billchenchina has quit [Remote host closed the connection]
ivanich has quit [Ping timeout: 272 seconds]
lucasta has joined #ffmpeg
LionEagle has quit [Quit: Leaving]
LionEagle has joined #ffmpeg
Captain_Haddock has quit [Quit: Leaving]
Tano has quit [Quit: WeeChat 4.1.2]
kasper93_ is now known as kasper93
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
vampirefrog has quit [Quit: Leaving]
lucasta has quit [Remote host closed the connection]
minimal has joined #ffmpeg
fossdd has quit [Ping timeout: 255 seconds]
fossdd has joined #ffmpeg
LionEagle has quit [Quit: Leaving]
lavaball has quit [Quit: lavaball]
lavaball has joined #ffmpeg
fossdd has quit [Ping timeout: 255 seconds]
LionEagle has joined #ffmpeg
fossdd has joined #ffmpeg
Marth64 has joined #ffmpeg
fossdd has quit [Ping timeout: 256 seconds]
fossdd has joined #ffmpeg
epony has quit [Remote host closed the connection]
ballsxd has joined #ffmpeg
fossdd has quit [Ping timeout: 256 seconds]
epony has joined #ffmpeg
<ballsxd>
hey guys, is there a reason ffmpeg is ~15x faster on my gen 3 nvme boot ssd than on my gen 4 nvme non boot ssd?
fossdd has joined #ffmpeg
ivanich has joined #ffmpeg
FlorianBad has joined #ffmpeg
Hackerpcs has quit [Quit: Hackerpcs]
<FlorianBad>
aaabbb, ok, will look into aq-mode later today. I ran something overnight and the thread_queue_size became annoying, it had lower from 8192 to 512 to finally work, and that's with 64GB of ram. My new laptop will have 96 but still... Do you think I should just let it be small and complain with warnings? Look for $queue_size in my code
Hackerpcs has joined #ffmpeg
Hackerpcs has quit [Max SendQ exceeded]
<FlorianBad>
It literally took the entire night for a 2-minute video lol and it's a pretty decent machine
<FlorianBad>
That's because all these high resolutions had to try with a thread_queue_size, then crash (OOM) then try again with a smaller one, etc. until 512 finally works
fossdd has quit [Ping timeout: 246 seconds]
Vonter has quit [Ping timeout: 272 seconds]
Vonter has joined #ffmpeg
Hackerpcs has joined #ffmpeg
rossome has quit [Read error: Connection reset by peer]
bitbinge has quit [Ping timeout: 255 seconds]
fossdd has joined #ffmpeg
<FlorianBad>
aaabbb, should I make thread_queue_size invert-proportional to pixel surface? Or is it just input file size? (but input are PNGs though)
AbleBacon has joined #ffmpeg
fossdd has quit [Ping timeout: 256 seconds]
fossdd has joined #ffmpeg
fossdd has quit [Ping timeout: 256 seconds]
fossdd has joined #ffmpeg
rvalue has quit [Ping timeout: 272 seconds]
Marth64 has quit [Remote host closed the connection]
rvalue has joined #ffmpeg
aljazmc has joined #ffmpeg
fossdd has quit [Ping timeout: 255 seconds]
fossdd has joined #ffmpeg
NaviTheFairy has quit [Ping timeout: 272 seconds]
epony has quit [Remote host closed the connection]
TheSashmo has quit [Read error: Connection reset by peer]
Jhonny2x4 has quit [Read error: Connection reset by peer]
Ogobaga has quit [Quit: Konversation terminated!]
<nicoz>
Do you know a good dedicated server to stream my stream and store streams simultaneously?
<FlorianBad>
I mean she's probably dedicated, can stream and store stream all at once
<nicoz>
lol
<BtbN>
Hosting any kind of video streaming yourself with more than a handful of viewers is hard to impossible
<BtbN>
It's A LOT of bandwidth, and even a Gigabit link, which is common on dedicated servers, is easily overwhelmed
Haxxa has quit [Quit: Haxxa flies away.]
<nicoz>
Should I buy two dedicated, one for streaming and another one that is storage?
<FlorianBad>
nicoz, if that was up to me I would just get A LOT of tiny Linodes, like $5/mo each but you scale up/down as based on viewers, so you can have like 200 of them on surges and drop to 3 when nobody's watching. Then just make sure the viewers are spread equally to each, which might be quite a bit of coding, but should work well IMO
<CounterPillow>
the bigger issue is that routes to and from the server(s) aren't gonna be great for people around the world
<FlorianBad>
^ That's right, so you also put these Linodes closer to each person (they have servers everywhere)
Haxxa has joined #ffmpeg
<FlorianBad>
In the last recent years I shifted my approach from "Getting the most reliable massive server" to "Designing things in a way that I don't have to rely on servers being great, just very numerous and self-healing"
<FlorianBad>
Because every company will fail at some point, so let's just embrace that and consider that servers are unreliable. From there, what would that design look like?
<nicoz>
the problem is not the viewers, because they would be 10 viewers per stream, they are more video streams and I must also record each stream and store it while they see it
<furq_>
any cheap vps will do that just fine
furq_ is now known as furq
<nicoz>
I had thought to buy one for streaming and another for storage, storage I thought to make it from opencv that uses ffmpeg that performs a check if the stream is broadcasting must record
<FlorianBad>
well, maybe you just want a dedicated type of vps though (not shared) to guarantee the performance at all times
<FlorianBad>
(that's an option with all of them, including Linode)
<furq>
you'd only really care about dedicated bandwidth for this
<furq>
which is not always offered or it's expensive
<furq>
anyway you don't need to write anything for a streaming/relay server that can also save the incoming streams
<nicoz>
the real problem is that it has to capture a stream emanating from a Multi SIM router moving on a vehicle
<nicoz>
for that I was thinking of a streaming server, so that it served as a proxy server such as live555
Jhonny2x4 has joined #ffmpeg
<another|>
why is that a problem?
LionEagle has quit [Quit: Leaving]
<furq>
presumably they want some kind of fallback stream to handle dropouts
<furq>
there are hacky ways to do that with nginx-rtmp
<nicoz>
because if in a certain area there is no network coverage the streaming server crashes and even recording would do it, and I don’t have the dvr SSD at hand physically
LionEagle has joined #ffmpeg
fossdd has quit [Ping timeout: 268 seconds]
hussein1_ has quit [Remote host closed the connection]
fossdd has joined #ffmpeg
hussein1_ has joined #ffmpeg
berndj has quit [Read error: Connection reset by peer]
berndj has joined #ffmpeg
ivanich has quit [Read error: Connection reset by peer]
ivanich has joined #ffmpeg
ivanich has quit [Remote host closed the connection]
fossdd has quit [Ping timeout: 272 seconds]
fossdd has joined #ffmpeg
fossdd has quit [Ping timeout: 246 seconds]
fossdd has joined #ffmpeg
<FlorianBad>
Instead of `seg_duration` is there some way to specify each individual segment (approximate) duration manually? (for audio) Similar to what `-force_key_frames` does, but for audio segments.
aljazmc has quit [Remote host closed the connection]
halvut has joined #ffmpeg
aljazmc has joined #ffmpeg
fossdd has quit [Ping timeout: 272 seconds]
fossdd has joined #ffmpeg
jagannatharjun has quit [Quit: Connection closed for inactivity]
Vonter has quit [Ping timeout: 272 seconds]
Vonter has joined #ffmpeg
fossdd has quit [Ping timeout: 272 seconds]
fossdd has joined #ffmpeg
Blacker47 has quit [Quit: Life is short. Get a V.90 modem fast!]
fossdd has quit [Ping timeout: 255 seconds]
fossdd has joined #ffmpeg
Raito_Bezarius has quit [Read error: Connection reset by peer]
fossdd has quit [Ping timeout: 256 seconds]
Coinflipper has quit [Quit: ]
Coinflipper has joined #ffmpeg
fossdd has joined #ffmpeg
aljazmc has quit [Remote host closed the connection]
TheSilentLink has quit [Ping timeout: 276 seconds]
aljazmc has quit [Remote host closed the connection]
fossdd has joined #ffmpeg
aljazmc has joined #ffmpeg
Vonter has quit [Ping timeout: 272 seconds]
aljazmc has quit [Client Quit]
Vonter has joined #ffmpeg
TheSilentLink has joined #ffmpeg
HarshK23 has quit [Quit: Connection closed for inactivity]
alexherbo2 has joined #ffmpeg
emmanuelux has joined #ffmpeg
fossdd has quit [Ping timeout: 246 seconds]
fossdd has joined #ffmpeg
fossdd has quit [Ping timeout: 256 seconds]
fossdd has joined #ffmpeg
NaviTheFairy has joined #ffmpeg
fossdd has quit [Ping timeout: 264 seconds]
halvut has quit [Ping timeout: 272 seconds]
fossdd has joined #ffmpeg
five618480 has quit [Remote host closed the connection]
five618480 has joined #ffmpeg
fossdd has quit [Ping timeout: 255 seconds]
fossdd has joined #ffmpeg
Juest has joined #ffmpeg
<Juest>
hello, is ffmpeg working on windows vista and windows 7?
<Juest>
or supported even
<CounterPillow>
god I hope not
alexherbo2 has quit [Remote host closed the connection]
Ogobaga has joined #ffmpeg
fossdd has quit [Ping timeout: 264 seconds]
fossdd has joined #ffmpeg
cxc has joined #ffmpeg
<Juest>
i mean, does it run?
<Juest>
there's no information about dropping windows 7 support
<drv>
the ffmpeg 4.0 release notes mention dropping support for XP, but I doubt anyone is testing Vista or 7 specifically since those operating systems are long out of official support from Microsoft anyway