Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

August 2014

1 participants
60 discussions

ffmpeg-devel.log.20140820
by burek 21 Aug '14

21 Aug '14

[00:40] <cone-383> ffmpeg.git 03Diego Biurrun 07master:67a7695c1425: avfilter: Remove unused variable from ff_get_video_buffer() [00:41] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:5a22877e9d19: Merge commit '67a7695c142561fe60f21adffe89c133385d37c9' [00:52] <kurosu__> BBB / michaelni: I'm for pushing "Re: [FFmpeg-devel] [PATCH] x86: hevc: adding transform_add" [00:52] <kurosu__> another reason being that it is not the most important part of the idct [01:21] <BBB> kurosu__: can you explain why not? [01:23] <kurosu__> BBB: if I'm not mistaken, transform_add is not the idct [01:23] <kurosu__> it's just hevc's add clamped or whatever [01:23] <kurosu__> I think this might needed for range extensions where there is an inter-component residual prediction [01:24] <kurosu__> so you have to really idct to produce residuals [01:24] <kurosu__> and not just do idct+add clamped in one step [01:26] <BBB> oh, I see, its not the idct [01:26] <BBB> so its not the interesting part [01:26] <BBB> ok [01:26] <kurosu__> yeah [01:28] <BBB> right, ok, michaelni: patch ok [01:28] <BBB> Im not sure Id do that in separate functions but ok I wont complain until I write it myself [01:29] <kurosu__> and I present you our first broken hevc stream with somewhat widespread [01:29] <kurosu__> ticket #3872 [01:29] <BBB> rofl [01:29] <BBB> well that was to be expected [01:30] <kurosu__> seems to be that: http://kickass.to/michael-jackson-hevc-x265-1080p-eng-t9386565.html [01:30] <kurosu__> i'm not completely sure, but the SPS looks truncated [01:30] <kurosu__> might be a bug in the multiplexing tool (mkvtoolnix 7.1) apparently [01:33] <jamrial> it's probably what kurosu said. transform_dc_add got split into idct_dc and transform_add when the rext stuff was merged [01:37] <cone-383> ffmpeg.git 03Pierre Edouard Lepere 07master:a6af4bf64dae: x86: hevc: adding transform_add [02:36] <cone-383> ffmpeg.git 03James Almer 07master:9f498f4e6fa0: x86/hevc_res_add: fix register count in hevc_transform_add{16,32}_10_avx2 [10:19] <kurosu__> for whoever read and/or noted my comment on hevc+sps truncation, at least it's not an obvious mkvtoolnix 7.1's fault: other hevc streams get properly muxed without truncation [10:56] <nevcairiel> i'm slightly confused, why do the 10-bit versions of hevc_transform_add32 use way less registers than the 8-bit versions [10:58] <nevcairiel> and more importantly, i dont even see where it uses them :D [10:59] <nevcairiel> oh, i'm blind, i see [10:59] <nevcairiel> still not sure why [11:19] <ubitux> /home/ux/fate/ffmpeg/libavformat/rtmppkt.c:269:4: error: implicit declaration of function $if [-Werror=implicit-function-declaration] [11:19] <ubitux> wtf is lcov doing [11:24] <plepere> nevcairiel, [11:25] <plepere> the transform add in 8 bit adds a 8bit and a 16bit int [11:25] <plepere> so there's a need to split the 16bit to 2 8 bits [11:25] <plepere> while in 10bit, it's 16bit + 16bit. [11:27] <J_Darnley> What? It does a high and low byte? [11:32] <henry0312> wm4, ubitux: https://gist.github.com/henry0312/b0feccedd5b9fd2e636b [11:32] <henry0312> sorry it took so long. [11:34] <henry0312> btw, what does '1 +' at the line 57 in the above diff mean/do? [11:35] Action: henry0312 goes afk. [11:37] <henry0312> < henry0312> btw, what does '1 +' at the line 57 in the above diff mean/do? <-- I want to know why adding + 1. [11:48] <kurosu> how can one recompile some files by eg adding -DDEBUG=1 to cflags ? [11:48] <kurosu> I saw specifying that in CFLAGS didn't help [11:49] <kurosu> I'm split between adding additional environment vars, adding new rule or something else [11:50] <nevcairiel> I assume for all files is not what you would like [11:50] <kurosu> no, and editing config.mak would force recompiling? [11:51] <nevcairiel> dont think it would force it, I've had that as a problem before that it didn't pick up changes in the makefiles, only in the actual files [11:51] <kurosu> oh ok [11:51] <kurosu> it's just that it easy to forget it [11:51] <kurosu> *is easy to forget about it [11:51] <kurosu> and have it applied to a lot more files than expected [11:52] <nevcairiel> yeah..enabling dlog for everything makes it spam so much stuff [12:15] <J_Darnley> kurosu: if you're not familiar with it, you should look at the -W option for make which tells make to assume the file given is new [12:18] <kurosu> ok that would do what my rm kind of does + rebuild whatever target I want [12:39] <cone-166> ffmpeg.git 03Stefano Sabatini 07master:cb0524f7a02f: lavfi/apad: fix if_( style [15:04] <ubitux> michaelni: "get rid of floats i init code" "in init code" [15:06] <ubitux> lol bottom posting apple mail; it works, except the signature stays on top [15:07] <nevcairiel> lol [15:08] <Daemon404> apple mail is horrible [15:08] <Daemon404> it cant even display threads [15:09] <Daemon404> it flattens all thread [15:09] <Daemon404> s [15:09] <Daemon404> other mail clients are starting to copy it to... and it leads to 10-bazillion-mail-deep nested replies [15:09] <Daemon404> that are hard as shit to follow [15:09] <nevcairiel> hey, even outlook can display threads, somewhat! [15:09] <Daemon404> yeah [15:10] <nevcairiel> if youre top posting you at least dont have to scroll past billions of deeply nested mails to find the new stuff, huh [15:10] <Daemon404> i generally trim bottom or interlaved replies [15:11] <Daemon404> to only contain relevant quotes [15:11] <Daemon404> most clients make it easy [15:11] <nevcairiel> i do that too when its getting too excessive, but some people never do it [15:11] <Daemon404> >>>>>>>>>>>>>>>>>> return 0; [15:15] Action: michaelni doesnt understand why with something as old as email still the most basic things like threading are handled correctly in some implementations [15:15] <Daemon404> michaelni, apple mail made a conciosu decision [15:15] <Daemon404> it's marketed as a feature [15:15] <Daemon404> "IM-like email replies" [15:15] <nevcairiel> also known as "dumb email replies" [15:16] <Daemon404> http://www.postbox-inc.com/ [15:16] <nevcairiel> but yeah, many clients where this doesnt work are intentionally dumbed down [15:16] <Daemon404> scroll down to "conversation view" [15:16] <Daemon404> and cringe. [15:16] <Daemon404> this is literally the onyl view you can use. [15:17] <Daemon404> aside from no grouping at all [15:19] <cone-166> ffmpeg.git 03Michael Niedermayer 07master:7caacc50aed5: avcodec/hevc_ps: do cleanup in case of unsupported bit depth [16:49] <alexfu> what does avpicture_fill do excatly? i'm trying to figure out it's purpose in the code I have. [16:56] <cone-166> ffmpeg.git 03Michael Niedermayer 07master:05dd5368a927: avformat/nutdec: always initialize event_flags [18:07] <wm4> henry0312: I don't know ts, but it's part of the public API and documented as having the value+1 [18:08] <wm4> henry0312: maybe it's done so that 0 means "unknown" [18:08] <wm4> henry0312: you shouldn't change it, even if it's probably stupid [18:34] <cone-166> ffmpeg.git 03Michael Niedermayer 07master:207609554981: avformat/asfdec: Check av_new_packet()s return code [18:55] <cone-166> ffmpeg.git 03Michael Niedermayer 07master:a5cbff22b203: avfilter/avf_showspectrum: fix colums typo [19:23] <henry0312> <+wm4> henry0312: you shouldn't change it, even if it's probably stupid <-- ok! [19:23] <henry0312> I just read https://www.ffmpeg.org/doxygen/trunk/structAVStream.html [19:30] <henry0312> wm4: updated https://gist.github.com/henry0312/b0feccedd5b9fd2e636b (also you can see the diff at https://gist.github.com/henry0312/b0feccedd5b9fd2e636b/revisions) [19:33] <wm4> henry0312: at least to me this looks fine, maybe wait for a comment by kierank [19:33] <wm4> then post the patch to the mailing list [19:34] <henry0312> I wonder MKBETAG('A','R','I','A') and MKBETAG('A','R','I','C') may not be good.... [19:34] <henry0312> hm [19:34] <henry0312> ok! [19:34] <wm4> I wonder whether you need to add the new codec IDs to doc/APIchanges [19:34] <kierank> probably ok as long as it doesn't clash with dvb [19:34] <wm4> also why are there 2 codec IDs? [19:35] <JEEB> extracting the text probably isn't going to be too hard, but rendering it will be a whole separate affair :s [19:36] <wm4> I thought the library does this [19:36] <wm4> unless there are people who insist the decoder should be NIH'ed [19:36] <JEEB> orly? [19:37] <JEEB> I didn't know there was a capable enough renderer for the format [19:37] <wm4> outputting the result will still be messy though [19:37] <henry0312> I asked the author of aribb24 to create some documents, [19:37] <henry0312> and he created, https://github.com/nkoriyama/aribb24/wiki [19:37] <henry0312> he put SampleCodes and TestData [19:37] <JEEB> lol, not mentioning which part of ARIB B-24 [19:38] <JEEB> I mean, that thing now has like two or three parts [19:38] <JEEB> I don't remember any more which was related :/ [19:39] <henry0312> <+wm4> also why are there 2 codec IDs? <-- please see https://github.com/nkoriyama/aribb24/blob/master/src/aribb24/decoder.h#L65 [19:39] <henry0312> there are arib_initialize_decoder_a_profile and arib_initialize_decoder_c_profile [19:40] <henry0312> <+kierank> probably ok as long as it doesn't clash with dvb <-- I'll check. [19:44] <henry0312> JEEB: yeah, actually we have to read more documents. c.f. https://github.com/nkoriyama/vlc-aribsub/wiki/Aribsubspecification [20:04] <ubitux> heh [20:04] <ubitux> i guess pkg-config would have helped here.. [20:06] <henry0312> kierank: sorry, how do I test with DVB? [20:06] <JEEB> basically check the DVB specs for the defined IDs, I guess? [20:07] <henry0312> hmm [20:11] <kierank> henry0312: is there an unambiguous way of checking for a japanese mpegts? [20:13] <henry0312> kierank: umm.... I don't know. [20:13] <henry0312> JEEB: do you know? [20:13] <henry0312> kierank: but ffprobe outpus is the same with mediainfo, which supports ARIB subtitles, i guess. [20:14] <wm4> if there are clashes (I don't know if there are), mediainfo could have heuristics to resolve them [20:14] <wm4> or mediainfo could wrongly assume that it's a japanese ts [20:15] <kierank> henry0312: probably just submit it [20:15] <wm4> yeah, just submit it [20:15] <henry0312> ok :D [20:15] <henry0312> I'll submit. [20:20] <henry0312> but it's about time to sleep..., so I'll submit it after getting up. [20:37] <ubitux> wm4: btw, what about utf-16? [20:37] <ubitux> :-° [20:37] <wm4> that's actually not much work [20:38] <ubitux> :) [20:41] <nevcairiel> Didn't an argument with Nicolas stand in the way of utf16 the last time [20:43] <ubitux> i think wm4 stand in the way of generic charset detect project from nicolas instead, iirc [20:44] <wm4> nicolas wanted to implement generic charset detection, on the demuxer level [20:44] <wm4> but it was bad because it tried to deal with 8 bit legacy charsets [20:44] <wm4> where it's not always possible to find a good or correct match [20:45] <iive> there is enca librarby, but imho it haven't gotten much development since its creation. (I could be wrong). [20:45] <cone-166> ffmpeg.git 03Lou Logan 07master:d2163f5e2836: doc/ffmpeg: fix metadata language example [20:45] <wm4> iive: enca is pretty bad [20:45] <wm4> in fact most/all charset detectors are [20:46] <iive> at lest supporting BOM should be easy. [20:46] <ubitux> iive: actually, not really& [20:46] <ubitux> it's hard to make such abstraction properly [20:46] <wm4> BOM is pretty easy and that's what my patch did [20:46] <ubitux> it's not about the detection itself but the integration within ffmpeg [20:47] <wm4> of course it's assuming that the BOM is 100% reliable and sufficient [20:47] <wm4> but then, most UTF-16 files are made by microsoft tools... [21:21] <alexfu> what's required to open a network stream? [21:22] <ubitux> a network connection [21:23] <alexfu> ubitux: besides that. I get an IO error. is it somethign that should just "work"? [21:23] <ubitux> i can't guess the problem with so much information [21:24] <ubitux> btw, you should probably ask #ffmpeg, unless you're actually writing code for ffmpeg [21:24] <alexfu> ubitux: yes, i am asking in the context of writing ffmpeg code in C [21:25] <ubitux> this is not *for* ffmpeg, this is *with* ffmpeg [21:25] <ubitux> it's not really a channel for api usage [21:25] <Mavrik> on the other hand this is pretty much the only channel with people that know how api works in depth :) [21:29] <alexfu> ubitux: so... the #ffmpeg channel is not for ffmpeg users? [21:31] <llogan> #ffmpeg-devel is for FFmpeg development. #ffmpeg is for user support. [21:31] <kurosu> for development of FFmpeg, even? [21:32] <kurosu> user = user of the libav libraries [21:32] <kurosu> like the mailing lists [21:35] <wm4> Mavrik: yes, but I think ubitux feels like his questions are way too basic [21:36] <ubitux> i was just being an dick, don't mind me [21:36] <ubitux> -n [21:42] <Mavrik> wm4, hmm, yes, that might be an issue :) [21:50] <ubitux> would anyone be interested in having an advanced pkg config customization in the configure? [21:50] <ubitux> like, being able to staticly link only one (pkg-config detected) library? [21:50] <ubitux> typically what we can do with autotools [21:52] <Compn> im sure someone is interested [21:53] <alexfu> wow... i'm an idiot... forgot to specify internet permissions for my app. [21:53] <ubitux> told you you needed a network connection... [21:53] <ubitux> ;) [21:56] <cone-166> ffmpeg.git 03James Almer 07master:76a99d467fff: x86/hecv_res_add: add ff_hevc_transform_add{8,16,32}_8_avx [21:57] <wm4> http://coverage.ffmpeg.org/ [21:57] <wm4> lol only 17% for libswscale? [21:57] <ubitux> x86 [21:57] <ubitux> i thought i disabled the asm actually [21:58] <ubitux> i'm actually running the tests with CPUFLAGS=none [22:25] <cone-166> ffmpeg.git 03Clément BSsch 07master:f2f6d45dbd17: avfilter/showwaves: add "cline" mode (centered line) [22:25] <cone-166> ffmpeg.git 03Clément BSsch 07master:ba29746feb54: avfilter/showwaves: split out draw sample code [22:25] <cone-166> ffmpeg.git 03Clément BSsch 07master:e35fb5add45c: avfilter/showwaves: add split_channels option [22:27] <ubitux> ./ffplay -f lavfi "amovie=$HOME/samples/test.flac,asplit=2[out0][w];[w]showwaves=mode=cline:split_channels=1:s=640x480[out1]" [22:28] <ubitux> not exactly crazy but well... :) [22:28] <ubitux> note: i'm working on extracting the whole song in a single frame [22:30] <cone-166> ffmpeg.git 03Clément BSsch 07master:5abcc8e1a0e2: doc/filters: fix cline option name recently added [22:32] <cone-166> ffmpeg.git 03Clément BSsch 07master:e298b2f5d6db: avfilter/showwaves: align const mode values (cosmetics) [22:32] <j-b> VDD registration is almost over [22:33] <llogan> i wish i could have gone. always wanted to visit that area. [22:34] <ubitux> michaelni: no comment on codecview? (more than half of the code in it is yours) [22:55] <michaelni> ubitux, comment added [22:57] <ubitux> ah cool, thanks for the sample [22:58] <ubitux> michaelni: inserting the filter in ffmpeg won't solve the problem for ffplay [22:58] <ubitux> the code is still kept anyway, the warning should be enough for the time being [23:20] <ubitux> mmh i think i messed up something with the mv exports [23:21] <ubitux> since the coordinates can be outside the frame [23:21] <ubitux> i need to make the src[xy] and dst[xy] signed [23:30] <wm4> why would you even put effort into keeping the command line compatible for this [23:32] <ubitux> wm4: https://encrypted.google.com/search?hl=en&q=vismv [23:32] <ubitux> it's probably used somehow a bit [23:32] <ubitux> but the deprecation process should be fine [23:33] <wm4> most of these are ffmpeg ml posts... [23:33] <ubitux> it's probably not used for anything critical so yeah it's fine to deprecate it [23:33] <ubitux> i don't think a compat layer is necessary [00:00] --- Thu Aug 21 2014

1 0

ffmpeg.log.20140820
by burek 21 Aug '14

21 Aug '14

[00:30] <A__> Um... [01:54] <lockylucy> I want to live broadcoast my current desktop screen and than play that stream in a html file that is on the same machine. I then want to publish that html site to the internet so everybody can see that stream. in other words; broadcoast my desktop to my desktop and then make it viewable through a site that runs locally. I searched for good ways to do this and the best way I THINK is with ffmpeg (libav now). [01:54] <lockylucy> but the sample's i've seen stream it to a udp://192.x.x.x. is it possible for me to play that udp://192.x.x.x stream embedded in a locally hosted website? [01:59] <llogan> lockylucy: what do you mean by "libav now"? [01:59] <lockylucy> llogan: sorry, should mention that I use ubuntu server and that it's deprecated there now [02:01] <llogan> we can only support ffmpeg from FFmpeg here [04:59] <amish_ninja> join [04:59] <amish_ninja> interesting [04:59] <amish_ninja> Anyone familiar with receiving errors on a direct show capture device after setting a framerate of any type? I get the following regardlesss "No such file or directory" [10:10] <KU0N> Hello [10:13] <KU0N> I'd like to cut a video with -vcodec copy, but I'd like it to be frame precise. How can I re-encode the video from the first frame up to the first keyframe, then use vcodec copy between keyframes then again reencode up to the final frame. For example, I have a 20 sec video with keyframe at 0, 5, 10, 15, 20 . If I cut from sec 2 to 17, I'd like sec 2->5 to be rencoded, sec 5->15 to be vcodec copy and 15->17 to be rencodec. [10:43] <Mavrik> KU0N, ugh [10:43] <Mavrik> that sounds like a horrible thing to do [10:43] <Mavrik> just reencode everything -_- [10:44] <KU0N> I need it to be done very quickly [10:45] <KU0N> if I cut 10 minutes in a 2h video, I need it to be done in less than 500ms [10:48] <KU0N> with vcodec copy it takes about 400ms to cut 10minutes in an hours long 1080p vid, but the output file is not frame perfect [11:21] <Mavrik> KU0N, cut a slightly larger piece [11:21] <Mavrik> and reencode that one [11:22] <KU0N> http://stackoverflow.com/questions/25400649/precise-cut-of-remote-video-file [11:42] <Mavrik> you can't just blindly splice together frames encoded with different settings [11:42] <Mavrik> in best case it'll look wierd, in worst case you'll choke decoders [11:50] <KU0N> mavrik mmh, can ffmpeg give me the timing info and extract keyframe->keyframe segment? For example, let's say I have my 20 sec vid with keyframes every 5 sec, I do ffmpeg -ss 7 -i .. -t 6 to get from sec 7 to 13, ffmpeg sees keyframes at sec 5 and 15 and, extract a 10 sec long vid and report "start: 2, end : -2" which means play from sec 2 to sec -2. [11:51] <Mavrik> ffprobe (and ffmpeg with info filter) can give you information on per-frame basis [11:51] <KU0N> This way I can add a header to the HTTP response and have a custom HTML5 player seeking to sec 2 and stoping at sec -2 [11:54] <KU0N> I'll dig this route, thanks. [14:36] <polylux> good afternoon [14:37] <polylux> quick one about looping a video, what's the best way? just seek to frame zero? [16:34] <tmkt> Hey Hey..trying to create a thumbnail from a video if i go 70x70 it works fine for the size, but 50x50 and i get sws: filterSize 273 is too large, try less extreme scaling or set --sws-max-filter-size and recompile [17:24] <Technicus> Hi, I'm trying to convert a file with: "ffmpeg -i in_file.MP4 -ab 128 -b 7772632 -vcodec out_file.mov". The output I get is: "[aac @ 0x147c7e0] The encoder 'aac' is experimental but experimental codecs are not enabled, add '-strict -2' if you want to use it.", when I include '-strict -2' it produces the same result. How do I get this file to convert? [17:38] <Technicus> https://gist.github.com/Technicus/a7ac5cdcf3e4b805b908 [17:39] <c_14> -strict -2 is an output option, not an input option [17:39] <c_14> place it before 04_test.mov [19:16] <llogan> polylux: i know of no simple ways unless your player can do it. a lame method: https://trac.ffmpeg.org/wiki/How%20to%20concatenate%20%28join%2C%20merge%29… [19:17] <llogan> "loop a video" [19:24] <Wulf> Hi [19:25] <Wulf> I encoded a video with ffmpeg, it works for me but other people claim that they can't play it. How would I convert it to a "more compatible" video format? [19:27] <Wulf> llogan: http://codepad.org/kxjYxLec [19:27] <llogan> can you show the console output too? [19:27] <Wulf> llogan: no, don't have it anymore [19:27] <llogan> then i can only guess. [19:28] <llogan> how are they playing the output? which players? [19:28] <Wulf> llogan: no idea. One person is presumely using a macbook [19:28] <Wulf> *presumably [19:29] <llogan> 1. get a recent ffmpeg version 2. add "-pix_fmt yuv420p" as an output option. 3. change the input "-r 10" to "-framerate 10" and remove the output "-r 10" [19:29] <llogan> add "-movflags +faststart" as an output option if viewers are watching via progressive download (like from a web browser) [19:30] <Wulf> height not divisible by 2 [19:32] <llogan> libx264 with 4:2:0 chroma subsampling requires height and width divisible by 2 meaning you may have to crop, pad, or scale. [19:32] <Wulf> llogan: http://codepad.org/6gw6Mi2d [19:34] <llogan> ffmpeg -i input.mp4 -c:v libx264 -vf crop=iw=ih-1,format=yuv420p -movflags +faststart output.mp4 [19:34] <llogan> wait, why are you re-encoding the mp4 file? [19:35] <Wulf> llogan: don't have the other files anymore [19:35] <llogan> your console output shows the input is yuv444p which is not decodeable be quicktime, etc [19:36] <llogan> anyway, the example i provided may work for you [19:36] <llogan> and them [19:36] <Wulf> llogan: thanks, I reencoded it. I'll have them check if it plays now :) [19:37] <llogan> there's a typo. should be crop=iw:ih-1 [19:47] <Azelphur> Hi folks, I've been using VLC to live stream my screen, which works reasonably well but the latency is far too high. Does anyone know if ffmpeg can stream my screen over the network, with minimal latency/buffering? [19:49] <Mavrik> latency is dependent on your infrastructure, configuration and pipeline [19:49] <Mavrik> not so much on software... so you'll have to learn what you're doing I'm afraid [19:50] <Azelphur> Mavrik: the trick I'm trying to pull off here is using an Android tablet as a second monitor, so the stream would be over WIFI on LAN, so the bandwidth and infrastructure is of little concern (802.11n should be fast enough and very low latency) [19:50] <Azelphur> my approach with VLC worked, but it has 4+ seconds of latency on it sadly [19:51] <Mavrik> yes because your pipeline buffers video aggresively [19:51] <Azelphur> indeed, I'd need it to...not do that :) [19:51] <Mavrik> and no, infrastructure is NEVER of little concern when you want low latency video ;) [19:52] <Mavrik> yeah, you'll have to tweak VLC encoding parameters to minimize buffers and encode for minimal latency [19:52] <Mavrik> and make sure your player doesn't buffers too much and that your network equipment doesn't buffer too much ;) [19:52] <Azelphur> Mavrik: well as much as any advice is appreciated, I was wondering about trying ffmpeg since I spent about 6 hours last night trying to get VLC to lower the buffer size without any luck ;) [19:53] <Azelphur> although I imagine VLC (for Android) would still need to be the video client [20:23] <DarkIT1> hi [20:23] <DarkIT1> is it possible ffmpeg to use mp4 and stdout? [20:23] <DarkIT1> my command: ffmpeg -i sample.mp4 -filter_complex "drawtext='text=\"Sample Text\"':x=(w-text_w)/2:y=(h-text_h-line_h)/2:fontsize=40:fontcolor=white:fontfile=TimesNewRoman.ttf:enable='between(t,1,5)'" -f mp4 - [20:24] <DarkIT1> but I received error: [20:24] <DarkIT1> ... [20:24] <DarkIT1> [mp4 @ 0x10400d200] muxer does not support non seekable output [20:24] <DarkIT1> & [20:24] <DarkIT1> Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument [20:24] <DarkIT1> Conversion failed! [20:52] <llogan> DarkIT1: the mp4 muxer does not support non seekable output. why do you want mp4? [20:53] <DarkIT1> because input file is mp4 [20:54] <DarkIT1> I have to return the same file but with added text [20:54] <llogan> why not output a file instead of -? [20:57] <DarkIT1> becuase I want to real time render - not wait untill all big video file is ready and then return to client. But render and return as any data is ready [21:02] <llogan> DarkIT1: use a different muxer [21:04] <DarkIT1> do you mean don't use mp4 ? [21:04] <Mavrik> yes [21:04] <Mavrik> mp4 isn't a streamable format and cannot be written to a stream. [21:04] <Mavrik> (target has to be seekable) [21:05] <DarkIT1> which streamable format is the best for web video? [21:06] <Chaz6> Best is subjective [21:06] <DarkIT1> :) [21:07] <DarkIT1> most non-problematic for web browsers [21:07] <Mavrik> Hah. [21:07] <Mavrik> No such thing. [21:07] <Mavrik> Sorry :) [21:07] <Mavrik> Restructure your infrastructure or invest into a streaming server. [21:08] <llogan> it's hard to provide information without knowing what you are doing. you are piping output, but then ask about "web video". [21:08] <DarkIT1> I have service which should add text and images to existed video and return them ASAP [21:09] <DarkIT1> clients are web browsers [21:09] <DarkIT1> that why I dont want to write to file and then return this file because it's too long to wait [21:09] <Mavrik> You'll have to use RTMP or HLS in Flash then. [21:10] <Mavrik> or just bear with the delay [21:11] <DarkIT1> I see [21:11] <DarkIT1> thanks a lot [21:12] <Mavrik> DarkIT1, basically the issue is that MP4 has a file index as part of structure [21:12] <Mavrik> which cannot be written (because it has direct byte offsets in there) before the actual content is written [21:12] <DarkIT1> I understand [21:12] <Mavrik> of course, if you want to play it in the browser, that index has to be at the start of the file (or the users will have to download it in full) [21:12] <Mavrik> hence ffmpeg reserves space, writes file, then returns to write the index in the MOOV atom [21:13] <DarkIT1> as for streaming is mp4 OK as source file or it's better to prepare in another format? [21:13] <Mavrik> MP4 is the most widely supported format and it's "ok" for HTML5 video if it's quickstarted [21:13] <DarkIT1> Mavrick: but it can be fixed by -movflags faststart, right? [21:13] <Mavrik> it's not the most efficient one (it'll burn alot of bandwidth, especially for seeking) but it's okish [21:14] <Mavrik> faststart moves MOOV from end to start yes, but that can only be done in a file and after the video is fully encoded [21:14] <Mavrik> (you can have segmented MP4 but that doesn't help your use-case) [21:14] <Mavrik> that's why MPEG has a MPEG2-TS standard for streaming, but sadly no browser (except for Safari and mobile devices) supports TS muxed video [21:17] <DarkIT1> :( [21:18] <Mavrik> so, use HLS [21:18] <Mavrik> and use Flash-based player on your site for browsers that don't support it if that's so important for you [21:18] <Mavrik> do whine to Chrome and Firefox to support HLS on desktop. [21:29] <DarkIT1> do you mean that flash supports MPEG2-TS [21:40] <ArunC> Hi, I have a 10 hour long video file and a 8 core box. Using libavcodec, will I be able to decode the frames from the video file using all the cores? [21:43] <sacarasc> Depends on the codec. [21:46] <ArunC> sacarasc: Thanks. If that's not possible, I am thinking of a data parallel architecture where a master thread will send the video filename to all the workers (bound to their respective CPU core) and their start time and end time OR start frame number and end frame number. [21:47] <ArunC> sacarasc: Is it possible to achieve this accurately without missing any frames in the video? [21:47] <Mavrik> what is your goal really? [21:48] <Mavrik> what inputs do you have? [21:48] <Mavrik> what is the desired output? [21:48] <Mavrik> what is the desired use-case of video output? [21:48] <Mavrik> you're asking specific questions without providing specific information :) [21:48] <ArunC> My goal is to decode long videos and perform face detection on them. [21:49] <ArunC> Input: video file, probably from NFS. I can copy that to local. [21:49] <Mavrik> in that case decoding the vieo will not be nearly your bottle-neck [21:49] <Mavrik> so in your place I really wouldn't worry about that until you can optimize your face detection libraries to the point where video decode is the bottle-neck [21:49] <ArunC> Desired output: RAW or JPEG images [21:49] <Mavrik> just make sure you're processing frames in parallel [21:50] <Mavrik> ArunC, btw, when we're talking about video encoding [21:50] <Mavrik> usually "video file" isn't a specific enough answer :P [21:50] <ArunC> Mavrik: ah, OK. [21:50] <Mavrik> because whether the decoder supports multi-threaded decoding is dependant on what kind of video format you have inside your container :) [21:50] <Mavrik> some decoders support multithreaded decoding, some don't [21:51] <ArunC> The video file could be of any type (MPEG4, x264, etc) [21:51] <ArunC> OK.. [21:52] <Mavrik> but as I said, all CV and face detection work I did was heavily bottlenecked by CPU use of the main detection algorithm [21:52] <Mavrik> video decoding wasn't an issue [21:52] <ArunC> When the number of cores are less, say, 8 the video decoding is not a bottleneck. But it will become a a bottleneck on my 32 core box. [21:53] <ArunC> Yeah, my face detection is not a bottleneck on a 32 core box. [21:53] <Mavrik> did you test that? [21:53] <ArunC> Just an emperical calculation. Let me explain that. [21:53] <Mavrik> did you test that the decoder won't keep up with processing algorithms? [21:56] <ArunC> The video decoding using ffpmeg took around 800 fps. My face detection takes less than 20 ms, which is roughly 50 fps. On a 32 core box, I could parallelize it to 1600 detections per second. [21:57] <Mavrik> point [21:57] <Mavrik> yeah, you could slice up the video [21:57] <Mavrik> I'm just not sure if frame-accurate seeking is in ffmpeg yet [21:58] <vlatkozelka> hi .. can anyone help me ? [21:58] <Mavrik> I doubt it. [21:58] <ArunC> Oh OK. Generally is the seeking done using frame number or the time in the video? [21:58] <iive> vlatkozelka: nobody can help you, [21:58] <iive> vlatkozelka: until you say what the problem is... [21:58] <Mavrik> ArunC, last I checked the API had only time based seeking [21:58] <vlatkozelka> ok [21:59] <Mavrik> but that might have changed. [22:01] <vlatkozelka> Im trying to save a udp stream containing TV channels onto segments ... the recording is fine but , the timestamp is being reset so start is 00:00:00 , everything else is good . I tried -copyts but didnt work and made things worse , now it records like 30 1 second long ts files then the rest the time i need but still timestamps are reset . [22:02] <ArunC> Mavrik: thanks, should I check in #ffmpeg-devel? [22:02] <Mavrik> check what? [22:02] <Mavrik> check the documentation first :P [22:02] <ArunC> :) sure, thanks. [22:05] <vlatkozelka> here are code and logs [22:05] <vlatkozelka> http://pastebin.com/pRWBaSad [22:47] <vlatkozelka> Im trying to save a udp stream containing TV channels onto segments ... the recording is fine but , the timestamp is being reset so start is 00:00:00 , everything else is good . I tried -copyts but didnt work and made things worse , now it records like 30 1 second long ts files then the rest the time i need but still timestamps are reset . [22:47] <vlatkozelka> http://pastebin.com/pRWBaSad [23:41] <RaZoR37> hello! Excuse me, anyone can explain me how to install ffmpeg ? thanks you =) [23:45] <llogan> RaZoR37: what OS? [23:46] <RaZoR37> window vista [23:46] <RaZoR37> 32bitq [23:48] <llogan> no need to install in a traditional sense. just download, extract, then run it in cmd or whatever Windows users use [23:48] <RaZoR37> okay thanks! but i don't know how to run it in cmd [23:49] <llogan> press shift, then right click the "folder" containing the ffmpeg binary, then click "open in cmd" or whatever it says. then in cmd just type "ffmpeg -i input output" [23:49] <llogan> Actual Windows users here may have a better clue than me. [23:50] <llogan> you may need 7-zip or equivalent to extract the archive containing ffmpeg [23:50] <RaZoR37> hmmmm ok, yep i already extracted [23:51] <RaZoR37> so i lunched in cmd, now if i want to stream a rtmp link in vlc, what's the cmd ? thanks again! [23:52] <llogan> sorry, but i don't quite understand what you're trying to do [23:53] <RaZoR37> i need to open a rtmp video in vlc [23:54] <vlatkozelka> do u need to do that from CLI ? [23:54] <vlatkozelka> or np using the vlc GUI ? [23:54] <vlatkozelka> cuz u dont need ffmpeg for i think [23:54] <RaZoR37> i tried whith rtmpGUI but this is not working [23:55] <vlatkozelka> hmm [23:55] <vlatkozelka> do u have link for that rtmp ... or maybe its private [23:55] <RaZoR37> unfortunelly it's private [23:55] <vlatkozelka> well [23:55] <RaZoR37> i found a fail into a website [23:56] <llogan> you should ask the videolan guys for help if you're using vlc. i'm not sure how ffmpeg is involved here [23:56] <vlatkozelka> u can do it with ffmpeg w/o vlc [23:56] <RaZoR37> maybe ffmpeg is not what i need, maybe i need rtmpdump ? [23:56] <vlatkozelka> for example u could save the stream onto a ts file [23:56] <vlatkozelka> if that suits u [23:57] <RaZoR37> the question is : how ? ^^ [23:57] <vlatkozelka> u built ffmpeg ? [23:57] <RaZoR37> built ? you mean run in cmd ? [23:57] <RaZoR37> sorry my english is not perfect haha [23:57] <vlatkozelka> no i mean do u have a working ffmpeg build ? [23:58] <RaZoR37> i don't think so [23:58] <RaZoR37> i have ffmpeg 2.3.3 [23:59] <vlatkozelka> ok [23:59] <vlatkozelka> open cmd [23:59] <vlatkozelka> and type ffmpeg.exe just to make sure everything is working [00:00] --- Thu Aug 21 2014

1 0

ffmpeg-devel.log.20140819
by burek 20 Aug '14

20 Aug '14

[02:14] <cone-101> ffmpeg.git 03Michael Niedermayer 07release/1.2:4ce6d65b6fbe: Changelog: update for 1.2.8 [03:26] <cone-101> ffmpeg.git 03Michael Niedermayer 07release/1.2:59b2a9ef957e: remove VERSION file [03:26] <cone-101> ffmpeg.git 03Michael Niedermayer 07release/1.2:0a64e9a0299b: version.sh: Print versions based on the last git tag for release branches [03:46] <cone-101> ffmpeg.git 03Lukasz Marek 07fatal: ambiguous argument 'refs/tags/n1.2.8': unknown revision or path not in the working tree. [03:46] <cone-101> Use '--' to separate paths from revisions [03:46] <cone-101> refs/tags/n1.2.8:HEAD: lavu/log: add device category macros [05:54] <jamrial> https://gcc.gnu.org/develop.html#num_scheme Oh boy [05:54] <jamrial> everybody wants to be like chrome [06:29] <mark4o> nobody wants an x.10 version number [06:29] <mark4o> Except Apple, who can't get enough 10's ever since making X/10 part of the OS name OS X 10.10. [07:57] <Kovensky> jamrial: so they're formalizing the notion that .0 releases are bad [08:40] <plepere> good morning [08:41] <nevcairiel> Morning [09:50] <kurosu__> plepere, hi [09:51] <kurosu__> plepere, are there plans for you to spend time submitting patches for idct ? [09:51] <kurosu__> the transform_add is, if I'm not mistaken, a small stepping stone [09:52] <kurosu__> plepere, I'd suggest adding small bits of the transforms, eg start with 4x4 dst/dct then 8x8 [09:53] <kurosu__> 16x16 and 32x32 are already large beasts in getting them to work in yasm [09:54] <plepere> I can do that. :) [09:55] <plepere> kurosu__, it seems that we have some ASM idct_dc functions [09:55] <plepere> if that's the question [09:56] <kurosu__> yeah, but the actual idct are useful/needed [09:56] <kurosu__> what you have as intrinsics in openhevc is like 20-40% speedup, so that's a major thing missing [09:56] <kurosu__> *full idcts [09:57] <nevcairiel> after i applied the idct and sao intrinsics, final performance was over 100% faster than ffmpeg master today [09:57] <plepere> yeah [09:58] <plepere> but the problem is that intrinsics doesn't have a register limit, so it cheats quite well [09:59] <kurosu__> nevcairiel, is that for toying around or do you plan to have the patched code used eg in some distributed software (not a license issue, just bug issues) [09:59] <ubitux> 4x4 and 8x8 should not hit the register limit [09:59] <nevcairiel> i'll probably have it in the distribution of my software, but those people report their problems to me anyway [10:00] <kurosu__> nevcairiel, ok [10:00] <kurosu__> is that using my branch or yours? I'm asking because of my proposed multithread api [10:01] <plepere> Ok, I'll try to do the transforms. :) [10:01] <kurosu__> so far I'm the only one having an interest/figures, and so I'm wondering if an improvement is seen on other more-than-2-cores systems [10:01] <nevcairiel> kurosu__: i just applied the intrinsics [10:02] <kurosu__> ok [10:02] <nevcairiel> and manually at that, not picked from your tree [10:03] <kurosu__> nevcairiel, so did I, it's not a merge from openhevc, just a hack job [10:05] <nevcairiel> i applied the gcc pragmas, so i can still build the main code without the high sse requirements [10:05] <nevcairiel> i hope gcc works properly with those options :P [10:08] <nevcairiel> in a couple weeks i could possibly test the threading changes on a 6-core X99 platform, but considering the hardware isnt even available yet, it'll still be a bit [10:12] <kurosu__> iirc sse4 is needed for hevc mc only for pextrw, and that's for small, hardly used, chroma partitions [10:34] <__gb__> hi wm4, libva itself is not thread-safe, that part is delegated to the driver [10:34] <__gb__> On the Intel HD Graphics side, there seems to be a render mutex held during output to X11. Though, that does not preclude anything to other bits/operations... [10:36] <__gb__> wm4, anything specific to expose issues? on what display backend? [11:35] <cone-383> ffmpeg.git 03Ben Hagen 07master:c9a5497a0b4d: avformat/cinedec: allow number zero in metadata [12:21] <Daemon404> wm4, https://www.dropbox.com/s/hewentitmd4n0db/deb1.png [12:21] <Daemon404> sigh. [12:21] <Daemon404> definitely worth privately mailing me. [12:24] <nevcairiel> debian folks are special kind of weirdos [12:24] <Daemon404> https://www.dropbox.com/s/mxhpq93wfcul6nk/deb2.png [12:25] <Daemon404> ^ i replied by trolling [12:25] <Daemon404> ;) [12:25] <Daemon404> (text looks weird cause im RDPing from a high dpi box to a server that i originally logged into from a low dpi box... :MS:) [12:31] <Compn> Daemon404 : should have replied with, ' i added it to my TODO *Do Not Troll' :P [12:32] <Daemon404> lol [12:32] <Daemon404> dammit Compn [12:32] <Daemon404> that would have indeed been better [12:53] <ubitux> /home/ux/fate/ffmpeg/libavcodec/mpegaudiodec_template.c:1546:1: internal compiler error: Segmentation fault [12:53] <ubitux> ... [12:53] <ubitux> ffs [12:53] <Daemon404> haha. [12:54] <ubitux> not sure what's going on here, i didn't change anything on the box [12:55] <Daemon404> ubitux, it picked a lovely file to ICE on too [12:55] <ubitux> :) [13:03] <cone-383> ffmpeg.git 03Pavel Koshevoy 07master:6380f2e3670a: avfilter/atempo: Flush all buffered input samples [13:19] <nevcairiel> could be worse, could be mpegvideo [13:32] <BBB> Daemon404: I call this the last-word-theory [13:33] <BBB> Daemon404: saw it a lot in gnome - as a thread grows longer, the usefulness of replies goes towards zero; but people will keep iterating the same general themes, because if youre the last response, youve won [13:34] <Daemon404> fun [13:34] <BBB> debian is just like that [13:35] <BBB> I see a sine wave of reply-recursion, where after a week, Ive quite literally seen it all [13:35] <Daemon404> have you heard the word of our Lord and savior, gerrit, BB? [13:35] <Daemon404> BBB* [14:01] <cone-383> ffmpeg.git 03Christophe Gisquet 07master:1467780772d6: huffyuvenc: add a non-deterministic option [14:17] <BBB> Daemon404: I did! it prevents world hunger and saves bickering and infighting, just by means of a simple credo and policy: thy shallt review! [14:17] <BBB> Daemon404: and voila, all evil vanishes! [14:20] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:76a8cb9d7bcc: avcodec/proresenc_kostya: set initial max_slice_size based on frame_size_upper_bound [14:20] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:f0e51be8d027: avcodec/proresenc_kostya: allocate 1 slice more to avoid triggering the reallocation warning when the used space is actually less than the allocated [15:40] <cone-383> ffmpeg.git 03Paul B Mahol 07master:02dc75f218e9: avcodec/pafvideo: remove unused header [15:40] <cone-383> ffmpeg.git 03Paul B Mahol 07master:9a07c15f4893: avcodec/pafaudio: use paf.h instead [16:06] <alexfu> I've got the following code... http://pastebin.com/8rUVQxc0 and i get a stange warning at the bottom... not sure exactly what that means [16:07] <Daemon404> it's exactly what it says. [16:07] <Daemon404> https://www.ffmpeg.org/doxygen/trunk/group__lavc__core.html#gae80afec6f26df… [16:07] <Daemon404> you are not passing what it is supposed to take. [16:08] <alexfu> Daemon404: oh shoot. i thought i was passing a codec [16:10] <alexfu> i'm actually surprised thats a warning [16:13] <alexfu> is it possible to get a codec context from a newly allocated avformatcontext? [16:13] <alexfu> i would assume format_context->streams[i]->codec->codec_type would only work if it has data in it [16:14] <cone-383> ffmpeg.git 03rogerdpack 07master:ea97859c8c21: gdigrab: fix gdi object leak if using mouse [18:01] <cone-383> ffmpeg.git 03Christophe Gisquet 07master:11a39bdf534a: wavpack: report if there is no bits left [18:16] <cone-383> ffmpeg.git 03Christophe Gisquet 07master:2ba58bec20b0: wavpackenc: proper buffer allocation [18:30] <kurosu__> what part of libav* would deal with conversion of rgb formats with different packings ? [18:31] <kurosu__> I'm asking this because the ljpeg decoders selects RGB48 for any bitdepth >8, and then stores that in AVCodec's bits_per_raw_pixel [18:31] <kurosu__> the conversion could maybe notice that this is only a repacking without resampling or intended bitdepth change [18:31] <kurosu__> and thus copy this over to the output format [18:32] <kurosu__> allowing anything to use that info [18:32] <kurosu__> example: input is "Stream #0:0: Video: mjpeg, bgr48le(12 bpc, bt470bg), 1200x1200, 25 tbr, 25 tbn, 25 tbc" [18:33] <nevcairiel> Any such conversions are in swscale presumably [18:33] <kurosu__> output is "Stream #0:0: Video: ppm, rgb48be, 1200x1200, q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc" [18:33] <kurosu__> at least the 12bpc information could be used [18:33] <cone-383> ffmpeg.git 03Diego Biurrun 07master:86dfcfd0e30d: mov: Drop unused parameter from ff_mov_read_esds() [18:33] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:b07dc81a9e35: Merge commit '86dfcfd0e30d6645eea2c63c1c60a0550e7c97ea' [18:33] <nevcairiel> swscale isn't that smart [18:33] <kurosu__> nevcairiel, I bet so, and I intended to only check that on ffmpeg's side [18:34] <kurosu__> afaik, the scale filter seems used [18:34] <nevcairiel> But if you're lucky it just reorders the bgr to rgb [18:34] <nevcairiel> If you're unlucky, it goes through yuv [18:34] <nevcairiel> sws is fun like that [18:39] <cone-383> ffmpeg.git 03Diego Biurrun 07master:8bc52dbd9dff: vfwcap: Drop fallback VfW defines [18:39] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:c18a3b3e8ef4: Merge commit '8bc52dbd9dffb1b2fa4a6aeed2d298d036b619b2' [18:57] <kurosu__> that's probably doable in ffmpeg instead [18:57] <kurosu__> as it's a reencoding issue [19:02] <wm4> <__gb__> wm4, anything specific to expose issues? on what display backend? <- user reports weird behavior and crashes when using vaapi decoding and native vaapi output, but not when using GLX interop output (both on i965) [19:02] <wm4> __gb__: and that started to happen since the decoder runs on a separate thread [19:06] <__gb__> wm4, surprising, I would have actually expected the opposite case to happen :) [19:07] <__gb__> though I remember a discussion on libav-devel and I was actually ok to remove the lavc side lock so that to expose bugs in driver [19:07] <__gb__> so, it seems there are then. do you have a self-contained test case handy around? [19:08] <__gb__> anyway, I have one around for FFmpeg/vaapi demonstration purposes, but not decoding in a separate thread yet [19:09] <wm4> __gb__: no, I just have my player code (mpv), a rather big thing; but I'm not doing much special [19:09] <wm4> though it's true that it's still possible that the error is on my side [19:10] <__gb__> I will try to remember about it for my TODO, but no immediate promise :) [19:10] <nevcairiel> In the not too far future I'll venture into that area as well. [19:10] <nevcairiel> Fix all the bugs before! [19:10] <nevcairiel> :D [19:11] <cone-383> ffmpeg.git 03Diego Biurrun 07master:d456baafb68c: vc1: Add missing parentheses to conditions in vc1_decode_b_mb_intfr() [19:11] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:580e81fca578: Merge commit 'd456baafb68cd80c0f537f1d843076e4dd853558' [19:12] <nevcairiel> Although I'll probably stick to glx interop, don't feel like multiple outputs [19:12] <wm4> I'm just very confused that something as fragile as GLX interop works well (you'd expect that it's harder to make it thread-safe) [19:13] <__gb__> yes, exactly, and from a VA intel-driver perspective, there is no native support for GLX interop, so the default code in libva is used, which definitely is not thread-safe, iirc [19:34] <alexfu> is there a way I can figure out the reason why avformat_open_input is failing? i.e is there a way to determine if the error is a file not found or file locked error? [19:35] <llogan> i'm back now. thanks for keeping up with the mail queue. [19:44] <SanJose_Kid_> hello [19:44] <SanJose_Kid_> so an issue we're facing is there is no translation b_annexb to x264 in libavcodec - so it seems [19:45] <SanJose_Kid_> were trying to stream x264 in Annex B format - any idea if this is supported ? [19:45] <llogan> SanJose_Kid_: #ffmpeg is the channel for user support [19:46] <SanJose_Kid_> i see - im pretty sure this might not be supposed by current system and would require patch / extension to framework [19:46] <iive> check the bit stream filters [19:46] <iive> bfs [19:47] <J_Darnley> perhaps it is h264_mp4toannexb you are looking for [19:49] <llogan> and x264 is an encoder, not a video format [19:49] <J_Darnley> If you're actually encoding using x264 I thought it gave you annexb anyway (or at least an option) [19:50] <SanJose_Kid_> thank you - great [19:50] <SanJose_Kid_> sorry i assumed this was not supported and mentioned in this channel [19:52] <SanJose_Kid_> thanks again [19:54] <cone-383> ffmpeg.git 03Diego Biurrun 07master:14d2006ca6c0: pcm: Drop unused variable from DECODE_PLANAR macro [19:54] <cone-383> ffmpeg.git 03Diego Biurrun 07master:6af2930222ee: pcm: Drop av_unused attribute from variable that is always used [19:54] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:4042c8eee187: Merge commit '14d2006ca6c0e2b54784b93560f09e0e19c0a270' [19:54] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:746095bc2981: Merge commit '6af2930222ee5d8ce19f3b999a78d85a3c457391' [20:15] <cone-383> ffmpeg.git 03Diego Biurrun 07master:b977b287f61f: vsrc_movie: Avoid a variable indirection in movie_get_frame() [20:15] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:b1cf83b3d4e8: Merge commit 'b977b287f61fea48ecd6251d54a26334213b7ec6' [20:19] <alexfu> is there a way to debug avcodec_encode_video2? it fails (crashes the app) without any output [20:22] <wm4> gdb? [20:27] <alexfu> wm4: i tried that but it doesnt display anything [20:28] <alexfu> nothing useful that is... all i get is "Program received signal SIGSEGV, Segmentation fault." [20:29] <alexfu> hm [20:31] <alexfu> can av_init_packet not accept NULL? [20:33] <wm4> probably not [20:41] <cone-383> ffmpeg.git 03Moritz Barsnick 07master:66d02d3ca626: align and correct messages regarding bitstream filters [20:44] <alexfu> is this workflow correct? http://pastebin.com/CCQXhA1Y [20:45] <alexfu> or am i missing something? [20:53] <alexfu> damnit.. an invalid codec would probably cause a segfault in avcodec_encode_video2 right? [21:04] <alexfu> any possible reason why when i call avcodec_alloc_context3(codec); passing in a MPEG-4 codec, the resulting codec context has an invalid codec? [21:05] <wm4> also I think you need to open the codec for encoding, but not sure [21:10] <alexfu> wm4: you seem to be correct [21:20] <alexfu> wm4: do you know if the resulting AVCodecContext (from avcodec_alloc_context3) supposed to have a NULL codec? [21:21] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:6ea69a8ffaea: avcodec/tiff: do not use photometric to detect pix_fmt [21:21] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:f0c0ae37c669: avcodec/tiff: Check that pix_fmt is a yuv variant for TIFF_PHOTOMETRIC_YCBCR [21:26] <wm4> alexfu: don't know, maybe not [22:54] <alexfu> does av_log simply write to stdout? [22:55] <wm4> by default yes, there's a global log callback which you can set to override the beavhaior [23:07] <alexfu> so i see a "08-19 17:04:40.030: I/FFMpeg(2593): Specified pixel format -1 is invalid or not supported [23:08] <alexfu> sorry, i see a "Specified pixel format -1 is invalid or not supported" message right before avcodec_open2 errors out... any idea what that possibly means? [23:10] <cone-383> ffmpeg.git 03Jon Morley 07master:18e70006e7d3: avcodec/adpcm: Fix incorrect AVSampleFormat for sample_fmts_s16p [23:20] <alexfu> do you have to specify pixel format for an encoder? [23:20] <alexfu> or is that automatic? [23:36] <Compn> depends what you are doing, probably yes [23:47] <michaelni> can i push "Re: [FFmpeg-devel] [PATCH] x86: hevc: adding transform_add" ? or someone else wants to comment? (james asked "Not sure if someone else wants to comment (Ronald?)") [23:52] <cone-383> ffmpeg.git 03James Almer 07master:b4231b4fedc2: lavc/tiff: move unpack_yuv() above the deflate functions [23:52] <cone-383> ffmpeg.git 03James Almer 07master:201a511bb9dd: lavc/tiff: add support for YUV deflate [00:00] --- Wed Aug 20 2014

1 0

ffmpeg.log.20140819
by burek 20 Aug '14

20 Aug '14

[00:25] <sirnfs> I have a video that someone sent to me which was created with Quicktime. The first three seconds of the video are essentially frozen and then the video and audio abruptly kick in. When transcoding the video, this causes the audio and video to become out of sync. Any suggestions for how to prevent the audio/video from becoming out of sync during transcoding? [00:26] <sirnfs> You can see the problem here: https://www.dropbox.com/s/ldsva3713f06ax1/6bd7b15e-1bc6-4edb-8663-9aed34269… [00:27] <sirnfs> This seems to happen quite frequently when users clip/trim video with Quicktime [01:06] <jotterbot1234> Hey guys, i am having trouble encoding wmv video [01:06] <jotterbot1234> i understand that ffmpeg does not use the latest wmv3 codec [01:07] <jotterbot1234> but even using msmpeg4 or wmv2 video codec, on "general imagery" the performace is acceptable....... [01:07] <jotterbot1234> i am just getting issues on text elements. it "flickers" between a good rendition of the text and blocky artefacts [01:07] <jotterbot1234> would something like 2 pass encoding help in those circumstances [01:18] <iive> jotterbot1234: no, 2pass would only make better bitrate tradeoff for the target bitrate. [01:19] <iive> try increasing the quality, using mv0 might be good idea too. [01:19] <iive> there shouldn't really be artefacts. i remember xvid having problem when using max quantizer 1 (aka perfect quality). [01:23] <jotterbot1234> iive: thanks mate. I have had some success switching back to the wmv2 codec from msmpeg4 [01:24] <jotterbot1234> still much larger file sizes then ideal, but the text does not flicker between blocky and normal [01:24] <iive> use mbd=2 and trellist options. they should help a lot. [01:24] <iive> trellis [01:25] <jotterbot1234> hmm, as an argument to which parameter? i haven't used that before [01:25] <jotterbot1234> i can search docs though , thank you for helping :) [01:27] <iive> i'm not quite sure where they go, i've used them from another program. [01:28] <jotterbot1234> no worries, I'm just googling those terms to determine what they actually "do" [01:30] <iive> also, if you have cpu cycles to burn, you can try different cmp functions. e.g. precmp, cmp, subcmp. these control the motion estimation algorithm, using 2 or 3 might make a difference. 5 should be slower but optimal. [01:36] <jotterbot1234> iive: could i trouble you for an exmaple command with those options [01:36] <jotterbot1234> i'm looking here: http://smorgasbork.com/component/content/article/97-real-time-mpeg-2-encodi… [01:36] <jotterbot1234> so something like "-trellis 2 -cmp 2 -subcmp 2" might help [01:50] <iive> jotterbot1234: i think trellis takes other values than 0/1 So : -mbd 2 -trellis 1 -cmp 2 -flags mv0 [01:52] <jotterbot1234> iive: thank you :) [02:06] <DoctorTrombone> How would I use ffmpeg to take several audio streams (save one) in my input file (some mono, some stereo), and mix them into one stereo output file? [03:33] <rudi_s> mencoder supported -vobsoubout to dump the subtiles as .idx and .sub files. Is this still possible with ffmpeg? [03:34] <jrgill> Does the concat demuxer produce a container with streams for each segment? [03:52] <rudi_s> I tried to convert the .vob to .mkv, but it seems the idx-"part" is not correctly transferred, as mkvextract doesn't let me extract the .idx/.sub from the resulting mkv file. [03:53] <rudi_s> (codecprivate seems to be missing.) [05:01] <jrgill> Is it possible to apply pan to the output of concat, both in the same filter_complex? I have each filter working; just not sure how to apply the both of them (-af and -filter_complex mutually exclusive). [05:02] <jrgill> I have [out] from concat and normally map this with -map. I need my pan to happen in between. [05:13] <jrgill> Ah, think I've got it. [05:58] <Eiam_> after completing a `make install` for yasm 1.3, I try to ./configure for ffmpeg 2.3.3 and im told that yasm isn't found.. but its there.. [05:58] <Eiam_> > which yasm [05:59] <Eiam_> ./configure --prefix=$OPENSHIFT_DATA_DIR/bin --bindir=$OPENSHIFT_DATA_DIR/bin -> fail [06:00] <Eiam_> whoops IRC ate the which yasm, but it shows it there in data/bin/yasm [07:21] <jrgill> Any tips for trimming with full timestamp? Before I had atrim=35:40 now trying something like atrim=00\:00\:35.00:00\:00\:40.00 which isn't working. [07:26] <jrgill> (time duration format rather) [07:27] <Eiam_> ah figured it out [07:27] <Eiam_> had to force the env to point the right place on PATH [07:51] <jrgill> Well, finally got it even though it's pretty nasty. atrim='00\:00\:35.00:00\:00\:40.00' [10:21] <Meriipu> so I am trying `ffmpeg -s 1x1 -f rawvideo -i /dev/urandom out.mp4` but libx264 complains that width is not divisible by 2, is there anything I can do? [10:23] <ubitux> video codecs are not designed to support arbitrary sizes, for performance and simplicity [10:24] <Meriipu> I see [11:24] <svvitch> I compiled ffmpeg with this options https://dpaste.de/06cV , now I'm trying to open an input stream over http protocol and it fails, what conf options i missed ? [11:25] <cdecl_xyz> Hello I have a question regarding color space conversions. in sws_getContext, sws_setColorSpaceDetails gets called with ff_yuv2rgb_coeffs[SWS_CS_DEFAULT] for input and output color space range. my question is, if I want the OUTPUT color space output to be SWS_CS_ITU709 or FULL_RANGE, do i also have to set the input color space? I assume yes. But then I would have to know which space the source is in right? This poses a problem. And does [11:25] <cdecl_xyz> SWS_CS_ITU709 also apply if I convert to RGB? [11:26] <relaxed> svvitch: does "ffmpeg -protocols" list http? maybe you need https support? [11:26] <Mavrik> cdecl_xyz, you always have to know what your input color space is [11:27] <Mavrik> there's no way to guess from image itself you know [11:27] <cdecl_xyz> thanks [11:27] <cdecl_xyz> i thought so [11:27] <Mavrik> but I'm not sure about more exact details of what you have :/ [11:27] <Mavrik> I've never tried doing such fine grained conversion [11:27] <cdecl_xyz> i cant assume anything abou tthe input file [11:27] <cdecl_xyz> mostly mpeg2 or prores [11:27] <cdecl_xyz> but can also be h264 in mp4/mkv [11:27] <cdecl_xyz> so yes, I thought so already. I will probably ask the user to define the input space [11:28] <cdecl_xyz> do you know if this also applie swhen converting from yuv to rgb? [11:28] <cdecl_xyz> i cant find a function yuv2rgb in swscale, only rgb2yuv [11:29] <svvitch> fflogger: ok, just a minute [11:30] <relaxed> svvitch: fflogger is a bot, fyi [11:31] <svvitch> relaxed: ;) [11:32] <Mavrik> cdecl_xyz, if what applies really? [11:32] <Mavrik> swscale can do YUV to RGB conversion [11:32] <cdecl_xyz> yes i Know i do it already [11:32] <drakeguan> Hi, just wondering if this is the right channel to ask about the result of ffprobe? [11:32] <cdecl_xyz> but if i specify output color space to be ITU709 [11:32] <cdecl_xyz> and do a yuv2rgb conversion or a rgb2rgb conversion [11:33] <cdecl_xyz> will the rgb values then be in the range of ITU709? [11:33] <cdecl_xyz> with rgb2rgb i mean (rgb full range to rgb 709( [11:33] <Mavrik> isn't ITU709 a YUV definition? which is basically just a flag on a stream? [11:34] <Mavrik> and makes no sense in RGB context? [11:34] <svvitch> relaxed: http://pastie.org/9485222 I think problem is not in protocol [11:34] <Mavrik> drakeguan, probably :) [11:34] <cdecl_xyz> http://en.wikipedia.org/wiki/Rec._709 [11:34] <cdecl_xyz> and no its not a flag [11:34] <drakeguan> Mavrik: thx cause it looks like http://ffmpeg.gusari.org/viewforum.php?f=27&sid=8fc1f2eaf1d6fa515dd8f6d0663… is not that active. [11:34] <cdecl_xyz> it restricts the values of rgb to be within i think 16 and 231 or so [11:34] <svvitch> relaxed: -protocols : this list active protocols in ffmpeg ? [11:35] <cdecl_xyz> so if you have an rgb image full range, then black is 0, but with itu709 its 16 [11:35] <Mavrik> ah, yeah, I know what do you mean [11:35] <relaxed> svvitch: is that all of the console output, or did it get cut off? [11:35] <Mavrik> I'm not sure really, RGB support is not as developed due to practically no video codecs supporting it [11:36] <svvitch> relaxed: it's all [11:36] <cdecl_xyz> i am putting the decoded frames into my jpeg2000 encoder [11:36] <cdecl_xyz> i dont use avcodec to do the encoding as I need 100% broadcast conform jpeg2000 files [11:36] <drakeguan> For ffprobe, I'm confused the relationship between probed `codec_time_base` and `avg_frame_rate` (assuming the stream's frame rate is fixed). Given one MPEG_PS file, I got "codec_time_base": "1001/48000" and "avg_frame_rate": "24000/1001". Does that mean I can conclude this video stream is interlaced? [11:37] <cdecl_xyz> but the decoding must be well defined, i need more info about how swscale does color space stuff [11:38] <relaxed> svvitch: does it work without using tee? [11:38] <Mavrik> I'm afraid you'll just have to read the source :/ [11:38] <Mavrik> drakeguan, no, not really [11:38] <Mavrik> drakeguan, for alot of codecs you can set timebase for anything and it does not imply anything [11:39] <Mavrik> so you can't really rely on that :/ [11:39] <Mavrik> also, for example for H.264, it's not even required that all frames are interlaced or not - that's set on perframe basis [11:39] <Mavrik> which makes detection of interlaced video a serious problem [11:40] <svvitch> relaxed: yes this works http://pastebin.com/EYEhaqD6 [11:40] <svvitch> relaxed: problem is not in protocol [11:40] <Mavrik> drakeguan, if you know that your stream will reliably be one thing or another, use -show_frames for ffprobe and grab information from first decoded frame [11:46] <drakeguan> Mavrik: Thanks a lot. I'm quite surprised to know that timebase doesn't imply anything! [12:21] <bigzed> hello [12:22] <coalado> hi. I know that ffmpeg guesses the output format from the file extension. I want to use a different extension, and this have to use the -f format switch. [12:23] <coalado> but while ffmpeg test.m4a works, ffmpeg -f m4a test.tmp does not work [12:23] <coalado> is there any way to access the internal extension->format map ? [12:24] <Mavrik> coalado, m4a is a different name for mp4. [12:24] <Mavrik> so that's what causing you issues, name of format is "mp4" :) [12:24] <Mavrik> the map is just written in source code I'm afraid [12:28] <coalado> Mavrik: I only have the file extension. I need some kind of mapping. [12:29] <coalado> If I execute ffmpeg dummy.m4a I could parse the output Output #0, ipod, to 'dummy.m4a': , delete the file, and use -f ipod for the actual execution [12:30] <coalado> But that's kind of dirty [12:31] <Mavrik> use ffprobe and it's JSON output. [12:31] <Mavrik> that's why it's there for. [12:33] <coalado> ffprobe can be used to analyse actual files/streams. How should I use it to get outputfile mapping? [12:35] <svvitch> I found that ffprobe does not return video bitrate http://pastie.org/9485629 , is this a common issue ? [12:36] <Mavrik> svvitch, your pasties don't work [12:37] <svvitch> Mavrik: http://pastebin.com/37BQMqpw [12:40] <Mavrik> svvitch, doh [12:40] <Mavrik> you're just asking for stream information [12:40] <Mavrik> not container (format) information :) [12:40] <coalado> svvitch: -show_format [12:41] <coalado> but this fails for your stream.. [12:42] <svvitch> Mavrik: hmm you are right [12:42] <Mavrik> also it seems you don't get enough data for video bitrate to be probed [12:42] <svvitch> but this is stream, that's why I'm looking for stream [12:44] <svvitch> Mavrik: coalado, thanks [12:46] <Diogo> hi anyone ubitux..do you know where i can find more information about this article https://tech.dropbox.com/2014/02/video-processing-at-dropbox/? [12:46] <coalado> svvitch: this does not help. it returns the audio bitrate only. [12:46] <coalado> try -probesize [12:46] <ubitux> Diogo: i'm not working at dropbox [12:47] <svvitch> coalado: hm yes, it's equal to audio :( [12:48] <Diogo> ok thanks for your answer, but can you give me some advise to generate the m3u8 from avi file very quick? [12:48] <Diogo> only the structure? [12:48] <Diogo> this is possible or to generate the mpegts file in parallel? [12:50] <drakeguan> Diogo: check this, http://www.bogotobogo.com/VideoStreaming/ffmpeg_http_live_streaming_hls.php [12:50] <drakeguan> https://www.irccloud.com/pastebin/LjOP6QC0 [12:52] <Diogo> yes thanks for your help and advice... [12:52] <Diogo> i already did that procedure...but my question is to generate the out%03d.ts...in paralel [12:52] <Diogo> i need to generate the mpegts very quick [12:54] <Diogo> imagine that you have a avi file with 2hours...and i need to generate the first chunks of ts file during the user upload and after that i generate the mpegts files on the fly....when user is seeing the video... [12:55] <Diogo> i don't know if -ss option and -t option works for that solution.. [13:11] <ubitux> Diogo: see http://ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_002c-… or http://ffmpeg.org/ffmpeg-formats.html#hls-1 [13:14] <Diogo> what is a nut file? [13:15] <ubitux> a ffmpeg format, it's an example [13:27] <Nopik> hi, can ffserver read feed directly from http? or I absolutely need to have extra ffmpeg reading from http and pushing to ffserver? [14:08] <baidoc2> Does anyone have any ideea why after 8 minutes: ffmpeg -analyzeduration 0 -threads 1 -i "rtmp://RTMP/cam1 live=1" -r 10 -sws_flags lanczos -f image2pipe -q 3 - [14:08] <baidoc2> stops sending data into pipe? [14:08] <baidoc2> it has nothing to do with the stream, the stream still works [14:29] <rudi_s> mencoder supported -vobsoubout to dump the subtiles as .idx and .sub files. Is this still possible with ffmpeg? [14:29] <rudi_s> I tried to convert the .vob to .mkv, but it seems the idx-"part" is not correctly transferred, as mkvextract doesn't let me extract the .idx/.sub from the resulting mkv file. [14:29] <rudi_s> (codecprivate seems to be missing.) [14:43] <Harzilein> oh, regarding "used to be possible"... [14:45] <Harzilein> i recently was given an "s1 mp3" device and want to use amv containers now. the amv demuxer apparently got rolled into the regular avi demuxer, but there's no muxer. if someone were to adapt the muxer from the s1mp3 project, would it be awkward to have only muxing support? (i.e. it would look asymmetric, demuxing would use -f avi and muxing would use -f amv) [14:51] <sacarasc> Harzilein: What's an AMV? [15:03] <Diogo> ubitux: -reference_stream can you explain with more detail how can i use this option? [15:05] <ubitux> i don't know [15:06] <Diogo> -reference_stream <last ts file> [15:06] <Diogo> ? [15:07] <ubitux> 15:05:33 < ubitux> i don't know [15:07] <ubitux> i don't use that, last time i created an hls stream was 2 years ago [15:07] <Diogo> :) ok thanks [15:49] <dietlev> hey all. For a small app, I would need to extract the maximum Decibel out of a video. Not really an audio expert, so could someone point me in the right direction or an example for this? [15:50] <c_14> the volumedetect filter should do just that (among other things) [15:55] <dietlev> @c_14 so the max_volume ( -4db in the example ) is the highest peak? [15:57] <c_14> I think so. [15:57] <dietlev> cool. thx [16:57] <sine0> serious question. in windows I used aae and mbl and various other plugins to get effects on my videos. now im using linux gentoo and i really like gimp image manipulation. would it be feasable to batch edit the frames if i were to extract them, and do some ffmpeg and gimp cl magic? [16:58] <ubitux> you can extract all the frames but you're going to loose the timing [16:58] <sine0> timing ? [16:58] <ubitux> what automatical filter in gimp do you miss in ffmpeg btw? [16:59] <ubitux> sine0: yes, for video with non constant framerate, you'll get surprise [16:59] <ubitux> anyway, your question is vague [16:59] <sine0> ubitux: i havent delved into what ffmpeg can do in that area, im going to do color correction and video overlay [16:59] <ubitux> we really have everything you need in that area in ffmpeg [16:59] <sine0> oh goodie [16:59] <ubitux> curves, colorbalance and whatever filters [17:00] <ubitux> you also have 2D and 3D LUT for advanced color management [17:00] <sine0> wow [17:00] <ubitux> and we have an overlay filter as well [17:00] <sine0> i used that in aae with technicolor picture styles [17:00] <sine0> got some real nice effects [17:01] <ubitux> http://ffmpeg.org/ffmpeg-filters.html#overlay-1 [17:01] <ubitux> http://ffmpeg.org/ffmpeg-filters.html#lut_002c-lutrgb_002c-lutyuv [17:01] <ubitux> http://ffmpeg.org/ffmpeg-filters.html#lut3d-1 [17:01] <sine0> im curious about the timing though, im using one camera only and i shoot in a constant fps [17:01] <ubitux> http://ffmpeg.org/ffmpeg-filters.html#colorchannelmixer [17:01] <ubitux> http://ffmpeg.org/ffmpeg-filters.html#colorbalance [17:01] <ubitux> http://ffmpeg.org/ffmpeg-filters.html#curves-1 [17:01] <ubitux> anyway... [17:01] <ubitux> :) [17:02] <sine0> did you catch what i wrote [17:02] <ubitux> sine0: ffmpeg -i ... -f image2pipe ... or simple out%03d.png as output if you want [17:02] <ubitux> you'll re-encode the png at constant rate [17:03] <sine0> I dont understand you, are you saying that i will do that and it will be a bad thing or its wrong, OR are you saying thats what i should do [17:03] <ubitux> it will be fine [17:03] <ubitux> assuming you have a constant frame rate as source [17:04] <ubitux> even with variable fps actually, ffmpeg should dup the frames when necessary [17:13] <Technicus> Hi, I am recording screen casts in a Linux environment with Simple Screen Recorder: < http://www.maartenbaert.be/simplescreenrecorder/ >. My coworker then needs to be able to open the files in Adobe Premier. How can I convert them to a format Adobe will play nice with, via FFMPEG? [17:13] <c_14> What format is SSR creating? [17:14] <c_14> format + codecs [17:14] <c_14> But pretty much anything these days will eat H.264 in an mp4 container. [17:18] <Harzilein> sacarasc: riff-compatible "obfuscated" avi, basically [17:18] <Harzilein> sacarasc: ffmpeg already supports it through case statements in the avi demuxer [17:19] <Harzilein> sacarasc: but it did not mainline the muxer, now its awkward for people to get it into ffmpeg because you can't select an avi-variant that way [17:22] <sacarasc> Hmm, okay. [17:23] <jkli> hi guys [17:23] <jkli> is there any command to batch merge a batch of video files ? [17:24] <c_14> merge as in concat? [17:25] <jkli> yeah [17:25] <c_14> https://trac.ffmpeg.org/wiki/How%20to%20concatenate%20(join,%20merge)%20med… [17:25] <jkli> got 30 vids all 1-2 min [17:25] <c_14> look at the "with a bash for loop" section. [17:25] <c_14> also the process substitution section [17:26] <jkli> already there [17:27] <jkli> for f in ./*.wav this thing finds all wav files in CURRENT dir? [17:27] <c_14> yep [17:27] <jkli> or do i have to use absolute folder path [17:27] <c_14> both work [17:33] <jkli> works [17:38] <jkli> but i dont really understand the bash loop [17:38] <jkli> so does it echo "file filename.mp4" everytime? [17:38] <c_14> pmuch [17:38] <jkli> i mean, why is the "file" even needed in the echo loop [17:39] <c_14> that has to do with the concat demuxer [17:39] <jkli> so it is required [17:39] <c_14> yes [17:39] <jkli> i see [17:39] <jkli> kk then makes sense [17:39] <jkli> just downloading the newly muxed video file [17:39] <jkli> thank god, i dont have to watch 30 seperate videos [17:59] <sine0> ubitux: how can i work out the settings to use on a particular scene and apply it, seeing as there is no gui, is it a matter of try it on a frame and see and then repeat, or can i extract the information from gimp and then apply as a command line [18:00] <ubitux> you can use the timeline option [18:00] <ubitux> like, -vf "curves=xxxx:enable='between(t,10,25)'" [18:01] <ubitux> you can test with ffplay first, and frame step with 's' [18:02] <ubitux> sine0: try ffplay -f lavfi -i testsrc -vf "curves=vintage:enable='between(t,2,5)'" [18:02] <ubitux> for example [18:02] <ubitux> note that not all filters support timeline [18:02] <ubitux> if you see a filter that don't but think it should, feel free to name it i'll have a look [18:07] <ubitux> sine0: see http://ffmpeg.org/ffmpeg-filters.html#Timeline-editing for more info [18:08] <sine0> is that cl correct or does -i need to be before -f [18:08] <sine0> as you posted [18:08] <sine0> [lavfi @ 0x7f0f440008f0] No such filter: 'MVI_3799.MOV' 0B f=0/0 [18:08] <sine0> MVI_3799.MOV: Invalid argument [18:08] <sine0> i replaced testsrc with my movie filename [18:09] <sine0> but i will read the page [18:10] <ubitux> sine0: -f lavfi is to say that the next specified input (-i testsrc) is of type "lavfi" [18:10] <ubitux> sine0: replace "-f lavfi -i testsrc" with "-i MVI_3799.MOV" [18:10] <ubitux> (you can drop the -i with ffplay btw, but not ffmpeg) [18:11] <ubitux> gtg, bbl [18:12] <sine0> tybb [18:15] <tlhiv_work> i have a AVI file that has a single audio channel (on the LEFT side) and I would like to make the video have a MONO audio channel with this one channel duplicated into both LEFT and RIGHT channels [18:19] <c_14> https://trac.ffmpeg.org/wiki/AudioChannelManipulation#stereo2monofiles [18:19] <c_14> just leave out the part for the right channel [18:20] <c_14> If I'm understanding your question correctly and you want mono output. [18:20] <Harzilein> tlhiv_work: i think you mean "stream" on two occasions where you write channel. mono streams only have one channel, it's customary for players/operating systems/soundcards to play that on both sides of their analog stereo outputs [18:24] <tlhiv_work> Harzilein: probably ... i have a video that i just recorded that is only playing out of the left speaker ... i would like to it to play (duplicate) out of both speakers [18:28] <tlhiv_work> nevermind ... -ac 1 does it [21:10] <A__> I was just going to join here and ask why .mp4 H.264 videos exported from Premiere Pro (CC 2014) are so god damn big because ffmpeg can convert them without any loss of quality to a fraction of their size. [21:10] <A__> But then ffmpeg produced a bigger file than the source. [21:10] <A__> So it's not always the case. [21:10] <A__> But one has to wonder how bad the Adobe encoder is. [21:10] <A__> Because it's usually grossly oversized. [21:14] <JEEB> it's not like the encoder knows what size your source is, and it /shouldn't/ know [21:14] <JEEB> set CRF to the highest value that still looks good, and encode with the slowest preset that is still fast enough for you, and you should get as much compression as you can handle :P [21:27] <llogan> A__: might be useful to you https://trac.ffmpeg.org/wiki/Encode/PremierePro [21:28] <llogan> haven't tried it with CC7+ though [21:29] <A__> JEEB: CRF = ? [21:29] <A__> Whenever I set the "target bitrate" to maximum, etc., the video output is completely broken. [21:30] <A__> Hehe. Their lossless output is so big that my hard drives just look at me with sad eyes and go: "Why, Master? Why?" [21:31] <A__> Hmm. Both of those solutions, llogan, are quite annoying. [21:31] <llogan> so is AME [21:32] <A__> Never used that crap. [21:32] <A__> I just wanna export in a sane way. [21:33] <A__> I always use H.264. But I tend to have to run ffmpeg on that output file each time too. [21:33] <A__> Or else it takes a million megabytes. [21:33] <llogan> how can you use Premiere but not Adobe Media Encoder? [21:42] <A__> llogan: I'm not sure I understand the question. [21:43] <A__> Maybe you are going to say that it's built in or something. [21:43] <A__> But AFAIK, it's a separate application. [21:43] <A__> And one that sucks, at that. [22:01] <A__> "Install Ut Video. It is a fast, lossless video encoder (and decoder), and is natively supported by ffmpeg. " [22:01] <A__> What? [22:01] <A__> This also makes no sense. [22:12] <line0> how does it not make sense? [22:14] <line0> utvideo is a vfw-based encoder, which is why you can use it in AME [00:00] --- Wed Aug 20 2014

1 0

ffmpeg-devel.log.20140817
by burek 18 Aug '14

18 Aug '14

[00:10] <Compn> hooo boy [00:10] Action: Compn approves a flame from debian devel [00:11] <kierank> I don't even understand that email [00:11] <Compn> kierank : its classic debian double-speak [00:12] <Compn> the same reason why xine (with libavcodec) was in debian for years but mplayer (with libavcodec) was rejected [00:12] <Compn> very very old "mplayer rejection" [00:12] <J_D> Everything in debian is old [00:12] <J_D> I don't know why people care about it [00:13] <Daemon404> some of us run servers [00:13] <Compn> yeah, and you want 10 year old openssl bugs :) [00:13] <Compn> ehe [00:13] <Daemon404> you dont need 10 year old bugs [00:13] <Daemon404> there are penty of new ones too [00:13] <kierank> Daemon404: in b4 use gentoo [00:13] <J_D> I'm sure a lovely old server is good [00:13] <J_D> but I hate it as a user [00:14] <Daemon404> so dont use it [00:14] <J_D> I try not to [00:14] <kierank> Compn: actually yes Debian did that to x264 [00:14] <kierank> They picked some ancient version because it was more stable [00:15] <Daemon404> x264 is not suitable to be packaged [00:15] <kierank> Not understanding one point of a new version is to fix bugs [00:15] <Daemon404> full stop [00:15] <J_D> Instead of ranting further I will just be quiet. [00:15] <wm4> that mail by Mr. Allbery is rude [00:15] <wm4> does he even have a fucking clue [00:15] <kierank> Daemon404: why [00:16] <Daemon404> kierank, it (used to) break api and abi constantly, no releases, etc [00:16] <Daemon404> unless you like rebuilding stuff constantly [00:16] <wm4> I don't understand why something as simple as x264 needs to break abi all the time [00:17] <Daemon404> it doesnt anymore, obv [00:17] <Daemon404> since dev is more or less "done" [00:19] <Daemon404> ok i just read that debian guy's email [00:19] <Daemon404> ... rofl [00:19] <Daemon404> what sort of drugs do these people do [00:20] <Daemon404> " I'm glad that FFmpeg takes security [00:20] <Daemon404> seriously, but what FFmpeg needs is to *have fewer security bugs*." [00:20] <Daemon404> yes, just code less bugs [00:21] <Daemon404> such an easy solution! [00:23] <kierank> wm4: it's because of obscure features [00:23] <kierank> Unless you want the api to be x264_set_opt [00:24] <wm4> would probably be better... I only loathe such APIs for core things [00:26] <J_D> I wonder, would you have to pass quantiser offsets as a string? [00:51] <wm4> "It would be nice, if everyone, including you, would refrain from posting such flamebaits on debian-devel." [00:52] <wm4> he's posting that only now... [00:52] <wm4> "Indeed it's getting late, because the FFmpeg package has been waiting in the NEW queue for more than 3 months." [00:52] <wm4> debian... [01:25] <BBB> the whole thread is kinda funny [01:26] <BBB> let me tell you guys, if you all used gerrit, you wouldnt fight so much anymore" [01:26] <J_D> ubitux: are you still around? [01:26] <BBB> if libav just stops reviewing and ffmpeg makes less experimental stuff, youll all get along again" [01:26] <Daemon404> BBB, my favourite is still "just write less bugs" [01:26] <BBB> true [01:26] <BBB> theyre all quite monumental [01:31] <kierank> Daemon404 and wm4: you have made my day [01:33] <Daemon404> kierank, i dont really know how to react to his reply [01:33] <Daemon404> it's surreal. [01:34] <kierank> ask him to translate what he said to english [01:34] <kierank> "and putting systems in place that let the computer do [01:34] <kierank> lots more security sanity checking for you" [01:36] <j-b> Statistically, more features means more bugs and more security issues [01:37] <wm4> > * Don't write bugs. [01:37] <wm4> That's a really bad way of avoiding security bugs. [01:38] <wm4> ^ ok that really is a strange mail [01:38] <Daemon404> i wondered what drugs he was on [01:38] <Daemon404> then i noticed he wrote a lot of kerberos stuff [01:38] <Daemon404> krb5 etc [01:38] <Daemon404> ALL the drugs [01:39] <Daemon404> in any case [01:39] <Daemon404> i am simply not going to reply [01:39] <Daemon404> i dont feel like arguing on the internet right now [01:39] <Daemon404> not for something liek this. [01:40] <wm4> one should troll them with the debian valgrind disaster [01:40] <wm4> (although openssl or what it was could be blamed for that equally) [01:41] <BBB> oh kerberos [01:41] <BBB> kerberos is wonderful [01:42] <BBB> & if youre on drugs [01:42] <BBB> anyway, Im gonna say that bugs dont happen in our relevant decoders (h264, vp8), these are well-tested, -maintained, safe etc. [01:42] <BBB> our RE code isnt always so good& especially stuff that was REed early on and basically just dumped x86 assembly back into C [01:43] <BBB> nowadays we tend to do better [01:43] <Daemon404> enjoy your internet arguments [01:43] <Daemon404> it's likely not worth anyone's time IMO [01:43] <BBB> Im not getting into any [01:43] <J_D> ubitux: let me know, somehow, if you object to me putting 680 MiB of test files on that laptop and if you have a preferred time for when I can do this. [01:43] <BBB> I wasnt gonna post it [01:43] <BBB> just saying it here [01:43] <Daemon404> o ok [01:52] <jamrial> J_D: If you mean the fate test suit, it's already there [01:52] <jamrial> ah, missed him [01:56] <kierank> 12:40 AM <"wm4> one should troll them with the debian valgrind disaster --> haha [01:57] <Daemon404> i would point out all the *grind and *san instances we run [01:57] <Daemon404> or well, all of FATE [01:57] <Daemon404> but i cant be arsed [02:00] <BBB> I also see theres this whole libav subtrhead that is not cced to ff-devel? [02:00] <BBB> better would be an auto-fuzzed based on fate to test for crashes [02:00] <Daemon404> the amount i care about it is so little that i have not bothered to even look. [02:00] <BBB> lol [02:00] <BBB> anyway [02:00] <BBB> yeah [02:00] <BBB> who cares [02:01] <Daemon404> i used to run an instance that would randomly fail allocs [02:01] <Daemon404> but there were so many unchecked allocs, it got boring [02:10] <BBB> yeah its mostly a theoetical thing here [02:10] <BBB> we do something on 80% of allocs if they fail [02:10] <BBB> but the something is rarely actually tested [02:11] <wm4> from a security perspective it might be better to abort() in av_malloc if allocation fails [02:13] <Compn> wow that raa guy email is hard to read [02:13] <Compn> :D [03:11] <iive> to be honest, I'm starting to think that debian wants some cold hard cash in order to let ffmpeg in [07:09] <msca> are there any lossless hardware encoders for audio streams? [07:09] <msca> and any hardware for high density parallel stream decode? [09:52] <Case> I have been testing WMA Lossless recently and it seems to me that ffmpeg's decoder fails to decode every single WMAL file incorrectly. Tens of thousands of samples are missing from the end of the file [11:29] <cone-824> ffmpeg.git 03Timothy Gu 07master:32c712f1437b: vidstabutils: fix indentation [11:49] <cone-824> ffmpeg.git 03Nicolas George 07master:4f3e2f107b63: ffprobe: add -show_data_hash option. [12:52] <cbsrobot> kurosu_: ping [13:21] <nevcairiel> someone should port the intrinsic hevc idct's from openhevc to yasm, i applied them as-is and it improved speed by over 50%, i was like, wow :d [13:22] <nevcairiel> (but i suck too much at yasm to do it myself) [13:23] <wm4> compile, disassemble? :D [13:23] <JEEB> lol [13:24] <beastd> intrinsics re ;D [13:25] <nevcairiel> wm4: can just get the compiler to give me a assembly output, but yeah, thats ugly :D [13:28] <nevcairiel> i should run fate on the intrinsics and just keep em in my fork [13:48] <ubitux> michaelni: no need to review the usage of bdiff thing, i'll probably drop that, sorry (i think i said it in one of the reply) [13:49] <ubitux> michaelni: i'm interested in the asm review though [13:52] <ubitux> thx :) [14:33] <J_Darnley> ubitux: did you see my question from severa hours ago? [14:33] <J_Darnley> *several [14:33] <ubitux> yes, feel free to sync the fate samples [14:34] <J_Darnley> They're not the fate samples but files I was using to test here. [14:34] <ubitux> yeah sure go ahead [14:35] <J_Darnley> will do [14:43] <cone-824> ffmpeg.git 03Michael Niedermayer 07master:cabcd8ff66ef: avformat/movenchint: use av_freep() for safety [14:43] <cone-824> ffmpeg.git 03Michael Niedermayer 07master:afe23e430e2d: vcodec/rpza: print mismatching size in case of error [14:43] <cone-824> ffmpeg.git 03Michael Niedermayer 07master:b6c9266722d7: avcodec/rpza: fix +- error [14:47] <kurosu_> nevcairiel, yeah, I also have the sao applied too [14:48] <kurosu_> I'm most often basing my benchmark on those because current status is not representative of a future good reference [14:48] <nevcairiel> how much does the sao do? [14:48] <kurosu_> I don't remember, probably 5-10% [14:48] <nevcairiel> hm might just try it [14:50] <kurosu_> going to rebase before pushing to github [14:51] <kurosu_> cbsrobot, pong ? [14:52] <kurosu_> the openhevc guys were contracted for maybe 2 years, an plepere should quit around october iirc [14:52] <nevcairiel> more time to work on yasm then! [14:54] <kurosu_> I'm not sure plepere is that found of it - most asm in openhevc is first intrinsics (then get ported to yasm if they can spare the effort) [14:55] <kurosu_> https://github.com/kurosu/ffmpeg/commits/hevc_mt <- with some working yet useless patches too [14:55] <kurosu_> iirc, ~110fps with 6 cores on 1080p [14:56] <nevcairiel> that seems slow [14:56] <kurosu_> yeah :( [14:56] <kurosu_> most time is spent on cabac though [14:56] <kurosu_> but that's a 4yo 6 core too [14:56] <kurosu_> per core, my laptop is like 40% faster [14:57] <kurosu_> HEAD is probaly around 60 [14:57] <kurosu_> on the 6 cores [14:58] <kurosu_> note: manual commits, run configure with --extra-cflags="-msse4.2" [15:01] <nevcairiel> yeah, that part is annoying, in my idct change i added a bunch of gcc pragmas to enable it only for that particular file [15:01] <nevcairiel> i think its stupid, msvc manages to build intrinsics without optimizing the whole code base [15:04] <kurosu_> it's possible with ffmpeg, but the build system needs to be modified, and that's a fruitless effort, given asm maintainers don't want to have intrinsics [15:04] Action: Daemon404 is reminded to update yasm to 1.3 [15:04] <kurosu_> last time I tried, intrinsics were giving me some unneeded moves [15:04] <Daemon404> kurosu_, wouldnt that depend on teh compiler / version used too [15:05] <kurosu_> yes, but that was at least 4.6 [15:05] <kurosu_> if not 4.8 [15:05] <kurosu_> might also have been PEBKAC [15:05] <nevcairiel> i didnt want to mess with the build system, so I just went with pragmas [15:05] <kurosu_> I'm thinking in x264asm then I have to translated in intrinsics [15:06] <nevcairiel> they require 4.8 i think, but what do i care [15:06] <kurosu_> nevcairiel, indeed, like my extra cflags hack [15:07] <Daemon404> kurosu_, the few times ive done asm, x264asm seemed less annoying than intrinsics [15:07] <Daemon404> but i was also only targeting one OS on oen arch. [15:08] <kurosu_> x264 alleviates a lot of work, but you still have to bother with a bit of abi [15:08] <kurosu_> in particular if you optimize reg usage [15:08] <Daemon404> kurosu_, i was only targeting x86_64 linux [15:08] <Daemon404> that eased most of that pain [15:09] <cone-824> ffmpeg.git 03Michael Niedermayer 07master:94f60b65446b: avcodec/h264_mb: fix grayscale only decoding with weighted prediction [15:09] <kurosu_> well, the optimizaton isn't possible with intrinsics most of the time anyway so that's self-inflicted pain [15:09] <nevcairiel> intrinsics are just easy, especially if you have a lot of variables to work with, and try targeting 32-bit as well [15:09] <kurosu_> on the other hand, hevc instrinsic code on 32bits yield little to no improvement iirc [15:10] <nevcairiel> the idct seemed to help on 4k content [15:10] <kurosu_> but it was some time ago when there wasn't asm for even mc [15:10] <kurosu_> I bet it does seeing how the 32x32 transform must be prevalant [15:11] <nevcairiel> i didnt benchmark 32-bit th o [15:12] <kurosu_> I haven't either, but you can imagine there's a whole lot of nothing to code for 4K [15:13] <kurosu_> btw, my comment about intrinsics 32bits was on the mc only [15:22] <J_D> (wtf was that?) [15:22] <J_D> I'll ask again incase my message didn't go through... [15:22] <J_D> Where's the "master" source for the open hevc code? [15:23] <Daemon404> https://github.com/OpenHEVC/openHEVC [15:27] <J_Darnley> Bloody github! What's wrong with black text? [15:29] <kurosu_> https://github.com/OpenHEVC/openHEVC/tree/hevc_rext even [15:30] <cdecl_xyz> hello, i have questions regarding libswscale and how to do proper colorspace conversion (full range -> smpte range). is this the right place? [15:30] <cdecl_xyz> i see, it must be #ffmpeg i guess. nevermind [15:31] <cone-824> ffmpeg.git 03Christophe Gisquet 07release/2.3:9794727ccd24: proresenc_kostya: remove unneeded parameters [15:31] <cone-824> ffmpeg.git 03Christophe Gisquet 07release/2.3:60bfa9154d00: proresenc_kostya: report buffer overflow [15:31] <cone-824> ffmpeg.git 03Justin Jacobs 07release/2.3:59d98fc05078: avformat/matroskadec: Check avpriv_new_chapter() for failure [15:31] <cone-824> ffmpeg.git 03Christophe Gisquet 07release/2.3:35738e589847: proresenc_kostya: properly account for alpha [15:31] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/2.3:10c2d22ba195: avcodec/mjpegdec: Support AV_PIX_FMT_YUV420P16 with upscale_h [15:32] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/2.3:4f187f0af13b: avformat/mpegts: Use differential score for analyze() [15:32] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/2.3:3b6bde3b3de4: avcodec/h264_mb: fix grayscale only decoding with weighted prediction [15:32] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/2.3:bc259185cb69: Update for FFmpeg 2.3.3 [15:32] <J_Darnley> kurosu_: it looks like github points you to the branch anyway [15:33] <kurosu_> J_Darnley, ok [15:47] <J_Darnley> blimey! only 196 MiB! [15:49] <cone-824> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.3.3': unknown revision or path not in the working tree. [15:49] <cone-824> Use '--' to separate paths from revisions [15:49] <cone-824> refs/tags/n2.3.3:HEAD: avcodec/h264_mb: fix grayscale only decoding with weighted prediction [17:30] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/1.2:c285db74f647: avformat/utils: do not wait for packets from discarded streams for genpts [17:31] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/1.2:f70ee7d14fcf: avcodec/dvdsub_parser: never return 0 when the input isnt 0 [17:31] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/1.2:454f6c622c45: avcodec/dvdsub_parser: Check buf_size before reading 32bit packet size [17:31] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/1.2:b4632cec7401: avcodec/dvdsub_parser: print message if packet is smaller than the packet size field [17:31] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/1.2:ca232ff9b0af: avformat/tee: flip assigment direction [17:31] <cone-824> ffmpeg.git 03Anton Khirnov 07release/1.2:f712d3669e2e: cdgraphics: do not return 0 from the decode function [17:31] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/1.2:abc1fa7c5a1d: avcodec/iff: check pixfmt for rgb8 / rgbn [17:31] <cone-824> ffmpeg.git 03Luca Barbato 07release/1.2:61a51598e343: lavc: move put_bits_left in put_bits.h (cherry picked from commit afe03092dd693d025d43e1620283d8d285c92772) [17:31] <cone-824> ffmpeg.git 03Christophe Gisquet 07release/1.2:18342848f7fa: proresenc_kostya: report buffer overflow [17:32] <cone-824> ffmpeg.git 03Michael Niedermayer 07release/1.2:ab4e54f6f6b3: update for 1.2.8 [17:33] <michaelni> anyone wants to update th changelog for 1.2.8 ? if not ill do it later today [18:23] <michaelni> BBB, you are listed as http maintainer in MAINTAINERS, do you still maintain it ? iam asking as there are 2 patches from nicolas on the ML [18:48] <p0nce> hi [18:48] <p0nce> is endianness defined for y4m high bitdepth? [18:49] <p0nce> currently I read/write y4m frames as is, I wonder if the format mandates one form [18:51] <wm4> good question... libavformat's demuxer seems to always use native endian (?) [18:52] <wm4> that doesn't sound right [18:53] <wm4> same for encoding [18:53] <p0nce> I have the same question about shifting bits to the right or the left of the 16 available bits in a sample [18:54] <wm4> AFAIK formats like AV_PIX_FMT_YUV420P10 require you shift bits to get to 16 bit [18:55] <wm4> +to [18:59] <p0nce> ok, thanks [19:00] <p0nce> it would help if C420p10 would become C420p10LE or C420p10BE [19:39] <Compn> p0nce : reading yuv4mpegdec.c , it doesnt look like high bit 10/12/16 are defined one way or the other [19:39] <Compn> which makes sense, as you can use LE or BE if you want [19:40] <Compn> some formats require LE or BE , i know mov does it sometimes [19:41] <Compn> libavformat/yuv4mpegenc.c also doesnt require LE or BE [19:42] <Compn> wm4 : its because the decoder handles both, so theres no reason to use LE or BE formats in the (de)muxer [19:42] <Compn> would just needlessly complicate things [19:42] <Compn> and if you arent using lavc .... too bad. [19:42] <Compn> :) [19:50] <kurosu_> see libavutil/pixfmt.h [19:52] <Compn> kurosu_ : what file explains the direction (left or right) of the shifting ? [19:59] <BBB> michaelni: oh, rly? well I know the code.. [19:59] <BBB> michaelni: I can look, weblink to patches? [20:00] <BBB> michaelni: oh, those, both ok [20:06] <michaelni> BBB, thx, forwarded your approval to the ML [20:06] <michaelni> i guess i could have just applied them instead, well doesnt matter much i guess [20:06] <Compn> BBB : you want to be listed as maintainer of http ? [20:07] <Compn> continued to be listed* [20:07] <BBB> sure [20:07] <BBB> I know the code [20:07] <Compn> k :) [20:07] <Compn> just making sure you werent listed erroneously [20:07] <BBB> nah [20:07] <BBB> I just didnt remember [20:13] <p0nce> Compn: ok so let's suppose I write a y4m decoder, I would have to detect endianness? [20:13] <BBB> is the idct order v/h) in hevc wrong"? [20:16] <Compn> p0nce : um. [20:18] <BBB> fionag: do you know anything about this? [20:18] <Compn> p0nce : possibly yes. i think the only difference you'd get is swapped uv though (red / blue colors switched) [20:20] <p0nce> Compn: do you mean UV order also isn't defined in y4m? [20:20] <p0nce> I would assume Y then U then V [20:22] <Compn> no i mean if you decode LE or BE incorrectly, its usually the u and v gets swapped... [20:22] <p0nce> ok [20:22] <Compn> the uv order is defined by the colorspace used, which can be those formats listed in the dec/enc files [20:23] <kurosu_> Compn, no idea, but pixdesc.[ch] contains the data on how to manipulate the data [20:23] <Compn> i think you maybe confused on codecs, colorspaces and endianness [20:23] <kurosu_> I was only looking at it yesterday when trying to add some RGB3N format with N=10/12 [20:23] <Compn> yuv4mpeg only uses one codec iirc. which is raw yuv [20:24] <Compn> then it can use any colorspace of raw yuv , which defines the amounts per bit of Y U and V planes (8bit 10/12 bit) and the endianness (byte structure, LE/BE) [20:25] <Compn> i'm not really the one to be asking about codecs and colorspaces, but i think the above is correct. [20:25] <p0nce> ok, was just confused that endianness is to be guessed [20:27] <BBB> kurosu_: you may know [20:27] <Compn> i think the endianness check is only 10 or 20 lines of code. i could be wrong [20:27] <BBB> kurosu_: http://x264dev.multimedia.cx/archives/486 point 5, idct ordering; is hevcs wrong? [20:44] <ubitux> i missed some stuff in the comments of that post [20:44] <ubitux> > Interlacing is a pretty clever compression method [20:46] <JEEB> whom shall I cut? [20:47] <BBB> interlacing is pure crap [20:47] <BBB> its just a blast from 50 years ago and somehow we forgot to erase it [20:48] <ubitux> hevc has no interlacing? [20:48] <JEEB> yeah, you can just encode the fields separately [20:48] <JEEB> and note that you're coding fields [20:50] <cone-824> ffmpeg.git 03Piotr Bandurski 07master:a3329a09f934: avcodec/lcldec: fix decoding of YUV444 sample [20:50] <cone-824> ffmpeg.git 03Nicolas George 07master:481cbc5ad578: lavf/http: fix cookie parsing. [20:50] <cone-824> ffmpeg.git 03Nicolas George 07master:4bebce06175a: lavf/http: remove special case for cookies attributes. [20:50] <cone-824> ffmpeg.git 03Michael Niedermayer 07master:3d40ba3d8127: Merge remote-tracking branch 'cigaes/master' [21:13] <fionag> BBB: what do you mean by wrong? [21:13] <BBB> fionag: http://x264dev.multimedia.cx/archives/486 point 5 [21:14] <BBB> not wrong, just wrong [21:14] <fionag> ohhhh. I don'tknow what order they did it in [21:14] <BBB> the wrong one :( [21:15] <fionag> aw :< that does slightly surprise me since H.264 had it "right" [21:15] <BBB> indeed [21:15] <fionag> but not *too* surprising since they don't seem to think very hard about software implementations [21:42] <iive> BBB: actually interlace is worse than that. e.g. mpeg4 asp had it almost removed, there was only MB interlace support. [21:43] <cone-824> ffmpeg.git 03Luca Barbato 07master:96ce6d6f119a: doc: Add more information in the README [21:43] <cone-824> ffmpeg.git 03Michael Niedermayer 07master:eb706575baa6: Merge commit '96ce6d6f119a16e489941c629a2805204322b717' [21:44] <iive> the problem is that it popped up back, when they needed a trade back, that would cut bandwidth/decoding in half, by sending only half the data. [21:44] <iive> tradeoff [00:00] --- Mon Aug 18 2014

1 0

ffmpeg.log.20140817
by burek 18 Aug '14

18 Aug '14

[01:08] <FirstContact> hi all this is a question about the MOOV atom, and its relation to the MDAT atom in mp4 files. My question is: does anyone here know where the actual data is stored that contains the location of the MDAT atom? or how it's stored or any info at all about it? [01:09] <FirstContact> I have a bad mp4 file and I think I see the location of the MDAT atom but don't know how to tell the file that it is located there [01:10] <FirstContact> Ive been looking at the specifications but not seeing where the offsets are actually stored [03:41] <jrgill> Scaling from 1280 x 720 to 854 x 480, would you setsar 1:1 or setdar 16:9? [03:42] <jrgill> (originally 1:1 and 16:9 respectively) [04:01] <c_14> Nah, why? [06:32] <mgalgs> is there a way to specify a default transition between all input sources? I want to create a video from a sequence of images and cross fade between *every* image... [07:02] <Technicus> Hello, does anyone here have experience setting up a video streaming service? [07:02] <Technicus> I'm looking for suggestions to for setting up a service that recieves RTMP and broadcasts video. [08:22] <t4nk376> I am trying to take videos uploaded to my server and encode the Video as MP4 and the Audio as MP3. But im having trouble figuring out how to do it with ffmpeg [09:45] <camper> greetings, I'm using stopmotion, a software that depends on ffmpeg to create video from a sequence of stills, and the software uses a command line relaying on Image file demuxer (avconv -r 12 -b 1800 -i "$IMAGEPATH/%06d.jpg" "$VIDEOFILE" ; i want an expression that captures more file, at least jpg files with capital letters in the extension [10:05] <camper> sorry, lost power [10:09] <ochorocho> hey ... i want to stream videos using ffmpeg. i want the videos to be converted to mp4 or webm on the fly. Is there a way to do this using ffmpeg and php? [10:47] <Mavrik> ochorocho, you'll need a proper streaming server for what you want [10:47] <Mavrik> like Wowza [10:51] <ochorocho> Mavrik: ok ... hm. so id better go with mplayer or vlc? [10:57] <Mavrik> no. [10:57] <Mavrik> because none of those do what you want. [10:57] <Mavrik> (If I understood correctly.) [10:57] <Mavrik> Preencode videos to mp4 and webm and then serve them later. [11:00] <ochorocho> Mavrik: basically i dont want to cache the videos, i want them served in the right format for html5. [11:01] <Mavrik> And Im telling you you cant encode MP4 while serving it without a proper streaming server. [11:02] <Mavrik> Wowza licenses are relatively cheap and it has a live transcoder by default [11:02] <ochorocho> ok ... [11:02] <ochorocho> Mavrik: thank you. [11:14] <DopeLabs> you need a segmenter [11:16] <ochorocho> DopeLabs: talkin to me? ... can you give me a example? i read abozt segmenter but did not get it... [11:16] <DopeLabs> reading above [11:16] <DopeLabs> yea [11:17] <ochorocho> :-) [11:17] <DopeLabs> so whats stopping you from just.. converting them to mp4 [11:18] <ochorocho> i dont want to cache all the files in my library ... [11:18] <DopeLabs> what are you doing with the uploads now [11:19] <Mavrik> DopeLabs, usually the way more sensible decition for that usecase is just to stream via RTMP / HLS [11:19] <Mavrik> since those containers aren't streaming hostile and you get way lower latency [11:19] <Mavrik> segmented MP4 is kinda problematic support-wise... plus you get a full segment latency [11:20] <DopeLabs> (yes i use a streaming server for all this hooha) [11:20] <Mavrik> mhm [11:22] <ochorocho> DopeLabs: currently i do nothing with the uploads. just want to serve the vids in a convenient way without filling up my harddisk to much. [11:22] <gilbahat> Hi, I have built ffmpeg with opencl and I am trying to run accelerated decode/encode task, but GPU consumption is always on 0%. I have tried to set platform_idx and device_idx explicitly and still nothing. [11:23] <DopeLabs> so when the upload completes, have it fire off ffmpeg to convert them to mp4 and delete the original file (if your worried about space, etc) [11:24] <ochorocho> DopeLabs: the videos on the server i use are all my originals i want to keep.... its my media library [11:25] <gilbahat> for the same reason, it doesn't appear to use vdpau either. is there any way to ascertain that opencl or vdpau is being used by ffmpeg? [11:25] <DopeLabs> what format is most of it currently? [11:25] <ochorocho> DopeLabs: mov [11:25] <Mavrik> ochorocho, why don't you use a streamable container then? [11:26] <DopeLabs> mov's are always fine for me (and what he said) [11:26] <DopeLabs> (heh... upload all that shit to youtube and let them deal with it... its free!) [11:29] <ochorocho> DopeLabs: ;-) ... [11:31] <DopeLabs> i have about 4k audio recordings of dj sets.. between 1 and ~4 hours each.. i already did a mass upload to soundcloud. and now im working my way through them all again.. this time using ffmpeg and showwaves/showspectrum to create videos from the audio recordings, then upload to yt... [11:33] <DopeLabs> gonna take a little longer than soundcloud did, which i basically just fed a script the whole directory and pushed ~900GB to soundcloud lol [11:37] <Chaz6> Want [11:37] <DopeLabs> ? [11:38] <Chaz6> What's your soundcloud name? [11:38] <DopeLabs> /dubstepfm [11:38] <DopeLabs> same with youtube [11:39] <DopeLabs> now i just need to figure out a way to get ffmpeg to spit out real time volume dblevels [11:40] <DopeLabs> from a *cast audio stream [11:41] <DopeLabs> so i can then have fun with pipes and xaos and make audio reactive real time fractal generation [11:52] <gilbahat> turns out there's an undocumented parameter called x264opts [11:52] <gilbahat> GREAT [11:53] <DopeLabs> if its undocumented.. how did you find out about it [11:53] <gilbahat> random web search, some forum post - the usual way to find undocumented stuff [11:54] <DopeLabs> so its totally mentioned in the man pages [11:54] <gilbahat> which man page? just grepped ffmpeg manpage for it and found nada [11:54] <DopeLabs> man ffmpeg-all [11:55] <DopeLabs> just search for opts and its like the 2nd or 3rd hit [11:55] <gilbahat> hrm. didn't know this thing existed. tried man ffmpeg, etc [11:55] <DopeLabs> yea -all has... well.. all of it [11:57] <gilbahat> could've been worse I guess, at least it's there somewhere. now I have to guess why it's not making things any faster :P [11:57] <DopeLabs> what do you want to go faster? [11:57] <DopeLabs> and whats the command your using [11:58] <gilbahat> transcoding a file [11:58] <DopeLabs> well generally -preset ultrafast [11:58] <gilbahat> http://pastebin.com/f4KD3nTV [11:59] <gilbahat> I mean, I am trying this specific variant with x264opts opencl and without it, and noting by debug log that opencl does get used, and still not running any faster [11:59] <gilbahat> ymmv on opencl x264, true, but I was hoping it will be faster. [12:00] <DopeLabs> your trying t ouse opencl for what exactly [12:00] <JEEB> x264's opencl is more of a POC [12:00] <gilbahat> encoding [12:00] <JEEB> it runs a worse version of lookahead ME (IIRC) [12:00] <JEEB> and can be faster under certain presets [12:01] <DopeLabs> as far as i know.. the only hw x264 support ffmpeg has is for decoding [12:01] <JEEB> x264 has opencl-based stuff in there [12:01] <JEEB> not something most people would want to use, of course [12:01] <JEEB> but to use lookahead ME you b [12:02] <JEEB> basically need slower presets to begin with [12:02] <DopeLabs> ^ [12:02] <JEEB> :V [12:02] <JEEB> so yes, if you have quick enough GPU and fast enough memory lanes between RAM and VRAM it can be quicker [12:03] <JEEB> but you're already able to make stuff faster without it, not to mention that the algorithm running on the GPU is worse off :P [12:05] <gilbahat> I see. so right now, if i'm working on an ffmpeg-based transcoding service, I'm better off running it on CPU nodes rather than GPU nodes (edge cases notwithstanding) [12:05] <JEEB> definitely [12:05] <Chaz6> One thing missing from cloud services are fpga nodes [12:05] <DopeLabs> for x264 encoding at least [12:05] <Chaz6> I see $$$ [12:05] <JEEB> you only want CPU and RAM basically [12:05] <gilbahat> Chaz6 - I fully agree [12:07] <gilbahat> JEEB: currently it doesn't look like much RAM is needed, unless you aimed to avoid reading/writing input/output files to disk [12:07] <DopeLabs> yea its basically all cpu bound [12:07] <JEEB> slower presets in x264 buffer more pictures, and if you have o9k cores at some point it becomes useful to run multiple instances [12:08] <JEEB> of course, base it all against your own usage scenario [12:09] <gilbahat> I guess it's worth tracking x264 though, this could change if their OpenCL support matures, right? [12:09] <JEEB> not much possibility for that [12:09] <JEEB> for effective encoding GPU stuff just isn't useful :P [12:10] <JEEB> it's mostly a Proof Of Concept created by MCW [12:10] <JEEB> and then after months of fixing it got merged into mainline x264 [12:10] <DopeLabs> um well [12:10] <DopeLabs> nvm.. [12:11] <gilbahat> but they are supposed to have dedicated encoder units. if that isn't useful, that's dead silicone, not something you'd expect nvidia/amd/intel to have... [12:11] <JEEB> yes, specific ASICs are more useful [12:11] <JEEB> but those are effectively black boxes :P [12:12] <JEEB> and currently the best ASICs are @ intel basically, so no dGPU needed there, either [12:12] <gilbahat> JEEB: no, I mean that modern nvidia GPUs have a dedicated encoder unit in them [12:12] <JEEB> yes, I know [12:12] <JEEB> that's ASICs [12:12] <gilbahat> ah, I thought you mean discrete/standalone ASICs [12:12] <JEEB> basically they noticed that no-one but idiots were drinking their kool-aid regarding doing encoding with GPGPU [12:12] <DopeLabs> heh.. asic.. i remember that term from btc mining lol [12:13] <JEEB> so they actually put something more useful in there [12:13] <JEEB> that said, even with the haswell intel encoders, depending on your needs they don't give you the bang for the buck you'd get from x264 [12:13] <gilbahat> but that won't be covered by OpenCL or any other 'general purpose' interface because it's properietary stuff I guess [12:14] <JEEB> you never know what interface they stick their shit into :P I mean, it was bad enough with "CUDA decoding" when nvidia put their decoding ASICs under that API [12:15] <DopeLabs> i would rather use gpu based for x264 encoding than cpu..its much faster / less expensive on the resources [12:15] <JEEB> DopeLabs, GPU hardware is good for some calculations and algorithms, efficient modern video encoding is _not_ one of those [12:15] <JEEB> which is exactly why makers switched to ASICs [12:16] <JEEB> instead of trying to do it with GPGPU [12:16] <DopeLabs> well it def better with gpu than cpu (on my machines at least) [12:16] <JEEB> you have no fucking idea what you're talking about [12:17] <DopeLabs> im pretty sure i know how to measure system resource usage between an encoder thats using cpu and one thats using gpu thanks [12:17] <JEEB> ... [12:17] <JEEB> jesus christ, of course offloading does _that_ [12:17] <JEEB> now pretty please read what exactly your solution is doing [12:18] <JEEB> for fuck's sake [12:18] <JEEB> if it's actually using GPGPU for encoding it's most probably useless as fuck as far as compression goes - if it's ASIC-based it's less retarded, but still worse bang for the buck than x264 unless your CPU is fucking underpowered [12:19] <JEEB> also as I said a few times, actually currently the best goddamn ASICs are at Intel, so you don't even need to get a fucking dGPU for that :V [12:20] <Chaz6> on slight detour, the logitech c920 1nc c930e have onboard h264 encoders, but only the c920 encoder is accessible from directshow/v4l2 x.x [12:20] <Chaz6> *and [12:20] <Chaz6> fucking logitech [12:20] <JEEB> regarding whatever else that application you're using is doing on the GPU, some of that might actually be useful - as in stuff regarding actual image manipulation (scaling/filtering/whatever), and possibly decoding the video with the integrated decoding ASIC [12:21] <JEEB> but if we limit ourselves to encoding, GPUs are a fucking waste in general. If you've got one of those models with ASICs and can actually use it, that /can/ be of use, but is meant for a subset of things that x264 is meant for (low-latency, no need for hard compression etc) [12:22] <DopeLabs> its just a screen capture/streamer app.. much faster and less expensive than the cpu encoders (at least on my particular system) [12:22] <JEEB> please at least look into things and read what I've said :P Maybe after that you might understand a bit better [12:22] <JEEB> and/or put your thoughts into words better [12:22] <DopeLabs> i understand fine [12:23] <gilbahat> JEEB: but you see, intel tied the thing to desktop CPUs mainly and it's not available on cloud services [12:23] <JEEB> gilbahat, aye [12:23] <JEEB> DopeLabs, ok, so do you know if your solution is using the actual GPU hardware or a separate ASIC? [12:24] <DopeLabs> well as its a macbook pro from a few years ago... [12:25] Action: JEEB sighs [12:25] <DopeLabs> its actually older than i thought it was lol [12:26] <JEEB> so yes, my recommendation stands: please learn more about these things and read what I noted to you, so you can move away from misleading/wrong on the internet arguments [12:26] <JEEB> it's just tiring to lecture someone for the umpteenth time on what is actually useful in hardware encoding and what is not :V [12:26] <DopeLabs> im not arguing anything.. im not here to get any advice about it... i already know which works better (for me) [12:27] <gilbahat> thank you very much, you've helped set things straight with this [12:27] <JEEB> you might actually want to look into some things regarding that. as in, what's it using and how [12:27] <JEEB> and how much worse the compression efficiency is, etc [12:28] <JEEB> because it can be very much misleading to note things like "<DopeLabs> i would rather use gpu based for x264 encoding than cpu..its much faster / less expensive on the resources" [12:28] <DopeLabs> (for me) [12:28] <DopeLabs> on that particular laptop.. over there [12:29] <JEEB> well, even for you, you don't have the information needed to actually note why it is and if it really is, other than you lose cpu usage [12:29] <JEEB> if you learn about these things you can actually put your ideas into proper words :P [12:29] <JEEB> which are much less misleading [12:29] <DopeLabs> do i realy need anymore information about it? [12:29] <JEEB> yes [12:30] <JEEB> because then you know what kind of solution you want and what solutions you don't want [12:30] <DopeLabs> its not going to change the way i encode on that laptop at all [12:31] <JEEB> even for a herp derp person like you this should be a fucking obvious case: there's vendor a) giving you GPGPU based encoding , and there's vendor b) giving you ASIC based encoding [12:31] <JEEB> right now you are oblivious and neither of those market their solution as such [12:31] <JEEB> because the "GPGPU" marketing word is much more effective [12:31] <DopeLabs> i already know which is better... [12:31] <JEEB> thus, if you don't learn, how do you know which of them is actually which it is [12:31] <JEEB> but you don't! [12:31] <DopeLabs> but i do [12:31] <JEEB> you don't want to learn more [12:32] <JEEB> as I said, neither of them will market it [12:32] <JEEB> if they use the actual general computing shit on the GPU versus some encoding-specific ASIC [12:32] <gilbahat> is there any reason either x264 or ffmpeg never implemented nvenc or QSV support? [12:32] <DopeLabs> you dont have to tell me that asic's are more efficient [12:32] <JEEB> nvenc had some crap regarding the licensing [12:33] <JEEB> DopeLabs, yes but how the fuck would you learn which would be which [12:33] <JEEB> buy both!? [12:33] <JEEB> if you don't want to do fucking research [12:33] <DopeLabs> im not buying either one [12:33] <JEEB> :V [12:33] <JEEB> seriously, I'm just trying to tell you that actually learning about this shit can be fucking useful [12:33] Action: Mavrik hugs JEEB. [12:34] <DopeLabs> and again.. i have [12:34] <JEEB> then why the fuck can I see you being ignorant here and spewing shit that can be easily quoted so that it makes no fucking sense [12:34] <JEEB> I can quote that one line of yours again if you want [12:34] <DopeLabs> i went through all this shit when transitioning from gpu to asic based hashers for btc's [12:34] <DopeLabs> sure [12:34] <DopeLabs> quote it up [12:35] <DopeLabs> i also said.. for this particular laptop, and for (me) [12:35] <JEEB> <DopeLabs> i would rather use gpu based for x264 encoding than cpu..its much faster / less expensive on the resources [12:35] <JEEB> yes, you said that later [12:35] <JEEB> that specific line is as it is [12:35] <DopeLabs> everyones setup is different [12:35] <JEEB> :V [12:35] <JEEB> anyways, for fuck's sake stop being ignorant and actually learn about what your solution uses and why it is useful to you [12:35] <JEEB> that way your arguments will become better [12:36] <JEEB> and if you choose to not be ignorant you can actually do better selections in the future [12:36] <DopeLabs> so when i have ableton live, vdmx, anda bunch of other shit going on, yes ill take the gpu/graphics card encoding solution rather than the cpu based one so i can have the resources i need thanks [12:36] <JEEB> as I said, neither vendor A or vendor B will tell you which hardware encoding APIs they will use in their marketing shit [12:37] <JEEB> and if you have no interest towards "what's inside", you will happily take the one that's worse :P [12:37] <JEEB> but I'm pretty sure I've said enough here and I hope you've learned something [12:37] <DopeLabs> spose it depends on what your application is and how your using it to be able to define which is 'worse' [12:38] <JEEB> no, with the scenario I just put to you there is clear worse and clear better [12:38] <DopeLabs> likewise [12:38] <JEEB> vendor a's shit will suck because doing the encoding on the actual general computational hardware makes no fucking sense [12:39] <JEEB> vendor b's shit will still suck for heavy compression needing things, but from the two it's the better one [12:40] <JEEB> I specifically gave you two alternatives where they both do what you seemingly wanted -- offload the encoding off from the CPU part of the CPU or whatever else you're going to use [12:40] <JEEB> gilbahat, if x264 implemented either of those it would no longer be x264 [12:40] <JEEB> because those are black box solutions [12:40] <JEEB> and I thought there was some sort of QSV support already in? I remember talking with the intel guy [12:41] <JEEB> in Libav/FFmpeg that is [12:41] <JEEB> nvenc had some licensing-related issues [12:48] <DopeLabs> mmm yt supporting 60fps now/soon [12:50] <gilbahat> JEEB: it's not uncommon to yield to a hardware implementation, but that's a philosophical argument that's not the least bit interesting. ffmpeg bumped into licensing issues you say? [12:51] <JEEB> I think the implementation of NVenc needed some stuff that was in the SDK that wasn't usable [12:51] <JEEB> I don't remember the exact details [12:51] <JEEB> -devel IRC logs should have some stuff [13:11] <anshul_mahe> how to call avcodec_decode_video2 so that i only get information in frame side data no decoding [13:15] <anshul_mahe> I do not want to decompress any frame, just extract raw closed caption in user dat [13:16] <JEEB> then you probably want to only use lavf, not lavc. although you will have to parse the actual video stream by yourself in that case, lavf will only give you packets methinks [14:38] <anshul_mahe> thanks jEEB [14:51] <Fjorgynn> fish [15:29] <cdecl_xyz> hello, is this the right place to ask questions about swscale ? [15:29] <Fjorgynn> what is swscale [15:29] <cdecl_xyz> libswscale [15:29] <Fjorgynn> aha [15:31] <cdecl_xyz> i have questions regarding libswscale and how to do proper colorspace conversion (full range -> smpte range). is this the right place? [15:33] <Fjorgynn> just ask [15:36] <cdecl_xyz> in sws_getContext, sws_setColorSpaceDetails gets called with ff_yuv2rgb_coeffs[SWS_CS_DEFAULT] for input and output color space range. my question is, if I want the color space output to be SWS_CS_ITU709, do i also have to change the input color space? I assume yes. But then I would have to know which space the source is in right? So the user must set it or is this stored in certain containers? [18:06] <pfloyd> my tv doesn't support 1080p@50Hz and I'm trying to play back a 25fps PAL HD bluray rip on my popcorn hour. The result is very jerky playback, especially when panning. I'm assuming it's frame skipping/dup'ing and not TV judder since normal NTSC content is ok. can I convery with ffmpeg from 25fps PAL to 24p to smooth the playback? [18:12] <c_14> You can try one of the commandlines from 'https://ffmpeg.org/pipermail/ffmpeg-user/2013-July/016098.html' [18:12] <c_14> Change codec options and input/output filenames/formats to whatever you need. [18:13] <Mavrik> pfloyd, what you just wrote makes absolutely no sense [18:13] <pfloyd> but the video does need to be re-encoded (i.e. some lossiness) then, right? [18:14] <Mavrik> why would 24fps video which isn't synced to your display framerate work better than a 25fps progressive video? [18:14] <Mavrik> you have another issue probably. [18:14] <pfloyd> Mavrik: probably. all I know is 25p content plays like complete shit on my PCH+TV and my TV does not support 50 Hz. regular NTSC HD content plays as I'd expect, with the normal judder due to lcd/led tv technology [18:15] <Mavrik> 25Hz support? do you have an american TV? [18:15] <pfloyd> yes it is an american tv and I'm trying to play pal content [18:16] <Mavrik> hmm [18:16] <Mavrik> has to be one shitty tv [18:16] <Mavrik> but yeah, you have to reencode for that IIRC [18:17] <pfloyd> *shrug* probably is "shitty" but it's good enough for me. thank you c_14 [18:18] <Mavrik> note that while cheap and easy, c_14's command line will make movies slightly wierder due to them not having proper telecine [18:19] <Mavrik> but then again, most PAL content was authored that way, so *shrug* :) [18:21] <pfloyd> yeah that's true. but at least it won't look like utter shite haha [18:22] <pfloyd> my friend's plasma has no such issues, but I'm guessing it's because it can output at 1080p @ 50Hz ? [18:22] <Mavrik> probably, depends on what TV does [18:22] <pfloyd> i'll have to have him check next time I'm over there [18:22] <Mavrik> mine can do 24p/25p as well and then does some wierd "movie" postprocessing stuff on image when that kind of input is detected [18:23] <Mavrik> your image might be mauled by the player as well, since it sounds like it's forcing 50Hz output for 25p video [18:23] <Mavrik> (or is your video 1080i@50?) [18:37] <pfloyd> no it has the option to force whatever output I want. it looks like it's coming out at 60 Hz [18:37] <pfloyd> if I put it on auto, it tries to to 50 Hz and my tv throws a "not supported" message when it tries to play [18:39] <pfloyd> and while he has an older model ,his is a popcorn hour also so I think it's the tv :/ but I just bought it a few years back no way is $wife gonna let me get something else hahahh [18:41] <Mavrik> mhm [18:42] <Mavrik> I'm just asking because my player has the option to either sync output to video or just output everything at 1080@60 or whatever is set [18:45] <pfloyd> yeah same here [18:46] <pfloyd> but yeah I figured the crux of the problem was "cheap tv" hahah [18:49] <pfloyd> Mavrik: one other question. it's been a while since I've used ffmpeg. my command line is: ffmpeg -y -threads 0 -i input.mkv -filter:v setpts=25025/24000*PTS -vcodec libx264 -preset slow -crf 21 -acodec ac3 -ac 6 -ab 1500k -ar 48k -filter:a atempo=0.959040959040959 -f matroska -r 24000/1001 output.mkv but the output size is quite a bit smaller (646MB vs. 2.2 GB). I'd like to keep the video quality high and thought -crf 21 and -preset slow would be good, but ... [18:49] <pfloyd> ... wow 1/3 the size? [18:58] <pfloyd> I guess I can find out the input video bitrate and use -b <that> and -qscale 0 ? [18:58] <spaam> using -crf 21 and slow and complain about file size its to small? :S [19:01] <pfloyd> well those settings used to work without a huge size drop but I haven't used ffmpeg in about 4-5 years heh [19:02] <pfloyd> but then again, the input files I was dealing with were already very compressed back then (ipod/iphone videos) [19:02] <pfloyd> so that makes sense. so what should I do to make it automatic without having to pre-determine the bitrate and then pass that to -b? [21:39] <cdecl_xyz> in sws_getContext, sws_setColorSpaceDetails gets called with ff_yuv2rgb_coeffs[SWS_CS_DEFAULT] for input and output color space range. my question is, if I want the color space output to be SWS_CS_ITU709, do i also have to change the input color space? I assume yes. But then I would have to know which space the source is in right? So the user must set it or is this stored in certain containers? [00:00] --- Mon Aug 18 2014

1 0

ffmpeg-devel.log.20140816
by burek 17 Aug '14

17 Aug '14

[00:18] <J_Darnley> Really? I read that alignment was not nessecary for avx [00:25] <J_Darnley> Oh wait. That says "most". How the heck do you which need alignment then? [00:25] <jamrial> aligment is still necessary with avx and above for instructions that read 16 or 32 bytes [00:26] <J_Darnley> Then Intel's own manual should state that! [00:27] <J_Darnley> That is clear! [00:27] <jamrial> usually, if it doesn't state somewhere that an instruction works with unaligned data, then it doesn't :P [00:27] <J_Darnley> "Most VEX-encoded 128-bit and 256-bit AVX instructions (with both load and computational operation semantics) are not restricted to 16-byte or 32-byte memory alignment" [00:27] <jamrial> i use this https://prd1idz.cps.intel.com/sites/default/files/managed/68/8b/319433-019.… [00:32] <J_Darnley> I've been reading "Intel® 64 and IA-32 Architectures Software Developers Manual" volumes 1, 2a, 2b [00:38] <J_Darnley> More rebasing then [00:45] <J_Darnley> In that case I also shouldn't need a separate condition for avx. The x86inc abstraction should do what I need. [00:55] <jamrial> huh, seems that you were right after all. just tested the vex versions of some instructions and they can read unaligned memory [00:55] <jamrial> wonder why i ran into crashes before [00:55] <J_Darnley> the abstraction emulating with aligned loads? [00:56] <jamrial> no, i tested on an avx enabled machine, x86util didn't do anything in that regard [00:57] <J_Darnley> okay [00:57] <jamrial> the xop code you wrote should be ok then. still, it would be better if you keep the order of instructions for the sse4 version intact [01:06] <J_Darnley> Now how do I change my branch back to that old commit? [01:07] <J_Darnley> Ah just an uppercase B in git checkout -B [01:18] <ubitux> michaelni: so is this coccinelle this time? :) [01:20] <wm4> looking at the first change of the first patch, I'm not sure if fclose(NULL) works (although it's implied it's called) [01:20] <wm4> ubitux: have you ever used coccinelle? [01:21] <ubitux> yes, one or two times [01:21] <ubitux> for 1ec94b0f066f14153d86395980a31b7466de3d9d last time [01:22] <wm4> how is it? was it hard to get started/to get it work= [01:22] <ubitux> interesting, not mature [01:22] <ubitux> i retested a few hours ago actually [01:22] <ubitux> it took 40 sec to process ffmpeg.c (4k LoC) [01:23] <ubitux> so i gave up on looking any further [01:23] <ubitux> the documentation seems to still sucks hard [01:24] <wm4> :( [01:24] <michaelni> ubitux, yes [01:25] <wm4> also, 0 is a valid null pointer constant [01:25] <michaelni> sure [01:26] <michaelni> question is should the patch be applied or not [01:26] <wm4> probably should [01:28] <J_Darnley> is fclose(0 or NULL) really safe? [01:29] <wm4> J_Darnley: I'm pretty sure it's not [01:42] <cone-14> ffmpeg.git 03Michael Niedermayer 07master:65f05eff0a5d: avfilter/lavfutils/ff_load_image: Return error if no frame could be decoded [01:46] <J_Darnley> Reaching EOF without closing an if statement. Surely that must be some syntax error, yasm? [02:11] <Timothy__Gu> Did anyone watch the CodeJam final? [02:15] <Timothy__Gu> michaelni: how did you find a need for commits like http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=9c712d0b1608ec998dbe41… ? [02:16] <Timothy__Gu> Do you use some kind of static analyzer or did you encounter a clip that causes memleak? [02:16] <Timothy__Gu> Oh never mind [02:17] <Timothy__Gu> It's just a fix-up of the parent commit [02:20] <michaelni> Timothy__Gu, yes, i just spoted then when reviewing the patch [02:20] <Timothy__Gu> Alright [02:23] <Timothy__Gu> Huh? I'm already op how can I be +v again? [02:25] <BBB> Timothy__Gu: theyre different flags [02:26] <BBB> its like being u+rwx and getting g+rwx for a file with group rbultje user rbultje on my laptop [02:27] <BBB> not very useful, but strictly speaking theyre different flags so semantically it makes sense [02:27] <Compnn> run as root anyways. [02:27] <Compnn> screw permissions [02:27] <BBB> am I the only one whos getting mildly frustrated with all the kind advice on how to run a project from our dearest friends in debian [02:28] <BBB> youshoulddothis and youshoulddothat [02:28] <BBB> I wish they didnt do that [02:28] <wm4> they don't really have an idea what the problem is [02:29] <Compnn> its mostly 'you should get back together and be friends' or some iteration thereof [02:29] <Compnn> feels like 2011 all over again [02:29] <wm4> so did debian decide yet whether they want ffmpeg or libav [02:29] <Compnn> rather avoid bikesheds like this [02:39] <jamrial> wm4: users want ffmpeg. debian security team doesn't really care but would rather stick with libav since it's already there and tested [02:39] <jamrial> that's more or less what i could gather from this thread and earlier discussions [03:03] <Plorkyeran> re fclose(0): The fclose() function does not handle NULL arguments; they will result in a segmentation violation. [03:03] <Plorkyeran> also I'm always amused by the os x man pages saying things are FreeBSD implementation details (such as that) [03:57] <Compn> j-b : like i said, i dont think ffmpeg and libav will be reuniting [03:57] <Compn> i'm not really interested in libav's developer rules either [12:12] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:82e0cb360aaa: avformat/thp: dont mix integers with pointers [12:33] <cone-714> ffmpeg.git 03Reimar Döffinger 07master:c2829dc925ff: dict.c: Add av_dict_set_int helper function. [12:33] <cone-714> ffmpeg.git 03Reimar Döffinger 07master:a0941c8a2b3e: Use new av_dict_set_int helper function. [12:52] <cone-714> ffmpeg.git 03Reimar Döffinger 07master:bddc592001bd: dict.c: empty dictionaries should be a NULL pointer. [13:53] <Compn> michaelni : i dont think your mail was insulting :( [13:54] <Compn> sigh [13:54] <Compn> j-b : you name caller you! [13:54] <Compn> like 4th grade all over again [13:55] <wm4> hue [13:56] <wm4> that reminds me, didn't michaelni agree to step down if there's another non-evil person who wants to be maintainer? [13:56] <wm4> so, volunteers, take a step forward [13:56] Action: wm4 takes a step backwards [14:00] Action: ubitux wonders what's this overreacting mail all about again [14:21] <wm4> so who here is against Libav commit rules [14:21] <wm4> reminder: it means that each patch must be reviewed by 2 maintainers (or something) before it can be pushed [14:22] <J_Darnley> I don't really know and I'm not sure I care? [14:22] <nevcairiel> if its really 2, its not like they really follow it, usually one vague "probably OK" is all it needs [14:23] <michaelni> wm4, yes iam happy to resign if this resolves the situation [14:28] <nevcairiel> hm, reimar pushed from the future, all his commits are at least stamped 20 minutes from now [14:28] <ubitux> wm4: i'm against [14:28] <michaelni> can someone review a few patches btw, there are a few on the list that need reviews [14:28] <wm4> time traveling has its perks [14:29] <wm4> ubitux: why and what would you want changed [14:29] <michaelni> from v4l2, over fic to a few really trivial ones from me [14:30] <ubitux> wm4: i want to be able to push trivial stuff like ee7ee9b the minute i see them without generating ml noise, and i also want to be able to work on code i maintain freely as long as it's not affecting some other people code [14:32] <ubitux> wm4: also, i want to be able to push after 3 days if i see no comment on patches i submit [14:32] <ubitux> i make a personal exception for myself concerning api changes, but i don't think it should be applied to anyone [14:32] <ubitux> basically... i like how it currently is in ffmpeg [14:33] <ubitux> (by exception i mean i won't push after 3 days if i see no review, because i'm not comfortable doing this, and i'm fine if other ppl prefer to push in such situation) [14:34] <ubitux> i think that way of handling the project has proven to be effective so far [14:36] <ubitux> (this also means that developers who care should register to -cvslog, or follow the git log) [14:37] <kurosu> is there an lav utility function converting a known-length, non-null-terminated buffer into a string, in particular for metadata ? [14:37] <wm4> and you don't think temporarily losing these rules would be worth for merging the two projects? [14:37] <wm4> kurosu: av_strndup [14:38] <wm4> for metadata, an av_dict_snprintf() would have been useful [14:38] <ubitux> wm4: not so sure, because i don't think i'm the only one to share a similar opinion on the matter [14:39] <ubitux> wm4: if i need to send a patch for ee7ee9b, i won't do it [14:39] <ubitux> wm4: if i can't push something on my code because no one care about giving a meaningful or meaningless review, it will drives me away from the project [14:40] <wm4> also the commit message of that commit has a typo [14:40] <wm4> not the best way to demonstrate your point [14:40] <ubitux> wm4: also, i saw the level of review slightly decrease on libav side especially because review became a core [14:40] <wm4> chore? [14:40] <ubitux> yes, +h sorry [14:40] <ubitux> wm4: the "vissible" typo is what i fix [14:40] <wm4> oh, I see, the typo in the commit message is intentional [14:41] <wm4> but really, what patches that don't need review are there, aside from typos [14:41] <ubitux> anyway, i believe the strict rules from libav are an hindrance to the progress of the project [14:41] <wm4> which could actually be not typos... [14:42] <ubitux> small spaces shuffles [14:42] <ubitux> or small indent fixup or whatever [14:42] <ubitux> wm4: this one for instance: 7ac7e879 [14:45] <ubitux> the 3-days timeout is very important too [14:45] <ubitux> basically, it doesn't force people to do meaningless review on stuff they don't know [14:45] <ubitux> we can't make a distinction between meaningful and meaningless reviews on libav because they are all force to do them [14:47] <ubitux> so when someone who works only on formats and protocol says OK to an ASM change in libavcodec, there is no way to know if it's just been reviewed on the way the code looks or if he has expertize in the matter [14:47] <ubitux> this happens less in ffmpeg, because people don't feel the need to review stuff they don't know [14:48] <wm4> well, I don't know, I like that each change has to be looked at by someone else, even if that someone else is not necessarily an expert [14:48] <ubitux> this is what -cvslog is for [14:49] <ubitux> i don't read all the patches that go on the ml, but i actually do read cvslog as a matter of curiosity on areas i don't know [14:50] <wm4> getting a commit reverted is much harder than just nacking a patch [14:50] <ubitux> that way, i don't need to irresponsably review stuff i don't know nor prevent its inclusion [14:50] <J_Darnley> michaelni: okay, I'll start by looking at your trivial NULL check patches [14:51] <michaelni> if a commit is crap it should be reverted, it shouldnt be hard. [14:51] <ubitux> wm4: probably yes, but i think it's less important than the drawbacks i listed, especially if the people of the project are relatively wise [14:51] <michaelni> J_Darnley, thx [14:52] <ubitux> wm4: you might arguee we're all stupid kids though ;) [14:52] <ubitux> wm4: the only place where i see this problematic is when a maintainer pushes stuff in a gray area where some other people would disagree [14:53] <ubitux> typically if Carl pushes stuff on the lib detections in configure ;) [14:53] <ubitux> but honestly, it's of relative importance [14:54] <ubitux> i aknowledge the current disagreements and problems, i just think they are way less a problem than the hindrance of forced review [14:54] <ubitux> wm4: should we review all the merges from michael? :) [14:54] <ubitux> if we do, we do it on cvslog [14:55] <wm4> no, but all commits from michael [14:56] <ubitux> i believe michael learned when to send patches (api changes, another maintainer area), and when not to (mainly non sensible fixes) [14:56] <ubitux> i like how it is currently [15:00] <iive> ubitux: were you around here during the time of the take-over? [15:01] <ubitux> i arrived in the project around that time [15:01] <ubitux> i read the threads daily, but didn't participate [15:01] <wm4> at the time I was just watching from the outside [15:01] <wm4> but I agreed with the fork [15:02] <wm4> it was just later that the fork business turned out as disaster [15:02] <nevcairiel> it turned out a disaster because they didnt fork, they tried to do a hostile takeover [15:03] <wm4> which turned into a fork after it didn't work [15:03] <wm4> (lol) [15:03] <nevcairiel> but thats the reason its a disaster [15:03] <wm4> yeah [15:03] <ubitux> i'd suggest to get over it for now and instead focus on the current state & methods of each project [15:03] <wm4> I see subtle differences in the review process [15:03] <ubitux> IMO these 3 years have shown the limits of forced reviews [15:03] <iive> well, imho, it turned out a disaster, because the new rules were not enforced honestly [15:03] <wm4> which emerged _after_ the fork [15:04] <ubitux> OTOH i think the ffmpeg project became wiser, even though the rules haven't changed much [15:04] <iive> developers who didn't support the take-over were pushed away, patches delayed and not reviewed. [15:04] <nevcairiel> to me it seems the other side seems to not even be open to discuss any changes, their way or the high way, etc [15:05] <iive> the new FFmpeg methodology to a bigger extent completely avoid the possibility of this happening here. [15:05] <iive> libav rules were created with intent of manipulating them. [15:05] <ubitux> i think it's more important to have a discussion when a problem occurs than forcing strict rules [15:06] <iive> absolutely [15:06] <ubitux> michael didn't change his way on working on ffmpeg because we setup new rules [15:06] <BBB> <ubitux> so when someone who works only on formats and protocol says OK to an ASM change in libavcodec, there is no way to know if it's just been reviewed on the way the code looks or if he has expertize in the matter [15:06] <BBB> that ^^ [15:06] <wm4> nevcairiel: actually nobody seems to be ready to accept change [15:06] <BBB> that is exactly my problem with peer review [15:07] <iive> rules are just mementos of past mistakes, with the purpose to avoid them in the future. [15:07] <BBB> (at least the way opensource people do it) [15:07] <ubitux> wm4: i think ffmpeg is open to changes, but it has to be justified and proven effective [15:07] <ubitux> forced review wasn't IMO [15:08] <ubitux> if i'm the only one to think that, then be it, i'll leave this to people in charge [15:08] <ubitux> but i don't think that's the case [15:09] <ubitux> wm4: it's an intereting discussion, i think you could share that backlog with libav devels if they're willing to remove their blinkers for a moment [15:09] <wm4> well the log is public [15:10] <saste> ubitux, +1, no-review for trivial patches, no need for reviews for patches under maintainer's area, API and controversial patches sent for review to the ML as exception [15:10] <ubitux> yes, it's basically common-sense vs strict rules [15:10] <ubitux> you have strict rules with people you can't trust [15:10] <BBB> you havent discussed patch blocking yet [15:10] <iive> +1 [15:10] <saste> in general the maintainer is empowered and trusted, this limits the review chore and avoids fake-reviewing [15:10] <BBB> if you wnt to share this with libav anyway [15:11] <BBB> the way baptiste used to block patches was beyond disgusting [15:11] <BBB> libav does the same nowadays [15:11] <wm4> blocking by not replying in any way? [15:11] <BBB> oh, your whitespace isnt up to gods standards, let me block your patch [15:11] <wm4> ooh. [15:11] <BBB> and other stuff complete irrelevant to the functionality of the patch [15:12] <ubitux> do we have such problems currently? [15:12] <wm4> so there's a bit too much micromanagement about things that don't matter [15:12] <wm4> (hurrr cosmetics) [15:12] <BBB> patch review should be deep and meaningful, such a to help the quality of the project, not show off the incompetence of the reviewer or non-bugs by the developer [15:12] <BBB> ubitux: we dont; we did, though [15:12] <BBB> baptiste was a terrible example of this [15:12] <BBB> he was truly horrible [15:12] <ubitux> i'm not sure i have an answer to patch blocking, but i don't think a general rule can do something about it [15:13] <BBB> its a concept we have to be aware of and prevent it from occurring again [15:13] <ubitux> i guess it all goes down a human issue [15:13] <ubitux> +to [15:13] <ubitux> also, having a "dictator" helps in that matter, as it acts as a mediator [15:14] <ubitux> assuming he's wise enough, and technically up to [15:14] <wm4> ubitux: michaelni is a terrible mediator though [15:14] <iive> i don't agree [15:14] <ubitux> i'm not so sure about that [15:14] <iive> he is entirely focused on the code side, not on the human side. [15:15] <wm4> and utterly incompetent in social issues [15:15] <ubitux> you can't put someone too emotionnally sensible as a mediator [15:16] <iive> well, diego is excellent as social mediator. [15:17] <ubitux> that's the kind of mediator i would be extremely afraid to have [15:18] <iive> that's my point. [15:29] <ubitux> wm4: how does it work in mpv btw? do you get review for all your patches? [15:30] <wm4> ubitux: no, there are not enough developers for that, I just push whatever I feel like pushing (it's great) [15:31] <wm4> other developers which "own" a subsystem are free to push too, though [15:31] <wm4> but it's a very very tiny project, but a ffmpeg [15:31] <wm4> *not [15:32] <ubitux> yes, there are a lot of differences [15:32] <ubitux> note thought that pushing directly to ffmpeg is backed up by several things [15:32] <ubitux> such as tests, in addition to people following cvs-log [15:33] <Compn> wm4 : me, i like committing directly :P [15:33] <Compn> but i'm not a big devel... [15:34] <ubitux> Compn: actually, i wouldn't mind if *you* could send some patches instead sometimes ;) [15:34] <Compn> ;P [15:36] <Compn> i think we should try examples [15:37] <Compn> there are going to be differences of opinions on patches [15:37] <Compn> who decides which party is correct ? when one devel says its ok, and one rejects it ? [15:37] <ubitux> discussion [15:37] <saste> Compn, in practice it worked fine most of the times [15:37] <ubitux> and if it leads to nowhere, mediator [15:38] <Compn> hey saste :) [15:38] <saste> we have to manage a (relatively) small project, not a country [15:38] <Compn> i remember commit war [15:38] <Compn> but ok , it did work for the most part [15:38] <saste> I don't remember serious flames after the fork [15:39] <Compn> right, i mean if we get back together [15:39] <ubitux> it should be progressively [15:39] <Compn> the ml is currently very calm :) [15:39] <ubitux> otherwise it won't work [15:39] <saste> basically the internal tensions were resolved when the disagreeing contributors left the project [15:39] <Compn> right [15:40] <Compn> saste : j-b wants us to get back together and be friends [15:40] <ubitux> yes, naruto want that too [15:40] <ubitux> +s [15:40] <saste> Compn, uhm, start convincing libav to join [15:40] <iive> yes, it would save a lot of code merging [15:41] <saste> i'm for merging back too, but i'm not too positive about the fact that it can be done in practice [15:41] <saste> starting from choosing the new repository [15:41] <ubitux> easy, the one that has both ffmpeg and libav changes ;) [15:42] <saste> also, i've been told many times from libav developers that they are happy the way we are [15:42] <saste> and ffmpeg developers seem also to be mostly happy about the current situation [15:42] <saste> so the main problems are for users [15:42] <iive> actually [15:43] <iive> it would help if ffmpeg and libav developers talk more about how to solve problems [15:43] <iive> even if at the end there is no agreement, there is still a chance for having technical discussion [15:44] <ubitux> yes, maybe they should join here [15:44] <ubitux> like some of us do on their channel [15:44] <ubitux> it may help communicating a bit [15:45] <ubitux> we're not really welcome there though [15:59] <kierank> Compn: it's not going to happen all of a sudden [15:59] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:2d7cec14beb5: avcodec/dvdsubdec: Dont mix integers with pointers [15:59] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:0014541e9a23: avcodec/dvbsubdec: dont mix integers with pointers [15:59] <kierank> there will be a shared mailing list of some sort [15:59] <kierank> and then it'll go from there imo [15:59] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:7916053cedb4: avformat/udp: dont mix integers with pointers [15:59] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:74c81106d231: avformat/udp: remove unneeded variable initialization [16:00] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:97bb456b6b78: avcodec/hevc_mvs: dont redundantly initialize ref_idx_curr [16:00] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:e7f3b507a343: avcodec/mips/compute_antialias_float: remove unused variable [16:00] <kierank> http://www.slate.com/features/2014/07/middle_east/graphics/graphical_versio… [16:14] <funman> flfimbpaevg [16:18] <wm4> kierank: should make such a chart for ffmpeg/libav [16:27] <kierank> wm4: yeah [16:27] <ubitux> lol durandal_1707 [16:27] <ubitux> (re: missing signed-off) [16:30] <durandal_1707> why is VDD so far away? [16:39] <wm4> "Social people not having any empathy for non-social ones really is a joke." [16:39] <wm4> heh [16:58] <saste> yeah i'm tired by that attitude [16:58] <saste> also if they feel the need to communicate with michaelni maybe they can remove the ban on the ML/IRC [16:58] <saste> that would be a start [16:59] <saste> the rest is hypocrisy [16:59] <ubitux> they don't want to, because michael is stealing open source code [17:00] <kierank> it's the other way round [17:00] <kierank> michael complains he can't communicate with libav [17:01] <ubitux> why would they impose the worst possible medium for such thing? [17:01] <saste> kierank, and the usual reply from libav is, only RL matters [17:01] <kierank> ubitux: irc and emails have made so much progress you know [17:01] <kierank> look at where we are now compared to 2011... [17:01] <saste> that is they only admit the only mean that michaelni will surely avoid [17:02] <saste> kierank, where are we now? [17:02] <kierank> nowhere [17:02] <kierank> we have moved a total of 0m [17:02] <kierank> from 2011 [17:02] <saste> i'd say at the same point, but at least there are no internal flames [17:02] <saste> we have no major internal management issues in ffmpeg, that's at least something [17:03] <kierank> true [17:03] <saste> we lack on PR and on organization, that was never a strong point of ffmpeg [17:03] <saste> much less after the fork [17:03] <ubitux> we lack manpower, and distribution :) [17:03] <kierank> raising money for OPW because libav did OPW is totally unnecessary [17:04] <kierank> it's pure jealousy [17:04] <ubitux> it's part of being a superset on all levels [17:04] <kierank> lol [17:04] <saste> kierank, that's a legitimate standing, but it's your personal position [17:04] <nevcairiel> Didn't they just leverage the money out of the opw organization somehow [17:05] <kierank> I don't have an objection with OPW itself [17:05] <kierank> I have an objection with ffmpeg doing from what appears to be just because libav did it [17:05] <saste> i dislike OPW because i consider it discriminatory on a sexual basis, but others consider that an opportunity to gain new contributors [17:06] <ubitux> kierank: i see no difference with patch picking/merging [17:06] <ubitux> it's all about competition [17:06] <ubitux> "jealousy" is your interpretation [17:06] <saste> ubitux, competition sucks [17:06] <ubitux> maybe [17:07] <saste> but it is culturally hardwired in us, so deal with it [17:07] <saste> cooperation is much better, but we can't manage that [17:07] <saste> so let's just kill each other, it's easier [17:07] <ubitux> :)) [17:08] <ubitux> cooperation between two projects with the same codebase will lead to a merge, that's probably what some people want to avoid [17:09] <ubitux> i think all we can do is just keep honoring all their changes, and welcome those who want to contribute [17:26] <kierank> ubitux: I can't tell if you are serious or not about opw [17:34] <iive> imho, the opw from ffmpeg was a mistake [17:35] <iive> ffmpeg didn't had the cash, so it would likely fail. there is already somebody working on it in libav. [17:37] <durandal_1707> are you referring to K&R and splitting? [17:46] <saste> iive, we had a few chat meetings with OPW admin (me, michaelni, and reynaldo) [17:46] <saste> the bottom line is that if we don't gather enough money, we'll join the next round [17:47] <saste> so time is not a problem, also we just need to find one or two commercial sponsors to get the required money [17:47] <saste> that's not unreasonable [17:49] <iive> it would look quite pity if we can't collect the money. [17:51] <iive> and that's quite a lot of money for such bare-bone project as ffmpeg. [17:52] <iive> btw, do we still have people in FFmtech board and does somebody know what is going on there? [17:53] <durandal_1707> avscale? [17:53] <Compn> iive: reimar was there, dunno about now [17:57] Action: durandal_1707 wonders when mxf signed-off patch will appear [18:26] <Compn> so [18:26] <Compn> whos working to merge mythtv back to ffmpeg ? [18:26] <Compn> :) [18:26] <Compn> the mythtv devs gave up on it years ago [18:26] <Compn> so someone of us is going to have to take over. [18:27] <Compn> i guess a first start would be cutting patches out and submitting them to the list for review [18:27] <Compn> verifying they compile and pass fate [18:27] <Compn> any volunteers ? :) [18:29] <Daemon404> wouldnt all their patches be ancient [18:29] <Daemon404> or just useless hacks [18:31] <Compn> Daemon404 : wm4 did a diff of ffmpeg , http://sprunge.us/gTcY [18:32] <kierank> mostly just niche ts features [18:32] <kierank> the reason they didn't get merged is because ffmpegcli wouldn't know how to deal with the ts data formats for interactive tv etc [18:33] <Compn> ffmpegcli isnt the only user of libavcodec/libavformat [18:33] <kierank> of course [18:34] <kierank> but then people want FATE tests which inherently require ffmpegcli [18:34] <wm4> yeah, too much focus on ffmpeg.c :( [18:34] <Compn> i dont think fate tests are a blocker for closed caption support [18:34] <Daemon404> +libavcodec/dvbsub_parser.c // Fix for #5978 [18:34] <Daemon404> i wonder about this sort of stuff [18:34] <Daemon404> why not just send that upstream [18:35] <Compn> Daemon404 : because the old development rejected it. now we're ready to accept things. maybe. [18:35] <Compn> more accepting of things. [18:35] <Daemon404> tsundere ffmpeg [18:39] <Compn> and ffmpegcli intergration with new features is also not a blocker. especially when those features (interactive tv / teletext) can be used by other projects like vlc [18:39] <Compn> at least in my opinion, which means little :) [18:40] <Compn> kierank : i'm curious why you think everything is a blocking issue? where in the ffmpeg developer rules is that written ? :P [18:40] <Daemon404> ffmpeg/c integration should not be a blocker, no. [18:40] <kierank> Compn: i didn't say it was a blocking issue [18:40] <kierank> but every patch i send it seems someone wants a fate test [18:40] <Compn> its a request for a fate test. [18:41] <Compn> request, not blocker [18:41] <Compn> we do like to have samples of course and be able to test patches. [18:42] <Compn> by 'we' i mean those people who do the testing :) [18:42] <Compn> not me personally [18:43] <Compn> sometimes people send patches for bug fixes but dont give samples. that maybe a blocker, since all files that touch that code have to be tested to make sure the fix didnt break anything [18:43] <Compn> or maybe i am wrong. [18:44] <Compn> i cant speak for others. [18:44] <Compn> Daemon404 : do you notice how nicely commented the mythtv code is? :) [18:45] <nevcairiel> "// hack starts here" is not nicely commented. :P [18:45] <Daemon404> ffdshow styf [18:45] <Daemon404> style [18:45] <Compn> bah [18:45] <Compn> * HACK! To allow BBC IPTV streams with incomplete PMTs (they [18:45] <Compn> + * advertise a length of 383, but only send 182 bytes!), we [18:45] <Compn> + * will not wait for the remainder of the PMT, but accept just [18:45] <Compn> + * what is in the first TS payload, as this is enough to get [18:45] <Compn> + * playback, although some PIDs may be filtered out as a result [18:46] <nevcairiel> I have a whole load of special hacks in my "fork", but I just use git to keep track and comments [18:46] <nevcairiel> Also, pastebin [18:47] <Compn> thats what i'd like to do is reduce the amount of diffs from the various forks [18:47] <Compn> at least where its easy to agree with the changes [18:47] <nevcairiel> I should go through my patches again some day and send a few [18:47] <Compn> we wont bite. [18:49] <nevcairiel> I should really squash all the patches for my custom mkv demuxer, it would make the history so much shorter [18:49] <nevcairiel> Oh well [19:21] <cone-861> ffmpeg.git 03Ben Hagen 07master:6928ea7eb0fb: cinedec: add shutter and crop metadata [20:07] <cone-861> ffmpeg.git 03Marton Balint 07master:51748b6377ff: mpegts: always parse pcr [20:07] <cone-861> ffmpeg.git 03Michael Niedermayer 07master:3574d34aca9d: Merge remote-tracking branch 'cus/stable' [20:18] <michaelni> anyone has any comments on: " Mohammad Alsale (8.0K) [FFmpeg-devel] [PATCH] avformat/metadata: Implement AVFMT_FLAG_NO_META_CONV" ? [20:19] <michaelni> if not ill apply it [20:21] <wm4> hm I'm neither against not for it, but maybe it would be better to keep the original metadata around in a separate dict? [20:29] <michaelni> wm4, iam fine with either, if you think it should be in a seperate dict, reply to that patch and request that [20:31] <wm4> replied [20:49] <cone-861> ffmpeg.git 03Michael Niedermayer 07master:b7d5e016a3f3: swresample: Add AVFrame based API [22:16] <ubitux> lol @ debian thread where lintian is pointed out to solve "human problems" [22:17] <ubitux> there is a slight misunderstanding here it seems :)) [22:26] <ePirat> Seems that Google is a ffmpeg fan :P http://i.imgur.com/Yanqua0.png [22:28] <kierank> ePirat: why is google using mpeg-ts? [22:28] <ePirat> kierank, for HLS, they use hls for live streams [22:29] <kierank> ah [22:29] <ubitux> why 48k for streaming btw? [22:29] <kierank> because that's what they get the content in [22:29] <ubitux> so just to get free of a resample? [22:29] <kierank> why would they want to resample [22:30] <kierank> 44.1khz is annoying# [22:30] <ubitux> i guess the bw gain between 48k and 44.1 is more than negligible [22:30] <ubitux> kierank: annoying in what sense? [22:30] <kierank> ubitux: difficult to fit within a multiple up 29.97 [22:30] <kierank> in fact very complex [22:31] <kierank> of* [22:32] <ePirat> actually there was a huge rant on twitter, because the stream was lagging all the time& seems the provider of the original stream fucked something up :P [22:32] <ePirat> lagging as in video stops, audio continues [23:27] <cone-861> ffmpeg.git 03Michael Niedermayer 07master:427bcdf035f5: avformat/mpegts: Use differential score for analyze() [00:00] --- Sun Aug 17 2014

1 0

ffmpeg.log.20140816
by burek 17 Aug '14

17 Aug '14

[00:57] <smo_> hi! still searching for my problem :p i have a nodejs http server where i send links of local or online files , i send it to ffmpeg to make live transcoding then pipe the result in my http response, problem i have is that i m unable to get the right duration of the file in my player an idear? [00:58] <smo_> i can get all infos from orginal files i seacrh a way to force writing the duration in the response header or something like that [03:08] <SmallMalePony> Can you help me figure out how to improve the following command so that it forces a fixed bitrate (and picks the value automatically -- this is the important part)? [03:09] <SmallMalePony> ffmpeg.exe -i %1 -q:a 0 -q:v 0 %1.avi [03:09] <SmallMalePony> (This is because if it's variable, Premiere Pro fucks up the audio.) [03:10] <SmallMalePony> (It makes the audio drift which is INSANELY annoying.) [03:43] <relaxed> SmallMalePony: -q = vbr, try ffmpeg.exe -i %1 -b:a 320k -b:v 2M %1.avi [03:44] <SmallMalePony> relaxed: But that's a manually specified one? [03:46] <relaxed> if you only need a fixed bitrate for audio, ffmpeg.exe -i %1 -b:a 320k -q:v 1 %1.avi [03:55] <SmallMalePony> ffmpeg has the weirdest syntax for the command line options. :S [03:55] <SmallMalePony> Will try that. [03:56] <klaxa> i think it's one of the smartest ones i know [03:58] <relaxed> replace -b:a 320k with -c:a pcm_s16le for lossless audio [03:59] <SmallMalePony> What do you mean lossless? [03:59] <SmallMalePony> You mean it will be fixed and lossless? [04:00] <c_14> Constant bitrate lossless, yes. [04:01] <SmallMalePony> What exactly is pcm_s16le? [04:01] <SmallMalePony> You have no idea how much suffering this will save me if it works. :D [04:01] <c_14> Signed 16 bit little endian Pulse-Code-Modulated audio. [04:01] <SmallMalePony> Imagine having 20 cuts in a movie and each one has to have the audio adjusted manually. [04:02] <SmallMalePony> Thanks a lot. I think this will work. [04:04] <relaxed> SmallMalePony: completely lossless, ffmpeg.exe -i %1 -c:a pcm_s16le -c:v rawvideo %1.avi [04:04] <relaxed> expect huge output [04:14] <SmallMalePony> Well, the -q:v is already lossless. [04:15] <SmallMalePony> Unless I am misinformed. [04:15] <SmallMalePony> That is, lossless compared to the source. [04:17] <c_14> -qp 0 is lossless for x264, but not for every encoder [04:19] <SmallMalePony> Then what is -q:v? [04:19] <SmallMalePony> Then what is -q:v 0? [04:19] <SmallMalePony> (Forget the first question, please) [04:22] <relaxed> -q:v is vbr, and "0" isn't even a valid value. The range is from 1 - 31 [04:24] <relaxed> "0" is valid with -q:a but it depends on the external codec. [04:24] <c_14> relaxed: The scale for x264 goes from 0-69 [04:24] <c_14> What codec are you talking about? [04:25] <relaxed> I thought -q:v had nothing to do with libx264. Are you thinking -qp ? [04:25] <relaxed> and the default codec for .avi is mpeg4 [04:26] <c_14> I am, but isn't -q:v aliased to -qp for x264? [04:26] <c_14> It is? I thought almost everything defaulted to x264 these days (if x264 was linked it). [04:27] <relaxed> Yes, I just tested. [04:27] <relaxed> You maybe right about -q:v being aliased to -qp, though. I'm not sure. [04:28] <c_14> Neither am I... [04:33] <troy_s> sine0: Yes. Your pipeline. It ultimately depends on your project, but how you intend to organize the process is key. [04:34] <troy_s> sine0: If you are interested and willing, feel free to hit me via PM and I can probably offer you some pipeline tips. [04:34] <DopeLabs> first you pack it up [04:38] <SmallMalePony> -qp would probably be the code for ordering a quarterpounder cheese from McDonald's if they had an interface. [04:39] <SmallMalePony> That is perhaps the one positive thing about drones. [04:39] <SmallMalePony> They could deliver hamburgers to my window. [04:39] <SmallMalePony> By paying with Bitcoin on the command line. [04:39] <SmallMalePony> But that is also an extremely decadent and sad existence. [04:40] <DopeLabs> post something on craigslist that you will buy someone a happymeal if they deliver you some mc-d's [04:44] <DopeLabs> weee [05:19] <oglop374_xads> hello all, i have a question about compiling ffmpeg with librtmp on centos 7, i'm using this forked build script, https://github.com/oglops/ffmpeg-static which i only added a few lines of downloading librtmp , and add --enable-librtmp to ./configure [05:19] <oglop374_xads> but it doesn't work. the last error message is [05:19] <oglop374_xads> *** Building FFmpeg *** [05:19] <oglop374_xads> ERROR: librtmp not found [05:19] <oglop374_xads> full config.log here: http://pastebin.com/k2wsJzuw [05:27] <DopeLabs> did you install librtmp? [05:32] <oglop374_xads> the "static" build script put all compiled dependency libs in build/lib folder [05:32] <oglop374_xads> i saw librtmp there, and also the pkgconfig folder there. it can "see" all the other libs but not librtmp, don't know why [05:40] <DopeLabs> i might recall running into something similar.. i may have install librtmp-dev and that may have worked [05:40] <DopeLabs> though i cant remember exactly [05:48] <oglop374_xads> but my librtmp is git cloned from git://git.ffmpeg.org/rtmpdump source. and compiled in the build script , it should have included the "librtmp-dev" ( i didn't install librtmp from repo ) [05:49] <DopeLabs> /usr/include/librtmp ? [05:51] <oglop374_xads> in here /home/oglop/Downloads/ffmpeg-static-mine2/target/lib/ [05:52] <oglop374_xads> the build script already set some env vars [05:52] <oglop374_xads> export LDFLAGS="-L${TARGET_DIR}/lib" [05:52] <oglop374_xads> # FIXME: detect OS somehow [05:52] <oglop374_xads> export DYLD_LIBRARY_PATH="${TARGET_DIR}/lib" [05:52] <oglop374_xads> export PKG_CONFIG_PATH="$TARGET_DIR/lib/pkgconfig" [05:52] <oglop374_xads> #export CFLAGS="-I${TARGET_DIR}/include $LDFLAGS -static-libgcc -Wl,-Bstatic -lc" [05:52] <oglop374_xads> export CFLAGS="-I${TARGET_DIR}/include $LDFLAGS" [05:52] <oglop374_xads> export PATH="${TARGET_DIR}/bin:${PATH}" [06:31] <oglop374_xads> what does this line mean TARGET_DIR="${TARGET_DIR:-$ENV_ROOT/target}" [11:33] <BillyZane> hi [11:39] <anshul_mahe> hello [11:40] <anshul_mahe> ask your question,Its often no chat on this irc [11:42] <BillyZane> well [11:42] <BillyZane> i want to stream to twitch or any other video streaming service [11:42] <BillyZane> but what i want to stream is video files [11:43] <BillyZane> an example would be a mkv file with multiple audio files and subtitles [11:49] <anshul_mahe> need more details about twitch, which stream does that server support, rtp http hls etc [11:50] <anshul_mahe> cmd is simple ffmpeg -i <videofile> <pathofserver> [11:56] <DopeLabs> you would use rtmp [11:56] <DopeLabs> if your going to twitch [11:56] <DopeLabs> or whoever you go with [11:57] <DopeLabs> im sure they have a recommended encoder settings page somewhere [12:04] <BillyZane> i believe it uses rtmp [12:04] <BillyZane> it authenticates using a username and a key [12:04] <BillyZane> *stream key [12:04] <DopeLabs> ustream doesnt and twitch doesnt [12:05] <DopeLabs> its just a rtmp://live.twitch.tv/secret/stuff [12:52] <oglop374_xads> pkg-config --exists librtmp shows librtmp exists ... but still can not find it [12:55] <relaxed> oglop374_xads: I bet it will work if you don't try to compile ffmpeg statically. [12:57] <relaxed> oglop374_xads: wait, try adding --pkg-config-flags="--static" [13:08] <oglop374_xads> i tried manually copy librtmp.so to /usr/lib64, it works ... [13:08] <oglop374_xads> thanks i'll try that. because i have no root permission at office. and i want to copy my compiled ffmpeg to other machine, that's why i was trying to build it statically. [13:15] <oglop374_xads> relaxed: where do i add --pkg-config-flags="--static" ? [14:02] <relaxed> oglop374_xads: ffmpeg's ./configure [14:07] <oglop374_xads> the build script hard coded download links for ffmpeg and libraries. previously it was using ffmpeg2.1.4, and it doesn't have that flag in ./configure. i'm trying updating all of them to latest. right now trying ffmpeg 2.3.2 [14:26] <oglop374_xads> relaxed: tried adding that flag, the error is Unknown option -static [14:26] <oglop374_xads> Unknown option -static [14:26] <oglop374_xads> ERROR: opus not found [14:28] <relaxed> you need two -- [15:09] <oglop374_xads> relaxed: still the same error ERROR: librtmp not found [17:22] <oglop374_xads> relaxed: this post seems solved my problem http://stackoverflow.com/questions/9634496/building-ffmpeg-with-librtmp-for… [17:33] <bbbruce> I am using ffmpeg -f rawvideo -s 640x480 -pixfmt bgr32 -r 25 -i - -an output.mp4 from inside a java program to create video. I write images to the outputstream (ffmpegs stdin) until I am done, then I close the stream. This works for sequences with around 1000 images. With larger sequences it looks like ffmpeg never terminates and fails to produce a playable mp4 file. Is there anything I can do to fix this? [17:36] <bbbruce> I use ffmpeg 2.3.2 on OSX 10.9 [18:58] <Wonka> g'day [18:58] <Wonka> I have an mpegts file here which contains a video stream and an audio stream. [18:58] <Wonka> ffmpeg doesn't recognize the audio stream [18:59] <Wonka> I know it is SMPTE 302M. [18:59] <spaam> what does ffmpeg -i say? [19:00] <spaam> and what version are you using? :) [19:00] <Wonka> output of "ffmpeg -i miracast.ts" piped to file: http://chaos.in-kiel.de/~w/tmp/ffmpeg-i.log [19:01] <Wonka> "ffmpeg version 2.3.1" it says [19:01] <Wonka> »ffplay -f lavfi 'movie=miracast.ts:s=#0x1011'« works fine to play the video part [19:02] <spaam> looking at Changelog, ffmpeg added support for that codec in version 0.8 so it should work in 2.3.1 [19:03] <Wonka> yeah, it just doesn't seem to recognize the stream as audio and/or s302m [19:03] <Wonka> Stream #0:1[0x1100]: Unknown: none ([131][0][0][0] / 0x0083) [19:03] <Wonka> which I don't really wonder about, as 0x83 is "private data" [19:04] <Wonka> I'm more-or-less just looking for a way to override the (failing) stream type detection [19:05] <Wonka> »ffplay -f lavfi 'amovie=miracast.ts:s=#0x1100'« fails: »[Parsed_amovie_0 @ 0x7f5e74002680] Stream specifier "#0x1100" matched a (null) stream,currently unsupported by libavfilter« [19:09] <spaam> if you can share the file. make a bug ticket and attach the file so they can fix the issue :) [19:11] <c_14> Wonka: you can try and override the detection ffmpeg -c:a s302m -i file [19:11] <c_14> s/detection/detection: [19:12] <spaam> c_14: can you do that even if ffmpeg say the other stream is Unknown? didnt know that:) [19:12] <Wonka> c_14: doesn't work, it doesn't find any audio stream to apply that to [19:13] <c_14> spaam, Wonka: it only works sometimes, but it was worth a shot [19:14] <Wonka> »ffmpeg -c:0:1 s302m -i file« errors »Invalid decoder type 's302m'« [19:14] <Wonka> not "Unknown decoder", but "Invalid". [19:14] <c_14> does ffmpeg -decoders list s302m for you? [19:15] <Wonka> yes [19:16] <c_14> Do you have any other player/decoder/whatever that can play the file? [19:16] <c_14> If yes, it's probably time for that bug report. If not, it might be corrupt. [19:17] <Wonka> well... I do have a Rasperry Pi with a Wifi stick, and the code from https://github.com/codemonkeyricky/piracast/ [19:18] <Wonka> I can stream Audio+Video from my mobile to the RasPi's HDMI output with that [19:18] <Wonka> works fine. [19:18] <Wonka> I can capture the data, and replay it to the same software. [19:19] <c_14> So that piracast thingy can play it? [19:19] <Wonka> I can extract the mpegts from the captured data [19:19] <Wonka> yes [19:19] <Wonka> it uses the RPi's video HW though [19:20] <Wonka> parts are done in some blackbox there, and I can't capture the output there [19:20] <Wonka> but I am quite well sure the data is not corrupted [19:20] <c_14> I'd open a bug report on trac with a sample of the file. [19:22] <Wonka> mmh... will see. currently trying gstreamer with libav.... [19:24] <spaam> :D [21:14] <Baked_Cake> i just learned how to -tune animation / -tune film [21:14] <Baked_Cake> kinda excited to see the results on animation [21:44] <DopeLabs> i use -tune stillimage alot when rendering image seq's [21:55] <differentnick> when seeking with -ss before -i (and only -ss before -i), sometimes (depending mostly on codec I think) the output will be glitchy for the first few seconds, until it comes across a keyframe in the input. Is there any argument that fixes this within ffmpeg other than -ss seeking "close" to where you want to start before -i then seeking the rest of the way after -i? [00:00] --- Sun Aug 17 2014

1 0

ffmpeg-devel.log.20140815
by burek 16 Aug '14

16 Aug '14

[00:37] <kierank> 10:05 PM <"Daemon404> >making the user manually call emms [00:37] <kierank> I disagree [00:37] <kierank> as long as it's documented then it's ok [00:37] <kierank> (assuming the speed difference is not negliglbe) [00:40] <jamrial> making emms_c() public makes no sense. there's an intrinsic for that in every c library [00:41] <jamrial> emms_c() in fact calls that intrinsic if there's no inline asm support [02:27] <cone-268> ffmpeg.git 03John Stebbins 07master:998c9f15d1ca: idct: remove call to ff_idctdsp_init from ff_MPV_common_init [02:27] <cone-268> ffmpeg.git 03Michael Niedermayer 07master:2fd87a3d7895: Merge commit '998c9f15d1ca8c7489775ebcca51623b915988f1' [02:42] <cone-268> ffmpeg.git 03John Stebbins 07master:b869eea7ea8f: h263dec: Fix order of initialization [02:42] <cone-268> ffmpeg.git 03Michael Niedermayer 07master:012062cfd51f: Merge commit 'b869eea7ea8f5d8331fcd6355f848bb6a6e06b14' [03:10] <cone-268> ffmpeg.git 03John Stebbins 07master:552bc42df487: h261dec: Fix order of initialization [03:10] <cone-268> ffmpeg.git 03Michael Niedermayer 07master:595c63357cdc: Merge commit '552bc42df48784ae3ce0d499ece5b33f3cc7576a' [03:10] <cone-268> ffmpeg.git 03Michael Niedermayer 07master:6c1ee1a11446: avcodec/h261dec: Fix context initialization sequence [05:51] <cone-268> ffmpeg.git 03Christophe Gisquet 07master:33fefdb44992: ffmpeg: fix streamcopy with side data [05:51] <cone-268> ffmpeg.git 03Michael Niedermayer 07master:d3a22491c736: ffmpeg: remove 32 channel limit from audio_channels_map [07:52] <ubitux> wm4: yes, the bump adopted the new behaviour [08:03] <ubitux> i'll probably mention it in the behaviour changes section in the release notes [08:15] <nevcairiel> It changed codec Id right? [08:15] <ubitux> yes [08:15] <nevcairiel> Then I hopefully handle that already [10:38] <durandal_1707> why is now important to have signed off patches??? [10:46] <nevcairiel> i never understood why you would sign-off your own patches specifically, obviously you signed it off, since you're the author :D [12:29] <cone-574> ffmpeg.git 03Diego Biurrun 07master:7ccb847f0f1f: http: Reduce scope of a variable in parse_content_encoding() [12:30] <cone-574> ffmpeg.git 03Michael Niedermayer 07master:1e81b185ae72: Merge commit '7ccb847f0f1f28199fa254847b91b6e50fb92832' [12:38] <cone-574> ffmpeg.git 03Diego Biurrun 07master:6baeadd11083: w32pthreads: Mark functions in compatibility wrapper as av_unused [12:38] <cone-574> ffmpeg.git 03Michael Niedermayer 07master:6afd726b7b27: Merge commit '6baeadd11083774ebd823dd5e1a744c2150a3bfc' [12:45] <cone-574> ffmpeg.git 03Diego Biurrun 07master:7c371754fbc0: atomic_win32: Drop unnecessary atomic.h #include [12:45] <cone-574> ffmpeg.git 03Michael Niedermayer 07master:edd0dc854d45: Merge commit '7c371754fbc0dcc23bd00278b147f8095ccc5625' [14:48] <ubitux> http://www.iquilezles.org/blog/?p=2892 [14:49] <J_Darnley> Interesting. [14:49] Action: J_Darnley goes to find a calculator [14:50] <J_Darnley> Wow it does work [14:50] <ubitux> this guy drives me crazy every time [14:51] <ubitux> (https://www.shadertoy.com/view/ldXXDj) [15:09] <kierank> 48khz ftw [15:39] <henry0312> hello, developers. [15:39] <henry0312> please see http://git.videolan.org/gitweb.cgi/vlc.git/?a=commit;h=97c02be6f591c0f3ef93…. [15:40] <henry0312> I'd love to make ffmpeg support ARIB subtitles, which are defined in http://www.arib.or.jp/english/html/overview/doc/6-STD-B24v5_2-1p3-E1.pdf [15:40] <wm4> ubitux: ^ [15:40] <henry0312> and the vlc commit use https://github.com/nkoriyama/aribb24 [15:41] <nevcairiel> ffmpeg doesn't really do external subtitle rendering libs [15:41] <wm4> nevcairiel: like libass? [15:41] <nevcairiel> its certainly not part of any subtitle decoder, and its lavfi integration is questinonable [15:41] <nevcairiel> -n [15:42] <ubitux> i saw mention of PNG in the specs and thus closed the pdf in fear [15:42] <wm4> so do you not believe this belongs into libavcodec? [15:42] <ubitux> just re-opened it and saw GIF [15:43] <ubitux> that's actually probably unrelated to the subs [15:44] <henry0312> hm [15:44] <ubitux> henry0312: do you wish to add native support or through an external lib? [15:46] <henry0312> ubitux: I want to use aribb24 (https://github.com/nkoriyama/aribb24) if possible. Can I do this? [15:47] <ubitux> i guess, even though a native support is often preferred [15:48] <henry0312> The problem of adding native support is that I don't know much about ARIB STD-B24... [15:49] <wm4> I don't see a single reason why we should NIH something this complicated and obscure [15:49] <nevcairiel> ubitux: how would you ever add an external subtitle decoder? make it output bitmaps and pretend its a bitmap subtitle format? :d [15:50] <ubitux> nevcairiel: yes? [15:50] <nevcairiel> but it would be the first time, we never did that before, afaik [15:50] <nevcairiel> all other text things just massage the output to look like ass [15:51] <ubitux> i assumed it wasn't text subtitles but bitmaps [15:51] <ubitux> maybe that's more like teletext [15:52] <ubitux> wm4: ffmpeg isn't a lib web, it's supposed to provide decoders for audio, video and subtitles natively& [15:53] <nevcairiel> anyway, here, run in fear: [15:53] <nevcairiel> STD B24 specification is derived from an early draft of XHTML 1.0 strict, which it extends and alters. Some subset of CSS 1 and 2 is supported, as well as ECMAScript. [15:53] <ubitux> aaaah [15:53] <nevcairiel> it has the interesting name of Broadcast Markup Language [15:53] Action: ubitux will stay away from this [15:54] <J_Darnley> WTF? javascript in subtitles? [15:54] <nevcairiel> its probably meant to be more than subtitles to some degree [15:54] <ubitux> henry0312: we typically have support for libzvbi, so it's probably possible to have support for that aribb24 [15:56] <henry0312> hum [15:57] <henry0312> ubitux: so, first, do I have to understand libavformat/mpegts.c? [15:57] <ubitux> i have no idea [15:58] <wm4> henry0312: you need to find out whether mpegts can already extract the raw captions [15:58] <ubitux> look at what aribb24 takes in input and what it outputs [15:59] <henry0312> wm4: i see. [15:59] <henry0312> ubitux: i see. [16:03] <ubitux> the decoder doesn't actually look like much work [16:05] <ubitux> but you actually have some png shit in it [16:12] <wm4> does the arib lib take care of the png? [16:12] <wm4> how did vlc implement this? [16:16] <Daemon404> probably as usual [16:16] <Daemon404> adding more deps [16:16] <henry0312> I think aribb24 gets subtitles as text. [16:16] <henry0312> http://git.videolan.org/gitweb.cgi/vlc.git/?p=vlc.git;a=blob;f=modules/code… [16:17] <henry0312> and see around l.239 [16:19] <wm4> looks like the arib lib does all the hard work [16:19] <henry0312> yes. [16:22] <ubitux> arib lib has a libpng dep [16:26] <henry0312> wm4: so I think, if we can extract correct packets in ffmpeg, we could support it [16:26] <henry0312> yes, the lib need libpng. [16:26] <wm4> there's another problem: what does the lib output at all? and can the ffmpeg API handle it? [16:36] <henry0312> what does the lib output at all? <= I think we have to run arib_decode_buffer (https://github.com/nkoriyama/aribb24/blob/master/src/aribb24/decoder.h#L71-…) [16:36] <henry0312> can the ffmpeg API handle it? <= I don't know, yet. [16:37] <wm4> is the arib API documented somewhere? [16:38] <henry0312> no, it doesn't have any documents. [16:38] <henry0312> but the author is Japanese, so I could contact him. [16:39] <wm4> it's not clear at all what all these fields mean [16:39] <wm4> I'd guess p_start and p_end point to UTF-8 text? [16:39] <wm4> but it also must be able to export bitmaps... [16:41] <ubitux> if they can be png, then they will need to be downscaled to 256 colors iirc [16:42] <ubitux> which brings the discussion about the current limitation of AVSubtitles graphics [16:42] <wm4> just add a pixelformat field? [16:43] <ubitux> what will be the difference between and AVFrame and a bitmap AVSubtitles? [16:43] <ubitux> AVSubtitles will be a collection of AVFrames? [16:43] <ubitux> AVFrame *rects[]? [16:45] <wm4> x, y, nb_colors, type, text, ass, flags [16:47] <ubitux> mmh yeah, x/y [16:52] <wm4> and all the other fields [16:53] <ubitux> for bitmap subs none of the other matters for rects [16:53] <wm4> with paletted ones, it's especially annoying that you don't know whether sub rects share the palette [16:53] <wm4> because if they do, some renderers might be much simpler [17:57] <henry0312> Hum... probably, I have to read the spec to understand aribb24 and think how to render, how to use in ffmpeg and something. [17:58] <henry0312> wm4, ubitux: I'll talk with you again later, thanks! [18:01] <henry0312> wm4: btw, ffmpeg doesn't seem to recognize ARIB subtitles for now (btw, though MediaInfo can recognize them) [18:09] <wm4> henry0312: it's probably the matter of adding a codec id [18:15] <henry0312> should I add add a codec id for them to `static const StreamType ISO_types[]`? [18:16] <wm4> probably, I don't know which is the correct place (there are many codec id arrays in mpegts.c...) [18:17] <henry0312> yeah. I'll try. [18:19] <kierank> henry0312: what kind of identifier does it have [18:19] <kierank> there are many ways of signaling packets in mpegts [19:18] <henry0312> kierank: as far as I see his patch for vlc's demuxer for ts, http://privatepaste.com/cf68d77f7f, I think the stream_type is 0x06 [19:19] <henry0312> (also you can get the same patch from https://onedrive.live.com/?cid=2dab0d8d07fa4ebf&id=2DAB0D8D07FA4EBF%21856) [19:20] <wm4> the second links is the worst way to post a patch I've ever seen [19:22] <henry0312> it's OneDriver of the author of aribb24 [19:22] <henry0312> *OneDrive [19:24] <wm4> then the worst way of hosting code [19:25] <ubitux> just after sharing it in a docx document [19:26] <JEEB> hey, that's at least xml in a zip [19:26] <JEEB> rather ye olde doc [19:26] <JEEB> which is binary [19:27] <henry0312> (I also wonder why he doesn't use gist or something to host codes) [19:27] <wm4> seems like he has a github repo [19:27] <wm4> so that's ok [19:30] <kierank> wm4: there was one guy that sent an html diff [19:31] <wm4> the open scene graph project doesn't even accept patches, you just to post full files in a zip attachment [19:31] <wm4> s/just/must [19:33] <ubitux> osg is really insane yeah [19:35] <ubitux> "Do not send diffs or copy and paste extracts in emails, these will be simply disgarded, as they are too unreliable for review and merging." [19:36] <JEEB> lolwut [19:36] <ubitux> http://www.openscenegraph.org/index.php/support/faq#HowcanIcontributetotheO… [19:36] <wm4> I looked at the ML, they really do this [19:36] <ubitux> " [19:36] <ubitux> "Patches or email copy and paste submissions are not accepted and will be ignored until full files are submitted. " [19:37] <henry0312> lol [19:38] <ubitux> random funny stuff: [19:38] <ubitux> https://github.com/openscenegraph/osg/blob/master/configure [19:38] <ubitux> https://github.com/openscenegraph/osg/commit/5e904fd62ce7402c53a377133a64b7… [19:39] <wm4> wat [19:39] <ubitux> anyway, i'm actually really surprised it hasn't been forked yet [19:39] <wm4> it has a fork count of 130 [19:39] <wm4> (lol github) [19:40] <ubitux> personnal trees [19:40] <wm4> yeah, the "lol" is for the fact that github blurs the line between actual fork and personal trees [19:41] <nevcairiel> Technically that's called a fork in git lingo [19:42] <ubitux> "howto make project management worse than on a doom9 forum thread" [19:44] <ubitux> https://github.com/openscenegraph/osg/blob/master/CMakeModules/FindFFmpeg.c… [19:44] <ubitux> this makes me really sad [19:44] <ubitux> but i guess that's more related to the cmake insanity [19:45] <wm4> ubitux: ugh that's pretty bad [19:45] <J_Darnley> Is that typical use of cmake? [19:45] <ubitux> that's actually pretty typical yes [19:45] <ubitux> there are about 5k lines of cmake finders in that directory [19:45] <ubitux> trying all the most stupid possible paths [19:45] <ubitux> and expect it to find the libs there [19:46] <ubitux> there is even a FindZLIB [19:47] <ubitux> https://github.com/openscenegraph/osg/blob/master/CMakeModules/FindOpenThre… [19:47] <ubitux> what about this one? [19:48] <wm4> just wth is that [19:48] <ubitux> :) [19:49] <ubitux> there are a lot of other things in this project you don't want to see [19:50] <ubitux> i initially though i was going to update the ffmpeg stack so it can work with recent versions [19:50] <ubitux> but do you really think i'll be able to submit changes? [19:51] <ubitux> i submit a 4-lines patches a while ago (with both inline diff and the file as attachement in the mail) for something random [19:51] <ubitux> i'm not sure if that's ever going to make it [19:58] <cone-14> ffmpeg.git 03Diego Biurrun 07master:a6a27fede94e: vfwcap: Replace deprecated av_destruct_packet() by av_free_packet() [19:58] <cone-14> ffmpeg.git 03Michael Niedermayer 07master:3eba0a91905f: Merge commit 'a6a27fede94efe48aad1dcc9d5e000d2de71c7b2' [19:58] <cone-14> ffmpeg.git 03Andrey Myznikov 07master:609d5db8035c: Fix packet_buffer memory leak in avformat_free_context [19:58] <cone-14> ffmpeg.git 03Michael Niedermayer 07master:9c712d0b1608: vformat/utils: call flush_packet_queue() from avformat_free_context() [19:59] <ubitux> https://github.com/openscenegraph/osg/blob/master/src/osgDB/ImagePager.cpp#… how to deal with threading issues [19:59] <ubitux> a bit more unstable without the #if 0 ;) [19:59] <wm4> starting threads from a ctor is not sane [20:00] <wm4> OpenThreads::Thread::YieldCurrentThread(); [20:00] <wm4> oh ho [20:00] <wm4> who needs condition vars? [20:01] <ubitux> anyway, the project is something like 500.000 lines of code, it's still a mystery how this can be manageable [20:12] <henry0312> wm4: https://gist.github.com/henry0312/dce50d7abdac2cad04a7 [20:13] <henry0312> I added codec id. [20:13] <kierank> i am not 100% sure that is correct [20:13] <kierank> but will need to check [20:13] <henry0312> thanks! [20:14] <wm4> henry0312: you also need to change a bunch of other places when adding a new codecid [20:14] <wm4> at least an entry to libavcodec/codec_desc.c needs to be added [20:14] <henry0312> ok. [20:15] <henry0312> btw, if you (also including other developers) need a sample, let me know. [20:24] <cone-14> ffmpeg.git 03Diego Biurrun 07master:835f798c7d20: mpegvideo: cosmetics: Lowercase ugly uppercase MPV_ function name prefixes [20:24] <cone-14> ffmpeg.git 03Michael Niedermayer 07master:c1df467d73ee: Merge commit '835f798c7d20bca89eb4f3593846251ad0d84e4b' [20:27] <JEEB> lol, I still have the herp.ts that was the test file for spiegel's ARIB captions thingy [20:29] <henry0312> :D [20:30] <JEEB> Start time : UTC 2011-04-15 01:45:57 [20:30] <JEEB> not old at all by now :V [20:30] <ubitux> henry0312: please add a MKBETAG() if you're adding a codec id [20:31] <JEEB> goddamnit visual studio [20:31] <JEEB> > dot-ts [20:31] <JEEB> > typescript [20:31] <JEEB> thank you for hijacking my extension [20:32] <wm4> henry0312: there's a sample FTP [20:32] <wm4> uh what was it [20:32] <wm4> there's this, but last time it didn't work: http://upload.ffmpeg.org/upload/ [20:33] <wm4> also not quite appropriate for ffmpeg, because it wants a VLC version... [20:33] <henry0312> :e avcode.h [20:33] <henry0312> ops, wrong window [20:33] <cone-14> ffmpeg.git 03Diego Biurrun 07master:efd26bedec9a: build: Add explanatory comments to (optimization) blocks in the Makefiles [20:33] <cone-14> ffmpeg.git 03Michael Niedermayer 07master:3bb22973518c: Merge commit 'efd26bedec9a345a5960dbfcbaec888418f2d4e6' [20:34] <JEEB> ahaha [20:34] <JEEB> chiba tv umineko OP [20:34] <JEEB> this awesome rainbowing [20:34] <JEEB> no idea why I kept this shit [20:34] <henry0312> ubitux: can I set a tag I like? [20:35] Action: JEEB is having fun looking through *.ts files on his drives [20:35] <wm4> henry0312: yeah, these tags are pretty random (IMO a stupid practice) [20:35] <henry0312> ok. [20:35] <JEEB> oh, this was 2009 [20:35] <wm4> just make sure it doesn't collide with anything [20:35] <JEEB> lörs lärä [20:36] <ubitux> henry0312: yes, but MKBETAG('A','R','I','B') is more likely to be accepted than MKBETAG('H','N','R','Y') [20:36] <henry0312> ok! :D [20:37] <JEEB> man, I'm happy we don't have this kind of shit on Japanese DTV any more [20:45] <ubitux> saste: ping [20:45] <saste> ubitux, pong [20:45] <ubitux> saste: what was the plan for option clashes? [20:46] <alexfu> is there documentation on the code somewhere? kind of like a javadoc [20:46] <saste> ubitux, nothing was done I think [20:46] <saste> my idea was to use some sort of namespace [20:46] <ubitux> alexfu: http://ffmpeg.org/documentation.html look for doxygen [20:47] <ubitux> saste: ok, because we currently have a clash between a decoder and a protocol [20:47] <alexfu> ubitux: thanks [20:47] <saste> ubitux, what in particular? [20:47] <ubitux> saste: -password, tta/icecast [20:47] <saste> anyway such conflicts are nasty but can be avoided using a prefix in the option [20:49] <alexfu> if resizing a video results in something like this: http://i.imgur.com/fjk25eo.png -- what does that usually indicate? [20:49] <ubitux> wrong linesize step? [20:49] <wm4> alexfu: wrong stride [20:50] <wm4> also called linesize [20:51] <wm4> what you need to be careful about is that there can be padding between the end of the last pixel of a line, and the start of the first pixel of the next line [20:52] <alexfu> wm4: maybe i'm missing something, but how can scaling effect that? [20:54] <ubitux> saste: changing the option name can be done; icecast is recent but is present in the fork so changing the option name means incompatibility. OTOH tta is more ancient and ffmpeg exclusive, but chaning the option name is more problematic then from a compat PoV [20:54] <ubitux> that's why i was wondering if another way wasn't possible [20:55] <wm4> alexfu: the scaler needs it to access the pixels [21:09] <ubitux> michaelni: it seems the issue can simply be fixed by doing the same as 8a1714ad85dd5defdf1fb2baba9ababebfa47d01 for encoding [21:10] <cone-14> ffmpeg.git 03Gabriel Dume 07master:f929ab0569ff: cosmetics: Write NULL pointer equality checks more compactly [21:10] <cone-14> ffmpeg.git 03Michael Niedermayer 07master:fb33bff990a8: Merge commit 'f929ab0569ff31ed5a59b0b0adb7ce09df3fca39' [21:25] <alexfu> wm4: so when that happens, does that mean the linsize is too small? [21:27] <wm4> it means different parts of the code didn't use the same linesize, which probably means some code didn't pass it along correctly [21:36] <JEEB> ah, nice. found a sample that has colors, positioning... let's see if we get pictures too [21:45] <JEEB> ok, pictures too :D [21:54] <cone-14> ffmpeg.git 03Gabriel Dume 07master:4b1f5e5090ab: cosmetics: Write NULL pointer inequality checks more compactly [21:54] <cone-14> ffmpeg.git 03Michael Niedermayer 07master:60dbed606767: Merge commit '4b1f5e5090abed6c618c8ba380cd7d28d140f867' [21:55] <wm4> JEEB: so you found The EVIL? [21:58] <JEEB> https://dl.dropboxusercontent.com/u/175558/screenshots/tvtest_caption_gaiji… too bad I don't have this around any more. Liked the TV symbol [21:58] <alexfu> anyone mind taking a lookg @ this? https://gist.github.com/alexfu/7702fbf7d9617266d99d .. when resizing the video, i get incorrect linesizes but I cant figure out why from the code. [22:03] <JEEB> oh right, goddamnit [22:03] <JEEB> ruby text [22:05] <JEEB> funky [22:05] <JEEB> another sample I opened has those [22:05] <JEEB> time to cut something [22:08] <JEEB> wish I could see the byte-wise position of frames :| [22:21] <wm4> JEEB: AVPacket has a pos field or so, is that what you want? [22:22] <JEEB> could be useful, although I'm right now already almost finished with cutting the sample [22:22] <wm4> alexfu: don't use avpicture_, and especially not with AVFrame... that's 100% broken [22:22] <wm4> where do people get the idea to alias AVPicture with AVFrame [22:22] <wm4> must be from old tutorials when it was still valid... [22:22] <wm4> jesus fuck [22:23] <JEEB> lol [22:25] <wm4> alexfu: I think your problem is memcpy(windowBuffer.bits, buffer, width * height * 4); [22:25] <wm4> this assumes linesize == width * 4 [22:25] <wm4> but it doesn't have to be [22:25] <alexfu> wm4: ah, ok [22:25] <JEEB> dd if=201307130225000103-KéÜ [22:25] <JEEB> dd for the win [22:28] <JEEB> http://fushizen.eu/samples/arib_captions_colors_positioning_ruby_subpics.ts [22:28] <JEEB> enjoy [22:29] <wm4> I'll come back to it once henry0312 gets further [22:29] <JEEB> I wonder how well VLC handles it [22:29] <JEEB> j-b, do the current nightlies have support for ARIB captions already? [22:38] <j-b> JEEB: no [22:38] <JEEB> aww [22:40] <wm4> everyone wants ARIB captions! [22:40] <j-b> really? [22:41] <Compnn> i remember a lot of requests for ARIB support [22:42] <j-b> like 2? [22:43] <Compnn> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2009-October/062725.html [22:43] <Compnn> someone spent the time to include it in mplayer :P [22:44] <JEEB> yeah, I remember there being some derpy patch around [22:44] <JEEB> also there's spiegel's parser [22:44] <wm4> Compnn: I wonder why that patch was not accepted [22:45] <Compnn> it wasnt ? ... probably needs to be resent [22:45] <j-b> because to support ARIB, there are many tweaks to do [22:45] <kierank> http://www.arib.or.jp/english/html/overview/img/arib_std-b24v4.0_e.pdf [22:45] <kierank> I thought this was the spec [22:45] <kierank> it's the TABLE OF CONTENTS for the spec... [22:46] <j-b> non-standard iconv conversion, unstandard TS muxing, support of rubys-and-quarter-pixels [22:46] <wm4> kierank: oh god, and it's 40 pages [22:46] <JEEB> B-24 consists of like 3 books now [22:46] <JEEB> even the Japanese lulz at it [22:47] <JEEB> "I used to have this printed as a single booklet" [22:47] <j-b> JEEB: so, it's in the VLC NB [22:47] <j-b> JEEB: but, you need to compile your own, to get the decoder. :) [22:47] <j-b> JEEB: the code is merged, mostly [22:47] <JEEB> ok [22:48] <j-b> but the Win32 NB does not have the arib24 .so [22:50] <cone-14> ffmpeg.git 03Michael Niedermayer 07master:81a663f49edd: Drop remaining unneeded != NULL [22:52] <j-b> JEEB: what OS are you on? [22:53] <JEEB> j-b, win [23:36] <J_Darnley> jamrial: thanks your your comment on my XOP patch, I had completely forgotten that they are "legacy SSE instructions" [23:36] <J_Darnley> I didn't mean that you should register for an account just to make that comment though. [23:48] <jamrial> J_Darnley: they are not "legacy sse". They use the avx VEX coding scheme [23:49] <jamrial> it's just that vpmacsdd can't read from unaligned memory just like pmulld can't [23:50] <jamrial> so you need to use movdqu, be it sse4 or xop [23:52] <jamrial> J_Darnley: same thing with your avx2 patch [23:56] <cone-14> ffmpeg.git 03Clément BSsch 07master:11aab8d6cb3b: ffmpeg: look for encoding options in both avcodec and avformat [00:00] --- Sat Aug 16 2014

1 0

ffmpeg.log.20140815
by burek 16 Aug '14

16 Aug '14

[01:58] <micechal_> hi [01:59] <micechal_> would anyone be so kind to give me a little help on compilling ffmpeg on windows with msys? [01:59] <micechal_> I saw this: https://trac.ffmpeg.org/wiki/CompilationGuide/MinGW [01:59] <micechal_> but it really doesn't say much to me [02:00] <micechal_> I'd like to build ffmpeg shared with libfdk_aac [02:00] <micechal_> so I get libavcodec-54.dll [02:14] <micechal_> ./configure --enable-libfdk_aac --enable-shared [02:14] <micechal_> would this be enough? [02:17] <wonder88> hello [02:55] <jrgill> I'm working to optimize some options set by Avanti; given curves with one point per channel, would you consolidate this into eq2? I'm getting a warning about some changes pending for eq2 so please offer any tips in terms of compatibility with future builds (this is part of a script). [10:54] <nicoit> how can i determine the pixel format of my video? [10:55] <nicoit> using ffmpeg.exe [11:24] <relaxed> nicoit: pastebin the output of ffmpeg -i yourvideo [11:35] <nicoit> relaxed: http://pastebin.com/mVvhN9AB [11:39] <relaxed> nicoit: it's yuv420p, look at the line starting with "stream #0:1" [11:41] <nicoit> thank you [11:45] <nicoit> please, look at this answer [11:45] <nicoit> http://stackoverflow.com/questions/5985273/using-ffmpeg-hwaccel-from-c [11:45] <nicoit> Is there any method convert pixel format to AV_PIX_FMT_DXVA2_VLD? I want decode video using dxva2. [12:03] <IamTrying> On a Macbook Air, how can i capture the default camera and record it using ffmpeg? [12:04] <relaxed> which OS? [12:04] <IamTrying> relaxed: OSX 10.9.4 (MacBook Air i have) [12:04] <relaxed> https://trac.ffmpeg.org/wiki/Capture/Webcam [12:07] <IamTrying> http://paste.ubuntu.com/8052521/ - i am getting this in OSX 10.9.4 when i executed ffmpeg, relaxed [12:09] <relaxed> did you try, ffmpeg -f avfoundation -i "default" out.mpg [12:10] <IamTrying> YES - that is not working relaxed [12:10] <IamTrying> Unknown input format: 'avfoundation' [12:13] <relaxed> Do you have the latest XCode installed? [12:13] <IamTrying> YES - relaxed [12:13] <relaxed> I don't need your caps [12:14] <IamTrying> relaxed: when i tried get-launch-0.10 -v autovideosrc ! autovideosink that also fails [12:14] <IamTrying> but when i use Mac built in PhotoBooth that capture camera well. ffmpeg and gst both seems failing [12:16] <relaxed> The latest release is 2.3.2, so try that or the latest from git. [12:16] <IamTrying> OK - relaxed [15:27] <jleclanche> I have a broken mp4 file (ffmpeg crashed while recording and now getting "moov atom not found"). Tried various tools to repair it (including a windows closed source one which was able to recover the first 2 seconds of it)... This is what AtomicParsley reports: http://dpaste.com/3QYEWR6 [15:28] <jleclanche> any idea how to repair it? [15:30] <c_14> Short answer, you can't. [15:31] <c_14> "a normal MOV/MP4 is undecodable if it is not properly finished" [15:32] <DopeLabs> i have kinda wondered about this as well.. its kind of a shitty problem [15:33] <DopeLabs> i mean.. there are livestreams of the same type that dont really have an 'end' [15:33] <c_14> Those livestreams have the moov atom stored at the beginning. [15:33] <c_14> The problem is that the moov atom is only generated once the entire file has finished encoding and without the moov atom it is almost impossible to decode the file. [15:34] <c_14> You can try and "bypass" this by fragmenting the moov atom. [15:34] <c_14> But the issue is a defect in the mp4 specs and not in FFmpeg. [15:34] <c_14> "defect" [15:35] <DopeLabs> it seems it would make sense that if the static file is broken to try and force it to be handled like a livestream... which could never include an end [15:35] <c_14> Most livestreams are hls [15:36] <c_14> That is encoded in numerous fixed-length files. [15:36] <c_14> The others use fragmentation afaik. [15:36] <DopeLabs> so is that not an option to fix said files (frag)? [15:37] <c_14> That only works if you specify it _while_ you're encoding. Once the encoding is broken you cannot (in most cases) fix the mp4 file. [15:37] <Bombo> what's in the moov atom anyways? just info about the used format? length? if one coud record a new file WITH a moov atom and the same settings, can't we reuse that? [15:38] <DopeLabs> i have seen cases where people would try and use moov atom info from a similar file [15:38] <DopeLabs> with various degrees of sucess [15:39] <c_14> "The moov atom, also referred to as the movie atom, defines the timescale, duration, display characteristics of the movie, as well as subatoms containing information for each track in the movie. " [15:40] <DopeLabs> if one already knows that info before hand, there ought to be a way to just write a new one, and just specify all the peramiters [15:42] <jleclanche> c_14: I don't need to get a perfect file out of it, just best guessts [15:42] <jleclanche> guesses* [15:42] <jleclanche> c_14: you mentioned fragmenting the moov atom, how? [15:43] <DopeLabs> you want HLS fragmentors [15:43] <jleclanche> did you mean while recording? just looking for some data salvaging solutions [15:43] <c_14> https://ffmpeg.org/ffmpeg-formats.html#mov_002c-mp4_002c-ismv [15:43] <c_14> While recording, yes. [15:43] <jleclanche> right, that doesnt help me - trying to just salvage the one file [15:44] <phelps> heh, I got streaming from my PS4 to my PC working, through the Twitch app [15:44] <jleclanche> untrunc was able to salvag eall the audio properly after some tweaking [15:45] <phelps> now I can archive all my gameplay in a sane manner using ffmpeg [15:46] <c_14> jleclanche: there are hacks that _might_ recover some of the data from the file, but I don't know any of them because I try to stay as far away fromp4 as possible, and it'd probably be easier to just reencode the source [15:46] <jleclanche> c_14: there is no source, this is a direct webcast recording [15:47] <DopeLabs> yea i have a ~20G mp4 thats broken sitting around until a good solution to this same problem arrises [15:48] <DopeLabs> phelps: doesnt twitch allow recording? [15:48] <phelps> DopeLabs: I'm using NAT redirection to send it to a local nginx running the nginx-rtmp-module [15:48] <phelps> so the stream never hits Twitch [15:48] <DopeLabs> why not run ffserver locally [15:49] <phelps> that'd work too, i think this is a little more passive though, it creates nice .flv's for each broadcast I start [15:49] <phelps> and its always running [15:49] <DopeLabs> yea i have wowza servers for that specifically [15:50] <phelps> I've been able to implement everything I needed using nginx-rtmp-module, its saved a lot of money switching away from wowza [15:50] <phelps> (for a production service) [15:50] <phelps> wanted to archive gameplay without taxing my network connection, my ISP caps data usage :/ [15:51] <DopeLabs> well if all you need to do is save a file than sure [15:52] <DopeLabs> too bad theres not a way to save the recording on the console, then worry about moving it across your network after its done recording for that sesion [15:52] <phelps> yeah, the only way to get them off is via facebook it seems [15:53] <DopeLabs> no youtube uploader? [15:53] <phelps> nah [15:53] <phelps> https://dl.dropboxusercontent.com/spa/ogoh5fdarolmwla/64kvzrgi.png [15:54] <DopeLabs> well if it can upload the recordings to fb, the data is on there somewhere.. just gotta find it [15:56] <phelps> yeah, its saving as an flv but its already H.265, just needs repackaged as mp4 [15:56] <phelps> s/265/264/ [15:56] <DopeLabs> soooo.. whats the need to stream to your pc to save it then? [15:57] <phelps> well, I can't upload all the clips, transfer cap from ISP, and I don't have the bandwidth to upload the live 720p [15:57] <phelps> 1.5mbps upload cap, 250GB/m cap [15:57] <phelps> now I can stream to my local server, saving _everything_ and then pick what I want from that [15:58] <phelps> the PS4 "clip" feature is pretty bad as well, its supposed to save 15 min, but it always misses the first 4 or 5 min of a game [15:58] <DopeLabs> ah.. i ifugre just grab the flv right off the consol and just straight copy the file [15:58] <phelps> oh no, you'd have to pull the HDD out to do that, if the tools even exist for it [15:58] <phelps> you can't browse the console HDD remotely [15:58] <DopeLabs> im sure theres a way [15:59] <DopeLabs> seems pretty common these days to have the ability to just put arbitrary data on those things [15:59] <DopeLabs> evem if its some 3rd party thing you gotta run thats like a filesystem browser [16:00] <phelps> you'd think so, and it was that way on the PS4, but they've tied these down to a few specific services and thats it [16:00] <phelps> you can't even watch x/h264 mkv/mp4 movies on them [16:00] <phelps> like you could with the previous gen PS3 [16:00] <DopeLabs> you cant playback the recordings you make? [16:01] <phelps> you can, but only on the PS4, then you can only share it to facebook [16:01] <phelps> they've done a great job of making the console shitty [16:01] <DopeLabs> hehe [16:01] <phelps> the PS3 was far more open to these types of things, it'd be cake to do it [16:01] <DopeLabs> give it time [16:02] <phelps> they're forcing you to use apps they've partnered up with, or use their storefront [16:02] <phelps> I've already got a lot of exp. with rtmp streams, it was cake to get this working [16:02] <phelps> hardest part was finding the IP range it used [16:03] <DopeLabs> or get something that just captures the hdmi signal in-line to the display [16:03] <phelps> bah, I can't afford that [16:03] <DopeLabs> ip range? ping? [16:04] <phelps> used syslogd to capture the connection status, searched for the 1935 port, found the range to be 199.9.0.0/16 [16:04] <phelps> dd-wrt and a little knowhow [16:05] <phelps> 2 iptables commands and I'm redirecting that range to my desktop [16:06] <DopeLabs> um.... can you not specify custom servers to stream to in whatever app your using to do that? [16:06] <phelps> nah, it gets one from some source, but they all seemed to be in that range [16:06] <phelps> you can stream to Twitch or Ustream [16:07] <phelps> both use standard RTMP tech, literally nothing stopping them from allowing custom output servers [16:07] <DopeLabs> well twitch's servers are on 199. ip [16:07] <phelps> yeah, 199.9.0.0/16 [16:07] <phelps> I've broke all of twitch.tv doing this, but I don't care for Twitch anyways [16:08] <DopeLabs> well its not really broken.. just disable the redirections and you should be solid [16:08] <phelps> yeah [16:09] <phelps> ah nope. fixed it [16:09] <DopeLabs> yea im lazy and just have a wowza box on the local lan at home [16:11] <ob1> Good morning. Wondering if anyone can offer a hand: I'm using ffmpeg to split commercials out of a mpegTS stream. When I start at time 0 via -ss 0, it seems to cut out the first half second or so when compared with the original. Any thoughts? [16:11] <DopeLabs> (sigh.. and closing the window doesnt work when your clicking a screenshot and not an actual window) sigh [16:12] <DopeLabs> specify an end time too? [16:12] <DopeLabs> some good examples here [16:12] <DopeLabs> http://superuser.com/questions/138331/using-ffmpeg-to-cut-up-video [16:13] <ob1> Actually going thru that site right now [16:13] <ob1> my command is: ffmpeg -y -i video.ts -vcodec copy -acodec copy -ss 0:00:0 -t 10 ./output.ts [16:15] <ob1> hmm and interestingly enough, this creates a 6 second file (not actually the problem i care about though) [16:15] <DopeLabs> maybe -ss 00:00:00.000 -t 00:00:10.000 [16:16] <ob1> hmm no change. switching to -t 30 yields a 26 second file. [16:17] <DopeLabs> well i guess go -t 14 then? [16:17] <ob1> but the real issue is that it skips the first couple of words of the video (it's a Seinfeld episode -- standup) [16:19] <ob1> hmm very odd: i changed the -ss command to "-ss -2" (as in negative 2) and it works correctly. [16:19] <ob1> does this sound like a reportable bug [16:23] <ob1> well at any rate talking it thru helped so thanks. if you want to bugreportify this go for it. [16:28] <DopeLabs> phelps: and shitty about your ISP limits.. [16:29] <phelps> its becoming the norm in the US [16:29] <DopeLabs> who do you use [16:29] <phelps> pay the most, get the least [16:29] <phelps> SuddenLink [16:30] <DopeLabs> ah i see.... yea comcast decided to not enforce the limits they once had set [16:30] <DopeLabs> theres throughput limitations but nothing as far as how much data/mo [16:33] <DopeLabs> 250G/mo is not much at all... i would smash that pretty quick [16:33] <DopeLabs> ive pushed 5TB already this month [16:34] <phelps> yeah. its 8GB/day [16:34] <DopeLabs> mb [16:34] <DopeLabs> oh [16:34] <DopeLabs> whath do they do to you when you hit the 250 mark [16:35] <phelps> and I have 30mbps download, I could eat my entire month of transfer in 1 day [16:35] <phelps> I get charged $10 per extra 50 GB [16:35] <DopeLabs> this sounds strangly familiar to verizons lte data plans [16:37] <DopeLabs> satisfied with the comcast though.. their dirty cheap, and (at least for me) seem to be pretty solid/stable these days [16:38] <DopeLabs> i keep calling them back every 6 months and telling them that i want to increase my speeds and pay less than i currently am... [16:38] <phelps> I'm happy with my speeds, I pay for 15mbps and get 25-30mbps, the cap is a killer though [16:38] <DopeLabs> thats worked 3 times so far [16:40] <kaotiko> hi [16:54] <micechal> do you know if there exists a list of scaling algorithms supported by ffmpeg good for pixel art? [16:55] <micechal> I've found hqx and super2xsai already [16:55] <micechal> are there any more? [17:16] <finko> has anyone had any issues downsampling audio with ffmpeg where you lose your high frequency sounds and the audio comes out muddy? from what I have read, the low pass filter seems to be the issue, but I am stuck looking for a solution to the problem. [17:21] <klaxa> to what sampling rate are you converting? [17:22] <finko> Im coming from any mp3 file to a 8khz mono 16 bit PCM wav file [17:22] <klaxa> that should low-pass filter at 4 khz [17:23] <klaxa> because you need twice the sampling rate to correctly reconstruct a signal of a certain frequency [17:23] <finko> is there an option to adjust the low pass filter? [17:24] <klaxa> that sampling rate is (was?) used in phone lines [17:24] <finko> yeah. thats what this conversion is for. call recordings that need converted [17:24] <klaxa> if you try to encode a signal with a frequency higher than 4 khz it will lead to aliasing [17:25] <finko> which is fine, so long as i dont completely lose the high frequency sound. im okay with the audio quality dropping significantly. i still need to be able to hear what was said in the conversation [17:26] <klaxa> 4 khz is not that high of a frequency, maybe you can post some sample files? [17:26] <c_14> try halving the bit depth and doubling the frequency [17:26] <finko> i am executing "ffmpeg -i in.mp3 -af aresample=osr=1000:filter_size=256:cutoff=1 out.wav" and i get the muddy muffled noise [17:28] <klaxa> what does osr do? [17:29] <finko> set the sampling rate [17:29] <klaxa> it's not in the online documentation [17:30] <klaxa> isn't 1000 a little low? [17:30] <finko> with a 16kb/s it matches 8khz [17:30] <klaxa> wh..at? [17:30] <klaxa> oh [17:30] <klaxa> ah [17:31] <klaxa> have you tried just using "ffmpeg -i in.mp3 -ar 8000 out.wav" ? [17:32] <finko> yes. the file comes out as a 128kb/s bitrate, which is way too high for our purposes. the file size also ends up way too large [17:32] <klaxa> wait... it's wav [17:32] <klaxa> of course it will be large [17:33] <klaxa> it's raw pcm, there is no compression [17:33] <finko> is there an option im missing in the documentation for bit depth? and yes, but the current files we have are generated by asterisk with the following details: 99-409.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 8000 Hz [17:34] <finko> my issue is I cannot get down to that low quality without losing the high frequency audio [17:35] <klaxa> ffmpeg -i in.mp3 -ac 1 -ar 8000 -f s16le out.wav [17:35] <klaxa> that should produce mono 8khz 16 bit little endian pcm in a wave container [17:35] <klaxa> no wait... [17:36] <klaxa> ffmpeg -i in.mp3 -ac 1 -ar 8000 -c:a pcm_s16le out.wav [17:36] <klaxa> like that [17:36] <klaxa> you could also encode it in a lossless format like flac [17:37] <klaxa> or if you want to be futuristic try opus, it has very good quality at extremely low bitrates [17:37] <finko> and that works perfectly with one major drawback: the wave file is twice the size of the original mp3 file, and still sitting at a 128kb/s bitrate [17:38] <klaxa> you do understand that you are encoding a lossy compressed file to a lossless uncompressed file, right? [17:39] <finko> no. i do not know that much about audio conversion. i realize this is frustrating from your end and i appreciate the help [17:40] <klaxa> do you have options regarding the final codec? because you could use pretty much anything but pcm and the file will be smaller [17:41] <finko> our asterisk system could take a GSM encoded wave file with the same sampling and bitrate requirements (8khz, mono 16 bit) [18:14] <rp__> Hi, anybody knows how to record live streams with current timestamps (as metadata) and then seek stream by passing timestamp as start position? [18:15] <rp__> I'm trying to set up streaming server with archive playback functionality in it. [18:15] <rp__> According to ffserver docs (https://www.ffmpeg.org/ffserver.html) it should be easy configurable but I've been stuck on this for a while. ("ffserver is a streaming server for both audio and video. It supports several live feeds, streaming from files and time shifting on live feeds. You can seek to positions in the past on each live feed, provided you specify a big enough feed storage.") [18:16] <rp__> (I post it yesterday as well - sorry for duplication) [18:16] <rp__> I created topic on SO as well http://stackoverflow.com/questions/25314666/how-to-record-live-video-stream… [18:26] <fajung> how can I do to convert .srt(ISO-8859-15) to (SAMI [it is listed in the codec info] ) .smi or .ass -sub_charenc ISO-8859-15 ? [19:13] <finko> how would I go about integrating libgsm to the windows FFMpeg executable to allow for GSM 6.10 encoding? [19:14] <JEEBcz> if it's not enabled and linked in already, there's no other way than to just build it yourself :P [19:15] <JEEBcz> or do you mean adding support for a library that isn't yet supported at all in FFmpeg? [19:15] <finko> i mean enabling the libgsm library that is mentioned in the ffmpeg documentation. i can see you can currently decode gsm files, but I need to convert from another file format to gsm [19:16] <JEEB> does that library and its libavcodec wrapper support encoding? [19:16] <JEEB> if yes to both, then you just have to build the library and then FFmpeg [19:17] <finko> that i do not know. its simply listed in the documentation as an available library, and no further documentation is available on it [19:19] <JEEB> check the FFmpeg git repository, browse to the libavcodec directory and check if 1) there are separate ...dec and ...enc files for it (if yes, it should be rather obvious) or 2) if there's a single file for it, if there are two things defined in the definition part [19:30] <finko> there is no precompiled ffmpeg executable with the libgsm already included? [19:35] <JEEB> no idea [19:35] <JEEB> http://ffmpeg.zeranoe.com/builds/ seems to contain it [19:42] <finko> turns out the windows executable already has the library and i was looking in the entirely wrong place for the name of the encoder. [19:42] <finko> thanks jeeb [20:40] <alexfu> if I resize a video and the video ends up looking like this: http://imgur.com/fjk25eo -- what does that indicate usually? [20:57] <odisa> Hello. I'm trying to stream by screencapping with VLC and UDP-ing it to ffmpeg to RTMP it to Twitch.TV. But I get the following error: http://pastebin.com/RZYJQWGi and Twitch shows no stream.. [20:57] <odisa> What am I doing wrong? [21:00] <odisa> I am using Ubuntu 14.04 and am consulting this guide: http://marctv.de/blog/tutorial-hd-pvr-twitch-mac-os-ffmpeg/ [21:46] <BtbN> odisa, ffmpeg can do X11 capture itself. [21:47] <BtbN> You might want to take a look at https://github.com/jp9000/obs-studio/ [21:57] <odisa> Ahh sweet, thanks! [21:57] <odisa> Wasn't aware that OBS was ported to Linux as well [22:01] <sine0> does anyone know of a decent video editing application for linux. i used to use adobe after effects on windows [22:03] <odisa> Try OpenShot [22:03] <odisa> sudo apt-get install openshot [22:05] <sine0> thanks ill give that a bash [22:07] <odisa> np, gl! g2g, bye and thanks BtbN [22:09] <brontosaurusrex> sine0, how much ram do you have? [22:10] <sine0> i forgot how do i check in linux [22:11] <brontosaurusrex> sine0, anyway, kdenlive is almost decent, if you have plenty of ram you may want to check lightworks beta [22:11] <brontosaurusrex> and "after effects" is not an editing application [22:11] <sine0> i think i have 8 gig of ram and an i7 [22:12] <sine0> yes i know but i was using blender cgi and lots of effects so it defaulted as my editor [22:12] <brontosaurusrex> thats should be fine for lightworks i guess [22:13] <brontosaurusrex> sine0, don't expect a smooth workflow thought [22:13] <sine0> i have 32 gigs in my other computers [22:14] <brontosaurusrex> ok, if you did master blender then lightworks could work for you, its more like a story-telling editor thought, don't expect and usefull effects [22:14] <brontosaurusrex> any* [22:16] <sine0> yea i mean if i got desperate i would create a partition and isntall windows7 just for aae. ill be find if i can edit and maybe do some color grading and correction. [22:16] <sine0> does ffmpeg support any kind of effects overlays or color edit application [22:16] <brontosaurusrex> i'd try kdenlive first [22:16] <sine0> also i like free software over payware [22:22] <brontosaurusrex> sine0, I hate free software [22:53] <troy_s> sine0: Your pipeline will solve most things in most instances. An NLE shouldn't be doing effects work. Junk approach. [22:55] <troy_s> sine0: Most of the NLEs out in Free Software-ville have succumbed to this (erroneous) belief that an NLE is used for effects. They aren't and shouldn't be. Not capable nor decent enough for anything above hobby grade work. This is also why they eventually collapse under their own weight, and the annals of history are littered with NLEs that have succumed to the identity crisis. [23:53] <sine0> troy_s: ? my pipeline [00:00] --- Sat Aug 16 2014

1 0