Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

February 2014

1 participants
56 discussions

ffmpeg-devel.log.20140222
by burek 23 Feb '14

23 Feb '14

[00:02] <cone-449> ffmpeg.git 03Michael Niedermayer 07master:8c55ff393340: avcodec/h264: use subsample factors of the used pixel format [04:23] <cone-746> ffmpeg.git 03Michael Niedermayer 07master:44b22bba422b: avcodec/h264_ps: fix printed num_reorder_frames value [09:56] <ubitux> michaelni: any comment on the png fix? [10:37] <michaelni> ubitux, replied [10:38] <ubitux> mmh ok [11:56] <cone-550> ffmpeg.git 03Carl Eugen Hoyos 07master:b89596a43250: Fix FSF address in colormatrix and libzvbi license headers. [13:14] <cone-550> ffmpeg.git 03Paul B Mahol 07master:8bcacd9f4262: SDR2 demuxer [13:25] <aca> I have now working FFmpeg Debian packages, build with --enable-raise-major to avoid conflicts with libav packages. I named the development packages lib*-ffmpeg-dev, and only these are not coinstallabel with the libav versions, but having both dev packages wouldn't be useful anyway. [13:27] <aca> I rebuilt the 108 reverse dependencies of src:libav and 50 failed to build (but even more fail to build with libav10). The most common failures were due to missing AVCODEC_MAX_AUDIO_FRAME_SIZE and CodecID. Is there something like a migration guide for these common errors? [13:34] <JEEB> there's some migration documentation written over at libav at least, and since these changes generally are the same with ffmpeg, I would guess it's useful as well? https://wiki.libav.org/Migration/10 [13:34] <JEEB> CodecIDs became AV_CODEC_ID and AVCodecID [13:35] <aca> Thanks, I'll look at that. [14:37] <cone-550> ffmpeg.git 03Michael Niedermayer 07master:f288e1b67cba: avformat/utils: factorize h264/hevc checks out in compute_pkt_fields() [14:37] <cone-550> ffmpeg.git 03Michael Niedermayer 07master:d4dfa97ae3ad: avformat/utils: reset pts_buffer in estimate_timings_from_pts() [14:37] <cone-550> ffmpeg.git 03Michael Niedermayer 07master:3c096751ffe8: avformat/utils: compute_pkt_fields: Fix DTS for the case where has_b_frames is too large but the correct one is constant [16:03] <cone-550> ffmpeg.git 03Luca Barbato 07master:d922c5a5fbaf: h264: Fix a typo from the previous commit [16:03] <cone-550> ffmpeg.git 03Michael Niedermayer 07master:f98821dddb4a: Merge remote-tracking branch 'qatar/master' [16:34] <BBB2> ubitux: ty! [19:18] <BBB2> ubitux: question - is atom 64bit or 32bit only? [19:20] <ubitux> it's 64 [19:20] <BBB2> thnx [21:05] <cone-550> ffmpeg.git 03Peter Ross 07master:6236debe1a28: avcodec/raw: add bayer formats [21:05] <cone-550> ffmpeg.git 03Peter Ross 07master:55479f42ce60: avformat/nut: add bayer colorspaces [21:11] <cone-550> ffmpeg.git 03Anton Khirnov 07master:7e86c27b4ee9: lavr: add a function for checking whether AVAudioResampleContext is open [21:11] <cone-550> ffmpeg.git 03Michael Niedermayer 07master:5367c0be6238: Merge commit '7e86c27b4ee9e5a3fbe6cf5249b9d918b2a5e731' [21:13] <ubitux> it's really too bad hqx seems to work in the yuv domain [21:15] <wm4> did you mean "not"? [21:16] <cone-550> ffmpeg.git 03Anton Khirnov 07master:1db03a686411: lavr: return an error if a avresample_open() is called on an open context [21:16] <cone-550> ffmpeg.git 03Michael Niedermayer 07master:246eae98cfe4: Merge remote-tracking branch 'qatar/master' [21:18] <ubitux> wm4: no [21:19] <ubitux> i mean it's for 8-bit rgb games [21:19] <ubitux> it's too bad to require a convert for analysis [21:26] <ubitux> just ran http://pastie.org/8759318 on a ffmpeg objdump [21:26] <ubitux> not sure if it's accurate... but http://pastie.org/pastes/8759317/text [21:26] Action: ubitux go back doing interesting stuff [22:17] <BBB2> this will probably get lost in the netsplits, but ffvp9 blogpost: http://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ff… [22:19] <beastd> BBB2: thanks for highlighting and quite elaborate blog post. will read it tomorrow or so. [22:25] <ubitux> https://news.ycombinator.com/item?id=7283668 [22:41] <Daemon404> BBB2, that's an extremely useful link, thanks [22:41] <Daemon404> your former coworker reached out to vimeo yesterday with some bogu claims [22:41] <Daemon404> that link is helpful to me [22:45] <ubitux> where is llogan when we need him [22:46] <Daemon404> pff [22:46] <Daemon404> i try and upvote it [22:46] <Daemon404> but nothing happens [22:46] <Daemon404> hn is broken for me \o/ [22:47] <ubitux> is it a newly created accoutn/ [22:47] <ubitux> ? [22:47] <Daemon404> no [22:47] <Daemon404> but i do only have one point [22:47] <BBB2> Daemon404: which former coworker? [22:48] <Daemon404> it was one of the main guys... i cant remember his name, sec [22:48] Action: Daemon404 checks git [22:48] <Daemon404> iirc he gave a talk about it before you once [22:49] <Daemon404> crap i cant remember his name now [22:50] <Daemon404> but he gave some ridiculous claims [22:50] <Daemon404> like only 5x slower than x264 with 1/2 the size [22:50] <Daemon404> for same quality [22:50] <BBB2> marketing or engineer? [22:50] <Daemon404> not sure... i swear it was an engineer, but i could be wrong [22:51] <BBB2> lou, matt, jim, paul? [22:51] <Daemon404> might be matt or jim... i'd have to ask my coworker who was on the call [22:52] <BBB2> lou quillio is webmaster [22:52] <BBB2> matt frost is product manager (marketing) [22:52] <BBB2> jim bankoski is engineering manager [22:52] <Daemon404> it was someone from the chrome team who reached out to us to try and sell us on using vp9 [22:52] <BBB2> paul wilkins is lead engineer [23:11] <BBB2> kierank: oh you'd find that interesting also [23:14] <cone-550> ffmpeg.git 03Michael Niedermayer 07master:f284e2a58a13: swresample: factorize clear_context() out [23:14] <cone-550> ffmpeg.git 03Michael Niedermayer 07master:a89c01253190: avformat/mux: support shifting timestamps so they start at 0 [23:14] <cone-550> ffmpeg.git 03Michael Niedermayer 07master:717ec57c7e22: avformat/movenc: shift positive timestamps to 0 if edit lists cannot be used [00:00] --- Sun Feb 23 2014

1 0

ffmpeg.log.20140222
by burek 23 Feb '14

23 Feb '14

[00:58] <Logicgate> i need help [00:58] <Logicgate> http://pastebin.com/2GnUn53w [00:58] <Logicgate> here's the output [00:58] <Logicgate> This video has 2 video streams and I'm trying to watermark it [00:59] <Logicgate> As stated in the pastebin I get these two errors: [00:59] <Logicgate> Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [00:59] <Logicgate> and: [00:59] <Logicgate> [libx264 @ 0x272db40] height not divisible by 2 (640x361) [01:00] <Logicgate> how can one pick the right stream? [01:01] <Logicgate> http://pastebin.com/NrhWJFDw [01:01] <Logicgate> here is the ffprobe pastebin of that video [01:04] <Logicgate> God damn it. No one isn't ever there to help :( [01:18] <klaxa> Logicgate, you can't encode with libx264 to a resolution where one of the dimensions isn't divisible by 2 [01:19] <klaxa> also, can you add the command you used too? [01:19] <klaxa> to the pastebin i mean [01:19] <klaxa> because i can't see what your actual input is [03:16] <Snowleaksange> Tonight is one of the 4 sacred times a decade that I upgrade ffmpeg. [03:16] <Snowleaksange> Peace and blessings be upon us all. [05:11] <LithosLaptop> +- [06:45] <Snowleaksange> apparently av_resample died and went to heaven [06:49] <Snowleaksange> but i can cope with that if i remain VERY CALM [08:01] <Snowleaksange> av_rdft_calc crashes in ff_fdct_sse2 @ 0x00000000 [08:02] <Snowleaksange> are SSE instructions an optimiazation or a DOS on users? [11:35] <jclairem> do you know if ffmpeg can use gpu of Rpi to encode H264? [11:47] <relaxed> jclairem: I doubt that's possible. [11:52] <pron> can fmpeg use gpu to encode stuff on x86?:} [11:52] <Snowleaksange> this ffmpeg upgrade going REASONABLY well [11:52] <relaxed> pron: no [11:53] <Snowleaksange> got fft, and image decoding working. mp3 decoding almost works but sounds really staticy. having test moving decoding, or video encoding, or windows portability [11:53] <Snowleaksange> havent* test [12:05] <Snowleaksange> hrm av_probe_input_format not working now [13:45] <Snowleaksange> got video playback working... now for audio.. simultaneous change to avcodec_decode_audio4 from 3 with changed resampling library next [13:45] <Snowleaksange> looks like i dont have to keep this annoying overflow buffer i had before [13:46] <Snowleaksange> will simplify my code ince i figure out magic params [14:03] <DelphiWorld> Hi FFMpegifiers [14:03] <DelphiWorld> question [14:03] <DelphiWorld> this broadcom cristal [14:03] <DelphiWorld> is a encoder or decoder? [14:08] <davesa> guys i have a question, i tried a lot, with ffmpeg no go while vlc usinf faad works fine: [14:08] <davesa> [aac @ 0x37a5200] channel element 0.0 is not allocated [14:08] <davesa> Last message repeated 6 times [14:08] <davesa> [h264 @ 0x37a47a0] mmco: unref short failure [14:08] <davesa> Last message repeated 1 times [14:08] <davesa> [aac @ 0x37a5200] channel element 0.0 is not allocated [14:08] <davesa> its 0 : 0 [14:08] <davesa> i was reading online i see people says i need to use faad audio encoder [14:09] <davesa> which vls use [14:09] <JEEB> how old is your ffmpeg? [14:09] <JEEB> or libavcodec in general [14:09] <davesa> i run vlc in debug mode and i see it use faad so the sound work fine [14:09] <davesa> latest [14:09] <JEEB> latest as in? [14:09] <davesa> fmpeg version N-60700-g07b4b0c Copyright (c) 2000-2014 the FFmpeg developers [14:09] <davesa> built on Feb 17 2014 08:35:59 with gcc 4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) [14:09] <JEEB> latest release is not latest HEAD, and neither of those is generally the latest what distros package [14:09] <JEEB> ok [14:09] <JEEB> so 07b4b0c [14:10] <davesa> yes [14:10] <davesa> i tried to enable faad but ffmpeg does not recognize as decoder [14:11] <davesa> and i read ffmpeg discontinue faad for the behalf of libfdk_aac and AAC [14:11] <davesa> but i tried both no go [14:11] <davesa> its been 2 days trying to get it to work [14:11] <davesa> no go [14:11] <davesa> :( [14:12] <JEEB> ok, so a commit pushed ~5 days ago [14:13] <Peace-> hello i would like to know fi there is a way to set microphone using ffmpeg and pulse i was using this , i guess no but i will ask anyway , ffmpeg -f alsa -ac 2 -i pulse test.flac [14:13] <Peace-> it starts pulse but mic is the internal one [14:13] <JEEB> davesa, feel free to report the issue on the trac with a sample that replicates it [14:13] <Peace-> i wish to start ffmpeg with another mic [14:14] <davesa> how to do a sample? [14:14] <JEEB> well, what's your input? [14:14] <JEEB> also does it actually fail at doing stuff or does it just spurt warnings? [14:14] <davesa> i have mpegts [14:14] <davesa> mp4 [14:14] <davesa> i try to read the stream from multicast [14:15] <davesa> i am sending stream using my tvheadend addon [14:15] <davesa> to multicast [14:15] <JEEB> does it only happen when you try to read it from network, or does it also happen with the same thing as a file? [14:15] <davesa> i never tried from file [14:15] <davesa> look what i find so far [14:15] <JEEB> try that once, I guess. That way we can take the network part out of it [14:16] <JEEB> if it also happens with a file [14:16] <davesa> ffprobe -show_format -i http://192.168.15.135:8200/teststream [14:16] <davesa> i get this [14:17] <davesa> Stream #0:0[0x33d]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, smpte170m), 544x480 [SAR 40:33 DAR 136:99], 29.17 fps, 59.94 tbr, 90k tbn, 59.94 tbc [14:17] <davesa> Stream #0:1[0x335](spa): Audio: aac ([15][0][0][0] / 0x000F), 0 channels, fltp, 96 kb/s [14:17] <davesa> [FORMAT] [14:17] <davesa> filename=http://192.168.15.130:8200/118antenalatina [14:17] <davesa> nb_streams=2 [14:17] <davesa> nb_programs=1 [14:17] <davesa> format_name=mpegts [14:17] <davesa> format_long_name=MPEG-TS (MPEG-2 Transport Stream) [14:17] <davesa> start_time=32856.922167 [14:17] <davesa> duration=N/A [14:17] <JEEB> just dump some of your stuff and see if it happens as file as well [14:17] <davesa> size=N/A [14:17] <davesa> bit_rate=96000 [14:17] <davesa> probe_score=100 [14:17] <davesa> [/FORMAT] [14:17] <davesa> if i define [14:17] <JEEB> and use a goddamn pastebin >_< [14:17] <DelphiWorld> davesa: pastebinnnnnnnnn! [14:17] <davesa> the ar before [14:17] <davesa> loool [14:17] <davesa> ok [14:18] <davesa> sorry [14:18] <DelphiWorld> lol JEEB [14:18] <JEEB> anyways, please. Dump some data that you're getting from that thing [14:18] <JEEB> and try with a file [14:18] <davesa> what command do you siggest me to dump? [14:18] <JEEB> I have no idea what would be 1-to-1 dumping [14:18] <DelphiWorld> JEEB: did you see my Q? about broadcom cristal hd [14:18] <davesa> suggest* [14:19] <JEEB> DelphiWorld, I have no fucking idea about the broadcom piece of shit [14:19] <DelphiWorld> JEEB: lol [14:19] <DelphiWorld> JEEB: dont wory, all we hate broadCrap [14:19] <JEEB> because -c copy would still use the libavformat muxer and friends [14:19] <JEEB> so you'd get a remuxed stream [14:20] <JEEB> of course if nothing else can be found, then you can poke at -c copy [14:20] <JEEB> and see if the same thing still happens [14:20] <JEEB> oh, it's http? [14:20] <JEEB> shouldn't you be able to just curl it into a file or something? [14:20] <JEEB> or wget [14:21] <JEEB> just "download" it for like 30MB [14:21] <JEEB> then stop [14:23] <davesa> yes [14:24] <davesa> i just send the paste to pastebin [14:25] <davesa> the thing when i use ffprobe --show_formats shows audio stream as unknow, [14:25] <davesa> but this command ffprobe -show_format -ar 48000 -ac 2 [14:25] <davesa> show the right audio streams info [14:25] <davesa> as i took those parameters from vlc when it plays the stream [14:25] <JEEB> (because ignoring what people say is cool) [14:26] <davesa> but if i define ffmpeg -ar 48000 -ac 2 [14:26] <davesa> it does not do [14:26] <davesa> bcz ffmpeg does not accept to predifine the input parameters [14:26] <davesa> JEEB what do you mean by using curl? [14:27] <JEEB> curl -o dump.ts http://192.168.15.130:8200/118antenalatina [14:27] <JEEB> if I remember it correctly [14:27] <JEEB> literally, dumping whatever shit it's sending to you via http [14:29] <davesa> yes [14:29] <davesa> i did that [14:29] <davesa> and saved about 1 minute [14:29] <davesa> how can i try to play from the computer where i did the dump? [14:29] <davesa> ffplay? [14:30] <JEEB> ffmpeg -i dump.ts -f rawvideo - [14:30] <JEEB> do this [14:31] <davesa> look it gave me this [14:31] <davesa> Stream #0.1[0x335](spa): Audio: aac, 48000 Hz, 0 channels, s16, 94 kb/s [14:31] <davesa> SDL_OpenAudio: [14:31] <davesa> so it detected the audio from dumped file [14:31] <davesa> but 0 channels [14:31] <davesa> which not true [14:31] <davesa> its supposed to be stereo [14:32] <JEEB> but can it decode it? [14:32] <JEEB> that is what matters [14:32] <davesa> let me try ur command now [14:34] <davesa> -f rawvideo - ( i continue my command used bfore ) [14:34] <davesa> if i run urs only my pc go crazy [14:34] <davesa> and show me all type of alaphabets and charchters [14:34] <davesa> :) [14:36] <davesa> Could not find codec parameters for stream 1 (Audio: aac ([15][0][0][0] / 0x000F), 0 channels, fltp, 95 kb/s) [14:36] <davesa> unless my ffmpeg command has something wrong [14:37] <davesa> but i use it for other streams on the same network [14:37] <JEEB> pastebin your full command and terminal output [14:37] <davesa> works great [14:37] <JEEB> also sorry [14:37] <JEEB> -f null [14:37] <JEEB> not -f rawvideo [14:37] <JEEB> -f rawvideo will output the stuff into your terminal with - [14:45] <davesa> ok [14:45] <davesa> let me see [14:46] <davesa> still same [14:46] <davesa> audio not detected at all [14:47] <davesa> Stream #0:1[0x335](spa): Audio: aac ([15][0][0][0] / 0x000F), 0 channels, fltp, 95 kb/s [14:47] <davesa> i did the pastebin thing [14:47] <davesa> do you know how can i use other audio library then faac [14:47] <davesa> is it possible to use external audio encoder / decoder [14:51] <JEEB> so what happens? [14:51] <JEEB> does it actually decode? [14:51] <JEEB> also what pastebin? how am I supposed to know if you don't link it? [14:53] <JEEB> this is supposed to be quick checks so I can then poke you towards the issue tracker so the bug could get fixed, but you're definitely not making it easy for me :P [14:56] <davesa> hey [14:56] <davesa> sorry [14:57] <davesa> ouch [14:57] <davesa> i thought pastebin [14:57] <davesa> its something ihave to wait [14:57] <davesa> heheeh [14:57] <davesa> i am new in this [14:57] <davesa> sorry boss [14:57] <davesa> :) [14:57] <davesa> no does not decode [14:57] <davesa> wait let me send you the pastebin [14:57] <JEEB> yes, please [14:57] <JEEB> the -f null - one [14:58] <JEEB> also start uploading that small sample you have, if it's bigger than a few megabytes, you can try dd'ing the first megabyte or two of it into a separate file [14:58] <JEEB> and if that has the problem happen too [14:59] <JEEB> and why the fuck do you pm !? [14:59] <davesa> i just sent you the pastebin link [14:59] <davesa> you want all here [14:59] <davesa> np [14:59] <JEEB> yes, I mean the links you can post here [14:59] <davesa> ok [14:59] <JEEB> otherwise if I won't happen to know something no-one else can reply to it [15:00] Action: DelphiWorld pm JEEB [15:00] <JEEB> also please do post the output of that command line I said [15:00] <JEEB> ffmpeg -i dump.ts -f null - [15:00] <JEEB> I don't need your encoders and shit [15:00] <JEEB> just minimalistic decoding [15:07] <davesa> http://pastebin.com/hCqdWMc3 [15:09] <JEEB> thank you [15:09] <JEEB> huh [15:09] <JEEB> why did it decide to ignore the audio there? [15:10] <davesa> Thnx for ur help [15:10] <davesa> no idea [15:10] <davesa> i tried the analyzeduration and higher probesize [15:10] <davesa> same thing [15:10] <JEEB> ffmpeg -i dump.ts -c:v rawvideo -c:a pcm_s16le -f null - [15:10] <JEEB> try this [15:13] <davesa> still the same [15:13] <davesa> Stream #0:1[0x335](spa): Audio: aac ([15][0][0][0] / 0x000F), 0 channels, fltp, 95 kb/s [15:13] <JEEB> not that [15:13] <JEEB> see if it actually a) selects the stream [15:13] <davesa> where do you want me to upload the sample? [15:13] <JEEB> and b) tries to decode it [15:14] <JEEB> wherever it's not too hard to grab, depending on its size you might be able to fit it in the trac [15:14] <JEEB> http://trac.ffmpeg.org/ [15:14] <JEEB> make an issue about the aac decoder failing to decode [15:15] <JEEB> and give the log for ffmpeg -i dump.ts -map 0 -c:v rawvideo -c:a pcm_s16le -f null - not decoding it there, if it doesn't work for you locally [15:15] <JEEB> ok? [15:15] <davesa> yes [15:15] <davesa> i tried to play the dump.ts in vlc does not read it [15:16] <davesa> i mean does not read the audio [15:16] <davesa> maybe when we dump it using ffmpeg [15:16] <davesa> it also removed the audio from it [15:16] <davesa> as remeber is gave us 48000 then 0 channel [15:17] <JEEB> you dumped it via curl, no? [15:17] <JEEB> ffmpeg has nothing to do with that [15:18] <JEEB> and the audio is there, the track can be seen fine enough [15:18] <JEEB> just dump the shit in a sane enough way (curl/wget f.ex.) and check that it fails with the ffmpeg to decode, and if it does -> issue tracker [15:19] <JEEB> keep your fucking re-encoding off the example on the issue tracker because you will then proceed to get ass-raped by cehoyos regarding taking "anything unneeded" away from the example replicatable command line [15:20] <JEEB> and it will be worse for you, and will mean that it will take longer for you to get your goddamn bug fixed [15:20] <davesa> ok [15:20] <davesa> so i will just put summarized resolut [15:20] <davesa> no need for all the other stuff [15:20] <JEEB> no [15:20] <davesa> ok [21:49] <llogan> Logicgate: there are people to help you here but so far you've never actually supplied your actual ffmpeg command and the complete ffmpeg console output. [23:09] <ubitux> https://news.ycombinator.com/item?id=7283668 [23:09] Action: ubitux now stops spamming [00:00] --- Sun Feb 23 2014

1 0

ffmpeg-devel.log.20140221
by burek 22 Feb '14

22 Feb '14

[00:03] <cone-229> ffmpeg.git 03Luca Barbato 07master:5c79d2e12d13: avconv: Do not divide by zero [00:03] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:f2387152bcdc: Merge commit '5c79d2e12d13959fc6aed92d102c25194a06de05' [00:38] <cone-229> ffmpeg.git 03Vittorio Giovara 07master:f777504f6402: h264: Lower bound check for slice offsets [00:38] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:de7b50e9cde7: Merge remote-tracking branch 'qatar/master' [00:38] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:0ad8f73f137d: avcodec: fix dxva2 & vaapi after removing the +52 offset from the loop filter parameters [00:38] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:76dd01ecd4ed: avcodec/h264: fix sign error [01:09] <llogan> trac is having issues [01:13] <BtbN> sounds familiar. [01:18] <J_Darnley> oops. I forgot I uninstalled git [01:43] <BBB> nevcairiel: did you do the last x264/vp8 encode (so we have an exact same-quality encode for all 3)? [04:42] <cone-866> ffmpeg.git 03Michael Niedermayer 07master:1b872de8f49e: avformat/movenc: check that the input timestamps are within the range that can be stored in mov [04:42] <cone-866> ffmpeg.git 03Michael Niedermayer 07master:20fa3fb93d0f: avformat/movenc: assert that get_cluster_duration() value is valid [10:26] <nevcairiel> BBB: i'll do them now, was out yesterday [12:03] <t355u5> Trac detected an internal error: [12:03] <t355u5> OperationalError: database is locked [12:03] <t355u5> Is there an ETA when this will be resolved? [12:24] <ubitux> yeah that database lock sucks a bit [12:24] <ubitux> also, sqlite; really? [12:36] <Xeta> Anyone here had opportunity to look at my ticket for reading/applying replaygain tags? https://trac.ffmpeg.org/ticket/3398 [12:37] <wm4> Xeta: Libav has a patch, I expect it will be applied, and then ffmpeg will merge it [12:38] <aca> I have been looking at the licensing of FFmpeg and noticed that 4 files (compat/avisynth/avisynth_c.h, compat/avisynth/avxsynth_c.h, libavfilter/vf_colormatrix.c, libavcodec/libzvbi-teletextdec.c) refer to an old FSF address. Please update that to: 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA [12:39] <wm4> as if anyone is ever going to use the address [12:39] <aca> It just produces unnecessary warnings. [12:40] <wm4> where? [12:40] <aca> lintian complained, after I copied the paragraph to debian/copyright. [12:46] <Xeta> +wm4 ah great i filed a ticket there as well and have been bugging them about it [12:48] <wm4> yeah, bugging both projects leads to double success chance [12:51] <Xeta> Heh ok, i was scared it would lower it [12:51] <Xeta> How often do you guys import libav patches? [12:52] <ubitux> wm4: that pngenc code looks weird [12:52] <ubitux> it's doing a diff on size [12:52] <wm4> Xeta: ffmpeg merges _everything_ Libav does [12:52] <ubitux> and copying only bpp [12:53] <ubitux> btw, also reproducible without mmx [12:53] <ubitux> (so C code) [12:53] <ubitux> and with just -pred 3 [12:53] <ubitux> so, valgrind ./ffmpeg_g -cpuflags -mmx -f lavfi -i testsrc -pred 3 -y out.png [12:53] <wm4> ah, I thought it was some weird asm stuff [12:54] <ubitux> (and -frames:v 1) [12:54] <ubitux> valgrind ./ffmpeg_g -cpuflags none -f lavfi -i testsrc -pred 3 -frames:v 1 -y out.png [12:56] <wm4> well it's still somewhere in dsputil.c [12:56] <ubitux> code from original commit (4a5b619df74ea6a5d476fc4f91cbb98b5aa5098a) [12:56] <wm4> (scary file) [12:56] <ubitux> wm4: doesn't the caller look weird to you? [12:57] <wm4> *shrug* [12:57] <ubitux> i'd say diff_bytes should be called with bpp [12:57] <ubitux> and not size [12:57] <Xeta> Heh ok +wm4 [12:57] <ubitux> but not sure [12:57] <ubitux> well, probably wrong [12:59] <wm4> it would be better if anything there would document what it actually does [13:02] <ubitux> maybe that's simply because src-bpp if src is beginning of buffer [13:02] <ubitux> oh well. [13:02] <ubitux> wm4: that's not a problem in the diff func [13:03] <ubitux> doing a 1-to-1 dummy diff leads to an invalid read anyway [13:03] <wm4> seems size is in pixels, and bpp the pixel size [13:11] <ubitux> http://www.w3.org/TR/PNG-Filters.html [13:13] <ubitux> ok fixed [13:13] <ubitux> wm4: [13:13] <ubitux> - dsp->diff_bytes(dst, src, src-bpp, size); [13:13] <ubitux> + dsp->diff_bytes(dst+bpp, src+bpp, src, size-bpp); [13:14] <ubitux> will make a proper commit eventually [13:14] <wm4> thanks :D [13:14] <wm4> and the old code still produced correct results? [13:15] <ubitux> yes [13:15] <ubitux> it was overwriting the uninitialized based computed data [13:15] <ubitux> (see following memcpy) [14:05] <cone-449> ffmpeg.git 03Diego Biurrun 07master:dc9e05e279cb: libvorbis: Give consistent names to all functions, structs, and defines [14:05] <cone-449> ffmpeg.git 03Michael Niedermayer 07master:6e6386777128: Merge remote-tracking branch 'qatar/master' [14:17] <ubitux> http://b.pkh.me/0001-avcodec-pngenc-fix-invalid-read-in-sub-filter.patch [14:17] <ubitux> opinion? [14:18] <ubitux> oh well, ml. [14:45] <ubitux> mmh [14:45] <ubitux> isn't there a 1-frame delay bug in overlay filter? [14:46] <ubitux> ah, i guess that's a pts issue thing again [14:49] <ubitux> BBB: ./ffplay -f lavfi -i "movie=/tmp/etv5k-vp9-b5000.webm [a]; movie=/tmp/etv5k-x264-b10000.mkv, crop=iw/2:x=iw/2 [b]; [a][b] overlay=w" [14:49] <ubitux> i'm trying to compare like this but... timestamps are not handled the same in both format [14:49] <ubitux> so it's causing some weird jumps [14:56] <wm4> dump the timestamps with ffprobe? [14:56] <wm4> and hope it's not some CODEC_ID_H264 shit in utils.c [14:56] <ubitux> i just need to set the correct setpts after each movie=.. [14:58] <ubitux> wm4: carl is probably complaining about the missing sample [14:58] <ubitux> you should use tests/lena.pnm or some random source filter when possible [14:59] <ubitux> so we can be sure it's not related to the input [14:59] <wm4> yeah, I should have used testsrc or so [15:02] <ubitux> oh wait [15:02] <ubitux> i have a lot of NOPTS with the webm file [15:03] <ubitux> sounds like some libvpx derping [15:05] <ubitux> mmh wait [15:05] <ubitux> derp, it's movie device related [15:11] <plepere> hmm... i'm doing a patch for ffmpeg to integrate my ASM. it works in one of our branches, but the fate doesn't work in mine. :/ [15:12] <BBB> ubitux: maybe the parser isn't filling in timestamps? [15:12] <BBB> (vp9_parser.c) [15:12] <BBB> I don't know how that stuff works [15:13] <ubitux> mmh [15:13] <BBB> what does etv stand for? [15:13] <ubitux> enter the void [15:14] <ubitux> (name of the movie) [15:14] <Compnn> plepere : does fate pass without your patch ? [15:15] <ubitux> ./ffplay -f lavfi -i "movie=/tmp/etv5k-vp9-b5000.webm, setpts=N/(25*TB) [a]; movie=/tmp/etv5k-x264-b10000.mkv, setpts=N/(25*TB), crop=iw/2:x=iw/2 [b]; [a][b] overlay=w, drawbox=iw/2:0:2:color=red@0.5" [15:15] <plepere> Compnn, my 8-tap filter works, but my 4-tap doesn't [15:15] <ubitux> ok so this works [15:15] <ubitux> BBB: if yoiu want to try ^ [15:15] <ubitux> to compare [15:16] <BBB> so ffvp9 timestamps are screwy? [15:17] <plepere> Compn, but I can enable it all on another branch and the fate passes, so I don't think it's a bug in my ASM [15:17] <ubitux> BBB: yeah when using movie it seems [15:17] <Compn> plepere : think its miscompile ? [15:17] <ubitux> BBB: anyway, it seems the plane scene has grain uglier with x264 [15:17] <ubitux> and it's visible [15:18] <BBB> ok so ssim score was slightly higher with vp9, and this confirms it indeed looks a little better right? so that's good then [15:18] <plepere> Compn, what's miscompile ? (sorry) [15:18] <BBB> the metric isn't completely lying [15:20] <Compn> plepere : gcc bug [15:20] <Compn> or yasm bug, i guess :) [15:20] <BBB> unlikely [15:21] <plepere> Compn, I think it's unlikely, since it's working on another branch of ffmpeg. (just not the one I want it to) [15:21] <ubitux> BBB: ./ffmpeg -i /tmp/etv5k-vp9-b5000.webm -i /tmp/etv5k-x264-b10000.mkv -lavfi "[1:0] crop=iw/2:x=iw/2 [b]; [0:0][b] overlay=w, drawbox=iw/2:0:2:color=red@0.5" -ss 10 -frames:v 1 -y test.png [15:28] <plepere> if all my ASM was wrong, I'd say to myself that I did something wrong in the linking, but it's only the 4-tap... [15:30] <Compn> what branch works ? [15:30] <Compn> what version is it, i mean [15:32] <plepere> it's our own branch, but it's based on the current master from ffmpeg [15:33] <plepere> https://github.com/OpenHEVC/FFmpeg : hevc_optimized works, feb_patch does not work [15:33] <plepere> but feb_patch has only the ASM-related changes, and not all the other stuff (intrinsics and whatnot) [15:51] <plepere> nvm, I'm an idiot [15:52] <BBB> plepere: do you have a link to the code? [15:53] <plepere> BBB : I've resolved my issue [15:53] <BBB> lol [15:53] <plepere> I didn't see that the filters table changed from one version to another. [15:53] <plepere> therefore : I'm an idiot [15:53] <BBB> wel that's kinda harsh [15:53] <BBB> stuff happens [15:54] <plepere> more often than not. :) [15:55] <plepere> the great news is that now the branch is ready. [15:55] <plepere> so.... now that I have that, how do I submit a patch for review ? [15:55] <ubitux> git format-patch or git send-email [15:58] <plepere> ok, so to whom should I send the .patches ? [15:59] <plepere> oh and it put different .patch for each local commit. is it possible to put everything together ? [15:59] <ubitux> ffmpeg-devel(a)ffmpeg.org [15:59] <ubitux> rebase & squash them [15:59] <ubitux> not familiar with git i suppose? [15:59] <plepere> I'm just using the base functions [16:00] <ubitux> go into master, git pull, go into your work branch, git rebase -i master [16:00] <plepere> ok [16:00] <ubitux> your editor spawn, replace the "pick" into squash/fixup/edit depending on what you want to do (see help at the bottom) [16:01] <plepere> so all but last, I replace pick by squash. [16:02] <ubitux> i personnally like to do fixup instead, and edit the message commit of the first one [16:02] <ubitux> works fine with squash ofc [16:04] <plepere> hmm, git says I'm not on any branch after rebase. [16:05] <ubitux> did you do "edit"? [16:05] <kurosu_> rebase --continue ? rebase --abort if you fear to break something? or were you cherry-picking ? [16:06] <ubitux> what timeline did you do? [16:06] <ubitux> you're probably in the middle of the rebase because of conflicts or edit [16:08] <plepere> meh, I've got to go. I've sent my multiple patch files, I'll see this later if it's not accepted. :) [16:08] <plepere> see you, and thanks for your help [16:13] <Compn> git is so user unfriendly [16:14] <ubitux> it's like saying "c pointers are so user unfriendly" [16:14] <Compn> ehe [16:14] Action: Compn trolls and runs [16:14] <j-b> Compn: it's that what you do all the time? [16:15] <Compn> hey, i helped plepere solve his own problem [16:16] <Compn> thats all people need sometimes, someone to talk to while they solve it themselves [16:16] <Compn> its like 'placebo support' [16:17] <wm4> but now that you said that it's placebo, it's not going to work anymore [16:43] <iive> wm4: actually studies show that placebo works, even when the people who take it know it is placebo. [16:44] <iive> on the other side, there is some chemical, that when injected, suppresses the effect of placebo completely. [17:14] <wm4> ubitux: I think after all, this couldn't have caused a crash, since it's unlikely that the first bytes before a memory allocation are not mapped [17:30] <cone-449> ffmpeg.git 03Michael Niedermayer 07master:a0f8e6ad67b0: tests/tiny_ssim: drop isatty() support [17:31] <ubitux> :( [17:31] <ubitux> should have been isatty(1) anyway [17:31] <BBB> it's ok, it was kind of silly, you can just tr \r to \n [17:53] <ubitux> still no one to write/port a hqx-like filter? [17:54] <rcombs> wm4: keep in mind how erratic this is, though [17:54] <rcombs> wm4: it crashes on very rare occasion, and while it's unlikely, there's certainly a chance that a few bytes before an allocation won't be mapped [17:55] <wm4> rcombs: maybe you could check whether a huge memalign() (like what av_malloc() does) starts on a page boundary with no page mapped before it? [17:55] <nevcairiel> a couple bytes before an allocation could be part of control data, ie. if you use the memalign hack, it would store its info there [17:56] <wm4> this happens on OSX [17:56] <wm4> I think it uses native memalign there [17:56] <wm4> but even then, memalign would most likely store its own header just before start of the allocation [18:58] <cone-449> ffmpeg.git 03Carl Eugen Hoyos 07master:1f7e9be0b034: Only complain about missing frame rate for video streams. [18:58] <cone-449> ffmpeg.git 03Carl Eugen Hoyos 07master:f5fe6a4f79fa: Do not warn about missing start time for unknown streams. [18:58] <cone-449> ffmpeg.git 03Michael Niedermayer 07master:c8f3c3a5794d: Merge remote-tracking branch 'cehoyos/master' [19:49] <llogan> why did x265 choose cmake and mercurial? [19:53] <nevcairiel> obviously the answer is "because the developer liked it" [19:53] <nevcairiel> seems like a silly question :p [19:53] <Daemon404> and because msvc support is easier [19:53] <Daemon404> and all their devs use msvc [19:53] <Daemon404> and their ead dev is also one of the leads on mercurial [19:53] <Daemon404> so shockingly, they picked mercurial [19:53] <nevcairiel> that goes for cmake maybe, not mercurial though :p [19:53] <nevcairiel> vs2013 has a git client even! [19:53] <Daemon404> muggs is the hg lead [19:54] <Daemon404> windows installer is even signed by him [19:54] <Daemon404> ;P [19:54] <JEEB> tortoisehg maintainer [19:54] <llogan> Daemon404: that explains it then [19:54] <Daemon404> i dont like hg [19:54] <Daemon404> but i use git-hg to bridge it [19:54] <Daemon404> so im fine [19:54] <llogan> * dont like hg [19:54] <JEEB> there's an official git mirror IIRC [19:54] <JEEB> and the build system IIRC supports it, too [19:55] <nevcairiel> i always get confused when i try to use hg [19:55] <JEEB> yeah [19:55] <nevcairiel> its commands are very confusing [19:55] <JEEB> prunedtree hates git tho :< [19:55] <JEEB> which is sad [19:56] <Daemon404> [18:54] < JEEB> there's an official git mirror IIRC [19:56] <Daemon404> months out of date [19:56] <JEEB> :< [19:56] <Daemon404> nevcairiel, git-hg is in the official git git repo [19:56] <Daemon404> use it if you can [19:57] <nevcairiel> dont think msysgit comes with git-hg [19:57] <JEEB> it's a script so you don't really need a special binary methinks [19:57] <nevcairiel> but i need mercurial :p [19:57] <JEEB> yes [19:58] <Daemon404> which is easy on windows [19:58] <Daemon404> unlike git [19:58] <JEEB> I grabbed x's build which happened to have it without installers and bundled python [19:58] <nevcairiel> never considered git to be hard [19:58] <nevcairiel> well if you dont like CLI maybe [19:59] <Daemon404> same [19:59] <Daemon404> hg really confuses me [19:59] <Daemon404> i once tried to do something liek rebase in it [19:59] <Daemon404> i gave up and cloend a new repo [19:59] <Daemon404> and patch -p1 < [19:59] <nevcairiel> it doesnt have rebase [19:59] <JEEB> enable all the extensions! [19:59] <wm4> Daemon404: here too... [19:59] <JEEB> it does come with hg core, but it's all disabled by default [19:59] <wm4> but everyone says hg has a nicer interface [19:59] <nevcairiel> they consider changing history a sin, or something [19:59] <Daemon404> wm4, it looks amateur to me [19:59] <JEEB> which is what tortoisehg overrides [19:59] <Daemon404> the el output is e.g. all lower case [19:59] <JEEB> it basically enables a whole shitload of stuff [20:00] <Daemon404> help* [20:00] <Daemon404> no love given at all [20:00] <JEEB> because hg is much less usable without them [20:00] <JEEB> *shrug* [20:00] <Daemon404> the crappy help / lowercase stuff makes it look like a hacked together thing to me [20:42] <tbarletz> Will it make sense to add support for different DRM solutions into ffmpeg? [20:42] <tbarletz> e.g. Widevine or SecureMedia [20:43] <BtbN> drm in an open sourcep project? Sounds like a horrible idea. [20:43] <BtbN> or even in a closed source project [20:43] <BtbN> it's allways a horrible idea. [20:44] <JEEB> I think he mostly means decryption [20:44] <tbarletz> Well, perhaps we can provide drm-specific implementaion, using externally linked libraries (via the provider's SDK) [20:44] <BtbN> those are most likely not gpl compatible [20:44] <tbarletz> And then have general decryption methods to use [20:45] <tbarletz> i.e., HLS chuncks that are encrypted with SecureMedia -> use SDK to get clear control word -> decrypt -> save to file (or whatever) [20:46] <BtbN> i'm pretty sure that isn't allowed by the drm license [20:46] <BtbN> they'll only give you access to the SDK, under an NDA, if you sign not to make it possible to bypass it [20:46] <tbarletz> The proprietary libraries will not be provided with ffmpeg [20:46] <tbarletz> Just the code that uses it [20:47] <tbarletz> Are you saying that even the interface is not public? [20:47] <BtbN> would be quite pointless if it was [20:47] <BtbN> drm is just huge security by obscurity [20:48] <tbarletz> Well, I thought that the binaries are the secret part [20:48] <JEEB> the API and libs are [20:48] <JEEB> the loaded up libraries of course have to be public [20:48] <JEEB> since the end-user has to deal with them [20:50] <BtbN> if you could just load up the lib, and decrypt the video and save it to disk, the drm system would be extremely pointless [20:51] <tbarletz> Well, in the case of SecureMedia, the encryption system is a server accessed in a protected environment, AFAIK [20:51] <tbarletz> So you can't just get the clear control word if you don't have access to it [20:58] <cone-449> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:84cdd2fd80ac: qcelpdec: break some too-long lines [20:58] <cone-449> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:b295bce14813: qcelp: grammar [21:04] <wm4> heh, what a underhanded way to add precise seeking to ffmpeg [21:08] <rcombs> it was merged in from libav, wasn't it? [21:08] <wm4> rcombs: no, I was referring to the patches on ffmpeg-devel [21:10] <rcombs> oh, I can't handle mailing lists [21:11] <Daemon404> wut? [21:11] <Daemon404> will you go into the fetal position? [21:11] <wm4> mailing lists are a must for interaction with some projects, including ffmpeg/libav [21:11] <Daemon404> and a good chunk of the FOSS world [21:12] <JEEB> Daemon404, can you add experimentality to the 4:4:4 patch? [21:13] <BtbN> well, specialy sending patches via mail seems strange to me [21:13] <rcombs> ^ yeah [21:13] <JEEB> Daemon404, as in, that you need -strict experimental [21:13] <JEEB> to actually use 4:4:4 [21:13] <wm4> BtbN: git does that for you [21:13] <wm4> with git send-email [21:13] <JEEB> because range extensions aren't finished yet [21:13] <Compn> wm4 : people can pass patches via pastebins if they want here [21:13] <Daemon404> JEEB, why [21:13] <wm4> it's pretty convenient, even more convenient than github pull requests [21:13] <BtbN> if you have a working mailserver on your system, and your system is linux... [21:13] <Compn> just most get ignored [21:13] <Compn> also trac patches work too [21:14] <rcombs> I find PRs more convenient by far [21:14] <Compn> PR ? [21:14] <Daemon404> JEEB, if x265 doesnt mark it as experiment *in their lib*, im not going to [21:14] <wm4> BtbN: you don't need to run a mail server [21:14] <rcombs> pull requests [21:14] <Compn> ah [21:14] <Daemon404> it's not my responsibility. [21:14] <cone-449> ffmpeg.git 03Philip de Nier 07master:a9099e04026f: mxf: Add uncompressed 422 8-bit rawvideo UL [21:14] <BtbN> wm4: last time i tried it it wanted a working sendmail [21:14] <JEEB> eh [21:14] <cone-449> ffmpeg.git 03Michael Niedermayer 07master:f93bd82ee6bc: Merge commit 'a9099e04026f300924ac363fa6f8aef912677d90' [21:14] <rcombs> or even just having a git branch somewhere that I can checkout, diff, review, and merge [21:14] <wm4> BtbN: that's a possible configuration [21:14] <Daemon404> [20:14] < rcombs> pull requests <-- so your one of those young guys who cant remember anything before github or git existed [21:14] <nevcairiel> does it actually encode in 4:4:4 or just support 4:4:4 input and downconverts itself? [21:14] <Daemon404> or perhaps live in SV [21:14] Action: Daemon404 runs [21:14] <BtbN> wm4: not on windows. [21:14] <Daemon404> nevcairiel, it encodes in 4444 [21:14] <BtbN> and not on a desktop machine [21:14] <rcombs> Daemon404: too young, yeah [21:14] <JEEB> nevcairiel, it actually encodes 4:4:4 [21:15] <JEEB> according to whatever draft version [21:15] <BtbN> i also don't see anything wrong with the linux kernel pull-request model. [21:15] <BtbN> They also use a ML, but just send a repo url to pull from [21:15] <JEEB> Daemon404, x265 is fucking dumb with that and that we can't do anything about, it doesn't mean that you have to fall to their level, though :P [21:15] <Daemon404> rcombs, anyway, you should follow what a project uses if you want to contribute [21:15] <nevcairiel> then you should really add a experimental gate there, as the bitstream isn't even finalized yet AFAIK [21:15] <JEEB> it isn't [21:15] <rcombs> Daemon404: sure [21:15] <JEEB> they're still working on it [21:16] <cone-449> ffmpeg.git 03Tomas Härdin 07master:c416b5cdf117: mxf: Add DNxHD UL [21:16] <cone-449> ffmpeg.git 03Michael Niedermayer 07master:9aa59a9ce6aa: Merge remote-tracking branch 'qatar/master' [21:16] <rcombs> Daemon404: fortunately, the projects I contribute to largely take Git branch-based PRs [21:16] <Daemon404> PRs on github lack some thinsg MLs provide [21:16] <Daemon404> it's not a 1:1 tradeoff [21:16] <BtbN> what do they lack? I can't think of anything [21:17] <rcombs> I know I've read a long rant from torvalds about them being useless [21:18] <Daemon404> BtbN, multiple revisions of single patches are handled very poorly [21:18] <Daemon404> especially historically archivig said revisions [21:18] <Daemon404> and yes that is useful [21:18] <rcombs> that's a valid point [21:19] <wm4> github could handle this correctly easily (if they wanted to) [21:19] <rcombs> maybe they should provide an option to archive the previous state of a branch when you force-push, and attach it to any currently-open PR [21:19] Action: rcombs puts in a feature request [21:19] <wm4> the main downside of github is javascript everywhere, and that it's a single point of failure [21:20] <Daemon404> yes [21:20] <Daemon404> large patchsets *cripple* my browser [21:20] <Daemon404> even on an i7 [21:22] <Compn> firefox ? [21:23] <Compn> youtube changed the javascript there, its 100% cpu to do anything for me now. [21:23] <Compn> using mobile versions of yahoo mail and gmail. wonder if i can user-agent my way around the mobile ver of youtube [21:24] <rcombs> you don't even have to iirc; just go to m.youtube.com [21:24] <rcombs> erm, nope [21:25] <rcombs> yeah, m.youtube.com redirects, but if you use an iOS UA it'll load the mobile version just fine [21:25] <Compn> less js ? :) [21:26] <rcombs> how are we measuring it? [21:26] <Compn> faster loading time [21:27] <wm4> so when will there be a github mobile version? [21:27] <rcombs> bit faster here, but not by a lot [21:27] <rcombs> wm4: there already is [21:27] <Compn> is there a github extension or app to speed things up ? [21:28] <rcombs> there are desktop apps for Windows and OSX [21:32] <Daemon404> JEEB, seems i misunderstood you [21:32] <Daemon404> i though you wanted 4:4:4 experimental because x265 was buggy [21:33] <Daemon404> i didnt realize it was in draft [21:33] <JEEB> I literally linked you this today http://up-cat.net/p/220d1e34 [21:33] <JEEB> :V [21:33] <wm4> hevc doesn't have 4:4:4 yet? [21:33] <Daemon404> lost in the noise [21:34] <JEEB> wm4, they're still optimizing it and friends [21:34] <JEEB> range extensions will contain 4:2:2 and 4:4:4 [21:34] <JEEB> as well as >10bit [21:34] <JEEB> it already passed DIS, so they're now working on to finish it and get it through FDIS [21:35] <Daemon404> btw [21:35] <JEEB> when it gets into DIS and x265 gets updated to more or less create complying byte streams [21:35] <JEEB> *FDIS [21:35] <Daemon404> markign shit experimental didnt stop anyone before [21:35] <Daemon404> ;) [21:35] <JEEB> yes [21:35] <JEEB> but it at least adds an extra barrier [21:38] <Daemon404> more like it lets me yell at people if they report problems [21:39] <JEEB> yes [21:39] <JEEB> that too [22:30] <Compn> kierank : you were the one who had the kickstarter account right? indiegogo got back to me, they "usually dont delete banking info" . veeeeeeeery secure. [22:34] <kierank> Compn: yes [22:39] <Daemon404> Compn, there must be some sort of laws... [22:40] <Compn> Daemon404 : yes, the banking laws say these idiot companies have to keep banking info for like 10 years [22:40] <Compn> to catch the bad drug dealers (who the banks are working with) [22:42] <JEEB> reminds me of startssl being in israel [22:42] <JEEB> if you buy a certificate from them where you actually confirm your identity [22:42] <JEEB> they will keep it for at least 7 years [22:42] <JEEB> because of israel data retention laws [22:44] <Daemon404> JEEB, good thing i didnt confirm jack [22:44] <JEEB> yes, the free certs don't need that [23:45] <rcombs> wow, github actually got back to me very quickly on that feature request, with more than a canned response [23:46] <Compn> they made the javascript quicker ? [23:46] <Compn> ehe [23:46] <rcombs> I got a standard "glad to receive your suggestion, we'll consider it", but also a suggestion that you could put the previous HEAD in a comment on a PR to keep track of previous versions of a branch if you're force-pushing after making changes [23:47] <Daemon404> rcombs, that still makes seeing old comments kind of meh [23:47] <Daemon404> less nice than just looking at gmane or a mailan archiv [23:47] <Daemon404> ee [23:47] <rcombs> yeah, optimally they'd keep around line notes and such [23:48] <nevcairiel> if you still have a reference to the revision, the line notes would still be there at least [23:48] <Daemon404> im not sure, but i think if the user deletes their fork, you lose the history anway [23:48] <Daemon404> and it will be impossible to enforce such things [00:00] --- Sat Feb 22 2014

1 0

ffmpeg.log.20140221
by burek 22 Feb '14

22 Feb '14

[00:08] <BtbN> Is there a way to tell ffprobe to stop after the first valid (video) frame? [00:39] <didge> Hi. How can I trim the last few seconds from an mp4 file if I don't know the length ? I'm running the encoding as a simple shell script. [00:44] <didge> http://pastebin.com/fGFx55f4 [00:46] <llogan> ive never seen a -b:v:a [00:47] <didge> llogan: that was a parameter I didn't understand. I put that in from the Wowza official forum post but the syntax differed. [00:47] <didge> llogan: what would you suggest ? I'm not quite sure what it is doing. [00:48] <llogan> it depends on what you're trying to do and how you're going to use the output [00:48] <didge> The goal is to stream 1080p through Flowplayer or JWPlayer [00:49] <llogan> as progressive download or a live stream? [00:49] <didge> video on demand is the Wowza feature I am using. [00:49] <llogan> i am not familiar with wowza [00:50] <didge> I think live stream. Like, the source is previously recorded. [00:50] <didge> So I'm encoding a series of mp4 files [00:51] <llogan> sounds like progressive download [00:52] <didge> ok. that's the plan. [00:53] <didge> http://pastebin.com/BPsZPrp5 [00:54] <llogan> you're missing the console output. [00:55] <didge> The console output looks like a video being encoded. I don't mean to be a smart ass. [00:56] Action: llogan moves on to another ffmpeg question [04:19] <pabs3> I'm trying to register in trac.ffmpeg.org but the page doesn't seem to load after I press register. I wanted to update #2983 with a link to http://wiki.multimedia.cx/?title=VP7 [04:35] <pabs3> hmm, it finally returned and gave me this error. how do I fix this? "Warning: Username pabs doesn't match local naming policy." [04:47] <FriendlySeal> arite wtf [04:47] <FriendlySeal> same instalation of ffmpeg [04:48] <FriendlySeal> converting mkv to mp4 [04:48] <FriendlySeal> works on debian [04:48] <FriendlySeal> not works on ubuntu [04:48] <FriendlySeal> DAFUQQQ! [04:49] <FriendlySeal> converting mkv to webm works on both [04:49] <FriendlySeal> weird? [04:50] <FriendlySeal> im asuming its the 264 codec? [04:50] <FriendlySeal> but the install is the same!!! [05:08] <FriendlySeal> yesh yesh [05:10] <FriendlySeal> lets try build from ffmpeg not git pull [08:28] <cbreak-work> Hmm... I get the feeling that I am missing something. I get this format dumped: Stream #0:0: Video: mpeg4 ( [0][0][0] / 0x0020), yuv420p, 1920x800, q=2-31, 1000 kb/s, 12288 tbn, 24 tbc [08:28] <cbreak-work> but 12288 seems a bit high for tbn [08:29] <cbreak-work> before I write the header, it even says 90k [08:43] <cbreak-work> maybe a bug in ffmpeg [08:43] <cbreak-work> back to 2.1 [08:44] <cbreak-work> hmm, no. Same problem with 2.1 [08:45] <cbreak-work> but strangely enough not with avi output format, it does happen with mp4 and mov [09:00] <relaxed> cbreak-work: try 1.2.5: http://johnvansickle.com/ffmpeg/releases/ffmpeg-1.2.5-64bit-static.tar.bz2 [09:02] <cbreak-work> isn't that really old? [09:02] <cbreak-work> I currently think it's a bug in my code though. [09:03] <relaxed> and old branch but it was released this year [09:04] <relaxed> an* [09:13] <cbreak-work> yes, seems it was indeed my fault [09:13] <cbreak-work> I didn't set the AVFrame::pts correctly [09:13] <cbreak-work> so they were all bunched up [09:27] <termos> I have some bug when muxing an AVPacket. I get an error saying "dimensions are not set", and it seems that the AVOutputFormat->flag does not have the AVFMT_NODIMENSIONS flag set. [09:28] <termos> I am using av_guess_format for getting the AVOutputFormat [09:29] <braincracker> hello my friends [09:30] <braincracker> i have a quick question [09:30] <braincracker> can one take a snapshot from a webcam/usb camera with best quality ? not just "webcam quality" [09:33] <BtbN> so you want to capture a better image than the webcam is actualy able to do? oO [09:33] <braincracker> no [09:34] <braincracker> new webcams are able to take 2Mpixel photos fo example [09:34] <braincracker> while they deliver 640x480 video streams [09:35] <BtbN> sounds like a thing the driver has to support [09:35] <braincracker> :( i thought something like that too, ffmpeg doesn't know this? [09:36] <braincracker> and all brands have different drivers for this function i assume then, just to make life easy [09:36] <cbreak-work> hmm... The output is now correct, but ffmpeg crashes sometimes :( [09:37] <cbreak-work> in libswscale [09:40] <cbreak-work> time to recompile ffmpeg without optimization [09:42] <cbreak-work> anyone else using ffmpeg on OS X 10.9 compiled with clang? [09:43] <braincracker> never used osx, is it free? [09:44] <T-Co> Free as in beer [09:50] <cbreak-work> braincracker: free as in bundled-with-hardware [09:50] <cbreak-work> big chunks are open source too [09:58] <cbreak-work> maybe a bug in ff_rgb24ToY_avx [10:17] <cbreak-work> https://gist.github.com/cbreak-black/9131169, very weird. [10:19] <rjp421> i made an adobe AIR app that launches ffmpeg with some args and receives the output... but no matter how i try to define the arguments for the dshow input video/audio devices, i either get device not found, or malformed dshow input string [10:21] <cbreak-work> this is just out of bounds. [10:21] <cbreak-work> the input given to sws_scale seems valid [10:21] <cbreak-work> print srcSlice[0] + srcStride[0] * srcSliceH gives (const uint8_t *) $19 = 0x000000010ae69000 [10:22] <rjp421> i.e. -f dshow -i video="WebcamMax Capture":audio="Default" [10:37] <rjp421> this is in windows btw [11:30] <cbreak-work> Hmm... can't help but think that this is a bug in FFMPEG... [11:36] <cbreak-work> all parameters to swscale look sane [11:36] <cbreak-work> and yet, inside it, a function performs an out of bounds access [11:43] <Mavrik> there are some padding requirements for frame buffers [11:43] <Mavrik> are you obeying them? [11:44] <cbreak-work> There are no padding requirements mentioned in the documentation for swscale [11:44] <cbreak-work> my buffer is 1920x800 pixel, stride is 5760 (because input is RGB24) [11:45] <Mavrik> considering the fact that swscale heavily relies on SSE instructions, there certanly are at least some padding requirements [11:46] <cbreak-work> the crash happens in ff_rgb24ToY_avx, but I have not been able to find this function anywhere in the source code [11:46] <cbreak-work> it seems to somehow have been obfuscated [11:46] <Mavrik> the _avx tells you you have to look in the ASM files [11:47] <Mavrik> and indeed, AVX probably will require you to pad stuff to 256 bits I think [11:47] <ubitux> cbreak-work: try to reproduce with ffmpeg [11:47] <ubitux> also try to reproduce with -cpuflags -avx [11:47] <Mavrik> its also rather new so having a bug there wouldnt be strange :) [11:47] <cbreak-work> the ffmpeg command line? [11:47] <ubitux> yes [11:47] <cbreak-work> ok. [11:50] <cbreak-work> what I do in my program is decode a video, convert it to RGB24, then encode that back with FFMPEG to a file (it's a test) [11:50] <cbreak-work> how can I do that in command line ffmpeg? [11:53] <ubitux> ffmpeg -i input -vf format=rgb24 -f null - [11:53] <ubitux> or something like that [12:00] <cbreak-work> it doesn't crash if I do it in the command line [12:00] <cbreak-work> ./ffmpeg -v verbose -i input.mov -an -vf format=rgb24 out.mp4 is what I run exactly [12:05] <cbreak-work> but it uses different flags [12:05] <cbreak-work> I use lanczos in my code [12:16] <cbreak-work> hmm... no, doesn't crash even if I make it use lanczos in the cli, and still sometimes crashes if I use bilinear via the library [12:16] <cbreak-work> that would have been weird anyway since I don't change the size [12:17] <relaxed> cbreak-work: try, ffmpeg -i input.mov -cpuflags +avx -an -vf format=rgb24 out.mp4 [12:19] <cbreak-work> still doesn't seem to crash [12:24] <cbreak-work> weird. My program always crashes on the same frame. [12:25] <cbreak-work> hmm... could it be that there's some weird global state issue in ffmpeg? [12:25] <cbreak-work> I encode the input video into two separate files, but if I only write it into one there's no crash [12:27] <cbreak-work> hmm, no. It still crashes, sometimes [12:36] <cbreak-work> if it crashes, then on frame 244... super weird. [12:40] <cbreak-work> if I try to encode every frame twice (so that the output video contains all frames double, and is twice as long), then it does not crash. [12:41] <cbreak-work> so it seems to be data dependent... or some strange interaction behind the scenes [12:42] <cbreak-work> but if I skip frame 244 then it crashes on 245 [12:51] <cbreak-work> if I give it completely white frames instead of input movie frames, it crashes a bit earlier (but still not right away). [12:52] <cbreak-work> I reuse the input buffer, so the encoding part gets 100% the same input parameters [12:54] <koko_> hello [12:55] <koko_> how can i keep original timing when i use ffmpeg to change bitrate 128 -> 32k for example ? [12:55] <cbreak-work> I also reuse the conversion context [13:12] <koko_> i have song1.mp3 = 00:02:30 after convert ffmpeg -i song1.mp3 -b 32k song2.mp3 i have song2.mp3 = 00:02:35 [13:12] <koko_> how can i keep song2.mp3 with 00:02:30 [13:29] <Snowleaksange> hmm.. i had a working ffmpeg flv stream with mediaplayer.swf, but it seems thats no longer supported in many browsers. any example for html5 stream? [13:29] <Snowleaksange> what recommend codecs? [13:30] <znf> Seems that you can pretty much strike gold with h264 in mp4 [13:41] <Keyboard_Warrior> Snowleaksange, h264 in .mp4 with aac is like "the gold standard" [13:42] <Keyboard_Warrior> i asume ffmpeg still doesn automatically fast-start the mp4, so you have to do it if you want to use it online [13:43] <koko_> please how to keep same timing ffmpeg when i change bitrate 128 to 32 in mp3 ? [13:54] <relaxed> Keyboard_Warrior: it can with ffmpeg -i input -movflags faststart output.mp4 [13:54] <relaxed> koko_: timing? [13:55] <relaxed> koko_: the only thing that will change is the bitrate [13:55] <relaxed> Snowleaksange: https://trac.ffmpeg.org/wiki/x264EncodingGuide [14:02] <Keyboard_Warrior> relaxed, i really should re-familiarize myself with ffmpeg [14:02] <Keyboard_Warrior> relaxed, i was using it daily back in 2008-9 era [14:02] <Keyboard_Warrior> but, so much has changed since then [14:03] <Snowleaksange> hmm im using an ffmeg that doesnt have movflags [14:03] <Snowleaksange> gonna look at what it does [14:03] <Keyboard_Warrior> Snowleaksange, well, if you cant get a new one, its not the end of the world [14:03] <Keyboard_Warrior> theres other ways to faststart a .mp4 [14:03] <relaxed> Snowleaksange: http://johnvansickle.com/ffmpeg/ [14:04] <relaxed> or there's qt-faststart, mp4box, etc.. [14:05] <Snowleaksange> how else could you do it, Keyboard_Warrior? [14:08] <relaxed> Snowleaksange: qt-faststart input.mp4 output.mp4 [14:09] <relaxed> Keyboard_Warrior: it's an ongoing battle to stay on top of it all. [14:09] <Keyboard_Warrior> relaxed, didnt used to change this fast [14:09] <Keyboard_Warrior> amount of change in the last 2-3 years is a lot more than between 2007 and 2009 :P [14:10] <Snowleaksange> hmm [14:11] <Snowleaksange> so i gotta upgrade ffmpeg [14:11] <Snowleaksange> i cant see what this movflags does [14:12] <Snowleaksange> i was using x264 with flv [14:12] <Snowleaksange> trying to just replace flv with mp4 doesnt seem to work [14:12] <relaxed> it moves th eindex to the front on the file for better streaming [14:12] <Snowleaksange> not sure why it doesnt play [14:12] <relaxed> the index* [14:13] <Snowleaksange> yeah i understand conceptually. but not from the code [14:15] <Snowleaksange> vc->flags |= CODEC_FLAG_GLOBAL_HEADER; [14:15] <Snowleaksange> hmm maybe that just has to do with x265 [14:16] <Snowleaksange> i wonder if some flag i could set on fctx->oformat [14:17] <Snowleaksange> ok maybe ill.. UPGRADE FFMPEG! [14:17] <cbreak-work> so, I tried to isolate the sws crash [14:18] <cbreak-work> The scaling for encoding crashes even if I don't encode anything [14:18] <cbreak-work> it does NOT crash if I only encode images without decoding any [14:18] <cbreak-work> it however does not seem to be data dependent, even if I encode always the same (full white) image, it crashes on converting a white frame after decoding frame 197 [14:19] <cbreak-work> I also made it scale each frame ten times, it still crashes after frame 197 was decoded [14:22] <cbreak-work> hmm... it also crashes if I just decode those 197 frames, and then and ONLY then try to scale. [14:37] <koko_> relaxed: yes timing [14:38] <koko_> relaxed: when you change bitrate i have some millisecond in ouput file [14:39] <koko_> for example if my file is 00:02:30 after change bitrate from 128k to 32k , output file become 00:02:35 [14:53] <cbreak-work> where is the code for that ff_rgb24ToY_avx? [15:02] <cbreak-work> it gets weirder and weirder [15:02] <cbreak-work> I recompiled ffmpeg without avx support, and now the sse3 function crashes [15:03] <cbreak-work> if I disable that, it works... [15:07] <ubitux> recompile? [15:07] <ubitux> you know you can play with cpuflags at runtime right? [15:08] <ubitux> if it works with c but not asm, make sure it's not an alignment problem [15:08] <ubitux> like, make sure you use av_malloc & friends for your buffers [15:09] <cbreak-work> ubitux: I doubt it's an alignment problem [15:09] <cbreak-work> since it works 196 times with the same buffer [15:15] <cbreak-work> ubitux: what really strikes me as strange is that decoding frames in an other part of the program causes this issue [15:15] <cbreak-work> the other part doesn't even use swscaling [15:16] <ubitux> maybe a ref counting issue then [15:16] <Mavrik> or memory corruption [15:26] <cbreak-work> well, it stops crashing if I don't do av_free_packet on the packet I just decoded [15:27] <cbreak-work> but then it leaks memory like a sponge [15:43] <cbreak-work> that can't be the solution... [16:14] <Xeta> What would be a good library to use to playback video after it's been streamed & decodec by ffmpeg? This is on a linux arm device (rpi), I'm playing the audio with openal... [16:15] <Xeta> Should i just use opengl directly to print the frames? [16:16] <ubitux> i think someone was working on a hwaccel using the gpu blob thing [16:16] <ubitux> actually, i know [16:16] <ubitux> but no news since a while now [16:16] <ubitux> you won't have any interesting results without that accel on rpi [16:18] <relaxed> koko_: can you upload the input you're using somewhere? [16:19] <koko_> relaxed: yes [16:19] <relaxed> hurry, the pubs are calling. [16:21] <koko_> http://pastebin.com/VAwMwYCY [16:22] <relaxed> er, can you upload song1.mp3 somewhere? [16:23] <Xeta> ubitux: how does hwaccel work, is both the decoding and playback done on the gpu? [16:23] <ubitux> i think so [16:24] <koko_> ok [16:24] <Xeta> so it's not like i in my software first call ffmpeg to decode and then call openal to render with the raw frames? it's all done on the gpu in one go? [16:32] <koko_> where can i upload files i dont have server [16:34] <koko_> my file http://speedyshare.com/tprmD/12-Kapa.mp3 [16:37] <Xeta> Or hm, isn't it actually that first i use ffmpeg (compiled with e.g. --enable-hwaccel=h264_vaapi) and then render the frames with opengl as normal? [16:40] <Xeta> How do most video players, which use ffmpeg, render the actual video? [16:41] <Mavrik> they usually use accelerated targets [16:41] <Mavrik> so you don't have to copy frames from HW decoder memory to OpenGL context via CPU [16:43] <relaxed> koko_: So the input is 00:03:30.90 and the output is 00:03:30.94 [16:44] <koko_> yesh [16:44] <Xeta> Aha ok see Maverick [16:44] <Xeta> Do you happen to know any good example where I can learn how this is done? [16:44] <Mavrik> Xeta, see http://en.wikipedia.org/wiki/Video_overlay [16:44] <Mavrik> Xeta, it's OS specific [16:46] <Xeta> Ok but is there any built in support for this is ffmpeg? Or how do i get from av_read_frame/avcodec_decode to the accelerated target? [16:47] <relaxed> koko_: I don't know if that's a bug or not. Anyone else? ^^ [16:47] <Xeta> Or i guess i shouldn't use accodec_decode since that will give me the frames in-memory [16:55] <koko_> relaxed: have you a solution ? [17:21] <julienb> Hello all [17:21] <julienb> i need to cut videos from the end, this is possible with ffmpeg ? [17:29] <koko_> from the end ? [17:29] <koko_> julienb: some second of video ? [17:36] <julienb> koko: no, i mean i need to put an offset from the end let's say 3mn and they cut 10mn [20:24] <Logicgate> hey guys [20:24] <Logicgate> I get that [libx264 @ 0x361cb40] height not divisible by 2 [20:24] <Logicgate> when trying to watermark a film [20:24] <Logicgate> 640x361 [20:24] <Logicgate> is there a way to fix this? [20:33] <Logicgate> http://pastebin.com/m3WDz8Da [20:33] <Logicgate> here is the ffprobe output [20:33] <Logicgate> there seems to be 2 video streams, 1 audio [21:36] <BeholdMyGlory> Hi, I'm trying to use ffmpeg to grab video from a webcam using video4linux2. When I run v4l2-ctl --list-formats, I see "H264 (compressed)" as one of the available pixel formats. Does that mean that it's possible to grab H264 video directly from the webcam without having to do any additional encoding on ffmpeg's side (making it less CPU intensive to output H264 video)? If so, how do I instruct ffmpeg to grab H264 rather than YUYV video [21:36] <BeholdMyGlory> which seems to be what it's using by default? At the moment I'm running: "ffmpeg -f video4linux2 -i /dev/video0 -r 5 -s 320x240 video.mkv" [21:41] <llogan> BeholdMyGlory: ffmpeg -f v4l2 -list_formats all /dev/video0 [21:41] <llogan> * -i /dev/video0 [21:43] <BeholdMyGlory> llogan: That gives me http://hastebin.com/raw/vomexitayo [21:44] <llogan> you can choose one of the formats listed: ffmpeg -f v4l2 -input_format h264 -video_size 1280x720 -i /dev/video0 -codec:v copy output.mkv [21:45] <llogan> Raw (yuyv422) is probably default. [21:45] <llogan> http://ffmpeg.org/ffmpeg-devices.html#video4linux2_002c-v4l2 [21:47] <llogan> but your ffmpeg lacks H.264 encoding support so you can not encode from yuyv422 to H.264 if you wanted to [21:50] <BeholdMyGlory> Yeah, I know that I'd have to rebuild ffmpeg if I'm not able to grab H264 video directly from the webcam, which is another reason I'm trying to get this working [21:51] <BeholdMyGlory> Unfortunately the device I'm working with seems to have become unresponsive at a bad timing (I don't have physical access to it at the moment), but I'll see if I can get it working later, thanks for the help llogan [21:53] <jclairem> hi, I'm trying to stream raw (yuyv422) from my webcam to my LAN, what's the good way to do that? [21:54] <jclairem> right now I'm trying to avoid compression as the streaming device cannot live encode without huge latency [21:56] <jclairem> I've tried something like this; [21:56] <jclairem> ffmpeg -r 5 -s 320x240 -f video4linux2 -i /dev/video0 -c rawvideo -f rawvideo rtp://192.168.0.16:8080 [21:57] <jclairem> data is flowing to network [21:57] <jclairem> but i can't decode it using vlc [21:59] <jclairem> any hint? [22:04] <rjp421> pi cams? [22:05] <rjp421> jclairem, theres always MJPEG if all else fails [22:20] <jclairem> rjp421: yes, that's on a Rpi [22:21] <jclairem> what do you mean by "theres always MJPEG" [22:21] <jclairem> ? [22:21] <rjp421> jclairem, http://twit.tv/show/know-how/77 [22:21] <rjp421> mjpeg is ip cam style [22:22] <rjp421> not a video stream, just frame by frame [22:22] <jclairem> ok [22:22] <rjp421> but that video has a good method to making the pi an ip cam [22:23] <rjp421> using ffmpeg behind the scenes, you just edit the config [22:25] <jclairem> thx [22:26] <jclairem> looking at the video [22:26] <rjp421> not sure if theres any performance diff as opposed to just using ffmpeg alone [22:26] <rjp421> np [00:00] --- Sat Feb 22 2014

1 0

ffmpeg-devel.log.20140220
by burek 21 Feb '14

21 Feb '14

[00:41] <BtbN> Are named filter arguments changed/broken in current master? [00:56] <Compn> what error you get BtbN ? [00:57] <BtbN> it trys to use the filter line as output filename, like -vf wouldn't be there [00:57] <Compn> can you copy and paaaste ? [00:57] <BtbN> i'm not yet sure why, i suspect a bash escaping hell [00:58] <BtbN> it's a script which generates the commandline, i guess something goes wrong with that [00:58] <Compn> yes i blame your script :) [00:58] <Compn> ehe [00:58] <BtbN> oh, yea [00:58] <BtbN> -vf is not missing, it's there twice... [00:59] <BtbN> yeah, first scaling, then deinterlacing helps a lot! [01:56] <cone-632> ffmpeg.git 03Anton Khirnov 07master:6bb8720f00e2: AVOptions: deprecate unused AV_OPT_FLAG_METADATA [01:56] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:f4c8d002231a: Merge commit '6bb8720f00e2e6209665f819fb351fd42b82d5d0' [02:07] <cone-632> ffmpeg.git 03Anton Khirnov 07master:c3ecd968f0e7: AVOptions: add flags for read/read-only options [02:07] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:6a24d77929e0: Merge commit 'c3ecd968f0e78da6e77f0c06c2f785b266d83cf1' [02:17] <cone-632> ffmpeg.git 03Leandro Dorileo 07master:8370a6fa5942: libavformat/mpegts: expose raw packet size [02:17] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:c849b00b804c: Merge remote-tracking branch 'qatar/master' [02:35] <BBB> j-b: libvpx [02:37] <BBB> ubitux: I guess [02:37] <BBB> nevcairiel: thanks! [02:37] <BBB> ubitux: will add your results soon [02:39] <BBB> ubitux: we should throw in some more bitrates for you, like, I don't know, 50000kbps for vp8/x264 [02:40] <BBB> ubitux: and maybe a few lower bitrates [02:40] <BBB> ubitux: like 2500, 1000 for all [02:40] <BBB> (don't need to do 50000 for vp9, the 20k gives good enough results) [02:42] <BBB> did anyone notice the vp9 bitrate is like WAAAAAAAAAAAAAAY off on that clip? like 2x or so [02:46] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:8f33810ed26f: avfilter/vf_fps: fix rounding error accumulation [02:57] <cone-632> ffmpeg.git 03Nicolas George 07master:6c27aea81163: lavfi/pan: use extended_data instead of data. [02:57] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:cbd9cc5997ec: Merge remote-tracking branch 'cigaes/master' [03:06] <cone-632> ffmpeg.git 03Nicolas George 07master:916a79227e0d: lavf/mux: check av_dup_packet() return value. [03:27] <smarter> BBB: try encoding without --aq-mode 1 to get closer to the target bitrate [03:27] <Daemon404> O.o [03:27] <Daemon404> thats some pretty derpy rc [03:27] <smarter> also it might make things better at low enough bitrates [03:31] <smarter> Daemon404: AQ makes it harder to predict the bitrate right in VP9 very limited first pass, but yeah, 2x seems rather crazy [03:32] <Daemon404> just encode N times and use NewtonRaphson [03:32] <Daemon404> duh [03:32] <Daemon404> perfectly feasible. [03:32] <BBB> smarter: nah we'll use --aq-mode=1, I don't mind if it's off [03:33] <BBB> smarter: we'll just re-encode another one at a lower target rate ;) [03:33] <BBB> it's really 2x off [03:33] <BBB> smarter: maybe you should try to debug if --aq-mode=1 has something to do with it? I'm not sure [03:33] <BBB> x264 actually beats vp9 on this clip at high bitrates [03:34] <Daemon404> metric wise or psy? [03:34] <BBB> metric ofc, I'm not going to go into arguments with people over which clip looks better [03:34] <smarter> (for my tests, I first encoded with libvpx then did 3- or 4-pass encodes with x264 to get as close as possible to the vp9 bitrate) [03:34] <BBB> it'll never ends [03:34] <smarter> what's the clip? [03:34] <BBB> etv5k [03:34] <BBB> ask ubitux [03:34] <BBB> http://lucy.pkh.me/encodes/ [03:35] <BBB> there's the source clip also [03:35] <smarter> yeah, but I don't know if he'll be happy if I download that huge file from his host :] [03:36] <BBB> he put it there for a reason [03:36] <Daemon404> people need to start compressing these things [03:36] <Daemon404> its such a pain in the butt to dl them [03:36] <smarter> lossless VP9 :D [03:36] <Daemon404> the 4k clip i have comrpesses from 25gb to 9gb with lzma2 [03:36] <Daemon404> thats very nontrivial [03:37] <Daemon404> (yuv444p10le, so lots of redundancy) [03:52] <Compn> what about compression-in-container ? why has no video container done that ? [03:52] Action: Compn trolls and runs away [03:54] <BBB> Compn: well the cntent is compressed already, so low-overhead is all that's left [03:55] Action: Compn would like rar/zip/xz/7z demuxer in ffmpeg too [03:55] Action: Daemon404 barfs [03:56] <BBB> I'll just keep focussing on real things [03:56] <BBB> like it'd be nice if chrome used ffvp9 [03:56] <Daemon404> dont the even still use libpx for vp8 [03:56] <Daemon404> due to error concealment [03:57] <Daemon404> they* [03:57] <BBB> for webrtc yes [03:57] <BBB> for html5 and stuff related to that (including media source api), no, they use ffvp8 [03:57] <BBB> mediasource/html5 is over tcp so error concealment isn't an issue [04:19] <BBB> kierank: how many cores does obe2 have? [04:24] <BBB> looks like 8? [04:24] <BBB> can I play with that? [06:01] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:3edc3b159503: avcodec/mpeg4videodec: Check for bitstream overread in decode_vol_header() [10:04] <ubitux> <@BBB> did anyone notice the vp9 bitrate is like WAAAAAAAAAAAAAAY off on that clip? like 2x or so // yeah... :/ [10:07] <ubitux> smarter: do you want the h264 source of etv? [10:08] <ubitux> BBB: so, is that due to aq mode? [10:10] <ubitux> smarter: i don't mind if you grab the y4m, it will just take some time :p [10:12] <ubitux> -rw-r--r-- 1 ux ux 497M Feb 17 16:47 etv5k-vp8-b20000.webm [10:12] <ubitux> -rw-r--r-- 1 ux ux 940M Feb 19 13:45 etv5k-vp9-b20000.webm [10:12] <ubitux> -rw-r--r-- 1 ux ux 494M Feb 17 20:49 etv5k-x264-b20000.mkv [10:12] <ubitux> that really is freaky [10:15] <nevcairiel> vp9 fails to achieve the bitrate target? [10:15] <ubitux> by a factor 2 yeah [10:15] <nevcairiel> did 10000 work better? [10:15] <ubitux> it's closer to 2 ;) [10:15] <ubitux> -rw-r--r-- 1 ux ux 249M Feb 17 16:45 etv5k-vp8-b10000.webm [10:15] <ubitux> -rw-r--r-- 1 ux ux 501M Feb 19 07:27 etv5k-vp9-b10000.webm [10:15] <ubitux> -rw-r--r-- 1 ux ux 248M Feb 17 19:44 etv5k-x264-b10000.mkv [10:15] <nevcairiel> heh [10:16] <nevcairiel> no wonder your ssims looked pretty good [10:16] <ubitux> and before you ask, yeah 5000 as well [10:16] <nevcairiel> so encode a 2500 which comes out at around 5000, and everything is fine?!? [10:17] <ubitux> :D [10:17] <nevcairiel> seems like a serious bug, above all a 2-pass should hit its target bitrate [10:18] <ubitux> don't have the issue with your samples? [10:18] <nevcairiel> nah, perfect sizes [10:18] <ubitux> 'love my sample ;) [10:18] <nevcairiel> its the grain i tell you [10:19] <ubitux> :) [10:19] <nevcairiel> i wonder why h264 film grain synthesis was never used by anything, i'm sure it could've helped on such samples [10:22] <ubitux> ah there is actually such flag? [10:24] <nevcairiel> its technically a post-processing step in the decoder, the source is stripped of grain (or doesn't have any to begin with), and the decoder synthesis it back, but its not supported by anything i know [10:24] <nevcairiel> maybe it didn't work out as expected [10:27] <wm4> that sounds awesome, if it works [10:27] <ubitux> nevcairiel: there is not only grain in that video btw; motion is relatively creepy, there are also flashes scene cut killers, random color madness and creepy motion [10:27] <ubitux> oups quoting twice motion. [10:41] <cbsrobot> what movie is it ? [10:41] <cbsrobot> it's a good example of POV madness [10:43] <cbsrobot> s/what/which/ [10:43] <ubitux> http://www.imdb.com/title/tt1191111/ [10:44] <ubitux> cbsrobot ^ [10:44] <ubitux> 5000 frames starting at about 135 seconds [10:59] <kierank> BBB: ask ifb [10:59] <kierank> who for some reason is not online [14:25] <plepere> hmmmmm. apparently, doing multiple SWAP in ASM gives wrong results [14:25] <plepere> took some time to find that bug. :/ [14:27] <ubitux> you can use them in a loop [14:27] <ubitux> can't* [14:28] <ubitux> otherwise it's not a problem at all [14:37] <ubitux> BBB: 2.42 fpm [ETA 45:17: 21] [14:37] <ubitux> (2500, 1000 just a little less) [14:37] <ubitux> i never remember if it's 45 minutes, 45 hours or 45 days [14:37] <ubitux> but all three are indecent [14:38] <wm4> so who writes a fast encoder? is that planned for libavcodec or something? [14:39] <plepere> ubitux : actually, I'm using them in a loop and it works [14:39] <plepere> just not when they are one after another; [14:39] <ubitux> swap is only applied once [14:39] <ubitux> it's a pp [14:39] <plepere> had 3 SWAPS, but changed them to movdqa [14:40] <BBB> lol [14:40] <BBB> plepere: right, between-iterations cannot depend on each other if you use SWAP [14:40] <BBB> anyway [14:40] <BBB> ubitux: sounds good, I'm starting to have some good numbers, once we have all the correct clips let's do speed measurement son a bunch of machines [14:41] <ubitux> vp8 and x264 ones are available (1000, 2500 and 50000) [14:41] <ubitux> as you said, i won't run a 50000 one in vp9 or we'll still be on it next year [14:44] <BBB> well we already have a 50k vp9 one [14:44] <cone-677> ffmpeg.git 03Diego Biurrun 07master:192ccc5034ad: build: The MPEG-4 video parser depends on h263dsp [14:44] <ubitux> :D [14:44] <cone-677> ffmpeg.git 03Michael Niedermayer 07master:fdba564585e5: Merge commit '192ccc5034ad4ac1b5022fc16c1162267add6a0f' [14:44] <BBB> it's the one you encoded at 20k [14:44] <BBB> it was just slightly off [14:44] <BBB> oh 50k? I was thinking 40k, so it hits the 20k vp9 clip [14:45] <BBB> I guess 50k is ok also [14:45] <BBB> it doesn't matter much [14:45] <ubitux> i can do 40k as well [14:45] <ubitux> vp9 are 20x slower so... [14:45] <BBB> if it's not too much effort [14:45] <BBB> lol [14:45] <BBB> I'll look at the results tonight, thanks [14:45] <BBB> and then hopefully this weekend it's all done [14:46] <BBB> I have most of the figures we need, we just need the vp9 vs libvpx comparisons of a few selected clips (same-quality per codec probably) on a bunch of machines [14:46] <cone-677> ffmpeg.git 03Diego Biurrun 07master:61e7c7f27b0a: svq3: Adjust #endif comment [14:46] <cone-677> ffmpeg.git 03Michael Niedermayer 07master:e948f17369d4: Merge commit '61e7c7f27b0a2652bf5cd282b97762ee99d025ef' [14:46] <BBB> work now though [14:57] <cone-677> ffmpeg.git 03Diego Biurrun 07master:ba42c852477e: bit_depth_template: Use file name as multiple inclusion guard [14:57] <cone-677> ffmpeg.git 03Michael Niedermayer 07master:a0cfec2e2bbb: Merge commit 'ba42c852477e87f6e47a5587e8f7829c46c52032' [15:11] <sspiff> can anyone tell me if the teletext subtitle decoder actually works? [15:11] <ubitux> it depends on an external lib [15:11] <ubitux> make sure you have it and linked ffmpeg against [15:11] <sspiff> ubitux: libzvbi right? [15:11] <Compn> yes zvbi [15:11] <sspiff> and I can use the codec ID CODEC_ID_DVB_TELETEXT or should I use LIBZVBI_TELETEXT? [15:11] <ubitux> sspiff: did you register codecs? [15:11] <ubitux> does it work with other codec id? [15:11] <sspiff> ubitux: yeah, plain DVB subtitles work [15:11] <ubitux> is ffmpeg recognizing them? [15:11] <sspiff> yes, I'm generating PNG's from them [15:11] <Compn> sspiff : are you playing a stream or a file with teletext ? [15:11] <Compn> playing/encoding whatnot [15:11] <Compn> uploading a sample goes a long way in us reproducing any bugs... [15:14] <sspiff> Compn: it contains this: Stream #0:14[0x157f](eng): Subtitle: dvb_teletext ([6][0][0][0] / 0x0006) [15:15] <sspiff> but it seems like configure isn't picking up zvbi [15:15] <sspiff> so that's the problem I suppose [15:15] <ubitux> it's not enough to say the decoder is build with [15:15] <ubitux> ./ffmpeg -codecs|grep teletext [15:15] <ubitux> and check if there is the D flag [15:15] <ubitux> if not, then that's not built correctly [15:15] <sspiff> nope, it's not there, thanks! [15:15] <sspiff> I really should repay you guys by improving the dvb subtitle encoder! [15:22] <cone-677> ffmpeg.git 03Diego Biurrun 07master:017a06a9ee86: x86: dsputil: Use correct file name as multiple inclusion guard [15:22] <cone-677> ffmpeg.git 03Michael Niedermayer 07master:8372aaf7210e: Merge commit '017a06a9ee86b047079166c2694c9c655ff03356' [15:41] <cone-229> ffmpeg.git 03Diego Biurrun 07master:984e3398662d: avcodec: Consistently name encoder init functions foo_encode_init [15:41] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:add54280bfc1: Merge commit '984e3398662d460e15904f9e4a6df9ef759070cb' [15:47] <cone-229> ffmpeg.git 03Diego Biurrun 07master:4bcca3611da2: mpeg4video_parser: Drop pointless av_-prefix from static function [15:47] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:c427b2b86e72: Merge remote-tracking branch 'qatar/master' [16:20] <ubitux> any news on bayer support? [16:27] <Compn> ubitux : ask pross? but also someone made it into a GSOC task for some reason [16:29] <ubitux> > This makes the helgrind error disappear. [16:29] <ubitux> yay \o/ [16:34] <Daemon404> helgrind clean fate is onl 9 years away now [16:42] <cone-229> ffmpeg.git 03Nicolas George 07master:299a56879d2d: ffmpeg: make reading packets from thread blocking. [16:42] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:d089e9a4d125: Merge remote-tracking branch 'cigaes/master' [16:58] <ubitux> Daemon404: huh? [18:29] <wm4> michaelni: so what _is_ the reason that this lock manager stuff exists? [18:31] <wm4> other than historic reasons (when ffmpeg didn't have any locking or atomics) [18:39] <michaelni> iam pretty sure that was discussed on the ml at least once. but its basically, 1. difficulty to proof that all global init of codecs is thread safe, 2. av_find_stream_info() using codecs (and thus their init) 3. uncertainity of lock compatibility (in case a specific one like pthreads is used) and then theres 4. dfficulty of deallocating the lock [18:39] <michaelni> there are many ways out but each is a compromise of some kind [18:42] <michaelni> in that way the existing lock manager is a compromise too [18:42] <michaelni> lock manager system [18:53] <wm4> you don't need to deallocate the lock, and you can easily do it in a way that hides the log from valgrind to avoid the user questions [18:53] <wm4> lock compatibility (3.) seems very questionable; even if pthread is a wrapper, it will use the operating system's mutexes [19:59] <michaelni> wm4, please do hide it from the users valgrind log [20:03] <michaelni> if theres anythng i can do to help, like applying a patch, iam happy to do so [20:39] <llogan> ubitux: RE: dropbox, "The faststart option of ffmpeg does a second pass on the file that is output of ffmpeg. This is unfortunately not useful for us because we need to rearrange the moov atom *before* it gets into ffmpeg. This is because we want to avoid the latency involved in fetching the whole content from the storage system before starting transcoding." [20:41] <Daemon404> the article wasnt that interesting [20:41] <Daemon404> nothing surprising or novel [20:42] <llogan> that's because it didn't have any cats in it for you [20:42] <Daemon404> ? [20:48] <Compn> llogan : then you write a special mov muxer that writes a fake header index [20:49] <Compn> thats i think, the only way to hack a mov without re-writing the index [20:52] <wm4> how did they manage to misdesign mov that it can't be streamed? [20:53] <wm4> even mkv got this right [20:54] <JEEB> you can, it's just that no-one does it right [20:54] <JEEB> no-one uses the fragments feature [20:54] <JEEB> and even less people implement it in their demuxers [20:55] <Compn> iirc apple only does keynotes over rtsp [20:55] <Compn> the only other mp4 streaming is that adobehds or apple hls or silverlight or all that nonsense with 1000 mp4 files cut up into 200k chunks [20:56] <Daemon404> hls and dash both satisfy the latter [20:56] <JEEB> HLS is mpeg-ts [20:56] <Daemon404> and by silverlight you mean smoothstreaming [20:56] <Daemon404> ah yes [20:56] <Daemon404> true [20:56] <Compn> wm4 : i had an argument with a user in #mplayer how .avi was not made for streaming either. there were and are no live .avi streams :P [20:57] <Compn> its just so old that the internet (and even networked computers) werent ready for streaming video [20:57] <wm4> having the player concatenate small files for streaming sounds pretty retarded [20:57] <wm4> even worse than mkv ordered chapters [20:57] <wm4> maybe they should just use .ts or so... [20:58] <wm4> not fragments of it of course [20:58] <Compn> i actually dont mind ordered chapters, its just i havent seen a compelling argument for watching the opening and ending to each anime episode. [20:58] <Compn> which happens to be ordered chapters' only big use case [21:00] <Compn> oh well complaining about old stuff again [21:00] <Compn> hows GSoC going ? [21:04] <llogan> no news until Feb 24: List of accepted mentoring organizations published on the Google Summer of Code 2014 site. [21:04] <llogan> then on Feb 28 they will tell us "why" we got rejected. [21:04] <Compn> ehe [22:47] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:0c803eba2f56: avformat/mov: make invalid sampledelta error more verbose [23:07] <cone-229> ffmpeg.git 03Janne Grunau 07master:982b596ea664: h264: avoid undefined behavior in chroma motion compensation [23:07] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:4d943cec68f3: Merge commit '982b596ea6640bfe218a31f6c3fc542d9fe61c31' [23:08] <cone-229> ffmpeg.git 03Christophe Gisquet 07master:ef010f08ae53: dca: replace some memcpy by AV_COPY128 [23:08] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:1bef9c5e83c0: Merge commit 'ef010f08ae53479c54e2f16be5a7e1a809a9e268' [23:12] <cone-229> ffmpeg.git 03Christophe Gisquet 07master:996697e266c8: x86: float dsp: unroll SSE versions [23:13] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:1859b1de31bd: Merge commit '996697e266c8adc0ad9b7fc7568406c7529c97cf' [23:17] <cone-229> ffmpeg.git 03Janne Grunau 07master:9c029f67ca82: aarch64: use EXTERN_ASM consistently for exported symbols [23:17] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:490215cbd70e: Merge commit '9c029f67ca82147ddfa83a1546ee1e109e11fbd4' [23:21] <ubitux> should i add a valgrind + cpuflags none? [23:26] <cone-229> ffmpeg.git 03Diego Biurrun 07master:6adf4290ebcf: configure: Move inet_aton check into network function check block [23:26] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:36eec0321182: Merge commit '6adf4290ebcf65ac8243d74f34ba0a508f561633' [23:37] <cone-229> ffmpeg.git 03Diego Biurrun 07master:2b0bb69997c2: configure: Move cpunop into ARCH_EXT_LIST_X86 [23:38] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:5176e9651bda: Merge commit '2b0bb69997c2416e74f41aa1400ce983bf8775c0' [23:39] <BBB> ubitux: cool, I see the encodes are finished? [23:39] <ubitux> BBB: not vp9 [23:39] <ubitux> in progress [23:39] <ubitux> but yeah of course all the others are done [23:40] <ubitux> ETA 24:15: 23 [23:40] <ubitux> you can follow on http://lucy.pkh.me/encodes/logs/etv5k-vp9-b1000.log and http://lucy.pkh.me/encodes/logs/etv5k-vp9-b2500.log [23:41] <BBB> I see a vp9 1000, 2500, 5000 [23:41] <BBB> or is that inprogress files? :) [23:41] <ubitux> yeah in progress [23:41] <BBB> ah [23:41] <BBB> sneaky [23:41] <ubitux> 5000 is done though [23:41] <ubitux> check the related log file [23:41] <ubitux> you can see if it's done there [23:42] <ubitux> BBB: http://lucy.pkh.me/encodes/ssim-summary.txt [23:42] <ubitux> those are done [23:43] <ubitux> i should have run a 500 for vp9... [23:43] <ubitux> but hey, fuck the speed [23:43] <ubitux> that's not fun anymore :( [23:44] <Daemon404> hmm [23:44] <Daemon404> -vf alphaextract doesnt extract alpha from pal8 png [23:44] <Daemon404> :/ [23:45] <BBB> ubitux: i know, the encoder is slow [23:48] <cone-229> ffmpeg.git 03Luca Barbato 07master:d6a27f885b5d: configure: Add usan to the toolchain presets [23:48] <cone-229> ffmpeg.git 03Michael Niedermayer 07master:9026c49c82dc: Merge commit 'd6a27f885b5d4cba7a82e50af423c741d2f37c3e' [23:49] <Daemon404> lol... convertign to rgba, and piping to a 2nd ffmpeg works [23:50] <michaelni> ubitux, is your gcc on your fate client new enough for usan and all that stuff ? [23:50] <ubitux> what version do i need? [23:51] <ubitux> seems i have 4.8.2 [23:51] <nevcairiel> usan is only 4.9 iirc, which isnt even released yet [23:52] <ubitux> k [00:00] --- Fri Feb 21 2014

1 0

ffmpeg.log.20140220
by burek 21 Feb '14

21 Feb '14

[00:03] <BtbN> Is there any less cpu intensive useable deinterlacer in ffmpeg? [00:07] <klaxa> as opposed to what? [00:07] <BtbN> yadif [00:07] <BtbN> it's just too much at 1080i [00:07] <klaxa> hmm... i don't think there is [00:08] <klaxa> what you could try is -vf fieldmatch,decimate [00:08] <BtbN> what does that do? [00:08] <klaxa> basically the same, it matches fields (interlaced frames) and removes duplicate frames [00:08] <klaxa> at least that is how i understand it [00:09] <klaxa> i use it for .ts files from TV streams [00:09] <klaxa> i might use even more cpu though [00:09] <klaxa> worth a try though maybe? [00:09] <BtbN> than yadif? oO [00:10] <BtbN> it uses like one full core on its own [00:10] <klaxa> how do you know? [00:10] <BtbN> because it does? [00:11] <klaxa> where do you take that information from? [00:11] <BtbN> the cpu usage?! [00:11] <rjp421> anyone on windows using -f dshow -i "WebcamMax Capture"? im using the latest ffmpeg 2.1.3 win64 build, and keep getting "real-time buffer not full, frame dropped" errors.. i dont want to have to set -rtbufsize to 2 gig, and -r 10000/1001 before -i stopped the errors, but produced 10fps video.. i tried 24000/1001 for 24fps but still got the error flooding the screen. [00:12] <klaxa> but you must be re-encoding if you are using yadif so i wouldn't think yadif is using up most of the cpu usage [00:12] <BtbN> it clearly does, because without it it's not using one full core on its own... [00:16] <Mavrik> yadif does burn alot of CPU [00:16] <Mavrik> but it's pretty much the best thing you have [00:16] <BtbN> well, it's worth nothing if the cpu can't keep up [00:16] <Mavrik> hmm, [00:16] <Mavrik> just how crappy is your CPU then_ [00:16] <BtbN> i3 3220 [00:17] <Mavrik> even at it's worst, yadif doesn't really go over 10% of cpu usage for x264 encode [00:17] <BtbN> 1080i25 is quite taxing [00:17] <BtbN> the output format doesn't matter for the deinterlacing [00:17] <Mavrik> *shrug* [00:18] <Mavrik> we have no problems doing 1080i/50 -> 1080p/25 [00:18] <Mavrik> 4-5 streams or so on a quad [00:18] <BtbN> one is the max [00:19] <BtbN> how do i pass a named parameter to a filter? [00:22] <llogan> which filter? [00:23] <BtbN> any filter, the parameters all have names, but i haven't found out how to set them by name, only via a : seperated value list [00:23] <Mavrik> filter=parameter=bla:paramter2=bla2 [00:24] <BtbN> huh, it just errord to me about that, that it wouldn't know the parameter interl at the scale filter [00:27] <BtbN> scale=trunc(oh*a/2)*2:min(720\,ih):interl=1: Invalid argument [00:27] <BtbN> that's what i get [00:29] <BtbN> nope, also doesn't work if i name them all [00:36] <BtbN> i don't get it, according to google that's how it should just work [00:37] <BtbN> "scale=2*iw:2*ih:interl=1" even the docs say it, but it doesn't work [00:41] <BtbN> even just scale=w=1280:h=720 fails with Invalid argument. [00:43] <BtbN> it's using it as a filename, what? [00:44] <renihs_> thanks for the help! gn8 [00:47] <Mavrik> BtbN, make sure you're properly escaping stuff for your shell. [00:47] <BtbN> the string is printed by ffmpeg correctly and as one piece, i don't think that's the issue [00:48] <BtbN> got it working now without named params, but encoding interlaced video seems to just fail. Only get green output [01:07] <llogan> without your actual command and console output we can not help [01:19] <BtbN> llogan, seems like libx264 or something in ffmpeg can't handle interlaced video propperly. It's not very well tested i guess [04:55] <aji> #ffmpeg [05:01] <sacarasc> This is #ffmpeg. [08:21] <njoyard> Hello everyone [08:21] <njoyard> I'm looking into using ffmpeg to transcode videos on the fly to serve to a HTML5 player [08:22] <njoyard> As browsers do byte-based Range requests to the web server, I'm wondering if there is a way (under certain codec conditions of course) to determine/enforce the total transcoded file size using ffmpeg ? [08:24] <njoyard> (if possible I would like to avoid waiting for the whole video file to be transcoded before being able to serve it) [08:36] <hendry> hi, i'm trying to make an mp4, given a bunch of jpegs, is this the correct way of going about it? ffmpeg -r 1/10 -i $tmpdir/%03d.jpg -c:v libx264 -r 30 -pix_fmt yuv420p out.mp4 [08:36] <zap0> tias [08:44] <hendry> it seems to most a whole bunch of frames though. what am I missing in this log? http://ix.io/aCG [08:59] <Keshl> hendry: One thing I notice, the -s is wrong. you want -vf scale=360:240. [08:59] <Keshl> I forget what -s is. I'm pretty sure it's "seek ahead inaccurately to nearest keyframe", though. [09:07] <hendry> i think the problem i have is the images are in different resolutions https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images [09:08] <hendry> i'm not quite sure how I get the images all to 1440x1080 http://ix.io/aCJ [09:10] <Keshl> Yes, that actually /is/ the issue. I've run into it before. It'll take the resolution of the first frame, then only encode identically-sized frames. ANnoying as heck. <.< [09:10] <Keshl> I'm not sure of any fast way to fix it either. I ended up doing it by hand with Gimp. Took like five minutes for ~300 frames. (Not that hard to do it /really/ fast if you're good with keyboard shortcuts.) [09:11] <hendry> been trying imagemagick, neither -resize 1440x1080 not -scale 1440x1080 works [09:22] <hendry> Keshl: think I nailed it http://ix.io/aCM [09:23] <Keshl> Shiny. -É-. [09:54] <brontosaurusrex> how do i say what fps a y4m should have? [09:54] <brontosaurusrex> input is png sequence [10:17] <zap0> brontosaurusrex, http://ffmpeg.org/ffmpeg.html very first mention of 'fps' [10:20] <brontosaurusrex> zap0, yeah, that doesn't seem to work [10:21] <brontosaurusrex> i did -r 24 before input and -r 24 before output and it still seems like 25 fps files [10:21] <brontosaurusrex> unless y4m has no fps info [10:28] <relaxed> y4m should have the fps [10:29] <relaxed> oh, -r after the input will set its framerate [10:30] <relaxed> $(sed q input.y4m) should show you [11:37] <zap0> brontosaurusrex, y4m is just raw video in'it ? [11:38] <brontosaurusrex> zap0, mostly [11:38] <brontosaurusrex> should have a simple header [11:38] <zap0> brontosaurusrex, maybe it has no fps [11:38] <brontosaurusrex> it has resolution [11:39] <brontosaurusrex> well, i got the pipe to work [11:39] <brontosaurusrex> ffmpeg -r 24 -i big_buck_bunny_%05d.png -pix_fmt yuv420p -r 24 -f yuv4mpegpipe - 2> /dev/null | x265 --crf 20 -o bbb.hevc - --y4m [11:39] <brontosaurusrex> i think [11:39] <brontosaurusrex> and it looks like x265 knows the framerate now [11:40] <brontosaurusrex> "y4m [info]: 1920x1080 24/1 fps i420, unknown frame count" [11:40] <zap0> brontosaurusrex http://wiki.multimedia.cx/index.php?title=YUV4MPEG2 [11:40] <brontosaurusrex> can't open the browser for the next few hours i suppose [11:41] <brontosaurusrex> 100% cpu at 2.3 fps < encoding [11:41] <zap0> set priority of that to low. [11:41] <brontosaurusrex> how to do that on nix? [11:41] <zap0> nice [11:42] <brontosaurusrex> yes, but i can't change the priority now i guess? [11:42] <zap0> why not? [11:43] <active8> OT: anyone know how to fix ++ WARN: [mpeg2enc] Frame height won't split into two equal field pictures... (piped from a jpeg2yuv) ? [11:44] <zap0> stop using odd height vale [11:44] <zap0> value/ [11:49] <brontosaurusrex> yeah, htop + f8 did something [11:50] <active8> zap the conversion came from a gm / imagemagic conversion that specified a width just to keep the aspect ratio. I might need to address the prob that way. maybe crop a line/px [11:50] <javisepe> Hi! Could you help me with a compiling process? [11:51] <javisepe> cross-prefix=arm-unknown-linux-gnueabi- [11:51] <javisepe> arm-unknown-linux-gnueabi-gcc is unable to create an executable file. [11:51] <javisepe> C compiler test failed. [11:51] <javisepe> If you think configure made a mistake, make sure you are using the latest [11:51] <javisepe> version from Git. If the latest version fails, report the problem to the [11:51] <javisepe> ffmpeg-user(a)ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net. [11:51] <javisepe> Include the log file "config.log" produced by configure as this will help [11:52] <javisepe> solving the problem. [11:52] <javisepe> cross-prefix=arm-unknown-linux-gnueabi- [11:52] <javisepe> arm-unknown-linux-gnueabi-gcc is unable to create an executable file. [11:52] <javisepe> C compiler test failed. [11:52] <javisepe> If you think configure made a mistake, make sure you are using the latest [12:11] <active8> hendry: image magic is posed to be less efficient than grahics magic. I think i used im. one or the other has a utility and syntax to specify the width or height only and maintain aspect ratio. right now I'm using gm and it works great but mpec2enc is warning about Frame height won't split into two equal field pictures. [12:25] <active8> ffmpeg -r 1/10 -i $tmpdir/%03d.jpg -c:v libx264 -r 30 -pix_fmt yuv420p out.mp4 [12:26] <active8> is -r 1/10 just a cool way to say one picture every 10 sec? [12:32] <brontosaurusrex> active8, i guess, that would be 0.1 fps [12:33] <active8> that was a cool trick i didn't seen in any of the 1000 tabs open IIRC (or I don't RC) [12:35] <active8> and I would think the -pix_fmt yuv420p bit should come before -i, but what is that? not in man. is it a way to say "this is what is getting encoded into the mp4? [12:36] <brontosaurusrex> this is what we will convert into before feeding x264 [12:37] <active8> brontosaurus: -r is fps and it's in Hz which is cycles per second; so yes, you are correct [12:38] <active8> and x264 is the default mp4 or only. i have to read up on those guys. lots of forums with alphabet soup today, h264 libx faac* vs whatever. heh heh what fun with a kick ass program like ffmpeg [12:39] <active8> s/only/omly one/ [12:39] <active8> and s/omly.only. oh boy [12:39] <active8> never mind [12:54] <njoyard> javisepe: are you sure arm-unknown-linux-gnueabi-gcc is in the PATH and runs ? did you compile a test hello world with it ? [13:59] <brontosaurusrex> JEEB, how do i mux raw hevc with m4a (aac) audio with l-smash? [14:01] <JEEBsv> m4a is already muxed so use remuxer for that [14:01] <JEEBsv> muxer is for raw streams [14:02] <JEEBsv> (patches welcome to improve it) [14:02] <Paranoialmaniac> :) [14:06] <sspiff> I'm having trouble opening a teletext subtitle in my code [14:08] <sspiff> avcodec_find_decoder(AV_CODEC_ID_DVB_TELETEXT) returns 0 for me [14:08] <sspiff> and fmt_ctx->streams[i]->codec->codec_id == AV_CODEC_ID_DVB_TELETEXT is true. [14:09] <sspiff> I recompiled --enable-decoder=libzvbi_teletext explicitly mentioned, but it still won't work [14:10] <sspiff> anyone here know what I could be doing wrong? [14:24] <brontosaurusrex> JEEBsv, ok [14:52] <rjp421> JEEB, ive currently ended up with: ffmpeg -f dshow -i video="WebcamMax Capture":audio="Microphone (ManyCam Virtual Mic" -c:v libx264 -crf 23 -preset slow -r 24 -profile:v main -maxrate 554k -bufsize 1108k -vf "scale=640:-1,format=yuv420p" -g 48 -threads 0 -c:a libvo_aacenc -b:a 96k -ac 1 -ar 44100 -sn -f flv "rtmp://1.11002.fme.ustream.tv/ustreamVideo/11002/channelStreamKey flashver=FME/3.0\20(compatible;\20FMSc\201.0) live=1" [14:54] <rjp421> it works but wont go above 554k... that encoding for streaming page said to only count the video bandwidth [14:55] <rjp421> unless the output is only showing the outbound video bitrate [16:46] <Demon_Fox> It would seem that celt and opus get nearly the same result [16:47] <Demon_Fox> though opus uses celt and silk, iirc [17:01] <Na_Klar> After tons of reading about mapping, I think to understand how it works. But I cannot find out why this command-line fails: http://pastebin.com/DSQrm7ND ... some hint would be appreciated. [17:09] <Na_Klar> meh, avconv does the job ... nvm [22:28] <Mista_D> any way to just copy a file as is in the same container (as part of automated process where ffmpeg has to be envoked)? [22:33] <llogan> Mista_D: i guess you could script it. [22:34] <Mista_D> llogan: will have to do... [22:35] <Mista_D> Any way to use "copy" filter? [22:37] <llogan> http://mywiki.wooledge.org/BashFAQ/073 would be useful for scripting [22:45] <Mista_D> llogan: Thank you, looked over it... [22:57] <spaam_> ux is the old ubitux ? :) [22:57] <ubitux> actually the "new" [00:00] --- Fri Feb 21 2014

1 0

ffmpeg-devel.log.20140219
by burek 20 Feb '14

20 Feb '14

[01:58] <cone-137> ffmpeg.git 03Michael Niedermayer 07master:8f853159f6ea: avutil/opt: preserve fractions in set_string_number() [02:24] <cone-137> ffmpeg.git 03Luca Barbato 07master:96f9fbe10933: h264: fix slice_type value reported in decode_slice_header() [02:24] <cone-137> ffmpeg.git 03Michael Niedermayer 07master:2d93f76f8ab6: Merge commit '96f9fbe10933944b3eba86efa1d1ca094f2c28f8' [02:32] <cone-137> ffmpeg.git 03Luca Barbato 07master:fea6db064b00: h264: informative error reporting in decode_slice_header() [02:32] <cone-137> ffmpeg.git 03Michael Niedermayer 07master:d0e236292d24: Merge remote-tracking branch 'qatar/master' [02:47] <cone-137> ffmpeg.git 03Ronald S. Bultje 07master:b9936e59e8e0: tiny_ssim: add per-frame metrics and final ssim db number. [02:50] <BBB> nevcairiel: I see the smaller vp9 files are still encoding? :-p [06:50] <anshul> guys I was adding av_cleanup_on_lib_unload() in ffmpeg, which file would we most suitable for this purpose [09:59] <ubitux> nevcairiel: encoder and decoders should be able to do whatever they want to! :D [10:15] <nevcairiel> ubitux: its a lost cause, i should just submit revert commits to ffmpeg instead of trying to argue over there [10:31] <nevcairiel> also, all my encodes are done now, will try to create the SSIM values later today [10:31] <JEEB> need a win32 binary of the dump_ssim tool? [10:31] <JEEB> I built one a few months ago [10:31] <nevcairiel> nah, using tiny_ssim [10:31] <JEEB> k [10:31] <nevcairiel> BBB patched it to produce the values we want [10:32] <ubitux> 5k and 10k are done for me [10:32] <ubitux> 20k should be done in a few hours [10:32] <nevcairiel> i added 500 750 1k and 2.5k [10:32] <nevcairiel> the high bitrates were boring [10:32] <ubitux> ah, should i add them as well? [10:33] <nevcairiel> dunno [10:33] <nevcairiel> my source was rather clean so that the high bitrates didnt change much [10:33] <ubitux> you're using these bitrate with 1080p? [10:33] <nevcairiel> yeah [10:33] <nevcairiel> 1mbit looks surprisingly well [10:33] <nevcairiel> but yeah, extremely clean source material [10:35] <nevcairiel> anyway everything up here now http://files.1f0.de/encodes/ .. in case someone wants to see a scene from ToS in 500kbit :p [10:43] <JEEB> that makes me notice that my copy of mpv has a bugged vp9 decoder [10:43] <JEEB> non-intra pictures get whoopsie-daisie'd [10:43] <nevcairiel> does it use libav? :P [10:43] <JEEB> nope [10:58] <aca> ubitux: I got 'make check' working by exporting LD_LIBRARY_PATH to the local build directories. Now I wonder, how this works for everyone else. Do you run 'make install' first? [10:59] <ubitux> i never make install, except when doing random configure/build tests [10:59] <ubitux> i'm just running make check (actually make fate) from the build dir [10:59] <aca> ubitux: strange... [10:59] <ubitux> but i'm not building with --enable-shared [10:59] <ubitux> so& ;) [11:00] <aca> ubitux: That may be the cause. [11:00] <ubitux> i have a shared fate instance, let me check how i do that& [11:01] <ubitux> extra_ldflags="-Wl,-rpath=libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample" [11:01] <ubitux> heh. [11:01] <aca> ubitux: Ah! [11:01] <ubitux> i think there is an option for this nowadays [11:01] <ubitux> --enable-rpath probably [11:02] <aca> ubitux: Would it not be simpler to export LD_LIBRARY_PATH in fate-run.sh (my current workaround)? [11:02] <ubitux> well, you may want to run ffmpeg without fate [11:02] <ubitux> :p [11:02] <ubitux> so there is no point in having that env variable at fate level [11:03] <aca> ubitux: I mean just for the tests. [11:03] <ubitux> well, just do LD_LIBRARY_PATH=... make fate then [11:04] <ubitux> it would be evil to set it in fate-run.sh [11:04] <ubitux> anyway, rpath is probably going to cause issues for packaging [11:06] <aca> ubitux: I will try adding 'export LD_LIBRARY_PATH=...; ' to the Makefile now. [11:07] <ubitux> why export? won't do as a command prefix? [11:08] <aca> ubitux: That's probably better. [11:38] <aca> ubitux: It doesn't work without export, at least not for ffprobe-test.nut. [12:49] <ubitux> huh, libav is re-implementing the replaygain filter? [12:50] <wm4> there's a replaygain filter? [12:50] <JEEB> yes [12:50] <JEEB> but as far as I see it, they're just talking about how to handle the side data [12:50] <JEEB> it could mean that elenril was reimplementing that filter, but I have NFI [12:51] <wm4> isn't that filter about generating replaygain data? [12:51] <wm4> instead of applying it [12:51] <JEEB> yup [12:53] <ubitux> adding side data... from the filter side? wut? [12:53] <wm4> no, reading it from the demuxer [12:54] <ubitux> aah [12:54] <ubitux> oh well, then in volume filter [12:54] <ubitux> and read metadata from there [12:56] <BBB> ubitux: we'll see how the high ones look; if you look at my graphs, you can sort of see the range of ssim values (in dB) we're interested in, and if you go way beyond that, we should lower your rates a little also [12:57] <BBB> ubitux: the good thing is that lower bitrates tend to encode faster [12:57] <BBB> and yes tiny_ssim is ok now, and much easier to build than dump_ssim, so let's stick to tiny_ssim [12:58] <JEEB> nice [12:58] <BBB> I figured patching tiny_ssi would be faster than building dump_ssim [12:59] <BBB> plus dump_ssi itself ended up being terirbly, terribly slow [13:06] <JEEB> yeah, it's not exactly fast if I recall correctly [14:00] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:36fb07d1abc7: avcodec/mpeg4videodec: set field durations to safe values when they are invalid [14:07] <cone-632> ffmpeg.git 03Martin Storsjö 07master:543156d7518f: arm: Mark the stack as non-executable [14:07] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:53d11f7b2d38: Merge commit '543156d7518f5e5d731123da066d86278f9fa492' [14:13] <ubitux> http://gcc.godbolt.org/ fun, probably old [14:15] <wm4> ubitux: what should I name the avoption for microdvd, and what should it do? [14:15] <ubitux> keep the same name as aqtitle [14:16] <ubitux> "subfps" [14:16] <wm4> and how does this solve the problem at hand? [14:17] <ubitux> if it's set in the file and not by the user, you override the value [14:17] <ubitux> you set a default one of 0/1 or something [14:17] <ubitux> or 0/0 [14:20] <wm4> what if the user wants to override it, but only if the format is frame based? [14:31] <cone-632> ffmpeg.git 03Martin Storsjö 07master:1e142d5b4842: movenc: Add a fallback fragmentation method for plain mp4 as well [14:31] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:ef1aae6ea9aa: Merge commit '1e142d5b4842dcb39fcb0e92e4aacbc9977bfa66' [14:31] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:3f461566b707: avformat/movenc: simplify code, decrease difference to libav [14:32] <nevcairiel> BBB: does the order of inputs matter to tiny_ssim? i used tiny_ssim original.yuv decoded.yuv now without thinking about it until now :p [14:43] <BBB> nevcairiel: no, shouldn't [14:44] <cone-632> ffmpeg.git 03Diego Biurrun 07master:294a51e18ab7: gitignore: Add all examples below doc/examples [14:44] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:d808dce4a98f: Merge commit '294a51e18ab7df4d658249361a03f0d716a4e9f0' [14:44] <nevcairiel> BBB: well then, all my encodes and ssim info is up here now: http://files.1f0.de/encodes/ [14:46] <BBB> can you tail the last line of each .ssim file in a ssim.summary? [14:46] <BBB> for now we only need the total line [14:46] <nevcairiel> sure [14:46] <BBB> like grep ^Total *.ssim > ssim.summary [14:46] <ubitux> nevcairiel: you didn't keep the log? [14:46] <BBB> (I hope that includes the filename, else it sucks) [14:46] <nevcairiel> ubitux: i have the logs locally, they cluttered up the web folder :p [14:47] <ubitux> :) [14:47] <ubitux> oh, 20k done \o/ [14:47] <BBB> how many cores do you guys have? [14:48] <ubitux> 4HT [14:48] <nevcairiel> 4+4 [14:48] <BBB> I really only have 2 so any sort of mt comparison stops at 2 :-p [14:48] <BBB> 4ht = 4+ht, or 2x2ht? [14:48] <BBB> (I have 2x2ht) [14:48] <BBB> maybe you guys should do the mt comparisons then [14:48] <BBB> I get good numbers from 1 to 2 [14:49] <BBB> but from 2 to 4 it sort of crumbles [14:49] <nevcairiel> the tiny_ssim tool is weird [14:49] <nevcairiel> it produced files with \r line endings [14:50] <nevcairiel> not \n .. not \n\r [14:50] <BBB> sed -e 's|\r|\n|g' :-p [14:50] <BBB> and yes I use \r, it's shelly [14:50] <smarter> tr '\r' '\n' :] [14:50] <nevcairiel> tail didnt like those files [14:50] <nevcairiel> :P [14:51] <j-b> good morning [14:51] <BBB> nevcairiel: for file in *.ssim; do sed -e 's|\r|\n|g' $file | grep ^Total; done > ssim.summary [14:51] <smarter> what are you doing all these encodes for? Decoding performance benchmarks? [14:51] <BBB> smarter: basically same-quality decoder performance benchmarks [14:51] <BBB> smarter: but it also shows you ow the encoders compare (ignoring encoder performance, obviously) [14:51] <smarter> same quality between what and what? [14:52] <BBB> e.g. same quality vp9 and h264; which decodes faster? [14:52] <smarter> oh I see, nice [14:52] <ubitux> so isatty doesn't work well for the \n \r thing? [14:52] <smarter> I might be interested in putting the resulting encodes on http://exp.martres.me/splitview/ :) [14:52] <BBB> some google exec came out saying vp9 wouldn't be more than 50% more complex than vp8; so is that true? for same-filesize, or same-quality? [14:53] <BBB> (oh it was 40%, not 50%) [14:53] <BBB> smarter: yeah, I want to do that actually [14:53] <BBB> smarter: but not there yet... lots of work to do [14:53] <smarter> okay, cool [14:54] <BBB> work [14:54] <BBB> bbl [14:54] <nevcairiel> BBB: summary file up now [14:55] <nevcairiel> hm i should sort it, file system sort doesnt do well with numbers [14:58] <nevcairiel> in quality per bitrate vp9 seems to beat x264 at least ...igorning that it took like 20x the time to encode though [15:06] <ubitux> eval $(ffprobe -v 0 -of flat=s=_ -select_streams v:0 -show_entries stream=height,width $1) [15:06] <ubitux> size=${streams_stream_0_width}x${streams_stream_0_height} [15:06] <ubitux> i love ffprobe e [15:09] <smarter> what settings are you using for your encodes? [15:17] <ubitux> BBB: weren't you supposed to isatty(1) instead of isatty(0) && isatty(2)? [15:19] <ubitux> you're only interested in stdout piping [15:20] <ubitux> it fixes the issue nevcairiel was talking about [15:20] <nevcairiel> the \r ? :p [15:20] <nevcairiel> i was redirecting to a file when that happened, in case it matters [15:20] <ubitux> yes [15:20] <ubitux> it happens all the time [15:20] <ubitux> the isatty check can't work [15:21] <ubitux> nevcairiel: http://pastie.org/8748691 [15:21] <ubitux> try this [15:21] <nevcairiel> lazy, files are done now :( [15:21] <ubitux> then "tiny_ssim ..." vs "timy_ssim ... | cat" will work as you expect [15:26] <ubitux> http://ubitux.fr/pub/pics/_ssim-art.png [15:27] <ubitux> http://lucy.pkh.me/encodes/ [15:27] <ubitux> smarter: see encode.sh [15:27] <ubitux> 'will print the encode commands [15:28] <ubitux> http://pastie.org/pastes/8748711/text [15:28] <smarter> thanks! [15:29] <smarter> I'm not sure if I would recommend --aq-mode=1 [15:29] <nevcairiel> not re-doing the vp9 encodes now! [15:29] <ubitux> :D [15:30] <ubitux> i blindly listened to BBB :) [15:30] <ubitux> btw, ssim script: http://lucy.pkh.me/encodes/ssim.sh [15:30] <smarter> it probably does not have a big impact, though it'd be interesting to do one encode without it at least [15:30] <ubitux> (based on BBB script) [15:31] <smarter> you should put all that stuff on a git repo somewhere for reproducibility :) [15:32] <ubitux> i actually don't want to share the samples for a long time :p [15:33] <smarter> for bandwidth reasons? [15:33] <ubitux> legal [15:33] <nevcairiel> he is afraid because his sample is a movie clip [15:33] <nevcairiel> while BBB used sintel and i used ToS [15:34] <smarter> oh yeah, not a great idea :p [15:34] <ubitux> it's a relatively long, HD, and from recent source [15:34] <ubitux> so... welll :) [15:34] <nevcairiel> 3 minutes should be well into fair use, but shrug [15:34] <smarter> I haven't looked very much but I suspect there's some creative commons stuff that could be used for that [15:35] <ubitux> of course [15:35] <ubitux> but i like that sample :D [15:35] <nevcairiel> which movie is that anyway [15:36] <ubitux> http://www.imdb.com/title/tt1191111/ [15:38] <ubitux> smarter: is splitview supposed to work with firefox? [15:39] <smarter> ubitux: you need firefox >= 28 [15:39] <smarter> the beta [15:39] <smarter> for VP9 support [15:39] <smarter> also H.264 support in your OS [15:39] <ubitux> obviously... ok [15:40] <smarter> I'll try to make it usable on browsers without VP9 or H.264 soon [15:40] <ubitux> by integrating a jsffmpeg? [15:40] <smarter> (so that you can use it with your own URLs/files at least) [15:40] <smarter> hah no :p [15:40] <ubitux> :( [15:40] <smarter> just display something by default instead of exploding [15:40] <ubitux> did mozilla nih a vp9 decoder btw? [15:41] <smarter> they use libvpx [15:41] <ubitux> ok [15:41] <smarter> 1.3.0 [15:41] <mateo`> smarter: through gst ? [15:42] <smarter> I think so [15:42] <smarter> I think rillian on #vp8 did the integration [15:53] <ubitux> > Also, recent versions of ffmpeg (we use 2.0) come with a segmenter tool, but we found it introduces significant latency to our pipeline. [15:53] <ubitux> :( [15:53] <ubitux> and they didn't use -movflags +faststart :( [15:53] Action: ubitux is sad [15:53] <ubitux> (https://tech.dropbox.com/2014/02/video-processing-at-dropbox/) [15:54] <nevcairiel> never used segmenter with mov [15:56] <ubitux> BBB: ssim results available [15:56] <ubitux> (http://lucy.pkh.me/encodes/) [15:56] <nevcairiel> lacks a summary file! [15:56] <nevcairiel> (http://files.1f0.de/encodes/ssim.summary) [15:57] <ubitux> heh [16:03] <ubitux> nevcairiel: for f in *.ssim; do printf "%-18s %s\\n" $(echo $f|sed 's/\..*//'): "$(tail -n1 $f)"; done > ssim-summary.txt [16:03] <ubitux> here you go. [16:03] <ubitux> http://lucy.pkh.me/encodes/ssim-summary.txt [16:03] <nevcairiel> \o/ [16:03] <nevcairiel> vp9 did a rather good job at this grainy video [16:04] <nevcairiel> it took ages, but still [16:04] <ubitux> well, it could given the time it had [16:08] <ubitux> btw [16:09] <ubitux> should we make hevc encodes? [16:09] <ubitux> because i'm pretty sure the single first comment will be about that [16:10] <ubitux> that would be a good opportunity to make a slowpoke race between libx265 and libvpx [16:10] <nevcairiel> heh [16:10] <nevcairiel> i was th inking about that [16:11] <ubitux> though our hevc decoder is not optimized yet, so it won't be relevant for the main thing we're trying to show; aka decoder speed [16:11] <smarter> it'be a good way to benchmark it :) [16:11] <nevcairiel> it lacks a 2-pass mode though, and 1-pass cbr is kinda unfair crap mode [16:12] <smarter> still no 2 pass? [16:15] <nevcairiel> no [16:15] <cone-632> ffmpeg.git 03Diego Biurrun 07master:b23bc95920e2: x86: dca: Add missing multiple inclusion guards [16:15] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:130c33af35c5: Merge commit 'b23bc95920e2f10b9621857e829c45b064f356c0' [16:16] <nevcairiel> constant qp, average bitrate or crf so far [16:52] <plepere> ubitux, I'm working on the HEVC ASM right now. we did quite a bit of changes so I had to start from scratch [16:53] <plepere> but hopefully I'll be able to do a diff at the end of the month and be able to submit the code for review [16:53] <smarter> yay [17:03] <cone-632> ffmpeg.git 03Vittorio Giovara 07master:35b05c5184fb: vf_interlace: deprecate lowpass option [17:03] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:b14517d3cd37: Merge remote-tracking branch 'qatar/master' [17:29] <cone-632> ffmpeg.git 03Carl Eugen Hoyos 07master:9c070ae03e15: Fix dctdnoiz dependencies, the filter should select dct, not fft. [17:29] <cone-632> ffmpeg.git 03Carl Eugen Hoyos 07release/2.1:ac38860ec959: Add decoder dependency to the HEVC parser. [18:53] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:2969fb43939e: avformat/utils: av_guess_frame_rate() favor avg_frame_rate if r_frame_rate has a comparably unlikely value [18:53] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:3734c3ea51ae: ffmpeg: reduce frame rate for mpeg4 to be within the spec limits [19:39] <j-b> BBB: is chrome using ffvp9 or libvpx for vp9 decoding? [19:56] <cone-632> ffmpeg.git 03Carl Eugen Hoyos 07master:a88dee8eea19: Add decklink_enc.h to SKIPHEADERS. [20:28] <llogan> JEEB: see anything retarded in EncodingForStreamingSites? i see you've been helping out users in that area lately. [21:53] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:4332b01c30a4: avcodec/huffyuv: simplify allocation of temporaries [21:58] <cone-632> ffmpeg.git 03Diego Biurrun 07master:874c751cc5b9: threads: Check w32threads dependencies at the configure stage [21:58] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:0a30ad347357: Merge commit '874c751cc5b99cd68932e21c2c3a0d21134207e0' [22:07] <cone-632> ffmpeg.git 03Luca Barbato 07master:a7b3216cbdc7: doc: Sort the muxer documentation [22:07] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:ca5b45b9b3cb: Merge commit 'a7b3216cbdc7796a9d14cd22a863fae3556098ba' [22:09] <cone-632> ffmpeg.git 03Luca Barbato 07master:93632a70f9ac: doc: Name the MOV muxer as it should be called [22:10] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:4ba03e37fd16: Merge commit '93632a70f9ac2cb2ebf0e69d21fdfaae68ff02fd' [22:52] <BtbN> How do i tell the configure script to link libavcodec against libdl if my encoder is enabled? [22:52] <BtbN> i tried nvenc_encoder_extralibs="$ldl" but it doesn't work [22:53] <BtbN> oh, of course. Because the ldl variable is generated AFTER the encoder lines [22:53] <BtbN> or is that variable evaluated later on? [23:01] <cone-632> ffmpeg.git 03Luca Barbato 07master:521726ff577c: hevc: Always consider VLC NALU type mismatch fatal [23:01] <cone-632> ffmpeg.git 03Michael Niedermayer 07master:ca9f7e183278: Merge remote-tracking branch 'qatar/master' [00:00] --- Thu Feb 20 2014

1 0

ffmpeg.log.20140219
by burek 20 Feb '14

20 Feb '14

[00:00] <active8> i looked in that page for the setpts filter and didn't see anything. [00:00] <llogan> http://ffmpeg.org/ffmpeg-filters.html#setpts_002c-asetpts [00:05] <active8> damn. I fell asleep right after looking. I guess I wasn't worth a damn at the time [00:06] <llogan> i've only used atempo. i don't know if asetpts can do it and i haven't tried. [00:08] <llogan> active8: if you want more control see http://slowmovideo.granjow.net/ [00:11] <active8> they don't thanks. that might make things easier for the kind of effects I might want for public consumption [00:11] <active8> s/they don't// [00:12] <active8> i was going to say they don't, or rather they made it hard to find the option to invoke the audio filter and not clear if there are different options to invoke different filters [00:13] <active8> still scrolling to find it [00:15] <llogan> -filter_complex "[0:v]setpts=2.0*PTS[v];[0:a]atempo=0.5[a]" -map "[v]" -map "[a]" [00:15] <llogan> for example [00:34] <`Ishq> Is there a list of beginner projects that would be useful to contribute to ffmpeg? [00:43] <llogan> `Ishq: you can take a look at bug tracker and choose what interests you. https://trac.ffmpeg.org/ [00:44] <`Ishq> Thanks. [00:44] <llogan> or if you're a student and we get accepted to GSoC https://trac.ffmpeg.org/wiki/FFmpegSummerOfCode2014 [00:45] <`Ishq> Well, I won't be a student anymore. [00:45] <`Ishq> At least this summer. [00:45] <llogan> there is also http://wiki.multimedia.cx/index.php?title=Small_FFmpeg_Tasks but i don't know how up to date it is [00:47] <llogan> `Ishq: you count as a student if you're still enrolled and actively pursuing the degree. i don't think you have to be taking classes in the summer, but i could be wrong. [00:48] <JEEB> GSoC has a single date [00:48] <JEEB> Will you be a student on 21 April 2014? [00:48] <JEEB> http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc20… [00:48] <JEEB> That's really the only date that maters. :-) [00:48] <`Ishq> Yeah, I will be a student then. [00:48] <JEEB> (quote from the GSoC mailing list) [00:48] <`Ishq> I graduate in May. [00:49] <JEEB> anyways, I recommend poking around spots you are interested in [00:49] <llogan> As long as you are accepted into or enrolled in a college or university program as of 21 April, 2014, you are eligible to participate in the program. Students will be asked by Google to provide proof of enrollment during registration. [00:49] <llogan> but of course we may not get accepts, but you can still do any of the listed projects for fun [00:49] <llogan> *accepted [00:49] <`Ishq> Well, I don't realy need the money or anything. I just want to pick up a task. [00:50] <JEEB> :) [00:50] <`Ishq> I already have a job :) [00:50] <JEEB> well, personally I'd recommend something you like [00:50] <JEEB> or something that irks you [00:50] <`Ishq> Well, the main thing that kinda irks me [00:50] <`Ishq> Is the SBR extension warnings [00:50] <JEEB> "X doesn't work, let's see if I can make it better" is how many people get into development [00:50] <`Ishq> But [00:51] <`Ishq> I'm not sure if I can deal with that, but would be interesting to research. [00:51] <JEEB> sounds like AAC? [00:51] <`Ishq> Maybe. [00:51] <`Ishq> I could look into it. The unfinished SoC projects seems like a good place to start. [00:52] <JEEB> well, if you decide to poke at AAC, I recommend seeing if you can contact the AAC guy, who happens to mostly hang around #libav-devel AFAIK (after the forking some people are on one "side", while others are on the "other" and then the third group are in both) [00:53] <JEEB> lemme see if I can grab his IRC nickname... [00:53] <`Ishq> Sounds like politics. fun. [00:53] <llogan> do you mean Claudio/klauss? (im not sure of his nick). [00:54] <JEEB> Alex Converse, IRC nick peloverde [00:54] <`Ishq> Not connected to IRC. [00:54] <JEEB> you can see him adding new features every now and then, like LD-AAC as of late [00:54] <JEEB> oh he is, if you join #libav-devel you can see his ____ nick [00:54] <llogan> also contact klaussfreire @ gmail. he's the mentor for the "implement AAC SBR (spectral band replication)" GSoC task. [00:54] <`Ishq> Ahh [00:55] <JEEB> oh, there was an AAC guy on the FFmpeg side as well? Don't see him in the aacdec.c history :s [00:55] <llogan> https://trac.ffmpeg.org/wiki/FFmpegSummerOfCode2014#AACEncoderImprovements [00:56] <JEEB> oh, encoder? [00:56] <llogan> also the "epic trac thread" [00:56] <JEEB> yeah, encoder is mostly being poked on the FFmpeg's issue tracker [00:56] Action: llogan wasn't sure if discussion was en/decoder [00:56] <JEEB> neither was I :D [00:56] <JEEB> encoders generally don't say they don't support something, though [00:57] <llogan> https://trac.ffmpeg.org/ticket/2686 [00:57] <JEEB> yeah, the encoder doesn't seem to warn [00:57] <llogan> just throwing out ideas.... [00:57] <JEEB> and yeah, I know the epic encoder thread [00:57] <JEEB> but yeah, I promote cross-project communication for people who seem to be In The Know of various parts of the code [00:58] <`Ishq> All right, I'll do some more research on SBR and see if it is a good task for me. [00:58] <JEEB> you should poke the -devel channels if you happen to end up needing specifications and such [00:58] <JEEB> usually ISO/IEC number + .pdf queries end up with nice results tho [00:59] <`Ishq> Ah, thanks. [00:59] <JEEB> #ffmpeg-devel and #libav-devel are the dev channels for both projects [00:59] <llogan> devel worship [00:59] <`Ishq> Cool. [01:03] <`Ishq> Link is dead to the SBR spec on Wikipedia, sadly. [01:04] <JEEBsv> that's pretty usual :P it's a paid-for spec after all [01:06] <`Ishq> So I have to be creative in how obtain it. [01:07] <`Ishq> Luckily, I'm at a university so they generally pay for these types of things. [01:07] <JEEBsv> oh I wish mine did :P [01:08] <JEEBsv> you have no idea how "fun" going around chinese internets for obscure PDFs can be at times [01:08] <`Ishq> Haha [01:16] <`Ishq> http://jongyeob.com/moniwiki/pds/upload/13818-7.pdf [01:16] <`Ishq> Found it. [01:17] <JEEBsv> that's the MPEG-2 version, the third edition of the MPEG-4 spec should be relatively simple to find [01:17] <`Ishq> nooo [01:18] <JEEBsv> fourth ed of the MPEG-4 one I can't find too easily though [01:18] <JEEBsv> http://www.nhzjj.com/asp/admin/editor/newsfile/2010318163752818.pdf [01:19] <JEEBsv> the 3rd ed of the MPEG-4 one [01:19] <`Ishq> Thanks. [01:27] <`Ishq> This seems to have the basic SBR spec and how to detect. [03:19] <Rain724> Hello everyone! Anyone have time for a quick question? [03:20] <relaxed> Rain724: never ask to ask [03:20] <Rain724> Lol, alright then. [03:21] <Rain724> I'm trying to split some video files (.avi, FWIW) with multiple audio tracks. -acodec copy only copys the first track. Anyway around this? [03:22] <relaxed> you want all the tracks? [03:22] <Rain724> I can provide all of the arguments I'm using if it helps. [03:22] <Rain724> Yes [03:22] <relaxed> ffmpeg -i input -map 0 -c copy ... [03:23] <Rain724> Hmm. Let me give that a shot! [03:24] <relaxed> -map 0 includes all streams from the first input file [03:25] <Rain724> Yea, just read that on the documentation page as I'm letting ffmpeg run. ;D [03:25] <relaxed> -c copy copies all those streams. If you only want to copy all the audio use -c:a copy [03:26] <Rain724> Yep! That worked great! Thanks, I really appreciate it! [03:26] <relaxed> you're welcome [03:44] <active8> llogan: that all worked out reasonably well. Thanks for the pointers. BTW. That old ffmpeg is the one that gets installed with this special script to install vlc media player. I forget the lib, but the centos repositories in stall ffmpeg and vlc with a mismatched lib version on I forget which lib, so the script kinda shoehors the right stuff together by temorarily setting an alternate repo. friggin kludge. So I built my own the way I wanted it. [06:45] <jellosea> i get this error can someone help me? [h264 @ 0x804104600] cabac decode of qscale diff failed at 1 14 [06:45] <jellosea> followed by a shit ton of errors like these [h264 @ 0x804105f00] concealing 2358 DC, 2358 AC, 2358 MV errors in B frame [06:45] <jellosea> [h264 @ 0x804104600] Reference 2 >= 2 [06:51] <jellosea> meow [06:56] <anshul> guys I was adding av_cleanup_on_lib_unload() in ffmpeg, which file would we most suitable for this purpose [06:57] <jellosea> hey relaxed [07:36] <arjay> Hi. having trouble setting up ffmpeg for Mac and Xcode 5 [08:13] <lo_o|> hi [08:14] <lo_o|> any1 hear? [08:14] <lo_o|> need to discuss mp4 to webm [08:27] <zap0> just do it [08:28] <lo_o|> o hay [08:28] <lo_o|> u there [08:28] <lo_o|> im using super simple no arguments convert [08:29] <lo_o|> do you know how to squeeze max quality from src file [08:29] <zap0> quality is subjective. [08:29] <relaxed> lo_o|: ffmpeg -h encoder=libvpx [08:30] <relaxed> lo_o|: https://trac.ffmpeg.org/wiki/vpxEncodingGuide [08:30] <lo_o|> wat hapens wen no arguments [08:30] <lo_o|> doesnt ffmpeg default best? [08:31] <zap0> best is subjective. [08:31] <lo_o|> well teh original [08:31] <JEEB> <lo_o|> doesnt ffmpeg default best? <- never has never will [08:31] <lo_o|> how else is it [08:31] <lo_o|> JEEB ya my video is super wack [08:31] <JEEB> you clearly missed on the "everything on MPEG-1 feature level, 300kbps" defaults [08:31] <relaxed> it used to default to worst :) [08:32] <lo_o|> oh [08:32] <lo_o|> arite [08:32] <lo_o|> ya worst is baaaaad [08:32] <JEEB> of course that isn't true with the newer wrappers [08:32] <JEEB> that got their own defaults now [08:32] <JEEB> but FFmpeg will never default to what is --preset placebo for libx264 :P [08:33] <JEEB> also, good luck and have fun with libvpx. For VP8 it's both slower and worse than x264 [08:33] <lo_o|> rly [08:33] <zap0> i'm still waiting for the --make-mpeg1-porn-clips-from-the-90s-watchable flag. when is that going to be implmeneted? [08:33] <JEEB> yarly [08:33] <lo_o|> webm is kinda new [08:33] <lo_o|> y i like it [08:33] <lo_o|> mp4 is beter? [08:34] <zap0> beter is subjective. [08:34] <JEEB> AVC/H.264 is better than VP8, yes [08:34] <JEEB> no, as a FORMAT it is better [08:34] <JEEB> there's no doubt about that :P [08:34] <JEEB> also the implementations are much better (*cough* libx264 *cough* ) [08:34] <lo_o|> ya but one browser doesnt suport mp4 [08:35] <JEEB> VP8 is "new" (released around 2010 or so by Google into the public), but it's basically a stripped AVC/H.264 [08:35] <JEEB> anyways, don't expect anything from the video side of "WebM" with VP8 [08:35] <JEEB> Vorbis at least is good, esp. with aotuv [08:35] <lo_o|> oh ic [08:35] <rjp421> im trying to stream to ustream on win7 x64, using dshow input with webcammax as the source... works fine on linux with v4l or x11grab... but its being very picky on windows with dshow [08:35] <lo_o|> well im encoding flv mp4 webm [08:36] <lo_o|> i made a dedicated ffmpeg box too [08:37] <rjp421> im using the latest build, ffmpeg-20140219-git-b9936e5-win64-static [08:50] <Xorg> good morning everyone [08:55] <zap0> expecting 219 replies? [08:59] <Xorg> just one or two would ne nice yeah [09:00] <Xorg> just to see if someones there who i can annoy [09:00] <anshul> zap0 is there some kind of feature request u have placed in ffmpeg trac,if done so ,then please give the ticket number too [09:00] <zap0> anshul, wha!? [09:01] <anshul> zap0,--make-mpeg1-porn-clips-from-the-90s-watchable flag is there any feature request registered in trac [09:03] <Xorg> maybe someone there wo might help me with a file? [09:04] <zap0> anshul, oh ;) [09:05] <zap0> given how long some things take to get fixed, someone probably already has a ticket, and mine will be marked -duplicate- [09:07] <rjp421> what would be good preset settings for a 24fps 360p x264 stream at 650kbit/s max? unless i could fit a higher res in that bitrate [09:07] <rjp421> 480p possibly, but 720p might be pushing it [09:09] <zap0> why use a preset, when you already know your limits you want to set [09:09] <rjp421> i made a copy of the libx264-ipod320 preset, but the bitrate is set to 3000000 (3mbit/s) [09:09] <JEEB> <zap0> why use a preset, when you already know your limits you want to set <- because presets set the compression vs speed defaults? [09:10] <JEEB> rjp421, what kind of content you have there defines what kind of resolution you can take [09:10] <JEEB> and the idea is to use the slowest preset that is still fast enough for your uses :P [09:11] <JEEB> http://mewiki.project357.com/wiki/X264_Settings#preset [09:11] <JEEB> listing of them [09:11] <JEEB> (-preset in ffmpeg cli) [09:11] <rjp421> cool, thanks ill read up [09:11] <JEEB> is this for web or otherwise bandwidth limited scenarios btw? [09:11] <JEEB> and what in general are aiming at? [09:12] <rjp421> basically talking head video, nothing like fast motion video [09:12] <JEEB> then everything but the most fastest presets should be able to compress that rather nicely [09:13] <JEEB> and please tell more about the usage scenario so I can comment more on if you're doing things completely wrong or not :P [09:18] <rjp421> awesome, thanks again :) im reading that link... im just streaming to ustream, which likes a -g of 4, and only allows 360p at 650kbit/s max [09:19] <JEEB> ok, so you are bandwidth limited [09:19] <rjp421> (for non-pro) [09:19] <rjp421> yes [09:19] <JEEB> first of all drop that ipod preset :P [09:19] <JEEB> https://trac.ffmpeg.org/wiki/EncodingForStreamingSites [09:20] <JEEB> also -g definitely can be higher than 4 [09:20] <JEEB> I recommend setting a CRF value that generally looks good for you (default is 23 and higher uses less rate and lower uses more rate), set maxrate and bufsize accordingly to your streaming site's limitations [09:20] <rjp421> i believe its for the transcoding to HLS [09:21] <JEEB> no, it is not [09:21] <JEEB> it's from way before that [09:22] <JEEB> you need 1) vf scale to resize to your preferred size 2) CRF value that generally looks good for you (as I just wrote) 3) maxrate and bufsize according to your bandwidth limitations 4) slowest -preset that is still fast enough for you [09:22] <JEEB> and that page I linked has some examples, except of course that the stuff before -i and -i itself are lunix-specific [09:22] <JEEB> otherwise it's generic and for RTMP(E) streaming providers [09:23] <JEEB> if your buffer size is set in seconds instead of kbits or mbits, calculate it by maxrate * seconds of buffer [09:24] <JEEB> for example maxrate 650k and two seconds of buffer would be 1300k [09:24] <JEEB> CRF is a VBR rate control mode that is closest to "constant quality" we have right now :P [09:24] <JEEB> so no other bit rates or anything needed [09:24] <JEEB> just limit it with VBV (maxrate and bufsize) [09:26] <rjp421> nice, thanks! that definitely helps, also just looking at some of the examples [09:30] <anshul> zap0, to look in detail I just need that Ticket number, I am too lazy to search in track ;) [10:13] <rjp421> JEEB, do i need the -crf 23 anywhere in particular in the cmd line? i dont see it in the examples with maxrate and bufsize... my current upload is 100KB/s, but im working on this for someone with a much higher upload. i set maxrate 554k and bufsize 1108k, since the audio would be 48k stereo aac.. but should that be -ar 22050 or 44100? i think only 22050 has worked for me on linux [10:14] <JEEB> both should be OK, and if the input is something you want you could just use that, too. The rate limitations of FLV don't apply to AAC (the spec says "write 44.1kHz here, and we'll ignore it and go onto just parsing the AAC stream itself") [10:14] <JEEB> -crf goes after -i [10:14] <JEEB> as in, output settings [10:14] <JEEB> everything before -i is input [10:14] <JEEB> everything after -i is output [10:14] <rjp421> ahh, ok [10:14] <JEEB> (and decoding, encoding accordingly) [10:17] <JEEB> also it probably isn't there because crf 23 is the default rate control mode for libx264 nowadays (same as with the x264 command line app). But yeah, you need to set some rate control mode, and you might have to tweak it to your liking :) [10:18] <JEEB> maxrate/bufsize will limit the bandwidth accordingly to how you've set it [10:21] <rjp421> the current input (-f dshow -i video="WebcamMax Capture" @ 30fps) is giving me a lot of real-time buffer full, frame dropped warnings... but it hasnt stopped it from working.. i saw a page that mentioned the rtbuffer, still looking for it [10:22] <rjp421> with the fixed max bitrate, i should leave -maxrate 554k, and play with buffersize and crf? [10:22] <rjp421> bufsize* [10:22] <JEEB> ? [10:25] <rjp421> that encoding for streaming page says to experiment with maxrate and bufsize [10:26] <JEEB> in case the values don't work for whatever reason :P you should know your outgoing bandwidth and you should know the limitations of the streaming service you're using, and then you might or might not need to adjust things to cope with stuff like container overhead (usually very small) [14:09] <Vuk> Hello [14:11] <Vuk> Need help with streaming h264 [14:16] <Vuk> I have #0:0[0x144]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv), 720x576 [SAR 64:45 DAR 16:9], max. 15000 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc [14:17] <Vuk> And I want to stream it to a ffserver as mp4 with 720x576 res [14:17] <Vuk> Can anybodey help ? or give some hint :) [14:31] <Vuk> damn [14:43] <renihs> hello, my intention is to run a screencapture _with_ pcm audio, so essentially everything that is displayed on screen and _output_ on audio, so far i had only sucess recording from input devices like a mic [14:45] <renihs> due to lack of a more sophisticated approach, i simply tried all audio devices, but nothing got recorded [14:46] <renihs> ffmpeg -f alsa -ac 2 -i hw:0,0 -f x11grab -r 30 -s 1920x1200 -i :0.0 -acodec pcm_s16le -vcodec libx264 -preset ultrafast -crf 0 -threads 0 bla.mkv [14:47] <renihs> is my general approach currently :) [14:49] <renihs> it seems like i can only capture from _input_ devices, but not from output devices? [14:50] <renihs> or recording devices i mean [15:19] <renihs> anyone? or is it not possible with alsa to capture audio OUTPUT? [15:19] <renihs> or am i facing some bug that i get no ouput captured on any hw:x,x device? [15:19] <renihs> is that supposed to work? [15:44] <dericed_> hi all, does ffmpeg support field dominance flags in matroska. `ffmpeg -f lavfi -i mandelbrot -c:v ffv1 -vf "fieldorder=bff" -t 1 test.mkv` gives a progressive output. [16:42] <Keestu> hi, when i dump the av_dump_format (), it shows frame type is yuv420P, whereas when i try in the coding, after getting codec context, when i check enum, i get AV_PIX_FMT_UYVY422 . [16:43] <Keestu> i am checking with if (pCodecCtx->pix_fmt & AV_PIX_FMT_UYVY422 ) LOGD (" Haaa it is AV_PIX_FMT_UYVY422 format "); [16:48] <troulouliou_dev> hi anybody here to discuss a little bit about dts audio format ? [17:14] <tbindi> Hi. Can I use FFMPEG to create a timelapse video out of 300 odd images? [17:14] <sacarasc> https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images [17:17] <tbindi> does the sequence number begin from 1? because I get a "Deprecated" message when I try "start_number" [17:18] <sacarasc> That deprecated message probably means you're not using FFmpeg's encoder, but LibAV's one. [17:19] <JEEB> in that case the avconv binary should be used instead, different project :) [17:20] <Na_Klar> how do I write the "-ac" parameter, in order to add a stream identifier, like: "-c:a:0" (what does not work because this "c" is for "codec" not for "channel")? [17:21] <tbindi> I am using libx264 in the command. Should I install x264 encoder? [17:21] <JEEB> you should install libavcodec-extra [17:21] <JEEB> that enables stuff like libx264 [17:22] <JEEB> in the debian/ubuntu Libav packages [17:22] <Na_Klar> libavcodec-extra-53 to be specific ;) [17:22] <JEEB> well, the version depends on the thingamajig, and I think the versionless package is always set to the current versioned one, no? [17:23] <JEEB> Na_Klar, -ac:a:0 or so? Or just -ac:0 (which of course counts all tracks) [17:23] <Na_Klar> it will upgrade to the highest version anyways .. but you need at least 53 for x264 [17:24] <Na_Klar> JEEB, -ac:a doesn't make sence, cause it would mean: -audioChannels:Audio:Stream .. but i'll try [17:24] <Na_Klar> (since there is no -audioChannels:Video:Stream ...) [17:25] <JEEB> well, if you don't prefix the type first you'll get the global stream count :P [17:25] <JEEB> but I have no idea if that works, that's just how it theoretically blobbed up in my mind :P [17:27] <Na_Klar> isn't there a table anywhere with that different parameter syntax in it? [17:31] <tbindi> unrecognized option 'start_number' [17:31] <Na_Klar> ah, got it: it's just "-ac:0" .. nvm [17:32] <tbindi> when I try : `ffmpeg -r 1 -start_number 567 -i IMG_0%3d.JPG -c:v libx264 -r 24 -pix_fmt yuv420p out.mp4` [17:33] <JEEB> yeah, because it's Libav's ffmpeg that was left to wither after elenril updated it (and renamed it to avconv) [17:33] <JEEB> so with Libav, use avconv [17:33] <JEEB> with FFmpeg use ffmpeg [17:34] <Na_Klar> tbindi: try to add "-f image2" before [17:35] <tbindi> Na_Klar: same error again [17:36] <tbindi> I am on 12.04 Ubuntu [17:36] <JEEB> do what I just said :P [17:36] <JEEB> or are you no comprende? [17:36] <Na_Klar> yeah ubuntu 12.04 has some issues with ffmpeg and avconv ... [17:37] <JEEB> it's got (by now) an old libav, that's all. thus it still has the ffmpeg binary which is even older (because it was left to wither from 0.8 until 9 was released) [17:37] <JEEB> <JEEB> so with Libav, use avconv [17:37] <JEEB> <JEEB> with FFmpeg use ffmpeg [17:38] <active8> Good morning | afternoon | evening; trying to get a screen capture with sound. Maybe I accidentally used the old ffmpeg but I actually had sound at one time and after searching bash history and trying all of them, nada. I get a weird error and I thing (google thinks) it's got to do with the tagging or mapping. Something like that. You can explain the prob better. http://pastebin.com/uqQdHkSd [17:38] <tbindi> so I should install Libav? [17:38] <JEEB> you already have libav... [17:38] <tbindi> okay [17:38] <JEEB> that ffmpeg binary comes from Libav [17:38] <Na_Klar> and there are (was) lots trouble with presets ffpreset and avpreset stuff .. [17:38] <JEEB> so you also have avconv [17:38] <tbindi> so I should use avconv? [17:39] <JEEB> that totally isn't what I've been telling you the last X minutes </sarcasm> [17:39] <active8> was that X11 minutes? [17:41] <tbindi> so what should I be doing? can you please elaborate on " with Libav, use avconv. with FFmpeg use ffmpeg" [17:41] <JEEB> it's not harder than that? [17:41] <JEEB> the binary you use when using Libav is avconv, the binary you use when you use FFmpeg is ffmpeg [17:43] <JEEB> tbindi, don't fucking pm me for no reason, please :| [17:43] <JEEB> there's no reason why what you just said shouldn't be on #libav or here [17:43] <tbindi> okay [17:43] <JEEB> seriously, switch your command line from using ffmpeg to avconv in case of Libav-based packages [17:43] <JEEB> that's all [17:43] <JEEB> there's no catch 22 to it [17:43] <JEEB> :V [17:44] <ubitux> tbindi ^ [17:52] <tbindi> thanks fflogger [17:52] <tbindi> thanks JEEB [17:56] <spaam> JEEB: :D [17:56] <Na_Klar> active8: did you read in the error message, that flv does not support 48khz .. maybe this is why the output header could not be written .. [17:56] <JEEB> actually, it does for AAC [17:57] <Na_Klar> its mp3 [17:57] <JEEB> ok, yes [17:57] <JEEB> that one is limited [17:57] <JEEB> AAC is just "write the 44.1kHz value into the container, we'll ignore it and just parse the stuff from the stream" [17:57] <Na_Klar> hacky [17:57] <JEEB> well, that's how it's specified so you can't really do much about that :V [17:58] <JEEB> some kind of default value I guess @ 44.1kHz [17:58] <JEEB> of course you still have people re-encoding 48kHz stuff to 44.1kHz when doing FLV streaming [17:58] <JEEB> because they never changed their workflows [17:58] <Na_Klar> flv sucks anyways .. [17:59] <JEEB> well, for some use cases it's the only container usable :P [17:59] <Na_Klar> yeah, for flv videos [17:59] <JEEB> RTMP(E) streaming [17:59] <Na_Klar> oO [17:59] <Na_Klar> that's adobe shit too [17:59] <JEEB> which doesn't have to be live streaming, it can be VOD too [17:59] <JEEB> yes, yes it is [18:00] <JEEB> but it's the only "real" streaming thingamajig we have on the internets in wide use atm [18:00] <JEEB> HLS is the only thing coming close [18:00] <JEEB> which is even more of a hack to be honest [18:00] <Na_Klar> define "real streaming" [18:01] <JEEB> actually a usable protocol to do live or VOD streaming [18:01] <JEEB> which also has a nice support ratio [18:02] <Na_Klar> i don't bash the rtmp protocol. But there are plenty of transport streams. most of them useable. [18:02] <JEEB> uhh [18:03] <JEEB> I noted HLS, and that is already a pretty lulzy system [18:03] <JEEB> what else do we have, that is actually kind of widely supported? [18:03] <active8> Na_Klar: I thought about that but google didn't suggest it. Which of the 100 tabs that I have open has the page that tells me how to set the rate? ;) [18:03] <JEEB> -ar [18:03] <troulouliou_dev> hi does ffmpeg use the track channel info for audio streams in mkvs to init avformat ? [18:03] <active8> note to self: man ffmpeg [18:04] <active8> 1st [18:04] <ChocolateArmpits> Hello, Is it possible to successfully pipe a filter output from a 1st pass encode command line to a 2nd pass encode command line ? [18:05] <JEEB> Na_Klar, to be honest, I've done "just push MPEG-TS through HTTP" live just fine, but now start counting with your fingers how many things on the web actually _support_ that without specific player software (as in, separate apps) [18:05] <Na_Klar> you don't "pipe a filter" .. you pipe data through a filter [18:05] <Na_Klar> ^ ChocolateArmpits [18:05] <Na_Klar> JEEB, MTS through HTTP .. i like that one [18:05] <Na_Klar> but indeed .. [18:06] <JEEB> HLS is the closest to that, but it's a lulzy mess as I said :P [18:06] <JEEB> the generated playlists, the multiple files... [18:06] <Na_Klar> MTS though UDP based protocol .. even better ^^ [18:07] <ChocolateArmpits> Na_Klar: Well what I mean is, I want to split a stream through filter, map one end of it to a 1st pass encode, while second would mapped and piped to an input of another command line that would perform a 2nd pass encode [18:07] <Na_Klar> JEEB, there are some good plans with html5 and transport streams .. [18:08] <Na_Klar> ChocolateArmpits: you can easily run several instances of ffmpeg (even fork it) and let a imageserver spit out and catch the data. [18:09] <ChocolateArmpits> Na_Klar: Are you talking about ffserver? I haven't used that yet [18:10] <ChocolateArmpits> What I want to do is to skip filtering input for two encode proceses to save time [18:10] <Na_Klar> ChocolateArmpits: you can use this, but it might be overkill for your task. are you familiar with your OS process structure? [18:11] <ChocolateArmpits> Na_Klar: Figuring that I don't figure what you mean, I may well not be familiar [18:12] <Na_Klar> ChocolateArmpits: Basically you can run a ffmpeg process wich filters and do first pass, than pipe it to another ffmpeg process wich takes the data and does 2nd pass and writes to disk. BUT: your wished time save might be dissapointing .. [18:13] <Na_Klar> I doubt you would use a filter using 2passes anyways ... [18:14] <Na_Klar> And even if, how could you then drop the 2nd pass? [18:14] <Na_Klar> your plan is not well thought, I'd say .. [18:15] <active8> Na_Klar, JEEB: I'm only using flv to get this working from supposedly working examples. I'd only use it for real if I have to. I tried mp4 without specifying a codec, formay, whatever I should do and it gave me a blank, grey picture. I'm not sure if I'm supposed to set a sample rate in ffmpeg, or if the error means "screw mike, his sound card is too good for flv even with ffmpeg." and I'm still scrolling through the man page to find something to set the samp [18:15] <active8> le rate so I can come back here when it doesn't work. [18:16] <Na_Klar> active8: you should start reading better .. JEEB already gave you "-ar" [18:17] <Na_Klar> -ar 44100 [18:17] <Na_Klar> you can use flv, btw. no problem with that. we are just nerding around [18:18] <active8> ok thanks. I'm also scrolling through xchat reading what you guys were saying and missed it [18:19] <active8> heey. I agree that flv sux to a degree. It's small but there's been talk about it going the way of the dinosaur. If nothing else, adobe flash player is a POS that leaks memory and firefox is a bigger POS that can't contain it with it's container plugin. worse still: [18:21] <active8> I have a dell 600m with a radeo mobility one day later we pout something better in here and certain sites that embed videos not only eat the memory, but even after shutting down firefox, it's FUBAR. I have to actually power off and pull the battery as if the GPU has a stuck flag bit or word [18:22] <Na_Klar> the plug-in is not really related to the flv codec. the codec is kind of solid. not very effective, but solid. [18:55] <smo_> hi [18:56] <active8> i'm just saying that adobe and mozilla can't dance and that radeon mobility is eh. Never said anything about the codec. I got -ar 41000 and -ar:1 41000 to do the trick Na_Klar and JEEB. Thanks. I'll be back after lunch to pester you all when I try this grabbing the sound from a playing video. Actually, that looks like it will work so I'll find something else ;) Thanks [18:57] <smo_> i use ffmpeg to make live transcoding thru html video for the client side it works right on desktop/my app/some android phones but won t play in damn iphone can anyone help me to understand why ? command line is [18:57] <smo_> ffmpeg -i rtsp://mafreebox.freebox.fr/fbxtv_pub/stream?namespace=1&service=201&flavour=ld -f matroska -movflags +faststart -sn -c:v h264 -preset fast -profile:v high -b:v 256k -c:a libvo_aacenc -s 480x320 -b:a 96k -threads 0 - [18:58] <smo_> it fails with Error while decoding stream #0:3: Invalid data found when processing input [18:58] <smo_> or many channel element x.x is not allocated [18:58] <smo_> same coman,d line works always in another device Oo no invalid data [18:59] <Na_Klar> please do not paste into channel. use e.g. pastebin and post the whole input/output. [19:02] <renihs_> hmm ok, i am still trying to capture audio AND video, it seems however that i can only capture audio ...on low video resolutions, e.g the following does _not_work: [19:03] <renihs_> ffmpeg -f alsa -ac 2 -i hw:0,0 -f x11grab -r 30 -s 1680x1050 -i :0.0 -acodec pcm_s16le -vcodec libx264 -preset ultrafast -crf 0 -threads 0 bla.mkv [19:03] <renihs_> while if i capture with 1280x1024 audio gets captured [19:03] <renihs_> this is starting to become confusing :( [19:03] <renihs_> any reasons for that, or is that some limitation of x264 or ...something? [19:20] <BtbN> How do i tell ffmpeg to only deinterlace a stream if it actualy is interlaced? [19:30] <Na_Klar> there is no problem with deinterlacing a progressiv stream. just deinterlace every time, when you expect sometimes it could be needed. [19:34] <smo_> sorry Na_Klar... it makes me crazy i m trying many differents command line can t get one working [19:34] <Mista_D> How can I stop "-ac 2" from lowering the volume? [19:37] <Na_Klar> smo_ please paste the whole output somewhere. e.g. pastebin [19:37] <Na_Klar> Mista_D: you are converting from what? mono? [19:38] <Mista_D> 5.1 to 2, volume drops ~20-30%. [19:38] <Na_Klar> lol [19:39] <smo_> i will Na_Klar , what s the best -f container to use for a libx264/aac encoding? [19:40] <Na_Klar> it drops 20-30%? ... downmixing is a difficult thing. if you would just combine all 6 channels you would peak the audio everywhere. be satisfied with 20% and normalize the stereo sound afterwards [19:40] <BtbN> Na_Klar, doesn't deinterlacing a progressive stream waste cpu time and degrade quality? [19:40] <Na_Klar> also, be sure that you are acutally downmixing and not just copying the FL and FR channels [19:41] <Na_Klar> BtbN, I don't think so. A good deinterlace algo would come to the conclusion to have nothing do deinterlace when it gets progressive material. [19:41] <Mista_D> Na_Klar: the values that fed into pan filter are also off, using pinknoise source, all pan values are ignored and sox reports constant dB irrelevant of pan values (possibly a bug, will post sample file and command in trac). [19:41] <BtbN> nope, if you enable it via cli, it'll allways run [19:41] <BtbN> at least that's what my cpu usage tells me [19:42] <Mista_D> Na_Klar: "-ac 2" is actually downmixing, no? [19:43] <Na_Klar> Mista_D, report it. But I don't know what you expect from a downmixing algo. How do you think it would downmix to 0db? I think a lesser value is expectable to gain headroom. expecially with cinema sound. [19:44] <Na_Klar> Mista_D, I personally prefer a manual mixdown. Think of LFE and stuff. I don't want an algo to decide that for me. [19:46] <Mista_D> Na_Klar: Is there a known volume reduction in ac and pan filters? Maybe point me to the source file? Thanks for the assist anyways. [19:46] <Na_Klar> BtbN: What do you mean? ffmpeg runs. It costs cpu. How can you tell the difference if it deinterlaced or not on your cpu status monitor? [19:47] <BtbN> because it needs way more to deinterlace? [19:47] <Na_Klar> well .. but does that decrease the speed? [19:48] <Na_Klar> Mista_D: Pan is made for channle-wise volume reduction. But I cannot point any source files, sorry. I don't develop ffmpeg. [19:48] <BtbN> it's nearly 100% on all cores with it, and totaly useless on progressive streams [19:48] <BtbN> also it does degrade the quality [19:50] <Na_Klar> BtbN: that sounds strange. But if so, I cannot help you, since I don't know of any way how ffmpeg could differ the input or has somelike a IF-condition parameter. You probably have to solve this with a script-wrapper. Like a ruby script which decides which command line will be executed. [19:50] <BtbN> i have no way to know if a channel is interlaced [19:50] <Na_Klar> a channel? [19:51] <smo_> Na_Klar, http://pastebin.com/PrAavN3A [19:51] <BtbN> yes. [19:51] <Na_Klar> what channel? you mean an input? [19:51] <BtbN> a tv channel [19:52] <Na_Klar> that is probably not hard to differ. [19:52] <Na_Klar> can you script a language like ruby? [19:52] <BtbN> not without analyzing the video stream [19:53] <BtbN> which would take way too long [19:53] <Na_Klar> ? [19:54] <Na_Klar> that does not make any sense. You can analyse if the stream is interlaced or not and then deinterlace or not. I just think ffmpeg cannot do that on its own. [19:55] <BtbN> Analyzing it involved opening it a second time, which doesn't work. [19:56] <BtbN> also, it takes quite a long time to tune a channel, which would cause a timeout [19:56] <Na_Klar> smo_, is it normal that the http server sends several audio data within the stream? [19:56] <BtbN> it has to be possible to tell ffmpeg to deinterlace only interlaced material... [19:56] <smo_> yes it s tv from my isp [19:56] <smo_> web tv [19:56] <Na_Klar> what are that different audio-streams? different languages? [19:57] <smo_> yep [19:57] <smo_> sometimes no always the same thing for all channels [19:57] <smo_> not* [19:58] <smo_> i disable the subtitles with -sn and don t care of other languages [19:58] <BtbN> Na_Klar, also, it's not simple to tell if a stream is interlaced at all. Even in some script. [19:58] <Na_Klar> smo_, did you also deactivated the sound for debuggin purpose? [19:59] <smo_> yep i tried -na [19:59] <smo_> still fail [19:59] <Na_Klar> BtbN: if it is not easy, how you think ffmpeg can easily? And furthermore, I don't think ffmpeg has any IF-condition you could setup in your command-line.. [19:59] <Na_Klar> smo_, you mean -an [19:59] <BtbN> because ffmpeg has to decode the material anyway, and so has to know anyway?! [20:00] <smo_> yep sorry [20:00] <BtbN> you need to actualy decode a frame to know [20:01] <BtbN> not even ffprobe is able to tell me that without -show_frames, which is a problem because it never stops, because it waits for the "end of file" of the livestream. [20:01] <Na_Klar> BtbN: maybe the headers contain information. Framerate, standard or the like. [20:01] <smo_> Na_Klar, with no audio http://pastebin.com/qyTzMt4d [20:02] <BtbN> no, the headers don't contain any information about this. It's only in the h264 bitstream. [20:02] <BtbN> or whatever codec it is [20:02] <BtbN> And ffmpeg DOES know it internaly after decoding, it would be trivial do check for that in the deinterlacer... [20:03] <Na_Klar> BtbN: Have you look if within 'filter_complex' are maybe more usable deinterlacing methods? [20:04] <Na_Klar> smo_ I don't see with which error ffmpeg exits. It seems like you aborted the operation. [20:04] <BtbN> there is nothing like a "usable deinterlacer" for progressive content... [20:05] <smo_> Na_Klar, if i retry i have grep stderr: [h264 @ 0xb336d20] concealing 1002 DC, 1002 AC, 1002 MV errors in P frame [20:05] <smo_> error while decoding MB 37 14, bytestream (5374) [20:06] <Cloudstrike> Hey i have a question i have my own stream server with nginx, all files get converted with ffmpeg, if i try to watch the stream with my iphone / ipad and try to skip then the video get freezed but the sound continues, after i updated ffmpeg new files werent effected but on many old files the problem still exists. I can provide more Information if needed :) [20:07] <Fusl> Cloudstrike: skip -> seek [20:08] <Na_Klar> BtbN: filter_complex is the last hint I could give you. I've no other idea how you could achieve that. [20:08] <BtbN> There is no documentation on how to find out if the stream is interlaced. [20:08] <Na_Klar> then maybe ffmpeg cannot [20:10] <Na_Klar> Cloudstrike: you should provide a question. that would be needed. [20:10] <BtbN> ffmpeg can, the information is in every single frame it passes around... [20:11] <Na_Klar> just that there is an information does not neccessarily mean a program will use it for something you think would be nice. [20:11] <Cloudstrike> the question is jow can i fix it? xD i want to re-encode all files who have this problem [20:11] <Na_Klar> then just re-encode them, if you want to do that. [20:13] <Fusl> Na_Klar: the problem is, we already re-encoed them but the problem still persists on the re-encoded files [20:13] <Na_Klar> so re-encoding was no solution. why do you claim it would be a solution then? [20:13] <BtbN> Na_Klar, it is absolutely stupid to deinterlace progressiv material. It wastes a hell lot of CPU cycles, and looks bad. [20:13] <Na_Klar> BtbN: then don't. Who do you want to blame for that? [20:14] <BtbN> Well, not deinterlacing interlaced material is also bad. [20:14] <BtbN> and i have no way to know that in advance. [20:15] <Na_Klar> you have plenty of ways, but you don't want to get into it. listen: if IF ffmpeg could differ between interlaced and progressive, ffmpeg does (most probably) NOT contain any way to make if-conditions on the fly. [20:15] <Fusl> Na_Klar: we're looking for options which fix this bug... i think there's something wrong with the zerolatency tuner but i'm not sure... how can i find out if the files have been converted with zerolatency? [20:16] <Na_Klar> s/if/even/ [20:16] <BtbN> Na_Klar, well, what way to i have?! I can't even create a huge list of channels and map them, because some of them use diffrent formats from time to time. [20:17] <BtbN> All i could do is create a second script and let the user decide, which is unaceptable. [20:17] <Na_Klar> BtbN: I just can give you the concept. Wrap the transcoding in a script which pre-decides if the input should be deinterlaced or not. I guarantee this is technically possible. [20:18] <BtbN> And HOW do i pre-decide if it should de-interlace?! [20:18] <BtbN> not even ffprobe helps me there [20:18] <Na_Klar> BtbN: Can you even script a language? (that I know if further information will help you at all) [20:18] <BtbN> ... [20:19] <BtbN> I have even developed some stuff for ffmpeg, which is why i know that it has that information easily available... [20:19] <BtbN> It just HAS to be possible to only deinterlace interlaced material. Everything else is absolutely stupid. [20:20] <BtbN> And i won't create an entire new application just to determine if a stream is interlaced. [20:20] <BtbN> Specialy because this won't help if it changes at runtime. [20:20] <BtbN> which it does sometimes [20:20] <flarunt> what if only some parts of the source are interlaced? [20:20] <brontosaurusrex> BtbN, so the channels have some sort of metadata for interlaced flag? [20:20] <BtbN> brontosaurusrex, no, the data for that is in the h264 bitstream. [20:21] <BtbN> which means it needs to decode at least one frame to know. [20:21] <brontosaurusrex> so why not parse the first few frames then? [20:21] <BtbN> yeah, because just decoding and parsind h264 or mpeg2 or vc1 is that simple [20:22] <brontosaurusrex> right ... [20:22] <flarunt> wouldn't a "smart" deinterlacer leave progressive material alone and only alter interlaced sections? obviously with some cpu overhead... [20:22] <BtbN> flarunt, yes, but ffmpeg doesn't care, if you tell it to deinterlace, it just does, no matter if it makes any sense [20:23] <brontosaurusrex> no, smart deinterlacer should deinterlace dinamicaly [20:23] <brontosaurusrex> but yes, it would be "active" all the time [20:23] <BtbN> checking if the interlaced flag is set each frame should cause no noticable cpu load [20:24] <BtbN> but it nearly doubles the cpu usage [20:24] <Na_Klar> BtbN: then go ahead and rewrite ffmpeg that it supports deinterlace/passthru on the fly [20:24] <flarunt> i believe yadif has options to operate like that [20:24] <BtbN> yeah, yadif does [20:25] <BtbN> but yadif is a little bit too much for my cpu [20:25] <BtbN> specialy with 1080i [20:25] <flarunt> i dont trust that interlaced flags are correct [20:26] <BtbN> they are [20:27] <flarunt> maybe you have better tv stations / bluray studios than i do :) [20:27] <Na_Klar> lol, somebody expects ffmpeg would change deinterlacing on the fly, while ffmpeg even does not support frame-property change on the fly ^^ [20:27] <BtbN> even a changes resolution works fine [20:28] <BtbN> *d [20:28] <Na_Klar> wut? [20:28] <Na_Klar> even a change of the colorspace does not work on the fly? wtf are talking about? [20:28] <BtbN> i have a station that changes to a 4:3 resolution each time it goes into comercials. Works as expected [20:29] <Na_Klar> Maybe with anamorph data .. but impossible with actual resolution [20:29] <BtbN> it does change the actual resolution [20:29] <Na_Klar> i don't believe you [20:30] <BtbN> ffmpeg stretches the video to the pre-configured output res, but it works [20:30] <Na_Klar> sounds like anamorph to me .. ffmpeg does definitely not support chaning frame properties on the fly. [20:30] <Na_Klar> *changing [20:31] <BtbN> No, the resolution actualy changes its width [20:31] <Na_Klar> whatever you tell me. I got so much trouble with that issue, that I hardly will believe you. [20:31] <BtbN> Does w3fdif use more or less cpu than yadif? [20:33] <llogan> Mista_D: are you using pan? note there is a difference between = and < in pan [20:35] <llogan> Fusl, Cloudstrike: you'll need to provide samples of the videos that do work, and samples of the videos that do not work, and the complete ffmpeg command and ffmpeg console output for each. [20:36] <llogan> also list the exact devices that it does not work [20:36] <Fusl> llogan: we're currently trying to find a video but as it seems we can't find one atm... maybe it was a bug from iOS and they fixed it already? who knows? i dunno, it's very weird :/ [20:37] <llogan> show your command and console output anyway for a typical video [20:37] <Na_Klar> BtbN: You are talking rubbish anyways, look here: http://www.100fps.com/video_resolution_vs_fluidity.htm .. the quality loss of deinterlacing progressive material is slight [20:38] <BtbN> deinterlacing one progressive frame into two other progressive frames is a horrible mess [20:46] <Na_Klar> gosh, there is even interlaced parts in progressive frames .. tv is a mess. deinterlace it all and that's it. [20:48] <flarunt> but then you lose fluidity of motion [20:50] <Na_Klar> meh bollocks, one could call that 'micro-optimization'. if you render your own material then you are right, you have to keep maximum quality. but this is tv. f*ck it [20:51] <BtbN> Na_Klar, deinterlacing it all is not an option, it realy does look horrible, Specialy because it doubles the framerate, which results in 100fps material for the normal 50 fps progressive channels. [20:51] <flarunt> any sport that airs interlaced at 50 fields and is deinterlaced to an output of 25fps looks horrible [20:51] <BtbN> which halves the available bandwidth [20:51] Action: Na_Klar *sighs* [20:52] <BtbN> making 100 fps out of 50 fps is not an option at all, seriously. [20:53] <BtbN> the bandwidth is already limited, but this halves it [20:53] <Na_Klar> you can enforce the output framerate [20:53] <BtbN> this will deinterlace the [20:53] <BtbN> the 50 fps to 100 fps, and then scale that down again [20:53] <BtbN> also a fixed framerate does not work for non 50fps channels [20:54] <flarunt> your source is 50fps progressive? [20:54] <flarunt> or 50 fields, interlaced? [20:54] <BtbN> yes [20:54] <Na_Klar> deinterlace all to the smallest common framerate. .. really, you are not seeing the wood for the trees [20:54] <BtbN> 720p50 [20:55] <BtbN> Na_Klar, it does look absolutely HORRIBLE [20:55] <BtbN> it's not an option [20:55] <Na_Klar> then you are doing something wrong. it shouldn't look >horrible< .. maybe less good .. but not horrible [20:55] <BtbN> flarunt, it results in 720p100 out of 720p50. Even with yadif and if i tell it to only deinterlace interlaced content [20:57] <flarunt> tell it to output at 50 [20:58] <BtbN> flarunt, that results in problems for 30 or 60 fps channels [20:58] <flarunt> use a different script / cli for that [20:58] <BtbN> i have no way to know in advance if a channel is deinterlaced or not. [20:59] <flarunt> you dont know if a channel will be 30, 50 or 60 fpr prior to encode? [20:59] <BtbN> ffmpeg propably does, but i don't know it when issuing the ffmpeg command [20:59] <flarunt> how many channels alter between 30 and 50 fps [20:59] <Na_Klar> ever heard of the least common denominator? that's your way. [20:59] <BtbN> i don't know. [21:00] <BtbN> that would be 10 fps... [21:00] <flarunt> you have a channel which airs at 10fps? [21:00] <Na_Klar> no .. that's the least. not the least common [21:00] <BtbN> so, what is thate that's bigger for 30, 50 and 60 fps? [21:01] <brontosaurusrex> so how many channels are actually progressive? [21:01] <flarunt> typically a channel in europe will be 25/50, and usa will be 30/60.. i dont know of any that switch between the two [21:01] <BtbN> brontosaurusrex, quite a lot [21:01] <brontosaurusrex> 1080p25 or what? [21:01] <BtbN> 720p50 [21:01] <brontosaurusrex> right [21:02] <BtbN> FullHD is either 1080i50 or 1080p24, which is even worse [21:02] <flarunt> are you sure it is 50 frames and not fields? perhaps the channel is broadcasting 50 fields flagged as interlaced, but actually the fields are from the same point in time and so 25fps? [21:02] <brontosaurusrex> worse than what? [21:03] <BtbN> flarunt, no. All the German ÖR hd channels are in 720p50 [21:03] <BtbN> brontosaurusrex, 50 or 30 fps [21:03] <BtbN> it's not even divieable by 5 [21:04] <flarunt> tell yadif to keep original framerate [21:05] <BtbN> that would make 1080p25 from 1080i50 [21:05] <Mista_D> llogan: thank you, "=" worked well. Its the "more proper to my ear" downmix now (: [21:06] <brontosaurusrex> BtbN, so whats the problem with short pre-analisis? at least you could catch framerate [21:06] <flarunt> no.. it would keep the frame rate the same.. so if your source is 50p your output will be 50. if your source is 50i, it will still be 50. [21:06] <BtbN> brontosaurusrex, tuning takes ~5-10 seconds [21:06] <brontosaurusrex> BtbN, you could cache it [21:06] <llogan> Mista_D: just watch out for clipping. [21:06] <BtbN> flarunt, unfortunately not. It would create one frame per frame [21:07] <BtbN> which means 25 frames for 50 fields [21:07] <BtbN> brontosaurusrex, how should i cache it? It's nothing that never changes [21:07] <flarunt> i guess it depends what you tell it to do... [21:08] <BtbN> it only has two modes of operation [21:08] <flarunt> you could make 50 frames from 50 fields if you wished too [21:08] <BtbN> mode_frame and mode_field [21:08] <BtbN> yes, but the i50->p50 mode results in p50->p100 [21:08] <BtbN> even tough i told it not to deinterlace progressive content [21:09] <BtbN> or is -vf yadif=1:-1:1 wrong? [21:09] <flarunt> like i said.. i dont think interlaced flags are accurate, or yadif does not read them accurately.. [21:10] <BtbN> the interlaced flags are not present [21:10] <BtbN> it just does it anyway [21:12] <flarunt> a long time ago i used the lavf directshow interface for yadif, i remember the "aggressive deinterlacing" option and "treat as progressive".. maybe that would be of use? http://devil-strike.com/kmp/KMplayer.jpg [21:12] <flarunt> ignore the arrows :) [21:13] <BtbN> if i'd know in advance what kind of material i have it would be simple to set the correct options [21:13] <brontosaurusrex> BtbN, so what exactly is ffmeg doing there, transcoding or what? [21:13] <BtbN> yes [21:15] <BtbN> it looks like a bug in the yadif deinterlacer. [21:16] <BtbN> It does correctly check and only deinterlace interlaced frames. But it still doubles the framerate value, without checking if the stream is interlaced or not [21:18] <brontosaurusrex> no, the questions is how can ffmpeg adapt the filter chain based on xy input changes dinamicaly [21:18] <brontosaurusrex> if it can at all [21:19] <brontosaurusrex> what do you get with something like ffmpeg -i input_video -f ffmetadata metadata.txt ? [21:21] <BtbN> "Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used)" [21:21] <BtbN> the file only contains "title=ZDF HD" after that [21:21] <BtbN> but it didn't analyse a single frame, even with a -frames option [21:22] <brontosaurusrex> so thats probably container meta [21:25] <BtbN> ffprobe correctly tells me that interlaced_frame is 0 [21:25] <BtbN> but aparently you can't tell ffprobe to only analyze one frame [21:25] <BtbN> so it goes on forever [21:28] <BtbN> ffmpeg -i http://localhost:9981/stream/channelnumber/2 -frames 1 -c:v copy -map 0:v:0 -f matroska - | ffprobe - -show_frames [21:28] <BtbN> seems to work... [21:39] <brontosaurusrex> -analyzeduration maybe [21:39] <brontosaurusrex> in miliseconds [21:39] <brontosaurusrex> ^ for ffprobe [21:41] <brontosaurusrex> ffprobe -analyzeduration 1 http://url < seems to work here [21:44] <brontosaurusrex> later~ [21:47] <renihs_> hmm how can i display what encoding options a vcodec has? [21:51] <Na_Klar> renihs_, you can always set all options. the question is, if they make sense. Read the codec documentary for further information. [21:51] <renihs_> Na_Klar, i am unaware about what options exist, can i display those with ffmpeg somehow? [21:52] <renihs_> trying to avoid looking up dozens diffrent documentation [21:52] <renihs_> which most i seem unable to find [21:52] <Na_Klar> trying to avoid to rtfm, aye? [21:52] <renihs_> um no? [21:52] <renihs_> are there man pages on the codecs? [21:53] <Na_Klar> no, mostly not [21:53] <renihs_> i am trying to _find_/display optins/docs [21:53] <renihs_> google is not really helpfull [21:53] <renihs_> bits and pieces of nonsense everywhere :( [21:53] <Na_Klar> what codec are we talking about? [21:54] <renihs_> well,i wanted to test around abit, but i guess thats too time costly, will try betwen vpx? vp9? and h264 now i guess [21:54] <JEEB> libvpx's vp9 encoding is _slow_ [21:55] <JEEB> it's not multithreaded [21:55] <JEEB> libx264's H.264 encoding on the other hand is quite optimized [21:55] <Na_Klar> renihs_, if you don't find a h264 parameter list in the interwebs, you are not allowed to be here .. [21:55] <JEEB> and as much as I might hate MCW's x265, that is just ~10 times slower than --preset placebo [21:55] <JEEB> (of x264) [21:55] <renihs_> well, so far vp9 has screenrecorded nicely hmm h264 i am trying to get to reasonable sizes [21:55] <JEEB> I'm pretty sure you're doing vp8 [21:56] <renihs_> ah [21:56] <JEEB> if you got realtime speeds [21:56] <renihs_> ya [21:56] <renihs_> did this afternoon, cant recall, too much vp/x/9/8 something [21:56] <JEEB> x264 is both going to compress better and most probably be able to go faster at that [21:56] <JEEB> you would have remembered libvpx's vp9 encoding :P [21:56] <renihs_> well, atm it only produces gigantic files [21:56] <JEEB> as in, you would've not gotten anything done [21:57] <renihs_> and i dont even know what audio codec i could use, trying to get "easy viewability" [21:57] <renihs_> thats why webm is still abit favored [21:57] <JEEB> well, capture is supposed to be big because you're trying to create a file with the least possible loss [21:57] <JEEB> and then you re-encode that taking your time for consumption [21:57] <renihs_> well, i would prefer realtime encoding [21:57] <JEEB> only exception being live streaming [21:58] <renihs_> the vp8? stuff i did all realtime on a notebook with small endfiles [21:58] <renihs_> but so far, 20min 1280x720 produces like 4gb [21:59] <renihs_> instead like 200m [21:59] <Na_Klar> maybe you should get familiar with presets and profiles [21:59] <renihs_> presets i am [21:59] <renihs_> bitrates i try to figure out now [22:00] <renihs_> and for someone not into audio/video. this is all very confusing, or at least for me [22:00] <renihs_> brb [22:04] <ubitux> < JEEB> you would have remembered libvpx's vp9 encoding :P // :D [22:19] <renihs_> i dont even know yet, those things will have differernt length and content and hmm [22:19] <renihs_> something between 1m and 1.5m i guess [22:19] <BtbN> that seems quite low [22:20] <renihs_> its screencast stuff so hmm doesnt need to be too crazy [22:20] <renihs_> 1280x720 [22:21] <renihs_> uff, too much load, my poor lappy will never survive that :p [22:21] <BtbN> does it happen to have a nvidia kepler gpu? [22:33] <renihs_> hmm regarding audio, what codec "should" one use with h264? i am confused, i currently use libvorbis/ogg but i doubt thats very compatible [22:33] <BtbN> i'd use aac [22:34] <renihs_> ah it brabled about experimental, hmm lemme recheck [22:34] <BtbN> the normal aac encoder is expermiental, yes [22:34] <BtbN> libfaac shouldn't be [22:34] <renihs_> ah Alternatively use the non experimental encoder 'libvo_aacenc' [22:34] <JEEB> if you're going to be using an encoder you have to compile yourself, use fdk-aac [22:34] <JEEB> renihs, no [22:35] <JEEB> that is NOT better than the internal one [22:35] <JEEB> :| [22:35] <renihs_> oh hmm [22:35] <renihs_> ffmpeg says that :) [22:35] <JEEB> well, it's not tagged 'experimental', that's the only difference :/ [22:35] <BtbN> is fdk better than libfaac? [22:35] <JEEB> yes [22:35] <JEEB> so either use the internal, or build fdk-aac [22:35] <JEEB> (you'll have to rebuild ffmpeg, too) [22:35] <BtbN> i'm currently using libfaac, maybe i should switch [22:36] <JEEB> yes, you should :) [22:36] <BtbN> is it realy that much better? oO [22:36] <JEEB> yes :) [22:36] <renihs_> awesome, why dont i have libfaac but i have ... libvo_aacenc "Android VisualOn AAC" [22:36] <renihs_> what the heck :) [22:36] <BtbN> you built your ffmpeg without it [22:36] <JEEB> yes, you can't distribute builds of faac or fdk-aac [22:37] <JEEB> because faac used non-GPL-compatible stuff (reference code) in it [22:37] <JEEB> and fdk-aac's license is a bit derpy, but at least it was properly open sourced [22:37] <renihs_> recompiling [22:37] <JEEB> https://github.com/mstorsjo/fdk-aac [22:37] <JEEB> fdk :) [22:37] <JEEB> after google noticed that vo-aacenc sucks, they bought and licensed and open sourced fdk-aac [22:38] <JEEB> fraunhofer's encoder :) [22:38] <BtbN> i never noticed that faac is bad [22:39] <JEEB> well, it isn't as bad as the libavcodec one or vo-aacenc, but it's most definitely not on the level of fdk-aac [22:39] <JEEB> also fdk-aac supports HE-AAC v1 and v2 [22:39] <llogan> renihs_: "ffmpeg -h encoder=libx264" for example [22:40] <renihs_> llogan, um nice..thanks [22:41] <renihs_> feeling dumber already, these help features are not that easy to spot... [22:41] <renihs_> ok, with faac and fdk [22:41] <JEEB> just fdk is enough [22:41] <JEEB> there's nothing that faac does better [22:41] <JEEB> :) [22:42] <renihs_> i believe you but for "having it purposes" i fetch it hmm [22:43] <renihs_> should have added openal as well [22:44] <renihs_> Fraunhofer FDK AAC (codec aac) [22:44] <renihs_> better :) [22:45] <JEEB> make sure the afterburner option is enabled when you use it, btw :) not sure if it's enabled by default nowadays [22:45] <JEEB> -afterburner 1 [22:45] <JEEB> it makes the encoder a bit slower, but on normal PCs it doesn't really matter [22:45] <JEEB> quality goes up nicely [22:46] <renihs_> sounds great, applying without question :) [22:46] <llogan> i think it is default, but i can't remember [22:46] <JEEB> it's probably not enabled by default in fdk-aac because it was made for ARM originally [22:46] <JEEB> yeah, it could be on by default nowadays [22:47] <renihs_> Afterburner (improved quality) (from 0 to 1) hmm [22:47] <renihs_> well sounds nice :) [22:48] <llogan> Afterburner (improved quality) (from 0 to 1) (default 1) [22:48] <JEEB> :) [22:48] <llogan> according to my build and a quick test with md5 [22:49] <llogan> md5 muxer [22:52] <renihs_> hey, mine doesnt say which is default [22:53] <llogan> is your ffmpeg or fdk-aac old? [22:55] <renihs_> 0.1.3 for fdk-aac, probably [22:56] <renihs_> na, seems to be latest hmm [23:24] <BtbN> Why does ffmpeg use 26GB virtual memory? oO [23:24] <BtbN> while only using 220M real mem [00:00] --- Thu Feb 20 2014

1 0

ffmpeg-devel.log.20140218
by burek 19 Feb '14

19 Feb '14

[05:10] <cone-358> ffmpeg.git 03Michael Niedermayer 07master:61d59703c918: avcodec/snow: split block clipping checks [09:38] <superware> can someone please explain how to sync video frames to internal timer using PTS. I found https://trac.handbrake.fr/wiki/LibHandBrakeSync but don't really understand the concept.. [09:41] <ubitux> j-b: "With FFmpeg, HuffYUv is broken." huh? [09:42] <j-b> ubitux: fact. [09:42] <j-b> ubitux: https://wiki.videolan.org/Libavcodec_regressions [09:42] <j-b> ubitux: being bored of FUD, I do my own tracking [09:42] <ubitux> yes that from where i quoted it [09:43] <ubitux> i'm just wondering where is the sample/ticket/whatever [09:43] <j-b> https://forum.videolan.org/viewtopic.php?f=14&t=117212&p=398361&hilit=huffy… [09:43] <j-b> and as usual, you'll dismiss this [09:44] <av500> dismissed [09:44] <av500> next [09:44] <ubitux> i? huh? [09:45] <ubitux> confirmed, 'will open a ticket [10:00] <ubitux> bisecting. [10:05] <ubitux> michaelni: e6d1c66d742d766a80a26ed2a9524a0fffbcf958 #3395 [10:06] <ubitux> j-b: other facts while i'm at it? [10:06] <nevcairiel> that is one odd commit to break stuff [10:07] <nevcairiel> i mean, it just disables asm [10:08] <j-b> ubitux: some issues with bmp encoding and threading, IIRC [10:09] <ubitux> j-b: ticket/forum post/sample/anything? :p [10:10] <j-b> no [10:11] <j-b> and the famous vdpau issue [10:11] <ubitux> what's that? [10:19] <av500> FFmoped? [11:48] <ubitux> lol @ mp4 files with megabytes of zero padding... [11:55] <nevcairiel> i was wondering if someone would dig up my old h264 dxva2 patches one day. :p [13:59] <cone-331> ffmpeg.git 03Michael Niedermayer 07master:469de4f58317: avcodec/huffyuvdec: use the correct height field [13:59] <michaelni> j-b, fixed [14:02] <michaelni> j-b, that is the huffyuv issue. What do you mean by "and the famous vdpau issue" ? [14:02] <michaelni> which ticket is that ? [14:03] <j-b> don't know if there is a ticket [14:03] <j-b> but vdpau from libav and ffmpeg is not the same, IIRC [14:04] <michaelni> "not the same" is a bit vague, is there some incompatibility? something not working? [14:06] <ubitux> michaelni: https://mailman.videolan.org/pipermail/vlc-devel/2014-February/096628.html [14:06] <ubitux> i think that's this thread [14:07] <nevcairiel> the thread reads more like vlc drama then a technical discussion of issues in ffmpegs code [14:08] <ubitux> i read later "An ugly workaround would be to disable VDPAU if micro > 100, aka FFMpeg case." but i have no idea what the issue actually is [14:24] <BBB> does anyone mind if we temporarily use upload.ffmpeg.org/incoming for sharing some files between developers (ubitux/nevcariel/me)? [14:24] <ubitux> Compn ^ ? [14:26] <ubitux> ETA 30h for the etv5k vp9 samples [14:26] <BBB> \o/ [14:27] <nevcairiel> I added a few more bitrates to my encodes, and to my own surprise a 1mbit vp9 encodes much slower then 5mbit :p [14:28] <nevcairiel> (also, 1mbit vp8 looks like crap) [14:29] <ubitux> 5k in 17h, 10k in 22h and 20k in 30h [14:29] <ubitux> larger = slower for me here with vp9 [14:29] <nevcairiel> was the same for me, except that it went back up with 1mbit [14:29] <ubitux> vp9 backfire [14:30] <BBB> ubitux: yeah same for me [14:30] <BBB> libvpx doesn't seem to prune rd modes very well at high bitrates, not sure why [14:30] <JEEB> <nevcairiel> (also, 1mbit vp8 looks like crap) <- IIRC libvpx's vp8 encoder lacks a lot of psyopts. Although for example AQ is already quite expensive to do because signaling the change is expensive IIRC? [14:30] <BBB> nevcairiel: yeah more bitrates is good, also if you guys can, make sure the resulting ssim values are recorded somewhere before you destroy the y4m original [14:31] <nevcairiel> i kept the original [14:31] <BBB> ok thanks [14:31] <nevcairiel> everything here; http://files.1f0.de/encodes/ .. except the 1mbit vp9 which is still encoding [14:31] <BBB> I use this script to measure ssim: http://pastebin.com/iyC3C4Xp [14:31] <BBB> it uses tiny_ssim and then please do apply the patch I sent to the ML [14:32] <BBB> so that we have both db as well as raw ssim numbers (and it will also record psnr, this isn't terribly useful but why not...) [14:32] <BBB> and relevant files are in ftp://upload.ffmpeg.org/incoming/vp9-speed/ [14:33] <BBB> that probably needs to be moved somewhere to be world-readable but I don't have the password anymore [14:33] <BBB> so if someone feels like organizing that, that'd be wonderful [14:35] <BBB> nevcairiel: ubitux: can you guys try to generate the ssim/psnr numbers per file yourself? then I don't have to download the raw y4ms :-p [14:35] <BBB> (still have a diskspace problem) [14:35] <ubitux> sure [14:36] <BBB> ty :) [14:36] <ubitux> if you give me the command [14:36] <BBB> http://pastebin.com/iyC3C4Xp [14:36] <nevcairiel> I suppose the tool should work on windows right [14:36] <BBB> I think so [14:36] <BBB> maybe mkfifo won't? [14:36] <BBB> don't know [14:36] <BBB> it basically just calls ffmpeg twice to decode the file and the y4m, and then calls tiny_ssim [14:37] <BBB> then run that in a loop on all encoded files [14:37] <BBB> off to work now, bbl [14:39] <j-b> ubitux: michaelni: details in your mail. [14:42] <Compn> ubitux : why would i mind? :) [14:42] <ubitux> Compn: dunno, i thought you were somehow maintainer of the samples [14:42] <Compn> (p.s. upload.ffmpeg.org is j-b's server) [14:43] <Compn> its ok with me [14:43] <Compn> i actually dont know how to delete off incoming [14:44] <Compn> maybe carl knows [14:45] <Compn> j-b would know , i only have http access... [14:50] <nevcairiel> hm a 500k encode still looks surprisingly well, wonder if i should try to do something extreme like 100k :p [15:01] <nevcairiel> BBB: yeah mkfifo doesn't work, but no matter, i'll just create the full files first [15:36] <{V}> nevcairiel, there is a mkfifo-like solution if creating the full files is less desireable [15:41] <cone-331> ffmpeg.git 03Reimar Döffinger 07master:e535897fad2c: Fix libswresample compilation with Apple Neon assembler. [15:41] <cone-331> ffmpeg.git 03Michael Niedermayer 07master:1355cafcb675: Merge remote-tracking branch 'cehoyos/master' [16:10] <ubitux> nevcairiel: we definitely need a "stream" metadata to be exported in lavfi though [16:10] <ubitux> for the final values [16:10] <ubitux> frame metadata works, but final one are not exported up to the stream [16:21] <nevcairiel> lavfi doesnt have a concept for that though, and pushing that in frame side data to be extracted later and copied to stream metadata seems like a terrible ugly thing [16:22] <ubitux> i wasn't thinking of this [16:23] <nevcairiel> but "the others" were :p [16:23] <ubitux> more like AVStream metadata linked to AVFilterlinks [16:23] <ubitux> so like, rotate/transpose filters could use the rotate metadata from the stream [16:23] <ubitux> or we could inject replaygain metadata in the stream metadata [16:23] <ubitux> so it's written as id3 or whatever [17:01] <cone-331> ffmpeg.git 03Michael Niedermayer 07master:9bb1af8f36ec: avcodec/huffyuvdec: use RGB0 for 24bit rgb output instead of BGRA [17:43] <cone-331> ffmpeg.git 03Hendrik Leppkes 07master:7716eda0aad7: vp9/x86: set correct number of registers used in intra pred asm [18:19] <cone-331> ffmpeg.git 03Gonzalo Garramuno 07master:3d20260157cb: avcodec/exr: read layers [19:08] <aca> Hi. I'm trying to compile ffmpeg 2.1.3 on Debian testing and I thought it went well. But 'make check' fails: "Test idct8x8 failed. Look at tests/data/fate/idct8x8.err for details." This file says: "symbol av_buffer_allocz, version LIBAVUTIL_52 not defined in file libavutil.so.52 with link time reference" Does someone know what went wrong? [19:09] <nevcairiel> sounds like it tried to load a system library [19:09] <aca> Can I tell it not to do so? [19:35] <ubitux> ffplay -user-agent "Mozilla/5.0" "http://translate.google.com/translate_tts?tl=ja&q=................" [19:41] <ubitux> (seems the user agent is not necessary anymore/in this case - can be ignored) [19:42] <michaelni> aca, simple/quick solution is not to use --enable-shared [19:44] <cone-331> ffmpeg.git 03Michael Niedermayer 07master:cbcfd7da4d1f: avcodec: support setting the chroma intra matrix [19:44] <cone-331> ffmpeg.git 03Michael Niedermayer 07master:3e70c7023e59: ffmpeg: support setting the chroma intra matrix [19:46] <aca> michaelni, thanks for the hint, but I'm trying to make a Debian package... Not build-depending on libopencv-dev should help, as this pulled in libavutil52. [19:47] <michaelni> aca, debian package for yor personal use or something official ? [19:49] <aca> At the moment for personal use, but I intent to send the debian.tar.xz to the RFP bug and see what comes of it. [19:52] <michaelni> about doing it the correct way with shared libs, there are 2 ways, the first is to change the major version numbers to match libav and use --enable-incompatible-libav-abi, this would then install libs matching libav as a theoretically 100% compatible replacement. Or instead of all that use --enable-raise-major to install libs with different sonames which theoretically should be installable side by side with libav [19:52] <michaelni> if either of these fails somehow iam quite interrested in bug reports [19:55] <aca> Do you mean that with --enable-incompatible-libav-abi programs compiled with libav will work with ffmpeg? Has this negative consequences, e.g. missing features? [19:56] <michaelni> no missing features, the only problem is that this has not been tested much so it likely will hit bugs that will need to be fixed [19:57] <ubitux> note that it probably won't be enough; i believe some apps depends not only on the libraries but the programs as well [19:57] <ubitux> you will probably have to make sure those apps can call both ffmpeg and avconv [19:57] <ubitux> ...or add a avconv symlink to ffmpeg as a tmp workaround, but that would be evil [20:00] <aca> At the moment I'm not installing qt-faststart in the ffmpeg package, so that it does not conflict with libav-tools. So if e.g. avconv works with the ffmpeg libraries this should work, if both ffmpeg and libav-tools are installed. [20:01] <ubitux> qt-faststart has a limited usage nowadays, and it doesn't diff much between the 2 projects [20:01] <ubitux> we just have a few fixes iirc [20:03] <Daemon404> the epic ticket reached 256 [20:03] <aca> Would packages compiled against these ffmpeg libraries with --enable-incompatible-libav-abi work with the libav libraries? [20:04] <nevcairiel> Daemon404: I wish they would find some commitable changes already [20:04] <Daemon404> yeah [20:04] <ubitux> aca: i'd say probably very badly [20:05] <ubitux> ah mmh sorry misread [20:05] <ubitux> aca: as long as they don't use ffmpeg specific features... [20:07] <ubitux> aca: if you want to package both libs properly i'm afraid you'll have to duplicate dep packages (foobar-libav and foobar-ffmpeg) [20:12] Action: Daemon404 sees BB patche tiny_ssim [20:12] <Daemon404> BBB* [20:12] Action: Daemon404 used to use xiph's dump_ssim for that [20:12] <ubitux> aca: a lot of packages have various .100 minor check to enable ffmpeg specific path; so even if it's build with --enable-incompatible-libav-abi, the app will probably try to use ffmpeg features [20:12] <ubitux> s/minor/micro/ [20:12] <nevcairiel> he tried, he hated it because it was incredibly slow, Daemon404 [20:12] <Daemon404> of course it is [20:12] <aca> ubitux: Do you mean every package using ffmpeg/libav would need to be duplicated? I don't think that is doable... [20:13] <nevcairiel> we're already spending hours and hours encoding test footage in vp9, at least the ssim can be fast! [20:13] <Daemon404> iirc the windowing in tiny_ssim is a lot bigger [20:13] <ubitux> aca: doesn't debian already do that with various libs? [20:13] <ubitux> aca: like gnutls vs openssl or stuff like that [20:13] <Daemon404> nss1 [20:13] <Daemon404> ! [20:14] <aca> ubitux: Yes, but that's rather painful and I think nobody wants to do this for ffmpeg/libav... [20:14] <aca> ubitux: But compiling with --enable-raise-major should give packages that are coinstallable with libav? [20:15] <michaelni> ubitux, why would any packages need to be duplciated ? [20:17] <ubitux> michaelni: well, it means every app using libav* will need to be build against libav [20:17] <ubitux> aca: it's simple, we are basically "retro" compatible with libav assuming the --enable-incompatible-libav-abi flag, in the sense that we are a subset of it [20:17] <ubitux> you can consider it that way [20:17] <Daemon404> i think you mean superset [20:17] <ubitux> a superset* [20:18] <ubitux> yes [20:18] <michaelni> ubitux, i think you are wrong on the "every" i thnk the majority of apps that work with libav would also work with it when they have been build against ffmpeg [20:19] <ubitux> michaelni: i think most app nowadays use the .100 micro check to do specific ffmpeg path [20:19] <ubitux> maybe i'm wrong.. [20:19] <aca> By the way, is this compatible with libav 9 or libav 10? [20:20] <shahriman> hi guys [20:20] <Daemon404> the version #s more or less have no me meaning at all [20:20] <Daemon404> s/me // [20:20] <shahriman> can anyone please unblock my message to ffmpeg-devel [20:20] <shahriman> my patch* [20:20] <shahriman> who is the mod for ffmpeg-devel ML? [20:21] <michaelni> aca, compatibility should be always to the versions from about the same time [20:21] <nevcairiel> Daemon404: technically tiny_ssim is part of fate, and not the tool set. :p alternative suggestions to detect isatty are surely welcome i reckon [20:21] <aca> Daemon404: I'm not so sure about that. A lot of packages that build with libav9 fail to build with libav 10. [20:21] <nevcairiel> I think the patch to tiny_ssim breaks fate anyway, since it changes the output [20:21] <Daemon404> nevcairiel, it actually was originally a tool [20:21] <Daemon404> by pengvado [20:21] <Daemon404> we just happened to import it [20:21] <aca> michaelni: So 2.3.1 is libav10? [20:21] <Daemon404> aca, i mean the version numbers between libav and ffmpeg are in no way related [20:21] <Daemon404> there is no " is comptible with Y" [20:22] <Daemon404> X* [20:22] <aca> Daemon404: I see. [20:23] <ubitux> shahriman: i think llogan has control over it [20:25] <llogan> shahriman: there you go [20:25] <shahriman> llogan: thanks a lot. [20:26] <llogan> mail mod with UTC -9 results in odd queue clearing times. [20:27] <aca> Now the next test fails: make[1]: *** [tests/data/ffprobe-test.nut] Error 127 How to make this one work? [20:28] <wm4> ubitux: ping on the subtitle shit? [20:28] <Daemon404> aca, ? [20:28] <ubitux> wm4: yes i'll have a look tonight, 'didn't forget [20:29] <ubitux> wm4: i have some stuff to get done right now though, sorry [20:29] <superware> can someone please explain https://trac.handbrake.fr/wiki/LibHandBrakeSync ? I'm looking for an algorithm for syncing network stream video frames for display. [20:30] <Daemon404> superware, perhaps you should go as in teh handbrake channel [20:30] <Daemon404> we're not handbrake [20:31] <aca> Daemon404: I'm trying to get 'make check' working, but it fails... [20:31] <Daemon404> if it fails then it's a bug [20:32] <aca> Daemon404: How can I debug this? [20:32] <Daemon404> well... [20:32] <Daemon404> error 127 is a POSIX code [20:32] <Daemon404> it means command not found [20:32] <Daemon404> something isnt being built, or a makefile dep is wrong [20:32] <Daemon404> probably. [20:33] <ubitux> ffprobe maybe :) [20:33] <aca> Daemon404: Maybe it needs --enable-libnut, but I think libnut is not available in Debian. [20:33] <Daemon404> no [20:33] <superware> Daemon404: my issue is rather general, not really handbrake related (plus their channel is empty) [20:33] <Daemon404> the nut tests use our own thing [20:33] <Daemon404> its probably what ubitux said. [20:34] <Daemon404> superware, looks pretty full to me [20:36] <Daemon404> 23 [20:36] <Daemon404> woops. [20:39] <superware> Daemon404: you're right, sorry :) [22:21] <superware> if I set AVCodecContext->refcounted_frames = 1; I will later need to av_frame_unref(frame); av_free(frame); per frame, right? [22:24] <wm4> superware: yep [22:24] <wm4> superware: actually, you have to be careful [22:24] <Daemon404> you dont av_free frames [22:24] <wm4> first, don't call av_free(frame), but av_frame_free(frame) [22:24] <wm4> it will also do the unref for you [22:25] <superware> woops [22:25] <wm4> and second, I think you should always unref the frame you pass to the decoder [22:25] <wm4> I'm not sure what currently happens if you pass a referenced frame to it [22:27] <wm4> maybe use av_frame_move_ref [22:28] <superware> I have a rendering thread which dequeues AVFrame*s, renders, and free/unref [00:00] --- Wed Feb 19 2014

1 0

ffmpeg.log.20140218
by burek 19 Feb '14

19 Feb '14

[00:00] <three_le1s> sorry i'm a noob lol [00:05] <llogan> three_le1s: i don't understand waht you're trying to do. there is no 1.26.x or 1.27 release of FFmpeg [00:30] <three_le1s> erm [00:30] <three_le1s> i meant zoneminder [00:30] <three_le1s> sorry im tired [00:30] <three_le1s> llogan: [00:31] <llogan> three_le1s: this is #ffmpeg. [00:31] <three_le1s> oh [00:31] <llogan> you are tired [00:31] <three_le1s> wow i'm really tired [00:31] <three_le1s> ty [00:52] <Hello71> is there an option for "check if this is supported"? [00:52] <Hello71> very poorly worded question [00:52] <Hello71> background: I want to use travis-ci to check my project [00:53] <Hello71> which uses ffmpeg to convert some assets (out of my control) [00:53] <Hello71> I want to reduce the compile time of ffmpeg, so use --disable-everything and --enable specific (de)muxers, (de)coders, etc [00:54] <Hello71> I want to run my build system with some option to check that all required options are present [00:54] <Hello71> like --pretend or somesuch [00:54] <Hello71> should I just touch output then use -n and examine the output? [02:05] <Hello71> what protocol do I need to handle local files through ffmpeg? [02:05] <Hello71> cache? data? file? unix? [02:05] <Hello71> pipe? [02:22] <llogan> Hello71: usually a file is used as an input for ffmpeg. see "man ffmpeg-protocols" [02:23] <Hello71> llogan: what about my previous question? [02:25] <llogan> Hello71: sorry, but i don't understand your first question. [02:26] <Hello71> I want to ensure that everything in the... "pipeline" is supported by the currently configured ffmpeg [02:26] <Hello71> that is, I have included all the correct muxers, demuxers, encoders, decoders, protocols, etc. [03:08] <Hello71> oh, I thought of a solution [03:08] <Hello71> -t 00:00:01 [03:11] <Hello71> www/dump/bgm/The_Student_Council.wav: Invalid data found when processing input [03:11] <Hello71> that's a peculiar error. [03:11] <Hello71> apparently it means "container is not supported" [06:09] <Keestu> i am not sure if i need to do dts/pts calculation , if i need to display only video captured from IPed camera, through ffmpeg?. [06:26] <chooga> looking for a good example of how to use libffmpeg to package h264 + aac into a TS file [09:27] <superware> can someone please explain how to sync video frames to internal timer using PTS. I found https://trac.handbrake.fr/wiki/LibHandBrakeSync but don't really understand the concept.. [14:05] <FedoraUser> hi friends [14:05] <FedoraUser> i am trying to set up live broadcast using ffmpeg [14:06] <FedoraUser> but can't seem to find how to add some text later on in broadcast [14:06] <FedoraUser> what should I look into? [18:55] <Magiobiwan> So, I've finally gotten audio capturing working properly on my tuner card encoding setup. Now I need to get video working properly [18:55] <Magiobiwan> avconv/ffmpeg detects the input to be 320x240 raw video. It should be 720x480 though [18:56] <Magiobiwan> How do I specify to ffmpeg the input resolution? [19:07] <llogan> Magiobiwan: use pastebin to show the complete output of: ffmpeg -f v4l2 -list_formats all -i /dev/video0 [19:07] <llogan> and make sure you're using ffmpeg from FFmpeg, and not a fork since this is #ffmpeg and we don't support third-party stuff here. [19:21] <Magiobiwan> http://pastie.org/8746142 [19:22] <Magiobiwan> llogan, ^ [19:23] <Magiobiwan> Oh [19:23] <Magiobiwan> That would be a fork [19:23] Action: Magiobiwan glares at Ubuntu Maintainers [19:42] <Astyanx> Anyone willing to spend some time helping a novice troubleshoot? :) I just installed Ubuntu 13.10 server yesterday, but I'm having issues with serviio seeing ffmpeg as installed. [19:42] <llogan> Astyanx: where is the ffmpeg binary, and where is serviio looking for it? [19:44] <llogan> Magiobiwan: you can download a static build or compile ffmpeg [19:44] <llogan> http://trac.ffmpeg.org/wiki/UbuntuCompilationGuide [19:45] <Magiobiwan> I'd prefer to use the package included with Ubuntu, as this is going to be production once I get it working. What would the IRC channel be for support with the fork Ubuntu uses? [19:45] <JEEB> Magiobiwan, #libav [19:45] <Magiobiwan> I wonder if CentOS has support for the tuner cards I'm using... [19:46] <Magiobiwan> If it does, I'll just jump over to it [19:46] Action: Magiobiwan will have to investigate [19:46] <Magiobiwan> Thanks JEEB [19:46] <JEEB> both are so old I wouldn't use anything packaged with them to be completely honest :P [19:46] <JEEB> esp. centos [19:46] <JEEB> at least it seems like ubuntu 14.04 will finally have something newer than Libav 0.8 [19:51] <superware> can someone please explain https://trac.handbrake.fr/wiki/LibHandBrakeSync ? I'm looking for an algorithm for syncing network stream video frames for display. [21:43] <siscoco> hi all [21:44] <siscoco> i need help to play a link into ffplay [21:44] <Magiobiwan> So, using a freshly compiled REAL ffmpeg build, it still only sees the input as being 320x240 raw video [21:44] <siscoco> but what is strong , is .qmx [21:50] <siscoco> i really need your help i used user-agent but doesnt work [21:50] <siscoco> i got all the info from wireshark but still stuck [21:50] <siscoco> couldnt play it [21:51] <Hello71> real as opposed to imaginary? [21:57] <siscoco> is it possible to play qmx on ffmpeg ? [22:05] <Hello71> !g ffmpeg qmx [22:09] <Blah> Hi guys, I have a stream 720x576 res coming to ffmpeg, then I feed it to ffserver, I want to have a same resolution when its served by FFServer to a player [22:09] <Blah> But ffmpeg is refusing to cooperate :) [22:12] <Blah> max bitrate possibly too small or try trellis with large lmax or increase qmax [22:12] <Blah> [mpeg4 @ 0x37b0d20] rc buffer underflow [22:12] <Blah> so I increased on the FFServer side [22:13] <Blah> and i get the same error [22:19] Action: Blah needz helpz [22:24] <superware> if I set AVCodecContext->refcounted_frames = 1; I will later need to av_frame_unref(frame); av_free(frame); per frame, right? [22:25] <siscoco> most usa channels are now using qmx file and its not playable on ffplay, but what i see , the directory software has avcodec.dll [22:25] <siscoco> so its how they do ? [22:29] <siscoco> Move Player [22:29] <sacarasc> I have never heard of QMX before. :| [22:31] <siscoco> well its a file used by move player [22:31] <siscoco> all channels like ABC are using it now [22:31] <siscoco> im stuck to grab the stream [23:16] <rcombs> what's the largest size one can expect in a MOOV atom? [23:39] <active8> hi. trying to slow down a mp4 clip. found a bunch of pages telling me to -vf setpts= string along with a new frame rate and ffmpeg errors that vf is an unknown option. How do I change playback speed. I'd like to not trash the audio - it's a lightning fast classical guitar run, so hearing the notes helps. [23:40] <active8> intro to La Villa Strangiato, BTW 8) Rush rules! [23:46] <active8> ok. one sec [23:48] <active8> http://pastebin.com/Ebe1jXz6 [23:49] <llogan> your ffmpeg is too old. [23:49] <active8> i see it's not the ffmpeg I built last month. forgot my ./ [23:49] <llogan> http://trac.ffmpeg.org/wiki/CompilationGuide [23:52] <active8> thanks. sorry. i saw that just before you responded, but you called it right while I had just a hunch. What's static build have to do with this? llogan? fflogger? [23:53] <llogan> fflogger is a bot. [23:53] <active8> i read the build guid 3 times 8) [23:53] <llogan> you can simply download, extract, and execute the build if you're too lazy to compile. [23:55] <active8> ah. 'swat I thought you meant, not knowing I had a newer build at the time you posted. it worked, incidentally. I just have to play the result and see if I need to tweak those options [23:57] <active8> now to figure out how to slow down the audio without changing the pitch. audio editors call that time warp and I forget the real name - 3 different FFT choices, IIRC [23:58] <llogan> http://ffmpeg.org/ffmpeg-filters.html#atempo [23:58] <llogan> and also maybe asetpts [23:58] <active8> asetpts. an intuitive little program, isn't it? [00:00] --- Wed Feb 19 2014

1 0