rvalue has quit [Ping timeout: 256 seconds]
fossdd has quit [Ping timeout: 255 seconds]
ivanich has quit [Remote host closed the connection]
jtgd has quit [Quit: WeeChat 4.2.1]
fossdd has joined #ffmpeg
jtgd has joined #ffmpeg
vincejv has joined #ffmpeg
luva6 has quit [Ping timeout: 256 seconds]
rvalue has joined #ffmpeg
fossdd has quit [Ping timeout: 246 seconds]
fossdd has joined #ffmpeg
fossdd has quit [Ping timeout: 260 seconds]
lavaball has quit [Quit: lavaball]
fossdd has joined #ffmpeg
luva6 has joined #ffmpeg
luva6 is now known as luva
fossdd has quit [Ping timeout: 256 seconds]
navi has quit [Quit: WeeChat 4.1.2]
fossdd has joined #ffmpeg
fling has quit [Remote host closed the connection]
fling has joined #ffmpeg
fossdd has quit [Ping timeout: 255 seconds]
fossdd has joined #ffmpeg
lexano has quit [Ping timeout: 256 seconds]
thilo has quit [Ping timeout: 268 seconds]
thilo has joined #ffmpeg
fossdd has quit [Ping timeout: 276 seconds]
fossdd has joined #ffmpeg
minimal has quit [Quit: Leaving]
kus has quit [Read error: Connection reset by peer]
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #ffmpeg
waleee has quit [Ping timeout: 264 seconds]
Suchiman has quit [Quit: Connection closed for inactivity]
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg
jnbek has quit [Quit: kthx]
jnbek has joined #ffmpeg
jarthur has quit [Quit: jarthur]
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
Muimi has joined #ffmpeg
qaph has joined #ffmpeg
kron has quit [Ping timeout: 256 seconds]
qaph is now known as kron
AntimaD96 has joined #ffmpeg
AntimaD96 has quit [Client Quit]
AntimaD has joined #ffmpeg
lusciouslover has quit [Ping timeout: 268 seconds]
YuGiOhJCJ has joined #ffmpeg
Vonter has quit [Ping timeout: 252 seconds]
Vonter has joined #ffmpeg
AntimaD has quit [Read error: Connection reset by peer]
pa has quit [Ping timeout: 260 seconds]
YuGiOhJCJ has quit [Remote host closed the connection]
pah has joined #ffmpeg
YuGiOhJCJ has joined #ffmpeg
shokohsc51081294 has joined #ffmpeg
fling has quit [Ping timeout: 255 seconds]
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
lusciouslover has joined #ffmpeg
lusciouslover has quit [Ping timeout: 264 seconds]
fling has joined #ffmpeg
lusciouslover has joined #ffmpeg
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
rv1sr has joined #ffmpeg
junaid_ has joined #ffmpeg
Muimi has quit [Quit: Going offline, see ya! (www.adiirc.com)]
carpenter has quit [Ping timeout: 256 seconds]
Suchiman has joined #ffmpeg
FH_thecat has quit [Quit: Leaving]
Tinos has joined #ffmpeg
junaid_ has quit [Quit: leaving]
alexrelis has joined #ffmpeg
ivanich has joined #ffmpeg
ivanich has quit [Remote host closed the connection]
FH_thecat has joined #ffmpeg
junaid_ has joined #ffmpeg
AbleBacon has quit [Read error: Connection reset by peer]
<aaabbb> how do i use the concat muxer with a one frame mpegts and a longer mpegts (both created with the same encoder settings) to create a video where the first frame lasts for 5 seconds?
<aaabbb> it seems using -muxdelay only works if i'm concatenating one frame and one video
junaid_ has quit [Quit: leaving]
junaid_ has joined #ffmpeg
cosimone has joined #ffmpeg
kepstin has quit [Remote host closed the connection]
kepstin has joined #ffmpeg
waleee has joined #ffmpeg
rsx has joined #ffmpeg
<JEEB> this FOSDEM's FFmpeg talk ttps://live.fosdem.org/watch/ub4132
cosimone has quit [Remote host closed the connection]
<JEEB> *https
cosimone has joined #ffmpeg
Tinos has quit [Quit: Client closed]
carpenter has joined #ffmpeg
shokohsc51081294 has quit [Ping timeout: 255 seconds]
<CounterPillow> wtf ffmpeg catching up to gstreamer :^)
<APic> 😸
<CounterPillow> wtf is this question
<CounterPillow> bringing drama to FOSDEM lmao
<JEEB> well it's a valid note; you don't hurr and durr and call people names on a public PR thing like that :P
<CounterPillow> I didn't hear the full question but I assume it's the usual "ffmpeg-devel is full of assholes" discussion
<JEEB> nah, specifically twitter which is handled by certain entities
<CounterPillow> lol
<JEEB> I don't think ffmpeg-devel was mentioned
<JEEB> ffmpeg-devel has its own issues o' course, but at that point you're much more in the weeds VS being on some common platform like tweeter
<CounterPillow> I would never use an open source project's twitter account to call people rude things :^)
<aaabbb> CounterPillow is the epitome of politeness
hightower3 has joined #ffmpeg
hightower2 has quit [Ping timeout: 255 seconds]
emanuele6 has quit [Ping timeout: 260 seconds]
emanuele6 has joined #ffmpeg
HarshK23 has joined #ffmpeg
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
fossdd has quit [Ping timeout: 256 seconds]
fossdd has joined #ffmpeg
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
fossdd has quit [Ping timeout: 256 seconds]
fossdd has joined #ffmpeg
<rodeo> The voice and speech rate of that first question al
<rodeo> most seemed familiar, but I can’t remember the name of who it reminded me of
<rodeo> Not that it matters, but it made me curious
lavaball has joined #ffmpeg
navi has joined #ffmpeg
cosimone has quit [Remote host closed the connection]
VarunAgw has joined #ffmpeg
fossdd has quit [Ping timeout: 264 seconds]
fossdd has joined #ffmpeg
fossdd has quit [Ping timeout: 260 seconds]
fossdd has joined #ffmpeg
LionEagle has quit [Quit: Leaving]
fossdd has quit [Ping timeout: 246 seconds]
fossdd has joined #ffmpeg
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg
<bcn> What happens if I omit "-codec:v libx264" ? I'm trying to fully understand the suggestions on https://superuser.com/questions/578321/how-can-i-rotate-a-video-180-with-ffmpeg Also, I think that wether I include "-metadata:s:v rotate=0" or not will only affect wether the matadata of my output file states that it's not rotated, or does not state that (which should be the same as stating it right?)
<CounterPillow> if you omit -codec:v libx264 then FFmpeg picks whatever encoder it defaults to for the output format, which is usually not a good choice
fossdd has quit [Ping timeout: 246 seconds]
<bcn> oh... I want to match the encoding of my source file, which I "think" is h264. does that sound right from this output? https://paste.debian.net/1306269/
<bcn> I think the important line out of all of that is Stream #0:0[0x1](eng): Video: h264 (Baseline) (avc1 / 0x31637661), yuvj420p(pc, smpte170m/bt470bg/smpte170m, progressive), 3840x2160, 41973 kb/s, SAR 1:1 DAR 16:9, 30 fps, 30 tbr, 90k tbn (default)
<CounterPillow> Yes, that is an H.264 encoded video stream. libx264 is an H.264 encoder.
fossdd has joined #ffmpeg
<bcn> oh. I thought h264 was the container. but no mp4 is the container?
<CounterPillow> mp4 is the container
<bcn> what is avc1? is that a subtype of h264?
<galad> another name for h264
nact has quit [Quit: leaving]
<bcn> what's yuvj420p in that output? is it something "inside" the h264 encoding?
<bcn> like h264 is inside mp4
<CounterPillow> it's the pixel format
<galad> actually "avc1" is the four character code that indicates the format of the video inside the mp4 container
<bcn> galad: and that code is used by h264?
<galad> yes
<CounterPillow> the j in yuvj420p seems to indicate full range or something, the yuv part means YCbCr colours, the 420 refers to 4:2:0 chroma subsampling, the p refers to a packed (or was it planar? idr) format
<galad> if there is no rotate metadata, it means it's not rotated
<galad> or well, the player won't rotate it
<bcn> used by/assigned to.... ahhhh I was thinking it meant 420p resolution, which didn't jive with it being a modern phone.
s55 has joined #ffmpeg
<bcn> I have several videos that I stupidly recorded 180 because it was much less precarious to position my phone that way, and I'm trying to go back in time and turn the phone back the right way.... I kind of prefer the output file does NOT mention rotation in its metadata because the originals didn't
<galad> then you should just change the rotate metadata without reencoding
<galad> reencoding will always lose quality, or create a bigger file at the same quality
<bcn> galad: the original file had no such metadata
<galad> then either add the rotation metadata, or reencode the rotated video
<galad> there isn't much more that can be done
<bcn> I want to re-encode it. Looking at the stack exchange answers I see they include "-metadata:s:v rotate=0" That, taken as one hole does only one thing right? it adds metadata on the putput file to say "this file does not need to be rotated for playback". right?
<CounterPillow> if you want to reencode the video anyway you don't need to mess with metadata at all, just add a -vf rotate with the right params
<bcn> I want to understand ffmpeg better as part of doing this
<aaabbb> CounterPillow: the j is deprecated, it's being removed
<aaabbb> yuvj420p = yuv420p with pc range
<bcn> is it true that "-metadata:s:v rotate=0" is one "thing" that causes the metadata of the output file to say "I'm not rotated"?
<aaabbb> bcn: why do you want to reencode it just to rotate it?
<bcn> aaabbb because I thought you had to decode/encode to apply a filter and I thought you had to use a filter too rotate frames. it's kind of a bummer that it causes quality loss. because a strict 180 imho shouldn't. wouldn't with a still image anyway
<CounterPillow> metadata rotation isn't a filter
<CounterPillow> metadata rotation is applied by the player on playback
<aaabbb> bcn: you don't need to apply a filter
<aaabbb> it's literally just metadata that tells the player "rotate this"
<bcn> i'm going to merge this video later with serveral others, some of which aren't rotated
<bcn> also, wouldn't the player introduce the same quality loss during playback then, and use a bunch of cpu to play it back?
<aaabbb> no because it wouldn't be reencoding it
<bcn> ahh
<bcn> so the decode isn't lossy, its just the encode that is right?
<aaabbb> the decode is lossless
<aaabbb> the encode is lossy (for 99.99% of codecs)
<aaabbb> ofc you might scale it after decoding but that doesn't really matter
<bcn> I guess that makes sense. encoding something has to decide what's worth keeping and what's not.. I'd assume then that decodes are repeateble bitwise identical operations, you always get the same outout if you hashed it. Are encodes typically deterministic or so they have some element of randomness?
Vonter has quit [Ping timeout: 252 seconds]
<aaabbb> encodes have some deterministic aspects but not always
<aaabbb> but there are usually setting to create "bitexact" (deterministic) output, at the expense of speed
<aaabbb> and decodes are always 100% repeatable as long as the decoder is working properly. in fact a codec's specifications don't have anything to do with encoding, they only describe how to decode
Vonter has joined #ffmpeg
<bcn> how to encode might be different if you're coming from a camera sensor vs from cgi I suppose
<aaabbb> the way to encode is always the same (raw uncompressed input in, compressed bitstream out) but the ideal settings might differ
<aaabbb> you might need denoising from a camera sensor that you'd never need from cgi
<bcn> aaabbb: oh.. differ depending on what? the desired quality/space constraints only? or differ depending on the input at all?
<aaabbb> depending on the input
<aaabbb> most encoders make it easy with a -tune setting
<aaabbb> so you can -tune film or -tune animation
<aaabbb> and those change some internal settings, like -tune animation will adjust settings that are useful for lots of flat simple gradients
<aaabbb> so more b frames for example
<aaabbb> bcn: you can always just decrease crf to get the same quality, but that comes at the expense of bitrate (thus file size). so when you tune the settings properly for the time of input you have, you can end up with a file of equal quality but smaller size
<bcn> interesting! Is there a good app in linux for viewing two video files side by side to spot error/quality differences? myabe you could zoom scroll on areas and your cursor when in either video window, functions as a magnifier that zooms/pans equall on both windows
<aaabbb> zooming in isn't a good way to tell quality differences for a few reasons
<aaabbb> in fact there are features in encoders like x264 and x265 that actually make it look worse when paused and zoomed, but better when played
<bcn> aaabbb: that's a downer. I like to pause netflix on my 4k tv sometimes and walk up to it and read the newspaper on the table in a scene
<aaabbb> such as psychovisual optimizations ("psy" settings) that will intentionally take bits away from accurate motion and use them to increase accurate shape, because our eyes are better at detecting bad shape than bad motion
<aaabbb> well netflix also puts a lot of effort into making extremely good quality encodes, and they're pretty high bitrate too
<aaabbb> they're able to give good enough quality that you can zoom in and pause and you won't notice any serious problems
<galad> actually netflix is the streaming service with the worst quality out there
<galad> at least for 1080p
<aaabbb> galad: for the bitrate, they're among the best
<aaabbb> they do something like 5 encodes with different settings, then throw away all but the best. that's why they developed vmaf
<galad> could be, but it's still an artifacts and blocks party
<bcn> hahah does best bitrate mean uses the most data, or least data for the quality?
<aaabbb> bcn: bitrate means most data
<aaabbb> when you encode something you tell the encoder "you're allowed to use X kilobits for every second of video, do with that what you will"
<aaabbb> and it's up to the encoder to allocate those bits. if you give it a lot of bits then it can spend time improving things that a human could never see anyway. if you give it very few bits then it has to make tough decisions about what information to throw away
<bcn> still, somehow my lowest tier google fiber service doesn't seem to struggle at all with two people watching netflix and me using bit torrent and ssh I don't think I've ever seen lag
<aaabbb> when you use a slow preset like -preset veryslow then you're telling the encoder to try really really hard to optimally use the bits it is given, even at the expense of encoding speed
<aaabbb> bcn: that's because the encoding they use is able to put those bits to use very well. that's also why cell phone video is so much more massive for its length
<aaabbb> like 100mb for a 10 second 4k clip
<bcn> because cellphones are cpu limited and can't compress it very welll?
<aaabbb> right, so to get good quality, they have to throw in a very high bitrate
<bcn> huh. honestly, 10mb/sec for 4k doesn't sound too greedy to me. them's a lot of pixels!
<aaabbb> you can get equivalent quality for like 1mb/s
<aaabbb> but not without being so slow on a phone that it can't record in real time
<bcn> I'd like to see lower resolutions more readily accessible on my android's recorder app. sometimes I only want video as proof something happened, not as a cinematic masterpiece. the audio is probably the most important part and video just proves I didn't spoof the audio
<aaabbb> you can reencode it to a smaller size
<aaabbb> which is actually better than encodign it at that size to begin with, because the encoding doesn't have to work at 1x speed
<aaabbb> and when you downscale, you mitigate generation loss (basically when you downscale, the compression artifacts are practically removed and it becomes a virtually lossless source as far as the encoder is concerned)
<aaabbb> > Is there a good app in linux for viewing two video files side by side to spot error/quality differences
<aaabbb> ffmpeg
<aaabbb> well ffplay
<bcn> that's smart. record live with less encoding to keep up with the actual pace of time, then go back later and compress it
<aaabbb> you can use the hstack filter to play two inputs together
<aaabbb> bcn: that's actually how professional studios do it
<aaabbb> the original recording is called a mezzanine. it's a format that is generation-loss resistant (which makes editing a breeze), and super super high quality, but at the expense of bitrate (we're talking >100mb/s)
<aaabbb> so you can use a format like prores, dnxhd, or ffv1 to record in real time in super high quality but super high bitrate, and then after the editing you can take your sweet time to make a really good encode
<bcn> huh. gonna need some fast storage for a room full of those workers to pick over mezzanine with whatever editor tools they're using
<aaabbb> if you're recordinga an 8k yuv444p12le mezzanine format, yeah you need some fast storage
<bcn> Hate to think what a few hundred PV of nvme costs, and then add 10gbe fiber everwhere
<aaabbb> well not everyone needs to encode with the highest possible bitrate, if you are going to distribute as 1080p then recording at a "mere" 4k is fine
<aaabbb> but you can generally save to just one nvme
<aaabbb> 100mb/s is 100 megabits, not megabytes
<aaabbb> so it's only 12.5 megabytes per second (for 100mbit)
<bcn> okay so to knock outsome understanding of the ffmpeg cli, "-metadata:s:v rotate=0" is one command given to ffmpeg right? and its saying insert a metadata tag in the output container to say "this video is not rotated", right?
<aaabbb> right, that will set it to rotate 0 degrees
<aaabbb> make sure you do -c copy
<aaabbb> so that it only remuxes it and doesn't transcode
<bcn> sort of directing the player to "rotate this 0 degrees"
<aaabbb> yeah
<aaabbb> just like if you have an anamorphic video and you need to tell the decoder "ok i know this is in 1920x1080, but i want you to play it at a 4:3 ratio not 16:9"
<bcn> so philosophically. why does "rotate this 0 degrees" exist as a possible thing to say? its kind of like going to the super market with a roll of sticker that say "this is safe to eat" and sticking it on everything, isn't it?
<aaabbb> it might remove the rotate metadata, not sure
<bcn> or is there a difference betwen specifying "rotate this 0 deg during playback" and not saying that
<aaabbb> you could also just strip the metadata
<aaabbb> there's no difference. removing the rotate metadata or setting the rotate to 0 deg are the exact same
<aaabbb> bcn: just tested it. -metadata:s:v rotate=0 will simply remove the rotate metadata
<aaabbb> or at least ffprobe no longer shows it, so perhaps the container always contains the displaymatrix rotation, and 0 just means disabled, so it doesn't display it in ffprobe, dunno
<bcn> aaabbb: that's good. vexes me a little less. so it would be helpful to add that if the original file had wrong metadata. But if the underlyign video wasn't rotated, then adding "-metadata:s:v rotate=0" to my ffmpeg command is sort of superfluous
<aaabbb> yeah that would be a noop
<aaabbb> but you can always harmlessly add that if you want to make sure to remove any rotate metadata if it exists, it won't hurt if the video isn't rotated already
<bcn> And if I only had one file in a vacuum, the easiest(and probably best quality too) way to "rotate it" isn't to rotate the encoded video, but to add the "-metadata:s:v rotate=180"
<aaabbb> exactly
<aaabbb> that's probably how phones do it. they record the video and check the gyro to know the average orientation of the phone, then set the rotation metadata to that average
<bcn> ... doesn't hurt to add it ... unless I'm an idiot and my brain starts to hurt looking at an ever longer commandline ..... :-)
LionEagle has joined #ffmpeg
waleee has quit [Ping timeout: 246 seconds]
<bcn> ffmpeg is one of the most magnificently featureful commands I've seen if not the most, in 20 years linuxing
<aaabbb> it's pretty impressive
<aaabbb> only thing lacking is the documentation. ffmpeg-all is absolutely huge, but only touches on a fraction of what it can do
<aaabbb> eg it says nothing about mpeg1, yet when you do "ffmpeg -h encoder=mpeg1video" you see a myriad of undocumented features
<bcn> imagemagick is a close second. I appreciat the ascii art in the ffmpeg manpage
<aaabbb> not that you'd want to use mpeg1 ofc
<aaabbb> nearly 40,000 lines in the ffmpeg-all manpage, and yet it's still considered rather poorly documented. that's how powerful it is
<aaabbb> but it makes sense that it's so complex, because av itself is complex
<aaabbb> bcn: btw you mentioned merging videos. if they're encoded with the *exact* same settings, you can merge them losslessly
<aaabbb> ffmpeg -i "concat:vid1.ts|vid2.ts|vid3.ts" -c copy merged.mp4
<aaabbb> the ts file being created with: ffmpeg -i vid1.mp4 -c copy vid1.ts
<bcn> aaabbb: would that work even if some of them are rotated (after I re"mux?" them with the metadata 180 thing?
<aaabbb> the rotation metadata would be irrelevant, it would be the "original" dimensions
LuKaRo has quit [Ping timeout: 264 seconds]
<aaabbb> so two 1920x1080 videos with identical settings could be concatenated, but whether it makes sense at the end depends on whether a single rotate=N value works for them all
<aaabbb> otherwise it'll just look weird
<bcn> so I would first, convert all source files to ts with ffmpeg, then merge the ts into an mp4?
<aaabbb> if the source files are all encoded with identical settings, yeah
<aaabbb> with -c copy
<bcn> when I convert into TS, should I add "-metadata:s:v rotate=0" or "-metadata:s:v rotate=180", depending if the camera was upside down or not in that source video?
<aaabbb> well if you merge them that way, you'll have to have one rotation for them all
<aaabbb> and the metadata won't matter anyway
<BtbN> I don't think mpegts has rotation metadata, has it?
<aaabbb> BtbN: i don't think so
<aaabbb> bcn: basically if you can rotate=0 for them all, concat, and then do rotate=N for the final video and it makes sense, then you can do it this way
<bcn> oh.... that won't work in my case then I don't think. part of what I need to do is rotate some of the source videos but not others.
<aaabbb> otherwise you might be stuck with transcoding some of the videos you want to rotate instead of just stream copy
<bcn> yeah that's what I feared/thought, since the originals are mixed. The "settings" are the same on them all, but literally the camera was rorated upside down on half of them
<aaabbb> -i "concat:vid1.ts|vid2.ts|vid3.ts" is still worth it even if you have to reencode vid2
<aaabbb> bcn: then reencode the fewest number you can, then merge with the concat muxer
<bcn> actually I think it was a phone in a car windshield mount holder, and the way we put it in was wrong sometimes. And the accelerometer was broke or being ignored on the phone
<bcn> so it was always landscape. but anyone's guess if it was rightside up or upside down
<aaabbb> actually, these were recorded on a phone right? so actually that might be hard to concat them after reencoding
<aaabbb> because ffmpeg might not be able to get the exact same setting the camera used, if the camera didn't use ffmpeg itself
<bcn> yeah i doubt the camera used ffmpeg. i saw h264 in the original file not libx264
<aaabbb> anyway if it is a phone recording then you may be better with reencoding them all just to get the smaller file size
<aaabbb> h264 is the name of the codec
<aaabbb> so libx264 is an h264 encoder
<aaabbb> and if you're gonna be encoding them to get a smaller file size, you might as well use h265 instead of h264
LuKaRo has joined #ffmpeg
fossdd has quit [Ping timeout: 260 seconds]
<bcn> ahhh, so specifying "-codec:v h264" to try to match the source is wrong and "-codec:v h264 " is the closest I can get? and 265 is even better i take it. there's no 266? :-p
<aaabbb> as a rule of thumb, if you do "ffmpeg -i in.mp4 -c:v libx265 -preset slower -crf 21 out.mp4", you'll get it visually lossless conversion, but probably a fraction of the filesize of the original bloated high bitrate camera
<aaabbb> no you'd have to do -codec:v libx264
<aaabbb> -codec:v = -c:v btw
<aaabbb> bcn: there is h266, and an upcoming x266 encoder, it's in the works
<bcn> I did notice that no matter how I tweaked the commandline the output files I was getting were half the size as my inputs. being apessimist I thought I was losig quality was the reason they were smaller. but perhaps there was SOME quality lost simply to the fact that it was encoding at all, but the 50% size reduction was just that my laptop has much more cpu available and can squish them down a lot better
<aaabbb> there will always be a little quality loss. the lower the crf you use, the more bits it will throw at it to be faithful. the slower the preset you use, the more time your cpu will take to utilize the bits it is given well
fossdd has joined #ffmpeg
<aaabbb> the default crf (23 for libx264, 26 for libx265) are kinda high and cause more loss than you'll usually want
lexano has joined #ffmpeg
<bcn> its still cold in Kansas City, burning more cpu just keeps me that much warmer :-) is crf 21 sort of a judgement/sanity call? i.e. crf0 would be higher quality but take a year and a half to run?
guanche has joined #ffmpeg
<aaabbb> lower crf doesn't take (much) longer, it just means you are giving more bits
<bcn> no wait crt means larger filesize
<aaabbb> and for libx264, crf 0 has a special meaning, which is lossless
Joeboy has joined #ffmpeg
<guanche> Hi, what tools are out there to show as much info as possible about video files? I'm mostly interesed in h.264 and h.265
<aaabbb> so if you use -crf 1 you'll have a file that is absolutely gigantic
<aaabbb> guanche: ffprobe can show quite a lot, see the man page for all the settings. there's also AtomicParsely if you want to see stuff about the container, and mediainfo if you want to see some general information. if you want really extreme details like info on each motion vector and what every macroblock is doing, you'll need specialized tools
<aaabbb> bcn: crf 21 is nearly visually lossless for x265. the equivalent for x264 is crf 18
<aaabbb> roughly
<bcn> aaabbb: would anything make "lossless" larger than the source file? or does that essentialy mean all frames are full frames, like splitting every frame into a seperate bmp file
<guanche> thanks aaabbb, mostly willing to see if I can mimic "pro" videos. I'm able to encode video out of png files by using libav*, but don't know best or which settings I should use
<aaabbb> bcn: lossless means no generation loss at all. it will always be smaller than the raw (like y4m), but much much much bigger than lossy
<aaabbb> if you take a lossy file and reencode to lossless, you won't lose anything at all, but the file will be HUGE
<aaabbb> only reason to use lossless ever is if you have a raw lossless input already
<aaabbb> like ffv1 or y4m
<aaabbb> (ffv1 is compressed lossless, y4m is uncompressed lossless)
<bcn> aaabbb: Ah, I get it now, what I'm looking at as a 49MB source mp4 file isn't just 49MB of video. if it was raw it might be gig or something
<bcn> I don't *have* raw source video. (epiphany) probably very few consumer cameras do that by default
<aaabbb> yeah exactly
<aaabbb> raw (uncompressed) means you're encoding each pixel separately (or a simple transform, like Y'CbCr from RGB)
AntimaD74 has joined #ffmpeg
AntimaD74 has quit [Client Quit]
<aaabbb> you can always forget about lossless unless you have an already lossless source
fossdd has quit [Ping timeout: 268 seconds]
<bcn> I have h264 /encoded/ video using yuvj420p pixel format, in an mp4 /container/ https://paste.debian.net/1306269/ and I'm going to decode/encode each into h265 with "-preset slower -crf 21" to do my best to preserve quality. and it should output using yuv420p pixel format because the j is deprecated right?
<bcn> and because some of them are upside down, I should add the "-metadata:s:v rotate=180" to those? or would that make it impossible to later concatente them with ones that have rotate=0?
bitbinge has joined #ffmpeg
fossdd has joined #ffmpeg
<bcn> I'm inclined to think I have to use a "-vf "hflip,vflip"" to rotate the video while it's decoded, before encoding. so that all the reultant files have identical parameters and can then be merged
<bcn> (or any one of the several -vf's that can rotate video)
<aaabbb> bcn: yuvj420p is just a deprecated way of saying yuv420p with pc color range
cancername has joined #ffmpeg
<aaabbb> not 100% sure but i think you'll have to do -pix_fmt yuv420p -vf "scale=out_range=pc" -color_range pc
<aaabbb> that will preserve the full color range
<rodeo> aren't most container-level video rotation flags per-track? if so, changing the rotation mid-file would not work
<cancername> Since yuvj* are deprecated, what's the correct option for center chroma siting? Someone said something about -color_range?
<aaabbb> cancername: you mean chroma location?
<cancername> yep
<bcn> aaabbb I'll play with that for color range. I do want to preserve color well on this, it was a very pretty drive! Should I be doing directly from my source files to TS files, since my intention is to concat them anyway?
<aaabbb> cancername: chromaloc in x264 i think
<aaabbb> bcn: yeah that works
alexherbo2 has joined #ffmpeg
<cancername> I mean in general for the ffmpeg CLI aaabbb
<aaabbb> cancername: there's no general way iirc, you'll have to pass that directly to the encoder with -x264-params and such
<rodeo> and it's completely unrelated to YUVJ isn't it???
<cancername> so uh, is this just getting rid of the mechanism to indicate chroma siting? I'm a bit confused.
<aaabbb> rodeo: yeah unrelated
<cancername> rodeo: ? I was under the impression yuvj indicated center chroma location, right?
<aaabbb> no it doesn't
<aaabbb> yuvj420p is a deprecated name for full color range yuv420p
<cancername> I see
<aaabbb> and color range isn't about chroma location
<cancername> yeah
<cancername> that's why I was confused
<cancername> thanks
<bcn> aaabbb When you said if they're encoded with the *exact* same settings, you can merge them losslessly, does with the exact settings include the rotation metadata?
<aaabbb> bcn: exact same settings in the h264 bitstream. metadata is in the container
<rodeo> you're saying your final output is MPEG-TS?
<aaabbb> rodeo: the final is mpegts because he's gonna then concat it into an mp4
<rodeo> AFAIK there's no standardized way to indicate rotation in MPEG-TS?
fossdd has quit [Ping timeout: 268 seconds]
<aaabbb> cancername: you just do -x264-params chromaloc=N where N is an integer, 0=left, 1=center, 2=topleft, 3=top, 4=bottomleft, 5=bottom. it's probably the same for x265
<rodeo> so that info would be lost wouldn't it?
<cancername> thanks aaabbb, but I was under the impression FFmpeg specified this in other ways
<aaabbb> rodeo: he'll be reencoding so he can vflip,hflip or whatever
<cancername> or, well, in codec-independent ways
<cancername> since conversion to and from non-subsampled pixel formats is affected by the chroma location, right?
<rodeo> but then he said some of them would be upside down an required metadata
<aaabbb> cancername: i don't think so, but i might be wrong
<cancername> gotcha aaabbb
<aaabbb> rodeo: if he's reencoding them all anyway then there's no reason not to just flip it at that time
minimal has joined #ffmpeg
<rodeo> as long as it's understood correctly
<aaabbb> cancername: i think you can also use a bitstream filter to change chroma location losslessly
<rodeo> you either rotate and/or flip correctly or you use metadata, it cann't be both
<aaabbb> rodeo: if it's being saved as mpegts it's not gonna have that metadata anyway
fossdd has joined #ffmpeg
<cancername> aaabbb: that makes sense. do you know how libswscale handles this?
<bcn> i didn't have a strong preference over hflipvflip or using metadata to rotate them during playback. but he hitch is some need rotation and others don't. and I need them all in one file in the end. so I think that means metadata won't cut it for me. I have to reencode the upside down ones. so I might as well reencode them all
<aaabbb> cancername: it's not handled by libswscale i think? not sure
<rodeo> bcn: correct
<aaabbb> bcn: since they were encoded on a phone and not by ffmpeg, you'll have to reencode them all anyway (if you want to concat them at the end)
<cancername> huh, how would it upsample the chroma planes for e.g. conversion to yuv420p then @_@
<cancername> er, not yuv420p, rgb, or yuv444p, really anything
<aaabbb> cancername: i mean chroma location, there's nothing about it in ffmpeg-scaler
<bcn> Exciting. I compiled this command in a text editor, and its running now without error on the first shot! ffmpeg -i VID_20210201_182518.oud.mp4 -vf "hflip,vflip,scale=out_range=pc" -color_range pc -metadata:s:v rotate=0 -codec:v libx265 -preset slower -crf 21 -pix_fmt yuv420p VID_20210201_182518.ts
<aaabbb> it just takes chroma location info from the bitstream
<aaabbb> bcn: i *think* you can leave out the metadata thing if you're turning it into a ts since that won't be able to be copied anyway. and the -preset slower was just an example, if you have time you can even do -preset veryslow
<aaabbb> and adjust crf as you see fit
<cancername> I'm confused as to how it could upsample it correctly then
<aaabbb> cancername: because it gets the chroma location information from the bitstream
<cancername> how exactly does libswscale have access to the bitstream? 👀
<rodeo> IIRC there's a way to override and/or change it but cannot find it off the top of my head
<aaabbb> rodeo: the hevc_metadata bsf
<aaabbb> cancername: i misunderstood you
<bcn> aaabbb: I've also seen ",format=yuv420p" in the -vf argument. is that the same as adding the "-pix_fmt yuv420p" argument outside of -vf?
<aaabbb> bcn: unless you're doing pretty complex filter chains, yeah
<aaabbb> bcn: btw you can also improve quality somewhat by using 10 bit, which is slower but can reduce banding (especially for x264)
guanche has quit [Read error: Connection reset by peer]
<aaabbb> in that case you'd use yuv420p10le rather than yuv420p
<aaabbb> a 10 bit encode from an 8 bit source is a perfectly legitimate thing to do
alexherbo2 has quit [Ping timeout: 250 seconds]
<bcn> aaabbb would it make the output larger?
<aaabbb> bcn: for the same bitrate, it'll give similar or better quality
<aaabbb> whether it bumps up the bitrate at a given crf isn't really relevant (because you just adjust the crf to your liking)
<cancername> IIRC modern codecs compress better on 10-bit input
vlm has joined #ffmpeg
fossdd has quit [Ping timeout: 255 seconds]
<aaabbb> i'm being pedantic, the quality increase usually isn't worth the extra encoding time, but if you're already doing -preset veryslow and have plenty of time, it won't hurt anymore than adding bframes=16:ref=6:subme=7 will hurt
<aaabbb> takes a lot longer but can squeeze a percent better quality for the same bitrate
alexherbo2 has joined #ffmpeg
fossdd has joined #ffmpeg
<cancername> I think I have an answer to my question: there's an enum AVChromaLocation that's supposed to be passed to libswscale, but apparently, libswscale doesn't consider it.
rsx has quit [Quit: rsx]
Muimi has joined #ffmpeg
fossdd has quit [Ping timeout: 246 seconds]
<bcn> is it normal for encoding speed to start out fast and then get way slower? I get the first 48 frames in about 2 seconds, then it plumets to 1.5fps
<CounterPillow> yes
cancername has quit [Remote host closed the connection]
<aaabbb> yeah that's completely normal, you have to wait a while for it to stabilize, and even then it can change slightly based on the contents of the video
rvalue has quit [Ping timeout: 240 seconds]
fossdd has joined #ffmpeg
<bcn> it's not a big deal if this all takes a week to process even. I have a server with the same source files on it that can chew away it while my toenails grow. I was trying to do one last comparison of ffmpeg settings before I set it to run on everything though..... the method of rotating. That stack exchange showed four different ways to do a rotate. "transpose=1,transpose=1", "hflip,vflip", "transpose=2,transpose=2", and "rotate=PI:bilinear=0" I wish I had kept a 1 s
<bcn> I'm inclined to believe that the rotate=PI:bilinear=0 method is the fastest. the others imply doing two consequetive operations
<rodeo> do people really use x265 veryslow? veryslow makes sense for x264, but x265 slow is plenty slow enough for most people, I've heard of people using x265 slower, but x265 veryslow?
<aaabbb> bcn: if you want it to really max out everything you possibly could, do: -preset placebo -x265-params "bframes=16:ref=6:subme=7:me=sea" -pix_fmt yuv420p10le
<aaabbb> but beware it will take ages
<aaabbb> rodeo: sure people do, although sometimes with small changes to remove the stuff that *really* slows things down, like setting rd=4
<bcn> just occurred to me if I want to compare the different rotate methods I could use fast instead of slower for the h264 method. as long as I do the same on all runs it should get me results to compare sooner and still be a fair comparison of rotate methods
<aaabbb> bcn: you can use ffplay to compare them
<aaabbb> then you aren't reencoding you're just putting the video through a filter and displaying it
<bcn> my aptop has 8gb of ram on it, the server, maybe I shoudl mention, has 288. in case using more ram can help. and it's got a gpu too. I use that with pytorch for openai/whisper and jaidedai/EasyOCR my pitiful laptop just has inbredded intel iris graphics
<aaabbb> bcn: there are encoders that can use the gpu to accelerate things, but the quality is always going to be worse than pure software encoding
<bcn> and of course firefox needs at least 8.5 of those 8 gbs of memory on the laptop.... so at least swap is on nvme
SuicideShow has quit [Ping timeout: 240 seconds]
rvalue has joined #ffmpeg
<aaabbb> bcn: go to about:memory on firefox, click minimize memory
<aaabbb> it will do gc and seriously free up memory
SuicideShow has joined #ffmpeg
fossdd has quit [Ping timeout: 264 seconds]
TheSilentLink has quit [Quit: Good Bye! My bouncer has probably crashed or lost connection to the internet...]
fossdd has joined #ffmpeg
lucasta has joined #ffmpeg
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ffmpeg
rv1sr has quit []
<bcn> aaabbb: reminds me of that mysterious button I have in my breaker panel labeled "don't burn the house down" not sure if I should press it monthly or weekly. How ever often do I want to not burn the house down I suppose.
waleee has joined #ffmpeg
fossdd has quit [Ping timeout: 260 seconds]
TheSilentLink has joined #ffmpeg
<bcn> interesting. the rotate was WAY slower than the other options. any idea why? other than bilinear sounding complicted. about 2 minutes for flipflip, the transposes took about 2.5. and rotate a whopping 22 minutes
fossdd has joined #ffmpeg
<bcn> i think rotate can do any arbitrary number of degrees, which i WOULD expect to take a lot of compute. But i guess I assumed it used a more efficient method for 180 and 90's
<aaabbb> no, rotate is just inefficient
<aaabbb> and bilinear is one of the faster scaling algorithms haha
<bcn> filesize on all of them is about, if not exactly, the same. and a third of what the original file was while looking basically the same
<aaabbb> it's not meant to be foolproof, so it doesn't use any kind of special edge cases for rotating by 180 or 90 or 270
<aaabbb> that's why you'd use transpose
<bcn> fair enough. I'll stick to the hflip,vflip them since it's slightly faster and i don't understand the nuance between transpose=1 vs transpose=2. I'm kind of curious about fuzzy hashes now. if there's a way to computationally evaluate these are all "materially the same thing"
<aaabbb> ssim
<aaabbb> and psnr
<aaabbb> if you wanna compare how similar an encoding is to the original, you use those (but you gotta -tune ssim or -tune psnr when encoding for it to be valid)
<aaabbb> it'll tell you how close they are to the original. 1.000000 would mean pixel for pixel identical
<bcn> ooh lah lah. I see there's an hflip_vulkan and vflip_vulkan and a transpose_vulkan!!!
<bcn> is there a technical reason why there's not a single filter to rotate 180 in one step other than the inefficient rotate filter that could do 181 degrees? am I just that uniquely dumb for putting a camera upside down half the time? I guess most of them have threaded mounts only on one side so....
<aaabbb> because you don't want to rotate, you want to transpose
Marth64 has joined #ffmpeg
<bcn> invert I think. kind of scratching my head at the meaning of rotate and transpose. if it was a sheet of paper on the table I'd rotate it with my hand. ghen again I supppose I couldflip it once vertically and another time horizontally
<aaabbb> rotating 180 and transposing look the same, but they're done differently
fossdd has quit [Ping timeout: 264 seconds]
<bencoh> hmm ... I might be wrong, but https://ffmpeg.org//ffmpeg-filters.html#transpose-1 doesn't look like rotate 180 to me
fossdd has joined #ffmpeg
<bcn> bencoh: I ran it twice. as well as running transpose=2 twice
<bcn> i think if I wanted to rotate 90 (without flipping) I might be in a real pickle. not to mention having to deal with 16:9 vs 9:16 so please nobody do vertical video!!
<bcn> maybe someday they'll make the sensor square and the camera app can sample the appropriate rectangle depending on the phone's position. then again someone will want to record in full square I know it!! I had a sony Clie PDA a few decades ago, whos single camera literally swiveled around from front to back, and it must have flipped the video during recording
<aaabbb> rotating by a right angle (with or without flipping) is easy
<aaabbb> it's when it's not a perfect right angle that you have to use more sophisticated (and slow) scaling filters
<bcn> .. and the question of do yo crop it to avoid black/white space, or matte it, or something between. How does "round" video work? weird round displays like sides of buildings or wrist watches? they probably store full square and just crop it during playback so if viewed on a square display there might actually be content in the corners?
fossdd has quit [Ping timeout: 264 seconds]
<aaabbb> bcn: those are stored square, yeah
fossdd has joined #ffmpeg
zsoltiv_ has joined #ffmpeg
JanC_ has joined #ffmpeg
JanC has quit [Killed (lead.libera.chat (Nickname regained by services))]
JanC_ is now known as JanC
<bcn> interesting in https://ffmpeg.org/ffmpeg-filters.html, I see there is vflip and hflip. then vflip_vulkan and hflip_vulkan. But there's also just flip_vulkan which it says does h and v flipping. Any reason other than lack of interest why flip_vulkan exists but not just a regular flip?
<aaabbb> no idea
<bcn> does the gpu create lower quality encoding, even for something as mathematically "clear" as a transpose? Or is the quality loss because if I do the flip in the gpu I also have to do h265 in the gpu and h265 is not so "clear" and the routines for it are better on cpu?
<bcn> I guess there's not much to be gained by trying to use gpu to flip it and cpu to encode it. the encode is going to be the bottleneck i bet
fossdd has quit [Ping timeout: 256 seconds]
<aaabbb> bcn: transpose should be totally fine to accelerate with a gpu
fossdd has joined #ffmpeg
<bcn> how would I tell ffmpeg to use gpu for that but not h265? "vf "hwupload,flip_vulkan,format=yuv420p10le,scale=out_range=pc,hwdownload"" (knowing I have to add the global opts to init_hw_device before my input file of course? But I don't see where it's specified thenthat h265 should run on cpu
iive has joined #ffmpeg
<aaabbb> if you use -c:v libx265, then it's running on the cpu
<aaabbb> there are several things that you can do on a gpu, such as scaling, some kinds of denosing, etc
<bcn> gotcha. so encoding h265 on gpu would probably look like -c:v libx265_cuda or -c:v libx265_vulkan i guess
fossdd has quit [Ping timeout: 256 seconds]
<aaabbb> exactly
fossdd has joined #ffmpeg
fossdd has quit [Ping timeout: 256 seconds]
fossdd has joined #ffmpeg
lavaball has quit [Remote host closed the connection]
<furq> bcn: copying back from vram to ram is slow
AbleBacon has joined #ffmpeg
fossdd has quit [Ping timeout: 255 seconds]
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #ffmpeg
fossdd has joined #ffmpeg
user03 has joined #ffmpeg
user03 is now known as gchound
<bcn> furq: Is there an alternative to doing it you could propose? Or are you saying it would make more sense to ignore the gpu altogether because the copy process takes more time than a flip likely would?
fossdd has quit [Ping timeout: 268 seconds]
<bcn> an alternative to copyig back from vram to ram, I meant. I just took for granted I had to do that to run libx265 on it or safe it to any file at all
fossdd has joined #ffmpeg
<furq> i mean just ignore the gpu
<furq> those filters are mostly so you don't have to copyback when doing hardware decoding and encoding
fossdd has quit [Ping timeout: 255 seconds]
fossdd has joined #ffmpeg
theobjectivedad has quit [Quit: ZNC - https://znc.in]
theobjectivedad has joined #ffmpeg
lucasta has quit [Quit: Leaving]
fossdd has quit [Ping timeout: 246 seconds]
fossdd has joined #ffmpeg
fossdd has quit [Ping timeout: 255 seconds]
fossdd has joined #ffmpeg
fossdd has quit [Ping timeout: 256 seconds]
fossdd has joined #ffmpeg
emanuele6 has quit [Ping timeout: 264 seconds]
emanuele6 has joined #ffmpeg
LionEagle has quit [Ping timeout: 256 seconds]
LionEagle has joined #ffmpeg
fossdd has quit [Ping timeout: 268 seconds]
gchound has quit [Quit: WeeChat 3.8]
epony has quit [Remote host closed the connection]
fossdd has joined #ffmpeg
Tinos has joined #ffmpeg
epony has joined #ffmpeg
fossdd has quit [Ping timeout: 255 seconds]
vlm has quit [Quit: Leaving]
fossdd has joined #ffmpeg
darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg
lavaball has joined #ffmpeg
fossdd has quit [Ping timeout: 260 seconds]
fossdd has joined #ffmpeg
fossdd has quit [Ping timeout: 256 seconds]
cxc has joined #ffmpeg
fossdd has joined #ffmpeg
junaid_ has quit [Remote host closed the connection]
fossdd has quit [Ping timeout: 255 seconds]
lucasta has joined #ffmpeg
fossdd has joined #ffmpeg
Ogobaga has quit [Remote host closed the connection]
Ogobaga has joined #ffmpeg
ossifrage has quit [Ping timeout: 240 seconds]
fossdd has quit [Ping timeout: 256 seconds]
<rodeo> encoding H.265 on GPU does not involve libx265 at all
fossdd has joined #ffmpeg
YuGiOhJCJ has joined #ffmpeg
<rodeo> there's e.g. hevc_videotoolbox, hevc_qsv, hevc_nvenc, hevc_amf
<rodeo> libx265 is a purely software encoder, not a format
<aaabbb> and it generally produces superior quality to the hw accel encoders
<rodeo> especially anything that would be implemented in CUDA
<aaabbb> i don't think the encoding itself is implemented in cuda/opencl, doesn't it use hevc encoders native to the gpu?
<rodeo> for a very short time, GPGPU encoding was a thing
<rodeo> it was crap, people moved on
<aaabbb> what made it crap
<aaabbb> ?
<rodeo> the implementation
<aaabbb> was there any serious performance benefit?
<aaabbb> at least in theory with a good implementation?
<rodeo> not sure it was possible
<aaabbb> ic
<JEEB> GPUs used to be really bad with integer math (which apparently is somewhat better now), but still the main benefit of GPUs is that they can do massive threading. which well-compressing encoders don't generally do too much
<rodeo> it was fast, because it was heavily parrallelized, hurting compression efficiency to the point of making the encoder somewhat pointless
<JEEB> GPU encoding of formats which are not really geared at too much compression but take use of what GPUs can do well
<rodeo> remove the parallelism, lose the performance benefit
<JEEB> that is possible and people (including ATi) have done that
<aaabbb> i guess it makes more sense just to levarage things like avx
cxc has quit [Quit: Remote host closed the connection]
<iive> at least the nvidia encoder that used dedicated silicone for video, was really fast, it could encode multiple HD video streams at once. But the software encoder could produce around 30% smaller bandwidth for the same quality.
<JEEB> after those experiments hardware manufacturers understood that just making an ASIC would be much more optimized
alexherbo2 has quit [Remote host closed the connection]
<JEEB> for formats which were not designed for GPGPU from the ground up
<rodeo> then dedicated hardware arrived and gave the performance of those bad encoders while somewhat usable
<aaabbb> i would have thought that some of the bottlenecks like the motion estimation would be pretty good with gpgus as long a the merange is not huge
<rodeo> but even though those GPGPU encoders were around for what, two years max? over 10 years later people still come up with examples like "x265_cuda"
<iive> does somebody know if the asic encoders allow improvement of the implementation with firmware upgrade?
<aaabbb> iive: i doubt it, firmware upgrade could make minor changes but nothing major
<JEEB> iive: I think some do some specifics on the GPU and those binaries seem to be something that the drivers can feed
<JEEB> like the binary blobs for intel's or how AMD leaves rate control to external control as a possibility
<BtbN> x264 tried offloading the parts that GPUs in theory should be good at
<rodeo> everything is going through a driver anyway, there's already potential to fix bugs and make tweaks through that without having to touch the firmware
<BtbN> turns out, the overhead of shoveling all that data to and back from the GPU is slower than just doing the processing on the CPU
<aaabbb> rodeo: not much room for hw accel improvements
<aaabbb> via driver i mean
<iive> aaabbb, the problem is that modern encoders have motion estimation modes that go up to finding the minimal bitstream length.
bitbinge has quit [Ping timeout: 255 seconds]
fossdd has quit [Ping timeout: 276 seconds]
<JEEB> BtbN: yea. I would expect it might be less bad now with faster PCI-e and various improvements to opencl and vulkan compute or cuda, but it'd require once again funky amount of effort to check that :P
<aaabbb> modern video codecs are too complex. let's just go back to mpeg1
<aaabbb> motion vectors are for chumps
Marth64 has quit [Ping timeout: 240 seconds]
fossdd has joined #ffmpeg
<iive> it would be interesting way to optimize stuff, if we can do an (i)dct with a single instruction.
<aaabbb> iive: i think apple silicon does that for prores
<iive> niiice
<aaabbb> but generally the dct isn't the encoding bottleneck
<aaabbb> it only is with prores because it's a super simple intra-only mezzanine
<iive> at high bitrates, usually the cabac become bottleneck at least in software implementation. But if you have one instruction for dct, another for motion compensation and one for bitstream encoding...
<aaabbb> prores doesn't use cabac
VarunAgw has quit [Ping timeout: 268 seconds]
<iive> h264/5 does, afaik
<aaabbb> yeah
<aaabbb> well h264 can use cavlc instead in constrained baseline but ya
ossifrage has joined #ffmpeg
bitbinge has joined #ffmpeg
fossdd has quit [Ping timeout: 256 seconds]
fossdd has joined #ffmpeg
fossdd has quit [Ping timeout: 256 seconds]
kasper93 has quit [Remote host closed the connection]
fossdd has joined #ffmpeg
kasper93 has joined #ffmpeg
Marth64 has joined #ffmpeg
SakuraChan has joined #ffmpeg
HarshK23 has quit [Quit: Connection closed for inactivity]
Sakura`Kinomoto has quit [Read error: Connection reset by peer]
lusciouslover has quit [Ping timeout: 276 seconds]
lusciouslover has joined #ffmpeg
fossdd has quit [Ping timeout: 260 seconds]
fossdd has joined #ffmpeg
SuicideShow has quit [Ping timeout: 255 seconds]
SuicideShow has joined #ffmpeg