Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

December 2014

1 participants
62 discussions

ffmpeg-devel.log.20141230
by burek 31 Dec '14

31 Dec '14

[00:34] <Tim_G> nevcairiel: that's why CC0 exists btw, for the countries where PD doesn't exist [00:55] <kapouik> hi [00:56] <kapouik> I'm looking on source code of the version 2.4 on github and I find something strange [00:57] <kapouik> the branch 2.4 has been updated in 2.5 if I look the latest commit message [00:57] <kapouik> is it normal ? [01:46] <michaelni> kapouik, what do you look at, and what do you see that you find strange exactly ? [01:50] <kapouik> https://github.com/FFmpeg/FFmpeg/tree/release/2.4 <- look latest commit on this branch [01:50] <cone-867> ffmpeg.git 03Martin Storsjö 07master:50036c30df83: fate: Use bitexact conversions in the dpxparser test [01:50] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:8d3133f46851: Merge commit '50036c30df83b609bc5a95276f1287f8b9b8bdd6' [01:50] <kapouik> michaelni, it look like you commit on the wrong branch [01:51] <kapouik> oh my fault ... I just look again ... I have read 2.5 and not 2.4.5 [01:51] <kapouik> sorry for the mistake [01:57] <cone-867> ffmpeg.git 03Martin Storsjö 07master:b91a5757fcbf: dashenc: Fix writing of timelines that don't start at t=0 [01:57] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:e5a3766767a1: Merge commit 'b91a5757fcbf723da99b05b298a6f820271dbc2b' [02:12] <cone-867> ffmpeg.git 03Martin Storsjö 07master:8d54bacb789c: dashenc: Remove some stray double spaces [02:12] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:0ffb61e8cabf: Merge commit '8d54bacb789c7d37ca3cf48d9ac13083ad0c1ba7' [02:26] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:17dc83ab5e69: avfilter/vf_cropdetect: add RGB & RGBA support [03:57] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:60e2c3110ae3: avfilter/vf_cropdetect: Unroll 1byte per sample loop [03:57] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:5c7227bbb3c1: avfilter/vf_cropdetect: Unroll 3 & 4 bytes per sample loop [05:46] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:6ab4812f31c6: avfilter/vf_cropdetect: support 9-16bit planar formats [05:46] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:a2e2a9f240a7: avfilter/vf_cropdetect: fix ; typos [05:46] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:e405a8a73eeb: avfilter/vf_cropdetect: extend limit to cover 16bit pixel formats [10:34] <cehoyos> saste: I fear your review does not really help;-) [11:30] <saste> cehoyos, what review? [11:47] <cehoyos> You wrote on -devel that you prefer to use struct member names in ffprobe but that you agree it's nice to have more meaningful output. [11:50] <ubitux> nb_ref_frames would be even better [11:55] <saste> cehoyos, the choice is left to the contributor [12:03] <ubitux> saste: is it possible to plug a filtergraph (with 1 input and 1 output) at the end of another filtergraph? [12:03] <ubitux> typically in the context of the ffplay or ffmpeg [12:03] <ubitux> like, imagine you would want to support -vf foo -vf bar [12:04] <ubitux> (and i really meant a filtergraph, not a filter) [12:05] <saste> ubitux, it should be doable, but only *before* configuration [12:05] <saste> once a filtergraph is configured I don't think that's possible [12:06] <ubitux> ok [12:06] <saste> also you need to know how to link output and input pads, of course [12:06] <ubitux> and can you call any of the avfilter_graph_parse_* function multiple times on the same graph? [12:40] <saste> ubitux, never tried... [12:40] <saste> I don't know what happens if you configure a graph multiple times [13:58] <ubitux> why do we still have AVFilterBufferRef things all over? [13:59] <ubitux> ah it's under FF_API thing [14:15] <ubitux> mmh we still have 2 filters with "needs_fifo" flag? [14:29] <cone-77> ffmpeg.git 03Clément BSsch 07master:39e18b1f4063: avfilter/framepack: use FF_CEIL_RSHIFT() [14:29] <cone-77> ffmpeg.git 03Clément BSsch 07master:0c10cf6ab1aa: fate: add a fate-filter-framepack rule [15:14] <anshul__> I am planning to write a filter, that use data stream and 2 programs with multiple stream, Which implementation should I chose for my starting point [15:24] Action: ubitux wonders why there is a distinction between AVFilterLink and AVFilterInOut [16:05] <ubitux> i'd like to test if an option is available in a given format before opening [16:05] <ubitux> how can i do that? [16:06] <ubitux> akira4: hey :) [16:06] <ubitux> akira4: how are things going? [16:07] <akira4> good timing :) I had a few doubts about the protocol patch. [16:08] <ubitux> sure [16:10] <akira4> I'm not sure what exactly the dvd_protocol_send function is for. It seems to be used in all the build_packet_* function calls [16:13] <cone-77> ffmpeg.git 03Michael Stypa 07release/2.1:bf5df31b4f92: fix Makefile objects for pulseaudio support [16:14] <ubitux> akira4: it sounds like future plans for a user callback [16:14] <ubitux> like, you know, for menu and stuff [16:14] <ubitux> you can probably drop that stuff [16:14] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:8240fa5701aa: avcodec/motion_est: use 2x8x8 for interlaced qpel [16:14] <ubitux> i see no such thing available right now in the URLProtocol [16:14] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:80ba4b5d4536: avformat/rmdec: Check codec_data_size [16:14] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:56c5e009a184: swscale/x86/rgb2rgb_template: fix crash with tiny size and nv12 output [16:14] <cone-77> ffmpeg.git 03wm4 07release/2.1:68b6a5efbfd5: avformat/matroskadec: fix handling of recursive SeekHead elements [16:14] <cone-77> ffmpeg.git 03Rob Sykes 07release/2.1:059762d9da08: swresample/soxr_resample: fix error handling [16:14] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:844f7f78aa52: avformat/aviobuf: Check that avio_seek() target is non negative [16:14] <cone-77> ffmpeg.git 03wm4 07release/2.1:df1ea139b4fb: lavu/frame: fix malloc error path in av_frame_copy_props() [16:14] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:b4c4f9dba613: configure: create the tests directory like the doc directory [16:14] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:96981b092c09: avcodec/vmdvideo: Check len before using it in method 3 [16:14] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:ba99e90357c9: avcodec/utvideodec: Fix handling of slice_height=0 [16:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:07a37001a323: avformat/mov: check atom nesting depth [16:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:9354c47d2ec9: swscale: increase yuv2rgb table headroom [16:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:ac499d8142f3: avcodec/h264: make the first field of H264Context an AVClass [16:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:35819400e782: avcodec/indeo3: use signed variables to avoid underflow [16:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:9dc6a7f13a23: avcodec/hevc: clear filter_slice_edges() on allocation [16:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:84bc2cea2377: avcodec/h264: Clear delayed_pic on deallocation [16:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:7bd8ea83a0ba: avcodec/hevc_ps: Check diff_cu_qp_delta_depth [16:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:b188ff5e183d: avcodec/h264: Check *log2_weight_denom [16:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:d3853ad11f21: avcodec/indeo3: ensure offsets are non negative [16:15] <cone-77> ffmpeg.git 03Anton Khirnov 07release/2.1:01c83f4cb197: jvdec: check frame dimensions [16:15] <cone-77> ffmpeg.git 03Anton Khirnov 07release/2.1:823a9177a3ea: mmvideo: check frame dimensions [16:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:a736171b69b0: avformat/mov: Fix memleaks for duplicate STCO/CO64/STSC atoms [16:15] <cone-77> ffmpeg.git 03Stefano Sabatini 07release/2.1:67e2394cc68e: lavf/segment: remove duplicated and inconsistent cleanup code in seg_write_packet() [16:15] <ubitux> akira4: basically, you want something as basic as libavformat/bluray.c [16:16] <ubitux> if possible [16:16] <ubitux> (it's a ~200 line file which seems to support the strict minimum) [16:17] <ubitux> hopefully the libdvd* offers a similar api [16:18] <ubitux> so feel free to drop anything not used or incomplete [16:20] <j-b> commit release rage [16:28] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:c27539cd1eaa: Update for 2.1.7 [16:55] <cone-77> ffmpeg.git 03Michael Niedermayer 07master:eb465b8c56d4: avfilter/vf_uspp: clear AVPacket to not leave uninitialized memory [16:58] <ubitux> huh... in ffplay, is->video_st is set in configure_video_filters(), but is->audio_st is not st in configure_audio_filters() [16:58] Action: ubitux confused [17:00] <ubitux> oh great it's called twice [17:08] <ubitux> aselect should be made sample accurate [17:08] <ubitux> i think. [17:43] <anshul_mahe> What i need to do, if my patch breaks ABI [17:44] <anshul_mahe> and what to do, if there is no existing revision or similar thing in world realted to my patch [17:46] <ubitux> add the fields at the end [17:46] <ubitux> btw, use PRIu64 and similar instead of %llu [17:51] <anshul_mahe> Actually I am looking some more harsh review comments, about implementation and logic used [17:52] <ubitux> i know, that's why i'm mentioning it here [18:10] <Tim_G> anshul__: is it possible to use AVBuffer instead of adding a new structure? [18:11] <cone-77> ffmpeg.git 03Michael Niedermayer 07master:eee9b7a673de: ffprobe: Support extracting the number of reference frames [18:12] <anshul__> I dont know I will look at it, will get back 2 u soon [18:15] <anshul__> Tim_G: yes that struct is good, i will surely use it [18:16] <anshul__> you want me to use it instead of AVData structure [18:17] <anshul__> What do we do when things break ABI, I rarely understand this ABI and API concept [18:23] <anshul__> i will look git logs for this ABI thing [18:26] <Daemon404> as ubitux said, if you add fields at the end, it's not an ABI break [18:26] <BtbN> As long as only ffmpeg functions are used to allocate the struct [18:27] <Daemon404> well, yeah. [18:28] <ubitux> damn ffmpeg [18:29] <ubitux> i feel like this -ss thing is going to be annoying [18:31] <anshul__> ok, i will do that thanks [18:31] <Daemon404> i should look closer at that patch... [18:31] <Daemon404> AVData sounds liek a way too generic name [18:31] Action: Daemon404 wonders what is wrong with avbuffers here [18:32] <anshul__> I was changing it to AVBuffer as Tim_G suggested, didn't knew about it [18:32] <Daemon404> oh ok [18:34] <anshul__> can be add is_valid in AVBuffer, or use size to check whether its valid or not [18:35] <anshul__> because moving got_output variable is much cumbersome [22:15] <BBB> lol @ that x265 idea [22:15] <BBB> I remember a while ago there was a user trying to add runtime BE/LE selection to ffmpeg, so he could make runtime-selectable universal binaries for macosx that work on both ppc and x86 [22:15] <BBB> ... [22:16] <BBB> I think theyre in the same ballpark [22:16] <kierank> debian does the 8-bit/10-bit thing [22:18] <iive> i think elf supports such a thing, but there is a patent covering it. [22:22] <BBB> theres a patent for a bit that specifies whether a following image sequence consists of one progressive frame or two half fields that are to be interleaved to emulate a progressive image sequence [22:22] <BBB> I bet you theres a patent for any sentence that anyone in this chat channel has ever uttered [22:25] <iive> well, i've read about somebody trying to implement this, i don't remember what list was, kernel, glibc or gcc. but they scrapped the code because it was covered by patent. [22:28] <ubitux> it's still an enigma to me why both x264 and x265 can't just have 8 and 10 bit available in the same build [22:29] <ubitux> maybe that require some extended templating for a lot of code but well... is that really impossible to do? [22:30] <iive> ffmpeg can decode 8.9,10 bit with same binary :) [22:31] <nevcairiel> ubitux: well its just a design decision i guess [22:33] <ubitux> i believe it really is a technical issue [22:33] <ubitux> no one would make such annoying "design" on purpose [22:34] <iive> maybe they couldn't extend their existing design, without making a huge mess in the code. [22:34] <nevcairiel> in x264 probably because 10-bit was bolted on afterwards [22:34] <nevcairiel> and x265 was just a copy :p [22:35] <iive> maybe somebody could explain to me, why the 10bit version cannot encode 8bit videos... [22:35] <iive> it can't, can it? [22:36] <kierank> who is mentoring the crypto person? [22:36] <kierank> opw student [22:36] <kierank> can we have AES-NI (i.e something useful) instead of random ciphers that nobody uses [22:36] <kierank> pleasssssee [22:36] <nevcairiel> i wonder how hard using aes-ni is [22:37] <nevcairiel> do we have a benchmark for aes? [22:40] <jamrial> i posted some numbers a while ago [22:40] <ubitux> kierank: maybe tell it in the thread [22:40] <ubitux> and explain why it would be welcome :) [22:40] <jamrial> gcrypt uses aes-ni, and it's many times faster than c thanks to it [22:43] <jamrial> nevcairiel: tools/crypto_bench [22:51] <wm4> <BBB> I think theyre in the same ballpark <- what's the matter, for decoding this is also done? [22:59] <kierank> it's not [22:59] <kierank> well it kind of is [23:01] <BBB> I dont think we dlopen on decoding [23:01] <BBB> I think they just dont want to add another layer of templating to their api [23:01] <BBB> which is kind of a silly reaon [23:01] <BBB> but whatever [23:02] <BBB> theres no fundamental reason why you wouldnt be able to do it [23:02] <BBB> its just effort [23:02] <BBB> and most developers are lazy [23:02] <kierank> well the right way would actually be to mix them in an encoder [23:03] <iive> BBB: you know h264 code better, is it possible to do 8 bit decoding with 10bit routines? [23:03] <kierank> because for many calculations you don't need 10-bits of precision [23:03] <iive> i mean, encoding... [23:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07master:081567397e3c: avfilter/vf_yadif: add >8bit planar rgb formats [00:00] --- Wed Dec 31 2014

1 0

ffmpeg.log.20141230
by burek 31 Dec '14

31 Dec '14

[00:43] <Eryn_1983_FL> ok [01:37] <ParkerR> Are there any setups where ffmpeg is accelerated? I'm planning a new machine and wasnt sure if there was anything in particular that would helo towards video encoding/decoding [01:38] <ParkerR> *help [01:44] <klaxa> you can do hardware decoding for a bunch of codecs with graphics cards [01:45] <klaxa> for example vdpau can accelerate h264 decoding [01:47] <ParkerR> klaxa: Well my current setup has VAAPI but that doesnt seem to be supported all that well [01:47] <klaxa> https://trac.ffmpeg.org/wiki/HWAccelIntro [01:47] <ParkerR> And none of it seems to be enabled by default/I dont see a way to enable [01:47] <ParkerR> Yeah I saw that [01:48] <klaxa> in the manpage there is explained how to use vdpau for hardware decoding, vaapi is not listed not sure if it can be supported [01:48] <jarainf> On the other hand you could always go for raw CPU power [01:51] <ParkerR> Yeah. Anything would be an upgrade over what I have. Two main machines. One Core 2 2.13ghz P7450 and Celeron Dual core 1.1ghz 847 [01:55] <klaxa> do your machines have intel graphic chips? [01:56] <ParkerR> klaxa: The 847 is [01:56] <ParkerR> ~HD2000 [01:56] <klaxa> i doubt you will be able to utilize that [01:56] <ParkerR> Yeah thats why I was thinking about a nnice desktop [01:56] <ParkerR> *nice [03:10] <jswensen> I have been trying to solve some audio sync problems and cant figure the right command line options to prevent it. MP4s are created on iOS device. Converting to TS so I can split it for HTTP Live Streaming. Here is a simple example of the MP4->TS conversion that shows the audio sync getting progressively worse. http://pastebin.com/pfXqpwH2 [03:27] <jswensen> Even the simple command: ffmpeg -i 51305A0C-49E0-4695-BCF3-DCD1A9258FE4.mp4 51305A0C-49E0-4695-BCF3-DCD1A9258FE4_out.mp4 is causing the sudio sync problem [05:28] <squeegily> Hey guys. What was the command to discard everything but the second frame? [05:28] <squeegily> I remember it had to do with "select" [05:38] <squeegily> Aha it's ffmpeg -i /dev/video0 -vf select='eq(n\,2)' -vframes 1 test.jpg [11:42] <edoardo> hello [11:42] <edoardo> ffmpeg -f s16le -ar 48k -ac 1 -i pipe:0 -c:a libaacplus -b:a 32k test.m4a [11:42] <edoardo> this works [11:42] <edoardo> ffmpeg -f s16le -ar 48k -ac 1 -i pipe:0 -c:a libaacplus -b:a 32k pipe:1.m4a [11:42] <edoardo> this doesn't work [11:43] <edoardo> "Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument [11:43] <edoardo> " [11:43] <edoardo> "[ipod @ 0x1c56680] muxer does not support non seekable output" [11:56] <SirDarius> edoardo: alas, a pipe is not seekable, and your muxer needs a seekable output. this can happen if the muxer needs to update parts of the file, for example a header, after the file has been written already [11:56] <edoardo> so how could i reencode a stream on the fly? [11:56] <edoardo> the output gets transmitted via oggfwd [11:59] <SirDarius> do you have to use M4A ? Someone correct me if I'm wrong but I'm not sure it is streamable [11:59] <Mavrik> edoardo, mux to something else. [11:59] <edoardo> Mavrik: like? i don't know what's used for streaming [11:59] <Mavrik> edoardo, like important question. [11:59] <Mavrik> edoardo, why are you muxing audio to MP4 ... instead of OGG when you're using OGGFWD? [12:00] <Mavrik> I'd also think that oggfwd expects OGG Vorbis audio, not AAC [12:00] <edoardo> oggfwd just streams whatever you put in stdin [12:00] <edoardo> it doesn't care of what you are streaming [12:01] <Mavrik> I doubt it. [12:01] <Mavrik> Especially if you're trying to stream a non-streamable format like MP4. [12:04] <edoardo> Mavrik: it actually sends the stream, but the browser nor any player can play it [12:08] <SirDarius> edoardo: you might want to try ADTS, if whatever you are streaming to supports it: ffmpeg -f s16le -ar 48k -ac 1 -i pipe:0 -c:a libaacplus -b:a 32k -f adts pipe:1.aac (-f adts is not necessary here, it is implied by a .aac extension) [12:12] <edoardo> SirDarius: can't decode it :\ [12:14] <edoardo> Input #0, aac, from 'test.aac': [12:14] <edoardo> Duration: 00:00:29.27, bitrate: 48 kb/s [12:14] <edoardo> Stream #0:0: Audio: aac (HE-AACv2), 44100 Hz, stereo, fltp, 48 kb/s [12:14] <edoardo> this is from a stream that works [12:14] <SirDarius> or a TS, maybe ? ffmpeg -f s16le -ar 48k -ac 1 -i pipe:0 -c:a libaacplus -b:a 32k -f mpegts pipe:1.ts [12:15] <edoardo> can't open [12:15] <Mavrik> why don't you check what your streaming server actually supports first. [12:15] <Mavrik> Then find out of you can deliver content directly wihtout oggfwd crap [12:15] <Mavrik> Since you're obviously using the wrong tool for the job you're trying to do. [12:16] <Mavrik> THEN start blindly copy-pasting commands. [12:16] <edoardo> i actually switched to ezstream after you told me that oggfwd was the wrong tool :) [12:16] <SirDarius> i don't like being on the Y side of XY, more details are needed, indeed [12:16] <edoardo> blablabla | ezstream -c aac.xml [12:17] <edoardo> so, i have a opus stream that i'd like to reencode to aac [12:18] <edoardo> i'm currently using this: opusdec --quiet --rate 48000 - - | ffmpeg -f s16le -ar 48k -ac 1 -i pipe:0 -c:a libaacplus -b:a 32k -f mpegts pipe:1 | ezstream -c aac.xml [12:18] <Mavrik> hmm [12:18] <edoardo> fact is, it works when i reencode to vorbis/mp3 [12:18] <edoardo> but doesn't work with aac [12:18] <Mavrik> yes, because of different containers [12:18] <Mavrik> edoardo, first question, why aren't you using ffmpeg directly? [12:19] <Mavrik> IIRC it supports opus [12:19] <edoardo> Mavrik: because i have one opus stream that i want to reencode to multiple streams [12:19] <Mavrik> also cutting out the piping will fix alot of your issues with containers [12:19] <Mavrik> but yes, your issue is that m4a/mp4 is not a streamable container per se and requires a streaming server to put it together [12:19] <edoardo> so i'm using wget | oggdec | tee (encoder1 | ezstream) (encoder2 | ezstream) (encoder3|ezstream) [12:20] <Mavrik> hence you're better off delivering your audio to your streaming server in a streamable container [12:20] <Mavrik> why are you using ezstream and not streaming to icecast with ffmpeg directly? [12:21] <edoardo> Mavrik: the ffmpeg version i'm using for whatever reason doesn't want to stream to icecast [12:21] <edoardo> ffmpeg version 2.5.1 Copyright (c) 2000-2014 the FFmpeg developers [12:23] <SirDarius> is icecast listed in the output of "ffmpeg -protocols" ? [12:24] <edoardo> yes [12:26] <edoardo> hey! it works! but i get a very glitchy sound [12:27] <edoardo> adts works perfectly! :) [12:27] <edoardo> thank you!! [15:00] <gaspard> how could I create a stream like http://ice38.infomaniak.ch:8000/radiomeuh-128.mp3 ? [15:00] <c_14> use something like icecast or another streaming server? [15:10] <Mavrik> yep [15:10] <Mavrik> gaspard, by the domain name I presume they use icecast streaming server... ffmpeg can stream audio TO icecast :) [15:22] <gaspard> okay, thnx Mavrik and c_14, that was a missing piece, now I can start looking more effectively :-) [15:23] <gaspard> is there an easy way to stream with ffmpeg ? with ffserver ? [15:23] <gaspard> (I should have only subscriber to the live audio ) [15:24] <c_14> you _can_ stream with ffserver. The ease thereof depends. [15:34] <edoardo_> how can i install ffmpeg on wheezy? [15:34] <edoardo_> i have avconv right now :\ [15:34] <c_14> Get a static build, compile from source, get ffmpeg from testing [15:37] <BtbN> testing already has it? As in, the upcoming release? [15:38] <edoardo_> BtbN: yes, testing has ffmpeg [15:38] <edoardo_> wheezy has still ffmpeg version 0.8.16-6:0.8.16-1, Copyright (c) 2000-2014 the Libav developers [15:52] <fmiz> Hi all! I'm a noob with ffmpeg, I'm trying to test if I can stream video from my webcam to youtube, but I'm stuck. I figured that youtube takes in input only audio+video streams. I'm not interested in streaming audio, so I'm trying to add an empty audio track to my video, but I don't understand what's happening [15:55] <Trixboxer> Hello Everyone, Im trying to convert video into Black&Blue. I'm able to do it B&W but not able to find option to make it Black&Blue [15:56] <fmiz> This is what I see: http://pastebin.com/7GQgN7AZ [16:14] <Mavrik> gaspard, am [16:14] <Mavrik> gaspard, if you have icecast, then it already replaces ffserver [16:14] <Mavrik> so you just do ffmpeg -i <your file> -c copy icecast://<icecast-server> to stream to the icecast [16:14] <gaspard> yes, I just installed a icecast server and configured it, now my radio is live [16:15] <gaspard> sorry I didn't post anything, I got this working an hour ago [16:16] <gaspard> the installation on ubuntu is really easy (apt-get and a few steps) [16:16] <gaspard> pluging it to ffmpeg is nice too [16:17] <gaspard> i will post a gist when I get some clean result [16:17] <Mavrik> ok, good to hear that [16:19] <c_14> fmiz: does that error occur only when you add the audio stream? [16:19] <gaspard> I am doing this to voice chat to mobile phone browsers because it occurs that <audio id="audio" src="http://ice38.infomaniak.ch:8000/radiomeuh-128.mp3" controls></audio> works well with iOS/Safari, Android/Chrome and WPhone/IEmobile [16:26] <fmiz> c_14: yes, but even encoding only a video stream sometimes doesn't work [16:29] <fmiz> c_14: I don't know what happens, one time I run ffmpeg (only video capture) and it will not work, it looks like it isn't capturing any frame (frame counter doesn't change), another time it works flawlessy [16:29] <c_14> try updating ffmpeg, try adding -flags +global_header, try using the internal aac encoder [16:29] <c_14> maybe your capture device is doing weird things? [16:29] <fmiz> c_14: usually stopping and restarting works [16:30] <fmiz> c_14: I don't know... the capture device is a crappy laptop webcam [16:30] <c_14> maybe your capture device is doing weird things? <- probably this [16:30] <fmiz> c_14: Right now I'm testing with this device, how can I check for this weird things? [16:32] <c_14> hard to tell, you'd have to check the bitstream for corruption [16:32] <fmiz> c_14: I also tried 2 different versions of ffmpeg (the one in openSUSE 13.1 and the one you see in the pastebin), same issue [16:32] <fmiz> c_14: what about the other things you suggested? Intenal aac encoder? [16:33] <c_14> If it happens even when you don't have an audio stream, you can ignore that. [16:33] <fmiz> Yes, but it looks different [16:33] <c_14> Different error message? [16:33] <fmiz> Without audio, ffmpeg runs, it just doesn't get any frame [16:34] <fmiz> Instead with audio it quits, but I may understand why this happens ("Packets are not in the proper order with respect to DTS").. [16:35] <fmiz> fflogger: this is the output: http://pastebin.com/7GQgN7AZ [16:35] <c_14> Not that one, the one without the audio stream. [16:36] <fmiz> ah.. ok I'm also a noob with irc :D [16:37] <fmiz> c_14: http://pastebin.com/qvqnuwQe [16:38] <fmiz> c_14: the test.flv file looks right [16:39] <c_14> that one looks fine. [16:39] <c_14> try the other command with -c:a aac -strict -2 [16:39] <c_14> instead of -acodec libwhatever [16:39] <fmiz> c_14: with aevalsrc ? [16:39] <c_14> ye [16:40] <fmiz> c_14: same error as before [16:40] <c_14> add -flags +global_header [16:40] <fmiz> c_14: There is something though [16:40] <fmiz> c_14: My mistake :) [16:41] <fmiz> c_14: where should I put -flags? Before the first stream input? [16:42] <c_14> somewhere before the output [16:42] <fmiz> c_14: same error, should I pastebin? [16:43] <c_14> sure [16:44] <fmiz> http://pastebin.com/VJFjwF0z [16:46] <fmiz> I noticed something: the test.flv file without audio has a little "lag" at the begin of the file [16:46] <c_14> lag? as in the video is slower at the beginning or it takes a while to display [16:47] <fmiz> no, it displays immediately [16:48] <c_14> But doesn't play in realtime? [16:48] <fmiz> c_14: new test, without audio, but frame count is stuck, output: http://pastebin.com/SGLRTcWV [16:50] <fmiz> Let's say the video is slower at the beginning [16:50] <fmiz> it looks more like there are frame drops [16:51] <fmiz> c_14: this is the output of the last test.flv, that has the "lag" at the beginning http://pastebin.com/992w37TQ [16:51] <c_14> It looks to me like your webcam isn't producing frames sometimes. [16:53] <fmiz> in the last ouput I see atleast that the frame output isn't constant [16:53] <fmiz> This could be fixed using -r before the output? [16:54] <fmiz> or better before the input? [16:56] <c_14> try it before the input [16:57] <fmiz> http://pastebin.com/XW0aSrUf [16:57] <fmiz> c_14: Still nothing, same error [17:00] <fmiz> c_14: at least the command I'm using is right? I can test with another webcam, sooner or later, will it work or do you think it can't be done with ffmpeg? [17:02] <fmiz> c_14: Look at the last pastebin (you can see it also the others), line 15 and 18 [17:02] <fmiz> the error ffmpeg throws as anything to do with it? [17:02] <fmiz> *has [17:02] <c_14> it might, try -vf setpts=PTS-STARTPTS [17:03] <fmiz> before output? [17:03] <c_14> yep [17:04] <fmiz> Nope, still the same [17:05] <fmiz> c_14: http://pastebin.com/YdwWrWF8 [17:07] <c_14> try with this: -filter_complex '[0:v]setpts=PTS-STARTPTS[v]' -map '[v]' instead of the -vf [17:08] <fmiz> it works but the file has no audio stream [17:09] <c_14> -map 1:a [17:09] <c_14> add that as well [17:09] <fmiz> Same error :) [17:10] <fmiz> c_14: http://pastebin.com/NUDHQqSQ [17:16] <c_14> Can you try `ffmpeg -f v4l2 -r 30 -s 640x360 -i /dev/video0 -c copy -t 60 out.mkv' and then `ffmpeg -i out.mkv -f lavfi -i aevalsrc=0 -c:v libx264 -pix_fmt yuv420p -c:a aac -strict -2 out.flv' ? [17:18] <fmiz> it's working but muxing never ends [17:18] <fmiz> -shortest? [17:18] <c_14> eh, ye [17:19] <fmiz> It works [17:20] <olavi> Hi, when using ffPLAY for audio there is a window that pops up with some kind of graph for the audio. from looking in documentation i can see you can change the title of ffplay window, but any way to disable showing the window? or is there some flag to hide the window? [17:20] <c_14> `ffmpeg -f v4l2 -r 30 -s 640x360 -i /dev/video0 -c copy -f matroska pipe:1 | ffmpeg -i - -f lavfi -i aevalsrc=0 -c:v libx264 -pix_fmt yuv420p -c:a aac -strict -2 out.flv' [17:20] <fmiz> ok, but I need to stream this thing, so what can I do? I can't use an intermediate file... [17:20] <c_14> fmiz: pipes [17:20] <fmiz> c_14: god bless unix pipes :) [17:20] <c_14> olavi: -nodisp [17:21] <olavi> c_14: worked like a charm, thanks [17:22] <fmiz> c_14: Still the same error. [17:22] <fmiz> It looks like webcam and audio stream can't be processed on the fly. [17:24] <fmiz> http://pastebin.com/bZD18UW5 [17:24] <c_14> But it worked with the mkv? Did the errors always happen within 60 seconds? [17:24] <fmiz> It worked with the mkv, I stopped it after 10 sec [17:25] <c_14> The errors normally occur within 10s ? [17:26] <fmiz> in much less [17:26] <fmiz> I think it takes 1 or 2s [17:26] <fmiz> I'm retesting with you command with out.mkv, 60s [17:27] <fmiz> It worked [17:27] <c_14> `ffmpeg -f v4l2 -r 30 -s 640x360 -i /dev/video0 -c libx264 -pix_fmt yuv420p -f matroska pipe:1 | ffmpeg -i - -f lavfi -i aevalsrc=0 -c:v copy -c:a aac -strict -2 out.flv' maybe? [17:28] <fmiz> You moved the encoding before the pipe? [17:28] <c_14> yeah [17:28] <c_14> I don't even know anymore. [17:28] <fmiz> It's doing something weird [17:28] <c_14> oh boy [17:29] <fmiz> I'm testing [17:30] <fmiz> http://pastebin.com/WCKJTtbX [17:31] <fmiz> To stop it I first press q, but it won't stop.. it looks like the one of the two ffmpeg stop, the other won't, I had to use Ctrl+c [17:33] <c_14> Eh, ye. The 2nd process won't quit on q because it doesn't receive it (because it's getting the matroska stream on stdin [you could use fifos to get around this]) [17:33] <c_14> But other than that it works? [17:33] <fmiz> maybe yes [17:34] <fmiz> There are no errors, but the outfile has is very long [17:34] <fmiz> I mean, maybe there are 10s of video, and 2 hours of audio track [17:35] <fmiz> But I could limit the audio streaming ... what? audio rate? [17:35] <c_14> add -re before -i aevalsrc=0 [17:36] <fmiz> I think it's working [17:37] <fmiz> You did it :) [17:37] <fmiz> Thanks a lot [17:39] <fmiz> About the fifos... what can I do? [17:39] <fmiz> Instead of a pipe i redirect the first ffmpeg to a file thats is not a file, then I use that as video source for the 2nd ffmpeg? [17:39] <c_14> yep [17:40] <fmiz> (never used fifos before) [17:40] <c_14> mkfifo foo [17:40] <c_14> then use foo as output for the first command and foo as the input for the second [17:40] <c_14> and don't use the | separator anymore [17:40] <c_14> either start them in separate shells or use & to fork the first one [17:41] <fmiz> the first ffmpeg still requires pipe:1? [17:42] <c_14> nah, foo [17:42] <c_14> (if you did mkfifo foo [17:42] <c_14> ) [17:42] <c_14> or actually, the full path to foo (or relative) [17:49] <fmiz> c_14: ok I'm back testing :) [17:49] <nacho_> hey guys [17:49] <nacho_> anybody else having this issue building from osx? http://fpaste.org/164330/99581671/ [17:53] <fmiz> c_14: it's working. Thanks, you solved everything :) plus now I know that fifos exist.. That's going to be really useful. [17:56] <fmiz> c_14: last thing, I probably will need to run something like what you've suggested as a service. What should I do? Create a bash script and run it as a service? I probably will be using systemd [17:56] <c_14> Ye, something like that probably. [17:57] <fmiz> or may be use something in python to glue everything together? [17:57] <c_14> That'll work as well. [17:58] <fmiz> I'll try and see what's best... I'm still learning python, and I'm not that good with bash script :). Still thank you. [18:05] <fmiz> c_14: I'm trying the streaming to youtube, it's working. Can I use gpu acceleration to compress video? [18:05] <c_14> gpu acceleration is mainly useful for decoding video, not for encoding [18:07] <fmiz> So I just need a fast enough cpu to compress the stream, right? [18:10] <c_14> yep, you can also change the h264 preset to make it compress faster [18:10] <c_14> https://trac.ffmpeg.org/wiki/EncodingForStreamingSites [18:13] <fmiz> c_14: thanks, I already read that. I hoped I could use a GPU to speed up compression to achieve better quality, because probably the pc that will stream will not be that great. At least I'll be able to use a higher bitrate than my dsl [18:16] <__jack__> c_14: is gpu processing faster than cpu's, with recent GPUs ? with mine (3 years old), opencl is not useful compared to a pure cpu encoding, but maybe that changed (more & more works on such hardware) [18:17] <c_14> cpu encoders are still better than gpu encoders (in most cases) [18:19] <BtbN> pure hw encoders are only usefull in some special cases [18:20] <BtbN> like video game streaming for example, where you need your CPU power for the game. Or streaming to another PC at a high bitrate, which then transcodes to a lower bitrate with a high quality codec. [18:20] <BtbN> Generaly everything where you don't realy care about the bitrate beeing a bit higher [18:21] <jarainf> c_14, "generally speaking" [18:21] <__jack__> what about x264's opencl implementation ? [18:22] <BtbN> It's not a huge speedup [18:22] <JEEB> a good proof of concept [18:22] <JEEB> but not really something you want to use in a production [18:22] <JEEB> *-q [18:22] <JEEB> *-a [18:22] <BtbN> Isn't it used by default, when available? [18:22] <JEEB> no [18:22] <JEEB> it's probably built in, but not used [18:23] <JEEB> (if it finds the opencl related stuff on the system) [18:24] <BtbN> CUDA/OpenCL Based encoders aren't that powerfull anyway. [18:24] <BtbN> bothh the intel and nvidia hw encoders use a hardwired pice of hardware for it [18:24] <JEEB> GPUs are not meant for that kind of processing that is not very, very heavily multithreadable [18:24] <JEEB> as in, throw thousands of threads at the driver [18:24] <JEEB> and it will feed the GPU [18:25] <JEEB> video encoding that is well compressed is not that kind of stuff [18:25] <BtbN> Which is why they add special chips for that [18:25] <JEEB> the stuff the opencl thing for x264 does is very limited and is one of those things where you can do stuff separately from the rest (to a limit) [18:25] <JEEB> yup [18:25] <JEEB> everyone understood that the kool-aid was getting warm [18:26] <BtbN> I realy need to get a new nvidia card [18:26] <JEEB> and not only the server rooms with expensive heaters that the PR departments were able to sell :P [18:26] <BtbN> i want to look at that h265 hw encoder [18:26] <__jack__> JEEB: bad-compressed encoding can be usefully speed-up, you means ? :) [18:26] <JEEB> __jack__, yes - ATi made their own format which was simple as hell and intra-only methinks [18:26] <JEEB> and that was quite fast [18:27] <JEEB> basically you have to make the format around what the GPU can do :P [18:27] <JEEB> BtbN, I don't think the HEVC encoder components are on actual hardware yet [18:28] <BtbN> yes they are [18:28] <BtbN> the newest maxwell generation has them [18:28] <BtbN> so, the 900 gtx cards [18:28] <__jack__> BtbN: encoder or decoder ? [18:28] <JEEB> but yeah, ASICs usually aren't geared for compression [18:28] <BtbN> encoder [18:28] <JEEB> so you might get alright speeds, but not really compression [18:28] <JEEB> might be fun to test if you need the card for other things, too [18:28] <JEEB> but not worth buying the card for just the ASIC [18:29] <BtbN> "Support for HEVC (H.265) encoding on GM20x GPUs (GTX980 and future Quadro/Tesla/GRID platforms based on GM20x GPUs)" [18:29] <BtbN> Aparently it's only the 980 [18:30] <JEEB> yeah, but I think they added HEVC support for decoding as well, but that was at least partially software if not fully. so they might have just added a CABAC encoder or something there :3 not that I know [18:30] <BtbN> Yeah, but h265 decoding is supported by all maxwell cards [18:30] <JEEB> an ASIC CABAC coder would be pretty cool, though [18:30] <BtbN> encoding is 980gtx only [18:30] <JEEB> although probably not on a GPU :/ [18:30] <JEEB> too much latency [18:32] <BtbN> nvenc is extremely usefull for video game streaming. As it can use OpenGL/Direct3D framebuffers as input [18:32] <BtbN> So you can encode the game without the frames ever leaving the vram [18:32] <BtbN> They use that for their ultra-low-latency game streaming [18:33] <JEEB> yeah [18:33] <JEEB> for that kind of stuff it's quite useful [18:33] <JEEB> it'd be even more if it had a lossless mode [18:33] <JEEB> RGB or YCbCr [18:33] <BtbN> The api has a lossless mode [18:33] <BtbN> but so far it's not implemented by the hardware [18:34] <BtbN> But i think the new maxwell generation added YUV 4:4:4 lossless mode [18:34] <__jack__> I don't think GPUs will produce a better HEVC output than x265; it's the eternal fight, software vs hardware; software will always be, in practical, better than hardware, because it is easier and can be patched; well, it's usefull sometime, still [18:35] <BtbN> Well, but they will encode it in real time without needing 16+ cores [18:35] <BtbN> And propably at a better quality/lower bitrate than h264 [18:35] <JEEB> well, that we will see when the HEVC encoders get more mature [18:35] <JEEB> currently even the sw implementations are having problems with beating x264 [18:36] <BtbN> That's why i'm so curious about what this nvidia encoder is capable of [18:36] <JEEB> but yeah, the bottom line is that no useful ASIC will produce better compression than software encoders, but if you have specific needs they can be quite useful [18:38] <BtbN> nvidia primarily added the encoder chip for their Game Streaming products. The encoder was originaly not intended to be useable individualy. [18:39] <BtbN> When i first got in touch with nvenc, i had to contact nvidia for a license key. [20:13] <myndzi> i'm looking for a way to filter a capture or webcam source through some stuff to clean up the video and output another video or webcam source; know of anything like this? [23:54] <shevy> are there any examples out there how to use ffmpeg filter capabilities? [23:54] <shevy> for instance, "blur a video by 1 pixel" or something like that [23:55] <c_14> https://trac.ffmpeg.org/wiki/FilteringGuide [23:55] <shevy> cool thanks c_14 [23:56] <shevy> whoa.. about 180 filters [00:00] --- Wed Dec 31 2014

1 0

ffmpeg-devel.log.20141229
by burek 30 Dec '14

30 Dec '14

[00:05] <cehoyos> Compn: Could you test r10k with the directshow filter? [00:07] <michaelni> kierank, i am not sure because it would lead to interlaced scaling being done on progressive video in many cases. See for example: -i matrixbench_mpeg2.mpg -vf scale=1920:1024:interl=-1 -qscale 1 test.avi [00:08] <kierank> michaelni: please read the ticket again [00:08] <michaelni> kierank, please look at test.avi [00:08] <iive> isn't there an interlace flag in the frame data? [00:08] <michaelni> from the example above [00:09] <kierank> where do I download matrixbench [00:10] <michaelni> http://samples.mplayerhq.hu/benchmark/testsuite1/matrixbench_mpeg2.mpg [00:10] <nevcairiel> well the reasoning for default interlace is that interlaced scaling on progressive looks "ok-ish" still, while progressive scaling on interlaced entirely destroys the image [00:11] <iive> once again, isn't there a interlace flag set in the frame data? [00:11] <kierank> yes [00:11] <michaelni> nevcairiel, i thought so too but the video in the above example doesnt exactly look ok-ish [00:11] <iive> then why not use it? [00:11] <kierank> the filter does [00:12] <michaelni> yes when interl=-1 is set [00:13] <iive> i don't understand, the best behaviour is to use interlace scaling for interlaced frames and progressive for progressive. [00:14] <iive> why botch one or the other? [00:14] <kierank> iive: read the code [00:14] <iive> which code vf_scale? [00:14] <kierank> yes [00:15] <michaelni> iive, lots of videos have the interlaced flags set, even when the content actually is from progressive sources [00:16] <iive> well, isn't there an interlace detect filter in ffmpeg? [00:16] <michaelni> yes [00:16] <nevcairiel> in my experience from real-world content, its usually not that many, and for default behaviour it would be acceptable to use it [00:16] <iive> so... just put it before scale? [00:16] <nevcairiel> its slow [00:16] <cehoyos> nevcairiel:Isn't that a reason to leave the default (that is looks ok-ish)? [00:16] <nevcairiel> the current default doesnt look ok-ish [00:16] <cehoyos> If you forgot to use interlaced scaling, you see the issue. [00:17] <kierank> michaelni: looks ok? [00:17] <iive> well, for once, I'm absolutely against using interlaced scaling on progressive frames! [00:17] <cehoyos> That is what I mean: Since you wouldn't immediately see the bad quality, you wouldn't notive that you should have set progressive scaling. [00:17] <kierank> michaelni: i didn't encode to to avi [00:17] <ubitux> "split=2[a][b]; [a]scale=1920:1024:interl=-1[x]; [b]scale=1920:1024[y]; [x][y]blend=difference" yay. [00:17] <ubitux> (difference128 more relevant maybe) [00:17] <cehoyos> That is apart from the fact that I thought we all agree interlaced content is a bad thing. [00:18] <kierank> interlaced *coded* content should be scaled interlaced [00:18] <kierank> and the user should override it to progressive if they know the underlying content is progressive [00:18] <kierank> mpeg-2 chroma subsampling was designed to do this [00:18] <iive> kierank: WRONG! [00:18] <iive> interlace must die [00:18] <cehoyos> nevcairiel: All dvb sources are marked as interlaced but are very often progressive [00:18] <kierank> cehoyos: wrong [00:18] <nevcairiel> cehoyos: wrong [00:19] <kierank> I tried to explain this to you in the ticket [00:19] <cehoyos> What do you mean? [00:19] <kierank> the coding method and the display method of the material are orthogonal [00:19] <iive> and we should not cripple our software in order to support it by default. [00:19] <nevcairiel> we have plenty 720p50 dvb broadcasts in germany, which are actually marked progressive [00:19] <kierank> iive: when you get a clue, please come back [00:19] <cehoyos> But only the coding method is written to the stream or do I miss something? [00:20] <iive> kierank: so you are going into insults, instead of explaining and defending your position. [00:20] <cehoyos> nevcairiel: Really? They were all marked interlaced when I last checked: Which program should I look at? [00:20] <kierank> iive: read the ticket and the code [00:20] <kierank> instead of just crying about interlaced [00:21] <iive> kierank: no, i want YOU to explain what do YOU want to be done. [00:21] <nevcairiel> cehoyos: ZDF HD for example [00:21] <kierank> iive: I want to solve a ticket, therefore you must read the ticket to understand the context [00:21] <iive> i'll read them, but you should be able to explain your position, without wasting time. [00:21] <kierank> michaelni: the error is probably because you are encoding [00:21] <cehoyos> Sorry, of course all 720p is marked as progressive, I meant the (hundreds?) of SD channels. [00:22] <kierank> the content has been prefiltered for interlaced vieweing [00:22] <Daemon404> iive, and you should not be able to piss over someone withotu any context [00:22] <Daemon404> please kindly go forth. [00:22] <cehoyos> Daemon404: I am sorry that I am currently around, please spare your insults while I am here. [00:23] <Daemon404> s/please kindly go forth.// [00:23] <Daemon404> dome [00:23] <Daemon404> done* [00:24] <Daemon404> anyway, ive read the ticket and agere with kierank here. [00:24] <Daemon404> and my real world experience seems to match nevcairiel's wrt the flags [00:24] <nevcairiel> I would say just to use the frame flags [00:24] <Daemon404> i'd be inclined to agree [00:24] <kierank> nevcairiel: yes, that's what setting the interlaced method does in vf_scale [00:24] <kierank> it uses the frame flags [00:25] <kierank> at the moment it's hardcoded to progressive [00:25] <michaelni> there are various flags in mpeg2, we use the one the spec says should be used to determine interlaced/progressive, but maybe something else works better [00:25] <nevcairiel> I use it to enable deinterlacing, and I very rarely ever encounter a problem where a progressive frame is being deinterlaced wrongly [00:25] <cehoyos> As I understand, nevcairiel actually confirmed that nearly all dvb content is marked as interlaced [00:25] <nevcairiel> I confirmed that interlaced content is marked interlaced, and progressive content is not :P [00:25] <cehoyos> This sounds very unlikely: All SD channels are always marked as interlaced afair [00:26] <cehoyos> That is not what you wrote above. [00:26] <kierank> cehoyos: again read the ticket [00:26] <kierank> PAL is interlaced [00:26] <kierank> the material is filtered so as to be interlaced [00:26] <kierank> it is not ffmpeg's job to override the flagging [00:26] <kierank> the user should do that [00:26] <nevcairiel> dvb is special, you can have a progressive movie with 2:2 telecine, and a truely interlaced overlay on top from ads or something [00:26] <cehoyos> I am right now watching a PAL dvb stream with interlaced content [00:26] <cehoyos> Please epxlain. [00:27] <kierank> the upscaling will be very similar when doing interlaced upsampling on underlying progressive material [00:27] <cehoyos> But not correct or am I wrong? [00:27] <kierank> but interlaced material with an progressive upsample (the default) is totally broken [00:28] <cehoyos> Yes, luckily you immediately see the issue and can choose the correct flags. [00:28] <cehoyos> If the default will be changed, it will break typical encodes in a very subtle way. [00:28] <iive> i could agree that vf_scale been hardcoded to progressive is bad thing. it should be autodetect based on frame flag. [00:28] <cehoyos> No: That would always lead to bad encodes. [00:28] <cehoyos> For dvb [00:28] <cehoyos> And many dvd sources [00:28] <iive> but if user wants to override the interlace, he can do it in the scale... [00:29] <kierank> the specs have been designed such that interlace upsampling progressive material is very similar [00:29] <cehoyos> Yes, luckily the user can choose the correct method. [00:29] <kierank> cehoyos: so in my batch job encoding 10k files you want me to check them manually? [00:29] <iive> it is absolutely wrong to set vf_scale to always do interlace scaling. [00:29] <cehoyos> I thought that Michael showed an example where this is not correct or do I misunderstand? [00:29] <kierank> cehoyos: looks fine to me? [00:29] <cehoyos> Does idet not work for you? [00:29] <iive> just because most dvb encoders doesn't set the flags correctly. [00:30] <kierank> idet is a heuristic [00:30] <cehoyos> But why don't you set interlaced encoding if you think this is the right choice? [00:30] <cehoyos> I don't understand? [00:30] <kierank> ??? [00:30] <kierank> interlaced encoding? [00:30] <iive> meaning, the interlace flag is taken from the decoder [00:30] <cehoyos> interlaced scaling for your 10k encodings... [00:31] <iive> assuming that interlaced content would not be encoded as progressive, because it is inefficient. [00:31] <kierank> cehoyos: that's what i am saying should be teh default [00:31] <iive> you've written mpeg2 encoders, you should be the expert. [00:31] <kierank> so that most things work [00:31] <cehoyos> iive: All dvb content (that is: all SD dvb content) is marked as interlaced, including (progressive) movies and series. [00:31] <kierank> the dvb encoder doesn't know what the underlying format is [00:32] <kierank> it doesn't care [00:32] <kierank> the input format is PAL which is defined as interlaced [00:32] <iive> cehoyos: great, then kierank hacks would be automatically done. [00:33] <cehoyos> Which is why we can not auto-detect interlaced nor choose interlaced scaling as default: Most users would not realize why their encodings are suddenly of worse quality [00:34] <iive> cehoyos: that's my point! [00:34] <kierank> the spec defines upscaling to be performed as interlaced [00:34] <kierank> it is not ffmpeg's decision to do it otherwise [00:34] <iive> kierank: what specs? [00:34] <kierank> mpeg-2 specs for example [00:34] <kierank> bt 601 [00:34] <kierank> as well [00:34] <iive> kierank: mpeg-2 specs define progressive frames to be scaled as interlaced? [00:35] <kierank> iive: probably to you they do since you just complain and don't read the specs [00:35] Action: kierank adds iive to ignore [00:35] <iive> kierank: tell me the paper and the title where this is defined. [00:35] <kierank> michaelni: can you explain to me what is wrong with your clip? [00:36] <michaelni> kierank, it looks quite bad [00:36] <kierank> michaelni: can you make a screenshot? [00:43] <michaelni> kierank, http://ffmpeg.org/~michael/good.pnm vs. http://ffmpeg.org/~michael/bad.pnm [00:45] <iive> well, I can't find anything about interlaced scaling in iso13818-2 (video coding). [00:45] <iive> michaelni: in case kierank have really ignored me, ask him for exact reference to the standard. [00:49] <kierank> if you really want then you could make it only do an interlaced *chroma* conversion [00:50] <kierank> so make it follow the frame interlaced flags if the resolution doesn't change [00:50] <kierank> I think that's an upscaler bug though [01:35] <Compn> cehoyos : not sure if i have r10k dshow setup [01:38] <kierank> cehoyos: http://www.bitjazz.com/en/products/sheervideo/faq/formats/pixel_formats.php… [01:46] <cehoyos> Compn: https://www.aja.com/en/support/directshow [01:46] <cehoyos> kierank: This link was already sent today with a remark that it appears they are not sure. [01:47] <cehoyos> But this is actually irrelevant, I would like to know if somebody has the filter and can test playback. [01:55] <Compn> downloading filter now [01:56] <Compn> what sample do you want me to test ? [01:56] <Compn> i dont have latest ffmpeg [01:57] <cehoyos> This has not much to do with FFmpeg. [01:57] <cehoyos> First the two samples from our repo: [01:58] <cehoyos> ./V-codecs/R10k.mov and ./V-codecs/R10g.mov [01:58] <cehoyos> Then the sample that doesn't work with FFmpeg:https://www.dropbox.com/s/6ugnjlivdhdlixt/10BitRGB444_r10k_2sec.avi [02:00] <Compn> well not sure if wmp will play .mov [02:01] <cehoyos> It does here, what version are you testing? [02:01] <cehoyos> (No chance for current WMP?) [02:02] <Compn> i have wmp11 [02:02] <Compn> is it new enough ? [02:04] <cehoyos> Please test and tell us. [02:05] <Compn> probably need gabest mp4 demuxer (no , it wont open .mov) [02:05] <cehoyos> Then please test the avi file [02:06] <Compn> downloading now [02:09] <Compn> wmp does not play it with aja installed [02:10] <cehoyos> Does it play the output of ffmpeg -f lavfi -i testsrc -t 10 -vcodec r10k out.avi ? [02:10] <cehoyos> Are our files played with a mov filter? [02:10] <Compn> hmm i'm not sure i installed aja correctly, cant get any 10k to work [02:12] <cehoyos> Maybe you could answer on the mailng list that this link does not lead to a filter that helps? [02:13] <jamrial> doesn't wmp11 use media foundation instead of dshow? [02:14] <jamrial> wmp11 supports mov, but probably not files like that one that require dshow filters [02:16] <jamrial> try mpc-hc and force the usage of aja instead of the internal decoder [02:16] <Compn> downloading mpc-hc [02:17] <Compn> (testing this on a vista box btw) [02:22] <Compn> getting nothing with mpc-hc [02:23] <cehoyos> Nothing? [02:23] <Compn> mpc-hc could not render some of hte pins in the graph, you may not have the needed codec or filter installed on the system [02:23] <Compn> for the avi [02:24] <Compn> for the mov i get nothing. [02:25] <jamrial> if you forced aja from the external filters menu and it still fails then no idea [02:26] <Compn> yea external filters aja av render 0 > 3 [02:26] <Compn> graphedit also fails [02:29] <Compn> course i could be doing something wrong :) [02:30] <Compn> aja makes a quicktime codec [02:30] <Compn> or did at one time [02:30] <Compn> https://static.aja.com/assets/software/AJA_SoftwareCodec.zip [02:31] <Compn> Install the AJA QuickTime codec on any machine without having to install the complete driver for an AJA hardware device. [02:32] <cehoyos> The quicktime codec will not help with the avi file I fear. [02:32] <cehoyos> My issue is that the avi file plays ugly with FFmpeg but I think the ugliness is correct: The user disagrees. [02:39] <kierank> cehoyos: it breaks because of the 10 to 16-bit upconversion [02:41] <cehoyos> kierank: How does your poc look that shows this? [02:41] Action: Compn slinks away [02:42] <kierank> i just looked at the code [02:42] <cehoyos> No! [02:42] <kierank> it's rgb48 so 16-bit rgb [02:42] <cehoyos> Please test the sample before you comment, thank you! [02:42] <cehoyos> https://www.dropbox.com/s/6ugnjlivdhdlixt/10BitRGB444_r10k_2sec.avi [02:43] <cehoyos> And if you have a player that shows pretty colour bars for this file, please tell me how I can reproduce. [02:51] <Compn> that file was made with lavf :P [02:51] <Compn> ehe [02:51] Action: Compn runs [02:51] <Compn> >sample made with lavf, its invalid [02:53] <cehoyos> Which file? [03:11] <Tim_G> michaelni: You need documentation for the mpeg profiles patch [03:24] <cehoyos> Compn: Which file was made with libavformat? [03:54] <michaelni> Tim_G, added mpeg4_* to the list in the docs where the others are locally [04:02] <Tim_G> michaelni: cool thanks [04:02] <Tim_G> cehoyos: I think he was referring to https://www.dropbox.com/s/6ugnjlivdhdlixt/10BitRGB444_r10k_2sec.avi [04:09] <cehoyos> I have to go to sleep now but maybe you could ask him how he found out? [04:35] <Compn> oh i was wrong about it being lavf [04:35] <Compn> just me being stupid [04:35] Action: Compn hides under a rock [04:35] <Compn> sorry carl [04:35] <Compn> cant even read mplayer output correctly anymore [04:41] <cone-45> ffmpeg.git 03Michael Niedermayer 07master:ac08c5c0adcb: avformat/mux: 2 subtitle packets could have the same DTS [07:13] <visiot> can i control udp transmission rate while streaming [07:32] <visiot> while multicasting using ffmpeg i'm getting a jitter on my HQAM 40 to 60 ms. i'm capturing screen. if i use cvlc on the same i'm getting jitter of 1 to 3 ms only. how can i reduce jitter size on ffmpeg [07:44] <av500> kierank: yep, saw it [08:33] <ubitux> --enable-nvenc and --enable-libnvenc enabling 2 different things? [08:33] <ubitux> that's really what you want nvidia? [08:33] <ubitux> ;_; [09:30] <nevcairiel> they just dont think :p [11:18] <visiot> ubitux : can you tell me how can i slow the udp transmission rate while multicasting [11:18] <ubitux> no idea [14:18] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:748ad112e2c0: avcodec/ffwavesynth: Use av_freep() to avoid leaving stale pointers in memory [14:42] <ubitux> cehoyos: freedesktop.org? [14:46] <cehoyos> If we agree that the nvenc header is not free and can only be used in FFmpeg with non-free than nothing changes if a wrapper gets added to FFmpeg. [14:46] <cehoyos> If the wrapper is a system library like vdpau, that does - imo - change the issue. [14:47] <cehoyos> Does the xcb-shm patch work on your system? [14:47] <ubitux> haven't tested [14:48] <ubitux> cehoyos: the "wrapper" is lgpl so i don't see what's your point [14:49] <ubitux> the header as well [14:49] <iive> cehoyos: generally headers are not considered copyrightable [14:49] <cehoyos> How can it make a difference if a header - if we consider it non-free - is included by a c file inside the FFmpeg sources called libnvenc.c or by a file called libnvwrapper.c? [14:49] <ubitux> where do you see a non-free header? [14:49] <cehoyos> My point is just that I like to hear the FSF's opinion on this, and I believe we agreed about this. [14:50] <ubitux> my main concern with the patch is the duplication of current nvenc [14:50] <ubitux> which is going to raise a lot of complains if this is merged [14:50] <cehoyos> We should not allow the second patch we get for the same problem to be allowed something that we did not allow the first patch. [14:50] <cehoyos> Of course! [14:50] <cehoyos> Please tell that on the mailing list. [14:50] <wm4> why don't we tell nvidia that we don't want to promote their shit under these conditions? [14:51] <cehoyos> We already did... [14:51] <wm4> good [14:51] <cehoyos> We already promoted their shit into our codebsae. [14:51] <cehoyos> codebase [14:52] <ubitux> cehoyos: will do, but i still don't get what's the legal problem with the patch [14:53] <cehoyos> that the header contains a note "do not use this header for anything that looks like open source". Note that I am not saying we shouldn't ignore this but that we should ask somebody who knows better. [14:53] <ubitux> what header? [14:53] <cehoyos> We already have enough copyright problems, I would like not to add one more knowingly [14:54] <cehoyos> The nvidia header, sorry I don't understand your question. [14:54] <cehoyos> (We had the discussion already before 2a428db5 was committed.) [14:54] <ubitux> are you talking about "All rights reserved"? [14:54] <ubitux> or a file? [14:55] <cehoyos> No, where do you see that? [14:55] <ubitux> i'm just wondering about what you are talking about [14:55] <ubitux> what are you refering to by "header" [14:55] <ubitux> ? [14:55] <cehoyos> The nvidia header [14:55] <ubitux> what is that? [14:55] <cehoyos> nvapienc.h or similar [14:55] <BtbN> nvEncodeApi.h [14:56] <ubitux> thank you. [14:56] <iive> is it installed in the system? or included in the patch/ffmpeg? [14:56] <BtbN> You need to download it from nvidia [14:56] <cehoyos> It is included by nvenc.c and the new patch [14:56] <ubitux> and it's necessary? [14:56] <ubitux> nvenc seems not to use it [14:56] <cehoyos> Definitely [14:56] <BtbN> Of course it uses it [14:56] <ubitux> ah mmh... [14:57] <ubitux> my bad [14:57] <cehoyos> It's the fourth line afaict [14:58] <ubitux> so we already have the issue [14:58] <cehoyos> No, the existing encoder is marked non-free [14:59] <ubitux> alright, so you just need to die_license_disabled nonfree nvenc [14:59] <ubitux> libnvenc* [14:59] <cehoyos> I thought we agree that we don't want the patch at all? [14:59] <ubitux> yes sure [14:59] <ubitux> but it's better if we explain what is wrong [14:59] <cehoyos> (But I assumed we would like to see a system librray that allows us to use nvenc without non-free, or am I wrong?) [15:00] <BtbN> If nvidia itself releases an open source library for nvenc, that would propably circumvent any licensing issues [15:00] <BtbN> as they can't sue themselves [15:00] <cehoyos> I don't think we fear to be sued by Nvidia... [15:00] <cehoyos> (We certainly aren't) [15:01] <BtbN> nvidia doesn't seem to care at all. There are other projects who just added that header to their own repos. [15:01] <BtbN> And nvidia even promotes those [15:02] <BtbN> No idea if they are even aware of the license they put there [15:04] <wm4> lol [15:07] <Compn> nvidia wants it in ffmpeg because tools that use nvenc will call in ffmpeg [15:07] <Compn> otherwise nvidia has to submit it to every stupid distro and have the same 'oh we dont want to promote nvidia' talk that cehoyos is giving [15:07] Action: Compn plays devils advocate [15:08] <Compn> but yeah vdpau reference makes sense [15:08] <Compn> why dont they just put it in vdpau ? [15:08] <iive> don't give them ideas! [15:09] <BtbN> vdpau is a pure _de_coding api [15:09] <wm4> Compn: that's what intel did (they put encoding into their own hw decoding lib) [15:09] <Compn> BtbN : so what [15:09] <BtbN> wm4, did you ever try vaapi based encoding? [15:09] <iive> hum... actually that kind of makes sense. [15:09] <BtbN> It's horrible. Worst api i have seen in a while. [15:09] <wm4> BtbN: fortunately not [15:09] <wm4> I saw that wayland uses it [15:09] <wm4> or rather, weston [15:09] <Compn> BtbN : having another header in vdpau wont change that [15:09] <BtbN> You have to generate the h264 nal bitstream manualy [15:10] <BtbN> Compn, well, the main reason propably is that there is no vdpau on windows. [15:10] <Compn> ah [15:10] <wm4> BtbN: isn't that somewhat similar to hw decoding? there you also need to decode parts of the bitstream yourself [15:10] <BtbN> wm4, not the h264 nal [15:10] <cehoyos> What talk am I giving? [15:10] <BtbN> you have to do the de-slicing yourself [15:11] <cehoyos> Can you explain why you believe that the file (which file?) yesterday was written by libavformat? [15:11] <Compn> cehoyos : i was wrong about the r10k avi sample being lavf [15:11] <Compn> i was reading mplayer output incorrectly, my bad. [15:11] <BtbN> wm4, https://github.com/BtbN/vlc-vaapi-enc i wrote that a while ago. It works, but the code is a huge pain. [15:11] <cehoyos> np, I already sent a patch when the user provided a new ("better") sample. [15:11] <BtbN> It's such a huge pain that intel itself is writing a wrapper library around libva. [15:12] <BtbN> so you don't have to deal with libva [15:12] <Compn> cehoyos : hopefully it works for that user :) [15:13] <BtbN> https://github.com/01org/libyami is anyone is interested [15:15] <cehoyos> ubitux: The private options are what makes the patch a good idea... [15:15] <cehoyos> At least this is how I understand others' comments, I don't care much about h264 encoding. [15:15] <ubitux> cehoyos: the x264 option mapping ? [15:15] <cehoyos> Yes, this was welcomed iirc [15:15] <ubitux> :/ [15:15] <ubitux> my bad then [15:15] <cehoyos> (And it makes a lot of sense afaict) [15:15] <Compn> anyone talk to x264 about this patch ? [15:15] <cehoyos> Why? [15:16] <Compn> just for fun i guess [15:16] <ubitux> cehoyos: the fact that some option are compatible with libx264 is a good thing [15:16] <cehoyos> The easiest and best thing imo would be to port the options from the Nvidia patch to the existing encoder [15:16] <ubitux> but that 90% of them are unusued... [15:16] <cehoyos> Sorry, then I misunderstood you [15:16] <Compn> is timo still around ? [15:16] <Compn> to maintain his nvenc ? [15:17] <wm4> BtbN: so why does v4l apparently include encoders and decoders? [15:17] <cehoyos> I understand your concern, I don't know what's the best solution [15:18] <Compn> as there is no technical reason to disallow the patch from being merged into the tree... commit it, emotional reasons be damned! [15:18] Action: Compn runs [15:19] <cehoyos> I believe a license issue is stronger than a technical issue, don't you agree? [15:19] <ubitux> there are both Compn [15:23] <BtbN> wm4, hm? [15:24] <BtbN> v4l is yet another api that hw de/encoders can support [15:26] <wm4> BtbN: that seems odd... well whatever [15:27] <nevcairiel> video apis on linux is a odd world [15:31] <BtbN> v4l is common for special hw encoder hardware. Like the encoders in tv tuner cards or capture cards. [15:31] <Compn> cehoyos : in the file that they arent asking us to distribute ? [15:31] <ubitux> Tim_G: adding flags to framecrc? i don't think that's a good idea [15:32] <ubitux> ah, you meant the shell function, meh, my bad [15:36] <Compn> ubitux : or what license issue ? [15:36] <Compn> bring it up on the list ? [15:36] <ubitux> i did [15:37] <Compn> hmm i maybe missing such email [15:42] <Compn> oh i see new email from you now [15:42] <Compn> :) [15:43] <Compn> that offhanded comment about the license was it ? [15:43] <Compn> harumph [15:44] <Compn> - There are still some license uncertainties about the licensing (see [15:44] <Compn> "die_license_disabled nonfree nvenc" in the configure) [15:44] Action: Compn cant help [15:44] Action: Compn gone [16:08] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:db0a52d611d7: avcodec/ituh263enc: Check den==0 in ff_h263_aspect_to_info() [16:08] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:827af242308e: avutil/rational: Check that av_reduce() returns values within the requested max [16:12] <aetasx> what was that x264 discussion about? I tried to go through but I think the point scrolled off the top of my chat buffer [16:13] <ubitux> all the option from libx264 encoder are copied in the libnvenc patch [16:13] <ubitux> but most of them are unused/have no effect [16:14] <aetasx> *shrugs* frankly if none of you guys know what the hell they do, I'd probably just leave them to x265-options to avoid confusion [16:14] <aetasx> err 4 [16:15] <aetasx> I mean one thing ffmpeg isn't lacking on is command-line flags [16:15] <ubitux> are you the author of the patch? [16:16] <aetasx> nah [16:17] <ubitux> http://pngmini.com/lossypng.html another filter suggestion [16:19] <aetasx> how does that have anything to do with png itself? can't you do that with any image format? [16:19] <aetasx> well, most [16:20] <ubitux> you can apply such filter to any image [16:20] <ubitux> it just make the png compression way more effective [16:21] <aetasx> yeah, it just reads like its some png-specific behavior though [16:25] <aetasx> so this is just the gui page for a few different libs? [16:26] <ubitux> yeah you need to dig a bit more [16:26] <ubitux> he made a package or something [16:26] <aetasx> yeah Im looking at https://github.com/pornel/pngquant/ [16:28] <aetasx> the lib code in here looks at least separated off from the png-specific stuff [16:32] <aetasx> where'd the request come in from? [16:35] <ubitux> i just came accross this [16:38] <aetasx> only thing I don't understand is why the lib is framed as being png-specific despite even it being called libimagequant [16:39] <aetasx> seems like it would just turn people away that might otherwise have a use for it [16:41] <aetasx> looks like hes got a sponsor for it, maybe you can squeeze some money out of them too ;) [19:01] <aetasx> Can someone comment on this for me? https://github.com/lachs0r/mingw-w64-cmake/commit/d3501226937629223d93a7367… [19:01] <wm4> aetasx: why don't you ask lachs0r [19:03] <aetasx> wm4: I don't need to. The behavior hes talking about does cause build failures. [19:03] <wm4> hopefully he reported it somewhere [19:04] <aetasx> I'm not sure, mingw had removed the requirement of having to have _POSIX defined in order to use localtime_r and gmtime_r a month ago and just recently added it back in so now some things are getting broken including wxWidgets [19:04] <aetasx> http://sourceforge.net/p/mingw-w64/mailman/message/33167130/ [19:05] <nevcairiel> mingw-w64 is driven by many morons, they do stupid things all the time [19:05] <wm4> wow that's a bad commit [19:05] <aetasx> I sort of got that impression when they started pushing out changes like that without any public dialog [19:05] <nevcairiel> although ffmpeg builds fine with the latest stable release for me, but i dont use their abomination of a pthread clone [19:06] <aetasx> Are you using a mingw from a release made after it the 19th or so? [19:07] <nevcairiel> if there was a very recent release, i may be on the previous stable still [19:07] Action: nevcairiel checks [19:07] <nevcairiel> 3.3.0 still seems to be the latest stable release, that works fine for me [19:08] <nevcairiel> but like i said, i dont use their pthreads dealy since in my experience its just broken [19:08] <wm4> I've written my own win32 pthread impl 2 days ago; unfortunately it just deadlocks [19:08] Action: wm4 has trouble to debug it [19:08] <nevcairiel> whats wrong with pthreads-w32 [19:09] <wm4> too GNU [19:09] <nevcairiel> working fine for me for a long time now [19:09] <nevcairiel> although i build ffmpeg with w32threads now [19:09] <aetasx> Im not sure, the change was made in the crt headers though, not in one of the threading implementations [19:10] <aetasx> you can't tell what the hell is going on considering nothing is documented on it [19:11] <aetasx> frankly if you're going to commit something that may have breaking-level changes, I would expect more of a commit message than "Adding these checks back in..." [19:20] <cehoyos> michaelni: There may be a bug in flv demuxer: https://trac.videolan.org/vlc/ticket/12389 [19:23] <aetasx> nevcairiel: Ill check out pthreads-win32. Still, you would think their own implementation would work with their own builds [19:27] <aetasx> cehoyos: no clue but I can say that I constantly work with really trashed flv files and a fair amount of them simply crash vlc out [19:46] <Tim_G> nevcairiel: IIRC pthreads-win32 is dead [19:46] <nevcairiel> dead or not, it works fine [19:47] <Daemon404> we could certainly benefit from a modern impl [19:47] <Daemon404> that doesnt cripple itself for the sake of XP [20:05] <wm4> most of pthreads maps quite well to vista+ APIs these days [20:07] <wm4> "someone" should collect all the hacks, and put them under a liberal license into a repo [20:07] <wm4> so every project can stop NIHing its own pthread wrapper [20:08] <aetasx> maintaining IE compatibility set internet tech back years on its own [20:21] <Daemon404> wm4, youd probably want something more like what mingw does [20:21] <Daemon404> 'public domain' [20:21] <Daemon404> not a license per se [20:22] <wm4> yeah [20:25] <nevcairiel> not every country follows the concept of public domain, so using something very liberal but still license-y like MIT might be clearer [20:25] <Daemon404> those still require you to reproduce author info [20:26] <Daemon404> mingw has some sort of explicit disavowing of all rights [20:26] <Daemon404> iirc [20:26] <nevcairiel> like gnu? :p [20:26] <Daemon404> ? [20:27] <nevcairiel> dont they make you give up any and all rights as well [20:28] <Daemon404> thats not what i meant [20:28] <Daemon404> i meant mingw's headers all say the author gives up all rights and use it however you want [20:28] <Daemon404> or something like that [20:29] <nevcairiel> german law makes that impossible, fwiw [20:29] <nevcairiel> i always retain the most basic rights to everything i create [20:29] <nevcairiel> unless i do it as part of my job, then the company has this right [20:29] <aetasx> you apparently don't have the right to give them away :p [20:30] <nevcairiel> its primarily designed so that artists can still protect their art from being defaced or something like that, even after the work was sold [20:31] <aetasx> sounds like one hell of an EULA [20:34] <nevcairiel> many countries seem to have similar provisions in copyright law [20:36] <aetasx> corporations are generally treated as people over here so they'd have to try and make some sort of exception [21:40] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:256df8a2fafa: libavformat/cdxl: fix duration in case of overflow [23:11] <cone-867> ffmpeg.git 03Carl Eugen Hoyos 07master:7905bd555573: Fix decoding for little endian Aja Kona 10-bit RGB. [00:00] --- Tue Dec 30 2014

1 0

ffmpeg.log.20141229
by burek 30 Dec '14

30 Dec '14

[02:01] <Wulf> hi [02:02] <Wulf> I want to periodically (few times per second) take pictures from my camera and them to a web browser where they can be watched as a movie stream. What would be the best way to implement this? [03:10] <chan1> hello, while compiling OpenCV, I got [03:12] <chan1> I tried configure --enable-pic and --extrac-cflags="-fPIC" but got same result. [03:12] <chan1> Can anybody give me a hint? [03:12] <chan1> \/usr/bin/ld: /usr/local/lib/libavcodec.a(vc1dsp_mmx.o): relocation R_X86_64_PC32 against symbol `ff_pw_9' can not be used when making a shared object; recompile with -fPIC [04:06] <pinkette> what does setting "h264 level" do? [04:24] <debianuser> Wulf: You can stream it with ffmpeg/ffserver as usual, just set output frame rate to 5, for example, for having 5 shots per second. :) [04:35] <debianuser> pinkette: http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels [04:41] <debianuser> chan1: /usr/local/lib/libavcodec.a? Maybe you need to rebuild your ffmpeg with -fPIC, not just OpenCV? [06:59] <chan1> debinauser:hi, I rebuilt ffmpeg with --enable-shared and the problem is gone! maybe without it, the .so file is not a shared library?.. [07:13] <visiot> can i control udp transmission rate while streaming [07:17] <kaotiko> RTCP :) [07:30] <visiot> while multicasting using ffmpeg i'm getting a jitter on my HQAM 40 to 60 ms [07:31] <visiot> i'm capturing screen [07:31] <visiot> if i use cvlc on the same i'm getting jitter of 1 to 3 ms only [07:31] <visiot> how can i reduce jitter size on ffmpeg [14:11] <AlexRussia> hey, what means things like that when i try convert mp3(native) to mp3(libmp3lame): [14:11] <AlexRussia> Error while decoding stream #0:0: Invalid data found when processing input [14:11] <AlexRussia> ? [14:13] <c_14> It means that your input is probably broken. [14:16] <AlexRussia> Sad [15:15] <abjinxed> can I build any ffmpeg version, to support 64 bit arm architecture? Or, Is there any particular version I need to use? [15:17] <abjinxed> I am trying to find from which version did ffmpeg started supporting 64 bit architecture. But could not find any info on that. [15:17] <c_14> try git master HEAD [15:33] <storrgie> I saw a recent post by the kodi team that they have upgraded ffmpeg so that they can play h265. I've got a ton of h264 content (ripped via makemkv), is there a simple way to convert to h265? I'm scared I'll screw something up in the conversion. [15:34] <c_14> Converting is simple, but it'll take forever. [15:34] <storrgie> thats fine [15:34] <storrgie> I have everything on a central server that has a big xeon on it, with 32g memory [15:35] <c_14> https://trac.ffmpeg.org/wiki/Encode/H.265 [15:36] <ribasushi> more importantly the conversion will be lossy (on top of the original h264 losses) [15:36] <storrgie> ribasushi, ahh i didnt think of that [15:36] <storrgie> ribasushi, I'd be better off going from source material then [15:37] <ribasushi> this is (for better or worse) always the case with encoding [15:37] <ribasushi> errr lossy encoding [15:37] <storrgie> ribasushi, actually in reading a bit. it looks like makemkv doesn't re-encode when it does the rip [15:38] <c_14> ye, makemkv just dumps whatever's on the source into a file [15:38] <storrgie> ribasushi, http://www.makemkv.com/forum2/viewtopic.php?f=1&t=8338 [15:38] <storrgie> c_14, yeap [15:38] <storrgie> so I could even h264 this stuff to get a large reduction in filesize [15:39] <c_14> Technically you'd want to encode from the master, but getting your hands on those isn't easy. [15:40] <storrgie> I am now not sure what I'll do [15:40] <storrgie> I wanted to tamp down my increasing storage needs by using h265 [15:40] <storrgie> but I was under the impression I was already using h264 [15:41] <storrgie> now that I realize I've mostly got the raw stream, I would have to do some testing to see if I notice anything visually [15:41] <storrgie> I keep all my music in flac, it seems like I'd be a poseur to lossly encode the video streams [16:05] <miburi> hi has anyone ever successfully installed ffmpeg with libopenjpeg before? [18:56] <Fjorgynn> TIRED I AM [18:57] <tacpilot> I have linux ffmpeg compiled and installed with libx264-dev .. turns out i need the x264-10b and have downloaded the current binary.. how to point to x264 and not libx264 ? [19:00] <tacpilot> if is just a CL option just a simple example command would be awesome [19:01] <__jack__> by x264, you mean the command line executable ? [19:03] <tacpilot> yes [19:04] <__jack__> it is useless for a pure ffmpeg usage, you need the lib; however, you can still pipe raw video from ffmpeg to x264 [19:05] <__jack__> something like this: ffmpeg -i blabla -f yuv4mpegpipe - | ./x264 -o blabla - [19:05] <tacpilot> been digging around for a while and with every thing i fing the relation between x264 - ffmpeg - libx264 is really gray [19:07] <__jack__> libx264 is a shared library, this means every program, if compiled & linked with, can use it. It's responsible for encoding, decoding, all "x264" stuff; x264 is a command line binary, it uses the libx264, and add cli stuff (parsing args etc etc); ffmpeg can also use the libx264 for encoding, and will add different stuff: multiplexing, decoding, muxing etc etc [19:07] <__jack__> you cannot use a lib as-is [19:10] <tacpilot> i would really prefer ffmpeg to use the 10 bit internally .. the info here recommends getting x264 from https://www.ffmpeg.org/general.html#x264 .. am guessing installing from source provides libs for ffmpeg rather than just grabbing the binary ? [19:10] <jarainf> You need to compile libx264 in 10bit mode and pull it into ffmpeg [19:12] <tacpilot> IC .. if i uninstall the libx264-dev from repos and compile and install in 10 bit mode from source .. will i need to recompile ffmpeg to utilize the new libs ? [19:13] <__jack__> yup [19:13] <tacpilot> will do .. TY All [20:48] <olvdi> i am trying to record audio from a computer and get a stream of the mp3 data to send over an application of my own, so i have this: http://pastebin.com/gXxSzt1M [20:49] <olvdi> i have no idea on how to go around to fix that, any help any direction is useful [20:50] <c_14> add -stdin as an option [20:54] <olvdi> ffmpeg.exe -f dshow -i audio="My mic" -f s161e -acodec libmp3lame -stdin - [20:54] <olvdi> is that what u meant? [20:54] <c_14> you can put it wherever [20:54] <c_14> and maybe replace - with pipe:1 [20:55] <c_14> though that's just because I think it's cleaner [20:56] <olvdi> i need stdout and stdin [20:56] <c_14> hmm? [20:56] <olvdi> with pipe:1 [20:57] <c_14> pipe:1 is stdout [20:57] <olvdi> yeah [20:57] <olvdi> i need stdin and stdout [20:57] <olvdi> so pipe:1 will only give me stdout ... right? [20:57] <c_14> You can't output to stdin [20:59] <olvdi> with -stdin i get the conversion failed randomly btw [20:59] <c_14> what's your current cmdline ? [21:01] <olvdi> '-f', 'dshow','-i','audio=Microphone (Webcam C170)','-f', 's16le','-acodec', 'libmp3lame','-stdin','pipe:1' [21:02] <c_14> and the error ? [21:03] <olvdi> conversion failed [21:03] <olvdi> av_interleaved_write_frame(): Invalid argument [21:06] <olvdi> can i get this issue due to being unable to write to buffer? [21:07] <c_14> That's the default something broke error. Can you pastebin the complete console output? Everything on stderr? [22:15] <miburi> anyone have any idea how to fix the "undefined reference to opjXXX" issues when trying to compile and make ffpmeg with openjpeg? [22:16] <miburi> which is within the libopenjpeggenc.c file "ffmpeg-2.5.2/libavcodec/libopenjpegenc.c:266: undefined reference to `opj_destroy_compress'" [22:57] <Eryn_1983_FL> hey peeps how do i convert rm to mpeg or mp4? [23:00] <Eryn_1983_FL> i got it ffmpeg -i foo.rm -vcodec mpeg4 -sameq -acodec libfaac -ab 94208 foo.mp4 [23:05] <SirDarius> Eryn_1983_FL: I would rather use something like ffmpeg -i foo.rm -c:v libx264 -crf:v 20 -c:a libfaac -b:a 96k foo.mp4, because -sameq is probably not what you want (https://ffmpeg.org/faq.html#Why-was-the-ffmpeg-_002dsameq-option-removed_00…) [00:00] --- Tue Dec 30 2014

1 0

ffmpeg-devel.log.20141228
by burek 29 Dec '14

29 Dec '14

[00:03] <JEEBsv> uhh, I don't think the handler is meant for that kind of data :s [00:04] <JEEBsv> although I don't remember the definition in the spec [00:04] <nevcairiel> many things abuse it for track titles [00:04] <nevcairiel> but technically its supposed to have a technical meaning [00:04] <JEEBsv> yes [00:04] <nevcairiel> not sure what the actual track title atom was in mov/mp4 [00:07] <Zeranoe_> nevcairiel: that does seem to work, for the audio handler_name. I'll have to experiment to get it to work for subtitles [00:07] <JEEBsv> l-smash seems to have itunes title metadata [00:07] <nevcairiel> it should work the same way, use -metadata:s:s for the subtitle stream, or use integer indexes for individual stream numbers [00:08] <JEEBsv> not track-specific it seems [00:08] <JEEBsv> although I'm not sure of the details [00:09] <nevcairiel> well if the format itself would truely lack such a feature, no wonder people abuse the handler for that [00:09] <JEEBsv> yeah, track options in L-SMASH are: fps/language/handler [00:09] <muken> mp4 has no track title atom. mov and 3gpp have though [00:11] <Zeranoe_> nevcairiel: Bingo, s:s did it. Thank you [00:24] <Tim_G> ubitux: mail client problem [01:08] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n0.11-dev': unknown revision or path not in the working tree. [01:08] <cone-963> Use '--' to separate paths from revisions [01:08] <cone-963> refs/tags/n0.11-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf' [01:08] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n0.12-dev': unknown revision or path not in the working tree. [01:08] <cone-963> Use '--' to separate paths from revisions [01:08] <cone-963> refs/tags/n0.12-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf' [01:08] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n1.1-dev': unknown revision or path not in the working tree. [01:08] <cone-963> Use '--' to separate paths from revisions [01:08] <cone-963> refs/tags/n1.1-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf' [01:08] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n1.2-dev': unknown revision or path not in the working tree. [01:08] <cone-963> Use '--' to separate paths from revisions [01:08] <cone-963> refs/tags/n1.2-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf' [01:08] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n1.3-dev': unknown revision or path not in the working tree. [01:08] <cone-963> Use '--' to separate paths from revisions [01:08] <cone-963> refs/tags/n1.3-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf' [01:08] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.1-dev': unknown revision or path not in the working tree. [01:08] <cone-963> Use '--' to separate paths from revisions [01:08] <cone-963> refs/tags/n2.1-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf' [01:08] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.2-dev': unknown revision or path not in the working tree. [01:08] <cone-963> Use '--' to separate paths from revisions [01:08] <cone-963> refs/tags/n2.2-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf' [01:08] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.3-dev': unknown revision or path not in the working tree. [01:08] <cone-963> Use '--' to separate paths from revisions [01:08] <cone-963> refs/tags/n2.3-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf' [01:08] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.4-dev': unknown revision or path not in the working tree. [01:08] <cone-963> Use '--' to separate paths from revisions [01:08] <cone-963> refs/tags/n2.4-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf' [01:08] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.5-dev': unknown revision or path not in the working tree. [01:08] <cone-963> Use '--' to separate paths from revisions [01:08] <cone-963> refs/tags/n2.5-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf' [01:25] <ubitux> lol [01:33] <cone-963> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.6-dev': unknown revision or path not in the working tree. [01:33] <cone-963> Use '--' to separate paths from revisions [01:33] <cone-963> refs/tags/n2.6-dev:HEAD: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf' [01:37] <jamrial> michaelni: you typoed the description of the n2.6-dev tag :p [01:42] <michaelni> j-b, can you force push a n2.6-dev tag with "2.4" replaced "2.5" ? [01:42] <michaelni> in the commit message [01:43] <michaelni> that is what the following would generate git tag -m 'Main development, master branch after release/2.5 branched off' -a -f n2.6-dev f478bdabf2afcd5f709789347f8a3becc4ff17bc [01:44] <michaelni> i cant fix it myself as "git push origin n2.6-dev -f" gives ! [remote rejected] n2.6-dev -> n2.6-dev (hook declined) [01:58] <cone-963> ffmpeg.git 03Michael Niedermayer 07master:c263102298ec: avcodec/vdpau: fix assertion failure and < vs > error [02:55] <cone-963> ffmpeg.git 03Simon Thelen 07master:cc63da1223da: ffmpeg: add sdp_file option [03:04] <cone-963> ffmpeg.git 03Michael Niedermayer 07master:627f5658b68f: ffmpeg: Use av_freep(), avoid leaving stale pointers in memory [12:51] <anshul__> is there already some function to convert int to string or should I use sprintf [12:54] <anshul__> i got its av_d2str [14:20] <ubitux> a8eb52a8c32536a1b93bebe2d0372edf1a520501 anyone knows why? [14:53] <BBB> ubitux: because pthread is the standard api used for threading code? [14:54] <ubitux> i don't know; aren't semaphore also posix standardized? [14:59] <aetasx> yeah [15:02] <aetasx> I was waiting for testdisk to finish running last night which takes forever and came across a National Geographic special with possibly the worst name ever [15:08] <ubitux> ==31803== ERROR SUMMARY: 4302161 errors from 45 contexts (suppressed: 394 from 96) [15:09] <wm4> ubitux: uh well it uses mutexes and condvars instead of semaphores? [15:09] <ubitux> i really wonder by what miracle we don't see any problems [15:09] <ubitux> wm4: yes; the question is why is it more appropriate [15:09] <wm4> ubitux: or something else? [15:09] <wm4> well semaphores can be slower, I guess [15:09] <wm4> and OSX doesn't implement them [15:09] <ubitux> (it's a naive question from someone who has not much clue) [15:09] <ubitux> ok [15:09] <wm4> (despite OSX being POSIX certified, hurr) [15:10] <wm4> it also might be that the code is simpler after that change, but I didn't check if that's the case [15:11] <ubitux> you sure it's not available on osx? [15:12] <rcombs> it's a bit shorter after the change; dunno about simpler per se [15:12] <rcombs> (not reading all that right now) [15:13] <wm4> ubitux: very sure [15:13] <wm4> OSX has named semaphores, but not normal ones [15:13] <ubitux> ok [15:31] <akira4> ubitux, would you please have a look at this diff if you're free? http://pastebin.com/5BA4MKm5. [15:31] <ubitux> gonna look at this, give me an hour [15:31] <akira4> sure. thanks [15:32] <aetasx> ubitux: did you ever decide whether you're going to merge read and nav together? [15:33] <ubitux> that's not up to me [15:33] <ubitux> i'm not a libdvd* dev at all [15:34] <aetasx> fork it then ;) [15:35] <ubitux> i already have my quota of insane things to deal with [15:36] <aetasx> whats your primary role around here anyway? [15:38] <aetasx> like what all areas do you work on [15:40] <ubitux> goldbricking maybe [15:41] <iive> libdvd is so forked it is quite troublesome to find what version is currently in development. [15:41] <wm4> iive: simple, the videolan one [15:41] <aetasx> how dare you make me look up a slang term [15:42] <ubitux> more seriously, my current projects wave between (mainly text) subtitles, mov edit list, nlmeans filter, mentoring the dvd stuff [15:42] <ubitux> i'm having troubles getting some shit done thought [15:42] <iive> also, DonDiego seems to have abandoned libav and moved to libdvd in vlc, so expect a lot of puzzling cleanups. [15:42] <aetasx> to be fair, holidays aren't really the time when things get done anyway [15:43] <ubitux> well, that's actually the best opportunity to get things done [15:43] <iive> depends... on whenever you code in your work or free time. [15:43] <aetasx> or you have any interest in being around your family [15:44] <ubitux> (ah, and i started looking again at why helgrind is complaining so much, but i hate threading so much to look at this peacefully) [15:45] <ubitux> no fuck given for my family; this is my free time, i'm definitely not going to share a single second for them :p [15:45] <wm4> why hate threading [15:45] <aetasx> I wouldn't want to deal with it specifically in as far as encoding goes at least. Trying to figure out how best to dish out frames seems like a nightmare [15:46] <ubitux> wm4: mainly because of my ineptitude & confusion :) [15:46] <ubitux> wm4: i just don't like the idea of being unable to know if i'm doing anything wrong with the current state of ffmpeg regarding threading [15:46] <ubitux> and that's kind of frustrating [15:47] <ubitux> i mean, try something as simple as valgrind --tool=helgrind ./ffmpeg_g -nostats -i ~/fate-samples/utvideo/utvideo_rgb_median.avi -f null - [15:47] <ubitux> and see the shitstorm [15:47] <ubitux> most of it is related to the state variable in pthread_frame.c, so i'm assuming we're kind of doing something somehow undefined around here [15:48] <ubitux> there are many other issues, but they're (partly) hidden because of this one [15:49] <aetasx> thats one of the reasons why I usually am hesitant to get too deeply involved in things in general [15:49] <aetasx> get worried about if something is the way it is for a specific reason [15:49] <ubitux> it's in the way because it prevents from using these tools when adding threading elsewhere [15:50] <ubitux> and it's also annoying because it's wasting resources (kind of entirely my fault here thought); we have instances with drd, helgrind and tsan [15:50] <ubitux> but they are vomitting so much errors, the relevant ones are lost in it [15:51] <ubitux> and all of them take a lot of time to process [15:51] <ubitux> (a fate run of helgrind takes several hours typically) [15:51] <aetasx> jesus [15:52] <ubitux> we were forced to drop the details from the main fate page too [15:52] <ubitux> because a report is several GB in size [15:53] <aetasx> are all those lines unique though? can't you just prune dups out of it? [15:53] <ubitux> -rw-r--r-- 1 ux ux 3.3G Dec 28 10:16 fate/x86_64-archlinux-gcc-valgrind-threads/report [15:53] <ubitux> -rw-r--r-- 1 ux ux 2.3G Dec 28 15:14 fate/x86_64-archlinux-gcc-valgrind-drd/report [15:53] <wm4> ah I see a "volatile" in the code [15:54] <wm4> it's probably evil code [15:54] <ubitux> aetasx: or we could fix the code... [15:54] <aetasx> sounds like libav sabotage to me [15:54] <aetasx> :p [15:54] <wm4> ubitux: do you have some example error report? [15:55] <wm4> just so I can take a look and give up [15:55] <aetasx> I bet it'll at least compress pretty well [15:55] <ubitux> wm4: http://fate.ffmpeg.org/report.cgi?time=20141228091535&slot=x86_64-archlinux… i guess [15:55] <ubitux> try "stderr" on any of the test [15:57] <wm4> why are there failed audio tests? [15:57] <ubitux> probably because of the threaded demuxing or something [15:57] <ubitux> (you know, for multiple inputs) [15:58] <wm4> interesting [15:58] <ubitux> actually [15:58] <wm4> the page is very slow [15:58] <ubitux> that might just be because of threaded frame decoding [15:58] <ubitux> so it still the same thing [15:58] <wm4> and crashed firefox (what= [15:58] <ubitux> wm4: report is 3G+ [15:58] <aetasx> you miss the part where it was 3gb? [15:59] <ubitux> note: a normal report is around 10M [15:59] <ubitux> tsan is the smallest of the 3: 429M [16:00] <wm4> also this page uses javascript shit [16:00] <wm4> so you can't actually click on "stderr" [16:00] <wm4> because it needs JS [16:00] <wm4> which also means you can't just wget it or so [16:01] <wm4> maybe you have to wait until the page has loaded [16:01] <wm4> ... [16:01] <aetasx> I'd pull it up and look at a way of doing it but Ill pass on the 3gigs [16:01] <ubitux> lavf-mov test is fun [16:01] <aetasx> doubt any browser could survive that [16:01] <ubitux> ==11772== ERROR SUMMARY: 1269306 errors from 890 contexts (suppressed: 1098 from 89) [16:02] <ubitux> you can also just run the command i gave earlier if you want a random output [16:02] <ubitux> i mean, almost any fate test is triggering the problem [16:05] <aetasx> was it always like this? [16:06] <ubitux> yes [16:06] <ubitux> i think nicolas fixed the threaded demuxed part [16:06] <ubitux> iirc something like 70 out of the 2k+ tests got better [16:07] <ubitux> but since one of the main core threading code make these tools choke [16:07] <aetasx> I'll have to wait like a couple hours for testdisk to fix my stupidity before I can look at any of those [16:07] <ubitux> most of the tests triggers the flood [16:07] <wm4> ubitux: haha, looking at the first reported data race, helgrind seems to be right [16:07] <wm4> it's about accessing something called p->state [16:07] <ubitux> yes [16:08] <wm4> which at one point is accessed under a progress_mutex held, but in another place at the code without [16:08] <ubitux> yeah that's what i observed as well [16:08] <ubitux> but the whole thing is generally protected by "mutex" [16:08] <ubitux> which frame the whole function generally [16:08] <ubitux> so i don't know [16:08] <ubitux> i'm having a hard time what's going on here honestly [16:09] <ubitux> if we can shut up these warnings, i'm pretty sure we can shut up most of the helgrind complains [16:10] <ubitux> it's also strange to me to see waiting loop around condition variables [16:10] <wm4> actually reading the code, this is some sort of double-checked locking [16:10] <wm4> if (p->state != STATE_INPUT_READY) { [16:10] <wm4> pthread_mutex_lock(&p->progress_mutex); [16:10] <wm4> while (p->state != STATE_INPUT_READY) [16:10] <ubitux> yes [16:10] <wm4> pretty sure this is a bad idea [16:11] <ubitux> and you have a pthread_mutex_lock() on p->mutex, framing the whole function (sometimes.) [16:11] <wm4> in this particular case, removing the outer if should fix it [16:11] <ubitux> honestly, feel free to send patches for this [16:14] <aetasx> whats setting p->state to break out of that loop in that example? [16:16] <aetasx> seems odd to see it start blocking on the mutex and then get out of it and go right back into waiting on something else again [16:17] <wm4> another thread [16:18] <wm4> condition variables [16:18] <aetasx> to account for any sort of race condition between when the thread unlocks the mutex? [16:20] <aetasx> Im still waiting on my drive repair so I'm somewhat blind as far as looking up the related code [16:20] <aetasx> thank god for testdisk though [16:21] <Compn> what size disk are you testing aetasx ? [16:22] <aetasx> 1TB raid array [16:23] <aetasx> was moving a partition around and it failed mid-way so I used it to find the partitions got lost [16:25] <aetasx> that tool beats out any form of commercial stuff I've tried to use. the only ones that let you really work with them at a low level are all linux tools [16:33] <wm4> ubitux: there are several places where p->state is (apparently) intentionally accessed without mutex, so I'm not very confident about moving them in [16:36] <wm4> hm code was authored by Alexander Strange [16:38] <iive> that should be beastd [16:39] <ubitux> astrange ` beastd [16:42] <ubitux> akira4: ok so [16:43] <ubitux> afaict, the libdvd*, even dvdread, is actually really low level [16:43] <ubitux> and don't even give you information on the stream themselves [16:44] <ubitux> akira4: did you branch out master with the original patch from Stefano? [16:44] <ubitux> and check what you can get from it [16:57] <iive> ops. mybad [17:03] <wm4> <ubitux> and don't even give you information on the stream themselves <- they probably give you what's in the dvd on-disk structures, but don't parse the mpeg streams themselves (maybe) [17:04] <ubitux> yeah i mean, it doesn't seem to provide enough abstraction to create an AVPacket from it [17:04] <ubitux> like, it doesn't seem trivial to create the streams yourself from the info the libs give you, and map the data you get from the lib to your AVPackets [17:05] <ubitux> like i initially though [17:05] <ubitux> +t [17:06] <wm4> mapping the mpeg streams to what dvdread provides can be messy, yes [17:07] <ubitux> so the protocol might actually be the way to go [17:07] <wm4> you have to map them anyway at some point [17:08] <ubitux> are dvd always mpeg2 with ac3? [17:08] <wm4> no [17:08] <nevcairiel> they can be mp2 audio, or even dts [17:08] <nevcairiel> but its super rare [17:08] <wm4> I think there are dvds with pcm too [17:08] <ubitux> still possible then [17:08] <nevcairiel> oh yeah pcm too [17:08] <nevcairiel> even a special pcm_dvd codec in avcodec [17:11] <ubitux> so yeah, "protocol" is the way to go [17:11] <BBB> the state accesses suppose that integers are atomic [17:11] <BBB> that is not guaranteed in c, although it happens to be true on most archs, e.g. x86 [17:12] <BBB> feel free to change them to atomic ints if you want to be c compliant [17:12] <ubitux> don't we have an atomic api for that? [17:12] <BBB> we didnt back then when he wrote it [17:13] <BBB> a lot of opensource programmers think that writing a lib or api solves all problems; it only does, if you port all software to use the new api/lib [17:13] <wm4> BBB: is there any reason not just to access this state under a mutex? [17:13] <BBB> too much overhead [17:14] <BBB> grabbing a mutex is actually a really heavy operation, and these are called per macroblock [17:14] <BBB> try it, I saw a patch doing that when I worked on chrome [17:14] <BBB> someone using some automatic tool found the errors [17:14] <BBB> I think it was 5-10% slower [17:15] <BBB> and so I recommended they dont even try to push that patch upstream, because why waste your time and energy on something pointless [17:15] <ubitux> don't we already have mutexes around most state accesses? [17:15] <BBB> nobody wants to lose 5-10% performance for no benefit other than making helgrind happy [17:15] <wm4> BBB: what if it finds new bugs in turn [17:15] <BBB> then do it only when running udner that tool [17:15] <BBB> which is very dangerous in itself [17:16] <BBB> as soon as you get a tool to run different code than what the user runs& the tool becomes useless in finding actua errors in that code [17:16] <BBB> (its one of the reasons I dont like our bitexact flags) [17:17] <BBB> (in fate) [17:17] <ubitux> using the atomic api should be a no-op with most compilers, right? [17:17] <nevcairiel> i think there is actually different instructions that get used [17:18] <BBB> with atomic, yes [17:18] <BBB> ubitux: yes [17:18] <ubitux> and if we use this atomic api, can we get rid of all the mutexes dance in this file? [17:18] <ubitux> "all" is a bit much [17:19] <ubitux> let's say "a lot of" around state [17:19] <nevcairiel> if all its used for is to access a single state variable, possibly [17:19] <ubitux> the progress ones seems to be related to that [17:19] <ubitux> but i can't tell; state seems protected by both p->mutex and p->progress_mutex [17:20] <ubitux> but not properly all the time apparently [17:20] <nevcairiel> lock-free thread interaction gives me headaches though [17:20] <ubitux> :confuse: [17:20] <BBB> particular transitions are protected by different mutexes [17:20] <BBB> iirc [17:24] <akira4> ubitux, so then what do I do? I have the patch but I haven't branched master and applied it. [17:25] <ubitux> akira4: try to do that, it will be useful whatever you do later [17:25] <ubitux> like, try to make that patch work [17:25] <akira4> okay. I'll do that. Did you try to read and ISO file with the diff I gave ? [17:25] <akira4> *an [17:26] <ubitux> no; it works? [17:26] <akira4> I get a segfault when the playback stops. I can't figure out why. [17:27] <ubitux> i'm looking at the original dvd patch currently (trying to apply it myself) [17:27] <ubitux> to check a bit more what you'll need to do on it [17:27] <ubitux> assuming we use it as a base [17:36] <ubitux> akira4: the patch seems to "work" for me [17:36] <ubitux> https://github.com/ubitux/FFmpeg/compare/dvdprotocol [17:37] <ubitux> it crashes randomly, isn't able to seek, doesn't see any subtitles stream, but... it somehow playbacks things [17:37] <akira4> hmmm.. [17:38] <akira4> so then I'll try fixing this patch then ( I guess ?) [17:42] <akira4> ubitux, I get some errors when trying to apply the patch. Its the patch that you gave the link to right? [17:43] <ubitux> you should have no problem applying the patch from the branch i just pasted [17:43] <ubitux> git remote add ubitux git@github.com:ubitux/FFmpeg.git [17:43] <ubitux> git fetch ubitux [17:44] <ubitux> go into your branch, and git cherry pick ubitux/dvdprotocol [17:44] <ubitux> should do it [17:44] <akira4> okay. thanks [17:47] <ubitux> you should probably drop the self alloc and stuff [17:49] <ubitux> which fixes the crash for me [17:49] <ubitux> but i still see no subtitles stream [17:52] <ubitux> anyway, try to play with this [17:55] <akira4> okay. [18:12] <cone-53> ffmpeg.git 03Michael Niedermayer 07master:3b1f747238d6: avfilter/vf_cropdetect: add max_outliers parameter [18:26] <akira4> ubitux, I tried the patch. In my case the video plays abruptly but I see the subtitles .And what about the DVD input device then ? [18:28] <ubitux> what's your ffprobe output? [18:28] <ubitux> the input device might not be the best decision since libdvd* are too low level [18:30] <akira4> well, the ffprobe gave some errors because of some missing parameters first. When I tried to read the data packets I got a segfault. [18:30] <akira4> so basically everything was going wrong :'( [18:33] <akira4> I was hoping that if I could resolve the segfault problem then maybe I could get a proper ffprobe output. [18:37] <ubitux> 17:47:59 <@ubitux> you should probably drop the self alloc and stuff [18:37] <ubitux> 17:49:12 <@ubitux> which fixes the crash for me [18:38] <JEEBsv> fun times with AAC broadcasts https://fushizen.eu/u/jeeb/out-intare.ts [18:39] <JEEBsv> (the 5.1 part seems borked) [18:41] <akira4> ubitux, I'm not sure what you meant by self alloc? [18:41] <ubitux> BBB: the atomic get is a no-op, but the atomic set calls mfence on here on x86 [18:41] <ubitux> akira4: the allocation of the local DVD context [18:41] <ubitux> akira4: what you removed in your patch a few days ago [18:42] <nevcairiel> set has to use a memory barrier to avoid simultaneous writes on different cores [18:42] <ubitux> so in practice it's actually necessary [18:43] <ubitux> but only for write [18:43] <nevcairiel> thats on x86 anyway, other systems may require something for get as well [18:46] <cone-53> ffmpeg.git 03Michael Niedermayer 07master:beaea2de61c8: avdevice/dv1394: Use av_freep() to avoid leaving stale pointers in memory [18:46] <cone-53> ffmpeg.git 03Michael Niedermayer 07master:a3f6e8c4d926: avdevice/dshow: Use av_freep() to avoid leaving stale pointers in memory [18:46] <cone-53> ffmpeg.git 03Michael Niedermayer 07master:9c3a8693a20d: avdevice/dshow: Remove unneeded NULL checks [18:51] <akira4> ubitux, regarding the ffprobe o/p I was talking about my patch not Stefano's patch. [18:51] <ubitux> focus on stefano's one [18:53] <akira4> alright. [19:11] <ubitux> http://pastie.org/pastes/9802400/text [19:11] <ubitux> BBB, nevcairiel ^ [19:12] <ubitux> so on arm at least, both read and write aren't atomic [19:12] <ubitux> so the current code could fail there, right? [19:12] <nevcairiel> fail is a relative term, it may be more vulnerable to race conditions [19:13] <ubitux> yes [19:13] <ubitux> so it basically means it's not reliable [19:20] <wm4> I think the current code relies that the writes get through eventually [19:20] <wm4> which might be true? [19:21] <BBB> you guys miss the important questions [19:21] <BBB> a) does it fix an actual, real issue [19:21] <BBB> b) is it slower [19:21] <BBB> depending on a trade-off between these two, the patch may or may not be acceptable [19:22] <wm4> who can really answer a)? [19:24] <BBB> well, why are you workign on this [19:24] <BBB> it suggests youre trying to implement a feature requestor fix a reported bug [19:24] <BBB> right? [19:24] <BBB> or did you just stumble on the code and you couldnt stop wondering whether there was a race condition and it lead to this discovery? [19:24] <BBB> or did you trust helgrind or related tools? [19:25] <BBB> or something else? [19:42] <ubitux> BBB: the real issue is that it this potential issue is hidden many potential other issues and make these tools useless [19:42] <ubitux> just like 999 uninitialized read with no visible consequences could hide 1 real one [19:43] <ubitux> i'm not familiar enough with the code to know what to do to show the issue; like, i could add some sleep randomly [19:43] <ubitux> i would need to test on arm instead of x86 [19:43] <ubitux> or such thing [19:43] <ubitux> which is hard to test [19:47] <ubitux> it's really annoying to not be able to know if we aren't doing anything wrong when writing threading code [19:47] <ubitux> and i consider this a real issue and hindrance in development [19:48] <ubitux> now of course the performance issue is a concern [19:49] <ubitux> but closing our eyes until it explodes doesn't look like the appropriate approach :p [19:51] <wm4> sometimes debugging tools produce far more false positives than useful results [19:51] <wm4> don't know if helgrind is such a tool, though [19:54] <ubitux> well [19:55] <ubitux> wheither it's tsan, drd or helgrind [19:55] <ubitux> they all complain a lot about the same thing [19:55] <wm4> heh [19:56] <ubitux> btw [19:56] <ubitux> using atomics for every state access doesn't help [19:56] <ubitux> it still complains [19:57] <wm4> well it doesn't know that these are atomics [19:57] <wm4> (probably) [19:57] <wm4> especially if the atomic access compiles to the same code as non-atomic [19:58] <BBB> ubitux: tsan is helgrind [19:58] <BBB> ubitux: its the same tool [19:59] <BBB> (I know thats weird, but I asked the author once and he said its basically helgrind) [19:59] <ubitux> ok [19:59] <BBB> so... [19:59] <BBB> I know that for atomics, helgrind has special accessors [20:00] <BBB> basically macros that mark them as HI I AM AN INVALID ACCESS ACCORDING TO THIS RETARDED TOOL, BUT ITS OK SO PLEASE DONT SAY ANYTHING [20:00] <wm4> so it substitutes its own stdatomic.h? [20:00] <BBB> if you hook these up in libavcodec(?)s atomic code, they should go away [20:01] <BBB> we already have separate implementations for gcc and msvc and anything else" [20:01] <BBB> this would just be another implementation [20:01] <BBB> but anyway, if you use these special accessors, the warnings do go away for that once tool [20:01] <BBB> s/once/one/ [20:02] <BBB> if you have a real threading bug, Id love to have a look, I love these bugs [20:02] <BBB> that reminds me I should writeup my libswresample optimizations at some point on my blog [20:12] <ubitux> ok so, adding atomic get/set for p->state and p->die, and forcing HAVE_ATOMICS_NATIVE to 0 make all the issues go away with the random command line i tried [20:12] <ubitux> but now i'm trying with a h264 video [20:13] <ubitux> and i get many others [20:13] <ubitux> http://pastie.org/pastes/9802491/text such as this [20:16] <cehoyos> BBB: Isn't this a threading bug? http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-threads [20:24] <BBB> not a race condition [20:24] <BBB> I can fix it if you want, but I dont work on hevc much so far [20:28] <cehoyos> I am just wondering because it only happens on one machine... [20:32] <Zeranoe> Am I correct to assume that libshine uses some lame components and it's either one or the other in a build? [20:34] <Zeranoe> and if that is the case, which should be included in the Windows builds? [20:37] <cehoyos> Definitely lame. [20:40] <cone-53> ffmpeg.git 03Simon Thelen 07master:750b10ff85d4: doc/ffmpeg.texi: document the new -sdp_file option [20:48] <cehoyos> Did anybody ever test "AJA Kona 10-bit RGB Codec"? Is it really likely that there is a difference between "R10k" and "r10k"? [21:44] <cone-53> ffmpeg.git 03Carl Eugen Hoyos 07master:6a6a0620e2f8: Fix R10k blue channel output. [22:00] <ubitux> http://ubitux.fr/pub/pics/_the-simple-formula.png [22:01] <ubitux> mathematicians know how to make you feel dumb [22:01] <cone-53> ffmpeg.git 03Pedro E. M. Brito 07master:202947a0665e: libavformat/segment.c: Add strftime expansion for segment filename templates [22:42] <kierank> av500: http://events.ccc.de/congress/2014/Fahrplan/events/6156.html [22:42] <kierank> quite interesting [23:15] <kierank> michaelni: can the interlaced flag just be set to default in the scale filter? [23:25] <michaelni> maybe [23:30] <Daemon404> ubitux, is that from wikipedia? [23:30] <Daemon404> they just really like to wank over eq'ns [23:30] <ubitux> no, "the" paper [23:31] <Daemon404> well, >academic papers [23:31] <Daemon404> must make it as inpenetrable as possible [23:44] <kierank> 10:25 PM <"michaelni> maybe --> ? [00:00] --- Mon Dec 29 2014

1 0

ffmpeg.log.20141228
by burek 29 Dec '14

29 Dec '14

[00:08] <lm_> c_14 [00:08] <lm_> how convert m4a for mp3 in mint using ffmpeg and lame? [00:09] <c_14> https://trac.ffmpeg.org/wiki/Encode/MP3 [01:11] <shevy> how do you designate output file again? ffmpeg -o test.vi ? [01:11] <shevy> *test.avi [01:14] <t4nk263> hello! why could avcodec_decode_video2 not to return got_picture_prt as 1? [01:38] <debianuser> shevy: ffmpeg syntax is like: ffmpeg <infile1 options> -i infile1.ext ... <infileN options> -i infileN.ext <outfile options> outfile.ext [01:41] <shevy> hmm ok so there is no special format indicator like -o there, we will simply take the last argument instead [01:48] <shevy> hmm [01:52] <t4nk263> exactly [02:33] <shevy> it's a bit late here, my eyes are getting tired [02:33] <shevy> does one of you guys spot the error? [02:33] <shevy> ffmpeg -i test.mp3 -ss 00:00:11.000.000 [02:34] <shevy> ffmpeg tells me [02:34] <shevy> Invalid duration specification for ss: 00:00:11.000.000 [02:40] <klaxa> omit the last .000 [02:40] <klaxa> i don't think there are nanoseconds in timestamps [02:40] <shevy> ok [02:41] <shevy> that worked, thanks; my script had an error apparently, appending an extra '.000' [03:08] <t4nk263> anyone? [03:57] <echelon> does ffmpeg preserve the aspect ration, height/width when doing a simple conversion? [03:59] <echelon> i forget :/ [04:04] <Zeranoe_> echelon: yes, it should [04:06] <echelon> ok cool, thanks [05:22] <sergio-br2> hello [05:22] <sergio-br2> I'm trying to build 2.4.5 [05:22] <sergio-br2> and I got this: ../libavutil/utils.c:30:33: fatal error: libavutil/ffversion.h: No such file or directory [05:23] <sergio-br2> there is no ffversion.h in libavutil [05:56] <pinkette> damn x265 is slow to encode.. is this normal [06:03] <klaxa> yes [06:15] <pinkette> is this true sse4 helps with x265 ? [06:25] <klaxa> probably? special purpose hardware usually is faster than software implementations [06:25] <klaxa> x265 will still be slow [06:25] <klaxa> it's pretty new [06:25] <klaxa> i don't think people really use it for productive stuff yet [06:26] <klaxa> unless they have access to hardware encoders and decoders [06:31] <pinkette> does sse4 only help x265 or does it help x264 too [06:39] <klaxa> http://forum.doom9.org/showthread.php?t=133567 [07:47] <pinkette> what is better player mpc-hc or mpc-be ? [11:36] <tyr> hi i want to help translate manual [11:56] <anshul__> tyr: which language [13:13] <idlecore> Is ffserver maintained? [13:23] <idlecore> Is ffserver capable of receiving an rtmp feed? Would it work with Open Broadcast Software? [13:26] <Mavrik> idlecore, ffserver doesn't really receive anything [13:26] <Mavrik> idlecore, the receive and transcode part is still handled by ffmpeg [13:26] <Mavrik> ffserver is just restreaming stuff [13:26] <Mavrik> so whatever ffmpeg can receive, ffserver can [13:26] <Mavrik> but it's not really actively maintained [13:31] <idlecore> Mavrik Thanks. [13:33] <Fjorgynn> Welcome [16:06] <pinkette> wow 12+ hours to encode using x265 [16:13] <ubitux> this is the time required to encode 2 minutes of 1080p footage with a decent hw with libvpx [16:18] <pinkette> ubitux huh [16:19] <pinkette> ubitux are you saying vp9 is faster or slower? [16:21] <ubitux> i'm giving you a model of comparison with the worse i know [20:01] <Teilio> i'm trying to use -acodec copy for including an acc latm audio from a .ts but it doesn't seem to work - is there a library that might be needed for this? [20:02] <Teilio> or a way to include it in a more conventional aac format without reencoding [21:05] <rhagu> hi, is there a way to use this command for a few MB only? "ffmpeg -v error -i my.mkv -map 0:v -map 0:a -threads 3 -f null -" [21:51] <gsuberland> anyone familiar with the details of UYVY (YUV 4:2:2) planar data formats? [21:51] <gsuberland> I'm trying to work out if macropixels wrap lines if the horizontal resolution of the frame is odd [21:52] <gsuberland> and if so, what value (if any) is expected for the second Y value if it doesn't wrap [21:52] <gsuberland> also, if it does wrap, same question for the final macropixel in frame sizes that have an odd pixel count (e.g. 51x51 pixels) [21:54] <iive> well, it cannot have odd pixel count. the memory representation should always be even. if you have odd image dimension, you just ignore the last pixel. [21:56] <iive> basically the UV chroma components correspond to both Y Y samples. so you have something like Y1,U,V and Y2,U,V. [21:56] <gsuberland> so does it wrap, or just treat the entire image as one long stream? [21:57] <gsuberland> erm, badly phrased [21:57] <iive> i don't get what you mean by wrap? [21:57] <gsuberland> so let's say you've got an image line with 51 pixels [21:57] <gsuberland> for the last macropixel on that line you've only got one Y value, because there's no second pixel [21:58] <gsuberland> so does it take that Y value from the first pixel on the next line (i.e. handling the entire image as a single stream) or just not fill in that second Y value because it's the end of the line? [21:58] <iive> you just copy the value of the previous Y, and you should be fine. [21:59] <gsuberland> ah, that's a good idea actually [21:59] <gsuberland> so each line is treated as separate [21:59] <gsuberland> if you have an SO account, feel free to summarise as such here: http://stackoverflow.com/questions/27680466/how-does-the-uyvy-yuv-422-y422-… [21:59] <gsuberland> (for others' future reference) [22:00] <gsuberland> (and for some free rep ^^) [22:00] <iive> usually in video encoding you have width, height and linesize/stride . [22:00] <gsuberland> yeah, I'm aware of stride [22:00] <iive> the stride is same or bigger than the width in bytes. [22:00] <gsuberland> yeah, stride is sizeof(pixel)*width [22:00] <iive> so you can have some padding between the lines. [22:01] Action: gsuberland nods [22:01] <iive> e.g. it is quite useful if all lines start from memory address aligned for use with SIMD. [22:01] <gsuberland> I know sometimes they align lines at 4-byte or 8-byte boundaries so that you can do aligned reads for SIMD on file mappings [22:01] <gsuberland> heh, beat me to it :P [22:05] <gsuberland> cheers for the info :) [23:03] <Teilio> anyone know anything copying latm aac to raw aac [00:00] --- Mon Dec 29 2014

1 0

ffmpeg-devel.log.20141227
by burek 28 Dec '14

28 Dec '14

[00:39] <BBB> how do you compile libvpx 32bit? [00:47] <jamrial> "./configure --target=x86-linux-gcc" i think [00:48] <jamrial> you may have to use --extra-cflags for -m32 if you're on linux x64 [01:22] <BBB> (creating some x86-32 numbers) [03:06] <BBB> hm& I think gnome.org kicked me off their webspace [03:06] <BBB> can I get ffmpeg.org webspace for random stuff? [03:06] <BBB> (like ffmpeg.org/~rbultje) [03:08] <kierank> all the cool kids just post on github now [03:09] <BBB> hm [03:09] <BBB> how does that work? [03:10] <kierank> I think you just commit a file in markdown [03:10] <kierank> and then share it [03:11] <BBB> commit a file in markdown? [03:11] Action: Daemon404 just uses dropbox [03:11] <Daemon404> for files [03:11] <BBB> dropbox has adds [03:11] <kierank> BBB: markdown is github's markup language [03:11] <kierank> and you just make a repo like github.com/bbb/blog [03:11] <kierank> and make a file like github.com/bbb/blog/2014-12-27/ or whatever [03:12] <kierank> and share that [03:14] <kierank> or you can be really hipster and get a livejournal [03:14] <aetasx> thought girls gave that up in favor of spamming it on their facebook pages [03:16] <BBB> https://raw.githubusercontent.com/rbultje/public/master/vp9-32bit.png [03:16] <BBB> yay [03:16] <BBB> thanks kierank [03:17] <kierank> wow that's a big speed boost [03:30] <jamrial> what version of libvpx is this? odd that sse2 and ssse3 are the same with it [03:50] <michaelni> BBB, i can create an account on ffmpeg.org if you need one and send me a public ssh key. Not sure its optimal for random stuff though [04:49] <BBB> jamrial: todays git head of libvpx [04:50] <BBB> jamrial: I think our cpuflags dont work on them, so their sse2 may have ssse3 enabled also [04:50] <BBB> jamrial: Id have to force-disable it and Im just too lazy for that :] [04:51] <BBB> (as in: edit the optimizations template file and remove all ssse3 functions manually) [04:51] <BBB> michaelni: Ill try github for now, but thanks [04:54] <BBB> michaelni: if you want to review the branch I sent to ubitux earlier, thatd be nice [04:54] <BBB> Im hoping to merge that [04:55] <BBB> anyway, bed now [04:55] <jamrial> BBB: your vp9 blog post on gnome is still up, so your webspace was not deleted [05:07] <cone-82> ffmpeg.git 03Michael Niedermayer 07master:fa0e5ffb89b1: avfilter/vf_cropdetect: add yuv440p and yuv410p support [08:01] <Zeranoe> Is it possible to set the handler_name for audio/subtitles? It defaults to "SoundHandler" [12:17] <wm4> ==11780== Use of uninitialised value of size 4 [12:17] <wm4> ==11780== at 0x4FE79FC: ??? (h264_qpel_10bit.asm:853) [12:17] <wm4> is this interesting? [12:19] <nevcairiel> depends, sometimes this is intentional for some reason [12:19] <wm4> it's in asm, so it probably doesn't matter [12:27] <cone-78> ffmpeg.git 03Rémi Denis-Courmont 07master:4cfbeef31d4e: h264: factor hwaccel pixel formats list [12:27] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:57089084ba7e: Merge commit '4cfbeef31d4e6096c0596359d212f5d99a7ba4b5' [12:34] <arwa> When I am testing the formats for pp7, this is the result - "detected 2 logical cores" [12:34] <arwa> What does this mean? [12:40] <aetasx> wm4: you have a particular dev IDE you use? [12:41] <wm4> no [12:41] <aetasx> just using vim or something? [12:41] <wm4> I'm using kate... why me? [12:42] <aetasx> cause no one else is here :p [12:52] <cone-78> ffmpeg.git 03Rémi Denis-Courmont 07master:57b6704ecd0f: avcodec: add AVCodecContext.sw_pix_fmt [12:52] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:d16079abf473: Merge commit '57b6704ecd0f56d6a3092e448687cfd837bb0ac1' [13:04] <cone-78> ffmpeg.git 03Rémi Denis-Courmont 07master:6c99c92a42ad: libavcodec: add AV_HWACCEL_ALLOW_HIGH_DEPTH flag [13:04] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:ddb9a24a7f11: Merge commit '6c99c92a42add7f6a462114d5a4a53c93c551058' [13:12] <ubitux> wm4: mmh afaik we tend to fix these as well (the overreads are fine but shouldn't end up in uninitialized data) [13:15] <cone-78> ffmpeg.git 03Rémi Denis-Courmont 07master:c220a60f92dd: vdpau: add helper for surface chroma type and size [13:15] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:d7aaeea5402c: Merge commit 'c220a60f92dde9c7c118fc4deddff5c1f617cda9' [13:16] <michaelni> arwa, it just means your computers CPU has 2 logical cores [13:18] <arwa> Ohh...okay! [13:19] <arwa> If I am not getting any error, does this mean that all the pixel formats are supported? [13:19] <arwa> Well , the command I used was - libavfilter/filtfmts-test pp7 [13:23] <BBB> jamrial: yeah, but I cant log in to it :( [13:25] <cone-78> ffmpeg.git 03Rémi Denis-Courmont 07master:ebd5320afd42: vdpau: add support for 4:2:2 and 4:4:4 chroma sampling [13:25] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:751731540f5b: Merge commit 'ebd5320afd42d4315851f3e0ca7f5d4a6300eb68' [13:35] <cone-78> ffmpeg.git 03Rémi Denis-Courmont 07master:1f9237f2ac46: avconv_vdpau: allocate video surface of VDPAU-specified size [13:35] <BBB> (I can log in to my blog, but not into my webspace) [13:35] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:a6ab9ed50d8a: Merge commit '1f9237f2ac46dfbed1bfa1f4f0f1314c2a1d62ec' [14:24] <BBB> jamrial: new results with corrected VPX_SIMD_CAPS_MASK values uploaded (same location) [14:24] <BBB> (for reference: VPX_SIMD_CAPS_MASK=7 is sse2, VPX_SIMD_CAPS_MASK=31 is ssse3) [14:26] <BBB> maybe we can couple that to out -cpuflags cmdline option smehow? [14:26] <BBB> (I realize this would be hacky, I dont see an API to set the mask, maybe open a featur request against libvpx) [14:35] <saste> ubitux, fine to push tblend? [14:54] <cone-78> ffmpeg.git 03Rémi Denis-Courmont 07master:737d35e33408: vdpau: add support for the H.264 High 4:4:4 Predictive profile [14:54] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:6f764d291121: Merge commit '737d35e33408263c04d7730f5487eed0d04938ba' [15:13] <ubitux> saste: i think s/consecutives/consecutive/ [15:13] <ubitux> "for @code{blend}" "for the @code{blend} filter" [15:13] <ubitux> same below [15:15] <ubitux> saste: otherwise LGTM [15:16] <cone-78> ffmpeg.git 03Anton Khirnov 07master:60d4c6ff7646: h264: restore a block mistakenly removed in e10fd08a [15:16] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:9e893473297e: Merge commit '60d4c6ff76467d4d8f55c1cc61ab6c618e8ea2f3' [15:59] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:336bb3f706ea: avutil/dict: Use av_freep() to avoid leaving stale pointers in memory [15:59] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:6d639ecf4472: avutil/audio_fifo: use av_freep() to avoid leaving stale pointers in memory [15:59] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:05e74ac2f3f3: avutil/hmac: use av_freep() to avoid leaving stale pointers in memory [16:18] <cone-78> ffmpeg.git 03Stefano Sabatini 07master:d4fd3f24e86f: lavfi: add tblend filter [16:30] <BBB> ubitux: any progress on my 15 patches? :-p [16:54] <ubitux> BBB: can you submit them to the mailing list? [16:54] <ubitux> i'll review in the next hours probably [16:54] <ubitux> gtg now [17:00] <BBB> ok [17:03] <BBB> ubitux: ok, you asked for it [17:22] <aetasx> wth is tblend [17:23] <wm4> aetasx: RTFML [17:23] <aetasx> I get enough emails already ;) [17:25] <ubitux> aetasx: main usage is to make a diff between 2 successive frames [17:25] <aetasx> ah, interesting [18:21] <ubitux> Tim_G: why would that be the wrong patch? [19:09] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:ed96830afc05: avfilter/vf_blend: Fix AVClass [19:15] <cone-78> ffmpeg.git 03Michael Niedermayer 07master:cc91488588ac: avfilter/vf_cropdetect: Factorize duplicated code using a macro [19:40] <ubitux> akira4: i will look deeper into libdvd* tomorrow (CET tz here) [19:40] <ubitux> akira4: meanwhile, did you try to make the original protocol patch work? [21:07] <Zeranoe_> Is it possible to set the handler_name for audio/subtitles? It defaults to "SoundHandler" [21:12] <BBB> ubitux: new patchset pushed with all comments addressed [21:15] <Zeranoe_> Is it possible to set the handler_name for audio/subtitles? It defaults to "SoundHandler" [21:15] <Zeranoe_> Woops [21:17] <BBB> ubitux: if you have no further comments, poke michaelni so he can merge from github, I guess [22:06] <ubitux> BBB: yeah, no further comment [22:06] <ubitux> you can "pull request" :) [22:06] <ubitux> merge* [22:09] <michaelni> merging rbultje/vp9-32bit would add 46 commits, the patchset contained 15 IIRC, i assue this is not intended [22:11] <jamrial> the rest were already merged in a squashed form before, i think [22:17] <michaelni> yes, i could cherry pick the last 15, they apply cleanly or BBB could rebase them and i could merge the result. But either way merging from this branch will alway have this problem as long as these commits mismatch the squashed one from master [22:21] <ubitux> just wait for a rebase [22:22] <michaelni> ok [22:24] <cone-963> ffmpeg.git 03Clément BSsch 07master:56e432b27b8f: avutil/atomic: reuse ret to avoid dereferencing twice the same value. [22:31] <ubitux> so... ilpack can be dropped or not yet? [22:35] <BBB> michaelni: its now 16 [22:36] <BBB> michaelni: ubitux asked for an extra one to add my name to copyright list [22:37] Action: Daemon404 bets chrome still wont switch to ffvp9 [22:37] <BBB> file a bug so they can track it :D [22:37] <BBB> (cr.bug.com?) [22:37] <Daemon404> i have many open bugs with chrome [22:37] <BBB> or whatever it was [22:37] <Daemon404> its akin to throwing my woes into a pit [22:38] <nevcairiel> dont they use it now [22:38] <nevcairiel> i thought they actually did [22:38] <Daemon404> only small things like "DASH is broken and nonconformant" and "does not handle bt709 properly full stop" [22:38] <BBB> lets see [22:38] <nevcairiel> people on d9 complained that it was so extremely slow on 32-bit at least [22:39] <nevcairiel> unless theirs is as well :P [22:39] <Daemon404> nevcairiel, i thought the gave some reason like error resiliance [22:39] <Daemon404> or something [22:39] <ubitux> chromium will probably not switch to ffvpx because they need libvpx anyway i suppose [22:40] <ubitux> typically because vp10 or whatever project they fancy [22:40] <Daemon404> encoding too [22:40] <Daemon404> webrtc crap [22:40] <ubitux> in chromium? [22:40] <ubitux> ah.. [22:40] <ubitux> is that really possible to make real time encoding with libvpx? [22:40] <ubitux> i strangely have high doubts :') [22:40] <Daemon404> vp8 yeah [22:40] <ubitux> yeah vp8 ok. [22:42] <michaelni> BBB did you push the rebased 16 to your github ? [22:42] <BBB> I think I did [22:43] <kierank> ubitux: i believe yes [22:43] <BBB> let me see [22:43] <kierank> ubitux: but I am assuming swscale is doing the right thing [22:43] <ubitux> kierank: so what's the magic equivalent command line? [22:43] <kierank> just vf_scale from 420 to 422 [22:43] <ubitux> (so we can document it in the drop commit message) [22:43] <kierank> with interlaced [22:43] <BBB> michaelni: yeah its there [22:43] <BBB> https://github.com/rbultje/ffmpeg/commits/vp9-32bit [22:44] <kierank> 9:40 PM <"ubitux> is that really possible to make real time encoding with libvpx? --> some people say it is [22:44] <BBB> vp9/x86: save one register in loopfilter surface coverage. until top [22:45] <ubitux> i wonder if i reach 1 fpm by encoding with libvpx/vp9 [22:45] <Daemon404> ubitux, im doing my latest round of 4k testing right now [22:45] <Daemon404> im debating even botherign with vp9 [22:46] <ubitux> is the first frame encoded yet? [22:46] <Daemon404> ;p [22:47] <BBB> is x265 that much better? Most comments I read complain it has the same issue as libvpx, its slow or not better than x264 [22:47] <michaelni> git fetch rbultje && git log master..rbultje/vp9-32bit --oneline | wc [22:47] <michaelni> still gives 45 [22:48] <BBB> michaelni: well you merged it previously :) [22:48] <nevcairiel> BBB: its not *that* slow ;) [22:48] <BBB> nevcairiel: oh no, it takes only 17 days to encode a frame, instead of 24 [22:48] <BBB> such progress" [22:48] <BBB> yay" [22:48] <BBB> look how cool" [22:49] <nevcairiel> nah its actually acceptable [22:49] <BBB> maybe its more recent perormance is acceptable [22:49] <nevcairiel> quality exceeds x264 on low bitrates at least, on high rates its about equal still i think [22:49] <BBB> in the past it was poor [22:49] <Daemon404> BBB, x265 right now reminds me of using x264 on my athlon xp back then [22:49] <michaelni> BBB i can merge it but there will be 30 duplicate commits [22:49] <Daemon404> that is, it's reasonably fast [22:50] <Daemon404> for what it is [22:50] <BBB> michaelni: let me rebase on top of new master, one sec [22:51] <Daemon404> nevcairiel, i.e. Not Worth It [22:51] <Daemon404> my main issue with vp9 is not actually teh speed fwiw [22:51] <Daemon404> it's the terrible ratecontrol. [22:51] <nevcairiel> Daemon404: at 4k its probably useful, as the compression gains are actually there [22:52] <Daemon404> nevcairiel, we'll see, i am going to look at that on monday [22:52] <nevcairiel> but we all know that x264 also didnt beat xvid in the beginning, but of course you have to start somewhere [22:52] <nevcairiel> h265/hevc should be with us for a while [22:53] <Daemon404> x264 didnt beat xvid at high rates in mainline x264 until aq and psyrd got pushed [22:53] <Daemon404> unless you disabled trellis and lowered the deadzone settings [22:53] <Daemon404> which is kinda cheating [22:54] <Daemon404> that said [22:54] <Daemon404> x264's ratecontrol always hit teh target well (sometimes too well) [22:54] <Daemon404> xvid's was criminally bad [22:55] <JEEBsv> yeah [22:55] <jamrial> hevc will be with us for a while indeed. blu-ray 4k and streaming will guarantee it [22:55] <Daemon404> i am still waiting for teh fabled day when there is a way to actually play it back for most people [22:56] <Daemon404> i dont count "you can get hevc if you stream to a smart tv" [22:56] <BBB> michaelni: rebasing& will take a few minutes to confirm it all still works [22:57] <michaelni> sure, no hurry [22:57] <Daemon404> are vp9 bitstreams trivially concatable? [22:57] <michaelni> BBB and thanks [22:57] <nevcairiel> Daemon404: once blu-ray picks up hevc playback stuff will have to adapt [22:58] <Daemon404> nevcairiel, yea [22:58] <Daemon404> but tbh, one of the only reasons h264 caught on on teh web IMO was flash [22:58] <Daemon404> and flash is not getting hevc. [22:58] <nevcairiel> and with the openhevc simd, software playback is also quite acceptable performance wise [22:58] <nevcairiel> without, its just painfully slow [22:58] <cone-963> ffmpeg.git 03Reimar Döffinger 07master:035180901de9: r210enc.c: Simplify and never store more than 10 bits. [22:58] <Daemon404> nevcairiel, MS's filters used in IE may be ok [22:58] <jamrial> i thought it caught on because anime switched to it from xvid [22:59] <nevcairiel> Daemon404: thats only win10 however [22:59] <Daemon404> jamrial, well i meant on the web. [22:59] <BBB> why dont people write proper asm for hevc? [22:59] <Daemon404> youtube and pals [22:59] <Daemon404> BBB, chicken and egg problem [22:59] <BBB> like, not the intrinsics crap [22:59] <BBB> it seems people dont care about hevc [22:59] <BBB> that is [22:59] <BBB> they want the pretty software [22:59] <BBB> but they dont want to pay for it, or write it themselves [22:59] <Daemon404> nobody cares about anything post-h264 yet in reality [22:59] <BBB> they just want to leach off the work of others [22:59] <Daemon404> except youtube [22:59] <nevcairiel> the intrinsics are decently fast at the very least [22:59] <Daemon404> and marketing folks [22:59] <jamrial> BBB: plepere was porting all those intrinsics to yasm [22:59] <jamrial> but stopped midway [23:00] <BBB> right that was 6 months ago [23:00] <BBB> right [23:00] <BBB> so now what? [23:00] <jamrial> his contract with openhevc ended. nobody seemingly took his place [23:01] <Daemon404> nobody wants to pay because there is no direct benefit right now [23:01] <Daemon404> chicken and egg, liek i said [23:01] <BBB> if investors worked this way [23:01] <BBB> we would all be really, really, really, poor and unemployed [23:01] <Daemon404> thats how investors work in parts of europe [23:01] <ubitux> and have more time to work on ffmpeg \o/ [23:02] <Daemon404> deliciously stagnant [23:02] <Daemon404> :) [23:02] <BBB> hehe [23:03] <nevcairiel> i would work on porting the asm, but i'm too bad at the asm, it takes too long to be fun :p [23:03] <BBB> at least 32bit performance of ffvp9 is awesome [23:03] <BBB> hevc & yeah ... [23:03] <BBB> I hope people use ffmpeg in their hevc vs vp9 comparisons [23:03] <BBB> it will be awesome (for vp9) [23:03] <nevcairiel> the advantage of the intrinsics is that it magically works in 32-bit :d [23:03] <BBB> the disadvantage of intrinsics is that it sucks [23:04] <Daemon404> i sitll dont see vp9 beign adopted due to its abysmal encoder [23:04] <nevcairiel> eh decoding speed isnt a common thing for codec comparison [23:04] <Daemon404> i asked alex about the encoder at vdd btw [23:04] <BBB> Daemon404: true [23:04] <Daemon404> he said its because theyre 'tailoring it to their biggest customer' [23:04] <BBB> the encoder is kinda shit (ask ubitux :D) [23:04] <Daemon404> aka youtube [23:04] <jamrial> nevcairiel: after an unholy and most likely unnecesary amount of movs to and from memory :p [23:04] <nevcairiel> jamrial: nah its actually not that terrible [23:04] <Daemon404> since they do distributed GOP encoding + implement their own ratecointrol hacks [23:04] <Daemon404> they dont care [23:04] <nevcairiel> at least with recent compilers [23:04] <Daemon404> thus, libvpx oesnt care [23:04] <Daemon404> and nobody else will use it. [23:05] <BBB> so we need to write our own encoder :) [23:05] <jamrial> Daemon404: it wont be adopted because Google doesn't even try to get people to adopt it, for some reason [23:05] <BBB> anyway [23:05] <BBB> vp9 ... [23:05] <BBB> theyre already on vp10 [23:05] <BBB> so who care [23:05] <Daemon404> jamrial, not true [23:05] <Daemon404> they phone us (Vime) periodically [23:05] <Daemon404> and feed us a bunch of lies [23:05] <Daemon404> :D [23:05] <Daemon404> Vimeo* [23:05] <jamrial> haha [23:06] <jamrial> who cares about vp10 when there's daala? :p [23:06] <Daemon404> i am skeptical of daala [23:07] <Daemon404> xiph has this way of deciding on a way to do stuff, and hammering it until it works [23:07] <Daemon404> see: all previous xiph codecs except opus [23:07] <Daemon404> also ogg. [23:07] <nevcairiel> vorbis isnt too terrible, if you dont count its ogg container [23:08] <Daemon404> it was quite bad until a third part worked on it [23:08] <Daemon404> (aotuv) [23:08] <Daemon404> party* [23:08] <Daemon404> the encoder i mean. [23:08] <BBB> I do think daemon404 has a point [23:08] <BBB> you should choose techniques because theyre better [23:08] <BBB> they just choose techniques because they sound cool and then they advertise it like a iraqi minister of public affairs [23:09] <BBB> and then they withdraw it because it sucks [23:09] <BBB> and circle back to step 1 for a replacement technique [23:09] <Daemon404> well [23:09] <Daemon404> also [23:09] <Daemon404> xiphcode.c [23:09] <Daemon404> incomprehensible [23:10] <BBB> michaelni: https://github.com/rbultje/ffmpeg/commits/vp9-32bit-lpf [23:10] <BBB> yeah, xiphcode is just shit [23:10] <Daemon404> actually this all reminded me [23:11] <Daemon404> i should submit a patch to vp9 [23:11] <Daemon404> alex told me where/how i shoudl add bt709 support. [23:11] <Daemon404> btu :effort: [23:11] <BBB> I believe it already has bits in the bitstream for it [23:11] <kierank> i don't understand the people who say they are using vp9 in realtime [23:11] <BBB> (in profile 1 and up) [23:11] <Daemon404> BBB, it does not [23:11] <Daemon404> it only has yuv and rgb [23:11] <BBB> no it has bt709 [23:11] <BBB> I reviewed the patch [23:11] <Daemon404> oic [23:11] <BBB> Im not saying its exposed in the cli [23:11] <BBB> but the bits in the bitstream are there (normatively) [23:12] <Daemon404> also chrome ignores colorspace flags anyway [23:12] <Daemon404> and treats everythign as 601 [23:12] <BBB> that too [23:12] <BBB> lol [23:12] <BBB> :) [23:12] <Daemon404> BUT [23:12] <Daemon404> only on sw decode [23:12] <kierank> and chromecast doesn't work with 25hz tvs [23:12] <Daemon404> hw decode uses drivers -> Does it right [23:12] <Daemon404> so i have confused-as-hell users [23:12] <Daemon404> \o/ [23:12] <BBB> yay [23:12] <kierank> Daemon404: is chrome using swscale? [23:12] <BBB> actually profile 0 probably has these bits also [23:12] <BBB> anywya [23:13] <Daemon404> kierank, no [23:13] <Daemon404> libyuv [23:13] <BBB> baby steps [23:13] <BBB> I can hook up the ffvp9 colorspace bits if the libvpx ones are hooked up [23:13] <BBB> so far its meaningless :D [23:13] <Daemon404> lol yea [23:13] <jamrial> what do they use ffmpeg libs for? ffvp8? audio codecs? [23:13] <Daemon404> sw h264 [23:14] <jamrial> ah [23:14] <Daemon404> probably vorbis or something [23:14] <Daemon404> chrome is also the blocking browser on me for some DASH stuff [23:14] <Daemon404> i swear chrome is teh new IE6 [23:14] <Daemon404> have to hack around its crap [23:14] <jamrial> firefox uses the cisco openh264 because patents [23:14] <Daemon404> it will use system hw iirc [23:15] <Daemon404> if possible [23:15] <Daemon404> dxva and pals [23:15] <jamrial> on windows it can also use ms h264 decoder i think [23:15] <Daemon404> yes [23:16] <Daemon404> on os x it has VDA in beta iirc [23:16] <Daemon404> but youd be silly to use firefox on os x [23:17] <nevcairiel> someone was trying to get MS to support Opus in html5 audio, that would be a nice addition [23:18] <Daemon404> its somewhat likely [23:18] <Daemon404> they did create half of opus technically [23:18] <Daemon404> also opus-in-mp4 is Almost Ready i think [23:18] <Daemon404> waiting to mp4a reg to go through i think. [23:19] <nevcairiel> i would love to have a option on android to support opus in some sort of streaming format, but apparently android 5.0 still doesnt do opus in ts, only plain .opus for audio playback [23:20] <Daemon404> .opus is just ogg [23:20] <Easyfab> For vp9 I see some days ago this -> https://github.com/ittiamvpx/libvpx ? I don't try because I don't have a decent opencl gpu and it's based on old 1.3 version. Has someone tried it for the speed ? [23:25] <nevcairiel> opencl encoding has generally been a big disappointment, no matter which codec [23:26] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:c013ca58c534: vp9/x86: save one register in loopfilter surface coverage. [23:26] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:8132629bd587: vp9/x86: make cglobal statement more conservative in register allocation. [23:26] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:e59bd0898686: vp9/x86: slightly simplify 44/48/84/88 h stores. [23:26] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:d1c55654e11c: vp8/x86: remove unused register from ABSSUB_CMP macro. [23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:418c202c6363: vp9/x86: simplify ABSSUM_CMP by inverting the comparison meaning. [23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:e42409479f09: vp8/x86: move variable assigned inside macro branch. [23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:8ea2194ebb57: vp9/x86: store unpacked intermediates for filter6/14 on stack. [23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:7f80c3344cc0: vp8/x86: save one register in SIGN_ADD/SUB. [23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:75f8e520897f: vp9/x86: make filter_44_v work on 32-bit. [23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:6433a9133f41: vp9/x86: make filter_88_v work on 32-bit. [23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:0cc9c23ea171: vp9/x86: make filter_48/84_v work on 32-bit. [23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:047088b8c6cf: vp9/x86: make filter_16_v work on 32-bit. [23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:8a1cff1c355d: vp9/x86: make filter_44_h work on 32-bit. [23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:b26bc3520f9a: vp9/x86: make filter_48/84/88_h work on 32-bit. [23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:afd8c464b7ea: vp9/x86: make filter_16_h work on 32-bit. [23:27] <cone-963> ffmpeg.git 03Ronald S. Bultje 07master:3aefca68cae6: vp9/x86: add myself to copyright holders for loopfilter assembly. [23:27] <cone-963> ffmpeg.git 03Michael Niedermayer 07master:17dde95ec52e: Merge remote-tracking branch 'rbultje/vp9-32bit-lpf' [23:30] <BBB> yay [23:30] <nevcairiel> so are you done now, or still more to do? :d [23:30] <BBB> thats it [23:31] <BBB> I mean tehcnically we could now optimize filter_4_16 or filter_8_16 [23:31] <BBB> but theyre not very important [23:32] <nevcairiel> that should make those 32-bit or pre-ssse3 users happier, some complained a bit about the slowness in their setups [23:32] <BBB> yes [23:32] <nevcairiel> i should push out an update to all those that use my stuff [23:33] <nevcairiel> lets see if fate remains happy, i wanted to work on some stuff next week anyway [23:40] <Zeranoe_> Looking at the code for movenc.c (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/movenc.c;hb=HEAD…) it looks like descr does not accept user override? I'm guessing these meta parts cannot be changed... Perhaps a patch is in order [23:45] <nevcairiel> you can shove it into AVStream->metadata as "handler" [23:45] <nevcairiel> and the code will use it [23:46] <Zeranoe_> nevcairiel: Can it be done though CLI? [23:46] <nevcairiel> i dont use the cli [23:48] <nevcairiel> it does have -metadata but i dont know if you can make it apply to a stream [23:48] <BBB> Ive updated the blog post to cross the line that says 32bit doesnt work [23:48] <BBB> feels kind of official now [23:48] <BBB> anyway [23:48] <BBB> lets do something thats not 32bit hammering [23:48] <BBB> (32bit seriously sucks) [23:49] <nevcairiel> i think you can do -metadata:s:1 to set metadata for stream #1 [23:50] <nevcairiel> not tested if it actually works, some SO posts claimed so :P [23:51] <jamrial> "8 gprs is ought to be enough for anyone" [23:52] <BBB> stack spill/unspill deluxe [23:52] <nevcairiel> how many regs do alternate architectures have, like arm? [23:53] <jamrial> some variants have 32 i think [23:53] <nevcairiel> typically 15 GPRs apparently [23:54] <Zeranoe_> nevcairiel: That doesn't seem to change it [23:54] <jamrial> arm8 has 32 gprs and 32 simd [23:57] <nevcairiel> Zeranoe_: works here [23:58] <nevcairiel> Zeranoe_: ffmpeg -i foo.mkv -c:v copy -c:a copy -metadata:s:a handler="FooHandler" test.mp4 [23:58] <nevcairiel> gives the audio stream a handler "FooHandler" [23:59] <Zeranoe_> nevcairiel: Oh, let me try that, I did handler_name="English" [00:00] --- Sun Dec 28 2014

1 0

ffmpeg.log.20141227
by burek 28 Dec '14

28 Dec '14

[00:53] <c_14> v4l2 should be able to tell you, ffprobe should also tell you whatever it picks [01:49] <fahadash> hello [01:49] <fahadash> any ffmpeg folk online ? [02:16] <squeegily> Hey guys. I have an old Acer Aspire laptop I'd like to try to watch anime on. This thing is too slow to play the videos as-is (720p H.264). Any tips for re-encoding? [02:17] <squeegily> It's OK if it takes up to an hour or two to re-encode, and files up to 1GB per 20 minutes are fine [02:17] <squeegily> So what can I do to make it look as good as possible [02:19] <squeegily> I know that the 4 factors in (re)encoding video are finished file size, encoding time, video quality, and decoding ease, and that for the most part those factors can be improved at the cost of each other [02:19] <squeegily> Speaking generally [02:28] <squeegily> The only hard limit I have is that a 1.33GHz Atom processor needs to be able to decode it at watching speed. We have as much ENcoding time as we need, and the hard drive space is also pretty much immaterial. So how can I get the least damage to the video with this? [02:41] <debianuser> squeegily: You can try reencoding it into divx/xvid or other mpeg4 format that is easy to decode (basically `ffmpeg -i file.mkv recoded.avi` would do that with default encoding settings). Do a few experiments, to make sure you like the quality. Check https://trac.ffmpeg.org/wiki/Encode/MPEG-4 to see some quality options (-qscale:v). [02:42] <squeegily> debianuser: Thanks. [02:42] <debianuser> squeegily: Another option: configure mplayer on your laptop locally with --extra-cflags="-O3 -march=native" and build it. It should have enough performance to decode 720p h264 in software :) [02:44] <squeegily> The GPU is a gma500 [02:45] <squeegily> It's supposed to have H.264 acceleration on Linux.. but I have my doubts [02:45] <squeegily> So DivX is relatively easy to decode? [02:46] <squeegily> Hehe "the most common usage of Xvid video is currently for older hardware devices. See the H.264 and AAC encoding guides if you are using modern devices. " [02:46] <squeegily> This sounds perfect ^0^ [02:48] <shevy> guys I have a hypothetical question [02:48] <shevy> say I have an .avi file - which should have video, and audio. now I wish to add another audio to said video [02:49] <shevy> do I first have to demultiplex so that I get the raw video, and then add the new audio - or can I directly just add the new audio to that .avi file, and it would replace the existing audio part? [02:49] <shevy> (I want only one audio track in total btw) [02:51] <debianuser> squeegily: Actually gma500 supports h264 decoding. I don't remember supported profile, but I did that a few years ago. :) You need a special proprietary "psb" driver (https://wiki.ubuntu.com/PoulsboObsoleteDrivers) specific version ranges of xorg and kernel, and a patched mplayer with vaapi support (I *guess* those are in centos6). But if you manage to match them all - it works. [02:54] <debianuser> shevy: You can replace the audio track. Something like that: `ffmpeg -i infile.avi -i infile.mp3 -map 0:v -map 1 -c copy outfile.avi` Check -map option: https://trac.ffmpeg.org/wiki/How%20to%20use%20-map%20option [02:56] <debianuser> squeegily: Ah, debian squeezy may work too. :) [02:56] <debianuser> *squeeze [03:00] <squeegily> debianuser: The audio I don't worry about.. I'm actually running "ffmpeg -i ../Joshiraku/[gg]_Joshiraku_-_02v2_[01AC8A77].mkv -c:v libxvid -c:a copy -c:s copy 2.mkv" and we'll see what happens [03:00] <shevy> hmm [03:00] <shevy> debianuser ok so in other words, I don't need the additional step of demultiplexing there - I can simply just add the new audio track, right? [03:01] <squeegily> shevy: I don't think ffmpeg can modify a file in-place [03:01] <shevy> yeah the old file will be retained I guess [03:02] <squeegily> shevy: You'll be saved the trouble of re-encoding if you map things correctly (it'll list itself as running at thousands of frames per second since it's literally just copying the streams) [03:02] <debianuser> shevy: Yes, you can either add one more track or replace existing track in one ffmpeg run, depending on what tracks you select to be copied with -map option. [03:02] <shevy> debianuser ok cool, thanks man [03:02] <debianuser> you're welcome. :) [03:02] <squeegily> debianuser: Wait.. ffmpeg can modify files in-place? [03:03] <debianuser> squeegily: Not in place, it would still create a new file. You just can do it in one run [03:03] <squeegily> debianuser: ffmpeg -i audio -i video output && mv output video [03:03] <squeegily> You mean like that? [03:04] <debianuser> squeegily: I mean you don't have to extract video track with first command ("demultiplex") and then combine it with audio track with second command - you can do both in one run. [03:04] <squeegily> debianuser: Ohh I think I see [03:04] <squeegily> What's the point of that? [03:04] <debianuser> of what? ;) [03:05] <squeegily> Oh wait I thought you meant something else [03:05] <shevy> squeegily ah I am in the process of building up piped instructions [03:05] <shevy> squeegily one part goes like this currently: [03:05] <squeegily> shevy: Yeah the only places you'll need piping with ffmpeg these days is the one corner case involving subtitle conversion [03:05] <shevy> assign TheShining.avi | remove audio | add audio bla.mp3 [03:06] <shevy> and when I saw it I was wondering whether I had to really remove the audio [03:06] <squeegily> shevy: Ohh.. yeah you can do that in one command [03:06] <shevy> :) [03:07] <squeegily> I really like MKV as an output format because I can mix Vorpis video and M4A audio without reencoding [03:07] <squeegily> Or any other mismatches [03:07] <squeegily> Just remember that remuxing is awesome [03:07] <squeegily> Saves CPU and completely lossless [03:08] <squeegily> I just discovered it recently [03:08] <squeegily> Blew my mind [03:08] <shevy> .mkv sounds like a improvement over .avi [03:09] <squeegily> shevy: The only case where MKVs aren't absolutely suitable is if the video is going to be played on a PS3 [03:09] <squeegily> MKVs are the best thing ever.. It's literally the perfect container format [03:10] <squeegily> It can accept any number of video, audio, or subtitle tracks, and since it's completely modular, it's forward-compatible so whatever gets invented in the future will still work with it [03:12] <squeegily> I use them for YouTube rips so I can have the easier to decode, smaller file Webm video with the better quality m4a audio [03:12] <shevy> hmm [03:12] <shevy> with YouTube rips, you actually mean you first have to download the video (which I assume will often be a .mp4 file) and the re-encode it into a .mkv file? [03:13] <shevy> *and then re-encode [03:13] <squeegily> No.. I download the video-only Webm and the m4a audio and then remux them into an MKV [03:14] <squeegily> it takes like a second and is literally 100% lossless since nothing gets reencoded [03:14] <shevy> it's been some years since I last looked into .mkv; back then it did not seem to be as polished, or simply as widespread. like initially I found mostly just .avi and .mpeg files, then .flv and lately very often .mp4 (which I assume usually has h264) [03:14] <shevy> hmm [03:14] <shevy> how can you download the video only webm? [03:14] <squeegily> Check out youtube-d [03:14] <squeegily> youtube-dl; [03:14] <shevy> aaaah ok [03:15] <shevy> I know that, commandline thingy in python right? [03:15] <squeegily> Try out youtube-dl -F and you'll understand why it's the best [03:15] <squeegily> Yeah exactly [03:15] <squeegily> That's how I remember it too [03:15] <shevy> hmm [03:15] <shevy> but you will get a single file by default right? [03:15] <shevy> so I assume you use ffmpeg to split the file? [03:15] <squeegily> Yes, by default it downloads the MP4 format [03:15] <shevy> ok I understand finally! [03:16] <squeegily> Try it out with the -F flag and it will list all the backend ways YouTube lets you download the video in [03:16] <squeegily> It has an option to automatically use ffmpeg to download and merge two different formats [03:17] <squeegily> I used the flags --prefer-ffmpeg -f 271+172 -o '%(title)s.mkv' when downloading RWBY [03:18] <squeegily> I have no idea why --prefer-ffmpeg isn't the default since avconv is really lamee [03:18] <shevy> oh? [03:18] <squeegily> But yeah if you just run it on a URL with no flags it will download from YouTube a ready-to-watch MP4 without any further ado [03:18] <shevy> you mean I can choose which format youtube will give me the file in? [03:18] <squeegily> Yes, YouTube has several formats available [03:19] <shevy> cool. I always thought there was just one (the default I use with youtubedl heheheheh) [03:19] <squeegily> Usually it's an MP4 (video+sound), a lower-quality webm (video+sound) and then a TON of quality options in webm or mp4 (these are video only) and some audio options (I think they're all m4a except 1 webm) [03:20] <squeegily> So I prefer the webm that's the same quality as the default MP4 muxed with the best quality m4a audio [03:20] <squeegily> For some reason it seems 1080p video (scaled up?) is available for every video [03:21] <squeegily> But anyway, after discovering -F it's pretty cool [03:21] <shevy> for the most part I am interested mostly in audio [03:21] <squeegily> shevy: You can download the raw audio for e.g., a song which is nice [03:21] <squeegily> Just a plain .m4a file [03:22] <shevy> ah [03:22] <squeegily> I wonder if m4a and mp3 match up like WAV and CDA [03:22] <shevy> so I could use youtube-dl just to grab the audio directly? [03:22] <squeegily> Exactly [03:22] <squeegily> Run it with the -F flag [03:22] <shevy> my current workflow was like this: get the file through youtube-dl, use ffmpeg to extract the audio through a script :) [03:22] <squeegily> Wow [03:22] <squeegily> What's up with pekman [03:23] <squeegily> He keeps connecting and disconnecting [03:23] <squeegily> Maybe his wifi is flaky [03:25] <squeegily> Is it -scale=height:width? [03:41] Action: debianuser actually came here to ask a question too :) [03:41] <debianuser> I have 3d half-side-by-side 1280x720 video, how can I reencode it to a single side video? "-vf stereo3d=sbs2l:ml" is not enough, I get just the left half which is displayed as 640x720, while I want to see it as 1280x720. I don't want to actually scale it (that's a last resort), just wanted set some tag to have it scaled by the device playing the file. Is there some option I miss? [03:43] <squeegily> Whoa [03:43] <squeegily> I think you're the senior user here [03:43] <squeegily> You may not get any help from that unless we get the maker of ffmpeg here [03:44] <debianuser> We have them here. :) They just don't always read this channel. But I can wait. [03:45] <debianuser> This is a rather active channel, there're IRC channels where I had to wait for a few days before someone who knows the answer would actually come and read my question. [03:46] <squeegily> Do you have any idea why this is giving an error: ? [03:46] <squeegily> ffmpeg -i ../Joshiraku/\[gg\]_Joshiraku_-_02v2_\[01AC8A77\].mkv -vf scale=-1:480 -c:v libxvid -vtag xvid -q:v 24 -c:a copy 2.mkv [03:46] <squeegily> It's the usual "Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height" [03:47] <squeegily> I tried removing the quality option incase it was conflicting with the scale option [03:47] <squeegily> But it looks like the scale option is not working [03:47] <debianuser> Try dropping options one by one until you find the one that causes the error. :) [03:47] <squeegily> It's the scale one [03:47] <squeegily> The command worked until I added that in [03:48] <squeegily> I add things one by one for the very reason of diagnosis when one fails [03:48] <squeegily> The syntax is correct.. [03:48] <debianuser> Try different value then, e.g. 5 instead of 24 [03:49] <squeegily> The quality is fine.. other values of it still cause crashing [03:49] <squeegily> But it works without the scale filter [03:49] <squeegily> So the scale filter's crashing it [03:49] <squeegily> Even if I use the scale without the quality it still crashes [03:51] <squeegily> But 24 quality is barely tolerable to watch and still isn't easy-to-decode enough [03:51] <squeegily> I'm going to try 24 quality and 480p so maybe it'll play properly [03:52] <squeegily> Okay I just ran this and it still failed: [03:52] <squeegily> ffmpeg -i ../Joshiraku/\[gg\]_Joshiraku_-_02v2_\[01AC8A77\].mkv -vf scale=-1:480 2.mkv [03:52] <debianuser> Replace -1 with actual number [03:53] <squeegily> Ah it works [03:53] <squeegily> Now I just need to calculate 1280/720=x/480 [03:54] <debianuser> 854 :) [03:54] <squeegily> Thanks [03:54] <debianuser> But since you're encoding to xvid you don't have to scale, unless the screen of your laptop is 480p ;) [03:55] <squeegily> The laptop is 1366x768 [03:56] <squeegily> But it can't handle 1280x720 H.264 decoding [03:56] <squeegily> It's spamming [libxvid @ 0x9b32a40] Invalid pixel aspect ratio 1280/1281, limit is 255/255 reducing [03:56] <squeegily> So I can't see the progress [03:56] <squeegily> But I think it's working [03:57] <squeegily> Trying 853 or 855 make it crash outright [03:57] <squeegily> made [03:58] <squeegily> debianuser: I'm scaling since even with xvid killed all the way down to 24 quality (31 is worst) it STILL lags too much to be worth watching [03:59] <debianuser> squeegily: What about a simple: ffmpeg -t 60 -i ../Joshiraku/\[gg\]_Joshiraku_-_02v2_\[01AC8A77\].mkv 2.avi [03:59] <debianuser> (-t 60 is to limit it to first 60 seconds, enough for the test and much faster than encoding entire file) [04:11] <debianuser> squeegily: Because when even xvid "lags too much" the problem is probably not in your cpu, but in your video output. If you have mplayer there run `mplayer -benchmark -lavdopts threads=2 -vo null -ac null -endpos 120 \[gg\]_Joshiraku_-_02v2_\[01AC8A77\].mkv` and copy its output to some pastebin, let's see how fast it's decoded. [04:37] <Dr_Radium> should i use PSNR or sSIM when encoding using x265 ? [05:36] <squeegily> debianuser: Yeah I usually run it for about 45 seconds worth of film, then ^Z to pause it, then I take a look at it and see if it will work [05:37] <squeegily> I've tried mplayer with multithreading and even frame dropping and I get about the same results [05:46] <Zeranoe> Trying to extract subtitles (PGS) to .sup to do a ORC on them. Keep getting "Unable to find a suitable output format...". Output: http://paste.ubuntu.com/9628132/ command: ffmpeg -i "C:\input.m2ts" -an -vn -map 0:3 -c:s copy "C:\output.sup" [05:48] <squeegily> Lol on the video 480p quality 24 mplayer 4 threads frambuffer it prints out a huge warning in all caps "YOUR COMPUTER IS TOO SLOW TO PLAY THIS" [05:49] <squeegily> And it proceeds to lag [05:50] <squeegily> Wait.. does MPlayer pre-decode the video like buffering it? [05:51] <squeegily> Because I have always thought that such a thing would be amazing - just pause a video, let it buffer, and then you're ready to playe [05:51] <squeegily> holy crap where has this been all my LIFE [05:51] <squeegily> MPlayer has earned a special spot in my heart [05:56] <Dr_Radium> is x265 much better than x264 ? [05:58] <Zeranoe> Dr_Radium: In what category? [05:58] <Dr_Radium> encoder category [05:59] <Zeranoe> Dr_Radium: Yes, but encoding speed, compression ratio, compatibility... etc [05:59] <Dr_Radium> compression ratio [05:59] <Zeranoe> Dr_Radium: It's marginally better [06:00] <Zeranoe> Dr_Radium: I would not recommend it for anything yet [06:00] <Dr_Radium> zeranoe why not [06:01] <Zeranoe> Dr_Radium: encoder speed is horrid. Compression is good, but not substantially better. Very beta source right now [06:01] <Zeranoe> Dr_Radium: It's more of a proof of concept right now IMO [06:07] <Zeranoe> Looks like I stumbled on a known bug... https://trac.ffmpeg.org/ticket/2208 [06:12] <squeegily> I managed to get my anime somewhat working with this command, thanks to you all! [06:12] <squeegily> sudo mplayer -lavdopts threads=4 -vo fbdev2 ~/Videos/Anime/Joshiraku/\[gg\]_Joshiraku_-_02v2_\[01AC8A77\].mkv -frames 4096 -fs -pp 0 [06:12] <squeegily> It can't handle scenes with too much motion, but at least it works! [06:14] <Zeranoe> squeegily: no idea what you're doing, but why sudo? [06:14] <squeegily> Zeranoe: Just to make sure the framebuffer would work [06:14] <squeegily> It's the 'video' group on Ubuntu? [06:15] <squeegily> The console is 1366x768 but the video is 1280x720.. mplayer seems to ignore the -fs flag..... [06:38] <Dr_Radium> what is best aac encoder [07:14] <Zeranoe> Dr_Radium: FDK-AAC [07:14] <Dr_Radium> is that better than apple or nero one? [07:14] <Dr_Radium> or google one [07:14] <Zeranoe> Dr_Radium: Yes [07:14] <Zeranoe> Dr_Radium: Is is the "Google one" [07:15] <Dr_Radium> fdk = frauhofer [07:15] <Zeranoe> Dr_Radium: Yes, but it's also the library that is included with the android SDK [07:15] <Zeranoe> if that's what you meant by "google one" [07:18] <Dr_Radium> no, there is google one [07:18] <Kei_N> he probably means the vo one [07:18] <Dr_Radium> there is lib vo [07:20] <Zeranoe> Dr_Radium: Well yes, it's better than vo [07:20] <Dr_Radium> what about compared to nero and apple [07:20] <Zeranoe> Dr_Radium: See https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio [07:21] <Dr_Radium> nero and apple is not listed there [07:22] <Zeranoe> Dr_Radium: It's better that both, but feel free to run your own tests and find out for yourself [07:23] <Dr_Radium> what is "opus" never heard of that one [07:23] <Zeranoe> Dr_Radium: It's not AAC [07:23] <Dr_Radium> then what is it [07:25] <Zeranoe> Dr_Radium: I believe it is a variant of ogg, but it specializes in lot latency and bitrate [07:25] <Dr_Radium> is it bette than vorbis? [07:26] <Zeranoe> Dr_Radium: Did you read the wiki page? [07:26] <Dr_Radium> libopus > libfdk_aac = libvorbis > libmp3lame >= libfaac >= eac3/ac3 > aac > libtwolame > vorbis > mp2 > wmav2/wmav1 > libvo_aacenc [07:26] <Zeranoe> So what does that tell you? [07:27] <Dr_Radium> google-aac is worst? [07:27] <Dr_Radium> why is eac3/ac3 ranked so low? [07:28] <Zeranoe> Dr_Radium: Because at the same bitrate as fdk-aac ac3 and such are worse [07:28] <Dr_Radium> i see [07:28] <Dr_Radium> is libfdk-aac new? because i didn't see this before until very recently [07:29] <Zeranoe> Relatively, probably within the last year [07:30] <Dr_Radium> why did it took so long [07:30] <Zeranoe> Dr_Radium: I don't understand the question, AAC has been around for a while [07:31] <Dr_Radium> zeranoe exactly [07:31] <Dr_Radium> my point [07:31] <Zeranoe> ? There have been plenty of other open source AAC encoders [07:32] <Dr_Radium> what took so long to release fdk one? [07:33] <Zeranoe> Sorry, but these questions are not worth loosing sleep. I'm heading to bed [10:45] <t4nk793> How do I split a video into smaller clips? I have this so far: http://pastebin.com/F6MWchYt How does that look in a "for" loop in Microsoft DOS? [10:48] <Mavrik> t4nk793, first, you have to add -codec copy if you don't want to ruin your quality [10:48] <Mavrik> second, I have no idea how that looks like in batch script :P [13:00] <t4nk793> How to escape quotations marks and get back in? [13:16] <t4nk793> How do I use a wildcard for file input? [14:33] <debianuser> t4nk793: Don't know about wildcards, I used bash scripts for it, e.g. `ffmpeg $(ls *.mp4 | sed 's/^/-i /') ...` It's not too important, because you have to manually configure mapping for each file usually anyway. [14:34] <debianuser> By the way, I have 3d half-side-by-side 1280x720 video, how can I reencode it to a single side video? "-vf stereo3d=sbs2l:ml" is not enough, I get just the left half which is displayed as 640x720, while I want to see it as 1280x720. I don't want to actually scale it (that's a last resort), just wanted set some tag to have it scaled by the device playing the file. Is there some option I miss? [14:54] <rhagu> hi I am checking a lot of mkvs for missing parts or corruptions. This is the command I use: "ffmpeg -v error -i "$X" -map 0:v -map 0:a -threads 3 -f null -" and this is a sample of the outputs I get: http://pastebin.com/cwcfTNKX I am actually looking for files missing parts of the video information due to a corruption in the underlying filesystem, the errors in the pastebin do not seem to be caused by something like this, do they? What do [15:03] <debianuser> It looks like an error in encoded data, but it's hard to tell if it's caused by the filesystem or it was there from the beginning. (I'm not familiar with those encoding format, can't tell what they mean) [15:04] <c_14> ye, what I'd probably do is just check for ffmpeg's exit code [15:05] <c_14> If you know how long the file is supposed to be, you can also check things like the length etc [15:07] <debianuser> rhagu: If you're checking some downloaded files - you can check for files itself. E.g. there're integrity checksums in torrent file. Or you can do it the other way and just watch the files (especially during those "error" moments). Who cares it's corrupted if it plays fine. :) [15:15] <rhagu> no torrents, so there is no checksum file [15:16] <rhagu> it is too many files to watch them to find the errors [15:19] <c_14> rhagu: what kind of corruption are we talking about here? bit-failures or more like head-crash? [15:31] <rhagu> c_14 xfs filesystem on zfs volume, the zfs volume was shrunk from 8TB to 6TB and 2 TB of data were lost, then it was set back to 8TB and xfs repaired, so the filesystem does not "see" the missing 2TB, but they are not there anymore, but 6TB of mkv data are still good, some files may not be affected at all, others partly and some may be gone for good [15:33] <iive> i don't think you can shrink xfs... at least not with the xfs tools. [15:37] <rhagu> iive you cannot i shrinked the block device xfs was on, which was the reason I lost 2 TB of data [15:39] <iive> was it lvm? [15:40] <rhagu> iive not really, it was a zvol of zfs, I checked if the data can be rescued but the people over at #zfsonlinux told me it can not, so I am trying to figure out which files are still "good" and which need to be replaced [15:41] <iive> never heard of it, so zfs provides volumens/partitions that could be formatted with another filesystems? [15:44] <c_14> rhagu: I'd probably just check the fatal loglevel [15:44] <debianuser> rhagu: How are you going to replace them? Do you have a backup somewhere? I mean maybe you can just compare against that backup? [15:46] <rhagu> iives yes, they are called zvols and behave like block devices [15:46] <rhagu> c_14 is there a summary that shows the differences between fatal and error? [15:47] <rhagu> debianuser they are on blu rays and I would need to reread every one of them [15:47] <c_14> http://ffmpeg.org/ffmpeg.html [15:47] <c_14> under loglevel [15:48] <rhagu> c_14 thanks I will have a look [15:50] <rhagu> "cannot continue after" seems fine, I will run it with this setting and see, what turns up, may take some time though :-D [16:15] Action: debianuser still looks for a way to make decoding device show a 640x720 video (got with ffmpeg from 1280x720 video by "-vf stereo3d=sbs2l:ml") as a 1280x720... Shouldn't "stereo3d" filter do that on its own? [16:34] <c_14> debianuser: it probably should... (at least if my understanding is correct) [16:38] <JEEBsv> you probably have to actually signal somehow to the device what the content is [16:39] <JEEBsv> at least x264 has related settings to that [16:39] <JEEBsv> http://up-cat.net/p/15a661e5 [16:39] <JEEBsv> that's for the x264 command line encoder, you probably will have to use -x264opts or so to set the API-wise setting [16:40] <JEEBsv> and of course, there is no way to know if the player you'll play your content with will support that specific way of signaling :P [16:41] <JEEBsv> also if it's the other way (part of side-by-side being encoded), then you will have to make sure the SAR is correct [16:50] <debianuser> JEEBsv: No, it's the other way around. :) I have a 3d half-side-by-side 1280x720 video and trying to encode it as usual 2d video to play on a regular 2d player. The problem is that after doing "-vf stereo3d=sbs2l:ml" I get a 640x720 video, which looks narrow... [16:51] <JEEBsv> yes, should then use setsar filter to set a 2:1 SAR [16:51] <JEEBsv> because the samples should be two times as wide as they are high [16:52] <debianuser> Trying, thanks! Looking into the docs... [16:52] <vivan> are planar 10-bit formats (yuv420p10le, yuv422p10le, yuv444p10le) padded to 16 bits (and essentially the same as 16-bit formats)? [16:53] <JEEBsv> basically they use the 10 least significant bits out of the 16 [16:54] <vivan> thanks [17:10] <debianuser> Tried "-vf stereo3d=sbs2l:ml,setsar=2/1" - worked for mplayer, but not for targetted hardware player. I guess it does not support non-square pixels... Unless there's some other option that I forgot to set. [17:12] <JEEBsv> yeh, hw shit can fail in various ways although usually the ways that ffmpeg sets should work in most things [17:12] <JEEBsv> my condolences if your shit is not one of those [17:13] <JEEBsv> I guess you can just use the scale filter to scale to 2x the width [17:13] <JEEBsv> (this is usually the less preferred way to do it because you're creating unnecessary data [17:18] <MaximLevitsky> I implemented simple encoder using ffmpeg, but resulting mp4 files don't play well in some players, including totem, OSX quicktime,windows media player [17:18] <MaximLevitsky> Could you take a look, at what I do wrong? [17:18] <MaximLevitsky> https://github.com/maximlevitsky/animations-editor-bdmorph/blob/master/util… [19:09] <t4nk910> hi guys [19:11] <t4nk910> is there any known issue for mp4 video to go black (something like 85% opacity) for a few seconds in chrome/ff and then get back to normal? [19:11] <pzich> at a particular time? or periodically? [19:11] <t4nk910> periodically [19:12] <t4nk910> and not always.. [19:12] <debianuser> MaximLevitsky: Check compatibility section of https://trac.ffmpeg.org/wiki/Encode/H.264 [19:12] <pzich> not always meaning not for every video, or for different playbacks of the same video? [19:12] <t4nk910> for example for me the video loads ok, but for my friends sometimes they get this issue [19:12] <pzich> ah, hmm [19:13] <pzich> and this is Chrome and FF, not Chrome vs FF? [19:13] <t4nk910> yes, chrome and ff [19:13] <t4nk910> they experienced the issue in these 2 browsers.. [19:16] <t4nk910> pzich: yes, for different playbacks of the same video [19:23] <AlexRussia> hey [19:23] <AlexRussia> if i have cue file with metadata and flac with tracks, can i split flac by metadate in cue? [19:23] <AlexRussia> metadata* [19:26] <pzich> well, googling "ffmpeg cue file" brings up this: https://bbs.archlinux.org/viewtopic.php?pid=702289 [19:26] <pzich> looks like maybe not with ffmpeg, but shntool can? [19:28] <AlexRussia> pzich: yep, looks like shntool is what i need [19:29] <AlexRussia> pzich: i just prefer live people than search machine :) [19:29] <AlexRussia> pzich: i thought, isn't complicated question xD [19:29] <pzich> we prefer search machine first, then machines are doing the work instead of other people :) [19:30] Action: c_14 doesn't mind if you ask dead people first [19:30] <AlexRussia> pzich: just i can reask ppl about misunderstanding parts, with static text i can't do it :P [19:31] <AlexRussia> c_14: xD [19:32] <AlexRussia> re-ask* [20:07] <shevy> got a question [20:07] <shevy> when I chop off the first 5 minutes of an .avi file, I must re-encode the full movie, and hence will lose quality? [20:10] <JEEBsv> in theory if you can do it properly with that format, you could encode the required GOPs [20:11] <JEEBsv> and stitch them to the rest of the GOPs [20:11] <JEEBsv> but [20:11] <JEEBsv> 1) not automagically supported in ffmpeg 2) not sure if even applicable with your formats [20:14] <debianuser> shevy: Actually I *think* it should work: ffmpeg -ss 300 -i fullfile.avi -map 0 -c copy chopfile.avi [20:15] <debianuser> (at least a similar idea worked in mencoder a few years ago, so why shouldn't it work in ffmpeg...) [20:17] <shevy> ah ok [20:19] <JEEBsv> yeah, if you can cut right on the GOP and that's OK then that should work [20:20] <JEEBsv> but as soon as as the GOP points are not on that very point you start getting a difference [20:21] <mnewton> Hey guys, codec question. I have a file that has the following codec information. What's codec should I use that will be optimized for the web (that is fast - about 1 min per 100mb) Video: h264 (avc1 / 0x31637661), yuv420p, 640x480 [SAR 39:40 DAR 13:10], q=2-31, 135 kb/s, 10 fps, 10240 tbn, 10 tbc (default) Audio: aac (mp4a / 0x6134706D), 22050 Hz, mono, 32 kb/s (default) [20:22] <mnewton> What would the ffmpeg command look like. Sorry I dont have much idea about codes or ffmpegs - i just want to make some lecture videos avilable on s3 for streaming and the file size if huge even though it is low quality [20:30] <iive> mnewton: hum? the line you pasted shows that the video bitrate is 135kb/s, so that's about 8MB for 1 minute [20:31] <mnewton> iive, okay - i meant that processing 100mb should take about 1 min when converting [20:31] <mnewton> Is 8MB for 1 min decent for web? [20:32] <iive> 1mbps (mega bits per second) is usually good quality for SDTV (720x576x25) [20:32] <iive> you can probably go lower, since you have smaller resolution and framerate. [20:32] <mnewton> okay [20:33] <mnewton> what should I try? [20:33] <mnewton> it is a .m4v file [20:33] <iive> avc (advanced video coding) is also know as H264. it is quite good and widely supported codec. [20:34] <iive> ffmpeg uses libx264 for encoding in this format. imho that's the best encoder that there is. [20:34] <mnewton> isn't it already in it? Video: h264 (avc1 / 0x31637661) [20:35] <brontosaurusrex> mnewton: not by default, thats probably a container [20:36] <brontosaurusrex> or rather "format" [20:36] <mnewton> okay - so how do I convert it? [20:37] <iive> ffmpeg -i <input_file> -c copy -c:v libx264 -crf 24 -preset fast <output>.mp4 [20:40] <iive> hum.... [20:40] <iive> kb/s is kbps [20:41] <iive> sorry for the confusion. [20:41] <iive> the video is 135kbps, not 1000kbps, it is already insanely low. [20:42] <iive> same for the audio. 128kbps is plenty for 44kHz stereo, you have 22kHz mono, that is 32kbps. [20:42] <iive> I don't think you can get lower than these [20:44] <mnewton> ok [20:49] <mnewton> how do i get it from a m4v container to a mp4 container [20:51] <brontosaurusrex> mnewton: thats the same thing, just rename [21:16] <Zeranoe_> Is it possible to set the handler_name for audio/subtitles? It defaults to "SoundHandler" [21:19] <Fjorgynn> let there be cake [23:17] <lm_> Hi. I need of help [23:18] <lm_> Hello! [23:18] <c_14> Don't we all. [23:19] <lm_> How enable suport to libmp3lame in ffmpeg? [23:19] <c_14> --enable-libmp3lame [23:19] <c_14> probably [23:19] <lm_> not work [23:20] <c_14> error? [23:20] <lm_> ERROR: libmp3lame >= 3.98.3 not found [23:20] <c_14> Is it installed? [23:21] <lm_> Yes. I have LAME 64bits version 3.99.5 [23:21] <c_14> distro? [23:22] <lm_> linux mint 17.1 64 bit [23:25] <c_14> Did you install the -dev version? [23:25] <lm_> not [23:25] <c_14> install it and try again [23:26] <lm_> OK. [23:32] <lm_> Has worked [23:32] <lm_> Thank's [00:00] --- Sun Dec 28 2014

1 0

ffmpeg-devel.log.20141226
by burek 27 Dec '14

27 Dec '14

[00:08] <ubitux> so what is the netpbm for audio? [00:43] <ubitux> ah, seems gnuplot can take raw binary, cool. [00:44] <ubitux> well, then no problem to solve [01:11] <ubitux> mmh, so pthreads is prefered over atomics for the buffer pool? [01:42] <ubitux> helgrind really doesn't like the "state" var access in lavc/pthread_frame.c [02:23] <cone-99> ffmpeg.git 03Michael Niedermayer 07master:68609edd4acf: Changelog: Mention non continuous cache protocol [02:23] <cone-99> ffmpeg.git 03Michael Niedermayer 07master:954fc854f237: avformat/cache: cleanup cache file on cache write failure [02:23] <cone-99> ffmpeg.git 03Michael Niedermayer 07master:ce3551896ab4: avformat/cache: keep cache_pos updated [02:23] <cone-99> ffmpeg.git 03Michael Niedermayer 07master:312151bb9af6: avformat/cache: avoid lseek() on reading from the cache if possible [02:23] <cone-99> ffmpeg.git 03Michael Niedermayer 07master:7c210c442462: avformat/cache: Extend cache entries if possible instead of creating new ones [06:53] <jamrial> michaelni: commit 954fc854 broke msvc because it lacks ftruncate (yes, even vs2013) [06:53] <jamrial> seems _chsize_s() can be used for this [07:02] <anshul_mahe> I have created scte-35 decoder, which tells the PTS from advertisement start and where it should stop [07:03] <anshul_mahe> but looking at encoder of hls, dash and hds there every muxer have different requirement for placing those cue message [07:04] <anshul_mahe> even if some muxer prefer xml, there xml format is different. [07:04] <jamrial> Daemon404, nevcairiel: can you test if this works? http://pastebin.com/d6atRQtW [07:06] <anshul_mahe> Should I make filter, for scte35 ts to hls m3u8 and scte35 hls to ts and so on [07:15] <fffan> is ffmpeg slower compiled by microsoft toolchain run slower than mingw's toochain? [07:16] <jamrial> afaik, yes [07:17] <jamrial> the lack of inline asm support is one reason [07:20] <fffan> are there benchmark between them? how much is microsoft's version slower than? [07:48] <jamrial> no idea how much, never used it [08:00] <anshul_mahe> What should be used for data stream, when encoding and decoding does not make much sense, but I want to use same functionality across diferent muxer [10:00] <anshul__> I do have some structure, which is common in encoder and decoder, where should I decleare it, but it is very specific to my protocol [10:58] <fffan__> I use ./configure --enable-hwaccel=h264_dxva2 --enable-shared --disable-static --enable-w32threads in mingw env, but h264_dxva2 is not enabled after configuration. [11:07] <nevcairiel> You may be missing the dxva headers. Original mingw doesn't have any, use mingw-w64 [11:09] <fffan__> yes, I found it dxva2api.h: No such file or directory [11:10] <fffan__> I am googling how to dxva2 to mingw [11:29] <cone-661> ffmpeg.git 03Stefano Sabatini 07master:afaa4a894631: lavfi/blend: add difference128 mode [12:17] <michaelni> anshul__, common structures are commonly put in common files like foo.h for a foodec.c and fooenc.c [12:19] <wm4> michaelni: what exactly is the avformat cache useful for? [12:27] <michaelni> it could be used to allow seeking backward in streams which come from a non seekable protocol / realtime streams. It could also be used to speedup working with stuff accessed over slow protocols [12:28] <wm4> the thing that IMO is missing here is running the real read accesses in a separate thread [12:29] <michaelni> yes [12:42] <cone-661> ffmpeg.git 03Michael Niedermayer 07master:0704c44d6870: avformat/cache: remove ftruncate usage, its not always available [12:51] <aetasx> any of you mess with librtmp and can look at something for me? [13:01] <anshul__> michaelni: i saw ur mail that day for missing decoder files, but those were not ready at that time, I will send them in day are two [15:20] <cone-661> ffmpeg.git 03Michael Niedermayer 07master:f7da4b1cf159: avformat/rtsp: Use av_freep() to avoid leaving stale pointers in memory [15:20] <cone-661> ffmpeg.git 03Michael Niedermayer 07master:4bc0dbfc9f05: avfilter/vf_boxblur: generate supported pixfmt list instead of hardcoding [15:50] <cbsrobot_> bdc4db0ee35 seems to have broken certain clang builds on darwin: http://fate.ffmpeg.org/?query=os:darwin [15:52] <nevcairiel> That looks like a ICE, not code error [15:53] <nevcairiel> Although chances are it fixes itself when the inline asm is ported to yasm [15:53] <nevcairiel> Patch on ML [15:53] <cbsrobot_> nevcairiel: I saw it, but it's not yet in [16:13] <BBB> ubitux: do you remember why p0tmp/q0tmp are different between 44 and !44 in lpf asm? [16:13] <BBB> ubitux: Im trying to unify that and its not working and I dont quite understand why, it seems like the values in the 44 case are somehow special, do you remember whats going on there? [16:31] <BBB> oh I guess youre reusing them in the h transpose [16:31] <BBB> ... [16:31] <BBB> hm... [16:32] <BBB> ok [16:37] <anshul__> where is av_format_get_subtitle_codec defined? [16:39] <wm4> you could find that in 1 sec with grep -r ? [16:39] <anshul_mahe> got it in libavformat/utils.c hidden in MAKE_ACCESSORS [16:39] <anshul_mahe> greped git log [16:39] <wm4> oh, so it's stupid accessor bullshit [16:40] <wm4> these macros just define functions to read or set a field [16:40] <wm4> nothing else [16:40] <anshul_mahe> yes I was adding some parameter in that structure, so needed those thing [16:57] <BBB> yay filter_44_v works on 32bit now [16:57] <BBB> a few more to go [17:02] <akira4> umm ubitux, how do I decide what parameters are to be set for the DVD streams? [17:04] <anshul__> in int av_codec_is_encoder(const AVCodec *codec) funtion if any one use encode older api then it will not recognise that encoder [17:04] <anshul__> it is done delibrately [17:05] <anshul__> sry for noise, i got it [17:28] <jamrial> michaelni: the patch for ftruncate on msvc i posted here last night didn't work? [17:52] <michaelni> jamrial, dunno, it just felt easier to drop ftruncate() usage to me. But if preferred we could put it back and apply the patch [17:53] <ubitux> BBB: so did you figure it out? [17:53] <BBB> yes [17:53] <ubitux> akira4: hi; i guess you get the "parameters" from the ifo parsing [17:55] <akira4> hmm. What do I set as the type for video codec? I've set it to raw video currently [17:55] <ubitux> but dvdnav probably provides an abstraction from this [17:55] <ubitux> mmh [17:56] <ubitux> it's probably mpeg2 [17:56] <akira4> hmm. that seems right. [17:57] <akira4> there is a function call dvdnav_get_spu_attr which seems to set some attributes regarding the subpictures [17:57] <ubitux> you need the resolution as well [17:57] <ubitux> i see there is a vm_get_video_res() function [17:57] <ubitux> and various other functions [17:59] <ubitux> look for "obtaining stream attributes" in the dvdnav.h header maybe [18:00] <akira4> Ah. I was trying dvdnav_get_video_aspect but I get a Invalid pixel format. Failed to open codec in av_find_stream_info [18:00] <akira4> any ideas on that? [18:02] <ubitux> i have no idea what you are doing, but again i'm not really familiar with dvdnav; i need to look into it [18:02] <ubitux> i'm not sure of the level of abstraction it actually provides [18:02] <ubitux> it looks like it's a bit low level (hence the initial code protocol wise) [18:04] <wm4> what [18:04] <wm4> akira4: just rely on the mpeg stream [18:04] <wm4> let the mpeg demuxer handle these things [18:05] <ubitux> wm4: so you suggest to open a mpeg demuxer? [18:05] <wm4> you might need to supply additional information (like aspect ratio or subtitle palette etc.), but that's "on top" of it [18:05] <wm4> ubitux: of course [18:05] <ubitux> ok [18:05] <ubitux> so a bit like vobsub then [18:05] <wm4> well not entirely sure, but since this is going to be crappy anyway (and not usable for players etc.), dumping the raw mpeg stream is best anyway [18:06] <ubitux> how do you actually interact with dvdnav? [18:06] <ubitux> you read buffer of data? [18:06] <wm4> otherwise, parsing mpeg could _maybe_ be used to get exact timestamp shifting (just a thought) [18:06] <akira4> alright. here is a link to the current diff http://pastebin.com/zA6KbzKu. I've removed the data packets part . [18:10] <BBB> ubitux: I have working ports for filter_44/48/84/88_v so far [18:10] <BBB> working on filter_16_v now [18:10] <BBB> Ill do the transposes separately [18:11] <BBB> (see github if you feel like reviewing) [18:12] <jamrial> michaelni: yeah, assuming it works, i think it would be better than removing ftruncate for all platforms [18:27] <cone-560> ffmpeg.git 03Kieran Kunhya 07master:18982f084c3e: swscale: Pass through chroma positions in sws_getCachedContext [18:27] <cone-560> ffmpeg.git 03Michael Niedermayer 07master:9224c7f0dd18: avfilter/vf_fspp: clarify comment [19:45] <cone-560> ffmpeg.git 03James Almer 07master:466e32bf25ac: x86/vf_fspp: port inline asm to yasm [19:47] <ubitux> BBB: will do when you're done [19:47] <ubitux> - for w in flower flour; do ffmpeg -v error -i "http://translate.google.com/translate_tts?tl=en&q=$w" $w.wav; done; md5sum *.wav [19:47] <ubitux> 50195a1e6063ea0c8dea8cd8a084df0e flour.wav [19:47] <ubitux> 50195a1e6063ea0c8dea8cd8a084df0e flower.wav [19:47] <ubitux> damn english. [19:50] <BBB> bakmeel, bloem [19:50] <BBB> better? [19:50] <jamrial> haha [19:51] <ubitux> :) [21:16] <BBB> ok everything except filter_16_h done (stupid transpose16x16b :D) [21:46] <cone-164> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:1abdfb100ac6: ffserver: break lines at 80 in func prototypes [21:46] <cone-164> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:ec4225171529: ffserver: reflow start_children() [21:46] <cone-164> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:18011888cc87: ffserver: reindent start_children() [22:21] <cone-164> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:719cc025869b: ffserver: reflow start_multicast() [22:21] <cone-164> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:978bc4327b11: ffserver: reindent start_multicast() [23:05] <cone-164> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:114622369939: ffserver: minor formatting improvement to http_server() [23:05] <cone-164> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:0121ddabb867: ffserver: reflow close_connection() [23:51] <BBB> ubitux: full set pushed, everything seems to work [23:51] <BBB> ubitux: https://github.com/rbultje/ffmpeg/commits/vp9-32bit [23:51] <BBB> ubitux: want a patchset on the ML? [23:53] <cone-164> ffmpeg.git 03Michael Niedermayer 07master:a4b13dbd02c7: avfilter/vf_fspp: Add GBRP and gray8 support [00:00] --- Sat Dec 27 2014

1 0

ffmpeg.log.20141226
by burek 27 Dec '14

27 Dec '14

[03:54] <justinX> merry ffmpeg to you :-D [04:16] <Dr_Radium> is x265 much better than x264 ? [04:35] <fahadash> Hi [04:36] <fahadash> I am trying to convert a 42MB wav file to mp3, and the command has been running for 2 minutes now, the file is created and it is at 3MB... Is it normal ? [04:37] <fahadash> this is my command: ffmpeg -loglevel panic -i /path/to/some.wav -b:a 64k /path/to/some.mp3 [04:39] <butters> Hi all, I run Debian sid and sadly experienced that all of my H.264 videos from my Canon 5D Mark III began having terribly garbled and corrupted playback for the past few weeks [04:40] <butters> I found out that it was a bug in libav, but not ffmpeg... [04:40] <butters> Finally tonight someone wrote a fix https://lists.libav.org/pipermail/libav-devel/2014-December/065937.html [04:44] <butters> My question is (other than 'wtf?') is what happened for this regression to occur? [04:46] <butters> They copied ffmpeg code and removed this and it broke, and now they're adding it back? Or is it a completely different section of code that handles H.264 decoding? [04:47] <butters> And what specifically about the videos produced by the Canon 5DMkIII make it hit this bug? [07:06] <fffan> if I wanna use "h264_dxva2", which compilation options should I use? [07:07] <anshul_mahe> may be --enable-libx264, not sure [07:08] <fffan> I am not sure --enable-hwaccel=h264_dxva2 is enough and correct [07:09] <anshul_mahe> try them, and see [07:10] <fffan> trying just take me too much time, my machine is too slow to compile ffmpeg, it takes me about 1 hour for compilation. [07:12] <anshul_mahe> ok, I will see for u [07:13] <anshul_mahe> What is dxva2 in h264_dxva2 [07:14] <anshul_mahe> ohh, its windows thing sry I am on linux [08:28] <Dr_Radium> is x265 much better than x264 ? [10:46] <hexhaxtron> I'm trying to use ffmpeg but I'm getting lots of these errors: xorg115/xf86-input-void 1.4.0-6 (xorg-drivers xorg) [installed: 1.4.0-7]: No such file or directory [10:46] <hexhaxtron> What can I do? [10:54] <wag434> hexatron: what are you trying to do? [13:22] <Easyfab> Hi, is there a equivalent from vpxenc --end-usage=cq --cq-level=x under ffmpeg with libvpx-vp9 ? [13:22] <rhagu> hi my distribution ships libav instead of ffmpeg and I am getting segmentation faults. Is there a distribution that ships ffmpeg? [13:23] <__jack__> rhagu: Debian [13:25] <iive> debian sid, it is not going to be in Jessie. [13:27] <rhagu> I see, do I need to download additional packages for vc-1 and h264? [13:30] <iive> no [13:30] <iive> for h264 encoding you'll need separate libx264 [13:31] <iive> but the libraries are decided by distro packagers. [13:31] <iive> if you are running gentoo, then it does have ffmpeg, but it needs a little tweaking, (it defaults to libav). [13:32] <iive> i mean, if ffmpeg is compiled without x264 support it won't use the library. if it is compiled with libx264, then it won't run if it is not installed too. [13:32] <rhagu> I actuall just want to check if my files are ok, for ubuntu I had to install ubuntu-restricted-extras package, but it uses libav and that faults [17:03] <c_14> rhagu: just use the static builds? [17:12] <rhagu> c_14 what would that be? [17:13] <c_14> http://johnvansickle.com/ffmpeg/ [17:13] <rhagu> this means compiling it myself, right? [17:14] <c_14> nah [17:14] <c_14> just download, extract, and run [17:25] <rhagu> c_14 thanks I will have another look at it [18:05] <Zeranoe> Are there any visual comparison examples for x264 crf 18 vs crf 20? Or someone who compared 18-22? [19:38] <wag434> good evening y'all [19:39] <wag434> c_14: I have looked into your suggestion and made some progress [19:39] <wag434> have compiled from scratch, started ffserver and used [19:39] <wag434> Error while opening encoder for output stream #0:1 - maybe incorrect parameters such as bit_rate, rate, width or height [19:39] <wag434> sorry [19:39] <wag434> have used [19:39] <wag434> ffmpeg -s 320x240 -f video4linux2 -i /dev/video0 -f lavfi -i aevalsrc=0 -c:a libmp3lame http://127.0.0.1:8090/feed1.ffm [19:39] <wag434> getting error above [19:40] <wag434> have remobed -s for testing, same result [19:45] <iive> wag434: is #0:1 the audio stream? then check libmp3lame options... maybe you can specify some bitrate? [19:49] <wag434> iive: actually I don't wnat to stream audio [19:49] <iive> then use -an [19:49] <wag434> trying, thanks. [19:50] <iive> and remove the other audio options. [19:51] <wag434> fiddling with it [19:51] <wag434> ./bin/ffmpeg -f video4linux2 -i /dev/video0 -an http://127.0.0.1:8090/feed1.ffm [19:52] <wag434> getting: Missing audio stream which is required by this ffm [19:53] <iive> then... back to mp3lame bitrate :| [19:55] <wag434> . [19:56] <wag434> ./bin/ffmpeg -f video4linux2 -i /dev/video0 -c:a libmp3lame http://127.0.0.1:8090/feed1.ffm [19:56] <wag434> same error message [19:56] <wag434> any reading / research you'd suggest, iive? [19:58] <iive> try adding -b:a 128k [19:58] <wag434> . [19:58] <iive> there is manual page, you can look up by `man ffmpeg` [19:59] <wag434> same message [19:59] <wag434> did quite some reading on ffmpeg on project page [19:59] <wag434> don't understand why an audio stream is required [19:59] <wag434> is that a video4linux2 thing? if so: can I opt for something else? [20:00] <wag434> I won't need any audio streaming for what I want to achieve [20:37] <iive> wag... [20:45] <kb22> iive, yes. changed nick [20:45] <kb22> to reflect stackoverflow... ;I) [20:46] <iive> oh.. well, it seems that the .ffm format is the one that requires audio [20:46] <iive> video4linux2 is linux kernel interface for capturing video, mostly analog tv (and cameras) [20:47] <iive> i believe that a(udio)eval(uation)src is generating sound as audio. [20:48] <kb22> ok, so I need to research how to create a non FFM feed [20:49] <kb22> and then look into feeding that feed without audio, right? [20:49] <iive> i guess.. [20:50] <iive> or you can try just -b 128k [20:50] <kb22> trying [20:50] <iive> around libmp3lame [20:50] <kb22> same thing, claims that audio is needed [20:51] <kb22> thanks for you time, I'll look into non ffm streams. [20:51] <kb22> your [20:53] <kb22> non ffm feeds [20:55] <iive> sorry, i'm not in condition today ... [20:59] <kb22> iive, na². your support is much appreciated, I'll get back to homework on this. [20:59] <kb22> enjoy your holiday, if you celebrate christmas. :) [21:00] <iive> ffmpeg syntax is quite convoluted. and the placement of options matters a lot.. [21:01] <kb22> avonv fork didn't help with that... [21:01] <kb22> avconv [21:02] <Mavrik> kb22, if you're using ffserver [21:02] <Mavrik> you need to say to ffserver that you don't want audio [21:02] <Mavrik> since ffserver.conf is the one controling the encoding, not the ffmpeg process [21:02] <kb22> Mavrik, ok how would I do that? I use the sample conf [21:03] <kb22> admitably new to the matter [21:03] <Mavrik> kb22, NoAudio or smthn [21:04] <kb22> looking into ti [21:04] <kb22> it [21:11] <kb22> ok, added NoAudio to mpeg stream in .conf [21:11] <kb22> running ./bin/ffmpeg -f video4linux2 -i /dev/video0 http://127.0.0.1:8090/feed1.ffm [21:11] <kb22> Mavrik, still getting [21:12] <kb22> Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [21:12] <Mavrik> kb22, is there a reason why aren't you reading the actual error message above? [21:13] <Mavrik> that's the generic muxer error message which is almost always preceeded by the error message from encoder which explains what's wrong. [21:13] <kb22> Mavrik, ok - sry about that. [21:14] <kb22> [mpeg1video @ 0x1f26cc0] bitrate tolerance 21333 too small for bitrate 64000, overriding [21:14] <kb22> [mpeg1video @ 0x1f26cc0] MPEG1/2 does not support 3/1 fps [21:14] <kb22> so I guess I need to experiment with different fps [21:14] <Mavrik> ew, what are you doing with MPEG2 O.o [21:14] <Mavrik> and yes, you'll have to use probably something like 25 or 29,976 or whatsit [21:15] <kb22> well, unfortunately I cannot answer that. I'm, fairly new to this and trying to get the samples I found on the internets to work [21:15] <kb22> lemme try different fps [21:16] <Mavrik> kb22, ok, let's do this again [21:16] <Mavrik> what are you trying to do [21:16] <Mavrik> and why are you trying to use a codec from 1995 do to it :) [21:17] <kb22> Mavrik, I am trying to set up my debian box to stream a webcam onto the internet [21:17] <kb22> not sure about the codec, just fiddling with samples from the net [21:17] <Mavrik> and how should that webcam be viewed? [21:18] <kb22> optimally through a browser [21:18] <kb22> as I figure [21:18] <Mavrik> *sigh* [21:18] <kb22> it would be way to slow [21:18] <kb22> to over ssh [21:18] <kb22> i.e. piping it into mplayer over ssh [21:18] <Mavrik> read this: https://www.virag.si/2012/11/streaming-live-webm-video-with-ffmpeg/ [21:18] <Mavrik> this will work on Firefox [21:18] <Mavrik> and maybe Chrome [21:18] <Mavrik> but not much else [21:19] <Mavrik> It uses VP8/WebM video codec for streaming [21:19] <kb22> ok [21:19] <kb22> allow me to turn the question around [21:19] <Mavrik> for anything more... I don't have enough time to explain all the basics you need to know :P [21:19] <kb22> well, ok - won't ask more then. ;) [21:19] <kb22> just one more: [21:20] <Mavrik> kb22, basically, long story short, browser live video support it shit [21:20] <kb22> what would be the general direction to look at for accessing that stream?= [21:20] <Mavrik> kb22, and if you want it simple, you'll have to pay alot, if you want it free, you'll have to learn alot [21:21] <Mavrik> the keywords you should be looking at for streaming that works on most browser and mobile devices is HLS [21:21] <Mavrik> and you'll need a proper streaming server [21:21] <Mavrik> and you'll have to use flash on desktop. [21:21] <kb22> meh [21:21] <kb22> @flash [21:21] <Mavrik> kb22, for a simple solution what I posted works ok [21:21] <kb22> ok, thanks again. [21:21] <Mavrik> but it's limited in terms of browser compatiblity [21:22] <Mavrik> everything else is a reason why we charge the big bucks to make that broken crap work :P [21:22] <kb22> I looked at [21:22] <kb22> zoneminder [21:22] <kb22> seemed to me to be a bit of a blob [21:23] <kb22> yet quite what I would want to do [21:23] <codehero> i want to use ffmpeg to stream to twitch but i also want it to save it to a file [21:23] <codehero> http://sprunge.us/AYdC i tried doing it like that but it doesn't work [21:24] <Mavrik> codehero, read the error mesage, continue. [21:25] <codehero> well. the problem is that i don't understand anything the message wants to tell me [21:28] <codehero> http://pastebin.com/dkT5fnTM that's the error message [21:28] <codehero> it's saying that i should add x264 options but i did [21:28] <codehero> or do i have to put that vcodec stuff in brackets? [21:29] <Mavrik> hrmf. [21:29] <Mavrik> codehero, no, it looks ok [21:29] <kb22> g [21:29] <Mavrik> codehero, how old is your ffmpeg? [21:29] <codehero> 2.5.2 [21:31] <Mavrik> hmmhmm [21:31] <Mavrik> now that error message makes no sense [21:31] <codehero> it works fine without the tee but then i can't write it to a file [21:31] <Mavrik> codehero, can you add -map 0:v -map 0:a [21:32] <Mavrik> right after "-f tee" ? [21:32] <codehero> sure [21:32] <codehero> "Stream map '0:a' matches no streams." [21:32] <Mavrik> huh [21:32] <Mavrik> codehero, ok, give us the full output of ffmpeg [21:32] <Mavrik> including the stream info [21:33] <codehero> http://pastebin.com/iFRTjb5m [21:34] <Mavrik> doh [21:34] <Mavrik> don't add "-map 0:a" [21:34] <Mavrik> only the v one, since you have no audio [21:35] <codehero> well, i actually do have audio [21:35] <codehero> it doesn't complain and seems to do something but it doesn't stream [21:36] <codehero> it does record [21:36] <Mavrik> well, in that output only video stream is mentioned :) [21:36] <Mavrik> ah [21:36] <Mavrik> wrong index [21:36] <Mavrik> codehero, add "-map 1:a" [21:37] <Mavrik> (since your audio steam is marked as Stream #1:0) [21:38] <codehero> ohhh. so that's how it works [21:38] <codehero> well, it saves to the file with audio now [21:38] <codehero> now i only need to get the streaming to work again [21:44] <codehero> weird [21:45] <Mavrik> Twitch might reject streams it deems not ok [21:45] <codehero> well. it did work without the tee [21:46] <codehero> hmm... it does upload something somewhere [21:47] <codehero> now streaming doesn't work at all \o/ [21:48] <codehero> sometimes i just feel stupid [21:50] <codehero> well. obs works so twitch isn't blocking me [21:50] <codehero> dang it [21:51] <kb22> Mavrik, copied Virág's post. ffserver still complains about FPS. Won't accept 25, 29 nor 29.97. Feeling altruistic enough to look into it? ;) [21:52] <Mavrik> codehero, it might simply be that RTMP and FLV files aren't compatible for tee :/ [21:52] <codehero> hmm. that might be possible [21:52] <Mavrik> kb22, VP8 can accept any framerate, so you did something wrong with the config file [21:52] <Mavrik> codehero, e.g. one is header-only format, other isn't or some crazy stuff like that [21:52] <kb22> Mavrik, ok - double checking. [21:54] <Fjorgynn> so [22:05] <queeq> Hi all. I'm trying to stream from usb webcam though ffserver but getting errors with standard configs. ffmpeg grabs from /dev/video0 just fine, feeds it to ffserver but once I connect to it it gives tons of "Too large number of skipped frames" messages. [22:07] <vibhavsinha> When doing two-pass encoding, mbtree and log files are created after pass1 and used in pass2. When running double 2-pass encoding in the same folder and I can see there is just one file being created. [22:08] <kb22> Mavrik, it worked. Thanks a bunch. Proof of concept done, much more tweaking coming me way I guess. [22:09] <queeq> That's with avi format and mpeg4 codec. libx264 doesn't work at all giving creepy errors like faulty default settings in ffmpeg for libx264. Encodes fine for file output though... [22:22] <codehero> Mavrik: yeah. seems to be the header stuff. it says that it needs to have a header when specifying a container [22:32] <codehero> Mavrik: i managed to fix it :) [22:32] <codehero> i had to add "-flags +global_header" [22:51] <Fjorgynn> You like me [23:01] <vibhavsinha> I am getting errors when running multiple instances of two-pass encoding in the same folder. There is only a single mbtree and log file generated. How to do mulitple two pass encoding in the same file. [23:01] <vibhavsinha> *folder [23:02] <vibhavsinha> during pass2, I get the error: statistics are damaged at line 149019, parser out=0 [23:02] <c_14> set the passlogfile prefix with -passlogfile [23:03] <c_14> Make it something different per encode [23:04] <vibhavsinha> Thanks. That solved it. [23:04] <vibhavsinha> Was not able to find it after multiple internet searches... [23:10] <c_14> It's in the man pages. If you know what you're looking for. [23:20] <queeq> What to do if v4l2 driver lowers the resolution from a webcam? Webcam's native res is 1280x960, v4l2 sets it to 640x480 [23:25] <c_14> use -s 1280x960 as an input option? [23:29] <ramiro_> some webcams support higher resolutions only for still pictures, not for video [23:31] <BtbN> 720p via USB 2(Or even 1.1 on crappy webcams) is just a lot of data [23:32] <queeq> When I try to set size manually it gives "[video4linux2,v4l2 @ 0x1e24660] The V4L2 driver changed the video from 1280x960 to 640x480" [23:33] <queeq> I have this cam: http://www.hercules.com/us/legacy/bdd/p/18/hercules-deluxe-webcam/ [23:33] <queeq> So the question must be if there is some way to influence the driver [23:34] <queeq> Cam specs say: 1.3 Mega pixels (still image), 1280x960 VGA resolution (still image and video) [23:34] <BtbN> 1280x960 != VGA Resolution [23:35] <BtbN> 1280x960 is 1.3MPixels [23:35] <queeq> oops [23:35] <queeq> :) [23:35] <BtbN> I'd read that as "1.3 Mega pixels (still image), 1280x960" and "VGA resolution (still image and video)" [23:36] <queeq> Maybe I'll need series of still pictures then... [23:37] <queeq> I wonder how to do that with ffmpeg [23:37] <BtbN> You won't be able to do that in realtime [23:37] <BtbN> USB is too slow [23:39] <queeq> Well, its bitrate on 640x480 is less than 100kbit/s, I don't think 1280x960 would not fit into USB [23:41] <queeq> Even USB 1.1 low bandwidth mode is 1.536 Mbit/s [23:41] <BtbN> It's 100kbit/s encoded [23:42] <BtbN> but the webcam sends it entirely uncompressed, raw pixels [23:42] <BtbN> That's quite a lot of bandwidth, even for low resolutions [23:42] <BtbN> 720p, depending on the framerate, is already too much for USB2 [23:42] <BtbN> I'm not even sure if 720p30 still fits in [23:43] <queeq> What encodes it then? Driver? ffmpeg reports it's encoded. [23:43] <c_14> BtbN: some webcams actually produce H.264 output [23:44] <BtbN> hm, never seen one of those then [23:47] <queeq> Is there any way to measure the actual "traffic" going through the usb port? [23:51] <ramiro> some webcams also send mjpeg or mpeg [23:57] <queeq> Is there a way to detect that? [00:00] --- Sat Dec 27 2014

1 0