Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

February 2016

1 participants
58 discussions

ffmpeg-devel.log.20160228
by burek 29 Feb '16

29 Feb '16

[01:37:57 CET] <philipl> [02:03:48 CET] <cone-833> ffmpeg 03Michael Niedermayer 07master:b70e9b4906a3: avutil/imgutils: Assert that the 2nd av_image_fill_linesizes() call in av_image_fill_linesizes() still succeeds [03:20:29 CET] <michaelni> j-b, any news about the hwaccel-mt case ? I really would like you to remove the check that prevents ffmpeg from being used with vlc 2.2 or whatever versions are affected. [03:21:43 CET] <michaelni> also if there is anything i can do, like rewording the warning or adding a flag to turn the warning off or otherwise, then please say so [03:32:10 CET] <cone-833> ffmpeg 03Andreas Cadhalpun 07master:15708f13477a: configure: add direct detection of libopencv [04:26:36 CET] <cone-833> ffmpeg 03Syed Andaleeb Roomy 07master:b4dcd351ec50: movenc: Timecode in MP4 Although MP4 does not have a concrete specification to store timecode information, the following technical note from Apple describes a way to achieve this via timecode track, similar to how it is done for MOV files. [04:26:37 CET] <cone-833> ffmpeg 03Michael Niedermayer 07master:5d18dc379539: tests/lavf-regression: Add mp4 timecode test [05:33:50 CET] <Timothy_Gu> michaelni: next time you apply a patch could you please make sure that the commit message is doesn't contain such a long line? thanks [09:31:36 CET] <funman> michaelni: i am looking if i can test vdpau hwaccel iwth vlc [10:03:21 CET] <funman> http://git.videolan.org/?p=vlc.git;a=commitdiff;h=b8869f97ea66ac7ec9912a74c… [12:09:15 CET] <michaelni> funman, thanks alot! [13:37:58 CET] <cone-054> ffmpeg 03Reimar Döffinger 07master:0f199f0ad01e: mss2: Fix buffer overflow. [13:37:58 CET] <cone-054> ffmpeg 03Reimar Döffinger 07master:45fa03b1f9b0: mjpegdec: Do not assume unused plane pointer are NULL. [13:37:58 CET] <cone-054> ffmpeg 03Reimar Döffinger 07master:4dd4d5353130: Document and validate AVFrame plane pointers. [14:10:47 CET] <kierank> atomnuker: ping [14:11:19 CET] <atomnuker> kierank: pong? [14:11:37 CET] <atomnuker> what's up? [14:19:40 CET] <kierank2> kieran@ubuntu:~/mpv-build$ ./mpv/build/mpv ~/ffmpeg/trailer.avi -lavfi-complex='[aid1] asplit [t1] [ao] ; [t1] showvolume [t2] ; [vid1] [t2] overlay [vo]' [14:19:59 CET] <kierank2> I get [14:19:59 CET] <kierank2> Error parsing option lavfi-complex (option not found) Setting command line option '--lavfi-complex=[aid1] asplit [t1] [ao] ; [t1] showvolume [t2] ; [vid1] [t2] overlay [vo]' failed. [14:21:04 CET] <durandal_170> what mpv version is that? [14:21:14 CET] <durandal_170> old release? [14:21:33 CET] <kierank2> mpv 0.15.0-git-d1d6257 (C) 2000-2016 mpv/MPlayer/mplayer2 projects built on Sun Feb 28 13:09:14 GMT 2016 [14:21:53 CET] <kierank> mpv 0.15.0-git-d1d6257 (C) 2000-2016 mpv/MPlayer/mplayer2 projects [14:21:53 CET] <kierank> built on Sun Feb 28 13:09:14 GMT 2016 [14:22:12 CET] <durandal_170> i guess you need git one, latest version [14:29:19 CET] <kierank> ok it works with git [14:44:43 CET] <cone-054> ffmpeg 03Roman Ryltsov 07master:af2568a675a7: avformat/Makefile: Fixed missing rawutils.o reference (required by movenc.c) [14:52:58 CET] <Daemon404> michaelni, https://github.com/golang/go/issues/14522 this image decodes wrong in ffmpeg too [14:53:03 CET] <Daemon404> in case you are interested [14:53:24 CET] <Daemon404> im not sure if its the jpeg's fault, or if it uses some obscure feature only libjpeg and ms's jpeg decoder can decode (and maybe apple's) [14:58:10 CET] <cone-054> ffmpeg 03Derek Buitenhuis 07master:1c9215e580b6: lavf/mp3: Properly check return values of seeks and reads while reading the header [15:15:00 CET] <kierank> durandal_170: can you make volume like this? https://wiki.videolan.org/File:VLC-visualeffect.png/ [15:19:02 CET] <atomnuker> kierank: showfreqs does more or less that: https://0x0.st/8O0.jpg [15:19:21 CET] <kierank> I mean with the green and yellow colours [15:19:24 CET] <kierank> at the moment it's a fixed colour on the bars [15:28:02 CET] <durandal_170> kierank: why you need that? I guess it just picks some random frequencies to show or it averages them somehow [15:28:48 CET] <kierank> I mean the colours [15:29:09 CET] <kierank> maybe I will send a patch to use the actual colours [15:34:00 CET] <durandal_170> i you mean volume colour to be like gradient? [15:34:09 CET] <durandal_170> kierank: ^ [16:17:09 CET] <kierank> Yes [17:19:16 CET] <cone-054> ffmpeg 03Timothy Gu 07master:222e6da605ea: x86/vf_blend: Add SSE2 optimization for divide [17:20:24 CET] <cone-054> ffmpeg 03Timothy Gu 07master:bbf7500df99c: LICENSE: Thorough editing [19:01:21 CET] <cone-054> ffmpeg 03Michael Niedermayer 07master:c6f4720b8664: avcodec/mjpegdec: Fix decoding slightly odd progressive jpeg [19:14:36 CET] <Daemon404> michaelni, what exactly was wrong/odd with the file? [19:15:45 CET] <michaelni> that not all passes reached Al=0, but i dont think jpeg requires that [19:16:05 CET] <Daemon404> interesting [20:05:18 CET] <cone-054> ffmpeg 03Paul B Mahol 07master:2ad1c87bb260: avfilter/vf_vectorscope: add color5 mode, mode like color but with higher saturation [20:06:43 CET] <cone-054> ffmpeg 03Rostislav Pehlivanov 07master:5cc53c2e530d: vc2enc: cache bits per quantizer, calculate wasted bits [20:06:44 CET] <cone-054> ffmpeg 03Rostislav Pehlivanov 07master:fc1d3cbfdc66: vc2enc: use 32 bits for quantized coefficients LUT [20:06:45 CET] <cone-054> ffmpeg 03Rostislav Pehlivanov 07master:0a2adf0f47ce: vc2enc: carry over quantization index across frames as a starting point [20:06:46 CET] <cone-054> ffmpeg 03Rostislav Pehlivanov 07master:6e5c6d61bdda: vc2enc: clip and warn when user bitrate set too low [20:06:47 CET] <cone-054> ffmpeg 03Rostislav Pehlivanov 07master:2f19583911eb: 2enc: clip and warn when user bitrate set too low [20:06:48 CET] <cone-054> ffmpeg 03Rostislav Pehlivanov 07master:bbcd5e99c303: vc2enc: allocate the DWT context with the current plane size [20:06:49 CET] <cone-054> ffmpeg 03Rostislav Pehlivanov 07master:e7345abe052b: vc2enc: redistribute leftover bytes [20:08:00 CET] <atomnuker> grr, why does copying commit messages always stip the first 2 chars [20:09:07 CET] <ubitux> forgot to enter insert mode? [20:09:55 CET] <ubitux> 'c' seems to trigger insert mode when in visual mode [20:10:28 CET] <atomnuker> seems I did [20:10:57 CET] <atomnuker> oh well, it's in the middle of the commits, anyone with basic pattern recognition skills knows what it touches [20:26:23 CET] <jamrial> atomnuker: make sure to backport the commits that fix crashes or wrong output to the 3.0 branch [20:31:25 CET] <atomnuker> jamrial: it'll be a bit difficult to do it directly since 2f195839 needs 2 more arguments (NULLs), but I'll try [20:35:14 CET] <kierank> durandal_170: ping [20:41:09 CET] <ubitux> michaelni: i have random mb glitches with msmpeg4 video: http://b.pkh.me/msmpeg4-mb-glitch.png [20:41:20 CET] <ubitux> i don't know if it's an encoding error though [20:41:52 CET] <ubitux> does it ring a bell or i should open a ticket? [20:43:06 CET] <michaelni> ubitux, probably encoding error (too low qscale) but i might miss-guess [20:43:38 CET] <ubitux> how can i check that? [20:44:02 CET] <atomnuker> looks like the DC coefficient is incorrect [20:45:03 CET] <michaelni> ubitux, are there any warnings during encoding ? [20:45:15 CET] <ubitux> i didn't encode the file [20:45:57 CET] <michaelni> are there any errors during decoding and how does it look with the binary decoder vfw or whatever? [20:46:00 CET] <ubitux> i uncommented ERROR_DETAILS in libavcodec/msmpeg4dec.c but it didn't raise anything either [20:46:20 CET] <michaelni> it all sounds like too low QP [20:46:37 CET] <michaelni> msmpeg4 cannot increase the QP like other codecs can [20:46:57 CET] <michaelni> so when theres a contrasty edge bad things happen at low QP and intra MBs [20:47:16 CET] <michaelni> you could check the QP used [20:47:21 CET] <michaelni> -debug 1 probably shows it [20:48:01 CET] <ubitux> qp:2 [20:48:19 CET] <michaelni> thats too low IIRC for some patterns [20:49:15 CET] <ubitux> ok; it's curious that this file was distributed, because these patterns are kind of common in the whole video [20:49:31 CET] <ubitux> it often happens in very high contrast part of the video [20:49:38 CET] <ubitux> like black on white (eyes etc) [20:49:49 CET] <michaelni> yes thats the too low qp issue you describe [20:49:56 CET] <ubitux> ok [20:56:05 CET] <ubitux> http://ubitux.fr/pub/pics/msmpeg4-mb-glitch-0.png http://ubitux.fr/pub/pics/msmpeg4-mb-glitch-1.png http://ubitux.fr/pub/pics/msmpeg4-mb-glitch-2.png http://ubitux.fr/pub/pics/msmpeg4-mb-glitch-3.png [20:56:26 CET] <durandal_170> kierank: pong, ping durandal_1707 next time, that's my phone [20:57:26 CET] <kierank> ok [20:57:30 CET] <durandal_170> wm4: can ass draw random antialiased lines? [20:57:41 CET] <kierank> durandal_1707: how does synchronisation between video and overlay work in lavfi? [20:57:46 CET] <kierank> where does the logic happen to match pts [20:58:12 CET] <durandal_170> kierank: inside framesync.c [20:58:19 CET] <durandal_170> is there something wrong? [21:00:11 CET] <durandal_170> framesync will sync to same pts, it may duplicate frames, or keep them in memory until it finds one it needs [21:00:27 CET] <kierank> that's what I'm worried about [21:01:00 CET] <kierank> I don't understand how buffering will work [21:02:02 CET] <durandal_170> framesync itself will drop frames when its increases internal queue [21:02:38 CET] <kierank> that scares me [21:03:18 CET] <durandal_170> you should not worry if audio pts match video [21:03:33 CET] <kierank> I am just doing video + subtitle [21:03:49 CET] <kierank> but I don't think it'll do what I want [21:06:20 CET] <kierank> Let's say I have video frame with PTS n and subtitle with PTS n [21:06:24 CET] <kierank> then I continue with video n+1, n+2 but I don't get a subtitle until n+5 [21:06:37 CET] <kierank> what will it do? [21:07:30 CET] <durandal_170> you mean with subtitle filter and overlay? [21:08:00 CET] <kierank> no I have my own bitmaps [21:08:40 CET] <kierank> the dvbsub decode goes via my own pipeline [21:10:55 CET] <durandal_170> if you do not give another frame to overlay filter it will wait for bitmap [21:11:31 CET] <kierank> you have no way of knowing latency [21:15:04 CET] <durandal_170> by default it will keep up to 64 frames in queue [21:15:43 CET] <durandal_170> if nothing appears, all frames are dropped iirc [21:16:11 CET] <durandal_170> until right one appears [21:28:45 CET] <wm4> durandal_170: ass can draw lines, yes [21:28:59 CET] <wm4> at least I'm pretty sure it does [21:29:06 CET] <durandal_170> wm4: function? [21:29:16 CET] <wm4> durandal_170: why does vf_overlay need a queue??? [21:29:29 CET] <wm4> it doesn't have a line draw function, but a polygon rasterizer [21:30:54 CET] <durandal_170> wm4: it have queue because framesync have it, you can setup framesync to not do any pts syncing [21:31:11 CET] <wm4> I mean why would syncing need a queue [21:31:21 CET] <wm4> you'd only need 2 buffered images per input? [21:31:34 CET] <wm4> (at most) [21:32:11 CET] <durandal_170> ask your friend Nicolas :-P [21:35:10 CET] <kierank> problem is the latency is undefined [21:35:25 CET] <kierank> so you have no idea when to present your frame [21:36:23 CET] <kierank> is there any way I can present frames together to libavfilter? [21:36:29 CET] <kierank> so I can say overlay X onto Y [21:37:07 CET] <durandal_170> if they have same pts, sure [21:37:20 CET] <kierank> yes but I have gaps [21:37:23 CET] <kierank> so how do I stop that [21:37:37 CET] <kierank> I just want data x overlaid on data y [21:37:47 CET] <kierank> no buffering, no pts syncing and all that stuff [21:38:31 CET] <wm4> didn't vf_overlay originally strictly sync to the first input [21:38:55 CET] <durandal_170> it still does, iirc [21:39:01 CET] <wm4> so it'd output the frame from input 1, overlayed with whatever happens to be in the other ones [21:39:41 CET] <kierank> pfftg [21:39:45 CET] <kierank> might have to write my own overlay then [21:39:47 CET] <durandal_170> overlay needs 2 frames [21:39:59 CET] <kierank> yes for no reason [21:40:05 CET] <kierank> I have data x that needs to overlay on data y [21:40:08 CET] <kierank> why should I buffer [21:40:56 CET] <durandal_170> i will look can it be done with current framesync, currently busy writting antialiased lines drawing [21:41:12 CET] <wm4> frame scheduling could become very complicated if no buffering has to be guaranteed, because how would it know the next frame on input 2 has the required pts, or a higher pts [21:41:23 CET] <kierank> and that's the problem with vfr [21:41:49 CET] <wm4> well most vfr things actually come with frame durations [21:41:54 CET] <wm4> just not ffmpeg in general [21:42:04 CET] <wm4> which makes vfr much harder [21:42:23 CET] <durandal_170> lavfi does have frame durations i used it [21:42:33 CET] <kierank> is there a way to manually push frames to the filter [21:42:35 CET] <wm4> (libavformat's guessed and wrong frame durations don't make ti easier) [21:43:21 CET] <durandal_170> av_frame_get_pkt_duration(out) [21:43:58 CET] <durandal_170> kierank: directly, without buffersrc? no [21:44:12 CET] <kierank> can I avoid this unnecessary framesync? [21:44:26 CET] <kierank> it adds latency for no reason [21:44:42 CET] <kierank> and worse still latency I can't measure [21:49:08 CET] <durandal_170> try experimenting setting sync to 0 for one of streams in libavfilter/dualinput.c:87 [21:49:29 CET] <durandal_170> actually 59th line [21:50:06 CET] <kierank> hmmm [21:51:11 CET] <kierank> I guess I have to write a function that guesses the latency [21:51:46 CET] <kierank> but I still don't know how to simulate missing teletext [21:53:28 CET] <kierank> durandal_170: so does it expect ABABABABAB [21:53:43 CET] <kierank> assuming A and B have same PTS [21:54:44 CET] <durandal_170> yes, i think so [21:55:10 CET] Action: rcombs makes stream with one frame in the middle and then nothing for the whole rest of the duration [21:55:20 CET] <rcombs> (this frame lasts 2 seconds) [21:55:26 CET] <rcombs> pls make sure you don't fail on that case [21:55:39 CET] <rcombs> (I've been bitten by that sort of thing before) [22:01:52 CET] <cone-054> ffmpeg 03Rodger Combs 07master:3617e69d50dd: lavf/mov: fix sidx with edit lists [22:01:53 CET] <cone-054> ffmpeg 03Rodger Combs 07master:22dbc1caaf13: lavf/mov: downgrade sidx errors to non-fatal warnings; fixes trac #5216 [22:25:01 CET] <kierank> durandal_1707: does vf_showvolume support arbitrary channel maps? [22:25:14 CET] <kierank> i.e does it work if I just provide 12 channels or whatever? [22:25:20 CET] <kierank> does it care what the map is? [22:26:31 CET] <durandal_170> currently it accepts only known channel layouts, but i can change that [22:27:37 CET] <wm4> can't see a reason why it'd care about the layout... [22:28:18 CET] <durandal_170> to draw channel names [22:28:47 CET] <wm4> ah [22:43:18 CET] <ubitux> so... how do we proceed for the merge of codecpar? [22:45:30 CET] <kierank> ubitux: you don't let morons like carl ruin the project [22:45:34 CET] <kierank> and bring derek back [22:45:53 CET] <ubitux> ? [22:46:17 CET] <ubitux> Daemon404 is here [22:50:20 CET] <ubitux> anyway, i'm happy to help if someone drives the merge and we are at least 2 working on the merge itself [22:50:43 CET] <ubitux> i can allocate time for this, so if anyone is up to... [22:50:50 CET] <durandal_170> its same as most boring thing ever [22:52:58 CET] <ubitux> durandal_170: well, there are many fate changes [22:53:49 CET] <durandal_170> can't it be done with sed? [22:53:59 CET] <ubitux> wanna try? [22:55:14 CET] <durandal_170> ubitux: wanna finish nlmeans? [22:55:20 CET] <ubitux> if you look at the commit, you'll see that the codec->time_base field is replaced by setting the st->avg_frame_rate [22:55:47 CET] <ubitux> and i wonder how much things this will influence [22:55:55 CET] <ubitux> especially given that we still have r_framerate [22:56:02 CET] <ubitux> durandal_170: yes [22:56:53 CET] <durandal_170> tell others what branch on github we can use? [22:58:41 CET] <cone-054> ffmpeg 03Raymond Hilseth 07master:20e4863ab14a: avformat/file: enable file_move() without unistd.h [22:58:42 CET] <cone-054> ffmpeg 03Raymond Hilseth 07master:c66a6369e488: avformat/dashenc: Enable dash output to work when the output isn't a local file [23:04:55 CET] <cone-054> ffmpeg 03Marton Balint 07master:4840effe4222: avformat/mov: merge mov_read_custom functions [23:04:56 CET] <cone-054> ffmpeg 03Marton Balint 07master:e22bd239c046: avformat/mov: do not leak memory on ffio_read_size failure [23:17:27 CET] <cone-054> ffmpeg 03Michael Niedermayer 07master:149250720878: ffmpeg_vdpau: Remove unused variable [23:18:41 CET] <cone-054> ffmpeg 03Paul B Mahol 07master:65cc3915db66: avfilter/avf_showvolume: support unknown channel layouts too [23:40:34 CET] <cone-054> ffmpeg 03Michael Niedermayer 07master:3e42c1128fe7: avcodec/libzvbi-teletextdec: Remove unused variable [23:53:41 CET] <durandal_170> kierank trolling smpte :) [00:00:00 CET] --- Mon Feb 29 2016

1 0

ffmpeg.log.20160228
by burek 29 Feb '16

29 Feb '16

[00:43:57 CET] <postmodern> is it possible to join multiple mkv files together which have different aspect ratios and resolutions? [00:44:28 CET] <wiak> would think so yes [00:44:53 CET] <wiak> but dunno [01:00:53 CET] <postmodern> hmm, trying to figure out how i can tell the player that the aspect ratio changes in the middle of the mkv [01:01:26 CET] <postmodern> mpv seems to default to using the container aspect ratio, which stretches or squeezes the image [01:01:39 CET] <postmodern> first mkv is 16:9 and the others are 4:3 [01:01:45 CET] <JEEB> make sure the parameter sets are taken into mention [01:01:54 CET] <JEEB> poke #mpv for mpv specifics [02:15:15 CET] <Nanashi> Hahahahaha I found it. It contained gamma metadata which made it a little brighter than the screenshots I find online since they have it stripped. [02:15:39 CET] <Nanashi> (pains me as a man of consistency though) [03:30:15 CET] <logic_> hello [03:30:21 CET] <logic_> i need some help [03:31:27 CET] <logic_> ffmpeg -i LJ3.wmv -vcodec copy -acodec copy LJ3.mkv [03:31:43 CET] <logic_> how do i convert the audio to AAC 128kb? [03:31:50 CET] <logic_> instead of copying the audio stream [03:38:16 CET] <Nanashi> -c:a aac -b:a 128k [03:39:05 CET] <Nanashi> more information: https://trac.ffmpeg.org/wiki/Encode/AAC [05:01:54 CET] <kevmitch_> according to http://pastebin.com/Bay9wetL [05:02:03 CET] <kevmitch_> ignore that [07:05:34 CET] <Jesperhead> Hello all, trying to record my desktop with ffmpeg using the test example: ffmpeg -video_size 1366x768 -framerate 25 -f x11grab :0.0 output.mp4 only to receive a null error stating "Requested output format 'x11grab' is not a suitable output format" I appreciate any assistance while I continue googling this. [07:29:48 CET] <Jesperhead> additional note I omitted: ":0.0: Invalid argument" is one line below the earlier noted error message [07:38:15 CET] <Jesperhead> ffmpeg's suggested string was not suitable for my linux distribution [07:38:36 CET] <Jesperhead> i tried a test string from arch's wiki and all appears to work. Thank you all for.. listening? [08:17:15 CET] <LJHSLDJH1DLJH> how to know the codecs info of a .webm file under ubuntu? [08:18:07 CET] <furq> ffprobe [08:18:28 CET] <LJHSLDJH1DLJH> I can't seek (forward / backward) [08:18:50 CET] <LJHSLDJH1DLJH> tried to cut but this is the error I get pastebin.com/pK9CPaq7 [08:19:30 CET] <furq> av_interleaved_write_frame(): No space left on device [08:20:43 CET] <LJHSLDJH1DLJH> furq: yeah but it doesn't make any sense to me [08:21:01 CET] <LJHSLDJH1DLJH> what that supposed to mean and how to fix it? [08:21:23 CET] <furq> it means your disk is full [08:26:01 CET] <LJHSLDJH1DLJH> stupid me :(( [08:26:05 CET] <LJHSLDJH1DLJH> thanks furq [08:26:26 CET] <LJHSLDJH1DLJH> but still the same problem of not able to play this file properly [08:26:59 CET] <LJHSLDJH1DLJH> I actually was able to play with mplayer from command line but it crashes at certain point [08:27:11 CET] <LJHSLDJH1DLJH> then it's possible to forward or backword [12:51:16 CET] <Polochon_street> hi! I'm trying to decode songs into an array, but sometimes I have extra zeroes in it, and I don't know why... [12:51:40 CET] <Polochon_street> I'm allocating an array of size int8_t, as described here http://pastebin.com/DReryLar [12:52:30 CET] <Polochon_street> I use a while(av_read_frame(context, &avkpt)), and sometimes, it seems that I receive « extra frames » (I don't know why), and I must realloc my sample array [12:53:31 CET] <Polochon_street> I think that's where my extra zeros come from, but I don't know how to avoid it... How can I have more samples than duration*sample_rate*nb_bytes_per_samples*channels/AV_TIME_BASE ? [12:54:40 CET] <Polochon_street> (here's the full code: https://github.com/Polochon-street/bliss/blob/63bede0e4d6f0ab0caa22ab49f1f7…) [15:21:19 CET] <Polochon_street> okay, I solved my problem. Turns out getting the number of samples via a duration computation is good to approximate, but not to determine the exact number [15:23:46 CET] <grublet> Polochon_street: afaik the duration thing will always be innacurate to some degree [17:33:56 CET] <YaMoonSun> I should be able to record my screen and main audio output using ffmpeg and output as HEVC right? [17:41:41 CET] <kepstin_> YaMoonSun, in theory yeah, but you have to have a really fast computer or use really low-quality settings to get realtime hevc encoding. [17:45:57 CET] <YaMoonSun> I was using an application on ubuntu once that allowed me to record the screen and it would output it as a massive .avi, I think it was muxing the screen capture. Can I do that and then just convert to hevc later? [17:46:20 CET] <YaMoonSun> windows currently [17:47:29 CET] <furq> sure [17:48:55 CET] <kepstin_> couple options - if you've got a lot of disk space, you could use a video codec like ffvhuff; if not, try x264 with a fast profile; could also try a hardware encoder (nvenc?) and just use a really high bitrate. [17:50:02 CET] <furq> if you want a massive uncompressed screen capture then use rawvideo [17:50:45 CET] <kepstin_> rawvideo can be fun tho; your bottleneck is often the speed of your hard drive writing :) [17:51:04 CET] <YaMoonSun> If I use that to record let's say an hour, what do you think the output size will be? [17:51:34 CET] <furq> depends on the resolution [17:51:40 CET] <YaMoonSun> I've got the samsung 840 evo, speed is no problem, but size is 250gb [17:51:41 CET] <furq> unless "massive" is specific enough [17:51:53 CET] <YaMoonSun> 1080p [17:52:51 CET] <furq> what framerate [17:53:36 CET] <furq> at 60fps that'd be close to 700GB [17:53:41 CET] <furq> unless i've forgotten how to work this out [17:53:57 CET] <furq> assuming you use yuv420, rgb would be even bigger [17:54:18 CET] <YaMoonSun> well ffs [17:54:44 CET] <YaMoonSun> I'd need x4 1tb drives on raid 0 [17:54:48 CET] <furq> you could use a fast hevc profile but then there isn't much point using hevc over avc [17:55:24 CET] <YaMoonSun> Quite disappointing. [17:55:30 CET] <YaMoonSun> Thanks for the input [17:55:46 CET] <furq> there are lossless codecs if you specifically want to use hevc [17:57:23 CET] <furq> but unless you have a specific requirement to use hevc then i'd just stick with x264 [17:57:37 CET] <furq> x265 is overrated anyway [17:58:34 CET] <YaMoonSun> Not even [17:59:25 CET] <tp__> its not overrated for 4K [18:13:16 CET] <anddam> i have a 1280x720 video that I want to rescale vertically to a 480p size, I tried -vf scale=-1:480 as in https://gist.github.com/anddam/3ccf9893b7a1b2d38931 but I'm getting "Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height" [18:13:29 CET] <anddam> how can I check what the incorrect parameter is? [18:13:48 CET] <BtbN> read what it outputs [18:13:49 CET] <furq> [libx264 @ 0x7fb2a2830e00] width not divisible by 2 (853x480) [18:43:07 CET] <anddam> oh, that line I missed [18:43:51 CET] <anddam> actually I didn't _need_ 480p but the 720 point was a bit higher for an old ipad that was skipping frames so I wanted to scale it [18:47:00 CET] <anddam> I went for a close 864:486 [18:47:16 CET] <anddam> thanks [18:50:52 CET] <jackhold> hej anyone that could help me with a little problem i got trying to send udp stream and capture pictures every 30sek from a webcam?? [18:52:11 CET] <anddam> mmm "[mp4 @ 0x7fb2e5000000] Application provided invalid, non monotonically increasing dts to muxer in stream 2: 575609 >= 513977 av_interleaved_write_frame(): Invalid argument" [18:52:57 CET] <anddam> I figure that's stream in input file [18:54:25 CET] <firewated> i had a similar problem with an iPad, just re-encoding the audio to 2 channel aac and copying the video stream into an mp4 gave me smooth playback [18:54:57 CET] <YaMoonSun> -i "Input.mov" -vf scale=-2=480 -c:v libx264 -b:v 2M -c:a copy "Output.mp4" ? [18:55:42 CET] <anddam> what does -2 mean in the scale argument? [18:55:56 CET] <furq> same as -1 but mod2 [18:56:27 CET] <anddam> furq: I cannot find mod2 in the man page [18:56:51 CET] <anddam> firewated: I'll try, why 2 channels? [18:57:14 CET] <anddam> I got a lot of [18:57:16 CET] <anddam> [mp4 @ 0x7f9343820c00] Non-monotonous DTS in output stream 0:1; previous: 13412354, current: 13412344; changing to 13412355. This may result in incorrect timestamps in the output file. [18:57:45 CET] <anddam> this is the audio stream, I worked around the previous error on stream 2, that was subtitle, by just stripping it out [18:58:52 CET] <YaMoonSun> Sounds like it's being a dingleberry. Are you using the latest build? [18:59:06 CET] <firewated> I can't remember if there was a specific reason, does the iPad have more than 2 speakers? [18:59:40 CET] <firewated> Also, does the mp4 container event support DTS? [18:59:46 CET] <firewated> even* [19:02:15 CET] <jackhold> Why do this just overwrite the output and not auto incrementing?? ffmpeg -v info -r 25 -s 1280x720 -f video4linux2 -vcodec mjpeg -i /dev/video1 -f image2 -r 1/30 ~/indput/out%20d.png -vcodec copy -f mjpeg udp://test.eu:33333 [19:05:37 CET] <anddam> YaMoonSun: nope [19:05:54 CET] <anddam> firewated: I think the iPad has just the one speaker [19:06:09 CET] <firewated> So why do you want DTS audio [19:10:06 CET] <anddam> I don't, I don't even know what that is [19:10:37 CET] <anddam> I'm just copying the audio stream to avoid recoding [19:13:18 CET] <firewated> try this: ffmpeg -i in.mkv -c:s mov_text -ac 2 -b:a 320K -c:v copy out.mp4 [19:18:26 CET] <eksrow> Hi, i'm using the overlay filter to slide an image across a video(with overlay=x=-'(t*20) - 50') and it's working great. but the animation looks 30fps ish while the framerate of the video itself is 60. is it possible to get this animation to 60? [19:44:28 CET] <kepstin> eksrow: that should be recalculated every frame. Perhaps make sure both inputs to the overlay filter are the same framerate? [20:09:39 CET] <eksrow> kepstin: good to know it's possible, i'l keep trying. each input has -r 60, that should be correct right? [20:12:01 CET] <anddam> firewated: lots of those "Non-monotonous DTS in output stream 0:1; " then again the error "Application provided invalid, non monotonically increasing dts to muxer in stream 2: 575609 >= 513977 av_interleaved_write_frame(): Invalid argument" [20:13:19 CET] <firewated> can you post the full output from ffmpeg, i don't see how DTS is getting to the output, it should be getting re-encoded [20:21:08 CET] <anddam> sure, give one moment [20:23:48 CET] <anddam> it's _very_ long [20:23:59 CET] <anddam> I figure you just want to see the start and the end [20:24:16 CET] <firewated> sure, in a gist [20:28:53 CET] <anddam> https://gist.github.com/anddam/3ccf9893b7a1b2d38931 updated [20:29:47 CET] <anddam> notice the massive "[mp4 @ 0x7fb0bb01fa00]" starting line cut at L105 [20:30:58 CET] <firewated> hmm your input audio is aac, not sure why there's references to DTS at all [20:33:34 CET] <furq> firewated: decoding timestamp [20:34:36 CET] <firewated> oh, right [20:34:51 CET] <firewated> ffmpeg version is recent too, not sure [20:35:03 CET] <furq> anddam: try -fix_sub_duration as an input option [20:39:42 CET] <firewated> and you probably don't need to re-encode the audio either as it's already aac [20:45:02 CET] <anddam> "ffmpeg -y -fix_sub_duration -i in.mkv -c:s mov_text -c:a copy -c:v copy out.mp4" results in the same error [20:45:10 CET] <anddam> [mp4 @ 0x7f9159802600] Application provided invalid, non monotonically increasing dts to muxer in stream 2: 573373 >= 513977 [20:45:18 CET] <anddam> av_interleaved_write_frame(): Invalid argument [20:45:58 CET] <anddam> I'm halfway scaling the video anyway [20:46:49 CET] <firewated> do you also still get the timestamp out of range messages? [20:49:58 CET] <anddam> not with the rescale, I dropped the sub stream, copied the audio and rescaled video using libx264, [20:51:36 CET] <firewated> may be because of the sub stream [20:55:30 CET] <jookiyaya> anybody here? mirc [21:10:34 CET] <anddam> what does that even mean? [00:00:00 CET] --- Mon Feb 29 2016

1 0

ffmpeg-devel.log.20160227
by burek 28 Feb '16

28 Feb '16

[00:00:16 CET] <Compn> or volume level graph kinda like ffplay audio file [00:00:25 CET] <Compn> no idea [00:03:01 CET] <wm4> Compn: lol no [00:05:01 CET] Action: wm4 stares at vf_datascope output [00:05:03 CET] <wm4> whatever that is [00:07:03 CET] <durandal_1707> hex numbers of pixels [00:07:30 CET] <wm4> which ones? [00:08:10 CET] <durandal_1707> each block is one pixel [00:09:01 CET] <wm4> the video resolution is the same in/out, there are not enough blocks to show all pixels? [00:09:02 CET] <durandal_1707> components are one bellow other [00:09:52 CET] <durandal_1707> yes, so there is x/y to set offset [00:10:46 CET] <durandal_1707> you could increase output size but it will be slow and you do not have so big display [00:12:05 CET] <wm4> how about... interactive zooming? [00:13:28 CET] <durandal_1707> idea is to use with overlay, to mark what pixels are under scope [00:14:13 CET] <durandal_1707> with drawbox for example [00:14:17 CET] <wm4> allow interactive selection of a video region, and show its contents in a separate overlaid rectangle (well that's probably _way_ beyond scope of lavfi) [00:15:06 CET] <durandal_1707> its was scope of lavfi to provide interactive control [01:31:06 CET] <cone-565> ffmpeg 03Mats Peterson 07master:9a2778082121: lavf/movenc: Add palette to video sample description [02:42:33 CET] <michaelni> we need a backup mentor for "TrueHD encoder" [02:44:17 CET] <atomnuker> michaelni: I'll ask Claudio [02:46:48 CET] <michaelni> please do and thanks! [02:46:57 CET] <atomnuker> okay, wrote to him, but if anyone else wants to be a backup mentor feel free to do so [03:06:44 CET] <cone-565> ffmpeg 03Mats Peterson 07master:6aac43f1805d: lavf/matroskadec: Process QuickTime palette per track [03:10:19 CET] <Shiz> it's heere [04:26:22 CET] <cone-565> ffmpeg 03Vicente Olivert Riera 07master:8514fb6b987c: mips: improve detection of ISAs, FPU and ASEs (DSP, MSA) [04:26:23 CET] <cone-565> ffmpeg 03Vicente Olivert Riera 07master:5156578d1f48: mips: do not disable any feature for generic cores [05:02:31 CET] <jamrial> Timothy_Gu or whoever: all fate slots seem to be stuck since a day or so ago [05:03:10 CET] <jamrial> i just ran mine and noticed it froze while sshing [05:04:04 CET] <jamrial> i fear pretty much every fate client will have to be unstuck manually [05:04:34 CET] <jamrial> michaelni, ubitux, nevcairiel et all: can you check your clients to confirm that? [05:49:32 CET] <rcombs> people wanted a TrueHD encoder? [05:51:48 CET] <Compn> encoding to bluray ? [06:13:36 CET] <Timothy_Gu> jamrial: i can't seem to reproduce it [06:15:06 CET] <jamrial> well, my client here froze while sshing and i had to kill the process. then i checked fate and most clients last ran a day ago, even those that usually run every couple hours [06:15:15 CET] <jamrial> so i assume the same happened to them [06:19:25 CET] <drv> it looks like i have a similar situation on my client [06:19:32 CET] <drv> `ssh -T fate(a)fate.ffmpeg.org` is hung [06:38:41 CET] <jamrial> yeah [06:40:14 CET] <Timothy_Gu> :/ [06:45:38 CET] <Timothy_Gu> jamrial: can you test again? [06:45:53 CET] <Timothy_Gu> note that when executing directly the ssh command is supposed to hang [06:46:04 CET] <Timothy_Gu> but it should not hang on EOF [06:46:14 CET] <Timothy_Gu> ... which it seems to be [07:25:33 CET] <jamrial> Timothy_Gu: happened again [08:28:21 CET] <Timothy_Gu> that's so weird [11:14:26 CET] <cone-641> ffmpeg 03Clément BSsch 07master:f9987464cff3: sws/yuv2rgb: avoid a few ub on signed left shifts [11:14:26 CET] <cone-641> ffmpeg 03Clément BSsch 07master:1e7a37f0a07f: sws/yuv2rgb: clarify precision of coeff and offset for mmx code [11:26:00 CET] <ubitux> Timothy_Gu: i confirm all fate instances still stall [11:28:11 CET] <nevcairiel> mine dont, but i dont use openssh [11:28:44 CET] <nevcairiel> results dont seem to appear on the site either way though [13:13:36 CET] <cone-641> ffmpeg 03Michael Niedermayer 07master:bdf7093bd0cb: avcodec/utils: Check all data[] pointers in video_get_buffer() not just the first [13:13:37 CET] <cone-641> ffmpeg 03Michael Niedermayer 07master:d39b770aa276: avcodec/utils: Check that the video data[] arrays are NULL on the input to get_buffer_internal() [13:18:20 CET] <cone-641> ffmpeg 03Kieran Kunhya 07master:0096453f70c4: cfhd: reallocate internal buffers on format change. [13:21:48 CET] <kierank> hmm should have been under your name, sorry BBB [13:23:07 CET] <BBB> no worries [13:23:12 CET] <BBB> as long as its fixed [13:23:34 CET] <kierank> I still get some crashes with certain thread counts [13:38:40 CET] <BBB> if you can file more specific bugs, Im happy to help [13:39:06 CET] <kierank> I'll add the new alpha support first [13:39:14 CET] <kierank> then I'm sure that fuzzing guy will submit more [14:05:53 CET] <michaelni> Timothy_Gu, others, has the fate stuckness been resolved ? it seems sometimes data goes through [14:08:03 CET] <michaelni> Timothy_Gu, i see some ... /node /home/fate/mongo-experiments/process/migrate.js ... stuff from 26th on the server, that date is close to when the problems started ... [14:09:08 CET] <michaelni> with see i mean in "ps aux" output [14:10:51 CET] <michaelni> ive apt-get updated the box but that didnt help, also no past updates match the time when the problem started [14:14:03 CET] <michaelni> note, i wont look into this further i know nothing about the new fate server, mongo or related stuff, just saying so noone waits/thinking iam working on this [14:21:34 CET] <cone-641> ffmpeg 03Kieran Kunhya 07master:8adbe26b909a: avcodec/cfhd: Add support for 12-bit RGBA. [14:22:55 CET] <michaelni> btw, if someone wants to look into the fate issue and needs command line access to the server / an account, contact me [15:19:40 CET] <kierank> durandal_1707: to play a file/stream and have live volume metering [15:24:31 CET] <durandal_1707> kierank: live volume metering? What's that? [15:24:59 CET] <kierank> durandal_1707: http://broadcastandfilm.com/products/Cinegy%20to%20launch%20version%209/Cin… [15:25:05 CET] <kierank> you see the way the volume is overlaid on the video? [15:25:29 CET] <kierank> or http://cdn.studiodaily.com/wp-content/uploads/2015/09/new-multiviewer-softw… [15:26:59 CET] <durandal_1707> kierank: showvolume, but its horizontal, I could add vertical mode [15:27:19 CET] <durandal_1707> It's just peak metering [15:27:43 CET] <kierank> can I test it on a file? [15:27:44 CET] <durandal_1707> do you need more sophisticated one? [15:27:57 CET] <durandal_1707> kierank, sure [15:28:57 CET] <durandal_1707> kierank, ffplay sucks so you need to use mpv [15:29:14 CET] <atomnuker> kierank: here's how it looks now: https://0x0.st/892.jpg [15:29:36 CET] <kierank> ah cool [15:29:38 CET] <kierank> durandal_1707: see pm [16:11:28 CET] <Timothy_Gu> michaelni: the mongo stuff commented out [16:13:29 CET] <Timothy_Gu> I suspected its that, but it worked a few days ago and I don't really understand how it stopped working... [16:26:36 CET] <cone-641> ffmpeg 03Clément BSsch 07master:653af9f18839: lavfi/ass: fix version check for sub_text_format option [16:30:27 CET] <Timothy_Gu> michaelni, ubitux, nevcairiel, drv: issue found and fixed [16:34:33 CET] <ubitux> it seems we don't need to restart our instances? [16:34:44 CET] <ubitux> they "unfreezed" [16:34:52 CET] <nevcairiel> mine didnt hang anyway, probably timed out or something [16:35:12 CET] <nevcairiel> but the results didnt show up [16:38:32 CET] <Timothy_Gu> ubitux: i killed the stalling processes [16:39:07 CET] <Timothy_Gu> nevcairiel: that's weird. the stall should be after the recording stage [16:39:29 CET] <michaelni> Timothy_Gu, great, thx [16:40:24 CET] <nevcairiel> looks like the failure left the lock file in place [16:42:12 CET] <Timothy_Gu> nevcairiel: ah [17:12:46 CET] <Compn> "twitter chats" [17:46:35 CET] <cone-641> ffmpeg 03Paul B Mahol 07master:e266d29978cd: avfilter/avf_showwolume: add orientation and step option [17:56:13 CET] <atomnuker> 2 hours, wow [18:26:50 CET] <Hot_Rod_> hello, got an issue, im using shareX which uses ffmpeg, i upgraded to win10 3 days ago, now i'm getting an error from ffmpeg, the shareX guys tell me this is an issue with ffmepeg and has been fixed, but i still have it and i installed the latest ffmpeg but get the error only with certain size screen captures [18:27:06 CET] <Hot_Rod_> if i capture small areas it works fine [18:27:21 CET] <Compn> paste the error to pastebin [18:27:28 CET] <Compn> but also probably bug reports go to #ffmpeg channel [18:28:21 CET] <Hot_Rod_> ok TY [19:47:43 CET] <durandal_1707> what's cineform raw bit? [20:00:32 CET] <BtbN> n [20:05:48 CET] <wm4> can someone tell Mats that the mailing list is not his diary [20:05:55 CET] <ubitux> :D [20:07:45 CET] <thardin> classic mats [20:10:33 CET] <JEEB> yeah, he's quite... verbose [20:13:47 CET] <durandal_1707> anybody writing key spill filter? [20:13:59 CET] <thardin> didn't he threaten to leave the list? [20:16:29 CET] <thardin> oh, does anyone know why mencoder is no longer in debian jessie? [20:18:19 CET] <ubitux> thardin: is mplayer in? [20:18:33 CET] <thardin> uh.. don't know [20:18:48 CET] <ubitux> iirc they stopped packaging it [20:18:50 CET] <thardin> this is on a friend's wondering [20:18:59 CET] <ubitux> because it was too annoying to have ffmpeg separated or some shit [20:19:26 CET] <nevcairiel> their mplayer" package is mplayer2 [20:19:27 CET] <ubitux> and probably related to libav incompat initially [20:26:00 CET] <JEEB> well, not sure if it's a bad thing that mencoder is no longer there [20:26:14 CET] <JEEB> you have both ffmpeg cli as well as mpv's encoding feature [20:27:08 CET] <ubitux> ffmpeg still can't produce vobsub though :° [20:27:48 CET] <ubitux> nor read them from dvd properly last i heard [20:28:06 CET] <JEEB> well for hardsubbing you can use mpv's encoding functionality I guess [20:28:16 CET] <JEEB> it's not perfect either, but not sure if it's worse than mencoder [20:28:25 CET] <wm4> mplayer is back in debian unstable [20:28:37 CET] <wm4> the real one [20:28:41 CET] <JEEB> that said most of my recollection of mencoder come from the time when it didn't handle b-frames at all [20:28:47 CET] <wm4> mencoder is also there [20:28:53 CET] <ubitux> JEEB: what if you just want to rip a dvd and mux its subs into a mkv? [20:29:14 CET] <wm4> last I checked mencoder produced completely broken mkv files [20:29:28 CET] <ubitux> maybe, but you can dump the vobsub and remux them with ffmpeg [20:29:30 CET] <ubitux> :D [20:29:37 CET] <JEEB> ubitux: in theory the subtitle track copying should work, no? [20:29:52 CET] <ubitux> but in practice we have nothing to read from dvd [20:29:52 CET] <JEEB> or is it broken [20:30:11 CET] <JEEB> and yeah, except for the IFOs or VOBs [20:30:30 CET] <ubitux> which contain subs meta etc, no? [20:31:13 CET] <wm4> $ file out.mkv [20:31:13 CET] <wm4> out.mkv: RIFF (little-endian) data, AVI, 1280 x 720, 23.98 fps, video: H.264 X.264 or H.264, audio: MPEG-1 Layer 3 (stereo, 48000 Hz) [20:31:24 CET] <wm4> well first I have to try to make it actually output mkv [20:31:31 CET] <nevcairiel> haha [20:32:56 CET] <ubitux> btw, is someone can provide me the dvd specs (especially the sub part) i'm actually very interested in it [20:33:12 CET] <wm4> ok, mencoder still outputs broken mkv files [20:33:21 CET] <wm4> it doesn't reorder PTS lol [20:33:50 CET] <JEEB> yeah, that reminds me of how it did mp4 [20:34:20 CET] <JEEB> reordering? is that something yummy? [20:34:22 CET] <wm4> writing gibberish that only mplayer can decode? [20:38:38 CET] <durandal_1707> atomnuker: is half of your mails missing on ml? [20:44:02 CET] <atomnuker> more than that [20:44:30 CET] <atomnuker> oh, a few more appeared [20:44:56 CET] <atomnuker> this is still ridiculous [21:23:16 CET] <nevcairiel> they came in delayed, but all here now [21:35:51 CET] <cone-797> ffmpeg 03wm4 07master:5d2c5e8bffed: vf_copy: exclude hwaccel formats [21:59:24 CET] <kierank> durandal_1707: ? [22:03:17 CET] <durandal_1707> kierank: smthing wrong? [22:04:01 CET] <kierank> 6:47 PM <"durandal_1707> what's cineform raw bit? [22:04:03 CET] <durandal_1707> also why you still have only + [22:04:35 CET] <durandal_1707> read some shit on Twitter [22:05:09 CET] <kierank> it's a different format [22:05:15 CET] <kierank> transform-type=2 [22:19:53 CET] <kierank> is there a way to do a deeper git blame [22:20:01 CET] <kierank> I need to find the commit GBRP12 was added [22:20:37 CET] <kierank> all I get are diego cosmetics [22:24:01 CET] <JEEB> I usually use git gui blame and it has an option to blame the base [22:24:08 CET] <JEEB> and you can go through that until you get where you want to get [22:30:23 CET] <kierank> where is this option [22:32:13 CET] <ubitux> -w is not enough? [22:34:20 CET] <wm4> I like blaming with gitk [22:34:34 CET] <kierank> no [22:34:38 CET] <kierank> not enough [22:35:38 CET] <kierank> because of the AV_ prefix commit [23:32:36 CET] <cone-833> ffmpeg 03Rodger Combs 07master:b426d6637031: lavc/Makefile: dnxhd demuxer depends on dnxhddata.o [23:33:38 CET] <cone-833> ffmpeg 03Rodger Combs 07master:a21a3c25dc79: probe TrueHD in MPEGTS [23:41:43 CET] <cone-833> ffmpeg 03Rodger Combs 07master:9f5baf90856f: lavc/aac_ac3_parser: avoid zeroing codec parameters if we haven't read a frame [23:41:44 CET] <cone-833> ffmpeg 03Rodger Combs 07master:f0ea536c47c8: lavc/aac_ac3_parser: reindent [00:00:00 CET] --- Sun Feb 28 2016

1 0

ffmpeg.log.20160227
by burek 28 Feb '16

28 Feb '16

[00:02:53 CET] <derekprestegard> looks like my split and stitch issue was due to the fact that Im dealing with 23.98fps content [00:03:16 CET] <kepstin> you mean 24000/1001 ? [00:03:21 CET] <derekprestegard> yes [00:03:28 CET] <kepstin> don't use the rounded fractional number if you can avoid it :) [00:03:33 CET] <derekprestegard> ;) [00:03:47 CET] <derekprestegard> I think our dev used 60.06, not sure -waiting on confirmation [00:03:56 CET] <derekprestegard> but the frame count matches exactly so Im good [00:04:22 CET] <derekprestegard> why is this necessary though? shouldnt ffmpeg be smart enough to figure all this out since Im specifying times in seconds?? [00:07:58 CET] <kepstin> derekprestegard: hard to say. It might be that when you're doing the final mux, maybe you could use one of the -vsync settings to force ffmpeg to recalculate all the frame timestamps based on constant framerate? [00:08:59 CET] <derekprestegard> well when it wasnt working we were seeing 40 additional frames [00:09:08 CET] <derekprestegard> confirmed were using 60.06006 [00:09:41 CET] <derekprestegard> so I think when we were using 60.0 sometimes it was picking up an extra frame [00:10:06 CET] <kepstin> you can use fractions as input to all the ffmpeg rate options, to get exact values... [00:10:21 CET] <kepstin> (modulo whatever the container supports, of course) [00:10:36 CET] <derekprestegard> these parameters are for -to and -ss [00:10:51 CET] <kepstin> oh, huh... [00:12:34 CET] <kepstin> if you used exactly '60' it should be always be giving you either 1339 or 1338 frames for a 24000/1001 fps stream, i think (it'll probably alternate a bit) [00:12:47 CET] <derekprestegard> yeah that makes total sense [00:13:41 CET] <kepstin> which shouldn't be a problem, as long as the duration of the last frame of the previous file is accounted for correctly when appending the next file [00:13:53 CET] <derekprestegard> which it wasnt [00:13:56 CET] <derekprestegard> we did like [00:14:04 CET] <derekprestegard> -ss 0 -i foo.mp4 -to 60 [00:14:10 CET] <derekprestegard> -ss 60 -i foo.mp4 -to 60 [00:14:14 CET] <derekprestegard> -ss 120 -i foo.mp4 -to 60 [00:14:32 CET] <derekprestegard> so we were picking up extra frames every now and then [00:14:42 CET] <derekprestegard> a little bit less than half the time [00:14:56 CET] <derekprestegard> (40 extra frames accumulated in 90 segments) [00:16:13 CET] <kepstin> 40 in extra frames in 5400 seconds of video? that's a rather close number to the expected number of drop frames :/ [00:16:17 CET] <derekprestegard> kepstin: assuming you meant 1438 / 1439 above, right? [00:16:29 CET] <kepstin> my calculations were not guaranteed to be exact :) [00:16:32 CET] <derekprestegard> rof [00:16:36 CET] <derekprestegard> rofl [00:16:43 CET] <derekprestegard> so is our solution reasonable? it definitely works [00:16:51 CET] <derekprestegard> or is there a better way to solve this issue? [00:17:28 CET] <kepstin> no idea. I'd probably do it by putting all the segments into mpegts containers, then concatenate them and write the final mp4 with ffmpeg with options to cause it to rewrite the timestamps with constant-fps [00:18:11 CET] <derekprestegard> would that result in ffmpeg dropping the erroneous frames? [00:18:32 CET] <derekprestegard> also, where does constant fps come into the equation? [00:18:39 CET] <kepstin> I'm not sure where your extra frames are coming from, tbh [00:19:54 CET] <kepstin> for segment cutting like that, you want to get any frame that hits the start time exactly, and not include frame that hits the end time exactly [00:20:10 CET] <kepstin> have you tried using -t instead of -to? [00:21:34 CET] <kepstin> I can never remember the exact edge-case behaviour of the two [00:25:55 CET] <derekprestegard> kepstin: exactly what we want [00:26:00 CET] <derekprestegard> Ill try -t instead :) [00:29:52 CET] <derekprestegard> another question - when comparing ssim scores using the output from x264 [00:30:05 CET] <derekprestegard> if one encode has 14.855 dB SSIM [00:30:14 CET] <derekprestegard> and another has 14.702, the difference is .153 dB [00:30:22 CET] <derekprestegard> how do I think about that in terms of percentage? [00:32:03 CET] <derekprestegard> kepstin: -t produces the same result [00:55:40 CET] <eternalamnesia> Hello I am having difficulties with VOB files, they were recorded with a realtime VHS to DVD burner and every time the DVD burner was paused it would reset the timestamp, so I have corrupted VOB files .. when I try to concat them the resulting file is also corrupted.. Any suggestions on a efficient method of converting the individual VTS_01_1.VOB, [00:55:40 CET] <eternalamnesia> VTS_01_2.VOB etc files beforehand and then concat them ?? [00:56:07 CET] <eternalamnesia> btw ffmpeg is a godsend [00:58:33 CET] <derekprestegard> try remuxing? [00:58:53 CET] <derekprestegard> ffmpeg -i foo.vob -c:a copy -c:v copy foo.ts maybe [00:59:33 CET] <eternalamnesia> awesome i will try it, thanks derek [01:02:05 CET] <yongyung> Is there a difference between using -s x:y and using -vf scale=x:y? [01:02:31 CET] <derekprestegard> eternalamnesia: np - you can also try another tool like mp4box or mkvmerge perhaps - they might work better [01:03:01 CET] <derekprestegard> also look at the -vsync option in ffmpeg possibly [01:08:54 CET] <llogan> yongyung: if i recall correctly, -s uses just scale filter. using scale instead is better because of additional options, such as allowing ffmpeg to preserve aspect ratio: -vf scale=1280:-1 [01:09:13 CET] <yongyung> llogan: Thanks [01:09:38 CET] <derekprestegard> yongyung: you can also specify the scaling algorithm, which some people like me care about :D [01:10:00 CET] <llogan> yongyung: also, if you use other filters you can more easily control when the scaling occurs [01:10:22 CET] <llogan> -vf filter0,filter1,scale,filter2,filter3 [01:10:56 CET] <llogan> i personally haven't used -s in a long time [01:11:10 CET] <yongyung> derekprestegard: What are the different scaling algorithms and why would you use one over another? [01:11:21 CET] <derekprestegard> things like lanczos, spline etc [01:11:28 CET] <derekprestegard> some are sharper than others [01:11:35 CET] <derekprestegard> the default is bicubic which is pretty well balanced [01:11:38 CET] <furq> yongyung: use -vf zscale if you have it [01:11:46 CET] <derekprestegard> ^ [01:11:49 CET] <derekprestegard> its SLOW though omg [01:11:56 CET] <derekprestegard> at least for me it was [01:12:05 CET] <furq> it's not noticeably slower for me [01:12:24 CET] <derekprestegard> well, the colorspace conversion and dithering was horrendously slow for me [01:12:30 CET] <derekprestegard> havent tried benchmarking basic scaling [01:12:41 CET] <llogan> yongyung: here are the scale options: http://ffmpeg.org/ffmpeg-scaler.html#scaler_005foptions [01:13:04 CET] <llogan> scale=640:-2:flags=lanczos for example [01:14:05 CET] <llogan> I meant "scaler options" [01:14:12 CET] <furq> derekprestegard: yeah i'm not doing any colourspace conversion [01:14:38 CET] <furq> i would definitely want to use zscale for that anyway since i hear swscale does a terrible job of it [01:15:18 CET] <yongyung> llogan: Does it matter what filter I should use depending on if I'm up or downscaling? [01:15:55 CET] <furq> yongyung: try with a few different ones and see which looks best for your source [01:16:29 CET] <llogan> it depends on your content and the desired look of the output, but as furq suggests you'll just have to experiment to see what you prefer [01:16:45 CET] <furq> lanczos and spline are sharp, bicubic is softer [01:17:12 CET] <yongyung> If I specify scaling on a video file that already has the correct resolution it's just ignored and has no negative effect, right? [01:17:22 CET] <furq> i should have thought so [01:17:41 CET] <furq> it might waste some cycles but it won't actually resample the image [01:19:02 CET] <furq> if you're upscaling a high-quality source then spline is probably a good choice [01:19:22 CET] <furq> or spline16 if you're using zscale [01:21:39 CET] <eternalamnesia> does anyone else love ffmpeg as much as i do [01:23:19 CET] <furq> do you have an ffmpeg hug pillow [01:24:02 CET] <eternalamnesia> lol no.. where do i get one [01:24:27 CET] <yongyung> I have a different kind of ffmpeg pillow [01:24:38 CET] <yongyung> ( a° \ a°) [01:24:53 CET] <yongyung> Man lenny just looks like a happy fat man with this font [01:25:38 CET] <llogan> eternalamnesia: ffmpeg -i pillow -i fflogo -filter_complex "overlay=(W-w)/2:(H-h)/2" ffpillow [01:25:54 CET] <TD-Linux> the closest I have is a traffic cone t-shirt [01:26:01 CET] <yongyung> furq: The hell is zscale again?^^ [01:26:54 CET] <llogan> that reminds me. i still have a brick of ffmpeg stickers. for today only if you email me your address at "lou at lrcd dot com" i'll mail some [01:28:36 CET] <llogan> they look like this: https://twitter.com/FFmpeg/status/476066145758236673/photo/1 [01:29:07 CET] <eternalamnesia> really? [01:29:25 CET] <eternalamnesia> i would love stickers [01:29:25 CET] <llogan> yes [01:30:15 CET] <FireFly> :o [01:30:34 CET] <yongyung> Hmm, somehow -to doesn't seem to work for me. "ffmpeg -ss 12:08 -i test.mp4 -to 12:50 -c copy clip.mp4", he takes the start time correctly but he just keeps everything after it. -t works fine [01:31:10 CET] <eternalamnesia> *sends email [01:31:19 CET] <derekprestegard> yongyung: when you use -ss before -i the timestamps are reset to 0 [01:31:33 CET] <derekprestegard> so do you want from 12:08 to 12:50 or 12m50s starting at 12:08? [01:31:53 CET] <yongyung> derekprestegard: Yeah that's what I want, makes sense I guess, kinda annoying though [01:31:58 CET] <derekprestegard> :) [01:32:03 CET] <llogan> you could try adding the -copyts input option [01:32:03 CET] <derekprestegard> you can try adding -copyts [01:32:04 CET] <eternalamnesia> derek .. that worked !! [01:32:05 CET] <yongyung> Since afair using -ss after -i is super slow [01:32:21 CET] <eternalamnesia> that will help me tremendously .. thank you [01:32:25 CET] <derekprestegard> yeah you def dont want -ss after -i [01:32:32 CET] <derekprestegard> eternalamnesia: awesome :) [01:32:47 CET] <yongyung> derekprestegard: Especially considering my input file is a 100GB lossless .mp4 ;) [01:32:57 CET] <furq> yongyung: https://ffmpeg.org/ffmpeg-filters.html#zscale [01:33:11 CET] <furq> look for --enable-zimg in your configure line [01:33:19 CET] <llogan> eternalamnesia: may not get mailed until Monday [01:34:23 CET] <furq> it should be higher quality than zscale but probably not to a noticeable extent [01:34:29 CET] <furq> s/zscale/swscale/ [01:34:44 CET] <eternalamnesia> thank you llogan [01:36:28 CET] <eternalamnesia> if anyone is interested to hear how someone uses ffmpeg, here is my story .. i have a basement recording studio set up with video security cameras and i stream live music performances to twitch.tv, then i use ffmpeg to chop the video for youtube .. the process is so much faster with ffmpeg [01:36:48 CET] <derekprestegard> eternalamnesia: awesome :) [01:37:19 CET] <derekprestegard> heres a question - if I have an MP4 file and want to stream it with seekability [01:37:20 CET] <eternalamnesia> i used to record the video with a dvd burner and im going through the old dvd files as well [01:37:22 CET] <derekprestegard> like with RTMP [01:37:31 CET] <derekprestegard> BUT I also want to burn in some text [01:37:33 CET] <derekprestegard> is that possible? [01:37:49 CET] <eternalamnesia> does it have to be mp4? why not flv? [01:37:56 CET] <derekprestegard> could be anything really [01:38:10 CET] <TD-Linux> derekprestegard, yes, just with HTTP, but only if you can transcode the entire file before you start streaming. [01:38:22 CET] <derekprestegard> yeah see thats the tricky bit [01:38:26 CET] <derekprestegard> its on-demand [01:38:38 CET] <derekprestegard> I need to burn in an email address or something similar on-demand [01:38:46 CET] <furq> if you stream it with rtmp then you'll be using flv [01:38:46 CET] <TD-Linux> in that case you need to use a streamable container, like indexless webm or fMP4 [01:38:53 CET] <furq> which will work fine [01:39:22 CET] <derekprestegard> TD-Linux: so if I start an encode using webm or fMP4 [01:39:23 CET] <TD-Linux> generating fMP4 and then pushing it into the browser via MSE is the new popular way [01:39:43 CET] <derekprestegard> so the player will be able to open the video before the encode is finished, right? [01:39:47 CET] <TD-Linux> derekprestegard, yes [01:39:51 CET] <derekprestegard> and also seek?? [01:39:57 CET] <TD-Linux> yes [01:40:02 CET] <derekprestegard> 0_0 cool! [01:40:12 CET] <derekprestegard> do you have an example of something like that you could point me towards? [01:40:36 CET] <derekprestegard> Im sitting here trying to get this crazy split and stitch workflow up and running (which it does BTW - 90 minute movie in under 1 minute from start to streamable) [01:40:40 CET] <derekprestegard> but this sounds way more interesting [01:41:05 CET] <TD-Linux> derekprestegard, so unfortunately there are a lot of methods and I don't know of any that will "just work" without JS, at least with seeking [01:41:18 CET] <derekprestegard> I see [01:41:24 CET] <derekprestegard> when you say fMP4 do you mean DASH et al? [01:41:34 CET] <TD-Linux> you can use DASH, though it's optional [01:41:54 CET] <llogan> eternalamnesia: look into the zmq filter with drawtext [01:42:11 CET] <derekprestegard> what would be the alternative to DASH? [01:42:16 CET] <TD-Linux> basically you have a list of segments and a widget to seek, and when you seek you grab the correct new segment and push it in via JS [01:42:23 CET] <TD-Linux> derekprestegard, anything, it's implemented in JS [01:42:32 CET] <TD-Linux> DASH is just a way to descrdibe the list of segments [01:42:37 CET] <derekprestegard> sure [01:42:58 CET] <derekprestegard> so the list is constnatly replaced as new segments come out of the encoder, right [01:42:59 CET] <derekprestegard> ? [01:43:07 CET] <TD-Linux> note that the segments can actually be segments of a single file [01:43:11 CET] <derekprestegard> right [01:43:19 CET] <TD-Linux> (or multiple files it doesn't matter) yes [01:43:32 CET] <derekprestegard> its kind of like a live streaming manifest except old segments arent removed [01:43:42 CET] <TD-Linux> yup. [01:44:02 CET] <derekprestegard> so the real trick is in keeping track of where you are and grabbing the appropriate chunk and then seeking inside that chunk [01:45:47 CET] <TD-Linux> yes. the browser will seek inside the chunk for you [01:53:17 CET] <llogan> eternalamnesia: i put the envelope in the printer wrong way. oh well. [01:57:27 CET] <eternalamnesia> lol [01:57:46 CET] <eternalamnesia> is it still sendable? [02:00:03 CET] <llogan> yeah. i always second guess myself with that printer and then always put it in the wrong orientation [02:12:03 CET] <yongyung> Does ffmpeg have a function to analyze the frame rate of video files? I have a 60 FPS file but it feels like there are some duplicated/dropped frames [02:19:56 CET] <eternalamnesia> i know ffmpeg -r 60 -i input .. will ignore the timecode and pretend like it is 60fps, which might help you see whats going on [02:40:14 CET] <iive> yongyung: maybe ffprobe have a mode that would output the frame timestamps. [03:58:09 CET] <yongyung> I guess that'd have to be an actual pixel based analysis, since the time stamps are all absolutely perfect, which makes me think they're not really measured and just generated by the recording software [05:10:44 CET] <licson> Hello. I'm currently using FFMpeg to record a HLS live stream and the live feed at the backend initiated a reconnect. [05:10:59 CET] <licson> I then get some errors like Application provided duration: 4080282478 / timestamp: 4564566641 is out of range for mov/mp4 format [05:11:16 CET] <licson> FFMpeg does not stop [05:11:46 CET] <licson> I wonder what that means and what will happen on the file recorded video? [05:12:01 CET] <licson> *recorded video file [09:02:05 CET] <eternalamnesia> im having difficulties with a very simple thing .. i have a video file with right channel audio only and want the right channel to be copied to left .. help pls [09:06:18 CET] <c_14> ffmpeg -i audio -map_channel 0.0.1 -map_channel 0.0.1 out [09:06:21 CET] <c_14> I think that should work [09:07:14 CET] <eternalamnesia> awesome thank you [09:08:17 CET] <eternalamnesia> i have to do the audio and video seperately right? [09:09:14 CET] <c_14> If you don't want to do anything to the video just add -c:v copy [09:11:26 CET] <eternalamnesia> there is an error message it says mapchan: stream #0.0 is not an audio stream [09:11:54 CET] <c_14> the second 0 might have to be a 1 [09:12:04 CET] <c_14> It's file_id.stream_spec.channel_id [09:14:29 CET] <eternalamnesia> awesome it worked thanks [09:33:36 CET] <licson> Hello. I'm currently using FFMpeg to record a HLS live stream and the live feed at the backend initiated a reconnect. [09:33:43 CET] <licson> I then get some errors like Application provided duration: 4080282478 / timestamp: 4564566641 is out of range for mov/mp4 format [09:33:50 CET] <licson> FFMpeg does not stop [09:34:02 CET] <licson> I wonder what that means and what will happen on the recorded video? [09:56:25 CET] <eternalamnesia> does anyone know what "invalid dropping " means? [10:08:09 CET] <bradfordli123> I am new to ffmpeg and I am trying to extract 15 second audio from a video in okay/low quality audio. so far I have "ffmpeg -i {video/audio} -vn" not sure what else to add for do this [10:32:47 CET] <sfan5> bradfordli123: add "-t 15" to only get 15 seconds and an output file obviously [10:33:31 CET] <sfan5> if the extract is not at the beginning you need at add -ss <seconds> to seek forward to the desired place [10:34:00 CET] <bradfordli123> awesome [10:34:03 CET] <bradfordli123> thank you so much! [12:59:31 CET] <yann|work> jkqxz: in fact there seems to be at least another example of hwaccel use, and for on-screen rendering (using va-api), in https://github.com/gbeauchesne/hwdecode-demos - only problem is that it works with ffmpeg 0.8, and a simple upgrade of the now-missing APIs is apparently not enough [13:00:37 CET] <yann|work> and I just realized that vaapi (aside from that I'm mostly interested in vdpau) is apparently *the* one not supported by ffmpeg.c :) [13:21:34 CET] <jkqxz> yann|work: You can also look at the uses vlc or mpv. [13:39:31 CET] <jkqxz> yann|work: Also, for VAAPI only, these two patches might provide some inspiration, though they have been superseded by an hwcontext-based set: <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-February/188909.html>, <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-February/188910.html>. [15:07:48 CET] <Spotlight1> hello,can little help with this things: LINUX: how can i do 3x3 screenshot from .m2ts: 1x1 is easy ffmpeg -ss 00:05:00 -i 111.m2ts -vframes 1 -y -f image2 222.png but for 3x3 screenshot is what command? on WEB i didnt find any .... thanks for help and response..... [15:09:28 CET] <DHE> sounds like something imagemagick might help with after you take a full size screenshot [15:13:27 CET] <J_Darnley> That sounds incredibly inefficient to do with ffmpeg without a dedicated filter for it. [15:14:37 CET] <furq> https://ffmpeg.org/ffmpeg-filters.html#tile [15:16:02 CET] <J_Darnley> "Tile several successive frames together" I think my point still stands although it has been reduced from a horrible filter chain to 2-passes [15:17:00 CET] <J_Darnley> although maybe you can stick some frameratefilter before it. [15:34:52 CET] <Spotlight1> btw:got it!!! [17:08:35 CET] <yann||work> jkqxz: thx for the hints - for now I've even settled with libmpv itself, i'll dig further afterwards [18:20:17 CET] <antiPoP> hi, I'm trying to convert around 3000 videos with "find . -name video.mp4 -execdir ffmpeg -y -i {} -vf scale=240:-1 video240p.mp4 \;" [18:20:58 CET] <antiPoP> however after 1000 it crashed with the error "Too many open files". How can a fix that? [18:21:09 CET] <antiPoP> *can I [18:32:39 CET] <ChocolateArmpits> antiPoP: That's probably not ffmpeg's fault [18:33:01 CET] <antiPoP> ChocolateArmpits, yes, I was guessing that... [18:33:16 CET] <ChocolateArmpits> Does it execute parallely ? [18:34:16 CET] <ChocolateArmpits> you could get a list of files and only execute in batches of 50 files let's say [18:35:14 CET] <Hot_Rod_> hello, i have an issue, http://pastebin.com/EaD07yTh im using shareX which use's ffmpeg, i upgraded to win10 3 days ago, now i get a error from ffmpeg but only for screen captures above a certain screen size, if i capture small areas it works fine, i was told be sharX developers this was a ffmpeg error and has be fixed, but i still have the error ?? [18:36:04 CET] <Hot_Rod_> by shareX* [18:36:44 CET] <Hot_Rod_> also i installed the latest ffmpeg yesturday.. [18:36:53 CET] <c_14> Hot_Rod_: your version of ffmpeg is 2 years old [18:37:34 CET] <Hot_Rod_> is there a link to the newest, i got that version from your site [18:38:42 CET] <Hot_Rod_> if there is a link to the latest, a installer version would be prefered [18:38:43 CET] <c_14> Where did you get the build from? [18:38:56 CET] <Jaex> Hot_Rod_: i told you to download new version and you downloaded 2 years old version?! [18:39:14 CET] <Hot_Rod_> the ffmpeg site ffmpeg.com or something [18:39:14 CET] <Jaex> not to mention i told ShareX can download latest version automatically, why you downloading manually [18:39:38 CET] <Hot_Rod_> i had it installed before the upgrade [18:40:14 CET] <Hot_Rod_> should i uninstall / reinstall ( i didnt try that) [18:41:11 CET] <Jaex> no just press ffmpeg download button it will redownload latest version [18:42:06 CET] <Hot_Rod_> ok off i go to try somemore.. TY again, sorry to be a pain in the butt [19:13:42 CET] <BtbN> ffmpeg does not have an installer, so if you "installed" ffmpeg, you downloaded something fishy. [23:10:25 CET] <Nanashi> Is it possible for a simple -i input output%d.png to be color inaccurate, or can I assume "some other guy" screencapped it totally wrong? (well, slightly darker) [23:11:29 CET] <JEEB> Nanashi: everything is possible with swscale! [23:11:46 CET] <Nanashi> e-everrrything [23:11:55 CET] <JEEB> I recommend you go verbose (-v debug) and look at how the chain gets done [23:12:05 CET] <JEEB> and then try doing something similar with zscale (based on zimg) [00:00:00 CET] --- Sun Feb 28 2016

1 0

ffmpeg-devel.log.20160226
by burek 27 Feb '16

27 Feb '16

[00:28:19 CET] <J_Darnley> ugh [00:28:49 CET] <J_Darnley> I wonder whether speding time removing a factor of 2 from all my memory args will help me see this bug [01:24:59 CET] <atomnuker> darkapex: sure [01:43:23 CET] <funman> atomnuker: just found 5edd1f62ca1 [01:58:24 CET] <funman> http://paste.ubuntu.com/15202492/ - my laptop doesn't do vdpau though so i can't test it now [02:53:21 CET] <jamrial> ubitux, Timothy_Gu: regarding tsan failing, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67308 [02:55:20 CET] <Timothy_Gu> jamrial: seen that bug; not very applicable [02:55:37 CET] <jamrial> removing -pie solves the failures here [02:57:00 CET] <jamrial> the configure failures, that is [02:57:31 CET] <jamrial> which is basically gcc not being able to compile a simple "int main() return 0;" program and making configure bail out [02:58:13 CET] <Timothy_Gu> oh that [02:58:32 CET] <Timothy_Gu> never mind, i confused it with helgrind [03:02:06 CET] <Shiz> huh [03:02:08 CET] <Shiz> how does that work [06:17:06 CET] <cone-825> ffmpeg 03Lou Logan 07master:0eb0f29a404e: MAINTAINERS: remove myself as a server maintainer [07:18:44 CET] <darkapex> atomnuker: Cool, I've edited the wiki. We need to add a backup mentor I guess. [09:27:18 CET] <cone-565> ffmpeg 03Matthieu Bouron 07master:885a6d83247b: configure: only check dispatch header on darwin [09:56:28 CET] <cone-565> ffmpeg 03Carl Eugen Hoyos 07master:07eec5e721cc: lavf/img2dec: Skip SOF size when probing jpeg. [10:21:36 CET] <cone-565> ffmpeg 03Stefano Sabatini 07master:dedcb3c5a5e6: lavf/mux: do not fail in case of non strictly monotonically increasing DTS values for data packets [11:42:09 CET] <cone-565> ffmpeg 03Paul B Mahol 07master:2a7f056d8807: avfilter/af_astats: do not clear previous sample value [13:17:50 CET] <cone-565> ffmpeg 03Rostislav Pehlivanov 07master:35346c7b0f7c: vc2enc: mark as FF_CODEC_CAP_INIT_THREADSAFE and align AVCodec entries [13:25:21 CET] <cone-565> ffmpeg 03Rostislav Pehlivanov 07master:3ef10406e196: vc2enc: correctly zero out coefficient array padding [13:56:21 CET] <cone-565> ffmpeg 03Rostislav Pehlivanov 07master:7db2e757c594: vc2enc: use FFABS() instead of abs() [14:46:14 CET] <Daemon404> ... so carl's strategy is to simply never respond to my reply and let the patch die? [14:46:17 CET] <Daemon404> sigh. [14:47:57 CET] <RiCON> Daemon404: try sending 20 slightly different versions of it [14:48:08 CET] <Daemon404> lol [14:48:11 CET] <Daemon404> close [14:48:17 CET] <Daemon404> he is at 27 i think [14:51:23 CET] <wm4> Daemon404: carl probably thinks the problem is solved because he fixed yet another jpg probing failure [14:51:59 CET] <Daemon404> i still do not understand his objection [14:52:07 CET] <Daemon404> mimetype should be more accurate that extension full stop [14:54:44 CET] <wm4> agreed [15:04:31 CET] <Daemon404> https://www.dropbox.com/s/dtucxsj8wbov3yd/srsly.png?dl=0 [15:04:34 CET] <Daemon404> this is ridiculous [15:05:53 CET] <Mavrik> :/ [15:10:00 CET] <Daemon404> 17% of all mails in feb are from him replying to himself. [15:10:48 CET] <Daemon404> almost 300. [15:15:23 CET] <durandal_1707> lol [15:22:53 CET] <ubitux> http://ubitux.fr/pub/pics/arm-instruction-explanations.png [15:23:10 CET] <ubitux> "signed integer saturating doubling multiply accumulate long" should be enough as an explanation [15:24:34 CET] <ubitux> jamrial: yes i saw the issues [15:24:37 CET] <ubitux> -s [15:25:55 CET] <jamrial> ubitux: not sure how to fix the configure check to not add -pie. $gcc_basever isn't set until several lines after the toolchain checks [15:26:15 CET] <durandal_1707> michaelni: for some reason if filter accepts only le 9bit be format will be converted to 16bit one instead of just swaping bytes [15:26:29 CET] <ubitux> jamrial: no idea either... version check? [15:26:41 CET] <ubitux> oh, base version later, meh [15:26:54 CET] <jamrial> yes, the errors with -pie seem to be with gcc >= 5.2 [15:27:15 CET] <ubitux> well after version gcc basever is defined, you add flags if toolchain [15:27:19 CET] <jamrial> maybe we could add another case $toolchain later to add -pie [15:27:23 CET] <jamrial> yeah [15:27:36 CET] <Daemon404> is there ever a release of gcc that doesnt break something new? [15:33:45 CET] <Compn> i think there was a prerelease release that we tested on and it worked, but then the final release broke something :P [15:34:03 CET] <nevcairiel> breaking something in 5.2 is odd though, considering thats a point release [15:34:09 CET] <nevcairiel> usually only the first release is entirely broken =p [15:36:09 CET] <Timothy_Gu> durandal_1707: is there a filter to remove background noise in audio? [15:39:06 CET] <durandal_1707> Timothy_Gu: 2pass in sox and spectral one in audacity [15:40:11 CET] <durandal_1707> Timothy_Gu: I assume its spread accross multiple frequencies [15:41:20 CET] <michaelni> durandal_1707, do you have a testcase/cmdline for the 9bit issue ? [15:43:44 CET] <durandal_1707> michaelni: see datascope filter, add/use format filter before it [15:44:09 CET] <Timothy_Gu> durandal_1707: yes, uniformly [15:44:11 CET] <Timothy_Gu> thanks [15:51:53 CET] <cone-565> ffmpeg 03Rostislav Pehlivanov 07master:2b811e4605eb: vc2enc: halve allocated table size, refactor and optimize quantization [16:08:14 CET] <michaelni> durandal_1707, ./ffplay -v 99 matrixbench_mpeg2.mpg -vf format=yuv420p9le,datascope -an [16:08:22 CET] <michaelni> works fine, uses 9le format [16:09:04 CET] Action: michaelni rereads what durandal_1707 wrote and realizes tat this isnt what was meant [16:11:03 CET] <michaelni> durandal_1707, "-vf format=yuv420p9le,format=yuv420p9be,datascope" still no 16bit [16:11:38 CET] <michaelni> it would save me alot of time if you would share testcases and i wouldnt have to guess and construct them [16:29:23 CET] <jya> looks like avfilter_graph_parse2 doesn't handle float parameters depending on the locale. it chokes on a 1.77 aspect ratio as a treat the . as a , [16:30:15 CET] <Daemon404> jya, i dont blame it [16:30:28 CET] <Daemon404> c locales are crap [16:30:41 CET] <Daemon404> i bet most libraries don't handle it right [16:30:51 CET] <jya> Qt does :) [16:30:59 CET] <Daemon404> qt rolls its own.... literally everything [16:31:04 CET] <Daemon404> the rest of the world uses atoi and pals [16:31:23 CET] <jya> at first the %f was printing my 1.77 as 1,77 ; which I figure could be worked around [16:31:42 CET] <Daemon404> i disaree [16:31:48 CET] <Daemon404> libraries should not be messing with locales [16:31:54 CET] <jya> but then I get a failure when the buffer filter gets initialised, and that one I can't get around... will have to calculate the ratio myself :( [16:32:00 CET] <Daemon404> it will affect user applications using said library [16:32:05 CET] <Daemon404> if we screw around with setting a locale [16:32:43 CET] <jya> at I guess I would say it's the routine calculating the ratio from the float [16:32:51 CET] <jya> surely that shouldn't consider the locale [16:33:06 CET] <Daemon404> it does [16:33:11 CET] <Daemon404> because it's a filter string. [16:33:18 CET] <Daemon404> it has to parse the string into a float [16:33:20 CET] <Daemon404> and radix matters. [16:33:24 CET] <jya> right.... [16:33:53 CET] <Daemon404> why dont you use raptionals btw? [16:33:56 CET] <Daemon404> rationals* [16:34:24 CET] <Daemon404> (there's also a new api that doesnt use strings at all, but it's likely too new for you) [16:35:41 CET] <jya> because the aspect ratio in our MythFrame is a float [16:36:04 CET] <jya> i'm not working on firefox tonight, porting mythtv to the new ffmpeg 3.0 [16:36:20 CET] <jya> and the removal of avpicture_deinterlace has given me heaps of grief [16:36:38 CET] <Daemon404> ... why you ever use that at all is a mystery [16:36:45 CET] <Daemon404> its been deprecated for like 5+ years [16:37:00 CET] <jya> sure, but to generate a preview picture it's great [16:37:23 CET] <Daemon404> [15:35] < jya> because the aspect ratio in our MythFrame is a float <-- well, MythFrame sucks then, but you can use av_d2q to convert it to a rational [16:37:35 CET] <jya> it takes a single AVFrame, deinterlace it well enough and hop you go [16:37:46 CET] <jya> av_d2q won't choke because of the locale? [16:37:57 CET] <Daemon404> strings arent involved [16:37:57 CET] <BtbN> how is there a locale involved in a double? [16:38:03 CET] <Daemon404> double2rational [16:38:38 CET] <jya> Daemon404: thanks for that. [16:38:58 CET] <wm4> BtbN: conversion to/from strings [16:39:11 CET] <wm4> I find it hilarious that Qt indeed fucks up C string processing by default [16:39:27 CET] <Daemon404> ? [16:39:31 CET] <jya> I've spent my entire evening wondering what was going on on why that particular user saw stuff like '77778' unknown filter in his log [16:39:36 CET] <wm4> Qt sets the locale on start [16:39:52 CET] <Daemon404> wouldnt that screw with apps usign qt [16:40:00 CET] <jya> wm4: not at all, for QString, the conversion is define to use the US locale [16:40:04 CET] <flux> maybe C string processing deserves to be fucked up if setting up locale breaks it ;-) [16:40:11 CET] <wm4> jya: that's C++ [16:40:12 CET] <jya> if you want to use another locale you use SetNum [16:40:19 CET] <Daemon404> flux, locales in c is the single biggest mistake in C [16:40:34 CET] <wm4> counting down to when someone will suggest to convert ffmpeg to C++ because of this [16:40:58 CET] <flux> seems like most of the time locales in programming languages is the mistake. [16:41:03 CET] <Daemon404> yep. [16:41:11 CET] <flux> but I suppose the world seems different form the eyes of a developer.. [16:41:26 CET] <cone-565> ffmpeg 03Rostislav Pehlivanov 07master:bc7beb657499: vc2enc: calculate the minimum slice size only once [16:46:51 CET] <jamrial> at what point do we declare that mats peterson is spamming the list? [16:49:53 CET] <Timothy_Gu> jamrial: he admitted it himself [16:50:26 CET] <jamrial> that's nice. next milestone would be telling him to slow down [16:51:02 CET] <wm4> we did that before [16:51:08 CET] <wm4> and he promised to do that before [16:51:15 CET] <Timothy_Gu> jeez 13 replies... [16:51:15 CET] <wm4> but the outcome is pretty much the same [16:59:04 CET] <durandal_1707> michaelni: only single format to be [17:13:43 CET] <BBB> jya: I put up some example code somewhere to use as drop-in replacement for avpicture_deinterlace using lavfi [17:13:58 CET] <BBB> jya: if helpful, let me know ill dig it up [17:15:11 CET] <durandal_1707> tell mats to come here, he would always ask/answer something [17:16:25 CET] <wm4> the most painless way is just copying the old deinterlace function [17:16:34 CET] <wm4> others did the same with the lavc resampler [17:24:33 CET] <Daemon404> wm4, how well do you know mp3dec.c in lavf [17:25:57 CET] <wm4> relatively well [17:26:27 CET] <Daemon404> ffmpeg -loglevel debug -f mp3 -i http://chromashift.org/skyfire.ico [17:26:41 CET] <Daemon404> it just keeps seeking past EOF [17:26:49 CET] <Daemon404> i dont know if it's infinite or just a really huge amount of seeks [17:26:59 CET] <Daemon404> if i try the file local, i see: [17:26:59 CET] <Daemon404> [AVIOContext @ 0x2c54e00] Statistics: 6580 bytes read, 116298 seeks [17:27:04 CET] <Daemon404> so... could be either. [17:27:29 CET] <wm4> it scans the start of the file byte by byte [17:27:38 CET] <Daemon404> it's 6kb. [17:27:45 CET] <Daemon404> Range: bytes=7953- [17:27:49 CET] <Daemon404> stuff like that shouldnt happen [17:28:05 CET] <wm4> it doesn't check for that though [17:28:13 CET] <Daemon404> why [17:28:20 CET] <wm4> maybe the return value for ffio_ensure_seekback should really be checked [17:28:29 CET] <Daemon404> i added checks for that an avio_seek [17:28:30 CET] <Daemon404> didnt help [17:28:32 CET] <Daemon404> and* [17:28:43 CET] <wm4> so where does it "hang"? [17:28:46 CET] <Daemon404> 416s on every request and it just continues [17:28:55 CET] <Daemon404> where in the code do you mena? [17:29:02 CET] <wm4> yeah [17:29:38 CET] <Daemon404> #17 mp3_read_header (s=0x1ef9280) at libavformat/mp3dec.c:376 [17:29:41 CET] <Daemon404> somewhere in this loop [17:29:43 CET] <Daemon404> which blames you [17:29:55 CET] <wm4> I know [17:30:12 CET] <wm4> but strange that the avio functions return success? [17:30:22 CET] <Daemon404> hmmm i didnt add it in check() [17:30:24 CET] <Daemon404> maybe thats it [17:31:00 CET] <wm4> yeah, I bet it's it [17:31:09 CET] <Daemon404> wheres that defined [17:31:15 CET] <Daemon404> such a generic name.. but its not local [17:32:07 CET] <wm4> lol [17:32:37 CET] <Daemon404> oh it is [17:33:26 CET] <Daemon404> it does check avio_seek [17:33:28 CET] <wm4> so the function must now distinguish invalid headers, and not being able to read data [17:33:45 CET] <wm4> also, the API it uses can't even signal read failure [17:33:49 CET] <wm4> avio_rb32() [17:34:01 CET] <Daemon404> it shouldnt get to rb32 [17:34:08 CET] <Daemon404> because it shouldnt be able to seek that far [17:34:14 CET] <Daemon404> unless http is special [17:34:14 CET] <wm4> ok, god [17:34:17 CET] <wm4> good [17:36:34 CET] <Daemon404> wm4, i have an idea [17:36:35 CET] <Daemon404> 1 sec [17:40:01 CET] <Daemon404> nevermind, didnt work. [17:40:12 CET] <Daemon404> i think [17:44:43 CET] <wm4> I can take a closer look later [17:44:46 CET] <Daemon404> http://sprunge.us/XEHf [17:44:48 CET] <Daemon404> was not enough [17:44:52 CET] <Daemon404> same issu [17:45:20 CET] <wm4> check() is allowed to fail, because it returns whether the mp3 header is valid [17:45:31 CET] <wm4> so skipping N bytes will have check() fail N times [17:45:43 CET] <Daemon404> im not sure what to do then [17:45:48 CET] <wm4> so it needs to distinguish wrong header and failed seek [17:46:04 CET] <wm4> I wonder if check() returning 0 can happen currently [17:46:42 CET] <Daemon404> ugh [18:02:02 CET] <Daemon404> wm4, fixed i think [18:02:10 CET] <ubitux> so i just stopped being an idiot, dropped half of the asm, and made the code twice faster [18:03:49 CET] <kurosu> "How I learned to stop worrying and love the Bomb^W^W swscale" [18:04:54 CET] <wm4> but removing asm must make it slower! [18:05:05 CET] <wm4> what heresy [18:05:22 CET] <ubitux> for yuv420p, nv12 and nv21, i was factoring the chroma premultiplying [18:05:37 CET] <ubitux> so we wouldn't need to read twice the chroma, and do all the mul [18:05:42 CET] <ubitux> twice [18:06:08 CET] <ethe> michaelni: What does the list() notation mean here? http://guru.multimedia.cx/small-tasks-for-ffmpeg/ (assuming you are the michael that posted this) [18:06:13 CET] <ubitux> but apparently, the cpu didn't like at all reading 2 lines of chroma, and writing 2 lines of rgba in parallel [18:06:27 CET] <ubitux> and re-doing all the mult, add, and reading made the code twice faster [18:06:30 CET] <ubitux> ...and twice simpler [18:06:37 CET] <ubitux> we should probably do that to the armv7 [18:06:51 CET] <ubitux> and with all the extra reg available, we can probably avoid some bubbling [18:08:49 CET] <Daemon404> wm4, ill send a patch [18:29:35 CET] <michaelni> ethe, thats from 2007, thats a long time ago, but theres an example [18:30:01 CET] <hawken> uuu ubitux :D gcc always beats asm these days [18:30:41 CET] <michaelni> ethe, the example should explain the list [18:31:28 CET] <hawken> ubitux: are there things you simply cannot do in C? In my experience gcc always seems to find the best way, but I haven't exactly written video encoders either [18:36:50 CET] <Daemon404> hawken, any sort of nontrivial SIMD [18:36:57 CET] <Daemon404> or even just SIMD which is not broken. [18:37:36 CET] <Shiz> lidt/lgdt is hard in C [18:37:45 CET] <Shiz> or even cli/sti [18:41:41 CET] <ethe> michaelni: "thats from 2007" it doesnt look like the huffman table generation has changed since 2001 though, so it's still an improvement that could be made. "the example should explain the list" should. Maybe I'll just come back to it later. I want to help, but I just.. cant :/ [18:42:39 CET] <TD-Linux> bsr, but maybe gcc can infer it nowadays [18:44:50 CET] <michaelni> ethe, with 2007 i meant i dont remember exactly [18:46:10 CET] <michaelni> ethe, theres also a wikipedia article linked but wikipedia had the tendency to be "not so good" for algorithm descriptions often imho [18:51:26 CET] <Mavrik> Daemon404, is SIMD so bad even with GCC 5.x / Clang 3.6 ? [18:52:11 CET] <JEEB> no compiler can know from the C code all of the optimizations it can take in a specific case [18:52:24 CET] <JEEB> all the assumptions etc [18:52:51 CET] <JEEB> otherwise people wouldn't be writing hand-written asm [18:53:07 CET] <Mavrik> Mhm, I had no idea about current state of that. [18:53:14 CET] <Mavrik> Are intrisics also still a horrible idea? [18:54:10 CET] <JEEB> intrinsics aren't horrible per se, just that they aren't as good as actual asm functions where you handle the regs and all. that said, you can get the big part of the speed-up with just intrinsics [18:54:32 CET] <JEEB> that's why people usually don't bother writing actual asm if they have already written optimizations with intrinsics [18:54:36 CET] <JEEB> see: openhevc [18:54:42 CET] <Mavrik> Mhm, I was looking at them to try to make the pain of supporting both NEON and SSE a bit smaller. [18:56:06 CET] <michaelni> ethe, the lists are lists of symbol piles if you want to call them that way, each pile has a integer representing occurance, but i dont really remember the algortithm/why this works [18:56:39 CET] <michaelni> id have to think about it but have no time atm [19:04:01 CET] <ethe> I know why, and how visually--I'd just have to spend a bit of time to work out the code for it. I'm also a little confused about what the ff_mjpeg_build_huffman_codes() function does if it doesnt build optimal huffman codes. Again, I'll probably have to read up on the spec to understand what exactly to do [19:04:16 CET] <JEEB> mateo`: I will try your new patch set today :) it seems like v2 works nicely - the biggest issue right now seems to be catching decoding failures [19:08:44 CET] <wm4> isn't continue at the end of a for/while loop always a NOP, or did my brain fully decay now [19:12:39 CET] <michaelni> ethe, ff_mjpeg_build_huffman_codes() takes a list of symbol lengths and assigns them binary codes of that length [19:12:56 CET] <michaelni> ethe, feel free to send a patch to document it [20:20:13 CET] <cone-565> ffmpeg 03Michael Niedermayer 07master:410f717ff644: avcodec/utils: Merge identical if conditions [20:20:14 CET] <cone-565> ffmpeg 03Michael Niedermayer 07master:7a8ab57cf1fc: fate: Add test for packed mp3 in mp4 demuxing [20:26:13 CET] <ubitux> hawken: well, 60ms is still better than 500 [20:26:26 CET] <ubitux> simd isn't "just asm" [20:26:54 CET] <ubitux> and there is no way gcc is going to generate better code than this here, it has not enough information about the constraints [20:29:27 CET] <durandal_1707> anybody against pushing datascope? [20:31:50 CET] <J_Darnley> What did I miss regarding asm/simd? [20:32:32 CET] <J_Darnley> oh is someone trying to sell us on intrisics? [20:32:42 CET] <J_Darnley> *intrinsics [20:33:25 CET] <JEEB> lol [20:39:36 CET] <TD-Linux> Mavrik, intrinsics are instruction set specific, you still have to write one set for NEON and one for SSE [20:40:30 CET] <JEEB> they are pretty much SIMD functions, and then the compiler tries to map them within the C/C++ [20:40:35 CET] <wbs> TD-Linux: actually, intel have written an arm_neon.h which is implemented with sse intrinsics, so you can build neon intrinsics code for x86 [20:40:38 CET] <JEEB> (register etc. wise) [20:40:53 CET] <JEEB> oh, that case :D [20:40:55 CET] <wbs> they claim that it actually still gives you some sort of speedup, but it depends a lot on how the code is designed. when I tried it, it made things slower than C [20:41:00 CET] <TD-Linux> wbs, sounds awful :) [20:41:07 CET] <JEEB> hah [20:41:13 CET] <wm4> nice try Intel [20:41:31 CET] Action: TD-Linux is a bit surprised that they didn't write it the other way around [20:41:47 CET] <wbs> I guess the main target is to get better opts for android apps for x86 [20:41:57 CET] <wm4> TD-Linux: they want people to write intel code [20:42:01 CET] <wbs> which primarily are designed for arm, but to be able to bring some of those simd opts over to x86 [20:42:26 CET] <Mavrik> wbs, oh I actually tried those [20:42:38 CET] <Mavrik> Intel built that for Android so people would actually port .so stuff to x86 [20:42:38 CET] <TD-Linux> wm4, right, which is why I suggested the other way around [20:42:42 CET] <Mavrik> It's slow as arse. [20:42:44 CET] <Mavrik> :) [20:42:53 CET] <TD-Linux> the thor video codec has a "instrinsics abstraction layer" that is similar [20:43:50 CET] <TD-Linux> it works quite a bit better, but it has to have rather high level abstractions for e.g. SAD and it's still intrinsics [21:45:09 CET] <BBB> hm right so the google guy didnt test his patches [21:45:11 CET] <BBB> that kind of sucks [21:45:57 CET] <Daemon404> BBB, do you know why he puts everything in |these| [21:46:09 CET] <BBB> probably a java'ism? [21:46:17 CET] <Daemon404> ive never seen such a thing in java [21:46:25 CET] <Daemon404> but my experience is limited [21:47:35 CET] <BBB> it looks vaguely familiar [21:47:38 CET] <BBB> but I dont know from what [21:53:16 CET] <Shiz> ruby-ism? [21:53:18 CET] <peloverde> It's a chromism [21:53:27 CET] <jkqxz> I assume those patches are mainly going for the "data races are undefined behaviour, so we must remove them whatever the cost because the compiler might be able to optimise it to make demons fly out of our noses", ignoring the fact that it could only cause a problem with DS9K levels of malice involved. [21:55:11 CET] <rcombs> compilers _do_ get pretty malicious about data races, though [21:56:48 CET] <jkqxz> The die one, for example, pretty much requires the compiler to use the undefined behaviour to deduce that there can't be any other threads and therefore eliminate most of the code. [21:59:10 CET] <BBB> the die one is the least malicious one, since it doesnt introduce new lock/unlock pairs [21:59:20 CET] <BBB> I dont have major issues with that one, only half-major'ish [21:59:32 CET] <BBB> the other two, particular the one I responded two twice, I have more serious issues with [22:01:43 CET] <jkqxz> The die one is correctly fixed by making die relaxed atomic (which is how the compiler is already treating it if it isn't absurdly malicious). The locking and extra variables are not doing anything useful. [22:01:53 CET] <cone-565> ffmpeg 03Clément BSsch 07master:805685fffd31: Kill timed SSA [22:01:54 CET] <cone-565> ffmpeg 03Clément BSsch 07master:294128212410: lavc: allow subtitle text format to be ASS without timing [22:01:55 CET] <cone-565> ffmpeg 03Clément BSsch 07master:30e76853608f: lavc/options: add ass_ro_flush_noop to flags2 [22:01:56 CET] <cone-565> ffmpeg 03Clément BSsch 07master:6433618dc01c: ffmpeg: set sub_text_format to ass (without timing) by default [22:01:57 CET] <cone-565> ffmpeg 03Clément BSsch 07master:fa2df3a40124: lavfi/ass: use ass_process_chunk() instead of ass_process_data() [22:01:58 CET] <cone-565> ffmpeg 03Clément BSsch 07master:22ebbda63725: lavc: deprecate decoded ass subtitles with timings [22:02:54 CET] <wm4> whoop [22:03:43 CET] <Daemon404> doesnt it use soon-to-be-deprecated APIs =p [22:03:55 CET] <wm4> which does? [22:04:08 CET] <Daemon404> avctx->time_base iirc [22:04:25 CET] <wm4> isn't it more about _not_ using it [22:04:40 CET] <Daemon404> i must have misunderstood ubitux then [22:05:13 CET] <ubitux> Daemon404: so decoders were using it to rescale the timing [22:05:26 CET] <ubitux> now most of them do not do it anymore [22:05:41 CET] <ubitux> and it's now done in lavc/utils in the factorized code [22:05:53 CET] <ubitux> which will be deleted at next bump [22:06:02 CET] <Daemon404> ic [22:06:06 CET] <ubitux> some decoders still actually do use it: ccaption and zvbi [22:06:46 CET] <ubitux> anyway, any comment on doc/APIChanges is welcome, I didn't ask for a review of this (sorry!) [22:07:03 CET] <ubitux> (last 2 entries) [22:10:37 CET] <ubitux> i feel like i just removed a cancer from my ass [22:10:40 CET] <ubitux> this shit was really insane [22:11:04 CET] <ubitux> we can now work on moving subtitles to lavu [22:11:14 CET] <ubitux> and integrates them in lavfi [22:14:22 CET] <BBB> jkqxz: Ive had conversations with these tsan people in the past, I really want them to move away from tsan and implement something akin to MS chess, but they refuse and tell me Im delusional, obsctructive, uninformed and stupid [22:14:32 CET] <BBB> (in nice words, of course) [22:15:40 CET] <wm4> how nice [22:15:57 CET] <cone-565> ffmpeg 03Clément BSsch 07master:b5451d88cf8b: lavc: reindent a few decoders after previous commits [22:16:01 CET] <wm4> ubitux: that means AVSubtitle must be moved to AVFrame [22:16:03 CET] <wm4> somehow [22:16:19 CET] <ubitux> wm4: so you really think we should do that? [22:16:29 CET] <wm4> how else would you do it [22:16:32 CET] <ubitux> like, using extended_data as AVSubtitlesRect or sth? [22:16:37 CET] <wm4> lavfi is pretty much hardcoded to use AVFrame for everything [22:17:00 CET] <ubitux> right, well [22:17:02 CET] <ubitux> api is private [22:17:13 CET] <ubitux> for the most part [22:17:23 CET] <ubitux> so it could technically be adjusted to AVSubtitles [22:17:35 CET] <ubitux> now i'm not against AVFrame as holder [22:17:44 CET] <ubitux> i have a few concerns though [22:17:46 CET] <ubitux> but well [22:17:51 CET] <ubitux> why not really [22:18:06 CET] <wm4> in its simplest form AVFrame.data[0] could point to a AVSubtitle [22:18:37 CET] <ubitux> i'd go for AVFrame.extended_data[] being all the rects [22:18:50 CET] <ubitux> and AVFrame holding all the info we currently have in AVSubtitle [22:19:17 CET] <wm4> I don't know, maybe [22:19:36 CET] <ubitux> i need a little break from subtitles for a while though :D [22:21:47 CET] <BBB> michaelni: you want it split so one patch introduces the bhaviour change (drop packet after BSF if size==0/num_side_data_elements==0), and one to introduce the new vp9 BSF? [22:22:19 CET] <cone-565> ffmpeg 03Paul B Mahol 07master:42c5e1cc2ad9: avfilter: add datascope filter [22:23:10 CET] <ubitux> it's very nice to see someone working on threading! [22:23:31 CET] <wm4> where [22:23:55 CET] <ubitux> Wan-Teh Chang, ml [22:24:05 CET] <ubitux> someone at google apparently [22:24:13 CET] <michaelni> BBB, yes, or lavc/lavf/ffmpeg, also some version bumps are likely needed [22:24:14 CET] <ubitux> trying to calm down the tsan furry [22:24:16 CET] <wm4> yeah, magnitudes of slowdown for minor correctness changes [22:24:21 CET] <BBB> hehehe [22:24:30 CET] <BBB> now now now, he didnt test his changes [22:24:31 CET] <ubitux> probably a lock design mistake [22:24:43 CET] <wm4> ubitux: I think this code should use proper atomics [22:24:51 CET] <BBB> he probably didnt know that youre supposed to test changes or that some people use threading to speed complicated things up rather than just for aesthetics [22:24:53 CET] <wm4> instead of x86 maybe-it-works-atomics [22:24:54 CET] <ubitux> i think so too [22:25:19 CET] <wm4> BBB: maybe he did test it, just not for performance impact [22:25:19 CET] <BBB> and his complaint about atomics is right, on arm atomics may not always be as speed-optimal as on x86 [22:25:54 CET] <BBB> michaelni: hm& minor or micro? [22:26:52 CET] <michaelni> strictly it probably needs minor [22:27:07 CET] <BBB> okiedokie [22:32:00 CET] <jkqxz> It's only a possible performance issue because the atomics libavutil offers are sequentially consistent (i.e. barrier ALL the memories!). Sequential consistency is totally overkill for almost everything. [22:32:35 CET] <wm4> true [22:32:57 CET] <wm4> too bad we can't require C11 atomics [22:33:00 CET] <jkqxz> C11 required to build ffmpeg, anyone? [22:33:10 CET] <jkqxz> Yeah :) [22:36:12 CET] <ubitux> we have atomic_{gcc,suncc,win32}.h [22:36:16 CET] <ubitux> we can add atomic_c11.h [22:36:27 CET] <ubitux> or is it abi incompatible? [22:36:37 CET] <BBB> why not just add the atomic calls you guys think we need? [22:36:43 CET] <wm4> no, the problem is about exposing all the different barrier modes [22:36:51 CET] <BBB> yes [22:36:53 CET] <BBB> so [22:36:58 CET] <BBB> why not add the appropriate ones? [22:37:13 CET] <kierank> michaelni: so how come you didn't write a rgb_to_a function for GBRAP12? [22:37:21 CET] <BBB> Ive looked at c11 and chrome also has an amazing assortment of different calls doing the same thing approximately with different barriers [22:45:58 CET] <michaelni> kierank, i did write planar_rgb##nbits##endian_name##_to_a [22:46:06 CET] <kierank> oh right [22:46:10 CET] <jkqxz> Examining things and changing them to relaxed atomics to remove data race complaints is a lot of effort to go to to make no difference whatsoever (since exactly the same code would be generated unless the compiler was going to huge effort to screw you over). [22:49:04 CET] <BBB> you dont have to do it [22:49:08 CET] <BBB> this google guy can do it for you! [22:50:47 CET] <jkqxz> Come to think of it, it does sound like an ideal project to pad out the GSoC long tail of things that noone would ever pick... [22:51:28 CET] <ubitux> i think we need someone really competent on this issue [22:51:38 CET] <ubitux> it's a bit too sensible imo [22:51:53 CET] <ubitux> (and complex) [22:55:43 CET] <wm4> there _are_ talented students [22:55:55 CET] <wm4> they just don't seem to look at ffmpeg too often [22:56:25 CET] <J_Darnley> Because its written in C and not ${FLAVOUR_OF_THE_MONTH} [22:57:26 CET] <J_Darnley> Or because it deals with boring bitmaps and not text strings someone enters into a webpage [22:58:35 CET] Action: J_Darnley is perhaps too cynical [22:59:38 CET] <jamrial> so i'm writing resample simd for the missing fmt, s32, and just noticed it needs to shift an int64_t by 30. problem is that there's only a logical quadword right shift sse2 instruction [23:00:01 CET] <jamrial> since after shifting i only need the lower dword, it should be functionally the same, right? [23:00:48 CET] <J_Darnley> if you immediately truncate it sounds fine [23:01:19 CET] <proxima> hi kierank, have you received my submission regarding video fuzzing? [23:01:20 CET] <jamrial> yeah, pminsd+pmaxsd right after shifting [23:02:01 CET] <kierank> proxima: no, what is your email name and address [23:02:51 CET] <proxima> kierank, its swetarani3007(a)gmail.com (signed as Sweta Rani) [23:03:35 CET] <kierank> Ah I mixed you up with someone else [23:03:41 CET] <kierank> yes I got that [23:03:50 CET] <kierank> you should file bug reports on trac.ffmpeg.org with the crashes you found [23:04:18 CET] <kierank> but make sure they are crashes and not just that you don't have memory [23:04:25 CET] <kierank> so segfaults [23:04:48 CET] <proxima> okay [23:05:59 CET] <proxima> thanks, will do it and report you soon [23:06:29 CET] <wm4> ubitux: I'm disappointed, my code still works [23:06:48 CET] <ubitux> wrt sub/ass? [23:06:55 CET] <ubitux> the default isn't changed [23:06:59 CET] <ubitux> you need to force the option [23:07:39 CET] <wm4> I know [23:07:49 CET] <ubitux> but it still works anyway? [23:07:58 CET] <wm4> well that was mostly ironic [23:08:04 CET] <wm4> as in, nothing broke [23:08:12 CET] <proxima> kierank: were the steps adopted by me correct? [23:08:16 CET] <kierank> yes [23:08:27 CET] <kierank> I think fuzzing h264 will be hard to find crashes though [23:08:35 CET] <kierank> I would find a more obscure codec on samples.ffmpeg.org [23:08:44 CET] <ubitux> wm4: well, glad to hear it :) [23:08:56 CET] <proxima> yeah i got seg faults for images but could not get for video [23:09:16 CET] <proxima> okay , i will search for better one [23:09:19 CET] <kierank> proxima: images is fine [23:09:43 CET] <kierank> proxima: do you understand the goal of the outreachy project? [23:11:38 CET] <proxima> yes, as I read we need to find out bugs caused due to fuzzing(by tools like zzuf and afl-fuzz). Next we need to build a platform so that anyone can test their projects in similar fashion. Is this right? [23:12:27 CET] <kierank> not quite [23:12:38 CET] <wm4> ubitux: wait, it still can output multiple ASS lines per decode? [23:12:54 CET] <kierank> proxima: the platform is there to test whether individual commits broke files with fuzzin [23:12:58 CET] <kierank> -g [23:13:09 CET] <kierank> at the moment we just fuzz random files [23:13:42 CET] <kierank> we need to do this more systematically [23:14:01 CET] <wm4> ubitux: and the duration is always in MS?? [23:14:19 CET] <proxima> we need to channelize it such that all the commits gets tested excluding unchanged files. [23:14:34 CET] <kierank> proxima: basically we need to make sure that only the correct files are fuzzed per commit [23:14:42 CET] <kierank> so a commit to jpeg wouldn't fuzz png for example [23:15:13 CET] <proxima> what do you mean by correct files? [23:15:47 CET] <kierank> well in the set of files (known as a corpus) we have all sorts of files: images, video etc [23:16:02 CET] <kierank> but we would only want to fuzz jpeg files if jpeg was changed [23:16:04 CET] <kierank> not the whole thing [23:16:54 CET] <kierank> the whole corpus [23:17:13 CET] <proxima> okay, and one thing more that it will be fully automatic to detect that which files have changed and then fuzz those particular ones? [23:17:58 CET] <kierank> yes we could do this by parsing the commit message or by looking at which files have changed [23:19:02 CET] <proxima> any thing more i need to know? [23:19:51 CET] <kierank> you should look at fffuzz [23:20:18 CET] <kierank> problem is that when you fuzz using ffmpeg the application you're basically just fuzzing probing [23:20:38 CET] <kierank> but if you are finding crashes already you are doing well [23:21:18 CET] <ubitux> wm4: i don't know if any decoder does, but i would say it could (they would be at the same time though) [23:21:23 CET] <rcombs> valid header, then fuzz after that [23:21:26 CET] <kurosu> kierank, how would you achieve the restricting of tests? dependency tracking? current build system? [23:21:26 CET] <proxima> this https://github.com/OpenBroadcastSystems/fffuzz [23:21:28 CET] <ubitux> wm4: i didn't change that api (ms) [23:21:49 CET] <kierank> kurosu: do that in the corpus [23:21:57 CET] <kierank> so h264 just fuzzes h264 [23:22:04 CET] <wm4> ubitux: that seems strange, so the start time stamp is in the timebase, while the duration is in ms? [23:22:17 CET] <ubitux> yeah, i don't know why it's done like that [23:22:25 CET] <ubitux> i kept the structure as is [23:22:26 CET] <kurosu> kierank, yes, but how do you map a source file to a subsystem/codec/... ? [23:22:36 CET] <kierank> kurosu: plan was to use the commit message [23:22:36 CET] <ubitux> wm4: and yeah it's stupid IMO [23:22:44 CET] <wm4> ubitux: maybe this is something that could be fixed when going to AVFrame [23:22:46 CET] <kierank> kurosu: and ignore utils etc [23:23:03 CET] <kierank> not ideal but on average the crashes are in the codec or demuxer [23:23:19 CET] <kurosu> kierank, ok, sounds somewhat fragile, but as fragile as a Makefile solution [23:23:21 CET] <ubitux> wm4: so for libass, i'm doing this: [23:23:22 CET] <ubitux> const int64_t start_time = av_rescale_q(sub.pts, AV_TIME_BASE_Q, av_make_q(1, 1000)); [23:23:24 CET] <ubitux> const int64_t duration = sub.end_display_time; [23:23:37 CET] <kierank> kurosu: the worst that could happen is that the wrong files are fuzzed [23:23:40 CET] <kierank> no harm in that really [23:24:10 CET] <ubitux> gtg [23:54:28 CET] <kierank> durandal_1707: is it possible in libavfilter to get volume loudness overlaid onto video [23:55:45 CET] <durandal_1707> overlay+showvolume? [23:57:00 CET] <durandal_1707> define what you want exactly [23:59:55 CET] <Compn> maybe he wants volume bar like mplayer has ? [00:00:00 CET] --- Sat Feb 27 2016

1 0

ffmpeg.log.20160226
by burek 27 Feb '16

27 Feb '16

[00:00:02 CET] <julius> this one can do 30fps, but the picture isnt that great [00:00:24 CET] <Interrogator> ok i will try that [00:00:26 CET] <julius> how about the c310 - ever used that one? [00:00:33 CET] <julius> its a logitech [00:03:18 CET] <jkqxz> I could believe that I recognise it, but I don't remember it specifically. Sorry. [00:04:01 CET] <TD-Linux> the ps3 eye is $7 on amazon and can hit 120fps [00:04:23 CET] <TD-Linux> though it's designed for computer vision, not visual quality. it gives extremely stable frame rates at the expense of noise [00:06:18 CET] <julius> maybe i should get the 920 [00:10:09 CET] <Interrogator> [tls @ 03e20a60] The TLS connection was non-properly terminated. [00:10:09 CET] <Interrogator> https://www.youtube.com/watch?v=jkvbfirXJmU: Input/output error [00:10:34 CET] <Interrogator> it s what im obtaining as report [00:13:54 CET] <firewated> what are you trying to do? [00:15:51 CET] <firewated> i got that error message when inputting the youtube url as an input to ffmpeg [00:16:32 CET] <firewated> i was suggesting you use youtube-dl to get the direct link to the audio and video files using the "-g" option, then feeding as an input to ffmpeg [00:17:16 CET] <julius> TD-Linux, whats the "ps3 eye" ? [00:17:29 CET] <TD-Linux> julius, search on google or amazon [00:18:17 CET] <TD-Linux> wow it's now $5 in my region [00:18:18 CET] <TD-Linux> buy 10 [00:19:18 CET] <J_Darnley> The eye toy was my favourite webcam [00:19:30 CET] <J_Darnley> at least until MS killed unsigned drivers [00:22:43 CET] <julius> TD-Linux, hey, thank you [00:22:57 CET] <julius> that actually looks like a perfect solution [00:23:41 CET] <julius> i can oversee ms mistakes, i have forgiven them a long time ago [01:15:06 CET] <maziar> what is the best way to convert mp4 ? [01:15:13 CET] <maziar> is any one here ? [01:20:08 CET] <x86iac> to ? use ffmpeg to avi ? [01:21:41 CET] <maziar> x86iac to make multiple quality from 1080.mp4 to 720.mp4 and 480.mp4 [01:23:24 CET] <x86iac> answer is still ffmpeg [01:24:44 CET] <x86iac> you want to see man page -s [01:27:33 CET] <J_Darnley> or this http://trac.ffmpeg.org/wiki/Encode/H.264 [14:11:13 CET] <mrec> can yadif be used without the graph functions? [14:13:07 CET] <mrec> the stream detection functions are just extremely slow so I'm not using those [14:13:23 CET] <mrec> so basically at the moment I only use the decoder and do the rest myself.. [14:13:39 CET] <mrec> back to filters it seems that the ffmpeg streamdetection functions should be used again? [14:13:42 CET] <mrec> all a bit confusing [14:14:33 CET] <J_Darnley> What "graph functions"? [14:14:44 CET] <J_Darnley> -vf yadif is all you needto use it [14:15:10 CET] <mrec> I'm trying to write a player myself [14:15:20 CET] <J_Darnley> oh API use [14:15:41 CET] <mrec> the API is quite dirty.. [14:15:42 CET] <J_Darnley> you don't want to use the "magnificent" libavfilter API? [14:15:59 CET] <mrec> yes, because it doesn't work well it seems [14:16:07 CET] <J_Darnley> Then you will have to cut the yadif code out [14:16:28 CET] <Mavrik> Huh, what exactly doesn't work on the filtergraph api? [14:16:46 CET] <mrec> with the "reimplementation" of certain things I can change channels within 1 sec, by using the API well it's messy [14:17:02 CET] <mrec> change channels = restart another stream and get a visible picture [14:17:21 CET] <J_Darnley> The filter rests on top of the internal API providd by libavfilter [14:17:45 CET] <J_Darnley> Mavrik: lots [14:17:46 CET] <Mavrik> mrec, what's messy? [14:17:53 CET] <Mavrik> J_Darnley, I mean it's not pretty [14:17:58 CET] <Mavrik> J_Darnley, but it certanly does work. [14:18:05 CET] <mrec> more or less the whole libav API [14:18:10 CET] <J_Darnley> But no one undertsands how it works. [14:18:17 CET] <Mavrik> J_Darnley, ? [14:18:30 CET] <mrec> I tested several "ffmpeg" libraries for android and none of them work for playing mpeg-ts [14:18:46 CET] <J_Darnley> I'm not going to repeat my arguments from a couple of years ago. [14:18:58 CET] <mrec> I have done some implementation by using libavcodec a year ago and that works smooth even on android [14:19:19 CET] <Mavrik> J_Darnley, well I guess you had some strong ones. [14:19:46 CET] <Mavrik> (I prefer to use libav API than deal with having to maintain filter code manually due to copypasting it out.) [14:20:07 CET] <Mavrik> mrec, well... ok :) [14:20:17 CET] <Mavrik> If you have anything specific to ask we can help I guess. [14:21:30 CET] <mrec> I'm playing from a live source (the libav api might be ok for filestreams) [14:21:45 CET] <mrec> the filter API I mean [14:22:04 CET] <Mavrik> O.o [14:22:31 CET] <Mavrik> That's... not connected at all. [14:22:53 CET] <Mavrik> Can you be specific about what the problems you have are? [14:23:41 CET] <mrec> how to use yadif without the graph api [14:24:07 CET] <mrec> guess I just have to spend some more time with it to come up with "better" questions [14:24:27 CET] <Mavrik> The answer is: you shouldn't. It's not split. [15:23:56 CET] <mrec> AVFormat->format = AV_PIX_FMT_YUV420P ? [15:24:07 CET] <mrec> (for example) [15:38:50 CET] <J_Darnley> sorry, is that a question? [15:55:15 CET] <EmleyMoor> Is there something I can do with ffmpeg to make my videos upload to YouTube more readily? [15:56:33 CET] <J_Darnley> What problem are you having? [15:57:35 CET] <EmleyMoor> J_Darnley: Just that YouTube is occasionally slow to process them and it recommends I make them into a streamable format first - pointing me to this page: https://support.google.com/youtube/answer/1722171?hl=en-GB [15:58:38 CET] <J_Darnley> What? This part "moov atom at the front of the file (Fast Start)"? [15:58:46 CET] <J_Darnley> -movflags +faststart [15:58:59 CET] <EmleyMoor> It isn't telling me how I'm non-compliant. [15:59:26 CET] <EmleyMoor> I will try that with my next upload though [15:59:38 CET] <J_Darnley> You haven't told us anything either? [15:59:45 CET] <J_Darnley> What do you have now? [16:00:12 CET] Action: J_Darnley has lost the ability to write correct sentences [16:01:01 CET] <EmleyMoor> Er... I told you the whole story as it is told to me by YouTube... I do know the codecs and frame rate are not the problem, but that's it. [16:17:20 CET] <BtbN> just don't use mp4 [16:18:11 CET] <BtbN> and youtube will allways transcode your video, so there is no point in localy transcoding it again from what you already have. [16:18:20 CET] <BtbN> Just remux it to mkv or at least move the moov atom. [16:57:21 CET] <mrec> J_Darnley: no already the answer heh [17:13:54 CET] <m3gab0y> hi guys, any suggestions on how to do 2-pass transcoding for HLS? [17:14:54 CET] <J_Darnley> Impossible if you expect to stream [17:15:06 CET] <J_Darnley> otherwise it is no different to usual 2-pass I guess [17:17:44 CET] <m3gab0y> I need it for streaming :) can't get anything usable at low bitrate [17:18:50 CET] <J_Darnley> 2-pass isn't a magic bullet that will 4k look perfect at 1Mbit [17:20:00 CET] <J_Darnley> perhaps you should explain what "usable at low bitrate" means [17:20:21 CET] <m3gab0y> I'm quite familiar with that- I just want to get something usable at 500 kbps - here is a good example of pushing h264 to the limits http://www.progettosinergia.com/flashvideo/advancedpostprocessing.html [17:23:26 CET] <m3gab0y> any good recommendation of getting out the best of ffmpeg at 500 kbps is more than welcome :-) [17:24:40 CET] <J_Darnley> use low resolution [17:24:45 CET] <J_Darnley> remove noise [17:24:52 CET] <J_Darnley> use slow settings [17:26:05 CET] <m3gab0y> any particular example setting you got in mind [17:26:05 CET] <J_Darnley> the second is difficult in ffmpeg, it lacks the best denoisers [17:26:15 CET] <J_Darnley> -preset veryslow [17:26:36 CET] <m3gab0y> I'm using the git-build, so it should be very recent version [17:30:44 CET] <EmleyMoor> BtbN: Yes, but it implies strongly it won't take as long in some set of circumstances. [17:37:01 CET] <BtbN> you won't get any usefull quality out of 500kbps, unless you are happy with 240p [17:50:59 CET] <yann|work> anyone with experience with the AVHWAccel around ? [18:00:30 CET] <jkqxz> yann|work: Just ask your question. [18:04:52 CET] <yann|work> I'm trying to understand how we're supposed to use the hwaccel code in libavcodec, but can't find much code on it [18:05:27 CET] <yann|work> looks like the closest to a doc would be ffmpeg*.c [18:06:08 CET] <jkqxz> Yeah, the canonical example is ffmpeg.c + ffmpeg_$HWACCEL.c. [18:43:27 CET] <m3gab0y> @J_Darnley Thanks for the suggestions! Got something decent using denoise and deblock filters! @BtbN It's 400x320 which is perfectly fine for the target devices that it's gonna be used on, see for yourself: http://test8:test8@188.166.34.164/test [19:35:50 CET] <Burlington> Hey folks. I am trying to stream an mp4 to an hdmi output device. If I use the output format "alsa", I am able to get audio to stream to the hdmi device, but no video. Any idea what output format to use to stream video to hdmi? [19:38:11 CET] <Burlington> http://pastebin.com/jGCC5yjU This works well to send the audio, but after a few hours of putzing around, I still can't sort out how to send the video to this output device. [19:42:15 CET] <relaxed> Burlington: use mpv [19:42:29 CET] <debianuser> Burlington: It's not up to ffmpeg. It's up to xorg and your video player. :) HDMI is just another way to attach a display. You can't "send" video to a display, but you can show it on the screen. Expand your screen to that display with your regular desktop environment settings (or maybe "nvidia-settings", if you use official binary driver), then just move video player window to that display. :) [19:43:50 CET] <debianuser> mpv, mplayer, vlc, smplayer... some gnome/kde players... any of them should work. [19:45:51 CET] <hexploit> Im trying to concat two mp4 for files using concat demux. One of the mp4 files does not have an audio track (stripped using -an) while the other does. The end result of concatenation is a file that does not have an audio track. Relevant outputs are here: http://pastebin.com/TQAwB4Xn . Am I missing something? [19:46:37 CET] <relaxed> hexploit: the file you concat need to match in regards to video/audio streams [19:47:46 CET] <hexploit> relaxed: I tried adding a blank sound stream to the first mp4. In that case there is an audio stream but still no sound [19:50:42 CET] <relaxed> dd.mp4 lacks an aac audio stream [19:51:38 CET] <Burlington> @relaxed Thank you. I did try that, but then I receive this as an output: http://pastebin.com/dZD0xrs0 [19:52:22 CET] <J_Darnley> mpv is another piece of software, not an output device [19:52:35 CET] <relaxed> Burlington: mpv is a serperate program for playing video files [19:53:41 CET] <hexploit> relaxed: for that I tried creating another file using ffmpeg -f lavfi -i aevalsrc=0 -i dd.mp4 -vcodec copy -acodec aac -map 0:0 -map 1:0 -shortest -strict experimental -y ddd.mp4 [19:53:42 CET] <relaxed> separate* [19:53:55 CET] <hexploit> and tried concatenating that [19:54:01 CET] <Burlington> @debianuser Thank you. I am trying to understand this. I have a secondary monitor connected via hdmi. Ultimately, I am trying reciv [19:54:23 CET] <Burlington> receive a video network stream and have it output to a clean hdmi line... [19:54:58 CET] <hexploit> in that case there was an audio stream in the final output but still no sound [19:55:44 CET] <relaxed> Burlington: with ffmpeg you're using the wrong tool for the job. Either use mpv, https://mpv.io/ , or vlc (which has a gui and might be easier for you) [19:56:47 CET] <Burlington> @relaxed Thank you! I've used ffmpeg for years now and I love it. perhaps, you are right that VLC is a better tool for what I am trying to accomplish. This is all CLI. [19:57:37 CET] <relaxed> mpv is the best video player, and also is cli [19:58:02 CET] <relaxed> ffmpeg is a transcoder [20:04:41 CET] <relaxed> hexploit: from the pastebin dd.mp4 clearly doesn't have an audio stream [20:05:28 CET] <hexploit> yeah it doesnt. I agree. Thats why I created a separate file with a blank audio stream [20:06:48 CET] <relaxed> see if this works, MP4Box -cat 1.mp4 -cat 2.mp4 -new combined.mp4 [20:09:07 CET] <Burlington> @relaxed do you have thoughts on ffplay? could that do the job? [20:10:13 CET] <hexploit> will look into it. thanks [20:10:50 CET] <relaxed> Burlington: no, ffplay is more for testing than anything [20:30:38 CET] <Skull0inc> hello [20:32:45 CET] <Skull0inc> just wondering if anyone knew if it would be possible to emulate DVR saving from an rtsp stream using ffmpeg? By that I mean to save a single stream to a fixed output size and constantly overwrite fifo format of that file. [20:34:32 CET] <ChocolateArmpits> Skull0inc: look into segment format [20:34:44 CET] <kepstin> Skull0inc: could do it with the segment muxer and an mpeg-ts output [20:34:51 CET] <ChocolateArmpits> hls is based on that and it supports such behavior [20:43:09 CET] <Skull0inc> hmm, ok. [20:46:45 CET] <mrec> I wonder did anyone use libavcodec on android for playing back mpeg2 videos? [20:46:55 CET] <mrec> I wonder if anyone achieved the 50fps [20:47:53 CET] <mrec> I'm currently playing the video at 25fps (just using the normal yadif 25fps deinterlacer) [20:48:12 CET] <Mavrik> yadif is incredibly CPU expensive [20:48:32 CET] <Mavrik> Doing playback with SW decoder and yadif on a mobile phone at 50fps is probably going to work only on a few really fast devices. [20:49:03 CET] <mrec> I'm sure that won't work easily yes [20:49:21 CET] <mrec> do you have any experience with mpeg2 playback on mobile devices? [20:49:42 CET] <mrec> I wonder if there's any way [20:50:21 CET] <mrec> I'm not only targetting the mobile devices there are quite a few android media players out there [20:52:52 CET] <Mavrik> Well, first I'd thrmf [20:52:55 CET] <Mavrik> eh, sorry. [20:53:05 CET] <Mavrik> First I'd check if the device HW decoder supports MPEG-2 and use that. [20:53:13 CET] <Mavrik> Then fallback to SW decoding on as many cores as possible. [20:53:22 CET] <Mavrik> If possible render to OGL surface. [20:57:55 CET] <TD-Linux> mrec, on android I can play back 1080p VP9 in software, so I really hope you can achieve mpeg2 playback in software :) [20:59:23 CET] <Mavrik> on top 10% of devices only? [21:04:12 CET] <mrec> TD-Linux: mpeg2 playback is no problem but I'm concerned about smooth 50fps [21:04:27 CET] <mrec> that also requires deinterlacing of course [21:05:39 CET] <mrec> deinterlacing is just an option anyway I'm using the GPU for displaying the YUV frames onto the screen [21:06:09 CET] <mrec> I figured out how to use the filter graph stuff it's not so difficult (I just expected it to be much more difficult ^^) [21:07:36 CET] <GreaseMonkey> if you can do 1080p vp9 you can probably do 50fps mpeg2... as for deinterlacing you can probably do that in a shader [21:10:05 CET] <kepstin> just using anything simpler than yadif would bee a good start, yeah [21:10:47 CET] <kepstin> (ideally, you'd deinterlace the video before encoding, to make the stream smaller and easier to decode, of course...) [21:11:07 CET] <mrec> I'm playing back live source (DVB) [21:38:37 CET] <kasd11> heyho, can i do something like 4 point distortion with ffmpeg filters? googling only gave me an imagemagick example but i need to do it realtime. this is what i am talking about http://silveiraneto.net/2014/12/07/imagemagick-four-point-perspective-disto… [21:39:48 CET] <kasd11> i should have searched for "perspective" :) this seems to be it https://ffmpeg.org/ffmpeg-filters.html#perspective [22:10:49 CET] <antiPoP> hi [22:11:46 CET] <antiPoP> This command: "ffmpeg -i $videofile -c:v libx264 -preset ultrafast $new_video" only converts the video to x264 without changing resolution and and copies the audio, right? [22:13:16 CET] <kepstin> antiPoP: unless you add -c:a copy it will re-encode the audio (to a codec selected automatically based on output format) [22:13:30 CET] <kasd11> antiPoP, nope, by default it will convert the audio to vorbis [22:13:33 CET] <kasd11> ah [22:14:00 CET] <antiPoP> so it will convert to ogg vorvis then? [22:14:09 CET] <antiPoP> wchi bitrate [22:14:10 CET] <kasd11> trust him, not me [22:14:14 CET] <kepstin> antiPoP: it depends on the output format. mp4 defaults to aac, for example. [22:14:21 CET] <kepstin> if you want it to copy, use -c:a copy [22:14:24 CET] <antiPoP> (I'm new to ffmpeg and I just found this on the code) [22:14:55 CET] <antiPoP> kepstin, so in te case of x264 is vorbis, right? [22:15:08 CET] <antiPoP> shouldn't be mp3? [22:15:14 CET] <kasd11> x264 is the codec, not the output format (=container) [22:15:15 CET] <kepstin> antiPoP: it depends on the output file format [22:15:20 CET] <kasd11> that is mp4, mkv, avi etc [22:16:17 CET] <antiPoP> it's mp4 [22:18:25 CET] <GreaseMonkey> x264 has nothing to do with audio [22:19:02 CET] <GreaseMonkey> i think mkv typically uses ogg vorbis, and mp4 typically uses aac [22:19:14 CET] <GreaseMonkey> mp4 also typically sucks horrendously [22:19:23 CET] <antiPoP> https://trac.ffmpeg.org/wiki/Encode/H.264 I can't find any info here [22:19:56 CET] <antiPoP> GreaseMonkey, well, it's web video and seems well supported by the player... [22:19:57 CET] <kepstin> antiPoP: that's because h264 is a video codec; of course there wouldn't be anything about audio on that page. [22:20:07 CET] <kasd11> please read up on the basics of video formats, codecs, containers and so on. otherwise this is all super confusing ;) [22:20:08 CET] <kasd11> take care [22:20:11 CET] <GreaseMonkey> (you can work around the moov atom nightmare but it tends to do buffer e.g. 16 video frames, then e.g. 16 audio frames) [22:20:33 CET] <antiPoP> well, tehre is a mention to copy audio, but it doe snot says with which audio format is rencoded [22:20:59 CET] <GreaseMonkey> antiPoP: to be blunt i'd seriously consider even .flv instead of .mp4, if you want streamable .mp4 you need a special option to drop the moov atom in early [22:21:52 CET] <GreaseMonkey> although .webm is probably a better option unless you need to livestream (x264 encodes stuff fast, libvpx does NOT) [22:22:05 CET] <kepstin> antiPoP: that's because the automatic selection depends on many factors. if you want a specific codec, you should specify one. [22:22:09 CET] <GreaseMonkey> as far as i care mp4 is NOT a streaming format [22:22:33 CET] <GreaseMonkey> for flv: -f flv -vcodec libx264 -acodec libmp3lame [22:23:25 CET] <GreaseMonkey> for webm: -f webm -vcodec libvpx -acodec libvorbis (and then you usually change the quality setting as it usually produces a nasty image at the defaults) [22:24:29 CET] <antiPoP> well, I'm using http://videojs.com/ as player [22:24:35 CET] <GreaseMonkey> webm [22:24:49 CET] <GreaseMonkey> really, just use webm [22:25:16 CET] <antiPoP> what I want is to be able to have multiple resolutions in the player [22:25:30 CET] <antiPoP> what the current code does not do [22:25:57 CET] <GreaseMonkey> then you'll want to find some sort of irc channel for video.js [22:26:05 CET] <GreaseMonkey> oh and one more thing [22:26:13 CET] <antiPoP> I also have read about making a container with multiple resolutions so the player chooses automatically the stream... [22:26:22 CET] <GreaseMonkey> apparently, "-movflags faststart" is what you need to make a streamable .mp4 [22:26:47 CET] <GreaseMonkey> if you have a container with multiple resolutions it's a waste of bandwidth, you'll want multiple files instead [22:27:25 CET] <derekprestegard> hey guys - Im trying to do segment encoding (e.g. take one video and process many chunks of it in parallel using many machines and then re-assemble the results). It works fine for a relatively small number of segments like 18x 5 min chunks for a 90 min movie but when I try to do 90x 1 min chunks I end up with an audio desync. Does this sound familiar to anyone? [22:27:49 CET] <antiPoP> GreaseMonkey, ok thanks, ill check webm [22:28:11 CET] <antiPoP> and the movflags option [22:28:18 CET] <TD-Linux> derekprestegard, yes, my first recommendation is to *not* segment the audio when encoding [22:28:26 CET] <J_Darnley> GreaseMonkey: for an extremely loose definition of streaming. [22:28:41 CET] <derekprestegard> TD-Linux: indeed, we handle audio separately as a parallel process on a single machine [22:28:58 CET] <TD-Linux> and you still get desyncs? sounds like a muxer bug [22:29:08 CET] <kepstin> derekprestegard: all constant-framerate content? [22:29:15 CET] <derekprestegard> we have ffmpeg make mp4 files, then join them with mkvmerge [22:29:16 CET] <derekprestegard> kepstin: yes sir [22:29:26 CET] <derekprestegard> then ifnally back to mp4 with faststart including audio [22:29:44 CET] <derekprestegard> I am going to check frame counts to see if were introducing addional frames somewhere [22:31:00 CET] <dystopia_> why do you go to mp4 to mkv to mp4 [22:31:14 CET] <dystopia_> why not just cat the mp4 files [22:31:18 CET] <derekprestegard> just because mkvmerge was something that I knew could stitch mp4s together well :) [22:31:26 CET] <dystopia_> use mp4box [22:31:42 CET] <derekprestegard> would I have timestamp issues? I dont use -copyts when segmenting [22:32:02 CET] <dystopia_> mp4box -fps frameratehere -cat file1.mp4 -cat file2.mp4 -cat file3.mp4 output.mp4 [22:32:05 CET] <dystopia_> for example [22:32:16 CET] <derekprestegard> thats handy [22:32:23 CET] Action: TD-Linux really hopes this isn't yet another "how long is the last frame" [22:32:45 CET] <derekprestegard> do you think mkvmerge is introducing problems? [22:33:41 CET] <dystopia_> probably not [22:36:06 CET] <TD-Linux> you are converting timebases twice, lots of room for bugs [22:45:17 CET] <derekprestegard> so our logic is -ss $startTime -i $input -to $chunkDuration [22:45:47 CET] <derekprestegard> so if I want to do 1 min chunks Id do -ss 0 -i $input -to 60, then -ss 60 -i $input -to 60 [22:45:49 CET] <derekprestegard> right? [22:46:13 CET] <furq> -t 60, not -to 60 [22:47:08 CET] <derekprestegard> really? even though were not using -copyts? [22:47:21 CET] <furq> oh. maybe not then [22:47:25 CET] <derekprestegard> :) [23:10:17 CET] <antiPoP> is possible to only specify the vertical resolution (eg 240) so the the horizontal one is calculated automatically? [23:10:48 CET] <kepstin> antiPoP: if you use the scale filter, yes; read its docs for details. [23:11:09 CET] <antiPoP> kepstin, https://trac.ffmpeg.org/wiki/Scaling%20(resizing)%20with%20ffmpeg here? [23:11:37 CET] <antiPoP> yes, thanks [23:12:01 CET] <kepstin> antiPoP: i'd start with https://www.ffmpeg.org/ffmpeg-filters.html#scale-1 but the wiki might have some helpful examples [23:12:19 CET] <SebastianThorn> Hello, im looking at this but i dont understand where the file of the first pass gets saved? https://wiki.archlinux.org/index.php/FFmpeg#Two-pass_x264_.28very_high-qual… [23:12:40 CET] <JEEB> why would it get saved? [23:12:42 CET] <SebastianThorn> is it just an example that saved to /dev(null? [23:12:58 CET] <kepstin> SebastianThorn: the video statistics from the first pass are stored in a text file in the current working directory [23:13:07 CET] <SebastianThorn> ok, then i dont understand how it works [23:13:12 CET] <kepstin> the video output isn't needed, so it's thrown away [23:13:13 CET] <SebastianThorn> kepstin: ahh, ok [23:13:36 CET] <JEEB> 1st pass is to get statistics of the video (but the video is still created if you really want it), second pass is where that information is then used [23:13:40 CET] <SebastianThorn> i thought that the first pass created a file for the second pass to use [23:13:53 CET] <JEEB> it does, but outside the usual output file name [23:13:57 CET] <SebastianThorn> JEEB: ok, thanks verry much [23:14:14 CET] <furq> SebastianThorn: "very high-quality" on that page is misleading, 2-pass is only useful if you want to hit a specific bitrate [23:14:29 CET] <JEEB> aand yes, I was going to note that [23:14:30 CET] <furq> otherwise 1-pass crf is better [23:14:40 CET] <kepstin> (or specific filesize, which is the same thing as specific bitrate) [23:15:57 CET] <SebastianThorn> i bought a blyray set of all the James Bond movies and thought i try to rip then to play on my rpi2 using openelec (kodi). I tried with makeMKV and handbrake, but it lags when i run them, so i thight i take a couple of beers and try something else :) [23:16:41 CET] <furq> there shouldn't be much (if any) difference between handbrake and ffmpeg's output [23:17:04 CET] <furq> they both use the same underlying libraries [23:17:36 CET] <SebastianThorn> furq: i agree, but i wanna try it anyways, so i can autamate it when i find settings that works good for me [23:18:02 CET] <SebastianThorn> and i might learn somehing new :) [23:18:21 CET] <furq> well obviously ffmpeg is much better than handbrake, otherwise i'd be in #handbrake [23:18:52 CET] <SebastianThorn> i tried in #handbrade aswell, and google, but learning this might be good :) [00:00:00 CET] --- Sat Feb 27 2016

1 0

ffmpeg-devel.log.20160225
by burek 26 Feb '16

26 Feb '16

[00:03:21 CET] <cone-242> ffmpeg 03Paul B Mahol 07master:0d65a7d03304: avfilter/af_astats: clear all stats [00:08:56 CET] <cone-242> ffmpeg 03Michael Niedermayer 07master:6bc20e84d84f: avfilter/drawutils: Fix ff_fill_rectangle() on big endian [00:08:57 CET] <cone-242> ffmpeg 03Michael Niedermayer 07master:954f865c8ee2: avfilter/drawutils: fix gray and gbr formats on big endian [00:24:51 CET] <Daemon404> [22:49] < TD-Linux> BBB, chrome decides that if it's MSE then it's bt 709 <-- i hope youre joking [00:25:10 CET] <Daemon404> unless you mean non unflagged streams only [00:26:10 CET] <TD-Linux> Daemon404, nonflagged only [00:26:34 CET] <TD-Linux> the only part I'm miffed about is them not flagging YT tracks [00:26:35 CET] <Daemon404> ok [00:26:54 CET] <Daemon404> our (vimeo's) are all flagged properly, so it isnt my problem...\ [00:26:55 CET] Action: Daemon404 runs [00:36:13 CET] <ethe> If I require cus' patch for one of mine, then I guess I have to convince him to submit it first, or can I do it on his behalf? [00:37:01 CET] <ethe> I spoke to him about my patch, and he said the only think blocking his was that mine didn't exist yet. [00:37:38 CET] <ethe> sorry for being such a pain. I'm still very new to contributing open source [00:47:30 CET] <JEEB> ethe: if it's a useful patch you can throw it into review if you think it's ready for that. of course, asking if the guy think it's ready for that as well probably is a good idea as well. [00:47:58 CET] <JEEB> tl;dr just get the authorship right [00:48:45 CET] <ethe> JEEB: oh yeah, that's not a bad idea. [02:09:18 CET] <Jung> hi, can any one tell me why ffmpeg use YUV420P as default decoding output and most hardware decoders use nv12? [02:12:40 CET] <BBB> Jung: its just an implementation tidbit [02:12:47 CET] <J_Darnley> because much was written before things started using nv12 [02:15:06 CET] <iive> nv12 have 2 planes, Y and U/V interleaved, afair [02:16:07 CET] <iive> having then color planes interleaved is probably cache optimization, so you can process both blocks in parallel. [02:17:05 CET] <iive> it actually makes more sense if hardware decoders are in hm12 format, that is like nv12 but in 8x8 tiles/blocks [02:17:50 CET] <iive> i remember some experimental mpeg12 decoder that claimed dramatic speed boost by using that scheme on PC. [02:20:34 CET] <J_Darnley> Can anyone else replicate a crash with this command: ./ffmpeg_g -f lavfi -i testsrc=s=720x576:d=1:r=25,format=yuv420p -vcodec vc2 -strict -1 -threads 1 -f null - [02:20:52 CET] <J_Darnley> (on a clean master) [02:22:12 CET] <Jung> thanks [02:22:30 CET] <iive> Jung: don't forget, Y and UV are in different resolutions [02:24:50 CET] <Jung> @iive: I have to do format conver every time when i get decoded data from hardware and store them into AVFrame [02:25:04 CET] <iive> why? [02:25:41 CET] <iive> avframe should be able to hold any type of color format. [02:28:57 CET] <jamrial> J_Darnley: yes [02:29:14 CET] <J_Darnley> thanks for the confirmation [02:30:38 CET] <jamrial> seems to be a memset [02:31:07 CET] <atomnuker> ah, it's that memset [02:31:41 CET] <atomnuker> that memset zeroes out the padding [02:33:17 CET] <atomnuker> I'll troubleshoot both crashes (this one + the vsynth one) tommorow or on friday [02:34:18 CET] <atomnuker> J_Darnley: you can remove the memset without affecting anything as long as you keep the wavelet_depth set to 3 or lower [02:34:38 CET] <Jung> @iive: how to change output format in ffmpeg? [02:34:45 CET] <J_Darnley> okay, I'll note incase I can't find the problem [02:35:46 CET] <Jung> @iive: change avctx->pix_fmt value and store data in related sequence? [02:36:26 CET] <iive> Jung: let me ask you this way... how do you get the data that you are converting? [02:36:46 CET] <iive> you do use swscale for conversion, don't you? [02:37:00 CET] <Jung> yes [02:38:33 CET] <cone-242> ffmpeg 03Neil Birkbeck 07master:ad17b9d2d47a: libavcodec:add packet level support for mastering metadata [02:41:58 CET] <Jung> I have two way to covert. 1. through swscale; 2. write a simple coverting function. [02:42:28 CET] <Jung> I find 2 is more efficient than 1 [02:43:24 CET] <iive> really? [02:43:49 CET] <iive> we might summon michaelni to investigate ;) [02:43:53 CET] <iive> sorry gtg. [02:43:58 CET] <iive> n8 ppl [02:44:23 CET] <Jung> yes, my coverting function is very simple without any optimization [02:45:03 CET] <Jung> so, i think maybe there are some optimization options for configure? [02:53:58 CET] <Timothy_Gu> Jung: what is your operation? [02:54:26 CET] <Timothy_Gu> swscale should be fairly optimized, especially for simpler operations which have SIMD assembly [03:30:36 CET] <J_Darnley> atomnuker: I think the problem is when the height is not padded (p->dwt_height is equal to p->height), dwt_plane() uses all the available lines in the buffer [03:30:42 CET] <J_Darnley> buf is left pointing to the end of the memory block [03:31:17 CET] <J_Darnley> then some bad math results in writing to buf [03:31:33 CET] <J_Darnley> basically I think you want this diff: http://pastebin.com/jjuYak1B [05:52:45 CET] <cone-210> ffmpeg 03Matt Oliver 07master:7ecef5ed514e: avfilter/hwupload_cuda: Add missing semicolon. [10:24:06 CET] <kierank> so I guess I have to concede defeat [10:24:23 CET] <kierank> since nobody seems to have any interesting ideas for ffmpeg [10:24:29 CET] <kierank> and so we trot out the same gsoc crap as next year [10:24:33 CET] <kierank> last [10:45:45 CET] <wm4> I guess we should maybe think less about "what is something useful we could make the students do" to "what is something fun and engaging (even if useless) the students could do" [10:46:21 CET] <kierank> yes [10:54:09 CET] <iive> if they are getting paid, it's better be useful. [10:55:22 CET] <nevcairiel> iive: no, those projects are not meant to offer cheap labor for projects that noone else wants to do. students never pick those projects anyway, or if they do they dont get finished, so its not working in any case [10:55:39 CET] <nevcairiel> the actual point is to atract new contributors with an incentive to start working, and ideally stick around after [10:56:13 CET] <iive> you can do that, with your own money. [10:57:43 CET] <nevcairiel> you have to realize that there are more project offers than students, so boring tedious projects that no developed wanted to do before is not something thats going to convince a student to work for you [10:58:52 CET] <nevcairiel> its proof in itself that our gsoc page carries the same silly projects for years, simply because noone ever does them [10:58:52 CET] <iive> look, a lot of developers are working in projects only for fun. That's fine. [11:00:10 CET] <iive> money are motivator. if you don't use them for useful things, you are wasting them. [11:00:37 CET] <nevcairiel> gaining a new contributor that sticks around afterwards is certainly a useful thing [11:00:39 CET] <wm4> as nevcairiel said, it's about attracting talent [11:00:57 CET] <nevcairiel> you wont do that with annoying tedious tasks [11:00:59 CET] <iive> well, would that new contributor stick around for the boring parts? [11:00:59 CET] <wm4> for open source, talent is more valueable than money [11:01:54 CET] <nevcairiel> every project has its boring parts, but the first thing someone does should be interesting and engaging, or they wont engage to the project and leave [11:02:10 CET] <ubitux> the only way to keep someone who is getting paid to continue working on the project is to give him fun things to do [11:02:11 CET] <nevcairiel> if an interesting project engages a new contributor, he is more likely to also do boring work afterwards [11:02:18 CET] <ubitux> but most of the unpaid people already pick the fun things to do [11:03:42 CET] <nevcairiel> projects shouldnt be useless of course, because once the student realizes that it also removes a lot of the motivation, but projects also shouldnt be the same old boring ones from 5 years ago because we can't think of any interesting ideas [11:04:59 CET] <wm4> well, "useless" [11:05:26 CET] <wm4> there are many things being done that don't have a high need, but might be useful for some people in some situations, like all those filters [11:08:16 CET] <iive> well, i could agree that it is your personal fault for not been able to think of project(s) that are both useful and fun/engaging :P [11:09:02 CET] <wm4> sure, and yours as well [11:10:22 CET] <nevcairiel> maybe we just shouldnt participate for a year and try to come up with project ideas for 2017 now already, instead of rushing through that in 3 weeks again next winter =p [11:10:23 CET] <iive> can't take a joke :| [11:10:51 CET] <nevcairiel> its not a joke, its the truth, everyone here is to blame for not having any fun ideas =p [11:11:14 CET] <iive> that's because there is no low hanging fruit anymore [11:20:00 CET] <jkqxz> Better plant some more fruit trees, then. Once your orchard has been around for a few years, there will tend not to be anything with the right scope without doing something different. [11:26:39 CET] <iive> the problem is that we already cover the majority of the available assortments. Even some of the old and obscure ones (like video game decoders). [11:31:24 CET] <ank_95_> Hello, I am new to this organisation. I was looking through the project ideas and found them interesting. Can Somebody tell whether this org will be participating in GSOC'16 or not ? [11:33:59 CET] <nevcairiel> We have applied, but in the end google will decide if we take part [11:35:47 CET] <ank_95_> Okay, Thanks! [12:38:33 CET] <wm4> woah $15 bounty for demuxing hds [12:46:52 CET] <nevcairiel> wm4: better get on it, it can fund about half a day of food to sustain you while you work [13:04:16 CET] <Daemon404> lmao $15 [13:04:38 CET] <ubitux> looking for an arm/aarch64 instruct to do (a*b)>>16 where a and b are i16 [13:04:52 CET] <ubitux> would anyone knows that here? [13:08:05 CET] <wbs> ubitux: for neon there's vqdmulh, but that's also doubling at the same time (for some reason that I'm not familiar with) [13:08:39 CET] <ubitux> sqdmulh seems indeed to match the description [13:08:42 CET] <ubitux> thx [13:09:37 CET] <jkqxz> vmull (widening multiply) + vqshrn (right shift and narrow) would do it. [13:11:44 CET] <ubitux> jkqxz: not enough space [13:24:36 CET] <cone-142> ffmpeg 03Carl Eugen Hoyos 07master:03af008e21ca: doc/filters: Fix idet option name "rep_thres". [13:33:05 CET] <cone-142> ffmpeg 03Carl Eugen Hoyos 07master:0f31d401c35c: lavc/mjpegdec: Fix decoding images with Adobe_CM tag. [14:18:34 CET] <durandal_170> is ffmpeg work paid so cheap? [14:19:15 CET] <nevcairiel> if you find the right company, they tend to pay you decent money [14:19:20 CET] <J_Darnley> (if at all) [14:21:56 CET] <J_Darnley> Well damn. It doesn't crash any more but now I've got 300 lines of assembly to check for bugs [14:39:31 CET] <J_Darnley> Is ffmpeg supposed to be able to decode vc2 that it made itself? [14:39:52 CET] <ubitux> ethe: the dispatch.h check is not correct [14:40:02 CET] <ubitux> it only check for the header but it doesn't link to the library [14:40:12 CET] <ubitux> so link will fail if the header is present but there is no library [14:48:26 CET] <Daemon404> J_Darnley, i would think so... [14:48:44 CET] <Daemon404> but i dont remember the internal dirac decoder being amazing [14:49:15 CET] <nevcairiel> ubitux: cant you just overwrite shlibdir? I use --shlibdir="@loader_path" when building for OSX, something similar would work for iOS without a new option? [14:49:54 CET] <ubitux> this literally creates a @loader_path directory when doing a make install [14:50:13 CET] <J_Darnley> Daemon404: what containers other than raw vc2 would be a good idea for muxing it in? [14:50:20 CET] <nevcairiel> this is true, but i move it into an appropriate place after anyway [14:50:33 CET] <nevcairiel> iOS or OSX are not systems where make install is particularly useful =p [14:50:52 CET] <Daemon404> J_Darnley, i have no idea. [14:50:57 CET] <J_Darnley> oh well [14:51:22 CET] <ubitux> nevcairiel: i like to control both dir anyway [14:51:38 CET] <Daemon404> oh GOD [14:51:42 CET] <Daemon404> liekly/unlikely [14:51:44 CET] <Daemon404> kill me now [14:52:09 CET] <wm4> look forward to hundreds of patches adding it EVERYWHERE [14:53:17 CET] <jrosser> J_Darnley: poeple might expect vc2 in mxf [14:53:49 CET] <J_Darnley> thanks [14:53:54 CET] <J_Darnley> I sorted my issue [14:53:58 CET] <J_Darnley> mostly user error [14:54:23 CET] <J_Darnley> I needed to give a framerate when decoding the vc2 file [14:57:00 CET] <Daemon404> wm4, GNU codebases came to mind [14:57:12 CET] <Daemon404> and i dont think any GNU codebase is really... maintainable/readable. [14:57:27 CET] <Daemon404> not any of the core projects anyway [14:57:32 CET] <J_Darnley> wow, neat glitch art [14:57:40 CET] <wm4> we will convert to GNU coding style as well [14:57:54 CET] <wm4> for a speedy and free future [14:57:56 CET] <nevcairiel> i tried to find an issue in binutils once [14:57:59 CET] <nevcairiel> the code is so fucking ugly [14:58:27 CET] <nevcairiel> every second C construct is replaced by some crazy macro, every if has unlikely's [14:59:51 CET] <nevcairiel> interestingly i found my issue =p [15:00:02 CET] <Daemon404> how unlikely. [15:00:13 CET] <nevcairiel> was mingws fault afterall [15:00:29 CET] <nevcairiel> that was to be expected, yes, but still :p [15:01:09 CET] <ubitux> poor ganesh [15:01:30 CET] <ubitux> he was unactive for a while, and suddenly 2 angry devs jump at him at his first patch [15:01:32 CET] <ubitux> :D [15:02:00 CET] <nevcairiel> well he comes back with another idea for nuisance patches [15:05:39 CET] <Nithiya> Hi... I would like to work on the project " TrueHD encoder". Can someone please help me how to get started? [15:08:38 CET] <wm4> Nithiya: try to contact the mentor for this project [15:10:30 CET] <Nithiya> But she is not in the list [15:11:37 CET] <wm4> " Mentor: Ramiro Polla (ramiro in #ffmpeg-devel on Freenode IRC, ramiro DOT polla AT gmail DOT com) " [15:11:50 CET] <wm4> not on IRC, but there's a e-mail address [15:14:43 CET] <Nithiya> wm4: Thank you [16:19:26 CET] <ethe> ubitux: oh right, I'll make a patch for that quickly [16:19:27 CET] <ubitux> mmh new bsf api [16:19:36 CET] <ubitux> ethe: there is a patch on the ml already [16:19:53 CET] <ubitux> rcombs: how is this libav bsf api going to fit with your ffmpeg changes? [16:26:58 CET] <ethe> ubitux: so I dont need to do anything? Although, other systems could potentially have a working libdispatch/GCD as well--So maybe I need to add support for manually enabling, and checking for, it on other systems [16:27:12 CET] <ubitux> ethe: you can comment on the patch [16:28:50 CET] <ethe> err. yes... I can :) [16:33:29 CET] Action: J_Darnley wonders whether the output is better now than before [17:18:52 CET] <J_Darnley> okay, that output is definitely better [17:26:19 CET] <ubitux> can't make the preload useful in any way on aarch64 :( [17:26:35 CET] <ubitux> so i guess i'll push without it [18:06:37 CET] <Daemon404> does any sane person want to chime in with me on this img2dec mimetype thing [18:07:17 CET] <Daemon404> preferably someone who doesnt think webservers call 'file' [18:08:41 CET] <ubitux> heh, nice the csel instruction [18:09:34 CET] <wm4> Daemon404: well he admits that jpg might be problematic [18:09:51 CET] <Daemon404> heh [18:10:00 CET] <Daemon404> it's not just jpeg [18:10:04 CET] <Daemon404> it is a problem for all http/image [18:10:23 CET] <Daemon404> especially when stuff ends up getting detected as bloody mp3 [18:10:36 CET] <Daemon404> i dont get why you would not want to factor mimetype into probing [18:11:17 CET] <wm4> he has a point that at least stuff like PNG should be very reliable and cheap for probing (just a 4 byte magic at the start of the stream) [18:11:18 CET] <ubitux> images are just signal, depending on your PoV you can consider it sound [18:11:23 CET] <ubitux> :s [18:11:46 CET] <Daemon404> wm4, that's one sort of image only [18:12:04 CET] <Daemon404> wm4, btw i think you asploded the mp3 demuxer recently [18:12:10 CET] <Daemon404> i can make it loop infinitly over http [18:12:16 CET] <Daemon404> due to unchecke avio_seek i think [18:12:47 CET] <wm4> uh [18:13:08 CET] <Daemon404> it's requesting a http range past teh end of the file, and gettign a 416, and it increments the pos by one, forever [18:13:12 CET] <Daemon404> and keeps getting 416s [18:13:17 CET] <wm4> that ffio_ensure_seekback abomination? [18:13:25 CET] <Daemon404> possibly [18:13:48 CET] <Daemon404> it's next on my list of things to investiage [18:13:54 CET] <wm4> that code got pretty complex [18:14:04 CET] <Daemon404> it was blowing some stuff up because, lavf being lavf, detected a bunch of urls as mp3 [18:14:07 CET] <Daemon404> and looped infinitely [18:15:59 CET] <wm4> also lol @ mp3 probing [18:16:09 CET] <Daemon404> he mentions mpeg a bunch of times [18:16:11 CET] <Daemon404> i assume he means mp3 [18:16:30 CET] <wm4> I can still play random files in /bin as mp3 with lavf [18:16:49 CET] <Daemon404> you know [18:16:59 CET] <Daemon404> hmmm damn [18:17:07 CET] <Daemon404> i guess i cant disable just mp3 probing [18:17:13 CET] <Daemon404> because of the way its put in mov and stuff [18:17:20 CET] <Daemon404> during build, i mena [18:20:02 CET] <nevcairiel> Usually those are with extremely low scores, can't we make mp3 just ignore those files instead [18:24:34 CET] <wm4> low scores will skip some legitimate mp3s [18:24:59 CET] <Daemon404> i dont blame lavf for it, i blame whoever designed the mp3 format [18:25:07 CET] <nevcairiel> Then make the probe smarter? [18:25:33 CET] <wm4> many formats "support" id3v2 [18:25:44 CET] <wm4> and often id3v2s will contain large images [18:25:48 CET] <wm4> it's not so easy [18:25:54 CET] <Daemon404> short of reading the whole file, you cant have a 100% accurate mp3 probe, afaik [18:26:05 CET] <nevcairiel> Then do that :p [18:48:22 CET] <atomnuker> J_Darnley: you can contain Dirac/VC-2 in Ogg and Matroska [18:49:22 CET] <atomnuker> both work with the encoder [18:50:25 CET] <atomnuker> you can also output it to a mpegts stream, to the dismay of some (probably not strictly standards compliant) and pipe that into a media player [18:57:24 CET] <wm4> <atomnuker> J_Darnley: you can contain Dirac/VC-2 in Ogg and Matroska <- sounds like one of those things only ffmpeg will be able to play [18:59:47 CET] <rcombs> wm4: now I'm imagining patching the program loader to pass unrecognized files through libavformat probing, and if applicable treating mpv as the program interpreter [19:00:13 CET] <rcombs> so you could mark a media file as +x and then run it as an executable [19:00:19 CET] <rcombs> (note: this is a TERRIBLE IDEA) [19:00:32 CET] <wm4> indeed [19:00:35 CET] <JEEB> mateo`: tried your v2 branch and it seems like there's some timestamp weirdness with libmpv [19:00:39 CET] <rcombs> /usr/bin/rickroll.mp4 [19:00:53 CET] <wm4> JEEB: did you make mpv feed it timestamps in microseconds or whatever? [19:01:30 CET] <JEEB> hmm,I don't think I did [19:02:07 CET] <atomnuker> wm4: well, AFAIK the ogg encapsulation is spec-compliant [19:02:17 CET] <atomnuker> (as given by the BBC themselves) [19:02:52 CET] <atomnuker> but yeah, I doubt anything else other than lavf has implemented that [19:04:42 CET] <Daemon404> you can use libogg + a ton of manual work if you hate life [19:09:26 CET] <BBB> ubitux: does that also fix shlibs on osx when not installing? [19:50:29 CET] <J_Darnley> atomnuker: thanks for the suggestion about containers [19:51:10 CET] <J_Darnley> I resolved my issue about the raw stream by just giving -r as an input option [20:08:42 CET] <ubitux> BBB: no idea; default behaviour isn't changed [20:09:08 CET] <BBB> I need to manually run name_install_tool every time I link any app with libav*.dylib [20:09:42 CET] <ubitux> yes, it saves this operation [20:46:09 CET] <wm4> jesus christ, I'm getting libav-devel mails on ffmpeg-devel [20:46:14 CET] <wm4> thanks a lot claws-mail [21:10:26 CET] <darkapex> atomnuker: As ramiro is unable to mentor for this GSoC term, would you like to mentor the TrueHD encoder project? [21:12:46 CET] <mateo`> JEEB: can you describe what is happening ? [21:13:06 CET] <JEEB> it keeps going either slower or faster, oscillating [21:13:10 CET] <JEEB> weird stuff [21:13:31 CET] <JEEB> in an earlier version of the decoder I used to get completely bonkers timestamps, but that doesn't seem to be an issue any more [21:14:17 CET] <mateo`> is it with a particular sample ? [21:16:21 CET] <JEEB> I tried one with mpv's matroska demuxer, and one with lavf [21:16:23 CET] <wm4> mateo`: keep in mind that by default mpv sends absurd timestamps to the decoder [21:16:32 CET] <JEEB> oh [21:16:34 CET] <wm4> that's because they're reinterpret-casted double values [21:17:14 CET] <JEEB> any params I can set to poke at that? [21:17:26 CET] <mateo`> btw, tomorrow i'll take some time to update the patchset and include all wm4 remarks [21:18:16 CET] <wm4> JEEB: vd_lavc.c uses microsecond timestamps specifically for mmal, you could enhance this [21:18:27 CET] <wm4> JEEB: should be just a line of code [21:20:34 CET] <JEEB> oh right [21:20:36 CET] <JEEB> that thing [21:20:42 CET] <JEEB> I might have poked at that once before [21:21:28 CET] <wm4> mateo`: I'm thinking we might have to expose the required codec timebase as a new field in AVCodecContext... [21:24:04 CET] <mateo`> why ? (i might be missing something here; i'm just forwarding the input pkt pts to the output frame pkt_pts) [21:25:26 CET] <wm4> because these decoders tend to mess with timestamps in deep ways [21:25:50 CET] <wm4> up to the point that if they're not in the unit they expect it might cause issues [21:25:58 CET] <wm4> (because they're trying to be too clever) [21:30:08 CET] <mateo`> sure, and it will be probably useful when i'll support surface output, because the timestamps you push to the decoder gets propagated to the surface timestamps and it could probably be useful to get the values scaled to microseconds (that's what the api is expecting) [21:34:09 CET] <cone-867> ffmpeg 03Matthieu Bouron 07master:666e2edc41b7: configure: add missing --strip option to show_help() [21:45:55 CET] <ubitux> damn, there are so much flavor of C version of yuv2rgb [21:48:41 CET] <ubitux> yuv2rgb_{X,1,2}_c_.. i'm curious about what these X, 1 and 2 mean [21:49:05 CET] <wm4> how long until you consider zimg a viable alternative? [21:50:45 CET] <ubitux> i didn't (completely) give up on subtitles, i'm not going to give up on sws :p [21:54:27 CET] <ubitux> btw, unless i'm mistaken, it looks like it's not going to process the border when the stride is not large enough [21:55:01 CET] <ubitux> i wonder if we need some kind of helper/fallback for most optimizations in sws [21:55:23 CET] <ubitux> such that unlaligned/odd padding are not processed in asm but simply as C [21:55:48 CET] <ubitux> asm process most of the pic, then you'd have a 2nd pass to fill the few remaining pixels [21:55:56 CET] <ubitux> probably not very cache efficient though [21:56:27 CET] <ubitux> doing it in asm itself is often very problematic [21:58:24 CET] <Compn> zimg uses graphicsmagick code [21:58:39 CET] <Compn> wonder why there was not much imagemagick / ffmpeg collaboration [22:00:11 CET] <ubitux> what kind of collaboration? [22:00:29 CET] <ubitux> Compn: it's like you're wondering about collaboration between gnome and kde [22:00:40 CET] <ubitux> "can we merge some code?" [22:01:42 CET] <Compn> more like google/on2 and ffmpeg or x264 and ffmpeg. [22:01:52 CET] <Compn> which both have been done... [22:02:05 CET] <wm4> <Compn> zimg uses graphicsmagick code <- the fuck? no [22:02:17 CET] <Compn> sharing optimized code that does the same thing in both projects is a thing :P [22:02:35 CET] <Compn> wm4 : https://github.com/buaazp/zimg/blob/master/src/zscale.c "* @brief scale image functions by graphicsmagick. [22:02:57 CET] <Compn> probably you are talking about some other part of the code. [22:03:04 CET] <wm4> wrong project [22:03:09 CET] <Compn> or that :D [22:03:09 CET] <Compn> lol [22:04:01 CET] <wm4> https://github.com/sekrit-twc/zimg [22:04:29 CET] <durandal_1707> Compn: what lies are you spreading? [22:06:02 CET] <fritsch> mateo`: you work on amlogic or mediacodec? [22:06:33 CET] <Compn> durandal_1707 : all of the lies. [22:06:41 CET] <mateo`> fritsch: mediacodec [22:06:45 CET] <fritsch> mateo`: if on amlogic, you need to sort the dts and remember that it is some kind of "streaming" codec, that uses it's own pts for dropping and rendering is done completely without influence [22:06:53 CET] <fritsch> mateo`: okay, then not that much of a beast [22:11:45 CET] <mateo`> thanks for the info (i'm not familiar at all with amlogic) [22:13:38 CET] <wm4> fritsch: that sounds so fucking broken [22:14:29 CET] <fritsch> yes :-( [22:14:45 CET] <fritsch> we currently investigate a way to get the "buffer" back [22:14:54 CET] <fritsch> so that we have more control on rendering [22:15:58 CET] <JEEB> ouch [22:17:30 CET] <JEEB> Compn: [22:17:31 CET] <JEEB> 23:14 < anon32> didn't know that buaazp project existed before I started [22:17:31 CET] <JEEB> 23:14 < anon32> it was originally meant to parody C.img [22:19:13 CET] <JEEB> wbs: just checked out the latest thing that is supposed to become the "Common Media Format for Segmented Media" spec. edit lists are tolerated, but only for *audio* delay [22:20:28 CET] <wm4> does libavformat export mp4 audio delay correctly yet? [22:20:42 CET] <wm4> because I haven't found out yet if it does (also, too lazy to read mov.c) [22:20:48 CET] <wbs> JEEB: what spec is that? [22:20:51 CET] <wbs> wm4: afaik it does [22:20:53 CET] <Daemon404> "mp4 audio delay" could mean like 5 different things [22:21:09 CET] <JEEB> wbs: something posted on mp4-sys [22:21:15 CET] <wm4> ok, I want to play m4a files gaplessly [22:21:19 CET] <wm4> which of the 5 things do I need [22:21:39 CET] <JEEB> pre-roll [22:21:39 CET] <wbs> wm4: ah, the end trimming probably isn't exported correctly though [22:21:56 CET] <JEEB> although no idea what itunes exports [22:22:35 CET] <Daemon404> cool kids only listen to optimfrog [22:23:29 CET] <JEEB> wbs: http://up-cat.net/p/bc0ac7c1 [22:25:14 CET] <JEEB> so basically using negative CTS offsets to make CTS offset zero @ sample[0] becomes canonical, and edit lists are only available for audio :D [22:25:29 CET] <JEEB> this is not a finished document, but yeah... [23:02:24 CET] <JEEB> mateo`: seems to have gotten fixed after adding mediacodec to mpv's timebase workaround :) sorry for poking [23:09:11 CET] <Compn> JEEB : i dont know if i'm supposed to lol or not [00:00:00 CET] --- Fri Feb 26 2016

1 0

ffmpeg.log.20160225
by burek 26 Feb '16

26 Feb '16

[00:02:50 CET] <DANtheBEASTman> https://upload.teknik.io/jcQTV.webm this is with -b:v 2400k [00:22:49 CET] <yann||work> well, looking at my various search results, I can't even understand what the level of support of VDPAU support is (or of any hwaccel, for that matter) - could someone please shed some light ? [00:46:57 CET] <DHE> vdpau is for playback as I understand it. and it will be limited by your card's capabilities. mine does 1080p H264 pretty well using mpv or mplayer [01:31:17 CET] <t4nk524> Hello [01:31:29 CET] <t4nk524> I'm currently trying to build ffmpeg [01:32:00 CET] <t4nk524> I'm using ./configure --disable-all , then enabling all the protocols and filters that I need [01:32:32 CET] <t4nk524> ./configure --disable-all --enable-protocol=https [01:32:52 CET] <t4nk524> however, it seems that --disable-all triumphs all the enable flags [01:41:26 CET] <FFMPEGMASTER> HI SIR [01:41:42 CET] <FFMPEGMASTER> How may I help you [01:43:55 CET] <t4nk524> Hello [01:44:12 CET] <t4nk524> So, I'm trying to build the latest FFMpeg 3.0 manually [01:44:37 CET] <t4nk524> when I run ./configure --disable-all --enable-protocol -enable-openssl [01:44:54 CET] <t4nk524> when I run ./configure --disable-all --enable-protocol=https -enable-openssl [01:45:25 CET] <t4nk524> the output for the enabled protocols does not include the https protocol [01:45:30 CET] <FFMPEGMASTER> what is your environment? [01:45:39 CET] <t4nk524> it seems that --disable-all triumphs all the enable flags [01:46:02 CET] <t4nk524> Mac OS 10.10.5 (Yosemite) [01:46:42 CET] <c_14> You might also have to enable the http and tls protocols [01:46:58 CET] <c_14> Though those should get pulled in iirc [01:47:46 CET] <t4nk524> Let me try that "./configure --disable-all --enable-protocol=https,http,tls --enable-openssl" [01:48:17 CET] <t4nk524> The output for the ./configure command is empty for "Enabled protocols:" [01:49:50 CET] <t4nk524> This ./configure command worked in ffmpeg 2.5.3, and seems to be broken from >2.6 [01:50:01 CET] <t4nk524> Has the behaviour of --disable-all changed? [01:50:09 CET] <c_14> you need to enable-avformat [01:51:22 CET] <c_14> hmm, that only enables http and tcp though. not tls/https [01:53:14 CET] <t4nk524> mmm, I see that as well. [01:53:22 CET] <c_14> Right, enable tls_openssl instead of tls [01:58:47 CET] <t4nk524> Great, let me give that a shot [02:02:38 CET] <t4nk524> Woooo, that worked! I'm going to enable that flag in my actual project now. [02:02:40 CET] <t4nk524> thanks so much [02:03:18 CET] <t4nk524> One more question unrelated [02:03:28 CET] <t4nk524> Does FFmpeg support range header requests natively? [02:05:03 CET] <c_14> You mean HTTP byteranges, afaik yes. [02:05:25 CET] <t4nk524> Yes, http byteranges. [02:06:26 CET] <t4nk524> So when opening a stream using "avformat_open_input(...)", how do I insert the byte ranges into the header [02:07:23 CET] <c_14> the offset and end_offset options [02:07:28 CET] <c_14> to the http demuxer [02:11:00 CET] <t4nk524> great, would you be able to point me to a resource i could read more about byterange requests in ffmpeg? [02:11:26 CET] <c_14> https://ffmpeg.org/ffmpeg-protocols.html#http [02:13:38 CET] <t4nk524> and you've been very helpful today, is there a way to easily contact you in the future? [02:13:54 CET] <ethe> here, most likely. [02:14:04 CET] <c_14> I usually hang around here, feel free to highlight me. [02:19:16 CET] <t4nk524> great, see you around then [08:04:26 CET] <maziar> hi is there any body at there ? [08:06:03 CET] <squ> yes [09:50:13 CET] <mattf000> I am using ffmpeg + rtmp + nginx + flowplayer(flash) in an application where I am trying to display video captured by a usb3 capture card then streamed over wifi to android smart glasses. Problem is the device is locked down to 4.0.4. It does appear that hw decoding is taking place but my problem is just a bit of latency. [09:52:49 CET] <mattf000> Here is my ffmpeg command: http://pastebin.com/8bH0Reiv [09:52:59 CET] <mattf000> Can anyone advise on how to lower the latency a bit? [09:55:32 CET] <furq> mattf000: do you get unacceptable latency when playing back the stream with ffplay -fflags nobuffer [09:55:45 CET] <furq> if not then it's probably being introduced by the player [09:56:40 CET] <mattf000> when i stream to a computer the latency seems to be under 100ms .. but when i stream to the android device sometimes it gets bad [09:57:21 CET] <mattf000> the android is really my only use-case tho so streaming to a computer is fairly useless but it does tell me i'm hitting some limit of the device? [09:58:14 CET] <mattf000> as far as i can tell it's using the gpu to decode correctly ... i need the player to throw away frames to keep up with timestamps [09:58:19 CET] <mattf000> or something like that [09:59:34 CET] <furq> players normally buffer network streams by a few seconds to prevent dropouts [09:59:50 CET] <furq> you probably just need to find some way to disable that [10:00:00 CET] <furq> dropouts shouldn't be an issue if it's streaming over a lan [10:01:46 CET] <mattf000> I've got the client set to a bufferTime of 0. http://flash.flowplayer.org/documentation/configuration/clips.html [10:04:25 CET] <mattf000> any other ideas? [10:08:10 CET] <mattf000> should i look into a different codec maybe? [10:13:21 CET] <furq> if you're using rtmp then you've got no other choice [10:13:29 CET] <furq> i doubt it would make a positive difference anyway [10:15:26 CET] <furq> i take it you have to use a web player? [10:19:07 CET] <furq> i also take it you've changed the default nginx-rtmp settings, in particular buflen [10:19:26 CET] <furq> that might be overriding the player's settings [10:19:31 CET] <mattf000> yea i've set buflen but it also gets set by the client config [10:20:06 CET] <furq> have you tested with vlc for android or something similar [10:20:19 CET] <furq> or a computer on wifi [10:20:27 CET] <mattf000> i don't have to use a web player .. i only went with flowplayer flash because @ Android 4.0.4 my options are limited [10:20:40 CET] <mattf000> yes.. both actually [10:22:04 CET] <mattf000> the computer does well.. vlc on android isn't as reliable as the flash player [10:22:48 CET] <mattf000> Any suggestion on what I should be using for a chunk size? [10:23:14 CET] <mattf000> really haven't noticed a difference whether i use 128 or 4096 [10:23:27 CET] <furq> no idea, i've never had to tune for latency [10:23:54 CET] <furq> it wouldn't make a dent in the horrible inherent latency of hls [10:25:11 CET] <mattf000> how's the latency with MPEG-DASH? [10:25:17 CET] <mattf000> haven't looked yet [10:28:45 CET] <furq> i've never tried, but i would have thought it has the same problem as hls [10:29:19 CET] <furq> chunks aren't written out until a gop ends, so latency is inherently at least the length of one gop [10:29:54 CET] <furq> in my experience it's often much worse, but apparently you can tune that to some degree [10:30:23 CET] <furq> it sounds totally useless for your use case anyway [10:31:42 CET] <mattf000> yea i'm just looking for anything that can drop the latency a bit more .. or have the client catch up better if it falls behind from network fluctuations [15:10:48 CET] <petec> Hi I'm looking for a way to reset timestamps on a rtsp stream from a webcam. Its H.264 / pcm_alaw, vcodec copy, acodec aac, recording it as mp4. Pts drifts between audio and video with result that ffprobe displays negative start time in final file. I want to just throw away the timestamps on the incoming video and audio streams and get ffmpeg to create new ones based on its own time of packet reception. Any way to do this? TIA [15:11:48 CET] <petec> Did a full write up of the problem with logs at http://ffmpeg.gusari.org/viewtopic.php?f=11&t=2699 [15:12:17 CET] <termos> I'm getting a huge spike of packets in the start of transcoding, I have a suspicion that these are the packets used by the analyzeduration. Is there a way to flush this buffer and remove the huge spike of packets in the beginning? [16:00:19 CET] <||JD||> hey guys, is it possible to access ffmpeg from php without root/admin permissions? I mean, a library I can install myself in the user folder [16:07:07 CET] <JEEB> niin /win22 [16:07:13 CET] <JEEB> welp [16:17:04 CET] <humbledbysymfon1> Hi! Anyone doing html audio livestreaming with ffmpeg? [16:18:55 CET] <zyme> Didn't know you could do that, but it makes me wonder, [16:19:49 CET] <zyme> Can you stream to chromecast natively with ffmpeg or would you need a gateway app as a connector? [16:20:11 CET] <humbledbysymfon1> No idea about Chromecast. But HTML livestreaming: It works, actually pretty well, I get a delay of about 7-25s. Only thing I haven't figured out what to use at the other end. [16:20:44 CET] <humbledbysymfon1> I don't want to use the native browser support but a webplayer. I thought someone might have some experience with that... [16:23:31 CET] <zyme> VLC? [16:23:32 CET] <Mavrik> zyme, you need a gateway app [16:24:12 CET] <zyme> Its even got a ios port these days. [16:24:18 CET] <humbledbysymfon1> Zyme, thanks, vlc would work, but it needs to work in any browser. [16:25:18 CET] <zyme> Mavrik: know of any? [16:25:58 CET] <zyme> humbledbysymfon1: can't you just use html5? [16:27:24 CET] <kepstin> I found when testing it a while back that most browsers with html5 audio support can actually play an mp3 icecast stream reasonably well (although you have no control over buffering) [16:28:42 CET] <zyme> Flash, though its always having a critical exploit fixed, is supported by most browsers. [16:29:19 CET] <zyme> Otherwise... Silverlight? [16:29:28 CET] <humbledbysymfon1> kepstin: exactly, i was hoping to find a javascript player that I could configure in terms of buffering and thus reducing latency& And I was hoping to increase stability. [16:29:33 CET] <zyme> Maybe QuickTime [16:30:11 CET] <kepstin> humbledbysymfon1: javascript player won't help; they only do custom ui controls. all of the actual media path is done by the browser. [16:30:31 CET] <kepstin> (although if you're using MSE with a custom streaming protocol, you could maybe bypass that a bit...) [16:30:41 CET] <zyme> Javascript usually is what loads flash, and often has a check and fallback to html5 if not present, etc. [16:31:03 CET] <humbledbysymfon1> kepstin: What's mse? [16:31:46 CET] <kepstin> "media source extensions"; a way to feed media into the browser's decoder/playback engine in chunks. It's how javascript/html5 players implement hls and dash. [16:32:19 CET] <humbledbysymfon1> Can you recommend any javascript player? [16:33:30 CET] <kepstin> for this particular use case? haven't really heard of anything. [16:34:47 CET] <retard> kepstin: browsers will shit themselves when there's inline metadata changes htough [16:35:31 CET] <kepstin> hmm, I only tested it with a single continuous stream, tbh. [16:36:38 CET] <||JD||> Guys, is there a ffmpeg library I can install myself in a shared hosting plan? [16:36:40 CET] <retard> the metadata changes are multiplexed in the stream [16:36:48 CET] <retard> ||JD||: there are static builds? [16:37:20 CET] <||JD||> can you link them please? [16:37:45 CET] <J_Darnley> ffmpeg.org/download [16:38:02 CET] <retard> http://johnvansickle.com/ffmpeg/ [16:38:23 CET] <retard> http://ffmpeg.zeranoe.com/builds/ for windows [16:38:32 CET] <||JD||> thank you [16:50:10 CET] <humbledbysymfon1> kepstin: thanks! I need it for multiple streams and multiple users, but the streams can go to multiple instances of the javascript player [17:27:04 CET] <lroe> I'm trying to use hls.js to view an m3u8 stream. I'm looking at the docs and I ended up with: http://paste.debian.net/hidden/14e247cd/ [17:27:39 CET] <lroe> using some web developer tools chrome errors saying "Uncaught ReferenceError: Hls is not defined" [17:31:57 CET] <DHE> the documentation references dist/hls.js [17:39:47 CET] <zyme> I wonder if iis loads ffmpeg and i open a page which uses javascript to scream to itself and the chromecast extion is running in chrome i could make an on page/ tv interface four changing ffmpeg and relaunching it [17:40:31 CET] <zyme> The java app auto retrying to connect during the restart if ffmpeg streaming.. [17:41:15 CET] <zyme> Since the chrome extention mirrors the open page onto the chromecast... [17:43:14 CET] <zyme> The same iis site url could be open in in a different url as long as its the same application pool, for a web based controller page... [17:45:04 CET] <zyme> acctually I wouldn't need the java based web player, I have a HEVC extension in chrome for native support. [17:47:00 CET] <zyme> Might need the occasional open url on pc and click chromecast extention button, but otherwise quick dirty custom streaming of what I want to my chromecast. [18:08:48 CET] <EmleyMoor> I'm looking for a way to encode my videos in a "YouTube streamable" format, so as to speed up processing time. What do I need to do to achieve this? [18:12:31 CET] <kepstin> EmleyMoor: pick codecs and settings compatible with https://support.google.com/youtube/answer/1722171 , use mp4 container, use "-movflags faststart" [19:30:28 CET] <lroe> hallelulah I finally got rtsp->hls working using vlc, nginx, hls.js [19:30:49 CET] <lroe> but now when viewing the stream in a browser it seems to freeze randomly [19:31:00 CET] <lroe> and I have to refresh the page to get it started again [20:06:51 CET] <tEtra> this: https://www.pastery.net/aesgby/ [20:07:05 CET] <tEtra> is a bash script to rotoscope a video [20:07:44 CET] <tEtra> it works well to create the individual images, but putting them back togeher is driving me crazy [20:09:18 CET] <J_Darnley> I don't know what to say other than "use something that will work with a video stream" [20:10:15 CET] <tEtra> https://www.pastery.net/jkwywv/ is the console output of running script [20:10:35 CET] <tEtra> J_Darnley: are you saying that to me? [20:10:49 CET] <tEtra> if so, what does that mean? [20:11:00 CET] <J_Darnley> yes. [20:11:04 CET] <tEtra> I know absolutely zip about this stuff [20:11:21 CET] <J_Darnley> something that does not require hundreds of separate files [20:11:34 CET] <tEtra> I have modified the script extensively to get it to work as good as it doed [20:12:01 CET] <tEtra> why is that an issue for anything other than storage? [20:12:15 CET] <J_Darnley> because you said "but putting them back togeher is driving me crazy" [20:12:30 CET] <J_Darnley> Perhaps you should be more specific. [20:12:39 CET] <tEtra> yes, my bad [20:12:50 CET] <tEtra> please have a look at the output paste [20:13:11 CET] <J_Darnley> yeah, what about it? [20:13:17 CET] <tEtra> I think I am not encoding/decoding correctly [20:13:35 CET] <tEtra> input is a cell phone video [20:13:56 CET] <tEtra> No pixel format specified, yuvj444p for H.264 encoding chosen. [20:13:57 CET] <tEtra> Use -pix_fmt yuv420p for compatibility with outdated media players. [20:13:57 CET] <tEtra> [20:14:17 CET] <tEtra> I get this error, but if I try the suggested format, it barfs too [20:14:58 CET] <tEtra> let me ask a different way - how would you do it? [20:15:25 CET] <J_Darnley> I would start by finding out what "rotoscope" means [20:15:38 CET] <J_Darnley> Then I would look for a better tool to do whatever that is [20:15:59 CET] <J_Darnley> if I couldn't find one I would probably use png files [20:16:44 CET] <J_Darnley> then I would see whether "autotrace" can output something other than svg [20:16:49 CET] <J_Darnley> then I would make sure that it outputs uniformly sized images [20:17:04 CET] <J_Darnley> otherwise I might ask "convert" to do that. [20:17:49 CET] <J_Darnley> failing that I would try a scale filter in the final encoding command [20:18:02 CET] <tEtra> re: png: autotrace cannot input that format [20:18:10 CET] <tEtra> I was trying that initially [20:18:36 CET] <J_Darnley> yet it supports jpeg?! [20:21:04 CET] <tEtra> that test was before installing an additional libmagickcore-6.q16-2-extra package [20:21:15 CET] <tEtra> maybe it will work now [20:21:20 CET] <tEtra> I'll try that [20:21:35 CET] <tEtra> that J_Darnley! [20:21:38 CET] <tEtra> thanks [20:33:39 CET] <svip> I have been using the Capture/ALSA guide to record sound device output while it still plays through the speakers, but to no avail. [20:33:49 CET] <svip> The files ffmpeg produces are silent. [20:34:03 CET] <svip> https://trac.ffmpeg.org/wiki/Capture/ALSA << Last section. [20:34:43 CET] <c_14> You set it up just like in that section? [20:34:49 CET] <svip> Yes. [20:35:13 CET] <c_14> Is the application you're trying to record using the correct output device? [20:35:18 CET] <svip> Well, I do have two extra lines in the file: pcm.pulse { type pulse } and ctl.pulse { type pulse } [20:35:44 CET] <svip> c_14: Well, I am pretty certain it is, as it is coming out through the speakers and I can control its volume through alsamixer. [20:35:50 CET] <c_14> What are you trying to record? [20:36:20 CET] <svip> I am trying to record snippets of Spotify tracks. [20:38:26 CET] <c_14> Could it be that the application you're trying to record is using pulse? [20:38:41 CET] <svip> It is plausible. [20:38:50 CET] <c_14> try checking with pactl or something [20:38:55 CET] <svip> Pulse definitely seems to be somewhere. [20:39:09 CET] <ethe> I heard JACK is good for these things [20:41:48 CET] <svip> c_14: Yes, pactl list clients lists it as one of its clients. [20:42:13 CET] <c_14> Then you're going to either have to make the program use alsa or record over pulse. [20:42:24 CET] <svip> How do I record over pulse? [20:43:40 CET] <c_14> You have to insert some pulse modules afaik [20:44:09 CET] <c_14> https://dl.c-14.de/t/pulse_record_audio.svg <- so that it looks something like this [20:44:37 CET] <svip> Aha. [20:44:49 CET] <svip> Are the modules called that? [20:45:14 CET] <c_14> I believe so [20:49:58 CET] <svip> Hmm pactl won't let me load any modules. [20:50:28 CET] <svip> Someone suggested -f alsa -i pulse [20:50:33 CET] <svip> But that doesn't seem to work either. [20:52:41 CET] <c_14> pactl load-module module-null-sink <- that doesn't work? [20:53:11 CET] <svip> c_14: 24 [20:53:12 CET] <svip> It said. [20:53:32 CET] <svip> Apparently, I got the names wrong. [20:54:38 CET] <debianuser> svip: When recording from pulse you need to start ffmpeg recording from pulse default source, e.g. `-f alsa -i pulse` and then in `pavuconrol` "Playback" tab find your running ffmpeg and select its source to "Monitor of whatever card you're playing to". [20:57:08 CET] <debianuser> Ah, sorry, that should be "Recording" tab, not playback, as ffmpeg records sound :) [20:57:33 CET] <svip> debianuser: ! [20:57:38 CET] <svip> Great success. [20:58:27 CET] <debianuser> Great! \o/ [20:58:37 CET] <c_14> debianuser: You wouldn't happen to want to write the Capture/Pulse page on trac would you? (I don't have pulse...) [21:02:25 CET] <debianuser> c_14: I don't actually have it either. :) I just don't need its features, so I use just alsa. But the tutorial itself is the same: start `ffmpeg -f alsa -i pulse ...`, run `pavucontrol`, on "Recording" tab switch ffmpeg source to "Monitor of ..." your card. Example: http://osvideo.constantvzw.org/screencast-ffmpeg-with-sound/ Also see https://unix.stackexchange.com/a/162822 [21:04:51 CET] <debianuser> (The last https://unix.stackexchange.com/a/162822 is another option, using pulse backend with `-f pulse -i ...monitor ...`, you can see exact names in `pactl list`. But I'd still suggest `-f alsa -i pulse` way, it's easier to explain :) ) [21:05:51 CET] <c_14> Ah well, I'll just try and remember that then. [22:53:30 CET] <julius> hi [22:53:51 CET] <julius> can i ask a not strictly ffmpeg question, more about space usage of x264 question here? [22:54:06 CET] <J_Darnley> sure [22:54:33 CET] <J_Darnley> we don't stay strictly on tpoic [22:55:19 CET] <julius> says here: http://stackoverflow.com/questions/701991/h-264-file-size-for-1-hr-of-hd-vi… that h264 needs several gb per hour of recording [22:55:51 CET] <J_Darnley> depends on the content and what sort of quality you expect. [22:56:15 CET] <sfan5> or rather the encoding settings [22:56:37 CET] <julius> i would like to record my plants growing over 6 weeks, of course i dont need every second. what about a picture every 5 minutes at 1080p - is there a formula to calculate that or approximate? [22:57:06 CET] <sfan5> it's probably easier to just use jpeg for that [22:57:06 CET] <J_Darnley> filesize = bitrate * length [22:57:31 CET] <julius> ~12600 pictures [22:57:41 CET] <J_Darnley> I would expect that to be fairly easy to compress [22:57:49 CET] <julius> is there a "easy" way to get those jpegs later into a video? [22:57:59 CET] <J_Darnley> ffmpeg? [22:58:19 CET] <J_Darnley> wait, are the plants indoor or outdorr? [22:58:22 CET] <julius> didnt think about compression, but youre right, camera will be stationary [22:58:25 CET] <J_Darnley> *outdoor [22:58:26 CET] <julius> indoor [22:58:44 CET] <J_Darnley> good, no wind [22:58:55 CET] <J_Darnley> little motion [22:59:03 CET] <julius> the light changes, and the plans a little [22:59:04 CET] <J_Darnley> pretty easy to compress then [22:59:37 CET] <J_Darnley> sure, it isn't completely static [23:00:11 CET] <J_Darnley> but you aren't cycling the lights on and off for every other photo, ar you? [23:00:42 CET] <J_Darnley> The basic rule about video encoding is the the less that changes between frames the easier it is to compress. [23:01:01 CET] <julius> ok [23:01:09 CET] <julius> no, just daylight changing [23:01:24 CET] <julius> and later on i can just create a video with something like this? ffmpeg -r 25 -qscale 2 -i %05d.morph.jpg output.mp4 [23:01:50 CET] <J_Darnley> Yes (almost) [23:02:04 CET] <sfan5> https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images [23:02:11 CET] <julius> ah [23:04:23 CET] <J_Darnley> Saving each image separately is a good idea if you want to check on them by viewing an image. [23:04:33 CET] <J_Darnley> If you don't need to view the frames as they are being recorded then you might consider making the video directly. [23:05:01 CET] <J_Darnley> but I guess how easy that is depends on how you capture them. [23:05:16 CET] <julius> got a rpi2, with a usb webcam [23:05:49 CET] <julius> will write out to a usb stick or usb harddrive [23:06:10 CET] <julius> how do you record a video every x seconds? [23:06:37 CET] <TD-Linux> motion is a nice program that will grab a .jpg from your webcam every x seconds [23:06:47 CET] <furq> -framerate 1/300 [23:06:52 CET] <jkqxz> There are probably enough things which can go wrong that you'd be better off making images purely so that the intermediate state is verifiable, given the time that would be required for a second attempt. [23:06:54 CET] <TD-Linux> or that. [23:06:56 CET] <furq> i would probably just take pictures though [23:07:19 CET] <furq> running ffmpeg for six weeks sounds unreliable [23:07:51 CET] <firewated> if the power goes out or something, you could end up with a corrupted video file that's difficult to recover data from, better to stick with individual images [23:07:52 CET] <jkqxz> Making the video later is easy, and you get more than one attempt to get the settings right with the whole input. [23:08:06 CET] <julius> hm, ok makes sense [23:08:25 CET] <julius> excellent info here guys, thank you [23:08:44 CET] <furq> it's bad enough when i spend an hour encoding something and then realise i've used the wrong settings [23:08:56 CET] <furq> i'd be pretty annoyed if i had to spend another six weeks retrying [23:10:11 CET] <J_Darnley> these people all make good points [23:12:07 CET] <julius> again, not a real ffmpeg question. but maybe you have observed this. i tried 3 webcams so far (1 very cheap) but none of them did output like 30fps. all were like ~10fps. tested with cheese and another program, gcview or something. is the linux video camera support so bad? [23:12:52 CET] <J_Darnley> Make sure there is plenty of light on the subject [23:12:54 CET] <jkqxz> Are you somewhere with low light? [23:13:06 CET] <jkqxz> All webcams drop framerate down a lot in low light. [23:13:39 CET] <julius> hm, daylight [23:13:54 CET] <julius> "normal working" hours [23:14:09 CET] <J_Darnley> Maybe its just shit on the RPi2 [23:14:12 CET] <TD-Linux> uvc web cams generally work the same as on any other os. did you see better framerate on a different os? [23:14:13 CET] <firewated> could it be that the raspberry pi can't handle more than 10fps at the settings your running at? [23:14:32 CET] <jkqxz> What is your input format, then? You can't fit 720p raw video over USB high speed, so it has to be MJPEG or a smaller image. [23:15:33 CET] <julius> tested on a normal laptop [23:15:50 CET] <julius> can only test on linux, currently [23:16:54 CET] <firewated> tried lower resolution or bitrate? [23:17:32 CET] <julius> yes [23:17:50 CET] <julius> cheese had some options to go trough, even at 640x480....around 15fps [23:18:16 CET] <julius> so this is not a normal thing, one of the cams should have produced 30fps? [23:19:41 CET] <jkqxz> Assuming you don't have really cheap webcams or a really weak machine, yes. [23:20:52 CET] <julius> the laptop is old, but not that old. core i5 [23:21:17 CET] <TD-Linux> julius, is this the recorded video or the live view that you're seeing this btw? [23:21:49 CET] <kepstin> julius: a lot of usb webcams can only do higher framerates/resolutions when using mjpeg - try "-input_format mjpeg" on it [23:21:52 CET] <kepstin> maybe? [23:23:12 CET] <jkqxz> Lower resolutions will generally fix that anyway. The constraint is really the USB bandwidth. [23:26:43 CET] <jkqxz> Looking at "uvcdynctrl -f" on this rubbishy builtin laptop camera, I get 30fps up to 848x480 in YUYV, or 11fps 1280x720 in YUYV, or 30fps 1280x720 in MJPEG. [23:27:33 CET] <julius> TD-Linux, live...my hand movements before the lense were very sluggish [23:27:45 CET] <julius> i waas using my laptop for testing, it got usb2 [23:28:04 CET] <TD-Linux> julius, hmm. I get 60fps with cheese and my laptop webcam. it could be a terrible webcam, or potentially a really busted video driver [23:28:25 CET] <julius> jkqxz, i get that listing too [23:28:31 CET] <TD-Linux> er 30fps [23:28:42 CET] <julius> jkqxz, doesnt mean it records at that rate..does it? [23:29:31 CET] <julius> the built in laptop shows my hand very nicely. smooth [23:29:37 CET] <julius> let me look for one of the cameras [23:30:43 CET] <jkqxz> uvcdynctrl just dumps what the V4L2 UVC driver has worked out. The camera really will do that unless something is very broken. [23:40:24 CET] <julius> uvcdynctrl -d /dev/video1 -f says that 30fps@1920x1080 with MJPG should be possible. but guvcview -f mjpg -d /dev/video1 only gives me like 10fps. the laptop webcam, can do 30 at these light conditions [23:42:03 CET] <psycho_> This isn't strictly an ffmpeg question, but I figure there is probably overlap between mplayer and ffmpeg. I'm trying and failing to convert a gmp4 file. [23:42:26 CET] <psycho_> This is the console output. [23:42:27 CET] <psycho_> http://pastebin.com/NECc8UVy [23:43:00 CET] <psycho_> I think I ran into this issue a year ago, and forgot to document the solution, but needed a different version of either mplayer or mencoder. [23:44:50 CET] <jkqxz> julius: Ouch. That has always worked correctly in my experience, so I'm afraid I have no idea. [23:45:47 CET] <julius> ok thanks [23:45:52 CET] <julius> jkqxz, what webcam do you use? [23:49:24 CET] <jkqxz> I've used quite a few different ones. (Logitech C920 is still the best, despite being some years old now.) [23:49:38 CET] <julius> yeah, read about that one [23:49:43 CET] <julius> and quite expensive for my project [23:49:56 CET] <julius> what else did you use? [23:53:50 CET] <jkqxz> Not for a while, so I don't remember precisely. A lot of cheap ones, which tended to be unmemorable. The Microsoft ones were OK, though I remember them liking to make up weird colours. The expensive Logitechs were generally the best, though the C930 was a small step backwards from the C920. [23:57:02 CET] <Interrogator> is there any script witch can let ffmpeg download Youtube-videos instead of youtube-dl ? [23:57:55 CET] <firewated> you can get http links from youtube-dl which ffmpeg can use as inputs [23:58:25 CET] <jkqxz> Integrated ones built in to screens were consistently worse than plausible discrete cameras. [23:59:48 CET] <julius> jkqxz, yep [00:00:00 CET] --- Fri Feb 26 2016

1 0

ffmpeg-devel.log.20160224
by burek 25 Feb '16

25 Feb '16

[00:03:50 CET] <cone-585> ffmpeg 03Michael Niedermayer 07master:df36257a5356: swscale/input: Fix GBRAP16 input [00:03:50 CET] <cone-585> ffmpeg 03Michael Niedermayer 07master:67e5bd0c501f: swscale/utils: Fix chrSrcHSubSample for GBRAP16 [01:26:17 CET] <proxima> Explain about the qualification task(about fixing the crash using zzuf) mentioned for project Create a fuzzing testsuite for FFmpeg for Outreachy 2016. Please clear what kind of crash i.e. software or a simple file or any other specification? [01:30:09 CET] <iive> proxima: is that question to michaelni or somebody else? [01:31:00 CET] <Compn> iive : its to clarify the task [01:31:13 CET] <michaelni> proxima, ask kierank [01:31:29 CET] <Compn> proxima : crashes and memory leaks i'd guess [01:31:47 CET] <Compn> so it would have to tie in with valgrind [01:32:23 CET] <Compn> maybe you could assemble the different fuzzing tools, zzuf is one of them [01:32:46 CET] <proxima> okay, i tested that for a normal exe file. So, just wanted to know if we need to test on any ffmpeg program [01:33:28 CET] <Compn> probably ffmpeg program only. i dont think we currently fuzz test ffprobe/ffplay/ffserver [01:33:39 CET] <Compn> much. [01:33:48 CET] <proxima> thanks, i will contact kierank for further description [01:33:55 CET] <Compn> no problem [01:34:15 CET] <proxima> thanks for help [02:34:07 CET] <Timothy_Gu> Compn: it'd be better if you read the description of the task before replying to students. We are fuzzing with a modified version of an example in doc/ so that we actually end up fuzzing libavcodec/format and not ffmpeg.c [02:43:20 CET] <cone-585> ffmpeg 03Ganesh Ajjanagadde 07master:e86444b19d0b: lavc/utvideodec: prevent possible signed overflow [02:44:57 CET] <Timothy_Gu> ethe: the SDL device is supposed to support window resizing: https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/sdl.c#L210 [02:48:36 CET] <Compn> Timothy_Gu : it'd be better if mentors spent some time establishing contacts and communications so students didnt come here and ask me, we are in accord. [03:27:48 CET] <cone-585> ffmpeg 03Kieran Kunhya 07master:4170a44bbc7b: Add GBRAP12 pixel format [03:27:49 CET] <cone-585> ffmpeg 03Michael Niedermayer 07master:10fa50c156ea: avcodec/mpeg12dec: Fix missing slice handling without padding [05:57:44 CET] <proxima> kierank: can you elaborate the qualification task for creating a fuzzing testsuite for FFmpeg [06:00:15 CET] <Timothy_Gu> proxima: the wiki page says "Compile and run fffuzz and report and (possibly fix) a crash using zzuf or afl-fuzz." [06:00:51 CET] <Timothy_Gu> the first step is obviously using git to clone the GitHub repo for fffuzz and build it [06:01:08 CET] <proxima> yeah i have done that, just wanted to know about fuzz part [06:01:23 CET] <proxima> currently i have tested it on a c program and an exe file [06:01:39 CET] <Timothy_Gu> ok so have you installed afl yet? [06:01:40 CET] <proxima> what should be my next step? [06:01:59 CET] <Timothy_Gu> have you installed afl? [06:02:01 CET] <Timothy_Gu> http://lcamtuf.coredump.cx/afl/ [06:02:12 CET] <proxima> no i havent done with afl yet. i did with valgrind [06:02:26 CET] <Timothy_Gu> valgrind is not a fuzzing too [06:02:27 CET] <Timothy_Gu> *tool [06:02:42 CET] <Timothy_Gu> it merely checks for correctness in handling memory [06:02:47 CET] <Timothy_Gu> afl is a "fuzzer" [06:03:26 CET] <proxima> i followed this tutorial https://fuzzing-project.org/tutorial1.html.I did it with zzuf. i will attempt it with afl now [06:03:36 CET] <Timothy_Gu> zzuf works too [06:04:08 CET] <Timothy_Gu> proxima: I'm not sure if afl works on windows though [06:04:19 CET] <proxima> i am working on ubuntu [06:04:50 CET] <Timothy_Gu> uhm didn't you said you got an exe? [06:04:59 CET] <Timothy_Gu> well never mind [06:07:17 CET] <proxima> Okay, and how do we have to submit or report the progress about the task for Outreachy [06:07:31 CET] <Timothy_Gu> that you gotta ask kierank [06:08:28 CET] <proxima> thanks [06:27:39 CET] <rcombs> nevcairiel: michaelni: doesn't 93d336fb076a8abe33e37251af5475673e716f6d break segment manifests? [06:28:24 CET] <rcombs> i.e. list files [08:47:19 CET] <nevcairiel> rcombs: why would it break, it just changes how the filename is allocated [08:49:04 CET] <rcombs> nevcairiel: `seg->cur_entry` points to the end of a linked list [08:49:52 CET] <rcombs> say `size` never changes (a common case): `av_reallocp(&seg->cur_entry.filename, size)` will leave `seg->cur_entry.filename` the same, so we just keep writing into the same buffer forever instead of making a new one for each segment [08:50:57 CET] <nevcairiel> every new segment gets this buffer cloned when its created [08:51:05 CET] <nevcairiel> its not shared between segments [08:51:21 CET] <nevcairiel> using realloc just avoids leaking the memory [08:53:16 CET] <rcombs> ohhhh, I see my mistake [08:55:25 CET] <rcombs> this was with https://ffmpeg.org/pipermail/ffmpeg-devel/2016-February/189992.html [08:57:45 CET] <rcombs> sorry, my bad [09:44:49 CET] <ubitux> is it OK to preload beyond allocated size? [11:07:55 CET] <ubitux> what can i use to load/dup a byte/word/dword/... into a mm reg? [11:08:10 CET] <ubitux> that is, something not constant [11:16:19 CET] <jkqxz> mov* + pshufw for things larger than bytes. Not sure for a single byte. [11:20:44 CET] <jkqxz> Probably just dup the byte into a word? Given pshufb a zero register gives you the right shuffle, but probably you don't want to use SSSE3. [11:22:26 CET] <ubitux> i'm limited to mmx [11:23:14 CET] <rcombs> what are you doing on MMX :3 [11:23:37 CET] <ubitux> because i'm porting ancient code [11:23:44 CET] <ubitux> and it's a nightmare [11:23:46 CET] <ubitux> :( [11:24:54 CET] <rcombs> what code [11:25:02 CET] <wm4> swscale? [11:25:13 CET] <rcombs> ubitux: btw any chance you're planning on replacing zvbi in the near future [11:25:52 CET] <ubitux> yes, swscale, yuv to rgb [11:26:06 CET] <rcombs> wm4: double btw, mpv barfs on zvbi subs because the codec descriptor says it's a text format, but the decoder gives you bitmaps by default (for some reason?????) [11:26:07 CET] <ubitux> rcombs: not really [11:26:23 CET] <wm4> rcombs: it can give both, AFAIK [11:26:28 CET] <ubitux> rcombs: -txt_format option configures for one way or another [11:26:37 CET] <rcombs> and there's an AVOption to give text instead, but I can't figure out how to specify that in mpv [11:26:42 CET] <ubitux> the text version is most of the time broken [11:26:45 CET] <rcombs> since there's no --sd-lavc-o option [11:26:53 CET] <wm4> rcombs: yeah, you can't [11:26:55 CET] <rcombs> ubitux: lovely [11:27:16 CET] <ubitux> rcombs: http://ubitux.fr/pub/pics/_zvbi-shit-happens.jpg [11:27:16 CET] <wm4> bitmap decoders have to be added explicitly to sd_lavc.c [11:27:19 CET] <ubitux> stuff like this [11:27:38 CET] <rcombs> wm4: so I hacked it in lavc to output text by default and now the stream appears to work (`ffmpeg -i file.ts -f ass -` gives normal-looking output), but mpv doesn't display anything [11:28:05 CET] <rcombs> ubitux: &lovely [11:28:23 CET] <rcombs> what's that look like rendered as bitmaps? [11:28:24 CET] <wm4> (I'd welcome an API that'd allow handling text vs. bitmap output more sanely) [11:31:08 CET] <ubitux> rcombs: no idea, it was a while ago [12:00:52 CET] <saij123> Hello. I am jahnavi doing my final year of engineering in IIIT hyderabad. I am very much interested in contributing to FFmpeg via outreachy . Could someone guide me how to start the work? [15:08:30 CET] <Daemon404> i think the first two mails of my 2/2 got caught in spam? [15:08:40 CET] <Daemon404> they do not show up on pipermail. [15:19:58 CET] <ubitux> mmh so there is no concept of tb in the codec param thing [15:20:11 CET] <Daemon404> timebase? [15:20:52 CET] <ubitux> yeah [15:21:07 CET] <ubitux> codec timebase, which seems to be used but disappeared [15:21:12 CET] <Daemon404> wtf is codec timebase [15:21:16 CET] <Daemon404> and why does it exist [15:21:44 CET] <Daemon404> (inb4 h264 sei) [15:22:17 CET] <ubitux> dunno but it's been in use [15:22:35 CET] <Daemon404> that is not a valid answer [15:22:55 CET] <ubitux> i feel like this merge is going to be problematic if we don't worry about it asap [15:23:06 CET] <Daemon404> i was planning to merge up to the Big COmmit [15:23:11 CET] <Daemon404> then Team Effort Time [15:23:33 CET] <ubitux> i will probably push my subtitles patchset pretty soon btw [15:23:49 CET] <Daemon404> doesnt affect me ;p [15:23:57 CET] <ubitux> well actually it does [15:24:08 CET] <ubitux> because subtitles decoders are using the avctx time base [15:24:21 CET] <ubitux> (they won't after the patch) [15:24:34 CET] <Daemon404> yes but where does it (avctx timebase) come from [15:24:41 CET] <Daemon404> and it sounds dumb as hell to have a tb in avctx [15:24:44 CET] <ubitux> i don't know [15:24:48 CET] <Daemon404> you use it but you dont know? [15:24:50 CET] <Daemon404> A+ [15:25:04 CET] <ubitux> ffmpeg works in mysterious ways [15:25:06 CET] <ubitux> ;) [15:25:34 CET] <ubitux> idr, this time rescaling madness has been here for a long time and most of the patchset is about dropping it [15:25:43 CET] <Daemon404> is this some sort of crappy way of exporting subtitle timestamps with when they have no real demuxer [15:25:45 CET] <ubitux> bc timestamping doesn't belong in lavc but in lavf so., [15:26:09 CET] <ubitux> decoders were duplicating lavf work [15:26:32 CET] <ubitux> by rescaling timestamps to ASS tb and inserting them as text into the decoded payload [15:26:49 CET] <Daemon404> is there a problem with just exporting all timestamps with AV_TIME_BASE [15:26:51 CET] <wm4> <Daemon404> yes but where does it (avctx timebase) come from <- I just set an arbitrary timebase on subtitle converters [15:29:05 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:c51b2c79a7ba: Allow linking to CUDA dynamically instead of dlopen()ing it at runtime [15:29:05 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:1f32d01de217: Merge commit 'c51b2c79a7ba084253e892c56dd49ee97115c7de' [15:30:17 CET] <BtbN> another commit that raises the question "but why?". [15:30:32 CET] <Daemon404> BtbN, ? [15:30:40 CET] <BtbN> "Allow linking to CUDA dynamically instead of dlopen()ing it at runtime" [15:30:42 CET] <BtbN> why? [15:30:43 CET] <ubitux> we're going to have a bad time with ffserver btw [15:30:52 CET] <wm4> ubitux: should have dropped it sooner [15:30:53 CET] <Daemon404> ubitux, ffserver can fuck off and die [15:31:05 CET] <ubitux> okay [15:31:06 CET] <Daemon404> it cant even bloody run with public api [15:31:09 CET] <Daemon404> as it stands. [15:32:01 CET] <BtbN> "This commit is a no-op. We already have such functionality." I don't think that's true, I'm not aware ffmpeg is able to link against cuda. [15:32:18 CET] <Daemon404> oh, i misread [15:32:27 CET] <nevcairiel> BtbN: its one of those pointless things that elinril likes, for some reason dlopen is offensive to him or something [15:32:30 CET] <Daemon404> but we still dont wnat to merge anyway [15:32:34 CET] <Daemon404> nevcairiel, MUH FREEDUMS [15:32:51 CET] <BtbN> I put in quite some effort to avoid linking against cuda, and even depending on the CUDA SDK. [15:33:10 CET] <Daemon404> BtbN, it's fine; i didn't merge it [15:33:30 CET] <BtbN> Yeah, I'm not complaining about the no-op merge, was just a comment regarding the original libav commit. [15:35:13 CET] <Daemon404> BtbN, great; youre here [15:35:19 CET] <Daemon404> youre opinion on [15:35:20 CET] <nevcairiel> i would love to get dlopen support for more things, say like vaapi, so i can build without a hard dep [15:35:26 CET] <Daemon404> merge / no-merge / re0impl [15:35:34 CET] <Daemon404> https://git.libav.org/?p=libav.git;a=commit;h=7bc780cd4413f688d3b834037b0f9… [15:35:36 CET] <BtbN> Of the CUDA-Stuff? [15:35:37 CET] <Daemon404> https://git.libav.org/?p=libav.git;a=commit;h=ad884d100259e55cb51a4239cd8a4… [15:35:47 CET] <Daemon404> [..] [15:35:47 CET] <Daemon404> https://git.libav.org/?p=libav.git;a=commit;h=871d0930d4c8666df5514093beff8… [15:35:53 CET] <Daemon404> two are cuda, oen is nvenc/cuda [15:36:45 CET] <BtbN> I'm personaly not a fan of CUDA in ffmpeg, but if the general opinion on it is accepting, I'm fine with it. If it's possible to merge it at all. [15:36:58 CET] <Daemon404> the first two should not be an issue [15:37:02 CET] <Daemon404> the latter may be messy [15:37:17 CET] <BtbN> The one touching nvenc is probably not possible to merge, but if the other two are possible, I'll add the neccesary changed to NVENC. [15:37:27 CET] <Daemon404> ok [15:37:33 CET] <Daemon404> ill skip th nvenc one [15:37:53 CET] <BtbN> They probably need the CUDA-Linking, which you already no-op'd though? [15:38:39 CET] <Daemon404> BtbN, ah... that's why [15:38:56 CET] <Daemon404> blarg [15:39:19 CET] <Daemon404> lavu hard dep on cuda <3 [15:39:33 CET] <BtbN> well, the pixel format should not create any dependencies [15:40:09 CET] <Daemon404> oh indeed [15:40:32 CET] <BtbN> https://git.libav.org/?p=libav.git;a=commit;h=ad884d100259e55cb51a4239cd8a4… does though [15:41:05 CET] <Daemon404> i guess ill-have to re-merge cuda linking... really would rather not, but eh... [15:41:24 CET] <BtbN> I realy dislike linking against CUDA, but it's non-free anyway, so... [15:41:42 CET] <nevcairiel> as long as it remains optional [15:42:36 CET] <Daemon404> BtbN, is there something which precludes dlopening CUDA with lavu / nvenc change? [15:42:45 CET] <Daemon404> i haven't looked super-hard at it (i hate hwaccel) [15:43:11 CET] <nevcairiel> its kinda silly to link to it at one place and then dlopen in another, but it shouldnt break [15:43:26 CET] <Daemon404> no i mean pure-dlopen [15:43:32 CET] <BtbN> In libav, they ifdefed in nvenc.c so it also uses the linked one if cuda is in linking-mode. [15:44:03 CET] <Daemon404> as in, why is it necessary to link to support it [15:44:22 CET] <BtbN> Because there is no official dyn-load version of it. I made that myself. [15:44:42 CET] <Daemon404> ah. [15:45:15 CET] <BtbN> So for every new function and struct it uses, it means writing the loading code and adding the struct somewhere [15:45:31 CET] <Daemon404> so it's possible, just incredibly tedious [15:45:50 CET] <BtbN> For the code that's added so far, that wouldn't be too hard. But I guess they have plans for more. [15:46:24 CET] <Daemon404> beats me [15:46:47 CET] <Daemon404> i ask because i dont want to write new hwaccel code, which i cant test, or build [15:46:54 CET] Action: Daemon404 is just a merger [15:48:19 CET] <BtbN> The CUDA functions needed for NVENC to work are extremely minimal. You only need to create a contex, nothing more. [15:48:55 CET] <BtbN> But if libav plans to actualy to video-processing with CUDA, they will need a whole lot of it. Dyn-Loading all that would be horribly annoying and would mean duplicating larger parts of the CUDA SDK into ffmpeg. [15:49:14 CET] <Daemon404> [libav-devel] [RFC] lavfi: add an NVIDIA NPP-based scaling filter [15:49:15 CET] <Daemon404> like this? [15:49:19 CET] <BtbN> yep [15:49:40 CET] <Daemon404> i see [15:49:45 CET] <Daemon404> so what's your opinion then [15:49:57 CET] <Daemon404> i'll defer to you to decide the Best Course [15:49:58 CET] Action: Daemon404 runs [15:50:32 CET] <BtbN> linking CUDA is fine for that purpose, as long as plain NVENC is kept in a way where it works without all that. [15:50:44 CET] <BtbN> Which it currently is, so I'm fine with it. [15:51:34 CET] <cone-242> ffmpeg 03Justin Ruggles 07master:e1c15a9475f0: img2dec: Support Progressive JPEG in jpeg_probe [15:51:44 CET] <BtbN> Feel free to merge what's possible, I'll take care of the CUDA-Frame-Input stuff for nvenc.c [15:52:04 CET] <Daemon404> BtbN, wouldnt the lavu change + cuda/nvenc necessitate linking? [15:52:09 CET] <BtbN> yes [15:52:09 CET] <Daemon404> if i merged as-is [15:52:12 CET] <Daemon404> or will you take care of that [15:52:18 CET] <nevcairiel> its an optional feature [15:52:23 CET] <nevcairiel> just dont enable it if you dont want linking [15:52:34 CET] <BtbN> It's an optional feature for nvenc.c, but the other CUDA stuff needs linking. [15:52:39 CET] <Daemon404> gotcha [15:52:47 CET] <nevcairiel> you can still build lavu without these features, of course [15:53:08 CET] <Daemon404> unrelated: holy crap mats v26 [15:53:12 CET] <BtbN> yeah, if you merge the lavu changes right now, ENABLE_CUDA will never be set, so it won't ever be built. [15:53:59 CET] <Daemon404> BtbN, so you *dont* want me to go back and merge teh configure changes right now? [15:54:15 CET] <Daemon404> otherwise it's possible it will be set by user interaction [15:54:29 CET] <nevcairiel> well you could merge the mandatory parts for future cuda support, without the nvenc changes [15:54:42 CET] <BtbN> I'll make sure it builds and works, and then send a the CUDA-Configure-Patch again [15:54:48 CET] <nevcairiel> or that [15:54:50 CET] <Daemon404> BtbN, awesome [15:55:25 CET] <BtbN> So merge the lavu changes, even though they are currently impossible to activate. [15:55:38 CET] <nevcairiel> be careful though [15:55:44 CET] <nevcairiel> without configure support it will error [15:55:52 CET] <nevcairiel> because the defines are not set [15:56:00 CET] <BtbN> I couldn't find it checking the defines anywhere, except in the Makefile [15:56:07 CET] <nevcairiel> any feature define we have is a lways set, to either 0 or 1 [15:56:13 CET] <nevcairiel> but without configure, it would remain undefined entirely [15:56:44 CET] <nevcairiel> so there should be configure support before its merged to avoid nastyness [15:56:54 CET] <BtbN> ah, no. hwcontext.c has a check [15:57:10 CET] <BtbN> Would adding cuda to the external lib list be enough to make the define appear? [15:57:25 CET] <Daemon404> no i dont think so [15:57:40 CET] <nevcairiel> the configure check itself is pretty simple and should work vanilla from libav, shouldnt it [15:57:48 CET] <Daemon404> it should [15:57:52 CET] <BtbN> nevcairiel, yeah, but it's already no-op merged. [15:58:06 CET] <Daemon404> that doesnt stop one from re-applying it [15:58:24 CET] <nevcairiel> just skip the nvenc hunk in configure, and grab the other 3 [15:58:26 CET] <nevcairiel> should be fine [15:58:43 CET] <BtbN> Sure. I guess it needs to be applied first then. If some user decides to go for it, and it explodes, well... [15:59:17 CET] <Daemon404> lavu will build, but itll just accomplish nothing [15:59:19 CET] <Daemon404> afaict [15:59:27 CET] <Daemon404> i dont think anything will explode [15:59:36 CET] <nevcairiel> evne in libav master it doesnt accomplish anything yet [15:59:38 CET] <nevcairiel> so thats ok =P [15:59:43 CET] <Daemon404> lol [16:00:28 CET] <nevcairiel> in other news, libav forgot to fix the concat exploit in their latest stable point release [16:05:32 CET] <Daemon404> nevcairiel, http://sprunge.us/YQMd [16:05:36 CET] <Daemon404> that seem right? [16:05:56 CET] <nevcairiel> seems fine [16:11:37 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:7bc780cd4413: pixfmt: add a CUDA hwaccelled format [16:11:38 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:9f2c1c77d209: configure: Allow linking to CUDA dynamically instead of dlopen()ing it at runtime [16:11:39 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:63c3e3533283: Merge commit '7bc780cd4413f688d3b834037b0f9ddfd6948140' [16:16:03 CET] <Daemon404> BtbN, btw i remember why this is happening now, i think [16:16:19 CET] <Daemon404> some guy from nvidia talked to me (for some reason) + anton at the last VDD [16:16:23 CET] <Daemon404> about hardware filtering [16:23:51 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:ad884d100259: hwcontext: add a CUDA implementation [16:23:52 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:6992276acaae: Merge commit 'ad884d100259e55cb51a4239cd8a4fd5154c2073' [16:27:38 CET] <wm4> what did he say? something about doing unpaid work to further their sales? [16:27:59 CET] <Daemon404> i think he mentioned them doing work or something [16:28:03 CET] <Daemon404> my memory is vague [16:28:19 CET] <nevcairiel> maybe anton even is paid, who knows [16:41:25 CET] <Daemon404> people are uploading VTT files that start at 1 hr and expecting us to handle it "correctly" (they want us to subtract 1 hr and then display at that time) [16:41:30 CET] <Daemon404> goddamn broadcast people [16:41:34 CET] <Daemon404> thats not a valid VTT. [16:42:04 CET] Action: Daemon404 wonders why this persists [16:43:04 CET] <durandal_1707> implement ssetpts filter [16:43:43 CET] <Daemon404> lol [16:43:49 CET] <Daemon404> no, im not goign to fix it [16:43:54 CET] <Daemon404> also we dont use libav* for subtitles. [16:44:08 CET] Action: Daemon404 was just lamenting "professional" subtitlign software [16:45:05 CET] <wm4> Daemon404: how would that even be fixable in theory [16:45:29 CET] <wm4> the first subtitle event can come at an arbitrary time, and you can't just display it at the start [16:45:41 CET] <Daemon404> it's not legitimately fixable [16:45:52 CET] <Daemon404> only with heuristics [16:53:52 CET] <ubitux> you can adjust the ts from sub events with libav* [16:54:04 CET] <ubitux> remuxing with itsoffset and stuff like that works [16:54:18 CET] <wm4> it's about finding the offset, not applying it [16:54:35 CET] <J_Darnley> Gah! These strides are not in bytes! [16:55:04 CET] <Daemon404> J_Darnley, google product? [16:55:09 CET] <Daemon404> google stuff tends to have strides in pixels [16:55:14 CET] <J_Darnley> no, ffmpeg product [16:55:18 CET] <Daemon404> aw :( [16:57:08 CET] <cone-242> ffmpeg 03Michael Niedermayer 07release/2.8:536f6c4ec2f8: avutil/frame: Free destination qp_table_buf in frame_copy_props() [16:57:09 CET] <cone-242> ffmpeg 03KO Myung-Hun 07release/2.8:8dd71d0bd40f: MAINTAINERS: add myself as an OS/2 maintainer [16:57:10 CET] <cone-242> ffmpeg 03Michael Niedermayer 07release/2.8:530192b0e06c: swscale/x86/output: Move code into yuv2planeX_mainloop [16:57:11 CET] <cone-242> ffmpeg 03Michael Niedermayer 07release/2.8:21a6b7930e5d: swscale/x86/output: Fix yuv2planeX_16* with unaligned destination [16:57:12 CET] <cone-242> ffmpeg 03Michael Niedermayer 07release/2.8:b3a64fc0397a: avcodec/h264: Execute error concealment before marking the frame as done. [16:57:13 CET] <cone-242> ffmpeg 03Michael Niedermayer 07release/2.8:23ef5996a589: avutil/pixdesc: Make get_color_type() aware of CIE XYZ formats [16:57:14 CET] <cone-242> ffmpeg 03Carl Eugen Hoyos 07release/2.8:1e9aa7907ed4: postproc: fix unaligned access [16:57:15 CET] <cone-242> ffmpeg 03Michael Niedermayer 07release/2.8:a3d698dcb143: swscale/input: Fix GBRAP16 input [16:57:16 CET] <cone-242> ffmpeg 03Michael Niedermayer 07release/2.8:4ccb97650a94: swscale/utils: Fix chrSrcHSubSample for GBRAP16 [16:57:17 CET] <cone-242> ffmpeg 03Michael Niedermayer 07release/2.8:800334947d95: avcodec/avpacket: clear priv in av_init_packet() [17:04:11 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:b3dd30db0b2d: lavfi: pass the hw frames context through the filter chain [17:04:12 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:10424024a16a: Merge commit 'b3dd30db0b2d857147fc0e1461a00bd6172a26a3' [17:29:44 CET] <BtbN> Daemon404, yes, nvidia sent a patch like that to ffmpeg-devel a while ago, but it was horrible and changed every library in some horrible way to make full CUDA transcoding possible. [17:29:57 CET] <BtbN> It was rejected, and they never followed up with something. [17:30:15 CET] <BtbN> Instead they published a guide on how to use nvenc with ffmpeg, where they included said hack-patch as a compilation-step. [17:30:16 CET] <Daemon404> i guess that was the follow up [17:30:25 CET] <Daemon404> fb did that too [17:30:38 CET] <Daemon404> its popular with big companies with Very Clever engineers who you couldnt possibly be more clever than [17:31:01 CET] <BtbN> Well, I don't have a problem with the general Idea of that patch, it was just horrible code. [17:31:02 CET] <durandal_1707> ah [17:31:11 CET] <BtbN> If it comes in as propper code that way, well... [17:31:22 CET] <Daemon404> BtbN, the was my point about clever :P [17:31:38 CET] <Daemon404> you dont want their code, but theyre more clever, so they just take their code and leave! [17:32:09 CET] <BtbN> And then something like libva happens. [17:35:08 CET] <BtbN> I wonder if this -lcuda just works on Windows. [17:39:49 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:1bf34134612e: avconv: use the new buffersrc parameters API [17:39:50 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:14f942b35982: Merge commit '1bf34134612e509fa68c70dfff418c6022459259' [17:40:02 CET] <Daemon404> BtbN, depends what it is named on windows [17:40:06 CET] <Daemon404> and with which compiler [17:46:48 CET] <Daemon404> is there anything special to do when merging a new filter in lavfi from libav? [17:47:00 CET] <Daemon404> i cant find ANY examples from the last 1-2 years in git history [17:55:43 CET] <BBB> jamrial: I understand what youre saying (re: md5) [17:55:57 CET] <BBB> jamrial: but I dont understand why its an issue. we only do it on platforms where unaligned loads are specifically supported [17:56:42 CET] <BBB> jamrial: Id go as far as to say that ubsan is buggy, but I think the point of ubsan is like tsan, its to be buggy, nosiy and tell you stuff that is sometimes intentionally done so as a speed optimization, i.e. its a great tool for ignorant high level java coders, but not useful for development of highly performant libraries [18:00:04 CET] <jamrial> well, if we're going to do what ubitux mentioned about making ubsan fail for every runtime error, something like that will be needed [18:00:29 CET] <jamrial> BBB: there's also big endian. i'm still interested to know if this change benefits those systems or not [18:01:36 CET] <BBB> so does ubsan not complain about av_rl32 doing unaligned loads? [18:01:42 CET] <jamrial> no [18:01:49 CET] <BBB> very interesting [18:01:57 CET] <BBB> I wonder why [18:02:17 CET] <BBB> the change probably benefits be b/c you dont memcpy anymore [18:02:27 CET] <BBB> although youre doing it scalar instead of vector... [18:02:31 CET] <BBB> I guess who cares [18:02:48 CET] <BBB> I think patch is fine, I still dont udnerstand ubsan being ok with av_rl32 but not the direct access [18:03:34 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:21f7cd4acd8d: lavfi: add a filter for uploading normal frames to CUDA [18:03:35 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:ef9915a0e243: Merge commit '21f7cd4acd8dc4b4796b55966dd015cb037164d8' [18:06:50 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:7b3214d00506: lavc: add a field for passing AVHWFramesContext to encoders [18:06:51 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:871d0930d4c8: nvenc: support CUDA frames as input [18:06:52 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:7e49cdd12973: Merge commit '7b3214d0050613bd347a2e41c9f78ffb766da25e' [18:06:53 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:e05704bd46b9: Merge commit '871d0930d4c8666df5514093beff874acbe5cce0' [18:07:56 CET] <BBB> are we still blacklisted by vlc? or is that fixed now that mt/hwaccel issue is fixed? [18:08:11 CET] <BtbN> it's now unsupported! so they left in the block,. [18:08:32 CET] <BBB> huh what? [18:08:39 CET] <BtbN> exactly [18:08:54 CET] <BBB> j-b: Im gonna cry, what else do you want? [18:10:35 CET] <iive> have mt/hwaccel been fixed for real? [18:11:03 CET] <iive> i thought we just reverted to the previous state [18:11:28 CET] <BBB> theres a bug left in dxva2, I believe [18:11:34 CET] <BBB> but in general it works again, yes [18:12:07 CET] <BBB> so you can call that previous state if you want [18:14:37 CET] <jamrial> BBB: since instead of failing we now warn, they consider the functionality as unsupported, meaning a future commit could break it, even if it works right now [18:15:09 CET] <jamrial> so they are going to change how they inits hwaccel, and scheduled it for vlc 3 [18:15:36 CET] <jamrial> for vlc 2.2.x i think they don't plan to change the current blacklist [18:16:00 CET] <BBB> great... [18:16:06 CET] <jamrial> although michaelni was trying to see if a change in the warning could convince them otherwise [18:16:12 CET] <BBB> do we warn? [18:16:15 CET] <BBB> I dont think we warn anymore [18:16:22 CET] <BBB> I fixed the bug, so why are we warning? [18:16:35 CET] <BBB> the only hwaccel with issues is dxva2 [18:16:48 CET] <jamrial> BBB: https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=5edd1f62ca15ad3470578… [18:17:09 CET] <BBB> we should remove that warning [18:17:15 CET] <Daemon404> this alls sounds petty [18:17:23 CET] <BBB> its supported and known to work with everything except dxva2, right? [18:17:38 CET] <BBB> Ill go grab lunch :/ [18:17:50 CET] <jamrial> well, j-b's priority seems to be windows, so... :P [18:18:03 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:c15f6098b1b2: avconv: pass the hw context from filters to the encoder [18:18:04 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:259fef86bb91: Merge commit 'c15f6098b1b25689dd5e86aeb5ce69bc12efe1e1' [18:20:37 CET] <iive> what's the bug exactly? [18:20:43 CET] <iive> the one that's been fixed? [18:22:18 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:47570dbde8b3: fft: ppc: Place ff_fft_calc_interleave_altivec() under correct ifdefs [18:22:19 CET] <cone-242> ffmpeg 03Luca Barbato 07master:2edc718723b6: configure: Relax the implication of --enable for components [18:22:20 CET] <cone-242> ffmpeg 03Vittorio Giovara 07master:b92962436bdc: mov: Fix the format specifier type for size [18:22:21 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:2cfb34a4e8b4: Merge commit '47570dbde8b33001d5ccac44e7ebaaeecbcb807c' [18:22:22 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:33215d3c4898: Merge commit '2edc718723b60530aead26c20cbc891102f7d529' [18:22:23 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:f6d633d72686: Merge commit 'b92962436bdcfae478c8598dca397a397762eef8' [18:24:20 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:9c0bc1e980a9: qsv: add a missing #include [18:24:21 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:d847a40888c0: hwcontext_cuda/vdpau: add to skipheaders [18:24:22 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:0d4c0240affc: Merge commit '9c0bc1e980a99106d6749ec632f166b87275871e' [18:24:23 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:cb0355537d6a: Merge commit 'd847a40888c064cc8c35b546fc5a0ccb69136a7c' [18:31:44 CET] <nevcairiel> BBB: they are just being silly, we dont even use the word unsupported anywhere, so it sounds to me like someone is just trying to stir up problems, i'm done catering to those people [18:32:40 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:29c2d06d6772: cosmetics: Drop empty comment lines [18:32:41 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:1a12eb4a7314: Merge commit '29c2d06d67724e994980045afa055c6c34611b30' [18:36:56 CET] <durandal_1707> its politic, evil people everywhere [18:37:32 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:6b96d2dcdaa6: cosmetics: Drop particularly redundant silly comments [18:37:33 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:3d8025d60204: profiles: Add missing #endif comment [18:37:33 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:7c82d31cbe9f: checkasm: Use standard multiple inclusion guards [18:37:35 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:5eb4073781ee: Merge commit '6b96d2dcdaa60d7919d710432c6ca204b7fab0ab' [18:37:35 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:aaa3d6227279: Merge commit '3d8025d602045cbd2894e5182d9243c2e864c8c8' [18:37:37 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:ca408cf557b8: Merge commit '7c82d31cbe9fc5d5a321ad49c14a472bd629b50f' [18:39:22 CET] <cone-242> ffmpeg 03Vittorio Giovara 07master:71eaefa64a54: build: Add missing celp_math dependency for G723_1 encoder and decoder [18:39:23 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:e45312932177: build: Add missing dependencies for eatqi decoder [18:39:24 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:7e12a3d57ca0: Merge commit '71eaefa64a54bece571299ca600d06f48ac7c6c3' [18:39:25 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:3c5a040ad94d: Merge commit 'e453129321778886813dcecf73c8b42f8352ca0e' [18:39:36 CET] <nevcairiel> only a couple patches left until the evilness [18:40:00 CET] <Daemon404> like 20 diego patches [18:47:00 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:7403be9b1bce: build: Fix dependencies for components relying on H.263 data tables [18:47:01 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:2870972e9de6: build: Fix mpegvideo component dependencies [18:47:02 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:de3b134be3f5: build: Adjust mpeg4video parser dependencies [18:47:03 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:82454c3a826b: build: Let the WTV demuxer select the MPEG-TS demuxer [18:47:04 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:34e4c588c8e8: Merge commit '82454c3a826bc8aa42474097784b70befd5be532' [18:54:01 CET] <jamrial> regarding the codecpar stuff, does every demuxer need to be updated at the same time to avoid compilation failures? because we have a bunch libav doesn't [18:54:24 CET] <nevcairiel> yes [18:54:52 CET] <nevcairiel> well not compilation problems as such, but it wouldnt work [18:55:08 CET] <nevcairiel> but we'll just do what we did last time, merge it into a github branch and slowly work on fixing it [18:55:50 CET] <jamrial> right [18:56:25 CET] <Daemon404> this one will probably be less painful [18:56:29 CET] <Daemon404> than TEP1 [18:58:28 CET] <nevcairiel> i'm not that sure [18:59:30 CET] <ubitux> Daemon404: can you explain why it's a noop sometimes? [18:59:38 CET] <ubitux> i'm thinking of "avconv: use the new buffersrc parameters API" [19:02:14 CET] <nevcairiel> avconv and avplay have largely diverged, so its hard to merge those [19:02:35 CET] <Daemon404> ubitux, it cant be done easily afaik [19:02:44 CET] <Daemon404> we have a bunch of stuff set thats not in the param struct [19:02:54 CET] <Daemon404> i tried, but it wasnt working out [19:03:25 CET] <J_Darnley> atomnuker: I've got a couple of questions about the vc2 encoder [19:03:29 CET] <Daemon404> the code thats already there doesnt use any deprecated api calls afaik either [19:03:49 CET] <J_Darnley> I'll start with: does it accept arbirary frame dimensions? [19:03:58 CET] <J_Darnley> *arbitrary [19:06:06 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:ab9068cc9cc7: build: Fix typo in HEVC VDPAU hwaccel dependencies [19:06:07 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:624e235502c5: build: Introduce iso_media component [19:06:08 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:0d1229f1d2b8: voc: Split ff_voc_get_packet into a separate file [19:06:09 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:b4a0f172c7f1: Revert all recent configure changes related to dependency resolution [19:06:10 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:745d0c030085: Merge commit '624e235502c5aa2d17e22dd6c0ccdf080a177310' [19:06:11 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:f99195d56f4a: Merge commit '0d1229f1d2b8f26dd50c6be7917bb8ed8cb95364' [19:06:12 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:9fad1ce7c95a: Merge commit 'b4a0f172c7f116d8d329ff02f29c138a9291fd3c' [19:09:40 CET] <cone-242> ffmpeg 03Luca Barbato 07master:3ef98937f512: mov: Force the full parsing of mp3 [19:09:41 CET] <cone-242> ffmpeg 03Luca Barbato 07master:f273f7fb25b6: mkv: Force the full parsing of mp3 [19:09:42 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:79127dbbeffa: Merge commit '3ef98937f512184f80d3bd30015f5ec83dc11eb0' [19:09:43 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:dc61014319ba: Merge commit 'f273f7fb25b68792be481c9241b0ec2876e41f35' [19:09:53 CET] <Daemon404> almost at the evil [19:10:03 CET] <JEEB> the evil within [19:10:16 CET] <Daemon404> good game [19:10:50 CET] <JEEB> hmm, I don't remember how good its PC port is but I guess I should try it out [19:12:50 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:7d16d8533daf: build: More precise dependencies for h264dsp [19:12:51 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:b10c33c5ea9a: build: Add missing mpegvideo dependency for the MSS2 and VC-1 decoders [19:12:52 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:0ffaae60e849: Merge commit '7d16d8533daf73b66d318c5e27de3b17208aa0ba' [19:12:53 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:d61849f0b7f0: Merge commit 'b10c33c5ea9a41c41726fb5488ea1633e3f898ac' [19:15:39 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:79866803ffc4: msmpeg4data: K&R formatting cosmetics [19:15:40 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:f9fbd474676e: msmpeg4data: Move WMV2 data tables to their own file [19:15:41 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:133aa68601d5: Merge commit '79866803ffc4c1a1b02663de9bab216b8cfdb8b4' [19:15:42 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:2814f06abf43: Merge commit 'f9fbd474676e903e12efe83203697d60a9d28cf9' [19:22:26 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:15a24614aef5: build: Add vc1dsp component for more fine-grained dependencies [19:22:27 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:b056482ef361: Merge commit '15a24614aef5836af3cd2c7cc3b2b737eee6bf3c' [19:22:35 CET] <BBB> nevcairiel: I suppose, but I can at least try [19:25:47 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:d24bd96bdd5b: build: Disentangle VC-1 decoder and parser [19:25:48 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:8d918a98aa24: rtpdec: Use the right logging context [19:25:49 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:8caadfc53ddc: fate: Be silent when switching to Git branch [19:25:50 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:ef7ce480c848: Merge commit 'd24bd96bdd5b4bae9a9e0055fa8d1104db1283a9' [19:25:51 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:79b1a24b7ddd: Merge commit '8d918a98aa24134a043d578ef45bae363dbed9db' [19:25:52 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:8ae21fd95985: Merge commit '8caadfc53ddc55a269722ada65294f0ea8b609ac' [19:27:45 CET] <cone-242> ffmpeg 03Luca Barbato 07master:bf7be043fcfd: matroska: Always consider S_TEXT/UTF8 as SRT when demuxing [19:27:46 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:2ef37691a059: Merge commit 'bf7be043fcfda29c81ef2268885b4ccc643e7c49' [19:28:02 CET] <Daemon404> nevcairiel, we're now at the start of the TEP2 commit cluster [19:28:12 CET] <Daemon404> i think some can be merged though [19:28:35 CET] <Daemon404> or rather, there are some prep commits first before TEP [19:28:42 CET] <Daemon404> and some unrelated ones [19:29:05 CET] <Daemon404> ack, i was mistaken.. there's still a bunch of crap before TEP [19:29:08 CET] <Daemon404> nevermind, carry on [19:29:11 CET] <Daemon404> i will do it later [19:29:12 CET] <Daemon404> dinner time [19:38:15 CET] <cone-242> ffmpeg 03Paul B Mahol 07master:b6a0aa1c0a6c: avfilter/vf_blend: add freeze and heat modes [19:49:25 CET] <BBB> poor daemon404 [19:51:58 CET] <cone-242> ffmpeg 03James Almer 07master:fc404460bd92: configure: add missing vc1dsp dependency to vc1_decoder [20:06:32 CET] <philipl> fritsch: kodi's configure is demanding decadec even when shared ffmpeg is used. This seems unnecessary from my reading [20:09:15 CET] <michaelni> Daemon404, some merge today broke packed_maindata.mp3.mp4 [20:12:33 CET] <michaelni> https://dl.dropboxusercontent.com/u/76042064/packed_maindata.mp3.mp4 [20:16:40 CET] <J_Darnley> In x86 assembly, can I do x*17 with fewer instructions than 3 LEAs other than an IMUL? [20:17:06 CET] <kurosu_> imul would be better [20:17:25 CET] <durandal_1707> writing assembly for what? [20:17:33 CET] <J_Darnley> vc2 encoder [20:18:25 CET] <BBB> J_Darnley: how many registers? [20:18:43 CET] <jkqxz> x | x << 4? imul might still be better. [20:18:45 CET] <jamrial> J_Darnley: can't you do y = x; x <<= 4; x += y? [20:18:53 CET] <BBB> J_Darnley: if you have two, simply do ebx=lea[eax*4]; ebx=lea[ebx*4+eax] [20:19:10 CET] <BBB> J_Darnley: thats two instructions, but requires a free register [20:19:58 CET] <J_Darnley> I have a few free but I might like to save some if I want to use 32-bit at some point. [20:21:18 CET] <jamrial> since lea is slow, how about mov ebx, eax; shl eax, 4; add eax, ebx? [20:21:43 CET] <J_Darnley> Wait, it's slow now? [20:22:04 CET] <kurosu_> all of these are sequential - I doubt that they are actually faster than an imul [20:22:06 CET] <jamrial> latency of three cycles afaik [20:22:33 CET] <jamrial> mov, shl, add, all those are one [20:22:47 CET] <kurosu_> yeah but sequential [20:23:00 CET] <ubitux> clang does an imul, gcc does mov,shl,add [20:23:04 CET] <ubitux> pick your favorite [20:23:26 CET] <jamrial> the mov and the shl can run at the same time. only the add needs to wait for the two former instructions to finish [20:23:29 CET] <J_Darnley> How many of you went off to a compiler? Raise your hands. :) [20:23:43 CET] <kurosu_> I'd personally solve the question by just using START/STOP_TIMER anyway [20:24:01 CET] <kurosu_> s/solve/answer [20:25:26 CET] <J_Darnley> Well, thanks for the suggestions, I'll stick with imul for now and optimise later [20:32:49 CET] <kurosu__> re fixed point synth_filter & dts, I really wonder if a sse4 version, particularly on x86_64, will improve much anything [20:34:20 CET] <jamrial> kurosu__: it should. try decoding a dts-ma file and use perf [20:34:57 CET] <jamrial> most cpu time is spent in a parse function and synth filter last time i checked [20:35:07 CET] <kurosu__> what I mean: you're just going to do twice the multiplies and then you'll need some more shuffling [20:35:29 CET] <kurosu__> I'm not contesting it's an hot point [20:35:36 CET] <jamrial> ah [20:35:58 CET] <jamrial> well, it helped with mlp/truehd [20:36:32 CET] <kurosu__> ok, then it's more like the effort is not that much rewarded [20:36:39 CET] <kurosu__> but yeah, parsing is probably more rewarding, I haven't looked at it [20:37:17 CET] <jamrial> with mlp using pmuldq i got the function to be 2.5x faster than the c version [20:39:15 CET] <jamrial> pity there's no pmuhdq instruction [20:39:50 CET] <kurosu__> pmaddddq ? :D [20:40:04 CET] <jamrial> heh, that'd be even better :p [20:40:06 CET] <JEEB> :D [20:40:19 CET] <jamrial> one of the avx512 extensions adds pmullq [20:42:07 CET] <kurosu__> well, I'd look it up, weren't there that much corruption on the network I'm on (which manages to poison google or any dns) [20:54:42 CET] <rcombs> pmadgpgpgpgpuwaitaminute [20:54:43 CET] <michaelni> Daemon404, found the commit breaking the mp3, posted a patch [20:55:25 CET] <rcombs> michaelni: maybe fix the MP3 parser instead? [20:55:52 CET] <rcombs> I've definitely seen MKV files the equivalent change fixes; would not be surprised if the same was true of MP4 [20:56:36 CET] <rcombs> it fixes files where the MP4 (or in MKV, that) packets aren't aligned with MP3 frames [20:56:43 CET] <rcombs> which is pretty stupid but happens in real files [21:04:48 CET] <michaelni> rcombs, mp4 allows packing mp3 so it cannot easily be parsed if thats not the case our mp4 demuxer uses the parser, mkv always uses the parser for mp3 [21:06:02 CET] <michaelni> rcombs, that said, if the parser can be made to handle such packed mp3, dong that of course wont hurt either [21:06:35 CET] <rcombs> seems like the most general solution [21:06:57 CET] <jamrial> kurosu__: with avx2 you also have 256bit wide regs, so four multiplies per pmuldq [21:11:38 CET] <michaelni> rcombs, are you ok wth reverting the merge that broke it ? [21:12:18 CET] <rcombs> as long as we're handling it in the specific case known to be broken, I guess it's fine [21:13:26 CET] <kurosu__> gtg [21:13:29 CET] <michaelni> rcombs, iam not aware of a file that doesnt work, and iam interrested in files that dont work (please CC me on any tickets about such bugs) [21:13:50 CET] <rcombs> I've just got the MKV one laying around (that's since been fixed) [21:14:04 CET] <rcombs> I'll tell you if I run into an MP4 though [21:14:18 CET] <michaelni> ok, please do [21:14:24 CET] <rcombs> I think these things come from some crappy camcorders [21:24:10 CET] <atomnuker> J_Darnley: yes, the VC-2 encoder should be able to accept arbitrary frame sizes [21:24:26 CET] <J_Darnley> drat. [21:24:32 CET] <atomnuker> why? [21:24:37 CET] <J_Darnley> I will need to split some of these loops [21:24:42 CET] <atomnuker> that [21:25:19 CET] <J_Darnley> split for width & ~mmsize and width & (mmsize-1) [21:25:46 CET] <cone-242> ffmpeg 03Michael Niedermayer 07master:5870f2a1dc46: Revert "Merge commit '3ef98937f512184f80d3bd30015f5ec83dc11eb0'" [21:26:20 CET] <atomnuker> J_Darnley: couldn't you fall back to C code in case the dimensions aren't 1080p? [21:26:22 CET] <J_Darnley> Unless I am mistaken about its operation and that the smaller dwt sections are not nested into the same frame/buffer [21:27:03 CET] <atomnuker> The current Haar transform can be applied fully in-place [21:27:35 CET] <J_Darnley> yeah, because they don't do 8 samples at a time [21:27:47 CET] <atomnuker> for a single level transform, since you still need to deentangle the coefficients to prepare them for another level [21:28:20 CET] <J_Darnley> Okay, let me ask a more simple question. [21:29:05 CET] <fritsch> philipl: since ffmpeg-3.0 most likely, yes [21:29:28 CET] <J_Darnley> If it needs to do a width of 9, are the extra 7 samples going to overwrite something important? [21:29:31 CET] <fritsch> philipl: we have some parts of the code that want the dcadec codec for e.g. number of channels estimation [21:30:17 CET] <atomnuker> J_Darnley: a width of 9 for what? slice size, frame size? [21:30:34 CET] <fritsch> philipl: my next todo is bumping kodi's ffmpeg to 3.0 + some hevc-10 bit patches, but I want to cure all the tons of warnings before that. Will start next week. [21:30:36 CET] <J_Darnley> i don't know, whatever width the DSP function gets [21:30:51 CET] <J_Darnley> a "subband" I think [21:31:48 CET] <atomnuker> J_Darnley: ah, you mean the actual transform functions [21:31:56 CET] <J_Darnley> yes [21:32:51 CET] <t4nk748> fritsch: What are the 10bit hevc patches? [21:33:31 CET] <fritsch> dxva hwaccel [21:33:33 CET] <fritsch> by nevcairiel [21:33:43 CET] <fritsch> from ffmpeg 3.1 [21:34:02 CET] <t4nk748> thank you [21:35:53 CET] <atomnuker> J_Darnley: the subband function gets called with the size of a single plane (e.g. 1920x1080 luma and twice for 960x540 for 420 chroma) [21:36:19 CET] <atomnuker> for every single level (wavelet_depth), the function gets called again with the size of the previous image halved [21:36:39 CET] <J_Darnley> A max of 5 levels, right? [21:37:01 CET] <atomnuker> so 1920x1080 for level 1, 960x540 for level 2, 430x270 for level 3, etc. [21:37:05 CET] <atomnuker> yes, maximum of 5 times [21:37:39 CET] <J_Darnley> okay, I'll limit the function's use at first [21:37:49 CET] <J_Darnley> thank you. [21:38:04 CET] <atomnuker> J_Darnley: keep in mind that everything is padded [21:38:25 CET] <atomnuker> FFALIGN(p->width, (1 << s->wavelet_depth)) [21:38:45 CET] <atomnuker> so for a 4 level transform at 1080p you get a vertical resolution for the plane of 1088 [21:39:24 CET] <J_Darnley> okay, I'll look at the padding later [21:39:29 CET] <atomnuker> so in case you overwrite some stuff you have some leeway at the end of your buffer [21:58:40 CET] <philipl> fritsch: no worries. [21:59:05 CET] <fritsch> philipl: what's the status on 10 bit hwaccel on linux / vdpau? [22:01:38 CET] <philipl> fritsch: no update I'm afraid. We'll know things are moving when the 10bit libvdpau changes appear on the vdpau mailing list. [22:02:13 CET] <fritsch> will stay tuned [22:02:24 CET] <fritsch> as vaapi already has pushed 10 bit libva / libva-driver-intel patches [22:02:28 CET] <fritsch> though no hw yet [22:08:38 CET] <atomnuker> btw J_Darnley, which subband function are you currently trying to DWT? [22:09:31 CET] <J_Darnley> the first one, uh 97 [22:09:36 CET] <J_Darnley> vc2_subband_dwt_97 [22:12:12 CET] <atomnuker> nice [22:13:26 CET] <atomnuker> in the future i'd be nice to do DWT per slice so we can just do transform->encode per slice rather than do the first per plane [22:13:35 CET] <atomnuker> though that's only possible with the Haar wavelet [22:15:15 CET] <atomnuker> 9_7 gives you the best quality as long as you don't give it crazy low bitrates [22:16:55 CET] <atomnuker> Haar wins then because having blocking artifacts due to quantization wins over having ugly eliptical artifacts (due to the fact 9_7 isn't doable without overlap per slice) [22:18:19 CET] <atomnuker> but the 9_7 is the default for a good reason (which is that it simply looks better at all other cases) [22:33:54 CET] <cone-242> ffmpeg 03Paul B Mahol 07master:c09248aecd0d: avfilter/af_astats: reset stats prior not after filtering [22:39:02 CET] <rcombs> philipl: fritsch all for HEVC, though, yeah? [22:49:59 CET] <nevcairiel> in the meantime, microsoft pushed vp9 10-bit support, although no hardware and/or drivers support it yet =p [22:53:23 CET] <wm4> isn't vp9 10 bit obscure? [22:54:34 CET] <TD-Linux> right now yes, but the latest broadcast standards and blu-ray specs specify 10 bit so presumably there is some demand [22:54:57 CET] <philipl> rcombs: for now yes. nvidia hardware doesn't do 10bit h264 and I don't know what their vp9 hardware capabilities are [22:55:34 CET] <nevcairiel> specifiying it in the dxva2 context isnt all that hard, the structs all contained the necessary information anyway, so all they had to do is define a restricted profile [22:55:41 CET] <nevcairiel> philipl: no hardware does h264 10-bit [22:55:50 CET] <nevcairiel> consumer hardware anyway [22:55:55 CET] <rcombs> maybe some broadcast stuff might :3 [22:56:07 CET] <JEEB> and the non-consumer stuff most probably only handles intra-only anyways [22:56:14 CET] <rcombs> inb4 GPGPGPGPGPU [23:00:07 CET] <wm4> is vp9 still fixed to bt.601? [23:00:51 CET] <nevcairiel> no, it has flags [23:01:05 CET] <nevcairiel> including bt2020 and rgb even [23:02:27 CET] <wm4> I swear at least vp8 was once fixed to bt.601 [23:02:58 CET] <wm4> is bt2020 patent unencumbered? [23:03:16 CET] <nevcairiel> vp8 is i think [23:03:35 CET] <nevcairiel> also, TIL there is a difference between "texture array" and "array of textures" in d3d11 [23:04:06 CET] <wm4> the former is a hardware abstraction, the latter is just a bunch of unrelated textures? [23:11:19 CET] <TD-Linux> yes, vp9 has tags though yt videos are untagged and chrome magically picks bt.709 [23:13:17 CET] <nevcairiel> wm4: apparently so, you can either allocate a bunch of Texture2D objects, or allocate one with X "elements" [23:13:51 CET] <nevcairiel> and the hevc dxva2 spec lets the driver ask for one of the two modes for better performance =p [23:14:15 CET] <nevcairiel> although obeydience is optional [23:15:03 CET] <wm4> interesting, wouldn't have thought that it makes a perf difference at all with just 2 textures [23:15:55 CET] <nevcairiel> the difference is only in d3d11 anyway, i dont do that (yet) [23:16:14 CET] <nevcairiel> d3d11 hw decoding api is freaking weird anyway [23:16:51 CET] <wm4> weird in what way? I'll have to implement this at some point too [23:17:03 CET] <nevcairiel> it seems just so complex [23:17:19 CET] <nevcairiel> but i havent done it yet, so maybe it'll fall in place and make sense somehow [23:24:47 CET] <nevcairiel> .. so much to do, so little time [23:46:56 CET] <BBB> wm4: yes, vp8 was fixed to bt601 [23:47:14 CET] <BBB> wm4: vp9 isnt [23:47:19 CET] <wm4> ok [23:47:37 CET] <BBB> its allowed to be unknown just like in h264/hevc so often its unknown" [23:47:49 CET] <BBB> I dont know how yt decides it should be bt709 or whatever [23:49:33 CET] <wm4> BBB: possibly resolution? [23:49:42 CET] <TD-Linux> BBB, chrome decides that if it's MSE then it's bt 709 [23:49:53 CET] <BBB> could be. I didnt mean Id have no idea, I meant I dont know :) [23:50:02 CET] <TD-Linux> otherwise it's >480 height it's bt 709 [23:50:11 CET] <BBB> ah ok [23:50:16 CET] <wm4> MSE? [23:50:32 CET] <TD-Linux> media source extensions, aka "detect youtube" [23:50:33 CET] <nevcairiel> but but pal sd is 576, always with these limited american minds [23:50:36 CET] <wm4> oh [23:57:08 CET] <BBB> status:closed, resolution: works4me [00:00:00 CET] --- Thu Feb 25 2016

1 0

ffmpeg.log.20160224
by burek 25 Feb '16

25 Feb '16

[00:02:02 CET] <Rajko> JEEB, so does it put the extradata into the output AVFrame ? [00:02:23 CET] <Rajko> on filter_filter ? [00:02:35 CET] <lroe> so this config *should* have created an m3u8 file in /tmp/hls? http://paste.debian.net/hidden/678d22d3/ [00:04:33 CET] <JEEB> Rajko: bsfs are kind of special [00:04:39 CET] <JEEB> special like in "special olympics" [00:04:45 CET] <Rajko> because like... how can it do that [00:04:51 CET] <Rajko> you only get one avframe back in filter_filter [00:05:01 CET] <Rajko> does it output multiple NALs in one AVFrame ? [00:05:04 CET] <JEEB> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264_mp4toannexb_bs… [00:05:25 CET] <Rajko> the stuff that happens if idr_sps_seen is 0 [00:05:27 CET] <JEEB> the whole thing doesn't even touch AVFrames [00:05:37 CET] <Rajko> it does, it replaces the header with 0001 at least [00:05:49 CET] <JEEB> well I mean API-wise [00:05:52 CET] <Rajko> 'replaces' being it allocates a new data and puts it there [00:06:11 CET] <JEEB> but yes looking at that I see it probably allocates another buffer [00:06:26 CET] <JEEB> so that the contents of the AVFrame get converted [00:06:39 CET] <Rajko> im asking if theres no sps/pps in the first avframe you give it [00:06:48 CET] <Rajko> does it prepend them in the output avframe [00:06:57 CET] <Rajko> or doe sit just straight up replace the avframe with a sps/pps avframe [00:07:03 CET] <Rajko> or does nothing other than convert header [00:07:30 CET] <JEEB> see the if (!ctx->extradata_parsed) part :) as far as I can tell it just pushes it into the "front" of the buffer [00:07:38 CET] <JEEB> with h264_extradata_to_annexb [00:07:42 CET] <Rajko> 'insert' seems that it outputs more than 1 NAL in the out AVFrame [00:07:51 CET] <Rajko> so theres multiple startcodes [00:08:27 CET] <Rajko> which means i gotta split it back again if im outputting to something that cant handle more than oen [00:08:34 CET] <JEEB> yes [00:08:41 CET] <JEEB> that's how I understand that code [00:08:50 CET] <JEEB> with a quick look, since I've never used it API-wise [00:09:00 CET] <Rajko> JEEB, how about i just do it myself :D [00:09:43 CET] <Rajko> way more efficient than it allocating a new copy every time i call it that i then have to free [00:09:55 CET] <JEEB> sure [00:10:09 CET] <Rajko> the only difference between annexb and avcc is the extradata format and the 4 byte header ? [00:10:15 CET] <JEEB> yup [00:10:17 CET] <Rajko> great [00:10:39 CET] <JEEB> AVCc can have N byte header with the length (variable, because WhyNot), Annex B has three and four byte headers [00:11:09 CET] <Rajko> ffmpeg avcodec decides to use one or the other based on extradata format [00:11:22 CET] <Rajko> (with null extradata it expects annexb) [00:11:34 CET] <JEEB> the truth is less pretty [00:11:40 CET] <JEEB> it probably in many cases just probes [00:11:52 CET] <Rajko> im saying avcodec, not ffmpeg binary as a whole [00:12:05 CET] <JEEB> I think at least in AVC and HEVC decoders there's probing for AVCc/Annex B start codes [00:12:17 CET] <JEEB> or well, start code for the latter [00:12:19 CET] <Rajko> well it didnt work when it had no header or avcc header [00:12:22 CET] <Rajko> with null extradata [00:12:32 CET] <Rajko> but it did work with 0,0,1 or 0,0,0,1 with null extradata [00:12:44 CET] <JEEB> that's surprising [00:13:06 CET] <JEEB> because mp4 without any parameter sets out-of-band is kind of legal [00:13:10 CET] <JEEB> I guess the demuxer might do some magic [00:13:23 CET] <Rajko> well it needs to know how many bytes is the header [00:13:26 CET] <Rajko> in case of avcc [00:13:30 CET] <Rajko> so with null extradata it cant do that [00:13:33 CET] <JEEB> yes, so the AVCc structure should be there [00:13:45 CET] <JEEB> it just doesn't have to contain any decoding-related parameter sets [00:14:05 CET] <JEEB> so yeah, you are correct then that it will not work without the AVCc structure there [00:14:07 CET] <Rajko> how does it figure out profile/level with annexb extradata though [00:14:10 CET] <Rajko> thats not in that, just sps/pps [00:14:18 CET] <Rajko> is it redundantly in sps ? [00:14:35 CET] <JEEB> I think lavc always probes the profile/level from the parameter sets [00:14:54 CET] <JEEB> I don't think it actually uses the values in the container AVCc structure [00:15:15 CET] <JEEB> (they added even more duplicated info in the HEVC-for-ISOBMFF spec) [00:15:24 CET] <Rajko> so null extradata is fine as long as it gets a sps/pps in the bitstream before a IDR, yes ? [00:15:46 CET] <JEEB> yes, and annex b in that case [00:16:14 CET] <Rajko> i also had to give it CODEC_FLAG2_CHUNKS because i was feeding it one NAL at a time [00:16:24 CET] <Rajko> otherwise you have to give it enough to decode an entire frame [00:16:32 CET] <Rajko> but i was told that this disables multithreaded decoding ? [00:18:12 CET] <proxima> zzuf[s=86382,r=0.004]: signal 9 (memory exceeded?). what it means and how do we handle this? [00:20:40 CET] <JEEB> Rajko: I don't have ffmpeg.git cloned here but at least the quick look at h264.c doesn't strictly seem to disable MT... although it is mentioned by some third party [00:21:31 CET] <JEEB> oh [00:21:34 CET] <JEEB> pthread.c [00:22:02 CET] <JEEB> int frame_threading_supported = .. && && !(avctx->flags2 & AV_CODEC_FLAG2_CHUNKS); [00:22:05 CET] <JEEB> so yeah [00:22:35 CET] <JEEB> drip-feeding the decoder only lets you do slice based threading [00:35:43 CET] <Rajko> which is fine because frame threading is broken anyway ? [00:36:52 CET] <Rajko> how about this, is it possible for ffmpeg compiled with --disable-codecs to mux 264 and aac into a mp4 container from a source it didnt demux ? [00:37:24 CET] <Rajko> because i wasnt able to figure that one out [00:40:31 CET] <JEEB> frame threading has its limitations, but it is the most speedy way of threading (sliced threads have lower latency and less memory consumption, but speed-wise frame threading is king) [00:40:59 CET] <JEEB> only hwaccel+frame threading is something that is not recommended, mostly because you get jack shit out of that anyways [00:41:50 CET] <JEEB> not sure about your last question but in theory it should be possible, esp. if the h264 parser is in lavf [00:41:53 CET] <Rajko> i dunno how i would set up the avstream and such for those [00:42:15 CET] <Rajko> i would need the avcodec copy context and i dont know how to get one of those, only by find_decoder_by_name etc [00:42:46 CET] <JEEB> I would probably just make my own AVIO wrapper and tell it its raw annex b or something if I was lazy [00:42:59 CET] <JEEB> and have the h264 demuxer demux it for me [00:43:00 CET] <Rajko> but then it wouldnt have pts/dts [00:43:11 CET] <JEEB> true that [00:43:42 CET] <Rajko> you can just feed avframes to av_mux_interleaved or whatever, but you need to set up a stream for each stream, a codec context so it knows what codec it is, etc [00:44:00 CET] <JEEB> not that you couldn't override the PTS [00:44:12 CET] <JEEB> after having the avformat h264 demuxer read the data [00:44:14 CET] <Rajko> also, where does mp4 even store pts/dts as 264 doesnt ahve it [00:44:14 CET] <JEEB> :D [00:44:57 CET] <JEEB> ISOBMFF had to come up with its own nomenclature so it's called DTS and CTS (Composition Time Stamp) there [00:45:08 CET] <JEEB> also there's multiple boxes in mp4 that contain timestamps [00:45:21 CET] <JEEB> you have DTS and then a CTS offset for each sample [00:45:43 CET] <Rajko> i have the opposite as input though [00:45:56 CET] <Rajko> i only have pts, and the order i have my packets in is the 'dts' [00:46:03 CET] <JEEB> yes [00:46:07 CET] <JEEB> that's how it goes generally [00:46:17 CET] <JEEB> thus you have the DTS pretty much always :P [00:46:33 CET] <JEEB> so you just have to override the PTS as lavf h264 demuxer reads the packets [00:46:37 CET] <Rajko> do the pts and dts have to start at the same value ? [00:46:44 CET] <JEEB> no [00:46:52 CET] <Rajko> but <JEEB> you have DTS and then a CTS offset for each sample [00:47:07 CET] <JEEB> yes, that's in mp4 [00:47:11 CET] <JEEB> the muxer can make that up [00:47:12 CET] <Rajko> does it figure that out ? [00:47:22 CET] <JEEB> the main thing is to not have DTS > PTS :P [00:47:45 CET] <Rajko> so i could just fake the dts as index of NAL i have [00:50:17 CET] <Rajko> im afraid that it would then make the mp4 pts really inaccurate if its stored as offset from dts [00:51:36 CET] <JEEB> pretty sure it'll be OK if you handle timebases (or in ISOBMFF vocab timescales) properly into mention [00:52:24 CET] <JEEB> also having lavf-based muxing for something completely different isn't really that rare, with a quick reminder I can think of VLC having a lavf muxer that works without lavc being used for encoding before it [00:54:31 CET] <JEEB> also if you are doing custom demuxing you might just want to look at L-SMASH for ISOBMFF muxing [00:54:44 CET] <Rajko> i can also try just setting pts and having dts be AV_NO_DTS or whatever, but im afraid it will just set dts=pts in that case and mess up my b-frames [00:55:05 CET] <JEEB> it's a library that's meant just for that, and is quite spec-compliant [00:55:49 CET] <Rajko> (also is there a rtsp server out there that actually supports ffmpeg streaming rtsp to it ?!) [00:57:47 CET] <JEEB> Rajko: talking of b-pictures, the way it's handled in ISOBMFF is fun. for a while the CTS offsets could only be positive, so you basically had N samples' duration worth of positive offset on the first sample, depending on the required amount. then you would have a thing called an edit list that would map that initial sample's CTS to be the start of the video track's time line. [00:58:40 CET] <Rajko> well all the hls.js things out there convert mpeg2-ts to mp4 on the fly in JS so it cant be that hard [00:59:18 CET] <Rajko> oh good l-smash is all in japones [00:59:28 CET] <JEEB> the "official site" only [00:59:34 CET] <JEEB> the code and headers is all English [00:59:45 CET] <JEEB> and I've been thinking of English'izing the site [00:59:52 CET] <JEEB> ENOTIME [01:01:04 CET] <JEEB> anyways, then later people who didn't want to implement edit lists (they weren't required by the spec) complained enough and ISO decided to let the user decide whether they wanted int32 or uint32 CTS offsets depending on the version of that box used [01:04:17 CET] <JEEB> that said, if I recall correctly L-SMASH is quite a bit on a different level than lavf [01:04:47 CET] <Rajko> i just want to get rtsp video to a browser, i can either do that by decoding myself/using chrome api, or trying to mux into a mp4 and give that to MSE [01:04:59 CET] <JEEB> gunky [01:05:03 CET] <JEEB> uhh, funky [01:05:04 CET] <JEEB> I meant [01:05:12 CET] <Rajko> still no clue how i will handle a/v sync in the first case [01:05:36 CET] <Rajko> ffplay has super overcomplicated sync code [01:07:18 CET] <JEEB> you'd probably want tot take a look at a real player first, like mpv [01:07:31 CET] <JEEB> both use lavf in the background, of course [01:17:17 CET] <proxima> Explain about the qualification task(about fixing the crash using zzuf) mentioned for project Create a fuzzing testsuite for FFmpeg for Outreachy 2016. Please clear what kind of crash i.e. software or a simple file or any other specification? [01:47:33 CET] <jookiyaya> what is the latest version of x265 [02:07:57 CET] <J_Darnley> what ever is in their git (or other VCS) [02:21:42 CET] <jookiyaya> does ffmpeg come with FDK AAC encoder? [02:22:55 CET] <J_Darnley> no [02:23:05 CET] <kepstin> you can build your own copy that uses the fdk aac encoder, but because of license incompatibility problems ffmpeg binaries with fdk aac can't be distributed. [02:23:17 CET] <J_Darnley> ^ what he said [02:24:03 CET] <jookiyaya> if it's not allowed, then why am i allowed when i building my own copy? [02:24:14 CET] <J_Darnley> because you're not distributing [02:24:34 CET] <jookiyaya> may i ask what happened? why was it allowed before? [02:24:39 CET] <J_Darnley> it never was [02:24:39 CET] <kepstin> the provisions of the GPL license only take effect when you distribute the binaries to other people [02:24:44 CET] <jookiyaya> and all of sudden not anymore [02:25:00 CET] <jookiyaya> j_darnley i am pretty sure old version of ffmpeg had fdk aac encoder before [02:25:29 CET] <J_Darnley> Perhaps a long time ago, before people realised, but not last week, last month, last year [02:25:35 CET] <kepstin> if people were distributing it before, they were in violation of the license, so perhaps when informed of that fact they took it down? [02:26:03 CET] <jookiyaya> and for example: old version of handbrake supported fdk-aac [02:26:14 CET] <jookiyaya> and just now released new version without it [02:26:31 CET] <jookiyaya> Thursday, Feb 11, 2016 [02:26:31 CET] <jookiyaya> Unfortunately due to circumstances beyond our control we can no longer include binary distributions of HandBrake which include the FDK-AAC encoder. [02:26:31 CET] <jookiyaya> Please also be aware that if you are distributing any previous 0.10.x you must cease doing so now due to licensing issues. [02:26:37 CET] <kepstin> all current ffmpeg binaries should include the native aac encoder of course, which while it isn't quite as good as fdk-aac is still decent, and far better than vo-aacenc. [02:27:13 CET] <jookiyaya> is fdk-aac better than apple-aac aka coreaudio-aac [02:27:26 CET] <kepstin> not sure, I haven't seen any comparisons [02:27:31 CET] <furq> "circumstances beyond our control" probably means "we misread the licence" [02:28:15 CET] <furq> and i'm not aware of any meaningful listening test comparing fdk and qaac [02:29:17 CET] <kepstin> i'd expect they're overall fairly similar, and almost certainly nearly indistinguishable at higher bitrates. [02:29:22 CET] <furq> you might be confusing fdk-aac for libfaac which was previously distributed with some ffmpeg builds [02:29:38 CET] <jookiyaya> what is qaac ? [02:29:47 CET] <furq> qaac is the same thing as appleaac [02:29:52 CET] <jookiyaya> i see [02:30:03 CET] <jookiyaya> does ffmpeg support qaac ? [02:30:09 CET] <furq> not as far as i'm aware [02:30:21 CET] <J_Darnley> maybe as a system library on a mac [02:30:27 CET] <furq> qaac is a binary which requires itunes to be installed [02:30:27 CET] <kepstin> qaac isn't even an aac encoder, it's just a command line tool for using apple's aac encoder library [02:31:17 CET] <furq> i doubt there's any distinguishable difference between qaac, fdk and ffmpeg at >=128kbps anyway [02:32:10 CET] <kepstin> for the listening comparisons for these codecs, they always go down to something like 64kbit anyways, so that the encodes have a chance of being distinguished. [02:32:12 CET] <rsully> kepstin so fdk is still better than native? [02:32:13 CET] <furq> the builtin ffmpeg encoder is recommended now for cbr aac-lc [02:32:23 CET] <furq> for anything else fdk is better [02:32:41 CET] <rsully> does builtin support 5.1? [02:33:53 CET] <jookiyaya> according to ffmpeg site: libopus > libvorbis >= libfdk_aac > aac > libmp3lame >= libfaac >= eac3/ac3 > libtwolame > vorbis > mp2 > wmav2/wmav1 [02:34:07 CET] <jookiyaya> is this accurate of the author is very bias? [02:34:28 CET] <jookiyaya> is this accurate or the author is very bias? [02:35:20 CET] <jookiyaya> why are there 2 vorbis ? [02:35:27 CET] <furq> vorbis is the ffmpeg internal encoder which sucks [02:35:39 CET] <jookiyaya> and libvorbis is? [02:35:44 CET] <furq> libvorbis is libvorbis [02:35:47 CET] <kepstin> libvorbis is xiph's reference encoder library [02:36:04 CET] <jookiyaya> liborvis is a lot better than vorbis? [02:36:32 CET] <furq> it sure looks like it [02:36:42 CET] <kepstin> "libvorbis" is a lot better of an encoder than ffmpeg's builtin "vorbis" encoder. [02:36:47 CET] <furq> i doubt libvorbis is better than fdk, but it's certainly better than lame [02:38:20 CET] <furq> rsully: i just checked and it seems to support 5.1 [02:38:42 CET] <rsully> I guess the better question is does mp4 support ac3 widely or not [02:38:56 CET] <rsully> since I'm in the process of muxing an mkv to mp4, and the mkv has ac3 audio [02:39:22 CET] <furq> it's not part of the spec iirc [02:39:28 CET] <rsully> that's what i thought [02:40:07 CET] <wintershade> hey guys! a quick question. I'm converting some x264 videos, and I want them to work properly on hardware players. I have chosen high profile v4.0, which I suppose works on Apple and Sony devices, right? will MKV work there? also, which format should I use for subtitles, SRT or ASS? is there a chart/documentation where I can look these things up (i.e. what works where, and what not)? thanks in advance! [02:40:08 CET] <rsully> I know ffmpeg can "force" it, but pretty sure playback support is limited [02:40:26 CET] <furq> yeah if you care about compatibility then convert to aac [02:40:46 CET] <rsully> furq what would you recommend for this 5.1? builtin aac or fdk? [02:40:58 CET] <rsully> in the past I used fdk at -b 512k and -cutof 18000 [02:41:10 CET] <furq> i downmix everything to stereo so idk [02:41:20 CET] <furq> if you have a build with fdk then you might as well use it [02:41:36 CET] <rsully> well -b 512k would be cbr right? and it sounds like builtin is better in that case? [02:43:03 CET] <furq> i suspect "better" factors in not having to bundle a library with a ropey license [02:43:21 CET] <rsully> oh ok. [02:43:29 CET] <furq> i doubt there's much difference in terms of quality [02:44:45 CET] <rsully> I know 512k is probably overkill, but I figure audio is so small I'd rather go a little bloated and ensure quality is maintained [02:46:19 CET] <rsully> according to this AC3 is supported in mp4 https://en.wikipedia.org/wiki/Comparison_of_video_container_formats [02:46:34 CET] <rsully> citing "ETSI TS 102 366 v1.2.1 - Digital Audio Compression (AC-3, Enhanced AC-3) Standard, Annex F" [02:46:36 CET] <rsully> with no link... [02:46:56 CET] <kepstin> rsully: you'd have to check individual players. e.g. web browsers will do h264+aac, but not ac3; quicktime probably does both. [02:47:02 CET] <furq> https://en.wikipedia.org/wiki/MPEG-4_Part_14#Data_streams [02:47:05 CET] <furq> i'm going off that [02:47:41 CET] <rsully> Yeah I saw that originally [02:48:08 CET] <furq> why are you muxing to mp4 anyway [02:48:24 CET] <rsully> for iOS/appletv playback [02:48:32 CET] <rsully> just general portability [02:48:45 CET] <rsully> since its a h264 stream in the mkv anyways [02:48:49 CET] <furq> if it's for a specific device then you might as well try it [02:49:12 CET] <rsully> I tried it, but ffmpeg gave me a warning [02:49:33 CET] <rsully> "track 1: codec frame size is not set" [02:49:49 CET] <rsully> thats a straight -c:a copy [02:51:10 CET] <rsully> and I know a year ago when I was experimenting with this I had hit-or-miss results with my iphone playback [02:55:59 CET] <jookiyaya> which aac encoder does youtube use [02:59:59 CET] <kepstin> huh, I wouldn't actually know how to find out. I wonder if any of the aac encoders snuck in watermarks like x264 did :) [03:00:27 CET] <furq> i've read that they use fdk but i don't know how reliable that is [03:01:18 CET] <kepstin> that would make sense; they do apparently use a lot of pieces based on ffmpeg, and the platform is almost certainly running on linux [03:01:31 CET] <kepstin> could have also licensed someone else's, e.g. nero [03:01:46 CET] <furq> i think we can safely rule out appleaac [03:06:03 CET] <rsully> hm youtube uses CBR AAC LC [03:06:08 CET] <rsully> but no hints to encoder in mediainfo [03:06:17 CET] <wintershade> hey guys, how do I set default streams in MKV? I have two audio streams and one subtitle stream, and would like a specific audio stream to be defaul, as well as load the subtitles by default. [03:06:22 CET] <wintershade> (yes, it's anime.) [03:09:37 CET] <kepstin> wintershade: huh, I don't actually know... If all else fails, it might be easiest to just run the ffmpeg output through mkvmerge after encoding to set the metadata up. [03:11:13 CET] <wintershade> kepstin: is mkvmerge available for Linux?* [03:11:26 CET] <kepstin> wintershade: yep, it's usually in the 'mkvtoolnix' package [03:11:51 CET] <kepstin> i suspect you can do it in ffmpeg by using the '-metadata' option, if you know the right metadata keys [03:11:54 CET] <wintershade> okay thanks [03:12:10 CET] <wintershade> kepstin: I've tried, looking at Matroska's metadata keys... but it doesn't really work. [03:12:53 CET] <furq> afaik ffmpeg can't do it but you can edit it inplace with mkvpropedit [03:12:57 CET] <furq> which is also part of mkvtools [03:13:10 CET] <furq> s/s$/nix/ [03:13:39 CET] <wintershade> lol [03:13:42 CET] <wintershade> thanks [03:13:50 CET] <wintershade> I'll do that, then. [03:14:11 CET] <wintershade> how come ffmpeg is unable to do it, though? if I may ask [03:18:12 CET] <kepstin> it looks like all the stuff is wired up in the matroska muxer to do it, actually. hmm. [03:18:23 CET] <furq> yeah there's a patch which added it last january [03:18:29 CET] <furq> but the docs for -disposition just say "disposition" [03:18:34 CET] <furq> which is not really helpful [03:18:37 CET] <slowfoxtrot> hey guys I have a question about m3u8 [03:18:44 CET] <slowfoxtrot> anyone familiar with that format? [03:18:47 CET] <furq> or -h format=mkv says that, the docs don't mention it at all [03:19:06 CET] <kepstin> slowfoxtrot: it's a text-based playlist file encoded in utf8 [03:19:14 CET] <kepstin> slowfoxtrot: often used to describe HLS streams [03:19:20 CET] <slowfoxtrot> yes, I have found that when I use ffplay [03:19:30 CET] <slowfoxtrot> it reads the EXT-X-DISCONTINUITY correctly [03:19:41 CET] <slowfoxtrot> and the timestamps are adjusted accordingly [03:20:17 CET] <slowfoxtrot> but when I try to use ffmpeg it apparently ignores that flag and just duplicates the last frame of the previous frame for the duration of the commercial [03:20:25 CET] <slowfoxtrot> the time is shifted in ffplay [03:20:29 CET] <slowfoxtrot> but absolute in ffmpeg [03:20:50 CET] <slowfoxtrot> is there a trick to get ffmpeg to play nice with EXT-X-DISCONTINUITY? [03:21:05 CET] <wintershade> furq: thanks, I've looked into disposition flag. thing is, I've tried setting "default" streams with disposition, but it leaves me with some other tracks set as default, which I cannot "un-default". [03:21:45 CET] <wintershade> furq: i.e., I have a video stream, two audio streams and the subs. I set the audio stream A to be default, but I see ffmpeg setting both A and B as default. [03:22:07 CET] <wintershade> furq: most likely based on the fact that stream B is default in the source, and it just copies that flag, oddly enough. [03:22:10 CET] <furq> shrug [03:22:18 CET] <Rajko> slowfoxtrot, ffmpeg doesnt have a great hls/m3u8 parser [03:22:22 CET] <furq> i vaguely remember this being broken but i've never actually used it [03:22:25 CET] <Rajko> use python livestreamer and pipe to whatever program you need instead [03:22:55 CET] <slowfoxtrot> Rajko: I thought that might be the case, but I thought it was ironic that ffplay worked correctly [03:23:09 CET] <slowfoxtrot> I believe ffmpeg receives a lot more attention than ffplay [03:23:27 CET] <Rajko> theyre in the same thing [03:23:30 CET] <Rajko> ffplay uses ffmpeg lib [03:23:38 CET] <slowfoxtrot> how can I make ffmpeg not keep the timestamps absolute? [03:23:53 CET] <slowfoxtrot> I want it to just skip immediately to the next video and not duplicate frames [03:24:06 CET] <wintershade> damn, this mkvtoolnix sure takes a long time to compile... [03:24:12 CET] <slowfoxtrot> lol right now during the commerical it looks like the video is frozen for like 10 seconds on the same frame [03:24:45 CET] <kepstin> wintershade: yeah, their build system sucks. Doesn't support parallel compilation [03:24:56 CET] <slowfoxtrot> if ffplay uses ffmpeg then I would imagine there has to be a way to make ffmpeg do what i am seeing in ffplay [03:25:16 CET] <Rajko> ffmpeg doesnt display any video tho ? [03:25:17 CET] <Rajko> ffplay does [03:25:29 CET] <Rajko> so you want the a/v sync code out of ffplay instead of whatever player you are currently using [03:25:37 CET] <slowfoxtrot> yes, but they aaparently parse m3u8 files diferently [03:25:42 CET] <Rajko> no they dont [03:25:47 CET] <Rajko> ffplay uses ffmpeg to demux that [03:26:13 CET] <slowfoxtrot> basically my m3u8 file had various EXT-X-DISCONTINUITY flags to skip like 10 seconds from time to time [03:26:41 CET] <slowfoxtrot> ffplay skips over the 10 seconds, ffmpeg shows 10 seconds of the last frame [03:26:44 CET] <Rajko> the m3u8 parser is the same, there is no m3u8 parser in ffplay.c go look for yourself if you want [03:26:50 CET] <Rajko> how can ffmpeg 'show' anything ? [03:26:53 CET] <Rajko> its not a video player. [03:27:25 CET] <slowfoxtrot> im referring to the mp4 im getting from the ffmpeg output [03:27:25 CET] <wintershade> Rajko: there is ffplay... [03:27:26 CET] <furq> i'm going to go out on a limb and say he means the video encoded by ffmpeg [03:27:39 CET] <kepstin> keep in mind that many of the output formats that ffmpeg supports can't handle pts discontinuities; mp4 is one of them iirc [03:27:52 CET] <slowfoxtrot> maybe that is the problem [03:28:05 CET] <slowfoxtrot> is there a format that can handle discontinuities? [03:28:19 CET] <furq> if it works in hls then presumably .ts can [03:28:20 CET] <kepstin> dunno. mpegts maybe? haven't tried. [03:28:26 CET] <Rajko> furq, it doesnt [03:28:34 CET] <Rajko> the m3u8 file supplements it [03:28:36 CET] <wintershade> kepstin: perhaps I should have compiled it without qt5 support... [03:28:56 CET] <kepstin> wintershade: heh, yeah, that doubles the build time and gives you a gui of questionable usefulness :) [03:29:09 CET] <wintershade> kepstin: stopping now. recompiling. [03:29:33 CET] <slowfoxtrot> kepstin: Ill bet you nailed it kepstin& if mp4 cant handle discontinuities then it might be the container that simply needs to change [03:30:21 CET] <kepstin> well, one fix would be to use a filter that rewrites the pts values to remove the discontinuities (or re-encode the video, perhaps) [03:30:25 CET] <wintershade> what's the advantage of mp4 over mkv? [03:30:26 CET] <slowfoxtrot> any suggestions on a good container i should try? [03:30:35 CET] <wintershade> slowfoxtrot: OGM hehe [03:30:42 CET] <slowfoxtrot> lol [03:30:45 CET] <Rajko> why dont you try just using livestreamer as an stdout input of ffmpeg ? [03:30:50 CET] <wintershade> slowfoxtrot: it's actually pretty robust, error-wise. [03:31:02 CET] <wintershade> especially when it comes to errors on the physical media. [03:31:06 CET] <Rajko> it handles hls/m3u8 way better than the in-ffmpeg code [03:31:08 CET] <wintershade> I was pleasantly surprised. [03:31:14 CET] <kepstin> wintershade: the advantage of mp4 over mkv is that it plays on apple devices mostly :) [03:31:22 CET] <wintershade> kepstin: and mkv doesn't? [03:31:45 CET] <furq> mp4 is more widely supported and also worse [03:31:56 CET] <wintershade> furq: worse in what way? [03:32:16 CET] <furq> mostly codec support [03:32:34 CET] <wintershade> furq: but if I'm using x264+aac+srt... shouldn't it work well? [03:32:44 CET] <furq> it doesn't support srt [03:32:48 CET] <wintershade> O.o [03:32:52 CET] <wintershade> whoa [03:32:56 CET] <kepstin> wintershade: mp4 doesn't have any widely supported text subtitle formats [03:32:56 CET] <slowfoxtrot> trying ts [03:32:57 CET] <wintershade> (in keanu reeves voice) [03:33:06 CET] <furq> it has mov_text [03:33:11 CET] <furq> idk how widely supported it is though [03:33:16 CET] <slowfoxtrot> can you use livestreamer to output to a file? [03:33:20 CET] <Rajko> slowfoxtrot, yes [03:33:27 CET] <Rajko> or to stdout so you can pipe it directly to ffmpeg [03:33:31 CET] <wintershade> ok, so how do I get subtitles to play on a standalone player then? [03:33:37 CET] <wintershade> external srt file? or something? [03:33:50 CET] <furq> either that or mov_text [03:34:01 CET] <wintershade> wow. [03:34:20 CET] <furq> ffmpeg should automatically convert srt to mov_text if you try to mux it into mp4 [03:34:23 CET] <furq> iirc [03:34:34 CET] <wintershade> hmm [03:34:43 CET] <wintershade> perhaps I should try using m4v instead of mkv then.. [03:34:45 CET] <kepstin> also, you can't write mp4 files to a pipe, which is kind of annoying at times. [03:35:54 CET] <slowfoxtrot> Rajko: could you give me some sudo code for piping livestreamer to ffmpeg? [03:35:59 CET] <slowfoxtrot> i just installed livestreamer [03:36:52 CET] <Rajko> livestreamer hlsvariant://your.hls.url.here/m3u8 best --stdout | ffmpeg ... [03:37:25 CET] <slowfoxtrot> k let me try [03:37:38 CET] <Rajko> tell ffmpeg to read from stdin too [03:37:57 CET] <slowfoxtrot> is this correct? [03:37:57 CET] <Rajko> which is ffmpeg -i - [03:38:30 CET] <slowfoxtrot> livestreamer [stream] | ffmpeg -i pipe:0 -c copy -loglevel verbose test.mp4 [03:38:31 CET] <slowfoxtrot> ? [03:38:50 CET] <Rajko> you missed half the arguments i gave you [03:38:53 CET] <Rajko> best and --stdout [03:39:24 CET] <slowfoxtrot> ok [03:39:38 CET] <slowfoxtrot> is pipe the correct stdin for ffmpeg? [03:40:25 CET] <kepstin> slowfoxtrot: you can just use '-' as the input file to get stdin, but that should be equivalent. [03:40:27 CET] <Rajko> its just -i - [03:40:47 CET] <slowfoxtrot> livestreamer: error: unrecognized arguments: best [03:41:20 CET] <slowfoxtrot> does best need to come before the url? [03:41:33 CET] <Rajko> after [03:41:51 CET] <Rajko> what if you just type livestreamer url what does it give you [03:42:03 CET] <Rajko> (not piped to ffmpeg) [03:42:35 CET] <slowfoxtrot> k trying now [03:44:16 CET] <slowfoxtrot> what does hlsvariant:// mean? [03:44:26 CET] <slowfoxtrot> the m3u8 is just hosted on an apache server [03:44:28 CET] <Rajko> it means its a hls stream with multiple qualities [03:44:30 CET] <slowfoxtrot> via http:// [03:44:49 CET] <Rajko> aka the m3u8 points to multiple m3u8s with different qualities [03:44:58 CET] <slowfoxtrot> ah I see [03:47:02 CET] <slowfoxtrot> shoot it is expecting https [03:47:13 CET] <slowfoxtrot> hlsvariant apparenlty defaults to http [03:47:15 CET] <Rajko> try hlsvariant://http:// then [03:48:14 CET] <slowfoxtrot> trying [03:49:24 CET] <slowfoxtrot> while Im working on this, do you think it is worth trying straight ffmpeg with different containers that might be more friendly to discontinuities? [03:49:28 CET] <slowfoxtrot> do you think that could be the issue? [03:54:54 CET] <slowfoxtrot> is there a way with livestreamer to skip the m3u8 that point to the multiple m3u8s with different qualities and put in the URL of the quality desired directly? [03:56:49 CET] <wintershade> k I'm off, thanks everyone for your help! [03:57:31 CET] <slowfoxtrot> thanks wintershade [04:02:15 CET] <Rajko> yes its just hls:// i think [04:04:42 CET] <kepstin> hmm, it doesn't look like livestreamer actually will do any timestamp discontinuity corrections - I think it just concatenates the mpegts segments [04:04:57 CET] <Rajko> whats wrong with that [04:05:16 CET] <kepstin> nothing, except that it won't fix the problem that slowfoxtrot is having :) [04:05:22 CET] <Rajko> you sure [04:05:33 CET] <Rajko> maybe just concatenating is exactly what he needs [04:05:49 CET] <slowfoxtrot> no i think that is exactly what I wan [04:05:52 CET] <slowfoxtrot> want actualy [04:05:56 CET] <kepstin> but the built-in ffmpeg hls support should be doing that already - concatenating the hls ts segments [04:06:04 CET] <kepstin> i'd expect the behaviour to be identical [04:06:09 CET] <slowfoxtrot> i want it to concat them together and normal ffmpeg output doesnt [04:06:19 CET] <kepstin> be interesting to try and see i guess [04:06:40 CET] <slowfoxtrot> is there an argument to tell ffmpeg to explicltiy concatenate the hls ts segments? [04:07:10 CET] <kepstin> if you just want the concatenated mpeg-ts segments on your hard drive, using only livestreamer is probably the best option (without ffmpeg at all) [04:07:56 CET] <slowfoxtrot> but i want to output to some kind of friendly video file? [04:10:32 CET] <altusd> So 3.0 was just released. I went to the Windows builds page, saw no mention of 3.0 (or any other version number). Downloaded the latest file... unpacked... [04:10:38 CET] <altusd> NO MENTION AT ALL OF 3.0! [04:10:42 CET] <altusd> Or any version number at all. [04:10:48 CET] <Rajko> run ffmpeg -v [04:10:50 CET] <J_Darnley> Of course [04:10:51 CET] <altusd> "ffmpeg version N-78636-g45d3af9 Copyright (c) 2000-2016 the FFmpeg developers" [04:10:58 CET] <altusd> The hell is N-78636-g45d3af9? [04:11:02 CET] <J_Darnley> only foolish people don't use the latest git master [04:11:03 CET] <Rajko> git commit id [04:11:11 CET] <slowfoxtrot> wow [04:11:12 CET] <kepstin> slowfoxtrot: it'll probably work if you actually do a video transcode; this seems to only be an issue with using -c copy [04:11:25 CET] <slowfoxtrot> unbelieveable, livestreamer did NOT concat the ts stream [04:11:44 CET] <slowfoxtrot> it actually stopped on the frame and showed it for the duration of the break [04:11:50 CET] <altusd> "Missing argument for option 'v'." [04:11:50 CET] <slowfoxtrot> just like normal ffmpeg output... [04:11:58 CET] <altusd> What is going on? [04:12:16 CET] <J_Darnley> -v is an alias for loglevel [04:12:27 CET] <J_Darnley> -version if you want the version [04:12:48 CET] <slowfoxtrot> kepstin: why in the world would livestreamer not concat the hls ts segments? [04:12:50 CET] <altusd> Heh. This is like the perfect example of how incredibly user-hostile FOSS projects are. I struggle to find any mention of which damn *version* of the program I have! [04:13:06 CET] <Rajko> N-78636-g45d3af9? [04:13:26 CET] <J_Darnley> Stop caring about a pointless version number and use the daily builds. [04:13:31 CET] <altusd> "ffmpeg.exe -version" only prints that garbage data. [04:13:44 CET] <altusd> So 3.0 was made up? [04:13:52 CET] <J_Darnley> All version numbers are made up [04:13:58 CET] <altusd> ... [04:14:19 CET] <altusd> The announcement made it sound as if FFMPEG has reached a whole new generation. [04:14:26 CET] <altusd> 3.0. After many years of 2.x. Etc. [04:14:47 CET] <J_Darnley> Only for dumb people who use linux and *need* a version number [04:15:39 CET] <slowfoxtrot> here is an example of my m3u8 file: [04:15:45 CET] <slowfoxtrot> #EXTINF:20.000, [04:15:45 CET] <slowfoxtrot> https://file-2.ts [04:15:46 CET] <slowfoxtrot> #EXT-X-DISCONTINUITY [04:15:47 CET] <slowfoxtrot> #EXTINF:20.000, [04:15:48 CET] <slowfoxtrot> https://file-4.ts [04:15:48 CET] <J_Darnley> The FFmpeg website points you to where you can get daily build of ffmpeg. [04:16:13 CET] <slowfoxtrot> i believe this is a completely standard m3u8 file [04:16:31 CET] <J_Darnley> The day after 3.0 it became newer than 3.0 [04:17:04 CET] <slowfoxtrot> keptstin: do you have experience concatentating hls ts segments using ext-x-discontinuity? [04:17:11 CET] <kepstin> hmm. 'git describe' does give something a bit more useful than the ffmpeg version string tho, you get "n3.1-dev-173-g45d3af9" [04:17:36 CET] <kepstin> so that's 173 commits after the 3.1 development started. [04:17:53 CET] <kepstin> slowfoxtrot: not specifically, no. [04:19:01 CET] <slowfoxtrot> kepstin: any idea why livestreamer would not have concatenated the hls ts stream? [04:19:19 CET] <slowfoxtrot> kepstin: seems like if livestreamer cant do it im screwed with ffmpeg [04:19:37 CET] <kepstin> slowfoxtrot: my guess is that it probably did, and you might have run into a player issue? [04:20:08 CET] <kepstin> although discontinuous mpeg-ts seems like something that would work in most players :/ [04:20:49 CET] <slowfoxtrot> kepstin: ya I have tested that, but that frame is the exact duration of the discontinuity [04:21:17 CET] <slowfoxtrot> kepstin: and I have tested doing a video transcode to see if that would make ffmpeg concat instead of doing a copy [04:21:42 CET] <slowfoxtrot> kepstin: but it seems whether I copy or transcode the timestamps are always all powerful and nothing ever concats! [04:21:49 CET] <altusd> A cat with a con. [04:21:51 CET] <altusd> Con-cat. [04:23:07 CET] <kepstin> Like, I know I've had ffmpeg transcode mpeg-ts streams where the timestamps periodically reset to 0 just fine (these files are the result of concatting multiple independently encoded segments) [04:23:41 CET] <kepstin> but if you have discontinuities the other way, where the timestamps just suddenly jump higher... :/ [04:23:57 CET] <kepstin> well, that's equivalent to showing a single frame for the length of the discontinuity [04:24:39 CET] <slowfoxtrot> exactly, that is what is happening [04:24:51 CET] <Rajko> working as intended then [04:24:56 CET] <slowfoxtrot> in fact in ffmpeg it actually says dup 167 frames" [04:25:09 CET] <slowfoxtrot> it is duplicating the frame for the duration of the discontinuity [04:25:57 CET] <slowfoxtrot> I am wanting it to ignore the gap, and ffplay does it perfectly [04:26:00 CET] <slowfoxtrot> lol [04:26:12 CET] <slowfoxtrot> it is so frustrating [04:26:24 CET] <slowfoxtrot> but I cant save the output of ffplay to anything anywhere [04:26:32 CET] <kepstin> slowfoxtrot: actually, it looks like you might be able to do it. use the '-dts_delta_threshold' option and set it to something shorter than the length of the discontinuity? [04:26:40 CET] <slowfoxtrot> there has to be a flag Im missing [04:27:25 CET] <slowfoxtrot> -dts_delta_threshold [04:27:26 CET] <slowfoxtrot> Timestamp discontinuity delta threshold. [04:27:47 CET] <slowfoxtrot> hmmm, this seems like it might be what I am looking for, but it doesnt say what the default value is or what it means [04:28:59 CET] <kepstin> slowfoxtrot: the default is '10', and it looks like it's in seconds. [04:29:18 CET] <slowfoxtrot> where are you finding more info? man? [04:29:30 CET] <kepstin> for that? I had to grep the source code :/ [04:29:36 CET] <slowfoxtrot> if it was 10 that would definitely be my problem [04:29:46 CET] <slowfoxtrot> all the ones Im testing are shorter than that [04:31:13 CET] <slowfoxtrot> can it accept floats? [04:31:21 CET] <slowfoxtrot> can I set it to 0.1? [04:31:26 CET] <slowfoxtrot> or even 0? [04:31:48 CET] <kepstin> 0 wouldn't make sense, frames are more than 0 apart so it would detect a discontinuity every frame [04:32:07 CET] <kepstin> and then the video would be all sorts of nasty desynced [04:32:52 CET] <slowfoxtrot> maybe 1 then? [04:33:09 CET] <kepstin> it does take floating point. [04:34:03 CET] <kepstin> you'll want it more than 1 frame long, so I wouldn't go below 0.05 for sure (and even that is iffy) [04:35:54 CET] <slowfoxtrot> ill try 0.5 [04:36:58 CET] <slowfoxtrot> suck [04:37:06 CET] <slowfoxtrot> i just cant get a break with this [04:37:17 CET] <slowfoxtrot> frozen frame nightmare of my life [04:37:30 CET] <slowfoxtrot> lol I tried setting it to 0.5 but still no concat [04:37:42 CET] <slowfoxtrot> just duplicates the frame to fill the gap [04:38:51 CET] <slowfoxtrot> but because ffplay works, then there has to be a way to get ffmpeg to work [04:42:49 CET] <slowfoxtrot> *** 136 dup! lol bane of my existence [04:43:46 CET] <slowfoxtrot> kepstin: I just tested transcoding the video with -dts_delta_threshold set to 1 instead of copy, still no dice [04:44:03 CET] <slowfoxtrot> kepstin: could it still be that I am trying to store it in a mp4? [04:44:14 CET] <slowfoxtrot> do I need to be using a different container? [04:44:28 CET] <kepstin> for the dts_delta_threshold option, I think it depends on the input container format, not output [04:45:05 CET] <slowfoxtrot> thats what I would have thought, because the mp4 shouldnt care that there are discontinuity in the source [04:45:25 CET] <slowfoxtrot> it is the processing from the source that I need to fix, right? [04:50:24 CET] <slowfoxtrot> lol I just dont know what else to try [04:50:33 CET] <slowfoxtrot> i think this hls ts concat stuff hates me [05:00:59 CET] <slowfoxtrot> holy crap I just figured it out [05:02:17 CET] <slowfoxtrot> sanity checking now... [05:51:38 CET] <jookiyaya> it says aac-FDK is removed but i still see it [05:53:15 CET] <furq> what says that [05:53:36 CET] <jookiyaya> Thursday, Feb 11, 2016 [05:53:36 CET] <jookiyaya> Unfortunately due to circumstances beyond our control we can no longer include binary distributions of HandBrake which include the FDK-AAC encoder. [05:53:36 CET] <jookiyaya> Please also be aware that if you are distributing any previous 0.10.x you must cease doing so now due to licensing issues. [05:54:09 CET] <furq> what does that have to do with ffmpeg [05:54:40 CET] <jookiyaya> they told me handbrake uses ffmpeg [05:56:14 CET] <relaxed> jookiyaya: ffmpeg has a native aac encoder you can use [05:56:24 CET] <jookiyaya> what about fdk? [05:56:36 CET] <furq> where do you "still see it" [05:57:02 CET] <relaxed> or compile ffmpeg with libfdk-aac support [06:00:04 CET] <jookiyaya> i have no idea how to compile [06:01:16 CET] <slowfoxtrot> kepstin: i figured it out [06:02:50 CET] <relaxed> jookiyaya: these are questions for #handbrake [06:09:01 CET] <slowfoxtrot> it has libfaac [06:09:15 CET] <slowfoxtrot> or you can just copy native aac [06:09:43 CET] <furq> handbrake uses ffmpeg aac now [06:09:49 CET] <furq> i don't think it uses libfaac any more [06:10:13 CET] <furq> i also think it only ever used fdk for he-aac [06:10:51 CET] <jookiyaya> according to ffmpeg site: libopus > libvorbis >= libfdk_aac > aac > libmp3lame >= libfaac >= eac3/ac3 > libtwolame > vorbis > mp2 > wmav2/wmav1 [06:10:57 CET] <jookiyaya> how accurate is this statement [06:11:09 CET] <furq> well it says vorbis is better than fdk_aac which i find doubtful [06:12:17 CET] <furq> if you're doing cbr aac-lc encodes then just use the builtin aac encoder [06:12:48 CET] <furq> it's not worth going through the hassle of compiling fdk and handbrake for a possible imperceptible quality improvement [06:16:02 CET] <furq> jookiyaya: if you're really determined to use fdk then there's a standalone fdk encoder in debian [06:16:14 CET] <furq> https://packages.debian.org/stretch/fdkaac [08:34:13 CET] <slowfoxtrot> thanks for the help guys [08:34:18 CET] <slowfoxtrot> appreciate all the input [09:00:00 CET] <Hexmind> Hi all. I have a series of raw rgb24 images I want to make a video with. My images are name %08d and I want to make a 60fps avi video. What command should I use? [09:00:28 CET] <Hexmind> Images are 1280x720 and want to make a video of the same size. [09:02:45 CET] <Hexmind> Images name are 00000001.raw and so on. [09:15:35 CET] <furq> Hexmind: -f image2 -framerate 60 -s 1280x720 -pix_fmt rgb24 -c:v rawvideo -i %08d.raw -c:v whatever_output_codec out.avi [09:16:58 CET] <furq> the second -c:v should be copy if you don't want to encode [09:18:29 CET] <Hexmind> furq, Thanks a lot! I really appreciate. [10:10:17 CET] <termos> I keep getting these errors: "Buffer queue overflow, dropping." when transcoding. It causes my video/audio to get our of sync, is there a way to avoid this? [10:12:33 CET] <DHE> you're overloading something. you need a bigger buffer or turn down the CPU requirements [10:12:49 CET] <DHE> I assume this is some kind of live source, maybe a video capture card [12:08:19 CET] <termos> yes, it's a live source from rtmp [12:13:49 CET] <dmp> Hello. I am trying to build ffmpeg 3.0 for Android in Windows. I have followed the instructions at http://www.roman10.net/how-to-build-ffmpeg-with-ndk-r9/ whilst following the adaptations for Windows at http://stackoverflow.com/questions/23683518/how-to-compile-ffmpeg-2-2-2-on-…. When I run the build_android.sh [12:13:49 CET] <dmp> script, however, I get the following error [12:14:07 CET] <dmp> libavfor: No such file or directory [12:14:07 CET] <dmp> make: *** [libavformat/libavformat.a] Error 1 [12:14:21 CET] <dmp> Does anyone know how to fix this? [13:04:59 CET] <yuriks> Hey. I'm trying to do opus streaming to Firefox inside a webm [13:05:28 CET] <yuriks> encoding to a file with ffmpeg and then playing it in firefox seems to work ok but I'm unable to seek [13:05:58 CET] <yuriks> apparently this is a firefox problem: https://bugzilla.mozilla.org/show_bug.cgi?id=657791 adding the -dash 1 option (which I found online but was unable to find documented anywhere) seem to fix it [13:06:22 CET] <yuriks> however, if I try to output to stdout instead (even if I just pipe to a local file), then seeking stops working again [13:06:27 CET] <yuriks> is this an inherent limitation? [13:07:05 CET] <yuriks> this is my ffmpeg commandline: ffmpeg -i input.flac -map 0:0 -c:a libopus -b:a 192k -f webm -dash 1 - > test.webm [13:11:40 CET] <relaxed> yuriks: ffmpeg -h muxer=webm [13:12:19 CET] <yuriks> ah, that's helpful, thanks. I was looking in the website [13:14:17 CET] <yuriks> only other interesting looking option is -live, but that doesn't do anything either [13:22:49 CET] <LigH> Hi. [13:23:37 CET] <LigH> Does ffmpeg support 2-pass normalization in audio filters (scanning for max. volume in a 1st pass, applying the calculated gain in a 2nd)? ... I believe to remember that ffmpeg usually only works like a 1-pass filter. [13:24:25 CET] <LigH> http://ffmpeg.org/ffmpeg-filters.html#dynaudnorm sounds like AGC, that's not desired. [13:29:26 CET] <J_Darnley> are you looking for volume and volumedetect? [13:31:56 CET] <LigH> A kind of combination: "volumedetect" in a 1st pass to calculate the gain required in a 2nd pass to bring the volume to "normalization" in a 2nd pass. [13:32:30 CET] <LigH> Increasing the volume just even so much that it doesn't clip. [13:33:02 CET] <LigH> But not with a small look-ahead window, instead looking ahead the whole playing time. [13:51:37 CET] <lroe> Can someone help me figure out why I don't have an m3u8 file in /tmp/hls? http://paste.debian.net/hidden/344199a4/ [13:51:53 CET] <lroe> I'm using the nginx rtmp module [13:57:36 CET] <kepstin> LigH: there's a variety of 2-pass filters already in ffmpeg, but I don't think there's a normalization one like you are looking for [13:59:13 CET] <LigH> OK, thank you; then it may be possible to script that using SoX or BeSweet. [14:09:04 CET] <J_Darnley> Huh? Volume and volumedetect are exactly what you want? Volume detect spits out the maximum sample volume. Volume will apply the gain. [14:11:32 CET] <kepstin> I prefer using the ebur128 filter then the volume filter, peak normalization really isn't very useful (particularly with lossy audio codecs where it's basically meaningless) [14:12:10 CET] <LigH> J_Darnley: And how do you combien them in just one call? [14:12:13 CET] <kepstin> but none of the volume filters have a thing where they write to then read from a state file, you actually have to read the output then manually place it into a different filter [14:12:17 CET] <J_Darnley> You don't [14:12:24 CET] <J_Darnley> No ffmpeg filter works that way [14:13:10 CET] <LigH> The overall task is: Convert an input format to an output format and normalize the audio during the conversion. [14:13:33 CET] <kepstin> the only ffmpeg filter that uses a state file for multipass is one of the detelecine ones, iirc, and it needs multiple runs (with a parameter change between runs to set the pass no). And if you're doing multi-pass video encodes, that's a total of 3 passes needed... [14:14:01 CET] <LigH> If ffmpeg can't do multi-pass conversions, then one may have to use a different tool. [14:14:39 CET] <kepstin> LigH: ffmpeg can, you just have to run it multiple times (once for each pass) [14:14:42 CET] <J_Darnley> Is it supposed to buffer uncompressed video to memory or disk? [14:16:10 CET] <Rajko> no it just decodes each pass [14:16:11 CET] <J_Darnley> no trolling: this is something ffmpeg does lack [14:16:52 CET] <LigH> The reason is probably that ffmpeg was designed to work as filter in a pipe; multi-pass filters would not work in a pipe, though, only on disk files. [14:17:20 CET] <kepstin> all the tools that have a "one step" multi-pass mode just run the encode from scratch multiple times from the original disc file [14:17:35 CET] <kepstin> if you want to do that with ffmpeg, write a shell script with a loop :/ [14:18:08 CET] <kepstin> ("if you want to do that with the ffmpeg cli tool"...) [14:19:10 CET] <LigH> Alright, thank you. [14:19:12 CET] <LigH> Bye [14:26:40 CET] <Rajko> can .mp4 be used in a way for streaming [14:42:05 CET] <BtbN> Rajko, no. [14:42:27 CET] <Rajko> why not [14:42:37 CET] <BtbN> because it's not designed to be a streamable format. [14:43:04 CET] <BtbN> If you have a finalized file, and move the moov-atom to the front, it can be played from a webserver while still downloading it, but that's all the streamability you get. [14:43:31 CET] <Rajko> so all the hls things that transmux to mp4 and then feed that to MSE are a lie ? [14:43:42 CET] <BtbN> no. [14:43:46 CET] <BtbN> They don't stream mp4 [14:43:58 CET] <Rajko> MSE only accepts mp4 if you want to use h264 [14:44:05 CET] <BtbN> exactly [14:44:23 CET] <BtbN> Doesn't make it any better [14:44:29 CET] <Rajko> so there is a way to produce a 'streamaable' mp4 at runtime [14:44:32 CET] <BtbN> nope [14:44:33 CET] <Rajko> to feed the decoders [14:44:36 CET] <BtbN> it's just _a lot_ of mp4 files [14:45:02 CET] <BtbN> each indivualy isn't streamable, but if you play them one after the other, you "stream" them. [14:46:42 CET] <Rajko> so i cant just somehow leave the mdat with box size 0 so it 'goes to the end of the file' and then just keep on concatenating packets ? [14:47:45 CET] <BtbN> The moov atom cannot be generated before the file is finalized. [14:48:06 CET] <BtbN> It can only be moved to the front as a post-processing operarion. [14:48:15 CET] <BtbN> And without it, you can't play the file. [14:48:20 CET] <Rajko> whats it contain [14:48:45 CET] <BtbN> codec extradata, information about the file layout and stuff [14:49:58 CET] <Rajko> so i would have to figure out an independent sequence in my stream, then make a small mp4 file containing just that, and feed that to mse [14:50:07 CET] <BtbN> what? [14:50:19 CET] <Rajko> like one keyframe + dependent frames [14:50:49 CET] <BtbN> good luck [14:51:00 CET] <Rajko> no it just means i cant use mse [14:51:04 CET] <BtbN> You could also just use one of the other supported streaming methods, like DASH or HLS since hls.js exists. [14:51:29 CET] <Rajko> no. i cannot take the latency of lagging behind an entire segment [14:51:40 CET] <BtbN> Well, you'll have to. [14:51:49 CET] <BtbN> Also, you lag 3 segments behind, by design. [14:51:55 CET] <Rajko> good to know i can take mse off the table [14:52:06 CET] <BtbN> It's the only way browser support live streaming [14:52:10 CET] <BtbN> So you're stuck with it. [14:52:11 CET] <Rajko> not true [14:52:18 CET] <BtbN> Well, Flash not included... [14:52:37 CET] <Rajko> https://developer.chrome.com/native-client [14:52:49 CET] <BtbN> I said Browsers, not Google-OS. [14:52:58 CET] <Rajko> runs in opera too [14:53:05 CET] <BtbN> Because it is Chrome. [14:53:09 CET] <Rajko> thats fine [14:53:14 CET] <Rajko> most people have it [14:53:35 CET] <ultrav1olet> Does anyone know how to add CRC to matroska/mkv? [14:54:27 CET] <ultrav1olet> I couldn't find anything on the internet aside from checksumming every frame and exporting that info as a text file [14:56:09 CET] <ultrav1olet> Even MP3's have a built-in checksumming [14:57:21 CET] <ultrav1olet> According to https://www.matroska.org/technical/specs/index.html there's some CRC-32 checksumming built in but I don't have any clue as to what it really checksums [15:04:44 CET] <J_Darnley> Could it be that ffmpeg doesn't add it? [15:05:03 CET] <J_Darnley> What about mkvmerge or another tool from movtoolnix? [15:05:44 CET] <ultrav1olet> J_Darnley: I cannot find anything definite [15:06:14 CET] <J_Darnley> (of course I mean mkvtoolnix) [15:31:33 CET] <ultrav1olet> https://trac.ffmpeg.org/ticket/4347 [15:31:44 CET] <ultrav1olet> a feature request no one is working on [17:37:15 CET] <Hfuy> Hello. [17:38:13 CET] <Hfuy> If I'm h.264 compressing something with (for instance) a sky, and it's macroblocking, what could I do to improve things without throwing more bitrate at the whole thing? [17:38:29 CET] <Hfuy> I essentially want the codec to use more bits to encode the sky, taking them from other parts of the frame. [17:40:13 CET] <kepstin> Hfuy: you're already using x264 encoder with a non-fast preset? [17:40:26 CET] <Hfuy> Actually this is more a general technical question. [17:40:34 CET] <Hfuy> The encoder is in a camera. The decoder is ffmpeg. [17:40:52 CET] <Hfuy> I'm not sure how h.264 distributs quantisation tables across the image. I guess I want less quantisation in currently-more-quantised areas. [17:41:25 CET] <J_Darnley> if the enocder is in a camera do you have any control over its settings? [17:41:41 CET] <Hfuy> It's a camera for which the manufacturer is about to release a firmware update. [17:41:47 CET] <Hfuy> So yes, in that sense, I sort of do. [17:41:47 CET] <kepstin> Hfuy: the h264 format supports the encoder deciding arbitrary qp levels per macroblock [17:42:14 CET] <kepstin> Hfuy: in x264, they use advanced psychological optimizations to determine bit allocation within a frame. [17:42:20 CET] <J_Darnley> in general I would say "spend more time encoding" [17:42:39 CET] <Hfuy> Let me see if I can find a before-and-after image. [17:43:02 CET] <J_Darnley> but it sounds like you have no control over the encoder [17:43:05 CET] <kepstin> Hfuy: if you can tell your camera manufacturer "please encode using x264", then you're done ;) [17:43:16 CET] <Hfuy> Ha. [17:43:41 CET] <Hfuy> I can't say who the manufacturer is, but I've been provided with a before-and-after [17:43:54 CET] <Hfuy> I'm trying to figure out what they might have done. [17:44:11 CET] <Hfuy> http://imagebin.ca/v/2Y5ac6TV4Cso [17:44:20 CET] <kepstin> but in general, cameras use hardware encoder blocks with poor ability to make decisions on bitrate allocation within frames, so the solution is "bump up the bitrate high enough, then re-encode in software afterrwards" [17:44:54 CET] <Hfuy> This is a rather low bitrate codec, to be brutally honest. [17:45:19 CET] <kepstin> Hfuy: huh, looks like they have at least some tweaking ability. probably added grain preservation as a priority (preserving high-frequency detail) rather than smoothing. [17:45:36 CET] <Hfuy> I was trying to figure out how to describe what they've done. [17:45:42 CET] <Hfuy> I'm not sure if it's necessarily obvious from that. [17:45:58 CET] <Hfuy> I assume it will mean less bitrate elsewhere in the frame. [17:46:43 CET] <kepstin> yeah, but it's always a tradeoff :) [17:47:09 CET] <Hfuy> specs, by the way, are 100mbps, 3840x2160p24 [17:47:39 CET] <kepstin> the 'before' image imo looks like what you get with an encoder optimized for psnr rather than human vision - the loss of detail in that one area is offset by improved detail in other spots on the image. [17:48:08 CET] <Hfuy> Yes, psnr optimisation resulting in greater noise in low con areas. [17:48:44 CET] <kepstin> but the human eye really picks that out, since it's dynamically more sensitive to detail in low-contrast low-motion spots :/ [17:49:09 CET] <Hfuy> It only really shows up when you use a lot of gain, so the image gets noisier [17:49:43 CET] <kepstin> (x264 makes use of the fact that it doesn't even have to be the "right" detail - just any noise would look better there than smooth - which lowers the "objective" psnr scores more) [17:50:05 CET] <Hfuy> How does it do that - just use a less harsh quantisation table on those blocks, or in that area of the image? [17:51:12 CET] <kepstin> I dunno, you'd have to read the code :) [17:52:12 CET] <kepstin> I suspect it does adjust the qp up in regions of low motion low contrast if it can without hurting the rest of the frame too much, but there's probably more to it than that. [17:52:49 CET] <Hfuy> sorry, qp? [17:53:55 CET] <kepstin> er, quantization parameters [17:54:08 CET] <Hfuy> OK, I assumed something like that. [17:54:51 CET] <Hfuy> But that isn't decided on a block-by-block basis, is it? [17:55:18 CET] <kepstin> in h264 i'm pretty sure you can use different quantization levels for each block [17:55:24 CET] <Hfuy> I see. [17:55:50 CET] <kepstin> the question is whether the overhead of coding that is worth the visual quality increase :) [17:55:54 CET] <kepstin> everything's a tradeoff. [17:56:28 CET] <Hfuy> That's basically the thrust of the article I'm writing. [17:56:30 CET] <Hfuy> These things are choices. [17:56:54 CET] <Hfuy> 100mbps is sweet spiff all for an in-camera origination codec. [18:16:31 CET] <Rajko> hi, https://chrome.google.com/webstore/detail/geforce-experience-stream/gjljkni… uses ffmpeg internally, how do i get their modified source ? [18:16:57 CET] <Hfuy> Perhaps they didn't modify it. [18:17:25 CET] <Rajko> its in there as a .so [18:17:37 CET] <Rajko> if it was statically linked they would have to give out their entire source out, right ? [18:18:00 CET] <Hfuy> I suspect they're not going to do that. [18:18:21 CET] <Hfuy> In any case, even if they were breaking the rules, the likelihood that anyone's ever actually going to take it to court is microscopic, so I wouldn't get too excited. [18:18:35 CET] <J_Darnley> Like with all distribution: contact them and request source [18:18:50 CET] <J_Darnley> They cannot say "go to ffmpeg.org" [18:19:54 CET] <Hfuy> well, they can, and you probably should. [18:19:56 CET] <Rajko> i cant even find out where their GPL contact form is [18:20:12 CET] <Rajko> usually companies have a list of all the gpl stuff they use and links [18:20:23 CET] <J_Darnley> well, they can tell you that but that isn't compliant with the license [18:21:14 CET] <Rajko> /apurva1/amayekar_workspace1/sw/grid/oss/GoogleChrome/naclports_43/src/out/build/ffmpeg/ffmpeg-2.1.3/libavcodec/ [18:21:26 CET] <Rajko> thats an old ffmpeg [18:22:32 CET] <Rajko> im looking for the configure string so i can use exactly what they did as i know that works [18:23:01 CET] <J_Darnley> then try running a binary through strings and grep for something [18:23:22 CET] <Rajko> usually i can find -with etc [18:23:44 CET] <J_Darnley> ffmpeg's configure doesn't use any "with"s [18:23:58 CET] <Rajko> youre right, its -enable [18:24:02 CET] <Rajko> huh its just the stock one [18:24:05 CET] <Rajko> they didnt even strip it down [19:22:01 CET] <Rajko> they only use it for audio it seems too :( [19:28:40 CET] <bofh> Hi there! Where can I get some FFPMEG (static?) builds with all HW accelerations enabled at compile time? [19:29:29 CET] <JEEB> that doesn't make any sense [19:29:42 CET] <JEEB> 1) hwaccels generally require linking against system driver libs [19:29:49 CET] <JEEB> 2) hwaccels are OS-specific [19:29:59 CET] <JEEB> so by definition you can't get all of them at once [19:30:05 CET] <bofh> ok, thanks, I will learn more of that [19:30:08 CET] <Rajko> he probs means for his own platform [19:30:23 CET] <bofh> by a chance - anybody here uses ffmpeg with GPU-enabled AWS instances? [19:30:51 CET] <JEEB> I stick my money into something more price-performant :) [19:31:26 CET] <JEEB> hwaccels do have their limited use cases, but I'm definitely not one of those who'd get much out of them [19:32:03 CET] <kepstin> bofh: last time someone came in talking about that, they were disappointed with the performance. GPU encoding mostly makes sense if you can't use CPU, for example if you're doing something else (running a game, render, whatever) [19:32:05 CET] <bofh> well, I just need to decide whether our company really need to use those GPU-enabled instances [19:32:22 CET] <Rajko> also, the decoder/encoder on a gpu is a separate piece of silicon [19:32:28 CET] <Rajko> not used for anything else or share-able [19:32:47 CET] <JEEB> yeah, so you basically have a fixed maximum of streams that you can transcode with a certain ASIC [19:32:50 CET] <bofh> kepstin: my use case - we have a stream of PNG images, and we're using FFMPEG to create an MP4 file out of them [19:33:07 CET] <JEEB> and the requirement for the GPU is exactly where? [19:33:10 CET] <kepstin> the nvidia one has pretty low-overhead context switching, so you can do a fair number of streams as long as you don't go over the max fps [19:33:13 CET] <bofh> I'm not sure if we could get any benefit of GPU-enabled instances [19:33:56 CET] <bofh> so basicly I planned to get couple of instances of EC2, with and w/o GPU, and run some tests [19:34:10 CET] <Rajko> does anything even support nvenc ? [19:34:12 CET] <Rajko> like, libraries [19:34:15 CET] <bofh> but i'm not sure how to actually run ffmpeg for getting some stats [19:34:19 CET] <Rajko> you pretty much just have to use it directly [19:34:28 CET] <kepstin> Rajko: ffmpeg is a library that supports nvenc :) [19:34:29 CET] <Rajko> VDPAU decoding sure, but does that work when headless ? [19:35:09 CET] <JEEB> I think the hwaccel things in ffmpeg (tool) work as long as you have access to the GPU [19:35:23 CET] <JEEB> they don't require a screen per se [19:35:35 CET] <kepstin> nvenc explicitly does not require a display running, vdpau I believe does. [19:35:40 CET] <Rajko> i know nvenc is accessed via the cuda dlls so its there regardless [19:35:43 CET] <bofh> JEEB: so it is enough to run ffmpeg - and it will decide whether it should use GPU ? [19:35:54 CET] <JEEB> bofh: seriously just don't even think about it [19:35:59 CET] <bofh> ) [19:36:02 CET] <kepstin> bofh: you need a build with nvenc enabled (which you'll probably have to do yourself). [19:36:08 CET] <kepstin> and yeah, probably not worth it [19:36:17 CET] <Rajko> (the quality per bitrate you get from nvenc is also way below what you get with x264) [19:36:19 CET] <bofh> looks like I'm looking for something esoteric, as usual [19:36:28 CET] <JEEB> just use one of the faster libx264 presets [19:36:34 CET] <Rajko> exactly [19:36:42 CET] <Rajko> (or an insane bitrate with nvenc so its basically losless) [19:36:43 CET] <JEEB> and you will be getting nice speeds, or you will have your bottleneck *before* the encoder [19:37:02 CET] <JEEB> in which case it doesn't matter if you're using nvenc or libx264 with the CPU [19:37:11 CET] <kepstin> reading png frames from disk and decoding it might actually end up being your bottleneck [19:37:11 CET] <bofh> I c, so for the moment I could just skip the GPU part [19:37:28 CET] <Rajko> yeah png is huge [19:37:30 CET] <JEEB> kepstin: also RGB->YCbCr conversion with swscale/zscale [19:37:37 CET] <bofh> kepstin: images are generated by the app, true, and this is most likely to be a bottleneck [19:37:50 CET] <JEEB> so you have decoding=>colorspace conversion=>encoding [19:37:57 CET] <Rajko> JEEB, my swscale takes about as much time as avcodec_decode on h264 [19:38:04 CET] <Rajko> and thats not even scaling, just converting to rgba [19:38:08 CET] <JEEB> yup [19:38:09 CET] <kepstin> if images are being generated by an app and piped, you probably want to skip the png decode/encode [19:40:41 CET] <kepstin> I had a fun thing recently where I had an app writing raw video to a pipe and it was slower than I wanted; turned out that I was doing blocking io to the pipe, and the pipe buffer was smaller than a full frame, so it blocked my app until ffmpeg finished reading the next frame. [19:40:55 CET] <kepstin> Had to add a thread to handle writing the output to the pipe. [21:20:24 CET] <Mindiell> hi there, I need to convert a .mp4 into a .avi, using the mpeg4 video encoder. My problem is the quality is very bad and when I convert I see the kb/s from 889 to 200. Is there any option to fix the kb/s rate ? [21:20:44 CET] <Mindiell> (from some hc264 video codec though) [21:21:31 CET] <J_Darnley> set the bitrate you want or use constant quantiser encoding? [21:21:57 CET] <J_Darnley> -b:v 500k or -v:q 3 for example [21:22:09 CET] <Mindiell> thx, I'll try that :o) [21:23:00 CET] <Mindiell> first option, it starts the conversion showing a bitrate at 0kb/s... [21:23:23 CET] <J_Darnley> What about at the end? [21:23:29 CET] <Mindiell> seems I'm not an expert :o) [21:23:40 CET] <Mindiell> still converting, I'll see that in a minute [21:24:59 CET] <Mindiell> but it takes time, and size, which sounds good :o) [21:26:51 CET] <Mindiell> nop, quality is bad, I try the second option ;o) [21:27:56 CET] <furq> use libxvid for mpeg4 if you have it enabled [21:28:10 CET] <Mindiell> hmm, the second option make ffmpeg quiet, strange :o) [21:28:25 CET] <furq> it should be -q:v [21:28:26 CET] <Mindiell> furq: I'll see that, how can I verify if libxvid is enabled ? [21:28:35 CET] <furq> ffmpeg -version [21:28:40 CET] <furq> it'll say --enable-libxvid if it's enabled [21:29:31 CET] <Mindiell> yup, it's enabled :o) [21:29:47 CET] <furq> use -c:v libxvid then [21:30:06 CET] <furq> all the other options are the same iirc [21:30:08 CET] <J_Darnley> oops, yes -q:v [21:32:28 CET] <Mindiell> arf [21:32:31 CET] <Mindiell> ok :o) [21:33:03 CET] <Mindiell> and -q:0 (for stream 0) or -q:v ? [21:33:34 CET] <J_Darnley> depends whether your video is stream 0 [21:33:42 CET] <Mindiell> yes it is [21:34:00 CET] <Mindiell> v takes the video stream whichever is the number ? [21:34:00 CET] <J_Darnley> then I think they're the same [21:34:05 CET] <Mindiell> ok, thx [21:34:08 CET] <J_Darnley> but ffmpeg can put the audio first [21:34:12 CET] <furq> use q:v unless you have multiple video streams which need different options [21:34:20 CET] <furq> which seems unlikely in an avi [21:34:31 CET] <Mindiell> thx [21:35:05 CET] <Mindiell> hmm, file is bigger, maybe this will work [21:36:15 CET] <Mindiell> I'll have to read/understand all the doc :o) [21:38:46 CET] <Mindiell> ok, quality is here, now I'll try to see if my media-box can read it, thx every1 ! [22:15:31 CET] <techtopia> is there anyway to specify whats displayed in stdout when ffmpeg is doing a job? [22:15:48 CET] <furq> techtopia: -v and -stats [22:15:54 CET] <techtopia> like can i get it not to display the bitrate and speed [22:15:59 CET] <techtopia> ahh cool [22:16:21 CET] <furq> -v error will suppress the stats output iirc [22:16:29 CET] <furq> -v quiet definitely will but that will also suppress errors [22:17:15 CET] <furq> actually you can just use -nostats [22:17:48 CET] <techtopia> thanks man, will have a play with -v -stats and -nostats [22:21:38 CET] <lroe> Can someone help me figure out why I don't have an m3u8 file in /tmp/hls? http://paste.debian.net/hidden/344199a4/ [22:25:45 CET] <techtopia> not sure what that is, bash maybe [22:26:03 CET] <techtopia> but does # comment out the line [22:26:11 CET] <techtopia> so "# hls_path /tmp/hls;" [22:26:27 CET] <techtopia> would mean the path never get's set ? [22:27:11 CET] <furq> he has hls_path set in the other application block [22:27:56 CET] <furq> lroe: http://sprunge.us/WRER [22:28:14 CET] <furq> that should (hopefully) work [22:30:26 CET] <furq> check your nginx error log if not [22:30:48 CET] <furq> and maybe append 2>>/path/to/ffmpeg-error.log to the exec_static line [22:31:00 CET] <lroe> nothing in the nginx error log [22:31:02 CET] <furq> i would hope that ends up in the nginx error log though [22:39:27 CET] <lroe> ok [22:41:12 CET] <lroe> I added 2>>/tmp/ffmpeg.err to the exec line and now that file has: http://paste.debian.net/hidden/3e399ca5/ [22:47:10 CET] <lroe> I can connect via VLC or mplayer to the RTMP stream which means I believe the ffmpeg portion is working [22:47:29 CET] <lroe> but sor some reason the 'hls' portion isn't generating the correct file [22:47:44 CET] <lroe> for* [23:13:12 CET] <DANtheBEASTman> i wrote this script that records x11 regions, but the quality is terribad and I'm not quite sure where I got the ffmpeg settings from or how to improve them https://gist.github.com/DanielFGray/334168827097f2d11729#file-record-sh-L94… [23:21:50 CET] <ac_slater> DANtheBEASTman: https://trac.ffmpeg.org/wiki/Encode/H.264 [23:22:14 CET] <ac_slater> I would avoid vpx and use h264 or h265 instead [23:22:59 CET] <TD-Linux> unless you value your freedom [23:23:00 CET] Action: TD-Linux runs [23:23:07 CET] <ac_slater> and having -crf and -b:v is kinda odd. I would just use one or the other (or manual quantization) [23:23:22 CET] <ac_slater> TD-Linux: good point, use vpx if you can. [23:23:25 CET] <TD-Linux> if you are using vp8 you want both. [23:24:03 CET] <ac_slater> TD-Linux: I thought h265 was a bit more libre. I can't remember. [23:24:04 CET] <TD-Linux> but you shouldn't have both -b and -b:v, and I don't think -preset does anything with libvpx [23:24:41 CET] <TD-Linux> DANtheBEASTman, does cranking up the bitrate with -b:v help? [23:32:10 CET] <max246> hello [23:32:43 CET] <max246> someone knows why ffmpeg sometimes it records at 2-4 FPS and then restarting the software 2-3 times it goes back to 30? [23:32:58 CET] <max246> is this a common issue? [23:33:10 CET] <ac_slater> max246: that is not a general issue, it's most definitely your parameters or build [23:33:31 CET] <max246> I am using the latest version from ffmpeg website [23:33:35 CET] <ac_slater> encoding? decoding? muxing? demuxing? [23:33:39 CET] <max246> and I am using a blackmagic card [23:33:49 CET] Action: ac_slater googles [23:34:15 CET] <max246> I am capturing and encoding in mkv [23:34:18 CET] <max246> at 60 fps [23:34:46 CET] <max246> this is my line: ffmpeg -y -f dshow -video_size 1920x1080 -pixel_format uyvy422 -rtbufsize 2100M -framerate 59.94 -i video="Decklink Video Capture" -threads 10 -codec:v libx264 -preset ultrafast -an -crf 0 rawvideo.mkv [23:35:20 CET] <ac_slater> do you have a 10 core CPU? Just curious [23:35:21 CET] <max246> I just dont get it why I need to restart 2-3 times then I get 60 FPS fixed [23:35:26 CET] Action: jkqxz wonders whether the one component which isn't in common with everyone else who happily uses ffmpeg might be the blame... [23:35:33 CET] <max246> em.. no that my mistake [23:35:39 CET] <max246> will need to change it back to 4 [23:35:46 CET] <max246> but even to 4 it happened [23:35:52 CET] <ac_slater> mo'threads mo'problems [23:35:57 CET] <ac_slater> I see. [23:36:05 CET] <ac_slater> well, I first blame windows :p [23:36:08 CET] <max246> it is strange, because it works fine when it runs [23:36:15 CET] <max246> I even had the same issue on linux :( [23:36:18 CET] <max246> recording webcam [23:36:20 CET] <ac_slater> :( [23:36:25 CET] <max246> so I thought this is was a common issue of ffmpeg [23:36:32 CET] <DANtheBEASTman> TD-Linux: if it's at 1200k what would be a better choice? doubling it? [23:36:56 CET] <TD-Linux> DANtheBEASTman, yeah, if you're recording to a file you probably want to set it high and then use crf as the primary limit on quality [23:36:58 CET] <ac_slater> DANtheBEASTman: it's directly correlated to quality (most times) [23:37:04 CET] <max246> so what I found so far is to parse the FPS info with python and kill it if it doesnt record at 60 FPS [23:37:21 CET] <TD-Linux> libvpx-vp8 will limit to the lower quality of the two limits. [23:37:23 CET] <max246> but I wished to know if I did some wrong :( [23:37:38 CET] <ac_slater> max246: that's lame :(. I'm leaning toward the device causing an issue [23:37:45 CET] <ac_slater> not the software. [23:37:49 CET] <max246> I see [23:38:02 CET] <furq> max246: don't set -threads manually with x264 unless you specifically want to keep cores free [23:38:26 CET] <max246> ok so I will remove threads [23:38:48 CET] <max246> what about the lower FPS, is something hardware , furq? [23:39:04 CET] <ac_slater> max246: why not a hard 60 opposed to 59.94 [23:39:26 CET] <max246> because the capture card has different settings, and the Lumix camera that I am using, it outputs 59.94 [23:39:31 CET] <ac_slater> do you need that drop frame [23:39:33 CET] <ac_slater> ah I see [23:39:38 CET] <max246> it was a pain in the ass to get the setting right [23:39:38 CET] <ac_slater> leave it them [23:39:39 CET] <ac_slater> then * [23:40:02 CET] <max246> if you set to 60, you get a black video, but if you set 59.94, you get the right video :) [23:40:17 CET] <ac_slater> haha, not the weirdest thing I've heard today [23:40:24 CET] <ac_slater> but, that's the name of the game [23:40:50 CET] <max246> yeah , I spent like 2 days googling and testing ... I wished people would make more docs for hardware :) [23:41:21 CET] <max246> ok I need to give up and just keep using my script [23:41:35 CET] <ac_slater> max246: good luck [23:41:46 CET] <jkqxz> 59.94Hz (60000/1001) is normal for people in NTSC-land. Strange that it should demand that, but the number itself isn't surprising. [23:41:56 CET] <max246> what about to make a slow motion ? what is the best practices ? [23:42:15 CET] <pzich> you want to slow down the playback speed? [23:42:16 CET] <max246> should I use "setpts=2.0*PTS" ? [23:42:18 CET] <furq> you could maybe try increasing rtbufsize [23:43:07 CET] <max246> jkqxz: well might be the Lumix outputing as NTSC [23:43:26 CET] <max246> furq: I think this is the make it can handle, after that ffmpeg complains [23:43:50 CET] <max246> *this is the max it can handle [23:44:15 CET] <max246> pzich: I would like to have a slow motion effect from 60 to 30 fps [23:44:47 CET] <max246> should I follow this https://trac.ffmpeg.org/wiki/How%20to%20speed%20up%20/%20slow%20down%20a%20… or try to re-encode the video by settings the framerate [23:45:16 CET] <yann|work> I can't find an example of h264 vdpau decoding/rendering through libavcodec, Can I find that somewhere ? Are we just supposed to set codec_context->hwaccel before calling avcodec_open2 ? [00:00:00 CET] --- Thu Feb 25 2016

1 0