Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

January 2016

1 participants
62 discussions

ffmpeg-devel.log.20160130
by burek 31 Jan '16

31 Jan '16

[00:00:24 CET] <cone-895> ffmpeg 03James Almer 07master:8514f6dcfd29: avcodec/amrwbdec: use av_mod_uintp2 [00:00:25 CET] <cone-895> ffmpeg 03James Almer 07master:1bb3b90db833: avcodec/pngdec: use av_mod_uintp2 [00:00:26 CET] <cone-895> ffmpeg 03James Almer 07master:5893e8753702: avcodec/proresdec_lgpl: use av_mod_uintp2 [00:05:23 CET] Action: durandal_170 wonders who wrote vf_transforn [00:11:24 CET] <jkqxz> ffmpeg_filter.c:423: "if (codec->width || codec->height) {" <- can anyone suggest what this conditional actually wants to test? It doesn't trigger on the first graph configure because the encoder isn't initialised yet, and then does on all subsequent ones even if nothing has changed. [00:12:31 CET] <jkqxz> (This messes with you if want to pass something through the filter graph which vf_scale doesn't support, because it adds extra scalers which then barf on your frames.) [01:59:51 CET] <mattervr> wondering if someone can help me out with a nvenc_hevc hardware encoding issue. Seems that I am unable to transcode prores or dnxhd to h265 using the hw accelerated nvenc_hevc codec. Works just fine transcoding from h264. I have a full trace log posted here http://pastebin.com/Q05KVbBS [01:59:58 CET] <mattervr> is that a limitation of the nvenc_hevc encoder? or do I need to re-compile ffmpeg with additional flags? [02:13:31 CET] <Timothy_Gu> mattervr: does encoding to h264 work? [02:13:40 CET] <Timothy_Gu> you might want to file a ticket at trac.ffmpeg.org [02:15:01 CET] <cone-895> ffmpeg 03Timothy Gu 07master:9ba54c1b82a8: avcodec: Remove libaacplus [02:18:28 CET] <mattervr> yeah encoding to h264 using hw nvenc_x264 and cpu works just fine [02:27:50 CET] <cone-895> ffmpeg 03Kieran Kunhya 07master:e07e88cd82f7: avcodec: Remove libvo-aacenc support. [10:38:13 CET] <durandal_1707> in what room are everybody? [10:44:47 CET] <kierank> durandal_1707: open media [10:44:49 CET] <kierank> are you here? [10:44:54 CET] <kierank> not sure where atomnuker is [10:47:10 CET] <durandal_1707> nah, i wanted to watch live video stream [10:51:32 CET] <durandal_1707> will it be recorded and available to watch later? [11:40:46 CET] <kierank> durandal_1707: yes [11:42:02 CET] <funman> http://video.fosdem.org/2016/h2214/ [12:30:07 CET] <cone-218> ffmpeg 03Stephen Hutchinson 07master:0dd201d947e2: libx265: Remove experimental flag when encoding 4:2:2 and 4:4:4 [13:09:01 CET] <cone-218> ffmpeg 03Clément BSsch 07master:d3d03fd55e08: lavf/vqf: fix suported/supported typo [13:10:25 CET] <cone-218> ffmpeg 03Clément BSsch 07master:54ab90c05b9d: lavc/utils: fix instanciate/instantiate typo [13:23:54 CET] <wm4> hm trac is sloooooooow [13:31:00 CET] <cone-218> ffmpeg 03Carl Eugen Hoyos 07master:0275b2d91754: Changelog: Sanitize Common Encryption entries. [13:32:18 CET] <nevcairiel> wm4: always has been [13:33:07 CET] <cone-218> ffmpeg 03Carl Eugen Hoyos 07master:d391feff544f: lavc/v210dec: Allow odd width. [13:40:44 CET] <cone-218> ffmpeg 03Carl Eugen Hoyos 07master:31f5fa21b03d: lavc/exr: Move setting SAR down. [13:53:55 CET] <ubitux> any idea how i can make check_code actually do check up to linking? [13:53:59 CET] <ubitux> (configure) [14:43:13 CET] <luc4> Hello! How do I propose an update to an example code of ffmpeg? Through a bug report? [14:43:20 CET] <BBB> send a patch? [14:45:07 CET] <luc4> BBB: through a bug report? [14:49:35 CET] <wm4> to the mailing list [14:51:04 CET] <wm4> clone the git repo, make your change, commit, run "git format-patch HEAD~1" to produce a patch, and send it as attachment to the ML [14:53:16 CET] <luc4> wm4: ok, thanks [15:15:25 CET] <luc4> Anyone who knows if there is a specification about the seek callback to be provided to avio_alloc_context? [15:17:54 CET] <wm4> the code comments [15:51:11 CET] <luc4> wm4: you mean ffmpeg code? Not sure where to look as that callback should be implemented by me. [15:52:04 CET] <wm4> yeah [15:52:11 CET] <wm4> most functions are probably under-documented [15:52:33 CET] <wm4> patches for making the doxygen comments more precise would be welcome too [15:54:19 CET] <luc4> wm4: to complete the implementation of my code I need a proper definition. Im confused about the SEEK_END value for whence and AVSEEK_SIZE. Not sure how to behave for those values. [15:55:07 CET] <luc4> wm4: my code works, but an example should be very precise and I cant simply return -1 for those values. [15:57:06 CET] <wm4> you can e.g. look at libavformat/file.c to find out what they're supposed to do [16:01:00 CET] <durandal_1707> still old stuff in filter_design, anu volunters? [16:01:08 CET] <durandal_1707> *any [16:17:07 CET] <durandal_1707> the native aac topic seems gone from ha [16:19:30 CET] <luc4> Anybody who has ever seen a crash like this? http://pastebin.com/f7adHQ9W [16:46:50 CET] <RiCON> durandal_1707: https://hydrogenaud.io/index.php/topic,111085.0.html ? [16:54:18 CET] <jkqxz> wm4: On the codec profile constraint thing, would you be happy with trying possibly-compatible profiles iff the vaapi hwaccel is explicitly requested? If you are trying to autodetect, it will fail out and software can do it. If you explcitly requested it then it will give up anyway if we fail that test, so we might as well try. [16:57:11 CET] <wm4> jkqxz: I think the user should be made a conscious decision that the decoded video might be corrupted [16:58:43 CET] <wm4> (for profiles which are not strictly reported as supported by the hardware, and which are not strict subsets of supported profiles) [17:05:29 CET] <jkqxz> I don't think that conscious decision is a useful one, except to users who fully understand the problem. [17:13:50 CET] <jkqxz> Given my suggestion above, the user already explicitly requested that we decode on their VAAPI hardware. If it works, good. If it fails, ok, they asked for no software fallback anyway. Silently giving a wrong result is the problem, and in this case the user will have a warning message telling them what the problem was. [17:15:45 CET] <jkqxz> This is better than the DXVA2 hwaccel, which won't even give you a warning message for that case because it can't distinguish profiles far enough out to do so. (And it's the same hardware underneath, so silent failure will likely be equivalent?) [17:25:08 CET] <Daemon404> that src/ dir really screws up my grepping if i dotn distclean first [17:25:12 CET] <Daemon404> i get all my results twice [17:25:15 CET] <Daemon404> unless i build out of tree [17:25:16 CET] <Daemon404> -__ [17:28:27 CET] <nevcairiel> build on windows :D [17:28:49 CET] <Daemon404> ... is this src bs from andreas [17:28:53 CET] <Daemon404> seriously? [17:28:55 CET] <nevcairiel> of course [17:31:18 CET] <BBB> its so that we dont have to revert his patch, right? [17:31:37 CET] <BBB> although I seriously doubt that explanation, it looks mostly like a macho penis size contest [17:32:32 CET] <Daemon404> i dont really care why [17:32:37 CET] <Daemon404> i just care that it's a pain in the ass [17:33:54 CET] <BBB> I think you should bring that up in the ML and wait for the next hack that gives you a git grep equivalent that filters out each second line or so [17:33:55 CET] <BBB> :D [17:34:41 CET] <Daemon404> i dont even use git grep [17:34:41 CET] <jamrial> why does he need "bitexact" out of tree builds anyway? [17:34:43 CET] <Daemon404> i use grep [17:34:59 CET] <Daemon404> if i cant use standard unix unilities, that's ad [17:35:01 CET] <Daemon404> sD [17:35:02 CET] <Daemon404> sad* [17:38:27 CET] <wm4> I prefer in-tree builds because it's less of a bother generally [17:38:31 CET] <Daemon404> so do i [17:38:42 CET] <wm4> so do I hear this right, the debian bullshit broke windows builds and they're still broken? [17:38:49 CET] <Daemon404> and when im working on stuff i dont distclean between every change/build [17:39:07 CET] <Daemon404> but if i dont clean, grep is broken because of the src symlink [17:39:12 CET] <Daemon404> sure i could sort | uniq [17:39:14 CET] <Daemon404> but that's vs [17:39:15 CET] <Daemon404> bs [17:45:14 CET] <nevcairiel> Daemon404: way to edit your quotes before posting them on the ML =p [17:45:55 CET] <ubitux> fuck this pthread naming shit ffs [17:45:59 CET] <Daemon404> nevcairiel, only typos :P [17:46:28 CET] <iive> your grep should have option to not follow symlinks [17:47:01 CET] <Daemon404> iive, that's not a good argument [17:47:04 CET] <Daemon404> i could uniq|Sort too [17:48:09 CET] <iive> well, I guess moving all files is better solution. [17:49:31 CET] <Daemon404> it was working just fine until the series of 4 or 5 hacks that slowly broke different thinsg were pushed without much review [17:49:39 CET] <Daemon404> for a "feature" of dubious value [17:50:16 CET] <wm4> ubitux: heh [17:50:34 CET] <wm4> why is it so hard to check a specific signature, though? [17:50:56 CET] <ubitux> i can compile link and execute with a wrong sig [17:51:50 CET] <nevcairiel> cant you also test headers for presence [17:52:03 CET] <nevcairiel> i t hought we had crazy tests that can test all these aspects [17:52:08 CET] <ubitux> feel free to, i'm done with that crap [17:53:41 CET] <Daemon404> ubitux, you can work on subtitles again instead? [17:53:44 CET] <Daemon404> ;) [17:53:51 CET] <Daemon404> you love painful tasks apparently [17:54:19 CET] <ubitux> well actually [17:54:23 CET] <ubitux> that's exactly what i was doing [17:54:25 CET] <ubitux> :p [18:01:16 CET] <wm4> ubitux: don't know, mpv uses it on osx, glibc, bsd and netbsd [18:01:27 CET] <wm4> they're all different of course [18:01:55 CET] <nevcairiel> I use it on windows, only on windows, and its the same on every windows! :P [18:02:17 CET] <nevcairiel> (although a bit weird, you have to raise an exception with the string as an argument and a ratehr specific code, and it magically works) [18:02:31 CET] <wm4> does windows have an API for that? which one? [18:02:36 CET] <wm4> oh [18:02:52 CET] <nevcairiel> https://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx?f=255&MSPPError=-214… [18:03:22 CET] <wm4> ridiculous [18:03:22 CET] <ubitux> wm4: well, feel free to submit, i'd be really happy if you come up with a working solution [18:03:31 CET] <wm4> even requires MS extensions... [18:03:59 CET] <wm4> ubitux: sorry it's all in waf, and I didn't write the osx and bsd versions [18:05:53 CET] <nevcairiel> wm4: you dont need to use their extensions, just need to raise and catch the exception [18:08:42 CET] <nevcairiel> no idea what pthread emulation libraries do, probably just register an exception handler that ignores this one [18:09:26 CET] <BtbN> What the hell kinda method to set the thread name is that, wtf [18:09:57 CET] <nevcairiel> its a way to communicate with the debugger to inform it about the thread name =p [18:29:45 CET] <Timothy_Gu> durandal_1707: is there any asm that needs to be ported for former libmpcodecs filters? [18:30:57 CET] <durandal_1707> Timothy_Gu: nope, buth vf_phase seems simdable [18:31:30 CET] <Timothy_Gu> hmm ya [18:37:25 CET] <nevcairiel> hm I think I'll rebase, update and prepare the new dca decoder for pushing, its been sitting on the ML for so long now [18:38:33 CET] <Daemon404> nevcairiel, with remvoal of the old one...? [18:38:39 CET] <nevcairiel> of course [18:38:41 CET] <Daemon404> ok [18:38:42 CET] <nevcairiel> why would we have two [18:38:49 CET] <Daemon404> because ffmpeg is insane [18:39:06 CET] <Daemon404> i think this is the right move =p [18:39:16 CET] <Daemon404> but i expect at least a few regressions [18:39:21 CET] <Daemon404> mostly of broken files [18:42:28 CET] <Timothy_Gu> as long as it's better than when the new asf demuxer is first committed & [18:43:14 CET] <Daemon404> i trust foo86 a lot more as a programmer. [18:46:42 CET] <wm4> and I guess Libav will maintain the old decoder [18:46:46 CET] <wm4> sigh [18:46:49 CET] <kierank> going to push cfhd [18:46:56 CET] Action: Timothy_Gu really needs to set up distcc [18:46:58 CET] <kierank> when koda finishes [18:47:31 CET] <Timothy_Gu> durandal_1707: when you say log scaler, you meant using log scale for the freq axis? [18:50:09 CET] <durandal_1707> no, amplitude axis [18:50:29 CET] <durandal_1707> its default [18:50:35 CET] <Timothy_Gu> oh ok [18:50:58 CET] <Timothy_Gu> so the way i made the graphs is fine? [18:52:55 CET] <durandal_1707> Timothy_Gu: the height need to be power of two, otherwise half of freq are lost [18:53:46 CET] <atomnuker> durandal_1707: that ticket is from you, right? [18:54:06 CET] <durandal_1707> yes [18:54:26 CET] <atomnuker> you mean the beeps at the start are the artifact, right? [18:54:43 CET] <Timothy_Gu> durandal_1707: the height of the graph? what do you mean by "half of freq"? [18:55:58 CET] <durandal_1707> atomnuker: listen flac file and then aac file, aac file have strange sounds in right channel [18:57:32 CET] <atomnuker> durandal_1707: just tested it, I can't hear anything wrong with the right channel [18:57:40 CET] <atomnuker> but I don't have my headphones here, so [18:58:31 CET] <durandal_1707> Timothy_Gu: for 44100 you have 22050 freq, so y axis should have freq values up to 22050 [18:58:38 CET] <Timothy_Gu> ah ok [18:59:14 CET] <cone-218> ffmpeg 03Kieran Kunhya 07master:3485332bf996: avcodec: Cineform HD Decoder [18:59:57 CET] <Timothy_Gu> I thought the graph scales automatically with height ... [19:00:35 CET] <Daemon404> kierank, you forgot to bump the version [19:00:40 CET] <kierank> bah [19:01:05 CET] <kierank> should I just commit a bump? [19:01:15 CET] <Daemon404> yes [19:01:27 CET] <kierank> what do I bump? [19:01:44 CET] <Daemon404> should be avcodec minor version bump (and reset micro to 100 if it's >100) [19:01:55 CET] <nevcairiel> practically everything bumps minor, i dont even know what would bump micro [19:01:57 CET] <durandal_1707> atomnuker: headphones here [19:02:41 CET] <Daemon404> kierank, also add it to codecs.texi [19:02:44 CET] <Daemon404> with the bump [19:03:06 CET] <kierank> ? [19:03:08 CET] <durandal_1707> Timothy_Gu: that would technically masquerade real freq output [19:03:09 CET] <Daemon404> and changelog [19:03:38 CET] <Timothy_Gu> I see what you mean [19:03:42 CET] <Daemon404> we not codecs.texi [19:03:44 CET] <Daemon404> wtf file was it [19:03:54 CET] <Timothy_Gu> general.texi [19:03:56 CET] <durandal_1707> Timothy_Gu: it could be done, same as log scaler for freq axis [19:04:16 CET] <Daemon404> Timothy_Gu, ok [19:04:20 CET] <Daemon404> kierank, general.texi and changelog [19:04:21 CET] <Timothy_Gu> what is "window size" in this context [19:04:25 CET] <Daemon404> it's just a table entry [19:07:26 CET] <durandal_1707> Timothy_Gu: talking to me? [19:07:31 CET] <Timothy_Gu> durandal_1707: yeah [19:08:49 CET] <durandal_1707> Timothy_Gu: now it is directly correlated with height, next power of two defines size off fft window [19:09:00 CET] <jamrial> nevcairiel: changes in codec specific options and such bump micro [19:09:43 CET] <Timothy_Gu> now I know I will sound like a total noob but what is an FFT window? [19:10:44 CET] <cone-218> ffmpeg 03Kieran Kunhya 07master:32bf4a72e326: avcodec: Add forgotten minor bump, add Changelog and add Cineform to general.texi [19:12:16 CET] <durandal_1707> Timothy_Gu: fast Fourier transform [19:16:35 CET] <kierank> Bah I lost j-darnley [19:18:00 CET] <jamrial> kierank: no fate test? [19:18:23 CET] <kierank> I'll find a suitable sample [19:19:01 CET] <Daemon404> nobody will beat my sexy elenril sample [19:30:19 CET] <wm4> (slight morbid curiosity setting in) [19:31:09 CET] <Daemon404> it's the ficv sample [19:31:26 CET] <Daemon404> it's not as sexy as you think [19:36:53 CET] <Timothy_Gu> durandal_1707: seems like GCC is smart enough to automatically vectorize vf_phase [19:38:48 CET] <durandal_1707> Timothy_Gu: how you found it? [19:38:56 CET] <Timothy_Gu> disasm [20:40:55 CET] <atomnuker> Daemon404: why restrict the vectorization enabling patch to x86 only? [20:41:25 CET] <Daemon404> it's well known to be broken on x86 for quite a while. [20:41:34 CET] <Daemon404> and i would not enable it on lesser-user platforms without testing [20:41:39 CET] <Daemon404> it's only been tested on x86. [20:41:54 CET] <Daemon404> auto-vectorization is not exactly platform independent [20:42:00 CET] <atomnuker> yeah, makes sense [20:42:24 CET] <atomnuker> what was it that was broken about auto vectorization? made slower and larger code? [20:42:43 CET] <Daemon404> slower or miscompiled [20:42:50 CET] <Daemon404> every tried icl's autovectorization? :P [20:42:54 CET] <Daemon404> "it's faster, and slightly wrong [20:43:00 CET] <Gramner> aucto vectorization was known to miscompile stuff which caused alll kinds of fun breakage and debugging [20:43:28 CET] <Daemon404> didnt icl used to default to "fast float" [20:43:32 CET] <Daemon404> which just plain broke a lot of stuff [20:44:11 CET] <atomnuker> wow [20:45:47 CET] <Daemon404> https://github.com/FFmpeg/FFmpeg/blob/master/configure#L3825-L3827 [20:45:54 CET] <Daemon404> see [20:45:54 CET] <Daemon404> :D [20:46:43 CET] <Daemon404> also https://github.com/FFmpeg/FFmpeg/blob/master/configure#L3812 [20:47:04 CET] <Daemon404> https://github.com/FFmpeg/FFmpeg/blob/master/configure#L3809 [20:47:10 CET] <Daemon404> lol... icl. [20:47:59 CET] <Gramner> (@Daemon404) didnt icl used to default to "fast float" [20:48:01 CET] <Gramner> they still do [20:48:10 CET] <JEEB> :D [20:48:23 CET] <Daemon404> o ok [20:48:32 CET] <Daemon404> default for icl is to miscompile [20:48:36 CET] <Daemon404> as seen in links above [20:49:43 CET] <Gramner> --ffast-math and -fp:fast are good options that are quite useful, but they really shouldn't be on by default [20:50:02 CET] <Gramner> I'm guessing intel just enabled t by default so they can show how much better they are over MSVC in benchmarks [20:50:36 CET] <Daemon404> look how fast we are! no, ignore the output, look at the speed! [20:50:42 CET] <Daemon404> just make everything NOPs [20:50:44 CET] <Daemon404> much faster [20:53:20 CET] <Gramner> they are fine to use if you use floating point numbers as just approximate numbers which is quite common so comparing it to NOP is a bit silly. it's a problem if you rely on specific rounding behavior though [20:56:05 CET] <Daemon404> youre forgettign all the other bits that are enabled by default [20:56:07 CET] <Daemon404> that miscompiler [20:56:08 CET] <Daemon404> not just fp [20:56:11 CET] <Daemon404> s/r$// [20:58:37 CET] <Gramner> which are those? I mean there's a difference between fp optimizations that changes behavior by design and auto vectorization miscompilations that are just bugs [20:59:02 CET] <Gramner> because all compilers have bugs [21:00:03 CET] <Daemon404> Gramner, see linked [21:00:11 CET] <Daemon404> autovec and simd seem to be enabled by default. [21:00:14 CET] <Daemon404> and they miscompile. [21:02:13 CET] <Gramner> gcc also turns auto-vectorization on by default [21:02:19 CET] <Gramner> unless they changed it [21:02:33 CET] <Daemon404> i dont think that's a good argument in favour :) [21:03:03 CET] <Daemon404> gcc at leasts seems to compile most stuff correctly with it on [21:03:08 CET] <Daemon404> every 2nd thing i build with icl seems to break [21:03:19 CET] <Daemon404> perhaps a bit antecdotal. [21:03:27 CET] <Gramner> and gcc vectorization also miscompiles (or at least used to, I havn't really studied in a long time) [21:04:08 CET] <Daemon404> hey now [21:04:15 CET] <Daemon404> gcc is good at micompiling all on its own [21:04:18 CET] <Daemon404> with no autovec [21:04:30 CET] <nevcairiel> we talked about enabling tree vectorization on recent gcc versions some time ago [21:04:34 CET] <nevcairiel> not sure what happened to that [21:04:46 CET] <Gramner> I'm not sure I understand the business model of intel's compilers though. doesn't seem to be that many people buying and using them over msvc/gcc/clang/whatever [21:04:46 CET] <Daemon404> i mentioned it cause there's a new patch on the ML [21:05:05 CET] <Daemon404> Gramner, not for C/C++ [21:05:10 CET] <Daemon404> their fortran compiler however [21:05:15 CET] <Daemon404> very popular in certain communities [21:05:45 CET] <Daemon404> though that may be small. not sure. [21:05:51 CET] <nevcairiel> all I know of the intel co mpiler is that its popular in the ricer crowd, but those tend to not buy the compiler, so no clue who does [21:06:13 CET] <wm4> enterprise companies? [21:06:18 CET] <Daemon404> ive never known even 1 person who had a legit company [21:06:20 CET] <Daemon404> er [21:06:24 CET] <Daemon404> legit intel license [21:06:30 CET] <Gramner> enterprise usually go for msvc for windows stuff what I've seen [21:06:39 CET] <Daemon404> msvc from 10 years ago [21:06:56 CET] <nevcairiel> the performance difference to intel compiler on windows is marginal at best, and compatibility is worse [21:07:07 CET] <nevcairiel> does it still need this hack to not destroy performance on AMD CPUs [21:07:11 CET] <Daemon404> it had c99 going for it for a while [21:07:12 CET] <Daemon404> but thats gone now [21:07:24 CET] <Daemon404> oh, i know IPP is pretty popular [21:07:29 CET] <Daemon404> does that work with msvc, or just ICL? [21:07:30 CET] <nevcairiel> you can use IPP with msvc [21:07:35 CET] <Daemon404> ah ok [21:07:36 CET] <Gramner> and to be honest, minor performance differences is largely irrelevant for the vast majority of software nowadays [21:08:04 CET] <Daemon404> most perf problems i seem to read about are alloc related [21:08:05 CET] <Daemon404> not cpu [21:09:10 CET] <Gramner> or just retarded algorithms. e.g. (O^n) when you could make it O(n*log n) or better in like half an hour. an comoilers aren't gonna fix that for you [21:09:24 CET] <Daemon404> for(){for(){for(){for(){ [21:09:33 CET] <Daemon404> shit we need HPC / supercomputer! [21:09:37 CET] <Daemon404> ^ every academic [21:11:04 CET] <jamrial> you say that as if libavcodec isn't filled with nested fors :p [21:11:35 CET] <Gramner> nevcairiel: yes, intel only enables optimizations on intel cpus [21:12:02 CET] <Gramner> but it's fine. becase they have a 3px disclaimer about that in the manual [21:12:41 CET] <Daemon404> jamrial, :D [21:12:52 CET] <durandal_1707> where are retarded algos in FFmpeg? [21:13:18 CET] <Daemon404> there's a patch on the ML right now fixing one for wtv :P [21:14:43 CET] <durandal_1707> I ask for others :) [21:24:59 CET] <omerjerk> Hey so I was looking at ffmpeg trac [21:25:21 CET] <omerjerk> Is there any way to find if someone has already sent a patch to the ML for that particular bug ? [21:26:13 CET] <Daemon404> usually carl notes it [21:26:21 CET] <Daemon404> in the trac comments [21:26:23 CET] <Daemon404> but not always [21:27:32 CET] <omerjerk> I was planning to start with this - https://trac.ffmpeg.org/ticket/5160 [21:28:08 CET] <Daemon404> i dont remember seeign any doc patch for that [21:28:44 CET] <wm4> the easiest to know is following the ML [21:29:56 CET] <omerjerk> I follow that. [21:30:55 CET] <omerjerk> but it's too many mails and a high chance of missing the mails. [21:32:36 CET] <durandal_1707> omerjerk: no such patch have ever been sent [21:38:15 CET] <omerjerk> thanks. [22:13:46 CET] <durandal_1707> when are fosdem recordings going to be available? [22:23:11 CET] <Daemon404> if it follows last years schedule... 2 months [22:23:21 CET] <Daemon404> and given their live stream was broken the full day.... [22:23:26 CET] <Daemon404> i dont have high hopes. [22:23:33 CET] <nevcairiel> there all done, dca decoder nicely wrapped and ready for action [22:23:53 CET] <Daemon404> git drama origin master:master [22:24:28 CET] <nevcairiel> all intermediate steps build and pass fate and everything [22:25:06 CET] Action: Daemon404 pushes a subtle change which breaks dca but not fate [22:25:13 CET] <omerjerk> Btw there's also fossasia in March. Are you guys coming there ? [22:25:25 CET] <Daemon404> omerjerk, maybe, but seems unlikely [22:25:30 CET] <Daemon404> most of us are in europe [22:25:46 CET] <nevcairiel> yeah its easier for most to travel to fosdem if your flight is 1-2 hours at most [22:25:54 CET] <Daemon404> or train. [22:25:55 CET] <nevcairiel> or god beware you can even take the train [22:25:59 CET] <omerjerk> okay, I'll be there though. [22:26:26 CET] <BBB> Daemon404: lies, half of us is in the US [22:26:34 CET] <wm4> a train would have taken 6 hours or so for me [22:26:42 CET] <wm4> probably slightly longer than a flight [22:27:15 CET] <BBB> fosdem was just now? [22:27:28 CET] <BBB> any interesting talks? [22:27:35 CET] <nevcairiel> train takes 7 hours for me [22:27:39 CET] <nevcairiel> would probably favor flying [22:29:14 CET] <Daemon404> BBB, probably less than half, but yes [22:29:45 CET] <furkan> can anybody here comment on this issue? https://github.com/ZoneMinder/ZoneMinder/issues/811 [22:29:59 CET] <omerjerk> What do you guys mostly use to edit the source code ? Some IDE or a normal text editor like sublime ? [22:30:07 CET] <omerjerk> or vim ? :P [22:30:15 CET] <furkan> same issue is reported here for omxplayer on the raspberry pi (which uses ffmpeg as the back-end) https://github.com/huceke/omxplayer/issues/242 [22:30:21 CET] <nevcairiel> most proably just use their favorite text edito [22:30:23 CET] <nevcairiel> +r [22:30:34 CET] <furkan> i posted a screenshot near the bottom of that thread, of what it looks like https://www.dropbox.com/s/8s6m1ssi1wowbky/IMAG0096.jpg?dl=0 [22:30:40 CET] <Daemon404> and some people use their os (emacs) [22:30:41 CET] <furkan> the problem seems to be related to UDP buffering [22:31:06 CET] <wm4> rtsp with ffmpeg seems to be an endless source of pain [22:31:14 CET] <nevcairiel> thats just UDP being UDP [22:31:24 CET] <nevcairiel> if you stream high bandwidth, you need to increase the kernel buffers [22:31:24 CET] <cone-305> ffmpeg 03Michael Niedermayer 07master:8619582bdf1b: avformat/format: Replace nodat by enum [22:31:24 CET] <cone-305> ffmpeg 03Michael Niedermayer 07master:77864be44a0d: avformat/format: Weight the filename extension higher if there is nearly no data after an ID3 available [22:31:27 CET] <furkan> but there seem to be reports that increasing the buffer size fixes the issue [22:31:28 CET] <nevcairiel> sad story but true [22:31:36 CET] <Daemon404> that lines up [22:31:51 CET] <furkan> would it help, then, to add a paramter for rtsp streams to allow increasing the buffer size? [22:31:53 CET] <nevcairiel> for some people just increasing the UDP buffer in ffmpeg already helps [22:32:04 CET] <nevcairiel> i think someone suggested increasing it by default just recently [22:32:09 CET] <furkan> there seems to be an option already for udp:// streams, but not rtsp:// [22:32:58 CET] <furkan> man reason i'd like to use UDP is to allow multicasting [22:33:03 CET] <furkan> *main [22:34:06 CET] <furkan> this is all on a LAN, btw, so no packet loss or anything [22:38:39 CET] <furkan> for starters, would anybody mind exposing the "buffer_size" parameter that's already there for UDP streams to RTSP as well? [22:39:10 CET] <nevcairiel> rtsp has a buffer_size option [22:39:37 CET] <furkan> is this out of date then? https://www.ffmpeg.org/ffmpeg-protocols.html#rtsp [22:39:51 CET] <nevcairiel> probably [22:40:31 CET] <furkan> ok i see [22:40:37 CET] <nevcairiel> but rtsp is a demuxer, so you should be able to simply do ffmpeg -buffer_size 123 -i rtsp://... [22:47:47 CET] <furkan> i see, i'll try testing it out [22:50:04 CET] <nevcairiel> hm should adapt the existing synth filter simd for the new synth filter types, the differences between the two look trivial [22:50:12 CET] <nevcairiel> unless thats the simd jamrial said he already wrote :D [22:50:32 CET] <jamrial> nope, i wrote lfe1 [22:50:51 CET] <furkan> also, any idea why increasing the kernel's buffer size might help (as some are suggesting)? or do you guys not believe that it would? [22:51:20 CET] <furkan> or would that only help in the scenario where the application's buffer is filling up? [22:51:48 CET] <furkan> because i'm assuming that the kernel will just pass the UDP datagrams on to the application, and it's the application's responsibility to buffer until it has a full frame [22:52:51 CET] <furkan> given that there's no packet loss, and plenty of bandwidth (we're just talking a 6-10Mbps VBR stream here) i just don't see why there should be any trouble [22:56:22 CET] <nevcairiel> man the asm for that synth filter looks more complicated than I thought it would be [22:58:35 CET] <nevcairiel> just doubling all offsets used should probably still make it a valid synth64 [22:58:50 CET] <jamrial> with functions that are full of different paths for different cpuflags i usually remove every preprocessor check to get a cleaner view of wtf is going on [22:59:19 CET] <nevcairiel> thats probably not a bad idea [23:00:00 CET] <jamrial> this one function for example removes the main loop if you're using avx on x86_64, but not if you're using anything else [23:00:21 CET] <nevcairiel> yeah i saw that, it can process all 16 entries in one go on 64-bit [23:10:22 CET] <kierank> J_Darnley: sorry I spent ages trying to find you [23:10:37 CET] <nevcairiel> well i'll revisit that idea once its pushed, too much alternative code paths in there to start cleaning it up now [23:11:07 CET] <nevcairiel> should just enlist kurosu to write the 3 new variants, he wrote the original =p [23:11:36 CET] <kierank> J_Darnley: if you want to meet we will be around tomorrow [23:11:54 CET] <J_Darnley> Then I am truely sorry about that. I did leave without saying bye. /me hangs head in shame. [23:12:57 CET] <J_Darnley> I hope you all had a nice dinner. [23:24:58 CET] <kierank> Well please find me tomorrow [23:25:02 CET] <kierank> I am leaving late [00:00:00 CET] --- Sun Jan 31 2016

1 0

ffmpeg.log.20160130
by burek 31 Jan '16

31 Jan '16

[00:04:17 CET] <spidergeorg> hello, how can I sharpen this using the unsharp filter without adding edge halos? http://puu.sh/mOEK6/40e7684e95.PNG [00:04:35 CET] <spidergeorg> I'm afraid I don't quite understand the luma and chroma values [00:05:16 CET] <spidergeorg> this not the actual resolution of the source so I used the 'area' scaling algorithm since it gave me the best looking results [00:06:24 CET] <furq> if you're capping at native res then you should use neighbor [00:07:03 CET] <spidergeorg> I'm deinterlacing by separating the fields though so I end up with video that's the correct width but half the height [00:07:16 CET] <spidergeorg> and the resolution I'm resizing to isn't 1:1 [00:07:46 CET] <furq> use yadif mode 1 for deinterlacing if you want to keep the correct framerate [00:07:51 CET] <TD-Linux> yes, try a different scaler such as nearest. using unsharp is only going to give you halos. that's what it does. [00:09:08 CET] <furq> also fwiw that screenshot doesn't look like it's in need of sharpening [00:09:37 CET] <furq> i know some weird people like ultra sharp pixel boundaries though [00:09:43 CET] <spidergeorg> this is what using neighbor gives me http://puu.sh/mOF7U/91ccf6a73b.jpg [00:10:22 CET] <spidergeorg> yadif blurs motion pretty badly [00:10:51 CET] <furq> with mode 1? [00:12:10 CET] <TD-Linux> is that analog capture of a super nintendo? [00:12:36 CET] <TD-Linux> if so, and it's running in "240p", yadif is probably a bad idea actually [00:13:06 CET] <spidergeorg> @td-linux yes, and yadif mode 1 gives everything in motion a sort of wet look [00:13:14 CET] <spidergeorg> all of the hard edges are lost [00:13:34 CET] <spidergeorg> which is why I decided to go with separatefields and resizing since I had to resize anyway [00:13:51 CET] <durandal_170> trier nnedi 2x resize? [00:14:00 CET] <durandal_170> *tried [00:14:33 CET] <TD-Linux> yeah you probably actually want to deinterlace with just bob [00:16:30 CET] <spidergeorg> isn't yadif=1:0 bob? [00:17:14 CET] <spidergeorg> each field becomes a frame [00:17:35 CET] <TD-Linux> I don't remember. but it looks like whatever you're doing is working so disregard me [00:17:47 CET] <kepstin> yadif=1 turns fields into frames, but it interpolates the other field by guessing data rather than simply scaling like a bob [00:17:49 CET] <TD-Linux> does nearest not look like what you want for scaling, btw? [00:18:00 CET] <furq> 23:09:43 ( spidergeorg) this is what using neighbor gives me http://puu.sh/mOF7U/91ccf6a73b.jpg [00:18:11 CET] <furq> that doesn't look like something anyone would want [00:18:33 CET] <TD-Linux> ah it has the uneven sized pixels problem? [00:18:40 CET] <spidergeorg> no neighbor is causing the pixels to look different sizes, which is understandable since it's not the original size [00:19:07 CET] <spidergeorg> I'm just looking for a way to sharpen the resized video without adding bad edge halos [00:19:11 CET] <TD-Linux> one thing you can try is doing an integer scaling with nearest neighbor (like 2x), then scaling to your final size with bilinear or whatever [00:19:17 CET] <spidergeorg> the default values for unsharp look terrible [00:19:52 CET] <spidergeorg> so double the scale using neighbor and then down scale? [00:20:20 CET] <kepstin> spidergeorg: well, the way unsharp works is explicitly by "adding halos". The main thing you'll want to play with it is the blur radius setting, which effects how big the halos are. [00:20:38 CET] <kepstin> in effect, if your halos from the unsharp are the same size as the blurriness, they cancel out [00:20:39 CET] <spidergeorg> is there a way to mask just the edge halos? [00:24:19 CET] <TD-Linux> spidergeorg, yeah [00:24:57 CET] <TD-Linux> you can get a similar effect with some other filters but I don't think they are in ffmpeg [00:25:15 CET] <furq> i'd have thought separating fields and resizing would give nasty horizontal shimmering [00:25:33 CET] <TD-Linux> furq, well snes output isn't actually interlaced [00:25:36 CET] <furq> i've never tried to capture from a snes though [00:25:39 CET] <TD-Linux> (in most modes iirc) [00:26:23 CET] <furq> i would suggest using a better deinterlacer but if that's not an issue then there's not much point [00:27:10 CET] <furq> especially since using a better deinterlacer means using avisynth/vapoursynth [00:28:45 CET] <spidergeorg> is this what you mean @furq? http://puu.sh/mOGq5/9bf750f345.png [00:30:07 CET] <furq> no i mean the scanlines not lining up between frames [00:30:42 CET] <furq> it causes shimmering in motion, particularly during static scenes [00:30:51 CET] <furq> but if the snes doesn't actually output interlaced then that shouldn't be an issue [00:31:33 CET] <spidergeorg> ah ok [00:32:27 CET] <TD-Linux> furq, the snes messes up NTSC timing a bit so that on a CRT TV, the scanlines of each field are drawn on top of each other [00:35:08 CET] <furq> well then the best suggestion i can offer is to just use snes9x [00:35:15 CET] <spidergeorg> lol [00:35:21 CET] <spidergeorg> you mean bizhawk ;) [00:35:46 CET] <furq> are you recording tool-assists on a real snes [00:35:48 CET] <furq> that's pretty hardcore [00:36:19 CET] <furq> that would almost make up for the fact that you're playing yoshi's island [00:36:42 CET] <spidergeorg> haha [01:03:33 CET] <GuiToris> hello! is there an other way to trim my videos than $ ffmpeg -i clip -ss 00:01:00 -t 00:02:34 endresult.ogv? [01:03:46 CET] <GuiToris> I would just simply add the end time, if it's possilbe [01:03:59 CET] <furq> -to 00:03:34 [01:04:25 CET] <GuiToris> let's see, thank you furq :) [01:07:21 CET] <GuiToris> awesome, works as expected. thank you once again [01:16:23 CET] <spidergeorg> is it possible to output as a virtual device using solely ffmpeg? [01:54:23 CET] <spidergeorg> if you're capturing from a device and outputting to a file is it live when you run it or is it recording? [01:57:15 CET] <mattervr> wondering if someone can help me out with a nvenc_hevc hardware encoding issue. Seems that I am unable to transcode prores or dnxhd to h265 using the hw accelerated nvenc_hevc codec. Works just fine transcoding from h264. I have a full trace log posted here http://pastebin.com/Q05KVbBS [01:58:03 CET] <mattervr> is that a limitation of the nvenc_hevc encoder? or do I need to re-compile ffmpeg with additional flags? [01:58:37 CET] <mattervr> encoding fails with EncodePicture failed! [01:58:37 CET] <mattervr> Video encoding failed [06:43:41 CET] <spidersgeorg> it looks like it's possible to output to a window with opengl? would this be used with ffplay? [06:46:15 CET] <spidersgeorg> I'm trying to figure out a way to create a virtual device as the output [07:45:57 CET] <mmy> any one familiar with this error : [07:45:58 CET] <mmy> [hls @ 0x1db8850]failed to rename file tmp to [07:46:26 CET] <mmy> more details here : http://pastebin.com/kzxJdUVu [08:03:42 CET] <mmy> no one ? [08:03:49 CET] <mmy> [hls @ 0x1db8850]failed to rename file tmp to [08:03:59 CET] <J_Darnley> I guess everone is still asleep [08:27:25 CET] <vrfa> how can I improve playback using ffplay? I am dropping a ton of frames atm [10:39:39 CET] <hurstly> is it possible to output to a null/blank file in windows like you can in linux via /dev/null/ ? [11:10:01 CET] <SuperRoach> hello, how can i get ffmpeg to recognise a sequence like 0001.jpg ? image2 -i %04d.jpg [11:10:21 CET] <SuperRoach> Seems to not pickup the name. it's not %04d? [11:22:46 CET] <relaxed> SuperRoach: that should work, pastebin.com your command and output [11:23:02 CET] <SuperRoach> ok [11:23:44 CET] <SuperRoach> http://pastie.org/10701533 [11:25:30 CET] <jkqxz> Remove the "-f image2"? [11:28:20 CET] <SuperRoach> jkqxz, negative. yeah it does seem weird. I'll keep looking. [11:28:37 CET] <relaxed> pastebin.com your command and and all console output [17:30:24 CET] <luc4> Anybody who has ever seen a crash like this? http://pastebin.com/f7adHQ9W [18:14:49 CET] <dystopia> has some commands changed in the new builds on Zeranoe? [18:15:57 CET] <dystopia> my downloading commands have stopped working [18:16:11 CET] <dystopia> ffmpeg -i %m3u8link% -cookies %cookie% -vcodec copy download.mp4 [18:16:23 CET] <dystopia> works in last build, and fails in current build [18:18:16 CET] <dystopia> http://i.imgur.com/v9Opwwn.png [18:47:10 CET] <redalert> Hello, the hls muxer is now generating segments without subtitles (if the stream has), and puts them in vtt files [18:47:26 CET] <redalert> Is there any way to make the FFmpeg to use the old format for HLS, and the subtitles to be embed in the TS Segments? [18:47:34 CET] <redalert> or i need to use the old FFmpeg version? [18:47:59 CET] <redalert> didn't find any documentation for this [18:51:31 CET] <dystopia> i have reverted to an old version [21:46:32 CET] <spookypeanut> hello everybody [21:46:58 CET] <spookypeanut> i'm on a mission to rip my dvds at the correct speed, despite the pal speedup https://en.wikipedia.org/wiki/576i#PAL_speed-up [21:47:46 CET] <spookypeanut> i found this page, which is almost perfect: https://trac.ffmpeg.org/wiki/How%20to%20speed%20up%20/%20slow%20down%20a%20… [21:47:59 CET] <spookypeanut> but it doesn't say anything about subtitles [21:48:25 CET] <spookypeanut> i've tried several things, but can't find a way to speed up subtitles in a filter [21:48:31 CET] <spookypeanut> does anyone know a way? [21:48:47 CET] <J_Darnley> You will probably need another tool. I don't think ffmpeg has features like that for subs (yet). [21:49:34 CET] <J_Darnley> But look at the docs/help for various subtitle muxers/demuxers to see if they have some option for foring timing. [21:54:05 CET] <mobilespooky> (Sorry, have been forced to go mobile to calm a screaming baby) [21:55:07 CET] <J_Darnley> Shall I repeat my last two lines for you? [21:59:44 CET] <mobilespooky> Yes please [22:00:22 CET] <J_Darnley> You will probably need another tool. I don't think ffmpeg has features like that for subs (yet). [22:00:26 CET] <J_Darnley> But look at the docs/help for various subtitle muxers/demuxers to see if they have some option for foring timing. [22:01:41 CET] <mobilespooky> OK, thanks, I'll investigate [22:02:46 CET] <mobilespooky> I guess an option would be to pull them out to an srt, filter (manually? Need to look into file format) and re insert [22:03:12 CET] <J_Darnley> Yes, that would work. [22:03:43 CET] <J_Darnley> I don't know what tools you might use but SubRip definitely had that feature. [22:04:19 CET] <mobilespooky> Cool, thanks for the info! [22:05:03 CET] <c_14> You might be able to use aegisub, iirc it has such a feature. [22:05:46 CET] <J_Darnley> That is probably a much better idea than ancient subrip. [22:23:24 CET] <spookypeanut> damn, srt format is not an option, because my subtitles are from dvd (stored as bitmaps) [22:23:38 CET] <spookypeanut> will investigate those tools you mentioned [22:33:53 CET] <spookypeanut> hmmm, had a look at aegisub (subrip not an option, as i'm on linux), and it doesn't seem to do anything with bitmap subtitles [22:34:19 CET] <c_14> Yeah, I was assuming text subs. [22:34:41 CET] <c_14> Don't know of anything for bitmap subtitles. I avoid them. [22:54:27 CET] <spookypeanut> yeah :-/ i guess a (bad) option would be to burn them into the video before changing the speed [22:54:44 CET] <spookypeanut> i don't like it, but it would be better than nothing [22:58:00 CET] <c_14> Maybe something like http://forum.doom9.org/archive/index.php/t-162721.html ? Try searching for "retime bitmap subtitles" or something [23:07:21 CET] <spookypeanut> thanks, i'll have a look [00:00:00 CET] --- Sun Jan 31 2016

1 0

ffmpeg-devel.log.20160129
by burek 30 Jan '16

30 Jan '16

[00:00:25 CET] <ac_slater> wm4: stupid question. How much of a single line of YUV420P is Y ? [00:00:29 CET] <ac_slater> half? [00:00:38 CET] <Mavrik> Full. [00:01:42 CET] <ac_slater> Mavrik: oh so Y is just 2/3 of a frame? [00:01:51 CET] <Mavrik> ? [00:02:02 CET] <ac_slater> Mavrik: I'm looking athe picture on wikipedia [00:02:02 CET] <ac_slater> it's confusing [00:02:10 CET] <Mavrik> In 4:2:0, Y is full frame resolution , UV are half [00:02:20 CET] <ac_slater> https://en.wikipedia.org/wiki/YUV#/media/File:Yuv420.svg [00:02:32 CET] <ac_slater> I se [00:02:34 CET] <ac_slater> see * [00:04:02 CET] <wm4> that picture is confusing [00:06:05 CET] <ac_slater> Mavrik: what's resolution in your definition? [00:06:27 CET] <BBB> ac_slater: for a 100x100 image, y is 100x100 pixels and u/v is 50x50 each in 4:2:0, so in bytes, the y plane is twice as big as u+v together (so yes, 2/3rd) [00:06:49 CET] <BBB> ac_slater: but you cant really say per line because the line size is half, not quarter, its just that the number of lines is also half [00:06:51 CET] <Mavrik> ^ [00:07:21 CET] <Mavrik> The resolution of the raw frame before being stretched via SAR :) [00:08:45 CET] <ac_slater> interesting [00:09:13 CET] <ac_slater> in terms of bytes, Y is laid out FIRST then U, then V? [00:09:19 CET] <ac_slater> I hope that's the casr [00:09:21 CET] <ac_slater> case * [00:10:07 CET] <Mavrik> Aren't planes split in ffmpeg AVFrame structure anyway? [00:10:39 CET] <wm4> yes [00:11:00 CET] <wm4> but ac_slater has some omx thing that expects y/u/v all in one continuous buffer [00:11:09 CET] <wm4> and I'd expect Y comes first [00:11:13 CET] <Mavrik> Ah. [00:11:36 CET] <Mavrik> Yeah, I've mostly seen Y folloved by UV in those OMX cases. (NV12 or what's it called?) [00:11:46 CET] <durandal_170> kierank: yo evil, Trac thinks I'm spammer [00:11:53 CET] <wm4> Mavrik: he doesn't have nv12 [00:12:00 CET] <ac_slater> I'm confused since each channel/plane IS contiguous according the wiki image and what you guys said [00:12:04 CET] <wm4> just Y, then U and V (in whatever order) [00:12:07 CET] <Mavrik> Ok. I'll let you guys to it then :) [00:12:08 CET] <ac_slater> Trying to find a definition on "contiguous" [00:12:27 CET] <wm4> ac_slater: erm, that's not a specific term [00:12:29 CET] <ac_slater> Mavrik: thanks for the help mate [00:12:30 CET] <Mavrik> ac_slater, well, wiki image describes a theoretical case [00:12:44 CET] <ac_slater> wm4: I know I know ... but I still dont get it [00:12:46 CET] <wm4> the difference here is that ffmpeg can have each plane in an arbitrary place [00:12:53 CET] <ac_slater> ohhh [00:12:55 CET] <wm4> each plane can even be malloc'ed separately [00:13:06 CET] <wm4> all what counts is the plane pointers in AVFrame.data [00:13:10 CET] <ac_slater> I didn't know they cared about that [00:13:12 CET] <wm4> s/is/are [00:13:34 CET] <wm4> and in your omx thing it sounds like the U or V plane strictly follows the Y plane in memory [00:13:54 CET] <wm4> those av_image... functions also can give you this layout [00:13:55 CET] <ac_slater> I seeeeee now. [00:14:01 CET] <wm4> but AVFrame can be arbitrary [00:14:14 CET] <ac_slater> I do memcpy(in_buf, frame->data[0], n) [00:14:18 CET] <jkqxz> Remember that ffmpeg's YUV420P planes are ordered Y, V, U (Y, Cr, Cb), so if you copy them to your YUV buffer in that order you need to take data[2] before data[1] to get the colours right. (This will be obvious from the output, though.) [00:14:30 CET] <wm4> ac_slater: yeah [00:14:32 CET] <ac_slater> jkqxz: interesting [00:15:13 CET] <ac_slater> jkqxz: would this be the result of something like that? http://i.imgur.com/ERM8dQw.png [00:15:20 CET] <ac_slater> that == U and V swapped [00:15:56 CET] <Mavrik> Hrmf. [00:16:18 CET] <Mavrik> That looks more like wrong plane sizes, if the channels would be swapped you'd get colors broken uniformly. [00:16:22 CET] <Mavrik> But Y looks good :P [00:16:22 CET] <jkqxz> No, it swaps red and blue. Images all look kindof right, but people and whatnot are strangely coloured. [00:16:30 CET] <ac_slater> I'm all over the place. I'll see if simply copying planes 0,2,1 in that order to a contig buffer helps [00:16:38 CET] <ac_slater> jkqxz: I see thanks mate [00:17:25 CET] <BBB> jkqxz: wait what? yuv420p data[1] is u/cb in ffmpeg [00:18:28 CET] <wm4> ac_slater: ah wait a moment [00:18:30 CET] <JEEB> yeah, it's YCbCr in that [00:18:34 CET] <wm4> you can't use a single memcpy to copy a plane [00:18:46 CET] <jkqxz> The one OMX implementation I've worked on in the past required padding between planes (it was feeding into a H.264 encoder which needed the edge space). That would explain a strange offset if it were required here? (This is probably a very confusing thing to mention if it isn't.) [00:18:48 CET] <wm4> you have to copy line by line if stride is not equal to the plane width [00:19:23 CET] <ac_slater> my stride is equal the my plane width [00:19:53 CET] <wm4> but the AVFrame you get as input doesn't have to [00:19:55 CET] <jkqxz> How big is your image? 100x100? [00:20:02 CET] <BBB> the height of the buffer may be padded also [00:20:15 CET] <ac_slater> wm4: true. Dammit [00:20:22 CET] <BBB> that is, data[0] + stride[0] * height may not be equal data[1] [00:20:23 CET] <ac_slater> jkqxz: 640x480 [00:20:29 CET] <ac_slater> BBB: right [00:20:51 CET] <ac_slater> well shit [00:22:28 CET] <kierank> durandal_170: if you're at FOSDEM I'll fix it ;) [00:22:43 CET] <kierank> I have no idea how to fix in reality [00:23:38 CET] <jkqxz> (That was wondering about alignment: 640x480 is divisible by a large multiple of 2, so it probably isn't going to bite you here. Hardware things often care strongly about that too.) [00:23:50 CET] <ac_slater> agreed [00:26:30 CET] <ac_slater> BBB: so then if copying planes is difficult to do manually, what would you suggest - sws_scale? [00:27:17 CET] <ac_slater> and is linesize[n] a representation of the actual data in data[n] ? [00:28:32 CET] <ac_slater> oh wait, nevermind that last question... line != plane [00:31:04 CET] <ac_slater> avpicture_layout? [00:32:32 CET] <ac_slater> (av_image_copy_to_buffer() I mean) [00:38:22 CET] <ac_slater> woot! av_image_copy_to_buffer worked [00:38:50 CET] <ac_slater> wm4: I thought YUV420 was separated by line, not the entire image [00:38:55 CET] <ac_slater> so I was trying to manually pack things [00:39:15 CET] <wm4> oh [00:39:29 CET] <ac_slater> wm4: yea ....... [00:39:35 CET] <ac_slater> not to proud of myself there [00:39:43 CET] <ac_slater> too * [00:39:52 CET] <ac_slater> jkqxz: Mavrik wm4 BBB ... thanks guys [00:40:40 CET] <jkqxz> BBB: Gah, sorry about that. I was looking at this a day or two ago because of VAAPI formats, and it appears I got myself thoroughly confused. YUV420P == IYUV is YUV == YCbCr order. YV12 is YVU == YCrCb order. [00:42:14 CET] <jkqxz> I think that a platform I have worked on in the past has YV12 the wrong way around relative to everyone else. And the test I attempted a few days ago must have been wrong somehow (maybe I swapped twice), because repeating it in slightly different conditions I now get that answer. [00:55:58 CET] <jkqxz> (To which I think the lesson is mainly "this is confusing and you should check very carefully if dealing with multiple formats". The output makes a good check in itself, but that doesn't mean you haven't swapped twice.) [01:11:38 CET] <jkqxz> Might also be nice if the comment in pixfmt.h didn't have them the opposite way around. It doesn't make a statement on order, but if you try to infer something then you will be wrong. [01:13:33 CET] <nevcairiel> its called YUV420 not YVU420! :P [01:25:57 CET] <wm4> so which one is morally right [01:26:56 CET] <Plorkyeran> bgr24 [01:28:40 CET] <BBB> jkqxz: right, thats correct, thanks for clearing that up [01:56:36 CET] <cone-926> ffmpeg 03Marton Balint 07master:cfc040a49f4b: lavf: bump micro version after the new segment muxer options [01:56:36 CET] <cone-926> ffmpeg 03Marton Balint 07master:98e94dff7a59: configure: use -ldl for decklink [01:56:36 CET] <cone-926> ffmpeg 03Marton Balint 07master:995c7a6f5ad4: lavd/decklink_dec: add support for teletext [01:56:36 CET] <cone-926> ffmpeg 03Marton Balint 07master:6bc610b39efe: configure: remove libzvbi GPL dependency [02:06:45 CET] <ac_slater> thanks again guys [02:07:25 CET] <ac_slater> I'll share my pi2 openmax IL encoder in a few days. It's not worthy of being in the tree, but it's a fun toy [02:17:35 CET] <derekprestegard> hello, where can I find a description of ffmpegs IO patterns? [02:18:11 CET] <derekprestegard> Im trying to optimize for reading huge files out of S3 storage and this requires large IOs that are ideally highly parallel - not sure if ffmpeg can do this or not [02:25:43 CET] <Timothy_Gu> derekprestegard: are you doing it over the network or locally? [02:26:44 CET] <derekprestegard> @Timothy_Gu the storage is S3 so it will always be network. The server could either be an EC2 instance or a local server [02:27:14 CET] <derekprestegard> i.e. we will be using http or https for all communication with the storage [02:27:32 CET] <TD-Linux> it really depends on the file and isn't set in stone. [02:27:39 CET] <BBB> derekprestegard: I dont think i/o is parallelized in ffmpeg [02:27:50 CET] <BBB> derekprestegard: and more generally, i/o is really not the constraining factor in performance of ffmpeg [02:27:56 CET] <TD-Linux> s3 has really high latency, have you considered just pulling the entire thing? [02:28:09 CET] <derekprestegard> we have [02:28:12 CET] <BBB> derekprestegard: i/o is buffered, maybe a readahead buffer could be useful (in a thread) [02:28:18 CET] <derekprestegard> 200 GB source files ar ekind of unwieldy [02:28:25 CET] Action: TD-Linux actually uses a NFS mount on EC2 for this purpose [02:28:44 CET] <BBB> I would add a readahead thread in the caching layer (AVIOContext<>URLContext) [02:45:35 CET] <derekprestegard> thanks for the info guys [04:50:00 CET] <cone-926> ffmpeg 03Timothy Gu 07master:44304ae3220f: all: Add missing header guards [04:50:01 CET] <cone-926> ffmpeg 03Timothy Gu 07master:e74378aa8c53: amrwbdec_mips: Add missing ff_ prefix [05:16:58 CET] <Timothy_Gu> jamrial: lol, even your replies show how we have too many aac encoders [05:53:38 CET] <RiCON> Timothy_Gu: you forgot an ending "/" in decklink_common.h [05:56:11 CET] <RiCON> line 109 of libavdevice/decklink_common.h* [11:31:34 CET] <durandal_1707> Daemon404: does libutvideo x64 asm works on linux? [11:31:54 CET] <durandal_1707> I get crash when encoding [11:36:46 CET] <cone-795> ffmpeg 03Stefano Sabatini 07master:b91093a4111f: ffmpeg: replace "flush Media" with "flush_media" in benchmark_all output [12:33:58 CET] <cone-795> ffmpeg 03Michael Niedermayer 07master:2d163cbdabae: avcodec/huffyuvenc: Remove duplicate include [13:00:19 CET] <ubitux> kinda incredible the shitton of stuff you can find in sei [13:08:07 CET] <durandal_1707> ubitux: sei? [13:08:23 CET] <ubitux> h264 sei [13:39:23 CET] <cone-795> ffmpeg 03Michael Ira Krufky 07master:44a50feebe1f: libavdevice/decklink_common.h: fix broken build due to missing `/` [14:38:16 CET] <durandal_1707> who idiv instruction works? [14:38:48 CET] <durandal_1707> *how [14:40:37 CET] <J_Darnley> Sorry I just remember that it's complicated. [14:44:54 CET] <jamrial> durandal_1707: http://www.felixcloutier.com/x86/IDIV.html [14:49:05 CET] <durandal_1707> I always get fpe [14:54:47 CET] <J_Darnley> May I suggest that you post the code you've written and what you think the arguments hold? [14:59:34 CET] <durandal_1707> http://pastebin.com/tPg89A1X [15:01:33 CET] <Daemon404> g31 [15:01:35 CET] <durandal_1707> I'm missing smthing obvious [15:03:24 CET] <J_Darnley> What is "RDX:RAX" supposed to hold? A 128 bit signed integer number split over the two registers? [15:05:08 CET] <J_Darnley> You have checked the obvious thing that slices isn't zero? [15:09:02 CET] <jkqxz> You haven't written RDX? Signed overflow also gives you SIGFPE. [15:10:30 CET] <durandal_1707> divisor is 6, dividend is 0 [15:23:26 CET] <durandal_1707> xoring edx fixed it [17:00:03 CET] <cone-895> ffmpeg 03Mats Peterson 07master:b34c9d1b9d93: lavc/rawdec: Use AV_PIX_FMT_PAL8 for raw 1 bpp video in AVI [17:01:30 CET] <durandal_1707> is this pal8 saga finally over? [17:18:40 CET] <jamrial> ther guy is adhd as fuck, so probably no [17:19:38 CET] <wm4> I'm sure there's an infinite number of bugs with mov-in-mkv files [17:48:58 CET] <durandal_1707> kierank: that vlc t-shirt resembles something? [17:49:50 CET] <kierank> durandal_1707: reply on twitter [18:00:33 CET] <cone-895> ffmpeg 03James Almer 07master:6cc156793d4f: avcodec/dvaudio: add missing header include [18:42:17 CET] <ubitux> > Duration: 00:00:02.13, start: 0.533333 [18:42:20 CET] <ubitux> ffs [18:42:31 CET] <ubitux> 26.98 fps [18:42:37 CET] <ubitux> pretty sure fps is broken because of this [18:43:39 CET] <ubitux> playback is btw broken in most player [18:44:13 CET] <ubitux> that is, ffplay, mpv, vlc but not quicktime (obviously, and fuck edit list btw) [18:44:40 CET] <ubitux> i can't imagine the shit going on if some audio was present [18:46:26 CET] <wm4> what where [18:46:51 CET] <wm4> mpv doesn't normally use the reported fps, or if it does, only after attempting to verify it [18:47:01 CET] <ubitux> fps reported by ffmpeg [18:47:06 CET] <ubitux> i need to check if i can share that file [18:47:09 CET] <ubitux> just a sec [18:47:20 CET] <wm4> I've found many many files with broken fps reporting [18:47:34 CET] <wm4> usually mkv files with a wrong value in the file header [18:47:46 CET] <wm4> (and then there's vfr...) [18:48:57 CET] <ubitux> pretty sure it's because of the start time here [18:49:09 CET] <ubitux> (you have a bunch of frames with negative ts because of it) [18:49:40 CET] <ubitux> wm4: http://b.pkh.me/LZZX7353.MOV [18:49:41 CET] <ubitux> here you go [18:50:17 CET] <ubitux> so basically the beginning the video has a "laggy" effect [18:50:25 CET] <ubitux> in ffplay and mpv [18:50:53 CET] <ubitux> vlc seems to show the first one, and wait for the ts to reach 0, so it's freezing half a sec [18:51:02 CET] <ubitux> and quicktime plays it smoothly [18:52:05 CET] <wm4> hm just broken timestamps? [18:53:23 CET] <ubitux> who knows [18:53:35 CET] <ubitux> not sure if they are broken [18:53:42 CET] <ubitux> but they seem shifted by -start_time [18:54:07 CET] <ubitux> so starting around t=-0.5 [18:54:48 CET] <ubitux> would be nice to have some audio in it for a more pathologic case [18:56:05 CET] <wm4> fascinating, mplayer shows it flipped [18:56:09 CET] <JEEB> lol [18:56:38 CET] <wm4> ah it's the rotation hint [18:57:45 CET] <ubitux> yeah, i think i'll keep that sample for future tests, it has nice "properties" [18:58:24 CET] <JEEB> boxdumper is a great tool to quickly take a look at that info [18:59:11 CET] <JEEB> reminds me I should add compatibility for MS's tfxd's contents [18:59:20 CET] <JEEB> currently it just outputs it as a "UUID box" [19:20:21 CET] <cone-895> ffmpeg 03Neil Birkbeck 07master:c323c98ee348: libavutil/mastering_display_metadata.h: change fields to be rationals as this is how they are typically coded. [19:39:42 CET] <durandal_1707> what register number is edx? [19:45:43 CET] <BBB> durandal_1707: depends on the ABI [19:46:07 CET] <BBB> durandal_1707: mixing named registers and r%d gets hairy very quickly :D [19:49:04 CET] <ubitux> "i r" in gdb should give you a hint i suppose [19:51:13 CET] <jamrial> durandal_1707: look at the DECLARE_REG lines in x86inc [19:51:45 CET] <jamrial> as BBB said it depends on the abi (Win x64, Linux x64, x86_32) [19:57:43 CET] <BBB> do we have a filter that counts the number of frames and printf()s to stdout how many frames there were? [20:14:29 CET] <beastd> BBB: I guess idet kind of does it. Don't know if there's another filter that does something like you want. [20:16:38 CET] <ubitux> BBB: showinfo? [20:16:45 CET] <ubitux> otherwise you have a count frame mechanism in ffprobe [20:17:36 CET] <wm4> man I wish I knew how to use all the amazing functionality in ffprobe [20:17:49 CET] <wm4> but both docs and command line help are like "fuck you" [20:18:35 CET] <BBB> :D [20:19:18 CET] <ubitux> ffprobe -v warning -show_entries stream=nb_read_frames -of flat -count_frames <input> [20:20:41 CET] <wm4> why -v warning [20:20:58 CET] <ubitux> so you get only the useful info :p [20:23:41 CET] <cone-895> ffmpeg 03Michael Niedermayer 07master:8fac0d640341: avformat/avio: free url/avio options [21:21:21 CET] <Timothy_Gu> RiCON: crap. Seems like it was fixed [21:26:49 CET] <RiCON> Timothy_Gu: weird that it wasn't missing in the patch in ML [21:32:34 CET] <cone-895> ffmpeg 03Zhao Zhili 07master:1e2c2622120c: libavformat/network: use defined constant in poll [21:49:25 CET] <durandal_1707> there is thread on ha about native aac encoder [21:53:13 CET] <RiCON> oh, but still without the TNS fixes [21:54:14 CET] <durandal_1707> I just tested it with some flac sample and I could encounter difference [21:56:03 CET] <durandal_1707> s/encounter/hear [22:09:20 CET] <kierank> J_Darnley: if you are in town we are at moder lambic [22:09:59 CET] <J_Darnley> I was. [22:10:07 CET] <J_Darnley> I'm now back home. [22:10:46 CET] <J_Darnley> De Lijn have become cheap. Few busses after 21.00 [22:12:26 CET] <kierank> Sorry about that [22:12:37 CET] <kierank> We'll be at FOSDEM tomorrow [23:07:00 CET] <cone-895> ffmpeg 03Hagen Schmidt 07master:583a6431460a: mpegtsenc: Do not fail ADTS AAC muxing if the first frame is not ADTS [23:07:02 CET] <cone-895> ffmpeg 03Thierry Foucu 07master:9a0995269549: lavf/flvdec: Allow files where the PreviousTagSize is not set according to the spec. [00:00:00 CET] --- Sat Jan 30 2016

1 0

ffmpeg.log.20160129
by burek 30 Jan '16

30 Jan '16

[00:06:04 CET] <jakej> anyone know if vp9 -thread option works in ffmpeg 2.6? [00:06:22 CET] <jakej> setting -threads 0, 4, or 16 seem to make no difference [00:10:46 CET] <jakej> actually think i figured it out [00:10:55 CET] <jakej> libvpx-vp9 is out of date [00:10:59 CET] <jakej> version 1.3 [00:13:27 CET] <J_Darnley> $ssl [00:18:24 CET] <TD-Linux> jakej, yeah you'll get like twice as fast upgrading to 1.5 (not even counting multithreading) [00:50:03 CET] <pinPoint> h264==x264 I assume? [00:53:08 CET] <derekprestegard> hello, how do I specify the numver of taps for spline resizing? [00:53:28 CET] <derekprestegard> I like how Spline36Resize looks in AviSynth and want to get equivalent results in ffmpeg - how do I do that? [00:58:25 CET] <J_Darnley> pinPoint: H.264 is the standard. x264 is one encoder for said standard. [00:59:07 CET] <J_Darnley> derekprestegard: all scalers better than bilinear are so similar you won't see the different in real video. [00:59:49 CET] <drv> don't tell the mad-vr people [01:00:08 CET] <J_Darnley> Anyway, see if this http://ffmpeg.org/ffmpeg-scaler.html tell you how/if [01:00:12 CET] <derekprestegard> J_Darnley: I know this is generally the case - Im encoding SD from an HD source as part of an ABR package [01:00:20 CET] <pinPoint> k [01:00:31 CET] <derekprestegard> using spline36 instead of bicubic looks way sharper when you play on a 1080p display [01:01:28 CET] <J_Darnley> Another option to look at is the new zimg filter [01:01:32 CET] <derekprestegard> saw that page earlier - doesnt seem to indicate whether you can specify the number of taps or not. Its probably either 16 or 32, both of which are probably fine :) [01:01:36 CET] <derekprestegard> oh? whats that [01:01:50 CET] <J_Darnley> A new scaler some guy is working on. [01:02:28 CET] <J_Darnley> I don't know very much about it [01:04:23 CET] <derekprestegard> cool thx. btw madvr is amazing - but for me I really like the sync behavior [01:07:56 CET] <TD-Linux> unfortunately it's proprietary so it won't get added to ffmpeg [01:09:03 CET] <johnnny22-afk> trying to figure out why my mpegts is playing video too fast :o/ [01:09:37 CET] <johnnny22-afk> using mplayer the A-V: values decreases and decreases [01:10:30 CET] <johnnny22-afk> the .ts file generated is simply a 'cat' of many .ts segments [01:38:25 CET] <derekprestegard> any advice on making ffmpeg play nice with s3 buckets? [01:38:41 CET] <derekprestegard> particularly WRT read performance? [01:39:29 CET] <johnnny22-afk> I'm having a lot of messages when i ffprobe my .ts file. Any ideas on what's causing this ? http://pastebin.com/C6VDdZBW [02:47:45 CET] <needmorespeed2> Are there any tuning flags available for the default h264 decoder, or only when using x264? [02:48:18 CET] <pinPoint> isnt x264 just h264 [02:48:33 CET] <pinPoint> 16:02:49 -!- Buster [Buster@2001:470:1f0b:1639::2] has quit [] [02:48:36 CET] <pinPoint> oops [02:48:41 CET] <pinPoint> https://trac.ffmpeg.org/wiki/Encode/H.264 [02:48:50 CET] <needmorespeed2> x264 is a separate lib [02:50:14 CET] <relaxed> needmorespeed2: ffmpeg -h decoder=h264 [02:51:11 CET] <needmorespeed2> How can I access the h264 flags -crf and -preset when decoding in C++ using avcodec_decode_video2 ? [02:52:24 CET] <needmorespeed2> For x264, there is x264_param_default_preset but I want to tune the default h264 decoder [02:53:03 CET] <drv> those options only make sense when encoding [02:53:27 CET] <pinPoint> and check https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264.c#L1952 [02:53:39 CET] <pinPoint> or the just the whole file [02:53:39 CET] <relaxed> I guess you're hope is to replicate how it was encoded in the first place? [02:53:46 CET] <relaxed> your* [02:54:36 CET] <needmorespeed2> I am only interested in decode - not encode [02:59:54 CET] <needmorespeed2> I am looking for more decode speed. Does anyone know if x264 decodes faster than the default h264 decoder? [03:00:36 CET] <drv> x264 is an encoder only, not a decoder [03:00:44 CET] <J_Darnley> x264 IS NOT A DECODER! [03:01:31 CET] <needmorespeed2> There is a "fastdecode" flag in x264 [03:01:39 CET] <J_Darnley> And? [03:01:44 CET] <J_Darnley> IT IS NOT A DECODER [03:01:56 CET] <J_Darnley> That flag makes files which are quicker to decode. [03:02:17 CET] <needmorespeed2> Oh I see, thanks for clearing that up [03:02:42 CET] <J_Darnley> The options availble for ffmpeg's h264 decoder are in -f decoder=h264 and the global options. [03:02:48 CET] <J_Darnley> uh [03:02:56 CET] <J_Darnley> -h decoder=h264 [08:04:45 CET] <pinPoint> furq: TD-Linux c_14 my latest post: http://wideopenbokeh.com/AthenasFall/?p=347 [08:05:01 CET] <pinPoint> ideas, changes, additions? [08:06:01 CET] <furq> my idea is to run youtube-dl -f 266,141 to have it mux the video for you [08:06:19 CET] <furq> or 266+141 even [08:06:47 CET] <pinPoint> ah [08:07:50 CET] <furq> also don't use -b:v with libx264 unless you're targeting a filesize [08:07:54 CET] <furq> and if you are then use 2pass [08:09:13 CET] <pinPoint> furq: so how do I tell it to do a x264 file then without specifying encoder? [08:09:39 CET] <furq> you do specify the encoder [08:09:43 CET] <furq> use -crf instead of -b:v [08:10:18 CET] <pinPoint> which section are you talking about? the end? [08:10:30 CET] <furq> yes [08:12:12 CET] <pinPoint> ok [08:16:21 CET] <pinPoint> furq: does youtube-dl have ffmpeg infused in it? or does it use my ffmpeg in the same directory [08:16:36 CET] <furq> it uses the system ffmpeg [08:17:10 CET] <pinPoint> so mine in the same directory [08:21:05 CET] <pinPoint> furq: 12M is like -crf 10 [08:21:43 CET] <furq> yeah that's far too high [08:22:12 CET] <furq> 18-24 is a good range [08:22:30 CET] <furq> there's very little reason to use anything between -qp 0 and -crf 16 [08:23:15 CET] <pinPoint> even for large media files? bluray lvl [08:23:35 CET] <furq> well crf 16 might well exceed 12mbps [08:23:38 CET] <furq> it depends on the source [08:23:56 CET] <pinPoint> source file is 2160 @ 12.4Mbps [08:24:33 CET] <furq> i've seen 720p content exceed 10mbps at crf 20 [08:27:36 CET] <pinPoint> yeah crf 15 puts me at ~9Mbps [08:28:01 CET] <furq> youtube content looks like it's been heavily denoised so i'd expect it to compress well [08:28:02 CET] <pinPoint> it is downscaled to 1080p though [08:29:52 CET] <pinPoint> yeah: frame= 9463 fps= 39 q=-1.0 Lsize= 505654kB time=00:06:34.73 bitrate=10493.8kbits/s speed=1.63x [08:34:28 CET] <furq> why are you reencoding it anyway [08:34:40 CET] <furq> you could just download the 1080p version off youtube [08:35:05 CET] <pinPoint> furq: it is an example to understand how to deal with xbox one media player that is all. [08:35:21 CET] <pinPoint> In the normal world, I'd just grab a 1080p version. :) [08:36:21 CET] <pinPoint> Also an idea so one can possibly start with a large intermediate file to preview on xbox one [08:54:39 CET] <teyekea> dear all, i want to install ffmpeg to generate thumbnails from video for dspace repository. I want it on ubuntu for now and on centOs latter. so i download "ffmpeg-2.8.5.tar.bz2" then what?? i got some guide on how to generate thumbnails, but i couldn't found on the installation [08:55:43 CET] <ultramage> hi, is it possible to encode a rgb24 source using vp9 or h265 without distorting the colors? [08:59:44 CET] <relaxed> teyekea: that's the source, you need to compile it- see https://trac.ffmpeg.org/wiki/CompilationGuide [09:00:13 CET] <relaxed> teyekea: or you can download a static build, http://johnvansickle.com/ffmpeg/ [09:06:28 CET] <luc4> Hello! Im trying to open a container with ffmpeg libs to get data but Im getting this: http://pastebin.com/STgbtPGD. Anyone who knows why Im getting that error? Im doing this for a minimal test of a crash Im experiencing with ffmpeg in my software, so dont focus on minor details, just correctness. [09:06:59 CET] <waressearcher2> luc4: hallo und herzlich willkommen [09:07:05 CET] <luc4> Just to be precise: Im working on an arm platform. [09:09:24 CET] <ultramage> (Video: h264 (avc1 / 0x31637661), none <- the colorspace is supposed to go here, maybe you need to provide that info [09:10:26 CET] <luc4> ultramage: provide? How do I know without opening the container? [09:11:21 CET] <ultramage> hmm, according to the message underneath, it seems to be trying to guess the format, but running out of time? try stepping through the code (or add debug prints) to see which call pritns it [09:11:37 CET] <ultramage> you are setting max_analyze_duration, but you might be setting it too late [09:12:05 CET] <ultramage> also, "stream 0, offset 0x24: partial file" - that doesn't sound good [09:13:50 CET] <luc4> ultramage: avprobe works perfectly fine on the same file [09:14:08 CET] <teyekea> relaxed: thank you, now i am following the compilation guide [09:14:22 CET] <luc4> ultramage: and also my software using the same ffmpeg build works, just this minimal code is not working [09:15:20 CET] <ultramage> maybe some programmer in here or in -devel might know [09:16:50 CET] <luc4> ultramage: ok, place that before in the code but no difference [09:17:42 CET] <ultramage> alright, those later messages might just be the library trying to recover from some earlier problem, and confusing things [09:18:19 CET] <ultramage> I have no idea about programming this library, but I would try doing a search for those error messages [09:48:38 CET] <cousin_luigi> Greetings. [09:48:50 CET] <cousin_luigi> Is 2.9 due anytime soon? [10:18:20 CET] <waressearcher2> cousin_luigi: hallo wie geht's es dir ? [10:19:02 CET] <cousin_luigi> alles gut, danke [11:33:02 CET] <kurkale6ka> Hello, after this command ffmpeg -i foo.mp4 -ss 60 -c copy /tmp/bar.mp4, my video has lost it's createdate exif tag (it's been set to 0000:00:00 00:00:00) [11:43:46 CET] <waressearcher2> kurkale6ka: hallo und herzlich willkommen [11:52:17 CET] <TekniQue> so I have a problem with ffmpeg lagging despite not being CPU limited [11:52:31 CET] <TekniQue> where do I even start to diagnose this? [11:57:11 CET] <kurkale6ka> Hmm, so turns out I need -map_metadata 0 [12:14:12 CET] <TekniQue> the exact problem I have is that when I'm encoding 4 variants of something, performance drops below real-time and after a while ffmpeg quits without telling why, presumaby because of a buffer overrun [12:15:58 CET] <relaxed> TekniQue: pastebin.com the command and output [12:16:53 CET] <relaxed> kurkale6ka: ffmpeg version? [12:17:34 CET] <kurkale6ka> relaxed: 2.8.5 [12:19:03 CET] <relaxed> does it happen if you omit -ss ? [12:19:18 CET] <kurkale6ka> lemme test [12:20:41 CET] <kurkale6ka> yes, happens event without -ss [12:21:08 CET] <TekniQue> relaxed: http://pastebin.com/vRhmmvbn [12:22:11 CET] <TekniQue> this is a live source, and it'll run indefinitely with three outputs [12:22:25 CET] <TekniQue> with four outputs it'll do 23-24fps for a while and then quit [12:23:08 CET] <TekniQue> and no cpu core is even near max [12:23:28 CET] <TekniQue> and x264 speed preset has no effect on the fps [12:23:59 CET] <TekniQue> it'll lower cpu usage but not improve the throughput [12:28:44 CET] <relaxed> TekniQue: How many threads does your cpu have? [12:28:48 CET] <TekniQue> 12 [12:29:12 CET] <TekniQue> Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz [12:29:18 CET] <TekniQue> 6 cores, 12 threads [12:30:19 CET] <TekniQue> but watching htop, none of the 12 logical cores is much past 50% [12:30:51 CET] <TekniQue> as evident from running the command with 'time' [12:30:52 CET] <TekniQue> real 4m7.895s [12:30:52 CET] <TekniQue> user 19m50.749s [12:30:54 CET] <TekniQue> sys 0m37.770s [12:31:15 CET] <relaxed> try using -threads:0 3 -threads:1 3 .. [12:31:34 CET] <TekniQue> runs for 4 minutes, uses 20 of the 48 available processor minutes [12:32:13 CET] <relaxed> you know what I'm saying? [12:33:18 CET] <relaxed> kurkale6ka: I thought the metadata was always copied [12:33:38 CET] <kurkale6ka> me too [12:33:43 CET] <TekniQue> hm, what exactly will that accomplish? [12:34:52 CET] <relaxed> divide the threads evenly between each output, -threads:0 3 = use thre threads for the first output [12:36:58 CET] <TekniQue> well it made things worse [12:39:09 CET] <relaxed> does it happen if when you're not piping into ffmpeg? [12:41:25 CET] <TekniQue> I haven't tried that. But running ffmpeg with 3 outputs encodes in real time [12:41:27 CET] <kurkale6ka> is it worth filing a bug about my issue? [12:43:22 CET] <relaxed> TekniQue: stick around, maybe someone else has an idea [12:43:49 CET] <relaxed> kurkale6ka: sure, but look to see if there's one already [12:43:57 CET] <kurkale6ka> ok [12:51:37 CET] <TekniQue> relaxed: ok, to me it looks like there's some lock somewhere that becomes a bigger burden as the number of outputs grows [12:52:15 CET] <relaxed> TekniQue: what's ffmpeg's exit status? [12:52:18 CET] <TekniQue> in fact, using a file source encoding 4 outputs results in less than real time performance on another machine I've got running [12:52:56 CET] <TekniQue> but using a separate ffmpeg process to decode the file and pipe rawvideo+pcm into another process for encoding results in 1.5x speed [13:05:52 CET] <luc4> Hello! Anyone who knows why Im getting this output with the code reported? http://pastebin.com/STgbtPGD [13:09:15 CET] <TekniQue> relaxed: exit status 0 [13:09:45 CET] <J_Darnley> luc4: Is that all the output at the bottom? [13:09:55 CET] <J_Darnley> have you considered doing what it says? [13:11:36 CET] <luc4> J_Darnley: above that there is a large number of those printf placed in the read callback, I increased max_analyze_duration but not sure about probesize, how do I set it? [13:12:33 CET] <J_Darnley> along side the analyze there should be a probesize too [13:13:08 CET] <J_Darnley> I think the AVOpt name is exactly as printed. [13:44:37 CET] <ecraven> greetings :) [13:45:21 CET] <ecraven> is there a way to say "copy from the keyframe before 00:00:10 until 00:00:15"? I've tried combinations of -ss, -to and -t, but haven't succeeded so far [13:46:47 CET] <c_14> ffmpeg -i video -ss 10 -to 15 -c copy -map 0 out.mkv ? [13:48:08 CET] <ecraven> so -ss and -to name time positions in the input? [13:48:14 CET] <ecraven> (if used after -i)? [13:48:47 CET] <c_14> kind of [13:49:21 CET] <ecraven> hm.. -ss after -i doesn't got to a keyframe, right? but I need each segment to start with a keyframe :-/ [13:49:52 CET] <Mavrik> then put -ss before -i ? [13:50:11 CET] <c_14> It will always cut at a keyframe if you use -c copy [13:50:34 CET] <c_14> It can't cut anywhere else (without trashing video) [13:50:46 CET] <ecraven> c_14: ok, that's great [13:52:44 CET] <c_14> And putting -ss before -i won't necessarily force it to cut at a keyframe (if reencoding unless you set -noaccurate_seek) [13:52:58 CET] <ecraven> I'm using -c copy [13:53:15 CET] <c_14> Yeah, that was just for informational purposes. [13:53:17 CET] <ecraven> I have one mp4, I want to cut several segments and concatenate them [13:54:09 CET] <ecraven> alternatively, throw away some segments :) [13:58:08 CET] <c_14> You could also probably use: ffmpeg -ss 10 -i video -to 15 -copyts outfile [14:00:44 CET] <ecraven> ok, -ss <start-position> -i <input> -to <duration> seems to work [14:01:05 CET] <ecraven> what does copyts do? [14:01:22 CET] <ecraven> can I make ffmpeg just re-calculate all timestamps on the final video? [14:02:44 CET] <c_14> copyts copies the timestamps from the input to the output so that you can use -to as an output option with -ss as an input option. (otherwise -to acts like -t) [14:03:26 CET] <c_14> What do you mean recalculate? It should always align them so they increase monotonically from near zero [14:04:03 CET] <c_14> You can use -fflags +genpts to regenerate all timestamps though [14:04:22 CET] <ecraven> I should really know more about video stream internals :-/ [14:06:46 CET] <TekniQue> if the source is for example a ts file off a TV broadcast, the timestamps won't start anywhere near zero [14:10:33 CET] <ecraven> if I just combine segments from one source video in-order, I shouldn't have problems with the timestamps? or would I have to use -copyts to make sure I can recombine them? [14:11:17 CET] <luc4> J_Darnley: doesnt seem to be working with probesize. [14:11:58 CET] <c_14> ecraven: ffmpeg should take care of it [14:12:19 CET] <luc4> J_Darnley: I set it to 50000000, should be sufficient, shouldnt it? [14:17:24 CET] <J_Darnley> Have you checked that ffmpeg can openyour file? [14:23:10 CET] <TekniQue> relaxed: I strace ffmpeg, and in 86 seconds it made 35 thousand futex() calls, but it's not spending that much time in syscalls [14:23:35 CET] <TekniQue> most of the time is spent in read() but that's only 2 seconds per minute [14:26:36 CET] <relaxed> TekniQue: are you piping from decklink? [14:26:59 CET] <TekniQue> yes [14:27:40 CET] <relaxed> but your ffmpeg is compiled with decklink support, so why aren't you using ffmpeg to read from the device? [14:27:57 CET] <TekniQue> but of course, strace doesn't report the time spent un-scheduled while waiting for a blocking syscall [14:28:19 CET] <TekniQue> I compiled decklink support in because I wanted to test using the native decklink driver [14:28:25 CET] <TekniQue> but I haven't tested that yet [14:29:58 CET] <relaxed> I would do that and widdle your command down to so if it makes any difference- something simple [14:30:22 CET] <relaxed> to see* [14:31:36 CET] <TekniQue> trying that now [14:35:40 CET] <relaxed> fyi, widdle means to urinate. I meant whittle :) [14:36:35 CET] <TekniQue> well running with -i decklink it seems to survive but I wonder for how long [14:36:43 CET] <TekniQue> because it's reporting speed=0.8x [14:37:23 CET] <TekniQue> but 25fps [14:37:31 CET] <TekniQue> the numbers don't add up here [14:37:52 CET] <c_14> Try setting -framerate as an input option to 25 [14:38:06 CET] <J_Darnley> I'm not sure how correct that is. Using testsrc input doesn't even get to 1x speed [14:39:00 CET] <c_14> J_Darnley: testsrc with -re as an input option gets me about 1.01x [14:39:21 CET] <J_Darnley> Oh okay then. Ignore what I said. [14:39:55 CET] <relaxed> TekniQue: look at "ffmpeg -h demuxer=decklink" too [14:42:32 CET] <J_Darnley> Oh after leaving ffmpeg going for a few minutes the speed is approaching 1x. I must have had some big delay at the begining. [14:45:33 CET] <ultramage> I would like to encode my videos without degrading the colorspace, but neither x264 nor vp9 seem to accept rgb, or even yuvj444p... they just do yuv444 at best, which causes a visible shift in brightness [14:45:49 CET] <c_14> there's libx264rgb [14:46:29 CET] <c_14> Also the yuvj formats are deprecated, you could try setting -color_range instead [14:46:31 CET] <TekniQue> well it's not working, all I get is colorbars :( [14:46:34 CET] <ultramage> yeah, I found that and I'm using that, and it's good, but I thought I'd try the fancier algorithms to cut down on filesize, hmm. [14:46:52 CET] <ultramage> ahh, I'll see what that does, thanks [14:47:50 CET] <J_Darnley> x264 should work just fine with yuv(j)444p [14:48:13 CET] <ultramage> but h265/vp9 promise to halve the filesize ^^ [14:48:36 CET] <TekniQue> the native decklink driver is hardly documented at all [14:49:21 CET] <J_Darnley> Did I misread that x26*? [14:50:26 CET] <J_Darnley> If you do get stuck with h264 then make sure your player corrects the levels correctly. [14:52:20 CET] <J_Darnley> oh I think I mean yuv444p [14:52:27 CET] Action: J_Darnley should focus on one thing [14:58:12 CET] <TekniQue> ok, selecting the right format, the format numbers seem to change across different programs that use decklink... [14:58:17 CET] <TekniQue> and not it works beautifully [14:58:32 CET] <TekniQue> almost [14:58:39 CET] <TekniQue> it's down to 0.97x speed now [15:03:22 CET] <ultramage> hm, nope color shift still happens [15:03:45 CET] <ultramage> I guess I'll try waiting a year or two for libx265rgb or some such [15:04:01 CET] <TekniQue> back up to 1x [15:04:16 CET] <TekniQue> so maybe it's going to be alright [15:04:28 CET] <TekniQue> I'll leave it over the weekend to be sure [15:59:43 CET] <James123> Hello, is there a way to extract frame (keyframe) from video at specific time? I don't want to loose any quality in the process however (that's why I don't do a screenshot!) [16:01:00 CET] <TekniQue> uh [16:01:14 CET] <TekniQue> a screenshot isn't lossy by definition [16:01:32 CET] <TekniQue> but yes there is a way to output still frames [16:02:30 CET] <James123> TekniQue: Thank you, I will look into it [16:39:09 CET] <Zeranoe> I'm looking for some spec compliant AVI content. Is there a resource for finding sample media in different formats? [16:46:30 CET] <durandal_1707> samples.ffmpeg.org [16:46:59 CET] <Zeranoe> Just found upload.ffmpeg.org/samples/avi [19:38:23 CET] <johnnny22-afk> I'm attempting at understanding some anomalies I'm having with HLS segments that I'm then concatenating. I have a feeling the segments aren't 100% perfect. Here's the output of ffmpeg inspecting the frames and extra messages http://pastebin.com/miGGAXhg . On line 397 is the 1st frame that ffmpeg seems to discover, I assume it's the 1st, but then again maybe it's not. Nevertheless, the PTS is [19:38:23 CET] <johnnny22-afk> 61680.0000 while the T is 0.685333 . The anomalies I'm encountering are that while playing with mplayer without forcing the lavf demuxer gets bad audio offsynch, while with the lavf demuxer, when playing from segment to segment the audio sometimes doubles or studders. Also, I get a gray-startup and often get blocking when passing from segment to segment. Then, there's the case of all those [19:38:23 CET] <johnnny22-afk> h264 warnings between line 38 and 327. Anyone got hints at what might be particularly wrong ? [19:47:40 CET] <johnnny22-afk> Are the PTS vs T variations possibly related to the audio starting off-sync ? And if so, can ffmpeg be told to re-adjust the pts or t values to match ? [20:26:34 CET] <johnnny22-afk> is there a way to ask ffmpeg to not attempt at fixing audio-sync ? To just treath is as-is ? [21:02:46 CET] <johnnny22-afk> shouldn't my 1st frame DTS start at 0.000000 ? [22:53:38 CET] <t4nk296> how do you attach the scaling algo to the scale paramter? [22:53:42 CET] <t4nk296> parameter? [23:06:05 CET] <luc4> Hello! Anyone who can have a look at this code to see if there is something that could explain the reason for the output pasted below? http://pastebin.com/STgbtPGD [00:00:00 CET] --- Sat Jan 30 2016

1 0

ffmpeg-devel.log.20160128
by burek 29 Jan '16

29 Jan '16

[00:00:06 CET] <kierank> Yeah but you see vfr [00:00:08 CET] <kierank> That's worse [00:00:20 CET] <J_Darnley> I'm sure you can find interlaced somewhere! [00:00:44 CET] <Daemon404> kierank, there's vfr in broadcast [00:00:48 CET] <Daemon404> you just telecine it craftily [00:00:52 CET] <Daemon404> so it's "not" vfr [00:01:03 CET] <kierank> Yes [00:01:11 CET] <Daemon404> (and it looks like crap) [00:01:36 CET] <nevcairiel> i hate broadcasts that switch between telecine and true interlaced at will, its hell on processing pipelines [00:01:49 CET] <Daemon404> thats not so bad [00:01:55 CET] <Daemon404> it's worse when they overkay it on eachother [00:02:04 CET] <Daemon404> 60i overlayed on telecined material [00:02:05 CET] <Daemon404> yum yum. [00:02:37 CET] <nevcairiel> that too [00:03:05 CET] <Daemon404> or randomly run it through an analogue pipeline before broadcast [00:03:10 CET] <Daemon404> so theres dot crawl and rainbowign everywhere [00:03:15 CET] <wm4> is there a reliable way to detect interlaced vs telecined yet [00:03:30 CET] <nevcairiel> not really any good hands-off solutions [00:03:31 CET] <Daemon404> yes. eyes. [00:03:53 CET] <Daemon404> kierank, perhaps the broadcasters you work with are too competent :P [00:04:02 CET] <Daemon404> compared to some [00:06:52 CET] <jya> Daemon404: I was wrong there, seekable is [0, 55.936) [00:07:02 CET] <llogan> cbsrobot: why this change? https://trac.ffmpeg.org/wiki/CompilationGuide/Centos?confirm_email=&email_c… [00:07:55 CET] <Daemon404> jya, oic [00:08:07 CET] <Daemon404> it's that time of night when my brain starts going slow [00:08:14 CET] <jya> but when seeking we ask to seek to the point, get the first keyframe prior that point (found at 0), to ensure proper A/V sync (this was mostly due to MSE with audio and video track not always fully aligned), so we seek audio. Then we loop decoding until we reach the seek time [00:08:30 CET] <nevcairiel> llogan: our vlc hosts asked us to favor http cloning in our documentation to limit usage of the git daemon [00:08:36 CET] <jya> we don't find a video frame at seek time, and so it stall [00:09:10 CET] <llogan> nevcairiel: ok. it doesn't support --depth apparently, so i'll just remove that [00:09:12 CET] <jya> (more accurately, we hit EOS on the video track) so seek is interrupted and we start playing from 0. [00:09:59 CET] <Daemon404> i imagine this is probably not worth redesiging the architecture for in 2016. [00:10:36 CET] <jya> we've had a bug for that for a while. (dailymotion lodged it) [00:10:48 CET] <michaelni> llogan, someone reporting a security issue and i dont want to have open security issues in releases, so i have to make new releases [00:10:55 CET] <jya> I have a pending solution which is to totally ignore frame duration [00:11:05 CET] <jya> e.g. a frame is valid until a new frame starts [00:11:09 CET] <Daemon404> jya, is there a bug id i can shove in out internal tracker [00:11:11 CET] <llogan> michaelni: i see. just curious. [00:11:11 CET] <Daemon404> for the player guys [00:11:43 CET] Action: jya searching [00:12:18 CET] <durandal_1707> michaelni: something similar to hls? [00:12:38 CET] <jya> if we hit EOS when seeking on the video track, simply displaying that last frame and contiue seeking the audio would do easily [00:13:19 CET] <Daemon404> right, this is what chrome does [00:14:18 CET] <llogan> durandal_1707: wonder why russians didn't tell us instead of blogging (AFAIK). [00:14:33 CET] <Daemon404> llogan, you must be new to infosec =p [00:14:40 CET] <Daemon404> thats how they do it [00:15:00 CET] <Daemon404> bonus points if they complain they didnt get money [00:15:39 CET] <llogan> Daemon404: should i queue Yackety Sax again? [00:16:16 CET] <Daemon404> i had to google what that was... [00:16:21 CET] <michaelni> durandal_1707, out of array access from some fuzzer i would guess [00:16:39 CET] <llogan> Daemon404: bonus points for a running shrimp on treadmill [00:16:40 CET] <Daemon404> llogan, now i finally know the name of that song [00:16:52 CET] <llogan> aka "Benny Hill Theme" i think [00:17:00 CET] Action: jya googling Yackety Sax [00:17:32 CET] <jya> ah ! lol [00:18:05 CET] <rcombs> how much does PNS help in the AAC encoder? [00:18:18 CET] <nevcairiel> its a decent improvement [00:18:32 CET] <nevcairiel> although someone should poke atomnuker about all the PNS fate failures [00:18:40 CET] <jya> Daemon404: we started fuzzing ffmpeg a little while back, all created bug is marked private and michaelni is CCed on it. So not hard to do the right thing [00:19:07 CET] <Daemon404> jya, yeah i know... but you know how some of those infosec people are [00:19:29 CET] <nevcairiel> I dislike the secrecy, it makes reviewing any changes and whatnot hard, all I see is "fixes mozilla bug 12314512313" and i cant even look up wtf that is [00:19:31 CET] <Daemon404> although infosec people probably dont liek to be lumped in with them [00:19:46 CET] <jya> this is giving me frights just thinking about stagefright again [00:20:26 CET] <Daemon404> nevcairiel, probably wouldnt be hard to just have an ftp or something for devs [00:20:34 CET] <Daemon404> the problem is not the secrity [00:20:40 CET] <Daemon404> it's that most of them are under NDA from e.g. youtube [00:20:43 CET] <Daemon404> because theyre user content [00:21:08 CET] <kierank> jya: there is a security ML [00:21:10 CET] <jya> I was so annoyed by that entire stagefright episode. I found the bug and fixed it in Jan 15 (in our copy), notified stagefright. Comes Jun 15, still not fixed, someone come very vocally with 0-day disclosure, and he got $5k grant money [00:21:26 CET] <Daemon404> jya, sounds right [00:21:37 CET] <Daemon404> i assume stagefright = the android team? [00:21:42 CET] <jya> yes [00:21:44 CET] <Daemon404> theyve been very bad about community interaction [00:21:46 CET] <Daemon404> for years [00:21:47 CET] <Daemon404> IMO [00:22:04 CET] <nevcairiel> why do you think they go around announcing it wildly as 0-days, they want to make a name for themself [00:22:05 CET] <jya> that stuff is so badly designed... [00:22:16 CET] <nevcairiel> its not like anyone can stop them =p [00:22:53 CET] <kierank> I need to restart h264 fuzzing [00:23:11 CET] <durandal_170> why? [00:23:18 CET] <Daemon404> to find bugs, presumably. [00:23:47 CET] <kierank> Because I want to roll forward our ffmpeg [00:24:12 CET] <jya> I think we've started to only fuzz ffvp9 right now. because we now ship it for all platforms. While ffmpeg/h264 is only used on linux, and the linux users is a tiny proportion of our users [00:24:14 CET] <durandal_170> It take ages to complete [00:25:06 CET] <jya> fuzzing is an art really :) [00:25:28 CET] <kierank> I don't care much about the security aspects, more the crashing on air aspects [00:27:17 CET] <jya> kierank: should be the other way round really. [00:27:47 CET] <kierank> In the main we control our sources [00:27:54 CET] <jya> crashing is better [00:28:30 CET] <nevcairiel> if you dont run untrusted media through your setup, you dont really care [00:28:47 CET] <nevcairiel> but packet loss or whatever can always produce situations that could crash [00:28:48 CET] <Daemon404> kierank, i demand you secretly add max headroom into OBE [00:29:03 CET] <jya> nevcairiel: I wish this could ever be true for us :) [00:29:25 CET] <kierank> jya: Am I right in saying you're in Aus? [00:29:31 CET] <Daemon404> you think browsers get weird files? [00:29:49 CET] Action: Daemon404 should show his collection [00:30:08 CET] <nevcairiel> I've seen my share of crazy files as well [00:30:12 CET] <jya> nevcairiel: is there more nvidia cards supports VP9 than the 965 (or was that 985) ? [00:30:18 CET] <nevcairiel> 950 and 960 [00:30:26 CET] <nevcairiel> and probably the refreshed 750 [00:30:38 CET] <Daemon404> nevcairiel, and theyre always paired with crazy content too. [00:30:40 CET] <nevcairiel> not sure if they renamed it [00:31:12 CET] <jya> nevcairiel: the dxva with nvidia, do they use the same ID as intel to report that they support vp9 ? [00:31:25 CET] <nevcairiel> they use the one specified by microsoft [00:31:28 CET] <nevcairiel> which intel also supportrs [00:31:31 CET] <nevcairiel> so i guess? [00:31:31 CET] <jya> kierank: I'm in Melbourne yes [00:32:47 CET] <jya> nevcairiel: hmmmm I need to try it... can I ask you a favour ? do you have a working setup with this video card? [00:32:51 CET] <nevcairiel> yes [00:33:03 CET] <nevcairiel> although its not my primary card, that can throw off a bunch of applications [00:34:12 CET] <jya> can you get Firefox Developer Edition (45) and set media.webm.intel_decoder.enabled to true and media.mediasource.webm.enabled to true [00:34:18 CET] <jya> (you do that in about:config) [00:34:31 CET] <jya> and let me know if it works ? :) [00:35:58 CET] <nevcairiel> now i need a webm video i guess [00:36:03 CET] <jya> then you go youtube , they serve vp9 / webm [00:36:09 CET] <jya> if MSE webm is supported [00:36:26 CET] <jya> you can check with the "stats for nerds" (right click on the video) [00:37:30 CET] <nevcairiel> it plays vp9, but i couldnt tell you if it uses the intel decoder [00:38:13 CET] <jya> CPU usage maybe? [00:38:35 CET] <nevcairiel> looks too high for gpu decoding [00:39:35 CET] <jya> I put something in Firefox Nightly (it will be in 46) that let you know. you need to install this extension https://github.com/doublec/aboutmedia/raw/master/aboutmedia.xpi [00:39:37 CET] <nevcairiel> the official microsoft vp9 dxva specification is only a couple months old, intel had their proprietary interface long before that [00:39:49 CET] <nevcairiel> so it might just be something else [00:39:52 CET] <jya> if you go to the about:media page, it will say which decoder it's using (WMF or ffvp9) [00:40:04 CET] <jya> nevcairiel: ah that must not be it then [00:40:13 CET] <RiCON> Daemon404: http://j.fsbn.eu/Yj1z.txt probably caused by 0e6c8532? [00:40:15 CET] <jya> our stuff was really based on intel api [00:40:56 CET] <atomnuker> nevcairiel: if you want to help edit CMP_TARGET of the fate-aac-pns-encode to some crazy value, run fate-aac and tell me what PSNR you get when fate fails [00:41:15 CET] <jya> se we look for intel CLSID_WebmMfVp9Dec [00:41:26 CET] <nevcairiel> atomnuker: unfortunately it doesnt fail here, I only see it on a variety of fate systems [00:41:37 CET] <atomnuker> no, I want it to fail [00:41:46 CET] <nevcairiel> oh [00:41:48 CET] <jya> https://dxr.mozilla.org/mozilla-central/source/dom/media/platforms/wmf/WMFV… [00:41:48 CET] <atomnuker> so set the target to something that would make it fail [00:41:50 CET] <nevcairiel> give me a sec [00:42:53 CET] <jya> nevcairiel: have they only defined VP9 ? (they said they were going to support vp9, I wonder if they're doing VP8 too) [00:43:07 CET] <nevcairiel> jya: vp8 too, but i know of no hardware that supports that spec yet [00:43:17 CET] <nevcairiel> once it does, i'll add it to ffmpeg as well [00:43:58 CET] <Daemon404> RiCON, yes looks like koda typo'd that [00:44:04 CET] <Daemon404> it seems to be a bug in libav too [00:44:14 CET] <jya> nevcairiel: where is it in ffmpeg? want to see which CLSID/GUID you use [00:44:21 CET] Action: Daemon404 wonders if every damn commit in libav is buggy lately [00:44:39 CET] <cone-559> ffmpeg 03Paul B Mahol 07release/2.8:40ebeee3fc35: avformat/brstm: fix overflow [00:44:40 CET] <cone-559> ffmpeg 03Paul B Mahol 07release/2.8:7b0fb4fdf796: avformat/ipmovie: put video decoding_map_size into packet and use it in decoder [00:44:41 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:667a23a03249: ffmdec: reset packet_end in case of failure [00:44:42 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:e3d7796336c8: vorbisdec: reject channel mapping with less than two channels [00:44:43 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:6ffaf40c02d3: vorbisdec: reject rangebits 0 with non-0 partitions [00:44:44 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:94b9e7caaea8: brstm: make sure an ADPC chunk was read for adpcm_thp [00:44:45 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:247bb203e4e2: brstm: also allocate b->table in read_packet [00:44:46 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:cf99f0dd0fa2: brstm: fix missing closing brace [00:44:47 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:1272b88d0457: dca: fix misaligned access in avpriv_dca_convert_bitstream [00:44:48 CET] <cone-559> ffmpeg 03Hendrik Leppkes 07release/2.8:2cd41c5d5230: Merge commit '8375dc1dd101d51baa430f34c0bcadfa37873896' [00:44:49 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:d7fbd0366005: asfdec_o: only set asf_pkt->data_size after sanity checks [00:44:50 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:407ab167c07c: asfdec_o: reject size > INT64_MAX in asf_read_unknown [00:44:50 CET] <Daemon404> RiCON, s/q->extco2.b_strategy/q->b_strategy/ please [00:44:51 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:e188c267c871: asfdec_o: check avio_skip in asf_read_simple_index [00:44:52 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:782257ba66e0: asfdec_o: prevent overflow causing seekback [00:44:53 CET] <nevcairiel> jya: the guid is in the specification, but http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg_dxva2.c;h=905bf8907cf… [00:44:53 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:4679e543880a: asfdec_o: make sure packet_size is non-zero before seeking [00:44:54 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:93559adfbfd4: asfdec_o: break if EOF is reached after asf_read_packet_header [00:44:55 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.8:d640bc75459d: asfdec_o: check for too small size in asf_read_unknown [00:45:07 CET] <nevcairiel> Daemon404: i told you, koda refactoring needs special attention [00:45:36 CET] <Daemon404> nevcairiel, all the other bugs today were luca bugs though ;) [00:46:07 CET] <nevcairiel> the last patchset moving some global option into codec privates was riddled with bugs [00:46:19 CET] <Daemon404> i guess [00:46:21 CET] <nevcairiel> decoders that didnt have one before were suddenly missing an AVClass [00:46:29 CET] <Daemon404> if (externallib) apply_extra_extra_extra_attention() [00:46:37 CET] <Daemon404> since it probably wasnt even tested [00:46:41 CET] <nevcairiel> parameters were mapped wrong [00:46:55 CET] <nevcairiel> options didnt work because they conflicted with global opitons [00:46:56 CET] <Daemon404> yes i saw that, there is a fix from martin [00:46:59 CET] <nevcairiel> and fun things like that [00:47:08 CET] <Daemon404> RiCON, does this fix it for you? [00:47:17 CET] <jya> nevcairiel: we go through the WMF, not dxva directly. so for h264 we use constants: e.g. MFVideoFormat_H264 / CLSID_CMSH264DecoderMFT [00:47:29 CET] <jya> don't know how that translate to dxva [00:47:41 CET] <nevcairiel> yeah well thats the MFT decoders, the GUIDs we use are for the hardware devices [00:48:18 CET] <nevcairiel> not sure if MS provides a MFT for vp9 [00:48:25 CET] <nevcairiel> maybe they do, they wanted to add support to edge [00:48:32 CET] <nevcairiel> but it would only be available on 10 then of course [00:50:10 CET] <kierank> nevcairiel: how does decoder security work on hardware decoders? [00:50:26 CET] <jya> i wonder what ccontainer microsoft will use for vp9 [00:50:33 CET] <Daemon404> probably webm [00:50:35 CET] <RiCON> Daemon404: "this"? [00:50:35 CET] <jya> they only mentioned supporting vp9, they never talked about webm [00:50:38 CET] <Daemon404> windows 10 has a matroska demuxer [00:50:43 CET] <Daemon404> - if (q->extco2.b_strategy >= 0) [00:50:43 CET] <Daemon404> + if (q->b_strategy >= 0) [00:50:46 CET] <Daemon404> ^ RiCON [00:50:46 CET] <jya> we're betting on vp9 in mp4 [00:51:05 CET] <Daemon404> jya, brb killing self [00:51:20 CET] <kierank> what's wrong with vp9 in mp4? [00:51:39 CET] <Daemon404> same thing thats will be wrong with vp9 in anything [00:51:44 CET] <Daemon404> no ratified or real spec anywhere [00:52:01 CET] <kierank> there is a thing on github [00:52:03 CET] <kierank> from netflix [00:52:05 CET] <nevcairiel> i think i saw someone defining a spec for vp9 in mp4 [00:52:07 CET] <nevcairiel> yeah that [00:52:11 CET] <Daemon404> yes [00:52:12 CET] <Daemon404> netflix [00:52:24 CET] <kierank> can I make fuzzed files that crash hw decoders? [00:52:34 CET] <Daemon404> you can probably make legit files that crash hw decoders [00:52:46 CET] <atomnuker> nevcairiel: ran fate yet? [00:52:53 CET] <kierank> how much practical damage could I cause [00:53:02 CET] <Daemon404> kierank, lockups / bsod [00:53:09 CET] <Daemon404> maybe not bsod [00:53:16 CET] <nevcairiel> depends [00:53:21 CET] <Daemon404> are windows drivers still kenel space [00:53:22 CET] <Daemon404> kernel [00:53:23 CET] <nevcairiel> most will probably just crash the driver [00:53:34 CET] <Daemon404> yeah theyre userpspace now arent they [00:53:39 CET] <kierank> :( [00:53:45 CET] <nevcairiel> atomnuker: stddev: 616.71 PSNR: 40.53 MAXDIFF: 9768 bytes: 1675800/ 1679360 [00:54:45 CET] <Daemon404> jya, will you be attending FOSDEM btw? [00:54:47 CET] <atomnuker> then the fate test is outdated, I get the same values, will push an update [00:55:38 CET] <TD-Linux> jya, their initial press release said WebM/VP9 [00:55:59 CET] <nevcairiel> atomnuker: the failing tests on bsd systems have things like stddev: 568.59 PSNR: 41.23 MAXDIFF: 7868 bytes: 1675800/ 1679360 [00:56:00 CET] <nevcairiel> stddev: |568.59 - 662| >= 72 [00:56:13 CET] <atomnuker> yeah, I know [00:56:28 CET] <nevcairiel> wonder why its so much different there [00:57:47 CET] <jya> TD-Linux: you should tell that to k17e then [00:58:30 CET] <atomnuker> miscompilation? weird float discrepancies? [00:59:03 CET] <cone-559> ffmpeg 03Rostislav Pehlivanov 07master:925f145ace2e: FATE: update AAC encoder PNS test target [00:59:04 CET] <nevcairiel> kierank: would also be careful what you fuzz, only the slice data is passed 1:1 to the hardware, the slice headers and all other bitstream parameters (sps etc) are parsed by ffmpeg, so if those turn out bad, ffmpeg might already block it all :D [00:59:43 CET] <TD-Linux> jya, I think he knows based on prior discussion in #media? [00:59:44 CET] <kierank> I had a lot of obscure interlaced bugs that I found [01:00:13 CET] <nevcairiel> atomnuker: speaking of the target, i always wondered, is lower or higher cmp_target "better"? :) [01:00:14 CET] <jya> from discussion with him, he appears convinced that MS hasn't made an announcement about webm, just VP9 [01:00:34 CET] <Daemon404> technically they alreadt support webm [01:00:35 CET] <Daemon404> via mkv [01:00:49 CET] <atomnuker> nevcairiel: stddev -> standard deviation -> lower ~= better [01:01:25 CET] <nevcairiel> jya: https://dev.windows.com/en-us/microsoft-edge/platform/status/webmcontainer?… .. if worth anything, it says "in development" [01:02:00 CET] <Daemon404> just 10 more years until edge has a reasonable share [01:02:19 CET] <nevcairiel> its a decent basis for a browser though, just needs some more UX work [01:03:24 CET] <Daemon404> at least as far as MSE is concerned, IE11 and Edge have been pretty well the most spec compliant [01:03:27 CET] <Daemon404> (unlike chrome) [01:04:21 CET] <jya> Daemon404: edge certainly, IE11 not from my finding [01:04:42 CET] <jya> I take offence though, because I think FF since 42 has the most compliant implementation [01:05:11 CET] <jya> and in 44, other than text track, it's all *exactly* per spec [01:06:30 CET] <jya> edge implementation of sequence mode is bad. But I don't know anyone doing it properly (except FF of course) nor anyone using it :) [01:06:44 CET] <jya> (I wrote the MSE stack found in 42 and later) [01:06:55 CET] <Daemon404> jya, for a long time, IE11 was the only one to support MSE fragments that dont start with keyframes [01:06:58 CET] <Daemon404> (this is allowed) [01:07:03 CET] <Daemon404> chrome still doesnt [01:07:08 CET] <Daemon404> havent tested ff [01:07:16 CET] <Daemon404> since it lacked mse entirely when i originally tested [01:07:58 CET] <jya> well, mse in FF has been there a long time, was just only allowed for youtube [01:08:24 CET] <Daemon404> i know [01:08:29 CET] <RiCON> Daemon404: sorry for the delay, had run make clean [01:08:31 CET] <RiCON> seems to fix it [01:08:36 CET] <Daemon404> RiCON, thought so [01:08:45 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:02bd02da5f90: qsvenc: Fix b_strategy typo [01:08:56 CET] <jya> fragments not starting with keyframes are fine (obviously all frames are dropped until the first keyframe) [01:09:38 CET] <jya> I can't think of a day where we don't get a report that FF MSE is broken: look it plays in Chrome. and it's totally rubbish content [01:09:53 CET] <Daemon404> jya, in this case ff will play it then [01:09:58 CET] <Daemon404> and chrome will just refuse [01:09:58 CET] <jya> last time, they had prefixed every fragment with ftyp box [01:10:33 CET] <jya> Daemon404: that's sounds weird, we've had stuff where none of the frames in the container were marked keyframes [01:10:47 CET] <Daemon404> it's a known bug in chrome [01:10:49 CET] <jya> obbviously we just ended with an empty source buffer, but chrome played them nicely [01:10:50 CET] <Daemon404> they fixed it today-ish [01:10:53 CET] <Daemon404> but it broke netflix [01:10:55 CET] <Daemon404> so its reverted now. [01:11:23 CET] <Daemon404> jya, you will love what GPAC does [01:11:32 CET] <Daemon404> they make every frame a separate fragment [01:11:34 CET] <Daemon404> all marked as keyframes [01:11:37 CET] <Daemon404> even if they arent [01:11:44 CET] <Daemon404> for 'compatability' [01:12:00 CET] <jya> what gives me the biggest hassle is that the webref tests are based on chrome's own internal test. they append fragments that starts at 0.095s and their test assume that the buffered range will start at 0 [01:12:52 CET] <jya> they shift every timestamp to make it start at 0, but they don't shift all tracks accordingly. so if you have a video where the timestamp start at 0..095 and audio at 0, you have A/V sync off by that much [01:13:13 CET] <Daemon404> where does that timestamp come from? [01:13:19 CET] <jya> the container [01:13:30 CET] <Daemon404> yes but before or after edit list application? [01:13:34 CET] <Daemon404> baseMediaTime must start at 0 [01:13:42 CET] <Daemon404> its required [01:14:01 CET] <jya> I've seen those GPAC encoding, we don't handle them nicely, because we process things by block of frames [01:14:12 CET] <kierank> lol gpac [01:14:15 CET] <jya> so we end up with block of 1 frame, that's a lot of reset/start [01:14:24 CET] <Daemon404> there's no possible wya to handle it well [01:14:26 CET] <jya> Daemon404: that's after edts [01:14:30 CET] <Daemon404> jya, ok [01:14:45 CET] <jya> let me find you an example. (I lodged a bug with w3c) [01:16:11 CET] <Daemon404> i should really settle down and get of irc soon [01:16:15 CET] <Daemon404> or i wont sleep [01:16:18 CET] <Daemon404> off* [01:16:31 CET] Action: kierank writes FOSDEM presentation [01:17:07 CET] <Daemon404> 20 slides of: WHATS THE DURATION OF THE LAST FRAME, ANTON?! [01:17:46 CET] <kierank> he wasn't there for that [01:18:15 CET] <Daemon404> that makes me sad [01:22:44 CET] <jya> Daemon404: https://github.com/w3c/web-platform-tests/tree/master/media-source [01:22:46 CET] <jya> https://github.com/w3c/web-platform-tests/blob/master/media-source/mp4/test… is one [01:22:59 CET] <jya> starts at 0.083333 [01:24:19 CET] <jya> this test: https://raw.githubusercontent.com/w3c/web-platform-tests/master/media-sourc… expects data added to be between [0, 2.023] [01:24:30 CET] <Daemon404> github dead [01:24:49 CET] <Daemon404> everything is 503 [01:25:35 CET] <Daemon404> their status page is dead [01:25:37 CET] <Daemon404> nice. [01:25:45 CET] <Compn> why keep using mp4 stupid non streamable format :\ [01:26:34 CET] <Compn> damn apple mp4 pushers [01:27:14 CET] <TD-Linux> well not quite. they pushed HLS with MPEG-TS (which would actually be worse due to royalties) [01:27:53 CET] <Compn> yes, apple is stupid too [01:29:22 CET] <TD-Linux> we've had a free streamable container since 2001. it's called ogg :^) [01:29:53 CET] <Compn> you shut your mouth [01:30:24 CET] <kierank> meh most of the mpegts patents don't apply [01:30:36 CET] <kierank> they are for things like PCR which you guys don't even use [01:30:44 CET] <kierank> or other obscure stuff [01:34:30 CET] <jya> kierank: you'll pay the legal fees to argue that point ? [01:34:52 CET] <kierank> well don't send pcr and you avoid the patent on pcr [01:35:12 CET] <kierank> they stopped taking our money now in the uk [01:35:15 CET] <kierank> all the uk patents expired [01:35:41 CET] <jya> our solution to support HLS has been to help with stuff like hls.js , and HLS -> MSE conversion [01:35:43 CET] <jya> works well [01:36:20 CET] <jya> mpeg-ts can work with MSE, but we don't support it. My manager wants to limit the amount of container we support [01:36:27 CET] <jya> he even wants to drop ogg [01:44:51 CET] <TD-Linux> kierank, yeah it's much better now, though people wanted MSE a lot sooner than 2016. [01:48:22 CET] <Daemon404> jya, i looked at that sample [01:48:54 CET] <jya> and? [01:49:22 CET] <Daemon404> im not surprised [01:49:40 CET] <Daemon404> baseMediaTime is 0, but the sidx's earliest_presentation_time is 1024 [01:49:45 CET] <Daemon404> chrome doesnt even read sidx boxes [01:49:48 CET] <Daemon404> last i checked. [01:50:04 CET] <jya> sidx are to be ignored per spec [01:50:36 CET] <jya> "Valid top-level boxes such as pdin, free, and sidx are allowed to appear before the moov box. These boxes must be accepted and ignored by the user agent and are not considered part of the initialization segment in this specification." [01:51:02 CET] <Daemon404> i dont see any elst at all in that file [01:51:20 CET] <jya> not surprising, stagefright doesn't support them properly [01:51:33 CET] <Daemon404> im wondering where the nonzero start time comes from [01:51:44 CET] <jya> in MSE, the specs are clearly based on the start and end time of each frames found in the segment [01:52:17 CET] <Daemon404> cts is 1024 i suppose [01:52:21 CET] <jya> ffprobe gives me the same timestamps as what our demuxer give [01:52:35 CET] <Daemon404> yes the cts is 1024 [01:52:41 CET] <Daemon404> i forgot basemediatime is based off dts [01:52:42 CET] <Daemon404> for a sec [01:53:42 CET] <Daemon404> looks correct [01:55:57 CET] <Daemon404> i think this technically should have an edts to account for non-zero cts for the first sample [01:56:01 CET] <Daemon404> but i doubt thats required. [01:56:13 CET] <Daemon404> oh well. 1 am. i should sleep. [02:03:49 CET] <jya> nevcairiel: unless there's a newer version of it, VP9 doesn't appear to be defined for MFT https://msdn.microsoft.com/en-us/library/windows/desktop/aa370819%28v=vs.85… [02:25:46 CET] <cone-559> ffmpeg 03Paul B Mahol 07release/2.7:0c03d860f49a: avformat/ipmovie: put video decoding_map_size into packet and use it in decoder [02:25:47 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.7:a21ec4e1ee54: ffmdec: reset packet_end in case of failure [02:25:48 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.7:00a0c0fd75f2: vorbisdec: reject channel mapping with less than two channels [02:25:49 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.7:6fe77207ed3b: vorbisdec: reject rangebits 0 with non-0 partitions [02:25:50 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.7:496c02a065bd: brstm: make sure an ADPC chunk was read for adpcm_thp [02:25:51 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.7:269a522aeccf: brstm: also allocate b->table in read_packet [02:25:52 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.7:f106232e9405: brstm: fix missing closing brace [02:25:53 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.7:41157f6bfff3: dca: fix misaligned access in avpriv_dca_convert_bitstream [02:26:28 CET] <cone-559> ffmpeg 03Paul B Mahol 07release/2.6:eadf932867fc: avformat/ipmovie: put video decoding_map_size into packet and use it in decoder [02:26:29 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.6:eaba40842183: ffmdec: reset packet_end in case of failure [02:26:30 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.6:9dd768dc1e7e: vorbisdec: reject channel mapping with less than two channels [02:26:31 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.6:b244e67f9cc6: vorbisdec: reject rangebits 0 with non-0 partitions [02:26:32 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.6:20d4c087ed8c: brstm: make sure an ADPC chunk was read for adpcm_thp [02:26:32 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.6:95e52303da7e: brstm: also allocate b->table in read_packet [02:26:34 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.6:e577e712a8a2: brstm: fix missing closing brace [02:26:35 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.6:1d8a6a46a303: dca: fix misaligned access in avpriv_dca_convert_bitstream [02:27:26 CET] <cone-559> ffmpeg 03Clément BSsch 07release/2.5:1a65265131cd: avcodec/samidec: make sure to properly restore parsing context after a tag [02:27:27 CET] <cone-559> ffmpeg 03Paul B Mahol 07release/2.5:bf446993145a: avformat/ipmovie: put video decoding_map_size into packet and use it in decoder [02:27:28 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.5:3b535bbf8857: ffmdec: reset packet_end in case of failure [02:27:29 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.5:b6fb6ccda40a: vorbisdec: reject channel mapping with less than two channels [02:27:30 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.5:641a01015727: vorbisdec: reject rangebits 0 with non-0 partitions [02:27:31 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.5:a90a7594a81e: brstm: make sure an ADPC chunk was read for adpcm_thp [02:27:32 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.5:cdedd71a7e13: brstm: also allocate b->table in read_packet [02:27:33 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.5:f2fd5b9eb267: brstm: fix missing closing brace [02:27:34 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.5:873a0dfa26df: dca: fix misaligned access in avpriv_dca_convert_bitstream [02:28:10 CET] <cone-559> ffmpeg 03Clément BSsch 07release/2.4:2b2943e1ef80: avcodec/samidec: make sure to properly restore parsing context after a tag [02:28:11 CET] <cone-559> ffmpeg 03Paul B Mahol 07release/2.4:a2667c60ecc3: avformat/ipmovie: put video decoding_map_size into packet and use it in decoder [02:28:12 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.4:46fcc2ba55df: mjpegdec: extend check for incompatible values of s->rgb and s->ls [02:28:13 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.4:33ad09205a9f: ffmdec: reset packet_end in case of failure [02:28:14 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.4:7b6f04850610: vorbisdec: reject channel mapping with less than two channels [02:28:15 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.4:bc4332b3fc49: vorbisdec: reject rangebits 0 with non-0 partitions [02:28:16 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.4:d5b1ea8c7aba: brstm: make sure an ADPC chunk was read for adpcm_thp [02:28:17 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.4:ab13ba2ae832: brstm: also allocate b->table in read_packet [02:28:18 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.4:368a1803ff84: brstm: fix missing closing brace [02:28:19 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07release/2.4:859a348e44d7: dca: fix misaligned access in avpriv_dca_convert_bitstream [02:47:45 CET] <jya> Daemon404: I've created https://bugzilla.mozilla.org/show_bug.cgi?id=1243608, I'l work on it [03:07:56 CET] <llogan> that page doesn't render for me correctly in firefox [03:08:35 CET] <llogan> even firefox hates bugzilla [04:15:55 CET] <cone-559> ffmpeg 03Michael Niedermayer 07master:e0b187e7dada: avcodec/h264: Fix memleak in case of ff_h264_decode_extradata() failure [04:42:41 CET] <Timothy_Gu> Daemon404, wm4: fyi the numbers in that Chinese aren't characters. they are the ID of a IM service developed by tencent (one of the biggest chinese computer companies) [04:43:02 CET] <Timothy_Gu> as to how one can remember it, i have no idea [04:43:22 CET] <Timothy_Gu> zjh is the initials of the romanization of that guy's name [05:19:09 CET] <rcombs> Timothy_Gu: often sequences of digits pronounced individually in Chinese (or Japanese) sound like a word or phrase [05:19:18 CET] <rcombs> which can make for easy mnemonics sometimes [05:19:37 CET] <Timothy_Gu> rcombs: sometimes I guess [05:19:51 CET] <Timothy_Gu> but for that specific case it's randomly (or sequentially?) generated [05:20:26 CET] Action: rcombs shrugs [05:20:38 CET] <rcombs> maybe chunking, like how you remember phone numbers [05:21:58 CET] <Timothy_Gu> meh. but I guess when you use the number a lot you remember it (as with credit card, etc.) [08:37:39 CET] <wm4> nevcairiel: daily nagging when you will push your dxva hevc main10 patch [09:36:41 CET] <cone-231> ffmpeg 03Matthieu Bouron 07master:27f1ea5097da: lavc/mjpegdec: use ptrdiff_t instead of ssize_t [10:37:44 CET] <durandal_170> can I get review for dvaudio parser, its trivial [10:38:12 CET] <durandal_170> its needed to set packet durations [13:08:10 CET] <cone-231> ffmpeg 03Paul B Mahol 07master:2edd47582b4d: avcodec: add dvaudio parser [13:24:26 CET] <superware> I'm running "ffplay.exe udp://224.0.18.0:40003" with the ethernet cable disconnected (Windows 7), but when I connect the cable to the NIC the video doesn't play. It plays only if I execute ffplay after the cable is already connected, any ideas? [13:26:27 CET] <Compn> superware : maybe there are no retries? whats it do just sit there? maybe windows throws it an error no_addy_found hmm [13:28:38 CET] <superware> Compn: I've also tried ffmpeg libav by retrying avformat_open_input every 20 seconds, but it starts playing only once I restart the process. [13:29:31 CET] <superware> it seems that if the process was launched when the interface was "down" then it will not be able to receive the multicast even after the interface it up... sounds possible? [13:36:44 CET] <Compn> superware : try ffplay -timeout 400 ? [13:36:56 CET] <Compn> http://ffmpeg.org/pipermail/ffmpeg-devel/2012-August/130236.html [13:36:59 CET] <Compn> might fix things... [13:40:17 CET] <superware> shouldn't avformat_open_input handle that? I'm trying it every 20 seconds [13:40:44 CET] <Compn> udp has no timeout by default? maybe ? [13:40:46 CET] <superware> the only thing that runs once is avformat_network_init [13:40:49 CET] <Compn> i'm not sure, wait for someone that knows.. [13:41:15 CET] <Compn> did you check what is returned by network_init ? [13:42:04 CET] <superware> when there's no active interface? no... [13:42:32 CET] <superware> but on the other hand the wireless interface is active... [13:45:28 CET] <Compn> you're at the mercy of windows network switching then. :P [13:45:49 CET] <Compn> win7 is pretty outdated now :P [13:45:59 CET] <superware> but why is this related to the process itself? [13:46:59 CET] <Compn> try disable the network interface and see if it works over the wireless connection [13:47:06 CET] <Compn> instead of disconnecting the network interface [13:47:31 CET] <Compn> er disable the network adapter for the unplugged cable that is [13:48:55 CET] <Compn> i'm curious if there will be a difference [13:49:01 CET] <Compn> i think there will be [13:49:28 CET] <superware> the wireless is meaningless to what I see with the multicast video [14:52:08 CET] <Daemon404> jya, quite a lot of stuff happened on that bug whilst i slept [14:53:05 CET] <jya> Daemon404: my recollection of things was entirely incorrect. What I thought about was only the case for MSE (where indeed buffered range and seekable are per frame demuxed, regardless of what the metadata contain [14:53:25 CET] <Daemon404> that explains thingd ;P [14:53:28 CET] <Daemon404> things, even [14:54:17 CET] <jya> those progressive mp4 would have worked in Firefox 40 I'm guessing, it utlitmately a regression due to some work around put in place shit video encoding done by one of our device [14:54:40 CET] <jya> but while looking into it, I guess I got overzealous [14:55:31 CET] <Daemon404> said every engineer ever [14:55:38 CET] <Daemon404> ;P [14:55:44 CET] <jya> fixing the seeking issue was very straight forward (I reverted the change).. the following changes are about speeding up the seek. We always used to seek the audio to whatever video was seeked to [14:56:11 CET] <Daemon404> as in packet location or timestamp? [14:56:56 CET] <jya> so if you were seeking at 1 minute, it would have seeked the video at 0s (pts) and then seek audio to 0, then decode every single audio frame until it reached 1 minute and drop them if it was prior the seek target) [14:57:05 CET] <Daemon404> ah. [14:57:16 CET] <jya> so seek were particularly slow in that video [14:57:32 CET] <jya> the other good news is now I'm an expert on Lupus [14:57:56 CET] <Daemon404> ha. [14:58:38 CET] <jya> i don't know if that change will be approved for uplifting... that it's a regression helps. release management is awlays very keen to fix regression. [14:59:02 CET] <jya> that it had regressed so long ago will put it on the low priority list though [14:59:23 CET] <Daemon404> also it's not MSE [14:59:27 CET] <Daemon404> so not Hip & Cool 2016 [14:59:59 CET] <jya> one way to put it on top of the queue is find me a video like this on Youtube :) [15:00:22 CET] <nevcairiel> youtube probably encodes carefully enough to not produce those [15:00:23 CET] <Daemon404> that makes me sad [15:00:25 CET] <jya> what do you guys do currently for those videos? do you serve FF flash? [15:00:41 CET] <Daemon404> like 90% of bugs/problems we find are results of "well it works for youtube" [15:00:51 CET] <Daemon404> which is annoying as hell [15:00:53 CET] <jya> Daemon404: unfortunately, youtube is so prevalent today, that it's kind of the only thing that matters :( [15:01:08 CET] <Daemon404> jya, its more annoying when it's chrome [15:01:13 CET] <jya> don't worry, I hear that every day with "it works with chrome" [15:01:17 CET] <Daemon404> because youtube is their "customer" [15:01:22 CET] <Daemon404> same for vp9 [15:01:36 CET] <Daemon404> thats why vp9 has utter shit ratecontrol [15:01:40 CET] <Daemon404> because youtube rolls their own [15:01:52 CET] <Daemon404> /ran [15:01:53 CET] <Daemon404> t [15:02:04 CET] <jya> dailymotion now serves MSE exclusively on Firefox (they used http live streamer, and use their hls.js interface) [15:02:17 CET] <jya> they used to have heaps of those type of video [15:02:41 CET] <BtbN> hls.js works even better than dash.js now... it's sad [15:02:44 CET] <Daemon404> we have to keep progressive around for some crappy plastic devices to consume [15:02:53 CET] <Daemon404> but firefox should be all mse soon. [15:03:24 CET] <Daemon404> BtbN, dash.js is utter awfulness [15:03:27 CET] <Daemon404> so it's unsurprising [15:03:34 CET] <jya> BtbN: main reason for dailymotion to use hls.js (which they kindly made open), is so that they only have to encode once. they used the lowest common denominator [15:03:50 CET] <BtbN> Twitch is also rolling their own hls.js like thing [15:03:52 CET] <Daemon404> jya, we only encode once too =p [15:04:04 CET] <Daemon404> it's segmented/cached at cdn level [15:04:07 CET] <BtbN> Twitch is not usualy encoding at all though [15:04:17 CET] <jya> never found dash.js to be that bad.. it's the content that is used with that is often crap [15:04:33 CET] <nevcairiel> BtbN: huh, twitch seems to encode everything to various quality levels [15:04:35 CET] <BtbN> They were just too... lazy? to switch their CDN from HLS to DASH [15:04:43 CET] <BtbN> Only for Partnered streams [15:04:56 CET] <BtbN> And the Source-Quality level is still just a direct passthrough [15:06:13 CET] <jya> hls.js has just fixed something that caused issue on mac with some streams (noticeable if you watch nasa tv like all respectable geek should) [15:06:47 CET] <Daemon404> ive never used hls.js, but ive written my own [15:06:48 CET] <jya> that's one problem solved that still puzzles me. it decoded just fine with ffmpeg, but Apple VT used to out half green content [15:07:01 CET] <Daemon404> did the bother to handle hls streams that dont have keyframes at seg boundaries [15:07:05 CET] <Daemon404> liek akamai produces [15:07:16 CET] <Daemon404> because while you can transmux those as-is, and it is valid mse [15:07:18 CET] <BtbN> works fine in hls.js [15:07:19 CET] <Daemon404> chrome wont play them. [15:07:39 CET] <Daemon404> BtbN, it must be doing clever things then [15:07:45 CET] <BtbN> Twitch does that a lot, and it just works for me. [15:07:49 CET] <Daemon404> like joining bits of segs during nal parsing [15:07:58 CET] <jya> Daemon404: for chrome defense. Just 1.5 years ago, segments *had to* start with a keyframe in the MSE spec [15:08:08 CET] <jya> it was only relaxed to facilitate conversion from HLS [15:08:32 CET] <Daemon404> i know it changed [15:08:40 CET] <BtbN> You can stream with a 30 second gop length, and it will still make 4 second segments out of it [15:08:40 CET] <BtbN> joining the stream might take a while, but it will eventualy play it [15:08:44 CET] <Daemon404> im just disgruntled at chrome :P [15:08:58 CET] <Daemon404> it took them ike 2 years and months of convincing to get them to fix their ycbcr to rgb conversion [15:08:59 CET] <BtbN> I tested that with chrome using hls.js and the official twitch HTML5 player. Both work [15:10:24 CET] <jya> twitch has finally moved to 100% html5? wasn't it like just flash with a html5 overlay not long ago? [15:10:36 CET] <Daemon404> last time i opened twitch in firefox [15:10:38 CET] <Daemon404> it was just a black screen [15:10:39 CET] <BtbN> it still hasn't(for good reasons, the HTML5 player is still wonky) [15:10:41 CET] <Daemon404> wouldnt play at all [15:10:46 CET] <BtbN> But there is a HTML5 player if you know the URL for it [15:11:08 CET] <Daemon404> oic [15:11:08 CET] Action: jya blames flash for black screen [15:11:28 CET] <BtbN> Also, I wrote a userscript that replaces the player with a plain hls.js video element [15:11:45 CET] <jya> the flash player is actually a HLS one ? [15:11:55 CET] <Daemon404> its fairly common [15:11:56 CET] <BtbN> Yes, the use exclusively HLS [15:15:17 CET] <BtbN> http://player.twitch.tv/?html5&channel=rocketbeanstv is their HTML5 player [15:17:22 CET] <jya> Daemon404: had any issue with FF's MSE stack? [15:17:58 CET] <jya> BtbN: MSE, nice.. [15:18:00 CET] <Daemon404> not yet, i think [15:18:11 CET] <Daemon404> it has the least testing though [15:18:18 CET] <Daemon404> since stable only recently got MSE for non-youtube [15:18:26 CET] <BtbN> They finaly seem to have it working propperly [15:18:29 CET] <BtbN> only took them like 5 years [15:18:46 CET] <Daemon404> BtbN, they = jya [15:19:01 CET] <Daemon404> or do you mean twicth [15:19:10 CET] <jya> I think he means twitch :) [15:19:14 CET] <Daemon404> ah [15:19:23 CET] <BtbN> The last time I tested it it barfed on itself within minutes [15:19:44 CET] <BtbN> and while it played, it had several seconds of audio desync [15:20:22 CET] <jya> we had issues with the dash.js and live stream, we didn't fire canplaythrough which they were waiting on to start playing. I don't think it made it in 44. only 45 [15:20:25 CET] <BtbN> I still wonder why they didn't just start using DASH, would have been less painfull [15:20:49 CET] <BtbN> They are remuxing from rtmp/flv input anyway [15:20:57 CET] <jya> I'm still trying to get my head around the dash format. How could anyone ever come up with something so complicated [15:21:17 CET] <BtbN> Yeah, DASH seems like a solution to a bunch of non-existend problems [15:21:23 CET] <BtbN> "Let's throw XML at it" [15:21:42 CET] <jya> I'm so happy that we only have to do MSE (we had a native DASH player for a while) [15:22:04 CET] <BtbN> A native HLS player would be nice, but for some reason mpeg-ts is bad [15:22:29 CET] <jya> LOL, watching the twitch live stream, I was impressed on how realistic some of the screams were. [15:22:50 CET] <jya> but it's my 1yo who woke up screaming.. wonder how long he's been up [15:23:09 CET] <cone-231> ffmpeg 03Vittorio Giovara 07master:84c4714f397c: lavc: Move brd_scale to codec private options [15:23:10 CET] <cone-231> ffmpeg 03Derek Buitenhuis 07master:4f32ccb61800: Merge commit '84c4714f397c9c50eb9d49008cc1c08385f68f31' [15:23:30 CET] <jya> right 1:20AM, my turn to be tired... good night [15:23:46 CET] <Daemon404> cya [15:24:31 CET] <Daemon404> i see there's some fate tests.. crud [15:24:53 CET] <Daemon404> actually it's fine... [15:29:53 CET] <Daemon404> huh [15:29:55 CET] <Daemon404> kierank, [15:29:59 CET] <Daemon404> tests/ref/fate/api-mjpeg-codec-param <-- exists [15:30:05 CET] <Daemon404> daemon404@bbvm:~/dev/f/ffmpeg$ make fate-api-mjpeg-codec-param [15:30:05 CET] <Daemon404> make: Nothing to be done for 'fate-api-mjpeg-codec-param'. [15:30:11 CET] <Daemon404> png works fine [15:30:36 CET] <Daemon404> oh wut... if it runs once, it never runs again [15:30:39 CET] <Daemon404> that doesnt seem right. [16:08:32 CET] <nevcairiel> michaelni: some of your fate systems seem to be out of space, x86_64-debian-asan-144800, ia64-debian-qemu-gcc-4.4-shared and some more [16:09:28 CET] <Daemon404> things that such about changing avcodec.h -> ccache wont work [16:09:45 CET] <nevcairiel> i never use ccache, dont trust it =p [16:09:53 CET] <nevcairiel> bought a 6 core cpu instead [16:09:56 CET] <Daemon404> i have no reason to mistrust it [16:10:05 CET] <Daemon404> i used it extensively in a past job [16:10:47 CET] <Daemon404> nevcairiel, i dont suppose you are coming to FOSDEM [16:11:31 CET] <nevcairiel> nah [16:11:42 CET] <Daemon404> didnt think so [16:11:53 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:8008a029ab40: avcodec/aacenc: Check both channels for finiteness [16:11:54 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:034edcec6d83: swscale/swscale_unscaled: Fix odd height inputs for bayer_to_rgb24_wrapper() [16:11:55 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:6eb76b34ca24: swscale/swscale_unscaled: Fix odd height inputs for bayer_to_yv12_wrapper() [16:11:56 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:f121ed611ef3: swscale/x86/rgb2rgb_template: Fix planar2x() for short width [16:11:57 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:6897859b5acf: swscale/swscale: Add some sanity checks for srcSlice* parameters [16:11:58 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:61850f1c8423: avcodec/tiff: Check subsample & rps values more completely [16:11:59 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:aa833e1a60c3: avcodec/put_bits: Assert buf_ptr in flush_put_bits() [16:12:00 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:828d85bf8693: avcodec/gif: Fix lzw buffer size [16:12:01 CET] <cone-231> ffmpeg 03Derek Buitenhuis 07release/2.8:b9551e71bf33: mov: Add an option to toggle dref opening [16:12:02 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:c6f6829ce6e0: avcodec/ass_split: Fix null pointer dereference in ff_ass_style_get() [16:12:03 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:d64ff3a6a961: avformat/img2dec: do not interpret the filename by default if a IO context has been opened [16:12:04 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:642c54270be6: avformat/avio: Limit url option parsing to the documented cases [16:12:05 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:8ed4b446571a: avformat/img2dec: Use AVOpenCallback [16:12:06 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:f77b656b6eaf: avcodec/mpeg12enc: Move high resolution thread check to before initializing threads [16:12:07 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:00393c56da97: avcodec/wmaenc: Check ff_wma_init() for failure [16:12:08 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:971f47f2ebff: avformat/avformat: Replace some references to filenames by urls [16:12:09 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:85cfcb87ff9b: avcodec/mpegvideo_enc: Check for integer overflow in ff_mpv_reallocate_putbitbuffer() [16:12:10 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:98199983420b: avcodec/mjpegdec: Check for end for both bytes in unescaping [16:12:11 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:e0d53cbeef7c: doc/demuxers: Document enable_drefs and use_absolute_path [16:12:12 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:cb88f428b32f: avformat/concat: Check protocol prefix [16:12:13 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:736e42bc33ec: avformat/libquvi: Set default demuxer and protocol limitations [16:12:14 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:b432d883e623: avformat: Document urls a bit [16:12:15 CET] <cone-231> ffmpeg 03Paul B Mahol 07release/2.8:0dc379cfa66d: avcodec/flacenc: fix calculation of bits required in case of custom sample rate [16:12:16 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:6fec0dbd2e15: avutil/opt: check for and handle errors in av_opt_set_dict2() [16:12:17 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:b15ae71305b2: avcodec/jpeg2000dec: More completely check cdef [16:12:20 CET] <Cloudef> wow [16:14:33 CET] <michaelni> my ccache says its 6gb .ccache is 34mb large great [16:14:53 CET] <Daemon404> lolwut [16:15:09 CET] Action: michaelni rm -r .ccache [16:15:27 CET] <ubitux> mmh... we can't send back a user arg in the log callback? [16:16:10 CET] <michaelni> should fix the out of diskspace issue [16:17:13 CET] <cone-231> ffmpeg 03Vittorio Giovara 07master:0ac9f33a9e69: lavc: Move frame_skip_* to codec private options [16:17:15 CET] <cone-231> ffmpeg 03Derek Buitenhuis 07master:13be46c08e59: Merge commit '0ac9f33a9e69c64eee592791be3c5441a6a3d6b7' [16:23:21 CET] <cone-231> ffmpeg 03Vittorio Giovara 07master:5764d3817366: lavc: Move chromaoffset to codec private options [16:23:22 CET] <cone-231> ffmpeg 03Derek Buitenhuis 07master:7c6e86c0cec1: Merge commit '5764d38173661c29d954711dd5abfddf709e9ba4' [16:36:39 CET] <cone-231> ffmpeg 03Vittorio Giovara 07master:7c79587d7407: lavc: Move scenechange_threshold to codec private options [16:36:40 CET] <cone-231> ffmpeg 03Derek Buitenhuis 07master:30c1bdb87ce3: Merge commit '7c79587d7407dab4b9445d66b5f111fe657c8c4d' [16:36:41 CET] <cone-231> ffmpeg 03Derek Buitenhuis 07master:e8c5d5f42960: snow: Move scenechange_threshold to a private option [16:48:36 CET] <cone-231> ffmpeg 03Michael Niedermayer 07release/2.8:af21d609a0dd: Update for 2.8.6 [17:27:21 CET] <cone-231> ffmpeg 03wm4 07master:0badf4564a90: configure: fix mmal build dependencies [17:27:23 CET] <cone-231> ffmpeg 03wm4 07master:d27a12cb0982: mmaldec: print the MMAL format FourCC automatically [17:27:24 CET] <cone-231> ffmpeg 03wm4 07master:7b1b53f3a456: mmaldec: support MPEG-4 [17:27:25 CET] <cone-231> ffmpeg 03wm4 07master:14a90c9ef09a: mmaldec: limit internal buffering [17:36:54 CET] <cone-231> ffmpeg 03James Almer 07master:c79252897096: x86/imdct36: use extractps inside the STORE macro [17:42:50 CET] <cone-231> ffmpeg 03Vittorio Giovara 07master:1482aff20485: lavc: Move noise_reduction to codec private options [17:42:51 CET] <cone-231> ffmpeg 03Derek Buitenhuis 07master:b986a4625d0e: Merge commit '1482aff2048511b821ff9feac19426113cc641a2' [18:07:12 CET] <Daemon404> ff_frame_thread_encoder_init makes me want to cry blood [18:07:20 CET] <Daemon404> look at those per codec hacks [18:09:57 CET] <wm4> wow [18:12:23 CET] <Daemon404> at least i see how to fix it here [18:15:44 CET] <michaelni> x264 sc_threshold is broken, iam testing a fix ATM [18:16:22 CET] <Daemon404> michaelni, there is a libav on libav-devel [18:16:26 CET] <Daemon404> i noticed it earlier [18:16:37 CET] <Daemon404> for more than just that [18:17:54 CET] <michaelni> Daemon404, if fixes exist can you cherry pick them or something ? [18:18:30 CET] <Daemon404> theyre not pushed yet [18:18:36 CET] <Daemon404> or reviewed [18:18:40 CET] <Daemon404> but let me look [18:19:08 CET] <michaelni> for sc_threshold i can push mine, it seems working [18:19:41 CET] <Daemon404> go ahead [18:19:48 CET] <Daemon404> i can just skip bits later [18:20:02 CET] <cone-231> ffmpeg 03Vittorio Giovara 07master:12b497692232: lavc: Move mpeg_quant to codec private options [18:20:03 CET] <cone-231> ffmpeg 03Vittorio Giovara 07master:96c373c7704a: lavc: Move context_model to codec private options [18:20:04 CET] <cone-231> ffmpeg 03Derek Buitenhuis 07master:0e3e3656d31a: Merge commit '12b49769223234673db1003d9c43e7483ceb0282' [18:20:04 CET] <cone-231> ffmpeg 03Derek Buitenhuis 07master:5b0d4c247a3c: Merge commit '96c373c7704aeb1cc1d2c275fbb5d71777665589' [18:20:06 CET] <cone-231> ffmpeg 03Derek Buitenhuis 07master:1a2d6055beed: avcodec/frame_thread_encoder: Check the private option for huffy's context modelling [18:20:46 CET] <nevcairiel> huffy? How cute :p [18:21:49 CET] <Daemon404> lol [18:29:53 CET] <cone-231> ffmpeg 03Michael Niedermayer 07master:cb06be6136dd: avcodec/libx264: Fix sc_threshold after 30c1bdb87ce336f2b9957769e30a10d72f93d372 [18:31:18 CET] <Daemon404> yes that looks right [18:41:53 CET] <Daemon404> that src folder is annoying [18:43:20 CET] <michaelni> should i push vittorios x264 fix ? or wait ? [18:43:34 CET] <michaelni> dont want to break some in process merge [18:43:34 CET] <Daemon404> i dont have an opinion there [18:43:44 CET] <michaelni> proGress [18:43:46 CET] <Daemon404> im not merging right now. im thinking [18:43:50 CET] <michaelni> ok [18:44:06 CET] <Daemon404> the next commit moves timecode_frame_start to a mpeg12enc private option [18:44:22 CET] <Daemon404> but in ffmpeg it was repurpose to also be a decoder field [18:44:27 CET] <Daemon404> :/ [18:44:52 CET] <Daemon404> the right fix is what? side data? [18:44:55 CET] Action: Daemon404 groan [18:45:38 CET] <wm4> probably skip the change [18:45:57 CET] <Daemon404> no, i think it should be fixed [18:46:03 CET] <Daemon404> it's a field in avctx for a single codec. [18:46:10 CET] <Daemon404> that's not right [18:46:21 CET] <cone-231> ffmpeg 03Vittorio Giovara 07master:b340bd8a58c3: libx264: Make sure to preserve default option values [18:48:06 CET] <wm4> I mean it can be fixed after that [18:48:11 CET] <wm4> instead of messing it into the merge [18:48:59 CET] <Daemon404> i wouldnt include it in the merge [18:49:10 CET] <Daemon404> and IME "fix it later" ends up as never [18:49:38 CET] <Daemon404> wm4, the merge also doesnt remove it [18:49:42 CET] <Daemon404> it just deprecates [18:57:49 CET] <wm4> ok [18:58:05 CET] <wm4> then you don't really have to care [18:58:17 CET] <Daemon404> g 31 [21:00:33 CET] <Daemon404> g 42 [21:24:00 CET] <ac_slater> hey guys, in an libavcodec codec, how can I get the input format? ie - I want to test if my input is the "Null" codec [21:24:49 CET] <wm4> you can't and you shouldn't need to know [21:37:37 CET] <cone-231> ffmpeg 03Marton Balint 07master:1036a1b8a31d: lavf/segment: add support for specifying clock time offset [21:37:39 CET] <cone-231> ffmpeg 03Marton Balint 07master:369a6a6ed450: lavf/segment: add new option segment_clocktime_wrap_duration [21:40:06 CET] <wm4> does anyone have one of those mpeg 4 files that fail with hw decoding? [21:40:18 CET] <wm4> AFAIK they use some form of GMC and tend to fail with most hwaccels [21:41:01 CET] <JEEB> I've never actually tried MPEG-4 Part 2 in HW [22:43:40 CET] <durandal_170> how to handle private stream in mpeg? [23:11:15 CET] <ac_slater> wm4: I kinda want to detect "Null" input and produce a test pattern. I guess I could just use a test pattern input [23:16:45 CET] <wm4> uh yes [23:17:04 CET] <wm4> anything else would be weird, unless it's a temporary debug hack [23:19:48 CET] <J_Darnley> Using an existing testing source generator also means you won't screw up writing it and then wondering whether your encoder or the generator is wrong. [23:19:58 CET] <ac_slater> exactly, you guys are right [23:20:05 CET] <ac_slater> too much to do in the encoder. [23:21:11 CET] <ac_slater> wm4: I never did figure out how to pack yuv420p. I think I got the packing right, but apparently it stalls my encoder so hard that I can convert in software. So, I'm looking into using NEON to do my memcpys (since I'm on ARM). It might work [23:22:04 CET] <wm4> sounds weird [23:22:17 CET] <wm4> if it stalls hard, you might have crashed the firmware [23:22:27 CET] <wm4> (this happened all the time when I tried to get mmal decoding to work) [23:22:34 CET] <ac_slater> right, I reboot often [23:22:43 CET] <wm4> (or at least I think that's what happened) [23:22:52 CET] <ac_slater> I was looking at the mmal decoder you had commits on [23:23:03 CET] <ac_slater> I like it and I might contribute to an MMAL encoder [23:23:38 CET] <ac_slater> I'm sticking with openMAX IL at the moment since I only need to support one device at the moment [23:23:45 CET] <wm4> I'm sure rcombs has his proof of concept still somewhere (I based by mmal code on it) [23:24:05 CET] <ac_slater> I ping'd him/her last night without a responce [23:24:08 CET] <ac_slater> rcombs: ping [23:24:56 CET] <wm4> the mmal decoder is a bit absurdly complicated, because it has to connect libavcodec synchronous API to mmal's asynchronous API [23:25:23 CET] <ac_slater> exactly. I didn't want to mess with async unless I had a good grasp on vc [00:00:00 CET] --- Fri Jan 29 2016

1 0

ffmpeg.log.20160128
by burek 29 Jan '16

29 Jan '16

[00:10:46 CET] <johnnny22-afk> hyponic: great question :) [00:11:38 CET] <hyponic> johnnny22-afk you think it is doable? [00:12:19 CET] <johnnny22-afk> i don't know :) [00:12:42 CET] <johnnny22-afk> but i want to know too. [00:16:24 CET] <debianuser> hyponic: while true; do ffmpeg ... ; done [00:17:16 CET] <johnnny22-afk> but that wouldn't resume, i think. [00:17:48 CET] <hyponic> debianuser will it pick up from where it was dropped? i think it will just restart the stream and start from the bigging of the hls segment not resume [00:17:58 CET] <debianuser> maybe, not sure, it depends on a stream, I guess... [01:15:18 CET] <hyponic> debianuser i am sure it will not resume. there is no logic there for it to resume [01:22:49 CET] <IntelRNG> So I guess. [02:38:46 CET] <lucadealfaro> I am trying to use ffmpeg to record video from a webcam, and it quits after a short time. The command line is: ffmpeg -i rtsp://192.168.1.114:554/axis-media/media.amp?videocodec=h264 -vcodec copy -t 40 axis5.mp4 [02:39:14 CET] <lucadealfaro> It quits after a few seconds, e.g. after 98 frames. [02:39:47 CET] <lucadealfaro> Any suggestions? [02:50:32 CET] <__builtin> hello [02:50:42 CET] <YaMoonSun> Hello [02:50:49 CET] <__builtin> is it possible for ffmpeg to leave some blank space below a frame? [02:51:01 CET] <__builtin> and then burn in the subtitles in the blank space [02:51:30 CET] <YaMoonSun> The subtitles are burned in over the frame, not below it. It's a layering effect. [02:51:40 CET] <YaMoonSun> To my knowledge anyways [02:52:01 CET] <__builtin> no, like "below" in 2D space [02:52:50 CET] <YaMoonSun> I'm either too dumb to comprehend the question, or it's being worded strangely. Wait for more input from other members. [02:53:04 CET] <YaMoonSun> What are you trying to convert, and do you want soft subs or hard? [02:53:29 CET] <__builtin> I want to scale a video for a really weird-sized screen, and burn in hard subs [02:54:04 CET] <YaMoonSun> You know how to use the mapping tool? [02:54:23 CET] <__builtin> what is that? [02:54:54 CET] <YaMoonSun> It allows you to choose which subtitle file you want to include in the hard-subbed video output [02:55:16 CET] <__builtin> let me draw a picture to explain [02:55:42 CET] <J_Darnley> __builtin: see the pad filter [02:56:50 CET] <__builtin> thanks [02:57:11 CET] <YaMoonSun> ffmpeg -i "input" -vf scale=x:y -c:v libx264 -b:v 1200k -strict -2 -c:a aac -b:a 96k "Output.mp4" [02:57:20 CET] <YaMoonSun> https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo [02:57:21 CET] <__builtin> and also, can I place the subtitles in the blank space? [02:57:50 CET] <J_Darnley> Depends on the subs. [02:58:17 CET] <J_Darnley> srt would work just fine [02:58:26 CET] <__builtin> burned-in? [02:58:30 CET] <J_Darnley> ass might move down somewhat [02:58:41 CET] <J_Darnley> As I said: it depends on the subs [02:58:51 CET] Action: __builtin can't use "soft" subs at all [02:58:58 CET] <J_Darnley> Many sub formats contain position information [02:59:03 CET] <__builtin> ah [02:59:13 CET] <__builtin> well, I've got SubRip [02:59:17 CET] <J_Darnley> When they are rendered that info will control where they appear [02:59:44 CET] <__builtin> so no position info; how can I set where they are rendered? [03:00:10 CET] <J_Darnley> read the help about a "subtitle filter" [03:00:20 CET] <J_Darnley> YaMoonSun posted a link [03:00:54 CET] <__builtin> it doesn't give anything on how to change their offset in the frame, though [03:01:44 CET] <J_Darnley> Read the text a little more [03:01:58 CET] <J_Darnley> "See the ubtitles video filter documentation for more details. " [03:02:03 CET] <YaMoonSun> Your question is ridiculous. If you have a problem with the timing, then open the srt file with a text editor and see how subtitles work. [03:02:32 CET] <J_Darnley> He did not say "when" but "where" [03:02:54 CET] <YaMoonSun> Ah, like, top of the screen as opposed to bottom? [03:02:56 CET] <YaMoonSun> Ect [03:03:00 CET] <__builtin> yeah [03:03:00 CET] <J_Darnley> Yeah [03:03:16 CET] <YaMoonSun> Quite a pain in the arse there. Trying to sub some anime or something? [03:03:43 CET] <__builtin> kinda [03:04:51 CET] <YaMoonSun> Says you need to convert srt to ASS and then edit the file to change location of the text. [03:04:56 CET] <YaMoonSun> https://ffmpeg.org/pipermail/ffmpeg-user/2013-March/014096.html [03:05:27 CET] <YaMoonSun> Sounded like I was trolling for a minute huh? "ASS" lol [03:06:22 CET] <llogan> that's an old thread. maybe the "force_style" option in subtitles filter will do what you want [03:10:35 CET] <furq> if you're adding blank space at the bottom then a burnt-in srt will move down into that space [03:10:48 CET] <furq> whether it will be entirely in that space depends on how much space you're adding [03:21:03 CET] <__builtin> hey, thanks guys [03:21:10 CET] <__builtin> it's working now :D [03:49:12 CET] <Falxor> Hi all [03:50:40 CET] <Falxor> i have a problem, i use archlinux on a raspberry pi with the camera pi, i would like record a video file to my sd (its a C++ dashcam project) with the opencv lib. [03:51:26 CET] <Falxor> But, ffmpeg make my rpi cpu load at 100 % during recording. at 640*480@35fps [03:53:23 CET] <Falxor> i can use "raspivid" (its tools maked for the RPi), with this tools, i can record 1080p@60fps with 10%cpu load [03:53:45 CET] <Falxor> anyone know why ffmpeg overload my cpu usage ? [03:54:30 CET] <massimodipierro> I have a similar problem. also for me ffmepg quits after a while [03:54:47 CET] <Falxor> this is the command i try: ffmpeg -f v4l2 -r 25 -s 640x480 -i /dev/video0 ffmpegTest.avi [03:55:03 CET] <Falxor> oh [03:56:41 CET] <Falxor> i just try to record less 1min video, ffmpeg dont quit. for me ffmpeg generate a accelerated video [03:57:18 CET] <Falxor> i record 20 sec, the video duration is randomly, 8s, 2, 12s [03:57:32 CET] <Falxor> and cpu usage 100% [03:57:36 CET] <massimodipierro> ffmpeg -i rtsp://192.168.1.114:554/axis-media/media.amp?videocodec=h264 -vcodec copy -t 40 axis5.mp4 quits after 98 seconds on the rpi with raspian [03:57:46 CET] <massimodipierro> *98 frames* [03:58:52 CET] <Falxor> you try to stream the image, i have found 3 post for this problem: [03:59:05 CET] <Falxor> https://virtlab.wordpress.com/2013/08/23/raspberry-pi-performance-with-vide… [03:59:17 CET] <Falxor> https://www.reddit.com/r/raspberry_pi/comments/1kbybb/using_rpi_webcam_and_… [03:59:26 CET] <Falxor> https://wolfpaulus.com/journal/embedded/raspberrypi_webcam/ [04:00:35 CET] <massimodipierro> thanks looking [04:01:05 CET] <Falxor> np, i dont have tried this, i dont sure this works, but, its possible ^^ [04:04:52 CET] <Falxor> but, its sure ffmpeg have a problem with this configuration. Personaly, i can record with the raspivid command at 1080p@60fps and my cpu load its max at 10%. [04:05:51 CET] <Falxor> and the raspivid dont use ffmpeg, raspivid use MMAL lib. and all works [04:10:41 CET] <Falxor> Another, i thinks you can use "raspivid -o -" option for redicted the flux to netcat for exemple (for the test or for you use) [04:11:34 CET] <Falxor> yes its possible, "/opt/vc/bin/raspivid -t 0 -w 300 -h 300 -hf -fps 20 -o - | nc <IP-OF-THE-CLIENT> 2222" [04:11:41 CET] <Falxor> http://raspberrypi.stackexchange.com/questions/27082/how-to-stream-raspivid… [04:13:31 CET] <massimodipierro> thanks. I know how to use raspvid and that works. Just trying with ffmpeg because need code that eventually will be moved to a different architecture that will not have raspvid [04:15:05 CET] <Falxor> oh ok, i uderstand. yes same probleme, i need ffmpeg for open cv :/ [04:22:55 CET] <lucadealfaro> raspivid is for recording the local camera, right? [04:23:28 CET] <lucadealfaro> Or can it also record from network streams such as the axis camera? [04:26:20 CET] <Falxor> raspivid its a tool for recording a local camera [04:27:27 CET] <lucadealfaro> Ok thanks& this is why I was hoping to get ffmpeg to work, to be able to process the streams of my webcams [04:30:41 CET] <Falxor> but i thinks mmpge bug during aquisition of the image on me 2 camera, (raspicam and another USB camera) [04:30:46 CET] <Falxor> ffmpeg* [04:31:58 CET] <lucadealfaro> Yes, its strange, it acquires a few frames just fine (sometimes 89, sometimes a bit more or less) then quits w/o explaining why. Perhaps detecting a pause in the streaming and believing the stream is finished? [04:33:49 CET] <Falxor> i dont know, personaly, ffmpeg dont quit, but i dont stream the image, i just record the image in local to my SD card. and ffmpeg make my cpu usage more of 100% [04:34:18 CET] <lucadealfaro> ffmpeg uses 100% CPU (and works) if you ask it to recode [04:34:31 CET] <lucadealfaro> if you use -vcodec copy , then it just copies but then quits [04:34:52 CET] <lucadealfaro> I was trying to use it to segment the video with the -segment options [04:36:05 CET] <Falxor> i dont try to recode, my raspicam output h.264, i try to save in h264 [04:39:59 CET] <Falxor> i use this command for recording: ffmpeg -f v4l2 -r 25 -s 640x480 -i /dev/video0 ffmpegTest.avi [04:42:18 CET] <lucadealfaro> Interesting, if I do a ls /dev I dont see the /dev/video0 device. Did you do something (install video4linux) to create it? [04:42:57 CET] <Falxor> (another my project is on C++ and i use opencv lib, opencvlib use ffmpeg for aquisition) but in my program, the output file is accelerated (i record 20 sec, the video file duration is 2 s or more or less) during my program, cpu usage 100%, i try to fix this. but with only ffmpeg, cpu usage 100% too, i suspect ffmpeg ^^ [04:43:14 CET] <Falxor> you need to lunch the service [04:43:45 CET] <Falxor> sudo modprobe bcm2835-v4l2 [04:43:57 CET] <Falxor> and the rpicam its on /dev/videoX [04:46:35 CET] <lucadealfaro> Oh wow, thanks, I did not know that there was already a module to act as video4linux, this is great advice. [04:47:21 CET] <Falxor> np ! ^^ [04:52:35 CET] <massimodipierro> Thanks Falxor [06:48:27 CET] <TannerK> Hello, I was wondering if anyone had a way to duplicate the exact encoding of a video for a new one? I want to concatenate 2 videos but try as I might I can't get the second video to match the first. [06:49:33 CET] <TannerK> I plan to add the second video on to a lot so reencoding the first videos everytime isn't an option and it will always be in the same format. [06:52:19 CET] <TannerK> Here are the settings to the first file http://pastebin.com/2a3FqH0t I'm just trying to find a way to encode a video exactly like that to concat. [06:52:56 CET] <furq> how are you trying to concat them and what error do you get [06:53:15 CET] <TannerK> I get an error that the videos don't match [06:53:29 CET] <furq> pastebin the command line [06:54:06 CET] <TannerK> Okay, I'll re-run it and paste it. Just a minute [06:58:46 CET] <TannerK> http://pastebin.com/MR6pKMNU [06:59:55 CET] <furq> i don't think the concat demuxer works with mp4 [07:00:00 CET] <furq> did you try with the concat protocol [07:00:31 CET] <TannerK> I tried a few different ones that I couldn't get to work but I'm not sure what. [07:00:42 CET] <furq> ffmpeg -f concat -i <(printf "file myfile1.mp4\nfile myfile2.mp4") -c copy out.mp4 [07:01:34 CET] <furq> if you're on windows you'll probably need to create a concat file and use that as the input [07:01:47 CET] <TannerK> I am on windows [07:01:48 CET] <johnnny22-afk> Trying to figure out if hls.c uses the http's protocol 'timeout', 'reconnect_streamed', 'multiple_requests' and maybe even 'reconnect_delay_max' options for the requests used to fetch the HLS segments. [07:01:59 CET] <furq> TannerK: https://trac.ffmpeg.org/wiki/Concatenate#demuxer [07:02:46 CET] <TannerK> Thanks for the direction. I'll see what I can pull from that [07:03:16 CET] <furq> if it still doesn't work then if the first file was encoded with x264 then you can get the exact encoding settings [07:03:38 CET] <furq> i forget how to do it with ffprobe but you can get it with mediainfo [07:04:24 CET] <furq> http://sprunge.us/fiib [07:06:30 CET] <TannerK> Looking at the concat protocal I did try that but it needs to re-encode the videos to combine it in the output file since the codecs don't match [07:06:47 CET] <furq> use the demuxer, not the protocol [07:11:57 CET] <TannerK> I tried that and my video is still not working http://pastebin.com/3tsxSaTT [07:12:17 CET] <TannerK> It's giving me an error like the second file has an invalid duration [07:13:25 CET] <TannerK> I made the second file from an image with ffmpeg matching the settings from the first file. [07:13:55 CET] <TannerK> I wanted the second file to match so I could easily concate it to other files of the same format in the future as I have to append it a lot [07:14:42 CET] <TannerK> I don't know if there is a better method to make a video that matches the first but I'm sure my video is the issue [07:45:50 CET] <TannerK> I finally solved my issue but with a really weird workaround. [07:47:03 CET] <TannerK> The source video I'm trying to match is the output of a twitch stream. I couldn't create a video that matched those setting no matter what I tried so I couldn't combine them. What I ended up doing was creating an account and broadcasting what I wanted and pulled that twitch stream so it would be in the exact same format and it worked. [07:47:32 CET] <johnnny22-afk> hehe, nice workaround :) [07:47:43 CET] <TannerK> thanks for putting up with me firq. :) [07:47:45 CET] <TannerK> Thanks [09:44:14 CET] <realies> can I integrate ffplay in wpf application as a control? [09:44:24 CET] <zylthinking> what is the avstream->time_base means, I assigin it with .num = 1, .den = 1000; then I call avformat_write_header to write mp4 header, after I return, I find the time_base changed to .num = 1, .den = 16000 [09:46:11 CET] <zylthinking> I want to know why such thing happens, and what is the right way to assign the time base, because I only have pts of type uint64_t, I wants to make the mp4 to play normally and the file duration correct [09:47:10 CET] <zylthinking> and how can I assign the dts, which I am absent of it. [09:52:53 CET] <Artix> Hello, anyone know an 'howto' to make mpeg2 for d10 mxf please (SD PAL) ? [09:56:05 CET] <Artix> have tried that, but the quality is not what i expect => http://pastebin.com/Hst5pbcx [10:26:06 CET] <durandal_170> realies: nope [12:02:09 CET] <dj_beirut> is possible to get ffmpeg to automatically respawn if a hls steam is disconnected and try to pick up from where it was dropped? [12:13:40 CET] <J_Darnley> I don't think ffmpeg has that feature. Perhaps you can do that in your shell. [12:21:52 CET] <dj_beirut> J_Darnley can you please elaborate? how would it be done from the shell? and how would it know where it was drop and resume from the segment it was dropped from? [12:22:35 CET] <J_Darnley> Its a stream. It will start from where ever the server sends. [12:26:13 CET] <J_Darnley> As for the restarting: while true; do ffmpeg; done [13:09:48 CET] <dj_beirut> J_Darnley well a hls stream have different segments and if the last segment id was y and you reconnect the first segment might be x and the next is y where you dropped off. i need it to analyse the segments and start from segment y where it was dropped off. [13:22:41 CET] <superware> I'm running "ffplay.exe udp://224.0.18.0:40003" with the ethernet cable disconnected (Windows 7), but when I connect the cable to the NIC the video doesn't play. It only plays if I execute ffplay after the cable is already connected, any ideas? [13:28:08 CET] <jkqxz> It only tries to join the multicast group once, and you can't join it if the cable is disconnected maybe? It sounds more likely to be something in Windows than in ffmpeg. [13:30:31 CET] <superware> I've also tried ffmpeg libav by retrying avformat_open_input every 20 seconds, but it starts playing only once I restart the process. [13:31:09 CET] <superware> hmmm, what can it be? [13:36:18 CET] <jkqxz> Does Windows believe you are actually joined to the multicast group when you think you should be? [13:39:15 CET] <superware> shouldn't avformat_open_input handle that? I'm trying it every 20 seconds [13:41:19 CET] <superware> jkqxz: no, only after I restart the process (ffplay or mine) [13:46:57 CET] <jkqxz> That does just call setsockopt(..., IP_ADD_MEMBERSHIP, ...) directly, so I think your problem must be Windows. [13:49:45 CET] <jkqxz> Hmm. It calls it with INADDR_ANY if you didn't specify a local address to use. Are you explicitly specifying the interface you want using the "localaddr" option? [14:34:39 CET] <amason> Hi. I'm creating a fisheye effect using lenscorrection but it results in a green border as if the background is green. Any way to set that to black? [14:46:47 CET] <superware> jkqxz: what do you mean by "explicitly specifying the interface you want using the "localaddr" option"? [14:54:39 CET] <jkqxz> udp has an option "localaddr", which will specify the interface you are binding to and then gets used in the IP_ADD_MEMBERSHIP setsockopt(). Have you tried specifying that to match the local address of the interface you want to use? [15:06:43 CET] <superware> jkqxz: but avformat_open_input is being called AFTER the interface is available, but it doesn't receive the multicast, only when I restart the process it works. [15:09:19 CET] <jkqxz> Maybe Windows is remembering something about the set of interfaces it used in the INADDR_ANY default case? Even if that isn't the case, trying to join the multicast group on other interfaces as well could be confusing it somehow. [15:13:31 CET] <superwav> jkqxz: you mean something avformat_network_init is doing once at startup? [15:17:34 CET] <jkqxz> No. Look in libavformat/udp.c, it runs for every udp_open(). [15:21:09 CET] <superware> but it doesn't explain why start-process => avformat_network_init => avformat_open_input (no data) => connect-cable => avformat_open_input (still no data) vs. connect-cable => start-process => avformat_network_init => avformat_open_input (works) [15:21:57 CET] <superware> in both cases avformat_open_input should have worked once the NIC is connected [15:31:10 CET] <DHE> is your switch doing IGMP snooping? [15:34:12 CET] <Ccdc_DuckZ> hello, I have to add video export capabilities to our commercial software (video only), and I'm considering ffmpeg, but I don't understand the licence very well... http://ffmpeg.org/legal.html at the bottom of that page it says MPEG LA might come after us for fees, but isn't ffmpeg an "unofficial" implementation of mpeg codec? [15:34:57 CET] <Ccdc_DuckZ> does that mean that no matter the codec I use, we have to pay MPEG LA as long as the app emits mpeg videos? [15:35:07 CET] <Ccdc_DuckZ> *the implementation [15:36:28 CET] <DHE> MPEG LA licensing is more about content distribution. this is why google is big on making VP9, etc [15:36:44 CET] <DHE> the codec software itself isn't really a factor [15:41:15 CET] <superware> DHE: no switch, PC-to-PC [15:42:19 CET] <Pimster_> Hi there. I'm trying to get a RTSP stream to Youtube Live, using FFmpeg on Ubuntu. I'm failing at the moment. Could anyone help? [15:42:20 CET] <Ccdc_DuckZ> sorry, firewall problems I guess [15:43:28 CET] <Ccdc_DuckZ> DHE: did I miss anything? http://pastebin.com/FeGU3twD [15:44:02 CET] <Pimster_> This is one of the error messages "[rtsp @ 0x242a320] method PLAY failed: 453 Not Enough Bandwidth" [15:44:31 CET] <DHE> Ccdc_DuckZ: you missed nothing related to your issue. but I didn't see your post on line 6 [15:45:03 CET] <Ccdc_DuckZ> DHE: ok! btw, I was going to say that our program just needs to save an animation with no audio at all, and the user will do whatever he wants with that video [15:46:15 CET] <Ccdc_DuckZ> if it won't cause additional legal troubles/uncertainties, I'd also like to add an upload to vimeo/youtube button [15:46:31 CET] <DHE> well I'm not a lawyer either... [15:46:59 CET] <DHE> http://www.mpegla.com/main/programs/AVC/Documents/avcweb.pdf This looks like the abridged version of the licensing terms... in small volumes (less than 100,000 users/sales) it sounds like you'll be okay. [15:48:25 CET] <DHE> but again, don't take my word for it [15:49:43 CET] <Ccdc_DuckZ> DHE: that sounds like useful info, I'll pass it on to my manager, no way I'll be taking responsibility on this stuff :p [15:50:28 CET] <Ccdc_DuckZ> btw what alternatives do I have, other than mpg? [15:50:29 CET] <furq> Ccdc_DuckZ: it sounds like you could use libvpx and libwebm directly [15:51:05 CET] <furq> idk if vimeo accepts webm uploads but youtube definitely does [15:51:38 CET] <Ccdc_DuckZ> furq: so that's the VP9 DHE was mentioning, right? [15:52:11 CET] <furq> vp8 would probably be fine too [15:52:37 CET] <furq> it's not as widely supported as h264 but it's free of patent encumbrance [15:54:13 CET] <Ccdc_DuckZ> a-ha, interesting [16:02:32 CET] <jkqxz> superware: It doesn't explain that difference directly, but Windows remembering something about the process certainly would. Hence the suggestion to specify more properties explicitly rather than relying on some default behaviour to eliminate that possibility. [16:26:33 CET] <Ccdc_DuckZ> that was very helpful, thanks for the pointers! [16:29:58 CET] <superware> jkqxz: thanks man! localaddr rox :) [17:00:46 CET] <dystopia_> can someone help me with -ss [17:00:49 CET] <dystopia_> http://pastebin.com/Ji3WyPpa [17:01:17 CET] <dystopia_> when i add -ss 00:13:11 before -i in my command, it breaks it [17:01:24 CET] <dystopia_> without the -ss and time it works fine [17:01:36 CET] <YaMoonSun> Just do -ss 00:13:11 near the end [17:01:47 CET] <dystopia_> after the -i ? [17:01:52 CET] <YaMoonSun> Yup [17:01:56 CET] <dystopia_> ok :) [17:01:57 CET] <dystopia_> testing [17:02:02 CET] <YaMoonSun> Good luck [17:02:43 CET] <DHE> kinda looks like %hcrf% isn't defined [17:03:51 CET] <dystopia_> ahh your right about crf [17:04:05 CET] <dystopia_> need to move that up in my script [17:05:05 CET] <dystopia_> heh nothing was being defined pretty much [17:05:07 CET] <dystopia_> ok thanks guys [17:05:11 CET] <dystopia_> got it going [17:07:51 CET] <YaMoonSun> Nice [17:25:29 CET] <DHE> well if you have blanks for variables then the next parameter name will be swallowed as the previous parameter value and your whole commandline break [17:25:33 CET] <DHE> s. so don't do that [19:42:31 CET] <Sashmo> hey guys..... im using black detect to find full black frames over 6 seconds... here is the command -vf "blackdetect=d=6:pix_th=0.00" but its catching black frames that still have a logo on them.... does anyone have an idea how to correct that and get 100% black frame? [19:44:30 CET] <durandal_170> Sashmo: there is picture_black_ratio_th [19:44:37 CET] <durandal_170> Option [19:45:03 CET] <Sashmo> durandal_170: is that better than the blackdetect or just different.... I thought the blackdetect was better [19:45:36 CET] <Sashmo> durandal_170: ahhhhh [19:45:42 CET] <Sashmo> I miss read the command.... [19:45:54 CET] <Sashmo> its miissing ratio.... that command is only for duration [19:46:38 CET] <durandal_170> ? [19:46:45 CET] <Sashmo> nothing [19:46:56 CET] <Sashmo> let me re-read the options.... I am clearly not doing it correctly [19:46:59 CET] <Sashmo> tahnks [00:00:00 CET] --- Fri Jan 29 2016

1 0

ffmpeg-devel.log.20160127
by burek 28 Jan '16

28 Jan '16

[00:09:20 CET] <cone-213> ffmpeg 03Andreas Cadhalpun 07master:9079e99d2c46: svq1enc: fix out of bounds reads [00:13:17 CET] <llogan> my server problem was due to systemd change regarding predictable network interface names. [00:14:12 CET] <nevcairiel> Daemon404: i got tired of carefully reviewing every single commit and fixing half of them, so i took a break. I wish their quality hadn't degraded that much [00:16:48 CET] <durandal_1707> hmm, what needed fixing? [00:20:25 CET] <nevcairiel> Daemon404: not to m ention that they live in a bubble and re-implement so many things they could just port, and the things they do port end up being refactored to no end =p [00:21:21 CET] <llogan> sounds like a cult [00:28:04 CET] <wm4> refactor cult? [00:28:42 CET] <llogan> living in a bubble, refactoring, killing goats, re-implementing, etc. [00:30:27 CET] <durandal_1707> sometime it get approved but never comitted [00:47:43 CET] <Daemon404> nevcairiel, yeah i know [00:47:53 CET] <Daemon404> ill try and catch us up tomorrow [00:47:57 CET] <Daemon404> or at least make a dent [00:49:07 CET] <nevcairiel> some hints: discard any and all nvenc changes, ours is vastly different; carefully review refactoring from koda, his commits are usually on the more sloppy side [00:50:46 CET] <Daemon404> o/ [03:55:28 CET] <BBB> jya: do you know the first stable firefox release that used ffvp9 decoding? (or will use) [04:05:00 CET] <jya> BBB: 46 [04:05:19 CET] <jya> 46 made alpha on Monday [04:05:30 CET] <jya> so in 12 weeks it will be official release [04:05:52 CET] <jya> if all goes well (and no major regressions were found in ffvp9) [04:06:14 CET] <jya> we want to provide an update benchmark. last we did it was with ffvp9 based on 2.8 [04:14:25 CET] <BBB> I just want to show cpu usage in firefox vs. chrome playing the same youtube video [04:24:29 CET] <TD-Linux> BBB, I think it's still not on for all users though [04:24:48 CET] <TD-Linux> I think windows users still get H.264 only :/ [04:25:10 CET] <TD-Linux> so just make sure you're actually getting VP9 in both cases before doing the comparison [07:42:09 CET] <cone-963> ffmpeg 03Matt Oliver 07master:b66ac803fac2: avformat/mux: Fix error when writing uncoded frames. [10:13:14 CET] <cone-963> ffmpeg 03Carl Eugen Hoyos 07master:69dbecf920f6: lavc/h264: Show "Increasing reorder buffer" message with loglevel info. [10:16:55 CET] <BtbN> So there are two "competing" libva h264 encoders on the list now? [10:17:19 CET] <BtbN> I'm in favor of the one included with the vaapi revamp though [10:24:55 CET] <cone-963> ffmpeg 03Carl Eugen Hoyos 07master:7a90edc188a7: lavc/mjpegdec: Set SAR even if no resolution is available. [10:27:23 CET] <wm4> BtbN: yeah [10:31:23 CET] <nevcairiel> someone should probably tell those guys to cooperate =p [10:31:48 CET] <BtbN> Well, they're both done [10:31:55 CET] <wbs> one of them at least finally stopped calling it libih264 [10:38:36 CET] <BtbN> well, the other one wasn't ever called like that [10:39:01 CET] <wbs> yeah [10:39:13 CET] <wbs> rephrase, "the one that used to call it weird stuff at least stopped doing that" [10:39:53 CET] <nevcairiel> that one probably still has a bunch of problems left though, it wasnt exactly clean code otherwise [10:40:34 CET] <nevcairiel> still havent removed the unrelated changes to configure which were pointed out in the very first review [10:42:58 CET] <wm4> it also opens X displays in libavcodec and such things [10:48:05 CET] <BtbN> There is no real point in doing that, the drm method works just fine, and doesn't depend on X [10:48:31 CET] <wm4> you need it if you use the vaapi vdpau backend [10:48:40 CET] <wm4> but even so, libavcodec shouldn't be doing stuff like this [10:48:49 CET] <BtbN> That still exists? [10:49:19 CET] <BtbN> What else should it do? Just expect the application to implement it? [10:50:55 CET] <wm4> http://sprunge.us/PEJH [10:50:58 CET] <wm4> from the patch [10:51:13 CET] <wm4> BtbN: yes, ffmpeg_vaapi.c etc. [10:51:47 CET] <BtbN> Well, that'd mean you need to implement special handling just for that encoder, and can't just use it like all the other ones [10:52:22 CET] <wm4> the patch even wraps vaPutSurface, what's that even for [10:52:34 CET] <BtbN> I don't see an issue with implementing the DRM open thing in lavc, it's just opening a file. [10:53:17 CET] <BtbN> introducing a pointless dependency on X is kind of an issue though [10:53:29 CET] <BtbN> The VAAPI vdpau backend is dead anyway [11:20:37 CET] <jkqxz> The VAAPI H.264 encoder I wrote is entirely a token effort - it only does IDR/P at constant QP. Copying the libva example encoder as in the other patch would be a sensible advance. [11:21:31 CET] <cone-963> ffmpeg 03Paul B Mahol 07master:ce404b4d7c99: avfilter/af_afade: do not duplicate curve option [11:21:32 CET] <cone-963> ffmpeg 03Paul B Mahol 07master:74e8f4f67446: avcodec/dvaudiodec: set channel layout [11:22:42 CET] <jkqxz> (I am intending to work on improving the H.265 encoder only.) [11:25:20 CET] <wm4> jkqxz: so how should we do it [11:25:37 CET] <wm4> jkqxz: not apply your h264 encoder at first, and ask him to port it to your infrastructure? [11:30:15 CET] <ubitux> is RGBA supposed to be premultiplied in ffmpeg? [11:30:39 CET] <nevcairiel> dont think so [11:31:40 CET] <ubitux> would it make sense to have a filter to premult, and should we have a bunch of new pixfmt to mark the difference? (i'm gonna get killed for that second question) [11:35:36 CET] <jkqxz> wm4: Might be the best course of action, if they feel like cooperating. [12:03:16 CET] <durandal_1707> ubitux: no, adding pixels formats for that is wrong [12:05:30 CET] <wm4> actually a new pixfmt would be reasonable [12:05:42 CET] <wm4> considering how bad support for other attributes like limited range etc. is in lavfi [12:05:56 CET] <wm4> (format negotiation only considers pixfmt) [12:06:07 CET] <nevcairiel> "a new", more like cloning every rgba format [12:07:30 CET] <rcombs> re: jkqxz's work, I wonder if it might make sense to integrate the surface conversion into vf_scale [12:08:57 CET] <rcombs> or otherwise integrate it into the autonegotiation infrastructure [12:10:28 CET] <rcombs> I'm saying "integrate" too much [12:15:31 CET] <jkqxz> I wondered that. Really I would prefer to keep it explicit, but the libavfilter automatic things do mess with that and make you want some integration for anything but a single leaf operation (especially in vf_scale). [12:16:14 CET] <jkqxz> (Pure hardware transcode, with no copy through normal memory, still does not work with the patchset I have.) [12:19:20 CET] <wm4> but in theory, it could work, right? [12:20:59 CET] <jkqxz> Certainly. (I was meaning that avfilter gets in the way - it works with some nasty hackery.) [12:21:54 CET] <wm4> you mean the problem of passing the vaapi context? [12:22:48 CET] <BtbN> The vaapi h264 encoder is propabaly more important than the hevc one. [12:23:11 CET] <BtbN> hevc hardware encoding is kind of useless. For h264 it's usefull for live streaming [12:23:26 CET] <jkqxz> Yeah. And also of automatically created things barfing on AV_PIX_FMT_VAAPI. [12:28:12 CET] <rcombs> because it's a hardware format, and those are explicitly not used for some autonegotiation? [12:28:56 CET] <wm4> isn't the problem that libavfilter will think vf_scale always can convert anything [12:29:17 CET] <jkqxz> The autonegotiation always tries to choose YUV420P/NV12 if it can. If you force it, it inserts vf_scale instances which then barf. [12:30:01 CET] <jkqxz> *tries to choose YUV420P/NV12 over VAAPI if it can. [12:30:24 CET] <nevcairiel> full hardware transcode works with qsv, it somehow manages to just skip avfilter entirely [12:31:55 CET] <rcombs> nevcairiel: see ffmpeg_qsv.c [12:33:18 CET] <rcombs> (I'd rather not be like ffmpeg_qsv.c) [12:35:10 CET] <jkqxz> We do want avfilter, there are useful things to do there. Just, no magic. [12:35:30 CET] <wm4> rcombs: I don't see how it prevents lavfi from throwing up [12:35:45 CET] <rcombs> jkqxz: right [12:38:24 CET] <rcombs> wm4: it makes sure full-hardware transcoding is only used when there are no filters in the chain that care about pixel format [12:39:03 CET] <nevcairiel> well of course, thats the only way it can be full hardware, otherwise you need to go back to software [12:39:21 CET] <nevcairiel> because you cant expect any arbitrary filters to accept hardware surfaces [12:40:11 CET] <rcombs> nevcairiel: well if the autonegotiation infrastructure knew how to convert back and forth it'd be fine [12:40:25 CET] <rcombs> just like any other auto-negotiated pixel format conversion [12:40:55 CET] <rcombs> and at some point additional filters might gain support [12:41:04 CET] <rcombs> e.g. vf_overlay [12:41:35 CET] <rcombs> or a VAAPI deinterlacer [12:42:03 CET] <jkqxz> Yeah, overlaying a software-created image onto the hardware surface is totally possible here. [12:42:06 CET] <rcombs> and I'm sure there's some way to get ff_draw to work with this [12:42:27 CET] <rcombs> which would mean vf_subtitles would work [12:42:32 CET] <rcombs> amongst others [12:42:35 CET] <nevcairiel> feel free to propose a clean non-vaapi-specific api =p [12:43:52 CET] <nevcairiel> that hw api from anton might possibly be able to do that at some point, it tried to define a generic copy-back function extensible for all hwaccel implementations [12:45:55 CET] <rcombs> sounds promising [12:49:43 CET] <rcombs> &huh [12:50:52 CET] <rcombs> jkqxz: could you call an AVFrame e.g. AV_PIX_FMT_YUV420P, and just set all its plane pointers to the relevant offsets into the mapped surface? [12:51:51 CET] <nevcairiel> without optimized copy-back functions, thats going to be crawling slow [12:52:30 CET] <wm4> also, not all hw apis have such mapping [12:52:55 CET] <jkqxz> In VAAPI, only in some cases. Drivers are not required to allow the mapping (using vaDeriveImage()), you would need to fall back to copying into memory and out again (vaGetImage()/vaPutImage()). [12:53:49 CET] <jkqxz> Also on Intel the mapping you get is not in cached memory, so reading it is immensely slow without special extra magic. [12:54:30 CET] <rcombs> hmmm, so interesting but impractical [12:56:30 CET] <durandal_1707> wm4: if AVframe primaries, etc changed they are kept, no need to query formats on them [12:57:09 CET] <durandal_1707> adding another yuvj variants is insane [12:57:12 CET] <wm4> durandal_1707: the point is they should be subject to automatic conversion or negotiation failure if not possible [12:57:29 CET] <nevcairiel> maybe its time for smarter negotiation then [12:57:42 CET] <nevcairiel> i agree that another yuvj debacle would be terrible [12:58:01 CET] <durandal_1707> can we add yuv420bt2020halfassfloat [12:58:26 CET] <wm4> durandal_1707: one suggestion was replacing the format enum with a struct, the pixformaton [12:58:37 CET] <wm4> which describes the format using multiple fields [12:59:10 CET] <jkqxz> rcombs: Drawing on surfaces probably needs to work by drawing to a scratch buffer with an alpha channel, copying that buffer to a hardware surface and then blending in hardware. Getting the input surface somewhere you can draw on directly is just too much trouble. [12:59:10 CET] <rcombs> I'd be in favor of that [12:59:31 CET] <rcombs> and then it could also be partially-filled in cases where you only know some properties [13:00:10 CET] <rcombs> e.g. the H.264 parser can tell you that a particular stream has Y, U, and V components, each 8 bits per sample, with 4:2:0 subsampling [13:00:24 CET] <wm4> for lavfi, maybe we could also do something like having "prototype" AVFrames with no data, and let format negotiation work on that [13:00:53 CET] <rcombs> but the actual format you're storing it is up to the decoder and multiple might be applicable, so the parser has no business picking one [13:01:15 CET] <rcombs> jkqxz: mmmmm [13:02:55 CET] <nevcairiel> fwiw alpha blending manually on dxva surfaces works quite well [13:03:17 CET] <nevcairiel> not sure how slow it is on some hardware, i only do it with dvd subtitles [13:03:22 CET] <nevcairiel> and thats not much data [13:05:05 CET] <rcombs> jkqxz: well I need to get some sleep, but this work is definitely relevant to my interests [13:11:15 CET] <jkqxz> nevcairiel: Yeah, small areas would probably work ok. Maybe that /is/ worth supporting on its own for just that case (with a lot of errors and warnings to explain the failure modes and likely slowness if abused). [14:03:46 CET] <cone-963> ffmpeg 03Paul B Mahol 07master:75a7565bcb69: avcodec/dvaudiodec: support cases when codec_tag is not set but block_align is [14:08:22 CET] <wm4> nevcairiel: daily nagging when you will push your dxva hevc main10 patch [14:28:10 CET] <Daemon404> time to start some merges... [15:04:04 CET] <nevcairiel> good luck [15:09:54 CET] <nevcairiel> i think i left it off right at one annoying change where they renamed that macro =p [16:02:28 CET] <Daemon404> nevcairiel, lol k [16:10:19 CET] <Daemon404> got sidetracked fixing a fosdem schedule to be less shitty... [16:10:34 CET] <JEEB> lol [16:14:07 CET] <Daemon404> nevcairiel, wait... they put the macro in public API? [16:14:08 CET] <Daemon404> wtf? [16:14:44 CET] Action: Daemon404 doesnt really have a choice but to rename it to AV_* then to match API... [16:16:19 CET] <wm4> what where [16:16:39 CET] <Daemon404> they merged FF_CEIL_RSHIFT as AV_CEIL_RSHIFT [16:16:44 CET] <JEEB> löl [16:16:51 CET] <kierank> yes they did that [16:16:54 CET] <kierank> blame koda [16:17:30 CET] <durandal_1707> they are libAV not FFmpeg [16:19:31 CET] <nevcairiel> Daemon404: stop caring about compat [16:19:35 CET] <nevcairiel> just screw them =p [16:22:28 CET] <Daemon404> nevcairiel, easier to rename for future though. Patch on ML. [16:22:35 CET] <Daemon404> it screws us, not them [16:23:05 CET] <nevcairiel> we even tried to tell koda, but you can imagine how that went [16:23:20 CET] <nevcairiel> all those crazy macros are FF [16:23:22 CET] <nevcairiel> but hell [16:24:03 CET] <wm4> meh I guess the day where I might have to drop libav support in my own code is coming closer (these little API differences are just so annoying) [16:24:22 CET] <Daemon404> at work we only use ffmpeg, and it's pretty sane [16:24:28 CET] <Daemon404> and only HEAD [16:25:41 CET] <JEEB> same here [16:25:59 CET] <nevcairiel> every sane thing just rolls their own fixed version [16:26:30 CET] <nevcairiel> controlling the version just saves so many headaches [16:26:41 CET] <JEEB> well yeah, I lock a version and update it every time I can run a new revision through testing [16:27:18 CET] <Daemon404> until you end up like youtube stuck on a 3 year old ffmpeg =p [16:27:46 CET] <nevcairiel> work is currently at about one year old, I wanted to wait until a aac improvements were in [16:27:51 CET] <nevcairiel> gotta start upgrading soon [16:28:36 CET] <JEEB> Daemon404: yeah, I've been really strict at making sure that every time I can update FFmpeg and it passes tests, it gets updated [16:28:43 CET] <JEEB> getting behind is the worst :P [16:28:49 CET] <Daemon404> i *cant* use an old ffmpeg [16:28:53 CET] <Daemon404> some stuff i need aint there [16:29:22 CET] <JEEB> yeah [16:29:47 CET] <JEEB> I've never been behind more than a month so far I think [16:31:34 CET] <nevcairiel> there, throwing w3fdif at the masses, lets see if anyone actually still cares about swdeint =p [16:31:54 CET] <nevcairiel> someone should totally port the remaining asm to x86 [16:35:15 CET] <durandal_1707> w3fdif is worse than yadif at vectors content [16:35:41 CET] <JEEB> nevcairiel: oh nice, I was wondering if we had any info on how good/bad it was [16:36:02 CET] <durandal_1707> graphical shapes that are static [16:36:21 CET] <nevcairiel> most video deinterlacers have problem with such elements [16:36:40 CET] <durandal_1707> there is nnedi, if someone wants to add asm [16:40:00 CET] <nevcairiel> my interest is mostly on real-time use during playback, and if w3fdif is anything, its very fast, so that plays well there [16:40:21 CET] <j-b> 'morning [16:40:23 CET] <wm4> you could just use some bob thing [16:40:29 CET] <Daemon404> badvr allows nnedi for playback [16:40:34 CET] Action: Daemon404 runs [16:44:03 CET] <Daemon404> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/188104.html <-- these never made it to my inbox [16:44:07 CET] <Daemon404> how strange [16:44:14 CET] <nevcairiel> i saw them [16:45:01 CET] <Daemon404> not even in my spam folder [16:45:22 CET] <wm4> seeing them too [16:46:34 CET] <Daemon404> weird [16:46:41 CET] <Daemon404> i can reply using the headers anywya... [16:51:25 CET] <durandal_1707> mpv use nnedi for playback too [16:51:38 CET] <durandal_1707> using shaders [16:59:58 CET] <wm4> it's too slow though (nobody tried to optimize it either) [17:01:03 CET] <nevcairiel> madvr does it with opencl, but i've been told pixel shader variants can be equally fast though if optimized [17:01:17 CET] <nevcairiel> but even then it needs high-end hardware, its rather expensive [17:01:23 CET] <nevcairiel> and forget running it on the cpu inr ealtim,e [17:01:26 CET] <nevcairiel> realtime* [17:01:47 CET] <wm4> well modern opengl shaders are almost opencl anyway [17:01:53 CET] <Daemon404> madvr's version makes my fan spin wildly on my gpu [17:01:56 CET] <wm4> same for d3d I'm sure [17:14:50 CET] <ubitux> nevcairiel: just define FF_CEIL_RSHIFT on AV_CEIL_RSHIFT, and i'll sed everything to AV and drop the FF if you don't want to do it later [17:15:13 CET] <nevcairiel> tell Daemon404, its his task for the day :D [17:15:49 CET] <ubitux> Daemon404: in the merge, drop FF_CEIL_RSHIFT and replace it with #define FF_CEIL_RSHIFT AV_CEIL_RSHIFT [17:16:00 CET] <ubitux> smaller merge [17:16:10 CET] <ubitux> i'll make it consistent if you're too lazy [17:17:09 CET] <Daemon404> ubitux, uh [17:17:14 CET] <Daemon404> did you not see my patch on the ML [17:17:17 CET] <Daemon404> it does exactly this [17:17:24 CET] <ubitux> ah, my bad [17:17:26 CET] <ubitux> sure ok [17:17:32 CET] <Daemon404> i even defined it :P [17:17:53 CET] <Daemon404> just waiting on an ACK [17:18:19 CET] <Daemon404> poor wm4, caring about mmal [17:18:52 CET] <wm4> lol [17:19:31 CET] <wm4> so does anyone care about reviewing those mmal patches, or should I just push? [17:19:59 CET] <Daemon404> who could even review? [17:20:44 CET] <durandal_1707> the one who can test it [17:24:10 CET] <Daemon404> dammit why are you so stipid thunderbird [17:24:18 CET] <Daemon404> why do you default to replying to: me [17:24:20 CET] <Daemon404> instead of teh list [17:25:11 CET] <ubitux> Daemon404: on the ml too [17:25:15 CET] <ubitux> (the ack) [17:25:27 CET] <Daemon404> nah i sent it again... [17:25:31 CET] <Daemon404> teh first was solely to: me [17:25:39 CET] <Daemon404> it's because i bcc myself [17:25:44 CET] <wm4> "àw" <243186085(a)qq.com> [17:25:46 CET] <ubitux> i mean i replied on the ml [17:25:53 CET] <Daemon404> oh [17:25:58 CET] <ubitux> but it seems it didn't reach it [17:26:00 CET] <ubitux> ... [17:26:03 CET] <wm4> that's hell of a username and email [17:26:10 CET] <ubitux> Daemon404: anyway, please add a \n after the define [17:26:20 CET] <Daemon404> ubitux, i dont see it [17:26:24 CET] <Daemon404> and ok [17:26:42 CET] <ubitux> (FFUDIV etc are not for backward compat) [17:26:52 CET] <ubitux> that was my only comment [17:27:04 CET] <ubitux> waiting for it to reach the ml [17:27:28 CET] <Daemon404> O_o [17:28:33 CET] <cone-559> ffmpeg 03Michael Niedermayer 07master:0aada30510d8: avcodec/jpeg2000dec: More completely check cdef [17:33:33 CET] <ubitux> wm4: Signed-off-by: zjh8890 <243186085(a)qq.com> [17:33:43 CET] <ubitux> zjh8890 is much better than àw [17:33:46 CET] <Daemon404> the numbers apparently make sense in chinese [17:33:47 CET] <wm4> true [17:33:55 CET] <Daemon404> since they can form 'words' [17:33:57 CET] <Daemon404> or something [17:34:06 CET] <ubitux> builtin 1337 speak [17:34:08 CET] <wm4> yes that's why their websites are often numbers [17:37:21 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:21f946840260: avutil: Rename FF_CEIL_COMPAT to AV_CEIL_COMPAT [17:41:36 CET] <Daemon404> wait what the fuck [17:41:42 CET] <Daemon404> #define AV_CEIL_RSHIFT(a,b) (!av_builtin_constant_p(b) ? -((-(a)) >> (b)) \ : ((a) + (1<<(b)) - 1) >> (b)) [17:41:45 CET] <Daemon404> ours [17:41:46 CET] <Daemon404> #define AV_CEIL_RSHIFT(a, b) \ [17:41:46 CET] <Daemon404> (av_builtin_constant_p(b) ? ((a) + (1 << (b)) - 1) >> (b) \ [17:41:47 CET] <Daemon404> : -((-(a)) >> (b))) [17:41:48 CET] <Daemon404> theirs [17:41:54 CET] <Daemon404> why the shit would you reverse it? just for fun? [17:42:02 CET] <Daemon404> sorry for the foul language [17:42:03 CET] <Daemon404> but jeez. [17:42:23 CET] <Daemon404> ... inb4 cosmetic reasons [17:42:44 CET] <jamrial> arm gets idct hevc before x86, lol [17:42:52 CET] <ac_slater> hey all. I'm making a libavcodec encoder. In my AVCodec instance, .pix_fmts contains only AV_PIX_FMT_YUV420P and AV_PIX_FMT_NONE. Yet, my input source is not auto converted to yuv420p. Clues? [17:43:12 CET] <ac_slater> And, I do see the logging where a scaler is created for yuv420p [17:43:37 CET] <ac_slater> oh, I'm on HEAD/trunk [17:43:37 CET] <wm4> Daemon404: maybe it's faster [17:43:39 CET] Action: wm4 hides [17:43:46 CET] <wm4> ac_slater: you're testing this with ffmpeg.c? [17:43:52 CET] <ac_slater> wm4: yes [17:43:58 CET] <ubitux> Daemon404: one less character :p [17:43:58 CET] <Daemon404> wm4, sounds akin to using gcc's likely/unlikely [17:44:01 CET] <Daemon404> i.e. dumb [17:44:26 CET] <ac_slater> wm4: I can paste a long. The input source is v4l2... so I'm testing with some rawvideo and other input formats too. [17:44:32 CET] <ac_slater> log* [17:45:40 CET] <ubitux> likely/unlikely makes no sense here, av_builtin_constant_p() is not evaluated at runtime [17:45:50 CET] <ubitux> so it just doesn't make a difference [17:47:09 CET] <cone-559> ffmpeg 03Clément BSsch 07master:e8bc642202c1: lavu: add AV_CEIL_RSHIFT and use it in various places [17:47:10 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:dbbfbde085b8: Merge commit 'e8bc642202c10beda1ea4e93ec8492b1e39805e5' [17:47:31 CET] <kierank> anyone want to say something at fosdem, there is a free slot? [17:48:29 CET] <cone-559> ffmpeg 03Kieran Kunhya 07master:46350db737a1: get_bits: Support max_depth > 2 in GET_RL_VLC_INTERNAL [17:48:30 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:711dae575d80: Merge commit '46350db737a15910f468d30cf7beda16a4cc8332' [17:48:49 CET] <ac_slater> wm4: http://paste.debian.net/plain/371265 [17:49:31 CET] <durandal_1707> kierank: me! [17:51:20 CET] <cone-559> ffmpeg 03Vittorio Giovara 07master:81737f42c288: sunrastenc: Properly load codec private options [17:51:21 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:9f18be42f0af: Merge commit '81737f42c28858dad76a40284a35f7a64faa2fc7' [17:53:57 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07master:62825236dba3: lavc: Add get_bitsz() [17:53:59 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:71b79b587bc1: Merge commit '62825236dba31a2240e25974a3ba41c1303e4edc' [17:54:12 CET] <Daemon404> so many noops [17:54:56 CET] <jamrial> code already in our tree, or code that doesn't apply in our tree at all? [17:55:23 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07master:fa66237b69c2: lavc: Use get_bitsz where needed [17:55:24 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:e5fe75ae2bd4: Merge commit 'fa66237b69c27befa788b100e73783e0f47fe1b7' [17:55:32 CET] <Daemon404> jamrial, former mostly [17:55:36 CET] <Daemon404> ot rewrites of teh former [17:55:39 CET] <Daemon404> that do nothing [17:58:02 CET] <cone-559> ffmpeg 03Anton Khirnov 07master:521dc78366c6: mux: drop the warning about global headers [17:58:03 CET] <cone-559> ffmpeg 03Anton Khirnov 07master:9cce011b1d2f: movenc-test: stop setting the GLOBAL_HEADER codec flag [17:58:04 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:895b888f1606: Merge commit '521dc78366c6ea54b7b69426dab302a57231f81e' [17:58:05 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:257766a838c5: Merge commit '9cce011b1d2f66366f5d75a024c2a2f93dc2b589' [17:58:23 CET] <Daemon404> nevcairiel, you said i should skip the slew of commits to nvenc from anton? [18:13:31 CET] <nevcairiel> Our nvenc is vastly different, so I would say so [18:13:54 CET] <nevcairiel> Merging them in is practically impossible [18:14:13 CET] <durandal_1707> does it work? [18:15:17 CET] <Daemon404> nevcairiel, i dont know enough about ours to know if we should add some of teh stuff elenril adds or not [18:15:21 CET] <Daemon404> like dts generation [18:15:32 CET] <Daemon404> (note: add, not merge) [18:15:47 CET] <ubitux> just say in the commit merge you're nooping it, and poke the maintainer [18:16:15 CET] <Daemon404> who is that for us? BtbN? [18:16:22 CET] <Daemon404> looks like it [18:16:24 CET] Action: Daemon404 pokes BtbN [18:16:47 CET] <BtbN> hm? [18:17:30 CET] <Daemon404> nvenc: generate dts properly [18:17:35 CET] <Daemon404> nvenc: fix encoding with B-frames [18:17:40 CET] <Daemon404> nvenc: flush the encoder before closing it, as required... [18:17:43 CET] <Daemon404> any useful for us? [18:17:49 CET] <BtbN> I might have a look at the libav nvenc encoder and copy over usefull stuff. [18:17:53 CET] <Daemon404> ok [18:17:55 CET] <BtbN> But I'm not aware of issues with dts and bframes [18:17:55 CET] <Daemon404> so i may skip merging? [18:18:05 CET] <BtbN> And we think I already do flush on close? [18:18:13 CET] <Daemon404> ok [18:18:23 CET] <BtbN> Just noop them, I'll look into it [18:18:27 CET] <Daemon404> https://git.libav.org/?p=libav.git;a=commitdiff;h=ee359c72ef8735122929da960… [18:18:30 CET] <Daemon404> what about this [18:18:32 CET] <Daemon404> this is more general [18:18:50 CET] <Daemon404> (also this seems pretty ridiculous) [18:19:22 CET] <BtbN> Seems kinds pointless, why rename it? [18:19:28 CET] <Daemon404> i know [18:19:31 CET] <BtbN> It already has multiple names [18:19:36 CET] <BtbN> because of libav... [18:19:49 CET] <Daemon404> yay... [18:19:55 CET] <Daemon404> ill have to pay close attention then [18:19:59 CET] <Daemon404> it's an api thing technically [18:20:53 CET] <cone-559> ffmpeg 03Anton Khirnov 07master:39571e86cb0d: nvenc: better error handling [18:20:53 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:a54422fff294: Merge commit '39571e86cb0d55536f649210a025c54e440c632b' [18:27:04 CET] <jamrial> if it's supposedly more consistent with other encoders, then why not? [18:27:50 CET] <Daemon404> lol wait... we already have that name [18:27:53 CET] <philipl> BtbN: On the subject of dts, have you tried using nvenc with, for example, a dvd transcode with deinterlacing and vfr? [18:27:55 CET] <Daemon404> so it doesnt even matter [18:34:28 CET] <Daemon404> wait no we dont [18:34:29 CET] <Daemon404> godamn [18:35:10 CET] <wm4> these codec names sure are confusing [18:36:41 CET] <Daemon404> ugh [18:36:51 CET] <Daemon404> apparently we didnt merge something or something [18:36:59 CET] <Daemon404> so it's all messed up trying to handle then ames correctly [18:38:38 CET] <Daemon404> yeah i see it... [18:39:15 CET] <nevcairiel> stuff diverges more and more, at some point soon we really should talk about the merging business again [18:39:16 CET] <Daemon404> ah i see it.... [18:39:20 CET] <Daemon404> it was libav tha twas confusing [18:39:36 CET] <Daemon404> +AVCodec ff_h264_nvenc_encoder = { [18:39:37 CET] <Daemon404> + .name = "nvenc_h264", [18:39:39 CET] <Daemon404> when it was dded [18:39:40 CET] <Daemon404> added* [18:39:44 CET] <Daemon404> no wonder i was confused [18:41:08 CET] <Daemon404> nevcairiel / BtbN - do we care enough to keep the names compatible [18:41:12 CET] <Daemon404> i can... it's just a pita [18:41:20 CET] <nevcairiel> we dont [18:41:43 CET] <BtbN> unless it comes with a propper aliasing system so it doesn't duplicate all the data structures each time, at least I don't. [18:44:35 CET] <Daemon404> ok [18:45:01 CET] <ac_slater> wm4: any chance you peeked at that log I sent? [18:45:07 CET] <ac_slater> ;) [18:45:47 CET] <wm4> ac_slater: I just saw that you used -pix-fmt [18:45:50 CET] <wm4> err -pix_fmt [18:46:09 CET] <ac_slater> wm4: but there is an auto-inserted scaler [18:46:12 CET] <ac_slater> I still need it? [18:46:23 CET] <cone-559> ffmpeg 03Anton Khirnov 07master:ee359c72ef87: nvenc: rename encoders [18:46:24 CET] <cone-559> ffmpeg 03Anton Khirnov 07master:aac7d6b284c3: nvenc: flush the encoder before closing it, as required by the docs [18:46:25 CET] <cone-559> ffmpeg 03Anton Khirnov 07master:9d36cab4c0dc: nvenc: fix encoding with B-frames [18:46:26 CET] <cone-559> ffmpeg 03Anton Khirnov 07master:c59fec783d65: nvenc: generate dts properly [18:46:28 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:42f0ed67a34d: Merge commit 'c59fec783d6540dd96540b079d753ee4a6ad2e58' [18:46:31 CET] <Daemon404> noops ahoy [18:46:57 CET] <wm4> ac_slater: the scaler is inserted because the input is not 420p, and you forced the format to 420p [18:47:50 CET] <ac_slater> wm4: interesting. I thought that would scale/convert automatically to 420p [18:48:26 CET] <wm4> whether or not it does isn't clear from your log anyway, but I expect that it does without -pix_fmt if the AVCodec fields are set [18:48:41 CET] <ac_slater> wm4: I see. So remove -pix_fmt ? [18:49:56 CET] <ac_slater> I tried and it does change anything. My resulting video is reporting 420p but the colors are all off [18:50:03 CET] <ac_slater> I guess that's VEDRY vague [18:50:05 CET] <ac_slater> VERT * [18:50:09 CET] <ac_slater> VERY * ... err [18:54:24 CET] <ac_slater> wm4: here is the output http://i.imgur.com/ERM8dQw.png ... I'm starting to think it's my encoder [18:55:07 CET] <wm4> maybe the linesizes are changing or so and your encoder doesn't handle it? [18:55:16 CET] <ac_slater> yea maybe [18:55:18 CET] <wm4> does the AVFrame you get have the correct format? [18:55:22 CET] <ac_slater> yea [19:04:51 CET] <durandal_1707> ac_slater: do you initialize chroma? [19:12:42 CET] <ac_slater> durandal_1707: I wish I knew what that meant [19:13:46 CET] <durandal_1707> ac_slater: using different linesize and width for chroma planes [19:14:21 CET] <durandal_1707> hard to guess without source code [19:14:44 CET] <ac_slater> durandal_1707: hmm I do not do that manually as I'm struggling to figure out exactly how my encoder expects input. It says "YUV420PackedPlanar" [19:15:09 CET] <ac_slater> I was thinking that was the output format, but I guess that's also the input format :( [19:15:28 CET] <durandal_1707> nonsense name for sure [19:15:49 CET] <durandal_1707> what's planar and what packed in it [19:16:01 CET] <ac_slater> no clue [19:16:17 CET] <ac_slater> :( durandal_1707 it's a raspberry pi2 and I'm using the OMX layer to encode [19:17:38 CET] <ac_slater> durandal_1707: apparently "YUV420PackedPlanar : packed per payload in planar slices" [19:17:47 CET] <ac_slater> more vagueness [19:18:34 CET] <ac_slater> durandal_1707: https://www.raspberrypi.org/forums/viewtopic.php?t=22019&p=208571 ... forth comment/reply [19:19:08 CET] <wm4> oh, you're messing with RPI [19:19:18 CET] <wm4> why not use MMAL? [19:19:25 CET] <ac_slater> wm4: undocumented :( [19:19:30 CET] <wm4> rcombs still has an encoder patch for it around somewhere [19:19:46 CET] <ac_slater> ooo [19:19:57 CET] <wm4> well just get into contact with popcornmix or so if you have questions about MMAL [19:20:07 CET] <ac_slater> I could use that. But, my OMX encoder is working minus the issue with yuv output [19:20:15 CET] <wm4> (he's maintaining parts of it and tends to be friendly and helpful) [19:20:40 CET] <ac_slater> ah the xbmc guy [19:20:58 CET] <wm4> yeah, he also works for broadcom [19:21:01 CET] <wm4> or something [19:21:14 CET] <ac_slater> very awesome [19:21:58 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07master:2884cf205a9a: on2avc: limit number of bits to 30 in get_egolomb [19:21:59 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07master:5b83b24ccbec: nuv: sanitize negative fps rate [19:22:00 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07master:8431629dd112: xwddec: prevent overflow of lsize * avctx->height [19:22:01 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07master:9cdddb93bb33: nutdec: only copy the header if it exists [19:22:02 CET] <cone-559> ffmpeg 03Andreas Cadhalpun 07master:b06cb15b9d79: dca: fix misaligned access in ff_dca_convert_bitstream [19:22:03 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:66eb8ce473e7: Merge commit 'b06cb15b9d7928bf54b639c9f9f7658c2c38bfb9' [19:22:08 CET] Action: kierank uses 422 specifically to break silly people on rpis [19:22:33 CET] <ac_slater> kierank: pis are silly, but they're the cheapest device I could find with an h264 encoder [19:22:50 CET] <kierank> they aren't silly [19:23:08 CET] <kierank> but people trying to use them instead of proper broadcast decoders are [19:23:17 CET] <ac_slater> agreed [19:24:16 CET] <ac_slater> kierank: since you know about 422, any idea how to unpack the Pi's 420PackedPlanar? ;) [19:25:14 CET] <wm4> "packedplanar" sounds so nonsense [19:25:21 CET] <wm4> maybe they mean nv12? [19:25:33 CET] <ac_slater> wm4: I think since the call it that it's not like any other formats [19:25:58 CET] <ac_slater> wm4: the link I posted has a broadcom guy explaining how it's laid out [19:27:36 CET] <cone-559> ffmpeg 03Diego Biurrun 07master:4f22b138886e: x86: ac3dsp: Drop forward declaration for nonexisting function [19:27:37 CET] <cone-559> ffmpeg 03Diego Biurrun 07master:03ef89faf23c: x86: build: Group all encoder objects together [19:27:38 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:ea2df330525c: Merge commit '4f22b138886e29f7fffa8c715673951e51be9f32' [19:27:39 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:d97a6193c323: Merge commit '03ef89faf23c4851848208c9fe004cd9ef690cec' [19:29:41 CET] <cone-559> ffmpeg 03Michael Niedermayer 07master:09f4822e4eaf: flvdec: perform duration search just once [19:29:42 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:949d6dd51ce1: Merge commit '09f4822e4eaf61513b9092414450f3ae920ccd9d' [19:30:29 CET] <ac_slater> Anyone have a clue on how to manually extra Y,U, and V from 420p? [19:31:10 CET] <kierank> ac_slater: download pyuv and play with the settings until they look right [19:31:57 CET] <ac_slater> kierank: nice, pyuv from 2008. Dang [19:34:11 CET] <ac_slater> kierank: ah, I see the github repo [19:43:35 CET] <ac_slater> kierank: unfortunately, none of the things pyuv does can adjust for packed yuv [19:43:39 CET] <ac_slater> unpacked? [19:43:57 CET] <kierank> who knows how it's packed [19:44:09 CET] <kierank> the only other way is to just make files [19:44:22 CET] <cone-559> ffmpeg 03Martin Storsjö 07master:e4eb13ca7762: flvdec: Add sanity checking of the last packet size [19:44:23 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:e5b5676c0085: Merge commit 'e4eb13ca77624401ea7cef1ed6ad8e2d13fd2063' [19:44:59 CET] <ac_slater> kierank: once I figure out how to get each channel from yuv420p, I can start playing with the packing [19:45:26 CET] <kierank> yuv420p is just one big y plane and 2 subsampled uv [19:46:03 CET] <durandal_1707> ac_slater: for extracting there is extractplanes filter [19:46:12 CET] <ac_slater> but how large are the planes? I know almost nothing about yuv [19:46:19 CET] <ac_slater> durandal_1707: interesting [19:47:06 CET] <durandal_1707> u plane is quarter of y plane [19:47:36 CET] <durandal_1707> or 1/16 [19:47:49 CET] <wm4> ac_slater: the link describes it as yuv420p [19:47:59 CET] <wm4> except that there are restrictions on how it's laid out in memory [19:48:06 CET] <ac_slater> exactly [19:48:19 CET] <wm4> apparently it needs exact line size, and all planes in the same buffer with no offset between [19:48:37 CET] <ac_slater> right, that's my understanding too [19:48:40 CET] <wm4> you generally won't get it this way in the encoder, but copying the planes is trivial [19:49:16 CET] <ac_slater> wm4: I'm restricting my input format to be 420p, so once I figure out how to extract the planes, then lay them out contiguously, we're oglden [19:50:33 CET] <wm4> the planes are already "extracted", each AVFrame.data[n] pointer points to plane n [19:50:38 CET] <durandal_1707> have you any C skills read others simple encoders [19:51:01 CET] <ac_slater> durandal_1707: yea yea ;) [19:52:10 CET] <ac_slater> wm4: so [0] = Y, [1] = U , [2] = V on my input image? [19:52:14 CET] <ac_slater> AVFrame* [19:52:25 CET] <durandal_1707> Yes [19:52:25 CET] <wm4> yes [19:52:31 CET] <ac_slater> thanks guys [19:52:38 CET] <wm4> for yuv420p [19:52:50 CET] <ac_slater> right. And the size of each plane is determined how? [19:53:05 CET] <durandal_1707> see also linesize of each plane [19:53:33 CET] <wm4> linesize is how many bytes you need to add to the plane pointer to get to the next vertical line of pixel [19:54:03 CET] <wm4> the rest is up to the width and height fields, and what pixel format you're using [19:54:55 CET] <ac_slater> durandal_1707: thanks mate [19:58:51 CET] <durandal_1707> does vlc have some demuxers we can steal? [20:01:36 CET] <kierank> durandal_1707: you can fuzz cfhd if you want :) [20:02:27 CET] <durandal_1707> no, I trust its author skills :P [20:03:08 CET] <durandal_1707> I don't have all the samples and its not commited [20:03:10 CET] <ac_slater> wm4: hmm I'm struggling with this. So If I wanted the Nth line of Y, I would do, `nth_y = frame->data[0] + (frame->linesize[0] * n);` ? [20:03:23 CET] <wm4> ac_slater: yeah [20:03:30 CET] <ac_slater> thanks mate [20:03:49 CET] <durandal_1707> np bro :) [20:04:08 CET] <ac_slater> wm4: just checking, same for U and V ? [20:04:30 CET] <wm4> yes, but be aware that they're half the size [20:07:27 CET] <kierank> durandal_1707: can send you samples if you want [20:07:41 CET] <durandal_1707> I wanted to write utvideo decoder asm [20:08:05 CET] <durandal_1707> kierank: how much large? [20:08:43 CET] <kierank> durandal_1707: not large [20:08:59 CET] <ac_slater> wm4: alright great. Last thing, Y=320, U=160, V=160 (linesizes)... when I do avpicture_get_size(frame->format, w, h), I get 115200. But, 320*160*2 is 102400 [20:09:22 CET] <ac_slater> wrong function, or rounded up maybe [20:09:46 CET] <wm4> it aligns the lines and start pointers [20:09:53 CET] <wm4> maybe [20:10:03 CET] <wm4> also avpicture_... is deprecated [20:10:20 CET] <durandal_1707> isn't AVPicture deprecated [20:10:53 CET] <wm4> hm it calls av_image_get_buffer_size with align=1 [20:11:46 CET] <wm4> ac_slater: what are the image dimensions? [20:11:58 CET] <ac_slater> 320x240 [20:12:47 CET] <ac_slater> av_image_get_buffer_size() with align=1 returned the same size as the avpicture call obviously. Still 115200 [20:13:03 CET] <wm4> 320*240+2*320/2*240/2==115200 [20:13:10 CET] <ac_slater> ohhh [20:13:38 CET] <wm4> right, I see you say the line sizes are 160 for chroma [20:14:01 CET] <wm4> so the chroma planes are padded by 40 bytes [20:14:08 CET] <wm4> err [20:14:23 CET] <wm4> they're not padded, well whatever [20:16:37 CET] <ac_slater> wm4: I see... so (W*H + W * H/2) ... magic [20:28:23 CET] <cone-559> ffmpeg 03Matthieu Bouron 07master:0d733ec3794d: lavc/mjpegdec: speed up scan data copy [20:30:31 CET] <cone-559> ffmpeg 03Luca Barbato 07master:8fd361f53b3c: configure: Use pkg-config to check for openssl [20:30:32 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:bd7da0ae7b6b: Merge commit '8fd361f53b3c17c1ae13a39e030c8fa3ab4d8f1f' [20:33:05 CET] <cone-559> ffmpeg 03Luca Barbato 07master:c4de754d4dac: mathops: mips: Correctly enable loongson-specific assembly [20:33:05 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:ba7d16a30353: Merge commit 'c4de754d4dac5ddae4d5a6f02798c0f560771921' [20:34:03 CET] <cone-559> ffmpeg 03Luca Barbato 07master:e59708bb9d94: configure: mips: Support both-endian compilers [20:34:04 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:f97d2d210553: Merge commit 'e59708bb9d94f67381f19344b5e021591eb711bf' [20:41:05 CET] <cone-559> ffmpeg 03Arttu Ylä-Outinen 07master:7486418683bd: lavc: Make sure that the effective timebase would not overflow [20:41:06 CET] <cone-559> ffmpeg 03Arttu Ylä-Outinen 07master:472d488ebcc5: libkvazaar: Set frame rate as a rational number [20:41:07 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:e87ace6246fc: Merge commit '7486418683bd2477772e03aab573cf846c12fb0d' [20:41:07 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:7daad5c44145: Merge commit '472d488ebcc53bea4cdb124edb94558e72d8f23f' [20:42:05 CET] <cone-559> ffmpeg 03Vittorio Giovara 07master:e9175634ec96: yuv2rgb: Document the color space coefficients [20:42:06 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:fafb18d14654: Merge commit 'e9175634ec96e36873929637491189150cfce9ec' [20:42:33 CET] <Daemon404> noop noop noop [20:48:42 CET] <wm4> the yuv2rgb coefficients were documented already? [20:53:13 CET] <cone-559> ffmpeg 03Luca Barbato 07master:8e7bea6dc6ac: configure: Improve requesting specific features [20:53:14 CET] <cone-559> ffmpeg 03James Darnley 07master:883ad2c59cee: fate: add 10-bit v210 encoder tests [20:53:15 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:65d29dd274a3: mov: Add an option to toggle dref opening [20:53:16 CET] <cone-559> ffmpeg 03Luca Barbato 07master:e93aa2c9e7b3: configure: Force-enable select_any dependencies only on --enable [20:53:17 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:3de3937ecdd5: Merge commit '8e7bea6dc6ac5b21484774a026847bec0771ab62' [20:53:18 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:b3702b6b660e: Merge commit '883ad2c59ceea1ced5495b5ccc83695ed4bbb94b' [20:53:19 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:97d57424344f: Merge commit '65d29dd274a302131e2e4bc6d2b1eca4a093900c' [20:53:20 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:3662e55943d3: Merge commit 'e93aa2c9e7b3599aee6a5820760fc1a2c629dea0' [20:53:26 CET] <Daemon404> wm4, yes [20:53:29 CET] <Daemon404> same patch even [20:53:56 CET] <J_Darnley> Hey look. There I am again. [20:54:05 CET] <nevcairiel> your noop merges are weird, you should leave the reference which commit you skipped in the message =p [20:54:13 CET] <J_Darnley> (which reminds me, I need to look for more replies) [20:54:37 CET] <Daemon404> nevcairiel, i need to change my default merge settings [20:54:41 CET] <Daemon404> to list commits [20:54:50 CET] <nevcairiel> thats default for me [20:54:56 CET] <Daemon404> not me for some reason [20:55:01 CET] <Daemon404> man git-merge didnt show me much [20:55:05 CET] <Daemon404> it's not very searchable [20:56:32 CET] <Daemon404> --log [20:56:35 CET] <Daemon404> not sure what it is on git config [20:57:05 CET] <cone-559> ffmpeg 03Vittorio Giovara 07master:9d3ea5cbf57e: imgconvert: Drop outdated comment block [20:57:06 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:54f49bd3781c: Merge commit '9d3ea5cbf57e30bf2717a9ce64e858dad8a02aa6' [20:57:11 CET] <Daemon404> now with 100% more log [20:57:15 CET] <J_Darnley> That's the good thing about git. Config is somehow seprate from the programs it affects. [20:57:27 CET] <Daemon404> :D [20:59:32 CET] <BBB> nevcairiel: tired of merging already? :D [20:59:40 CET] <Daemon404> BBB, may as well split the load [20:59:46 CET] <Daemon404> otherwise killign sprees etc [21:00:18 CET] <BBB> some people have claimed we make libav relevant by merging their commits [21:00:23 CET] <nevcairiel> Daemon404: i use this script http://pastebin.com/TKtQwURs .. so i guess i added --log [21:00:38 CET] <BBB> or, inversely, libav becomes irrelevant if we stop merging [21:01:04 CET] <cone-559> ffmpeg 03Vittorio Giovara 07master:892f037c55d8: imgconvert: Move the shrink functions only where needed [21:01:05 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:fa48cd8814e7: Merge commit '892f037c55d86ce36f8705fbeab052189312a13e' [21:01:31 CET] <Daemon404> i dont buy into either of those [21:04:14 CET] <Daemon404> hmm... i wonder if kierank will murder me if i merge this deprecation commit [21:04:19 CET] <Daemon404> for avcodec_get_chroma_sub_sample [21:04:27 CET] <Daemon404> does it have a replacement? [21:04:30 CET] <wm4> isn't there a libavutil equivalent [21:04:33 CET] <nevcairiel> avutil one i think [21:04:43 CET] <wm4> av_pix_fmt_get_chroma_sub_sample [21:04:47 CET] <cone-559> ffmpeg 03Vittorio Giovara 07master:f7168d7016f7: imgconvert: Move AVPicture-related static function to the deprecated section [21:04:48 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:fa6c7ccc20d3: Merge commit 'f7168d7016f7d1034ec90223fa91a90711704e11' [21:04:55 CET] <Daemon404> wm4, ic [21:05:06 CET] <kierank> ok [21:05:14 CET] <kierank> so we now have 3 subsample functions [21:05:41 CET] <Daemon404> looks more like were going to remove the old ones? [21:06:03 CET] <kierank> ok [21:06:23 CET] <Daemon404> https://git.libav.org/?p=libav.git;a=commitdiff;h=d43a165bda0eae95f4c7a168c… [21:06:27 CET] <Daemon404> the commit in question [21:06:58 CET] <Daemon404> so just s///? [21:09:31 CET] <cone-559> ffmpeg 03Piotr Bandurski 07master:7c4059ae1e96: riff: add YUYV FourCC (Drastic YUYV) [21:09:32 CET] <cone-559> ffmpeg 03Vittorio Giovara 07master:d43a165bda0e: imgconvert: Add the proper API guards to a deprecated function [21:09:33 CET] <cone-559> ffmpeg 03Piotr Bandurski 07master:55c7e5bf7c8d: riff: add C210 FourCC (Canopus C210) [21:09:34 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:e15e10888534: Merge commit 'd43a165bda0eae95f4c7a168c7d13d94966c1a09' [21:09:35 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:11e6f13a1330: Merge commit '55c7e5bf7c8d368c9bc60a219b04849ec9f4c84c' [21:10:13 CET] <Daemon404> all the tribial merges done... now it's all koda api-changing stuff [21:11:22 CET] <Daemon404> most of them are moving avctx members to private options [21:11:29 CET] <Daemon404> i dont know if ffmpeg people have opinions on those or not. [21:13:03 CET] <wm4> generally sounds like a good idea [21:13:08 CET] <durandal_1707> those are ok, moving stuff where it really belongs [21:13:13 CET] <Daemon404> i agree [21:13:15 CET] <Daemon404> but there's uh [21:13:17 CET] <Daemon404> special people [21:13:19 CET] <Daemon404> around ffmpeg [21:13:22 CET] <Daemon404> when ti comes to giant structs [21:13:24 CET] <Daemon404> so... [21:13:29 CET] <wm4> just look out for decoders which use them and which are not in libav [21:13:38 CET] <Daemon404> of course [21:13:48 CET] <Daemon404> i just dont want to get HEY MR D404 WHY U MERGE EVIL [21:14:21 CET] <wm4> they'd post patches to revert it [21:14:32 CET] <Daemon404> true [21:14:32 CET] <wm4> while calling you evil [21:18:07 CET] <durandal_1707> anybody against dvaudio parser? [21:18:27 CET] <Compn> parser is required then ? [21:21:17 CET] <cehoyos> Daemon404: Hi, your merges broke --disable-everything. Could you revert? [21:21:38 CET] <cone-559> ffmpeg 03Vittorio Giovara 07master:0e6c85322157: lavc: Move b_frame_strategy and b_sensitivity to codec private options [21:21:39 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:2e9b995e4f7f: Merge commit '0e6c8532215790bbe560a9eea4f3cc82bb55cf92' [21:21:51 CET] <Daemon404> cehoyos, define broke [21:21:53 CET] <Compn> cehoyos : i think Daemon404 would rather ask for patch to fix --disable-everything instead of reverting , if thats ok with you cehoyos [21:21:57 CET] <Daemon404> it was supposed to change its behavior [21:22:20 CET] <Daemon404> unless it broke in some unintended way [21:22:25 CET] <cehoyos> Then please revert the behaviour change: This is a very important function, it should not be broken without any warning. [21:22:37 CET] <Daemon404> first tell me how it broke [21:22:43 CET] <Daemon404> im not going to blindly revert withotu more info [21:22:48 CET] <cehoyos> ./configure && make ffmpeg [21:22:53 CET] <cehoyos> Used to work, does not work anymore [21:23:01 CET] <Daemon404> uh? [21:23:03 CET] <cehoyos> Sorry, please ignore [21:23:14 CET] <cehoyos> ./configure --disable-everything && make ffmpeg [21:23:25 CET] <cehoyos> This is broken since your configure merges. [21:24:18 CET] <Daemon404> theres a uh... i might have broke it differently [21:24:19 CET] <Daemon404> ./libavcodec/version.h:20:0: error: unterminated #ifndef #ifndef AVCODEC_VERSION_H [21:24:22 CET] <Daemon404> this is why i see [21:25:32 CET] <Daemon404> let me fix this then i will test [21:25:37 CET] <cehoyos> Please revert before doing other commits: This is extremely annoying and --disable-everything is a very important option for bug tracking. [21:25:38 CET] <Daemon404> too many screwups! [21:25:58 CET] <wm4> why is it important for bug tracking? [21:26:11 CET] <cehoyos> I cannot work on bug reports without it [21:26:24 CET] <wm4> for what reason? [21:26:26 CET] <cehoyos> OR how do you do regression tests? [21:26:43 CET] <Compn> wm4 asks why not just use ffmpeg iwth all features enabled to do regression testing ? [21:27:03 CET] <cehoyos> Because even my time is unfortunately not unlimited;-(( [21:27:13 CET] <Compn> too long to compile ? [21:27:27 CET] <wm4> hm could make sense for bisecting I guess [21:27:40 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:5889bc16a4f6: avcodec/version: Add missing #endif [21:27:56 CET] <Daemon404> ok now to look at disable-everything [21:28:07 CET] <Compn> (cough: last commit fixes broken build) [21:28:54 CET] <nevcairiel> there is a commit on the libav ml to restore disable-everything behavior [21:29:00 CET] <nevcairiel> but i dont think they pushed it yet [21:29:38 CET] <Daemon404> i will revert [21:29:41 CET] <nevcairiel> but maybe you can steal it if it fixes everyhting [21:29:43 CET] <Daemon404> and re-merge once it is fixed [21:29:44 CET] <Daemon404> properly [21:29:51 CET] <cehoyos> Thank you! [21:29:52 CET] <Daemon404> no ill wait until its properly un-screwed [21:33:53 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:cefad29df93a: configure: Revert recent changes to disable-everything [21:34:06 CET] <Daemon404> ^ cehoyos [21:34:46 CET] <jamrial> msvc is broken again [21:34:56 CET] <Daemon404> jamrial, surely not from me though! [21:35:14 CET] <Daemon404> unles it was the avcodec issue [21:35:23 CET] <nevcairiel> no its the mjpeg change [21:35:28 CET] <nevcairiel> ssize_t is not available [21:35:38 CET] <cehoyos> Thank you! Are you the new maintainer? [21:35:40 CET] <jamrial> whoops, this window didn't scroll and i missed the above discussion [21:35:58 CET] <Daemon404> cehoyos, i am helping out nevcairiel because he wanted a break [21:36:12 CET] <cehoyos> Why don't we all break from these merges? [21:36:21 CET] <Daemon404> not touching that with a 10 foot pole [21:36:26 CET] <cehoyos> Or probably "take a break"... [21:36:42 CET] <Daemon404> nevcairiel, indeed [21:38:59 CET] <Daemon404> ssize_t length = (ptr - src) - (skip); [21:39:03 CET] <Daemon404> shoulnt this be ptrdiff_t [21:40:37 CET] <nevcairiel> probably [21:41:22 CET] <jamrial> and in any case better than ssize_t considering it's apparently not available on msvc [21:41:44 CET] <Daemon404> what's the usecase of ssize_t anyway [21:41:55 CET] <Daemon404> pls dont say returning -1 as error for size_t returnign funcs [21:41:56 CET] <rcombs> Daemon404: size_t for functions that might return a negative error code [21:42:00 CET] <Daemon404> god dammit [21:42:28 CET] <Daemon404> i thought that might be the case... but ew. [21:42:40 CET] <JEEB> :3 [21:42:47 CET] <wm4> better than returning (size_t)-1 [21:42:52 CET] <wm4> or (void*)-1 [21:42:56 CET] <rcombs> hey you asked [21:43:32 CET] <rcombs> wm4: the OS X standard lib has at least one case of assigning special values to pointers between 0 and& 4, I think? [21:44:03 CET] <wm4> *shrug* [21:44:18 CET] <wm4> usually osx has windows-style error codes [21:44:25 CET] <michaelni> make libavformat/seek-test -> tls_openssl.c:(.text+0x9e3): undefined reference to `SSL_ctrl' [21:44:28 CET] <wm4> one big namespace for EVERYTHING [21:44:34 CET] <michaelni> and lots of other errors [21:45:02 CET] <Daemon404> michaelni, i reverted the changes that touched the ssl stuff in configure [21:45:04 CET] <Daemon404> did you pull since then [21:45:59 CET] <rcombs> http://www.opensource.apple.com/source/dyld/dyld-96.2/include/dlfcn.h has a few `((void*)-1)` and such [21:46:21 CET] <Daemon404> michaelni, oh... i see... its fixed later on in libav [21:46:33 CET] <Daemon404> of course, after the giant wall of tedious-to-merge commits [21:46:47 CET] <Daemon404> michaelni, https://git.libav.org/?p=libav.git;a=commit;h=c0c4d7a0a556ec66e3068d36a883e… [21:46:51 CET] <wm4> rcombs: ah, terrible, looks like it might be posix [21:47:07 CET] <rcombs> implementation-defined special pointer values [21:47:33 CET] <jamrial> Daemon404: in our case we have use_pkg_config, which they don't [21:47:51 CET] <jamrial> i can update the configure check with that right now, and then you just noop that commit [21:47:58 CET] <Daemon404> jamrial, go for it [21:48:11 CET] <Daemon404> i wont be finishing a giant set of api commits today. [21:49:39 CET] <Daemon404> michaelni, see ^ [21:50:42 CET] <jamrial> ok, one sec while i test it [21:53:43 CET] <Daemon404> nevcairiel clearly should have warned me about different people's patches =p [21:53:47 CET] Action: Daemon404 runs [21:54:37 CET] <Daemon404> no more merges today [21:55:39 CET] <mateo`> nevcairiel, Daemon404: is ptrdiff_t available on msvc ? [21:56:35 CET] <Daemon404> michaelni, it is since 2010 or so [21:56:42 CET] <Daemon404> and for older versions we requrie msinttypes [21:56:44 CET] <Daemon404> which has it [21:56:45 CET] <nevcairiel> mateo`: yes thats fine [21:56:46 CET] <Daemon404> er mateo` [21:59:23 CET] <cone-559> ffmpeg 03James Almer 07master:09d5c28c3dc4: configure: fix openssl pkg-config check [21:59:27 CET] <jamrial> michaelni: ^ [22:02:42 CET] <jamrial> also, libavcodec/options-test is throwing a Floating point exception since a couple commits ago [22:02:55 CET] <jamrial> http://fate.ffmpeg.org/report.cgi?time=20160127201034&slot=x86_64-freebsd8.… [22:03:12 CET] <Daemon404> of all the breakage [22:03:14 CET] <Daemon404> that one is unexpected [22:03:33 CET] <jamrial> http://git.videolan.org/?p=ffmpeg.git;a=shortlog;h=78133-g54f49bd;hp=78110-… one of these merges [22:03:51 CET] <mateo`> nevcairiel, Daemon404: i've sent the fix to the ml, (i just ran fate + tested the sample michael provided) [22:03:52 CET] <Daemon404> most of those are noops [22:04:25 CET] <Daemon404> jamrial, i cant see anything there that would cause an FPE... [22:06:07 CET] <jamrial> commit e87ace6246fc6528a9a8304abdb81858c70cefb7 is the culprit [22:06:58 CET] <jamrial> "avctx->ticks_per_frame > INT_MAX / avctx->time_base.num" maybe? [22:07:40 CET] <Daemon404> yeah [22:07:45 CET] <Daemon404> thats the only thing i see [22:07:49 CET] <Daemon404> but wouldnt that be integer division? [22:09:36 CET] <Daemon404> gdb... [22:09:48 CET] <jkqxz> Integer-divide-by-zero is undefined behaviour in C. Lots of people choose "raise SIGFPE" as their undefined thing to do. [22:10:05 CET] <Daemon404> ah yes. [22:10:09 CET] <Daemon404> avctx->time_base.num may be 0. [22:10:19 CET] <Daemon404> den wont bem but num may be [22:11:53 CET] <Daemon404> yes that fixes it [22:11:57 CET] <Daemon404> sendign a patch to ML. [22:52:54 CET] <jya> BBB: for your ffvp9 comparison, while of course you can compare chrome vs firefox. If you want to directly compare libvpx vs ffvp9 ; the best would be to use the flag media.ffvpx.enable and change between true or false. To get Firefox to use vp9 in Youtube, you need to set media.mediasource.webm.enabled to true (it is off by default at present, we only turn [22:52:54 CET] <jya> it on if the OS doesn't have a h264 decoder or if we find that h264 hardware decoding doesn't work (because the graphic cards is black listed) [22:53:38 CET] <BBB> Im pretty sure I dont have h264 decoding hw [22:54:04 CET] <BBB> and although libvpx-vs-ffvp9-in-firefox is fun, wouldnt it be much better to make fun of chrome? ;) [22:56:52 CET] <nevcairiel> how do you even properly benchmark a browser [22:58:09 CET] <BBB> cpu usage is 50% cpu usage is 70% its different!!112" [22:58:19 CET] <BBB> (when playing the same youtube video) [22:58:29 CET] <TD-Linux> alternately, measure power draw [22:58:36 CET] <jya> BBB: the way I've done it is in youtube [22:58:48 CET] <jya> if you right click on the video, you see "stats for nerds" [22:58:49 CET] <nevcairiel> Daemon404: you should push that diff-by-zero patch, half of fate is turning yellow [22:59:14 CET] <jya> it will show you the current resolution , how many frames have been decoded and more importantly how many frames have been dropped [22:59:32 CET] <nevcairiel> "both managed to play the video without dropping frames", hooray =p [22:59:58 CET] <jamrial> yeah, assuming both decoders don't tax the cpu, that will not let you know which is faster [23:00:27 CET] <jya> comparing libvpx vs ffvp9 (as to be fair it's the only thing that we're really comparing). If found that on a low end HP laptop (a $500 i3 quadcore). Where we could do only 720p with libvpx [23:00:35 CET] <jya> we could do 1440p with ffvp9 [23:00:49 CET] <jya> now it's a bit silly test because that laptop has a 1360x768 screen only [23:01:04 CET] <BBB> :D [23:01:23 CET] <BBB> you can spend the saved cpu on downscaling the image in software [23:01:27 CET] <jya> but that was still interesting to test purely on the CPU level. That laptop has HW VP9 [23:01:36 CET] <cone-559> ffmpeg 03Derek Buitenhuis 07master:265ed6732fbd: libavcodec/util: Fix timebase overflow check [23:02:18 CET] <jya> however, with those intel drivers, VP9 was buggy and a fewtimes I hard to restart the computer (because chrome *will* use hardware vp9 decoding if available, regardless of how buggy that stuff is [23:02:19 CET] <nevcairiel> Intel doesn't have a full hw vp9 decoder, sorry no cookies :D [23:02:44 CET] <nevcairiel> its hybrid and slow [23:02:46 CET] <jya> nevcairiel: it's partially accelerated. and the decoding is done via their WMF drivers [23:03:05 CET] <nevcairiel> nvidia are the only ones with a full vp9 decoder, which is actually fast [23:03:07 CET] <jya> as opposed to being decoded in either libvpx or ffvp9 [23:03:29 CET] <Daemon404> didnt the hybrid one use just as much cpu [23:03:34 CET] <Daemon404> and was slower [23:03:34 CET] <jya> yeah, but currenly only on linux via vdpau. [23:03:45 CET] <nevcairiel> its less cpu, but slower [23:04:11 CET] <nevcairiel> jya: windows dxva vp9 works fine, i wrote it for ffmpeg afterall [23:04:17 CET] <jya> Daemon404: actually not my finding, CPU usage playging vp9 on youtube was fairly low. it's just unstable. From time to time, no more video frames come out and you must power cycle the laptop [23:04:56 CET] <jya> anyhow, that's not what I wanted to talk about, getting sidetracked. [23:05:18 CET] <jya> BBB: on a dual core, the difference between ffvp9 and libvpx were less obvious. [23:05:28 CET] <Daemon404> jya, sounds like a pleasant experience? >_> [23:05:45 CET] <BBB> jya: on a typical machine, ffvp9 should be 30-40% faster from what I recall [23:05:47 CET] <jya> when comparing chrome vs firefox in youtube using the "Stats for Nerds" there's one thing I've noticed [23:06:02 CET] <BBB> as in, it used to be 40% faster but libvpx copied some of our approaches so now its 30% [23:06:15 CET] <nevcairiel> BBB: is that single threaded? [23:06:21 CET] <nevcairiel> I would think MT adds a lot more [23:06:22 CET] <BBB> yes [23:06:25 CET] <jya> we (firefox) attempt to keep audio at all time, we will drop video frames or skip to the next keyframes when video decoding is really behind so that audio is perfect [23:06:52 CET] <jya> chrome on the other hand, just pause the whole lot, start decoding in a loop, and when it has enough video frames will resume. [23:07:16 CET] <jya> so the experience watching 4K on those low end laptop is that on Firefox, you only get the audio perfectly with a few video keyframe showing [23:07:24 CET] <jya> while chrome will jsut pause ever 3-4s [23:07:37 CET] <nevcairiel> not sure if either is any better [23:07:48 CET] <BBB> reminds me of realmedia [23:07:50 CET] <BBB> "buffering" [23:07:53 CET] <jya> I don't know which approach is less sucky :) [23:07:55 CET] <nevcairiel> personally i never bothered to really "work" on bad performance situations [23:07:58 CET] <Daemon404> i must ask [23:08:01 CET] <Daemon404> why even do that [23:08:06 CET] <Daemon404> such a low end laptop wont even have a 4k screen [23:08:08 CET] <Daemon404> or even 2k [23:08:18 CET] <jya> Daemon404: because you can ? [23:08:23 CET] <Daemon404> thats a terrible reason [23:08:56 CET] <jya> i've only been working at mozilla for 18 months, but what I've learnt there is that with such big user count. If there's something that can break it will [23:09:20 CET] <jya> so many times I've put a task aside because really this won't ever happen, it's just too dumb [23:09:20 CET] <nevcairiel> of course, users break everything [23:09:24 CET] <Daemon404> maybe i should start forwarding mozilla breakages to you from work (vimeo) [23:09:25 CET] <jya> without fail it will happen [23:09:27 CET] Action: Daemon404 runs [23:09:43 CET] <jamrial> on my old k10 dual core, ffvp9 could play 1080p <=30fps content whereas libvpx would struggle [23:09:46 CET] <jya> Daemon404: please do, we can only fix bugs if we know about them [23:09:52 CET] <Daemon404> jya, yeah i know [23:09:58 CET] <Daemon404> but bugzilla is ain to devnull [23:10:01 CET] <Daemon404> i speak from experience [23:10:02 CET] <Daemon404> akin* [23:10:13 CET] <jya> not if you set the proper group [23:10:21 CET] <jya> Core -> Audio/Video Playback [23:10:33 CET] <jya> the media team, while small is very reactive [23:11:28 CET] <jya> jamrial: yes, typically a 720p 30fps that play just with libvpx we could play the same video at 60fps with ffvp9 [23:12:41 CET] <jya> BBB: I'll add you to my spreadsheet with some of my results. those were done using ffvp9 form ffmpeg 2.8 [23:12:51 CET] <BBB> ok ty [23:13:51 CET] <jya> I have a video, on my mac pro I can play it in realtime with ffvp9 [23:14:09 CET] <jya> it takes 25s to play 10s using chrome [23:14:25 CET] <jya> 49s if libvpx isn't compiled with -O [23:15:40 CET] <Daemon404> jya, http://chromashift.org/ff/1frame.mp4 [23:15:50 CET] <Daemon404> seeking after video-end is broken [23:15:57 CET] <Daemon404> this file has audio for 1 min + 1 static frame [23:16:01 CET] <Daemon404> enjoy! [23:16:46 CET] Action: Daemon404 cant be arsed to make a Yet Another Bug Tracker Account at 10pm [23:16:50 CET] <jya> BBB: you can use this too. https://people.mozilla.org/~jyavenard/tests/frame-drop-test/ it will play bunny in various resolutions and display the number of frames dropped [23:17:06 CET] <jya> so now again, chrome cheat on the number because it almost never drop frames, it just pauses [23:18:09 CET] <jya> Daemon404: if it is what I think it is, we don't handle those videos (where you have a single video frames) [23:18:23 CET] <jya> dailymotion also have heaps of those music videos. [23:18:37 CET] <nevcairiel> its a bane of many video players [23:18:39 CET] <jya> Flash handled them perfectly, so they continue to use flash for those [23:19:24 CET] <jya> now if the video frame was marked as having a 1 minute duration that would probably work. but if the video has a short duration, then it will just stall [23:19:55 CET] <jya> and this is by spec. the buffered range of a media element, is defined as the intersection between the audio buffered range and the video track buffered range [23:20:10 CET] <Daemon404> jya, it happens on any video where audio rusn longer than video [23:20:17 CET] <Daemon404> you cant seek to any point past video [23:20:24 CET] <Daemon404> and this is a very common thing to have [23:20:30 CET] <Daemon404> (think, e.g. slideshows) [23:20:35 CET] <Daemon404> or screen captures [23:20:38 CET] <jya> I read this as: the buffered range is what we can actually play. If you have no audio or video at a particular point -> we stall it's not buffered [23:21:20 CET] <jya> Daemon404: that may well be the case for your default video player. but with html5 you have strict specifications and rules on how things are to behave. so I tag this as the file is broken [23:22:05 CET] <jya> try setting in the container the duration of the video frame to be the same as the duration of the entire video, and you'll find that it will work [23:22:51 CET] <Daemon404> how exactly do you defined "buffered range" [23:22:54 CET] <Daemon404> define* [23:23:41 CET] <Daemon404> for example: an mp4 has a timeline duration, which is separate from track duration [23:23:46 CET] <Daemon404> and which should be respected above those [23:23:49 CET] <Daemon404> (IMO) [23:24:17 CET] <jya> BBB: actually, it's already shared: https://docs.google.com/spreadsheets/d/1JvD7GJmr-Krk27sx9gv2tAeNGFYPxxy8kX2… [23:25:28 CET] <jya> https://html.spec.whatwg.org/multipage/embedded-content.html#dom-media-buff… [23:25:42 CET] <jya> "Users agents must accurately determine the ranges available, even for media streams where this can only be determined by tedious inspection." [23:25:54 CET] <jya> so the buffered range is calculated on what frames are available [23:26:02 CET] <jya> that's our "tedious inspection" [23:26:14 CET] <jya> let me check what we have for your video [23:26:31 CET] <Daemon404> i would argue the mvhd duration supercedes the track duration here [23:27:03 CET] <jya> i would say that neither apply, only the sample table [23:27:19 CET] <Daemon404> thats pretty much opposite of what mp4 says you should do [23:27:27 CET] <jya> where? [23:27:41 CET] <Daemon404> the specs are all behind paywalls [23:28:03 CET] <Daemon404> but it's the presentation layer that takes precedent almost always [23:28:10 CET] <Daemon404> (yes mp4 has such a thing) [23:28:17 CET] <TD-Linux> that spec actually sounds like it's referring to streaming containers like ts or ogg. [23:28:32 CET] <TD-Linux> it's ridiculous in general how the spec tries to avoid naming any containers though :( [23:28:33 CET] <Daemon404> TD-Linux, it reads quit vague to be TD-Linux [23:28:41 CET] <Daemon404> quite* [23:29:32 CET] <jya> Daemon404: if you tell me which part of the spec it is, I can have a look [23:29:53 CET] <Daemon404> i'd need to refer to Paranoialmaniac for a place in the spec [23:30:04 CET] <Daemon404> fwiw, firefox is the only browser which fails. [23:30:23 CET] <jya> Daemon404: closer inspection (ffprobe) of the file shows me that it has a single video frame: pts_time=0.000000 duration_time=0.042709 [23:30:33 CET] <Daemon404> it has a media duration [23:30:35 CET] <Daemon404> -show_format [23:30:41 CET] <Daemon404> the mvhd box has it set correctly [23:30:46 CET] <jya> so the buffered range for that video will always be [0, 0.042709] [23:30:51 CET] <Daemon404> youre nto listening [23:31:32 CET] <Daemon404> mp4 has both track duration and *full media* duration code.d [23:31:41 CET] <Daemon404> the latter of which represents the entire file. [23:31:43 CET] <jya> i am listening, I'm telling you on why you can't seek in those videos. video.seekable is [0, 0.042709] [23:31:58 CET] <Daemon404> sure. and im saying firefox does it wrong here. and is teh only browser to do so. [23:32:16 CET] <Daemon404> because the global duration is set correctly [23:32:18 CET] <jya> I'll argue we're doing it right, and all the other are wrong :D [23:33:41 CET] <jya> there are so many wrongly formatted mp4 files out there, that we just can't rely exclusively on the container. the only thing that's ever accurate is the actual data it contains [23:33:45 CET] <Daemon404> i can only disagree. the spec makes no mention of tracks, only "ranges of the media resource" [23:34:00 CET] <Daemon404> in mp4, the mvhd duration is the defacto range. [23:34:03 CET] <jya> just like we even stopped looking at the dimensions set in the mp4 and instead decode the SPS NAL [23:34:38 CET] <Daemon404> mp4 does not have an sps nal [23:34:40 CET] <Daemon404> it's a separate box [23:34:46 CET] <Daemon404> if you have an sps packet in an mp4, it is illegal. [23:34:47 CET] <jya> because almost all the time, people got it wrong between frame dimensions and display dimension: so they displayed with wrong aspect ratio [23:35:02 CET] <jya> you have it in the avcC atom [23:35:09 CET] <Daemon404> thats a box, not a NAL [23:35:14 CET] <jya> or if AVC3 in one of the sample [23:35:30 CET] <jya> yes, the avcC atom (mp4) contains a SPS NAL [23:35:37 CET] <jya> youre arguing semantics [23:35:38 CET] <Daemon404> nit: mp4s dont have atoms [23:35:40 CET] <Daemon404> only mov does ;P [23:35:45 CET] <Daemon404> in mp4 theyre boxes. [23:36:00 CET] <Daemon404> sure, but so are you [23:36:08 CET] <Daemon404> your linked spec does nothing to back you up either [23:36:08 CET] <jya> fine ... no point continuing then, this is leading nowhere [23:36:13 CET] <nevcairiel> Daemon404: if sps inband in mp4 is legal or not depends on which codec identifier is used [23:36:21 CET] <Daemon404> nevcairiel, very true [23:36:27 CET] <Daemon404> your are right. [23:37:36 CET] <Daemon404> jya, if you say so. you may stick to you "literally everyone else on earth is wrong" stance if you wish. You should learn about the presentation layer properly though at some point. [23:37:40 CET] <Daemon404> i wont bikeshed here anymore [23:37:44 CET] <jya> Daemon404: wants your video to play in firefox, have the duration of the video frame extend to where audio ends. simple. You'll also find that once you guy move to MSE, the behaviour I've described is even more correct [23:38:18 CET] <jya> because then your video won't play with any browsers out there at all, because they all enforce that rules [23:38:21 CET] <Daemon404> we have moved to mse ;) [23:38:36 CET] <Daemon404> but im talking progressive here [23:39:16 CET] <Daemon404> and you can keep parrottign the same "but teh video track duration is short!" nd ignore the resentation later, it doesnt really sell me on it. [23:39:19 CET] <jya> MSE has very clearly defined that buffered range == seekable attribute and is identical to the *frames* time [23:39:36 CET] <Daemon404> i never said firefox's MSE behavior was wrong [23:39:40 CET] <Daemon404> i wouldnt expect it to work in MSE [23:40:01 CET] <jya> well, mp4 is mp4. fragmented or not [23:40:43 CET] <Daemon404> global duration is generally not set in many fragmented mp4 at all [23:40:48 CET] <jya> we just use the same logic: buffered range are calculates on the actual demuxed frames [23:40:50 CET] <Daemon404> it's allowed to be 0 [23:40:55 CET] <Daemon404> unlike non-fragmenetd mp4. [23:41:07 CET] <jya> 0 means infinity [23:41:11 CET] <Daemon404> yes [23:41:50 CET] <Daemon404> like i said, i see nothinf in the html5 spec mentionign anything that would invalidate the mvhd duration [23:41:59 CET] <Daemon404> but in MSE, yes. [23:42:05 CET] <jya> and you'll find nothing validating it either :) [23:42:43 CET] <Daemon404> yes but in the absence of an actual strict html5 spec, one would sanely defer to the container spec [23:42:50 CET] <Daemon404> to define what said buffered range is [23:42:55 CET] <Daemon404> not a generic "tracks" [23:43:11 CET] <Daemon404> that would be my argument, anyway. [23:44:48 CET] <Daemon404> and for MSE it's a bit easier: we have separate tracks. [23:45:01 CET] <Daemon404> er, fielsp er track [23:45:15 CET] <Daemon404> buffers, etc [23:47:53 CET] <Daemon404> so i suppose this argument will be moot whenever we switch on to 100% [23:49:00 CET] <jya> Daemon404: loading this in safari, when I seek, audio seek but then no video frame is displayed: it's black (1frame.mp4) [23:49:12 CET] <Daemon404> that can be considered correct [23:49:34 CET] <Daemon404> i dont believe the mp4 spec defines what do to with teh ended track [23:52:38 CET] <llogan> michaelni: what's the occassion for the new point releases since there were some 12 days ago? security stuff? [23:54:09 CET] <jya> seeing that seekable == buffered here (because we construct our buffered range based on the actual frames), so when seeking (https://html.spec.whatwg.org/multipage/embedded-content.html#seeking) we fall into the step 8. that is currentTime > seekable.end(seekable.length-1) , so we end up seeking to the end of the video frame [23:54:58 CET] <Daemon404> i dont agree with not being able to seek within the presentation duration, really [23:55:11 CET] <Daemon404> but as i said, it'll be a moot argument soon anyway [23:55:19 CET] <Daemon404> we wont be servign any progressive [23:55:32 CET] <jya> any timeframe? [23:55:47 CET] <Daemon404> right now 20-30% is MSE [23:56:17 CET] <Daemon404> this week or next all new stuff will be MSE, i think [23:56:39 CET] <Daemon404> should be serving mostly MSE within a month, i hope? [23:58:31 CET] <jya> Daemon404: that's great [23:58:32 CET] <kierank> Haha you web people not learning the mistakes of broadcadt [23:58:44 CET] <Daemon404> kierank, im sure we havent [23:58:52 CET] <Daemon404> which one here [23:59:10 CET] <kierank> Dunno [23:59:27 CET] <kierank> All of them [23:59:41 CET] <Daemon404> we learned some [23:59:45 CET] <Daemon404> you dont see interlaced web content [00:00:00 CET] --- Thu Jan 28 2016

1 0

ffmpeg.log.20160127
by burek 28 Jan '16

28 Jan '16

[00:05:52 CET] <dorp> If one performs lengthy screen-capture sessions, what would be a recommended/common alternative to lossless x264, for mitigating the size of the exports? Simply using crf? [00:06:11 CET] <J_Darnley> Do you want a lossless encode or not? [00:06:58 CET] <dorp> J_Darnley: Well, I can't afford the size of the export, so I suppose the compromise can't be lossless? [00:08:21 CET] <J_Darnley> You could try ffv1 as a lossless alternative (with -coder range_tab) [00:08:37 CET] <J_Darnley> Otherwise, yes just give the crf you want to use. [00:09:16 CET] <dorp> Hmm.. I was under the assumption that -qp 0 -preset ultrafast ... would produce the smallest export? (even smaller than ffv1?) [00:09:41 CET] <J_Darnley> To be honest I don't know [00:09:52 CET] <dorp> (tries it out) [00:10:33 CET] <dorp> But in any case, if I can't afford lossless, then simply having crf is the next best thing? [00:11:25 CET] <J_Darnley> Yes, you ask the encoder to provide a quality and the encoder will use as many bits as it thinks it needs [00:11:51 CET] <llogan> lossless will probably suffice. just perform some tests. [00:12:02 CET] <llogan> i mean lossy [00:16:39 CET] <dorp> Hmmm, weird, I'm trying very low crf's... 0, 5, 10... and I was under the assumption that the cpu consumption will be higher than -qp 0 (same ultrafast preset) [00:17:08 CET] <dorp> And it seems that the differences are relatively insignificance. So I guess it's a good thing [00:17:26 CET] <dorp> insignificant* [00:18:24 CET] <J_Darnley> That's because most of the time will be spend in entropy coder. The time spent in it is proportional to the bitrate. [00:19:03 CET] <J_Darnley> Oh wait, that was cabac and ultrafast use cavlc [00:19:18 CET] <J_Darnley> Maybe the same applies (just to a lseer degree) [00:19:21 CET] <dorp> So the higher the bitrate of the export- the less time spent? [00:20:02 CET] <J_Darnley> No, I meant the opposite. [00:20:49 CET] <dorp> But the bitrate of -qp 0 is the highest, wouldn't that imply that -qp 0 should consume more time? [00:21:31 CET] <J_Darnley> Now we're just talking in circles. [00:22:55 CET] <dorp> crf 10, exported 20Mbits/sec, 7 seconds [00:23:11 CET] <Krish> Hi There , could anybody tell me where to place the external libraries for the enabling them with ffmpeg while compiling? [00:23:12 CET] <dorp> qp 0, exported 55Mbits/sec, 6.2 seconds [00:23:31 CET] <J_Darnley> Krish: anywhere your compiler can find them [00:24:01 CET] <J_Darnley> If you want to use a special location then read the configure help and your compiler's manual. [00:24:30 CET] <J_Darnley> Oh pkgconfig needs to find them too. [00:24:40 CET] <Krish> i am using the msys 2 in windows. I tried the command gcc search dir [00:24:59 CET] <Krish> and placed my lib file in the usr/lib [00:25:09 CET] <Krish> but it says libx264 not found [00:25:33 CET] <J_Darnley> Please post the whole log. [00:25:38 CET] <Krish> Oh by the way, I managed to compile libx264 for windows 10,. Thanks for your help. [00:25:59 CET] <J_Darnley> Was that me? I remember being not much help to someone [00:26:04 CET] <Krish> Henrik created a patch for x264 which made it compatible with win 10 RT [00:26:18 CET] <Krish> well your giudance helped :) [00:26:23 CET] <Krish> guidance* [00:26:51 CET] <Krish> u and furq here. [00:27:00 CET] <Krish> Now I am trying to compile it with ffmpeg [00:27:01 CET] <furq> huh [00:27:05 CET] Action: J_Darnley doubts that. J_Darnley distinctly remembers ranting and raving. [00:27:12 CET] <Krish> heheh [00:27:37 CET] <furq> J_Darnley? ranting and raving? never [00:27:49 CET] <furq> certainly not in my lifetime [00:27:54 CET] <J_Darnley> I suggest you use --extra-cflags and -I and --extra-ldflags and -L [00:28:25 CET] <J_Darnley> If you're using gcc that is [00:29:03 CET] <Krish> tried that, got this error in the log "-LC:/msys64/usr/local/lib" option ignored [00:29:33 CET] <J_Darnley> gcc won't ignore options, that sounds like msvc again [00:29:46 CET] <Krish> well a warning actually. After that the error " cannot open input file x264.lib [00:29:57 CET] <Krish> yup , I am tring it for msvc mate [00:29:57 CET] <furq> x264.lib definitely sounds like msvc [00:30:01 CET] <Krish> need it for WinRT [00:30:13 CET] <furq> i don't think putting those in /usr/lib will work but then i've never tried [00:30:52 CET] <Krish> opened MSYS2 from MSVC as suggested by https://trac.ffmpeg.org/wiki/CompilationGuide/WinRT#Windows10x64 [00:31:02 CET] <Krish> without libx264 this is working fine [00:31:29 CET] <Krish> the moment I include --enable-libx264 starts throwing error libx264 not found [00:33:09 CET] <drv> -L should get translated to -libpath for MSVC [00:33:31 CET] <drv> (looks right in configure to me) [00:36:11 CET] <Krish> let me try [00:38:40 CET] <Krish> --extra-ldflags="-APPCONTAINER WindowsApp.lib -libpath/usr/local/lib" is this fine? or the the slashes needs to be forward? [00:39:39 CET] <drv> no, you should pass -L to configure so it can get translated correctly, or if you want to use -libpath yourself, it needs to have a colon between it and the path [00:40:17 CET] <drv> -libpath:/usr/local/lib or whatever, should get translated because of the MSYS magic [00:41:04 CET] <furq> sometimes msys pathnames don't work [00:41:30 CET] <furq> you might need to pass the real path [00:41:33 CET] <Krish> well -L is not working as mentioned above since the option is getting ignored [00:41:49 CET] <furq> try with C:\\mingw\\usr\\lib or whatever the real path is [00:43:29 CET] <Krish> --extra-ldflags="-APPCONTAINER WindowsApp.lib -libpath:C:\\msys64\\usr\\local\\lib" like this? [00:43:49 CET] <Krish> the previous one threw error [00:48:58 CET] <Krish> second one also threw error [00:48:59 CET] <Krish> fatal error C1083: Cannot open include file: 'x264.h': No such file or directory [00:49:48 CET] <drv> so then it's working, but you also need --extra-cflags with -I to the include path [00:50:24 CET] <Krish> and -I in msvc converts to? [00:54:04 CET] <drv> -I is the same in MSVC, shouldn't need to be converted [00:55:49 CET] <Krish> but what about the path type [00:56:45 CET] <Krish> should it be like -I/usr/local/include or? -IC:\\msys64\\usr\\local\\include [00:56:53 CET] <drv> the same as whatever worked for -libpath [00:59:55 CET] <Krish> tried both: both gives the error : x264.libLINK : fatal error LNK1181: cannot open input file 'x264.lib' [01:06:11 CET] <hyponic> Hi. i have a stream that has a continuity error every few seconds. i was told that ffmpeg can fix this and and give an output without glitches. i wonder if this is true? [01:07:48 CET] <hyponic> somthing like this: [mpegts @ 0xac4a40] Continuity check failed for pid 0 expected 7 got 0 [02:14:59 CET] <dorp> Is ffmpeg the right tool for precision (frame-accurate) cutting and joining of an exported video (x264, crf=10, variable framerate)? [02:16:36 CET] <dorp> Is there a common tool for such a task, that wouldn't require a complete retranscode of the whole video, and would only retranscode the touched segments? [04:24:04 CET] <TD-Linux> dorp, ffmpeg does not have that capability, and I don't know of a tool that does, sorry [05:29:08 CET] <william_sg> Hi [05:29:43 CET] <william_sg> i'm trying HLS using vlc + ffmpeg .. [05:30:15 CET] <william_sg> but im not sure what is the best transcodeing parameters for better quality and to be able to play on mobile devices .. [05:30:26 CET] <william_sg> source is multicast stream .. [05:32:26 CET] <william_sg> take a look my script and parameters her http://pastebin.com/NzYP3dDc [05:32:28 CET] <william_sg> here* [07:14:51 CET] <DHE> william_sg: what's the source video? 1.5 megabit video is a bit low for anything above 480p or so [07:18:45 CET] <DHE> broadly speaking you shouldn't need -aspect, and for quality I wouldn't recommend ultrafast. at 480p most modern CPUs can keep up alright at "veryfast" [07:37:23 CET] <william_sg> HI DHE , source is multicast stream . it's a live tv channel [07:38:00 CET] <DHE> yes. what resolution? SD? [07:38:05 CET] <william_sg> yes SD [07:38:13 CET] <william_sg> i have both SD and HD .. [07:38:43 CET] <william_sg> if i put bit rate to 2M and higher .. it 's very slow to load . [07:38:49 CET] <william_sg> on mobile device [07:42:54 CET] <william_sg> im using apple mac mini and install fedora on it .. [07:43:15 CET] <william_sg> i can only transcode about 3SD + 1 HD channel .. [07:43:23 CET] <william_sg> and quality is still a bit low .. [07:54:43 CET] <DHE> so, SD is usually interlaced. if so I'd recommend using a deinterlacer [07:55:28 CET] <DHE> and switch from ultrafast to veryfast [07:56:01 CET] <chandujr> hey guys [07:56:27 CET] <chandujr> have anyone visited this site: http://cinekatz.com [07:57:19 CET] <chandujr> i want to know what technology they've used to edit the videos there and put customized texts in it [07:57:30 CET] <chandujr> anybody know about this? [07:58:28 CET] <chandujr> We can upload pictures, give our texts and select a template video. Then the customized video will be generated within seconds. [07:59:35 CET] <chandujr> i asked people, some have said that it's possible to have done using python and some video libraries, but he's not sure about it. [09:52:11 CET] <dorp> Is ffmpeg capable of precision (frame-accurate) cutting/joining, without the requirement of a complete retranscode of the whole stream? [10:00:13 CET] <DHE> no unless the whole video is made of key frames, because the video must start with a keyframe or playback would not be possible anyway [10:06:17 CET] <furq> dorp: if you mean only transcoding the bits that you cut out, the trim filter might work [10:06:26 CET] <furq> i'm not sure if it's frame-accurate though [10:07:47 CET] <dorp> DHE: But theoretically, only the modified segment is required to be retranscoded, and not the whole stream, right? [10:08:05 CET] <dorp> furq: I'm reading about it, thanks [10:08:55 CET] <furq> dorp: http://superuser.com/a/682534/146437 [10:08:58 CET] <furq> something like that [10:09:05 CET] <DHE> oh that... not sure if ffmpeg does it. in theory it can be done. there are some concerns about getting the encoding parameters right though. I've seen hardware devices become unhappy if something happens like the resolution changes without it being informed [10:09:21 CET] <furq> except you probably want trim=start_frame=123:end_frame=456 [10:15:28 CET] <mike_papa> Hello. I need to record MJPEG stream from usb camera without recompressing it. Just as it is. How do I tell ffmpeg to just save it without recompressing? [10:15:38 CET] <furq> mike_papa: -c:v copy [10:16:07 CET] <mike_papa> furq: thanks. :) [10:16:47 CET] <mike_papa> whole bunch of buffer underflow messages [10:18:34 CET] <dorp> furq: Hmm, the documentation doesn't seem to elaborate on the nature of the filter, wouldn't that imply that a full retranscode of the whole stream is required? And not just the specific segments that are being trimmed? [10:18:55 CET] <furq> unselected frames aren't processed at all [10:21:30 CET] <dorp> furq: I'm not sure if my question was clear enough, my intention was to trim a few frames, within a lengthy video, that doesn't consist of strictly I frames [10:22:00 CET] <dorp> Without the need to retranscode the whole thing, but only retranscode the mandatory modified segments [10:22:43 CET] <BtbN> While in theory possible, I don't think you can easily do that with a plain ffmpeg command. [10:23:13 CET] <BtbN> You could cut the video into a lot of parts, starting a new segment on every I frame, and then do the processing on each segment if neccesary. [10:24:02 CET] <furq> does it matter if the segments start on an i-frame if you're encoding them and then concatting the encoded files together [10:24:26 CET] <dorp> BtbN: I thought about that, but I wasn't sure if the re-stitching is guaranteed not to introduce a/v related side-effects? [10:24:31 CET] <termos> ffmpeg does not write the CODECS attribute to my m3u8 files, is there a way to enable this in the muxer? [10:25:27 CET] <furq> dorp: i should have thought the video would be fine, but i'm not sure about the audio [10:26:33 CET] <dorp> Is there a native ffmpeg feature for such a thing, for splitting a video into segments, and later restitching them, or such a thing should be scripted? [10:27:16 CET] <furq> afaik you'd have to run ffmpeg once per section and then one more time with -f concat [10:27:19 CET] <BtbN> there is a segment output [10:27:45 CET] <BtbN> or just tell it to output to a m3u8 HLS playlist, with 1 second segments, and it will cut at key frames [10:28:10 CET] <furq> wouldn't that encode the whole input file [10:28:13 CET] <furq> which is what he's trying to avoid [10:37:37 CET] <chandujr> hey guys [10:37:44 CET] <chandujr> have anyone visited this site: http://cinekatz.com [10:37:57 CET] <chandujr> i want to know what technology they've used to edit the videos there and put customized texts in it [10:38:04 CET] <chandujr> anybody know about this? [10:38:30 CET] <chandujr> We can upload pictures, give our texts and select a template video. Then the customized video will be generated within seconds. [10:38:48 CET] <chandujr> i asked people, some have said that it's possible to have done using python and some video libraries, but he's not sure about it. [10:39:01 CET] <mike_papa> after using: 'ffmpeg -t 00:00:05 -f v4l2 -input_format mjpeg -r 5 -s 1280x720 -i /dev/v4l/by-id/usb-Creative_Technology_Ltd._Live__Cam_Connect_HD_VF0750_123456789abcdef0-video-index0 -c:v copy test.avi', I get whole bunch of 'Non-monotonous DTS in output stream 0:0; previous: 264, current: 59; changing to 265.' and video is 5 times slower then it should be. [10:39:37 CET] <mike_papa> And ffmpeg doesn't stop after 5 seconds. [10:40:01 CET] <_Vi> How do I turn off output buffering? With `-f matroska -` or `-f nut -` I don't immediately receive little frames, but with `-f mpegts -` or `-f avi -` I do. [10:49:17 CET] <furq> mike_papa: use -framerate 5 instead of -r 5 [10:53:11 CET] <mike_papa> furq: Still didn't stop after 5 s. Non-monotonous DTS error still shows up. Video 3x slower then real life. Command I used:ffmpeg -t 00:00:05 -f v4l2 -input_format mjpeg -framerate 5 -video_size 1280x720 -i /dev/v4l/by-id/usb-Creative_Technology_Ltd._Live__Cam_Connect_HD_VF0750_123456789abcdef0-video-index0 -c copy test.avi [10:55:16 CET] <relaxed> mike_papa: use -t after the input [10:55:31 CET] <mike_papa> furq: and after stopping it, ffmpeg says: frame= 142 fps= 32 q=-1.0 Lsize= 8904kB time=00:00:16.10 bitrate=4530.5kbits/s speed= 3.6x. Why fps is 32? [10:57:35 CET] <mike_papa> relaxed: It helped for stopping after 5 seconds. Thanks. Still video is 15 seconds instead of 5, and it is 3x slow motion. [10:57:58 CET] <mike_papa> "frame= 123 fps= 34 q=-1.0 Lsize= 7569kB time=00:00:14.20 bitrate=4366.3kbits/s speed=3.87x" [10:58:35 CET] <relaxed> pastebin.com the command and console output [11:00:46 CET] <mike_papa> relaxed: here it is: http://pastebin.com/fFEhtW7v [11:04:08 CET] <relaxed> hmm, maybe you need to use v4l2-ctl as stated in https://trac.ffmpeg.org/wiki/Capture/Webcam [11:05:34 CET] <mike_papa> relaxed: seems that frame rate is good there: http://pastebin.com/R1hag8xT [11:15:25 CET] <relaxed> and when you omit -framerate ? [11:17:34 CET] <mike_papa> Still lot of Non-monotonous DTS, video frozen for first 2 seconds, than catching up for 1 second (double speed), then normal. [11:17:58 CET] <an3k> I want to extract a video stream that's stored in two M2TS files. Is https://trac.ffmpeg.org/wiki/Concatenate the correct way? [11:19:05 CET] <mike_papa> relaxed: When I changed time to 10 seconds it went well. No Non-monotonous DTS errors, video is good. [11:19:17 CET] <an3k> Concat demuxer or Concat protocol [11:19:22 CET] <mike_papa> it seems that lowering framerate couses problems. [11:20:59 CET] <mike_papa> but v4l2-ctl --list-formats-ext shows that 5 fps is available. [11:21:28 CET] <relaxed> mike_papa: try with -vsync 0 before the input [11:24:49 CET] <mike_papa> relaxed: frame= 223 fps= 26 q=-1.0 Lsize= 14045kB time=00:00:22.30 bitrate=5159.4kbits/s speed=2.55x [11:24:49 CET] <mike_papa> video:14034kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.077763% [11:25:01 CET] <mike_papa> relaxed: video is almost 3x slower [11:25:22 CET] <mike_papa> then it should. I believe it's 10s to 22.3s ratio now [11:25:50 CET] <mike_papa> and bunch of those dts errors again [11:26:43 CET] <mike_papa> maybe I should try grabbing series of jpeg images and then combine them to video file on PC? Actually I need only 1-2 fps. [11:28:06 CET] <an3k> avisynth? :) [11:28:45 CET] <relaxed> mike_papa: -vsync drop ? [11:31:07 CET] <mike_papa> relaxed: http://pastebin.com/p1nB9EaF - video still ca. 3 x slower. But no errors. [11:31:41 CET] <mike_papa> No DTS errors. It complains about not setting timestamps correctly. [11:32:56 CET] <relaxed> it's slower on playback? [11:35:05 CET] <mike_papa> relaxed: yes. On playback file is over 22 seconds long. [11:35:21 CET] <mike_papa> relaxed: while recording took only 10 seconds. [11:49:22 CET] <an3k> Whenever I try to directly read a Blu-ray: http://pastebin.com/9mn7VdXp [11:51:45 CET] <mike_papa> relaxed: if I use -r 24 before output I get more or less good speed. But still, output doesn't have 5 fps. [11:54:47 CET] <an3k> mike_papa: if you specify -r 24 your output will have 24 frames per second [11:55:54 CET] <mike_papa> an3k: If I specify -r 5 (as input has 5 fps) I get 48.2 seconds output from 10 seconds input. [11:56:30 CET] <mike_papa> an3k: If I don't use -r before output at all I get 22.5 seconds output [11:57:53 CET] <an3k> mike_papa: what happens if you set -r 5 as an input option? [11:58:44 CET] <mike_papa> an3k: -r 5 on input and nothing on output gives 48.2 s [11:59:55 CET] <an3k> and with -framerate 5 as an input option? [12:00:23 CET] <mike_papa> an3k: I have it. [12:00:55 CET] <an3k> Great :) What's the solution? -framerate? [12:01:51 CET] <mike_papa> an3k: no... It still doesn't work. I cannot get 5 fps avi from webcam. I can grab 5 fps from it, but I cannot save it into 5 fps avi. [12:02:43 CET] <an3k> ah ok. Guess my brain needs some overhaul :( [12:03:07 CET] <mike_papa> an3k: it's slow motion. If I force -r 23 (or 24) on output I get more or less 1x playback speed. [12:03:32 CET] <an3k> mike_papa: is the recording exactly 10 seconds long? How many frames are in the created file? [12:04:02 CET] <mike_papa> an3k: I use -t 00:00:10 so ffmpeg should make it 10s [12:04:26 CET] <mike_papa> an3k: and it grabs 238 frames [12:04:44 CET] <mike_papa> at least that's what it says at the end [12:04:46 CET] <an3k> °_0 [12:05:51 CET] <mike_papa> an3k: see yourself: http://pastebin.com/ycpXM1cH [12:09:09 CET] <an3k> hmm [12:09:41 CET] <an3k> try -vframes 50 [12:10:07 CET] <mike_papa> an3k: on input? [12:11:19 CET] <mike_papa> an3k: on output. It says frame=50, but file is 5s [12:11:58 CET] <an3k> ok, now it does 10 fps [12:13:09 CET] <mike_papa> ak3k: and recording took something like 1.7s (at least that's what my stopwatch, which I'm recording, says). [12:16:06 CET] <an3k> ffmpeg -f v4l2 -framerate 5 -r 5 -input_format mjpeg -video_size 1280x720 -vsync drop -t 00:00:10 -i /dev/v4l/by-id/usb-Creative_Technology_Ltd._Live__Cam_Connect_HD_VF0750_123456789abcdef0-video-index0 -c copy -r 5 test.avi [12:16:10 CET] <an3k> what does this do? [12:21:32 CET] <mike_papa> 48s video file. After I moved -t to output. On input it deosn't work. [12:23:55 CET] <mike_papa> Ok. I gtg now. I think I will record at 15 fps. It works good then. [12:24:40 CET] <an3k> Ok, bye. sorry that we couldn't help. [12:25:41 CET] <mike_papa> Bye. Thanks guys [13:25:23 CET] <hyponic> Hi. i have a stream that has a continuity error every few seconds. i was told that ffmpeg can fix this and and give an output without glitches. i wonder if this is true? [13:25:26 CET] <hyponic> somthing like this: [mpegts @ 0xac4a40] Continuity check failed for pid 0 expected 7 got 0 [13:28:19 CET] <waressearcher2> hyponic: hallo und herzlich willkommen [14:41:35 CET] <YaMoonSun> -i "Input" -r 30 -q 1 "Output"%5d.jpeg should give me the highest quality video extractions without going to .png right? [14:42:15 CET] <relaxed> YaMoonSun: yes [14:44:32 CET] <YaMoonSun> Cheers, just confirming, I did -q 10 earilier and it looked questionable. Forgot the quality scale for a moment. [14:53:39 CET] <hyponic> waressearcher2 i don't speak german i am sorry [14:56:32 CET] <hyponic> waressearcher2 but google translate does! thanks. :) [14:56:56 CET] <hyponic> waressearcher2 do you have an idea if ffmpeg can help me solve that problem? [14:57:31 CET] <waressearcher2> nein, keine ahnung [14:58:46 CET] <spaam> kaputt! [16:18:20 CET] <dorp> If I take a video file and split it into segments, based on the I frames. The duration/length of the video and audio streams must be identical? ... because otherwise, when I wish to concat these segments, desn't this has the potential to cause an audio skew? [16:19:16 CET] <JEEB> most containers have timestamps [16:19:45 CET] <JEEB> so as long as your player is not completely retarded and you don't do dumb things during concatenation it should be OK [16:22:10 CET] <dorp> JEEB: I've tried to make a testcase with MP4Box, I've removed the audio stream from one of the segments, and concated it back, and it seems like MP4Box would produce a skew (based on the length of said no-audio segment) [16:22:19 CET] <YaMoonSun> I once tried to make a video a smaller file size by exporting the 6 hour long .ogg and then using a 144p jpeg that was complete blacked out and then I tried to make the video one frame per hour and youtube had a fit about it [16:22:25 CET] <dorp> I'm trying to test it with ffmpeg too, but it seems that I'm doing something wrong with ffmpeg [16:23:30 CET] <JEEB> dorp: no idea how mp4box fucks things up [16:23:40 CET] <JEEB> but IIRC mp4 concatenation isn't a simple process to begin with [16:24:16 CET] <JEEB> plus after checking your file is correctly muxed (use L-SMASH's boxdumper etc) you will have to check that the player you're testing with is also handling all the crap correctly [16:24:36 CET] <JEEB> basically, instead of expecting things to do things right, check their output and confirm that shit is like it should be [16:24:57 CET] <JEEB> of course checking that shit requires some specification reading as well :P [16:25:11 CET] <JEEB> thankfully the 14496-12 is available for free [16:27:03 CET] <dorp> JEEB: In the MP4Box case, not only the player would introduce th skew, MP4Box -info would show the concatenated export has the audio stream's duration shorter by the same amount of seconds [16:27:23 CET] <JEEB> as I said, don't expect things to work like you'd think they work [16:27:35 CET] <JEEB> use boxdumper et al to read the output file's timestamps and other things [16:30:25 CET] <FilipeMaia> Hi. Is there a way to losslessly compress a series of png images and then decompress them? [16:31:16 CET] <FilipeMaia> I tried ffmpeg -i input.png -c:v libx264 -preset ultrafast -qp 0 output.mkv followed by ffmpeg -i output.mkv -r 1/1 $filename%03d.png, but that left some artifacts [16:32:02 CET] <c_14> You're going to need a codec that can encode rgb [16:32:04 CET] <J_Darnley> 1 - that will convert rgb into yuv, try libx264rgb [16:32:20 CET] <J_Darnley> 2 - that might drop frames to reach a framerate of 1 [16:32:55 CET] <c_14> If you're only compressing 1 png, just use -frames:v 1 ? [16:34:18 CET] <FilipeMaia> Thanks, Ill give lib264rgb a try [16:34:18 CET] <kbarry> c_14 I have a follow up question after your advice yesterday [16:34:32 CET] <J_Darnley> If you don't want to change from png files then try a png compressor like opting, pngcrush, pngquant [16:35:01 CET] <kbarry> http://pastebin.com/4U7SgFqd [16:35:39 CET] <kbarry> stream 0 is 5:48, stream 1 is 3:00 [16:36:01 CET] <FilipeMaia> J_Darnley: The png was just a test. Eventually I want to try with some data from some scientific camera so any format is fine [16:36:11 CET] <FilipeMaia> J_Darnley: I just dont know how to read/write yuv files [16:36:50 CET] <kbarry> I am using the -t 348 and a -stream_loop -1 (on the 3:00 stream to try to produce a file that has the metadata including duration) of stream 0 with the audio of stream 1 [16:37:06 CET] <FilipeMaia> J_Darnley: we have many terabytes of uncompressed images, which are often similar. Im curious how much they can be compressed with modern compression technology [16:37:11 CET] <kbarry> Also, the metadata isnt coming thru. [16:37:16 CET] <J_Darnley> ha wow [16:39:34 CET] <FilipeMaia> btw libx264rgb worked perfectly [16:44:23 CET] <kbarry> I can't seem to get the metadata to clone from an input file to the output file [16:46:40 CET] <J_Darnley> kbarry: you probably want -c copy unless you want to compress an already compressed file [16:47:05 CET] <J_Darnley> as for the metadata, that looks "right" to me [16:47:30 CET] <c_14> kbarry: you're missing the -map_metadata:g 0 [16:47:40 CET] <c_14> Also, it doesn't look like stream_loop works when you have multiple input files [16:47:42 CET] <kbarry> c_14: Lemm e try that (again) [16:47:42 CET] <c_14> For whatever reason [16:48:05 CET] <kbarry> any reason why it chose the duration of the shortest file? [16:48:14 CET] <c_14> You might just have to create a stream_loop'd version that's longer than the longest song you're trying to replace and then use that as input without the stream_loop option [16:48:30 CET] <c_14> kbarry: because that was the audio stream you were using [16:48:47 CET] <kbarry> Ahhh. Alright, [16:49:10 CET] <kbarry> I seem unable to get the metadata to go thru [16:49:21 CET] <kbarry> i just tried -map_metadata:g 0, no change [16:49:34 CET] <kbarry> (been trying lots of iterations, trying to get a fix on the syntax. no luck.) [16:49:49 CET] <kbarry> does it matter that I am changing the name of the file? [16:50:06 CET] <kbarry> (ie, the output file will not have the same name as stream 0 ? [16:52:26 CET] <kbarry> so, trying to not been a leech here. First thing I am doing is, creating a 20 minute look file of my original. [16:52:37 CET] <kbarry> (so it will always be longer than the stream0 [16:52:52 CET] <derp_annex> Anyone have suggestions on how I can cut down the CPU utilization for this live transcoding: http://pastebin.com/NcPqry3V ? [16:53:44 CET] <c_14> derp_annex: -preset veryfast [16:54:10 CET] <derp_annex> @c_14 And ultrafast as well? haha [16:54:51 CET] <kbarry> c_14: OK, got the durration to work, using a super-long version of the stream I "was" trying to loop before. [16:55:16 CET] <kbarry> My output file is the same duration as stream 0, not just need to get the metadata copied over. [16:57:19 CET] <c_14> kbarry: ffmpeg -i a.mp3 -i b.mp3 -t 00:03:58.86 -map_metadata:g 0 -map_metadata:s:0 0:s:0 -c:v copy -c:a copy -map 1:a -map 1:v out.mp3 <- seems to work for me [16:57:53 CET] <kbarry> Lemme give it a try, then i might have a few questions. [16:59:30 CET] <c_14> Eh, that command is wrong. It should be 0:v not 1:v [17:01:06 CET] <kbarry> yea, i fixed that, [17:01:06 CET] <kbarry> Still no metadata. [17:01:13 CET] <c_14> Oh, and while you're at it, add -fflags +bitexact -flags +bitexact [17:01:48 CET] <c_14> How are you checking the metadata? [17:01:51 CET] <kbarry> In the output, it shows that stream 0 has metata "publisher: Ninja tune, but later in the output, it shows metadata "tpub: Ninja Tune" [17:02:03 CET] <kbarry> I'm on windows (sorry ahead of time) [17:02:51 CET] <kbarry> And looking for the metadata on the file-browser [17:02:52 CET] <c_14> Can you compare the outputs of ffprobe -of flat -show_streams -show_format blah.mp3 for the input and the output? [17:03:20 CET] <kbarry> I can. Might have to wait a little. About to get off the trin. [17:04:30 CET] <derp_annex> @c_14 Thanks for the suggestion. I suppose I am going to need to research some more, considering I am republishing those three rtmp streams to HLS via nginx-rtmp. This doesn't look like it's going to scale well. haha [17:30:34 CET] <nfshr> HI all, i jsut wanted to create a small gif file from a mkv-clip. now i created one with '-s 320x174 "fps=15"' which just works fine. But now i wanted to create the same gif with a corresponding pallette file, which i created and used via '-filter_complex "fps=15,scale=320:-1:flags=lanczos[x];[x][1:v]paletteuse"' which amps up the output size from an acceptable 1.6MB without the palette, to an 180% whooping increase to 4.5MB.. why is this and [17:30:34 CET] <nfshr> how can i reduce the size? [17:31:30 CET] <nfshr> my intuitun would be that both should be the same size, since both have the same fps and resolution... [17:40:20 CET] <nfshr> corresponding full input lines: http://pastebin.com/raw/REHrGEy0 [17:48:42 CET] <kbarry> c_14, I think the metadata i am "seeing" may not be part of what windows displays. [17:49:02 CET] <kbarry> IE, the metadata displayed in windows, it might be some "extra" metadata, possibly handled by the OS. [17:56:27 CET] <salviaD> there is this 4k video on Vimeo, I can stream it OK, but if I download it (with youtube-dl command line tool), the resulting .mp4 file has lots of lag/shuttering momments. Is this something related to ffmpeg conversion? [18:23:13 CET] <dorp> It seems that I'm back to square one... I would like to cut/join with precision (frame-accuracy), video+audio exports that do not consists only of I frames. As I understand the common convention would be to re-transcode the whole stream, I was wondering if there's an approach that would require to retranscode only the modified segment? [18:23:43 CET] <c_14> sure, but it's a pain [18:24:10 CET] <dorp> I tried to split the video into segments (based on I frame positions), but it seems that the considerations related to video/audio stitching is too complicated for me to comprehend [18:24:10 CET] <c_14> You'd have to find the nearest i-frame at the section you want to modify cut there, then recode everything after it [18:25:50 CET] <dorp> c_14: I'm willing to live with this compromise, but I'm not sure how to handle the stitching of the 'new' segment? If I simply split the .mp4 into segments, it's clear that the segments' video/audio streams do not necessraily have the exact same length/duration, how would one go about and stitch them together? [18:28:56 CET] <c_14> You'll first have to find the timestamp of the i-frame nearest and before the point you want to cut then copy everything up to that point into a new file (preferably not mp4, something like mpegts is great for this). Then seek to the first frame after the i-frame and cut reencoding to the point where you actually wanted to cut and put that in another file (again preferably something like mpegts), then concat [18:28:58 CET] <c_14> those two pieces [18:29:31 CET] <c_14> The benefit of using mpegts in this case is that you can just cat them together [18:29:57 CET] <c_14> And you have to make sure when encoding the section that you use the same codec/settings as in the part you cut out [18:30:34 CET] <J_Darnley> nfshr: what about the full logs? [18:30:51 CET] <c_14> This gets more fun when you want to avoid audio desync because the audio frame might not have the same boundary as the video frame, so it's probably best to do both separately [18:32:31 CET] <dorp> c_14: Could you elaborate on the 'fun' part? Does that imply that I can't simply break a video into segments (based on I frames), and then stitch the segments together, and expect to be identical to the source? [18:34:21 CET] <dorp> Maybe I should experiment with something other than mp4, such as mpegts/mkv and see where I stand [18:35:03 CET] <c_14> The 'fun' part is making sure the audio and video stay in sync. [18:35:22 CET] <c_14> Because the audio and video frames might not line up perfectly. [18:36:45 CET] <c_14> And the problem with cutting a video at iframes and then just concatting it back together is that you'd have all the iframes you cut at twice right next to each other [18:37:00 CET] <c_14> Because an iframe usually opens and closes a gop [18:37:25 CET] <c_14> So in order to have 2 blocks that can be decoded independently of each other you'd have to have the iframe at the end of the first block and start of the second [18:37:45 CET] <c_14> Which is why I mentioned cutting the part you reencode one frame after the nearest i-frame [18:40:09 CET] <dorp> Well, I guess it's above my head, thanks for trying to explain that to me- I guess I better yet just 'try' and see whether I manage to get something I can live with, I just hate the idea of a full retranscode for such a thing, even if the retranscode is lossless [18:45:36 CET] <nfshr> Full logs regarding my issue: http://pastebin.com/MA80zz3J , J_Darnley [18:49:27 CET] <J_Darnley> I don't know what the problem is, sorry. [18:49:49 CET] <J_Darnley> Perhaps try making sure the same thing is done in both runs. [18:49:58 CET] <c_14> You'd probably have to ask the author of the paletteuse filter or read the source code. [18:49:59 CET] <J_Darnley> you use fps filter in one and not the other [18:50:38 CET] <J_Darnley> You also scale slightly differentlt [18:50:43 CET] <J_Darnley> *differently [18:51:21 CET] <nfshr> J_Darnley, hm.. [18:52:14 CET] <J_Darnley> Have you looked at the output and checked that both look similar and "correct"? [18:52:21 CET] <nfshr> J_Darnley, well thx for looking into it [19:17:25 CET] <hyponic> Hi. i have a stream that has a continuity error every few seconds. i was told that ffmpeg can fix this and and give an output without glitches. i wonder if this is true? [19:17:28 CET] <hyponic> somthing like this: [mpegts @ 0xac4a40] Continuity check failed for pid 0 expected 7 got 0 [19:20:39 CET] <an3k> Is subtitle extraction (PGS) still not possible? I found https://trac.ffmpeg.org/ticket/2208 and have the same issue [19:22:46 CET] <J_Darnley> I guess it isn't [19:23:26 CET] <J_Darnley> There isn't a gread deal of support for "raw" subtitle formats [19:25:33 CET] <an3k> So how do I convert them if I can't extract them in the first place? [19:25:48 CET] <dorp> It seems that simply by using .mkv with mkvmerge, I have the capability of 'stitching' segments, and it will apply something for keeping the a/v syncing in-shape. (maybe it's not 'identical', but I can't hear/see any issue, so that would do) [19:25:57 CET] <J_Darnley> Convert them to what? [19:26:04 CET] <an3k> Any other format [19:26:23 CET] <J_Darnley> Why not use eac3to like in that ticket? [19:27:03 CET] <dorp> c_14: Thanks for the hint of ditching .mp4, .mkv with mkvmerge's capabilities are good enough for me ^ [19:28:34 CET] <an3k> J_Darnley: So I should use ffmpeg for the video stream, eac3to for two audio streams and eac3to again for four subtitle stream? That would take more than 3 1/2 hours to extract everything [19:29:38 CET] <J_Darnley> If you want pgs format writing then you'd better write it. [19:31:38 CET] <an3k> J_Darnley: I guess one can expect pgs format writing with a tool like ffmpeg?! [19:32:20 CET] <J_Darnley> That's because nobody wrote it yet! These things don't magically happen. [19:32:47 CET] <J_Darnley> That ticket is 3 years old. [19:33:02 CET] <J_Darnley> In that time nobody has stepped up with a patch. [19:33:03 CET] <an3k> Yeah, especially after that period of time. [19:33:12 CET] <J_Darnley> So clearly people don't care enough. [19:34:20 CET] <an3k> Wow. I thought the devs would care of more or less completing their project [19:34:52 CET] <J_Darnley> Yeah! That's the only missing feature. When that gets added we can all go home. [19:35:58 CET] <an3k> Never said it's the only missing feature. I doubt it will take soooo much time to implement it specially the code is already there [19:44:36 CET] <digidog> vspipe | via ffmpeg using ffms2 spits out that it has FAILED. Python exception: No attribute with the name ffms2 exists. Did you mistype a plugin namespace? - but of course ffms2 is installed. :$ I don't get it. I am sure I messed up sth with plugin paths etc. but the docs are too confusing ot be sure to know what to do ... [19:49:40 CET] <durandal_1707> and this is not vapoursynth support channel [20:01:25 CET] <durandal_1707> pgs are bitmaps [20:01:27 CET] <an3k> digidog: why not directly sending to x264? [20:01:47 CET] <durandal_1707> he need to process it [20:02:45 CET] <an3k> digidog: have you imported ffms2? it's probably not in the vapoursynth autoloading libary directory [20:58:33 CET] <johnnny22-afk> when using a m3u8 stream as input, ffmpeg starts downloading full speed, but after it has gotten a couple of segments, it seems to fetch one segment at the time more slowly, with a tiny 1 second gap between each segments being downloaded. While i did specify -live_start_index 1 and the stream has many many segments. Is there a reason for this ? [21:00:54 CET] <J_Darnley> It downloads whatever is available then it has to wait for more to be produced? [21:01:10 CET] <johnnny22-afk> nope, there's a lot available [21:01:44 CET] <johnnny22-afk> it basically looks like the delay between ending the download of a segment and the time it takes for the next segment to start downloading... [21:02:52 CET] <johnnny22-afk> testing something. [21:07:00 CET] <johnnny22-afk> does -live_start_index need to be applied to the input or the output ? [21:19:27 CET] <litb> hello all [21:19:31 CET] <litb> I try to capture my desktop and stream it to raspberry pi 2 [21:19:38 CET] <litb> but raspberry only displays weird color war and then dies after a few seconds [21:19:42 CET] <litb> (kodi hangs) [21:19:48 CET] <litb> this is the ffmpeg command I use [21:19:51 CET] <litb> ffmpeg -f alsa -ac 2 -i pulse -f x11grab -r 25 -s 1920x1080 -i :0.0 -acodec aac -strict -2 -preset fast -vcodec libx264 -crf 30 -threads 0 -f mpegts - | vlc -I dummy - --sout='#std{access=http,mux=ts,dst=:3030/}' [21:20:00 CET] <litb> any idea what could be wrong with it? [21:43:09 CET] <CFX> Hi everyone, I had a support question in case anyone is able to help me. [21:44:00 CET] <CFX> I'll just leave it here in case anyone wants to [21:44:54 CET] <CFX> I'm porting some old code using ffmpeg to the newest version of the libraries. I keep getting errors about deprecation of av_dup_packet(AV_Packet*) telling me to use av_ref_packet instead [21:45:25 CET] <CFX> however av_ref_packet takes two arguments and I'm not exactly sure what am I suppossed to pass as the dst argument [22:00:52 CET] <J_Darnley> CFX: is the message a warning or an error? [22:01:00 CET] <J_Darnley> if its a warning just continue. [22:01:28 CET] <J_Darnley> The code is still there just sort of "marked for future deletion" [22:02:31 CET] <J_Darnley> I can't hep you with updating your use of the API [22:09:23 CET] <debianuser> litb: Does it work if you just save it to a file and try to play it? e.g. `ffmpeg ... -f mpegts somefile.ts` then try to play somefile.ts locally or at raspberry [22:17:09 CET] <CFX> it's actually an error [22:17:14 CET] <CFX> It prevents compilation [22:17:45 CET] <CFX> It's a video player, I'm not using the ffmpeg executables [22:18:28 CET] <CFX> I've checked the source files, and I'm gonna try to do something like the actual source code does, and try to disable the deprecation checks [22:18:59 CET] <CFX> to see if at least it gets by while I look for a proper solution [22:21:09 CET] <derekprestegard> hey, does anyone have a good method for gop aligned abr segmented encoding? [22:21:25 CET] <derekprestegard> e.e. taking a file and encoding multiple chunks of multiple bitrates all in parallel across a ton of servers? [22:34:08 CET] <litb> debianuser: it works locally [22:36:41 CET] <litb> debianuser: it doesn't play on kodi.. i only see green war [22:38:59 CET] <litb> debianuser: also tried different pixel formats [22:45:48 CET] <litb> debianuser: ah i needed yuv420p [23:06:38 CET] <hyponic> is possible to get ffmpeg to automatically respawn if a hls steam is disconnected and try to pick up from where it was dropped? [00:00:00 CET] --- Thu Jan 28 2016

1 0

ffmpeg-devel.log.20160126
by burek 27 Jan '16

27 Jan '16

[00:00:12 CET] <durandal_1707> but dynamic dimensions are still not defined well [00:00:47 CET] <cone-102> ffmpeg 03Andreas Cadhalpun 07master:38622007c4bd: vf_libopencv: add support for opencv 3 [00:01:31 CET] <durandal_1707> for example, when to update buffersink dimensions [00:02:14 CET] <durandal_1707> when it have mix of different frames [00:03:05 CET] <durandal_1707> so link dimensions are useless and frame should be used directly [00:03:42 CET] <durandal_1707> instead of link w and h [00:05:32 CET] <durandal_1707> but if you prefer I can force all inputs to have same dimension [00:09:43 CET] <ubitux> no, streamselect should support it [00:09:44 CET] <nevcairiel> jamrial: this dts-in-wav that michaelni found broken is ...odd. Its not even in the usual 14b dts-in-wav format, but a 16b LE bitstream, which is like the rarest format ever, and has giant audio frames [00:09:54 CET] <ubitux> lavf should make the constraints [00:12:15 CET] <nevcairiel> the frames are literally padded with 12kb of zeros [00:17:10 CET] <durandal_1707> if because of that new dts decoder blocked? [00:22:49 CET] <kierank> nevcairiel: is it not spdif? [00:23:00 CET] <kierank> hence the padding [00:24:41 CET] <nevcairiel> i suppose someone could have created it with an spdif encoder, but strictly speaking spdif needs BE dts, not LE [00:29:21 CET] <durandal_1707> blocking because of some dumb sample is bad [00:33:45 CET] <nevcairiel> lets see if foo96 shows up to comment on the issue, I dumped my analysis and idea for solution on the ML [00:33:51 CET] <nevcairiel> 86* [00:39:03 CET] <jamrial> dcadec cli can't decode it either. it reports it's a "20bit 5.1 48khz" stream before failing [00:39:47 CET] <jamrial> current ffdca decoder has apparently no issues decoding it, and doesn't show any warnings [00:40:08 CET] <nevcairiel> The error that triggers is an overread check in the new decoder [00:40:25 CET] <nevcairiel> but it doesnt overread the input, just the designated frame size in the core header [00:40:48 CET] <nevcairiel> which should probably be a warning or explode condition, not a general error [00:44:57 CET] <nevcairiel> If i just disable the error, it decodes and seemingly sounds fine [00:55:47 CET] <kierank> no idea how to fix this fuzz crash [02:57:04 CET] <atomnuker> From Debian's Chromium changelog: * Use ld.gold to avoid memory exhaustion while linking (closes: #812569). [02:58:18 CET] <atomnuker> I think they've almost ran out of libraries to statically link now [04:17:44 CET] <Plorkyeran> it's awesome how gold still isn't the default [04:17:48 CET] <Plorkyeran> after something like a decade [05:41:36 CET] <rcombs> https://gist.github.com/f5ca1ee40e622309ae8d I gave up on trying to figure out the cause of this and sent https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/188045.html instead [10:07:38 CET] <flux> I wonder, has it been considered that an AV_OPT_JSON might be useful in some cases? [10:16:00 CET] <durandal_1707> what would that do? [10:22:34 CET] <flux> well, pass in a complex argument such as { "track": 5, "tunables": [1, 2, 3] } [10:23:04 CET] <flux> in practice the alternative is to use AV_OPT_STRING and figure out a minimal protocol for doing the same [10:23:20 CET] <flux> potentially doing it in a different by every piece of code needing it :) [10:24:13 CET] <flux> another thing is that it would eventually provde a way to use the direct structured representation as the argument, bypassing the json generation and parsing altogether [10:24:38 CET] <flux> (when used as a library that is) [10:27:20 CET] <durandal_1707> patch welcome :P [10:27:44 CET] <flux> really? because if it's acceptable then it might just happen ;-) [10:27:56 CET] <durandal_1707> ubitux: sent new version [10:28:50 CET] <durandal_1707> flux: how would you know where and how to store data ? [10:29:09 CET] <flux> durandal_1707, it would work just like the rest of the (ie. encoder) options [10:30:09 CET] <flux> durandal_1707, so basically you have a context where there would be, say, Structured tunables; and then 00~{ "tunables", "Track tunables", offsetof(Context, tunables), AV_OPT_TYPE_JSON, {.structured = NULL}, .flags = AV_OPT_FLAG_ENCODING_PARAM } [10:30:59 CET] <nevcairiel> I don't see the benefit, instead of setting a struct of options, the options should just be seperate options so that you can get the automatic options documentation and set them using the existing options api [10:32:01 CET] <flux> I can see that viewpoint, but the data I'm thinking of writes a set of parameters to potentially all the tracks (I'm not actually discussing the kind of the data until the project is able to be published) [10:32:33 CET] <flux> it might work in this case if there was a possibility to reuse an option multiple times, but I don't think it is? [10:35:36 CET] <nevcairiel> not to mention that inputting json strings over the CLI API would be terrible, while using the existing syntax even for a long list of options is equally verbose, but not quite as annoying [10:36:05 CET] <flux> well, I'm not really pursuing the JSON syntax as is, but only the ability to parse something more than individual strings or integers or such [10:36:24 CET] <flux> for example how would one pass a list of integers as an option? [10:37:06 CET] <nevcairiel> use a string, split it into integers wherever its needed [10:37:13 CET] <jkqxz> I was wondering about JSON options, too. Passing them on the command line is nasty but possible, and being able to say "load them from this text file" would make it much nicer. [10:37:34 CET] <flux> nevcairiel, and if maybe I need to pass a list of such lists? [10:37:47 CET] <nevcairiel> don't [10:37:50 CET] <flux> :-) [10:37:52 CET] <nevcairiel> keep options simple =p [10:38:07 CET] <flux> so if I want to pass complex data, add a new API? [10:39:33 CET] <flux> it would be sort of elegant to have one place for providing setup data, simple or complex [10:41:55 CET] <nevcairiel> codec-specific API is never a good idea [10:45:37 CET] <nevcairiel> we havent really had a need for anything to have extremely complex options, the most complex is probably things like x264 which have a wild mixture of native ffmpeg options and their own private x264opts which is a list of options inside a string field [10:48:03 CET] <flux> maybe the right solution for my track/encoder-specific (but it really could be applied to other encoders in principle) would be adding a field type to AVPacketSideDataType and go that way [10:54:28 CET] <flux> nevcairiel, thanks for the feedback! it is always nice to know upfront what kind of changes might be approved and what not :). [10:56:01 CET] <nevcairiel> in general, complex public user-facing APIs will be under serious scrutiny, since once we have them we're stuck with them for a long time. So best is always to use what we have instead of forcing new API [10:57:32 CET] <flux> well, let's say ISO MP4 has very many features.. [11:11:02 CET] <wm4> durandal_1707: in my opinion lavfi simply doesn't support dynamic reconfiguration, and the process command code in vf_scale and vf_crop is a bug [11:11:16 CET] <wm4> if you want dynamic reconfiguration, it should be figured out properly [11:11:33 CET] <wm4> without introducing random inconsistencies all over the place [11:13:48 CET] <durandal_1707> not really, its possible just that you need to use frame width/height instead of outlink/pads [11:16:46 CET] <wm4> no, that's a random inconsistency [11:17:14 CET] <wm4> and "happens to work sometimes" is not "figured out properly" [11:20:12 CET] <durandal_1707> noted that we disagree [11:20:57 CET] <wm4> I hate this style of development, and it's a reason why the ffmpeg API is traditionally so bad [11:21:24 CET] <wm4> no clear concept of how it should work [11:21:29 CET] <wm4> inconsistencies all over the place [11:21:40 CET] <wm4> some things just crashing on format changes [11:22:04 CET] <ubitux> reconfiguration should definitely be defined better (and tested) [11:22:24 CET] <ubitux> (yes i know thx captain obvious) [11:22:56 CET] <ubitux> do we even have a flag for filters supporting configuration changes? [11:23:24 CET] <wm4> according to durandal_1707 the flag is "if it doesn't crash" [11:23:25 CET] <ubitux> i remember some kind of broken list of filters somewhere [11:30:07 CET] <durandal_1707> the scale filter should rescale if filter doesnt support it [11:31:41 CET] <durandal_1707> but note that there is already inconsistency and crashes, they are just more easily accessible with streamselect [11:32:36 CET] <wm4> what about other parameters like pixfmt, timebase, aspect [11:33:09 CET] <wm4> and inserting a scale filter would be very ugly (is this really what a user would want in most cases?) [11:38:56 CET] <durandal_1707> timebase can already be changed with settb [11:39:46 CET] <durandal_1707> format/layout/samplerate needs new graph [12:10:55 CET] <wm4> so format change support is worthless anyway [12:13:40 CET] <cone-119> ffmpeg 03Hendrik Leppkes 07master:c2869b4640f0: avutil: add P010 pixel format [12:13:40 CET] <cone-119> ffmpeg 03Hendrik Leppkes 07master:2e31434d84bb: swscale: add P010 input support [12:15:19 CET] <wm4> now only the dxva change is missing [12:15:35 CET] <nevcairiel> someone should simd the p010 input support, its so fucking slow [12:23:56 CET] <ubitux> always perplexed when the first video frames have negative ts [12:23:58 CET] <ubitux> :( [12:24:31 CET] <kierank> what's P010? [12:27:38 CET] <nevcairiel> NV12 in 10-bit, see https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578%28v=vs.85… [12:27:40 CET] <jkqxz> A really unhelpfully named fourcc. [12:28:17 CET] <nevcairiel> actually the names arent that bad if you understand the naming scheme, once you do you can just understand what P010, P016, P210, P216 etc are just from their name [12:29:24 CET] <wm4> I really think there's no way to defend fourcc naming conventions [12:29:38 CET] <wm4> (same for subsampling) [12:29:50 CET] <nevcairiel> its just 4 letters, its not like you can put that much meaningful details in them : p [12:29:55 CET] <jkqxz> The "four" part of it is rather too low. [12:30:19 CET] <nevcairiel> I still prefer P010 or NV12 over the apple equivalent [12:30:50 CET] <nevcairiel> or android mediacodec [12:30:54 CET] <nevcairiel> way too verbose names :D [12:30:56 CET] <wm4> you don't like kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange? [13:31:00 CET] <atomnuker> michaelni: getting somethin odd here, your dirac decoder golomb reading patches actually slightly reduce performance [13:31:21 CET] <atomnuker> this very naive way of reading is a bit faster: https://0x0.st/HnV.diff [13:40:18 CET] <atomnuker> michaelni: btw, this is what the specs give as examples: https://0x0.st/HnW.png [13:41:17 CET] <atomnuker> I've noticed that the length of each coefficient is basically the distance from the start to the first 1 in an even position [14:42:18 CET] <michaelni> atomnuker, reading bits, one at a time even if faster is a dead end, reading multiple symbols will be faster [14:42:48 CET] <michaelni> also which commits made it slower ? [14:44:33 CET] <michaelni> of course iam fine with changing to 1 bit reading if that is faste then the current code until somone implements something better ... [14:45:30 CET] <atomnuker> it's fine, I think I can completely avoid any loops [14:46:37 CET] <atomnuker> just showing 16 bits, ANDing those with 87381 to remove any 1s at odd positions [14:47:11 CET] <atomnuker> then just doing an ff_log2 will give you the length of the entire golomb code [14:47:58 CET] <atomnuker> then starting from the original coefficient, removing the 1 at the end (after shifting it by the length to avoid garbage) [14:48:21 CET] <atomnuker> and adding +1 to the coefficient for every single odd bit which is 1 [15:01:37 CET] <kierank> michaelni: are there any examples of how to read multiple symbols? [15:06:03 CET] <michaelni> there are plenty but i think they are about slightly different situations, huffyuv is one, also we merged symbols frequently for inner loops of othe important decoders, AC VLC but these have small sets of VLCs so a fixed number of symbols can be merged [15:08:14 CET] <michaelni> for dirac if one would lets say read 12bit and look in a table that could contain 12 symbols or fewer down to less than 1 complete symbol [15:09:19 CET] <michaelni> there are many many ways to use this, one could have such 12bit table that lists the complete symbols if any + the number of bits to move forward [15:09:45 CET] <michaelni> and a fall back to handle symbols that are longer than 12bit [15:21:15 CET] <durandal_1707> why nobody writes simd for utvideo? [15:22:15 CET] <kierank> because utvideo [15:22:49 CET] <Compn> maybe scared of author changing a bunch of code ? [15:22:56 CET] <Compn> or no one cares about weeaboo codecs? [16:04:41 CET] <durandal_1707> Compn: kierank doesnt use it [16:07:32 CET] <ubitux> is it well supported to have a 1/tb ` samplerate for audio? [16:08:44 CET] <kierank> mpegts does it [16:08:48 CET] <kierank> mkv as well [16:09:08 CET] <ubitux> ok [16:43:49 CET] <atomnuker> nevcairiel: "output" is the keyword here, I could change the pointers of the AVFrame I was given during the second field, but then I'd need to free the pointers I replaced and the new pointers to the data from my frame would get freed as well [16:44:05 CET] <atomnuker> so I'd still end up doing an allocation [16:44:40 CET] <atomnuker> and all of this just to save what is basically a memcopy [16:45:00 CET] <nevcairiel> a memcpy of raw image data is always worth saving [17:33:22 CET] <Daemon404> so uh [17:33:29 CET] <Daemon404> why is github not being updated [17:36:57 CET] <cone-213> ffmpeg 03Michael Niedermayer 07master:f3ace85d8869: avutil/opt: check for and handle errors in av_opt_set_dict2() [17:36:58 CET] <cone-213> ffmpeg 03Vittorio Gambaletta (VittGam) 07master:6e448fb97ee2: ffmpeg_opt: Move the 'process manually set programs' block above 'process manually set metadata' in open_output_file(). [17:36:59 CET] <cone-213> ffmpeg 03Vittorio Gambaletta (VittGam) 07master:74658a8b4db3: ffmpeg_opt: Allow -metadata option to set metadata on programs. [18:09:12 CET] <kierank> ffmpeg and udp... [18:09:36 CET] <durandal_1707> yes? [18:09:56 CET] <durandal_1707> push cfhd? [18:09:59 CET] <jermy> ...sitting in a tree? Where are you going with this? [18:11:02 CET] <jermy> (and the answer is: it could do with a much larger default fifo_size for higher bandwidth content) [18:11:54 CET] <kierank> durandal_1707: I will do that at fosdem [19:02:03 CET] <Timothy_Gu> Daemon404: 09:53 <@Timothy_Gu> kierank: I'm running a cron job that updates the GitHub mirror every hour [19:22:33 CET] <durandal_1707> anybody against dvaudio patch? [19:23:03 CET] <durandal_1707> I would like to close 4 years old bug [19:43:01 CET] <kierank> J_Darnley: are you coming on friday? [20:11:56 CET] <J_Darnley> kierank: You mean the beer drinking, rihgt? [20:12:01 CET] <J_Darnley> I might. [20:15:28 CET] <durandal_1707> michaelni: does it make sense to visualize concealed pixels with codecview filter? [20:18:27 CET] <J_Darnley> durandal_1707: re. the dvaudio patch: is there a source for the numbers in dv_get_audio_sample_count()? Or would someone who knows dvaudio be able to see where they come from? [20:19:49 CET] <J_Darnley> I guess I also want to ask the same about the shuffle assignment in dv_get_audio_sample_count(). [20:20:25 CET] <durandal_1707> its from dv_profile.c [20:20:58 CET] <durandal_1707> and dc code from demuxer [20:21:21 CET] <durandal_1707> It's ripped from dc container [20:21:28 CET] <durandal_1707> *dv [20:22:25 CET] <Compn> durandal_1707 : you test with all dvaudio samples ? [20:22:35 CET] <Compn> or if not, its not important, can be fixed later.. [20:24:40 CET] <J_Darnley> Okay, I see. No other comments from me about the patch. [20:25:07 CET] <durandal_1707> Compn: yes [20:25:30 CET] <durandal_1707> all have been tested [20:51:46 CET] <J_Darnley> kierank: what time did you plan to arrive at the beer event? [20:51:53 CET] <kierank> dunno [20:51:57 CET] <kierank> 7/8 I guess [20:52:03 CET] <kierank> I think the current plan is to visit bruges [20:53:31 CET] <J_Darnley> I guess I'll try to have dinner early(ish) and then get the bus. [20:53:32 CET] <Daemon404> kierank, hopefully one can get in at that time [20:53:33 CET] <michaelni> durandal_1707, error concealment visualization sounds certainly interresting [20:53:45 CET] <kierank> Daemon404: I always get in at about 9 [20:53:47 CET] <kierank> and squeeze in [20:54:05 CET] <Daemon404> my first year i arrived aroudn then and i could not get in until diego argued with a guy for 15 mins [20:54:44 CET] <Daemon404> (last year i arrived at 5 and that was a mistake) [20:55:20 CET] <J_Darnley> Were you out cold by the time anyone else arrived? [20:55:42 CET] <kierank> I remember last year you lot were all drunk when I arrived [20:55:57 CET] <Daemon404> J_Darnley, left at midnight [20:56:03 CET] <Daemon404> s/left/dragged off by coworker/ [20:58:24 CET] <Daemon404> maybe 7-8 this year. [21:33:22 CET] <llogan> i'm back now. everything is going to be ok, citizens. [21:42:16 CET] <J_Darnley> Praise the LLord. For he has returned. [21:49:16 CET] <llogan> facebook made a ffilter: https://github.com/facebook/transform [21:49:30 CET] <llogan> unfortunately, icense. [21:49:38 CET] <llogan> license [21:52:24 CET] <atomnuker> that AVOption usage... [21:54:15 CET] <wm4> what about it? except that there are 50 or so [21:56:18 CET] <atomnuker> did not use BOOL, use strings and have synonyms [21:59:50 CET] <TD-Linux> llogan, seriously WTF is that license [22:00:12 CET] <jamrial_> atomnuker: bool avoption is not in 2.8, so maybe that's why [22:01:11 CET] <TD-Linux> does anyone actually recognize that license? [22:09:01 CET] <J_Darnley> Is it not a bsd variant? [22:09:53 CET] <cone-213> ffmpeg 03Ivan 07master:a0174f67298b: avformat/flvenc: copyts in FLV muxer [22:10:46 CET] <J_Darnley> aw :( duckduckgo couldn't find it for me [22:11:15 CET] <jkqxz> Seems to be used on several facebook things and nowhere else. [22:12:01 CET] <JEEB> classic [22:13:49 CET] <BtbN> I don't understand what this filter does oO [22:15:25 CET] <J_Darnley> Ha ha ha. Now I'm getting results for ANPR or ALPR [22:18:49 CET] <J_Darnley> Dammit search engines! When I "quote a string" I want that exact string! [22:20:00 CET] <durandal_1707> llogan: isn't that panorama filter I wrote, I mean does same thing [22:20:30 CET] <durandal_1707> name of filter is extremely verbose [22:20:52 CET] <llogan> not sure. didn't get to look at it because one of my servers went down after i pasted link. [22:21:17 CET] <llogan> i've come to hate being a server bitch [22:36:06 CET] <BBB> michaelni: how does input frame ownership in AVCodec video encoding implementations work? particularly when talking about internal frame queues [22:36:26 CET] <BBB> michaelni: should I always copy if I want an internal frame queue? or is there some trick? [22:39:03 CET] <nevcairiel> just try to ref the frame, if its refcounted yay, otherwise it should automatically make a copy for you? [22:40:51 CET] <BBB> but the input is const AVFrame *, not AVFrame * [22:41:00 CET] <BBB> you cant modify the refcount if its const [22:41:47 CET] <BBB> I also dont see libx264.c of libvpxenc.c ref the input frame [22:42:00 CET] <BBB> although m honestly not sure how they work, they may just copy [22:42:10 CET] <nevcairiel> probably do [22:42:22 CET] <nevcairiel> since their api cant rely on any external refcounting [22:47:46 CET] <michaelni> the refcount isnt in AVFrame its in AVBuffer. i think const AVFrame should work [22:52:36 CET] <BBB> michaelni: http://pastebin.com/rg24e3vB [22:52:40 CET] <BBB> I dont think that works [22:54:02 CET] <BBB> oh as a struct it does? [22:54:03 CET] <BBB> hm [22:54:09 CET] <BBB> pointer [22:54:28 CET] <BBB> nvm [23:13:50 CET] <cone-213> ffmpeg 03Paul B Mahol 07master:df7b165e878e: avfilter/vf_zscale: make it possible to override input frame parameters [23:17:47 CET] <cone-213> ffmpeg 03Paul B Mahol 07master:e9e623369d7b: avcodec: add Ulead DV audio decoder [23:34:45 CET] <cone-213> ffmpeg 03Paul B Mahol 07master:11bc4fd653fa: avcodec/dvaudiodec: only stereo makes sense [23:47:11 CET] <durandal_1707> no more merges? [23:48:35 CET] <Daemon404> not sure why nevcairiel hasnt [23:48:42 CET] <Daemon404> i can pitch in again... [23:49:50 CET] <wm4> you could switch to cherry-picks [23:50:04 CET] <wm4> not sure if easier? [23:51:00 CET] <Daemon404> i personally would not [23:51:21 CET] <J_Darnley> I think people want merges so that you can find the commit hash in ffmpeg [00:00:00 CET] --- Wed Jan 27 2016

1 0

ffmpeg.log.20160126
by burek 27 Jan '16

27 Jan '16

[00:01:11 CET] <dorp_> Is there a better alternative to gdigrab? Or I might as well test a different machine? (I'm still uncertain whether the results are to be expected) [00:01:29 CET] <ricardo_> Hello, I have a video separated in two files: data (.dat) and a index (.dix). Using totem I can open the .dat and see the video, but with others players I can't. How do I open these files with ffmpeg? [00:02:16 CET] <J_Darnley> dorp_: you could see if dshow has a capture device available on your system [00:02:34 CET] <J_Darnley> otherwise consider a "better" capture tool [00:02:46 CET] <J_Darnley> perhaps fraps or obs [00:03:14 CET] <kepstin> yeah, i added the gdigrab filter because it was simple to code, dumb, and works on any windows version [00:03:33 CET] <kepstin> a better capture driver that e.g. grabs the compositor front buffer can get a lot better performance [00:03:33 CET] <J_Darnley> Oh its your feature is it? [00:03:44 CET] <kepstin> not really, i just got it upstream and cleaned up the code a bit :/ [00:03:55 CET] <J_Darnley> ah [00:04:35 CET] <dorp_> J_Darnley: Thanks for the suggestions, I'm on it [00:04:47 CET] <Mavrik> I guess interfacing with modern stuff like nVidia / AMD video encoder directly would probably net better results. [00:04:57 CET] <Mavrik> E.g. the APIs Steam etc. use to stream gameplay. [00:05:54 CET] <kepstin> in theory, the fancy on-card encoders on nvidia, amd, intel can feed data directly from the video ram into the encoder at native framerate :/ [00:06:11 CET] <Mavrik> Exactly. [00:06:36 CET] <Mavrik> You get freshly encoded H.264 directly form the card without having to transport raw display anywher.e [00:06:43 CET] <Mavrik> (If you have the HW of course.) [00:06:50 CET] <dorp_> Are there existing tools for utilizing that? Or I'm getting excited for nothing? :) [00:07:17 CET] <Mavrik> dorp_, nVidia GeForce Experience is the nVidia tool I know of [00:07:19 CET] <Mavrik> no idea about AMD [00:07:34 CET] <Mavrik> You need a decently modern GPU tho. [00:08:33 CET] <furq> i think raptr can do it for amd and intel [00:12:11 CET] <YamakasY> yo anyone know the right parameters to have the sound synced flv to mp4 ? [00:17:07 CET] <J_Darnley> Why do you think that needs a special option? [00:17:23 CET] <J_Darnley> Did you post the command and full log yet? [00:17:41 CET] <dorp_> J_Darnley: Thanks for the suggestion, it seems that obs with 60fps can capture all the frames [00:18:45 CET] <YamakasY> J_Darnley: erm [00:22:19 CET] <YamakasY> nah testing out [00:22:34 CET] <YamakasY> I'm going install some extra ffmpeg servers, that is for sure [00:25:15 CET] <YamakasY> ok this seems to be best for now -vcodec mpeg4 -async 1 -acodec libvo_aacenc [00:26:31 CET] <J_Darnley> If you have a recent ffmpeg please use the internal encoder. [00:26:33 CET] <YamakasY> mhh can be better [00:26:35 CET] <kepstin> YamakasY: the vo_aacenc encoder isn't very good, I'd recommend using the internall encoder (-acodec aac) instead [00:26:57 CET] <YamakasY> kepstin: yeah that should be better, but I need to specify it it seems [00:27:16 CET] <J_Darnley> Also, you were complaining about the video quality. I'm not surprised since you're using mpeg4 [00:27:27 CET] <YamakasY> mhh still experimental ? [00:27:31 CET] <J_Darnley> At the default of 200k [00:27:38 CET] <J_Darnley> Not anymore [00:27:39 CET] <YamakasY> nah it's not that bad [00:28:19 CET] <YamakasY> no I have a birate of 255 [00:28:21 CET] <YamakasY> oops [00:28:22 CET] <YamakasY> 355 [00:30:55 CET] <YamakasY> mhh I need much better, fps is 30 default [00:30:59 CET] <YamakasY> of the flv [00:33:21 CET] <dorp_> Is there a filter for ffmpeg to discard frames which are the same, essentially keeping the unique frames in a variable-framerate sort of way? [00:34:57 CET] <YamakasY> oh the windows 10 player is crappy ti seems [00:35:04 CET] <J_Darnley> I think you can use one of the telecine filters forthat [00:48:55 CET] <kepstin> dorp_: the decimate filter can do that, yeah [00:50:15 CET] <dorp_> kepstin: I actually just tried it, it seems to me that it's not very thorough, I can still skip-through lots of duplicate frames [00:50:24 CET] <dorp_> Unless I'm using it wrong [00:50:45 CET] <YamakasY> is 30 fps on 640x480 really an advanatge ? back the days I saw some PC's having a hard time on it when recording with flash [00:51:15 CET] <dorp_> ./ffmpeg -i -c:v ... -vf mpdecimate out.mp4 ... seems correct? [00:51:35 CET] <furq> YamakasY: why are you using mpeg4 instead of libx264 [00:52:36 CET] <YamakasY> furq: dunno, I come from flv's [00:52:46 CET] <YamakasY> furq: I need to play it on mobile devices [00:52:52 CET] <furq> so use libx264 [00:53:07 CET] <TD-Linux> ffmpeg's mpeg4 encoder is unlikely to produce something playable on a mobile device [00:53:29 CET] <YamakasY> but what would be my extention with that lib ? [00:53:30 CET] <TD-Linux> (it's an ASP encoder right?) [00:53:36 CET] <furq> mp4 [00:53:42 CET] <furq> and i think it's an SP encoder [00:53:42 CET] <YamakasY> ok [00:54:05 CET] <YamakasY> so as acodec I need to se libx264? [00:54:09 CET] <furq> vcodec [00:54:16 CET] <furq> or c:v if you're not from the past [00:54:27 CET] <YamakasY> I have vcoded in my command [00:54:47 CET] <YamakasY> furq: I like the 90's [00:55:02 CET] <furq> that explains why you're using nellymoser [00:55:03 CET] <TD-Linux> I do not miss 90's video encodes one bit [00:55:24 CET] <TD-Linux> it looks like his input is nellymoser, not output [00:55:36 CET] <furq> yes but it would have spoiled the rhythm of the joke to make that clear [00:55:45 CET] <YamakasY> so than it would be ffmpeg -i bla.flv c:v output.mp4 ? [00:55:52 CET] <TD-Linux> opus in mp4 soon (tm) [00:55:54 CET] <furq> -c:v libx264 [00:56:02 CET] <YamakasY> nothing more ? [00:56:22 CET] <furq> that depends on whether you want to do anything more [00:56:37 CET] <YamakasY> furq: what is advised ? [00:57:03 CET] <YamakasY> I record my flv's at high 264 but at a fps of 25 atm [00:57:15 CET] <YamakasY> 30 can be done but was not always nice with buffering I thought [00:57:40 CET] <furq> use the framerate of the input [00:58:41 CET] <YamakasY> ye syes [00:58:51 CET] <YamakasY> that for sure and i need async [00:59:30 CET] <YamakasY> heh, these ffmpeg servers are sure gonna be there [01:00:51 CET] <YamakasY> ok,, perfect quality, but async doesn't sync that good [01:02:49 CET] <YamakasY> furq: good advise [01:03:02 CET] <YamakasY> I knew about the framerate, never UP it [01:11:36 CET] <themisfit610> hey all, looking to identify options for the e-ac3 encoder in ffmpeg [01:11:44 CET] <themisfit610> is there documentation of this? [01:14:59 CET] <J_Darnley> Is there one? [01:15:34 CET] <J_Darnley> So there is [01:15:58 CET] <J_Darnley> Then: -h encoder=eac3 [01:16:11 CET] <J_Darnley> And other global options [01:17:29 CET] <themisfit610> many thanks! [01:18:54 CET] <themisfit610> another question [01:19:34 CET] <themisfit610> best practices for ac3 / ec3 encoding includes things like lowpass filtering the LFE [01:19:45 CET] <themisfit610> will the encoder in ffmpeg do this automatically or do I need to handle that upstream? [01:25:18 CET] <J_Darnley> I have no idea about that [01:30:03 CET] <maduro> hi all, is it possible to generate DASH manifests with both webm and mp4 content using ffmpeg? [04:48:38 CET] <waressearcher2> can you imagine living on a planet 5 times bigger than earth, all that gravity [06:15:40 CET] <johnnny22-afk> can i really just cat all the .ts files from an m3u8 playlist into a single .ts files without adjustments ? [06:26:45 CET] <c_14> usually, yes [06:28:53 CET] <johnnny22-afk> nice to hear, i'll give it a test ;) [07:52:43 CET] <digidog> hm, any chance to get vpse installed on Linux ? :$ [07:53:23 CET] <furq> that depends on what vpse is [07:54:00 CET] <digidog> furq: vapoursynth-editor [07:54:45 CET] <digidog> furq: it seems that the packages miss sth for compiling if I understood correctly :/ https://bitbucket.org/mystery_keeper/vapoursynth-editor/issues/7/modificati… [07:56:25 CET] <furq> that says clang and osx [07:57:13 CET] <digidog> furq: the last comment [07:57:37 CET] <furq> that says clang on linux [07:59:07 CET] <furq> https://bitbucket.org/mystery_keeper/vapoursynth-editor/issues/4/building-i… [07:59:42 CET] <digidog> furq: sry, not much exp in compiling ... so you think it should compile fine with gcc or how do I start to compile it since there is no instruction and I am on ... [07:59:48 CET] <digidog> furq: ah ... [07:59:59 CET] <digidog> furq: awesome. that was the link I was looking for! [08:00:11 CET] <digidog> furq: thanks a million! [08:01:53 CET] <digidog> furq: qmake ... *facepalm* sure ... since it is Qt5 [08:01:57 CET] <digidog> thank you ! [08:02:02 CET] <digidog> furq++ [08:03:00 CET] Last message repeated 1 time(s). [09:07:26 CET] <nindustries> Hi, with Skylake bringing HEVC hardware decoding, is there any acceleration in ffmpeg possible? [09:19:14 CET] <fritsch> on linux? [09:19:15 CET] <fritsch> no [09:19:21 CET] <fritsch> not for 10 bit [09:19:27 CET] <fritsch> but HEVC 8 bit is already there in ffmpeg [09:19:41 CET] <fritsch> libva / libva-intel-driver >= 1.6.1 [09:20:05 CET] <fritsch> nindustries: [09:31:57 CET] <nindustries> But there is on windows? fritsch [09:32:06 CET] <nindustries> Reason is i'm picking out a new server [09:42:57 CET] <furq> nindustries: apparently ffmpeg does hevc decoding with dxva2 [09:43:10 CET] <fritsch> it has for windows / linux [09:43:14 CET] <nindustries> hmm [09:43:14 CET] <fritsch> but only for 8 bit both [09:43:22 CET] <nindustries> And why only 8-bit? [09:43:40 CET] <fritsch> skl has no 10 bit decoding unit [09:43:44 CET] <fritsch> it is done "gpu accelerated" [09:43:50 CET] <fritsch> much too slow for 4k video anyways [09:44:13 CET] <fritsch> but, the reason is: for linux 10 bit hwaccel work is missing and for windows hendrik did not yet PR his bits [09:44:27 CET] <fritsch> lavfilters already can do it on windows [09:45:29 CET] <nindustries> skl ? [09:45:39 CET] <nindustries> oh, skylake [09:46:19 CET] <fritsch> yeah don't buy it [09:46:21 CET] <fritsch> wait for kabilake [09:46:33 CET] <nindustries> why, may I ask? [09:46:41 CET] <fritsch> hä? [09:46:50 CET] <fritsch> cause it cannot play hevc 10 bit content [09:46:56 CET] <fritsch> without the cpu going to 400% [09:46:56 CET] <nindustries> second half of 2017.. [09:47:12 CET] <fritsch> the future live tv / uhd bluray is 4k @ 10 bit [09:47:22 CET] <nindustries> yah [09:47:23 CET] <fritsch> i would not buy an expensive skylake just to add an nvidia card later [09:47:24 CET] <fritsch> to play that [09:47:33 CET] <nindustries> this is going to be the server btw [09:47:40 CET] <nindustries> so I was thinking about converting things [09:47:50 CET] <nindustries> ah right.. that's ENcoding.. [09:48:03 CET] <fritsch> encoding won't work either [09:50:38 CET] <nindustries> yeah [09:50:50 CET] <nindustries> so I suppose only reason for skylake is DDR4 memory [09:54:16 CET] <YamakasY> morning [11:59:06 CET] <YamakasY> anyone doing an ffmpeg exec in php and checking for a OK in an if ? [13:41:31 CET] <dorp_> If it helps anybody else- it seems that there's a difference between screen capturing 'desktop' with -f gdigrab .. and capturing a specific window. When I have a window set to 1920:1080, playing a video at 25fps ... and then use ffmpeg to capture said window at 60fps, it seems that all the frames are captured. (at least within the scope of 8 seconds, 200 frames) [13:41:43 CET] <dorp_> (using 'desktop' would result with missing frames) [13:44:03 CET] <dorp_> Maybe it's worth adding that to the documentation? [14:15:18 CET] <luc4> Hello! Im using ffmpeg libraries in my code to open containers. Im running a sort of unit test that simply opens and closes the same file. After approx 6500 times, I get this crash: http://pastebin.com/fuFkCfxj. Im inclined to think this is my fault, I only found old reports, but anyone who experienced something similar by any chance? Im using ffmpeg 2.7.2. [14:17:04 CET] <J_Darnley> Not that I know of. [14:18:10 CET] <J_Darnley> I do wonder why you are using 2.7.2 when 2.7.5 is available (not to mention the 2.8 releases) [14:19:17 CET] <J_Darnley> If you want to report a bug then you should compile with debug symbols and post a full trace in the report. [14:19:28 CET] <J_Darnley> You should test the latest git head first though. [14:20:37 CET] <luc4> J_Darnley: unfortunately I spent one day trying to use 2.8, but without success. [14:20:47 CET] <luc4> J_Darnley: I can try 2.7.5 though [14:24:00 CET] <durandal_1707> luc4: what's wrong with 2.8? [14:27:02 CET] <luc4> durandal_1707: totally unknown, just switching from 2.7.2 to 2.8 was breaking my code, but dont remember the details. I was helped here but no one could find anything. I was told that actually a code written for 2.7.2 should be compatible with 2.8, but my code was simply not working. After a day I stopped trying. [14:36:30 CET] <durandal_1707> luc4: does your code have source code? [14:36:57 CET] <luc4> durandal_1707: you mean if it is open source? [14:37:13 CET] <luc4> durandal_1707: it is open yes [14:37:32 CET] <durandal_1707> where it is? [14:37:46 CET] <luc4> durandal_1707: however I was trying on 2.8.0, maybe 2.8.1 is different [14:38:54 CET] <J_Darnley> Why would you not use the newest version of each branch? [14:39:00 CET] <luc4> durandal_1707: this is the portion using ffmpeg to open: https://github.com/carlonluca/pi/blob/master/piomxtextures_src/omxplayer_li… [14:39:07 CET] <J_Darnley> Isn't this why people spend time maintaining them? [14:39:43 CET] <luc4> J_Darnley: because it takes much time to rebuild for an arm platform, and I do not do it unless there is a real reason to do it. [14:40:18 CET] <luc4> J_Darnley: last time I tried to update to 2.8 it took 1 day, and it was wasted :-) [14:40:52 CET] <luc4> J_Darnley: however if I find out this crash is really only caused by ffmpeg and not by me Ill have to update [14:40:57 CET] <J_Darnley> ARM clearly sucks so much [14:41:53 CET] Action: J_Darnley wonder how long it takes to build on an RPi [14:42:21 CET] <luc4> J_Darnley: crossbuilding takes 5/10 minutes approx [14:44:01 CET] <J_Darnley> Curses I don't have the source on it. [14:46:47 CET] <hook> hey all [14:47:00 CET] <hook> trying to pipe a gource video to ffmpeg with this; gource --seconds-per-day 0.3 --auto-skip-seconds 6 --file-idle-time 500 --multi-sampling -1024x768 --hide filenames,dirnames --stop-at-end --disable-progress --output-ppm-stream - | ffmpeg -an -threads 4 -y -vb 4000000 -r 60 -f image2pipe -vcodec ppm -i - -vcodec libx264 ./gource.mp4 [14:47:03 CET] <waressearcher2> hook: hallo und herzlich willkommen [14:47:12 CET] <hook> thanks waressearcher2 [14:47:26 CET] <hook> but it seems that the video is cropping to the top left? [14:47:40 CET] <hook> zoomed in [14:48:12 CET] <J_Darnley> What does ffmpeg say about it? [14:48:13 CET] <waressearcher2> "-vb 4000000", ist korrekt ? [14:49:11 CET] <hook> probably not, I guess I should be figuring this value out [14:49:50 CET] <hook> I see this in the output; Stream #0.0: Video: libx264, yuv420p, 1024x768, q=-1--1, 60 tbn, 60 tbc [14:50:45 CET] <J_Darnley> Why don't you stop guessing and post the whole log? [14:52:08 CET] <hook> ffmpeg version 0.8.17-4:0.8.17-0ubuntu0.12.04.1, Copyright (c) 2000-2014 the Libav developers [14:52:08 CET] <hook> built on Mar 16 2015 13:26:50 with gcc 4.6.3 [14:52:08 CET] <hook> The ffmpeg program is only provided for script compatibility and will be removed [14:52:09 CET] <hook> in a future release. It has been deprecated in the Libav project to allow for [14:52:09 CET] <hook> incompatible command line syntax improvements in its replacement called avconv [14:52:09 CET] <hook> (see Changelog for details). Please use avconv instead. [14:52:09 CET] <hook> [image2pipe @ 0x778c40] Estimating duration from bitrate, this may be inaccurate [14:52:10 CET] <hook> Input #0, image2pipe, from 'pipe:': [14:52:10 CET] <hook> Duration: N/A, bitrate: N/A [14:52:10 CET] <hook> Stream #0.0: Video: ppm, rgb24, 1024x768, 60 fps, 60 tbr, 60 tbn, 60 tbc [14:52:11 CET] <hook> Incompatible pixel format 'rgb24' for codec 'libx264', auto-selecting format 'yuv420p' [14:52:11 CET] <hook> [buffer @ 0x779380] w:1024 h:768 pixfmt:rgb24 [14:52:56 CET] <J_Darnley> OMFG [14:53:00 CET] <hook> apologies for the dump, forgotten my irc skills [14:53:10 CET] <J_Darnley> 1 - That's not ffmpeg [14:53:13 CET] <J_Darnley> 2 - That so old [14:53:20 CET] <J_Darnley> 3 - That's not the whole log. [14:53:24 CET] <hook> ah okay, good [14:53:35 CET] <hook> trust me to trust an apt-get [14:53:53 CET] <hook> if I fire it through avconv I get the same issue [14:54:16 CET] <J_Darnley> I assume your version of avconv is equally as old [14:54:30 CET] <hook> let's see [14:55:19 CET] <hook> avconv version 0.8.17-4:0.8.17-0ubuntu0.12.04.1, [14:56:06 CET] <hook> does anyone mind me dumping logs here, or is there a preferred way? [14:56:16 CET] <J_Darnley> pastebin or similar! [14:57:10 CET] <hook> ok ;) [15:07:49 CET] <dorp_> Is there anybody here with access to the documentation? Who should I contact for making a suggestion for a note about gdigrab? [15:08:19 CET] <J_Darnley> Anyone with the source can do that [15:09:15 CET] <J_Darnley> If you have a specific change in mind and don't want to bother with that then put the text you want somewhere and I will look at putting it in. [15:10:30 CET] <dorp_> J_Darnley: It's just a simple note concerning what I've experienced, that capturing 'desktop' and capturing a specific window entity, would perform differently, even if both happen to be the same resolution/canvas [15:11:22 CET] <J_Darnley> I'm afraid I don't understand what you mean. [15:11:39 CET] <dorp_> Capturing a 25fps 1920:1080 with 'desktop' would have missing frames, where capturing the same 25fps 1920:1080 by a specific window/title, would have none. [15:12:00 CET] <J_Darnley> Perhaps if you post the two command lines I could test myself. [15:13:16 CET] <dorp_> J_Darnley: As basic as that: ./ffmpeg -f gdigrab -framerate 60 -i desktop -c:v libx264 -qp 0 -preset ultrafast -y out.mp4 [15:14:01 CET] <dorp_> J_Darnley: Given a monitor with 1920:1080 60hz, playing and capturing a 1920:1080 video with 25fps, would result with missing frames [15:14:16 CET] <J_Darnley> And what about the "slow" command? [15:15:00 CET] <dorp_> J_Darnley: This is the command that would result with missing frames. The one that didn't- was about replacing: -i desktop, with: -i title="explicit" [15:15:04 CET] <jkqxz> Huh, that's a "fun" answer to the question. They really don't seem like they should be different from the code. [15:15:21 CET] <dorp_> jkqxz: Hey there, what do you mean? [15:17:56 CET] <dorp_> jkqxz: BTW, thanks a lot for the sequence of numbers suggestion, made my testing a lot easier and clearer to evaluate comparisons [15:18:01 CET] <jkqxz> Desktop vs. window in gdigrab is essentially the same code, except a bit of the initialisation setting it up. The difference must be somewhere on the Windows side. [15:18:18 CET] <bencoh> dorp_: what about cpu use? [15:18:31 CET] <J_Darnley> Windows is known for its exceptionally good code(!) [15:19:25 CET] <dorp_> bencoh: My cases didn't involve cpu concerns, and the case I've shown ^ is about two identical cases. Both having the same resolution, source fps, capture fps, same codec, and same drive [15:20:45 CET] <dorp_> bencoh: The only difference was whether the selection was -i desktop, or -i title= ... so if other happens to stumble issues, it would be best to know that if you don't actually wish to capture your desktop activity, and you wish to capture something within a window canvas, it's possible it will perform better [15:21:47 CET] <bencoh> dorp_: I was only asking if you noticed any difference in cpu usage between the two (be it for ffmpeg or the rest of the system), but okay. [15:23:03 CET] <dorp_> bencoh: I didn't notice anything significant, so I'm not sure how to measure/compare a subtle difference. I just wanted to emphasize that this is not a cpu bottleneck concern [15:32:41 CET] <eau4x6> I'm using to concat demuxer to join two parts of the same video (no reencoding). I get an annoying gap when the first video ends. The last frame of first video is displayed for 7 seconds along with audio from second. I tried monkeying around with vsync/async, copyts, copytb options but it didn't help :) [15:33:00 CET] <eau4x6> "I'm using concat demuxer" [15:34:43 CET] <eau4x6> the video format is h.264 and i use mkv container. any tips? [15:36:22 CET] <hook> think I'm going to give up on this gource/ffmpeg thing for today, let it settle and pick it up tomorrow [16:28:18 CET] <digidog> any vapoursynth friends here? need to add PATHONPATH to vapoursynth since it doesnt work in bashrc or profile. any hints ? [16:36:08 CET] <jkqxz> You've misspelled PYTHONPATH, perhaps? [16:41:13 CET] <digidog> jkqxz: jesus! yes ... sry. *squints* [16:41:50 CET] <durandal_1707> do you see letters well? [16:42:06 CET] <shincodex> I love gutting your make file [16:42:51 CET] <digidog> jkqxz: vspipe -v doesnt work - I always need to type PYTHONPATH=/usr/local/lib/python3.5/site-packages vspipe -v that why I try to place this somewhere useful [16:43:30 CET] <digidog> durandal_1707: define *well* after 26 hours awake ... [16:44:54 CET] <digidog> shincodex: that doesn't even make any sense for my spare english ... [16:46:09 CET] <shincodex> I have a spare tire in my trunk [16:49:37 CET] <digidog> shincodex: well ... drop it off ;) ... btw: we can also talk in German, French or Italian if you want ? :) [17:04:05 CET] <digidog> Myrsloik: can I set up PYTHONPATH somewhere in vapoursynth/*? Placing it in the ~/.bashrc or ~/.profile doesn'T has any effect. (the usual way to add any paths in ENV Variables for Terminal commands under Linux/Debian) [17:10:38 CET] <dorp_> Yesterday I've asked if it's possible to screen capture at a high framerate, and have the export consists only of the unique frames. It seems that I've achieved just that with: -vf mpdecimate -vsync 0 ... just using 'mpdecimate' would seem to discard the duplicates from the source, but introduce 'dups' to fill the gaps. So -vsync 0 is significant [17:16:52 CET] <jkqxz> digidog: "export PYTHONPATH=..." in ~/.bashrc really should work if you're using bash. Does "set" output show the right PYTHONPATH in the environment immediately before you run the program? [17:29:29 CET] <digidog> jkqxz++ [17:30:48 CET] <digidog> jkqxz: you saved my ass. thanks. made another check and it turned out that my echo PATH >> basrc missed *export* [17:30:56 CET] <digidog> *facepalm* [17:31:06 CET] <digidog> jkqxz: thank you. [17:37:54 CET] <jkqxz> :) [18:25:18 CET] <salviadud> Lets say I want to disable x86 flags on an encoding [18:26:01 CET] <salviadud> would I go like this: ffmpeg -cpuflags -mmx-sse-avx-cmov ? [18:26:23 CET] <salviadud> My question is how do I disable multiple x86 flags on a single command [18:27:01 CET] <J_Darnley> If you want to disable them all: -cpuflags 0 [18:27:25 CET] <J_Darnley> (I wonder why though) [18:27:53 CET] <J_Darnley> As for disabling some I think you might be able to use what you posted [18:28:18 CET] <salviadud> Thank you J_Darnley [18:29:58 CET] <J_Darnley> Yeah, see cpuflags here http://ffmpeg.org/ffmpeg.html [18:30:34 CET] <salviadud> You got any favorite distro for ffmpeg ? [18:31:01 CET] <J_Darnley> ? [18:31:10 CET] <J_Darnley> Do you mean operating system? [18:31:54 CET] <salviadud> Yeah [18:31:55 CET] <jkqxz> I think the cpuflags only handles internal use in libav* - if you use libx264 for encoding it won't be respected. [18:32:02 CET] <J_Darnley> Windows. [18:32:23 CET] <salviadud> jkqxz, how do I encode in h264 without libx264 then? [18:32:28 CET] <drv> why do you want to restrict cpu flags? have you found a bug in one of the optimized routines? [18:32:31 CET] <J_Darnley> You don't [18:33:01 CET] <salviadud> Then I would have to compile h264 without those flags [18:33:35 CET] <salviadud> cpu flags don't allow me to decompress a binary file hidden within a video [18:35:06 CET] <salviadud> libx264 seems to only have sse [18:35:17 CET] <salviadud> There is no bug [18:35:20 CET] <salviadud> so, don't worry [18:35:32 CET] <salviadud> ffmpeg works fine [18:35:37 CET] <J_Darnley> I think you're seeing things. [18:36:15 CET] <J_Darnley> Anyway, you can control the features used in libx264. See the asm option. [18:37:20 CET] <salviadud> But then, I would have to compile ffmpeg with --disable-asm [18:37:26 CET] <J_Darnley> No [18:37:35 CET] <J_Darnley> See x264's asm option [18:38:25 CET] <J_Darnley> And I don't mean a compile time option. [18:39:46 CET] <salviadud> I can't seem to find that option. [18:39:56 CET] <salviadud> on google at least [18:40:08 CET] <salviadud> most of the stuff that comes out is how to compile libx264 [18:40:20 CET] <bencoh> x264 --fullhelp|grep asm [18:44:23 CET] <salviadud> I don't have x264 as a binary [18:44:32 CET] <salviadud> I can get full help on ffmpeg [18:45:47 CET] <salviadud> I only got the library [18:52:01 CET] <jkqxz> Something like "ffmpeg ... -x264opts asm=sse8,avx7 ..." should do it. It doesn't have a negative form, though, so you need to build up the whole set yourself. [18:52:55 CET] <salviadud> I would only use the most basic of flags [18:53:09 CET] <salviadud> to achieve my lab test [19:04:07 CET] <kbarry> I'm very new to FFMPEG. Google doesnt offer any read answers, so came here looking for help with what to search for (what is it called) [19:04:35 CET] <grublet> kbarry: what are you trying to find the name of? [19:04:38 CET] <grublet> describe it [19:04:50 CET] <kbarry> I'd like to take a audio track (an MP3), and replace the audio, but keep all else the same, metadata, track length, etc. [19:05:06 CET] <kbarry> I don't know what that might be called. [19:05:25 CET] <kbarry> not entirely sure its common procedure, but seems that it should be fairly straitforward, [19:06:06 CET] <kbarry> Was thinking I might have to generate a sample of [length of origin] from my "new audio source", then "slip/insert" that in as the only audio track. [19:06:07 CET] <grublet> kbarry: you're looking to copy metadata. someone else will need to tell you what specifically to do though, but googling 'copy metadata' may give better results [19:06:24 CET] <grublet> oh, keep track length the same? that idk [19:06:29 CET] <Mavrik> kbarry, that's a very interesting usecase [19:06:38 CET] <Mavrik> What are you trying to do? :) [19:07:38 CET] <kbarry> Prank my Mentor. [19:07:39 CET] <c_14> kbarry: ffmpeg -i metadata.mp3 -i audio.mp3 -map_metadata 0 -map 1:a out.mp3 [19:07:40 CET] <c_14> should do it [19:07:43 CET] <kbarry> (to be honest) [19:08:01 CET] <c_14> track length will depend on the length of audio.mp3 though [19:08:09 CET] <kbarry> c_14: Would that keep the track length the same? [19:08:14 CET] <kbarry> Right, [19:08:14 CET] <c_14> (you can use -t duration as an output option to trim) [19:08:29 CET] <Mavrik> kbarry, ah, we can help with that :P [19:08:43 CET] <Mavrik> Yeah, what c_14 said. [19:08:52 CET] <kbarry> What is the Dureation of my "replacement " track is , say 30 seconds, and the original was 5 minutes? [19:08:55 CET] <Mavrik> Or reencode audio and use silence audio filter. [19:09:02 CET] <Mavrik> That will keep everything the same just the track is silent. [19:09:07 CET] <kbarry> will it just have 30 seconds of the "new" thne silence? [19:09:36 CET] <kbarry> So, were going to clone-backup his music library, [19:09:42 CET] <c_14> kbarry: you also have to add -map_metadata:s:0 0:s:0 [19:10:11 CET] <YamakasY> what is the right term for ffmpeg an flv to a mp4 ? [19:10:13 CET] <kbarry> but then we are going to replace all his music with a song (techno/kids song called "i'm a jellybean", guess what the only lyric is) [19:10:39 CET] <c_14> kbarry: you can use -stream_loop -1 as an input option to infinitely loop (and then with -t as an output option to cut off after x seconds/minutes) [19:10:46 CET] <Mavrik> YamakasY, remuxing if you don't want to touch video and audio inside [19:10:49 CET] <kbarry> But want to keep "everything else" the same, so the metadata, album art (i know its probably not part of the track) [19:10:56 CET] <Mavrik> ffmpeg -i bla.flv -codec copy bla.mp4 [19:10:59 CET] <YamakasY> Mavrik: ok, no transcoding ? [19:12:53 CET] <kbarry> c_14: OK, going to take down all you said, and read the docs, so I can learn. [19:13:51 CET] <kbarry> c_14: in -map_metadata:s:0 0:s:0 what is the 0:s:0 [19:14:00 CET] <kbarry> (you didnt have that in the original suggested command) [19:15:05 CET] <c_14> You want both, the one with the s will copy the stream metadata, the other one will copy the global metadata [19:15:07 CET] <YamakasY> Mavrik: ? [19:15:23 CET] <c_14> 0:s:0 being the first stream of the first file [19:15:48 CET] <kbarry> 0:s = index0 STREAM [19:16:00 CET] <kbarry> :0 index0 stream [19:16:31 CET] <Mavrik> YamakasY, what? [19:18:33 CET] <YamakasY> Mavrik: 'no transcoding ? [19:24:31 CET] <kbarry> When using a command like -stream_loop, is it possible for me to apply this to a specific stream/input ? [19:24:52 CET] <kbarry> ie, Currently i'd have 2 streams, and I really only want to repeat one. [19:25:16 CET] <kbarry> In my use-case i'll be using a -t, so it wont r"really" matter, but for a broader understanding, i'd like to know [19:25:21 CET] <c_14> just put it directly before the -i you want it to affect [19:25:35 CET] <c_14> Most ffmpeg options affect the file they are placed in front of. [19:26:36 CET] <kbarry> OK, [19:27:13 CET] <kbarry> so "technically" I could have -stream_loop 2 -i file.mp3 -stream_loop -1 -i secondaudio.mp3 [19:27:39 CET] <c_14> yes [19:27:43 CET] <c_14> practically as well [19:27:44 CET] <digidog> hm, qtgmc @ vapoursynth has switched from Yadif to nnedi3, does this infect the all over qtgmc quality ? any experiences ? [19:29:19 CET] <kbarry> Thanks for the help. [19:29:43 CET] Action: kbarry enjoying ffmpeg more every time he gets to use it [20:27:02 CET] <durandal_1707> digidog: nnedi3 gets pixels out of nothing, using trained neurons [20:28:57 CET] <durandal_1707> digidog: yadif uses other fields from prev, current and next frame [22:26:42 CET] <Chagall1> would it be faster to extract text subs and retime them (automatically) compared to slow seek all the way? [22:26:56 CET] <Chagall1> (if you have to seek anyway) [22:27:48 CET] <c_14> Well, you're going to have to read the entire file either way. And if you extract them you'll have to read it twice (assuming you want the subs put back in again later) [22:36:13 CET] <c_14> Chagall1: did you get my message? [22:38:26 CET] <Chagall1> no, didn't see it [22:38:31 CET] <c_14> Well, you're going to have to read the entire file either way. And if you extract them you'll have to read it twice (assuming you want the subs put back in again later) [22:42:36 CET] <Chagall1> yeah but I can fast seek for the encode [22:43:15 CET] <Chagall1> if I can get the subtitles faster somehow [22:43:49 CET] <c_14> Are you adjusting the timings for the entire file or just for a part of it? [22:44:27 CET] <Chagall1> whatever part corresponds to the video i am re-encoding [22:44:54 CET] <c_14> I'm not sure I understand what you're trying to do. [22:45:17 CET] <Chagall1> i would be seeking, like i said, so it would be a part of it [22:47:39 CET] <c_14> You should be able to fast seek in either case, no? [22:48:23 CET] <Chagall1> if you fast seek with text subs they just get displayed from the beginning [22:49:02 CET] <Chagall1> (with subtitles filter) [22:49:43 CET] <Chagall1> but if i can just extract them with ffmpeg using fast seek then i can use them as input for the actual encode and lose almost no time, not sure if that would work though [22:50:39 CET] <c_14> Ah, your question is which would be faster ffmpeg -i video -ss <time> -t <duration> -vf subtitles=video out or extracting the subs, retiming them and then using ffmpeg -ss <time> -t <duration> -i video -vf subtitles=subs out, right? [22:50:43 CET] <c_14> In that case extracting would be faster. [22:51:18 CET] <c_14> s/would/should/ [22:52:53 CET] <Nitori> so, if ffmpeg tells me a x264/x265 video stream has the pix fmt yuv422p10le, that does imply 10-bit depth, correct? [22:52:57 CET] <Chagall1> ok, thanks [22:53:10 CET] <c_14> yes [22:53:57 CET] <Nitori> okay, and any idea what the "(tv)" in "yuv422p10le(tv)" means? [22:54:07 CET] <Nitori> x265 [22:54:10 CET] <c_14> It means it's not full-range [22:54:33 CET] <c_14> It was either that or the bt level [22:54:58 CET] <c_14> ie bt.701 or bt.609 etc [22:54:58 CET] <Nitori> ok.. [23:06:36 CET] <c_14> It's the color range [23:06:42 CET] <c_14> tv = not full-range [23:17:13 CET] <Nitori> could have something to do with me using crf 0, or preset "fast"? or just simply that the video only consists of black and white? [23:21:08 CET] <J_Darnley> crf 0 is just the quality level (which is not lossless at 10-bit) [23:21:46 CET] <Nitori> didn't know it wasn't lossless [23:21:53 CET] <J_Darnley> 422 refers to how the chroma is subsampled [23:22:12 CET] <Nitori> those are fancy words. Still have much learning to do [23:22:29 CET] <J_Darnley> Anything else you're not sure about? [23:23:08 CET] <J_Darnley> p means planar [23:23:13 CET] <J_Darnley> 10 does mean 10-bit [23:23:20 CET] <J_Darnley> le means little endian [23:23:33 CET] <Nitori> figured those last two :-) [23:56:53 CET] <salviadud> Just so you guys know, to disable-asm on the x264 library, you need a recompile [23:57:09 CET] <salviadud> that way, when ffmpeg calls for it, it's disabled [00:00:00 CET] --- Wed Jan 27 2016

1 0