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

[burek]

[00:02:04 CET] <JEEB> pretty sure you'll want to limit your support first
[00:02:10 CET] <JEEB> since there's a lot of really limited stuff there
[00:02:31 CET] <JEEB> and IIRC there's a by_name getter for them
[00:02:43 CET] <JEEB> (and the names of things rarely change)
[00:02:57 CET] <JEEB> so I think you'll want to have a list of the ones you actually support
[00:03:26 CET] <alexpigment> jkqxz: to work around AMF issue in Windows Media Player, you can specify '-flags loop' in the ffmpeg command (until the driver issue is fixed next month). not sure why it works, and I know you probably don't personally have any reason to use it, but I figured I'd let you know
[00:08:55 CET] <alexpigment> roughly how much of a speed boost would you see from disabling the deblock filter on x264?
[00:09:11 CET] <alexpigment> i can test this, but I figured I'd quickly ask in case it was common knowledge
[00:09:56 CET] <alexpigment> ok, i'll go test ;)
[00:10:06 CET] <JEEB> speed boost for what?
[00:10:09 CET] <JEEB> encoding or decoding?
[00:10:23 CET] <durandal_170> not much, also are your pc from prev century.?
[00:10:44 CET] <JEEB> yea, the last time I used -tune fastdecode was for my xbox :)
[00:10:48 CET] <JEEB> with xbmc
[00:10:58 CET] <JEEB> 733MHz custom celeron chip \o/
[00:11:19 CET] <alexpigment> encoding
[00:11:37 CET] <JEEB> nope :) usually that is done together with the presets in general
[00:12:23 CET] <JEEB> ok, the last preset benchmark I saw hadn't even considered the faster-than-medium presets :)
[00:12:26 CET] <JEEB> so never mind
[00:12:43 CET] <alexpigment> ok, running some tests now
[00:17:45 CET] <alexpigment> ok, the answer was not a noticeable amount
[00:17:52 CET] <alexpigment> maybe that has to do with other settings
[00:18:14 CET] <alexpigment> but I just had a moment where I realized I was encoding from non-lossy sources and it was probably applying an unnecessary deblock
[00:18:22 CET] <JEEB> yea I didn't expect it to be too time-consuming :P
[00:18:23 CET] <JEEB> uhh
[00:18:25 CET] <JEEB> lol
[00:18:35 CET] <JEEB> alexpigment: did you forget the deblock is post-encode
[00:18:42 CET] <JEEB> it's the thing that makes shit look better
[00:19:02 CET] <alexpigment> oh, it's decode only?
[00:19:19 CET] <alexpigment> i was reading some article that i must have misread
[00:19:19 CET] <JEEB> not really, the encoder has to utilize it as well, but it mostly takes time on decoding side IIRC
[00:19:22 CET] <alexpigment> and it was showing screenshots
[00:19:43 CET] <JEEB> of course x264 has to do the reconstruction itself as well
[00:19:44 CET] <alexpigment> anyway, i was like "wait. why would I ever want deblock when the source isn't lossy?"
[00:20:08 CET] <JEEB> because you most likely end up with compression artifacts which that stuff is great at hiding
[00:20:24 CET] <JEEB> in-loop deblocking is one of those things that came up in H.263 and for some godawful reason didn't en up in MPEG-4 Part 2
[00:20:41 CET] <JEEB> and thus the difference from MPEG-4 Part 2 to AVC/H.264 was even bigger :D
[00:20:52 CET] <JEEB> so you had suddenly CABAC, in-loop deblocking etc
[00:20:54 CET] <alexpigment> ah
[00:21:15 CET] <alexpigment> i always was confused between h.263 and mpeg-4 part 2
[00:21:19 CET] <alexpigment> in my head, they're the same thing
[00:21:25 CET] <alexpigment> but i know they're not exactly the same
[00:21:31 CET] <JEEB> they're related but MPEG-4 Part 2 removed some things and added others
[00:21:49 CET] <alexpigment> like i consider divx mpeg-4 part 2, but maybe that's closer to h.263?
[00:21:52 CET] <alexpigment> i don't even know
[00:22:03 CET] <JEEB> divx was an mpeg-4 part 2 implementation
[00:22:06 CET] <JEEB> xvid as well
[00:22:16 CET] <JEEB> even the hacked up divx ;-)
[00:22:24 CET] <JEEB> which based on MS's MPEG-4 Part 2 encoder
[00:22:33 CET] <JEEB> (IIRC)
[00:22:38 CET] <alexpigment> ok, i guess the point of confusion is that an h.264 part 2 decoder will decode h.263
[00:23:08 CET] <JEEB> no? also mpeg-4 part 2 never got ratified over at ITU-T
[00:23:09 CET] <alexpigment> i've never even tried ms mp4. i don't know what it does, and I never had a need to try it
[00:23:10 CET] <JEEB> unsurprisingly
[00:23:18 CET] <JEEB> well, at this point there's no reason
[00:23:25 CET] <JEEB> this was early 2000s yo
[00:23:36 CET] <alexpigment> from the h.263 wiki: "MPEG-4 Part 2 is H.263 compatible in the sense that basic "baseline" H.263 bitstreams are correctly decoded by an MPEG-4 Video decoder.[8][11]"
[00:23:46 CET] <JEEB> ah yes, that maybe
[00:23:49 CET] <alexpigment> so i guess baseline is the operative word
[00:23:54 CET] <JEEB> if it lacked the in-loop deblocking etc
[00:24:03 CET] <alexpigment> most likely
[00:24:12 CET] <alexpigment> baseline anything lacks most of what makes the codec good ;)
[00:25:39 CET] <alexpigment> alright. enough learning today. time to go home and drink beer
[00:50:47 CET] <bilb_ono> is there a good way to analyze movement in a video? I want to look at a video and any time there is movement, create a clip of the movement
[00:51:08 CET] <bilb_ono> so when movement is happeneing, I want to detect it
[01:26:18 CET] <therage3> bilb_ono: try this, this is someone asking how to do what you said with an IP camera feed https://superuser.com/questions/984841/ffmpeg-remove-parts-without-motion
[01:26:40 CET] <therage3> bilb_ono: the proposal is to use the select filter to compare similarity of two consecutive frames
[01:42:20 CET] <SortaCore> bilb_ono: that would involve a difference filter and edge filter
[01:42:27 CET] <SortaCore> and then some...
[01:48:07 CET] <furq> bilb_ono: maybe mpdecimate
[01:48:10 CET] <furq> !filter mpdecimate
[01:48:10 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#mpdecimate
[01:48:41 CET] <furq> overlay a timestamp, set max to 0 and then you'll only get frames that differ from the previous frame
[01:49:09 CET] <furq> overlay a timestamp so that you can remux to cfr
[01:49:27 CET] <furq> that's not exactly what you asked for but afaik it's as close as ffmpeg will get you
[01:50:01 CET] <furq> also if you have a noisy source or a low-quality feed then you're going to have a real hard time with this in general
[01:51:29 CET] <therage3> yeah, the compression artifacts are bound to throw off the filters
[02:22:58 CET] <bilb_ono> Ideally I could get some number for each new frame showing how much it differs from the previous frame
[02:23:24 CET] <bilb_ono> then I could choose like less than 10 and its basically static
[02:23:24 CET] <bilb_ono> some threshold
[02:30:38 CET] <SortaCore> my current motion detection is homebrew
[02:31:10 CET] <SortaCore> I just convert a frame to greyscale, and do a "difference exceeds number" for all pixels, then check if num diff is above another number
[02:39:08 CET] <bilb_ono> SortaCore: hmm that seems pretty good
[03:51:31 CET] <SortaCore> is there a way to initialise a AVFrame from a AVStream?
[03:52:23 CET] <SortaCore> I'm having to set width, height, pixel format, color range, color primaries...
[04:57:04 CET] <kriskropd> hi - you know how Audacity has a "Change Tempo" effect where you set the current bpm and tell it which bpm you want it to change into?
[04:57:15 CET] <kriskropd> can ffmpeg do something like that with the same sort of input?
[04:57:40 CET] <kriskropd> or some other scriptable tool like sox even?
[04:58:21 CET] <kriskropd> premise: tons of music loops and samples I want to change the tempo of, but too lazy to open each in audacity individually and then export with a new name manually
[04:58:55 CET] <kriskropd> and though each has the bpm in their filename, they are not all the same, so I can't just pitch up by .1 and call it a day
[05:00:41 CET] <kriskropd> ah - maybe ill just use a chain in audacity to batch process and hand pick files afterall :/
[05:01:02 CET] <kriskropd> was looking forward to an excuse to use some bash parameters - but alas the wheels need not be reinvented I guess
[06:12:47 CET] <SortaCore> kriskropd: isn't tempo just sample rate?
[06:34:23 CET] <WireCat> sortacore did you figure out how to tell if its a video stream?
[06:34:37 CET] <SortaCore> yea, you use codec->type
[06:34:58 CET] <WireCat> thankyou :-)
[10:25:36 CET] <Zucca> Hi. I've been using the zlib video codec for quite a many things in the past. It's very fast and scales well on many CPU cores. It's especially good raw compressor on some game videos. Not that facebook has developed zstd, _could_ it be used to create similar video codec with even less overhead and better compression?
[10:26:41 CET] <JEEB> there are already nice well compressing video formats that are quite optimized
[10:26:48 CET] <JEEB> like libx264's lossless mode
[10:27:07 CET] <JEEB> ffv1 is being standardized with the EU for archival
[10:27:31 CET] <Zucca> JEEB: But in my experience that way slower. Only utvideo is somewhat comparable to the zlib video codec.
[10:27:36 CET] <JEEB> and less on the compression rate of things, but Ut Video is great for when you need to open the file in a video editor because there's modules for all OSs
[10:27:43 CET] <JEEB> Zucca: did you actually set preset?
[10:27:56 CET] <JEEB> of course zlib and ut video are very very simple
[10:28:20 CET] <JEEB> so they (well optimized) probably are faster, but libx264 is /very/ well optimized
[10:28:36 CET] <JEEB> it is of course more complex than zlib/ut video :P
[10:28:46 CET] <JEEB> but that's the usual thing
[10:29:16 CET] <JEEB> if you end up wanting something more complex you will pay with processing (although if you have optimizations then even a less complex format can end up slower)
[10:31:04 CET] <Zucca> If my GPU had hw encoding of h.264... The it might be feasible. But most of the time h.264 is too slow. Also when compressing retro game videos, zlib beats every other codec. :P I've been quite impressed how well it fares against ffv1 for example.
[10:31:46 CET] <furq> what about qtrle
[10:31:55 CET] <Zucca> Anyway. I'm not currently searching for another codec. Although I'll give libx264 a second try at lossless.
[10:31:58 CET] <JEEB> what sort of machine is this and did you poke the presets?
[10:32:34 CET] <Zucca> I just wonder if zstd could be used to create better zlib -like codec.
[10:33:22 CET] <Zucca> JEEB: Last time I tried... it was propably more than year ago. I cannot recall what settings I did try.
[10:33:49 CET] <JEEB> in theory yes but I wouldn't be surprised that if you *just* wanted to compress there are better algos for that which are not compatible with zlib :P
[10:34:21 CET] <JEEB> the web people are staying in zlib-compatible realm because they need to support browsers for the data decompression
[10:34:50 CET] <Zucca> I see.
[10:36:45 CET] <JEEB> and most of all, there are actually better video compression techniques than "just feed it to compressor X after giving it some basic 'prediction'"
[10:37:19 CET] <JEEB> and given that we're at the point where you get >10fps from x264's preset placebo on some machines... :D
[10:37:37 CET] <Zucca> I'll try out the lossless mode of libx264 next time when I'm in process of making video dumps.
[10:37:54 CET] <Zucca> What? >10 fps on placebo?
[10:37:58 CET] <JEEB> yes
[10:38:04 CET] <Zucca> At what resolution and fps?
[10:38:11 CET] <Zucca> Oh. Forget fps.
[10:38:12 CET] <JEEB> the fps doesn't matter does it :)
[10:38:16 CET] <JEEB> 1080p I think
[10:38:18 CET] <JEEB> 4:2:0 YCbCr
[10:38:31 CET] <Zucca> Damn... CPU only?
[10:38:35 CET] <JEEB> as someone who was using x264 in 2006 those numbers make me smile
[10:38:51 CET] <JEEB> yes, of course
[10:39:13 CET] <JEEB> the opencl stuff in x264 is very limited anyways (it has to be since it has to be able to run completely separate from the main encoding part)
[10:39:39 CET] <Zucca> Ah. Yeah. O mixed x264 with vpx.
[10:39:45 CET] <Zucca> *I
[10:39:57 CET] <JEEB> vpx got much less love poured into it
[10:40:05 CET] <JEEB> it was GOOG's toy
[10:40:32 CET] <Zucca> Newer GPUs support hw encoding of VP9.
[10:40:48 CET] <JEEB> maybe, but that's ASIC-based
[10:40:54 CET] <JEEB> all video encoding on those boards is ASIC based
[10:40:56 CET] <Zucca> Yup.
[10:40:56 CET] <JEEB> not GPGPU
[10:41:28 CET] <JEEB> also x264 and vpx are specifically the SW implementations of AVC/H.264 and VPx formats
[10:41:32 CET] <Zucca> I believe there's not much of room in adjustments.
[10:41:33 CET] <JEEB> so those ASICs are unrelated
[10:41:39 CET] <furq> huh
[10:41:42 CET] <furq> is there really no mng decoder
[10:41:56 CET] <JEEB> possibly, no idea
[10:42:04 CET] <furq> it just decodes the first frame
[10:42:15 CET] <JEEB> which was PNG-compatible, right?
[10:42:19 CET] <furq> yeah
[10:42:39 CET] <Zucca> JEEB: Does ffmpeg currently support GPU asic encoding (of any sort)?
[10:42:44 CET] <JEEB> yea you only have apng and png_pipe
[10:42:46 CET] <JEEB> Zucca: yes
[10:42:47 CET] <furq> i figured i would test zlib with "retro game video" and mame spits out mng
[10:43:01 CET] <furq> i guess i have to convert it to apng or something
[10:43:04 CET] <furq> or i could just not bother
[10:43:37 CET] <JEEB> Zucca: I think only nvidia that I know of currently supports lossless video with their ASICs
[10:43:45 CET] <JEEB> for encoding
[10:43:58 CET] <JEEB> otherwise it's all lossy
[10:44:04 CET] <Zucca> furq: Mame can output raw video. I'm not sure if you could just fifo it into ffmpeg and compress with zlib....
[10:44:39 CET] <furq> yeah but i already have some mngs
[10:47:10 CET] <Zucca> JEEB: Lossless would be nice, but I wouldn't mind about some higher quality lossy either. Although x264 with some fast preset is quite fast anyways.
[10:51:21 CET] <JEEB> yea, the ASICs are generally meant for realtime or so anyways
[10:53:04 CET] <furq> x264 4:4:4 at medium is twice as fast and a third the size of zlib
[10:53:18 CET] <furq> maybe x264 is just well optimised for real bout 2
[11:11:46 CET] <Nacht> There isn't a way to let ffmpeg make folders, right ?
[11:12:46 CET] <JEEB> some muxers have that, but in general the API client should handle stuff like that
[11:13:09 CET] <JEEB> and the stuff that has that is usually stuff like HLS which is a meta-muxer anyways :P
[11:14:08 CET] <Nacht> Hmm. Segment doesn't seem to have it :/
[11:14:25 CET] <JEEB> not surprising
[11:16:08 CET] <termos> I have a loop over all my filter graphs (10-15) where I call av_buffersrc_add_frame_flags for each 1080P decoded frame. The problem is that this causes a bottleneck in my software as too much time is spent copying out that frame into each filter graph. Is there a way around this?
[11:17:32 CET] <termos> something I can do with the AV_BUFFERSRC_FLAG_KEEP_REF flag?
[11:17:35 CET] <JEEB> in theory with refcounted frames the source frame could be passed the same, but then of course the filter wouldn't be able to do in-place filtering
[11:17:48 CET] <JEEB> unfortunately I haven't looked into lavfi enough
[11:21:42 CET] <termos> ah I see
[11:22:14 CET] <termos> only way out I see now it do a proxy transcoding (maybe just scaling) into lower resolutions and push this to the lower resolution filter graphs
[14:56:34 CET] <rodrigo-vitulli> Hi,
[14:56:35 CET] <rodrigo-vitulli> I'm using ffmpeg to create 1 minutes mp4 segments, but the problem is I can never assure the segment lenght. Sometimes it has 1 minute + 2 seconds, sometimes 56 seconds. I understand that this may be releated to how ffmpeg use keyframes to properly create segments, but this is causing me timestamp disarrange inside my application. My question is: is it possible to force ffmpeg to stick to exactly 1 minute segments? I'm using the folliwng
[14:56:35 CET] <rodrigo-vitulli> command:  ffmpeg -i #playlist_url# -force_key_frames 60 -vf scale=1280:720 -b:v 1000 -b:a 128 -f segment  -segment_time 60 -segment_atclocktime 1 -reset_timestamps 1 -strftime 1 %Y-%m-%dT%H:%M:00%z.mp4
[14:56:35 CET] <rodrigo-vitulli> Thanks
[16:10:41 CET] <alexp> rodrigo-vituli: i'm not sure if this wil help, but perhaps try -g 60 as well
[16:11:39 CET] <d9867eb> hi
[16:13:35 CET] <d9867eb> i have some video files and I want to store them in a open free format such as theora. however theora is the outdated. what is the best codec for me?
[16:13:48 CET] <Fyr> VP9?
[16:16:02 CET] <d9867eb> how is the vp9 license? is it permissive?
[16:16:18 CET] <d9867eb> Fyr:
[16:16:34 CET] <JEEB> software licenses and patent stuff are two completely separate things
[16:17:06 CET] <JEEB> you can have something very permissive in software licenses yet (depending on your legal location etc) you can be fscked with the patent situation on it
[16:17:16 CET] <Fyr> >> Parts of the format are covered by patents held by Google. The company grants free usage of its own related patents based on reciprocity, i.e. as long as the user does not engage in patent litigations.
[16:17:44 CET] <alexpigment> Fyr: what about the other parts? ;)
[16:17:51 CET] <JEEB> yes, they also have a patent grant for their stuff in there of course by GOOG
[16:18:03 CET] <JEEB> but what you'd care about are non-GOOG things anyways. if you care about it
[16:18:15 CET] <JEEB> IANAL but please just *always* remember to keep these two issues separate
[16:18:19 CET] <alexpigment> basically any number of entities can come in and say the codec violates patents (and they usually will try at some point)
[16:18:44 CET] <JEEB> software licensing is one thing, the mess that is software patents and if it touches *you* is a separate and more messy thing
[16:19:05 CET] <alexpigment> you can at least rest safely that google has infinite cash and will probably step in and pay off whoever tries to litigate on their patents
[16:19:11 CET] <alexpigment> semi-safely at least
[16:19:45 CET] <JEEB> well if you cared about sw patents you wouldn't be caring about the GOOG patents
[16:20:00 CET] <JEEB> the things that other places have which are not using libvpx or related things
[16:20:13 CET] <alexpigment> that's true
[16:20:17 CET] <JEEB> anyways, libvpx is a relatively permissively licensed thing (you can read it license in their repo and FAQs most likely)
[16:20:34 CET] <JEEB> and it seems like most places see libvpx as OK to distribute
[16:20:37 CET] <JEEB> IANAL though
[16:20:52 CET] <alexpigment> but JEEB, aren't you actually a lawyer though?
[16:20:57 CET] <alexpigment> :)
[16:20:58 CET] <JEEB> fuck no
[16:21:04 CET] <d9867eb> so should i libvpx instead of libtheora? how about vc2
[16:21:06 CET] <JEEB> I don't make enough money to be one
[16:21:06 CET] <alexpigment> JEEB is a closet lawyer
[16:21:07 CET] <d9867eb> ?
[16:21:13 CET] <alexpigment> he's a shill for Big Patent
[16:21:40 CET] <JEEB> no, all I'm saying is that whether or not you care about sw patents is unrelated to software licensing
[16:21:43 CET] <alexpigment> d9867eb: if you have to choose bewteen vp9 and theora, go with vp9
[16:22:06 CET] <JEEB> and that I am not a lawyer who is recommend something to someone
[16:22:07 CET] <alexpigment> <-- also not a lawyer
[16:22:30 CET] <JEEB> all I can say that entities that tend to be really careful with sw patents distribute libvpx (mozilla, red hat)
[16:23:13 CET] <alexpigment> yeah, mozilla has had to also pay out the ass before, which is hard since they don't have millions of other revenue streams
[16:23:16 CET] <JEEB> so the de facto thing seems to be that it is perceived as "safe to use", while there of course is no way to really be assured of that unless you do comprehensive IPR
[16:23:26 CET] <alexpigment> which is why they dropped native H.264 support
[16:23:27 CET] <d9867eb> alexpigment: i had just like a open format. if there are only vp9, vc2 and theora then i have go with someone of them
[16:23:37 CET] <JEEB> VC-2 is not for your use case anyways
[16:23:48 CET] <alexpigment> d9867eb: vp9
[16:23:55 CET] <JEEB> it's a high bit rate thing utilized instead of raw video over networks
[16:24:08 CET] <alexpigment> (assuming you are re-encoding existing files, which I don't really recommend in the first place)
[16:24:09 CET] <JEEB> for stuff like broadcast thingamajigs
[16:24:22 CET] <JEEB> (internal video transfer etc)
[16:24:34 CET] <d9867eb> ok
[16:24:35 CET] <JEEB> although I've only seen BBC and open broadcast systems use it
[16:25:43 CET] <d9867eb> also, let say i have ac3 audio in the source file. should i use flac or libopus in the output file?
[16:26:00 CET] <alexpigment> opus probably, unless you want completely lossless
[16:26:10 CET] <JEEB> why would you not just copy the audio over?
[16:26:13 CET] <alexpigment> or again, just keep the ac3
[16:26:14 CET] <JEEB> it's already lossy
[16:26:22 CET] <d9867eb> ok
[16:26:26 CET] <JEEB> or what's the thing?
[16:26:38 CET] <alexpigment> ac3 patents have run out anyway, if that matters to you
[16:26:46 CET] <JEEB> yea, that's true
[16:26:58 CET] <JEEB> which is why two or so years ago Dolby made up AC-4
[16:27:01 CET] <JEEB> for more patent moneys
[16:27:03 CET] <alexpigment> :)
[16:27:12 CET] <alexpigment> yeah, dolby lives off of licensing
[16:27:16 CET] <alexpigment> they gotta keep doing something
[16:27:38 CET] <alexpigment> i wonder if they paid adobe to drop AC3 from creative cloud
[16:28:05 CET] <alexpigment> there's something to that story - i don't know why adobe would drop ac3 this year - after the patents ran out
[16:28:09 CET] <JEEB> and they're not DTS. DTS will basically yell at you over the phone if you ask about specs for putting DTS into, say, MP4
[16:28:45 CET] <JEEB> not even decoding it, lol
[16:28:52 CET] <d9867eb> isnt the ac3 codec closed source?
[16:29:03 CET] <alexpigment> yes
[16:29:05 CET] <JEEB> it's a standard (A/52)
[16:29:08 CET] <alexpigment> but open source encoders exist
[16:29:12 CET] <alexpigment> and patents have run out
[16:29:27 CET] <JEEB> yes, you have both open source decoders and encoders, and as far as I know the spec is open
[16:29:37 CET] <alexpigment> i'll trust JEEB
[16:29:37 CET] <d9867eb> i had like only open codecs for my videos
[16:29:44 CET] <JEEB> so it's not proprietary
[16:29:58 CET] <JEEB> https://www.atsc.org/standard/a522012-digital-audio-compression-ac-3-e-ac-3-standard-12172012/
[16:30:48 CET] <JEEB> d9867eb: I think you're rather confused about things :P
[16:30:49 CET] <alexpigment> d9867eb: out of curiosity, are you trying to take lossy videos (e.g. MP4 and MKV files) and transcode them to something open source, just because you prefer open source?
[16:31:13 CET] <d9867eb> alexpigmet: yes!
[16:31:17 CET] <JEEB> if something is standard, as in with a proper specification, that most likely has an open source decoder or encoder
[16:31:18 CET] <alexpigment> d9867eb: don't do it
[16:31:23 CET] <d9867eb> why?
[16:31:31 CET] <alexpigment> because it's a waste of time, and you're going to lose quality
[16:31:37 CET] <JEEB> then *separately* you have the "patent free" (in quotes) stuff
[16:31:45 CET] <JEEB> which is what you care about?
[16:31:55 CET] <JEEB> is it just having *standardized* stuff
[16:32:05 CET] <JEEB> or is it "patent free" (in quotes)?
[16:33:30 CET] <JEEB> if it's just "has to have open source decoder/encoder", then that's of course even more wide :P but generally I would limit stuff with an actual specification
[16:34:28 CET] <d9867eb> i care about the license of the original decoder/encoder
[16:34:44 CET] <alexpigment> d9867eb: well if you care more about that than your time and quality, go ahead
[16:34:49 CET] <JEEB> "original" doesn't really make sense
[16:35:05 CET] <JEEB> for example you have the AVC/H.264 or HEVC/H.265 formats.
[16:35:09 CET] <JEEB> they do have reference implementations
[16:35:15 CET] <JEEB> is that the "original" you care about?
[16:35:39 CET] <JEEB> (note: absolutely no-one uses the reference ones because they're just that - references)
[16:36:22 CET] <JEEB> and what do you care what something is encoded with as long as it's according to a specification and thus you can decode it with open source means? and if we speak about open standardized formats you most likely have an open source encoder for that format, too
[16:36:31 CET] <JEEB> but anyways, you have much tighter control on what you *encode*
[16:36:46 CET] <alexpigment> d9867eb: what JEEB is trying to get at, for example, is that H.264 has an open source encoder (x264), but it is subject to payments on the patents (to MPEG-LA)
[16:37:04 CET] <JEEB> alexpigment: even before that darn it. the question I posed was relatively simple
[16:37:25 CET] <alexpigment> sorry, I was trying to break it down from the abstract to the specific
[16:38:14 CET] <alexpigment> anyway, I really just don't see the point in all this. people don't care enough about quality to not re-encode an already lossy source. I feel like I'm so ideologically opposed to this that I'll just be quiet :)
[16:38:18 CET] <d9867eb> alexpigment: the libx264 encoder is not offical encoder iirc
[16:38:28 CET] <alexpigment> there is no official encoder
[16:38:28 CET] <JEEB> there is no "official" encoder for AVC/H.264
[16:38:31 CET] <JEEB> other than the reference
[16:38:36 CET] <JEEB> they make a reference and the specification
[16:39:22 CET] <JEEB> but sure, AVC/H.264 reference software is open source and available here http://iphome.hhi.de/suehring/tml/
[16:39:53 CET] <JEEB> specification is freely available @ http://www.itu.int/rec/T-REC-H.264-201704-I/en
[16:40:15 CET] <JEEB> that's why I note that what you should be caring is if something is a standardized format or not
[16:40:34 CET] <JEEB> things with specifications etc tend to have open source decoders which will continue to work
[16:40:46 CET] <JEEB> and most likely an encoder, too
[16:41:46 CET] <alexpigment> if i had to pick a format that I thought would be most likely still playable in 30 years, it would be H.264
[16:43:21 CET] <JEEB> d9867eb: so yea, go re-read my lines starting from the line that begins "if something is standard, as in with a proper specification" (like the following less than 10 lines from me)
[16:43:31 CET] <JEEB> then think what do you care about
[16:44:42 CET] <JEEB> there are people with beliefs who do not want anything that is considered "patent encumbered" (with a reason or not), and those end up with theora or libvpx for example. and then those that just care that things are standardized and with an open source implementation (thus most likely to work in the future, too)
[16:45:24 CET] <JEEB> the first part wouldn't take AVC/H.264 even with GPL (x264) or MIT/BSD (openh264)
[16:45:57 CET] <d9867eb> JEEB: i think I am going to keep my video files in x264 for a while
[16:46:36 CET] <JEEB> the format's called either AVC or H.264
[16:46:39 CET] <JEEB> x264 is an encoder
[16:46:46 CET] <d9867eb> i might migrate to libvpx + libopus in the future
[16:46:49 CET] <d9867eb> ok
[16:46:57 CET] <d9867eb> thank you
[16:48:13 CET] <JEEB> heh, these confused types are not simple to have things explained
[16:48:47 CET] <alexpigment> i knew from the get-go that he was just going to try to re-encode x264
[16:48:50 CET] <alexpigment> sorry
[16:48:53 CET] <alexpigment> "x264" :)
[16:49:08 CET] <JEEB> I was pretty sure he just had something with H.264 or MPEG-2 Video with AC3
[16:49:11 CET] <JEEB> yes
[16:49:30 CET] <JEEB> thus I was trying to make him understand what he really wants or does he want anything?
[16:49:56 CET] <alexpigment> now, granted: if he had MPEG-2 video from DVD and wanted to transcode, fine. some people just really get on the open source bandwagon and just take it too far
[16:50:33 CET] <JEEB> I don't think this has much to do with open source but rather a misunderstanding of what the people with beliefs are requiring
[16:50:38 CET] <Fyr> JEEB, I couldn't find comparison of libx264 and openh264. which one is better?
[16:50:45 CET] <alexpigment> libx264 is usable
[16:50:47 CET] <JEEB> openh264 is limited to baseline profile
[16:50:59 CET] <JEEB> and it may be faster with ARM
[16:51:00 CET] <Fyr> ok, thanks, it's enough.
[16:51:15 CET] <storrgie> I'm trying to use ffmpeg to record audio from two interfaces on a windows machine. I'd like to mux this together into a single file that I can pull channels out of later... correct me if I'm wrong in thinking I can take two stereo inputs and mux them into a file with four channels?
[16:51:15 CET] <JEEB> also you can dodge the license stuff by using a binary from cisco
[16:51:19 CET] <JEEB> which is what Firefox does
[16:51:35 CET] <storrgie> I'm capturing the mic like this: ffmpeg -f dshow -i audio="Microphone (Realtek Audio)" mic.wav, and the "stereo upmix" which is what they here, like this: ffmpeg -f dshow -i audio="Stereo Mix (Realtek Audio)" upmix.wav
[16:51:38 CET] <JEEB> storrgie: you can just use an audio filter chain that remaps teh audio stuff
[16:51:45 CET] <alexpigment> i thought firefox just gave up entirely and used the H.264 decoder that's included with the system
[16:51:57 CET] <alexpigment> i didn't think they encoded anything
[16:52:20 CET] <JEEB> alexpigment: they never had a proper integrated H.264 decoder. so your comment about "paying up" was weird. They added openh264 for the webrtc spec compliance, which they download from cisco
[16:52:34 CET] <JEEB> also they have support for using MediaFoundation, gstreamer and FFmpeg
[16:52:40 CET] <JEEB> for AVC/AAC decoding
[16:53:03 CET] <JEEB> so basically if you have libavcodec.so available Firefox on lunix can use that
[16:53:04 CET] <alexpigment> JEEB: so MPEG-LA had a license fee that had a cap of ~$5mil I believe
[16:53:11 CET] <alexpigment> and all the browsers paid it
[16:53:15 CET] <JEEB> 5 or 10 now, don't remember. and no.
[16:53:19 CET] <alexpigment> but firefox couldn't swing it at some point
[16:53:33 CET] <JEEB> I don't think Mozilla ever distributed a H.264 decoder
[16:53:34 CET] <alexpigment> maybe I heard the details wrong...
[16:53:56 CET] <JEEB> they "gave up" about it circa 2013 or so? and then implemented Media Foundation, gstreamer
[16:54:05 CET] <JEEB> then in 2014 or 2015 they also implemented a libavcodec wrapper
[16:54:24 CET] <rodrigo-vitulli> vituli
[16:54:35 CET] Last message repeated 1 time(s).
[16:54:35 CET] <JEEB> for WebRTC compliance they added openh264 which is used for the video conference stuff
[16:54:47 CET] <JEEB> and openh264 is grabbed from cisco, as I noted
[16:55:03 CET] <JEEB> since cisco is providing the binaries, and MPEG-LA only cares about binary distribution
[16:55:18 CET] <rodrigo-vitulli> alexp: thanks! I've already tried that...
[16:55:21 CET] <JEEB> (and cisco just like google has run into the distribution limit ages ago)
[16:55:58 CET] <alexpigment> JEEB: k. I probably just misheard the details. thanks for the info
[16:57:01 CET] <JEEB> it sounds like you misunderstood the openh264 thing where they're using cisco-provided binaries
[16:57:18 CET] <JEEB> because cisco doesn't care as they already pay the maximum :D
[16:58:05 CET] <alexpigment> i didn't know they did that. i knew cisco did openh264 and basically all the fees are paid by them. i just didn't know firefox used that for any reason
[16:59:12 CET] <JEEB> yea, WebRTC specifies H.264 for video IIRC
[16:59:14 CET] <JEEB> which is why it's used
[17:01:15 CET] <Johnjay> see xkcd comic about specifications
[17:01:41 CET] <storrgie> JEEB, sorry I'm getting a bit lost in all the audio filter documentation... would I want to just do a channelmap?
[17:02:16 CET] <alexpigment> Johnjay: that's a good one :)
[17:03:35 CET] <storrgie> JEEB, actually it looks like I'd want to do a channelsplit
[17:03:53 CET] <JEEB> storrgie: you first need amerge I think https://trac.ffmpeg.org/wiki/AudioChannelManipulation
[17:04:31 CET] <JEEB> since you have more than one input from which you want to create a single thing that then gets remapped
[17:05:16 CET] <JEEB> just take a look at the examples on that page that have multiple inputs
[17:06:45 CET] <storrgie> thanks!
[17:07:09 CET] <alexpigment> are there audio formats that have multiple streams?
[17:07:26 CET] <alexpigment> or do you have to use a container like MKV for that?
[17:07:40 CET] <JEEB> yes, just use a proper container if you need multiple streams
[17:08:03 CET] <alexpigment> it sounds like the best option is to have a 3 streams, 1 that is downmixed from the two streams, as well as the two original streams
[17:08:30 CET] <alexpigment> rather than a "quad channel" stream that probably won't get downmixed properly on most players
[17:08:45 CET] <JEEB> well I have no idea if he has 4.0 input or what
[17:08:50 CET] <JEEB> he asked for 4.0 though
[17:08:56 CET] <JEEB> and mapping the original tracks is simple anyways
[17:09:06 CET] <JEEB> -map 0:a -map 1:a
[17:09:09 CET] <alexpigment> sure, i'm just talking about playback
[17:09:31 CET] <JEEB> well yea, it depends. something like mpv can handle 4.0 if it's proper 4.0. and if he actually needs mixing he can do that in the filter chain
[17:09:37 CET] <JEEB> so far he asked for four channels
[17:09:41 CET] <alexpigment> anyway, just figured i'd throw that option out there, because player downmixing from 4.0 to 2.0 or 5.1 is going to be a crapshoot
[17:10:00 CET] <alexpigment> right, just trying to read between the lines over here
[17:10:21 CET] <alexpigment> anyway storrgie: that's something to consider if the 4.0 thing doesn't work too well
[17:10:36 CET] <JEEB> or he just wants a single WAV file for his audio editor
[17:10:42 CET] <JEEB> instead of two
[17:10:45 CET] <alexpigment> true
[17:10:52 CET] <JEEB> so he doesn't actually just care about the actual layout of the channels
[17:10:56 CET] <JEEB> E_NO_IDEA
[17:10:56 CET] <storrgie> I guess I could just have separate files
[17:11:02 CET] <storrgie> I really just wanted to ensure time alignment
[17:11:12 CET] <JEEB> just use the filter chain then
[17:11:48 CET] <alexpigment> if time alignment is the main concern here, then yeah, a 4.0 channel file is fine if your editor supports it
[17:12:01 CET] <storrgie> I'd actually be using ffmpeg to split it later
[17:12:10 CET] <alexpigment> yeah, completely fine then
[17:12:10 CET] <storrgie> I just want to capture it all aligned
[17:12:43 CET] <storrgie> so really I'm just wanting a four channel file to store as an archive, then if someone says "can you examine around this time" I can corroborate what was being said/heard
[17:12:56 CET] <storrgie> its literally recording people playing a videogame, but we want to know the things they say based on stimulus
[17:13:12 CET] <storrgie> trying to elicit their vocabulary in duress situations
[17:13:14 CET] <alexpigment> sure
[17:13:53 CET] <alexpigment> i just wanted to make sure you weren't trying to actively listen to 4.0 audio, but wanted the original streams just in case
[17:14:02 CET] <storrgie> yeah
[17:14:09 CET] <storrgie> so should I use something like mkv as my container?
[17:14:11 CET] <alexpigment> because 4.0 audio has to be downmixed for 2.0
[17:14:21 CET] <storrgie> and just store two stereo tracks inside it?
[17:14:51 CET] <alexpigment> try the 4.0 thing first
[17:15:13 CET] <storrgie> I don't have a machine to try it on right now, I'm going to have to test this next monday. I was just updating my notes about it
[17:15:14 CET] <alexpigment> if it *sounds bad* when playing it, then you can consider storing a file with 3 streams
[17:15:28 CET] <storrgie> I think it would actually be better to store a file with multiple streams
[17:15:34 CET] <storrgie> for simplicity sake
[17:15:46 CET] <storrgie> because then someone could reasonably open up, say, vlc, and select the stream they wanted
[17:15:55 CET] <storrgie> without bothering me to split into wav/mp3 immediately
[17:16:02 CET] <alexpigment> storrgie: would they ever want to select both streams simultaneously?
[17:16:07 CET] <alexpigment> or is it one or the other?
[17:16:26 CET] <storrgie> I highly doubt it
[17:16:36 CET] <storrgie> however, if they did want to... then what do you suggest
[17:16:37 CET] <alexpigment> ok, then a two-stream MKV file would be fine
[17:16:57 CET] <alexpigment> then i'd suggest doing another audio track (the primary presumably) that is a downmix of the two streams
[17:17:24 CET] <storrgie> I guess, because I'm going to be doing this like 30-60 * 8 hours a day * 5 days... I should probaly store it in the "best" archival format
[17:17:35 CET] <alexpigment> so the streams would be 1) A+B, 2) A, 3) B
[17:17:41 CET] <storrgie> yeah that makes sense
[17:17:51 CET] <storrgie> so have a downmix of A+B, then A and B separately
[17:17:56 CET] <alexpigment> right
[17:18:00 CET] <alexpigment> that would be my suggestion
[17:18:01 CET] <storrgie> all in an mkv, so they could select
[17:18:05 CET] <alexpigment> right
[17:18:20 CET] <storrgie> soo... I have this page (https://trac.ffmpeg.org/wiki/AudioChannelManipulation) to get my started, is that still the right place to begin?
[17:18:41 CET] <alexpigment> yes
[17:19:16 CET] <alexpigment> see the 2 x stereo > stereo section for the mixdown
[17:21:03 CET] <storrgie> so, I'd start like this then: ffmpeg -f dshow -i audio="Microphone (Realtek Audio)" -f dshow -i audio="Stereo Mix (Realtek Audio)" -filter_complex "[0:a][1:a]amerge=inputs=2[aout]" -map "[aout]" -ac 2 output.mkv
[17:21:25 CET] <storrgie> however that is only giving the A+B track to the mkv right now, so I also need to do A and B respectively?
[17:22:04 CET] <alexpigment> yeah i think you just also add -map 0:a -map 1:a after -ac 2
[17:22:35 CET] <storrgie> thanks a ton
[17:22:40 CET] <storrgie> I'll attempt this on Monday!
[17:23:26 CET] <alexpigment> good luck
[17:23:37 CET] <storrgie> and this is not going to do any on the fly compression right?
[17:23:39 CET] <alexpigment> i'll do a test over here real quick to make sure there isn't some caveat about that setup
[17:23:40 CET] <storrgie> which, is ok with me
[17:24:12 CET] <alexpigment> well, if it's all in PCM, it's not going to be compressed
[17:24:20 CET] <storrgie> right, it is
[17:24:25 CET] <storrgie> because coming off sound interfaces
[17:24:26 CET] <alexpigment> but I guess you need to specify that
[17:24:33 CET] <storrgie> I dont think I _want_ to compress it
[17:24:40 CET] <storrgie> I could always do that later right, via re-encoding it?
[17:24:43 CET] <alexpigment> right
[17:24:51 CET] <storrgie> I'd rather spare the CPU cycles at capture time for the actual game
[17:24:59 CET] <storrgie> its quite intense on the machine, and they are on Alienware R5 laptops
[17:25:04 CET] <storrgie> laptop CPU is not the best
[17:25:11 CET] <alexpigment> but keep in mind that with 44.1/16bit you're going to be doing 10MB every minute
[17:25:14 CET] <alexpigment> x3
[17:25:18 CET] <alexpigment> so 30MB/min
[17:25:26 CET] <storrgie> I have a 1T hard drive in each for capture
[17:25:27 CET] <alexpigment> probably fine, but just saying
[17:25:37 CET] <storrgie> they have an SSD for the OS/game, but a 1T conventional drive for capture
[17:29:07 CET] <alexpigment> i'm doing some tests right now
[17:29:20 CET] <storrgie> I've gotta run, but I'm on here with my bouncer so I'll see it!
[17:29:21 CET] <alexpigment> the filterchain and the copy are kinda mutually exclusive it hink
[17:29:23 CET] <storrgie> thanks for looking at it
[17:32:15 CET] <alexpigment> storrgie: i PM'd you the command, so as not to spam in here
[17:47:09 CET] <d9867eb> hi again
[17:47:31 CET] <d9867eb> I hava a new question
[17:49:31 CET] <d9867eb> If I have a 720p or 1080p video and want to convert to 480p, then what is the correct scale filter? would scale=16:9 do fine?
[17:50:05 CET] <JEEB> -vf "scale=-2:480"
[17:50:16 CET] <JEEB> -2 is (according to aspect ratio, but divisible by 2)
[17:50:21 CET] <JEEB> which is what you need for 4:2:0
[17:50:51 CET] <d9867eb> ok thanks jeeb
[19:50:27 CET] <SortaCore> JEEB: Any built-in way to set up properties of an AVFrame to receive from a AVStream?
[19:50:34 CET] <SortaCore> I'm having to set width, height, pixel format, color range, color primaries...
[20:17:07 CET] <BtbN> you mean AVPacket?
[20:22:57 CET] <JEEB> SortaCore: the decoder should set the values to the AVFrame, no?
[20:33:46 CET] <SortaCore> avcodec_receive_frame() requires a frame, so I have to pre-initialise it to match the stream
[20:33:59 CET] <JEEB> uhh, no?
[20:34:17 CET] <JEEB> the decoder fills the fields in the AVFrame
[20:34:34 CET] <JEEB> you just give it an AVFrame allocated and usable
[20:35:17 CET] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html and https://www.ffmpeg.org/doxygen/trunk/group__lavc__decoding.html#ga11e6542c4e66d3028668788a1a74217c are related
[20:36:11 CET] <SortaCore> right now I'm doing av_frame_alloc, av_image_alloc, setting the format and types
[20:36:46 CET] <SortaCore> I am using sws_scale if that is a factor
[20:37:02 CET] <JEEB> you don't have to allocate anything else than the AVFrame
[20:37:26 CET] <JEEB> the decoder has already generated the buffer which it will stick to the AVFrame's pointer
[20:38:04 CET] <JEEB> also I recommend you use the scale and format filters in lavfi instead of swscale itself since the interface is much clearer that way
[20:38:14 CET] <JEEB> but if you're OK with swscale that's fine, too
[20:38:30 CET] <JEEB> avfilter just takes in AVFrames and returns you AVFrames
[20:38:49 CET] <JEEB> so you never have to leave the AVFrame abstraction layer
[20:39:14 CET] <SortaCore> I'm using it for format converts
[20:39:17 CET] <JEEB> yes
[20:39:28 CET] <SortaCore> yuv to nv12, rgb, greyscale
[20:39:33 CET] <JEEB> you get the same with lavfi (it uses swscale in the background)
[20:39:43 CET] <JEEB> it's just simpler in the way that you never have to deal with something that isn't AVFrames on your side
[20:39:50 CET] <JEEB> but as I said, if you are OK with swscale and all, that's fine
[20:40:21 CET] <JEEB> alexpigment: mpv can use the GPU's filters through d3d11 it seems, but only when d3d11 hwdec is being used
[20:40:25 CET] <JEEB> https://mpv.io/manual/master/#video-filters-d3d11vpp
[20:41:06 CET] <SortaCore> yea, dunno how to use lavfi that way
[20:41:39 CET] <JEEB> see the docs/examples if you ever get interested
[20:41:53 CET] <alexpigment> JEEB: thanks for the heads up. i'll take a look into that today
[20:58:03 CET] <alexpigment> JEEB: under --hwdec= it lists d3d11va
[20:58:19 CET] <alexpigment> and mentions Windows 8+
[20:58:24 CET] <alexpigment> i'm on 7
[20:58:27 CET] <JEEB> ah
[20:58:32 CET] <JEEB> oh well
[20:58:33 CET] <alexpigment> actually, maybe they're just talkinga bout gpu-context=angle
[20:58:33 CET] <JEEB> :)
[20:58:42 CET] <alexpigment> sorry, still trying to figure this out
[21:01:22 CET] <JEEB> I'm using git master mpv anyways since I have to test PRs :D
[21:01:41 CET] <JEEB> which defaults to d3d11 rendering if you have the correct dependencies available
[21:01:57 CET] <JEEB> (OpenGL shaders compiled into HLSL)
[21:02:42 CET] <alexpigment> yeah, they don't really do a good job in the documentation of giving an example for this
[21:03:11 CET] <alexpigment> there's a generic filter chain example, but it's unclear if d3d11 itself needs to be specified, or if the sub options need to be specified
[21:04:27 CET] <JEEB> don't play with the VO, --hwdec=d3d11va --vf=d3d11vpp=deint=yes
[21:04:33 CET] <JEEB> I guess something like that?
[21:04:59 CET] <JEEB> the suboptions have defaults so if the default is OK you don't have to override
[21:06:59 CET] <JEEB> oh, if I enable the post-processing it downconverts to 8bit YCbCr (NV12) for me in case of P010 :<
[21:07:40 CET] <storrgie> alexpigment, sorry it seems znc didn'y pick up the pm :(
[21:08:26 CET] <alexpigment> i just re-sent, did you get it?
[21:08:44 CET] <JEEB> alexpigment: but yea, current git master on win10 seems to work. not 100% sure if anything else gets applied as well http://up-cat.net/p/fc331504
[21:09:04 CET] <alexpigment> ok, so i've got an mpv.conf file
[21:09:06 CET] <JEEB> at least the image received is NV12 from the post-processor
[21:09:15 CET] <alexpigment> which I had to create manually
[21:09:21 CET] <alexpigment> because it didn't exist (curiosity #1)
[21:09:33 CET] <alexpigment> and really all i put in it is this:
[21:09:42 CET] <alexpigment> --vo=gpu --gpu-context=d3d11 --hwdec=d3d11va --vf=d3d11vpp=deint=yes
[21:09:49 CET] <alexpigment> i tried it without the first two, but nothing happened
[21:10:06 CET] <alexpigment> i don't really know of a way to even verify that these parameters or the file in general is getting read
[21:10:19 CET] <JEEB> open cmd.exe?
[21:10:32 CET] <JEEB> or powershell if you prefer that
[21:10:41 CET] <alexpigment> yeah i've got cmd right here
[21:11:13 CET] <JEEB> then just don't call it mpv.exe but instead leave the extension out or specify mpv.com :P (because windows is stupid with standard output)
[21:11:15 CET] <alexpigment> is there no way to specify this via mpv.conf so it gets used all the time?
[21:11:26 CET] <JEEB> it is, but those all are without -- and on separate lines
[21:11:31 CET] <JEEB> and you wanted to check, no?
[21:11:42 CET] <alexpigment> well, let me try separate lines
[21:11:44 CET] <JEEB> easiest way to check is to run it in cli and check what it's using :P
[21:12:01 CET] <JEEB> removal of the -- might not be needed but that's what I'm using since it's not command line options
[21:12:35 CET] <alexpigment> mpv [what next]?
[21:12:39 CET] <alexpigment> to check what it's using
[21:12:49 CET] <JEEB> just drag and drop a video file then
[21:12:50 CET] <alexpigment> apologies. i'm really green on mpv
[21:12:55 CET] <JEEB> on the cmd.exe
[21:12:58 CET] <JEEB> and the path to it will get inserted
[21:13:11 CET] <JEEB> you can do tab-autocomplete as well, but I find it usually simpler
[21:13:30 CET] <alexpigment> ok, so i'm back to what I had before
[21:13:33 CET] <alexpigment> with separate lines
[21:13:41 CET] <alexpigment> and when i try to load mpv.exe, it never loads
[21:13:44 CET] <JEEB> also if you want it to write a verbose log into a text file there's --log-file=file.txt
[21:13:50 CET] <alexpigment> ok
[21:13:52 CET] <alexpigment> i'll try that
[21:15:17 CET] <alexpigment> Video output gpu not found!
[21:15:23 CET] <JEEB> ok, so yours is just old
[21:15:25 CET] <alexpigment> that's a quote - i'm not that excited
[21:15:35 CET] <JEEB> there's separate documentation for the latest "release"
[21:15:37 CET] <alexpigment> i downloaded a precompiled binary a few days ago
[21:15:41 CET] <alexpigment> k
[21:15:51 CET] <JEEB> lachs0r only builds releases, if you want mine I can put it up
[21:16:12 CET] <alexpigment> lemme check the other person's site first
[21:16:25 CET] <alexpigment> shinchiro
[21:18:19 CET] <JEEB> also the reason why mpv builds come with both mpv.exe (the actual player) and mpv.com (a wrapper for standard output/error logging) is because windows either lets you build an app that doesn't output anything to standard output/err (GUI), or an app that outputs to that, but will forcibly open a cmd.exe for you :D (CLI)
[21:18:34 CET] <JEEB> and because cmd.exe picks .com first, before .exe :P
[21:19:06 CET] <JEEB> (mpv.com launches mpv.exe in the background and redirects the debug output to the terminal)
[21:19:09 CET] <alexpigment> oh crap
[21:19:15 CET] <alexpigment> this new one had an installer.bat
[21:19:21 CET] <JEEB> no need to use it really
[21:19:26 CET] <alexpigment> and i didn't realize it creates file associations
[21:19:42 CET] <JEEB> yea, that's the only "installation" you'd require with mpv
[21:19:57 CET] <JEEB> I think it also comes with an uninstall thing although I am not sure if it can restore things back
[21:20:04 CET] <alexpigment> yeah, that's what i'm hoping ;)
[21:28:00 CET] <alexpigment> "Creating filter 'd3d11vpp' failed"
[21:28:02 CET] <alexpigment> that's in the log
[21:28:22 CET] <JEEB> did it succeed with d3d11va?
[21:28:25 CET] <alexpigment> after it mentions all the things were registered correctly (or seemingly correctly)
[21:29:01 CET] <alexpigment> Loading hwdec driver 'd3d11-egl'
[21:29:02 CET] <alexpigment> [   0.151][v][vo/gpu] Loading failed.
[21:29:02 CET] <alexpigment> [   0.151][v][vo/gpu] Loading hwdec driver 'd3d11-egl-rgb'
[21:29:02 CET] <alexpigment> [   0.151][v][vo/gpu] Loading failed.
[21:29:02 CET] <alexpigment> etc
[21:31:05 CET] <JEEB> a working case looks like this to me http://up-cat.net/p/bb3d14dd
[21:31:36 CET] <alexpigment> oh, so you have the same failure messages?
[21:31:53 CET] <JEEB> d3d11va works so it will use that one
[21:32:06 CET] <JEEB> the egl stuff is for opengl/angle compatibility I guess
[21:32:15 CET] <JEEB> since d3d11 can use d3d11 textures as-is
[21:32:26 CET] <JEEB> which the d3d11va decoder outputs
[21:34:33 CET] <JEEB> but yea, that has the rendering/decoding/video filter stuff
[21:34:38 CET] <JEEB> in a working case
[21:35:05 CET] <JEEB> HEVC works the same for me except it will downconvert to 8bit for the deinterlacing filter :(
[21:37:15 CET] <alexpigment> hmmm
[21:37:22 CET] <alexpigment> it's just failing on the video filter part
[21:37:26 CET] <alexpigment> I don't really know why
[21:37:35 CET] <alexpigment> maybe this *is* something that doesn't work on win7
[21:37:38 CET] <alexpigment> although i don't know why
[21:38:17 CET] <JEEB> so the decoder actually works if you disable the post-processor?
[21:38:43 CET] <JEEB> because I would expect d3d11va to also fail on win7 if the post-processor does - as that's a limitation I remember :P
[21:39:20 CET] <alexpigment> oh ok, so i guess it diverges where it says "could not create device"
[21:39:25 CET] <alexpigment> on mine
[21:40:00 CET] <alexpigment> there are some loading failures on yours, but then it says Trying hardware decoding via mpeg2video-d3d11va.
[21:40:12 CET] <JEEB> yea, it tries to initialize all of the ones built in I think
[21:40:29 CET] <JEEB> I recently merged a PR for some logic like that I think :P
[21:40:53 CET] <JEEB> https://github.com/mpv-player/mpv/commit/a4705e8b59a0c496852d67db591bb480e0146e5e
[21:40:57 CET] <JEEB> yup
[21:41:27 CET] <alexpigment> well, real life is calling for a few minutes. i'll have to try this later
[21:41:34 CET] <JEEB> alright
[21:41:38 CET] <alexpigment> rather, keep trying and stare at some logs ;)
[21:41:48 CET] <JEEB> you could just post the same range as I did if you want :P
[21:41:59 CET] <JEEB> also we could move this discussion to #mpv I guess
[21:59:32 CET] <TheRock23> hi, is it true that ffmpeg is the best player ?
[21:59:54 CET] <teratorn> TheRock23: no, who says that?
[22:00:10 CET] <JEEB> FFmpeg is not a player, but you'd be surprised how many players use FFmpeg behind the scenes
[22:00:14 CET] <JEEB> ;)
[22:00:52 CET] <TheRock23> i see, so its better than winodws player?
[22:04:47 CET] <dystoipa_> it's not a video player TheRock23
[22:06:22 CET] <SortaCore> VLC best player
[22:49:16 CET] <szefoski> Hello, I have an IP camera, I'm receiving I and P frames. When I do ffprobe on I frame I see such output:
[22:49:19 CET] <szefoski> Stream #0:0: Video: h264 (High), yuvj420p(pc, bt709, progressive), 640x360, 25 tbr, 1200k tbn, 50 tbc
[22:49:52 CET] <szefoski> How can I Combine these frames into valid video file using FFMPEG C API?
[22:50:30 CET] <BtbN> What do you mean? It gives you individual pictures, or a video stream?
[22:50:51 CET] <JEEB> you can read packets from the input with libavformat and then you can mux those packets into a container
[22:53:16 CET] <szefoski> How to convert such packets into valid AVFrame?
[22:53:33 CET] <JEEB> AVFrames require throwing it at the decoder
[22:53:43 CET] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html
[22:53:50 CET] <JEEB> also there are examples under docs/examples
[22:54:28 CET] <szefoski> Thank you!
[22:56:19 CET] <szefoski> @BtbN,  individual pictures
[22:56:32 CET] <BtbN> them being I/P frames makes no sense then
[22:56:39 CET] <BtbN> That would indicate them being a video stream
[23:45:18 CET] <SortaCore> does libopenh264 require shared library or is static ok
[23:47:55 CET] <JEEB> SortaCore: both should work
[00:00:00 CET] --- Sat Dec 16 2017