[Ffmpeg-devel-irc] ffmpeg.log.20180429

[burek]

[01:08:17 CEST] <amaurea> I'm using the command ffmpeg -f concat -safe 0 -t 10 -i "$ifile" -vf setpts=1/4*PTS,vidstabtransform=smoothing=60,unsharp=5:5:0.8:3:3:0.4 -r 30 -an -y "$ofile" to concatenate stabilize and speed up a video. It is quite high resolution (2704x1520), but even so the speed I'm getting is surprisingly slow, at 0.7 fps. So I wonder if I'm doing something wrong. In particular, I wonder if the dropping of frames needed to speed up the video by 4 times, as this command
[01:09:41 CEST] <amaurea> Since the starting point is a 60 fps video, and the output is a 4x fast forward 30 fps video, that means that in the end only one frame in 8 will be used in the output. Hence the point at which the frame dropping happens should matter a lot for the speed
[01:10:25 CEST] <amaurea> The ffmpeg version is 3.4.2 on linux
[01:14:12 CEST] <furq> amaurea: -r 30 will just append -vf fps to the end of the filterchain
[01:14:55 CEST] <amaurea> I assume that the actual video encoding happens after the whole filterchain?
[01:14:57 CEST] <furq> yes
[01:15:08 CEST] <amaurea> So I would still only be encoding 1/8 of the original frames, then
[01:15:10 CEST] <furq> i guess you might want to put it before vidstabtransform but idk if that'll make any difference
[01:15:14 CEST] <klaxa> but filtering all of them
[01:15:18 CEST] <amaurea> The redundant part is the stabilization of frames that would be dropped
[01:15:36 CEST] <amaurea> Would the select filter be better, then?
[01:16:11 CEST] <furq> select,setpts might be faster
[01:16:22 CEST] <amaurea> thanks, I will try that
[01:16:34 CEST] <furq> x264 with default settings shouldn't be that slow at ~1440p
[01:16:39 CEST] <furq> so i guess vidstab is bottlenecking it
[01:17:00 CEST] <amaurea> (otherwise my video would take half a week to encode
[01:17:25 CEST] <furq> i guess lowering the smoothing value might help as well
[01:17:32 CEST] <furq> i've never really used vidstab so that's just a guess
[01:17:44 CEST] <amaurea> Maybe it's a bit high. The video is quite shaky, though..
[01:17:49 CEST] <amaurea> I'll experiment a bit
[01:18:16 CEST] <furq> i take it $ofile ends in either mkv or mp4
[01:18:26 CEST] <furq> otherwise it might be defaulting to some worse codec
[01:19:00 CEST] <amaurea> Yes, it's mp4 since mkv is poorly supported by browsers etc.
[01:19:24 CEST] <furq> you can maybe try -preset superfast
[01:19:35 CEST] <amaurea> Is that a lot faster than fast?
[01:19:43 CEST] <furq> the default is medium
[01:20:04 CEST] <furq> but yeah if vidstab is the bottleneck then ffmpeg won't be using close to 100% cpu
[01:20:05 CEST] <amaurea> I tried fast, and it didn't make any noticable difference. Which makes me think that the encoding isn't the bottleneck
[01:20:17 CEST] <furq> if it's not then changing the x264 preset won't make any difference
[01:20:28 CEST] <furq> if it's not using close to 100% cpu, that is
[01:21:09 CEST] <furq> it's probably also worth testing without unsharp, although that's probably not the issue
[01:21:14 CEST] <furq> but it's good to rule it out
[01:21:30 CEST] <amaurea> Ok, I'll keep you updated on the result
[01:25:26 CEST] <kepstin> furq: amaurea: the -r output option actually *doesn't* put the fps filter on, it behaves slightly differently
[01:25:40 CEST] <kepstin> (i normally recommend using the fps filter instead, it has better rounding behaviour imo)
[01:25:47 CEST] <furq> oh yeah this came up recently didn't it
[01:25:54 CEST] <furq> either way it won't take affect until after the rest of the filterchain
[01:25:58 CEST] <furq> effect
[01:26:24 CEST] <kepstin> yeah, the -r option takes effect when muxing the encoded video into the container, iirc
[01:26:35 CEST] <kepstin> and the fps filter takes effect wherever you put it :)
[01:27:04 CEST] <kepstin> er, no, -r has to be before the encoder
[01:27:11 CEST] <furq> right
[01:27:15 CEST] <kepstin> between the filter chain and encoder, not sure exactly where
[01:36:48 CEST] <amaurea> 1.7 fps with select and without unsharp
[01:37:00 CEST] <amaurea> I'll try a simpler plain reencode test, with no filters
[01:55:40 CEST] <amaurea> Encoding 10 s of video with default settings takes 107 s. 10 s of input video with select=mod(n\,8) and setpts=1/8*PTS takes 25 s, as does setpts=1/4*PTS with -r 30. So encoding only 1/8 of the frames is not 8 times faster, only 4
[01:56:19 CEST] <furq> well those are encoding the sane number of frames because of -r 30
[01:56:23 CEST] <furq> same
[01:56:55 CEST] <amaurea> you mean the 1/8 and 1/4 examples, right?
[01:57:01 CEST] <amaurea> Those were supposed to be the same
[01:57:17 CEST] <amaurea> I expected both of them to be 8x faster than the plain encode, since the original video is 60 fps
[01:58:01 CEST] <kepstin> I wouldn't expect a linear speedup, because video decoding becomes a larger portion of time used as you decrease the number of frames encoded.
[01:58:13 CEST] <furq> if you're going from 60 to 30 then i'd only expect that to be about twice as fast
[01:58:31 CEST] <furq> but it's probably duplicating some frames which would account for the rest of the speedup
[01:59:00 CEST] <amaurea> furq: I'm going from 60 to 30, but it's 30 after dividing the PTS by 4, so effectively it's like going from 60 to 7.5
[01:59:08 CEST] <kepstin> using a setpts=1/4*PTS and setting an output framerate <= input should only drop frames.
[01:59:26 CEST] <amaurea> kepstin: so all the frames are decoded, even those that will be dropped?
[01:59:28 CEST] <kepstin> (it'll shorten the run time of the video)
[01:59:28 CEST] <furq> oh yeah you're speeding it up
[01:59:32 CEST] <kepstin> amaurea: yes
[02:00:18 CEST] <kepstin> amaurea: there's some tricks that can be done to e.g. only decode keyframes, but that depends on the video having a keyframe interval suitable for what you want to do.
[02:00:29 CEST] <amaurea> Encoding 10 s with hwaccel and superfast took just 19 s
[02:00:39 CEST] <amaurea> without any frame dropping etc.
[02:00:49 CEST] <amaurea> kepstin: that makes ense
[02:02:07 CEST] <amaurea> superfast without hwaccel: 25 s
[02:12:57 CEST] <amaurea> 10 s with hwaccel, superfast, motion estimation and motion compensation: 150 s. So clearly the motion stuff totally dominates
[02:20:24 CEST] <amaurea> I think the main conclusion here is that the resolution is too high. I get more tolerable results with rescaling to 1280:720
[02:42:58 CEST] <nohop> Hey guys. I'm using an ffmpeg to stream to ffserver using: /usr/bin/ffmpeg -v 2 -r 2 -s 640x480 -f video4linux2 -i /dev/video0 http://localhost:8090/webcam.ffm
[02:43:27 CEST] <nohop> The framerate, however, is much higher than 2 (around 4-5 or so). Am I missing something?
[02:55:48 CEST] <kepstin> nohop: first of all, ffserver isn't supported any longer, so we can't help you with any problems specific to that
[02:56:30 CEST] <kepstin> nohop: you should not use the -r option with live inputs - please either use the -framerate option to request the input use a different framerate (if supported), or use the -r *output* option or -vf fps filter instead.
[02:58:56 CEST] <nohop> ffserver is no longer supported?! That makes me a little sad. It has been with us for so many years! :)
[02:59:40 CEST] <klaxa> i'm working on a replacement through google summer of code, so maybe after the summer there is something usable that replaces the old ffserver
[03:00:35 CEST] <nohop> And, ah... So it's probably the 'if supported' part. I thought maybe ffmpeg would 'resample'.. In my case I'd actually be fine throwing away frames to the point where I average ~2fps. That's a little hacky though, so I'd understand if there's no option for that :)
[03:00:49 CEST] <nohop> klaxa: Nice!
[03:02:48 CEST] <kepstin> nohop: if you want ffmpeg to drop/duplicate frames to get exact 2fps output, the fps filter is the way to go.
[03:07:49 CEST] <nohop> As in -vf "fps=2" ?
[03:12:47 CEST] <kepstin> yeah
[03:14:43 CEST] <nohop> Doesn't seem to change anything...
[03:15:23 CEST] <nohop> It's also not that big a deal, just wanted to reduce a tiny bit of CPU load on this old little intel atom n270 board :)
[03:20:28 CEST] <kepstin> heh. at least you don't need to apply spectre/meltdown fixes on that :)
[03:22:26 CEST] <nohop> On the other hand, compiling shit on it gives you cancer. So I guess there's pros and cons :)
[03:24:57 CEST] <nohop> I haven't really followed much of that whole debacle. Are there now patches/hacks/workarounds in the mainstream kernel to 'protect' against it at all?
[03:26:04 CEST] <nate> there have been patches since before it was even announced (though it was patches to the linux kernel which lead to people figuring out the vulnerability which then lead to the early announcement)
[03:26:25 CEST] <nate> (for meltdown anyways, spectre's been getting rolled out a bit more carefully)
[03:26:47 CEST] <kepstin> the kernel has a pretty decent set of patches to protect itself now, but it requires microcode updates (only available on recent cpus) to fully apply. Some userspace apps that run/interpret untrusted remote code - like browsers - needed some work as well.
[03:27:15 CEST] <nohop> model name      : Intel(R) Xeon(R) CPU           W3520  @ 2.67GHz
[03:27:24 CEST] <nohop> Probably shit-out-of-luck with this old beast huh :)
[03:27:30 CEST] <nohop> (Not that I care, really)
[03:28:35 CEST] <kepstin> looks like the W3520 is one generation older than the oldest they have updates for
[03:29:03 CEST] <kepstin> looking at the intel guidance, they might still have something for it later, not sure
[03:29:41 CEST] <nate> nohop: Intel released patch/microcode stuff for every CPU made since I believe the P2 era
[03:30:03 CEST] <nate> or whatever was the earliest vuln ones
[03:30:05 CEST] <nate> Was that P4?
[03:30:33 CEST] <kepstin> microcode updates have only been released for second generation "core" series chips and later from intel
[03:30:49 CEST] <kepstin> and some first generation core series, and a few later atom chips
[03:31:13 CEST] <kepstin> vulnerable chips are anything with speculative execution, which iirc is pentium pro and later excluding some early atom chips.
[03:31:17 CEST] <nohop> Ah. Oh well.
[03:32:17 CEST] <nohop> Yeah, I watched some talks on the vuln. It's actually a pretty exciting one, I thought :)
[03:34:52 CEST] <nate> kepstin: That's variant 2 isn't it?  They claim they "can't" microcode fix variant 2 on older stuff, but variant 1 I thought they were doing a mix of microcode+software patches going back ages
[03:35:03 CEST] <nate> https://downloadcenter.intel.com/download/27591 <-- this one specifically, which looks like it goes back at least to the P2 Xeons
[03:35:15 CEST] <nate> Or sorry, original pentiums actually
[03:37:09 CEST] <kepstin> yeah, variant 1 can be mitigated purely in software (which on older systems reduces performance quite a bit - newer processors have features that reduce the overhead)
[03:40:13 CEST] <kepstin> variant 2 iirc can be mostly mitigated in software (retpoline), but there's some weird cases with preemption or something that can break it so microcode fixes are usually used in combination.
[03:40:32 CEST] <kepstin> er, i'm getting 1 and 3 mixed up
[03:40:44 CEST] <kepstin> anyways, this isn't really the place to talk about it, so I'm gonna shut up now :)
[03:49:30 CEST] <Kadigan> Hey. When I split a file but do -c:v copy -c:a copy, I'm not guaranteed to have the segment start on an i-frame, am I?
[03:50:37 CEST] <kepstin> Kadigan: using the segment muxer? ffmpeg will by default adjust the segment lengths so they start on keyframes
[03:51:14 CEST] <Kadigan> I'm trying to understand ordered chapters, so I took a TV series I have and split off the intro sequence and the episodes (2 for now)
[03:51:34 CEST] <Kadigan> and it seems it's working, but... when the next segment starts, I have blank video until something happens...
[03:51:58 CEST] <Kadigan> I'm not sure what that "something" is. When I play the "cut off" file back directly, the same happens.
[03:52:05 CEST] <Kadigan> When I seek or something, it shows video.
[03:52:30 CEST] <furq> how did you split it
[03:52:55 CEST] <furq> if you used -ss and the file has audio then you'll probably end up with a video delay
[03:53:12 CEST] <Kadigan> I did. How should I do this?
[03:53:40 CEST] <furq> i'm not really aware of an elegant way other than finding the correct timestamp of the nearest iframe
[03:54:26 CEST] <Kadigan> I need to cut on that spot. So what, I need to use a NLE?
[03:54:33 CEST] <Kadigan> an*
[03:56:52 CEST] <furq> ffprobe -show_frames -show_entries frame=pict_type,best_effort_timestamp_time test2.mkv | grep -B1 pict_type=I
[03:57:01 CEST] <furq> that should give you the timestamps of every idr frame
[03:57:35 CEST] <furq> hopefully you're not on windows
[04:04:39 CEST] <Kadigan> ... I am. :)
[04:04:55 CEST] <Kadigan> I realized I could cut via Premiere Pro and just recode the whole thing,
[04:05:11 CEST] <Kadigan> but then I also realized that the audio doesn't end cleanly and would pose problems down the line.
[04:05:43 CEST] <Kadigan> So I'm forgetting this idea. I <did> get ordered chapters working, though, before I ran into all sorts of trouble, so <that> part of the activity went just fine... :D
[04:06:03 CEST] <Kadigan> Also helped me understand ordered chapters, which is nice.
[04:06:06 CEST] <Kadigan> Thanks, anyway. :)
[10:30:48 CEST] <acresearch> hello people, i have a video .mp4 at 150MB    i want to reduce its size to 5MB but keep it at .mp4 encoding i understand i would lose quality but how can i setup the command? any help?
[10:30:56 CEST] <acresearch> no audio in the video
[10:42:27 CEST] <Mavrik> acresearch, how long is the video? In minutes / seconds?
[10:43:02 CEST] <acresearch> Mavrik: 1:20
[10:45:34 CEST] <Mavrik> So you need to reduce bitrate of the video to about 500kbps
[10:45:59 CEST] <acresearch> Mavrik: sure as long as i get low memory
[10:46:20 CEST] <Mavrik> (500 kbit/s * 80 s) / 8 = ~5MB
[10:46:49 CEST] <Mavrik> so something like ffmpeg -i <your video>.mp4 -codec:v libx264 -b:v 500k -preset slow output.mp4 should do the trick
[10:48:22 CEST] <Mavrik> acresearch, what's the resolution of your video?
[10:48:38 CEST] <acresearch> 4k
[10:48:45 CEST] <Mavrik> ah, I'd suggest reducing that
[10:48:55 CEST] <Mavrik> Or you'll get a blurry blotch :P
[10:49:21 CEST] <Mavrik> add "-vf scale=-2:480" to that commandline :)
[10:55:26 CEST] <acresearch> Mavrik: thanks
[12:17:24 CEST] <kerio> hm, would a 4k video viewed as 480p look worse than a video scaled to 480p before encoding, given the same bitrate?
[12:21:51 CEST] <sfan5> definitely not
[12:22:32 CEST] <sfan5> though.. by "same bitrate" you mean encoding 4k video at the bitrate you would use for 480p?
[12:22:43 CEST] <kerio> yep, see the backscroll
[12:23:26 CEST] <iive> yes it would definitely look worse.
[12:35:53 CEST] <Mavrik> Yes, it'll look like a shapeless blob :P
[12:36:15 CEST] <Mavrik> You can't record 3840x2160 worth of pixels at 30fps into 500.000 bits per second :P
[12:54:10 CEST] <iive> let's say that you use format that has 4x4 dct blocks. one such block would be like 1 pixel in the SD image.
[12:54:56 CEST] <iive> so you will effectively use only DC part of the encoding. If the format has loopfilter, it might smooth the edges of the blocks.
[12:55:44 CEST] <iive> still, you'd have to spend some bits in order to fix the errors caused by the artifacts and you don't have any extra bits to spare.
[14:14:12 CEST] <voltagex> Out of interest, is x265 encoding likely to get much faster in the coming years, other than through CPU improvements?
[14:16:12 CEST] <JEEB> that is up to the x265 development team, which currently is 99% developers from MultiCoreWare
[14:17:20 CEST] <iive> i don't think they have that as a major goal...
[14:17:47 CEST] <iive> but that's just my own speculation.
[14:18:38 CEST] <voltagex> Is 1.8fps using veryslow on a 6 core Intel normal? 1080p transcode
[14:18:47 CEST] <JEEB> that sounds like fast
[14:18:56 CEST] <JEEB> with x264 in 2006 I was having 0.6fps
[14:19:03 CEST] <JEEB> with slow settings
[14:20:13 CEST] <voltagex> That's good perspective, thanks
[14:20:53 CEST] <JEEB> granted it seems like veryslow is still on the faster side with x265, they noted that they would be adding another preset between veryslow and placebo later
[14:21:12 CEST] <JEEB> because the jump is pretty big right now in performance with veryslow to placebo
[14:22:09 CEST] <voltagex> As in placebo is much slower?
[14:22:17 CEST] <JEEB> yea
[14:22:23 CEST] <voltagex> Sigh
[14:22:25 CEST] <JEEB> before all the presets very geared a bit slower
[14:22:36 CEST] <JEEB> so the change between veryslow and placebo wasn't that big
[14:22:37 CEST] <JEEB> now it is
[14:22:43 CEST] <JEEB> so they will be adding a middle point I guess
[14:23:10 CEST] <voltagex> Question is now, do I build a dedicated Threadripper encoding box, or spend the same amount of money on AWS
[14:23:48 CEST] <JEEB> depends on your needs completely. on the longer run, do you think your needs for encoding will stay the same?
[14:23:59 CEST] <JEEB> because IIRC AWS and similar things make you pay quite a bit for the CPU time
[14:24:11 CEST] <JEEB> if you are using it constantly
[14:24:24 CEST] <voltagex> By splitting the file among 20 AWS boxes I was able to encode at about realtime for ~$1/hour
[14:24:28 CEST] <JEEB> if you have very limited needs on-demand
[14:24:33 CEST] <JEEB> then AWS etc makes sense
[14:24:40 CEST] <voltagex> Bandwidth costs killed me
[14:24:50 CEST] <JEEB> as in, you don't need to have the things running all the time
[14:24:59 CEST] <JEEB> then not having a dedicated box might be useful
[14:25:01 CEST] <voltagex> Yeah, I don't
[14:25:21 CEST] <JEEB> try to also check other places like google's thing etc
[14:25:32 CEST] <JEEB> to see the best price/perf on other people's hardware
[14:25:39 CEST] <voltagex> I'm looking at packet.net's threadripper boxes too
[14:25:40 CEST] <JEEB> for your use case
[14:25:58 CEST] <voltagex> I also need to get my x265 settings right
[14:27:52 CEST] <voltagex> Hm, speed is one of thier project goals - http://x265.org/
[14:33:04 CEST] <JEEB> well yea, realtime is already possible
[14:33:13 CEST] <JEEB> you just need to use one of the faster presets
[14:33:34 CEST] <arnold> knock knock
[14:46:31 CEST] <kerio> who's there
[14:54:31 CEST] <kerio> voltagex: check out hetzner, if you're in europe
[14:54:36 CEST] <kerio> cheap iron
[15:22:09 CEST] <arnold> do you guys have example mux AAC and h264 to mp4 file
[15:30:05 CEST] <BtbN> pretty much any commandline from the h264/aac encoding wiki page
[19:12:17 CEST] <Madsfoto> G'day. I have a syntax issue, the command   ffmpeg -i Org.mov -vf tmix=frames=128 -c:v libx264 orgx264.mp4   only creates a tmix of 3 frames (the default). It's not   -vf tmix:frames=128 OR -vf tmix=frames:128  . What am I doing wrong?
[19:14:13 CEST] <durandal_1707> Madsfoto: you need add weights: "1 1 1 .... 1 1 1" 128 numbers :)
[19:15:18 CEST] <durandal_1707> perhaps, it would be good idea, to use last item to fill all the rest?
[19:15:53 CEST] <Madsfoto> last item to fill the rest?
[19:16:30 CEST] <durandal_1707> yes, do you need such feature? so you do not need to type 128 times '1 '
[19:16:50 CEST] <Madsfoto> To be honest I assumed it would do that automatically
[19:17:41 CEST] <Madsfoto> the syntax would be written how? -vf tmix=frames=20=weights="1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1"
[19:18:05 CEST] <Madsfoto> .. as an example (I don't want to spam 128 1's in here)
[19:18:27 CEST] <Madsfoto> so, yes, I would very much like such a feature
[19:18:32 CEST] <durandal_1707> ok
[19:22:08 CEST] <Madsfoto> The correct syntax (for logging reasons) is: ffmpeg -i Org.mov -vf tmix=frames=20:weights="1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1" -c:v libx264 orgx264.mp4
[19:25:09 CEST] <Madsfoto> Although, @durandal_1707 can I request it's written in the docs too, as an example? I think that's easier than coding the thing
[19:27:05 CEST] <durandal_1707> ok
[19:30:30 CEST] <ariyasu> what are weights?
[19:31:59 CEST] <Madsfoto> "Specify weight of each input video frame. Each weight is separated by space." I assume how much it's blended (so if you care most about the 3rd frame, you weight it more => giving it higher priority)
[19:43:46 CEST] <Madsfoto> Thank you very much. Now the waiting for the website/github to catch up begins :)
[20:38:04 CEST] <icy_hot> Hi guys, will really appreciate if anyone experienced with advanced ffmpeg settings can help me out. I know my way around but I´ll be at the summerhome for the next month or so, and I want to get out the *best* possible quality of ffmpeg with x264 coded for a 512 kbps connection to stream my live TV and movies on the limited connection. Here´s what I got so far but I think you can do much better: https://pastebin.com/63GnMc6b
[20:53:55 CEST] <klaxa> icy_hot: looks pretty sane to me, maybe see if slower presets are still acceptably fast
[20:54:19 CEST] <klaxa> that should increase the quality at the same bitrate at the expense of computation time
[20:55:58 CEST] <icy_hot> It does not help very much, medium seems to be the sweet spot, veryfast also is very good with almost unnoticeable disruption and considerably faster, but I've seen some way better results at 500 kbps
[21:29:40 CEST] <romano> Can someone explain to me how the select filter works when used with overlay filter?
[21:29:50 CEST] <romano> With the enable
[21:29:53 CEST] <dragmore88> good evening! So im trying to extract 6 mono channels from a prores file and encode a valid AC3 5.1 track.. but i have issues.. Anyone care to take a look? https://pastebin.com/HBZFb7uB
[21:41:00 CEST] <durandal_1707> dragmore88: you cant just copy paste random command, you need to understand stuff
[21:41:27 CEST] <durandal_1707> dragmore88: you will need to use join or amerge filter to merge all mono channels into 5.1
[21:41:40 CEST] <JEEB> I even linked him the audio filtering article the other day
[21:41:58 CEST] <durandal_1707> pan filter is not useful in this situation
[21:42:31 CEST] <JEEB> and I mentioned there was even an example where there were 6 inputs and 5.1 output was needed lol
[21:42:34 CEST] <JEEB> :P
[21:43:24 CEST] <JEEB> https://trac.ffmpeg.org/wiki/AudioChannelManipulation
[21:43:33 CEST] <JEEB> specifically https://trac.ffmpeg.org/wiki/AudioChannelManipulation#a6mono5.1
[21:54:24 CEST] <romano> Can someone explain to me how the select=between filter works when used with overlay filter?
[21:57:47 CEST] <durandal_1707> romano: like any other case, what you want to do?
[22:10:17 CEST] <cryptopsy> what does this asm error mean when compiling ffmpeg-4.0 ? https://clbin.com/I9S2B
[22:11:31 CEST] <JEEB> cryptopsy: do you enable PIC?
[22:11:34 CEST] <dragmore88> JEEB, as i said before.. the example doesnt cover my problem.. i have all in 1 source file, not 6 random wave files.. im just asking for help, and ive read the docs several times
[22:12:18 CEST] <durandal_1707> dragmore88: then use [2:a][3:a].., join=6 ...
[22:12:19 CEST] <JEEB> cryptopsy: seems like you do. various parts of hand-written SIMD use more registers than x86 has
[22:12:33 CEST] <JEEB> (when PIC is enabled)
[22:12:38 CEST] <cryptopsy> JEEB: what's pic?
[22:12:42 CEST] <durandal_1707> JEEB: failure is in inline libpostproc asm
[22:13:01 CEST] <durandal_1707> written eons before
[22:13:12 CEST] <JEEB> cryptopsy: position independent code
[22:13:34 CEST] <JEEB> cryptopsy: in other words one or more registers are being used to keep offsets if I recall correctly
[22:13:36 CEST] <cryptopsy> JEEB: just CFLAGS="-march=native"
[22:13:47 CEST] <cryptopsy> no flto no pipe no O3
[22:14:02 CEST] <JEEB> if you look at your build lines you clearly have PIC there
[22:14:02 CEST] <cryptopsy> -j3 MAKEOPTS
[22:14:11 CEST] <JEEB> -DPIC and -fPIC
[22:14:25 CEST] <cryptopsy> so -fno-PIC should save it?
[22:14:44 CEST] <JEEB> it would enable the SIMD to be built, if not then I was wrong :P
[22:14:55 CEST] <JEEB> this is a 32bit x86 specific issue
[22:15:10 CEST] <dragmore88> durandal_1707,is 2:a the 3rd source track or the 3rd target track ?
[22:15:25 CEST] <JEEB> 3rd input file
[22:15:26 CEST] <JEEB> audio track
[22:15:30 CEST] <cryptopsy> is that -fno-PIC or -fno-pic ?
[22:15:55 CEST] <JEEB> cryptopsy: I have no idea how gentoo calls it since it seems like it's overriding whatever FFmpeg's build system is doing
[22:16:05 CEST] <JEEB> since you don't have --enable-pic in your configure
[22:16:05 CEST] <cryptopsy> its a gcc option
[22:16:16 CEST] <cryptopsy> the compiler is gcc ..
[22:16:32 CEST] <JEEB> yes, but it is your gentoo build system setting that flag somehow, so have fun disabling it somehow
[22:16:50 CEST] <JEEB> because there's a flag in FFmpeg's configure which is called --enable-pic, which does this. but that is nowhere to be seen
[22:16:50 CEST] <dragmore88> something like this : ffmpeg -loglevel verbose -i "BBC_Short_HDR.mov" -filter_complex "[2:a][3:a][4:a][5:a][6:a][7:a]amerge=inputs=6[aout]" -map "[aout]" -acodec ac3 -ac 6 -ar 48000 -ab 448k test.ac3 ?
[22:17:00 CEST] <JEEB> that's a single input file
[22:17:12 CEST] <JEEB> in that case you want 0:a:N
[22:17:13 CEST] <dragmore88> correct, as it has allways been
[22:17:18 CEST] <dragmore88> k
[22:17:34 CEST] <JEEB> 0th (1st) input file, audio Nth (N+1st) audio stream
[22:17:47 CEST] <JEEB> (add one , after audio
[22:18:08 CEST] <dragmore88> ffmpeg -loglevel verbose -i "BBC_Short_HDR.mov" -filter_complex "[0:a:2][0:a:3][0:a:4][0:a:5][0:a:6][0:a:7]amerge=inputs=6[aout]" -map "[aout]" -acodec ac3 -ac 6 -ar 48000 -ab 448k test.ac
[22:18:23 CEST] <furq> you presumably want 0:a:0 through 0:a:5
[22:18:30 CEST] <dragmore88> (its the 3rd track counting from 0 since the first 2 are stereos
[22:18:33 CEST] <furq> oh
[22:18:33 CEST] <JEEB> he had two stereo tracks IIRC
[22:18:37 CEST] <furq> yeah 2 to 7 is correct then
[22:18:37 CEST] <JEEB> yea
[22:18:43 CEST] <JEEB> looks good
[22:18:50 CEST] <dragmore88> aaait
[22:19:31 CEST] <dragmore88> [Parsed_amerge_0 @ 000001ea74bc5f40] No channel layout for input 1
[22:19:32 CEST] <dragmore88> [Parsed_amerge_0 @ 000001ea74bc5f40] Input channel layouts overlap: output layout will be determined by the number of distinct input channels
[22:19:37 CEST] <dragmore88> ignore?
[22:19:44 CEST] <furq> yeah you don't care about the input channel layout
[22:21:14 CEST] <dragmore88> thx
[22:21:18 CEST] <dragmore88> looks like its working
[23:52:08 CEST] <leewdch> when I play an swf file it plays really fast for the first 5 seconds with desync audio that plays normally for the whole length of the video. what is happening?
[23:52:39 CEST] <leewdch> I tried decompressing it first but same result
[23:56:41 CEST] <tdr> you sure it was encoded right?
[23:57:01 CEST] <leewdch> it plays correctly in the browser
[23:57:11 CEST] <leewdch> it is also an old swf I found on internet
[00:00:00 CEST] --- Mon Apr 30 2018