Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

April 2019

1 participants
60 discussions

ffmpeg-devel.log.20190414
by burek 15 Apr '19

15 Apr '19

[00:04:37 CEST] <cehoyos> michaelni: Patch sent [01:08:04 CEST] <cone-831> ffmpeg 03Michael Niedermayer 07master:0ad0533e914a: avcodec/truemotion2: Fix integer overflow in tm2_decode_blocks() [01:37:59 CEST] <cehoyos> michaelni: So is the patch ok or do I misunderstand? [01:43:59 CEST] <michaelni> cehoyos, i think if you want to maintain the unused C64/FIX64 code working without changing it then uint16 instead of int16 is needed or some other change [01:45:07 CEST] <michaelni> C64() does not work with a negative signed argument as it is implemented ATM [01:46:12 CEST] <cehoyos> I didn't change C64() or did I? [01:47:45 CEST] <cehoyos> And FIX64 is unused [12:49:06 CEST] <faLUCE> Hello. When patching makefiles, how can I re-indent? I was told to avoid TABs [12:56:07 CEST] <thilo> IIRC Makefiles are an exception to the no-tabs rule for their syntax [12:58:12 CEST] <faLUCE> thilo: yes, in factI read "The TAB character is forbidden outside of Makefiles as is any form of trailing whitespace. Commits containing either will be rejected by the git repository." [12:59:12 CEST] <atomnuker> use spaces. [12:59:14 CEST] <faLUCE> thilo: but carl suggested yesterday to avoid re-indentation of makefiles [12:59:22 CEST] <atomnuker> yes, use spaces. [12:59:26 CEST] <faLUCE> atomnuker: ok thanks [13:13:34 CEST] <faLUCE> when a patch includes ffmpeg/dir1/file1 and ffmpeg/dir2/file2, which is the command for making one patch that includes both the modified files? [13:13:51 CEST] <faLUCE> (on the master) [13:17:43 CEST] <JEEB> git add dir1/file1 dir2/file2 [13:17:50 CEST] <faLUCE> thnx [13:17:51 CEST] <JEEB> git commit [13:18:18 CEST] <JEEB> then mkdir -p patches/ && git format-patch -o patches REMOTE/master..HEAD [13:18:24 CEST] <JEEB> REMOTE is usually by default origin [13:18:58 CEST] <JEEB> and generally it probably is worth it to make your own work-in-progress branch that your local master isn't with your own changes [13:20:41 CEST] <faLUCE> JEEB: wait, too many things :-) . 1) [13:18] <JEEB> then mkdir -p patches/ && git format-patch -o patches REMOTE/master..HEAD <--- what exactly does this command? [13:22:27 CEST] <JEEB> faLUCE: the && runs the other one if the first one succeeds. so you make a directory called "patches", and then the -o parameter in format-patch outputs there [13:23:01 CEST] <JEEB> and the REMOTE/master..HEAD part takes the hash of REMOTE/master and outputs patches for all commits that are locally in your tree until HEAD [13:23:06 CEST] <JEEB> HEAD being the current working tree tip [13:24:05 CEST] <JEEB> you can take a look at what `git show HEAD` outputs as an example [13:27:35 CEST] <faLUCE> JEEB: OK, but given that I would not use git-send-email, where the email info, description of the patch etc. well be put? [13:27:44 CEST] <JEEB> format-patch outputs that [13:28:20 CEST] <JEEB> git diff outputs a simple patch without authorship/commit message etc [13:28:34 CEST] <JEEB> git format-patch outputs proper `git am`'able commits [13:48:31 CEST] <faLUCE> ok JEEB, thnks, I have to learn more about that [14:19:05 CEST] <JEEB> does anyone remember if VP9 kept state over RAPs? [14:19:19 CEST] <JEEB> so if you just try to cut a VP9 stream over RAPs that you could get corruption [14:19:32 CEST] <JEEB> or more specifically, starting with a RAP in the middle of the stream [14:39:21 CEST] <jkqxz> A key frame in VP9 clears all state. [14:39:41 CEST] <JEEB> ok, so cutting and then stitching on a RAP should be OK then [14:40:06 CEST] <JEEB> I don't remember which format I was talking about where this was not true and the coder state was dependant on previous frames [14:40:16 CEST] <JEEB> on of the VPx or AV1 [14:40:34 CEST] <jkqxz> Nothing would stop you marking a non-key intra-only frame as a RAP in VP9, but I don't think anyone does that. [14:41:05 CEST] <BBB> av1 has invisible keyframes [14:41:10 CEST] <BBB> which don't clear state until they become visible [14:41:15 CEST] <BBB> as a show-existing-frame reference [14:41:20 CEST] <BBB> and then hevc also of course [14:41:22 CEST] <JEEB> yea, I was mostly considering correctly mapped pictures [14:41:54 CEST] <JEEB> ok, then I wonder why I remember there being a thing about not being able to cut some formats [14:42:09 CEST] <JEEB> thanks [14:43:47 CEST] <jkqxz> H.26[45] both allow non-decodable leading pictures before a non-IDR RAP (and H.265 explicitly marks them with a different NAL unit type). [14:43:59 CEST] <JEEB> yup [14:47:46 CEST] <atomnuker> BBB: so an encoder could in theory fill all invisible frame slots and then never show them even after a keyframe? [14:49:12 CEST] <atomnuker> I seem to remember that was because of some closed gop thing, but having a broken file hog decoder memory isn't cool [14:49:44 CEST] <BBB> yes [14:49:46 CEST] <jkqxz> Showing a key frame clears all frame slots at the point it is shown. [14:49:47 CEST] <BBB> it's a delayed clear-state [14:50:07 CEST] <BBB> you can do all sort of weird stuff with this [14:50:15 CEST] <BBB> but mostly it's both dumb and innocent [14:50:23 CEST] <BBB> so it's ok I guess [14:50:29 CEST] <BBB> it's not like you can break your hardware or something [14:53:14 CEST] <atomnuker> well, filling all ref frame slots is difficult to do in av1 in the first place, so yeah, not much danger [14:55:20 CEST] <atomnuker> the sequence and naming was something completely illogical, and I'm too lazy to dig up the 2 crazy flowcharts google made to further confuse everyone [14:55:46 CEST] <durandal_1707> atomnuker: what's up? [14:55:47 CEST] <JEEB> anyone wants to look at a supposed sample of 22.2ch LATM AAC? [14:56:46 CEST] <atomnuker> durandal_1707: trying to fully complete gta san andreas [14:56:59 CEST] <JEEB> that's a fun one [14:57:17 CEST] <JEEB> not 100% sure it's valid since the provider isn't sure of the crypto but it does get as far as noting that multiple programs are not yet supported [14:59:18 CEST] <durandal_1707> atomnuker: stop wasting time on stupid games [15:20:49 CEST] <cone-372> ffmpeg 03Steven Liu 07master:b18c8688dd4f: avformat/hlsenc: flush packets before update split message [18:10:57 CEST] <philipl> JEEB, haasn: So this crap is harder than it looks. If I rename the ta_* functions from xtalloc, it will compile. I couldn't do a full static mpv build because many of the dependencies don't have static versions in Ubuntu. So I tried just linking a static libplacebo. [18:12:02 CEST] <philipl> That actually linked after the renames, but blows up at runtime because there are symbol conflicts with spriv_shader.c which exists in both code bases. Strangely it doesn't fail at link time. [18:12:13 CEST] <philipl> but it ends up calling the mpv version which then fails - no surprises. [18:12:26 CEST] <JEEB> probably wrong channel but ouch :/ [18:12:38 CEST] <philipl> whoops. [18:12:43 CEST] <philipl> I will repeat in the right channel. [20:55:31 CEST] <cone-285> ffmpeg 03James Almer 07master:62074b8f85e0: avcodec/cbs_av1: add a function to strip trailing zeroes from a buffer size [20:55:32 CEST] <cone-285> ffmpeg 03James Almer 07master:1f260d7285c8: avcodec/cbs_av1: add support for Padding OBUs [21:22:58 CEST] <thardin> so I'm staring at mxf_read_sync() and it seem it'll behave incorrectly for any UL which contains 0x06 in places beyond index 0 [21:25:37 CEST] <thardin> baptiste: do we have any sample that uses say mxf_crypto_source_container_ul[] ? [21:27:04 CEST] <baptiste> Im afraid not :( [21:27:43 CEST] <thardin> mxf_sony_mpeg4_extradata as well [21:28:01 CEST] <thardin> ah but that has a fate sample. hmmm [21:28:49 CEST] <thardin> I *really* don't like that sync thing being used for anything besides run-in [21:33:40 CEST] <thardin> I see it works because both of those are local tags [22:57:42 CEST] <thardin> hum hum.. who in here had knowledge about protools again? [23:13:53 CEST] <jamrial> jkqxz: adding support for Scalability Metadata obu to cbs_av1 should be trivial, but it will probably increase the struct size considerably [23:13:58 CEST] <jamrial> do you think it's worth doing? [23:14:58 CEST] <jkqxz> Have you found anything which uses it? [23:15:18 CEST] <jamrial> no, that's why i'm not sure it's worth implementing it :p [23:15:38 CEST] <jamrial> although something has to be first, right? :p [23:16:10 CEST] <jkqxz> Yeah, that was my position too. [23:16:36 CEST] <jamrial> the couple samples i saw using more than one spatial/temporal layers didn't have it [23:17:23 CEST] <jkqxz> If you want to do it then go ahead, but I'm happy to wait and see if anyone ever uses it. [23:17:49 CEST] <jamrial> i wouldn't mind if it wasn't so big. the struct will be like 8kb alone [23:19:06 CEST] <jkqxz> How big is the current largest thing in the OBU union? [23:20:45 CEST] <jkqxz> If all the stuff in frame header is already bigger than that then it doesn't make a difference. [23:23:55 CEST] <jamrial> let me check [23:24:25 CEST] <jamrial> biggest is frame, 1k [23:28:58 CEST] <cone-285> ffmpeg 03Marton Balint 07master:f9840cd2b501: avformat/mxfdec: use operational_pattern_ul instead of operational_pattern for metadata [23:48:01 CEST] <jamrial> jkqxz: my bad, with the new struct it will be ~3k, no 8k [23:48:08 CEST] <jamrial> considerably bigger than frame still, but not that bad [00:00:00 CEST] --- Mon Apr 15 2019

1 0

ffmpeg.log.20190414
by burek 15 Apr '19

15 Apr '19

[00:02:12 CEST] <cehoyos> JEEB: For dst, this is not a question of the "information", our decoder provides the audio with this sample rate (which is different from the one in the white paper or advertising), it cannot be changed. The same is true for some SBR files. [00:04:08 CEST] <JEEB> yes [00:04:16 CEST] <JEEB> I was mostly just responding to the question asked [00:04:38 CEST] <JEEB> regarding a decoder showing the wrong rate after probe() was done [00:05:00 CEST] <JEEB> dst is of course its own bundle of fun :) [00:05:00 CEST] <cehoyos> I finally realize there is a usecase for mediainfo ;-) [00:05:15 CEST] <cehoyos> (Or a fundamental problem about ffprobe) [00:15:28 CEST] <garyserj> I have two mp4 files, I made examples files, each one second. One uploads to youtube, one does not. If I look at the profile of each on mediainfo, I see that the bad one has encoding settings and writing library, and the good one does not. I am able to import the bad one into movie maker, and save it, and it becomes good, and has no encoding settings or writing library listed by mediainfo. [00:15:28 CEST] <garyserj> I'd like to do that with ffmpeg though. How can I do that? this is the profile of the bad mp4 https://pastebin.com/raw/XD5YnaLg and this is the profile of the good mp4 https://pastebin.com/raw/b5xqFLxy [00:16:43 CEST] <JEEB> garyserj: neither of those flags most likely has anything to dow ith whether youtube takes it in or not [00:16:53 CEST] <JEEB> otherwise everyone would have to run a patched libx264 [00:17:24 CEST] <cehoyos> garyserj: Instead please provide the command line that you used to produce the "bad" file together with the complete, uncut console output. [00:19:10 CEST] <garyserj> cehoyos: ok that will take a while.. i'll reply when done! [00:25:40 CEST] <Atlenohen> standby ... will report findings soon [00:33:21 CEST] <garyserj> thanks for waiting. here is the output of mp4 that won't upload to youtube https://pastebin.com/raw/9ap6bMfe [00:33:51 CEST] <JEEB> > 1348290000.00 tbn [00:34:07 CEST] <JEEB> this sounds like something that might cause issues down the line if it gets written into the output container [00:35:47 CEST] <garyserj> a)what does it mean b)movie maker was able to import the file and save it and the saved file uploaded to youtube. How might I 'fix' it witih ffmpeg like movie maker did? [00:36:27 CEST] <JEEB> well if it decoded and re-encoded your thing it most likely limited the time base, while somehow ffmpeg.c ended up with a humongous time base there [00:36:55 CEST] <JEEB> given that the input time base is 90k it sounds funky at the very least [00:37:43 CEST] <garyserj> so is there a flag in ffmpeg to limit the timebase or is this a bug in ffmpeg that has no flag to fix? [00:37:50 CEST] <garyserj> (or both) [00:39:16 CEST] <JEEB> I would first check a newer version of FFmpeg [00:39:21 CEST] <JEEB> since you're on 3.4 [00:39:32 CEST] <JEEB> you can find current master builds from zeranoe's for example [00:40:38 CEST] <garyserj> another odd thing is I reckon the phone i recorded the 3gp on has been oriented the correct way, yet some videos come out needinig a vflip and some needing a -vf "transpose=1" (clockwise 90 degree turn), and most don't need any turn or flip [00:40:44 CEST] <garyserj> this one didn't need any turn or flip [00:41:31 CEST] <JEEB> mobile camera stuff is fun :P [00:41:52 CEST] <garyserj> I can understand the case of vflip 'cos maybe it's possible i oriented my rectangular phone the wrong way. but 90 degrees is very strange 'cos don't place my camera on one of its small edges [00:42:04 CEST] <garyserj> 'cos don't = 'cos I don't [00:42:16 CEST] <JEEB> yea but the software might still think you're in some other mode [00:42:21 CEST] <JEEB> fun for the whole family [00:42:36 CEST] <JEEB> of course, I'm just guesstimating without knowing more about it [00:43:48 CEST] <JEEB> also the weird time base is probably due to the content being of non-constant rate (mobile phones generally tend to record "as fast as possible with a cap". so you might be hitting that cap (say, 30Hz) or something lower than that [00:43:59 CEST] <JEEB> although I'm just guesstimating without knowing the details [00:44:33 CEST] <garyserj> zeranoe has 'builds' i'm just downloading one it's about 60MB! [00:45:20 CEST] <cehoyos> I suspect the input file is vfr, I suggest you force an output frame rate with "-r 30000/1001" [00:45:31 CEST] <cehoyos> This will force a sane time base [00:45:56 CEST] <JEEB> yes, that is what I was alluding to with the long and winding explanation about mobile phone cameras recording at a non-static rate :) [00:46:07 CEST] <JEEB> "as fast as possible, with a cap" basically [00:46:07 CEST] <cehoyos> Yes, I hadn't read so far, sorry [00:46:29 CEST] <JEEB> although it's still weird so it would be interesting to know if current master handles it any better [00:46:46 CEST] <JEEB> and considering the input has 90k time base for the stream, it's kind of weird how it goes worse from that [00:46:47 CEST] <cehoyos> But thank you for proving that "complete, uncut console output missing" is still the key to such issues;-) [00:46:59 CEST] <JEEB> often it is :) [00:47:05 CEST] <JEEB> sometimes you end up needing a bit more [00:47:21 CEST] <cehoyos> I don't really expect it to work better but a test won't hurt. [00:47:32 CEST] <cehoyos> garyserj: Feel free to provide the input sample [00:47:35 CEST] <JEEB> yea, I don't think the code around there changed too much [00:47:47 CEST] <JEEB> but since there are binaries available, the test shouldn't take too long :) [00:47:57 CEST] <cehoyos> True! [00:48:19 CEST] <JEEB> also funny enough there should be a time base option both in ffmpeg.c as well as in movenc.c [00:48:28 CEST] <JEEB> so in theory one could set it to the input time base (90k) [00:48:31 CEST] <JEEB> to get a similar result [00:49:27 CEST] <cehoyos> Maybe "-r 24000/1001": Check if many frames are dropped with this value [00:49:47 CEST] <cehoyos> I think the correct solution is to force a sane frame rate [00:50:39 CEST] <JEEB> I would think a similar time base should most likely work (since 90k is used in mpeg-ts and youtube has to be taking in content straight from these devices). but yes, either vf fps=30000/1001 or -r 30000/1001 should make sure the output is of constant rate :) [00:51:05 CEST] <JEEB> (the options in ffmpeg.c are -time_base and -enc_time_base btw) [00:51:46 CEST] <JEEB> movenc.c has video_track_timescale AVOption [00:51:51 CEST] <JEEB> just for the record :) [00:52:27 CEST] <garyserj> https://pastebin.com/raw/7dTEv0by [00:52:50 CEST] <JEEB> garyserj: thanks. so yea, the logic that leads to that value is still there :) [00:53:32 CEST] <JEEB> if you are re-encoding you might attempt what cehoyos noted regarding setting output rate of 30000/1001 [00:53:39 CEST] <JEEB> which is seemingly the cap in your sample [00:54:11 CEST] <JEEB> or then if you don't want to do that, you can attempt setting the time bases for that output stream. setting the frame rate is simpler [00:54:32 CEST] <JEEB> and if you could share the sample, that could be lovely [00:54:32 CEST] <garyserj> okay, i'm an ignoramous with ffmpeg, what'd be the flag for that? And what might movie maker be using if not ffmpeg? [00:54:50 CEST] <JEEB> no idea, and it might be forcing the rate by default [00:54:58 CEST] <JEEB> since usually video editors don't output variable frame rate [00:55:03 CEST] <JEEB> (even if the input is) [00:55:39 CEST] <garyserj> so i guess i'd need the flag for setting a set frame rate [00:56:03 CEST] <garyserj> is that a 'no dea' for the second question only? [00:56:11 CEST] <garyserj> (sorry, my 'i' key is rubbish) [00:56:22 CEST] <garyserj> dea=idea [00:56:40 CEST] <JEEB> the no idea is regarding whether the thing you're talking about is also using FFmpeg in some capacity [00:56:58 CEST] <garyserj> i'd assume not [00:57:08 CEST] <garyserj> but i'm wondering what alternatives there are that software uses [00:57:11 CEST] <cehoyos> Didn't I already provide the missing "flags"? [00:57:24 CEST] <garyserj> ah ok [00:57:27 CEST] <JEEB> and setting a video frame rate can be done in two ways. either -r "30000/1001" or -vf "fps=fps=30000/1001" [00:57:42 CEST] <cehoyos> Actually not [00:57:53 CEST] <garyserj> cehoyos: yeah -r 30000/1001 [00:57:56 CEST] <JEEB> you did note the rate setting twice :) [00:57:58 CEST] <cehoyos> The second variant won't tell you if it wasn't necessary to choose such a high value [00:58:34 CEST] <cehoyos> Look at "dups", if it increases constantly, choose a lower number [00:58:39 CEST] <garyserj> okay i will try that [00:58:45 CEST] <JEEB> also the 90k time base seems to be a common thing with android [00:58:50 CEST] <JEEB> my sample from last year has that too [00:58:57 CEST] <cehoyos> If it only duplicates for the first second(s) and then stays (nearly) constant, the value is ok [01:00:55 CEST] <garyserj> https://pastebin.com/raw/zrzkSJnA [01:01:24 CEST] <JEEB> my sample ends up with "only" 22500 AVStream time_base :) [01:01:33 CEST] <garyserj> ah the file example is only one second long. But the problem exists for a three second file too or for larger [01:01:55 CEST] <cehoyos> Remove "-t 1" [01:02:07 CEST] <garyserj> how many seconds do you need? [01:02:16 CEST] <cehoyos> Yes but with the one second sample you don't know a useful value for -r. [01:02:27 CEST] <cehoyos> As many as your input has [01:02:53 CEST] <cehoyos> You can use "-f null -" instead of "-vcodec libx264 outputfilename.mp4" [01:02:57 CEST] <garyserj> okay! i'll just remove the -ss and -t completely. this will take longer. [01:03:00 CEST] <cehoyos> To speed up the process [01:03:03 CEST] <cehoyos> If you need [01:03:44 CEST] <garyserj> and isntead of -acodec i guess? [01:03:58 CEST] <garyserj> so no vcodec no acodec no output filename but -f null - [01:04:56 CEST] <garyserj> and i guess i keep the -r "30000/1001" [01:04:57 CEST] <cehoyos> "ffmpeg -i input -acodec copy -r 30000/1001 -f null -" [01:05:08 CEST] <garyserj> ffmpeg -i Apr__8_2019_WLC_C_3.3gp -f null - -r "30000/1001" [01:05:13 CEST] <cehoyos> No [01:05:41 CEST] <cehoyos> ffmpeg -i Apr__8_2019_WLC_C_3.3gp -acodec copy -r 30000/1001 -f null - [01:05:55 CEST] <JEEB> yea, the remux-only -r patch I think is still on the ML [01:06:56 CEST] <cehoyos> It wouldn't help [01:06:57 CEST] <garyserj> I am getting a lot of lines like [null @ 00000000004b8fc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 6443 >= 6443 and each time the number increases I will show the full output on pastebin link [01:07:28 CEST] <JEEB> cehoyos: yea it would just break the A/V sync of VFR input :) [01:08:46 CEST] <garyserj> https://pastebin.com/raw/EnxTqCJv [01:09:14 CEST] <cehoyos> Sorry, the command was wrong;-( [01:09:33 CEST] <cehoyos> Should have been: ffmpeg -vsync cfr -i Apr__8_2019_WLC_C_3.3gp -acodec copy -r 30000/1001 -f null - [01:09:42 CEST] <cehoyos> But don't worry, we can calculate the issue... [01:09:57 CEST] <garyserj> ok, running now, thanks [01:10:43 CEST] <cehoyos> 30000/1001 is correct [01:10:46 CEST] <garyserj> https://pastebin.com/raw/GgECKThL [01:11:17 CEST] <cehoyos> The device just needed to "warm up", it could then keep the high framerate [01:12:00 CEST] <cehoyos> I wonder if it is a bug that ffmpeg is trying to produce vfr output with "-r"... [01:12:13 CEST] <cehoyos> May be a regression [01:12:15 CEST] <JEEB> quite possible [01:12:22 CEST] <cehoyos> Sounds like one to me [01:13:06 CEST] <garyserj> heh, sounds like a star trek conversation ;-) [01:15:01 CEST] <garyserj> good stuff. hmm , I can't see an 'issues' section on the ffmpeg github page [01:15:10 CEST] <garyserj> I see bug reports link n topic, i'll check there [01:16:45 CEST] <cehoyos> Why are you interested in that topic if I may ask? [01:17:20 CEST] <cehoyos> To quote myself: Feel free to provide a sample... [01:17:27 CEST] <garyserj> well, if there's a bug in ffmpeg then I want to help resolve it [01:17:36 CEST] <cehoyos> Feel free to provide a sample [01:17:41 CEST] <garyserj> also sometimeis something is said that I don't understand now but understand later [01:17:55 CEST] <JEEB> the android mp4 samples I have seem to max out in more pleasant time bases :) [01:18:04 CEST] <JEEB> so definitely something interesting in that one [01:19:35 CEST] <garyserj> The other 3gp files I had did upload, but is it possible they had the same issue? [01:19:57 CEST] <garyserj> like the other 3gp files i had did convert to an mp4 that uploaded, but is it possible they had the same issue? [01:20:23 CEST] <garyserj> i'd rather make a new video, 'cos that one did have some peoples' faces in t [01:20:47 CEST] <garyserj> the first second didn't have anybodys' faces but seconds beyond that did [01:21:00 CEST] <cehoyos> The first second is enough [01:21:44 CEST] <Atlenohen> ... Takes a bit long to make it really nice and clear ... [01:21:58 CEST] <garyserj> ffmpeg -i -ss 0 -t 1 Apr__8_2019_WLC_C_3.3gp -acodec copy -vcodec copy sample.3gp <-- that ok? [01:22:03 CEST] <cehoyos> NO!!! [01:22:03 CEST] <garyserj> ah mean [01:22:10 CEST] <garyserj> ffmpeg -iApr__8_2019_WLC_C_3.3gp -acodec copy -vcodec copy -ss 0 -t 1 sample.3gp [01:22:15 CEST] <garyserj> with space after -i [01:22:24 CEST] <cehoyos> Either provide an input file not created with FFmpeg (!), or feel free not to provide a sample file [01:22:32 CEST] <faLUCE> cehoyos: instead of making re-indentation on the makefiles, how should they formatted? by adding spaces? [01:22:42 CEST] <cehoyos> Don't change it [01:23:10 CEST] <faLUCE> cehoyos: and what if they appear badly formatted? [01:23:21 CEST] <cehoyos> Then send a second patch that fixes the indentation. [01:24:15 CEST] <faLUCE> uhmmm but why the indentation can't be changed in the first patch? [01:24:16 CEST] <garyserj> okay so let's say i don't proviide a sample. Shall I just provide this line and its output ffmpeg -vsync cfr -i Apr__8_2019_WLC_C_3.3gp -acodec copy -r 30000/1001 -f null - [01:24:37 CEST] <garyserj> What commands with output, should I provide? [01:25:20 CEST] <garyserj> is this chat log sufficient? [01:27:01 CEST] <garyserj> here http://ffmpeg.org/bugreports.html they say if the sample file is too large, cut it down e.g. dd if=sample-file of=small-sample-file bs=1024 count=10000 [01:27:07 CEST] <garyserj> I can cut it down to 1 second with a line like that [01:31:12 CEST] <cehoyos> Please do that, than test the sample (this is very important!), then provide it [01:33:12 CEST] <cehoyos> If you decide to open a ticket (as I tried to imply, it may be better to just provide a sample), please do not share a chat log there, please do not open a ticket if you cannot provide a sample file, please test your sample file before uploading it and please don't forget to provide the command line you tested together with the complete, uncut console output, only current FFmpeg git head is supported [01:34:07 CEST] <garyserj> ok, thanks [01:36:47 CEST] <cehoyos> will you provide the sample now? If not, I will see the link in 24 hours [01:37:12 CEST] <garyserj> yeah i'll provide a sample now, just running the dd command, thanks [01:37:24 CEST] <garyserj> just fixing my path so i can run the dd command. i have some path issues! [01:41:43 CEST] <garyserj> I just made a 1MB sample with dd, dd if=Apr__8_2019_WLC_C_3.3gp of=sample.3gp bs=1024 count=1000 And even VLC won't play it [01:42:43 CEST] <cehoyos> You have to use tools/qt_faststart before using dd [01:43:02 CEST] <garyserj> i've used dd before, but not that, i'll look into that [01:43:45 CEST] <cehoyos> Just post your link here, I will see it a day later. [01:43:50 CEST] <cehoyos> Good night [01:43:52 CEST] <garyserj> okay, thanks [01:43:57 CEST] <garyserj> i'll make a 100KB sample [01:43:59 CEST] <garyserj> that's about 1 second [01:44:14 CEST] <garyserj> without the qt.. i'll be here this week too [01:44:24 CEST] <garyserj> gnight [01:44:30 CEST] <garyserj> and will post here [01:45:33 CEST] <garyserj> http://ge.tt/5JDvaYv2 [01:45:50 CEST] <garyserj> 102,400 sample1.3gp [01:49:00 CEST] <cehoyos> How did you test the sample you uploaded? [01:51:52 CEST] <garyserj> I haven't managed to test it yet 'cos I don't know the faststart command. And i'm not even sure how i'd test it for the timebase issue other than perhaps trying to run those commands on it and look for tb. but that's where I am at the moment. [01:52:09 CEST] <garyserj> sorry, should've tested it but can't yet. but i wanted to make sure you had something! [01:52:34 CEST] <garyserj> if i knew right now how to test it then i would [01:52:43 CEST] <cehoyos> Please do not provide a sample that you didn't test and please do not open a ticket without a sample! [01:52:53 CEST] <garyserj> okay. i haven't opened any ticket [01:53:03 CEST] <cehoyos> (And how is all this related to faststart??) [01:53:27 CEST] <garyserj> just that you mentioned to do qt_faststart before using dd. [01:53:33 CEST] <garyserj> but i don't know the command to do that [01:54:08 CEST] <cehoyos> tools/qt_faststart is a tool that you have to use before dd so that dd will not damage your file, faststart is an option for the mov (and mp4) muxer [02:01:47 CEST] <garyserj> can anybody advise how I can use tools/qt_faststart ? [02:05:23 CEST] <garyserj> ah i see it's fairly simple https://manpages.debian.org/stretch/ffmpeg/qt-faststart.1.en.html i just gotta get the program [02:07:43 CEST] <Atlenohen> Actually , build log proven to be useful [02:07:49 CEST] <Atlenohen> it just takes a good peek at it [02:09:59 CEST] <garyserj> I see it was integrated into ffmpeg [02:18:39 CEST] <garyserj> ffmpeg -i Apr__8_2019_WLC_C_3.3gp -codec copy -movflags +faststart largefixed.3gp Thus fixing it with faststart. I tried dd if=largefixed.3gp of=sample2.3gp bs=1024 count=1000 It plays. [02:18:47 CEST] <garyserj> here is the sample http://ge.tt/9CRTdYv2 [02:18:59 CEST] <garyserj> 1,024,000 sample2.3gp [02:48:13 CEST] <Atlenohen> btw, I found YOUTUBE to be broken with MP4 faststart, or ffmpeg aint doing it right (but it is confirmed with ffprobe), so I had to use MKV for YOUTUBE [02:51:34 CEST] <garyserj> Interestingly, when I made a sample file so dd, followed by faststart (I used the ffmpeg one), then I used the -vsync cfr line with -r ... that was given, so I Had a sample 3gp. Then I did the command I Had done to convert to mp4, the mp4 not only played fine and not only gave no tbn issue, but also, uploaded fine to youtube. [02:53:04 CEST] <garyserj> I mean.. When did dd followed by faststart(I used the ffmpeg one), then i used the -vsync cfr line with -r ... that was given, (But making a file rather than using -f null -). Then it played fine, gave no tbn issue , and most importantly, it uploaded fine to youtube. [03:18:54 CEST] <HickHoward> is Dolby AC-4 worth implementing into ffmpeg? [03:34:42 CEST] <garyserj> btw, I am not sure how I would verify the sample, but it played, and it failed to upload to youtube, so in that sense it's a good sample. [04:17:04 CEST] <furq> HickHoward: someone will implement it when they have something they want to decode with it [04:17:10 CEST] <furq> which is probably why nobody has done it yet [04:21:35 CEST] <HickHoward> well this is gonna suck [04:22:03 CEST] <HickHoward> but i don't mind waiting for that moment [07:29:17 CEST] <Atlenohen> solved it [07:29:20 CEST] <Atlenohen> report tomorrow, sleep [09:01:05 CEST] <dongs> JEEB: i have it, but i donno if decrypting it was correct. you're welcoem to the sample stream tho.https://mega.nz/#!cQsw3IAZ!VN8d_QSJDH0iu4isLqtfmX5yuy9Yjl6PGeJkMtegDzY [10:29:24 CEST] <Silicium> hi there [10:30:53 CEST] <Silicium> i dump images from a video using image2 but i want to change the output frame integer value by 20. how can i achieve that? [13:53:38 CEST] <howaboutsynergy> Can ffmpeg cut out multiple parts from an audio file with one command? eg. removing multiple ads [13:54:53 CEST] <howaboutsynergy> rather than using multiple ffmpeg invocations for each part to be removed using -ss and -to [13:54:54 CEST] <pink_mist> I would be extremely surprised if it couldn't [13:55:09 CEST] <howaboutsynergy> ok, can you tell me how? pink_mist [13:55:20 CEST] <pink_mist> no, if I knew how, I would have already done so [13:55:27 CEST] <howaboutsynergy> oh, right [13:55:30 CEST] <JEEB> you can probably do it with a filter but not with -ss / -t [13:55:32 CEST] <pink_mist> I'd check the ffmpeg-filters man pages [13:55:42 CEST] <howaboutsynergy> ok, let's check [13:55:43 CEST] <JEEB> which also means that you will have to re-encode [13:56:04 CEST] <howaboutsynergy> ohhh [13:56:05 CEST] <pink_mist> oh, well that's a bummer [13:56:24 CEST] <howaboutsynergy> yeah, I'd rather use multiple ffmpeg invocations than reencode [13:56:28 CEST] <pink_mist> unless you've got a lossless stream [13:56:44 CEST] <howaboutsynergy> nah, it's lossy [13:57:09 CEST] <howaboutsynergy> I don't need precision though, so -c copy would od [13:57:10 CEST] <howaboutsynergy> do* [13:57:38 CEST] <howaboutsynergy> ok then, thanks for the help, I'll stick to -ss and -to and multiple ffmpeg runs. [13:57:58 CEST] <howaboutsynergy> Oh, one more thing, this yields a bunch of parts, how would I merge them? [13:58:34 CEST] <howaboutsynergy> without reencoding [13:58:52 CEST] <howaboutsynergy> looks like $ ffmpeg -f concat -i mylist.txt -c copy output [13:58:59 CEST] <howaboutsynergy> yes? [13:59:42 CEST] <howaboutsynergy> I'll try [14:00:08 CEST] <pink_mist> yeah, trying it and seeing is a great way to check if something works =) [14:01:38 CEST] <howaboutsynergy> :D [14:02:01 CEST] <howaboutsynergy> just wanted to make sure there wasn't a better or more idiomatic way first ;) [14:02:42 CEST] <JEEB> you could make an app that indexes things and then processes them in one pass nicely [14:02:47 CEST] <JEEB> but ffmpeg.c currently will not do that for you :) [14:02:58 CEST] <JEEB> after all, ffmpeg.c cannot do everything you could do with the library [14:03:48 CEST] <howaboutsynergy> interesting that -ss can be used on output: "When used as an output option (before an output url), decodes but discards input until the timestamps reach position.)" I wonder if this means I don't get garbled first frames in vlc [14:04:20 CEST] <JEEB> but that only works with re-encoding [14:04:41 CEST] <howaboutsynergy> so, you mean, not with copy? [14:04:45 CEST] <JEEB> yes [14:04:48 CEST] <howaboutsynergy> got it [14:04:49 CEST] <JEEB> because you can't decode [14:05:03 CEST] <howaboutsynergy> right [14:05:15 CEST] <JEEB> with -c copy ffmpeg.c will use lavf seeking to guesstimate where the last random access point was [14:05:18 CEST] <JEEB> and copies from there [14:05:19 CEST] <howaboutsynergy> so with copy, I'm always suck with those evil video frames(when video) [14:05:34 CEST] <howaboutsynergy> stuck* [14:05:37 CEST] <JEEB> you shouldn't get garbled unless your input is marked incorrectly [14:05:54 CEST] <howaboutsynergy> what do you mean by that? [14:05:55 CEST] <JEEB> as ffmpeg.c and lavf should only seek to random access points [14:06:08 CEST] <JEEB> you shouldn't get a stream starting at a non-RAP [14:06:46 CEST] <howaboutsynergy> sounds like I shouldn't get garbled first frames ? [14:06:52 CEST] <howaboutsynergy> with copy, ever [14:07:07 CEST] <howaboutsynergy> but man ffmpeg looking at -ss kinda makes sense that I do [14:07:08 CEST] <JEEB> I wouldn't say ever since some files are mis-marked [14:07:23 CEST] <JEEB> but generally you shouldn't be getting them [14:07:28 CEST] <JEEB> unless the stream is broken [14:07:47 CEST] <howaboutsynergy> I only tested on youtube videos, downloaded with youtube-dl [14:08:15 CEST] <howaboutsynergy> I don't remember ever not getting any bad ones [14:08:31 CEST] <JEEB> I'm trying to remember if VP9 had something special that made cutting more problematic [14:10:26 CEST] <howaboutsynergy> however, vlc kinda skips a bit of the beginning on any video/audio, compared to mplayer, so I don't know [14:13:13 CEST] <JEEB> howaboutsynergy: what sort of inputs are you dealing with btw? youtube can feed you a lot of different stuff [14:17:20 CEST] <howaboutsynergy> ah, I'm not using any youtube inputs anymore, I'm currently looking at audio mp3s from grc the Security Now shows, Stream #0:0: Audio: mp3, 44100 Hz, mono, fltp, 64 kb/s ; So I don't remember what codecs the youtube vids were using [14:18:05 CEST] <howaboutsynergy> I took a look at one vid: Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv, bt709), 1920x1080, SAR 1:1 DAR 16:9, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default) [14:18:14 CEST] <JEEB> ok, so vp9 [14:18:19 CEST] <howaboutsynergy> Stream #0:1: Audio: aac (LC), 44100 Hz, stereo, fltp (default) [14:18:26 CEST] <JEEB> I don't remember if there was some thing in VP9 that made cutting it harder [14:18:40 CEST] <JEEB> like, that the coder state was not reset at RAPs [14:18:51 CEST] <howaboutsynergy> no idea [14:19:38 CEST] <JEEB> asked #elsewhere if someone would remember [14:19:48 CEST] <JEEB> because I remember having discussions on something that slightly resembles this [14:20:50 CEST] <howaboutsynergy> ok I actually found a cut vid which, in the beginning of the vid, garbles with vlc but not at all with mplayer [14:21:07 CEST] <howaboutsynergy> so, I tend to believe that maybe's a vlc issue [14:21:15 CEST] <JEEB> possible [14:21:26 CEST] <howaboutsynergy> like: [h264 @ 0x7f0d490943c0] co located POCs unavailable [14:21:26 CEST] <JEEB> but I still recall some things about these things so I'll see if someone responds [14:21:29 CEST] <JEEB> oh [14:21:30 CEST] <JEEB> that is H.264 :D [14:21:30 CEST] <howaboutsynergy> [00007f0d49052f70] avcodec decoder error: more than 81 frames of late video -> dropping frame (computer too slow ?) [14:21:50 CEST] <howaboutsynergy> oh yeah it's another vid, Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1280x720 [SAR 1:1 DAR 16:9], 1116 kb/s, 30 fps, 30 tbr, 90k tbn, 60 tbc (default) [14:22:01 CEST] <JEEB> H.264 should be cut'able on RAPs [14:22:02 CEST] <howaboutsynergy> Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 125 kb/s (default) [14:22:27 CEST] <howaboutsynergy> and I used -accurate_seek -acodec copy -aq 1 -vcodec copy [14:22:36 CEST] <JEEB> umm [14:22:43 CEST] <howaboutsynergy> the "-aq 1" is useless there right? I dno why I had it [14:22:45 CEST] <JEEB> not sure -aq 1 or -accurate_seek do anything [14:22:55 CEST] <JEEB> or latter might do something, and I wonder if it does anything good [14:23:21 CEST] <howaboutsynergy> yeah, accurrate seek is default anyway, but yeah both must be leftovers for when I didn't use copy at all! [14:23:56 CEST] <howaboutsynergy> "seeking is accurate when transcoding" [14:24:08 CEST] <JEEB> ok, seems like the value is only utilized in ffmpeg_filter.c [14:24:10 CEST] <howaboutsynergy> "which may be useful e.g. when copying some streams and transcoding the others." [14:24:22 CEST] <howaboutsynergy> so, it's useless with copy? [14:24:26 CEST] <JEEB> yes [14:24:33 CEST] <JEEB> since you can only be more "accurate" in that sense if you are decoding [14:24:45 CEST] <JEEB> howaboutsynergy: btw was your input container MPEG-TS in that case? [14:24:51 CEST] <JEEB> since I see the 90k tbn [14:25:26 CEST] <howaboutsynergy> -ss " When used as an input option (before "-i"), seeks in this input file to position. Note that in most formats it is not possible to seek exactly, so ffmpeg will seek to the closest seek point before position. When transcoding and -accurate_seek is enabled (the [14:25:26 CEST] <howaboutsynergy> default), this extra segment between the seek point and position will be decoded and discarded. When doing stream copy or when -noaccurate_seek is used, it will be preserved." [14:25:43 CEST] <JEEB> yes [14:26:44 CEST] <howaboutsynergy> yeah makes sense what you said. I don't know what the input container was when youtube-dl got it, but before cutting it was the same ".mp4" [14:27:29 CEST] <JEEB> ok [14:27:44 CEST] <howaboutsynergy> or can I run something on it that tell you more info about the container? [14:27:50 CEST] <howaboutsynergy> tells* [14:28:01 CEST] <JEEB> `ffprobe -v verbose -i FILE` gives you a general overlook [14:28:05 CEST] <JEEB> like the format etc [14:28:22 CEST] <JEEB> so for mp4 you get mp4, and then the streams etc [14:29:58 CEST] <JEEB> there are then special tools to look at the details if you need to get those [14:30:10 CEST] <howaboutsynergy> ffprobe is what I used but without the -v verbose [14:30:32 CEST] <JEEB> yea, you mostly posted the part that says something about the streams within [14:30:37 CEST] <howaboutsynergy> ok, so since vlc is the only one garbling, i guess I can rest assured it wasn't ffmpeg [14:30:50 CEST] <howaboutsynergy> Input #0, mov,mp4,m4a,3gp,3g2,mj2 [14:30:57 CEST] <JEEB> you can test decoding with something like `ffmpeg -v verbose -i FILE -f null -` [14:31:02 CEST] <howaboutsynergy> compatible_brands: isomiso2avc1mp41 [14:31:09 CEST] <JEEB> yea, so it's mp4-like [14:31:13 CEST] <JEEB> probably mp4 [14:31:28 CEST] <JEEB> which should have a global index (Generally) and proper fields for RAPs [14:31:49 CEST] <howaboutsynergy> the extension is .mp4 [14:32:06 CEST] <howaboutsynergy> encoder : Lavf58.26.101 [14:32:11 CEST] <howaboutsynergy> cool [14:32:27 CEST] <JEEB> then for various formats there's actual inspectors [14:32:39 CEST] <howaboutsynergy> I tried VLC media player 4.0.0-dev Otto Chriek (revision 4.0.0-dev-7321-gdb9131787a) [14:32:39 CEST] <JEEB> but in this case I don't think you need those :) [14:32:42 CEST] <kubast2_> Does tune makes any difference when doing lossless x264 like use -crf 0/ -qp 0 -qpmin 0 -qpmax 0 ? [14:33:00 CEST] <kubast2_> As in [14:33:05 CEST] <JEEB> kubast2_: I don't think you need to set min/max :P [14:33:09 CEST] <kubast2_> Is it possible for the output material to be different [14:33:09 CEST] <JEEB> with libx264 at least [14:33:18 CEST] <JEEB> you just set -q:v or whatever to zero [14:33:25 CEST] <JEEB> (crf zero works for 8bit) [14:33:48 CEST] <JEEB> kubast2_: I don't think anything set in tunes generally affects lossless mode too much [14:35:47 CEST] <kubast2_> I guess I can always convert the files to rawvideo and check if there's a difference [14:35:59 CEST] <JEEB> there shouldn't be :) [14:36:10 CEST] <JEEB> lossless if enabled is always lossless [14:36:38 CEST] <JEEB> at most tune fastdecode or zerolatency affect compression efficiency [14:42:29 CEST] <JEEB> howaboutsynergy: VP9 seems apparently to reset coder state on RAPs so as long as they're correctly marked it should JustWork [14:43:57 CEST] <howaboutsynergy> what's a RAP? relative access point? [14:44:09 CEST] <JEEB> random access point [14:44:22 CEST] <JEEB> because a "keyframe" talks only about a single frame [14:44:23 CEST] <howaboutsynergy> oh right, (pretending to know what that's about xD) [14:44:34 CEST] <JEEB> it does not make a promise about being able to decode what comes after [14:44:58 CEST] <JEEB> while RAP always means that what comes after in presentation order should be decode'able as well [14:47:24 CEST] <dongs> JEEB: dongs [14:48:05 CEST] <JEEB> exactly [14:48:28 CEST] <JEEB> thanks for the sample, although I couldn't parse it as LATM I think [14:49:34 CEST] <dongs> i handle 22ch shit same way as < 22ch, which is just prepend length header or wahtever [14:49:37 CEST] <dongs> and dump [14:49:40 CEST] <dongs> i donno if thats wrong or not [14:50:31 CEST] <JEEB> yea, as bit stream it should be the same so no special handling there methinks [14:50:39 CEST] <dongs> hdr[0] = 0x56; hdr[1] = 0xE0 | ((pInfo->Length >> 8) & 0xF); hdr[2] = pInfo->Length & 0xFF; [14:52:25 CEST] <furq> kubast2_: use the hash muxer if you want to compare two decoded files [14:52:50 CEST] <furq> ffmpeg -v error -i foo.mp4 -i bar.mp4 -map 0 -f hash - -map 1 -f hash - [14:53:07 CEST] <dongs> JEEB: unless it was split across separate PIDs and i didnt notice [14:53:14 CEST] <dongs> anyway, the dump there is raw dump + latm header. [14:53:21 CEST] <dongs> whats beyond it is either trash or ?? i donno. [14:53:27 CEST] <dongs> since not 100% sure of crypto either. [14:53:33 CEST] <JEEB> aye [14:53:40 CEST] <dongs> unfortunately 8K is crypto even during sleep time [14:53:45 CEST] <dongs> unlike 4K [14:53:47 CEST] <dongs> whcih is in teh clear [14:53:59 CEST] <dongs> so i don't have a baseline [14:54:27 CEST] <JEEB> yea I just noticed it mentioned something about multiple programs so the insane people might have decided to do sub-streams in LATM [14:54:36 CEST] <dongs> im back in japan so i'll be poking with this again as soon asi get my desk from exploded state [14:59:14 CEST] <JEEB> I'll probably poke a bit more on the MMTP part after I get over some other stuff I'd like to move forwards [14:59:23 CEST] <JEEB> since I think I've got TLV more or less OK [15:00:10 CEST] <howaboutsynergy> looks like -nostdin is pretty much what I always want to specify on every ffmpeg command [15:02:46 CEST] <kubast2_> furq they all have different hashes [15:03:15 CEST] <kubast2_> I did both converssion to rawvideo with the same pix format and using the hash mux [15:03:34 CEST] <kubast2_> tune modifies lossless video then? [15:03:40 CEST] <furq> by decoded i meant the decoded contents [15:03:45 CEST] <furq> you can use it on the encoded files [15:04:07 CEST] <kubast2_> Yeah I used the muxer on encoded frame/file [15:04:14 CEST] <kubast2_> Well gonna check one more thing tbh [15:04:22 CEST] <furq> are you enabling the vbv [15:04:32 CEST] <furq> x264 output is nondeterministic if you use multithreading and enable vbv [15:04:32 CEST] <kubast2_> vbv? [15:04:36 CEST] <furq> maxrate/bufsize [15:04:43 CEST] <furq> probably not if it's lossless [15:04:55 CEST] <kubast2_> I used none options for maxrate and bufsize [15:05:04 CEST] <kubast2_> And if ffmpeg uses multithreading by default [15:05:16 CEST] <kubast2_> Then yes I did use it and didn't add -threads 1 [15:05:17 CEST] <furq> well libx264 does by default [15:05:26 CEST] <furq> but one or the other is fine [15:05:29 CEST] <furq> it's just if both are enabled [15:06:27 CEST] <furq> also i guess you want -map 0:v and -map 1:v if the files have audio [15:06:50 CEST] <kubast2_> Ah I'm an idiot [15:10:04 CEST] <kubast2_> The hashes are still different, but yeah I forgot to use -crf 0 :^) [15:10:46 CEST] <kubast2_> And now I put -crf 0 in a wrong place :^) I will just open bash history file and fix it there [15:10:58 CEST] <kubast2_> And redo it as one command [15:15:44 CEST] <kubast2_> Yep [15:15:46 CEST] <kubast2_> Same hash [15:29:58 CEST] <howaboutsynergy> What do they mean here by timestamps being copied? " Note that if you specify -ss before -i only, the timestamps will be reset to zero, so -t and -to have not the same effect. If you want to keep the original timestamps, add the -copytsoption. " from https://trac.ffmpeg.org/wiki/Seeking#Cuttingsmallsections [15:30:56 CEST] <howaboutsynergy> and is that 'not' a type for 'now' ? in "so -t and -to have not the same effect" [15:31:10 CEST] <howaboutsynergy> typo* [15:33:22 CEST] <howaboutsynergy> oh i understand it now that I read the 3 explained examples which follow [15:39:03 CEST] <howaboutsynergy> I recompiled vlc, same garblage at the beginning and boy vlc changed, now I've 2 windows: one for video and one for playlist+menu. [16:19:51 CEST] <Atlenohen> JEEB,Cehoyos,furq: I had to go and document things from the get go to figure this out, infact this picture is the draft of what will be a new guide, I should have analyzed the build log earlier it turned out to be very helpful [16:20:15 CEST] <Atlenohen> https://i.imgur.com/U89cCmO.png [16:21:27 CEST] <Atlenohen> The configure file would need some updates, but this is just bare to get it working, there's a lot of stuff that's "unknown option" which I can summarize later, will probably put it all on a bug ticket [16:23:00 CEST] <Atlenohen> As for BCrypt, after I finished the graphic, I went and tried if it's the version issue, with Win10 SDK, I basically made a copy of the LIBs and INCLUDEs of Win10SDK's older version and make them to be fakes, renamed to a folder of the new version, so it took the old files, but it didn't help [16:24:19 CEST] <Atlenohen> Finally, it only struck me then at the end of that, well, why the hell don't I try forcing the bcrypt.lib and bcyrpt.h into the final program, who cares if ffmpeg doesn't compile it, I'll just put it there, that worked and sovled the whole issue. [18:15:00 CEST] <HickHoward> uhhh [18:15:00 CEST] <HickHoward> so [18:15:43 CEST] <HickHoward> has anyone ever ripped a netflix video with ffmpeg before? [18:16:52 CEST] <durandal_1707> that is illegal [18:17:15 CEST] <HickHoward> oof [18:29:03 CEST] <aboxer> I am converting h264 to h265 with this command: ffmpeg -i IN.ts -c:v libx265 -preset ultrafast -x265-params lossless=0 OUTPUT.ts [18:29:22 CEST] <aboxer> I would also like to convert ATSC closed captions [18:29:28 CEST] <aboxer> what am I missing ? [18:30:14 CEST] <JEEB> quickly looked at the libx265.c wrapper here [18:30:19 CEST] <JEEB> and I don't see it touching the side data [18:31:11 CEST] <aboxer> o o [18:31:16 CEST] <aboxer> thanks, JEEB [18:31:16 CEST] <JEEB> I mean, touching the side data that contains the captions [18:31:20 CEST] <aboxer> yes [18:31:55 CEST] <aboxer> plan B is to find an h265 sample with SEI closed captions [18:36:16 CEST] <aboxer> JEEB: is there an issue open for CC conversion for h265 ? [18:39:53 CEST] <aboxer> I found a sample file, btw: https://streams.videolan.org/streams/ts/CC/hevc_cc.ts [18:54:48 CEST] <lrusak> I'm only getting about 90fps when transcoding with vaapi, is that normal? [18:55:03 CEST] <lrusak> ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i input.mkv -c:v hevc_vaapi output.mkv [18:55:17 CEST] <JEEB> could be normal, depends heavily on what the hardware can provide [18:55:35 CEST] <JEEB> it's more than real time for a lot of stuff so I would expect that to be what's expected [18:55:51 CEST] <JEEB> (because 60Hz is usually most you get with broadcast/streaming) [18:58:14 CEST] <lrusak> Ok, it's a kaby lake i7, and the content is 23.976 [19:15:29 CEST] <jkqxz> lrusak: The default compression level in some drivers trades a lot of speed for a marginal quality gain in the encode. Try "-compression_level 100" (some large number, it'll tell you what he upper bound is). [19:25:02 CEST] <lrusak> [hevc_vaapi @ 0x564f25964200] Invalid compression level: valid range is 0-7, using 7. [19:25:25 CEST] <lrusak> I don't seem much difference though when using different vaues [20:11:19 CEST] <ncouloute> When I use the concat demuxer to combine several cfr mp4s I'm getting a variable framerate file back. Is there any way to get it to output cfr without reencoding? [20:16:14 CEST] <Ariyasu> is the frame rate the same in each file? [20:16:40 CEST] <Ariyasu> if you concat somthing thats 25fps and somthing thats 50fps, while both have cfr the output will be vfr [20:17:24 CEST] <Ariyasu> and if it's the case that your source files have differing framerates, you would have to encode to get them all to match and you probably dont want to be doing that [20:17:38 CEST] <Ariyasu> changing framerate is noramlly a bad idea [20:30:46 CEST] <ncouloute> yes each file has the same constant framerate of 60000/1001 In fact I encode them with ffmpeg at first.. then concat after [20:31:45 CEST] <JEEB> ncouloute: you should check the timestamp diffs with either ffprobe or l-smash's boxdumper [21:07:09 CEST] <ncouloute> How would I go about that. Starting at second frame the pkt_pts and pkt_dts is off. Too much info going on with ffprobe. Going to give boxdumper a shot less output [21:07:13 CEST] <ncouloute> I tried using the concat protocol and that seems to generate a file that is only slightly variable. Although that is 3 ffmpeg statments. one to mux each file to ts and then stitch the files together then remux to mp4. Another approach would be to concat during the initial encode might work be better that way. [21:46:15 CEST] <Atlenohen> Is there some kind of an explanation to the configure file [21:46:28 CEST] <Atlenohen> it's like totally undocumented of what's what [21:48:15 CEST] <Atlenohen> these tests that are being done ff.conf_9djdsnj87c.test are they even needed for building? [21:49:09 CEST] <Atlenohen> so many repeating tests in the config.log, testing what? [21:49:52 CEST] <Atlenohen> I know it generates the things and checks for valid paths but, how roughly how much is strictly necessary ? [22:34:09 CEST] <Atlenohen> install command also copies shared text files [22:34:26 CEST] <Atlenohen> but in makefile it only speifies libs and headers [23:26:54 CEST] <Atlenohen> I have received word from other people that static libs aren't going to pack other libs like bcrypt.lib anyway so it's not ffmpeg fault [23:27:33 CEST] <Atlenohen> Not sure if it's that true, however, ffmpeg's build log could be designed to output a list of dependencies that may be needed later on [00:00:00 CEST] --- Mon Apr 15 2019

1 0

ffmpeg-devel.log.20190413
by burek 14 Apr '19

14 Apr '19

[00:05:00 CEST] <mkver> Hello all. I have a question regarding inactive maintainers: What happens with patches to components whose maintainers are inactive? [00:08:37 CEST] <BBB> someone else will eventually review them [00:09:43 CEST] <mkver> Ok, then I'll simply ping the patchset. Thanks. [08:10:25 CEST] <mkver> If an error happened during writing a packet during muxing, is the user then actually allowed to simply try to mux another packet or is he supposed to end muxing altogether and write the trailer? I presume the former, but I am not sure. [08:14:10 CEST] <mkver> I'm asking because of the webm_chunk muxer. This muxer uses a Matroska/Webm muxer internally and if an error happens during writing the packet, the whole Matroska/Webm mux context gets freed. In this case a use-after-free (and also double free) also happens during writing the trailer. And depending upon the answer to my question, a use-after-free would also happen when one writes another packet after an error occurred during a [08:14:10 CEST] <mkver> packet. [08:15:05 CEST] <mkver> during writing a packet. [10:47:23 CEST] <nevcairiel> even if a call is technically wrong, it should not result in a use-after-free, so checks are needed regardless [12:57:44 CEST] <atomnuker> "The string codecs="av01.0.01M.08" in this case would represent AV1 Main Profile, level 2.1, Main tier, 8-bit content with 4:2:0 chroma subsampling, ITU-R BT.709 color primaries, transfer characteristics, matrix coefficients, and studio swing representation." [12:58:14 CEST] <atomnuker> why the cryptic codec name? that data is available elsewhere [12:59:08 CEST] <atomnuker> not like hardware decoders care about colorspace or range [13:02:10 CEST] <nevcairiel> the last part isnt even signaled in t he string, those are the defaults [13:02:20 CEST] <nevcairiel> but it can be [13:02:35 CEST] <nevcairiel> it may want to know if something is hdr vs not or such [13:09:08 CEST] <atomnuker> av01.0.05M.08, so youtube signal it [13:45:04 CEST] <nevcairiel> a full string would be something like "av01.0.04M.10.0.112.09.16.09.0" .. yours all end after the bitdepth, so no color info [13:51:06 CEST] <atomnuker> oic, still very verbose [15:03:53 CEST] <cehoyos> jkqxz: There is a GSoC proposal for an OpenCL Deshake Filte, you are listed as a possible mentor on trac - are you (still) interested? [15:05:38 CEST] <BtbN> Anyone happen to know if my Visual Studio 2017 Enterprise License will activate 2019? [15:06:03 CEST] <BtbN> I highly suspect it won't, but the Installer is offering me the update. [15:10:04 CEST] <BtbN> btw. regarding opencl filters. I guess we are no longer integrating them with the existing native filters? [15:10:18 CEST] <BtbN> Cause that OpenCL version of the colorkey filter had me wondering. [15:10:42 CEST] <JEEB> BtbN: my first guess would be not to activate although I don't think I've noticed details being written about that anywhere [15:10:54 CEST] Action: JEEB has mostly moved onto the free SDKs after leaving university [15:11:21 CEST] <BtbN> I'm still at a university, and will be for quite a while, since I work there. [15:11:44 CEST] <BtbN> But Microsoft rebranded MSDNAA/Dreamspark/Imagine/... once again, and has so far not supplied anyone with info on how to get access. [15:12:10 CEST] <JEEB> oh, they changed that again [15:13:04 CEST] <BtbN> "Azure Dev Tools for Education" is what it's called now [15:13:47 CEST] <BtbN> "Microsoft has so far failed to provide us with information on how to gain access." [15:13:55 CEST] <BtbN> That's my Unis statement about it [15:14:21 CEST] <BtbN> They're a bit pissed, because they did not fail to send the next bill [16:39:56 CEST] <durandal_1707> https://github.com/losnoco/vgmstream/issues/395 [16:55:27 CEST] <HickHoward> "i'm da badass here" [16:57:36 CEST] <durandal_1707> look at https://github.com/losnoco/vgmstream/issues/394 for explanations [17:01:57 CEST] <HickHoward> huh... [17:02:22 CEST] <HickHoward> guy's a possible terrorist by this point [17:47:05 CEST] <durandal_1707> why hevc-two-first-slice is still failing? [17:52:54 CEST] <jamrial> because whoever runs those fate clients hasn't synced the sample [17:53:30 CEST] <durandal_1707> who is responsible for it? [17:54:19 CEST] <jamrial> "mik" [17:54:46 CEST] <jamrial> i worry more about how no slot seems to have run in two days [17:55:22 CEST] <jamrial> michaelni: is there something wrong with fate? it's been two days since the last submitted result [17:56:42 CEST] <durandal_1707> ffmpeg got to big for fate [17:56:49 CEST] <jamrial> oh, nevermind, it's just that no commits were made since then [17:57:17 CEST] <jamrial> fate just discards new results if it's for the same commit as the last one [17:58:07 CEST] <durandal_1707> even if it becomes green? [17:58:37 CEST] <jamrial> no idea [18:02:14 CEST] <cehoyos> Did anybody ever look at "warning: implicit conversion from 'int' to 'int16_t' (aka 'short') changes value from 44130 to -21406" when compiling fspp with clang? [18:02:49 CEST] <durandal_1707> i ignore darkmagic filters [18:03:19 CEST] <cehoyos> I thought you wrote it;-) [18:04:15 CEST] <JEEB> could be valid depending on the values passed [18:04:51 CEST] <JEEB> or technically: is valid, but whether it affects things depends on the values passed [18:09:09 CEST] <durandal_1707> trac is unresponsive again [18:15:28 CEST] <cone-188> ffmpeg 03Paul B Mahol 07master:16f7c1f2911c: avcodec: add LSCR decoder [18:18:41 CEST] <JEEB> meanwhile brr, I really need to create that sample for that one sub2video FATE test that I wanted to add :V [18:18:52 CEST] <JEEB> that one sub2video bugfix has been sitting on the ML for a while [18:19:02 CEST] <JEEB> (use case that michael noticed) [18:19:31 CEST] <michaelni> jamrial, one of my fate client VMs died, one has a clock thats a day off, iam checking the others dunno if thats the issue [18:20:47 CEST] <jamrial> michaelni: no, it isn't. i noticed after asking you that there have been no new commits since then [18:23:42 CEST] <jkqxz> cehoyos: Yes, I've been talking to that student. [18:24:03 CEST] <cehoyos> michaelni: Does this clang warning have any real-life effect: "warning: implicit conversion from 'int' to 'int16_t' (aka 'short') changes value from 44130 to -21406" [18:24:08 CEST] <cehoyos> This is when compiling fspp [18:24:23 CEST] <cehoyos> jkqxz: Please accept the mentor invitation by Google. [18:25:40 CEST] <jkqxz> Hmm. I'm trying to log in with my account from last year, but it says I don't have one. Do I need to sign up again? [18:25:59 CEST] <cehoyos> Did you not receive an invitation? [18:26:31 CEST] <jkqxz> Where? [18:26:45 CEST] <cehoyos> sw(a)jkqxz.net [18:27:49 CEST] <cehoyos> Or to say it differently: Where do you want it? [18:28:05 CEST] <jkqxz> Ah, I do have an email. [18:28:11 CEST] <cehoyos> ;-) [18:28:32 CEST] <cehoyos> Do you know how to setup Linux so that you don't have to login locally to enable remote vaapi? [18:28:43 CEST] <cehoyos> remote: via ssh [18:29:35 CEST] <jkqxz> Use a render node? [18:30:17 CEST] <cehoyos> Sorry? [18:30:17 CEST] <jkqxz> Does it fail because you have X forwarding enabled and it tried to connect via X? [18:30:46 CEST] <cehoyos> It doesn't fail after I logged in on the system where I want to test vaapi [18:30:50 CEST] <cehoyos> Even via ssh [18:31:11 CEST] <jkqxz> Huh. What is the error? [18:31:42 CEST] <cehoyos> The error was: No VA display found for device: /dev/dri/renderD128. [18:33:01 CEST] <jkqxz> Can you strace it to find out what fails? That's a pretty generic top-level error because you don't get much feedback from libva. [18:37:09 CEST] <cone-188> ffmpeg 03Paul B Mahol 07master:a208c277f811: avcodec/imm4: flush prev_frame after seeking [18:40:34 CEST] <cehoyos> openat(AT_FDCWD, "/dev/dri/renderD128", O_RDWR) = -1 EACCES (Permission denied) [18:41:46 CEST] <nevcairiel> there may be a group your user needs to be in to access that [18:42:15 CEST] <jkqxz> Most distributions make that accessible to a group called "video". Is the user you are running as in that group when you run it? [18:43:18 CEST] <cehoyos> I see the same error after adding my user to that group [18:43:50 CEST] <cehoyos> Works after logoff-login [18:44:09 CEST] <cehoyos> I wonder why it worked locally and via ssh if I was logged in locally [18:44:21 CEST] <JEEB> something could have made the file more accessible [18:44:29 CEST] <JEEB> I just checked the rights on my fedora while logged in [18:44:32 CEST] <JEEB> http://up-cat.net/p/d5e059e7 [18:44:48 CEST] <JEEB> which seems to be rather free for the render end point? [18:44:52 CEST] <cehoyos> Anyway jamrial: Neither vaapi nor nv decode the sample(s) bit-exact, only old FFmpeg did [18:45:25 CEST] <cehoyos> The third gop of the second sample is still different with your patch. [18:47:26 CEST] <jkqxz> It's possible to have different sets of groups when logged in by different methods. When running as the user, try "id". [18:48:32 CEST] <cehoyos> Thank you! [18:49:21 CEST] <cehoyos> Feel free to click "Want to mentor" for the deshake project. [18:50:31 CEST] <jkqxz> Looking at it now. [19:04:31 CEST] <michaelni> cehoyos, the cast looks correct [19:05:39 CEST] <JEEB> that warning says implicit, so there is no explicit cast there [19:05:48 CEST] <JEEB> unless clang is missing it [19:06:09 CEST] <michaelni> theres a explicit cast in the line and a implicit one [19:06:18 CEST] <JEEB> ah [00:00:00 CEST] --- Sun Apr 14 2019

1 0

ffmpeg.log.20190413
by burek 14 Apr '19

14 Apr '19

[01:10:01 CEST] <friendofafriend> Actually communicating with the MPEG LA sounds terrifying. [01:27:35 CEST] <freemint> Hello i try to findout whether my Intel i5 8250 running fedora 29 performs harware accelartion for video. [01:28:25 CEST] <freemint> I tried figure that out by ffmpeg -i file -map 0:v:0 -c:v libx264 -f null - vs ffmpeg -i file -map 0:v:0 -c:v mpeg2_vaapi -f null - [01:29:38 CEST] <freemint> When i call anything goal codec ending in _vaapi i always get the error: [01:29:39 CEST] <freemint> Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto_scaler_0' [01:29:39 CEST] <freemint> Error reinitializing filters! [01:29:41 CEST] <freemint> Failed to inject frame into filter network: Function not implemented [01:38:55 CEST] <friendofafriend> freemint: You're talking about QuickSync? [01:39:49 CEST] <freemint> i think the technology i want to use is called libva or vaapi or vdpau [01:40:12 CEST] <friendofafriend> And you're trying to hardware accelerate encoding on your Intel CPU, yes? [01:40:27 CEST] <freemint> Encoding and decoding, yes [01:41:17 CEST] <friendofafriend> You'll find some excellent information about it, here. https://trac.ffmpeg.org/wiki/Hardware/QuickSync [01:42:55 CEST] <freemint> Is it the same as quicksync? [01:43:30 CEST] <friendofafriend> That's the term for hardware accelerated video encoding/decoding with Intel CPUs. [01:43:38 CEST] <freemint> my intel is gen8 [01:45:06 CEST] <friendofafriend> Right, so the wiki recommends you use intel-vaapi-driver from the linked repo. [01:46:28 CEST] <friendofafriend> There's a lot of example commands in the wiki, also. You'll want to make sure the ffmpeg you have supports "qsv", in the first place. [04:46:38 CEST] <Tu13es> hi folks, i have a mp4 whose audio/video goes out of sync part way through. is there a way I can adjust the video stream partway through? [04:48:09 CEST] <Tu13es> i used -itoffset to fix some initial sync issues but it goes out of sync again later in the video [15:07:02 CEST] <Atlenohen> Is it possible to disable audio of the mpegts muxer ? LATM and ADTS are added as muxers [15:07:41 CEST] <Atlenohen> Not a big deal tho [15:08:10 CEST] <cehoyos> They are a requirement [15:08:18 CEST] <cehoyos> Actually a dependency [15:08:38 CEST] <Atlenohen> Oh allright [15:09:47 CEST] <JEEB> probably in order to minimize the amount of ifdefs in code [15:11:36 CEST] <cehoyos> No, in this case the dependency was added because users protested that the mpegts muxer didn't work [15:12:18 CEST] <JEEB> :) [15:12:23 CEST] <Atlenohen> hmm, ffmpeg's configure treats .LIB files as "shared libs" and .a as static for MSVC and WIN64, while lib.exe according to everyone I talked never worked with .a files, whether shared or static [15:13:14 CEST] <JEEB> Atlenohen: yea I think in msvc nomenclature .lib is generally utilized for both the stubs as well as static libs I think [15:14:37 CEST] <Atlenohen> So my MSYS2 MINGW MSVC build attempt with x264 is stuck with these invalid .a files, they look like they're COFF (!<arch>) format but their size is too small IMO, I have more muxers/encoders and it's 3 times the size of the older library which has only 1 muxer and 1 encoder [15:15:20 CEST] <Atlenohen> So I get errors in VS2017,LNK2019 unresolved external symbol BCryptOpenAlgorithmProvider referenced in function av_get_random_seed avutil.lib(random_seed.o) [15:16:44 CEST] <BtbN> .lib and .a are virtually the same [15:16:56 CEST] <cehoyos> The error you quote is definitely not related to x264 [15:16:57 CEST] <Atlenohen> 3 times less size, the old lib is 10 MB and I have 3 MB [15:17:02 CEST] <BtbN> it's impossible to tell, other than by guessing based on file size. [15:17:29 CEST] <BtbN> Cause an import-.lib is technically also just a static lib, but only containing trampolines [15:17:44 CEST] <cehoyos> It sounds more as if you forgot to tell which native Windows libraries libavutil needs [15:17:55 CEST] <BtbN> 3MB is still way too large for it to be just an import-lib [15:18:32 CEST] <cehoyos> 3MB sounds correct for x264 [15:19:08 CEST] <Atlenohen> cehoyos: I had same kind of errors pointing to avcodec.lib(libx264.o) previously, someone else told me that static libs dependencies may not be packing themselfs like russian dolls and that the 3rd C++ project needs all the includes so I added them, the x264 errors turned into warnings and new errors pointing to ffmpeg stuff shown up [15:19:35 CEST] <cehoyos> I saw some of the nonsense you were told yesterday;-) [15:19:48 CEST] <cehoyos> Atm, I only see an error message that you quoted and that is not related to x264 [15:20:02 CEST] <Atlenohen> cehoyos: these are the x264 warnings now LNK4217 locally defined symbol x264_levels imported in function X264_init avcodec.lib(libx264.o) [15:20:46 CEST] <JEEB> I don't think static libs have dependencies noted in them so you need to link all of the stuff (usually noted by pkg-config implementations), and preferably in the right order for your linekr [15:20:50 CEST] <JEEB> *linker [15:20:53 CEST] <Atlenohen> cehoyos: cause I was around 5 other channels all day long, so it's a bit spread around, I was on #msys on OFTC alot, on ##linux, on ##c++-general, etc [15:21:20 CEST] <Atlenohen> BtbN cause I want full static libs, not DLL import libs [15:21:39 CEST] <BtbN> You'll need to make sure all your dependencies are static libs then [15:21:42 CEST] <cehoyos> I don't think the Windows C library is available as a static library, is it? [15:21:49 CEST] <BtbN> It is [15:22:05 CEST] <cehoyos> And also all other Windows system libraries? [15:22:06 CEST] <BtbN> You don't want that though, cause it comes with Windows anyway, and is huge [15:22:08 CEST] <cehoyos> I didn't know that. [15:22:21 CEST] <BtbN> Like, 30MB or so [15:22:37 CEST] <BtbN> And it's part of Windows in every still supported release [15:22:38 CEST] <cehoyos> I mean I didn't know that all Windows system libraries exist as static libraries. [15:22:53 CEST] <JEEB> I didn't know if all of them did? [15:22:59 CEST] <Atlenohen> X264 building is a lot different, look a lot different output, and lib.exe command is clearly shown at the end and a .lib is made, but I have independently confirmed that AR (archive tool) is indeed lib.exe so the problem may be somewhere else [15:23:28 CEST] <JEEB> msvcrtXXX was a thing that definitely had static versions though [15:23:30 CEST] <cehoyos> As long as you don't tell us your problem, it is unlikely that we will be able to help you;-) [15:23:41 CEST] <Atlenohen> BtbN: Yes I built x264 as static, there's no other dependencies that I'm aware of. [15:24:07 CEST] <cehoyos> x264 can have several dependencies but this was not the issue of the error message you quoted above. [15:25:37 CEST] <Atlenohen> cehoyos: I wish I knew what the problem was. Simply put the .a files (which I renamed to .lib) that got generated all day yesterday in those conditions weren't valid for the C++ project which always used and is using static ffmpeg libs [15:26:15 CEST] <Atlenohen> I did further config adjustments, added more params, will try again now, and I'll paste all the config's [15:26:23 CEST] <cehoyos> They weren't valid? You mean you created libraries incompatible with the toolchain you want to use? [15:26:45 CEST] <cehoyos> Instead of pasting the config's you should maybe tell us the error you get. [15:27:07 CEST] <Atlenohen> x264 build and ffmpeg build were all successful, it was a struggle to just get to some result. [15:27:27 CEST] <Atlenohen> There's no error in x264 or ffmpeg builds in MSYS2 MINGW shell [15:27:32 CEST] <cehoyos> (Given that static compilation is the default, this is a little surprising) [15:27:34 CEST] <BtbN> You cannot use gcc built .a files in msvc builds. They will be targetting a different libc [15:29:10 CEST] <Atlenohen> BtbN: this is what I was trying to figure out yesterday evening with someone on a C++ channel, but we confirmed MSYS2 MINGW64 shell is indeed using lib.exe from MSVC because I got an error if it didn't find it, i also forced option --ar=lib too [15:29:40 CEST] <Atlenohen> So it's not using ar.exe in MSYS2/MINGW64, even tho ffmpeg's output prints "AR libavcodec.a" [15:30:05 CEST] <JEEB> AR is just "whatever is set to be your 'ar' equivalent" [15:30:11 CEST] <JEEB> I think the more specific output is with make V=1 [15:30:19 CEST] <JEEB> which outputs the actual commands if you wish to see those [15:30:34 CEST] <cehoyos> To answer the question that you have not yet asked: You need the additional import library Bcrypt.lib for libavutil in your project. [15:31:14 CEST] <Atlenohen> x264 build log printed lib.exe and the full command referencing all .o files, I'm sure probably that's what it's done under the hood in ffmpeg case, the messaging may just be different, although for a novice user that's sometimes very confusing but I managed to figure things out [15:32:50 CEST] <Atlenohen> cehoyos: Oh well, if it's that easy ... I never knew about it's existence so I couldn't have been able to ask it, I might have figured it out by searching the error, but hours later probably. [15:33:22 CEST] <cehoyos> I didn't know about its existence either but it took me a minute to find out. [15:33:25 CEST] <Atlenohen> cehoyos: this is something the ffmpeg's build log should have warned about, (or maybe i should have enabled warn failure) [15:34:22 CEST] <cehoyos> Please provide the output of: make libavutil/libavutil.pc && cat libavutil/libavutil.pc [15:34:40 CEST] <Atlenohen> JEEB: V=1, oh the messaging configuration, thanks [15:35:07 CEST] <Atlenohen> cehoyos: after the build? I cleaned it so I'll have to rebuild, moment [15:35:20 CEST] <cehoyos> No, you don't have to rebuild [15:35:22 CEST] <Atlenohen> or wait, maybe it's still in the output folder [15:35:33 CEST] <JEEB> his command specifically re-builds the pc file [15:35:35 CEST] <JEEB> :) [15:35:38 CEST] <JEEB> (only) [15:35:50 CEST] <JEEB> (or makes sure it exists if you have some build outputs still there) [15:36:06 CEST] <Atlenohen> Ofocurse, I'm totally new to this. [15:36:39 CEST] <BtbN> lib and ar are just archiv creating tools for virtually the same format [15:37:05 CEST] <BtbN> It's the object files inside that matter [15:37:21 CEST] <cehoyos> I am curious about something else: What is your original issue? After all, the default builds are static. [15:38:21 CEST] <Atlenohen> cehoyos: https://pastebin.com/5pAE8xcL [15:39:31 CEST] <cehoyos> So, if I count correctly there are three ways to immediately tell you that bcrypt.lib is a needed library (I was just interested in this one because I was curious if pkg-config really works, I doubted it). Where id you look? [15:39:56 CEST] <Atlenohen> BtbN: I worked with delayloaded DLLs and their .libs, while there is similarities they look a lot different in text editor and they're much smaller, only a few 100 KBs at most, I am thinking maybe FFMPEG has improved in years so much there's less code needed for the stuff I'm using [15:40:01 CEST] <cehoyos> The easiest would be "rm ffmpeg_g && make V=1 ffmpeg_g" [15:40:08 CEST] <Atlenohen> unrelated project* [15:40:15 CEST] <cehoyos> after building FFmpeg [15:40:59 CEST] <cehoyos> This is extremely unlikely: The FFmpeg libraries grow each year. [15:41:25 CEST] <Atlenohen> cehoyos: after ffmpeg built, there was no any indication of anything wrong, so I just spent 3 hours figuring out why .a, and all that was a long story, I then just put .a renamed to .lib manually and see what happens, and here we are [15:41:53 CEST] <cehoyos> Why do you believe that anything went wrong? [15:41:55 CEST] <Atlenohen> The log was long, I didn't check all warnings, but if it's a needed lib it probably should have been an error, no big deal, it may be a bug [15:42:28 CEST] <cehoyos> Why would there be a bug? [15:42:39 CEST] <Atlenohen> cehoyos: Such thing should show an error by default, not my me having to explicitly use some verbose output mode. Error happened when it didn't find x264.lib so why not bcrypt.lib [15:42:49 CEST] <cehoyos> What should show an error by default? [15:43:24 CEST] <cehoyos> You showed us an error when compiling your project and - as said - it was immediately clear what was missing. Then you asked if FFmpeg didn't know about the dependency, and yes, it knew. [15:43:37 CEST] <cehoyos> (I forgot that configure also told you about the dependency, that makes four times) [15:44:10 CEST] <Atlenohen> If ffmpeg needs it for building then ffmpeg. So you're trying to say it's some dependency which is needed but not at build time, so VS2017 project would need it? [15:44:17 CEST] <cehoyos> * what was missing although I don't compile on Windows and I had never heard about this library before. [15:44:58 CEST] <cehoyos> It is needed at build time which is why FFmpeg's build system first told you about it, wrote it down for you and used it when linking ffmpeg (the application). [15:46:24 CEST] <Atlenohen> Look I just woke up in the morning after doing that for 14 hours straight yesterday, Bcrypt error happened late yesterday and I called it quits, so I haven't had the chance to search, I did assume and didn't check if it's something else so I didn't rush to search what it means [15:47:22 CEST] <Atlenohen> I'm going to repeat build now, and I'll pay attention at the log [15:50:11 CEST] <cehoyos> (I didn't suggest to pay more attention to the log, just that it is not difficult to find out about additional dependencies and that afaics, there is no bug.) You still haven't answered my question what your original issue is: What is wrong with the Zeranoe builds? [15:50:55 CEST] <Atlenohen> I haven't saw that question before - zeranoe does not provide static libs, those are shared libs [15:51:40 CEST] <Atlenohen> the .lib files are just refs to the .DLLs, they're not the same, but they kinda look the same since the extension is the same .lib [15:52:14 CEST] <Atlenohen> MS uses same extension for both, it's nothing new, it's just one more stupid thing MS does. [15:53:10 CEST] <Atlenohen> Plus, I need a custom build with only a few components, not the full blown ffmpeg. [15:54:09 CEST] <Atlenohen> And I generally am interested in learning how to build my self, ffmpeg happened to be the first one for me. [15:54:54 CEST] <cehoyos> I see. [15:55:54 CEST] <Atlenohen> And, you know it kinda looked as if I couldn't search this one little error, as I explained, circumstances, .. I'm exhausted! [15:56:19 CEST] <Atlenohen> As if I didn't turn over the whole internet yesterday ;) [15:56:57 CEST] <BtbN> Atlenohen, yes, DLLs work because they can link in their own libc. When static linking the whole application and all libs and their libs have to aggree on the same libc. [15:57:39 CEST] <BtbN> The .lib for loading DLLs and true static .lib files don't only look the same, they are the same. [15:58:01 CEST] <BtbN> The .lib to load a dll just has a GetProcAddress based shim function for every function in the dll [16:00:53 CEST] <Atlenohen> BtbN: We had a big discussion on the .a and .lib differences yesterday, I went in ##linux at one point and called for real linux people to tell me the first 8 bytes of a .a file they had, and the result was some had ELF and some had !<arch> format (COFF) which is the format used by LIB.EXE while linux utils can do both but they usually don't name .lib they name it .a so you have another confusion on linux cause not .a files may be [16:00:53 CEST] <Atlenohen> the same format, that's one thing [16:01:23 CEST] <BtbN> both .a and .lib files are just ar archives with object files in them [16:01:44 CEST] <BtbN> That's not the issue at all [16:02:05 CEST] <BtbN> It's what built that code inside and what libraries and runtime it expects to have access to [16:02:49 CEST] <Atlenohen> Second thing is, the !<arch> files thhe ones are static are several times larger than the ones that are only references, all it takes is taking a look at zeranoe's build, avcodec.lib is 128 kilobytes large, tell me how can that be a static library ? [16:02:50 CEST] <BtbN> If you build libx264 with msvc and ffmpeg with mingw64, or vice versa, that will explode because one expects Microsoft CRT, and the other the gcc libc [16:03:08 CEST] <BtbN> Zeranoe does not offer static libraries [16:03:13 CEST] <BtbN> For license reasons [16:03:29 CEST] <BtbN> There are static fftools and shared libraries [16:03:35 CEST] <BtbN> no static libraries [16:04:21 CEST] <Atlenohen> But he offers .libs which look like static libs but they aren't so the argument is when you said all .libs are the same which just doesn't make sense. [16:04:43 CEST] <BtbN> All libs are, in their essence, static libraries. [16:04:56 CEST] <BtbN> But some of them are just empty shim ones that load a .dll and forward to it. [16:05:28 CEST] <BtbN> That's a Windows specific btw., on Linux you can link directly against .so files, so there is no need for import .libs [16:06:06 CEST] <BtbN> Only real way to tell on Windows is to either decompile the .lib and look what it does. Or it's plain obvious by its size. [16:06:19 CEST] <Atlenohen> Sure if you want to treat such a significant practical difference as a small technical details than that's your opinion, to me that's a major difference, and while you may be right about the technical aspect of the files themsefls, in practice, it's a night and day difference. [16:06:28 CEST] <BtbN> gcc/mingw on Windows has adopted the .dll.a vs. .a scheme to differentiate the two [16:08:26 CEST] <Atlenohen> At least that. But I do agree with the .lib exention, althought only for "independent static libs" for "reference libraries" i'd use something like ".rlib" or ".dlib" [16:08:47 CEST] <BtbN> That will confuse the hell out of the linker and build system though [16:09:00 CEST] <BtbN> Cause for them, there is zero difference between a shim .lib and actual static lib .lib [16:09:06 CEST] <BtbN> They work and behave the same [16:09:27 CEST] <BtbN> And Windows likes its file extensions [16:09:37 CEST] <Atlenohen> I do however find .a extension kinda like linux usually does, put some random name on it, weird, you know the trend of naming software after some random anime/manga name, which makes zero relevance/sense. [16:09:48 CEST] <BtbN> ? [16:10:06 CEST] <BtbN> It's called .a because it's an ar archive. [16:13:00 CEST] <Atlenohen> Well, yeah I did eventually heard that. Oh and I didn't mean that with linux, at least I feel it's a recent trend, I think I saw an utility called "Candy" or something. [16:13:52 CEST] <Atlenohen> Nevermind, I don't remember it was several months ago, but it doesn't help with making things less confusing. [16:24:39 CEST] <Atlenohen> cehoyos: There is no mention of bcrypt.lib in the default output log (without V=1) [16:26:52 CEST] <Atlenohen> https://pastebin.com/HHTDU8wd [16:34:18 CEST] <cehoyos> Atlenohen: Missing configure output [16:34:47 CEST] <Atlenohen> Yeah I was about ot [16:36:47 CEST] <Atlenohen> cehoyos: Configuration https://pastebin.com/7WktAgFC [16:38:13 CEST] <cehoyos> Indeed, bcrypt is not mentioned, feel free to send a patch. [16:38:21 CEST] <cehoyos> Note that your configure line has multiple issues... [16:39:04 CEST] <Atlenohen> pkg config probably since I pasted it later on from a forum, but it didn't made a diff apparently [16:47:05 CEST] <cehoyos> Try: $ ./configure --toolchain=msvc --disable-all --enable-avformat --enable-avcodec --enable-gpl --enable-protocol=file --enable-muxer=webm,matroska,mpegts,rawvideo,mxf,frame* --enable-libx264 --enable-encoder=mpeg4,libx264*,bmp,ffv*,rawvideo [16:47:45 CEST] <Atlenohen> Will do [16:48:53 CEST] <Atlenohen> Althought I was thinking, maybe bcrypt is needed by framecrc/hash/md5 that looks related, those aren't that that super necessary (but it comes useful for debug), so I could do another test later without those [16:49:29 CEST] <cehoyos> You cannot disable it [16:49:50 CEST] <cehoyos> Sorry, you can, but you have to remove a header from your toolchain [16:50:14 CEST] <cehoyos> (Or patch the FFmpeg source code) [16:50:56 CEST] <furq> it's required for the matroska muxer [16:51:06 CEST] <cehoyos> ./configure --disable-autodetect --toolchain=msvc --disable-all --enable-avformat --enable-avcodec --enable-gpl --enable-protocol=file --enable-muxer=webm,matroska,mpegts,rawvideo,mxf,frame* --enable-libx264 --enable-encoder=mpeg4,libx264*,bmp,ffv*,rawvideo [16:51:21 CEST] <cehoyos> Is more similar to what you did (disable-autodetect) [16:51:30 CEST] <cehoyos> I don't know if it has an effect on bcrypt [16:52:07 CEST] <furq> bcrypt is used for av_get_random_seed on windows [16:52:10 CEST] <cehoyos> furq: I don't see a requirement for bcrypt or do I misundersatnd? [16:52:32 CEST] <furq> which is called a couple of times in matroskaenc [16:52:51 CEST] <furq> apparently the mxf muxer needs it as well [16:53:00 CEST] <cehoyos> Yes, but the function doesn't need it. [16:54:48 CEST] <Atlenohen> Building the first command - maybe the old libs were larger because they were build with debug (as I have the original configure command, or it looks like it, good thing it gets copied over to the .lib) [16:55:17 CEST] <Atlenohen> Debug is enabled here now, so it looks like it's the default. [16:56:45 CEST] <Atlenohen> Debug Symbols* - didn't made a difference to the size of he .a libs [16:56:48 CEST] <furq> i guess it's not required then but that's what's pulling it in [16:59:40 CEST] <furq> you can probably just use --disable-bcrypt if it's causing issues [17:01:26 CEST] <Atlenohen> No wait [17:01:52 CEST] <Atlenohen> cehoyos: I was looking at the old --prefix, it picked /usr/local in MSYS2 [17:02:59 CEST] <Atlenohen> the libraries appear to be of the expected size, slightly larger, 11 MB for libavcodec ... but is this due to debug symbols, idk, it's still at least positive indication. [17:03:16 CEST] <Atlenohen> the old was 9.x MB [17:05:32 CEST] <Atlenohen> What about cflags, loks like defining -I and -L wasn't necessary, but I hope the autodetect used -GS- for disabling Buffer Security [17:15:52 CEST] <furq> 15:59:40 ( furq) you can probably just use --disable-bcrypt if it's causing issues [17:15:55 CEST] <furq> ok apparently you can't do this [17:15:59 CEST] <furq> that's slightly annoying [17:18:21 CEST] <Atlenohen> I'm building C++ Solution right now with the first build [17:21:19 CEST] <Atlenohen> Looks like Swscale is required by the C++ solution, I'll have to rebuild ffmpeg [17:35:33 CEST] <Atlenohen> Yeah bcrypt again [17:36:49 CEST] <Atlenohen> yeah, debug symbols make a big diff in lib size [17:39:10 CEST] <cehoyos> ./configure --disable-autodetect --toolchain=msvc --disable-all --enable-avformat --enable-avcodec --enable-swscale --enable-gpl --enable-protocol=file --enable-muxer=webm,matroska,mpegts,rawvideo,mxf,frame* --enable-libx264 --enable-encoder=mpeg4,libx264*,bmp,ffv*,rawvideo [17:42:25 CEST] <Atlenohen> I would need to do multiple into the PKG config then [17:45:55 CEST] <Atlenohen> Sure, I found that environmental vars are set up, but they don't point directly to /um/x64 where bcrypt.lib is apparently, still checking [17:47:39 CEST] <Atlenohen> ah spoke too soon, it does [17:51:51 CEST] <Atlenohen> but can't check it if accessible in shell [17:52:03 CEST] <Atlenohen> tried cat bcrypt.lib but won't work. [18:05:13 CEST] <Atlenohen> I probably have to make universal pkgconfig and add another pkgconfig entry, not directly to just x264 [19:03:29 CEST] <Atlenohen> cehoyos: If I turn autodetect off wouldn't then some options which are enabled by default be turned on? Like pthreads? [19:12:51 CEST] <cehoyos> Atlenohen: (What you write - "wouldn't turning autodetect off turn autodetection on?" - makes little sense imo), either pthreads or win32threads is the default, I forgot which: Use either --disable-pthreads or --enable-w32threads if you don't like the default, no need to use both [19:14:07 CEST] <Atlenohen> Well since there's much less, i'd leave autodetect on, probably it's good to do it simple first, then define it more specifically later on [19:16:28 CEST] <cehoyos> No, I can see from your configure line that you do not want autodetection [19:16:56 CEST] <cehoyos> (I always recommend to leave it on and I regularly fight for more auto-detection but judging from your configure line it is not what you want) [19:17:21 CEST] <Atlenohen> But I'm not using mine anymore, i'm using your now [19:17:28 CEST] <cehoyos> Note that my recommendation - contrary to what you have used so far - is to do it simple first [19:18:22 CEST] <cehoyos> My suggestion from 16:51 was to turn auto-detect off [19:18:22 CEST] <Atlenohen> Well, it still works the same, right now I'm trying to combine PKGCONFIG for both x264 and Bcrypt [19:18:49 CEST] <cehoyos> But I am not sure what the default threads type for msvc is [19:19:16 CEST] <cehoyos> I don't think there is PKGCONFIG for Bcrypt... [19:19:31 CEST] <cehoyos> And you don't need it for x264 as it also works without [19:19:38 CEST] <cehoyos> (Some libraries absolutely need it) [19:19:55 CEST] <Atlenohen> I moved the pkgconfig for x264 and made it for Bcrypt in a central location inside msys64/usr/local/.../pkgconfig but it has trouble locating x264 [19:20:07 CEST] <Atlenohen> so I kinda have to fiddle with it [19:20:39 CEST] <Atlenohen> Because I can't link to just x264, I need included more than one dependency then [19:21:30 CEST] <cehoyos> Instead of fiddling supply --extra-cflags=-i/path/to/x264/include --extra-ldflags=-L/path/to/x264/library [19:21:48 CEST] <Atlenohen> Sure ... but what about bcrypt [19:21:58 CEST] <cehoyos> I have x264 on the same "level" as FFmpeg, so here it is: --extra-cflags=-I../x264 --extra-ldflags=-L../x264 [19:21:59 CEST] <Atlenohen> I never got cflags working anyway [19:22:08 CEST] <cehoyos> capital I... [19:23:08 CEST] <cehoyos> It's not difficult: clone x264, cd into x264, build it, cd .., clone FFmpeg, cd into FFmpeg, configure with --enable-gpl --enable-libx264 --extra-cflags=-I../x264 --extra-ldflags=-L../x264 [19:23:08 CEST] <Atlenohen> well I did i just left it as --extra-cflags=-I until you removed it which means it wasn't necessary at all as PKGCONFIG worked [19:23:33 CEST] <cehoyos> It should have returned an error imo because -I needs a parameter... [19:23:36 CEST] <cehoyos> awk [19:23:55 CEST] <Atlenohen> But it did work make, and I did put it in C++ and it was the same result, BCRYPT issue [19:24:53 CEST] <Atlenohen> I have x264 as separate gitrepo, I guess move the whole thing into ffmpeg then, along with bcrypt [19:25:24 CEST] <Atlenohen> Bcrypt is accessible, no idea why it doesn't take it, as if a config is missing, because it is part of INCLUDE environment that MS Dev Cmd makes [19:25:46 CEST] <Atlenohen> So I wanted to try to force bcrypt inclusion by making a pkconfig for it [19:29:39 CEST] <Atlenohen> The .a thing's pretty much done, i found LIBSUF whihc defines it, i'll force change it to .lib in the configure it self, done! :D [19:29:56 CEST] <Atlenohen> in the configure file it self* [19:43:10 CEST] <Atlenohen> cehoyos: well can you confirm the extact values, no dots, one dot, two dot -Ipath ? [19:43:28 CEST] <Atlenohen> actual folder like include, libs, or root one like x264 ? [20:05:09 CEST] <Atlenohen> cehoyos: nothing works with flags [20:05:42 CEST] <Atlenohen> that's why I came to pkconfig, I put all combinations, .. dots, one dot, no dots, no slash, while I had the x264 in ffmpeg and in usr/local [20:06:06 CEST] <Atlenohen> msys64/usr/local that is, now I typed out the full path, still nothing, it's broken or what [20:06:34 CEST] <Atlenohen> # ./configure --toolchain=msvc --extra-cflags=-I/c/msys64/usr/local/dependency/x264/include --extra-ldflags=-L/c/msys64/usr/local/dependency/x264/lib [20:10:45 CEST] <Atlenohen> if it given me the path where is it searching [20:11:14 CEST] <Soni> can ffmpeg hwdecode with my GPU and hwencode with my CPU? [20:14:38 CEST] <ncouloute> yes it can [20:18:25 CEST] <garyserj> What commands would help convert an mp4 with this profile https://pastebin.com/raw/XD5YnaLg into an mp4 with this profile https://pastebin.com/raw/b5xqFLxy ? [20:28:51 CEST] <ncouloute> Soni you can specify the decoder before the input (-i) for example for nvidia. (-hwaccel cuvid -c:v h264_cuvid -i "Path\to\ConvertMe.mp4") [20:29:54 CEST] <ncouloute> garyserj - unlikely someone will give you the exact flags. It isn't that hard to figure it out. Documentation for that kind of stuff is pretty good. [20:31:15 CEST] <Soni> what about intel and amd (mesa)? [20:34:37 CEST] <ncouloute> -hwaccel qsv -c:v h264_qsv -i "Path\to\ConvertMe.mp4" for intel. I'm not sure there is a AMD specifi decoder yet. I know there is an encoder. At least not in the zeranoe i use. There are a few generic hw decoders that arent brand specific [20:37:07 CEST] <Atlenohen> cehoyos: That does it had to put an end to this, deep monitoring: I can see that CL.exe is accessing bcrypt.h in the configuration process, which surely means it's also possible in the making process, and link.exe is accessing crypt.lib in the default directory, it first tries to find it in the ffmpeg repo root directory, tries a few other MS directories and then finds it in the existing default location [20:38:23 CEST] <Atlenohen> I think I have the latest or at least almost latest Win10 SDK ... what if the bcrypt is TOO HIGH version ???? [20:38:39 CEST] <Atlenohen> C:\Program Files (x86)\Windows Kits\10\Lib\10.0.17134.0\um\x64\bcrypt.lib [20:48:22 CEST] <garyserj> ncouloute: both are x264 and both are AAC so i've no idea [20:49:33 CEST] <garyserj> the main difference is one of them have "writing library" and "encoding settings" and the other doesn't [20:49:59 CEST] <garyserj> but i've no idea how to convert one that does into one that doesn't [20:53:24 CEST] <Atlenohen> Cehoyos: okay we got the full picture now, cflags actually works, it forwards the -I/path parameter to CL.exe, CL.exe finds x264.h successfully [20:54:48 CEST] <Atlenohen> Cehoyos: link.exe receives nothing from --extra-ldflags and this is probably what I was hinting at previously, there is no "-L" option I found on the MS documentation sites I checked 2 days ago (i'll do again as soon as I finish writing this) [20:55:06 CEST] <Atlenohen> It must be a legacy option that was deprecated and removed, replaced [20:56:01 CEST] <Atlenohen> so link.exe (not the MSYS2 link.exe, i disabled that, this is actual MSVC link.exe) first looks into the ROOT FFMPEG directory where were configuring, it doesn't find it. [20:56:49 CEST] <Atlenohen> Link.exe then tries C/msys64/mingw64/lib/ directory, doesn't find it, then it tries the FFMPEG root again [20:58:02 CEST] <Atlenohen> It then tries 3 other Windows Kits "lib" directories (which are part of $INCLUDE and other env variables), doesn't find it there obviously, then tried FFMPEG root again, and that's it, nothing found so we get an error in MSYS2 MINGW64 Shell [20:59:41 CEST] <Atlenohen> The workaround is obviously to try to move it there where it's looking at, or using the PKCONFIG which worked previously, but PKCONFIG's also hit and miss, I'll debug it as well to get an idea [20:59:55 CEST] <Atlenohen> PKGCONFIG* [21:01:11 CEST] <Atlenohen> https://docs.microsoft.com/en-us/cpp/build/reference/libpath-additional-lib… let's try this [21:03:44 CEST] <Atlenohen> didn't work, maybe the whole --extra-ldflags is broken the way it's scripted, i'll see... I'm pretty much developing ffmpeg at this point lol [21:03:57 CEST] <Atlenohen> debugging it at least [21:04:38 CEST] <Atlenohen> I have no choice but to go to the bottom of it, and well, probably would be great if I can contribute back too. [21:40:02 CEST] <ncouloute> garyserj - In the case of encoding settings and writing library. That is telling you that the original file was made with x264 using those specific flags. You care more about the resulting file info as you are trying to emulate that [21:56:36 CEST] <_bt> hello, i have some 1080p60 h264 video which i want to timelapse. i'm using 'ffmpeg -i 2019_0412_202119_001.MP4 -vf framestep=30,setpts=N/60/TB,fps=60 -an out.mp4' to create the timelapse. it works well, but the output file is the same length as the input file, only with the last frame displayed for the remainder of the video. where am i going wrong? [22:11:57 CEST] <_bt> cracked it: ./ffmpeg -discard nokey -i 2019_0412_202119_001.MP4 -vf "setpts=0.0120*PTS" -an out3.mp4 [22:12:00 CEST] <_bt> see ya [22:12:26 CEST] <poutine> I feel like that guy has been asking the same question for months now [22:15:07 CEST] <HickHoward> uhhh [22:15:16 CEST] <HickHoward> how as ATRAC3 reverse-engineerred in the first place? [22:17:35 CEST] <JEEB> by finding a decoder and looking what it did inside [22:17:51 CEST] <JEEB> nowadays you can get rather fancy decompilers etc in open source [22:17:56 CEST] <JEEB> like NSA's ghidra being the latest [22:19:07 CEST] <JEEB> sometimes of course you might also find something documenting the format [22:19:10 CEST] <JEEB> often this is not the case [22:19:42 CEST] <JEEB> and then you have people documenting their findings [22:19:46 CEST] <JEEB> f.ex. https://wiki.multimedia.cx/index.php/ATRAC3plus [22:21:45 CEST] <faLUCE> JEEB: yesterday I got an answer from MPEG LA [22:22:41 CEST] <HickHoward> he [22:22:45 CEST] <HickHoward> *heh [22:25:05 CEST] <durandal_1707> faLUCE: and? [22:25:35 CEST] <faLUCE> durandal_1707: they told me that "Based on your explanation below, I understand that you will not be offering end products with AVC functionality for Sale. Rather, you will simply publish source code. Therefore, your understanding is correct that you would not benefit from coverage under our AVC License in that case." [22:27:23 CEST] <faLUCE> what could it mean? does it mean that the license is not required? [22:28:34 CEST] <faLUCE> it seems to confirm what the old threads pasted by JEEB said [22:29:14 CEST] <faLUCE> (given that source code is not an end product) [22:32:05 CEST] <faLUCE> yes, it confirms that [22:33:46 CEST] <faLUCE> then MPEG-LA seems to be perfectly compatible with FOSS non commercial stuff [22:50:17 CEST] <iive> faLUCE, the last statement doesn't seem correct [22:50:32 CEST] <faLUCE> iive: why? [22:51:33 CEST] <iive> they told you that simply publishing the source code is OK. that has always been the case. [22:51:49 CEST] <iive> distributing working program for free is separate issue [22:51:56 CEST] <faLUCE> iive: yes, you are right [22:52:03 CEST] <iive> so is distributing working program for money. [22:53:06 CEST] <iive> that's why cisco basic avc codec exists... [22:53:26 CEST] <faLUCE> iive: anyway, the important thing is that MPEG LA is absolutely not against non commercial open source [22:53:33 CEST] <faLUCE> this is very good [22:54:31 CEST] <faLUCE> I think it's ethical [22:59:09 CEST] <cehoyos> Atlenohen: It's unlikely that we would accept a change to how --extra-ldflags work, it is working for many people for a very long time. [22:59:14 CEST] <cehoyos> Please explain what is not working for you [23:00:39 CEST] <cehoyos> " then MPEG-LA seems to be perfectly compatible with FOSS non commercial stuff" [23:00:43 CEST] <cehoyos> No, this is not correct [23:00:51 CEST] <cehoyos> And please do not repeat this again and again [23:01:18 CEST] <cehoyos> "anyway, the important thing is that MPEG LA is absolutely not against non commercial open source" [23:01:27 CEST] <cehoyos> This is of course also not true, on the contrary [23:01:42 CEST] <faLUCE> cehoyos: why? [23:08:22 CEST] <cehoyos> The MPEG-LA tries (actively) to oppress the freedoms that open source implies: They do not allow re-distribution. [23:09:01 CEST] <cehoyos> The re-distribution that free software implies of course includes binary distribution, it is not limited to source distribution. [23:09:32 CEST] <cehoyos> Note that I clearly remember a C interpreter, I wonder what happens if MPEG-LA remembers it;-) [23:10:44 CEST] <faLUCE> cehoyos: I did not even know that a C interpreter does exist! [23:11:03 CEST] <faLUCE> cehoyos: but would it have performance issues...? [23:13:42 CEST] <cehoyos> Yes =-) [23:13:59 CEST] <JEEB> cehoyos: I would guess the intent of the distributor is what will end up meaning something in the courts :) f.ex. "just distributing code" in python or JS and expect that to be OK in their eyes (in case you get on one of these patent licensing things' radar) [23:14:23 CEST] <JEEB> but yes, all this patent licensing is a mess :P [23:14:35 CEST] <JEEB> full of "let's make things not clear to not make promises" [23:14:53 CEST] <faLUCE> JEEB: but a native python x265 encoder would never exist... [23:15:32 CEST] <JEEB> why not? just like fabrice made a JS decoder (not sure if he used emscripten with HM or the lavc thing) [23:16:07 CEST] <faLUCE> JEEB: I mean _encoders_ .... because it would not take full advantage of the current technology [23:16:33 CEST] <cehoyos> My point is just that this isn't patent-law-exchange, and it would be great if we could agree that we cannot know what exactly the MPEG-LA thinks. I still don't know faLUCE's use case... [23:16:42 CEST] <JEEB> very true [23:16:47 CEST] <JEEB> we are all very much not lawyers [23:16:58 CEST] <JEEB> (and even if we are, we don't want to give out law advice) [23:16:59 CEST] <cehoyos> I usually read irc-log and this goes on for far too long;-) [23:17:09 CEST] <cehoyos> Correct! [23:17:43 CEST] <faLUCE> I was interested in understanding all the sides of open source digital-audio video [23:18:02 CEST] <faLUCE> because I see that it's a mess! [23:18:43 CEST] <faLUCE> anyway, I'm thinking seriously to switch to theora [23:19:11 CEST] <faLUCE> from what I read, its current quality is comparable to h264 [23:19:21 CEST] <JEEB> o_O [23:19:32 CEST] <faLUCE> not true? [23:20:40 CEST] <JEEB> I would be very surprised :D libvpx and friends came out (plus then daala/libaom/rav1e etc). so the theora encoder's issues such as rate control I think never got resolved. [23:20:59 CEST] <JEEB> I remember derf talking about the rate control fixes a few years ago at VDD [23:21:32 CEST] <HickHoward> is it just me or am i the only one who thinks that Ogg Opus is not a good audio codec? [23:21:34 CEST] <JEEB> basically, while theora encoding could be improved, the effort went into more modern formats [23:21:38 CEST] <faLUCE> JEEB: which kind of issue? it's not possible to change bitrate on fily? [23:22:10 CEST] <faLUCE> or is it a more general problem? [23:22:21 CEST] <JEEB> I wish I remembered the details [23:23:11 CEST] <cehoyos> Why do you believe that it is a mess? And is there a specific reason why you want to "understand" all sides? [23:23:35 CEST] <JEEB> ooh, https://git.xiph.org/?p=theora.git;a=commit;h=eac29ae2f9c748cb4a0a3fc381002… [23:23:42 CEST] <JEEB> so the mentioned issue might have gotten fixed :) [23:23:52 CEST] <cehoyos> But the technology is not up-to-date [23:24:10 CEST] <JEEB> yea [23:24:14 CEST] <cehoyos> The idea that libtheora's is equal to x264 makes not much sense to me. [23:24:18 CEST] <JEEB> theora was vp3++ [23:24:19 CEST] <faLUCE> cehoyos: because before three months ago I did not knew anything detailed about patent question [23:24:22 CEST] <faLUCE> s [23:24:33 CEST] <JEEB> patents don't really relate to open source as such [23:24:42 CEST] <JEEB> it's in a way relevant to all software, and yes - it's a mess [23:25:08 CEST] <cehoyos> I am not 100% convinced that you know many details now and I wonder why you want to know them. [23:25:43 CEST] <faLUCE> cehoyos: because I would like to work more and more with open source video stuff [23:26:33 CEST] <damdai> cehoyos why are you keep closing my bug report for no reason [23:26:38 CEST] <faLUCE> [23:25] <cehoyos> I am not 100% convinced that you know many details <-- in fact it's a mess [23:27:23 CEST] <JEEB> dongs: no problemos. not sure if it was much more than maybe a ping regarding a possibility of getting a sample of the 22.2ch AAC to see how it's bolted together [23:27:26 CEST] <Atlenohen> cehoyos: none of the combinations of -cflags and ldflags have worked that I tried, would you be able to provide an exact working example ? [23:30:24 CEST] <cehoyos> I provided one (the one I use) at 19:23 but if pkg-config works for you, please use it! [23:31:02 CEST] <cehoyos> faLUCE: We all work (more and more) with open source video stuff and we try not to think about patents - what is the reason that you want to think of them? [23:31:17 CEST] <cehoyos> damdai: Would you like to tell me which ticket you talk about? [23:31:51 CEST] <Atlenohen> cehoyos: whether or not PKGCONFIG works, if flags don't work it's a bug of some kind [23:31:57 CEST] <damdai> cehoyos http://trac.ffmpeg.org/ticket/7824 [23:32:19 CEST] <Atlenohen> PKGCONFIG needs to support more than one library, not only x264 [23:32:25 CEST] <Atlenohen> If it can't do that it's useless [23:32:32 CEST] <cehoyos> Again: They work fine, if they don't work for you, I am happy to help you find out why but if pkg-config works for you (it doesn't work for me on many operating systems), that may save us both time. [23:33:25 CEST] <JEEB> I think it's worthwhile checking the differnce between the make V=1 output between the two ways [23:33:40 CEST] <Atlenohen> cehoyos: Yes PKGCONFIG hasn't been working when I tried to combine it with other than x264 [23:33:40 CEST] <cehoyos> damdai: Ticket 7824 has not similarities to a valid ticket, I really don't know why you are surprised that I closed it. [23:33:49 CEST] <faLUCE> cehoyos: because I wanted to be sure that publishing source code is OK. it would be much better to publish also binaries, but from what I see, it's a mess (and it depends also on the laws country where you are). Then, in my next projects I wonder which codec could I use without all this mess [23:33:51 CEST] <damdai> cehoyos bug still exist [23:34:20 CEST] <Atlenohen> JEEB: This is only the ./configure process, it can't get past that yet (I know it works one way, but that was is not really practical) [23:34:21 CEST] <faLUCE> so I thought about theora, based on what I read on wikipedia, but now you are telling me that is not comparable to h264 [23:34:48 CEST] <cehoyos> damdai: No, there is no bug. FFmpeg's implementation of dst uses 352800Hz, if you are unhappy about it, don't use it. [23:35:07 CEST] <cehoyos> If you don't believe me: It is trivial to replace this value but this will break compilation;-( [23:35:20 CEST] <JEEB> Atlenohen: ok, the configure script outputs its stuff in ffbuild/config.log [23:35:33 CEST] <JEEB> so you should be able to compare whatever is your failing and succeeding configuration [23:35:42 CEST] <damdai> cehoyos but it shouldn't show as 352800Hz [23:35:51 CEST] <damdai> how is that not a bug [23:35:52 CEST] <cehoyos> faLUCE: What do you mean with sure? There are more than one thousand contributors in FFmpeg, what problem could you have that they do not have? [23:36:01 CEST] <Atlenohen> JEEB: That has not been helpful most of the time I checked it, but I'll do it again, it only says "x264.h" not found and that's it [23:36:10 CEST] <cehoyos> damdai: Again, this is how it is implemented, this is not a bug as long as the output sounds correct. [23:36:30 CEST] <damdai> cehoyos well i am just doing ffprobe [23:36:33 CEST] <JEEB> Atlenohen: it should have the check (code) and the actual commands utilized for checking in there [23:36:59 CEST] <cehoyos> Atlenohen: In case your issue is that bcrypt has nothing to do with pkg-config than you can neither fix this in pkg-config nor with --extra-flags: Both are not related to bcrypt. [23:37:17 CEST] <faLUCE> cehoyos: "There are more than one thousand contributors in FFmpeg, what problem could you have that they do not have?" <--- this is true... but what could happen if tomorrow MPEG LA changes their rules? [23:37:18 CEST] <damdai> cehoyos so if a 22khz mp3 file show as 44khz mp3 file on ffprobe, you are saying that is not a bug then? [23:37:37 CEST] <cehoyos> damdai: As said: If you are not happy about our dst implementation, just use another one;-) [23:37:42 CEST] <Atlenohen> LDFLAGS=' -L/c/msys64/usr/local/dependency/x264/lib' [23:37:46 CEST] <damdai> cehoyos answer my question [23:37:47 CEST] <damdai> cehoyos so if a 22khz mp3 file show as 44khz mp3 file on ffprobe, you are saying that is not a bug then? [23:37:57 CEST] <JEEB> damdai: if the decoded output is correct, then it is "only" an issue with the output of the information provided at the probe [23:38:09 CEST] <JEEB> if the actual *decode* is incorrect, that's a separate case [23:38:20 CEST] <cehoyos> That would likely be a bug because our mp3 implementation requires that the output has the frequency that you want to hear. [23:38:40 CEST] <cehoyos> I suspect it would be possible to change the mp3 decoder so that it shows another frequency and still works. [23:38:50 CEST] <cehoyos> (Note that this is exactly what happens for some aac files) [23:39:19 CEST] <Atlenohen> JEEB: does that mean it's trying to pass linux-paths to a windows utility? cl -nologo -I/c/msys64/usr/local/dependency/x264/include -c -Fo./ffconf.xwinK8u6/test.o ./ffconf.xwinK8u6/test.c [23:39:20 CEST] <damdai> i expect 22khz mp3 file show to show as 22khz mp3 file in ffprobe [23:39:26 CEST] <cehoyos> faLUCE: Then - sad as it is for us and maybe for you - you should not contribute to FFmpeg. [23:40:00 CEST] <faLUCE> cehoyos: in addition, I was about fsf complaining MPEG-LA... so my thought was.. should I continue to use MPEG stuff or do I have to switch to theora and opus. I tried opus in the last two months and I was very satisfied [23:40:14 CEST] <cehoyos> damdai: That is correct for the current mp3 decoder implementation, it could (theoretically) change in the future, as said for some aac files this is exactly what happens. [23:40:26 CEST] <JEEB> Atlenohen: yes. although do remember that msys(2) has funky utilities to convert stuff in flight [23:40:28 CEST] <cehoyos> you were about or it was about? [23:41:16 CEST] <cehoyos> Now you are saying "use": Do you want to use FFmpeg or do you want to contribute to FFmpeg? I believe these are two differect things (I very, very rarely use FFmpeg) [23:41:36 CEST] <faLUCE> cehoyos: I would like to contribute too. [23:41:55 CEST] <cehoyos> Then please do, man power (time) is the only limiting factor;-) [23:42:18 CEST] <faLUCE> cehoyos: I did in the past! And in this channel I try to help newbies [00:00:00 CEST] --- Sun Apr 14 2019

1 0

ffmpeg-devel.log.20190412
by burek 13 Apr '19

13 Apr '19

[01:32:20 CEST] <atomnuker> how many people are going to write ec code simd for dav1d before I get the clue giving it to someone else was a bad idea? [01:33:26 CEST] <atomnuker> and the last 2 attempts are going the wrong way about it by assuming a specific cdf size [01:34:18 CEST] <nevcairiel> optimizing the most common cases seperately is the essence of making stuff fast =p [01:34:31 CEST] <jamrial> you should join #dav1d and mention it there [01:35:18 CEST] <atomnuker> not when there's no need for it, my code was at least generic and overwrote/read as it saw fit as it padded all CDFs and just needed a loop for when they were big [01:36:21 CEST] <atomnuker> actually I don't think they got big enough to need a loop at all, IIRC they fit in a single 256bit reg [01:37:57 CEST] <atomnuker> oh well, I'll rewrite it when we port the codebase to lavc, no way I'm giving my code away to big corps under MIT [01:39:32 CEST] <atomnuker> well, I do if they pay [01:40:02 CEST] <BBB> <3 [01:40:39 CEST] <BBB> atomnuker: in the end it's about speed [01:40:56 CEST] <BBB> your (our? I wrote part of that also) code didn't speed it up half as much as this code appears to do [01:41:14 CEST] <atomnuker> it was unfinished IIRC [01:41:28 CEST] <BBB> another issue, yes :) [01:42:17 CEST] <atomnuker> I'll admit for small CDF sizes it didn't speed things up, it turns out avx2 is kinda too heavy [01:43:17 CEST] <atomnuker> I think that was what I had to finish, specialcase 128bit simd for small CDFs [01:45:07 CEST] <atomnuker> hmm, maybe even have separate functions for avx2/sse (macro'd in at runtime based on cdf size) since you don't want another branch [10:02:25 CEST] <kurosu> it makes sense to optimize aggressively the most costly case, and then more generically the other ones [16:58:30 CEST] <BtbN> Ghidras decompiler has very weird ways to express things. "state_byte = (uint)CONCAT11(1,(char)uVar2);" This is "movzx eax,al; or ah,1", so essentially (uVar2 & 0xFF) | 0x100. [16:59:26 CEST] <BtbN> There is zero results about CONCAT11 in its docs for all I can tell [17:03:23 CEST] <BtbN> This code I'm analysing is also doing highly weird things. It has an elaborate function to get the next byte from a buffer, which returns data[pos] | (pos & ~0xff). But every instance of it using that function immediately applies & 0xFF to the result. Like... what are you doing there? [17:15:02 CEST] <ubitux> the use of these CONCAT thing is often due to bad type set on the variables/arguments [17:15:13 CEST] <ubitux> (or the use of SIMD) [17:15:33 CEST] <ubitux> check again the type you set [17:19:13 CEST] <BtbN> The types look proper to me [17:19:24 CEST] <BtbN> Looks like a compiler optimization to me [17:20:20 CEST] <BtbN> Which optimized EAX=(EAX & 0xFF) | 0x100 to MOVZX EAX,AL; OR AH,1 [18:29:50 CEST] <philipl> BtbN: what do you think of Yogender's reply? [18:30:39 CEST] <BtbN> I have no idea. Requiring that the input pointers stay "alive" for the whole runtime of the encoder is not _that_ unreasonable. [18:35:03 CEST] <philipl> It seems like you'd have to go out of your way to write your custom pipeline where that's hard to achieve. [00:00:00 CEST] --- Sat Apr 13 2019

1 0

ffmpeg.log.20190412
by burek 13 Apr '19

13 Apr '19

[00:01:02 CEST] <faLUCE> JEEB: it's strange that this discussion is of about 10 years ago... [00:01:08 CEST] <faLUCE> what happened meanwhile? [00:01:18 CEST] <JEEB> (Ž4@) [00:04:32 CEST] <faLUCE> JEEB: note that: [00:04:33 CEST] <faLUCE> https://www.openh264.org/faq.html [00:04:54 CEST] <faLUCE> " In order for Cisco to be responsible for the MPEG LA licensing royalties for the module, Cisco must provide the packaging and distribution of this code in a binary module format (think of it like a plug-in, but not using the same APIs as existing plugins), in addition to several other constraints" [00:05:08 CEST] <JEEB> yes, cisco distributes binaries that f.ex. firefox then downloads [00:05:21 CEST] <JEEB> this way cisco is distributing the binaries [00:05:25 CEST] <faLUCE> JEEB: it confirmes what the quoting of ryan said [00:05:58 CEST] <JEEB> it's the more or less common understanding of what *MPEG-LA* wants [00:07:19 CEST] <faLUCE> JEEB: so, openh264 source code doesn't pay MPEG-LA ? [00:07:43 CEST] <JEEB> what [00:08:39 CEST] <faLUCE> JEEB: yes, look at that. The binary has another license than the source code [00:08:43 CEST] <faLUCE> "Additionally, this binary is licensed under Ciscos AVC/H.264 Patent Portfolio License from MPEG LA, at no cost to you, provided that the requirements and conditions shown below in the AVC/H.264 Patent Portfolio sections are met. " [00:08:53 CEST] <JEEB> that is not a software license [00:08:56 CEST] <faLUCE> while the source code is BSD [00:08:59 CEST] <JEEB> that is a patent license [00:09:02 CEST] <JEEB> separate things [00:09:22 CEST] <faLUCE> ok, but I mean: the patent license is applied only to the binary [00:09:28 CEST] <faLUCE> not to the source code [00:09:41 CEST] <faLUCE> even if the source code has patented algos [00:10:19 CEST] <JEEB> that is the common understanding of how it goes with MPEG-LA, yes. do note that unless cisco has this in writing from mpeg-la, mpeg-la could choose to change its mind [00:10:34 CEST] <JEEB> of course probably, maybe that is unlikely to happen [00:10:38 CEST] <JEEB> but welcome to legalese [00:10:58 CEST] <JEEB> although cisco already pays the maximum license amount [00:11:01 CEST] <faLUCE> JEEB: ok, but this license clarifies all [00:11:05 CEST] <JEEB> so for cisco it wouldn't matter at all :P [00:12:15 CEST] <faLUCE> FOSS source code doesn't require license from MPEG LA, while binary requires patent license [00:12:31 CEST] <faLUCE> they WROTE that, so.... [00:12:37 CEST] <JEEB> cisco did, yes [00:12:51 CEST] <JEEB> I'm not saying this is not the common understanding [00:12:53 CEST] <JEEB> just details :P [00:13:19 CEST] <faLUCE> JEEB: but note this is an important doc, because your thread is old and without explicit quotes [00:13:30 CEST] <faLUCE> instead, this is a sort of legal doc by cisco [00:13:31 CEST] <JEEB> is this an explicit quote? [00:13:40 CEST] <faLUCE> yes, it's the cisco license [00:13:45 CEST] <faLUCE> https://www.openh264.org/BINARY_LICENSE.txt [00:14:25 CEST] <JEEB> yup, that's just cisco's understanding [00:14:39 CEST] <JEEB> most likely they talked with MPEG-LA and it will hold :P [00:14:48 CEST] <faLUCE> ok, but it something more "official" [00:14:53 CEST] <faLUCE> than the old thread [00:15:00 CEST] <faLUCE> (it is) [00:15:27 CEST] <faLUCE> JEEB: otherwise even CISCO would be in violation! [00:15:42 CEST] <JEEB> of course, but they already pay the max :D [00:15:55 CEST] <JEEB> that's why they are distributing it [00:16:00 CEST] <JEEB> because it doesn't cost anything to them [00:16:03 CEST] <JEEB> and it's good PR [00:16:44 CEST] <JEEB> faLUCE: also was there a spot where it notes that the source code is not applicable? either in the txt or the site. [00:16:51 CEST] <JEEB> we both know that's most likely what MPEG-LA thinks [00:16:56 CEST] <JEEB> but yunno :P welcome to legal stuff [00:16:59 CEST] <JEEB> it's all vague [00:17:19 CEST] <faLUCE> JEEB: yes, there is that spot: [00:17:21 CEST] <faLUCE> https://www.openh264.org/faq.html [00:17:47 CEST] <faLUCE> "In order for Cisco to be responsible for the MPEG LA licensing royalties for the module, Cisco must provide the packaging and distribution of this code in a binary module format (think of it like a plug-in, but not using the same APIs as existing plugins), in addition to several other constraints. This gives the community the best of all worlds - a team can choose to use the source code, in which case the team is [00:17:48 CEST] <faLUCE> responsible for paying all applicable license fees, or the team can use the binary module distributed by Cisco, in which case Cisco will cover the MPEG LA licensing fees." [00:18:18 CEST] <faLUCE> ----> this means that the first one who makes binaries, has to pay MPEG-LA [00:18:25 CEST] <JEEB> no [00:18:26 CEST] <JEEB> not make [00:18:27 CEST] <JEEB> distribute [00:18:30 CEST] <faLUCE> yes [00:18:32 CEST] <faLUCE> distribute [00:18:45 CEST] <JEEB> I could make the binary to a company, and the company would distribute it [00:19:15 CEST] <JEEB> according to the common understanding the company would thus be the end-user distributor [00:20:15 CEST] <JEEB> faLUCE: also do note how that quote does not specifically say that the source code is not relevant to the MPEG-LA licensing. it's the common understanding, but it is /not/ mentioned there. [00:20:23 CEST] <JEEB> not trying to be an asshole, just noting it :P [00:22:01 CEST] <faLUCE> JEEB: it says: "a team can choose to use the source code, in which case the team is responsible for paying all applicable license fees" [00:22:16 CEST] <faLUCE> which means that "source code itself is not subject to fees" [00:22:45 CEST] <damdai> anybody know what it means by "fragmented" and "cbcs" ? http://download.opencontent.netflix.com/?prefix=AV1/Chimera/ [00:24:29 CEST] <JEEB> faLUCE: no it does not. it just says that if you don't use cisco's binary it is of course not licensed [00:24:47 CEST] <JEEB> you can /read/ it like you do [00:24:58 CEST] <JEEB> it doesn't /say/ it [00:25:29 CEST] <faLUCE> JEEB: I'm talking about the non-binary case [00:25:36 CEST] <faLUCE> for an user too [00:25:59 CEST] <faLUCE> so, an user that uses cisco's code for making another non-binary library [00:27:16 CEST] <JEEB> faLUCE: but see how it specifically say what you read out of it :P it does /not/ say "source code itself is not subject to fees". it /only/ says "if you choose to use the source code, you are responsible for handling any applicable license fees" [00:27:33 CEST] <faLUCE> JEEB: ok, but it can be deduced [00:27:46 CEST] <JEEB> no it cannot be. it is the common understanding though. [00:27:53 CEST] <JEEB> that mpeg-la does not care about source [00:28:05 CEST] <JEEB> anyways, good night :) [00:28:12 CEST] <faLUCE> good night :-) [00:29:40 CEST] <kevinnn> does anyone know why some routers block UDP traffic and others don't? Specifically for rtsp streams [00:31:05 CEST] <faLUCE> kevinnn: by closing ports [00:31:06 CEST] <faLUCE> ;-) [00:31:54 CEST] <kevinnn> faLUCE: how do I get my routers not to do that? it is affecting my performance [00:31:55 CEST] <kevinnn> also... [00:32:01 CEST] <kevinnn> apple's facetime [00:32:06 CEST] <kevinnn> that goes over rtp [00:32:10 CEST] <kevinnn> which is UDP [00:32:18 CEST] <kevinnn> but it doesn't seem to be blocked [00:32:37 CEST] <faLUCE> kevin, be more precise [00:32:40 CEST] <kevinnn> or do they also revert to TCP when UDP is blocked [00:32:48 CEST] <faLUCE> yes, it can be [00:32:58 CEST] <faLUCE> kevinnn: you should a test with netcat [00:33:05 CEST] <kevinnn> but the other thing is I tested with netcat [00:33:08 CEST] <kevinnn> yes exactly [00:33:20 CEST] <faLUCE> and what netcat said? [00:33:21 CEST] <kevinnn> and it seems like UDP traffic gets through just fine [00:33:32 CEST] <kevinnn> but for some reason rtsp still defaults to tcp [00:33:35 CEST] <kevinnn> as opposed to UDP [00:33:41 CEST] <kevinnn> it is very confusing [00:33:55 CEST] <faLUCE> kevinnn: it works in this way [00:34:13 CEST] <faLUCE> the RECEIVER asks to the STREAMER a rtsp description [00:34:38 CEST] <faLUCE> then the receiver allocates resources based to this description [00:34:50 CEST] <faLUCE> then the streamer sends stuff over UDP [00:35:24 CEST] <faLUCE> RTSP is TCP, while RTP is UDP [00:35:54 CEST] <faLUCE> now, given that your player doesn't allow you to allocate a netcat receiver [00:36:02 CEST] <faLUCE> use a SNIFFER [00:36:04 CEST] <faLUCE> ok? [00:36:29 CEST] <kevinnn> faLUCE: okay use a sniffer to determine if rtp is being passed via UDP or tcp? [00:36:52 CEST] <faLUCE> yes [00:37:07 CEST] <kevinnn> because on some routers (like mine) vlc produces this error when connecting to an rtsp stream: no data received in 10s. Switching to TCP [00:37:17 CEST] <kevinnn> okay, let me download and install a sniffer [00:38:10 CEST] <faLUCE> [00:37] <kevinnn> because on some routers (like mine) vlc produces this error when connecting to an rtsp stream: no data received in 10s. Switching to TCP <--- then you should already know if it's TCP or UDP [00:38:29 CEST] <kevinnn> right... but I don't want it to be [00:38:37 CEST] <kevinnn> I want it to be UDP [00:38:50 CEST] <kevinnn> and it is my router so I should be able to configure it like so [00:39:03 CEST] <kevinnn> but there don't appear to be any settings that allow me to adjust that [00:39:42 CEST] <faLUCE> kevinnn: this is another problem [00:40:10 CEST] <kevinnn> faLUCE: I know... but for my specific use case TCP adds too much latency [00:40:17 CEST] <kevinnn> the stream must be in UDP [00:40:46 CEST] <faLUCE> kevinnn: first check if it's TCP instead of UDP [00:41:04 CEST] <kevinnn> okay, I will check with wireshark, give me a sec [00:41:25 CEST] <faLUCE> kevinnn: also note that TCP doesn't introduce significant latency [00:41:33 CEST] <faLUCE> you can drop frames [00:41:57 CEST] <kevinnn> for bi-directional streaming, every millisecond of latency counts [00:42:28 CEST] <faLUCE> kevinnn: not if they have the same latency [00:43:15 CEST] <kevinnn> TCP always higher latency than UDP does doesn't it? [00:43:31 CEST] <kevinnn> I mean it physically feels slower when i use tcp vs udp [00:43:55 CEST] <faLUCE> yes, but it doesn't mean that it's higher in a significant way for you [01:48:01 CEST] <garyserj> I have this video that won't upload to youtube. I used ffmpeg to cut 1 second of it so I have a very small example file. That gives the same error from youtube The video is available here http://ge.tt/1wtKlWv2 and is 98KB in size. The story is I had a bunch of .3gp videos on my phone, I converted them to mp4. For some inexplicable reason a few 90 degrees rotated or needed a vertical flip, [01:48:01 CEST] <garyserj> which I did with -vf "transpose=1" or -vf "transpose=vflip". One of the videos (I don't know if it's one that needed rotating or flipping), but it's not uploading. mediainfo shows https://pastebin.com/raw/YXdiTxeu e.g. mp4(AVC,AAC) so I am not sure the problem or how can change it so it uploads. [02:38:23 CEST] <fella> garyserj: nothing that strikes my eye, but see for yourself: https://support.google.com/youtube/answer/1722171 [02:38:39 CEST] <fella> what's the err you get? [03:08:25 CEST] <garyserj> fella: "The video has failed to process. Please make sure you are uploading a supported file type." [03:37:49 CEST] <garyserj> fella: just tried importing to movie maker and saving, and it worked, and I made a cut of the working one. http://ge.tt/1jovrWv2 i'm interested if i can use ffmpeg to turn the bad one into the good one? [08:44:23 CEST] <fella> garyserj: could you post the 'mediainfo' of the working one as well? [12:12:16 CEST] <aleek> hello! [12:14:07 CEST] <aleek> we are trying to transcode live stream of regular tv. We have mpeg2ts subtitles Elementary Stream, but usually it is empty, because there is no subtitles at the moment. I cannot start ffmpeg, until it finds at least one subtitle frame. Can we somehow overcome that? [12:19:00 CEST] <JEEB> not sure the probe function would do that [12:37:53 CEST] <DHE> failure to detect the input codec causing fail? [12:38:34 CEST] <xerpi> Hi, I'm trying to use ffmpeg (libavcodec to do video decoding specifically) on bare-metal, without any OS beneath [12:38:56 CEST] <xerpi> I can provide my own implementations of simple libc functions such as memcpy, strlen, etc [12:39:45 CEST] <xerpi> But I see that for example file_open.c of libavutil, which uses open() and the like, is unconditionally compiled [13:43:26 CEST] <dongs> JEEB: im sorry, im gulag'd in korea/taiwan so i probably missed your message. i saw a highlight here. but it scrolled off my screen [14:42:09 CEST] <Numline1> Hey folks. I'm looking to implement this one thing in Go and I wonder if I could use ffmpeg for that. I need to process a video and extract one frame for each second of the video. This frame should be as stable as possible, meaning no blurry mid-frames and stuff. Would this be possible? Thanks! [14:43:05 CEST] <BtbN> That depends on the material. If the source material uses tons of motion blur, you're gonna get motion blur. [14:45:29 CEST] <BtbN> Extracting frames will not mix multiple together unless you explicitly use a filter for that. [14:48:19 CEST] <Atlenohen> furq: Looks like it's the other way around /GS checks for buffer security, not disables it https://docs.microsoft.com/en-us/cpp/build/reference/compiler-options-liste… [14:49:05 CEST] <Atlenohen> unless, the minus after it [14:49:44 CEST] <Atlenohen> it was typed -GS- so I guess - at the end would mean to disable, I was wondering what does it mean I guess I figured it out [14:52:28 CEST] <Numline1> BtbN yeah I was either hoping I could find the most "perfect" frame or mix multiple ones. Are there any resources on this online? [14:55:23 CEST] <BtbN> mixing multiples ones will only make matters worse [14:55:45 CEST] <BtbN> But generally, just set the fps to 1, and you will get, well, one frame per second. [14:56:14 CEST] <Numline1> BtbN Fair enough. I found this - https://www.bugcodemaster.com/article/extract-images-frame-frame-video-file… which seems to be what I need. I was just hoping there's a filter that could look for stable frames [14:59:29 CEST] <furq> Numline1: check the thumbnail filter [14:59:38 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#thumbnail [15:00:49 CEST] <Numline1> furq that'll probably do. Thanks! Are there any details on how that filter works? [15:00:59 CEST] <Numline1> by that I mean what are the methods it uses under the hood [15:01:43 CEST] <furq> https://notbrainsurgery.livejournal.com/29773.html [15:01:46 CEST] <furq> apparently it's derived from this [15:02:18 CEST] <Numline1> thank you :) [15:02:27 CEST] <Numline1> also, what I like is that there's a filter named "ass" [15:02:37 CEST] <Numline1> I'm going to use that even though I might not need it [15:08:12 CEST] <iive> well, there is also file format .ass [15:08:37 CEST] <iive> that this filter renders [15:10:05 CEST] <Numline1> one could say it consumes ass [15:55:15 CEST] <killown> hi there [15:55:22 CEST] <killown> ffmpeg -y -ss 00:00:10.0 -i *BuUOl7HKM8U.mkv -strict -2 -c copy -t 00:00:13.0 ../videos/video.mp6 [15:55:25 CEST] <killown> mp4 [15:55:37 CEST] <killown> why ffmpeg is cuting random times? [15:56:14 CEST] <killown> I want to cut 3 seconds from starting from second 10 [15:57:13 CEST] <ritsuka> you can't cut at a random point if the video format uses P and B frames [15:57:23 CEST] <DHE> you must cut starting on a keyframe [16:08:52 CEST] <killown> how is that? [16:08:57 CEST] <killown> starting on a keyframe? [16:09:12 CEST] <killown> cannot cut from 10 seconds? [16:09:22 CEST] <furq> only if there's a keyframe at that timestamp [16:09:27 CEST] <HickHoward> okay, so i did... this [16:09:27 CEST] <HickHoward> ffmpeg.exe -i "H:\Tourist Trophy (Japan)\tt_vol\openingW.m2v" -vf "il=1:1:1,setfield=tff,separatefields" -vcodec rawvideo -pix_fmt bgr24 openingW.avi [16:09:30 CEST] <furq> otherwise it'll seek to the (closest/next) one [16:09:39 CEST] <HickHoward> now the final .avi video is looking all jittery every 2 frames [16:10:09 CEST] <HickHoward> this is especially noticeable on parts of the video in which only a static image is displayed for like 5 seconds [16:12:10 CEST] <killown> furq how do I check that? [16:12:48 CEST] <furq> well there almost certainly isn't one there [16:12:52 CEST] <furq> so you probably just want to reencode the video [16:13:26 CEST] <furq> HickHoward: what's that even supposed to do [16:13:49 CEST] <killown> furq could you help me reencode the vide to have this keyframe? [16:14:02 CEST] <furq> killown: i don't mean reencode the entire video [16:14:23 CEST] <furq> you can't cut at arbitrary points and use -c copy [16:14:31 CEST] <furq> because the output video has to start on a keyframe [16:14:31 CEST] <DHE> move your -ss to after the input file, and change -c to an actual codec. plus codec options suitable to your needs [16:14:40 CEST] <furq> if you cut and reencode then it'll work fine [16:19:42 CEST] <HickHoward> furq: not do this shit to me -> https://diff.pics/2vcOo4y6Z3ve/1 [16:31:05 CEST] <killown> ffmpeg -y -i *BuUOl7HKM8U.mkv -acodec aac -strict experimental -ss 0:00:10 -t 0:00:13 ../videos/A... [16:31:08 CEST] <killown> still not working [16:35:03 CEST] <quakenet> INVITED: Hello I invite you to a great chat service >< IRC quakenet ORG <<< #philosophy #DALnet , #NASA , #Freenode , #LOVE [16:45:52 CEST] <zalaare> https://pastebin.com/raw/Gg8wUS8x Can someone point out where the "other" filters exist that ffmpeg is complaining about here? I only thought I was using 1 video and 1 audio. [17:16:02 CEST] <Atlenohen> hey guys, VS2017 MSVC doesn't list any linker/compiler arguments for -L from --extra-ldflags=-L../build/lib [17:17:04 CEST] <Atlenohen> I see where was -IInclude like if "Include" is an environmental variable would it for both included headers and libs then? [17:47:06 CEST] <Atlenohen> pretty much the only thing left is ERROR: libx264 not found [17:54:53 CEST] <Atlenohen> Ah it may just be a bash/VC env variable problem, i'll ask on ##linux [17:56:37 CEST] <DHE> pkg-config? maybe you need to set PKG_CONFIG_PATH=/usr/local/lib/pkg-config if you used configure defaults on x264 when building from source [17:56:48 CEST] <DHE> dunno how that works on VC... [17:58:27 CEST] <Atlenohen> Well, it's a MINGW64 shell created from a VS2017 Developer Command prompt which sets environmental variables for that windows (without having to set them up in windows) [17:59:07 CEST] <Atlenohen> I had manually created added more paths and it didn't work, looks like it ignores system ones, that or I need to reboot the machine for it to confirm [17:59:48 CEST] <Atlenohen> I'll first reboot and then all I think I need to figure out is how to input new env into bash [18:00:08 CEST] <Atlenohen> oh I don't have PKG at all, i'll add if it's needed, brb [18:06:01 CEST] <Atlenohen> back [18:06:40 CEST] <Atlenohen> Looks like the windows env won't work echo %comspec% or $comspec won't wokr [18:07:11 CEST] <Atlenohen> well it does work now [18:07:28 CEST] <Atlenohen> I guess it works for non %windowspercent% variables [18:07:59 CEST] <Atlenohen> but that's base MINGW64, now I'll test the VC initialized one, [18:14:09 CEST] <Atlenohen> Oh so if I specify pkconfig then I don't need to specify include and libs [18:18:23 CEST] <Atlenohen> DHE: does this pkg_config_path need to be set under ./configure ? [18:24:06 CEST] <furq> it's an environment variable [18:31:25 CEST] <Atlenohen> Oh I need to use that to actually enter it, okay --pkgconfigdir [18:38:18 CEST] <Atlenohen> furq: still won't work: https://pastebin.com/7fWqUKC3 [18:38:42 CEST] <furq> i've never used msvc so i can't help you [18:39:28 CEST] <DHE> well x264.pc isn't a dir [18:39:46 CEST] <DHE> normally I do "export PKG_CONFIG_PATH=/usr/local/lib/pkg-config" before running configure [18:40:10 CEST] <furq> afaik you should still be able to link gcc dlls to an msvc host as long as you don't link any C++ libs to ffmpeg [18:40:16 CEST] <furq> so it'll probably be easier to do that [18:41:28 CEST] <DHE> it's not recommended, but if you specify enough options that compiling a test x264 application succeeds (eg: --extra-cflags=-I/path/to/x264 --extra-ldflags=-L/path/to/x264 substitute for what VC needs) it should work. [18:42:06 CEST] <furq> if you're only linking one library then specifying paths manually will be simpler [18:42:51 CEST] <furq> you also probably want to use relative paths [18:43:16 CEST] <furq> i never quite figured out at what point msys bash transforms msys paths to actual windows ones but i do know it's pretty fragile [18:43:34 CEST] <furq> so it's best to just use relative paths and avoid that entirely [19:05:14 CEST] <Atlenohen> furq: oh oops, DHE: I'm not sure anymore what pkg-config were talking about, I was linking to the x264 one, not the one in the msys2 install directory [19:05:58 CEST] <syadnom> I'm pulling my hair out trying to get ffmpeg to encode mpeg dash at all, with a goal of multiple streams. can anyone point me to a comprehensive guide or look at what I've got right now that isn't working? [19:11:08 CEST] <Atlenohen> DHE:okay but all the talk is about the env variable, what do you put into the --pkgconfigdir then ? [19:13:28 CEST] <Atlenohen> for relative paths that means I make a copy of the x264/built folder over to the ffmpeg repo, make sense, okay [19:13:50 CEST] <Atlenohen> indeed the whole linux paths inside windows is confusing [19:17:33 CEST] <Atlenohen> DHE: then --extra-ldflags -L is not a MSVC option then, there is no -L anywhere in the C complier options, linker [19:21:10 CEST] <Atlenohen> okay it didn't work, i'm out of ideas, I'll be back later after a big break [19:21:39 CEST] <Atlenohen> this was the final command I tried: CC=cl ./configure --toolchain=msvc --arch=x86_64 --pkgconfigdir=./x264/built/lib/pkgconfig --extra-cflags='-I./x264/built/include -O2 -MT -GS-' --extra-ldflags=-L./x264/built/lib --prefix=./BUILT/x64 [19:25:44 CEST] <Atlenohen> petty issues with licenses making this process 100x the hassle it could be [19:26:04 CEST] <Atlenohen> it could have just been boundled with ffmpeg [19:26:10 CEST] <Atlenohen> meh [19:48:21 CEST] <cptnhmr42> How can I keep audio and video timestamps / idr alligned when transmuxing and transcoding from rtmp to mpeg-dash / hls? [19:59:10 CEST] <cptnhmr42> If no one answers questions in here, should I ask my question on the mailing list? [19:59:47 CEST] <Atlenohen> Okay the thing actually worked [20:01:27 CEST] <Atlenohen> DHE: I used your suggestion to define PGK_CONFIG_PATH, and then I ommited any text from the -I and -L options, and it worked, but it is set for x86 instead of x64, I have installed both YASM and NASM in , I did not enable yasm in ffmpeg config, not sure if that has anything to do with x64 vs x86 [20:02:32 CEST] <Atlenohen> https://pastebin.com/ZTyWR59m [20:07:01 CEST] <Atlenohen> oh, yasm stuff seems deprecated [20:20:42 CEST] <Atlenohen> so wait, it is x86_64, it just gets reported as x86 [20:20:45 CEST] <Atlenohen> i[3-6]86*|i86pc|BePC|x86pc|x86_64|x86_32|amd64) [20:20:45 CEST] <Atlenohen> arch="x86" [21:10:42 CEST] <lindylex> I am trying to concat video using this script https://pastebin.com/jjpkY7w5 I am not sure why it is turning my 4 and 2 minute in length videos in 4 second videos. [21:10:58 CEST] <garyserj> What is this command for libx264? fmpeg -i input.mkv -c:v libx265 -b:v 4000k -an -x265-params no-info=1 output.hevc [21:11:35 CEST] <garyserj> I tried ffmpeg -i c_bad.mp4 -vcodec libx264 -libx264-params no-info=1 -acodec copy d.mp4 and I got "Unrecognized option 'libx264-params'." [21:12:55 CEST] <garyserj> ah, maybe x264-params [21:13:36 CEST] <garyserj> it isn't removing all encodnig settings though. how would I do that? [21:13:43 CEST] <lindylex> garysej: are you trying to use something like this? -codec:v libx264 [21:14:07 CEST] <garyserj> I think -codec:v is the same as -vcodec copy so that's ok [21:15:46 CEST] <Atlenohen> lindylex: because the scrip has trim, you don't need any trim if you want to combine full videos [21:16:13 CEST] <lindylex> Ok thanks that was new to me. Trimming videos this way. [21:16:23 CEST] <garyserj> if you look here https://pastebin.com/raw/ZJHhHGnD c_good.mp4 has no encoding settings and no writing library listed, whereas c_bad.mp4 has writing library listed, and encoding settings e.g. "cabac=1 / ref=3 / deblock=1:0:0 " I want to convert c_bad.mp4 to have no writing library and no encoding settings listed [21:16:25 CEST] <Atlenohen> concat works differnt on different OS I believe, in windows I usually got it working with a list file, a text file that has the input filenames [21:17:51 CEST] <Atlenohen> lindylex: that trim is probably used for a large batch, if you only have one or two videos to trim, you can do that manually with -ss and -to options, like -ss 00:00:10 (start at 10 seconds) and -to 00:00:30 (end at 30) [21:17:54 CEST] <lindylex> Atlnohen I use to use a text file with a list. I no longer. [21:18:12 CEST] <lindylex> That is the way I use to do it. -ss and -to [21:18:14 CEST] <Atlenohen> As you wish if it works better for you [21:18:50 CEST] <lindylex> I was just sharing. And thanks for your input. Trimming the way it is done in the script is new to me. [21:19:26 CEST] <Atlenohen> You may need to customize the script to make trimming the way you need, if necessary, I never used that so I can't tell much from the first look. [21:20:05 CEST] <garyserj> ah -to is useful, i've been using -t [21:20:41 CEST] <lindylex> -to is my favorite. Before that I used -t and I had to do to many calculations. [21:20:49 CEST] <garyserj> heh, i wrote a program to do the calculations! [21:21:04 CEST] <lindylex> What language? [21:21:07 CEST] <Atlenohen> garyserj: the bad.mp4 may be corrupt so it may not show details, if you want to ommit details you may need to HEX edit the file, that's the only way I know right now, I don't know if encoders/muxers have the option to customize or omit the info [21:21:35 CEST] <lindylex> I wrote a wrapper for special effects python calling ffmpeg [21:22:40 CEST] <garyserj> lindylex: ruby [21:23:01 CEST] <garyserj> How can I check if an mp4 is corrupt? [21:23:16 CEST] <garyserj> and how can I fix it if it is corrupt? [21:23:36 CEST] <garyserj> atlen: the bad one iis the one with the details [21:23:56 CEST] <garyserj> Both play, but the bad one won't upload to youtube and the good one will [21:24:29 CEST] <lindylex> Atlenohen : https://github.com/MotionDesignStudio/commandlinemediahelper [21:24:48 CEST] <lindylex> sorry I meant garyserj : https://github.com/MotionDesignStudio/commandlinemediahelper [21:24:56 CEST] <garyserj> thanks ,i'll check that [21:25:00 CEST] <garyserj> bbiab like 3h but will check for any replies when I get back [21:25:13 CEST] <lindylex> Send me yours please. [21:25:39 CEST] <Atlenohen> furq, DHE: I managed to do something, but it produced .a files not .lib, they're much smaller than they suppose to be IMO as I have a lot more encoders/muxers enabled than the 5 year old versions have [21:29:12 CEST] <garyserj> lindylex : I haven't used it in ages and there seems to be a little bug but anyhow https://pastebin.com/raw/B0fTcJLt you just entered the start and end time and it told you the -ss and -t [21:29:25 CEST] <lindylex> Atlenohen I am having issues removing the trim and getting this ffmpeg command to run. [21:29:46 CEST] <garyserj> lindylex: nothing special, like a 5min program! [21:30:02 CEST] <lindylex> Thanks nice work. [21:30:10 CEST] <garyserj> heh, gotta go though, bbaib 3h [21:30:32 CEST] <garyserj> slight bug on gets.chomp but the calculation s fnie [21:30:56 CEST] <garyserj> not seen that bug before but it says bug on line 18. should be quick to fix but i gtg. [23:07:13 CEST] <lindylex> I am trying to remove the trim and the audio removal from the ffmpeg command without success. I tried sever variations with no success. https://pastebin.com/Psn7cp0H [23:23:00 CEST] <Ariyasu> maybe try concat the source files [23:23:11 CEST] <Ariyasu> so your working with less inputs [23:23:23 CEST] <Ariyasu> might make it easier to work out where things are goign wrong [23:24:18 CEST] <lindylex> The source files need to have the transition between them. This is why I can not concat before applying the filter. [23:56:12 CEST] <faLUCE> Hello all. JEEB: I just got a confirmation from MPEG LA :-) [00:00:00 CEST] --- Sat Apr 13 2019

1 0

ffmpeg-devel.log.20190411
by burek 12 Apr '19

12 Apr '19

[00:14:47 CEST] <cone-246> ffmpeg 03Michael Niedermayer 07master:7f3d39b21f89: avcodec/pnm_parser: Support concatenated ASCII images [00:14:47 CEST] <cone-246> ffmpeg 03Michael Niedermayer 07master:1d43d72b181a: avcodec/pnm_parser: Factor next initialization out [00:14:47 CEST] <cone-246> ffmpeg 03Michael Niedermayer 07master:3fe37033b982: avcodec/pnm_parser: Factor out next/index compensation [08:09:12 CEST] <cone-788> ffmpeg 03Lauri Kasanen 07master:ce92ee4b4f3e: swscale/ppc: VSX-optimize non-full-chroma yuv2rgb_2 [11:59:50 CEST] <cone-788> ffmpeg 03Paul B Mahol 07master:0f2835597484: avcodec/agm: add support for higher compression [11:59:51 CEST] <cone-788> ffmpeg 03Paul B Mahol 07master:7be8f7ac8143: avcodec/agm: add support for non-dct coding [11:59:52 CEST] <cone-788> ffmpeg 03Paul B Mahol 07master:d0f24df648f4: avcodec: add ADPCM AGM decoder [13:44:05 CEST] <durandal_1707> michaelni: what type of NALs are those? : https://github.com/richardpl/FFmpeg/blob/imm5/libavcodec/h264dec.c#L956 [13:45:19 CEST] <nevcairiel> 0x67 in the 5th spot is SPS, 0x68 is PPS [13:45:32 CEST] <JEEB> if it's H.264 the spec should have a nice list [13:45:35 CEST] <JEEB> for NAL unit types [13:47:54 CEST] <nevcairiel> note that the type is only 0x1f of that byte, so its 7 and 8, ie. sps and pps [14:02:46 CEST] <durandal_1707> and what they contain? [14:03:18 CEST] <nevcairiel> information to decode the video! [14:03:18 CEST] <nevcairiel> :) [14:03:30 CEST] <durandal_1707> like? [14:04:05 CEST] <nevcairiel> read the syntax spec yourself =p [14:04:50 CEST] <nevcairiel> profile, width/height/bitdepth, all that stuff, various flags [14:26:00 CEST] <pranayvshah> Is this the right place to hire an ffmpeg dev from? [14:26:17 CEST] <JEEB> this has developers at least :P [14:26:39 CEST] <JEEB> the ffmpeg-devel mailing list is another venue since I don't think we have a specific list for offers [14:28:17 CEST] <pranayvshah> Alright, will post there too. I went through drawtext filter's .c code and libfribidi seems to be the only shaper supported. Who would be the right dev to add support for harfbuzz and are they available for contracting work? [14:31:33 CEST] <BradleyS> i believe libass uses harfbuzz if enabled, and ffmpeg can use libass if enabled [14:31:50 CEST] <BradleyS> this is how we use harfbuzz in handbrake, for example [14:32:34 CEST] <pranayvshah> But that's just the ass/subtitles filter, drawtext wouldn't use libass right? [14:33:11 CEST] <BradleyS> indeed, subtitles only but might be helpful reference [14:34:24 CEST] <BradleyS> see also http://ffmpeg.org/consulting.html [14:34:48 CEST] <BradleyS> and do email the ffmpeg-devel mailing list [14:35:11 CEST] <pranayvshah> Agreed, and will email to the dev list. Thank you :) [14:44:15 CEST] <durandal_1707> aren't there ass filter? [14:45:19 CEST] <JEEB> yup, for cases where a static ASS file can be generated it should be good enough [14:45:43 CEST] <JEEB> since it effectively just tells libass to parse an ASS file [19:47:54 CEST] <cone-562> ffmpeg 03Michael Niedermayer 07master:3308e3da045e: avcodec/agm: Check frame dimensions [20:47:47 CEST] <cone-562> ffmpeg 03James Almer 07master:80e9f50f82a7: avcodec: add an AV1 frame split bitstream filter [21:05:12 CEST] <cone-562> ffmpeg 03James Almer 07master:c5a825dc7536: configure: fix av1_frame_split bsf dependencies [21:47:41 CEST] <cone-562> ffmpeg 03Marton Balint 07master:6ed7df5b20e4: avformat/mxfdec: export operational pattern UL as file metadata [21:47:42 CEST] <cone-562> ffmpeg 03Marton Balint 07master:3e10223385b8: avformat/file: add seekable option to disallow seeking [00:00:00 CEST] --- Fri Apr 12 2019

1 0

ffmpeg.log.20190411
by burek 12 Apr '19

12 Apr '19

[00:00:24 CEST] <phisch> kepstin: that could explain it, but default behavior should be that background tasks don't receive the sigint afaik [00:00:34 CEST] <phisch> don't know why this should be different for me [00:01:34 CEST] <kepstin> but that would explain the behaviour - if ffmpeg receives *two* SIGINT, the first starts a clean exit, but the second aborts that and exits immediately [00:02:11 CEST] <phisch> yeah, but i don't know how i could check/prevent this [00:03:05 CEST] <phisch> i think this is very ffmpeg related [00:05:28 CEST] <kepstin> I explained ffmpeg's behaviour ^^ [00:06:31 CEST] <phisch> do you know if there is a way to disable this behavior then? :P [00:07:12 CEST] <phisch> or could you run the script, hit ctrl+c and tell me your output? just to make sure that this is not some messed up stuff related to my system [00:07:14 CEST] <kepstin> I'm really not familiar enough with how the process group stuff in the shell works to give a suggestion :/ [00:07:26 CEST] <kepstin> this is the expected behaviour with your script, i think. [00:11:06 CEST] <phisch> no, i expect that when my script receives a sigint (either by `kill -INT [PID]` or `ctrl+c`) the sigint trap handles gracefully killing background processes [00:23:20 CEST] <kepstin> hmm. i really dislike working with signal handling. I can't even get that working when just running 'sleep' instead of ffmpeg :/ [00:25:53 CEST] <kepstin> phisch: you might have better results if you remove the 'wait $FFMPEG_PID' from the signal handler [00:26:48 CEST] <phisch> i need to wait until it's completely done though [00:27:05 CEST] <kepstin> don't wait in the signal handler :/ [00:27:46 CEST] <phisch> i have to, since i want to run the script via a shortcut and kill it with another one [00:28:22 CEST] <kepstin> not sure what you mean. you shouldn't need to wait in the signal handler, you're already waiting at the end of the script [00:32:21 CEST] <phisch> you hit a shortcut, select a screen area with slop, it records that screen area with ffmpeg, once the process is killed via another shortcut the trap sends a sigint to ffmpeg and then waits until the process has fully exited, then takes the video and makes a gif out of it [00:33:16 CEST] <kepstin> ah, the issue is that the signal handler interrupts the wait at the bottom of the script and it doesn't get resumed :/ [00:33:40 CEST] <phisch> yes, thats why i need the wait in the signal handler [00:34:28 CEST] <phisch> and everything works for my use-case, but i'd really like to also be able to use this from a terminal directly and having it work with hitting ctrl+c [00:34:42 CEST] <phisch> but as we have seen the ctrl+c somehow sends 2 sigints to ffmpeg [00:34:55 CEST] <phisch> because ffmpeg does some magic or whatever [00:39:01 CEST] <kepstin> just to confirm, you want to run some other commands in the same script after ffmpeg exits? [00:41:48 CEST] <kepstin> probably the easiest solution is to run the ffmpeg command under nohup (like `nohup ffmpeg <args> &`), that'll make all the signals work the way you expect. Note that nohup by default sends the command output to a file named nohup.out. [00:42:27 CEST] <kepstin> (bit of a big hammer for this, since you probably would want ffmpeg to be killed if you close the terminal, but it'll work) [00:44:46 CEST] <phisch> yeah, detaching with nohup seems like something worth trying [00:45:21 CEST] <phisch> and yes, i want to run more commands, my example is just a stripped down version to illustrate the problem without unnecessary stuff [00:47:01 CEST] Action: kepstin has confirmed that it works - if you still want the command output in the terminal, `nohup ffmpeg ... | cat &` is a hilarious way of doing it. [00:47:35 CEST] <kepstin> i assume there must be a way to do this without nohup, but..? :/ [00:48:02 CEST] <phisch> yeah, without would be perfect [01:49:30 CEST] <kevinnn> does anyone know if vlc streams rtsp using UDP by default? [01:49:43 CEST] <kevinnn> and if it does how can I set it to use TCP? [03:10:12 CEST] <memelover> I'm attempting to transcode some FLACs to ALAC. The specific command I'm using is "ffmpeg -i song.flac -acodec alac -map 0:0 song.m4a. This seems to preserve most of the tags, but not all. For example, the "total tracks" tag does not appear in the m4a.Is there some gotcha that I'm missing? [03:11:52 CEST] <memelover> It also appears to gut the replaygain data. [03:17:21 CEST] <klaxa> there is a -map_metadata flag, maybe look into that? [03:18:10 CEST] <klaxa> https://ffmpeg.org/ffmpeg.html#Advanced-options [03:21:40 CEST] <memelover> Hmm. It says that if not included, it defaults to including all metadata. [03:24:53 CEST] <klaxa> -map 0:0 excludes everything but track 0 from file 0 though [03:25:05 CEST] <klaxa> not sure if that also excludes metadata, but maybe? [03:25:15 CEST] <klaxa> but if you tried and it didn't help, guess not [03:33:18 CEST] <memelover> Well, my reason for doing that is that track 1 sometimes contains an mjpeg album cover, which ffmpeg really doesn't like. It cannot seem to process it at all, so my plan is to add it back in after transcoding. [03:34:27 CEST] <memelover> And it looks like the replaygain data isn't actually metadata, but information inside the audio track. Even -fflags keepside doesn't seem to help with that. [03:41:03 CEST] <phisch> kepstin: wait, how did you get nohup to work? [06:25:59 CEST] <damdai> anybody know what it means by "fragmented" and "cbcs" ? http://download.opencontent.netflix.com/?prefix=AV1/Chimera/ [07:29:16 CEST] <damdai> what is wrong with ffmpeg devs? [07:29:29 CEST] <damdai> they closed my bug report for no reaosn [07:32:13 CEST] <damdai> dongs you there? [08:39:15 CEST] <pkunk> Does "-use_wallclock_as_timestamps 1" work with mpegts streams? [08:40:44 CEST] <pkunk> I sometimes get "non-monotonous" packet errors on output. So tried this option, but with this I instead get "DTS discontinuity in stream 1" errors as the mpegts packets sometimes come in out of order over http [08:42:03 CEST] <pkunk> Or is there any other way to "fix" the timestamps on mpegts streams so I can avoid the dreaded "non-monotonic" errors on av_interleaved_write_frame() [10:04:33 CEST] <JEEB> pkunk: if it's wrap-around that's standard in MPEG-TS in theory libavformat has wrap-around handling but that only seems to work once. ffmpeg.c then attempts to do it again in a separate piece of logic. [10:05:15 CEST] <JEEB> for that specific option what it does is it overrides the timestamp in libavformat's utils [10:05:28 CEST] <JEEB> in other words if you have b-frames etc it will just bork [10:05:31 CEST] <JEEB> pkt->dts = pkt->pts = av_rescale_q(av_gettime(), AV_TIME_BASE_Q, st->time_base); [10:06:18 CEST] <JEEB> so yes the option will "work" for MPEG-TS input, but I think of this as something that an API client would handle rather than the framework (I like the way upipe has three timestamps) [10:06:43 CEST] <JEEB> (in upipe each packet has three timestamps: original coded, coded+wrap-arounds etc handled, receipt time) [10:07:41 CEST] <JEEB> that way the API client can still know the original timestamps but attempt to normalize the stream in case the input timestamps are actually broken [11:50:12 CEST] <pkunk> JEEB: Thanks JEEB . I'm using the console ffmpeg right now, modified to do parallel open of all input streams [11:51:57 CEST] <pkunk> Excuse the additional nickname, Will have a look at what "upipe" is . First time I've heard of it [11:57:44 CEST] <cartman412> Hi there! I've been making a gif maker using ffmpeg and I noticed that for some reason, when I try to add padding the final output quality seems to lower drastically. Here are the commands I use (no padding/padding): https://pastebin.com/3rrAJ0df / https://pastebin.com/uYg8PZuq and a screenshot of the resulting gifs (no padding/padding): https://pasteboard.co/I9CCPmr.png / https://pasteboard.co/I9CD8xK.png [11:58:20 CEST] <cartman412> Also note how the padding color seems to leak into the actual video on the left side [11:58:28 CEST] <cartman412> Any ideas of what I might be doing wrong? [11:58:49 CEST] <JEEB> pkunk: it's a more broadcast-oriented multimedia framework that has modules for decoding through FFmpeg etc [11:58:55 CEST] <JEEB> it has some nice ideas [11:59:11 CEST] <furq> cartman412: you probably want to pad before calling paletteuse [11:59:56 CEST] <cartman412> that was what I was thinking, thanks for confirming it :) I'll try this now! [12:08:08 CEST] <cartman412> furq your suggestion fixed the quality and pad color leaking into the actual image, but now the padding color seems to be affected instead [12:08:41 CEST] <furq> yeah it sounds like the problem is that the pad color isn't in the generated palette [12:08:41 CEST] <cartman412> https://pasteboard.co/I9CJAB7.png [12:08:59 CEST] <cartman412> so I should add padding when generating the palette as well? [12:09:05 CEST] <furq> that should work [12:09:22 CEST] <cartman412> awesome, thanks for the quick answers :) [12:16:48 CEST] <cartman412> furq: it worked! https://pasteboard.co/I9CMJz4.png thank you so much! :) [13:19:01 CEST] <Atlenohen> Any idea what this does in ffmpeg's config? --extra-cflags='-MT -IWindowsInclude -GS-' [13:19:18 CEST] <Atlenohen> Build config [13:22:24 CEST] <furq> they're just extra arguments to your c preprocessor/compiler [13:22:26 CEST] <pink_mist> sets flags for the C compiler [13:22:31 CEST] <pink_mist> yeah, or preprocessor [13:22:58 CEST] <pink_mist> what exactly they do to your C preprocessor or compiler, you'd haveto read its documentation or ask on its support forums [13:24:40 CEST] <furq> if this is msvc then -MT uses the static runtime library and -GS disables buffer security checking [13:24:57 CEST] <furq> i assume -I is the same as gcc (sets a header include directory) [13:39:20 CEST] <King_DuckZ> hi, anyone knows what the -profile:v 3 option would be set in code? I'm using the library directly [15:05:22 CEST] <th3_v0ice> Why would avformat_find_stream_info() fail for a same file that FFmpeg reads properly? Both are from the same version 4.0. [15:34:56 CEST] <pranayvshah> How can I get ass->shaping to hold a value of 1 that is "shaping complex" in here https://github.com/FFmpeg/FFmpeg/blob/release/4.1/libavfilter/vf_subtitles.… [15:35:57 CEST] <JEEB> pranayvshah: set the shaping option to the value "complex" [15:36:27 CEST] <pranayvshah> That option works for the ass filter. I need it to work for the subtitles filter [15:36:28 CEST] <JEEB> oh, that is specific to the ass filter [15:36:30 CEST] <JEEB> right [15:36:43 CEST] <JEEB> just noticed the name of the struct that defines the option :) [15:37:00 CEST] <pranayvshah> Yeah :P [15:37:24 CEST] <JEEB> wonder why it was added as ass-only [15:37:59 CEST] <pranayvshah> I nevertheless tried the same option on the subtitles filter, did not work :D [15:39:28 CEST] <JEEB> ok, sounds like you could try moving the option from ass_options to COMMON_OPTIONS [15:40:04 CEST] <JEEB> if it really works as an option for the other filter that you're utilizing [15:40:05 CEST] <JEEB> :) [15:40:58 CEST] <JEEB> which would effectively make ass_options into COMMON_OPTIONS and then nullptr [15:41:09 CEST] <pranayvshah> As a workaround, I simply set removed the ass->shaping argument and replaced it with 1. That's a lot simpler for me since I know libass is compiled with harfbuzz [15:41:36 CEST] <JEEB> if the option works then we might want to move it into the common options [15:41:48 CEST] <JEEB> if you think that's a useful change and it isn't specific to the ass filter [15:42:42 CEST] <pranayvshah> This does work for me - ass_set_shaper(ass->renderer, 1); [15:43:06 CEST] <JEEB> ok, might post a patch on the mailing list moving the option into the common one [15:43:09 CEST] <JEEB> *common list [15:43:16 CEST] <pranayvshah> I was hoping to not have to use my own compiled version [15:53:57 CEST] <bencoh> 41 [16:08:09 CEST] <Atlenohen> Does this still hold true? http://www.ffmpeg-archive.org/ffvhuff-codec-improvement-td4661530.html FFV1 doesn't operate on per-frame level? And the force intra-frame only is not a 100% workaround? [16:11:29 CEST] <furq> what does "operate on per-frame level" mean [16:12:27 CEST] <DHE> and this is talking mostly about pixel formats [16:12:47 CEST] <DHE> oh, this bit about precise and fast seeking I assume... [16:35:33 CEST] <Atlenohen> Yeah, [16:36:18 CEST] <furq> what makes you think setting the gop size isn't a workaround [16:36:39 CEST] <Atlenohen> I was about to mention that, if the GOP size has anything to do wiht it [16:37:09 CEST] <Atlenohen> I guess good then [16:37:29 CEST] <furq> i mean i don't know that it is [16:37:33 CEST] <furq> i just didn't see that in the thread [16:37:51 CEST] <furq> it ought to work fine with a gop size of 1 [17:03:36 CEST] <HickHoward> uhhhhhhh [20:50:11 CEST] <HickHoward> uhh [20:50:57 CEST] <HickHoward> how can i encode a mpeg2 video file with a custom intra quantizer matrix? [20:52:57 CEST] <HickHoward> wait a second [20:53:00 CEST] <HickHoward> nevermind [21:17:05 CEST] <HickHoward> anyways i'm having a bit of a problem with this filter [21:17:06 CEST] <HickHoward> file:///H:/ffmpeg/doc/ffmpeg-filters.html#toc-il [21:17:32 CEST] <HickHoward> so, with ffmpeg's current version i'm supposed to just use "-vf 'il'" or something? [21:18:46 CEST] <HickHoward> i say this because i tried other options 'il' has in offer like chroma_mode and interleave but none of them work [21:18:48 CEST] <HickHoward> like this [21:18:57 CEST] <HickHoward> "-vf "il=chroma_mode=interleave"" [21:21:12 CEST] <durandal_1707> pastebin full command and ffmpeg output [21:21:24 CEST] <HickHoward> wait [21:21:33 CEST] <HickHoward> ffmpeg.exe -i "H:\Tourist Trophy (Japan)\tt_vol\openingW.m2v" -vf 'il=chroma_mode:interleave' openingW.avi [21:21:35 CEST] <HickHoward> no [21:21:38 CEST] <HickHoward> sorry [21:21:47 CEST] <HickHoward> you meant pastebin [21:22:06 CEST] <HickHoward> https://pastebin.com/TaQKq8VD [21:23:09 CEST] <durandal_1707> HickHoward: il=chroma_mode=interleave [21:23:45 CEST] <HickHoward> pastebin edited [21:23:48 CEST] <HickHoward> doesn't work for me either [21:24:29 CEST] <durandal_1707> HickHoward: you forgot to paste and ffmpeg output of command [21:25:02 CEST] <HickHoward> just the ffmpeg output of command [21:25:11 CEST] <HickHoward> okay [21:26:02 CEST] <HickHoward> pastebin updated [21:29:25 CEST] <durandal_1707> HickHoward: ffmpeg.exe -i "H:\Tourist Trophy (Japan)\tt_vol\openingW.m2v" -vf "il=chroma_mode:interleave" openingW.avi [21:30:28 CEST] <HickHoward> done [21:30:31 CEST] <HickHoward> pastebin updated [21:36:50 CEST] <durandal_1707> HickHoward: Sorry, use: ffmpeg.exe -i "H:\Tourist Trophy (Japan)\tt_vol\openingW.m2v" -vf "il=chroma_mode=interleave" openingW.avi [21:37:55 CEST] <HickHoward> okay, *now* it works [21:39:53 CEST] <HickHoward> well, i feel like i haven't communicated my idea with this yet [21:40:00 CEST] <HickHoward> so, the source file looks like this [21:40:01 CEST] <HickHoward> https://i.boring.host/WS8WD5U.png [21:40:21 CEST] <HickHoward> what you're seeing here is *two* frames being combined into one [21:40:33 CEST] <HickHoward> and the frame rate is halved [21:40:36 CEST] <HickHoward> because of this [21:41:08 CEST] <HickHoward> (as in, the original frame rate of this source file is 29.98 fps) [21:41:16 CEST] <HickHoward> *29.97 fps [21:42:31 CEST] <durandal_1707> use weave/doubleweave [21:42:38 CEST] <HickHoward> okay [21:44:40 CEST] <HickHoward> tested it, all that ever did was double the horizontal screen size of the output file [21:44:55 CEST] <HickHoward> *all that ever did => all that weave/doubleweave [21:49:10 CEST] <durandal_1707> HickHoward: il=1:1:1 [21:49:25 CEST] <HickHoward> hold on [21:49:27 CEST] <durandal_1707> HickHoward: il=1:1:1,separatefields [21:49:42 CEST] <HickHoward> okay, testing now [21:54:26 CEST] <HickHoward> tested, now the frame organization is wrong as all hell(first frame is bottom, second frame is top, and so on until the end of video) so i had to put setfield=tff before separatefields [21:57:45 CEST] <durandal_1707> HickHoward: so it works? if not upload first 20 frames somewhere [21:57:54 CEST] <HickHoward> yes [22:16:15 CEST] <HickHoward> okay, now i've done this [22:16:17 CEST] <HickHoward> ffmpeg.exe -i "H:\Tourist Trophy (Japan)\tt_vol\openingW.m2v" -vf "il=1:1:1,setfield=tff,separatefields" -vcodec rawvideo -pix_fmt bgr24 openingW.avi [22:16:36 CEST] <HickHoward> and now i want the output video to remain its input resolution(640x448) [22:19:06 CEST] <cptnhmr42> Does anyone know if there are any patches out there for dealing with AV sync issues when converting RTMP to HLS / MPEG-DASH? [23:08:34 CEST] <faLUCE> Hello. If a GPL non-commercial library uses ffmpeg/x264, does it have to contact/pay something to MPEG LA ? [23:09:46 CEST] <faLUCE> it seems that MPEG LA's license doesn't talk about FOSS projects, and requires a fee only for big commercial ones [23:11:42 CEST] <JEEB> software licensing is unrelated to patent licensing due to distributing binaries [23:12:30 CEST] <faLUCE> JEEB: and what does this cause? [23:13:24 CEST] <JEEB> that whether something is open source or not doesn't matter. you look if <patent licensing for thing X> is applicable to you (maybe consult a lawyer if you care enough) regardless [23:14:25 CEST] <JEEB> I don't know your laws and whether such licensing is applicable in your country to begin with [23:14:51 CEST] <faLUCE> JEEB: for example, in France? [23:15:07 CEST] <JEEB> VideoLAN seems to be on the stance of middle fingering [23:15:15 CEST] <JEEB> given that they are not paying for VLC distribution [23:16:02 CEST] <faLUCE> JEEB: but what if a library doesn't provide binaries? [23:16:13 CEST] <JEEB> then at least with MPEG-LA you have no problems [23:16:17 CEST] <JEEB> they license binary distribution [23:16:32 CEST] <JEEB> at least according to a quote from donald graft on doom9 ages ago [23:16:51 CEST] <JEEB> if you start caring about patent licensing of course, then there's way more than just MPEG-LA :P [23:17:46 CEST] <JEEB> it's a messy thing if you really want to start looking into it [23:18:03 CEST] <faLUCE> JEEB: yes, I tried to understand but it's too messy [23:18:19 CEST] <faLUCE> after reading several posts I did not get any conclusion [23:18:22 CEST] <JEEB> well, the MPEG-LA rules in general are pretty simple [23:18:25 CEST] <JEEB> for H.264 at least [23:18:55 CEST] <faLUCE> which are them? [23:19:00 CEST] <JEEB> https://www.mpegla.com/wp-content/uploads/avcweb.pdf [23:19:08 CEST] <JEEB> this is the brief overview [23:19:43 CEST] <JEEB> for example for encoders you pay nothing if you distribute 0-100k binaries :P [23:20:04 CEST] <faLUCE> JEEB: where is the word "binary" in that doc? [23:20:29 CEST] <JEEB> "Products sold to end users" is basically binary distribution to end user [23:20:46 CEST] <faLUCE> JEEB: in this case thekeyword is "sold", not "binary" [23:21:05 CEST] <JEEB> yes, but you can sell it for $0. it's made for businesses that generally don't set the price at $0 :P [23:21:11 CEST] <JEEB> of course [23:21:17 CEST] <JEEB> nothign stops you from *asking* MPEG-LA [23:22:17 CEST] <faLUCE> JEEB: but why a library is not a "product" ? [23:22:25 CEST] <JEEB> ? [23:22:36 CEST] <JEEB> I don't think whether it's a library or not matters [23:23:18 CEST] <faLUCE> so, it's not clear if open source code is not a "product sold to end user" [23:23:25 CEST] <faLUCE> (encoder) [23:23:31 CEST] <JEEB> I will have to find the quote [23:23:39 CEST] <JEEB> but MPEG-LA has said that they don't care about *source* [23:23:40 CEST] <durandal_1707> faLUCE: you need to pay for any non-foss codec usage as user to my address [23:24:26 CEST] <faLUCE> durandal_1707: yes, in fact I understood that MPEG LA wants to be payed for non FOSS [23:24:37 CEST] <faLUCE> durandal_1707: but where is it specified in their license? [23:24:47 CEST] <faLUCE> it doesn't talk about foss or non foss [23:25:16 CEST] <JEEB> https://forum.doom9.org/showthread.php?t=156599 [23:25:34 CEST] <JEEB> yea, MPEG-LA does not care if the distributed software (binaries) is OSS or not [23:26:32 CEST] <durandal_1707> OSS is irrelevant to them, they count only implementations [23:27:06 CEST] <JEEB> well, as I noted (this is not legal advice) they don't really care about open source (by non-corps) [23:27:13 CEST] <JEEB> or well, it would be stupid to go after them [23:27:43 CEST] <faLUCE> [23:27] <JEEB> well, as I noted (this is not legal advice) they don't really care about open source (by non-corps) <--- this is true, but tehy could, if they want [23:28:08 CEST] <JEEB> yes [23:28:16 CEST] <JEEB> if they would want to enforce it they 100% could attempt to [23:28:25 CEST] <JEEB> whether such patent licensing is valid in your country is the key [23:28:29 CEST] <JEEB> > Ryan has just clarified that indeed source code is not a "product" in the required sense. He clarified that anybody creating a product using FFMPEG source code is a supplier, so anyone compiling and supplying the binary library would be subject to licensing. [23:28:42 CEST] <JEEB> this is the quoting from MPEG-LA [23:29:40 CEST] <faLUCE> JEEB: so, if a library wraps ffmpeg, there are not binaries or "products" [23:29:56 CEST] <JEEB> faLUCE: until someone produces a binary and distributes it to users, yup [23:30:05 CEST] <JEEB> source code only is something that MPEG-LA does not care about [23:30:41 CEST] <JEEB> or at least this was the case in 2010 [23:31:01 CEST] <faLUCE> JEEB: in case MPEG LA cares about source code, it would stop/break projects like vlc,ffmpeg, mplayer and tons of other stuff downloaded by million of users [23:31:20 CEST] <faLUCE> this would be absurd [23:31:25 CEST] <durandal_1707> really? [23:32:13 CEST] <faLUCE> durandal_1707: so this is the reason for which they don't do anything [23:32:30 CEST] <faLUCE> ? [23:34:01 CEST] <durandal_1707> sometimes they ask authors to remove source code implementing certain codecs [23:34:22 CEST] <faLUCE> durandal_1707: which codecs for example? [23:34:59 CEST] <durandal_1707> any random one =p [23:36:06 CEST] <faLUCE> durandal_1707: but they asked that to ffmpeg too? [23:36:42 CEST] <durandal_1707> yea [23:37:03 CEST] <faLUCE> and did ffmpeg remove the code? [23:37:45 CEST] <durandal_1707> nope [23:38:06 CEST] <faLUCE> durandal_1707: and they (MPEG LA) did not do anything else? [23:38:43 CEST] <durandal_1707> uhg, i dunno about MPEG LA, I was talking about other companies [23:39:29 CEST] <faLUCE> durandal_1707: so there's a fight between companies and ffmpeg [23:40:33 CEST] <durandal_1707> more like fight with authors of certain REd code [23:41:06 CEST] <HickHoward> gotta protect my codecs! [23:41:23 CEST] <faLUCE> durandal_1707: but do they have really power to begin a legal action against ffmpeg ? [23:42:01 CEST] <durandal_1707> dunno, anything can change [23:43:31 CEST] <faLUCE> then it's a very obscure situation :-( [23:44:36 CEST] <faLUCE> JEEB: from what "ryan" of the linked discussion say, that companies could not do anything [23:46:32 CEST] <faLUCE> let's ask to x264 channel too... [23:47:08 CEST] <durandal_1707> x264 is encoder, while i mainly talked about decoders [23:47:36 CEST] <faLUCE> durandal_1707: what's the difference, in terms of legal stuff? [23:48:50 CEST] <durandal_1707> dunno, for important legal stuff ask lawyers [23:49:50 CEST] <durandal_1707> short story: if you make money on ffmpeg, they will come after you... [23:50:01 CEST] <faLUCE> durandal_1707: this is not my case [23:50:11 CEST] <faLUCE> and I understood that [23:51:11 CEST] <faLUCE> durandal_1707: but I wondered if is there anything in their licens/docs that assures that if you DON'T provide binaries and DON'T make money , you won't have probles [23:51:16 CEST] <faLUCE> problems [23:51:32 CEST] <JEEB> of course not, why would they write that :D [23:52:05 CEST] <JEEB> but at least the binary distribution is a requirement for *MPEG-LA* [23:52:12 CEST] <faLUCE> JEEB: for completeness [23:52:16 CEST] <JEEB> so it doesn't matter for MPEG-LA if you're OSS or not [23:52:27 CEST] <JEEB> if you don't distribute binaries you're not distributing to end users [23:52:34 CEST] <JEEB> that's an early exit :P [23:52:46 CEST] <JEEB> (not legal advice but that's how a lot of people read it) [23:53:05 CEST] <faLUCE> JEEB: it seems more a "common thought" that the reality [23:53:35 CEST] <JEEB> faLUCE: for you, not for MPEG-LA or any other licensor. for the licensor it is much better if there are cases where someone is unsure, and thus they are more likely to license [23:53:46 CEST] <JEEB> for possible licensees it is of course worse [23:53:47 CEST] <JEEB> :P [23:54:09 CEST] <JEEB> thus it becomes a legal thing and the only ones that can advise you on that are lawyers [23:55:21 CEST] <JEEB> or if you want MPEG-LA's opinion, ask them [23:55:32 CEST] <faLUCE> but in the case they want to require license from one of these GPL non-commercial products, they would have to do that for all of them [23:56:04 CEST] <JEEB> dunno, I don't know if there are such requirements in laws [23:56:14 CEST] <JEEB> I Am Not A Lawyer (IANAL) [23:56:43 CEST] <faLUCE> JEEB: anyway, "Ryan has just clarified that indeed source code is not a "product" in the required sense. He clarified that anybody creating a product using FFMPEG source code is a supplier, so anyone compiling and supplying the binary library would be subject to licensing." <-- it doesn't quote ryan's words [23:56:50 CEST] <JEEB> true [23:57:00 CEST] <JEEB> he did leave ryan's contact though [23:57:09 CEST] <JEEB> feel free to request a new quotable thing [23:57:23 CEST] <JEEB> if you want MPEG-LA's opinion on things [00:00:00 CEST] --- Fri Apr 12 2019

1 0

ffmpeg-devel.log.20190410
by burek 11 Apr '19

11 Apr '19

[01:05:29 CEST] <jamrial> jkqxz: i disagree, sps parsing can and should be added to libavformat [01:05:39 CEST] <jamrial> we did it for hevc, and av1 [01:05:58 CEST] <jamrial> making that function avpriv can be a pita in the long run [01:06:21 CEST] <nevcairiel> also his current code is super wrong, semantically [01:06:39 CEST] <nevcairiel> he passes some random pointer as AVCodecContext [01:06:57 CEST] <nevcairiel> if the code ever tries to access it, nevermind a ssuming it may have a H264Context in its priv_data, there is no c oming back from that [01:07:00 CEST] <jamrial> it's for logging purposes. the AVClass is always first [01:07:07 CEST] <jamrial> but yes, it's ugly [01:07:08 CEST] <nevcairiel> but the API does not document it like that [01:07:10 CEST] <nevcairiel> hence, wrong [01:07:23 CEST] <nevcairiel> its an AVCodecContext argument, it needs to get one, a real one [01:08:23 CEST] <jkqxz> So limited copy of H.264 header parsing? I guess it doesn't actually need that much of it. [01:08:49 CEST] <jamrial> yeah, only until the beginning of vui_parameters [01:09:23 CEST] <cone-114> ffmpeg 03Lynne 07master:4d2f62150dba: aarch64/opusdsp: implement NEON accelerated postfilter and deemphasis [01:11:46 CEST] <jkqxz> I wonder whether it could include cbs_h264_syntax_template.c. [01:12:00 CEST] <jkqxz> Hmm, probably a bit too horrible. [01:12:36 CEST] <jkqxz> A file include might be better than a complete reimplementation, still. [01:25:08 CEST] <jamrial> jkqxz: i suggested to basically copy what you did in cbs_h264, since it's the simplest, most straightforward sps parsing function in the codebase [01:25:53 CEST] <jamrial> compared to h264_ps, which does a lot more than just read bits, it should be trivial to copy into libavformat [01:32:34 CEST] <jkqxz> The fatal case would be when the next version of this format decides it needs to know the value of some field that is currently discarded (something HRD, say). Then you're entirely screwed with this avpriv approach. [01:39:15 CEST] <jkqxz> Also the code does already write to some random memory through that forged AVCodecContext pointer: <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/h264_ps.c;h=17bfa…>. [01:57:26 CEST] <tmm1> is it possible to define and register an AVInputFormat at runtime? [01:58:44 CEST] <jamrial> no [02:00:26 CEST] <tmm1> thanks [02:26:20 CEST] <jamrial> i could use other people's opinion on that thread [10:37:27 CEST] <cone-522> ffmpeg 03joepadmiraal 07master:951561b64ee6: libavformat/dashenc : Prevent writing manifest files multiple times [12:42:14 CEST] <cone-522> ffmpeg 03Don C. Bigler 07master:2be7c388db67: avdevice/opengl_enc: fix build error using msvc compiler [14:36:46 CEST] <thardin> oof, that mxf avg_frame_rate ticket [14:37:47 CEST] <thardin> I went over S336m and it turns out ULs are not allowed to contain bytes 0x80-0xFF [14:38:28 CEST] <thardin> so the probe function can be improved somewhat [14:52:59 CEST] <thardin> ah no, that's only for the first 8 bytes of the UL [16:06:49 CEST] <thardin> getting a bit annoyed at all these hacks that don't have corresponding files in FATE [16:13:41 CEST] <kurosu> thardin: I think michaelni and cehoyos also run ffmpeg against ticket files. Dunno how and how much though, but that's why they sometimes come back with issues [16:20:01 CEST] <thardin> i see [16:22:07 CEST] <thardin> still, should be in fate [16:36:23 CEST] <rcabrera> Pasting this here as I wrote it on the wrong channel. [16:36:42 CEST] <rcabrera> I am parsing this args with avfilter_graph and creating a filter graph, however even I get the frames from the buffersink the filter doesn't seem to be applied. [16:36:42 CEST] <rcabrera> https://pastebin.com/LATvky15 [16:36:42 CEST] <rcabrera> Any idea of why this could be happening? [16:36:42 CEST] <rcabrera> The image should be flipped but instead I see the frame as if no filters were applied [16:42:55 CEST] <kurosu> thardin: I did that for some of the tickets that I fixed [16:43:27 CEST] <kurosu> and some people/parties expressed interest in adding as many of these files as possible [16:43:43 CEST] <kurosu> though size of the fate suite was mentioned [16:47:01 CEST] <kurosu> and fate-suite grew by 20MB since I last sync'ed it \o/ [16:54:56 CEST] <durandal_1707> sent 319 bytes received 572,663 bytes 163,709.14 bytes/sec [16:54:58 CEST] <durandal_1707> total size is 1,158,179,157 speedup is 2,021.32 [17:02:10 CEST] <thardin> kurosu: the problem is that it's hard to write patches to certain things (like probing) if such samples can't be tested by all [17:25:37 CEST] <durandal_1707> trac is 503 [17:30:48 CEST] <BtbN> %256 and &255 is equivalent, right? Or am I confusing myself? [17:31:34 CEST] <JEEB> & 0xFF basically selects the least significant byte's value [17:31:53 CEST] <JEEB> the hex-version at least makes it easier to see for me than just a 255 [17:31:54 CEST] <durandal_1707> negative is differents i think [17:32:08 CEST] <BtbN> Only caring about unsigned ints [17:33:12 CEST] <JEEB> so basically you will be getting the value between 0x00-0xFF from the least-significant byte. so I would *guess* for unsigned ints they're equivalent with % 256 [17:37:00 CEST] <BtbN> Yeah, I'm just gonna roll with the assumption. Compiler will optimize it anyway I guess [17:39:51 CEST] <durandal_1707> do not use % [17:47:47 CEST] <ubitux> BtbN: not if it's signed [17:48:50 CEST] <ubitux> using % on x86 generates 5 more instructions here (gcc -O2) on signed int [17:49:07 CEST] <BtbN> Yes, on signed ints it's clearly different [17:49:34 CEST] <nevcairiel> & on signed probably also doesnt make much sense [17:49:56 CEST] <nevcairiel> except for cases where one tries to be very smart = p [17:50:01 CEST] <BtbN> it ignores the signedness pretty much [17:50:34 CEST] <ubitux> there are many places where we use signed instead of unsigned but rely on it to be positive [17:50:56 CEST] <ubitux> it sometimes happen that you want to detect -1 only and not the whole negative space [17:51:37 CEST] <nevcairiel> sure, but in reality you are not really dealing with a signed number [17:51:49 CEST] <nevcairiel> i mostly meant & on negative n umbers is weird [19:01:58 CEST] <durandal_1707> anybody here can read japanese? i need some bitmap translated [19:02:10 CEST] <JEEB> sure [19:03:45 CEST] <durandal_1707> https://0x0.st/zZk0.png [19:04:23 CEST] <JEEB> this selection cannot be done with the free version [19:06:06 CEST] <durandal_1707> aha, thanks, the other version of similar software is limited differently but somehow buggy [19:06:21 CEST] <JEEB> np [00:00:00 CEST] --- Thu Apr 11 2019

1 0

ffmpeg.log.20190410
by burek 11 Apr '19

11 Apr '19

[01:03:03 CEST] <Atlenohen> hi trying to compile ffmpeg on linux mint (latest) any tips that aren't on the compilation guide [01:04:21 CEST] <Atlenohen> I'm usually on windows but I can do live linux boot and I was wondering if it's going to be less than a few hours so I don't need to leave, I don't have a good place or conditions to intall linux for some time due to HDD/Data maintenance/archiving taking place [03:39:38 CEST] <HickHoward> uhh [03:44:19 CEST] <HickHoward> so [03:45:07 CEST] <HickHoward> i have a mpeg2 video file whose frame consists of both the top and bottom feeds for whatever reason [03:45:08 CEST] <HickHoward> https://i.imgur.com/fOKgS3s.png [03:45:09 CEST] <HickHoward> like this [03:45:43 CEST] <HickHoward> *feeds => fields of a frame [03:45:53 CEST] <HickHoward> okay to elaborate [03:46:21 CEST] <HickHoward> in this image you are seeing two frames being merged together into both the top and the bottom fields each [03:46:44 CEST] <HickHoward> and i want to handle both fields of a frame so the final video can have this "interlaced" look [03:47:02 CEST] <HickHoward> but the thing is how can i actually do that *without* having to convert one format into another? [03:56:21 CEST] <iive> HickHoward, check `man ffmpeg-filters` 'il Deinterleave or interleave fields." [03:58:12 CEST] <iive> he didn't see it. [04:43:39 CEST] <CarlFK> this works: ffplay tcp://localhost:11000 - anyone know how to make melt use ffmpeg do play that? [04:43:51 CEST] <CarlFK> docs lead me here: https://www.mltframework.org/plugins/ProducerAvformat/#rtsp_transport [04:47:24 CEST] <CarlFK> I'm guessing something like melt -producer avformat:rtsp_transport tcp=tcp://localhost:11000 [04:51:51 CEST] <Atlenohen> hello [04:52:27 CEST] <Atlenohen> Is it better compiling on windows if the target platform is windows ? I need to compile some libs, not actualy final compiled exe [04:53:02 CEST] <Atlenohen> the libs then get put in another project and compilation later [04:58:30 CEST] <CarlFK> Atlenohen: it shouldn't matter. the complier you run needs to run on the OS it was build for. [04:59:17 CEST] <CarlFK> as long as you get all the input files where it wants them, it should produce a legit output [04:59:42 CEST] <CarlFK> getting all the files - that may be cumbersome [05:05:12 CEST] <Atlenohen> CarlFK: first time attempting this http://mingw-w64.org/doku.php/download [05:05:29 CEST] <Atlenohen> the multiple platforms is already confusing [05:05:51 CEST] <Atlenohen> MinGW for windows .... then why are all other platforms doing on the main DL page [05:06:25 CEST] <furq> because it builds binaries for windows [05:06:38 CEST] <furq> it'll run more or less anywhere gcc does [05:09:05 CEST] <Atlenohen> oh [05:09:32 CEST] <Atlenohen> I thought it's about "where the environment can be setup" as opposed to what the target compilation result is [05:09:39 CEST] <Atlenohen> so it's the other way around? [05:09:52 CEST] <Atlenohen> unless is labeled "cross compiler"? [05:22:41 CEST] <Atlenohen> meh i'll just poke something and see if it works [05:26:48 CEST] <Atlenohen> great trac.ffmpeg.org appears to be down or what [05:30:06 CEST] <Atlenohen> okay i got the all-in-one installer from surceforge as I have no idea what to download [05:30:37 CEST] <Atlenohen> funny URLs the project is w64, then it's "targeting 32bit" and then the "64bit version" again mingw-w64/files/Toolchains targetting Win32/Personal Builds/mingw-builds/installer/mingw-w64-install.exe [05:41:30 CEST] <Atlenohen> SEH or SJLJ ? [05:57:02 CEST] <damdai> does ffmpeg support making 320x240 video to 640x480 video ? [05:57:39 CEST] <CarlFK> damdai: yes [05:57:58 CEST] <damdai> carlfk okay, how is that possible though [05:58:32 CEST] <damdai> that means extra 320x240 pixels comes from nothing [05:58:41 CEST] <damdai> that means extra 320x240 pixels must appear from nothing [06:00:06 CEST] <CarlFK> what are the names of your input and output files? [06:04:01 CEST] <CarlFK> ffmpeg -i in.mpg -s 640x480 out.mpg [06:05:14 CEST] <Atlenohen> there is no MSYS in MINGW installation [06:05:26 CEST] <Atlenohen> ffmpeg docs are seriously outdated, links don't work [06:05:43 CEST] <Atlenohen> eh [06:06:10 CEST] <Atlenohen> I'm done bothering with this for today ... which'll trun into this week, this month :p [06:21:57 CEST] <bray90820> is there a way to concatenate VOB files with ffmpeg? [06:22:22 CEST] <damdai> what do you mean by "concatenate [06:23:49 CEST] <bray90820> Combine 4 VOB files into one [06:25:02 CEST] <damdai> yes ffmepg supports that [06:48:05 CEST] <bray90820> damdai: what code would I use? [06:48:18 CEST] <damdai> you mean command? [06:48:43 CEST] <bray90820> Yes my bad [06:49:29 CEST] <damdai> ffmpeg -y f concat -i list.txt -map 0:v -map 0:a:2 -map 1:v -map 1:a:2 -map 2:v -map 2:a:2 -map 3:v -map 3:a:2 -map 4:v -map 4:a:2 -c copy -f mpegts joined.mpeg [06:50:16 CEST] <bray90820> That would do a passthrough of the video and audio right? [06:51:10 CEST] <damdai> actually use this: [06:51:12 CEST] <damdai> ffmpeg -i input1.mp4 -c copy -bsf:v h264_mp4toannexb -f mpegts intermediate1.ts [06:51:12 CEST] <damdai> ffmpeg -i input2.mp4 -c copy -bsf:v h264_mp4toannexb -f mpegts intermediate2.ts [06:51:12 CEST] <damdai> ffmpeg -i "concat:intermediate1.ts|intermediate2.ts" -c copy -bsf:a aac_adtstoasc output.mp4 [06:51:22 CEST] <damdai> but instead of .mp4 use .vob [06:53:14 CEST] <bray90820> Assuming those three should be on one line right? [06:53:25 CEST] <damdai> actually try this first: ffmpeg -i "concat:input1.ts|input2.ts|input3.ts" -c copy output.ts [06:53:33 CEST] <damdai> but instead of .ts use .vob [06:54:10 CEST] <damdai> let me know if that worked [06:56:06 CEST] <bray90820> It seems to be working [06:56:22 CEST] <bray90820> I'll let you know in a minute tho [06:56:22 CEST] <damdai> check the output.vob to make sure [06:56:34 CEST] <damdai> play the output.vob to make sure [06:57:01 CEST] <damdai> there is a chance it can create corrupted/unplayable file [06:57:19 CEST] <bray90820> I get a lot of these errors idk if it's a problem tho [06:57:19 CEST] <bray90820> [svcd @ 0x7ff517828000] buffer underflow st=0 bufi=79900 size=81218 [06:57:38 CEST] <damdai> i am not familar with that error message [06:58:23 CEST] <damdai> are you able to play individual .vob files fine? [06:58:24 CEST] <bray90820> Ok [06:58:40 CEST] <bray90820> Well the Vob file seems to play correctly [06:59:01 CEST] <damdai> you mean output.vob ? [06:59:05 CEST] <bray90820> Yes [06:59:13 CEST] <damdai> make sure video/audio sync match [06:59:38 CEST] <damdai> sometimes it can create non sync [07:00:26 CEST] <bray90820> Yes it's in sync [07:01:52 CEST] <damdai> if you joined 2 5:00 min video playback at 4:57-5:05 to check it joined smoothly [07:03:07 CEST] <bray90820> Yes it's good [07:04:52 CEST] <bray90820> Is that all I need to check [07:05:08 CEST] <damdai> i guess [07:06:56 CEST] <bray90820> Woot [07:06:59 CEST] <bray90820> Thanks for the help [10:21:56 CEST] <jya> is there a way with a h264/mp4 video that contains no colorspace information in the SPS NAL (colour_description_present_flag is false), to rework it quickly to say it's BT601 ? [10:23:14 CEST] <furq> jya: https://www.ffmpeg.org/ffmpeg-bitstream-filters.html#h264_005fmetadata [10:23:57 CEST] <jya> furq: do you know how you call this ? [10:28:10 CEST] <furq> -i foo.mkv -bsf:v h264_metadata=colour_primaries=6:transfer_characteristics=6:matrix_coefficients=6 -map 0 -c copy bar.mkv [10:29:49 CEST] <jya> awesome thank you [10:30:03 CEST] <furq> 6 is smpte170m which is correct for ntsc iirc [10:30:10 CEST] <furq> i think you'd want 5 (bt470bg) for pal [10:30:19 CEST] <jya> smpte170m is what I want [10:30:38 CEST] <jya> we don't differentiate bt470bg from smpte170m anyway [11:16:53 CEST] <JsbBpk> Hello ! [11:17:22 CEST] <JsbBpk> I am facing a problem with http version and ffplay. Even though http version is 1.1, connection header is still "close" not "keep-alive" [11:19:18 CEST] <JsbBpk> ffplay version N-93544-g0a347ff422 Copyright (c) 2003-2019 the FFmpeg developers built with gcc 8.2.1 (GCC) 20190212 [11:22:18 CEST] <JsbBpk> It looks like this bug : https://trac.ffmpeg.org/ticket/5845 (fixed 3 years ago) [11:51:24 CEST] <DHE> based on the code it looks like there is an onus on the user to explicitly set the header themselves and ffmpeg should roll with it [13:39:36 CEST] <Atlenohen> Anyone around, trying to put another go at building ffmpeg on windows, for windows [13:39:48 CEST] <Atlenohen> don't need any other target platforms just win64 [13:40:20 CEST] <BtbN> The easiest way to build for Windows is to install Linux, or use WSL, and cross compile it. [13:53:53 CEST] <Mavrik> Won't WSL give you linux binaries? [13:54:21 CEST] <Mavrik> As opposed to just installing Mingw-64? [13:58:48 CEST] <furq> you can install mingw in wsl [13:58:59 CEST] <BtbN> Well, I said cross compile for a reason [13:59:41 CEST] <furq> i should really get a wsl toolchain set up [14:00:02 CEST] <BtbN> I'm waiting for the 1903 update to land so I can finally replace Cygwin with WSL [14:00:05 CEST] <furq> the only distro i know of with mingw packages or ports is arch and for some awful reason they decided to move mingw into the aur [14:00:27 CEST] <furq> hell yeah i want to compile gcc myself [14:00:28 CEST] <BtbN> Hm? Ubuntu and Debian both have mingw64 packaged just fine [14:00:39 CEST] <furq> i mean libraries packaged for mingw [14:01:05 CEST] <BtbN> You can use mxe if you need something more complex [14:01:45 CEST] <furq> arch has mingw pkgbuilds for pretty much all the ffmpeg deps i want [14:01:53 CEST] <furq> so i mistakenly thought that would make it easier [14:01:58 CEST] <furq> but i forgot that it also involves using arch [14:03:57 CEST] <Mavrik> What does using WSL give you though? [14:04:02 CEST] <BtbN> Ubuntu [14:04:17 CEST] <BtbN> But people have ported pretty much all common distros to it [14:04:25 CEST] <furq> something theoretically less likely to kill itself than msys2 is [14:05:39 CEST] <BtbN> 1903 WSL will finally allow access to WSL files from regular applications [14:06:05 CEST] <furq> i couldn't help but notice that configure is still a lot slower than it is in a vm [14:06:11 CEST] <furq> so i guess the fork emulation still isn't up to par [14:06:22 CEST] <furq> it is way faster than msys/cygwin fork though [14:06:23 CEST] <BtbN> There is no fork emulation [14:06:38 CEST] <BtbN> Windows implemented fork in their kernel long ago, both Cygwin and WSL use that now [14:06:43 CEST] <BtbN> MSYS does not however [14:07:25 CEST] <BtbN> configure on Windows is primarily slow because of I/O [14:13:19 CEST] <Atlenohen> Well I don't have a HDD spare to installa linux to, I wanted to do it on Mint but it's not looking like a fast thing I could do on the live boot [14:13:49 CEST] <Atlenohen> I'm also in the middle of HDD/Data archial/sorting/maintennace, [14:13:57 CEST] <BtbN> Just use WSL then [14:14:12 CEST] <Atlenohen> Perhaps running linux in virtualbox or so? [14:15:52 CEST] <BtbN> If you just want to compile, there is no reason to deal with that. WSL does that just fine. [14:28:13 CEST] <JsbBpk> Hello again ! Thank you for your reply about http headers. It worked [14:32:37 CEST] <JsbBpk> However, http_version option seems not working in version available on your website [14:33:09 CEST] <JsbBpk> ffplay version N-93544-g0a347ff422 Copyright (c) 2003-2019 the FFmpeg developers built with gcc 8.2.1 (GCC) 20190212 [14:33:59 CEST] <JsbBpk> For instance : ffplay.exe -http_version "1.0" Error : Error setting option http_version to value 1.0 [14:34:12 CEST] <JsbBpk> same without quotes [14:38:56 CEST] <DHE> I don't host ffmpeg builds, that's for sure... [14:40:29 CEST] <JsbBpk> I just tested the behavior with keep-alive header. ffplay keeps closing the socket [14:44:20 CEST] <Hackerpcs> on hydrogenaud.io wiki it says that aoTuV vorbis is the recommended encoder of vorbis, does libvorbis include its improvements? I'm mostly interested in Q 7-8 [14:46:09 CEST] <furq> didn't all the aotuv stuff get merged back into mainline eventually [14:46:29 CEST] <furq> also you should be using opus instead of vorbis if your device supports it [14:47:08 CEST] <Hackerpcs> opus cuts off high frequencies [14:47:29 CEST] <JEEB> so do all audio encoders that are lossy [14:47:40 CEST] <JEEB> it might be configurable depending on the encoder [14:47:41 CEST] <Hackerpcs> Don't know so that's why I ask about libvorbis [14:48:00 CEST] <Hackerpcs> fdk aac (thanks furq) on VBR 5 doesn't, vorbis too on Q 8 [14:48:13 CEST] <furq> lame v0 doesn't either [14:48:17 CEST] <Hackerpcs> it does [14:48:23 CEST] <Hackerpcs> ~20k [14:48:25 CEST] <JEEB> that's surprising, I'd have thought it still does cut around 21-22kHz [14:48:26 CEST] <furq> it hasn't for quite a while [14:48:38 CEST] <furq> with that said 20khz is fine [14:50:16 CEST] <furq> https://0x0.st/slrd.png [14:50:18 CEST] <furq> that's 3.100 v0 [14:50:26 CEST] <furq> weirdly 320 still cuts off at 20khz [14:50:53 CEST] <furq> no idea what the rationale for that is but it's cbr mp3 in 2019 so who cares [14:51:14 CEST] <Atlenohen> btbn: but since the compilation guides are outdated what does that help me unless someone is guiding me through the process it'll take me forever, but oh wll [14:51:28 CEST] <Hackerpcs> true I was wrong, V0 doesn't cut [14:52:16 CEST] <Atlenohen> so WSL is different thatn using virtualbox [14:52:35 CEST] <Atlenohen> I'd figure VM is a less intrusive thing than setting up WSL env [14:52:50 CEST] <Atlenohen> Don't want to mess my Win10 up where I have other env setup [14:53:06 CEST] <Hackerpcs> which platform Atlenohen? on Win10 https://github.com/jb-alvarado/media-autobuild_suite works nicely, compiled this morning [14:53:56 CEST] <Hackerpcs> Win10 LTSC 64 here [14:57:08 CEST] <furq> Hackerpcs: anyway, i don't think the libvorbis api changed recently, so you could presumably just build ffmpeg with an aotuv libvorbis [14:57:21 CEST] <furq> i would still just use opus though [14:58:33 CEST] <furq> also i was technically right about the changes being merged back into mainline except it was in 2004 [14:58:42 CEST] <furq> so only about 10 years out [15:06:34 CEST] <Atlenohen> Hackerpcs: LTSB, not LTSC yet [15:06:58 CEST] <Hackerpcs> it doesn't matter as you don't use WSL with the above [15:07:07 CEST] <Hackerpcs> I don't have WSL at all, I use cygwin [15:07:17 CEST] <Atlenohen> Yeah, good then [15:08:53 CEST] <Atlenohen> By the way I'm not sure if this is called compiling or not, but I have to make libraries as it was before, i still have the old "compiled" ones [15:09:36 CEST] <Atlenohen> they're just .lib files as in avcodec.lib and the file starts with the term !<arch> [15:10:33 CEST] <BtbN> How is installing a full VM environmentr with kernel mode drivers and everything less intruse than installing Ubuntu from the Windows store which then runs pretty much natively? oO [15:11:35 CEST] <BtbN> and compiling ffmpeg boils down to running configure with the options you desire, and then make [15:12:33 CEST] <Atlenohen> btbn: oh sorry, the offices still use LTSB from 2016 and Windows Store is not allowed, I'm not sure if WSL goes that far back, among many other things, long story but it's company policy [15:13:14 CEST] <BtbN> you want the latest version for WSL [15:13:20 CEST] <BtbN> it gets steadily improved [15:14:47 CEST] <Hackerpcs> https://superuser.com/a/1369767 "Windows 10 LTSB 2016 is build 14393, and you need at least build 16215 to run WSL" [15:15:29 CEST] <BtbN> didn't they end support for 1709 recently? A build from 2016 doesn't seem like the best idea. [15:15:30 CEST] <Hackerpcs> LTSC is 17763 [15:15:51 CEST] <Hackerpcs> LTSB is 10 year supported like LTSC [15:16:09 CEST] <Hackerpcs> it's Win10 enterprise [15:17:01 CEST] <Hackerpcs> Atlenohen: do you need to pay to upgrade to LTSC from LTSB or it's free? [15:17:42 CEST] <Hackerpcs> basically LTSx is similar to windows 7 [15:17:51 CEST] <Hackerpcs> in support manner [15:22:05 CEST] <Atlenohen> Not sure about that stuff I wasn't setting any of the OS stuff up around here currently. [15:23:27 CEST] <Atlenohen> What's confusing is there's so many terms and it's like a sea of version,subversion,editions,packs,combinations,platforms, msys, msys64,msys2, msys+gcc, mingw+msys, mingw+msys1+msys2 ... just oh [15:23:55 CEST] <Hackerpcs> why do you want to compile and don't grab a zanoe build? [15:24:35 CEST] <Atlenohen> One of the guides said I have to go into msys inside mingw, I install mingw and there is no msys inside it, then double msys1 and msys2 ... [15:25:49 CEST] <Atlenohen> hackerpcs: that's because zeranoe does not provide proper .lib files, he provides only placeholders for delayed DLL loading, not for integration in another project for final compilation later. [15:26:05 CEST] <Hackerpcs> oh ok [15:26:46 CEST] <Atlenohen> And, we don't need full blown FFMPEG, can disable most stuff and only need a few codecs/formats [15:27:09 CEST] <BtbN> He builds with gcc [15:27:13 CEST] <BtbN> There are no .lib files [15:28:03 CEST] <BtbN> but looking at his build... there are .def, .lib and .dll.a files in there. So he added compatiblity for everything one can thing of. [15:29:07 CEST] <BtbN> Of course those are for shared linking the .dll. He intentionally does not provide static libs, because you cannot use those anyway in most cases due to GPL [15:29:22 CEST] <Atlenohen> Yes, they are in the -dev package, to be used with compatible .dlls [15:30:21 CEST] <Atlenohen> Oh so it's a license thing? [15:30:50 CEST] <BtbN> You can only statically link GPL libs into projects with a GPL compatible free license [15:31:01 CEST] <BtbN> If he'd offer static libs, most people would abuse them [15:33:26 CEST] <Atlenohen> Oh, I see, well then I would recommend the proper change to the master project to change it over to DLLs, however I don't believe this was released earlier, it supposed to be an internal helper utility. [15:33:47 CEST] <Atlenohen> Would that be a problem either way? [15:35:17 CEST] <furq> honestly cross-compiling is easy if you don't need any external libraries [15:35:23 CEST] <furq> the guides on the wiki are massively overengineered for that [15:36:41 CEST] <furq> nowadays with debian/ubuntu you can just install mingw-w64 and then ./configure --cross-prefix=x86_64-w64-mingw32- --target-os=mingw32 [15:42:34 CEST] <Hackerpcs> https://images2.imgbox.com/56/2d/kA8des51_o.png -- flac vs opus vs vorbis vs fdk aac vs lame, roughly same sizes. fdkaac seems the best and I can't hear any audible difference in any of them (AKG K240, Realtek mobo soundcard, no amp) [15:43:38 CEST] <furq> you won't hear any difference at 256kbps [15:44:01 CEST] <Hackerpcs> does opus have any alt setting that may not cut off? [15:44:14 CEST] <furq> there's -cutoff but i think it clamps at 20khz [15:44:29 CEST] <Hackerpcs> ah true, forgot the cutoff [15:44:39 CEST] <Hackerpcs> yes there is a hard limit at 20k [15:45:13 CEST] <Hackerpcs> no scrap that, that's fdkaac [15:45:59 CEST] <Hackerpcs> no that's correct actually "Cutoff frequency must be exactly one of: 4000, 6000, 8000, 12000 or 20000.", it just doesn't fail like fdkaac [15:49:25 CEST] <Hackerpcs> but there's no difference with -cutoff 20000, it defaults to that "Invalid frequency cutoff: 24000. Using default maximum bandwidth." [15:50:18 CEST] <Hackerpcs> sorry for the spam :P [15:52:16 CEST] <Atlenohen> Okay, I checked with mgmt, the utility was released as free, for fixing in some cases, can update it with proper GPL and include source so it shouldn't be a problem [15:53:43 CEST] <Atlenohen> Hackerpcs: I'll give this script a shot, I might want to know how to build ffmpeg for me personally for anything that may come up in future anyway, but does the script support static libraries out of the box or would I need to modify the install script? [15:54:04 CEST] <Atlenohen> It's asking me how would I want to build FFMPEG, non-free, GLPv3, etc [15:54:15 CEST] <Atlenohen> Or I can set all those things later? [15:55:06 CEST] <Hackerpcs> you set the settings to customize what you want to have available. I compiled to use the fdkaac which isn't available as a binary because of licensing [15:55:35 CEST] <Hackerpcs> unless you want something specific like that, for personal use zeranoe builds are fine [16:00:30 CEST] <Atlenohen> Hackerpcs: I said, zeranoe doesn't do static libraries, I did some calls and it's possible to go this route as this is a small free utility for internal and some customer maintenance use which can be updated with proper GPL/source, I wouldn't want to mess with changing the master project to do DLLs since I don't manage the whole thing, besides I decided it's a good opportunity to learn how to build things manually for me personally [16:00:30 CEST] <Atlenohen> as a bonus, might come hand in future elesewhere. [16:01:30 CEST] <Hackerpcs> I was talking about personal use in your last message, I don't know about the project situation/needs [16:02:45 CEST] <Atlenohen> Hackerpcs: You are misunderstanding, I am not personally using this right now, I was talking about the personal experience of setting up a build environment and building from source, the experience I would get from this it may help me in future unrelated cases. [16:03:28 CEST] <Atlenohen> So I prefer this over DLLs right now, I just explained one of the reasons. [16:04:21 CEST] <Atlenohen> So I'm assuming in order to build static-library I probably need to turn some knobs and switches within the build environment, or maybe they are automatically generated by default? [16:05:00 CEST] <Hackerpcs> It's pretty noob-proof (like me), you just select static and it builds ffmpeg.exe, ffprobe, etc and that's all you need. I just moved the three exes to my C:\tools\bin folder plus h264 and it works. During the script you select what you want and it's done automatically, you don't mess with msys2 environment [16:05:02 CEST] <BtbN> Building static libs is the default. [16:05:28 CEST] <Atlenohen> BtbN: Thanks. [16:06:16 CEST] <Atlenohen> BtbN: Well, https://github.com/jb-alvarado/media-autobuild_suite it could be different here but, only one way to find out is just try it :) [16:06:33 CEST] <BtbN> that's something very third party and not supported here [16:08:29 CEST] <Atlenohen> Yeah, that's why I'm asking hackerpcs: who linkes to this, to confirm whether that thing is setup to build most of the things or only .exe ? [16:11:22 CEST] <Hackerpcs> Atlenohen: https://pastebin.com/dq4u2ddq [16:12:23 CEST] <rcabrera> Hello, I am parsing this args with avfilter_graph and creating a filter graph, however even I get the frames from the buffersink the filter doesn't seem to be applied. [16:12:49 CEST] <rcabrera> https://pastebin.com/LATvky15 [16:13:19 CEST] <rcabrera> Any idea of why this could be happening? [16:14:09 CEST] <rcabrera> The image should be flipped but instead I see the frame as if no filters were applied [16:14:44 CEST] <Hackerpcs> the whole local folder, plus my build options https://pastebin.com/V2KHk6Jb [16:50:54 CEST] <Improvotter> Is it possible to tell ffmpeg to use an intermediary file and copy it to its destination once the task is done without doing `ffmpeg ... && mv in out`? [16:52:26 CEST] <DHE> pretty sure the answer is No [16:52:45 CEST] <Improvotter> DHE: alright, I asked just in case. Thank you. [18:07:47 CEST] <zerodefect> I have a simplish code example (https://pastebin.com/BZzqGZtB) which uses the C-API in libswscale to convert a set of buffers from 720p @ YUV420P to 720p @ YUV422P. When I use the electric fence library (libefence.so) with LD_PRELOAD, a segfault is reported. I'm allocating/sizing the buffers myself. Now when I use an AVFrame and allocate a buffer using the corresponding API, it does not [18:07:47 CEST] <zerodefect> crash. [18:29:58 CEST] <zerodefect> http://ffmpeg.org/doxygen/trunk/frame_8c_source.html#l00211 - I think I've figured out my problem. It appears that the height must be padded to 32 lines (if not evently divisble by 32). [18:36:56 CEST] <kepstin> zerodefect: yeah, some of the code in ffmpeg overreads past the ends of the frame, so that special handling isn't required for boundary conditions when using vector instructions. (libswscale in particular requires this, iirc) I thought that there were some notes about this in some of the headers. [18:39:40 CEST] <DHE> the AVFrame method involves calling av_frame_get_buffer which specifically asks for a padding value [18:40:50 CEST] <kepstin> yeah, the get_video_buffer function in that link^ is what av_frame_get_buffer ends up calling. It uses a default padding of 32 if you didn't pass a padding (used 0) [18:42:08 CEST] <kepstin> looks like you can call the av_cpu_max_align() function instead of hardcoding a value if you prefer [19:06:21 CEST] <Atlenohen> hey guys does this line still hold true? [19:06:22 CEST] <Atlenohen> Then run the mingw32_shell.bat or mingw64_shell.bat command in the MSYS2 installation home. Be careful not to run the MSYS2 Shell as this will result in FFmpeg's configure saying building an MSYS binary is not recommended and exiting. [19:26:30 CEST] <zerodefect> Thanks @DHE and @kepstin :) [20:36:30 CEST] <mauz555> hello multimedia gurus [20:37:24 CEST] <mauz555> I'm trying to stream audio microphone speech to an local nginx rtmp server and consume on another lan-connected computer [20:37:35 CEST] <mauz555> like this `ffmpeg -re -f avfoundation -ac 1 -i ":0" -acodec pcm_s16le -ab 16k -ac 1 -f flv -rtmp_app speech -rtmp_playpath test rtmp://127.0.0.1:1935/` [20:38:16 CEST] <mauz555> I can't hear anything on the consumer side (VLC or rtmpdump) [21:07:18 CEST] <Atlenohen> From the what I figured this gcc thing has a load of ports/forks whatever, the FFMPEG guide says "i could install gcc in msys and skip above (pacman) steps" as one user puts it's "it's quite clear" to him, that's rich, I think i have a word for it, excuse me, a clusterfuck of namings https://superuser.com/questions/996332/what-is-the-difference-between-the-d… [21:07:44 CEST] <Atlenohen> So if gcc isn't made for windows, why would one install "gcc" [21:08:17 CEST] <Atlenohen> and msys is like gcc port anyway or what? .. sorry cygwin fork [21:08:46 CEST] <Atlenohen> so why would I need a cygwin fork(which is a gcc port again) if I then install the base gcc inside msys2 [21:20:51 CEST] <Atlenohen> there's no usr/local/bin in the msys64 root directory or in mingw64 [21:21:07 CEST] <Atlenohen> okay maybe it gets created later, i'll put it in just bin [22:50:29 CEST] <cptnhmr42> Hi! I'm using ffmpeg to convert an rtmp stream to an mpeg dash stream (using the -f dash flag). I want to keep the source audio and video and add an additional encoded video stream. The issue I'm having is that audio drifts over time. Here is the command I'm running https://pastebin.com/7krDpGsv [22:52:11 CEST] <cptnhmr42> How can I keep all 3 streams in sync? [23:45:19 CEST] <phisch> i have a short bash script that runs ffmpeg to record a part of the screen, when hitting ctrl+c (sigint) a trap catches it, sends a sigint to the ffmpeg background process and continues with other stuff. this works when i run the script in one terminal, and send the sigint to the script from another terminal. but when hitting ctrl+c, ffmpeg just in [23:45:19 CEST] <phisch> stantly dies horribly [23:45:27 CEST] <phisch> this is the script: https://pastebin.com/HjsrpxsB [23:46:54 CEST] <phisch> it feels like when i hit ctrl+c ffmpeg somehow receives 2 sigints, the one that i send it, and a ghost one, but i am wondering where the ghost one comes from [23:47:02 CEST] <phisch> (if this is the case at all) [23:53:17 CEST] <kepstin> phisch: your interactive shell might be sending the signal to the entire process group rather than just the foreground task. [00:00:00 CEST] --- Thu Apr 11 2019

1 0