Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

February 2016

1 participants
58 discussions

ffmpeg-devel.log.20160203
by burek 04 Feb '16

04 Feb '16

[00:18:51 CET] <Daemon404> 42 [00:59:38 CET] <kierank> Daemon404: going to try and use vf_overlay from the api soon, looking forward to a whole lot of fun [01:07:04 CET] <cone-623> ffmpeg 03Matthias Hunstock 07master:e9025573faf6: decklink: support all valid numbers of audio channels [01:12:27 CET] <jya> BBB: how good is the ARM code for ffvp9 compare to the one in libvpx? [01:13:03 CET] <jya> I remember hearing that libvpx has neon optimisations that ffvp9 didn't have, or something like htat [01:21:31 CET] <cone-623> ffmpeg 03Andreas Cadhalpun 07master:916da13d6dac: cfhd: fix off-by-one error in level check [01:27:05 CET] <BBB> jya: right, afaik there is none [01:27:19 CET] <BBB> jya: I know some people that could help you write neon simd, but Im probably not one of the [01:27:21 CET] <BBB> +m [01:27:41 CET] <jya> BBB: ok, so libvpx should be performing better on arm then no ? [01:31:37 CET] <BBB> yes [01:33:53 CET] <BBB> I dont think its hard to write the neon simd, so if arm has a high priority for you guys and you like the performance enhancement you likely get, you should absolutely consider writing the neon simd for ffvp9 *advertisement* [01:42:41 CET] <jamrial> judging by x86 performance, i guess writing mc alone would put ffvp9 above libvpx :p [01:52:19 CET] <jya> jamrial: are you volunteering ? :) [02:09:39 CET] <jamrial> no, never wrote neon [02:11:16 CET] <jamrial> simply saying that, based on what we saw with x86, ffvp9 on arm would probably only need mc to get ahead of libvpx [02:11:27 CET] <jamrial> any further asm would make it much, much faster [02:13:00 CET] <BBB> jya: wbs is pretty good at neon assembly, maybe you can convince him [02:36:18 CET] <baptiste> thardin, agree with the comment about the MXF muxer, I changed it in ffmbc, I'll try to find the time to port the change [02:38:40 CET] <Compn> a wild baptiste appears :) [02:39:06 CET] <Compn> (its a pokemon reference, i'm not calling baptiste wild) [02:39:19 CET] <baptiste> :) [03:06:34 CET] <cone-623> ffmpeg 03Timothy Gu 07master:228eb6708bd7: sdl: Remove AVPicture usage [03:06:34 CET] <cone-623> ffmpeg 03Timothy Gu 07master:13b8ba8c9d1f: xv: Remove AVPicture usage [03:06:35 CET] <cone-623> ffmpeg 03Timothy Gu 07master:0ab25dac2f0b: cinepakenc: Stop using AVPicture [03:16:28 CET] <Timothy_Gu> anybody who knows "grace.ryan" [03:16:47 CET] <Timothy_Gu> his/her fate box is running outta space [08:17:40 CET] <Timothy_Gu> michaelni: your openbsd box seems to be running out of space [08:17:46 CET] <Timothy_Gu> http://fatebeta.ffmpeg.org/report/x86_64-openbsd4.8-gcc3.3/20160122092450 [08:51:34 CET] <thardin> baptiste: cool [08:52:51 CET] <thardin> I need to set up an serverside filter for mxf on my mail account somehow. I sort all ffmpeg mail into its own folder because of the volume, so I tend to miss some of the mxf related emails (especially if not marked "mxf" in the subject) [09:18:34 CET] <wm4> why do we still have x11grab? [09:19:30 CET] <wm4> I thought xcbgrab is the new cool thing [09:29:59 CET] <thardin> maybe not all systems have libxcb? [09:30:36 CET] <wm4> doubtful [09:31:07 CET] <flux> I doubt though xcbgrab would be any better than x11grab? [09:31:24 CET] <flux> or would the pipelining increase throughput?-) [09:31:41 CET] <wm4> I don't know, but that doesn't justify duplicated code [09:35:19 CET] <flux> oh, I hadn't noticed it already exists :). I would probably say then just give the libx11-version the axe. [09:37:32 CET] <flux> doesn't seem like the xcbgrab embraces the asynchronicity of xcb (if there's anything to embrace), but at least it's possible. [09:40:32 CET] <cone-465> ffmpeg 03Paul B Mahol 07master:c1b23e158c92: avfilter/vf_nnedi: fix ISO C90 warnings [12:27:34 CET] <wm4> raw dts appears to output incorrect timestamps [12:28:10 CET] <wm4> it's like libavformat assumes half the sample rate to compute it (although the reported samplerate is correct) [12:28:24 CET] <wm4> might be av_get_audio_frame_duration's fault, but this function is such a fucking mess [12:29:58 CET] <wm4> hm, or is the parser computing it here [12:32:00 CET] <nevcairiel> the parser computes a duration in samples [12:32:10 CET] <nevcairiel> however, the parser doesnt know about extra samples for higher sample rates [12:32:16 CET] <nevcairiel> so its duration is always based against the core [12:32:56 CET] <wm4> hm [12:33:38 CET] <nevcairiel> so was your raw dts actually 96 or 192khz? [12:33:47 CET] <wm4> 96, 7.1 [12:34:10 CET] <nevcairiel> then the duration will probably be wrong [12:34:33 CET] <nevcairiel> or well, use another timebase than you might expect [12:35:03 CET] <wm4> so dca_parse_params returns 512, while the decoder output is 1024 [12:35:48 CET] <nevcairiel> could probably rescale the duration to the actual samplerate in dca_parse [12:38:03 CET] <wm4> s->duration = duration * (sample_rate / avctx->sample_rate);? [12:38:09 CET] <wm4> could it just set the correct samplerate? [12:38:24 CET] <nevcairiel> i would've said s->duration = av_rescale(duration, avctx->sample_rate, sample_rate); [12:38:26 CET] <nevcairiel> but yes [12:38:38 CET] <nevcairiel> and feel free to make the parser parse all the dts extensions [12:40:05 CET] <michaelni> Timothy_Gu, that run is from 12 days ago, theres 2 gb free space currently [12:41:08 CET] <nevcairiel> wm4: i dont see where this duration field is actually read though [12:41:28 CET] <wm4> patch sent [12:41:48 CET] <wm4> nevcairiel: libavformat/utils.c should be using it [12:41:52 CET] <wm4> "somewhere" [12:42:03 CET] <wm4> in generally uses the frame duration for formats with no timestamps [12:42:17 CET] <nevcairiel> wm4: that patch is wrong [12:42:24 CET] <nevcairiel> its not the "actual samplerate" [12:42:29 CET] <nevcairiel> the actual samplerate is what the decoder sets [12:43:48 CET] <wm4> so this bug just compensates the other bug? [12:44:02 CET] <wm4> where is the decoder involved in this? [12:44:03 CET] <nevcairiel> why not do what you wanted to do first, scale to the actual sample rate [12:44:33 CET] <wm4> you suggested that... scaling the duration seems strange to me [12:46:46 CET] <nevcairiel> like I said, either you make the parser figure out the actual sample rate, or y ou just trust avctx->sample_rate [12:47:06 CET] <nevcairiel> otherwise the decoder and parser will once again fight over the sample rate and cause weirdness [12:48:52 CET] <nevcairiel> making the parser smarter would be a better solution, but alas thats also rather complicated [12:50:34 CET] <wm4> yeah, that looks very annoying [13:02:33 CET] <nevcairiel> did you test if the patch actually produces proper durations again? [13:02:41 CET] <nevcairiel> i tend to screw up order of arguments in av_rescale [13:04:37 CET] <wm4> nevcairiel: from what I can see, the patch works fine [13:34:58 CET] <cone-465> ffmpeg 03Tobias Rapp 07master:ca71e6052e86: doc/demuxers: add some concat demuxer script examples [14:20:43 CET] <Daemon404> :D [14:29:25 CET] <wm4> D: [14:29:35 CET] <wm4> we should rewrite lavc in Rust [14:30:21 CET] <Daemon404> too unsafe, should be haskell [14:31:19 CET] <iive> well, i've heard that java script is the best optimized language... [14:31:27 CET] <iive> maybe we should at least consider it... [14:31:54 CET] <JEEB> Daemon404: not agda? [14:32:00 CET] <Daemon404> ada you mean? [14:32:46 CET] <JEEB> probably 8) [14:54:41 CET] <Daemon404> :D [16:00:28 CET] <Daemon404> what a mess the mjpeg and mpegec stuff is... [16:00:36 CET] <Daemon404> why does mjpeg have ff_mpv_generic_options [16:14:14 CET] <Daemon404> ah i see... [16:19:58 CET] <cone-465> ffmpeg 03Schenk, Michael 07master:93f4b41208fb: avformat/http: add crypto to default whitlist to get encrypted HLS working again [16:19:59 CET] <cone-465> ffmpeg 03Michael Niedermayer 07master:edc34c937b70: avcodec/utils: Check the return code of av_image_fill_linesizes() [16:49:58 CET] <nevcairiel> so far none of the dca tests failed on any fate box, I wonder when the more rare things like arm and aarch64 run the next ime [16:53:01 CET] <Daemon404> my old pal snow shows up during merge... [16:53:11 CET] Action: Daemon404 swears it uses the entirety of avctx [16:53:35 CET] <nevcairiel> it does use a wide variety of crazy features, yes [17:06:55 CET] <Daemon404> ugh it affects libutvideoenc.cpp [17:07:02 CET] Action: Daemon404 doesnt want to fix that crap [17:13:52 CET] <BBB> Daemon404: having fun with the old clunky code? :D [17:14:51 CET] <Daemon404> BBB, libutvideo doesnt even exist anymore. [17:15:00 CET] <BBB> so remove it? [17:15:03 CET] <BBB> I mean [17:15:04 CET] <BBB> ... [17:15:08 CET] <Daemon404> sure. i can try again. [17:15:11 CET] <BBB> why are we having this discussion :D [17:15:20 CET] <Daemon404> people complain we lack some of its features (10 bit utvideo) [17:15:26 CET] <Daemon404> and that you can still use the 3rd party fork of it [17:15:27 CET] <BBB> IT DOES NOT EXIST ANYMORE [17:15:27 CET] <Daemon404> to build [17:15:35 CET] <BBB> oh ok so it does exist [17:15:47 CET] <Daemon404> in the form of Some GUy maintaining a fork [17:17:07 CET] <nevcairiel> Aren't we all just some guy maintaining some code [17:18:05 CET] <Daemon404> im not sure if it's maintained [17:29:39 CET] <cone-465> ffmpeg 03Michael Niedermayer 07master:908d010b12fa: avfilter/af_sidechaincompress: Free out frame on error [17:38:40 CET] <Daemon404> uh... so is it impossible to add avoptions to c++ based things? [17:38:46 CET] <Daemon404> since it uses designated initializers on a union. [17:39:02 CET] <Daemon404> on a static const var [17:39:15 CET] <BtbN> it should be, just with a very ugly syntax [17:39:43 CET] <Daemon404> how? [17:40:15 CET] <Daemon404> i guess i could have a union of the same type, intiialzie it with that [17:40:26 CET] <Daemon404> which is annoying.. because avoptions use ananonymous union. [17:40:54 CET] <BtbN> iirc it involved implementing a struct that inherits from the main struct and then doing stuff in its constructor. [17:41:16 CET] <Daemon404> hmm actually [17:41:17 CET] <Daemon404> luckily [17:41:24 CET] <Daemon404> the type i want is the unions first element [17:41:29 CET] <Daemon404> so i can initialize it fine [17:41:31 CET] <Daemon404> luck! [17:42:37 CET] <BtbN> you can probably also do { 0, 0, 0, 0, 1234 } style, if it does the assignments from left to right [17:48:42 CET] <BtbN> Great, libva added support for more VP9 profiles and 10bit, but didn't bother bumping the version number [17:49:57 CET] <cone-465> ffmpeg 03Vittorio Giovara 07master:2862b63783b5: lavc: Move prediction_method to codec private options [17:49:58 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:f3af379b5c18: Merge commit '2862b63783b5556f7f3fb2d097629bc6879f833a' [17:50:05 CET] <Daemon404> bloody hell that was an ordeal [17:54:02 CET] <cone-465> ffmpeg 03Vittorio Giovara 07master:5b6f42da98c2: lavc: Move me_penalty_compensation to codec private options [17:54:03 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:43c0298208ad: Merge commit '5b6f42da98c26a8aee8d2c2edfcbd0633ad1c607' [17:54:51 CET] <BBB> this fork business is such a mess [17:54:55 CET] <cone-465> ffmpeg 03Vittorio Giovara 07master:0e9c4fe25407: lavc: Move pre_me to codec private options [17:54:56 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:730d2aabacd6: Merge commit '0e9c4fe254073b209970df3e3cb84531bc388e99' [17:55:01 CET] <Daemon404> THEYRE DONE [17:55:10 CET] <atomnuker> Daemon404: what's the point of removing a field from avctx when a ton of things use it? [17:55:23 CET] <Daemon404> atomnuker, they all use it for different things. [17:55:29 CET] <Daemon404> very different things. [17:55:38 CET] <atomnuker> ah, okay [17:55:42 CET] <Daemon404> they just shoehorned them into the closest avcts field that fit [17:55:50 CET] <Daemon404> pre-private-options [17:56:09 CET] <Daemon404> BBB, the ordeal was mostly fixing snow [17:56:14 CET] <Daemon404> and mpeg*c [17:56:15 CET] <nevcairiel> Daemon404: if you should reach "lavf: allow custom IO for all files" .. ffmpeg already has such a callback, duplicating it seems senseless [17:56:28 CET] <Daemon404> ill check [17:58:07 CET] <cone-465> ffmpeg 03Martin Storsjö 07master:87a814fdce52: libavcodec: Add missing AVClass pointers [17:58:08 CET] <cone-465> ffmpeg 03Luca Barbato 07master:c0c4d7a0a556: configure: Correctly add openssl cflags and libs [17:58:09 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:2880e6810c97: Merge commit '87a814fdce522d45aa31aa258cb5514d7e754bff' [17:58:10 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:27acb64a5337: Merge commit 'c0c4d7a0a556ec66e3068d36a883e84d1efb0690' [17:58:31 CET] <nevcairiel> BBB: like i said some weeks ago, at some point we should discuss if we really want to continue doing this, or just cherry-pick actual improvements and just let them diverge [17:58:56 CET] <nevcairiel> no linux distribution uses libav anymore, so downstreams will just follow us wherever we go [17:59:24 CET] <cone-465> ffmpeg 03Anton Khirnov 07master:d336bfcf69fe: pixdesc: fix and extend doxy for av_pix_fmt_get_chroma_sub_sample() [17:59:25 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:74f5cb0189d6: Merge commit 'd336bfcf69fee159e9dba5e5e486ddb1aba61aab' [17:59:52 CET] <Daemon404> cherry picking is a hell of a lot harder than merging [18:00:01 CET] <kierank> yeah [18:00:04 CET] <Daemon404> for the current time, i prefer to merge [18:00:30 CET] <nevcairiel> not really, git can apply the same conflict resolution, except you need to do a concious decision which to bring over [18:00:34 CET] <BBB> nevcairiel: I have no opinion on merge vs cherrypick [18:01:02 CET] <Daemon404> nevcairiel, it is when you let codebases drift significantly by skipping some e.g. refactoring [18:01:20 CET] <BBB> nevcairiel: Im starting to become more negative over the prospect of this ever being an advantage to anyone, and if it isnt, and people follow us, maybe we should just let libav be [18:01:21 CET] <Daemon404> i used to cherry pick to libav and it was not fun. [18:01:36 CET] <Daemon404> BBB, merging is absolutely an advantage [18:01:46 CET] <Daemon404> and i believe it's partly why ffmpeg 'won' [18:01:46 CET] <BBB> to who [18:01:49 CET] <Daemon404> users. [18:01:59 CET] <BBB> I agree that it was an advantage in the past [18:02:05 CET] <BBB> and I agree its why were doing better than libav [18:02:07 CET] <nevcairiel> honestly in the last half year or so, there was nothing in there worth having [18:02:19 CET] <BBB> Im not sure I agree that continuing this is beneficial for us (compared to doing nothing) [18:02:27 CET] <Daemon404> says the person who doesnt merge anyway [18:03:00 CET] <Daemon404> i think the stuff i just merged, for example, is useful. [18:03:33 CET] <nevcairiel> the time it takes to merge these, you could probably re-do them =p [18:04:00 CET] Action: Daemon404 notes these arguments are the exact same ones libav gave for not merging, and doign cherry picks [18:04:06 CET] <Daemon404> look how well thst turned out [18:04:08 CET] <Daemon404> oh wait. [18:04:09 CET] <nevcairiel> they dont even do those [18:04:15 CET] <nevcairiel> they just ignore us entirely [18:04:20 CET] <wm4> merging is definitely why ffmpeg "won", because it implies it has everything libav does (even if that is not true) [18:04:34 CET] <wm4> sanity for one often wasn't merged [18:04:50 CET] <Daemon404> for the time being with myself merging [18:04:55 CET] <Daemon404> the argument is moot [18:04:59 CET] <Daemon404> you guys dont even have to do anything. [18:06:32 CET] <nevcairiel> just wait until the next evil plan gets pushed to libav, and free your weekends :D [18:07:32 CET] <BBB> Daemon404: so & Im thinking of the long-term mental health of contributors to this project, rather than whether my application will have libav+ffmpeg features next week [18:07:50 CET] <BBB> becuase if you get burned out - and you will - 6 months from now, were all worse off [18:08:19 CET] <cone-465> ffmpeg 03Henrik Gramner 07master:7adcd4e841f3: x86inc: Make cpuflag() and notcpuflag() return 0 or 1 [18:08:20 CET] <cone-465> ffmpeg 03Henrik Gramner 07master:f60f06d9894b: x86inc: Be more verbose in assertion failures [18:08:21 CET] <cone-465> ffmpeg 03Henrik Gramner 07master:715eb7ca24c9: x86inc: Improve FMA instruction handling [18:08:22 CET] <cone-465> ffmpeg 03Henrik Gramner 07master:91ed050f426b: x86inc: Preserve arguments when allocating stack space [18:08:23 CET] <cone-465> ffmpeg 03Henrik Gramner 07master:5ca8e195e51c: x86inc: Use more consistent indentation [18:08:24 CET] <cone-465> ffmpeg 03Henrik Gramner 07master:fd6ecac38eb3: x86inc: Simplify AUTO_REP_RET [18:08:25 CET] <cone-465> ffmpeg 03Henrik Gramner 07master:002c47798da0: x86inc: Avoid creating unnecessary local labels [18:08:26 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:9de85c544aaa: Merge commit '002c47798da0c43a053822c8041144798d49ed84' [18:08:45 CET] <Daemon404> [17:07] <@BBB> becuase if you get burned out - and you will - 6 months from now, were all worse off <-- considering i average like 2 patches a year [18:08:49 CET] <Daemon404> "worse off" [18:12:03 CET] <BBB> maybe its a dutch expression [18:12:03 CET] <BBB> sorry [18:12:07 CET] <BBB> it means were all fucked [18:12:54 CET] <cone-465> ffmpeg 03Geza Lore 07master:cc602061ee86: x86inc: Add debug symbols indicating sizes of compiled functions [18:12:55 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:4736f8115be4: Merge commit 'cc602061ee860b041013397e27a036b85cd87b09' [18:13:02 CET] <Daemon404> i dont see how [18:14:17 CET] <cone-465> ffmpeg 03Anton Khirnov 07master:68395f8c9939: qsvenc: fix a typo [18:14:18 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:06278265239f: Merge commit '68395f8c99393c281a08139d20a7a04398b2fd04' [18:14:59 CET] <BBB> we lose 2 patches a year, we lose a positive voice in this irc channel, a reviewer on the mailinglist, heck even a community person working at some us company thats into video streaming [18:15:07 CET] <BBB> no, I couldnt possibly see how any of these would be bad for us [18:15:09 CET] <nevcairiel> Honestly the reason why I think merging should be re-considered is because the quality and substance of their changes has gone down greatly, their "review" process is a sham really [18:15:13 CET] <BBB> o_O [18:15:19 CET] <kierank> nevcairiel: yes that's kind of the problem [18:15:35 CET] <Daemon404> that is true [18:16:10 CET] <Daemon404> got to 'lavf: allow custom IO for all files' [18:17:05 CET] <nevcairiel> for example, no-one is going to review every single of anton's next big refactoring pushes, so there is two choices, either I do it now on their ML, or I do it when I merge ... since I need to review every change anyway when merging since our code is different, I tend to do it then and fix it as appropriate =p [18:17:15 CET] <nevcairiel> or replace "I" with whoever merges at that instance [18:18:39 CET] <atomnuker> Daemon404: are you done with pushes for now? I have some stuff okay'd [18:18:46 CET] <Daemon404> atomnuker, yes [18:18:47 CET] <Daemon404> im thinking [18:19:09 CET] <Daemon404> nevcairiel, thats a bad example to use [18:19:21 CET] <Daemon404> because i think almost all of anton's changes are very useful [18:19:28 CET] <Daemon404> and would be picked anywya [18:19:41 CET] <kierank> yes TEP was what took libav* from a neckbeard project into the 21st century [18:20:03 CET] <nevcairiel> like I said, free your weekends, because it requires every single demuxer and whatnot to be changed in one step [18:20:21 CET] <Daemon404> nevcairiel, part of the problem is the way we merge [18:20:25 CET] <Daemon404> it's One Guy Who Merges [18:20:28 CET] <Daemon404> instead of a team effort. [18:20:34 CET] <nevcairiel> the last TEP was a team effort [18:20:37 CET] <nevcairiel> refcounting [18:20:41 CET] <Daemon404> yes [18:20:43 CET] <Daemon404> and only that. [18:20:45 CET] <cone-465> ffmpeg 03Rostislav Pehlivanov 07master:3bbe7862ec81: diracdec: move the MAX_DWT_LEVELS macro to dirac.h [18:20:46 CET] <cone-465> ffmpeg 03Rostislav Pehlivanov 07master:f02103036526: diradec: split tables away to a separate diractab file [18:21:32 CET] <Daemon404> anyway [18:21:36 CET] <Daemon404> on to something more relevant [18:21:39 CET] <Daemon404> [17:16] <@Daemon404> got to 'lavf: allow custom IO for all files' [18:21:48 CET] <Daemon404> you suggested i skip [18:21:53 CET] <Daemon404> but that would be an API breakage [18:22:20 CET] <nevcairiel> the alternative is providing two callbacks that do the same thing [18:22:23 CET] <nevcairiel> thats worse [18:22:23 CET] <nevcairiel> =p [18:22:40 CET] <Daemon404> do they do exactly the same thing? [18:22:52 CET] <nevcairiel> they get called when a new file is supposed to be opened [18:23:08 CET] <Daemon404> doesnt answer me :P [18:23:10 CET] <nevcairiel> not sure how widely ours is used, but its in the AVFormatContext [18:23:45 CET] <nevcairiel> i think theirs is a bit more generic, ours is meant more as a filterign function [18:23:53 CET] <nevcairiel> but still plenty overlap [18:23:59 CET] <Daemon404> hmm. [18:25:01 CET] <Daemon404> how have we handled such scenarios in the past [18:25:17 CET] <nevcairiel> usually by duplication and deprecating our variant [18:25:24 CET] <nevcairiel> no clue how old ours even is [18:25:40 CET] <Daemon404> yeah, but if they do separate things [18:25:44 CET] <Daemon404> then thats not possible [18:30:54 CET] <Daemon404> not merging anymore today though [18:46:29 CET] <Daemon404> rcombs, ^ [18:46:37 CET] <Daemon404> either the sidx index is wrong, or code is busted [19:21:30 CET] <wm4> remind me, what is the theoretical maximum h264 can delay a frame? shouldn't it be 16 frames? [19:21:39 CET] <kierank> yes [19:22:17 CET] <wm4> ok [19:23:25 CET] Action: Daemon404 allocs 16 4k cinema frames [19:25:38 CET] <wm4> I guess I don't quite understand the relation between input packets and frame output logic, and what has_b_frames has to do with it [19:26:51 CET] <nevcairiel> has_b_frames is a measure of amount of delay in this particular stream [19:28:34 CET] <wm4> so if has_b_frames is 2, you need to feed the decoder 3 packets to get 1 frame, right [19:28:53 CET] <iive> yes, the decoder could "store" 2 frames [19:29:00 CET] <iive> before output anything. [19:29:17 CET] <wm4> but in that scenario, how could it reorder a frame to output it much later than 2 or 3 frames? [19:29:42 CET] <iive> let's say we have IBBBBB...BBBI [19:29:59 CET] <iive> the B frame references the two I frames. [19:30:23 CET] <iive> the decoder stream looks IIBBBBB...BBB [19:31:06 CET] <BBB> iive: lies! [19:31:06 CET] <nevcairiel> wm4: just because it stores only 2 frames doesnt mean that one of those couldnt be stored for a long time [19:31:08 CET] <wm4> oh I see [19:31:13 CET] <wm4> yeah [19:31:31 CET] <wm4> but then, why would that be limited by 16? [19:31:51 CET] <iive> max_b_frames ? [19:32:19 CET] <BBB> 16 is the max number of refs [19:32:31 CET] <BBB> not the max number of time units that refs can be stored [19:33:00 CET] <nevcairiel> its also the max size of the DPB, but that is closely related to ref frames [19:33:04 CET] <iive> wm4: the thing is, that it the above examples, it stores only the second I frame. [19:33:12 CET] <BBB> DPB is basically n_refs + 1 [19:33:17 CET] <BBB> so I guess max_refs is then 15 [19:33:22 CET] <BBB> or something like that [19:33:37 CET] <BBB> or in other words, cur_frame is a ref also [19:33:43 CET] <iive> or rather, the future frame and the previous one. [19:55:36 CET] <wm4> is max_dec_frame_buffering what I'm looking for? [19:56:57 CET] <nevcairiel> no, num_reorder_frames [19:57:02 CET] <nevcairiel> one before that [19:57:26 CET] <nevcairiel> but its only set in very few bitstreams [20:02:53 CET] <wm4> what I'm looking for is the number of frames the output of a picture can be delayed maximally, and I don't see how num_reorder_frames could be that value [20:03:16 CET] <RiCON> Daemon404: https://j.fsbn.eu/wxDK.txt [20:03:24 CET] <nevcairiel> wm4: 16 [20:03:32 CET] <nevcairiel> but num_reorder_frames is that number [20:03:36 CET] <nevcairiel> but its hardly reliable [20:03:48 CET] <nevcairiel> bvecause its rarely available [20:05:56 CET] <Daemon404> RiCON, i guess ill hunt down whatever fork of utvideo im supposed to use and try [20:06:04 CET] <Daemon404> i would ask, of course: wtf do you use it for [20:06:18 CET] <wm4> I'm trying to understand out why using has_b_frames packets for reordering PTS is enough to handle avi timestamps, but not enough after decoding [20:06:44 CET] <RiCON> i don't, personally, but those don't seem like errors from utvideo [20:06:57 CET] <Daemon404> theyre not [20:07:05 CET] <Daemon404> but if you dont use it, why build it [20:07:29 CET] <Daemon404> [19:05] <@Daemon404> RiCON, i guess ill hunt down whatever fork of utvideo im supposed to use and try <-- referring to the fact that upstream utvideo does nto actually build into libutvideo. [20:07:58 CET] <RiCON> i help maintain a building script that includes libutvideo as feature [20:08:08 CET] <RiCON> zeranoe has it too [20:08:10 CET] <Daemon404> ... c++ cant do some_array[] = {1,2,3}? [20:08:15 CET] <Daemon404> i need to have [3]? [20:08:16 CET] <Daemon404> really? [20:08:25 CET] <RiCON> i use https://github.com/qyot27/libutvideo.git [20:08:35 CET] <Daemon404> RiCON, yes he just builds with everything possible [20:08:40 CET] <Daemon404> 90% is useless [20:08:59 CET] <RiCON> just give me a reason to not include it :) [20:09:19 CET] <Daemon404> not one he'll accept [20:09:24 CET] <Daemon404> im dling/fixing [20:10:38 CET] <nevcairiel> Daemon404: such an array definition should be valid in c++ [20:12:34 CET] <Daemon404> ffconf.RAvjgsDs.c:(.text+0x0): multiple definition of `main' [20:12:34 CET] <Daemon404> /home/daemon404/dev/f/u/lib/libutvideo.a(Coefficient.o):Coefficient.cpp:(.text.startup+0x0): first defined here [20:12:41 CET] <Daemon404> yes this is a quality fork/library [20:12:50 CET] <Daemon404> A+ [20:13:19 CET] <JEEB> lol [20:13:31 CET] <Daemon404> it fails to configure because of that [20:13:54 CET] <JEEB> because it defines main itself :V [20:14:29 CET] <Daemon404> /* This file is NOT a part of "utv_core" module. */ [20:14:30 CET] <Daemon404> from that file [20:14:35 CET] <Daemon404> so it shuldnt even be included [20:14:38 CET] <Daemon404> quality fork, etc [20:14:38 CET] <JEEB> :DDDD [20:14:40 CET] <JEEB> yeah [20:14:47 CET] <Daemon404> how did this ever work [20:15:08 CET] <RiCON> btw, you're using HEAD and not master, right? [20:15:19 CET] <JEEB> uhh [20:15:23 CET] <JEEB> HEAD is a HEAD from some branch [20:15:25 CET] <RiCON> HEAD as in 15.1.0 [20:15:26 CET] <JEEB> master is a branch [20:15:27 CET] <JEEB> :V [20:15:28 CET] <Daemon404> ... [20:15:33 CET] <Daemon404> HEAD of master [20:15:37 CET] <Daemon404> like 99% of people will use [20:15:50 CET] <RiCON> yeah, that never worked [20:15:54 CET] <Daemon404> A+ [20:15:57 CET] <RiCON> try with 15.1.0 [20:16:20 CET] <Daemon404> daemon404@bbvm:~/dev/f/libutvideo$ git branch [20:16:20 CET] <Daemon404> * 15.1.0 [20:16:21 CET] <Daemon404> well. [20:16:22 CET] <Daemon404> i was. [20:16:25 CET] <JEEB> :D [20:16:33 CET] <RiCON> hm, wonder how zeranoe makes it work then [20:16:44 CET] <Daemon404> he probably stashed a .a somewhere [20:16:47 CET] <Daemon404> and manualyl fixed [20:16:53 CET] <Daemon404> i did say this was crap [20:17:05 CET] <RiCON> oh, he doesn't. [20:17:11 CET] <RiCON> why did i think he included it [20:17:42 CET] <JEEB> because he does the kitchen sink [20:17:43 CET] <Daemon404> regardless, i guess ill fix ffmpeg's C++ [20:17:49 CET] <Daemon404> otherwise someone will harass me' [20:18:01 CET] <Daemon404> even if NOTHING builds libutvideo in a way we can use [20:21:42 CET] <RiCON> what does a working libutvideo have that native utvideo doesn't, again? [20:22:03 CET] <nevcairiel> 10-bit [20:22:32 CET] <Daemon404> yes [20:27:57 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:0ea716f70b0f: libutvideo: Unbreak [20:36:26 CET] <jamrial> Daemon404: you could make the AVCodec and AVClass use initializers while at it [20:36:36 CET] <jamrial> that way you'd get rid of all the pointless NULL lines [20:36:39 CET] <Daemon404> no. i cant [20:36:41 CET] <Daemon404> it's C++. [20:37:01 CET] <jamrial> ah [20:37:49 CET] <J_Darnley> Isn't it such a great language. [20:37:54 CET] <nevcairiel> its intentionally not supported because they dont like that style in C++, instead use constructors [20:40:46 CET] <wm4> nevcairiel: but classes now support static intiializers, and there are initializer lists which look like the C thing except they are 1000% more complex [20:46:07 CET] <llogan> kierank: why is grub stuff being held back on ffmpeg1? [20:48:38 CET] <Daemon404> ...grub [20:48:40 CET] <Daemon404> ? [20:54:06 CET] <Compn> ffmpeg bootloader ? [20:54:16 CET] <michaelni> i did put it on hold because kieran said grub updates break stuff [20:54:24 CET] <michaelni> didnt want to find out if thats true ;) [20:55:10 CET] <michaelni> break due to raid&grub&whatever IIRC [20:55:18 CET] <llogan> ok. i never had it break anything, but i'm not at all interested in dealing with grub. [20:55:55 CET] <J_Darnley> Oh I think I get it now. "ffmpeg1" is some computer somewhere and the grub package is not being updated on it. [20:57:14 CET] <Daemon404> ah. [20:59:35 CET] <llogan> J_Darnley: you are correct. you win a washing machine...or what's in the box! [20:59:50 CET] <wm4> take the box! [20:59:51 CET] <J_Darnley> What's in the box! [21:00:02 CET] <llogan> you win ffmpeg1! you are now the maintainer! [21:00:14 CET] Action: J_Darnley cackles, evilly. [21:00:40 CET] <llogan> cone-465 ffmpeg Lou Logan master:02948sif: MAINTAINERS: James Darnley is now server maintainer [21:00:54 CET] <llogan> J_Darnley: ping [21:01:00 CET] <llogan> grub is broken [21:08:21 CET] <wm4> hm, the claws-mail databases is getting corrupted again [21:10:04 CET] <llogan> wm4: what's the symptoms? I use claws and haven't had issues [21:12:46 CET] <Compn> claws gets stupid after a couple thousand mails. i keep deleting old ones... [21:13:11 CET] <wm4> llogan: when mails from one folder suddenly show up in the wrong one [21:13:19 CET] <wm4> it's because its index is somehow corrupted [21:16:27 CET] <llogan> i may have seen that once or twice, but it "fixes" itself after reopening folder. have 65k messages among 12 folders. (vast majority FFmpeg mailing lists) [21:16:56 CET] <wm4> not sure how many I have, must be over 100k [21:17:14 CET] <wm4> ffmpeg-devel alone is 47k [23:03:38 CET] <RiCON> Daemon404: apparently there's patches to make 15.4.0 compile with linux [23:03:47 CET] <RiCON> probably doesn't work with ffmpeg as is [23:03:48 CET] <Daemon404> A+ [23:03:59 CET] <RiCON> trying now [23:07:40 CET] <nevcairiel> Daemon404: you broke mjpegenc =p [23:08:42 CET] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/mjpegenc.c;h=b751… .. listing the same initializer twice causes the c99 converter to assert (priv_class) [23:11:06 CET] <Daemon404> shit [23:11:13 CET] <Daemon404> i didnt even get a warning about that [23:11:18 CET] <Daemon404> git merge happily placed it in [23:11:20 CET] <Daemon404> it seems. [23:11:48 CET] <Daemon404> i even ran fate like 10 times [23:11:50 CET] <nevcairiel> yeah sometimes it likes to do that, happened once before, which is why I remember what the problem was [23:12:03 CET] <nevcairiel> and compilers generally dont complain if they both init to the same value [23:12:05 CET] <Daemon404> gcc and clang are quite happy with it too [23:12:10 CET] <Daemon404> not even a peep [23:12:55 CET] <Daemon404> nevcairiel, care to push a fix? [23:13:02 CET] <Daemon404> im not logged in on ym dev box [23:13:04 CET] <Daemon404> and am lazy. [23:13:15 CET] <nevcairiel> same, about to head to bed [23:13:27 CET] <Daemon404> lol damn. [23:14:58 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:c4ef6c883bb6: mjpegenc: Remove duplicate initializer [23:15:00 CET] <Daemon404> there [23:17:51 CET] <jamrial> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/aes_ctr.c;h=234354… shouldn't this be av_free(a)? [23:18:54 CET] <Daemon404> looks like it... [23:19:19 CET] <Daemon404> eh... whats with the untypedef'd and all caps struct [23:19:37 CET] <Daemon404> oh it is typedef'd... just not in the func [23:35:00 CET] <cone-465> ffmpeg 03James Almer 07master:0711c5bfb8b4: avutil/aes_crt: free AVAESCTR struct properly [23:38:48 CET] <RiCON> Daemon404: looks like it'd need some updating to the code https://j.fsbn.eu/EvJH.txt https://www.diffchecker.com/upcpgqad [23:39:46 CET] <Daemon404> utvideo has no api. [23:39:49 CET] <Daemon404> it's not a library. [23:40:17 CET] <Daemon404> it's an unwinnable game of chase [23:41:00 CET] <RiCON> yeah, i don't care either [23:41:20 CET] <Daemon404> even the fork im supposed to use is apparently not maintained or tested [23:41:23 CET] <Daemon404> so uh... :V [23:41:23 CET] <llogan> just get rid of it [23:41:27 CET] <Daemon404> I WANT TO [23:42:02 CET] <llogan> i know...i submitted a patch to do so [23:42:10 CET] <Daemon404> so did i. [23:42:16 CET] <Daemon404> ill send one tomorrow again [23:42:33 CET] <Daemon404> now it's more broken than ever. [23:43:45 CET] <llogan> refer to "[PATCH] libutvideo: remove libutvideo wrapper" if you want to see old discussion [23:44:54 CET] <Daemon404> without lookinh, 5 bucks says stephen hutchenson was fighting for it almost solely [23:45:28 CET] <Daemon404> (he maintains the fork that isnt maintained) [23:45:31 CET] <RiCON> qyot? [23:45:35 CET] <Daemon404> yes [23:46:02 CET] <RiCON> the 15.1 branch still works, more or less, at least in mingw [23:46:25 CET] <Daemon404> except for that whole 'main' thing. [23:46:27 CET] <JEEB> also re 10bit [23:46:28 CET] <JEEB> The wrappers also don't support the 10-bit variants of Ut Video's [23:46:29 CET] <JEEB> 4:2:2 codec, but when I last checked, the native one didn't either. [23:47:03 CET] <RiCON> unless he somehow picks up on updating the wrappers and the fork [23:47:13 CET] <JEEB> ,,, and then mini adds support to 10bit!? [23:47:35 CET] <JEEB> also qyot doesn't even fight for the wrapper [23:47:39 CET] <Daemon404> o [23:47:45 CET] <jamrial> hey, times they are a changin' [23:47:46 CET] <jamrial> we got rid of quvi, aacplus and vo-aac [23:47:50 CET] Action: Daemon404 sedates JEEB [23:47:51 CET] <jamrial> we can get rid of this one [23:48:01 CET] <JEEB> From my perspective as the one taking the Ut Video release zips [23:48:01 CET] <JEEB> and updating libutvideo itself, I don't particularly care whether the [23:48:01 CET] <JEEB> lib wrapper is removed. Not that I can provide any insight beyond [23:48:02 CET] <JEEB> that, since I only make sure the lib still compiles. [23:48:15 CET] Action: TD-Linux goes on doom9 and realizes people are still installing Ut Video [23:48:36 CET] <JEEB> TD-Linux: it has things for all major multimedia frameworks [23:48:39 CET] <JEEB> it just makes sense [23:48:56 CET] <JEEB> it's a lossless format, pretty fast and with good VFW/QT/MF support [23:48:59 CET] <llogan> i use it when i have to use Premiere 'n junk and need intermediates [23:49:13 CET] <TD-Linux> QT hasn't had pluggable decoders in a long time [23:49:24 CET] <Daemon404> no, the api has been deprecated [23:49:26 CET] <JEEB> then I wonder what this module for it is then :P [23:49:27 CET] <Daemon404> everyone still develops for it. [23:49:30 CET] <Daemon404> because you have to. [23:49:43 CET] <JEEB> and probably what Dae says :P [23:49:48 CET] <TD-Linux> Daemon404, is there a way to install them system wide still? [23:49:55 CET] <Daemon404> that, i am unsure of [23:50:15 CET] <TD-Linux> or is it just an API that programs manually implement themselves now? [23:50:23 CET] <JEEB> http://umezawa.dyndns.info/archive/utvideo/utvideo-15.4.0-macosx.zip [23:50:26 CET] <JEEB> feel free to try? [23:50:31 CET] <Daemon404> i wouldnt be surprised if major NLEs did [23:50:37 CET] <JEEB> from http://umezawa.dyndns.info/wordpress/?p=5754#more-5754 [23:50:37 CET] <TD-Linux> IIRC someone had looked at this for XiphQt and determined it wasn't possible systemwide anymore at least [23:50:55 CET] <JEEB> at least it seems to get used in NLEs [23:50:59 CET] <JEEB> so it seems to work [23:51:31 CET] <JEEB> also huh, umezawa seems to have an internal git repo now? [23:51:39 CET] <RiCON> the patches http://git.pld-linux.org/?p=packages/utvideo.git;a=tree [23:51:42 CET] <JEEB> since he notes that his zipballs are now done with git archive [23:51:56 CET] <Daemon404> RiCON, oh good random packager patches [23:51:59 CET] <Daemon404> my favourite [23:52:07 CET] <Daemon404> to a fork with further patches [23:52:24 CET] <Daemon404> ah no it uses the zip. but still. [23:52:30 CET] <RiCON> and it's still your makefile [23:52:48 CET] <Daemon404> i also wrote the .cpp files [23:52:51 CET] <Daemon404> it haunts me to this day [23:53:03 CET] <JEEB> oh nice [23:53:05 CET] <JEEB> https://github.com/umezawatakeshi/utvideo [23:53:08 CET] <JEEB> official github [23:53:09 CET] <JEEB> :V [23:53:29 CET] <Daemon404> wow real VCS [23:53:32 CET] <Daemon404> no more zip drops [23:53:53 CET] <RiCON> still sjis though [23:54:01 CET] <JEEB> he still does them but I started looking at his stuff after I read the part "this zipball was made with git archive" [23:54:21 CET] <JEEB> RiCON: windows still makes it very easy to create files with that [23:54:28 CET] <JEEB> if you are on japanese locale [23:55:09 CET] <JEEB> also I think the gplv2 being sjis is a historical thing [23:55:18 CET] <JEEB> the japanese translation probably was encoded as such [23:55:31 CET] <JEEB> because that way it would open in windows's text editors :P [23:55:47 CET] <RiCON> doesn't notepad work with utf-8 [23:56:02 CET] <JEEB> only with stuff that *nix editors don't usually write [23:56:27 CET] <JEEB> but yeah, japanese gplv2 file from 2002 :P [23:56:31 CET] <JEEB> are you surprised it's in SJIS? [23:58:29 CET] <TD-Linux> wow github correctly converts encoding, neat [00:00:00 CET] --- Thu Feb 4 2016

1 0

ffmpeg.log.20160203
by burek 04 Feb '16

04 Feb '16

[00:10:35 CET] <jkqxz> shadow42085: You are in the right channel. Linux native packages are not relevant to a cross compile. Have you looked at <https://trac.ffmpeg.org/wiki/CompilationGuide/CrossCompilingForWindows>? [00:15:02 CET] <shadow42085> jkqxz i have been there and they dont tell me which packages only scripts that can build the environment needed but i want to incorporate the Cross-Compilers into my system's native build path [00:18:56 CET] <jkqxz> Reading one of those scripts will tell you what they build (there is a lot). [00:20:39 CET] <jkqxz> What are you actually wanting at the end of it, when you say it should be incorporated into your system's native build path? [00:22:24 CET] <shadow42085> i dont want extra directories i have to call like what it say's in the ubuntu/debian compilation guide [00:29:06 CET] <shadow42085> I have already installed mingw32 libs [00:29:11 CET] <jkqxz> Can you be a bit clearer about what extra directories you are referring to? [00:29:44 CET] <shadow42085> ffmpeg_bulid bins [00:30:39 CET] <shadow42085> where as they can be in my systems native /bins diectory or other native directories [00:31:13 CET] <shadow42085> hope I am not to confusing i am trying to be direct as possible [00:33:21 CET] <jkqxz> Nothing which has been cross-built should be in your system directories, because they are not usable there. Cross-compiling, you will make a separate sysroot containing all of the cross-built libraries and headers which go into ffmpeg, then copy the final pieces to Windows to actually use. [00:35:56 CET] <jkqxz> Some of the build tools (the compiler, etc.) will be usable on the host, and they could go in system directories with suitable naming to distinguish them from native tools (hence i686-w64-mingw32-gcc, etc.). [00:36:52 CET] <shadow42085> ok [00:37:57 CET] <shadow42085> so i just need to cross-compile the libs in the guide? [00:39:40 CET] <jkqxz> Pretty much, yes. (And the scripts to do it for you exist because this takes a long time and is highly finicky.) [00:40:55 CET] <shadow42085> ok [00:44:06 CET] <shadow42085> being finicky is normal since we are going from a native linux system to windows and windows itself is finicky as well [00:53:09 CET] <shadow42085> well thanks anyways [01:43:48 CET] <aolko> hi guys [01:44:22 CET] <aolko> any ideas how to _only overlay image_ on a hls live stream and return it back? [04:30:53 CET] <barry_> hello. can anybody out there help me with compiling ffmpeg on a RPi 2....I've tried every resource on the Net and I'm stuck with a few problems [04:31:38 CET] <waressearcher2> barry_: hallo und herzlich willkommen [04:31:47 CET] <barry_> gates [04:32:45 CET] <barry_> and danke [04:37:18 CET] <klaxa> barry_: what problems did you run into? [04:38:59 CET] <barry_> hi klaxa, I can compile using the instructions for debian and then I send it off to youtube...but the straem has a glitch about every 5 seconds. it starts out strong and then degrades [04:39:16 CET] <klaxa> what [04:39:30 CET] <klaxa> so you got it to compile? [04:39:41 CET] <barry_> yes I did [04:40:12 CET] <klaxa> and by "send it off to youtube" you mean stream some video? [04:40:19 CET] <barry_> but I don't know if I am using the correct flags [04:40:22 CET] <klaxa> pastebin your command with output on pastebin or something [04:40:23 CET] <barry_> yep [04:40:49 CET] <barry_> hang on an I'll get it [04:42:08 CET] <barry_> raspivid -o - -t 0 -fps 30 -b 5000000 | ffmpeg -re -ar 44100 -ac 2 -acodec pcm_s16le -f s16le -ac 2 -i /dev/zero -f h264 -i - -vcodec copy -acodec aac -ab 128k -g 50 -strict experimental -f flv rtmp://a.rtmp.youtube.com/live2/##mykey## [04:42:39 CET] <barry_> this is the input side [04:43:58 CET] <klaxa> are those the settings recommended by youtube? [04:44:08 CET] <barry_> oh darn it...I deleted my output [04:44:09 CET] <klaxa> ah wait [04:44:26 CET] <klaxa> it's definitely not an issue with ffmpeg [04:44:31 CET] <klaxa> since it's not re-encoding the video [04:44:34 CET] <klaxa> i think? [04:44:48 CET] <klaxa> did you try to play whatever raspivid outputs locally? over the network or something? [04:45:05 CET] <barry_> I think that is true as I have read tat it is just copying it? [04:45:09 CET] <klaxa> like: raspivid [...] | nc -l 1234 [04:45:27 CET] <klaxa> and on the client: nc <ip of raspi> 1234 | mpv - [04:45:30 CET] <klaxa> or vlc or whatever [04:45:59 CET] <klaxa> yes, with the settings you provided, ffmpeg will copy the video stream and add a silent audio stream [04:46:13 CET] <barry_> I'm just getting the hang of it all, but I did follow some instructions for setting up a local webserver and the delay was about 5 seconds [04:46:23 CET] <klaxa> although i'm not sure you can do -g 50 [04:46:41 CET] <klaxa> -g 50 means "make it an I-Frame every 50 frames" [04:46:48 CET] <klaxa> which you cannot influence if you are not encoding [04:48:42 CET] <barry_> there's a guy who posted the input and he used a docker container for the binaries....and his youtube stream is incredible, but I haven't been able to reproduce his work [04:49:21 CET] <barry_> I'll have to stop by and talk to you folks tomorrow night after I get all of my ducks in a row [04:49:52 CET] <klaxa> ok [04:49:58 CET] <barry_> can I post a URL here for you to look at? [04:50:43 CET] <barry_> etiquette wise? [07:11:35 CET] <Marcurling> Can't ffmpeg output.mkv ? [07:12:49 CET] <Marcurling> got Unable to find a suitable output format for 'pipe:' pipe:: Ivalid argument trying to. [07:14:20 CET] <relaxed> that's not a complete ffmpeg command [07:15:30 CET] <Marcurling> ffmpeg -vcodec copy -acodec copy -i input.mp4 output.mkv [07:16:32 CET] <relaxed> ffmpeg -i input.mp4 -vcodec copy -acodec copy output.mkv [07:16:54 CET] <Marcurling> Gives [NULL @ 000000000261f680] Unable to find a suitable output format for 'pipe:' [07:16:54 CET] <Marcurling> pipe:: Invalid argument [07:25:41 CET] <Marcurling> >ffmpeg -vcodec copy - acodec copy -i "Doctor.Who.(2005).9x07.Vérité.Ou.Conséquences.(Part.1).FR.LD. [07:25:41 CET] <Marcurling> WEBRip.x264-LiBERTY.[tvu.org.ru].mp4" output.mkv [07:25:41 CET] <Marcurling> ffmpeg version N-78263-g5fc310f Copyright (c) 2000-2016 the FFmpeg developers [07:25:41 CET] <Marcurling> built with gcc 5.3.0 (GCC) [07:25:41 CET] <Marcurling> configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzli [07:25:42 CET] <Marcurling> b --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libblu [07:25:44 CET] <Marcurling> ray --enable-libbs2b --enable-libcaca --enable-libdcadec --enable-libfreetype --enable-libgme --enab [07:25:46 CET] <Marcurling> le-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enab [07:25:48 CET] <Marcurling> le-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger [07:25:50 CET] <Marcurling> --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --ena [07:25:52 CET] <Marcurling> ble-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable- [07:25:54 CET] <Marcurling> libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-lzma --enable-d [07:25:56 CET] <Marcurling> ecklink --enable-zlib [07:25:58 CET] <Marcurling> libavutil 55. 17.100 / 55. 17.100 [07:26:00 CET] <Marcurling> libavcodec 57. 24.101 / 57. 24.101 [07:26:02 CET] <Marcurling> libavformat 57. 24.100 / 57. 24.100 [07:26:04 CET] <Marcurling> libavdevice 57. 0.101 / 57. 0.101 [07:26:06 CET] <Marcurling> libavfilter 6. 28.100 / 6. 28.100 [07:26:10 CET] <Marcurling> libswscale 4. 0.100 / 4. 0.100 [07:26:12 CET] <Marcurling> libswresample 2. 0.101 / 2. 0.101 [07:26:14 CET] <Marcurling> libpostproc 54. 0.100 / 54. 0.100 [07:26:16 CET] <Marcurling> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Doctor.Who.(2005).9x07.V®rit®.Ou.Cons®quences.(Part.1).F [07:26:19 CET] <Marcurling> R.LD.WEBRip.x264-LiBERTY.[tvu.org.ru].mp4': [07:26:21 CET] <Marcurling> Metadata: [07:26:23 CET] <Marcurling> major_brand : isom [07:26:25 CET] <Marcurling> minor_version : 1 [07:26:27 CET] <Marcurling> compatible_brands: isom [07:26:29 CET] <Marcurling> creation_time : 2016-01-23 17:33:45 [07:26:31 CET] <Marcurling> Duration: 00:45:27.68, start: 0.000000, bitrate: 1131 kb/s [07:26:33 CET] <Marcurling> Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709/unknown/unknown), 72 [07:26:35 CET] <Marcurling> 0x404 [SAR 1:1 DAR 180:101], 969 kb/s, 25 fps, 25 tbr, 100 tbn, 50 tbc (default) [07:26:37 CET] <Marcurling> Metadata: [07:26:41 CET] <Marcurling> creation_time : 2016-01-23 08:03:31 [07:26:43 CET] <Marcurling> handler_name : Doctor.Who.2005.S09E07.FRENCH.LD.WEB-DL.x264-LiBERTY [07:26:45 CET] <Marcurling> Stream #0:1(fre): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 157 kb/s (default [07:26:47 CET] <Marcurling> ) [07:26:49 CET] <Marcurling> Metadata: [07:26:51 CET] <Marcurling> creation_time : 2016-01-23 17:33:48 [07:26:53 CET] <Marcurling> handler_name : GPAC ISO Audio Handler [07:26:55 CET] <Marcurling> [NULL @ 000000000241f6a0] Unable to find a suitable output format for 'pipe:' [07:26:57 CET] <Marcurling> pipe:: Invalid argument [07:26:59 CET] <Marcurling> ooops [07:27:56 CET] <relaxed> oops indeed, don't do that again [07:28:28 CET] <Marcurling> never used pastedbin, sorry [07:29:29 CET] <relaxed> it's a website where you paste your output there and then give us the URL [07:31:09 CET] <Marcurling> I did but... which function should I use then ? [07:35:14 CET] <Marcurling> Should be http://pastebin.com/7eK4VvgB [07:36:16 CET] <relaxed> ffmpeg -i input <other options here> output [07:37:28 CET] <relaxed> hmm, if that doesn't work rename the input to Doctor.Who.9x07.mp4 and try again [07:39:19 CET] <Marcurling> ffmpeg -i input <other options here> output is working fine, thanks ! [09:36:22 CET] <Artix> Hello, anyone have a command line for SD PAL v210 to d10 please ? i have tried http://pastebin.com/Hst5pbcx but i'm not happy with it. [10:32:38 CET] <tfilk> I want to dump only audio track from video: "ffmpeg -i input.avi -ac 2 -ar 44100 -ab 192k -y -f wav 2.wav", but there are 3 tracks, how to choose the track ? what option ? [10:33:26 CET] <tfilk> is it "-map 0:a:0" ? [10:33:38 CET] <relaxed> tfilk: that's the first audio stream [10:34:13 CET] <Mavrik> Yep, "0" - 1st input file, "a" - audio, "0" - 1st stream [10:36:25 CET] <tfilk> so I want to dump all 3 audio streams in different files, so should I go one by one "-map 0:s:0, -map 0:s:1, -map 0:s:2" or there is one command that do all stuff at once / [10:36:28 CET] <tfilk> ? [10:36:44 CET] <relaxed> https://trac.ffmpeg.org/wiki/Map [10:36:59 CET] <relaxed> :s: is subs [10:39:45 CET] <tfilk> also ffprobe shows streams as: "Stream #0:1(en): Audio, Stream #0:2(en): Audio, Stream #0:3(en): Audio, ", so it starts from "1" so there is no "-map 0:a:0" stream ? so all streams will be numbered as "-map 0:a:1, -map 0:a:2, -map 0:a:3" or "-map 0:a:0, -map 0:a:1, -map 0:a:2" ? [10:39:46 CET] <relaxed> you can use one instance or three [10:40:45 CET] <relaxed> no, the count starts at 0. You can use -map 0:1 if that's easier for you [10:41:25 CET] <tfilk> thanks [10:41:42 CET] <relaxed> so "-map 0:a:0" is the same as "-map 0:1" in your example [17:02:55 CET] <MINIMAN10000> Out of curiosity when using h264 is it possible to improve black gradients at a constant bitrate? [17:49:35 CET] <kbarry> I'm experiencing an audible phenomenon when listening to an HLS stream i'm generating (HLS generated by Wowza) [17:49:42 CET] <kbarry> with loglevel set to 56, I am seeing an error in the logs (Header missing) [17:50:19 CET] <kbarry> followed shortly by a clicki/micro-silence, or a short "vrrrp" (like a tiny amount of sped-up audio) [17:51:40 CET] <kbarry> coincidentally, when I use VLC (With verbose logging on), I see a error at the same time, (different error) [19:19:02 CET] <RazWelles> Hey, I'm trying to point ffmpeg2theora to a custom build of ffmpeg? [19:19:23 CET] <RazWelles> I set the pkg_config_path variable to the ffmpeg git directory but no luck [19:20:45 CET] <J_Darnley> "no luck" is not an error message [19:20:57 CET] <RazWelles> sec [19:22:30 CET] <RazWelles> http://hastebin.com/bicinojoco.vbs [19:23:03 CET] <RazWelles> So I have ffmpeg compiled in another directory which I've set in PKG_CONFIG_PATH [19:23:26 CET] <J_Darnley> That must be the worst paste site I have ever seen [19:23:56 CET] <J_Darnley> Is there not a better, more detailed log? [19:25:20 CET] <RazWelles> Not really, it just lists the libraries individually, and I can paste that- where it says (no) I've actually had it say yes last night by manually adding each ffmpeg subdirectory to the PKG_CONFIG_LIBPATH but it still choked and gave the same PKG_CONFIG_PATH message [19:25:50 CET] <J_Darnley> It doesn't make a config.log file? One that actually says what it is doing? [19:26:15 CET] <RazWelles> Where would I look for that? I can do a find for a log sec [19:26:29 CET] <J_Darnley> In the directory you ran configure. [19:26:52 CET] <RazWelles> Found it, not much better, I"ll paste [19:27:23 CET] <RazWelles> http://hastebin.com/xulesaharo.coffee [19:27:31 CET] <RazWelles> The libraries its showing as not found are part of ffmpeg [19:27:32 CET] <relaxed> what can ffmpeg2theora do that ffmpeg with libvorbis and libtheora can not? [19:28:11 CET] <RazWelles> I just found it easier to edit, I suppose I could go through and edit ffmpeg instead but its a much bigger project to wade through [19:28:13 CET] <J_Darnley> Useless log is useless! [19:28:43 CET] <RazWelles> I need to pass more data from commandline into theora [19:29:22 CET] <J_Darnley> I guess that the software is too old and that causes whatever test it is doing to fail when you try a new ffmpeg. [19:29:57 CET] <RazWelles> Let me check the git log on ffmpeg2theora [19:30:17 CET] <RazWelles> Strange, last edit was Jan 10 of this year [19:30:30 CET] <RazWelles> But it was only edited once last year.. [19:30:50 CET] <J_Darnley> Can you tell me where I can find it? [19:31:13 CET] <RazWelles> J_Darnley: http://v2v.cc/~j/ffmpeg2theora/ [19:31:15 CET] <RazWelles> There you go [19:31:34 CET] <RazWelles> I'm basically trying to point the builds to custom directories so I'm not running make install or scons install [19:32:13 CET] <J_Darnley> "2016-01-01 - update to current FFmpeg api" [19:35:34 CET] <RazWelles> I guess that means it should be working? [20:52:40 CET] <cousin_luigi> Greetings. [20:57:07 CET] <cousin_luigi> What's new with the new AAC encoder in trunk, licence-wise? [20:57:25 CET] <c_14> nothing? [20:59:38 CET] <cousin_luigi> "In both cases, you will enjoy an audible quality improvement and as well as fewer licensing headaches. " [20:59:52 CET] <cousin_luigi> https://ffmpeg.org/index.html#news [21:00:13 CET] <c_14> The licence of the builtin AAC encoder never changed. [21:00:20 CET] <c_14> It's just better now so you don't have to use the other ones. [21:00:22 CET] <furq> it means you don't have to use https://android.googlesource.com/platform/external/aac/+/master/NOTICE [21:00:26 CET] <c_14> (And 2 of the old ones got removed) [21:00:29 CET] <JEEB> hh [21:00:35 CET] <JEEB> the license didn\t change [21:00:44 CET] <JEEB> it was always LGPL [21:00:51 CET] <cousin_luigi> ok [21:01:07 CET] <JEEB> but yes, the internal aac encoder got a whole lot better in master's HEAD :P [21:01:17 CET] <furq> is it any good at vbr yet [21:01:19 CET] <cousin_luigi> so it can be used liberally whenever there are no patent concerns, right? [21:01:45 CET] <furq> also have the changes made it into 2.8 releases yet [21:01:49 CET] <JEEB> follow the software license (LGPL methinks, check the header to be sure) and other [21:01:53 CET] <JEEB> furq: they will not [21:01:58 CET] <JEEB> I mean, it's new features :P [21:02:03 CET] <JEEB> not just bugfixes [21:02:10 CET] <furq> are they held for 2.9 [21:02:13 CET] <cousin_luigi> furq: I don't think so [21:02:26 CET] <JEEB> they will come up in any next release, whatever the version for that will be [21:02:26 CET] <cousin_luigi> 2.9 also for dca [21:02:42 CET] <furq> oh [21:02:43 CET] <JEEB> also fdk-aac is still the thing you want to use for HE-AAC [21:02:58 CET] <JEEB> what the updated lavc encoder excels at is LC [21:03:03 CET] <cousin_luigi> Speaking of dropping libdca, is there a dependency between it and mdts? [21:03:06 CET] <furq> people have been talking about this since before 2.8.5, but i guess that was specifically a bugfix release [21:03:07 CET] <cousin_luigi> JEEB: hmm [21:03:35 CET] <JEEB> furq: yes, but that's a point release off an earlier branch-off :P [21:04:16 CET] <JEEB> 2.8 was a branch off and 2.8.5 is a patched version of that with additional bugfixes cherry-picked from master [21:04:27 CET] <furq> oh hey 2.8.6 is out now [21:04:30 CET] <cousin_luigi> yeah [21:05:17 CET] <JEEB> the dca decoder was replaced in master with one that is pretty much libdcadec [21:05:25 CET] <JEEB> by the author of libdcadec [21:05:32 CET] <cousin_luigi> JEEB: yes, I understand as much. foo86 right? [21:05:35 CET] <JEEB> yes [21:06:03 CET] <cousin_luigi> but I saw a reference to that other decoder in the relevant commit and wondered if I had to enable it or something [21:06:24 CET] <JEEB> what [21:06:36 CET] <JEEB> it was a replacement so no multiple decoders :P [21:06:45 CET] <cousin_luigi> ...bitte warten... [21:06:49 CET] <JEEB> there were some mistakes done regarding keeping multiple things [21:06:55 CET] <JEEB> but dcadec thankfully isn ot one of those [21:07:42 CET] <cousin_luigi> https://github.com/FFmpeg/FFmpeg/commit/ae5b2c52501d5009fe712334428138a9b75… <- see mdct [21:07:59 CET] <cousin_luigi> is it related or just in the same commit? [21:08:29 CET] <J_Darnley> "mdct" is a component that is required by the dca decoder. [21:08:33 CET] <JEEB> ^ [21:08:34 CET] <JEEB> this [21:08:47 CET] <cousin_luigi> exactly as I suspected [21:08:54 CET] <cousin_luigi> that was my question btw [21:09:20 CET] <cousin_luigi> do I have to enable it along with dca? [21:09:28 CET] <J_Darnley> ? [21:09:43 CET] <JEEB> pretty sure if you are enabling the decoder it will select that thing it depends on [21:09:48 CET] <JEEB> since it's an internal thing [21:09:50 CET] <cousin_luigi> k [21:09:59 CET] <JEEB> and isn't limited by licensing [21:10:15 CET] <JEEB> just like those other decoders or encoders depend on features in lavc :P [21:10:33 CET] <JEEB> J_Darnley: I guess this person is doing --disable-everything --enable-decoders=dca or something [21:10:42 CET] <JEEB> and he asked if it will enable mdct as well :P [21:11:00 CET] <cousin_luigi> JEEB: exactly, needed to avoid enabling patent-encumbered stuff [21:11:02 CET] <cousin_luigi> by mistake [21:11:06 CET] <J_Darnley> Ah. If that ever fails then we definitely want to know about it. [21:11:18 CET] <J_Darnley> That is everything then. [21:11:21 CET] <drv> i suspect the only non-patent-encumbered build of ffmpeg is --disable-everything [21:11:37 CET] <J_Darnley> Some patent somewhere will cover something according to some troll. [21:12:01 CET] <cousin_luigi> drv: yes, but then we want also to build a non-US version [21:12:22 CET] <cousin_luigi> so I need to enable it explicitly [21:12:31 CET] <cousin_luigi> by the way, is 2.9 long to come? [22:01:29 CET] <cortexman> i'm trying to get either 30 or 60 images per second to show in a video: ffmpeg -r .5 -pattern_type glob -i '*.jpg' fps=60 -c:v libx264 output.avi [22:02:07 CET] <c_14> ffmpeg -framerate 60 -pattern_type glob -i '*.jpg' -vf fps=60 -c:v libx264 out.avi [22:04:16 CET] <cortexman> yeah, that works [22:04:31 CET] <c_14> actually [22:04:37 CET] <c_14> get red of the -vf fps=60 [22:04:43 CET] <c_14> there's no point, the input is already 60fps [22:08:19 CET] <cortexman> can you help set the output to a percentage (such as 25%) of the input as well? [22:08:29 CET] <c_14> What? [22:08:56 CET] <cortexman> i tried to set -vf scale= using division operators but the output video was very blurry [22:09:05 CET] <cortexman> i want the output video to be like 25% of the present resolution [22:09:07 CET] <c_14> Ah, you want to scale down? [22:09:26 CET] <cortexman> yeah [22:10:01 CET] <c_14> -vf scale=iw*.25:ih*.25 <- doesn't work? [22:10:58 CET] <cortexman> yep that one works. division didn't work well for some reason [22:10:59 CET] <cortexman> thanks [22:20:12 CET] <cortexman> c_14, this video is weighing in a several hundred megs. any ideas for making it reasonable-ish? [22:20:50 CET] <c_14> change the crf? use a slower preset? set a bitrate? [22:21:55 CET] <c_14> https://trac.ffmpeg.org/wiki/Encode/H.264 [22:22:52 CET] <cortexman> i set the crf, it helped although there is a bit of aliasing at 18 [00:00:00 CET] --- Thu Feb 4 2016

1 0

ffmpeg-devel.log.20160202
by burek 03 Feb '16

03 Feb '16

[00:02:10 CET] <kierank> the first two don't crash for me [00:02:20 CET] <nevcairiel> hm here is an interesting result, dca-xll_51_16_192_768_1 has the first two frames with the same checksum, but the dmix2 variant has varying md5s for the first two frames, somehow i would think that would also want to match :D [00:11:28 CET] <jamrial> it does if you use -ac 2 (swr dowmixing) instead of using request_channel_layout [00:11:38 CET] <nevcairiel> maybe coeffs change [00:12:31 CET] <jamrial> it also sounds considerably different [00:13:14 CET] <nevcairiel> like, better or worse [00:14:40 CET] <nevcairiel> its a sine wave, how different can it sound [00:17:04 CET] <nevcairiel> hm odd, i wrote both to wav and it mis-detects it as some adpcm [00:17:43 CET] <nevcairiel> oh my bad [00:18:52 CET] <nevcairiel> but yes, they sound quite differently [00:19:01 CET] <nevcairiel> hard to tell, might be intentional [00:21:27 CET] <nevcairiel> i think it actually is intentional [00:21:42 CET] <nevcairiel> the stereo downmix uses another audio source [00:21:52 CET] <nevcairiel> ie sine _2 [00:26:07 CET] <nevcairiel> if anything, the request channel layout version makes for a much nicer and cleaner audio spectrum [00:26:36 CET] <jamrial> yeah [00:28:29 CET] <nevcairiel> so working as intended, i guess [00:28:34 CET] <Daemon404> dirac pro in rtp... [00:28:36 CET] Action: Daemon404 blames kierank [00:28:50 CET] <kierank> prolly [00:29:50 CET] <nevcairiel> jamrial: what do you think about just testing downmix of every sample to simplify the test setup? michael seems to like that [00:30:03 CET] <Daemon404> patch is broken [00:30:09 CET] <Daemon404> do people copy/pasta patches into their client or something [00:30:14 CET] <nevcairiel> yes they do [00:30:25 CET] <Daemon404> .. paste* [00:30:29 CET] <Daemon404> damn internet reuined my brain [00:30:34 CET] <Daemon404> ruined veen [00:30:40 CET] <Daemon404> eh, i give up. [00:31:38 CET] <jamrial> nevcairiel: you can reuse pcm ref samples (just change the REF line accordingly), so i guess we could [00:32:08 CET] <nevcairiel> well if i make my function generate them, i can't re-use ref samples [00:32:38 CET] <nevcairiel> unless they get manually overwritten after the auto-generation [00:34:49 CET] <jamrial> i mean, you simply write "REF = $(SAMPLES)/dts/dcadec-suite/x96_xxch_71_24_96_3840-dmix_6.pcm" for both dmix_2 and dmix_6 tests [00:34:57 CET] <jamrial> and it generates only that file [00:35:13 CET] <nevcairiel> of course, but the idea is to simply let my two macros generate dmix tests for all files [00:35:17 CET] <nevcairiel> and that one cant special case [00:37:55 CET] <jamrial> you can in the patch you just sent. unless you mean a new patch that tests dowmix for all samples using a single macro [00:38:34 CET] <nevcairiel> yes that was the idea, extend the existing macros used for the non-dmix cases to simply also create dmix tests, so no need to explicitly list tests [00:39:02 CET] <nevcairiel> although that would mean a bunch of duplicate outputs [00:39:54 CET] <nevcairiel> i could just do it for xll and leave a few select lossy cases for manual checks [00:48:27 CET] <nevcairiel> that seems better, no unnecessary pcm references, only a few duplicate xll reference text files that harm noone [02:01:25 CET] <cone-301> ffmpeg 03Timothy Gu 07master:838abfc1d711: x86: vc1dsp: Convert vc1_inv_trans_*_dc to NASM format [02:19:54 CET] <jamrial> nevcairiel: heh, changing the tests to use f32 and creating the ref pcm files using cpuflags 0 makes all of them fail if i then run them with sse/avx enabled :p [02:20:18 CET] <jamrial> need to add a fuzz of about 8 to fix it [03:56:43 CET] <cone-301> ffmpeg 03Michael Niedermayer 07master:1dba8371d93c: avformat: add protocol_whitelist [04:25:10 CET] <cone-301> ffmpeg 03Michael Niedermayer 07master:fe3fed0b143e: Update demuxers and protocols for protocol whitelist support [05:41:42 CET] <cone-301> ffmpeg 03Timothy Gu 07master:f5e2b8de55cb: diracdsp_mmx: Fix indentation [05:48:12 CET] <cone-301> ffmpeg 03Timothy Gu 07master:dd57b316c109: diracdsp_mmx: Fix some more indentations [10:29:47 CET] <durandal_1707> wm4: so mpv have lua scripting support [10:30:29 CET] <durandal_1707> how was it done? the filtering side of story [10:33:32 CET] <wm4> mpv has no scripting in filtering, other than some high-level control [10:33:49 CET] <wm4> if you want a filter framework with scripting integrated, look at vapoursynth [10:55:01 CET] <durandal_1707> wm4: I do not want framework I want to create it [10:56:11 CET] <wm4> yes, but first understand what makes avs and VS great [10:57:15 CET] <durandal_1707> they are like cancers to me [10:57:30 CET] <nevcairiel> so you want to create more cancer? [10:57:50 CET] <wm4> nah he wants ffmpeg to replace them [10:57:54 CET] <wm4> for the better or worse [12:10:24 CET] <JEEB> did lavfi nowadays handle cases where input aspect ratio changes? [12:10:47 CET] <JEEB> so if I have a scale+pad into a specific res (let's say 16:9) and the input at first is 4:3 [12:11:27 CET] <JEEB> if and when it switches to 16:9. would it still work or bork? [12:16:59 CET] <durandal_1707> JEEB: define bork [12:18:16 CET] <JEEB> not understand that the input aspect ratio got updated, and recalculate some things [12:18:55 CET] <Workday> for mpeg2 video does ffmpeg traverse through the whole video file to get total frames or does it do an approximation? [12:18:56 CET] <JEEB> like recalculation of the scale and pad filters [12:20:25 CET] <durandal_1707> that two filters may use expr so it should work [12:21:41 CET] <JEEB> http://up-cat.net/p/b2312b24 [12:21:47 CET] <JEEB> so if something like this would bork [12:22:01 CET] <JEEB> {} is just for visibility [12:24:31 CET] <JEEB> should test at some point [12:24:51 CET] <JEEB> but those should be expressions that should work IFF they get poked :) [12:24:59 CET] <JEEB> when the AR changes [13:14:51 CET] <Daemon404> j-b must have so much HN karma [13:15:27 CET] <j-b> Daemon404: 7000+ [13:15:59 CET] <Daemon404> :D [13:17:48 CET] <iive> tell me when it goes over 9000 [13:22:32 CET] <iive> ;) [13:32:54 CET] <Compn> lol the comments... people hate the cone! [13:32:56 CET] <Compn> :p [13:33:17 CET] <J_Darnley> Of course HN would hate the cone. [13:33:38 CET] <J_Darnley> It doesn't fill their beliefs of what constitutes good design. [13:34:12 CET] <J_Darnley> "It's too noisy, it should be 'flat'" [13:34:55 CET] <J_Darnley> "It doesn't have your name in it" [13:38:11 CET] <thardin> cone? [13:38:30 CET] <Compn> vlc icon [13:38:37 CET] <Compn> is a traffic cone [13:38:44 CET] <thardin> ohhh [13:41:03 CET] <kierank> J_Darnley: the cone is a symbol of government regulation in markets [13:41:54 CET] <JEEB> hmm, anyone can spot what I'm doing wrong in this? http://up-cat.net/p/e73fcf91 [13:42:11 CET] <durandal_1707> and of masons [13:42:13 CET] <JEEB> I do yadif, scale, pad and then setsar/format [13:42:52 CET] <J_Darnley> You're not esacping the commas [13:43:20 CET] <JEEB> that's because it's within "" [13:43:25 CET] <JEEB> it doesn't seem to be a parsing issue [13:43:40 CET] Action: J_Darnley wonders how that works [13:43:41 CET] <JEEB> because the thing works, except the input aspect ratio is not followed [13:43:45 CET] <J_Darnley> What is the error then? [13:44:05 CET] <JEEB> the input is 720x576 + 16:9 AR [13:44:21 CET] <JEEB> output is correct AR and res, but it's as if the input format aspect ratio is not taken into mention [13:44:54 CET] <J_Darnley> scale thinks it has square pixels? [13:45:11 CET] <JEEB> let me double-check. either 4:3 or square pixels [13:46:27 CET] <J_Darnley> Perhaps yadif isn't setting output frame properties correctly. [13:46:54 CET] <kierank> is that guy seriously trying to do hevc on rpi2? [13:47:07 CET] <wm4> wat [13:47:12 CET] <JEEB> yeah, it seems to have a 720:576 aspect ratio thing in the middle [13:47:19 CET] <JEEB> so it seems like it's taken in as 1:1 [13:48:40 CET] <JEEB> ffprobe does show that the DAR is taken into mention [13:49:00 CET] <JEEB> Stream #0:1[0x64]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv), 720x576 [SAR 64:45 DAR 16:9] [13:50:51 CET] <J_Darnley> I don't know what to say then. [13:51:12 CET] <J_Darnley> yadif appears to call the correct funtion (av_frame_copy_props) [13:51:15 CET] <Compn> JEEB : why not setdar while you are at it ? [13:55:36 CET] <ubitux> JEEB: btw, any reason not to use force_original_aspect_ratio instead of the ifery? [13:56:11 CET] <ubitux> ah mmmh, misread [13:56:38 CET] <Compn> isnt there also a container aspect you have to set somewhere ? [13:56:43 CET] Action: Compn remembers setting container aspect [13:58:40 CET] <JEEB> Compn: setsar handles that too [13:58:53 CET] <JEEB> the main thing is I know that sar should be 1:1 [14:03:48 CET] <JEEB> J_Darnley: I guess I'll test once more with latest HEAD [14:04:46 CET] <JEEB> but it seems like yadif hasn't gotten changes after the commit I am on except for the context change [14:04:56 CET] <JEEB> (which I think was the point of libav merge) [14:13:31 CET] <JEEB> yeah, same result with current master [14:13:32 CET] <JEEB> welp [14:17:06 CET] <J_Darnley> I wasn't suggesting you should update. [14:17:14 CET] <JEEB> yeah, I just wanted to make sure [14:17:24 CET] <J_Darnley> Anyway. I guess it tis time for some printf debugging. [14:17:30 CET] <JEEB> actually [14:17:33 CET] <JEEB> take a look at the SAR value [14:17:38 CET] <JEEB> 64:65 [14:17:40 CET] <JEEB> oh wait [14:17:42 CET] <JEEB> 45 [14:17:44 CET] <JEEB> ok, that looks better [14:17:59 CET] Action: J_Darnley thought he saw the right value before. [14:18:27 CET] <JEEB> yeah, I for a moment thought I saw 64:65 and thought "how the hell can that be 64:65" [14:18:34 CET] <JEEB> which is deffo not 16:9 with a 720x576 res [14:18:42 CET] <JEEB> ok, yadif+scale works [14:19:38 CET] <JEEB> wait what [14:20:37 CET] <JEEB> ok, that's ok [14:22:31 CET] <JEEB> ok, I think I have misdone some math [14:22:35 CET] <JEEB> or misused something [14:24:55 CET] <JEEB> yeah, it's my brainfart at calculating the scale [14:25:02 CET] <JEEB> I'm keeping the input aspect ratio [14:45:05 CET] <kierank> JEEB: read etsi ts 101 154 [14:45:11 CET] <kierank> PAL aspect ratios are non trivial [14:47:14 CET] <durandal_1707> I wrote lavfi lua script that's capable of registering random filter and doing log calls, very useful indeed [14:47:26 CET] <JEEB> kierank: I know that [14:47:41 CET] <kierank> JEEB: I doubt ffmpeg does though [14:47:44 CET] <JEEB> yeah [14:48:01 CET] <JEEB> and I'm just failing at life at making my own parameters correct [14:48:17 CET] <JEEB> basically you'd have to change some AR logic to set the "real" PAL/NTSC aspect ratios [14:48:30 CET] <JEEB> but that would then probably break a lot of people's assumptions on what is going to be pushed out of their workflows [14:48:53 CET] <JEEB> we had a long discussions about this with baptiste in like 2011 [14:49:37 CET] <kierank> and I did with nicolas last year... [14:49:48 CET] <kierank> the nvidia driver was doing the right thing [14:49:54 CET] <kierank> but this was unacceptable apparently [15:05:58 CET] <BBB> j-b: congrats! almost of drinking age :-p [15:08:02 CET] <Daemon404> not in the usa [15:08:15 CET] <BBB> well theyre not us-based [15:08:34 CET] <Daemon404> j-b mentioned moving to .ca next year [15:08:40 CET] <Daemon404> but i suppose thats not all vlc [15:08:43 CET] <BBB> \o/ [15:08:52 CET] <BBB> well effectively it sort of is [15:08:53 CET] <BBB> but ohwell [15:09:41 CET] <j-b> Daemon404: well, yes. I really want to move to .ca or .nz [15:09:44 CET] <BBB> was it vancouver where the asian food was so good? [15:10:01 CET] <Daemon404> hongkouver, yes [15:10:31 CET] <BBB> should do a vlcdevmeetup in hongkouver then [15:10:49 CET] <Daemon404> wouldnt work, it's outside schengen [15:13:12 CET] <BBB> WhoCares [15:13:17 CET] <BBB> schengen is practically dead [15:16:03 CET] <nevcairiel> wasnt this in ireland once [15:16:08 CET] <nevcairiel> thats also not technically schengen [15:16:26 CET] <Daemon404> yes, and people protested [15:16:34 CET] <Compn> j-b to canada?! ehe [15:16:46 CET] <Daemon404> but realistically, most of vlc is in europe, so it would be $$$ to fly everyone to vsncouver. [15:16:55 CET] <nevcairiel> because they need to get a passport or what .p [15:17:07 CET] <Daemon404> certain people also wont fly. [15:17:29 CET] <BBB> certain people wont even come if its in paris [15:17:31 CET] <BBB> ... [15:19:19 CET] <Compn> i wonder how paris is doing now [15:19:43 CET] <Compn> do they put army guys at airport/trains like usa ? [15:20:29 CET] <av500> brussels was full of them [15:20:36 CET] <nevcairiel> every airport and bigger train stations had at least heavily armed police forces the last couple weeks in europe [15:21:15 CET] <kierank> nevcairiel: ireland was great [15:21:18 CET] <kierank> no passport control [15:21:27 CET] <kierank> CTA ftw [15:21:32 CET] <nevcairiel> for you from the UK yes =p [15:21:39 CET] <atomnuker> michaelni: I did send all the patches to the ML as a patchset [15:21:44 CET] <atomnuker> but they got delayed quite a bit [15:21:56 CET] <atomnuker> and for some reason that patch for the diractab got split from the rest [15:22:10 CET] <atomnuker> so yeah, apply that one first [15:22:46 CET] <nevcairiel> atomnuker: no patch arrived on the ML that actually adds the new diractab.c/h files [15:22:50 CET] <Daemon404> kierank, i had passport control ;p [15:22:57 CET] <nevcairiel> i would think 1/4 did that, but it looks like it misses them [15:23:09 CET] <nevcairiel> are you sure you didnt miss a git add :D [15:23:11 CET] <Daemon404> in fact the stupid irish visa took up an entire oage of my passport [15:23:15 CET] <kierank> Daemon404: in the uk? [15:23:16 CET] <kierank> rofl [15:23:21 CET] <atomnuker> nevcairiel: damn it I did [15:23:30 CET] <Daemon404> kierank, yes. [15:23:40 CET] <kierank> interesting, I went through a CTA door [15:23:51 CET] <Compn> i did a bunch of customs going us > uk > ireland > uk > us. [15:23:51 CET] <Daemon404> it could just be where flybe lands [15:23:59 CET] <Daemon404> i did exeter<->dublin [15:24:28 CET] <kierank> maybe exeter doesn't have cta [15:24:47 CET] <Daemon404> CTA = ? [15:24:59 CET] <kierank> common transfer area [15:25:05 CET] <kierank> mini-schengen [15:25:05 CET] <nevcairiel> its always interesting when you arrive at a local-only gate on an airport, you just go through two doors and are suddenly on the outside, while totally expecting some checks still to come [15:25:17 CET] <Daemon404> kierank, of course it doesnt [15:25:23 CET] <kierank> bristol did [15:25:25 CET] <kierank> separate exit [15:25:35 CET] <Daemon404> next to no flights would go foriegn->exeter->foriegn [15:25:42 CET] <Daemon404> why would you have two 50 minutes flights [15:25:46 CET] <Daemon404> instead of one 1.5 hr one [15:27:00 CET] <nevcairiel> it really depends if the airport in question has separate gates for domestic/CTA flights, so the people can be separated [15:27:08 CET] <Daemon404> we dont [15:27:19 CET] <nevcairiel> if you dont, then everyone has to go through the checks =p [15:27:21 CET] <Daemon404> UK doesn't really have "real" domestic airports [15:27:28 CET] <Daemon404> there's London, and London, and London [15:27:57 CET] <Daemon404> people can claim Manchester or Birmingham do... theyre not, really. [15:28:04 CET] <nevcairiel> medium-sized airports could still have separate gates for domestic and international flights [15:28:18 CET] <nevcairiel> the very small ones probably dont [15:28:21 CET] <Daemon404> yes [15:29:38 CET] <nevcairiel> for all the security the US usually has regarding airports, when I got on and off a domestic flight, there was practically no checks to speak of [15:29:57 CET] <Daemon404> i've never flown domestically in the usa [15:30:10 CET] <Daemon404> and when i fly .ca -> .us, there is pre-clearance in .ca [15:30:16 CET] <Daemon404> so no border control when i land [15:31:15 CET] <kierank> If I want to output a PAL8 for debug, how do I output that? [15:31:44 CET] <nevcairiel> first time I had to fly to the US for work I stayed a couple days in NYC to see the city, had to get where I was going afterwards, so =p [15:50:45 CET] <kierank> ubitux: is there an equivalent of "rawvideo" for subtitles? [15:51:15 CET] <ubitux> i don't think so, it doesn't make much sense [15:51:21 CET] <ubitux> since subtitles timing are sparse [15:51:34 CET] <kierank> I just want to visually see the dvb teletext [15:51:54 CET] <kierank> the packets are decoded but ffplay don't show them for some reason [15:52:09 CET] <ubitux> so we have a decoder for these? [15:52:11 CET] <ubitux> ccaption dec? [15:52:16 CET] <kierank> no dvb_teletext [15:52:18 CET] <kierank> it's a bitmap [15:52:28 CET] <wm4> do you have a sample? [15:52:31 CET] <ubitux> then mmh with the overlay we have a hack right? [15:53:17 CET] <kierank> wm4: maybe I can find one [15:53:27 CET] <ubitux> ffmpeg -i input.ts -filter_complex '[#0x2ef] setpts=PTS+1/TB [sub] ; [#0x2d0] [sub] overlay' -sn -map '#0x2dc' output.mkv [15:53:31 CET] <ubitux> (from the doc) [15:53:50 CET] <ubitux> 0x2* being mts pid) [15:54:22 CET] <durandal_1707> we should have two kind of subtitle decoders, bitmap which uses rawvideo and text only ones [15:54:39 CET] <wm4> durandal_1707: but there are formats which mix text and bitmaps [15:55:38 CET] <kierank> [Parsed_overlay_1 @ 0x225dfc0] [framesync @ 0x1ea6748] Buffer queue overflow, dropping [15:55:40 CET] <kierank> all over the place [15:55:52 CET] <kierank> oh i see [15:56:23 CET] <durandal_1707> use fifo [16:00:42 CET] Action: kierank hopes this isn't teletext without PTS [16:01:46 CET] <kierank> can't get that overlay to work [16:03:23 CET] <Timothy_Gu> my strange good friends, I want to use ffmpeg do some work but I used ffmpeg.exe with trouble. [16:03:29 CET] <Timothy_Gu> best wish.. I'm from china. [16:03:37 CET] <durandal_1707> kierank: have you inserted fifo filter? [16:03:50 CET] <kierank> no but why do I need tha [16:03:55 CET] <kierank> It encodes now [16:03:56 CET] <ubitux> kierank: "(0x2d0, 0x2dc and 0x2ef are the MPEG-TS PIDs of respectively the video audio and subtitles streams; 0:0, 0:3 and 0:7 would have worked too)" [16:03:58 CET] <kierank> but there's no overlay [16:04:01 CET] <kierank> yeah did that [16:04:12 CET] <kierank> ./ffmpeg -loglevel debug -i ttx.ts -filter_complex '[#0x1002] setpts=PTS+1/TB [sub] ; [#0x1000] [sub] overlay' -sn -map '#0x1001' -vcodec mpeg2video -b:v 100000 output.mkv [16:05:15 CET] <JEEB> btw, do I have to use eval=frame with scale filter to make sure it notices when aspect ratio changes? [16:05:17 CET] <durandal_1707> kierank: because bunch of subtitles are demuxer before others [16:05:53 CET] <nevcairiel> JEEB: if the alternative is to only eval once, then it sure sounds like it [16:06:14 CET] <JEEB> "Only evaluate expressions once during the filter initialization or when a command is processed." [16:06:18 CET] <JEEB> the last part is what sounds interesting [16:06:23 CET] <JEEB> "or when a command is processed" [16:06:36 CET] <durandal_1707> JEEB: isn't there variable that contains ar [16:06:43 CET] <nevcairiel> sending commands is not something you can just do that easily from the CLI =P [16:06:49 CET] <JEEB> durandal_1707: ? [16:06:53 CET] <JEEB> yes [16:07:02 CET] <JEEB> which I am using [16:07:24 CET] <durandal_1707> and what ffmpeg version? [16:07:32 CET] <JEEB> ? [16:07:36 CET] <JEEB> I've been testing with HEAD now [16:07:41 CET] <JEEB> I got my stuff fixed [16:07:51 CET] <JEEB> it was my PEBKAC that I was keeping the aspect ratio as 1:1 [16:07:59 CET] <JEEB> now I'm juts asking if I requrie that init var [16:08:09 CET] <JEEB> I could of course create conent with an AR change [16:08:11 CET] <JEEB> and test it [16:08:17 CET] <JEEB> but I didn't have any at hand [16:08:49 CET] <kierank> what's the difference between PAL8 and RGB24? [16:09:01 CET] <durandal_1707> Yes, you need sbsl frame [16:09:03 CET] <nevcairiel> PAL8 is palettized, RGB24 is RGB? [16:09:03 CET] <nevcairiel> :D [16:09:07 CET] <durandal_1707> *eval [16:09:08 CET] <JEEB> sbsl? [16:09:10 CET] <JEEB> oh, ok [16:09:14 CET] <JEEB> cheers [16:09:30 CET] <kierank> nevcairiel: basically how do I view PAL*? [16:09:34 CET] <kierank> PAL8* [16:09:50 CET] <durandal_1707> dosbox [16:09:52 CET] <nevcairiel> convert it to RGB? [16:10:22 CET] <Daemon404> PAL8 is not even a colorspace [16:10:24 CET] <Daemon404> its a hack [16:10:42 CET] <nevcairiel> PAL8 is two planes, one with an 8-bit color index per pixel, and one plane with 256 RGB palette entries (ie. 1024 byte) [16:11:02 CET] <Daemon404> see: not a colorspace [16:11:12 CET] <nevcairiel> its another form of RGB really [16:11:40 CET] <Daemon404> it's rgb. it's a hack to pass around the palette "in case we need it" [16:11:47 CET] <Daemon404> e.g. gif->gif [16:11:48 CET] <Daemon404> or somethin [16:11:49 CET] <Daemon404> g [16:11:59 CET] <kierank> ubitux: ah I think setpts is unnecessary [16:12:01 CET] <kierank> or wrong [16:12:03 CET] <nevcairiel> the concept of keeping data close to the original isnt that bad [16:12:44 CET] <nevcairiel> and we have far weirder pixel formats :p [16:12:48 CET] <kierank> really what I need is a PAL8 to RGB converter [16:12:52 CET] <kierank> that can output me raw pictures [16:12:54 CET] <nevcairiel> swscale :) [16:13:07 CET] <kierank> yeah but I want to do this without going through the api currently [16:13:10 CET] <Daemon404> or a loop. [16:13:12 CET] <kierank> just to see whether the teletext actually exists [16:13:16 CET] <Daemon404> it's just a LUT [16:13:20 CET] <nevcairiel> the code is easy, yes [16:14:48 CET] <nevcairiel> two loops and a buffer to write into, its like 6 lines of code [16:15:16 CET] <cone-623> ffmpeg 03Michael Niedermayer 07master:d117b090211e: avformat/tls_securetransport: Add missing include [16:20:47 CET] <JEEB> how did I show help for specific filters? [16:21:35 CET] <durandal_1707> -h filter-negate [16:21:39 CET] <Daemon404> man ffmpeg-filters [16:22:50 CET] <JEEB> seems like this build on this other box is from october... ffmpeg -h filter-scale doesn't give naything [16:23:15 CET] <durandal_1707> you can't use - [16:23:28 CET] <durandal_1707> use brain [16:23:37 CET] <nevcairiel> ffmpeg -h filter=scale [16:24:12 CET] <wm4> durandal_1707: if you want to say the syntax can be guessed intuitively, then HAHAHAHAHA....... NO. [16:24:51 CET] <durandal_1707> you need to have IQ high for sure [16:25:35 CET] <JEEB> sorry, tired as fuck at this point :V [16:25:58 CET] <durandal_1707> just I can't type that character from phone [16:27:11 CET] <cone-623> ffmpeg 03Kevin Mitchell 07master:5120b03d6987: avformat: add windows.h to SChannel SSP TLS code [16:27:13 CET] <ubitux> param0 <double> ..FV.... Scaler param 0 (from INT_MIN to INT_MAX) (default 123456) [16:27:17 CET] <ubitux> original value [16:28:23 CET] <jamrial> ubitux: coverage.ffmpeg.org is not working [16:28:31 CET] <jamrial> gives 403 error [16:28:33 CET] <ubitux> ah yeah someone told me i forgot to answer [16:28:39 CET] <ubitux> yeah going to look at it now [16:29:16 CET] <jamrial> and 404 if i try to open any link in my browser history (libavcodec directory and such) [16:30:29 CET] <ubitux> jamrial: http://lucy.pkh.me/ffmpeg-coverage-snapshots/ you have old snapshots here [16:30:31 CET] <ubitux> some are working [16:30:53 CET] <ubitux> it broke around 25/01 [16:31:10 CET] <jamrial> i was mostly interested in seeing how the dca decoder will look after we push nevcairiel's patch, but thanks :p [16:31:19 CET] <ubitux> yep [16:31:25 CET] <nevcairiel> an up-to-date before would be nice too [16:31:28 CET] <ubitux> you'll be able to compare with that [16:31:39 CET] <ubitux> yeah trying to fix asap [16:32:16 CET] <nevcairiel> would be curious to know how much coverage the three existing samples do give [16:32:51 CET] <nevcairiel> also, why was I worrying about a few hundred KBs of reference data, the existing xll sample has 8mb of pcm reference, twice! [16:33:58 CET] <jamrial> yeah, i wonder why it was uploaded twice [16:34:06 CET] <nevcairiel> decoder was changed [16:34:17 CET] <nevcairiel> and we dont break old samples so old fate can still pass [16:34:47 CET] <nevcairiel> it was part of the partial bitexactness of the old decoder [16:35:11 CET] <jamrial> ah right, those non bitexact xll changes. kinda shortsighted to add 16mb of ref files when it was inevitably going to become bitexact at some point... [16:35:55 CET] <nevcairiel> i would've probably at least taken the chance to shorten the sample [16:40:35 CET] <jamrial> and the current samples should be testing both the standard float and fixed codepaths, except probably the x96 stuff (synth_filter64, lfe2, etc) and xch/xxch [16:53:33 CET] <aworan> Hi all, I am using ffmpeg on my raspberry pi 2 under Ubuntu mate. I recompiled ffmpeg to enable mmal decoders and it work great. I have a question to makes things better on raspberry pi. By default, ffplay or another 3part software like Firefox use h264 decoder. So I want to do a build (modifying source code if needed) to replace h264 decoder code by h264_mmal decoder. Do you think it is possible ? Or a stupid idea ? [17:00:50 CET] <ubitux> i think i found the problem [17:01:02 CET] <ubitux> it's probably due to b46aae093634271931395d65f422f4b2a23112d3 ... [17:01:54 CET] <ubitux> apparently lcov doesn't like to follow the links [17:08:19 CET] <jamrial> lol, even more issues because of these hacks [17:10:18 CET] <ubitux> could probably be fixed by adding a if toolchain=gcov but well [17:10:39 CET] <wm4> aworan: you need to move the mmal entry above the builtin one in allcodecs.c [17:13:28 CET] <aworan> OK thank you, I will try it ! [17:17:10 CET] <nevcairiel> ubitux: sounds fun =p [17:17:42 CET] <ubitux> should i look for a fix or i let Andreas handle it? [17:18:00 CET] <ubitux> note: you can run the coverage yourself [17:18:08 CET] <ubitux> revert the commit locally [17:18:53 CET] <ubitux> you can reset lcov counters with make lcov-reset [17:19:00 CET] <ubitux> so you can make comparison that way [17:19:06 CET] <nevcairiel> wonder if my system has gcov [17:19:35 CET] <nevcairiel> appaers it does [17:46:06 CET] <kierank> ubitux: ok so got the overlay to work but the subtitles are in the wrong place [17:46:28 CET] <kierank> how do I debug that [17:46:53 CET] <kierank> ./ffmpeg -i dest_flavour.ts -filter_complex '[#0x1000] [sub] overlay' -sn -map '#0x1001' -vcodec mpeg2video -b:v 100000 output.mkv [17:47:15 CET] <ubitux> maybe -canvas_size? [17:49:24 CET] <kierank> ooh [17:49:27 CET] <kierank> looks right, thanks ubitux [17:51:18 CET] <nevcairiel> (in before fate turns yellow) [17:51:20 CET] <cone-623> ffmpeg 03Hendrik Leppkes 07master:da6ee11ecf28: dca: split decoder fate tests into dca.mak [17:51:20 CET] <cone-623> ffmpeg 03Hendrik Leppkes 07master:084ab3104953: dca: add new fate tests based on the dcadec-samples test suite [18:00:15 CET] <nevcairiel> jamrial: definitely improves the coverage quite a bit [18:02:45 CET] <nevcairiel> dca_core.c 42.8% -> 76.9%, dca_exss.c 49.1% -> 57.5%, dca_xll.c 57% -> 80.8%, dcadec.c 53% -> 75%, dacdct.c 53% -> 100%, dcadsp.c 43% -> 88% [18:03:09 CET] <nevcairiel> oh and synth_filter.c is also up to 100 [18:05:24 CET] <nevcairiel> now to watch fate for a bit [18:09:41 CET] <jamrial> you should have probably waited a day for the samples to spread :p [18:09:57 CET] <nevcairiel> i was told once we dont do that anymore [18:10:44 CET] <jamrial> oh? ok then [18:11:17 CET] <jamrial> i thought the fate clients were still purposely doing an rsync per day or so [18:16:25 CET] <jamrial> nevcairiel: curious, the ref files you uploaded do need after all a fuzz higher than the ones i created locally [18:17:33 CET] <nevcairiel> my build did use x87 fpmath, not sse, maybe that changes that still [18:18:52 CET] <jamrial> ah, could be. gcc x86_64 defaults to sse math [18:28:45 CET] <cone-623> ffmpeg 03Hendrik Leppkes 07n2.4.13:HEAD: dca: add new fate tests based on the dcadec-samples test suite [18:46:46 CET] <durandal_1707> anybody interested in lavfi having scripting support? [18:50:36 CET] <atomnuker> durandal_1707: and do stuff like what with it? [18:52:02 CET] <durandal_1707> changing filter options per call [18:52:39 CET] <durandal_1707> conditional filtering [18:52:56 CET] <atomnuker> yeah, that could be nice actually, filtering entire files based on a timeline in your script [18:57:09 CET] <durandal_1707> thing is there is no way to get Nth frame from input, the only filter with seeking support is movie source [18:58:39 CET] <durandal_1707> saste: ping [18:58:54 CET] <saste> durandal_1707, pong [18:59:35 CET] <durandal_1707> saste: have done anything new regarding scripting in lavfi? [18:59:52 CET] <saste> durandal_1707, no [19:00:08 CET] <TD-Linux> isn't that basically vapoursynth? [19:00:27 CET] <saste> durandal_1707, I propose to create a GSoC for that, it's unlikely that I'll find the time to do it myself [19:00:42 CET] <atomnuker> yeah, that's basically vapoursynth [19:01:03 CET] <saste> it's not only about filtering, it's also about scripting all operations [19:01:40 CET] <durandal_1707> I'm doing it inside lua [19:01:48 CET] <atomnuker> yes, do it, Lua is awesome [19:01:51 CET] <saste> for example i could want to send an event to a remote server when a transcoding operation finishes [19:01:59 CET] <saste> lua looks like a good choice [19:02:08 CET] <TD-Linux> I mean, adding an API to step the filter graph by frame and reconfigure it might be neat [19:03:59 CET] <durandal_1707> some filters don't work/conflict with this, they keep local cache of stuff, so I need to find way how to handle it [19:04:26 CET] <TD-Linux> but I don't see why you'd put the scripting language interpreter itself in ffmpeg [19:06:09 CET] <durandal_1707> I put it into filter [19:52:55 CET] <nevcairiel> jamrial: so i am having the weirdest error, calling avcodec_flush_buffers on the new dca decoder somehow causes playback to go completely foobar for me, and I have no clue wtf it might be doing that could ever cause this [19:53:28 CET] <nevcairiel> i neven weirder news, it does not happen when compiled with msvc =p [19:53:54 CET] <jamrial> haha [19:54:07 CET] <jamrial> did you try another gcc version, like 4.9? [19:54:20 CET] <nevcairiel> not yet [19:54:33 CET] <nevcairiel> i am trying to cmment out a variety of the flush code [19:55:21 CET] <nevcairiel> unfortunately i dont think fate tests this [19:56:12 CET] <jamrial> a seek test might [19:56:27 CET] <nevcairiel> seems like erase_adpcm_history in core_flush causes it [19:57:34 CET] <jamrial> AV_ZERO128? [19:57:51 CET] <jamrial> is this x86_32? it might need an emms_c [19:57:58 CET] <nevcairiel> yes it is [19:58:11 CET] <jamrial> try adding one [19:59:50 CET] <nevcairiel> hm yeah it uses mmx regs there [20:00:04 CET] <nevcairiel> dangerous macro this one [20:00:26 CET] <jamrial> the header warns about it, though [20:01:23 CET] <nevcairiel> all other users are video codecs [20:01:26 CET] <nevcairiel> lets try [20:01:51 CET] <nevcairiel> that might explain the totally incomprehensible results i got [20:02:10 CET] <nevcairiel> yeah that fixes it [20:02:13 CET] <jamrial> and why it didn't happen with msvc [20:02:15 CET] <jamrial> no inline asm there [20:02:18 CET] <nevcairiel> indeed [20:02:22 CET] <jamrial> \o/ [20:04:21 CET] <nevcairiel> i suppose i could just push that, no need to go to the ML and get an ok from you is there =p [20:04:42 CET] <nevcairiel> http://pastebin.com/jjyqSxFE [20:05:27 CET] <jamrial> looks good [20:12:18 CET] <cone-623> ffmpeg 03Hendrik Leppkes 07master:0b1972d4096d: dca: add emms_c after AV_ZERO128 macros [20:41:04 CET] <nevcairiel> jamrial: what ever happened to the float dsp fix? I had it fail again just now [20:43:42 CET] <nevcairiel> float_dsp-test: random seed 2323630816 [20:43:42 CET] <nevcairiel> 96: -34.500125914490 - -34.500125914490 = -7.1054273576e-015 [20:43:43 CET] <nevcairiel> :( [20:54:50 CET] <jamrial> never really sent the fix to the ml since i'm not sure if it's correct. or correct-er than the current check [20:55:26 CET] <jamrial> it at least fixed that one seed i tested back then [21:01:58 CET] <jamrial> nevcairiel: http://pastebin.com/n8p18db5 seems to fix this seed as well [21:05:34 CET] <nevcairiel> i'm slightly confused what the patch really does, it seems a rather long way to write a float comparison =p [21:06:53 CET] <nevcairiel> the inaccuracy scales with the size of the number? [21:07:36 CET] <nevcairiel> because that would move the precision away from the low digits, i guess [21:09:06 CET] <jamrial> i'm not sure either! that's essentially the result of a google search for how to compare floats while having the least amount of innacurate results as possible :p [21:10:28 CET] <jamrial> the current check also fails with seed 2323630821 [21:10:58 CET] <nevcairiel> suspiciously close to my number [21:12:08 CET] <jamrial> yes, and the one seed that failed a few weeks ago was 2331579809 [21:12:38 CET] <nevcairiel> what does it seed these with, unix time [21:13:16 CET] <jamrial> on windows it uses CryptGenRandom [21:13:34 CET] <nevcairiel> hm indeed [21:13:52 CET] <nevcairiel> if that works, that is [23:09:14 CET] <cone-623> ffmpeg 03Hendrik Leppkes 07n2.5.11:HEAD: dca: add emms_c after AV_ZERO128 macros [23:19:06 CET] <jamrial> nevcairiel: dca_core also uses AV_COPY128, so i guess we should add emms_c there as well [23:19:34 CET] <jamrial> wonder why they didn't break playback for you, though [23:19:55 CET] <nevcairiel> the two i fixed were in dca_core [23:20:04 CET] <nevcairiel> the only two outside of video decoders [23:21:18 CET] <jamrial> i mean, wonder why the two av_copy128 didn't break for you like the two av_zero128 did [23:21:25 CET] <nevcairiel> oh copy [23:21:28 CET] <nevcairiel> lets see [23:22:21 CET] <jamrial> oh, maybe they didn't because av_copy128 also has an sse version [23:22:35 CET] <nevcairiel> ah yeah [23:22:40 CET] <nevcairiel> should still add it though [23:22:44 CET] <jamrial> and you're compiling your x86_32 build with -msse [23:22:47 CET] <jamrial> yeah [23:24:18 CET] <jamrial> wonder why av_zero128 is written in sse2. like av_copy128 it could just use xorps and movaps [23:25:13 CET] <wm4> I have a user who reports a strange playback breakage with the new decoder, but the emms thing doesn't fix it (neither does --disable-asm) [23:26:30 CET] <jamrial> wm4: we're still missing a couple emms, so it could be that. [23:26:57 CET] <nevcairiel> interestingly my usual test builds of ffmpeg are not with -msse and those didnt fail [23:28:30 CET] <jamrial> they neither have -mmmx [23:28:35 CET] <nevcairiel> hm right [23:28:40 CET] <nevcairiel> that makes sense [23:28:43 CET] <jamrial> default march is i686 [23:30:03 CET] <cone-623> ffmpeg 03Hendrik Leppkes 07master:5fc310f7ca2a: dca: add emms_c after usage of AV_COPY128 [23:30:11 CET] <nevcairiel> use of those macros seems rather silly [23:30:22 CET] <nevcairiel> but shrug [23:32:41 CET] <jamrial> memset/memcpy probably couldn't be used in those cases. he does use them elsewhere after all [23:33:07 CET] <nevcairiel> smells like micro-optimization to me [23:33:29 CET] <nevcairiel> happens to be 16 byte or something, just use the macro [23:34:22 CET] <jamrial> well, a single emms call after the loop is going to be considerably faster than several memset/memcpy calls inside the loop anyway :p [23:34:45 CET] <nevcairiel> maybe a compiler would optimize a memcpy of a small defined size [23:37:25 CET] <nevcairiel> but yeah, emms_c might look kinda ugly there, but doesnt do any harm in some generic code [23:44:49 CET] <jamrial> nevcairiel: a memcpy with a size of 16 is indeed optimized if -msse is used, but not with -mmmx [23:47:07 CET] <wm4> anyway, I made the user add emms after the decoder returns, and it's still broken, so my problem is probably something else [23:47:24 CET] <nevcairiel> can you describe the problem somehow? [23:47:38 CET] <nevcairiel> the emms problem was rather... crazy [23:48:06 CET] <nevcairiel> not sure it would have occured to me quickly if jamrial hadn't said something about it [23:48:47 CET] <nevcairiel> when everything starts misbehaving and you dont see how it could ever do that, you sit there puzzled for a bit [23:49:39 CET] <jamrial> only reason i knew it could be that was because not too long ago i toyed with the idea of adding an av_zero/copy256 using avx and saw the warning about mmx :p [23:49:50 CET] <wm4> nevcairiel: just getting mysterious A/V desync, which I thought might be a problem with FPU state getting messed up [23:50:00 CET] <nevcairiel> ah avx would have similar crazyness indeed [23:50:04 CET] <nevcairiel> at least on ymm [23:50:40 CET] <jamrial> yeah, basically each call would need a vzeroupper and probably kill any performance gain compared to sse [23:51:41 CET] <nevcairiel> wm4: if you are on 64-bit, none of this mmx code would ever execute, just fyi, since it has sse(2) variants then, since most linux users are on 64-bit i would wager [23:52:16 CET] <wm4> I for one can't reproduce this problem anyway [23:52:46 CET] <jamrial> and if he's using x86_32, make him test with current git head, to see if the latest emms patch fixes it for him [23:53:00 CET] <nevcairiel> in my case, the messed up fpu caused the playback rate to go bananas, screwing with everything [23:53:16 CET] <nevcairiel> sound was garbled and video was practically frozen =p [00:00:00 CET] --- Wed Feb 3 2016

1 0

ffmpeg.log.20160202
by burek 03 Feb '16

03 Feb '16

[00:33:57 CET] <kbarry> I think 'ffprobe' is the right tool to learn "what kind of stream is this" [00:49:02 CET] <hurstly> what sort of things can you use ffprobe for and is there any examples for it? [00:49:47 CET] <c_14> https://trac.ffmpeg.org/wiki/FFprobeTips [00:50:47 CET] <hurstly> thanks :) [03:12:17 CET] <hawke__> hows it going anyone home [03:12:32 CET] <dystopia> evening hawke__ [03:12:38 CET] <hawke__> hey dystopia [03:12:56 CET] <hawke__> he do you know how to install from a clone ffmpeg onto centos [03:13:03 CET] <hawke__> hey not he [03:13:58 CET] <dystopia> i don't sorry, but stick around, im sure someone else will be able to help [03:14:09 CET] <hawke__> thanks [03:32:23 CET] <J_Darnley> hawke__: what's wrong with ./configure && make && make install? [03:33:01 CET] <hawke__> nothing im a noob at centos didnt know it was that simple [03:33:21 CET] <hawke__> just do it from the ffmpeg clone directory right [03:36:45 CET] <J_Darnley> yes [03:36:57 CET] <J_Darnley> the installing is optional [03:37:09 CET] <J_Darnley> you can just run it from the directory you build it in. [04:02:43 CET] <hawke__> thanks [04:02:47 CET] <hawke__> got it to work now [04:02:57 CET] <hawke__> just having issue with ampache streaming [04:03:12 CET] <hawke__> but i am going to find ampache channel for that [04:03:16 CET] <hawke__> thanks a million [04:21:39 CET] <wizkid057> there a good way to downmix 5.1 to stereo with VLC-like results? [06:18:23 CET] <dystopia> wizkid057 use ffmpeg to demux the audio, then encode it with nero's aac encoder or qaac, then remux [08:52:33 CET] <markusl> good morning, anonyoe awake with DASH (webm_chunk and webm_dash_manifest) knowledge? I've got the problem that those commands http://pastebin.com/22zHuGdE (output: http://pastebin.com/bLaBbS7r) give the same bandwidth= in manifest for all live streams even if they're encoded differently [09:20:29 CET] <siery> hey, I was trying to set up streaming channel with ffmpeg, but I'm getting all the time error: [x11grab @ 0x1178f40] Cannot open display HDMI-1, error 5. [09:20:29 CET] <siery> HDMI-1: Input/output error [09:21:35 CET] <siery> I write a simple script in bash to do that, but even when i type directly the command -i and then screen input I'm getting this error [09:23:40 CET] <siery> I'm using Debian Jessie. And I think i install all dependences. Is there something more i need to specify? Maybe someone can review my script? [10:38:42 CET] <Ajay_> Hi [10:39:16 CET] <Ajay_> i wan't to know the status of .webm container support in ffmpeg [10:39:30 CET] <Ajay_> .webm (vp8 + vorbis) [10:40:02 CET] <Ajay_> file recorded with sample https://webrtc.github.io/samples/src/content/getusermedia/record/ in firefox & chrome-canary [10:40:43 CET] <Ajay_> but am unable to process it with latest ffmpeg stable build on windows 32'bit server [10:40:57 CET] <Ajay_> is it a known issue ? [11:45:37 CET] <roxlu> When I concat multiple ts streams with ffmpeg, does it increment all the PTS/PCR values? Or does it restart when a new stream is appended? [11:55:27 CET] <Mavrik> roxlu, PTS depends on your -copyts, PCR is always restamped. [11:56:28 CET] <roxlu> Mavrik, ok awesome thanks! So is stream A ends with e.g. PCR = 10:01, then it will get e.g. 10:02 when stream B is appended ? [11:56:40 CET] <roxlu> i.e. the PCRs increment [11:56:43 CET] <Mavrik> PCR is applied on the output muxer [11:56:54 CET] <Mavrik> So it should be monotonously incremented. [11:57:03 CET] <roxlu> Okay thanks Mavrik ! [11:57:08 CET] <Mavrik> Even though I'm not sure what mpegtsenc.c does in all cases. [12:04:38 CET] <Workday> does ffmpeg traverse through the whole video file to get total frames? [12:05:02 CET] <Workday> regards to mpeg-2 [12:05:20 CET] <HiddenWolf> Does ffmpeg allow to set a subtitle as default on? [12:08:41 CET] <tp_> theres no such thing as a default flag for subtitles [12:09:09 CET] <tp_> its all up to your video player to decide [12:11:51 CET] <HiddenWolf> hm. [12:12:28 CET] <HiddenWolf> If I start the source file in vlc, it defaults to English subs, if I test-encode a bit of it, I can select the subs, but they're not automatically started. [12:16:16 CET] <HiddenWolf> Oh well. Plex can handle that. [12:21:22 CET] <Mavrik> Maybe you're just losing the subtitle language flag [12:21:25 CET] <Mavrik> And the player doesn't enable them. [12:56:36 CET] <Ajay_> but am unable to merge .webm(vp8+vorbis) video file with latest stable build on windows 32'bit server [12:56:40 CET] <Ajay_> any idea ? [13:35:32 CET] <FirePowi> Hi, is it possible to directly impose subtitles with ffmpeg, please ? [13:36:56 CET] <J_Darnley> What do you mean by "impose"? [13:37:01 CET] <J_Darnley> FirePowi ^ [13:37:32 CET] <J_Darnley> ffmpeg can render subttles onto video quite easily. See the subtitle video filters. [13:38:18 CET] <FirePowi> J_Darnley, I mean that I want the subtitled to be in video output. [13:38:39 CET] <zylthinking> hi, I use ffmpeg to wirte aac to mp4, I can write the file without any warning, but the result mp4 file fails to being played [13:38:49 CET] <zylthinking> the code is at http://sprunge.us/egEC [13:39:22 CET] <J_Darnley> In what? By what? Can ffmpeg decode the files you write? [13:40:13 CET] <zylthinking> I have not try ffmpeg, while, the vlc fails to play [13:40:58 CET] <FirePowi> J_Darnley, testing. [13:41:10 CET] <zylthinking> vlc can show there is a aac stream in mp4, with sample rate 44100 strearo, while, in fact it is 8000 & mono [13:44:21 CET] <zylthinking> ffprobe shows: Stream #0:0(und): Audio: aac (mp4a / 0x6134706D), 8000 Hz, mono, fltp, 23 kb/s (default) [13:44:30 CET] <FirePowi> J_Darnley, It work ! Thanks :8) [13:44:42 CET] <FirePowi> I meant :-) * [13:48:53 CET] <zylthinking> chrome in mac seems plays it well [14:04:44 CET] <J_Darnley> zylthinking: perhaps you should also ask you question on FFmpeg's libav-user mailing list. [14:07:05 CET] <zylthinking> ok, thanks, some one figures that because of sample rate does not specified in mp4, while, he does not say how to specify it. I have specified the information in AVcodecContext, seems is not enough. I will research [14:25:37 CET] <bove> Is there a way to limit macroblock size in ffmpeg? I am getting an XDCam file rejected with this error: "MB Size exceeds limit. MB No. 7271 was found to be of size 6793. Max allowed is 6144." [14:27:42 CET] <bove> Is mblmax what I am looking for? [14:43:05 CET] <leventel> hello [14:45:02 CET] <spaam> Hello and welcome to #ffmpeg [14:46:04 CET] <relaxed> bove: what was your command? [14:49:58 CET] <bove> relaxed: Basically -target xdcamhd422. This was in ffmbc, but I am assuming the required setting would be compatible [15:10:35 CET] <roxlu> Mavrik, when I concat two TS streams with ffmpeg the PCR intervals are to far apart. Do you maybe know if there is a flag to change the PCR interval? [15:12:15 CET] <roxlu> hmm http://ffmpeg-users.933282.n4.nabble.com/MPEGTS-no-PCR-when-muxing-H264-td2… same issue .. way back [15:19:53 CET] <DHE> I've had a similar issue. Using CBR mode (-muxrate parameter) does generate PCR in reasonable increments, with obvious downsides... [15:20:10 CET] <DHE> I had ffmpeg drop a PCR every 2 seconds (the keyframe interval) [15:26:13 CET] <roxlu> DHE, ah thanks! Do you maybe have a full command? [15:39:57 CET] <DHE> roxlu: just add "-muxrate 5M" or such before the output filename. you may have to experiment with different values if you don't know the actual necessary rate [15:40:08 CET] <DHE> you should get errors if you choose too small a value [15:40:45 CET] <roxlu> Ok thanks DHE [15:41:03 CET] <DHE> concatenation isn't what I was doing, so check it out first. otherwise you may need to do timestamp manipulation [15:41:45 CET] <roxlu> DHE, does ffmpeg have support to that too? [15:43:11 CET] <DHE> yes, check the manual. Check -vsync, including all the comments around it [16:12:39 CET] <Ccdc_DuckZ> hello, can somebody point me to the right functions (or even a tutorial) on how to save an animated gif from ffmpeg? I've never used this library before, so I'm not sure where to start from [16:23:04 CET] <furq> Ccdc_DuckZ: the binary or the library [16:23:13 CET] <furq> if it's the binary then ffmpeg -i input.video output.gif [16:23:23 CET] <Ccdc_DuckZ> ah sorry, library [16:32:46 CET] Action: HiddenWolf is amazed at the efficiency of x265 [17:03:08 CET] <aworan> Hi all, I am using ffmpeg on my raspberry pi 2 under Ubuntu mate. I recompiled ffmpeg to enable mmal decoders and it work great. I have a question to makes things better on raspberry pi. By default, ffplay or another 3part software like Firefox use h264 decoder. So I want to do a build (modifying source code if needed) to replace h264 decoder code by h264_mmal decoder. Do you think it is possible ? Or a stupid idea ? [17:07:14 CET] <c_14> It should be possible. You'd probably have to remove the AVCodec struct in libavcodec/h264.c and add one in libavcodec/mmaldec.c that has the same name but all the other entries from the mmaldec struct. I can't say whether or not it's a stupid idea though. [17:11:14 CET] <aworan> Thank you c_14 ! I will try it [17:11:35 CET] <c_14> wm4's comment in #ffmpeg-devel might be better [17:12:12 CET] <c_14> at the very least less hacky [17:12:25 CET] <aworan> Ok [17:12:42 CET] <aworan> I will do that instead ;) [22:26:36 CET] <Halidith> Hi, im trying to make a playable file from a m3u8 playlist with 191 segments. but i get the error Failed to open segment of playlist 0 [22:46:22 CET] <lmat> Here's a script I use to play music: http://sprunge.us/UUeW [22:47:11 CET] <lmat> By default, it plays all the files in ./* in order. You can pass files to play. You can play ./ recursively, and you can pass directories to be read recursively, and the files can be random-sorted. [23:39:35 CET] <cokomoko> hi [23:46:54 CET] <shadow42085> ok what packages do i need to Cross-Compile to build ffmpeg for windows [23:47:47 CET] <shadow42085> i have all of the dev packages for linux native built and installed [23:52:57 CET] <shadow42085> anyone or am I in the wrong channel? [23:59:58 CET] <genii> shadow42085: You might want #ffmpeg-devel , as per the /topic [00:00:00 CET] --- Wed Feb 3 2016

1 0

ffmpeg-devel.log.20160201
by burek 02 Feb '16

02 Feb '16

[00:00:24 CET] <Timothy_Gu> do you know of a specific reason for it to do that? performance or compliance? [00:19:47 CET] <kierank> Need to meet more FFmpeg people now that I met J_Darnley [00:22:59 CET] <jamrial> Timothy_Gu: performance, maybe instruction size, can't really say [00:26:42 CET] <Timothy_Gu> anyway agner's tables don't show any performance deficit when using 64-bit lea (or any other instructions) so changed locally [00:33:53 CET] <J_Darnley> They're usually the same speed, just the size changes [00:34:14 CET] <cone-985> ffmpeg 03Timothy Gu 07master:014e4e4499fd: vf_phase: Reduce the scope of several variables [00:41:35 CET] <cone-985> ffmpeg 03popcornmix 07master:def56677e58d: wtv: Speed up wtv index creation [00:44:33 CET] <cone-985> ffmpeg 03Timothy Gu 07master:180f9a09588d: all: Make header guard names consistent [00:52:54 CET] <cone-985> ffmpeg 03Timothy Gu 07master:e5a6dcac47c2: wtvdec: Removed unused variable [00:52:55 CET] <cone-985> ffmpeg 03Timothy Gu 07master:80075b014904: Changelog: add entry on wtvdec performance improvement [00:55:43 CET] <Timothy_Gu> http://i.imgur.com/jWtUoOM.png [00:56:00 CET] <J_Darnley> oooh traffic stats [00:56:09 CET] <Timothy_Gu> "developers.google.com" [00:56:34 CET] <Timothy_Gu> hmm apparently it's this https://developers.google.com/web/updates/2013/07/Alpha-transparency-in-Chr… [00:58:30 CET] <kierank> I could probably make that data for trac [01:31:55 CET] <kierank> BBB: so how do I add a GBRAP12 pixel format? [01:32:51 CET] <kierank> I guess add it and flag it in swscale [01:34:05 CET] <wm4> and then see if it explodes [01:38:14 CET] <kierank> I'm not really sure how to test alpha looks right [01:38:15 CET] <cone-985> ffmpeg 03Stephen Hutchinson 07master:70742e599b66: libx265: Enable 12-bit encoding [01:58:27 CET] <BBB> kierank: yeah, that basically [01:58:44 CET] <BBB> kierank: I believe all planar formats are automatically handled correctly in swscale so you shouldny need any special handling [01:58:46 CET] <kierank> how do I check alpha looks right? [01:58:51 CET] <BBB> except marking them as input supported" [01:58:54 CET] <BBB> check alpha... [01:58:55 CET] <BBB> dunno [01:58:58 CET] <BBB> :D [01:59:07 CET] <BBB> wait for cehoyos to file bugs? [01:59:31 CET] <J_Darnley> kierank: there's a seprate planes filter [01:59:48 CET] <kierank> yeah but still unclear whether the alpha plane is correct or not [01:59:52 CET] <kierank> in cfhd, that is [02:00:07 CET] <BBB> swap alpha/luma [02:00:14 CET] <BBB> is best I can think of [02:03:17 CET] <Compn> we have no alpha fate tests ? [02:03:19 CET] <cone-985> ffmpeg 03Stephen Hutchinson 07n2.8.6:HEAD: libx265: Enable 12-bit encoding [02:09:39 CET] <wm4> does swscale really handle >8bit fprm,a [02:09:41 CET] <wm4> oops [02:09:46 CET] <wm4> does swscale really handle >8bit formats correctly? [02:10:19 CET] <kierank> for yuv it seems to [02:10:23 CET] <kierank> can't comment on rgb [02:10:26 CET] <kierank> or anything else [02:13:50 CET] <BBB> I think it does for rgb also [02:17:22 CET] <wm4> I seem to recall problems with dithering to 8 bit making the picture too green [02:35:27 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:a2966c7d1f14: swscale/swscale-test: Fix slice height in random reference data creation. [02:35:28 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:fc0f08f9fb5e: avformat/mxfenc: Do not crash if there is no packet in the first stream [02:35:29 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:8132ed4a4377: avfilter/vf_mpdecimate: Add missing emms_c() [02:35:30 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:ffda227636a3: avcodec/h264_refs: Fix long_idx check [02:35:31 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:41289bc85322: swscale/utils: Fix intermediate format for cascaded alpha downscaling [02:35:32 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:0affd64b1c21: avcodec/put_bits: Always check buffer end before writing [02:35:33 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:7ea0e525edc1: swscale/utils: Use normal bilinear scaler if fast cannot be used due to tiny dimensions [02:35:34 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:8158fb129e15: avcodec/h264_slice: Fix integer overflow in implicit weight computation [02:35:35 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:593dea80f28e: avcodec/motion_est: Fix mv_penalty table size [02:35:36 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:5fe8dad4671e: avcodec/mpegvideo_enc: Clip bits_per_raw_sample within valid range [02:35:37 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:dd285715308f: avformat: Add integer fps from 31 to 60 to get_std_framerate() [02:35:38 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:f6a503c4438d: avcodec/mss2: Check for repeat overflow [02:35:39 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:5c0d8a838777: avcodec/mjpegdec: Fix negative shift [02:35:40 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:d8cb5887c1ca: avcodec/dvdec: Fix "left shift of negative value -254" [02:35:41 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:60bc36193ee8: avcodec/wavpackenc: Headers are per channel [02:35:42 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:250e5cb71df4: avcodec/wavpackenc: Check the number of channels [02:35:43 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:78f9c7dd14be: avcodec/mpeg4video: Check time_incr [02:35:44 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:937f3058fa23: avformat/asfenc: Check pts [02:35:45 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:66aeb5467eee: avformat/aviobuf: Fix end check in put_str16() [02:35:46 CET] <cone-985> ffmpeg 03Maxim Andreev 07release/2.4:70b35708b915: avformat/hls: forbid all protocols except http(s) & file [02:35:47 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:ed44b57935f6: swscale/yuv2rgb: Factor YUVRGB_TABLE_LUMA_HEADROOM out [02:35:48 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:38369313b959: swscale/yuv2rgb: Increase YUV2RGB table headroom [02:35:49 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:990abbd1c612: avformat/hls: More strict url checks [02:35:50 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:c0df58b0e5ec: avformat/hls: Even stricter URL checks [02:35:51 CET] <cone-985> ffmpeg 03James Almer 07release/2.4:2a2205b05184: configure: bump copyright year to 2016 [02:35:52 CET] <cone-985> ffmpeg 03James Almer 07release/2.4:a6ef7205e9fb: avcodec/wavpackenc: print channel count in av_log call [02:35:53 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:e4b2c75c2a69: swscale/swscale_unscaled: Fix odd height inputs for bayer_to_rgb24_wrapper() [02:35:54 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:af384c870354: swscale/swscale_unscaled: Fix odd height inputs for bayer_to_yv12_wrapper() [02:35:55 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:f8728dc83417: swscale/x86/rgb2rgb_template: Fix planar2x() for short width [02:35:56 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:5d40272ba8fc: swscale/swscale: Add some sanity checks for srcSlice* parameters [02:35:57 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:7142ddcf92c6: avcodec/tiff: Check subsample & rps values more completely [02:35:58 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:c88fa43a3adf: avcodec/put_bits: Assert buf_ptr in flush_put_bits() [02:35:59 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:49ae02d36f25: avcodec/gif: Fix lzw buffer size [02:36:00 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:a9a6e4e9c1f6: avcodec/ass_split: Fix null pointer dereference in ff_ass_style_get() [02:36:01 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:5af593290488: avformat/avio: Limit url option parsing to the documented cases [02:36:02 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:0732e7b0eab4: avcodec/mpeg12enc: Move high resolution thread check to before initializing threads [02:36:03 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:9e44ea7c0f39: avcodec/wmaenc: Check ff_wma_init() for failure [02:36:04 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:76de78a9dbef: avformat/avformat: Replace some references to filenames by urls [02:36:05 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:fa9873cce8c5: avcodec/mjpegdec: Check for end for both bytes in unescaping [02:36:06 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:4f52c0a619ed: doc/demuxers: Document enable_drefs and use_absolute_path [02:36:07 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:53f5efcae117: avformat/concat: Check protocol prefix [02:36:08 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:106e0fff2e88: avformat: Document urls a bit [02:36:09 CET] <cone-985> ffmpeg 03Paul B Mahol 07release/2.4:ac8a265be81a: avcodec/flacenc: fix calculation of bits required in case of custom sample rate [02:36:10 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:9a1433683cf3: avutil/opt: check for and handle errors in av_opt_set_dict2() [02:36:11 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:a944744f197a: avcodec/jpeg2000dec: More completely check cdef [02:36:12 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:a49d870aac6c: MAINTAINERS: remove unmaintained releases [02:36:13 CET] <cone-985> ffmpeg 03Derek Buitenhuis 07release/2.4:8380f62155d9: mov: Add an option to toggle dref opening [02:36:14 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.4:3709c43887c8: Update for 2.4.13 [02:45:39 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.7:d2b2c66b17a2: MAINTAINERS: remove unmaintained releases [02:53:32 CET] <cone-985> ffmpeg 03Stephen Hutchinson 07n2.7.6:HEAD: libx265: Enable 12-bit encoding [03:06:52 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:0f091f808af7: swscale/swscale-test: Fix slice height in random reference data creation. [03:06:53 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:9acbe5fa8489: avcodec/aacenc: Check both channels for finiteness [03:06:54 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:78c9e1f00b4c: swscale/swscale_unscaled: Fix odd height inputs for bayer_to_rgb24_wrapper() [03:06:55 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:aea2f5a6eeb7: swscale/swscale_unscaled: Fix odd height inputs for bayer_to_yv12_wrapper() [03:06:56 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:c48296d3bf1c: swscale/x86/rgb2rgb_template: Fix planar2x() for short width [03:06:57 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:372ea28f6832: swscale/swscale: Add some sanity checks for srcSlice* parameters [03:06:58 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:524ee420502c: avcodec/tiff: Check subsample & rps values more completely [03:06:59 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:8394fa26961d: avcodec/put_bits: Assert buf_ptr in flush_put_bits() [03:07:00 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:2b7f125af78b: avcodec/gif: Fix lzw buffer size [03:07:01 CET] <cone-985> ffmpeg 03Derek Buitenhuis 07release/2.6:1733981ec3ac: mov: Add an option to toggle dref opening [03:07:02 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:0b70b546a226: avcodec/ass_split: Fix null pointer dereference in ff_ass_style_get() [03:07:03 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:4de748119497: avformat/avio: Limit url option parsing to the documented cases [03:07:04 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:ee5ba0a1ad8b: avcodec/mpeg12enc: Move high resolution thread check to before initializing threads [03:07:05 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:0d312030d25b: avcodec/wmaenc: Check ff_wma_init() for failure [03:07:06 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:4950c02d44f9: avformat/avformat: Replace some references to filenames by urls [03:07:07 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:302a3269d623: avcodec/mpegvideo_enc: Check for integer overflow in ff_mpv_reallocate_putbitbuffer() [03:07:08 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:517c856d7fea: avcodec/mjpegdec: Check for end for both bytes in unescaping [03:07:09 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:50ca8b72d57f: doc/demuxers: Document enable_drefs and use_absolute_path [03:07:10 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:a967e5515717: avformat/concat: Check protocol prefix [03:07:11 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:3bb83fd03369: avformat/libquvi: Set default demuxer and protocol limitations [03:07:12 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:e4b4f9e2dc30: avformat: Document urls a bit [03:07:13 CET] <cone-985> ffmpeg 03Paul B Mahol 07release/2.6:f71e0b798a50: avcodec/flacenc: fix calculation of bits required in case of custom sample rate [03:07:14 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:361af0a47cee: avutil/opt: check for and handle errors in av_opt_set_dict2() [03:07:15 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:684e189eb3a5: avcodec/jpeg2000dec: More completely check cdef [03:07:16 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:d91a03d46ce2: MAINTAINERS: remove unmaintained releases [03:07:17 CET] <cone-985> ffmpeg 03Michael Niedermayer 07release/2.6:a3a5aedc0782: Update for 2.6.8 [03:27:03 CET] <BBB> omg auto-vectorization is useful after all? [03:27:16 CET] <BBB> I remember some blog post that the only thing it optimized was memset(0) calls in init functions [03:27:18 CET] <BBB> (a few years ago) [03:29:29 CET] <TD-Linux> I used it about a year ago and it worked okay [03:29:42 CET] <TD-Linux> especially with adequate use of restrict etc [03:43:23 CET] <cone-985> ffmpeg 03Stephen Hutchinson 07n2.6.8:HEAD: libx265: Enable 12-bit encoding [03:57:02 CET] <Timothy_Gu> the autovectorization patch makes ffmpeg get 3MB bigger (not --enable-small)... [04:05:07 CET] <jamrial> after stripping? [04:19:42 CET] <Timothy_Gu> ya after stripping [07:28:59 CET] <Gramner> Timothy_Gu: 64-bit registers outside of addressing brackets (and 32-bit registers inside addressing brackets) require the use of a REX-prefix, so the code becomes larger when using 64-bit regs when it's not neccessary. also some more complex instructions are slower when using 64-bit registers on some older cpus [10:45:27 CET] <cone-454> ffmpeg 03Hendrik Leppkes 07master:f85cc3bf1223: hevc: set profile based on the profile compatibility flags if needed [10:45:27 CET] <cone-454> ffmpeg 03Bruce Dawson 07master:09b3a42495b4: riffdec: Explicitly null-terminate array to work around VC++ bug [10:52:20 CET] <cone-454> ffmpeg 03Carl Eugen Hoyos 07master:9ca5b2724010: lavf/adxdec: Add Autodetection. [11:31:07 CET] <ubitux> so, how are we supposed to behave when facing negative timestamps? [11:32:44 CET] <wm4> in which situations? [11:34:02 CET] <ubitux> http://dpaste.com/029FFGR.txt [11:34:04 CET] <ubitux> this one [11:35:03 CET] <andrey_utkin> could maillist moderators please approve tonights letter "doc/examples/transcoding cannot into libx264" to ffmpeg-devel and libav-user? [11:37:15 CET] <wm4> ubitux: depends what the hell mov/mp4 specifies here [11:46:38 CET] <ubitux> FFS apple decided that a pdf for a specs wasn't a good thing so they put it on a fucking website with shitty js folding and the inability to search in it [11:46:42 CET] <ubitux> fuck these assholes seriously [11:46:48 CET] <ubitux> fuck them, i'm so annoyed [11:47:42 CET] <wm4> I'm sure Daemon404 or Paranoialmaniac know about negative timestamps in mov/mp4 [12:00:26 CET] <nevcairiel> andrey_utkin: i see those mails on the ML already [12:02:28 CET] <durandal_1707> ubitux: negative timestamps should be properly scaled if not passed unchanged [12:02:44 CET] <ubitux> what is the player supposed to do? [12:03:01 CET] <cone-454> ffmpeg 03Paul B Mahol 07master:0a7379d9cfc0: avfilter/vf_yadif: make use of ctx pointer [12:03:09 CET] <wm4> probably depends in the player [12:05:37 CET] Action: durandal_1707 will push nnedi [12:06:09 CET] <ubitux> wm4: it's a general question, how do you interpret it? [12:06:35 CET] <ubitux> like, you have the first video ts at -320, and let's say you have the audio at -640, or even +640 [12:06:40 CET] <ubitux> what do you do in these situations? [12:07:10 CET] <wm4> mpv doesn't care [12:07:11 CET] <ubitux> do you start by offsetting everything by min_ts? [12:07:30 CET] <ubitux> and fill the gaps with either silence for audio and black frames for videos? [12:07:32 CET] <wm4> well if libavformat reports a start time, then all timestamps are offset by that after the demuxer [12:07:51 CET] <wm4> but either way the player core doesn't care if the first timestamps isn't 0 [12:08:01 CET] <wm4> it's similar to the case after seeking, where the timestamp isn't 0 either [12:08:04 CET] <ubitux> ah, so you do a pts + stream->start_time? [12:08:22 CET] <wm4> yeah (pts - start_time) [12:08:34 CET] <ubitux> why does mpv have this laggy effect then? [12:08:39 CET] <ubitux> is it another issue? [12:08:46 CET] <wm4> but it doesn't matter, unless a player 1. expects start time = 0, or 2. has unsigned pts, or 3. has special logic for pts<0 [12:09:09 CET] Action: durandal_1707 gonna write filter that creates own filtergraph [12:09:11 CET] <wm4> dunno [12:09:14 CET] <wm4> maybe some bug [12:10:54 CET] <wm4> ubitux: which was the sample again? [12:13:14 CET] <ubitux> http://b.pkh.me/LZZX7353.MOV [12:13:25 CET] <ubitux> ok so, the "laggy" effect is probably normal [12:13:40 CET] <ubitux> the frame are actually that way [12:13:54 CET] <ubitux> it appears smooth in QT because they're actually dropping the frames [12:14:02 CET] <wm4> what [12:14:15 CET] <ubitux> the first frame in qt is the first non negative one [12:14:19 CET] <wm4> anyway, might be the camera reducing framerate due to bandwidth then? [12:14:41 CET] <wm4> maybe there's an edit list thing that discards the frames? [12:14:48 CET] <wm4> I have no clue about mov though [12:15:05 CET] <ubitux> yes there is an edit list [12:15:09 CET] <ubitux> with a single entry [12:15:19 CET] <ubitux> value=320 (the start time basically) [12:16:04 CET] <ubitux> so we basically if there is a start time, we should just discard anything before it? [12:18:46 CET] <wm4> is it possible to mark frames as "do not display"? [12:19:00 CET] <ubitux> well, i guess that's what pts<0 means [12:19:08 CET] <ubitux> or even the start time [12:21:52 CET] <wm4> not sure if I agree with such semantics in general, but it could work anyway [12:24:18 CET] <ubitux> quicktime behaves like this, so apparently that's how you're supposed to [12:24:49 CET] <wm4> if it's mov [12:25:05 CET] <wm4> anyway, I guess there seriously aren't any other uses of negative timestamps [12:37:59 CET] <kierank> ubitux: how familiar are you with the teletext decoder? [12:39:31 CET] <ubitux> not much, but you can ask [12:41:02 CET] <kierank> basically i was wondering how the bitmaps work [12:41:15 CET] <kierank> when the subtitles "run along" [12:41:24 CET] <kierank> when you have one word, then another then another appear [12:44:04 CET] <ubitux> i don't know, maybe ask tmm1_ [12:54:19 CET] <wm4> the lavc API is such that a new bitmap subtitle completely replaces the previous one [13:04:32 CET] <wbs> ubitux: yes, in mov/mp4, pts<0 doesn't exist, and the start time in this case means "start presenting the content from this timestamp" - mainly used to cut out e.g. audio preroll [13:05:06 CET] <ubitux> i don't like the "in this case" :( [13:05:31 CET] <wbs> (and to handle delays with e.g. b-frames) [13:07:17 CET] <wm4> for audio we have AV_FRAME_DATA_SKIP_SAMPLES [13:07:20 CET] Action: JEEB is just debugging something similar [13:07:24 CET] <wm4> which handles this in a container-agnostic way [13:07:34 CET] <wm4> probably could be used for video too? [13:07:38 CET] <JEEB> tfxd and timestamp differences between tracks [13:07:59 CET] <ubitux> i suppose it's a video preroll in this case as well, like, the camera isn't yet hot/in sync (that's why it's "laggy" when you play it) [13:08:11 CET] <ubitux> (there is no audio) [13:08:31 CET] <ubitux> i don't understand why they just don't drop the frames though, but whatever [13:09:15 CET] <Venti^> s [13:12:50 CET] <cone-454> ffmpeg 03Paul B Mahol 07master:75f3e5e08226: avdevice/lavfi: replace deprecated avpicture_layout [13:43:20 CET] <cone-454> ffmpeg 03Paul B Mahol 07master:79991b2288a9: avfilter: add nnedi filter [13:56:32 CET] <JEEB> does the nnedi help or documentation point you towards the weights? [13:59:14 CET] <wm4> I wonder if this slower or faster than the mpv shaders [14:00:58 CET] <nevcairiel> C will be slower than a GPU could ever be [14:03:56 CET] <wm4> not sure about that, the shader is extremely slow and unoptimized [14:04:54 CET] <cone-454> ffmpeg 03Umair Khan 07master:9effa0125531: doc/ffmpeg: explain properly how -fs works [14:08:56 CET] <kierank> can someone push my fuzz patch [14:11:15 CET] <durandal_1707> wm4: its nowhere realtime for SD [14:16:51 CET] <J_Darnley> kierank: did you post it on the ML? Is it the "Fixes tickets #5208 and #5209" one? [14:17:02 CET] <J_Darnley> "[FFmpeg-devel] [PATCH] avcodec/cfhd: Make sure we have an end of header tag before allocating a frame."? [14:17:14 CET] <durandal_1707> that one [14:17:14 CET] <kierank> yes [14:17:21 CET] <kierank> I can't push it currently [14:17:26 CET] <kierank> on the wrong pc [14:17:45 CET] <J_Darnley> Sure. I will. Let just switch back to master. [14:21:32 CET] <cone-454> ffmpeg 03Kieran Kunhya 07master:bdd8e02b72e7: avcodec/cfhd: Make sure we have an end of header tag before allocating a frame. [14:22:52 CET] <J_Darnley> There you go [14:25:55 CET] <Daemon404> [10:47] <+wm4> I'm sure Daemon404 or Paranoialmaniac know about negative timestamps in mov/mp4 <-- too much [14:25:57 CET] <Daemon404> and also [14:26:00 CET] <Daemon404> theyre onlt negative in lavf [14:26:11 CET] <Daemon404> due to the way it handles edit lists [14:26:24 CET] <Daemon404> theyre not actually coded negative [14:26:44 CET] <Daemon404> indeed timestamps are unsigned in isobmff [14:27:28 CET] <wm4> fascinating [14:38:27 CET] <Daemon404> ubitux, pingpong [14:39:23 CET] <jrosser> isnt there a subtlety that one of mov/mp4 allows -ve timestamps and the other doesnt? [14:39:58 CET] <Daemon404> not sure what -ve does [14:40:53 CET] <jrosser> i dont remember this very well (looong time ago) but it was due to coded vs display order [14:41:09 CET] <jrosser> and what happened at the very start of the file [14:41:34 CET] <Daemon404> sure, the first PTS in mp4 for e.g. h264 is usually non-zero [14:41:39 CET] <Daemon404> due to frame reordering [14:41:49 CET] <Daemon404> usually there is an edit list to compensate [14:42:00 CET] <Daemon404> lavf applies this in such a way taht it shifts everything back to the fitst entry of teh edit list [14:42:06 CET] <Daemon404> making the dts negative [14:42:32 CET] <Daemon404> of course, this is wrong for edit lists with more than one entry. [14:42:33 CET] <jrosser> my very distant memory is that the defintions of the mov vs mp4 containers are slightly different wrt this [14:42:36 CET] <Daemon404> yes [14:42:40 CET] <Daemon404> mov timestamps are signed [14:42:42 CET] <Daemon404> mp4 are not [14:42:50 CET] <Daemon404> however, you can do the same in mov [14:42:56 CET] <Daemon404> multiple ways to do everything in mov/mp4 [14:42:59 CET] <Daemon404> it's like the perl of containers. [14:45:03 CET] <wm4> write-only? [14:46:47 CET] <Daemon404> that said its still way less painful than most containers [14:46:49 CET] <Daemon404> if you use a good subset [14:46:52 CET] <JEEB> yeah [14:46:56 CET] <JEEB> ENOBIFS [14:47:02 CET] <JEEB> iä iä BIFS f'thagn [14:47:16 CET] <JEEB> (that's what they recommend to use for chapters, crazy folk) [14:50:37 CET] <Paranoialmaniac> on player, negative timestamps in mp4/mov make no sense. you can see there are always implicit or explicit edits on presentation and the spec does not refer to the start time i.e. arbitrary. there are maps from media timelines to a presentation timeline [14:51:02 CET] <Paranoialmaniac> that's all [14:51:35 CET] Action: Paranoialmaniac hides [14:51:38 CET] <Daemon404> :P [14:51:40 CET] <Daemon404> hmm [14:51:41 CET] <Daemon404> "Dear FFmpeg developer, [14:51:41 CET] <Daemon404> we are conducting a short survey to study the characteristics of [14:51:42 CET] <Daemon404> developer roles that exist in open-source communities." [14:51:58 CET] <Daemon404> sure do get a lot of emails about FOSS studies [14:52:03 CET] <Daemon404> 2-4 a year [14:56:42 CET] <BBB> Daemon404: I think we all got that one [14:56:50 CET] <Daemon404> BBB, yeah [14:56:56 CET] <BBB> Daemon404: typical hi Im doing a masters in business school please help me do my homework [14:57:04 CET] <BBB> heres a question my teacher is asking me to ask someone" [14:57:09 CET] <BBB> $lawyer_legal_business_language [14:57:14 CET] <BBB> ktnxbye" [14:57:18 CET] <ubitux> Daemon404: timecode? [14:57:24 CET] <Daemon404> ubitux, aye [14:57:30 CET] <Daemon404> michael reviewed 2 of 3 [14:57:34 CET] <Daemon404> ffprobe change needs review [14:57:39 CET] <ubitux> Daemon404: any reason not to set it to every frame btw? [14:57:43 CET] <ubitux> :p [14:57:51 CET] <Daemon404> because its not the timecode for every frame? [14:57:55 CET] <Daemon404> it only applies to one frame per gop [14:57:59 CET] <ubitux> but you can compute the missing ones :) [14:58:15 CET] <Daemon404> that doesnt seem like our job. [14:58:27 CET] <ubitux> depends if you want to print them in drawtext :° [14:58:31 CET] <ubitux> anyway, no problem :) [14:58:38 CET] <ubitux> if you obtain matching timecode with ffprobe, it's fine with me [14:58:43 CET] <Daemon404> yeah i do [14:58:44 CET] <Daemon404> i checked [14:58:49 CET] <Daemon404> i actually think it is more useful [14:58:54 CET] <Daemon404> since the old way only showed the first [14:58:55 CET] <Compn> Daemon404 : we should ask the students for the teachers name and then talk to the teacher and ask him why hes making his studnets bug FOSS projects [14:58:55 CET] <ubitux> well then it's fine with me [14:58:59 CET] <ubitux> please add a Changelog entry though [14:59:02 CET] <Daemon404> i did [14:59:07 CET] <Daemon404> oh wait i didnt [14:59:07 CET] <ubitux> great [14:59:09 CET] <Daemon404> lol. [14:59:18 CET] <ubitux> no more comment from me, thanks [14:59:21 CET] <Daemon404> al lright [14:59:25 CET] <ubitux> we have ffprobe tests btw [14:59:30 CET] <Daemon404> i know [14:59:37 CET] <ubitux> you might want to add one at some point, but i feel like you're fed up with it :p [14:59:38 CET] <Daemon404> the only part im unhappy about is where i put the code in mpeg*.c [14:59:41 CET] <Daemon404> as noted in the patch [14:59:45 CET] <Daemon404> nobody suggested a better place though [14:59:57 CET] <ubitux> at the end at got output seems ok with me [15:00:09 CET] <ubitux> but i'm not a mpeg expert :p [15:00:11 CET] <Daemon404> seemed kinda "high level" [15:00:13 CET] <Daemon404> but eh. [15:01:34 CET] <Daemon404> BBB, weirdly this has a siemens url [15:01:46 CET] <kierank> probably a student [15:01:49 CET] <Daemon404> yeah [15:18:09 CET] <BBB> do we have a way to skip the first N frames from an input file in ffmpeg? [15:18:16 CET] <BBB> like -ss, but in frame number instead of time [15:18:45 CET] <Daemon404> BBB, -r 1, then 1s = 1 frame [15:18:52 CET] <Daemon404> ive ysed this trick to trim e.g. .h264 before [15:18:57 CET] <Daemon404> but YMMV [15:19:01 CET] <Daemon404> depending on use case [15:19:03 CET] <BBB> does that work for input which has a framerate? [15:19:07 CET] <BBB> my input is ffv1/mkv [15:19:16 CET] <Daemon404> probably not [15:19:21 CET] <Daemon404> remember that lavf is not frame accurate [15:19:36 CET] <Daemon404> (i use an external library for this) [15:22:22 CET] <Compn> BBB : if ffmpeg has framestep filter ? [15:22:37 CET] <Daemon404> filter doesnt do jack if you want to remux. [15:22:42 CET] <Compn> ah [15:22:45 CET] <Daemon404> or dont want to decode all the preceding frames [15:23:09 CET] <BBB> hm I guess I have to write my own helper for this then [15:23:34 CET] <Daemon404> frame -> time is pretty simple [15:24:58 CET] <Daemon404> assuming CFR. [15:25:10 CET] <Daemon404> otherwise youll need the index [15:25:41 CET] <BBB> I did frame/fps [15:25:45 CET] <BBB> and its off by a few frames [15:26:55 CET] <Daemon404> not sure how we seek in mkv [15:27:49 CET] <Daemon404> (and i never use -ss) [15:31:23 CET] <cone-454> ffmpeg 03Michael Niedermayer 07master:af24b1c0cd3c: Revert "avformat/hls: Require the file extension to be m3u / m3u8 for probing to succeed" [15:36:07 CET] <BtbN> ah, so that's why twitch streams stopped working [15:47:42 CET] <wm4> what did twitch do? [15:48:15 CET] <BtbN> Nothing, but they have a massive amount of query strings behind the .m3u8 [16:13:40 CET] <cone-454> ffmpeg 03James Almer 07master:77b5b952470a: avcodec/dca_core: rename get_vlc function [16:13:41 CET] <cone-454> ffmpeg 03James Almer 07master:f781bf3e101b: fate: re-enable dca-xll test [16:55:38 CET] <atomnuker> michaelni: I got an email about the dirac HQ profile decoding [16:56:43 CET] <atomnuker> the tables we have support up to 128 quantization values [16:57:09 CET] <atomnuker> but the HQ profile spec does allow up to 8 bits to be used (different from the low delay mode which only uses 7 bits) [16:58:24 CET] <atomnuker> michaelni: can you generate new quanziation tables (with taking overflows in account like last time) if I sent you the part of the spec that specifies how? [17:01:18 CET] <michaelni> if the equations are the same then further values would not fit in 32bit ints [17:01:37 CET] <atomnuker> oh yeah, forgot about that [17:50:44 CET] <Timothy_Gu> kierank: is avdev still open to general use? [17:50:55 CET] <kierank> erm probably but I reinstalled it [17:54:25 CET] <atomnuker> can someone compile without optimizations and test if fate-dirac still passes? [18:00:45 CET] <atomnuker> nvm it works [18:00:51 CET] <BBB> blegh that sucked [18:00:59 CET] <BBB> I ended up writing my own ffmpeg.c sort of thing :D [18:01:19 CET] <BBB> I have to admit that our API usability has gone up a fair deal, I find it fairly easy to get things done with it nowadays [18:53:17 CET] <cone-454> ffmpeg 03Sebastian Dröge 07master:e3a125c970db: Revert "do not write f2 if not interlaced" [19:30:04 CET] <wm4> nevcairiel: time to push that main10 patch? [19:33:43 CET] <cone-454> ffmpeg 03Derek Buitenhuis 07master:66e9d2f44ee0: avutil: Add GOP timecode frame side data [19:33:44 CET] <cone-454> ffmpeg 03Derek Buitenhuis 07master:792a5cefbe53: mpeg12dec: Export GOP timecodes as side data [19:33:45 CET] <cone-454> ffmpeg 03Derek Buitenhuis 07master:b62825a48051: ffprobe: Deprecate stream timecode field and add frame side data timecode field [19:35:43 CET] <kierank> Gramner: can you review J_Darnley's patch when you have time please :) [20:41:46 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:d1fc87529f38: swscale/swscale-test: Fix slice height in random reference data creation. [20:41:47 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:b515a23f7628: avcodec/aacenc: Check both channels for finiteness [20:41:48 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:262192a48b59: swscale/swscale_unscaled: Fix odd height inputs for bayer_to_rgb24_wrapper() [20:41:49 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:93c675d6a6c9: swscale/swscale_unscaled: Fix odd height inputs for bayer_to_yv12_wrapper() [20:41:50 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:9631209eeaf0: swscale/x86/rgb2rgb_template: Fix planar2x() for short width [20:41:51 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:0f956cde937b: swscale/swscale: Add some sanity checks for srcSlice* parameters [20:41:52 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:dee25a5fa5da: avcodec/tiff: Check subsample & rps values more completely [20:41:53 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:22e20a1d833e: avcodec/put_bits: Assert buf_ptr in flush_put_bits() [20:41:54 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:9f30eafd0f31: avcodec/gif: Fix lzw buffer size [20:41:55 CET] <cone-454> ffmpeg 03Derek Buitenhuis 07release/2.5:dd957b56e614: mov: Add an option to toggle dref opening [20:41:56 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:7ee0b1937a25: avcodec/ass_split: Fix null pointer dereference in ff_ass_style_get() [20:41:57 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:30463a0c9985: avformat/avio: Limit url option parsing to the documented cases [20:41:58 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:3fc75e79cf03: avcodec/mpeg12enc: Move high resolution thread check to before initializing threads [20:41:59 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:65bb07d4bed2: avcodec/wmaenc: Check ff_wma_init() for failure [20:42:00 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:2df2c0aab0ca: avformat/avformat: Replace some references to filenames by urls [20:42:01 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:0ec1ffcb4db4: avcodec/mpegvideo_enc: Check for integer overflow in ff_mpv_reallocate_putbitbuffer() [20:42:02 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:58ea532cad81: avcodec/mjpegdec: Check for end for both bytes in unescaping [20:42:03 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:e46999ccf440: doc/demuxers: Document enable_drefs and use_absolute_path [20:42:04 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:dde76f2d0414: avformat/concat: Check protocol prefix [20:42:05 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:0251cd6cf328: avformat/libquvi: Set default demuxer and protocol limitations [20:42:06 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:7bcf142c02e0: avformat: Document urls a bit [20:42:07 CET] <cone-454> ffmpeg 03Paul B Mahol 07release/2.5:d7c0287fbdac: avcodec/flacenc: fix calculation of bits required in case of custom sample rate [20:42:08 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:3fa6ecca7632: avutil/opt: check for and handle errors in av_opt_set_dict2() [20:42:09 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:69e191f854f7: avcodec/jpeg2000dec: More completely check cdef [20:42:10 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:5eca7ba16b8c: MAINTAINERS: remove unmaintained releases [20:53:49 CET] <cone-454> ffmpeg 03Michael Niedermayer 07release/2.5:60eebbbf22f3: Update for 2.5.11 [22:17:31 CET] <jamrial> nevcairiel: tiny_pnsr seems only able to compare s16 pcm audio [22:17:53 CET] <nevcairiel> thats what all those lossy tests use [22:18:01 CET] <nevcairiel> converts to s16 and then compares that [22:18:29 CET] <jamrial> wouldn't it be better to stick with s24 if possible? [22:18:49 CET] <nevcairiel> it comes out of the decoder as float [22:19:08 CET] <nevcairiel> (unlike libdcadec, he stuck to a pure float chain) [22:19:17 CET] <jamrial> ah true [22:19:39 CET] <nevcairiel> tiny_psnr actually supports float [22:19:45 CET] <jamrial> did you reuse the pcm reference files (merged into multichannel files) or made new ones? [22:19:55 CET] <nevcairiel> make fate-dca GEN=1 =p [22:20:09 CET] <nevcairiel> his are wav's [22:20:13 CET] <jamrial> haha [22:20:15 CET] <nevcairiel> would need careful mangling :( [22:20:32 CET] <nevcairiel> but i confirmed its bitexact to libdcadec wrapper [22:20:36 CET] <nevcairiel> so .. [22:20:38 CET] <jamrial> well, you could always use amerge filter taking all mono files as input and barfing a multichannel pcm file [22:23:36 CET] <nevcairiel> his files are also 24-bit wavs which we cant use anyway [22:23:40 CET] <nevcairiel> so not sure there is anything to gain [22:37:53 CET] <jamrial> nevcairiel: forcing the tests to use f32le results in somewhat bigger reference pcm files. about ~550kb extra [22:37:56 CET] <jamrial> not sure if worth it [22:38:25 CET] <nevcairiel> and would probably need careful tuning of the compare functions [22:38:35 CET] <nevcairiel> who knows how big the difference in float can be on some systems [22:39:09 CET] <nevcairiel> all the float decoders use the pcm s16 mode and oneoff compare, so it seems fine for the lossy tests [22:39:20 CET] <nevcairiel> i made the lossless tests stick to their original bitdepth [22:39:42 CET] <jamrial> yeah [22:40:14 CET] <nevcairiel> curious that there is no stereo f ile in the bunch [22:40:16 CET] <nevcairiel> but oh well [22:40:42 CET] <jamrial> one of the 5.1 files has stereo downmix coeffs, so your idea to test that is good [22:40:52 CET] <nevcairiel> yeah i noticed [22:41:08 CET] <nevcairiel> those with _0 _1 endings usually have one with coeffs [22:43:26 CET] <nevcairiel> i guess i'll just pick 2 or 3 which I know have coeffs to test that code path [23:10:57 CET] <nevcairiel> there posted a new patch with a select number of downmix tests [23:52:09 CET] <Daemon404> :D [00:00:00 CET] --- Tue Feb 2 2016

1 0

ffmpeg.log.20160201
by burek 02 Feb '16

02 Feb '16

[00:15:47 CET] <xochilpili> hi there! [00:16:21 CET] <xochilpili> im having some issues with mkvmerge and subtitles Error: The file 'subtitle.srt' has unknown type [00:16:26 CET] <xochilpili> any hand with this? [00:17:11 CET] <sbraz> xochilpili: that's a mkvtoolnix question, care to upload the file somewhere though? [00:22:08 CET] <solrize> hmm thanks i'm currently using vp8 encoder which only uses 1 core. [01:08:25 CET] <p1_> where should I report a company that is using ffmpeg in a product without attribution nor source? [01:08:46 CET] <c_14> open an issue on trac [01:13:07 CET] <p1_> yeah, I'd prefer to do it anomomously [01:14:28 CET] <velusunivers-sys> hello ca\n ffmpeg be used as a streaming server? im hoping to get a online tv station for virtual worlds, im needing to have something that will be able to play videos from a list i.e xml [01:20:18 CET] <J_Darnley> p1_: email someone directly then [01:20:48 CET] <J_Darnley> Michael Niedermeier perhaps (michaelni) [01:21:48 CET] <J_Darnley> There's also a private security mailing list you could email but I'm not sure about the nettiquette using it for non security matters. [01:23:57 CET] <retard> velusunivers-sys: ffserver [01:24:21 CET] <velusunivers-sys> how easy is it to set up, and what format does it stream in? [01:24:37 CET] <c_14> I honestly wouldn't recommend ffserver. [01:24:45 CET] <c_14> Use HLS/dash or maybe nginx-rtmp [01:24:45 CET] <velusunivers-sys> why not? [01:25:05 CET] <velusunivers-sys> i need something that can read from a play list [01:25:09 CET] <p1_> I think there needs to be a way to report these things anonomously, as people take a risk doing so. [01:25:23 CET] <velusunivers-sys> i would prefere the playlist be in xml but yeah any format would be good [01:25:52 CET] <c_14> p1_: create an account on trac with a throwaway email address? [01:27:20 CET] <J_Darnley> I guess it depends how anon you want to be. We could set up some sort of tor-only drop box but that sounds like a lot of work. [01:27:33 CET] <p1_> can I just report it here? [01:27:57 CET] <J_Darnley> Are you aware that this channel is publicly logged? [01:28:14 CET] <p1_> do they log ip addresses? [01:28:39 CET] <velusunivers-sys> how easy is ffserver to set up and what format does it stream in? [01:28:41 CET] <J_Darnley> Not sure. I would have to check it to see if joins are there. [01:28:44 CET] <c_14> I'm pretty sure join/parts are logged. Yes [01:29:08 CET] <p1_> ok, I'll go to a internet cafe and do it :-) [01:30:14 CET] <c_14> Hmm, it doesn't look like they're logged on the public logs, but there could always be other ones. [01:30:52 CET] <p1_> cafe sounds the safest anyway [01:31:27 CET] <J_Darnley> I wonder if its the NSA and he's in danger of being black bagged [01:31:41 CET] <J_Darnley> No, the CIA do that. [01:31:47 CET] <J_Darnley> Is it them? [01:34:24 CET] <velusunivers-sys> CIA NSA and the MI6 MI7, and SPC [01:34:36 CET] <velusunivers-sys> do the black bagging [01:35:00 CET] <J_Darnley> Don't forget our benevolent overlords from the FSB [01:38:22 CET] <p1_> It is a company Called echo360, and the product is echo360. They bundle up ffmpeg in a java wrapper to obscure it, but you can see it running in the process table when the wrapper is called. [01:38:53 CET] <Bray90820> is this a good channel to talk about video editing? [01:40:43 CET] <J_Darnley> Bray90820: a little off topic but we do know things [01:42:11 CET] <Bray90820> j am basically looking for a way maybe in adobe premiere to keep the same dolby digital 5.1 audio track as was on the video before I edited it [01:42:15 CET] <Bray90820> If that makes any sense [01:43:49 CET] <J_Darnley> If you made edits in time then I guess it won't let you do that. [01:44:07 CET] <J_Darnley> Maybe you can import the original again as new new track or something. [01:44:23 CET] <Bray90820> I meant the same encoding [01:44:45 CET] <Bray90820> Or maybe format it's called [01:44:48 CET] <J_Darnley> You mean you want it to encode to 5.1 DTS? [01:45:39 CET] <Bray90820> I am actually not sure if I want 5.1 DTS what I want is whatever the video had originally [01:46:24 CET] <J_Darnley> Well you probably need to tell it what format you want the audio. [01:46:58 CET] <J_Darnley> I can't say whether it has a "look at the input and make it like that" setting. [01:47:14 CET] <Bray90820> Is there a way I can tell it to keep the same format? [01:48:00 CET] <J_Darnley> I have no idea. I've never used it. [01:48:33 CET] <Bray90820> Alright [01:48:41 CET] <Bray90820> Thanks for the help you could give [01:54:59 CET] <andrey_utkin> JEEB: "doc/examples/transcoding cannot into libx264" with all details emailed to libav-user and ffmpeg-devel @ ffmpeg.org. Awaits moderation approval (not subscribed on my new mail) [12:31:03 CET] <dorp> I'm trying to use ffmpeg for capturing an audio device under Windows: "CABLE Output (VB-Audio Virtual Cable)" ... but it seems that I can't specify 6 channels, ffmpeg says: "Guessed Channel Layout" ... "Stereo" ... anybody has any idea if/how to enable 6 channels? [12:40:27 CET] <J_Darnley> What input device are you using (dshow, other)? [12:41:21 CET] <J_Darnley> That has the channels options you can try [12:41:53 CET] <dorp> J_Darnley: Input #0, dshow, from 'audio=CABLE Output (VB-Audio Virtual Cable)' [12:42:28 CET] <J_Darnley> try prepending "channels=6:" to the input argument. [12:44:32 CET] <dorp> As in: -f dshow -i channels=6:audio="..." ... ? "Malformed dshow input string" [12:44:48 CET] <J_Darnley> Yes [12:45:06 CET] <J_Darnley> Oh [12:45:23 CET] <J_Darnley> Maybe I mean: add -channels 6 before -i [12:47:05 CET] <dorp> J_Darnley: Not sure what that's about: "Could not set audio only options" ... "Searching for audio device within video devices..." [12:47:16 CET] <dorp> Do I have to specify a video input device, too? [12:47:53 CET] <J_Darnley> I have no idea. I've only used dshow acouple of times to capture a webcam. [12:48:26 CET] <J_Darnley> You can use -list_option to show the options available for your audio device. [12:48:41 CET] <J_Darnley> -list_options [12:49:27 CET] <relaxed> look at "ffmpeg -h demuxer=dshow" [12:49:59 CET] <dorp> -list_options reveals: Pin "Capture" (alternative pin name "Capture") ... min ch=1 bits=8 rate= 11025 max ch=2 bits=16 rate= 44100 [12:51:27 CET] <dorp> relaxed: Thanks for the hint [12:51:37 CET] <J_Darnley> There's also http://ffmpeg.org/ffmpeg-devices.html#dshow [12:52:03 CET] <dorp> It seems that "-channels 2" works, where "-channels 6" produces: "Could not set audio only options" [12:52:24 CET] <J_Darnley> But I think it looks like 6 channel input for your device isn't available through dshow (or ffmpeg doesn't know how). [12:52:40 CET] <dorp> I guess I better look for another audio device and see if it works there [12:53:19 CET] <dorp> (if anybody has a suggestion for such an audio device, to capture 6 channels under Windows, that happens to work with ffmpeg, I'm open to suggestions) [12:54:10 CET] <tp_> anyway to use -ss while using -re too? [13:04:30 CET] <mcmillen_> msg [13:05:50 CET] <mcmillen_> msg how to use videotoolbox in FFmpeg? [13:07:16 CET] <mcmillen_> msg FFmepg's official wiki and website has no any document or examples about the videotoobox [13:14:34 CET] <BtbN> What even is "the videotoolbox"? [13:16:18 CET] <J_Darnley> tp_: Does it not work? [13:16:20 CET] <mcmillen_> videotoolbox is a framework both in iOS and OS X, for h264 hardware encoding/decoding [13:17:00 CET] <mcmillen_> i can't find any example code for videotoolbox hwaccel [13:18:08 CET] <mcmillen_> ffmpeg release 2.8 source include the videotoolbox support in libavcodec/videotoolbox.h, but no actually work [13:19:26 CET] <J_Darnley> If you can't compile ffmpeg with that support then please tell us more. [13:19:51 CET] <BtbN> It's propably just like any other hwaccel. ffmpeg just fills the buffers for you [13:19:57 CET] <J_Darnley> Is there some other problem you're experiencing? [13:20:13 CET] <J_Darnley> "doesn't work" is not an error message. [13:22:36 CET] <mcmillen_> is there any document or example for videotoolbox ? like qsv-accelerated decoding? https://www.ffmpeg.org/doxygen/2.8/qsvdec_8c-example.html#a72 [13:24:33 CET] <J_Darnley> It doesn't look like it (judging from grep) [13:24:57 CET] <J_Darnley> All I can say is read how ffmpeg does it. [13:29:59 CET] <BtbN> QSV is a "complete" encoder. VT is just a hwaccel module. [13:30:10 CET] <BtbN> You still have to do the majority of work yourself. [13:30:35 CET] <mcmillen_> even the vda-acclerated decoding just a wiki with few introduction. https://github.com/dilaroga/ffmpeg-vda/wiki/FFmpeg-vda-usage [13:31:11 CET] <BtbN> That page is not from ffmpeg. [13:33:02 CET] <tp_> J_Darnley: nope, it will just delay showing the video until the seconds it gets from -ss [13:33:29 CET] <J_Darnley> Can ffmpeg seek in the input or is it some sort of stream? [13:33:40 CET] <tp_> it can see [13:33:55 CET] <tp_> seek* [13:34:01 CET] <J_Darnley> okay. I guess -re does emulate well then. [13:34:23 CET] <mcmillen_> actually, the developer using the FFmpeg, almost can't using the hwaccel feature. isn't it ? i search "ffmpeg videotoolbox" from google these days, can't find example code any. [13:34:28 CET] <tp_> i can seek the video with -ss, when im not using -re, but when using -re, i can't [13:35:03 CET] <J_Darnley> And -re is supposed to make ffmpeg behave as though it is a stream (or something). [13:35:31 CET] <J_Darnley> Oh I should ask: are you putting -ss before the -i? [13:35:42 CET] <tp_> yes, before, also tried after [13:36:06 CET] <J_Darnley> Then if you feel it is a bug then submit a report to trac. [13:39:40 CET] <tp_> if theres some other way i can encode at normal speed, i dont think its a problem [13:40:03 CET] <J_Darnley> Why do you want to do that? [13:42:19 CET] <tp_> because im transcoding to a stream with seeking ability, and if i dont do it, ffmpeg will use 100% cpu, when im using -re it doesnt use 100% cpu, but then i cant seek [13:57:00 CET] <TekniQue> I have confirmed that ffmpeg is in fact horrible at multithreading [13:57:57 CET] <TekniQue> and as ou increase the number of outputs, performance goes down but CPU usage hits a ceiling [13:58:37 CET] <TekniQue> and doing the same work in multiple ffmpeg processes accomplishes a lot more than having one process produce multiple outputs [13:59:13 CET] <BtbN> Fully using every core seems more like it's good at multi threading. [13:59:31 CET] <TekniQue> it's not fully using every core, that's the problem [13:59:47 CET] <TekniQue> encoding drops below real time but cpu usage is at 50% roughly [14:00:06 CET] <TekniQue> but by running multiple processes I'm able to use more cpu [14:00:07 CET] <J_Darnley> More encoding -> more cpu usage -> cpu has limits -> encoding speed drops. Is that surprising? [14:00:08 CET] <BtbN> ffmpeg itself isn't multi threaded at all, btw. It's strictly single-threaded. Only certain encoders/filters are [14:00:10 CET] <TekniQue> and encode in real time [14:00:40 CET] <TekniQue> BtbN: that explains a lot [14:01:12 CET] <BtbN> No idea how multiple outputs are implemented, but I wouldn't be surprised if it works through them sequentualy for each packet [14:03:07 CET] <TekniQue> yeah that sounds likely [14:03:36 CET] <TekniQue> the scenario is that encoding 4 outputs doesn't use any more cpu than encoding 3 outputs [14:04:34 CET] <TekniQue> and that setting x264 to a faster preset reduces cpu time but doesn't improve encoding speed [14:04:52 CET] <BtbN> well, the encoder should still only run once, no matter how many outputs you have. So that doesn't sound unusual. [14:05:09 CET] <TekniQue> running 4 encoders actually [14:05:18 CET] <TekniQue> encoding at different resolutions and bitrates [14:05:40 CET] <BtbN> I wouldn't bother using a single ffmpeg process for it then. [14:05:42 CET] <BtbN> Just run 4 of them [14:05:50 CET] <BtbN> Way easier to manage, too [14:06:16 CET] <pkeuter> hey guys, i'm trying to run the following command: http://pastebin.com/LVQKGAKx, and it gives me a "Error when filtering: cannot allocate memory"-error. Any idea what could be wrong? The machine still has 12GB of RAM left, so that shouldn't be the issue... [14:06:47 CET] <TekniQue> BtbN: yup [14:09:12 CET] <durandal_1707> Probably amix fault [14:09:27 CET] <pkeuter> alright BtbN : http://pastebin.com/Tx9RC8fN, is that better? [14:10:53 CET] <BtbN> Is it a 32bit build of ffmpeg? That's running out of virtual memory for some reason? [14:11:12 CET] <pkeuter> durandal_1707, well that definately fixes it, removing the audio filters... [14:12:23 CET] <durandal_1707> pkeuter: use amerge and pan instead of amix [14:12:24 CET] <pkeuter> BtbN, it's built from source on a 64 bit machine, so no, i guess. [14:13:05 CET] <BtbN> Strange, what the hell is amix doing to exhaust the memory resources? [14:15:20 CET] <pkeuter> durandal_1707, what is the difference between amerge and amix? [14:15:35 CET] <pkeuter> And BtbN; my question exactly [14:16:54 CET] <durandal_1707> something stupid? [14:49:11 CET] <pkeuter> well thanks for getting me on the right path! [14:57:43 CET] <bobby_> I know this question has been asked many times on the mailing list, but I can't find any clear answer: is av_write_frame() functions is thread safe? [15:15:18 CET] <BtbN> At least not for the same context/packt [15:15:23 CET] <BtbN> +e [15:47:16 CET] <roxlu> Hey I'm working on some code which muxes mpeg-ts and I was wondering if someone knows a good approach to restamp the pts/pcr values. I know this is not a easy thing to do, but I was hoping someone here has done something similar. [16:18:22 CET] <DHE> the mpegts spec calls for the PCR to be very accurate (0.5 microsecond tolerance). any reason not to use ffmpeg since it should already do it properly? [16:25:45 CET] <Mavrik> ffmpeg's PCR timings are nowhere near spec compliant. [17:50:16 CET] <HiddenWolf> Hi all. I'm trying to follow the example on the wiki and re-encode a stream to x265, but I'm getting an error 'unrecognised option x265-params' [17:52:21 CET] <HiddenWolf> I am using ffmpeg 2.8.5,1 on FreeBSD 10.2 [17:53:35 CET] <atomnuker> HiddenWolf: paste your command line [17:54:25 CET] <dorp> Anybody happens to know if ffmpeg is capable of capturing 6 audio channels via dshow (Windows)? ... I've tried two virtual audio devices, and a physical external device, when I try: "-channels 6" I get: "Could not set audio options" [17:57:15 CET] <HiddenWolf> atomnuker: http://pastebin.com/Hrjj3Rah [17:58:09 CET] <HiddenWolf> atomnuker: adapted from the wiki and a stackexhange example. Ideally I'd grab the english subtitle from an idx file and mix that in as default [17:59:28 CET] <atomnuker> HiddenWolf: you can also set the crf using -crf 28 [17:59:41 CET] <atomnuker> so just remove -x265_params crf=28 and just use -crf 28 [18:00:03 CET] <atomnuker> or maybe just wrap "crf=28" in quotation marks [18:00:52 CET] <c_14> HiddenWolf: your version of ffmpeg isn't built against libx265 [18:01:04 CET] <HiddenWolf> c_14: ah [18:01:10 CET] <HiddenWolf> c_14: drat [18:04:17 CET] <furq> time to update your ports [18:05:05 CET] <HiddenWolf> furq: I guess. I just grabbed the default pkg though. Why build if they're pre-built for you. [18:05:19 CET] <furq> because the default options suck [18:05:26 CET] <furq> although i guess i don't need to tell you that now [18:05:57 CET] <HiddenWolf> furq: in this case, yeah. but it saves a lot of time and headache, usually. [18:06:29 CET] <HiddenWolf> At least, for the lazy amateur sysadmin that I am. [18:45:59 CET] <dorp> Anybody can guess whether ffmpeg should be able to capture 6 audio channels under Windows? (dshow) [18:46:41 CET] <dorp> (I don't know if I should bother looking for more devices to test with) [20:58:03 CET] <dorp> So apparently the issue I've stumbled is not specific to ffmpeg, but an issue with multi-channel recording with DirectShow as a whole. I've managed to use something called "WASAPI" with a non-free virtual audio device for capturing 6 audio channels. Not fun [21:20:42 CET] <markusl> hi [21:23:32 CET] <markusl> I'm trying to implement DASH audio streaming from alsa using ffmpeg. so far everything works, but now i'm trying to have multiple streams/representations in the manifest [21:24:18 CET] <markusl> that seems to work, too. but the manifest generated by ffmpeg has the same bitrate (128000) for every representation even if they differ. [21:24:40 CET] <markusl> I wonder if i'm calling the webm_dash_manifest in the wrong way or if this is a bug. [21:37:29 CET] <markusl> I've got the command lines (systemd unit) here: http://pastebin.com/22zHuGdE output of encoder + manifest generation: http://pastebin.com/bLaBbS7r [21:38:19 CET] <markusl> result (w/ all streams reporting the same bandwidth) in shaka-player: https://www.eldoradio.de/experiment/dash/ [21:39:53 CET] <markusl> (currently plays in chrome but not in ff even if shaka says ff is supported after loading the polyfills, but that's a different story) [21:43:36 CET] <sanket> i am new to contributing to opensource, can anyone help me get started for contributing to ffmpeg [22:02:36 CET] <J_Darnley> sanket: what can you do? [22:02:42 CET] <J_Darnley> or what do you want to do? [22:02:50 CET] <DHE> there's a page on the web site with info and guidelines [22:03:42 CET] <sanket> i want to contribute by coding [22:05:43 CET] <J_Darnley> You could start by reading http://ffmpeg.org/developer.html [22:05:58 CET] Action: J_Darnley notes that "coding" still isn't very specific. [22:07:03 CET] <genii> sanket: What language were you thinking to code in? [22:08:27 CET] <sanket> genii: mainly c and c++ [22:08:41 CET] <furq> can i contribute by writing perl 6 [22:10:14 CET] Action: J_Darnley chases furq away with the hose. [22:10:40 CET] <furq> are you annoyed at my bad joke or at perl 6 [22:49:35 CET] <HiddenWolf> So, I got an ffmpeg built with x265 [22:50:28 CET] <HiddenWolf> Now, Is it possible to grab a subtitle from an .idx file? [22:50:44 CET] <HiddenWolf> Preferably the right language? [22:51:06 CET] <c_14> Assuming it's tagged, yes [22:51:16 CET] <c_14> At least, I think so [22:51:27 CET] <c_14> Does ffprobe file.idx show several streams? [22:55:49 CET] <podman> If I'm trying create multiple resolutions representations for DASH. Youtube always vertical height when describing their resolutions but that seems to assume 16x9 videos. Does it make more sense to use the width instead when calculating the size? For instance if I were to upload a video that were 1280x544 to YouTube, it would describe that as 720p [22:58:00 CET] <HiddenWolf> c_14: It craps out, no such file. And the file certainly is there [22:59:28 CET] <TD-Linux> podman, well internally youtube steps up/down resolutions to utilize available bandwidth, so it doesn't really matter what exactly you pick [23:00:17 CET] <podman> TD-Linux: oh, i'm aware. I'm just trying to figure out a reasonable way to generate different resolutions [23:00:30 CET] <TD-Linux> IIRC youtube's resolution steps actually fit the video into a 16:9 box [23:00:40 CET] <HiddenWolf> c_14: http://pastebin.com/ahreXqHU [23:01:11 CET] <TD-Linux> which is a good way to do it if you're dealing with user generated content [23:01:12 CET] <podman> For instance I could use something like -vf scale=-2:720, but that would wind up with a video that is 1694x720 [23:01:35 CET] <TD-Linux> yeah I'd suggest fitting it into a box, don't know if there is a vf scale option that can do that though (there is for imagemagick) [23:02:00 CET] <podman> but, if i went with the horizontal, on the other hand, 1280x544 which makes more sense [23:02:08 CET] <podman> oh, i can do the math [23:02:30 CET] <TD-Linux> googling gives this horrific string -vf scale="'if(gt(a,4/3),320,-1)':'if(gt(a,4/3),-1,240)'" [23:02:42 CET] <podman> yeah, i already have something pretty crazy [23:02:52 CET] <podman> i guess that's assuming a 4:3 aspect ratio? [23:02:56 CET] <c_14> HiddenWolf: the idx is just an index file, the .sub contains the actual subtitles and it can't find the .sub [23:03:12 CET] <HiddenWolf> ah, drat, of course [23:03:27 CET] <podman> TD-Linux: I already have something pretty involved: scale='trunc(min(iw+mod(iw,2),#{width})/2)*2:-2' [23:05:14 CET] <podman> TD-Linux: do you happen to know what "a" is in that scale filter? Aspect? [23:05:31 CET] <TD-Linux> it must be. [23:06:18 CET] <podman> so, if the aspect greater than 4:3, use 320. otherwise -1 [23:06:19 CET] <podman> interesting [23:08:11 CET] <podman> so, an equivalent might be 'if(gt(a,16/9),1280,-2)':'if(gt(a,16/9),-2,720)' [23:08:29 CET] <podman> I'll see what that does [23:10:06 CET] Action: TD-Linux is a little bit leery of rounding errors in that [23:10:35 CET] <TD-Linux> eh should be fine. [23:10:40 CET] <podman> Yeah, I might mess around with it a bit more [23:10:47 CET] <podman> but it did seem to give me 1280x544 [23:12:52 CET] <J_Darnley> podman: yes "a" is the display aspect ratio (within the scale filter) [23:12:54 CET] <podman> seems broken for 16x9 or less though [23:12:58 CET] <podman> J_Darnley: Thanks [00:00:00 CET] --- Tue Feb 2 2016

1 0

ffmpeg-devel.log.20160131
by burek 01 Feb '16

01 Feb '16

[00:43:17 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:4b17205c7756: swscale/swscale-test: Fix slice height in random reference data creation. [00:43:19 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:9d230f4666ac: avcodec/aacenc: Check both channels for finiteness [00:43:19 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:d3cefc271daa: swscale/swscale_unscaled: Fix odd height inputs for bayer_to_rgb24_wrapper() [00:43:20 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:1a88eef93bd1: swscale/swscale_unscaled: Fix odd height inputs for bayer_to_yv12_wrapper() [00:43:22 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:edc7ef376bbe: swscale/x86/rgb2rgb_template: Fix planar2x() for short width [00:43:23 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:1b6390dd5be9: swscale/swscale: Add some sanity checks for srcSlice* parameters [00:43:23 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:eb0872335f01: avcodec/tiff: Check subsample & rps values more completely [00:43:24 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:f6755e5e19eb: avcodec/put_bits: Assert buf_ptr in flush_put_bits() [00:43:26 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:40e846bb3f8e: avcodec/gif: Fix lzw buffer size [00:43:26 CET] <cone-305> ffmpeg 03Derek Buitenhuis 07release/2.7:c6ab367dbe73: mov: Add an option to toggle dref opening [00:43:28 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:6fabd8586599: avcodec/ass_split: Fix null pointer dereference in ff_ass_style_get() [00:43:29 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:4180a83892b4: avformat/img2dec: do not interpret the filename by default if a IO context has been opened [00:43:30 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:3cd17b9b5c43: avformat/avio: Limit url option parsing to the documented cases [00:43:31 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:8c2f006d10c7: avformat/img2dec: Use AVOpenCallback [00:43:31 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:302f11e719cc: avcodec/mpeg12enc: Move high resolution thread check to before initializing threads [00:43:33 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:974f9d255d28: avcodec/wmaenc: Check ff_wma_init() for failure [00:43:34 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:874945c7b93e: avformat/avformat: Replace some references to filenames by urls [00:43:34 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:e229fbf5ce84: avcodec/mpegvideo_enc: Check for integer overflow in ff_mpv_reallocate_putbitbuffer() [00:43:36 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:965a8bda9422: avcodec/mjpegdec: Check for end for both bytes in unescaping [00:43:36 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:3c7597f2e9c9: doc/demuxers: Document enable_drefs and use_absolute_path [00:43:38 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:573a7b4c6706: avformat/concat: Check protocol prefix [00:43:39 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:197c0f618acf: avformat/libquvi: Set default demuxer and protocol limitations [00:43:40 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:41f97fe378e3: avformat: Document urls a bit [00:43:41 CET] <cone-305> ffmpeg 03Paul B Mahol 07release/2.7:d8b37664d524: avcodec/flacenc: fix calculation of bits required in case of custom sample rate [00:43:42 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:b54b8a628c8b: avutil/opt: check for and handle errors in av_opt_set_dict2() [00:43:43 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:12f256a729a8: avcodec/jpeg2000dec: More completely check cdef [00:43:44 CET] <cone-305> ffmpeg 03Michael Niedermayer 07release/2.7:bbea86d80922: Update for 2.7.6 [00:50:41 CET] <ubitux> https://github.com/Microsoft/FFmpegInterop am i late to the party? [00:51:52 CET] <wm4> the fuck is this [01:06:11 CET] <omerjerk> hahaha [01:07:34 CET] <rcombs> LAV Filters, but for the Win8 media thing? [01:09:24 CET] <wm4> apparently [04:38:40 CET] <cone-453> ffmpeg 03Michael Niedermayer 07master:6ffac5d33d33: avcodec/rawdec: Switch to monowhite if there is no palette & bpp=1 [05:14:56 CET] <Timothy_Gu> "This project is licensed from Microsoft under the Apache 2.0 License" [05:15:24 CET] <Timothy_Gu> is that even legal? [07:30:27 CET] <rcombs> Timothy_Gu: why not? [07:30:43 CET] <rcombs> (AFAIK poor phrasing is not illegal) [07:49:05 CET] <TD-Linux> it's actually quite nice because the Apache 2.0 includes a patent grant [07:49:42 CET] <TD-Linux> meanwhile, Facebook is off inventing their own broken licenses and patent terms [07:58:13 CET] <Timothy_Gu> rcombs: oh wait ffmpeg is LGPL [07:58:35 CET] <rcombs> well, mostly [07:59:27 CET] <Timothy_Gu> meanwhile, their ffmpeg copy is half a year old [08:01:28 CET] <Timothy_Gu> and no threading [08:01:47 CET] Action: Timothy_Gu goes back to lavfilters [09:29:25 CET] <nevcairiel> michaelni: the hls .m3u8 filename checks breaks opening URLs like http://www.example.org/stream.m3u8?parameter_here, which isn't that uncommon to have [11:07:21 CET] <michaelni> nevcairiel, should i revert it or search for ".m3u8?" anywhere in the string ? [11:24:23 CET] <cone-985> ffmpeg 03Paul B Mahol 07master:0c28aa6ddc88: doc/filters.texi: fix typo in spectrumsynth example [11:29:49 CET] <durandal_1707> when are API merges going to happen again? [13:01:22 CET] <cone-985> ffmpeg 03Paul B Mahol 07master:b4af7d68fe14: avcodec/fraps: remove superfluous "Fraps:" from av_log [13:05:59 CET] <wm4> 6 mats reply in succession [13:06:11 CET] <wm4> with most of its content being that he doesn't know that git revert exists [13:20:04 CET] <nevcairiel> some people should just get thrown out of the good of everyones sanity [13:20:13 CET] <nevcairiel> s/of/for7 [13:30:20 CET] <cone-985> ffmpeg 03Vittorio Giovara 07master:d74961533308: lavc: Move timecode_frame_start to codec private options [13:30:20 CET] <cone-985> ffmpeg 03Derek Buitenhuis 07master:9938697c1c11: Merge commit 'd749615333084e62c9fcc480d1ae466369fdf14f' [13:37:45 CET] <Daemon404> hmmm ubitux ping [13:38:02 CET] <Daemon404> origins of this 'feature' trace back to a commit you did with a one lien commit message [13:38:05 CET] <Daemon404> and no other info [13:38:15 CET] <Daemon404> b1ca5634fdeac3bba8edee8a89e9246e9cb5188f [13:38:17 CET] <durandal_1707> michaelni: are you going to submit ffmpeg to gsoc this year? [13:38:56 CET] <Daemon404> ah... it's for ffprobe. [13:39:33 CET] <Daemon404> ubitux, do you have any samples i can tets [13:48:21 CET] <Daemon404> lol mp3 [14:20:15 CET] <cone-985> ffmpeg 03Vittorio Giovara 07master:936f0d98f864: lavc: Move rtp_payload_size to codec private options [14:20:16 CET] <cone-985> ffmpeg 03Derek Buitenhuis 07master:899e19f1776c: Merge commit '936f0d98f864f9f6bb4f9e5458b78537e146bacd' [14:25:44 CET] <ubitux> Daemon404: ffmpeg -f lavfi -i testsrc2=d=10:r=30000/1001 -gop_timecode '01:02:03;04' test.mpg [14:25:53 CET] <ubitux> then ffmpeg -debug pict -i test.mpg -f null - [14:25:56 CET] <Daemon404> ubitux, there's a patchset on ml [14:26:00 CET] <Daemon404> if you want to look [14:29:49 CET] <cone-985> ffmpeg 03Vittorio Giovara 07master:243df1351d2d: lavc: Move {min,max}_prediction_order to codec private options [14:29:50 CET] <cone-985> ffmpeg 03Derek Buitenhuis 07master:c86ecdf3f7b0: Merge commit '243df1351d2d928caa084a5704ed783f0b83f072' [14:30:19 CET] <Daemon404> almost done these tedious API merges [14:31:40 CET] <ubitux> Daemon404: broadcasters are not going to be happy about the information going away from ffprobe [14:33:54 CET] <Daemon404> ubitux, it's not [14:33:59 CET] <Daemon404> it's in show_frames [14:34:10 CET] <Daemon404> and it was always wrong to have it global [14:34:12 CET] <Daemon404> it changes per gop [14:34:19 CET] <ubitux> does it look pretty, or does it look an int64? [14:34:31 CET] <wm4> ideally AVCodecContext would have no fields at all [14:34:43 CET] <Daemon404> ubitux, int64, however, it can be special case, if you wish [14:35:13 CET] <ubitux> yes, and probably a changelog entry if you're willing to break compat [14:35:13 CET] <Daemon404> i dont buy into the "people will be angry that is obvious wrong thing went away" argument though [14:35:16 CET] <Daemon404> ok [14:35:28 CET] <wm4> Daemon404: wrong, people will always be angr< [14:35:35 CET] <Daemon404> ;p [14:35:39 CET] <wm4> even if the thing that went away was insane [14:35:40 CET] <ubitux> well, they can be angry, so far it wasn't available anywhere else [14:35:44 CET] <wm4> and was replaced with something sane [14:36:07 CET] <ubitux> i'm not saying it's a wrong move, i'm just saying it will break compatibility instantly [14:36:38 CET] <wm4> ffprobe should have a "collect info from first frame" mode [14:36:44 CET] <wm4> which would include things like resolution [14:36:46 CET] <Daemon404> ubitux, i can leave it in ffprobe under deprecation defines [14:36:49 CET] <iive> what are you talking about? [14:36:51 CET] <wm4> instead of relying on libavformat probing it [14:36:54 CET] <ubitux> Daemon404: that would be great [14:36:59 CET] <Daemon404> then it will have teh same deprecation period as the old thing itself [14:37:10 CET] <ubitux> Daemon404: yes, please do this if you can [14:37:15 CET] <Daemon404> sure. [14:37:35 CET] <Daemon404> the next commit (2862b63783b5556f7f3fb2d097629bc6879f833a) looks like a massive pain in the butt [14:38:03 CET] <Daemon404> "This options is only used by huffyuv, ffvhuv, jpegls, mjpeg, [14:38:04 CET] <Daemon404> mpegvideoenc, png, utvideo." [14:38:15 CET] <ubitux> yeah i "laugh" at this one [14:38:31 CET] <Daemon404> ive agreed with all the avctx changes so far [14:38:35 CET] <Daemon404> this one im a bit iffy about [14:38:54 CET] <Daemon404> it'll be pain regardless. [14:39:09 CET] <ubitux> yeah it's a bit like pushing an ideology to the point where it doesn't make sense anymore :X [14:40:26 CET] <ubitux> saying "very codec specific" when it affects 7 encoders is weird, especially since probably other encoders could use it [14:40:38 CET] <ubitux> but well :) [14:41:27 CET] <Daemon404> we'll see what wm4 and nevcairiel thing [14:44:14 CET] <ubitux> Daemon404: you kept the avctx field assignment under deprecation guards too, right? [14:44:39 CET] <Daemon404> it is in v2, which i havent sent yet [14:44:46 CET] <Daemon404> it kind of has to be [14:45:50 CET] <ubitux> ffprobe -v warning -show_entries stream=timecode -of flat test.mpg [14:45:53 CET] <ubitux> if you need to test [14:46:03 CET] <ubitux> (with the sample generated with the command earlier) [14:46:10 CET] <Daemon404> ok [14:51:39 CET] <nevcairiel> Daemon404: what is codec specific about that option is its values, ie. png doesnt share a single option with the others [14:52:54 CET] <Daemon404> ah [14:52:55 CET] <Daemon404> ok [14:53:03 CET] <Daemon404> well ill merge it in a bit [14:53:09 CET] <Daemon404> its gonna be tedious [14:59:26 CET] <ubitux> Daemon404: thanks for doing this btw [15:02:15 CET] <Daemon404> this == ? [15:02:57 CET] <wm4> merging [15:03:27 CET] <Daemon404> o ok [15:06:51 CET] <Daemon404> good thing i tested [15:06:53 CET] <Daemon404> (gdb) print (*s).current_picture_ptr [15:06:53 CET] <Daemon404> $3 = (Picture *) 0x0 [15:07:03 CET] <Daemon404> hmm. [15:07:18 CET] <Daemon404> so there is no picture at the time of decoding the gop header. [15:11:05 CET] <Daemon404> ah there we go... [15:18:02 CET] <wm4> is that the new decoder? [15:18:28 CET] <nevcairiel> yes [15:18:45 CET] <wm4> that guy sure is fast [15:29:27 CET] <Daemon404> i dont know how he finds thiss tuff [15:29:52 CET] <wm4> or why? [15:33:10 CET] <nevcairiel> fuzzing isnt exactly hard =P [15:36:01 CET] <ubitux> [cfhd @ 0x4a5f420] Sample format of 259 is unsupported [15:36:03 CET] <ubitux> [cfhd @ 0x4a5f420] is not implemented. Update your FFmpeg version to the [15:36:06 CET] <ubitux> ugly formating [15:37:07 CET] <Daemon404> ubitux, new patchset sent [15:45:57 CET] <wm4> durandal_1707: so how do I tell a buffersink that it should not accept anymore frames? [15:46:09 CET] <wm4> sort of like EOF [15:46:49 CET] <wm4> normal filters apparently can do it by having av_buffersrc_add_frame() return AVERROR_EOF [16:30:12 CET] <durandal_1707> wm4: IIRC no way [16:46:57 CET] <nevcairiel> Daemon404: did you break fate [16:47:11 CET] <Daemon404> not afaik... [16:47:19 CET] <nevcairiel> lavf-ffm is not happy [16:48:08 CET] <Daemon404> ... the only stuff i merged was soem avctx field stuff for mpeg timecodes and rtp payload [16:48:15 CET] <Daemon404> and pred order [16:48:22 CET] <Daemon404> wtf would ffm need with that [16:48:38 CET] <nevcairiel> some metadata that it lost along the way? [16:48:49 CET] <wm4> unintended interaction with features you never heard of! [16:49:49 CET] <nevcairiel> it uses mpeg1 encoding i think [16:50:11 CET] <Daemon404> ... and why would only ffm be hit [16:50:25 CET] <nevcairiel> those commits like to "lose" default parameters sometiems =p [16:51:00 CET] <Daemon404> let's see.. [16:52:17 CET] <Daemon404> i think i see it [16:52:21 CET] <wm4> durandal_1707: is there a filter that always send EOF? [16:52:23 CET] <Daemon404> and here i thought i caught them all [16:52:26 CET] <Daemon404> since i fixed liek 4 of them [16:52:27 CET] <Daemon404> -_- [16:53:11 CET] <Daemon404> nevcairiel, it's veyr bizzarre that only ffm would be hit though [16:53:15 CET] <Daemon404> and you know [16:53:18 CET] <Daemon404> not mpeg1 tests [16:53:30 CET] <Daemon404> which i rnas [16:53:33 CET] <Daemon404> ran* [16:53:35 CET] <nevcairiel> ffm uses a crc of the output file, maybe the others test differently [16:53:43 CET] <nevcairiel> personally i tend to run full fate =p [16:53:50 CET] <Daemon404> i think the ps option changed from DEFAULT to 0 [16:53:54 CET] <Daemon404> assumign DEFAULT is not 0 [16:54:11 CET] <Daemon404> running a ufll fate for every single commit seems utterly insane to me [16:54:14 CET] <Daemon404> :/ [16:54:38 CET] <Daemon404> 90% of these are broken in libav too, but they dont have tests [16:54:39 CET] <Daemon404> quality. [16:54:52 CET] <nevcairiel> i warned you about koda refactoring [16:55:05 CET] <Daemon404> [15:52] <@Daemon404> and here i thought i caught them all [16:55:05 CET] <Daemon404> [15:52] <@Daemon404> since i fixed liek 4 of them [16:55:05 CET] <Daemon404> [15:52] <@Daemon404> -_- [16:57:37 CET] <Daemon404> no that wasnt it [16:57:39 CET] <durandal_1707> wm4: nope [16:58:21 CET] <Daemon404> nevcairiel, how new is this breakage [16:58:24 CET] <wm4> man I have no idea how not to stall this damn libavfilter thing if one stream just has n input [16:58:24 CET] <wm4> *no [16:58:43 CET] <durandal_1707> what changed in ffm output? [16:59:10 CET] <Daemon404> trying to figure that out [16:59:52 CET] <durandal_1707> wm4: sources?, ah you receive unlimited frames? :) [17:00:33 CET] <nevcairiel> Daemon404: ffm is literally evil [17:00:44 CET] <nevcairiel> it encodes codec configuration [17:00:54 CET] <nevcairiel> including timecode_frame_start=0 [17:00:58 CET] <nevcairiel> which vanishes now =p [17:01:01 CET] <nevcairiel> not sure why it does [17:01:03 CET] <nevcairiel> but it does [17:01:57 CET] <nevcairiel> ah because 0 was not the default [17:02:06 CET] <Daemon404> what the fuck? [17:02:11 CET] <nevcairiel> -1 is the default [17:02:18 CET] <Daemon404> -1 should still be default [17:02:26 CET] <Daemon404> i made sure it was the same [17:02:38 CET] <nevcairiel> the point is, the mpeg1encoder changed the value in the context to 0 [17:02:47 CET] <nevcairiel> so it was no longer equal to the default [17:02:51 CET] <nevcairiel> so it got written to the file [17:03:30 CET] <Daemon404> something isnt right then [17:03:34 CET] <Daemon404> it shouldnt change it [17:03:58 CET] <nevcairiel> cant fix previous versions of the code [17:03:59 CET] <Daemon404> behvior looks the same.. [17:04:00 CET] <nevcairiel> it did [17:04:07 CET] <Daemon404> ah [17:04:09 CET] <Daemon404> i see it... [17:04:10 CET] <Daemon404> i think? [17:04:19 CET] <Daemon404> } else { [17:04:19 CET] <Daemon404> - s->avctx->timecode_frame_start = 0; // default is -1 [17:04:19 CET] <Daemon404> + s->timecode_frame_start = 0; // default is -1 [17:04:20 CET] <Daemon404> } [17:04:25 CET] <Daemon404> but this would mean it was always 0 [17:04:36 CET] <Daemon404> and now it isnt [17:05:28 CET] <Daemon404> oh it vanishes because it *wasnt* default before... classy [17:05:37 CET] <nevcairiel> in any case, you can just push an update to fate with the new ref [17:05:43 CET] <nevcairiel> thats the only difference in the file [17:05:52 CET] <Daemon404> yes [17:06:00 CET] <Daemon404> it sitll boggles my mind why ffms would do that [17:06:16 CET] <nevcairiel> no idea, its ffserver crap, who knows why it does anything [17:06:28 CET] <JEEB> iä iä ffserver the usual [17:06:29 CET] <nevcairiel> its not too crazy of an idea to write out all options that are non-default, i guess [17:07:33 CET] <Daemon404> [15:48] <+wm4> unintended interaction with features you never heard of! [17:07:35 CET] <Daemon404> ^ [17:07:54 CET] <cone-985> ffmpeg 03Derek Buitenhuis 07master:b552f3afa2a7: fate/ffm: Update test ref [17:08:16 CET] <Daemon404> why is this PAL8 trhead so long [17:08:27 CET] <Daemon404> i get a mail ever few minutes in it [17:08:31 CET] <Daemon404> and all of it is noise [17:08:35 CET] <nevcairiel> because that mats guy posts 10 mails instead of thinking more than 10ms [17:10:21 CET] <durandal_1707> consider marking his mails as spam [17:12:37 CET] <Daemon404> im very close to the end of this wave of refactorings... i can see the light [17:12:41 CET] <Daemon404> should be smoother after [17:14:15 CET] <cone-985> ffmpeg 03foo86 07master:46089967722f: avcodec/dca: remove old decoder [17:14:16 CET] <cone-985> ffmpeg 03foo86 07master:64f6d17b405b: avcodec/dca: add REV1AUX sync word [17:14:17 CET] <cone-985> ffmpeg 03foo86 07master:9a0a3bbeaaf4: avcodec/dca: add more tables [17:14:18 CET] <cone-985> ffmpeg 03foo86 07master:4a53b83691ac: avcodec/dca: add math helpers and fixed point DCT [17:14:19 CET] <cone-985> ffmpeg 03foo86 07master:8984806a510b: avcodec/synth_filter: fix whitespace [17:14:20 CET] <cone-985> ffmpeg 03foo86 07master:5b1b536e2b7c: avcodec/synth_filter: add more filters [17:14:21 CET] <cone-985> ffmpeg 03foo86 07master:0930b2dd1f01: avcodec/dca: add generic defines [17:14:22 CET] <cone-985> ffmpeg 03foo86 07master:ae5b2c52501d: avcodec/dca: add new decoder based on libdcadec [17:14:35 CET] <nevcairiel> (in before someone whines about lack of real names) [17:14:53 CET] <Daemon404> some guy name popcorn is getting pushed soon... so.. [17:14:58 CET] <Daemon404> named* [17:15:06 CET] <nevcairiel> some people still keep whining [17:15:14 CET] <JEEB> nice [17:15:19 CET] <Daemon404> i think it's crappy myself, too [17:15:23 CET] <Daemon404> but i have 0 power here, so. [17:15:39 CET] <JEEB> (nice@the new dcadec [17:18:16 CET] <wm4> Daemon404: at least that guy is relatively well known in the rpi and xbmc community [17:20:54 CET] <kierank> J_Darnley: so h264 patch, is it pushable? [17:21:42 CET] <J_Darnley> Oh shit. Thanks for the reminder [17:21:59 CET] <J_Darnley> I made a couple of changes so I should probably post the list again. [17:22:10 CET] <fritsch> that popcorn guy is one of the rpi founders :-) [17:22:44 CET] <fritsch> writing the rpi firmware and kodi [17:56:42 CET] <JEEB> hmm, did this work before? https://gist.github.com/andrey-utkin/c6fb55bb3e13faf82fbe [18:01:58 CET] <Daemon404> it looks like it should [18:02:28 CET] <JEEB> well with current libx264 defaults that shouldn't happen [18:02:48 CET] <JEEB> that stuff is for the default that got overridden in like 2011 or so [18:02:55 CET] <JEEB> also someone says it used to work in 2.8.x [18:03:38 CET] <Daemon404> wait.. what is being run here [18:03:45 CET] <Daemon404> the cli or the transcoding example [18:03:58 CET] <JEEB> both, ffmpeg is for creation of the input [18:04:07 CET] <Daemon404> which one is erring then [18:04:09 CET] <JEEB> and then the transcoding example is used for the crap done afterwards [18:04:15 CET] <JEEB> the transcoding example [18:04:25 CET] <Daemon404> then i have no idea. [18:04:47 CET] <JEEB> it's as if avcodec's libx264 defaults just went back a few years [18:05:53 CET] <Daemon404> i cant tell WHAT is wrong [18:05:59 CET] <Daemon404> the error message is the most useless thing ever [18:07:02 CET] <JEEB> IIRC libx264 checks against (at least some) params that FFmpeg used to set up until 2011 or so [18:07:10 CET] <JEEB> back when all encoders had the same defaults [18:07:40 CET] <Daemon404> well ffmpeg cli would fail rtoo if defaults were the problem. [18:08:11 CET] <JEEB> well ffmpeg cli can be a special snowflake. could just be an error in the example [18:08:18 CET] <JEEB> which was brought up by something that came up lately [18:09:52 CET] <BBB> ffmpeg cli is a snowflake for sure [18:11:01 CET] <Daemon404> looking at the x264 code theres no way it shoild trip that [18:11:16 CET] <Daemon404> can you repro it? [18:11:34 CET] <JEEB> I'll try after I've finished my chinese cartoons for the day [18:11:58 CET] <JEEB> and yes, in any usual case you wouldn't be tripping that thing [18:24:24 CET] <durandal_1707> I get red text when encoding flac [18:27:39 CET] <jkqxz> wm4: I was trying to conform to the documented convention that the argument to av_log() is a "pointer to an arbitrary struct of which the first field is a pointer to an AVC lass struct" (where the arbitrary struct is context-meaningful). Once that is discarded then whatever, it's just a const AVClass**. [18:28:18 CET] <jkqxz> And AVVAAPIHardwareContext is deliberately compatible with (that is, usable as) struct vaapi_context, with extra fields at the end. [18:28:33 CET] <nevcairiel> should really use NULL instead of inventing a new context [18:28:55 CET] <wm4> jkqxz: then maybe it shouldn't do that [18:29:04 CET] <wm4> make vaapi_context a simple field [18:29:55 CET] <jkqxz> Then you lose the backward-compatibility with existing users of the VAAPI decoders. [18:32:26 CET] <wm4> jkqxz: no, it just means you can't use the pointers interchangeably [18:35:59 CET] <durandal_1707> Daemon404: try encode flac, red text appear [18:36:28 CET] <wm4> red text is a feature [18:36:33 CET] <wm4> it looks cooler [18:44:31 CET] <jkqxz> wm4: How do you do the later upgrade to add correct locking to the decoders, in that case? [18:44:34 CET] <J_Darnley> Red text? Error messages (or worse)? [18:45:12 CET] <wm4> jkqxz: there needs to be a second context pointer in the codeccontext I guess [18:45:23 CET] <jkqxz> Without the structure compatibility everything has to change simultaneously. [18:46:35 CET] <Daemon404> J_Darnley, if it was an error, fate would fail. [18:46:37 CET] <Daemon404> it doesn't. [18:46:44 CET] <jkqxz> Oh, hwaccel_context2 in AVCodecContext? I guess that also works. [18:49:35 CET] <wm4> jkqxz: maybe we should wait for that Libav patch? it also adds a new context [18:49:37 CET] <durandal_1707> gonna fix it? [18:50:15 CET] <J_Darnley> What? There's no atestsrc? [18:52:06 CET] <wm4> there are some simple sources [18:52:31 CET] <Daemon404> i can only move so fast, while all i hear is https://www.youtube.com/watch?v=1Isjgc0oX0s [18:52:36 CET] <J_Darnley> Oh I was looking in the wrong section of the list. [18:57:35 CET] <durandal_1707> Daemon404: LOL [19:01:05 CET] <Daemon404> trying to figure out wtf happened [19:01:16 CET] <Daemon404> slowed down by builds. [19:01:46 CET] <wm4> jkqxz: so how does your patch distinguish a sole vaapi_context, and one embedded in a hw ctx? [19:05:16 CET] <jkqxz> I was hoping that a delay for users to transition would be sufficient to avoid the problem (deprecate user-instantiated struct vaapi_context, wait). If they have to exist simultaneously then some magic numbers set by the allocation function could be added. [19:07:34 CET] <wm4> so you have this problem either way [19:10:36 CET] <Daemon404> as yes of course [19:10:44 CET] <Daemon404> it was of course broken in libav and fixed later [19:10:47 CET] <Daemon404> of course. [19:10:56 CET] <Daemon404> every damn commit has to be broken [19:10:57 CET] <Daemon404> and fixed later [19:11:48 CET] <wm4> seems like the reviews on the Libav side are pretty worthless, despite being strict [19:11:58 CET] Action: JEEB pats Daemon404 [19:14:33 CET] <jkqxz> wm4: Ok. The backward compatibility is not relevant to me, so I am happy to change to do what you say. [19:15:11 CET] <wm4> my main problem here is that the planned change in Libav will change everything again [19:16:34 CET] <Daemon404> oh my bad [19:16:38 CET] <Daemon404> it's *still* broken in avconv. [19:26:51 CET] <cone-985> ffmpeg 03Derek Buitenhuis 07master:e9eb8b3ba253: flacenc: Restore defaults and range for {min,max}_prediction_order [19:26:54 CET] <Daemon404> durandal_1707, ^ [19:26:56 CET] <Daemon404> sigh [19:27:08 CET] <Daemon404> he made the default value out of range [19:38:57 CET] <nevcairiel> i complained about that patch a couple times and he still didnt get it right [19:38:58 CET] <nevcairiel> oh well [20:14:59 CET] <cone-985> ffmpeg 03Michael Niedermayer 07master:3c8e95ab5da5: avcodec/flacenc: Fix prediction_order parameter [20:22:48 CET] <Daemon404> michaelni, can you expland on 3c8e95ab5da5a1e5ada0379020911d99efe48534 a bit [20:23:06 CET] <Daemon404> -1 was the default in the past [20:23:39 CET] <Daemon404> and that bit wasnt touched [20:23:59 CET] <michaelni> yes, -1 or when the user explicityl set a value then that value, the code then overwrites either before my commit [20:24:29 CET] <Timothy_Gu> ubitux: http://coverage.ffmpeg.org/ seems to be down [20:24:39 CET] <michaelni> previously the users value was in avcodec context so wasnt overwritten [20:26:51 CET] <Daemon404> staring a bit longer... urg [21:50:46 CET] <wm4> kierank: you did see these, right? ^ [21:51:22 CET] <durandal_1707> he is drinking, leave him alone [22:15:31 CET] <cone-985> ffmpeg 03Henrik Gramner 07master:58313f2dda0a: msvc: Fix libx264 linking [22:18:37 CET] <cone-985> ffmpeg 03Paul B Mahol 07master:4ab4793c155e: avfilter/avf_showfreqs: properly handle pts [22:25:31 CET] <kierank> wm4: on the train [22:25:34 CET] <kierank> can only look now [22:26:25 CET] <wm4> just so that you don't miss it [23:02:23 CET] <jya> is there an official schedule on the next official release ? [23:06:46 CET] <JEEB> jya: nope [23:07:18 CET] <JEEB> releases are something somewhat random since they're generally only made for distros and such that seem to require a "release" [23:19:28 CET] <jya> JEEB: Firefox 46 will be using the current master. but I would have much preferred to follow a "2.9" or something [23:20:04 CET] <jya> Ubuntu 16.04 freeze is soon too. [23:20:17 CET] <jamrial> 2.9 is supposedly going to be made soon [23:20:36 CET] <jya> so it will ship with 2.8 unless things are released soon [23:20:42 CET] <JEEB> would make sense as we got the AAC encoder and dcadec replacement in [23:20:44 CET] <jya> jamrial: good to know [23:21:09 CET] <jya> (stable release make cherry-picking changes much easier) [23:34:22 CET] <durandal_170> it should be 3.0 [23:39:13 CET] <Compn> it should be versioning based on dates, otherwise we are going to be at ffmpeg 40 in a year or three :P [23:39:23 CET] Action: Compn runs [23:41:19 CET] <nevcairiel> Compn: everyone does that these days, so why not [23:50:44 CET] <jya> what's wrong with version 40 ? [23:51:08 CET] <Compn> whats wrong with version $date ? [23:51:23 CET] <jya> date format of which country ? :) [23:52:40 CET] <iive> there are other countries? [23:52:48 CET] <nevcairiel> version inflation in many projects seems kinda silly, especially when some things just seem to do it to follow a trend, ie. chrome started it, firefox had to follow =p [23:57:56 CET] <nevcairiel> these days even gcc does it [23:59:46 CET] <Timothy_Gu> jamrial: I wanted to use the native-sized regs for everything but then I saw the gcc disass used this mixture of reg sizes [00:00:00 CET] --- Mon Feb 1 2016

1 0

ffmpeg.log.20160131
by burek 01 Feb '16

01 Feb '16

[10:45:36 CET] <BlackBishop> any easy way to get one.mkv to two.mkv with same resolution but lower a/v bitrate ? [10:48:58 CET] <BlackBishop> ( even keeping the codec ) [10:55:22 CET] <BlackBishop> ffmpeg -i sone.mkv -b:v 2048k ~/stwo.mkv would be enough ? [10:56:23 CET] <BlackBishop> hmmm .. and -preset ultrafast [14:03:47 CET] Action: cousin_luigi would like to concatenate and reencode to h265 two files of a different resolution: what is the best way to do so? [14:42:16 CET] <waressearcher2> cousin_luigi: ffmpeg -i file1.mp4 -i file2.mp4 -filter_complex '[0:0] [0:1] [1:0] [1:1] concat=n=2:v=1:a=1 [v] [a]' -map '[v]' -map '[a]' -vcodec h264 -vb 2000k -vf scale=1280:720 -ab 128k -ar 44100 -ac 2 -acodec libmp3lame -y -f mp4 out.mp4 [14:43:42 CET] <cousin_luigi> waressearcher2: Won't that reencode to x264? [14:43:46 CET] <cousin_luigi> But thanks. [14:45:27 CET] <waressearcher2> cousin_luigi: ffmpeg -i file1.mp4 -i file2.mp4 -filter_complex '[0:0] [0:1] [1:0] [1:1] concat=n=2:v=1:a=1 [v] [a]' -map '[v]' -map '[a]' -vcodec h265 -vb 2000k -vf scale=1280:720 -ab 128k -ar 44100 -ac 2 -acodec libmp3lame -y -f mp4 out.mp4 ? [14:46:04 CET] <cousin_luigi> Looks good. Thanks! [14:46:06 CET] <cousin_luigi> bbl [14:48:34 CET] <tp_> what technology is used for DTS hardware acceleration? i have an old Intel Q9400 CPU which is terrible for DTS decoding [16:24:56 CET] <kepstin> hmm? DTS should decode fast enough that you don't even notice it on that processor [16:25:51 CET] <kepstin> if you don't want to decode it on the cpu, you need an external decoder (e.g. a stereo receiver) that can take a dts bitstream over hdmi or spdif. [16:27:24 CET] <tp_> i do, i need to transcode it, but a Q9400 is too slow for DTS [16:31:12 CET] <kepstin> oh, you're encoding to dts? [16:31:33 CET] <kepstin> or.. no, doesn't seem like it [16:31:48 CET] <kepstin> it's *probably* something other than dts decoding that's slow for you [16:39:43 CET] <tp_> im decoding DTS, and thats really slow on a Q9400 :/ [16:40:33 CET] <tp_> DTS>AAC is slow, but AC3>AAC is fast enough [17:10:09 CET] <chungy> how slow are you talking? [17:10:28 CET] <chungy> the encoder doesn't care what the input codec was [17:10:44 CET] <chungy> Q9400 is a Core 2 isn't it? That should be plenty for DTS. [17:18:53 CET] <dystopia> how can i download video from m3u8 files with the latest ffmpeg builds from zeranoe? [17:19:06 CET] <dystopia> the commands that worked before faile in the latest builds [17:19:48 CET] <J_Darnley> Failed with what message? [17:20:07 CET] <J_Darnley> And ffmpeg is not really a tool for *downloading* files. [17:20:34 CET] <dystopia> ffmpeg -i %m3u8link% -cookies %cookie% -vcodec copy download.mp4 [17:20:43 CET] <dystopia> well this worked for years, now it doesent heh [17:21:04 CET] <dystopia> only thing ffmpeg says now is "data found processing input" [17:21:07 CET] <J_Darnley> (For some definition of "work") [17:21:16 CET] <dystopia> http://i.imgur.com/v9Opwwn.png [17:21:47 CET] <dystopia> well i downloaded with ffmpeg then encoded them again with ffmpeg to x264 [17:22:48 CET] <chungy> they're already H.264 it seems [17:22:56 CET] <dystopia> yeah they are [17:23:22 CET] <chungy> Try putting -cookies before the input? [17:23:34 CET] <dystopia> ok [17:23:41 CET] <dystopia> will give it a shot [17:49:51 CET] <andrey_utkin> could anybody please remind/explain why x264 complains for "broken settings" with ./doc/examples/transcoding? https://gist.github.com/andrey-utkin/c6fb55bb3e13faf82fbe [17:50:00 CET] <andrey_utkin> what special ffmpeg cli util does to avoid this? [17:50:46 CET] <Mavrik> Just how old is your ffmpeg?? [17:51:16 CET] <andrey_utkin> current git master HEAD [17:53:31 CET] <JEEB> interesting, that check definitely shouldn't be hit by default, it was meant for the defaults that got changed around 2011 [17:53:42 CET] <JEEB> andrey_utkin: how old is your x264? [17:54:44 CET] <JEEB> oh wait, examples [17:54:49 CET] <JEEB> I wonder... [17:56:25 CET] <JEEB> andrey_utkin: can you please iterate until you get it back to working with git bisect or so? :) [17:56:31 CET] <JEEB> meanwhile I'll poke -devel [17:58:34 CET] <andrey_utkin> x264 is something 148, hard to say - the package is x264-9999 :) https://gist.github.com/andrey-utkin/46757f7499eba4036336 [17:59:01 CET] <andrey_utkin> JEEB: ok [18:00:48 CET] <andrey_utkin> sorry, seems ffmpeg used that time is 2.8.5, but still this is recent [18:01:45 CET] <JEEB> 2.8.x was branched quite a bit of time ago [18:02:13 CET] <andrey_utkin> rebuilding git master HEAD now just to be sure [18:26:55 CET] <andrey_utkin> now with proper local rebuild with --enable-shared the situation is different: https://gist.github.com/andrey-utkin/d92df8e767dc853457b1 [18:27:50 CET] <andrey_utkin> AVCodec ff_libx264_encoder doesn't have pix_fmts[] set... [18:29:06 CET] <andrey_utkin> should we add it (back)? [18:29:35 CET] <JEEB> please try with a standard configure without any params [18:29:45 CET] <andrey_utkin> ok [18:29:49 CET] <JEEB> which is a static libs+binary [18:30:16 CET] <andrey_utkin> JEEB: this way examples get linked with system-provided libs, which are in my case 2.8.5 [18:30:27 CET] <JEEB> uhh [18:30:37 CET] <JEEB> don't mish-mash FFmpeg libraries :P [18:30:45 CET] <andrey_utkin> i'm used to that [18:30:54 CET] <JEEB> it would use mpeg-4 part 2 encoder for the mkv file I think. if that works, then --enable-gpl --enable-libx264 [18:31:06 CET] <JEEB> you might be used to it but it might bring out random weirdness as well :P [18:31:43 CET] <andrey_utkin> JEEB: please look at my last paste, no encoders are involved except libx264 [18:32:02 CET] <JEEB> yes, but with a default no-configure-params build you won't have libx264 [18:32:17 CET] <JEEB> first you try with a standard LGPL build, then enable-gpl and enable-libx264 [18:32:21 CET] <JEEB> :P [18:32:26 CET] <andrey_utkin> and I have already determined that the issue is that AVCodec definition doesn't have .pix_fmts part, so it remains NULL in contrary to many other codecs [18:33:02 CET] <andrey_utkin> is there some API function to get codec's preferred pix_fmt? or should we bring back that definition? [18:33:11 CET] <andrey_utkin> JEEB: i have enable-gpl in my configure [18:33:19 CET] <JEEB> you definitely seem to not be listening [18:33:20 CET] <JEEB> fine [18:33:35 CET] <andrey_utkin> i can expose to you the fullest track of what i am doing [18:33:44 CET] <andrey_utkin> JEEB: you seem the same to me :) [18:34:22 CET] <JEEB> after you said that you have mish-mashed FFmpeg libraries it is a top priority that you can replicate things with a standard static build [18:34:50 CET] <JEEB> because otherwise whatever is happening to you can be random and/or not really an issue. I cannot be sure, but I must limit the issue to whatever it is [18:35:11 CET] <JEEB> which is why I asked you to try with a standard FFmpeg build + that example built [18:35:13 CET] <andrey_utkin> well fine, going to create a sandbox to avoid disruption of my system [18:35:18 CET] <JEEB> why!? [18:35:25 CET] <JEEB> I mean, you have the code, right [18:35:33 CET] <andrey_utkin> so? [18:35:38 CET] <andrey_utkin> so what? [18:35:40 CET] <JEEB> then you mkdir build && ../configure && make -jN [18:35:47 CET] <JEEB> that will not affect your system in any way or form [18:35:48 CET] <andrey_utkin> && make install [18:35:55 CET] <JEEB> why would you install something you're just testing!? [18:36:00 CET] <JEEB> it's static, too [18:36:13 CET] <JEEB> you might use a custom prefix if the example requires a proper dir structure [18:36:15 CET] <JEEB> (--prefix) [18:36:23 CET] <JEEB> and then just point the example building to it [18:36:23 CET] <andrey_utkin> because when examples are built, they have just -lstuff, no -L as far as i have seen [18:36:37 CET] <andrey_utkin> so it gets linked with system-wide installed libs [18:36:41 CET] <andrey_utkin> as i have said previously [18:36:56 CET] <JEEB> well I see you already know how to do LDFLAGS (if those work) [18:37:12 CET] <JEEB> just use a custom prefix if you really need to, no need to affect your whole system or setup complex chroots or anything [18:37:31 CET] <JEEB> --prefix=/home/my_username/muh_ffmpeg or whatever [18:38:24 CET] <andrey_utkin> JEEB: please look at doc/examples/Makefile and figure out that it uses system-wide installed libs and doesn't try to use ones from local sources tree [18:39:05 CET] <JEEB> ok, it uses pkg-config. evne better [18:39:19 CET] <JEEB> PKG_CONFIG_PATH=/home/my_username/muh_ffmpeg/lib/pkgconfig [18:39:29 CET] <JEEB> before you run the makefile [18:39:42 CET] <JEEB> https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/Makefile#L11 [18:40:18 CET] <andrey_utkin> that's right, i just explained that install phase is required [18:40:34 CET] <JEEB> yes, and I have been saying that you can use a custom prefix for quite a while [18:40:48 CET] <JEEB> 19:37 < JEEB> you might use a custom prefix if the example requires a proper dir structure [18:40:51 CET] <JEEB> 19:37 < JEEB> (--prefix) [18:40:52 CET] <JEEB> and then [18:40:57 CET] <JEEB> 19:38 < JEEB> just use a custom prefix if you really need to, no need to affect your whole system or setup complex chroots or anything [18:41:00 CET] <JEEB> 19:38 < JEEB> --prefix=/home/my_username/muh_ffmpeg or whatever [18:41:01 CET] <andrey_utkin> no, you've been saying "why would you install something you're just testing!?" first [18:41:18 CET] <JEEB> yes, I said that first because I wasn't sure at that point since I've never built the damn examples [18:41:36 CET] <JEEB> but in any case, prefix can be set and as I said, that will not affect your goddman installed pakcages in any way or form [18:42:15 CET] <JEEB> so can we just get this tested with? unless you're just picking me off on purpose to make me do the testing [18:43:05 CET] <andrey_utkin> JEEB: i'll test it [18:43:32 CET] <JEEB> I just want to make sure that whatever issue you're having also happens with a standard build without any of your "lol I mixed stuff and it doesn't work" shenanigans [18:44:09 CET] <JEEB> first without libx264 (enable-gpl and enable-libx264, just an empty configure with the prefix) [18:44:20 CET] <JEEB> and then with enable-gpl and enable-libx264 that adds libx264 there [18:45:29 CET] <JEEB> and then if both of those work it's a more limited issue related to whatever you've been doing [19:52:34 CET] <tp_> chungy: less than 30 fps encoding, and 100% cpu load while doing it, and yes, its a core 2 quad [19:59:51 CET] <chungy> tp_: encoding isn't decoding, like you were talking about [20:00:17 CET] <chungy> and fps doesn't really make sense in the context of audio... heh. [20:05:44 CET] <kepstin> tp_: I assume you're doing audio-only encoding (e.g. an audio only source, with -vn to disable video, or -c:v copy)? [20:29:58 CET] <tp_> well, audio needs to be decoded before it can be encoded i guess [20:30:03 CET] <tp_> its with video copying, and it works fine with AC3>AAC [20:32:08 CET] <tp_> it will take longer to transcode a DTS stream than listening to it [20:36:42 CET] <tp_> i dont find anywhere where i said encoding is decoding tho [22:08:14 CET] <spookypeanut> for those that were here for me talking about retiming dvd subtitles last night, I have a plan [22:08:48 CET] <spookypeanut> i am going to use the info on this page: http://archive09.linux.com/feature/125978 [22:09:05 CET] <spookypeanut> all command line ways to rip, just only from vob [22:09:37 CET] <spookypeanut> then it ocrs to an srt, so i'll write a tiny python script to retime that [22:09:44 CET] <spookypeanut> thanks for al the suggestions! [23:29:09 CET] <solrize> hi guys i sometimes have to convert a big mp4 file to webm preferably without having to wait too long. i have a 4-core computer, is it reasonable to split the input file into 4 pieces, convert in parallel, then recombine? [23:31:38 CET] <Mavrik> Nope. [23:32:02 CET] <Mavrik> VP9 encoder should be able to use all four cores. [23:32:11 CET] <Mavrik> Which makes splitting files just a waste of time. [23:39:43 CET] <J_Darnley> how old fashioned [23:39:56 CET] <J_Darnley> I feel a /. joke coming. [23:41:01 CET] <Mavrik> O.o [23:41:02 CET] <durandal_170> buy better CPU, or do smthg else [23:42:40 CET] <drv> does ffmpeg run on beowulf clusters? :) [00:00:00 CET] --- Mon Feb 1 2016

1 0