[Ffmpeg-devel-irc] ffmpeg.log.20170725

[burek]

[00:02:12 CEST] <pech> hi
[00:07:09 CEST] <pech> I wanna 2 pictures(image001.bmp and image002.bmp)combine to a mp4 with 6 seconds delay ...
[00:09:34 CEST] <pech> Does somebody have a link...?
[00:10:21 CEST] <pech> or better the whole line... starting with ffmpeg
[00:12:51 CEST] <pech> This is what i now have:
[00:12:56 CEST] <pech> ffmpeg -r 1 -i image001.bmp -ss 00:00:04 -i image002.bmp  -pix_fmt yuv420p test.mp4
[00:14:55 CEST] <pech> afk
[00:46:38 CEST] <pech> I leave bye
[01:09:56 CEST] <cryptodechange> hm, the 10bit encode test is near enough the exact same size, not changing any settings
[01:54:46 CEST] <furq> great news everyone
[01:54:47 CEST] <furq> https://github.com/google/pik
[01:56:00 CEST] <c_14> oh
[01:56:02 CEST] <c_14> yay
[01:56:06 CEST] Action: c_14 nips off to shoot himself
[01:56:12 CEST] <DHE> interesting... AVX2 required?
[01:56:51 CEST] <c_14> Why does it need libjpeg-dev and libpng-dev though
[01:56:59 CEST] <c_14> Is it some frankencodec?
[01:57:03 CEST] <furq> presumably for decoding
[01:58:05 CEST] <c_14> uses png for debug heatmaps apparently
[01:59:01 CEST] <c_14> and jpeg for benchmarking or something
[01:59:16 CEST] <furq> fun
[01:59:26 CEST] <furq> well i guess at least it's not HEIF
[01:59:35 CEST] <c_14> what was that other one, FLIF?
[01:59:37 CEST] <furq> yeah
[01:59:45 CEST] <furq> that does lossy now in spite of the name iirc
[01:59:55 CEST] <furq> nobody's backing that though so it'll probably just remain a curiosity
[02:06:40 CEST] <TD-Linux> it's basically JPEG fwiw
[02:08:18 CEST] <TD-Linux> much fancier entropy coder though
[02:08:46 CEST] <atomnuker> its pathetic, it still uses scalar quantization
[02:11:31 CEST] <iive> atomnuker: ?
[02:14:09 CEST] <furq> which, pik?
[02:15:29 CEST] <atomnuker> yes
[02:15:37 CEST] <atomnuker> quantizer.h, const float val = block_in[k] * scale[k];
[02:16:00 CEST] <atomnuker> and yes, the coefficients are all floats
[02:16:03 CEST] <atomnuker> ...
[02:18:25 CEST] <atomnuker> but hey, its work in progress, I'm sure in a few years time it'll compare better than hevc intra... in psnr
[02:19:02 CEST] <atomnuker> just after another jpeg-killer has started development by someone else at google
[02:19:42 CEST] <furq> i should probably check how flif compares to webp lossless
[02:19:52 CEST] <atomnuker> pathetic
[02:19:56 CEST] <furq> i don't think i have anything that actually decodes it though
[02:19:59 CEST] <atomnuker> absolutely pathetic
[02:20:07 CEST] <atomnuker> ffv1 beats both in speed and compression
[02:20:20 CEST] <furq> you should make an image format out of it then
[02:20:21 CEST] <atomnuker> flif took a minute to encode a 4k image last time I tested it
[02:20:23 CEST] <furq> everyone will love that
[02:20:28 CEST] <kerio> ffvhuff is so fast tho ;o
[02:20:40 CEST] <furq> christ
[02:20:44 CEST] <furq> kerio: we get it. you want to fuck ffvhuff
[02:20:48 CEST] <furq> can you do it privately
[02:20:55 CEST] <kerio> nu
[02:21:03 CEST] <kerio> you can't stop my love
[02:21:24 CEST] <furq> it's none of my business if you want to be sexually conjoined to a slightly rubbish video codec
[02:21:27 CEST] <furq> please stop making it my business
[02:45:22 CEST] <TD-Linux> I still haven't managed to verify the ffv1 vs flif claim
[02:53:25 CEST] <thebombzen> furq: FLIF is much better than webp lossless
[02:53:28 CEST] <thebombzen> I can tell you this personally
[02:53:48 CEST] <thebombzen> its lossy preprocessor also works much better, is much less lossy than webp's and improves everything dramatically
[02:53:56 CEST] <furq> idc about lossy
[02:54:11 CEST] <thebombzen> but yea, FLIF outperforms webp lossless in compression ratios
[02:54:33 CEST] <thebombzen> for screencaps and stuff that lossless formats excell at, it's still better than webp but not dramatically
[02:54:47 CEST] <thebombzen> but for anything remotely photographic it's much much better
[02:55:06 CEST] <thebombzen> it's also got progressive decoding, etc. it's a really well-designed format and the only real downside is speed at this point (and support)
[02:55:14 CEST] <thebombzen> its decode performance is slow
[02:55:51 CEST] <thebombzen> as for what supports it, I wrote a gdk-pixbuf loader for it so if you use Eye of Gnome / MATE, that works (ish). It's still kind of iffy and I need to iron it out
[02:55:52 CEST] <thebombzen> but it's there
[02:56:06 CEST] <thebombzen> but if you want it for anything other htan long-term archival, it's not great b/c it's slow and has bad support
[02:59:39 CEST] <thebombzen> furq: as for compression ratio, I'm not entirely sure why atomnuker thinks ffv1 has a better ratio. (It doesn't.)
[03:00:11 CEST] <atomnuker> it did when I tested it
[03:00:18 CEST] <atomnuker> (make sure to use the range coder)
[03:02:19 CEST] <furq> are you just encoding a single frame into nut or something
[03:03:23 CEST] <thebombzen> yes
[03:04:57 CEST] <TD-Linux> alright I'm going to settle this question with subset
[03:04:58 CEST] <TD-Linux> 1
[03:05:08 CEST] <thebombzen> granted, it was only 15% larger than flif and way faster
[03:05:22 CEST] <thebombzen> on a huge photograph, flif ended up at 20M and ffv1 was 23M
[03:05:42 CEST] <thebombzen> given the speed difference flif is probably "not worth it" but total trash isn't quite accurate
[03:05:52 CEST] <thebombzen> given that it *is* more efficient
[03:06:36 CEST] <thebombzen> (and yes, I used -coder 1 when encoding)
[03:07:28 CEST] <atomnuker> use -coder range_tab
[03:08:03 CEST] <TD-Linux> should I do 8-bit or 16-bit
[03:13:50 CEST] <thebombzen> atomnuker: same size, 23M
[03:13:57 CEST] <thebombzen> flif was 20M
[03:19:27 CEST] <atomnuker> yeah, sure, for 1 impractically huge image
[03:20:01 CEST] <thebombzen> atomnuker: I tried with several other images, and got very similar results
[03:20:29 CEST] <thebombzen> ffv1 was consistently about 15% larger than FLIF, but encoded and decoded very fast. FLIF took a long time
[03:21:00 CEST] <thebombzen> also depends on what FLIF version you used. if you used a version before a few months ago, that might make sense. FLIF release a new version in April
[03:21:22 CEST] <furq> goddamn flif is slow
[03:21:58 CEST] <furq> three minutes and counting
[03:22:22 CEST] <TD-Linux> yeah still waiting on subset1
[03:22:45 CEST] <furq> this is already like 20x slower than cwebp -z 9
[03:22:57 CEST] <furq> maybe i shouldn't have used -E100
[03:23:05 CEST] <TD-Linux> oh I just used defaults
[03:23:09 CEST] <TD-Linux> though on 16 bit images...
[03:23:20 CEST] <furq> yeah this is rgb24 but it's like 4k by 8k
[03:23:40 CEST] <furq> five minutes now
[03:23:51 CEST] <furq> ffv1 took about five seconds
[03:24:42 CEST] <TD-Linux> hmm ffv1 can't do 16bit rgb
[03:25:03 CEST] <TD-Linux> ah strict -2 gets it
[03:25:09 CEST] <furq> idk why i said "4k by 8k". i could have said 8k
[03:25:24 CEST] <TD-Linux> 227M	subset1-ffv1
[03:25:24 CEST] <TD-Linux> 202M	subset1-flif
[03:27:32 CEST] <furq> http://vpaste.net/HVLv4
[03:27:41 CEST] <furq> test.flif took 8 minutes though so it fucking better be small
[03:27:42 CEST] <thebombzen> furq: don't use -E100
[03:27:46 CEST] <furq> too late
[03:27:59 CEST] <thebombzen> as in, it's not guaranteed to even be better than -E60 (yes really)
[03:28:01 CEST] <thebombzen> the UI is quite bad
[03:28:07 CEST] <furq> i expected that tbh
[03:28:15 CEST] <thebombzen> but FLIF is still a bit early in its development so that shouldn't be a surprise
[03:28:18 CEST] <thebombzen> the default is -E60
[03:28:22 CEST] <furq> i know
[03:28:42 CEST] <thebombzen> I mean the same reason lasse collins recommends against xz -9 most of the time
[03:28:50 CEST] <furq> and the same reason flac -5 is the default
[03:28:55 CEST] <thebombzen> for gzip -9 is much slower than -7 and usually not worth it
[03:29:02 CEST] <furq> the default is generally the point at which diminishing returns kicks in
[03:29:14 CEST] <furq> but i was using cwebp -z 9 so i figured i should make it a fair test
[03:29:17 CEST] <thebombzen> although for zip it's -6. -7 is a lot better than -6 but then it starts deminishing
[03:29:27 CEST] <thebombzen> gzip* I should say
[03:29:40 CEST] <furq> but yeah holy shit that is slow
[03:29:51 CEST] <thebombzen> for XZ it's not that -9 doesn't help, but the primary advantage of -9 is a larger dictionary
[03:30:03 CEST] <thebombzen> so you generally should only use -9 if you're compressing an enormous file with long-range redundancy
[03:30:30 CEST] <thebombzen> but even then you can use tricks to mitigate the need for that, like sorting filenames before you tar them up
[03:30:36 CEST] <furq> you're still talking about xz
[03:37:38 CEST] <TD-Linux> in the land of lossless diminishing returns really kick in quick
[03:37:50 CEST] <TD-Linux> flif getting as far as it does is pretty impressive despite the speed
[03:38:49 CEST] <TD-Linux> audio is even worse, the spread between the best and worst formats is like 4% http://wiki.hydrogenaud.io/index.php?title=Lossless_comparison
[03:39:41 CEST] <furq> https://xiph.org/flac/images/all-tracks-decode.png
[03:39:56 CEST] <furq> hth
[03:40:56 CEST] <furq> tak is pretty impressive but still not worth it at all
[03:42:03 CEST] <thebombzen> APE too is one of those ones people like to use a lot for some reason
[03:42:15 CEST] <furq> well the reason is obvious, it compresses better
[03:42:23 CEST] <thebombzen> even lavc-flac -compression_level 12 competes pretty well though
[03:42:30 CEST] <furq> and has better support than la and optimfrog which nothing supports
[03:42:46 CEST] <thebombzen> the only reason I can read APE is lavc has a decoder
[03:42:53 CEST] <thebombzen> the reference encoder/decoder is a windows binary
[03:43:12 CEST] <furq> i don't know of anything that has an la or optimfrog decoder
[03:43:16 CEST] <furq> other than the reference binaries
[03:44:26 CEST] <furq> those two, mp4 als and wma lossless are the only formats on that list i've never seen in the wild
[03:44:42 CEST] <thebombzen> are there even decoders for those in lavc?
[03:44:57 CEST] <furq> some of them
[03:45:03 CEST] <furq> ape, tak, alac definitely
[03:45:10 CEST] <furq> and wavpack and shn
[03:45:15 CEST] <thebombzen> alac is useful for some people
[03:45:24 CEST] <furq> and tta apparently
[03:45:39 CEST] <thebombzen> in particular alac-inside-mp4 is how you put lossless audio on an iDevice through the normal sync method
[03:45:41 CEST] <thebombzen> some people care about that
[03:45:48 CEST] <furq> and also wmalossless and mp4als
[03:45:58 CEST] <furq> no optimfrog or la though
[03:46:26 CEST] <furq> i don't think it matters because nobody has ever actually used them
[03:46:35 CEST] <furq> it's like mp4 sls, it only exists in theory
[03:46:52 CEST] <thebombzen> because of lavc, alac is fairly well supported, but it's also slightly less efficient than flac and has no real use other than iDevices
[03:46:57 CEST] <thebombzen> cause apple's closed software
[03:47:02 CEST] <furq> iOS 11 is apparently finally adding flac support
[03:47:07 CEST] <thebombzen> really? that's impressive
[03:47:10 CEST] <furq> supposedly
[03:47:19 CEST] <thebombzen> I know that Apple has been avoiding Xiph formats intentionally on principle
[03:47:21 CEST] <furq> my favourite thing about alac is that i don't think mp4 officially supports it
[03:47:24 CEST] <furq> it's not part of any spec iirc
[03:47:40 CEST] <thebombzen> mp4 doesn't yea, but mov does so I assume lavf uses the same mechanism
[03:47:46 CEST] <thebombzen> like mov has a spec for it
[03:47:49 CEST] <furq> oh
[03:47:54 CEST] <furq> shame
[03:48:05 CEST] <thebombzen> also you *can* mux it to mp4 but you need -f ipod
[03:48:16 CEST] <thebombzen> -c alac -f ipod out.m4a
[03:48:21 CEST] <furq> well i assumed ffmpeg was following the well-known "whatever the fuck itunes does" mp4 spec
[03:48:25 CEST] <furq> like it does for album art
[03:48:33 CEST] <thebombzen> I don't know
[03:48:39 CEST] <thebombzen> using -c alac -f mp4 throws an error
[03:48:42 CEST] <furq> it doesn't really matter because fuck alac
[03:48:46 CEST] <thebombzen> using -c alac -f ipod does not, but outputs an mp4 file
[03:49:10 CEST] <thebombzen> I think -f ipod is basically the cheaty muxer that puts quicktime stuff in mp4 that isn't supposed to be there but is part of the MOV spec
[03:49:23 CEST] <furq> i think they realised that HEIF and no flac was some kind of critical mass of shittiness for an operating system
[03:49:46 CEST] <thebombzen> HEIF? is that an apple thing?
[03:49:47 CEST] <furq> so they were forced to add flac support before all the apple logos on their devices magically change to microsoft logos
[03:49:56 CEST] <furq> HEIF is technically a nokia thing but apple are going full bore with it
[03:50:00 CEST] <thebombzen> wow
[03:50:02 CEST] <furq> it's a NEW IMAGE FORMAT (hooray!!!!!!) based on hevc iframes
[03:50:08 CEST] <furq> sorry i mean
[03:50:11 CEST] <thebombzen> you mean like BPG
[03:50:13 CEST] <furq> it's a NEW IMAGE FORMAT (hooray!!!!!!) based on hevc (HOORAY!!!!!!!!!!!!!!!!!!) iframes
[03:50:25 CEST] <furq> and yeah it's pretty much bpg
[03:50:29 CEST] <thebombzen> but way isn't the whole world except Apple trying to avoid hevc
[03:50:33 CEST] <furq> yes
[03:50:33 CEST] <furq> they are
[03:50:35 CEST] <thebombzen> HEVC is expensive as fuck so unless you're the MPEG-L
[03:50:38 CEST] <thebombzen> MPEG-LA
[03:50:43 CEST] <furq> yup
[03:50:52 CEST] <thebombzen> lol making it 3x as expensive as H.264 seems to have backfired
[03:51:03 CEST] <furq> but the important thing is that google didn't make it, so it's better
[03:51:10 CEST] <thebombzen> everyone is like, "yea, I'll keep using my cheaper license, existing infrastructure, and x264"
[03:51:28 CEST] <furq> and also you have to pay out the ass if you want to write a program that has an HEIF decoder on non-apple systems
[03:51:31 CEST] <furq> but mostly the first thing! yay
[03:51:48 CEST] <thebombzen> I mean nobody lkes vp9 so they could have made it not absurdly expensive and people still would use it over vp9
[03:52:05 CEST] <thebombzen> but they kinda just scared everyone back to their cheap H.264 and x264
[03:52:13 CEST] <furq> well they did make it less expensive
[03:52:23 CEST] <furq> unfortunately they also didn't bother preventing three other patent pools from appearing
[03:52:36 CEST] <furq> so now you need four licenses that are all more expensive than the one avc license you need
[03:52:45 CEST] <furq> and potentially more
[03:53:11 CEST] <furq> either that or you need to spend an equal amount of money on patent lawyers to figure out which pools you potentially owe money to
[03:53:12 CEST] <thebombzen> Software Patents (TM)
[03:53:19 CEST] <thebombzen> Patents protect innovation, right?
[03:53:31 CEST] <furq> i sure am glad i'm in the EU
[03:53:34 CEST] <thebombzen> They surely don't discourage people from trying to create new things
[03:53:36 CEST] <furq> oh...wait...ah fuck
[03:53:38 CEST] <thebombzen> that would be silly
[03:53:51 CEST] <thebombzen> Americans had a brief moment of smugness
[03:54:00 CEST] <furq> yeah that didn't last long did it
[03:54:08 CEST] <thebombzen> then we elected an orange
[03:54:14 CEST] <thebombzen> and we lost our right to be anti-smug
[03:54:26 CEST] <thebombzen> or whatever we did for like 2 months
[03:54:32 CEST] <thebombzen> but it goes to show there's idiots everywhere
[03:54:51 CEST] <furq> i don't want to brag but i already knew both of those countries were fucked
[03:55:11 CEST] <thebombzen> yea I should just move back to the country of my ancestors
[03:55:13 CEST] <thebombzen> ohwait which one is that
[03:55:23 CEST] <thebombzen> Ukraine? nvm
[03:55:41 CEST] <furq> you should just become donald trump's next wife
[03:55:55 CEST] <thebombzen> but then I'd have to be an illegal immigrant
[03:56:00 CEST] <thebombzen> but I was born here, can't be possible
[03:56:38 CEST] <thebombzen> in order to do that I'd have to move to Eastern europe, renounce my citizenship, say, "oh wait, nvm, I love Murica, we have the best things, this other country is wrong so sad"
[03:56:46 CEST] <thebombzen> and pretend that I'm female
[03:56:58 CEST] <thebombzen> not worth it, tbh, when I could just sit at home and make fun of him
[03:57:01 CEST] <furq> just pretend you're a big truck
[03:57:08 CEST] <furq> vroom vrooom
[03:57:18 CEST] <furq> honk honnkkkk
[03:57:34 CEST] <thebombzen> maybe he watches enough family guy he'd belive it
[04:06:52 CEST] <TD-Linux> thebombzen, ironically it's expensive even if you're the MPEG-LA, because HEVC advance charges more.
[04:07:20 CEST] <thebombzen> so the business practice they created ended up screwing them
[04:07:21 CEST] <furq> do they actually sell one another licenses
[04:07:21 CEST] <thebombzen> excellent
[04:07:35 CEST] <furq> don't they all claim to have patent pools that cover the whole thing
[04:07:40 CEST] <TD-Linux> flac actually has a mp4 containerization now and it works in firefox
[04:08:41 CEST] <TD-Linux> furq, no
[04:08:47 CEST] <TD-Linux> they only cover the patents they have
[04:08:59 CEST] <TD-Linux> even for H.264, MPEG-LA never claimed to cover the whole thing
[04:09:25 CEST] <furq> i know velos are claiming to cover the whole thing
[04:09:31 CEST] <TD-Linux> really? interesting
[04:09:35 CEST] <TD-Linux> their pricing is also unannounced
[04:09:39 CEST] <furq> although it's probably weasel-worded well enough that they can claim to not actually be saying that
[04:09:56 CEST] <furq> oh fucking hell i forgot their fucking piss awful scrolljacking on their site
[04:10:05 CEST] <furq> i'll be back in five minutes when i have figured out how to find some text on a website
[04:10:37 CEST] <TD-Linux> I can't even select the relevant text
[04:10:38 CEST] <furq> fucking hell this shit should be fucking banned
[04:10:45 CEST] <furq> you should be wiped off the face of the fucking earth for websites like this
[04:11:04 CEST] <furq> Were streamlining the patent licensing process by offering a single license to end user product companies that manufacture or sell HEVC-enabled devices, thereby creating a solution for them and patent holders alike, said Kasim Alfalahi, co-founder of the Marconi Group, an entity formed to create, launch and support new patent licensing platforms, including Velos Media.
[04:11:13 CEST] <furq> i had to find a press release somewhere else
[04:11:22 CEST] <TD-Linux> yeah so on their website they say they have 5 different companies
[04:11:27 CEST] <TD-Linux> and it's a single license for those company's things
[04:11:38 CEST] <TD-Linux> as opposed to negotiating with the companies separately
[04:11:40 CEST] <furq> but yeah i notice that doesn't actually say "this is the only license you need"
[04:11:46 CEST] <furq> it just sounds a lot like it says that
[04:11:59 CEST] <furq> i wonder why~
[04:13:07 CEST] <furq> anyway, i think it is extremely cool and good that apple have decided to use this not only for all video but also for images
[04:13:16 CEST] <klaxa> wow scrolling like that sucks
[04:13:22 CEST] <klaxa> why are people allowed to do that
[04:13:25 CEST] <furq> hopefully they figure out some way to use it for audio as well somehow
[04:14:09 CEST] <furq> also this is to say nothing of the way velos have an "h264 vs hevc" comparison video
[04:14:12 CEST] <furq> which is a webm
[04:14:25 CEST] <furq> and they just scaled the "h264" video with nearest
[04:15:56 CEST] <TD-Linux> LOL I just found that video now
[04:17:21 CEST] <TD-Linux> >vp8/vorbis
[04:17:37 CEST] <furq> noice
[04:17:46 CEST] <furq> there is an h264 one as well
[04:17:54 CEST] <furq> idk if that's more or less ironic
[04:17:56 CEST] <TD-Linux> this is like north korea using linux
[07:21:42 CEST] <FlyingJester> I have a capture card that has multiple inputs (RF, Composite, and S-Video). How would I choose which one to use when capturing?
[07:37:54 CEST] <kerio> why does v4l2enc only support raw video? :(
[10:40:58 CEST] <pihpah> How can I extract HDMV PGS subtitles from an MKV file to something 'Subtitle Edit' would understand? Like *.sup or *.sub/*.idx  formats.
[10:53:10 CEST] <ubitux> we have demuxers but no muxers
[10:53:47 CEST] <tdr> https://trac.ffmpeg.org/wiki/ExtractSubtitles ?
[10:54:11 CEST] <ritsuka> mkvextract
[11:37:42 CEST] <memphisw> i use `./ffmpeg -i xxx.mp4 -i xxx%03d.png out.mp4` to merge a mp4 and a gif, pngs is the shorter one, how can i repeat pngs from beginning after pngs are use out
[13:27:01 CEST] <memphisw> -loop i in input option, i figure it out
[16:31:57 CEST] <Mavrik> Hmm, so what's more efficient overall, slice or frame based threading for H.264 DEcodec?
[16:32:00 CEST] <Mavrik> *decoder
[16:32:50 CEST] <JEEB> generally frame based threading is faster, slice based decoding gives less latency
[16:33:18 CEST] <JEEB> I implemented slice based multithreading for another decoder and that was the general gist as well.
[16:33:33 CEST] <JEEB> you did get a speed-up, but it wasn't as fast as frame-based threading can be
[16:33:51 CEST] <JEEB> but on the other hand, slice based threading lets you have less threading-based latency
[16:34:55 CEST] <Mavrik> Hmm, point.
[16:35:37 CEST] <Mavrik> Having a bit of issues with H.264 1080p decode being slow/late even though the machine's CPUs aren't saturated.
[16:37:05 CEST] <kepstin> a lot of the latency when decoding h264 depends on the encoder settings used - if b-frames are used, the decoder has to buffer frames to reorder them.
[16:37:31 CEST] <JEEB> of course
[16:38:12 CEST] <Mavrik> Mhm. I don't really have issues with latency though.
[16:38:18 CEST] <Mavrik> Just throughput
[16:38:26 CEST] <JEEB> yea, then frame threads is the one you want
[16:38:32 CEST] <Mavrik> Meaning - the decoder can'
[16:38:32 CEST] <JEEB> and that's more tested, anyways
[16:38:42 CEST] <Mavrik> *can't seem to decode as fast as the stream is coming in
[16:38:46 CEST] <Mavrik> Ah, makes sense.
[16:43:19 CEST] <kepstin> with h264, I think slice-based threading on the decoder can only be done if the video was encoded with slices?
[17:00:49 CEST] <DHE> I'm in the same boat. just use frame-based decoding and a sane number of threads. I'm using 4
[17:01:25 CEST] <JEEB> kepstin: naturally
[17:01:33 CEST] <JEEB> if you have a single slice then that's it
[17:50:31 CEST] <jcelerier> hello :) where can I find how to devise the codec to use with a given file, in the C API ?
[17:50:59 CEST] <jcelerier> (I'd like to make a function that just decodes any kind of audio file to an array of float)
[18:09:43 CEST] <jcelerier> (and I don't want to use ffprobe, or worse, libmediainfo)
[18:29:20 CEST] <leif> Does anyone know why the pointer returned by `avformat_open_input` would be NULL?
[18:29:34 CEST] <leif> (When the given file exists.)
[18:32:21 CEST] <DHE> check the return code for a reason
[18:32:24 CEST] <leif> Also the returned status is 0
[18:32:33 CEST] <leif> DHE: ya, its 0.
[18:37:44 CEST] <leif> DHE: Also, fwiw, the last thing to get sent to the log seems to be: on_parse_exit_offset=106479581
[18:46:21 CEST] <A3G1S> Hey Guys, need small help. When I am running ranlib on avutil.so I am getting -> Shared library: [libmp3lame.so.0]
[18:46:29 CEST] <A3G1S> How to make it so it shows -> Shared library: [libmp3lame.so] and not with .0 extension
[20:15:31 CEST] <leif> Another question, is there a changlog for libavfilter?
[20:15:58 CEST] <leif> I say that because libavfilter.6.65.100 does not seem to have av_buffersink_get_type, but avfilter.6.82.100 does.
[20:19:24 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/APIchanges;h=69f876e6c3e81103e1797ce1e27c3016864ae28e;hb=HEAD#l161
[20:19:36 CEST] <JEEB> the doc/APIchanges file
[20:23:01 CEST] <leif> Thank you.
[20:58:24 CEST] <Agafnd> so I have a 1920x1080 video, which is like a ratio of 1.77..., and I need it to be in either 4:3 or 16:9 ratio.
[20:58:52 CEST] <JEEB> use libavfilter according to your requirements
[20:59:41 CEST] <Agafnd> I'd like to add black bars to the sides, rather than stretching it.
[20:59:47 CEST] <Agafnd> can libavfilter do that?
[20:59:58 CEST] <furq> !filter pad
[20:59:58 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#pad-1
[21:00:23 CEST] <pgorley> Agafnd: 1920x1080 is 16:9
[21:00:33 CEST] <pgorley> 1920/1080==16/9
[21:01:33 CEST] <Agafnd> pgorley: *actually* I think it's 1080x1920
[21:01:43 CEST] <Agafnd> short side on top
[21:01:54 CEST] <Agafnd> which is a bit problematic.
[21:02:40 CEST] <DHE> wouldn't it be better to just store the aspect ratio properly and let the player deal with it?
[21:03:06 CEST] <Agafnd> well, this *wouldn't* be a problem
[21:03:12 CEST] <durandal_1707> players sucks
[21:03:24 CEST] <Agafnd> except devede doesn't want to deal with it.
[21:08:16 CEST] <cbsrobot> Agafnd: https://www.youtube.com/watch?v=Bt9zSfinwFA
[21:09:19 CEST] <Agafnd> cbsrobot: not my fault ;_;
[21:19:14 CEST] <Agafnd> hm this is a rather cpu-expensive computation
[21:19:17 CEST] <Agafnd> *shrug*
[21:24:49 CEST] <Blubberbub> is there a way to enable/disable filters based on (minimum) file length?
[21:27:20 CEST] <durandal_1707> no
[21:27:58 CEST] <durandal_1707> Agafnd: whats cpuexpensive?
[21:31:07 CEST] <Agafnd> adding a black bar to the side of every single frame
[21:31:17 CEST] <Agafnd> on second thought that's not too surprising
[21:32:04 CEST] <durandal_1707> thats very cheap, unless you run it on pottato
[21:34:03 CEST] <Agafnd> well it took forever and ran the four cores at 98-100% each
[21:34:57 CEST] <durandal_1707> put whole command here
[21:36:26 CEST] <Agafnd> ffmpeg -i video.mp4 -vf pad=1260:1920:180:0 video-bar.mp4
[21:37:14 CEST] <durandal_1707> because you are encoding
[21:37:34 CEST] <Agafnd> ...ah. how doesn't I encode?
[21:37:45 CEST] <Agafnd> something to do with "copy"?
[21:38:04 CEST] <durandal_1707> but then you cant filter
[21:38:07 CEST] <Blubberbub> you cannot copy and filter, though
[21:38:14 CEST] <Agafnd> good point
[21:39:17 CEST] <Agafnd> so is there anything I *can* do to speed it up?
[21:40:31 CEST] <furq> are you burning this to a dvd
[21:40:39 CEST] <Agafnd> I will be yes
[21:40:51 CEST] <furq> well then scale it to the right resolution
[21:41:07 CEST] <furq> honestly you could just encode the video in one step with ffmpeg instead of going through an intermediate format
[21:41:36 CEST] <furq> i have no idea whether devede will let you do that though
[21:43:27 CEST] <furq> actually
[21:43:36 CEST] <furq> how long is this video and do you have plenty of free disk space
[21:44:26 CEST] <Agafnd> about 5 or 6 minutes, and about 200G
[21:44:59 CEST] <furq> is this ntsc or pal dvd
[21:45:06 CEST] <Agafnd> ntsc
[21:46:13 CEST] <furq> -i video.mp4 -vf scale=270:480,pad=720:480:225 -c:v ffvhuff out.nut
[21:46:16 CEST] <kerio> gstreamer is bloody MENTAL
[21:46:20 CEST] <kerio> how do people use that
[21:46:31 CEST] <furq> kerio: look, i used ffvhuff in an example command
[21:46:34 CEST] <furq> do u love me now
[21:46:41 CEST] <kerio> i always love u bby
[21:46:43 CEST] <furq> Agafnd: actually
[21:46:47 CEST] <furq> -i video.mp4 -vf scale=270:480,pad=720:480:225 -c:v ffvhuff -c:a copy out.nut
[21:47:01 CEST] <furq> that should be extremely quick
[21:47:11 CEST] <Agafnd> furq: what does that do, exactly?
[21:47:32 CEST] <furq> scales the video to 270x480, pads it to 720x480 (ntsc dvd) and then encodes it with a fast lossless codec
[21:47:51 CEST] <Agafnd> what's .nut?
[21:47:54 CEST] <furq> apparently devede uses libavcodec so it should accept that as an input
[21:47:58 CEST] <furq> .nut is a container
[21:48:20 CEST] <Agafnd> okay, will try
[21:48:48 CEST] <furq> if it doesn't like .nut then try mkv
[21:48:52 CEST] <furq> that should work though
[21:49:14 CEST] <Blubberbub> TODO: ffmpeg-dvd-output-protocol, that can write directly to disk ;)
[21:49:36 CEST] <furq> it would be nice if it could read dvd directory structures, never mind write them
[21:49:48 CEST] <furq> i guess going through tccat is fine though
[21:50:01 CEST] <furq> i can imagine not wanting to go near that whole pile of shit
[21:50:45 CEST] <kerio> can a mkv fit a dvd exactly
[21:50:50 CEST] <kerio> with all extra content and menus
[21:51:07 CEST] <furq> does mkv support menu navigation
[21:51:13 CEST] <furq> also that would generally suck ass
[21:51:33 CEST] <furq> also i don't think it supports multi-angle either
[21:51:41 CEST] <furq> and there's no distinction between title and chapter
[21:51:49 CEST] <furq> so basically "yes, but it'll be shit"
[21:52:20 CEST] <kerio> wait, mkv is the one that can't represent 24000/1001 fps exactly, right
[21:52:34 CEST] <furq> yeah but dvds are never that framerate
[21:52:41 CEST] <furq> it can't represent 30000/1001 either though
[21:53:05 CEST] <furq> 25 is fine though so it's all good
[21:57:28 CEST] <Agafnd> furq: hey, that works pretty well
[21:57:30 CEST] <Agafnd> thanks
[22:20:38 CEST] <redrabbit> is there other options than maxrate and bufsize to keep a stream under a certain bit rate
[22:21:46 CEST] <furq> does there need to be
[22:33:15 CEST] <redrabbit> do they work with libx265 ? i see the bitrate going higher than the limit, stutters on the low bandwith link
[22:36:11 CEST] <kepstin> redrabbit: the ffmpeg options for it probably aren't hooked up, use -x265-params
[22:41:21 CEST] <redrabbit> i switched to theses, trying stability now
[23:07:49 CEST] <kerio> furq: what's the simplest format with a PTS for raw video?
[23:08:00 CEST] <kerio> that's understood by ffmpeg, that is
[23:31:14 CEST] <wondiws2> I forgot the command to extract ac3 from a vob file, what is it again? This time I will make a note :)
[23:31:47 CEST] <dystopia_> ffmpeg -i input.vob -sn -vn -acodec copy out.ac3
[23:33:32 CEST] <wondiws2> dystopia_, "could not find codec parameters" :(
[23:33:36 CEST] <dystopia_> if it has more than 1 audio track you will need to use -map to select which one you want
[23:33:43 CEST] <dystopia_> you sure it's ac3?
[23:34:34 CEST] <wondiws2> dystopia_, yes, but there seems to be a nasty menu in front of it, I think I'm gonna re-read my DVD, but this time with DVDDecryptor
[23:34:41 CEST] <dystopia_> ffmpeg -i input.vob -ac 2 -y out.wav
[23:34:44 CEST] <dystopia_> try that
[23:35:11 CEST] <wondiws2> dystopia_, negative
[23:35:27 CEST] <dystopia_> you should paste your termial logs to pastebin
[23:35:37 CEST] <wondiws2> dystopia_, never mind, I'm gonna re-rip again
[23:35:43 CEST] <dystopia_> also do ffprobe input.vob and post that to pastebin
[23:35:43 CEST] <wondiws2> I'm pretty sure something went wrong there
[23:35:48 CEST] <dystopia_> ok
[00:00:00 CEST] --- Wed Jul 26 2017