January 2019 - Ffmpeg-devel-irc

ffmpeg-devel.log.20190115
by burek 16 Jan '19

16 Jan '19

[00:28:26 CET] <cone-194> ffmpeg 03Carl Eugen Hoyos 07master:301cee61fa61: ffmpeg_opt: Print a warning if more than one -vf/-af option was specified. [01:19:13 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:dfa3a5ac6318: avcodec/truemotion2: fix integer overflows in tm2_low_chroma() [01:19:14 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:f3400e731a66: avcodec/truemotion2rt: Fix rounding in input size check [01:19:15 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:aa5190d54adb: avcodec/msmpeg4dec: Skip frame if its smaller than 1/8 of the minimal size [01:19:16 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:4ff4fd41791c: avcodec/wmv2dec: Skip I frame if its smaller than 1/8 of the minimal size [01:19:17 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:3c2207b10f0e: avcodec/msvideo1: Check for too small dimensions [01:19:18 CET] <cone-194> ffmpeg 03chcunningham 07release/3.2:418f13261ffe: lavf/mov: ensure only one tkhd per trak [01:19:19 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:9925adcd6847: avformat/nutenc: Document trailer index assert better [01:19:20 CET] <cone-194> ffmpeg 03chcunningham 07release/3.2:490a5253ca89: lavf/id3v2: fail read_apic on EOF reading mimetype [01:19:21 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:72536017a7c3: avcodec/mjpegdec: Fix indention of ljpeg_decode_yuv_scan() [01:19:22 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:d9010b1d8f08: avformat/mpegts: Fix side data type for stream id [01:19:23 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:bcc42f192342: avcodec/avcodec: Document the data type for AV_PKT_DATA_MPEGTS_STREAM_ID [01:19:24 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:b96292c6d348: avcodec/rpza: Move frame allocation to a later point [01:19:25 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:a48c69a04e28: avcodec/rpza: Check that there is enough data for all the blocks [01:19:26 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:bcf15577363b: postproc/postprocess_template: Avoid using %4 for the threshold compare [01:19:27 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:5a82f570a462: postproc/postprocess_template: remove FF_REG_sp from clobber list [01:19:28 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:6e5238d55f2e: avcodec/fic: Fail on invalid slice size/off [01:19:29 CET] <cone-194> ffmpeg 03gxw 07release/3.2:0f9cb4e726fc: avcodec/mips: Fix failed case: hevc-conformance-AMP_A_Samsung_* when enable msa [01:19:30 CET] <cone-194> ffmpeg 03David Bryant 07release/3.2:0eaff670a774: avformat/wvdec: detect and error out on WavPack DSD files [01:19:31 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:a27b49579d99: avcodec/mjpegbdec: Fix some misplaced {} and spaces [01:19:32 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:aae57535cae3: avcodec/4xm: Fix returned error codes [01:19:33 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:9f92a1d02028: avcodec/exr: set layer_match in all branches [01:19:34 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:f4a9455e03a6: avcodec/h264_slice: Fix integer overflow in implicit_weight_table() [01:19:35 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:53319cbe9787: avcodec/tests/rangecoder: initialize array to avoid valgrind warning [01:19:36 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:3389d479acef: avcodec/diracdec: Check component quant [01:19:37 CET] <cone-194> ffmpeg 03Michael Niedermayer 07release/3.2:05ed56286269: Update for 3.2.13 [01:21:22 CET] <jamrial> michaelni: do we also update the year in point releases? if so, you could backport 3209d7b393 [01:22:05 CET] <michaelni> Luigi12, just backported a few more fixes, will make 3.2.13 tomorrow assuming noone reports any issues in it to me and assuming nothing unexpected happens [01:22:26 CET] <michaelni> jamrial, we should update the year thanks, i didnt realize it wasnt [01:22:37 CET] <jamrial> no prob [01:27:26 CET] <Luigi12> michaelni: thanks! [01:40:38 CET] <cone-194> ffmpeg 03James Almer 07release/3.2:a97ea53ad96e: configure: bump year [09:10:07 CET] <JEEB> wee, got actual subtitles to decode :) now to stick the styling parts in there [11:21:52 CET] <cone-768> ffmpeg 03Paul B Mahol 07master:894cbcd83b89: avcodec: add HCOM decoder [11:21:52 CET] <cone-768> ffmpeg 03Paul B Mahol 07master:268d1466498b: avformat: add HCOM demuxer [11:24:50 CET] <atomnuker1> durandal_1707: I told you to get rid of the single line brackets [11:24:54 CET] <atomnuker1> we're not doing lisp here [11:25:50 CET] <durandal_1707> atomnuker1: i completely forgot [11:27:01 CET] <atomnuker1> fix it. [11:28:43 CET] <durandal_1707> yes, mum [11:37:40 CET] <cone-768> ffmpeg 03Paul B Mahol 07master:95a27a8846ce: avcodec/hcom: get rid of single line brackets [11:55:11 CET] <kurosu> pross: ok, my point was (I haven't checked) that if code becomes dead, maybe a patch to remove it? [11:55:37 CET] <kurosu> also, vp3dsp, mmx(ext)... [13:12:11 CET] <cone-768> ffmpeg 03Paul B Mahol 07n3.2.13:HEAD: avcodec/hcom: get rid of single line brackets [13:14:00 CET] <durandal_1707> wtf? [13:14:18 CET] <nevcairiel> it shows the latest commit again when someone pushes a tag [13:14:22 CET] <nevcairiel> the bot is a bit silly that way [13:15:50 CET] <JEEB> at least it marks it with the nTAG [13:15:57 CET] <JEEB> as opposed to master or branch [22:19:07 CET] <JEEB> durandal_1707: can you check if the valgrind warning in hcom_probe is valid? apparently there's now an invalid read of size 4 13 bytes after a block :) . [22:19:21 CET] <JEEB> http://up-cat.net/p/2194f4fb [00:00:00 CET] --- Wed Jan 16 2019

1 0

ffmpeg.log.20190115
by burek 16 Jan '19

16 Jan '19

[07:22:32 CET] <avi_m> Hello, I have some http input stream which the server recreates each 17~ seconds, meaning that in order to play it one would turn on "replay" in his video player and open the strea, what i'm trying to do is to generate m3u8 playlist that will buffer the video for me. I was trying to use this command - https://pastebin.com/XCkZNtq9 . with infinte list of the same link but it keep generating ts files for only first http stream [07:22:38 CET] <avi_m> any idea how to fix it ? [07:27:20 CET] <avi_m> ffmpeg output - https://pastebin.com/3gfUKxF8 [09:11:50 CET] <th3_v0ice> How does FFmpeg handle videos that have interlaced and progressive frames? [09:12:00 CET] <JEEB> AVFrames will have the coding mode [09:12:08 CET] <JEEB> and I think the field order [09:12:19 CET] <JEEB> with the *content* you will have to actually look (TM) [09:30:55 CET] <FishPencil> How do I convert an RGB png file to a raw YUV444P file and preserve the full range? [09:32:04 CET] <th3_v0ice> So does it simply pass everything in to some of the deinterlace filters like bwdif, yadif, or it looks at the coding modes and according to that uses or not the filter. I am interested in sequences that have mixed interlaced and progressive frames. [09:32:10 CET] <FishPencil> I tried ffmpeg -i i.png -pix_fmt yuv444p -vf setrange=full -f rawvideo i.yuv444p [09:32:23 CET] <furq> FishPencil: yuvj444p [09:33:39 CET] <FishPencil> furq: What is the j? [09:33:55 CET] <furq> jpeg/pc/full range [09:34:26 CET] <FishPencil> Oh nice [09:34:31 CET] <FishPencil> That looks correct [09:34:50 CET] <FishPencil> I see there's also an "a"? [09:34:56 CET] <furq> alpha [09:35:06 CET] <FishPencil> Ah [09:36:29 CET] <furq> th3_v0ice: you can set yadif etc to only deinterlace frames flagged as interlaced [09:38:12 CET] <furq> there's also the idet filter if the video isn't flagged correctly [09:38:27 CET] <th3_v0ice> furq: I set bwdif to do exactly that, but now my audio and video are not in sync. [09:38:37 CET] <furq> are you using send_field mode [09:39:02 CET] <furq> you should probably not do that [09:39:03 CET] <th3_v0ice> bwdif=0:-1:1, I am using API just for reference. [09:39:23 CET] <furq> no idea then [11:56:57 CET] <th3_v0ice> Is there a way to force bwdif filter not to touch PTS info of non interlaced frames? [12:03:13 CET] <durandal_1707> nope [12:05:56 CET] <JEEB> yea the filter itself doesn't touch things it seems. it just sets the frame rate for the link [12:06:09 CET] <JEEB> unless that code is moved to some common place [12:06:14 CET] <JEEB> instead of being vf_bwdif [12:06:31 CET] <JEEB> I would guess deint=interlaced would remove some filtering? [12:06:44 CET] <JEEB> since it would then only touched pictures coded in progressive mode [12:06:48 CET] <JEEB> or well, flagged progressive [12:08:04 CET] <JEEB> ok, it seems to be largely re-using yadif base code regarding that [12:08:07 CET] <JEEB> so the logic should be the same [12:09:01 CET] <th3_v0ice> Where is that source code located? What is the file name? [12:09:18 CET] <JEEB> libavfilter/vf_yadif.c and vf_bwdif.c etc related [12:09:37 CET] <JEEB> libavfilter/yadif_common.c as well [12:10:20 CET] <JEEB> ff_yadif_filter_frame has the deint checks [12:13:01 CET] <th3_v0ice> Ok, thanks [17:05:56 CET] <TheOneRing_m> hi [17:06:13 CET] <TheOneRing_m> I'm trying to build ffmpeg with msvc and lame enabled [17:06:15 CET] <TheOneRing_m> --enable-shared --disable-debug --disable-doc --enable-gpl --enable-version3 --enable-avresample --enable-libmp3lame --toolchain=msvc [17:06:25 CET] <TheOneRing_m> ERROR: libmp3lame >= 3.98.3 not found [17:06:59 CET] <TheOneRing_m> the lame makefile for msvc produces [17:07:02 CET] <TheOneRing_m> https://www.irccloud.com/pastebin/LTxZyu3d/ [18:26:41 CET] <avi_m> Hi, I have http stream which regenerates each 20~ seconds, I try to fetch it and convert to hls (m3u8) in order to buffer it, I use following command - https://pastebin.com/w8furX35 . The problem is ffmpeg only take the file once and does not re-GET it, any idea what i'm doing wrong ? [18:30:29 CET] <eschmidbauer> hi. id like to use ffmpeg to transcode wav -> mp3. so far it works great. just wondering if there is a way to tell ffmpeg to write to a "temp" file (or folder) until the encoding is completed, then move the completed file to the desired output destination [18:32:37 CET] <JEEB> no [18:32:57 CET] <JEEB> you will have to script or code that yourself as a user of ffmpeg.c or the FFmpeg APIs [18:33:45 CET] <eschmidbauer> really? i would think this is a common use-case [18:36:08 CET] <JEEB> well it is something that is outside of the use case IMHO. FFmpeg will write the output somewhere. if you want the file specifically to not be available in the end result, then you write into a temporary file or so, and then rename/move (depending on if you're on the same file system) it to the place you want in the end [18:36:58 CET] <JEEB> I can see an application utilizing the APIs or ffmpeg.c doing this, but I do not think "move after completion" as something that should be in the thing itself as a specifically coded function [18:38:14 CET] <eschmidbauer> really? cuz what if you are "watching" a directory for transcoded files? how could you handle that ? cuz ffmpeg will write them instantly into the directory, the "watcher" has no way of knowing if they are completed or not [18:38:57 CET] <JEEB> what I just said, a user of FFmpeg should do the moving if such requirements are there, not ffmpeg.c [18:39:38 CET] <JEEB> often it's not just that, but also various other rules like file names etc [18:39:48 CET] <JEEB> if you're already doing that on your automation or whatever side [18:39:58 CET] <BtbN> Use your shell to do that [18:40:08 CET] <BtbN> it's nothing more than "&& mv ..." [18:40:22 CET] <JEEB> or batch or python or powershell or whatever [18:40:36 CET] <eschmidbauer> i was hoping to do this all inside a system call from golang [18:40:49 CET] <eschmidbauer> and not have to worry about output or return result [18:41:10 CET] <BtbN> Don't use system(), it's always bad design [18:41:21 CET] <BtbN> (and it's not what you call a system call) [18:41:46 CET] <eschmidbauer> there are no go pkgs that can transcode [18:41:52 CET] <eschmidbauer> so i have to call a system call [18:42:00 CET] <BtbN> But there surely are packages to cleanly invoke processes [18:42:02 CET] <JEEB> eschmidbauer: you already have an app that has your own use cases there. adding things to ffmpeg.c etc just complicates things for no real reason [18:42:20 CET] <JEEB> just mktemp for the file either on the same disk or in general tmpt [18:42:22 CET] <JEEB> *tmp [18:42:34 CET] <eschmidbauer> JEEB: i really disagree with you but it's fine. no point in arguing [18:42:37 CET] <JEEB> then launch, if everything's good, rename/move [18:42:57 CET] <JEEB> eschmidbauer: do note that I'm not against the use case. just the fact that putting that into ffmpeg.c doesn't make much sense [18:43:02 CET] <eschmidbauer> having a "tmp" file is like using a buffer file. it makes complete sense if implemented with a flag [18:43:25 CET] <BtbN> It's trivial to do with any shell or whatever you use. No point in adding it. [18:43:28 CET] <JEEB> ^ [18:43:37 CET] <DHE> but then you have to specify where/what the buffer file is [18:43:41 CET] <JEEB> it's more complexity to add it into ffmpeg.c than just have people who have their own application logic [18:43:55 CET] <JEEB> also people can expand on that in N different ways [18:43:58 CET] <eschmidbauer> i actually dont give a crap about where/what the buffer file is [18:43:59 CET] <JEEB> also it's not always files etc [18:44:06 CET] <DHE> clearly you do [18:44:08 CET] <eschmidbauer> i just want the final output in a folder [18:44:23 CET] <DHE> <eschmidbauer> really? cuz what if you are "watching" a directory for transcoded files? # then you have a problem with that way [18:44:41 CET] <eschmidbauer> the transcoded files would be the final output [18:44:43 CET] <JEEB> what you now actually mean is that you want it somewhere from where you can rename() [18:44:56 CET] <JEEB> because as soon as you move() you start catching non-final data [18:45:03 CET] <JEEB> in your watching :P [18:45:03 CET] <DHE> and that somewhere will vary. maybe a different extension works, maybe a .hidden file works, maybe another directory works [18:45:18 CET] <JEEB> yes, it's heavily user's use case specific [18:45:41 CET] <eschmidbauer> yea pretty sure other libs have this type of flag. im really surprised ffmpeg doesn't [18:45:46 CET] <eschmidbauer> i'll just go with something else [18:45:53 CET] <JEEB> ok, cool [18:45:59 CET] <BtbN> (the img2 muxer actually does exactly that with a ${filename}.tmp, and it causes issues every now and then) [18:46:23 CET] <eschmidbauer> yea this doc mentions it too [18:46:26 CET] <eschmidbauer> https://ffmpeg.org/ffmpeg-all.html [18:46:30 CET] <eschmidbauer> `temp_file` [18:46:57 CET] <BtbN> That's for HLS [18:47:23 CET] <JEEB> yes, various people implemented their own little use cases in various places. whether that works for you is a whole separate discussion, and I would like to not add to that list since you will always get "one more" [18:47:23 CET] <DHE> which does in fact require atomic updates because users are expected to be downloading the .m3u8 at all times [18:47:59 CET] <BtbN> It doesn't even use it for the m3u8, but for the segment currently being written [18:48:02 CET] <eschmidbauer> BtbN: yes- so apparently HLS use-case fits [18:48:07 CET] <eschmidbauer> idk what HTLS is [18:48:19 CET] <eschmidbauer> but clearly there is need for such a flag there... [18:48:25 CET] <BtbN> It's a thing internal to HLS, not a public feature for generic use [18:48:28 CET] <DHE> literally "HTTP live streaming". being a live-stream protocol rather than a batch job protocol, it has different needs [18:48:44 CET] <BtbN> I really don't get what your issue with two, or even one, extra line of code is [18:48:59 CET] <JEEB> anyways, there are over 9000 things that warp around FFmpeg or related things [18:49:03 CET] <BtbN> ffmpeg ... /tmp/out.mp3 && mv out.mp3 wherever.mp3 [18:49:04 CET] <BtbN> done [18:49:06 CET] <JEEB> I recommend you poke there if you don't want to handle it yourself [18:50:30 CET] <eschmidbauer> what happens if ffmpeg fails there [18:50:45 CET] <BtbN> It fails [18:50:52 CET] <BtbN> You are aware what && does? [18:51:00 CET] <eschmidbauer> i guess problem is, i can't run that from a single system call [18:51:09 CET] <BtbN> It's not a system call. [18:51:17 CET] <BtbN> And don't ever use system(), it's seriously bad. [18:51:19 CET] <JEEB> your whole logic somehow already made things such as the file name [18:51:23 CET] <JEEB> but I digress [18:51:35 CET] <eschmidbauer> what should i use instead of system() in golang? [18:51:38 CET] <JEEB> executing a process and checking nonzero exit code should not be a Hard Thing [18:51:56 CET] <JEEB> https://golang.org/pkg/os/exec/ [18:51:59 CET] <BtbN> No idea about Go, but it _has_ to have something to properly invoke a process, pass arguments as an array, and get the final status code [18:52:01 CET] <eschmidbauer> ah [18:52:01 CET] <JEEB> this should do the trick? [18:52:15 CET] <JEEB> also you can additionally get the piped output if needed [18:52:19 CET] <JEEB> or pipe something yourself [18:52:32 CET] <DHE> system() just calls: sh -c "(your string here)" which is potentially a can of worms if you don't do quoting and escaping properly [18:52:50 CET] <JEEB> yea, APIs that take in an argument *list* generally are what you want [18:52:58 CET] <BtbN> And it has different semantics depending on what sh is [18:53:01 CET] <eschmidbauer> how is that better than system()? [18:53:08 CET] <BtbN> ... [18:53:13 CET] <JEEB> :) [18:53:41 CET] <eschmidbauer> what does exec do differently [18:53:46 CET] <JEEB> if you don't care about making sure the command goes out in the way you think it will, and all you need is the exit code - probably no difference [18:54:08 CET] <JEEB> I of course am expecting system() to also return the exit code [18:54:14 CET] <JEEB> which I didn't check :P [18:54:20 CET] <another> it starts a process. instead of starting a shell with arguments [18:56:34 CET] <eschmidbauer> https://play.golang.org/p/j8zvxQHX54p [18:56:45 CET] <eschmidbauer> throws an error [18:56:50 CET] <JEEB> yes [18:56:57 CET] <JEEB> -i is an argument [18:57:03 CET] <JEEB> the input file name should be the next [18:57:07 CET] <JEEB> not as a single argument [18:57:11 CET] <JEEB> that's the *good* side of such APIs [18:57:19 CET] <eschmidbauer> oh thanks [18:57:21 CET] <JEEB> for example if you have a file name with spaces or anything else that is random [18:57:23 CET] <eschmidbauer> that worked [18:57:37 CET] <JEEB> if you do a shell, you have to make sure you have properly ""'d or otherwise made it lovely [18:57:42 CET] <JEEB> with actual separate arguments [18:57:47 CET] <eschmidbauer> yea i can see how this is better, thanks for the help [18:57:57 CET] <JEEB> cool :) [18:58:49 CET] <JEEB> I think one of the most "what?" moments I've had with python came from them having an API like this, except they also let you pass in a single string which they would then parse as if they were a shell [18:59:00 CET] <JEEB> which kind of... counters the whole idea of a command launching API [18:59:05 CET] <JEEB> at least in my opinion [18:59:34 CET] <JEEB> of course the positive side is that it will not go into an actual shell [18:59:38 CET] <JEEB> but still :P [18:59:56 CET] <eschmidbauer> i still think ffmpeg should have this flag [19:00:09 CET] <eschmidbauer> it's a common use-case and isn't difficult to support [19:00:37 CET] <JEEB> uhh, the problem is - it's not. unless you take a *lot* of decisions that limit things [19:00:51 CET] <JEEB> like for example many things first make a file that starts with a dot in the same dir [19:00:54 CET] <JEEB> or something like that [19:00:59 CET] <JEEB> and then rename() in the end [19:01:13 CET] <JEEB> but then your own logic has to be able to handle that [19:01:18 CET] <JEEB> so it touches *your* logic anyways [19:01:52 CET] <JEEB> or then you have to decide on the temporary file name, in which case we're once again delegated majority of the logic to the user [19:03:31 CET] <JEEB> so yea, since it's so user's use case specific, I'm happy to leave something that can for that user be so simple (because they know their specific use case!) [19:04:20 CET] <JEEB> what FFmpeg should care about is to provide the means to do in and out [00:00:00 CET] --- Wed Jan 16 2019

1 0

ffmpeg-devel.log.20190114
by burek 15 Jan '19

15 Jan '19

[12:15:20 CET] <durandal_1707> atomnuker: will you please answer? [13:40:45 CET] <cone-383> ffmpeg 03Jerome Borsboom 07master:fc6e53b0b662: avcodec/vc1: fix B predictor validity for 4-MV MBs [15:04:21 CET] <kurosu> pross: btw, does you new code kills some other one? eg dsp functions? [18:33:10 CET] <cone-194> ffmpeg 03Rafaël Carré 07master:75ea329b78f4: api-h264-slice-test: fix arguments and help [18:33:10 CET] <cone-194> ffmpeg 03Michael Niedermayer 07master:6e23736aefa8: avcodec/gdv: Optimize and factorize scaling loops [18:33:10 CET] <cone-194> ffmpeg 03Michael Niedermayer 07master:c15972f0af76: avcodec/tests/rangecoder: initialize array to avoid valgrind warning [18:34:11 CET] <durandal_1707> michaelni: who is sponsoring your commits? [18:37:35 CET] <kierank> durandal_1707: the CIA [18:37:55 CET] <durandal_1707> more KGB [21:10:28 CET] <pross> kurosu: yeah, VP4 and VP6 filters are identical so they ought to share code. (VP5 is identical too, but I won't touch that in this round.) [21:34:56 CET] <durandal_1707> atomnuker: should i use cosine distance instead of squared euclidean in anlmdn? [21:40:14 CET] <JEEB> wee http://up-cat.net/p/586a1fe8 [21:40:21 CET] <JEEB> now I just need to make the decoder wrapper [21:48:05 CET] <pross> åí? [21:48:11 CET] <JEEB> yup [21:48:16 CET] <JEEB> MBS broadcasting sample, this one [21:49:04 CET] <JEEB> I hate myself for not enabling the libclang based plugin in my editor though, since modifying the avcodec codec_desc etc made me re-compile all the things [21:49:07 CET] <JEEB> and then I got lazy [21:49:34 CET] <JEEB> and suddenly > I forget to export the profile array > I forgot the = between the array[] and { > I forget the closing ; after } [21:49:36 CET] <durandal_1707> old news [21:49:42 CET] <JEEB> which are all dumb as hell mistakes [21:50:35 CET] <JEEB> well at least I care about this stuff on some level :P [21:50:56 CET] <JEEB> I'm going to have to start reviewing stuff in other projects soon, but for now I'm trying to actually *do something* [21:51:04 CET] <pross> no clang plugin for ed [21:51:22 CET] <durandal_1707> ed? [21:51:38 CET] <JEEB> yea it's fun when your editor screams at you instead of you waiting for full compilation and finding out you did something really dumb [22:12:53 CET] <atomnuker1> durandal_1707: if it works better, though for this use case I think SSE is alright [22:13:20 CET] <BradleyS> every time i see anlmdn i read "animal dn" [22:30:58 CET] <cone-194> ffmpeg 03Carl Eugen Hoyos 07master:5d958f0955fe: lavf/mov: Do not fail hard for more invalid atoms. [22:34:51 CET] <atomnuker1> I read **** microsoft developer network [22:38:50 CET] <BradleyS> :P [23:08:35 CET] Action: Luigi12 was wondering if you could cut another 3.2.x release. MythTV is bundling an older release from that branch. The 3.2.x branch has fixes for CVE-2018-15822 and other security issues committed since 3.2.12 was released. [23:10:17 CET] <Luigi12> although one of my fellow distro developers just told me that CVE commit is in the tarball even though that's not what git shows... [23:12:21 CET] <Luigi12> ahh no he's wrong [23:13:13 CET] <Luigi12> I see michaelni added a bunch of fixes in git on 20181118 but didn't cut a new release [23:17:25 CET] <durandal_1707> Luigi12: ask michaelni directly, he is paid for that [23:17:38 CET] <Luigi12> thanks [23:17:52 CET] <Luigi12> michaelni: just making sure you saw my request for a new 3.2.x release. Thanks! [23:19:12 CET] <kierank> durandal_1707: how much is he paid [23:20:59 CET] <durandal_1707> kierank: that info is top secret, sorry [23:21:41 CET] <kierank> durandal_1707: very important for the cia to "fix" fuzzed files that take time to decode [23:21:42 CET] <kierank> I understand [23:21:44 CET] <kierank> top secret [00:00:00 CET] --- Tue Jan 15 2019

1 0

ffmpeg.log.20190114
by burek 15 Jan '19

15 Jan '19

[00:04:22 CET] <maxrazer> It would be a lot easier if nvenc was enabled by default with ffmpeg on linux. I have to go through some custom compiling instructions. [00:04:39 CET] <maxrazer> I want to use nvenc with obs-studio on debian sid. [00:04:55 CET] <maxrazer> I found this: https://www.maketecheasier.com/nvidias-gpu-assisted-video-encoding-nvenc-wo… [00:06:28 CET] <maxrazer> Actually that may not work with Debian. [00:08:15 CET] <scriptease> thats why i use it with windows [00:08:19 CET] <scriptease> works out of the box [00:09:02 CET] <scriptease> https://developer.nvidia.com/ffmpeg [00:09:06 CET] <scriptease> does that help? [00:14:13 CET] <scriptease> maxrazer [00:14:15 CET] <scriptease> check this [00:14:16 CET] <scriptease> https://obsproject.com/forum/threads/nvenc-support-for-linux.47023/ [00:15:56 CET] <maxrazer> I think those links might do it. [00:16:25 CET] <maxrazer> The other thing though, is the video is very blurry. I don't think that should be caused by the encoder set to x264 software. In Windows and Linux Mint it looked fine I believe. [00:19:29 CET] <maxrazer> thanks [00:20:06 CET] <scriptease> np [04:25:44 CET] <television> inex: hi [04:25:52 CET] <inex> who tf named it "nut" [04:27:03 CET] <television> you mean the container? [04:27:07 CET] <television> https://ffmpeg.org/~michael/nut.txt [04:30:00 CET] <inex> yes! [04:30:33 CET] <television> i don't know... maybe michaelni knows? [11:04:09 CET] <lg188> Hello. Trying to pull some vhs tapes on digital and I'm getting this warning: "Queue input is backward in time" [11:04:36 CET] <lg188> and this is the command I'm using: /usr/bin/ffmpeg -thread_queue_size 1024 -i /dev/video0 -thread_queue_size 1024 -f alsa -i sysdefault:CARD=Cx231xxAudio -vf yadif=1:1,hqdn3d=4:4:3:3 -preset slow -strftime 1 2019-01-14_11:03:25.mkv [11:05:27 CET] <lg188> (ignore the strftime, I realised I still had it in there for some reason) [13:41:12 CET] <atbd> hi, is it possible to output to a char buffer instead of a file with an output AVFormatContext ? [13:41:45 CET] <JEEB> write your own AVIO context [13:41:49 CET] <JEEB> with write callback [13:42:08 CET] <JEEB> there's at least one AVIO context example doc/examples [13:43:46 CET] <atbd> okay thanks ! I'll look it [13:50:51 CET] <ariyasu> hey all [13:51:11 CET] <ariyasu> im getting this error repeated a bunch of times when demux audio (mp2) from a transport stream [13:51:13 CET] <ariyasu> [mp2 @ 0000000002a40f40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 19610640 >= 19608482 [13:51:27 CET] <ariyasu> when i then remux it into my encode, it's out of sync [13:51:34 CET] <ariyasu> any ideas why it's happening [13:51:42 CET] <ariyasu> seems to only be from ntsc sources [13:55:15 CET] <ariyasu> https://pastebin.com/raw/Vv9R8G2x [14:00:53 CET] <ariyasu> demuxing with mkvmerge from the .ts works without error and remuxes with my encoded video fine, so it's some issue with ffmpeg :( [16:50:59 CET] <zerodefect> I'm using Ubuntu Desktop v18.04; the desktop comes installed with version v3.4.4 of FFmpeg. Now what is the best way to build/run with a newer version of FFmpeg _without_ impacting on the older version of FFmpeg? Do I just use LD_LIBRARY_PATH? I appreciate this may not be an FFmpeg-specific question. [16:51:33 CET] <JEEB> default build is static so you can just configure with defautls and --prefix [16:51:45 CET] <JEEB> and then after make install it will be under your custom prefix/bin [16:52:09 CET] <JEEB> given that your prefix is not your standard location it should do zarro things to oyur current install of libraries etc [16:52:31 CET] <zerodefect> Ah, ok. I like that idea. [16:52:37 CET] <JEEB> if you for some reason need shared libraries, then yes -- --enable-shared and LD_LIBRARY_PATH towards that [16:52:47 CET] <JEEB> (the prefix/lib dir) [16:53:27 CET] <zerodefect> Thanks. I'll give the former a try for my development purposes. [16:53:54 CET] <JEEB> and then when developing against that FFmpeg copy, set PKG_CONFIG_PATH towards prefix/lib/pkgconfig [16:54:08 CET] <JEEB> and pkg-config *should* pick the .pc file from there [16:54:23 CET] <JEEB> if not, just remove the -dev package (which should not affect apps using those non-development libraries) [16:55:25 CET] <zerodefect> Ah ok. I'm not familiar with `PKG_CONFIG_PATH`. I'll need to read up about that. Seen it mentioned many a time though. [16:56:18 CET] <JEEB> it appends to the search path [16:56:25 CET] <JEEB> for cross-compilation you generally want PKG_CONFIG_LIBDIR [16:56:29 CET] <JEEB> which overrides the whole search path [16:56:29 CET] <JEEB> :) [16:56:43 CET] <JEEB> (usually you have xxx-pkg-config wrappers that do that for you, though) [16:57:07 CET] <zerodefect> So if I `echo $PKG_CONFIG_PATH`, it's currently blank. Surprising? [16:57:13 CET] <JEEB> nope [16:57:15 CET] <JEEB> it's an override [16:57:19 CET] <JEEB> as in, it appends [16:57:23 CET] <zerodefect> Right [16:57:26 CET] <Martchus> Browsing the livav APIs I'v noticed that there are FFT functions available. Are there any examples how to use them (or any piece of code using them)? How do those functions compare to fftw3? [16:58:15 CET] <JEEB> yea, there's some avfft.h - never used that. at least ffplay.c seems to be utilizing them [16:58:40 CET] <JEEB> and then multiple libavfilter filters it seems [17:00:00 CET] <Martchus> ok, I'll have a look (but maybe have to learn a bit more about fft in general first anyways) [17:36:45 CET] <ksk> hola. [17:38:23 CET] <ksk> I have some video material which comes in a .ts file, and a bunch of other files with other endings. Now for one video I only have the .ts file and got issues with playback, like the video plays through, but sometimes image and/or audio is missing. [17:38:55 CET] <ksk> vlc says its h264 - MPEG-4 HVC. [17:39:44 CET] <ksk> can you give me a hint on a) why a video is/was split in such a way in the first place b) if I can transform the complete ones into a single file c) If I can make the somewhat broken files whole again [17:40:48 CET] <ksk> *for example there might be 30s missing from minute 7 to minute 7:30 or so, but vlc still plays the no-content parts [18:02:37 CET] <ariyasu> Application provided invalid, non monotonically increasing dts to muxer in stream [18:03:04 CET] <ariyasu> anyone know how i can fix this, without creating sync issues [18:22:28 CET] <ariyasu> [mpegts @ 0000000000368c00] Invalid DTS: 19618599 PTS: 19612594 in output stream 0:0, replacing by guess [18:22:31 CET] <ariyasu> :( [18:52:26 CET] <meredydd> Hi; I'm trying to record and combine live audio and video that are desynced by quite a long time (audio is 10-20s behind, and I'd like to delay the video to match). Using "-itsoffset" on the video input and/or "-ss" on the audio input appears to confuse ffmpeg - it reports a very low "speed" and ends up dropping large chunks of either audio or video, leaving only little fragments of normal speed. [18:54:33 CET] <meredydd> In the absence of a video delay filter (I know there's one for audio delay), how should I do this in a live recording? [18:57:11 CET] <meredydd> (I apologise for the slightly ill-formed question; it is possible that the correct answer actually involves [eg] tweaking whatever mechanism governs the frame rate of v4l capture - although I've tried -r and -framerate, and they both fail in different ways) [18:58:08 CET] <Mavrik> meredydd, um, well [18:58:16 CET] <Mavrik> The obvious question is - why not just use audiodelay filter? [18:58:29 CET] <Mavrik> Since delaying video vs. audio or delaying audio vs. video should be the same thing? [18:58:41 CET] <meredydd> Erm, does audiodelay work with negative delay? [18:58:56 CET] <meredydd> If so, I feel like a complete idiot. [18:59:56 CET] <meredydd> (erm, I mean -adelay) [19:01:39 CET] <meredydd> Nope: "delay must be non negative number". Close, no cigar :( [19:02:48 CET] <pink_mist> shouldn't that just be a matter of adding a filter which discards the first x.x seconds of the audio? [19:04:41 CET] <durandal_1707> meredydd: there is video delay filter [19:05:10 CET] <meredydd> durandal_1707: What's it called? I've been googling looking for one on and off for several hours! [19:05:19 CET] <durandal_1707> meredydd: tpad [19:05:32 CET] <meredydd> pink_mist: I've tried "-ss 15.0" on the audio, but it just gets confused and does the thing I described to start [19:06:04 CET] <durandal_1707> you can use also atrim filter to trim audio [19:09:11 CET] <meredydd> durandal_1707: If this works, I could kiss you... [19:23:44 CET] <meredydd> durandal_1707: OK, so atrim doesn't work. It just produces 15s of silence with frozen video, then plays the audio at the un-shifted time (which unfreezes the video) [19:28:59 CET] <meredydd> And tpad blocks out the first 15 seconds of video all right, but after that it runs for a few frames and freezes, and sporadically does the same (run for a few frames, freeze) for the rest of my 45-second test. [19:29:37 CET] <durandal_1707> meredydd: what is your input and full command? [19:31:21 CET] <Mavrik> Not supporting negative delay seems wierd tho [19:31:38 CET] <durandal_1707> negative delay is trimming [19:31:43 CET] <meredydd> durandal_1707: Inputs are an ALSA device and a v4l capture device. [19:32:15 CET] <durandal_1707> so why they are out of sync? [19:32:50 CET] <meredydd> ffmpeg -f alsa -acodec pcm_s32le -ar 48000 -ac 2 -i hw:Loopback,1,0 -f v4l2 -framerate 25 -itsoffset 17.0 -video_size 640x480 -i /dev/video0 -c:v libx264 -t 45 out.mp4 [19:32:58 CET] <meredydd> Correction: ffmpeg -f alsa -acodec pcm_s32le -ar 48000 -ac 2 -i hw:Loopback,1,0 -f v4l2 -framerate 25 -video_size 640x480 -i /dev/video0 -c:v libx264 -t 45 out.mp4 [19:33:18 CET] <meredydd> durandal_1707: Because the ALSA device is coming out of the other end of some processing which imposes a delay. [19:36:08 CET] <durandal_1707> what kind of processing? [19:37:12 CET] <meredydd> Not stuff I can talk about on a public IRC channel, I'm afraid :-/ [19:39:01 CET] <durandal_1707> meredydd: what is first timestamp from audio and video? use (a)showinfo filters [19:39:54 CET] <meredydd> durandal_1707: With which combination of filters in the loop? (itsoffset, tpad, atrim...?) [19:40:03 CET] <durandal_1707> remove itsoffset [19:40:14 CET] <durandal_1707> and all filters [19:40:29 CET] <durandal_1707> and add (a)showinfo [19:40:43 CET] <durandal_1707> so it reports what timestaps is received [19:41:03 CET] <durandal_1707> -vf showinfo -af ashowinfo [19:41:16 CET] <meredydd> [Parsed_showinfo_0 @ 0x34a5c80] n: 1 pts:1756034 pts_time:1.75603 pos: -1 fmt:yuyv422 sar:0/1 s:640x480 i:P iskey:1 type:I checksum:CDBBED90 plane_checksum:[CDBBED90] mean:[120] stdev:[37.6] [19:41:20 CET] <meredydd> (first line from video) [19:41:47 CET] <meredydd> [Parsed_ashowinfo_0 @ 0x41b91c0] n:1 pts:152 pts_time:0.00316667 pos:-1 fmt:s32 channels:2 chlayout:stereo rate:48000 nb_samples:128 checksum:70675E5E plane_checksums: [ 70675E5E ] [19:41:51 CET] <meredydd> (first line from audio) [19:42:08 CET] <meredydd> (there are 7 lines - I assume frames - from the video before I see anything from the audio) [19:44:23 CET] <durandal_1707> well looking into pts_time they are not delayed that much [19:44:44 CET] <meredydd> Not according to ffmpeg, no. [19:44:56 CET] <meredydd> But the data is about 15s out of sync [19:45:48 CET] <durandal_1707> that would mean one need to buffer 15 seconds of video [19:46:09 CET] <meredydd> yep [19:46:16 CET] <meredydd> That's what I'm trying to get it to do [19:47:41 CET] <durandal_1707> you will need to use tpad with setpts filter to increase timestamps of video by ~15 seconds [19:48:24 CET] <durandal_1707> actually decrease [19:48:49 CET] <durandal_1707> because tpad filter inserts frames and alters pts [19:50:23 CET] <durandal_1707> setpts=PTS-<15s in timebase units> [19:50:23 CET] <meredydd> aha [19:52:18 CET] <durandal_1707> or you can add 15s to audio frames with asetpts=PTS+48000*15 [19:52:55 CET] <durandal_1707> I dunno what is strema timebase of Audio and Video [19:54:47 CET] <meredydd> OK, adding "-vf tpad=start=15 -vf "setpts=PTS-15/TB" produces a video that starts in the right place, and no audio. [19:55:00 CET] <meredydd> Guess I should break out showinfo and work out what the timestamps are now... [20:02:58 CET] <meredydd> durandal_1707: Hrm. I'm not seeing the effects of the setpts in the showinfo output. Should I be worried? [20:05:57 CET] <durandal_1707> meredydd: 15*TB i think [20:06:41 CET] <durandal_1707> meredydd: also you can not use -vf XXX -vf YYY [20:06:49 CET] <durandal_1707> use -vf XXX,YYYY [20:07:10 CET] <durandal_1707> -vf tpad=start_duration=15 for start [20:07:32 CET] <durandal_1707> start=15 will delay by 15 black frames only [20:15:47 CET] <meredydd> Current command: ffmpeg -f alsa -acodec pcm_s32le -ar 48000 -ac 2 -i hw:Loopback,1,0 -f v4l2 -framerate 25 -video_size 640x480 -i /dev/video0 -c:v libx264 -t 45 -vf tpad=start_duration=15,setpts=PTS+15/TB,showinfo out.mp4 [20:17:03 CET] <durandal_1707> 15/TB does nothing, it goes into 0 [20:17:35 CET] <durandal_1707> or not, i dunno really [20:18:24 CET] <meredydd> Seems to be doing sensible things on the console - I see 15 seconds of video coming out very quickly (presumably the black frames), then about 15 seconds after invocation (presumable the audio catching up) it starts issuing audio frames with a PTS of 15, smoothly up to 30 [20:18:47 CET] <exile_xii> hi all, does anyone know if there is a way that I could use a filter or something to access the name of the currently active segment of a HLS stream in code? [20:18:58 CET] <meredydd> However, the actual resulting video is black for 30 seconds (with good audio), then few-frames-at-a-time janky [20:19:24 CET] <meredydd> durandal_1707: Thanks so much for your help. I have to go now; you have given me some excellent pointers and I will now be digging in further. [20:19:35 CET] <durandal_1707> meredydd: try to remove setpts [20:21:07 CET] <meredydd> durandal_1707: That results in janky-video chaos IIRC [20:22:45 CET] <durandal_1707> janky? [20:23:51 CET] <durandal_1707> you better encode audio and video separately and play later with it [22:44:30 CET] <KombuchaKip> What is the meaning of an "atom" in the context of ffmpeg? [22:52:20 CET] <JEEB> mov/mp4 has atoms/boxes [22:52:32 CET] <JEEB> also I think MXF had atoms? [23:19:40 CET] <KombuchaKip> JEEB: Ok, but what are they? Some kind of VM instruction, metadata, a general algorithm concept in codecs? [00:00:00 CET] --- Tue Jan 15 2019

1 0

ffmpeg-devel.log.20190113
by burek 14 Jan '19

14 Jan '19

[03:09:00 CET] <Compn> [mjpegb @ 000000000046cac0] not mjpeg-b (bad fourcc) [03:09:01 CET] <Compn> why [12:09:01 CET] <cone-077> ffmpeg 03Paul B Mahol 07master:9217dedcd991: avfilter/af_anlmdn: add timeline support [12:45:18 CET] <durandal_1707> michaelni: who is sponsoring your commits? [14:34:55 CET] <jamrial> of all the times to troll, durandal_1707, you chose this one? [14:36:45 CET] <durandal_1707> i never troll [14:38:05 CET] <jamrial> you just did, feeding nicolas' latest time/patience wasting obsession [14:41:40 CET] <durandal_1707> i'm serious, i'm supporting nicolas work/obsession/patch whatever you call it [14:42:48 CET] <JEEB> copyright should be already noted by the authorship field, and anything like that IMHO is not going to make the review process any better [14:42:54 CET] <JEEB> which I agree it should be [14:44:34 CET] <durandal_1707> when you are paid autorship may belong to another entity [14:44:51 CET] <JEEB> of course [14:45:10 CET] <JEEB> that is why the authorship field is what generally mentions that, unless you have given the copyright on your work [14:46:01 CET] <JEEB> usually it's done so that you have a corporate e-mail (and possibly name) in your authorship field of the patch [15:49:13 CET] <kierank> durandal_1707: that has nothing to do with ffmpeg [16:52:00 CET] <Compn> durandal_1707 : unless someone updates copyright field, copyright is owned by committer / author field. payment for work != copyright owner [16:52:26 CET] <Compn> lots of devs get paid from various companies and still retain ffmpeg copyright [16:52:42 CET] <Compn> other devs submit code with company copyright [16:53:09 CET] <Compn> its nice having some big companies that can enforce GPL in our code [18:06:43 CET] <durandal_1707> kierank, Compn: it have to do with everything [19:01:17 CET] <cone-533> ffmpeg 03James Almer 07master:f477ee3e8956: checkasm/af_afir: relax the max allowed absolute difference [21:08:58 CET] <cone-533> ffmpeg 03Peter Ross 07master:d52a1be4e339: avcodec/vp3: ref_frame/ref_frames are only required when HAVE_THREADS=1 [00:00:00 CET] --- Mon Jan 14 2019

1 0

ffmpeg.log.20190113
by burek 14 Jan '19

14 Jan '19

[01:55:05 CET] <Retr0id> Sorry for repeating my question, I guess I'll open a bug report after this if nobody can help: Does anyone have advice on how to download a .mpd DASH stream while preserving the encryption metadata (senc atoms etc.)? [01:56:24 CET] <Retr0id> (when the stream is CENC encrypted) [10:15:08 CET] <scramblez> Hi All, I noticed some TV recordings won't play on a Sony TV (android OS) over DLNA. I used ffmpeg with '-codec: copy' so that no streams were altered and the resultant .ts file played fine on the TV. Would you know what changed to allow this to happen? Something in the .ts file headers? [10:16:04 CET] <scramblez> Is there a bit I could flip in situ on such recordings so that DLNA won't stop them playing on the TV? [10:42:41 CET] <ultramage> hi, with latest ffmpeg, -x264opts "range=full" gives "bad option 'range': 'pc'" even though x264 lists this option right next to other colorspace options that work. [10:43:05 CET] <ultramage> (er... I tried full and pc, neither works, got them mixed up in the previous line) [10:44:18 CET] <JEEB> lessee... [10:46:33 CET] <ultramage> a thread from 2014 says input_range and rage are missing options from from ffmpeg/libx264... great... [10:46:58 CET] <JEEB> x264-params should be passing it straight to libx264 btw, and most likely setting range in general might work as well [10:47:06 CET] <JEEB> I'm just looking at x264's "param_parse" [10:47:12 CET] <ultramage> ah, thank you [10:47:16 CET] <JEEB> which is what's getting called with both opts and -params most likely [10:47:26 CET] <JEEB> and I see an option called "fullrange" [10:47:42 CET] <JEEB> yea [10:47:53 CET] <JEEB> seems like it's not range=full if you want to pass it straight to libx264 API :P [10:48:21 CET] <JEEB> and that takes off, on [10:48:25 CET] <JEEB> as x264_fullrange_names [10:48:40 CET] <ultramage> I'm having extreme issues trying to convinve ffmpeg/libx264 and libx265 to produce output that plays along with MPC-HC. Currently anything I try will appear washed out since it's decoding it as TV [10:49:00 CET] <JEEB> full range YCbCr and MPC-HC can be fun depending on various factors [10:49:06 CET] <JEEB> I recommend testing with something like mpv [10:49:22 CET] <JEEB> but let's see the FFmpeg libx264 wrapper first for if you really need to use x264-params [10:49:23 CET] <ultramage> it plays fine in everything except mpc-hc, the thing uses some shitty heuristic or something to decide [10:49:40 CET] <ultramage> however, with x265 I set the output color range header to full and it still displayed wrong >_> [10:49:45 CET] <JEEB> avctx->color_range == AVCOL_RANGE_JPEG [10:49:56 CET] <JEEB> so that is another way in FFmpeg's libx264 wrapper to set range [10:49:59 CET] <ultramage> I can go into its renderer settings and force 0-255, but I don't like that solution [10:50:17 CET] <JEEB> well yea, limited and full range YCbCr is 100% up to your renderer in DirectShow [10:50:22 CET] <JEEB> it's called "too bad, joe" :P [10:50:35 CET] <JEEB> but anyways, the thing for you is to just flag the stream correctly [10:51:13 CET] <JEEB> which in case of libx264 in FFmpeg is either -color_range pc or -x264-params "fullrange=on" [10:51:21 CET] <JEEB> and that should output fullrange being enabled in the libx264 logging output [10:51:34 CET] <JEEB> for libx265 people have implemented less mappings I think [10:52:02 CET] <JEEB> yea, the libx265.c wrapper doesn't have a single entry for "range" if I ctrl+F [10:52:25 CET] <ultramage> so far the only thing that worked was -pix_fmt yuvj444p. That 'j' convinced the whole pipeline to work right. [10:52:51 CET] <JEEB> that's possibly needed if you want filtering because "lol swscale" [10:52:59 CET] <ultramage> "fullrange=on" is the correct magic incantation, and it writes the correct header into the metadata, but it still decodes wrong. [10:53:25 CET] <durandal_1707> ultramage: if you use filtering properly tag input with setrange filter.... [10:53:32 CET] <JEEB> if it shows right in mpv, then it's correctly encoded, but anyways with DirectShow you're shit out of luck :P [10:53:37 CET] <ultramage> or maybe it's actually encoding wrong? :/ [10:53:59 CET] <ultramage> I'll try throwing in any range settings I can find [10:54:11 CET] <JEEB> well, encoding is one part and then the possible filtering before that is another thing if you need to do filtering [10:54:15 CET] <JEEB> the encoding part is simple [10:54:21 CET] <JEEB> since you can verify the headers [10:54:27 CET] <ultramage> that yuvj444p thing also makes it write the correct header. but it says it's deprecated and x265 doesn't even support that format. [10:54:41 CET] <JEEB> yes, x265 wrapper doesn't take it in AFAICS [10:55:29 CET] <JEEB> (and thus there could be an implicit swscale conversion somewhere which is always fun) [10:55:34 CET] <ultramage> the fullrange and other color space options are just informative metadata settings only. I guess I'm missing an actual encoder toggle. [10:55:48 CET] <JEEB> well there is nothing else in the encoder for full range than the flag [10:55:57 CET] <JEEB> so if the flag is there, the encoder specifically is doing things right [10:56:45 CET] <JEEB> now, with libx264 part of the problem is that since the J formats aren't really supposed t obe utilized any more, it doesn't take those in. (the range flag instead should be used instead - although the libx265 wrapper doesn't use that, either) [10:57:12 CET] <JEEB> so it's highly likely that something that is before the *encoder* decides it needs to convert from pix_fmt X to Y [10:57:17 CET] <ultramage> and the worst thins is that things seem to default to 'tv' [10:58:03 CET] <durandal_1707> convert to tv, as pc is not supported [10:58:40 CET] <JEEB> I really wonder if I should be responding that comment or not [10:59:38 CET] <ultramage> Stream #0:0: Video: h264 (libx264) (H264 / 0x34363248), yuv444p(pc), 576x988, q=-1--1, 4000 kb/s, 30 fps, 1k tbn, 30 tbc [10:59:41 CET] <JEEB> anyways, one thing is now clear - for the *encoder* libx264 and libx265 can be clearly set to utilize the correct flag when you set it according to how the wrapper does it (libx264 it's either the range flag, or the fullrange=on api thing - for libx265 it's just the correct x265-params thing) [11:00:13 CET] <JEEB> you should at the very least bump verbosity to -v verbose as that shows you (mostly) everything lavfi/swscale comes up with [11:00:35 CET] <JEEB> + for libx265 specifically any hacks regarding the J pix_fmts will not work, since it doesn't take those in at all [11:01:16 CET] <ultramage> -color_range pc ffmpeg option appears to do the right thing... at least libx264 reports yuv444p(pc), and the metadata header is set. mpc-hc still decodes it wrong <_> [11:01:33 CET] <JEEB> yes, that only affects the libx264 *encoder* [11:01:35 CET] <durandal_1707> but perhaps x265 encode wrapper should not ignore set color_range? [11:01:52 CET] <JEEB> durandal_1707: yea you currently have to use x265-params to set the flag [11:01:54 CET] <ultramage> hm, now it seems to work? so confused. [11:02:25 CET] <ultramage> I'm going to do a bunch more tests to see if it behaves. Thank you for your help so far. [11:02:35 CET] <JEEB> ultramage: basically most likely whatever's going bonkers for you is /before/ the encoder part. although I would really, really use mpv as a reference as opposed to mpc-hc [11:02:44 CET] <JEEB> mpc-hc is so dependant on your driver and video rendere in directshow [11:02:46 CET] <ultramage> ah, it doesn't. I just forgot the 'j' in the pix format. [11:02:56 CET] <ultramage> okay I will do that [11:03:15 CET] <JEEB> also that 'j' pix_fmt can actually kill your attempts at passing that stuff through :P [11:03:18 CET] <JEEB> it really "depends" [11:03:28 CET] <JEEB> and that's the stuff *before* encoding, the filtering [11:03:40 CET] <JEEB> and as I said, -v verbose will help you poke at what on earth that thing's doing [11:03:58 CET] <JEEB> the encoder is just one thing of the chain, and we *know* how you get the *encoder* to flag it as you want [11:04:11 CET] <durandal_1707> ultramage: full uncut ffmpeg command and console output missing [11:04:15 CET] <JEEB> now the thing to make sure is to make sure what gets *fed* to the encoder is correct [11:04:38 CET] <JEEB> because there's umpteen things that may or may not go bonkers with this stuff :P [11:04:59 CET] <JEEB> in theory if your input is already in the size and pix_fmt you want [11:05:11 CET] <JEEB> you just want to minimize anything lavfi/swscale does to your input [11:05:52 CET] <JEEB> and I hope I haven't confuzzled the heck out of you by trying to separate the *encoder* part in this whole mess from the rest of it that comes before it :P [11:06:08 CET] <JEEB> because the *encoder* part is really simple to verify (the flag is set correctly) [11:06:20 CET] <JEEB> then the rest is making sure that the correct input is fed to it [11:06:37 CET] <JEEB> because unfortunately that part is what can go wrong in so many ways [11:07:02 CET] <JEEB> and after that has been verified with something known to more or less do things right, then you can just sigh in despair if DirectShow doesn't support it properly :P [11:07:15 CET] <JEEB> (read: whatever renderer you're using) [11:07:18 CET] <ultramage> yeah I'm familiar with the concept of the input being read wrong [11:07:36 CET] <JEEB> nah, more like it gets mungled after reading. reading itself is generally correct :P [11:08:15 CET] <JEEB> the semi-automated (but also user-controllable if needed) filtering that is between "we got raw images from input" and "we got raw images fed into an encoder" [11:08:36 CET] <JEEB> <input> - <filtering lol> - <encoder> - <muxing> [11:09:46 CET] <ultramage> .\ffmpeg.exe -y -i %1 -t 1 -c:v libx264 -preset veryfast -color_range pc -pix_fmt yuv444p -b:v 4000k -an %1.mkv [11:10:01 CET] <ultramage> the output of this appears washed out in mpv as well. [11:10:35 CET] <JEEB> now add -v verbose there and read out the log :P if the windows cmd.exe sucks with that - " 2> out.log" should output stderr into out.log [11:10:49 CET] <JEEB> and you can then read through that in a text editor [11:11:07 CET] <durandal_1707> <input> - <demuxing> - <FANCY filtering> - <encoder> - <muxing> - <output> [11:11:22 CET] <ultramage> I think I'll do a raw RGB capture and use that as input to first rule out any input recognition/conversion shenanigans [11:11:22 CET] <JEEB> and yes, you're setting color range full and pix_fmt to non-j. that might trigger some funky conversions [11:11:38 CET] <durandal_1707> oh, missed decoding part... [11:11:52 CET] <JEEB> yea [11:13:01 CET] <JEEB> ultramage: basically that sounds for me that the pix_fmt is causing a conversion to limited range in swscale, and then color_range of course sets the metadata in the encoder [11:13:04 CET] <JEEB> thus the mismatch [11:14:03 CET] <durandal_1707> i will repeat for last time, if input color range is not properly set the "-color_range pc" will do bad things [11:14:25 CET] <JEEB> of course [11:18:49 CET] <ultramage> mmm [11:21:47 CET] <ultramage> what is the toggle for the input color range override? [11:22:20 CET] <JEEB> there's probably one for lavfi and then there's the color_range for just input [11:22:48 CET] <JEEB> (color_range et al mean different things before/after -i) [11:23:06 CET] <JEEB> and yea, for lavfi filtering it'd be setrange filter [11:24:32 CET] <ultramage> ugh, someone smarter than me should look into this, to me it seems like there are multiple stacking issues [11:25:01 CET] <JEEB> possibly. that's what I was going after with the fact that the *encoder* being primed correctly for the range you'd want is simple :P [11:25:42 CET] <JEEB> (and that the stuff that happens before it is really the "fun" part) [11:28:45 CET] <ultramage> I created a small RGB avi from bmp files using vdub. I invoked 'ffmpeg -c:v libx264 -profile high444' to bypass any manual color fiddling. In mpv it looks fine, in mpc-hc it's washed out. [11:29:04 CET] <JEEB> always use -v verbose [11:29:25 CET] <JEEB> since that outputs stuff regarding any filter chains that might get utilized [11:33:06 CET] <ultramage> https://paste.pfak.org/nqodlgsK [11:33:58 CET] <JEEB> [auto_scaler_0 @ 000000000037b980] w:1920 h:1080 fmt:bgr24 sar:0/1 -> w:1920 h:1080 fmt:yuv444p sar:0/1 flags:0x4 [11:34:06 CET] <JEEB> what happened here is full->limited range conversion [11:34:42 CET] <ultramage> yup... if I lie about the fullrange header, mpv will show it washed out. this implies that the video is indeed limited [11:35:18 CET] <ultramage> this seems to match the x64 documentation which says that fullrange is off by default (although it says that only in the metadata docs) [11:35:22 CET] <JEEB> but yea, since you set no real parameters in there, that's what happens by default [11:35:29 CET] <JEEB> yes, limited range is default for YCbCr [11:35:34 CET] <JEEB> and full range is default for RGB [11:35:39 CET] <JEEB> almost everything works in that kind of setup [11:35:56 CET] <JEEB> unless said otherwise, that's how those are taken in by applications [11:37:14 CET] <ultramage> hm, my issue started once I switched to ffmpeg and asked it to encode as yuv444 instead of yuv420, and all my videos appeared washed out. I think mpc-hc decodes yuv444 as fullrange always. [11:37:59 CET] <JEEB> mpc-hc is less simple but I would say nope at that since pretty much all YCbCr interactions are taken in as limited range unless otherwise tagged (and if the receiving part even acknowledges that) [11:38:19 CET] <JEEB> like, even YCbCr colorspace tagging in directshow is 100% up to the renderer and/or driver [11:38:32 CET] <JEEB> BT.601 vs BT.709 that is [11:41:57 CET] <ultramage> so then, am I doomed? should I go back to x264rgb, or keep abusing yuvj444p? [11:42:35 CET] <JEEB> I would say if you can utilize RGB, that's simpler [11:42:43 CET] <JEEB> since you're encoding 4:4:4 anyways as far as I can see? [11:43:53 CET] <ultramage> I'd rather not... I think I stopped using rgb after discovering that x265 doesn't support it, or something like that. I wanted to keep my settings as similar as possible [11:44:26 CET] <JEEB> as far as I can see libx265's wrapper takes in GBRP as well [11:44:28 CET] <ultramage> might be less of an issue now that youtube finally accepts x265 [11:44:52 CET] <JEEB> if you're uploading to youtube I don't see any reason to use x265 tbqh. you can just throw lossless at that thing anyways [11:45:33 CET] <JEEB> anyways, AV_PIX_FMT_GBRP is in libx265's list of supported pix_fmts [11:45:42 CET] <ultramage> it does take direct lagarith/dxtory captures, but they tend to get quite large and the youtube cutoff is somewhere around 10GB. [11:46:23 CET] <JEEB> libx264 takes in BGR0,24 and RGB24 [11:46:35 CET] <JEEB> so somewhat different pix_fmts, but still RGB is supported in both [11:46:49 CET] <JEEB> oh, they've got an upload size limti now? :P [11:47:13 CET] <JEEB> that is awfully inconvenient given that generally you want to eff with your source the less as possible because their encoders will only barf *more* at them [11:47:30 CET] <ultramage> well, a few years back when I was doing this, that was about as much as it'd take without breaking during upload. [11:48:52 CET] <JEEB> anyways, personally I don't see any reason to use libx265 for youtube uploads. it's slower and last time I checked the detail retention at similar bit rates was worse off if you went out of the "both are crappy as hell" territory [11:48:55 CET] <ultramage> this originally started because the game footage me and a friend were uploading was getting its color space distorted and causing other artifacts... it looked crap. [11:49:39 CET] <ultramage> but god, it's been so long ago that I don't remember the cause anymore. We were using vdub's x264vfw back then, probably wihtout any fancy settings. [11:53:05 CET] <ultramage> I used rgb after that for some time, but then switched to yuv because... I don't remember why. Either my new capture software was using yuv and I wanted to avoid any extra lossy colorspace conversions, or the rgb encoding was much slower / less optimized than yuv. [11:53:38 CET] <JEEB> the encoding itself should be the same since it's 4:4:4 data (compared to 4:4:4 YCbCr) [11:53:54 CET] <JEEB> RGB conversion could be adding something in there, but loldunno [12:14:18 CET] <isimulate> Where is the FFMPEG documentation? I was able to navigate to https://www.ffmpeg.org/libavdevice.html, which appears to the be provided docs for libavdevice, btu there's no information there about how to use it, it just links you to user tools rather than any docs about the API. Where do you go to learn how to use this library? [12:14:39 CET] <JEEB> site:ffmpeg.org doxygen trunk KEYWORD [12:14:41 CET] <JEEB> is what I usually do [12:24:22 CET] <JEEB> also there's the examples under doc/examples [12:33:55 CET] <trfl> if a comment is added to a 2 year old issue on trac.ffmpeg.org, will it get bumped/noticed? [12:34:31 CET] <JEEB> it will get posted on the -devel IIRC channel at the very least [12:34:40 CET] <JEEB> whether someone does something about it is a different thing [12:34:53 CET] <JEEB> I know at least one person is somewhat looking at updates in the tickets [12:34:59 CET] <trfl> aight, that's good [12:35:27 CET] <trfl> was about to start blaming my cd drive for truncating tracks but turns out there's one particular wav file which causes ffmpeg's flac encoder to generate an invalid bitstream or something :p [12:35:37 CET] <trfl> so the file gets truncated depending on which decoder is used to read it [12:36:14 CET] <JEEB> funky [12:39:37 CET] <durandal_1707> shit [12:41:43 CET] <ultramage> ... encoding RGB24 with -pix_fmt yuvj444p causes oversaturation, nnnnnnooooooooo D: [12:42:46 CET] <durandal_1707> ultramage: full uncut ffmpeg command and console output missing [12:43:40 CET] <ultramage> actually nvm, it seems like the act of encoding to any form of yuv causes a noticeable difference in brightness (or something) [12:44:17 CET] <ultramage> I decided to take notes after each test and do a visual comparison of the input and output in mpc and mpv. [12:52:38 CET] <ultramage> there is a noticeable increase of brightness when encoding to yuv(420, 444, j444) in both mpc and mpv... is this the result of the conversion? [12:53:17 CET] <ultramage> (when encoding the testing rgb rawvideo) [12:53:43 CET] <durandal_1707> swscale is crap [12:54:02 CET] <durandal_1707> use zimg with zscale filter if you can [12:54:22 CET] <JEEB> also with verbose verbosity make sure that no funky stuff happens [12:54:43 CET] <ultramage> [auto_scaler_0 @ 00000000003fb9c0] w:1294 h:832 fmt:bgr24 sar:0/1 -> w:1294 h:832 fmt:yuv444p sar:0/1 flags:0x4 [12:54:52 CET] <JEEB> because while there's an option to disable implicit adding of swscale, I think you can't do that with ffmpeg.c :P [12:55:25 CET] <durandal_1707> there is filtergraph option to disable auto insertion of filters [12:55:30 CET] <JEEB> yes, that's what I meant [12:55:34 CET] <JEEB> but I don't think you can use that from ffmpeg.c [13:09:20 CET] <ultramage> strange, the options for zscale filter do not list any format options [13:09:43 CET] <JEEB> for output format you set the pix_fmt with the format filter [13:09:47 CET] <JEEB> which is a meta thing [13:10:10 CET] <JEEB> zscale=blah=blah:blah2=blah2,format=bgrp for RGB conversion, for example [13:10:24 CET] <JEEB> and then you set additional parameters in zscale as needed [13:17:20 CET] <isimulate> Why are timestamps normalised to a time base in general? I wonder why they can't be stored as unnormalized seconds into a uint64_t and avoid the multiplications to convert them back into seconds. I am new to MM in general, so no trick question here, sorry if it's very stupid xD [13:17:23 CET] <ultramage> I can't get it to work. zscale is missing documentation [13:17:38 CET] <ultramage> and I have an extreme headache after messing with this for 4 hours straight [13:19:46 CET] <ultramage> all I want is for the encoding process to retain as much of the original as possible. But it's immediately changing the brightness... that's not what I want [13:20:22 CET] <JEEB> well the first question of course is if your build is even built with zimg :P [13:20:32 CET] <ultramage> it is [13:20:33 CET] <JEEB> which zscale is a wrapper around [13:20:35 CET] <JEEB> ok [13:21:58 CET] <JEEB> zimg can error out with non-clear erros but I've had it work nicely when I've tried things [13:22:10 CET] <ultramage> I would like the magic incantation to make it do rgb->yuv444p conversion (maybe in bt709) so that when I encode the thing, there will be no perceivable difference between the input and output [13:23:07 CET] <ultramage> swscale seems to be doing some weird color correction, or idk, and it causes an obvious difference between the input and output [13:24:14 CET] <ultramage> hmmm maybe I should transcode it back to rgb to rule out any playback decoder interference [13:27:38 CET] <isimulate> are there any books y'all can recommend for a background in multimedia? [13:28:12 CET] <JEEB> it starts with "what is light", but there's EBU's "Circles of Confusion" [13:28:18 CET] <JEEB> which somehow is an apt name :P [13:28:26 CET] <JEEB> https://tech.ebu.ch/circles-of-confusion [13:29:47 CET] <isimulate> Haha, thanks JEEB ! [13:34:13 CET] <JEEB> isimulate: also unfortunately we have things that need fractional time bases, such as 24/1.001 , 30/1.001, 60/1.001 and 120/1.001 to note a few rates :) [13:34:25 CET] <JEEB> in which case your time base would be f.ex. 1001/24000 [13:34:37 CET] <JEEB> and then every picture in a constant frame rate stream would have a +1 PTS [14:52:49 CET] <Redfoxmoon> does ffmpeg support building with -no-undefined on linux? [14:54:08 CET] <JEEB> funny enough if you git grep for no-undefined, the symbian arch part of the configure script seems to contain "-Wl,--target1-abs,--no-undefined" [14:54:11 CET] <JEEB> linker parameters [14:54:21 CET] <JEEB> so at least something has had it by default :D [14:56:41 CET] <Redfoxmoon> oh dear. [14:57:20 CET] <Redfoxmoon> JEEB, does the symbian port still work though? :P [14:58:24 CET] <JEEB> I have no idea [14:58:38 CET] <JEEB> I haven't seen it in FATE at least [14:58:42 CET] <JEEB> so it's not automagically tested [14:58:47 CET] <JEEB> (and I'm totally not surprised) [14:59:05 CET] <JEEB> http://fate.ffmpeg.org/ is FATE, for the record [14:59:09 CET] <Redfoxmoon> fair enough, it's not exactly common:-) [14:59:22 CET] <JEEB> well it's one of those things that used to be all around :P [14:59:25 CET] <JEEB> but no more [14:59:41 CET] <Redfoxmoon> indeed:-) [14:59:46 CET] <Redfoxmoon> neat! @fate [15:44:19 CET] <Redfoxmoon> Is it possible to disable building the x86 code in libavutil when targeting x86? [15:44:47 CET] <Redfoxmoon> running into some issues attempting to port ffmpeg to a new platform :^) [16:17:31 CET] <JEEB> Redfoxmoon: plethora of ways to do something like that. see how other archs work etc [16:27:26 CET] <Redfoxmoon> taking libavcodec as an example, I don't see any links in either the root makefile or the libavcodec makefile to arch specific bits under libavcodec/ [16:27:27 CET] <Redfoxmoon> o_O [16:29:52 CET] <Redfoxmoon> ah nevermind, I figured it out [16:50:12 CET] <BenderRodriguez> why does ffplay segfault when trying to play music [16:50:21 CET] <BenderRodriguez> I have pulse audio configured with a bluetooth receiver as the sink [16:50:35 CET] <BenderRodriguez> mpg123 and other music player utilities work fine [16:50:38 CET] <BenderRodriguez> but ffplay segfaults [16:50:53 CET] <JEEB> ffplay is someone's favourite little thing, not generally developed thing [16:51:03 CET] <JEEB> if you care enough, you could try getting a stack trace with gdb [16:51:06 CET] <JEEB> and posting on trac [17:22:31 CET] <analogical> can I somehow use FFmpeg to download flash video from a website? [17:31:12 CET] <Mavrik> youtube-dl is your better bet I think. [17:32:53 CET] <iive> BenderRodriguez, try `-an` to rule out other possible reasons than the audio output. [17:40:18 CET] <wuOz> hi, I try to build ffmpeg 4.1. did you stop support libnut build and disabled the disable-ffserver option? Further it can't find xlib, but in version 3 build it could find it with my build options. [17:41:10 CET] <JEEB> git grep "libnut" [17:41:10 CET] <JEEB> Changelog:- remove the libnut muxer/demuxer wrappers [17:41:32 CET] <JEEB> seems so (doesn't surprise me since libavformat is pretty much the de facto implementation for NUT) [17:41:44 CET] <JEEB> and ffserver was removed quite a bit earlier [17:41:57 CET] <JEEB> actually, I think both those changes are probably way back there in the change log [17:42:05 CET] <wuOz> ffserver was great, what happened? [17:42:11 CET] <JEEB> uhh [17:42:42 CET] <JEEB> no, it was not great (only did very specific things), and it required quite not-pretty things to function in the libraries etc [17:42:53 CET] <JEEB> plus pretty much nobody was maintaining it :P [17:43:01 CET] <wuOz> streaming alway worked fine for me [17:43:11 CET] <JEEB> well for streaming you generally didn't even need ffserver [17:43:38 CET] <JEEB> for stuff like UDP multicast you could just use ffmpeg.c, and for HLS/DASH type of streaming you could just use ffmpeg.c feeding into a basic nginx or any of those media server things [17:44:13 CET] <JEEB> and I think the best part was that almost nobody of the FFmpeg developers even knew how ffserver was even supposed to be utilized [17:44:21 CET] <JEEB> as in, what would actually work with it :P [17:44:36 CET] <JEEB> long story short it was a mess and it is out now after years of "we should remove it unless someone steps up" [17:44:39 CET] <JEEB> and nobody stepped up [17:44:41 CET] <JEEB> :P [17:44:47 CET] <wuOz> well as application it was fine [17:45:09 CET] <JEEB> I would put that in a lot of quotation marks [17:45:24 CET] <wuOz> i quote myself [17:45:34 CET] <JEEB> as in, """fine""" [17:45:44 CET] <wuOz> alright [17:45:52 CET] <JEEB> but yes, it probably worked for some use cases [17:45:55 CET] <JEEB> unfortunately internally it was a mess [17:46:05 CET] <JEEB> and it didn't even work with modern ways of streaming [17:46:14 CET] <JEEB> which users tend to expect [17:47:17 CET] <wuOz> hmm, it could broadcast as well as search the stream. don't know what else you could expect [17:48:09 CET] <wuOz> but probably the code was messed up, if I got you right [17:48:18 CET] <JEEB> anyways, there generally seemed to be better working alternatives for a lot of use cases, and nobody stepped up to improve it [17:49:17 CET] <JEEB> some people have tried to write a new "ffserver" for the things that people tend to nowadays expect from HTTP streaming etc, but personally I would rather see those as modules for web servers and such (there already are a few, like nginx-rtmp and such) [17:49:35 CET] <JEEB> or just plain nginx since libavformat can push a stream to a serving server with HTTP POST [17:49:39 CET] <JEEB> (among other things) [17:51:15 CET] <wuOz> ok [18:22:46 CET] <wuOz> could fix building v4.1 and xlib with LDFLAGS="-L/way/to/libdir" flag [18:23:29 CET] <wuOz> despite pkg_config_path was given [18:25:38 CET] <JEEB> probably because xlib has no pkg-config check in configure [18:26:10 CET] <JEEB> if there's a pc file for it, someone should add that :P [18:26:44 CET] <JEEB> switch check_lib to check_pkg_config [18:32:06 CET] <wuOz> xlib.pc is not there, but x11.pc and it could build without LDFLAGS in ffmpeg version 3 [18:33:16 CET] <JEEB> probably accidental from something else, because I'd be surprised if xlib configure steps would have changed [18:33:49 CET] <JEEB> basically a lot of stuff before was globally added to a lot of checks, which made things accidentally work (but also add unnecessary flags for stuff) [18:34:38 CET] <JEEB> oh, it was actually touched in May 2018. used to only check for func_headers before? [18:35:11 CET] <wuOz> ok [18:35:23 CET] <JEEB> also at 3.3 (2016) there was another change to xlib checks [18:35:51 CET] <JEEB> because it seems back then it would way too easily try to link against xlib :P [18:37:33 CET] <wuOz> as I remember it was 3.1.3 which could still build, so that could explain it [18:39:10 CET] <JEEB> well that's quite a few years ago and tehre's been various changes/improvements to the configure script since [18:39:29 CET] <JEEB> it might have poked the extra library search path from something else [18:39:51 CET] <JEEB> nowadays the checks are more separated [18:40:03 CET] <JEEB> (which is why pkg-config is 100% preferred) [18:40:25 CET] <JEEB> I added a check for zlib through pkg-config because I got tired of having to add --extra-ldflags="-L/my/cross/prefix/lib" [18:40:32 CET] <JEEB> (and since zlib has a pc file) [18:58:44 CET] <cyberaesthetic> Anyone around to answer a question re: time skipping? Noticed something in emby, replicated it in VLC, speculation is that something is going on at the ffmpeg layer: [18:58:46 CET] <cyberaesthetic> https://emby.media/community/index.php?/topic/57777-chromecast-time-skip-no… [19:46:26 CET] <plexigras> how do i best compress a livestream i am recording? [19:46:56 CET] <plexigras> example: `streamlink https://www.twitch.tv/riotgamesbrazil 480p --stdout | ffmpeg -i pipe:0 out.mp4` [20:26:07 CET] <friendofafriend> plexigras: Sounds like you have the right idea. [20:32:06 CET] <Redfoxmoon> do I need to go through a mailing list to get patches upstreamed for ffmpeg? [20:34:43 CET] <Redfoxmoon> also wondering how HAVE_INLINE_ASM_DIRECT_SYMBOL_REFS, HAVE_INLINE_ASM_LABELS and HAVE_INLINE_ASM_NONLOCAL_LABELS are detected [20:39:24 CET] <plexigras> friendofafriend: i would just love to know if there are some cool tricks i can use to save on disk space :) [20:41:20 CET] <friendofafriend> plexigras: Yes, but you'll want to save on CPU time next! [20:45:08 CET] <plexigras> friendofafriend: true, do you know where i can read about compression in the documentation? [20:45:59 CET] <friendofafriend> When you say "compression", what do you mean? Available codecs? [20:48:02 CET] <plexigras> i am after reducing file size :) [20:48:12 CET] <friendofafriend> Compression comes down to codec and quality settings. It's mostly about how much CPU time you're willing to use, and how good looking the result needs to be. [20:49:06 CET] <friendofafriend> The best recommendation would probably be to scale the video down to a lower resolution. [20:49:56 CET] <friendofafriend> And then reencode with something hardware accelerated, like NVENC. [21:07:39 CET] <plexigras> friendofafriend: i'm trying around with different codecs but i can't really see a difference in file size what codecs do you recommend i try? [21:18:21 CET] <friendofafriend> plexigras: It would be best to use something hardware accelerated by your system. [21:19:32 CET] <plexigras> okay i will keep looking and if nothing better comes up i will just stick with libx264 [21:20:04 CET] <friendofafriend> If you just need to reduce your file size, try scaling down. You'll have to make a compromise somewhere. ;) [21:44:56 CET] <Mavrik> Umm. [21:45:08 CET] <Mavrik> Does NVENC come close to x264 yet? [21:45:53 CET] <pink_mist> how could it ever? [21:46:10 CET] <pink_mist> isn't it hardware-based? [21:46:35 CET] <pink_mist> literally replacing the hardware is the only way to improve it, isn't it? [21:49:17 CET] <Mavrik> Well there are several generations of the encoding block. [21:49:55 CET] <Mavrik> I was just wondering about the recommendation to use it for non-live content, since using HW encoders for that is usually a large waste of quality. [21:50:46 CET] <pink_mist> I have no idea what improvements newer variants have made over older variants, but it is certainly not on par with x264 for quality [21:51:41 CET] <Mavrik> "Sixth generation NVENC implements HEVC 8K encoding at 30FPS, HEVC B-Frames support and provides up to 25% bitrate savings for HEVC and up to 15% bitrate savings for H.264." [21:51:50 CET] <Mavrik> Hm, wonder if anyone did an actual comparison somewhere. [21:53:12 CET] <furq> "up to" doubtless doing a lot of work there [21:55:34 CET] <Mavrik> Yeah, although considering the rather huge lag in quality, I wouldn't be surprised if they managed to fix some low hanging fruits. [22:20:40 CET] <BtbN> Turing h264 nvenc is okayish, but it's still not x264 [23:14:09 CET] <scriptease> evenings [23:14:45 CET] <scriptease> found some strange behavoiur with ffmpeg...maybe someone can help... [23:15:20 CET] <scriptease> http://prntscr.com/m6r0ly [23:16:13 CET] <scriptease> the movie contains a german stream and i transcoded with... [23:16:14 CET] <scriptease> ffmpeg -hwaccel qsv -i "%%a" -metadata:s:a:0 language=ger -c:v hevc_qsv -load_plugin hevc_hw -preset slow -rc vbr_hq -b:v 3M -maxrate:v 6M -c:a copy -y "D:\Movie Convert\newfiles\%%~na.mkv" [23:16:39 CET] <scriptease> i tried to force german language on stream 1 with "-metadata:s:a:0 language=ger" [23:16:48 CET] <scriptease> but this didnt help [23:16:58 CET] <scriptease> it still uses english language [23:17:09 CET] <scriptease> any ideas? [23:36:08 CET] <scriptease> ok found it [23:36:14 CET] <scriptease> (missed "-map 0") [23:36:24 CET] <scriptease> thx for your attention [23:36:27 CET] <scriptease> ^ [23:38:56 CET] <Mavrik> Happy rubber duckies :) [23:39:44 CET] <scriptease> :-) [00:00:00 CET] --- Mon Jan 14 2019

1 0

ffmpeg-devel.log.20190112
by burek 13 Jan '19

13 Jan '19

[02:25:33 CET] <cone-016> ffmpeg 03Michael Niedermayer 07master:e94288c4932e: avcodec/nuv: add FF_CODEC_CAP_INIT_CLEANUP [02:25:33 CET] <cone-016> ffmpeg 03Linjie Fu 07master:5764c9528b97: lavc/hevc_parser: report detailed log when missing picture occurs [09:40:04 CET] <cone-817> ffmpeg 03Peter Ross 07master:ad0d5d7516dc: avcodec/dstdec: use appropriate alignment [13:18:24 CET] <pross> bit-exact vp6 achieved. now time to do something actually productive. [13:18:35 CET] <JEEB> najs [13:19:19 CET] <JEEB> yea, I got back from my holidays and I'll probably start poking at stuff I want to work with again [13:20:32 CET] <pross> classic On 2 style code reuse. VP 3/4/5/6 codecs all use the same loop filter design. [13:20:40 CET] <pross> cool! [13:20:54 CET] <durandal_1707> lies, lies and lies [13:21:23 CET] <JEEB> https://github.com/jeeb/ffmpeg/commits/mpegts_arib_stuff [13:21:27 CET] <JEEB> rebased this while on flight :D [13:23:47 CET] <Compn> pross : fixes all vp6 artifact bugs? :) [13:24:18 CET] <Compn> hmm http://trac.ffmpeg.org/ might be down ? [13:24:41 CET] <Compn> pross : http://trac.ffmpeg.org/ticket/6149 [13:26:25 CET] <Compn> interlaced vp6 http://trac.ffmpeg.org/ticket/5581 [13:28:17 CET] <Compn> this was the old bug i was thinking of though http://trac.ffmpeg.org/ticket/1282 [13:28:38 CET] <Compn> thought there was another one too hmm [13:28:57 CET] <Compn> oh you commented on that one :D [13:29:08 CET] Action: Compn goes back under his rock to wake up [13:30:38 CET] <pross> Compn: yes, artifacts all gone! interlaced support, hell no. [13:32:01 CET] <durandal_1707> pross: have you split codec? introducing new id? [13:32:27 CET] <JEEB> &41 [13:33:02 CET] <Compn> JEEB : the subtitle people will love you :D [13:33:12 CET] <Compn> or is it caption heh [13:33:44 CET] <durandal_1707> Compn: you are getting older and older [13:35:56 CET] <pross> durandal_1707: updated patch not ready yet. i wanted to understand the vp5/6 loop filter first [13:38:47 CET] <Compn> durandal_1707 : its just my buffer is full. need to flush cache [13:42:07 CET] <Compn> durandal_1707 : guy replied to your question http://trac.ffmpeg.org/ticket/959 [13:51:57 CET] <JEEB> Compn: same thing, basically :) text stuff is generally in broadcast called captions, I guess? (see: DVB subs being pictures) [13:52:21 CET] <JEEB> although teh funny thing with ARIB captions is that not only you have styling and positioning, but also you have in-band images [13:52:32 CET] <JEEB> not sure if I want to go that far, but I've seen OSS implementations of it :) [13:54:23 CET] <BtbN> Did the coverity tool download URL change or something? [13:57:22 CET] <atomnuker> lol, vp6 supported interlacing? [14:00:46 CET] <durandal_1707> no more coverity crap mails - finally freedom! [15:24:19 CET] <BtbN> https://community.synopsys.com/s/article/Coverity-Scan-Update oh, it's actually dead for now [15:44:42 CET] <nevcairiel> again? [15:45:01 CET] <BtbN> Their hoster has vanished from the face of earth or something [16:17:31 CET] <cone-614> ffmpeg 03Paul B Mahol 07master:f4fd8ef725a8: avfilter/af_anlmdn: rework how denoising strength is used [16:45:55 CET] <cone-614> ffmpeg 03Jerome Borsboom 07master:96740ec69f27: avcodec/vc1: shuffle calculation of MV predictor candidates [16:45:56 CET] <cone-614> ffmpeg 03Jerome Borsboom 07master:b6402278322d: avcodec/vc1: fix decoding of old WMV3 format [16:47:31 CET] <cone-614> ffmpeg 03Michael Niedermayer 07master:f9728feaf90e: avcodec/exr: Check for duplicate channel index [16:47:32 CET] <cone-614> ffmpeg 03Michael Niedermayer 07master:433d2ae4353f: avcodec/exr: set layer_match in all branches [16:47:33 CET] <cone-614> ffmpeg 03Michael Niedermayer 07master:77e56d74f972: avcodec/h264_slice: Fix integer overflow in implicit_weight_table() [17:18:05 CET] <cone-614> ffmpeg 03Carl Eugen Hoyos 07master:261e4cf03f9a: lavc/psd: Support CMYK images. [17:30:29 CET] <cone-614> ffmpeg 03Carl Eugen Hoyos 07master:90ab9a58ff69: lavc/tiff: Support CMYK images. [17:33:37 CET] <cone-614> ffmpeg 03Carl Eugen Hoyos 07master:2e8b0446c679: lavc: Allow very high bitrates in AVCPBProperties after next version bump. [18:07:01 CET] <JEEB> 9 [18:11:21 CET] <BtbN> Unless someone gets me one of those cards, there won't ever be much I can do in those extreme edge cases... [18:11:35 CET] <BtbN> 40 parallel streams. [18:12:27 CET] <BtbN> Also no idea what "ffmpeg was work unstable" is supposed to mean. [18:12:34 CET] <durandal_1707> https://whoislewys.com/2018/10/18/audio_norm_guides_are_evil_and_immoral/ ----> what i should write there in comments? [18:25:39 CET] <BtbN> what? [18:25:55 CET] <ePirat> o_o [18:43:26 CET] <kurosu> pross: so you checked the old vp6 ticket, and confirmed it is the in-loop filter? [18:43:50 CET] <kurosu> pross: also, bitexact, meaning you checked against the binary decoding (using eg mplayer loader) ? [19:52:18 CET] <cone-614> ffmpeg 03Paul B Mahol 07master:1ea5529dd260: avfilter: add maskfun filter [20:07:11 CET] <durandal_1707> atomnuker: when you finish fft/dct ? [20:23:09 CET] <Compn> ehe kurosu also does not believe bit exact vp6 :D [20:23:12 CET] <Compn> same as me [20:26:30 CET] <durandal_1707> Compn: why are you still connected? [20:46:09 CET] <Compn> durandal_1707 : mplayer isnt dead yet :D [20:47:52 CET] <durandal_1707> Compn: it's dead, and you can't do shit [21:02:46 CET] <kurosu> Compn, I'm not saying this or believing that [21:03:02 CET] <kurosu> just that if he is saying this, he has tested something, and it improved [21:03:08 CET] <kurosu> (besides vp4) [21:03:54 CET] <kurosu> bye [23:14:02 CET] <j-b> durandal_1707: do you know if AAC-ELD is supported? [23:17:50 CET] <JEEB> there was some type of AAC with a very specific sample count which wasn't supported in the lavc decoder [23:18:44 CET] <nevcairiel> AAC ELD should be supported for decoding [23:19:04 CET] <JEEB> ok [23:19:13 CET] <nevcairiel> although perhaps not necessarily all bitstream features [23:19:57 CET] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=b3be41ca82529d60f90107… [23:20:10 CET] <nevcairiel> the 960 transform was since added [23:20:13 CET] <nevcairiel> not sure about the others [00:00:00 CET] --- Sun Jan 13 2019

1 0

ffmpeg.log.20190112
by burek 13 Jan '19

13 Jan '19

[00:13:49 CET] <scriptease> is there a qsv h265 encoder for ffmpeg? [00:14:00 CET] <scriptease> ffmpeg -hwaccel qsv -c:v h265_qsv doesnt work [00:29:51 CET] <analogical> Hi. Does anyone know how to you download all the videos from a youtube playlist? [00:30:45 CET] <iive> analogical, `youtube-dl` has such feature [00:31:41 CET] <iive> scriptease, is qsv the intel acceleration? is h265 encoding supported by your hardware? does h264 work? [00:31:47 CET] <analogical> iive, I've tried youtube-dl but I don't understand how to download all the videos in the playlist [00:32:48 CET] <scriptease> yes [00:33:46 CET] <scriptease> i tried qsv hevc with xmedia recode [00:33:49 CET] <scriptease> and it worked [00:34:04 CET] <scriptease> its a new bean canyon intel nuc [00:35:55 CET] <iive> scriptease, do you get an error? do you see the encoder in `ffmpeg -encoders | grep qsv` [00:36:15 CET] <iive> analogical, just give the url of the playlist? just the playlist. [00:37:55 CET] <scriptease> ok i got it [00:38:08 CET] <scriptease> ffmpeg -hwaccel qsv -i "imput.mkv" -c:v hevc_qsv [00:38:09 CET] <scriptease> was it [00:38:30 CET] <iive> scriptease, great ! [00:38:35 CET] <scriptease> *input [00:38:56 CET] <analogical> iive, https://www.youtube.com/watch?v=AIbzmHBw4NY&list=PLT0hfPWJS6_ssS2DrtMQ7zhvN… [00:39:42 CET] <iive> analogical, i think old youtube-dl help was more useful... let me try myself. I've done it before [00:40:31 CET] <scriptease> *damn...cuda is 4 times faster! [00:40:51 CET] <Retr0id> When I try to use ffmpeg to download a CENC encrypted DASH stream, it a) doesn't decrypt anything b) doesn't preserve the "senc" atoms or other atoms required to decrypt later. e.g.: [00:41:08 CET] <Retr0id> ffmpeg -i 'https://bitmovin-a.akamaihd.net/content/art-of-motion_drm/mpds/11331.mpd' -decryption_key 100b6c20940f779a4589152b57d2dacb -c copy -map 0:6 foo.mp4 [00:41:15 CET] <Retr0id> (note, that is a public testing key) [00:41:39 CET] <Retr0id> if I run the same command, but on a single .ts file from the stream, it decrypts fine [00:41:52 CET] <Retr0id> anyone know what I'm doing wrong? [00:42:10 CET] <iive> scriptease, new nvidia special encoder is a beast. pro card can encode over 16 HDTV channels at once. [00:45:56 CET] <scriptease> ? [00:46:05 CET] <scriptease> what do i need? [00:46:56 CET] Action: scriptease got an old gtx 960 [00:48:02 CET] <iive> analogical, yes, just giving the URL seems to work, there is however a catch. if you don't escape the '&' bash would accept it as command and drop the rest of the url, including the part with the list [00:49:09 CET] <analogical> iive, please pase a working link [00:49:16 CET] <analogical> paste* [00:49:45 CET] <iive> analogical, you can also remove the v=xxx& part entirely. youtube-dl will pick it. [00:50:44 CET] <analogical> iive, please paste a working link [00:51:04 CET] <iive> just a moment. [00:51:04 CET] <analogical> so I can see what you did [00:51:46 CET] <scriptease> iive what do you mean with "new nvidia special encoder"? [00:52:21 CET] <scriptease> ah ic [00:52:28 CET] <scriptease> new OBS and RTX encoder [00:52:41 CET] <iive> analogical, `youtube-dl -s https://www.youtube.com/watch?list=PLT0hfPWJS6_ssS2DrtMQ7zhvNU-11JY6i` [00:55:25 CET] <iive> scriptease, might be the same one you call cuda. the thing is that it doesn't use general purpose shaders, but a dedicated silicon for encoder. [00:55:44 CET] <iive> analogical, ops... I used "-s" to avoid downloading the videos [00:55:59 CET] <analogical> np [00:56:08 CET] <iive> replace it with proper "-f" for the video quality you want. [00:56:09 CET] <analogical> iive, you removed v=AIbzmHBw4NY& and now it works [00:56:28 CET] <analogical> strange that youtube-dl doesn't understand this [00:56:35 CET] <iive> analogical, as I said, usually the problem is bash using & as command. [00:56:45 CET] <analogical> I'm on windows [00:56:50 CET] <iive> oh... [00:56:57 CET] <analogical> but the same is true here [00:57:01 CET] <analogical> obviously [00:58:46 CET] <analogical> iive, thanks! :D [00:59:19 CET] <iive> analogical, i'm glad I could help. [00:59:31 CET] <Retr0id> Sooo, anyone have advice on how to download a .mpd DASH stream while preserving the encryption metadata (senc atoms etc.)??? [01:00:03 CET] <iive> btw the syntax for -f is "-f <video>+<audio>" in case you want better than 1280x720 [01:00:35 CET] <iive> Retr0id, unfortunately I don't have an idea. the regular helpers seem to be away. [01:01:18 CET] <Retr0id> haha, what times of day are the regular helpers usually here? [01:01:41 CET] <scriptease> the rtx 2060 is still expensive and i dont use the pc for gaming anymore. wouldnt make sense for me to buy such a card just for encoding. i guess there would be better hardware like xilinx cards or streaming boxes. im a bit confused about the low speed of ffmpeg qsv so far. with xmedia recode it was much much faster [01:02:09 CET] <iive> Retr0id, if you use latest ffmpeg release you might want to fill a bug. or ask again later. [01:02:36 CET] <iive> Retr0id, to be honest... no idea (about time)... [01:02:52 CET] <iive> scriptease, rtx is overkill. [01:02:57 CET] <Retr0id> well, I don't know if it's a bug or not tbh [01:03:08 CET] <Retr0id> it's probably just me doing something wrong [01:04:22 CET] <iive> scriptease, on nvidia site, they say maxwell (2gen) can do hevc encoding.( strangely, no decoding). [01:04:45 CET] <scriptease> but the new encoder is only working with the rtx cards?! [01:05:13 CET] <iive> scriptease, it's relatively new... few years. [01:05:56 CET] <scriptease> and does ffmpeg make use of it? [01:06:08 CET] <scriptease> same encoder? [01:06:13 CET] <iive> scriptease, yes [01:07:03 CET] <scriptease> well iv got a gtx960 [01:07:10 CET] <scriptease> thats the 1st gen maxwell [01:07:21 CET] <scriptease> 2nd gen would be gtx 970 [01:08:09 CET] <iive> 1st gen gets only h264 encoding. and decoding mpeg1 to 4 (h264 included) [01:08:25 CET] <scriptease> nah [01:08:49 CET] <scriptease> i can encode h265 with my gtx 960 [01:08:57 CET] <scriptease> using cuda [01:09:19 CET] <iive> that's what i'm saying. cuda is using general purpose shaders [01:09:31 CET] <iive> the encoder is specialized module [01:09:48 CET] <iive> try encoding h264_nvenc and see if it is faster. [01:10:13 CET] <scriptease> mhm but i wont get the vids so small with h264 [01:10:24 CET] <furq> the gtx960 is second-gen maxwell [01:10:24 CET] <iive> just try it :D [01:10:29 CET] <furq> gm206 [01:10:42 CET] <scriptease> *ah ok [01:10:55 CET] <furq> pascal and turing both claim efficiency improvements but who knows how significant they are [01:11:28 CET] <iive> furq, there are actually two cards named gtx960 [01:11:36 CET] <scriptease> https://www.nvidia.com/en-us/geforce/news/geforce-rtx-streaming/ [01:11:46 CET] <furq> well one is 206 and one is 204 [01:11:49 CET] <furq> they're both second-gen [01:12:01 CET] <furq> first-gen is GM1xx [01:12:04 CET] <iive> one is OEM and is GM204, the other is just 960 and is GM206 [01:12:13 CET] <iive> the gm206 is like 3'd gen. [01:12:27 CET] <furq> second gen nvenc, then [01:13:57 CET] <scriptease> but i wonder why qsv is so slow with ffmpeg and my new bean canyon (nuc5i7bek) [01:14:11 CET] <scriptease> with xmedia recode it was about 3 or 4 times faster [01:14:45 CET] <furq> i take it you're using hardware decoding [01:15:01 CET] <furq> and not doing anything that would cause a bunch of copying [01:16:09 CET] <scriptease> hardware encoding [01:16:38 CET] <scriptease> i try different hardware...intel quicksnc on my barebone and the 960 gtx on my desktop pc [01:17:08 CET] <scriptease> with xmedia recode the quicksync was faster than the cuda encoding [01:17:21 CET] <scriptease> with ffmpg it just turned [01:17:24 CET] <iive> scriptease, if you card is GM206, then you have hevc encoding and decoding. [01:17:33 CET] <iive> you/your [01:17:38 CET] <scriptease> i have hevs encoding [01:17:40 CET] <scriptease> i know that [01:17:53 CET] <scriptease> as i said...i used xmedia recode before [01:17:57 CET] <scriptease> and everything worked [01:18:06 CET] <scriptease> *hevc encoding [01:18:26 CET] <iive> actually, 2gen Maxwell does not have hevc decoding.. [01:18:33 CET] <scriptease> cuda encoding also works now on my dektop pc using ffmpeg [01:18:50 CET] <scriptease> exactly iive ....decoding didnt work [01:20:41 CET] <scriptease> there is something wrong with intel qsv in ffmpeg [01:20:44 CET] <iive> furq, in the wikipedia list, only GT945A is listed as GM108, no other GM1xx cards. [01:20:59 CET] <furq> scriptease: i meant were you doing both decoding and encoding in hardware with ffmpeg [01:21:08 CET] <furq> software decoding will slow down hardware encoding quite a bit [01:21:15 CET] <furq> maybe not 3x but shrug [01:21:33 CET] <furq> i can't think of any other reason why ffmpeg would be that much slower unless it's setting very different defaults [01:21:50 CET] <scriptease> furq...no...as iive said...hevc-decoding didnt work...but hevc-encoding works with the gtx 960 [01:22:19 CET] <scriptease> nah i talk about different hardware here [01:22:29 CET] <iive> scriptease, furq means, that you should be using hardware decoding (e.g. h264) AND hardware encoding. [01:22:38 CET] <scriptease> i made a comparison using my barebone and my desktop pc [01:23:02 CET] <scriptease> the barebone uses intel hardware acceleration and the desktop pc uses nvenc [01:23:19 CET] <iive> intel is "meh" [01:23:21 CET] <furq> yeah i meant with qsv [01:23:27 CET] <furq> that's the one you said was much slower with ffmpeg right [01:23:36 CET] <scriptease> yep [01:23:44 CET] <scriptease> and with xmedia recode it was MUCh faster [01:24:20 CET] <scriptease> thats why i say there is something wrong with the utilisation of intel quicksync in ffmpg [01:24:54 CET] <scriptease> *ffmpeg [01:25:36 CET] <scriptease> yeah iive....hardware decoding AND encoding would be better ofc [01:32:22 CET] <scriptease> http://prntscr.com/m62vwg [01:34:51 CET] <scriptease> http://prntscr.com/m62wqv [01:37:20 CET] <iive> scriptease, https://developer.nvidia.com/ffmpeg :D [01:40:50 CET] <scriptease> yep [01:40:53 CET] <scriptease> know that site [01:40:56 CET] <scriptease> :-) [07:15:26 CET] <Gambit-_> Hello everyone again [07:16:23 CET] <Gambit--> I am trying to add keyframes to a video so as to get smaller segmentation on HLS generation. Right now, despite all of my efforts, the HLS generation process generates 8 fragments and reports "frame I:8" in the summary output. [07:17:10 CET] <Gambit--> I tried to create more keyframes using this command line: ffmpeg -I in.mp4 -force_key_frames "expr:eq(mod(n, ${GOPSZ}),0)" -x264opts rc-lookahead=${GOPSZ}:keyint=${GOPSZ_2X}:min-keyint=${GOPSZ} out.mp4 [07:17:20 CET] <Gambit--> (with GOPSZ=30 and GOPSZ_2X=60) [07:17:27 CET] <Gambit--> this was as per a SO post I can di gout. [07:17:59 CET] <Gambit--> the resulting file, when I count how may keyframes there are using show_entries frame=pict_type, has the expected 30 frames of type "I". [07:18:50 CET] <Gambit--> But that doesn't sync with the output from the HLS generation command: ffmpeg -I out.mp4 -hls_playlist_type vod -hls_flags single_file -hls_init_time 2 -hls_time 2 -hls_list_size 0 -hls_segment_filename main.ts test.m3u8 [07:19:38 CET] <Gambit--> (those -I should be -i, in those command lines, fwiw) [07:19:48 CET] <Gambit--> Thoughts? Suggestions? [07:20:25 CET] <c_14> well, you're reencoding the hls output [07:20:39 CET] <Gambit--> How's that? [07:20:51 CET] <furq> why are you setting keyint to gopsz*2 [07:20:52 CET] <c_14> the command that generates your hls reencodes the input [07:21:35 CET] <Gambit--> furq: magic incantation specified in a SO post - but the summary was that min_keyint (at that point in time) was hardcoded to be no less than keyint/2+1 [07:23:07 CET] <Gambit--> Here's the thread: https://superuser.com/questions/908280/what-is-the-correct-way-to-fix-keyfr… [07:25:25 CET] <Gambit--> The stream I'm working with appears to be the right type: [07:25:26 CET] <Gambit--> Stream #0:0(und): Video: h264 (libx264), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=-1--1, 30 fps, 90k tbn, 30 tbc (default) [07:33:01 CET] <Gambit--> c_14: I'm still missing what you mean. Are you suggesting I need to put all of the force_key_frame stuff in the same command that generates the hls? [07:33:17 CET] <c_14> either that (and then don't reencode beforehand) or use -c copy [07:34:31 CET] <Gambit--> Huh. [07:34:47 CET] <Gambit--> Well how about that. [07:34:52 CET] <Gambit--> Thanks c_14! [07:35:04 CET] <Gambit--> I would never have guessed that would have been necessary. [07:35:55 CET] <Gambit--> which has actually described every solution to a FFmpeg problem I've encountered to date :D [07:38:13 CET] <c_14> ffmpeg will by default always reencode your content unless you explicitly tell it not to [12:31:54 CET] <Kadigan> Hey. I'm looking through the "building ffmpeg" guides, and googling... and I'm having trouble finding a guide how to build ffmpeg -for- Windows. Not -on- Windows, -for- it. Under Debian, specifically. Does anyone have a good guide handy, perchance? For now I'm following a guide to build it for Linux, as I'll want the experience + a workable latest there. [12:32:20 CET] <Kadigan> If it's further down in the official guide, don't hesitate to call me a blind hobo. :) [12:33:13 CET] <JEEB> you just need to set/enable cross-compile, target-os and cross-prefix [12:33:49 CET] <JEEB> you can see if the mingw-w64 toolchain in debian is new enough, the one in fedora was generally OK but the headers and CRT were too old for a lot of newer APIs [12:34:13 CET] <JEEB> also you want to make sure that only the static versions of the CRT and C++ stdlib are available to the toolchain [12:34:24 CET] <JEEB> as otherwise it will end up requiring the gcc DLLs on runtime :P [12:35:56 CET] <JEEB> then just make sure you have new enough nasm installed and the very basic FFmpeg should be buildable (which means 99% of all decoders etc) [12:36:19 CET] <JEEB> external libraries are generally just required for encoding, and you generally should know which encoders you need, if any [12:37:54 CET] <JEEB> for example for 64bit windows I usually use something like --arch=x86_64 --enable-cross-compile --target-os=mingw64 --cross-prefix="x86_64-w64-mingw32-" [12:38:24 CET] <JEEB> which tells FFmpeg's build system to utilize the tools that are prefixed with x86_64-w64-mingw32- [12:55:45 CET] <Retr0id> Anyone have advice on how to download a .mpd DASH stream while preserving the encryption metadata (senc atoms etc.)? [12:57:21 CET] <Kadigan> JEEB: I'm following the guide to build under Ubuntu, and I'm generally building things directly instead of installing them (Debian is known to stick to stable, read - old, stuff). So I should have stuff new enough... hopefully. Thank you for the advice, appreciate it. [12:58:41 CET] <Kadigan> I'm building to encode (mainly x264 and, newly, x265), but yeah - I generally know what I need for x264... we'll see what I need for x265 :D [12:59:20 CET] <Kadigan> Mainly because my Windows build is from 2014 :D [13:09:50 CET] <JEEB> Kadigan: x265 is just cmake + C++ + nasm [13:21:08 CET] <Kadigan> Hm... I obviously have no idea what I'm doing, sadly. I have the Linux binary up and going, but building for Windows isn't something I've ever done under Linux... So yeah, way out of my depth here. :) [13:22:09 CET] <JEEB> you just need a mingw-w64 toolchain aiming either for i686 or x86_64 windows [13:22:32 CET] <JEEB> also if you want a thing with a toolchain that some other place is already using, look into videolan's docker registry [13:22:41 CET] <JEEB> they are using docker images to build their windows etc binaries [13:22:57 CET] <JEEB> and/or you can look at their dockerfile and see which things they build and which they just install [13:26:20 CET] <Kadigan> Hm... Well, https://ffmpeg.org/platform.html#Cross-compilation-for-Windows-with-Linux-1 says I only need to reconfigure ffmpeg, but it fails finding libass, so I obviously need to do something about that as well. [13:26:35 CET] <Kadigan> Unless I don't need libass for the Win64 build. [13:26:41 CET] <JEEB> uhh [13:27:04 CET] <JEEB> what libraries you need depends on your needs, and you need those for the matching mingw-w64 target [13:27:10 CET] <JEEB> lunix binaries naturally will not work [13:27:17 CET] <Kadigan> Yeah, figured. [13:27:43 CET] <JEEB> what I generally do is I have some sort of custom prefix for each cross-compilation target [13:27:57 CET] <JEEB> then I set --prefix towards it when configuring things [13:28:11 CET] <JEEB> and then PKG_CONFIG_LIBDIR=/path/to/that/prefix/lib/pkgconfig tells pkg-config to look for things there [13:28:28 CET] <JEEB> PKG_CONFIG_PATH *appends*, PKG_CONFIG_LIBDIR *replaces* [13:28:37 CET] <JEEB> and when you're cross-compiling you don't want your system libraries to pop up :) [13:28:57 CET] <JEEB> (which are of course lunix, not mingw-w64 win32 or win64) [13:34:49 CET] <Kadigan> https://hub.docker.com/r/moiamond/ffmpeg-windows-build-helpers/ here's something that might work. Once I have a running build, I'll look into how it works. [13:35:01 CET] <Kadigan> Assuming I get one. [13:53:09 CET] <JEEB> Kadigan: for docker containers I recommend the videolan ones for a toolchain base [13:53:18 CET] <JEEB> then you can run of course an FFmpeg build on top of that [14:24:51 CET] <kolesovdv> Hello. Can anybody help me? I need to use option "aac_seq_header_detect" via Dictionary (av_dict_set). [14:25:09 CET] <kolesovdv> For ffplay it is used in the next form "-flvflags aac_seq_header_detect". Can someone show example how to use it via av_dict_set? I think about using it in the avio_open2 but I am not sure. [16:23:17 CET] <Kadigan> Hm... it seems it fails on AX_SPLIT_VERSION for me, something to do w/ libtesseract from what I found on a (Chinese? Korean?! xD) website... Do I need Tesseract for something specific? [18:16:26 CET] <pixelou> Hi, I'm trying to use the C API to read video frames but I can't decode the frames with the new decoding API (av_read_frame, avcodec_send_packet). I have taken inspiration from a few examples online but it fails on avcodec_send_packet. Could anybody have a look at my code please? The error message is written at the bottom: https://pastebin.com/raw/evXQXmmz [18:20:56 CET] <DHE> pixelou: does the input file contain audio as well as video? [18:21:14 CET] <kepstin> yeah, that's my guess as well - you're passing an audio frame to the video decoder. [18:21:36 CET] <pixelou> yes, it has both (big buck bunny trailer). [18:21:56 CET] <DHE> and you're not discriminating what comes out of av_read_frame() before feeding it to the video decoder [18:22:37 CET] <DHE> the AVPacket has a stream_index (sp?) that will tell you if it's the audio or video, which matches the stream_idx from your call to https://pastebin.com/raw/evXQXmmz [18:22:42 CET] <DHE> oops, copy/paste fail... [18:22:54 CET] <DHE> av_find_best_stream [18:23:46 CET] <pixelou> Ok thanks, I will fix that. [18:44:36 CET] <pixelou> Well it now fails with 'Resource temporarily unavailable' after reading one empty packet: https://pastebin.com/raw/2v6qmGNx [18:46:36 CET] <pixelou> Note that I'm not sure I have clearly understood the api documentation about memory management with av_packet_unref. [18:50:13 CET] <kepstin> looks like a logic error - when the avcodec_receive_frame function returns AVERROR(EAGAIN), you need to loop back and get another packet to feed to the decoder [18:50:22 CET] <kepstin> but your code treats that as an error case and exits [18:55:51 CET] <pixelou> Indeed, I misinterpreted the documentation, I think I will do a more careful reread of the doc before asking another question. Thank you very much for your help. [19:53:15 CET] <Kadigan> Okay... [19:53:20 CET] <Kadigan> How the hell do I pass deblock to x265? :D [19:54:20 CET] <Kadigan> I'm aware I need to pass them in -x265-params "string", in the format of option=value separated by : [19:54:29 CET] <Kadigan> but how do I pass deblock, which itself is in format x:x? [19:56:01 CET] <c_14> escape it, either with \ or '' [19:56:12 CET] <c_14> probably anyway [19:56:34 CET] <Kadigan> Yes, that worked. I didn't think of that. Thank you. [20:19:56 CET] <Kadigan> (specifically, \ worked -- I failed to mention this) [22:27:40 CET] <BtbN> Does ffmpeg have some automatic way to do stinger transitions? [22:28:35 CET] <BtbN> As in, play one video, overlay the end of it with a transparent video, in the middle of that overlay-video cut to the next video, also overlaid with the stinger video [22:30:39 CET] <BtbN> All I can think of would end up with a _massive_ non-generic complex filter chain [22:30:57 CET] <BtbN> And I want to do this for hundreds of videos [22:32:41 CET] <furq> what about concat,overlay=enable [22:33:56 CET] <BtbN> Hm yeah, I could just concat them, and then overlay the stinger at the right time [00:00:00 CET] --- Sun Jan 13 2019

1 0

ffmpeg-devel.log.20190111
by burek 12 Jan '19

12 Jan '19

[11:46:13 CET] <pross> what is the going rate for a working photocd decoder? [11:47:26 CET] <durandal_1707> what? [11:47:54 CET] <funman> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/238711.html [11:49:07 CET] <durandal_1707> it is between me and Carl [11:49:23 CET] <pross> ack [11:49:39 CET] <funman> I'll have it known Carl is a good paying customer [11:49:54 CET] <durandal_1707> lol [11:56:27 CET] <cone-133> ffmpeg 03Paul B Mahol 07master:0c0fc8896cdd: avfilter/af_anlmdn: log used parameters [11:56:28 CET] <cone-133> ffmpeg 03Paul B Mahol 07master:b5ae61d2c0ae: avfilter/af_anlmdn: do not trim first samples [11:56:29 CET] <cone-133> ffmpeg 03Paul B Mahol 07master:c563513fdf72: avfilter/af_anlmdn: drain samples at end [12:44:31 CET] <durandal_1707> what solutions you will always use to stream audio & video? [12:55:43 CET] <funman> upipe [12:56:16 CET] <durandal_1707> upipe is just component its not full solution [12:58:31 CET] <durandal_1707> repeat untrue statement until it becomes truth - that is new multimedia world [12:58:34 CET] <kierank> there is uplay.c [12:58:41 CET] <kierank> the examples do many things [12:58:50 CET] <JEEB> yea, upipe is a framework [12:59:59 CET] <durandal_1707> so FFmpeg now lies in web page when it claims its full solution to stream? [13:00:17 CET] <JEEB> why? [13:00:25 CET] <durandal_1707> ffserver is gone [13:00:31 CET] <JEEB> uhh [13:00:36 CET] <JEEB> I'm not even going to go there [13:00:50 CET] <JEEB> because there's the stuff you can do with FFmpeg's libraries by itself [13:00:52 CET] <JEEB> like UDP multicast etc [13:01:02 CET] <JEEB> and then you have the stuff where you at the very least need something like nginx [13:01:11 CET] <JEEB> f.ex. DASH/HLS HTTP POST output [13:01:39 CET] <JEEB> adn generally speaking you really don't want to do the media serving with your encoder :| [13:01:55 CET] <durandal_1707> so we lie? [13:01:58 CET] <JEEB> no? [13:02:22 CET] <JEEB> like if you only want to do something 100% FFmpeg's libs then UDP multicast or so is one 100% valid example [13:02:40 CET] <JEEB> and not like you could do HLS/DASH with ffserver [13:02:50 CET] <JEEB> like seriously, are you just effing with my brain or something? [13:02:58 CET] <durandal_1707> no, sorry [13:03:09 CET] <kierank> JEEB: he's just trolling [13:04:08 CET] <JEEB> I would then recommend taking a course on that from TheFluff [13:04:09 CET] <durandal_1707> no trolling, someone asked my privately is it possible to stream with ffmpeg [13:04:33 CET] <JEEB> yes, yes it is [13:05:04 CET] <kierank> define stream [13:07:17 CET] <durandal_1707> it was not so detailed in its specification [13:14:46 CET] <funman> NAME [13:14:46 CET] <funman> fread, fwrite - binary stream input/output [13:47:06 CET] <cone-133> ffmpeg 03Peter Ross 07master:b4e6d1f597a3: intreadwrite: add AV_RL64A, AV_WL64A [13:47:07 CET] <cone-133> ffmpeg 03Peter Ross 07master:127564b3f114: dstdec: big-endian compatiblity [13:50:45 CET] <durandal_1707> pross: please follow style of other commits in commit log message [16:57:17 CET] <cone-730> ffmpeg 03Paul B Mahol 07master:c65c4ce77365: avfilter/af_anlmdn: do not output more samples than received [19:16:09 CET] <atomnuker> lots of posts today, I guess its because its a friday [19:16:48 CET] <funman> should i re-post my patch with my salary disclosed? [19:17:36 CET] <atomnuker> only if you middle click pasted it by accident and want to blame the primary buffer for existing [19:24:16 CET] <durandal_1707> you will pay for mocking me [19:27:09 CET] <durandal_1707> shit, what i caused... [19:30:04 CET] <kierank> durandal_1707: i'm speechless [20:03:30 CET] <BradleyS> well, that escalated quickly [20:11:50 CET] <gnafu> Ugh! [20:12:31 CET] <gnafu> "I want more [thing]. Do you hate [thing]?" [20:12:37 CET] <gnafu> That is never valid. [20:12:48 CET] <gnafu> "Think of the children" level BS. [20:13:08 CET] <BradleyS> what do you have against the children [20:13:41 CET] <gnafu> BradleyS: Children tend to be transparent and honest to a fault. [20:13:47 CET] <gnafu> ;-) [20:13:54 CET] <BradleyS> ;) [20:16:26 CET] <BradleyS> i understand what people are trying to accomplish with disclosure but seems to me very much like a problem we have here in america [20:16:54 CET] <BradleyS> people think that if they make a law, it will absolutely solve everything [20:17:44 CET] <BradleyS> so we make laws that are utterly unenforceable that people ignore [20:19:44 CET] <BradleyS> of course sponsored works can have ulterior motives and take short cuts, but imho the code review process should identify any potential code issues [20:21:13 CET] <BradleyS> better to focus on improving code review than divisive rule-making imho [20:22:57 CET] <BradleyS> plus it would be just embarrassing to know how much work durandal_1707 has done for only ~17 USD :P [20:24:20 CET] Action: BradleyS gives durandal_1707 a cookie [20:25:30 CET] <gnafu> And a patch should never be rejected just because it was "paid for" by some company or for some purpose the reviewer might disagree with. [20:25:35 CET] <JEEB> yes [20:25:51 CET] <JEEB> if something is not good enough in review technically that's it [20:26:02 CET] <JEEB> there should be no grey area in that IMHO [20:26:18 CET] <JEEB> you have your usual discussion about that with the disagreeing parties [20:26:40 CET] <JEEB> or call out a 3rd party to alleviate problems if it feels like the two parties cannot come to an agreement [20:28:04 CET] <kierank> kylophone: i see you've decided to join the insanity [20:29:00 CET] <JEEB> from one side it's good that people actually responded [20:29:26 CET] <JEEB> the patch in my honest opinion should receive NACKs [20:29:51 CET] <JEEB> if our review process has issues that's not something you fix with something that can't be enforced [00:00:00 CET] --- Sat Jan 12 2019

1 0

ffmpeg.log.20190111
by burek 12 Jan '19

12 Jan '19

[08:03:54 CET] <kingsley> Is it reasonable for the .webm format to need 469 MiB for 15 minutes of 1920x1080 resolution video? [08:05:38 CET] <JEEB> there is no specific magical thing that can tell you anything about that [08:06:22 CET] <JEEB> that's generally why I tell people to use some sort of variable bit rate rate control (like f.ex. crf in x264), and run that on like 2-5 minutes of a clip that contains the kind of content you'll be encoding [08:07:11 CET] <JEEB> and then you can just iterate over rate control values etc [08:07:14 CET] <JEEB> :P [08:07:35 CET] <JEEB> to find the parameters that give you maximum compression for the quality you want [08:07:44 CET] <JEEB> and then you can start using those or similar parameters on your actual clips [14:25:42 CET] <Jaex> Could I get a hostmask sharex/staff/bfnt.xenthys for Xenthys? [14:26:52 CET] <Jaex> oh my lol [14:26:55 CET] <Jaex> i thought i was in #freenode [14:27:08 CET] <Jaex> :facepalm: [14:29:33 CET] Action: Xenthys pats Jaex - it's ok buddy [15:18:13 CET] <atbd> hi, i'm trying to make a transcoding program with ffmpeg api. I succeed to transcode both video and audio but not to sync each other. Can somebody help me or provide example(s) of synchronization? [15:22:32 CET] <Mavrik> Well, you need to keep proper timestamps and write things next to each other on the output. [15:22:37 CET] <Mavrik> The default transcoding example should do that properly. [15:42:28 CET] <atbd> i keep timestamp generated by filtergraph on my frames (av_buffersink_get_frame) and then convert them to stream timebase for the packets. Audio and video then seem right but not synchronized [15:43:51 CET] <Mavrik> If they're not synchronized then the timestamps aren't correct [15:43:56 CET] <Mavrik> Or you're not interleaving packets correctly. [15:44:14 CET] <Mavrik> (e.g. your audio packets are so late that player can't compensate with buffer) [15:54:35 CET] <atbd> I think it comes from timestamps from video filtergraph, they begin at 0 whereas audio timestamp begin at a far greater value [15:57:25 CET] <Mavrik> Did you set timebases and whatnot correctly on filtergraph as well? [16:12:31 CET] <atbd> yes all filtergraph inputs/outputs have correct timebase [16:14:36 CET] <kepstin> the filtergraph stuff doesn't change the timestamps to start at 0 on its own, it'll only do that if there's a filter in the filter graph that's modifying timestamps. [16:15:12 CET] <kepstin> and if you are modifying timestamps in a video filter, you have to also modify the audio to keep stuff in sync :/ [16:24:59 CET] <atbd> my only video filter is for rescale, i'm looking for a pts reset elsewhere which cause my problem [17:08:48 CET] <atbd> thanks for your help, i found my mistake for the video timestamps .) [17:08:53 CET] <atbd> :)* [18:27:38 CET] <tommy``> guys, this is good for encoding .ass? ffmpeg -i file.mp4 -vf "ass=subtitles.ass" file_encoded.mp4 [18:51:15 CET] <scriptease> test [18:51:17 CET] <scriptease> ahh [18:51:19 CET] <scriptease> ^^ [18:53:40 CET] <scriptease> ffmpeg -hwaccel cuvid -i "input 1080p x264.mkv" -c:v hevc_nvenc -preset slow -rc vbr_hq -b:v 6M -maxrate:v 10M "output 1080p x265.mkv" ....returns errors: [18:53:43 CET] <scriptease> [h264 @ 000002aa9bd92c80] decoder->cvdl->cuvidCreateDecoder(&decoder->decoder, params) failed -> CUDA_ERROR_INVALID_VALUE: invalid argument [18:53:53 CET] <scriptease> [h264 @ 000002aa9bd92c80] Failed setup for format cuda: hwaccel initialisation returned error. [18:55:00 CET] <scriptease> using the latest ffmpeg for windows (10/x64) on a geforce 960 [18:55:12 CET] <scriptease> what is wrong here? [18:55:14 CET] <scriptease> ^^ [19:16:26 CET] <kepstin> does 960 even have a hevc encoder? [19:16:30 CET] Action: kepstin looks that up [19:16:42 CET] <scriptease> should work yes [19:18:11 CET] <kepstin> hmm, yeah, that's second gen baxwell, should work with 4:2:0 [19:18:33 CET] <scriptease> so that strin here is correct? [19:18:34 CET] <scriptease> ffmpeg -hwaccel cuvid -i "input 1080p x264.mkv" -c:v hevc_nvenc -preset slow -rc vbr_hq -b:v 6M -maxrate:v 10M "output 1080p x265.mkv" [19:18:37 CET] <scriptease> *string [19:18:38 CET] <kepstin> interesting, that's an error setting up the decoder, not encoder? [19:18:51 CET] <kepstin> scriptease: please share (via pastebin or similar) the complete ffmpeg output [19:18:59 CET] <scriptease> k [19:19:00 CET] <scriptease> 1 mom [19:22:40 CET] <scriptease> https://pastebin.com/iXRdCmAk [19:24:48 CET] <kepstin> wait, so the command is actually working? [19:25:10 CET] <scriptease> it works but it seems to be a "fallback" to software encoder [19:25:21 CET] <kepstin> no, there's no fallback in the encoder [19:25:26 CET] <kepstin> it's falling back to software decoder [19:25:36 CET] <scriptease> yep [19:26:05 CET] <kepstin> no idea why the decoder isn't initializing, it should be fine with a 4:2:0 high stream like that :/ [19:26:20 CET] <scriptease> look at line 112/113 [19:27:03 CET] <kepstin> yes, all that says is "the nvidia driver didn't let us set up the decoder" [19:27:15 CET] <scriptease> but why decoder? [19:27:22 CET] <scriptease> i want to ENcode?! [19:27:33 CET] <kepstin> the encoder works fine [19:27:58 CET] <scriptease> hmm [19:28:00 CET] <scriptease> ok [19:28:03 CET] <kepstin> the set of options you've provided attempts to do hardware decoding then hardware encoding [19:28:06 CET] <scriptease> how do you see that? [19:28:22 CET] <kepstin> the hardware decoder setup is failing, and falls back to software. the hardware encoder works. [19:28:36 CET] <scriptease> but that isnt a prob at all?! [19:29:09 CET] <kepstin> well, i'd expect the hardware decoder to work fine on that video, so it's a bit confusing. [19:29:22 CET] <scriptease> i was also a bit confused because i couldnt find a string for hwaccel in the ffmpeg documentation [19:29:23 CET] <scriptease> https://ffmpeg.org/ffmpeg.html [19:29:40 CET] <scriptease> *for "cuvid" [19:31:10 CET] <scriptease> http://prntscr.com/m5yo2z [19:31:25 CET] <scriptease> there is no information about nvenc (cuda) [19:31:52 CET] <kepstin> probably the docs didn't get updated :/ Does it show up when you run `ffmpeg -hwaccels` ? [19:32:44 CET] <scriptease> yes it does [19:32:45 CET] <scriptease> http://prntscr.com/m5yoqo [19:32:48 CET] <scriptease> :) [19:33:04 CET] <kepstin> https://trac.ffmpeg.org/wiki/HWAccelIntro#NVDECCUVID is the docs for hw decoding/encoding [19:33:22 CET] <scriptease> ah ok [19:33:22 CET] <scriptease> thx [20:05:39 CET] <tommy``> guys do you know if ffmpeg could have problems with long font names during encoding? [20:05:53 CET] <tommy``> i have an .ass file with this style: Style: msg_finale,5aeab475c0663b98150ecfa3bffece2,75,&H00FFFFFF,&H000000FF,&H00000000,&H00000000,-1,0,0,0,100,100,0,0,1,1,1,2,10,10,10,1 [20:07:19 CET] <tommy``> and this is the unique font i can't see in video [20:39:32 CET] <ldm> Hi, I've got a question, can ffmpeg convert from 60fps to 30fps and blend frames? the idea is to add motion blur to make a film shot at 60fps feel more "cinematic" [20:49:11 CET] <kepstin> it can do a simple blend between frames, but the result doesn't really look much like motion blur :/ [20:51:21 CET] <kepstin> "-vf tblend=average,framestep=2" will do it if you want to try. [21:28:52 CET] <ABLomas> hello, need some advice - i'm putting 4 videos from dshow devices into one screen, like this: [21:28:53 CET] <ABLomas> https://pastebin.com/Y9nd0wky [21:30:01 CET] <ABLomas> looks OK, but they desync badly, by ~4 seconds each, probably because ffmpeg buffers first source, then second, then third, last and with buffer this "sequential opening" adds delay compared to each other [21:31:13 CET] <ABLomas> how can i force them to be in sync (for example, any video should not reach filter_complex before others)? I can't kill rtbufsize because then it does not work properly at all [21:44:24 CET] <kepstin> the ffmpeg command line tool isn't designed for this use case. I've heard that some people have hacked this sort of thing into working by having each input handled by a separate ffmpeg command, piping the output to an additional ffmpeg that does the combining. [21:44:48 CET] <kepstin> probably better would be to write an app that uses ffmpeg libraries and does input in threads [22:00:03 CET] <ABLomas> :/ [22:01:01 CET] <ABLomas> i also found similar suggestions on web, but no real success stories. I want just put 4 low-res videos side-by-side (2x2 arrangement), this sounds trivial task for PC but that buffering... [22:17:01 CET] <kepstin> it's not that hard of a problem, tbh, it's just not a use case the ffmpeg cli tool was designed for. [22:17:33 CET] <kepstin> that tool is a batch file processing tool that's been extended over the years to mostly work with some types of realtime processing. [22:21:32 CET] <Gambit-> There we go. [22:21:50 CET] <Gambit-> Hi folks - I'm trying to take several sub selections from a video and concatenate them together [22:22:11 CET] <Gambit-> The Filtergraph I have right now doesn't seem to be working right - it puts a bunch of dead time in the middle. [22:22:35 CET] <Gambit-> ffmpeg -i ../media/in.mp4 -filter_complex "[0]trim=end_frame=20:start_frame=10[s0];[0]trim=end_frame=1050:start_frame=1000[s1];[s0][s1]concat=n=2[s2]" -map [s2] out.mp4 [22:23:05 CET] <Gambit-> I feel like that should produce a video that 's 60 frames long - frames 10-20 followed by frames 1000-1050 [22:23:42 CET] <Gambit-> Suggestions? [22:32:26 CET] <furq> Gambit-: trim=xyz,setpts=PTS-STARTPTS [22:32:33 CET] <furq> for both trims [22:37:43 CET] <Gambit-> furq, do I need to do both setpts and asetpts? [22:40:03 CET] <Gambit-> hm it looks like if I don't do anything with the audio, it will concat the video tracks but completely drop the audio ones. [22:40:08 CET] <Gambit-> That's... frustrating. [22:49:04 CET] <kepstin> Gambit-: if you use a -map option, ffmpeg disables its default mapping and only includes the specified tracks [22:49:51 CET] <kepstin> Gambit-: adding a "-map 0:a" or similar will include the audio again, although it won't be trimmed of course because you're only filtering the video right now. [22:54:21 CET] <Gambit-> huh [22:54:57 CET] <Gambit-> kepstin, what's the minimum I should be looking at? If I remove the map would I get the audio from the two segments by using just [0]trim+setpts? [22:55:22 CET] <kepstin> you need to separately trim the audio using the atrim filter [22:55:37 CET] <kepstin> (and then include it in the inputs to the concat filter, which will need the a=1 option added) [22:56:47 CET] <Gambit-> okay, so I do need the full trim+setpts atrim+asetpts set [22:58:42 CET] <Gambit-> Having all of those trim settings just felt expensive but I guess if it's compiled properly under the hood... [22:59:00 CET] <Gambit-> is there a library version of FFmpeg that avoids any potential command-line-length limitations? [22:59:59 CET] <Gambit-> I'd like to, say, extract a thousand small samples from a large video file and have it output to a stream (it's okay if it's sporadic, as long as it's fast), and stacking it all up from the command line sounds like a recipe for failure. [23:00:37 CET] <kepstin> ffmpeg is built on a set of libraries that can do all the same thing. But for your use case, you probably want to use the "-filter_complex_script" option that lets you load a filter spec from a file. [23:00:55 CET] <Gambit-> Oh that's probably sufficient, yea [23:02:55 CET] <Gambit-> thanks kepstin, that'll probably get me at least to the next hurdle :) [23:06:55 CET] <Gambit-> hm it takes a long time to seek (I assume) to some parts of the file. [23:07:12 CET] <kepstin> trim filter doesn't seek, it discards decoded frames [23:07:21 CET] <Gambit-> ahhh [23:07:35 CET] <kepstin> if you want to seek, you have to use a separate input (or a "movie" filter in the filter chain) with the -ss input option [23:08:50 CET] <Gambit-> ... should I just be using several movie filters instead of trim/atrim? [23:09:48 CET] <Gambit-> or maybe I need to do a movie+trim+atrim for each segment? [23:11:18 CET] <scriptease> kepstin...thx for helping so much btw ;-) [23:11:21 CET] <kepstin> it depends. if you have small segments close together, a single input might be less overhead than multiple inputs [23:11:32 CET] <kepstin> if there's bigger gaps, you'll probably want seeking [23:14:05 CET] <Gambit-> would the general structure be movie+trim+atrim[1], movie+trim+atrim[2], ... [1][2]...concat=n=N? [23:14:27 CET] <Gambit-> or rather [1a] and [1v] for each of those [23:16:07 CET] <kepstin> you can name the filter pads anything you like, just do something you'll be able to understand again later. Note that integers are used to refer to ffmpeg inputs, so it's best to avoid them for pads you name. [23:16:25 CET] <kepstin> i like using stuff like 'v1', 'a1' personally [23:16:28 CET] <Gambit-> sure, sure - but that's the general structure I should be looking at? [23:17:03 CET] <kepstin> a movie filter can read audio+video at the same time, synced, so you probably want something like this: [23:17:06 CET] <scriptease> haha this is funny [23:17:15 CET] <scriptease> didnt know that existed [23:17:15 CET] <scriptease> https://explainshell.com/ [23:18:04 CET] <Gambit-> scriptease: neat! [23:18:48 CET] <kepstin> movie=filename=blah.mp4:sp=12:s=dv+da[v0][a0];[v0]trim,setpts[v0trim];[a0]atrim,asetpts[a0trim];[v0trim][a0trim]...concat=v=1:a=1:n=N [23:19:10 CET] <Gambit-> why dv+da and not v+a? [23:19:16 CET] <kingsley> JEEB: Thank you for taking the time to type in your detailed thoughts on the size of .webm files. [23:19:36 CET] <kepstin> Gambit-: because that's what you specify to tell the movie filter to select the default video and audio tracks. [23:19:42 CET] <Gambit-> ah [23:19:44 CET] <kingsley> Your knowledge and generosity are both fine qualities. [23:20:36 CET] <kingsley> JEEB: I followed your advice. I experimented with render settings in kdenlive. [23:21:16 CET] <Gambit-> huh interesting that didn't work and then I changed the names to exactly match yours and it did work [23:21:24 CET] <Gambit-> I was using mv and ma as the outputs of movie, and it didn't like that. [23:22:12 CET] <kingsley> JEEB: The default setting of kdenlive's video quality slider rendered 5 seconds of 1920x1090 into 4.3 megabytes. [23:23:17 CET] <kingsley> JEEB: Setting kdenlive's video quality slider to 45 rendered 5 seconds of 1920x1090 into 3.2 megabytes. [23:23:48 CET] <kingsley> JEEB: Setting it to 15 rendered 5 seconds of 1920x1090 into 4.9 megabytes. [23:23:55 CET] <Gambit-> kepstin: I get a slightly alarming message: [out_0_1 @ 0x7ff028e1c3c0] 100 buffers queued in out_0_1, something may be wrong. [23:24:28 CET] <kingsley> JEEB: I think all 3 looked OK, and am not surprised by the differences in file sizes [23:24:53 CET] <kepstin> Gambit-: i'd have to see the full filter chain. that usually means you have some issue with routing between filters such that you're writing to a concat input that's not ready to read yet, for example [23:25:29 CET] <Gambit-> full filter chain is https://pastebin.com/D3NYiter [23:26:07 CET] <kepstin> Gambit-: your trim and atrim on the first input don't have the same start time [23:26:19 CET] <Gambit-> hm since there's no setpts attached to the movie= filter, that probably means the timestamps are still correct? [23:26:39 CET] <Gambit-> whups thanks for the spot [23:26:45 CET] <Gambit-> yeah, that disappeared the warning [23:27:18 CET] <kepstin> Gambit-: if you're using the seek_point option to the movie filter, you probably don't need the start option on the trim (since the seek will set the start) [23:27:26 CET] <kepstin> that said, i don't think it'll hurt anything :) [23:27:40 CET] <Gambit-> *nods* [23:27:47 CET] <Gambit-> because the timestamp remains coherent all the way through [23:27:53 CET] <kepstin> the movie filter keeps the timestamps when seeking - so if you use seek_point=5 on it, the timestamp of the first frame will be 5 seconds [23:27:56 CET] <Gambit-> So I'd be starting from the "current position" [23:28:00 CET] <Gambit-> gotcha [23:28:09 CET] <kepstin> note that this is different from using doing -ss 5 -i foo.mp4 on the cli [23:28:21 CET] <Gambit-> how so? [23:28:22 CET] <kepstin> ffmpeg by default resets timestamps to start at 0 after seeking when using -ss and -i [23:28:32 CET] <Gambit-> ah [23:28:36 CET] <Gambit-> just from a timestamp perspective, right [23:28:47 CET] <Gambit-> Is there a more performant way of doing this I should be looking at? [23:28:52 CET] <kepstin> so it'll start at 5 seconds, but the timestamp of the frame at 5 seconds will be 0 [23:29:27 CET] <kepstin> there's no real better way without using a proper editing tool or a custom built thing with ffmpeg libraries [23:29:41 CET] <Gambit-> okay, then this is good enough for govt work, so to speak [23:29:53 CET] <kepstin> (ffmpeg libraries can seek within a loaded file - so you could seek to 5s, read 10s, seek to 1050s, read 10s for example) [23:29:57 CET] <Gambit-> thanks for the tips, there was some definitely arcane pieces here. [23:30:00 CET] <Gambit-> Yeah [23:30:11 CET] <Gambit-> That's "future", when I eventually Need It. [23:30:41 CET] <Gambit-> is there a way to tell -f to specify the current filetype? [23:30:48 CET] <Gambit-> I'm outputting this to stdout and it gets confused. [23:31:07 CET] <kepstin> yeah, you can use -f as an output option to specify the container to use [23:31:16 CET] <kepstin> (note that you can't write mp4 to stdout) [23:31:53 CET] <Gambit-> I'm planning on taking the output and sending it to a remote client over http using HLS+video.js, but I'd rather not transcode it to something until I need to. [23:32:04 CET] <kepstin> also, your command right now only outputs video, you'll need something like ...concat=n=2:v=1:a=1[outv][outa]" -map [outv] -map [outa] ... [23:32:08 CET] <Gambit-> So do I need to probe the file for the right format to use first and then specify that in a subsequent invocation? [23:32:24 CET] <Gambit-> huh it plays audio when I drop it in the player... [23:32:35 CET] <kepstin> hmm. [23:32:41 CET] <kepstin> oh, right, filter complex is weird [23:32:56 CET] <Gambit-> FFmpeg.* is weird. [23:32:56 CET] <kepstin> unattached output pads are automatically included in the output file [23:33:09 CET] <Gambit-> that is odd. [23:33:17 CET] <Gambit-> should I do the map's to be more coherent? [23:33:18 CET] <kepstin> so the audio output from concat doesn't have a named pad - that means it's just passed on to the output file. [23:33:32 CET] <kepstin> (if you use a named pad, you have to use -map or it's sent nowhere iirc) [23:33:48 CET] <kepstin> that might be an error, actually [23:34:47 CET] <Gambit-> [outv][outa]" -map [outv] -map [outa] out2.mp4 -- did not produce a fully formed file [23:34:54 CET] <Gambit-> it had the first video segment but not the second one [23:35:22 CET] <kepstin> that doesn't make sense, there must be another issue somewhere in there :/ [23:36:07 CET] <Gambit-> *shrugs* It does work "as expected" with just [out]" -map [out] out2.mp4 [23:36:29 CET] <Gambit-> any tip on specifying the right parameter to -f to "do no unnecessary work" when outputting to stdout? [23:39:47 CET] <Gambit-> ffprobe -v error -show_entries stream=codec_name -select_streams v:0 ../media/volleyball.mp4 -- this kicks out h264 but I'm not sure if that's enough to specify... will test. [23:41:18 CET] <Gambit-> huh no that's not quite enough [00:00:00 CET] --- Sat Jan 12 2019

1 0