Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

December 2018

1 participants
62 discussions

ffmpeg-devel.log.20181220
by burek 21 Dec '18

21 Dec '18

[01:06:08 CET] <cone-290> ffmpeg 03Michael Niedermayer 07master:f8f762c300e2: tests/fate/filter-video: increase fuzz for fate-filter-refcmp-psnr-rgb [01:06:09 CET] <cone-290> ffmpeg 03Michael Niedermayer 07master:ab1319d82f0c: avformat/mpegts: Fix side data type for stream id [01:06:10 CET] <cone-290> ffmpeg 03Michael Niedermayer 07master:68e011e4103b: avcodec/avcodec: Document the data type for AV_PKT_DATA_MPEGTS_STREAM_ID [01:06:11 CET] <cone-290> ffmpeg 03Michael Niedermayer 07master:21f4b456f1ff: avformat/mov: Simplify get_stream_info_time() [01:06:12 CET] <cone-290> ffmpeg 03Michael Niedermayer 07master:8a708aa99cb0: avcodec/rpza: Move frame allocation to a later point [01:06:13 CET] <cone-290> ffmpeg 03Michael Niedermayer 07master:e63517e00a1a: avcodec/rpza: Check that there is enough data for all the blocks [02:47:20 CET] <cone-290> ffmpeg 03Peter Ross 07master:fa0f898e3f78: configure: --help typo [02:47:21 CET] <cone-290> ffmpeg 03Peter Ross 07master:d80eb8409c5a: configure: --help should dipslay --host-extralibs [02:47:22 CET] <cone-290> ffmpeg 03Peter Ross 07master:16ec62bbf434: configure: make --windres option work [11:58:05 CET] <cone-256> ffmpeg 03Jun Zhao 07master:90c45342066b: lavc/options_table: Change some options location in opt table. [11:58:06 CET] <cone-256> ffmpeg 03Jun Zhao 07master:59deae5d1c4d: lavc/libkvazaar: Use avctx->frame_rate first for framerate setting [11:58:07 CET] <cone-256> ffmpeg 03Jun Zhao 07master:3f08ed3920ee: lavc/libkvazaar: indent the code [14:25:31 CET] <jamrial> michaelni: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88559 [14:25:50 CET] <jamrial> they don't plan to fix it, saying it was never meant to work [14:26:13 CET] <jamrial> so if you want libpostproc to compile with gcc 9, you may want to work around this [14:33:38 CET] <Compn> ehehe gcc [14:33:54 CET] <Compn> always breaking ffmpeg compilation [14:37:26 CET] <jamrial> michaelni: does any fate test cover that inline asm? has it ever worked? [14:38:27 CET] <jamrial> i'd imagine that someone would have reported a crash if gcc has been silently generating bad assembly out of this code for the past 10 years [14:39:37 CET] <Compn> are we still supporting 3dnow ? [14:41:31 CET] <Compn> not that i'm against it. however i am not sure its useful to apply post process to 1080 h265 on a amd k6-2 :P [14:41:33 CET] <jamrial> only what's already there [14:44:09 CET] <Compn> although wikipedia says newer amd still had 3dnow [14:44:17 CET] <Compn> https://en.wikipedia.org/wiki/3DNow!#Processors_supporting_3DNow [14:45:16 CET] <jamrial> up to athlon 64, but starting with athlon xp they also have sse, so 3dnow is pointless [14:45:25 CET] <Compn> https://web.archive.org/web/20131109151245/http://developer.amd.com/communi… [14:48:48 CET] <Compn> isnt the whole inline asm gcc why we switched to yasm/nasm in the first place ? [14:49:37 CET] <Compn> just trying to refresh the old memory banks [14:53:31 CET] <jamrial> for portability reasons, yeah [14:54:06 CET] <jamrial> but nobody really cared about postproc, so it remained as is [14:55:38 CET] <Compn> right it was a separate -pp option [14:55:53 CET] <Compn> now i think it is also used in video filters maybe ? i know mplayer used it as a filter for ages [14:56:27 CET] <Compn> gotta make those postage stamp resolution videos look better somehow :) [14:58:09 CET] <jamrial> pretty much why nobody has cared about postproc for the better part of the last decade and a half, yes :) [15:03:00 CET] <iive> jamrial, why do we need rsp marked as clobbered. from what i see in the code it does "push" then "pop" right away, without any branching inside. [15:04:00 CET] <jamrial> iive: i have no idea, i didn't look at it [15:37:22 CET] <michaelni> jamrial, iam not aware of the code failing in any case, well before today learning about next gcc not building it though thats more of a artifical failure [15:39:00 CET] <jamrial> michaelni: they are taking the error at face value, it seems. i don't know if the code effectively tries to clobber the stack pointer or not [15:40:03 CET] <jamrial> either it is and gcc silently generated invalid assembly for the past decade, or it isn't and this is a gcc regression they don't seem to want to look into [15:50:59 CET] <michaelni> I think (but may be wrong) that the sp on the list was intending to tell gcc that it cannot use E/RSP as a general purpose register. The code does not clobber *sp in the sense that its different at the end compared to the begin but the code will push a value onto the stack. If a smart compiler would use rsp as a general purpose register then rsp would not point to the stack and something really bad would happen [15:51:21 CET] <michaelni> in practice the clobber entry for sp can probably just be dropped [15:56:16 CET] <jamrial> feel free to fix that, because gcc sure looks like they don't plan to :p [15:56:39 CET] <iive> i think that the clobbering is more to signal that the stack itself is clobbered, aka that we use it [15:58:10 CET] <iive> hum, i'm wrong [15:58:32 CET] <iive> 78d2d1e0270 put rsp on the clobber list to prevent gcc from using it in "q" [15:59:31 CET] <iive> Fixes Ticket2675 [16:11:23 CET] <jamrial> michaelni: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00532.html [16:11:36 CET] <jamrial> so looks like postproc needs to be fixed [16:13:41 CET] <jamrial> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11807 [16:13:50 CET] <jamrial> August 2003 [16:15:00 CET] <jamrial> so how did postproc even work after 78d2d1e0270? [16:19:06 CET] <iive> jamrial, did you see what i said? [16:19:25 CET] <jamrial> iive: yes [16:19:37 CET] <iive> ok. [16:20:02 CET] <jamrial> that commit technically made the code invalid, as gcc would not generate correct assembly [16:20:13 CET] <iive> ?? [16:20:45 CET] <jamrial> it's clobbering rsp [16:22:16 CET] <iive> https://trac.ffmpeg.org/ticket/2675 [16:22:58 CET] <iive> it seems to "workarond" or "hack" a gcc-4.7 bug, where the gcc would use rsp as gprs [16:23:25 CET] <iive> we just have to check when this bug has been fixed, if it has been fixed at all. [16:23:35 CET] <jamrial> yeah, yet it seems clobbering esp/rsp is not a valid workaround, seeing it was forcefully forbidden in the gcc patch in linked above [19:22:36 CET] <cone-296> ffmpeg 03Paul B Mahol 07master:4b5977fc5011: avfilter/af_sofalizer: add printing of license back [19:22:36 CET] <cone-296> ffmpeg 03Paul B Mahol 07master:1ead98ffd9cd: avfilter/af_sofalizer: increase max radius [19:33:45 CET] <cone-296> ffmpeg 03Paul B Mahol 07master:d06aae732c16: avformat: add vividas demuxer [20:32:00 CET] <cone-296> ffmpeg 03Paul B Mahol 07master:d6951e595a2b: avfilter/af_sofalizer: add framesize option [21:22:41 CET] <cone-296> ffmpeg 03Paul B Mahol 07master:1b4c01631b1a: avcodec/vc1_parser: use init_get_bits8() [21:57:34 CET] <cone-296> ffmpeg 03James Almer 07master:064f9505f498: avcodec/cbs_av1: fix parsing delta_frame_id_minus1 [22:31:34 CET] <cone-296> ffmpeg 03James Almer 07release/4.1:5356e610010a: avcodec/cbs_av1: fix parsing delta_frame_id_minus1 [23:33:12 CET] <cone-296> ffmpeg 03Jacob Trimble 07master:555f332e7adb: libavformat/mov: Fix NULL-dereference read for some encrypted content. [00:00:00 CET] --- Fri Dec 21 2018

1 0

ffmpeg.log.20181220
by burek 21 Dec '18

21 Dec '18

[01:00:09 CET] <orion> Hi. I am running ffmpeg in this way: ffmpeg -i foo.webm -f image2pipe -vf fps=1/600 pipe:1 | test.py <-- How does ffmpeg signal the end of one frame and the beginning of another? [01:06:28 CET] <klaxa> don't think it does? images should include information about their size? if not, simply scanning for headers should work [02:03:43 CET] <ntd> i have this cctv solution using the ffmpeg api for captures [02:03:45 CET] <ntd> zoneminder [02:04:14 CET] <ntd> some cameras don't make the audio stream available along with video when doing rtsp [02:04:49 CET] <ntd> so i have it pull the video stream then find some option to add a second inout for audio [02:05:14 CET] <ntd> "-i" isn't a support option :P [02:11:50 CET] <relaxed> ntd: how are you getting the audio? [02:12:06 CET] <ntd> i can ffplay it straight from the source [02:12:23 CET] <ntd> but zoneminder won't let me deifne to sources for the same minitor [02:12:34 CET] <ntd> two sources [02:13:13 CET] <relaxed> you can have two inputs (-i) [02:13:31 CET] <ntd> yeah [02:13:56 CET] <ntd> but the ffmpeg api ZM is built on doesn't let you add two inputs [02:14:42 CET] <relaxed> sounds like you need support from zoneminder [02:15:41 CET] <ntd> the extra "-i" option isnt't supported [02:15:55 CET] <ntd> any other way to specify pulling sep source? [03:27:12 CET] <saml_> I want to combine a video and an audio. And loop the video until the audio finishes. [03:27:46 CET] <saml_> ah there's loop filter and -shortest [10:08:43 CET] <th3_v0ice> Does FFmpeg still support preset files? [10:10:32 CET] <furq> th3_v0ice: https://ffmpeg.org/ffmpeg.html#Preset-files [10:11:02 CET] <th3_v0ice> Yeah, found it, was confused by some other info. If I use -fpre I should be able to specify the full path to the preset right? [10:11:34 CET] <furq> probably [10:11:38 CET] <furq> i've not used ffprests since about 2011 [10:11:40 CET] <furq> e [10:12:03 CET] <th3_v0ice> Why is that? [10:12:43 CET] <furq> i just don't have any reason to use them [10:12:47 CET] <furq> the x264 default presets work fine for me [10:12:58 CET] <furq> and i never encode anything else [10:14:07 CET] <th3_v0ice> Ok, I thought there was some other problem with it :) [13:25:44 CET] <k-man> i'm trying to convert some mp3 to m4a, but i get this error about framerate too high: https://hastebin.com/derutirape.bash [13:25:49 CET] <k-man> any idea what I'm doing wrong? [13:28:06 CET] <furq> k-man: add -vn [13:29:31 CET] <furq> or upgrade your ffmpeg, cover art in m4a was added fairly recently iirc [13:29:42 CET] <k-man> oh is that the issue? [13:30:01 CET] <furq> yeah ffmpeg treats cover art as a single-frame video stream [13:30:32 CET] <furq> so sometimes this sort of thing happens [13:30:38 CET] <furq> https://trac.ffmpeg.org/ticket/2798 [13:30:40 CET] <k-man> thanks furq [14:01:11 CET] <k-man> furq, so i built at new version of ffmpeg but it still wouldn't work without the -vn [14:02:35 CET] <k-man> oh, i would need to use the -c option? maybe -cv ? [14:06:24 CET] <furq> maybe -c:v png [14:06:31 CET] <furq> or -c:v copy [14:39:25 CET] <Sunger_> hello [14:39:56 CET] <Sunger_> im having trouble installing ffmpeg 4.1 on debian 9 [14:40:06 CET] <Sunger_> where can I find some help ? [14:46:19 CET] <pink_mist> maybe a debian-related channel? I don't rightly know [14:49:54 CET] <iive> Sunger_, what's the problem? [14:51:48 CET] <Sunger_> after installing the package I came up with no configuration [14:51:57 CET] <Sunger_> no encoders [14:52:21 CET] <Sunger_> ony the raw ffmpeg with codecs [14:53:11 CET] <Alina-malina> how to capture video desktop and sound from my speakers with ffmpeg? [14:57:56 CET] <Alina-malina> https://pastebin.com/raw/tRaAwiwu this is my error [15:38:46 CET] <relaxed> Alina-malina: maybe it's just ...:audio="Stereo Mix" [15:39:34 CET] <Alina-malina> relaxed, [dshow @ 00000000005f3080] Could not find video device with name [UScreenCapture] among source devices of type video. [15:39:35 CET] <Alina-malina> video=UScreenCapture:audio=Stereo Mix: I/O error [15:40:59 CET] <relaxed> you're going off of https://trac.ffmpeg.org/wiki/Capture/Desktop ? [15:43:05 CET] <Alina-malina> i guess so [15:44:31 CET] <relaxed> try the example with two inputs (-i) [15:45:35 CET] <Alina-malina> no, still same error [15:45:44 CET] <Alina-malina> i think UScreenCapture is wrong [15:46:30 CET] <Alina-malina> relaxed, ffmpeg -f gdigrab -framerate 30 -i desktop output.mkv this works, but no sound [15:48:08 CET] <Alina-malina> relaxed, and its awful quality tbh [15:55:44 CET] <relaxed> I don't use Windows, so I'm just stabbing in the dark. For higher quality see https://trac.ffmpeg.org/wiki/Encode/H.264 [16:22:18 CET] <saml> is it difficult to write a filter? [16:23:03 CET] <saml> using trim many times and concat to exclude many portions of a video is too slow probably because each trim filter starts seeking from the beginning [16:23:29 CET] <saml> so, I want to write my own filter that scans the video once, cut them to pieces, and concat [16:23:36 CET] <saml> i'll name it cutcat [16:24:44 CET] <saml> ffmpeg -i a.mp4 -filter_complex '[0:v][0:a]cutcat=0 1 4 9 10 40[v][a]' -map '[v]' -map '[a]' out.mp4 [16:25:24 CET] <saml> cutcat takes even number of floats. it'll include segments at (0, 1), (4, 9), (10, 40) seconds of a.mp4 [16:25:29 CET] <Mavrik> Take a look at vf_select.c to see how to write a filter that only selects certain segments. [16:26:21 CET] <Mavrik> and other filters (they're named vf_<filtername>.c in source) [16:26:31 CET] <saml> Mavrik, once I write a filter, how do I compile it? do I put my .c file to libavfilter/* and rebuild ffmpeg? [16:26:51 CET] <saml> i should search online first [16:27:06 CET] <Mavrik> Source is your best friend in this case :)\ [16:27:19 CET] <Mavrik> I think it should be picked up automatically, but grep for vf_source.c and see if has to be listed somewhere. [16:27:29 CET] <saml> https://github.com/FFmpeg/FFmpeg/blob/master/doc/writing_filters.txt [16:27:49 CET] <furq> you could do this with select and setpts fwiw [16:28:09 CET] <furq> but i guess your thing would have nicer syntax [16:28:16 CET] <saml> https://gist.github.com/saml/312f3a11b8db3a64c0ab1a17b4b6b6d4 this is what i'm doing [16:28:25 CET] Action: saml reads manual for select [16:29:45 CET] <furq> -vf select=between(t,9.8,10.283)+between(t,11.55,14.983)+between(t,16.617,22.484),setpts=PTS-STARTPTS [16:29:55 CET] <furq> plus the same thing again with aselect and asetpts [16:30:17 CET] <saml> whoa [16:33:08 CET] <furq> actually i guess that'd need to be setpts=N/(FR*TB) [16:50:11 CET] <saml> what is timebase, TB? is that in seconds? [16:57:10 CET] <saml> ah my ffmpeg was a bit old and didn't have FR but had FRAME_RATE [17:01:09 CET] <saml> hrm using select or trim and concat yields pretty similar time. I thought select would be faster [17:01:32 CET] <saml> looks like each between(t,A,B) starts seeking from the beginning as well [17:06:32 CET] <saml> now, I want to create a summary of video, selecting a couple of seconds of each scene. scene change detection is also select filter, right? [17:06:50 CET] <saml> select='gt(scene\,0.4)' [17:08:47 CET] <kepstin> hmm, the 'scene' detection will only match single frames. the challenge would be figuring out how to include several seconds of following video too (I'm not sure where to start with this, tbh) [17:09:01 CET] <furq> 16:01:32 ( saml) looks like each between(t,A,B) starts seeking from the beginning as well [17:09:04 CET] <furq> it doesn't [17:09:07 CET] <furq> and trim shouldn't either [17:09:11 CET] <furq> but both of them will decode the entire file [17:09:16 CET] <saml> "select='gt(scene,0.4)',showinfo" [17:09:38 CET] <saml> to get timestamps. then I parse stderr and add few seconds to each [17:09:40 CET] <furq> i don't think you can make lavfi seek forwards [17:09:46 CET] <saml> and then use select or trim,concat [17:10:05 CET] <saml> furq, what does seek forward mean? [17:10:48 CET] <furq> like between(t,0,1)+between(t,100,101) will still decode :02 to 1:39 [17:11:04 CET] <saml> between(t,1,10)+between(t,11,20) for second between(t,11,20), would it seek from previous (that ended at 10)? [17:11:09 CET] <furq> no [17:11:19 CET] <furq> like i said i don't think filters can do that [17:11:30 CET] <furq> select is just taking what comes from the decoder and comparing the timestamps [17:12:28 CET] <saml> ah, so decorder decodes entire file. and for each frame of the file, select filter decides if the frame needs to be included or not [17:12:40 CET] <furq> something like that yeah [17:12:44 CET] <saml> so, each between() will scan all frames? [17:13:05 CET] <furq> it runs the entire expression for every frame [17:13:16 CET] <furq> but that's a drop in the ocean compared to actually decoding the entire file [17:13:17 CET] <saml> or, i guess for each frame, multiple between() clauses are evaluated [17:13:21 CET] <furq> yeah [17:16:19 CET] <saml> ffmpeg -i /tmp/a.mkv -an -vf "select='between(t,0,2)+between(t,1,2)',setpts=N/(FRAME_RATE*TB)" out.mkv [17:16:28 CET] <saml> hrm so between()s can overlap [17:17:03 CET] <saml> this is great tool. [17:17:37 CET] <kepstin> note that if the betweens overlap, it'll add up to '2' instead of '1', which causes different behaviour in the select filter. [17:18:56 CET] <kepstin> (you might explicitly thow all the betweens into a 'gte(...., 1)' check to about that. [17:18:57 CET] <furq> it's only different if you have multiple outputs iirc [17:19:12 CET] <kepstin> hmm, so overflow just sends to the last output? [17:19:18 CET] <furq> i might be wrong about that [17:20:29 CET] <kepstin> oh, wow, you can store and retrieve variables in expressions. that's cool. [17:28:34 CET] <saml> is filter graph turing complete [17:31:07 CET] <th3_v0ice> Guys, can anyone shed some light on the following issue. The MPEG-TS stream I am outputting using the API is working fine. No errors. But some software that checks the quality of the given stream reports that program clock register (PCR) is not sent and/or is not sent fast enough. Is there something that I am missing while writting the packets to the muxer or this needs to be configured somewhere? [17:31:07 CET] <th3_v0ice> Thanks. [17:37:06 CET] <Hello71> saml: only if the input is infinitely long [17:40:10 CET] <^Neo> Hello friends, say I have a discontinuous HLS feed that I want to capture and ensure smooth playback without PTS jumps. I'm finding that doing `-fflags +genpts` is sometimes insufficient, should I additionally add vsync flags as well? [17:44:37 CET] <saml> what's an HLS feed? [17:44:41 CET] <saml> multiple videos? [17:56:44 CET] <^Neo> @saml, assume just a live HLS playlist that may have discontinuities within the manifest [17:56:52 CET] <pzy> https://trac.ffmpeg.org/ticket/7589?cversion=0&cnum_hist=11 [17:56:58 CET] <pzy> I love GPL slapfests [17:57:12 CET] <pzy> anyone want to talk about how annoying NewTek is? :P [17:57:50 CET] <JEEB> I dunno if they're annoying, and this partially was a problem with whomever let that thing past to begin with. we need better rules [17:57:55 CET] <saml> ^Neo, not sure if it's relevant.. but when I had to select many segments of a video and concat them to make video shorter, I had to use setpts=N/(FRAME_RATE*TB) [17:58:19 CET] <JEEB> because it's not an OS component etc [17:58:28 CET] <pzy> let it past what? there was no way to stop them before it happened unless they happened to care about licensing right? [17:58:29 CET] <saml> that set the timestamp correct after stitching segments together [17:58:45 CET] <JEEB> pzy: the fact that the nonfree closed source wrapper was merged [17:59:44 CET] <pzy> NDI is really cool, I wish NewTek wasn't the company behind it :P [18:00:11 CET] <JEEB> I think the part that's worst is that they seem to have harrassed open source devs that tried to implement their protocol in OSS [18:00:33 CET] <pzy> I'm not sure if they've done that recently, but they certainly have in the past [18:00:35 CET] <JEEB> which once again goes to the thing of "why did the wrapper for the library get merged to begin with?" [18:00:52 CET] <JEEB> like, if they have a history and their thing is not even open source [18:01:06 CET] <pzy> I think NDI isn't open source because of all the stolen code :P [18:01:23 CET] <JEEB> and clearly they have had use of it being in FFmpeg because they can market it being usable through FFmpeg [18:02:08 CET] <pzy> how does it work for licensing if they use ffmpeg for internal workflows in compiled software they provide? [18:17:53 CET] <BtbN> From how I understand it, they were primarily upset about that OSS clone clearly using re-labeled code from their SDK, and stuff that was clearly decompiled from their library. But that's just their side of the story, and I haven't heard anything from any of the affected oss devs. [18:18:53 CET] <BtbN> I also wonder what's so special about NDI. Something like it could be relatively easily implemented with existing OSS tools. Nobody just put the pieces together so far. [18:19:45 CET] <BtbN> The coded seems roughly similar to mjpeg, and network auto-discovery/multicast streaming (no idea what NDI actually does) isn't magic either [18:19:48 CET] <BtbN> *codec [18:20:00 CET] <pzy> it's just mdns [18:20:23 CET] <pzy> NewTek seems to have vaguely "tried" to make NDI "open" [18:20:27 CET] <BtbN> The only advantage with implementing NDI itself is the interoperability with a large range of applications [18:20:30 CET] <iive> avahi implements mDNS [18:20:33 CET] <pzy> but they are a stodgy 1980s software company who hates their customers [18:21:08 CET] <BtbN> What do they even make money with, in regards to NDI? Since it's pretty much free? [18:21:15 CET] <BtbN> I guess it's not free if you yourself make money with it? [18:21:45 CET] <iive> licensing? backdoors? [18:24:49 CET] <pzy> they made NDI "free" to push sales of their hardware, mostly [18:24:57 CET] <pzy> TriCasters etc [18:25:25 CET] <BtbN> The one time I tried to use it in a bigger setup it had so many little hickups that we never used it again [18:25:27 CET] <pzy> which is just a Windows 10 machine anyway sooooo [18:25:33 CET] <BtbN> But I partially blame out network for that [18:25:48 CET] <pzy> like with all newtek stuff, it's great when it works [18:26:09 CET] <BtbN> I'm pretty sure one of our links degraded to 100Mbit in that setup [18:26:21 CET] <pzy> is Andrew Cross idling in here? he seems to be that kind of hand-on guy :P [18:27:08 CET] <pzy> not an encouraging sign from a software company when bug reports and patches come via their literal President [18:27:26 CET] <pzy> President, CTO, patchmaker [18:27:44 CET] <BtbN> Why? I prefer that over a completely detached and clueless management [18:28:19 CET] <pzy> a few reasons, mostly their depressing lack of version control [18:28:55 CET] <pzy> of course when they removed the violating ffmpeg from their SDK, the SDK version didn't change, nor did any of their documentation [18:29:10 CET] <BtbN> Hm? They bumped it from 3.7 to 3.7.1 [18:29:27 CET] <pzy> where on earth did you see that? haha [18:29:55 CET] <BtbN> On the SDK Download page [18:30:30 CET] <pzy> ah it's 3.8 now, I didn't notice if they bumped it before [18:30:43 CET] <BtbN> It was release on the same day the issue came up [18:30:43 CET] <pzy> I just use their permanent new.tk shortlinks so I guess it's partly my fault :P [18:31:24 CET] <pzy> new.tk/NDISDK will always be the latest [18:31:39 CET] <pzy> and it still downloaded as 3.7 iirc [18:37:27 CET] <pzy> when would the ffmpeg project move forward with removing libndi support if newtek remains silent? [18:37:55 CET] <BtbN> When enough people agree on it. Which seems to not be anytime soon [18:38:23 CET] <pzy> great, sounds like they got away with it :P [18:38:45 CET] <BtbN> It would primarily punish everyone but Newtek to remove it from ffmpeg [18:39:24 CET] <JEEB> yea but it's a closed source thing that isn't even os stuff or hw driver interfacing [18:39:41 CET] <JEEB> it's a proprietary protocol [18:40:30 CET] <JEEB> it boggles the mind that i need to have long winded discussions regarding oss patches but that got in :p [18:40:52 CET] <pzy> haha [18:41:34 CET] <pzy> I won't even pretend to understand that whole process, I just think it sucks big companies continue to disrespect open source projects while simultaneously enriching themselves thanks to decades of open source work [18:41:42 CET] <pzy> same old shit I guess [19:54:52 CET] <^Neo> regarding OSS, does anyone know how to properly use BMD devices? [19:55:01 CET] <^Neo> do you have to get a redistributable license through BMD? [19:55:21 CET] <^Neo> since their SDK is obviously not usable [19:59:02 CET] <ePirat> why is their SDK not usable? [20:00:34 CET] <ePirat> I still need to email them and ask for clarification though as their license when downloading the SDK contradicts the license in the header files [20:01:02 CET] <JEEB> lol [20:02:17 CET] <ePirat> I guess their intention is that the license when downloading applies to the binaries and files without the license preamble in the SDK only [20:02:56 CET] <pzy> lol licensing [20:25:29 CET] <fengshaun> I'm learning ffmpeg's libav api and I'm trying to transcode a video file. So far, I've been able to open streams, get codec info, and decode to raw AVFrame thanks for dranger's tutorial. What are the next steps toward re-encoding the frames (eventually transcoding the entire file) and where should I look for docs? doxygen docs are great, but require some knowledge of what to look for. [20:28:39 CET] <JEEB> see the transcoding example under doc/examples [20:29:34 CET] <JEEB> demux -> decoding -> filtering (if applicable) -> encoding -> muxing [20:31:43 CET] <fengshaun> JEEB, thanks, where are those examples? github sources? [20:32:11 CET] <JEEB> git.videolan.org ffmpeg repo [20:32:17 CET] <JEEB> (github is a mirror) [20:32:39 CET] <furq> fengshaun: https://www.ffmpeg.org/doxygen/trunk/examples.html [20:32:44 CET] <fengshaun> thanks [20:33:39 CET] <fengshaun> nice and short examples [20:33:58 CET] <JEEB> not all of them are nice/best way of doing something but they are examples [21:39:43 CET] <fengshaun> the send/receive api is definitely nicer than encode/decode functions [21:41:14 CET] <JEEB> yup [00:00:00 CET] --- Fri Dec 21 2018

1 0

ffmpeg-devel.log.20181219
by burek 20 Dec '18

20 Dec '18

[10:22:48 CET] <cone-759> ffmpeg 03Michael Niedermayer 07master:645c5e8c91ff: doc/encoders: Fix colums typo [10:22:48 CET] <cone-759> ffmpeg 03Michael Niedermayer 07master:dfb5046cf33b: avcodec/mjpegdec: verify SOF len field validity [10:22:48 CET] <cone-759> ffmpeg 03Michael Niedermayer 07master:ea30ac1e4082: avcodec/mjpegdec: Fix indention of ljpeg_decode_yuv_scan() [10:30:08 CET] <cone-759> ffmpeg 03Paul B Mahol 07release/4.0:e44498984d3d: avformat/dsfdec: properly handle padded last packet [10:30:09 CET] <cone-759> ffmpeg 03Paul B Mahol 07release/4.0:7c000b9cead0: avformat/dsfdec: fix calculation of size of data chunk [13:39:02 CET] <durandal_1707> michaelni: can i get answer on ml about nut? [15:53:43 CET] <cone-905> ffmpeg 03Carl Eugen Hoyos 07master:a07470ba372f: lavu/internal: Replace an empty loop with "do {}". [17:25:57 CET] <jamrial> libaom keeps breaking shit [17:26:17 CET] <BtbN> API stability is not modern [17:26:31 CET] <BtbN> You just put everything into a Vagrant Container inside of a Docker container, and ship that [17:26:43 CET] <j-b> jamrial: you should be happy: someone suggested a rolling-release of the AV1 spec. [17:27:19 CET] <BtbN> That all sounds like h264 will eventually be patent free and still the most common codec [17:29:15 CET] <jamrial> j-b: lol, that would screw with hardware implementations, and that's a big no-no [17:30:39 CET] <BtbN> I'm really worried we'll end up with another libvpx as encoder, which so far seems to be the case [17:30:57 CET] <nevcairiel> technically it always was libvpx =p [17:31:02 CET] <nevcairiel> thats what it started out as [17:33:11 CET] <jamrial> BtbN: there's rav1e precisely to prevent another vp9 situation with libvpx as the only foss compiler [17:33:26 CET] <j-b> encoder :) [17:33:33 CET] <jamrial> right [17:33:40 CET] <j-b> rav1e, libaom and svt-av1 are already 3 foss encoders [17:33:56 CET] <jamrial> nice, haven't heard of svt-av1 [17:34:41 CET] <nevcairiel> the intel svt compilers seem to be a bit .. peculiar [17:34:44 CET] <jamrial> oh, Intel [17:34:57 CET] <nevcairiel> damn now jamrial infected me with his compiler speak [17:35:04 CET] <jamrial> :D [17:36:30 CET] <j-b> nevcairiel: how peculiar? [17:40:36 CET] <atomnuker> heh, "oh, Intel" says it all [17:40:48 CET] <nevcairiel> they seem to be very specifically tuned around a very specific set of server hardware, and not really scale down from that, with really high memory requirements [17:41:22 CET] <nevcairiel> (thats from looking at svt-hevc, svt-av1 doesnt seem to be public yet) [17:47:51 CET] <atomnuker> can't be worse than av1, encoding 1080p was taking around 5 gigs of ram [17:48:08 CET] <nevcairiel> it claims it wants 8 for 1080p [17:48:23 CET] <nevcairiel> oh waits its only 6 [17:48:26 CET] <nevcairiel> but 16 for 4K [17:55:00 CET] <atomnuker> okay thats worse [17:55:31 CET] <nevcairiel> its specifically designed for running on the intel "scalable" branded server CPUs [17:55:41 CET] <nevcairiel> which are probably assumed to also have a lot of memory [17:57:00 CET] <nevcairiel> the good thing is that it probably threads quite well then [17:57:15 CET] <nevcairiel> a soar point for libvpx and libaom [18:07:52 CET] <J_Darnley> assembly people... [18:08:50 CET] <J_Darnley> Is there a reason I can't abuse a SIMD bitpacking function that usually uses seprates source and dest buffers to operate on the same buffer? [18:10:02 CET] <J_Darnley> The order of the reads and writes should ensure that no data I still need is altered. [18:10:31 CET] <JEEB> michaelni: could you mention your stance on the nopts mpegts patch, as in the case you're not blocking it I'd love to take it forward. and if you think it's not a good enough improvement for some cases or that it breaks something for you mention that it's not good. [18:11:17 CET] <JEEB> right now it just ended up in that discussion without a clear view whether it is not good enough or not [18:14:24 CET] <nevcairiel> Didn't he say the other day that he would be fine with it, just that he might try to work on a buffering method in the future if time permits? That's what I read [18:14:29 CET] <J_Darnley> hm, what was the instruction to flush memory? sfence, mfence? [18:14:35 CET] Action: J_Darnley find he reference [18:14:51 CET] <JEEB> nevcairiel: yes, I'm just trying to make it clear on the ml [18:20:00 CET] <atomnuker> J_Darnley: same buffer? as in mem<-mem? [18:20:23 CET] <J_Darnley> yes [18:20:39 CET] <J_Darnley> movu reg, [buffer] [18:20:50 CET] <J_Darnley> ... processing ... [18:20:59 CET] <J_Darnley> movu [buffer], reg [18:22:34 CET] <J_Darnley> strictly speaking [buffer] is in two gpregs [18:23:00 CET] <J_Darnley> the addresses start the same but slowly diverge because I read in more data than I wrte out [18:26:25 CET] <atomnuker> not sure what shortcut you want to take here [18:26:54 CET] <atomnuker> oh, you want to do it in-placec? [18:26:59 CET] <atomnuker> *place [18:28:18 CET] <J_Darnley> yes [18:31:55 CET] <J_Darnley> Okay, that is very weird. The first 50MiB to come out of the function is identical to a quick C hack I made. (but that's only a few frames of data) [18:36:46 CET] <kierank> iirc there was a reason we didn't go inplace [18:37:12 CET] <J_Darnley> read-only buffers? [18:40:20 CET] <kierank> dunno [19:33:15 CET] <cone-905> ffmpeg 03Helmut K. C. Tessarek 07master:aaf917157479: libavcodec/libaomenc: fix breakage from upstream [20:05:00 CET] <JEEB> michaelni: thanks [20:05:08 CET] <zoff99> JEEB: ping [20:05:19 CET] <JEEB> zoff99: pong [20:05:37 CET] <zoff99> i am trying to get h264_mediacodec to work on android [20:05:44 CET] <zoff99> been reading old irc logs [20:06:00 CET] <zoff99> wihtout surface, that is [20:06:07 CET] <JEEB> if you pass it the JVM, it should work just as a "normal" decoder [20:06:24 CET] <JEEB> extra effort is only needed for the hwaccel side [20:06:30 CET] <JEEB> (which means texture output) [20:06:48 CET] <zoff99> yes i read that. but somehow it wont work [20:07:16 CET] <zoff99> is it not accelerated without surface? is it using pure cpu then? [20:07:35 CET] <JEEB> it is whatever your device gives for that format [20:07:45 CET] <JEEB> for the oneplus one for example, HEVC was swdec [20:07:49 CET] <JEEB> but AVC was hwdec [20:07:53 CET] <zoff99> ah, so it could be accelerated then [20:08:10 CET] <zoff99> is there an mediacodec encoder in ffmpeg aswell? [20:08:40 CET] <JEEB> no [20:09:33 CET] <zoff99> also not going to be? [20:09:50 CET] <zoff99> anything planned? [20:10:01 CET] <JEEB> not planned, but I don't think we have anything against it :P [20:10:09 CET] <JEEB> watches pelcome as people say [20:10:16 CET] <zoff99> :) [20:10:25 CET] <zoff99> ok so here is my JNI part: [20:10:25 CET] <zoff99> https://bin.disroot.org/?f97199138fd9d787#QnGfJpiWtE+WNfK921ZkRBoB5/u1xMQRT… [20:10:36 CET] <zoff99> but decoder open returns error [20:10:39 CET] <zoff99> still [20:12:18 CET] <JEEB> try if mpv-android works first since I kind of know that one logs various stuff nicely. after that start plugging in the FFmpeg logging framework into your thing [20:12:19 CET] <zoff99> does the code snippet seem correct? could there be a threading issue [20:12:35 CET] <zoff99> link? [20:13:12 CET] <JEEB> https://github.com/mpv-android/mpv-android [20:13:23 CET] <JEEB> APKs either from play store or from the release tab [20:13:40 CET] <zoff99> ok just run the apk? [20:13:44 CET] <JEEB> yea [20:14:15 CET] <zoff99> and then? [20:14:15 CET] <JEEB> also you can take a look at the JNI stuff if you want [20:14:20 CET] <zoff99> what does it log? [20:14:26 CET] <JEEB> all sorts of stuff :P [20:14:29 CET] <JEEB> and if it works or not [20:14:47 CET] <JEEB> then you can start plugging your FFmpeg library instances into the android logging framework [20:14:49 CET] <zoff99> the debug version then? [20:15:00 CET] <JEEB> debug version just has the debug bit on [20:15:04 CET] <JEEB> no real other difference [20:15:57 CET] <zoff99> media player? or what does the app do? [20:15:59 CET] <JEEB> because if you plug in your API usage into a logger you should be able to figure out how far it gets :P [20:16:04 CET] <JEEB> it's a player, yes [20:16:17 CET] <JEEB> (also this is API usage and not development of FFmpeg, so technically this should go onto #ffmpeg) [20:17:10 CET] <zoff99> oh. i read the logs of this channel [20:17:28 CET] <zoff99> and 2 persons where asking this exact stuff and had same issue, thats why i joined here [20:19:15 CET] <zoff99> ok so your app plays H264 mp4 file alright [20:19:31 CET] <zoff99> hwdec: true [20:20:02 CET] <JEEB> also you should have in adb logging a lot of stuff coming out from the ffmpeg decoding [20:24:15 CET] <zoff99> it says something about mediacodec_copy [20:25:21 CET] <JEEB> it's called like that within mpv [20:25:25 CET] <zoff99> ok [20:25:31 CET] <zoff99> well it all seems fine [20:25:37 CET] <zoff99> also my code seems ok [20:25:40 CET] <zoff99> very strange [20:25:52 CET] <zoff99> what libs did u build for ffmpeg? [20:25:57 CET] <zoff99> dependencies [20:26:06 CET] <JEEB> you should be OK with just NDK and FFmpeg itself [20:26:17 CET] <JEEB> since mediacodec itself only depends on NDK headers/libs [20:26:23 CET] <JEEB> as in, android stuff [20:26:48 CET] <zoff99> i could compile ffmpeg alright with h264_mediacodec [20:26:55 CET] <zoff99> what ffmpeg version did u use? [20:27:01 CET] <zoff99> i used n4.1 from github [20:27:06 CET] <zoff99> release [20:27:42 CET] <JEEB> it's been a while, but both the release in github as well as the settings/about screen should have the exact hash from master [20:28:04 CET] <JEEB> I should really build newer stuff, but I've been busy/having to handle other things [20:29:16 CET] <zoff99> cant figure out what i am doing wrong [20:29:29 CET] <zoff99> did those 2 others guys get back to u? it was in july this year [20:29:35 CET] <zoff99> the has the exact same issue [20:29:46 CET] <JEEB> no idea, I don't have such long-term memory :P [20:29:51 CET] <zoff99> :) [20:30:05 CET] <zoff99> ok i have another issue with h264 encoder [20:30:15 CET] <zoff99> i am working on a video conferencing app [20:30:30 CET] <zoff99> now it use ffmpeg decoder and x264 encoder directly [20:30:40 CET] <zoff99> works nice, but all software coding of course [20:30:52 CET] <zoff99> now i wanted to use x264 encoder but via ffmpeg [20:31:09 CET] <zoff99> and its impossible to know how to set the same options [20:31:15 CET] <zoff99> no examples around [20:31:38 CET] <zoff99> especially setting bitrate on the fly. seems impossible somehow [20:48:09 CET] <JEEB> also I seem to be focusing on the negative way too much. I always forget to write "or if someone has a better idea" [20:49:26 CET] <zoff99> i try my android build again. maybe you can help me on my 2nd issue? [20:51:31 CET] <JEEB> in theory when you feed it a frame, reconfig_encoder in libavcodec/libx264.c is called [20:51:47 CET] <JEEB> when that change is applied is a separate question [20:52:30 CET] <JEEB> that does touch bit rate as well [20:52:47 CET] <JEEB> so in theory from libavcodec's side if the values differ it should get applied [20:52:59 CET] <JEEB> (now when x264 applies those changes depends on x264) [20:53:08 CET] <zoff99> but how can i set the bitrate ? [20:53:26 CET] <JEEB> see the reconfig_encoder function in libavcodec/libx264.c [20:53:32 CET] <zoff99> int res = x264_encoder_reconfig(vc->h264_encoder, &param); [20:53:40 CET] <zoff99> x262 is easy, i just call this directly [20:53:45 CET] <JEEB> that's the final call yes [20:54:09 CET] <JEEB> but you asked which specific values it was looking at from FFmpeg's side [20:54:25 CET] <zoff99> yes [20:54:37 CET] <zoff99> at ffmpeg i dont see any public reconfigure* api functions [20:54:47 CET] <JEEB> thus so you can have the a-ha! moment I recommend you to look at libavcodec/libx264.c [20:55:06 CET] <JEEB> as I already noted, that encoder does have a reconfig_encoder function, which is getting called at each frame [20:55:58 CET] <JEEB> there is no separate function to reconfig the encoder [20:56:13 CET] <zoff99> oh its called internally each frame, ook [20:56:22 CET] <JEEB> you just update the values relevant to the AVFrame and AVCodecContext [20:56:28 CET] <JEEB> and then feed the AVFrame to the encoder instance [20:56:36 CET] <JEEB> for details, look in the location I specified [21:00:28 CET] <zoff99> the bad thing is "avcodec_open2" does not really say what the issue is [21:00:32 CET] <zoff99> it just does not work [21:00:39 CET] <zoff99> no message why [21:00:47 CET] <zoff99> i still think it needs a surface [21:00:59 CET] <zoff99> or needs some option set, to tell it not to use a surface [21:01:16 CET] <zoff99> somebody posted that on a message board somewhere that we traced the calls [21:05:12 CET] <zoff99> int av_mediacodec_default_init(AVCodecContext *avctx, AVMediaCodecContext *ctx, void *surface) [21:07:27 CET] <zoff99> is there an option or flag i have to set before calling "avcodec_open2" ? [21:12:09 CET] <mateo`> zoff99: did you set the codec extradata ? they are mandatory for the mediacodec decoders [21:12:17 CET] <zoff99> oh no [21:12:20 CET] <zoff99> whats that? [21:13:14 CET] <zoff99> is there an example in C ? [21:14:32 CET] <mateo`> its a chunk of bitstream that corresponds to the codec configuration, for avc it's the sps/pps [21:14:55 CET] <zoff99> i dont understand [21:15:09 CET] <zoff99> i am trying to pass the "avcodec_open2" call [21:15:14 CET] <zoff99> no data involved yet [21:17:37 CET] <JEEB> zoff99: plug FFmpeg's logging into your app's debugging [21:17:46 CET] <JEEB> the init() function does have plenty of logging there [21:17:51 CET] <mateo`> the AVCodecContext you pass to avcodec_open2 must be configured first [21:17:54 CET] <zoff99> JEEB: i dont understand what that means [21:18:29 CET] <zoff99> mateo`: yes, i did that. but only like for normal h264 decoders [21:18:43 CET] <mateo`> by settings the codec parameters, width, height, codec extradata, ... [21:18:43 CET] <zoff99> mateo`: what are the extra mandatory values i need to set? [21:18:49 CET] <JEEB> and yes, there is a function to generate AVCodecContext from the demuxer's properties [21:19:39 CET] <mateo`> AVCodecContext.extradata / AVCodecContext.extradata_size [21:20:06 CET] <zoff99> mateo`: mpv doesnt set these, as far as i can see in the source [21:21:06 CET] <JEEB> there's a function that lets you generate a new AVCodecContext from AVCodecParameters [21:21:13 CET] <JEEB> which should take care of some of the stuff :P [21:21:30 CET] <zoff99> JEEB: i am looking at vd_lavc.c [21:22:03 CET] <mateo`> look for avcodec_parameters_* functions [21:22:16 CET] <JEEB> yup, avcodec_parameters_to_context [21:22:19 CET] <JEEB> that was it :P [21:22:34 CET] <JEEB> just looked at some random test code I Wrote ages ago [21:23:00 CET] <JEEB> 1. init AVCodecContext from AVCodec, pass params, open2 [21:23:32 CET] <zoff99> hmm [21:23:43 CET] <zoff99> what are the minimum input i need for that function [21:23:47 CET] <zoff99> is there a sample? [21:23:53 CET] <zoff99> https://www.ffmpeg.org/doxygen/trunk/libavcodec_2utils_8c_source.html#l02092 [21:23:58 CET] <zoff99> this one right? [21:24:15 CET] <JEEB> yes [21:25:02 CET] <JEEB> ok, you don't need that if you don't have lavf used before lavc :P [21:25:20 CET] <JEEB> you then just need to initialize the correct parts of AVCodecContext [21:25:32 CET] <JEEB> but really, stick the logging callbacks [21:25:36 CET] <JEEB> into your logging [21:25:57 CET] <zoff99> ok. [21:26:02 CET] <JEEB> https://ffmpeg.org/doxygen/trunk/group__lavu__log.html [21:26:03 CET] <zoff99> logging example source? [21:26:09 CET] <JEEB> see av_log_set_callback [21:26:17 CET] <mateo`> and if you are using lavf, pick the video stream (AVStream), and call avcodec_parameters_to_context(avctx, stream->par); [21:26:34 CET] <zoff99> i dont have a stream at that [21:26:49 CET] <zoff99> i get single frames, over network [21:26:57 CET] <zoff99> i always use the same settings on the encoder [21:27:26 CET] <mateo`> you will have to extract manually the codec parameters then [21:27:41 CET] <zoff99> highly complex [21:27:51 CET] <zoff99> with software decoder this all is 3 lines of code [21:27:54 CET] <mateo`> craft manually the sps/pps in either the annex-b form or the avcc one [21:28:35 CET] <JEEB> zoff99: or you feed the raw bit stream to the H.264 "demuxer" and then get it from there? [21:28:54 CET] <JEEB> mediacodec requires it to initialize so either you or someone else handles it [21:29:03 CET] <mateo`> yes but with mediacodec we (I) put this restriction so the decoder can fail at initialization if it does support the bitstream you pass to it [21:29:51 CET] <mateo`> maybe I can make optionnal it ... [21:30:05 CET] <zoff99> would be nice [21:30:14 CET] <zoff99> can you tell me the source line in ffmpeg n4.1 [21:30:23 CET] <zoff99> the i can just for testing comment it locally [21:30:24 CET] <JEEB> I don't really see how it would make things simpler. having it fail at init is more clear IMHO [21:30:37 CET] <zoff99> i try logging now [21:30:54 CET] <mateo`> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/mediacodecdec.c#L135 [21:31:07 CET] <JEEB> zoff99: just add the H.264 "demuxer" in front if you don't want to do this yourself? [21:31:23 CET] <mateo`> before that line add if (!avctx->extradata) return 0; [21:31:37 CET] <zoff99> ok, i am confused [21:31:42 CET] <zoff99> do i need the demuxer? [21:31:48 CET] <JEEB> if you want it to be done for you [21:31:57 CET] <zoff99> i get raw data from h264 encoder, and put that into decoder [21:32:03 CET] <zoff99> with software it works fine [21:32:11 CET] <JEEB> yes, because the software thing will eat almost anything [21:32:20 CET] <zoff99> i see [21:32:20 CET] <JEEB> while with hwdec you probably want to know if your hardware isn't going to take it [21:32:28 CET] <JEEB> and it's better to get that failure at init() [21:32:30 CET] <JEEB> IMHO [21:32:48 CET] <zoff99> video coding is complicated [21:32:53 CET] <zoff99> makes my head hurt :) [21:35:07 CET] <mateo`> JEEB: I think the same, however, if it's optional and if the user do not provide the extradata it is up to him to properly handle the failure when he grab the first frame [21:35:20 CET] <mateo`> and maybe we can warn about it [21:37:50 CET] <zoff99> ok, matrix users do not have voice :-( [21:37:57 CET] <zoff99> thats why i cant talk with my phone [21:38:53 CET] <mateo`> I will propose a patch on the ml tomorrow and see how it goes [21:45:58 CET] <zoff99> mateo`: that line does not exist in version n4.1 :D [21:46:32 CET] <zoff99> oops sorry [21:46:37 CET] <zoff99> missed a "dec" in the name [21:48:47 CET] <zoff99> mateo`: do i have to "ff_h264_ps_uninit(&ps);" before return ? [21:48:57 CET] <JEEB> uhh [21:49:18 CET] <zoff99> every other path in that file does it [21:51:01 CET] <mateo`> just return 0 before calling ff_h264_decode_extradata() [21:51:21 CET] <zoff99> yes i did. now compiling again [21:52:10 CET] <zoff99> ok now the log callback works :) [21:52:21 CET] <zoff99> it says: looks like the input is annex_b already [21:53:35 CET] <zoff99> "The input looks like it is Annex B already\n"); [21:54:29 CET] <zoff99> h264_mp4toannexb_bsf.c [21:54:32 CET] <zoff99> string only happens here [21:55:37 CET] <zoff99> mateo`: ok with that change i get a new message and crash [21:56:12 CET] <zoff99> unsupported or unknown profile [21:58:02 CET] <zoff99> seems i need the extra data [21:59:42 CET] <JEEB> if it's raw annex B H.264 you're handling, it might just be simplest to use lavf for the input and parse it as raw H.264 [21:59:52 CET] <JEEB> that way the decoder initialization data will get parsed for you [22:00:37 CET] <JEEB> and then you can just use the codecpar to your codec context function to initialize the AVCodecContext fields [22:09:57 CET] <zoff99> JEEB: ok, i dont understand what that means [22:10:14 CET] <zoff99> yes i get raw anndex b and repeat header h264 video frames [22:10:18 CET] <zoff99> from encoder [22:11:13 CET] <JEEB> if you handle the protocol yourself, then you will have to implement your own read etc callbacks for avformat [22:11:23 CET] <JEEB> but that way you can utilize already available parsers [22:11:25 CET] <JEEB> and logic [22:11:39 CET] <JEEB> there's IIRC even an example for AVIO callbacks in the repo [22:12:19 CET] <JEEB> http://www.ffmpeg.org/doxygen/trunk/doc_2examples_2avio_reading_8c-example.… [22:12:22 CET] <JEEB> this one I think :P [22:12:47 CET] <JEEB> http://www.ffmpeg.org/doxygen/trunk/avio_8h.html#a853f5149136a27ffba3207d85… [22:13:10 CET] <JEEB> then you can feed AVFormatContext that AVIO context [22:27:34 CET] <zoff99> now i am getting frames [22:27:44 CET] <zoff99> all green but at least i am getting something [22:28:17 CET] <JEEB> is that with your own parsing or the lavf H.264 demuxer/parser? [22:29:30 CET] <zoff99> own [22:29:36 CET] <zoff99> i am not parsing anything [22:29:56 CET] <JEEB> ok, so you're still attempting without the extradata I guess [22:30:00 CET] <zoff99> i dont understand what that means. my app just takes frames at a time [22:30:03 CET] <zoff99> yes [22:30:14 CET] <zoff99> since i dont know how to extract it [22:30:30 CET] <JEEB> I just told you for the record if you re-read my last 15 or so lines? [22:30:35 CET] <JEEB> or not even that I think [22:30:36 CET] <zoff99> lavf seems lots complicated [22:30:45 CET] <JEEB> also what's your protocol? [22:30:52 CET] <zoff99> its tox [22:31:00 CET] <JEEB> ok, so not something that lavf speaks out of the box [22:31:13 CET] <zoff99> probably not [22:31:14 CET] <JEEB> if it was just rtp or udp then you wouldn't have needed custom IO [22:31:29 CET] <zoff99> what i do is i just take what x264 gives me, raw data [22:31:32 CET] <JEEB> zoff99: if it's a known working route then I'm not 100% sure if it's "complicated" [22:31:37 CET] <zoff99> and put that into the decoder [22:31:57 CET] <zoff99> ok, its complicated for me. since i have not done it yet [22:32:17 CET] <zoff99> its rtp but with some own stuff [22:32:38 CET] <zoff99> i put the data together so its exactly like at the encoder [22:33:14 CET] <JEEB> ok, so if you want to go your way - sure. then I will stop recommending lavf's parsing. good luck. [22:33:23 CET] <zoff99> ok [22:38:42 CET] <zoff99> thats not the issue [22:38:53 CET] <zoff99> i just dont understand what those things mean [22:39:15 CET] <zoff99> the software encoder does it pretty good [22:39:25 CET] <JEEB> because it's a known software decoder [22:39:29 CET] <zoff99> was hoping to just switch to hw decoder without much change [22:39:37 CET] <JEEB> it's our code and most likely it will eat pretty much whatever you feed it [22:39:57 CET] <zoff99> will proably be easier for me to use mediacodec in java then [22:40:04 CET] <zoff99> was hoping to avoid that [22:40:12 CET] <JEEB> I don't see how that will be easier to be honest [22:40:18 CET] <JEEB> if it's the same APIs underneath [22:40:24 CET] <zoff99> because there a examples [22:40:49 CET] <zoff99> in C with ffmpeg none of the examples are for my case sadly [22:40:51 CET] <JEEB> there are examples of what I just mentioned, it is just that you specifically say that you do not want to utilize that way! [22:41:11 CET] <JEEB> you specifically say that it feels complicated and thus you wanted to handle the parameter sets etc yourself [22:41:28 CET] <JEEB> so we have the tools for you available, and even an example for the custom IO [22:41:32 CET] <zoff99> http://www.ffmpeg.org/doxygen/trunk/doc_2examples_2avio_reading_8c-example.… [22:41:36 CET] <zoff99> this one uses a file [22:41:47 CET] <JEEB> the idea is that you have a callback [22:41:54 CET] <JEEB> that doesn't change with what it is [22:42:07 CET] <JEEB> I also linked http://www.ffmpeg.org/doxygen/trunk/avio_8h.html#a853f5149136a27ffba3207d85… for the AVIO context creation docs [22:43:06 CET] <JEEB> what the example exactly uses for the IO is irrelevant as the main part is that it shows you how to define the AVIO callbacks [22:43:25 CET] <JEEB> a file based thing is just one of the simplest things to make buildable [22:43:36 CET] <zoff99> in my software i dont have callback to fill the data. it work differently [22:43:56 CET] <JEEB> I did not have callbacks either in my matroska thumbnailer until I implemented them [22:44:31 CET] <JEEB> anyways, I'm sorry if it feels to you like we don't have enough examples or don't help you enough. but it really feels like you're specifically saying "no" to the helping functionality we do have. [22:44:45 CET] <zoff99> well you already gave me some pointers [22:44:50 CET] <zoff99> i will check some more [22:45:08 CET] <zoff99> if its too complicated i will switch to java, since proably i will need the encoder aswell [22:45:54 CET] <JEEB> also with your patched-out thing, even if you kept feeding it enough AVPackets, did it ever get out proper images? [22:46:04 CET] <zoff99> no [22:46:13 CET] <JEEB> enough as in that you got PPS/SPS etc [22:46:18 CET] <JEEB> the parameter sets [22:46:28 CET] <JEEB> (aka what goes into extradata in various ways) [22:46:40 CET] <zoff99> i set parameter manually hoping it would be enough [22:46:51 CET] <zoff99> wasnt :) [22:46:51 CET] <JEEB> you do know what parameter sets are, right? [22:47:08 CET] <zoff99> i have the PPS and SPS [22:47:12 CET] <JEEB> yes [22:47:17 CET] <zoff99> there are tool to extract it [22:47:21 CET] <JEEB> ok [22:47:33 CET] <JEEB> then you should be able to generate AVCodecContext.extradata from that [22:47:37 CET] <zoff99> it would mean to wait for the first data block [22:48:07 CET] <zoff99> basically i was trying to find out if it was easy (for me) to switch to the HW decoder [22:48:18 CET] <zoff99> now i know its more difficult then just 1 line [22:48:39 CET] <JEEB> yes, if you were using the other functionality from the beginning [22:48:42 CET] <zoff99> for exmaple on the raspi it was just decoder by name 'h264_mmal' and done [22:48:50 CET] <JEEB> because then the extradata field would have been set [22:48:52 CET] <zoff99> same for encoder on raspi [22:49:00 CET] <zoff99> no extra data no nothing [22:49:01 CET] <JEEB> encoder is a whole separate ball game [22:49:17 CET] <JEEB> well you just got to that point when you disabled the check in the mediacodec decoder [22:49:24 CET] <JEEB> so after that it's in MediaCodec's area [22:49:28 CET] <JEEB> I'd say [22:49:28 CET] <zoff99> yeah [22:49:41 CET] <zoff99> just i hoped since it was so easy on the raspi [22:49:55 CET] <JEEB> it would have been, IF you had been using lavf already [22:49:56 CET] <JEEB> unfortunately [22:49:57 CET] <zoff99> literally just rename the decoder name [22:50:02 CET] <JEEB> I feel like I'm repeating myself [22:50:07 CET] <zoff99> ok [22:50:12 CET] <zoff99> thanks anyway [22:51:17 CET] <JEEB> but as I said, if you are already parsing out the PPS/SPS [22:51:27 CET] <JEEB> which you mentioned you had functionality for [22:51:40 CET] <JEEB> then you could generate the extradata field from that :P [22:51:43 CET] <JEEB> just fyi [22:51:48 CET] <zoff99> no. i am using an external tool to look at it [22:51:51 CET] <JEEB> ok [00:00:00 CET] --- Thu Dec 20 2018

1 0

ffmpeg.log.20181219
by burek 20 Dec '18

20 Dec '18

[04:51:11 CET] <bemeurer> Hi, I was wondering: If I am receiving an RTSP stream in one process, is there some way for me to send the AVPacket's to another process (I'm using a shared memory ringbuffer.) I looked into the AVPacket struct, but it looks like it contains pointers, which would obviously be invalidated on the receiver proc. How can I do this? [04:51:48 CET] <bemeurer> FWIW: I just need the other process to be able to use the data to decode it's AVPackets, so that the sender works pretty much as a simple forwarder [11:32:51 CET] <visub> I calculated the PSNR and SSIM values of a set of videos using ffmpeg and also using VMAF. I see inconsistencies in the values calculated by both. Has someone experienced something similar or know why this could be the case? [11:35:49 CET] <durandal_1707> because vmaf use different algo to measure PSNR/SSIM [11:45:59 CET] <justinasvd> Is there any way to copy from a smaller AVFrame to a bigger one, leaving horizontal and vertical padding? [11:46:02 CET] <visub> durandal_1707 Thank you! By different algo, do you mean that vmaf computes something like the PSNR-HVS-M instead of the regular formula that one would use or something else? Would you explain a bit more? [11:46:58 CET] <justinasvd> What I wanted to do is to fill my bigger frame with black, and then to copy the small frame and have a bigger frame with the same content and the black border. [14:54:57 CET] <LigH> Hi. [14:55:23 CET] <LigH> Current HEAD of aomedia builds as separate applications, but libaomenc fails in libavcodec / ffmpeg. [14:55:33 CET] <LigH> Which bug tracker shall I report that best to? [14:55:39 CET] <LigH> Tail of make log: https://pastebin.com/SvEiLA5E [15:00:08 CET] <durandal_1707> LigH: only releses are supportted [15:00:25 CET] <durandal_1707> we can not fix wrapper if people break things all the time [15:00:42 CET] <LigH> So, probably a fault of aomedia's progress. [15:01:25 CET] <durandal_1707> it could get fixed if change is going to be stable [15:01:26 CET] <LigH> Well, that narrows it for now, thank you [15:01:54 CET] <LigH> Bye [17:13:57 CET] <sybariten> very vague question but can the select filter do things like cutting out many portions of a video, but without explicitly defining each of those intervals? I mean maybe with some sort of function, instead [17:30:55 CET] <kepstin> sybariten: the select filter doesn't modify the timestamps of the frames it passes through, so it can't really "cut" video (it'll leave a bit timestamp gap) [17:31:38 CET] <kepstin> (if the content is constant rate, you can work around this by using a setpts filter afterwards) [17:31:44 CET] <kepstin> constant frame rate* [17:32:22 CET] <kepstin> so i guess the answer is "yes, if your video is constant framerate and you rewrite the timestamps afterwards" [17:33:13 CET] <kepstin> (note that you'll have to separately cut the audio, possibly with aselect. It might be tricky to preserve a/v sync) [17:43:14 CET] <sybariten> kepstin: for this specific case i might even skip the audio then. Someone else needs to take a quick look at several hours of lecture video that i filmed, and i figured i would like to make "time compressed" versions. By periodically taking out chunks, if you understand [17:44:30 CET] <sybariten> i didnt completely understand the timestamp issue but ive realized that the select filter takes a little bit of ffmpeg knowledge [17:57:25 CET] <sybariten> basicly, what i'd like to do , in pseudo command line would be something like this ./ffmpeg -i input.mp4 -ss "every 100th second" -c copy -t 5 sliced-output.mp4 [17:58:12 CET] <furq> -vf select=eq(mod(t\,100)\,0) [17:58:14 CET] <furq> or something [17:58:50 CET] <furq> maybe lt(mod(t\,100)\,1) because i don't remember how that deals with float timestamps [17:59:37 CET] <kepstin> if the input's cfr (and it hopefully is, since you'll need to use something like setpts to remove the timestamp gaps), you can also go on frame count, which is a bit easier since it's integers [18:08:50 CET] <sybariten> so you think it's actually doable? [18:09:11 CET] <sybariten> It comes straight from a camcorder so i'd definitely imagine CFR, prolly 25 fps [18:14:14 CET] <aruns> Hey guys, using FFMPEG on Windows to record some activity on Google Chrome. [18:14:54 CET] <aruns> I am using FFMPEG 2.8.4 - if I use FFMPEG to record a specific window specified by title, is it possible to show other windows that overlay on top? [18:15:07 CET] <aruns> For instance, I want to show a DevTools window that displays in front of the window. [18:16:20 CET] <kepstin> aruns: first of all, upgrade your ffmpeg, 2.8 is *really* old. [18:16:51 CET] <kepstin> aruns: but anyways, when using the 'gdigrab' capture method selecting a window, it gets that window (and only that window), it will not capture things drawn over it. [18:17:29 CET] <kepstin> aruns: if you want to capture overlapping windows, you need to capture the full screen, or a section of the screen (you can choose what region to select by pixels) [18:17:52 CET] <kepstin> aruns: but note that ffmpeg's screen capture on windows is kinda slow, depending on the application you might consider using OBS instead. [18:19:38 CET] <aruns> kepstin: Yeah, I might specify the X and Y coordinates, but wasn't sure if it was easy to get or not from the Windows command line. [18:20:24 CET] <kepstin> aruns: you could always just capture the full screen and crop the video later when editing it. [18:21:37 CET] <sybariten> Just chiming in that I've used OBS a little and been quite satisfied with the result, once you get the hang of it it's a very good tool. I never did something like taking things that display in front of a specific window though [18:22:41 CET] <kepstin> (also, in many browsers you can configure devtools to open in the same window as the page content, which might work for you) [18:23:34 CET] <aruns> kepstin: I can, but I'm highlighting a bug on a friend's website and wanted it to be unobstrusive. [18:24:48 CET] <aruns> Oh, apparently window information is stored in the registry. [18:25:00 CET] <kepstin> note that ffmpeg has an option to draw a rectangle around the selected screen area - you might do something like capture some size area, then just move the windows you want into the rectangle so they're in the video. [18:26:59 CET] <aruns> In terms of editing, my laptop doesn't have the greatest specs, so I just want to be able to record the video in the selected area. [18:27:22 CET] <aruns> I'll fish around for the coordinate data in the registry, if I can't find it in there, I'll try another of your suggestions. [18:28:51 CET] <kepstin> yeah, that's one of the benefits of obs - it uses a lower-cpu-overhead method of screen capture, (and it might be easier to configure to use hardware encoder if your laptop has one - most recent stuff does) [18:29:46 CET] <BtbN> On Windows it uses pretty much the same window capture method that ffmpeg uses [18:30:17 CET] <kepstin> hmm? i thought it had some directx hooks to pull frames from the compositor in vram, or something like that [18:30:28 CET] <BtbN> That's Game Capture [18:30:39 CET] <BtbN> Only works for games that use one of the 3D APIs to render [18:30:53 CET] <BtbN> And is frequently blocked by Anti-Cheat, or gets people banned [18:31:16 CET] <kepstin> ffmpeg's windows capture (gdigrab) uses some ancient windows apis, pre-xp stuff, that has to copy stuff out of vram and convert it into a windows BMP image in system ram :/ [18:31:48 CET] <kepstin> (admittedly, I think it's not really any worse than what e.g. chrome or firefox use for screen capture) [18:32:01 CET] <BtbN> Depends what you mean. For Fullscreen-Capture OBS uses Desktop Duplication when available [18:32:10 CET] <BtbN> For capturing individual windows, it uses that exact GDI api [18:32:57 CET] <kepstin> hmm, then it would do the same thing as ffmpeg when capturing individual windows, where it wouldn't include overlapping windows [18:33:10 CET] <kepstin> so aruns would have to use the fullscreen capture anyways [18:33:26 CET] <BtbN> Of course it doesn't include overlapping Windows. It used to do that in old Pre-Win8 days, but it was fixed [18:33:46 CET] <kepstin> and i bet the desktop duplication fullscreen capture and crop is faster than ffmpeg's gdigrab fullscreen subregion capture. [18:34:05 CET] <BtbN> It only uses Desktop Duplication for actual fullscreen capture [18:34:11 CET] <BtbN> not for individual Windows [18:34:34 CET] <kepstin> right, but in this case the individual windows option can't be used, because the point is to capture overlapping windows. [18:34:47 CET] <BtbN> You will only ever get that with Fullscreen Capture [18:34:56 CET] <kepstin> great, we agree then :) [18:35:10 CET] <TheAMM> Gimme a cool witty name for the desktop duplication capture (ala gdigrab) and I'll try to throw a PR before new year [18:35:32 CET] <BtbN> Desktop Duplication Capture is far from trivial to implement [18:35:34 CET] <TheAMM> Something that's both obviously descriptive and short [18:35:48 CET] <TheAMM> Oh, no, I've had it for way too long locally [18:35:58 CET] <aruns> I see, thanks kepstin and everyone else. [18:36:14 CET] <aruns> Couldn't see any information on Chrome windows in either the Windows Registry or in AppData. [18:36:16 CET] <TheAMM> I'm sure it'll be torn to pieces but it works for me and IMO the code is fine-ish [18:36:16 CET] <BtbN> You need to do weird things with tracking changes, as it doesn't just give you images, but a list of changes to the previous image [18:36:23 CET] <aruns> So I suppose I'll just have to experiment with different coords. [18:36:28 CET] <BtbN> And then pull the image from the GPU [18:36:33 CET] <TheAMM> No problem [18:36:37 CET] <TheAMM> Done and dealt with [18:36:45 CET] <BtbN> So it needs to integrate with the d3d11va infra of ffmpeg [18:36:53 CET] <TheAMM> It already is [18:37:00 CET] <TheAMM> For some hw decoder or something [18:37:07 CET] <TheAMM> Even configure is set up with it [18:37:28 CET] <BtbN> Send it to the list then if it's so easy [18:37:39 CET] <TheAMM> <TheAMM> Gimme a cool witty name for the desktop duplication capture (ala gdigrab) and I'll try to throw a PR before new year [18:38:04 CET] <TheAMM> The issue is that handling rotated or special DPI displays is a bother, and I haven't done that [18:38:23 CET] <TheAMM> But it's certainly a whole lot better than gdigrab if you want dem frames [18:39:32 CET] <TheAMM> Actually another issue is the whole realtime input thing, because ffmpeg will request a frame and then warm up the encoders [18:40:16 CET] <TheAMM> So you'll get the first frame stuck for some amount of time (most visible with nvenc) [18:40:58 CET] <TheAMM> I've considered threads and rtbufsize but I really don't know how the mailing list will react to such things [18:45:10 CET] <aruns> Thanks, I got it working for my needs now. [19:21:23 CET] <capelino> hi all! [19:21:26 CET] <capelino> trying to build the latest version com github, getting this: "ERROR: libvpx decoder version must be >=0.9.1" on humble-video-captive. it says to report this error here. can anyone help me? [19:22:06 CET] <JEEB> that just means that the libvpx required for FFmpeg is higher than the version you have? [19:22:12 CET] <JEEB> I don't see a bug [19:22:58 CET] <JEEB> you can look at the details of how the check failed from ffbuild/config.log [19:24:07 CET] <kepstin> fixing that sort of thing is os-dependent, but a likely cause on many linux distros is that you don't have the libvpx-dev (or similar) package installed. [19:58:10 CET] <llogan> relaxed: is your lame compiled with --enable-nasm? [20:59:11 CET] <saml> if ffprobe says key_frame=1 does this mean the frame is I frame? [21:00:31 CET] <saml> ffprobe -select_streams v -show_frames -of json=compact=1 a.mkv |grep '"key_frame": 1' [21:00:47 CET] <kepstin> saml: there's a separate field that indicates the frame type [21:01:13 CET] <kepstin> but I think in pretty much all popular video codecs, key frames will by I frames (or IDR frames, but ffmpeg doesn't expose that) [21:01:52 CET] <saml> ah i see. thanks [21:04:38 CET] <saml> if there's a key frame roughly every 5 seconds, I cannot cut video at different boundary? [21:04:53 CET] <kepstin> saml: not without decoding and re-encoding the video. [21:06:11 CET] <__gh0st> Hi! Is it possible to get the AVPictureType from AVPacket, without decoding the packet? i.e I need to get the frame type of a packet. [21:06:55 CET] <saml> ffmpeg -f concat -i /tmp/concat.txt -c:a aac -c:v libx264 /tmp/combined.mp4 [21:07:03 CET] <saml> [mp4 @ 0x5595dd065ac0] Non-monotonous DTS in output stream 0:1; previous: 723380, current: 637086; changing to 723381. This may result in incorrect timestamps in the output file. [21:07:09 CET] <saml> I see a lot of these warnings [21:07:32 CET] <saml> even if I re-encode. concat.txt aren't necessarily at key frames [21:07:33 CET] <kepstin> saml: the concat *demuxer* that you are using is basically doing file cutting/joining without re-encoding, and therefore suffers from the limit that it can only cut on keyframes [21:08:04 CET] <saml> so i'll try concat filter [21:08:04 CET] <kepstin> you need to switch to use multiple individually decoded inputs then the concat filter if you want to cut/join at arbitrary points [21:09:01 CET] <saml> what is a decoded input? [21:09:34 CET] <kepstin> __gh0st: There's "parsers" available for a variety of codecs that can read data from the frames without decoding them. You might be able to get the info you want that way. [21:09:48 CET] <kepstin> saml: I'm just referring to a normal input specified with -i [21:11:47 CET] <__gh0st> kepstin: Thanks, I only need a h.264 parser, I think I can use libx264? [21:14:05 CET] <Hello71> x264 is only an encoder [21:14:07 CET] <kepstin> __gh0st: no, that's an encoder... libavcodec in ffmpeg includes an h264 parser. I'm not sure how to use it via the api, that's not something i've used before. [21:14:15 CET] <saml> hrm, so I need to extract hundreds of segments from a video and concat them. Maybe I need to write my own tool linking to ffmpeg libraries. the ffmpeg commandline will be long [21:15:16 CET] <__gh0st> kepstin: Okay, thanks! I'll go dig into that then. ) [21:15:45 CET] <kepstin> saml: one thing to try is to use -filter_complex_script with an input file, and then use the 'movie' filter to do inputs: https://www.ffmpeg.org/ffmpeg-filters.html#movie-1 [21:16:55 CET] <saml> wow i didn't know about filter_complex_script [21:17:51 CET] <saml> ah yeah hrm that could work. movie filter also has seek_point whoa [21:18:37 CET] <kepstin> Note that unlike the ffmpeg cli "-i" option, the movie filter doesn't reset timestamps to start at 0 when seeking. If you want to do this manually, add a "setpts=PTS-STARTPTS" filter after the movie filter. [21:18:52 CET] <kepstin> and you can use the 'trim' filter to cut the end point of your clips [21:19:39 CET] <saml> hrm it doesn't have -t equivalent [21:20:11 CET] <kepstin> saml: <kepstin> and you can use the 'trim' filter to cut the end point of your clips [21:26:11 CET] <kepstin> saml: i'd expect a (video only) script for this would look like https://gist.githubusercontent.com/kepstin/7e67d3d75339517423d494b124134954… [21:26:51 CET] <kepstin> it's a bit more complex if you add audio too, since you need more options to the movie filter to pull the audio+video together, and the audio has to be trimmed separately with atrim. [21:29:41 CET] <llogan> trim will require setpts before feeding it to concat filter [21:39:08 CET] <saml> kepstin, thanks. I did it https://gist.github.com/saml/312f3a11b8db3a64c0ab1a17b4b6b6d4 resulting out.mkv is sorta weird. it's duration is a lot longer [21:40:01 CET] <saml> oh i'll try moving setpts before concat, not before trim [21:40:18 CET] <kepstin> before trim is fine, in fact i'd expect issues after trim [21:40:28 CET] <kepstin> you're not using movie inputs tho? [21:40:41 CET] <kepstin> where's your inputs? [21:41:01 CET] <raytiley> can the concat filter work with subtitle streams? I'm getting `s` is not an option? [21:42:02 CET] <kepstin> raytiley: no. There's very few filters that can do anything with subtitle streams, iirc this is due to some general limitations in the filter framework [21:42:33 CET] <raytiley> kepstin: thanks [21:43:10 CET] <saml> kepstin, ffmpeg -i a.mkv -filter_complex_script filter.txt -map '[v]' -map '[a]' out.mkv [21:43:13 CET] <saml> i did it that way [21:43:24 CET] <saml> and use [0] in filter graph https://gist.github.com/saml/312f3a11b8db3a64c0ab1a17b4b6b6d4 [21:43:33 CET] <saml> using setpts after trim works perfect [21:43:41 CET] <kepstin> saml: ok, with that particular setup you have you would need setpts after trim, yeah [21:43:56 CET] <kepstin> tbh i'm kind of surprised that sending a single input to multiple filters like that works properly [21:44:10 CET] <saml> i feel like a video engineer [21:44:29 CET] <saml> now i can make video a lot shorter :P [21:47:31 CET] <Alina-malina> please help: [mov,mp4,m4a,3gp,3g2,mj2 @ 0000000000662de0] moov atom not found [21:47:40 CET] <Alina-malina> test.mp4: Invalid data found when processing input [21:48:39 CET] <kepstin> Alina-malina: your input file is truncated (incomplete download or cancelled encode, maybe) or otherwise corrupt, and therefore can't be played. [21:48:55 CET] <Alina-malina> omg is there a way to fix this? [21:48:59 CET] <Alina-malina> i was working on it so hard [21:49:01 CET] <Alina-malina> to create [21:49:49 CET] <kepstin> First - make sure that this doesn't happen again: When possible, use formats other than mp4 that can survive this type of error. [21:50:15 CET] <Alina-malina> its 8GB file [21:50:29 CET] <kepstin> In some cases it can be repaired - if you have another video from the same encoder/camera/whatever, or with tools that attempt to guess the right parameters [21:50:44 CET] <kepstin> but it's easier to just restore your backup copy, tbh. [21:50:54 CET] <Alina-malina> there is no backup copy [21:50:56 CET] <Alina-malina> thats the single file [21:52:09 CET] <kepstin> anyways, if you have another *working* video generated by the same program or device, you can try using https://github.com/ponchio/untrunc to repair it [21:52:59 CET] <kepstin> i think there's some proprietary tools around that can guess some repairs without a working sample file, but I don't have experience with any of them [21:55:01 CET] <kepstin> anyways, please take the lesson to heart: backup important stuff that you've put a lot of time into, and use formats other than mp4 (mkv is a good option) for long-running edits/encodes so that partial files can be recovered. [22:00:50 CET] <Alina-malina> kepstin, lmao, dude it was a desktop record itself, you cant make a backup from the stream you making from.... [22:01:01 CET] <Alina-malina> kek [22:01:41 CET] <kepstin> well, the second half of my statement covers that case. [00:00:00 CET] --- Thu Dec 20 2018

1 0

ffmpeg-devel.log.20181218
by burek 19 Dec '18

19 Dec '18

[00:00:29 CET] <JEEB> also most of all this really concerns me regarding the future because I do not know why this happened, and how I could make this stuff go through simpler. should I have said more clearly, earlier that I would like him to tell me specifically what was being required? I dunno [00:02:26 CET] <BradleyS> i wouldn't blame yourself, especially since this is not a rare incident [00:03:22 CET] <JEEB> and it's really weird since before I've posted quotes out of specs and he's thanked me for the check/review [00:19:17 CET] <jkqxz> atomnuker: I'm not sure that the visible responses there mean very much. The only people who can actually push things are Intel. [00:20:46 CET] <jkqxz> Though tbh I agree with the general position that the driver should be codec-only, and shouldn't include the WSI elements. If a change in EGL and Wayland breaks the codec library, something is wrong. [00:27:47 CET] <JEEB> michaelni: commented on the MPEG-TS subtitle case. that was one of the original alternatives I thought of, but since it was way too open ended I decided to not go for it. [08:31:12 CET] <cone-663> ffmpeg 03Zhong Li 07master:978c935f2f65: lavc/qsv_hevc: correct QSV HEVC default plugin on Windows [10:08:34 CET] <ubitux> note: display matrices may contain something else than a rotation; i have a case here where it's a vflip [10:09:01 CET] <ubitux> (due to the classic GL thing) [10:09:17 CET] <ubitux> with apple+mov [11:42:52 CET] <durandal_1707> michaelni: i see no way too find which stream reached EOF with .interleave_packet [11:56:47 CET] <michaelni> durandal_1707, the flush parameter would be set during trailer writing (and for one other case that would need to be distinguished). When flush is reached no more packets should get added into the buffers so the buffer content should work to indentify what is last. [11:56:57 CET] <michaelni> maybe theres a easier way, i dont know [11:59:06 CET] <michaelni> maybe st->last_in_packet_buffer can be used to simplify this [12:03:49 CET] <cone-319> ffmpeg 03Shiyou Yin 07master:76952aa46163: avcodec/mips: [loongson] enable MSA optimization for loongson platform. [12:24:15 CET] <JEEB> michaelni: I guess we have a difference in opinion regarding data that comes before PCR :) since in theory everything that comes before PCR is non-trustworthy :) [12:24:29 CET] <JEEB> (in my opinion) [12:25:40 CET] <durandal_1707> michaelni loves implementing hacks on top of hacks [12:25:58 CET] <JEEB> I wouldn't say it that way [12:26:22 CET] <JEEB> it's valid to want that result, but it's case of effort VS reward [12:26:40 CET] <JEEB> (and then consider the actual format you're basing your logic on) [12:35:31 CET] <michaelni> JEEB, if you prefer the simple solution iam fine with that too but i might (if i find time) rewrite it to do the buffering so the timestamps arent lost in the cases this affects [12:38:33 CET] <JEEB> yea, that sounds good. I think we have some data structure for growing buffers [12:50:40 CET] <JEEB> (although the real problem is in what sort of state are you going to start buffering? the full "pes" structure with buffer?) [12:50:57 CET] <JEEB> (or just the AVPackets - for which you then have to start poking at some other points) [12:52:19 CET] <JEEB> michaelni: also if you're interested in how f.ex. ffmpeg.c currently handles that sort of stuff, `ffmpeg -txt_format ass -fix_sub_duration -i https://kuroko.fushizen.eu/samples/2018-04-04-funky_teletext_mux.cut.ts -c:v libx264 -crf 21 -preset fast -c:a aac -b:a 192k -c:s ass out.mkv` for example is a good way to test :) [12:52:22 CET] <nevcairiel> finished AVPackets with missing timestamps seems like the most logical to me, unless you need a b unch of extra information to reconstruct the timestamp later, which cant be stored with it? [12:53:18 CET] <JEEB> nevcairiel: also this reminds me I should throw at least one of your patches onto the ML from your fork :P [12:54:22 CET] <JEEB> and compare that to what happens with the patch :) [12:54:34 CET] <nevcairiel> one of the mpegts things? [12:54:42 CET] <JEEB> I think it was some wrap-around hnadling thing [12:54:47 CET] <JEEB> "skip teletext" or so [12:54:52 CET] <JEEB> as in, don't use it as reference [12:54:54 CET] <nevcairiel> oh that [12:55:50 CET] <nevcairiel> it can probably be even more generic and dont use anything but audio/video for wraps, any other data can be rather spurious [12:56:12 CET] <JEEB> yea [12:57:47 CET] <JEEB> also talking of that [12:57:53 CET] <JEEB> I have some Japanese patch which I don't get [12:57:57 CET] <JEEB> but it helps with at least one sample [12:58:03 CET] <JEEB> I might just throw that one out there as well [12:59:02 CET] <JEEB> https://github.com/jeeb/ffmpeg/commit/dfeeeb226094a8b00f7319b89e4d3b3660326… [13:05:20 CET] <JEEB> a sample where that improves things was if I recall correctly http://kuroko.fushizen.eu/videos/pid_switch_sample.ts [13:05:26 CET] <JEEB> https://kuroko.fushizen.eu/screenshots/ffmpeg/blue_vanilla-orange_patched.p… [13:05:33 CET] <JEEB> that's the timestamp values graphed [13:06:29 CET] <durandal_1707> michaelni: the EOR packets injected into interleaver are of data size 0 ? [13:06:40 CET] <nevcairiel> those pid change streams probably trip up all sorts of logic [13:10:24 CET] <michaelni> durandal_1707, yes [13:20:56 CET] <durandal_1707> michaelni: ffmpeg -f lavfi -i sine=d=3 -f lavfi -i sine=d=1 -f lavfi -i pal100bars=d=2 -map 0 -map 1 -map 2 -c:v rawvideo -c:a pcm_s16le t.nut <<<<<-- with this one i receive flus too late [13:21:56 CET] <durandal_1707> michaelni: *flush, this is all flawed design which can not be fixed in code [14:18:54 CET] <cone-319> ffmpeg 03Michael Niedermayer 07master:568e1b229b85: avfilter/scene_sad: Fix funtions typos [14:33:06 CET] <kwizart> Hi, I have a license question as I wanted to have a LGPL ffmpeg built with cuda, I fail to understand why it would not be redistributable ? is it because it would be a derrived work ? thx for any advices... [14:33:40 CET] <JEEB> the enable-nonfree requirements in configure I think need to be better set. currently a lot of stuff is not nonfree if FFmpeg is configured as LGPL [14:34:16 CET] <JEEB> which it seems like hearing opinions from j-b etc that that is not true, since then oyu are no longer able to abide by the LGPL and giving out the code for the LGPL dependency in full [14:34:25 CET] <BtbN> cuda is one of the few cases which is not even lgpl compatible [14:34:31 CET] <BtbN> primarily due to it needing nvcc to be built [14:35:36 CET] <j-b> JEEB: hmm, difficult. LGPLv2 and v3 differ on that section [14:36:24 CET] <JEEB> ok, so we definitely need to then refine the configure checks and possibly divide "nonfree" libraries into multiple groups [14:36:38 CET] <JEEB> currently it's just dumb "if not GPL, nonfree is in various cases OK" [14:36:42 CET] <JEEB> if not always [14:38:02 CET] <BtbN> To build the CUDA filters you need nvcc which you can only get after registering with nvidia and accepting their EULA [14:38:21 CET] <JEEB> esp. since we have some nonfree stuff that is closed source, and some that is open source but just incompatible with the GPL (which is I think what the enable-nonfree option was originally for) [14:38:29 CET] <JEEB> which is why the check for GPL is incorporated there [14:38:54 CET] <kwizart> BtbN, I don't think there is any issue to compile GPL(or LGPL) code with a close source compiler (maybe I'm wrong and that's the point) or it would not be possible to build any GPL/LGPL code with windows compiler or solaris one etc... [14:39:15 CET] <BtbN> It wouldn't be a problem if there was an alternative [14:39:37 CET] <BtbN> But as it is right now, it's impossible to reproduce the build without getting nvcc from nvidia in the way described. [14:39:45 CET] <BtbN> And that very much is incompatible with both GPL and LGPL [14:42:11 CET] <BtbN> Some cuda filters, like the npp stuff, also needs an external closed source library which is not part of the driver, so does not fall under the system lib clause [14:43:40 CET] <j-b> JEEB: nonfree means not distributable. GPL or LGPL. [14:43:48 CET] <j-b> They have similar requirements. [14:44:32 CET] <j-b> kwizart: sorry, but I don't think that works. [14:44:37 CET] <JEEB> yes, but it is IMHO harder to repro the code for an LGPL build with not open source deps? [14:45:33 CET] <BtbN> As long as the closed source deps are freely available to everyone without accepting weird EULAs, it seems fine [14:46:14 CET] <kwizart> j-b, nonfree (as in the ffmpeg's configure) it totally unclear. One can has floss code but with incompatible license, that will also be non-redistributable (such as BSD with advertising with GPL) [14:46:59 CET] <durandal_1707> michaelni: what you want to do with EOR subtitle packets? and what with rest EOR packets? drop them? [14:46:59 CET] <BtbN> There are some edge-cases with stuff like that, yes. But for nvidia they are very very far of any edge. It's as nonfree as it gets. [14:47:04 CET] <j-b> BtbN: no, you need to also provide the relinking steps for this binary. [14:47:13 CET] <j-b> So, for Cuda, it would be fine if you: [14:47:21 CET] <j-b> - build the libray as a .so [14:47:33 CET] <j-b> - give the .o of the cuda part, for other people to relink. [14:48:13 CET] <BtbN> j-b, all our CUDA code is open, and the parts from nvidia are MIT licensed. The only thing holding it deep in nonfree is it needing nvcc to build the CUDA kernels, which are themselves also available as LGPL [14:48:27 CET] <kwizart> I think one can reproduce the build with cuda, it's just a matter to accept the specific EULA [14:48:40 CET] <j-b> ah, ok. [14:48:52 CET] <BtbN> kwizart, you cannot without registering with nvidia to get nvcc, which requires you to accept two separate EULAs [14:49:06 CET] <BtbN> sorry, but I fail to see how this is not incompatible with the requirements of the (L)GPL [14:49:13 CET] <bencoh> k/63 [14:49:24 CET] <j-b> this is clearly incompatible with LGPLv3 [14:49:32 CET] <j-b> where you need to actually be able to rebuild [14:49:42 CET] <j-b> For v2, this is debatable [14:50:03 CET] <j-b> depending if nvcc adds some code or not, and if that code is RE-able. [14:50:20 CET] <j-b> (See section 6 of the LGPLv2.1) [14:51:31 CET] <kwizart> j-b, I don't think one can rebuild say libreoffice (that using the ms compiler) without accepting the ms EULA (both msvc and os) [14:51:33 CET] <j-b> Because if it adds some code, and that code is not allowed to be RE-able, then, you cannot comply with LGPL, IIRC [14:52:13 CET] <j-b> kwizart: libreoffice is compilable with gcc and llvm [14:52:15 CET] <kwizart> but again, been abble to reproduce doesn't say without giving money (in this case) [14:55:16 CET] <j-b> I wish nVidia was more reasonable [14:57:12 CET] <michaelni> durandal_1707, in the demuxer ? yes, if EOR was created by the muxer the demuxer would drop it and only use it internally for seeking/duration [14:58:01 CET] <BtbN> j-b, nvcc converts .cu (which is basically normal C/C++) to a ptx file, which is then baked into libavfilter as a string, which is passed to the CUDA runtime to run on the GPU [14:58:40 CET] <j-b> BtbN: sure, but is the ptx file just the .cu converted or does it add more code? [14:58:44 CET] <BtbN> It has an extensive standard library to do so which is also understood by the GPU. clang has some attempts to replicate it, but it's far from trivial and unusable in its current statew [14:59:28 CET] <j-b> is that standard library RE-able? [15:00:06 CET] <BtbN> No idea, never looked into it that deep [15:00:24 CET] <BtbN> But it's definitely under their EULA, which forbids RE [15:01:21 CET] <j-b> Then, I believe this is not LGPL compliant. [16:14:03 CET] <philipl> there is some statically linked standard library that comes into play when building the ptx. [16:14:32 CET] <philipl> that's why trying to build a ptx with clang still requires the cuda sdk [16:15:05 CET] <philipl> or rather, trying to build the cu source. [16:15:42 CET] <philipl> it may be possible to write something that can compile to ptx without the cuda sdk but it requires giving up a bunch of stuff. [18:01:16 CET] <cone-873> ffmpeg 03Carl Eugen Hoyos 07master:06a436a224c0: lavc/mjpegdec: Interpret three-component Adobe transform 0 also as RGB. [19:02:33 CET] <cone-873> ffmpeg 03Paul B Mahol 07master:62dbcb7ddf10: avcodec/g723_1: add support for stereo files [19:02:34 CET] <cone-873> ffmpeg 03Paul B Mahol 07master:7a124138a719: avcodec/g723_1dec: reindent after last commit [19:02:35 CET] <cone-873> ffmpeg 03Paul B Mahol 07master:d283ee085f9a: avcodec/g723_1dec: improve stereo support [19:09:20 CET] <durandal_1707> CCCCCCCCCCCCCCCAAAAAAAAAAAAAAAAAAAARRRRRRRRRRRRRRRRRRRRRRRRRLLLLLLLLLLLLLL!!!!!!!!! [19:17:03 CET] <jamrial> JEEB: stop replying to that thread [19:17:26 CET] <jamrial> you'll get nothing out of it but another day of stress [19:17:53 CET] <JEEB> I still hang onto the thread of hope that we can improve this community [19:18:43 CET] <JEEB> but yes, it is quite possible that there will only be short reponses without real meaning other than noting that I am incorrect [19:18:52 CET] <jamrial> we can, but that thread is a lost cause. just look at his replies. [19:19:02 CET] <jamrial> and yes, that's what i mean [19:51:14 CET] <cone-873> ffmpeg 03Paul B Mahol 07master:c0fb6f963fd7: avformat/vorbiscomment: add support for writing chapters [19:55:49 CET] <JEEB> michaelni: did you have something against this btw? [19:55:51 CET] <JEEB> https://patchwork.ffmpeg.org/patch/10583/ [19:56:29 CET] <JEEB> because I think it's pretty important for the user to know if there's been discontinuities which ffmpeg.c has to handle? [19:57:31 CET] <JEEB> relevant issue from which these patches came was an example of the ffmpeg.c logic not doing the correct thing https://trac.ffmpeg.org/ticket/7482 [20:06:47 CET] <cone-873> ffmpeg 03Jan Ekström 07master:3a36b0c4b8f2: ffmpeg: improve the intra stream discontinuity message [20:17:53 CET] <michaelni> JEEB, i have no oppinion because i dont know how many warnings this would cause in practice. Also iam not sure warning is the best level [20:18:42 CET] <JEEB> for a live stream it would start appearing after lavf handles the first wrao-around, once per each 26h or so [20:19:00 CET] <JEEB> the sample in the ticket will get it a lot [20:19:17 CET] <JEEB> also no idea if warning is the right level, but if it starts spamming it's a clear sign that something's wrong [20:19:21 CET] <JEEB> and it being under debug [20:19:26 CET] <JEEB> will not make it visible to anyone [20:19:34 CET] <JEEB> esp. since IIRC we cannot control verbosity per-module [20:19:44 CET] <JEEB> so if you do -v debug [20:19:50 CET] <JEEB> you will get a lot of stuff [20:20:13 CET] <JEEB> info would be OK as well, but I definitely would make it visible by default [20:20:34 CET] <JEEB> if it gets hit often it seems like it most likely is hiding a problem somewhere [20:20:39 CET] <JEEB> or causing one [20:21:55 CET] <JEEB> I hope this makes sense [20:50:45 CET] <durandal_1707> michaelni: is latest nut patch ok now! (i will update fate before pushing) [00:00:00 CET] --- Wed Dec 19 2018

1 0

ffmpeg.log.20181218
by burek 19 Dec '18

19 Dec '18

[00:08:59 CET] <atoms118> does anybody know how I might stream using FFMpeg so that clients can connect/disconnect adhoc style? [00:10:26 CET] <kepstin> by using a streaming server that ffmpeg can send input to :/ [00:10:54 CET] <atoms118> ok well yes but aside from that [00:11:18 CET] <kepstin> other than that? by writing a multi-client server application that uses ffmpeg libraries internally [00:11:31 CET] <atoms118> ok then [00:11:37 CET] <atoms118> streaming server it is [00:11:56 CET] <kepstin> anyways, if you want some choices for the first option, something like nginx-rtmp might work well, or you can even have ffmpeg generate HLS or DASH directly and serve it with any plain webserver [00:13:34 CET] <atoms118> sounds good, thanks [03:01:13 CET] <Wiiplay123> Am I supposed to be able to do "ffmpeg -i %d.png -framerate 30 test.gif" to make an animated gif with transparent background if the PNGs have transparent background, or do I need to do something extra to make it work? [03:01:34 CET] <Wiiplay123> I just updated to the latest nightly Windows build in hopes that it would work but I can't figure it out. [03:23:26 CET] <Wiiplay123> I had to manually sort the layers in GIMP :( [09:00:29 CET] <quint> I'm trying to set the ouput bitrate using h264_vaapi, however, the -b:v option only changes the input bitrate to the intel chip, and the bitrate of the resulting output file never changes. How can I set the *output* bitrate of the stream from the chip? [09:01:50 CET] <pink_mist> input bitrate? 0_o is that a thing that exists? [09:01:54 CET] <quint> * when I set the bitrate, the video will show many compression artifacts, but the size of the output file does not reflect the quality whatsoever [09:02:10 CET] <quint> if that makes any sense [09:04:03 CET] <quint> pink_mist: by "input bitrate" I guess I mean to say the bitrate of the video as it goes into the encoder, as opposed to the "output bitrate" as it leaves the encoder... not even sure I'm correct in that assumption [09:04:46 CET] <pink_mist> but the input bitrate depends on the actual video source in question .. it's not a setting you can set [09:06:02 CET] <quint> well, I may be describing it poorly. [09:06:07 CET] <quint> I'm using the following command: [09:06:33 CET] <quint> ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -i bbb_sunflower_1080p_60fps_normal.mp4 -t 30 -vf 'format=nv12,hwupload' -c:v h264_vaapi -c:a copy file.mp4 -y [09:07:58 CET] <quint> when I add -b:v 1M, the bitrate that ffmpeg is encoding at is about 4-5M [09:08:25 CET] <quint> Mind you this is a 1080p video at 60fps so that certainly could be a factor [09:19:56 CET] <furq> where are you putting -b:v 1M [09:22:53 CET] <quint> furq: as the last option before the output filename [09:23:57 CET] <quint> As it turns out the bitrate is affected by this. qp seems to be the appropriate option to use in this case [10:40:43 CET] <Adcock> Hello [10:40:50 CET] <Adcock> Anybody here? [10:41:07 CET] <Adcock> ..._ _ _... [10:41:42 CET] <Adcock> I want to capture the whole desktop. [10:41:59 CET] <Adcock> But I don't want to tell ffmpeg the size of the video. [10:42:14 CET] <Adcock> I want full desktop to be recorded. [10:42:20 CET] <Adcock> How to do that? [11:21:17 CET] <justinasvd> Hi guys. Out of your experience, what's the minimum time interval that's worth seeking (as opposed to just do playing the frames normally)? [12:01:13 CET] <sybariten> Hey [12:01:27 CET] <Mavrik> o/ [12:02:40 CET] <sybariten> is there a way you can think of, that i could cut down say a 60 minute video to a few minutes, by having ffmpeg cut out portions evenly spread out alkl over it? [12:03:38 CET] <sybariten> I dont know how to explain this in a good way :) Sort of like a "supercut" but no real intelligence behind the cuts, i just want to "speed it up", but not by speeding the frame speed or antying, its more like "for each five minute segment just leave the first ten seconds" [12:05:04 CET] <relaxed> sybariten: you may be able to do it with aselect/select filter [12:05:55 CET] <sybariten> aha aha [12:07:10 CET] <relaxed> you could also stream copy segments and concat [12:08:00 CET] <relaxed> the latter being lossless [12:08:47 CET] <sybariten> phew, i'm gonna have to google a bit about this after lunch, but at least now i have a idea of way in, thanks [12:08:57 CET] <sybariten> i also saw something about ffconcat [12:09:53 CET] <sybariten> be back latger [12:11:27 CET] <relaxed> https://trac.ffmpeg.org/wiki/Concatenate [15:07:47 CET] <oliv3> hi there, i can't find a way to achieve CFR :( my program takes any video as input (with a pipe), converts to PPM, does things, then sends the output (also through a pipe) to another ffmpeg process for reencoding, output video is slower than the original, maybe i missed something ? commands are there: https://pastebin.com/RChAdyjv - any suggestion would be appreciated, thanks ! [15:13:16 CET] <furq> oliv3: add -framerate 30 before -i in the second command [15:18:49 CET] <oliv3> furq: thanks, will try this and let you know [15:24:45 CET] <Adcock> can I grab video from video card instead of x11? [15:24:57 CET] <Adcock> Or something.... [15:28:55 CET] <oliv3> furq: it's working perfectly now, thank you ! [15:36:42 CET] <Adcock> Please help. [15:36:57 CET] <Adcock> X11 Grab is slow and lagging. [15:36:57 CET] <BtbN> Define video cards. There are a few capture cards with linux support. Decklink and Magewell has a few, but they are on the expensive side. [15:36:59 CET] <Adcock> :( [15:37:17 CET] <Adcock> Oh. [15:37:38 CET] <BtbN> x11grab is the best you'll get for desktop capture I think [15:37:57 CET] <BtbN> Sure, you can loop your output through a capture card, but that's expensive [15:38:47 CET] <Adcock> Is there any other standard video grab device for desktop grabbing. [15:38:50 CET] <Mavrik> Also I doubt it's X11 that's the problem. [15:39:13 CET] <Adcock> Hmmm....... [15:39:24 CET] <Adcock> I think I get. [15:39:32 CET] <Adcock> But I am so...... [15:39:37 CET] <Adcock> Sorry guys. [15:40:00 CET] <Adcock> Forgive me if I wasted your time. [15:44:53 CET] <EEVV> hi, how do I fix `ERROR: nvenc requested, but not all dependencies are satisfied: ffnvcodec`? I tried to compile the git `nv-codec-headers` and install it but it still doesn't work [15:48:38 CET] <BtbN> You didn't install it correctly then. Cause that's what it's asking for. [16:09:28 CET] <debianuser> Adcock: "X11 Grab is slow and lagging" -- it should be fine unless you use it with some high fps on a slow pc. To test the performance of x11grab itself try: time ./ffmpeg -f x11grab -r 60 -s 1280x1024 -i :0 -t 30 -f null - [16:09:45 CET] <debianuser> Adcock: Also it could be it's not x11grab but pixfmt conversion being slow. To test that try: time ./ffmpeg -f x11grab -r 60 -s 1280x1024 -i :0 -vf format=yuv420p -t 30 -f null - [16:10:51 CET] <debianuser> (adjust resolution and fps to your needs) [16:13:16 CET] <BtbN> x11grab is pretty slow on some GPUs that are bad at copying back data [16:17:18 CET] <debianuser> Adcock: And IF it's the pixfmt conversion slowing down your encoding, I have some 3-years-old patch that sort of fixes that (it implements a shortcut for 0RGB32->YUV420P conversion)... Not sure if that's still needed, but if it is and you're willing to try - I can probably update it to current git. :) [16:19:09 CET] <JEEB> my condolences if you poked swscale [16:19:50 CET] <debianuser> Not much. I basically just copypasted "bgr24ToYv12Wrapper" into "bgr32ToYv12Wrapper" and adjusted some offsets. [16:20:03 CET] <JEEB> :) [16:20:29 CET] <JEEB> also I love it how the wording "Y12" still lives [16:25:22 CET] <debianuser> I don't even remember the exact format. I've read about it years ago when I was writing a patch, but I mostly forgot what exactly those subsampling numbers mean since then. :) [16:34:54 CET] <kepstin> the '12' comes from the 4:2:0 subsampling averaging 12 bits per pixel, iirc. [16:37:27 CET] <JEEB> yes [16:37:39 CET] <JEEB> the joke of course is that people tend to call it yv12 even if it's I420 :P [16:37:56 CET] <JEEB> since the only difference in MS systems between the two are the order of pointers to buffers [16:37:59 CET] <JEEB> Cb and Cr [16:52:00 CET] <Adcock> No guyz. [16:52:12 CET] <Adcock> I am trying to record stellaris. [16:52:19 CET] <Adcock> That is the culprit. [16:54:43 CET] <BtbN> Use OBS [16:57:14 CET] <Adcock> OBS? [16:58:06 CET] <Adcock> BtbN: ^^^ [17:01:48 CET] <TheAMM> Adcock: https://www.google.com/search?q=obs > https://obsproject.com/ [17:31:11 CET] <Mavrik> So you're trying to capture an OpenGL rendered game via X11 ? [17:31:17 CET] <Mavrik> On Linux? [17:32:45 CET] <debianuser> SimpleScreenRecorder was also good at capturing opengl games (and it uses ffmpeg for encoding anyway)... [17:35:41 CET] <BtbN> Isn't that the one that preload an OpenGL shim? [18:17:43 CET] <GuiToris> hello, which version of ffv1 codec should I use for intermediate files? [18:51:33 CET] <durandal_1707> GuiToris: last one [18:52:08 CET] <GuiToris> that's version 3, isn't it [18:55:09 CET] <GuiToris> I guess I should notice much difference as both version are lossless [19:04:02 CET] <InvisibleRasta> hello guys i am trying to convert amkv to avi so i can play it on the tv [19:04:13 CET] <InvisibleRasta> i saw on google i can ffmpeg -i foobar.mkv -vcodec copy -acodec copy foobar.mp4 but it gives me error [19:05:25 CET] <InvisibleRasta> https://paste.pound-python.org/show/EM03sdauaWL0qJSEA6Me/ [19:06:07 CET] <durandal_1707> which ffmpeg version? [19:06:24 CET] <InvisibleRasta> 1:4.1-1 [19:07:02 CET] <InvisibleRasta> https://paste.pound-python.org/show/zrfaIdhIZqm49fidg7Le/ [19:12:00 CET] <Adcock> Guys need help with watermark. [19:12:37 CET] <durandal_1707> InvisibleRasta: have you tried with that bitstream filter inserted? [19:14:35 CET] <InvisibleRasta> yeah it actually worked [19:14:44 CET] <InvisibleRasta> durandal_1707: id have onemore question [19:14:50 CET] <InvisibleRasta> how can i cut a video in two parts? [19:15:00 CET] <InvisibleRasta> without reencoding if possible [19:15:44 CET] <durandal_1707> -ss and -t with -c copy ? [19:16:32 CET] <InvisibleRasta> how sorry? [19:17:09 CET] <InvisibleRasta> can i jsut make it so it splits it in half [19:19:48 CET] <durandal_1707> InvisibleRasta: unfortunately there is not simple command to do that [19:21:48 CET] <InvisibleRasta> durandal_1707: so like this ? ffmpeg -i input.avi -vcodec copy -acodec copy -ss 00:00:00 -t 00:30:00 output1.avi [19:23:13 CET] <InvisibleRasta> ffmpeg -i input.avi -vcodec copy -acodec copy -ss 00:30:00 -t 00:30:00 output2.avi [19:24:15 CET] <durandal_1707> yes, did not tried [19:39:25 CET] <Adcock> Can watermarks be hard coded? [19:41:36 CET] <durandal_1707> yes [20:06:27 CET] <Adcock> durandal_1707: How? [20:12:24 CET] <durandal_1707> Adcock: with filters [20:12:54 CET] <Adcock> durandal_1707: I applied filters. [20:13:14 CET] <Adcock> Does it mean there is no way to separate the watermark ? [20:13:48 CET] <Adcock> Like they are one image. [20:14:07 CET] <Adcock> Not two video channels. [20:15:18 CET] <durandal_1707> you apply overlay filter and reencode video [20:16:38 CET] <Adcock> durandal_1707: https://ptpb.pw/j8NZ [20:16:47 CET] <Adcock> Will that work? [20:17:00 CET] <Adcock> http://ksloan.net/watermarking-videos-from-the-command-line-using-ffmpeg-fi… [20:17:08 CET] <Adcock> This is where I got it. [20:17:55 CET] <durandal_1707> that will overlay watermark in midddle of video [20:18:21 CET] <Adcock> Is it hard coded? [20:18:37 CET] <durandal_1707> off course it is [20:18:44 CET] <Adcock> :) [20:18:54 CET] <Adcock> Thank you. [22:50:34 CET] <Keshl> Quick sanity check: I've been googling about how to enable VFR for x265. I am aware of the risks of doing this, and I plan to do a lot of experiments first to make sure that the footage plays back as expected in the players that I want to ensure compatibility with. Googling how to enable this just turns up losts of angry posts about people telling other people not to do it because it's questionably compatible, and not actually how to do [22:50:35 CET] <Keshl> it and test these claims for myself. Is it possible to do VFR with x265? [22:52:35 CET] <Keshl> (See, normally I wouldn't care that much, but the source video outright pauses for a good 5-10 minutes at times, during which I can still see the file size increasing with ffmpeg. I figure VFR'll address a lot more with my particular input than it would with more typical input.) [22:56:52 CET] <kepstin> Keshl: shouldn't be any issues from the ffmpeg point of view to do vfr with x265, as long as you're writing to a container that supports it properly. [22:57:59 CET] <Keshl> Okay, thajk'ye, I'll keep trying to find useful resources, then. (Unless you'd be so kind as to hand me some. <É<' -- Seriously, I can't find /squat/ on this.) [22:59:43 CET] <kepstin> well, there's nothing really that special about vfr, it's just when the timestamps change by different amounts between frames instead of the same amount every time. Unless you add other options, the ffmpeg cli tool should preserve relative frame timing (aka vfr) by default. [23:00:30 CET] <kepstin> although some particular choices of output container, or misdetection of the input as cfr when it's actualy vfr, might cause issues [23:00:43 CET] <Keshl> Okay, that makes sense, and I just found https://superuser.com/questions/908295/ffmpeg-libx264-how-to-specify-a-vari… which made something click. [23:00:49 CET] <Keshl> Turns out, I have a problem. <.<' [23:01:33 CET] <Keshl> So, the input stream really is VFR. I'm recording a game. When I tab out, it actually quits producing frames. Like, ffmpeg just legitinimately gets no input. Since I'm streaming as well as recording, I have to use CFR for that, so ffmpeg inserts duplicate frames to keep things sane. That part's fine. [23:01:49 CET] <kepstin> hmm, you're using obs or something for that? [23:01:50 CET] <Keshl> What isn't so happy for me is that, now I have a CFR recording full of duplicate frames that I need to drop. [23:01:53 CET] <Keshl> (OBS, yeah.) [23:02:41 CET] <Keshl> So basically, I have an .mkv file, CFR, with duplicate frames up the wazoo, that I want to take and make into VFR so I don't have duplicate frames for 10+ minutes at times. If I just do -vsync 2, it'll still have duplicate frames, right? [23:03:11 CET] <kepstin> yeah, you have to filter the video to remove the duplicated frames [23:03:19 CET] <kepstin> handily, ffmpeg has a filter that does that - "mpdecimate" [23:03:25 CET] <Keshl> Okay, that's where I kept getting hung up on. Okay. Was Googling for the wrong term. [23:03:33 CET] <Keshl> Thank. You. o_o [23:03:59 CET] <kepstin> https://www.ffmpeg.org/ffmpeg-filters.html#mpdecimate is the docs [23:04:23 CET] <kepstin> Keshl: you might have to adjust the dropping thresholds a bit - the defaults look for "similar" frames, and it might drop too many [23:04:27 CET] <Keshl> See, I kept doing that -vsync stuff and was like "...The file size is almost identical. There's no way the ME is /that/ good with CFR in this situation. Something's gotta be wrong.". [23:04:48 CET] <Keshl> (Honestly, if I can make it drop similar frames, I'll do a happydance.) [23:05:11 CET] <Keshl> (Sometimes I'll pull an inventory up but not pause the game, so there's a very subtle background animation. I'd /love/ to just utterly nuke that, too.) [23:06:09 CET] <kepstin> if you have multi-minute gaps this'll probably reduce file size a bit, but at the expense of players having difficulty seeking near the gap. [23:06:33 CET] <kepstin> for shorter gaps, it'll probably make very little difference in file size (codecs are already really good at compressing similar/same frames) [23:06:49 CET] <Keshl> The gaps are truly massive, and frequent in some of the videos. [23:06:53 CET] <kepstin> it should make encoding faster, at least. [23:07:11 CET] <Keshl> I figure seeking will be a nightmare with all this, but I'm fine. I'll just turn playback speed up instead to get to where I want to go. [23:07:55 CET] <Keshl> Thank you so much. Seriously. o_o [23:07:58 CET] <kepstin> do you need to keep the audio from these sections? it might be best to trim these sections out of the video completely instead of having a long gap in the file [23:08:23 CET] <kepstin> (but that's probably a bit more work, ffmpeg won't be able to automatically do that) [23:08:28 CET] <Keshl> In some cases I do, some I don't. The only way I'll know for sure is if I actually watch the whole thing, which I don't wanna do. [23:08:51 CET] <Keshl> I can give you a full run-down of what I have and what I'm trying to achieve if you want, but I don't want to drag you into something deeper than you planned on. [23:09:06 CET] <Keshl> (Seriously, none of this is terribly "normal".) [23:09:36 CET] <Keshl> Heh, I was about to ask if it can be done automatically. <É<' [23:09:56 CET] <kepstin> anyways, if all you want to do is drop similar frames and get a vfr video back, just add "-vf mpdecimate" to your ffmpeg command line. [23:10:11 CET] <Keshl> I don't need -vsync 2? Just -vf? [23:10:42 CET] <kepstin> -vsync 2 is unrelated, it can help in some cases where you have vfr input that's not handled correctly otherwise. You shouldn't normally need iot [23:11:36 CET] <Keshl> Okay, thank'ye. One other question before I forget, hold on.. Gotta remember the specifics.. [23:11:38 CET] <kepstin> Anyways, you'll probably want to adjust some of the dropping threshold options on the mpdecimate filter depending on your content, if it's dropping too much or too little. You can also set a max number of frames in a row to drop if you just want low framerate output instead of no frames - this might help seeking. [23:14:24 CET] <Keshl> I'll experiment. Okay, there it is.. [23:15:00 CET] <Keshl> So, unsurpriswengly, I also have long stretches in my audio where there's utter and complete silence (Again, actual output just *stops*.). Clearly VBR would help there. I already know how to do that with mp3. [23:15:17 CET] <Keshl> My concern is, with VBR audio and VFR video, would things become unsynced? Would "-af "aresample=async=1:min_hard_comp=0.100000:first_pts=0"" help fix anything? [23:16:07 CET] <Keshl> (You might wonder why I don't just cut the recording when I know these input drops are happening. Well, see, I forget to do that.) [23:19:48 CET] <kepstin> Keshl: vbr codecs keep sync just fine. In fact, most codecs ffmpeg supports are vbr. [23:19:59 CET] <kepstin> mp3's one of the rare ones that actually supports non-vbr mode [23:21:15 CET] <Keshl> Oh. In that case, how can I check if the audio's already vbr or not? I recorded in aac. [23:22:06 CET] <kepstin> it's probably vbr then, most aac encoders are? [23:23:37 CET] <Keshl> Still. <É<' [23:24:02 CET] <Keshl> Due to how OBS' settings work, I have high reason to suspect it's CBR. [23:28:47 CET] <Keshl> https://trac.ffmpeg.org/wiki/Encode/AAC#NativeFFmpegAACEncoder Fwee. <.<' I don't have the "good" one, so VBR's gunna stink. D: Oh well. [23:30:36 CET] <Keshl> ...Oh. Works totally fine. I don't hear a difference. Okay. Cool. o.=.o. And the audio track's like half the size it was before. [23:31:59 CET] <Keshl> Now all I want is some way to automatically detect "empty" audio streams (there's four in each file, and at least one will always be populated, but the others may be silent but present) and then remove them if they're dead-silent the entire time. [23:32:29 CET] <Keshl> Then again, with VBR, maybe it won't matter. Let's see.. [23:32:45 CET] <Keshl> Yeah, okay, 1.5 meg/hour, I can live with that. [23:39:13 CET] <Keshl> Does ffmpeg -i "Original.mkv" -vcodec libx265 -preset veryslow -crf 28 -movflags faststart -pix_fmt yuv420p -acodec aac -q:a 2 -map 0 -tune grain -vf mpdecimate=0=61*12=64*5=0.75 "Archive.mkv" seem sane? I can never remember the syntax for specifying paramaters for filters. [23:44:08 CET] <Keshl> Nope. Decimate doesn't like that input. Without any input though, holy living bagels, it encodes incredibly fast. o_o' [23:46:33 CET] <Keshl> -vf mpdecimate=max=0:hi=61*12:lo=64*5:frac=0.75 -- There we go. Okay. All happy. [00:00:00 CET] --- Wed Dec 19 2018

1 0

ffmpeg-devel.log.20181217
by burek 18 Dec '18

18 Dec '18

[00:11:47 CET] <Compn> Original Codec (OC) pls do not steal :D [01:49:34 CET] <cone-497> ffmpeg 03Carl Eugen Hoyos 07master:63977ac38f90: configure: Use "clang" as cc_default for Android. [02:01:05 CET] <JEEB> can someone push https://github.com/jeeb/ffmpeg/commits/dolby_vision_in_isobmff through FATE? I mean, it just adds new identifiers so it should be highly unlikely for it to break FATE, but just in case :P [02:08:26 CET] <adrianOO7> okay, registered, now should work [02:08:29 CET] <adrianOO7> hi! [02:09:12 CET] <adrianOO7> got a problem, I've compiled ffmpeg 4.1 for arm platform (buildroot) and I've been using it to encapsulate camera capture into HLS segment files [02:10:05 CET] <adrianOO7> one feature I've been using is temp_file flag, on my host machine it works fine, but once I've moved to target device, temp files does not appear, instead I get 0-bytes files [02:10:45 CET] <adrianOO7> I've attached GDB and looked up values and for some reason HLS_TEMP_FILE flag isn't set on AVFormatContext instance [02:11:58 CET] <adrianOO7> I've also checked parsed options and indeed temp_file shows up in hls_flags as set (among other flags I've been playing around) [02:13:31 CET] <adrianOO7> it got me wondering whether proper object is probed for this flag, given a piece of code in hlsenc.c:1456, that is int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & HLS_TEMP_FILE); [02:14:08 CET] <adrianOO7> test for flag yields 0, but if I eval expression hls->flags & HLS_TEMP_FILE - it actually gets it right [02:15:57 CET] <adrianOO7> sorry, c->flags; anyway, removing temp_file from hls_flags and re-evaluating this code gives proper results: s->flags & HLS_TEMP_FILE and c->flags & HLS_TEMP_FILE yields 0 [02:16:51 CET] <adrianOO7> seems obvious it's a bug, but it's the first time I dig inside ffmpeg code, so want to be sure before I start working on a patch [02:20:54 CET] <adrianOO7> BTW there's also inconsistency between checks whether one should use temp file or not - there's a check for proto for s->url (playlist in this case) and oc->url (which is segment file) - while s->url could be actual local file, I believe segment files can be defined as remote (i.e http) - that, in combination with proper flag checking would give a false-positive check for segment file being allowed to be temp file [07:51:46 CET] <cone-228> ffmpeg 03kjeyapal(a)akamai.com 07master:d209a3d50f9c: avformat/dashenc : Refactored HLS media playlist related code [07:51:46 CET] <cone-228> ffmpeg 03kjeyapal(a)akamai.com 07master:f22fcd4483fc: avformat/dashenc: Added support for Low-latency HLS(Experimental) [07:52:20 CET] <j-b> seriously, configuring git shortname is not hard. [08:22:58 CET] <JEEB> asdf [08:23:22 CET] <JEEB> now supposedly implementing a thing according to a specification is "the issue" [08:24:01 CET] <JEEB> as if we are not already the butt of "you feed ffmpeg a broken and spec compliant file - guess which will work?" [08:24:04 CET] <JEEB> jokes [08:24:36 CET] <JEEB> i know having samples is always better but if chromium, vlc already added this stuff... [08:24:58 CET] <JEEB> and if the spec seems to hold for the effing samples we have [10:34:01 CET] <JEEB> ping for https://patchwork.ffmpeg.org/patch/11430/ , btw [10:34:27 CET] <JEEB> (sample where this fixes lavf passing through invalid timestamps is linked in the previous iteration of that thing) [10:34:43 CET] <JEEB> https://patchwork.ffmpeg.org/patch/11419/ [11:13:20 CET] <durandal_1707> just apply it [11:16:41 CET] <JEEB> I'm trying to believe that we still have a workflow :P [11:17:58 CET] <JEEB> (also I do not have my FFmpeg keys at $dayjob) [11:19:14 CET] <JEEB> also wut [11:19:15 CET] <JEEB> src/libavcodec/cfhd.c:139:20: warning: unused function 'process_alpha' [-Wunused-function] [11:27:16 CET] <durandal_1707> gsoc student [11:27:49 CET] <durandal_1707> kierank will fix it soon [11:38:55 CET] <JEEB> also I need to ping all of my other patches, too :| [11:42:02 CET] <durandal_1707> stop pinging if it is ignored all the time, just apply it [11:44:28 CET] <JEEB> I want to believe into a workflow! [11:44:39 CET] <JEEB> that we can be civilized and technical [11:45:08 CET] <JEEB> and I did already note a week ago that I'll apply one of the patches, so if there's literally no life whatsoever I will start noting that. [13:20:59 CET] <durandal_1707> michaelni: how to add EOR flag if NUT use this weird frame_code stuff? [13:30:42 CET] <michaelni> if a framecode with EOR exist that will be used otherwise a framecode with explixitly coded flags would be used and the EOR coded in these flags [13:33:40 CET] <durandal_1707> michaelni: can EOR packets have syncpoint? [14:06:32 CET] <JEEB> can someone run FATE on the MPEG-TS patch I posted and the dolby vision isom.c patch? [14:06:40 CET] <JEEB> I still don't have the full set somewhere :P [14:07:06 CET] <JEEB> I don't expect anything to break, but I want to be a nice guy and at least make sure things pass [14:31:29 CET] <michaelni> durandal_1707, i think you can put syncpoints before any frame including eor [14:32:44 CET] <JEEB> mpeg-ts: https://patchwork.ffmpeg.org/patch/11430/ , dolby vision ids: https://github.com/jeeb/ffmpeg/commits/dolby_vision_in_isobmff [14:40:36 CET] <cone-008> ffmpeg 03Carl Eugen Hoyos 07master:0b7269e62d03: lavc/cbs: Do not use format specifier "z" on Windows. [14:45:54 CET] <cone-008> ffmpeg 03Carl Eugen Hoyos 07master:826655d8d117: lavfi/program_opencl: Do not use format specifier "z" on Windows. [16:12:10 CET] <durandal_1707> michaelni: what is dts for syncpoint before EOR packet? [18:27:02 CET] <atomnuker> jkqxz: how long do lgtm'd PRs stay unmerged on libva? [18:27:28 CET] <atomnuker> vaapi with wayland has been broken since october (and since mesa 18.3) [18:42:27 CET] <cone-008> ffmpeg 03chcunningham 07master:ee1e39a57697: lavf/id3v2: fail read_apic on EOF reading mimetype [19:21:26 CET] <cone-008> ffmpeg 03Paul B Mahol 07master:d54276f9def8: avfilter/af_apad: add pad_dur and whole_dur options [20:55:31 CET] <durandal_1707> michaelni: can one add extra packet in .interleave_packet ? [21:08:23 CET] <cone-008> ffmpeg 03Paul B Mahol 07master:7b2a9aaa0b78: avformat/mxfenc: fix typo [21:10:22 CET] <JEEB> fucking vittusaatana [21:10:38 CET] Action: JEEB calms down and starts writing a reply [21:17:40 CET] <durandal_1707> lol [21:18:09 CET] <JEEB> there [21:20:29 CET] <durandal_1707> will there be vittusaatana 2 ? [21:22:33 CET] <JEEB> michaelni: what's the process if cehoyos blocks my patch officially? [21:23:03 CET] <JEEB> I do not want this to be a protracted beating-around-the-bush kind of thing [21:23:30 CET] <JEEB> I've already wasted enough time on this simple enough patch that I feel looking at the six points that I've noted should be correct enough and matching what's specified [21:23:54 CET] <JEEB> I do not know if we have ever had a set-in-stone requirement for each change set to have a matching sample available [21:24:03 CET] <durandal_1707> carl can not block patches, he is irrelvant to our project [21:26:03 CET] <durandal_1707> carl just officially approved your patch with single condition to mention ticket #7347 [21:26:58 CET] <jamrial> JEEB: carl wanted to add bullshit non official tags to mov just to make some crappy files play before [21:26:58 CET] <durandal_1707> not real condition ... just he will be very happy... [21:27:12 CET] <jamrial> he has no argument to block a mp4ra tag [21:27:14 CET] <jamrial> just ignore him [21:29:29 CET] <durandal_1707> do not ignore Carl, Carl is officially FFmpeg project leader! [21:29:52 CET] <JEEB> he is not, but I do not want to be the person getting burned for not following project guide lines or rules [21:30:13 CET] <JEEB> I feel like I've done my due dilligence with regards to those IDs [21:31:04 CET] <JEEB> durandal_1707: funny enough I'm against mentioning it getting fixed because we still cannot present these pictures [21:31:12 CET] <JEEB> we only gain capability of demuxing/decoding [21:31:20 CET] <JEEB> (fucking dolby proprietary bullshit perkele) [21:31:30 CET] <durandal_1707> rules are there to break them, i do it all the time, i'm rogue dev [21:34:00 CET] <iive> JEEB, the say it partially fixes it. [21:35:35 CET] <JEEB> at this point I've wasted enough time rewriting comments or commit message for that asshole of a patch, I am not touching it unless someone says there's something substantial to add to it [21:36:05 CET] <JEEB> I'm sorry [21:36:37 CET] <JEEB> at this point I'm tired and feel angry because someone kept seemingly blocking a patch while not saying it clearly [21:36:52 CET] <JEEB> so this simple patch was just there in the goddamn ether [21:37:24 CET] <michaelni> <durandal_1707> michaelni: can one add extra packet in .interleave_packet ? <-- i think so but i did never try [21:37:38 CET] <JEEB> there were other patches supposed to follow but at this point I'm not sure I want to push as much [21:37:57 CET] <JEEB> since you just feel like you've got a goddamn wall in front of you that is mocking you while you're trying to respond to it [21:40:42 CET] <jamrial> that's a perfect description of how dealing with carl feels like [21:41:42 CET] <jamrial> single line replies. questions as answer to questions. being purposely terse. etc [21:42:53 CET] <JEEB> and while I'm happy that he didn't block the patch, it still feels like bullshit that I had to go that far to get the what-feels-like-reversal. it's tiring, it's a last resort for me [21:44:29 CET] <JEEB> btw, do we have a box where we can run FATE with patches? [21:44:45 CET] <JEEB> because I don't have a local copy of FATE and/or I might not have the CPU time around to run the full suite [21:45:00 CET] <JEEB> but I would still like to make sure that FATE still passes with my things [21:46:20 CET] <michaelni> it should be easy to setup a box or boxes which test some public branch like "forfatetesting" or something like this [21:46:50 CET] <michaelni> i could add a branch like this to my boxes if people want and if that branch was in the main git [21:48:33 CET] <michaelni> about "<JEEB> michaelni: what's the process if cehoyos blocks my patch officially?", i think i might not know exactly what patch this referes to but talking with the developers involved in a disagreement is certainly the first step [21:49:15 CET] <durandal_1707> michaelni: i could add smthing flag but that requries that write_packets is called only once [21:50:36 CET] <jamrial> JEEB: do you have the patch in github or similar? i'll run it through fate [21:51:44 CET] <durandal_1707> just apply it, it breaks nothing [21:53:42 CET] <JEEB> jamrial: https://github.com/jeeb/ffmpeg/commits/dolby_vision_in_isobmff and https://patchwork.ffmpeg.org/patch/11430/ [21:53:52 CET] <JEEB> these are the two patch sets I'd like to be passed through FATE [22:06:50 CET] <michaelni> jeeb/dolby_vision_in_isobmff passes fate [22:06:57 CET] <JEEB> thank you [22:15:51 CET] <jamrial> JEEB: the mpegts patch also passes fate [22:15:57 CET] <JEEB> nice [22:16:00 CET] <JEEB> thank you very much [22:21:37 CET] <durandal_1707> seriously if you do not apply that patch I will in next 15 minutes [22:21:59 CET] <JEEB> I'm still hoping that someone steps in says that it's OK [22:22:06 CET] <JEEB> then I can push my github branch [22:22:22 CET] <JEEB> please do not push the version on ML since it has mismatching comments [22:22:32 CET] <JEEB> I got the AVC tags the wrong way [22:22:45 CET] <durandal_1707> ah, pain! [22:24:03 CET] <JEEB> just, please [22:24:16 CET] <JEEB> thank you [22:26:02 CET] Action: JEEB quickly rebases [22:28:02 CET] <cone-008> ffmpeg 03Rodger Combs 07master:6ebe88f3a4c4: lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264 [22:28:03 CET] <cone-008> ffmpeg 03Jan Ekström 07master:a1f0dd24f625: lavf/mov: document the dvh1 codec switch based on hvcC availability [22:34:27 CET] <JEEB> ok, what on earth is going on [22:40:47 CET] <durandal_1707> lol [22:43:17 CET] <BtbN> But why did he close it? The actual issue is not fixed. [22:44:11 CET] <JEEB> since when do we have to mention everyone who came up with the same thing independently? [22:44:25 CET] <JEEB> he clearly mentioned that he agreed that I had never seen Igor's patch before [22:46:10 CET] <durandal_1707> funny times [22:46:36 CET] <JEEB> and I was not an asshole to this person [22:47:03 CET] <JEEB> I was aggravated - maybe - by the style of replies, but I still tried to work with him [22:47:13 CET] <JEEB> he chose not to block my patch when I requested him to note so [22:48:26 CET] <BtbN> I don't think there was any ill intend here from Carl. Just way too much discussion for a trivial patch. [22:50:35 CET] <gnafu> I am thinking of trying my hand at adding the -aq-mode option for libaom-av1 (like libvpx-vp9), but I also have zero experience. So if someone else wanted to add that and not credit me, I would be quite happy ;-D. [22:50:57 CET] <gnafu> I am not likely to actually follow through, though I may give it a whirl tomorrow if I have time. [22:52:21 CET] <JEEB> BtbN: I really don't know. I think from my replies you can clearly see that I wanted to work with him. [22:52:38 CET] <JEEB> he just never seemed to actually say waht he wanted [22:52:44 CET] <BtbN> Since he also closed the ticket, maybe he misunderstood what the patch does? [22:52:46 CET] <JEEB> did he want to block me? did he want something else? [22:53:15 CET] <JEEB> I really don't know [22:54:05 CET] <JEEB> also he just weirdly accused me of ignoring reviews, spreading obvious nonsense and doing copyright violations [22:54:14 CET] <JEEB> I don't even goddamn know what's going on at this point [22:54:30 CET] <JEEB> and this is after trying to work with the person for days [22:54:37 CET] <JEEB> and I still would [22:55:11 CET] <jamrial> JEEB: you already dealt with enough bullshit, don't subject yourself to more stress for no gain [22:55:38 CET] <jamrial> patch was oked and commited, water under the bridge [22:56:08 CET] <JEEB> I just don't fucking understand [22:56:19 CET] <durandal_1707> it was oked by michaelni days ago [22:56:21 CET] <jamrial> no one does [22:57:19 CET] <JEEB> durandal_1707: and funny enough if I had pushed it then it would have probably gone through just fine. I don't fucking understand what the fuck is even going on [22:57:26 CET] <JEEB> I just want to go cry in a corner or something [22:57:48 CET] <JEEB> because as far as I can tell I've tried to co-operate as much as possible [22:58:00 CET] <JEEB> gave the person a chance to specifically block it if the person wanted to do that [22:58:07 CET] <durandal_1707> you co-operate too much [22:58:08 CET] <JEEB> so that it could clearly be marked as such [22:59:16 CET] <JEEB> and what I get out of it is getting called a copyright infringer and spreading obvious nonsense [22:59:53 CET] <durandal_1707> relax, forget about all of this [23:01:49 CET] <BtbN> Carl seems to have it with copyright lately. [23:02:42 CET] <JEEB> I don't even know why he said that if he agreed I had never seen Igor's patch [23:02:46 CET] <JEEB> like seriously [23:02:52 CET] <JEEB> I DON'T GET IT [23:03:27 CET] <wbs> JEEB: calm down [23:03:47 CET] <JEEB> and we're on the same mailing list and I want to co-operate with this person just like when I linked him the MPEG-2 Systems spec when he added the HEVC identifier [23:03:54 CET] <JEEB> I have nothing against him [23:04:59 CET] <JEEB> wbs: I am pretty calm but it's just all WTF right now [23:05:57 CET] <wbs> I don't see anywhere that he claims you did copyright infringment. he wanted you to mention the other patch which he vaguely referred to on and off during the discussion (I think?) and vaguely asked you to mention [23:07:07 CET] <JEEB> wait was that a private e-mail [23:07:25 CET] <JEEB> yes [23:07:28 CET] <JEEB> yes it was [23:07:29 CET] <JEEB> WTF [23:07:39 CET] <wbs> ok well that changes matters [23:08:59 CET] <BtbN> Must be quite some copyright there on adding two tags according to the spec [23:09:13 CET] <JEEB> http://up-cat.net/p/7a77bdf8 [23:10:12 CET] <BtbN> wtf [23:10:27 CET] <JEEB> exactly [23:10:38 CET] <JEEB> and I have no idea why he chose to post that off-list [23:10:57 CET] <wbs> because he knows that's not how one is supposed to talk to others in public [23:11:20 CET] <BBB> s/in public// [23:11:41 CET] <wbs> BBB: true [23:11:45 CET] <BBB> sorry that's unacceptable, regardless of whether it was sent in private or not [23:11:55 CET] <BBB> it was clearly sent as part of an ongoing project discussion [23:12:04 CET] <BBB> it was meant to influence project policy and project direction [23:12:09 CET] <BBB> it was meant to discourage and discredit [23:12:17 CET] <BBB> there's nothing private about that message [23:12:40 CET] <BBB> JEEB: sorry dude :( [23:13:32 CET] <JEEB> I don't even know [23:14:08 CET] <JEEB> I even replied to his additional comments [23:14:14 CET] <JEEB> which he had not brought up before [23:14:38 CET] <JEEB> nor when I noted that if he wanted to block the patch he should just say so [23:14:58 CET] <JEEB> the only copyright violation I could have done is taking the descriptions from MPEG-4 RA page [23:15:26 CET] <JEEB> because... they are the official descriptions of those codec identifiers [23:15:30 CET] <BBB> is that email actually from carl eugen? i.e. are the headers generally consistent with other emails from him? [23:16:30 CET] <JEEB> let me check [23:17:18 CET] <JEEB> at least SPF, DKIM and DMARC were marked passed by gmail [23:19:42 CET] <JEEB> and the e-mail itself matches with what he uses on the ML [23:21:55 CET] <JEEB> BBB: also the headers hint at it being sent from SMTP for that address [23:22:15 CET] <BBB> ok [23:22:18 CET] <BBB> :( [23:26:24 CET] <philipl> JEEB: Did he intend to send that to someone else on a completely different topic? He knows who you are. [23:26:33 CET] <philipl> It's so out of left field I can't quite believe it. [23:27:22 CET] <JEEB> philipl: welcome to me some time ago [23:27:29 CET] <JEEB> I didn't even notice it was sent to me privately [23:27:47 CET] <JEEB> until wbs mentioned that he didn't accuse me of anything seemingly [23:30:08 CET] <philipl> I guess he's still sour about MPEG-RA allowing Dolby to register a code that was used ad-hoc in a file once in 2001. [23:41:20 CET] <JEEB> also conveniently he at that point also cut the e-mail thread it seems https://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/237780.html [23:52:35 CET] <BradleyS> there's a word for this: shaming [23:53:12 CET] <BradleyS> don't feel ashamed for things you didn't do, don't feel ashamed for other people being difficult [23:53:42 CET] <BradleyS> a good faith effort is obvious here [23:55:42 CET] <JEEB> I would clearly hope so since in my opinion I did try to work with the person and when I started getting way too tired I would tell the person to actually specifically note that he'd be blocking me [23:56:54 CET] <BradleyS> carl can be a bit paranoid at times, i think he's just misjudging the situation and not being malicious [23:57:18 CET] <BradleyS> still frustrating [23:57:43 CET] <nevcairiel> then he has the worst judgement of any person ever, its not like this is the first, or even the 10th time =p [23:58:52 CET] <BradleyS> some of it could be language barrier as well [23:59:11 CET] <BradleyS> but it is not cool to respond that way to a contributor in public or private in any case [23:59:31 CET] <BradleyS> (this is why projects adopt codes of conduct) [23:59:32 CET] Action: BradleyS runs [00:00:00 CET] --- Tue Dec 18 2018

1 0

ffmpeg.log.20181217
by burek 18 Dec '18

18 Dec '18

[00:31:22 CET] <merethan> Lets try ffvhuff in the nut container [00:31:34 CET] <merethan> brb, mem constraints [00:56:00 CET] <ServiceRobot> hey guys, so I'm working on a personal project with ffmpeg but I keep running into an invalid data error [00:56:07 CET] <ServiceRobot> any idea what could be causing it? [00:57:06 CET] <JEEB> have you checked your code against f.ex. the transcoding example under doc/examples? [00:57:26 CET] <ServiceRobot> it's a library written in java. can't exactly do that [00:57:36 CET] <ServiceRobot> but the error code I'm getting is an ffmpeg error [00:57:43 CET] <ServiceRobot> INDA, aka invalid data [00:58:10 CET] <JEEB> why can you not? like, the core is the same so if you're getting FFmpeg errors underneath then you can match that against what's being done over JNI [00:58:31 CET] <JEEB> it's your java wrapper and if not - go ask someone who made that thing if you cannot figure it out [00:58:38 CET] <JEEB> sorry for being blunt [00:59:14 CET] <JEEB> and even if you're using someone's java wrapper, unless it's closed source you should be able to peek WTF it's doing with the APIs [00:59:27 CET] <JEEB> and compare against API examples [01:00:30 CET] <ServiceRobot> thing is I'm not exactly adept at C. the library is open source, but I was just hoping to get some more info on the error code [01:00:34 CET] <ServiceRobot> since it is an ffmpeg error code [01:01:09 CET] <JEEB> those don't pop out from a single place for eff's sake. and it usually means you're doing something wrong or that's your input's broken [01:01:39 CET] <JEEB> even if you're not adept at C, you should be able to grasp basics in the examples and compare WTF that JNI wrapper is doing [01:03:11 CET] <ServiceRobot> well, I'll take a look again then [01:04:58 CET] <JEEB> also make sure that a basic ffmpeg.c binary built with whatever copy of FFmpeg you have can actually open your input [01:06:34 CET] <ServiceRobot> it can open my input, just not remotely. I'm trying to send packets over the network and de-serialize them. idk what is needed to keep the packets consistent though [01:07:17 CET] <JEEB> I hope you're not trying to push through network AVFormat specific data structures :P [01:08:04 CET] <JEEB> you're supposed to push your AVPackets through an AVFormatContext set up with a usable container and a protocol or your own AVIO wrapper to send out the written data [01:08:19 CET] <JEEB> like mpeg-ts or NUT over some protocol :P [01:08:36 CET] <JEEB> NUT is often used for raw video/audio, while MPEG-TS is often used for broadcast uses [01:09:00 CET] <ServiceRobot> hmm, I was using a peer-to-peer library to just send packets over UDP [01:09:31 CET] <ServiceRobot> what is needed in an avformatcontext? I have video height, width, and pixel format [01:09:55 CET] <JEEB> valid input data is what's needed [01:10:16 CET] <ServiceRobot> what is needed for valid input data? the bare minimum? [01:10:48 CET] <JEEB> for sending side you either demux the input into AVPackets, or you generate them yourself, and open an *output* AVFormatContext with either NUT or MPEG-TS or whatever, with UDP protocol for example [01:11:14 CET] <JEEB> then on the receiving side you open an *input* AVFormatContext with that same protocol and container, and start reading into it :P [01:11:36 CET] <ServiceRobot> well I demuxed the input into packets, then I sent those packets across the network by serializing them [01:11:45 CET] <JEEB> yes, nope - don't do that [01:11:47 CET] <ServiceRobot> obviously there's missing data [01:11:49 CET] <ServiceRobot> oh [01:12:09 CET] <JEEB> AVPackets are not supposed to be network transparent [01:12:21 CET] <JEEB> they're internal FFmpeg data structures and have references to buffers etc [01:12:40 CET] <ServiceRobot> the library I'm using allows direct access to the buffer byte array [01:12:45 CET] <JEEB> that's OK [01:12:52 CET] Action: merethan out of memory, again [01:12:53 CET] <JEEB> but jesus christ jus topen an output lavf context [01:12:53 CET] <ServiceRobot> which is what I store in the serialized class [01:13:00 CET] <JEEB> that's not enough [01:13:10 CET] <JEEB> just open an output lavf context with the UDP protocol for example [01:13:16 CET] <JEEB> then if it's raw use NUT, if not try MPEG-TS [01:13:20 CET] <JEEB> and push that out :P [01:13:35 CET] <JEEB> then on receiving side just read input from UDP as if it's a file with libavformat [01:13:36 CET] <ServiceRobot> maybe pushing them raw would have been better, since I'd need to decode them on the other end [01:14:13 CET] <JEEB> anyways, you get crazy person points for even trying to serialize lavf internal structures :P [01:14:20 CET] <merethan> I invoke ffmpeg twice. First step i output to ffvhuff in nut. Stragely I now run out of memory. Before I did output to h264 both steps (with associated quality loss) but it did fit precisely in my ram. [01:14:23 CET] <JEEB> although it seems like you didn't even think it thoroughly enough [01:14:34 CET] <JEEB> where you would have seen the insanity of it [01:14:44 CET] <JEEB> just write your AVPackets into X in UDP for example [01:14:49 CET] <merethan> Does it make sense that processing lossless input takes more ram? [01:14:50 CET] <JEEB> and receive on another side [01:14:58 CET] <ServiceRobot> ya, I thought I was being clever, but seems I misunderstood the concept [01:15:24 CET] <merethan> Anyway, what lossless intra format takes the least ram? :P [01:15:27 CET] <JEEB> if you could 1:1 replicate all the lavf structures simply [01:15:30 CET] <JEEB> sure [01:15:43 CET] <JEEB> but since that's not true, just stop and properly push multimedia over network [01:15:52 CET] <ServiceRobot> what are all the lavf structures? [01:15:55 CET] <JEEB> that also lets you use random FFmpeg-based clients to test the stream :P [01:16:00 CET] <ServiceRobot> alright, I'll have to look at the examples again [01:18:21 CET] <ServiceRobot> what's even crazier is that I did get audio to work somewhat [01:19:51 CET] <JEEB> yea, I mean, given correct circuimstances and all of the correct parameters (including timestamps and init data etc) passing stuff would work [01:20:03 CET] <JEEB> after all there are FFmpeg wrappers that work over DirectShow etc [01:20:10 CET] <ServiceRobot> ya, I was passing timestamps, etc [01:20:30 CET] <JEEB> but you have to carefully regenerate values of AVPackets as well as the decoder initialization data etc [01:20:59 CET] <ServiceRobot> which I also tried to do. I sent the decoder over as well [01:21:10 CET] <ServiceRobot> I probably could have done this in a multitude of better ways [01:21:34 CET] <JEEB> but really, with network streaming it's just much simpler to do it in a way in which you can then receive and test the stream with something that isn't just your code [01:21:38 CET] <JEEB> also same for the sending side [01:21:58 CET] <JEEB> you can test both your receiver and your sender without your code on the other side if you just use a proper container over network :P [01:22:28 CET] <ServiceRobot> are you saying I could just do peer-to-peer streaming with ffmpeg alone? [01:23:25 CET] <JEEB> lavf has support for receiving and sending out UDP, including multicast - yes. and there are containers which send out headers in-band [01:23:40 CET] <ServiceRobot> O___O I'm an idiot then [01:23:53 CET] <ServiceRobot> I should have just used an ffmpeg wrapper then [01:25:31 CET] <merethan> Aight, another go (kill of all mem users again) [01:53:16 CET] <Hello71> maybe someone should tell merethan about swap [03:19:30 CET] <Keshl> In https://x265.readthedocs.io/en/default/cli.html#psycho-visual-options , I found a bit mentioning "--analysis-save" and related options. Given the description, I'd like to use these, but ffmpeg claims these options don't exist. Are they still present in recent builds? [03:22:26 CET] <furq> Keshl: -x265-params analysis-save=foo [03:24:32 CET] <Keshl> Thank you! For some reason, I thoguht x265-params was depricated. [03:25:55 CET] <Keshl> All happy, thank you. -- Holy nuggits, this file's big. o_o' [03:26:32 CET] <Keshl> That's a "me" problem though. I'm happy. [03:45:02 CET] <Keshl> Unrelated, just curious: Why can't I use yuv410 with x265? From my relitave naive perspective, I can't find any logical reason. [03:46:17 CET] <furq> nobody implemented it because nobody cares about it [03:47:44 CET] <Keshl> Am I right in assuming that it's more complicated than just diving by two? [09:02:36 CET] <th3_v0ice> Why would a decoder return a frame with wrong(?) PTS value if the input packet has the proper next PTS timestamp. For example: Input packet PTS: 2370413408, TB of stream 1/90000, TB of decoder 1/50, after rescaling 1316896, output frame PTS 6089068. Next packet PTS: 2370417008, same timebases, after rescaling 1316898, frame PTS 1316884. Why so big jump? Its very hard to debug this since this [09:02:36 CET] <th3_v0ice> program has been running 24+ hours and it seems to happen only on a long runs. Any advice is welcome. Thanks. [09:08:43 CET] <durandal_1707> th3_v0ice: which decoder? [09:20:34 CET] <th3_v0ice> h264 [09:22:47 CET] <JEEB> if it's live input I recommend having something dumping the input as well so with problematic cases you can double-check [09:23:04 CET] <JEEB> I think that's MPEG-TS? in which case DVBInspector is a good "alternative" to check the timestamps with [09:30:11 CET] <th3_v0ice> Its indeed an MPEG-TS live UDP source. [09:33:00 CET] <th3_v0ice> These are the timestamps that I am printing for every packet that comes in from input. Input packets timestamps seems fine to me, but the output from decoder is for some reason wrong. [09:34:40 CET] <JEEB> you can use something like multicat to dump the stream into a directory into f.ex. 2 min chunks [09:34:47 CET] <JEEB> and then you can have a running, say, 18 hour buffer [09:34:56 CET] <JEEB> so when you notice something weird you can double-check from the dump buffer [09:35:18 CET] <JEEB> https://code.videolan.org/videolan/multicat [09:35:36 CET] <JEEB> also packaged in various distributions, I think the version from 16.04 ubuntu upwards supports it [09:35:48 CET] <JEEB> the "dumping into directory" option [09:45:32 CET] <th3_v0ice> So If I understand correctly, You think its an input packet problem? I am just trying to understand what could be the possible culprit. Because I am logging input pts and timebases exactly for this reason and didnt expect the results that I saw. I will use multicat to dump the input. [09:47:27 CET] <JEEB> we don't know what the problem is, that is why you need a *reproduce'able* sample [09:47:46 CET] <JEEB> dumping the input and checking the dump when oyu notice something weird is the only way to deal with that [09:49:08 CET] <th3_v0ice> Ok, thanks, will start the dump now. [15:35:43 CET] <Skandalist> I don't get it how to get known, which file extension to use with certain encoder? When I don't put the file extension, the program says, that it doesn't know what to do. When I put wrong file extension I get the same error or unworkable file. I can get list of encoders and list of formats, but there is no info about that. [15:39:32 CET] <pink_mist> mkv can take most encodings afaik, so just use .mkv as extension [16:02:58 CET] <justinasvd> Morning, guys. [16:04:17 CET] <justinasvd> How do I properly capture frames from ffmpeg, say, every 100 seconds? The command ffmpeg -i video_file -f image2 -vf fps=fps=1/100 out%3d.png does not really work. [16:04:29 CET] <justinasvd> I.e., it outputs frames, but I don't understand what frames. [16:05:08 CET] <justinasvd> I verify simply: open the same video_file in mplayer and scroll to 1 minute and 20 seconds. It's a frame at 100 seconds. I except to see this frame from ffmpeg output. [16:05:20 CET] <justinasvd> What I see from ffmpeg is something different. What? [16:05:53 CET] <justinasvd> *expect [16:07:25 CET] <ed8> The following command return only audio with blank video: [16:07:27 CET] <ed8> ffmpeg -i ./data/partie-1:-Apprendre-300-mots-du-quotidien-en-LSF.jauvert-laura.hd.mp4 -b:v 1024k -c:v libvpx-vp9 -crf 32 -filter:v scale=1280x720 -loglevel error -maxrate 1485k -minrate 512k -pass 1 -quality good -speed 4 -threads 8 -tile-columns 2 -y ./data/partie-1:-Apprendre-300-mots-du-quotidien-en-LSF.jauvert-laura.hd.webm [16:13:44 CET] <relaxed> ed8: pastebin.com ffmpeg's output [16:18:38 CET] <ed8> relaxed: there is no stdout/stderr message [16:26:06 CET] <saml> hey how can I create a shorter summary video? given a long video, I want to capture important scenes and stitch them together to a few second long video [16:27:17 CET] <saml> I guess I can use some alpha go ai and get sections of videos. cut them and merge them [16:27:47 CET] <ed8> relaxed: does the order of the argument matter ? [16:28:17 CET] <relaxed> ed8: it maybe the file name, try quoting the input/output filename [16:30:09 CET] <ed8> relaxed: the output file exist and weight ~11Mb but I see audio [16:33:56 CET] <justinasvd> ed8: That's because you set log level error. Set it as debug. [17:01:23 CET] <justinasvd> Found the problem in my case. FFMPEG add t = 1/2*1/fps to the frame time, so all the captured frames are shifted by that exact amount. [17:01:31 CET] <justinasvd> adds [17:09:34 CET] <ed8> Converting from mp4/h264 to webm/vp9 I got audio but no video. [17:12:01 CET] <ed8> Here is a gist with the ffmpeg command executed, and the `mplayer -identitfy` for input/ouput files [17:23:26 CET] <Razwelles> tseting [17:23:52 CET] <Razwelles> Hey, does anyone know how to manually calculate pts for variable framerate libx264 frame by frame? [17:24:23 CET] <kepstin> Razwelles: need more context, what exactly are you trying to accomplish? [17:25:15 CET] <Razwelles> kepstin: I'm encoding a live stream from a realsense camera, its timestamps are measured in milliseconds [17:25:21 CET] <Razwelles> I'm able to encode the frames but I can't get the timing right [17:25:27 CET] <BtbN> You can't calculate it. It's either already there from what produced the VFR content, or that information is lost. [17:26:09 CET] <Razwelles> I thought the pts was a calculation basedd on timebase and framenumber? [17:26:17 CET] <kepstin> Razwelles: set the timebase to 1/1000, put the received timestamps in the timestamp field, done? [17:26:35 CET] <Razwelles> kepstin: I tried that, it gives me an error about dts, sec [17:26:37 CET] <kepstin> Razwelles: frame number is irrelevant [17:26:59 CET] <Razwelles> I did just try putting the timestamp in the pts with that timebase though [17:27:17 CET] <Razwelles> non-strictly-monotonic PTS [17:27:17 CET] <Razwelles> (repeated 7 more times) [17:27:17 CET] <Razwelles> Application provided invalid, non monotonically increasing dts to muxer in stream [17:27:49 CET] <Razwelles> I think I do check for repeated timecodes but there may be redundant frames [17:28:23 CET] <kepstin> well, you have to ensure that the pts values your sending to the encoder are monotonically increasing (no backwards steps, no repeated numbers) [17:28:41 CET] <kepstin> and then the encoder should be generating correct dts [17:29:52 CET] <Razwelles> I just ran acrosss some docs, it seems there's a timebase for both the codec and the stream, I'd been setting codec so maybe I was in the wrong are altogether. I'll try to do the check you mentioned thank you [17:30:15 CET] <Razwelles> *setting stream [17:30:18 CET] <kepstin> ah, yeah, if the codec and muxer timebase are different, then you have to handle converting between them [17:30:36 CET] <kepstin> note that some muxers will reject the timebase you set and instead use one they pick [17:30:50 CET] <Razwelles> Yes that might be the problem! Fingers crossed, thank you :) [17:40:10 CET] <justinasvd> Guys, how do I take snapshots every 100 seconds WITHOUT the initial 50 seconds shift? [17:40:28 CET] <justinasvd> ffmpeg -ss 0 -i my_video -vf "fps=1/100" -qscale:v 5 "img%03d.jpg" does not help. :-( [17:42:22 CET] <kepstin> justinasvd: the fps filter has a setting for rounding mode, you can try changing that to a different value [17:42:52 CET] <kepstin> justinasvd: alternately, you can use the select filter with an expression that matches only the frames you want [17:46:10 CET] <justinasvd> I will look into that rounding mode knob first. [17:58:19 CET] <alkmx> Hi everyone, I have been searching but I can not find a solution. Is there a way to send a header with a rtsp protocol, I know exist -header option but this only works for http protocol [18:01:50 CET] <justinasvd> kepstin: I can't thank you enough. round=down was exactly what I wanted. [19:27:44 CET] <saml> ffmpeg -f concat -i concat.txt output.mkv concat.txt has file, inpoint, outpoint. but output.mkv is not precise [19:28:19 CET] <saml> https://gist.github.com/saml/897cd893f49006cd80493d62a26a0e7d this is example concat.txt [19:28:53 CET] <saml> [matroska @ 0x55825cac0100] Non-monotonous DTS in output stream 0:1; previous: 5241, current: 3860; changing to 5241. This may result in incorrect timestamps in the output file. [19:28:57 CET] <saml> lots of output like this [19:33:46 CET] <saml> one constraint i have is that i'm removing portions from one file (file parameter of concat.txt will be always a single file) [19:37:45 CET] <kepstin> saml: concat demuxer is restricted in that it can only seek to keyframes [19:38:20 CET] <kepstin> saml: given how short your segments are, they probably are overlapping given that it has to go to the keyframe before the segment start [19:38:55 CET] <kepstin> saml: to get frame accurate seeking & concat like that, you're gonna have to use the concat filter. [19:39:11 CET] <saml> hrm i generated those segment inpoint and outpoint using silencedetect filter. [19:39:24 CET] <saml> how do I adjust my timestamps so that they fall in keyframes? [19:39:36 CET] <saml> I don't need frame accurate cuts. [19:40:07 CET] <saml> I guess I need to list timestmaps of all keyframes and combine it with silencedetect filter and find the closest keyframe timestamp [19:40:58 CET] <kepstin> saml: the easiest way to get a list of keyframe timestamps is probably with ffprobe -show_frames (there should be some additional selection options you can use to make it only show keyframes, or only specific streams) [19:46:00 CET] <kepstin> (actually, you might want the -show_packets option, and check for K in the flags field, since 'I' frames as reported in -show_frames might not necessarily be valid seek points) [19:46:10 CET] <saml> ffprobe -loglevel error -skip_frame nokey -select_streams v:0 -show_entries frame=pkt_pts_time -of csv=print_section=0 input.mp4 [19:46:27 CET] <saml> hrm i see. let me try both [19:46:33 CET] <saml> thanks. merry christmas [19:48:41 CET] <kepstin> ah, the 'key_frame' field in the frame (and the -skip_frame nokey option) should be equivalent to the K flag in the packet, I think [19:48:46 CET] <kepstin> should be good with that [20:13:26 CET] <bch> hello: i have a DVD (resolution: 720x480, aspect ratio: 1.78) which i'd like to convert to mp4. i end up with resolution: 720x480, aspect ratio: 1.50. the data is printed with mpv ("i" key). is there a way to convert a video in such a way that resolution & aspect ratio remain the same? [20:17:18 CET] <bch> i.e. keep the resolution and aspect ratio the same as the input file. dividing 720/480 is actually 1.5, so it seems that the original DVD is wrongly labeled? not sure... [20:21:00 CET] <kepstin> how exactly are you inputting the dvd to ffmpeg? Some of the methods (e.g. using a vob file as input) don't keep the correct aspect ratio [20:22:33 CET] <bch> i tried different versions, for example: cat *.VOB | ffmpeg -vf scale=720:480 -i - ~/lecture01_t.mp4 [20:22:39 CET] <kepstin> that must be ntsc widescreen, so to reset it to the correct value do "-vf setsar=40/33" [20:22:43 CET] <bch> the pipe might be the problem? [20:22:55 CET] <kepstin> no, the issue is that vob files don't store any aspect ratio info at all [20:23:13 CET] <relaxed> filter goes after input [20:23:25 CET] <bch> ok, thanks. will try with -vf [20:23:29 CET] <kepstin> well, the input is already 720x480, so the scale filter would do nothing anyways [20:23:39 CET] <kepstin> but yes - as relaxed said :) [20:24:25 CET] <bch> ohps yes, thanks. i stumbled upon this a few times. :) [20:24:52 CET] <kepstin> (note that 720x480 is actually *slightly* wider than 16/9) [20:25:08 CET] <kepstin> er, 720x480 ntsc widescreen specifically [20:26:10 CET] <kepstin> if you want exactly 16:9 output, then do "-vf setsar=40/33,crop=704:480:8:0" [20:28:05 CET] <bch> mhm ok, will try both. but it takes some time. 2hour DVD. [20:31:28 CET] <kepstin> you could add a "-t 60" option or something to encode just a minute of video to check the aspect ratio [20:32:43 CET] <bch> ah thats nice. [21:51:01 CET] <fullstop> hi all. I have a raw hevc stream and I'd like to put it inside of a container, such as mp4 or mkv, but I'm having some difficulty doing so. [21:51:24 CET] <durandal_1707> pastebin full uncut console output [21:51:59 CET] <fullstop> I don't want to reencode, just package the hevc stream and set the framerate. [21:52:28 CET] <durandal_1707> what you tried? [21:54:15 CET] <JEEB> IIRC we have issues with taht [21:54:22 CET] <JEEB> esp. with b-frames [21:54:39 CET] <durandal_1707> with hevc? [21:54:45 CET] <JEEB> with both H.264 and HEVC, IIRC_ [21:54:52 CET] <JEEB> unless that got fixed somewhere [21:54:55 CET] <fullstop> https://pastebin.com/raw/99WtjFLu [21:55:17 CET] <JEEB> umm [21:55:22 CET] <JEEB> that just seems to lack any parameter sets? [21:55:24 CET] <fullstop> this is from an ip camera which knows nothing about b-frames [21:55:47 CET] <JEEB> basically parameter sets are what's required for initializing the decoder [21:55:48 CET] <fullstop> right, the sps is likely missing or is not at the beginning of the file. [21:56:15 CET] <durandal_1707> fullstop: cant help unless short sample is uploaded [21:56:16 CET] <JEEB> if it comes somewhere along the road then you will take note of those messages regarding analyzeduration and probesize [21:56:29 CET] <fullstop> ffplay can play the file, but does spit out some error messages regarding PPS id out of range, etc [21:56:33 CET] <JEEB> see https://www.ffmpeg.org/ffmpeg-all.html for what those options can take in [21:56:48 CET] <JEEB> basically make the input parser probe the input file more [21:57:08 CET] <JEEB> generally those things expect parameter sets right away or very close by [21:57:28 CET] <JEEB> and to mux into mp4 you need things from the parameter sets [21:57:39 CET] <durandal_1707> it may be in special container, thats why i ask for sample [21:57:39 CET] <JEEB> like resolution and generally the sets themselves [21:58:12 CET] <JEEB> since the person knows about SPS I would guess he would see if it's some weird custom format? [21:58:21 CET] <JEEB> at least that's my initial guess :P [21:58:38 CET] <JEEB> if the person had no idea what I meant with parameter sets then I would maybe expect otherwise [21:59:38 CET] <durandal_1707> or pastebin hexdump of start of sample [21:59:48 CET] <fullstop> I'm fairly certain that it is a raw hevc stream. It's a rtsp stream straight from a cheap ip camera.. but it likely does not start on an i-frame and the sps stuff might be further in than the parser looks. [22:00:19 CET] <JEEB> ok, then just look for those two options in the docs I linked [22:00:27 CET] <JEEB> it should get parsed at some point [22:04:08 CET] <fullstop> okay, -analyzeduration did the trick [22:04:44 CET] <fullstop> it looks like the framerate set in the stream is incorrect; it is playing at 25 but the real rate is 15. [22:05:24 CET] <durandal_1707> raw h265 does store rate? [22:05:31 CET] <kepstin> i know h264 didn't [22:06:04 CET] <JEEB> there's a possible field for maximum time base [22:06:15 CET] <JEEB> which many things interpret as frames per second [22:06:31 CET] <JEEB> I am not sure if it is parsed [22:06:45 CET] <JEEB> but it of course requires that thing to exist in the stream [22:06:50 CET] <kepstin> fullstop: you said this was rtsp? It might make sense to send the rtp packets to ffmpeg rather than the hevc data only. Since the rtp packets have the timestamps [22:23:49 CET] <fullstop> kepstin: this stuff is captured by an embedded device and written to flash.. this device is not capable of running ffmpeg, unfortunately. [22:26:14 CET] <kepstin> well, if the device that's capturing the stream can't save to a proper container with timestamps, the best you can do is set the '-framerate' input option to the framerate you expect the stream to have when reading the hevc data with ffmpeg. [22:26:57 CET] <kepstin> and if the camera isn't constant framerate or some frames got dropped, well... :/ [22:33:36 CET] <fullstop> the container on the device does happen to have timestamps, so we're good there. [22:34:17 CET] <kepstin> so, why are you feeding ffmpeg raw hevc then, rather than the video in a container? [22:36:24 CET] <fullstop> It's a home-grown container. :-) [22:36:55 CET] <fullstop> I really just needed to get the data into a format playable on a PC. [22:40:37 CET] <kepstin> in the case of a home-grown container, you might be better served by writing a program (based on one of the encoding examples) that takes packets + timestamps from your container and feeding them to the ffmpeg decoder. [22:41:51 CET] <durandal_1707> fullstop: look if it is DHAV / DAHUA ? [22:43:02 CET] <fullstop> https://www.dropbox.com/s/wcivrzpicx868i8/soccer.mp4?dl=0 <-- here's a sample of the video [22:43:39 CET] <durandal_1707> is that output file? [22:43:54 CET] <fullstop> no, it's not DHAV/DAHUA... it's a container format that I came up with to minimize flash writes and mux a bunch of cameras into a single file. [22:44:00 CET] <fullstop> durandal_1707: yes [22:46:09 CET] <fullstop> anyway, it's all working now. Thanks for the help! [00:00:00 CET] --- Tue Dec 18 2018

1 0

ffmpeg-devel.log.20181216
by burek 17 Dec '18

17 Dec '18

[03:53:57 CET] <cone-142> ffmpeg 03Peter Ross 07master:436bffaca231: avutil/tests/random_seed: seeds[] is uint32_t, therefore use PRIX32 macro [10:19:01 CET] <cone-712> ffmpeg 03chcunningham 07master:c9f7b6f7a9fd: lavf/mov: ensure only one tkhd per trak [10:19:01 CET] <cone-712> ffmpeg 03Michael Niedermayer 07master:3a95b73abc86: avformat/nutenc: Document trailer index assert better [10:19:01 CET] <cone-712> ffmpeg 03Michael Niedermayer 07master:b11b3d2585cd: avcodec/vp7: Check for end of input in vp78_decode_mv_mb_modes() [10:19:01 CET] <cone-712> ffmpeg 03Michael Niedermayer 07master:092cb17983b2: avcodec/rasc: Check that the number of moves is less than or equal the number of pixels [20:10:52 CET] <atomnuker> huh, netflix have a spec page for that with a big red sign on the bottom saying its a draft [20:32:54 CET] <gnafu> atomnuker: I've been seeing more chatter about AVIF the last couple days, so I wonder if the spec is going to be updated as "final" soon. [20:33:57 CET] <gnafu> Netflix released some sample, and someone else released a Wasm-based decoder. [20:34:01 CET] <gnafu> s/sample/samples/ [20:34:32 CET] <gnafu> Or I guess the one who released the decoder works for Netflix. [20:34:41 CET] <gnafu> So Netflix seems to be moving on it lately. [21:45:52 CET] <thardin> only a single, proprietary format supported? oof [21:48:09 CET] <j-b> gnafu: yes, it will be soon. [22:03:42 CET] <gnafu> j-b: :-) [22:08:07 CET] <cone-040> ffmpeg 03Paul B Mahol 07master:de5e71fb1b2c: avcodec/tiff: add support for 12bit grayscale images [00:00:00 CET] --- Mon Dec 17 2018

1 0

ffmpeg.log.20181216
by burek 17 Dec '18

17 Dec '18

[00:00:21 CET] <Nosomy> Well apparently (for me) no has another lossy audio codec as good as Ogg Vorbis, it looks even lossless. [00:00:36 CET] <Mavrik> ? [00:02:10 CET] <kingsley> durandal_1707: Yes, I agree that nlmeans may be worth trying. [01:01:02 CET] <kingsley> I'm happy to report that kdenlive->Add effect->enhancement->"Denoiser" appears to reduce graininess. I applied it after improving brightness and contrast with kdenlive->Add effect->color correction->"3 point balance". [07:12:02 CET] <voltagex> what exactly does -absf aac_adtstoasc do? I've got one player that plays with bad audio without it, one player that won't play with it, and one player that plays perfectly with it [07:14:43 CET] <voltagex> ah, that explains why my MP4 works better with it. Hah. Hope it's a lossless operation. [10:20:53 CET] <kerio> ogg vorbis is kinda ass [10:21:07 CET] <kerio> especially compared to modern codecs like opus [10:22:38 CET] <cheapie> Well, yeah, Vorbis is kinda old :P [15:17:38 CET] <getrat> No matter what I try, following instructions exactly, I cannot get ffmpeg to react in any way to my attempts to making it turn a .ts and .audio.ts file into a single file (.mp4 or .mkv or whatever it prefers). All it does is "just sits there". Literally. Zero output. No "work has begun" text or anything. It just... sits there. [15:17:49 CET] <getrat> Example: "C:\Program Files\ffmpeg\ffmpeg.exe" -f concat -i file_list.txt -c copy out.mp4 [15:17:59 CET] <getrat> Opens a command prompt and then sits there. Forever. [15:18:20 CET] <getrat> At the same time, the ffmpeg binary is not broken because it can be used for other things, and then it does output stuff. [15:18:58 CET] <getrat> file_list.txt contains the two file names in quotes after the string "file " on each line. [15:19:07 CET] <getrat> Single quotes. [15:19:25 CET] <getrat> What is wrong? [15:37:42 CET] <Blacker47> getrat, if you want to put video and audio to one file, then concat is really wrong (it appends second file on the end of first). [16:24:06 CET] <getrat> Blacker47: Alright... So now I know what is wrong. What now? [16:24:10 CET] <getrat> What is the actual solution? [16:24:51 CET] <getrat> And even if it was wrong, it still makes no sense that it outputs nothing. [16:28:50 CET] <Blacker47> getrat, if files only contain one video and one audio stream (and they are sync...) then this should work i think: "ffmpeg -i video.ts -i audio.ts -vcodec copy -acodec copy -shortest out.mkv" [16:29:23 CET] <Blacker47> if some of files has more then one strem than you have to work with -map command. [16:31:10 CET] <getrat> Well, as I said, it's just one .ts and one .audio.ts file. [16:31:13 CET] <getrat> Trying your command now. [16:32:03 CET] <SpeakerToMeat> Hello all, again :) [16:32:19 CET] <SpeakerToMeat> is there any null codec? I want to convert from one format into nothing. [16:32:51 CET] <Blacker47> just for merging files to mkv (if it is ok that it would be mkv) you also can use mkvtoolnix. it is a nice gui where you also can select what streams from what file you want in the output file. [16:33:59 CET] <Blacker47> SpeakerToMeat, what should a 'null codec' be? [16:34:44 CET] <SpeakerToMeat> One that produces nothing. [16:35:08 CET] <furq> SpeakerToMeat: -f null [16:35:14 CET] <getrat> Blacker47: Thanks. It seems to have worked. But it makes no sense, because the resulting file was barely larger at all than the video file, in spite of now having the audio part in it. [16:35:30 CET] <Blacker47> then you wouldn't have any stream so just drop a stream. [16:35:34 CET] <furq> no [16:35:36 CET] <SpeakerToMeat> I'm veryfying discrete frames by runnign imagemagick's convert to null on each one, so each is loaded and if it loads, it's ok. I wanted to try and do the same in ffmpeg to see if it's more efficient (I know it is), and save the encode part of the process to save cpu time. [16:35:52 CET] <furq> getrat: mpegts has about 5-10% overhead over mkv [16:36:07 CET] <furq> so that probably swallowed up most of the size of the audio stream [16:36:12 CET] <SpeakerToMeat> furq: Ok I'll try that. I need to provide an output file anyhow? I can try with /dev/null [16:36:20 CET] <getrat> Video file = 1 988 320 kB. Audio file = 52 088 kB. Resulting (MKV) file = 1 988 416 kB. [16:36:20 CET] <furq> SpeakerToMeat: just -f null - [16:36:51 CET] <getrat> So somehow, MKV makes a 52 MB audio file into less than 100 kB? [16:37:06 CET] <furq> yes [16:37:13 CET] Action: getrat doesn't understand this. [16:37:16 CET] <Blacker47> getrat, audio are in generall much much smaller than the video... [16:37:16 CET] <SpeakerToMeat> furq: thanks [16:37:26 CET] <getrat> Blacker47: Did you see what I just typed? [16:37:31 CET] <furq> mpegts is about 5-10% bigger than mkv given the same streams [16:38:03 CET] <getrat> Isn't it odd that the resulting file starts with "1 988...", just like the input video file? [16:38:09 CET] <furq> does it work [16:38:37 CET] <furq> if it works then it's just a coincidence [16:39:39 CET] <getrat> furq: Are you talking to me? [16:39:43 CET] <furq> yes [16:41:07 CET] <getrat> I had a .ts video file of 1 988 320 kB, and an .audio.ts audio file of 52 088 kB. I ran Blacker47's magical command, and the resulting MKV file is: 1 988 416 kB. It works and plays with audio. The command was: "ffmpeg -i video.ts -i audio.ts -vcodec copy -acodec copy -shortest out.mkv" [16:41:13 CET] <Blacker47> getrat, see what furq said and you can use something line mediainfo to see the streamsitzes for video and audio (for the mkv). [16:41:31 CET] <getrat> 50 megs to 100 kB is not 5-10%... [16:42:07 CET] <getrat> MKV must be very efficient for the video as well. [16:42:19 CET] <getrat> And a bizarre coincidence that the numbers line up like that. [16:42:47 CET] <furq> it's not 5-10% of the size of the audio [16:42:58 CET] <furq> it'd be 5-10% of the combined size [16:43:09 CET] <furq> i guess it's only 2.5% in this case but you get the idea [16:44:01 CET] <Blacker47> getrat, in short: ts is not a raw format and had (as mkv too) overhead. this may be different. also mkv may be (some kind of zipped) additional compressed that may reduce slightly the size too. (not sure ffmpeg does that). [16:44:14 CET] <furq> mkv does not do any kind of compression [16:44:21 CET] <getrat> Tried with another identical set of files and it also becomes almost identical in size to the video file in spite of containing the audio... Again lining up with the first digits. Which freaks me out. [16:44:24 CET] <furq> mpegts is a streaming format so it sends additional headers inband [16:44:39 CET] <getrat> Hmm. [16:45:18 CET] <Blacker47> getrat, maybe mediainfo can show you for the .ts files the really size or percent of the overhead. [16:45:44 CET] <getrat> I get a creeping sensation on my back whenever something like this happens and I just don't understand why it's happening. I mean, I get the whole thing about different file formats having wildly different compression and efficiency, but the numbers seem too odd here. [16:45:46 CET] <furq> the overhead is more or less video.ts + audio.ts - combined.mkv [16:46:17 CET] <furq> also ffmpeg will show you the actual stream sizes when it's done muxing so you can just subtract those [16:46:54 CET] <furq> getrat: like i said, if the video works then there's nothing to worry about [16:46:57 CET] <furq> it's just a weird coincidence [16:47:13 CET] <getrat> Two weird coincidences. :/ [16:47:26 CET] <getrat> But yes... I should... be happy with this... [16:47:29 CET] <furq> well if all these files come from the same place then i'd expect them all to line up [16:47:48 CET] <furq> because it's a product of the mpegts overhead rate and audio bitrate being about the same [16:49:21 CET] <Blacker47> [16:44:14] <furq> mkv does not do any kind of compression <-- yes, i was a little wrong. mkv can have (zlib-) compressed subtitles but not additional compressed streams. [16:50:46 CET] <Blacker47> getrat, you can also try different output container like mp4, ts or whatever and see what sizes it produce. [16:50:55 CET] <getrat> I took a screenshot to perhaps better illustrate what puzzles me about the results: https://i.boring.host/KFHmR7f.png [16:51:41 CET] <pink_mist> getrat: it's just because .ts is a shitty container and needs so many more bytes to represent the same things as mkv does [16:51:55 CET] <pink_mist> there's nothing strange about it [16:51:59 CET] <pink_mist> it's just that .ts is shit [16:52:11 CET] <getrat> I tried with .mp4 just now and it ran much faster. The resulting file: 2 008 463 kB. [16:52:21 CET] <getrat> pink_mist: Hmm. [16:52:21 CET] <furq> it's not shit, it's designed for something else [16:52:42 CET] <pink_mist> ok, let me put it like this then: it's shit for all my needs [16:52:56 CET] <JEEB> I much prefer MPEG-TS to FLV as far as streaming goes [16:53:04 CET] <JEEB> for standalone seekable files, sure [16:53:09 CET] <JEEB> it's crap for that because it has no index [16:53:35 CET] <JEEB> blu-ray for some reason then decided to utilize it, and stuck extra 4 byte timestamp after each 188 byte packet I think? [16:54:39 CET] <getrat> In spite of this annoying mystery, thanks for helping me with the magical command. At least I can now watch this stuff. [16:54:56 CET] <pink_mist> getrat: compare an mkv of just the video stream to just the .ts video stream [16:55:26 CET] <getrat> By the way, nothing pisses me off more than when the audio is desynced or "drifts" while playing a video file. I can't even understand why those things happen, but it's been a frequent frustration both when trying to play back video files and while editing video for me for many years. [17:13:16 CET] <justinasvd> Morning, guys. [17:20:12 CET] <utack> does anyone know if "thebombzen" still resides here occasionally? [17:21:06 CET] <justinasvd> I came here with a problem, looked at the channel and I immediatelly understood how to solve the problem. [17:21:09 CET] <justinasvd> Thanks, guys. [17:24:05 CET] <SpeakerToMeat> furq: It kinda works well, only thing, I did a quick test and got an error on a purposefully damage dframe (for the test) but the error was pretty generic, is there any way to get an output that won't kill my console with logs, but will tell me the frame number the error ocurred at? so as to know what frame to verify? [17:26:30 CET] <SpeakerToMeat> Maybe -v verbose would help? [17:44:00 CET] <the_gamer> i have a .mp4 which i don't want the sound of but an .wav i want to replace as the audio. how to do this? [17:48:43 CET] <klaxa> ffmpeg -i input.mp4 -i input.wav -map 0:v -map 1:a -c copy output.mkv [17:49:28 CET] <the_gamer> thank you [18:25:05 CET] <ed8> I run a clipping command using -ss and -to option but the resulting file doesn't seem to respect the options [18:25:08 CET] <ed8> ffmpeg -y -ss 0:00:55.39 -i ./data/partie-1:-Apprendre-300-mots-du-quotidien-en-LSF.jauvert-laura.hd.webm -to 0:00:58.10 -c copy -loglevel error videos-hd/maintenant.webm [18:25:25 CET] <ed8> However: [18:25:29 CET] <ed8> mplayer -vo null -ao null -frames 0 -identify ./videos-hd/maintenant.webm 2>/dev/null [18:25:38 CET] <ed8> give ID_LENGTH=62.32 [18:26:31 CET] <ed8> i'm using ffmpeg version 4.0.3-1~18.04.york0 [18:30:15 CET] <klaxa> cutting with codec copy is only possible at keyframes [18:30:26 CET] <klaxa> if you want exact cuts you have to re-encode [18:32:40 CET] <ed8> well here, the more I advance in the source video the bigger are the files [19:06:02 CET] <SpeakerToMeat> Size should depend on video length, and partially, on its contents [19:09:07 CET] <ServiceRobot> good afternoon everyone [22:05:01 CET] <merethan> Hi all [22:13:20 CET] <merethan> I need some advice on transforming some video in a smarter way. [22:14:59 CET] <merethan> I currently do two things with ffmpeg. First step is converting a radial perspective into a equirectangular perspective (yes this is about 360 cam footage). I do this using a mapping like so: [22:14:59 CET] <merethan> ffmpeg -i 360footage.mp4 -i 360fly_3840x1920_x.pgm -i 360fly_3840x1920_y.pgm -lavfi remap 360footage_equirectangular.mp4 (Those mapings were generated using https://github.com/prouast/equirectangular-remap) Works beautifully well. [22:15:11 CET] <merethan> The second step involves some scaling and padding because my 360 cam has a blindspot, which requires some compensation. Essentially the frame needs to be scaled horizontally into the upper 2/3rd of the frame, and the lower 1/3rd of the frame needs to be blacked out. I do this like so: [22:15:11 CET] <merethan> ffmpeg -i 360footage_equirectangular.mp4 -vf "scale=w=0:h=1320,pad=w=3840:h=1920:y=0:x=-1" 360footage_equirectangular-blindspot.mp4 [22:15:11 CET] <merethan> And now the image works perfectly fine when viewing in 360. Thing is, it is reencoded twice because I invoke ffmpeg twice. Is there a smart way I can use the output of the remap as input for the scaling & padding, without having to run ffmpeg (and thus the encoding process) twice? [22:16:49 CET] <merethan> When I add the argumkents together ffmpeg refuses because it wants to run both transformations on the same input, rather than having them set up as a pipeline. [22:18:45 CET] <merethan> Oh oops I confused horizontally with vertically in my question :P [22:39:09 CET] <durandal_1707> merethan: remap does do interpolation for pixels [22:39:50 CET] <durandal_1707> *NOT do [22:42:33 CET] <merethan> I'm trying to understand why you mention this durandal_1707, but I don't get it. What do you mean exactly? [22:43:30 CET] <durandal_1707> merethan: worse quality if you zoom in pixels [22:45:05 CET] <merethan> Source material (360footage.mp4) is in 2880x2880 [22:45:59 CET] <durandal_1707> it is less noticeable for such high resolutions [22:46:26 CET] <merethan> To my understanding I cannot escape any zoom or scaling when converting radial to equirectangular. [22:46:45 CET] <merethan> Do you have any suggestions for improving the conversion quality? [22:47:48 CET] <durandal_1707> no, there is wip filter to do equirectangular to cubemap and back but not radial thing [22:48:08 CET] <merethan> Mm shite. [22:49:05 CET] <durandal_1707> with pixel interpolation you get better edges [22:49:07 CET] <durandal_1707> imho [22:49:22 CET] <durandal_1707> but that is also slower [22:49:55 CET] <merethan> I am relatively new to ffmpeg so I don't understand yet how all those operations fit together. [22:50:21 CET] <merethan> Do you see any way I can improve my pipeline qualitywise? [22:51:20 CET] <merethan> Also, I am very curious how 360fly themselves do it, as their desktop app is essentially a task-specific gui around ffmpeg. There's ffmpeg.dll in their install folder. [22:51:30 CET] <durandal_1707> no unfortunately, there is some software like hugin? but it works with images only [22:52:00 CET] <JEEB> merethan: generally people just decode with FFmpeg's libraries and then pass it onto their own filters, which can be software or HLSL/GLSL shaders [22:52:07 CET] <durandal_1707> merethan: hard to tell without RE, they can do it by own implementation [22:52:12 CET] <JEEB> I'd be surprised if they implemented the thing in libavfilter [22:52:25 CET] <merethan> Mm well skipping an encoding pass will already improve things, probably. So if that works I already made a good step. [22:52:45 CET] <durandal_1707> yea, they probably use GPU nice shaders, with free interpolation [22:54:03 CET] <durandal_1707> there is wip framework, vulkan filters which could speed up thing in libavfiler speed wise and quality wise [22:58:29 CET] <merethan> Now I look at it, the way you put the arguments together was super obvious durandal_1707 :P [22:58:49 CET] <merethan> Guess I gave up too quick [22:59:30 CET] <merethan> I have to leave for a moment, as I need to stop all programs to free ram. Else I don't have enough to do the encoding. [22:59:48 CET] <merethan> Xorg also has to go ;) [22:59:59 CET] <merethan> I'll be back later. [23:17:11 CET] Action: merethan ran out of mems [23:17:13 CET] <merethan> 3.3GiB does not cut it, apparently. [23:24:46 CET] <merethan> durandal_1707, it seems I cannot do the two steps in one go, as I run out of memory. Is there a smart way of reducing the quality loss in the first encoding step? [23:41:21 CET] <durandal_1707> merethan: use lossless encoder for mid step [23:42:36 CET] Action: merethan searches the docs [23:43:09 CET] <durandal_1707> ffvhuff in nut [23:43:25 CET] <merethan> ? [23:43:41 CET] <merethan> Did you nut?:P [23:45:45 CET] <durandal_1707> nut is ffmpeg container [00:00:00 CET] --- Mon Dec 17 2018

1 0