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

[burek]

[00:06:13 CET] <eau4x6> I don't understand how audio-starts-before-video -ss -c copy behavior (https://trac.ffmpeg.org/wiki/Seeking#Seekingwhiledoingacodeccopy) would result in negative timestamp. if audio is supposed to start before video then timestamp of the first frame should be positive not negative. what i am missing?
[00:18:06 CET] <slalom_> Does anybody know how to change the initial start offset time with the HLS muxer?   I am trying to replicate adobe media encoder's HLS output with ffmpeg, but I can't get the playlist to have a different start time.   i think with the normal muxer, -initial_offset is the value but it does nothing for hls muxing.. for some reason it's 1.445400 in my output by default.. i want it to be 10 sec
[01:12:56 CET] <jarkko> what's up
[01:23:42 CET] <witchdoctor> hello
[01:24:13 CET] <witchdoctor> logout
[01:26:31 CET] <witChdoCtOr> anyone do development work?
[01:31:49 CET] <DHE> when I need it done
[01:32:11 CET] <DHE> looking to hire, or looking to get something done for beer?
[01:32:33 CET] <DHE> (i'm not available, just asking questions others may ask)
[01:32:40 CET] <shincodex> whos hiring what
[01:32:45 CET] <shincodex> im legendary
[01:32:47 CET] <llogan> DHE: He's gone, Jim.
[01:33:12 CET] <DHE> oh geez...
[01:33:14 CET] <shincodex> i compiled ffslopfest in visual studio 2015 hue hue hue
[01:33:27 CET] <shincodex> and attach its debugger to it when debug linux
[01:33:41 CET] <shincodex> with remote gdbs and vgdbs its amazing
[01:33:55 CET] <shincodex> anyone mess with a odroid before
[01:34:25 CET] <DHE> why do they make debuggers? my code always works just fine. seems like a lot of hassle
[01:34:51 CET] <shincodex> oh they said if i knew anyone worthy
[01:35:03 CET] <shincodex> coding test
[01:35:13 CET] <shincodex> screw with ffmpeg configure why my shizit not work? gl
[02:21:17 CET] <xtina> debianuser: hey, don't know if you are around. i'm trying to use that custom hook we built last night, but i forgot the command to load it
[02:23:15 CET] <xtina> my system crashed last night and lost my history :(
[02:24:07 CET] <xtina> (is there any way to look at yesterday's history in this IRC chat?)
[02:30:18 CET] <xtina> does this ffmpeg IRC channel have public logs anywhere?
[02:30:25 CET] <xtina> it says 'this channel is publicly logged'?
[02:31:15 CET] <xtina> oh i found it here: http://ffmpeg.gusari.org/irclogs/2017/02/17/ffmpeg.log.20170217
[02:41:03 CET] <xtina> I just wanted to post my question again. I have two seemingly identical audio commands in FFMPEG and Arecord. FFMPEG uses 95% of my CPU and Arecord uses 5%
[02:41:11 CET] <xtina> Command 1. arecord -Dmic_sv -c2 -r48000 -fS32_LE -twav temp.wav
[02:41:18 CET] <xtina> Command 2. ffmpeg -f alsa -acodec pcm_s32le -i mic_sv temp.wav
[02:41:45 CET] <xtina> I am desperately trying to understand why FFMPEG's CPU usage is vastly higher than arecord. This is blocking my entire project
[02:41:56 CET] <xtina> I am on a Pi Zero
[02:42:00 CET] <xtina> any ideas appreciated, thank you
[04:34:04 CET] <vans163> is there a good guide to all the possible options in the sps pps and i frame headers?
[04:35:25 CET] <vans163> im trying to find info on direct_8x8_inference_flag
[04:58:53 CET] <vans163> anyone know what video_format and chroma_loc_info_present_flag mean?
[04:59:22 CET] <vans163> im trying to understand difference between video_format 1 and 5
[05:29:12 CET] <snakeryslug> Is the "pad" filter the filter I should use if I want to move the output slightly to the right?
[05:48:08 CET] <xtina> hey guys. i have a FFMPEG alsa command and i'm looking at the debug level output
[05:48:25 CET] <xtina> 'Input #0, alsa, from 'michooks':   Duration: N/A, start: 1487382765.289814, bitrate: 3072 kb/s'
[05:49:03 CET] <xtina> '[alsa @ 0x31ea450] format: start_time: 1487382765.290 duration: -9223372036854.775 bitrate=3072 kb/s'
[05:49:12 CET] <xtina> 1. I have a negative ALSA duration. why?
[05:49:31 CET] <xtina> 2. My ALSA bitrate of 3Mbps seems really high. I don't want it that high (I only have a Pi Zero). Can I change this setting?
[05:52:09 CET] <xtina> debianuser: we were talking about strange sleep times on my system last night, i wonder if this negative duration is related and/or part of problem?
[05:54:54 CET] <snakeryslug> It looks like the "pad" filter only pushes to the left. any way to push to the right?
[06:20:00 CET] <xtina> any ideas?
[06:30:11 CET] <thebombzen> xtina: that duration is -2^63
[06:30:20 CET] <thebombzen> as in, the smallest value for a 64 bit signed integer
[06:30:56 CET] <thebombzen> it means that the duration there is garbage
[06:31:13 CET] <thebombzen> but you should expect the duration to be garbage, because you're grabbing from a live alsa device
[06:32:08 CET] <thebombzen> xtina: 3 Mbps is not high. that's the bitrate of uncompressed 32-bit samples at 48,000 samples per second
[06:32:43 CET] <xtina> thebombzen: OK, gotcha. just hunting for clues
[06:32:48 CET] <thebombzen> stereo audio that is. 1536 kbps per channel
[06:35:04 CET] <thebombzen> xtina: what if you use ffmpeg -f alsa -i <input> -c copy -f null -?
[06:35:09 CET] <thebombzen> the "null" muxer just discards data
[06:54:44 CET] <xtina> thebombzen: if I take out -acodec pcm_s32le i get this msg:
[06:54:48 CET] <xtina> [alsa @ 0x33aa430] cannot set sample format 0x10000 2 (Invalid argument) michooks: Input/output error
[06:55:09 CET] <thebombzen> that's because the default sample format is wrong
[06:55:24 CET] <xtina> oh hmm, can you explain? how do i change it?
[06:55:38 CET] <thebombzen> well if your alsa device is outputting signed 32-bit little endian samples
[06:55:46 CET] <thebombzen> then you need to tell ffmpeg that it's receiving tht
[06:55:59 CET] <thebombzen> so the way you fix that is by not taking out -acodec pcm_s32le
[06:56:08 CET] <thebombzen> provided that alsa is actually outputting that sample format
[06:56:27 CET] <xtina> OK, so I keep -acodec pcm_s32le
[06:57:24 CET] <xtina> so my cmd now is: ALSA_CONFIG_PATH=/usr/share/alsa/alsa.conf:./dumpasoundrc  /home/pi/special/ffmpeg/ffmpeg -v 9 -loglevel 99  -f alsa -acodec pcm_s32le -i michooks -c copy -f  null -
[06:57:27 CET] <xtina> this is still taking 95% CPU
[06:57:43 CET] <xtina> (the stuff in the beginning is a hook so I get the PCM settings dumped to stdout)
[06:58:37 CET] <xtina> full pastebin here: http://pastebin.com/8avfdD01
[06:59:45 CET] <xtina> logging looks OK, don't know why CPU usage is maxed out :/
[07:02:21 CET] <thebombzen> xtina: just a bit of a warning, if you just do ffmpeg <all that stuff> -i input output.wav, ffmpeg picks pcm_s16le as the default codec for the wav
[07:02:31 CET] <thebombzen> and it will convert it, unless you use -c copy
[07:02:52 CET] <thebombzen> that appears to not be the issue here, because by using -c copy -f null you rule that out, but keep that in mind
[07:03:35 CET] <xtina> thebombzen: yes, i know that. that's fine, my equivalent arecord command is also converting 32bit to 16bit, with no problems and <5% CPU
[07:04:00 CET] <xtina> this is my arecord cmd: arecord -Dmic_sv -c2 -r48000 -fS32_LE -twav temp.wav
[07:04:10 CET] <thebombzen> not sure why you're okay with that but sure
[07:04:24 CET] <thebombzen> if you're downsampling then it's already not lossless, so you might as well use flac or something rather than wav
[07:04:41 CET] <xtina> well, i'm trying to understand why the equivalent command in ffmpeg takes 95% CPU and in arecord takes 5%?
[07:04:48 CET] <xtina> as long as the two are doing the same thing, they should take similar CPU, right?
[07:04:58 CET] <xtina> both arecord and ffmpeg are converting to WAV. so this can't be the culprit..
[07:05:29 CET] <xtina> this is not my true command. this is me trying to debug why FFMPEG alsa uses insane amounts of CPU
[07:06:04 CET] <thebombzen> xtina: what happens for other alsa devices?
[07:07:52 CET] <xtina> thebombzen: sorry, other alsa devices?
[07:08:01 CET] <thebombzen> Yea, other alsa devices
[07:08:12 CET] <xtina> i tried with the default hw:1,0, or whaever
[07:08:13 CET] <xtina> my base mic device
[07:08:14 CET] <xtina> same behavior
[07:08:22 CET] <thebombzen> hm
[07:08:39 CET] <thebombzen> ... I got nothing, other than "wtf is dumpasoundrc"
[07:08:42 CET] <xtina> i'll show you my asoundrc: http://pastebin.com/gd2zyhLW
[07:09:02 CET] <xtina> please don't worry about it, it's a hook to print out the PCM settings
[07:09:15 CET] <xtina> my original command is: ffmpeg -f alsa -acodec pcm_s32le -i mic_sv temp.wav
[07:09:18 CET] <thebombzen> well I'm worrying about it
[07:09:19 CET] <xtina> this takes 95% CPU
[07:09:35 CET] <xtina> i spent dozen's of hours debugging without dumpasoundrc
[07:09:43 CET] <thebombzen> yea and that command has a different device than the previous one
[07:09:50 CET] <xtina> correct
[07:10:11 CET] <xtina> http://pastebin.com/SQzRNa91
[07:10:29 CET] <xtina> 'michooks' is the mic_sv device i normally use, but it also dumps the PCM info
[07:10:40 CET] <xtina> as you can see in dumpasoundrc
[07:11:02 CET] <xtina> anyway, this is the original command that takes 95% CPU: ffmpeg -f alsa -acodec pcm_s32le -i mic_sv temp.wav
[07:11:12 CET] <xtina> it has nothing to do with dumpasoundrc. it uses default .asoundrc
[07:11:22 CET] <xtina> https://trac.ffmpeg.org/ticket/6156?cnum_edit=3#comment:3
[07:11:28 CET] <xtina> i just tried to file a bug about this
[07:11:35 CET] <xtina> that has more detailed debug console output
[07:11:42 CET] <xtina> in case you can make anything of it?
[07:12:13 CET] <xtina> i'm really concerned that i'm at the end of the road here..
[07:12:36 CET] <thebombzen> well start by not transcoding
[07:12:50 CET] <thebombzen> nobody's going to trust you if you say "I'm certain that isn't the problem"
[07:13:01 CET] <thebombzen> you might be right, but controlling variables is a big deal
[07:13:06 CET] <xtina> i have also compared these two commands:
[07:13:13 CET] <xtina> ffmpeg -f alsa -acodec pcm_s32le -i mic_sv -f  null -
[07:13:26 CET] <xtina> ^^ this take 95% CPU
[07:14:46 CET] <xtina> sorry, wrong one
[07:14:48 CET] <xtina> ffmpeg -f alsa -acodec pcm_s32le -i mic_sv -c copy -f  null -
[07:14:50 CET] <xtina> this takes 95% CPU
[07:15:03 CET] <xtina> it says it's only copying:   Stream #0:0 -> #0:0 (copy)
[07:16:36 CET] <xtina> and here is the detailed output: http://vpaste.net/WLgrA
[07:18:27 CET] <xtina> and here it is with the dumpasoundrc hook so I can see PCM settings, but you can ignore that if you don't trust it. it's 95% CPU no matter what. http://vpaste.net/KMmOW
[07:19:16 CET] <thebombzen> hmmmm it appears your problem is reproducable without a mic and without an rpi
[07:19:56 CET] <xtina> thebombzen: it is?
[07:20:49 CET] <thebombzen> yea
[07:20:54 CET] <xtina> did you just repro it?
[07:21:15 CET] <xtina> I am on a Pi Zero with mic, i've never heard of anyone able to repro. last night someone in here tried on his Pi 2 but both arecord and ffmpeg took 0% CPU for him
[07:21:17 CET] <thebombzen> when I run "ffmpeg -f alsa -i default -c copy -f null -" it uses significantly more cpu than if I run "arecord -D default -c 2 -r 48000 -f cd /dev/null"
[07:21:34 CET] <xtina> oh wow, that's amazing. i'm so glad someone is able to repro
[07:22:05 CET] <xtina> that's a start
[07:22:06 CET] <thebombzen> well, for me, the difference is something like 3% vs 10%
[07:22:13 CET] <thebombzen> but also keep in mind that i"m not on an embedded system
[07:22:19 CET] <xtina> 5% vs 95% for me :(
[07:22:28 CET] <xtina> the real issue for me is that
[07:22:30 CET] <xtina> i'm trying to livestream
[07:22:41 CET] <xtina> and when I use FFMPEG alsa, the audio in the stream is 100% garbage
[07:22:52 CET] <xtina> i'm guessing it's because ffmpeg alsa hogs my system's whole CPU
[07:23:00 CET] <xtina> when I use arecord instead, the audio is perfect
[07:23:06 CET] <xtina> (but then I get buffer overflows after 3 min)
[07:23:16 CET] <xtina> so I know my system can handle it, I feel something is wrong with FFMPEG alsa...
[07:23:34 CET] <thebombzen> perhaps. if I run ffplay -f alsa -i default then I just play what's coming out of my mic
[07:23:44 CET] <xtina> i've whittled it down to that pair of ffmpeg/alsa commands, one taking my entire CPU and the other almost nothing. this can't be right..
[07:24:27 CET] <Diag> Jesus chris
[07:24:35 CET] <Diag> I just grabbed 110 lol
[07:25:35 CET] <xtina> thebombzen: does FFMPEG do steps that arecord doesn't?
[07:25:38 CET] <xtina> do you think it is a bug?
[07:25:46 CET] <xtina> i looked at the FFMPEG alsa source code last night
[07:25:53 CET] <xtina> it seems that FFMPEG and arecord wait for ALSA packets differently
[07:26:09 CET] <xtina> Arecord uses snd_pcm_wait(), FFMPEG doesn't
[07:28:48 CET] <thebombzen> if you're a programmer you could try locally patching that and seeing what happens
[07:31:08 CET] <xtina> thebombzen: i'd like to try. i'm not sure what the problem is though
[07:31:42 CET] <thebombzen> well I mean in your own local version, change FFmpeg's behavior so it works like arecord
[07:31:45 CET] <thebombzen> and see if that does anything
[07:32:23 CET] <xtina> yea...
[07:32:32 CET] <xtina> i'm really glad someone is able to repro, i'm not insane..
[07:32:41 CET] <xtina> i do not know if i'll be able to patch it, i could try...
[07:58:15 CET] <ShaneVideo> I am capturing 1080i video and my capture card is converting it to 1080 30p.  Its splitting the fields so all the even are on the top and the odd are on the bottom.  What is this technique called?  I can share a screenshot if that helps.   Thanks guys!
[09:13:59 CET] <thebombzen> ShaneVideo: I don't know what it's called, but you can fix it with avfilter
[09:15:55 CET] <ShaneVideo> screencap of the source video: http://www.echovolleyball.com.s3.amazonaws.com/source.png
[09:16:22 CET] <thebombzen> If you're having an issue where the top lines are above and the bottom lines are below
[09:16:28 CET] <thebombzen> you can fix it with -vf stereo3d=abl:irl
[09:16:46 CET] <ShaneVideo> thank you so much!
[09:17:11 CET] <thebombzen> it'll take the input video as "two frames" abl (abl = above/below, with left eye on top) because it's a stereo3d filter
[09:17:21 CET] <thebombzen> irl is "interleaved, left eye first right eye second"
[09:17:30 CET] <thebombzen> so it'll take the top half and the bottom half and do a row-interleave
[09:17:32 CET] <thebombzen> which is what you want
[09:19:24 CET] <ShaneVideo> wow!
[09:19:32 CET] <ShaneVideo> It worked, now I'm going to try yadif
[10:22:28 CET] <ShaneVideo> One more question.  I have a 60fps half height video I need to convert into a full height 30fps video
[10:22:44 CET] <ShaneVideo> The 60fps are each field from an original 1080i source
[10:23:46 CET] <ShaneVideo> I'm wanting to use yadif and frame interpolation to make my original 1080i run at 60fps progressive
[11:01:29 CET] <ShaneVideo> I got it, have to tinterlace and then yadif
[11:26:26 CET] <thebombzen> ShaneVideo: don't do that
[11:26:56 CET] <thebombzen> if it's 60 fps, and one frame is the "top field" and the next frame is the "bottom field"
[11:27:17 CET] <thebombzen> you can just use -vf stereo3d=al:irl
[11:27:37 CET] <thebombzen> which does the same thing as abl -> irl, but "abl" has the two fields as "above/below"
[11:27:44 CET] <thebombzen> and "al" is "alternating"
[11:27:58 CET] <thebombzen> so if you use -vf stereo3d=al:irl it'll do what you want
[11:28:12 CET] <thebombzen> tinterlace is desgined to interlace a video that isn't already interlaced
[11:28:19 CET] <thebombzen> you generally don't want to do that unless you're testing something
[11:28:41 CET] <ShaneVideo> Awesome! I'll give it a shot
[11:28:50 CET] <eau4x6> A single packet always contains only single audio/video frame? (I'm playing with ffprobe output)
[11:28:56 CET] <thebombzen> you still might want to feed it through yadif, depending on what you see
[11:29:07 CET] <ShaneVideo> thebombzen: you rock!
[11:29:14 CET] <eau4x6> (ffprobe -show_packets and -show_frames)
[11:29:48 CET] <furq> ShaneVideo: you might also want to try scale and minterpolate
[11:30:02 CET] <thebombzen> furq: minterpolate?
[11:30:09 CET] <furq> !filter minterpolate
[11:30:09 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#minterpolate
[11:30:11 CET] <thebombzen> minterpolate upscales the framemrate using motion prediction
[11:30:19 CET] <thebombzen> that doesn't sounds like what he wants
[11:31:25 CET] <furq> oh nvm he's going back to 60p
[11:35:47 CET] <eau4x6> basically my question is: what is the relation between stream packets and stream frames?
[11:36:18 CET] <thebombzen> I would think the packetization depends on the container
[11:36:36 CET] <thebombzen> some containers like WAV don't have audio frames at all
[11:36:43 CET] <thebombzen> and y4m for video
[11:36:54 CET] <thebombzen> y4m doesn't have packets
[11:38:46 CET] <eau4x6> how about mp4 or mkv
[11:42:29 CET] <eau4x6> from my observation there's 1:1 correspondence
[12:09:46 CET] <ShaneVideo> thebombzen: you were right about al:irl.  Thanks again! I'm heading to bed
[12:40:17 CET] <Threads> !filter concat
[12:40:17 CET] <nfobot> Threads: http://ffmpeg.org/ffmpeg-filters.html#concat
[14:10:34 CET] <eau4x6> I would like to encode a file with libx264 with exactly same settings as other libx264 encoded file (to make them -c copy concatable). I tried to use the same -profile and -level but it's not enough.
[14:11:14 CET] <eau4x6> the video becomes distorted after join point
[14:11:58 CET] <eau4x6> what can I do?
[14:34:01 CET] <kepstin> what exactly do you mean by "video becomes distorted"?
[14:37:07 CET] <eau4x6> kepstin: colors are distorted
[15:42:16 CET] <thebombzen> eau4x6: can you send a screenshot?
[15:49:50 CET] <vans163> Hello does anyone know difference between video_format 1 and 5? also what chroma_loc_info_present_flag means?
[15:50:13 CET] <vans163> Im trying to understand if this means the pixel color format meaning one can be rasterized faster then the other on draw
[15:50:36 CET] <vans163> this is for h264
[15:51:49 CET] <thebombzen> you need to provide more context
[15:54:14 CET] <jkqxz> I think video_format is meant to be used to guess the other values if they aren't present, but whether anything does I don't know.
[15:54:47 CET] <jkqxz> (lavc just discards it: <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/h264_ps.c;h=8218e3a010f420d5e9def232c593d406a100e7be;hb=HEAD#l163>.)
[16:17:05 CET] <vans163> thebombzen: im looking at a video stream encoded for low latency and I am wodnering what encoder params they passed to set the video_format to 5
[16:18:00 CET] <vans163> also the low latency stream has transfer_characteristcs 6 while my stream has 4
[16:18:27 CET] <vans163> low lat has chroma_loc_info_present_flag: 1, chroma_sample_loc_type_top|bottom_field: 1.  mine has 0 for all 3
[16:19:11 CET] <vans163> otherwise my stream and the low latency sample stream i got are identical in the SPS frame
[16:19:43 CET] <vans163> im trying to figure out why my client is having such a hard time painting decoded frames. if its maybe the pixel or color format after decode
[16:19:50 CET] <vans163> (its taking way too long in paint)
[16:20:20 CET] <JEEB> the only difference that anything could make out of those is the interlacism
[16:20:44 CET] <JEEB> but in theory progressive should be faster :p
[16:20:58 CET] <JEEB> since you don't need to deint
[16:21:41 CET] <JEEB> otherwise any of those don't change how the thing is rendered. all ycbcr colorimetrics go through the same rendering chain
[16:22:54 CET] <vans163> JEEB: hum.. so the decoder should not be affected then?  Do you think the PPS or I-Frame headers might have some things to make the decode->paint->displayed pipeline faster?
[16:23:09 CET] <JEEB> so most likely whatever is causing your difference is not in there. if the other stream is interlaced you should rather check if your hw device for some unfathomable reason prefers interlacism
[16:23:43 CET] <vans163> the encoder im using rihgt now is software, and using the low latency stream + the same decoder seems much smoother then my stream
[16:24:01 CET] <vans163> im thinking its either a network/packetsize issue (all local net) my stream is using websockets, the other stream uses RTP
[16:24:16 CET] <vans163> or something with the encoder params/headers
[16:24:28 CET] <JEEB> vans163: the only possibility of making your rendering chain skmpler is to transfer rgb, since that skips the ycbcr to rgb conversion. but nothing hw decoding supports that :p
[16:25:49 CET] <JEEB> other than the interlacism I noted, but progressive should be better for rendering so that's just your shitty device decoding rather than general advice :)
[16:26:02 CET] <JEEB> but first of all make the whole thing comparable
[16:26:18 CET] <vans163> JEEB: hum.. good to know then that the stream should be alright.  Il going to try then to not use WebSockets and instead RTP or just UDP to create a quick test case.  Iv been noticing using websockets sometimes results in a few frames clumping together (on the client side) and coming in within 0-1ms of eachother. This could be what is overloading the renderer and causing studder?
[16:26:25 CET] <JEEB> if you're using a whole different protocol that mught make a world of difference
[16:27:24 CET] <JEEB> vans163: I didn't say your stream is ok, I just said those things you noted have generslly no way of making a picture "simpler to render after decoding"
[16:27:57 CET] <vans163> JEEB: but if all the other params in the SPS are identical, and say the PPS and IFrame headers are identical except for that. That means the streams much be pretty much very similar?
[16:28:51 CET] <vans163> same SPS header params, same decoder, only difference left now is one is feeding cecoder of RTP and I am over websockets
[16:29:06 CET] <JEEB> yeah, might want to test apples to apples
[16:32:33 CET] <vans163> JEEB: ty, its time to do the apples to apples test. Btw is there common strategies for handling frameskip/framelose.  For example due to a network issue I receive a clump of 3 frames (60fps) within 1ms of eachother, all hit the decoder (which takes 0-1ms to decode) and produces 3 pictures.  Should I now sleep/wait 2-5ms (to queue up those 3 pictures from the decoder) then drop all except the most recent?
[16:33:22 CET] <vans163> so instead of having a pipeline like decode->picture->render   its.  decode->picture->sleep(5ms)->render
[16:34:14 CET] <vans163> if I start painting the first picture of the 3, il be 3-4 frame behind by the time its done paiting (paint takes forever compared to decode)
[16:45:38 CET] <thebombzen> vans163: if it was encoded with libx264 as you said it was, did you check -tune:v zerolatency?
[16:46:10 CET] <vans163> thebombzen: this example is encoded with nvenc using nvenc sdk
[16:46:21 CET] <thebombzen> oh
[16:46:42 CET] <vans163> i played around with libx264 but it uses too much CPU, im gonna try the Windows Desktop Dedup API next
[16:49:23 CET] <thebombzen> "it uses too much CPU, im gonna try the Windows"
[16:49:36 CET] <thebombzen> I'm fairly certain using Windows* won't help
[16:50:47 CET] <vans163> thebombzen: im not sure either but windows would solve 2 issues. #1 I can capture the mouse cursor seperate from the frame, #2 the screencapture part it not free either, the Dedupe API should make the screencap part close to free
[16:50:59 CET] <vans163> anyways its something I think worth a try
[16:51:41 CET] <vans163> the actual h264 encoding would probably cost the same, but il save the CPU on the frame capture
[18:03:44 CET] <c3-Win> Hello fellow FFMPEG users.
[18:05:02 CET] <c3-Win> I am currently working on adding the Audio filters that exist in FFMPEG as plug-ins for OBS ( https://obsproject.com/ ) for audio processing.
[18:06:28 CET] <c3-Win> When looking at the code examples that are around the internet (for example: https://www.ffmpeg.org/doxygen/3.2/filter_audio_8c-example.html ) I see basically real-time encoding of audio filters with no need for any type
[18:06:54 CET] <c3-Win> of buffering in case the audio doesn't process in real-time.
[18:07:51 CET] <c3-Win> My question is this: What happens if a real-time audio process (i.e. deadline) happens and FFMPEG isn't finished processing the audio? do I get some type of error code, or do I get static?
[18:08:30 CET] <c3-Win> am I at risk of crashing the encoding if I try to grab the audio before it's done processing?
[18:10:27 CET] <c3-Win> My Last question is in regards to changing settings dynamically (i.e. changing a setting for an audio filter and NOT rebuilding the entire filter/scene graph), and that is... Can I do that? OR should/do I need to rebuild it with every change to a parameter that a user makes?
[18:50:14 CET] <fyre> whats considered to be the best scaling algorithm for quality vs performance
[18:57:33 CET] <DHE> c3-Win: while audio filtering is usually pretty quick, if you're that worried about it I would do some multi-threaded processing.
[18:59:41 CET] <c3-Win> DHE: Thank you for the reply.
[19:00:07 CET] <c3-Win> DHE: It's more that a user's CPU might become overloaded, then anything about an audio filter taking a while.
[19:00:40 CET] <c3-Win> But that is a good point and I will inquire about the mulit-threadedness of the current audio engine.
[20:30:57 CET] <gargamel> hello! i'm trying to re-encode a video and only copy the audio, but there is some bad frames in the video. and when i mux them together again the audio drifts out of sync.. i've tried to correct it but no..
[20:31:38 CET] <gargamel> there is no problem if i also encode the audio, only when i copy
[20:31:41 CET] <gargamel> http://pastebin.com/SNUuCdDD
[22:15:24 CET] <vladfi1> hey, so I'm trying to fix Using AVStream.codec.time_base as a timebase hint to the muxer is deprecated. Set AVStream.time_base instead."
[22:15:54 CET] <vladfi1> the issue is if I do this my videos are sped up way too fast
[23:36:33 CET] <lockdown> Hi, can ffmpeg cut parts of a mp3?
[23:37:05 CET] <durandal_1707> without reencoding?
[23:37:30 CET] <lockdown> yes
[23:37:51 CET] <lockdown> its already an mp3, is that what you mean?
[23:38:34 CET] <durandal_1707> without transcoding its possible but not everyehere
[23:38:35 CET] <lockdown> like I only want 20 secs from a song
[23:39:03 CET] <lockdown> I don't mind transcoding
[23:39:41 CET] <durandal_1707> transcoding ki:ls quality
[23:41:12 CET] <lockdown> yeah, I don't mind losing some quality, its just a snippet I want to send through whatsapp
[23:41:48 CET] <lockdown> I guess there is already some transcoding going since I'm using youtube-dl for the song
[23:52:41 CET] <trfl> lockdown, ffmpeg -ss 1:48 -i some.mp3 -map 0:a -codec copy -t 20 cut.mp3
[23:57:04 CET] <lockdown> trfl: thanks, that's 20 secs after 1:48 right?
[23:57:18 CET] <trfl> yep!
[00:00:00 CET] --- Sun Feb 19 2017