Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

January 2014

1 participants
62 discussions

ffmpeg-devel.log.20140130
by burek 31 Jan '14

31 Jan '14

[00:01] <cone-4> ffmpeg.git 03Diego Biurrun 07master:d67cfdeb5303: avformat: utils: Refactor duplicated PRINT macro [00:01] <cone-4> ffmpeg.git 03Michael Niedermayer 07master:72afa381b3fa: Merge remote-tracking branch 'qatar/master' [00:38] <BBB> ubitux: wdyt of working on a hevc encoder next? [00:39] <smarter> you want to write an encoder? :) [00:39] <BBB> dunno [00:39] <BBB> looking for a new project after ffvp9 is "done" [00:39] <smarter> https://github.com/ultravideo/kvazaar seems to have appeared from the void today [00:39] <smarter> it's C89 [00:40] <BBB> I read about that today [00:40] <BBB> could also do hevc decoder but smarter already did most of that with his openhevc buddies so nothing much left to do there [00:41] <smarter> are you going to write 32 bits asm for ffvp9? [00:51] <cone-4> ffmpeg.git 03Kirill Gavrilov 07master:e9e7e685166e: mjpegdec: parse JPS extension and save relevant stereo3d information [00:51] <cone-4> ffmpeg.git 03Michael Niedermayer 07master:ed56c021e728: avcodec/mjpegdec Fix potential memleak of stereo3D at the end in case of decoding failure [00:51] <cone-4> ffmpeg.git 03Michael Niedermayer 07master:b80073c05f7c: avcodec/mjpegdec: use av_freep() instead of av_free() [00:56] <iive> I'm hearing some things about h265 encoder that make me worry if it would ever be such success as h264. [00:57] <smarter> well, how long did it take for h264 to become a success? :) [00:57] <iive> sorry, x265 and x264 [00:57] <iive> talking about the project(s) not standard. [01:12] <BBB> smarter: no, 32bit should die [01:13] <BBB> smarter: if someone wants to pay for it, sure - if someone else wants to do it, sure [01:13] <BBB> but I have no use for it [01:13] <smarter> I see :) [01:20] <smarter> BBB: if you're bored you could investigate intra pred asm for hevc, no one has worked on that yet [01:21] <kierank> smarter: x265 have [01:21] <kierank> with crazy macros [01:21] <smarter> yeah, that's expected [01:22] <smarter> writing code every angular mode by hand wouldn't be very fun [01:22] <smarter> *for every [01:23] <kierank> theirs is intrinsics i think [01:23] <smarter> though I'm wondering if the advantages of having one function for each angular mode offsets the increase in code size [01:29] <cone-4> ffmpeg.git 03Carl Eugen Hoyos 07master:cfc36666f681: Force automatic thread_count to 1 for cbr mjpeg frame threading. [01:29] <cone-4> ffmpeg.git 03Michael Niedermayer 07master:1a5e8511d4ed: Merge remote-tracking branch 'cehoyos/master' [01:35] <BBB> smarter: try it :) [01:36] <smarter> I may at some point :) [01:37] <smarter> my intuition tells me that putting pressure on the instruction cache is not a big deal compared to lots of mispredicted branches [01:37] <BBB> and that omits the whole scalar vs vector advantage [01:41] <BBB> maybe I should do daala [01:41] <BBB> anyway, we'll see [01:41] <BBB> first finish ffvp9 [02:14] <cone-4> ffmpeg.git 03Carl Eugen Hoyos 07master:e1cb6dc59ec2: Warn the user if mjpeg cbr encoding with frame threading was requested. [07:52] <ubitux> BBB: not interested [07:54] <ubitux> (hevc encoder) [10:00] <anshul> I was looking in decoder how he is supporting planar, but I found that there they support FLTP and FLT, but then how come they are giving S16P at output? file:libavcodec/mpegaudiodec_float.c [10:01] <ubitux> no match for S16 here [10:01] <j-b> 'morning [10:03] <anshul> ubitux, because of same thing , that there is nomatch for S16, but mp2 decoder decode well for S16 how? [10:04] <ubitux> because _fixed is selected? [10:05] <anshul> ohhk [12:16] <cone-918> ffmpeg.git 03Carl Eugen Hoyos 07master:3f35a31ee956: Add rangecoder to the sonic dependencies in configure. [13:06] <BBB> ubitux: k - and how's 44/48/84_16 lf? :-p [13:07] <ubitux> BBB: a bit difficult during the week [13:07] <BBB> lol work :) [13:07] <BBB> yeah i know [13:07] <ubitux> not only work :p [13:07] <BBB> i get like 1 maybe 2 grs a day [13:07] <BBB> g=h [13:08] <BBB> and right now I'm chatting with baby on my lap [13:12] <ubitux> i have around the same amount a day [13:13] <ubitux> but generally between 22 and 24, i pretty much want to slack off [15:07] <cone-918> ffmpeg.git 03John Stebbins 07master:23d461fe8714: ac3dec: Allow asymmetric application of DRC when drc_scale > 1 [15:07] <cone-918> ffmpeg.git 03Michael Niedermayer 07master:3c7195a96933: Merge commit '23d461fe8714a20ee5e6929f22c61512fdda568e' [16:00] <cone-918> ffmpeg.git 03John Stebbins 07master:a17ab0e46a9f: doc: add decoders.texi [16:00] <cone-918> ffmpeg.git 03Michael Niedermayer 07master:d85284d4aa7d: Merge commit 'a17ab0e46a9fec7c31cc1be363828184c6ecebf7' [16:12] <Daemon404> G 43 [16:21] <ubitux> BBB: just got 84 working [16:22] <ubitux> i might submit that tonight [16:27] <cone-918> ffmpeg.git 03John Stebbins 07master:64ba831da99c: doc: document correct option to list encoders [16:27] <cone-918> ffmpeg.git 03Michael Niedermayer 07master:6dc9d2cf4741: Merge remote-tracking branch 'qatar/master' [16:41] <ubitux> ff_vp9_loop_filter_h_{48,84}_16_{sse2,ssse3,avx}() done [16:44] <j-b> drv: ping [19:08] <ubitux> BBB: https://github.com/ubitux/FFmpeg/compare/vp9-simd [19:08] <ubitux> i guess you want some benchmarks? [19:12] <ubitux> 5.40s 5.30s overall [19:42] <cone-918> ffmpeg.git 03Clément BSsch 07master:c5dd73b8902f: x86/vp9lpf: add ff_vp9_loop_filter_h_{48,84}_16_{sse2,ssse3,avx}(). [19:44] <ubitux> BBB: sorry dup :p [19:46] <llogan> finally...BadContent actually stopped some spam [20:25] <cone-918> ffmpeg.git 03Michael Niedermayer 07master:be7b76230fb2: ffmpeg: also count data streams bytes [20:32] <michaelni> llogan, you also could maybe copy the badcontent lists from other big trac installations [20:33] <michaelni> for example: trac.edgewall.org/wiki/BadContent [20:33] <llogan> i looked. some are kind of crappy, but maybe i can cherry-pick [20:34] <michaelni> or maybe some from this: trac-hacks.org/wiki/BadContent [20:34] <llogan> i saw that one too [20:38] <llogan> i wodner what the overhead is [20:51] <cone-918> ffmpeg.git 03James Darnley 07master:9a6d91b6b684: Changelog: add entries relating to metadata_header_padding [00:00] --- Fri Jan 31 2014

1 0

ffmpeg.log.20140130
by burek 31 Jan '14

31 Jan '14

[00:12] <PingasTheFourth> i can't seem to get ffmpeg to record system audio [00:12] <PingasTheFourth> ive tried just about everything i could think of. still no luck [00:13] <ChocolateArmpits> is the use of ffmpeg important for this? what about audacity? [00:14] <PingasTheFourth> havent tried [00:15] <PingasTheFourth> and im rying to record video AND audio, since my current recorder is a pile of junk [00:20] <dleedev> Hi, I recently purchased a GEEYA 720p ip cam. I figured out the URLs for the video stream and the audio stream, but how can I figure out what codec is being used? [00:21] <dleedev> I tried piping the stream to a file and opening it with various media players, and I only got mplayer to open the video dump, and nothing could open the audio dump [00:47] <relaxed> dleedev: playing the stream with mplayer should reveal which codecs are used. [00:47] <dleedev> relaxed: so I can get mplayer to open the video dump, but not the audio dump [00:48] <relaxed> why are you dumping them seperately? Use -dumpstream [00:49] <relaxed> or did you try ffmpeg -i "$url_of_camera" [00:51] <dleedev> relaxed: it's from an IP web cam that has two separate streams [00:51] <dleedev> relaxed: there are two different URLs, one that streams bits of video, and another that streams bits of audio [00:52] <relaxed> pastebin.com the output of ffmpeg -i "$url_of_audio" [00:54] <dleedev> relaxed: http://pastebin.com/4Fbseu3w [00:57] <dleedev> relaxed: when streaming, it comes at an average rate of 4352 bps [02:50] <fragamus> does anyone know in detail how to generate YUV411 input for ffmpeg? some code that generates a test pattern perhaps? [02:58] <llogan> fragamus: ffmpeg -f lavfi -i "testsrc,format=yuv411p" ... output [02:58] <llogan> http://ffmpeg.org/ffmpeg-filters.html#color_002c-haldclutsrc_002c-nullsrc_0… [03:10] <dounan> Hey guys, I'm trying to use ffmpeg for the first time. I'm getting some output warnings when transcoding audio from speex to aac for a flv file that is recorded from an RTMP stream with Wowza media server. [03:11] <dounan> The command I'm using is: ffmpeg -i "$filepath" -c:v copy -c:a aac -strict -2 -b:a 64k -ar 44100 -async 1 "$mp4file" [03:11] <dounan> The output is just a whole ton of these 3 lines: [03:11] <dounan> [mp4 @ 0x2199e60] Non-monotonous DTS in output stream 0:0; previous: 482864, current: 482864; changing to 482865. This may result in incorrect timestamps in the output file. [03:11] <dounan> [NULL @ 0x2196000] AVC: nal size 21102622 [03:11] <dounan> [NULL @ 0x2196000] missing picture in access unit with size 40 [04:38] <Kirito> Do you prefer .mp4 or .m4v? They're essentially the same, right? With the only difference m4v offering support for Apple DRM technologies. [04:40] <relaxed> Kirito: to the rest of the world m4v is raw mpeg4 [05:45] <joecool> hey, ffmpeg git not detecting new libquvi [05:45] <joecool> bails out right in the beginning with [05:45] <joecool> ERROR: libquvi not found [06:46] <anshul> How to see the sameple_fmt of audio using ffprobe [08:36] <anshul> Guys when I am encoding mp2 audio my sample format is AV_SAMPLE_FMT_S16 but when I am looking back the encoded stream using ffprobe [08:37] <anshul> its shows me AV_SAMPLE_FMT_S16P [08:38] <anshul> encoder of mp2 say that it only support AV_SAMPLE_FMT_S16 but how come then ffprobe is planar [08:44] <Kirito> Would it be good to encode baseline with x264 for videos intended to be viewed on modern Android devices? [08:45] <Kirito> Or should I just use main? [08:46] <Mavrik> Kirito, use main [08:47] <Kirito> http://superuser.com/questions/489087/what-are-the-differences-between-h-26… Says Android devices will only play videos encoded baseline. Should I assume that inaccurate? [08:47] <Mavrik> Kirito, thing is... Android devices are officially guaranteed only to support baseline [08:47] <Mavrik> but pretty much every device since awhile ago has a HW decoder capable of handling Main as well [08:48] <Kirito> Ahh, okay, thank you [08:48] <Mavrik> Baseline is a huge quality hit for video [08:49] <JEEB> yeah, basically if you want to support a whole lotta devices it's baseline + level 3 [08:49] <JEEB> but quite a few support main, and a big part of those even support high [08:50] <JEEB> so... yeah :) [08:50] <JEEB> it depends on what you're aiming [08:51] <JEEB> anshul, it's the same thing just planar, I would guess since all the decoders were moved to planar output that's just how it works :P [08:52] <JEEB> encoders take in whatever they've always taken (and possibly things have been added), and decoders were moved to planar formats (except for possible external libs) [08:59] <Mavrik> mhm, even cheap crap with 2.3 has Main capable decoders nowdays [09:22] <anshul> JEEB, will it be good idea to change encoder supported format, then I dont have to use swresample its a performance hit if i am cpoying frame just to change planar to packed [09:23] <anshul> .sample_fmts = (const enum AVSampleFormat[]){ AV_SAMPLE_FMT_S16, [09:23] <anshul> 34 AV_SAMPLE_FMT_NONE } [09:24] <anshul> JEEB, I suppose this is only place, where i have to add the [09:24] <anshul> .sample_fmts = (const enum AVSampleFormat[]){ AV_SAMPLE_FMT_S16, [09:24] <anshul> 34 AV_SAMPLE_FMT_NONE } [09:25] <anshul> JEEB, I suppose this is only place, where i have to add the [09:25] <anshul> .sample_fmts = (const enum AVSampleFormat[]){ AV_SAMPLE_FMT_S16, [09:25] <anshul> 34 AV_SAMPLE_FMT_NONE } [09:25] <anshul> sorry my copy paste is not working properly on my IRC client, or not working how I thought to be [09:26] <JEEB> well if the coder can't handle planar then you will have to convert :P [09:26] <JEEB> or actually make the coder support planar [09:26] <JEEB> but yes, the sample_fmts list is what is used when deciding if you can use the combo or not [09:27] <anshul> JEEB, I would be much intrested in making coder support planar, how much time do you think, that it will take to do that [09:28] <JEEB> depends, but I guess it shouldn't be too hard? [09:59] <anshul> I was looking in decoder how he is supporting planar, but I found that there they support FLTP and FLT, but then how come they are giving S16P at output? [09:59] <anshul> i was looking in file libavcodec/mpegaudiodec_float.c [10:11] <anshul> JEBB, by looking code intensity, I think just now i am not eligible to do that work, may be some one else can do, or after some time when I am having some better undrestanding about how encoder work [11:41] <anshul> guys if I am using code from all examples, I have to include all the license or any one of them or none of them [12:07] <Mavrik> what does the license say? :) [12:12] <superwormjim> Hi there, I'm hoping to get some help with ffmpeg. [12:12] <anshul> Actually some example are part of ffmpeg while some are of Copyright (c) 2003 Fabrice Bellard etc , I dont know what to copy or what to not, I am already giving LGPL license in different file [12:13] <anshul> superwormjim, without any question how would some one help :) [12:13] <superwormjim> I'm trying to do a lossless crop of a WMV file, but it doesn't seem to be possible. [12:13] <superwormjim> If it isn't possible, I am really interested to know why. [12:14] <relaxed> superwormjim: you could crop to a lossless format [12:14] <Mavrik> superwormjim, because you need to decode video into raw frames, crop them and reencode back [12:14] <Mavrik> it's not possible to do that losslessly due to how video encoding works for those formats [12:14] <superwormjim> The background info is: our university (www.tudelft.nl) has this "Collegerama" system (based on a Sonic Foundry product) that hosts videos of classes online for later viewing. [12:15] <superwormjim> Only, they do this in such a horrendous way (720p video with two 640 x 360 boxes, one with the professor and one with the slide show, side by side, surrounded by a big black void) [12:16] <superwormjim> that I want to separate the useful parts into an mkv with two video channels. [12:16] <superwormjim> Now, I must immediately admit that I have more of a background in STILL imaging. [12:17] <superwormjim> Why can this be done on a still JPEG, but not on a video? [12:17] <Mavrik> superwormjim, JPEG is encoded in blocks each frame while in video only I-frame is encoded in such a way [12:17] <Mavrik> superwormjim, other frames have only partial pieces and references [12:17] <superwormjim> There seem to be a lot of products on the internet claiming to be able to do "lossless cropping", although I have no idea if that is something they can live up to. [12:17] <Mavrik> thus you can't just arbitrarily remove pieces of a frame [12:18] <Mavrik> because you'd be removing references and, honestly, it's usually not really worth it [12:18] <Mavrik> since you can reencode video without noticable quality difference if you set parameters up right [12:18] <JEEB> you can lossless only modify the cropping info in the stream [12:18] <JEEB> but that is up to one or two macroblocks only [12:18] <superwormjim> Mavrik, actually I should have said I wanted to do the fastest crop possible on a large number of files, so with the least reencoding possible. [12:19] <superwormjim> Otherwise this might take ages. :P [12:19] <JEEB> one macroblock is 16x16 in H.264 [12:19] <Mavrik> see JEEB's :) [12:19] <JEEB> the feature is generally used to correlate the coded picture with macroblock sizes [12:20] <superwormjim> OK, I think i'm going to read up on that. [12:20] <JEEB> so for example 1080p is really encoded at 1088 height, but then the cropping info tells the decoder to drop 8 from height from wherever it left the padding [12:20] <JEEB> but if you need to crop more than one macroblock I'm not sure if it can do that [12:20] <JEEB> not to mention that you most probably will have to modify the bit stream yourself [12:21] <superwormjim> But, the part that I would throw out when I crop without reencoding; what information does it contain needed for rendering the part that I want to keep? [12:21] <JEEB> the actual coded pictures don't change [12:21] <JEEB> you just signal in the parameter set(s) that the decoder should output this part of the picture [12:21] <JEEB> after doing the decoding process [12:21] <Mavrik> you'll stil be transporting the whole stream tho [12:21] <superwormjim> I see. [12:22] <superwormjim> What about my last question? [12:22] <JEEB> I just answered it? [12:22] <JEEB> unless I misparsed it [12:22] <superwormjim> Oh no, I meant it in relation to my theoretical lossless cropping. :P [12:22] <JEEB> ? [12:22] <superwormjim> I just want to learn what is and isn't possible and why it is. [12:22] <JEEB> paraphrase [12:22] <JEEB> please [12:23] <superwormjim> Say, I would try to do a "lossless crop", like on a JPEG. [12:23] <JEEB> I'm not too knowledgeable of JPEG [12:23] <JEEB> but [12:23] <superwormjim> I've just been told that this wouldn't be possible, because only the keyframes get encoded in their entirety (i f I understood correctly). [12:23] <JEEB> not only that [12:23] <JEEB> I'm pretty sure even within intra coded pictures other parts of the picture can require other parts [12:24] <superwormjim> One would think, that it would be possible to only throw out information not needed for rendering the final picture. [12:24] <superwormjim> OK, so that should have been the first question to ask then :P [12:24] <JEEB> basically JPEG was a much simpler format [12:25] <JEEB> not only would multiple pictures all be intra coded [12:25] <superwormjim> I understand... [12:25] <JEEB> but I think the intra coding is more limited than with newer formats? [12:26] <superwormjim> But about those macroblocks: wouldn't it be possible - keeping in mind that this is WMV3 - to throw out a couple of them, that you really don't need? [12:26] <JEEB> oh, WMV3 [12:26] <superwormjim> Then you might end up with a video bigger than the one intended, but then you could tell the decoder to crop it to the right size. [12:27] <JEEB> well, at the point of WMV3 it gets raather derpy [12:27] <superwormjim> (This all seems reasonable from the perspective of a mechanical engineering student anyway) [12:27] <JEEB> mostly because I have no idea about that format [12:27] <superwormjim> I see :P [12:27] <Mavrik> yeah, WMV3 is rather obscure [12:27] <JEEB> if either the video or container format contain cropping information (WMV3 and ASF respectively) [12:27] <Mavrik> superwormjim, it sounds reasonable, I'm just not sure anyone really bothered with WMV3 do this extent :) [12:27] <JEEB> then you can most probably go off hacking [12:28] <JEEB> mp4 possibly has some tags to limit the viewport as a container (considering how much random crap it has :D), but WMV3 does not go into mp4 [12:28] <superwormjim> Let's just say: while the web is moving to formats like WebM and to HTML 5 video tags, education and the public broadcasting networks (at least in the Netherlands) are moving to Microsoft products. :') [12:28] <superwormjim> (Windows Media whatever server through silverlight :P) [12:29] <JEEB> that's still fine until you get to using proprietary formats like WMV3/WMA and ASF [12:29] <superwormjim> Of course, you can all view this in their proprietary "app" I'm sure... :P [12:29] <JEEB> silverlight takes in MP4 and H.264/AAC [12:29] <superwormjim> The Windows Media Whatever server product (I tend to forget about proprietary naming schemes) only supports WMV I think. [12:30] <JEEB> "fun" [12:30] <superwormjim> About the "soft cropping" thing... Telling the decoder to crop to a certain size. [12:30] <Mavrik> yeah [12:30] <superwormjim> That is a metadata thing I'm sure? [12:30] <Mavrik> it took us like 3 years to get some educational institutions off of WMV and into some decent server [12:31] <superwormjim> (3 years is like a blink of an eye in education!) [12:31] <JEEB> yes, it's metadata, saved somewhere [12:31] <JEEB> depends on the formats at hand if such metadata exists [12:31] <JEEB> and how limited it is [12:32] <superwormjim> (We've just moved to Pearson's "MathXL" for Linear Algebra - which basically is a Flash based enter-your-matrices-here-so-we-don't-have-to-check-them-because-the-computer-does system that opens pop-ups only to tell you to disable your pop-up blocker) [12:33] <JEEB> (matroska has a cropping field as well, but don't be fooled, this is just Haali's hack to make it simpler to edit H.264 parameter sets' cropping information without actually editing it, so it's limited by what you can do on the H.264 side -- also many splitters just don't support it. I think VLC is the only one that went all out on implementing it) [12:33] <superwormjim> Now, would it be possible to create an MKV containing a stream copy of the WMV, and create to video channels in it simply "cropping" them from the stream? [12:34] <superwormjim> I understand it would be possible to include the stream copy twice and then "soft crop" it twice, but that would be backwards. [12:34] <superwormjim> channels = tracks [12:36] <superwormjim> (Sorry if my terminology is a bit off, I will make it up to you whenever you ask me something about web standards or whatever :P) [12:36] <superwormjim> (But let's not brag... :$) [12:36] <JEEB> hey, IETF publishes H.264, too! :P [12:36] <JEEB> well, in this case I'll just say that there's no easy way out regarding losslessly cropping your WMV3 streams [12:36] <JEEB> also I have no idea what you're talking about with the two tracks [12:37] <superwormjim> An MKV can include multiple video tracks, right, that you can switch between? [12:37] <JEEB> yes [12:38] <superwormjim> The university puts two video frames next to eachother in one frame [12:39] <superwormjim> And I want to separate these into different videos, and since MKV is well supported these days, why not put them in one MKV container? [12:39] <JEEB> ok [12:39] <superwormjim> Now, since I can't do a crop without reencode... [12:39] <JEEB> basically, you can make that only so that a single vendor can show it "correctly" [12:39] <superwormjim> But I can do a "soft crop" (or what is it called officially?) telling the decoder to crop it. [12:39] <JEEB> and you will be muxing the track twice [12:40] <superwormjim> Wouldn't it be possible to make two different crops from the same bit stream and then make them available to the user as different video tracks? [12:41] <superwormjim> In fact, I am reasonably sure this could be solved the hard way with some VLC command line switches instructing it to crop... [12:41] <JEEB> also, just to note -- I'm pretty sure matroska has no native mappings for WMV3, it's just muxed there in VFW compatibility mode which is rather ugly as well [12:41] <superwormjim> But would something like that be possible in the mkv container itself? [12:42] <superwormjim> OK, I don't know about that. [12:42] <JEEB> well, matroska "has" a cropping field, but it's only supported by two vendors, and one of them is limited to H.264 [12:42] <JEEB> "has" because the definition of "specification" for matroska is always very vague [12:43] <superwormjim> OK, then I misunderstood. [12:43] <JEEB> and this is one of the very vague ones [12:43] <JEEB> so basically you could make a file that (probably) would crop off things in VLC [12:43] <superwormjim> Are there other container formats with a cropping field that is well supported ? [12:43] <JEEB> but !VLC would then show the whole pic [12:44] <JEEB> mp4 is one possibility [12:44] <superwormjim> OK. [12:44] <JEEB> I don't remember if it has one for viewport cropping [12:44] <JEEB> but it probably has something that can be (ab)used like that [12:44] <JEEB> although that pretty much stops at the [12:44] <JEEB> > WMV3 [12:44] <JEEB> > MP4 [12:44] <JEEB> part [12:45] <JEEB> which is why i said that you have one clear way of doing it, and that way would only work with a single vendor :P [12:46] <superwormjim> Just to be clear: what I'm trying to achieve, not right away but eventually, is a sort of shell script using ffmpeg to convert the university's ugly video into something modern and usable, that anyone can use without knowing anything about video. [12:46] <superwormjim> So other students could use it as well. [12:46] <superwormjim> To sum up, I: [12:47] <superwormjim> - either get multiple video tracks cropped from one and the same bit stream working in a reasonable number of video players [12:47] <superwormjim> - simply reencode the thing like a normal person would. [12:48] <JEEB> well, you start hitting a problem with the first point with not only getting the cropping done, but also having the same data be read for both :P [12:48] <superwormjim> You think that wouldn't be possible? [12:48] <JEEB> yes [12:48] <superwormjim> I figured as much... XD [12:49] <JEEB> or well, fancy formats like mp4 probably would let you point them "pointers" towards certain spots of data, but then again you're dealing with WMV3 [12:49] <JEEB> which doesn't go into MP4 [12:49] <superwormjim> Then back to the macro blocks. [12:49] <JEEB> second variant is the only thing that will realistically have wide support and not have the same thing twice in itself :P [12:50] <superwormjim> It would not at all be possible to throw out SOME of them that don't get used in the desired part of the picture? [12:50] <JEEB> I have no idea about the intricasies of WMV3 [12:50] <JEEB> but even if you could kind of poke it, you'd still have to go through the whole GOP [12:50] <JEEB> and make sure nothing in that GOP references those cropped areas [12:51] <JEEB> and that already implies that you can do such cutting in a WMV3 bit stream, which we don't know if we can [12:52] <superwormjim> But most video codecs reference things in other parts of the frame, I understand? *face palm* Of course they do, because things tend to move up and down and left and right in a video! [12:52] <superwormjim> (I should really stick to still images) [12:53] <JEEB> oh, and it gets even more fun when things in the same picture reference other parts in the same picture :P [12:53] <superwormjim> OK, thank you very much for all of your suggestions. I understand that I'm trying to achieve very unusual things, and thanks for putting up with tat. [12:54] <superwormjim> I'm going to research some more on the web. [12:54] <superwormjim> Is it OK if I come back here when I hit some roadblock trying to implement something? [12:55] <JEEB> who would stop you? [12:55] <superwormjim> You getting tired of this. ;) [12:56] <superwormjim> And trying to protect everyone else from my ignorance on video codecs. [13:04] <superwormjim> Thanks again! [14:10] <DeadSix27> anyone knows how to "update?" vidstab ? [14:10] <DeadSix27> config.log -> http://pastebin.com/gdKp4ed3 [14:12] <DeadSix27> ah. apparently its on the git [14:30] <Qantourisc> Looking for a comb-detect filter, can't find any atm, suggestions ? [14:30] <Qantourisc> (if I can pass a custom filter values, I can also make it work, but for example unsharp=1:3:0.5 refuses the 1 :/ [15:27] <firemanxbr> hey guys, I'm have problems with Logitech C920 capture 1080p resolutions using ffmpeg, anybody help me ? [15:29] <firemanxbr> I'm using this command: [15:30] <firemanxbr> ffmpeg -loglevel debug -f alsa -i hw:1 \ [15:30] <firemanxbr> -ac 2 -acodec aac -s 1920x1080 \ [15:30] <firemanxbr> -f video4linux2 -framerate 30 \ [15:30] <firemanxbr> -i /dev/video1 \ [15:30] <firemanxbr> -bt 4M -c:v libx264 -minrate 3000K -b:v 4500k -maxrate 6000k -bufsize 500K \ [15:30] <firemanxbr> -strict -2 -ar 44100 -g 2 out.mp4 [15:30] <firemanxbr> sorry [15:30] <firemanxbr> http://ur1.ca/gj5os [15:31] <firemanxbr> anybody help me ? [16:25] <mrmargolis> Hi Everyone. Is there a way for ffmpeg/ffprobe to get the timecode for a Poster Frame if one is set? I am working with quicktime files. [17:15] <DopeLabs> good morning ... anyone awake? [17:20] <DopeLabs> welp.. if anyone knows the specifics on the proper usage of the icy options to pass shoutcast metadata/title info along... id be happy to hear =] [19:45] <llogan> DopeLabs: what are icy options? [19:48] <llogan> firemanxbr: you didn't include the complete console output [19:48] <firemanxbr> llogan, okay I'm get new adjusts and send for fpast [19:52] <firemanxbr> llogan, http://ur1.ca/gj7a1 [19:52] <firemanxbr> llogan, I'm using Logitech C920 in my /dev/video1 [19:53] <DopeLabs> llogan: shoutcast metadata [19:53] <firemanxbr> but i'm not sucess in solve my bitrate and errors [19:54] <firemanxbr> llogan, some sugestion ? [19:54] <DopeLabs> more specifically... http.c [19:55] <llogan> firemanxbr: describe the issue [19:56] <firemanxbr> llogan, I'm get video for my WebCam and send to Youtube Live(RTMP) [19:56] <llogan> also ffmpeg will ignore -pix_fmt when stream copying [19:57] <firemanxbr> llogan, but Youtube live, drop my low bitrate [19:57] <firemanxbr> llogan, okay I'm remove this option [19:57] <llogan> sorry, what do you mean by, " Youtube live, drop my low bitrate" [19:58] <firemanxbr> llogan, Youtube live require this bitrate tax: https://support.google.com/youtube/answer/2853702?topic=2853713&hl=en [19:59] <firemanxbr> llogan, for my resolution(1080p = 1920x1080) minimal: 3000kbps, recommended 4500kbps and maximum: 6000kbps [20:01] <firemanxbr> llogan, I'm setting: -b:v 4500k, but my stream not send in this bitrate [20:01] <llogan> -b:v is probably ignored when stream copying [20:01] <llogan> (using -vcodec copy) [20:02] <firemanxbr> llogan, it is problem [20:02] <firemanxbr> llogan, exist other alternative about this ? [20:02] <DopeLabs> if you cant handle the upstream, lower your frame size/bitrate to something that will work [20:02] <llogan> if you must re-encode, then don't stream copy [20:03] <firemanxbr> llogan, some example for me ? [20:04] <firemanxbr> DopeLabs, I'm trying setting framerate in 20, but not sucess [20:04] <DopeLabs> right [20:04] <firemanxbr> return about youtube live: We recommend you use a stream bitrate value of (4500 Kbps). The current bitrate value (128.00 Kbps) for the stream is lower than the recommended bitrate. [20:04] <DopeLabs> you say that yt is bitching about you not meeting the bitrate for 1080p correct? [20:05] <llogan> does yt still display the video? [20:05] <firemanxbr> DopeLabs, exactly [20:05] <firemanxbr> llogan, no :( [20:05] <DopeLabs> from what i recall, you can set the live event to something lower htan 1080p... [20:06] <firemanxbr> my goal is create stream for world cup in brazil [20:06] <DopeLabs> can your internet connection handle a ~5000k upstream? [20:06] <llogan> try another streaming service [20:06] <firemanxbr> DopeLabs, exactly but my live events require this resolution [20:07] <firemanxbr> DopeLabs, yes, my connection is 1000 Mpbs [20:07] <DopeLabs> heh [20:08] <DopeLabs> yse ffserver [20:08] <firemanxbr> if I retreat "-vcodec copy" many drops in my stream [20:09] <DopeLabs> what is the source [20:09] <firemanxbr> http://ur1.ca/gj7e4 [20:09] <firemanxbr> whitout '-vcodec copy' [20:10] <llogan> you can try something like this: -i /dev/video1 -c:v libx264 -c:a aac -strict -2 -b:a 128k -maxrate 5000k -bufsize 10000k -pix_fmt yuv420p -g 2 -f flv rtmp://streaming-server/stream_name [20:10] <firemanxbr> llogan, okay i'm try [20:10] <DopeLabs> heh [20:11] <llogan> although if your input claims to be only 128k... [20:11] <DopeLabs> yea i would switch to the aac audio [20:12] <DopeLabs> Input #1, video4linux2,v4l2, from '/dev/video1': [20:12] <DopeLabs> is only outputting 1000k [20:12] <DopeLabs> can you set that higher? [20:13] <DopeLabs> on teh source? [20:13] <llogan> or for audio you could try -c:a libmp3lame -ar 44100 -b:a 128k [20:14] <firemanxbr> no :( [20:14] <firemanxbr> http://ur1.ca/gj7f6 [20:14] <DopeLabs> wonder if anyone knows what how the icy options work [20:14] <firemanxbr> many drops in my stream [20:15] <llogan> are the drops due to the encoding or your network? (I'm not very familiar with streaming to tell you the truth) [20:16] <llogan> if you output to a local file does it contain the drops? [20:16] <DopeLabs> you dont need to encode again [20:16] <DopeLabs> your already getting an h264 stream right? [20:16] <DopeLabs> just change the container, done [20:16] <DopeLabs> only thing you might want to do is the audio... [20:16] <DopeLabs> but you got the bandwidth, you said... [20:16] <firemanxbr> llogan, in local file, for example: out.mp4, same problem [20:17] <firemanxbr> how solve drops in ffmpeg ? [20:17] <llogan> what if you stream copy instead and output to a local file? does it look shitty too? [20:17] <llogan> DopeLabs: did you see http://ffmpeg.org/ffmpeg-protocols.html#http [20:18] <llogan> -icy 1 [20:18] <llogan> also -icy_metadata_headers -icy_metadata_packet [20:18] <firemanxbr> llogan, exactly in local file same problem, many freezs in my video file [20:19] <llogan> this is with the stream copy (-vcodec copy)? [20:19] <firemanxbr> good idea [20:19] <DopeLabs> llogan: yes [20:19] <DopeLabs> at most [20:19] <DopeLabs> what i can get from that [20:19] <DopeLabs> is i need to set [20:19] <DopeLabs> -icy 1 [20:19] <DopeLabs> somewhere [20:20] <DopeLabs> it seems the only place ffmpeg wont bark about it is before the -i shoutacst:port [20:20] <DopeLabs> but there are those other 2 things there [20:20] <DopeLabs> icy_metadata_headers [20:20] <DopeLabs> and packet [20:21] <firemanxbr> strange return [20:21] <DopeLabs> there just isnt really any doc about how it works, or an example of how it should be used to get it to work [20:21] <llogan> i dont know. try ffmpeg-user mailing list. [20:21] <firemanxbr> after [alsa @ 0x2244780] ALSA buffer xrun. [20:21] <firemanxbr> many many drops [20:21] <firemanxbr> *** drop! [20:21] <firemanxbr> Last message repeated 11 times [20:21] <firemanxbr> *** drop!91 fps= 11 q=24.0 size= 1427kB time=00:00:11.28 bitrate=1036.0kbits/s dup=0 drop=92 [20:28] <DopeLabs> this if your input format is something that yt will support... this is what worked for me [20:28] <DopeLabs> -c:v copy -c:a copy -bsf h264_mp4toannexb -f flv rtmp:// [20:32] <firemanxbr> DopeLabs, good sugestion, i'm try this it [20:33] <DopeLabs> but i also tuned my input to meet yt's requirements [20:34] <DopeLabs> which as it turns out, was a waste of my time [20:34] <DopeLabs> since yt will take away my live ability if i contune to broadacst content matched to 3rd parties... lol [20:34] <firemanxbr> DopeLabs, i'm trying for my job [20:35] <firemanxbr> lol :D [20:45] <DopeLabs> woot... forum registration is working again [21:23] <rcombs> so, I'm trying to render an ASS track over transparent video; does this command make sense? ffmpeg -f lavfi -i 'color=s=1920x1080:d=90:r=24:c=#FFFFFFFF' -filter_complex 'format=pix_fmts=argb [f];[f] lutrgb=a=0 [ass]; [ass] ass=kara.ass' -movflags faststart -vcodec qtrle -y -loglevel verbose out.mov [21:24] <rcombs> if I strip out the lutrgb, I end up with my text rendered over a white background; with it, I get fully-transparent video [21:27] <Qantourisc> rcombs: is the text B/W ? [21:27] <rcombs> Qantourisc: no [21:28] <Qantourisc> rcombs: is it 1 color ? [21:28] <rcombs> no [21:28] <Qantourisc> rcombs: are they the same brightness ? [21:28] <rcombs> nope! [21:28] <rcombs> there's blur, fading, and multicolor effects [21:29] <Qantourisc> rcombs: that's ok [21:29] <Qantourisc> rcombs: i mean the "center/non-blured" parts [21:29] <DopeLabs> how many f's you got goim on there? [21:29] <rcombs> oh, not exactly the same brightness, no [21:30] <rcombs> does ff_draw not handle alpha blending over all-transparent video well? [21:30] <Qantourisc> rcombs: if lutrgb support math,you can try (r+g+b)/3 i think [21:30] <Qantourisc> rcombs: I suspect your input has no alpga [21:30] <DopeLabs> #FFFFFFFF ? [21:30] <DopeLabs> is it not #FFFFFF [21:30] <rcombs> yeah, the lavfi input is YUV420p [21:31] <rcombs> I was trying to add an alpha channel, but it ignores it [21:31] <Qantourisc> rcombs: then you need to "generate" your alpha [21:31] <Qantourisc> problem is i'm an utter noob in user ffmpeg : [21:31] <rcombs> shouldn't format=pix_fmts=rgba do that? [21:32] <Qantourisc> rcombs: nope [21:32] <Qantourisc> rcombs: #FF FF FF ??(no alpha info) in mean #FF FF FF FF out [21:32] <rcombs> thus the lutrgb=a=0 [21:32] <Qantourisc> but then you make it invisble [21:33] <rcombs> yes [21:33] <Qantourisc> rcombs: what did yhe output look like again ? [21:34] <rcombs> using that command, I end up with a completely transparent video [21:34] <rcombs> I should be getting the subtitles rendered over transparent [21:34] <Qantourisc> completely ? both movy and text ? [21:34] <rcombs> yup [21:34] Action: Qantourisc ponders for a while. [21:34] <rcombs> 100% transparent across the entire video on every frame [21:35] <rcombs> my guess is that ff_draw isn't handling alpha blending over a transparent background properly [21:36] Action: Qantourisc does not see ff_draw in the command [21:36] <rcombs> vf_ass uses the ff_draw API [21:36] <rcombs> http://ffmpeg.org/doxygen/trunk/drawutils_8c.html [21:38] <Qantourisc> rcombs: hmmm "idea" [21:38] <Qantourisc> rcombs: let me look up the command [21:38] <Qantourisc> IF i find the command :/ [21:42] <Qantourisc> rcombs: happen to know the command to mix 2 streams using some sort of blend algoritme ? [21:42] <rcombs> Qantourisc: overlay? [21:43] <Qantourisc> hmm yes [21:43] <Qantourisc> actually :) [21:43] <Qantourisc> rcombs: /me tries if ffplay support this [21:44] <Qantourisc> rcombs: euuu where is your input video in that command ? [21:45] <rcombs> Qantourisc: -f lavfi -i 'color=s=1920x1080:d=90:r=24:c=#FFFFFFFF' [21:45] <Qantourisc> rcombs: lavfi is a video ? [21:46] <rcombs> no, lavfi is a special format, indicating that the input should come from one of libavfilter's generators [21:46] <rcombs> the input is 'color=s=1920x1080:d=90:r=24:c=#FFFFFFFF', which indicates to use the "color" generator at 1920x1080 for 90 seconds at 24fps and output pure white [21:47] <Qantourisc> rcombs: happen to know how to address an input files stream with ffmpeg ? [21:47] <rcombs> in filter_complex? [21:48] <Qantourisc> well that's a start :p [21:49] <rcombs> gimme a sec, I'm going to hack at vf_subtitles.c a bit [21:54] Action: Qantourisc needs something saner then overlay ;po [22:00] <Qantourisc> rcombs: overlay seemms to be hard-overlay [22:00] <rcombs> I've almost got this [22:01] <rcombs> I'm modifying vf_subtitles.c to handle alpha blending well [22:01] <Qantourisc> :p [22:01] <Qantourisc> well that's a way [22:02] <Qantourisc> I'd like to just find the filter that take 2 input and where you can choice yourself what math to unleash on it [22:02] <Qantourisc> blend ? [22:07] <rcombs> http://puu.sh/6E5H3.png <-- there should be yellow in there :| [22:08] <Qantourisc> mwea give up for now must do other things first [22:09] <Qantourisc> side question: pp=ha:a:512 vs pp=ha ? (a beeing quality according to the manual) [22:11] <Qantourisc> rcombs: i'd solve it with blend, but the docs are terrible :( [22:33] <gebbione> hi all, i am trying to crop a video but all i get is a reduced quality version of the original rather than a crop [22:33] <Qantourisc> gebbione: command used ? [22:35] <gebbione> ffmpeg -i Video.mp4 -vf "crop=1632:976:0:6" Video_2.mpg [22:35] <gebbione> trying with the right [22:35] <gebbione> extension now [22:36] <gebbione> even with the right extension it is not cropping anything [22:37] <Qantourisc> gebbione: what is the input dimentinon ? [22:38] <gebbione> 1632 x 992 [22:39] <Qantourisc> hmmm might need to specify the output size aswel [22:39] <Qantourisc> or it might just scale it back up :) [22:43] <odie133> hi, i'm trying to cross compile ffmpeg with libvpx support for windows under arch linux, but get the following error: libvpx decoder version must be =>0.9.1 [22:45] <Qantourisc> odie133: what is installed ? [22:46] <odie133> newest libvpx package actually [22:47] <Qantourisc> odie133: so indeed =>0.9.1 ? [22:47] <Qantourisc> odie133: next up what version is installed for corss-compile actions ? [22:48] <odie133> i just installed mingw64 toolchain [22:49] <Qantourisc> imo sounds like a problem not related to ffmpeg, but to the compiling/libs installed [22:51] <odie133> i try to figure it out then [23:10] <Moult> which part of this ffmpeg -i output (http://hastebin.com/jucaremaqe.mel) says that the wrapper format is mp4? [23:29] <Hello71> please use something that does not require JS [23:35] <DopeLabs> behold... [23:35] <DopeLabs> http://ffmpeg.gusari.org/viewtopic.php?f=11&t=1258 [23:55] <llogan> DopeLabs: the ffmpeg-user mailing list is better than the forum in most cases. there are more answer providers on the mailing list [23:55] <DopeLabs> alrighty then.. [00:00] --- Fri Jan 31 2014

1 0

ffmpeg-devel.log.20140129
by burek 30 Jan '14

30 Jan '14

[00:25] <BBB> ubitux: so mt is ... a little complicated, basically libvpx has tile-mt and loopfilter-mt, we have frame-mt [00:25] <BBB> on files with tiles and no parallelmode, tile-mt is better [00:25] <BBB> in all other cases, frame-mt is better [00:26] <BBB> I'd like to add tile-mt at some point in the future [00:26] <BBB> I don't have exact numbers on "how much better", just very rough approximations [00:29] <cone-490> ffmpeg.git 03Carl Eugen Hoyos 07master:4151b9953e23: Add elbg Makefile dependency to the cinepak encoder. [04:32] <cone-350> ffmpeg.git 03Carl Eugen Hoyos 07master:862174ec831d: Move GUID-related objects to riffenc.c and riff.c. [04:32] <cone-350> ffmpeg.git 03Carl Eugen Hoyos 07master:bf9a8d183ddc: Support writing E-AC3 in wav. [05:30] <smoak> ive found an hls stream that returns a Set-Cookie header when requesting the AES key and needs this cookie set for subsequent key requests. im looking around https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hls.c#L413 to figure out how to use the returned cookie. ive been able to read the cookie with av_opt_get(uc->priv_data, "cookies", 0, (uint8_t**)&(key_cookie)), but i dont know how to get it [05:30] <smoak> back into the URLContext->priv_data [05:43] <michaelni> smoak, setting it in the AVDictionary that is given to *open/connect should work [06:04] <cone-350> ffmpeg.git 03Michael Niedermayer 07master:ad61419bbffa: avformat/mpegts: drop stray space [06:04] <cone-350> ffmpeg.git 03Michael Niedermayer 07master:29986885ef7d: avformat/mpegts: Continue parsing PMTs until at least 2 streams are found or 100kb are reached [06:04] <smoak> michaelni: hmmm...that doesnt seem to get all the way to the http_connect method though [06:07] <smoak> i suspect in ffurl_connect, uc->prot->url_open2 is false [06:07] <smoak> in which case it would use url_open which doesnt take an AVDictionary [06:11] <smoak> nope thats not the case...hmmm [06:42] <smoak> i think it might be in here https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/http.c#L137 [06:51] <smoak> it looks like that AVDictionary that is given to open/connect gets put in a HTTPContext->chained_options but the get_cookies method doesnt check that [08:12] <smoak> ok, i traced this down to the get_cookies method when parsing a cookie with an Expires directive [08:16] <smoak> for example with a cookie like this lu=Rg3vHJZnehYLjVg7qi3bZjzg; Expires=Tue, 15-Jan-2013 21:47:38 GMT; Path=/; Domain=.example.com; when it gets to the Expires directive, it gets tokened by spaces like so: tok1 = Expires=Tue,; tok2 = 15-Jan-2013; tok3 = 21:47:38; tok4 = GMT such that each of those is considered its own param [10:00] <cone-4> ffmpeg.git 03Carl Eugen Hoyos 07master:cfe282ec80dc: Remove now unneeded Makefile dependency for the wtv muxer. [11:43] <xlinkz0> I've got an interesting bug when receiving a rtsp stream [11:43] <xlinkz0> the stream works fine in vlc but ffmpeg reports a much lower fps [11:44] <xlinkz0> and in fact when i stream copy with -t 20 the recording stops after a couple of seconds [11:44] <xlinkz0> but the final video file has 20 seconds duration and a low fps.. [11:45] <xlinkz0> i can give you the stream if anyone is interested.. [11:47] <xlinkz0> i updated to git head and i have the same problem [11:48] <anshul> why dont you search for similar bug at https://trac.ffmpeg.org/ [11:48] <anshul> I think this bug is already reported you can help people solving this bug [11:49] <xlinkz0> this is where i search? https://trac.ffmpeg.org/search?q=rtsp+fps&noquickjump=1&ticket=on [12:45] <anshul> xlink is this #2360: defect: FFmpeg rtp streaming was not synchronous (new) is matching to your problem [13:30] <xlinkz0> anshul: i have no sound [13:31] <xlinkz0> the problem is ffmpeg sets the stream ok 90k tbr [13:31] <xlinkz0> s/ok/on [17:02] <nevcairiel> hm is the hlsenc muxer good for anything? segment seems much more advanced [17:15] <cone-4> ffmpeg.git 03Diego Biurrun 07master:54b2ce7418c0: mpeg: Drop unused parameters from ff_draw_horiz_band() [17:15] <cone-4> ffmpeg.git 03Michael Niedermayer 07master:fbafd64acce4: Merge remote-tracking branch 'qatar/master' [17:38] <ubitux> https://github.com/ultravideo/kvazaar [17:38] <bri> ubitux: how's that look? :] [17:38] <ubitux> no idea [17:40] <bri> was that recently posted somewhere? i've been seeing the link going around [17:42] <ubitux> yeah, HN & friends [17:59] <wm4> ubitux: somehow this thing looks very sane [19:36] <llogan> ubitux: sorry for the email dupe. i forgot to reply to all. [19:36] <ubitux> no worry [20:13] <llogan> trac is down [00:00] --- Thu Jan 30 2014

1 0

ffmpeg.log.20140129
by burek 30 Jan '14

30 Jan '14

[01:23] <sineb> what resoloution is dvd. I want to scale down from 1920x1080 or 1280x720 [01:25] <sacarasc> http://mplayerhq.hu/DOCS/HTML/en/menc-feat-vcd-dvd.html shows you all the DVD compatible things. [01:25] <sacarasc> But 1280x720 is too big. [01:27] <sineb> thanks. will i have to crop my image [01:27] <sineb> maths makes my mind go blank. im an artistic left brainer [01:29] <sacarasc> If you're in a NTSC country, `ffmpeg -i input -target ntsc-dvd output` may be enough. [01:29] <sineb> im pal [01:30] <sacarasc> -target pal-dvd [01:30] <sineb> ok so this will drop MPEG2 files [01:30] <sineb> or in AUDIOTS VIDEOTS [01:30] <sineb> format [01:30] <sineb> im probably expecting to much here for it to create a ddvd for me lool [01:30] <sacarasc> It won't be in vobs. [01:31] <sineb> but VOBS is just a container right, no other encoding happens [01:32] <sacarasc> It will encode it to MPEG2, ready for a DVD authoring program. [01:32] <brianf> you could use dvdstyler to have a more automated thing (and if I recall correctly it uses ffmpeg to convert anyway) [01:32] <sineb> yea sure thanks, but i was thinking the dvd authoring program does not compress or encode the video audio stream any further does it [01:33] <brianf> hmm, I don't remember [01:33] <sineb> I basically have my nans birthday all filmed on my canon 550d in 1920 1080. i was thinking editing it all in AAE and then dumping it to a lossless and then ffmpeg it to MPEG2 [01:41] <brianf> well, I guess you could do that and use these mpeg2 files as input for the dvd tool if the problem is to convert it to AUDIOTS/VIDEOTS. [02:13] <bencc> does this should work on browsers (Chrome, FF, IE)? ./ffmpeg -i video.avi -c:v libx264 -vf -movflags faststart video.mp4 [02:14] <bencc> I can't play video.mp4 in browsers and not sure what's wrong [02:14] <bencc> I can play it in vlc [02:37] <llogan> probably chroma subsampling issue, but impossible to tell without a sample or the console output [02:37] <bencc> llogan: ok. a sec [02:40] <bencc> llogan: http://pastie.org/8677147 [02:53] <thebombzen> has anyone else noticed flickering when using ffmpeg's x11grab device input with an application running OpenGL? [02:53] <thebombzen> I suspect this is because OpenGL renders directly to the hardware and somewhat bypasses X11, but there might be a way to fix this [03:10] <didge> How do I get a good binary distribution of ffmpeg for freebsd using pkg ? [03:10] <didge> I'm trying to work with mp4 and png [03:14] <llogan> bencc: Use -pix_fmt yuv420p for compatibility with outdated media players [03:14] <llogan> (that's from the console output) [08:58] <fundies> any way to make ffmpeg copy only the video stream and all the audio streams regardless of how its mapped? [09:02] <relaxed> fundies: ffmpeg -i input -map 0:v -map 0:a ... [09:03] <relaxed> er, ffmpeg -i input -map 0:v -map 0:a -c copy ... [09:03] <fundies> thatll get all the audio tracks? [09:03] <relaxed> yes, and all the video streams [09:07] <fundies> thanks it worked [09:21] <bencc> llogan: works. thanks [09:25] <Mavrik> em [09:25] <Mavrik> not just outdated video players [09:26] <Mavrik> there's no requirement that any of the players have to support more than yuv420p [09:39] <bencc> Mavrik: I thought that browsers have new players but without this, the video doesn't play [09:40] <Mavrik> as I said. [09:40] <Mavrik> the standard requires ONLY support for yuv420p [09:40] <bencc> ok [09:40] <Mavrik> new or not, the player doesn't have to support anything else [09:40] <Mavrik> and browsers tend to use whatever hardware decoding capability the device has [09:40] <JEEB> uhh, more like it depends on what profiles the decoder supports :P [09:40] <JEEB> and then the features are limited to that [09:42] <JEEB> basically saying "the standard requires ONLY support for 4:2:0" is misleading, because it's the decoder that chooses the features (profile[s]) to support, and then if it wants to be compliant it has to implement what's in the specification [09:43] <JEEB> if you say that you support high 4:2:2 profile and you then don't implement it? that is not compliant [09:43] <JEEB> and yes, hardware decoders usually limit themselves to high profile support [09:43] <JEEB> which is 4:2:0 [09:43] <JEEB> (and main, constrained baseline are subsets of high, so they end up being supported as well) [10:04] <anshul> Is there any relation of planar sample format and number of channel? [10:05] <JEEB> no [10:05] <JEEB> as in, planar doesn't mean a specific channel count or anything like that [10:05] <JEEB> planar just means that you have separate buffers with each containing a single channel's data [10:09] <anshul> jeeb do you have master git version if you have line 1331 in libavcodec/utils.c does not make any sense [10:10] <anshul> in libavcodec/utils.c they have compared avctx->channels == 1 for selecting sample fmt [10:12] <JEEB> well, with mono you have just a single buffer, just like with interleaved stuff [10:13] <JEEB> so if (thing_is_mono && the_planar_version_matches) override_sample_fmt [10:13] <JEEB> because in that case planar and interleaved are the same [10:13] <JEEB> the general matching is done just before it and the break; would hit there if there was a match (as in, the encoder takes in the context's sample_fmt [10:18] <anshul> if I am having fltp sample format thing_is _streao so is it not supported by mp2 codec and i have to drop the sample fmt as fltp and make it s16 [10:19] <anshul> are encoder depends on perticular sample_fmt [10:20] <JEEB> yes, encoders have lists of sample formats they support [10:21] <JEEB> for example mpegaudioenc_float supports these http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/mpegaudioenc_floa… [10:21] <JEEB> and mpegaudioenc_fixed supports these http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/mpegaudioenc_fixe… [10:21] <JEEB> since you mentioned mp2 I noted those two [10:22] <active8> Hi. I'm having a problem configuring an ffmpeg build with gcc on linux. First it said it can't find librtmp and when I added extra paths, it said "gcc is unable to create an executable file" and finally "C compiler test failed" http://pastebin.com/PzWjQcGK [10:23] <anshul> jebb, thanks you were my eyes opener [10:24] <YellowOnion> I have a video that is yuvj420p, but is marked incorrectly (says its yuv420p) how do I set it to yuvj420p and then convert it to yuv420p? [10:24] <JEEB> I'm pretty sure you don't need -lrtmp in there, that is added when linking to it automagically. Also does librtmp really have no installation since I have noted you are using the source code directory :P [10:24] <JEEB> also for any errors see config.log [10:24] <JEEB> that tells you where exactly it failed [10:24] <JEEB> also, are you sure you need librtmp? [10:24] <JEEB> ffmpeg has had internal rtmp support for quite a while now [10:26] <active8> i have rtmpdump installed, but vlc used a special script to install ffmpeg because of lib dependency issues. so I have a crippled ffmpeg and am building a extra one to handle what the crippled one cannot [10:27] <JEEB> YellowOnion, if it really is full range you could try editing the value in the parameter sets (I will guess this is H.264 ?), although that will require hex editing and reading some of the H.264 specification. Or you have to just force the thing to be interpreted as full range by the filters. [10:28] <JEEB> oh [10:28] <JEEB> there's -color_range [10:28] <YellowOnion> JEEB: its some old school dx50 codec according to VLC, I can current get it to collectly output yuvj420 x264 but I don't want to have to recode again. [10:30] <JEEB> well, if you wanted to convert it you'd have to re-encode anyways :P [10:30] <JEEB> but yeah, try -color_range before -i [10:30] <active8> JEEB. infernal support, eh? I did not catch that fact at ffmpeg.org or elsewher. WTH. Maybe I'll go with it and see if it's built in. [10:30] <JEEB> active8, it was developed during the libav 2012 summer of code [10:30] <JEEB> I remember just because I was doing other work during then as well [10:31] <YellowOnion> JEEB: I mean don't want to have to do 2 encodes and waste a bunch of disk space with lossless. [10:31] <JEEB> YellowOnion, well try setting -color_range for decoding [10:31] <JEEB> as in, before -i [10:31] <JEEB> whatever the value for full range is, that is [10:31] <YellowOnion> I can't find any docs on that setting anywhere, does it even exist? [10:32] <JEEB> sure exists http://ffmpeg.org/ffmpeg-all.html [10:33] <JEEB> and color_range 2 makes ffmpeg -i welp.file output yuvj420p(pc) [10:33] <JEEB> for a 4:2:0 sample [10:34] <YellowOnion> ahh sweet thanks [10:35] <YellowOnion> Still has grey blacks/looks washed out [10:37] <JEEB> well, I told you how to override the range, anything after that depends on what you do :P [10:41] <YellowOnion> I've tried a bunch of -vf format=yuv420p and -pix_fmt yuv420p in places and I just can't get it to output non-washed out colours [10:41] <active8> JJEB. configure says all the rtmp protocols are enabled. I noticed that for enabled indevs, jack is enabled, but not for outdevs. I'm not well versed in jack. Is there any reason I'd want ffmpeg to output to jack like it would to an rtmp server or whatever I might get itchy to try 8) ? [10:45] <JEEB> I don't even know if there is a jack output avdevice :P And no idea [10:45] <YellowOnion> I can't think off the top of my head why you would want a outdev for jack [10:47] <active8> ok JEEB make is an epic fail [10:49] <active8> input_count and output_count are deprecated - just warnings. A whole slew of errors related to RTMP. I got the source from git://source.ffmpeg.org/ffmpeg . Was that not good? [10:51] <JEEB> errors sound like you've poked something the wrong way [10:51] <JEEB> the source code in the git repo should be good at most times [10:52] <JEEB> you can see it being tested on various systems @ http://fate.ffmpeg.org/ [10:52] <active8> poked? [10:52] <JEEB> simplify your configuration line and make sure any old things aren't there [10:52] <JEEB> make distclean [10:52] <JEEB> configure in a more simple way [10:53] <JEEB> for example, start with just ./configure which enables a basic LGPLv2 build [10:53] <JEEB> see that it finishes [10:53] <JEEB> (yes, that includes the internal RTMP stuff) [10:53] <JEEB> and then go onwards from that :P [10:54] <active8> crap. I think I found something i forgot to unpoke [10:57] <YellowOnion> JEEB: well its not pretty but it works: http://pastebin.com/ZWH4mC7t [10:59] <JEEB> YellowOnion, that converts the thing to full range first (pix_fmt after -i), then you feed that to another instance which filters like crazy and either does nothing or converts back to limited range depending on how the second instance reads the input :P [10:59] <Mavrik> JEEB, thanks for correction :) [11:00] <JEEB> which really doesn't sound like the input was full range, unless swscale does very weird things on the first part. Which is always possible, after all it _is_ swscale [11:03] <YellowOnion> JEEB: on the original file played in VLC, the starting scene fades in from black, the back values in rgb are 12,16,12, and the entire thing looks washed out during the live action stuff. [11:04] <YellowOnion> specifying -pix_fmt after (before doesn't work) seems to fix the colors (though I though pix_fmt was suppose to convert) [11:05] <JEEB> yes, before doesn't work since you're not reading raw pictures [11:05] <JEEB> which is why there is -color_range [11:05] <JEEB> and -pix_fmt is /supposed/ to convert [11:05] <JEEB> swscale is a pile of voodoo poo-poo so you can never know what exactly it does, but I'm pretty sure that widens the range [11:06] <JEEB> if you actually get a different result from ffmpeg -i welp -pix_fmt yuvj420p than from ffmpeg -color_range 2 -i welp when piping to the next thing, then you know that it's converting [11:11] <YellowOnion> JEEB: well specifying -pix_fmt yuvj420p gives me a yuvj420p stream with correct colors, and -color_range 2 didn't improve on the situation. [11:12] <JEEB> in all theory that should be converting though, so the problem then was not what you were originally saying [11:13] <JEEB> also look at what I actually asked [11:49] <active8> YellowOnion: thanks for the input on jack [11:51] <active8> JEEB: thank you! Success. changed the prefix to my build dir and it's all good. have more formats, codecs and protocols than ever. Next time, I'm pouring the caffeine into the compiler instead of my stomach [11:53] <active8> incidentally, the poked pork was forgetting to remove the --enable-librtmp bit [14:53] <lkiesow> Trying to create a video out of two still images using: [14:53] <lkiesow> ffmpeg -y -r 1/20 -i s%1d.jpg -c:v libx264 -filter:v fps=1 -pix_fmt yuv420p out.mp4 [14:53] <lkiesow> Problem: The second image is displayed only one second, not 20. Any idea? [14:53] <lkiesow> FFmpeg output: http://fpaste.org/72713/39100359/ [16:50] <thebombzen> lkiesow: try using the setpts filter [16:50] <thebombzen> as in -filter:v setpts=PTS*20 [16:51] <thebombzen> wait... that might not work [16:51] <thebombzen> ignore that [17:14] <lkiesow> thebombzen: For now I just duplicated the last image and cut the vide using -t [17:14] <lkiesow> Not a nice workaround, but did it :) [17:40] <Orbixx> Is there a video editing suite based on ffmpeg? [17:40] <Orbixx> Like GUI [17:40] <Orbixx> Cutting, merging, etc [17:41] <thebombzen> On Linux you can use kdenlive, but I don't know if it cuts (etc.) with avfilter [17:41] <thebombzen> also that sucks in the KDE libs which you may or may not want [17:42] <thebombzen> I do know that it has an FFmpeg decoder/encoder plugin, so it at least has that [17:45] <jnvsor> Orbixx: Kdenlive uses mlt which is partially based on ffmpeg libs - Blender does user ffmpeg libs mainly [17:46] <Logicgate> hey guys, libfaac doesn't support the specified bitrate, using 96kbit/s instead [17:47] <Logicgate> it "hangs" ffmpeg completely [17:48] <Logicgate> http://pastebin.com/uMKdY5Jj [17:48] <Logicgate> that's the full output [17:49] <Logicgate> will specifying the audio encoding flags fix the issue? [17:50] <sacarasc> Try adding -c:a copy [17:52] <Logicgate> still hangs [17:53] <Logicgate> when i say "hangs". It takes 100% cpu and encodes very slowly [17:54] <sacarasc> That's pretty normal. [17:54] <sacarasc> Depending on CPU. [17:54] <Logicgate> nah, the video is 814kb [17:54] <Logicgate> All other videos don't hang. [17:54] <Logicgate> Takes 1s to reencode other videos. [17:55] <Logicgate> Just this one video [17:55] <Logicgate> i can provide you with the video if you'd like to see [17:55] <Logicgate> weirdly it says audio bitrate is 35kbps [18:02] <Logicgate> appending -vsync 2 solved the issue [18:30] <DeadSix27> when using ffprobe on http sources, and using a short probesize, will it only request that size, or the whole file? [20:51] <Maverick|MSG> if I have an avi that ffmpeg outputs into an mp4 [20:51] <Maverick|MSG> but it only ouputs 0:30 to 0:60 [20:51] <Maverick|MSG> *outputs [20:52] <Maverick|MSG> it I then add audio to it how can I tell it to only add the audio from 0:30 to 0:60 [20:53] <llogan> Maverick|MSG: "but it only ouputs 0:30 to 0:60", as in you're experiencing an issue, or you're telling to ffmpeg to do that? [20:54] <Maverick|MSG> no no,that's on purpose [20:54] <Maverick|MSG> sorry, should have clarified [20:54] <llogan> you could probably use the atrim filter [20:54] <Maverick|MSG> that'll skip the first 30 seconds of the audio? [20:57] <llogan> Maverick|MSG: http://superuser.com/a/689992/110524 [20:57] <Maverick|MSG> thanks llogan [21:00] <Maverick|MSG> just for my sanity, if my mp4 is 30 seconds long and the audio I add into it is longer than 20 seconds will the audio get cut off when the video ends? [21:00] <Maverick|MSG> *longer than 30 seconds [21:00] <llogan> do you want it to do that? [21:00] <Maverick|MSG> yeah [21:01] <Maverick|MSG> that'll happen by default? [21:01] <Maverick|MSG> or will the resulting mp4 output be as long as the longest input? [21:01] <llogan> if you're using concat filter then i'm not sure [21:01] <llogan> otherwise see -shortest [21:02] <Maverick|MSG> ok [21:02] <llogan> does the input with video already contain audio? are you wanting to add another audio stream, or combine it with the existing audio? [21:03] <Maverick|MSG> there is no audio on the video stream to start with [21:03] <Maverick|MSG> (or if there is it should be replaced by the audio stream of the second input) [21:05] <llogan> also ive seen people claim that -itsoffset worked for them in this case, but i've never used it [21:05] <llogan> so i guess you have several methods to try [21:05] <Maverick|MSG> oh, yeah, i didn't think about itsoffet [21:31] <ChocolateArmpits> Can anyone help me understand why would P frames of a baseline h264 video be decoded to a blocky mess on a tablet when even a smartphone with less capable processor seems to decode it visually better ? [21:32] <JEEB> I've had a samsung phone fail at life regarding its HW decoding ASIC [21:32] <JEEB> so if both use ASICs [21:33] <JEEB> it could be a problem with one of them just being borked [21:44] <ChocolateArmpits> I will most likely install android VLC and see how that goes [21:45] <ChocolateArmpits> Because now it seems my only choice would be to reduce GOP to 8 or lower when framerate is 25 [23:03] <vl4kn0> Hi, I'm using ffmpeg api in my program and it fails on one video (one from ~20) with arithmetic error (floating point exception). gdb backtrack shows it occurs on function ff_mpeg4_set_direct_mv called from avcodec_decode_video2. What could possibly be wrong? [23:35] <chronic1> Hello [23:35] <spaam> hello and welcome to #ffmpeg chronic1 [23:35] <chronic1> I'm trying to size a new HTPC, and have a question about transcoding. What kind of cpu overhead is involved with transcoding only a container? [23:39] <llogan> chronic1: are you talking about re-muxing? [23:41] <chronic1> llogan: Maybe. Pardon my ignorance.... [23:41] <chronic1> I have a file called aFile.mkv, and it is 264 video. [23:42] <chronic1> I have a device (chromecast) which can't handle mkv containers, and I need to change the container into something supported. [23:43] <Hello71> that's not what transcoding means [23:43] <Hello71> ffmpeg input.mkv -c copy output.whatever [23:44] <chronic1> Is the situation I'm talking about called re-muxing? [23:44] <chronic1> And would transcoding be changing something from mpeg2 to mpeg4? [23:45] <Hello71> pretty much. [23:45] <Hello71> try google. [23:45] <llogan> that's usually not a helpful answer [23:45] <llogan> chronic1: http://ffmpeg.org/ffmpeg.html#Stream-copy [23:50] <chronic1> Nice. This sounds like it should have very little impact on a system! [23:52] <llogan> and i would call converting from one video format to another "re-encoding" since, depending on who you ask, "transcoding" may imply that information from the source bitstream, such as motion vectors, may be (re-)used [00:00] --- Thu Jan 30 2014

1 0

ffmpeg-devel.log.20140128
by burek 29 Jan '14

29 Jan '14

[00:04] <cone-319> ffmpeg.git 03Lukasz Marek 07master:7151411b9cf7: lavd: add avdevice_app_to_dev_control_message API [00:05] <cone-319> ffmpeg.git 03Lukasz Marek 07master:102bd641687a: lavd: add avdevice_dev_to_app_control_message API [00:05] <cone-319> ffmpeg.git 03Lukasz Marek 07master:ded6b3af41cd: lavd: add opengl device [00:05] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:c94ed2a72964: Merge remote-tracking branch 'lukaszmluki/master' [00:19] <BBB> ubitux: oh it's slower? ok, commit original then i guess [00:19] <BBB> ubitux: thanks for testing anyway [00:20] <BBB> ubitux: the not-less instructions is kinda weird, I think it's just ordering being off [00:21] <BBB> that is, the qdq step should be unnecessary [00:21] <BBB> if you need a qdq, it means original input ordering was wrong [00:21] <BBB> we can look into that some other time [00:21] <BBB> it's not urgent [01:27] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:2a9c50798b79: avcodec/huffyuv: dont depend on bitstream_bpp having a specific value for version>2 [07:24] <ubitux> BBB: well this is basically the same has a 8x8B transpose [07:24] <ubitux> unless you know a way to simplify a 8x8B transpose, i don't know how we could make this simpler [07:24] <ubitux> s/has/as/ [07:37] <cone-125> ffmpeg.git 03Clément BSsch 07master:222c46c53108: x86/vp9lpf: add ff_vp9_loop_filter_[vh]_88_16_{ssse3,avx}. [07:37] <ubitux> BBB: feel free to try something ^ [07:44] <ubitux> BBB: fuzzed7.ivf available btw [09:10] <ubitux> cbsrobot: ping [09:14] <cbsrobot> ubitux: pong [09:15] <ubitux> cbsrobot: in the 2nd ebur128 patch, you removed a \n in the logging [09:15] <ubitux> why? [09:15] <cbsrobot> so the true peak can be added without having the context printed [09:15] <cbsrobot> but it's added at the end again [09:18] <ubitux> mmh [09:18] <ubitux> cbsrobot: but if the peaks are not enabled, the stdout is broken [09:18] <ubitux> no? [09:18] <ubitux> ah, no indeed it's at the end [09:18] <cbsrobot> well there is a "\n" at the end [09:18] <ubitux> my bad [09:19] <ubitux> i need to fix the FFLIBS thing btw [09:19] <ubitux> and it should be ok [09:19] <ubitux> cbsrobot: i assume you tested it properly? :p [09:27] <cbsrobot> ubitux: I could still run the ebu testset on it .... [09:35] <ubitux> cbsrobot: could be nice [09:35] <ubitux> Compnn: aren't you maintaining samples.ffmpeg.org? [09:36] <cbsrobot> well - ofc they don't test the true peak metering .... [09:44] <ubitux> meh, ped1080p.webm does not exist anymore :( [09:50] <BBB> ubitux: well I was thinking of the end-transpose (not the start-one) [09:50] <BBB> ubitux: then you do just bw, wd and dq (not qdq) [09:51] <ubitux> aah. [09:51] <BBB> at that point, I think "P7" and "P6" is in lo/hi m0, "P5" and "P4" in lo/hi m1 [09:51] <BBB> etc. [09:52] <BBB> I'm not sure it works for the start, thinking about it I think it doesn't actually [09:52] <BBB> (which I probably should've thought of before I told you all of this) [09:52] <ubitux> it's fine :) [09:53] <ubitux> BBB: fuzzed7 crashes only with threading btw [09:53] <BBB> ;( [09:53] <BBB> ok [09:54] <ubitux> (it triggers the large swscale error otherwise) [09:54] <BBB> I thought I ul'ed ped1080p.webm to incoming? [09:54] <BBB> need me to ul it again? [09:55] <ubitux> yeah but it seems it's not there anymore :( [09:55] <ubitux> it's fine, i have it @home [09:55] <ubitux> though, it should probably be uploaded along with etv5k.webm in the samples directory [09:56] <BBB> re-ul'ed [09:56] <ubitux> thanks :) [09:56] <BBB> yeah I agree, plus any other samples we want to use for general profiling in the future [09:56] <BBB> I guess this + etv5k is enough for now [10:01] <BBB> I started writing simd for intra pred btw [10:01] <BBB> no idea whether it helps any, but I was bored [10:01] <ubitux> gonna push the sse patch from james almer [10:02] <BBB> yeah [10:02] <BBB> ok I'm gonna try to sleep also [10:02] <ubitux> can you confirm punpckl{bw,qdq} and pshuf[hl]w are indeed available in sse? [10:02] <BBB> yeah they are [10:02] <ubitux> cool ok [10:02] <BBB> ssse3 introduces things like palignr, pshufb, pmaddubsw [10:02] <BBB> most "generic" stuff is sse2 [10:02] Action: BBB zzz [10:02] <ubitux> 'night :) [10:03] <cone-125> ffmpeg.git 03James Almer 07master:644c32ea4b80: x86/vp9lpf: add ff_vp9_loop_filter_[vh]_88_16_sse2() [10:08] <cbsrobot> ubitux: compared to http://www.kvraudio.com/forum/viewtopic.php?f=6&t=354995 I get http://pastebin.com/Sxw5R4cV , which is in the +/- 0.3 range of other implementations [10:09] <ubitux> ok [14:16] <ubitux> BBB: so, do you want me to do some more lpf functions? [14:16] <ubitux> like the 8/4? [14:16] <BBB> yes please [14:16] <ubitux> or i can start trying to do some ARM? [14:16] <ubitux> ok [14:16] <BBB> 48/84 should be really trivial now that 88 is done [14:16] <BBB> it's basically 88 with a fixed zeromask for filter6 for the 4-half [14:17] <BBB> 44 is a little bit more work if you want to erase filter6 altogether (you probably do) for more runtime savings [14:45] <Daemon404> [13:16] <@ubitux> or i can start trying to do some ARM? <-- nah, im sure phones will get hw vp9 decoders Any Day Now [14:45] <Daemon404> just like vp8 did... wait [14:45] <Daemon404> oops. [14:47] <ubitux> having h264 hw decoder doesn't prevent ppl from writing h264 arm asm :p [14:47] <Daemon404> true [14:47] <JEEB> the vp9 hw reference design is pretty spanky [14:47] <JEEB> bigger than cortex a9 was it? [14:47] <Daemon404> lol really? [14:48] <ubitux> meanwhile [14:48] <ubitux> [~/src/ffmpeg]- ls libavcodec/x86/hevc* [14:48] <ubitux> zsh: no matches found: libavcodec/x86/hevc* [14:48] <ubitux> :( [14:48] <Daemon404> blame the french [14:48] <Daemon404> they wrote intrinsics for some reason [14:49] <nevcairiel> you're welcome to take over that task ubitux. :D [14:49] <ubitux> i'm busy helping BBB puting libvpx at shame [14:49] <Daemon404> thats not hard [14:50] Action: Daemon404 runs [14:50] <ubitux> well, they have some simd at least [14:50] <Daemon404> nah i meant it does a pretty good job of it on its own [14:50] <Daemon404> for !simd reasons [14:51] <mateo`> ubitux: do you have some kind of comparaison between libvpx and lavc ? [14:52] <ubitux> i didn't bench myself, but according to BBB we're now about 35% faster iirc [14:52] <Daemon404> already? :o [14:52] <mateo`> ubitux: nice ! [14:53] <Daemon404> ubitux, any idea how our MT compares? [14:53] <Daemon404> or is ffvp9 mt'd yet [14:53] <ubitux> it's mt'd [14:53] <ubitux> > already [14:53] <ubitux> well, we have about 3k lines of asm :p [14:57] <ubitux> i7-3520M, i'm decoding 1080p footage at 120 fps with 1 thread [14:57] <ubitux> and 250+ fps with 4 threads [14:57] <ubitux> but the sample is too short (3:30) [14:58] <ubitux> so it's hard to tell (it was constantly increasing) [14:58] <Daemon404> i was encoding some 4k samples with it [14:58] <Daemon404> but theyre only 600 frames [14:58] <ubitux> 5k frames here [15:13] <cone-490> ffmpeg.git 03Michael Niedermayer 07master:bb7a7111562b: avcodec/huffyuvenc: frame multi-threading support [16:11] <ubitux> the ogg patches from mathstuff are not yet pushed? [16:12] Action: ubitux is bored at the "[ffmpeg] NULL: Invalid packet" while listening to his webradio with mpv and wonder if that patchset would help [16:17] <wm4> ubitux: yes it would help [16:17] <wm4> I think he has to post a new iteration of patches still [16:19] <wm4> also, I think the chosen interface is indeed not so great (e.g. what happens if file-global metadata changes? ogg is just so messed up that it makes file global metadata stream local) [16:21] <ubitux> no idea [16:26] <wm4> why the crap does av_init_packet() not initialize all fields anyway? [16:26] <wm4> who knows how many users fell into this trap [16:26] <wm4> who thought it was a good idea? [16:27] <nevcairiel> its only really needed when you send a AVPacket to the decoders, so i guess someone though the only actual mandatory fields should be explicitly set [16:27] <nevcairiel> thought* [17:13] <michaelni> Anssi, any news about the HLS patches? anything others can help with ? also theres: a new hls pull req https://github.com/FFmpeg/FFmpeg/pull/55 [17:14] <Anssi> michaelni: just been very busy with other stuff lately :/ I hope to work on it later this week [17:15] <michaelni> Anssi, ok, great, no hurry [18:10] <cone-490> ffmpeg.git 03Lukasz Marek 07master:4115cd0e768f: doc/APIchanges: add avdevice_*_control_message functions [18:10] <cone-490> ffmpeg.git 03Lukasz Marek 07master:9ff2cc685bdb: MAINTAINERS: add myself as opengl_enc.c maintainer [18:10] <cone-490> ffmpeg.git 03Lukasz Marek 07master:406cb21b6365: doc/general: update device and protocol status [19:12] <cone-490> ffmpeg.git 03Mikael Finstad 07master:5846d8a91ebd: avformat/hls: Fix cookies and user agent with encrypted HLS streams [19:30] <bneff> I'm using ffmpeg-1.2.5, and I'm getting a consistent crash with av_packet_get_side_data. Is this the appropriate place to help troubleshoot? [20:52] <michaelni> bneff, what are you doing to get it to crash ? [20:52] <michaelni> also is this a regression ? [22:00] <cone-490> ffmpeg.git 03Michael Niedermayer 07master:3e41e747d654: avfilter/vf_colormatrix: Support using the source AVFrame colorspace if none is specified [22:01] <cone-490> ffmpeg.git 03Michael Niedermayer 07master:b50efe85eaf2: avfilter/vf_colormatrix: update output AVFrame colorspace [22:40] <bneff> michaelni: I started with ffmpeg 1.2.0, and duplicated it on 1.2.5 so I'm not sure if this is a regression. I'm calling avcodec_decode_video2(), and passing it an AVPacket that i set .data and .size on. Eventually that calls av_packet_get_side_data, and passed that an AVPacket *, but that is NULL [22:41] <nevcairiel> did you init the AVPacket first, with av_init_packet? [22:42] <bneff> nevcairiel: yes. [22:42] <bneff> My program runs for quite some time e.g. 40 minutes of decode / encode, but then this same crash is triggered [22:43] <bneff> on the 1.2.5 source, in libavcodec/avpacket.c on line 219 it tries to do pkt->side_data_elems, but pkt is NULL [22:45] <michaelni> why is pkt NULL? [22:46] <bneff> I don't know, I don't pass that in. That is all done inside avcodec_decode_video2() [22:46] <michaelni> well, so do you have a backtrace and how to reproduce it [22:46] <michaelni> ? [22:46] <bneff> I have a backtrace [22:47] <bneff> and I've been poking around in gdb, but I just don't know about about ffmpeg to know what it should be [22:47] <bneff> in terms of how to reproduce, I do not have that, sorry [22:50] <llogan> feel free to start adding ideas and stuff [22:52] <bneff> here is the backtrace: http://pastebin.com/q1GSpuZ7 [00:00] --- Wed Jan 29 2014

1 0

ffmpeg.log.20140128
by burek 29 Jan '14

29 Jan '14

[00:38] <madmouse> hi all, I have compiled ffmpeg from source on Linux Mint (but it seem I have the compiled version and the other avconv version), [00:38] <madmouse> how do I get rid of the avconv version or set the path to use the compiled one [00:38] <madmouse> from ~/ffmpeg_sources/ffmpeg I get : ffmpeg version git-2014-01-27-c94ed2a Copyright (c) 2000-2014 the FFmpeg developers [00:39] <madmouse> from e.g. ~/kde/build/amarok > ffmpeg I get : ffmpeg version 0.8.9-6:0.8.9-0ubuntu0.13.10.1, Copyright (c) 2000-2013 the Libav developers [00:45] <saste> madmouse, http://trac.ffmpeg.org/wiki/GenericCompilationGuide#Installpath [00:45] <madmouse> thanks sastelet me go read [00:45] <madmouse> thanks saste let me go read [00:46] <saste> madmouse, in other words you need to install the package or use a custom PATH [00:47] <Tawre> hopefully someone won't bite my head off for this: i encoded some images into a video with [00:48] <Tawre> ffmpeg -r 30 -i image-%3d.png -vcodec libx264 out.mp4 [00:48] <Tawre> it works fine in standalone video players i have but it won't work for html5 video players in chrome or firefox. should it not work or am i doing something wrong? [00:50] Action: saste bites the head off of tawre [00:50] <saste> Tawre, -pix_fmt yuv420p? [00:51] <Tawre> okay, some old version of gomplayer won't show it correctly, but all the rest i tried worked fine [00:51] <Tawre> saste, i didn't touch anything like that [00:52] <madmouse> thanks saste adding the path to the compiled ~/ffmpeg_sources/ffmpeg PATH env variable [00:53] <saste> Tawre, you probably should, since ffmpeg will generate yuv444p in some cases, which is not supported by many players [00:53] <saste> btw current version of ffmpeg warns you about that [00:54] <saste> madmouse, i'm glad the guide i wrote is useful [00:54] <madmouse> :-) [00:54] <Tawre> saste, thank you a lot [00:56] <Tawre> saste, i grabbed the latest compiled windows x64 binary - i either didn't notice or it wasn't there [00:56] <Tawre> but i might've just not noticed; anyways thanks a lot! works now [01:27] <madmouse> saste: I must be stupid or something [01:27] <madmouse> I added [01:27] <madmouse> export AVFORMAT_LIBRARIES=$HOME/ffmpeg_build/lib/ [01:27] <madmouse> export AVFORMAT_INCLUDE_DIRS=$HOME/ffmpeg_build/include/ [01:28] <madmouse> to my .bashrc [01:28] <madmouse> and [01:28] <madmouse> export PATH=$HOME/ffmpeg_build:$PATH [01:28] <saste> AVFORMAT_LIBRARIES what's this?? [01:29] <madmouse> ah sorry yeah I am trying to compile Amarok (that is the end goal) [01:29] <madmouse> but want to compile ffmpeg for Amarok and general use [01:29] <saste> you need to reload your bashrc with . .bashrc [01:29] <madmouse> aaah [01:29] <saste> don't know nothing about amarok [01:33] <madmouse> grr let me reboot I suspect the bashrc not relaoding correct [01:33] <madmouse> tnx for help saste [01:34] Action: saste going to sleep [09:34] <thoonai> hello. does I can use ffmpeg to encode mpeg2 on openCL graphic cards? [09:36] <Ris> could someone help with this error code http://pastebin.com/Us9AbQS5 [09:37] <thoonai> I have a project which needs to have 12++ streams encoded in mpeg2. so I'm not sure if to buy an AMD octa core or a decent graphics card [09:52] <thoonai> gotta go [11:36] <sspiff> is there a way to extract exactly one frame from every video stream in a container? [11:37] <sspiff> I "ffmpeg -i samples/trace_GbE2_03.cap -map 0:v -f image2 -frames:v 1 test-%03d.jpeg", but that just does one frame overall [11:45] <relaxed> sspiff: with scripting [11:46] <sspiff> relaxed: alright, that's what I'm doing [11:46] <sspiff> just figured I'd ask in case there was a simple flag I could pass [11:47] <relaxed> Not that I'm aware of [11:47] <sspiff> then I'll just continue down this road [11:57] <relaxed> sspiff: did you get it? [11:58] <Ris> could someone help with this error code http://pastebin.com/Us9AbQS5 [12:02] <relaxed> Ris: what is yo.mp4 doing there? [12:02] <Ris> do i need it there [12:03] <sspiff> relaxed: I have a bash script that calls ffmpeg and works fine on my samples [12:03] <sspiff> no magic flag as of yet [12:03] <Ris> took it out give me the same error [12:03] <relaxed> yeah, I did it with awk [12:04] <relaxed> Ris: you have ffmpeg twice [12:06] <Ris> opps [12:08] <Ris> http://cast7.eu/index/stream/name/cast101 [12:08] <Ris> no video [12:08] <Ris> but good audio [19:12] <ChocolateArmpits> Can it be said that a picture resize 2 times both vertically and horizontally smaller is faster than, let's say, 1.5 times both horizontally and vertically ? [19:13] <ChocolateArmpits> Or is the operation really dependent on the resize filter? [19:13] <ChocolateArmpits> that is operation speed [19:25] <clever> ChocolateArmpits: i would think that resizing by an int (2x 3x) would be faster then a float (1.5x), since it can just copy pixels, rather then blend [19:26] <clever> but you also have to consider the size of the output image and the bandwidth that will take up [19:40] <ChocolateArmpits> clever, I had in mind resize operation only [19:43] <ChocolateArmpits> So if we agree with that, can we say that a resize 1.5 times could be faster than 1.38 times? Or will we see diminishing returns if we go deeper after the decimal point? [19:52] <clever> i would think that 1.38 would use more cpu then 1.5, since the blending is more complex [19:52] <clever> 1.5 bigger is 2 pixels in 3 pixels out, so its a rather simple blend [19:53] <clever> but 1.5x would use more time in the final memcpy of the frame [19:53] <clever> and the encoding (yuv, rgb) also complicates things [19:53] <clever> simplest answer, measure it! [19:53] <ChocolateArmpits> I will most obviously [19:54] <ChocolateArmpits> Just want to theoretically ponder before that [19:54] <clever> if you make it 1.5 times bigger, it would take a 2x2 pixel input and create a 3x3 pixel output [19:55] <clever> so it would have to blend the 4 pixels together end create a new grid of 9 pixels [19:55] <clever> but 1.38x bigger would be more complex to blend and possibly take more cpu [19:55] <clever> but it depends on how it implements the blending [19:56] <ChocolateArmpits> the filter you mean? [19:56] <clever> yeah [19:56] <bneff> I'm using ffmpeg-1.2.5, and I'm getting a consistent crash with av_packet_get_side_data. Is this the appropriate place to help troubleshoot? [20:01] <llogan> bneff: does it also crash using ffmpeg from git master? [20:02] <relaxed> bneff: http://johnvansickle.com/ffmpeg/ [20:03] <bneff> llogan: I'll check. relaxed: thx [20:04] <relaxed> Umm, those are my static builds. I doubt they'll be useful to you. [20:05] <llogan> relax, don't worry, have a homebrew. [20:06] <relaxed> I love beer [20:06] <bneff> relaxed: Ok, I wasn't sure why you sent it, but I was just being nice haha [20:07] <relaxed> it dawned on me after pasting it... ;) [22:19] <fundies> can ffmpeg rip a vobsub with an idx too? [00:00] --- Wed Jan 29 2014

1 0

ffmpeg-devel.log.20140127
by burek 28 Jan '14

28 Jan '14

[00:15] <cone-907> ffmpeg.git 03Loren Merritt 07master:b7d0d10a1d54: x86inc: Speed up assembling with Yasm [00:15] <cone-907> ffmpeg.git 03Michael Niedermayer 07master:17e7048d30e5: Merge commit 'b7d0d10a1d54073501b728dbe166a32e2b7b26f1' [00:40] <Rodeo> cbsrobot: erm, pong [02:22] <cone-907> ffmpeg.git 03Michael Niedermayer 07master:7cf8918b0df7: avcodec/huffyuv: update years in copyright [02:22] <cone-907> ffmpeg.git 03Michael Niedermayer 07master:6369766f015f: avcodec/huffyuv: support gbrp9/10/12/14 [08:24] <Keestu> i m building ffmpeg in ubuntu 12.04, and First i built yasm-1.2.0, and tring to build x264, and for which i get the error ""No working C compiler found."". To refer the yasm-1.2.0 library i have used --extra-cflags, and --extra-ldflags options. [08:26] <JEEB> yasm is not a library, it's a binary that's needed [08:26] <JEEB> or well, it could also have a library but that's not needed [08:27] <JEEB> you only need to be able to call yasm --version and get the 1.2.0 one [08:27] <JEEB> as for the no working c compiler thing, check config.log :P [08:28] <Keestu> JEEB, thanks. yasm 1.1.0.2352 is installed version, but x264 requiers minimum of 1.2.0 of yasm. [08:29] <Keestu> hence wanted to refer to manually built yasm. :) [08:29] <Keestu> i still can do make install into system path, but i don't want to do that. :) [08:32] <JEEB> 1) configure yasm to some --prefix (for example --prefix=/home/myusername/ownapps/ ) 2) build 3) make install to copy the things to their places 4) export PATH=/your/prefix/bin:${PATH} [08:32] <JEEB> this should lead you to be able to call the new yasm with just yasm [08:33] <JEEB> if you don't want it to be in the PATH at all then I'm afraid you'll have to have some extra fun with that :P [08:33] <JEEB> setting the PATH in a single terminal in my opinion is nothing bad, though [08:34] <Keestu> JEEB, that means x264 only expects the binary of yasm not the dev library ? [08:34] <JEEB> yes [08:34] <JEEB> only the actual assembler is needed [08:35] <Keestu> I got the below error: Found yasm 1.1.0.2352 [08:35] <Keestu> Minimum version is yasm-1.2.0 [08:35] <JEEB> yes [08:35] <JEEB> because the assembler is too old [08:36] <Keestu> hence i used --extra-cflags, and --extra-ldflags to point to the 'prefix' location, where in i got the error no working c compiler found. [08:36] <JEEB> it most probably would tell you it needs libsomething if it wanted the library [08:36] <Keestu> JEEB, true, i set to PATH to prefixed bin directory of yasm. [08:37] <Keestu> Looks like it need libyasm.a file. [08:37] <JEEB> no... it should not [08:37] <JEEB> and in many cases that doesn't change the actual currently used yasm, if you do `which yasm` you should see which yasm is getting picked up :P [08:37] <JEEB> (in that case you might have to set the PATH in bashrc or something and open a new terminal) [08:45] <Keestu> JEEB, oops. shame on me. it works now i did PATH=$PATH:<mypath> rather than PATH=<MYPATH>:PATH :). [08:45] <Keestu> :) [08:46] <Keestu> thanks JEEB. [09:53] <kierank> "This is useful if you need only to read a video/samples buffer, without to fetch it" ? [10:33] <Keestu> dear all, how can i map ffpmeg error code with message ? for example return error code of avformat_open_input,? Kindly suggest. [11:13] <Rodeo> cbsrobot: pong #2, if you're around [12:40] <cbsrobot> Rodeo: still around ? [12:40] <Rodeo> yes [12:41] <cbsrobot> about the fdk_aac channel layout [12:41] <cbsrobot> see: http://pastebin.com/XpNVDCJQ [12:42] <cbsrobot> does that seem correct to you ? [12:42] <cbsrobot> I guess 7.1 is really MODE_7_1_REAR_SURROUND [12:42] <cbsrobot> but MODE_1_2_2_2_1 / MODE_7_1_FRONT_CENTER seem to be 7.1wide [12:43] <Rodeo> I would say so, except for consistency [12:43] <Rodeo> look at 5.0 and 5.1, they already use back channels, not sides [12:43] <cbsrobot> I compared channel_layout from ffmeg with: https://github.com/mstorsjo/fdk-aac/commit/fa3eba16446cc8f2f5e2dfc20d86a49d… [12:43] <j-b> don't use 7.1 :) [12:45] <Rodeo> either is fine though, but MODE_7_1_REAR_SURROUND should definitely be 7.1, not wide or wide back [12:45] <Rodeo> also, did you see my comment about MODE_1_2_2_2_1 vs. MODE_7_1_FRONT_CENTER? [12:49] <cbsrobot> sure, but how to deal with it ? [12:51] <Rodeo> make a choice [12:52] <Rodeo> i.e. do you want to use the official AAC channel config 7, or do you want channel_config = 0 and write a PCE on purpose [12:53] <nevcairiel> the official 7.1 channel config is stupid, it has two sets of front speakers, instead of the more common front, surround, back model [12:55] <cbsrobot> I have no specific requirement [12:56] <cbsrobot> I don't own a 7.1 setup - I just needed to test some 7.1 files with a soundcard [12:57] <Rodeo> nevcairiel: that's not the point, we're talking about only one layout [12:57] <Rodeo> but two ways to indicate it, one using a channel_config defined in the spec., vs using a PCE (can't remember what it means just now, but basically it describes the layout instead of using a predefined config) [12:58] <Rodeo> Program Config Element, maybe [13:08] <cbsrobot> so a new private option could be added instead of a new channel_layout [13:19] <Rodeo> not sure how that would work, TBH [13:26] <cbsrobot> where can I find information about pce ? [13:34] <av500> ask peloverde [13:36] <cone-319> ffmpeg.git 03Lukasz Marek 07master:9d087ab5ef15: ffplay: remove redundant prototype [14:01] <Rodeo> cbsrobot: AAC spec would me my first guess [14:28] <cone-319> ffmpeg.git 03Rainer Hochecker 07master:bceeccc648ba: dxva2: bump maximum number of slieces for mpeg2 [15:49] <cone-319> ffmpeg.git 03Martin Storsjö 07release/1.2:89c917fcd92c: rtpdec_asf: Copy the need_parsing field from the chained demuxer [15:49] <cone-319> ffmpeg.git 03Martin Storsjö 07release/2.1:d0e0329e9d3d: rtpdec_asf: Copy the need_parsing field from the chained demuxer [16:20] <cone-319> ffmpeg.git 03Carl Eugen Hoyos 07master:05e5bb6107b9: Fix decoding of some 8 < bpc < 16 signed j2k samples with libopenjpeg. [19:10] <kurosu_> BBB / ubitux: regarding vp9 loop filter: I guess there are different filters of different lengths. What are these lengths ? [19:11] <ubitux> 2,4,6,14 [19:13] <kurosu_> ubitux: 14 !? that must be a pain... Did you have to implement some kind of transpose or is it limited to 8xN blocks ? [19:14] <ubitux> there is a 16x16 transpose [19:15] <ubitux> filter6() and filter14() are actually pretty fun to write [19:15] <kurosu_> ubitux: from vp9dsp.c it seems the filter size is decided per border, right? if such is the case, do you think it would be possible to use a transpose smaller than 16x16? already done maybe? [19:15] <ubitux> filter2/4 are same as vp8 and honestly that was fucking painful because of the weird signess all over [19:15] <kurosu_> I guess you are calling twice this function for 32xN partitions [19:15] <ubitux> i don't really know about the caller [19:16] <kurosu_> actually the dsp function works on chunk of 8 pixels, so I do have my reply [19:18] <ubitux> mmh i think i'll push the simplifications before adding 88... [19:19] <kurosu_> BBB: do you know the gain of this 14taps filter over a 6-long one ? [19:19] <ubitux> kurosu_: https://github.com/ubitux/FFmpeg/blob/vp9-simd/libavcodec/x86/vp9lpf.asm#L5… [19:19] <ubitux> filter14() ^ [19:19] <ubitux> it's basically just the FILTER_{INIT,UPDATE} [19:20] <ubitux> the tricky part is the re-use of registers [19:20] <kurosu_> ubitux: do you know how long your asm implementation of filter14 and filter6 are taking respectively ? [19:20] <ubitux> mmh [19:22] <ubitux> full block is ~3000 decicycles, without filter14 it's about ~1900 decicycles [19:22] <ubitux> feel free to bench :p [19:22] <kurosu_> I'm just trying to figure the complexity vs gain tradeoff here, which might not be the best [19:23] <kurosu_> ubitux: it's been so long since my last pull, don't think I will any time soon [20:30] <llogan> beastd: can you take a look at https://trac.ffmpeg.org/ticket/3352 [20:31] <beastd> llogan: ah. i am having a look. [20:38] <llogan> i wish roger would proof read first... [22:04] <ubitux> BBB: ping [22:05] <ubitux> BBB: so i did the transpose differently: https://github.com/ubitux/FFmpeg/commit/4d126ce878b1a33455de9b38397473168bc… [22:06] <ubitux> it's basically a 8x8 transpose, but it's working on full width (16 instead of 8) [22:06] <ubitux> i don't have less instructions though [22:06] <ubitux> what did i miss? :p [22:11] <Skyler_> that looks like a nice solution [22:12] <ubitux> it doesn't look better though [22:12] <ubitux> it's probably slower actually but i didn't bench [22:15] <ubitux> well i guess i'll start pushing the beginning of the patchset meanwhile [22:15] <llogan> now everyone can watch me flail around with regex shenanigans [22:16] Action: llogan starts playing "Yackety Sax" [22:17] <ubitux> llogan: https://pbs.twimg.com/media/Be72GYUCYAAM7Vq.png:large ? [22:19] <llogan> ubitux: one clue is simply ".*" [22:20] <llogan> you'll make a soduku player cry [22:22] <nevcairiel> there is way too many stars in that thing! [22:43] <cone-319> ffmpeg.git 03Clément BSsch 07master:5d144086cc55: x86/vp9lpf: faster P7..Q7 accesses. [22:43] <cone-319> ffmpeg.git 03Clément BSsch 07master:315b4775adf8: x86/vp9lpf: refactor v/h using common macros for P7 to Q7. [22:43] <cone-319> ffmpeg.git 03Clément BSsch 07master:822385d77598: x86/vp9lpf: add a preload system in FILTER_UPDATE. [23:06] <ubitux> heh, strangely it's a bit faster [23:06] <ubitux> i guess i'll go for this [23:07] <ubitux> ah my bad, it's slower, switched the 2 results [23:08] <ubitux> (2738 -> 2808) [23:13] <ubitux> BBB: i'll push https://github.com/ubitux/FFmpeg/commit/699b25ce73514da89c0b168347eeecf5d38… soon [23:14] <ubitux> https://github.com/ubitux/FFmpeg/commit/c156d99c16fa1b39f8c88ba038bbd14df16… make it a bit slower [23:44] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:a38842120add: avcodec/libfdk-aacenc: change MODE_7_1_REAR_SURROUND to map to AV_CH_LAYOUT_7POINT1 [23:44] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:673ce8e46ae2: avcodec/libfdk-aacenc: change MODE_7_1_FRONT_CENTER to map to AV_CH_LAYOUT_7POINT1_WIDE_BACK [00:00] --- Tue Jan 28 2014

1 0

ffmpeg.log.20140127
by burek 28 Jan '14

28 Jan '14

[00:00] <lkiesow> Hello71: If you have a look at the aacenc_lib.h in the master branch of libfdk-aac you will find [00:00] <Hello71> I figured that out. [00:00] <lkiesow> AACENCODER_LIB_VL0 3, AACENCODER_LIB_VL1 4 and AACENCODER_LIB_VL2 12 [00:01] <Hello71> https://bugs.gentoo.org/show_bug.cgi?id=499402 [00:07] <lkiesow> So basically, the Error message is a bit confusion but there should be no problem if you have installed fdk-aac v0.1.3 as it already has the internal version number [00:07] <lkiesow> &which means that I sould update it for my systems as well :) [00:08] <Hello71> wait, what [00:08] <Hello71> 0.1.3 is 3.4.12 [00:08] <Hello71> seems legit [00:10] <lkiesow> checkout v0.1.3 and have a look into include/fdk-aac/aacenc_lib.h :) [00:10] <Hello71> ah. [00:10] <Hello71> I don't have it cloned [00:10] <Hello71> sourceforge git ui is !@#$ [00:11] <lkiesow> git clone git://git.code.sf.net/p/opencore-amr/fdk-aac [00:11] <Hello71> too much work [00:13] <lkiesow> Then use ffmpeg 2.1.3. That works [00:20] <Hello71> emerge =fdk-aac-0.1.3 [00:21] <NoZero> any help on this?... [00:21] <NoZero> 1>ffmpegDecode.obj : error LNK2028: unresolved token (0A000018) "extern "C" void __cdecl avcodec_free_frame(struct AVFrame * *)" (?avcodec_free_frame@@$$J0YAXPAPAUAVFrame@@@Z) referenced in function "private: int __thiscall FFmpegDecoder::DecodeAudio(int,struct AVPacket *,unsigned char *,unsigned int)" (?DecodeAudio@FFmpegDecoder@@$$FAAEHHPAUAVPacket@@PAEI@Z) [00:21] <Hello71> solution: use linux [00:21] <NoZero> I need to write a Windows software [00:22] <NoZero> 1>Linking... [00:22] <NoZero> 1>ffmpegDecode.obj : warning LNK4248: unresolved typeref token (01000013) for 'SwsContext'; image may not run [02:29] <NoZero> ok fflogger [02:29] <NoZero> ty [02:53] <Kronusdark> does anyone know if there is a way to select an embedded SSA subtitle and burn in one line? [02:54] <Kronusdark> google hasnt been helpful this evening [02:55] <DeadSix27> i just extract it and burn it using the ass filter. [02:55] <DeadSix27> to handle specific types of actorlines/functions/signs etc. i made a few simple python parse&process scripts [02:57] <Kronusdark> I have about 20 mkvs to convert and i really dont look forward to doing it by hand, would you happen to have one of those scripts handy to share? [03:01] <DeadSix27> Kronusdark: http://files.dead6.eu/ASS_MKV_Tools_python/ [03:01] <DeadSix27> i dont have a handy lineprocess script right now, its a mix of weird stuff i use [03:01] <DeadSix27> but those 3 scripts come in very handy in automated batch processing [03:03] <DeadSix27> note that they're very vague.. and undocumented. [03:03] <Kronusdark> awesome, thanks. this should speed things up a bit. and don't worry about the documentation, i've dealt with much worse. [03:04] <DeadSix27> also, the audio one requires binarys to be installed [03:04] <DeadSix27> i didnt put any check in there yet [03:04] <DeadSix27> and its windows, so for unix pretty much just remove the .exe [03:05] <DeadSix27> (if those tools even exist in linux, not sure) [03:05] <Kronusdark> if i can make use of these, I will let you know. [03:06] <DeadSix27> also nvm, those tools exist in unix [03:56] <Ris> hey all im looking for some help [03:59] <Ris> been useing this what im trying to stream off my rpd useing ffmpeg screen cap and sound [03:59] <Ris> my rdp has no sound card [03:59] <Ris> been useing this command ffmpeg -f dshow -i audio="virtual-audio-capturer":video="screen-capture-recorder" yo.mp4 -f flv "rtmp://xxx.cast7.eu/onlive?key=THC87G/cast101" [03:59] <Ris> could someone help me skype cpilecki06 [05:06] <jangle> greetings all. just a sanity check, can ffmpeg accept h264 annex b as input? or does it have to be the version where the startcodes of each nal indicate the nal length? [05:07] <jangle> (if that has a name I don't know if, or if it isn't a real format and I just made it up, I wouldn't be surprised) [05:40] <Ris> no1 is around [05:40] <Ris> to help [05:47] <Orbixx> https://trac.ffmpeg.org/wiki/How%20to%20burn%20subtitles%20into%20the%20vid… [05:47] <Orbixx> In the second example in this video, how am I supposed to escape a directory and filename after the "ass=" bit? [05:54] <llogan> Orbixx: what is the path you are trying to use? [05:54] <Orbixx> llogan: It contains spaces in both directories and filenames [05:54] <Orbixx> It's a Windows path [05:54] <Orbixx> Or rather, a path on Windows [05:56] <llogan> oh. windows. works fine on linux: "ass=path to/file name.ass" [05:57] <llogan> Ris: what is rpd? [06:15] <Ris> baseially a vps [06:33] <llogan> Ris: so what is the problem with ffmpeg, exactly? [06:33] <DeadSix27> Orbixx: try '' [06:33] <Ris> ok ' [06:33] <Orbixx> DeadSix27: ? [06:34] <DeadSix27> -vf "ass='c:/blabla spaces/'" [06:34] <Orbixx> oh [06:34] <Ris> i will do that now ' [06:36] <Ris> http://pastebin.com/mXgFdBLn [06:36] <Orbixx> DeadSix27: No good [06:37] <DeadSix27> Orbixx: -vf "ass=\"c:/blabla spaces\"" [06:37] <DeadSix27> not sure bout that though [06:38] <llogan> Ris: so you want to create a local file output and an output stream? [06:38] <Ris> yea [06:38] <Ris> more of screen capture [06:38] <DeadSix27> Orbixx: nvm [06:39] <Ris> then a file [06:39] <DeadSix27> Orbixx: forgot to escape ":" [06:39] <llogan> Ris: does it work as expected if you omit the local file? [06:39] <DeadSix27> Orbixx: -> -vf "ass='C\:\Test.ass'" [06:39] <Ris> havent try it yet [06:40] <llogan> Ris: also, the tee muxer is a better choice if you want two outputs (without having to encode both) [06:40] <llogan> http://ffmpeg.org/ffmpeg-formats.html#tee [06:40] <llogan> http://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs [06:42] <Ris> thanks i will try it [06:45] <Ris> what is causeing this [06:45] <Ris> real-time buffer 545% full! frame dropped! [06:50] <llogan> Ris: try a faster encoder (-vcodec libx264 -preset fast), try a smaller frame size. i'm just guessing here. i know nothing of dshow. [07:03] <Ris> sorry i got dced [07:07] <Ris> i found somthing [07:07] <Ris> http://nerdlogger.com/2011/11/03/stream-your-windows-desktop-using-ffmpeg/ [07:09] <Ris> im taking a break [07:18] <BtbN> Why don't you use a software which is more better designed for that purpose? [08:32] <llogan> Keestu: this is the correct channel. are you following the compile guide at the ffmpeg wiki? [08:38] <Keestu> llogan, yup. i foloow the wiki only. :) [08:39] <JEEB> then you either did not follow them or they suck [08:39] <JEEB> (the instructions) [08:42] <Keestu> :) :( [14:08] <pron> any tips for buying a hardware for h264 encoding/decoding with ffmpeg? [14:23] <relaxed> pron: fastest intel cpu with the most threads you can afford. [14:24] <pron> how about vaapi and amd apu ? [14:24] <relaxed> intel is king [14:26] <relaxed> hevc is around the corner [14:27] <pron> the stuff im encoding is mostly for web [14:27] <pron> was wondering how abotu ahrdware decoding/encoding etc [14:29] <pron> to squeeze out some speed :P [14:35] <JEEB> pron, not supported out-of-box with cli ffmpeg and in general not worth it at all [14:35] <pron> ahaa i see [14:35] <JEEB> decoding /could/ be worth it with the newest intel, since it can push ~300fps [14:35] <JEEB> but that isn't supported [14:36] <pron> so basicly even grabbing nvidia card for de/en coding isnt worth , and doesnt give any performance gains [14:36] <JEEB> and at that level of hardware I wouldn't be surprised if you got as much if not more out of software decoder [14:36] <JEEB> let me guess [14:36] <JEEB> you read some telestream kool aid? [14:36] <pron> im trying to read tru forumms/google rite now [14:36] <JEEB> anyways, the point is that everything else you could get regarding hw encoding is complete and utter crap, other than the newest intels [14:37] <JEEB> but even those will not help you if you need to limit bandwidth and get quality with that while being fast as well [14:37] <pron> okay i see [14:37] <JEEB> (and not supported by cli ffmpeg) [14:37] <pron> i just want to experiment :D [14:37] <JEEB> and when you get to those newest intels, you usually get a capable CPU on that die too [14:37] <pron> and buy tons of hardware and spend time on thinfgs others have done alrdy [14:37] <pron> :} [14:37] <JEEB> but yeah, "GPGPU" is not worth it [14:38] <pron> cool [14:38] <pron> si i5 i guess it is [14:38] <pron> so* i5 [14:38] <JEEB> if you need fast hw decoding or encoding, the intel blackbox stuff is the best right now. And the decoder could be useful with some encoding scenarios, I guess? You'd just have to plug it in [14:39] <pron> JEEB intel black box? [14:40] <JEEB> ASICs [14:40] <JEEB> the stuff they have on their higher-end haswell+ stuff [14:40] <JEEB> used via the quicksync interface [14:50] <pron> JEEB thx [15:57] <theos> hi [15:57] <theos> does ffmpeg support gpu yet? [16:31] <clever> theos: which gpu? [16:32] <theos> ATI radeon HD [16:32] <clever> dont know [16:32] <theos> :/ [16:33] <JEEB> FFmpeg supports a couple of hwaccels, but ffmpeg (cli app) does not [16:33] <JEEB> that said, their usefulness can be of dubious quantity [16:34] <theos> i see [16:35] <clever> i'm trying to get omx hwaccel, but its causing issues with b frames, and if i try to fix that, it just doesnt output frames at all [16:36] <clever> the hw api isnt designed to fit into the ffmpeg api style [18:17] <canci> I want to extract a specific time section from a dv stream, prepend a logo to that and output it reencoded as h264/aac. for that purpose I use the following call to ffmpeg: https://paste.as5580.net/p/7pvvrmw2qvbxjl3a [18:17] <canci> This works more or less, the video ends in the position where it should, however for the last few seconds, the audio is missing, there is just silence in the output file [18:18] <canci> any idea what I am doing wrong there? [18:30] <Guest66753> Hello, is it possible to use ff* tools to dump epg from ts streams? [19:46] <canci> llogan: I pasted the exact command line? [19:46] <llogan> ...and the COMPLETE console output [19:48] <canci> ah, I overread that part, my bad. I will keep that in mind for the next time - for now it seems that the issue was caused by audio and video loosing synchronization when seeking the input file [20:05] <llogan> canci: check that your output is not yuv422p since you're using dv as input if you want the output to be compatible with non-FFmpeg based players (QuickTime, etc). [20:06] <llogan> the console output would have shown this [20:18] <canci> llogan: these are the two calls to ffmpeg with their respective output https://paste.as5580.net/p/6yofpi0di360fzz - it seems to end up as yuv420p [20:23] <llogan> canci: oh, PAL DV... [20:23] <llogan> anyway, you can add format=yuv420p to the endo of your filterchain if you did need to change it [20:25] <canci> looking at the common h264 profile, yuv420p seems to me as a reasonable colorspace for distributing the video - or should I use something else there? [20:25] <llogan> no [20:25] <llogan> unless you're only going to use ffmpeg 'n friends [20:25] <llogan> then it doesn't matter [20:26] <canci> heh. The overall intention of that conversion is to have a video that should hopefully play on most systems. [20:27] <canci> that was also my reason to do deinterlacing and converting it to something with SAR 1:1 [20:29] <llogan> canci: note that the profile and level are something to consider depending on what devices you want to support [20:33] <relaxed> consider a more recent version too [20:37] <canci> relaxed: yea, that's also a good point [20:38] <canci> llogan, relaxed: thank you for the pointers [22:41] <Mista-D> Can't vcodec copy mpeg2 from PS file. "pts (0) < dts (1)" error. I can decode it, can transcode code just cant copy it... any ideas? [23:01] <Mista-D> sample and console printout in last entry there : https://trac.ffmpeg.org/ticket/2058 [00:00] --- Tue Jan 28 2014

1 0

ffmpeg-devel.log.20140126
by burek 27 Jan '14

27 Jan '14

[00:00] <ubitux> i think i happened to see the video :) [00:54] <JEEB> ubitux, fabulously chuuni2 logo you found there sir [01:03] Action: BBB randomly playing with github comments [01:05] <ubitux> BBB: saw that :) [01:05] <ubitux> funny thing, i can edit *your* comments [01:05] <ubitux> .. [01:06] <ubitux> but you're already saying you like that so that's not funny [01:09] <BBB> also with your comments on this one sample, time with -threads 1 gives us 5.5sec vs libvpx 7.5sec [01:09] <ubitux> :) [01:09] <BBB> so we're slightly more than 2 sec faster than libvpx, or 36% [01:09] <BBB> and this is still with a bunch of c code, so not bad [01:12] <ubitux> i don't know when i will receive my avx2 machine, but we probably want to have some avx2 asm before the announce as well [01:13] <BBB> that'd be nice [01:14] <ubitux> i'll try to get done with the transpose tomorrow [01:14] <ubitux> then i guess i'll have to do the 8/4 ones [01:15] <BBB> the only avx2 decoder function in libvpx is specialize vp9_lpf_horizontal_16 sse2 avx2 neon dspr2 [01:15] <BBB> (as of today) [01:17] <BBB> the others are encoder functions [01:17] <BBB> (fdct, fadst, variance, mse) [01:18] <BBB> (note that horizontal for libvpx is vertical for us) [01:18] <ubitux> it will be useful for filter6() and filter14() [01:18] <ubitux> and probably for idct16 and 32 [01:19] <BBB> well you noticed how all loopfilter functions are mix2 right? [01:19] <BBB> we should create mix4 versions for avx2 to be truly useful [01:19] <BBB> which is some sort of an exponentially explosive problem, because you need a lot more mix4 variants than mix2 variants [01:19] <ubitux> mmh yeah ok :) [01:20] <BBB> assuming we want to operate on 32px per iteration [01:20] <BBB> this is a great idea btw [01:20] <BBB> I'm just saying it's not exactly trivial [01:20] <BBB> idct16/32 are indeed very obvious candidates [01:20] <BBB> also all 16x16/32x32 intra pred and >= 16px inter pred (subpel mc) functions [01:21] <BBB> so yes that'll be fun, I didn't assume it to be critical before announce, but we can wait, sure [01:22] <ubitux> well we need to be honest and be faster everywhere :p [01:22] <ubitux> we're likely slower on arm already, so let's at least be faster on intel :) [01:24] <ubitux> BBB: btw, i heard vp9 now has 444; we should probably support that :p [01:36] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:53167ecfdb99: avcodec/huffyuv: support AV_PIX_FMT_YUV(A)4XYP16 and GRAY16 [01:40] <BBB> ubitux: profile 1, yes, also supports alpha, rgb and some other things [01:40] <BBB> lots of fun [01:41] <ubitux> i want 10-bit :( [01:41] <BBB> not in profile 0 or 1 [01:41] <ubitux> totally useless for animes [01:41] <ubitux> how am i supposed to watch vp9 files then [01:42] <BBB> youtube I guess [01:43] <ubitux> :) [01:44] <BBB> or you have to write profile 2 for 10bit yourself [01:49] <Compn> animes [01:50] <Compn> they still make that ? [01:54] <ubitux> that's probably the only important and relevant video source [01:58] <BBB> also we wrote 11.5k lines of code for this beast [01:58] <BBB> and still not yet done [01:58] <BBB> whoa [01:58] <Compn> yeah you guys are working hard [01:59] <Compn> way too hard [01:59] <BBB> it's pretty solid at this point [01:59] <BBB> I have some fuzzing issues left with scalable samples, but overall it looks fairly solid [01:59] <BBB> I guess I should fix scalable at some point [01:59] <BBB> that's part of profile 0 [02:00] <ubitux> i'll continue to bring you some fuzzed files ;) [02:01] <ubitux> http://ljdchost.com/26vA1uM.gif #ffmpeg users [02:07] <BBB> that's also half of doom9 posters [02:07] <BBB> and many alike [02:10] <Compn> is it bad i know thats from gravity falls ? [02:14] <cone-125> ffmpeg.git 03Janne Grunau 07master:fb0c9d41d685: avutil: remove timer.h include from internal.h [02:14] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:965fa6b0d9d9: Merge commit 'fb0c9d41d685abb58575c5482ca33b8cd457c5ec' [02:30] <BBB> ubitux: fixes for your fuz sample (and the base one) on ML [03:18] <cone-125> ffmpeg.git 03Janne Grunau 07master:6d93307f8df8: mpeg12: check scantable indices in all decode_block functions [03:18] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:3e6088f7322c: avutil/internal.h: add timer.h back [03:18] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:20626f53e9f4: Merge commit '6d93307f8df81808f0dcdbc064b848054a6e83b3' [03:18] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:6a92598e149b: avcodec/mpeg12dec: Redesign index checks for mpeg2_fast_decode_block_intra [03:18] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:7667afffb8dd: avcodec/mpeg12dec: Revert Change to mpeg2_fast_decode_block_non_intra [03:23] <cone-125> ffmpeg.git 03Janne Grunau 07master:fb87e69ff77f: configure: add missing x86 dependency for i686 [03:23] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:0e2dd05c22c4: Merge commit 'fb87e69ff77f96536768dbae01d82db70c8b41f3' [03:31] <cone-125> ffmpeg.git 03Janne Grunau 07master:9e057f53aa85: configure: clang: explicitly state dep file and rule name in DEPFLAGS [03:31] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:c46faacdf4e1: Merge remote-tracking branch 'qatar/master' [04:07] <cone-125> ffmpeg.git 03Jean First 07master:91489d28ba27: avcodec/libfdk_aacenc: enable 7.1 channel encoding [04:27] <BBB> do we have any sort of "rawframecrc" output that prints the size of the frame in addition to the crc of the data? [04:27] <BBB> that would be useful as an alternative to framecrc/framemd5 for scalable fate tests [04:35] <BBB> maybe I should just add a 'print_size' private option to framemd5 to print the size for each frame... [05:18] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:bc11b2c3e6b5: fate: add test for 16bps ffvhuff [11:51] <Rodeo> michaelni: are you around? [11:57] <Rodeo> I'm looking at http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=91489d2;hp=c46faac [11:57] <Rodeo> here's an excerpt from FDK_Audio.h: [11:57] <Rodeo> MODE_7_1_REAR_SURROUND = 33, /**< C, L+R, LS+RS, Lrear+Rrear, LFE */ [11:57] <Rodeo> MODE_7_1_FRONT_CENTER = 34 /**< C, LC+RC, L+R, LS+RS, LFE */ [11:58] <Rodeo> MODE_7_1_REAR_SURROUND is most definitely not AV_CH_LAYOUT_7POINT1_WIDE_BACK [12:00] <Rodeo> for consistency with the rest, MODE_7_1_FRONT_CENTER would be AV_CH_LAYOUT_7POINT1_WIDE_BACK (since LS+RS is mapped to back channels in other modes) [12:00] <Rodeo> MODE_7_1_REAR_SURROUND would probably be AV_CH_LAYOUT_7POINT1_WIDE_BACK, though here that means mapping LS+RS to side channels instead, and Lrear+Rrear to back channels [12:01] <Rodeo> sorry, I meant MODE_7_1_REAR_SURROUND would probably be AV_CH_LAYOUT_7POINT1 [12:14] <Rodeo> sigh [12:14] <Rodeo> not to mention, MODE_7_1_FRONT_CENTER and MODE_1_2_2_2_1 can't be used interchangeably [12:15] <Rodeo> the latter will use the AAC channel_config 7 instead of 0+PCE if you use the former [12:15] <Rodeo> I suppose this could be intentional [13:43] <michaelni> Rodeo, iam not the author of that commit, did you contact jean first about this ? [13:54] <Rodeo> michaelni: nope, sorry [13:54] <Rodeo> but you committed it [14:01] <BBB> ubitux: I had one more question [14:02] <BBB> ubitux: the vp8 loopfilter uses 8x16 pixels for lf, but it does it (on x86-64 at least) entirely in registers, i.e. no stack [14:03] <BBB> ubitux: do you think it's possible to reproduce that in the vp9 loopfilter? no-stack would remove a lot of shuffles to/from it and thus make it somewhat faster [14:03] <BBB> (at least in the 88 and lower ones, not the 16 one) [14:50] <michaelni> Rodeo, posted 2 patches to the ML that would make the changes you suggest [14:51] <Rodeo> patches looks good [14:52] <Rodeo> I guess I should subscribe to the ML, though it's too late for those 2 patches [15:54] <Nicias> Je;;phello [15:54] <Nicias> hello [15:54] <Nicias> I am writing a filter and I am having a bit of a problem. [15:54] <Nicias> All I want to do is modify the value of frame->pts. [15:55] <Nicias> I do this insde filter_frame. [15:55] <Nicias> and if, inside filter_frame, I print the new frame->pts it show the correct value. [15:55] <Nicias> However, it doesn't end up in the file that is written out at the end. [16:13] <Nicias> As part of my modifications, I want to change the timebase of the video stream, since all the pts are scalled by about 8. [16:14] <Nicias> If I put in a config_output that is just outlink->timebase = inlink->timebase * 8 [16:14] <Nicias> then it ignores the new PTS's entirely. [16:15] <Nicias> otherwise it does the correct thing but the timebase is wrong. [16:24] <cone-907> ffmpeg.git 03Reimar Döffinger 07release/1.2:8a38deb789ec: Fix compilation on ARM with android gcc 4.7 [16:24] <cone-907> ffmpeg.git 03Alex Sukhanov 07release/2.1:9ca79d284989: avformat/matroskadec: Fix start_time [16:31] <Nicias> any help on my filter question? [17:21] <ubitux> BBB: the stack is necessary only for h, and it's used partly because it's aligned, which actually helps a lot [17:22] <ubitux> there is one specific place where i'm using pand(n?) with the direct address, and having that with an intermediate register is a real pain [17:41] <BBB> ubitux: I didn't mean stack vs dst, rather stack vs registers [17:42] <BBB> ubitux: I'm wondering if 16 registers is enough for the 88 (maybe it isn't, I'm not sure :) ) [17:42] <ubitux> i probably won't need the stack for the transpose [17:43] <ubitux> dunno if i can avoid the whole stack but i doubt it since i need to re-read [17:43] <Daemon404> is it a bog standard transpose? [17:43] <ubitux> (and the stack is my dst in h mode) [17:43] <Daemon404> i.e. can reuse code [17:44] <BBB> Daemon404: sure [17:44] <Daemon404> there exists transpose asm to reuse elsewhere... [17:44] <Daemon404> if its useful. [17:44] <Daemon404> (not necessarily in ffmpeg_ [17:44] <ubitux> there was no transpose16x16b in x264 [17:44] <ubitux> but i based the code on those [17:44] <Daemon404> using 4 4x4 is too slow i take it? [17:44] <BBB> 4 4x4 is 16x4 [17:44] <BBB> he needs 16x16 [17:45] <Daemon404> uh [17:45] <Daemon404> well i can tread [17:45] <BBB> but he already wrote it [17:45] <Daemon404> yeah i know [17:45] <Daemon404> just curious [17:45] <Daemon404> i had ported asm to vf_transpose.c at one point [17:45] <Daemon404> from another project [17:45] <BBB> I think the code he wrote is shareable enough, not too worried about it [17:45] Action: Daemon404 fades back into the bg [17:47] <Daemon404> yeah [17:47] <Daemon404> https://github.com/vapoursynth/vapoursynth/blob/master/src/core/asm/x86/tra… [17:47] <Daemon404> stuff i had done doesnt look suitable for you. [17:48] <BBB> ubitux: anyway, it may be worth looking at later to see if we can eradicate stack altogether, or at least as much as possible; but can be done later I guess [17:49] <BBB> it's not utterly urgent to get that right the first time [17:49] <BBB> (assuming there is a right) [17:50] <cone-907> ffmpeg.git 03Michael Niedermayer 07master:a301bb63f05d: avcodec/huffyuvenc: fail if stats_out is too small instead of silently truncating [17:50] <cone-907> ffmpeg.git 03Michael Niedermayer 07master:599e629f88a0: avcodec/huffyuvenc: fix end pointer for stats_out [17:54] <BBB> ubitux: also wanna review my two vp9 patches to fix your fuzzed6? [17:55] <BBB> then I'll work on "real" scalable support in the near future [17:55] <ubitux> give me about 2h :p [17:55] <ubitux> i need to get something done [17:55] <BBB> ok [17:57] <Daemon404> aside: does vp9 have 10-bit yet? [17:59] Action: Daemon404 is evaluating HEVC encoders soon-ish, and would like to include vp9, but all 4k clips he has are 10-bit [17:59] <BBB> no [17:59] <Daemon404> hmm ok [18:12] <kierank> Daemon404: please deploy high-10 kthx [18:12] <kierank> screw 8-bit [18:13] <kierank> I guess however the chipset guys will force 8bit on you [18:13] <Daemon404> who knows [18:15] <cone-907> ffmpeg.git 03Stefano Sabatini 07master:68c5ba1f052f: doc/filters: re-edit notes on filtergraph escaping [18:15] <cone-907> ffmpeg.git 03Stefano Sabatini 07master:9651239f6747: ffmpeg: use intermediary variables in reap_filters, increase readability [18:33] <cone-907> ffmpeg.git 03Stefano Sabatini 07master:37baa2af43a0: configure: add missing dependency for the remuxing example [19:08] <saste> kierank, you gonna test my overlay patch? [19:09] <kierank> saste: hmm forgot about that. will do it tomorrow [19:09] <kierank> sorry [19:09] <saste> otherwise i'll probably drop it, since i have no special interest with testing/using the patch [19:09] Action: kierank was doing taxes this weekend [19:09] <saste> hope you had fun [19:09] <kierank> well i didn't owe any taxes so it was ok [19:10] <saste> so it was easy at least [19:10] <saste> michaelni, ping again about the timebase thing, anu comment? [19:10] <saste> *any [19:17] <ubitux> BBB: the 2 patches are probably ok [19:17] <michaelni> saste, fps * ticks_per_frame * time_base = 1, i suspect your patch breaks this [19:17] <ubitux> BBB: should i continue fuzzing or you want to write some solid sanity code first? [19:18] Action: saste has no idea what "ticks per frame" is [19:19] <saste> michaelni, then at least we should fix the documentation, if the time_base option is not supposed to be controllable by the user we should remove it [19:19] <michaelni> saste, some code like ratecontrol use "ticks per frame" to decide how many bits a frame should get for the user specified bitrate [19:19] <saste> and avoid even more confusion [19:20] <michaelni> currently AVCodecContext.timebase cant just be randomly set by the user in general, she can set it through setting the framerate though [19:21] <michaelni> if you want to change this so the user can set it, i dont mind at all but i cant just give you a list of files and lines of code that would need to be chnaged ;) [19:21] <michaelni> but with the current code ticks_per_frame has to be adjusted at least [19:21] <michaelni> i dont know if that will be enugh [19:22] <michaelni> at least libx264.c had a bug in relation to this which i fixed [19:23] <wm4> currently I have to set AVCodecContext.time_base in order to use the subtitle conversion "decoders" [19:24] <saste> michaelni, ah i see, thanks for fixing libx264.c [19:25] <michaelni> its not a problem to set AVCodecContext.time_base from user applications, the problem is if the user sets time_base through AVOptions to lets say 5000 and expects 25fps because he also specified -r 25 on the command line [19:25] <michaelni> s#5000#1/5000# [19:26] <saste> michaelni, ticks per frame = timebase units between each frame (assuming constant framerate)? [19:26] <michaelni> saste, yes [19:37] <BBB> ubitux: no keep fuzzing, each of these did expose real issues [19:37] <BBB> ubitux: so it definitly helps [19:38] <wm4> (stupid question) how much do you think fuzzing helps in general to find of the total amount of bugs that is assumed to exist? [19:39] <BBB> fuzzing only helps if total code and feature coverage is great enough in the base files used for fuzz input [19:41] <Daemon404> it could also be useful to hack an encoder to produce insane files [19:42] <BBB> yeah absolutely [19:43] <BBB> anyway, total amount of bugs ... I don't know if that's a measurable, but fuzzing does decrease the density of obvious and easy-to-find bugs [19:43] <BBB> so in that way it makes the code a lot safer in practice [19:43] <Daemon404> it also helps if you have a few thousand spare cores [19:43] <Daemon404> a al google [19:45] <ubitux> BBB: ok then i'll start fuzzing again when your current patches are upstream [19:45] <BBB> wm4: I believe the nvidia defense (which is shared by some lawyers and some kernel devs, but not all) is that the nvidia binary is in itself useful outside the linux kernel also; for example, the same code (sic) is used in the windows driver also [19:46] <BBB> wm4: so then it is not a derived work anymore [19:46] <wm4> heh [19:46] <wm4> interesting aspect that with the windows driver [19:46] <BBB> not all kernel devs and not all lawyers share this sentiment [19:46] <wm4> of course nobody can prove it [19:50] <wm4> I guess this is also how there can be a native ZFS driver [20:04] <BBB> michaelni: can you merge the two on the ML then? [20:04] <cone-907> ffmpeg.git 03Michael Niedermayer 07master:e6c0da70fc82: avcodec/huffyuvdec: optimize >8bps VLC reading [20:17] <cone-907> ffmpeg.git 03Ronald S. Bultje 07master:d9343c348412: vp9: disable use_last_frame_mvs on resolution change (scalable). [20:17] <cone-907> ffmpeg.git 03Ronald S. Bultje 07master:c2871568cffe: vp9: fix invalid ref frame w/h on size change. [21:05] <nevcairiel> default vob palettes ... the reason this format sucks so bad [21:19] <Daemon404> nevcairiel, arent you glad they did away with bitmapped subs in bluray... wait. [21:20] <ubitux> heh, in the 2nd transpose, i have more swaps that instructions [21:22] <wm4> bluray subs don't look so bad [21:29] <nevcairiel> bluray subs have inband palettes and generally more useful features [21:30] <wm4> ubitux: btw. we'll probably break ffmpeg subs... you ok with that? [21:30] <ubitux> :( [21:31] <ubitux> i personally don't care you know, that's for the users [21:31] <ubitux> (you're one of them) [21:31] <wm4> the files are definitely invalid [21:31] <wm4> and won't play with the ASS main consumer [21:31] <ubitux> ah you mean the libass thing [21:31] <wm4> yes [21:31] <ubitux> so [21:32] <ubitux> you're saying all the "broken" ass files out there won't work anymore? [21:32] <wm4> yes [21:32] <ubitux> is it that much trouble to keep that support? [21:32] <wm4> take a look at the parsing code [21:33] <wm4> and compare it with vsfilter's [21:33] <wm4> I guess ffmpeg itself will still be able to read the old files [21:33] <ubitux> i think that's a very bad idea to purposely break all the files out there but well [21:33] <wm4> they're already broken [21:33] <wm4> it just "happens" to work with a single ASS implementation (libass) [21:34] <ubitux> a single ASS implementation used by virtually millions of people (vlc/mplayer and friends) [21:34] <wm4> so we can conveniently redirect the blame to ffmpeg [21:34] <nevcairiel> i still don't understand why not simply implement a universal parser based on the header line [21:34] <wm4> nevcairiel: it's slow and breaks in files vsfilter accepts [21:35] <ubitux> "slow" how is parsing time relevant? oO [21:35] <wm4> vsfilter doesn't even have anything to parse that header line and just skips it as garbage [21:35] <wm4> ubitux: it matters a few percents [21:35] <ubitux> anyway, i don't have time & motivation to fix that [21:35] <wm4> IMO this whole ASS business is severely broken and insane, but whatever [21:35] <ubitux> at least not right now [21:36] <ubitux> yes, but we can't fix it easily [21:36] <wm4> I mean ASS and how it's used in general [21:36] <ubitux> i'm also not an ass expert at all [21:56] <ubitux> is there a movq for the low part? :p [22:06] <BBB> movlps? [22:07] <ubitux> too late, i rewrote differently :p [22:07] <BBB> lol [22:17] <kierank> "Output pad "default" with type video of the filter instance "in" of smptebars not connected to any destination" [22:17] <kierank> ?? [22:17] <kierank> wtf does that mean [22:17] <kierank> :( [22:20] <llogan> kierank: how did you get that message? [22:20] <kierank> from the api [22:21] <kierank> trying to build a filter graph [22:21] <kierank> https://privatepaste.com/f85158bdc2 [22:22] <kierank> oh i think it's because the example is for a text graph [22:22] <kierank> whereas I'm trying to use the API [22:24] <llogan> useless info: i get that message using cli if i don't -map my output link label from the filtergraph [22:25] <ubitux> oh shit [22:25] <ubitux> it works [22:26] <ubitux> without any debugging @_@ [22:26] <ubitux> let's benchmark the improvement of not doing full tranpose.. [22:30] <ubitux> BBB: hey, nice. [22:30] <ubitux> 2746 decicycles in ff_vp9_loop_filter_h_88_16_ssse3, 4193698 runs, 606 skips [22:30] <ubitux> it was 3058 before [22:31] <ubitux> (C is 9233) [22:31] <nevcairiel> and how much is v? [22:31] <ubitux> 1932 [22:33] <ubitux> code is really ugly though [22:33] <ubitux> dunno how to macrotize it in a sexy way [22:37] <BBB> ubitux: nice [22:38] <BBB> I wouldn't worry too much about the macro'ization, vp8 was always somewhat chaotic also and ... well, it works, so who cares [22:41] <ubitux> BBB: i'll do in a later commit, that's gonna be a pain to squash with the original commit [22:44] <ubitux> BBB: https://github.com/ubitux/FFmpeg/commit/c67766dd3c48ac5188267e6a6f7ab3ffda0… [22:48] <BBB> ok cool [22:48] <BBB> did you push the other 2 already? [22:48] <ubitux> no :p [22:48] <BBB> hm I think my commit msg for that latest one is also somewhat poor [22:48] <ubitux> i have ~5 commits in queue [22:49] <ubitux> i'll add a comment for the splat thing and probably push [22:50] <BBB> so for the original, instead of doing punpcklbw x 8, you can movhps in the first 8 registers immediately [22:50] <BBB> that'd be slightly faster [22:50] <BBB> so instead of having 16 half registers, you'd have 8 registers where the lower half is the top 8 lines and the upper half (movhps) is the bottom 8 lines [22:50] <BBB> and then fumble with that [22:50] <ubitux> mmh [22:51] <BBB> the butterflies then become bw, wd, dq instead of wd, dq, qdq [22:51] <BBB> the advantage of that is that it skips the movq+punpcklXX into movhps [22:51] <BBB> and at the end, you use movhps to get the upper half back out into the correct memory location [22:52] <BBB> in the end, it saves you 8 punpcklXX per 16x8 transpose [22:53] <ubitux> ok [22:53] <ubitux> gonna try that [22:54] <cbsrobot> Rodeo: ping [22:56] <ubitux> BBB: so movhps m0, [P7]; movlps m1, [P6]; etc. or i misunderstood? [22:58] <ubitux> cbsrobot: i'll review your patches this week [22:58] <ubitux> or probably just apply [22:58] <cbsrobot> ubitux: np - it' mostly your patch with some cosmetics from me [22:59] <ubitux> yeah that first patch is awesome ;) [22:59] <BBB> I think movq m0, [P7] movq m1, [P6] ... movhps m0, [Q0] movhps m1, [Q1] ... [22:59] <cbsrobot> not sure the frame true peaks are really needed - but with it you can analyze the audio in detail [23:01] <ubitux> BBB: mmh, isn't movq in the h part? [23:01] Action: ubitux feels tired [23:01] <BBB> maybe interleaved as you said, i.e. movq m0, [P7], movhps m0, [P6] movq m1, [P5] movhps m1, [P4] etc [23:01] <BBB> no movq is in the low part [23:01] <BBB> in gdb it's the last bits yes [23:02] <BBB> but that's just intel vs gdb being odd, maybe endianness related [23:02] <ubitux> mmh, yeah k [23:03] <BBB> you know how people can be weird about that sort of stuff [23:17] <ubitux> kierank: look at lavd/lavfi.c [23:17] <ubitux> that's what is used when you ffplay -f lavfi testsrc [23:17] <kierank> thanks [23:17] <kierank> ubitux: are you going to fosdem btw? [23:17] <ubitux> i don't think so [23:18] <ubitux> i hate those meetings you know [23:19] <kierank> i know you hate them [23:19] <kierank> but fosdem is fun because you can go to interesting talks unrelated to multimedia [23:21] <BBB> fosdem is very dirty, they really need to clean that place out [23:21] <kierank> BBB: there are some new buildings [23:21] <kierank> also the year you went it was snowing like hell and everyone brought water in [23:22] <ubitux> fosdem just sounds like another random boring geeks meeting talking about shit, drinking beer and eating crap [23:22] <ubitux> dunno why ppl bother about taht [23:22] <kierank> personally I am not going to many multimedia things [23:22] <kierank> The radio stuff is quite interesting [23:23] <ubitux> i'd better go to ccc next year, or another probably more interesting "meeting" thing [23:23] <BBB> it's snowing in new york yet my office is spotless and clean [23:23] <llogan> lol. people still trying to compile ffmpeg from SVN... [23:23] <ubitux> still not disabled? [23:24] <llogan> i'm not sure, and who knows where they get this stuff from [23:25] <kierank> ubitux: seems very useful in fact, thanks again [23:26] <llogan> ubitux: shit. it's still not disabled. [23:41] <cone-907> ffmpeg.git 03Diego Biurrun 07master:50ecf1571235: avformat: utils: K&R formatting cosmetics [23:41] <cone-907> ffmpeg.git 03Michael Niedermayer 07master:896d6a7736c8: Merge commit '50ecf15712354a1d5b3f4dc9a57ff90ed7ee9654' [00:00] --- Mon Jan 27 2014

1 0

ffmpeg.log.20140126
by burek 27 Jan '14

27 Jan '14

[06:41] <DeadSix27> is there a way using ffmpeg, to watermark text into the video, or images produces by it? [06:41] <DeadSix27> e.g top right corner time code [06:41] <DeadSix27> or similiar sutff [06:44] <sacarasc> You can use the text video filter thing, or maybe the overlay one if you want an image. [06:44] <DeadSix27> drawtext ? [06:44] <DeadSix27> i just found out about that [07:10] <DeadSix27> never had more syntax problems than with that drawtext thing [07:11] <DeadSix27> hell [07:29] <clever> ffmpeg -i Color\ Bars.mov -vf "drawtext=text=%{n}:fontcolor=black:fontsize=70:x=20:y=20" num.mp4 [07:29] <clever> DeadSix27: i had used this to draw frame numbers on every frame [07:30] <clever> might help as an example of a valid command [07:30] <clever> bbl [07:34] <DeadSix27> windows btw [07:35] <DeadSix27> which gives weird syntax escaping issues [07:37] <DeadSix27> filter line: http://pastie.org/private/agzkrkxvjs3arldat0oa | result: http://i.imgur.com/Vd458uu.png [07:40] <NoZero> I came hee for help yesterday. [07:40] <NoZero> I asked to get started in VC++ using FFMPEG [07:40] <NoZero> you told me I need MinGW [07:40] <NoZero> bullshit [07:40] <NoZero> If you don't KNOW, don't advise!! [07:41] <NoZero> Put this in your notes for the next guy: [07:41] <NoZero> Empty project (recommended) [07:41] <NoZero> Project Properties > (All Configurations) > Configuration Properties > C/C++ > General > Additional Include Directories: [07:41] <NoZero> ../ffmpeg/include/;../ffmpeg/include/libavcodec;../ffmpeg/include/libavdevice;../ffmpeg/inclu de/libavfilter;../ffmpeg/include/libavformat;../ffmpeg/include/libavutil;../ffmpeg/include/li bpostproc;../ffmpeg/include/libswresample;../ffmpeg/include/libswscale [07:41] <NoZero> Project Properties > (All Configurations) > Configuration Properties > Linker > General > Additional Library Directories: [07:41] <NoZero> ../ffmpeg/lib/ [07:41] <NoZero> Project Properties > (All Configurations) > Configuration Properties > Linker > Input > Additional Dependencies: [07:41] <NoZero> avcodec.lib avdevice.lib avformat.lib avutil.lib swscale.lib [07:41] <relaxed> pastebin.com [07:42] <NoZero> OP me [07:43] <relaxed> also, did you read the docs before asking here? http://ffmpeg.org/platform.html#Windows [07:43] <DeadSix27> oh [07:43] <DeadSix27> i get it sacarasc: [07:43] <DeadSix27> it uses the resulting data.. after encode [07:43] <DeadSix27> and i wonder why it kept saying 0 as frame number.. [07:43] <DeadSix27> also, figured the syntax [07:44] <NoZero> of course I read the docs [07:44] <NoZero> omg [07:44] <NoZero> they are no help for VC++ [07:45] <NoZero> only how to install [07:45] <NoZero> I tried 100 tutorials [07:45] <NoZero> none would compile [07:45] <sonto> I want to make up a software about audio/video meeting, can ffmpeg make it? thanks [07:45] <DeadSix27> sacarasc: any idea how to get the timecode before conversion? [07:45] <sacarasc> DeadSix27: Nope, sorry. [07:45] <NoZero> After I figured out for myself how to Compile it I came here to share. [07:47] <sonto> Are there any open softwares on multimedia meeting implemented with ffmpeg? [07:47] <relaxed> NoZero: if you want to fix the docs, that's great, send a patch. [07:47] <NoZero> lol [07:47] <relaxed> NoZero: pasting random stuff in the channel is not helpful [07:48] <NoZero> random stuff [07:48] <NoZero> took me a week to come up with "random stuff" [07:49] <NoZero> and without a thank you [07:49] <NoZero> FFMPEG is not my project. [07:49] <NoZero> I can't spend time perfecting your software for you (yet). [07:50] <NoZero> I need to get this project done by the end of the month. [10:26] <Tuplanolla> How can I change the frame rate of a video from n to m > n, using weighted averaging for constructing the frame transitions? [10:28] <Tuplanolla> I tried using slowmoVideo, but its performance is really bad. Encoding 20 seconds of video took hours and so encoding an hour of video could take months. [11:50] <Tuplanolla> I don't have months to spare. [11:54] <relaxed> Tuplanolla: Have you tried ffmpeg? ffmpeg -i input -r $new_framerate output [12:05] <Tuplanolla> Yes. It either duplicates or drops frames. [12:13] <relaxed> As far as I know that's the only way it can. [12:13] <Tuplanolla> How should I go about writing a filter for it then? [12:14] <JEEB> libavfilter [12:14] <JEEB> is the library that handles filters [12:14] <JEEB> you should proceed to #ffmpeg-devel then [12:14] <JEEB> that's the development discussion channel [12:14] <JEEB> (for FFmpeg itself) [12:14] <relaxed> http://wiki.multimedia.cx/index.php?title=FFmpeg_filter_howto [12:16] <Tuplanolla> Can I combine existing filters using higher order functions? [12:17] <JEEB> usage of existing filters can be done in the ffmpeg cli itself [12:17] <JEEB> not sure if filters can use other filters [12:17] <Tuplanolla> I'd only need basic homomorphisms. [12:17] <JEEB> basically the filter_complex stuff [12:17] <JEEB> which I have no idea of how to do [12:19] <Tuplanolla> I find it strange how such a trivial operation isn't supported out of the box. [13:49] <__raven> how to get a very detailed range of current vbr during encoding/transcoding? [15:10] <saste> lkiesow, I don't follow github [15:10] <saste> the better way is as usual to post patches on ffmpeg-devel [17:05] <CapsLock> hi every one [17:05] <CapsLock> I'm in search of a software to mix live video sources (the result would be sent to a streaming server) [17:06] <CapsLock> Do you know a software which can do this ? (opensource would be appreciated) [17:27] <lkiesow> saste: Ok, I will do that next time. [17:27] <JEEB> CapsLock, something like this? http://www.casparcg.com/ [17:28] <JEEB> and then you can feed that to ffmpeg or whatever which then most probably can feed it to your streaming server [17:34] <klaxa> casparcg looks nice [17:39] <CapsLock> klaxa: hum, does it work on linux ? [17:40] <klaxa> without looking at it any further, they say they run it 24/7, i haven't seen a windows system run 24/7 stable, so i would assume so [17:41] <klaxa> it's windows though apparently [17:41] <CapsLock> huhu [17:41] <klaxa> the server at least [17:41] <CapsLock> hum so not a valid candidate [17:41] <CapsLock> I looked at some vjing software, like the nice GlMixer [17:42] <CapsLock> but I do not find how to output live rendering to file [18:02] <sineb> is it me or are nikon lenses much cheaper..... [18:02] <sineb> um wrong channel [18:14] <shevy> good that it was just about nikon lenses and not the pink underwear [19:21] <ChocolateArmpits> Does anyone know if Constrained Baseline profile should be used over Baseline? Wikipedia seems to put it as a newer one. [19:21] <ChocolateArmpits> That's for h.264 [19:35] <JEEB> ChocolateArmpits, you pretty much never see a baseline profile encode [19:35] <JEEB> because baseline is not a subpart of main [19:35] <JEEB> constained baseline is [19:35] <JEEB> *constrained [19:36] <JEEB> when you set --profile baseline in x264cli, or -profile:v baseline in ffmpeg [19:36] <JEEB> you get constrained baseline [19:36] <JEEB> not baseline [19:41] <ChocolateArmpits> Can you explain "subpart" ? [20:19] <bsdwolf> anyone using freebsd and have ffmpeg working? [20:25] <shevy> I use linux and ffmpeg works beautifully on such a good OS [20:26] <bsdwolf> yeah [20:28] <shevy> :D [20:28] <shevy> bsdwolf you can compile from the ffmpeg sources? http://ffmpeg.org/releases/ffmpeg-2.1.2.tar.bz2 [20:30] <bsdwolf> I have it installed already [20:30] <bsdwolf> ffserver runs [20:31] <bsdwolf> ffmpeg won't stream a web cam though [20:41] <ChocolateArmpits> JEEB, Can you explain "subpart" ? [20:41] <JEEB> whatever the real word was for that ^^; as in, X doesn't fit into Y. [20:42] <JEEB> baseline does not fit into main feature-wise (there are things in baseline that main doesn't have) [20:42] <JEEB> constrained baseline, on the other hand, does [20:42] <ChocolateArmpits> You mean, constrained has what main has but what baselin doesn't have? [20:42] <JEEB> no [20:42] <ChocolateArmpits> baseline* [20:43] <JEEB> main has more than constrained baseline [20:43] <JEEB> but constrained baseline fits within the features of main [20:43] <JEEB> thus, if a decoder supports main, it also supports constrained baseline [20:43] <JEEB> this is not true for baseline [20:44] <JEEB> because it has features that main does not have (the non-constrained baseline seemed to be some kind of pot of frustrations and weird ideas) [20:44] <ChocolateArmpits> So even though baseline would take less processing power to decode than main, a main targetted decoder main not process baseline ? [20:44] <ChocolateArmpits> may* [20:44] <JEEB> baseline is not on the constrained baseline - main - high line [20:44] <JEEB> it has its own features [20:45] <JEEB> and that is why you generally don't see a H.264 stream that is tagged with the non-constrained baseline profile [20:45] <ChocolateArmpits> The wikipedia table explains that [20:45] <ChocolateArmpits> So is baseline at all used ? [20:45] <JEEB> I've not seen it around [20:46] <JEEB> probably some specific place that asked for those specific features uses or used it at some point [20:46] <ChocolateArmpits> So if I'm targeting mobile devices, I should be using constrained, right ? [20:46] <JEEB> yes [20:47] <ChocolateArmpits> That's awkward, I've gone through somewhat technical looking documents on apple's website, it mentions baseline solely, nothing about constrained [20:47] <JEEB> that's because everyone means constrained baseline when they say baseline [20:47] <JEEB> it's literally been forgotten about [20:48] <ChocolateArmpits> Then wikipedia article doesn't reflect that well ? [20:48] <JEEB> well, the wikipedia article can list everything in the specification, can it not? I have no idea about it otherwise, but I see no bad in it listing that stuff since it after all is in the spec. [20:49] <JEEB> that said, when someone says baseline, unless they're in for a very weird ride, you can bet your ass they're talking about constrained baseline [20:50] <ChocolateArmpits> I mean the fact that the real "Baseline" has been superseded by Constrained isn't worded very strongly or made any heavy notice [20:51] <ChocolateArmpits> That's why I came here to ask more on this [20:51] <JEEB> specification wise it has not been superceded, and the baseline profile did not get pretty much an use at all [20:52] <ChocolateArmpits> Well, the article says constained came only after the real baseline [20:52] <ChocolateArmpits> If they bear the name it would be logical (?) to say they have something in common through their purpose, no? [20:53] <ChocolateArmpits> Well the purposes also match [20:53] <JEEB> well, they do bear a similar name, but they're just feature levels basically [20:53] <JEEB> and yes, it was added most probably because no-one was using or implementing the baseline features [20:54] <JEEB> I'm surprised that it says that constrained baseline was only added in 2009 [20:56] <JEEB> which of course might be true, but in that case we had a very very long part of time where you probably had no-one say they did baseline profile decoders :D Because then you would have had to support those features that aren't in main. [20:59] <ChocolateArmpits> But wait, doesn't that mean that any mobile device that relied on the original baseline, actually uses baseline, say original iPhone? [20:59] <ChocolateArmpits> So if then anyone would want to still support it would have to use the original baseline ? [21:00] <ChocolateArmpits> Possible even 3G and 3GS versions [21:00] <JEEB> no [21:01] <ChocolateArmpits> Care to explain ? [21:01] <JEEB> as in, it doesn't matter to you because constrained baseline is a subset of baseline, and nothing supported the baseline-only features of baseline [21:01] <JEEB> so for you there is only one baseline, constrained baseline [21:02] <JEEB> in other words, you want to use whatever x264 outputs with -profile:v baseline or --profile baseline (depending on if you're using ffmpeg or x264cli) [21:02] <ChocolateArmpits> ok, I think I've got that hammered [21:05] <ChocolateArmpits> Going forward, I wanted to know what gop size would a video streaming situation require? I've read suggestions to use the framerate equavalent to reduce buffering and possible picture corruption going in first seconds [21:05] <ChocolateArmpits> equivalent* [21:07] <JEEB> a second's worth of pictures sounds OK, although you could set that to more or less depending on your needs and how dumb those plastic toys are [21:07] <JEEB> I mostly deal with PCs so I have no idea how much corruption (aka "how many devices actually decide to output broken pictures instead of waiting for the first proper") you would get [21:08] <JEEB> also for buffering reducement I really recommend you note this thing called VBV [21:08] <JEEB> in x264cli it's --vbv-maxrate and --vbv-bufsize, and in ffmpeg the equivalents are -maxrate and -bufsize [21:10] <ChocolateArmpits> Yeah, I understand that keeping maximum bitrate too high can yield longer buffer times if you jump to a more action intense scene [21:10] <ChocolateArmpits> I'm not sure about the buffer size however [21:11] <JEEB> as you just said that notes that you don't grasp the concept yet [21:12] <JEEB> you first set a maximum rate, and then you have a buffer in which this maximum rate is calculated within and made sure that the stream never goes beyond this bound [21:12] <JEEB> so it is limiting the average bit rate over bufsize [21:13] <JEEB> this is actually written down in the standard [21:13] <JEEB> as VBV [21:13] <JEEB> (and then there's even nal-hrd) [21:14] <ChocolateArmpits> And VBV translates to ? [21:14] <JEEB> "Video buffering verifier" [21:14] <JEEB> it's a model [21:15] <JEEB> anyways, you should never be doing stuff with video over limited bandwidth without VBV :) [21:15] <ChocolateArmpits> okay, so the buffersize tells how often to correct the bitrate ? [21:16] <JEEB> noot exactly like that, but yes -- it is the amount of data within which the average rate is being calculated [21:16] <JEEB> so at any point of time [21:17] <JEEB> if you buffer bufsize amount of stuff and your bandwidth is at least maxrate [21:17] <JEEB> that video stream will be OK for you to play back [21:17] <JEEB> now let's say that you set -maxrate 250K, and you want 2 seconds of buffer -- you set -bufsize 500K [21:18] <JEEB> of course it is not always you who decides the VBV limitations as they are affected by other things as well [21:18] <JEEB> like a possible man-in-the-middle restreaming service via which you are streaming (in case of live streaming) [21:18] <JEEB> or possibly the hardcoded values in mobile players? [21:19] <ChocolateArmpits> I'm listening [21:19] <JEEB> you match up the decoder and the encoder regarding VBV, and you're golden :) [21:19] <JEEB> and those two examples I just said are theoretical, I have no idea about them :P [21:20] <JEEB> just wanted to note that it's not always you who gets to pick the values [21:22] <ChocolateArmpits> I suppose in the situation where your bandwith matches the optimistic average bitrate you could have higher maximum bitrate than your bandwith allows with the awkward rule that you buffer more of the video when the bitrate is below average to compensate? [21:23] <ChocolateArmpits> Which sounds all sorts of flawed [21:27] <ChocolateArmpits> I was also interested in asking is there any maximum gop limit in h264 ? [21:31] <JEEB> ChocolateArmpits, no [21:32] <JEEB> it's not flawed, it works and you only have to have the average bit rate be over your set maxrate [21:32] <JEEB> and it just means that that is the MAXIMUM over bufsize [21:32] <JEEB> and no, there is no maximum GOP length limit in H.264 [21:32] <JEEB> there's even stuff like intra refresh [21:33] <JEEB> where you will never have another intra-only frame except for the first one [21:33] <ChocolateArmpits> But does that mean that a P frame has to be placed on a scene change ? [21:33] <JEEB> but if the decoder goes over your intra refresh amount of pictures, it will get a full picture and can continue from there because during that intra refresh period there's been enough intra [21:34] <JEEB> and yes, the encoder can select an intra-only frame, I just meant that it doesn't have to add any extra ones in there [21:34] <JEEB> IDR pictures or open gop keyframes [21:36] <ChocolateArmpits> open gop keyframes? Not just an open gop ? [21:36] <JEEB> well, open GOPs will not have IDR pictures, so I noted them separately [21:36] <ChocolateArmpits> Do you mean they reference previous iframes? [21:36] <JEEB> it's all more definitive in HEVC :P [21:36] Action: JEEB likes the definitions in that specification rather than AVC [21:37] <JEEB> anyways, yes -- with open GOP you don't cut the reference list [21:37] <JEEB> and thus you don't generally use IDR pictures there [21:37] <ChocolateArmpits> So open Gop and IDR are two different things ? [21:37] <JEEB> yes [21:37] <JEEB> open gop is a type of gop [21:37] <JEEB> IDR is a type of picture [21:38] <JEEB> IDR is used to start a new GOP with closed GOP [21:38] <ChocolateArmpits> ok, it's getting back to me [21:38] <ChocolateArmpits> or maybe not so much [21:39] <JEEB> anyways, just take these points from this 1) when streaming you NEED to use VBV (maxrate/bufsize) and 2) GOPs have no length limits [21:39] <JEEB> (in the H.264 specification) [21:42] <ChocolateArmpits> Last one, What about reference frames? [21:44] <JEEB> limit them to your level? [21:44] <JEEB> x264cli does this automagically when you set --level , but the libx264 wrapper in ffmpeg doesn't [21:44] <JEEB> -refs is the setting [21:45] <ChocolateArmpits> I really didn't get to count them from the level/resolution known [21:45] <JEEB> usually with baseline you use level 3.0 or so [21:45] <ChocolateArmpits> how* [21:47] <JEEB> it's noted in the specification, but you can see a quick example at the end of http://up-cat.net/x264%2528vbv%252Dmaxrate%252Cvbv%252Dbufsize%252Cprofile%… [21:47] <JEEB> it notes DPB and --ref [21:47] <JEEB> basically you calculate it off of the amount of macroblocks in your picture, as well as the MaxDpbMbs value from the specification [21:48] <JEEB> it even notes the spot in the specification where the actual way of counting is noted [21:49] <JEEB> "A.3.1 Level limits common to the Baseline, Constrained Baseline, Main, and Extended profiles" and "A.3.2 Level limits common to the High, High 10, High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra, High 4:4:4 Intra, and CAVLC 4:4:4 Intra profiles" [21:50] <JEEB> I've been thinking of implementing the limiting in the libx264 wrapper but I'm successfully procrasting [22:18] <llogan> JEEB: i opened a ticket about that https://trac.ffmpeg.org/ticket/3307 [22:18] <llogan> just imagine how fun it would be to close it as "fixed". [22:19] <JEEB> :) [22:47] <grinex> sup guys i was wondering if someone could assist me in streaming from ffmpeg, i can get it working and sending pkts but no video on the output [23:30] <grinex> llogan: http://pastebin.com/bx2sngfZ [23:31] <llogan> that's not from FFmpeg. we don't support third party stuff here [23:31] <llogan> see http://trac.ffmpeg.org/wiki/UbuntuCompilationGuide [23:32] <grinex> not from ffmpeg? [23:36] <llogan> grinex: please read the link i provided [23:38] Action: llogan now has to go [23:40] <Hello71> anyone tried compiling git head recently with fdk? [23:40] <Hello71> ERROR: libfdk_aac must be installed and version must be >= 3.4.12. [23:41] <Hello71> but the versions only go to 0.1.3 [23:45] <lkiesow> where did you get the &and version must be >= 3.4.12. [23:45] <lkiesow> I've compiled my FFmpeg 2.1.3 against fdk-aac 0.1.1 [23:45] <Hello71> from configure. [23:46] <Hello71> 91489d28ba271fb9dde54cb26e7ae93ada2997df [23:46] <Hello71> avcodec/libfdk_aacenc: enable 7.1 channel encoding [23:49] <lkiesow> hm, that came in today. Haven't tested that& [23:50] <Hello71> Date: 2014-01-26 01:31:53 +0100 [23:51] <lkiesow> which is today :) [00:00] --- Mon Jan 27 2014

1 0