Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

February 2019

1 participants
56 discussions

ffmpeg-devel.log.20190212
by burek 13 Feb '19

13 Feb '19

[02:14:56 CET] <cone-621> ffmpeg 03Jun Zhao 07master:6382d0334775: avfilter/tests/integral: Check malloc fail before using it [02:14:56 CET] <cone-621> ffmpeg 03Jun Zhao 07master:9f33b0ed392f: avfilter/tests/integral: Fix build warning after adjust the location [09:52:32 CET] <feliwir> Does ffmpeg have any builtin vpx encoder at all? [09:52:49 CET] <feliwir> Which i could use to start from with vp6 [09:53:42 CET] <JEEB> I don't think, it started with VP8/9 and those are through libvpx [09:54:10 CET] <JEEB> there used to be a separate project called xvp8, but that never got too far (and since it based on x264 it was GPL) [10:13:54 CET] <feliwir> Hm, would it make sense to start on the more simple vpx codecs? E.g. vp3 etc. [10:14:12 CET] <feliwir> Eventhough there probably is probably no userbase for those anymore [10:15:55 CET] <durandal_1707> feliwir: why you need this? [10:21:30 CET] <JEEB> durandal_1707: he wants something old game engines can play? for localization etc [10:22:19 CET] <durandal_1707> ah, that would be non trivial :-) [10:22:27 CET] <feliwir> durandal_1707, to encode VP6 videos for old EA game engines :) (there are actually more people than me who want that) [10:23:15 CET] <feliwir> I contributed a bit to the vp6 decoder a couple years ago, but i guess encoding is a complete different story [10:24:23 CET] <feliwir> But i wonder why Google never release the vp6 encoder after acquiring On2 anyways [10:24:30 CET] <feliwir> *released [10:28:43 CET] <JEEB> > verifying if your A/V sync is still OK after PCR+timestamps fall backwards in a broadcast stream [10:28:46 CET] <JEEB> oh the fun [11:00:56 CET] <atomnuker> feliwir: licenses probably [11:02:03 CET] <feliwir> atomnuker, who is holding licenses except for Google? [11:04:05 CET] <JEEB> I would just guess lack of care of touching those old versions of their code [11:04:28 CET] <feliwir> well, they wouldn't need to touch it to publish it :) [11:04:54 CET] <JEEB> even finding it is to touch it [11:05:00 CET] <JEEB> and/or clean it up from any random crap in there [11:05:10 CET] <JEEB> basically, to get it through legal [11:05:31 CET] <feliwir> Hm, i don't know anyone at Google who could do that :( [11:06:17 CET] <feliwir> Aren't some people in here employed by Google for working at libvpx? [11:09:23 CET] <JEEB> yes, but you know - they work with *current* libvpx [11:09:44 CET] <JEEB> I think the most we got out of that stuff (and I'm not 100% sure if it's official or not) was the VP7 spec? [11:11:02 CET] <feliwir> Well, but i'd be suprised if Google just ditched the old On2 tools / source repositories. Not sure how the policy is there at Google, but i don't see why they wouldn't give it out [11:15:07 CET] <JEEB> I'm probably explaining it badly :P it was never anyone's job to even take a look at the old On2 stuff. and to release something that hasn't been OK'd for release is probably a PITA anyways [11:15:13 CET] <JEEB> welcome to enterprises [11:16:55 CET] <feliwir> Hm, sounds stupid :) However vp3 was opensourced by On2, but still i can't seem to find any opensource encoder. I just know that Theora derived from it [11:17:36 CET] <durandal_1707> ask google [11:18:04 CET] <feliwir> I did ask it already [11:18:07 CET] <j-b> Why would anyone want to produce vp6 or vp3 content? [11:19:11 CET] <feliwir> Well, i don't know about vp3, but we need vp6 for https://github.com/OpenSAGE/OpenSAGE [11:19:32 CET] <feliwir> Basically to create videos for old EA games, which used vp6 :) [11:20:22 CET] <thardin> vp6 used some horrible combination of mplayer talking to the codec via RPC [11:20:26 CET] <thardin> for encoding [11:20:51 CET] <thardin> or perhaps it was mencoder. either way, horrifying [11:21:55 CET] <thardin> as always, kostya is the guy to talk to about duck things [11:24:56 CET] <feliwir> who is kostya ? [11:25:21 CET] <durandal_1707> black magic wizard [11:25:37 CET] <feliwir> And where can i find that wizard? :D [11:26:26 CET] <durandal_1707> codecs.multimedia.cx [11:29:22 CET] <jdarnley> > opensage [11:29:41 CET] <jdarnley> If thats a remiplementation of an engine then why cant you include a better video decoder? [11:29:49 CET] <atomnuker> ^^ [11:31:37 CET] <thardin> yeah that's what I thought too [11:31:39 CET] <thardin> just link libvpx [11:32:31 CET] <JEEB> you just need to somehow figure out when you need to load stuff for the original assets, and when the asset's a VP8/9 file [11:32:54 CET] <JEEB> and yes, that would make things much simpler unless you want to make the new files load up in the actual original game [11:32:56 CET] <thardin> if only there were some kind of set of multimedia libraries that do just that [11:33:55 CET] <durandal_1707> comercial - bink [11:36:36 CET] <JEEB> I still need to figure out bink2 for my chinese cartoon openings of games [11:37:13 CET] <feliwir> @jdarnley, we use the original assets to avoid any copyright issues. We don't ship them we expect the user to have them [11:37:45 CET] <thardin> feliwir: but then you only need a decoder [11:38:16 CET] <feliwir> but then we'd not be compatible to the original game anymore ;) [11:38:55 CET] <thardin> sure if you want to go the chocolate doom kind of path [11:38:55 CET] <feliwir> We'll probably allow better codecs aswell, since we link ffmpeg anyways [11:39:31 CET] <thardin> but you probably want to encourage people to use your libre implementation anyway [11:39:55 CET] <feliwir> hm, it's doom indeed. But i thought since I am interested in multimedia anyways i might give it a shot [11:40:20 CET] <thardin> you could try to write an encoder as a summer project [11:40:38 CET] <feliwir> GSoC? Well, i'm not a student anymore [11:40:42 CET] <thardin> my cinepak encoder ended up being commited after all, after some improvements [11:41:01 CET] <feliwir> Can i also participate as a normal developer? [11:41:21 CET] <thardin> I hadn't thought of gsoc even [11:41:28 CET] <durandal_1707> be mentor [11:41:32 CET] <feliwir> Ah, why a summer project then? :D [11:41:38 CET] <thardin> because summer = free time [11:41:48 CET] <feliwir> meh, unfortunaly not true :( [11:42:13 CET] <feliwir> durandal_1707, i don't think i could mentor anyone in ffmpeg :D [13:06:31 CET] <JEEB> with US captions, was there any spot where they put language IDs? [13:06:40 CET] <JEEB> since I remember there's 4 or so (?) slots [13:39:16 CET] Action: JEEB double-blinks at mpegts_get_pcr [13:39:26 CET] <JEEB> git grep only mentions it once and it's marked with av_unused [13:39:35 CET] <JEEB> which silences the warning... [15:29:57 CET] <cone-760> ffmpeg 03Jun Zhao 07master:84e7aff60816: tests/api/api-h264-test: Add AV_NOPTS_VALUE check for AVFrame.pkt_dts/pts [15:31:09 CET] <JEEB> trying to verify discontinuity handling... not fun [15:31:19 CET] Action: JEEB stabs streams that go backwards in time [15:37:42 CET] <atomnuker> how dare they violate the second law of thermodynamics [19:33:51 CET] Action: JEEB runs a static analysis pass on his thingamajig just in case [20:04:03 CET] <cone-530> ffmpeg 03Jan Ekström 07master:4beccf400df3: lavc/libaribb24: add error handling to region handling [20:04:04 CET] <cone-530> ffmpeg 03Jan Ekström 07master:03824afdb4a5: lavc/libaribb24: protect handled value with parenthesis in RGB_TO_BGR [20:04:05 CET] <cone-530> ffmpeg 03Jan Ekström 07master:1ed9e8e9377d: lavc/libaribb24: add missing type struct members to AVOptions [20:04:06 CET] <cone-530> ffmpeg 03Jan Ekström 07master:466cb4ed56a1: lavc/libaribb24: use integer math to calculate font scaling [20:29:04 CET] <feliwir_> When adding the vp3 encoder i should probably split from vp3.c into vp3_dec.c and vp3_enc.c? [20:29:17 CET] <feliwir_> or what are the preferences there? [20:30:01 CET] <atomnuker> just make a vp3.h or vp3_utils.h and throw shared code in there [20:30:29 CET] <JEEB> feliwir_: yea generally if we have a decoder and encoder they're _{enc,dec} [20:31:12 CET] <JEEB> feliwir_: f.ex. http://git.videolan.org/?p=ffmpeg.git;a=commit;h=77f47e328800f5d7e7d1d3259a… [20:48:21 CET] <feliwir_> I just realized that libtheora has a vp3 compability mode [20:48:45 CET] <feliwir_> why was that never used to create vp3 encoder in ffmpeg (since we use libtheora anyways)? [20:50:11 CET] <feliwir_> I guess noone bothered :D [20:54:09 CET] <JEEB> most likely [21:10:16 CET] <jamrial> theora had its use in ogg videos some 15 years ago. vp3 didn't [21:10:38 CET] <jamrial> so probably that's why nobody bothered with an encoder for it [21:10:56 CET] <atomnuker> fun fact: vp8 usually compresses worse than theora [21:12:34 CET] <jamrial> vp8, or libvpx? [21:13:50 CET] <atomnuker> libvpx, but vp8 in general [21:14:08 CET] <feliwir_> hm, since the theora decoder was hacked into vp3.c a native theora encoder would maybe make sense aswell. But maybe someone else can do that [21:14:25 CET] <kurosu_> what other encoder for vp8 than libvpx ? And I expect vs a heavily tuned theora encoder (Thusnelda?) [21:14:52 CET] <kurosu_> (but then on2 could have better tuned their encoder, too) [21:15:05 CET] <atomnuker> vp8 only had 4x4 blocks and I don't think it had segmentation, while theora had 8x8 and could change quantization on a per-block basis [21:16:31 CET] <atomnuker> even if vp8 could change per-block quantizer its still 4x4 only so the overhead would be 4x more than 8x8 [21:16:56 CET] <kurosu_> I had to look, indeed 4x4 only [21:17:44 CET] <kurosu_> Time to release a codec with 4CC VP8F! [21:18:19 CET] <durandal_1707> xvc [21:19:31 CET] <kurosu_> is that an equation where we need to solve for x ? [21:19:43 CET] <durandal_1707> no [21:19:53 CET] <durandal_1707> codec name [21:44:35 CET] <feliwir_> Is there a documentation of types & functions that `should/can` be reused between codecs? [22:53:32 CET] <cone-530> ffmpeg 03Moritz Barsnick 07master:a84af760b809: configure: fix dependencies for mlp and truehd encoders [00:00:00 CET] --- Wed Feb 13 2019

1 0

ffmpeg.log.20190212
by burek 13 Feb '19

13 Feb '19

[00:02:16 CET] <MapMan> I'm at a complete loss. I spent all day trying to figure this out. With ffmpeg I can't get the framerate I need, with OBS, I can get 60fps easy, but either the bitrate sucks or the colors suck. Anyone managed to record lossless with obs? [00:03:16 CET] <JEEB> I did manage it once when I tested it. of course as far as I can tell the colorspace conversion stuff is rather opaque but it seemed to look close enough in mpv [00:04:16 CET] <MapMan> nvenc does not support RGB, does it? [00:05:11 CET] <JEEB> officially it only supports 4:4:4 YCbCr so yes, there's some opaque colorspace conversion unless you do hack around it like I mentioned some time ago in the chat (no idea if possible in OBS) [00:05:39 CET] <JEEB> but in the test I did the BT.601 (I think?) 4:4:4 YCbCr seemed close enough when played in mpv [00:07:39 CET] <MapMan> anything except RGB in obs produces jagged edges and blurred text for me [00:07:49 CET] <JEEB> sounds like 4:2:0 mode [00:08:07 CET] <JEEB> but yea, I remember you had to go poke around the options for the 4:4:4 lossless [00:08:14 CET] <JEEB> so I recommend you poke the OBS community for help [00:08:58 CET] <MapMan> https://i.imgur.com/UelVLHG.jpg [00:09:36 CET] <MapMan> check out how the text and some straight edges on the shark statue look like [00:09:44 CET] <MapMan> I can't get rid of that unless I'm recording RGB [00:10:05 CET] <MapMan> also buffer dimension is 3440:1442 which is... weird? [00:10:09 CET] <JEEB> try mpv [00:10:16 CET] <JEEB> https://mpv.srsfckn.biz/ [00:10:22 CET] <JEEB> just extract, drag and drop file on exe [00:10:40 CET] <JEEB> just to have an alternative [00:11:42 CET] <MapMan> same thing, I even uploaded to youtube once to make sure it's not playback [00:11:47 CET] <JEEB> ok [00:12:21 CET] <JEEB> if you do shift+I in mpv, what does it say the stuff is? [00:12:25 CET] <JEEB> just in case [00:13:22 CET] <kepstin> wouldn't youtube transcode to yuv420 anyways? since browsers don't generally support 444 in h264 [00:13:40 CET] <JEEB> yes [00:14:40 CET] <kepstin> (fun thing: firefox and chrome can both play back 4:4:4 sampled vp9, so if you want to put a pixel art gif into a webm file...) [00:14:47 CET] <MapMan> https://i.imgur.com/rcdUMk1.jpg [00:14:52 CET] <kepstin> lossless vp9 even :0 [00:15:51 CET] <JEEB> MapMan: is that resolution btw what you're actually capturing or is it somehow off? [00:15:55 CET] <JEEB> since you commented about the res [00:16:56 CET] <JEEB> but yea, that does look like the 4:4:4 output I got from nvenc by its details [00:17:32 CET] <kepstin> i wonder if the sar is just set slightly wrong (not quite 1:1) so vlc is scaling it [00:17:45 CET] <MapMan> JEEB: 3440x1440 native, vlc says buffer dimensions are 3440x1442. [00:18:08 CET] <JEEB> ok, the latter is just an internal detail in VLC [00:19:17 CET] <MapMan> https://i.imgur.com/c5d3nFS.jpg [00:19:19 CET] <MapMan> uhhhhhh [00:23:18 CET] <JEEB> yes if you just force rgb it's not gonna look right unless you actually feed it RGB [00:23:34 CET] <MapMan> yeah, I imagine. Close but no cigar. [00:24:06 CET] <JEEB> basically my idea was to add an "RGB" mode into nvenc that would feed it RGB planes, and then rewrite the parameter set values [00:26:12 CET] <MapMan> well, I'm not that savvy when it comes to encoders and stuff, but I don't understand why RGB isn't there out of the box [00:26:18 CET] <MapMan> probably because it's a rare use case? [00:27:43 CET] <JEEB> yes, although at the point where you're taking in 4:4:4 planes [00:28:02 CET] <JEEB> it's literally just setting different parameter sets and enabling another type of input [00:31:17 CET] <MapMan> Do I have any other alternative to record lossless/rgb/60hz ? I tried utvideo and it produces 1:1 lossless for me but since it's all running on CPU, I can't output 60fps [00:32:33 CET] <furq> i mean you could use rawvideo [00:34:22 CET] <TheAMM> kepstin: I made some vp9 444 files from pixiv animations and got a lot of "this doesn't work" from FF users [00:34:43 CET] <TheAMM> This was just a few months ago, but I did delete them so it's possible I fucked up somehow [00:35:04 CET] <cryptodechange> when doing IVTC, I get interlaced frames using 'fieldmatch,decimate', am I better off using 'pullup -r 24000/1001' or adding yadif? [00:48:57 CET] <wfbarksdale> i'm still stuck on this remuxing code with ffmpeg 2.8, everything looks good except for the video stream doesn't play back and when i probe it I see the error AVC: nal size 0 [00:49:07 CET] <wfbarksdale> just been testing setting different things on the format context / stream / codec context, but nothing seems to work. [00:49:42 CET] <wfbarksdale> I'm assuming I don't need to open the codec? don't see why I would since I'm not encoding anything, just copying packets out of one file and into another [00:50:41 CET] <wfbarksdale> as far as I can tell, this nal size is derived from the extradata, which I am simply copying over from the source stream... [00:50:46 CET] <wfbarksdale> is there anything wrong with that? [01:13:20 CET] <MapMan> JEEB: I give up, but as a last note, I downloaded geforce experience which records at yuv420 and it does not produce the jagged lines or blurred text. There must be something wrong with OBS? [02:20:51 CET] <MapMan> JEEB: fuckity fuck: https://obsproject.com/mantis/view.php?id=624 [02:27:28 CET] <MapMan> https://cdn.discordapp.com/attachments/374636084883095554/54469025894445876… [02:27:36 CET] <kepstin> cryptodechange: depends on the particular content of your video which is better. Note that pullup's builtin deinterlacer is basically the same as kerndeint, i think? so you can get better looking results with fieldmatch plus a fancier deinterlacer for some types of content. [02:27:37 CET] <MapMan> JEEB: no artifacts: https://cdn.discordapp.com/attachments/374636084883095554/54469025894445876… [02:28:06 CET] <kepstin> oh wait, no, pullup doesn't have a builtin deint? [02:28:12 CET] <kepstin> i might be getting confused with filmdint [02:28:22 CET] <kepstin> we have too many detelecine/deinterlacing filters :/ [02:29:48 CET] <kepstin> the main benefit of pullup is that in theory it can pass through 30p content mixed with 24-telecined content properly, but that's kind of a rare case, and it probably won't help for the kind of stuff that makes it through fieldmatch without being matched. [02:29:58 CET] <kepstin> then again, try it and see? :/ [06:16:12 CET] <kepstin> huh. does there exist an mp4/isombff format that accepts both vp9 and alac? [06:16:32 CET] <kepstin> I can get vp9 if i use -f mp4, and alac if i use -f ipod, but not both [06:16:57 CET] <kepstin> hmm. guess I could use the experimental flac support :) [07:35:16 CET] <snowcatman> when checking cropdetect i get like 9 lines of parsed readings. how do i know whitch one to use? [07:48:45 CET] <snowcatman> I am reading https://ffmpeg.org/ffmpeg-all.html#cropdetect and am woundering how to use the flags to set the filter? so far i know this much "input -vframes 10 -vf cropdetect -f null ^ output". [11:41:40 CET] <iongion> Does anyone know if I can use ffmpeg cli to inject custom metadata at regular intervals in an RTMP live stream, the flv file format supports sending onMetadata tag whenever one needs to call it [14:20:02 CET] <kepstin> snowcatman: the cropdetect filter updates as it gets further into the video, so the later ones are usually better (particularly if there were dark/black frames early in the video) [14:20:10 CET] <kepstin> snowcatman: but you really need to test the values and see [14:20:34 CET] <kepstin> snowcatman: to do the actual cropping, you have to switch to the crop filter, and use the values printed by cropdetect as arguments to the crop filter [14:24:44 CET] <keegans> where is the channel log ? [14:26:55 CET] <durandal_1707> https://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/ [14:29:25 CET] <snowcatman> sorry, for my ignorance. i am still learning how to use ffmpeg. what does that look like? the "crop filter"? input cropfilter output? As i was just "input.ext -ss 1200 -t 15 -metadata:s:v:0 title="H264 Video" -vf crop=-704:48:714:64 -c:v libx264 -preset ultrafast -crf 0 output.ext" as an example. what is the difrance between crop and cropfilter? [14:33:18 CET] <keegans> JEEB: any idea who i can talk to about the cenc mp4 encryption impl [14:33:28 CET] <keegans> because it is broken on this file -- but another library called Bento4 seems to open it fine [14:33:35 CET] <keegans> i'd *really* rather use ffmpeg though [14:33:42 CET] <keegans> because bento is a pain in the ass [14:35:42 CET] <JEEB> look at the git blame of the implementation [14:35:51 CET] <JEEB> if you know the file, `git gui blame -- libavformat/FILENAME.c` [14:35:57 CET] <JEEB> that shows you per-line blame info [14:36:54 CET] <kepstin> snowcatman: the crop filter is the filter named "crop"... [14:38:10 CET] <iongion> Anyone knows if there is a way to inject dynamic metadata in live stream using flv over rtmp. I am recording a game and want to send the score values too, not only audio and video, to have the best sync [14:39:54 CET] <keegans> JEEB: is there a way to just disable it completely - because i just have to read samples, but it won't even let me do that, it just says "incorrect number of samples in encryption info," yet running `ffprobe -v trace` shows the correct number of samples and their offsets [14:40:25 CET] <keegans> so if i can just disable that functionality maybe it would work [14:40:31 CET] <snowcatman> kepstin: thank you. I will keep playing with it. seen this """ -filter:v "crop=100:60:120:80" """ so i was thinking there was more complexity to it. [14:41:04 CET] <JEEB> keegans: no idea, I've been keeping out of CENC but as far as I can see it's been made for some very limited use cases by possibly GOOG? [14:41:09 CET] <JEEB> don't remember [14:41:23 CET] <JEEB> anyways, $dayjob [14:41:37 CET] <kepstin> snowcatman: the last part of the output of cropdetect looks like "crop=1904:1072:8:4" - you just have to drop that into an ffmpeg command line like -vf crop=1904:1072:8:4 [14:41:42 CET] <keegans> ah , sorry lol [14:41:45 CET] <keegans> i'll leave you be :D [14:41:59 CET] <keegans> thanks for your help so far anyway [14:42:37 CET] <kepstin> snowcatman: see https://www.ffmpeg.org/ffmpeg-filters.html#crop for an explanation of what those numbers mean [14:42:54 CET] <kepstin> (they're, in order: w, h, x, y) [14:49:16 CET] <snowcatman> kepstin: thank you. I have yet to stumple onto this page. its very helpfull. guess i need to read up on this site much more. again thank you. [14:52:50 CET] <perseiver> Hello, I want to use ffmpeg in my application. What is the best place to start? I have compiled ffmpeg with --shared-library, don't know how to include in my code. Please help if anyone has done simple program [14:57:11 CET] <dongs> i have a file without any pts, just raw hevc frames. i wanna remux it to ts or mkv or something [14:57:24 CET] <dongs> its fixed framerate,is there anything i can do to make ffmpeg just re-create pts from scratch [14:57:53 CET] <dongs> i tried -copyts and -ffopt +setpts or wahtever shit, various random examples from internets, none of teh stuff worked [15:00:14 CET] <dongs> http://bcas.tv/paste/results/0fW53Z41.html this is the source hevc [15:01:13 CET] <JEEB> I think there was a stream-copy frame rate application patch [15:01:14 CET] <JEEB> on the ML [15:01:25 CET] <dongs> oh hi jeeb [15:01:31 CET] <JEEB> ohai [15:01:38 CET] <dongs> there's more of that BS4K hevc [15:01:42 CET] <dongs> proeprly clear this time [15:02:11 CET] <JEEB> yea I don't see it in master yet so you might want to ping that patch if nobody's cared about it [15:02:30 CET] <JEEB> not 100% sure it will handle b-frames correctly but apparently that re-ordering was fixed? [15:02:50 CET] <JEEB> https://patchwork.ffmpeg.org/patch/11688/ [15:02:56 CET] <JEEB> this is the latest iteration I think? [15:03:09 CET] <dongs> i have no idea, isn't it just a matter of setting SOME pts at start and then since its 60000/1001 fps just incrementing [15:03:20 CET] <dongs> ah i see [15:03:26 CET] <dongs> thats not normally allowed on stream copy? [15:03:31 CET] <vlt> Hello. I want to playback videos on an "HP x2 210" (intel atom X5-Z8300) with a 1280x800 screen. What codec can I use to get the lowest power consumption on this machine? [15:03:34 CET] <dongs> i aint got time to recompile ffmpeg haha. [15:03:41 CET] <vlt> Does it make sense to resize to 1280x800? [15:03:46 CET] <JEEB> then use l-smash's muxer or something? [15:03:54 CET] <JEEB> for mp4 [15:03:56 CET] <dongs> vlt, any modern intel atom will have dxva support [15:04:05 CET] <JEEB> or mkvmerge for mkv [15:04:11 CET] <dongs> and X5 doesnt sound nonmodern [15:04:15 CET] Action: vlt googles dxva [15:04:17 CET] <dongs> oh good point i never tried jsut thrwoing it into mkvmerge [15:04:29 CET] <dongs> letseee [15:04:39 CET] <JEEB> I'll have to check the patch for frame rate when I have time [15:04:46 CET] <JEEB> kind of had hands full with ARIB STD-B24 [15:04:47 CET] <JEEB> for now [15:04:55 CET] <JEEB> (and mpv) [15:05:36 CET] <vlt> dongs: I don't have a Microsoft OS on that device. It's Ubuntu 16.04 and mpv. [15:05:37 CET] <dongs> isnt that boring? B60 is where all the shit is [15:05:43 CET] <dongs> vlt, im extremely sorry to hear that. [15:05:59 CET] <JEEB> vlt: vaapi then [15:06:11 CET] <dongs> i don't think lunix supports hardware accelerated video, at least not at the level windows would. so you're probly SOL. maybe something with vaapi, no idea what level of support of that is for intel gfx. [15:06:12 CET] <JEEB> (which is the hwdec interface on lunix for intel/AMD) [15:06:24 CET] <JEEB> vaapi is the intel thing, originally [15:06:28 CET] <JEEB> and it seems pretty alright by now [15:06:51 CET] <dongs> https://i.imgur.com/RRC3dJh.jpg [15:07:48 CET] <dongs> well lol, i think mkv might jsut work [15:08:08 CET] <dongs> ya it did [15:08:24 CET] <JEEB> 'grats [15:08:36 CET] <dongs> ~at least there's a proper timestamp now and its seekable [15:08:55 CET] <dongs> hmm i dont think mkvmerge supporst latm AAC tho [15:08:57 CET] <vlt> JEEB: I found this list of supported video codecs. https://en.wikipedia.org/wiki/Video_Acceleration_API#Supported_video_codecs [15:09:11 CET] <dongs> vlt: yes, so just pick H264 [15:09:14 CET] <vlt> JEEB: Do you know if they differ in power cinsumption? [15:09:16 CET] <keegans> i have an HLS stream, is it possible for me to download into an mp4 without doing any decoding? [15:09:29 CET] <keegans> I assume -c copy does decoding [15:09:30 CET] <dongs> anything newer than a decade will have harwdare offload support for it [15:10:23 CET] <dongs> eyah definitely broken [15:10:29 CET] <dongs> time to give .aac samples to mkv guise [15:12:52 CET] <Mavrik> keegans: no, -c copy does remuxing, but no decoding [15:13:05 CET] <keegans> ah I can't have that either it seems [15:13:31 CET] <keegans> this hls stream is about 3 minutes, yet when I run ffmpeg -i "hls url" -c copy output.mp4 and then ffprobe output.mp4 it reports 19 seconds of audio [15:13:38 CET] <keegans> so idk what is happening [16:47:11 CET] <iongion> keegans - remuxing is not time consuming at all, use concat protocol as that one offers me the best results - check here https://trac.ffmpeg.org/wiki/Concatenate [16:47:27 CET] <keegans> no, its not that its time consuming, its breaking my file [16:47:38 CET] <keegans> ffmpeg doesn't decode this HLS stream properly [16:47:46 CET] <keegans> or parse rather [16:48:00 CET] <iongion> keegans - what kind of segments do you have in your HLS ? [16:48:06 CET] <iongion> mpegts or mp4 ? [16:48:24 CET] <JEEB> if you care about HLS, I recommend you take affirmative action since the HLS modules really need someone with a calm head and time [16:49:49 CET] <keegans> well the HLS file just references an mp4 file that is segmented, so i can just download the entire mp4 file. if i do that, ffprobe shows all the samples, sizes and offsets [16:50:02 CET] <keegans> yet when i try to do anything with it, ffmpeg breaks and exits [16:50:10 CET] <keegans> (ffprobe -v trace i mean) [16:50:33 CET] <iongion> I see, well, I never use hls as input for ff tools [16:50:41 CET] <keegans> https://github.com/FFmpeg/FFmpeg/blob/0b50f27635f684ec0526e9975c9979f35bbf4… [16:50:45 CET] <keegans> that is what prints^ [16:50:50 CET] <keegans> with the correct info i believe [16:50:58 CET] <JEEB> keegans: if it's encrypted it might just bork at parsing since of course you can't parse an encrypted sample [16:51:12 CET] <keegans> yeah it's encrypted, but its encrypted sample by sample [16:51:21 CET] <keegans> so before you decode a sample you decrypt it [16:51:25 CET] <JEEB> wyes [16:51:29 CET] <keegans> meaning it shouldn't break file parsing like this [16:52:11 CET] <JEEB> well, various parts in lavf can attempt to parse stuff from the bit stream. which of course fails if you haven't enabled decryption [16:52:22 CET] <JEEB> although in API usage I'm not sure if this will cause a fatal fail [16:52:25 CET] <keegans> i tried using Bento4 and mp4parse-rust and they both have the same issue, they report the stsc box contains no samples [16:52:57 CET] <keegans> yeah in api usage i am trying to just cycle through samples, i decrypt, then i attempt to decode but it errors out saying the number of samples in the encryption info is wrong [16:53:08 CET] <keegans> but it should just ignore that, because it doesnt affect what i am trying to do [16:53:45 CET] <JEEB> there was a patch on the mailing list regarding skipping parsing for encrypted samples that aren't decryptable (yet), but people basically got into opinion discussion there if that's valid at all for FFmpeg [16:54:00 CET] <JEEB> but yes, proper cenc decryption where you provide the key should work [16:54:10 CET] <JEEB> (which doesn't work for those who want to pass stuff into a DRM engine) [16:54:36 CET] <JEEB> and it seems like some people see enabling DRM usage as a problem (the encrypted sample pass-through) [16:54:49 CET] <JEEB> you can find it on the mailing list since I only vaguely remember the patch and the discussions [16:55:19 CET] <keegans> ok, i'll take a look, yeah [16:55:51 CET] <JEEB> also one of the cenc modes the mov/isobmff parser just doesn't support [16:55:55 CET] <keegans> what list would it be on likely? [16:55:56 CET] <JEEB> IIRC that was PatchesWelcome [16:55:59 CET] <JEEB> ffmpeg-devel [16:56:05 CET] <JEEB> that's the patch list [16:56:14 CET] <JEEB> also you can probably search through patchwork [16:56:40 CET] <JEEB> https://patchwork.ffmpeg.org/patch/10350/ [16:56:43 CET] <JEEB> this one it seems? [16:57:36 CET] <JEEB> although I'm not sure if this is what you are noticing [16:58:14 CET] <keegans> hmm [16:58:40 CET] <keegans> it specifically says "Incorrect number of samples in encryption info" [16:58:53 CET] <keegans> when i try to just cycle through sample data [16:59:48 CET] <JEEB> anyways, unfortunately I don't know the CENC stuff too well :P [16:59:56 CET] <JEEB> it had the "made for google and that's it" vibe [17:00:00 CET] <keegans> :D [17:00:21 CET] <JEEB> and I meant the code mostly, although I haven't looked too hard into the CENC spec either (although I have it around I think) [17:03:47 CET] <keegans> it seems to exit at `av_read_frame` with the incorrect number of samples in encryption info, yeah [17:03:53 CET] <keegans> i will try the patch i guess [17:04:29 CET] <keegans> and then i will report back with my findings [17:10:49 CET] <keegans> JEEB: it fixed it !!! [17:10:52 CET] <keegans> thank you so much [18:49:51 CET] <keegans> getting strange errors with the AAC decoder like : `[aac @ 0x56035f32a300] channel element 3.10 is not allocated` [18:50:28 CET] <keegans> is the decoder broken or did i fail to decrypt properly likely ( JEEB ) ? [19:09:58 CET] <JEEB> keegans: could be lack of extradata if that's used in AAC [19:10:39 CET] <JEEB> dongs: I've got a back-log and I've got more ye olde style samples so I'm getting that done first [19:10:48 CET] <JEEB> then the MMTP madness [19:11:05 CET] <JEEB> also lol did Japan go for the LATM meme as well? [19:12:18 CET] <keegans> https://pastebin.com/5wzGHG0G [19:12:22 CET] <keegans> there is side data it appears [19:43:30 CET] <ossifrage> What is a good choice for C (or native go if such a thing exists) for multiplexing h.264 or h.265 *live* elementary streams into fmp4 data? ffmpeg can do it, but is there a good choice for just the multiplexing code? [19:44:13 CET] <JEEB> FFmpeg's libavformat is what you mean in API way [19:44:19 CET] <JEEB> which only does multiplexing and demultiplexing [19:44:40 CET] <JEEB> then there's the L-SMASH library for just mp4 [19:44:50 CET] <ossifrage> JEEB, ah cool, I thought you ended up having to pull in the entire ffmpeg suite [19:45:34 CET] <JEEB> you can build a minimal one if you want to limit it. but even if you don't limit at build time, you only need some of the libraries [19:46:04 CET] <JEEB> and then there's GPAC's library for mp4 as well [19:46:14 CET] <JEEB> so you have at least three different alternatives for writing fragmented mp4 [19:46:39 CET] <ossifrage> I was looking at gpac, but they didn't seem to have api docs, just docs for the tools which seemed kinda weird [19:48:19 CET] <ossifrage> Trying to generate low latency DASH live streams from a hardware encoder (camera SOC) [19:58:59 CET] <Ariyasu> is there anyway to get ffmpeg to read a videoredo project file [19:59:33 CET] <JEEB> probably not. FFmpeg is closer to something the editor or renderer would be utilizing to open or read/write media [19:59:41 CET] <Ariyasu> a project file has cuts marked for an input video file, would save time if i could encode directl y from the source instead of cutting [19:59:50 CET] <Ariyasu> yeah [20:00:00 CET] <JEEB> if it's simple you could either use lavfi or vapoursynth [20:00:04 CET] <Ariyasu> ok i guess i can try script somthing to parse the cutpoints [20:00:08 CET] <JEEB> yea [21:43:31 CET] <MapMan> JEEB: have you seen what I said yesterday? Those 'artifacts' we looked into yesterday were caused by a precision bug somewhere in OBS. [21:43:37 CET] <JEEB> yea [21:44:10 CET] <JEEB> having buffers aligned and properly set is always good :) [21:44:43 CET] <JEEB> also I'll be seeing if TheAMM ever gets to putting his thing in review :) [21:44:52 CET] <JEEB> even though lavd designs frighten me vOv [21:49:46 CET] <MapMan> Asking out of curiosity: how is ffmpeg affected by phenomena such as screen tearing without vsync in games? Will ffmpeg capture frames properly or will the screen tearing be captured in video as well? [21:50:20 CET] <JEEB> depends on which buffer at which point exactly the capture module (whatever that is) will get it [21:50:51 CET] <MapMan> That's what I thought [21:54:13 CET] <kepstin> as far as the gdigrab stuff goes, i think it's basically "up to the driver"? although who knows what's going on there. [23:26:51 CET] <ossifrage> Huh, I can't find any DASH videos on youtube via youtube-dl (has youtube reduced the use of DASH?) [23:29:40 CET] <ossifrage> On the 10 videos I tried they all have DASH audio, but no DASH video, I know in the past they where serving DASH [23:32:42 CET] <JEEB> whether they use mp4 fragments or webm fragments depends [23:32:59 CET] <JEEB> AVC -> mp4, VP8/9 -> webm, AV1 -> mp4 [23:34:15 CET] <ossifrage> I'm just running youtube-dl -F to list the formats and none of the links I tested had a DASH video (just "audio only DASH audio") [23:34:36 CET] <JEEB> whatever that means [23:34:44 CET] <JEEB> I've still seen mp4 fragments and webm fragments [23:35:41 CET] <ossifrage> Yeah, I can't think of a good reason why you would chop the audio up into fragments, if you have to dynamically switch at audio bitrates you are kinda screwed [23:36:18 CET] <furq_> is youtube serving av1 already [23:38:11 CET] <ossifrage> furq_, I saw av01 (at potato resolutions), avc, vp9 [23:40:31 CET] <BtbN> potato resolutions is where it makes the most sense really [23:40:54 CET] <BtbN> helps people with horrible bandwidths, and can actually be decoded on normal PCs [23:41:04 CET] <ossifrage> furq, only a few of the links I tested had av01... but 144p, where can that still be of any use [23:43:02 CET] <ossifrage> (I SMS from my sister with videos and they are often transcoded into potatoes with lower resolution then a LED backlight [00:00:00 CET] --- Wed Feb 13 2019

1 0

ffmpeg-devel.log.20190211
by burek 12 Feb '19

12 Feb '19

[00:28:19 CET] <JEEB> michaelni: thanks for the review. some of those mistakes were just plain stupid [00:29:13 CET] <michaelni> JEEB, np, glad it was useful [00:30:04 CET] <JEEB> like how on earth did I miss the entry part of the struct (or how did I miss av_bprint_finalize) [00:30:41 CET] <JEEB> possibly having a narrow vision when looking at specific parts of other subtitle decoders [00:35:38 CET] <iive> JEEB, this is why we have review, because seeing other people's mistakes is easier than seeing our own. :D [00:35:48 CET] <JEEB> yes [00:36:36 CET] <JEEB> I did attempt to call for reviews, but unfortunately at the time I did get I think three (and then I think I did four revisions by myself after noticing some things) [00:37:00 CET] <JEEB> like noticing that I was applying RGB colors onto BGR ASS [00:37:13 CET] <JEEB> (although that I was kindly told of by a tester to be honest) [01:03:00 CET] <cone-201> ffmpeg 03James Almer 07release/4.1:33c800977350: avcodec/cbs_av1: don't call cbs_av1_read_trailing_bits() when no bits remain in the OBU [02:07:03 CET] <JEEB> there we go [02:09:33 CET] <JEEB> now, good night. and for the record, I will not be able to push anything during the day so if there's some really clear ones feel free to push them instead. [05:44:28 CET] <cone-922> ffmpeg 03Reto Kromer 07master:6174686bc346: doc/faq: update macOS and URLs [12:16:56 CET] <rcombs> jkqxz: dunno if you saw this: https://github.com/intel/libva/pull/266 [13:41:15 CET] <shivamgoyal> I want to contribute to ffmpeg. I know C lang but has a little experience with multimedia. I need some guide about from where to start. [13:45:27 CET] <durandal_1707> shivamgoyal: for example, write PSF (Portable Sound Format) playback support [15:14:49 CET] <robUx4> is there a place to report security issues ? (ie without it going too public) [15:15:40 CET] <robUx4> and/or who is maintaining the Matroska demuxer ? [15:22:58 CET] <iive> robUx4, there used to be a security maillist, that is not public. not sure if it is still relevant. [15:24:04 CET] <iive> robUx4, https://www.ffmpeg.org/security.html [15:28:47 CET] <robUx4> ok, thx [20:12:23 CET] <durandal_1707> what is AC-4 name under ATSC ? [20:12:45 CET] <JEEB> https://www.atsc.org/atsc-30-standard/a342-part-2-ac-4-system/ ? [20:14:03 CET] <durandal_1707> ATSC A/342 Part 2 ? [20:14:20 CET] <JEEB> röbäbly. I didn't look into the PDF [20:14:32 CET] <JEEB> ah, it's usage [20:14:48 CET] <JEEB> so it's basically a spec for AC-4 within ATSC [20:15:21 CET] <JEEB> it does describe the high level bit stream tho [20:15:27 CET] <JEEB> like the TOC etc [20:16:06 CET] <JEEB> it then points towards ETSI TS 103 190-1/2 [21:00:01 CET] <cone-474> ffmpeg 03James Almer 07master:00fd38f1846a: avformat/mov: don't rescale mastering display values from the SmDm atom [22:01:56 CET] <feliwir> Hey, on a scale from 1-10 how hard would it be to write a vp6 encoder? [22:02:20 CET] <feliwir> We already have the vp6 decoder stuff [22:02:36 CET] <cone-474> ffmpeg 03Charles Liu 07master:aa25198f1b92: avformat/mov: fix hang while seek on a kind of fragmented mp4 [22:02:37 CET] <cone-474> ffmpeg 03Marton Balint 07master:0c3333faf6b7: configure: warn about disabled explicitly enabled components [22:06:09 CET] <atomnuker> feliwir: a bad one? [22:06:59 CET] <atomnuker> a week maybe, if you had inverse transforms (longer if you ripped them out of some binary) [22:07:59 CET] <atomnuker> afaik the entropy coding system is the same as in vp9 so you could reuse that code (or just do the inverse of decoding, they were simple enough iirc) [22:10:18 CET] <durandal_1707> ==28102== Conditional jump or move depends on uninitialised value(s) [22:10:18 CET] <durandal_1707> ==28102== at 0x5710CC1: append_packet_chunked (utils.c:282) [22:10:18 CET] <durandal_1707> ==28102== by 0x5657F35: mov_read_packet (mov.c:7724) [22:10:18 CET] <durandal_1707> ==28102== by 0x5711D28: ff_read_packet (utils.c:856) [22:10:18 CET] <durandal_1707> ==28102== by 0x57133C1: read_frame_internal (utils.c:1582) [22:10:21 CET] <durandal_1707> ==28102== by 0x5717D19: avformat_find_stream_info (utils.c:3772) [22:10:23 CET] <durandal_1707> ==28102== by 0x408D35: open_input_file (ffmpeg_opt.c:1126) [22:10:26 CET] <durandal_1707> ==28102== by 0x4083A9: open_files (ffmpeg_opt.c:3273) [22:10:28 CET] <durandal_1707> ==28102== by 0x4081BB: ffmpeg_parse_options (ffmpeg_opt.c:3313) [22:10:31 CET] <durandal_1707> ==28102== by 0x41BAAD: main (ffmpeg.c:4869) [22:10:36 CET] <durandal_1707> FIX THIS CRAP ASAP!!! [22:13:16 CET] <JEEB> did the hcom probing thing get fixed btw? I remember posting about valgrind complaining about it at some point [22:14:50 CET] <durandal_1707> JEEB: yes it have been fixed [22:14:54 CET] <JEEB> cool [22:16:47 CET] <cone-474> ffmpeg 03Marton Balint 07release/4.1:110eff79caf4: avformat/async: fix assertion condition when draining buffer [22:16:48 CET] <cone-474> ffmpeg 03Charles Liu 07release/4.1:53f3f5233f38: avformat/mov: fix hang while seek on a kind of fragmented mp4 [22:19:16 CET] <jamrial> durandal_1707: was that introduced recently? [22:20:00 CET] <durandal_1707> jamrial: dunno, happens with audio and video files that comes from AC-4 site [22:23:09 CET] <durandal_1707> jamrial: http://dash.akamaized.net/dash264/TestCasesMCA/dolby/5/1/ [23:02:51 CET] <feliwir> @atomnuker, a bad one would be enough yes :D [23:02:57 CET] <feliwir> But i doubt that would get accepted [23:03:32 CET] <feliwir> Is there any reason why noone ever bothered to write an encoder? [23:07:41 CET] <rcombs> because why would you want to [23:07:58 CET] <rcombs> I can't think of a practical use-case [23:11:43 CET] <rcombs> durandal_1707: huh, I don't see any obvious issue there; could you run with --track-origins=yes? [23:15:28 CET] <durandal_1707> ==10769== Uninitialised value was created by a heap allocation [23:15:28 CET] <durandal_1707> ==10769== at 0x4C2FA3F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) [23:15:31 CET] <durandal_1707> ==10769== by 0x4C31D84: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) [23:15:34 CET] <durandal_1707> ==10769== by 0x810E543: av_realloc (mem.c:144) [23:15:37 CET] <durandal_1707> ==10769== by 0x810E543: av_fast_realloc (mem.c:488) [23:15:39 CET] <durandal_1707> ==10769== by 0x5661DCE: mov_read_trun (mov.c:4784) [23:15:42 CET] <durandal_1707> ==10769== by 0x56564E4: mov_read_default (mov.c:6865) [23:15:49 CET] Last message repeated 2 time(s). [23:15:49 CET] <durandal_1707> ==10769== by 0x5656B72: mov_read_header (mov.c:7405) [23:15:52 CET] <durandal_1707> ==10769== by 0x57114CB: avformat_open_input (utils.c:631) [23:15:54 CET] <durandal_1707> ==10769== by 0x408BB9: open_input_file (ffmpeg_opt.c:1104) [23:15:57 CET] <durandal_1707> ==10769== by 0x4083A9: open_files (ffmpeg_opt.c:3273) [23:15:59 CET] <durandal_1707> ==10769== by 0x4081BB: ffmpeg_parse_options (ffmpeg_opt.c:3313) [23:16:26 CET] <durandal_1707> rcombs: just download video files from link above and try to reproduce [23:33:00 CET] <feliwir> @rcombs we could need it: https://github.com/OpenSAGE/OpenSAGE [23:33:24 CET] <feliwir> The old EA games used vp6 and there isn't an opensource encoder around (or any good encoder at all) [23:46:44 CET] <atomnuker> feliwir: we have a bad jpeg2000 encoder, sure it would be merged [23:48:12 CET] <atomnuker> though can't you implement support for a more modern codec as well? low bitrate vp8 will look just as bad, maybe worse [00:00:00 CET] --- Tue Feb 12 2019

1 0

ffmpeg.log.20190211
by burek 12 Feb '19

12 Feb '19

[01:05:02 CET] <keegans> I'm getting a "Incorrect number of samples in encryption info" error, but when I ffprobe -v trace the file it shows the correct number of samples and their info [01:05:12 CET] <keegans> Is there a way to prevent ffmpeg from exiting or displaying this error? [01:30:57 CET] <JEEB> keegans: sorry for not being able to check things too much, I've been reviewing stuff in two projects and also fixing stuff that other people have found in my code :) [02:18:14 CET] <keegans> JEEB: yeah no worries , just trying to figure out why ffmpeg is refusing to read this mp4 file [02:18:31 CET] <keegans> i got it to encode the mp4 as pcm and then play it [02:18:51 CET] <keegans> but now i have to do some things to the packets before i decode them, but ffmpeg is throwing errors about issues with the sample count in this file [02:19:08 CET] <keegans> yet when i ffprobe -v trace it it shows all the correct sample offsets and sizes [02:19:10 CET] <keegans> so idk wtf [02:19:35 CET] <cryptodechange> Still getting interlaced frames with fieldmatch,yadif,decimate [02:19:53 CET] <cryptodechange> converting from telecine DVD (PPPII mostly) [02:20:34 CET] <cryptodechange> Getting a lot of 'Frame #X at X is still interlaced' messages [02:23:15 CET] <keegans> https://github.com/FFmpeg/FFmpeg/blob/7f8bfbee36638f3bcacea8a6af5eece887883… [02:26:10 CET] <keegans> i wonder if i just `nop` that out [03:23:36 CET] <keegans> be back later [04:16:40 CET] <killown> is that possible to create a blank video that displays a logo in the center? [04:17:00 CET] <killown> I have this ffmpeg -t 7200 -s 640x480 -f rawvideo -pix_fmt rgb24 -r 25 -i /dev/zero empty.mpeg [04:17:15 CET] <killown> but I want to display a logo [10:20:14 CET] <friendofafriend> I'm encoding a video with libx264, from a single image, at 30fps. I can't change the framerate. Is there some way to make the stream use less bandwidth, as the scene never changes? [13:48:50 CET] <merethan> friendofafriend, my guess is that the scene does change. Aren't you encoding a noisy image? [15:31:50 CET] <Fyr> guys, when copying video into mp4, FFMPEG adds: [15:31:50 CET] <Fyr> Stream #0:2(eng): Data: bin_data (text / 0x74786574) [15:31:56 CET] <Fyr> what is that? [15:32:29 CET] <Fyr> I used -sn option, the input file has only a video and an audio stream. [15:34:05 CET] <JEEB> could be chapters if your input had that, since that is also output as text [15:34:15 CET] <Fyr> wow, it has chapters. [15:34:27 CET] <JEEB> (or well, one of the ways of putting chapters into MP4) [15:34:40 CET] <JEEB> (there was the MOV way and the Nero we-did-it-our-way way) [17:24:31 CET] <kepstin> cryptodechange: the ones where you get that '...is still interlaced' message are the ones that got fix, it's the ones where it didn't detect that which are the problem :) [17:25:09 CET] <kepstin> cryptodechange: sounds like you have input with a lot of bad cuts or mismatched overlay/crossfades, etc.? [17:51:17 CET] <kepstin> cryptodechange: hmm, that said, yadif with no other options should be deinterlacing all frames [17:51:27 CET] <kepstin> cryptodechange: are you actually seeing interlaced frames in the result? [17:52:49 CET] <kepstin> cryptodechange: that "... is still interlaced" message is output from the fieldmatch filter, it's basically saying "I couldn't find any fields that matched close enough, all possible matches left some combing artifacts", the yadif filter should be removing the combing [20:53:02 CET] <friendofafriend> merethan: A noisy image? I don't follow, it's just one image. [20:53:55 CET] <merethan> Image as in, one and just one frame only? [21:00:34 CET] <doyouhas> ello squad fam [21:00:40 CET] <doyouhas> anyone fucking around here? [21:05:45 CET] <friendofafriend> merethan: One and just one frame only. [21:06:07 CET] <merethan> Mm weird [21:06:30 CET] <merethan> My best guess is that it has something to do with the keyframe rate. [21:07:31 CET] <merethan> Every so many frames there's a key frame, that kind of serves as a rebuild or reset of the image. Every frame after the keyframe only stores the differences from the previous one. [21:08:32 CET] <merethan> Since your video feed is static, so there ain't any differences from the keyframe to the next frame. But the rate at which keyframes are inserted is I recon a configuration option. [21:08:41 CET] <friendofafriend> I'm already using the libx264 "stillframe" tune. I saw an option to use "-x264-params keyint=". [21:09:41 CET] <friendofafriend> But I'm not really sure if that interferes with -g . [21:10:00 CET] <furq> it makes no difference with a still image [21:10:23 CET] <furq> keyint and -g are the same thing with x264 anyway but even changing scenecut or min-keyint will have no effect [21:23:05 CET] <friendofafriend> Ah. I thought about making the framerate really low, but some devices I test low framerate streams on seem awfully unhappy with it. [21:25:25 CET] <furq> if this is for youtube then the lowest framerate they transcode to is 6 [21:25:41 CET] <furq> it doesn't matter so much what you give them but i always just use 6 [21:29:11 CET] <wfbarksdale> I'm working on some code for remuxing an mp4 using ffmpeg, when i ffprobe the output file i see the warning `AVC: nal size 0`, everything else looks normal... any one know what I might be missing? presumably I am not setting something properly on output context or on the video stream? [22:23:39 CET] <wfbarksdale> Still working on this: very confused about what I am doing wrong. I've correctly copied the `extradata` over from the input file: I'm working on some code for remuxing an mp4 using ffmpeg, when i ffprobe the output file i see the warning `AVC: nal size 0`, everything else looks normal... any one know what I might be missing? presumably I am not setting something properly on output context or on the video st [22:23:40 CET] <wfbarksdale> ream? [22:32:03 CET] <doyouhas> why the hell are there no good ffmpeg wrappers in python [22:32:44 CET] <doyouhas> i can run the exact command in a terminal but when i run with ffmpy i get exception :( [22:40:43 CET] <w1kl4s> just run subprocess [22:41:01 CET] <w1kl4s> if you don't have ffmpeg in path then you are doing something wrong anyway [22:41:29 CET] <furq> if you know the command you want to run then why do you need a wrapper that abstracts it for you [22:41:37 CET] <furq> that just means you have to learn two things instead of one [22:41:50 CET] <furq> and then there are two things that might break instead of one [22:41:54 CET] <furq> and so on [22:42:18 CET] <w1kl4s> i mean pretty much everything that relies on ffmpeg requires it to be in path [22:42:23 CET] <w1kl4s> and just calls a subprocess [22:42:34 CET] <furq> that's apparently what ffmpy does [22:42:42 CET] <w1kl4s> lol [22:42:46 CET] <w1kl4s> then why even use it [22:42:53 CET] <w1kl4s> what's the actual reason to [22:43:06 CET] <furq> i guess it makes it look more like python? [22:43:09 CET] <furq> why you'd want that i don't know [23:10:41 CET] <MapMan> Hi! I'm having problems recording at 60 fps even though my hardware is capable of such recordings. Can someone take a look at how I'm running ffmpeg and tell me what's wrong? https://gist.github.com/Mapiarz/63165867470d19818694da68fc702905 [23:11:20 CET] <MapMan> By default, dshow input device caps at 30, I can edit registry and make the input any fps my pc supports, e.g. 100 fps [23:11:38 CET] <MapMan> ffmpeg decides to duplicate frames instead of recording at the framerate I tell him to, e.g. 60 fps [23:11:53 CET] <kepstin> MapMan: no idea, it should be mostly up to the performance of whatever external application is doing the screen capture [23:12:31 CET] <JEEB> MapMan: is it the vsync logic or which part doing derps at you? [23:12:40 CET] <kepstin> MapMan: note that you might need to use the -framerate input option [23:13:17 CET] <MapMan> https://gist.github.com/Mapiarz/e90b303e5cc019bd055a3b06873cb0f4 [23:13:21 CET] <MapMan> Heres -v trace log [23:13:46 CET] <JEEB> ok, so your input is at least perceived as 60Hz [23:14:39 CET] <JEEB> and yea, that *** X dup [23:14:43 CET] <JEEB> is the vsync code in ffmpeg.c [23:14:53 CET] <MapMan> my cpu/gpu usage is really low, I recorded lossless with other apps (like obs, which uses ffmpeg anyway...) [23:15:18 CET] <MapMan> And I did try lowering the resolution, using 'medium' profile and so on [23:15:24 CET] <JEEB> (also in your mind separate FFmpeg as the framework, and ffmpeg.c which is an API client with its own logic [23:15:38 CET] <MapMan> I see [23:15:50 CET] <JEEB> check if the timestamps logged there make sense [23:15:55 CET] <JEEB> the dshow ones I guess [23:15:56 CET] <MapMan> I did not build ffmpeg myself, I used a binary from ffmpeg website [23:16:00 CET] <kepstin> yeah, so it looks like your input isn't actually providing frames at 60hz, and ffmpeg is duplicating frames to keep the output vfr [23:16:07 CET] <JEEB> *cfr [23:16:12 CET] <kepstin> yeah, that [23:16:18 CET] <kepstin> they're like right beside eachother ;) [23:16:30 CET] <JEEB> thanks for checking the timestamps [23:16:33 CET] <JEEB> so that's incorrect then [23:17:14 CET] <MapMan> okay, so what you're saying is ffmpeg thinks (or is fed) data at 30 fps, not 60hz as I want it to? [23:17:26 CET] <JEEB> the dshow module is feeding timestamps at 30Hz [23:17:41 CET] <JEEB> so most likely your hack isn't 100% working or so? or there's a boog in the dshow reader [23:18:01 CET] <JEEB> because while your dshow input advertises itself as 60Hz [23:18:02 CET] <kepstin> MapMan: no. The dshow device says it's gonna be providing input at 60hz, and then is providing input slower than that (2-3x longer between frames than expected) [23:18:08 CET] <JEEB> yup [23:18:22 CET] <JEEB> because the timestamps of the packets actually matter, not the advertised frame rate [23:18:38 CET] <kepstin> so you're probably just hitting performance limits with the dshow input device implementation :/ [23:18:58 CET] <kepstin> consider using OBS, which has a higher performance (desktop duplication api) implementation of full screen capture. [23:19:21 CET] <kepstin> (i have no idea how your dshow device works) [23:19:29 CET] <MapMan> (me neither) [23:20:00 CET] <JEEB> the desktop duplication API looks neat, but you really need to be non-blocking for it to work [23:20:05 CET] <JEEB> not going to fly in lavd most likely [23:20:10 CET] <MapMan> what about gdigrab? I tried it before trying dshow but it was slooooow. Like, at half my native res, with medium profile I was hitting 15-20 fps. [23:20:32 CET] <JEEB> depending on your OS the perf of that can be something between bad and better [23:20:42 CET] <MapMan> win 10 [23:20:47 CET] <JEEB> GDI is an old thing and in various versions of Windows they removed GDI hw accel etc [23:20:51 CET] <kepstin> gdigrab depends on how well your video driver implements legacy apis, yeah [23:21:00 CET] <kepstin> it's better in win10 than win7, actually :/ [23:21:01 CET] <doyouhas> it is in the path [23:21:24 CET] <kepstin> (gdigrab is actually pretty fast in wine on X11, fwiw) [23:21:36 CET] <JEEB> xD [23:21:45 CET] <furq> what is this, opengl on amd [23:22:03 CET] <MapMan> Ok, for sanity, I'm gonna reboot, brb [23:22:13 CET] <kepstin> I was developing gdigrab in wine, and was surprised when i tested it on win7 intel drivers and it was ridiculously slow [23:22:59 CET] <JEEB> I wonder if for a nice experience for screen capture you have to basically spawn another thread with a growing buffer from which the frames are then fed when requested by lavf/lavd [23:23:08 CET] <JEEB> and then if possible provide them as d3d11 textures [23:23:36 CET] <JEEB> but yea, OBS has it already pretty optimized IIRC :P [23:23:47 CET] <MapMan> back [23:24:00 CET] <MapMan> Let me try a few things again after reboot [23:24:10 CET] <MapMan> and then I'll tell you all about the walls I've been hitting in OBS :P [23:24:32 CET] <JEEB> note: I have only used OBS once, to test nvidia lossless encoding [23:24:44 CET] <MapMan> lossless encoding is exactly what I want to do [23:24:54 CET] <kepstin> important in obs to use the full screen capture so you get dd api, i think the window capture uses a different path (maybe even gdi?) [23:25:05 CET] <MapMan> I had mixed results and ultimately decided to try just ffmpeg [23:25:18 CET] <JEEB> also I would love to basically hack RGB encoding into nvidia's encoding since it supports 4:4:4 already [23:25:26 CET] <JEEB> you would just have to use the bit stream filter to rewrite the headers :P [23:25:43 CET] <MapMan> kepstin: possible! I had similar slow-as-hell experience in some cases in OBS, I was thinking they could be using gdi [23:25:48 CET] <JEEB> "no this is not BT.601 4:4:4, it's totally BGRP" [23:26:41 CET] <kepstin> last I looked, the screencapture methods in browser webrtc screenshare in chrome and firefox are also using gdi [23:27:14 CET] <TheAMM> JEEB: >non-blocking [23:27:20 CET] <TheAMM> Doesn't gdigrab block? [23:27:38 CET] <kepstin> gdigrab blocks, yes; it does frame timing by sleeping in the input device [23:27:51 CET] <TheAMM> Yep, I've looked at it real close [23:27:59 CET] <kepstin> (said timing code was basically copied from x11grab) [23:28:12 CET] <JEEB> TheAMM: the idea was not to do it the usual way IFF such a module would be made :P [23:28:22 CET] <kepstin> with desktop duplication, rather than polling, don't you get updates pushed to you? [23:28:24 CET] <TheAMM> I'm still open for suggestions regarding the output duplication device api [23:28:27 CET] <JEEB> kepstin: yes [23:28:33 CET] <TheAMM> Hmh? [23:28:38 CET] <TheAMM> No, you have to ask for updates [23:28:41 CET] <JEEB> oh [23:28:43 CET] <JEEB> m'kay [23:28:45 CET] <TheAMM> And then are given dirty rects, if any [23:28:56 CET] <TheAMM> Mouse position, cursor icons, etc [23:28:58 CET] <JEEB> virtualdub's blog sounded a bit different but if you've actually looked at the API you know better :) [23:29:06 CET] <TheAMM> I've implemented it [23:29:18 CET] <JEEB> cool [23:29:18 CET] <kepstin> so you basically go and 60 times a second ask "what are the changes since the last time i checked?" ? [23:29:21 CET] <MapMan> Could my problem be caused by the fact that I'm running a game in fullscreen windowed mode? Shouldn't matter right, I'm recording entire screen anyway (with all the windows and stuff on top) [23:29:26 CET] <TheAMM> I've been trying to come up with a better name than mondup [23:29:35 CET] <TheAMM> Because I started with that without thinking about a name [23:29:44 CET] <kepstin> I like 'windowsddapigrabusethisnotgdi' [23:29:53 CET] <JEEB> lol [23:29:53 CET] <TheAMM> And I've been considering using rtbufsize, but 1080p RGBA gets real fat fast [23:30:08 CET] <TheAMM> The name should be short and sweet but also descriptive [23:30:13 CET] <TheAMM> out_dup is too vague, though [23:30:53 CET] <kepstin> i'd just call it 'ddapigrab' [23:31:33 CET] <TheAMM> I guess [23:31:41 CET] <kepstin> all of the existing screen grab drivers are named <name of api, shortened>grab [23:31:43 CET] <kepstin> so :/ [23:32:08 CET] <TheAMM> Works for me, then [23:32:19 CET] <JEEB> ddapi(_)rec nîn [23:32:20 CET] <MapMan> Okay, everything is same as before reboot. Looks like I'm back to square 1 with ffmpeg and gdigrab/dshow [23:32:24 CET] <TheAMM> I'll go over it and see if there isn't anything horribly awkward [23:32:36 CET] <TheAMM> Then get to experience the m a i l i n g l i s t [23:32:41 CET] <JEEB> xD [23:32:48 CET] <kepstin> always fun. [23:32:54 CET] <durandal_1707> lies. [23:33:09 CET] <kepstin> that reminds me, I should probably help review that gdigrab highdpi patch that's hanging out there [23:33:14 CET] <kepstin> or was hanging out there last I looked [23:33:22 CET] <JEEB> yea, it's still there I think [23:35:18 CET] <MapMan> JEEB: how was your experience with OBS and lossless? I wanted to use nvenc (h264 or hevc?) to record lossless at 60hz [23:35:52 CET] <kepstin> TheAMM: did you get it working so it produced hardware surfaces that could be sent directly to e.g. nvenc? [23:35:56 CET] <MapMan> I was reaching 60fps no problem but the color profile was poor (yuv420 or something?) [23:36:09 CET] <TheAMM> kepstin: no [23:36:12 CET] <MapMan> when switching to RGB I was getting 10fps for a change [23:36:18 CET] <TheAMM> If you have any examples on how to do that, I can look into it [23:36:21 CET] Action: kepstin still finds it hilarious that the easiest way to get gdigrab to work was to have it make bmp images, which were then decoded by the bmp decoder [23:36:36 CET] <TheAMM> But I only thought about that a week or so ago [23:36:52 CET] <kepstin> TheAMM: i've never worked with that stuff before, so i can't really help :/ [23:36:57 CET] <TheAMM> Ye [23:37:11 CET] <TheAMM> It's "fast enough" for now, imo [23:37:28 CET] <TheAMM> My FX wasn't able to do 1080@60, but nvenc was [23:37:35 CET] <kepstin> in theory gdigrab should work when you're running in 256color paletted mode, but I never actually tested that :) [23:37:40 CET] <TheAMM> Problem with nvenc is that it takes a moment to warm up, and ffmpeg probes the first frame [23:38:02 CET] <TheAMM> So the first frame is stuck for a fraction of a second [23:38:05 CET] <kepstin> right, the general issue with ffmpeg.c being singlethreaded [23:38:10 CET] <TheAMM> As there's no internal buffer (threading) [23:38:27 CET] <TheAMM> Which is why I considered the buffer but it's way too fat for too little gain [00:00:00 CET] --- Tue Feb 12 2019

1 0

ffmpeg-devel.log.20190210
by burek 11 Feb '19

11 Feb '19

[01:00:23 CET] <BtbN> So OBS completely duplicated another nvenc encoder, just to be able to pass in d3d11 textures. [01:00:33 CET] <BtbN> Guess it's not very clear that's possible to do with libavcodec [01:03:23 CET] <JEEB> yea [01:04:21 CET] <BtbN> Though passing in already existing textures actually is very hard, as they pretty much HAVE to be allocated by a hw_frames_ctx [01:04:31 CET] <BtbN> So you need to setup a fake one [01:05:03 CET] <BtbN> not sure how that works on the d3d11 end though [01:05:14 CET] <JEEB> also funky, ARIB strings mostly start with 0xe (14) and 0xf (15) so in theory this new conversion in mpegts.c should leave them alone. Except it doesn't for this one sample's mobile program. [01:07:13 CET] <JEEB> https://kuroko.fushizen.eu/samples/nhk_linux_sample.ts [01:08:10 CET] <JEEB> the initial byte seems to get cut off from the mobile one. wonder if I'll just have to make a separate mode for ARIB demuxing mode [01:09:11 CET] <JEEB> as in, an explicit if (mode == MPEGTS_MODE_ARIB) else current_code [02:58:01 CET] <cone-296> ffmpeg 03Jan Ekström 07master:100bfac6d6ec: add libaribb24 ARIB STD-B24 caption decoder [02:58:01 CET] <cone-296> ffmpeg 03Jan Ekström 07master:a03885b745be: lavf/mpegts: add reading of ARIB data coding descriptor [02:58:11 CET] <JEEB> there [02:58:21 CET] <JEEB> I waited 48h and there were no further objections [02:58:28 CET] <JEEB> (carl's was non-blocking) [03:17:09 CET] <agrecascino> i made a new patch [07:46:31 CET] <cone-632> ffmpeg 03Steven Liu 07master:9ec1f7634a62: avformat/hlsenc: fix fmp4_init_filename file name with %v problem [07:47:53 CET] <cone-632> ffmpeg 03Reto Kromer 07master:d20902fd2399: doc/filters: fix typos [12:41:23 CET] <j-b> durandal_1707: do you support IMM5? [12:42:26 CET] <durandal_1707> j-b: i had some WIP patch, but gave up to work on that crap codec [12:43:44 CET] <j-b> ok [12:43:52 CET] <j-b> Too hard? Too weird? [12:46:25 CET] <durandal_1707> j-b: it just shortens some NALs by hardcoding them into some funky codes. It is ripped H264. [12:46:54 CET] <j-b> So much not supririnsg [13:19:04 CET] <durandal_1707> ac4_toc() done, now remain hard part - actual parsing of audio data [16:44:50 CET] <cone-829> ffmpeg 03Moritz Barsnick 07master:885a80d18969: doc: fix various typos [16:47:10 CET] <cone-829> ffmpeg 03Reto Kromer 07master:21858b060fd9: doc/snow: fix typos [17:57:02 CET] <cone-829> ffmpeg 03Carl Eugen Hoyos 07master:826cc58debfe: lavf/img2dec: Split img2 and img2pipe options. [18:56:37 CET] <tmm1> can decoders set metadata or is sidedata the only way to return non-packet data [18:58:29 CET] <JEEB> I thought AVFrames could have metadata? or was that AVPacket-only? [18:58:38 CET] <cone-829> ffmpeg 03Carl Eugen Hoyos 07master:6de396c2168e: lavf/img2: Move "loop" into common options. [19:00:22 CET] <durandal_1707> AVFrame metadata is AVDictionary [19:02:07 CET] <tmm1> i'm trying to figure out what to do with ATSC XDS data like program name and rating [19:03:00 CET] <tmm1> unfortunately its part of a53cc so i can only decode it inside ccaption_dec which returns subtitle frames [19:06:36 CET] <JEEB> right [19:06:38 CET] <JEEB> AVSubtitle [19:07:07 CET] <durandal_1707> that is still not converted to AVFrame [19:07:42 CET] <JEEB> yea, there's been some work done on that but it's not yet done [19:08:15 CET] <tmm1> okay i see, i assumed it was the same as audio/video [19:10:12 CET] <JEEB> talking of subtitles, I need to fix ASS encoder/muxer to handle multiple lines in AVSubtitle [19:10:29 CET] <JEEB> implementing that in ARIB captions for positioning made me realize it was all borked [19:14:21 CET] <tmm1> so AVSubtitle doesnt even have sidedata or metadata [19:14:32 CET] <JEEB> yes, it's very much older and different [19:14:48 CET] <JEEB> sounds like you want to co-operate with ubitux [19:14:55 CET] <JEEB> he was the one doing the AVFrame conversion [19:30:33 CET] <tmm1> well there might not even be subtitles so trying to attach video stream metadata to the subtitle stream doesnt make much sense [19:32:38 CET] <JEEB> yes, these things relate to the AVProgram so it's all a problem of how things are set up [19:34:21 CET] <tmm1> ah right, thats where all the dvb details end up too [19:40:17 CET] <tmm1> i thought i had seen some dvb samples where ffmpeg pulled out the channel/program name, but i can't find them now [19:42:27 CET] <JEEB> channel/provider yes [19:44:02 CET] <tmm1> how does ffmpeg -i display it? [19:44:58 CET] <JEEB> ffprobe -v verbose https://kuroko.fushizen.eu/samples/tbs_sample.ts [19:45:03 CET] <JEEB> try that [19:45:21 CET] <JEEB> will not show the stuff correctly but yunno - it's something [19:56:19 CET] <durandal_1707> we should forbid travelers on behalf of FFmpeg project, they are doing nothing [19:57:09 CET] <durandal_1707> self promotion usually only happens [20:07:58 CET] <JEEB> man, on macs it becomes really evident that git's bash completion is something you want to have [20:08:33 CET] Action: JEEB adds getting the bash completion script from git's release into his macOS setup steps [20:08:49 CET] <durandal_1707> why you do not use shortcut/aliases ? [20:09:08 CET] <JEEB> that's not the same [20:09:16 CET] <JEEB> of course it adds auto-completion for commands [20:09:23 CET] <JEEB> but it also autocompletes branches and remotes [20:09:28 CET] <JEEB> as well as other things [20:09:30 CET] <JEEB> it's just useful [20:09:40 CET] <JEEB> and options [20:37:34 CET] <tmm1> thanks, looks like its inside AVProgram.metadata [20:38:18 CET] <tmm1> that's a good place for channel/provider, but not necessarily program name/info which can change without the mpegts program id changing [20:38:56 CET] <JEEB> let me see how that one anonymous guy implemented that [20:39:16 CET] <JEEB> now that I got ARIB caption demuxing in I'm going to attempt to bring his lavc decoder in for the format [20:41:05 CET] <JEEB> https://github.com/0p1pp1/FFmpeg/commit/b230101325dacf8baa62f3d6da48f9aeb86… [20:41:12 CET] <JEEB> https://github.com/0p1pp1/FFmpeg/commit/29ec522896eb716adba333dcd49f9decd9d… [20:41:20 CET] <JEEB> so that's how he seems to be doing it [20:42:14 CET] <tmm1> yea probably the most reasonable approach [20:43:03 CET] <JEEB> I'm really sad this guy never contacted upstream [20:43:08 CET] <JEEB> he seems to have a lot of interesting stuff [20:43:30 CET] <tmm1> can i get to AVProgram* from inside a decoder? [20:43:49 CET] <JEEB> right, that's the problem for you [20:44:05 CET] <JEEB> so you have to start putting decoders within the demuxing or application layer [20:44:46 CET] <tmm1> yep. maybe a better approach is to write it as a bsf and pull out into pkt side data [20:47:11 CET] <tmm1> even though it really should be a decoder [20:48:03 CET] <JEEB> the problem with these things is that broadcast likes to mish-mash abstraction layers [20:48:07 CET] <JEEB> put X into Y etc [20:53:04 CET] <tmm1> scte35 uses a new stream of AVMEDIA_TYPE_DATA, i could maybe do that and return each parsed XDS packet with its decoded contents attached as metadata [21:14:17 CET] <jamrial> jkqxz: check the patch i just sent if you can [21:19:49 CET] <jkqxz> Maybe that check should be moved out to the caller instead? [21:22:56 CET] <jkqxz> The spec requires that nbBits is greater than zero in trailing_bits, so avoiding doing it seems better than relaxing the check inside the function. [21:24:48 CET] <jamrial> alright [21:28:24 CET] <agrecascino> can someone tell me how appalling my patch is [21:28:45 CET] <jamrial> jkqxz: something like https://pastebin.com/raw/0jkfjMnu ? [21:28:58 CET] <durandal_1707> agrecascino: link to the patch? [21:29:15 CET] <agrecascino> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-February/239944.html [21:29:26 CET] <agrecascino> nobody responded to my rfc asking how to do this better [21:29:43 CET] <agrecascino> so i just did it to hopefully get people to yell at me how to do it right [21:33:05 CET] <jkqxz> jamrial: Yeah. [21:35:47 CET] <durandal_1707> agrecascino: i have no idea, wait several days, ping it weekly and request somebody to push it if nobody replies [21:36:18 CET] <JEEB> agrecascino: regarding teh counting - did the spec note that this should work? [21:43:58 CET] <cone-829> ffmpeg 03James Almer 07master:3e8b8b6b509c: avcodec/cbs_av1: don't call cbs_av1_read_trailing_bits() when no bits remain in the OBU [21:45:07 CET] <jamrial> jkqxz: done, thanks [21:48:46 CET] <jamrial> jkqxz: there's also the issue of the parsing code for mastering display metadata checking for a range of values that don't really apply [21:48:58 CET] <jamrial> they are not stored the same way as in hevc sei messages [22:00:26 CET] <jkqxz> Hmm, right, yeah. They use the whole range in the obvious way rather than a funny unit. [22:18:14 CET] <kierank> ¬1350, wow that's not a cheap flight [22:18:35 CET] <durandal_1707> not economy class [22:28:24 CET] <kierank> could be last minute [22:45:46 CET] <agrecascino> JEEB, the spec says absolutely nothing? [22:46:01 CET] <JEEB> wee [22:46:28 CET] <agrecascino> idk it's been a little while but there was nothing in there that would help with implementation [23:46:10 CET] <agrecascino> tbh someone is fixing the hang so [23:46:19 CET] <agrecascino> who needs one more sidx :^))))))))) [00:00:00 CET] --- Mon Feb 11 2019

1 0

ffmpeg.log.20190210
by burek 11 Feb '19

11 Feb '19

[00:00:03 CET] <JEEB> I did tell you didn't I? the VO probably didn't support 4:2:2 yet the module took it in [00:00:14 CET] <shibboleth> mhm [00:01:22 CET] <shibboleth> Movie-Aspect is 1.33:1 - prescaling to correct movie aspect. [00:01:24 CET] <shibboleth> VO: [gl] 640x360 => 640x480 Planar 422P [00:01:26 CET] <shibboleth> Movie-Aspect is 1.33:1 - prescaling to correct movie aspect. [00:01:28 CET] <shibboleth> VO: [gl] 640x360 => 640x480 Planar 422P [00:01:46 CET] <JEEB> yes, after you switch to gl it can take it in [00:02:05 CET] <fructose> So this will show where key frames are, right? ffprobe -loglevel error -skip_frame nokey -select_streams v:0 -show_entries frame=pkt_pts_time -of csv=print_section=0 [00:02:24 CET] <JEEB> anyways, no idea about mplayer but since one had vdpau and the other didn't that seemed like the clearest thing [00:03:41 CET] <JEEB> fructose: I think you just want pts for the AVFrames, and if you're OK with AVPackets then you should look at the AVPacket's pts/dts (pts is what you want) [00:08:03 CET] <fructose> JEEB: So is there another command you'd recommend instead? This channel is for users, not developers, right? [00:09:08 CET] <JEEB> yes [00:17:45 CET] <shibboleth> speaking of key frame/iframes [00:18:09 CET] <shibboleth> suggestions as to a golden rule when setting up sources such as sec cams? [00:20:21 CET] <fructose> One version of that rule is: "Treat your inferior as you would wish your superior to treat you." [00:21:42 CET] <fructose> You know like, avoid requiring a user to know the intimate details of a C struct in order to get help [00:22:20 CET] <JEEB> yes, you could just forget I mentioned the structs [00:22:41 CET] <JEEB> ffprobe has -show_packets (demuxer level) and -show_frames (decoding level) [00:23:13 CET] <JEEB> and you specifically noted pkt_pts_time , and thus I noted that you probably want to use pts or pts_time values from ffprobe [00:23:27 CET] <JEEB> getting the packet pts from a decoded frame just doesn't make too much sense to me [00:23:46 CET] <JEEB> unless show_entries frame=XXX does something completely different than what I'd guess [00:24:40 CET] <fructose> Thanks, I'll see if I can decypher that. [00:24:41 CET] <JEEB> and so far I think I'm treating people rather well, no? the only thing at times is that I can't give specifics right out of the store bookshelf because I don't remember all things exactly in my mind :P [00:25:33 CET] <fructose> JEEB: Text can be ambiguous, no worries on my end. [00:47:13 CET] <Kray> € [05:35:44 CET] <cryptodechange> https://stackoverflow.com/a/30832903 [05:36:08 CET] <cryptodechange> How would I adapt that to make a 4:3 video to 16:9 with the blurred sides? [06:34:33 CET] <cryptodechange> If a video's aspect ratio does not match the native resolution, does that simply mean that the media player is stretching the video to match? [06:43:56 CET] <Fenrirthviti> cryptodechange: depends on the video player. [07:09:40 CET] <mfwitten> cryptodechange: Did you figure it out? [07:23:49 CET] <cryptodechange> using mpv [07:25:12 CET] <cryptodechange> It's 720:480 with an 4:3 aspect ratio but mpv resizes it to 720x540 [07:26:03 CET] <furq> any video player that doesn't stretch to match sar/dar is broken [07:27:13 CET] <cryptodechange> Is it better that it upscales it to 540p instead of downscaling the width? [07:27:36 CET] <furq> probably [07:27:40 CET] <furq> otherwise you'd lose horizontal information [07:28:15 CET] <cryptodechange> I'm converting some 4:3 DVD content with a blurred background in the place of the black pillars [07:28:31 CET] <cryptodechange> as I want to watch 4:3 content on my OLED without burning in [07:49:31 CET] <furq> cryptodechange: "split[fg][bg];[bg]eq=contrast=0.4:brightness=-0.4:saturation=0.4,scale=w=if(gt(dar\,16/9)\,iw\,ih*16/9):h=i f(gt(dar\,16/9)\,iw/(16/9)\,ih):flags=bicubic,boxblur=8:8[bgout];[bgout][fg]overlay=x=(W-w)/2:y=(H-h)/2" [07:49:38 CET] <furq> should work with any aspect ratio [08:05:47 CET] <cryptodechange> nice thanks [08:06:25 CET] <cryptodechange> trying to remember the detelecine stuff, fieldmatch,decimate still shows as having interlaced frames [08:06:35 CET] <cryptodechange> every couple hundred frames [08:07:43 CET] <cryptodechange> furq: that chain comes up with the error 'width not divisible by 2 (853x480)' [12:03:47 CET] <sn00ker> hi all [12:03:48 CET] <sn00ker> https://stackoverflow.com/questions/54404097/ffmpeg-v4l-snd-aloop-sound-asy… [17:06:37 CET] <JEEB> what's the dumbest dedup filter in lavfi? [17:07:00 CET] <durandal_1707> dedup? [17:07:13 CET] <JEEB> huh, why did I not notice that in ffmpeg-filters.html [17:07:26 CET] <JEEB> yea, ctrl+F dedup there brings up nothing [17:07:30 CET] <JEEB> but if that's true, great [17:07:33 CET] <durandal_1707> define dedup [17:07:50 CET] <JEEB> drop frames if they are exactly the same as the previous one [17:07:58 CET] <JEEB> it can be dumb as a lamb [17:08:23 CET] <durandal_1707> they are smart, mpdecimate and decimate [17:08:33 CET] <JEEB> yes, decimate needs a pattern [17:08:37 CET] <JEEB> if I understand correctly [17:08:42 CET] <JEEB> and there's no pattern here [17:08:46 CET] <JEEB> so for context [17:09:06 CET] <JEEB> a friend asked me how to output DVD/BD subtitles as PNGs [17:09:55 CET] <JEEB> -i SUBTITLES -f lavfi -i "color=c=black:s=1920x1080:r=24000/1001" -filter_complex "[1:v][0:s:0]overlay[le_out]" -map "[le_out]" [17:09:59 CET] <JEEB> this is what I'm at right now [17:10:03 CET] <JEEB> 24/1.001 for sync [17:10:24 CET] <JEEB> then I just want to blindly dedup [17:10:34 CET] <JEEB> because duplicated frames will be exact dupes [17:10:37 CET] <JEEB> vOv [17:10:40 CET] <JEEB> lemme see mpdecimate [17:11:08 CET] <JEEB> mpdecimate=max=0 I think [17:12:53 CET] Action: durandal_1707 tries to dechipher hi/lo/frac [17:59:47 CET] <Zexaron> I can't find changes for 4.1 [17:59:56 CET] <Zexaron> release notes [18:01:21 CET] <Zexaron> ah here it is [18:03:17 CET] <JEEB> I usually check it from the repo personally. although I think the site should also get updated [18:15:15 CET] <cc0> hello, is there a way to print all encoder flags values used when encoding a file? [18:17:52 CET] <furq> depends on the encoder [18:17:56 CET] <furq> libx264 will do that automatically [18:22:12 CET] <keegans> I have an .mp4 container file that contains AAC samples, I'd like to read sample by sample, decode, and then play it out. How should I get started with this? [18:22:32 CET] <JEEB> see the transcoding example under doc/examples [18:22:44 CET] <JEEB> playing is a separate thing of course since you have to output the audio somehow [18:23:01 CET] <JEEB> but demuxing, decoding and filtering is achievable [18:23:17 CET] <JEEB> filtering for example to get the planar floating point samples of lossy formats into, say, 16bit int [18:23:30 CET] <JEEB> (and packed because many audio output things don't support that) [18:23:40 CET] <JEEB> that meaning planar actually [18:23:42 CET] <JEEB> sorry for that wording [18:23:53 CET] <keegans> ah, I'll look at the examples, thanks [18:24:02 CET] <keegans> it's audio-only thought, so is demuxing necessary [18:24:06 CET] <JEEB> yes [18:24:08 CET] <keegans> *though [18:24:11 CET] <JEEB> that gets the samples from the mp4 [18:24:29 CET] <keegans> ok, i'll read up on that [18:24:40 CET] <JEEB> basically you create/open an AVFormatContext which starts up the parser [18:24:54 CET] <JEEB> then there's the BestNamedFunctionEver which is "read_frame" [18:25:00 CET] <JEEB> (even though it returns AVPackets) [18:25:11 CET] <JEEB> I did not name it, but I'm still sorry for the name [18:25:40 CET] <keegans> :D [18:25:53 CET] <JEEB> then with each packet you can see which AVStream it came from. depending on the input format you may or may not have the full list of streams from the beginning [18:26:02 CET] <JEEB> and then in your code you either process or don't or whatever [18:26:06 CET] <JEEB> this stuff is really generic [18:26:23 CET] <JEEB> then the AVStream also has the AVCodecID [18:26:26 CET] <JEEB> of the stream [18:26:34 CET] <JEEB> through which you can then initialize an AVCodecContext [18:26:48 CET] <JEEB> and start feeding AVPackets to the decoder [18:27:06 CET] <JEEB> the newer decoding/encoding APIs are pretty well documented https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [18:27:44 CET] <JEEB> but yea, after this you are at the point where you're getting decoded AVFrames from a decoder [18:27:58 CET] <JEEB> with their timestamps and durations and sample counts [18:28:11 CET] <JEEB> and the world's your oyster [18:28:44 CET] <JEEB> you can then utilize libavfilter or libswresample (latter of which libavfilter utilizes) to do any format conversions you require [18:28:59 CET] <keegans> awesome! I am new to audio, so excuse me if this is an obvious question -- but the decoded frames are in what format? [18:29:10 CET] <keegans> as in, when I get the decoded frames I'd like to play those in SDL for example [18:29:13 CET] <JEEB> that 100% depends on the decoder [18:29:25 CET] <JEEB> lossy formats generally give you floating point [18:29:38 CET] <JEEB> the AVFrame has the actual data on what you received [18:29:56 CET] <JEEB> so you can decide "if it's not XYZ that I need, I do conversion with swresample/libavfilter" [18:30:29 CET] <JEEB> and it's generally planar, as I noted. as opposed to packed [18:30:52 CET] <JEEB> but once again, that info is available in the AVFrames coming from the decoder [18:31:02 CET] <JEEB> also the format can change [18:32:03 CET] <keegans> ah I see, the formats are specified here for SDL: https://wiki.libsdl.org/SDL_AudioSpec [18:32:10 CET] <keegans> so my goal is to get it in one of those formats I guess [18:32:34 CET] <keegans> the frequency, channel, samples, etc. I can read from the mp4 using libavcodec [18:33:04 CET] <JEEB> https://ffmpeg.org/doxygen/trunk/structAVFrame.html [18:33:34 CET] <JEEB> but at least libavfilter seems to be able to handle format changes on the input side. for example if your audio stream decides to switch from stereo to 5.1 and back [18:33:44 CET] <JEEB> not sure if swresample specifically by itself supports that [18:33:56 CET] <JEEB> it does have an AVFrame based API so it'd be possible to implement at least [18:34:20 CET] <cc0> furq: i'm using libxvid [18:38:24 CET] <keegans> what is the purpose of filters, or where can I read up on them [18:38:51 CET] <keegans> I am just reading the decoding process so I only need to demux then stream because I don't need to re-encode but it says you may filter after you demux [18:39:28 CET] <JEEB> well if you need to play you can't exactly feed your audio output coded audio packets, no? [18:39:31 CET] <JEEB> so decoding is needed [18:39:33 CET] <JEEB> not only demuxing [18:39:42 CET] <keegans> I understand the decoding, not the purpose of filtering [18:39:45 CET] <JEEB> ok [18:40:00 CET] <JEEB> filtering is when what you receive from input does not fit any hole on the other side [18:40:24 CET] <JEEB> as in, when you have a use case and you need the stuff to be X [18:40:41 CET] <JEEB> like, if you need your audio to be stereo, 16bit, 48000Hz, packed [18:40:56 CET] <JEEB> and you get 5.1, float, 32bit, 44100Hz, planar [18:41:01 CET] <JEEB> from the decoder :P [18:41:21 CET] <keegans> what are those properties called [18:41:43 CET] <keegans> that wasn't a very good phrasing of the question lol [18:41:55 CET] <keegans> i mean like what is the packed or planar property called [18:42:26 CET] <JEEB> AVFrame->format (AVSampleFormat) [18:42:38 CET] <keegans> awesome thanks [18:42:50 CET] <keegans> ok i get the purpose filtering now too, thank you [18:42:57 CET] <keegans> lots for me to learn :D [18:43:15 CET] <JEEB> also nb_extended_buf [18:43:26 CET] <JEEB> which is then the exact amount of planes you got in the AVFrame [18:43:52 CET] <JEEB> then channel_layout is basically the layout (stereo, 5.1 ec) [18:44:10 CET] <JEEB> since for the same amount of channels you can have different things [18:44:14 CET] <JEEB> 3.0, 2.1 etc for example [18:44:48 CET] <JEEB> which is why generally you trust channel_layout more than the channel count :) [18:45:10 CET] <JEEB> if channel_layout is not set then you have a function to help you guess the layout from the channel coun [18:45:12 CET] <JEEB> *count [18:46:00 CET] <JEEB> and yea, AVFrame also has sample_rate [19:36:02 CET] <keegans> I am getting a segfault on av_log? [19:36:21 CET] <keegans> I just run `avformat_open_input` [19:38:07 CET] <JEEB> post some code on pastebin or something, and then link here [19:39:58 CET] <keegans> https://pastebin.com/2vTwJHp7 [19:40:34 CET] <keegans> i guess i need to initialize something? [19:40:38 CET] <keegans> seems strange [19:41:18 CET] <JEEB> don't remember if av_register_all() is any more needed [19:41:49 CET] <JEEB> also oyu need to allocate the AVFormatContext first I think? [19:41:55 CET] <JEEB> avformat_alloc_context() [19:42:27 CET] <keegans> ah i am dumb [19:42:33 CET] <keegans> apologies, now it works [19:42:40 CET] <JEEB> np [19:42:59 CET] <JEEB> also I recommend dealing with a copy of FFmpeg with debug symbols while developing [20:14:23 CET] <keegans> JEEB: ok awesome so I now have a loop which reads all AVPacket from the file -- I am kind of lost now, though. If I want to convert these frames to a `.wav`, what should be next steps be? [20:14:35 CET] <keegans> I am reading through the transcoder example file but got a little lost [20:15:00 CET] <keegans> I believe I want to decode them to wav then repackage them into a new AVFormat context I create? [20:15:12 CET] <keegans> oh and i have to mux them too [20:17:01 CET] <JEEB> keegans: the first thing you do is handle stream selection. how you exactly do this depends on what you expect your input to be and how much configurability you want to add [20:17:18 CET] <keegans> it seems I only have one stream [20:17:23 CET] <JEEB> in this example, yes [20:17:46 CET] <keegans> it what cases would I have more than one? [20:18:05 CET] <JEEB> normal a+v stream, files with multiple a/v/s streams? [20:18:28 CET] <JEEB> also broadcast can have the program index update and thus you gain/lose streams dynamically [20:18:36 CET] <keegans> I won't ever get a+v, this is only for audio [20:19:09 CET] <keegans> for now I dont believe I will ever encounter more than one stream, I will just make it error out if I do [20:19:56 CET] <JEEB> anyways, in this initial state you can just pick/hard-code the stream index you get from the AVPacket [20:20:24 CET] <JEEB> then as you receive AVPackets you can check the AVFormatContext for what the stream actually is (in this case, AAC) [20:21:28 CET] <JEEB> basically you can make a function for decoder initialization that takes in AVCodec and AVCodecParameters pointers [20:22:03 CET] <JEEB> 1) avcodec_alloc_contextX (newest) with the AVCodec pointer [20:22:18 CET] <JEEB> 2) if you set the parameters, pass them on with avcodec_parameters_to_context [20:22:26 CET] <JEEB> 3) avcodec_open2 [20:22:31 CET] <JEEB> bam, you have a decoder context ;) [20:22:46 CET] <keegans> awesome [20:23:06 CET] <keegans> https://pastebin.com/6bnsxtaQ [20:23:18 CET] <keegans> ignore the shitty error handling i am just doing this for testing [20:23:25 CET] <keegans> and i will flesh it out better when i can get it working [20:23:35 CET] <JEEB> yup [20:23:58 CET] <JEEB> so yea, at that point you have a decoder available to which you can feed AVPackets and attempt to receive AVFrames [20:24:03 CET] <JEEB> according to https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [20:24:25 CET] <keegans> avcodec_send_packet() is what i want [20:24:41 CET] <keegans> then I just call receive_frame in a loop it seems [20:24:57 CET] <keegans> nice nice [20:25:00 CET] <keegans> ok let me try to do it now :p [20:27:59 CET] <JEEB> also lol [20:28:11 CET] <JEEB> I look at my own local test thing I coded up a year or two ago [20:28:18 CET] <JEEB> and I so much hated the "read_frame" thing [20:28:30 CET] <JEEB> I ended up writing a really thin wrapper called read_packet_from_input() [20:29:38 CET] <JEEB> (granted, in my simple use case I also made it skip all packets that I didn't give a damn about) [20:31:01 CET] <keegans> #define read_packet_god_damn_it read_frame [20:31:14 CET] <keegans> and i managed to mess that up [20:31:34 CET] <keegans> `git blame` [20:31:43 CET] <keegans> track 'em down [20:32:41 CET] <JEEB> also I think at this point it's probably a good idea to remind you of time bases, although often audio streams are continuous and thus you can be mostly oblivious of them [20:32:56 CET] <JEEB> your AVStream will have a time base, on which the AVPackets will recide [20:33:10 CET] <JEEB> decoders and encoders also have their time bases [20:33:49 CET] <JEEB> (as in, AVFrames decoded will have pts on that time base and AVFrames fed to an encoder should be on the time base set in the encoder [20:34:01 CET] <JEEB> same goes for filter chain inputs and outputs [20:34:29 CET] <JEEB> and output AVFormatContext AVStreams of course have their own time bases [20:34:33 CET] <JEEB> just something to keep in mind [20:40:09 CET] <keegans> will do [20:40:24 CET] <keegans> i am currently having trouble understanding lifetimes in ffmpeg [20:40:35 CET] <keegans> right now i am following a "if it doesnt segfault it probably works" philosophy [20:40:42 CET] <keegans> i'll have to correct this at some point [21:20:21 CET] <ossifrage> This is somewhat off-topic but should I be able to encode an aiff file as flac and then decode it and get the same bits (including headers) [21:20:52 CET] <ossifrage> I'm using --keep-foreign-metadata but the flac->aiff file is a little smaller then the original [21:21:07 CET] <ossifrage> (20 bytes) [21:21:45 CET] <furq> probably not [21:23:13 CET] <furq> some muxers support -fflags bitexact which ensures two files muxed by ffmpeg will be identical [21:23:20 CET] <furq> but not that they'll be identical to files muxed by anything else [21:24:31 CET] <durandal_1707> decoded audio should be same [21:24:57 CET] <furq> right [21:25:01 CET] <furq> you can check that with the hash muxer [21:26:56 CET] <ossifrage> I thought I got it to work ages ago, but I don't have a clue how (or where that data went) [21:30:33 CET] <furq> are they both big endian [22:03:36 CET] <ossifrage> It looks like there is one missing tag 'CodecID', it is in the original files and missing from the flac generated ones [22:03:47 CET] <ossifrage> the original files have it set to 'NONE' [22:05:10 CET] <furq> yeah that's aiff-c [22:05:19 CET] <furq> afaik the ffmpeg aiff muxer only does regular aiff [22:06:44 CET] <ossifrage> ah, yeah my test case came from old aiff files, not the really old ones, so maybe it will work for the 'really old ones'... [22:07:18 CET] <furq> only regular aiff for big endian, i mean [22:08:41 CET] <furq> i just tested with little and big endian and the little endian file is 18 bytes larger [22:08:46 CET] <furq> so presumably that's just the COMM chunk [22:12:20 CET] <ossifrage> Hmm, the ones from 2001 also have the 20 byte difference. [22:12:38 CET] <furq> `file` will tell you if it's aiff or aiff-c [22:12:44 CET] <furq> aiff-c is from the early 90s [22:13:05 CET] <ossifrage> IFF data, AIFF-C compressed audio [22:14:00 CET] <ossifrage> Some of the files might have been ripped on an old SGI O2 that I used to use as a media server [22:40:24 CET] <keegans> JEEB: do I have to worry about this : https://stackoverflow.com/questions/22822515/ffmpeg-resampling-from-av-samp… [22:40:36 CET] <keegans> the audio file i have is fltp as well [22:40:44 CET] <keegans> and i wish to convert to s16le [22:41:14 CET] <JEEB> that's why you need to swresample or libavfilter it [22:41:18 CET] <JEEB> which I mentioned [22:41:28 CET] <JEEB> so if you need packed from planar, or just float to int [22:41:47 CET] <JEEB> it sounds like crap if you do only one of those conversions if you need both, or none [22:56:03 CET] <keegans> ok so i just destroyed my ears [22:56:06 CET] <keegans> on the first attempt [22:57:07 CET] <JEEB> which way did you attempt? [22:57:10 CET] <JEEB> swresample or lavfi? [22:57:28 CET] <keegans> swresample [22:57:31 CET] <JEEB> ah [22:57:38 CET] <JEEB> yea, that one I haven't utilized to be 100% honest [22:57:43 CET] <JEEB> but it does have an AVFrame based API [22:57:49 CET] <keegans> yeah [22:57:49 CET] <JEEB> so I would hope you can do it [22:58:07 CET] <JEEB> (the thing originally had a non-AVFrame based API and then people yelled) [22:58:09 CET] <keegans> well i'll keep at it and figure it out eventually lol [22:59:35 CET] <JEEB> you can probably peek at af_resample or so, which is the filter that does the resampling in lavfi (using swresample) [23:00:35 CET] <JEEB> wait what :D [23:00:40 CET] <JEEB> it's using avresample? [23:00:43 CET] <JEEB> I don't even [23:01:28 CET] <JEEB> keegans: there seems to be an example in the examples dir, too [23:01:34 CET] <JEEB> using swresample [23:01:54 CET] <keegans> yeah that is what i've been going off of [23:02:23 CET] <JEEB> and of course it's using the non-AVFrame API? [23:03:16 CET] <JEEB> I did at some point write a thing that used swresample through lavfi resampling functionality, but I don't have that around. [23:03:23 CET] <JEEB> and of course ffmpeg.c also does stuff [23:05:35 CET] <keegans> ok so [23:05:42 CET] <keegans> i guess im playing it too slow [23:05:45 CET] <keegans> i really am not sure [23:06:03 CET] <keegans> i am using SDL to try to play the decoded PCM frames [23:06:32 CET] <JEEB> dump them to file first and then compare? [23:06:43 CET] <JEEB> against the expected values in there [23:07:22 CET] <keegans> ah good idea yeah [23:07:37 CET] <JEEB> of course it will headerless raw pcm but still [23:07:51 CET] <JEEB> since I don't think the overhead of adding a muxer there right now is worth it [23:08:43 CET] <keegans> oh im smart [23:08:47 CET] <keegans> i fucked up the sample rate [23:08:52 CET] <keegans> why did i hardcode this in the first place [23:09:10 CET] <keegans> ok so now it sounds more right [23:09:56 CET] <keegans> there is a loud hum over what sounds to be the bass and such [00:00:00 CET] --- Mon Feb 11 2019

1 0

ffmpeg-devel.log.20190209
by burek 10 Feb '19

10 Feb '19

[04:08:35 CET] <philipl> BtbN: Thanks for fixing. I can't remember if a fully inline version was discussed at the time but the multiply included file was a pattern used elsewhere. I'm fine with the inline. [04:09:31 CET] <philipl> so ship it. [12:57:46 CET] <BtbN> philipl, I wasn't able to reproduct any breakage, but the symbol was exported from two libraries, and someone somehow had an issue with that. [12:58:16 CET] <BtbN> I still think it's an issue with stale build files, but it's ugly in either case. [13:04:03 CET] <JEEB> any comments on the libaribb24 patch set dear silent majority? (I hope you're happy that only my SAN points are going down) [13:07:26 CET] <durandal_1707> j-b: i started writing ac-4 decoder [13:08:26 CET] <JEEB> durandal_1707: did the samples at DASH-IF actually work btw? [13:08:43 CET] <JEEB> like, if you demux them the samples seem to make sense as based on the spec? [13:13:30 CET] <durandal_1707> JEEB: yes, they have sense, have sequence counter increasing to 1020 and than wrapping back to 1 [13:14:11 CET] <JEEB> cool [13:53:29 CET] <atomnuker> durandal_1707: did you find a binary to re or something? [14:00:02 CET] <cone-143> ffmpeg 03Carl Eugen Hoyos 07master:0cac68bcf94e: lavu/parseutils: Allow to parse >= 100 hours. [14:08:32 CET] <durandal_1707> atomnuker: there is spec [14:08:40 CET] <JEEB> yup [14:08:45 CET] <JEEB> they're pushing it for ATSC3 I think? [14:08:49 CET] <JEEB> so they had to kind of publish it [15:15:41 CET] <kierank> durandal_1707: there is binary as well [15:24:34 CET] <atomnuker> what's it like? low-overlap mdct like opus? aac-like vector quantization with lots of codebooks? [15:25:41 CET] <JEEB> the only thing I remember with AC-4 is that instead of having longer audio frames they decided to make P-frames [15:29:41 CET] <atomnuker> neat, I wonder how many muxers mark audio keyframes correctly [17:53:38 CET] <durandal_1707> kierank: binary? [18:18:15 CET] <cone-164> ffmpeg 03Michael Niedermayer 07master:4cde7e62dbaa: avcodec/sbrdsp_fixed.c: remove input value limit for sbr_sum_square_c() [18:18:15 CET] <cone-164> ffmpeg 03Michael Niedermayer 07master:dfae0e295a6c: tools/target_dec_fate.list: Extend selftests upto issue 2000 [18:27:58 CET] <kierank> durandal_1707: for ac-4 [18:34:05 CET] <cone-164> ffmpeg 03chcunningham 07release/4.1:bcc71f30adc9: avformat/mov.c: require tfhd to begin parsing trun [18:34:06 CET] <cone-164> ffmpeg 03chcunningham 07release/4.1:00cdf4e4e517: avformat/mov: validate chunk_count vs stsc_data [18:34:07 CET] <cone-164> ffmpeg 03Michael Niedermayer 07release/4.1:74700e50bf74: Changelog: update [20:01:55 CET] <cone-164> ffmpeg 03Reto Kromer 07master:5b32f94b97df: doc/ffprobe: fix typo and update URL in man [20:32:26 CET] <JEEB> ok, does anyone have any further comments on the libaribb24 patch set? does anyone share the issues that carl has? [20:35:30 CET] <JEEB> the lack of even technical comments after the first one I received for the demuxer is at this point kind of funny. (I'm thankful for the first reviews of course) [20:55:28 CET] <agrecascino> since nobody told me anything i just went and implemented counting [20:55:46 CET] <agrecascino> it wasn't difficult nor much code [20:55:55 CET] <agrecascino> it's just ugly and bad [21:03:13 CET] <JEEB> michaelni: /62 [21:05:04 CET] <JEEB> uhh, sorry. anyways, can you check the libaribb24 thread if you share any of the fears that carl has. [21:06:17 CET] <JEEB> I'm mostly asking because right now it looks like I'm pushing my opinion over his (mostly because people from here don't voice their opinion on it way or another) [21:06:44 CET] <JEEB> I'm really happy I did at least get some technical comments at the beginning, which I then applied changes according to :P [21:06:53 CET] <JEEB> but after that it's been silent [21:22:45 CET] <michaelni> JEEB, iam silent because i know very little about the subject and because to me it looks like noone is blocking the patch, i have not looked at the lib before and looking now i see it is less than 3k lines of code in .c which includes some generic code like md5. So from this without any deeper knowledge the question about avoiding the dependancy and implementing this internally is an obvious thought. But i dont know the [21:22:45 CET] <michaelni> details so i dont know what is better [21:24:25 CET] <JEEB> my biggest issue with taking it in currently is that it's LGPLv3 (currently). if I have to push something through the FFmpeg review process then I'd want the result to be LGPLv2.1+ [21:24:44 CET] <michaelni> yes that makes sense [21:26:11 CET] <JEEB> I did write-up a plan of implementing it internally (given the license doesn't change), but that would be a relatively long process of changing an iconv module into something in libavutil for the text encoding first, and then reviewing/rewriting an anonymous lavc decoder from a person who literally seems to have forked and made custom changes to all the surrounding projects to get it to work (libass [21:26:17 CET] <JEEB> for ASS rendering etc) [21:26:18 CET] <JEEB> yet I got no real comments on that [21:27:07 CET] <JEEB> so now it's a case of me of course wanting a clear resolution and if possible the stuff I used my free time for in. and since literally no-one voiced an opinion the only other voice in the thread is one that is against the patch (but does not block it) [21:27:14 CET] <JEEB> I don't meant that you have to voice an opinion [21:27:18 CET] <JEEB> *mean [21:27:22 CET] <JEEB> it's just irritating as hell [21:27:45 CET] <JEEB> since I've generally received positive feedback from people including those who have tested it (and some people here) [21:29:31 CET] <JEEB> and if people really don't like this patch then I would get a resolution and just separate the AVCodecID/description stuff and then just the demuxing [21:30:32 CET] <JEEB> right now I'm in a weird state where it looks like I'm pushing over without consensus even though I feel like there's a consensus (which is not necessarily positive but also isn't negative) [21:32:41 CET] <JEEB> also VLC is using that library (and it's packaged in debian!) and the author has been seen commenting on pull requests again, so while it most likely will go off onto videolan's gitlab at some point for shared maintainership, it's not dead. [21:33:25 CET] <michaelni> JEEB, you could just post to the ML a patch (if a new one is needed) and then say you will apply it in X days if noone objects [21:34:49 CET] <JEEB> I already posted something along that way and got an angry response on it. still not blocking it, of course [21:35:36 CET] <JEEB> because of course my sincerity of trying to get a consensus is being contested because literally no-one else seems to be for the patch set (looking at the responses) [21:37:23 CET] <JEEB> I hope this explains why I'm feeling frustrated [21:40:01 CET] <JEEB> and this applies to literally everyone in this community. I am not specifically aiming this towards michael. I just happened to have him highlighted while thinking if I should ask or not :P and then I accidentally /window_id [21:41:40 CET] <durandal_1707> do not be frustrated with carl [21:42:27 CET] <michaelni> JEEB, maybe you are thinking too much about this, if noone objects then noone objects, and IIUC this is only intended to be a solution until some internal solution is designed&implemented [21:42:40 CET] <JEEB> yes, it's a reference [21:47:53 CET] <JEEB> durandal_1707: seriously, the last thing I want is issues down the line. I'm trying to be a nice person to work with, and I respond to comments that are put out towards my work. but then there are cases where I disagree and then literally no-one else replies [21:48:28 CET] <JEEB> (on the mailing list of course) [21:48:50 CET] <JEEB> on IRC I did get positive responses, but as I've been scolded by quoting them on the mailing list before... [21:49:28 CET] <JEEB> and I'm not specifically frustrated with someone. I'm frustrated over the situation. [22:35:26 CET] <cone-164> ffmpeg 03Reto Kromer 07n4.1.1:HEAD: doc/ffprobe: fix typo and update URL in man [23:52:32 CET] <cone-164> ffmpeg 03Carl Eugen Hoyos 07master:5c515b5f7d64: lavf/mpegts: Convert service_name and service_provider to utf-8. [00:00:00 CET] --- Sun Feb 10 2019

1 0

ffmpeg.log.20190209
by burek 10 Feb '19

10 Feb '19

[00:05:31 CET] <shibboleth> http://178.34.230.26/liveimg.cgi?serverpush=1 [00:05:41 CET] <shibboleth> both ffplay and mplayer struggle with it [00:05:52 CET] <shibboleth> ideas, libav option flags? [01:02:00 CET] <wfbarksdale> i'm working on some code for remuxing using c api, my output mp4, when using ffprobe shows an error, AVC: nal size 0. Does anyone have an intuition about what i might be for that to occur? [01:02:45 CET] <wfbarksdale> the video stream also plays back all black [01:02:57 CET] <wfbarksdale> or rather, is probably failing to be parsed [01:05:31 CET] <wfbarksdale> I imagine i am just forgetting to set something on my output context but i can't figure out what [01:29:54 CET] <No0n3Left> When downloading an HLS video stream (m3u8) with ffmpeg, I cannot open the file while it is downloading with VLC or mpv, mpv telling me it doesnt recognise the format. If I hit Q in ffmpeg to stop the download midway, and open the files, I can play them, is there a way to be able to play them while downloading, as you could be able to while downloading most other video formats (like mp4) [01:34:35 CET] <analogical> is it possible to crop a video with FFmpeg without re-encoding the video? [01:36:29 CET] <furq> analogical: sort of [01:36:50 CET] <furq> you can change the h264 or hevc crop metadata [01:37:05 CET] <furq> https://www.ffmpeg.org/ffmpeg-bitstream-filters.html#h264_005fmetadata [01:37:32 CET] <furq> No0n3Left: save the stream to something other than mp4 [01:39:33 CET] <No0n3Left> Okay, thanks, mkv worked [01:40:26 CET] <analogical> mkv is superior to mp4 in my not so humble opinion :) [01:51:07 CET] <Skandalist> Hmmm, so nobody can tell how to change video speed accurately? Can i use something like "setpts=(1594.6/1330.3)*PTS", instead of certain number like "setpts=(1.20)*PTS" [01:51:48 CET] <furq> sure you can [01:55:52 CET] <leite> furq, you here [01:58:34 CET] <Skandalist> But I still don't get it in -vsync section: "With -map you can select from which stream the timestamps should be taken. You can leave either video or audio unchanged and sync the remaining stream(s) to the unchanged one." How is it works? Will it change duration too? [04:03:06 CET] <teamcoltra> This might just need a whole new program written but I thought I would ask here first: I have a live stream let's call it http://localhost/test.m3u8 every 5-10 minutes there is about a minute of silence. I want to loop in /home/teamcoltra/silencereplacement.mp4 while it's silent and then go back to the initial m3u8 file once the volume comes back on. Then I want to output all this to a new m3u8 file like localhost/new.m3u8 how much of this [04:03:06 CET] <teamcoltra> could I do just with FFMPEG? [04:09:34 CET] <teamcoltra> I know FFMPEG has volume detection, my guess is I would need to have something like ffmpeg -i 'http://localhost/test.m3u8' -o new.m3u8 (with volume detect and other flags) and use something like python to read the volume data output and when it's 0 twice (or whatever) and when it's silent open up another ffmpeg which also writes to new.m3u8 with the mp4 [11:26:37 CET] <shibboleth> does anyone know how to pull the video analytics stream/content from say hikvision cameras? [11:26:58 CET] <shibboleth> rtsp://1.2.3.4/Intelligent/Channels/1 [11:27:28 CET] <shibboleth> will pull the main stream, but for some reason the analytics is only visible from their proprietary client or browser plugin [17:19:05 CET] <GuiToris> hey, does ffmpeg have lagarith encoding/decoding capabilities? [17:20:01 CET] <BtbN> There is a lagarith.c according to google. [17:20:38 CET] <c_14> according to -codecs there's a decoder but no encoder [17:20:47 CET] <c_14> though there might always be a configure switch for the encoder [17:20:50 CET] <GuiToris> c_14, ffmpeg -codecs? [17:21:40 CET] <GuiToris> I thought there's a list somewhere [17:22:21 CET] <furq> lagarith isn't particularly good anyway [17:22:53 CET] <furq> use utvideo if you want something fast and/or with vfw/quicktime support and ffv1 or x264 lossless otherwise [17:23:17 CET] <GuiToris> furq, could you recommend me another one? I usually use ffv1 in a nut file, but my friend who uses premiere cannot open these files [17:23:33 CET] <furq> utvideo [17:23:45 CET] <GuiToris> I'll check it, thanks [17:23:51 CET] <furq> they'll need to install the codec [17:24:19 CET] <furq> i think premiere should support it in mov [17:24:24 CET] <furq> but it might need to be avi on windows [17:25:15 CET] <GuiToris> or should I create lossless x264 files? That seems pretty widespread [17:25:26 CET] <furq> you can try [17:25:48 CET] <furq> i don't think premiere supports h264 hi444p [17:26:04 CET] <furq> which is the only profile that supports lossless coding [17:26:11 CET] <furq> i might be wrong though [17:26:46 CET] <furq> hi444pp, rather [17:29:19 CET] <JEEB> if you can use nvidia's encoder you'd be able to *encode* into it [17:29:21 CET] <JEEB> but not decode [17:29:23 CET] <GuiToris> helpx.adobe.com only says: h264 avc Various media that use H.264 encoding [17:29:31 CET] <JEEB> no idea if premiere lets you do that :P [17:29:47 CET] <JEEB> furq: 4:2:0 and 4:2:2 are the only things supported generally [17:29:56 CET] <JEEB> and most likely lossless coding is not [17:30:10 CET] <JEEB> even the nvidia hw *decoder* doesn't support lossless, only the encoder d oes [17:30:14 CET] <JEEB> which I find funny for some reason [17:31:33 CET] <GuiToris> right now I have thousands of png files, if I combine them into a lossless video file and that codec won't work, can I safely split them into pngs again? [17:31:44 CET] <furq> sure [17:31:48 CET] <furq> but you could also simply not delete the pngs [17:32:23 CET] <GuiToris> I don't have that much space, these files take an awful lot of space [17:32:27 CET] <furq> that will also ensure you're not doing rgb -> yuv -> rgb conversions back and forth [17:32:34 CET] <furq> which isn't lossless [17:33:07 CET] <GuiToris> ffmpeg -i lossless.nut %3d.png < is this good? [17:33:20 CET] <furq> why do you need pngs [17:33:47 CET] <furq> just work with the ffv1 source, it'll compress much better [17:33:52 CET] <GuiToris> I use blender and I usually export videos into pngs files [17:34:02 CET] <BtbN> that seems horribly inefficient [17:34:12 CET] <furq> if the ffv1 is rgb then you can convert it back to png without worrying [17:34:33 CET] <furq> i don't know that i would [17:35:10 CET] <GuiToris> BtbN, if something goes wrong, I don't have to rerender the whole footage [17:35:22 CET] <BtbN> I don't follow [17:36:07 CET] <GuiToris> you said rendering pngs files are inefficient [17:36:15 CET] <BtbN> Using them as a video is, yes [17:36:40 CET] <GuiToris> I don't use them as a video, these are just temporary files [17:36:55 CET] <GuiToris> but this time someone else is going to edit the video and he uses premiere [17:41:50 CET] <GuiToris> something else; I have a footage and I edited it, there was a boring 8 secs where nothing really happened so I cut that part. Since the subject moved a tiny bit during this period of time the editing is very noticeable. I tried fades and interpolation but you can still notice the editing. Can you recommend something? [17:43:01 CET] <GuiToris> I'm not sure if you used flash editor but there was a shape tween function [17:43:25 CET] <GuiToris> is there a similar filter in ffmpeg? [17:45:00 CET] <GuiToris> https://www.youtube.com/watch?v=b7N1fAdk0Jc&feature=youtu.be&t=236 [17:45:21 CET] <BtbN> That can't possibly work on video. [17:46:16 CET] <BtbN> It relies on the vector graphics aspect of it [17:46:33 CET] <GuiToris> I need a few more frames but minterpolate didn't work well [17:48:03 CET] <GuiToris> my backup plan is to add some camera shakes [17:48:37 CET] <BtbN> minterpolate is probably the best bet, but on plain video, that really isn't possible in that way [17:50:19 CET] <GuiToris> the main problem with thay solution is the transition had been longer and it was even more noticeable [17:50:32 CET] <GuiToris> is minterpolate the only interpolation filter in ffmpeg? [17:51:31 CET] <Hfuy> Hello. [17:51:59 CET] <Hfuy> Is there any support for HEIC images, as produced by iphones? It sounds sort of like a single HEVC frame in an ISO media file, so almost a one-frame HEVC quicktime, but... not. [17:55:11 CET] <GuiToris> Hfuy, heif? [17:55:49 CET] <Hfuy> Yes. I think HEIC is a subset of HEIF. [17:56:04 CET] <GuiToris> as far as I remember I could convert some files with the 'convert' tool [17:56:05 CET] <Hfuy> HEIC implies HEVC encoding, I believe. [17:56:16 CET] <furq> there's an open ticket for heif [17:56:19 CET] <Hfuy> But HEICs are not just single frame HEVC quicktimes, from what I can tell. [17:56:27 CET] <JEEB> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-August/215003.html [17:56:33 CET] <JEEB> the horrible story of HEIF [17:56:39 CET] <JEEB> someone implemented just the features that apple used in 2017 [17:57:22 CET] <JEEB> but since that wasn't pretty it wasn't merged [17:57:51 CET] <GuiToris> Hfuy, great, gimp is the only graphical application that can open heic [17:57:59 CET] <GuiToris> Hfuy, I used 'convert' [17:58:17 CET] <Hfuy> I have a converter. I'm just trying to write an article describing what it is and what the considerations are. [17:58:48 CET] <Hfuy> I mean, it would seem to make sense to me that something better than JPEG would be nice, but I'm not sure why that isn't just JPEG-2000, given that HEIF/HEIC is not patent-free either. [17:59:04 CET] <GuiToris> there's also webp [17:59:06 CET] <furq> because apple didn't invent webp [17:59:24 CET] <furq> i know they didn't invent heif either but who cares about nokia these days [18:00:08 CET] <JEEB> also HEIF specifically isn't limited to HEVC [18:00:19 CET] <Hfuy> Quite. [18:00:31 CET] <JEEB> it's just a supposed spec for a "new standard for images" [18:00:34 CET] <Hfuy> I believe the current iphone implementation only does HEVC, though. At least that's what the .HEIC extension implies. [18:00:40 CET] <JEEB> yes [18:00:53 CET] <Hfuy> Fuck's sake, how can they make THIS complicated. [18:00:59 CET] <JEEB> there's another subset for AV1 recently defined I think. unless they threw the HEIF over-complexity out [18:01:41 CET] <JEEB> Hfuy: HEVC even has a feature to code images as separate smaller images. instead they just split it in their own way as actually separate separate images [18:01:44 CET] <JEEB> fabulous [18:01:46 CET] <furq> a cynical man would say apple actively don't want anything else to support heif [18:01:52 CET] <furq> so that you have to use their tools [18:01:59 CET] <furq> if only there were some cynical men here to say it [18:02:11 CET] <Hfuy> Sorry. Code images as separate smaller images? [18:02:23 CET] <furq> like progressive jpeg presumably [18:02:25 CET] <JEEB> yes, in case a decoder can't handle a large enough [18:02:30 CET] <Hfuy> Oh. [18:02:36 CET] <JEEB> so you can f.ex. split it into N sectores [18:02:39 CET] <Hfuy> So you store it as four quarters, or whatever. [18:02:41 CET] <JEEB> which you can feed to a hwdecoder [18:02:44 CET] <JEEB> yea [18:02:56 CET] <JEEB> but instead of using the feature with which f.ex. our decoder could just output a single image [18:02:59 CET] <Hfuy> See that's fine, but I'm not sure what the value is of being able to decode a quarter of a photograph. [18:03:04 CET] <JEEB> "ahaha let's code it separately" [18:03:10 CET] <Hfuy> What, so more than one mdat in the file? [18:03:27 CET] <JEEB> I'm not sure of the details and some stuff probably has changed since 2017 in how apple uses it [18:03:34 CET] <Hfuy> OK. [18:03:45 CET] <JEEB> but yes, it seemed like the format gave you the option of using separate frames [18:03:47 CET] <Hfuy> This "image sequences" thing is presumably intended for "live photo" type applications. [18:03:56 CET] <Hfuy> But "image sequences" is not the same as "it's an HEVC quicktime?" [18:12:15 CET] <Hfuy> The more I read about this the more it starts to sound like MXF. [18:12:20 CET] <Hfuy> Let's make it everything to everyone! [18:12:43 CET] <JEEB> :D [18:57:18 CET] <Hfuy> JEEB you're the only software person I've ever had smile when I said MXF. [18:58:11 CET] <JEEB> mostly because I've not touched it too much - but instead looked at it from the sidelines [18:58:23 CET] <JEEB> I've done some minor patches to see if I can get the cropping info from it [18:58:37 CET] <JEEB> but applying that info would be a problem anyways [18:58:37 CET] <JEEB> :P [18:58:56 CET] <ossifrage> Is there a way to get ffmpeg to output the data at roughly 'realtime' [18:59:18 CET] <JEEB> there's multiple things that have various rate control [18:59:20 CET] <ossifrage> I'm testing some live streaming stuff but my source is just a local file [18:59:35 CET] <JEEB> ffmpeg.c has the -re option which sleep()s according to the difference in the timestamps [18:59:40 CET] <JEEB> (input option) [18:59:49 CET] <JEEB> but if your timestamps have discontinuities glhf with that [19:00:04 CET] <JEEB> then there's rate/burst control in the UDP protocol [19:00:25 CET] <ossifrage> JEEB, cool thanks, that did the trick! [19:00:56 CET] <ossifrage> It was getting *way* to far ahead without -re [20:28:48 CET] <shibboleth> i've been having trouble getting ffmpeg, mplayer to like the mjpeg stream from a specific source [20:29:07 CET] <shibboleth> just tried on a more recent distro (works) and noticed this: [20:29:55 CET] <shibboleth> not working: [swscaler @ 0x7f76a0b77fa0]bicubic scaler, from yuv422p to yuyv422 using MMXEXT [20:30:07 CET] <shibboleth> working: [swscaler @ 0x7f234de07020]bicubic scaler, from yuv422p to yuv420p using MMXEXT [20:30:24 CET] <shibboleth> how do i force the latter on the older, remote capture server? [20:31:23 CET] <JEEB> if you need 4:2:0 specifically then either push format to the end of your filter chain, or use -pix_fmt in ffmpeg.c :P [20:31:55 CET] <shibboleth> how do i do that with mplayer to test? [20:32:38 CET] <shibboleth> ffprobe on the troublesome setup: Stream #0:0: Video: mjpeg, yuvj422p(pc, bt470bg/unknown/unknown), 640x360, 25 tbr, 25 tbn, 25 tbc [20:36:26 CET] <JEEB> I would be surprised if the pix_fmt is your problem outside of maybe your player not being able to play it (for some reason) [20:37:11 CET] <shibboleth> the source device and firmware is from 2011 [20:37:34 CET] <shibboleth> i suspect both lavf56 and 57 are more recent :) [20:37:53 CET] <JEEB> if you have failures, bump verbosity to -v debug in ffmpeg.c and pastebin or so the logs [20:37:57 CET] <JEEB> then link here [20:38:13 CET] <JEEB> I'm pretty sure you're getting helped by some unrelated bug fix in FFmpeg if it started worked [20:38:14 CET] <shibboleth> not working: https://paste.ubuntu.com/p/kpyqs7k8sb/ [20:38:16 CET] <JEEB> *working [20:38:20 CET] <shibboleth> working: https://paste.ubuntu.com/p/t9h4SB3rbf/ [20:38:39 CET] <shibboleth> diff boxes, has nothing to do with vdpau, tried [20:38:58 CET] <JEEB> right, that's mplayer [20:39:10 CET] <JEEB> ffmpeg -v debug -i URL -f null - [20:39:27 CET] <JEEB> that should let ffmpeg.c decode it [20:39:55 CET] <JEEB> and you're using VDPAU VO. which then just means that the *renderer* is failing [20:40:00 CET] <JEEB> nothing to do with FFmpeg [20:40:09 CET] <JEEB> or wait, the latter is using xv VO [20:40:19 CET] <JEEB> well that explains a lot, doesn't it :P [20:40:22 CET] <shibboleth> i tried with/without on both [20:40:52 CET] <JEEB> anyways, if it doesn't fail with ffmpeg.c then it's most likely not FFmpeg [20:40:54 CET] <JEEB> it's mplayer [20:40:59 CET] <JEEB> mplayer has its own IRC channel and all [20:41:18 CET] <durandal_1707> mplayer is abandoned, same as mencoder [20:41:49 CET] <JEEB> yes, but the left over people probably can help this poor soul. not #ffmpeg [20:42:01 CET] <shibboleth> lemme try ffmpeg verbose [20:55:57 CET] <shibboleth> hmm [20:56:09 CET] <shibboleth> ffmpeg/libav on the remote box is actualy libav58 [20:56:13 CET] <shibboleth> actually [20:56:23 CET] <shibboleth> installed through a PPA [20:56:37 CET] <shibboleth> https://paste.ubuntu.com/p/3Sd8sqBZ7g/ [20:57:21 CET] <shibboleth> libav57: https://paste.ubuntu.com/p/57stYHgpMn/ [20:58:41 CET] <JEEB> to me that looks like decoding works just fine in both cases [20:58:49 CET] <JEEB> which means that if there is a problem it's highly likely in mplayer [20:59:03 CET] <shibboleth> if it is as you say, mplayer is abandoned, mpv might be the way to go [20:59:31 CET] <shibboleth> can ffplay or mpv do what mplayer can with regards to -geometry? [20:59:49 CET] <JEEB> https://mpv.io/manual/master/ [21:00:04 CET] <JEEB> depends on what you want to do with it [21:00:07 CET] <JEEB> ask #mpv if you want to test it out [21:00:47 CET] <shibboleth> well, it appears to have been fixed between xenial and bionic mplayer as well [21:01:00 CET] <shibboleth> why the version bump if abandoned? [21:01:13 CET] <JEEB> it's not 100% abandoned, at least as far as I last saw [21:01:22 CET] <JEEB> it's minimally poked by some people who still use it [21:01:29 CET] <JEEB> so if you want to use mplayer, #mplayer is available [21:04:56 CET] <shibboleth> i thought mpv was a ffplay spinoff, but i won't bother you further :) [21:05:39 CET] <JEEB> no, it's an mplayer->mplayer2->mpv spin-off [23:25:28 CET] <fructose> I'd like to quickly cut mp4 videos, but the tools I've found desync audio. Is there a method I can use with ffmpeg that avoids this? [23:26:03 CET] <JEEB> whether a desync happens depends on a whole lot of things including what the thing you're reading with can handle [23:26:33 CET] <JEEB> that said, I haven't had generally any desync when doing mp4 cuts and playing them in firefox for example [23:28:54 CET] <fructose> I'm looking for something specific, like using ffprobe to locate the nearest key frame. What I don't understand is how to prevent audio desync. [23:29:22 CET] <JEEB> as I don't know what the cause for your desync is I cannot really say anything [23:29:33 CET] <JEEB> as I noted, just plain -ss and -t with -c copy WorksForMe [23:29:50 CET] <JEEB> then there's the google "advanced" edit list stuff which you should attempt to disable [23:29:57 CET] <JEEB> since your input is mp4 [23:30:22 CET] <JEEB> -advanced_editlist 0 I think is the way to disable the google stuff [23:30:50 CET] <JEEB> (that's for the input side) [23:39:57 CET] <fructose> How does -c fit in a cut? [23:41:41 CET] <JEEB> if you don't set an output "encoder" you will get re-encoding [23:41:51 CET] <JEEB> -c copy is the "just pass these AVPackets through kthx?" option [23:41:52 CET] <JEEB> :P [23:43:45 CET] <fructose> I was getting "Unknown decoder 'copy'" so the question was more about ordering [23:43:52 CET] <furq> after the input [23:44:08 CET] <fructose> But it ran and there are lots of visual artifacts at the beginning [23:45:39 CET] <fructose> So is there a way to cut mp4 videos that doesn't desync audio or result in visual artifacts at the beginning? [23:47:42 CET] <furq> iirc you want -ss after -i when stream copying or else you'll get video delay [23:47:59 CET] <furq> because it'll cut the audio at the point you requested, which is usually before the first video keyframe [23:49:49 CET] <fructose> That removes artifacts, but leaves delay [23:49:56 CET] <fructose> I'm guessing it's not cutting on a key frame [23:51:10 CET] <JEEB> it can't not cut on a keyframe as far as I know [23:51:18 CET] <furq> it can't not cut the video on a keyframe [23:51:37 CET] <JEEB> ffmpeg.c adds a simple edit list delay so that the thing starts where you expect it to [23:51:42 CET] <JEEB> but a lot of things ignore such :P [23:51:44 CET] <furq> i take it you're using a recent ffmpeg [23:51:51 CET] <fructose> Also, the docs say "The -ss parameter needs to be specified somewhere before -i" [23:51:57 CET] <furq> because it shouldn't ever have artifacts at the beginning (unless your player is dumb) [23:52:10 CET] <JEEB> yes, -ss is preferred there esp. if you're doing remuxing [23:52:15 CET] <JEEB> but I think it's being taken on both sides :P [23:52:17 CET] <furq> which docs are these [23:52:35 CET] <JEEB> it used to matter more, I don't think it matters as much any more [23:52:51 CET] <fructose> furq: http://trac.ffmpeg.org/wiki/Seeking [23:53:16 CET] <furq> yeah the wiki isn't the docs [23:53:22 CET] <furq> https://ffmpeg.org/ffmpeg.html#Main-options [23:54:39 CET] <fructose> Might not be the manual, but they are docs [23:57:28 CET] <fructose> I'm using VLC, but I'll update to 3.0.6 to see if that helps [23:58:51 CET] <fructose> -ss before -i gets artifacts. -ss after gets delay in start of video [23:59:24 CET] <shibboleth> JEEB, it was vdpau [23:59:46 CET] <shibboleth> specifying -vo gl/x11 worked [00:00:00 CET] --- Sun Feb 10 2019

1 0

ffmpeg-devel.log.20190208
by burek 09 Feb '19

09 Feb '19

[00:15:30 CET] <cone-642> ffmpeg 03Marton Balint 07master:28dd73a4437a: ffplay: use different decoder names for each media type [00:15:30 CET] <cone-642> ffmpeg 03Marton Balint 07master:fe99a51c40d5: ffplay: add missing avfilter_graph_alloc result check [00:15:30 CET] <cone-642> ffmpeg 03Marton Balint 07master:7cab5471b231: ffplay: add support for setting the number of filter threads [08:15:22 CET] <akravchenko188> jkqxz: hi. it would be very good to speedup amf patches review and submit. to archive this we could send couple of new AMD cards to members of community who tests such patches. could you please help me with this? [08:59:03 CET] <JEEB> michaelni: I'm sorry for bothering, but I will have to ask you to review the libaribb24 thread to see if I could have done things better there. http://ffmpeg.org/pipermail/ffmpeg-devel/2019-February/239629.html [10:03:51 CET] <j-b> Sorry, going to disagree on homebrew [11:19:53 CET] <perseiver> can anyone help here regarding ffmpeg, converting video to h.264? [12:21:12 CET] <cone-143> ffmpeg 03chcunningham 07master:3ea87e5d9ea0: avformat/mov.c: require tfhd to begin parsing trun [12:21:12 CET] <cone-143> ffmpeg 03chcunningham 07master:1c15449ca9a5: avformat/mov: validate chunk_count vs stsc_data [12:21:12 CET] <cone-143> ffmpeg 03Decai Lin 07master:9d800d39d557: avcodec/h264_parse: no need check ref list1 for P slices. [12:21:12 CET] <cone-143> ffmpeg 03Michael Niedermayer 07master:7f8bfbee3663: avcodec/h264_parse: Clear ref_list[1] if only [0] is used [13:34:41 CET] <j-b> Could you stop committing things like this? [13:35:29 CET] <j-b> his name is "Chris Cunningham", not "chcunningham" [13:47:10 CET] <durandal_1707> michaelni: you evil [13:51:49 CET] <michaelni> j-b, sorry, that was what was in the submitted patch. Ill ask him fix this for future patches [13:56:37 CET] <j-b> Guys, you keep doing that over and over and over [13:56:59 CET] <j-b> When someone wants to use a pseudonym, sure, but here it is just "I did not set my git correctly" [13:57:07 CET] <j-b> it's very hard for copyright and so on [13:57:22 CET] <j-b> (see the vp9 or prores fight, why copyright is important) [14:27:17 CET] <atomnuker> vp9 fight? [14:27:39 CET] <durandal_1707> viper9 [14:30:51 CET] <gnafu> Was ProRes when The King broke the silence on his faked death, or am I thinking of another instance of misattribution? [14:46:41 CET] <durandal_1707> gnafu: king is dead, fake author was pushed to the tree [14:55:38 CET] <atomnuker> there are many kings, but only one's the king of pop [14:55:49 CET] <atomnuker> or was it rock? [15:35:25 CET] <gnafu> atomnuker: I'm referring to the king of rock 'n' roll. The king of pop is Michael Jackson, as I understand it. [17:54:09 CET] <BtbN> Is that a bot or something? [17:55:43 CET] <jdarnley> maybe a poor, unfortunate intern [19:23:34 CET] <jdarnley> Thankfully ffmpeg has its own robo/intern [21:50:33 CET] <KungFuJesus> you guys need to mangle names on this function or there's a symbol conflict: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/cuda_check.c [21:50:51 CET] <KungFuJesus> libavutil and libavcodec both are exporting ff_cuda_check [21:51:37 CET] <jamrial> philipl: ^ [21:52:22 CET] <KungFuJesus> or make one lib call into the other, though I'm guessing you are intentionally not doing that so that they can be separate SOs [21:52:55 CET] <JEEB> KungFuJesus: seems like the semi-correct person got highlighted :) [21:53:46 CET] <KungFuJesus> cool, glad I could help [21:57:22 CET] <BtbN> Sony Vegas Pro support forums at its best: "Except for uncompressed video there is no such thing as "lossless". All codecs are lossy, but I think what you are looking for is to encode with a setting that will have the same quality as your source encode." [21:57:59 CET] <BtbN> That guy is talking so much bullshit in that thread, wow [21:58:01 CET] <JEEB> :D [21:58:14 CET] <JEEB> yes, because enterprise only uses raw as lossless [21:58:24 CET] <JEEB> I have literally received masters that are raw RGB in mov [21:58:31 CET] <JEEB> when I requested lossless [21:58:49 CET] <BtbN> Guess I will not pay for Vegas, as it can't even do lossless h264 [21:59:07 CET] <JEEB> a lot of people utilize umezawa's Ut Video package for lossless intermediates [21:59:22 CET] <JEEB> since it has video for windows, directshow, media foundation and QT modules [21:59:30 CET] <BtbN> If only OpenShot would be more stable :/ [22:00:06 CET] <BtbN> I don't need a lot of functionality really, and in theory could do it with ffmpeg.c, but stinger transitions via CLI are a pain [22:00:26 CET] <BtbN> Might still end up scripting them [22:00:56 CET] <gnafu> BtbN: Are you referring to the newer 2.x series, or the older 1.4x one? [22:01:17 CET] <gnafu> Granted, I haven't used either extensively, but my impression is that the newer 2.x OpenShot is much more stable. [22:01:26 CET] <gnafu> I've also had good experiences with Shotcut. [22:03:46 CET] <BtbN> Tried whatever is the latest on their website [22:03:59 CET] <BtbN> And within minutes of playing around with it I had uninteractible things stuck in my timeline [22:04:47 CET] <gnafu> Aah. [22:06:43 CET] <KungFuJesus> yikes, sandybridge-e CPU is struggling with dav1d with Netflix's sample chimera video [22:07:05 CET] <JEEB> KungFuJesus: I think that's AVX1 only, right? [22:07:09 CET] <KungFuJesus> the toddler fountain footage drops frames like mad :-p [22:07:24 CET] <KungFuJesus> yeah, so no FMA and only SSE level 4-wide SIMD [22:09:00 CET] <KungFuJesus> I'm tempted to try to accelerate some of the functions myself, but my experience with SIMD is usually through intrinsics. It looks like ffmpeg prefers raw nasm asm [22:09:18 CET] <JEEB> raw asm with the x264 wrapper that makes defining functions simpler [22:09:27 CET] <JEEB> even I was able to do a left predict! [22:09:30 CET] <KungFuJesus> GCC's register allocator when playing with intrinsics, at least in my experience, isn't half bad. But perhaps people are better at tuning with nasm [22:09:32 CET] <JEEB> and I'm dumb in SIMD! [22:10:29 CET] <BtbN> Hm, we do not seem to have a way to not export a non-static symbol, or am I missing something? [22:10:55 CET] <JEEB> KungFuJesus: also dav1d technically is a separate project outside of FFmpeg, but the style is the same [22:11:01 CET] <jamrial> KungFuJesus: dav1d is currently fully optimized with avx2 simd. ssse3 simd is still in the works [22:11:08 CET] <KungFuJesus> I suppose I could write something in intrinsics, post the resulting assembly for someone to translate into the dialect NASM expects [22:11:10 CET] <jamrial> 8bits only in both cases [22:11:12 CET] <JEEB> manual assembler and most likely using the same x264 framework :) [22:11:15 CET] <jamrial> 10bit comes later [22:11:30 CET] <gnafu> KungFuJesus: Check out #dav1d. There's definitely need for more SSSE3 SIMD. [22:11:36 CET] <JEEB> KungFuJesus: example https://github.com/jeeb/libav/blob/utvideo-simd/libavcodec/x86/utvideodsp.a… (doesn't work beyond first line but that should be enough [22:11:50 CET] <JEEB> and yes, #dav1d [22:11:51 CET] <JEEB> :) [22:11:51 CET] <gnafu> For a list of things left to do: https://code.videolan.org/videolan/dav1d/issues/216 [22:11:58 CET] <KungFuJesus> I also have a G5 that I can author some altivec on, and an rpi3 for NEON/ASIMD [22:13:23 CET] <gnafu> KungFuJesus: CDEF is a big one that doesn't have any SSSE3 SIMD yet. As someone whose main computers lack AVX2, I would be grateful for anything you'd like to contribute in that regard ;-). [22:13:27 CET] <KungFuJesus> though I suspect the really poor memory bandwidth of the rpi3 will prevent any terribly useful accelerations (In my experience it's been really poor with fftw for work related stuff, SIMD or not) [22:14:13 CET] <gnafu> That I couldn't say. Here's the tracker for NEON SIMD: https://code.videolan.org/videolan/dav1d/issues/215 [22:14:39 CET] <KungFuJesus> I'm sure I could produce something that's useful, it's just hard to measure improvements on that device due to memory bandwidth constraints being what most problems are bound by [22:15:32 CET] <KungFuJesus> I'll have to run perf on the unstripped library to see exactly where the cycles are spent for me during that portion of the video, but I'll check out those links [22:16:30 CET] <BtbN> philipl, do you remember if there's a particular reason ff_cuda_check isn't an inline-function in the header? [22:34:01 CET] <KungFuJesus> looks like the vast majority of time is in cdef_filter_block_c for me [22:34:14 CET] <KungFuJesus> the "_c" I'm guessing means it's a vanilla C implementation [22:35:06 CET] <gnafu> That's my understanding, yes. [22:36:18 CET] <KungFuJesus> hmm, I see at least one loop in this asm that looks unrolled. And some conditional move instructions [22:36:36 CET] <KungFuJesus> actually the whole thing is basically cmov's, hah [22:36:37 CET] <gnafu> I think CDEF is the next big thing on the chopping block for SSSE3 SIMD, and probably that one that will enable my home machines to do realtime HD decoding :-D. [22:37:13 CET] <gnafu> BBB mentioned in #dav1d that translating from the AVX2 SIMD shouldn't be too difficult for someone who knows what they're looking at. [22:37:18 CET] <KungFuJesus> if the condition they are moving on is very predictable, it might actually be better to force a branch and let the BPB take care of it [22:37:32 CET] <gnafu> (If I understood him correctly.) [22:37:44 CET] <BBB> I already wrote a xmm function for cdef_dir [22:37:46 CET] <KungFuJesus> I tend to do a lot of AVX2 code and backport to SSE4/AVX at work [22:37:48 CET] <BBB> cdef_filter isn't hard either [22:38:50 CET] <BBB> but dav1d talk should be in #dav1d... [22:39:05 CET] <BBB> as for the cmov, don't do that. for the C is written to be small and readable [22:39:11 CET] <BBB> the simd is typically different and doesn't use branches [22:39:18 CET] <BBB> check x86 simd to get an idea of what to do [22:39:55 CET] <KungFuJesus> oh I'm aware of the branchless nature of whatever the SIMD implementation will be. I was just wondering if the scalar C version could be sped up by making GCC less eager to emit CMOVs [22:48:28 CET] <KungFuJesus> BBB: it looks like majority of the work is happening in 128 bit wide registers, anyhow: https://code.videolan.org/videolan/dav1d/blob/master/src/x86/loopfilter.asm [22:48:48 CET] <KungFuJesus> unless someone you guys are stripping off the vex encoded nomenclature for those instructions [22:49:50 CET] <BBB> we are :) [22:50:02 CET] <BBB> see x86inc.asm [22:52:05 CET] <KungFuJesus> ah yes, pmadd, the fma before there were FMAs :) [22:52:14 CET] <BBB> the basic idea (we don't necessarily use that in dav1d, but in general) is to be able to macro'ify functions and reuse them for xmm as well as ymm [22:52:34 CET] <BBB> fma is float though [22:52:53 CET] <KungFuJesus> right, but avx512 recently added integer FMAs, presumably for some DL stuff [22:54:30 CET] <KungFuJesus> if only the vast majority of this stuff was floating point domain, AVX would have been sufficient. I suppose they have to be integer or fixed point to not deal with the non-sense of denormals, under and overflows [22:54:31 CET] <BBB> ah right [22:54:44 CET] <BBB> it's more about not drifting [22:54:52 CET] <BBB> float drifts by nature because it's not bitexact [22:55:00 CET] <BBB> int cna be exactly defined [22:55:06 CET] <KungFuJesus> right, you blow out your precision with big numbers [22:56:48 CET] <KungFuJesus> this would be much more legible in compiler instrinsics, though :-/. And possibly easier to wrap. I might look at this this weekend to see if I can translate it to SSE4 (looks like there's a pmin/pmax in there) [23:08:01 CET] <BBB> readability of intrinsics is subjective [23:08:06 CET] <BBB> you like it because you're familiar with it [23:08:10 CET] <BBB> we don't because we're not [23:08:20 CET] <BBB> ¯\_(Ä)_/¯ [23:08:34 CET] <BBB> it's like coding style, or non-asm language: python or go? [23:09:00 CET] <BBB> it's the one nice thing about starting a new project, you cna just say "it shall be 4 spaces forever more!" and so it is [23:11:36 CET] <atomnuker> yeah, didn't work that way with rav1e [23:12:03 CET] <atomnuker> 2 spaces carried over from xiph/aom and 4 spaces introduced by sane people [23:19:39 CET] <KungFuJesus> BBB: it's mostly easier because the layer of glue between instructions and the C interface is more obvious. You get a little less control as to what spills to stack and what stays in registers, but it's very easy to know what's loading into a vector register and from what address [23:21:02 CET] <BBB> atomnuker: progress <3 b/c real programmers use 4 spaces [23:21:21 CET] <BBB> KungFuJesus: don't worry, I'm very familiar with asm :) [23:23:38 CET] <KungFuJesus> I'm not unfamiliar with it, but it's really convenient to not have to pay attention to when you need to spill to stack, or to track which vector registers you've used [23:24:42 CET] <jamrial> that's what the magic of x86inc is for [23:25:09 CET] <KungFuJesus> oh I wasn't aware it was handling register spills, that's at least one less thing to worry about [23:28:48 CET] <jamrial> it handles prologue and epiloge, stack pointer, provides aliases so you can write functions using mmx, xmm and ymm registers in a single macro [23:29:16 CET] <jamrial> translates three operand instructions (avx style) to mov + two operand instruction if needed, etc [23:29:19 CET] <jamrial> it's pretty neat [23:30:51 CET] <KungFuJesus> what is this madness in the RO section? [23:30:53 CET] <KungFuJesus> pb_m1_2: times 16 db -1, 2 [23:32:24 CET] <jamrial> an array of 32 bytes, probably to be used as index for pshufb or similar [23:34:06 CET] <KungFuJesus> that's not really clear that is a shuffle vec [23:34:20 CET] <jdarnley> The one time I looked at using intrinsics, it made doing that ^^ impossible. [23:34:52 CET] <atomnuker> its not the best name, yeah [23:34:55 CET] <KungFuJesus> so does that mean, for instance, the transpose macro there is mostly avx safe, or does it lack the proper number of tranpositions for the matrix dimension to work? [23:36:17 CET] <KungFuJesus> obviously those unpacks don't work, but you could just use the floating point versions and it'd work the same, albeit with maybe a slightly higher latency [23:37:39 CET] <KungFuJesus> actually the floating point unpacks have the same latency and pipeline throughput sizes [23:38:08 CET] <atomnuker> yeah, these days you can use whatever without penalty [23:38:12 CET] <jamrial> KungFuJesus: join #dav1d, there are other devs there who wrote most of these functions and understand them best [23:39:05 CET] <KungFuJesus> jdarnley: you can construct a shuffle vector with instrinsics quite easily [23:40:05 CET] <KungFuJesus> just declare an __m256i as a static, the compiler will put it in the RO section of the binary in most circumstances [23:44:23 CET] <KungFuJesus> most of the compiler intrinsics share a name with their instruction, I've never heard someone describe instrinsics as less legible than their raw assembly counterparts [23:46:26 CET] <jdarnley> most? bollocks! [23:50:31 CET] <BBB> ... [23:50:35 CET] <BBB> blue! [23:50:41 CET] <BBB> blue is better than yellow [23:50:43 CET] <BBB> everyone knows it [23:50:49 CET] <BBB> KungFuJesus: it's a pointless argument, really [23:50:56 CET] <BBB> let's not have it [23:51:02 CET] <BBB> everyone can program in their own favourite dialect [23:51:09 CET] <BBB> ours is x86inc.asm-assisted nasm [23:51:19 CET] <BBB> sorry if that's not yours [23:51:54 CET] <jdarnley> :( please can we argue? [23:52:44 CET] <BBB> sure [23:52:47 CET] <BBB> I'm gonna go home though [23:52:48 CET] <BBB> bbl [23:54:19 CET] <BtbN> philipl, https://github.com/BtbN/FFmpeg/commit/91ea6f192181a5947e6b966defb753d3fdcd0… [00:00:00 CET] --- Sat Feb 9 2019

1 0

ffmpeg.log.20190208
by burek 09 Feb '19

09 Feb '19

[01:09:02 CET] <Aerroon> is it possible to put text onto a video without re-rendering? i'm guessing it's not, right? [01:09:56 CET] <JEEB> nope [01:10:06 CET] <JEEB> I mean, if you mean into the actual video stream [01:10:19 CET] <JEEB> so that it isn't a separate subtitle track/stream [01:10:37 CET] <Aerroon> that's what i figured [01:11:02 CET] <Aerroon> i was just thinking that a lot of simple editing stuff people want to do shouldn't really require you to render the resulting video [01:11:23 CET] <Aerroon> in simple editing things you mostly just want to cut and transition from clip to clip and sometimes text of some kind [01:11:45 CET] <Aerroon> in those cases probably something like 90% of the video would be untouched, but it still gets rendered again [01:14:38 CET] <JEEB> partial re-encoding is a thing but it isn't something many tools do out of the box (but enable if you utilize the APIs and make your own tool for it) [01:15:24 CET] <JEEB> because you basically just look at the initialization parameters of the source stream, and then try to set up your encoder to match those parameters [01:15:39 CET] <JEEB> after that you figure out where does your editing actually touch the video surface [01:15:59 CET] <JEEB> and then re-encode only parts that are touched, otherwise pass the original video packets through :P [01:19:09 CET] <ossifrage> Aerroon, it might be possible to use some of the rarely used codec toolbox features to get an overlay layer, but it would be very-non-trivial [01:19:35 CET] <Aerroon> oh nah i'm not interested in doing it, i was just wondering if it's possible [01:19:56 CET] <Aerroon> but yeah, i was thinking that partial reencoding like JEEB mentioned [01:20:04 CET] <Aerroon> i wonder if that's ever going to be a thing with editing software [01:21:02 CET] <ossifrage> For example, you might be able to use the SCV stuff in h.264 to get an overlay, but it would be a hack [01:21:47 CET] <ossifrage> The partial re-encoding tricks only really work if you can constrain the initial encode [11:09:01 CET] <perseiver> Do anyone get success in setting packetization mode = 0 in H.264 video using FFMPEG? currently if any video is converted using ffmpeg (vcodec libx264) , the result stream comes with packetization-mode=1 in SDP parameter [13:12:27 CET] <hedgehog90> Hi, I'm trying to use the palettegen with a segment of video. I want it to be frame accurate so I use -ss after -i, but then I get the following error: [13:12:32 CET] <hedgehog90> Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used) [13:12:37 CET] <hedgehog90> If I put -ss before -i (inaccurate times) then it works. [13:12:42 CET] <hedgehog90> Works: ffmpeg -ss 5 -t 5 -i in.mkv -vf "scale=320:-1:flags=lanczos" -y out.mkv [13:12:46 CET] <hedgehog90> Fails: ffmpeg -i in.mkv -ss 5 -t 5 -vf "scale=320:-1:flags=lanczos" -y out.mkv [13:13:38 CET] <hedgehog90> ^ oops, forgot to add palettegen after scale filter in both examples [13:13:48 CET] <pink_mist> I thought -i specifies the input file [13:14:06 CET] <pink_mist> not anything to do with "inaccurate times" [13:14:41 CET] <hedgehog90> right, but if you put -ss before the -i then it is not frame accurate [13:16:11 CET] <hedgehog90> any ideas? [13:18:30 CET] <ariyasu> i think your error is the -t 5 after i [13:19:08 CET] <ariyasu> also unless it's raw video where every frame is an iframe [13:19:12 CET] <hedgehog90> I've tried either, makes no diff. -t is frame accurate, the video is 5 seconds exactly. [13:19:14 CET] <ariyasu> it will never be frame accurate [13:21:12 CET] <furq> -ss should be frame accurate if you're not stream copying [13:21:15 CET] <furq> before -i [13:22:21 CET] <hedgehog90> Oh really? It's hard for me to tell with a 16x16 palette if I've got the right frames. [13:22:41 CET] <furq> just run the command without palettegen [13:23:06 CET] <TheAMM> -ss before -i has had fast frame-accurate seeks by default for years (AFAIK) [13:23:12 CET] <hedgehog90> so -ss before -i is only inaccurate when copying video stream? [13:23:15 CET] <furq> you might want to put -t after -i, i forget how -t before -i works with -accurate_seek [13:23:24 CET] <furq> but yeah just check if it's right [13:23:55 CET] <hedgehog90> Nice one. Thanks furq [13:24:09 CET] <furq> -ss before -i seeks to the nearest keyframe before and then decodes and discards everything up to the timestamp you gave it [13:24:20 CET] <furq> obviously that doesn't work if you're stream copying because segments have to start on a keyframe [13:24:25 CET] <hedgehog90> Got it. [13:28:35 CET] <hedgehog90> Also, while I'm here, with filter_complex is it possible to palettegen and paletteuse in one filter chain? I tried it and it appeared no palette was being used. [13:38:50 CET] <furq> it is possible but it might use a lot of memory [13:41:03 CET] <hedgehog90> ok, would you recommend doing it in a separate process then? [13:41:11 CET] <furq> as a general rule yes [13:41:16 CET] <hedgehog90> ok [13:42:44 CET] <furq> ffmpeg -i foo.mkv -lavfi "[0:v]select=between(t\,5\,10),palettegen[pal];[0:v][pal]paletteuse" bar.gif [13:42:47 CET] <furq> something like that [13:43:52 CET] <hedgehog90> you're doing it in a single chain / process there [13:44:05 CET] <furq> yeah that's the one that might use a lot of memory [13:44:10 CET] <furq> it shouldn't be too bad if you're only selecting five seconds [13:44:58 CET] <furq> actually nvm that buffers like 4.5GB here on a 720p clip [13:45:00 CET] <furq> so maybe not [14:38:27 CET] <Elirips> Hello. I have a set of images, which I would like to use as input for ffmpeg and then output them again as images. The input shall be read with 1 fps, outputed to 5fps. I tried with 'ffmpeg.exe -r 1 -loop 1 -i E:\Var\dummy_%02d.jpg -r 1 -an -s 352x288 -q:v 2 -f image2pipe -update 1 -y \\.\pipe\Cam01.jpg' but it seems the first '-r 1' gets ignored? [14:39:22 CET] <Elirips> (sorry, the second '-r 1' should be '-r 5', but it does not matter for the problem) [14:39:46 CET] <Elirips> I also tried with something like -r 0.1 for the first fps parameter (for the input), but it does not change anything [14:44:23 CET] <Elirips> also using '-framerate' instead of '-r' before the input does not help [14:52:11 CET] <Elirips> hm, if outputing to avi, everything works as expected: 'ffmpeg.exe -f image2 -framerate 1 -i E:\Var\dummy_%02d.jpg -s 352x288 -y "c:\test.avi"' [15:27:55 CET] <Elirips> now I would like to take that avi, loop it forever, read it with 1 fps, and output that to image2pipe with 5 fps... impossible? [15:28:36 CET] <c_14> try -vsync vfr as an output option [15:29:08 CET] <c_14> and stream_loop instead of loop [15:33:53 CET] <Elirips> c_14: thanks I'll give that a try [15:34:35 CET] <Elirips> any idea why reading single images with '-f image2' and outputing them using '-f image2pipe' seems to ignore all '-framerate' settings? [15:40:38 CET] <Elirips> stream_loop works fine for the avi input, but still it is outputing the input avi at an enormous speed [15:41:05 CET] <Elirips> trying with 'ffmpeg.exe -vsync 1 -stream_loop -1 -i E:\test.avi -f image2pipe -y \\.\pipe\Cam01.jpg' [15:41:57 CET] <Elirips> trying with 'ffmpeg.exe -r 1 -vsync 1 -stream_loop -1 -i E:\test.avi -f image2pipe -y \\.\pipe\Cam01.jpg' [15:42:06 CET] <Elirips> its played with a speed of ~460x :D [16:01:56 CET] <c_14> try -re [16:02:01 CET] <c_14> that might be what you want [16:02:37 CET] <mfwitten> Elirips: ffmpeg -y -f image2 -framerate 1 -loop 1 -i E:\Var\dummy_%02d.jpg -r 5 -f image2 -update 1 \\.\pipe\Cam01.jpg [16:03:56 CET] <mfwitten> Elirips: The thing is, what you are expecting on output really? [16:04:06 CET] <mfwitten> Elirips: What is consuming those images? [16:04:36 CET] <Elirips> i am consuming those images from within a c++ app written by me :/ [16:04:51 CET] <Elirips> and normally, I have a bunch of rtsp streams as inputs [16:05:15 CET] <Elirips> but with my test-environment here, I can only start about ~ 10 streams at once, then the single camera I have crashes [16:05:24 CET] <Elirips> so I was trying to just feed it with single images [16:05:43 CET] <mfwitten> Elirips: OK. Well, ffmpeg will read in your frames, and you're telling it that those frames occur at 1 frame per second, and then you're telling ffmpeg to re-generate those frames such that they occur at 5 frames per second, and then you are writing out those generated frames to a pipe [16:06:09 CET] <mfwitten> Whatever is consuming those frames would be responsible for interpreting their presentation time (i.e., the frame rate) [16:06:19 CET] <Elirips> mfwitten: yes, so I would expect ffmpeg to give me one frame at my pipe every 200ms [16:06:21 CET] <mfwitten> Elirips: You just want to scale the images, etc. right? [16:06:48 CET] <Elirips> more or less, yes [16:07:08 CET] <BtbN> Elirips, ffmpeg will go as fast as it can. The fps value only governs the timestamps, not the actual speed it processes at. [16:07:20 CET] <BtbN> Like c_14 said, to artificially limit that, you want -re. [16:07:23 CET] <mfwitten> Elirips: ffmpeg is not a player. [16:07:27 CET] <mfwitten> Elirips: That's the issue [16:07:27 CET] <Elirips> thank you, so there is a fundamental missunderstanding on my side :) [16:07:51 CET] <Elirips> I'll give that a try thanks everyone for the hints [16:08:07 CET] <BtbN> Keep in mind -re is an ffmpeg.c hack. It's not available via the API. [16:09:04 CET] <Elirips> yep, reading the doc about -re sounds exactly like what I need [16:11:09 CET] <mfwitten> Elirips: ffmpeg -y -re -f image2 -framerate 5 -loop 1 -i E:\Var\dummy_%02d.jpg -f image2 -update 1 \\.\pipe\Cam01.jpg [16:15:21 CET] <Elirips> awesome :) [16:15:39 CET] <mfwitten> Elirips: What is your final command line? [16:17:25 CET] <Elirips> ffmpeg.exe -y -re -f image2 -framerate 1 -loop 1 -i E:\dummy_%02d.jpg -f image2pipe -r 5 -s 352x288 -q:v 2 -y \\.\pipe\Cam01.jpg [16:18:41 CET] <mfwitten> Elirips: To me, that would read it in at 1 FPS and then as quickly as possible produce 5 FPS (generate duplicate images) and send them off to your app as fast as possible [16:18:51 CET] <mfwitten> Elirips: So, you're probably doing a lot more processing than necessary [16:19:17 CET] <Elirips> right right [16:19:26 CET] <Elirips> if I look at the timings on my side [16:19:30 CET] <Elirips> things arrive very quickle [16:19:35 CET] <Elirips> then nothing for a long time [16:19:39 CET] <Elirips> and again 5 frames :) [16:19:51 CET] <Elirips> but I'm getting the idea now [16:20:05 CET] <Elirips> I'll just multiply my input images *5 [16:20:16 CET] <Elirips> then do '-re -framerate 5' [16:20:22 CET] <Elirips> and I thinkg then I should get what I want [16:20:57 CET] <mfwitten> Elirips: No need to multiply by 5 [16:21:43 CET] <Elirips> hm, but how then: I would like to get the first image 5 times, with a wait of ~200ms inbetween [16:22:16 CET] <mfwitten> Elirips: oh [16:22:44 CET] <Elirips> its for testing only, so multiply the input images will be fine [16:22:55 CET] <Elirips> I need to simulate an input-device with 5 fps [16:23:15 CET] <Elirips> but where the image changes only every 1 second [16:23:19 CET] <Elirips> (dont ask if that makes sense or not) [16:23:51 CET] <mfwitten> Elirips: All right. Good luck! [16:24:06 CET] <Elirips> mfwitten: thanks a lot (also all others who helped)! [18:08:28 CET] <hedgehog90> Is there a way to delay/re-time a subtitles filter (reading an srt) in ffmpeg? [18:09:06 CET] <hedgehog90> I'm hardcoding some subs and i want to delay them/make them appear sooner [18:09:15 CET] <kepstin> hedgehog90: using the subtitles filter? No. What you can do is re-time the *video* that it's being rendered over. [18:09:37 CET] <hedgehog90> Ok, but I want the base video to stay the same [18:09:39 CET] <kepstin> so if you want the subtitles to render earlier, use e.g. the -itsoffset input option to make the video be later [18:10:17 CET] <hedgehog90> -itsoffset delays the video? [18:11:13 CET] <kepstin> the -isoffset input option applies a timestamp offset to all of the streams in an input file [18:11:18 CET] <kepstin> -itsoffset [18:12:00 CET] <hedgehog90> I have to input the subtitle using filter_complex, I don't think -itoffset will work. I have a very complex filter chain, in which subtitles are just one element, I'm not sure -itoffset will work [18:12:02 CET] <kepstin> it doesn't actually change the contents in anyways, it just applies an offset to the timestamp numbers. And then the subtitles filter uses those timestamp numbers to figure out how to sync up the subtitles. [18:12:46 CET] <kepstin> ah, if you're doing multiple things then that would make it complicated, yeah. You might have to use a setpts filter to apply an offset before the subtitles filter, then another setpts filter afterwards to undo the offset. [18:13:41 CET] <hedgehog90> ah, setpts is what I was looking for I think [18:13:44 CET] <hedgehog90> thanks [18:14:49 CET] <kepstin> (as an aside, an option in the subtitles filter to set a timestamp offset would be pretty handy...) [18:17:22 CET] <hedgehog90> It would be nice :) [18:37:26 CET] <furq> you might just want to use another tool to retime the srt in advance [18:37:35 CET] <furq> any decent subtitle editor will do it [18:44:11 CET] <hedgehog90> furq I'd like to avoid that if possible [18:44:37 CET] <hedgehog90> btw I tried using setpts and couldnt get it to work. [18:44:57 CET] <JEEB> filters don't work with sbutitles because subtitels are the only things still not using AVFrames [18:45:04 CET] <JEEB> they have AVSubtitles [18:45:25 CET] <hedgehog90> even text subtitles? [18:45:32 CET] <furq> the ugly double input itsoffset trick should work iirc [18:45:38 CET] <hedgehog90> ie, not image based [18:45:48 CET] <furq> -i foo.mp4 -itsoffset 123 -i foo.mp4 -map 0:v -map 0:a -map 1:s [18:46:45 CET] <furq> also it's only text subtitles, image-based subtitles are treated as a video stream iirc [18:47:10 CET] <furq> idk if they're handled specially but you can definitely use filters on them [18:47:18 CET] <kepstin> hedgehog90: you need to apply the setpts filter on the video stream that the subtitles will be rendered over, and offset in the opposite direction [18:47:30 CET] <JEEB> there's sub2video for picture based subs [18:47:38 CET] <JEEB> which is a very horrible hack [18:47:55 CET] <JEEB> I've tried to improve it at some point but ended up having it go barely realtime with overlay :P [18:48:36 CET] <hedgehog90> ok, I think I've worked out a solution [18:48:51 CET] <kepstin> hedgehog90: e.g. to make the subtitles show up 10s later, do setpts=PTS-10/TB,subtitles=...,setpts=PTS+10/TB [18:48:56 CET] <JEEB> also itsoffset often doesn't work at all without copyts [18:49:02 CET] <JEEB> because ffmpeg.c loves to look at the initail offset [18:49:05 CET] <JEEB> and zero that out [18:49:22 CET] <hedgehog90> kapstin oh that's neat [18:49:24 CET] <JEEB> and/or -vsync passthrough [18:49:43 CET] <furq> yeah that setpts hack looks nicer than itsoffset [18:51:44 CET] <hedgehog90> I think you got the - and + back to front kepstin, flipping them worked [18:51:57 CET] <hedgehog90> thanks! [18:52:38 CET] <kepstin> yeah, that works in either direction [18:53:35 CET] <hedgehog90> works perfectly [19:29:33 CET] <lays147> Hello guys, I would like to have some guidance today. I have this old script that runs in a probably very old ffmpeg(dont have access to the machive to check the version) and the new script that runs on ffmpeg 2.8.15 [19:29:34 CET] <lays147> https://pastebin.com/0nLx9fxj [19:29:57 CET] <lays147> the problem is that apparently the audio channel generated by the codec aac is not compatible with out old system [19:30:55 CET] <DHE> he_v2 is most likely the issue. try again with the default profile. though you'll probably want to raise the audio bitrate as well [19:30:57 CET] <lays147> and then I compiled ffmpeg with the lib libfdk_aac and I am trying to generate a video/audio that works with the new specs [19:32:36 CET] <lays147> but changing the acodec from aac to libfdk_aac, and running the new script, I get an error that the option preset isnt recognized. [19:33:49 CET] <lays147> so anyone can help me to change the old script to works on new versions of ffmpeg ? or create a script that works? If I use the lib libfdk_aac and just remove the commands that arent recognized, I can get a video, but it freezes in almost every frame [19:50:30 CET] <furq> lays147: did you build the new ffmpeg with libx264 [19:52:50 CET] <lays147> furq: the ffmpeg that I build from my is based on the snapshot N-93094-g7f8bfbe based on this: https://stackoverflow.com/questions/18746359/compile-ffmpeg-with-libfdk-aac [19:53:11 CET] <lays147> that option is disabled by default when compiling by hand? [19:53:36 CET] <furq> any option starting with --enable-lib is disabled by default [19:54:45 CET] <DHE> so you'll need at a minimum: ./configure --enable-libx264 --enable-gpl --enable-libfdk-aac --enable-nonfree [19:54:55 CET] <DHE> though chances are this will be enough for you [19:55:11 CET] <lays147> DHE: thanks, just checked out and the libx264 is missing [19:56:38 CET] <furq> i take it you're not building ffmpeg 2.8 [19:57:37 CET] <lays147> furq: yeah, I got from the src... I think that I will get the src of 2.8 to not have future issues [19:57:54 CET] <furq> you should really build a newer version unless something's blocking you [19:58:06 CET] <furq> 2.8 is pretty old now [19:58:20 CET] <furq> if you're trying to build the same version your distro has then there's really no point doing that [19:58:41 CET] <furq> just build with --enable-static and keep your ffmpeg separate from the system one [19:59:19 CET] <lays147> furq: ok [21:45:11 CET] <KungFuJesus> you guys need to mangle names on this function or there's a symbol conflict: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/cuda_check.c [21:45:45 CET] <JEEB> post it either on the trac issue tracker, or the ffmpeg-devel mailing list I guess? [21:46:03 CET] <KungFuJesus> libavutil and libavcodec both are exported ff_cuda_check [21:46:17 CET] <JEEB> that sounds broken indeed [21:46:19 CET] <KungFuJesus> s/exported/exporting/g [21:47:44 CET] <JEEB> or I guess if you can catch anyone handling the cuda related code you might also have luck on the developer IRC channel. this is strictly for user support and mostly lacks developers :P [21:47:48 CET] <JEEB> (except masochists like me) [21:49:27 CET] <KungFuJesus> Ok, will try. Not sure it's worthy of a whole bug report, somebody will find it pretty quickly trying to build from master [21:49:49 CET] <KungFuJesus> if they are building libavutil + libavcodec (one uses the static archive from the other) [22:06:54 CET] <BtbN> KungFuJesus, it's like that for quite a while now, and it works great for me [22:07:11 CET] <BtbN> the identical same symbol exported by multiple libs isn't usually an issue [22:07:24 CET] <BtbN> (Also, the file you linked has no functions) [22:08:41 CET] <BtbN> That functions probably should not be exported in the first place though [22:32:46 CET] <Skandalist> Hello. I have audio stream with length 1330 sec and video stream with length 1594. Is it possible to change video tempo to make it equal to audio? (As an opposite operation of changing audio tempo faster in Audacity) [22:32:49 CET] <Skandalist> & [22:32:50 CET] <Skandalist> ? [22:33:30 CET] <Skandalist> I've found this in man: "With -map you can select from which stream the timestamps should be taken. You can leave either video or audio unchanged and sync the remaining stream(s) to the unchanged one." [22:34:42 CET] <KungFuJesus> I'm on gcc 7 if that matters [22:35:11 CET] <KungFuJesus> it seems that at least for my build, libavcodec tries to use code from the static archive in libavutil [22:35:14 CET] <Skandalist> and tried "-map 0:0,1:0" from advanced options [22:35:29 CET] <Skandalist> with no luck [22:35:43 CET] <KungFuJesus> perhaps it's because my distro moved to force pie on gcc by default and relocations are an issue? [22:40:35 CET] <BtbN> Specially on a static build, the linker should just eliminate the duplicate symbol [22:40:45 CET] <BtbN> make sure you are doing a clean build [22:41:11 CET] <BtbN> Though I agree that it should be fixed [23:06:09 CET] <wfbarksdale> hey folks, i'm wondering if there is any downside to using a flicks timebase (1 / 705600000) when writing an mp4 with ffmpeg? [23:12:21 CET] <JEEB> wfbarksdale: your PTS values can get awfully high quickly mostly [23:16:52 CET] <wfbarksdale> hmm, indeed [00:00:00 CET] --- Sat Feb 9 2019

1 0