[Ffmpeg-devel-irc] ffmpeg.log.20170227
burek
burek021 at gmail.com
Tue Feb 28 03:05:02 EET 2017
[00:15:15 CET] <Darby_> DHE
[00:15:25 CET] <Darby_> i have found the solution
[00:17:31 CET] <Darby_> ffmpeg don't compile with libssh using libssl-dev but if you run sed -i "/Libs:/ i\Requires.private: libssl" "~/ffmpeg_build/lib/pkgconfig/libssh.pc" ffmpeg compile in the right way
[00:20:13 CET] <Darby_> thanks DHE & BtbN ;)
[04:51:32 CET] <c3r1c3-Win> Trying to find what Error Code -22 is. Happens when I try to initialize an abuffer filter.
[07:28:08 CET] <Jonno_FTW> I'm trying to concatenate a bunch of mp4 files, but it's only putting the first file in
[07:49:26 CET] <llamapixel> Are you using the methods listed here Jonno_FTW with regards to a txt file and know they are all exactly the same codec? https://trac.ffmpeg.org/wiki/Concatenate
[08:26:58 CET] <satinder___> Hello everyone I have some serious problem
[08:27:44 CET] <satinder___> which processor is sufficient for play and encode 4 raw videos in h.264 at same time playing and recording
[08:27:54 CET] <satinder___> Is intel i3 good
[08:27:59 CET] <satinder___> ??
[08:29:01 CET] <tdr> thats a lot of work on an i3 ... 4 encoding + playing on whats usually a dual core?
[08:43:08 CET] <satinder___> yes
[08:43:14 CET] <satinder___> tdr
[08:44:09 CET] <tdr> sounds like your encoding could kill it depending on bitrate or whatever
[08:44:26 CET] <satinder___> ok
[08:45:01 CET] <satinder___> how many video we can play or encode on i3 if did any experiment
[08:45:03 CET] <satinder___> ?
[08:45:07 CET] <satinder___> tdr : ?
[08:45:19 CET] <satinder___> whith h.264
[08:45:27 CET] <satinder___> with*
[08:45:41 CET] <tdr> you'd have to test from yoru source
[08:46:07 CET] <tdr> it depends alot on the bitrate you're trying to push, memory, whether theres audio too etc
[08:46:14 CET] <llamapixel> There is a lot more to consider, eg drive speed, video size, memory etc
[08:46:49 CET] <satinder___> ok
[08:47:09 CET] <satinder___> Sir , have you used VPU with ffmpeg ?
[08:47:29 CET] <satinder___> can I compile ffmpeg libVA
[08:47:58 CET] <tdr> llamapixel, he said raw, figured he was getting raw streams live
[08:48:07 CET] <tdr> (assumed continous feeds)
[08:48:16 CET] <llamapixel> Ok
[08:48:20 CET] <llamapixel> https://app.zencoder.com/docs/guides/encoding-settings/h264-advanced
[08:48:41 CET] <satinder___> VPU ?
[08:48:43 CET] <llamapixel> content matters as well so you better ask
[08:49:04 CET] <llamapixel> anyway bbl
[08:49:36 CET] <satinder___> llamapixel : Have you used vpu with ffmpeg for video acceleration
[08:49:41 CET] <satinder___> ?
[08:49:54 CET] <llamapixel> no I havent mate
[08:50:00 CET] <satinder___> ok
[08:50:36 CET] <satinder___> there have option in ffmpeg how we can accelerate vpu
[08:50:50 CET] <satinder___> I am not able to findout
[09:32:23 CET] <forgon> Is this syntactically correct? `ffmpeg -i input.mkv -ss 01:05:00 -to 01:06:51 -vcodec libx264 -qp 0 -preset veryslow -acodec flac -compression_level 12 output.mkv`
[10:24:45 CET] <abdur91> hi my question is basically related to ffmpeg filter_complex.i am trying to create a logic in which any 2 sounds files can overlap on each other and these must also merge with a video file having a silent file.Now what i wanted to do is basically use both amerge and concat at a time with filter_complex.Any help in this regard is highly appreciated. thanks
[10:27:25 CET] <forgon> After compression, seeking is no longer possible, correct?
[10:35:22 CET] <abdur91> hi my question is basically related to ffmpeg filter_complex.i am trying to create a logic in which any 2 sounds files can overlap on each other and these must also merge with a video file having a silent file.Now what i wanted to do is basically use both amerge and concat at a time with filter_complex.Any help in this regard is highly appreciated. thanks
[10:38:10 CET] <Hennio> hi, i am building ffmpeg with nvenc support, but there is an error... "ERROR: nvenc requested but not found"
[10:39:13 CET] <Hennio> this is my configure:
[10:39:14 CET] <Hennio> ./configure \
[10:39:14 CET] <Hennio> --enable-shared \
[10:39:14 CET] <Hennio> --disable-yasm \
[10:39:14 CET] <Hennio> --disable-static \
[10:39:14 CET] <Hennio> --disable-programs \
[10:39:14 CET] <Hennio> --disable-swresample \
[10:39:15 CET] <Hennio> --disable-postproc \
[10:39:15 CET] <Hennio> --prefix=build \
[10:39:16 CET] <Hennio> --enable-nvenc \
[10:39:16 CET] <Hennio> --enable-cuda \
[10:39:17 CET] <Hennio> --enable-cuvid \
[10:39:17 CET] <Hennio> --toolchain=msvc \
[10:39:18 CET] <Hennio> --extra-cflags="-IC:\\cuda_8\\include -D_WIN32" \
[10:39:50 CET] <JEEB> don't post such long things on the channel itself in the future
[10:39:55 CET] <JEEB> and check your config.log
[10:40:02 CET] <Hennio> sorry!
[10:40:04 CET] <JEEB> that contains the results of the checks
[10:40:25 CET] <JEEB> basically anything more than 2 lines should go to a pastebin (or a similar service) instead
[10:40:29 CET] <Hennio> in the config.log there are a few errors
[10:40:33 CET] <Hennio> ok
[10:40:44 CET] <JEEB> and then linked on the channel, just fy
[10:40:46 CET] <JEEB> *fyi
[10:40:55 CET] <JEEB> <deity> damn it, Monday
[11:02:39 CET] <satinder___> Is there anyone who ever play more than 4 videos in single window using ffplay ?
[11:06:16 CET] <Hennio> @JEEB ok looking at the logs I found an issue with nvenc
[11:06:20 CET] <Hennio> error C2440: 'initializing' : cannot convert from 'const GUID' to 'unsigned long'
[11:06:33 CET] <Hennio> when compiling the check file
[11:07:49 CET] <satinder___> Hennio : ?
[11:08:01 CET] <satinder___> please see my question , help me
[11:08:17 CET] <Hennio> satinder___: no idea mate, im asking my own questions too
[11:08:36 CET] <satinder___> ok
[11:08:41 CET] <satinder___> thanks
[11:08:55 CET] <satinder___> JEEB : are you there ?
[11:11:06 CET] <abdur91> hi all
[11:11:34 CET] <abdur91> i have a question that i am trying to create a logic in which any 2 sounds files can overlap on each other and these must also merge with a video file having a silent file.Now what i wanted to do is basically use both amerge and concat at a time with filter_complex.Any help in this regard is highly appreciated.
[11:19:26 CET] <satinder___> ffmpeg -i video.mp4 -i video.mp4 -i video.mp4 -i video.mp4 -filter_complex "nullsrc=size=640x480 [base]; [0:v] setpts=PTS-STARTPTS, scale=320x240 [upperleft]; [1:v] setpts=PTS-STARTPTS, scale=320x240 [upperright]; [2:v] setpts=PTS-STARTPTS, scale=320x240 [lowerleft]; [3:v] setpts=PTS-STARTPTS, scale=320x240 [lowerright]; [base][upperleft] overlay=shortest=1 [tmp1]; [tmp1][upperright] overlay=shortest=1:x=320 [tmp2]; [tmp2][lowerleft] overlay=shortes
[11:19:27 CET] <satinder___> t=1:y=240 [tmp3]; [tmp3][lowerright] overlay=shortest=1:x=320:y=240" | ffplay -
[11:19:56 CET] <satinder___> what is wrong in above command please anyone help me
[11:24:46 CET] <abdur91> hi,any one here for help plz?
[11:39:27 CET] <forgon> What is a good value for analyzeduration if the default is not enough?
[14:32:03 CET] <xtina> hey folks. i have a question about bitrate.
[14:32:53 CET] <xtina> i have been using ffmpeg to stream 480p at 10fps video. sometimes the bitrate will be ~80kbps and ffmpeg speed is running at 1.0x. Other times bitrate is at ~160kbpsand speed is also running at 1.0x
[14:33:26 CET] <xtina> i thought that, given a particular resolution (480p) and FPS (10) and speed (realtime), bitrate should be a constant value
[14:33:40 CET] <xtina> how is it possible that 480p/10fps/1.0x speed can be both 80 and 160kbps bitrate?
[14:34:06 CET] <BtbN> If you are using a constant quality, it will use however much it needs to reach the requested quality.
[14:34:25 CET] <xtina> BtbN: what do you mean by 'quality'?
[14:34:28 CET] <xtina> resolution?
[14:34:47 CET] <BtbN> quite exactly that, the quality of the video
[14:35:05 CET] <xtina> so how come sometimes it requres 160kbps to reach 480p 10FPS and sometimes it only requires 80kbps?
[14:35:19 CET] <xtina> shouldn't it always require the same bitrate?
[14:35:21 CET] <BtbN> no
[14:35:38 CET] <BtbN> Unless you configure strict cbr, then it will adjust the quality to always reach the desired bitrate.
[14:35:48 CET] <xtina> i thought 480p/10fps specifies exactly how much data should be sent per second
[14:35:58 CET] <BtbN> if you send uncompressed video, maybe
[14:35:59 CET] <xtina> i did not specify a bitrate
[14:36:05 CET] <xtina> i'm sending h264 encoded video
[14:36:21 CET] <BtbN> So it's not uncompressed
[14:36:27 CET] <xtina> i specified the resolution in raspivid, from which i pipe h264 encoded video to ffmpeg
[14:37:09 CET] <xtina> hmm sorry, i still don't understand why the bitrate would fluctuate if i've specified resolution and FPS
[14:37:30 CET] <BtbN> Because it depends on the video and the requested quality.
[14:37:39 CET] <xtina> but i specified the quality, right? 480p?
[14:37:42 CET] <xtina> so that is constant?
[14:37:46 CET] <BtbN> no, that's the resolution-.
[14:37:57 CET] <BtbN> If you specified nothing, it will use whatever is the default
[14:38:14 CET] <xtina> i see, which parameter in ffmpeg specifies video 'quality'? i'm not sure what this term refers to technically, sorry
[14:38:28 CET] <BtbN> For libx264 it's -crf
[14:40:09 CET] <xtina> oh, very interesting, i didn't know. thanks.
[14:40:17 CET] <xtina> and if i pass a compressed h264 video to ffmpeg from raspivid
[14:40:24 CET] <xtina> is there a way to specify 'quality' in raspivid?
[14:40:31 CET] <BtbN> no idea
[14:40:32 CET] <xtina> ffmpeg does nothing but mux the video so i suppose i don't specify it in there
[14:41:05 CET] <BtbN> it might reencode if you specify nothing
[14:41:29 CET] <xtina> i don't think ffmpeg is reencoding anything
[14:41:30 CET] <xtina> Stream mapping: Stream #0:0 -> #0:0 (copy) Stream #1:0 -> #0:1 (copy)
[14:42:05 CET] <xtina> but i think i do see a quality param in raspivid, -qp
[14:42:06 CET] <xtina> "Varies from approximately 10 to 40, and will greatly affect the quality of the recording. Higher values reduce quality and decrease file size"
[14:50:21 CET] <BtbN> xtina, yeah, if you specify -c copy it will just remux
[14:50:35 CET] <BtbN> If you specify nothing at all it will re-encode though
[14:55:14 CET] <Steve__> Hi, is it possible to force ffmpeg to make the video and audio stream to have exactly the same length, down to the ms? -shortest does not work that exactly it seems
[14:55:41 CET] <BtbN> how should it do that? Even at 60 fps, a single frame covers more than one ms
[14:56:27 CET] <Steve__> I was hoping that it would be possible to adjust the audio. video should have the same number of frames
[14:56:51 CET] <BtbN> depending on the codec audio also has a frame size
[14:57:49 CET] <Steve__> I used this "-c:v libx265 -movflags +faststart -preset medium -crf 20 -s 1280x720 -aspect 16:9 -r 24 -af "volume=29.90dB" -c:a aac -b:a 128k -shortest", but audio is 25ms longer, what causes a noticeable lag when looping the mp4
[15:06:21 CET] <xtina> another question, sorry >.< earlier tonight i was streaming to youtube, no problem. now i am trying again and Youtube Live says there is no stream. ffmpeg tells me everything is going great
[15:06:32 CET] <xtina> if I try streaming to a flv file on disk, i can watch the video perfectly in VLC
[15:06:40 CET] <xtina> here's my full log if i try streaming to youtube:
[15:09:31 CET] <xtina> http://vpaste.net/a6QQq
[15:09:38 CET] <xtina> i can't spot anything wrong in the log...
[15:10:13 CET] <xtina> thanks in advance
[15:11:40 CET] <BtbN> Log is fine, whatever is happening is on youtubes end.
[15:11:53 CET] <BtbN> Also, if that rtmp url contains some private stream key, you should change it now.
[15:12:02 CET] <BtbN> rtmp://209.85.230.23/live2/xbjs-a3gp-0yvk-ftdg is in the log
[15:14:35 CET] <xtina> you're right, i will change it
[15:14:38 CET] <xtina> hmm, thanks btbn
[15:14:45 CET] <xtina> i will keep investigating. ffmpeg does look OK
[15:18:54 CET] <xtina> BtbN: you were right, stream's OK if i send it to Twitch instead. wish services would send a message if they were down @_@
[15:46:46 CET] <Steve__> for my understanding: I just tried opus using "-frame_duration 2.5 -shortest", but in the resulting mkv the audio is still 18ms longer. but shouldn't it be max 2.5ms longer than the video?
[16:02:22 CET] <DHE> what do I need to do to make a AVFrame I receive from avcodec_decode_video2() be reference counted? I'm getting a lot of time spent in memcpy while passing the AVFrame around. right now I just av_frame_alloc() and give that to the decoder immediately.
[16:04:48 CET] <JEEB> there was an option for that I think
[16:05:12 CET] <JEEB> ret = av_dict_set(&avdict, "refcounted_frames", "1", 0);
[16:05:17 CET] <JEEB> yea, that's what I'm doing
[16:07:28 CET] <DHE> oh wow that wording in the headers is concerning...
[16:08:55 CET] <DHE> JEEB: thanks, I'm on it
[16:12:45 CET] <JEEB> coal
[16:26:03 CET] <bencoh> .48
[17:36:28 CET] <Darby_> hi guys, now configure run without errors but make stop compilation on LD FFMPEG_G
[17:40:55 CET] <Darby_> https://clbin.com/0uaT6
[17:49:25 CET] <c_14> It looks like your linker can't find graphite/s-lang
[17:50:23 CET] <c_14> are libharfbuzz/libcaca linked statically against them?
[18:08:21 CET] <Phrk_> Hello, what is the easiest way to ffmpeg -c copy here.ts (and copy the same file at same time on a ssh server) ?
[18:08:24 CET] <Phrk_> like a mirror
[18:08:38 CET] <Phrk_> it's from a stream
[18:08:55 CET] <c_14> not entirely sure what you want
[18:09:00 CET] <c_14> 2 files from the stream, one local one remote?
[18:13:13 CET] <Phrk_> exactly c_14
[18:13:46 CET] <Phrk_> for now i just scp the file every 5min, but this is dirty, and when the file will make 20gb, it will be unsuable
[18:14:43 CET] <c_14> if ffmpeg is built with libssh then you can output directly via sftp
[18:14:50 CET] <Phrk_> wow
[18:15:03 CET] <Phrk_> but can i output 2 time ?
[18:15:09 CET] <Phrk_> one local and one sftp ?
[18:15:47 CET] <c_14> ffmpeg -i blah -c copy out.ts -c copy sftp://bar
[18:16:13 CET] <Phrk_> wow very simple
[18:16:28 CET] <Phrk_> thx ! ffmpeg is so powerfull
[18:19:00 CET] <DHE> I'm a big fan of sshfs as well. Even if you don't use it here, it's useful in general.
[18:21:59 CET] <c_14> if your ffmpeg isn't built against libssh it's probably easier to use sshfs than rebuild too
[18:58:21 CET] <xtina> hi guys, i have a kinda complicated q...
[18:58:37 CET] <xtina> i'm livestreaming using ffmpeg and my wifi signal varies during the stream
[18:58:52 CET] <xtina> i'm using raspivid to send h264 encoded video and i'd like the quantization to be variable
[18:59:21 CET] <xtina> effectively, i'd always like to have as high quality video as possible, but if the ffmpeg speed drops below 1.0x (realtime), then compression should increase a step until speed stabilizies at realtime
[18:59:28 CET] <forgon> 'Could not find codec parameters for stream 0 (Video: h264, none(progressive), 1280x800): unspecified pixel format Consider increasing the value for the 'analyzeduratino' and 'probesize' options
[18:59:39 CET] <forgon> What the hell is that, where does it come from and how do I fix it?
[18:59:42 CET] <xtina> i'm not setting the quantization parameter, so i can have a variable bitrate. however, it's not that intelligent
[19:00:06 CET] <xtina> sometimes my stream speed drops to 0.97x, but my bitrate isn't adjusting downwards to compensate, and as a result, my stream runs into problems
[19:00:46 CET] <xtina> because i'm not setting quantization it should be using the quantization logic from h264 codec, right? do you guys think it is possible for me to implement what i'm describing (periodically check ffmpeg speed and use it to adjust h264 quantization)?
[19:01:33 CET] <xtina> thanks in advance.
[19:30:12 CET] <xtina> how about a stupid basic question
[19:30:45 CET] <xtina> does anybody know - is the code for the h264 encoder the PI uses something I can modify?
[19:30:47 CET] <forgon> `Could not find codec parameters for stream 0 (Video: h264, none(progressive), 1280x800): unspecified pixel format Consider increasing the value for the 'analyzeduratino' and 'probesize' options`
[19:30:53 CET] <forgon> What the hell is that and how do I fix it?
[19:31:50 CET] <xtina> analyzeduratino is definitely spelled wrong, for one
[19:32:14 CET] <xtina> idk if you typoed that in here or misspelled it in ur cmd
[19:34:27 CET] <xtina> where is the code for variable quantization for omx_h264 in ffmpeg?
[19:37:51 CET] <furq> xtina: https://ffmpeg.org/doxygen/trunk/omx_8c_source.html
[19:38:08 CET] <furq> i don't know how much of it can be modified
[19:39:02 CET] <furq> if openmax exposes something which ffmpeg isn't using then i guess you could add it
[19:39:59 CET] <xtina> ooh
[19:40:30 CET] <xtina> er, is quantization in there? i searched 'quant', got nothing
[19:40:43 CET] <BtbN> ffmpeg does not support dynamic bitrate changes at runtime based on network performance
[19:40:52 CET] <xtina> oh dear
[19:40:55 CET] <BtbN> you'll have to implement your own application for that.
[19:41:00 CET] <xtina> does it support dynamic bitrate change based on ffmpeg's reported speed?
[19:41:15 CET] <xtina> my desired logic is: if ffmpeg speed goes below 1.0x, lower bitrate exponentially til itgoes back to 1.0x
[19:41:15 CET] <BtbN> Why would the speed have any relation to the bitrate?
[19:41:22 CET] <xtina> what's happening now is
[19:41:49 CET] <xtina> as i'm livestreaming, wifi signal sometimes drops, bitrate isn't dropping quickly enough, so i guess it has to wait more than 1s for 1s of video (?)
[19:42:02 CET] <xtina> hmmm
[19:42:10 CET] <xtina> BtbN: now i wonder if i'm misdiagnosing the problem
[19:42:11 CET] <BtbN> yes, I get that. No support from ffmpeg.c for that. You'll have to write your own
[19:42:26 CET] <xtina> do you think i'm on the completely wrong track?
[19:42:39 CET] <xtina> at some point in my streams, my speed starts dropping to like 0.97x or so
[19:42:45 CET] <xtina> and my bitrate drops a bit too
[19:42:59 CET] <xtina> but if my ffmpeg is at 0.97x for a few mins the stream will buffer
[19:43:18 CET] <xtina> and i want to avoid that, i thought i could avoid it by dropping bitrate b/c i don't know what else could cause it
[19:43:18 CET] <kepstin> if it is due to net bandwidth, then some adaptation might help - also using a udp protocol (e.g. rtp) rather than rtmp might help
[19:43:26 CET] <xtina> after like 30 min if successful streaming, 20% CPU, nothing looking wrong
[19:43:31 CET] <xtina> full battery
[19:43:36 CET] <xtina> all i can suspect is wifi variability
[19:43:39 CET] <kepstin> iirc, your main problems are likely due to connection setup + backpressure from the rtmp tcp stream
[19:44:02 CET] <kepstin> streaming udp (rtp) to a wired system which then pushes to rtmp might work better
[19:44:09 CET] <forgon> `Could not find codec parameters for stream 0 (Video: h264, none(progressive), 1280x800): unspecified pixel format Consider increasing the value for the 'analyzeduration' and 'probesize' options`
[19:44:18 CET] <forgon> Can someone explain that error to me?
[19:44:42 CET] <forgon> Are there downsides if I try 100M as value for both analyzeduration and probesize?
[19:44:45 CET] <DHE> forgon: information needed to process the video couldn't be inferred within the probe window. either something is wrong with the stream or you'll need to crank the parameters
[19:44:54 CET] <DHE> there will be a slow startup and possibly more memory required
[19:45:01 CET] <xtina> kepstin: if i want to add in some custom logic to adapt the bitrate downwards in response to occasional net bandwidth issues
[19:45:12 CET] <xtina> do you know what code i'm supposed to modify?
[19:45:20 CET] <kepstin> xtina: you'd be better off writing a custom app rather than starting with ffmpeg.c
[19:45:23 CET] <xtina> i'm currently using the pi h264 encoder in raspivid but also happy to use omx_h264 in ffmpeg
[19:45:49 CET] <kepstin> (in fact, starting with a custom app would solve most of the problems you've been having)
[19:45:51 CET] <mdavis> Hey, so I'm one of those Cygwin64 weirdos. I'm trying to use the h264_cuvid decoder, but every time it fails on ctx->cvdl->cuvidCreateDecoder(&cudec, &cuinfo) with CUDA_ERROR_INVALID_VALUE.
[19:45:53 CET] <mdavis> BUT!
[19:46:16 CET] <xtina> kepstin: i'm not expert enough for that at all ... sadly @_@
[19:46:24 CET] <mdavis> Running the same command, same video, same machine against a mingw64-compiled version works just fine
[19:46:40 CET] <xtina> there is some existing logic for varying quantization right?
[19:46:52 CET] <xtina> there must be, as it seems variable. i just want to find it...
[19:47:18 CET] <xtina> sorry if it sounds like i'm being stubborn, i understand your encouragement to build my own
[19:47:22 CET] <xtina> however i've actually been going great with ffmpeg
[19:47:24 CET] <forgon> DHE: What shall I do? '-probesize 100M -analyzeduration 100M -i inputfile -c copy outputfile'?
[19:47:37 CET] <xtina> i can stream like 30min of 720P 30FPS audio+video from my Zero to Youtube w/o any desyncs or buffers
[19:47:46 CET] <xtina> this current issue is the last one i face
[19:47:52 CET] <xtina> so i'd really prefer to work from this point :)
[19:48:21 CET] <mdavis> The call in question occurs at libavcodec/cuvid.c:670, in cuvid_test_dummy_decoder
[19:48:37 CET] <xtina> i'm just trying to track down the code that currently takes care of quantization in raspivid, it can't just happen magically
[19:49:02 CET] <xtina> or alternatively, the code for it in ffmpeg
[19:49:08 CET] <xtina> since i can use either command to encode
[19:49:41 CET] <kepstin> with hardware encoders, you usually either give them a static quantizer or a desired bitrate, and the rest happens magically in the black box
[19:49:51 CET] <kepstin> not really much you can do
[19:50:46 CET] <mdavis> So, anyone have any ideas why cuvid would work under mingw, but fail under cygwin?
[19:51:04 CET] <BtbN> define fails
[19:51:13 CET] <xtina> kepstin: hmm, so there's a bunch of quantizers out there.. and i could find one that works for me?
[19:51:21 CET] <mdavis> [h264_cuvid @ 0x60024ec40] ctx->cvdl->cuvidCreateDecoder(&cudec, &cuinfo) failed -> CUDA_ERROR_INVALID_VALUE: invalid argument
[19:51:27 CET] <xtina> oh
[19:51:39 CET] <xtina> static quantizer = static compression rate..?
[19:51:42 CET] <forgon> `Could not find codec parameters for stream 0 (Video: h264, none(progressive), 1280x800): unspecified pixel format Consider increasing the value for the 'analyzeduration' and 'probesize' options`
[19:51:58 CET] <kepstin> xtina: bitrate of a given frame is a function of quantizer and frame complexity more or less
[19:52:26 CET] <BtbN> mdavis, I'd guess it thinks it's on Linux which messed the library loading up.
[19:52:29 CET] <kepstin> (if you encode in bitrate mode, the encoder picks quantizer to use on the frame based on the complexity to get the desired rate)
[19:53:07 CET] <xtina> kepsin: so bitrate mode = i want this target bitrate, quantize appropriately. quantizer mode = use this much compression, and accept whatever bitrate comes out
[19:53:16 CET] <xtina> and i can't feed a param into the quantizer based on how ffmpeg is performing
[19:53:34 CET] <kepstin> xtina: not without substantial modifications to the ffmpeg command line tool, no
[19:53:36 CET] <BtbN> you can, just have to implement it yourself. ffmpeg.c does not do that.
[19:53:37 CET] <mdavis> BtbN: I'm trying to replace the current dynlink_loader.h setup and instead use CUDA implibs that I've generated, but I'm a bit out of my depth...
[19:53:44 CET] <xtina> so how do people stream from their phones? anyone who is using data is never gonna have the same upload speed
[19:53:54 CET] <xtina> i see
[19:53:59 CET] <xtina> oh dear
[19:54:00 CET] <kepstin> xtina: they don't use the ffmpeg command line tool :)
[19:54:02 CET] <BtbN> mdavis, why? The entire dynloading thing is put in place to make things easier.
[19:54:38 CET] <xtina> do you think it requires a ton of work on top of ffmpeg.c?
[19:54:50 CET] <mdavis> BtbN: So far that's the only place that things start to differ between cygwin and mingw
[19:55:05 CET] <BtbN> cygwin pretends to be linux
[19:55:07 CET] <BtbN> mingw doesn't
[19:55:12 CET] <BtbN> there are a lot of things that differ
[19:55:20 CET] <mdavis> BtbN: I've gone into GDB and verified that both versions are passing identical info in the cuinfo param
[19:55:36 CET] <kepstin> xtina: ffmpeg.c doesn't have any realtime handling code atm right now. you might be able to hack it into the main encoder loop, but ... well - i wouldn't know where to start :)
[19:55:42 CET] <BtbN> could just be the wrong calling convention
[19:56:12 CET] <BtbN> or different struct packing
[19:56:40 CET] <mdavis> BtbN: Yeah, could be. I know I'm going outside the realm of reasonable usecases, but I figured it couldn't hurt to ask :)
[19:57:06 CET] <xtina> so to make sure i understand. in bitrate mode ffmpeg picks a quantizer to achieve a bitrate. or is it the codec that picks the quantizer..?
[19:57:10 CET] <xtina> i'm still curious where this actually occurs
[19:57:14 CET] <BtbN> So you mean your modification does not work, but vanilla ffmpeg does just fine?
[19:57:32 CET] <mdavis> Nah, vanilla ffmpeg doesn't work (in cygwin).
[19:57:45 CET] <BtbN> xtina, ffmpeg just tells the encoder to deliver that bitrate.
[19:57:54 CET] <BtbN> It will do whatever it wants to achive it
[19:57:57 CET] <xtina> so it's the encoder's job
[19:58:04 CET] <xtina> gotcha
[19:59:11 CET] <xtina> OK. i guess i'm gonna have to make some compromises, i will use bitrate mode and use a low bitrate that i can hit 99% of the time and just end the stream if it starts buffering,i guess
[19:59:14 CET] <mdavis> Although, speaking of silly usecases, I compiled a static SDL2 from cygwin, but it uses the Win32 display backends. I found out I then had to #define SDL_MAIN_HANDLED in ffplay.c
[20:10:39 CET] <xtina> to further explain my troubles
[20:10:46 CET] <xtina> i dont care at all if my stream buffers ever 20 min or whatever
[20:11:00 CET] <xtina> the problem is that while the video is buffering the audio is overflowing the audio pipe and audio packets are dropping
[20:11:09 CET] <xtina> so whenever my stream buffers, the audio and video become permanently desynced and the stream is ruined
[20:11:25 CET] <xtina> so while it's pretty normal for streams to buffer.. for me it's fatal...
[20:11:28 CET] <xtina> :(
[20:11:57 CET] <alex1912> "ffmpeg --list-bsfs" gives "Unrecognized option '-list-bsfs'.Error splitting the argument list: Option not found" whats wrong?
[20:12:28 CET] <forgon> alex1912: The argument is probably in the wrong place
[20:12:45 CET] <kepstin> alex1912: that's not the right argument name. You probably mean "-bsfs"
[20:12:59 CET] <kepstin> alex1912: note that no ffmpeg arguments start with -- at all, where did you see that?
[20:13:24 CET] <alex1912> https://ffmpeg.org/ffmpeg-bitstream-filters.html#dca_005fcore
[20:13:30 CET] <alex1912> section 2
[20:13:56 CET] <forgon> `Could not find codec parameters for stream 0 (Video: h264, none(progressive), 1280x800): unspecified pixel format Consider increasing the value for the 'analyzeduration' and 'probesize' options`
[20:14:16 CET] <kepstin> alex1912: that's an option to ffmpeg's "configure" script when building, not to the command line tool
[20:14:27 CET] <alex1912> ah ok
[20:15:00 CET] <alex1912> so i need dca_core filter, have i realy to build my own ffmpeg?
[20:15:09 CET] <llogan> forgon: Consider increasing the value for the 'analyzeduration' and 'probesize' options
[20:15:21 CET] <kepstin> alex1912: maybe not, run "ffmpeg -bsfs" to see if it's included in your current build
[20:15:28 CET] <forgon> llogan: Be specific.
[20:15:44 CET] <forgon> I have obviously tried this already, with 100M as value for both.
[20:15:56 CET] <llogan> ffmpeg -analyzeduration <value> -probesize <value> -i input
[20:16:12 CET] <llogan> perhaps your input is garbage
[20:16:44 CET] <forgon> llogan: Everyone gets to that part. What about the output?
[20:17:13 CET] <forgon> What you gave is no valid command.
[20:17:14 CET] <alex1912> no its not
[20:17:22 CET] <alex1912> already did the otion
[20:17:29 CET] <llogan> forgon: ffmpeg -analyzeduration <value> -probesize <value> -i input output
[20:17:58 CET] <durandal_1707> alex1912: from where you get your ffmpeg?
[20:18:12 CET] <forgon> forgon: What will happen to the codec?
[20:18:28 CET] <alex1912> pfff, dunno, i guest it came on windows 8.1 with megui, #
[20:18:40 CET] <alex1912> and on ubuntu 16.04 with the system
[20:18:51 CET] <alex1912> same reaction thou
[20:19:20 CET] <durandal_1707> too old to be useful
[20:19:37 CET] <llogan> or just download a recent build and try again
[20:19:53 CET] <alex1912> will try
[20:19:55 CET] <llogan> https://ffmpeg.zeranoe.com/builds/ or https://johnvansickle.com/ffmpeg/
[20:20:58 CET] <forgon> llogan: Zero change of the problem.
[20:21:22 CET] <forgon> I already spammed the message here 10 times or so
[20:22:00 CET] <llogan> i see no link provided by you that shows your actual, full, unscripted ffmpeg command and the resulting complete, uncut console output
[20:25:33 CET] <forgon> http://sprunge.us/fMJH
[20:28:03 CET] <llogan> this whole time i assumed you were using ffmpeg
[20:30:10 CET] <forgon> It doesn't matter, you don't know the answer :p
[20:31:11 CET] <kepstin> forgon: so you tried adding the '-analyzeduration' and '-probesize' options to the ffprobe command with big values, and it didn't help?
[20:31:20 CET] <llogan> well, if that's the case then I don't have to do anything else
[20:31:21 CET] <kepstin> if so, your mkv file is probably corrupt, I guess...
[20:31:38 CET] <durandal_1707> how file was created?
[20:31:57 CET] <kepstin> (that info should be stored in a global header in mkv, I thought)
[20:33:20 CET] <forgon> kepstin: I tried that too.
[20:33:37 CET] <forgon> The thing I notice is that 'ENCODER' is missing for the corrupt file.
[20:33:42 CET] <alex1912> OH IT WORKED
[20:34:00 CET] <alex1912> THANKX ALOT kepstin & llogan
[20:34:06 CET] <alex1912> and all
[20:34:24 CET] <forgon> Metadata are different: http://sprunge.us/fEEN
[20:35:41 CET] <alex1912> well, with this thanks @all and bb
[20:52:06 CET] <DHE> are there current instructions on how to deal with telecine content somewhere? preferably handling mixed content but if not I can deal with it the harder way
[21:01:09 CET] <kepstin> DHE: fieldmatch works fairly well, but needs something to delete dup frames after which is harder with mixed content. iirc 'pullup' works reasonably well with mixed content and is more hands-off, you can throw a condititional deinterlacing filter and a dejudder after it to fix the remaining frames and smooth out the result.
[21:01:46 CET] <DHE> oh dear...
[21:01:53 CET] <kepstin> DHE: if you have really nasty content, like say the s.e.lain ntsc r1 dvds, well, ...
[21:02:04 CET] <kepstin> buy the blu rays instead in that case ;)
[21:02:26 CET] <DHE> it's a live MPEG-TS feed
[21:03:45 CET] <JEEB> mixed content properly is hard
[21:03:51 CET] <JEEB> as it's pretty much manual
[21:03:58 CET] <DHE> well @#%!
[21:04:04 CET] <kepstin> DHE: it really depends what you want to do with that. Really, bobbing it to 60/50fps is one of the easiest and least bad options to get everything to look okish
[21:04:52 CET] <DHE> input is officially 1080i, but it seems to be jumping between telecine and traditional 1080i. commercials seems to be 1080i, some shows are telecine...
[21:05:11 CET] <JEEB> yes
[21:05:31 CET] <JEEB> in theory you can match up fieldmatch and friends and yadif
[21:05:35 CET] <JEEB> but that's just in theory
[21:06:39 CET] <JEEB> so unless you get metadata on where to handle crap properly
[21:06:52 CET] <JEEB> you might as well be throwing a coin if you're getting it right
[21:07:14 CET] <JEEB> and to be honest I've never seen that kind of metadata in broadcast sources :P
[21:07:41 CET] <kepstin> I *think* pullup leaves the interlaced flag set correctly on frames that it doesn't match, so something like pullup,yadif=deint=interlaced,dejudder *might* work most of the time
[21:07:55 CET] <JEEB> yes, but it really depends on things
[21:08:10 CET] <kepstin> some stuff will sneak through because pullup's matching isn't that great
[21:08:24 CET] <JEEB> fieldmatch and the rest also should in theory leave the interlacism flag on not so great matching
[21:08:51 CET] <kepstin> but with fieldmatch you have to deal with removing the extra frames on telecined stuff, while not removing anything on interlaced stuff
[21:09:10 CET] <DHE> the only thing that strikes me is that the AVFrame->interlaced_frame field cycles in a pattern that should be measurable with a bit of buffering.
[21:09:55 CET] <kepstin> DHE: that's really weird, it should have all frames marked as interlaced in a stream such as you've described
[21:10:44 CET] <kepstin> unless maybe the encoder is being too clever and i dunno checking for combing to set the flag adaptively? :/
[21:12:16 CET] <forgon> `Could not find codec parameters for stream 0 (Video: h264, none(progressive), 1280x800): unspecified pixel format`
[21:12:21 CET] <forgon> What does this mean?
[21:12:26 CET] <kepstin> the other thing you have to worry about is (particularly if it's mpeg2, dunno if h264 does this?) whether the content is soft-telecined, which is done with repeat-field flags, because then you can have a mix of 24p, 60i telecine, 60i interlaced
[21:12:45 CET] <DHE> it is mpeg2... but I don't know about the details beyond that.
[21:13:03 CET] <JEEB> kepstin: soft-telecine is possible with AVC just fine
[21:13:15 CET] <JEEB> forgon: you're hosed
[21:13:51 CET] <kepstin> at least current ffmpeg has a port of mplayer's softpulldown now - "repeatfields" - so you can treat the 24p stuff as 60i telecined to make it a little less complex to handle
[21:14:25 CET] <forgon> The files are playable, they just are wrong in other ways.
[21:15:00 CET] <kepstin> forgon: what are you trying to do with this file? why is this error a problem for you?
[21:15:46 CET] <forgon> kepstin: Originally I tried to upload it to YouTube. Then I noticed that the thumbnail suggestion were in a horrible grayish mixture looking like an ant-war is going on.
[21:16:05 CET] <forgon> This did never happen with other files which I made on the same day using the same method.
[21:16:16 CET] <forgon> The difference is the error.
[21:16:26 CET] <kepstin> forgon: ok, that's a start. how did you make the files?
[21:16:44 CET] <kepstin> (because the issue is that this file is corrupt or incorrectly muxed)
[21:17:40 CET] <forgon> First I maximally compressed file a, which constisted of flac and libx264:
[21:18:07 CET] <forgon> 0) ffmpeg -i recording.mkv -vcodec libx264 -qp 0 -preset veryslow -acodec flac -compression_level 12 output.mkv
[21:18:22 CET] <forgon> Then I split it into parts via seeking:
[21:19:56 CET] <forgon> 1) ffmpeg -ss 05:14 -to 14:23 -i output.mkv -c copy final.mkv
[21:20:28 CET] <forgon> The first file I got in such a way has no apparent flaws, all the others do.
[21:21:06 CET] <kepstin> alright, can you give us the complete ffmpeg output from encoding one of those files that has flaws?
[21:21:50 CET] <forgon> I don't have the logs left, I'm afraid.
[21:22:27 CET] <kepstin> you could just re-run it, assuming you had the original file left.
[21:22:58 CET] <forgon> Let me see first whether i can reproduce.
[21:23:30 CET] <kepstin> keep in mind that even if it does work, you're not going to get accurate seek times, because in copy mode it can only seek to keyframes
[21:24:04 CET] <forgon> I heard ffmpeg does some magic to get the least worst solution, which I assume is far better than what I would get.
[21:24:07 CET] <kepstin> you might get better results re-encoding rather than copying, if you want accurate times (you're using lossless, so re-eocnding obviously doesn't lose you quality)
[21:24:38 CET] Action: DHE is off to the drawing board
[21:29:53 CET] <forgon> I got closer.
[21:30:08 CET] <forgon> Apparently -c copy is to blame.
[21:30:26 CET] <forgon> But now I am confused.
[21:31:30 CET] <llogan> why did you do step "0" in the first place? reencoding (from lossy?) to lossless and making a huge, gigantic file.
[21:31:42 CET] <kepstin> codec copy in combination with seeking is always going to be weird, at best. it's sometimes useful to break up lossy-encoded files where you want to avoid a transcode - but if you're working in lossless anyways, just transcode and be happy
[21:32:35 CET] <forgon> kepstin: Compression won't suffer this way, correct?
[21:34:14 CET] <kepstin> you're using lossless, compression suffering is the difference between an extremely large file and an extremely large file
[21:47:43 CET] <mdavis> After quite a bit of effort spent on removing the CUDA dynload system, my problem persists. :/
[21:50:12 CET] <kepstin> attempting to load native windows stuff from cygwin sounds like worlds of pain that I don't want to get into :)
[21:50:33 CET] <mdavis> That's what I'm quickly starting to see
[21:52:01 CET] <mdavis> Maybe I should shoot nvidia an email, "Hey, can I have your CUDA, CUVID, and NVENC source code? Kthx"
[21:56:29 CET] <BtbN> I did put some effort into making it work on cygwin, but for cuvid I never had much luck.
[21:56:32 CET] <BtbN> nvenc works though iirc
[21:56:44 CET] <BtbN> haven't tried it in a long while. Just build it natively.
[21:56:49 CET] <mdavis> Yeah it does, which I appreciate <3
[21:57:11 CET] <BtbN> And I still don't see the point of directly linking.
[21:57:16 CET] <BtbN> no benefit in that
[21:57:16 CET] <mdavis> And at any rate, cuvid isn't even faster than CPU-based decoding...
[21:57:30 CET] <BtbN> For HEVC and VP9 it most likely is
[21:57:36 CET] <mdavis> BtbN: I thought it had something to do with it, but it didn't
[21:58:04 CET] <BtbN> no, I suspect it's something about calling conventions(Linux uses cdecl, Windows stdcall), or cygwin-gcc packs some structs diffrently.
[21:59:06 CET] <mdavis> If it's struct packing, I should be able to see that in GDB. I'll take a look.
[21:59:36 CET] <xtina> hey guys. i hope i'm not asking the impossible. in my stream i'm targeting 800kbps
[21:59:44 CET] <xtina> however in the first 30s the stream needs to speed up to "catch up"
[21:59:56 CET] <xtina> so ideally it surges to like 1.5Mb before settling back down to 800kbps
[22:00:17 CET] <xtina> in raspivid if i specify -b 800K, then in the beginning it never goes above 800K, so it can't "catch up"
[22:00:36 CET] <xtina> but if i set -b 1.5M, then it always stays at 1.5M, which is too high
[22:00:57 CET] <xtina> if i don't specify any bitrate at all then it naturally goes to 1.5M before settling back down around 800, but sometimes it wanders back up, which i don't want
[22:01:33 CET] <xtina> essentially i want ffmpeg to be willing to stream up to 1.5M
[22:01:36 CET] <xtina> so that it can catch up initially
[22:01:41 CET] <mdavis> Is there a reason you want it to surge in the first 30 seconds? Do you want it to catch up time-wise, or bitrate-wise?
[22:01:43 CET] <xtina> but raspivid should only be willing to stream up to 800k
[22:01:56 CET] <xtina> so after everything is caught up, ffmpeg has no reason to go above 800, since raspivid is sending it 800
[22:02:06 CET] <xtina> mdavis: it needs to catch up time-wise
[22:02:26 CET] <xtina> a period of time passes between when the video pipe starts recording and when that starts getting sent over RTMP
[22:02:30 CET] <xtina> that video buffer needs to empty
[22:02:53 CET] <xtina> my ffmpeg isn't encoding, just copying (c:v copy)
[22:03:07 CET] <xtina> is it possible for me to tell fmpeg to stream up to 1.5M, even tho it's just copying and muxing?
[22:03:13 CET] <xtina> -maxrate has no effect
[22:04:19 CET] <xtina> b:v also seems to have no effect
[22:04:29 CET] <mdavis> The bitrate you give ffmpeg only directs the encoder, so with c:v copy it won't do anything. To achieve what you're looking for, you might have to mess around with timecodes
[22:05:13 CET] <xtina> (using a pi zero)
[22:05:13 CET] <xtina> i don't have any timecode stuff, as i need as little processing as possible
[22:05:27 CET] <xtina> the reason i'm using raspivid to write and then ffmpeg to read the video stream is so
[22:05:30 CET] <xtina> i can decouple the two processes
[22:05:37 CET] <xtina> and have the video pipe as a buffer
[22:06:14 CET] <xtina> so i thought i should be able to set the write speed (-b in raspivid) as well as some kind of bitrate in ffmpeg
[22:07:01 CET] <mdavis> Again, that doesn't actually tell the programs to write data faster, it tells them the encoder can use a higher bitrate -> better quality
[22:07:35 CET] <xtina> so the only way i can do this "catch up" thing is by avoiding setting any bitrates? :(
[22:07:39 CET] <mdavis> If you want to reduce latency, you should look into whether raspivid's encoder's buffer can be reduced
[22:08:28 CET] <xtina> hmm, how do you mean? if i reduce raspivid's buffer
[22:08:32 CET] <xtina> wouldn't that just cause frames to be dropped?
[22:08:36 CET] <xtina> at the start of the stream
[22:08:53 CET] <xtina> i was trying to get raspivid's buffer as large as possible to ensure no frames are dropped..
[22:09:23 CET] <kepstin> yes, but bigger buffer means more latency
[22:09:26 CET] <kepstin> it's a trade-off
[22:09:28 CET] <mdavis> Almost all encoders that target an average bitrate use a lookahead buffer, so they can preemptively drop quality if a complex scene is coming up/
[22:10:17 CET] <xtina> if a single packet is dropped from either my audio or video, my entire stream is doomed
[22:10:22 CET] <xtina> as the audio and video would never get back in sync
[22:10:34 CET] <xtina> from the moment the stream begins i need every recorded A/V packet to make it into the stream...
[22:11:14 CET] <xtina> i mean, this is such trouble that i wonder if i can timestamp them?
[22:11:28 CET] <mdavis> Maybe you should look into a streaming protocol? If you're doing raw A/V transport, then you will have problems with sync
[22:11:45 CET] <xtina> the audio and video files? currently raspivid is writing h264 encoded video and sox is recording mp3
[22:12:04 CET] <kepstin> xtina: remember that this is all workarounds for the fact that ffmpeg isn't really a realtime streaming app - if you had a custom app handling the capturing and encoding and streaming, then you could start stuff up in the right order so you wouldn't need massive buffers
[22:12:05 CET] <xtina> mdavis: as far as i can tell ffmpeg is the commonly used library for streaming from the raspberry pi
[22:12:28 CET] <kepstin> the ffmpeg libraries are great, ffmpeg tool isn't really meant for realtime stuff
[22:13:09 CET] <mdavis> xtina: In that case, you would probably be better off ditching raspivid and sox, and recording both audio and video with one ffmpeg instance.
[22:13:38 CET] <xtina> mdavis: sadly there's some bug in ffmpeg that means audio encoding requires almost 100% of my CPU
[22:13:46 CET] <kepstin> mdavis: xtina was trying that earlier, running into issues due to ffmpeg's poor multiple input handling not working well for realtime stuff on resource constrained systems
[22:13:58 CET] <xtina> kepstin: that isn't the problem
[22:14:11 CET] <xtina> the problem is that recording alsa audio in ffmpeg requires all o fmy CPU
[22:14:38 CET] <xtina> i doubt anyone will ever get to this, but https://trac.ffmpeg.org/ticket/6156
[22:14:52 CET] <xtina> i just decided to use Sox instead, it takes like 15% of my CPU to record AND encode to mp3
[22:15:38 CET] <xtina> my livestreaming A/V with a combo of ffmpeg, raspivid, and Sox requres <25% of my CPU
[22:15:42 CET] <kepstin> xtina: it looks like ffmpeg's doing a s32’s16 conversion there, does it work better if you just capture s16 directly?
[22:15:52 CET] <xtina> kepstin: s32 -> s32 same problem
[22:15:58 CET] <mdavis> OK, can you get SOX to output raw or minimally encoded audio, and pipe that into ffmpeg?
[22:16:02 CET] <kepstin> xtina: and s16’s16?
[22:16:23 CET] <xtina> mdavis: why would that help?
[22:16:45 CET] <kepstin> xtina: there's really no reason to use higher bit depths than 16 except maybe as intermediates in music production
[22:16:47 CET] <xtina> kepstin: dont think my mems mic does s16 natively
[22:16:51 CET] <kepstin> xtina: just wastes bw/cpu
[22:17:27 CET] <xtina> i mean, whatever it is, there's a bug in ffmpeg if 32->32 uses 95% of my CPU, right?
[22:18:15 CET] <mdavis> Maybe it's not 32->32? It could be that it's getting scaled up to 32 somewhere.
[22:18:26 CET] <xtina> ffmpeg tells me it is
[22:18:30 CET] <xtina> maybe not
[22:18:48 CET] <kepstin> hmm, if this issue is related to ffmpeg not doing a wait on the alsa device, I'm not sure that's fixable - since ffmpeg's single threaded, wouldn't a wait there cause the rest of the process to hang?
[22:19:00 CET] <kepstin> you'd really need to use a separate input thread to handle that right
[22:19:14 CET] <xtina> i don't really understand the issue, but if that's the case, that's the reason to use a separate process i suppose/
[22:19:16 CET] <xtina> ?
[22:19:37 CET] <kepstin> well, with separate process you run into the issue of needing a big buffer to workaround ffmpeg's slow startup
[22:19:39 CET] <xtina> though i'm not sure why there'd be an issue on ffmpeg not waiting for alsa.. doesn't ffmpeg have to wait for the h264 encoder
[22:19:44 CET] <kepstin> which means high latency
[22:19:50 CET] <xtina> @___@
[22:20:02 CET] <xtina> sorry.. running on low sleep.. this project has been giving me a headache
[22:20:09 CET] <kepstin> xtina: ffmpeg has to wait for lots of things - but it can't wait for one thing while also waiting for something else
[22:20:30 CET] <kepstin> it has to wait for alsa samples and wait for the h264 encoder and wait for the network data to send and...
[22:20:39 CET] <xtina> i'm not looking for perfection and i know it's near impossible with this setup
[22:20:50 CET] <xtina> my streams have been performing well for about 30mins which is already great
[22:20:55 CET] <xtina> i just want them to stabilize at a certain bitrate
[22:20:59 CET] <kepstin> since it's all single-threaded, it can't wait for one thing at the same time as something else, so stuff gets bogged down.
[22:21:03 CET] <xtina> instead of wandering wherever they want
[22:21:27 CET] <xtina> yea, makes sense
[22:21:39 CET] <xtina> that's unavoidable yes?
[22:22:07 CET] <xtina> with my current setup i need a bitrate surge at the start to catch up, which means i can't set a target bitrate
[22:22:11 CET] <xtina> if i changed setups
[22:22:23 CET] <kepstin> you don't need a "bitrate surge", that doesn't make sense
[22:22:25 CET] <xtina> i'm not sure i understand an alternative plan
[22:22:45 CET] <xtina> i mean, the only way i've gotten successful 30min streams so far is that the bitrate spikes to 2x for 5s and then lowers to 1x around 15
[22:22:46 CET] <xtina> 15s
[22:22:49 CET] <kepstin> if you want to empty the buffers, you need to send faster than realtime, but you can't do that because the streaming server wont' accept that
[22:22:59 CET] <xtina> if that doesn't happen, the stream buffers, audio overruns, and desyncs within 30s
[22:23:15 CET] <xtina> so, what is happening when speed reads 2x?
[22:23:22 CET] <xtina> where is all the extra data going?
[22:23:27 CET] <xtina> just drops or what?
[22:23:30 CET] <kepstin> xtina: hmm, then it must be sending to the server faster than realtime
[22:23:37 CET] <kepstin> no idea what the server's doing with it
[22:23:45 CET] <mdavis> What kind of server are you sending to?
[22:23:46 CET] <kepstin> it might accept it until a buffer fills, then force you to wait
[22:23:51 CET] <xtina> i dont care if data is thrown away as long as audio and video packets are thrown away together
[22:23:54 CET] <xtina> which means i stay in sync
[22:23:55 CET] <kepstin> mdavis: youtube, so a black box
[22:24:10 CET] <xtina> youtube, also trying twitch etc
[22:24:35 CET] <xtina> the way i see it is, with this initial surge i may lose some synced data, vs. letting one of the two pipes overflow causing permanent desync
[22:24:43 CET] <kepstin> xtina: it's probably not throwing data away, but more likely filling a buffer then forcing ffmpeg to wait before submitting more (since tcp can't "lose" data)
[22:25:04 CET] <xtina> maybe it just increases the latency?
[22:25:09 CET] <xtina> like it starts 15s behind and then becomes 25s behind?
[22:25:49 CET] <xtina> if the audio/video packets are thrown away in sync, fine. if they are streamed in sync with added latency, also fine
[22:25:54 CET] <xtina> only thing that's not fine is desync haha
[22:25:59 CET] <mdavis> Maybe I'm just not understanding how your setup works. What commands are you using to start sox, raspivid, ffmpeg, etc?
[22:26:25 CET] <xtina> mdavis: http://vpaste.net/Ep89E
[22:27:02 CET] <xtina> all in a bash script that executes upon boot
[22:27:06 CET] <kepstin> xtina: it sounds like ffmpeg is sending data to youtube, then getting stuck because it can't send more, which then chains up and blocks raspivid/etc., which then causes data to be lost at capture time (xruns, etc)
[22:27:17 CET] <xtina> kepstin: that doesn't happen..
[22:27:39 CET] <xtina> i havent' seen an xrun in weeks, unless they aren't printed
[22:27:50 CET] <xtina> you mean overruns?
[22:28:01 CET] <kepstin> xrun and overrun is the same thing, yes
[22:28:08 CET] <kepstin> (well, xrun can also be underrun)
[22:28:10 CET] <xtina> let me try to describe what i see happening, though maybe i made false assumptions
[22:29:12 CET] <xtina> scenario 1: ffmpeg surges to 2x speed in first 5s, stabilizes at 1x around ~15s, no overruns or desyncs whatsoever, perfect realtime streaming for 30min-1hr, around which point the bitrate may start drifting and speed goes below 1x, causing buffering and audio overruns
[22:29:32 CET] <ZexaronS> hello
[22:29:43 CET] <kepstin> xtina: that's most likely caused by a desync between the audio and video timestamps, since they're sourced from separate processes
[22:30:00 CET] <xtina> scenario 2: ffmpeg does not surge enough (only goes to 1.5x), takes 30-60s to stabilize, "too long" for the audio pipe which blocks, causing audio frames to be lost in the first 1min of stream and causing overrun/desync in first 1min of stream
[22:30:14 CET] <shincodex> why is x264 pixelating
[22:30:18 CET] <shincodex> Something default something
[22:30:41 CET] <shincodex> "vlc had less pixelation"
[22:30:49 CET] <shincodex> "when i set keyframes to 1" it best
[22:30:49 CET] <furq> could you be less specific
[22:30:57 CET] <xtina> kepstin: i set a max interleave delta to 500ms
[22:31:03 CET] <xtina> if it goes above that the stream would fail with tons of error msgs
[22:31:03 CET] <mdavis> xtina: I think you can get rid of the -analyzeduration by using -c:a mp3 and -c:v h264. Might help with the startup time.
[22:31:04 CET] <xtina> i dont' see that
[22:31:06 CET] <shincodex> Im so low on ram to even be more specific
[22:31:07 CET] <shincodex> lol
[22:31:17 CET] <xtina> instead i slowly see the ffmpeg speed drift to 0.97, 0.96, ... for minutes
[22:31:35 CET] <shincodex> is there a avdictionary options
[22:31:45 CET] <shincodex> for h264 to tell it the defaults are bad stop that
[22:32:05 CET] <xtina> kepstin: the stream doesn't ever violate the 500ms desync and fail. i notice the audio overrun first and kill the stream
[22:32:22 CET] <xtina> unless you're saying a small sub 500ms desync could be causing the audio to overrunn?
[22:32:26 CET] <kepstin> xtina: that has nothing to do with the problem i'm talking about
[22:32:33 CET] <mdavis> shincodex: Maybe you're looking for the -crf switch?
[22:32:34 CET] <xtina> because i think this is possible - i was noticing the stream beginning to desync a tiny bit...
[22:32:42 CET] <kepstin> the issue is probably that ffmpeg is reading the audio slightly faster than the video or vice versa
[22:32:56 CET] <kepstin> because the timestamps on the audio vs video input streams aren't quite clocked the same
[22:33:10 CET] <xtina> kepstin: i see. can i clock them...?
[22:33:16 CET] <xtina> i've been curious if i can add timestamps and align them
[22:33:20 CET] <kepstin> the solution to that is usually to retimestamp the video to match the audio, which you can't do in ffmpeg command line unless you re-encode
[22:33:21 CET] <xtina> if so i could maybe ignore packet drops
[22:33:27 CET] <shincodex> crf
[22:33:31 CET] <mdavis> shincodex: -crf 23 is visually almost perfect
[22:33:52 CET] <shincodex> --crf <float> (x264) -crf <float> (FFmpeg) Constant quality mode (also known as constant ratefactor). Bitrate corresponds approximately to that of constant quantizer, but gives better quality overall at little speed cost. The best one-pass option in x264.
[22:33:59 CET] <shincodex> What is default crf
[22:34:00 CET] <kepstin> nah, crf 23, the default, is "usually good enough for most cases" but it can get a bit blocky in high motion stuff
[22:34:19 CET] <kepstin> default options, assuming you have a modern ffmpeg and not an old broken one, are preset=medium crf=23
[22:34:27 CET] <shincodex> hmm
[22:34:30 CET] <xtina> mdavis: i will try your suggestion of reducing startup time with c:a etc
[22:34:30 CET] <shincodex> let me see if i can find ver
[22:34:33 CET] <mdavis> OK, visually perfect is a bit much, but it's pretty good
[22:35:01 CET] <kepstin> around crf=18 is usually considered to not give noticable artifacts ("visually lossless")
[22:35:11 CET] <kepstin> depends on preset a bit too
[22:35:36 CET] <shincodex> hold on
[22:35:50 CET] <shincodex> avcodec version
[22:35:50 CET] <shincodex> right?
[22:35:51 CET] <xtina> kepstin: gotcha, so no timestamping unless i re-encode
[22:35:58 CET] <mdavis> That'll work
[22:36:20 CET] <xtina> i have to use sox to encode the audio so there's no hope of adding timestamps without re-encoding at least the audio
[22:36:27 CET] <shincodex> #define LIBAVCODEC_VERSION_MAJOR 56 #define LIBAVCODEC_VERSION_MINOR 12 #define LIBAVCODEC_VERSION_MICRO 101
[22:36:55 CET] <kepstin> xtina: the audio can't really be retimestamped, it's a fixed clock based on the samplerate (e.g. 48000 samples per second)
[22:37:12 CET] <xtina> oh, well then that's straightforward right?
[22:37:15 CET] <kepstin> xtina: which is why the video is usually reclocked - it's hard to notice difference of a few ms in frame timing
[22:37:47 CET] <xtina> if i did video command and timestamped video in ffmpeg (omx_h264) would that be 1 encoding or 2?
[22:37:53 CET] <mdavis> shincodex: The one I built last week is 57.80.101, so it's not that old
[22:37:54 CET] <xtina> (no raspivid)
[22:38:47 CET] <kepstin> if you have a 30fps video and a 48000kHz audio, but the device producing the video and the device producing the audio are running off different clocks with slightly different speeds (they usually are...), then something reading both of them will slowly get more and more desynced
[22:38:50 CET] <xtina> would it be raw video -> add timestamp -> h264 encoding
[22:38:59 CET] <xtina> or raw -> h264 -> decode+timestamp -> re-h264
[22:39:22 CET] <kepstin> xtina: I'm not sure, I don't know enough about how the rpi camera works
[22:39:23 CET] <xtina> kepstin, ohh i see
[22:39:31 CET] <shincodex> cant find default
[22:39:35 CET] <shincodex> looking for it in code
[22:39:46 CET] <xtina> that must be happening... my streams do slowly desync as they go on
[22:39:59 CET] <shincodex> i assume its memset(blah, 0, sizeof(blah));
[22:39:59 CET] <shincodex> thop
[22:40:17 CET] <xtina> kepstin: do you think i have a hope of timestamping my video in ffmpeg and then clocking it to my 44.1khz audio?
[22:40:23 CET] <xtina> to avoid this little clock difference?
[22:40:29 CET] <xtina> or is there a way to .. match the clocks?
[22:40:44 CET] <mdavis> shincodex: So you're using the library API>
[22:40:45 CET] <xtina> the video and audio clocks themselves, i mean
[22:40:50 CET] <shincodex> Yes.
[22:40:59 CET] <shincodex> that why i talk about options
[22:41:01 CET] <shincodex> its prob 0
[22:41:12 CET] <shincodex> and ffmpeg or vlc or both give it 23 by default
[22:41:17 CET] <mdavis> shincodex: Not as familiar with the library, let me dig around
[22:41:26 CET] <shincodex> i just see crf everywhere
[22:41:34 CET] <kepstin> xtina: probably the best you can do on ffmpeg is have it read the audio as fast as possible, then retime the video based on the "realtime" clock while also reading it as fast as possible, then the audio should more or less match up with the frame you get at the same time.
[22:41:47 CET] <kepstin> xtina: that's the best you can do with the ffmpeg cli
[22:42:40 CET] <xtina> i see, thank you. in this method, the audio has timestamps or no?
[22:42:54 CET] <kepstin> audio timestamps are just the sample rate
[22:43:19 CET] <xtina> oh sorry
[22:43:28 CET] <xtina> and is the muxer able to mux based on timestamps in realtime?
[22:43:43 CET] <mdavis> shincodex: and you're using libx264 for encoding
[22:43:45 CET] <mdavis> ?
[22:45:15 CET] <kepstin> xtina: you can use the setpts video filter to throw away the video timestamps and replace them with realtime.
[22:45:53 CET] <kepstin> I'm not overall sure how well that will work, but it might be enough.
[22:46:35 CET] <xtina> kepstin: cool :) i'm excited to hear a new idea. i'll try it out right now. thanks for humoring me
[22:46:56 CET] <shincodex> Im using whatever is there
[22:46:58 CET] <shincodex> so im guessing no
[22:47:11 CET] <kepstin> (if you're using ffmpeg to capture audio and webcam video (v4l at least, not sure about rpi cam) at the same time, it generates video frame timestamps like this by default i think)
[22:47:35 CET] <shincodex> rtsp stream
[22:47:38 CET] <shincodex> no devices like that
[22:47:42 CET] <shincodex> no audio either
[22:48:13 CET] <kepstin> shincodex: hmm, you're doing network streaming (rtp/udp)? then you might be seeing packet loss rather than an encoding issue...
[22:48:15 CET] <shincodex> --enable-parser=h264 --enable-decoder=h264
[22:48:23 CET] <xtina> kepstin: gotcha. i just can't do the audio this way i think but i'll try your suggestion
[22:48:31 CET] <shincodex> "VLC IS SO MUCH BETTER"
[22:48:35 CET] <shincodex> and im like "THERE THE SAME THING
[22:48:49 CET] <shincodex> mostly
[22:49:40 CET] <furq> who would ever suggest vlc for anything
[22:50:01 CET] <mdavis> I mean, viewing media files on a desktop, sure
[22:50:07 CET] <furq> nope
[22:51:29 CET] <xtina> kepstin: i'm still trying to wrap my head around the possibility that, because a/v might have slightly diff clocks, audio is read faster than video, causing speed to go below 1.0x for a few mins (why?) before audio overflows
[22:52:26 CET] <xtina> so speedd would go under 1.0x because eventually ffmpeg is sitting waiting for the slower clock (video)..?
[22:52:44 CET] <kepstin> xtina: if it's reading audio faster than video, speed would go down because at some point it'll try to read audio, there's no audio ready, so it'll wait for a bit until some new audio is available
[22:53:03 CET] <kepstin> then while it's waiting, the video buffer will be getting more and more full
[22:53:09 CET] <xtina> right
[22:53:19 CET] <mdavis> It might not even be about the clock. It could be due to the OS's thread scheduling.
[22:53:19 CET] <kepstin> (if the speeds are the other way, switch "audio" and "video")
[22:53:27 CET] <xtina> well my audio buffer is always the culprit of overflowing, but i don't know if raspivid complains when its buffer overflows
[22:53:29 CET] <xtina> i've never seen it
[22:53:38 CET] <xtina> probably the other way around
[22:54:07 CET] <kepstin> raspivid probably just hangs, then gives the next frame with an even further off timestamp, which makes the problem worse :/
[22:54:24 CET] <kepstin> is the pi zero only single core?
[22:54:46 CET] <kepstin> a single 1ghz arm core really isn't very much do doing, well, anything with video :)
[22:58:32 CET] <xtina> kepstin: single core ya
[22:58:52 CET] <xtina> hmm
[22:59:05 CET] <xtina> so you think even if i use setpts to attach realtime ts's, they will be even further off
[22:59:18 CET] <thebombzen_> xtina: what "times" is it reading/writing
[22:59:18 CET] <xtina> so then it would be better if i added timestamps in a different thread than ffmpeg?
[22:59:28 CET] <thebombzen_> is it still 0.66x or 0.67x?
[22:59:38 CET] <kepstin> xtina: it should fix the gradual change of sync, but it might cause you to have a larger constant desync
[22:59:38 CET] <xtina> thebombzen_: i'm not manually doing anything with timestamps
[22:59:54 CET] <xtina> but if you mean my speeds.. i'm at 1.0x now after the first 20s or so
[22:59:59 CET] <kepstin> (and depending on the other apps, it could make video "jumpy")
[23:00:03 CET] <xtina> and stay there til 30min in when i start to go 0.99, 0.98, etc.
[23:00:09 CET] <xtina> kepstin: i see
[23:00:10 CET] <thebombzen_> because earlier, you mentioned that it was 0.66 or 0.67x and were encoding with raspivid at 10fps and used ffmpeg -framerate 15 -i
[23:00:11 CET] <xtina> hmmmm
[23:00:52 CET] <xtina> thebombzen_: er.. sorry, hard to remember because i've been through so many iterations :( but i got a new wifi module that is capable of better speeds
[23:01:00 CET] <xtina> i think i was network throttled before
[23:01:15 CET] <xtina> now i can get like 10 up or so if i'm lucky haha
[23:04:54 CET] <xtina> kepstin: er, for realtime ts on the video, would i set setpts to time(0)
[23:04:55 CET] <xtina> ?
[23:05:03 CET] <xtina> RTCTIME The wallclock (RTC) time in microseconds. This is deprecated, use time(0) instead.
[23:07:02 CET] <xtina> oh, doh, there's a 'realtime' filter..
[23:07:25 CET] <kepstin> nope, that's not what you want :)
[23:07:33 CET] <xtina> oh nvm, that's wrong
[23:07:38 CET] <xtina> realtime is wrong, at least :)
[23:07:47 CET] <kepstin> xtina: using "settb=1000000,setpts=RTCTIME-RTCSTART" should do it
[23:08:06 CET] <kepstin> (it says RTCTIME is deprecated, but it's easier than using time() since it has the same units as RTCSTART
[23:08:07 CET] <kepstin> )
[23:08:28 CET] <xtina> ohh, i see :)
[23:08:38 CET] <kepstin> settb=AVTB,setpts=RTCTIME-RTCSTART should be equivalent I think
[23:10:42 CET] <thebombzen_> now, is it possible to use settb and setpts without decoding?
[23:11:00 CET] <thebombzen_> ideally those are all managed by the container, right?
[23:21:16 CET] <kepstin> thebombzen_: ffmpeg cli doesn't support doing much with timestamps when not re-encoding, since most ts manipulation is done by filters
[23:21:36 CET] <kepstin> (ts manipulation on encoded video is tricky, since frames get re-ordered
[23:21:47 CET] <kepstin> and then you have both dts and pts)
[23:21:50 CET] <thebombzen_> ah so it's possible but specialized and therefore hard to do with ffmpeg.c
[23:22:41 CET] <xtina> kepstin: how does this look for the audio ts? -filter:a "asettb=1000000,asetpts=N/SR/TB" \
[23:24:08 CET] <kepstin> xtina: don't manipulate the audio ts. if you do, the best you'll get is crackly audio since blocks of samples aren't continuous
[23:24:18 CET] <kepstin> xtina: only do stuff to the video frame ts.
[23:25:40 CET] <xtina> kepstin: ah i see :)
[23:25:45 CET] <xtina> i get some crazy stuff if i only set video ts
[23:25:46 CET] <xtina> http://vpaste.net/iknXI
[23:26:01 CET] <xtina> frame= 1 fps=0.2 q=1.6 Lsize= 109kB time=19884:06:28.23 bitrate= 0.0kbits/s speed=1.31e+07x
[23:38:35 CET] <mdavis> BtbN: I think I'm on to something. MinGW's unsigned long seems to be 4 bytes, but Cygwin64's unsigned long is 8 bytes
[23:38:51 CET] <mdavis> Will explore further.
[23:39:06 CET] <BtbN> so the sizes of the structs are different between them?
[23:39:25 CET] <mdavis> Yup
[23:39:33 CET] <BtbN> Well, that's a very good reason
[23:39:42 CET] <mdavis> That would do it, I think
[23:40:12 CET] <mdavis> So, with some judicious use of sys/types.h, this might be fixable :D
[23:40:23 CET] <mdavis> rather, stdint.h
[23:40:25 CET] <kepstin> that sounds like cygwin just watching linux programmer's expectations rather than mingw
[23:40:40 CET] <kepstin> mdavis: that would kind of break using any cygwin system library...
[23:40:46 CET] <BtbN> mdavis, no, that'd be bad.
[23:40:55 CET] <BtbN> As the sizes would mismatch on other OS then
[23:40:58 CET] <kepstin> mdavis: might as well just write native windows app instead
[23:41:08 CET] <mdavis> :/
[23:41:19 CET] <BtbN> The official cuda headers use those types
[23:41:32 CET] <BtbN> so we have to use the same, as the sizes between Linux and Windows would mismatch otherwise
[23:42:03 CET] <kepstin> when linux went to 64bit, 'int' was left at 32bit and 'long' was made 64bit; windows left 'int' and 'long' as both 32bit for app compat reasons I guess :/
[23:42:03 CET] <mdavis> Alright, maybe there's a switch or a define for cygwin's GCC to make it behave more like mingw
[23:42:21 CET] <kepstin> mdavis: no, that's such a fundamental change that switching it breaks everything
[23:42:27 CET] <kepstin> just use mingw's compiler :/
[23:43:21 CET] <mdavis> That defeats the purpose of using cygwin! I want to make everything difficult!
[23:43:37 CET] <xtina> kepstin: still tinkering but haven't found what's wrong with my setpts, anything you recognize?
[23:43:43 CET] <xtina> http://vpaste.net/iknXI
[23:43:43 CET] <mdavis> I'm not proposing that this be incorporated into the codebase, I just want it to work for me
[23:43:51 CET] <kepstin> xtina: no idea :/
[23:44:30 CET] <xtina> i mean, the audio file doesn't have timestamps right?
[23:45:01 CET] <xtina> it read 1 video packet and hundreds of audio packets
[23:45:15 CET] <mdavis> kepstin: Indeed: https://cygwin.com/cygwin-ug-net/programming.html#gcc-64
[23:45:53 CET] <xtina> i thought i needed to set asetpts based on 44.1Khz so the audio file has timestamps for the video file to match with
[23:46:02 CET] <xtina> but not sure
[23:46:16 CET] <kepstin> xtina: the audio timestamps are inferred from the sample rate
[23:46:42 CET] <kepstin> since there's e.g. 44100 samples in a second, that means the timestamp goes up by 1s every 44100 samples
[23:46:47 CET] <xtina> in ffmpeg docs it gives this example: asetpts=N/SR/TB
[23:46:52 CET] <xtina> is that really default?
[23:46:57 CET] <xtina> otherwise why's it an example?
[23:47:07 CET] <xtina> just wanna make sure the issue isnt w the audio
[23:47:43 CET] <kepstin> xtina: the audio timestamps in your case are set by the wav demuxer when it reads the audio from the pipe, and they're set to the exact correct values based on the sample rate
[23:48:12 CET] <xtina> i see
[23:48:12 CET] <BtbN> yeah, "unsigned long" is 4 bytes on Windows, and 8 on Linux.
[23:48:20 CET] <BtbN> cygwin follows linux, so it'S 8 bytes there
[23:48:33 CET] <BtbN> which obviously breaks
[23:48:48 CET] <xtina> the only ts-related printout i got: tb:1/1000000 pts:0 -> tb:1000000/1 pts:0
[23:48:51 CET] <thebombzen_> 44.1 kHz is divisible by 3^2 and 7^2 so that's not possible unless the timebase has two factors of three and two factors of seven
[23:48:58 CET] <xtina> the 1st video packet
[23:49:31 CET] <thebombzen_> in particular, one million has no factors of 3 and 7 so if PTS is per-sample, it's not possible to do 44.1 kHz perfectly with a timebase of 1 million
[23:50:09 CET] <kepstin> thebombzen_: well, when audio's muxed into a container, and the container doesn't support 1/44100 timebase, then the times will have to be rounded to the nearest supported, yeah
[23:50:26 CET] <kepstin> thebombzen_: but ffmpeg internally has no issue using 1/44100 timebase...
[23:50:36 CET] <thebombzen_> but it depends on how they're rounded. if the muxer muxes them and rounds them afterward, sure
[23:51:02 CET] <thebombzen_> but if the muxer has a fixed difference between samples, then there will be issues
[23:51:38 CET] <thebombzen_> also it doesn't need to support a 1/44100 timebase - just 1 / any multiple of 44100
[23:53:14 CET] <xtina> thebombzen: do i need to choose a timebase other than 1000000? one that is a factor of 44.1k?
[23:53:29 CET] <xtina> er
[23:53:30 CET] <xtina> a multiple**
[23:53:36 CET] <kepstin> xtina: don't change the audio timestamps! they're fine!
[23:53:58 CET] <xtina> kepstin: alright :)
[23:55:03 CET] <kepstin> most video players don't actually use the container timestamps on audio for anything other than seeking, normally... they simply get the continuous samples from the decoder, send them to the sound card to play on the soundcard clock, then show the video frames matching the audio rate as close as possible
[23:55:47 CET] <xtina> i am trying to understand why my ffmpeg speed is 'speed=1.86e+07x'
[23:56:18 CET] <kepstin> xtina: it probably read a bunch of video frames in a batch quickly, so the speed calculation got weird.
[23:56:27 CET] <xtina> it seems like maybe just reading 1 video packet made ffmpeg think it was going super fast
[23:56:38 CET] <xtina> kepstin: i mean i've never seen speed surge above 3x... not 7 orders of magnitude lol
[23:56:46 CET] <xtina> whatever changed is a result of the setpts command
[23:56:47 CET] <kepstin> I have no idea which timestamps the speed is calculated on, input or output
[23:56:51 CET] <kepstin> could look at the code I guess
[23:56:59 CET] Action: kepstin has to go now, tho
[23:57:06 CET] <xtina> okok. thanks again for all the help
[23:57:14 CET] <xtina> i think it might be a clock issue so i'll keep trying
[23:58:21 CET] <BtbN> mdavis, https://github.com/BtbN/FFmpeg/commit/266087949410ca5820ceb1dccdaddead664a63b5
[23:59:19 CET] <BtbN> entirely untested though
[00:00:00 CET] --- Tue Feb 28 2017
More information about the Ffmpeg-devel-irc
mailing list