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

[burek]

[00:10:30 CET] <AndrewMock> Hi! The documentation is really out-of-date. How do I compile using MinGW on+for win64?
[00:12:37 CET] <JEEB> if you have shell and compiler/linker/yasm available, it's just "./configure" . if your toolchain is not the one without prefixes, you will have to add --cross-prefix and possibly arch/os
[00:15:33 CET] <AndrewMock> i literally understood none of that lol
[00:15:37 CET] <AndrewMock> I am a noob
[00:15:51 CET] <AndrewMock> I have the msys2 shell
[00:16:06 CET] <JEEB> what is the compiler you have under gcc -v ?
[00:16:23 CET] <JEEB> msys or mingw. and 32bit or 64bit
[00:16:36 CET] <JEEB> the target line says that
[00:17:08 CET] <AndrewMock> http://paste.debian.net/330334/
[00:17:14 CET] <AndrewMock> msys2 64
[00:17:26 CET] <AndrewMock> man posix and win32 collide so badly
[00:17:26 CET] <JEEB> and that's just by running gcc -v ?
[00:17:37 CET] <AndrewMock> gcc -v
[00:17:45 CET] <JEEB> no, you just have multiple things conflicting in your PATH
[00:18:08 CET] <AndrewMock> okay i will uninstall cygwin i dont need it
[00:18:25 CET] <JEEB> no idea why you added cygwin to your PATH anyways. that's always never a good idea
[00:21:35 CET] <AndrewMock> bash: gcc: command not found
[00:22:19 CET] <JEEB> then it's probably x86_64-w64-mingw32-gcc
[00:22:32 CET] <JEEB> try writing x86<TAB>
[00:23:33 CET] <AndrewMock> nothing
[00:23:52 CET] <JEEB> i686-w64-mingw32-gcc?
[00:23:56 CET] <AndrewMock> am i supposed to install win-builds for native windows or for msys/cygwin
[00:24:05 CET] <AndrewMock> also nothing
[00:24:24 CET] <JEEB> then you haven't installed the mingw-w64 toolchain for your thing
[00:24:32 CET] <JEEB> be it 32bit or 64bit
[00:24:37 CET] <AndrewMock> i didnt want to collide the packages between the two so i put win-builds in c:/win-builds
[00:25:06 CET] <JEEB> and no, while msys2 does do some retarded things in their packages, you shouldn't need anything else
[00:25:12 CET] <JEEB> cygwin also provides a mingw-w64 toolchain
[00:25:21 CET] <JEEB> basically there's as many alternatives as you want to think of :P
[00:25:48 CET] <JEEB> main thing is to get a mingw-w64 toolchain (targeting i686 or x86_64) and yasm
[00:26:28 CET] <AndrewMock> https://i.imgur.com/vHaga8O.png
[00:26:31 CET] <AndrewMock> is that correct
[00:26:44 CET] <JEEB> I have no idea about win-builds
[00:27:11 CET] <AndrewMock> hmm okay i will try it
[00:27:14 CET] <JEEB> don't
[00:27:25 CET] <JEEB> just install a mingw-w64 toolchain into either cygwin or msys2
[00:27:36 CET] <JEEB> targeting either i686 (32bit) or x86_64 (64bit)
[00:27:42 CET] <JEEB> it's not hard :P
[00:27:46 CET] <AndrewMock> what is a "toolchain"
[00:27:52 CET] <AndrewMock> comipler/linker/loader
[00:28:12 CET] <JEEB> well you want gcc,g++,binutils
[00:28:21 CET] <AndrewMock> hmm thx
[00:28:34 CET] <JEEB> those for the mingw-w64 target that you want to build for
[00:28:38 CET] <JEEB> and yasm without any prefix
[00:28:39 CET] <AndrewMock> i always use msvc on+for win32 no worries lol
[00:28:47 CET] <JEEB> as it's just a tool
[00:29:11 CET] <AndrewMock> oddly yasm is not in win-builds
[00:29:39 CET] <JEEB> if you keep using win-builds then I can offer no help whatsoever
[00:29:52 CET] <AndrewMock> lol
[00:30:04 CET] <JEEB> also you can use MSVC 2013 update 2 or newer just fine for FFmpeg
[00:30:09 CET] <JEEB> although 2015 is preferred
[00:30:47 CET] <JEEB> you require a shell and the MSVC tools available in PATH (which is doable through `call "%VS1X0COMNTOOLS%vsvars32.bat"`)
[00:30:54 CET] <JEEB> (and yasm, of course)
[00:30:57 CET] <AndrewMock> i tried that. mingw seemed easier to #ffmpeg
[00:31:50 CET] <JEEB> for basic ffmpeg either should be as simple since you don't need the c99-to-c89 thing any more, just when you start wanting extra libraries it gets a bit more kinky
[00:32:12 CET] <JEEB> but due to package management msys2 or cygwin are probably in that sense simpler :P
[00:33:26 CET] <AndrewMock> lol win-builds is installing all packages?? oops
[00:37:27 CET] <PhoenixBR> Hi there everyone!
[00:38:08 CET] <PhoenixBR> I have a question for you, guys
[00:38:36 CET] <PhoenixBR> can anyone help me?
[00:38:54 CET] <c_14> If you asked your question, maybe.
[00:38:54 CET] <JEEB> don't ask metaquestions, just ask what you want to ask
[00:38:59 CET] <JEEB> somebody may help you
[00:40:16 CET] <PhoenixBR> ok, ok, it's maybe a noob question, you will see
[00:41:01 CET] <PhoenixBR> I have some raw YUV files (from video quality expert group) that I want to open in matlab
[00:41:34 CET] <PhoenixBR> I tried too many ways, without sucess
[00:42:16 CET] <PhoenixBR> So, I tried to convert to raw AVI files
[00:43:02 CET] <PhoenixBR> ffmpeg -f rawvideo -vcodec rawvideo -s 720x486 -r 30 -pix_fmt uyvy422 -i src13_ref__525.yuv -vcodec rawvideo output.avi
[00:44:05 CET] <PhoenixBR> I'm not sure if this command is right, but it worked! And the only pixel format that worked for me is uyvy422
[00:45:23 CET] <AndrewMock> that's not a question
[00:45:39 CET] <JEEB> well the pixel format defines how the data is stored
[00:45:51 CET] <JEEB> so if it's correct with uyvy422 then that's it
[00:46:06 CET] <PhoenixBR> but I'm not sure if this conversion added some degradation, delay or something to raw AVI file
[00:46:22 CET] <JEEB> it shouldn't
[00:46:34 CET] <JEEB> since you used the "rawvideo" encoder
[00:46:52 CET] <JEEB> check the "  Stream #0:0 -> #0:0" line in the terminal output
[00:47:04 CET] <JEEB> that should after that point tell you the input and output format
[00:47:17 CET] <JEEB> also with -v debug it will tell you all of the possible swscale filtering it would do
[00:49:17 CET] <PhoenixBR>  Stream #0:0 -> #0:0 (rawvideo (native) -> rawvideo (native))
[00:49:59 CET] <PhoenixBR> is there any problem if the videos are interlaced?
[00:50:10 CET] <JEEB> nope
[00:50:25 CET] <PhoenixBR> do I have to do some deinterlaced procedure first?
[00:50:25 CET] <JEEB> a) ffmpeg would have no idea about it since it's just raw YCbCr
[00:50:40 CET] <JEEB> b) you're not compressing it so it just goes in and goes out
[00:50:59 CET] <JEEB> if you want to deinterlace then you will have to deinterlace
[00:51:09 CET] <JEEB> if you want the interlaced content then you just use it
[00:52:40 CET] <PhoenixBR> I just want to open the frames of those videos in matlab =\
[00:53:18 CET] <JEEB> well, you should know then
[00:53:27 CET] <JEEB> if you want fields or frames or whatever
[00:53:51 CET] <PhoenixBR> by the way, when it's in yuv format, they are in ycbcr color format, right?
[00:53:59 CET] <JEEB> yes
[00:54:09 CET] <JEEB> which colorimetry is a whole another subject, though
[00:54:23 CET] <JEEB> you should ask from the creators about that unless it is marked somewhere else
[00:54:41 CET] <PhoenixBR> but when I convert the file to AVI, it's in RGB, right?
[00:54:44 CET] <JEEB> (if you are going to convert it to RGB and then use that data for something else than preview)
[00:54:47 CET] <JEEB> why would it?
[00:54:58 CET] <JEEB> -c:v rawvideo just dumps the shit through
[00:55:55 CET] <PhoenixBR> hum, nice
[00:56:25 CET] <PhoenixBR> So, when I open the converted AVI in Matlab, the frames are in YCbCr format?
[00:57:24 CET] <JEEB> depends on what the fuck matlab does
[00:57:30 CET] <JEEB> read the fine documentation
[00:57:32 CET] <PhoenixBR> It's because I will run a video quality algorithm, called SSIM for video, to measure the quality of the video based on the frames
[00:57:49 CET] <JEEB> there's a filter for that in ffmpeg
[00:58:04 CET] <PhoenixBR> So, the algorithm gets the frames in ycbcr format
[00:58:22 CET] <JEEB> more like it should get them, but you have to make sure your tool doesn't fuck things up in the process
[01:02:06 CET] <PhoenixBR> Ok, now I get it
[01:04:57 CET] <PhoenixBR> let me try something here, and I let you know the results :)
[01:05:29 CET] <PhoenixBR> I really appreciate your help! Thank you very much.
[01:28:02 CET] <Yuknown> Hey i'm trying to combine 3 mp4 files to one out.mp4 files but i get /home/mcs_v_all: Operation not permitted
[01:29:03 CET] <Yuknown> http://pastebin.com/me6yWD0m
[01:32:29 CET] <PhoenixBR> JEEB: It seems that ffmpeg convert color format ycbcr->
[01:32:33 CET] <PhoenixBR> ops sorry
[01:32:54 CET] <PhoenixBR> JEEB: It seems that ffmpeg convert color format ycbcr->rgb when I convert raw yuv-> raw avi
[01:34:37 CET] <PhoenixBR> JEEB: So, when I open AVI in matlab, I have to convert back rgb->ycbcr because the algorithm uses the y cb cr matrix
[01:34:47 CET] <JEEB> I bet that's the VFW shit
[01:35:07 CET] <JEEB> add -v debug into your ffmpeg command line and post the terminal output to pastebin
[01:35:12 CET] <JEEB> then link here
[01:35:21 CET] <PhoenixBR> JEEB: ok, wait a second
[01:38:01 CET] <JEEB> anyways, if your command line is how you showed it before I bet ffmpeg outputs YCbCr, but the thing you're using to load AVI most probably converts it to RGB :P
[01:38:26 CET] <PhoenixBR> http://pastebin.com/rsm9Xu68
[01:39:05 CET] <JEEB> Stream #0:0, 0, 1/25: Video: rawvideo, 1 reference frame (UYVY / 0x59565955), uyvy422, 720x576, 1/25, q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
[01:39:09 CET] <JEEB> that is your output
[01:39:24 CET] <JEEB> it is 4:2:2 YCbCr
[01:39:50 CET] <JEEB> so yes, as I thought, your most probably VFW-based AVI reader for matlab is most probably just converting your shit to RGB before giving you the values
[01:42:16 CET] <JEEB> I'd almost say that since you know the sample size and the way the samples are saved you might as well read the samples into your shit manually
[01:44:47 CET] <PhoenixBR> hum, let me try
[01:46:31 CET] <PhoenixBR> by the way, is this ycbcr->rgb->ycbcr conversions lose informations that I need to be worried?
[01:55:41 CET] <PhoenixBR> other question that I have, is uyvy422 a planar? What's the difference to yuv422p ?
[08:23:52 CET] <LloydZX> Hello to everybody!
[08:24:23 CET] <LloydZX> I have a problem with FFMPEG just installed on my Debian wheezy
[08:24:48 CET] <LloydZX> it says "No such filter: fps"
[08:26:40 CET] <LloydZX> May some of you be so kind to help me with this issue?
[08:29:07 CET] <spaam> LloydZX: what does ffmpeg -filters say? do you see fps there?
[08:30:18 CET] <LloydZX> no, I don't
[08:30:41 CET] <LloydZX> but I have just install ffmpeg from repository
[08:30:54 CET] <LloydZX> so I would not expect the version is too old
[08:32:18 CET] <spaam> wheezy is old
[08:32:34 CET] <LloydZX> so what can I do?
[08:33:01 CET] <spaam> upgrade to newer version of debian or compile ffmpeg on your own
[08:33:29 CET] <LloydZX> and about downloading a Linux Static Builds of ffmpeg?
[08:39:30 CET] <furq> http://johnvansickle.com/ffmpeg/
[08:39:32 CET] <furq> if you mean that then sure
[08:39:44 CET] <furq> but if it's possible then you should just upgrade to debian stretch
[08:40:20 CET] <furq> actually i guess 2.8.1 is in jessie-backports now
[08:42:03 CET] <LloydZX> should I download "git", "release" or both?
[08:42:20 CET] <LloydZX> (thank you furq and spaam, for your help!)
[08:52:11 CET] <relaxed> LloydZX: git is the dev branch, either will do
[08:56:07 CET] <wyatt8740> Is it normal that libvpx encodes about 50x slower than libx264?
[09:13:55 CET] <fritsch> yes
[09:14:03 CET] <fritsch> there is a nice blogpost about it
[09:14:08 CET] <fritsch> that I cannot find currently
[09:14:45 CET] <fritsch> Also decoding won't work for at least twice amount of people that could decode h264 without blowing fans
[09:15:30 CET] <fritsch> cause most browsers / players decode h264 with the help of hw
[09:15:54 CET] <fritsch> while VP9 is only available on very limited hw out there ... some hybrid approaches yes, but not that widespread
[09:21:37 CET] <wyatt8740> fritsch: this isn't a decoding problem though
[09:21:44 CET] <wyatt8740> so I don't get why you're bringing up hw decoding
[09:22:12 CET] <furq> i assume he's saying that you should avoid vp9 in general
[09:22:18 CET] <wyatt8740> also, both vp9 and vp8 are slow to encode.
[09:22:18 CET] <fritsch> jep
[09:22:32 CET] <fritsch> if you want to have a wide range of people that are able to watch your stuff
[09:22:37 CET] <fritsch> without issues
[09:22:46 CET] <fritsch> see the "Also" in my sentence
[09:23:00 CET] <fritsch> h264 is still the most common and most optimized encoder out there to my knowledge
[09:23:05 CET] <wyatt8740> my question was just if libvpx's encoder was slow, not which one I should be using (8 or 9).
[09:23:12 CET] <wyatt8740> alright
[09:23:32 CET] <fritsch> https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecoding-performance-vs-hevch-264/
[09:23:35 CET] <fritsch> here, found it
[09:23:38 CET] <fritsch> ^^ that's what I was searching
[09:24:10 CET] <fritsch> see second section "Encoding speed"
[09:24:40 CET] <wyatt8740> I was averaging around 10fps encoding speed.
[09:25:06 CET] <wyatt8740> actually average was 8.
[09:25:13 CET] <wyatt8740> just ended doing around 10fps
[09:25:43 CET] <fritsch> those new generation encoders have a long way to go
[09:25:58 CET] <furq> i don't think i've ever got libvpx-vp9 to actually use more than one thread
[09:26:02 CET] <fritsch> the guy that has written this article has also implemented ffmpeg's vp9 stuff
[09:26:11 CET] <furq> even with tile-colums/frame-parallel etc
[09:26:15 CET] <furq> +n
[09:26:37 CET] <fritsch> so in short: if you want to implement a "scaling" encoding service with a lot of throughput needed - you need something else for now
[09:27:27 CET] <wyatt8740> nah, just encoding rick roll for my otherwise mostly html 1.0 site
[09:27:32 CET] <wyatt8740> *web 1.0
[09:28:06 CET] <wyatt8740> :p
[09:28:20 CET] <wyatt8740> thankfully no scaling needed
[09:29:41 CET] <furq> such a cutting-edge joke surely deserves a cutting-edge codec
[09:29:51 CET] <wyatt8740> yep
[09:30:06 CET] <wyatt8740> just was upgrading at last from cutting-edge swf video :p
[09:30:22 CET] <wyatt8740> furq: http://wyatt8740.no-ip.org/rick.html
[09:30:36 CET] <wyatt8740> something I maintain just for lulz
[09:31:42 CET] <wyatt8740> but even more cutting edge http://wyatt8740.no-ip.org/ayb/11940_AYB_1_.swf
[09:32:24 CET] <fritsch> hahaha :-)
[09:32:33 CET] <fritsch> at least it makes good luck (for 10 seconds)
[10:31:12 CET] <Ironhand> is there an option for the ffmpeg command to select all audio streams from the source file rather than just the best one? I know I can accomplish this using several -map options, but I'd like to do this for a large number of files that have varying numbers of audio streams
[10:31:20 CET] <JEEB> -map 0:a
[10:31:31 CET] <JEEB> takes in all audio streams from input zero (first input)
[10:31:43 CET] <Ironhand> JEEB: ah, excellent... tyvm!
[10:31:46 CET] <JEEB> do note that you will also have to map the video and other tracks, too
[10:32:01 CET] <JEEB> otherwise only the audio track(s) will get selected
[10:32:14 CET] <Ironhand> yeah, makes sense, I read that -map disables all default mappings
[10:39:44 CET] <JEEB> yup
[12:34:45 CET] <JoshX> Hello :-) Question, I'm trying to transcode a 1920x1080x30fps H264 video stream from an IP cam over RTSP to webm format also in 1920x1080x30fps on a 12 core xeon machine..
[12:35:03 CET] <JoshX> so far i just ge a stalling ffmpeg, stalls for a few seconds and then continues
[12:35:13 CET] <JoshX> and i only have load on like 4 cores...
[12:35:38 CET] <BtbN> why transcode it when you need the same format?
[12:35:56 CET] <JoshX> webm/vpx != h264?
[12:36:21 CET] <BtbN> h264 should play just fine, if streaming to browsers is what you're trying to do
[12:36:28 CET] <iive> you encode to vpx ?
[12:36:33 CET] <JoshX> that is what i try to do..
[12:37:03 CET] <JoshX> my ffmpeg commandline is
[12:37:04 CET] <JoshX> -vcodec libvpx \ -cpu-used 8 \ -threads 32 \ -deadline realtime \
[12:37:21 CET] <JoshX> and in my ffserver i have format webm
[12:37:48 CET] <JoshX> its a 12 core X5675  @ 3.07GHz
[12:37:55 CET] <JoshX> it should laugh at this :-/
[12:38:08 CET] <furq> 32 threads?
[12:38:12 CET] <JEEB> welcome to libvpx
[12:38:27 CET] <JoshX> ah libvpx is the culprit
[12:38:34 CET] <furq> also yeah if you just want to stream it to browsers then there's no good reason to use vp8 over h264
[12:38:55 CET] <furq> or any questionable or bad reasons either
[12:39:06 CET] <JoshX> so what would be my ffmpeg codec and what would be my ffserver 'format' line?
[12:39:55 CET] <furq> is ffserver actually usable these days
[12:40:05 CET] <furq> i've not used it for a few years but i remember it being pretty bad
[12:40:18 CET] <JoshX> do you have an alternative i could try then?
[12:40:32 CET] <furq> https://github.com/arut/nginx-rtmp-module
[12:40:35 CET] <furq> i use that for live streaming
[12:40:42 CET] <furq> it doesn't do rtsp but it does rtmp and hls
[12:40:47 CET] <BtbN> Well, you need flash to play rtmp streams though
[12:40:53 CET] <furq> it does hls and dash as well
[12:40:59 CET] <BtbN> poorly
[12:40:59 CET] <JoshX> thats a no go for me :-/
[12:41:04 CET] <furq> fair enough
[12:41:14 CET] <furq> is rtsp well supported in browsers now
[12:41:16 CET] <BtbN> The dash streams nginx-rtmp generates don't play propperly for me.
[12:41:23 CET] <furq> i couldn't get dash to work
[12:41:27 CET] <furq> but hls works fine
[12:41:34 CET] <JoshX> Past duration 0.669991 too large
[12:41:34 CET] <JoshX> Past duration 0.679985 too large
[12:41:36 CET] <BtbN> hls isn't supported by browsers withotu flash either.
[12:41:40 CET] <furq> yes it is?
[12:41:45 CET] <BtbN> Nope it isn't.
[12:41:49 CET] <BtbN> Only Safari on OSX supports HLS.
[12:41:52 CET] <furq> it works in my browser without flash
[12:41:52 CET] <JoshX> what do those mean btw?
[12:41:54 CET] <furq> you need js
[12:41:57 CET] <BtbN> For DASH
[12:42:22 CET] <BtbN> Chrome and FF both don't support demuxing mpegts
[12:42:26 CET] <BtbN> So no luck with HLS
[12:42:43 CET] <furq> https://github.com/dailymotion/hls.js/
[12:42:49 CET] <furq> hls works in firefox without flash for me with that
[12:43:07 CET] <furq> that sure was a sentence
[12:43:08 CET] <BtbN> So did they seriously implement a mpegts to mp4 remuxer in js, or how is that supposed to work?
[12:43:29 CET] <furq> "it works by transmuxing MPEG-2 Transport Stream into ISO BMFF (MP4) fragments."
[12:43:30 CET] <BtbN> "it works by transmuxing MPEG-2 Transport Stream into ISO BMFF (MP4) fragments. "
[12:43:38 CET] <BtbN> ...
[12:43:39 CET] <BtbN> Horrible
[12:43:51 CET] <furq> does rtsp actually work in browsers now
[12:44:02 CET] <furq> and if so is ffserver actually any good now
[12:44:04 CET] <BtbN> WebRTC works, which is similar I guess
[12:44:35 CET] <furq> i had a brief look around some rtsp servers and they all seemed awful
[12:44:47 CET] <furq> i even tried icecast+webm but that means using libvpx and no thanks
[12:45:34 CET] <JoshX> oh btw if i set ffserver to use mp4 as format i get:
[12:45:35 CET] <JoshX> Tue Nov 10 12:45:06 2015 [mp4 @ 0x318ef90]muxer does not support non seekable output
[12:45:38 CET] <JoshX> Tue Nov 10 12:45:06 2015 Error writing output header for stream 'stream1': Invalid argument
[12:45:41 CET] <JoshX> Tue Nov 10 12:45:06 2015 127.0.0.1 - - [GET] "/stream1 HTTP/1.1" 200 62
[12:45:54 CET] <furq> iirc you have to use flv
[12:46:01 CET] <furq> or maybe mpegts
[12:46:08 CET] <JoshX> it works with the webm codec on the ffserver side and it plays in chrome on all platforms then
[12:46:12 CET] <furq> actually probably flv for browser support
[12:46:23 CET] <JoshX> but flv requires flash again?
[12:46:36 CET] <fritsch> BtbN: NVIDIA GeForce 940M <- that one in a thinkpad supports nvenc + h264 right?
[12:46:56 CET] <BtbN> I have that exact GPU in front of me right now, and it completely lacks a video unit.
[12:47:00 CET] <BtbN> No vdpau, no nvenc.
[12:47:06 CET] <fritsch> Ouh!
[12:47:20 CET] <BtbN> They expect you to use the Intel GPU in its Optimus setup
[12:47:26 CET] <BtbN> no idea if it's active when it's a standalone version
[12:47:58 CET] <fritsch> so what is the 940M to be used for?
[12:48:05 CET] <BtbN> 3D Acceleration
[12:48:10 CET] <fritsch> okay
[12:48:10 CET] <BtbN> And CUDA
[12:48:38 CET] <fritsch> so - if someone buys the laptop for windows - he rather should go with Intel's quicksync + media-sdk api?
[12:48:54 CET] <fritsch> if video encoding is needed?
[12:48:58 CET] <BtbN> It's the only option, yes
[12:49:01 CET] <fritsch> oki
[12:50:33 CET] <fritsch> BtbN: http://www.dell.com/de/unternehmen/p/precision-m4800-workstation/pd
[12:50:44 CET] <fritsch> the quadro's might work correctly - I assume
[12:55:38 CET] <JoshX> anyawy, thanks for the info.. lets see if i can get it to work with a lower quality for now..
[12:55:56 CET] <JoshX> [detached]
[16:24:21 CET] <OrthATG> I'm encountering av drift/sync issues when encoding an h264 live stream to an rtmp endpoint. I can correct gradual drift that occurs over time by manually interleaving & using the system time to calculate the position/frame number/pts for video.
[16:25:01 CET] <OrthATG> Audio and Video are run in separate threads at 30fps. When it runs in perfect conditions then everything is great. But if the video thread takes a lot longer than 1/30s to encode (primarily if internet connection drops) then there is "immediate" drift where it quickly gets out of sync.
[16:28:16 CET] <OrthATG> How can I calculate proper pts/dts values for video without the use of system clock?
[16:37:32 CET] <flux> why not system clock?-) you may be able to access the monotonically increasing clock if you are worried about someone setting time during the stream.
[16:41:11 CET] <OrthATG> by using the system clock, if theres a long internet drop of, say 3 seconds, where nothing is being encoded then when it resumes there will be a gap in pts&
[16:42:34 CET] <OrthATG> upon resume, the next audio packet is calculated based on the fixed sample size and has a constant duration
[16:43:58 CET] <OrthATG> whereas video, its frame numbers would be 1, 2, 3, 4, 95, 96, 97
[16:44:45 CET] <OrthATG> ^^ where there was a 3 second pause when encoding frame 4, causing the gap in frames
[16:47:18 CET] <OrthATG> my thought is that av_rescale_q expects a fixed framerate, so each frame will get set with a duration of 1/30s (33ms)
[16:47:53 CET] <c_14> PTS are usually just passed through (maybe with slight modifications)
[16:47:57 CET] <c_14> What's your commandline?
[16:48:13 CET] <OrthATG> in an app, live stream, real time
[16:48:30 CET] <c_14> You're using the API?
[16:48:31 CET] <OrthATG> using javacv as a wrapper
[16:48:35 CET] <OrthATG> yes
[16:48:45 CET] <c_14> What's the source?
[16:50:31 CET] <OrthATG> https://github.com/bytedeco/javacv/blob/cc420a8d7b88006ed52f314c55f87f0e84227e1f/src/main/java/org/bytedeco/javacv/FFmpegFrameRecorder.java#L695
[16:51:11 CET] <c_14> Not the source code, the video input.
[16:51:15 CET] <OrthATG> doh
[16:51:27 CET] <OrthATG> camera feed
[16:52:03 CET] <c_14> And the camera feed contains both video and audio or do you have a separate source for the audio?
[16:52:14 CET] <OrthATG> separate
[16:54:09 CET] <c_14> And the output is a single rtmp stream containing the audio and the video?
[16:54:34 CET] <OrthATG> yes
[16:54:43 CET] <c_14> And with "connection drops" do you mean outgoing or incoming?
[16:54:47 CET] <OrthATG> outgoing
[16:55:38 CET] <c_14> Audio is also from a live source?
[16:56:06 CET] <OrthATG> yes
[16:57:30 CET] <OrthATG> the issue happens at the encoder level, as opposed to the server or anywhere else in the chain and we can faithfully repro it
[16:57:48 CET] <c_14> Hmm, in that case the audio should block as well. In which direction does it go out of sync? Audio faster or slower than video?
[16:58:05 CET] <OrthATG> indeed - audio does block too
[16:59:19 CET] <c_14> Presumably audio faster, right?
[16:59:21 CET] <c_14> When it can't output it caches input for both but flushes the audio buffer faster than it can flush the video buffer.
[16:59:24 CET] <OrthATG> but when it comes back, the audio packets resume perfectly because duration is always calculated of the data sample size
[17:00:55 CET] <OrthATG> the video resumes, but its pts is now 3 seconds ahead of where it should be
[17:01:33 CET] <c_14> Ahead?
[17:01:35 CET] <c_14> Not behind?
[17:01:47 CET] <c_14> In that case it's dropping frames.
[17:04:39 CET] <c_14> Dropping frames and not then keeping track of sync
[17:04:40 CET] <OrthATG> the end result is that you hear audio and then 3 seconds later see the video that corresponds
[17:05:06 CET] <c_14> Then the video is behind.
[17:05:17 CET] <c_14> Which is probably the buffer flushing thing.
[17:05:22 CET] <c_14> I'd file a bug with javacv
[17:06:50 CET] <OrthATG> with interleave = true, i dont get the same 3 second pts gap on a drop
[17:07:17 CET] <c_14> Probably because it then makes sure that it keeps everything synchronized
[17:07:26 CET] <c_14> In order to interleave packets with the same PTS
[17:08:04 CET] <OrthATG> however the out of sync issue is much worse and gradual sync is uncorrectable
[17:08:20 CET] <c_14> It's worse interleaved?
[17:08:40 CET] <flux> how big is the FATE test suite?
[17:09:13 CET] <c_14> 936M (but I haven't synced in a few weeks, might be a tad bigger)
[17:09:20 CET] <OrthATG> over time it gets out of sync, but setting the frame number is ignored so theres no correction
[17:09:43 CET] <flux> c_14, thanks, no need to find extra space then :)
[17:10:21 CET] <flux> also the docs says two rsync repos, where the first is at rsync.mplayerhq.hu and it's not responding
[17:10:39 CET] <flux> so the libav.org one is the 'authoritative' one?
[17:10:43 CET] <c_14> I just always `make fate-rsync'
[17:11:10 CET] <flux> oh :)
[17:12:51 CET] <c_14> flux: seems to be fate-suite.ffmpeg.org
[17:14:39 CET] <OrthATG> for the api, the basic structure is just grab frame, init packet, avcodec_encode_video2, av_rescale_q (for packet.pts & packet.dts) then av_write_frame (or av_interleaved_write_frame if flag is true)
[17:21:12 CET] <c_14> I'd open a bug with javacv, if they think the bug is present in the C api they can forward the bug to trac.
[17:23:12 CET] <OrthATG> unfortunately the project doesnt have a lot of resources, so they dont dig much into things like this
[17:23:25 CET] <OrthATG> what can i do to facilitate?
[17:26:54 CET] <c_14> You'll have to find the equivalent C API usage (probably by checking the definitions of the used java functions) and then open a bugreport on trac (or maybe ask on the libav-devel at ffmpeg mailing list) describing the problem and the used libav* API functions
[17:27:05 CET] <c_14> Also preferably a way to reproduce it (that does not depend on javacv)
[17:28:15 CET] <OrthATG> awesome thx so much. ill post back if i find anything new
[19:20:16 CET] <Fjorgynn> I've got a problem
[19:20:44 CET] <Fjorgynn> I am downloading stuff via rtmpdump and converting from flv to mp3
[19:21:04 CET] <Fjorgynn> I am not really reencoding
[19:21:20 CET] <Fjorgynn> but the problem is that when I listen to it, it continues playing after "end" of file
[19:40:03 CET] <waressearcher2> Fjorgynn: hallo
[19:54:01 CET] <Fjorgynn> :o
[19:54:58 CET] <waressearcher2> Fjorgynn: wie gehts ?
[20:45:22 CET] <Fjorgynn> seems like I got my answer
[20:45:34 CET] <Fjorgynn> if I reencode it I get much longer filesizes
[20:47:12 CET] <Fjorgynn> or rather file lenght
[23:50:27 CET] <Vegas_dev> hello, i'm looking for some help with settings for resampling audio with soxr/swr and filters.  i've heard many audiobooks that just sound like someone is talking through a tin can.  say i have a podcast with mainly voice in an mp3, that has broadband white noise.   here are my swr flags "-swr_flags 1 -filter_size 24 -filter_type 2 -dither_method lipshitz -linear_interp 1" and soxr flags aresample=resampler=soxr -cheby 1 -precision
[23:50:28 CET] <Vegas_dev> 33 .   for filtering,  which is the best combination?  using highpass/lowpass or bass/treble or bandpass?
[00:00:00 CET] --- Wed Nov 11 2015