September 2018 - Ffmpeg-devel-irc

ffmpeg-devel.log.20180929
by burek 30 Sep '18

30 Sep '18

[11:52:39 CEST] <durandal_1707> michaelni: stop playing with high voltages, please! [11:54:47 CEST] <michaelni> lol [12:37:56 CEST] <durandal_1707> michaelni: please ban Compn from this channel and strip him from his powers, as he is actively ignoring my requests [12:42:41 CEST] <iive> lol [12:45:49 CEST] <durandal_1707> iive: what's so funny? [12:48:12 CEST] <iive> that you just wrote makes no sense. I thought you are joking. [12:53:02 CEST] <durandal_1707> iive: perhaps english is not your native language? [12:53:48 CEST] <iive> it's not yours either. [12:55:09 CEST] <iive> maybe you can explain better what "actively ignoring" is. and also why it requires such sever punishment. [12:55:53 CEST] <durandal_1707> iive: Compn is ignoring my requests all the time, he is extremly passive and never replies when asked something [12:58:40 CEST] <iive> durandal_1707, is he your personal slave, that is obligated to grant every wish of yours? [12:59:35 CEST] <iive> at the moment you make it. [13:06:41 CEST] <durandal_1707> iive: i will not tolerate that way of interpretation of my words [13:07:47 CEST] <iive> and if your current request is representative for the nature of your other request, then ignoring them is the least confrontational course of action. [13:08:42 CEST] <iive> you can see how agitated you become, when your request is questioned. [13:08:59 CEST] <durandal_1707> iive: he can cleary say so: sorry folk, but i'm not going to do it [13:09:05 CEST] <iive> I'm still waiting for your explanation for "avtively ignoring". [13:11:50 CEST] <durandal_1707> iive: i asked him long ago about various things, including about new samples he claim to have and about updating codecs.conf, he apparenly more like to update wiki entries with codecs that noone use that updating mplayer code [13:14:27 CEST] <iive> and... ? [13:15:03 CEST] <durandal_1707> iive: he is ignoring me, and he does not even reply to benign questions [13:19:11 CEST] <iive> and? [13:19:55 CEST] <durandal_1707> iive: he is ignoring me, and he does not even reply to benign questions [13:23:12 CEST] <iive> ok, he ignores, you. how do you know he is _actively_ ignoring you? [13:24:12 CEST] <BBB> you guys know irc has an /ignore option, right? [13:27:19 CEST] <JEEB> most clients, yes [13:27:33 CEST] <JEEB> anyways, durandal_1707 just calm down and go have a nice cup of tea or something. [13:29:18 CEST] <kierank> durandal_1707: i would suggest putting compn and iive on ignore [13:30:56 CEST] <iive> yeh, because this is really mature kierank. [14:12:43 CEST] <Compn> durandal_1707 : i am collecting samples now [14:13:44 CEST] <Compn> durandal_1707 : its on my todo list to harmonize the ffmpeg codecs with mplayer (and vlc) [14:16:45 CEST] <Compn> just been busy. working full time, caretaking for disabled full time, moving out of my house and trying to buy/build a house at the same time... [14:16:46 CEST] <Compn> busy busy [14:17:07 CEST] <Compn> rest assured durandal_1707 , i am not ignoring you :) [17:10:09 CEST] <j-b> Compn: you did not come to VDD :'( [17:10:19 CEST] <j-b> Compn: but you already knew the place... [17:43:27 CEST] <kurosu> j-b, about the statement of ffhevc vs openhevc over #dav1d, how long ago was that? [17:43:45 CEST] <kurosu> I suspect this might have been before libav/sasshka idcts were added [17:45:12 CEST] <j-b> kurosu: don't remember, I could check [17:45:37 CEST] <j-b> kurosu: the fact is still that there are files that openhevc can decode and libavcodec cannot [17:45:47 CEST] <kurosu> that I didn't know [17:46:34 CEST] <j-b> Ateme complains about it every IBC/NAB [17:46:47 CEST] <kurosu> since mraulet left (which is when this happened), the ones maintaining it were totally disconnected from ffmpeg [17:47:26 CEST] <j-b> we talked about that on thursday with mraulet [17:47:27 CEST] <kurosu> Ateme complaining about *this* is somewhat ironical [17:47:55 CEST] <j-b> I agree :) [17:48:27 CEST] <j-b> but they are a broadcasting company, they are not always logical. [17:48:40 CEST] <kurosu> anyway, yeah, that's the state of hevc decoding, but it brought this on itself (no funding, too much licensing) [17:48:53 CEST] <j-b> +100 on that [17:49:03 CEST] <j-b> let's hope AV1 does not suffer the same fate. [17:49:46 CEST] <j-b> and let's hope AV1 does not suffer the VP9 fate, either... [17:49:50 CEST] <kurosu> the thing is, likely, h/w decoders come quite quicker and make s/w decoders less interesting - AV1 does have that part of the starting point [17:50:28 CEST] <kurosu> I expect people to be less wary of a format that do seem to have some background/support/ecosystem [17:50:37 CEST] <kurosu> *does seem [17:50:56 CEST] <kurosu> vp9 was basically only google, which didn't care about broadcast, live encoding etc [17:51:25 CEST] <kurosu> (or not enough, not blaming, just expressing the level of support) [17:55:47 CEST] <j-b> agreed [17:56:08 CEST] <j-b> av1 will have live encode, TS mappings for broadcast [17:57:19 CEST] <j-b> also vp9 did not really have a spec [18:06:59 CEST] <JEEB> yup [18:07:06 CEST] <JEEB> until very late into its lifetime [18:07:57 CEST] <JEEB> and yea, openhevc has some features and they IIRC tried to add stuff like WPP [18:08:03 CEST] <JEEB> threading wise [18:08:08 CEST] <j-b> so maybe av1 will be better than vp9 [18:08:31 CEST] <JEEB> yea, actual spec from day1 and container mappings should get people more interested [18:09:32 CEST] <j-b> and more companies than just google [18:09:59 CEST] <kurosu> iirc, wpp threading is in ffhevc already [18:10:11 CEST] <kurosu> use thread type slice for it [18:10:18 CEST] <JEEB> oh [18:10:22 CEST] <kurosu> what they have is multiple types of threading at a time [18:10:24 CEST] <JEEB> so it just doesn't use them together [18:10:25 CEST] <JEEB> right [18:10:44 CEST] <kurosu> but I guess API and arch experts have a lot to say about their implementation and how to go about it [18:11:07 CEST] <kurosu> yeah, threading types are mutually exclusive [18:11:37 CEST] <JEEB> also man, what a Saturday. Debugging ALSA audio output :D [18:11:39 CEST] <j-b> my point was: forking too early is not a good idea. [18:11:47 CEST] <kurosu> regular slice-threading is indeed troublesome to combine with framethreading: the progress there can't be explited [18:11:47 CEST] <j-b> JEEB: ALSA? you like pain? [18:12:13 CEST] <JEEB> j-b: at least it seems like this is 100% on "my" code's turf [18:12:15 CEST] <JEEB> not ALSA [18:12:19 CEST] <JEEB> although I've heard battle storeis [18:12:21 CEST] <JEEB> *stories [18:12:44 CEST] <BBB> tile threading + frame threading works, though [18:13:06 CEST] <BBB> and I think in hevc it (tile+frame or wpp+frame, or even all 3) should work better than for av1/vp9, in theory [18:13:16 CEST] <BBB> because you dont have the cross-frame entropy state dependency [18:13:23 CEST] <JEEB> yea [18:13:31 CEST] <JEEB> you just wait until a row has gotten far enough with WPP [18:13:35 CEST] <JEEB> and then start the next one [18:13:41 CEST] <jamrial> <@j-b> my point was: forking too early is not a good idea. [18:13:42 CEST] <jamrial> +1 [18:13:47 CEST] <jamrial> that's why i wrote the wrapper [18:13:49 CEST] <JEEB> yup [18:14:02 CEST] <j-b> hwaccel will come in 1,5y at best. [18:14:05 CEST] <jamrial> so people can use dav1d with ffmpeg, until dav1d is *in* ffmpeg [18:14:14 CEST] <j-b> and dav1d will be roughly finished in 6months [18:14:27 CEST] <BBB> 10bit asm may take longer [18:14:30 CEST] <BBB> 12bit also [18:14:35 CEST] <j-b> 12bit... lol [18:14:38 CEST] <j-b> sorry [18:14:43 CEST] <BBB> :D [18:14:44 CEST] <j-b> still (lol) [18:15:03 CEST] <BBB> someone will ask for it at some point [18:15:08 CEST] <j-b> ofc [18:15:25 CEST] <jamrial> the human eye can only see 255 shades of rgb anyway [18:15:28 CEST] <jamrial> /s [18:15:46 CEST] <j-b> 10bits+HDR is great [18:15:56 CEST] <kurosu> I think this is the point [18:16:26 CEST] <kurosu> hevc might not have got a hold if there wasn't that [18:16:45 CEST] <JEEB> it was a mix of HW implementations only having 10bit for HEVC [18:16:57 CEST] <JEEB> the AVC ASICs were left alone [18:17:29 CEST] <BBB> ePirat: !97 sounds great, any reason to hold it back? [18:17:36 CEST] <BBB> oops [18:17:53 CEST] <kurosu> BBB: tile and wpp in hevc are mutually exclusive for $reasons [18:18:08 CEST] <kurosu> except I think some Apple profiles [18:18:46 CEST] <BBB> oh, right, youdid mention that [18:18:48 CEST] <BBB> sorry [18:18:51 CEST] <kurosu> np [18:19:04 CEST] <BBB> I guess 2 of them together is enough parallelism [18:19:08 CEST] <BBB> at least for now [18:19:13 CEST] <BBB> maybe in 266 you can do all 3 together [18:19:20 CEST] <kurosu> I have to admit the tile is of course doable (that's in dav1d) but as I said, that whole "filter across tiles" is such a bother [18:19:34 CEST] <nevcairiel> 266 seems to get rid of wpp again [18:19:49 CEST] <BBB> yes, filter-across-tiles does make it a little annoying [18:19:51 CEST] <BBB> brb [18:20:14 CEST] <kurosu> or said otherwise: Samsung seems unhappy about its share of the cake, and want to throw everyone's else plates [18:20:49 CEST] <j-b> for hevc? [18:20:54 CEST] <kurosu> for h266 [18:20:57 CEST] <j-b> oh yes [18:20:59 CEST] <j-b> WC [18:21:35 CEST] <kurosu> well, formerly JEM, which had French laughing because again, weird meaning [18:21:53 CEST] <JEEB> :D [18:22:07 CEST] <durandal_1707> what JEM means in french? [18:22:10 CEST] <j-b> VVC looks like WC, and that is valid in numerous countries [18:22:17 CEST] <kurosu> "I like"/"I love" [18:22:22 CEST] <j-b> including UK/US [18:22:26 CEST] <j-b> It's idiotic [18:22:30 CEST] <j-b> FVC was fine [18:22:32 CEST] <kurosu> really? so "restroom" is just US ? [18:22:48 CEST] <j-b> https://en.wikipedia.org/wiki/WC [18:22:51 CEST] <kurosu> Versatile VC to go on Digital Versatile Disc maybe ? [18:23:08 CEST] <JEEB> :D [18:23:32 CEST] <j-b> BVC Big Video Coding [18:23:40 CEST] <j-b> or Bigly [18:23:49 CEST] <j-b> DVC Dantesque [18:24:22 CEST] <j-b> kurosu: https://aomedia.org/membership/members/ Samsung is absent, weirdly. [18:24:42 CEST] <kurosu> j-b, "weirdly" ? [18:25:00 CEST] <j-b> :D [18:25:28 CEST] <kurosu> ah ah, and for some reason mpeg la is unreachable here [18:26:10 CEST] <kurosu> well, suffice to say Samsung has like 40% of patents in mpeg-la *and* hevc advance (but not the 3rd and 4th and 5th and...) [18:49:46 CEST] <kurosu> https://aomedia.org/membership/members/ <- didn't notice the arrival of alibaba [18:51:24 CEST] <j-b> last week [19:00:36 CEST] <j-b> durandal_1707: did you get the money, btw? [19:04:36 CEST] <durandal_1707> j-b: yes [19:04:40 CEST] <j-b> cool. [19:04:59 CEST] Action: durandal_1707 wants more! [19:07:15 CEST] <j-b> sure [19:07:19 CEST] <j-b> bounties getting updated [19:07:41 CEST] <JEEB> nice [19:40:46 CEST] <jamrial> j-b: did you have time for mine? [20:08:33 CEST] <j-b> jamrial: yours? [20:08:47 CEST] <jamrial> money transfer [20:09:45 CEST] <j-b> still waiting for AOM. should be this week. [20:09:58 CEST] <jamrial> ah good [20:11:01 CEST] <jamrial> please let me know when you do [20:15:02 CEST] <j-b> sure [20:35:05 CEST] <crysna> Hello all! Any pointers on contributing to ffmpeg? [20:36:48 CEST] <kierank> crysna: find something interesting to work on I guess [20:36:58 CEST] <kierank> the small tasks page isn't really that good imho [20:37:49 CEST] <nevcairiel> the problem with that is that it often takes an experienced developer longer to even remember that this page exists then do most of those tasks =p [20:50:10 CEST] <JEEB> yea [20:53:29 CEST] <kierank> should have discussed it at vdd [21:06:37 CEST] <JEEB> yea, we don't have small "pet peeves" noted anywhere I think [21:06:46 CEST] <JEEB> which is why I end up mostly telling people to poke something that's broken for them [21:06:55 CEST] <JEEB> which doesn't always work [22:45:55 CEST] <J_Darnley> "do something you care about" is always good advice [22:46:19 CEST] <J_Darnley> it usually means you want to see it finished [00:00:00 CEST] --- Sun Sep 30 2018

1 0

ffmpeg.log.20180929
by burek 30 Sep '18

30 Sep '18

[01:40:23 CEST] <blue_misfit> hey remind me - if I want to specify options to the http protocol handler assuming I have http input, how do I do that? [01:40:35 CEST] <blue_misfit> e.g. I want to specify http_version=1.1 [05:54:39 CEST] <horohoro55> Hello, what is moov atom ? [06:00:22 CEST] <furq> it's a header in an mp4/mov that contains the file details [06:01:27 CEST] <horohoro55> Is it's bitlength fixed ? [06:01:37 CEST] <horohoro55> (meaning can I just copy it from another file ^^) [06:02:18 CEST] <horohoro55> (I am trying to repair AVC MOV video files) [06:05:01 CEST] <furq> no, but if you have a working file from the same device then it might be [06:06:36 CEST] <horohoro55> yes that's the idea [06:06:50 CEST] <horohoro55> I have a corrupted file and a not corrupted file from the same device [06:07:23 CEST] <furq> http://vpaste.net/gCBKv [06:07:29 CEST] <furq> that's the sort of thing it actually contains [06:07:31 CEST] <horohoro55> I have tried using untrunc but it tells me "Failed to parse atoms in truncated file". Search on the issue and a guy told to copy the 20 first byts of the header to make it work [06:07:43 CEST] <furq> obviously stuff like stsc and stco are variable length [06:07:45 CEST] <horohoro55> tried, didn't work :/ [06:08:19 CEST] <furq> you probably want to use something like boxdumper on a working file and see what the next atom in the file is [06:08:37 CEST] <furq> and then just zero everything up to that and try copying the one you have in there [06:08:55 CEST] <furq> https://github.com/l-smash/l-smash [06:08:57 CEST] <furq> boxdumper from here [06:14:47 CEST] <horohoro55> I insert [moov: Movie Box] into my corrupted file ? [06:16:13 CEST] <furq> i've never done it so idk how it works in detail, but moov is the thing your corrupt file is missing [06:16:28 CEST] <furq> i'm not sure what you'd do with the variable length fields [06:16:42 CEST] <furq> and obviously the duration and stuff will probably be wrong [06:16:46 CEST] <horohoro55> [moov: Movie Box] position = 251428872. So I insert everything after bit 251428872 into my file ... hum [06:16:48 CEST] <horohoro55> what is frea ? [06:16:58 CEST] <horohoro55> [frea] [06:16:58 CEST] <horohoro55> position = 24 [06:16:58 CEST] <horohoro55> size = 234260 [06:17:26 CEST] <horohoro55> I guess mdat is what I am interested in (the actual video) [06:17:53 CEST] <furq> yeah [06:17:59 CEST] <furq> frea is apparently just some kodak metadata [06:18:41 CEST] <horohoro55> Ok let's try to do something like that [06:19:06 CEST] <furq> if the moov atom is at the end of the file then hopefully that'll be a bit easier [06:19:31 CEST] <furq> you might just be able to copy the whole thing across [06:20:41 CEST] <horohoro55> let's try adding the header first [06:20:54 CEST] <horohoro55> The position of boxdumper are in bytes or bit ? [06:21:43 CEST] <horohoro55> bytes I guess [06:23:31 CEST] <furq> yeah it must be bytes [06:35:45 CEST] <horohoro55> I copied everything from:[moov: Movie Box] [06:35:46 CEST] <horohoro55> position = 251428872 [06:35:48 CEST] <horohoro55> but same issue [06:36:09 CEST] <horohoro55> ffmpeg is still unable to find moov. Is the position of the moov indicated in the header ? [06:36:34 CEST] <horohoro55> (by the way isn't it stupid to have it in the footer, how does a player do while preview if information are in the footer) [09:34:32 CEST] <keglevich> hey all... I'm using the following command for UDP streaming: [09:34:39 CEST] <keglevich> ffmpeg -re -i 1.mp4 -c:v libx264 -g 50 -pix_fmt yuv420p -x264opts nal-hrd=cbr -preset veryfast -b:v 2200k -minrate 2200k -maxrate 2200k -bufsize 260k -muxrate 2600k -pcr_period 30 -c:a mp2 -b:a 192k -ac 2 -ar 48000 -f mpegts "udp://239.2.2.2:10000?pkt_size=1316&bitrate=2600000" [09:34:49 CEST] <keglevich> The command works flawlessly on i5 or i7 CPU's... but I have issues on i3 (i3-8100) CPU's... it always crashes with fatal error "av_interleaved_write_frame(): Cannot allocate memory" and "Error writing trailer of udp://239.2.2.2:10000?pkt_size=1316&bitrate=2600000: Cannot allocate memory" ... the CPU is running at around 30% stable, but crashes anyway... I'm wondering why this is happening... why on i5 or i7 runs ok...but lower en [09:35:34 CEST] <keglevich> Also, I'm using "pthreads" ffmpeg version with it....with standard w32threads version, it works just fine all the time [09:35:53 CEST] <keglevich> I guess it has to be something with pthreads multithreading on weaker CPU's, but I don't know how to solve it [09:37:18 CEST] <ChocolateArmpits> keglevich, did you test same binary with all 3 systems? [09:37:34 CEST] <keglevich> yes [09:38:02 CEST] <keglevich> on all 6-core CPU's works flawlessly..even with 3 or 4 simultaneous streams [09:38:28 CEST] <keglevich> on 4-core cheaper CPU's it uses about 30% of CPU, but it just crashes randomly after 10mins or so [09:39:22 CEST] <keglevich> if I add "fifo_size=1000000" to UDP output, it's a bit better, but I guess that's not even right as fifo_size is input parameter if I'm not mistaken [09:39:29 CEST] <keglevich> but it uses more memory definitely [09:39:43 CEST] <keglevich> so (in some way) it works [09:40:42 CEST] <keglevich> as far as I know pthreads uses a separate trhead for packet UDP sending, so I believe the overflow happens there...it has to be something in these low-end CPU's that's not fast enough [09:42:40 CEST] <ChocolateArmpits> keglevich, did you try streaming to localhost? [09:42:53 CEST] <ChocolateArmpits> just in case this is something in the network configuration [09:44:41 CEST] <keglevich> hmm, I don't believe it's a network config error as I tried on three different motherboards with either i3-8100 or i5-2400 CPU's...different NIC's, etc... [09:44:57 CEST] <keglevich> but ok, I can set it up to 127.0.0.1:10000 just to be sure [09:46:03 CEST] <keglevich> it's already running, we'll see [09:46:54 CEST] <keglevich> I simply believe that one single trhead (pthreads streaming) does overflow on weaker CPU's [09:50:28 CEST] <jkqxz> "Cannot allocate memory" means that you're out of memory, not CPU. Does that machine have less available memory than the others you tested? [09:52:17 CEST] <keglevich> all machines have 8GB of memory... but memory shouldn't be an issue, I'm using 32-bit ffmpeg as well which can consume max 2GB of memory if I'm not mistaken...also memory usage never goes over 400MB or so in task manager [09:53:22 CEST] <keglevich> also...streaming to localhost also crached after 5mins a few moments ago...same error [09:56:42 CEST] <jkqxz> Try the 64-bit version, I guess. Or run in a debugger and find the first allocation call which fails? [09:57:56 CEST] <ChocolateArmpits> keglevich, maybe this has something to do with the bitrate parameter in the address and pthreads as you say? if the mux bitrate overshoots then maybe the thread implementation can't account for that properly. Just guessing [09:59:58 CEST] <keglevich> ChocolateArmpits, that's probably true...without bitrate parameter (w32threads version) doesn't crash on weaker CPU's... [10:00:22 CEST] <keglevich> but I need to use bitrate parameter to get as clean as possible CBR output [10:00:38 CEST] <keglevich> if there's an option to do proper CBR without bitrate paramater...I'm all ears [10:00:46 CEST] <ChocolateArmpits> keglevich, why not simply increase it? I guess it must pad the output anyways, no? [10:01:11 CEST] <keglevich> I tried that as well...insreasing it for 10%, 20% or even more...same results [10:12:15 CEST] <keglevich> is there maybe another option to get clear perfect CBR output without pthreads ffmpeg version and without using output bitrate UDP parameter? [10:12:23 CEST] <keglevich> cause I havent' found it yet... [19:41:28 CEST] <fl1pside555> a [19:43:52 CEST] <fl1pside555> Hi, I have a blu-ray rip. I want to downmix all of the tracks to stereo. The command I'm using results in just a single audio track in the output. I think I need to use the map command, but I'm not sure how to specify all audio tracks. This is the command I'm using. [19:44:04 CEST] <fl1pside555> ffmpeg -i INPUT -c:v copy -af "pan=stereo|FL < 1.0*FL + 0.707*FC + 0.707*BL|FR < 1.0*FR + 0.707*FC + 0.707*BR" OUPUT [19:45:43 CEST] <JEEB> -map 0:a [19:45:50 CEST] <JEEB> maps all audio tracks [19:46:08 CEST] <JEEB> also I'm pretty sure you can downmix by just telling the filter chain that you want stereo [19:46:16 CEST] <JEEB> unless you need some special downmixing that's not standar [19:46:17 CEST] <JEEB> d [19:48:17 CEST] <JEEB> aformat=channel_layouts=stereo [19:48:18 CEST] <JEEB> I think [19:48:36 CEST] <furq> iirc -ac 2 is aresample=ocl=stereo [19:48:53 CEST] <furq> you probably just want to use -ac 2 if you need multiple audio tracks [19:49:07 CEST] <JEEB> uhh, you should never recommend -ac [19:49:12 CEST] <fl1pside555> That command was one I came across on the web. It was a thread where a few people were discussing the best way to do it. [19:49:13 CEST] <JEEB> it gets confusing for anything over 2 [19:49:21 CEST] <furq> this is 2 though so it's fine [19:49:28 CEST] <JEEB> and it's better to have people say "I want stereo" [19:49:29 CEST] <furq> and it saves having to use lavfi and filter every audio track [19:49:34 CEST] <furq> -lavfi rather [19:49:46 CEST] <JEEB> umm, doesn't it work with just -af ? [19:49:57 CEST] <JEEB> aformat=channel_layouts=stereo [19:50:09 CEST] <JEEB> or aresample=ocl=stereo [19:50:42 CEST] <JEEB> furq: the problem with using channel counts at all is that you are setting a precedent. so that the next time someone is looking for 5.1 they will say 6 instead of "5.1" [19:50:47 CEST] <fl1pside555> This is the thread [19:50:48 CEST] <fl1pside555> https://superuser.com/questions/852400/properly-downmix-5-1-to-stereo-using… [19:50:59 CEST] <JEEB> fling: by default FFmpeg should downmix correctly [19:51:06 CEST] <JEEB> as long as you tell it you want stereo [19:51:11 CEST] <furq> -af only has a single output [19:51:21 CEST] <JEEB> yes but doesn't that apply to all mapped tracks? [19:51:22 CEST] <fl1pside555> So, what would the command be? [19:51:25 CEST] <furq> not as far as i can tell [19:51:32 CEST] <JEEB> ok, then I remember incorrectly [19:51:33 CEST] <furq> unless i've been using it wrong [19:51:56 CEST] <JEEB> I think it was when you wanted multiple outputs or something you started having issues with -af/-vf [19:52:25 CEST] <furq> i just tried it [19:52:26 CEST] <furq> http://vpaste.net/jv2LE [19:52:42 CEST] <furq> -map 0:a just outputs 0:0 [19:52:47 CEST] <JEEB> umm [19:53:01 CEST] <JEEB> that's because you have >1 inputs [19:53:16 CEST] <furq> oh yeah duh [19:53:18 CEST] <JEEB> you're trying to map audio tracks 0,1 from input 0 [19:53:33 CEST] <furq> ignore everything i said then [19:54:01 CEST] <JEEB> fl1pside555: -af aresample=ocl=stereo or -af aformat=channel_layouts=stereo [19:54:16 CEST] <JEEB> that should give you teh standard specified way of downmixing to stereo [19:54:37 CEST] <JEEB> the only reason you shouldn't be using that is if you knowingly want to pick something that is not the standard, specified way of downmixing content [19:55:01 CEST] <JEEB> the simplest case of this is that since stereo doesn't have an LFE channel, all LFE will be discard according to the specification [19:55:10 CEST] <JEEB> so some people like to have LFE in non-LFE mixes :P [19:55:35 CEST] <fl1pside555> That's what the discussion in the thread was about. They were tweaking the level of dialogue against the SFX, music, etc. [19:56:09 CEST] <fl1pside555> That's why they came up with that filter (or whatever it is!) [19:56:18 CEST] <JEEB> that's separate from just downmixing you know :P [19:56:29 CEST] <JEEB> there's one way of doing dowmixing correctly [19:56:33 CEST] <JEEB> (according to specification) [19:56:44 CEST] <JEEB> and then if you want to tweak it, that's a whole separate discussion [19:56:54 CEST] <JEEB> I know that you might want to do loudness normalization for example [19:56:57 CEST] <furq> i'm pretty sure those values you pasted are the atsc standard values [19:57:05 CEST] <furq> which is what ffmpeg defaults to iirc [19:57:24 CEST] <JEEB> I wouldn't be surprised if ATSC actually copied them from whatever else there is which is what FFmpeg used [19:57:34 CEST] <fl1pside555> So, if wanted to play about with the versions in that thread, what command would I use to apply it to all of the audio tracks? [19:57:46 CEST] <furq> just add -map 0:a [19:58:03 CEST] <JEEB> but yea, the nr1 thing that people want is loudness normalization usually after 5.1->stereo downmix [19:58:14 CEST] <JEEB> since 5.1 mixes tend to have a large difference in volume between those [19:58:42 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#loudnorm [19:58:59 CEST] <JEEB> I think you'd do this after you downmix, I think? [19:59:08 CEST] <fl1pside555> ffmpeg -i INPUT -c:v -map 0:a copy -af "pan=stereo|FL < 1.0*FL + 0.707*FC + 0.707*BL|FR < 1.0*FR + 0.707*FC + 0.707*BR" [19:59:14 CEST] <fl1pside555> Like that> [19:59:27 CEST] <JEEB> -c:v copy becamse -c:v -map ... :P [19:59:30 CEST] <JEEB> *became [19:59:37 CEST] <JEEB> but otherwise yes [19:59:43 CEST] <JEEB> it has to be after input, that's all [19:59:55 CEST] <JEEB> (and before the output) [20:01:02 CEST] <fl1pside555> ffmpeg -i INPUT -c:v copy -map 0:a -af "pan=stereo|FL < 1.0*FL + 0.707*FC + 0.707*BL|FR < 1.0*FR + 0.707*FC + 0.707*BR" [20:01:16 CEST] <JEEB> yup [20:01:26 CEST] <JEEB> that map is basically "map all audio track(s) from input 0" [20:01:54 CEST] <fl1pside555> Gotcha. I understand the syntax now. [20:02:23 CEST] <fl1pside555> Thanks a lot. I'll give them a try and see if I notice much difference between the standard one, and the one they came up with in the thread. [20:24:01 CEST] <keglevich> ffmpeg -re -i 1.mp4 -c:v libx264 -g 50 -pix_fmt yuv420p -x264opts nal-hrd=cbr -b:v 2200k -minrate 2200k -maxrate 2200k -bufsize 260k -muxrate 2600k -pcr_period 30 -c:a mp2 -b:a 192k -ac 2 -ar 48000 -f mpegts "udp://239.1.1.1:10000?pkt_size=1316" [20:24:39 CEST] <keglevich> this command should produce perfect mpegts UDP CBR, but it isn't near real CBR... can someone suggest what to do to improve it? [22:21:06 CEST] <GuiToris> hello, what audio container file can I use, if I'd like to extract audio from a video and mediainfo says : Format AC-3 [22:21:09 CEST] <GuiToris> acc? [22:21:16 CEST] <GuiToris> I mean aac [22:21:21 CEST] <furq> aac is a codec [22:21:28 CEST] <furq> you can mux ac3 into m4a [22:21:50 CEST] <furq> or you can just extract the raw bitstream and then put an id3 tag on it like an absolute monster [22:21:54 CEST] <furq> (lots of people do this for some reason) [22:22:32 CEST] <Mavrik> And then get A/V sync messed up? :D [22:22:33 CEST] <Shibe> Hi, I created this library that allows me to easily encode dmabufs, I was hoping someone could review it and point out if I'm doing something wrong/incorrect? https://hastebin.com/raw/zujeberiki [22:22:44 CEST] <furq> Mavrik: this is just for listening to it [22:23:04 CEST] <GuiToris> furq, for f in *.MTS; do ffmpeg -i "$f" -vn -acodec copy ${f%.*}.m4a; done is this reasonable? [22:23:17 CEST] <furq> sure but you probably want to select tracks explicitly [22:23:24 CEST] <furq> presumably -map 0:a:0 instead of -vn [22:24:26 CEST] <GuiToris> video, audio and subtitle? [22:24:46 CEST] <keglevich> ffmpeg -re -i 1.mp4 -c:v libx264 -g 50 -pix_fmt yuv420p -x264opts nal-hrd=cbr -b:v 2200k -minrate 2200k -maxrate 2200k -bufsize 260k -muxrate 2600k -pcr_period 30 -c:a mp2 -b:a 192k -ac 2 -ar 48000 -f mpegts "udp://239.1.1.1:10000?pkt_size=1316" [22:24:50 CEST] <keglevich> this command should produce perfect mpegts UDP CBR, but it isn't near real CBR... can someone suggest what to do to improve it? [22:24:58 CEST] <GuiToris> thanks furq [22:27:05 CEST] <Mavrik> keglevich, there's no such thing as perfect CBR in video [22:27:14 CEST] <Mavrik> and ffmpeg isn't optimized for that use-case at all [22:27:31 CEST] <Mavrik> so if you need that insanity you just wrote up there you'll have to buy some pro equipment [22:28:11 CEST] <keglevich> Mavrik: that insanity is needed by our partner fr DVB-T set-top-boxes [22:28:21 CEST] <Mavrik> Indeed. [22:28:31 CEST] <keglevich> it's either we do this with ffmpeg (if it can be done) or as you said...we buy expensivce equpiment [22:28:31 CEST] <Mavrik> Yeah, we tried to use ffmpeg for DVB-C. [22:28:37 CEST] <Mavrik> Report if you find a miracle :P [22:28:43 CEST] <keglevich> and I came really close with ffmpeg already [22:28:51 CEST] <Mavrik> But PCR generation is utterly broken (or was a bit ago) and we had to go back to cisco boxes [22:29:02 CEST] <Mavrik> If you manage to fix it, let me know. [22:29:26 CEST] <keglevich> PCR generation seem to work fine in conjunction with pcr_period and muxrate [22:29:33 CEST] <Mavrik> But IIRC the main issue is that mpegts muxer from ffmpeg just makes up PCR in a way that makes any kind of DVB ingester choke [22:29:53 CEST] <keglevich> also...near perfect CBR stream can be done using "pthreads" ffmpeg and output UDP parameter "bitrate" [22:30:07 CEST] <keglevich> but...pthreads in really unstable from what I've seen so far [22:30:24 CEST] <JEEB> it's definitely not perfect [22:30:33 CEST] <JEEB> improvements are welcome [22:30:38 CEST] <keglevich> and we experience random crashes...therefore I'd like to go ahead with w32threads version and find similar solution as we did with ptrheads [22:30:49 CEST] <Mavrik> There were some reports that OBS can do it better with different MPEG-TS muxer, but I've never tested it. [22:31:01 CEST] <keglevich> OBS is shit...simply [22:31:05 CEST] <JEEB> OBE you mean? [22:31:12 CEST] <JEEB> OBS is the gamer thing [22:31:28 CEST] <keglevich> yes...OBS can't even accept various ffmpeg parameters [22:31:43 CEST] <keglevich> and does only progressive output...so no go [22:31:44 CEST] <Mavrik> OBE or whatever yeah [22:32:24 CEST] <keglevich> JEEB: would you maybe have some suggestion how to improve stability with pthreads version of ffmpeg? [22:32:32 CEST] <Mavrik> I do have to admit that I didn't waste more than a week trying to get ffmpeg's mpeg-ts muxer under control so I might have missed something obvious. And that was like 2 years ago :/ [22:33:40 CEST] <JEEB> keglevich: I haven't had UDP/MPEG-TS output stuff going too much, might have to dwelve into it again later [22:33:45 CEST] <keglevich> regarding stability with pthreads....it works as far as we use high-class CPU's (i7, i5-8600), and as long as it has enough CPU room left... if we do it on low-class budget CPU.s (for instance i3-8100) it crashes randomly after 10mins or so with "cannot allocate memory" fatal error...even though CPU load is no more than 50% on those cheap CPU's [22:34:05 CEST] <JEEB> keglevich: both on 64bit? [22:34:20 CEST] <keglevich> yes...32bit and 64bit [22:34:47 CEST] <JEEB> try getting a backtrace through gdb or so [22:34:51 CEST] <keglevich> as soon as CPU load is 80% or more, it crashes on all CPU's [22:35:22 CEST] <keglevich> w32threads version never crashes...even if I do 5+ HD streams on single CPU and cpu load is 100% all the time [22:35:45 CEST] <Mavrik> Is both of that on Windows? [22:35:49 CEST] <keglevich> yes [22:38:24 CEST] <keglevich> under 50% CPU load it won't crash...multiple streams with pthreads versions and over 60%+ CPU load... it'll crash randomly.... but when 80%+ CPU load, it'll crash in 3mins or so [22:39:10 CEST] <keglevich> always same error "av_interleaved_frames...cannot allocate memory" or something similar [22:39:45 CEST] <keglevich> "av_interleaved_write_frame(): Cannot allocate memory" and "Error writing trailer of udp://239.2.2.2:10000?pkt_size=1316&bitrate=2600000: Cannot allocate memory" [22:40:11 CEST] <keglevich> memory usage never exceeds 400MB thought [22:40:20 CEST] <keglevich> so it's not memory related I guess [22:50:05 CEST] <furq> is there a standard for the track layout on blu-ray audio discs [22:50:41 CEST] <furq> everything i've seen has been one playlist and then one chapter per track, but idk if that's actually specified anywhere [00:00:00 CEST] --- Sun Sep 30 2018

1 0

ffmpeg-devel.log.20180928
by burek 29 Sep '18

29 Sep '18

[01:29:41 CEST] <cone-400> ffmpeg 03Michael Niedermayer 07master:b90d8cc74663: avcodec/gdv: Replace divisions by shifts in rescale() [01:29:41 CEST] <cone-400> ffmpeg 03Michael Niedermayer 07master:a423970511bc: avcodec/gdv: Factor terms out of inner loops in rescale() [01:29:42 CEST] <cone-400> ffmpeg 03Michael Niedermayer 07master:6228ce0a33c7: avcodec/gdv: Combine first and 3rd case in rescale() [01:29:43 CEST] <cone-400> ffmpeg 03Michael Niedermayer 07master:d021729efc1f: avcodec/gdv: Simplify first inner loop in rescale() [01:29:44 CEST] <cone-400> ffmpeg 03Michael Niedermayer 07master:5f84fbce0876: avcodec/gdv: Eliminate 50% of the reads in the first inner loop in rescale() [01:29:45 CEST] <cone-400> ffmpeg 03Michael Niedermayer 07master:6a4788e7b31a: avcodec/gdv: Replace loop in gdv_decode_frame() by memcpy() [01:29:47 CEST] <cone-400> ffmpeg 03Michael Niedermayer 07master:510bd6194154: avcodec/gdv: Optimize 2x scaling loop a little in gdv_decode_frame() [01:29:47 CEST] <cone-400> ffmpeg 03Michael Niedermayer 07master:35517e3ca7ea: avcodec/gdv: Error out if we had insufficent input for the output frame in decompress_2() [02:16:35 CEST] <cone-400> ffmpeg 03Michael Niedermayer 07master:8db9097308dc: avcodec/bintext: Check input size before allocating the input image [02:16:36 CEST] <cone-400> ffmpeg 03Michael Niedermayer 07master:db6af88cd0fa: avcodec/bintext: Use ff_get_buffer instead of ff_reget_buffer and simplify [02:16:37 CEST] <cone-400> ffmpeg 03Michael Niedermayer 07master:7274d849cc44: avcodec/diracdec: Propagate errors from codeblock() [02:16:38 CEST] <cone-400> ffmpeg 03Michael Niedermayer 07master:179ed2d2e089: avcodec/diracdec: check that GetBitContext has not ended in codeblock() [12:36:34 CEST] <durandal_1707> j-b: please add agm2 to bounty page (Japanese Amaze Graphic codec) [12:54:09 CEST] <durandal_1707> also remove old entries, like fox magic and dxv which are done [12:58:51 CEST] <j-b> durandal_1707: sir, yessir [14:55:05 CEST] <durandal_1707> j-b: are you gonna do it? because I need to know if my reversing time spent on it will be paid [15:06:35 CEST] <durandal_1707> ugh its AmuseGraphics and not AmazeGraphics, sorry for that [16:49:37 CEST] <BBB> -c:v doesnt work in ffplay [18:54:17 CEST] <durandal_1707> j-b: can i get answer? [18:54:43 CEST] <j-b> yes, I read all that [18:54:45 CEST] <j-b> all OK [18:54:47 CEST] <j-b> will update the wiki [18:54:57 CEST] <j-b> very busy atm, because of post-VDD and dav1d [18:55:05 CEST] <j-b> will do eveyrthing during the weekend [19:05:04 CEST] <atomnuker> oh right, the first deadline was in like 2 days [19:06:18 CEST] <jamrial> deadline for what? [19:08:13 CEST] <atomnuker> some minimal viable product? no idea what the contract said, I jut know the dates [19:09:30 CEST] <j-b> project is out, and more or less working [19:09:37 CEST] <j-b> so no care [19:09:55 CEST] <j-b> most of the work is to review MR and check the infra, the gitlab-ci, and so on [19:10:09 CEST] <j-b> we usually don't have this gitlab process [22:11:04 CEST] <kierank> durandal_1707: can you help me fix prores? [22:14:03 CEST] <kierank> J_Darnley: for a personal project, how hard is writing a 12-bit idct? [22:17:20 CEST] <kierank> I doubt prores coefficients are guaranteed to fit in 16-bit [22:19:16 CEST] <J_Darnley> I don't know. [22:19:18 CEST] <J_Darnley> From scratch it is probably quite hard. [22:19:28 CEST] <kierank> I mean the asm for it [22:21:41 CEST] <J_Darnley> Still, I'm not quite sure. [22:21:43 CEST] <J_Darnley> A correct C reference is good. [22:22:27 CEST] <J_Darnley> Still some effort though. [22:23:53 CEST] <J_Darnley> Although if it is supposed to replace the mpegvideo we probably fixed many of the obscure bugs and corner cases when I last worked on it. [22:27:38 CEST] <durandal_1707> kierank: whats broken? [22:35:53 CEST] <kierank> durandal_1707: weird adding 8192 to every dc coeff code [22:36:06 CEST] <kierank> also i don't understand if coeffs guaranteed to fit in int16_t [22:36:20 CEST] <kierank> I guess I can look at reference implementation [22:39:57 CEST] <durandal_1707> kierank: see my prores12 branch [22:40:59 CEST] <kierank> durandal_1707: your code is much more complex than mine [22:41:18 CEST] <kierank> i.e i make it just output 12 by default [22:41:38 CEST] <kierank> and I remove all the extrashift stuff [22:41:47 CEST] <kierank> which is some kind of weird hack iiuc [22:42:43 CEST] <JEEB> the 12->10 thing? [22:43:51 CEST] <kierank> https://github.com/FFmpeg/FFmpeg has stopped syncing [22:47:04 CEST] <kierank> durandal_1707: https://github.com/kierank/FFmpeg/tree/prores12 [23:03:42 CEST] <durandal_1707> kierank: does reference use 8192/offset ? [23:03:53 CEST] <kierank> haven't looked [23:04:18 CEST] <kierank> 8192 would need int32_t though [23:07:25 CEST] <durandal_1707> it doesnt, something stinks badly [00:00:00 CEST] --- Sat Sep 29 2018

1 0

ffmpeg.log.20180928
by burek 29 Sep '18

29 Sep '18

[02:37:48 CEST] <Highdude> is anyone around? I cant get openwrt to compile i keep getting an error related to ffmpeg(idk why it needs it but apparently base system does) https://pastebin.com/NJzS386X this is the error i get. this is the config.log for the ffmpeg folder. even exported the path shine.pc is in https://pastebin.com/wMhKTf9Z and still got the same error. [02:38:25 CEST] <Highdude> sorry here is the config.log https://pastebin.com/BxNR7X94 [02:38:31 CEST] <Highdude> guess i forgot to insert that [02:57:28 CEST] <furq> Highdude: you need to cross-compile libshine with the same toolchain [03:32:23 CEST] <Highdude> furq Thanks. Sounds horrific lol. or better put not worth the time [03:33:32 CEST] <Highdude> but thank you for the insight. with the help of you and some people in #openwrt i realized im a moron and need to approach this differently [03:34:39 CEST] <furq> i have no idea why they'd make that part of the base system [03:36:15 CEST] <furq> normally on debian/ubuntu or other multiarch distros you could just install the mipsel package [03:36:30 CEST] <furq> but if openwrt is using musl then that's not happening [03:37:18 CEST] <Highdude> i dont think its part of the base system [03:37:33 CEST] <Highdude> i think i was too high and or drunk to understand that i was fucking up [03:37:43 CEST] <furq> that makes more sense [03:37:59 CEST] <Highdude> cause i went through and started from fresh config and selectd only what i needed and its going good [03:38:13 CEST] <Highdude> as i said, operator was a moron so shit got fuckey :) [03:38:22 CEST] <Highdude> but thank you for helping me see that [05:53:24 CEST] <johnjay> hmm, i'm kinda confused by the format codes i'm getting from vimeo [05:53:50 CEST] <johnjay> can the same res have radically different bitrates? [05:54:13 CEST] <johnjay> like this one that says https-360 is about half the size of another one that's labeled 640x360 for the same vid [07:12:51 CEST] <kepstin> johnjay: resolution and bitrate can be varied completely independently [07:13:56 CEST] <kepstin> the resulting quality of the video depends on resolution, bitrate, and video contents [07:18:59 CEST] <johnjay> kepstin: right [12:08:18 CEST] <atbd> hi, i'm currently transcoding a subpart of a video using ffmpeg api. It plays well but I have issues with printed timestamp on VLC. For example the video starts at 26:30:00 to finish at 26:31:00. I tried to informed duration & start_time in AVStream before av_write_trailer and closing it all but without success. Someone can help me to fix it? [12:40:38 CEST] <Mavrik> atbd: VLC is looking at PTS to show those values [12:40:46 CEST] <Mavrik> So you'd have to start near 0 [13:07:14 CEST] <keglevich> hey all... I'm using the following command for UDP streaming: [13:07:16 CEST] <keglevich> ffmpeg -re -i 1.mp4 -c:v libx264 -g 50 -pix_fmt yuv420p -x264opts nal-hrd=cbr -preset veryfast -b:v 2200k -minrate 2200k -maxrate 2200k -bufsize 260k -muxrate 2600k -pcr_period 30 -c:a mp2 -b:a 192k -ac 2 -ar 48000 -f mpegts "udp://239.2.2.2:10000?pkt_size=1316&bitrate=2600000" [13:09:19 CEST] <keglevich> The command works flawlessly on i5 or i7 CPU's... but I have issues on i3 (i3-8100) CPU's... it always crashes with fatal error "av_interleaved_write_frame(): Cannot allocate memory" and "Error writing trailer of udp://239.2.2.2:10000?pkt_size=1316&bitrate=2600000: Cannot allocate memory" ... the CPU is running at around 30% stable, but crashes anyway... I'm wondering why this is happening... why on i5 or i7 runs ok...but lower en [13:24:13 CEST] <atbd> Mavrik: thanks for confirming [14:19:21 CEST] <Accord> what's the difference between acopy and anull? [14:43:53 CEST] <durandal_1707> Accord: acopy copies frames, anull - does nothing [20:50:41 CEST] <shincodex> anyone know if zlib has a irc channel here [20:51:10 CEST] <JEEB> zlib as in zlib or z.lib? [20:51:16 CEST] <JEEB> (latter more known as zimg) [20:51:51 CEST] <shincodex> zlib.a libz.lib [20:51:52 CEST] <shincodex> lol [20:52:18 CEST] <JEEB> ok, so what you'd expect with just zlib [20:52:23 CEST] <shincodex> company wants to add prefix to dll name exported blah-zlib.dll for instance [20:52:39 CEST] <JEEB> isn't that just a Makefile change or so? [20:52:50 CEST] <shincodex> I wanted to check irc channel to see if thats ok cause I know ffmpeg gets anal about that with libav** [20:52:57 CEST] <JEEB> uhh [20:53:02 CEST] <JEEB> we have a configure option for suffixes [20:53:04 CEST] <shincodex> No I know its easy. [20:53:08 CEST] <shincodex> I meant license reasons [20:53:11 CEST] <JEEB> uhh [20:53:16 CEST] <shincodex> laws [20:53:17 CEST] <shincodex> suits etc [20:53:35 CEST] <JEEB> I think renaming the library is just OK, the main thing is that you just follow the license [20:53:55 CEST] <JEEB> whether you distro libavcodec58-herpderp.dll or libavcodec58.dll doesn't really matter [20:54:15 CEST] <JEEB> (unless the license says something about that, but most sw licenses don't) [20:54:50 CEST] <JEEB> like the only case where someone could get angry is if you're trying to hide the fact you're not following the rules of the sw licenses by trying to obfuscate the names of the libraries [20:55:04 CEST] <JEEB> uhh, that went out wrong [20:55:14 CEST] <JEEB> I mean the issue there is the license non-conformance [20:55:18 CEST] <JEEB> not the act of renaming stuff [20:55:18 CEST] <shincodex> Yeah but what about libavcodecsomepostfix.a [20:55:29 CEST] <JEEB> we support that out of the box? [20:55:46 CEST] <shincodex> In that make file? no. [20:55:53 CEST] <JEEB> in zlib, no [20:56:05 CEST] <JEEB> but in FFmpeg's configure since you mentioned libavcodec [20:56:05 CEST] <JEEB> --progs-suffix=SUFFIX program name suffix [] [20:56:05 CEST] <JEEB> --extra-version=STRING version string suffix [] [20:56:05 CEST] <JEEB> --build-suffix=SUFFIX library name suffix [] [20:56:13 CEST] <JEEB> you can get a suffix for everything :D [20:56:49 CEST] <JEEB> anyways, technically if you follow the license it shouldn't matter how you call the binary (unless of course the license says something about the names of the libraries) [20:57:53 CEST] <shincodex> thanks. [20:58:04 CEST] <JEEB> of course, always read the license and understand what it requires you to do [20:58:23 CEST] <shincodex> in zlib it mentioned to email them [20:58:27 CEST] <JEEB> zlib's should be rather simple tho IIRC [20:58:39 CEST] <JEEB> and yea, you can contact them like that if you want to make sure [20:58:41 CEST] <shincodex> I jsut felt like... [20:58:43 CEST] <shincodex> "The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required." [20:59:00 CEST] <shincodex> the misrepresented would be something like zlibpost.lib [20:59:03 CEST] <shincodex> or whatever [20:59:33 CEST] <shincodex> We still maintain their copyright so its not claiming [20:59:40 CEST] <shincodex> just a prefix+zlib.lib [21:00:05 CEST] <shincodex> which in turn produces the prefix+zlib.dll [21:05:13 CEST] <furq> shincodex: if you're not distributing source then you don't need to do anything [21:05:27 CEST] <furq> if you are then just put zlib in vendor/ or something and keep the original license [22:34:04 CEST] <jrgcombr> Hi there! Is there a way to add a video overlay showing the waveform from its audio channel ? [00:00:00 CEST] --- Sat Sep 29 2018

1 0

ffmpeg-devel.log.20180927
by burek 28 Sep '18

28 Sep '18

[00:48:10 CEST] <cone-704> ffmpeg 03Mark Thompson 07master:c8c81ac5026c: lavc: Add coded bitstream read/write support for AV1 [00:48:11 CEST] <cone-704> ffmpeg 03Mark Thompson 07master:476a77128a25: lavc: Add AV1 metadata bitstream filter [00:50:18 CEST] <jamrial> \o/ [00:50:50 CEST] <jkqxz> :) [00:51:57 CEST] <jkqxz> (Todo: testing. Still waiting for any official test streams at all...) [00:59:54 CEST] <jamrial> the parser will make sure it gets enough testing, at least for cli and avformat users [10:30:56 CEST] <j-b> 'morning [10:42:42 CEST] <j-b> durandal_1707: ping [10:45:42 CEST] <durandal_1707> j-b: pong [10:46:40 CEST] <j-b> https://pastebin.com/raw/NqjEsT21 [10:47:45 CEST] <atomnuker> - AACE (aac enhanced with low delay) <- eh? aac-eld wasn't good enough [10:47:56 CEST] <durandal_1707> powerpoint? you are nuts [10:48:45 CEST] <durandal_1707> or it is RGBB fourcc in AVI? [10:52:47 CEST] <j-b> RGBB in AVI, I believ [10:53:35 CEST] <j-b> durandal_1707: complain to koda. [10:54:40 CEST] <j-b> durandal_1707: those are the ones we are discussing for bounties [10:56:08 CEST] <j-b> atomnuker: durandal_1707: so, I need your feedbacks before adding them officially. [10:56:29 CEST] <durandal_1707> well for bunch of them i see no samples [10:56:39 CEST] <j-b> Samples will be provided [10:56:49 CEST] <durandal_1707> or easily accessible decoder/encoder app [10:57:05 CEST] <durandal_1707> adding RASC was pain [10:57:18 CEST] <atomnuker> there are xHE-AAC samples? [11:21:18 CEST] <durandal_1707> j-b: verint rfb code download is allowed only to their users, one needs codec files to successfully RE codec, there is alternative link but it request i enter card details which i not going to do [11:38:53 CEST] <atomnuker> BBB: so _thats_ why you wanted a rewrite [11:38:56 CEST] <atomnuker> should have said so sooner [11:40:30 CEST] <atomnuker> I think I'll just close my PR then [11:41:46 CEST] <BBB> I think youre well underway [11:41:53 CEST] <BBB> I mean, youve so far fixed half of the style issues [11:42:07 CEST] <BBB> removed the redundant functions for symbol/bool reading [11:42:15 CEST] <BBB> so some things are better, some things still to do [11:51:47 CEST] <BBB> atomnuker: I think the question is basically whether youre interested in the above. If your goal is tomake the file better, youre doing it. If your goal is to make it consistent so the rewrite msac.c todo item goes away, thats the direction it should move into, IMO. which is your goal? :) [12:13:01 CEST] <Compn> j-b / durandal_1707 : amusegraphics ag2m info + link to screen capture program codec http://aviutl.info/ag-desctoprecoder/ [12:13:12 CEST] <j-b> sample? [12:13:33 CEST] <Compn> (it was mentioned in your bounty paste list above) [12:13:47 CEST] <Compn> i could probably make one [12:14:00 CEST] <Compn> j-b : where is list of bounties ? in vlc trac or ? [12:14:15 CEST] <j-b> https://wiki.videolan.org/Bounties [12:14:18 CEST] <Compn> thx [12:14:22 CEST] <j-b> + the list above that was mentionned [12:16:00 CEST] <Compn> curious list of codecs, some are very rare [12:16:06 CEST] <Compn> in the paste list [12:16:14 CEST] <Compn> or ones i've never seen/heard of [12:16:53 CEST] <j-b> same [12:17:07 CEST] <atomnuker> BBB: rewrite [12:17:40 CEST] <j-b> Compn: but, I mean, FFmpeg has almost everyhing [12:18:09 CEST] <Compn> well, there is a large list of binary decoders in mplayer that should be RE'd eventually :) [12:18:13 CEST] <BBB> atomnuker: ok, so the above is sort of my list of things. I like the comments youve kept there, I never comment my code well enough (says unlord) [12:20:41 CEST] <Compn> j-b : if you want i could come up with a list of codecs that still need RE [12:24:12 CEST] <Compn> I keep the list https://wiki.multimedia.cx/index.php/Category_talk:Video_FourCCs [12:26:22 CEST] <durandal_1707> just ignore Compn he do not want to add libavcodec reversed codecs to mplayer list any more, just to claim to add win32 emulation to ffmpeg [12:30:58 CEST] <Compn> ugh i find another new codec in google [12:31:39 CEST] <Compn> http://rain.ifmo.ru/~skakov/arvic.html [12:31:51 CEST] <Compn> Video codec based on wavelet-transform and subsequent arithmetic compression. [12:31:53 CEST] <Compn> ehe [12:41:10 CEST] <j-b> Compn: no, I want ones that are actually used [13:16:59 CEST] <Compn> crud, only 30gb free on samples server [13:28:50 CEST] <durandal_1707> j-b: AmuseGraphics - fourcc is AGM2, not AG2M [13:32:53 CEST] <durandal_1707> i got AGM2 avi file [14:18:59 CEST] <BBB> how do I set a custom vcodec in ffplay? [14:19:03 CEST] <BBB> -vcodec doesnt do it... [14:32:49 CEST] <durandal_1707> ffplay is crap [14:33:02 CEST] <atomnuker> mpv can specify a decoder [14:33:36 CEST] <atomnuker> you can always just compile your own libavcodec which disables a built in codec and LD_PRELOAD it [14:34:22 CEST] <durandal_1707> but -vcodec should work for ffplay [15:05:09 CEST] <kierank> https://www.bbc.com/news/technology-45664640 [22:05:48 CEST] <JEEB> wat [22:05:55 CEST] <JEEB> google adding AVC/HEVC support for IVF [22:05:58 CEST] <JEEB> I... don't even [22:22:37 CEST] <gnafu> JEEB: Where do you see that? [22:22:41 CEST] <gnafu> Also, WHY?! [22:22:49 CEST] <JEEB> https://patchwork.ffmpeg.org/patch/10506/ [22:22:51 CEST] <JEEB> yes [22:23:06 CEST] <JEEB> I hope I wasn't coming out too rude but that was my big question mark above my head as well [22:23:17 CEST] <JEEB> they put Annex B into IVF [22:23:44 CEST] <JEEB> also I like it how half of that patch misses HEVC [22:28:41 CEST] <gnafu> JEEB: I think your question is fair. Why allow creation of a file that no one should really need to create? [22:29:35 CEST] <kierank> JEEB: what are they smoking [22:30:04 CEST] <JEEB> kierank: evidently something very good or bad [22:30:05 CEST] <kierank> j-b: ^ [22:30:41 CEST] <jamrial> ivf can't even signal keyframes. you still need some packetizer/parser for it [22:31:08 CEST] <JEEB> jamrial: yea, that's why I mentioned it :D [22:31:15 CEST] <jamrial> i bet they did this because it makes spliting access units "easier" [22:31:30 CEST] <kierank> jamrial: AUDs? [22:31:33 CEST] <jamrial> yeah [22:31:40 CEST] <JEEB> yes, AUDs or something with packet sizes then [22:31:42 CEST] <jamrial> opening raw annex-b needs assembly, like our parser does [22:31:46 CEST] <kierank> I mean you can do it with auds [22:32:22 CEST] <kierank> January wrote a simple parser [22:33:00 CEST] <jamrial> aud nalus are not a requirement for a valid stream, and afaik are not even present in mp4/mkv [22:34:18 CEST] <JEEB> yes, they're not required and probably 14496-15 says nope at them since you no longer have to delimit things as much [22:41:56 CEST] <January> they cant afford a single NALU lookahead? [22:57:16 CEST] <kierank> January: not that easy to figure out what NALUs are in a frame [22:57:45 CEST] <kierank> I guess they want a simple container with timestamps [22:58:18 CEST] <JEEB> oh it has timestamps? [23:28:50 CEST] <nevcairiel> thats practically all it has, frame size and timestamp (with configurable fractional timebase even) [23:32:36 CEST] <JEEB> ok, so prefixed size and a timestamp? I guess that's useful on some level [23:39:48 CEST] <nevcairiel> a single byte for flags might have been nice, for keyframes etc, but what can you do [23:54:06 CEST] <cone-400> ffmpeg 03Carl Eugen Hoyos 07master:303439bc5f7a: lavf/mpeg: Support demuxing HEVC in mpeg-ps. [00:00:00 CEST] --- Fri Sep 28 2018

1 0

ffmpeg.log.20180927
by burek 28 Sep '18

28 Sep '18

[13:43:36 CEST] <odinsbane> I used ffmpeg -i file.mov -c:v copy file.avi I'm not sure if anything changed. [15:27:51 CEST] <Accord> so I created an audio file filled with silence with "ffmpeg -y -f lavfi -i anullsrc=channel_layout=stereo:sample_rate=44100" [15:28:24 CEST] <Accord> then I ran silencedetect and all I got is silence_start [15:28:37 CEST] <Accord> does that mean that it's silent until the end or it's just not working? [15:30:56 CEST] <Accord> guess it just means it's till the end [15:31:16 CEST] <Accord> I've concatenated the silent file with a normal one and silencedetect found it [15:49:49 CEST] <durandal_1707> Accord: you are using old version of ffmpeg, in master that bug have been fixed [15:49:59 CEST] <Accord> ah, ok [18:06:21 CEST] <analogical> does anyone know how extract files from a SACD iso-file? [18:16:27 CEST] <furq> analogical: https://github.com/sacd-ripper/sacd-ripper [18:16:36 CEST] <furq> sacd_extract from that [18:19:30 CEST] <analogical> furq, thank you but I'm looking for a binary not source code [18:20:01 CEST] <furq> there are windows binaries in the release section [18:26:39 CEST] <JEEB> do note that they are built by a 3rd party [18:26:45 CEST] <JEEB> oh, wrong software [18:26:48 CEST] <JEEB> sorry for that [19:13:24 CEST] <^Neo> hello friends, can someone suggest how to upconvert from p24 to p29.97/p59.94 with repeat fields signaled in the output? Is just setting -g 29.97/59.94 sufficient? [19:21:06 CEST] <furq> ^Neo: if you mean -r then that'll just repeat frames [19:21:18 CEST] <furq> i'm not sure that ffmpeg can do it without reencoding [19:22:18 CEST] <furq> i know dgpulldown on windows can do it for mpeg2video [19:22:36 CEST] <furq> i've not needed to do this since tools starting with "dg" were still relevant [19:50:49 CEST] <cfaber> Hi folks, I'm trying to figure out a fast way to dump single frames throughout a video file. I'm using the following commandline: ffmpeg -i test.mkv -ss 00:19:26.000 -vframes 1 out.jpg the problem is that htis takes about 4 minutes on a resonably fast system for a video that's only about 20 minutes long, I can perform a similar action in under a second with mplayer -vo:png dump. So what am I doing wrong and how can I speed this process [19:51:23 CEST] <cfaber> The time it takes to dump the frame depends on how far into the video I'm seeking [19:52:17 CEST] <kepstin> cfaber: move the -ss before the -i [19:52:27 CEST] <cfaber> ahha [19:53:27 CEST] <kepstin> -ss before -i means seek, it's quick. -ss after -i means "decode and discard until this timestamp", it's slow [19:54:17 CEST] <kepstin> specifically, that's -ss as an input option vs. as an output option. [19:54:20 CEST] <cfaber> great, that did it, thank you! [19:54:27 CEST] <cfaber> right makes sense [19:54:39 CEST] <cfaber> I didn't know that the argument order was that sensitive [19:54:45 CEST] <cfaber> but makes perfect sense [19:54:55 CEST] <cfaber> thanks kepstin [19:56:53 CEST] <kepstin> for most ffmpeg options, the location in the command line is important. In general, you put a particular option in front of the input or output file that it's supposed to affect [20:54:18 CEST] <^Neo> furq: Thanks! yes, I meant -r. So will I see repeat_pict be non-zero in this case? [20:59:59 CEST] <JEEB> -r would just actually change the frame rate [21:00:09 CEST] <JEEB> if you need soft pulldown you'd have to set something in the video encoder [21:06:59 CEST] <furq> if you're reencoding with x264 then -x264-params pulldown=32 [21:08:03 CEST] <furq> i'm guessing you need it for mpeg2video though [21:09:13 CEST] <^Neo> ah! that's exactly what I wanted. Great! TYVM! [23:00:48 CEST] <Filarius> I do hobby project using 8x8 DCT from x264 sources and I have questions, I wrote my questions at #x264dev several times but all was ignored... [23:01:45 CEST] <Filarius> last question is about I copy 8x8 DCT and IDCT to Python and I found its far not lossless, is it my mistake or it how it must be [23:02:40 CEST] <Filarius> *made Python implementation of that algorthim using x264 sources [00:00:00 CEST] --- Fri Sep 28 2018

1 0

ffmpeg-devel.log.20180926
by burek 27 Sep '18

27 Sep '18

[01:22:38 CEST] <jkqxz> jamrial: Right, I was missing that the KEY frame only clears the previous state at the point it is shown, not the point it is coded. [01:22:51 CEST] <jkqxz> Is the logic for why it does that obvious somehow? It's the opposite of what VP9 does. [01:49:49 CEST] <jamrial> jkqxz: i dont' know [01:49:55 CEST] <jamrial> the delayed RAP stuff is funny as it requires the container to somehow signal how far away from the key frame DRP the actual delayed RAP is in the stream [01:52:44 CEST] <jkqxz> I guess it needs an equivalent to the recovery point SEI message, which has precisely that information. [11:37:02 CEST] <January> https://0x0.st/s3YD.nal -> fate-samples/h264/crew_cif.nal (for test on ML, though not sure if this is best way to do it) [11:50:00 CEST] <kierank> michaelni: ^ [12:18:08 CEST] <kierank> January: i would personally have called the test "chunks" instead of slices [13:18:53 CEST] <michaelni> January, kierank fate sample uploaded, more test coverage should be good ... (the code has issues though see ML), [13:24:25 CEST] <atomnuker> kierank: https://www.iter.org/jpo [13:24:56 CEST] <kierank> atomnuker: hmmmm [13:25:22 CEST] <kierank> was thinking of going to demuxed [14:00:20 CEST] <JEEB> did the trim filter just pass through everything else than the selected range? [14:00:49 CEST] <JEEB> pass through as in throw away and go on [14:01:57 CEST] <durandal_1707> Pick one continuous section from the input, drop the rest. [14:03:53 CEST] <durandal_1707> if you want to throw away use aselect ? [14:04:34 CEST] <durandal_1707> and complex expression, haha [14:33:10 CEST] <JEEB> durandal_1707: yes, that is what I meant. as in, there shouldn't be extraneous buffering [14:33:32 CEST] <JEEB> it will just "consume" the AVFrames not within the range(s) [14:33:36 CEST] <JEEB> and not return anything [14:36:38 CEST] <durandal_1707> JEEB: trim filter pick selection and drops rest, i had impression you want reverse [14:39:00 CEST] <JEEB> yea [14:39:20 CEST] <JEEB> that is what I wanted and I just wanted to verify that there shouldn't be any funkyness wrt buffering etc [14:46:26 CEST] <durandal_1707> filters that buffers frames (including only one) are: reverse, loop, atadenoise, random, amplify, shuffleframes, tmix, tblend, tlut2, some audio filters and deinterlace filters [14:47:02 CEST] <durandal_1707> add (a)cue filters, obviously [14:47:27 CEST] <durandal_1707> and i probably forgot couple of them [14:50:09 CEST] <JEEB> cheers [17:24:19 CEST] <durandal_1707> what i should do next? [17:30:48 CEST] <kierank> durandal_1707: fix my fate test which don't work on big endian [18:04:00 CEST] <durandal_1707> kierank: isn't that trivial? [20:47:56 CEST] <cone-704> ffmpeg 03James Almer 07master:14ac62f9af58: avformat/matroskaenc: remove unnecessary additional codec tags [20:47:57 CEST] <cone-704> ffmpeg 03James Almer 07master:794079e81529: avformat/matroskaenc: implement AVOutputFormat.query_codec for webm [20:47:58 CEST] <cone-704> ffmpeg 03James Almer 07master:8439656503e9: avformat/matroskaenc: refactor checks for allowed codecs in WebM [20:47:59 CEST] <cone-704> ffmpeg 03James Almer 07master:819e4e79797e: avformat/matroskaenc: reindent after the previous commit [20:58:35 CEST] <durandal_1707> i want do do dynamic noise shaping & dither audio filter which will reduce bits ala lossywav [22:24:53 CEST] <cone-704> ffmpeg 03Paul B Mahol 07master:5ee414470192: avfilter/af_afftdn: add missing break [00:00:00 CEST] --- Thu Sep 27 2018

1 0

ffmpeg.log.20180926
by burek 27 Sep '18

27 Sep '18

[01:07:50 CEST] <autofsckk> hello, hello, i want to convert an mp4 movie to avi, i already did doing the "-codec copy" option but it didnt work, i try to play it on a specific dvd player that can do usb, i have a file that can be played in this specific player, i think its because the video format, how can i know that? i see that with mediainfo i get video format MPEG-4 Visual for the one that works on the player, but i have AVC [01:11:26 CEST] <autofsckk> https://pastebin.com/AJbvCYk8 this info i get from mediainfo from both files [01:13:43 CEST] <autofsckk> or could it be because of the audio that the video doesnt work? ill paste all the information from mediainfo from both files, hope somebody give me a hint, thanks [01:14:50 CEST] <autofsckk> https://pastebin.com/CKUgM6AF [01:41:28 CEST] <relaxed> autofsckk: see if this 30 seond sample works, ffmpeg -i input -c:a libmp3lame -ac 2 -b:a 192k -c:v mpeg4 -vtag XVID -q:v 2 output.avi [01:42:23 CEST] <relaxed> s/seond/second/ [01:44:47 CEST] <relaxed> oh, you probably need to scale it down as well [01:46:23 CEST] <relaxed> add -vf scale=720:-1 [01:47:44 CEST] <autofsckk> relaxed: thanks, doing it, but i have a very very old computer and it seems that its going to fly, the fan is very noisy :/ [01:49:57 CEST] <TheAMM> Can I (ab)use some filter to freeze the first frame to use in a filter graph, with only one input? [01:49:59 CEST] <relaxed> that means it's working hard for you :) [01:50:37 CEST] <TheAMM> Like [in]split[v1][v2]; [v2]<first frame>[v2]; ... [01:52:01 CEST] <TheAMM> To avoid the XY problem, the goal is to use a single input, crop a selected area and overlay that over the static first frame [01:52:03 CEST] <relaxed> maybe the select filter? [01:52:08 CEST] <autofsckk> the quality of the output video si great, let me copy it to my usb and test it on the dvd player, gimme a sec relaxed and thanks for the help [01:52:33 CEST] <relaxed> you're welcome [01:58:35 CEST] <TheAMM> select=eq(n, 0) does work [02:00:27 CEST] <autofsckk> well, the audio worked but not the video, i just get the image of the speller dvd player [02:00:30 CEST] <autofsckk> ja [02:03:04 CEST] <relaxed> mediainfo output of that file? [02:03:24 CEST] <autofsckk> https://pastebin.com/ra2TATNt [02:03:30 CEST] <autofsckk> was doing that :D [02:05:09 CEST] <autofsckk> i see different the writing library, xvid 64 the one that works, and lavc57.107.100 the one that does not work [02:06:10 CEST] <autofsckk> i also see that the audio seems different, but i was getting audio from the file so i think thats not important [02:06:15 CEST] <Lite89> Hello! [02:08:02 CEST] <autofsckk> Lite89: hi [02:08:35 CEST] <Lite89> Couple days before I requested here about ways of solving an issue I'm facing, trying to cancatenate decrypted via OpenSSL transport stream fragments. I just faced an errors about each of ~300+ segments like it shown here https://stackoverflow.com/questions/42432898/live-tv-recording-ts-to-mp4-wi… [02:09:34 CEST] <Lite89> Here one of members helped me, messaging that I should use at FFMPEG some kind of '/b copy' command [02:09:58 CEST] <Lite89> but I forgot how it should be exactly. [02:10:50 CEST] <Lite89> I mean FFMPEG doesn't understand '/b copy' command maybe I was wrong when marked this advise in my note. [02:11:05 CEST] <Lite89> Also have one more question. [02:12:25 CEST] <Lite89> Faced same issue trying to concatenate non-encrypted parts (segments) with .AAC extension (audio stream). [02:13:06 CEST] <Lite89> Here are errors sown by FFMPEG due to process of concatenation [02:14:11 CEST] <Lite89> 'Application provided invalid, non monotonically increasing dts to muxer in stream 0: XXXXXXXX >= YYYYYYYY' and sometimes 'Estimating duration from bitrate, this may be inaccurate' [02:14:52 CEST] <Lite89> Thanks in advance [02:19:24 CEST] <autofsckk> relaxed: any idea how can i fix that? [02:21:43 CEST] <Lite89> Maybe for AAC I should be guided by the instructions in the section M [02:22:29 CEST] <Lite89> Maybe for AAC I should be guided by the instructions in the section 'Using intermediate files' provided here https://trac.ffmpeg.org/wiki/Concatenate ? [02:23:02 CEST] <Lite89> I mean that: 'If you have MP4 files, these could be losslessly concatenated by first transcoding them to MPEG-2 transport streams. With H.264 video and AAC audio, the following can be used' [02:24:06 CEST] <Lite89> As soon as this is the decision, so how should look an example, provided there for MP4 (H.264) for AAC? [02:51:57 CEST] <allohol> Lite89: 'copy /b 1st.chunk /b +2nd.chunk /b +nth.chunk concatenaded.output' [03:16:02 CEST] <Lite89> @allohol, thanks, but still didn't understand. Where exactly this 'copy /b ...+...+...' string should be included in command string like: 'FFMPEG -f concat -safe 0 -i C:\FFMPEG\MyList.TXT -acodec copy C:\Output.MP4'?? [05:45:16 CEST] <Matador> weee [05:45:16 CEST] <Matador> https://trac.ffmpeg.org/ticket/6418 [05:45:36 CEST] <Matador> How much bounty/sponsor will it take to fix that ? heh [11:22:26 CEST] <blaisebool> hello, I'm trying to convert flv to mp4 whith this command : ffmpeg -i file01.flv -vcodec h264 -acodec aac -strict -2 file01.mp4 but I'm getting this error : "Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height" [11:22:31 CEST] <blaisebool> any help [11:23:01 CEST] <blaisebool> would be appreciated :-) [11:23:57 CEST] <blaisebool> Stream #0:0 -> #0:0 (vp6f (native) -> h264 (libx264)) [11:43:26 CEST] <blaisebool> I found [11:43:34 CEST] <blaisebool> for those interested : [11:43:48 CEST] <blaisebool> find . -type f -iname "*.flv" -exec ffmpeg -i '{}' -f mp4 -b 500k -r 30 -vcodec h264 -acodec aac -strict -2 -ab 128k -ar 48000 -ac 2 -s 720x480 '{}.mp4' \; [12:37:25 CEST] <relaxed> blaisebool: pastebin.com the ffmpeg output from the input that fails [12:37:55 CEST] <blaisebool> relaxed , it works now with my last command :-) thanks a lot [12:38:46 CEST] <relaxed> -strict -2 shouldn't be needed with recent ffmpeg releases [12:39:42 CEST] <blaisebool> my version is 2.8.15 [12:40:32 CEST] <blaisebool> without -strict -2, ffmpeg complains this "aac" [12:41:05 CEST] <relaxed> ok, any reason you're using such an old version? [14:28:54 CEST] <blaisebool> relaxed latest from Centos package [14:35:11 CEST] <kwizart> blaisebool, if using ffmpeg from rpmfusion, we are in the middle of updating the package to 3.x [14:35:58 CEST] <relaxed> blaisebool: https://www.johnvansickle.com/ffmpeg/ [14:36:14 CEST] <blaisebool> thanks a lot :-) [16:24:58 CEST] <mux> egeltje_: spam [18:38:59 CEST] <rmbeer> hello... [18:39:49 CEST] <rmbeer> for '-f concat' parameter, where found the complete guide for the text file? i need specific the init and length time for each fragment of video to concatenate.... [18:45:15 CEST] <rmbeer> i found this: https://ffmpeg.org/ffmpeg-formats.html#concat-1 [18:45:37 CEST] <rmbeer> but not understand, i must use inpoint and outpoint instead of init and length?... [18:54:28 CEST] <relaxed> rmbeer: have you read https://trac.ffmpeg.org/wiki/Concatenate ? [18:57:10 CEST] <rmbeer> relaxed, the document no explain about of take a fragment of each video... :/ [18:57:27 CEST] <rmbeer> i need set the init and length time for each video... [18:59:15 CEST] <rmbeer> relaxed, and your document jump to my document link... :/ [18:59:57 CEST] <rmbeer> i need understand how to work with 'duration', 'inpoint', and 'outpoint', but i not understand... [19:02:55 CEST] <rmbeer> https://ptpb.pw/vTCJ.txt [19:03:14 CEST] <rmbeer> Unsafe file name '../vids/Juego del Laberinto-ZXx3IZEC88o.mp4' [19:03:26 CEST] <rmbeer> what is the problem?... [19:09:53 CEST] <relaxed> rmbeer: add -safe 0 before the -i [19:11:41 CEST] <rmbeer> relaxed, thanks!... now i'm test it... [19:12:20 CEST] <rmbeer> the next problem is check if init and length is correct... [19:13:41 CEST] <rmbeer> nice... ffmpeg explode in errors.... [19:14:01 CEST] <rmbeer> Non-monotonous DTS in output stream 0:1; previous: 39458879, current: 37508832; changing to 39458880. This may result in incorrect timestamps in the output file. [19:14:12 CEST] <rmbeer> in million of lines... [19:26:22 CEST] <relaxed> rmbeer: maybe the concat filter is your best bet [19:26:52 CEST] <rmbeer> relaxed, .... what?.... [19:27:28 CEST] <rmbeer> this seem a bug of ffmpeg... [19:27:58 CEST] <rmbeer> my videos work perfect, and the lines of concat file is good... what happened then?... [19:29:57 CEST] <relaxed> hmm, sometimes changing containers can get around this. remux your mp4s to nut, ffmpeg -i input -c copy output.nut [19:30:19 CEST] <relaxed> then adjust your concat list to point to them [19:30:57 CEST] <rmbeer> relaxed, what is nut??... [19:31:09 CEST] <relaxed> a container, like mp4 [19:31:35 CEST] <relaxed> it's worth a shot :) [19:31:41 CEST] <rmbeer> well, if i not have other, make all fragments files... :/ [19:32:13 CEST] <rmbeer> that shit... [19:33:04 CEST] <ChocolateArmpits> why does http://ffmpeg.pastebin.com/ redirect to simple pastebin.com ? [19:33:28 CEST] <relaxed> it's a trap [19:34:42 CEST] <ChocolateArmpits> did someone once expect that there will be preferential treatment of ffmpeg on pastebin? [19:35:25 CEST] <Loeb> has the 33 bit mpeg-ts timestamp overflow been fixed or is that something that still has to be manually patched? Google is bringing up some reports and a patch from 2012 but I don't see a bug report for ffmpeg itself [19:38:41 CEST] <JEEB> Loeb: there's a timestamp overflow handling code in lavf's general utilities [19:40:49 CEST] <Loeb> JEEB, what is that? Google isn't bringing anything obvious up [19:45:10 CEST] <JEEB> don't remember the exact spot where the code was, but IIRC the generic packet reading code used AVFMT_TS_DISCONT [19:45:31 CEST] <JEEB> the demuxer exports the amount of bits its timestamp field has [19:46:17 CEST] <JEEB> and then ffmpeg.c has some generic stuff for discontinuity handling separately [19:47:36 CEST] <Loeb> Hmm... So I should probably try using -copyts and see if it fails after 26 hours? [19:47:44 CEST] <JEEB> oh, copyts then disables a lot of stuff :D [19:47:52 CEST] <Loeb> uh oh [19:48:20 CEST] <Loeb> I'm just looking to get audio sync here, which seems to require keeping the original timestamps in place [19:48:43 CEST] <Loeb> the async filters don't seem to do much if your source input has any errors [19:48:44 CEST] <JEEB> audio sync generally wasn't a problem for me with any mpeg-ts inputs I've had [19:49:02 CEST] <JEEB> oh, errors in the input? [19:49:18 CEST] <JEEB> ok, found the place [19:49:30 CEST] <Loeb> Yes. Input we get tends to have errors sooner or later [19:49:31 CEST] <JEEB> ff_read_packet in libavformat/utils.c tries to do the wrap-arounds [19:49:34 CEST] <Loeb> and ffmpeg doesn't handle them well [19:50:42 CEST] <JEEB> there's two levels really [19:50:47 CEST] <JEEB> 1) libavformat itself [19:50:49 CEST] <JEEB> 2) ffmpeg.c [19:50:59 CEST] <JEEB> copyts disables some stuff in ffmpeg.c [19:51:44 CEST] <JEEB> they both attempt to do some things, although I've found ffmpeg.c's logic to not always be perfect :P [19:51:46 CEST] <Loeb> So how should I go about preserving timestamps so that stuff can fall back in sync after errors? [19:51:59 CEST] <Loeb> The docs I'm reading about this are 6 years old now [19:52:04 CEST] <JEEB> eh [19:52:14 CEST] <JEEB> the docs are generated each night [19:52:32 CEST] <Loeb> Different docs, sorry [19:52:41 CEST] <Loeb> some paper written in 2012 about ffmpeg stability over long term use [19:53:06 CEST] <JEEB> anyways, if I were taking in live inputs I'd probably just use the API [19:53:09 CEST] <JEEB> instead of ffmpeg.c [19:53:23 CEST] <JEEB> because ffmpeg.c has a lot of weird logic (part of which you can disable with copyts) [19:54:09 CEST] <Loeb> The API? [19:55:02 CEST] <JEEB> FFmpeg itself consist of the libraries (libavformat, libavcodec etc) and an example API client (ffmpeg.c) [19:55:39 CEST] <Loeb> Ah, so if I'm just running ffmpeg from the command line, that's (the) ffmpeg.c (example API)? [19:55:44 CEST] <JEEB> yes [19:55:54 CEST] <JEEB> example API client [19:55:56 CEST] <kepstin> ffmpeg.c is a great tool for batch stuff with local files, and behaves acceptably in limited circumstances when dealing with live/streaming stuff. [19:56:04 CEST] <JEEB> which you can get surprisingly far with [19:56:10 CEST] <Loeb> That's what we're doing right now. And it does reasonably well [19:56:16 CEST] <Loeb> but it sounds like we need to be using it differently? [19:56:21 CEST] <Loeb> Or, rather not using it [19:56:23 CEST] <JEEB> which is why you get then people holding their heads when you start hitting the borders [19:56:51 CEST] <JEEB> also btw: you can disable most that ffmpeg.c does for your timestamps with -copyts -vsync passthrough [19:57:04 CEST] <JEEB> but it will indeed not try to fix various timestamp discontinuities with that [19:57:17 CEST] <JEEB> if it's not something handled by the wrap-around helper in lavf/utils [19:57:50 CEST] <Loeb> So if I'm going to try and move our current process from ffmpeg.c over to ???, where do I need to start reading? [19:58:03 CEST] <JEEB> see the examples directory under docs [19:58:06 CEST] <JEEB> in the git repository [19:58:18 CEST] <JEEB> doc/examples I mean [19:58:33 CEST] <JEEB> I think the transcoding example is relatively (?) up-to-date with the API usage [19:58:58 CEST] <JEEB> and if you want to look something up, googling "site:ffmpeg.org doxygen trunk KEYWORD" generally finds the documentation that's being generated [19:59:31 CEST] <Loeb> So all of this would need to be written in C? [19:59:52 CEST] <JEEB> not necessarily in C, I've used C APIs from python, rust and go so far :P [20:00:00 CEST] <JEEB> the API is in C, though, of course [20:01:21 CEST] <JEEB> Loeb: also the alternative is to start modifying ffmpeg.c, but it's so full of stuff I'm not sure if cleaning that up for your use case would take more or less time than making an API client of your own [20:05:01 CEST] <JEEB> Loeb: also I recommend checking whereabouts your timestamps go weird btw. you can add an av_log before and after wrap_timestamp in libavformat/utils.c [20:05:22 CEST] <JEEB> if it's: 1) the mpegts demuxer 2) the wrap-around logic or 3) ffmpeg.c itself [20:05:48 CEST] <JEEB> it's a lot of logging but I'd guess it's worth it :P [20:06:09 CEST] <JEEB> (since each packet of data read from the MPEG-TS packets gets logged) [20:06:32 CEST] <JEEB> and preferably keep dumping the input with multicat or so [20:06:52 CEST] <JEEB> so that when you get to the point where the breakage happens you can have a sample [20:06:58 CEST] <JEEB> (and then to iterate over it) [20:07:15 CEST] <Loeb> Can't say I know any C but I do know python. But I'm also fairly new to writing code. Think I'll poke around at it in the evening and see if I can make head and tails of it. [20:07:45 CEST] <Loeb> There isn't a tool that will take a ffmpeg command sequence and turn it into some sort of API example, is there? I'm assuming no but always worth asking [20:07:56 CEST] <JEEB> nope [20:08:10 CEST] <JEEB> also for the record, without disabling the extra things in ffmpeg.c, with generally sane mpeg-ts input even ffmpeg.c can be up for weeks [20:08:38 CEST] <JEEB> when you start hitting interesting things then it can either fail right away, or fail after a few days [20:09:12 CEST] <JEEB> for example if a broadcaster muxes in a subtitle track with completely bogus timestamps (not even close to PCR), and you happen to receive one before you get PCR [20:09:17 CEST] <rmbeer> ffmpeg are bugged... I am concatenating videos, the original video is in perfect condition, but when I concatenate the video it is cut out and the next half is filled with the last frame, it is not what I ask, only concatenate videos!!.... [20:09:45 CEST] <rmbeer> that shit... [20:09:50 CEST] <JEEB> rmbeer: there's like N different things that different people made for their specific use case of concatenation [20:09:53 CEST] <JEEB> have fun [20:09:58 CEST] <kepstin> rmbeer: you're probably trying to concatenate incompatible videos without re-encoding :/ [20:10:35 CEST] <Loeb> JEEB, sometimes we have stuff that's up for weeks... problem is we don't get sane mpeg-ts input all the time [20:10:44 CEST] <Loeb> And I need to make everything more robust in that regard [20:10:54 CEST] <rmbeer> kepstin, 'ffmpeg -f concat -safe 0 -i cconct.txt caca.mp4' - https://ptpb.pw/v8q7.txt [20:11:05 CEST] <JEEB> concat demuxer \o/ [20:11:20 CEST] <rmbeer> nothing strange, only ffmpeg does strange things that are over.... [20:11:24 CEST] <kepstin> rmbeer: yep, looks like you're trying to concatenate incompatible videos without re-encoding. [20:11:30 CEST] <JEEB> no -c copy [20:11:34 CEST] <kepstin> oh, huh [20:11:36 CEST] <JEEB> then he might as well concat with the filter [20:11:40 CEST] <JEEB> instead of demuxer [20:12:10 CEST] <kepstin> yeah, i guess this would need the filter then, there must be some weirdness where there's a video reconfig that isn't being handled by the decoder or something? [20:12:28 CEST] <JEEB> dunno, I'd put the blame generally on the concat demuxer :P [20:12:38 CEST] <kepstin> probably, yeah. [20:13:16 CEST] <JEEB> Loeb: first of all if you have some input that's known to do it at some point, set up multicat that dumps into a directory with like 2 minute blocks. then have a cron job that cleans up segments that are older than N hours. [20:13:24 CEST] <JEEB> multicat being https://code.videolan.org/videolan/multicat [20:13:52 CEST] <kepstin> rmbeer: you're going to want to try the concat filter, https://ffmpeg.org/ffmpeg-filters.html#concat [20:14:08 CEST] <JEEB> that way you can possibly catch teh actual glitching moment so you have a test case [20:14:34 CEST] <JEEB> and after that you can analyze what went wrong and where [20:14:39 CEST] <rmbeer> kepstin, you saying that i must test with other method of concat?... [20:14:39 CEST] <kepstin> rmbeer: note that the concat filter will have issues if the inputs have different framerates. [20:14:56 CEST] <kepstin> rmbeer: that's exactly it, yes. your input files don't work with the method you're trying right now. [20:15:20 CEST] <rmbeer> ok... thanks... try with other methods... [20:15:57 CEST] <kepstin> (another option might be to try to remux the input files to mpeg-ts, then combine them with 'cat' or by using the concat protocol) [20:19:37 CEST] <rmbeer> ffmpeg -i fr1b.mp4 -i fr2.mp4 -i fr3b.mp4 -i fr4b.mp4 -i fr5b.mp4 -i fr6b.mp4 -i fr7b.mp4 -i fr8b.mp4 -i fr9b.mp4 -filter_complex '[0:0] [0:0] [0:0] [0:0] [0:0] [0:0] [0:0] [0:0] [0:0] concat=n=9' caca.mp4 [20:19:43 CEST] <Loeb> JEEB, yup, need to get a test file to mess with. [20:19:51 CEST] <Loeb> Thanks for the help [20:20:11 CEST] <JEEB> and then you can also poke at it with DVBInspector [20:20:12 CEST] <rmbeer> https://pastebin.com/raw/aT7smu6R [20:20:20 CEST] <JEEB> so you can have an alternative view on how the timestamps look [20:20:42 CEST] <JEEB> https://sourceforge.net/projects/dvbinspector/ [20:20:58 CEST] <JEEB> it's java, but still probably the least bad thing to poke at MPEG-TS [20:21:15 CEST] <JEEB> it has a nice graph for DTS/PTS/PCR too [20:23:23 CEST] <rmbeer> I give up, I can not even ffmpeg concatenate these fragments, I'll have to wait for the bugs to fix.... [20:23:59 CEST] <JEEB> rmbeer: have you made a bug report on the trac tracker with samples so that it can be tested by someone else then? [20:24:24 CEST] <rmbeer> JEEB, still no... [20:24:31 CEST] <JEEB> ok, too bad [20:24:35 CEST] <JEEB> then it will not get fixed [20:24:44 CEST] <rmbeer> ........ [20:24:52 CEST] <JEEB> because the concat demuxer clearly worked for someone so it isn't broken always [20:24:59 CEST] <JEEB> is this a hard to understand concept? [20:25:33 CEST] <JEEB> if it's just two of the files needed to make it happen then just provide the two files and your command line [20:25:45 CEST] <JEEB> and put a bug report on trac [20:27:05 CEST] <relaxed> your concat filter has the same stream specified 9 times, fyi [20:29:25 CEST] <furq> you shouldn't need to specify them anyway [20:29:31 CEST] <furq> just -lavfi concat=n=9 should work [20:30:30 CEST] <relaxed> isn't -lavfi for input ? [20:30:37 CEST] <furq> no [20:30:46 CEST] <furq> -lavfi is an alias for -filter_complex [20:30:49 CEST] <JEEB> probably an alternative for filter_complex [20:30:49 CEST] <JEEB> yes [20:30:50 CEST] <kepstin> no, -lavfi is a short way to write -filter_complex [20:30:50 CEST] <JEEB> :V [20:31:01 CEST] <furq> you're thinking of -f lavfi [20:31:03 CEST] <relaxed> OK [20:31:03 CEST] <JEEB> s/alternative/alias/ [20:31:20 CEST] <relaxed> yes, that what is was [20:39:17 CEST] <rmbeer> 7mb of files upload to bugtrack... [20:39:28 CEST] <rmbeer> god... i want cookies... [20:39:47 CEST] <pzich> are you on dialup? [20:39:48 CEST] <rmbeer> "Tamaño máximo del archivo adjunto: 2621440 bytes" ok... no matter... [20:40:13 CEST] <rmbeer> https://trac.ffmpeg.org/ticket/7458 [20:41:57 CEST] <pzich> did you try running again with the '[0:0]'s removed? as relaxed said, you're currently passing in the same stream 9 times [20:43:47 CEST] <relaxed> rmbeer: the concat demuxer won't work because the videos are different resolutions [20:44:24 CEST] <rmbeer> yes... sorry... i send a new message... [20:44:42 CEST] <rmbeer> relaxed, yes, i'm see it... [20:44:58 CEST] <rmbeer> maybe also have the different fps... [20:45:34 CEST] <relaxed> with the concat filter, you'll have to scale them all to the same size before reaching concat in the filter chain [20:46:17 CEST] <rmbeer> omg... [20:46:35 CEST] <relaxed> there's an example here --> man ffmpeg-filters|less +/^' 'concat [20:48:16 CEST] <relaxed> these requirements are all spelled out in the man page [20:48:32 CEST] <rmbeer> relaxed, I have those documents, but I find it brutally difficult to understand right now, it does not give me the head.... [20:49:01 CEST] <rmbeer> I think I'd better leave it for another day... :( [20:49:18 CEST] <relaxed> Ok. You probably should close your bug, though [20:49:19 CEST] <rmbeer> I keep the link and continue it another day.... [20:49:49 CEST] <rmbeer> relaxed, nah... in the bug explain other problems... [20:50:12 CEST] <rmbeer> not is about of demuxer... [21:02:09 CEST] <TheAMM> Update for yesterday's "overlay crop over static first frame using only one input" question [21:02:34 CEST] <TheAMM> select=eq(n,0) did work, but horribly inefficient when I tested it on Sintel instead of a 2 second testsrc encode [21:03:02 CEST] <TheAMM> I realized overlay keeps the last frame, though, so trim is the better choice [21:03:48 CEST] <TheAMM> trim=end_frame=1 and feed that to the overlay [21:19:38 CEST] <relaxed> TheAMM: can you pastebin it? I'm interested to see it [21:20:21 CEST] <TheAMM> I'm using mpv, so you'll have to use a bit of imagination [21:20:28 CEST] <TheAMM> '--lavfi-complex=[vid1] split [v][bg]; [bg] trim=end_frame=1 [bg]; [v] crop=488:496:280:247[v]; [bg][v] overlay=280:247 [vo]' [21:20:46 CEST] <TheAMM> eg mpv sintel.mkv --lavfi-complex=... [21:21:16 CEST] <TheAMM> Looks like https://mygi.ga/Ygl/aecWK.png [21:25:00 CEST] <TheAMM> Here's my use-case https://mygi.ga/8wO/aecWL.webm (warning, anime) [21:25:25 CEST] <TheAMM> (please ignore the flicker, my laptop absolutely hates screen recording) [21:26:39 CEST] <durandal_1707> nice script [21:50:01 CEST] <rmbeer> ffmpeg -i "concat:video1.avi|video2.avi" output_video.avi [21:50:27 CEST] <rmbeer> this is useful for concatenate only two videos or also need -lavfi ?... [22:11:47 CEST] <rmbeer> well, i solve with -lavfi ... :/ [00:00:00 CEST] --- Thu Sep 27 2018

1 0

ffmpeg-devel.log.20180925
by burek 26 Sep '18

26 Sep '18

[00:17:07 CEST] <cone-547> ffmpeg 03Mark Thompson 07master:581b4125aa18: lavc/h264_levels: Avoid integer overflow in bitrate [00:17:08 CEST] <cone-547> ffmpeg 03Mark Thompson 07master:321294adb788: h264_metadata: Avoid integer overflow in bitrate [00:17:09 CEST] <cone-547> ffmpeg 03Mark Thompson 07master:feb1cf08ab39: lavc/h265_profile_level: Avoid integer overflow in bitrate [00:17:10 CEST] <cone-547> ffmpeg 03Mark Thompson 07master:1215fbad96da: lavc/h265_profile_level: Fix level guessing with no PTL structure [00:17:11 CEST] <cone-547> ffmpeg 03Mark Thompson 07master:74b4134d2f57: vaapi_encode_h265: Add missing error return [00:20:02 CEST] <jamrial> jkqxz: got a "trailing_one_bit out of range: 0, but must be in [1,1]." error on a freshly made monochrome av1 sample [00:20:27 CEST] <jamrial> apparently on the sequence header [00:23:15 CEST] <jkqxz> Hmm. Link? [00:23:26 CEST] <jkqxz> Probably a desync somewhere which it only finds at the end. [00:24:01 CEST] <jamrial> jkqxz: https://code.videolan.org/videolan/dav1d/uploads/39460802304c1b4f16e8ec035d… [00:26:20 CEST] <jamrial> jkqxz: ah, color_range [00:26:58 CEST] <jamrial> you're using infer for the value when you should read a bit when monochrome is 1 [00:27:51 CEST] <jamrial> did you see the cbs based parser i submitted to the ml, for that matter? [00:28:34 CEST] <jkqxz> Yes, I'm just looking at that. [00:28:56 CEST] <jamrial> it will give cbs_av1 some good testing once committed :p [00:31:03 CEST] <jkqxz> Right, color_range for mono_chrome. Fixed. [00:32:30 CEST] <jkqxz> (Wtf is with that crazy BT.709/sRGB/RGB special case? It saves like 1 bit in the sequence header and makes you have stupid extra code to handle it.) [00:33:51 CEST] <jamrial> that'd be gbrp pix_fmt if we were to implement it in the libaomdec wrapper [00:36:18 CEST] <jkqxz> I guess raw HDMI streams aren't really an intended use-case, but they often fall exactly into the disallowed case (BT.709, sRGB, limited range). [00:36:55 CEST] <jamrial> the reduced sitll picture header stuff is more annoying imo. it saves a few bytes in the sequence header for still images but makes parsing a mess [00:39:48 CEST] <atomnuker> jkqxz: yeah, you can blame me for that :p [00:40:09 CEST] <jkqxz> To stop people using AV1 for HDMI? [00:43:47 CEST] <atomnuker> no, not directly, the reasons I remember giving were that it was a modern codec for the internet, and not a dumping ground for outdated broadcast hacks, and also because we'd have to define what limited range rgb is, and we were writing a codec [00:45:09 CEST] <jkqxz> But why that specific combination? It lets you have limited range RGB, just not in sRGB with BT.709 transfer. [00:46:16 CEST] Action: atomnuker checks specs [00:50:05 CEST] <atomnuker> hm, maybe it should have been allowed for BT601 as well, but IIRC 2020 didn't allow limited range rgb, and I'm not sure about the rest with TC_SRGB (CP_XYZ + TC_SRGB == ?) [00:56:38 CEST] <jkqxz> atomnuker: Btw, what was the error you mentioned last night? [01:04:32 CEST] <atomnuker> it gets printed when mpv inits a hardware decoder [01:05:11 CEST] <atomnuker> checked, it didn't happen before the patchset, and there's only 1 patch which touched a seemingly unrelated part in hwcontext_vaapi [01:06:11 CEST] <jkqxz> Yeah, I was going to say that it didn't touch anything decode... [01:06:17 CEST] <jkqxz> Intel or AMD? [01:11:38 CEST] <jkqxz> Oh, it's in the testing step when it tries to work out what formats are mappable. [01:16:51 CEST] <jkqxz> The test is mapping YUYV as separate planes and failing with that error. [01:17:00 CEST] <jkqxz> I don't see why it would have been changes by that commit, though. [05:17:30 CEST] <cone-157> ffmpeg 03Steven Liu 07master:a7429d853de0: avfilter/buffersink.h: fix comment typo of av_buffersink_get_samples [15:10:41 CEST] <durandal_1707> http://sound-of-pixels.csail.mit.edu/ -----> this my next project [15:12:26 CEST] <thardin> now generate mpeg-7 metadata for each instrument [15:58:26 CEST] <cone-383> ffmpeg 03Steven Liu 07master:bb660800a55f: avformat/utils: move mkdir_p to utils [16:38:05 CEST] <BBB> atomnuker: ty for msac patch, so are you interested in the idea of rewriting it, or not really? [16:38:44 CEST] <cone-383> ffmpeg 03Paul B Mahol 07master:d6e50e0716d5: avfilter/vf_curves: add planar rgb support [17:31:14 CEST] <cone-383> ffmpeg 03Matthieu Bouron 07master:e294b5cf6464: RELEASE: update for git after 4.0 branchpoint [18:16:42 CEST] <kierank> anyone actually in paris? [18:18:31 CEST] <BBB> me [18:18:41 CEST] <BBB> henrik and luc also [18:18:44 CEST] <BBB> and some videolan people [18:19:09 CEST] <kierank> I have a ticket for biffy clyro tonight at the bataclan [18:26:34 CEST] <BBB> isnt bataclan that place? [18:27:43 CEST] <kierank> yes [18:30:50 CEST] <durandal_1707> this is ffmpeg development channel, for finding people who will take free ticket(s) search elsewhere [18:35:08 CEST] <BBB> Im trying to imagine my wifes reaction if I tell her I went to a concertn in that place :-p [18:36:22 CEST] <BBB> also, listening to that band, I think its for dates, not nerds? [18:36:27 CEST] <BBB> I dont know [18:40:37 CEST] <kierank> BBB: probably true but I have been given 2 free ticket [18:41:29 CEST] <BBB> probably not quite my thing, sorry& but thanks for asking [18:43:41 CEST] <durandal_1707> kierank: find (x/y/xy/yx)friend in that fancy hotel? [18:43:56 CEST] <kierank> not doable in 15 minutes [18:47:30 CEST] <BBB> ignore concert and go have a nice dinner with us [18:48:38 CEST] <kierank> I need to find some time away from tech for a while [18:48:48 CEST] <kierank> but maybe a pint after your dinner if you are still free [18:54:07 CEST] <BBB> ok, happy to [19:32:50 CEST] <durandal_1707> huh, KGB? some ffv1 commit did not get through? [19:54:31 CEST] <cone-383> ffmpeg 03Paul B Mahol 07master:efb65abedf40: avfilter: add audio denoising (afftdn) filter [21:01:00 CEST] <llogan> durandal_1707: forgot about that one [21:01:23 CEST] <durandal_1707> llogan: Carl? [21:01:37 CEST] <llogan> yeah. look at what you started. [21:01:53 CEST] <llogan> that one is already in the heap, so perhaps it will go up the queue [21:02:12 CEST] <durandal_1707> we should finally start using our names: Carl, Michael, James, Lou [21:06:57 CEST] <BradleyS> durandal_1707: see, i knew you were four people [21:31:45 CEST] <kierank> Gramner: are you guys around in 30-40 minutes? [21:38:03 CEST] <durandal_1707> i'm coming pronto: https://www.youtube.com/watch?v=VSrEIdhrXB4 [21:52:00 CEST] <durandal_1707> github down! [22:16:07 CEST] <kierank> SAD! [22:16:53 CEST] <durandal_1707> kierank: it is no more down [22:18:26 CEST] <gnafu> Thanks, Microsoft! [22:24:14 CEST] <durandal_1707> michaelni: please fix KGB [00:00:00 CEST] --- Wed Sep 26 2018

1 0

ffmpeg.log.20180925
by burek 26 Sep '18

26 Sep '18

[07:25:44 CEST] <acresearch> hello people, i have a video that i want to add to keynotes, but i think apple stopped allowing any video format except .gif is it possible to convert my video from .mp4 to .gif? [07:27:43 CEST] <Matador> fun freakin times [07:28:36 CEST] <acresearch> i tried ffmpeg -i video.mp4 -o video.gif but that did not work, any help please? [07:29:12 CEST] <acresearch> my video is 150MB would it be possible to convert to .gif? i alway simagine .gif as low quality videos, is that true? [07:49:00 CEST] <acresearch> i tried .avi but that does not work either. how do i find out what format works with keynotes apple? it seems no format does [08:31:33 CEST] <LigH> Hi. [08:33:29 CEST] <LigH> If I export single frames from a video as images, I can add the running number of the image to the file name via sprintf placeholder (e.g. %04d); is it also possible to use the number of the frame in the video instead of an increase +1? [08:34:32 CEST] <LigH> Like, the first frame being exported is number 0, so it becomes "0000", but the next frame is from video frame 25, so it shall be 0025 instead of 0001. [08:46:28 CEST] <JEEB> 19 [09:09:09 CEST] <LigH> o? [09:40:34 CEST] <LigH> When exporting images from video frames, does the number placeholder only support +1 increasing numbers? [10:05:39 CEST] <Nacht> LigH: As apposed to ? [10:06:42 CEST] <LigH> There is a question in our German video forum if there is a way to use the original frame number instead, when frames are exported to images via a filter which selects I-frames only. [10:07:02 CEST] <durandal_1707> no [10:08:38 CEST] <LigH> Well, thank you for this definitive answer... [10:08:44 CEST] <LigH> Bye. :) [11:49:30 CEST] <kwizart> hello, if anyone can provide use some help to know what's wrong with our ffmpeg compilation failing on arm (only with fedora 29 target, not with f28 or f30) [11:49:33 CEST] <kwizart> https://bugzilla.redhat.com/show_bug.cgi?id=1632636 [11:54:20 CEST] <BtbN> Are you trying to run a library? oO [12:04:28 CEST] <kwizart> BtbN, apparently this is what ldd does [12:42:52 CEST] <kwizart> the ldd test is failing because of function or data relocation issue [14:27:57 CEST] <barhom> I am transcoding HLS INPUT to HLS output, then I am reading the transcoded hls files with ffmpeg -re -i /tmp/hls/transcoded_input.m3u8 and outputting to UDP [14:28:12 CEST] <barhom> I am trying to make a UDP output that is "streamed" and not "bursty" [14:28:48 CEST] <barhom> Sometimes the output is still bursty and I have no idea how to fix it. Do you know what Im trying to achieve? Any tips? [16:00:56 CEST] <teratorn> anyone familiar with image mosaic with ffmpeg and/or opencv? e.g. stitching two or more images side-by-side to form a panorama? i'm looking around at various example code, including the Mosaic class from the Camera app in android and looking for options (?) [16:56:44 CEST] <sine0> ok, so is there any easy way to work out an aspect ratio from a single dimensio [16:57:15 CEST] <sine0> so width is 960 pixels, I want it 4:3 and 16:9 so what would the height be for both of those [16:57:25 CEST] <sine0> I know its 540 from habit for 16:9 [16:57:41 CEST] <kepstin> assuming square pixels (i.e. sar = 1/1)? [16:57:47 CEST] <sine0> yea [16:57:57 CEST] <Mavrik> 960 / (16/9) = 540 [16:58:03 CEST] <Mavrik> It is a ratio after all ;) [16:58:07 CEST] <furq> in what context do you need to know this [16:58:26 CEST] <sine0> im making images of different web sizes [16:59:37 CEST] <sine0> Mavrik: Ill try and do that in bc [17:00:44 CEST] <furq> if you just want a one-size-fits-all thing to pass to -vf scale then -vf scale="if(gt(a\,16/9)\,960\,-2):if(gt(a\,16/9)\,-2\,540)" [17:01:22 CEST] <Mavrik> although, scale="960:-2" would work better I guess? :) [17:02:06 CEST] <furq> well yeah sure if you actually read the question then that's a better answer [17:02:26 CEST] <Mavrik> Uhh. [17:02:30 CEST] <Mavrik> Hm. [17:02:31 CEST] <furq> i meant your answer [17:02:42 CEST] <kepstin> doesn't the scale filter preserve sar tho? so both of those will give unexpected results with non-square-pixel input video. [17:02:46 CEST] <Mavrik> I honestly don't really know what the endgoal is :D [17:03:28 CEST] <furq> i'm used to people asking for "how do i scale to 576p" in which case my answer is right (assuming square pixels) [17:03:36 CEST] <furq> but if the width is always 960 then yeah just 960:-2 [17:05:58 CEST] <sine0> omg i have set this chan on fyre [17:29:53 CEST] <BigNick> I was wondering if anyone had a parameter list for the target preset ntsc-dvd? Or is there a preset file which I can review these parameters? [18:06:41 CEST] <BigNick> *update, found the settings in the source [18:18:11 CEST] <c_14> BigNick: fftools/ffmpeg_opt.c lines 2795-2815 [19:47:57 CEST] <^Neo> Hello friends, does anyone here have experience with DeckLink cards and would be willing to answer some questions about leveraging FFmpeg and DeckLink? [20:12:54 CEST] <ChocolateArmpits> ^Neo, go ahead [21:02:12 CEST] <gustavbarnacle> Looking for some help with a concat issue. I have three videos that, individually are playable but when joined with concat are unplayable and the resulting duration is not right. Expected an output with a duration of 00:06:20, instead received an output of 124:05:43.. I think this has to do with vbr of the a and b videos. https://pastebin.com/SF4ykBcB [21:06:50 CEST] <ChocolateArmpits> gustavbarnacle, what's with the last video's framerate? [21:07:33 CEST] <ChocolateArmpits> maybe it's a timestamp issue [21:08:16 CEST] <gustavbarnacle> ~2x2.mp4 has fps of 30.10 [21:08:37 CEST] <ChocolateArmpits> gustavbarnacle, well that implies the source is unlike the first two videos [21:09:26 CEST] <gustavbarnacle> a.mp4 and b.mp4 have 30fps. Is the difference between 30 and 30.10 causing an issue? [21:10:14 CEST] <ChocolateArmpits> I guess the file would simply end up being flagged as vfr, but I think the timestamps may be off [21:11:13 CEST] <ChocolateArmpits> gustavbarnacle, could you give the ffprobe output of the output file? [21:13:04 CEST] <gustavbarnacle> https://pastebin.com/D6X6p38F. Fps is definitely the issue - output is 0.03fps. [21:13:24 CEST] <ChocolateArmpits> well then from that you get the insane duration [21:14:21 CEST] <ChocolateArmpits> gustavbarnacle, did you consider transcoding the video? [21:14:43 CEST] <gustavbarnacle> Right, I'm learning here. a.mp4 and b.mp4 are created from ffmpeg by looping a single jpg for 20 secs. ~2x2.mp4 is created from use hstack/vstack on 4 other videos. [21:15:34 CEST] <gustavbarnacle> Transcoding is much slower than concat, right? [21:15:48 CEST] <ChocolateArmpits> gustavbarnacle, well as an alternative to -c copy [21:15:55 CEST] <ChocolateArmpits> you'd still be concating anyways [21:16:01 CEST] <ChocolateArmpits> concatenating* [21:19:44 CEST] <gustavbarnacle> Can you point me in the right direction - i can't just drop the -c copy from the command, can I? [21:20:40 CEST] <ChocolateArmpits> gustavbarnacle, but you can, then ffmpeg will use default options to transcode that fit the output file [21:21:04 CEST] <ChocolateArmpits> in the case of mp4, h264 for video and aac for audio [21:36:17 CEST] <gustavbarnacle> Running the command without -c copy hangs and throws "More than 1000 frames duplicated" [21:36:45 CEST] <ChocolateArmpits> ok then something is really wrong with the third file [21:38:23 CEST] <gustavbarnacle> I was assuming that the 1000 duplicated frames is because the 'a' and 'b' videos were each created from a single jpg and are just repetitive frames. [21:40:25 CEST] <gustavbarnacle> The third video plays ok. Here is the output from when it was created: https://pastebin.com/TkAh9rmk [21:42:32 CEST] <ChocolateArmpits> gustavbarnacle, is a and b actually a single frame video, or are the populated with frames? frame duplication can also happen when there's a missing sequence of timestamps [21:42:38 CEST] <ChocolateArmpits> they* [21:44:31 CEST] <gustavbarnacle> How can I tell. Command used to create a.video is: ffmpeg.exe -framerate 1/20 -i "C:\dev\a.jpg" -y -c:v libx264 -r 30 -pix_fmt yuv420p "C:\dev\a.mp4" [21:58:58 CEST] <relaxed> gustavbarnacle: you want a single frame to be looped 30 fps in your output video? [22:03:43 CEST] <jorb> can ffmpeg do midi output encoding? [22:06:00 CEST] <kepstin> jorb: midi isn't really an "encoding", that doesn't make sense. [22:06:36 CEST] <kepstin> (generating a midi file for a piece of music is something that you'll want to hire a musician to do, since it basically involves transcribing the music and doing an arrangement of it) [22:08:26 CEST] <jorb> kepstin: ok [22:09:02 CEST] <jorb> there seem to be a ton of midi to an encoded format type programs [22:09:31 CEST] <jorb> i didn't realize it was not as simple to go from a mp3 or wave to midi.. [22:09:44 CEST] <kepstin> yeah, if you have a midi file, you can "play" it in a midi synthesizer to get a wave file back and encode that to anything [22:09:49 CEST] <jorb> i mean it wouldn't be applicable for most actual audio too i suppose [22:10:16 CEST] <kepstin> midi is basically like a piece of sheet music [22:10:28 CEST] <kepstin> it's instructions on how to play a song, not the audio for a song [22:11:14 CEST] <jorb> what i have is a wave file of morse code, so midi makes perfect sense, and would be so easy to parse! [22:11:40 CEST] <jorb> i tried this program morse2ascii, and it produces the output, but it doesn't seem to detect spaces, i'm just tyring to figure out how to parse it [22:13:06 CEST] <kepstin> detecting morse code (with minimal background noise) in an audio file shouldn't be very hard, I wish you luck. I imagine there's a lot of related software for that in the amateur radio community. [22:13:40 CEST] <kepstin> (and my impression was that morse didn't really have spaces? you might end up needing to use a dictionary or something to figure out where spaces should be) [22:14:34 CEST] <gustavbarnacle> relaxed: sort of. I want a single frame looped 20 sec (30fps), a different single frame looped 20 sec (30fps), then a four panel video made from hstack/vstack. [22:14:49 CEST] <jorb> the other suggestion i've gotten so far is to load it into audacity and just look at the audio spectrograph [22:16:25 CEST] <jorb> kepstin: yeah that was my first thought, but it seems the characters are diffrent lengths, not a simple byte encoding heh [22:17:25 CEST] <kepstin> jorb: if you take the signal and run it through an fft (like the spectrogram does), it's pretty easy to detect symbol start and stop times programmatically. after reading up a bit, people say "there are tiny gaps between letters and slightly longer gaps between words" [22:17:49 CEST] <kepstin> of course, with hand-keyed morse those gaps may or may not be super consistent :) [22:18:58 CEST] <relaxed> gustavbarnacle: try, ffmpeg.exe -loop 1 -i "C:\dev\a.jpg" -y -c:v libx264 -r 30 -t 20 -pix_fmt yuv420p "C:\dev\a.mp4" [22:19:29 CEST] <gustavbarnacle> relaxed: thanks, I'll try. [22:20:03 CEST] <durandal_1707> use loop filter [22:25:25 CEST] <gustavbarnacle> relaxed: ffmepg.exe -loop1 command creates an identical video to the ffmpeg.exe -framerate 1/20 -i "C:\dev\a.jpg" -y -c:v libx264 -r 30 -pix_fmt yuv420p "C:\dev\a.mp4" command. Same problem exists when final video is concat. [22:26:52 CEST] <relaxed> you can probably do this with one command using -filter_complex and needs filters [22:27:00 CEST] <relaxed> needed* [22:28:33 CEST] <gustavbarnacle> relaxed: that's I think where I'm heading next. I am already encoding the 2x2.mp4 video with: ffmpeg.exe -i "C:\dev\~upper_left.mp4" -i "C:\dev\~upper_right.mp4" -i "C:\dev\~lower_left.mp4" -i "C:\dev\~lower_right.mp4" -filter_complex "[0:v][1:v]hstack=shortest=1[t];[2:v][3:v]hstack=shortest=1[b];[t][b]vstack=shortest=1[v]" -map "[v]" -shortest -y "C:\dev\~2x2.mp4" [22:29:02 CEST] <gustavbarnacle> Can I create one filterchain to create and add the two 20 videos from still images first? [22:30:26 CEST] <relaxed> you may want to start with the images, otherwise you're encoding the same thing twice [22:30:49 CEST] <relaxed> durandal_1707 said use the loop filter [22:31:02 CEST] <ChocolateArmpits> gustavbarnacle, there's a concat filter to join several streams together on the filter graph [22:38:48 CEST] <GuiToris> ChocolateArmpits, hey, by the time I got to check that profile, you'd already left. I just wanted to say thank you, -pix_fmt yuv420p -vprofile main solved the problem. It can be played back now [22:38:59 CEST] <ChocolateArmpits> GuiToris, cool [00:00:00 CEST] --- Wed Sep 26 2018

1 0