Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

August 2017

1 participants
62 discussions

ffmpeg-devel.log.20170825
by burek 26 Aug '17

26 Aug '17

[00:00:30 CEST] <iive> actually it might be interesting idea if the encoders could output these frames [00:00:52 CEST] <iive> this way you can watch the encoding quality in real time [00:21:42 CEST] <kierank> BBB: it's what nicolas wants... [00:38:25 CEST] <jamrial> oh lol, libav also postponed coded_frame [01:37:51 CEST] <BBB> michaelni: AVERROR_EOF [01:38:58 CEST] <nevcairiel> all these patches look stupid, wouldn't it just loop for a bit and then quit? we don't have eof checks after every single read ever [01:39:37 CEST] <BBB> I didnt check [01:39:41 CEST] <BBB> I also didnt fully review [01:43:09 CEST] <kierank> interesting that they have managed to fuzz containers [01:43:13 CEST] <kierank> but yes patches look stupid [01:43:18 CEST] <kierank> surely every read needs checking [01:58:32 CEST] <michaelni> BBB, the function seems to use AVERROR_EOF for various conditions [02:00:40 CEST] <michaelni> nevcairiel, yes its a denial of service. It would block for a long time and eventually finish. In an attack the attacker would use this to bring down some tool or service [02:01:16 CEST] <michaelni> that is all but one, one is a real endless loop IIRC [02:14:54 CEST] <BBB> can you define "long"? [02:21:53 CEST] <michaelni> BBB, its different for each case according to the reports a 410 byte file caused more than 1 hour (24 cpu core xeon 2.4ghz with 96gb ), another caused more than 30min, one was 4 one was 1 and one was 5 minutes [02:23:14 CEST] <michaelni> IIUC these are fuzzed files not hand crafted to achive the worst case [02:27:24 CEST] <peloverde> Is there currently a propagation window for fate samples before pushing? [02:28:04 CEST] <michaelni> some fate clients need up to 24h to sync the samples [02:28:52 CEST] <michaelni> i think most fate clients need no delay [02:47:38 CEST] <cone-165> ffmpeg 03Paul B Mahol 07master:dbc9a8f21f92: avcodec/aac: Add floating point 960/120 MDCT window [02:47:38 CEST] <cone-165> ffmpeg 03Alex Converse 07master:cb96e9bea418: fate: add test vector aac-al04sf_48 [04:39:43 CEST] <cone-165> ffmpeg 03James Almer 07master:e51073fe00d2: checkasm/vf_blend: rename addition128 and difference128 to grainmerge and grainextract [05:41:52 CEST] <cone-165> ffmpeg 03Muhammad Faiz 07master:ae1ce0db91b8: avfilter/af_firequalizer: add min_phase option [05:41:52 CEST] <cone-165> ffmpeg 03Muhammad Faiz 07master:e0e991f8a131: avfilter/af_firequalizer: reindent after previous commit [09:11:10 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:4b96fd2b1ec6: avfilter/af_agate: switch to activate [10:36:22 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:1e7ce6d92513: avfilter/af_amix: check ff_insert_inpad() for failure [10:36:22 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:13f9639e3e2a: avfilter/af_headphone: check ff_insert_inpad() for failure [10:36:24 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:db5604ac26f0: avfilter/af_join: check ff_insert_inpad() for failure [10:36:24 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:f39136b0a76e: avfilter/af_merge: check ff_insert_inpad() for failure [10:36:25 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:9bd1bf382e18: avfilter/f_interleave: check ff_insert_inpad() for failure [10:36:26 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:99dd47a64752: avfilter/vf_extractplanes: check ff_insert_outpad() for failure [10:36:28 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:730734d4f3e0: avfilter/af_channelsplit: check ff_insert_outpad() for failure [10:36:28 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:01b986cf1819: avfilter/f_select: check ff_insert_outpad() for failure [10:36:30 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:1a58da434ad0: avfilter/avf_concat: check ff_insert_pad() for failure [10:36:30 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:dfea94ce994a: avfilter/vf_fieldmatch: check ff_insert_inpad() for failure [10:36:32 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:0b940c95b217: avfilter/vf_decimate: check ff_insert_inpad() for failure [10:36:33 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:5e706a2afb09: avfilter/split: check ff_insert_outpad() for failure [10:36:33 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:48ddd8ddec35: avfilter/src_movie: check ff_insert_outpad() for failure [12:40:50 CEST] <cone-952> ffmpeg 03Muhammad Faiz 07master:3ddd10290afb: avfilter/af_firequalizer: fix minval on cepstrum calculation [14:35:50 CEST] <cone-952> ffmpeg 03Paul B Mahol 07master:71907f250939: doc/filters: add pseudocolor example [14:59:50 CEST] <cone-952> ffmpeg 03Derek Buitenhuis 07master:9e02f35f6a1b: mjpeg: Add support for ICC side data [14:59:51 CEST] <cone-952> ffmpeg 03Derek Buitenhuis 07master:add7b3bc3fb7: utils: Do not expand a macro with 'defined' in it [16:02:54 CEST] <J_Darnley> Is GetBitsContext public API? [16:05:34 CEST] <J_Darnley> No, it would be called AV.. if it were. [16:06:06 CEST] <J_Darnley> av_dirac_parse_sequence_header it public though. :) [16:12:33 CEST] <J_Darnley> Oh dammit! Why can't I use that with a struct on the stack? [16:42:29 CEST] <BBB> J_Darnley: you can [16:44:48 CEST] <jya> what's the deal when submitting a patch, you post it on the mailing list and then you wait? [16:49:13 CEST] <J_Darnley> BBB: Huh? It takes a struct** and says it will allocate and then I need to call av_free [16:49:21 CEST] <J_Darnley> jya: Yeah, basically [16:50:04 CEST] <BBB> jya: you can poke people (this is similar to how you assign a reviewer on patch trackers) [16:50:10 CEST] <BBB> jya: poking works like this: [16:50:22 CEST] <BBB> J_Darnley: poke! can you review my patch bla: blurb? [16:50:43 CEST] <BBB> jya: ingenious, right? [16:50:49 CEST] <jya> indeed :) [16:51:02 CEST] <jya> I'm not sure why is the best person to review that though, its the mp4 muxer [16:52:33 CEST] <BBB> ah, yes [16:52:41 CEST] <BBB> thats where email based review is better than patch review trackers [16:52:48 CEST] <BBB> :-p [16:53:03 CEST] <BBB> not sure who could review it ;) [16:53:10 CEST] <BBB> you could poke usual victims [16:54:36 CEST] <jya> BBB: sounds like a job for you then :) [16:55:13 CEST] <jya> it's damn simple patch, replace writing 0 for whenever the sampling rate is > 65536, and instead write the closest divisor [16:55:40 CEST] <jya> only does the job properly is the sampling rate is even though, but it won't matter either way [16:56:42 CEST] <BBB> sample rate? [16:56:48 CEST] <BBB> is that a subtitle thing? [16:56:50 CEST] <BBB> :-p [16:56:54 CEST] <jya> audio [16:56:59 CEST] <BBB> I know, just kidding ;) [16:57:09 CEST] <jya> ah, never know these days :) [16:57:24 CEST] <jya> BBB: I saw the multi-threading stuff for slices while looking at patches [16:57:26 CEST] <jya> that's rather exciting [16:57:33 CEST] <BBB> yes, its quite nice [16:57:47 CEST] <jya> BTW, we plan to make vp9 the default for our webRTC implementation [16:57:50 CEST] <BBB> if we want to use it for rtc, we still need error resilience [16:58:04 CEST] <BBB> but that shouldnt be super-hard [16:58:17 CEST] <jya> actually, about that. libvpx error resilience is disabled by default, I even think the option was removed from the code [16:58:38 CEST] <jya> so I'm not sure it matters that much to have it in ffvp9 [16:58:59 CEST] <jya> BBB: will you be at demuxed in October? [17:11:40 CEST] <BBB> jya: yes [17:12:00 CEST] <BBB> jya: hm& but then every time a frame is missed, you cant reconstruct [17:12:01 CEST] <BBB> that would suck [17:12:04 CEST] <jya> great I'll get to meet you there [17:12:26 CEST] <jya> how do they do without it with libvpx? [17:13:31 CEST] <BBB> they probably have a backchannel API to signal the encoder to send a new keyframe or to occlude that frame as a reference [17:13:40 CEST] <BBB> hard to say for sure [17:13:58 CEST] <BBB> the decoder obviously doesnt know any of this [17:14:11 CEST] <BBB> this is between the rtp layer and the sender (encoder) [17:14:16 CEST] <BBB> the decoder just does what it does normally [17:14:23 CEST] <BBB> it happens to work, basically [17:18:42 CEST] <wm4> jkqxz: this v4l2 stuff looks pretty batshit [17:20:07 CEST] <cone-952> ffmpeg 03James Almer 07master:2c800eb7375c: avcodec: make the avcodec_get_chroma_sub_sample deprecation effective [17:21:49 CEST] <jkqxz> Yeah, but apparently it works. I've been failing to find time to look at it again - need at least a few hours to go through it properly. (Maybe tomorrow...) [17:22:13 CEST] <BBB> j-b: who do I poke about ticket prices? [17:23:02 CEST] <jya> BBB: that the peer request a keyframe is something else entirely [17:23:11 CEST] <jya> that is done [17:23:19 CEST] <BBB> right [17:23:29 CEST] <BBB> but if you hav that, error resilience in the decoder isnt so important [17:23:41 CEST] <BBB> different methods to do the same (sorta) thing [17:23:54 CEST] <jya> but from the decoder point of view, there's nothing in place for error-resilience, it's not compiled in [17:24:22 CEST] <jya> I implemented a change to use ffvp9 instead of libvpx [17:24:29 CEST] <jya> issues occurred when the resolution changed [17:24:56 CEST] <jya> libvpx handled it just fine. with ffvp9 you end up with a crappy image [17:25:01 CEST] <BBB> really? [17:25:06 CEST] <BBB> we have fate tests for that [17:25:17 CEST] <BBB> is this the svc-thing? or is this with a new kf? [17:25:19 CEST] <jya> like the new (typically lower resolution) image in the top left corner of an otherwise green image [17:25:32 CEST] <BBB> uh& [17:25:33 CEST] <BBB> hm... [17:25:59 CEST] <jya> mind you, it may be something I haven't done, such as not reconfiguring the decoder for a new res [17:26:07 CEST] <BBB> you dont have to reconfigure it [17:26:10 CEST] <jya> I just keep calling input with the data as it comes in [17:26:13 CEST] <BBB> you just have to read out the per-frame sizes :-p [17:26:19 CEST] <BBB> (AVFrame->width/height) [17:26:29 CEST] <jya> what comes out has the same resolution has the previous frame, but padded with green [17:26:42 CEST] <BBB> really& [17:26:47 CEST] <BBB> how interesting [17:26:49 CEST] <jya> i do that already (read the AVFrame dimensions) [17:26:58 CEST] <jya> I have some doubts suddenly, let me check again [17:27:05 CEST] <BBB> please do [17:27:09 CEST] <BBB> thatd be a major bug ;) [17:27:12 CEST] <durandal_170> have sample? [17:27:40 CEST] <BBB> in fact, Im pretty sure it works because I have some scalable samples and they rescale fine in my analyzer (which uses AVFrame->width/height) [17:27:51 CEST] <BBB> but happy to be proven wrong :-p [17:27:53 CEST] <jya> BBB: yes, that's what it does: https://dxr.mozilla.org/mozilla-central/source/dom/media/platforms/ffmpeg/F… [17:28:04 CEST] <jya> it reads the YUV planes from the AVFrame as well as the dimensions [17:29:40 CEST] <BBB> how strange [17:30:10 CEST] <jya> I'll try to reproduce it as part of a webRTC session [17:30:25 CEST] <jya> it's not easy when you're on a gigabit fiber at home [17:30:42 CEST] <jya> but this summer, I was traveling, on a mobile phone as modem.. was happening a lot [17:30:52 CEST] Action: kierank has gigabit fibre at work and these adaptive streaming things still are awful [17:31:09 CEST] <jya> the same code with just using libvpx as decoder, and the frames resized perfectly [17:31:11 CEST] <kierank> though i guess it's blame tcp which webrtc don't use [17:32:23 CEST] <jya> kierank: with what Youtube for example? [17:32:31 CEST] <jya> they do a pretty good job these days with MSE [17:32:31 CEST] <BBB> lemme test [17:32:35 CEST] <kierank> all of the streaming services on a smart tv [17:32:38 CEST] <kierank> amazon, netflix etc [17:32:41 CEST] <kierank> iplayer [17:32:47 CEST] <kierank> they just decide to randomly drop to 480p [17:32:59 CEST] <jya> amazon, netflix on a web browser desktop should be perfect really [17:33:27 CEST] <jya> for a smart TV, they typically use HLS, and unlike with MSE/DASH the job is on the client to do the adaptation [17:33:33 CEST] <jya> it's always a bit slower. [17:34:01 CEST] <jya> which isn't helped with the fact that HLS doesn't require a new segment to start with a keyframe, so typically when it change resolution, for a few seconds it's crap [17:35:23 CEST] <wm4> jkqxz: sent a quick review [17:36:03 CEST] <wm4> jvlol wut [17:36:07 CEST] <wm4> oops [17:36:10 CEST] <wm4> jya: wat [17:36:22 CEST] <wm4> what's the point of adaptive stuff if you can't actually adapt [17:36:43 CEST] <wm4> which pretty much requires that decoding can be restarted from an arbitrary fragment [17:38:25 CEST] <BBB> jya: just tested with vp90-2-05-resize.ivf [17:38:51 CEST] <BBB> jya: and I get (AVFrame->width/height): 352x288 -> 282x173 -> 352x288 [17:39:17 CEST] <jya> BBB: ok, I'll do further test and see what's going on then [17:39:20 CEST] <BBB> ty [17:39:33 CEST] <jya> but is the input set with the right resolution though? [17:42:22 CEST] <jya> during a webrtc session you don't know that, so here the input has no resolution set in the input [17:43:30 CEST] Action: jya gotta go [17:45:35 CEST] <BBB> jya: input is unset, the decoder overwrites whatever the input sets [18:48:40 CEST] <cone-952> ffmpeg 03James Almer 07master:8a0954dd51ca: avcodec: add missing FF_API_DEBUG_MV wrappers [19:18:27 CEST] <jamrial> BBB: can you check the getchroma comment from michael? [19:18:40 CEST] <jamrial> as i said there was a reason why it wasn't deprecated :/ [19:19:08 CEST] <BBB> he means int a, b; avcodec_get_chroma_subsample(user_input, &a, &b); printf(%d, %d\n, a, b); is fine with old AI [19:19:10 CEST] <BBB> API [19:19:17 CEST] <BBB> but in new API you need a condition [19:19:51 CEST] <jamrial> epatchwelcome. i never wanted to deal with this :p [19:19:57 CEST] <BBB> desc = av_get_pix_fmt_desc(user_input); if (!desc) HELP!!!!; printf(%d, %d\n, desc->comp[1].h_ss, v_ss); [19:20:03 CEST] <BBB> what do you mean? [19:20:07 CEST] <BBB> youre not changing any callers [19:20:09 CEST] <BBB> its totally fine [19:20:16 CEST] <BBB> maintainers should change their callers [19:20:37 CEST] <jamrial> alright [19:21:18 CEST] <BBB> I see 17 users in libavcodec [19:21:21 CEST] <BBB> nothing outside that [19:21:23 CEST] <BBB> so not that bad [19:21:53 CEST] <BBB> in most cases weve already decided at that point what the pixfmt is, so it really doesnt matter [19:24:51 CEST] <michaelni> BBB, its no problem to change it, but dont you think that API changes that everyone has to update their code to should be discussed? [19:25:32 CEST] <BBB> I have no opinion on that [19:26:25 CEST] <nevcairiel> not sure you can call avcodec_get_chroma_sub_sample inherently safe if it contains an abort() =p [19:27:00 CEST] <BBB> maybe its safe because valgrind doesnt complain about it? [19:27:23 CEST] <nevcairiel> both of thsoe cases deal with invalid pixfmts, in this case your app just quits, in the other you can write a check [19:27:28 CEST] <nevcairiel> i would say the other is safer [19:27:39 CEST] <BBB> again, I have no opinion on that [19:27:49 CEST] <BBB> but having two public APIs to do the same thing is ridiculous [19:27:53 CEST] <jamrial> guess i should have waited for more opinions before pushing [19:27:56 CEST] <BBB> subsampling is in desc, so use the desc API [19:27:58 CEST] <BBB> jamrial: no, its fine [19:28:04 CEST] <BBB> this has been in libav for ages [19:28:08 CEST] <BBB> at some point we have to move on [19:28:09 CEST] <michaelni> nevcairiel, if the code is misused one aborts() the other does something unexpected and random hard to debug [19:28:36 CEST] <michaelni> "<BBB> but having two public APIs to do the same thing is ridiculous" <-- i strongly agree [19:28:59 CEST] <BBB> hows coded_frame out of AVCodecContext going btw? [19:29:05 CEST] <BBB> speaking of interesting things [19:29:10 CEST] <nevcairiel> michaelni: but to be safe I have to validate the pixfmt myself before, basically by calling the same API anyway, so in my eyes the new API is therefor better [19:29:22 CEST] <jamrial> BBB: i know, but seeing the deprecation was made uneffective for a reason (regardless of it being good/bad/right/wrong), i should have waited for a comment from the person that did that [19:30:01 CEST] <BBB> how many prores encoders and decoders do we have again? [19:30:05 CEST] <BBB> alright, still the same :-p [19:30:10 CEST] <jamrial> heh [19:30:23 CEST] <jamrial> both are waiting for tests(tm) to see which is better i guess :p [19:30:39 CEST] <jamrial> the whole "one is lgpl" doesn't apply anymore after all [19:31:48 CEST] <jamrial> alright, got the major bump working with a minimal amount of ~2 years old APIs postponed (because removing them is a pain atm) [19:31:55 CEST] <michaelni> nevcairiel, if you just write some code lazily (which is what most people probably do) the old simply aborts when its wrong (easy to spot and fix) the new does someting random which can be annoying to debug [19:32:20 CEST] <nevcairiel> its not our job to fix lazy developers code [19:32:30 CEST] <nevcairiel> also null-pointer deref also just crashes on 99% of all systems [19:32:35 CEST] <jamrial> will send a patchset to the ml, to see if anyone wants to look at said apis and properly remove them. otherwise we can go ahead as is [19:34:32 CEST] <nevcairiel> we report errors through return values, not by abort()'ing all over [19:37:52 CEST] <BBB> how about we create an abort callback that users can implement to longjmp back to their caller code, but otherwise can be used internally to abort? <libjpeg> [19:38:05 CEST] <nevcairiel> go away with longjmps =p [19:38:10 CEST] <BBB> muhahahahahaha [19:38:47 CEST] <BBB> (and for the record: that was not serious, its godawful design) [19:39:29 CEST] <nevcairiel> i've worked with code that uses this, following the logic flow is awful [19:45:09 CEST] <michaelni> nevcairiel, when practically no caller checks the return, its not that great as a way to handle errors [19:47:16 CEST] <nevcairiel> again, thats not our problem. we have a clear way to communicate errors for all sorts of APIs, singular exceptions that abort instead are not good [19:49:02 CEST] <nevcairiel> or should we start abort()ing everywhere instead of using return values, just in case someone didnt check it? [19:50:02 CEST] <BBB> longjmp!!! [19:50:03 CEST] <BBB> guys [19:50:48 CEST] <nevcairiel> i even entirely hate the concept that release-mode builds can include abort()'s in them in general [19:51:10 CEST] <BBB> this problem is solved already, why do you think all cameras use jpeg when much better compression alternatives exist (e.g. HEIF)? it has nothing to do with compatibility; its longjmp!!! [19:51:56 CEST] <BBB> longjmp is the singularity around which everything else revolves. everything changes, but (lib)jpeg remains, and the only lib implementing longjmp error management is&? libjpeg! learn guys, its not correlation, its causation! [19:52:09 CEST] <BBB> :-p [19:52:17 CEST] <JEEB> :D [19:52:29 CEST] <BBB> maybe I shouldve added webp there for even more nuts [19:52:47 CEST] <BBB> </gone> [19:52:47 CEST] <drv> I think libpng uses longjmp() error handling too :) [19:52:51 CEST] <JEEB> but yea, trying to propagate abort() based error flagging just because people don't check results [19:53:06 CEST] <JEEB> users can always come up with ways of ignoring errors [19:54:22 CEST] <wm4> libpng also uses longjmp [19:55:41 CEST] <BBB> and what image format was able to overthrow gif? png! longjmp! guys! EUREKA! [19:55:54 CEST] <BBB> (maybe Im taking this too far :-D ) [19:56:24 CEST] <BtbN> I'd argue h264 has overthrown gifs on the web by now. [20:02:04 CEST] <BBB> animated gifs maybe [20:02:07 CEST] <BBB> logos still use png [20:02:51 CEST] Action: ubitux is still using gif everywhere he can [20:03:24 CEST] <ubitux> if github allows to use some looping webm, maybe i'll switch [20:03:33 CEST] <ubitux> (in their markdown thing) [20:03:44 CEST] <RiCON> i don't think you can [20:04:03 CEST] <ubitux> then long live to gif [20:04:39 CEST] <BtbN> imgur is trying to "standardize" gifv [20:04:53 CEST] <BtbN> (renamed mp4 without audio, looping by default) [20:05:28 CEST] <wm4> dumb [20:05:51 CEST] <wm4> fole extensions officially don't mean anything on http anyway [20:05:53 CEST] <wm4> *file [20:06:09 CEST] <BtbN> Pretty sure they also made up a new mime type for it [20:07:57 CEST] <nevcairiel> definitely, and mime-type means something on http [20:09:51 CEST] <RiCON> BtbN: isn't the mimetype just text/html? [20:10:30 CEST] <BtbN> for images and videos? No [20:10:35 CEST] <RiCON> for gifvs [20:10:40 CEST] <BtbN> Doubt it [20:10:51 CEST] <RiCON> it's a simple html with a <video>mp4 with fallback to gif [20:11:15 CEST] <RiCON> at least in browsers and curl [20:11:51 CEST] <RiCON> even if you go directly to ID.mp4 it 301s to the ID.gifv [20:12:46 CEST] <BBB> you have to admit that renaming .mov to .mp4 did great things [20:13:00 CEST] <BBB> didnt work for .ogg .ogm .oga etc. though [20:13:04 CEST] <BBB> .ogv [20:13:20 CEST] <wm4> RiCON: they might use http content negotiation if it works in curl [20:13:24 CEST] <jamrial> there's even .ogx [20:13:31 CEST] <RiCON> .ogg and .ogv are sorta used [20:13:42 CEST] <RiCON> for vorbis and theora+vorbis [20:13:43 CEST] <wm4> BBB: mp4 pretty much sucks [20:13:46 CEST] <jamrial> i have never seen a single file using it, unlike .ogv [20:13:51 CEST] <wm4> I've decided that mkv is the better format [20:14:39 CEST] <jamrial> RiCON: afaik .ogv is 1 video + 1 audio. can be theora, vp8, vorbis, flac, etc [20:15:12 CEST] <wm4> isn't ogm avi-in-ogg or something [20:15:21 CEST] <wm4> ogm timestamps are still broken with libavformat [20:15:21 CEST] <jamrial> .ogx is supposed to have a skeleton stream (weird data stream to work around limitations of the format), and can have several streams of any kind, including subtitles [20:15:24 CEST] <nevcairiel> ogm is its own sort of nightmare [20:15:29 CEST] <wm4> (got broken somewhere in recent years) [20:15:30 CEST] <jamrial> wm4: ogm is a non xiph hack [20:16:11 CEST] <wm4> the most shocking thing is that xiph apparently defends ogg [20:19:27 CEST] <RiCON> wm4: appparently curl/mpv work with the .mp4 directly [20:19:55 CEST] <nevcairiel> they use all sort of shitty server-side magic these days to serve different things to different clients [20:21:29 CEST] <RiCON> and the download only gives the huge gif, lol [20:21:36 CEST] <RiCON> download link* [20:21:53 CEST] <wm4> odd [21:01:33 CEST] <Compn> gifv is stupid name [21:01:45 CEST] <Compn> those sites that serve different items piss me off [21:27:46 CEST] <TD-Linux> BBB, the .opus rename did work well though [21:27:57 CEST] <BBB> cool [23:17:06 CEST] <atomnuker> BBB: what happened to the loopfilter avx2 asm? [23:22:05 CEST] <BBB> gh0st__: ^^ [23:26:21 CEST] <gh0st__> atomnuker: no worries, I am going to do it. [23:37:16 CEST] <wm4> lol web tech [23:59:26 CEST] <cone-260> ffmpeg 03Michael Niedermayer 07master:7c10068da10a: avcodec/dvbsubdec: Check for duplicate regions in dvbsub_parse_page_segment() [23:59:26 CEST] <cone-260> ffmpeg 03pkviet 07master:e0436ddaa496: ffmpeg options: Enable trailing ? for map_channel [00:00:00 CEST] --- Sat Aug 26 2017

1 0

ffmpeg.log.20170825
by burek 26 Aug '17

26 Aug '17

[00:07:02 CEST] <voip_> hello guys, i forgot what the normal range for q parameter ? [00:08:14 CEST] <voip_> quantizer [00:09:39 CEST] <kepstin> squarecircle: unless you've specifically asked ffmpeg to use a hw decoder, it won't be using one. You have to specify the device to use, so you can say which card to run on. [00:09:46 CEST] <kepstin> voip_: depends on the codec. [00:10:00 CEST] <voip_> actually acceptable value for CPU load h264 [00:11:32 CEST] <kepstin> are you using the x264 encoder? If so, use the '-qp' option (not -q) for constant quantizer mode, and probably something around 20 or so, lower for higher quality. [00:11:50 CEST] <squarecircle> kepstin: I'm not sure about that [00:12:34 CEST] <kepstin> squarecircle: well, I'm sure about it ;) [00:12:47 CEST] <squarecircle> kepstin: oh well, if I think, about it, yeah, a 1080p file creates 100% load on one cpu, a 4k 100% on four cpus [00:12:51 CEST] <voip_> kepstin, i encoding 9 streams and have q=32.0 in stats, but speed=0.992x [00:13:11 CEST] <squarecircle> how do I can tell ffmpeg to use the hardware? [00:13:32 CEST] <kepstin> voip_: the qp setting on x264 has rather minimal effect on how fast the encoder runs... look at the -preset option to adjust that. [00:14:16 CEST] <kepstin> squarecircle: Neither of the machines you mentioned support hardware decoding... [00:14:49 CEST] <kepstin> squarecircle: how to set it up depends on what type of hardware decoder you have and what OS. [00:16:41 CEST] <voip_> kepstin, so quantizer stats doesnt related with CPU loading ? I was tink q shows how mmuch my CPU loaded [00:16:59 CEST] <kepstin> voip_: nope, it's related to the visual quality of the encoded video [00:17:14 CEST] <kepstin> (when using x264, it's a very loose relation, the numbers don't mean much) [00:18:05 CEST] <kepstin> voip_: to make x264 run faster, use the -preset option to select a faster preset. The default is 'medium', so try 'fast', 'faster', 'veryfast', etc. [00:20:00 CEST] <voip_> thank you, kepstin [00:22:02 CEST] <squarecircle> kepstin: well I would put in some nvidia 8800GT that are moalding here [00:22:42 CEST] <squarecircle> kepstin: iirc I can put in three cards [00:23:25 CEST] <kepstin> squarecircle: 8800GT should be able to do 1080p h264 8bit decoding, but it doesn't have a hardware encoder. [00:24:34 CEST] <kepstin> assuming you're using nvidia's drivers (do they even still support the 8800gt? Might need the legacy version), you can probably use the cuvid decoder as described here: https://trac.ffmpeg.org/wiki/HWAccelIntro#CUDACUVIDNvDecode [00:24:47 CEST] <DHE> IIRC gtx680 or so was the first with the NVENC encoder chip on it [00:25:32 CEST] <squarecircle> so hardware acceleration in ffmpeg does not uses the openCL or Cuda, but relies on available decoders? [00:25:45 CEST] <squarecircle> so the best would be to buy a hardware decoder? [00:25:53 CEST] <DHE> opencl is limited to like 2 filters in ffmpeg, and some limited lookahead in x264 [00:26:13 CEST] <kepstin> squarecircle: all of the "hardware accellerated" decoding in ffmpeg is actually using decoder hardware, yes [00:26:19 CEST] <DHE> nvenc should be on any gtx card that's less than 4 years old now, except maybe the really low end ones [00:26:36 CEST] <kepstin> squarecircle: the geforce 8800gt has a dedicated part of the die with a decoder on it (but no encoder) [00:26:47 CEST] <kepstin> later cards add and encoder too, on some models [00:26:52 CEST] <squarecircle> kepstin: I don't need any encodet [00:27:13 CEST] <squarecircle> at the moment, I need only more decoding power [00:27:14 CEST] <squarecircle> :) [00:27:17 CEST] <DHE> yeah VDPAU and other APIs exist for video decoding (VDPAU is playback-oriented) [00:27:31 CEST] <kepstin> huh, the decoder on the 8800gt should work on nouveau via the vdpau api, assuming you have the appropriate firmware [00:27:45 CEST] <squarecircle> kepstin: hm [00:27:50 CEST] <squarecircle> thats an idea [00:28:02 CEST] <squarecircle> I'll try next week [00:28:13 CEST] <furq> wow, an 8800GT [00:28:19 CEST] <kepstin> or you can use it with the nvidia driver and the cuda/cuvid api [00:28:22 CEST] <furq> i think i have one of those in a box somewhere with no heatsink on it [00:28:30 CEST] <kepstin> either way, it uses the same decoder hardware, just different apis [00:28:31 CEST] <furq> that'll doubtless come in handy some day [00:28:49 CEST] <squarecircle> furq: well, thats whats moalding around in the local space here [00:29:12 CEST] <squarecircle> furq: there are also some Radeon HD6250 and stuff [00:29:45 CEST] <kepstin> no idea on the speed of the decoder on that card, all they had to support was realtime playback of ~1080p content [00:29:51 CEST] <squarecircle> hm [00:29:53 CEST] <squarecircle> ok [00:34:03 CEST] <kepstin> apparently there was a significant bump to the decoder performance in the geforce 600/700 series (kepler) gpus, which corresponds to when they added an encoder and let people do full hardware transcoding [00:34:23 CEST] <kepstin> so stuff older than that is probably not worth it unless you're using a contemporary cpu as well [00:39:31 CEST] <squarecircle> well its junk thats lying around and I don't spend money on it [00:40:21 CEST] <kepstin> worst case with a modern cpu is that it slows down the decoding :) [00:41:07 CEST] <squarecircle> Intel(R) Xeon(R) CPU E5640 @ 2.67GHz [00:41:21 CEST] <squarecircle> two times on my test bench [00:42:48 CEST] <squarecircle> so 8C16T [00:43:20 CEST] <squarecircle> is there a way to enhance the decoding by telling ffmpeg to uses as many cores as possible? [00:44:31 CEST] <squarecircle> Load average: 111.05 103.14 78.41 [00:44:37 CEST] <squarecircle> at the moment ^^ [00:48:46 CEST] <squarecircle> its obviously not a good idea to start 100 processes in parallel [00:49:01 CEST] <squarecircle> efficiency goes down [00:51:18 CEST] <DHE> you can specify -threads 2 (or whatever) before the -i parameter and it applies to the decoder [00:51:23 CEST] <DHE> but that assumes the decoder supports it [00:55:58 CEST] <squarecircle> hm [00:56:35 CEST] <CoreX> you learn something new everyday [00:57:01 CEST] <squarecircle> DHE: I'll try it [00:57:25 CEST] <squarecircle> thank you kepstin DHE [01:12:20 CEST] <LiedFrice> Afternoon :) [01:13:24 CEST] <LiedFrice> I was curious, can ffplay display a subtitle stream from a pipe like so? [01:14:39 CEST] <LiedFrice> Everything seems to be encoding right, I just do not see subtitles in the FFplay window: https://pastebin.com/raw/gnCM0GFM [01:43:09 CEST] <LiedFrice> Any thoughts are much appreciated, could really help with some presentations [01:51:13 CEST] <LiedFrice> Just an obvervation, vlc player can read the subtitle stream from a pipe and display it, but FFplay does not display anything with the same command [01:51:17 CEST] <LiedFrice> ffmpeg -f v4l2 -i /dev/video0 -sub_charenc ISO8859-1 -i MLP1.srt -vcodec huffyuv -scodec text -f matroska - | vlc - [02:36:00 CEST] <LiedFrice> rip [02:51:24 CEST] <LiedFrice> Also noted, mplayer can display a subtitle stream in a named pipe while FFplay still isn't displaying any subtitles [02:51:26 CEST] <LiedFrice> ffmpeg -f v4l2 -i /dev/video0 -sub_charenc ISO8859-1 -i MLP1.srt -vcodec huffyuv -scodec subrip -f matroska pipe:1 > itsafifo | mplayer itsafifo -vo x11 [03:44:12 CEST] <alexpigment> Hey guys, I saw this patch for FFMPEG to make it large address aware: https://ffmpeg.org/pipermail/ffmpeg-devel/2014-September/163207.html [03:44:26 CEST] <alexpigment> I'm a little green on patching, but what file specifically is being patched here? [03:49:13 CEST] <furq> configure [03:50:25 CEST] <alexpigment> Oh right. Sorry, I'm used to the Windows world where things have file extensions [03:50:31 CEST] <alexpigment> There's actually a file called configure [03:50:39 CEST] <alexpigment> Thanks for helping me realize the obvious [04:55:52 CEST] <dan2wik> I'm having a little trouble with cpu usage on an audio stream. [04:56:05 CEST] <dan2wik> 1 sec, I'll paste the command line [04:57:35 CEST] <dan2wik> https://pastebin.com/raw/vuuXs3vM [04:58:10 CEST] <dan2wik> It is currently using the same amount of cpu as the video encoding I am doing which is rather unacceptable. [07:30:06 CEST] <zarac> hey folks ; ) [07:34:37 CEST] <durandal_1707> hey [07:35:36 CEST] <kerio> what's the simplest way of shoving jpeg in a video container with absolute timestamps? [07:36:18 CEST] <zarac> ; ) [07:36:43 CEST] <zarac> was gonna type a bunch.. about tracker being down and about another bug. [07:37:01 CEST] <zarac> it solved itself... ; ) (tracker is a bit slow) [07:39:24 CEST] <zarac> registered and bumped ; ) [08:17:54 CEST] <ussher_> im trying to merge 2 .mp3 files, but the lenght of the output is always determined by the length of the shortest song. How to make the longest song be the length? https://pastebin.com/Rw8r6XYB [08:45:15 CEST] <teratorn> ussher_: run the shorter one through an apad filter filter before amerge? [08:45:30 CEST] <teratorn> ussher_: perhaps.. [08:46:53 CEST] <ussher_> thanks teratorn, i've rethunk it. currently looking at looping over the short track to make it longer than the longest track so the shortest track is always the one I want. [08:47:19 CEST] <ussher_> I'll look into the apad filter next time i get stuck with this current thought line. [08:47:23 CEST] <ussher_> appreciated. [08:47:28 CEST] <teratorn> cool good luck [11:22:22 CEST] <pihpah> How can I extract mov_text subtitles? What are those exactly? [11:35:35 CEST] <JEEB> they're mov/3gpp/mp4 timed text [11:35:52 CEST] <JEEB> they're in a container specific format so I'm not sure if they have a standardized format outside of the container [11:36:11 CEST] <JEEB> you can extract them as srt or ass, for example [11:44:26 CEST] <pihpah> JEEB: tried with ffmpeg -i {} -map 0:s:0 test.srt did not work out. [20:23:53 CEST] <flok420> what can be the problem that if avformat_open_input returns -1 (ffmplay and mplayer also fail) on an rtsp stream? [20:34:07 CEST] <dan3wik> I'm having issues with my audio encoder. I am using 1 ffmpeg instance for video and 1 for audio. The video one sits around 30%, the audio one starts at 15% but ends up around 60% after 2 minutes [20:34:43 CEST] <dan3wik> Command line for audio is "ffmpeg -f alsa -ar 44100 -ac 1 -i hw:%d -f mpegts -codec:a libtwolame -b:a 32k -muxdelay 0.02 http://%s:%s/%s/1/1" [21:36:27 CEST] <user_12> How do I convert/copy a WMV to an MP4 (with both auto and video)? It seems like this is overly complicated, everything I try (i.e., ffmpeg -i in.wmv -c:all copy out.mp4) never work, or the audio or video is missing [21:36:47 CEST] <user_12> every forum I goto has some other way or other flags to do it [21:36:56 CEST] <user_12> whats the best way, I dont care about speed/compression [21:37:08 CEST] <c_14> ffmpeg -i in.wmv out.mp4 [21:37:14 CEST] <c_14> eeh [21:37:18 CEST] <c_14> ffmpeg -i in.wmv -map 0 out.mp4 [21:38:11 CEST] <user_12> that throws out on-monotonous DTS in output stream 0:0; previous: 685207, current: 678032; changing to 685208. This may result in incorrect timestamps in the output file. which makes the audio choippy [21:38:54 CEST] <user_12> both of those do [21:39:05 CEST] <furq> user_12: you can't copy wmv streams into mp4, they don't support any of the same codecs [21:39:15 CEST] <furq> if you want to reencode it then do what c_14 said [21:39:25 CEST] <furq> if you have a broken wmv container or something and you want to remux, use mkv [21:39:57 CEST] <user_12> I did try to re-encode it, it doesn't sound right, its choppy [21:40:10 CEST] <user_12> mkv? [21:40:39 CEST] <user_12> How do I go from WVM to Mp4 then>? [21:40:50 CEST] <user_12> WMV to MP4 rather [21:40:57 CEST] <furq> you reencode it [21:41:04 CEST] <user_12> and how do I do that? [21:41:12 CEST] <furq> you do what c_14 said [21:41:19 CEST] <user_12> he posted two things, what one [21:41:23 CEST] <furq> the second one [21:41:51 CEST] <user_12> and I just said when I 're-encode it' it throws tons of DTS outpit stream errors, which makes the audio choppy [00:00:00 CEST] --- Sat Aug 26 2017

1 0

ffmpeg-devel.log.20170824
by burek 25 Aug '17

25 Aug '17

[11:08:29 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07master:c42a1388a6d1: avformat/rtpdec_h264: Fix heap-buffer-overflow [11:08:29 CEST] <cone-155> ffmpeg 03Dale Curtis 07master:37e8edc9f515: avformat/mov: Fix trampling of ctts during seeks when sidx support is enabled. [12:01:59 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07master:2b44dcbc44e9: avcodec/hevc_ps: Check delta_pocs in ff_hevc_decode_short_term_rps() [12:02:00 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07master:837cb4325b71: ffprobe: Fix null pointer dereference with color primaries [12:02:01 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07master:351e28f9a799: ffprobe: Fix NULL pointer handling in color parameter printing [12:51:38 CEST] <cone-155> ffmpeg 03Carl Eugen Hoyos 07master:cb1a3eecac2d: lsws/rgb2rgb: Add unscaled 48bit to 64bit rgb conversion. [13:00:43 CEST] <cone-155> ffmpeg 03Carl Eugen Hoyos 07master:f61e2dcfc399: lavf/g726: Demuxer for raw G.726 streams, both left- and right-justified. [14:12:25 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:8dc06a1cb151: avcodec/takdec: Fix multiple runtime error: signed integer overflow: 637072 * 4096 cannot be represented in type 'int' [14:12:26 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:e3d4321739af: avcodec/pafvideo: Fix assertion failure [14:12:27 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:e9c8fdbbcbb4: avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: 53098 * 40448 cannot be represented in type 'int' [14:12:28 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:bcdd5463f35d: avcodec/ac3dec_fixed: Fix multiple runtime error: signed integer overflow: -39271008 * 59 cannot be represented in type 'int' [14:12:29 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:f4dae487906a: avcodec/indeo4: Check remaining data in Pic hdr extension parsing code [14:12:30 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:5dc0393d9663: avcodec/flicvideo: Fix runtime error: signed integer overflow: 4864 * 459296 cannot be represented in type 'int' [14:12:31 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:e3a75af7080c: avcodec/ra144: Fix runtime error: signed integer overflow: -2200 * 1033073 cannot be represented in type 'int' [14:12:32 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:f0f9fa218460: avcodec/tiff: Fix leak of geotags[].val [14:12:33 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:295b24643ecf: avcodec/aacdec_fixed: Fix runtime error: left shift of negative value -1297616 [14:12:34 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:d182bb21add5: avcodec/snowdec: Fix runtime error: left shift of negative value -1 [14:12:35 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:0dfda74afc8d: avcodec/wavpack: Fix runtime error: signed integer overflow: 1886191616 + 277872640 cannot be represented in type 'int' [14:12:36 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:bc8fe5c4bdb4: avcodec/jpeg2000dwt: Fix runtime error: left shift of negative value -123 [14:12:37 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:0ac41463891c: avcodec/sbrdsp_fixed: Return an error from sbr_hf_apply_noise() if operations are impossible [14:12:38 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:fd0da0eef007: avcodec/aacsbr_fixed: Check shift in sbr_hf_assemble() [14:12:39 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:296b444a5caf: avcodec/mpeg4videodec: Fix integer overflow in num_sprite_warping_points=2 case [14:12:40 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:7bca492cfcc7: avcodec/mpeg4videodec: Check sprite delta upshift against overflowing. [14:12:41 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:c2562f5a8e0c: avcodec/hevc_refs: Check nb_refs in add_candidate_ref() [14:12:42 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:c8733c73763f: avcodec/hevcdec: Check nb_sps [14:12:43 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:92c5ff0763b8: avcodec/jpeg2000: Fixes integer overflow in ff_jpeg2000_ceildivpow2() [14:12:44 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:eb38f232b4ed: avcodec/shorten: Sanity check maxnlpc [14:12:45 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:c436af15596a: avcodec/jpeg2000dec: Check nonzerobits more completely [14:12:46 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:1ce850f96da2: avcodec/hevcdec: Fix signed integer overflow in decode_lt_rps() [14:12:47 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:ba23d53710ec: avcodec/hevcpred_template: Fix left shift of negative value [14:12:48 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:0aa14c7f67b2: avcodec/jpeg2000dsp: Reorder operations in ict_int() to avoid 2 integer overflows [14:12:49 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:5aa7d228cbad: avcodec/takdec: Fixes: integer overflow in AV_SAMPLE_FMT_U8P output [14:12:50 CEST] <cone-155> ffmpeg 03Anton Mitrofanov 07release/2.8:365ab04b16ec: avcodec/h264_cabac: Fix CABAC+8x8dct in 4:4:4 [14:12:51 CEST] <cone-155> ffmpeg 03Anton Mitrofanov 07release/2.8:a85f8fd4a625: avcodec/h264_mb: Fix 8x8dct in lossless for new versions of x264 [14:12:52 CEST] <cone-155> ffmpeg 03Anton Mitrofanov 07release/2.8:ea73c4813d83: avcodec/h264: Fix mix of lossless and lossy MBs decoding [14:12:53 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:cbc4f40d1372: avcodec/aacdec_fixed: Check s for being too small [14:12:54 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:4afd24805954: avcodec/wavpack: Fix undefined integer negation [14:12:55 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:b66e30ca7658: avcodec/mpeg4videodec: Fix overflow in virtual_ref computation [14:12:56 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:5c818b62867d: avcodec/hevc_filter: Fix invalid shift [14:12:57 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:be92b2702448: avcodec/tiff: Update pointer only when the result is used [14:12:58 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:7fadd9625f71: avcodec/takdec: Fix integer overflow [14:12:59 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:fe74c2364ee3: avcodec/wavpack: Fix integer overflow [14:13:00 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:7ee48d9de118: avcodec/mpeg4videodec: Fix GMC with videos of dimension 1 [14:13:01 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:bd33b15fe6a6: avcodec/wavpack: Fix integer overflow in wv_unpack_stereo() [14:13:02 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:bbcb59b94826: avcodec/apedec: Fix integer overflow [14:13:03 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:a6e90e5998ab: avcodec/jpeg2000dwt: Fix integer overflow in dwt_decode97_int() [14:13:04 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:f6954a1482f3: avcodec/vb: Check vertical GMC component before multiply [14:13:05 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:a5e969dd28c2: avcodec/hevc_ps: Fix integer overflow with beta/tc offsets [14:13:06 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:610bd595228b: avcodec/wavpack: Fix invalid shift [14:13:07 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:82ba7646c249: avcodec/sbrdsp_fixed: Fix integer overflow in sbr_hf_apply_noise() [14:13:08 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:080d6de9dfc1: avcodec/aacps (fixed point): Fix multiple signed integer overflows [14:13:09 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:a84ed3d01137: avcodec/mjpegdec: Clip DC also on the negative side. [14:13:10 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:1b1abf077d64: avcodec/aacdec_template (fixed point): Check gain in decode_cce() to avoid undefined shifts later [14:13:11 CEST] <cone-155> ffmpeg 03Brice Waegeneire 07release/2.8:061be75481ed: doc/filters: typo in frei0r [14:13:12 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:56e2ec0e9fea: avcodec/aacdec_fixed: fix: left shift of negative value -1 [14:13:13 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:91442fdc1c6e: avcodec/aacps: Fix multiple integer overflow in map_val_34_to_20() [14:13:14 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:490b6599bbf4: avformat/oggparsecelt: Do not re-allocate os->private [14:13:15 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:58ce199abac4: avcodec/hevc_ps: fix integer overflow in log2_parallel_merge_level_minus2 [14:13:16 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:b566ab49ca84: avformat/rtmppkt: Convert ff_amf_tag_size() to bytestream2 [14:13:17 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:8f9cbb3b7e84: avformat/rtmppkt: Convert ff_amf_get_field_value() to bytestream2 [14:13:18 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:406d9fdd1357: avcodec/takdec: Fix integer overflow in decode_subframe() [14:13:19 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:95bbbbd14e44: avcodec/diracdec: Fix integer overflow in divide3() [14:13:20 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:9d0eb81cb85c: avcodec/dirac_dwt: Fix multiple integer overflows in COMPOSE_DD97iH0() [14:13:21 CEST] <cone-155> ffmpeg 03Steven Siloti 07release/2.8:f0f45d840453: avformat/utils: fix memory leak in avformat_free_context [14:13:22 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:f236601e29b9: avcodec/h264_slice: Fix overflow in slice offset [14:13:23 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:5f44aa14ddb2: avcodec/aacdec_fixed: fix invalid shift in predict() [14:13:24 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:30a2c1a1b83f: avcodec/dirac_dwt: Fixes integer overflows in COMPOSE_DAUB97* [14:13:25 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:96cf249751bb: avcodec/mpeg4videodec: Clear mcsel before decoding an image [14:13:26 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:b463a0347636: avcodec/diracdec: Check perspective_exp and zrs_exp. [14:13:27 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:7829a712bb5a: avcodec/snowdec: Fix off by 1 error [14:13:28 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:0b37ae2ae475: avcodec/fic: Fixes signed integer overflow [14:13:29 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:079849f40c52: avcodec/me_cmp: Fix crashes on ARM due to misalignment [14:13:30 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:cab75cde0170: avcodec/aacdec_template: Fix running cleanup in decode_ics_info() [14:13:31 CEST] <cone-155> ffmpeg 03Vitaly Buka 07release/2.8:05fc22f9f69e: avformat/mov: Fix signed integer overflows with total_size [14:13:32 CEST] <cone-155> ffmpeg 03Vitaly Buka 07release/2.8:eaf231544f2f: avformat/aviobuf: Fix signed integer overflow in avio_seek() [14:13:33 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:ae37bbef4368: avcodec/hevc_ps: Check delta_pocs in ff_hevc_decode_short_term_rps() [14:13:34 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:c1a9f5675b95: ffprobe: Fix null pointer dereference with color primaries [14:13:35 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:49839ae0139c: ffprobe: Fix NULL pointer handling in color parameter printing [14:42:41 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:bc57c799704a: Update for FFmpeg 2.8.13 [14:47:35 CEST] <cone-155> ffmpeg 03Paul B Mahol 07master:f8d0689d3ff5: avfilter/vf_blend: rename addition128 and difference128 to grainmerge and grainextract [15:41:59 CEST] <J_Darnley> I hate this rate control crap in vc2enc. A circular dependency. You need to know how large the coded frame will be before you can code it. [15:43:27 CEST] <J_Darnley> All because a coded plane-slice uses single byte to show the size of itself. [15:44:03 CEST] <J_Darnley> So you need to scale scale the true size by some factor so that it is <= 255 [15:45:21 CEST] <J_Darnley> To know that factor you need to know how large the largest plane-slice will be. [15:56:01 CEST] <J_Darnley> I'm going to excise that slice byte counter [15:56:38 CEST] <BtbN> So you are essentially forced to do a full two-pass run? [15:57:44 CEST] <J_Darnley> Something like that, I think. [15:58:36 CEST] <J_Darnley> Fortunately The first pass only appears to count the bits [16:00:26 CEST] <J_Darnley> Also this links with the sliced multithreading it has: several independant PutBits are used and initialized to start at the right place in the output. [16:02:13 CEST] <kierank> J_Darnley: bear in mind in our use case each row needs to be the same size [16:02:16 CEST] <J_Darnley> Ah it is better after excising that count [16:03:05 CEST] <J_Darnley> kierank: at present it all appears to encode into the same size [16:03:10 CEST] <kierank> ok [16:06:48 CEST] <bove> I am writing a demuxer for SGO Mistika files. They mostly decode as rawvideo, but it supports some pixel formats I can't decode correctly. Should I be a) writing custom pixel formats, b) patching rawdec or c) writing a new decoder? [16:08:06 CEST] <bove> A few of them are stored as 3x10bits in a 32b DWORD. Can rawdec handle that? [16:08:55 CEST] <J_Darnley> We akready have some like that, v210 spring to mind. [16:08:59 CEST] <J_Darnley> *already [16:09:11 CEST] <bove> I'll have a look at that [16:09:33 CEST] <wm4> yeah, probably new raw decoder [16:09:50 CEST] <wm4> we try to avoid adding obscure raw codecs as pixfmts these days [16:10:15 CEST] <wm4> (thinhs like AV_PIX_FMT_BGR4_BYTE...) [16:10:18 CEST] <wm4> *things [16:10:44 CEST] <wm4> for 3x10 bits, it might actually be reasonable to add it as pixfmt [16:10:48 CEST] <wm4> as long as it's byte aligned [16:14:37 CEST] <bove> Yes. But I can't really understand the .comp part of the pixels format. Is it possible to define 3x10 plus padding in there? [16:17:29 CEST] <wm4> yes [16:17:49 CEST] <wm4> AV_PIX_FMT_AYUV64LE should be relatively similar [16:17:56 CEST] <wm4> just that it uses 8 bits per component [16:18:18 CEST] <wm4> the disadvantage with adding a new pixfmt is that you need to add support to libswscale.... [16:18:31 CEST] <wm4> a dedicated raw decoder might be simpler [16:21:49 CEST] <bove> If I do a custom decoder, I would just swap the bytes to match one of the existing pix_fmts, right? [16:22:07 CEST] <bove> I think the DPX decoder does the exact same thing [16:22:20 CEST] <wm4> yes [16:22:44 CEST] <wm4> considering that absolutely nobody hacks libswscale, that might be the easier route [16:22:53 CEST] <wm4> *nobody _likes_ to hack libswscale [16:24:17 CEST] <bove> Could I manipulate the data in the format's read_packet(), or is it better to do an encoder? [16:25:05 CEST] <wm4> I think you could do that [16:25:14 CEST] <wm4> maybe it's even preferable for something overly obscure [16:25:33 CEST] <wm4> but if the container can use multiple codecs, a separate decoder would be better [16:26:41 CEST] <bove> Ok. Thanks so far [16:34:22 CEST] <BBB> J_Darnley: does the second pass only affect the bitstream writing? or does it require a full new r/d loop? [16:34:30 CEST] <BBB> J_Darnley: or in other words, how big is the overhead? [16:34:34 CEST] <BBB> should be small [16:35:10 CEST] <J_Darnley> I don't know. [17:16:13 CEST] <wm4> kierank: nicolas george is offensive as usual, but to make an argument that does not aim to piss off everyone: we still could have --disable-libavformat or such, and libffmpeg would not contain the libavformat API [17:17:13 CEST] <kierank> true [18:43:09 CEST] <durandal_1707> see, that happens when you do not remove ffserver [19:01:48 CEST] <BBB> whos maintainer of ffserver again? [19:03:05 CEST] <wm4> BBB: reynaldo [19:11:13 CEST] <jamrial> ffserver hasn't been fixed after the whole vote-to-postpone-its-removal stuff last november, so it's going to be removed with the upcoming bump [19:11:41 CEST] <atomnuker> when is the next bump? [19:12:23 CEST] <jamrial> as soon as i get the help i requested on the ml, or once the merges resume and reach that point in the queue [19:13:30 CEST] <atomnuker> requested help? [19:13:40 CEST] <atomnuker> what do merges have to do with anything? [19:14:01 CEST] <jamrial> libav bumped major versions some months ago. the commit in question is in the merge queue [19:14:21 CEST] <jamrial> we can wait until that's merged, or we can bump at this point [19:15:43 CEST] <iive> there is somebody offerring a job to developer to maintain and fix ffserver [19:15:51 CEST] <iive> it's mail with "no subject" [19:16:12 CEST] <wm4> oh is that another reason to postpone removal of this POS [19:17:17 CEST] <jamrial> if someone magically fixes all ffservers problems in record time, then it can stay. but if not, it's going to be removed [19:17:36 CEST] <jamrial> it's been like nine months since the whole postponing vote stuff and nobody touched it any further [19:17:43 CEST] <jamrial> so i doubt it's going to be fixed [19:18:07 CEST] <iive> well, if nobody takes the offer, then ffserver is doomed. [19:19:18 CEST] <wm4> according to jamrial we're probably past this point [19:20:37 CEST] <iive> oh, so he is not project leader. Sorry I haven't got the memo. ~~ [19:20:45 CEST] <iive> not/now [19:21:19 CEST] <wm4> who is our project leader [19:21:30 CEST] <jamrial> i'm saying what the vote decided [19:21:47 CEST] <jamrial> if it was up to me, ffserver would have been removed in november [19:22:25 CEST] <jamrial> after the vote it was decided that if ffserver couldn't be fixed before the next bump, it would be removed [19:23:22 CEST] <iive> I thought it was fixed, that's why it remained. [19:23:36 CEST] <jamrial> no, it wasn't [19:24:26 CEST] <wm4> so let's hold another vote, where we decide to postpone ffserver removal again [19:24:34 CEST] <iive> i do remember people complaining that the inital plan was to fix the bugs and then remove it, but after the bugfixing people wanted to keep it. [19:24:37 CEST] <jamrial> I'd rather not [19:24:48 CEST] <iive> but maybe it's about different bugs [19:40:10 CEST] <kierank> 6:21 PM <wm4> who is our project leader [19:40:16 CEST] <kierank> he who shalt not be named [19:46:15 CEST] <wm4> if you mean HIM, he refuses that he is [19:54:15 CEST] <kierank> it's a fiat leader [19:54:17 CEST] <kierank> that's the problem [20:08:53 CEST] <BBB> VOLDEMORT [20:08:56 CEST] <BBB> so uh [20:09:03 CEST] <BBB> is voldermort attending VDD? :-p [20:09:08 CEST] <BBB> or how does this thing work [20:09:31 CEST] <BBB> is this like the shadow government, you have the minions feuding in public and the real power people staying behind the shades? [20:21:24 CEST] <BBB> [and there was silence] [20:22:40 CEST] <Compn> where are you reading this from bbb ? [20:22:48 CEST] <Compn> oh lol [20:22:53 CEST] <BBB> :-p [20:23:05 CEST] <Compn> kierank : you could nominate a leader and call a vote if you wanted [20:23:48 CEST] Action: Compn ducks [20:39:08 CEST] <cone-155> ffmpeg 03Paul B Mahol 07master:f0f48884b023: avfilter/af_sidechaincompress: switch to activate [20:39:38 CEST] <Compn> kierank : i mean you could nominate yourself if youwanted [20:52:04 CEST] <durandal_1707> im potter and you are voldemort [20:52:24 CEST] <jamrial> michaelni, durandal_1707: do you think you could remove coded_frame usage from vf_mcdeint and vf_uspp? they are apparently the only modules left using it [20:52:58 CEST] <durandal_1707> just remove it [20:53:23 CEST] <durandal_1707> nobody uses those voldermort filters [20:57:35 CEST] <BBB> I think we just created a new meme :-p [21:04:29 CEST] <wm4> I wonder if there's even a single user of those 2 filters [21:04:56 CEST] <wm4> or of they are just the forgotten dead pets of the original authors [21:08:35 CEST] <wbs> wm4: http://martin.st/temp/0001-Properly-specify-dllexport-for-data-symbols-shar… - proper use of dllexport doesn't seem to be insanely hard to do - this is only tested with msvc and in libav only, but should be a good base, in case you want to try to pursue this [21:09:32 CEST] <wm4> wbs: interesting [21:14:16 CEST] <BBB> wbs: oh wow thats pretty cool [21:15:13 CEST] <wbs> for ffmpeg, there seems to be a few av_export in libavutil as well so it has to be expanded to av_export_avutil, and perhaps the av_export_avcodec definition should be somewhere in libavcodec/*.h, but you get the idea [21:15:28 CEST] <michaelni> jamrial, i think these filters depend on the coded_frame API. Its possible to replace coded_frame with a different API of course but removing it without replacement would not work with the same efficiency [21:15:37 CEST] <wbs> (this was my 15 minute idea of derailing your fight by providing a different solution) :P [21:16:22 CEST] <jamrial> michaelni: so we just keep postponing the removal of coded_frame, then? [21:16:41 CEST] <wm4> jamrial: lol [21:16:47 CEST] <wm4> wbs: I thought it would be much more complex... anyway, would have to check whether it works with mingw as intended [21:16:52 CEST] <jamrial> i'm surprised it could be removed from every other decoder and filter but not these two... [21:17:07 CEST] <wm4> because they're filters ported from mplayer [21:17:17 CEST] <wm4> all you need to know [21:17:22 CEST] <michaelni> jamrial, these 2 actually acess the image [21:18:04 CEST] <michaelni> wm4, i dont think your mplayer reference is relevant or helpfull [21:19:02 CEST] <wm4> michaelni: I don't think your insistance to keep these filters combined with a refusal to fix them is helpful [21:19:58 CEST] <michaelni> wm4, please dont invent things about me [21:19:59 CEST] <wbs> wm4: yeah - I think it should work for mingw if you change the defined(_MSC_VER) into a defined(_WIN32), but the map of functions to export works a bit differently so something might come up, anyway, I'll leave the rest to you [21:20:23 CEST] <wm4> michaelni: I'm not inventing, but observing [21:20:37 CEST] <RiCON> wbs: as long as it doesn't break 'shared ffmpeg with static libs' even more than it is now [21:20:43 CEST] <jamrial> don't start a flame war for two filters, please [21:21:01 CEST] <wm4> yeah, let's choose a less optimal solution because of two filters instead [21:21:19 CEST] <RiCON> wbs: if some 3rd party lib uses dllimport, the .def only lists that lib's symbols, not ffmpeg's [21:21:47 CEST] <wbs> RiCON: with mingw? [21:21:50 CEST] <RiCON> yeah [21:22:01 CEST] <RiCON> specifically with "shared ffmpeg + static external libs" [21:22:10 CEST] <RiCON> static with static and shared with shared has no issues [21:22:36 CEST] <wbs> oh, then this will make the .def contain those dllexports from the external libs + dllexports for all the av_export data [21:23:01 CEST] <wbs> RiCON: if you want to fix that, hook up the script that we use for msvc to produce a def file prior to invoking the linker [21:23:46 CEST] <durandal_1707> isnt coded frame just to mark keyframes? [21:23:58 CEST] <wbs> actually, if you proceed with this dllexport patch with mingw in any normal case as well, you'll probably need to hook up that def script anyway [21:24:23 CEST] <michaelni> durandal_1707, the 2 filters access the actual pixels [21:24:45 CEST] <BBB> durandal_1707: it gives access to any portion of the compressed image (in decompressed form) [21:24:51 CEST] <BBB> durandal_1707: flags, pixels, etc. [21:25:17 CEST] <BBB> durandal_1707: think of it as the AVFrame if you decoded the compressed image again [21:25:48 CEST] <michaelni> jamrial, one could add a flag to the used encoder and return the internal bitmap in the avpacket if its set or maybe encode + decode to the the frame, later would be slower [21:26:09 CEST] <michaelni> then one could use that instead of coded_frame and remove it i think [21:27:16 CEST] <michaelni> maybe iam missing some magic simpler solution ... [21:28:09 CEST] <wm4> or we could just remove these obscure/rarely used filters that cause so much trouble [21:28:36 CEST] <BBB> just expose coded_frame in some internal form (codec-specific property, some internal api only for those encoders) [21:28:54 CEST] <BBB> I dont think anyone cares about coded_frame except for it being in AVCodecContext [21:28:55 CEST] <jamrial> we don't even know yet if dropping coded_frame as is will work even without considering those two filters [21:29:04 CEST] <BBB> if its anywhere else thats not AVCodecContext, I think nobody cares [21:29:26 CEST] <BBB> OneBigStruct { everything; // FIXME }; is not a good design ;) [21:29:44 CEST] <BBB> (remember dsputil? :D) [21:30:04 CEST] <BBB> o o o and mpegvideoenc!!!! woohoo \o\ /o/ \o/ [21:30:13 CEST] <BBB> (which was used in h264dec) [21:30:13 CEST] <jamrial> that one still exists, though :p [21:30:41 CEST] <BBB> michaelni: I think people are trying to make ffmpeg more maintainable, codec_frame is fine, just not in AVCodecContext [21:31:04 CEST] <BBB> michaelni: so just expose it as a codec-private option and I think youre fine [21:31:20 CEST] <BBB> (or as you said, side-data in a AVPacket) [21:31:32 CEST] <BBB> just not AVCodecContext [21:31:45 CEST] <michaelni> it should be something that doesnt require memcpy but is properly ref counted [21:32:10 CEST] <BBB> side-data refcounting sounds like a good idea [21:40:15 CEST] <iive> is codec_frame about keeping the quantizers of macroblocks? [21:43:41 CEST] <iive> no, it isn't [23:23:42 CEST] <jamrial> alright, libavcodec compiles after a bump and fate passes. we only need to fix or postpone at most four deprecated apis/functionality older than two years [23:35:16 CEST] <nevcairiel> Why do filters even have access to AVCodecContext in the first place, that seems wrong on do many levels [23:36:30 CEST] <jamrial> that's what BBB was saying. coded_frame doesn't need to be in avcodeccontext [23:37:17 CEST] <BBB> struct OneBigThing { everything; /* FIXME */ }; <- ffmpeg [23:38:07 CEST] <nevcairiel> How do they get to that context even? Do they make their own? [23:38:52 CEST] <nevcairiel> Would definitely be nice to get rid of coded_frame, at least from that public struct [23:41:29 CEST] <jamrial> nevcairiel: the two filters above do that, yes. alloc, open2, encode2, then look at coded_frame [23:42:10 CEST] <nevcairiel> Is the content of that different then the frame they input? [23:42:30 CEST] <nevcairiel> Seems a bit silly considering they originally had the frame :p [23:44:53 CEST] <nevcairiel> But side_data is recounted so (optionally) attaching it there might work [23:45:38 CEST] <nevcairiel> Or wait, maybe sidedata wasn't refcounted [23:45:43 CEST] <nevcairiel> I forget [23:58:46 CEST] <iive> they don't want the input frame, they want the frame that is the result of encoded and then decoded frame. [23:59:48 CEST] <iive> decoding is part of the encoder, as they need the reference frames. [00:00:00 CEST] --- Fri Aug 25 2017

1 0

ffmpeg.log.20170824
by burek 25 Aug '17

25 Aug '17

[00:07:00 CEST] <furq> otherwise there's only one audio stream [00:09:40 CEST] <c7j8d9> oh i see furq so can I -map 0:1 -map 0:a to copy one stream out of multiple? [00:09:59 CEST] <furq> 0:a:0 [00:10:03 CEST] <furq> or whichever stream it is [00:10:27 CEST] <furq> https://www.ffmpeg.org/ffmpeg.html#Advanced-options [00:11:08 CEST] <c7j8d9> perfect! thanks furq [00:36:28 CEST] <Cracki> kepstin, who's dealing with 4K content and still operating under 32 bit? [00:37:05 CEST] <kepstin> people who accidentally download 32bit builds of ffmpeg rather than 64bit ones, mostly. [00:37:24 CEST] <Cracki> I demand 16 bit builds [00:38:10 CEST] <Cracki> I need my ancient cnc machine with parallel port to cut movie frames into papyrus [00:44:28 CEST] <grublet> Cracki: i thought i was the only one [00:44:47 CEST] <Cracki> <3 I love audible pulse frequencies [00:48:36 CEST] <FishPencil> Is there a way to set the --install-name-dir for the output libs to @loader_path? [01:57:33 CEST] <leif> Can anyone tell me when I should use the AVFMT_* macros vs the AVFMT_FLAGS_* macros? [01:58:34 CEST] <leif> I ask because it looks like AVFMT_* works for the AVFormatContext's 'flags' field, but the AVFMT_FLAGS_* macros appeaer right next to it. [02:01:39 CEST] <commanderkeen> i wrote some code to take an input, demux, decode the video, run it through filter graph, encode it, then mux it to a file. it works other than i think my timestamps are messed up. ffmpeg - says the new video duration is 121:21:12.47 and the original is 0:0:14.08. any suggestions debugging the time issues? [02:02:18 CEST] <commanderkeen> im getting the frame-rate from the original stream [02:02:37 CEST] <commanderkeen> and time base [02:05:04 CEST] <ankitbehera2670> hi [02:05:22 CEST] <ankitbehera2670> I am a beginner in ffmpeg [02:05:34 CEST] <ankitbehera2670> I want to use ffmpeg with c [02:05:38 CEST] <leif> Ah, okay, it looks like AVFMT_* is for the AV(Input/Output) contexts. [02:06:18 CEST] <ankitbehera2670> to write programs [02:06:43 CEST] <commanderkeen> ankitbehera2670: have you looked at the examples? [02:06:56 CEST] <ankitbehera2670> which examples [02:07:40 CEST] <commanderkeen> ankitbehera2670: https://www.ffmpeg.org/doxygen/3.0/examples.html [02:09:00 CEST] <ankitbehera2670> ok, I saw those examples [02:09:28 CEST] <ankitbehera2670> but I wanted to find out a way to use those old source codes [02:09:34 CEST] <ankitbehera2670> in dranger.com [02:09:57 CEST] <commanderkeen> what do you mean find out a way to use them? [02:10:46 CEST] <ankitbehera2670> I heard that pixel formats have been prefixed with AV_, and the PIX_FMT_* defines were moves to libavutil/old_pix_fmts.h [02:11:04 CEST] <ankitbehera2670> I don't know it is true or not [02:54:09 CEST] <Diag> can ffmpeg delay audio [02:54:22 CEST] <Diag> For whatever reason my audio channel is ~5seconds fast [02:58:20 CEST] <klaxa> see -itsoffset maybe? [02:59:33 CEST] <klaxa> or the apad filter [03:08:56 CEST] <Diag> erm [03:09:08 CEST] <Diag> ill have a look [03:32:33 CEST] <durandal_1707> Diag: adelay filter [03:33:07 CEST] <Diag> durandal_1707: how did you see my message [03:34:29 CEST] <durandal_1707> Diag: im allseeing [03:34:47 CEST] <Diag> deleting ffmpeg now thanks [03:56:39 CEST] <alexpigment> what does avresample do? [03:56:48 CEST] <alexpigment> do I need to build with it? [03:57:17 CEST] <durandal_1707> no [03:57:41 CEST] <alexpigment> short and simple answer :) thanks durandal [03:58:30 CEST] <durandal_1707> its swresample like library for libav folks only [04:12:12 CEST] <alexpigment> durandal_1707: that was what I gathered from reading about it - I just needed to confirm to be on the safe side [04:12:15 CEST] <alexpigment> thanks again [04:54:50 CEST] <cryptodechange> DBZ bluray test (will probably need to DL as the preview video is compressed)... https://drive.google.com/open?id=0B6rDPzFC8IitYm1CSG02Z3gta2M (original) | https://drive.google.com/open?id=0B6rDPzFC8IitTlRHNTd6ZDVBLW8 (denoise/sharpened) [04:55:00 CEST] <cryptodechange> Not sure what to do with the 'frame shake', is it more noticeable in the denoised version? [05:09:22 CEST] <dan2wik> Is there a way I can compile ffmpeg faster? [05:09:48 CEST] <dan2wik> I'm compile on a Pi 0 because cross compiling doesn't seem to be working [05:10:13 CEST] <dan2wik> I don't know how much time it takes to compile them, but I don't need ffplay or ffserver [06:38:03 CEST] <lioz_tandil> Hi, I need help with commands of ffmpeg. I need record a streaming of camera ip to mp4 using h264, but i need generate files *.mp4 with fixed duration in seconds. How can i do? [06:41:21 CEST] <lioz_tandil> Any kind soul? :) [07:07:41 CEST] <dan4wik> How do i use the -listen argument? [07:12:11 CEST] <dan4wik> Alternatively, how would I go about listening for a connection for input? [07:13:29 CEST] <dan4wik> If ffmpeg accepts input from stdin, I could get that going too. [12:44:18 CEST] <jya> is there a way to set ffmpeg (ffplay / ffprobe) to print the http headers being sent and received? [13:10:48 CEST] <Nacht> jya: I see HTTP headers when I use '-v 56' with ffmpeg [13:11:00 CEST] <jya> Nacht: thanks will try [13:13:39 CEST] <JEEB> why would you use the numeric value :< [13:13:53 CEST] <JEEB> -v debug is much more readable, for example [13:14:12 CEST] <jya> easier to remember maybe ? :) [13:14:19 CEST] <jya> less character to type [13:14:46 CEST] <jya> just wondering why our code get a moved temporarily error when doing a range request, but it works fine with ffmpeg [13:26:24 CEST] <jcelerier1> hi :) [13:27:16 CEST] <jcelerier1> what could be the cause of an error -11 (resource temporarily unavailable) upon av_send_packet ? I'm just trying to read a .aiff file and it reads approximately the first thousand samples then fails with this [13:29:43 CEST] <jya> jcelerier1: increase the verbosity, you will see what the server responds with. (assuming you read over http) [13:31:03 CEST] <jcelerier1> no, it's a local file [13:31:23 CEST] <jcelerier1> this is my decoding code: https://github.com/OSSIA/i-score/blob/master/base/plugins/iscore-plugin-med… [13:35:08 CEST] <JEEB> umm [13:35:32 CEST] <JEEB> jcelerier1: try printing out the `av_err2str(return_code)` [13:36:11 CEST] <JEEB> I'm pretty sure you're actually getting EAGAIN [13:37:20 CEST] <JEEB> or well, check it against AVERROR(EAGAIN) [13:37:39 CEST] <jcelerier1> ah yes JEEB, that's it [13:37:40 CEST] <JEEB> and see the documentation on the send/receive stuff :P [13:38:10 CEST] <JEEB> it means that "I still have something stuck in my buffers so try the other side and then come back with that packet" [13:39:09 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [13:39:13 CEST] <jcelerier1> yep [13:39:13 CEST] <JEEB> relevant documentation [13:39:37 CEST] <jcelerier1> hmmm, so if I call avcodec_receive_frame(...) just afterwards I am greeted with "Invalid PCM packet, data has size 1 but at least a size of 4 was expected" [13:40:29 CEST] <jcelerier1> maybe I should go the other way [13:40:54 CEST] <jcelerier1> and try to read everything before calling av_send_packet ? [15:59:08 CEST] <hamersaw> i'm looking to check the integrity of a few movies files that i suspect have been corrupted on a file transfer. i can manually execute the command in the terminal and it works fine, but when i try to script it the movie is sent to stdout (or written to the log file) what am i doing wrong? [15:59:28 CEST] <hamersaw> ffmpeg -v error -i FILE -f null - 2> /tmp/log [15:59:47 CEST] <hamersaw> obvioulsy FILE is the the video file and /tmp/log changes for each iteration [16:03:41 CEST] <tezogmix> Any ideas on how to resolve an audio out of sync when converting a 50fps video to 25fps mp4? Normally, I've been able to do it fine without issue with: "ffmpeg -r 50 -i input.mp4 -preset veryfast -crf 15 -r 25 -c:a copy output.mp4" I checked the source to see if it was out of sync but it's not. [16:06:37 CEST] <BtbN> Why are you overriding the input framerate? [16:06:48 CEST] <BtbN> If it's not actually 50fps but something slightly different, that could easily cause your desync. [16:08:34 CEST] <tezogmix> hey BtbN , it was for a specific device that couldn't handle framerates over 30fps... so i've been having success with changing them on sources that were 60fps (e.g. 60000/1001 to 30000/1001 or 60 to 30 or 50 to 25) [16:08:53 CEST] <devinheitmueller> tezogmix: I agree with BtbN. Unless the input.mp4 is somehow broken, get rid of the first -r 50. [16:09:30 CEST] <BtbN> If it's an input device, that -r won't override the framerate but set it. [16:09:43 CEST] <BtbN> For a video file input, it will plain override the actual framerate. Get rid of it and try again. [16:10:26 CEST] <tezogmix> ah ok devinheitmueller & BtbN , so for future reference that initial "-r" prior to input file doesn't need to be there? [16:10:41 CEST] <BtbN> It's a very bad idea to have it there. [16:11:11 CEST] <devinheitmueller> Correct. The order of arguments with ffmpeg is very important. Having a -r 50 before the -i input.mp4 means to treat input.mp4 as 50 FPS regardless of what the actual files framerate is. [16:11:29 CEST] <tezogmix> ok i see, i was just following some random command lines i had seen over the months, it didn't seem to be a problem with the other conversions i've done (probably over 50 times now) [16:11:47 CEST] <devinheitmueller> The second -r 25 in your command line is what you want, since that will mean to take whatever the source framerate in the file is and make it 25 fps. [16:12:17 CEST] <tezogmix> ok, i did learn about halving or keeping the framerate changes in direct integers [16:12:29 CEST] <devinheitmueller> If the input.mp4 *really* is 50 FPS, then it probably wont matter. But as soon as you provide an input file which is 29.97 or some other framerate you will have an avsync problem. [16:13:04 CEST] <BtbN> and a way too slow or fast video [16:13:04 CEST] <tezogmix> maybe it was a build issues, normally i update it before running but haven't updated ffmpeg in the last few weeks [16:14:00 CEST] <tezogmix> any other info i can share of the input source that we could keep in mind (aside from removing the initial "-r 50") from mediainfo utility? [16:14:45 CEST] <devinheitmueller> Unless the source is known to be broken, you should generally trust ffmpeg to properly figure out the properties of the input. [16:20:18 CEST] <tezogmix> I just posted the mediainfo details here on pastebin (not sure if you all notice anything in particular to adjust into the command line conversion): https://pastebin.com/SwubLjKh [16:20:49 CEST] <tezogmix> it was just a simple conversion meant only to lower the framerate and keep everything else as is. [16:21:10 CEST] <devinheitmueller> Is that really 1080p/50 content? Or did it just get improperly encoded and its really 1080i/50? [16:22:04 CEST] <tezogmix> no idea devinheitmueller , that's how it is... i don't know what the source creator intended. [16:22:44 CEST] <tezogmix> source plays fine on vlc/mpc-hc [16:32:45 CEST] <tezogmix> anyways, i downloaded the new ffmpeg build, got another source of same input file again and re-running this with your suggestions of removing that initial -r, thanks devinheitmueller & BtbN [16:33:48 CEST] <tezogmix> have a good rest of your day/evening! [17:10:49 CEST] <jcelerier1> how safe is it to have multiple resamples operating at the same time ? [17:11:51 CEST] <klaxa> i don't see why it should be unsafe [17:23:37 CEST] <alexpigment> hey guys [17:24:12 CEST] <alexpigment> when using h264_qsv, if the system has an intel graphics card but it's not being used (no display attached), the qsv encoder will say that it's using partial acceleration and be really slow [17:24:31 CEST] <alexpigment> is there a way to make this warning an actual error that prevents the encoding from occurring? [17:24:51 CEST] <alexpigment> in my tests, "partial acceleration" is always significantly slower than x264 [17:30:10 CEST] <redrabbit> wondering if there is hardware encoders on my 6600k i could use [17:30:20 CEST] <alexpigment> yes, there definitely is [17:30:23 CEST] <alexpigment> you have quicksync [17:30:26 CEST] <jkqxz> alexpigment: Why would the presence of a display make a difference? Does that actually mean "is running X and therefore some default device is found"? [17:30:54 CEST] <alexpigment> jkqxz: i don't know. it's a dumb system to be honest [17:30:57 CEST] <alexpigment> but it's how it works [17:31:15 CEST] <redrabbit> atm i use ndivia hw encoders [17:31:20 CEST] <alexpigment> like right now I can simulate this by having an nvidia card running the display but the intel GPU enabled [17:31:31 CEST] <redrabbit> is there much of a difference between theses and intel [17:31:44 CEST] <alexpigment> redrabbit: you can't generally use them both (with full acceleration) unless you have a display hooked up to both [17:31:53 CEST] <alexpigment> redrabbit: nvenc is way better and faster [17:32:07 CEST] <redrabbit> no need to bother then i have nvenc setup [17:32:08 CEST] <jkqxz> alexpigment: You should be able to specify the device to avoid that problem. [17:32:16 CEST] <alexpigment> jkqxz: this is not for me [17:32:25 CEST] <alexpigment> this is for an unknowable set of systems and hardware configs [17:34:40 CEST] <jkqxz> Right. Then using libmfx is quite a pain, yeah. [17:36:28 CEST] <jkqxz> You could easily hack the source code to error out immediately in the case you described above. Message is at <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/qsvenc.c#l768>, can probably just return an error there. [17:41:12 CEST] <alexpigment> Thanks for the heads up [17:41:27 CEST] <alexpigment> I'm already doing a check to see if a test encode succeeds or fails, then enabling the option accordingly [17:41:33 CEST] <alexpigment> Because it's a warning, it technically succeeds [17:41:53 CEST] <alexpigment> I was just hoping there was an option you could put in the ffmpeg command line that effectly just treats warnings as fatal [17:42:00 CEST] <alexpigment> It sounds like there isn't though... [18:38:05 CEST] <Camusensei> Hello guys. I am struggling with .MTS files, I cannot get the audio out, what do you need? A dump of a ffprobe file.MTS? [18:39:15 CEST] <c_14> it'd be a start [18:41:02 CEST] <Camusensei> with output? [18:41:32 CEST] <c_14> the console output yeah (it usually lists errors etc) [18:41:38 CEST] <c_14> and it'll include the codecs in the file etc [18:43:07 CEST] <Camusensei> http://sprunge.us/YAIf [18:44:03 CEST] <c_14> Are you sure the input has audio? [18:45:03 CEST] <c_14> And apparently that's not MTS, it's a tele-typewriter file [18:45:53 CEST] <Camusensei> yeah, it contains a bunch of files and I' sure they have audio in them [18:46:17 CEST] <c_14> "it contains a bunch of files" [18:46:24 CEST] <c_14> Is it supposed to be a playlist? [18:46:37 CEST] <Camusensei> yes [18:46:56 CEST] <Camusensei> file 'file1.MTS' and so on [18:47:03 CEST] <c_14> The only playlists ffmpeg supports are hls and concat [18:47:07 CEST] <c_14> aah, add -f concat before -i [18:47:19 CEST] <Camusensei> http://sprunge.us/OQRA is an example [18:47:28 CEST] <Camusensei> oooh [18:47:30 CEST] <Camusensei> I see [18:49:37 CEST] <Camusensei> Yes, it works now, thank you very much!!!! [18:53:07 CEST] <c_14> np [19:22:07 CEST] <alexpigment> jkqxz: I edited the source code, but it doesn't error out, unfortunately [19:22:31 CEST] <alexpigment> It gives an error, sure, but it still goes through the process of creating the file [19:23:25 CEST] <alexpigment> Does anyone else know how to make ffmpeg fail when an error is encountered? [19:24:00 CEST] <alexpigment> The error in particular is: "[h264_qsv @ 0021fce0] Encoder will work with partial HW acceleration" [19:26:07 CEST] <furq> maybe -xerror [19:26:12 CEST] <furq> i forget if that bails out on any warning though [19:26:26 CEST] <kepstin> that's not an error, yeah, it's just a warning. [19:26:38 CEST] <alexpigment> I tried xerror [19:26:51 CEST] <alexpigment> kepstin: well, I changed qsvenc.c to make it a warning [19:26:52 CEST] <kepstin> would need special handling added to the qsv encoder to abort when a software fallback is used [19:26:59 CEST] <alexpigment> er [19:27:00 CEST] <alexpigment> rather, [19:27:07 CEST] <alexpigment> i changed it from a warning to an error [19:27:31 CEST] <alexpigment> this qsv encoder implementation is just a mess [19:29:32 CEST] <alexpigment> At any rate, here's the area in the code that I changed: https://pastebin.com/1pEyEbAF [19:29:54 CEST] <alexpigment> I just changed AV_LOG_WARNING to AV_LOG_ERROR [19:30:02 CEST] <alexpigment> that obviously just changes the color from yellow to red [19:30:11 CEST] <alexpigment> is there any way to make it fail if it gets that [19:30:23 CEST] <kepstin> alexpigment: you need the encoder function in the qsvenc.c file to return an error code to libavcodec [19:32:08 CEST] <alexpigment> do you think removing lines 3 and 4 would do the trick? [19:32:16 CEST] <alexpigment> i don't really care if the error is accurate. i just need it to be fatal [19:33:27 CEST] <kepstin> just add a "return AVERROR(EINVAL);" after your log message print [19:33:55 CEST] <kepstin> or whatever other error code you feel like [19:34:11 CEST] <alexpigment> so the next line after the semicolon? [19:34:27 CEST] <alexpigment> (i'm not a programmer - sorry for the dumb question) [19:34:30 CEST] <kepstin> between lines 3 and 4 in your paste, yeah [19:34:34 CEST] <alexpigment> cool [19:34:41 CEST] <alexpigment> i'll try it [19:34:43 CEST] <alexpigment> thank you very much [20:02:32 CEST] <alexpigment> kepstin: you just saved me hours of headache. thank you very much again [21:06:42 CEST] <thebombzen> if I'm trying to do a bit of editing on 44.1 kHz audio (specifically afade), should I use aresample=48k before or after the other effects? [21:07:58 CEST] <furq> huh [21:08:04 CEST] <ChocolateArmpits> thebombzen, there's nothing about that filter that would require 48kHz audio. Do you expect 48kHz output or something ? [21:08:23 CEST] <thebombzen> yea, if I want to do anything with it like encode it to Opus [21:08:26 CEST] <furq> yeah you don't need to do that and if you want to do that for some other reason then i would assume it makes no difference [21:09:10 CEST] <thebombzen> the reason I'd ask is if I want to encode it to Opus, it'll have to be 48 kHz anyway. I was wondering if there might be a reason to resample it beforehand [21:10:21 CEST] <furq> i mean i guess it might make the fade slightly higher quality [21:10:26 CEST] <furq> it won't be audible though [21:10:57 CEST] <ChocolateArmpits> the effect processing result won't be distorted [21:11:08 CEST] <ChocolateArmpits> but yeah, don't expect to hear anything [21:11:20 CEST] <furq> i wouldn't bother [21:11:51 CEST] <furq> especially not if you're not definitely going to encode this to opus [21:11:56 CEST] <furq> and do nothing else with it [21:13:15 CEST] <TD-Linux> thebombzen, there is no difference unless the intermediate filters are poor quality [21:13:43 CEST] <thebombzen> alright thanks [21:13:58 CEST] <furq> especially if you don't actually know if you're going to have to resample it to 48k [21:14:09 CEST] <thebombzen> well I do actually know that [21:14:20 CEST] <furq> you sounded very speculative when you mentioned opus [21:14:29 CEST] <thebombzen> that was just a hypothetical example [21:14:35 CEST] <thebombzen> I'm combing it with other mostly 48 kHz audio in an NLE [21:14:46 CEST] <furq> if you're definitely resampling to 48k then it couldn't hurt to do it first [21:14:56 CEST] <thebombzen> and I'm going to export it and UL it to YouTube later [21:15:06 CEST] <thebombzen> which will resample it to 48 kHz for Opus [21:15:37 CEST] <ChocolateArmpits> and libvorbis and aac [21:15:58 CEST] <ChocolateArmpits> multiple formats there [21:16:58 CEST] <furq> vorbis and aac will be 48k if the source is [22:13:56 CEST] <leif> Does FFMPEG compile with pthreads by default in os x? (The build I'm using didn't have the --enable-pthreads flag: https://gist.github.com/LeifAndersen/074d6e4b3246daa2658374a8eac2b8b6 ) [22:14:32 CEST] <BtbN> I'd guess pthreads are autodetect [22:17:08 CEST] <leif> BtbN: okay, thanks. [23:20:37 CEST] <squarecircle> ohai [23:21:08 CEST] <squarecircle> is there a way to see if my ffmpeg instance is using the graphics card for accelerated decoding? [23:22:07 CEST] <squarecircle> if I start multiple instances, and I have multiple graphic cards, do they access one card or does they are distributed on the cards? [23:23:59 CEST] <squarecircle> at the moment, I am calling ffmpeg on a server without real graphics card, only contains a MGA G200EV [23:24:15 CEST] <squarecircle> the vm I'm testing the code only uses the virtualized grpahics adapter [00:00:00 CEST] --- Fri Aug 25 2017

1 0

ffmpeg-devel.log.20170823
by burek 24 Aug '17

24 Aug '17

[00:52:23 CEST] <BBB> lots of ffmpeg devs in that demuxed conference speaker schedule :-o [00:53:01 CEST] <JEEB> yup [00:53:07 CEST] <JEEB> some promising talks [01:33:08 CEST] <Compn> the talks are very informative :) [01:33:16 CEST] <Compn> fun audience participation sometimes :) [02:27:21 CEST] <tdjones> What is the preferred way for me to send additional patches based off previous commits already sent to the mailing list? I don't want to spam the ML with patches that don't change for each time there is additional commits in the series, but I'd like to provide as much time as possible for comment before the end of GSoC. [02:28:08 CEST] <atomnuker> tdjones: reply to the original patch emails you send with a v2 [02:28:21 CEST] <atomnuker> you can supply git send-email with their message ids [02:28:31 CEST] <atomnuker> though you'll need to send them one at a time [02:29:27 CEST] <tdjones> You want me to resend them all with v2, even if there are just 2 separate additional patches included? [02:29:51 CEST] <tdjones> If I'm understanding you correctly [02:30:31 CEST] <atomnuker> tdjones: no, just the ones you want to replace [02:31:33 CEST] <tdjones> I'm not replacing any, they are additional patch files based as if the previous commits were HEAD but have no other relation [02:31:36 CEST] <atomnuker> (you can also just reply to them with new attached .patch files) [02:31:42 CEST] <atomnuker> oh [02:32:15 CEST] <atomnuker> just send them directly (if you want you can specify the original root email's message id so they appear under the same thread) [02:32:31 CEST] <tdjones> Alright, just wanted to check. Thanks [02:37:28 CEST] <tdjones> atomnuker: If you or any of the GSoC admins here have the time to verify that my gsoc submission post is acceptable, I'd greatly appreciate it. https://tjones879.github.io/blog/gsoc-2017/ [02:37:54 CEST] <tdjones> Just some time before the final deadline [03:18:19 CEST] <cone-349> ffmpeg 03Vitaly Buka 07master:8c2bb10ddfef: avcodec/utils: Fix signed integer overflow in rc_initial_buffer_occupancy initialization [03:18:19 CEST] <cone-349> ffmpeg 03Vitaly Buka 07master:4a404cb5b90b: avformat/mov: Fix signed integer overflows with total_size [03:18:19 CEST] <cone-349> ffmpeg 03Vitaly Buka 07master:eca2a49716ae: avformat/aviobuf: Fix signed integer overflow in avio_seek() [11:08:03 CEST] <zetax> hi, where can I get more info about this? I wanna look into if I could help "Currently its in development and only implements the CELT part of the codec. Its quality is usually worse and at best is equal to the libopus encoder." https://ffmpeg.org/ffmpeg-codecs.html#opus [11:08:44 CEST] <kierank> ask atomnuker [11:09:21 CEST] <zetax> atomnuker: see question about .opus above [11:18:52 CEST] <wm4> man I hate libavformat's probing so fucking much [11:19:13 CEST] <wm4> now it's an excuse for hardware decoders not to parse and export certain bitstream data, like colorimetry data [11:19:30 CEST] <nevcairiel> how is that related [11:19:32 CEST] <wm4> because libavformat does that anyway by calling back into libavcodec! trollol [11:19:47 CEST] <wm4> nevcairiel: they rely on the libavformat data [11:20:07 CEST] <nevcairiel> so tell them they're full of shit and avcodec decoders should be standalone =p [11:20:28 CEST] <wm4> just what is mentally wrong with these hardware decoder people that they can write entire decoders with hardware support, but fail at things this simple, like a bit of parsing [11:20:54 CEST] <nevcairiel> how is that any decent design, hey we rely on someone else giving us these information, if they don't, well, tough! [11:21:39 CEST] <nevcairiel> (also, thats why i like actual hwaccels, they just work with all sorts of crazy metadata) [11:22:17 CEST] <wm4> yeah [13:28:24 CEST] <wm4> if (fctx->next_decoding > (avctx->thread_count-1-(avctx->codec_id == AV_CODEC_ID_FFV1))) [13:28:26 CEST] <wm4> just what [13:28:40 CEST] <BBB> hahahahaha [13:28:46 CEST] <BBB> Ive posted that a few times also [13:28:57 CEST] <BBB> theres a few of them in different places, also [13:28:59 CEST] <BBB> anyway [13:29:04 CEST] <BBB> good luck fixing the unfixbal [13:29:07 CEST] <BBB> unfixable [13:29:44 CEST] <BBB> wm4: about your patch for mingw, I personally dont really like getter functions, but if the public API already uses that then it makes sense to reproduce that in the private API, so I wouldnt loudly object to it (I still dont like it) [13:31:06 CEST] <wm4> alternative solutions: remove all avpriv variables (unfixable), make libs buildable as single DLL/so (seems more realistic) [13:31:37 CEST] <BBB> we could also use dllexport/import correctly [13:31:52 CEST] <BBB> (although highly unlikely anyone actually wants to do the work required for that) [13:32:22 CEST] <wm4> that seems very hard [13:32:25 CEST] <BBB> it is [13:32:27 CEST] <wbs> would it work just the way we do it for msvc right now though? [13:32:30 CEST] <BBB> but Ive seen some libs do it correctly [13:32:35 CEST] <wm4> wbs: only for MSVC [13:32:37 CEST] <BBB> so its not impossible [13:32:45 CEST] <wm4> wbs: mingw doesn't support it this way [13:32:52 CEST] <wbs> wm4: ah, bummer [13:32:58 CEST] <nevcairiel> its not that hard, the effort is just exaggerated because we have 10 individual libs, instead of just one [13:32:59 CEST] <wm4> BBB: it's extremely hard for us, though [13:33:04 CEST] <BBB> I suppose [13:33:20 CEST] <BBB> Im not telling you to do it :-p Im saying your patch is probably fine [13:33:28 CEST] <wm4> unless maybe you define 10 av_export and av_import symbols, for each lib [13:34:02 CEST] <nevcairiel> yeah you need one av_export per library, so av_export_avcodec etc [13:34:05 CEST] <wm4> err, no av_import symbols, just av_export would have to switch between dllimport/export depending on context [13:34:09 CEST] <wm4> yes [13:34:30 CEST] <wm4> within libavcodec, av_export_avcodec would map to dllexport [13:34:36 CEST] <wm4> and outside to dllimport [13:34:56 CEST] <nevcairiel> thats how you're supposed to do it, just that this is typically with one library, not ten [13:35:04 CEST] <wm4> or maybe a special export header [13:35:21 CEST] <BBB> its not that much code honestly [13:35:24 CEST] <BBB> its just super-tedious [13:35:25 CEST] <iive> it's possible to remove all avpriv, by duplicating them in each library and not sharing/showing them. [13:35:34 CEST] <wm4> libavcodec/exports.h, which contains "#undef av_export #define av_exprt ..." and then hope for the best [13:35:37 CEST] <BBB> nobody likes doing tedious work [13:35:39 CEST] <iive> since they are all constants [13:37:19 CEST] <wm4> can we have the following policy: if someone wants to add new avpriv variables, he has to go through a klingon pain stick ritual involving all other ffmpeg developers [14:57:50 CEST] <wm4> when can we get rid of the J bullshit pixfmts? got another bug due to them [00:00:00 CEST] --- Thu Aug 24 2017

1 0

ffmpeg.log.20170823
by burek 24 Aug '17

24 Aug '17

[00:12:42 CEST] <Fenrirthviti> Is there an option for a custom vbv buffer size for NVENC? [00:14:55 CEST] <bigpresh> I'm trying to get ffmpeg to receive an RTSP feed from a camera and send it to ffserver; I'm using `ffmpeg -i rtsp://... http://127.0.0.1:8090/feed1.ffm`, and getting "Error while opening encoder for output stream #0:1 - maybe incorrect parameters such as bit_rate, rate, width or height" [00:15:12 CEST] <bigpresh> Is there a way to say "just use the bitrates etc of the RTSP stream"? [00:16:19 CEST] <alexpigment> Fenrirthviti: I've used -bufsize and -maxrate with nvenc in the past [00:16:50 CEST] <alexpigment> It's possible it ignored the parameters (it's been a while since I tested), but it didn't throw any errors and I believe it actually honored them [00:17:13 CEST] <Fenrirthviti> I have a few users who claim that streaming to an nginx-rtmp server with a vbv buffer of over 7k causes disconnects [00:17:21 CEST] <Fenrirthviti> I'm 99.9% sure they're full of shit, but, whatever. [00:17:32 CEST] <Fenrirthviti> I regularly stream to mine at 35-40k with no custom buffers set :\ [00:18:13 CEST] <alexpigment> Yeah, I'm not sure what would cause that. But either way, it's worth trying and confirming (or calling bullshit) [00:21:10 CEST] <bigpresh> (I've tried '-codec copy' which I would hope would copy all details of the codecs for each stream, but that may well be a misunderstanding of how it would work) [00:29:20 CEST] <kepstin> bigpresh: "-codec copy" tells ffmpeg to literally just copy the already encoded data from the input to the output, rather than decoding it, filtering, then re-encoding. [00:30:21 CEST] <kepstin> bigpresh: that said, you're unlikely to get help with ffserver here, very few people use it and it's basically unmaintained :/ [00:32:29 CEST] <bigpresh> Oh, really? Arse. [00:33:30 CEST] <bigpresh> Any recommendations on something similar that's actively maintained? Basically, I want to grab video & audio from a couple of IP cameras to a central box that can then re-stream them, as that box has much better network link than the cameras do [00:33:42 CEST] <bigpresh> (and the poor little things don't handle multiple viewers of their streams well :) ) [00:34:52 CEST] <klaxa> you could *try* my mkv server [00:35:10 CEST] <klaxa> https://github.com/klaxa/mkvserver_mk2 [00:35:42 CEST] <klaxa> or nginx-rtmp or hls with a webserver [00:36:39 CEST] <bigpresh> Interesting, thanks - I shall look in to those [00:37:08 CEST] <bigpresh> I started setting up ZoneMinder, figured that would be good - then realised I need audio :) [00:41:49 CEST] <bigpresh> I shall have a look at all of those optoins; nginx-rtmp stands out as maybe the easiest, and I'm already running nginx :) [00:42:29 CEST] <klaxa> hls should be similarily easy [06:18:19 CEST] <dafna_> Hi, if I set my own get_buffer2 when decoding a video [06:18:32 CEST] <dafna_> and I also use multithreaded, [06:19:10 CEST] <dafna_> that is thread_count in the avcodeccontext is > 1 [06:19:26 CEST] <dafna_> the n I need to handle my program with locks ? [08:00:20 CEST] <crux0> Anyone know if ffmpeg has support for FastTracker files? I've downloaded a whole bunch of chiptune mods, and many of them are still in fasttracker format. I'm trying to play them using mpv, but ffmpeg doesn't seem to natively support .ft [10:30:40 CEST] <thebombzen> uh, I just had FFmpeg default to aac for a webm encode [10:30:42 CEST] <thebombzen> is this a bug? [10:32:22 CEST] <JEEB> thebombzen: sounds like either your FFmpeg is old enough or you're not picking the webm mode correctly in matroskaenc [10:32:31 CEST] <JEEB> see around line 1288 in matroskaenc.c [10:32:33 CEST] <thebombzen> I built it recently [10:32:50 CEST] <thebombzen> also this is ffmpeg.c, so I shouldn't have to use this [10:32:54 CEST] <JEEB> if (mkv->mode == MODE_WEBM && !(par->codec_id == ....) [10:33:11 CEST] <JEEB> there's a definite avcodec check there for the thing you're trying to push in there [10:34:08 CEST] <thebombzen> hm, I can't reproduce [10:34:17 CEST] <thebombzen> ah, gg, I had -c copy and no -c:a [10:34:28 CEST] <thebombzen> closed: resolved. resolution: user is a dumb [10:53:45 CEST] <fbeaufort> Hello everyone! I'd like to convert "properly" a mp4 file to flac file. [10:53:45 CEST] <fbeaufort> The audio flac file I get can be read in Google Chrome but not in Firefox. [10:53:45 CEST] <fbeaufort> Firefox folks tell me it's because the "SampleDescriptionBox" reads 0 for the samplerate and it must be a valid value. [10:53:45 CEST] <fbeaufort> Would you happen to know how I can set the SampleDescriptionBox samplerate value from ffmpeg CLI? [10:53:45 CEST] <fbeaufort> For info, here's the command I used: [10:53:46 CEST] <fbeaufort> ffmpeg -i bear-1280x720.mp4 -map 0:0 -acodec flac -strict -2 -ar 192000 bear-flac-192kHz.mp4 [11:19:26 CEST] <fbeaufort> Note that when I don't change SampleDescriptionBox, audio file can be decoded in Firefox. [11:20:52 CEST] <fbeaufort> FYI jya [11:21:46 CEST] <fbeaufort> jya FYI [11:22:18 CEST] <jya> fbeaufort: what do you mean by "when I don't change SampleDescriptionBox" ? [11:22:42 CEST] <fbeaufort> when I don't set the "-ar" option in ffmpeg [11:23:16 CEST] <fbeaufort> See more at https://github.com/GoogleChrome/samples/pull/538#issuecomment-324270570 [11:23:21 CEST] <jya> it's very weird that -ar would actually set the rate in the AudioSampleDescriptionBox to 0 [11:23:26 CEST] <jya> rather counter intuitive [11:25:42 CEST] <fbeaufort> Would you happen to know where the code for this live in ffmpeg? [11:26:27 CEST] <fbeaufort> QQ: How did you create your flac-in-mp4 files at https://github.com/mozilla/gecko-dev/tree/master/dom/media/mediasource/test… [11:27:34 CEST] <jya> fbeaufort: I asked BBC :) [11:28:00 CEST] <jya> that was before ffmpeg had supports [11:28:32 CEST] <jya> let me give you the link for the flac support in ffmpeg, afaik we submitted that [11:34:20 CEST] <jya> fbeaufort: this was the commit adding flac in mp4 support https://github.com/FFmpeg/FFmpeg/commit/7dc4200c3828195ef33c8a6572891ecda50… [11:37:44 CEST] <jya> fbeaufort: at a glance, looks like it's because the track duration is 0, so it returns an average bitrate of 0 [11:38:01 CEST] <jya> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/movenc.c#L559 [11:38:26 CEST] <jya> oops sorry, that's bitrate [11:45:44 CEST] <jya> fbeaufort: did you create a ffmpeg bug already? [11:45:52 CEST] <fbeaufort> Not yet. [11:46:11 CEST] <fbeaufort> I'd like to understand what is going on ;) [11:46:14 CEST] <jya> i think i see why it does so [11:46:19 CEST] <jya> it always write 0 [11:46:56 CEST] <jya> this stupid pdf reader on my mac, is unable to perform a search on the ISO 14496-12 document [11:49:25 CEST] <jya> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/movenc.c#L1032 [11:49:33 CEST] <jya> if the rate is greater than 65536, it writes 0 [11:50:47 CEST] <jya> that can't be it, it's a 16 bits int, but in the spec it's 32 bits [11:53:03 CEST] <dafna> after allocating and opening a avcodeccontext with avcodec_open2, then when decoding finishes, is it valid to call just avcodec_flush_buffers( p_context ); and avcodec_free_context(&p_context); without calling avcodec_close ? [11:53:28 CEST] <dafna> I ask this because this is what I see in the implementation in VLC [11:54:32 CEST] <jya> fbeaufort: where do I get the bear-1280x720.mp4 file? [11:54:56 CEST] <jya> found it [11:55:02 CEST] <fbeaufort> :) [11:55:20 CEST] <fbeaufort> also at https://storage.googleapis.com/media-session/bear-1280x720.mp4 [11:56:47 CEST] <jya> not the most uplifting video [11:58:46 CEST] <jya> fbeaufort: I can play the file created via build.57/bin/ffmpeg -i bear-1280x720.mp4 -map 0:0 -acodec flac -strict -2 -ar 192000 bear-flac-192kHz.mp4 [11:58:52 CEST] <jya> in firefox that is [11:59:08 CEST] <jya> using ffmpeg from the 3.3 branch [11:59:27 CEST] <jya> ffmpeg version n3.3.3-1-ge51e07c34e [12:00:07 CEST] <fbeaufort> I used static release 3.3.3 from https://www.johnvansickle.com/ffmpeg/ [12:00:17 CEST] <fbeaufort> I'll try with most recent build and let you know [12:00:31 CEST] <fbeaufort> Does that matter that I've tried with Firefox on macOS? [12:01:13 CEST] <jya> no [12:03:18 CEST] <jya> that command line doesn't generate a fragmented mp4, maybe it's the fragmentation side of thing that mess things up [12:05:34 CEST] <jya> the file you generated has Lavf57.75.100 has version [12:05:50 CEST] <jya> 3.3 branch is Lavf57.71.100 [12:09:15 CEST] <fbeaufort> fragmented or not is the same result for me. [12:09:54 CEST] <fbeaufort> I can reproduce with latest builds from https://www.johnvansickle.com/ffmpeg/ [12:11:04 CEST] <jya> fbeaufort: pfffft, my bad, I actually made a change to the code which caused it to work [12:11:12 CEST] <fbeaufort> :D [12:11:26 CEST] <jya> I can't match what they are writing in the spec. [12:11:40 CEST] <jya> seems to me that it works because they write a 16 bits int followed by a 0 [12:12:54 CEST] <fbeaufort> Let me try to confirm your thoughts by creating files with different rates [12:14:41 CEST] <jya> oh, I'm certain that if you set a rate of 48kHz it will wor [12:14:42 CEST] <jya> k [12:14:53 CEST] <jya> because my change was doing just that [12:15:07 CEST] <jya> I replaced the 0 there https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/movenc.c#L1033 with 48000 [12:15:12 CEST] <jya> and it played just fine [12:17:25 CEST] <fbeaufort> You're right. It works fine! [12:17:32 CEST] <dafna> ? [12:18:22 CEST] <jya> fbeaufort: the definition of the AudioSampleEntry is defined in 12.2.3.2 [12:18:37 CEST] <jya> https://irccloud.mozilla.com/pastebin/jZR7Uu75/ [12:20:30 CEST] <fbeaufort> So here we are. There is indeed a bug ;) [12:23:05 CEST] <jya> i can't find the definition of the format ffmpeg write [12:23:10 CEST] <jya> I must be overlooking something [12:23:52 CEST] <fbeaufort> Is that as simple as using `avio_wb32` when writing sample rate? [12:24:52 CEST] <jya> no... because the value written is a 16.16 fixed point [12:25:16 CEST] <fbeaufort> oops noted [12:38:11 CEST] <jya> i don't undestand how that code ever worked, and if they are just using a different set of spec than I have [12:42:20 CEST] <fbeaufort> It looks like this code hasn't been touched for 6 years. [12:42:25 CEST] <fbeaufort> https://github.com/FFmpeg/FFmpeg/blame/5f4e555dc7caea343838e9f6f218525bb802… [12:42:29 CEST] <fbeaufort> This may explain why [12:45:23 CEST] <jya> maybe it was different in the quicktime spec [12:46:45 CEST] <jya> very lucky that anything works today though... so long as rate > 0 it's fine for us. even if the value is buggy. and after that, we actually read the rates in the specialised box that follows. mp3, opus, aac, flac, all have their codec data that will include the actual sampling rate [12:48:35 CEST] <jya> but having said that, even if we wrote a 16.16 value [12:48:40 CEST] <jya> you can fit 192kHz in there [12:50:07 CEST] <jya> you need to use a SamplingRateBox [12:50:14 CEST] <jya> and ffmpeg has no support for that [12:50:21 CEST] <jya> so no 192khZ in mp4 for you [12:50:33 CEST] <fbeaufort> ;( [12:53:27 CEST] <jya> creating a 192kHz output from a 48kHz file was a bit silly anyway :) [12:53:54 CEST] <jya> if you wanted to capture a whale singing I could understand, but here's it's a poor bear locked in a cage [12:54:46 CEST] <fbeaufort> I named this bear "poupi". Please. [12:56:03 CEST] <fbeaufort> Should we still file a bug or at least make the ffmpeg team aware of this? [12:58:08 CEST] <jya> you can create a bug that the SamplingRateBox (as per ISO 14496-2 12.2.3.2) is to be used if the value is greater than INT16_MAX [12:59:14 CEST] <jya> they have provision for that inthe SoundDescription V2, but i can't find this anywhere in the spec [12:59:20 CEST] <jya> must be a QT thing [13:00:14 CEST] <jya> and if they properly create a SamplingRateBox, need to file a bug in Firefox that our mp4 demuxer doesn't support it :) [13:01:46 CEST] <jya> ah indeed, you must enable the MOV mode [13:31:03 CEST] <fbeaufort> I'm having an error on https://trac.ffmpeg.org account registration. [13:31:03 CEST] <fbeaufort> http://i.imgur.com/EJyCD9e.png [13:31:12 CEST] <fbeaufort> Do you mind filing it if that works for you? [14:45:44 CEST] <stimple> greetings, earthlings [14:47:07 CEST] <stimple> is it correct that when ffmpeg converts .srt to ass, it chooses which line to display the new text on? [14:47:36 CEST] <klaxa> what do you mean with line? [14:47:48 CEST] <stimple> this is line 1 [14:47:50 CEST] <stimple> this is line 2 [14:47:59 CEST] <stimple> i want subs to scroll up [14:48:23 CEST] <stimple> like they do on youtube [14:48:28 CEST] <stimple> or a terminal [14:48:29 CEST] <stimple> or irc [14:48:55 CEST] <klaxa> that's not really the default for ass subs [14:49:23 CEST] <stimple> yes [14:53:43 CEST] <stimple> it's possible the libass format doesn't support this behavior [14:53:57 CEST] <stimple> trying to find the spec [15:27:42 CEST] <stimple> i don't see a way to do it with ass format [15:40:23 CEST] <stimple> i don't find any options to pass to ffmpeg for how to convert .srt to .ass [15:41:03 CEST] <fbeaufort> jya Let me know if you've filed it already. It looks like it works now. [15:48:36 CEST] <jya> fbeaufort: I haven't yet.... I need to lodge a bug on our side to have our new mp4 demuxer properly parse "SoundDescription" [15:48:58 CEST] <jya> I had amended stagefright to support it, but we're about to disable that demuxer [15:49:16 CEST] <jya> and we also need to add support for the SamplingRateBox [15:53:28 CEST] <fbeaufort> Here is ffmpeg ticket: https://trac.ffmpeg.org/ticket/6609#ticket [15:54:27 CEST] <fbeaufort> Do you have some doc/video about Firefox Media Stack? [15:54:27 CEST] <fbeaufort> I've already watched your Paris Video Tech talk and enjoyed it. [16:01:17 CEST] <jya> :) [16:23:33 CEST] <jya> fbeaufort: I've added details to the bug. [16:24:12 CEST] <fbeaufort> Yeah! Thanks. [16:32:31 CEST] <jya> fbeaufort: incidentally, even if FF doesn't support yet SamplingRateBox , it should work because per spec samplingrate is to be written with a value of 1<<16 which is greater than 0 [17:02:31 CEST] <stimple> ok i was misled into coming here, sorry - cheers [17:09:53 CEST] <charly> hello [17:09:57 CEST] <charly> I'm using avio/avformat/acodec to decode an mpegts stream and it works very well [17:10:09 CEST] <charly> but i don't know how to detects when the input mpegts stream change (codec, framerate ...) [17:10:16 CEST] <charly> there is a way to do it ? [17:12:28 CEST] <DHE> charly: there's not direct notification system. basically you have to watch the decoder's AVCodecContext values to see if they change while running [17:12:43 CEST] <DHE> also mpegts is a strange one because it uses the AVProgram type to specify which streams are members of the (active) feed. you'll have to watch the AVProgram for changes and then reconsider all listed streams [17:15:45 CEST] <charly> DHE, thank you, i will try this [17:27:41 CEST] <Kadigan> Hello. I just wanted to know if there's a foolproof way of determining whether the video is interlaced, progressive or progressive-segmented-frame? [17:27:55 CEST] <Kadigan> (programmatically using ffmpeg, I should add) [17:28:11 CEST] <Kadigan> (or possibly ffprobe, at that) [17:35:45 CEST] <JEEB> Kadigan: you can get the coding mode values at most [17:36:03 CEST] <Kadigan> Please elaborate, I'm not sure I understand. [17:37:34 CEST] <JEEB> there usually is a coding mode value in a video stream. what the actual content is is completely separate. additionally in some formats there are per-picture flags you can receive after decoding [17:38:24 CEST] <JEEB> what the actual content type is cannot be understood without looking at the decoded pictures [17:40:34 CEST] Action: Kadigan sighs [17:41:00 CEST] <Kadigan> I typically notice there's something wrong when I see a whole bunch of drop=X. [17:41:31 CEST] <Kadigan> I was hoping there was a way I could detect this <before> I start the decode proper, in order to select the flags (ie. use deinterlacing or just recombine) [17:44:05 CEST] <Kadigan> CANON support doesn't immediately know either, so I guess I'll have to wait for their action. Also, I'm running build N-86436-g4f9e958b04, and it <still> doesn't properly recognize the MXF files that come off of Canon XC10 -- I'm getting long lists of "[NULL @ 0x7ff99a0a7600] Truncating likely oversized PPS (9469 > 4096)". [17:44:25 CEST] <Kadigan> Or am I doing something wrong there? [17:44:31 CEST] <Diag> exucse that please [17:44:52 CEST] <Kadigan> Diag: that's an, um, interesting handle. [17:45:10 CEST] <Diag> Theres someone who goes by the name MrProcom in another channel [17:45:16 CEST] <Diag> and once someone made the name MrProlapse [17:45:18 CEST] <Diag> and grouped it [17:45:30 CEST] <Diag> It has since been ungrouped [17:46:12 CEST] <Kadigan> Well, the channel's PG13 and a prolapse is a legit medical condition that can happen due to a number of events... so... [17:46:27 CEST] <Diag> I can just imagine though [17:46:32 CEST] <Diag> ~this channel is publically logged~ [17:47:32 CEST] <Diag> wew [17:47:35 CEST] <Diag> i grouped it for them [17:55:01 CEST] <Diag> jesus christ i thought i left this channel [18:37:16 CEST] <tableflopper> Hello - question on merging in subtitle tracks into a video stream. Can I specify the subtitle file as a URL? e.g. ffmpeg -i myvid.avi -i http://host/mysubtitle.srt [18:38:57 CEST] <tableflopper> The ultimate goal is to stream in the subtitles incrementally, since they would be dynamically generated. Possibly using a pipe for the subtitle file? [18:40:28 CEST] <Diag> tableflopper: i dont know the answer to this specifically, but could you not just have a script that just wgets that link then executes ffmped [18:59:53 CEST] <tableflopper> Thanks Diag that could technically work. Would prefer a memory constant approach like streaming it into ffmpeg as needed as these files will be pretty big [19:00:31 CEST] <Diag> ah [19:45:54 CEST] <ney> Need help in streaming with ffmpeg, someone out there? [19:52:10 CEST] <ney> Someone available now? [19:54:12 CEST] <BtbN> All crystal ball operators and seers are gone. Forever. [19:56:22 CEST] <ney> Whoa, bad news man! heheh. I'm having a more trivial problem. [19:57:22 CEST] <ney> I'm streaming from ffmpeg to a NGinx server. The image is black and white and stripped. Any tip where is the misconfiguration? [20:00:19 CEST] <samgoody> Hi. Quick question: I compiled ffmpeg and put it into /usr/bin/local/ffmpeg. [20:01:02 CEST] <samgoody> Whereas the apt-installed version (which must have come with the default install of the OS) is at /usr/bin/ffmpeg [20:02:24 CEST] <samgoody> And /usr/bin/ffmpeg trumps /usr/bin/ffmpeg when I do $ ffmpeg [20:03:05 CEST] <ney> Hey Sam, you tried to uninstall the previous version first? [20:03:25 CEST] <samgoody> No. I wanted to know if there is ome reason not to [20:03:53 CEST] <BtbN> usr/bin/local is highly unusual [20:04:02 CEST] <BtbN> do you mean local/bin? [20:04:12 CEST] <samgoody> I had understood that /usr/local/ are for self compiled programs [20:04:20 CEST] <BtbN> It is [20:04:24 CEST] <BtbN> but you said /usr/bin/local [20:05:12 CEST] <samgoody> hmm, you are right. That is illogical. [20:05:59 CEST] <furq> you can probably set your $PATH such that /usr/local/bin comes before /usr/bin [20:06:15 CEST] <furq> debian doesn't usually put anything in /usr/local/bin so presumably anything in there should take precedence anyway [20:06:20 CEST] <samgoody> So, for starters I shouldput my compiled version into /usr/local/bin/ [20:06:24 CEST] <furq> yes [20:06:40 CEST] <samgoody> And thats what I suspected, but didnt want to mess with the path without asking first [20:08:08 CEST] <kepstin> I'm kind of surprised that debian doesn't already have /usr/local/bin earlier in the path? [20:08:40 CEST] <kepstin> note that if you're using a bash shell where you ran 'ffmpeg' before installing the new one, you might need to run 'hash -r' to reset its cached path lookup [20:08:59 CEST] <samgoody> $ echo $PATH [20:08:59 CEST] <samgoody> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games [20:09:25 CEST] <samgoody> So, now it should be first. But it isnt [20:09:49 CEST] <samgoody> $ ffmpeg // shows ffmpeg version 2.8.11-0ubuntu0.16.04.1 [20:10:41 CEST] <kepstin> samgoody: ok, so do you still get the wrong one after running 'hash -r' in that shell or opening up a new terminal? [20:10:58 CEST] <kepstin> if so, then what does the output of 'ls -l /usr/local/bin/ffmpeg' look like? [20:13:47 CEST] <samgoody> After logging out and in, it now has the correct version, thank you [20:14:26 CEST] <ney> Hi guys, I'm streaming from ffmpeg to a NGinx server. The image is black and white and stripped. Any tip where is the misconfiguration? [20:16:00 CEST] <ianbytchek> Greetings! Can anyone point in the right direction with translating `ffmpeg -i "src.jpg" -vf "palettegen=max_colors=45" -y "palette.png"` into c code? I did go throuh ffmpeg_filter.c and ffmpeg_opt.c and have a working code, but it produces an empty image& [20:16:15 CEST] <ianbytchek> Is there a knowhow or some guidance on this? [20:19:44 CEST] <ney> I'll have to go now, I'm almost there. Thanks! [20:24:35 CEST] <durandal_1707> ianbytchek: did you check for EOF? [20:27:44 CEST] <ney> To furq and devinheitmueller: Thanks for the support man, I'm able to make a C++ program to stream using ffmpeg to NGinx server without problem (at least, until now). Next step is to embed on my RPi B+ and see what happens! [20:31:28 CEST] <ianbytchek> durandal_1707: yes, if i try the full conversion, it works, the problem is with using a palettegen on it's own. i think i might be overcomplicating things, not sure where to start looking though. [20:32:52 CEST] <ianbytchek> durandal_1707: ffmpeg uses lots of custom structs for simple filtergraph, will palettegen work if used with buffer and buffersink filters? is output or anything else would need to be setup differently? [20:33:00 CEST] <durandal_1707> ianbytchek: palettegen consumes by default all stream and you need to tell him when its received all frames [20:33:45 CEST] <durandal_1707> ianbytchek: it should work with buffer filters too [20:34:27 CEST] <durandal_1707> just need to signal eof with special item i cant remmember exactly what [20:36:29 CEST] <ianbytchek> durandal_1707: that's good to hear. i use avfilter_graph_parse_ptr with simple `palettegen=max_colors=64` desciption. i want to know how ffmpeg knows that the output png must be 16x16, what pix format, etc. does it get this info from filter at some point? [20:37:58 CEST] <durandal_1707> ianbytchek: its 16x16 because paletteuse needs it that way [20:38:45 CEST] <durandal_1707> and paletteuse gets info from previous filter [20:40:28 CEST] <ianbytchek> durandal_1707: i understand that. but how does ffmpeg know that? i do avformat_alloc_output_context2, avcodec_alloc_context3, avformat_new_stream, avcodec_open2, avcodec_parameters_from_context, avio_open, then set up frames and filter graph. all manually. but perhaps i should call something else from palettegen to do the autosetup of the output? [20:41:26 CEST] <durandal_1707> no, buffersink is setup already what it will receive [20:43:33 CEST] <ianbytchek> durandal_1707: it just ticked a box in the head, you did tell something about eof, it was something very specific. i must be confusing this with something else. can you tell more about that? what should i invoke specifically? [20:44:11 CEST] <ianbytchek> durandal_1707: * the last time we talked about it, it fixed something back then but i ended up using a different configuration and didn't need it. [20:44:18 CEST] <durandal_1707> look at comments of headers for clues [20:44:27 CEST] <ianbytchek> durandal_1707: cool. [20:47:18 CEST] <durandal_1707> ianbytchek: you sent NULL as avframe to buffersrc to mark eof [21:00:07 CEST] <ianbytchek> durandal_1707: hmm. is this with avcodec_send_frame(codecContext, NULL)? [21:00:40 CEST] <durandal_1707> ianbytchek: no, you send to buffersrc [21:19:54 CEST] <ianbytchek> durandal_1707: k. testing, but now working. just to be sure, this is av_buffersrc_add_frame. i see this is used in configure_filtergraph in ffmpeg itself. [21:20:29 CEST] <durandal_1707> yes [21:21:44 CEST] <durandal_1707> you also need to setup filtergraph with palettegen as only filter, with also sink and src filters [21:38:36 CEST] <ianbytchek> durandal_1707: yes, that's what i have. i must be going wrong somewhere else. gonna figure it out. thanks for you help again! ffmpeg is a beast, can get my head around it. [21:51:17 CEST] <SolarAquarion> 2 errors detected in the compilation of "/tmp/tmpxft_0000575e_00000000-7_vf_scale_cuda.cpp1.ii". [21:51:19 CEST] <SolarAquarion> make: *** [ffbuild/common.mak:95: libavfilter/vf_scale_cuda.ptx] Error 2 [22:43:19 CEST] <alexpigment> drawing a blank here, is there a way to tell if a binary is 32-bit or 64-bit? [22:43:35 CEST] <alexpigment> or do I have to look for something in the configuration flags [23:02:17 CEST] <microchip_> alexpigment: on Linux? file /path/to/file [23:02:26 CEST] <alexpigment> Windows [23:02:29 CEST] <alexpigment> but no worries [23:02:51 CEST] <alexpigment> I figured out the issue isn't 32-bit/64-bit related [23:02:52 CEST] <alexpigment> thanks though [23:38:02 CEST] <kepstin> there are people who run into 32bit issues on windows; it's kind of surprising how much memory x264 can use on HD+ content ;) [23:55:52 CEST] <furq> alexpigment: for future reference, there's a windows port of file which will tell you [23:56:00 CEST] <furq> and also you can check in task manager if it's running [23:56:18 CEST] <furq> any 32-bit processes will have *32 next to the process name [23:56:55 CEST] <c7j8d9> is there a way to convert the audio of a movie and add it as a new stream keeping the original too. [23:56:58 CEST] <c7j8d9> ? [23:58:25 CEST] <furq> c7j8d9: -map 0:v -map 0:a -map 0:a -c:a:0 aac -c:a:1 copy [23:59:46 CEST] <c7j8d9> thanks furq. why the second -map 0:a? [00:00:00 CEST] --- Thu Aug 24 2017

1 0

ffmpeg-devel.log.20170822
by burek 23 Aug '17

23 Aug '17

[00:43:47 CEST] <unholy_me> I am experiencing error of form : "./ffmpeg: error while loading shared libraries: libavdevice.so.57: cannot open shared object file: No such file or directory" [00:44:03 CEST] <unholy_me> any suggestions? [01:00:14 CEST] <RiCON> unholy_me_: yeah, go to #ffmpeg, this is the wrong channel [01:01:02 CEST] <unholy_me_> ok [04:14:11 CEST] <stevenliu> BtbN: What happen? HLS supports fragmented mp4 ? [04:23:10 CEST] <cone-655> ffmpeg 03Steven Liu 07master:20a6b198b484: avformat/hlsenc: move free fmp4_init_filename after hls_window operation [05:06:42 CEST] <cone-655> ffmpeg 03James Zern 07master:d8269519e4a3: vp9: set color range to MPEG for intraonly profile 0 [10:50:52 CEST] <BtbN> stevenliu, since quite a while, yes? [11:03:54 CEST] <stevenliu> I saw you leave a hls fmp4 message here when i login in irc today morning Peking Time :) [11:05:01 CEST] <stevenliu> HLS supports fragmented mp4 i just saw this line [11:08:25 CEST] <wm4> stevenliu: what is your dash patch doing anyway? [11:09:19 CEST] <stevenliu> fix bugs [11:09:37 CEST] <stevenliu> do you and samsamsam has contact me , we fix bugs together :( [11:10:16 CEST] <stevenliu> test all case from : http://dashif.org/reference/players/javascript/v2.5.0/samples/dash-if-refer… [11:11:11 CEST] <wm4> I know a while ago there were reviews by others and new versions of the patches were posted all the time [11:11:13 CEST] <stevenliu> I cannot sure if i can commit a base version but have lots of bug for the cases, and holding maintaining the dashdec.c with samsamsam [11:11:36 CEST] <BtbN> How was the xml parser problem solved now? [11:12:23 CEST] <stevenliu> xml parser Nicolas maybe need time to support [11:13:02 CEST] <wm4> I wouldn't wait for that [11:13:06 CEST] <stevenliu> samsamsam has contact me , we fix bugs together :( [11:13:13 CEST] <wm4> (although he'll probably raise a fuzz anyway) [11:14:16 CEST] <stevenliu> Can i send a dashdec.c but have bugs, and let's fix all the bugs together? [11:15:35 CEST] <wm4> what kind of bugs are there? [11:16:57 CEST] <stevenliu> many of the kind of bugs are livestream with about timeline, timeshift, and avaliablestart[end] process [11:18:43 CEST] <stevenliu> the youtube bugs which from mailist reported by Ricardo Constantino has been fixed local [11:19:41 CEST] <stevenliu> but test users report about the lists of the live streams on http://dashif.org/reference/players/javascript/v2.5.0/samples/dash-if-refer…, have compatibility issue [11:21:37 CEST] <stevenliu> wm4: are you developing dash demuxer now? [11:21:51 CEST] <wm4> stevenliu: no [11:22:21 CEST] <stevenliu> don't worry, let me send a new version patch next week [12:43:02 CEST] <wm4> wbs: any comments on "[PATCH] all: avoid data imports across DLL boundaries"? [12:45:47 CEST] <wbs> wm4: not really, it looks pretty clean and straightforward to me [12:46:16 CEST] <durandal_1707> carl is on drugs when posting bitstream writer patch [16:35:40 CEST] <kierank> durandal_1707: why does he want to do that [16:36:23 CEST] <durandal_1707> kierank: dunno [17:52:59 CEST] <cone-690> ffmpeg 03Paul B Mahol 07master:e1be40bbb578: avfilter/vf_pseudocolor: add high bitdepth support [19:22:14 CEST] <nevcairiel> anyone happen to know a simple/small image scaling library with both x86 SIMD and ARM/Neon optimizations? Just need RGB resize, nothing fancy [19:23:30 CEST] <cone-690> ffmpeg 03Michael Niedermayer 07master:a2e444d5bb2e: avcodec/pngdec: Fix () placement [19:23:34 CEST] <BtbN> zimg? [19:23:41 CEST] <nevcairiel> no neon [19:24:09 CEST] <BtbN> swscale? [19:24:17 CEST] <nevcairiel> not small and nice =p [19:24:20 CEST] <rcombs> clearly NIH it [19:24:39 CEST] <rcombs> also, protip: don't use FreeImage for scaling [19:24:58 CEST] <nevcairiel> zimg would probably be nice if someone would contribute neon code :D [19:25:09 CEST] <rcombs> I found out the other day that it does scaling via floating-point in C, for some reason [19:26:50 CEST] <rcombs> (this is especially dumb when you realize that the armv7 compiler in the android NDK uses -mfloat-abi=soft by default rather than softfp, despite armv7 android always having an FPU available [afaik]) [19:27:13 CEST] <nevcairiel> great fun [19:27:20 CEST] <rcombs> tfw complaints of scales taking 15 seconds [19:27:59 CEST] <JEEB> :D [19:30:23 CEST] <BtbN> AMD accepted my RMA. [19:30:31 CEST] <BtbN> And my intermediary 1500X has the same bug [19:31:05 CEST] <atomnuker> nevcairiel: are you displaying the image somewhere? use shaders then [19:31:13 CEST] <BtbN> And according to its sensor, it's running at 11°C. [19:31:49 CEST] <nevcairiel> atomnuker: needs to be general purpose, not re-designing the entire rendering thing just to get faster image scaling on arm devices =p [19:32:20 CEST] <nevcairiel> BtbN: ryzen cpus have this weird offset temperature, if you switched from a high-end to a mid-range, it may have the offset wrong [19:32:47 CEST] <BtbN> Adding 20°C does not add up though [19:32:55 CEST] <BtbN> When I put it under stress, it settles in at 33°C [19:33:33 CEST] <atomnuker> BtbN: are you using the latest kernel? [19:34:17 CEST] <BtbN> This is Windows [19:36:55 CEST] <BtbN> Linux has no driver to even read those sensors [19:57:37 CEST] <J_Darnley> BtbN: Congrats on the duplicate bug. :-) [20:08:47 CEST] <BtbN> bug is probably a bad name for it [20:08:54 CEST] <BtbN> it's just a faulty chip [21:17:36 CEST] <cone-690> ffmpeg 03Michael Niedermayer 07master:6f03ffb47d51: avcodec/aacdec_template: Fix running cleanup in decode_ics_info() [22:34:58 CEST] <cone-690> ffmpeg 03Ravindra 07master:f3913dcc0685: libavdevice/decklink: configurablity to set max queue size [00:00:00 CEST] --- Wed Aug 23 2017

1 0

ffmpeg.log.20170822
by burek 23 Aug '17

23 Aug '17

[00:00:03 CEST] <JEEB> same as contrast changes and other color changes that GPU vendors have been doing with your 8bit YCbCr until now [00:00:49 CEST] <c7j8d9> sadly there is not much true 4k hdr content in the first place [00:01:01 CEST] <_benj> hello guys! [00:01:26 CEST] <_benj> just a quick question, is ffmpeg used at enterprise level for DASH and or HLS streaming? [00:01:36 CEST] <JEEB> yes, but that doesn't mean that you should rape actual content to get that good feeling of having your HDR LED (in hardware or software) light up [00:02:15 CEST] <c7j8d9> hehe...it is pretty selfish [00:02:45 CEST] <_benj> I'm considering proposing to my company doing an in-house streaming solution and I'm looking into ffmpeg for that... is it possible? has it been done? [00:02:48 CEST] <JEEB> _benj: most definitely. facebook, google among others base their solutions on FFmpeg etc [00:03:00 CEST] <_benj> oh really? didn't knew that! [00:03:04 CEST] <JEEB> usually solutions are multi-faceted and FFmpeg handles decoding/encoding etc [00:03:24 CEST] <JEEB> while content delivery is generally separated to just keep a separation of concerns [00:03:26 CEST] <_benj> yeah, I'm thinking a CDN in front of ffmpeg [00:04:51 CEST] <_benj> any good source to start my testing? I found some commands at the webm wiki but not too much for HLS [00:25:34 CEST] <DHE> testing what? ffmpeg as a streamer? CDN backending? [00:32:57 CEST] <_benj_> sorry, help with making the .m3u8 file [00:34:07 CEST] <DHE> ah... so I do a fair bit of HLS. Usually I have some process generate the master playlist on startup and launch ffmpeg to generate its normal child playlists [00:36:45 CEST] <_benj_> good to hear that you do HLS :-) so, a script or something that generates the master.m3u8 and then various ffmpeg for the childs, right? [00:36:59 CEST] <DHE> not various. one. [00:37:24 CEST] <DHE> various instances can work for pre-rendered video, but for live you really do need one ffmpeg to handle all of it [00:37:45 CEST] <_benj_> ok, got it [00:38:03 CEST] <_benj_> what about the hosting and cdn? any recommendations? [00:38:14 CEST] <squarecircle> ohai [00:38:17 CEST] <_benj_> I'm thinking something like nginx and AWS for CDN [00:39:02 CEST] <DHE> nginx is just software. you have to run it somewhere. your own AWS instances is an option. [00:39:11 CEST] <squarecircle> is there a way to distinguish between an video or an audio file? [00:39:18 CEST] <DHE> are you doing live or pre-rendered? [00:40:13 CEST] <squarecircle> DHE: who you are asking? [00:40:21 CEST] <DHE> squarecircle: I am asking benj [00:40:23 CEST] <_benj_> live [00:40:33 CEST] <DHE> okay, amazon S3 is probably a bad fit then.. [00:40:50 CEST] <_benj_> @DHE: this is what I have on mind, in-home server for live video encoding and probably nginx to host the m3u8 and .ts files [00:41:08 CEST] <_benj_> I'm not thinking S3 but CloudFront for CDN [00:41:13 CEST] <DHE> I'm not very familiar with all amazon offers. do they have a full out HTTP[s] proxy CDN? [00:41:38 CEST] <_benj_> supposedly they do [00:42:02 CEST] <DHE> interesting... [00:42:25 CEST] <_benj_> what I'm wondering tho is if the general setup is kind of what is standard [00:42:43 CEST] <DHE> for testing the biggest thing I'd check is what kind of traffic pattern you see. does cloudfront fetch once, or does each edge system fetch its own copy? your ffmpeg system needs to be able to endure that. [00:43:14 CEST] <DHE> you said "in-home" so I'm imagining a cable modem serving the video. which would be bad [00:43:29 CEST] <_benj_> in-location server hosting .m3u8 and .ts -> CDN [00:43:43 CEST] <_benj_> no, I meant in location... home is for the dumb testing [00:43:54 CEST] <_benj_> fiber 1g connection [00:44:02 CEST] <_benj_> I think tha the CDN fetches one [00:44:02 CEST] <DHE> right, but the CDN is itself many many systems, each with their own needs. subtleties in how that works might be a concern [00:44:19 CEST] <DHE> well, a 1gig connection is better than I was imagining [00:44:40 CEST] <_benj_> so, you'd worry more about the CDN than the actual ffmpeg? [00:45:14 CEST] <DHE> it's two steps. you can test ffmpeg by yourself with a factory-default apache installation to serve it. then you test the CDN [00:47:39 CEST] <_benj_> ok, maybe a stretch but, would you mind sharing a sample command for a simple /dev/video to .m3u8 stream? :-D [00:48:02 CEST] <DHE> before I begin, tell me what the input resolution is and what output formats you want [00:48:12 CEST] <DHE> by formats I typically mean bitrate and resolution [00:49:00 CEST] <_benj_> right now I'm using a cheap logitech camera for video source... production might be 1080p60 but that's later [00:49:09 CEST] <_benj_> so 720p15 is what I have [00:52:25 CEST] <_benj_> of just even 640x480 @ 15fps [00:54:15 CEST] <DHE> Going with an input of 720p, this is what I came up with on the spot: https://pastebin.ca/raw/3857625 [00:54:46 CEST] <DHE> I'm assuming 4:3 aspect ratios and a medium amount of action, for example. Numbers may need fudging. [00:55:04 CEST] <squarecircle> invalid post id [00:55:05 CEST] <squarecircle> ;) [00:56:30 CEST] <DHE> uhh.. that's funky... [00:56:54 CEST] <DHE> https://pastebin.ca/3857625 The non-raw version then... I usually try to link to the raw version to keep the noise, ads etc to a minimum [00:59:36 CEST] <squarecircle> I may actually need this somewhen in the future ^^ [01:00:10 CEST] <squarecircle> DHE: try the download raw [01:00:23 CEST] <squarecircle> DHE: its failing for some reason [01:01:22 CEST] <_benj_> sweet! [01:01:45 CEST] <squarecircle> if someone has some time spare: I like to use ffprobe to probe for file types [01:02:14 CEST] <_benj_> DHE: so, aac over mp3? [01:02:17 CEST] <DHE> _benj_: always always try it for yourself. I've made a lot of assumptions when I wrote that [01:02:36 CEST] <DHE> _benj_: in the earliest versions of the HLS spec, only H264 and AAC codecs were allowed. That's changed though. Again, assumptions made [01:03:02 CEST] <_benj_> DHE: oh don't worry, I'm not moving this anywhere to production yet! there's a lot of testing but that is such a great start! [01:03:16 CEST] <_benj_> I'm really appreciate it! seriously, thanks! [01:03:18 CEST] <unholy_me_> Hi! I have come across a weird error : ./ffmpeg: error while loading shared libraries: libavdevice.so.57: cannot open shared object file: No such file or directory. The problem is I cannot locate the file libavdevice.so on my pc anywhere/ [01:03:43 CEST] <DHE> unholy_me_: it should either be included with ffmpeg, or one of its immediate dependencies. [01:06:03 CEST] <squarecircle> its drivin me nuts, that I get a video stream from mp3 or opus files [01:06:48 CEST] <_benj_> DHE: one more thing... you said that you started a process that generated the master.m3u8, for that do you just make a bash script or something? or just write it manually? [01:09:57 CEST] <DHE> I use perl because that's my MO. For any half-decent amount of text processing, I use perl. [01:10:39 CEST] <DHE> the perl does everything for me. decides the resolutions based on the input device and some secret sauce parameters we use locally [01:11:16 CEST] <_benj_> neat [01:18:26 CEST] <squarecircle> any idea? [01:20:43 CEST] <furq> squarecircle: it's probably album art [01:20:51 CEST] <furq> ffmpeg just treats that as a video stream [01:21:07 CEST] <furq> on account of album art specs for audio files being a colossal clusterfuck [01:25:03 CEST] <squarecircle> furq: thats exactly my opinion [01:25:32 CEST] <squarecircle> I can find out, when I'm decoding the stream, that I only get one frame [01:25:42 CEST] <squarecircle> then I can throw the analysis away [01:25:56 CEST] <furq> well for mp3 it's definitely album art because that container can't contain video streams [01:26:14 CEST] <furq> ogg can, though, so you'll probably need a better check [01:26:31 CEST] <squarecircle> but it looks nasty: 50 files found, 49 files were video files, one was a audio file, because fuck you [01:26:45 CEST] <furq> you can probably check the video codec? [01:26:49 CEST] <furq> it'll be png or jpg for album art [01:27:04 CEST] <squarecircle> furq: ogg contains video for sure, Big Buck Bunny is downloadable as .ogg file [01:27:49 CEST] <furq> it's probably unlikely you'll have .mka that contains an actual mjpeg stream, so checking the codec is probably fine [01:28:11 CEST] <furq> i don't think any other audio container format will have anything to do with mjpeg [01:28:28 CEST] <furq> not that it's something you'd ever see anyway [01:29:18 CEST] <squarecircle> furq: http://paste.ubuntu.com/25365859/ [01:29:24 CEST] <squarecircle> actuallt its worse [01:29:59 CEST] <furq> ffmpeg will report jpg album art as mjpeg [01:30:05 CEST] <squarecircle> this is the ffprobe output on a mp3 [01:30:17 CEST] <furq> they use the same decoder [01:30:25 CEST] <squarecircle> oh great [01:30:38 CEST] <squarecircle> whose behind I can set on fire for this glorious idea? [01:30:41 CEST] <furq> like i said, mp3 and ogg can't contain mjpeg anyway [01:31:13 CEST] <squarecircle> furq: if I put an mjpeg stream into an ogg container? [01:31:18 CEST] <furq> you can't [01:31:40 CEST] <furq> you can with m4a and mka [01:32:08 CEST] <squarecircle> but I can put theora in it [01:32:12 CEST] <furq> you sure can [01:32:14 CEST] <furq> that's not mjpeg though [01:32:21 CEST] <squarecircle> why no mjpeg? [01:32:28 CEST] <furq> it's not part of the spec [01:32:33 CEST] <squarecircle> ah ok [01:33:01 CEST] <klaxa> as far as i researched mjpeg doesn't even have an official spec [01:33:16 CEST] <furq> the ogg spec [01:33:32 CEST] <squarecircle> so the clue is: if I have an mjpeg stream, I can check if its not m4a or mka I can throw it away? [01:33:44 CEST] <furq> it could be png as well [01:33:48 CEST] <squarecircle> how about mp3-container? [01:33:56 CEST] <furq> mp3 doesn't support video at all [01:34:02 CEST] <squarecircle> I can read png as Videos? [01:34:13 CEST] <furq> iirc mp3 is just the raw audio data with an id3 tag stuck to the end [01:34:19 CEST] <furq> it's not a real container [01:34:20 CEST] <squarecircle> furq: I pasted you the ffprobe on an mp3 file [01:34:31 CEST] <squarecircle> oh no [01:34:40 CEST] <squarecircle> the image is in the id3? [01:34:43 CEST] <furq> yeah [01:34:53 CEST] <furq> ffmpeg will still detect it as a video stream though [01:34:54 CEST] <squarecircle> and its interpreted as video stream? [01:34:59 CEST] <squarecircle> ouch [01:35:18 CEST] <furq> if you have mjpeg or png in an mp3 or ogg, it's 100% album art [01:35:28 CEST] <furq> or flac, or ape, or basically anything other than m4a or mka [01:36:01 CEST] <furq> tbh i would just assume it was album art for m4a [01:36:06 CEST] <furq> nobody uses mjpeg [01:36:23 CEST] <squarecircle> ok, let me rephrase my question please: How do I differ video files from audio or pictures? [01:36:31 CEST] <furq> that is the way [01:36:41 CEST] <furq> i mean you could check the frame count but that takes longer [01:37:07 CEST] <furq> i would just assume it's album art if the video stream is mjpeg or png [01:37:10 CEST] <squarecircle> furq: as I write a small analysis tool, I will most surely get som mjpeg [01:37:15 CEST] <furq> oh right [01:37:27 CEST] <furq> i guess you probably want to check the frame count then [01:37:30 CEST] <furq> either that or use mutagen [01:37:48 CEST] <squarecircle> furq: I may get some fucked up streams from centuries ago, or crappy sources [01:37:53 CEST] <squarecircle> mutage? [01:37:56 CEST] <squarecircle> *mutagen? [01:37:58 CEST] <furq> a python audio metadata lib [01:38:05 CEST] <furq> assuming you're writing this tool in python which you're probably not [01:38:50 CEST] <squarecircle> actually, I'm writing it in Python ^^ What else? [01:39:01 CEST] <furq> well yeah that might be easier [01:39:04 CEST] <squarecircle> (ok, DHE likes Perl, Clooney Nespresso) [01:39:15 CEST] <furq> i've never really looked into the album art stuff, but mutagen is generally very good with audio metadata [01:39:20 CEST] <furq> i know it has some basic handling of it [01:41:33 CEST] <squarecircle> I need some simple test ^^ [01:42:35 CEST] <squarecircle> this whole multimedia stuff is getting me depressed ^^ [01:44:09 CEST] <klaxa> really? just thinking about webstuff makes me depressed, at least multimedia stuff usually is about efficiency [01:45:01 CEST] <squarecircle> klaxa: webstuff is horrible too, you're right [01:45:18 CEST] <squarecircle> klaxa: but the efficiency thing I don't understand [01:46:03 CEST] <squarecircle> I may try libmagic [01:46:08 CEST] <squarecircle> furq: ^ [01:49:59 CEST] <furq> that won't give you anything useful afaik [01:50:26 CEST] <squarecircle> you think so? [02:02:32 CEST] <squarecircle> furq: thanks for helpin [02:02:37 CEST] <squarecircle> I gotta sleep [02:18:36 CEST] <SpLiC3> What would a good output method for restreaming a a single live tv mpegts input to a port/socket that could be used by a webserver to start stop on remote client request? [02:19:44 CEST] <SpLiC3> i recall seeing use of %d and similar [02:42:49 CEST] <DHE> <squarecircle> (ok, DHE likes Perl, Clooney Nespresso) # you go with what works and what you're familiar with. for me that's perl when I'm parsing ffprobe -show_xxxx output [02:54:28 CEST] <furq> it's all about awk baby [04:12:21 CEST] <DHE> furq: meh, to each their own. [07:08:38 CEST] <basse_> Hi, anyone knows where I could get a compile version of ffmpeg with --enable-libpulse? [07:31:14 CEST] <tdr> basse_, ./configure --help and look for the switch name [07:31:27 CEST] <tdr> or you wanting a binary? [07:32:49 CEST] <basse_> I was thinking of the binary [07:33:33 CEST] <basse_> I installed a static version, is that something that I can change? or I need to build ffmpeg with that flag? [07:35:16 CEST] <tdr> you can't flip it once its build, youd need to built it that way or find one already linked [07:39:32 CEST] <basse_> right, thanks tdr, I will look around, otherwise will attempt to compile it [10:11:22 CEST] <victorb> hey guys, is loudnorm rediciously slow only on my machine ? [10:11:49 CEST] <durandal_1707> buy faster machine [10:12:29 CEST] <victorb> :( im running i3 and im getting like 3x speed [10:12:49 CEST] <victorb> the other filters are dramatically faster [10:13:38 CEST] <durandal_1707> loudnorm cannot benefit from multiple threads [10:15:27 CEST] <victorb> so the filter is just slow and there is nothing that can be done ? [10:16:18 CEST] <Basse_> I was able to compile sources with --enable-libpulse, and have the ffmpeg command working, I am now using the following: ffmpeg -f pulse -i default f flv rtmp://host:1935:live/mystream [10:17:47 CEST] <Basse_> Anyone knows how can I pick a specific audio from pulse? I mean I might have more than one application generating audio in the same server, for each application I am generating an ffmpeg command, I'm wondering how I could tell ffmpeg which audio belongs to each one [10:18:10 CEST] <Basse_> something like this [10:18:43 CEST] <Basse_> application1 -> audio1, application2 -> audio2, application3 -> audio3 [10:19:08 CEST] <Basse_> ffmpeg1: ffmpeg -f pulse -i default:0 [10:19:16 CEST] <Basse_> ffmpeg2: ffmpeg -f pulse -i default:1 [10:19:22 CEST] <Basse_> ffmpeg3: ffmpeg -f pulse -i default:2 [15:27:48 CEST] <user01> hi i have some wav files that apparently have tagging on them . . . how do I transfer over these tags during a batch conversion to flac? [16:00:35 CEST] <Guest91577> Heya [16:02:14 CEST] <user01> -map_metadata 0:g:0 seems to work . . . i need all that though? [16:03:17 CEST] <Guest91577> I have an mp3 that appears to be slightly wonky. Transcoding it via libmp3lame gives a warning about Incomplete frame / Error while decoding stream #0:0: Invalid data found when processing input, and the resulting file seems to confuse a number of different tools - eg it contains 1:53:00 of audio data, yet exiftool reports its duration as 1:05:00, and some players cut off at that point [16:03:25 CEST] <Guest91577> What can I try to diagnose it further? [16:50:20 CEST] <c7j8d9> Is it possible to "reverse engineer" a 4K Blu-ray that used a bilinear upscale? [16:52:45 CEST] <JEEB> I think there's functionality for that in the zimg image library, and there originally was a filter called debilinear for avisynth [16:53:23 CEST] <JEEB> the animation side of things has been using "upscaling reversers" when it's obvious how a thing has been upscaled for quite a while now [16:55:22 CEST] <JEEB> outside of Japan it started with http://forum.doom9.org/showthread.php?t=158696 , which was meant to fix a very specific type of upscaling that left a very specific type of artifact [16:56:22 CEST] <JEEB> afterwards debilinear and such were made and multiple scaling filters got support for "inverse scaling" [16:58:39 CEST] <c7j8d9> So in theory some you can debilinear a 4k movie and see that its actually a 1080p upscale and not 2k upscale or 4k mastered? [16:59:23 CEST] <JEEB> there's also a thing that was meant to try and calculate the "original resolution" that came with the debilinear package (you feed raw RGB if I recall correctly) [16:59:45 CEST] <JEEB> but you should first have doubts that it is an upscale, and generally upscales can be seen pretty darn well :P [17:00:01 CEST] <JEEB> and if they can't they're often made in a more fancy way that you might not be able to reverse necessarily [17:03:36 CEST] <c7j8d9> sorry to be off ffmpeg topic but I am trying to get a second opinion of a guy claiming studios upscale 1080p bilinearly to produce 4K discs cheaply, as in Suicide Squad and Guardians 2. Though they claim to have used 2K mastered sources. When "reversed engineered" it shows a 1080p master [17:06:57 CEST] <iive> isn't 4k a 3840x2160 ? [17:07:08 CEST] <iive> that would mean that 2k is 1920x1080 [17:07:32 CEST] <JEEB> 4K and 2K are movie aspect ratios so they'd be somewhat wider, but marketing departments have taken over :P [17:07:40 CEST] <alexpigment> iive: yeah, it's a misnomer for the consumer industry [17:07:45 CEST] <JEEB> UHD or 2160p would be the correct way to note the 16:9 ones [17:08:00 CEST] <alexpigment> i try to fly the "UHD" flag, but just have to give into 4k sometimes :( [17:08:31 CEST] <alexpigment> this would have all been nice had we just agreed to say "2160p" [17:13:51 CEST] <steved1> Hi @all, I have a mp4 with multiple audiotracks and I would like to copy them to a new mp4 and add a mixdown track of all original audio tracks. Is it possible to do this in one command? I only manage to do it in two with ffmpeg using the amix filter. [17:14:04 CEST] <c7j8d9> 2K is 1440p also called QHD [17:16:50 CEST] <alexpigment> 2k is not 1440p [17:17:06 CEST] <alexpigment> 2k is 2048x[whatever] in the movie industry [17:17:21 CEST] <alexpigment> but sometimes (rarely) 2k refers to 1920x1080 [17:18:47 CEST] <alexpigment> 1440p is a strictly computer-based resolution, and those are usually designated by weird names like QHD and WQHD [17:19:30 CEST] <iive> QHD is 2560x1440 it is a quad of 1280x720 [17:19:52 CEST] <dystopia_> 2048 is only an extra 128 pixel boost [17:20:00 CEST] <furq> https://upload.wikimedia.org/wikipedia/commons/thumb/0/0c/Vector_Video_Stan… [17:20:03 CEST] <furq> this should clear everything up [17:20:03 CEST] <alexpigment> right. just saying 1440p is not a video or movie standard [17:20:10 CEST] <dystopia_> tbh i've never heard the term 2k [17:20:21 CEST] <furq> 2K is a cinema resolution [17:20:26 CEST] <alexpigment> dystopia_ it's uncommon outside of the movie industry [17:20:29 CEST] <furq> usually 2048*1080 but obviously it depends on AR [17:20:35 CEST] <alexpigment> a "2k master" is where you'll usually hear it [17:21:08 CEST] <furq> 4K should be 4096*2160 but the UHD marketing people thought 4K was more catchy [17:21:33 CEST] <alexpigment> yeah, i want to say it's because theaters started advertising "Cinema 4K" before showing the films [17:21:44 CEST] <alexpigment> that's my guess, anyway [17:21:57 CEST] <furq> just adding U to a product name is confusing [17:21:59 CEST] <furq> ask nintendo [17:22:04 CEST] <alexpigment> haha [17:22:15 CEST] <alexpigment> to be fair, they should have called it the Wii HD :) [17:22:30 CEST] <furq> they should have called it the It's Not A Wii It Has A Touch Screen For Inventory Management [17:22:41 CEST] <furq> or the INAWIHATSFIM [17:23:32 CEST] <alexpigment> i will say that other than the completely useless-to-me touchscreen thing, it was a good system - despite all the malignment that it got in the press [17:23:55 CEST] <alexpigment> trying to compare it to the sales of the Wii, almost every console will be a dud in that respect [17:24:17 CEST] <furq> nintendo generally didn't do a great job with it, and the controller seemed a bit uncomfortable [17:24:24 CEST] <furq> but really it all comes down to whether it has good games [17:24:44 CEST] <alexpigment> it had good games. not a huge library, but a very good one [17:24:49 CEST] <furq> i still think the DS is a completely stupid form factor and the touch screen is largely a gimmick [17:24:57 CEST] <furq> but i still owned one because there were games i wanted to play on it [17:25:03 CEST] <furq> and that's done incredibly well [17:25:53 CEST] <alexpigment> yeah, i've never owned any nintendo handhelds, but the 3DS sold like crazy from all accounts [17:26:27 CEST] <furq> i've never owned any nintendo non-handhelds [17:27:32 CEST] <furq> and yeah the 3D thing on the 3DS is definitely a gimmick that nobody likes, but that's done almost as well as the original DS [17:27:59 CEST] <alexpigment> they have a 2DS [17:28:06 CEST] <alexpigment> which is cheaper and effectively just omits that feature [17:28:08 CEST] <furq> yeah that shows how much of a gimmick the 3D is [17:28:12 CEST] <c7j8d9> How quickly the convo went off the rails [17:28:42 CEST] <klaxa> only nintendo handheld i have is a gbc [17:28:55 CEST] <furq> i had a fat gameboy and a fat DS [17:31:05 CEST] <redrabbit> had gbc gba [17:31:10 CEST] <redrabbit> sold them [17:31:13 CEST] <redrabbit> eyeballs killer [17:35:21 CEST] <furq> the gba sp was all right [17:36:33 CEST] <klaxa> backlight was a good idea [17:43:24 CEST] <dystopia_> the sp is very hard to play now with adult hands [17:43:52 CEST] <dystopia_> people mod the original model, by taking the back lit screens from the sp/101's and putting them in the original shell :) [17:43:58 CEST] <dystopia_> makes them easier to play [18:10:30 CEST] <kerio> alexpigment: the new 2ds xl is cute :3 [18:10:58 CEST] <alexpigment> i think i saw a screenshot of it. it sounds more up my alley (if i were a handheld console buyer) [18:11:17 CEST] <kerio> the new 3ds xl does feel more "premium" tho [18:11:39 CEST] <kerio> alexpigment: buy one tho [18:11:46 CEST] <kerio> it's got kirby in a mech [18:11:51 CEST] <alexpigment> haha [18:11:52 CEST] <alexpigment> well [18:11:54 CEST] <alexpigment> that's it [18:11:59 CEST] <alexpigment> kirby in a mech? sold. [18:12:18 CEST] <kerio> incredibly solid gameplay too [18:12:26 CEST] <kerio> with a fiendishly hard boss rush bonus game [18:13:19 CEST] <kerio> also you can pirate the shit out of the game library [18:13:27 CEST] <kerio> because nintendo has potato security [18:14:17 CEST] <furq> yeah the original 2ds was insane [18:14:24 CEST] <furq> i'm glad they came to their senses with the new one [18:15:10 CEST] <kerio> furq do you have a 3ds [18:18:07 CEST] <furq> no [19:44:31 CEST] <Guest43016> hi, someone know if pcie riser array like used in mining can be used to decode with 6 gpus? i want try but i dont know about performance issues [19:47:44 CEST] <BtbN> The hell are you doing that you need 6 graphicscards to decode stuff? [19:47:54 CEST] <BtbN> Probably cheaper to just buy a better CPU [19:48:15 CEST] <BtbN> Unless you stuff like a bunch of 1050s in there or something [19:50:56 CEST] <Guest43016> LOL [19:51:14 CEST] <Guest43016> it is for a iptv tv service [19:51:18 CEST] <redrabbit> decode what [19:51:22 CEST] <redrabbit> you mean transoding [19:51:27 CEST] <redrabbit> neat dawg [19:51:35 CEST] <redrabbit> i do that with my 1060 [19:51:45 CEST] <redrabbit> they include 2x encoders [19:51:55 CEST] <redrabbit> you can do hevc / avc [19:52:01 CEST] <Guest43016> decoding, resize and encoding, yes transcoding [19:52:12 CEST] <redrabbit> quality is decent but in now way its on par with x264/x265 [19:52:28 CEST] <redrabbit> its good for watching tv on the go [19:52:35 CEST] <Guest43016> the idea is to use up to 6 nvidia quadro cards to transcode about 120 channels [19:52:36 CEST] <redrabbit> if bitrate is not an issue [19:52:40 CEST] <redrabbit> HEVC works better [19:52:50 CEST] <redrabbit> if you really want to use theses hardware encoders [19:53:14 CEST] <redrabbit> 120, lol [19:53:16 CEST] <redrabbit> i don't know about that [19:53:17 CEST] <Guest43016> yes, i want to switch to hevc, right now were using h264_nvenc [19:53:29 CEST] <redrabbit> i can transcode 2X streams from my 1060 [19:53:30 CEST] <redrabbit> not more [19:53:32 CEST] <Guest43016> yes, and 120 is to start [19:53:46 CEST] <redrabbit> well you use hevc_nvenc then [19:53:57 CEST] <redrabbit> i use dvbviewer for my setup atm [19:53:59 CEST] <Guest43016> that is because a final user limitation, quadro cards can run unlimited streams in parallel [19:54:03 CEST] <redrabbit> but its only for 2 clients [19:54:29 CEST] <redrabbit> cool stuff didnt knew that [19:54:35 CEST] <redrabbit> do you get the flux via sattelite? [19:54:39 CEST] <redrabbit> satellite* [19:54:47 CEST] <Guest43016> were a startup, we want to change the cable tv industry forever [19:54:57 CEST] <Guest43016> sat, terrestrian, cable [19:54:59 CEST] <Guest43016> everything [19:55:04 CEST] <redrabbit> you know there is IPTV services allover the web right? [19:55:05 CEST] <redrabbit> :p [19:55:10 CEST] <redrabbit> neat [19:55:13 CEST] <atomnuker> do you call yourself "the spacex of the cable tv industry"? [19:55:23 CEST] <Guest43016> lol [19:55:27 CEST] <Guest43016> watcha.live [19:55:30 CEST] <redrabbit> what's new VS the exisiting stuff? [19:55:49 CEST] <Guest43016> now are in beta, only 45k users [19:55:51 CEST] <redrabbit> (spain ?) [19:55:55 CEST] <Guest43016> for now [19:56:11 CEST] <Guest43016> we go to add all latin america air tv [19:56:29 CEST] <redrabbit> i have like 7000 channels from my motorized dish [19:56:38 CEST] <redrabbit> you guys must have a baller dish setup [19:56:39 CEST] <Guest43016> were looking for partners in usa [19:56:45 CEST] <redrabbit> huge dish multi lnb ? [19:57:02 CEST] <redrabbit> partners to cap stuff? [19:57:03 CEST] <Guest43016> 4 dishes 3 meters each [19:57:10 CEST] <redrabbit> hehe [19:57:21 CEST] <Guest43016> yes, and bussines too [19:57:37 CEST] <Guest43016> microsoft is partner of us right now [19:57:51 CEST] <redrabbit> how do you deal with drm? [19:57:55 CEST] <Guest43016> debian rulez [19:58:08 CEST] <redrabbit> i mean for the content, legally [19:58:33 CEST] <redrabbit> sounds like a headache [19:58:34 CEST] <redrabbit> lol [19:58:38 CEST] <Guest43016> were working on that [19:58:58 CEST] <Guest43016> yes, but it is only pushing [19:59:13 CEST] <Guest43016> and get the same lawers they have [19:59:22 CEST] <redrabbit> you can free even more cpu if you decode with the gpu [19:59:23 CEST] <redrabbit> -c:v h264_cuvid [19:59:24 CEST] <Guest43016> crazy thinks from here [19:59:49 CEST] <Guest43016> yes, we now are using only gpu [20:00:36 CEST] <redrabbit> i guess its a pay-for service right [20:00:44 CEST] <Guest43016> but, i want to do something arround mining ideas to video stream [20:01:02 CEST] <Guest43016> right now is free, but yea. [20:01:25 CEST] <Guest43016> something like netflix or spotify. [20:01:42 CEST] <Guest43016> depends if ads pay well [20:01:43 CEST] <redrabbit> i have no facebook to try though [20:01:56 CEST] <Guest43016> bienvenido(a)watcha.live [20:01:57 CEST] <Guest43016> demodemo [20:02:04 CEST] <Guest43016> use that [20:02:45 CEST] <redrabbit> thanks, the account got locked though :p [20:03:12 CEST] <Guest43016> lol [20:03:12 CEST] <redrabbit> "To continue, please approve this login on a phone or computer you've used before." [20:03:28 CEST] <Guest43016> just wait a second... [20:03:42 CEST] <redrabbit> in france there is a something called "molotov" that does legal IPTv as well [20:03:47 CEST] <redrabbit> but the service was bad [20:03:49 CEST] <redrabbit> when i tried [20:04:13 CEST] <redrabbit> i have my own iptv with dvbviewer but im avid when it comes to try new stuff [20:04:20 CEST] <Guest43016> try again now [20:04:25 CEST] <redrabbit> it works now ! [20:04:25 CEST] <redrabbit> :) [20:04:46 CEST] <Guest43016> we use our system [20:05:06 CEST] <redrabbit> channel change is fast [20:05:08 CEST] <redrabbit> that's good [20:05:14 CEST] <redrabbit> quality however [20:05:17 CEST] <Guest43016> based in ffmpeg, it all dynamic [20:05:23 CEST] <redrabbit> what is the avg bitrate? [20:05:28 CEST] <redrabbit> for 1080p [20:05:34 CEST] <Guest43016> 2mbps cbr [20:05:43 CEST] <redrabbit> on fixed images its ok [20:05:47 CEST] <redrabbit> but with movement meh [20:05:52 CEST] <Guest43016> in tv shows whit led background is ugly [20:06:02 CEST] <Guest43016> but in general is great [20:06:04 CEST] <redrabbit> 2m is barely enough for 720p [20:06:13 CEST] <redrabbit> 1080p need 3.6 [20:06:22 CEST] <redrabbit> especially with the HW decoders [20:06:24 CEST] <furq> that's an awfully specific number [20:06:37 CEST] <redrabbit> well its the max out of the nvidia decoders [20:06:50 CEST] <Guest43016> yes, were to upgrate to 4mbps for 1080 [20:06:52 CEST] <furq> huh [20:07:18 CEST] <redrabbit> hevc works better with the hw encoders as well [20:07:27 CEST] <redrabbit> it looks more like x264 [20:07:28 CEST] <Guest43016> 4,2,1,0.5,0.25 and only audio at 32kbps for latin america extreme slow netwoks [20:07:59 CEST] <Guest43016> yes it is [20:08:08 CEST] <redrabbit> im a bit picky because it play on a 32" though [20:08:14 CEST] <redrabbit> so defaults jumps to the eye [20:08:21 CEST] <redrabbit> defects [20:08:37 CEST] <Guest43016> the idea is enable hevc to internal transport to save bandwidth [20:08:40 CEST] <redrabbit> in a smaller screen it looks better [20:08:58 CEST] <Guest43016> yes, the app for android is very used [20:09:03 CEST] <Guest43016> all small screens [20:09:27 CEST] <Guest43016> is like true hd for small screens :p [20:09:34 CEST] <redrabbit> on a small screen im happy with 1M AVC [20:09:45 CEST] <redrabbit> like sub 5" [20:10:18 CEST] <Guest43016> yes, 2M is heaven lol [20:39:37 CEST] <SpeakerToMeat> Do you guys know of a tool (other than qctool which I'm not sure does this) that can check a video file end to end to find if there's errors somewhere in between? a damaged frame/segment, etc? [21:19:22 CEST] <DHE> ffprobe in -show_frames mode will decode the whole video/audio. you'll have to throw away the main output and look for warning/errors from the decoders during that time. [21:19:49 CEST] <c_14> couldn't you also use ffmpeg -f null ? [21:25:55 CEST] <SpeakerToMeat> DHE: Sounds good, thanks [21:26:30 CEST] <SpeakerToMeat> Question, has the prores encoder/s diverged much from ffmbc over time? [21:40:32 CEST] <JEEB> nothing can be taken in from ffmbc [21:40:48 CEST] <JEEB> because FFmpeg prefers internal things to all be LGPL, while ffmbc specifically does GPL only [21:41:07 CEST] <JEEB> so effectively nothing can be ported back into FFmpeg [21:41:31 CEST] <JEEB> unless ffmbc rebased on top of newer FFmpeg and that's the prores encoder you're talking about [21:41:42 CEST] <JEEB> in which case the upstream for it is FFmpeg [21:42:01 CEST] <JEEB> (doesn't change the fact that none of the possible changes done by ffmbc can be taken back in, but yunno) [21:50:50 CEST] <SpeakerToMeat> Nod [22:05:45 CEST] <paveldimow> Hi, I would like to cut and concatenate two different videos (actually it's the same recording but from different cameras). I tend to use ms precision with ffmpeg -ss but it looks that it's not possible that ffmpeg has ms precision but rather it must seek the first I frame [22:05:52 CEST] <paveldimow> Am I right? [22:06:07 CEST] <Mavrik> Yes, unless you reencode [22:07:14 CEST] <paveldimow> I do reencode [22:10:36 CEST] <paveldimow> but still I am not sure it's precise I use ffmpeg -i test.mp4 -ss 00:00:31.341 -t 10 test1.mp4 [22:11:07 CEST] <durandal_1707> paveldimow: for concat with reencoding use filters [22:11:24 CEST] <durandal_1707> trim and concat filter [22:12:23 CEST] <paveldimow> durandal_1707: I use filter complex, but I will try trim and concat. Thank you! [22:19:31 CEST] <jrun> 10% into playing back wavfile mpv quits. it doesn't do it on mp3 files. i've tried with both -ao alsa and -ao pulse (default). any idea? [22:19:50 CEST] <jrun> and so does ffplay actually, forgot to mention. [22:23:22 CEST] <sh4rm4^bnc> with every wav file ? or just with one, or some with special characteristics ? (like 8 bit mono) [22:25:26 CEST] <thebombzen> jrun: does it provide an error message? [22:26:07 CEST] <thebombzen> can you pastebin the full uncut output if you use "ffmpeg -i input.wav -f null -" [22:28:57 CEST] <kepstin> jrun: it might be that your wav file has the length header set wrong, you could try 'ffplay -ignore_length 1 file.wav' and see if it plays the whole length [22:29:41 CEST] <kepstin> if it doesn't, then, i guess the wav file is just shorter than you thought it was? [22:34:27 CEST] <jrun> kepstin: nope, that didn't fix it. logs in a bit [22:36:58 CEST] <jrun> https://gist.github.com/e7c8aa21d4531254a0e350f91a2ac51c [22:41:01 CEST] <jrun> https://gist.github.com/ca33a67b15be0826ef4c13e7d41db84c [22:41:03 CEST] <jrun> https://gist.github.com/a952a7a6b3b61e24c57d14d974c38778 [22:41:06 CEST] <jrun> logs from mpv [22:44:26 CEST] <kepstin> so the ffmpeg logs look fine, ~27.7MB of audio data which is 5.3 minutes, which matches up with the expected file length [22:44:42 CEST] <kepstin> are you seeking in the players? might be that they just have busted seek code :/ [22:45:14 CEST] <jrun> kepstin: i am indeed seeking [22:45:27 CEST] <jrun> one of the mpv logs shows that [22:46:25 CEST] <jrun> i get the same problem with the same file(s) playing on android (i.e. seeking doesn't work on some of them). these are recorded by android as well. [22:46:35 CEST] <kepstin> you could try just saving in a format that has a seek index like, say, flac [22:46:42 CEST] <kepstin> might help the players [22:46:55 CEST] <kepstin> I assume that if you just play through straight from start to finish it works fine? [22:47:31 CEST] <jrun> it does on android. haven't tested with mpv. [22:49:03 CEST] <jrun> kepstin: works in flac indeed. [22:50:17 CEST] <SpeakerToMeat> I'm trying to specify a pixel format for the input file, doing "-pix_fmt xyz12le" before -i but ffmpeg is arguing "Option pixel_format not found.", any tips? [22:51:52 CEST] <jrun> kepstin: thanks; passed your comments to people at #mpv. will file a bug report after my exam. [22:57:50 CEST] <klaxa> SpeakerToMeat: that's no pixel format ffmpeg supports [22:58:14 CEST] <furq> sure it is [22:58:18 CEST] <klaxa> it is? [22:58:21 CEST] <furq> yeah [22:58:34 CEST] <furq> http://vpaste.net/vjkFg [22:59:01 CEST] <furq> SpeakerToMeat: -pixel_format is only recognised by certain demuxers iirc [22:59:03 CEST] <klaxa> how am i so quick with my wrong assumptions... sorry :( [22:59:06 CEST] <furq> what's the input format [22:59:37 CEST] <furq> it probably works for other formats but i've only ever had to use it with rawvideo [22:59:39 CEST] <SpeakerToMeat> furq: Hmm ok, I'm using libopenjpeg [22:59:52 CEST] <furq> if this is j2k then that should be autodetected [22:59:58 CEST] <SpeakerToMeat> it works with jpeg2000, not libopenjpeg so you're right. [23:00:26 CEST] <furq> did you try without specifying it [23:00:47 CEST] <furq> usually if it's flagged in the container then there's no need for the option [23:01:29 CEST] <SpeakerToMeat> it'¿s j2k but libopenjpeg detects ir as rgb48le IF I'm reading my -vf graph debug output right, I have no pix fmt mention before, but let me double check [23:01:37 CEST] <furq> ah [23:02:06 CEST] <kepstin> SpeakerToMeat: very few filters support that pixel format, so it might just be that it got converted to rgb in the filter chain [23:02:06 CEST] <furq> if you're doing filtering then a lot of filters don't support xyz iirc [23:02:10 CEST] <furq> right [23:02:27 CEST] <SpeakerToMeat> Yes, libopenjpeg is reading it: rgb48le(12 bpc, progressive) wrongfully [23:02:59 CEST] <SpeakerToMeat> Hmmmm there used to be a form of manual matrix conversion online for this but I can't find it anymore, to apply it. [23:03:28 CEST] <SpeakerToMeat> kepstin: Now my only filter is a crop, I can try to drop the filter and crop on a second pass (not ideal), but still libopenjpeg is reading the format wrong [23:04:07 CEST] <furq> yeah i would assume crop would work regardless [23:04:20 CEST] <SpeakerToMeat> And the input shows the wrong pix format so. [23:04:50 CEST] <furq> sounds like openjpeg is being dumb then [23:04:55 CEST] <SpeakerToMeat> yes [23:05:14 CEST] <furq> does the builtin j2k decoder work [23:07:48 CEST] <SpeakerToMeat> The built in j2k decoder recognizes xyz12le correctly, has trouble with many frames that openjpeg works correctly with though [23:14:20 CEST] <SpeakerToMeat> Hmm it seems colorchannelmixer might work, maybe [23:15:01 CEST] <kepstin> I wonder if you could do something silly like "-vf scale=src_format=xyz12le:dst_format=xyz12le" to just rewrite what the pixel format is tagged as [23:15:20 CEST] <kepstin> assuming it's actually xyv12le video that just has the format mistagged [23:15:42 CEST] <leif> Is there any information on how to set up AVFormatContext for avdevice_list_devices? [23:15:53 CEST] <leif> (I'm trying to get ffmpeg to give me a list of input devices.) [23:16:39 CEST] <leif> But I keep getting back an error. [23:16:54 CEST] <SpeakerToMeat> kepstin: That's interesting [23:17:57 CEST] <SpeakerToMeat> kepstin: I think my other option is to keep considering it "rgb" and use colorchannelmixer, I wonder, in the filter manual for colorchannelmixer if the parameter name is not specified the parameters order is the same as listed in the manual? so rr:rg:rb:ra:gr... etc etc? [23:17:59 CEST] <leif> Specifically ENOSYS [23:29:53 CEST] <DHE> leif: that means "function not implemented". I believe it means there are none available [23:30:21 CEST] <DHE> did you call the register_all function? [23:38:45 CEST] <leif> Yes I did. [23:39:01 CEST] <leif> DHE: [23:39:18 CEST] <leif> Although I didn't set an input format, maybe that's the problem... [23:42:38 CEST] <leif> Hmmm...ya, maybe I have to initialize the context's iformat list...trying that now... [23:51:13 CEST] <leif> DHE: hmm...nope, that didn't work. FWIW, here is what I'm currently trying: https://gist.github.com/LeifAndersen/a2886ad538b76264f9bf2fd3e4df91be [00:00:00 CEST] --- Wed Aug 23 2017

1 0

ffmpeg-devel.log.20170821
by burek 22 Aug '17

22 Aug '17

[00:02:40 CEST] <FishPencil> Might be an x265 issue, but I get https://paste.debian.net/plainh/eb39ffa1 when trying to build FFmpeg with x265 [00:07:00 CEST] <Compn> what ver ffmpeg , FishPencil ? [00:07:17 CEST] <Compn> looks like x265 problem [00:07:21 CEST] <Compn> try make clean and rebuild [00:07:34 CEST] <Compn> also this channel is for developing, try #ffmpeg for questions... [00:18:45 CEST] <FishPencil> Compn: latest ffmpeg head, and latest x265 head. both were built fresh, and will do [10:40:46 CEST] <mateo`> rcombs: do you have a branch somewhere i can use to test/review the heif support ? [11:36:16 CEST] <paveldimow> q [12:12:59 CEST] <jkqxz> ZhongLi: Yeah, sorry about that collision. The range one could be applied anyway, but given that it now checks properly against VAConfigAttribEncQualityRange I'm not sure how useful it is (the older drivers only have a 0-2 range, anyway). [17:09:52 CEST] <cone-957> ffmpeg 03Carl Eugen Hoyos 07master:898ea658c8a4: lavc/g726: Add a little-endian G.726 encoder. [19:12:42 CEST] <wm4> fate is not failing with master, right? [19:15:54 CEST] <jamrial> wm4: it is on netbsd [19:16:14 CEST] <jamrial> other targets are fine [19:16:58 CEST] <jamrial> bah, clang since version 5 is miscompiling mjpeg, but that's been a thing for a while [19:17:15 CEST] <jamrial> i don't think anyone reported that to llvm yet [19:19:34 CEST] <wm4> seems like this was an unclean build tree (as in stale .o or .d files) [19:39:54 CEST] <jya> to the h264 experts. What do you think of this code https://github.com/video-dev/hls.js/blob/master/src/demux/tsdemuxer.js#L495… ; it assumes that every non-IDR slice with a type of I slice or SI I slice is a keyframe [19:40:26 CEST] <nevcairiel> that depends how you define keyframe [19:41:40 CEST] <jya> one I can start decoding from I guess [19:41:48 CEST] <jya> or feed to a decoder and I get a frame out [19:42:20 CEST] <BtbN> Usually called IDR frame I guess [19:42:49 CEST] <jya> yes, IDR. But in various streams encountere, there's no IDR NAL of any kind [19:43:13 CEST] <nevcairiel> any I frame is not a clean recovery point [19:43:51 CEST] <jya> like http://212.143.237.109:1935/ws40-v01-video/mp4:36651.mp4/playlist.m3u8 , it starts with an IDR, and nothing after that. Just SEI recovery points regularly spaced [19:44:08 CEST] <jya> and indeed, you can start decoding from those just fine [19:45:10 CEST] <BtbN> The linked code is for NDR frames. [19:45:13 CEST] <BtbN> I have no idea what that even is. [19:45:18 CEST] <jya> oh, and while on SEI recovery point, H264 spec (D.1.7 Recovery point SEI message syntax) are there particular values indicating you can't really recover from there ? [19:45:26 CEST] <jya> non-IDR [19:45:32 CEST] <jya> (I assume) [19:46:00 CEST] <wm4> <jya> one I can start decoding from I guess [19:46:00 CEST] <wm4> <jya> or feed to a decoder and I get a frame out [19:46:04 CEST] <wm4> these are different things too [19:48:26 CEST] <nevcairiel> the rules when you can start h264 decoding and when you get a clean frame out are not that easy [19:48:40 CEST] <jya> wm4: in 99% of the streams I've seen, they are one and the same [19:48:54 CEST] <nevcairiel> SEI recovery points for example mean you have to feed it a bunch of frames until you get a clean result - the SEI tells you how many. [19:49:09 CEST] <BtbN> If the extradata is stored externally, I think I and IDR are similar, if not the same [19:49:22 CEST] <nevcairiel> thats not true [19:49:29 CEST] <nevcairiel> reference frames can span over I frames [19:49:31 CEST] <nevcairiel> IDR is a clean reset [19:49:35 CEST] <jya> BtbN: as it would be with avc1 [19:50:00 CEST] <nevcairiel> ie. a P frame right after an I frame could still reference frames from before this I frame [19:50:57 CEST] <jya> the issue for my purpose, is that when demuxing data, I get a start time and a duration. you want those times to match as much as possible [19:51:56 CEST] <jya> nevcairiel: alright, then i change my definition of a keyframe, to a frame where the ffmpeg demuxer would have keyframe flag set to 1 :) [19:52:52 CEST] <wm4> that would be "one I can start decoding from", or often "something random" [19:53:45 CEST] Action: wm4 specifiably remembers ffmpeg's mkv demuxer breaking seeking in some correct webm files to "fix seeking" in broken files [19:58:01 CEST] <jya> i guess, I need some kind of method that can determine when the keyframe information found in the container is broken, and only override that info from there. [19:58:38 CEST] <jya> maybe assuming that I always want recovery_frame_cnt = 0 [19:59:27 CEST] <jya> ah! https://www.ffmpeg.org/doxygen/3.1/structH264SEIRecoveryPoint.html#a8012e2f… " Frames having recovery point are key frames. " [20:03:06 CEST] <JEEB> yea, SEI+I are flagged as "key frame" (random access point) [20:21:00 CEST] <jya> JEEB: good point, maybe I should also look if there's a I-Frame that follows [20:21:39 CEST] <jya> though, I'm sure there are streams out there with no such data, and it's expected to need a few frames before something valid comes out [20:22:23 CEST] <JEEB> yea, many containers really lack a mechanism of noting intra refresh [20:22:42 CEST] <JEEB> as in, "you can start everywhere as long as you are X pictures before the point you want to get to" [20:22:52 CEST] <jya> my problems here is really for hls (mpeg-ts) streams converted into MP4 [20:27:22 CEST] <BtbN> yay, getting ma CPU replaced. [20:28:47 CEST] <wm4> the real problem is the web and their funny protocols [20:29:09 CEST] <BtbN> just stream in mp4 directly [20:29:16 CEST] <BtbN> makes hls.js a whole lot less insane [20:43:22 CEST] <jya> BtbN: for adaptative streaming, hls is super simple to implement as opposed to dash players [20:43:37 CEST] <jya> as far as content providers are concerned [20:43:50 CEST] <BtbN> HLS supports fragmented mp4 [20:44:01 CEST] <BtbN> Which removes most of the insanity hls.js is doing [20:44:42 CEST] <jya> BtbN: mp4 hls streams are almost unheard of. First is super new, and everyone has been deeply involved with ts anyway [20:44:50 CEST] <BtbN> YouTube uses them [20:44:57 CEST] <jya> the crazy thing with HLS, is that segments aren't required to start with a keyframe [20:45:09 CEST] <JEEB> DASH doesn't require that, either [20:45:10 CEST] <JEEB> AFAIK [20:45:20 CEST] <JEEB> the first sample doesn't have to be a RAP [20:45:21 CEST] <jya> on mobile maybe, you can't stream HLS with youtube from desktop [20:45:41 CEST] <BtbN> as long as you indicate in the key-segments in the playlist, I don't see an issue with that [20:45:43 CEST] <jya> JEEB: it used to, though to ease compatibility with HLS, that was removed from the spec [20:45:58 CEST] <BtbN> I think hls.js supports fmp4 in hls just fine. And I'd much rather use that insteas of remuxing ts in JavaScript [20:46:39 CEST] <jya> and for quite a while, chrome was buggy and failed to correctly play any streams not starting with keyframe. so people started to tag every single frames as keyframe. that caused heaps of issues. Hence, why in FF, I had to stop relying on the mp4 sample tables to determine of a frame was a keyframe or not [20:47:12 CEST] <JEEB> jya: ah right. I remember my friend herping a derp at google for that bug [20:47:15 CEST] <jya> BtbN: but the fact is, even if hls.js does support it, there are almost no content using fmp4 [20:47:46 CEST] <BtbN> why would that matter? ffmpeg can produce it just fine [20:48:02 CEST] <RiCON> nginx-vod-module too, a fork at least [20:48:07 CEST] <jya> because people play what's available on line, and not produce their own content? [20:48:24 CEST] <BtbN> If they play what's available online it's most likely an mp4 anyway [20:48:34 CEST] <BtbN> Only ever seen HLS being used for livestreams [20:51:28 CEST] <jya> BtbN: you'd be surprised. [20:51:55 CEST] <jya> plenty of content provider only care about hls, and use stuff like HLS.js to play their content [20:52:48 CEST] <jya> Dailymotion, TED, NYJ, etc [20:53:01 CEST] <wbs> BtbN: for content to be played on iOS (within an app), apple mandates that it uses hls (so that it can play on lower bitrate connections etc) [20:53:34 CEST] <wbs> so due to ios, "everybody" has to have hls, and once you have that, hls.js is a pretty neat way to not have to provide the same content in too many other formats [20:53:38 CEST] <jya> BtbN: with mobile exploding, HLS is the best common denominator. Have HLS, and you can stream everywhere to any clients [20:56:15 CEST] <BtbN> I'd still rather create HLS with fmp4. [21:14:39 CEST] <wbs> BtbN: that's only supported on ios >= 10 (which otoh has got a pretty big marketshare), but not e.g. on android, so it's not at all the same common denominator [21:22:10 CEST] <JEEB> doesn't exoplayer support it? [21:22:20 CEST] <JEEB> which pretty much all mobile playback apps use on android [21:29:49 CEST] <wbs> well that's probably doable, and with hls.js you could do that in a browser as well, but not just straight in a <video> [21:30:07 CEST] <BtbN> you can, in Safari and MS Edge! [23:20:51 CEST] <cone-343> ffmpeg 03Michael Niedermayer 07master:bc488ec28aec: avcodec/me_cmp: Fix crashes on ARM due to misalignment [00:00:00 CEST] --- Tue Aug 22 2017

1 0

ffmpeg.log.20170821
by burek 22 Aug '17

22 Aug '17

[04:59:21 CEST] <vans163> hello. is there a way to know what kind of YUV420 colorspace was used? [04:59:43 CEST] <vans163> I see there is 3 predominant kinds, and on my decoder I am getting some blurry text, but decoding with VLC is fine [04:59:51 CEST] <vans163> I am wondering if this can be the issue? [06:22:10 CEST] <dan3wik> Anyone know of a low latency, low bandwidth video format or system that they could point me to? [06:22:41 CEST] <dan3wik> It needs to be embeded in a website. [06:23:10 CEST] <dan3wik> Right now we are using mpeg1video but I would prefer if we had something more up to date. [06:25:51 CEST] <dan3wik> The hardware we are using can encode accelerated h264, but I heard that h264 needs full framesets before it can start to render them meaning it would add at least 2 seconds latency. [06:34:46 CEST] <Wallboy> I have a video with a SAR of 4:3 and a DAR of 16:9. When playing it back in MPC it displays as 16:9. My video chain currently scales a video to a 16:9 aspect resolution while maintain the original aspect and adding black bars if needed like so: "[0:v]scale=640:360:force_original_aspect_ratio=decrease,setsar=sar=1/1,pad=640:360:(ow-iw)/2:(oh-ih)/2[out]" [06:35:13 CEST] <Wallboy> However when the SAR and DAR differ like this, the encode "squishes" the video down to 4:3 [06:35:38 CEST] <Wallboy> i'm sure it's just a matter of putting setsar or setdar in the correct spot to fix the problem [06:42:04 CEST] <kerio> dan3wik: h264 can be encoded with one frame of latency [06:42:17 CEST] <kerio> by doing some Advanced Magic [06:42:44 CEST] <dan3wik> The encoding isn't the issue, its the browser side I'm having issues with [06:42:58 CEST] <dan3wik> There doesn't seem to be a low latency player available [06:43:53 CEST] <kerio> yeah the best you can do is webrtc [06:49:15 CEST] <dan3wik> kerio, what would the browser support be for something like that? [06:49:26 CEST] <kerio> chrome and firefox [06:49:42 CEST] <dan3wik> Ok, know of any it wont support? [06:50:25 CEST] <dan3wik> And, what about moobile support? [08:04:05 CEST] <robswain[m]> Webrtc with h264 will be supported in the next Safari release with iOS 11/macOS high sierra [08:04:25 CEST] <robswain[m]> And webrtc is supported in chrome on android [08:04:58 CEST] <robswain[m]> dan3wik: ^ [08:05:54 CEST] <dan3wik> ok [08:06:15 CEST] <dan3wik> I'm looking into it right now, it seems relatively easy to implement. [08:15:07 CEST] <Casper> Hi there, is there a way to rotate a video without reencoding? My guess is nope... but who knows... [08:59:24 CEST] <Cracki> your guess is right, generally. [08:59:48 CEST] <Cracki> some container formats (mov, mp4?) allow setting transform matrices, so you can rotate this way [09:00:05 CEST] <Cracki> it's like rotating a jpeg image by setting metadata. [09:00:23 CEST] <Casper> and supported by all players? or select few? [09:00:37 CEST] <Cracki> some players disregard such information, as I'm sure you've seen when taking photos and looking at them [09:01:41 CEST] <Casper> and I guess windows media player will ignore it... [09:01:42 CEST] <Cracki> I have no idea whether this is mandatory behavior, and for which container formats, or if whatever video codec you used can take this information either [09:01:49 CEST] <Cracki> don't guess. [09:01:50 CEST] <Cracki> try. [09:02:01 CEST] <Cracki> research this. [09:02:14 CEST] <Casper> do you have some link about it? [09:02:42 CEST] <Cracki> https://ffmpeg.org/pipermail/ffmpeg-devel/2009-November/076928.html [09:02:46 CEST] <Cracki> this is something I just found [09:03:16 CEST] <Cracki> I know of the existence of that metadata because I implemented some mov/mp4 parsing for my own purposes and saw it in the documentation of the mov format [09:03:28 CEST] <Casper> ok thanks will look into it [09:04:01 CEST] <Cracki> https://developer.apple.com/library/content/documentation/QuickTime/RM/Movi… [09:04:09 CEST] <Cracki> somewhere on that domain is the mov file spec [09:04:17 CEST] <Cracki> mp4 is a subset of mov, afaik [09:04:36 CEST] <Cracki> (probably not exactly) [09:05:01 CEST] <Cracki> https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QT… [09:05:27 CEST] <Casper> thanks will check that tomorrow [09:05:43 CEST] <Casper> now I should kick myself to do the dishes, then hit the bed... [09:05:53 CEST] <Casper> don't want to, as every night [09:06:24 CEST] <Cracki> always lick the dish you finish. less cleanup [09:10:04 CEST] <Cracki> mvhd/tkhd contain a 3x3 matrix https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QT… [10:32:05 CEST] <flux> when muxing h264 to mp4, how does ffmpeg find the codec configuration ("extradata")? when I try to do it (well, just really open h264), extradata ends up being null. [12:59:20 CEST] <paveldimow> save [13:05:51 CEST] <styler2go> Can i somehow transcode rtsp to mjpeg on the fly? [13:32:49 CEST] <Fyr> guys, what is h264_mp4toannexb option for? [13:33:59 CEST] <jkqxz> Changing H.264 from MP4 format to Annex B format. [13:34:24 CEST] <Fyr> jkqxz, does FFMPEG do it by default when remuxing from MP4 to TS? [13:35:19 CEST] <jkqxz> Yes. [13:35:30 CEST] <Fyr> great [13:35:39 CEST] <furq> it does now [13:35:47 CEST] <furq> if you're on an old ffmpeg you'll need to specify the option [14:12:53 CEST] <styler2go> Can i somehow convert a rtsp to html5 video? [14:15:24 CEST] <BtbN> "html5 video"? [14:15:27 CEST] <BtbN> So, an mp4 file? [14:46:59 CEST] <styler2go> BtbN, yes [16:22:03 CEST] <nivoh> hey guys (8 [16:22:59 CEST] <nivoh> im trying to understand how to use ffmpeg, is there any guide or something? [16:23:35 CEST] <nivoh> need to re encode a flv file into an avi one [16:30:43 CEST] <klaxa> nivoh: ffmpeg -i input.flv output.avi [16:33:44 CEST] <nivoh> thanks [16:33:51 CEST] <nivoh> but i dont get how to install it [16:35:53 CEST] <Nacht> nivoh: What OS do you want to install it ? [16:38:34 CEST] <nivoh> im in w8 [16:40:03 CEST] <Nacht> nivoh: You can download a build here: https://ffmpeg.zeranoe.com/builds/ [16:40:37 CEST] <Nacht> It's a ZIP file with the binaries in it. Just unpack it where you like, and you can run the executables from there. [16:41:51 CEST] <Nacht> If you wish to be able to use ffmpeg from any path when you're using cmd, be sure to add the path where you unpacked the executables to your PATH in your environment variables [16:42:45 CEST] <Nacht> Here's a simple website explaining it all: http://adaptivesamples.com/how-to-install-ffmpeg-on-windows/ [17:19:19 CEST] <nivoh> thanks dude (: [18:55:24 CEST] <kerio> where can i find some docs related to ffvhuff/huffyuv? [18:55:48 CEST] <kerio> a paper or something, maybe? something citable [19:02:42 CEST] <pgorley> kerio: have you tried google scholar? [19:03:07 CEST] <pgorley> not sure what you're looking for, but a few links turn up [19:03:09 CEST] <JEEB> kerio: IIRC it was just huffman coding and some intra prediction [19:04:28 CEST] <kerio> pgorley: lmao, this article cites ffvhuff as `FFMPEG [Online]. Available: http://www.ffmpeg.org` [19:04:34 CEST] <kerio> thanks fam [19:04:39 CEST] <kerio> 10/10 bibliography [19:04:46 CEST] <JEEB> kerio: https://wiki.multimedia.cx/index.php/HuffYUV [19:06:32 CEST] <JEEB> and I think ffvhuff is similar [19:10:03 CEST] <dbogdanov> Hello. I want to build a shared library linking with a static libavcodec.a. I get an error: "libavcodec.a(deinterlace.o): relocation R_X86_64_PC32 against symbol `ff_pw_4' can not be used when making a shared object; recompile with -fPIC". However, I can't manage to build ffmpeg to fix this error. I've tried --enable-pic flag. Anybody can help? [19:12:37 CEST] <JEEB> dbogdanov: have you made sure you cleared your build directory when adding enable-pic? [19:16:13 CEST] <dbogdanov> Yes I did [19:17:06 CEST] <dbogdanov> It appears to be an old problem: http://libav-users.943685.n4.nabble.com/Libav-user-compiling-ffmpeg-with-fP… [19:18:12 CEST] <JEEB> right, if you want to create a thing a la "libffmpeg.so" then you should take a look at the patchwork/mailing list [19:18:20 CEST] <JEEB> there recently was a patch posted for that purpose :P [19:18:32 CEST] <dbogdanov> In that thread somebody proposed a patch, but it seems to be an ugly workaround. [19:18:46 CEST] <JEEB> anyways, on ARM things seem to work for me just fine :P [19:18:50 CEST] <dbogdanov> why won't --enable-pic work? [19:19:26 CEST] <JEEB> I don't know, it has worked for me so far :P otherwise VLC's contrib system wouldn't work either [19:19:59 CEST] <iive> dbogdanov: are you using recent ffmpeg ? [19:19:59 CEST] <dbogdanov> I am building with ffmpeg-2.8.12 [19:45:56 CEST] <dbogdanov> Solved that by adding -Wl,-Bsymbolic flag to linker [19:46:00 CEST] <dystopia_> is there anyway to set force-cfr=1 with a copy? [19:46:09 CEST] <dbogdanov> Thanks, JEEB [19:46:25 CEST] <dystopia_> ffmpeg -i %input% -acodec copy -vcodec copy out.mkv [19:46:37 CEST] <dystopia_> ^input = cfr, output=vfr [19:49:58 CEST] <furq> dystopia_: is the input an mp4 [19:50:35 CEST] <furq> some tools will show 23.97/29.97fps material in mkv as vfr because the frame timings aren't constant [19:52:48 CEST] <dystopia_> in put was hevc .ts [19:54:38 CEST] <furq> the output probably isn't actually vfr then [19:54:58 CEST] <furq> i mean technically it is but it's as close as matroska can get to the input framerate [20:03:35 CEST] <JEEB> and mpeg-ts is limited to 90 kilohertz in timestamps as well [20:03:41 CEST] <JEEB> fun times [21:01:45 CEST] <_blinsay> hey y'all, i'm having some issues with the concat demuxer producing corrupt output with mp4s/h.264 [21:02:40 CEST] <_blinsay> the two videos i'm trying to combine both seem to have have the same framerate/encoding and all that jazz [21:03:25 CEST] <_blinsay> using a -filter_complex with the concat filter and the same two produces correct output [21:04:04 CEST] <durandal_1707> corrupt in what sense? [21:04:28 CEST] <_blinsay> the video doesn't play smoothly, blocks of solid color start appearing in it [21:07:07 CEST] <_blinsay> https://www.dropbox.com/s/9fwdkje4gdkk4tq/corrupt_moon.png?dl=0 [21:30:42 CEST] <cryptodechange> Are there any filters that can correct 'shaky' footage, clearly taken from a film? [21:31:13 CEST] <cryptodechange> I have applied some slight degraining to reduce bitrate, but it has made the wobble from whatever they used to convert from original film more apparent [21:44:08 CEST] <Dan203> I'm upgrading some software from using the v2 libs to v3. I'm trying to stamp out some of the depreciated stuff. But one issue I'm running in to is in the muxer. In the code I call avformat_new_stream to add a stream to the formatcontext, then I use the avstream->codec to set the various options I need for the codeccontext. However there is a warni [21:44:09 CEST] <Dan203> ng in v3 that the codec pointer is depreciated. So what is the new way to get the codeccontext for a avstream? [21:46:20 CEST] <Mavrik> Dan203, codecpar I think [21:50:05 CEST] <Dan203> Mavrik, that doesn't have all of the same options as CodecContext. Plus, according to the comments, if you call avformat_new_stream you're suppose to call avcodec_close on the created context. I can't do that unless I have some way to get the conext [22:22:00 CEST] <c7j8d9> Anyone knowledgeable in colorspace? Converting an VP9.2 video to HEVC 10bit I get flat colors with bt2020nc and closer to original colors with bt2020c. Are there better settings for HDR? (ffmpeg -hwaccel cuvid -i "HDR Input" -c:v hevc_nvenc -pix_fmt p010le -colorspace bt2020nc -color_primaries bt2020 -color_trc smpte2084 -rc constqp -qp 16 -c:a ac3 "Output.mp4") [22:22:23 CEST] <JEEB> Dan203: git grep "from_context" doc/examples/ [22:22:41 CEST] <JEEB> the examples have plenty of ways to get codec parameters from an avstream etc [22:23:53 CEST] <JEEB> c7j8d9: the question is how you're dealing with your content and what is the input/output [22:24:12 CEST] <JEEB> (also cuvid can be fscking with you just as fine as well) [22:27:11 CEST] <c7j8d9> Can you explain "dealing with your content"? [22:27:35 CEST] <c7j8d9> Do you know the difference between bt2020 constant and non constant? [22:27:46 CEST] <JEEB> in general yes, constant and non-constant luminance [22:27:51 CEST] <JEEB> most content is NCL because of course [22:28:06 CEST] <JEEB> that should be in the input metadata though, not a thing for any sort of debate [22:28:50 CEST] <JEEB> what I'm trying to say is tell us what you exactly want to do, and then we go through the chain of events [22:29:54 CEST] <c7j8d9> I downloaded vp9.2 video from youtube to play on my tv in hevc hdr10 since it won't play the vp9.2 file [22:30:18 CEST] <JEEB> ok, so you actually do not want to do any conversions and just want to re-encode it [22:31:23 CEST] <c7j8d9> yes...am I forcing conversions by specifying colorspace, primaries and trace? [22:31:59 CEST] <JEEB> those are just metadata forcing things as far as I know, unless they have some special meaning with that specific HW encoder [22:32:37 CEST] <JEEB> now, what colorspace values are you getting from the input and what sort of input is given by the HW decoder? also, does that HW decoder result go through some really insane conversion logic between the input and output. -v debug generally makes the thing spam a whole lot more but you should be able to see if any insane filter chains are going on [22:33:24 CEST] <JEEB> post a full -v debug log or so on pastebin.com (or anything similar) and link here [22:34:14 CEST] <paveldimow> Hi, can I analyze mp4 file so I can find what's the key frame interval? [22:34:57 CEST] <JEEB> L-SMASH's boxdumper or ffprobe's -show_frames or -show_packets with limitation on the video track [22:35:28 CEST] <JEEB> you can combine that with the -of json output to make it more digest'able by a script if you want to script it [22:35:47 CEST] <paveldimow> JEEB: You are the king! [22:36:35 CEST] <durandal_170> he is little peasant in field [22:38:46 CEST] <paveldimow> Well he helped me many times before, so for me he is a king :) [22:43:12 CEST] <c7j8d9> JEEB: is this enough info? https://pastebin.com/Mrwxqcgk [22:44:05 CEST] <JEEB> [auto_scaler_0 @ 00000000055b9560] picking yuv420p out of 2 ref:yuv420p10le alpha:0 [22:44:08 CEST] <JEEB> [auto_scaler_0 @ 00000000055b9560] w:3840 h:2160 fmt:yuv420p10le sar:0/1 -> w:3840 h:2160 fmt:yuv420p sar:0/1 flags:0x4 [22:44:11 CEST] <JEEB> my condolences :P [22:44:26 CEST] <JEEB> oh, that's ffplay [22:44:29 CEST] <JEEB> why are you doing that? [22:44:42 CEST] <JEEB> there's no way ffplay will play that sort of content correctly [22:45:23 CEST] <c7j8d9> sorry...getting my feet wet with ffmpeg [22:45:34 CEST] <JEEB> use latest mpv that can tone map down to SDR if you want a "proper" rendering of HDR content [22:45:42 CEST] <c7j8d9> do if ffmpeg -i input -v debug? [22:46:11 CEST] <JEEB> (although since tone mapping is not standardized in any way you cannot use it too much as a 'reference') [22:46:28 CEST] <JEEB> (since all hardware and software will be doing it differently) [22:46:44 CEST] <JEEB> c7j8d9: yes the idea was to get your ffmpeg command with your parameters - with the added -v debug in there [22:46:51 CEST] <JEEB> so that the verbosity level was higher [22:47:35 CEST] <c7j8d9> oh...when I convert? I was way off [22:48:21 CEST] <c7j8d9> is mpv different then mpc? [22:48:28 CEST] <JEEB> yes [22:49:09 CEST] <JEEB> mpv is 100% open source (as opposed to mpc using the DShow media framework and whatever you have registered there), and has the least retarded video rendering framework that's available in any open source video player as far as I know [22:49:17 CEST] <JEEB> lachs0r does windows builds [22:49:27 CEST] <JEEB> https://mpv.srsfckn.biz/ [22:49:40 CEST] <wolfy__> Hi! What is the best approach to perform byte seeking when seek via timestamp (by using av_seek_frame()) is not available? In my case, it is feasible to preprocess the input video by iterating through all AVFrames. I read that AV_SEEK_BYTE doesn't always work. [22:49:43 CEST] <wolfy__> I tried to use the approach described in the link below but I did not succeed, I populated a (timestamp -> byte) map, such that "byte" is the byte offset of the last read key frame while preprocessing the video. The frame that I obtain after performing the seek comes way before the target, there are lots of key frames between them. https://stackoverflow.com/a/3062994/351527 [22:50:22 CEST] <JEEB> c7j8d9: you can just extract and test by drag and dropping a file on top of mpv.exe. if you want hwdec to be utilized you will have to add --hwdec=dxva2-copy [22:51:03 CEST] <JEEB> "normal" dxva2 will go through funky automated dxva2 routines which will not give the original YCbCr to the renderer [22:59:23 CEST] <c7j8d9> JEEB: https://pastebin.com/G6RLEG1v [23:01:38 CEST] <c7j8d9> this time the color looks the same even using bt2020nc [23:03:51 CEST] <JEEB> that looks like swdec for the VP9, which should in theory be more less of "what the fuck is it doing" [23:04:04 CEST] <JEEB> what I am interested in is how the yuv420p10 conversion is being done [23:04:27 CEST] <JEEB> as in, yuv420p10 to p010le [23:04:35 CEST] <JEEB> which should just be byte packing [23:04:53 CEST] <JEEB> (yuv420p10 is fully planar, p010le is a semi-packed format) [23:08:28 CEST] <JEEB> also do double-check if the nvenc hevc encoder actually writes the metadata [23:08:53 CEST] <JEEB> if you ffprobe the file that was generated, if you get the correct colorspace values and MaxCLL/MaxFALL etc [23:17:03 CEST] <c7j8d9> JEEB: https://pastebin.com/zzUSChy9 [23:19:26 CEST] <JEEB> try with -v debug although it seems like the additional metadata was not passed through the nvidia encoder [23:19:43 CEST] <JEEB> basics are there, though [23:19:45 CEST] <JEEB> tv, bt2020nc/bt2020/smpte2084 [23:20:49 CEST] <c7j8d9> me/ being an impatient person quit the encoding early to paste the output [23:21:02 CEST] <JEEB> that should be OK as you can decode it fine [23:21:10 CEST] <JEEB> the extradata thing should be written at that point anyways [23:21:59 CEST] <JEEB> but yes, that result agrees with what I see in the nvenc hevc encoder, it just doesn't utilize the additional colorspace metadata [23:22:22 CEST] <c7j8d9> https://pastebin.com/hCPM3apy [23:22:55 CEST] <JEEB> so there's two possibilities: fuckery in the yuv420p10 -> p010le conversion (which should be lossless in theory since the data should be the same, just located differently in the buffers) or it's just the usual HDR playback bullshit. [23:23:47 CEST] <JEEB> yea, that's as expected now. since the nvenc hevc encoder doesn't handle the additional values. [23:24:05 CEST] <c7j8d9> additional colorspace metadata being the luminance and macll maxfall stuff? [23:24:35 CEST] <c7j8d9> the usual HDR playback BS is what? [23:25:07 CEST] <JEEB> that everything can play things differently yet they could all be correct [23:25:19 CEST] <JEEB> due to things like tone mapping etc not being standardized [23:25:40 CEST] <JEEB> so your TV, mpv and random other software could all claim they're correct at playback but they might not look similar [23:26:17 CEST] <JEEB> ok, libx265 doesn't seem to utilize the side data containing the maxfall/maxcll etc stuff [23:26:20 CEST] <JEEB> either [23:26:28 CEST] <Mavrik> Hmm, interesting question here - how does that work in terms of HDMI? [23:26:52 CEST] <Mavrik> If you have a HLG/HDR10/Dolby HDR content, do AVRs break that/need explicit support? [23:27:13 CEST] <JEEB> Mavrik: HDMI has various values. I know a lot of hardware just passes the YCbCr as-is with the required metadata [23:27:42 CEST] <JEEB> and other things convert to RGB and then note it as SMPTE ST.2084 / BT.2020 [23:28:48 CEST] <Mavrik> So for example you have an AVR that doesn't support HLG, but you have a player and TV that does - is metadata standard and gets passed through, or does it get stripped? [23:28:57 CEST] <Mavrik> Can't really find documentation on all that :/\ [23:29:05 CEST] <JEEB> what was an AVR again? [23:29:29 CEST] <Mavrik> Oh, AV Receiver [23:29:41 CEST] <Mavrik> Or any other such device that does switching or audio stripping [23:30:35 CEST] <JEEB> right. if it isn't doing "dumb" passthrough or cannot handshake the correct metadata it might just ASDF ASDF - or the feeding side just wouldn't be able to set the correct values as the protocol solving wouldn't finish [23:31:15 CEST] <JEEB> not that I'm any good at HDMI specifics - the last time I tried to look into how you could control what a HDMI device would output led to a lot of pain and giving up [23:31:59 CEST] <Mavrik> Yeah, that's the part I can't find any good info on - what to receivers actually do with HDMI signal [23:32:13 CEST] <JEEB> so at this point I think the only way to test is to find a GPU+screen that lets you use the new D3D HDR APIs [23:32:26 CEST] <JEEB> and then in actual full screen you can switch to SMPTE ST.2084/BT.2020 [23:32:38 CEST] <JEEB> since you have full control of the full screen environment [23:32:52 CEST] <JEEB> (there previously were nvidia-specific APIs for this) [23:33:17 CEST] <Mavrik> hmm, I have a nVidia 970 connected through an AVR to a 4K/HDR TV, so I guess I could go look for test cases [23:33:17 CEST] <JEEB> but yea, depends on if the protocol handshakes pass with such stuff. [23:33:40 CEST] <JEEB> and of course you'd have to make sure that it works correctly without the AVR in the middle [23:33:54 CEST] <JEEB> which can be fun to decide as well :D [23:33:56 CEST] <Mavrik> This whole HDR mess seems to be worse than the usual protocol problems :/ [23:34:02 CEST] <JEEB> yes [23:34:14 CEST] <Mavrik> I wonder what kind of BS will Apple do on their new AppleTV [23:34:14 CEST] <JEEB> tone mapping not being specified alone leads to quite different results [23:34:19 CEST] <Mavrik> Fourth standard? :P [23:35:48 CEST] <chance> Hi, I am trying to find a command that shows me the max bitrate of a video file. I have searched to hard to find this function, but no luck. Do any of you guys have ideas? [23:36:15 CEST] <JEEB> chance: the maximum bit rate is always dependant on over what you calculate it [23:36:25 CEST] <Mavrik> Yeah, that's what I wanted to ask - what's the window [23:36:35 CEST] <chance> Could you explain what that means? [23:36:37 CEST] <JEEB> usually you have a buffer size over which your maxrate would be calculated [23:36:44 CEST] <JEEB> otherwise your question makes no sense [23:37:03 CEST] <chance> Okay, so you sample small parts of the video? [23:37:19 CEST] <Mavrik> Yes, and the depending on how big your part is, that's what your number will be [23:37:25 CEST] <Mavrik> So it'll differ [23:37:41 CEST] <chance> What's the best way to estimate this then? [23:38:01 CEST] <JEEB> depends [23:38:10 CEST] <JEEB> I mean, what kind of buffer is relevant to you [23:38:31 CEST] <c7j8d9> thanks JEEB ... good food for thought [23:38:57 CEST] <chance> I want to make sure "VOD content the peak bit rate SHOULD be no more than 200% of the average bit rateaccording to HLS standards [23:39:10 CEST] <JEEB> yes, but that is always according to your buffer size [23:39:22 CEST] <JEEB> usually you set maxrate and bufsize when encoding to keep your encodes within such parameters [23:39:43 CEST] <chance> okay thank you [23:39:50 CEST] <Mavrik> What's a reasonable default buffer size? [23:40:00 CEST] <JEEB> or if the HLS specification defines the way of calculating the peak bit rate, that is the word [23:40:12 CEST] <JEEB> as far as I know, it doesn't [23:41:47 CEST] <DHE> there are distinct AVERAGE-BITRATE (-b) and BITRATE (-maxrate) parameters in the playlist [23:42:06 CEST] <DHE> that's how I interpret them [23:42:48 CEST] <JEEB> yes, but that still doesn't set the buffer size [23:42:59 CEST] <JEEB> over which to calculate the maxrate [23:43:18 CEST] <DHE> true. I'm not sure what the optimal value for that would be [23:43:31 CEST] <chance> I am using a Bitrate Viewer tool which shows this: https://www.filepicker.io/api/file/zi6olrRvShy29sHtaIvW?signature=ac6eadf57… [23:43:57 CEST] <JEEB> chance: the problem with those kinds of tools is that they are very opaque regarding what they mean with the values [23:44:10 CEST] <JEEB> are they calculating over a buffer? if yes, what sort of buffer? [23:44:22 CEST] <chance> Hmmm.. I will check their website [23:44:33 CEST] <JEEB> or is it a single packet's bit rate (duration of packet and amount of bits used) [23:44:43 CEST] <c7j8d9> Is there any benefit from converting bt709 to bt2020? [23:45:09 CEST] <JEEB> c7j8d9: not really. you lose compatibility and you're not going to be doing re-grading the stuff anyways [23:45:30 CEST] <c7j8d9> can you regrade with ffmpeg? [23:45:55 CEST] <JEEB> most likely not, although there's a plethora of filters. just that not many of them deal in float [23:46:25 CEST] <JEEB> which is pretty much required for keeping the over/underflowing values and the precision [23:46:33 CEST] <JEEB> when doing something like color grading :P [23:46:49 CEST] <JEEB> I have at least one UHD BD thing where the guys specifically said they took a BT.709 master and then made up the BT.2020/SMPTE ST.2084 grading [23:47:07 CEST] <JEEB> (and let's not even talk about the fact that the master was 1080p) [23:47:19 CEST] <c7j8d9> Tekno3D? [23:47:49 CEST] <Mavrik> hmm [23:47:59 CEST] <JEEB> nope, in-house by Q-Tec I think [23:49:00 CEST] <c7j8d9> Well I am kinda curious about the same thing. Taking 1080p blurays regrading to bt2020 and 10.000nit upscaling to 4k [23:49:18 CEST] <JEEB> doesn't make any sense [23:49:47 CEST] <JEEB> if you had a master it'd still be shitty but at least you'd have to make the original author give his OK on your re-grading [23:50:05 CEST] <JEEB> the upscale is just what it is, might be useful for future encoders if you did it sanely and your master was 4:4:4 [23:50:14 CEST] <JEEB> (since you could keep the 1080 worth of chroma in 2160p [23:50:29 CEST] <JEEB> re-encoding blu-rays like that just ain't making sense [23:50:37 CEST] <JEEB> but I bet people will do it [23:51:06 CEST] <JEEB> just like in the 2000s we had people applying dozens of filters on their DVD/HDTV/BD rips [23:54:31 CEST] <c7j8d9> they are "creating" 4k hdr content that doesn't exist and claim to be making better 4k hdr content than exists. [23:55:05 CEST] <c7j8d9> https://www.youtube.com/watch?v=HI06dDUEY98&list=PLXmpoI8kKMrybV4wpba9NJ-hw… [23:56:32 CEST] <c7j8d9> their stuff looks great with madvr but not that much better on my tv [23:57:25 CEST] <JEEB> well at that point it's no longer the original content and it's just someone's interpretation of how it should look as opposed to how the actual mastered content should look [23:57:45 CEST] <c7j8d9> true [23:58:06 CEST] <JEEB> I mean, similar shit has been done by GPU vendors for over 10 years now [23:58:13 CEST] <JEEB> they will inject shit into your DXVA2 chain [23:58:25 CEST] <JEEB> and do color filtering etc [23:58:54 CEST] <JEEB> this is just a fancy version of that with most likely some sort of human oversight to try and make it "look good" with the tone mapping they're applying [23:59:33 CEST] <c7j8d9> they are trying to make things look more "realistic" colors, shadows, deep blacks [23:59:46 CEST] <JEEB> well, yes. making shit up [00:00:00 CEST] --- Tue Aug 22 2017

1 0