Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

November 2016

1 participants
60 discussions

ffmpeg-devel.log.20161129
by burek 30 Nov '16

30 Nov '16

[00:03:56 CET] <cone-287> ffmpeg 03Michael Niedermayer 07master:c3f781c52ad7: tests/Makefile: Fix ffservertest dependencies [00:03:57 CET] <cone-287> ffmpeg 03Michael Niedermayer 07master:1e7f9b0ec602: tests: Fix running ffserver under qemu [00:11:53 CET] <lotharkript> i'm looking on how to fix the examples/remuxing.c to support y4m (or any container supporting rawvideo) to y4m. And following your idea, i will need to add code in the loop to convert the AVpacket from the demuxer to AVFrame, then either call wrapped_avframe_encode to wrap it to an AVPacket. The loop will become ugly, no? [00:12:59 CET] <nevcairiel> like I said earlier, examples don't have to cover every case [00:13:16 CET] <nevcairiel> its meant to be a simple illustration of API usage [00:13:27 CET] <lotharkript> but the example are for people who want to know about the API, no? [00:13:32 CET] <nevcairiel> a full blown app would probably factor a bunch of things into various components [10:14:18 CET] <superware> hi, is cehoyos around? [10:16:59 CET] <ubitux> rarely [10:17:02 CET] <nevcairiel> he doesnt usually hang around here, no [10:43:21 CET] <superware> I see [10:48:35 CET] <superware> I'm trying to resolve https://trac.ffmpeg.org/ticket/5615, problem is I don't have sufficient knowledge to debug this myself. [11:03:20 CET] <cone-542> ffmpeg 03Daniel Verkamp 07master:e856ac237328: avcodec/msrledec: implement vertical offset in 4-bit RLE [11:23:56 CET] <cone-542> ffmpeg 03Paul B Mahol 07master:d56c7830c097: avcodec/raw: add gray10 support in nut [11:36:50 CET] <cone-542> ffmpeg 03Paul B Mahol 07master:57ef0f0f17a0: avfilter/vf_waveform: add gray10 and gray12 support [12:58:52 CET] <wm4> jkqxz: wait what, vaapi 10 bit support confirmed? [13:00:07 CET] <JEEB> najs [13:06:34 CET] <jkqxz> wm4: ? It's been there for a while. [13:13:10 CET] <wm4> I thought it was unconfirmed whether it works [13:17:26 CET] <jkqxz> Um, why? I'm sure all the Intel people would have enjoyed making lots of driver changes which didn't work at all. [13:23:56 CET] <jkqxz> I only got a Kaby Lake last week. I've been looking at encode first (VP9 is on libav ML), but I'll look at decode after that (if someone else doesn't do it for me first, as they kindly have here). [14:04:01 CET] <BBB> J_Darnley: I love the new asm& one small thing (this isnt critical, just a personal preference), for the sse2/avx new simd you wrote, do you think it makes sense to start using named registers? [14:04:11 CET] <BBB> J_Darnley: it tends to make the asm quite a bit more readable imo [14:09:24 CET] <J_Darnley> That is usually my preference too [14:10:32 CET] <J_Darnley> However, since so much of this is done through macros that don't use named regs I see less use for it [14:13:53 CET] <ElAngelo> trying to create a bug, instructions tell me to upload the sample to upload.ffmpeg.org [14:13:59 CET] <ElAngelo> but i get a connection timeout? [14:17:50 CET] <kierank> BBB: do you know of anything that needs conversion to avx2 in h264? [14:17:57 CET] <kierank> michaelni: ^ maybe a q for you as well [14:18:39 CET] <BBB> maybe the MC? [14:18:53 CET] <BBB> loopfilter might also be a good candidate [14:18:56 CET] <BBB> let me check [14:19:06 CET] <michaelni> everything thats not avx2 and would be faster with avx2 [14:19:33 CET] <BBB> ff_h264_idct8_add4 also? [14:19:37 CET] <jamrial> not everything. i've written a couple functions that did not see any speed up because of cross lane crap [14:19:48 CET] <BBB> michaelni: well, lots of it doesnt help because you need more data throughput [14:19:51 CET] <kierank> various benchmarks https://usercontent.irccloud-cdn.com/file/VVxNyafi/h264_cavlc_sd.png https://usercontent.irccloud-cdn.com/file/g3qsZbqT/mpeg2hd.png https://usercontent.irccloud-cdn.com/file/BuzLCGg3/mpeg2sd.png https://usercontent.irccloud-cdn.com/file/8LfJgjjE/h264_cabac_422_10bit.png [14:19:51 CET] <kierank> https://usercontent.irccloud-cdn.com/file/AuiHIqtO/h264_cabac_golf_sat_420.… [14:20:06 CET] <BBB> I think the idct block functions can help (idct8_add4, idct_add16) [14:20:12 CET] <BBB> MC should also help [14:20:15 CET] <BBB> I wouldnt bother with intra [14:20:34 CET] <BBB> I also wouldnt bother with chroma initially TBH, but thats just me [14:21:11 CET] <kierank> (whoops put mpeg2 in there as well) [14:21:13 CET] <BBB> and idct_addN, loopfilter, weight/biweight/MC stuff [14:21:17 CET] <BBB> thats what I would go for [14:21:39 CET] <BBB> I dont know how much gain youll get in general [14:21:53 CET] <BBB> why dont you ignore h264 and optimize vp9 loopfilter instead? thats much more fun!!! [14:22:02 CET] <BBB> </commercial break> [14:22:23 CET] <nevcairiel> but thats your job [14:22:24 CET] <nevcairiel> :) [14:22:31 CET] <kierank> if there was an interlaced profile of vp9, sure [14:22:32 CET] <kierank> </troll> [14:22:32 CET] <BBB> I s'pose [14:22:40 CET] <BBB> add8x4 is the idct block function [14:22:42 CET] <BBB> that one can be made avx2 [14:22:46 CET] <BBB> but its only 3.2%... [14:22:58 CET] <nevcairiel> you should totally invent a much faster way to decode cabac [14:23:01 CET] <BBB> yeah [14:23:07 CET] <BBB> cabac is the killer& 60%& wtf [14:23:17 CET] <BBB> actually is that cavlc? [14:23:21 CET] <kierank> yeah [14:23:25 CET] <BBB> WHAT ARE YOU DOING!!!!! [14:23:31 CET] <BBB> YOU TERRIBLE PERSON!!!!! [14:23:41 CET] <kierank> it's some other encoder [14:24:02 CET] <kierank> we get streams from it [14:24:37 CET] Action: ElAngelo just reported 5982 [14:25:12 CET] <BBB> yeah so theres totally potential for avx2 [14:25:28 CET] <BBB> but you will get maybe 10% overall speedup if you do everything you can? [14:25:32 CET] <BBB> its not very much I admit :( [14:25:45 CET] <kierank> still worth it [14:26:09 CET] <BBB> J_Darnley: I see your point btw, I guess its fine& [14:26:14 CET] <kierank> and there's also 4:2:2 10-bit which has some opts needed [14:26:29 CET] <BBB> I cant believe you guys wrote mmxext simd [14:26:47 CET] <J_Darnley> BBB: If I need to rework the patch I will consider adding it with a bit more weight. [14:27:30 CET] <BBB> h264 was written before named registers were a thing& its basically old cruft& it shows h264s age& its ok [14:27:33 CET] <J_Darnley> Can I help it if there's only a 420 mmxext version I can copy? [14:27:43 CET] <BBB> hahaha [14:27:51 CET] <BBB> its fine, its just funny [14:28:04 CET] <BBB> not bad funny, just funny [14:28:30 CET] <J_Darnley> :) [14:31:33 CET] <BBB> so& are we actually voting on ffserver yes/no removal now? [14:31:38 CET] <BBB> or is that off the table again? [14:31:44 CET] <BBB> I dont udnerstand the email thread anymore [14:32:44 CET] <wm4> nicolas thinks he's making a vote to retract the earlier vote [14:33:26 CET] <BBB> right, so is that vote on? [14:33:27 CET] <BBB> or not? [14:34:05 CET] <atomnuker> J_Darnley: chroma_format_idc == 3 maps to 444 so the 422 assembly is used, do the functions work with that? [14:34:25 CET] <J_Darnley> oh, I don't know [14:34:37 CET] <J_Darnley> It does pass fate but maybe fate doesn't have a 44 sample [14:34:41 CET] <J_Darnley> *444 sample [14:36:13 CET] <J_Darnley> I might guess that it doesn't work with 444 because I think I'm mostly just doing twice as many lines in 422 [14:37:32 CET] <BBB> fate should have 1 444 sample [14:37:49 CET] <BBB> oh wait [14:37:54 CET] <BBB> 444 doesnt use chroma functions [14:38:01 CET] <BBB> it just uses the luma function pointers for all planes [14:38:22 CET] <BBB> the chroma functions are only called for 422 and 420 (idct_format == 2 or 1) [14:38:30 CET] <BBB> so its probably fine [14:52:30 CET] <cone-857> ffmpeg 03Paul B Mahol 07master:46752d6b12c8: avfilter/vf_extractplanes: add extract support for 10bit and 12bit formats [14:58:48 CET] <durandal_1707> anybody wants to write some simd for free? [15:00:58 CET] <atomnuker> durandal_1707: what do you need? [16:34:34 CET] <cone-857> ffmpeg 03Paul B Mahol 07master:c9dcd25288e3: avfilter/vf_bitplanenoise: add gray10 and gray12 suppport [16:52:57 CET] <cone-857> ffmpeg 03Paul B Mahol 07master:9e9c2276c308: avfilter/vf_masked*: add gray10 and gray12 support [17:41:39 CET] <BtbN> is there a way to mark intentional fallthrough in a switch case, so coverity doesn't complain? [17:42:06 CET] <nevcairiel> write /* fall through */ on them [17:44:46 CET] <BtbN> https://github.com/BtbN/FFmpeg/commit/00d8515150bf1c1b021f56df1cc4e48c2783b… like this? [17:45:33 CET] <nevcairiel> probably [17:45:40 CET] <nevcairiel> look for such comments, its used elsewhere [17:46:51 CET] <BtbN> yeah, seems about right. [18:59:35 CET] <ElAngelo> where am i supposed to upload a sample video for a bug? [19:03:48 CET] <BtbN> philipl, can I push the late-surface-format patch? [19:04:26 CET] <jamrial> ElAngelo: https://ffmpeg.org/bugreports.html [19:04:46 CET] <jamrial> but if it's small, you can attach it to the ticket instead [19:05:00 CET] <ElAngelo> it's 20MB [19:05:50 CET] <ElAngelo> i've tried the ftp server already [19:05:54 CET] <ElAngelo> it was not responding [19:27:03 CET] <ElAngelo> still not responing :s [19:27:33 CET] <cone-857> ffmpeg 03Michael Niedermayer 07master:744a0b520663: avformat/idroqdec: Check chunk_size for being too large [19:27:34 CET] <cone-857> ffmpeg 03Michael Niedermayer 07master:6216127d0cb9: tests/ffserver-regression.sh: give wget a timeout and prevent retries [19:27:35 CET] <cone-857> ffmpeg 03Michael Niedermayer 07master:dbe18780609a: tests/ffserver.regression.ref: update ffserver checksums [19:27:36 CET] <cone-857> ffmpeg 03Michael Niedermayer 07master:472fee91bcf9: ffserver_config: Setup codecpar in add_codec() [19:27:37 CET] <cone-857> ffmpeg 03Michael Niedermayer 07master:606702ea3483: ffsrever: Make the status page bitexact if any stream is bitexact [19:27:38 CET] <cone-857> ffmpeg 03Michael Niedermayer 07master:bced37c155c4: tests/ffserver-regression: Check the status page too [20:00:47 CET] <jamrial> michaelni: this work you're committing is not an effort aimed at making ffserver standalone. it's aimed at helping the attempts at keeping it in the tree [20:00:53 CET] <jamrial> please, either work in the former, or wait until this vote thing is over [20:02:54 CET] <jamrial> work in the former will be useful regardless of the outcome. work in the latter will be wasted time if July's decision and agreement remains in place [20:04:26 CET] <durandal_1707> shouldn't he work on making it not use internal stuff? [20:04:35 CET] <wm4> and I hoped everyone would just ignore this thread [20:05:11 CET] <michaelni> jamrial, i understand the work that i do may be wasted within ffmpeg but its interresting and fun work that i like doing, and like most i work on what is fun r what someone pays me to do [20:05:27 CET] <jamrial> michaelni: alright [20:06:14 CET] <jamrial> wm4: not acknowledging it will be good for nothing if others do [20:06:42 CET] <wm4> I don't care, fuck it [20:06:47 CET] <durandal_1707> if nobody is working on removing internal stuff I'm for removing ffserver [20:07:02 CET] <jamrial> what we need to do is establish limits about what we can start a vote for. things like a vote to undo another vote shouldn't be allowed [20:07:11 CET] <jamrial> however that is not the case here [20:07:55 CET] <durandal_1707> just put up vote on ffserver immediate removal... [20:08:08 CET] <wm4> time to turn this into a farce [20:09:37 CET] <durandal_1707> michaelni: are you paid to work on ffserver? [20:09:52 CET] <michaelni> durandal_1707, no [20:22:41 CET] <wm4> should I send this lol http://pasted.co/c6d6ceb6 [20:23:29 CET] <nevcairiel> isnt it simpler to just vote no [20:25:30 CET] <j-b> I'm sad to not be allowed to vote :) [20:27:40 CET] <durandal_1707> revoke decision to revoke decision to revoke ... [20:28:05 CET] <BBB> wm4: just vote no [20:28:12 CET] <BBB> wm4: dont make this more difficult than it is [20:28:24 CET] <wm4> but that's exactly what I want to do [20:28:36 CET] <wm4> if nicolas can sabotage and be special, why not me as well? [20:29:22 CET] <BBB> because we want to move on? [20:29:29 CET] <BBB> hes looking for a final yes/no [20:29:34 CET] <BBB> give him the final yes/no [20:29:37 CET] <BBB> and then move on [20:29:57 CET] <durandal_1707> hmm, change voting committee rules so Nicolas is not in? dirty me [20:34:44 CET] <BBB> so meta [20:34:54 CET] <BBB> just vote whatever way you want to and move on [20:35:10 CET] <BBB> you guys are taking all this too personally, which makes it very complicated [23:47:56 CET] <michaelni> fate is yellow, durandal_1707, d56c7830c0973dc4d2a068ba0b427ea6c1760dc2 breaks several tests [23:50:02 CET] <michaelni> example, but it fails acros many platforms: http://fate.ffmpeg.org/report.cgi?time=20161129202409&slot=x86_64-freebsd10… [23:55:07 CET] <durandal_1707> michaelni: one just needs to update hashes [23:56:24 CET] <jamrial> durandal_1707: you also forgot to add gray10 and gray12 to nut.c, i think [23:57:14 CET] <jamrial> mmh, maybe not [23:57:47 CET] <jamrial> no, they are there. you just forgot to update the hashes [00:00:00 CET] --- Wed Nov 30 2016

1 0

ffmpeg.log.20161129
by burek 30 Nov '16

30 Nov '16

[00:00:23 CET] <Guest94097> I am taking in a mpts via udp and trying to select a program and output to a file, but I am getting I/O error, anything wrong with this cli? [00:00:51 CET] <Guest94097> ffmpeg -i udp://244.13.9.13:3100 -map 0:p:450 -c:v copy -c:a copy c:\temp\test.ts [00:03:00 CET] <lvella> JEEB: from the MPEG-2 standard, the elements of a GOP are "pictures", and a "picture" is either a field, in interlaced mode, or a frame, in progressive mode, so that seems very weird that ffmpeg encoder would group the fields [00:21:26 CET] <iive> mpeg2 standard mandates that two complementary fields are always encoded, so you alway have a full frame. [00:29:43 CET] <durandal_1707> Hello71: play with overlap and video size [00:33:08 CET] <DHE> Guest24481: IP addresses starting in 244 are in the reserved block. that's not a multicast address [00:33:18 CET] <DHE> did you mean 224 instead? [00:33:26 CET] <PlanC> does anyone know why the image that's in the meta data/ID3 of a file is removed when it's copied with ffmpeg? [00:33:39 CET] <PlanC> everything else is still there but the album art/image/cover is missing [00:33:56 CET] <PlanC> this guy had the same problem as me: http://superuser.com/questions/758338/keep-album-art-with-ffmpeg-while-cutt… [00:34:15 CET] <PlanC> but he never shared the solution... (https://xkcd.com/979/) [00:34:35 CET] <DHE> there's an xkcd for everything. (I don't even have to click it) [00:35:58 CET] <c_14> PlanC: internal reasons needs a patch [00:36:18 CET] <PlanC> c_14: so it's a bug? [00:36:26 CET] <c_14> Well [00:36:38 CET] <c_14> It's a "feature" that wasn't very well thought out. [00:37:03 CET] <PlanC> strange [00:37:15 CET] <PlanC> because all the other data is coming with the output [00:37:24 CET] <PlanC> the image is the only thing that's not [00:37:50 CET] <PlanC> tried playing around with -map_metadata too without any luck [00:38:14 CET] <PlanC> is there any sort of "hack" that I can use to fix it? [00:38:34 CET] <c_14> https://ffmpeg.org/ffmpeg-formats.html#mp3 [00:38:44 CET] <c_14> the second example [00:39:09 CET] <c_14> the cover art should automatically be turned into a video stream in the input file [00:40:38 CET] <PlanC> the problem is that the image is in the file though [00:40:53 CET] <c_14> the cover art should automatically be turned into a video stream in the input file [00:40:56 CET] <c_14> ^like I said [00:41:05 CET] <c_14> you (probably) just need the -metadata stuff [00:46:49 CET] <PlanC> tried it just now [00:46:59 CET] <PlanC> it gives this in the output [00:47:05 CET] <PlanC> "No packets were sent for some of the attached pictures." [00:47:21 CET] <c_14> try explicitly mapping it -map 0:v [00:47:29 CET] <c_14> you'll also need -map 0:a [00:50:15 CET] <PlanC> I'm doing something wrong [00:50:19 CET] <PlanC> this is the command that I'm running: [00:50:32 CET] <PlanC> ffmpeg -i art.mp3 -c copy -map 0:v -map 0:a -metadata:s:v title="Test cover" -metadata:s:v comment="Cover (Front)" -ss 20 -t 30 out.mp3 [00:50:47 CET] <PlanC> that last "-ss 20 -t 30" is the part that I'm cutting [00:51:12 CET] <PlanC> art.mp3 contains the image [00:51:32 CET] <PlanC> out.mp3 which is the trimmed output doesn't have it [00:56:15 CET] <c_14> It doesn't seem to work with seeking [00:57:21 CET] <PlanC> ah crap [00:57:34 CET] <PlanC> and that's going to dramatically increase the time it takes to process the file, right? [00:58:17 CET] <Hello71> durandal_1707: I halved the horizontal resolution and stretched it but then it looks jerky [00:58:44 CET] <c_14> PlanC: ffmpeg -ss 10 -t 20 -i art.mp3 -i art.mp3 -map 0:a -map 1:v -metadata:s:v title="Test cover" -metadata:s:v comment="Cover (Front)" -c:a copy out.mp3 [00:58:46 CET] <c_14> ^that works [01:00:38 CET] <PlanC> checking it out [01:01:41 CET] <PlanC> c_14: wow that really does work [01:01:45 CET] <PlanC> c_14: thanks a lot mate! [01:02:53 CET] <PlanC> so you basically selected the same file twice and got the content and ID3 from the first file and the image from the second, right? [01:03:07 CET] <c_14> pretty much [01:03:09 CET] <c_14> well [01:03:17 CET] <c_14> I'm not sure which file it's getting the ID3 from [01:03:19 CET] <c_14> one of them [01:03:25 CET] <c_14> but since they're the same file it shouldn't matter [01:03:49 CET] <PlanC> ah that's clever [01:03:51 CET] <PlanC> thanks again! [01:09:10 CET] <Freakshow> quick and potentially silly question... [01:09:46 CET] <Freakshow> does the ffmpeg process wait for the log printf statement to complete before working on the next frame of video? [01:10:44 CET] <c_14> depends on where the log is coming from, but probaly yes [01:10:47 CET] <c_14> *probably [01:12:10 CET] <Freakshow> c_14, the log I am referencing is the output log from ffmpeg itself& [01:12:31 CET] <Freakshow> whether its on console or just written to disk [01:12:48 CET] <c_14> Like I said, it depends. But probably yes. [01:12:54 CET] <Freakshow> sure sure [01:12:57 CET] <Freakshow> thanks [01:32:07 CET] <PlanC> c_14, I just noticed that there seems to be something wrong with the start and end times though [01:32:42 CET] <PlanC> c_14, for example -ss 10 -t 20 should output a 20 a file with a 20 second duration [01:33:13 CET] <PlanC> c_14, but when I run it with the -map 0:a -map 1:v that you sent me it outputs a 30 second file [01:35:45 CET] <PlanC> and when I move the -ss and -t part it doesn't come with the cover [01:36:33 CET] <PlanC> it's respecting -ss but not the -t [01:37:03 CET] <PlanC> so if I use "-ss 10 -t 10" for a 1 minute file [01:37:24 CET] <PlanC> then it'll actually start from 10 seconds but it'll ignore the "-t" and continue to the end of the file [01:37:39 CET] <PlanC> so the output would be 50 seconds long instead of 10 seconds [01:54:41 CET] <klaxa> PlanC: afaik -t is an output option [01:54:53 CET] <klaxa> use ffmpeg -ss 10 -i somefile.mp4 -t 10 output.mp4 [01:59:54 CET] <PlanC> klaxa, I played around with it earlier and moving it to the end did the trick just like you showed [02:05:52 CET] <PlanC> thanks for the tip btw [05:16:50 CET] <tomed> what advantage do i get by using "very slow" setting over "fast" setting [05:41:00 CET] Last message repeated 1 time(s). [06:13:26 CET] <naylo44> Hey, I was wondering if anyone was able to compile ffmpeg using the --enable-nvresize and --enable-nvenc flags. I'm trying to follow these directions: http://developer.download.nvidia.com/compute/redist/ffmpeg/1511-patch/FFMPE… but they seem pretty outdated. Thanks! [06:23:32 CET] <c_14> naylo44: nvenc should be enabled automatically if it's supported [06:23:35 CET] <c_14> nvresize no idea [06:24:19 CET] <c_14> (in recent enough versions) [06:24:22 CET] <c_14> so 3.2 or git-master [06:30:42 CET] <naylo44> Thanks! I tried transcoding a video I had and only achieved ~23FPS on a GTX 770 using NVENC. I think this bad performance might be because of the missing nvresize flag. I might be worng though. Thanks! [06:48:36 CET] <Guest60667> Is there any flags that I can use to ignore the bad response (missing Transport?) for RTSP SETUP from the embedded RTSP server on an Amino STB? http://pastebin.com/NEAQBX8e [09:00:57 CET] <kurufu> So, av_interleaved_write_frame expects frames across all streams to have monotonically increasing dts? Not just frames within a single stream? [10:18:11 CET] <MZ_> Hi, I'm new to ffmpeg. I've added swscale, avcodec and avutil dll in my code. compile and link is done successfully but when I run my program I'll get this message: "the program can't start because out.dll is missing from your computer". So the question is: what is out.dll? I missed some dependencies? how can I fix this error? thank you for your time [10:45:42 CET] <alexvf> MZ_: are you linking with out.dll? sounds like a mock library taken from some compilation sample? [10:46:11 CET] <alexvf> MZ_: i'm no expert but that out.dll shouldn't be anything related to ffmpeg [10:46:13 CET] <MZ_> i do not know what is out.dll. i don't have it [10:46:58 CET] <MZ_> alexvf, i really cannot understand why there is that error message. i never used anything named "out.dll" [10:47:35 CET] <alexvf> MZ_: can you show how do you build your program? [10:48:18 CET] <MZ_> alexvf, I'm using visual studio, what I need to show you? [10:49:14 CET] <alexvf> bfff, i've never used that, in fact i rarely compile nothing on windows [10:49:51 CET] <alexvf> you should look where you add avcodec, avutil and all the dependencies that your code uses [10:50:10 CET] <superware> I'm trying to have https://trac.ffmpeg.org/ticket/5615 resolved, problem is I don't have sufficient knowledge to debug this myself. Can someone please help? it's extremely easy to reproduce.. [10:51:52 CET] <MZ_> alexvf, I added avcodec.lib, avutil.lib and swscale.lib to the Linker Additional Dependencies. And in the code I #include the headers inside extern "C"{} block. (I'm coding in C++). nothing more.. [10:55:42 CET] <alexvf> MZ_: sorry, i can't help with the Visual Studio tool, if it is a small program, you could try to compile it without Visual Studio but, again, i'm of little help because i don't develop under Windows [10:56:14 CET] <MZ_> alexvf, maybe I found the problem. I found some "out.dll" string inside the binary of the avcodec.lib file... I will work on that. thank you for your time! [10:56:41 CET] <alexvf> MZ_: i was about suggesting you that [10:56:49 CET] <alexvf> MZ_: looking in the binaries [10:57:22 CET] <alexvf> MZ_: it may be a problem in the libraries itself, good luck! [11:01:04 CET] <MZ_> alexvf, thank you XD [12:20:15 CET] <MZ_> Hi, avcodec_send_packet() give me an error code that I cannot understand. The error is -1094995529 How/Where can I look for understanding it? (i solved the previous problem about the dll) [12:27:41 CET] <jkqxz> MZ_: See libavutil/error.h. [12:29:50 CET] <MZ_> jkqxz, ok, thanks [13:29:05 CET] <fling> Hello! [13:29:14 CET] <fling> I have a video from a dancing contest. [13:29:40 CET] <fling> There is a head from audience appearing on top of the background in a part of the video. [13:30:06 CET] <fling> The idea is to overlay this part with the static solid background from the different time of the same video to hide this head. [13:30:13 CET] <fling> What is the proper way doing so? [13:45:25 CET] <superware> fling: it sounds like you need a video editing software. [13:45:27 CET] <ikevin> fling, maybe adding a static png with transparency and your background can do the job [13:54:14 CET] <fling> superware: but I thought ffmpeg cat overlay videos! [13:54:32 CET] <fling> ikevin: why static? [13:54:45 CET] <fling> s/cat/can/ [13:54:56 CET] <ikevin> a mistake, png are always statics [13:55:52 CET] <fling> But why not video? [13:56:01 CET] <fling> Is it just simplier? [13:56:08 CET] <ikevin> create a png with the same size than the video and with transparent background, add your logo where you want to hide the logo [13:56:12 CET] <ikevin> yes [13:56:35 CET] <fling> It is not a logo but a moving head of a person but I got your idea. [13:56:57 CET] <fling> I will try to do this! [13:58:11 CET] <ikevin> oh, if it's moving that will need more work [14:10:43 CET] <fling> Which picture file format for a single yuv 422 frame? [16:11:24 CET] <superguest> http://pastebin.com/FfpeLt6m [16:13:00 CET] <superguest> Basically ffmpeg doesn't recognize the 'localtime' format argument for 'pts' function for the 'text' parameter. [16:13:24 CET] <superguest> https://ffmpeg.org/ffmpeg-filters.html#Text-expansion [16:14:14 CET] <superguest> [Parsed_drawtext_0 @ 0x992dc0] Invalid format 'localtime' [16:14:16 CET] <DHE> but you're running version 2.8 whereas those docs will be based on the most up-to-date version available [16:15:18 CET] <superguest> :< shiieeet. [16:15:48 CET] <superguest> DHE, stable or devel? [16:16:26 CET] <DHE> umm... not entirely sure actually [16:16:42 CET] <DHE> I would guess release version [16:37:40 CET] <superguest> I am using Ubuntu Xenial (16.04.1), and 2.8.8 is the latest version in their official repo [16:37:56 CET] <superguest> I don't want to build ffmpeg from source [17:24:46 CET] <elmarikon> cheers! Can someone help me with the loudnorm Filter!? Is it still in development? It produces results that vary big time from what I am telling it to do... [17:25:16 CET] <elmarikon> my settings: loudnorm=-23:15:-1 [17:26:39 CET] <elmarikon> result: Output Integrated: -25.1 LUFS (should be -23), Output True Peak: -1.0 dBTP (ok), Output LRA: 20.5 LU (should be mx. 15) [19:20:14 CET] <tomed> what advantage do i get by using "very slow" setting over "fast" setting [19:21:27 CET] <BtbN> quality vs speed [19:23:31 CET] <DHE> it will take a lot longer, but the image quality should be better or the resulting file size will be smaller (depending on settings) [19:54:37 CET] <KDDLB> happy birthday `md! [19:54:41 CET] <kode54> yes [19:55:57 CET] <tomed> dhe i've seen slower setting producing bigger file [19:56:42 CET] <DHE> with what settings though? [19:56:54 CET] <DHE> I mean using -qp, -crf or -b may result in different effects [20:01:51 CET] <tomed> crf20/very slow vs crf20/fast [20:06:11 CET] <DHE> hmm.. not what I would have expected [20:09:46 CET] <JEEB> the result of crf depends completely on the preset, and you should not expect the same crf to be comparable between presets [20:10:05 CET] <JEEB> depending on the content you will also get results where a much slower preset gives you a larger size for the same crf [20:10:48 CET] <JEEB> you can think of it as the encoder being able to "see" more things and do more things as you enable a slower preset, thus the meaning of the CRF value changes [20:11:24 CET] <JEEB> CRF was never meant to be a stable base between presets, QED [20:11:43 CET] <JEEB> or well, by the pure fact that it isn't such a thing and never was such [20:41:26 CET] <kerio> qp ftw [21:02:14 CET] <kriskropd> hello - I have a ton of sound effects and stuff, but the problem is a lot of them are collected in groups of 3 or 4 per file - they are each separated by some time of silence though [21:04:08 CET] <kriskropd> I wonder if I might be able to use fmfpeg or some other tool to extract each sound effect from their grouped wav file using the audio silence as a delimeter [21:08:17 CET] <kriskropd> i think sox might be able to do this too actually [21:12:09 CET] <durandal_1707> kriskropd: there are ffmpeg filters like silencedetect [21:13:27 CET] <kriskropd> durandal_1707: http://unix.stackexchange.com/questions/318164/sox-split-audio-on-silence-b… I found this and I just adjust the silence threshold to a shorter distance [21:13:31 CET] <kriskropd> adjusted* [21:13:36 CET] <kriskropd> worked for me [21:16:42 CET] <durandal_1707> kriskropd: same filter is available in ffmpeg, silenceremove [21:18:37 CET] <kriskropd> noted - I'll give that a try too then, since I don't have sox on the cygwin computer at home [21:18:55 CET] <kriskropd> this is going to be a massive time saver for me x.x [21:20:09 CET] <kriskropd> durandal_1707: I think what I'm not understanding is how to split the audio with ffmpeg [21:20:26 CET] <kriskropd> I've done it before using timestamps and a very lengthy file, but I don't see anything in this man page about splitting files based on silence [21:25:10 CET] <durandal_1707> kriskropd: there is special muxer for that... [21:31:46 CET] <Filarius> how do YUV420p looks like ? (Height) lines of (Width) bytes of Y, after that (Height/4) lines of (Width/4) bytes of U and same for V ? [21:34:34 CET] <durandal_1707> Filarius: that's more like yuv410 iirc [21:35:02 CET] <durandal_1707> 440 actually [21:35:41 CET] <durandal_1707> 420 is divided by 2 [22:02:48 CET] <Filarius> oh, ye, w/2 and h/2. So i'm right? just need to undertand coordinates of pixels in 8x8 rectangles in yuv420p [22:15:30 CET] <jermz> http://pastebin.com/5bkB9RV9 gives me the error "Warning: data is not aligned! This can lead to a speedloss", while http://pastebin.com/XqvS8LhS does not. [22:15:48 CET] <jermz> The only difference between these two commands is the padding x coordinate which moves it over 280 px to center it. [22:16:48 CET] <jermz> Any idea how to center the video without getting the error? [22:23:33 CET] <Filarius> maybe it do not know what put at background ? [22:24:01 CET] <jermz> the background is just supposed to be a blank black background. I am using a PNG as an overlay in a separate command to fill the space [23:14:32 CET] <Guest60667> Is there any flags that I can use to ignore the bad response (missing Transport?) for RTSP SETUP from the embedded RTSP server on an Amino STB? http://pastebin.com/NEAQBX8e [00:00:00 CET] --- Wed Nov 30 2016

1 0

ffmpeg-devel.log.20161128
by burek 29 Nov '16

29 Nov '16

[00:04:47 CET] <philipl> Timothy_Gu: you have admin rights on the github project? You could set up the integrations [00:05:05 CET] <nevcairiel> we have fate for regular testing :p [00:06:21 CET] <Timothy_Gu> philipl: I'm not sure... let me check [00:06:53 CET] <Timothy_Gu> philipl: nope, I don't have admin rights, only write privilege [00:07:49 CET] <philipl> Well, then michaelni has to do it or give one of us rights [00:08:33 CET] <michaelni> what do i need to do ? [00:08:34 CET] <Timothy_Gu> philipl: did you mean to say something in http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203499.html? [00:08:47 CET] <philipl> urp [00:09:20 CET] <philipl> man. I wrote a bunch of stuff :-( [00:10:00 CET] <philipl> michaelni: https://scan.coverity.com/travis_ci [00:10:35 CET] <philipl> You need to follow the instructions there down to step 4 yourself [00:10:52 CET] <nevcairiel> can you sanely rate-limit travis integration on github? like michael s aid on the ML, we cant do it after every commit [00:10:55 CET] <philipl> I'm not sure how other people get added to the project in travis, but however that's done, then someone can take over. [00:11:08 CET] <Timothy_Gu> basically go to https://travis-ci.org/profile/FFmpeg (logging in with your GitHub account as needed), and enable FFmpeg [00:11:15 CET] <nevcairiel> oh r ight you wanted to use some branch [00:11:21 CET] <philipl> As discussed in the doc, you have a separate branch for coverity [00:11:25 CET] <Timothy_Gu> nevcairiel: we can specify the branch in .travis.yml [00:11:47 CET] <philipl> You could use travis to build every commit to master as a build test, but that's a separate objective. [00:11:55 CET] <philipl> easy to do once you've done all the work for coverity, of course. [00:12:54 CET] <Timothy_Gu> michaelni: actually before you enable it, we probably need to update the .travis.yml file to whitelist the coverity branch first [00:24:46 CET] <michaelni> i see no way to add a user to this travis thing [00:26:21 CET] <philipl> Does it inherit users from the github project? [00:26:25 CET] <philipl> Chloe, Timothy_Gu ? [00:26:43 CET] <Timothy_Gu> Yeah it inherits the organization status from github [00:26:49 CET] <Chloe> yes it does [00:27:10 CET] <Chloe> you need to be in the ffmpeg org and have read access on the ffmpeg repo [00:28:16 CET] <Timothy_Gu> Actually you need more than read or write access [00:28:22 CET] <Chloe> you do? [00:28:36 CET] <Timothy_Gu> Yeah. I have write access to FFmpeg repo but i can't add travis [00:28:36 CET] <Chloe> oh right, yeah. I think you may need admin access for the repo [00:30:30 CET] <michaelni> ive added travis to ffmpeg but ive no clue how to give anyone access to that [00:30:51 CET] <Chloe> you need to give them admin access to the ffmpeg repo on github [00:31:32 CET] <Timothy_Gu> Chloe: the problem is there isn't something called "admin" on github [00:31:43 CET] <Timothy_Gu> i'm guessing they really mean "owner" but I'm not sure [00:31:50 CET] <Chloe> (if they are to do any management on the travis settings that is), anyone with push access can trigger a build [00:31:56 CET] <Chloe> Timothy_Gu lemme check [00:32:32 CET] <Timothy_Gu> Triggering is different from managing [00:32:37 CET] <Chloe> I know [00:32:50 CET] <Chloe> Create a team called 'travis', add the FFmpeg repo, and set the permission level to 'Admin' [00:33:11 CET] <Chloe> and then add people to ffmpeg org, before adding them to the travis team [00:33:23 CET] <Chloe> (this is how it's set up in another org I'm in) [00:33:33 CET] <Timothy_Gu> Chloe: you can't set permission level of a team AFAICT [00:33:44 CET] <philipl> I think you can these days [00:33:44 CET] <Chloe> pretty sure you can [00:33:46 CET] <Timothy_Gu> only per member [00:34:06 CET] <Chloe> from what I can see, it looks likeyou can [00:34:17 CET] <Timothy_Gu> where? [00:34:29 CET] <Chloe> within the teams' settings [00:34:49 CET] <michaelni> i found a optio to give admin rights on: https://github.com/orgs/FFmpeg/teams/members/repositories [00:35:18 CET] <Timothy_Gu> Ok i think that'll work [00:35:26 CET] <Chloe> nevcairiel we can do travis after every commit, but not coverity [00:35:35 CET] <Timothy_Gu> this is so confusing. GH keeps changing their team settings [00:35:55 CET] <michaelni> ok ive given all members (timothy lou and me) admin for ffmepeg/ffmpeg [00:36:20 CET] <michaelni> "this is so confusing" +1 [00:36:37 CET] <Timothy_Gu> Right, I can access Travis settings now [00:36:45 CET] Action: michaelni happy :) [00:36:52 CET] <Chloe> cool, good it works now [00:37:11 CET] <Chloe> I can help with travis, but as I said, I'm not sure about docker [00:37:12 CET] <Timothy_Gu> I guess the question now is: do we want to only use Travis for Coverity, or do we want to do what Libav does and make it another FATE client [00:37:23 CET] <philipl> Timothy_Gu, Chloe: I'll let you guys handle getting travis going. [00:37:29 CET] <philipl> I'm currently building the Dockerfile [00:37:42 CET] <Chloe> Timothy_Gu there's no reason why it couldnt be another FATE client [00:37:55 CET] <philipl> Once you've gone to the trouble of getting it working for coverity, making it run FATE will be a small amount of work [00:38:38 CET] <Timothy_Gu> Chloe: you can try with something like https://github.com/TimothyGu/FFmpeg/commit/8330ab38679e984c5b69f8257674ce01… [00:38:51 CET] <Timothy_Gu> never got it working though [00:39:40 CET] <Timothy_Gu> Okay so I guess the answer is "Coverity first, FATE later" [00:45:51 CET] <philipl> The list of dependencies that you can't satisfy from official ubuntu packages is pretty small. [00:46:49 CET] <Chloe> So philipl's doing the docker, I'll add it as a FATE client. Who's overseeing travis? [00:47:22 CET] <Chloe> I mean, I can do that too, but I'd need access. [00:47:53 CET] <Timothy_Gu> Chloe: I can do it [00:47:59 CET] <Chloe> ok [00:48:20 CET] <Timothy_Gu> And I don't think I have the ability to add people to the FFmpeg gh org :( [00:48:36 CET] <Chloe> afaik only michaelni has the ability [00:48:49 CET] <Timothy_Gu> yeah [00:50:17 CET] <Timothy_Gu> If someone needs Travis to be enabled ping me [01:03:06 CET] <philipl> https://github.com/philipl/FFmpeg/commit/885eff0c6502a6f3ab7500a2442bd37702… [01:03:19 CET] <philipl> That's a build dockerfile and one that runs configure on top of it, to prove it works [01:05:13 CET] <Chloe> philipl so which dependencies are missing? [01:06:03 CET] <philipl> whatever maps to the commented out enable options [01:06:15 CET] <philipl> Of course, a few of those are impossible - android, rpi, etc [01:06:35 CET] <philipl> iec61883 and tesseract are present in ubuntu but configure failed. I haven't investigated yet. [01:07:33 CET] <philipl> So someone should register ffmpeg with docker hub and that can be pointed to the build environment Dockerfile after it's checked in. [01:08:40 CET] <Chloe> https://buildbot.openmpt.org/builds/auto/src/ the autotools tarballs from here work best [01:09:53 CET] <philipl> I can create the ffmpeg org in docker hub if we want. [01:10:55 CET] <Chloe> I dont see an issue with that, as long as other relevant people can get access too [01:11:04 CET] <philipl> Send me docker usernames/emails and I'll add them [01:17:24 CET] <philipl> I suspect someone with github admin access has to link to docker hub for the automatic builds to work. [01:17:30 CET] <Timothy_Gu> philipl: timothygu/timothygu99(a)gmail.com [01:17:56 CET] <philipl> done [01:18:18 CET] <Timothy_Gu> philipl: You can put the dockerfile in your own repo and set up the auto builds from there, no? [01:18:27 CET] <philipl> That's what I'm going to test, at least. [01:18:41 CET] <Timothy_Gu> There doesn't seem to be a connection between GitHub accounts and dockerhub ones [01:19:06 CET] <Chloe> Timothy_Gu there is [01:20:20 CET] <Chloe> https://cloud.docker.com/app/timothygu/settings -> Source providers -> click on github's socket thingy [01:21:12 CET] <Timothy_Gu> what's Docker cloud? [01:22:00 CET] <Timothy_Gu> I mean I already have a Docker Hub account? [01:22:13 CET] <Chloe> oh [01:22:20 CET] <Chloe> i think I signed up to the wrong thing [01:23:17 CET] <Chloe> Timothy_Gu: https://hub.docker.com/account/authorized-services/ -> github maybe? [01:23:31 CET] <Timothy_Gu> yeah we already did that [01:24:08 CET] <philipl> https://github.com/philipl/ffmpeg-build-docker [01:24:14 CET] <philipl> https://hub.docker.com/r/ffmpeg/build/builds/ [01:25:03 CET] <Timothy_Gu> well let's see how fast this thing runs [01:25:33 CET] <philipl> It took a while to do locally for me. It's 900MB of crap that needs to be downloaded and 3.5GB image at the end of the day [01:27:34 CET] <Timothy_Gu> michaelni: can you add me or philipl to the Coverity project? [01:27:46 CET] <Timothy_Gu> as "Admin" [01:27:51 CET] <Timothy_Gu> in order to submit builds [01:30:30 CET] <michaelni> Timothy_Gu, done [01:31:27 CET] <Timothy_Gu> thx [01:36:14 CET] <Timothy_Gu> ok I've linked the Coverity project with GitHub, so we just need to get the Travis thing working [01:53:10 CET] <philipl> Success. Took 27 minutes apparently [01:55:21 CET] <philipl> I'm not sure what the recommended way to run a build in docker on top of travis is. I haven't found exact examples. [02:00:25 CET] <Timothy_Gu> philipl: https://docs.travis-ci.com/user/docker/ [02:02:02 CET] <Timothy_Gu> "BuildTime: 2016-10-26T22:01:48.986273588+00:00" heh [02:05:27 CET] <philipl> Timothy_Gu: that doesn't discuss how to run the actual build in docker. [02:05:47 CET] <philipl> given that travis has already checked out the source code, what's the recommended way to access it in the container. [02:05:50 CET] <philipl> That kind of thing [02:06:05 CET] <Timothy_Gu> -v `pwd`:/src ? [02:06:16 CET] <philipl> probably. [02:06:22 CET] <philipl> It's just I couldn't find a discussion of it [02:24:30 CET] <Timothy_Gu> philipl: I don't think we can use Travis CI's nice coverity addon because we are using a container [02:25:02 CET] <Timothy_Gu> check out https://scan.coverity.com/projects/ffmpeg/builds/new?tab=upload for instructions on downloading the cov-build tool among other things [02:25:39 CET] <philipl> hrm, [02:27:35 CET] <philipl> With the addon, the build is still done using the script. [02:27:50 CET] <philipl> So you can '-v' the directory, run the build and then the output is there to be grabbed by coverity, right? [02:28:24 CET] <philipl> don't know until you try [02:29:11 CET] <wm4> can't you just use github's coverity integration? [02:30:08 CET] <philipl> That is what we're discussing. The builds have to run with travis [02:32:13 CET] <Timothy_Gu> cov-int basically puts some gcc wrappers in PATH, but because we are doing the build in the container with separate CC etc im not sure if it will work [02:33:23 CET] <philipl> ah. yeah, that won't help, although we could set it up in the container and still use the addon to upload [02:33:28 CET] <philipl> which has value [02:35:23 CET] <Timothy_Gu> or actually i think u might be tight. cov-int directory exists in the *cov-build [02:36:03 CET] <Timothy_Gu> sorry typed "enter" at the wrong time [02:36:57 CET] <Timothy_Gu> i think we should be able to use it for upload, but in that case we could just as well upload it ourselves [02:37:16 CET] <philipl> up to you. See what's easiest. [02:37:28 CET] <Timothy_Gu> yep [02:37:52 CET] <Timothy_Gu> sorry got homework tonight. Will try figuring something out tomorrow [02:38:26 CET] <philipl> Sure. [02:38:38 CET] <philipl> I'm done for the day. I found what I could in ppas and I'm updating the docker file. [02:39:09 CET] <philipl> Everything else is tricky. Source builds are always an option and some are in ancient ppas, which reflect that these libraries are ancient and irrelevant but that's ffmpeg for you. [02:46:44 CET] <Timothy_Gu> philipl: thanks for all the work! [02:47:02 CET] <philipl> you too. [04:49:22 CET] <rcombs> wm4: you mean, like, determine if a VT frame is yuv420p or nv12 (or I guess it could technically be RGB), find out what the plane offsets, strides, etc& are, and such? [04:49:44 CET] <rcombs> if so, yes, there are reasonably usable APIs for that [11:24:21 CET] <durandal_1707> don't kill ffserver, fix it instead [11:30:37 CET] <JEEB> right [11:31:19 CET] <JEEB> people are currently just saying that it should GTFO of the main repo as most probably the biggest offender of internal API usage etc [11:32:02 CET] <JEEB> also at least one attempt was to make a streamer based on the public APIs and it's definitely possible (someone posted a funky matroska streamer here before) [11:32:28 CET] <JEEB> where ffserver "works" is very limited and you should see how many times someone *thinks* they can utilize it on #ffmpeg [11:32:37 CET] <JEEB> that's of course separate from bad API usage [11:32:43 CET] <JEEB> but it's a mess from multiple sides [13:41:10 CET] <BBB> so are we removing ffserver tomorrow, or should I call for a vote to remove it? [13:46:50 CET] <jamrial> BBB: as i said on an email, i'm (still, somehow) ok with waiting until 3.3 is ready to be branched out before removing it, since it will aid michaelni and/or reynaldo on making it work as a standalone program [13:47:20 CET] <BBB> the only reason michael works on ffserver is because its in-tree [13:47:22 CET] <jamrial> but if you want to start a vote to choose between "remove after this voting ends" or "remove right before 3.3 is branched" then go ahead [13:47:29 CET] <BBB> like, he doesnt work on MPV or gstreamer or chrome [13:48:09 CET] <BBB> I just want to make sure 3.2 doesnt repeat itself [13:48:12 CET] <BBB> that was embarassing [13:48:24 CET] <Compn> embarassed for an open source project [13:48:33 CET] <jamrial> yes, i've said as much in more than one reply to that thread [13:49:36 CET] <BtbN> I can't think of any good reason for it to stay. Even with a few people desperately fighting for it. If they like it so much, it can be maintained out of tree. [13:50:00 CET] <BtbN> Eventually, all the cli tools should be moved out of tree. But ffserver is the most pressing one [13:51:03 CET] <BBB> ffmpeg can stay IMO [13:51:09 CET] <BBB> ffplay is fun but nothing else, it [13:51:15 CET] <BBB> its useful for seeking maybe [13:51:20 CET] <BBB> for lack of better seek tests [13:51:27 CET] <BBB> but probably should be moved also [13:51:36 CET] <BBB> (would also give us reasons to use real players like MPV or whatnot) [13:51:45 CET] <BBB> (or VLC; I dont care; just not ffplay) [13:52:05 CET] <BBB> ffmpeg.c is pretty useful for a lot of things, also because every single fate test uses it... [13:52:46 CET] <jamrial> was going to say, ffmpeg out of tree would be more a pain in the ass than a net gain. running fate would become twice as hard, for starters [13:52:52 CET] <jamrial> but that's a discussion for another day [13:53:51 CET] <BBB> totally agree [14:04:44 CET] <iive> so you want to get ffmpeg out of ffmpeg. [14:07:24 CET] <wm4> rcombs: getting the format once you have output is trivial [14:07:36 CET] <wm4> rcombs: but you still need to set an output format before decoding begins (or so) [14:07:47 CET] <wm4> rcombs: the question is how to determine the best format for that [14:08:00 CET] <rcombs> oh [14:11:35 CET] <rcombs> looks like I just hardcoded kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange (i.e. NV12) [14:16:12 CET] <wm4> the problem is that this format leads to horrible performance on older hw [14:17:04 CET] <rcombs> oh, it does? [14:17:23 CET] <rcombs> so older hardware prefers planar and new prefers semi-planar? [14:17:37 CET] <wm4> older hw prefers packed [14:18:47 CET] <nevcairiel> what kind of hardware are we talking about, mobiles or PCs? [14:19:43 CET] <rcombs> what does "packed" mean in that context? [14:20:11 CET] <wm4> maxminis [14:20:14 CET] <wm4> *macminis [14:20:38 CET] <wm4> rcombs: kCVPixelFormatType_422YpCbCr8 [14:20:40 CET] <nevcairiel> i find it rather curious that the same hardware that would run on a different OS suddenly has special requirements when it runs on osx =p [14:21:08 CET] <wm4> yeah [14:21:23 CET] <wm4> actually I don't know if the problem is in the decoder or renderer [14:21:27 CET] <rcombs> wew 4:2:2 [14:21:28 CET] <wm4> I never had direct access to said hw [14:21:53 CET] <wm4> it corresponds to AV_PIX_FMT_UYVY422 [14:24:45 CET] <rcombs> source on that being preferred over NV12? (as opposed to over yuv420p) [14:26:24 CET] <rcombs> or is that experimentally determined? [14:26:35 CET] <wm4> experimentally [14:29:30 CET] <rcombs> yeah, I've got no idea [14:29:35 CET] <rcombs> looks like most software just picks one [14:29:47 CET] <rcombs> or uses packed 4:2:2 on iOS and NV12 on macOS [14:29:54 CET] <rcombs> erm, swap those [14:30:04 CET] <wm4> woah [14:30:51 CET] <rcombs> I don't see any documentation on the topic [14:31:47 CET] <wm4> documentation seems to be completely absent more than not [14:32:10 CET] <rcombs> yup [15:40:43 CET] <Compn> https://en.wikipedia.org/wiki/Conflict_resolution [15:43:53 CET] <jamrial> Compn: there is no conflict. there's a few people that missed the ship sailing, noticed it only when it was about to reach destination, and now pretend it should instead go back home [16:10:47 CET] <MustBeLucky2> is #ffmpeg usually dead this time of morning? [16:16:32 CET] <DHE> it's very situational on what people have experience with. ALSA recording is probably less common knowledge than file-to-file work, for example [16:24:26 CET] <MustBeLucky2> Cool, thanks for the heads up [16:25:53 CET] <MustBeLucky2> maybe a dev can help me fidn ALSA_BUFFER_SIZE_MAX? i saw a post that claimed it was in libavdevices/asla-audio.h but this file does not exist on my device. Is this normal? [16:28:25 CET] <atomnuker> BBB: there's no need to vote, by the time it's close to 3.3 everything ffm related would be gone from ffserver and it will be removed [16:28:48 CET] <atomnuker> it's just that the people who care need some time to finally sort it out [16:28:56 CET] <nevcairiel> didnt we even vote before on the previous irc meeting or something [16:30:23 CET] <jamrial> holy shit, nicolas can be annoying [16:32:22 CET] <nevcairiel> its his usual deal, have no base to stand on but hide behind fancy arguments that make everyone want to quit isntead of keeping to argue [16:35:31 CET] <BBB> if he wants to play a game, thats fne [16:35:33 CET] <BBB> lets play the game [16:35:42 CET] <BBB> but we want him to agree (eventually) with some outcome [16:35:48 CET] <BBB> so that we can actually move on [16:35:48 CET] <nevcairiel> he wo nt [16:35:50 CET] <nevcairiel> he is like that [16:36:04 CET] <nevcairiel> if we vote he'll quote some pseudo legal why our vote was invalid [16:36:05 CET] <nevcairiel> done it before [16:36:16 CET] <BBB> pff... [16:36:25 CET] <BBB> at the end of the vote, if the result is to remove it [16:36:27 CET] <BBB> announce it [16:36:34 CET] <BBB> and apply patch at same time [16:36:41 CET] <BBB> can argue for days and years, but need to move [16:36:42 CET] <nevcairiel> we did announce it, publicly in a news entry, months ago when we decided to remove it [16:36:44 CET] <BBB> this is soooo ridiculous [16:36:48 CET] <nevcairiel> there isnt even room for s discussion [16:39:33 CET] <nevcairiel> jamrial summarized it pretty well in his mail, we conceded them sometime to split it into a new repo before we remvoe it, now some of the work towards that goal is used as leverage to actually keep it entirely, which is just malice [17:17:02 CET] <cone-287> ffmpeg 03Michael Niedermayer 07master:bda6f2937ea1: ffmpeg_opt: Fix starttime with ffm in bitexact mode [17:31:54 CET] <BBB> lol @ ET for atari [17:31:57 CET] <BBB> that was pretty sweet [17:32:43 CET] <wm4> where is the patch that makes ffserver not require the ffm parts in libavformat to access the deprecated AVCodecContext? [17:34:26 CET] <wm4> jamrial: I'm sorry that you have to "discuss" with this "person" [17:39:44 CET] <BBB> adding a streaming server? Whats next - adding a directory browsing API? [17:39:50 CET] <BBB> oh crap we already did that *headbang* [17:40:03 CET] <JEEB> :D [17:40:34 CET] <JEEB> for a while I haven't been able to take that thread seriously [17:40:47 CET] <JEEB> jusy for my own sanity [18:02:17 CET] <durandal_1707> this community is very toxic, can I add another filter? [18:02:46 CET] <nevcairiel> can you filter the community? [18:11:05 CET] <BBB> -vf trolls=false [18:17:56 CET] <Chloe[m]> they submitted a turing codec patch again, saying they fixed all the issues, yet it still doesn't build on macOS .-. [18:18:37 CET] <Chloe[m]> I would try fix it myself but I don't really know C++ [18:19:08 CET] <nevcairiel> building on all platforms isnt exactly a requirement, tbh [18:23:41 CET] <Chloe[m]> sure, but I'm not the only person here who uses macOS, and it would be nice for testing [19:15:02 CET] <roxlu> hey! I'm using ffmpeg in my C++ app. When I try to decode a .mp4 file (that was created using Quicktime on Mac), I get lots and lots of errors like: https://gist.github.com/roxlu/ae6e2e4fb06992da91bc8ac36c9ddd6f [19:17:08 CET] <Chloe[m]> roxlu: wrong channel, #ffmpeg [19:17:54 CET] <roxlu> Chloe[m]: ah thanks [19:18:22 CET] <Chloe[m]> turingcodec's code is hardly intuitive though... Maybe it's that I don't know C++ but... https://github.com/bbc/turingcodec/blob/stable/turing/Global.h#L461 [19:18:38 CET] <wm4> w-wat [19:20:30 CET] <Chloe[m]> I don't understand how this code works on linux, let alone why it doesn't work on macOS [19:20:35 CET] <BtbN> what even is that? Just another video codec? [19:20:46 CET] <JEEB> yet another HEVC encoder [19:20:50 CET] <JEEB> this time from BBC [19:21:02 CET] <BtbN> looks horrible [19:21:10 CET] <Chloe[m]> have you seen the API? [19:21:11 CET] <Chloe[m]> lol. [19:21:15 CET] <BtbN> yes [19:24:40 CET] <wm4> so the cmdline API seems not so bad suddenly [19:30:53 CET] <kierank> research code is complex, news at 11 [19:31:49 CET] <wm4> s/research/c++/? [19:36:54 CET] <durandal_1707> c++ is obfuscation step [19:50:25 CET] <durandal_1707> j-b: ping [20:20:29 CET] <cone-287> ffmpeg 03Vittorio Giovara 07master:afb84857bf53: vf_colorspace: Forbid odd dimensions [20:55:01 CET] <Chloe[m]> atomnuker: still on track for the patch to be pushed tomorrow, right? I guess the 'DECISION' or whatever (not sure what exactly it's mean to be) by nicolas will be ignored? [20:56:09 CET] <atomnuker> it was an arbitray decision by me so no [20:59:50 CET] <durandal_1707> so ffserver gonna be lost? it was useful I think maybe still is, but implementation is just bad [21:00:08 CET] <JEEB> it's not lost [21:00:12 CET] <JEEB> even if removed [21:00:19 CET] <JEEB> the idea was to just separate it [21:00:34 CET] <durandal_1707> to obscure place [21:00:35 CET] <JEEB> it will be lost if nobody updates it to be less insane [21:05:30 CET] <cone-287> ffmpeg 03Alex Converse 07master:8899057d914a: libvpxenc: Report encoded VP9 level [21:08:52 CET] <JEEB> durandal_1707: also the main part is that I can't think of anything that ffmpeg.c (actually tested component!) wouldn't be able to handle together with one of the following: icecast, nginx-rtmp, vlc [21:09:19 CET] <JEEB> rtsp, udp, HLS/DASH, basic http streaming [21:21:11 CET] <iive> the reason to move it to a separate repo is to let it rot there. [21:21:29 CET] <nevcairiel> in contrast to it rotting for years in the main repo, how is that different? =p [21:22:12 CET] <nevcairiel> without the attempt to move it out, noone would have cared to look at it at all [21:44:35 CET] <iive> nevcairiel: when it is in the main repo, there is still obligation to keep the api compatible with it, or update it when the api is changed [21:44:57 CET] <nevcairiel> thats the main reason it needs to go, it badly violate sthe api in several places [21:45:05 CET] <nevcairiel> please do inform yourself on the topic before commenting [21:45:08 CET] <iive> and that's the reason to request its removal [21:45:12 CET] <nevcairiel> we have enough people commenting from the sidelines [21:46:38 CET] <iive> well, we don't seem to disagree [21:46:42 CET] <iive> why the hostility. [21:50:23 CET] <wm4> iive: because we discussed this over and over months or weeks ago? [21:57:18 CET] <iive> and it is still discussed [21:57:51 CET] <iive> what really makes me sad is how much people are eager to kill things, instead of fixing them. [21:58:54 CET] <BBB> iive: not everyone has an interest in fixing everything and the kitchen sink [21:59:17 CET] <BBB> iive: yet a lot of people like to continue to push the boundaries of whats possible with ffmpeg and libav{codec,filter,format,*} [21:59:31 CET] <jamrial> iive: why didn't you answer to calls for help to fix and maintain ffserver during the past few years then? [21:59:33 CET] <BBB> iive: ffserver sits in the way of that purpose, it doesnt help it [22:01:52 CET] <lotharkript> I have a quick question: the example doc/examples/remuxing does not work for Y4M file. The problem is that the demuxer returns the codec RAWVIDEO, but the muxer take only WRAPPED_AVFRAME. To fix this, i could re-add the RAWVIDEO codec to yuv4mpegenc. Any comment? [22:02:16 CET] <lotharkript> doc/examples/remuxing /tmp/test.y4m /tmp/test1.y4m <-- this fails [22:05:14 CET] <iive> jamrial: (de)muxer and streaming are not in my competence. [22:11:22 CET] <iive> BBB: remove the old to give a way to the new. I've heard that before. [22:12:15 CET] <wm4> iive: if you don't know about it and won't fix it and don't even use it, you don't get to have strong feelings on it [22:12:27 CET] <BBB> lotharkript: did you check the APIChanges to see what the recommended way is to use muxers that want WRAPPED_AVFRAME input? [22:12:40 CET] <BBB> lotharkript: you likely need to call them in some special way and remuxing hasnt been updated for that change yet [22:12:51 CET] <wm4> iive: "it would be nice to keep it" is not enough reason that we torture ourselves for it [22:15:18 CET] <iive> wm4: are you quoteing me? because i don't think i've said that. [22:15:25 CET] <lotharkript> BBB: I did not see any thing in the API changes explaining what to do.. [22:15:41 CET] <iive> but if there are people who are fixing it and they want to keep it, then why not. [22:17:10 CET] <BBB> lotharkript: I believe quite literally you create an AVPacket where pkt.data is set to AVFrame * [22:17:41 CET] <BBB> lotharkript: since yuv4mpegpipe.c does AVFrame *frame = (AVFrame *)pkt->data; (where pkt was declared as AVPacket *pkt) [22:18:28 CET] <BBB> lotharkript: so in the case of AVCODEC_ID_RAWVIDEO, you probably need to decode it using the rawvideo decoder, and then input the decoded AVFrame wrapped in a AVPacket into the muxer [22:18:30 CET] <lotharkript> BBB: I agree, but the demuxer return a AVPAcket without an AVFrame. Does it mean you need to create a AVframe from the AVpacket and then use it in the new AVPacket? [22:19:19 CET] <BBB> lotharkript: yes exactly, I realize it sounds a litle counterintuitive that you need to decode a non-compressed packet to do remuxing [22:19:23 CET] <BBB> lotharkript: but thats indeed what it means [22:19:58 CET] <BBB> lotharkript: hopefully that makes sense (not conceptually, but as in you knowing what to do to get it to work) [22:20:05 CET] <lotharkript> BBB: Can we not just re-add the RAWVIDEO codec support to the muxer as secondary codec? [22:20:25 CET] <BBB> maybe& thats not up to me to decide [22:21:00 CET] <BBB> you could certainly propose this on the mailinglist [22:21:10 CET] <BBB> Im not against it (Im not really for it either, I dont know whats best) [22:21:47 CET] <lotharkript> it feel counter intuitive to create a decoder in the muxer to get a AVFrame before calling the write_frame [22:30:08 CET] <BBB> I totally agree its counterintuitive [22:30:24 CET] <BBB> I wasnt intending to defend the way it is, just trying to help you get it working with the current way it works ;) [22:30:41 CET] <BBB> btw, guys, didnt libav drop avserver? [22:31:27 CET] <Chloe[m]> BBB: yes [22:31:45 CET] <BBB> look at the counts when you search on google for avserver.exe (13.6k), avconv.exe (13.4k), ffmpeg.exe (212k) or ffserver.exe (9.6k) [22:31:56 CET] <BBB> avserver.exe appears _more_ than ffserver.exe [22:32:28 CET] <Chloe[m]> hmm, well I can't see it in the source tree. Is it in an external repo? [22:32:34 CET] <BBB> and avserver/avconv.exe is actually > 1.0, whereas ffserver/ffmpeg.exe is a few % at best [22:32:41 CET] <BBB> dunno [22:32:49 CET] <BBB> isnt it interesting that it appears more often than avconv.exe? [22:33:00 CET] <BBB> (and more than ffserver.exe) [22:34:59 CET] <Chloe[m]> I assume it's because of how the timing with debian switching to libav, and avserver still being in libav worked out. As in, people are on old stable debian (or something) using avserver because ffserver isn't on old stable (for example). [22:35:25 CET] <durandal_1707> an avserver may be something else [22:35:52 CET] <Chloe[m]> ^ there's this too. disclaimer: I have no idea [22:37:15 CET] <nevcairiel> lotharkript: you totally want to avoid using rawvideo for muxing, it's terrible for performance, intuitive or not. Using wrapped avframe is easy [22:38:14 CET] <nevcairiel> Examples j [22:38:31 CET] <nevcairiel> Examples are just examples, they don't support everything [22:38:47 CET] <BBB> durandal_1707: that may be, yes& but its interesting how close the counts for avserver and avconv are, which makes me & not doubt& but & wonder about that [22:39:39 CET] <BBB> nevcairiel: remuxing (w/o decoding) is a special case though, then there really is no reason to use avframe over rawvideo [22:39:50 CET] <BBB> nevcairiel: and requiring avframe adds some slight code complexity [22:39:58 CET] <BBB> again, not picking sides, but I can see his point that its sorta strange [22:40:04 CET] <BBB> (for this particular one use case only) [22:42:33 CET] <nevcairiel> Remuxing y4m to y4m is not particularly useful of a function [22:44:45 CET] <nevcairiel> And supporting multiple codecs required more then just a flag in the mixer for raw [22:44:53 CET] <nevcairiel> Mixer* [22:45:00 CET] <nevcairiel> Damn autocorrect [22:45:10 CET] <nevcairiel> I need to teach it some words [22:48:53 CET] <cone-287> ffmpeg 03Michael Niedermayer 07master:319a7c5deae5: tests/ffserver-regression.sh: Fix file truncation introduced in 508826f961caf662cadb7c253e3c0e7d75104bdd [22:48:54 CET] <cone-287> ffmpeg 03Michael Niedermayer 07master:c8b24a685ac5: ffserver: drop FeedData, its unused [22:48:55 CET] <cone-287> ffmpeg 03Michael Niedermayer 07master:75b436d8b682: ffserver: Remove use of AVStream as a intermediate to store parameters [22:48:56 CET] <cone-287> ffmpeg 03Michael Niedermayer 07master:da38da459598: ffserver: Remove some deprecated API use related to codec/codecpar [22:48:57 CET] <cone-287> ffmpeg 03Michael Niedermayer 07master:0dbee6770039: ffserver: Remove last use of AVStream size [22:51:39 CET] <jamrial> "fix" something introduced by a commit from freaking 2007 [23:12:37 CET] <michaelni> ffserver.exe is not found much because mingw* lacks the dependancies ffserver needs so its not built (at least not on my mingw32 or 64) [23:14:26 CET] <nevcairiel> it needs fork i think, which windows doesnt have [23:15:37 CET] <nevcairiel> and some signal.h thing, apparently [23:34:55 CET] <lotharkript> nevcairiel: I understand the wrapper is easier when you have decoding/encoding path, but when you just demux a Y4M file and you want to remux it, now, you have to decode the AVPacket to get the AVFrame. [23:37:05 CET] <nevcairiel> the av_image_* apis can just fill an AVFrame with the data from the rawvideo packet [23:37:26 CET] <nevcairiel> the key point is, supporting another codec in the muxer would require a lot of ugly ifs everywhere [23:39:48 CET] <lotharkript> agreed, but then the problem is done at the demuxer level, instead of the caller. Other wise, the called will need to check which demuxer it will use, check if the codec is the wrapper one and call some av_image_* api to fill an AVFrame. So, you are pushing the ifs statement to the caller of the libavformat, instead of the muxer to deal with it. [23:41:25 CET] <nevcairiel> rawvideo should really be discontinued from all muxers for unity [23:43:27 CET] <lotharkript> why? the codec type is still raw video. Why not then removing it from the demuxer then? Should the demuxer create a wrapped AVFrame when the codec is raw? [23:45:08 CET] <nevcairiel> the problem is that rawvideo is inherently extremely huge data that needs shuffling around, so any extra movement should be avoided, demuxing into rawvideo is ok since thats basically just the file packet copied into memory, but the other way around its different, and riddling every muxer with support for those two formats is just silly [23:47:30 CET] <nevcairiel> as such it being different is just the price you pay for not having your memory bandwidth requirements being trippled [23:54:25 CET] <nevcairiel> i wonder if you could make a bsf that would wrap rawvideo into an avframe, can bsf change the codec id? would that be sane? probably not right [00:00:00 CET] --- Tue Nov 29 2016

1 0

ffmpeg.log.20161128
by burek 29 Nov '16

29 Nov '16

[01:10:24 CET] <hiihiii> what's the ffmpeg command to merge/join two vids which are online? I'm using "concat -i "url_1" -i "url_2" -codec copy output.mp4 [01:22:51 CET] <Mysoft> ok, thanks for all the insights, i finally got my recorder working as best as i can [01:24:11 CET] <Mysoft> (windows XP / core2quad 2.5ghz / 4gb / 1mbps upload, capturing from the game with my own "injected module", and pipying the i420p+pcm to ffmpeg trough an .avi [01:24:31 CET] <Mysoft> and so on... tuning the best i could for quality recording of paladins... [01:24:39 CET] <Mysoft> result https://twitch.tv/mysoft [01:24:49 CET] <Mysoft> so thank you for all the fish :D [02:05:28 CET] <FishPencil> Does x264's CRF value actually calculate a "quality" target? As in, if I had two inputs of the same media with only different bitrates, would x264 compress them to the same size, if the same crf value is used? [02:06:56 CET] <FishPencil> Or is the crf value more of a percentage of the original bitrate? [02:23:16 CET] <DHE> FishPencil: broadly speaking busier frames will have the qp value raised. the crf setting specifies a sort of "nominal" qp value (that is oversimplifying it a lot) [02:34:47 CET] <Hello71> how do I make showspectrum go faster? [02:40:57 CET] <FishPencil> DHE: With identical inputs only varying with bitrate, will the same CRF value produce the same output, or does the input bitrate matter [02:41:43 CET] <DHE> crf is intended as an alternative to bitrate selection mode [02:42:41 CET] <DHE> though you can use a sort of constrained mode [02:43:48 CET] <FishPencil> DHE: So that would imply a "yes" to my question? [02:46:09 CET] <DHE> I don't know. I've never tried that. I'm saying what I know [02:47:53 CET] <DHE> that such a mode exists [02:48:35 CET] <FishPencil> DHE: I'm asking because I'm seeing oddly different file sizes with different streams from the same bluray. I would assume they should all be close to the same, assuming their motion is somewhat similar, but some are 3GB+, and other <1GB [04:54:25 CET] <mozzarella> guys [04:54:30 CET] <mozzarella> if I install gstreamer-ffmpeg, will it play all formats ffmpeg can play? [05:12:09 CET] <tomed> do you actually gain anything by using slow x264/x265 setting instead of fast [05:25:17 CET] <thebombzen> tomed: yea. depends on the setting. if you are using CRF then the quality will be the same but slow will have a bitrate improvement. [05:25:35 CET] <thebombzen> if you're using a VBR mode like -b:v 2000k, then slow will have better quality than fast. [05:25:45 CET] <tomed> thebombzen are you sure even if i use ultrafast setting? [05:26:22 CET] <thebombzen> tomed: ultrafast is different cause it forces a profile change. but yea, -crf:v 18 will have the same quality at all presets. [05:26:48 CET] <thebombzen> but if you use ultrafast, the bitrate will be absurdly high and if you use slow, the bitrate will be more reasonable. [05:26:58 CET] <tomed> so crf20 on ultrafast and placebo will same same quality output? [05:27:04 CET] <furq> no [05:27:19 CET] <furq> the same crf will look better with slower presets [05:27:30 CET] <thebombzen> furq: I don't understand? [05:27:31 CET] <tomed> it shouldn't though [05:27:38 CET] <thebombzen> afaik that's because ultrafast forces the constrained baseline profile. but everything else should be identical? [05:28:10 CET] <furq> no, you will often find veryslow results in a bigger file than slow [05:28:47 CET] <thebombzen> I also don't understand why that will occur? [05:28:50 CET] <thebombzen> that sounds like a bug. [05:29:00 CET] <tomed> furq if that is true, then what is the point of "very slow" [05:29:14 CET] <furq> like i said, it increases quality at the same crf [05:29:29 CET] <thebombzen> furq CRF stands for constant rate factor. it's a constant quality. [05:30:02 CET] <furq> http://forum.doom9.org/showthread.php?t=157779 [05:30:42 CET] <thebombzen> that thread is six years old [05:31:40 CET] <furq> http://forum.doom9.org/showthread.php?p=1567146#post1567146 [05:34:04 CET] <thebombzen> well that directly contradicts what's on the ffmpeg wiki last time I read it [05:34:18 CET] <furq> a lot of things directly contradict the ffmpeg wiki [05:35:00 CET] <thebombzen> well it says on https://trac.ffmpeg.org/wiki/Encode/H.264 that you should choose a CRF value first, and then a preset. [05:35:04 CET] <thebombzen> if that's wrong, someone should change it. [06:33:24 CET] <kepstin> I've found that changing the preset while keeping the crf the same usually seems to change the resulting bitrate more than the quality. [06:34:12 CET] <kepstin> but then i'm mostly comparing 'veryslow' to 'veryfast', don't use the in-between modes much :/ [09:30:04 CET] <Filarius> hi, i'm looking for RGB to YUV formula used by FFMpeg in RGB24 to YUP420P conversion, i'm not so good in diggining source code, just found it must be somethere around swscontext and sws_scale [09:38:35 CET] <JEEB> the formula itself is generic, you should look at something like BT.709 or BT.2020 or such, as not YCbCr is the same [09:54:57 CET] <SouLShocK> is it possible to use timestamp from input stream, to name files with the strftime using the timestamp from the input stream when writing to -segment format? i.e. name files output_2016_11_27_22_14_00.ts when input stream is at 22:14:00, instead of using local clock on the machine running ffmpeg [10:52:59 CET] <techtopia> is there someway i can scan a video for dupe frames eith ffmpeg [11:13:38 CET] <durandal_1707> techtopia: you can use framemd5 muxer or any hash muxer to help search for dupe frames [13:48:21 CET] <barhom> Hey, Im using libzvbi and "-txt_page" to overlay some dvb subtitles into the video, but I dont know how to find out the correct teletext (subtitle) page number. [13:48:26 CET] <barhom> Is there a way to list all available pages? [14:13:30 CET] <Mathijs> I want to extract audio from a video file and convert it to wav. Is it possible to obtain a wave-file (not raw, so with header) without writing to a file with the .wav extension? [14:13:31 CET] <Mathijs> I use a batch-processing tool that provides me with a temporary file (which I want to write the audio to) but that tempfile does not end in .wav and ffmpeg seems to write raw samples to it. [14:14:15 CET] <furq> Mathijs: -f wav [14:14:51 CET] <Mathijs> That's easy. I googled and couldn't find it... [15:08:25 CET] <superguest> https://ffmpeg.org/ffmpeg-utils.html#Date [15:08:56 CET] <superguest> [(YYYY-MM-DD|YYYYMMDD)[T|t| ]]((HH:MM:SS[.m...]]])|(HHMMSS[.m...]]]))[Z] [15:09:48 CET] <superguest> there's an extra ']' in both (HH:MM:SS[.m...]]]) and (HHMMSS[.m...]]]) [15:10:43 CET] <superguest> in case someone cares [15:11:00 CET] <JEEB> the docs are in the repo, if you found a bug you can write a patch and have it fixed [15:11:04 CET] <JEEB> vOv [15:27:05 CET] <Guest72179> good morning [16:00:21 CET] <MustBeLucky2> Has anyone experienced and fixed an ASLA buffer xrun problem before? I believe this is making my audio drop. [16:04:49 CET] <MustBeLucky2> i see a post that says to increase the ASLA_MAX_BUFFER_SIZE but they say its located in libavdevice/asla-audio.h but this file does not exist [16:05:22 CET] <MustBeLucky2> also, i decreased the frame rate via -r , but the log shows that it starts at 75 FPS and slowly drops down. [16:07:46 CET] <MustBeLucky2> my command http://pastebin.com/45mkeywS [16:24:14 CET] <debianuser> MustBeLucky2: It may be not because of alsa, but because of video encoding or otherwise high cpu usage, or slow network maybe. So ffmpeg can't read alsa stream in time, alsa just exposes that to you. Try recording just alsa to a file, e.g. `ffmpeg -f alsa -ac 1 -i hw:1,0 -acodec aac -strict -2 somefile.aac` - do you get xrun then? [16:26:46 CET] <MustBeLucky2> thank you debian user :) i will run this and see [16:31:46 CET] <durandal_1707> MustBeLucky2: that define is located in alsa.h [16:33:19 CET] <MustBeLucky2> Thank you durandal_1707. debianuser , thanks for this. Recording audio only to the file does not give me a xrun. I am going to try audio and video to file now. I think I may have an issue with crtmpserver [16:35:13 CET] <MustBeLucky2> I wish it would just reconnect when it hits an xrun. it stinks that it drops my audio all together. im sure this is for a reason though [16:38:05 CET] <MustBeLucky2> I get an xrun when recording video and audio to file. [16:38:05 CET] <debianuser> "xrun" is just an alsa warning (soundcard/driver writes data faster than ffmpeg can read it), but ffmpeg should automatically recover from it, skip some frames and continue recording. I mean it's not a good thing, but it's not a fatal error, audio stream should not be dropped because of that. [16:39:00 CET] <MustBeLucky2> strange, something else must becausing the audio to drop then, but the audio drops right around the time i hit the xrun [16:39:39 CET] <debianuser> check `top` while ffmpeg video+audio is running, maybe you have 100% CPU usage and just don't have enough resources to encode both video+audio at the same time? [16:41:18 CET] <debianuser> For a test you can try a smaller resolution, e.g. 320x240, it's not too useful for recording, but should use less cpu, check if your audio gets lost after that. [16:42:31 CET] <debianuser> MustBeLucky2: by the way, you said you get xrun when recording video and audio to file. Now try playing that file you recorded - does the audio gets lost there too? [16:44:19 CET] <MustBeLucky2> ok perfect thank you. Im surprised im not pulling more CPU on my Pi but it says im only at like 30% tops [16:44:37 CET] <MustBeLucky2> going to try smaller resolution .... how about bitrate? [16:44:42 CET] <MustBeLucky2> should i decrease that? [16:53:38 CET] <MustBeLucky2> so strange. It seemed pretty stable last night, now I cant get it to stay up for a few seconds [16:57:51 CET] <MustBeLucky2> durandal_1707, do you know if increasing that buffer changes my audio offset? [16:59:03 CET] <durandal_1707> no, never tried recording on current laptop [17:10:22 CET] <MustBeLucky2> can ALSA buffer xrun be cause by a crappy and noisy mic? [17:11:12 CET] <debianuser> no [17:11:25 CET] <debianuser> and if it could - you'd get it even when you record just audio and save it to a file [17:11:36 CET] <MustBeLucky2> ah [17:12:29 CET] <MustBeLucky2> well adding -thread_queue_size 1024 to video and audio input has kept the audio from dropping competely, but it bounces in and out [17:13:36 CET] <MustBeLucky2> nevermind it finally dropped [17:13:38 CET] <MustBeLucky2> :( [17:13:40 CET] <MustBeLucky2> shoot [17:22:12 CET] <debianuser> is the audio dropped if you save it to a file? [17:23:11 CET] <alexvf> hi, anyoone knows how can i totally flush a video decoder? avcodec_flush_buffers seems not enough [17:24:01 CET] <BtbN> recreate it [17:24:29 CET] <alexvf> is there no other way? [17:25:02 CET] <alexvf> i would like to reuse the same [17:26:59 CET] <alexvf> to recreate the AVCodecContext, it seems i have to call avformat_open_input again, which is slow for my needs [18:06:42 CET] <fred1807> can mp4 be VP9 ? [19:11:28 CET] <t4nk095> hey there. i got a quick question regarding ffmpeg and subtitles. I need to create a prores master with burned in subtitles. is there any way i can tell ffmepg to output the same video&audio container&codec which is the input? i mean a pass-through but burn in the subtitles at the same time. also how do i style and position the subtitles? any help is much appreciated :) greetings from munich [19:12:02 CET] <BtbN> you can't burn in without re-encoding [19:14:03 CET] <kline> hi, recently ive been having some issues with recording - specifically ffmpeg seems to stop being able to record after the second frame. the last warning is that there may be an issue with my swscaler settings, but i ask it to actually not scale (as far as i can see), so im not sure what to investigate from here. the full log is at https://paste.debian.net/899533/ [19:15:58 CET] <BtbN> something sent an SIGINT, so it exited. [19:16:03 CET] <kline> you can see on line 38 that something very suspect is going on, but im not sure how to interpret it myself or go about investigating it. this line used to work to record decent mkvs, but im not sure what changed some time in the past month or so in the end [19:16:19 CET] <kline> and yes, i send sigint after running it for a minute or so to generate the log [19:16:29 CET] <kline> (via ctrl+c) [19:16:56 CET] <kline> i can hit Q to stop it as well if you'd rather i do that for logs [19:18:07 CET] <roxlu> hey! I'm using ffmpeg in my C++ app. When I try to decode a .mp4 file (that was created using Quicktime on Mac), I get lots and lots of errors like: https://gist.github.com/roxlu/ae6e2e4fb06992da91bc8ac36c9ddd6f [19:18:08 CET] <thebombzen> kline: try using -c copy -f null -. see if it's an encoder issue [19:19:05 CET] <kline> cool. in the meantime i terminal recorded to show what it looks like, but i dont think its that much more interesting: https://asciinema.org/a/3ouawqojmni2opwyjfdg8b8uk [19:20:39 CET] <thebombzen> kline: it's also possible it's a problem with your video drivers. what card do you have and what driver are you using? [19:21:23 CET] <thebombzen> I was having trouble running x11grab with nouveau, just as example. I had to switch to the proprietary nVidia drivers to get it to work nicely. [19:22:48 CET] <kline> thebombzen, sorry, im not a big user of ffmpeg, can you clarify what that would look like in the context of the original line? as for driver, i have `Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)` as my "card", and `i965-va-driver` for amd, version 1.4.1-2 [19:23:11 CET] <kline> basically, its a fairly standard debian on intel thinkpad x240 [19:23:54 CET] <thebombzen> I mean ffmpeg -f x11grab -video_size 1366x768 -framerate 60 -i :0.0 -c copy -f null - [19:24:33 CET] <thebombzen> the -c copy says "don't reencode." the -f null is the "null format" which discards all output and doesn't write it to any file. [19:25:01 CET] <kline> https://paste.debian.net/899535/ [19:26:37 CET] <thebombzen> that sounds like a bug, but it doesn't occur in my FFmpeg build and I build it every night [19:26:49 CET] <kline> frustratingly, this used to work, but i use ffmpeg infrequently enough that i dont know what has since changed :( [19:27:14 CET] <thebombzen> try a minimal build from git master and see what happens [19:27:56 CET] <thebombzen> it's nice that Debian has switched off libav [19:31:26 CET] <kline> oh, hm, i think that might have been the breaking point. did this happen after the 4th october? [19:32:05 CET] <kline> i found a video i captured from that date (including build flags i think) but i'm still picking apart the frames to see what version it was etc [19:34:37 CET] <t4nk095> I know I have to re-encode, I just want the output to be the same codec as the input. prores in -> burn in subtitles -> prores out. can ffmpeg read the detail of the input file and use that to create the output? [19:34:48 CET] <kline> argh, the version numbers dont appear in any frame, too much is flushed to the console at once and by the next frame theyve fallen off the top [20:02:45 CET] <c_14> t4nk095: no, you'll have to script that (or use the libraries) [20:04:16 CET] <t4nk095> I suppose copy stream wont do the job? :D [20:04:30 CET] <furq> not if you want to burn in subtitles [20:19:31 CET] <t4nk095> any ideas why this wont work? "ffmpeg -i input.mov -vcodec prores-ks profile: hq -acodec copy -vf subtitles=sub.srt output.mov" [20:23:19 CET] <c_14> profile: hq isn't an option [20:23:29 CET] <c_14> did you mean -profile hq ? [20:23:31 CET] <c_14> maybe [20:29:37 CET] <t4nk095> I want to encode a ProRes 422 (HQ). But "-profile hq gives me: "Please use -profile:a or -profile:v, -profile is ambiguous" [20:30:16 CET] <durandal_1707> so add :v [20:32:47 CET] <t4nk095> which returns "Unknown encoder 'prores-ks'" :D [20:33:17 CET] <c_14> prores_ks [20:36:49 CET] <t4nk095> awesome! [20:37:49 CET] <t4nk095> is there a comparison between prores_ks and_aw somewhere? [20:42:12 CET] <durandal_1707> ks have finertia control versus quality iirc [22:47:19 CET] <Mista-D> get constant errors in MPEG2 VIDEO and xerror is not exiting. IF AC3 error is encountered, then xerror works. Please advise if there's any method to increase "xerror" sesitivity to video errors? `ffmpeg -i bad.ts -an -f null -strict very -xerror -" = no errors detected by xerror due to "-an" switch... [23:03:18 CET] <Mista-D> "-err_detect +explode " has no effect, exit status code is 0 and xerror is not exiting... [23:15:52 CET] <Hello71> how do I make showspectrum move faster? [23:31:19 CET] <Guest94097> can someone tell me what the command is for ffmpeg to taking a mpts and output a spts? [23:42:22 CET] <lvella> when encoding MPEG-2, what is the smallest unit contained in a AVPacket? [23:42:28 CET] <lvella> is it a picture? [23:43:12 CET] <lvella> or a picture may be broken between AVPackets ? [23:43:25 CET] <DHE> There should be a 1-to-1 correlation between AVPackets and AVFrames (though not necessarily in order) [23:44:16 CET] <lvella> in interlaced mode, an AVFrame contains one interlaced field? [23:46:38 CET] <DHE> I believe 1 AVFrame contains both fields [23:50:49 CET] <JEEB> DHE: that depends on the format [23:51:12 CET] <JEEB> although if we're talking about mpeg-2 video encoding most likely what you say is true [23:51:31 CET] <JEEB> HEVC decoder for example outputs fields separately if they are coded as separate pictures (which they mostly are) [23:52:04 CET] <kerio> ew interlaced video [23:52:43 CET] <lvella> kerio: not my fault, I didn't write the norms [23:53:49 CET] <DHE> Keridos: over-the-air broadcasts are almost universally 1080i. frequently in mpeg2 as well... [23:55:24 CET] <lvella> so, in interlaced mode both fields are inside a single AVPacket? [23:56:05 CET] <lvella> that would mean fields can't be reordered for better compression, right? [23:57:03 CET] <lvella> I mean, inside the GOP [00:00:00 CET] --- Tue Nov 29 2016

1 0

ffmpeg-devel.log.20161127
by burek 28 Nov '16

28 Nov '16

[00:30:16 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:230c04e3f6d7: aiffdec: fix division by zero [00:30:17 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:b3991ccd1170: astdec: fix division by zero [00:30:18 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:d4f64a0f545e: westwood_aud: prevent division by zero [00:30:19 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:d69dc10466e2: avformat: prevent triggering request_probe assert in ff_read_packet [00:30:20 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:13f032abbb26: rsd: limit number of channels [00:30:21 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:2c52b7498014: aiff: check block_align in aiff_read_packet [00:30:22 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:d77684b85305: dcstr: fix division by zero [00:30:23 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:72f1701c92f7: cavsdec: unref frame before referencing again [00:30:24 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:facf964d37ea: mpeg12dec: unref discarded picture from extradata [00:30:25 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:5ede8a9d8c26: interplayacm: check for too large b [00:30:26 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:d6fbc7a2daf0: interplayacm: validate number of channels [00:30:27 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:5a1433b19ab3: interplayacm: increase bitstream buffer size by AV_INPUT_BUFFER_PADDING_SIZE [00:30:28 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:e3f671b10140: ppc: pixblockdsp: do unaligned block accesses correctly again [00:30:29 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:cb0b8182448c: diracdec: check return code of get_buffer_with_edge [00:30:30 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:1af13ea53930: lzf: update pointer p after realloc [00:30:31 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:50d34cbf5ac8: mxfdec: fix NULL pointer dereference [00:30:32 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:a40189348710: mpegaudio_parser: don't return AVERROR_PATCHWELCOME [00:30:33 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:c19e9657049d: matroskadec: fix NULL pointer dereference in webm_dash_manifest_read_header [00:30:34 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:e1c1cb4aa148: mpegts: prevent division by zero [00:30:35 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:356e035773aa: icodec: fix leaking pkt on error [00:30:36 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:6a7f0585ab19: icodec: add ico_read_close to fix leaking ico->images [00:30:37 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:1499f65ad42a: escape124: reject codebook size 0 [00:30:38 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:727ec4acc471: proresdec_lgpl: explicitly check coff[3] against slice_data_size [00:30:39 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:5c2e26275cb1: dvbsubdec: fix division by zero in compute_default_clut [00:30:40 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:c35a140e7171: icodec: correctly check avio_read return value [00:30:41 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:eaf79ac2d9c1: smvjpegdec: make sure cur_frame is not negative [00:30:42 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:a5ba9eab44da: pnmdec: make sure v is capped by maxval [00:30:43 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:52d8c1e474c3: filmstripdec: correctly check image dimensions [00:30:44 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:d000e66c4f2f: softfloat: handle -INT_MAX correctly [00:30:45 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:89a22d3fbff3: libschroedingerdec: don't produce empty frames [00:30:46 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:f70e9726dcad: libschroedingerdec: fix leaking of framewithpts [00:30:49 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:71378e7937bd: exr: fix out-of-bounds read [00:30:49 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:cb936d62664c: exr: reindent after previous commit [00:30:49 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:b4f42e5c85f5: ffmdec: validate codec parameters [00:30:50 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:315f1dea84a3: mxfdec: fix NULL pointer dereference in mxf_read_packet_old [00:30:51 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:53e1493cb5a0: smacker: limit recursion depth of smacker_decode_bigtree [00:30:52 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:e2de6f31c0db: rmdec: validate block alignment [00:30:53 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:312757eb848b: sbgdec: prevent NULL pointer access [00:30:54 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:9b506280dd9b: pgssubdec: only set w/h/linesize when allocating data [00:30:55 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:d0f8741a5a29: flvdec: require need_context_update when changing codec id [00:30:56 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:e70caba38480: libopusdec: default to stereo for invalid number of channels [00:30:57 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:5d1502d4b68c: softfloat: decrease MIN_EXP to cover full float range [00:30:58 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:072246993acb: mss2: only use error correction for matching block counts [00:41:16 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:0009cf348aa8: avformat: prevent triggering request_probe assert in ff_read_packet [00:41:17 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:1d439041ece0: cavsdec: unref frame before referencing again [00:41:18 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:30d542d55ddb: mpeg12dec: unref discarded picture from extradata [00:41:19 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:a1e6daeb1e92: interplayacm: check for too large b [00:41:20 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:aa32d4152756: interplayacm: validate number of channels [00:41:21 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:aca7f5f06077: interplayacm: increase bitstream buffer size by AV_INPUT_BUFFER_PADDING_SIZE [00:41:22 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:087b77741526: ppc: pixblockdsp: do unaligned block accesses correctly again [00:41:23 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:dcc8d2418aca: diracdec: check return code of get_buffer_with_edge [00:41:24 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:ef2d91e9c337: lzf: update pointer p after realloc [00:41:25 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:e78d9f3f35e3: mxfdec: fix NULL pointer dereference [00:41:26 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:e6197a6ce986: mpegaudio_parser: don't return AVERROR_PATCHWELCOME [00:41:27 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:5801482379cb: matroskadec: fix NULL pointer dereference in webm_dash_manifest_read_header [00:41:28 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:3d82cebdd2bd: mpegts: prevent division by zero [00:41:29 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:c3307f7e9e18: icodec: fix leaking pkt on error [00:41:30 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:05e6606ba98a: icodec: add ico_read_close to fix leaking ico->images [00:41:31 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:e14cc2f1975b: escape124: reject codebook size 0 [00:41:32 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:416a8a06b977: proresdec_lgpl: explicitly check coff[3] against slice_data_size [00:41:33 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:27888d13b8d3: dvbsubdec: fix division by zero in compute_default_clut [00:41:34 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:3047b0a4a3e7: icodec: correctly check avio_read return value [00:41:35 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:69673d02790f: smvjpegdec: make sure cur_frame is not negative [00:41:36 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:b32c9941a21e: pnmdec: make sure v is capped by maxval [00:41:37 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:e93934e100d4: filmstripdec: correctly check image dimensions [00:41:38 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:48496e4d4fad: softfloat: handle -INT_MAX correctly [00:41:39 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:57665e04e22a: libschroedingerdec: don't produce empty frames [00:41:40 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:4ffd5805af4a: libschroedingerdec: fix leaking of framewithpts [00:41:41 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:1c282152c1c7: mxfdec: fix NULL pointer dereference in mxf_read_packet_old [00:41:42 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:48d24cca1308: smacker: limit recursion depth of smacker_decode_bigtree [00:41:43 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:80b85300ae0b: sbgdec: prevent NULL pointer access [00:41:44 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:5d2f1ffef1f2: pgssubdec: only set w/h/linesize when allocating data [00:41:45 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:dbad79248704: libopusdec: default to stereo for invalid number of channels [00:41:46 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:88bf1d274962: softfloat: decrease MIN_EXP to cover full float range [00:41:47 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:0496403c08ab: mss2: only use error correction for matching block counts [00:41:48 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:45b18fbb9a77: rsd: limit number of channels [00:41:49 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:e8ab2bd2ac85: dcstr: fix division by zero [00:41:50 CET] <cone-780> ffmpeg 03Mark Harris 07release/3.0:9375a7d85e8b: avformat/icodec: Fix crash probing fuzzed file [00:48:32 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:e14da0578c85: avformat: prevent triggering request_probe assert in ff_read_packet [00:48:33 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:51ff17d6b993: cavsdec: unref frame before referencing again [00:48:34 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:c5fb9df38aac: mpeg12dec: unref discarded picture from extradata [00:48:35 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:a94f846e2dba: ppc: pixblockdsp: do unaligned block accesses correctly again [00:48:36 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:0e8c44076d31: diracdec: check return code of get_buffer_with_edge [00:48:37 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:0cc619e0d756: mxfdec: fix NULL pointer dereference [00:48:38 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:f964046c58fb: mpegaudio_parser: don't return AVERROR_PATCHWELCOME [00:48:39 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:3148d1c25f22: matroskadec: fix NULL pointer dereference in webm_dash_manifest_read_header [00:48:40 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:b3ac458a5a20: mpegts: prevent division by zero [00:48:41 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:dc821d42a2fd: escape124: reject codebook size 0 [00:48:42 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:5c55f9881ed0: proresdec_lgpl: explicitly check coff[3] against slice_data_size [00:48:43 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:2260c0776ac6: dvbsubdec: fix division by zero in compute_default_clut [00:48:44 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:8a56b31e7cd1: icodec: fix leaking pkt on error [00:48:45 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:71fa32bbb747: icodec: correctly check avio_read return value [00:48:46 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:f76947fd567f: smvjpegdec: make sure cur_frame is not negative [00:48:47 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:0b948b1b8d10: pnmdec: make sure v is capped by maxval [00:48:48 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:ccda73a711ba: softfloat: handle -INT_MAX correctly [00:48:49 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:70ca4ce17a0a: libschroedingerdec: don't produce empty frames [00:48:50 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:7552f6fc1bbb: libschroedingerdec: fix leaking of framewithpts [00:48:51 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:8f27508f1cad: mxfdec: fix NULL pointer dereference in mxf_read_packet_old [00:48:52 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:8a7b2fbf6f4d: smacker: limit recursion depth of smacker_decode_bigtree [00:48:53 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:22cd4aa22116: sbgdec: prevent NULL pointer access [00:48:54 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:56b120630fd2: libopusdec: default to stereo for invalid number of channels [00:48:55 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:b45e112bbdcc: softfloat: decrease MIN_EXP to cover full float range [00:48:56 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:028c87be95dd: mss2: only use error correction for matching block counts [00:48:57 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:d8ec9e97b93e: filmstripdec: correctly check image dimensions [00:48:58 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:970781f5f29d: Update Changelog [01:50:59 CET] <Compn> https://en.wikipedia.org/wiki/Eggnog [04:08:30 CET] <cone-849> ffmpeg 03Michael Niedermayer 07master:a06e84b56e93: avformat/utils: Fix type mismatch [05:02:54 CET] <FishPencil> Can anyone point me in the direction of the code that handles decoding/playing hdmv_pgs subtitles (sup subtitles). They are found in blurays. [05:18:51 CET] <Compn> FishPencil : [05:19:31 CET] <Compn> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/pgssubdec.c [05:20:26 CET] <Compn> i think is what you want [05:20:48 CET] <FishPencil> Yes, thank you [05:24:18 CET] <FishPencil> I'm having a hard time finding an official specification for that format. Seems odd that the most popular bluray subtitle format is not documented [05:42:37 CET] <kierank> FishPencil: iirc it's in the blu-ray spec [05:42:39 CET] <kierank> which is not public [06:25:19 CET] <Compn> FishPencil : we might be able to get you access to that spec [06:25:21 CET] <Compn> if you need it [06:29:21 CET] <FishPencil> Compn: Thanks, I'm getting by so far though. [11:45:23 CET] <cone-894> ffmpeg 03Michael Niedermayer 07ffmpeg:HEAD: avformat/utils: Fix type mismatch [11:46:15 CET] <cone-894> ffmpeg 03Paul B Mahol 07master:4719e563a423: avfilter/vf_zscale: export approximate gamma option and enable it by default [11:47:41 CET] Action: michaelni looks at "<cone-894> ffmpeg Michael Niedermayer ffmpeg:HEAD: avformat/utils: Fix type mismatch" and wonders who and what caused that [11:48:58 CET] <BtbN> that's weird indeed [11:51:46 CET] <michaelni> whoever did this: " * [new branch] ffmpeg -> origin/ffmpeg" <--- please dont do that and j-b please remove this branch [11:54:47 CET] <durandal_1707> michaelni: i pushed to ffmpeg branch, stupid me [11:54:59 CET] <durandal_1707> maybe that is [11:55:56 CET] <michaelni> durandal_1707, if j-b doesnt remove it then please try to find another videolan root like thresh to get this cleaned [11:59:31 CET] <durandal_1707> j-b, thresh: please remove ffmpeg branch from existence [12:07:19 CET] <BtbN> can't it be removed remotely? [12:13:38 CET] <durandal_1707> no, we are not alfa and omega of vlc [13:05:35 CET] <nevcairiel> BtbN: destructive operations are forbidden, so no [13:07:27 CET] <cone-894> ffmpeg 03Anton Khirnov 07master:6a4e24280dd7: configure: check for stdatomic.h [14:18:45 CET] <cone-894> ffmpeg 03Michael Niedermayer 07master:bc9eb0467a52: Revert "ffserver: use AVStream.codecpar in open_input_stream()" [14:18:46 CET] <cone-894> ffmpeg 03Michael Niedermayer 07master:9478bd87d463: ffserver: Remove extract_mpeg4_header() [15:39:51 CET] <cone-894> ffmpeg 03Michael Niedermayer 07master:d9883ded3450: avcodec/me_cmp: Fix median_sad size [17:08:46 CET] <nevcairiel> philipl: did you notice, they released video codec sdk 7.1 [17:11:04 CET] <nevcairiel> although it doesnt seem to include any new output formats [17:11:53 CET] <BtbN> that's probably as pre-release as it gets [17:13:17 CET] <nevcairiel> 7.1 changelog is pretty short, just some encoder optimizations [17:13:26 CET] <nevcairiel> 8.0 is probably going to come with the next cuda release [17:53:14 CET] <philipl> the feature matrix shows 10bit decoding. [17:53:27 CET] <philipl> i will need to download and see the headers [17:53:37 CET] <BtbN> still only NV12 in those [17:53:50 CET] <philipl> feature matrix also shows vp8 10/12bit decoding. umm..... [17:53:58 CET] <BtbN> well, decoding. [17:54:04 CET] <BtbN> It can do that with only NV12 output [17:54:49 CET] <philipl> vp8... not 9... [18:04:43 CET] <philipl> They've added a cuvidInit(unsigned int flags) declarations with no docs and no flags. [18:04:46 CET] <philipl> Hrm. [18:10:59 CET] <BtbN> That's from their own dynloader, the function that loads the functions. [18:11:07 CET] <BtbN> That's not new [18:12:58 CET] <philipl> ah. ok. [18:13:50 CET] <philipl> Then the only difference is some semi colons [18:14:26 CET] <BtbN> yes, the headers seem unchanged [18:14:40 CET] <BtbN> Maybe they forgot updating them...? [18:15:41 CET] <philipl> A common problem, it seems. [18:15:55 CET] <philipl> the programming guide wasn't updated and there is still no decode api reference. [18:16:27 CET] <philipl> They've also redone their ffmpeg page. It now uses scale_npp in the examples and their multi-output stuff is a small section at the bottom. [18:29:46 CET] <nevcairiel> the feature matrix showed 10bit and 12bit decoding before the update, they probably have the new woutput format in the 8.0 update which also gets high bitdepth encoding, or so they say [18:39:45 CET] <philipl> I expect so. [18:40:14 CET] <philipl> So this sdk update is basically pointless. They haven't documented or officially exposed most of the stuff that's in the new drivers. [18:40:17 CET] <philipl> Why not just wait? [18:42:00 CET] <nevcairiel> probably had it scheduled for a while [18:42:03 CET] <nevcairiel> you know how these thigns go [18:42:18 CET] <BtbN> it's even version 7.1.9 [18:57:02 CET] <philipl> Yeah. It's just amusing. Still, the web page feature matrix is better designed than the old one. That's a real improvement (modulo the strange claims about 10/12bit vp8) [18:57:39 CET] <nevcairiel> maybe it works, the cuvid headers have vp8 [18:58:04 CET] <philipl> I wasn't aware 10/12 were defined for vp8. [18:58:06 CET] <nevcairiel> although they probably meant vp9 and just missed the row [18:58:22 CET] <philipl> That's what I hope. Certainly 10bit vp9 doesn't Just Work(tm) today. [18:58:37 CET] <nevcairiel> 10-bit vp9 presumably needs a 1050 [18:58:52 CET] <nevcairiel> or 1050 Ti [18:58:52 CET] <BtbN> oh great, that bullshitty situation again [18:59:04 CET] <philipl> You know this? They rev'ed the decoder hardware again? [18:59:24 CET] <nevcairiel> its not too special, 6 months older hardware gets a 6 month newer decoder [18:59:29 CET] <philipl> or is that a cynical, but accurate, prediction? [19:01:27 CET] <philipl> The linux driver readme, which is usually accurate about this stuff, lists the 1050 and 1050ti as using the same 'H' hardware as the other 10x0 parts. [19:01:50 CET] <philipl> So I'll continue hoping the 10bit vp9 is in there somewhere. [19:02:05 CET] <nevcairiel> all i know is that on the newest windows drivers, 10bit vp9 works on 1050, not any of the others [19:02:09 CET] <nevcairiel> might be driver fluke [19:02:13 CET] <philipl> ugh. [19:02:16 CET] <nevcairiel> and appear next driver [19:02:19 CET] <JEEB> \o/ [19:02:20 CET] <nevcairiel> or they typoed the linux readme [19:02:26 CET] Action: JEEB just IYH'd himself a GTX 1080 [19:03:03 CET] <philipl> Hopefully it's lagging the driver. They put effort into this part of the readme. They document hardware revisions with features that aren't exposed in drivers. [19:03:15 CET] <philipl> So I doubt they'd fudge it and call 1050 'H' if it's really 'I' [19:03:32 CET] <nevcairiel> maybe the doc writer wasnt told [19:03:40 CET] <philipl> but if that's what they did, then sad panda. [19:04:09 CET] <philipl> when you say works in windows, do you mean with cuvid or dxva? [19:04:14 CET] <nevcairiel> dxva [19:04:19 CET] <nevcairiel> possibly cuvid as well, who knows [19:04:27 CET] <nevcairiel> untested [19:04:28 CET] <nevcairiel> :) [19:04:38 CET] <philipl> Motivated enough to try it? It should all work correctly now. [19:04:39 CET] <BtbN> you have a vp9 10 bit sample? [19:04:44 CET] <JEEB> yeah, there's no real reason for CUVID nowadays [19:04:45 CET] <philipl> any youtube hdr sample [19:04:46 CET] <nevcairiel> i dont have a 1050 personally [19:04:49 CET] <philipl> ah [19:04:50 CET] <JEEB> DXVA2 works well enough [19:05:22 CET] <philipl> JEEB: on windows :-) [19:05:31 CET] <philipl> On linux, this is all we've got, given how vdpau is going nowhere. [19:05:40 CET] <JEEB> yup [19:07:29 CET] <fritsch> there is a chance for vdpau [19:07:32 CET] <fritsch> a quite easy one [19:07:42 CET] <fritsch> (besides the fact that it needs x11) [19:08:06 CET] <fritsch> if ckoenig from amd or someone of us would add the 10 bit hevc variants [19:08:13 CET] <fritsch> radeon could implement them first [19:08:40 CET] <fritsch> problematic currently is the "interop" for presenting ... as it's 8 bit only and needs some internal driver logic to do the conversation [19:08:46 CET] <philipl> fritsch: it would still require nvidia to put work into their own drivers. [19:08:56 CET] <fritsch> the idea behind that is: [19:08:59 CET] <fritsch> don't support nvidia :-) [19:09:04 CET] <fritsch> just make vdpau great on radeon oss [19:09:12 CET] <fritsch> they will do it themselves - I am quite sure [19:09:32 CET] <fritsch> my experience from the past: force vendors to standards ... if not - you implement "yet another decoder" [19:09:38 CET] <fritsch> especially on linux [19:10:17 CET] <wm4> fritsch: at this point I'd rather have everything support libva [19:10:36 CET] <fritsch> hehe - talk with ckoenig about vaapi [19:10:39 CET] <philipl> wm4: that really is a sign of the apocalypse. [19:10:46 CET] <fritsch> it's highly, highly tight to intel hw [19:10:57 CET] <fritsch> for example mpeg-4 will never work on anything not intel [19:11:17 CET] <BtbN> youtube-dl doesn't seem to be aware of the 10 bit formats [19:11:22 CET] <BtbN> still get vp9 profile 0 [19:11:44 CET] <philipl> BtbN: youtube-dl -F tO01J-M3g0U [19:11:48 CET] <philipl> see the vp9.2 entries [19:12:01 CET] <philipl> Note you cannot let youtube-dl remux video+audio, it will drop the hdr metadata. [19:12:06 CET] <nevcairiel> youtube-dlk works for me if you request the proper thing [19:12:10 CET] <philipl> but the video stream has it [19:12:48 CET] <BtbN> I should probably update it [19:12:58 CET] <fritsch> wm4: and for libva no reply for the libdrm / mesa changes [19:13:28 CET] <philipl> fritsch: I assume you continue to have no interest in cuvid support in kodi? With the dynamic loading approach, it could be done without introducing any external dependencies. [19:13:51 CET] <fritsch> we don't have the manpower to maintain yet another decoder in kodi [19:14:06 CET] <fritsch> if you send a PR it can be discussed obviously [19:14:22 CET] <fritsch> we currently don't even have HW to finish vaapi 10 bit [19:14:37 CET] <philipl> I've been contemplating it. Still trying to understand all the points you have to hook in [19:14:39 CET] <fritsch> (render part), decoder is well done in ffmpeg [19:14:49 CET] <philipl> each of the existing hwaccels is handled a bit differently from each other [19:15:01 CET] <fritsch> for kodi the critical part is the rendering [19:15:05 CET] <fritsch> "zero copy" [19:15:06 CET] <fritsch> if possible [19:15:14 CET] <fritsch> for vdpau we use glinterop [19:15:23 CET] <fritsch> for vaapi we use drm / dma_buf / mesa [19:15:29 CET] <fritsch> what would cuvid provide? [19:15:35 CET] <philipl> It has its own glinterop [19:15:39 CET] <philipl> I implemented it for mpv [19:15:52 CET] <fritsch> how do you transfer the 10 bit surfaces? [19:16:31 CET] <philipl> You get a P010 buffer in GPU memory from cuvid, then map your GL texture using interop and copy from one to the other. [19:17:09 CET] <fritsch> can you link me to the code? [19:17:50 CET] <philipl> https://github.com/mpv-player/mpv/blob/master/video/out/opengl/hwdec_cuda.c [19:18:09 CET] <philipl> It's mostly surface bit depth transparent. [19:18:38 CET] <BtbN> Just copy-back to system would be fine and trivial to implement [19:18:53 CET] <fritsch> CUDA_MEMCPY2D <- [19:18:55 CET] <philipl> As a first pass, yes. [19:19:01 CET] <fritsch> that looks like a deep copy [19:19:04 CET] <philipl> It is. [19:19:09 CET] <fritsch> we don't want that :-) [19:19:12 CET] <philipl> zero-copy is massively complicated [19:19:21 CET] <BtbN> it's impossible to avoid one copy out of the mapped buffer [19:19:33 CET] <philipl> Technically it's two copies today. [19:19:44 CET] <fritsch> which hw supports cuvid? [19:19:46 CET] <philipl> could be reduced to one but it's too much work and requires a new pix_fmt in avcodec [19:19:46 CET] <fritsch> which nvidia? [19:19:54 CET] <BtbN> all? [19:19:59 CET] <philipl> all recent. [19:20:01 CET] <philipl> kepler+ [19:20:12 CET] <BtbN> Everything that runs a recent driver [19:20:14 CET] <fritsch> we still need to run on GT520 or higher [19:20:20 CET] <fritsch> ION-2 would also be great [19:20:28 CET] <philipl> vdpau covers those. [19:20:30 CET] <fritsch> and i am quite sure ION-2 is not fast enough to do the copy [19:20:40 CET] <fritsch> yeah - then we need to maintain yet another codec [19:20:41 CET] <philipl> cuvid is only interesting if the hardware is new enough to have features outside the vdpau set [19:20:48 CET] <philipl> yes. but you need that for radeon, right? :-P [19:21:14 CET] <fritsch> in 2k16 with all the infrastructure available it feels wrong to support yet another blob [19:21:23 CET] <fritsch> and gpu intensive copies [19:21:37 CET] <BtbN> the copy is basically free [19:22:13 CET] <nevcairiel> on-gpu copies are indeed rather cheap [19:22:48 CET] <philipl> cheap enough that BtbN and nevcairiel think I'm crazy for doing all the work I did to demonstrate how to eliminate one of the copies. [19:22:57 CET] <nevcairiel> indeed =p [19:23:44 CET] <BtbN> For kodi it would be trivial to add basic support for cuvid decoding. Just treat it as software decoder with a diffrent name. [19:24:20 CET] <fritsch> oki - if you want to implement that - we can discuss it on github [19:24:22 CET] <BtbN> I don't think more is really possible anyway, as it needs CUDA SDK function [19:25:02 CET] <philipl> BtbN: what do you mean 'more'? More than software decoding? [19:25:25 CET] <philipl> dynlink works just fine for the interop stuff. I added that to mpv too [19:25:28 CET] <philipl> Shouldn't need sdk [19:25:47 CET] <philipl> Certainly on linux, I don't need sdk installed. [19:25:57 CET] <BtbN> but you need function from CUDA [19:26:02 CET] <BtbN> to map it to a texture and stuff [19:26:08 CET] <BtbN> which is in the licensed header [19:26:43 CET] <philipl> BtbN: yes. and just like the you did for the basic calls, they can be reverse-engineered from the docs [19:27:01 CET] <fritsch> basically for vdpau (for the basics) [19:27:07 CET] <fritsch> we need: two defines [19:27:36 CET] <BtbN> cuvid does not work like vdpau. It's implemented as complete decoder, no hwaccel [19:27:59 CET] <philipl> more like mediacodec than anything else. [19:28:12 CET] <fritsch> mediacodec :-) [19:28:22 CET] <fritsch> some of us think about using ffmpeg's mediacodec in the future [19:29:48 CET] <philipl> probably a good idea now that it's actually functional. [19:33:04 CET] <philipl> but yeah, to BtbN's point - even without interop, it makes a big difference. On my skylake i7 rig with mpv playing 10bit hevc: cuvid+interop: 25%, cuvid-only: 90%, software: 600% and too slow to actually play. [19:33:42 CET] <JEEB> and with HEVC that's probably even bigger for sw [19:33:50 CET] <JEEB> since the VP9 decoder has gotten quite a bit of love [19:33:55 CET] <JEEB> as far as asm goes [19:34:54 CET] <philipl> JEEB: indeed. a vp9 10bit sample is 250% for software decoding. [19:35:33 CET] <fritsch> philipl: yes - I am well aware [19:35:40 CET] <fritsch> we can better copy than decode [19:35:59 CET] <wm4> fritsch: did you end up using ffmpeg's videotoolbox support? [19:36:06 CET] <fritsch> yes [19:36:13 CET] <fritsch> I think so at least [19:36:17 CET] <fritsch> on ios afaik [19:36:23 CET] <fritsch> let me have a look [19:36:34 CET] <ubitux> you shouldn't use ffmpeg's VT support for iOS [19:36:47 CET] <ubitux> it's not fast enough [19:36:55 CET] <fritsch> https://github.com/xbmc/xbmc/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/V… [19:37:05 CET] <ubitux> like, about half the performances you should expect from it [19:38:46 CET] <fritsch> i am not really informed what they use on ios [19:39:42 CET] <fritsch> but can't find anything else [19:41:09 CET] <wm4> ubitux: isn't that because of async mode [19:41:10 CET] <fritsch> we dropped our own baked one, yes [19:41:13 CET] <fritsch> https://github.com/xbmc/xbmc/commit/ebefcd0c62689579b6c013e5d1b32f58cea23b37 [19:41:17 CET] <ubitux> wm4: yes that's the sole reason [19:41:27 CET] <fritsch> and use ffmpeg's one - without many compliants [19:41:45 CET] <wm4> ubitux: the painful thing is that the hwaccel impl. (probably) can't be made async... [19:42:03 CET] <ubitux> yes i'm aware of the issue [19:42:24 CET] <ubitux> alternative is to have packet reordering in a decoder [19:42:30 CET] <fritsch> let me ask a dump question: is that a problem, when decoder and render are run in different threads? [19:42:40 CET] <fritsch> for our use case [19:43:18 CET] <ubitux> shouldn't be a problem with VT [19:43:56 CET] <fritsch> as we really got no one complaining [19:44:07 CET] <mateo`_> same for mediacodec [19:44:14 CET] <ubitux> you can't decode 240 fps with ffmpeg's vt [19:44:22 CET] <fritsch> we don't need that [19:44:23 CET] <ubitux> not sure you can even hold 120 fps [19:44:35 CET] <ubitux> well, the iphone supports it [19:44:48 CET] <fritsch> yeah - see we are a video player [19:44:58 CET] <fritsch> and render thread is driven by vblank [19:45:21 CET] <fritsch> but yeah, the more the better of course :-) [19:45:22 CET] <ubitux> if you want to play 240 fps in real time you have to drop ref frame [19:45:39 CET] <wm4> fritsch: no, not a problem with different render threads [19:45:52 CET] <wm4> but that the VT decoder operates most efficiently in async mode [19:45:54 CET] <wm4> for whatever reason [19:45:54 CET] <fritsch> ubitux: obviously clear - I just tried to make up a reason - why no one complained yet [19:46:22 CET] <ubitux> if you capture a 240 fps footage with the iphone and can't play it back it's problematic [19:46:30 CET] <wm4> and we use the hwaccel infrastructure with VT (for frame reordering basically), which can't be made async [19:46:31 CET] <ubitux> play it back in real time that is [19:46:34 CET] <ubitux> not slowmo [19:46:40 CET] <fritsch> jep - I hear you [19:46:53 CET] <fritsch> if I give the same guy a 300 fps footage [19:46:59 CET] <fritsch> he also can't watch it :-) [19:47:10 CET] <ubitux> except the iphone actually creates 240 fps footages [19:47:28 CET] <fritsch> so you decode the 240 fps [19:47:29 CET] <ubitux> so you're saying users can't watch videos they capture with the same device [19:47:32 CET] <fritsch> and render 60 fps? [19:47:39 CET] <fritsch> e.g. you skip quite intelligently? [19:47:39 CET] <ubitux> you can't decode @ 240 fps [19:47:47 CET] <ubitux> with ffmpeg's VT [19:47:49 CET] <fritsch> jep [19:48:01 CET] <ubitux> (unless you drop ref frame) [19:48:01 CET] <fritsch> you can with the async code and so on [19:48:25 CET] <fritsch> currently I have no problem stating, that kodi can only do 120 fps [19:48:28 CET] <fritsch> with vtb [19:49:11 CET] <wm4> so I wonder why vtb needs this async mode [19:49:11 CET] <fritsch> we are happy for every ffmpeg hwaccel codec that allows us dropping on own hacks [19:49:30 CET] <fritsch> as kodi is running out of devs :-( [19:49:31 CET] <wm4> oh, another problem: deinterlacing [19:49:46 CET] <fritsch> i think we support "render bob" [19:49:52 CET] <fritsch> ugly :-) [19:49:58 CET] <fritsch> but better than nothing [19:50:10 CET] <wm4> heh [19:50:22 CET] <fritsch> that's funny with mediacodec btw. [19:50:29 CET] <wm4> vtb apparently does hw deint in the decoder [19:50:30 CET] <fritsch> they don't even support interlace in any documentation [19:50:32 CET] <wm4> which is hitler [19:50:45 CET] <fritsch> ... [19:51:06 CET] <ubitux> they do pixel format convert too [19:51:25 CET] <wm4> oh I think rcombs found out how to determine the native VT pixfmt [19:51:30 CET] <ubitux> (and scaling) [19:51:34 CET] <wm4> have to ask him about that later [19:51:44 CET] <ubitux> oh? that's interesting [19:51:44 CET] <BtbN> cuvid also deinterlaces in the decoer. [19:52:07 CET] <wm4> ubitux: especially because the ideal pixfmt changes with the hw [19:52:17 CET] <wm4> older hw apparently prefers packed yuv [19:52:19 CET] <ubitux> i'm and the footage i suppose [19:52:39 CET] <wm4> I wonder if vtb will support 10 bit [19:52:51 CET] <wm4> btw. why the fuck does apple not have its own consumer videocodec yet? [19:52:54 CET] <nevcairiel> its always funny how apple manages to make everything special [19:52:59 CET] <wm4> since they NIH everything anyway [19:53:17 CET] <ubitux> they NIH *badly* everything [19:54:14 CET] <philipl> BtbN: do you have coverity access? [19:54:30 CET] <BtbN> Not that I'm aware of [19:54:46 CET] <philipl> michaelni: can you add BtbN? [19:54:59 CET] <BtbN> Isn't that in pretty bad shape at the moment anyway? [19:55:02 CET] <philipl> There are a few warnings coming back for the cuda related parts [19:55:17 CET] <philipl> It is, based on the email but the results are meaningful when a report does get generated. [19:55:24 CET] <michaelni> BtbN, i need an emai addy to add IIRC [19:55:39 CET] <BtbN> timo(a)rothenpieler.org [19:55:58 CET] <philipl> michaelni: https://scan.coverity.com/travis_ci [19:56:20 CET] <philipl> Maybe we can set up travis for ffmpeg and have that run coverity for us [19:57:13 CET] <michaelni> BtbN, invite sent [20:01:54 CET] <BtbN> It claims ctx in cuvid_transcode_init leaks its storage [20:01:57 CET] <BtbN> but it doesn't. [20:02:56 CET] <michaelni> 50-60% or so what coverity says is probably wrong [20:03:16 CET] <philipl> BtbN: There is a path through there that leaks it. The question is whether you'd ever hit that path. [20:03:34 CET] <philipl> line 99: it allocates ctx [20:04:03 CET] <philipl> if ctx->hw_frames_ctx was not null, it would leak it. [20:04:13 CET] <philipl> but if you allocated ctx, then hw_frames_ctx must be null [20:04:18 CET] <philipl> I'm surprised it can't pick that up [20:04:24 CET] <philipl> probably because of av_mallocz [20:04:49 CET] <philipl> If it was using calloc, it would probably know [20:05:36 CET] <philipl> There's probably a way to tell coverity what av_mallocz is. [20:05:36 CET] <BtbN> it seems to be aware of that being an allocation function [20:05:36 CET] <michaelni> maybe something needs to be added to tools/coverity.c (and the new file uploaded) [20:05:55 CET] <philipl> yeah. [20:05:58 CET] <philipl> for mallocz [20:06:12 CET] <BtbN> ah, but it's not aware that stuff in ctx will allways be zero if it comes out of that branch [20:06:22 CET] <BtbN> so it will allways be entered when it was allocated previously [20:06:43 CET] <philipl> right. [20:06:44 CET] <BtbN> yeah, it's going through a path that's impossible [20:06:56 CET] <philipl> Let me update coverity.c [20:07:15 CET] <BtbN> to tell it av_mallocz returns zero initialized stuff? [20:07:26 CET] <philipl> yep [20:07:47 CET] <philipl> and we probably should mark that av_free should be used to free this stuff. [20:07:52 CET] <philipl> I've found examples. [20:08:14 CET] <BtbN> The one in hwcontext_cuda seems right [20:10:03 CET] <superware> hello, this defect https://trac.ffmpeg.org/ticket/5615 is quite old, although it's very easy to reproduce, any idea why it wasn't touched at all? :| [20:12:25 CET] <nevcairiel> issues get fixed as someone is interested in working on them [20:15:48 CET] <superware> yes well, anyone interested? :) [20:40:51 CET] <superware> nevcairiel: can you please reproduce this? simply open a non-existing UDP input such as udp://127.0.0.1:8000 and avformat_open_input will hang... [20:43:01 CET] <BtbN> well, it will wait for packets [20:46:20 CET] <superware> BtbN: but it doesn't return even when interrupt_callback.callback returns 1.. [20:46:42 CET] <cone-713> ffmpeg 03Clément BSsch 07master:5d7be07a8b82: lavfi/f_ebur128: relicense to LGPL [20:48:13 CET] <superware> "During blocking operations, callback is called with opaque as parameter. If the callback returns 1, the blocking operation will be aborted." [20:49:22 CET] <BtbN> If it's stuck in system io without a defined timeout, nothing will get it out of that easily [20:50:09 CET] <nevcairiel> superware: i am not interested in network stuff, so no [20:51:11 CET] <superware> BtbN: well, a) interrupt_callback.callback IS being repeatedly called, b) you might have just described the bug source :) [20:51:24 CET] <superware> nevcairiel: ok, thanks anyway [20:53:17 CET] <kierank> you've got to use thread cancellation for that [20:53:53 CET] <kierank> or better still nonblocking io [20:54:52 CET] <superware> I have no idea what avformat_open_input is doing with "udp://127.0.0.1:8000" [20:57:06 CET] <kierank> waiting for udp packets I guess [20:58:08 CET] <superware> can you please take a look at why interrupt_callback.callback returning 1 doesn't abort it? [20:58:23 CET] <kierank> no [21:01:04 CET] <superware> oh well [21:05:48 CET] <superware> thanks anyway, bye [22:04:30 CET] <Chloe> philipl: travis on GH is great fun [22:13:31 CET] <philipl> Chloe: is that actual fun or sarcastic fun? [22:13:53 CET] <Chloe> I think it's actual fun, it works the most out of all the CIs. [22:14:54 CET] <BtbN> it might be kind of annoying to setup all the dependencies on there every single time [22:15:06 CET] <BtbN> specially as they run on quite outdated ubuntu versions [22:15:29 CET] <Chloe> trusty isn't *that* old [22:15:49 CET] <philipl> It's just part of the yaml file. There's a ppa that has all the dependencies in it. [22:15:53 CET] <BtbN> oh, they finally arrived in 2014? [22:15:59 CET] <philipl> Two weeks ago [22:16:14 CET] <BtbN> Should have just gone for 16.04 right away [22:16:21 CET] <philipl> anyway, it's worth a try. Keeping a hardware box alive for this is nuts in this day and age. [22:16:41 CET] <philipl> BtbN: indeed. 2.5 years to update is nuts. [22:17:12 CET] <BtbN> could also just run your own docker image on it [22:17:35 CET] <philipl> yes, but I wouldn't do that if I could get their trusty container to work. Simpler and faster [22:18:00 CET] <BtbN> docker is probably faster [22:18:06 CET] <BtbN> it comes pre-installed and it's just a single command [22:20:32 CET] <philipl> they are presumably using docker for their container build environment. [22:20:55 CET] <philipl> dont want to nest or force the use of a vm to host the container. [22:22:06 CET] <Chloe> philipl: they use docker by default, but you can ask for a VM [22:22:57 CET] <BtbN> from my experience, the VMs run better and a lot faster [22:23:03 CET] <BtbN> And you can then run your own docker container on it. [22:25:32 CET] <Chloe> The docker configured & built FFmpeg in 3min50sec, which is pretty good IMO. [22:25:41 CET] <Chloe> travis' docker* [22:28:17 CET] <BtbN> it's about preparing all the dependencies it needs for the coverity run [22:34:30 CET] <philipl> well, i'll try it out once i get access [22:35:29 CET] <Chloe> you don't need access to try it out [22:36:19 CET] <BtbN> well, you can only set it up with a fork [22:39:01 CET] <philipl> yes, i can. [22:39:05 CET] <Chloe> yeah, that's what I'm trying [22:54:34 CET] <Chloe> philipl: which PPA are you looking at? https://launchpad.net/~mc3man/+archive/ubuntu/trusty-media doesn't have many of the dependencies [22:59:28 CET] <Timothy_Gu> michaelni: fatebeta/v3.2 seems to exist now... [23:00:03 CET] <Chloe> philipl: don't worry. You wanted to do this first, I'll stop. If you want someone to have a look at it as well, I don't mind. [23:00:04 CET] <michaelni> Timothy_Gu, yes, it seems no client tested 3.2 [23:00:20 CET] <Timothy_Gu> huh? http://fatebeta.ffmpeg.org/v3.2 shows a bunch of clients [23:00:29 CET] <michaelni> yes, now [23:00:34 CET] <Timothy_Gu> ok [23:00:52 CET] <Timothy_Gu> Chloe: 3min50sec on sudo: false? [23:01:05 CET] <Chloe> yeah [23:01:25 CET] <philipl> Chloe: it's got a decent number. It's where I intend to start. [23:01:48 CET] <Chloe> Timothy_Gu: I don't really have anything to compare it to other than my personal build times which are ~25min [23:01:58 CET] <Chloe> (at best) [23:02:03 CET] <Timothy_Gu> wasn't on IRC a few minutes ago but http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203491.html might be of interest [23:02:22 CET] <Timothy_Gu> Chloe: ok that's better than I thought [23:02:37 CET] <Timothy_Gu> see https://travis-ci.org/TimothyGu/FFmpeg/builds/114093334 which takes 18 min to build+run FATE [23:02:49 CET] <Timothy_Gu> but that was 9 months ago [23:03:09 CET] <philipl> Chloe: if you want to run with this, feel free. [23:03:36 CET] <Timothy_Gu> but I think Docker on their Trusty platform is probably the best way to get out of the deps situation [23:03:37 CET] <philipl> Timothy_Gu: the lack of pre-packaged dependencies is a concern but it's no worse than if you were not using travis. You have to deal with it anyway. [23:03:47 CET] <Chloe> Timothy_Gu the full build time, with FATE + packaging/upload of sample cache was 9 mins [23:04:02 CET] <Timothy_Gu> philipl: yeah, but then you only have to install it once as opposed to every single run [23:04:10 CET] <Chloe> philipl: the alternative to to build everything from source [23:04:28 CET] <Timothy_Gu> and plus there are multiple points of failure if you are installing the packages from source [23:04:30 CET] <Chloe> sure it'd make build times massive, but if it's only going to be build twice a week then it doesn't matter [23:04:31 CET] <philipl> Chloe: yeah, but if we can use packages, so much the better. [23:04:49 CET] <philipl> Timothy_Gu: you could build a base docker image and use that, but then you have to maintain it. [23:05:11 CET] <philipl> I'd rather just have the one script and do install/build of dependencies as necessary. As Chloe says - if it's infrequent, it doesn't matter. [23:05:16 CET] <BtbN> Timothy_Gu, the problem is with some non-redistributable deps [23:05:27 CET] <BtbN> I don't think it's possible to do that on such kind of public infrastructure. [23:05:42 CET] <philipl> BtbN: depends on what they are. eg: cuda can be installed from canonical repositories. [23:05:55 CET] <Chloe> someone has probably already made a docker image for building ffmpeg [23:06:10 CET] <BtbN> not with _all_ deps [23:06:28 CET] <philipl> and frankly, you need to decide what your goal is. coverity coverage without building all deps is still useful and you aren't getting windows coverage anyway. [23:06:39 CET] <Chloe> BtbN: of course, but I mean there's no reason to start from scratch [23:06:40 CET] <BtbN> why not? [23:06:41 CET] <Timothy_Gu> philipl: I'd rather go with a Docker image as you can control the installation process easily [23:06:47 CET] <philipl> There's no point paralysing yourself because you can't get 100% dep coverage [23:06:59 CET] <BtbN> There are free Windows CI services. [23:07:04 CET] <philipl> BtbN: travis has no windows offering [23:07:10 CET] <Timothy_Gu> If you mean AppVeyor, it sucks [23:07:11 CET] <philipl> I wouldn't want to use two CI services [23:07:20 CET] <Chloe> Timothy_Gu: indeed, but it does work. [23:07:28 CET] <BtbN> AppVeyor works fine for one of our projects at work [23:07:58 CET] <Timothy_Gu> It's the amount of time you have to wait for a single build to start, only to see it failing because of some stupid dependency problem 2 minutes into the build [23:08:08 CET] <Timothy_Gu> then you have to wait 30+ minutes for it to restart [23:08:12 CET] <BtbN> you will have to use the non-docker travis infrastructure anyway, as you can't freely install packages on the docker based one. [23:08:14 CET] <Chloe> Timothy_Gu: once you get that all fine though, it's alright [23:08:21 CET] <BtbN> So you can just go for docker directly [23:08:22 CET] <philipl> BtbN: you can. [23:08:33 CET] <Chloe> philipl: they have to be whitelisted though [23:08:33 CET] <BtbN> If the package you want happens to be on their witelist. [23:08:41 CET] <Timothy_Gu> BtbN: You can install APT packages on sudo: false [23:08:49 CET] <Timothy_Gu> they added it a few months ago [23:08:53 CET] <BtbN> Only if they are whitelisted iirc [23:08:53 CET] <Timothy_Gu> some "addons" thing [23:09:05 CET] <Chloe> (only if they're whitelisted by travis) [23:09:06 CET] <Timothy_Gu> Yeah, but their whitelist is pretty generoud IIRC [23:09:11 CET] <Timothy_Gu> *generous [23:09:15 CET] <Chloe> sure, but if you look at the backlog [23:09:17 CET] <Chloe> lol. [23:09:20 CET] <BtbN> Won't cover our exotic dependencies [23:09:30 CET] <philipl> eh. I didn't realise the whitelist problem. [23:09:31 CET] <BtbN> Like, CUDA for example, or zimg [23:09:46 CET] <philipl> So sure, if you're stuck using a VM, then yes, run a yakkety container inside it [23:09:53 CET] <BtbN> So just go for sudo: true, and prepare a Docker-Image elsewhere [23:10:07 CET] <philipl> You can prepare the docker-image inline. [23:10:30 CET] <BtbN> why would you do that? Can just have it pre-built on Docker Hub [23:10:56 CET] <philipl> And then you have to ask how do I build and update the docker container. [23:11:04 CET] <philipl> You need a separate set of build jobs for that [23:11:07 CET] <jamrial> michaelni: looks like you accidentally created an "ffmpeg" branch on the repo [23:11:12 CET] <BtbN> you push an updated Dockerfile to some repo [23:11:14 CET] <Chloe> I have 0 experience with docker though so probably better if someone else did it [23:11:26 CET] <BtbN> Docker Hub builds it for you then [23:11:31 CET] <philipl> hrm. [23:11:39 CET] <durandal_1707> jamrial: that was me [23:11:40 CET] <Chloe> jamrial: I dont think it was michaelni, and I think it was passed on to the videolan peeps to be removed. [23:11:51 CET] <jamrial> oh, i see [23:12:05 CET] <Chloe> you may want to chase that though, not sure if they saw it [23:12:07 CET] <Timothy_Gu> Wait who's running the GitHub mirror except for me? [23:12:14 CET] <Chloe> Timothy_Gu: no one [23:12:34 CET] <Timothy_Gu> ...ok sometimes I see commits pushed by other people [23:12:34 CET] <Chloe> oh, llougan and michaelni [23:12:35 CET] <jamrial> sorry. saw the latest commit from that branch was michaelni's so i assumed he pushed it by mistake [23:13:05 CET] <Chloe> Timothy_Gu: could you close the PRs/issues on the gh mirror? [23:13:22 CET] <Timothy_Gu> They keep popping up... [23:13:35 CET] <Chloe> dont close #153 though [23:14:20 CET] <Chloe> although you should probably lock it for good measure [23:14:42 CET] <Chloe> I added a CONTRIBUTING.md a little while back, but there were still PRs even after it was added... [23:15:25 CET] <Timothy_Gu> Exactly [23:15:44 CET] <Timothy_Gu> We might need .github/PULL_REQUEST_TEMPLATE.md [23:16:11 CET] <Timothy_Gu> Like https://help.github.com/articles/creating-a-pull-request-template-for-your-… [23:16:45 CET] <BtbN> that also won't stop people. [23:17:38 CET] <Chloe> Timothy_Gu: if you're going to create a PULL_REQUEST_TEMPLATE.md then move CONTRIBUTING.md into the .github dir too [23:19:02 CET] <Timothy_Gu> philipl: I guess we can start with an image that only contains packaged deps and go from there [23:19:12 CET] <Timothy_Gu> did anyone volunteer? [23:21:06 CET] <Timothy_Gu> We also need to migrate fate.ffmpeg.org to a new server as it still runs Precise ... [23:22:24 CET] <Chloe> I can't docker, sorry. [23:22:48 CET] <BtbN> It's just a shell script that installs stuff on whatever base system you like. [23:22:58 CET] <philipl> Timothy_Gu: I can start putting together a Dockerfile [23:23:07 CET] <Chloe> BtbN: I have no means of testing [23:23:31 CET] <BtbN> Just install docker locally [23:23:52 CET] <Chloe> which requires a VM, I can't run VMs. [23:24:02 CET] <Timothy_Gu> there's docker for mac these days i think [23:24:03 CET] <BtbN> They are not VMs, just containers. [23:24:32 CET] <BtbN> There's Docker for any major OS [23:24:47 CET] <Chloe> Timothy_Gu: which runs a VM [23:25:58 CET] <Timothy_Gu> oh ok [23:26:02 CET] <Chloe> BtbN: sure, but docker runs a VM to run the containers in. My hardware is too old to run VMs [23:26:42 CET] <BtbN> At least on Linux it definitely does not do anything like that. [23:26:48 CET] <JEEB> well that's what it actually is [23:26:52 CET] <Timothy_Gu> BtbN: he uses a Mac I think [23:27:05 CET] <JEEB> the "docker for !linux" stuff is basically a VM in which it then runs docker [23:27:25 CET] <JEEB> because docker kind of bases on linux kernel stuff :P [23:27:44 CET] <Timothy_Gu> and I would start doing something related to this but today is the last day of the Thanksgiving break so... [23:27:47 CET] Action: JEEB has mostly poked systemd-nspawn out of the "container" things [23:28:03 CET] <JEEB> (fancy name for chroot and namespaces) [23:29:17 CET] <cone-713> ffmpeg 03Michael Niedermayer 07master:102f7d0ee62e: avformat/rmenc: Check framerate before storing [23:29:18 CET] <cone-713> ffmpeg 03Michael Niedermayer 07master:55997d50431c: tests/ffserver.conf: Force bitexactness in the ffmpeg command [23:35:10 CET] <philipl> there's no 'enable-all' type thing is there? [23:35:54 CET] <nevcairiel> everthing is enabled by default, unless it requires external things [23:36:07 CET] <philipl> to be sure [23:47:34 CET] <cone-713> ffmpeg 03Andreas Cadhalpun 07master:801b5c18c7be: pngdec: check if previous frame exists instead of trusting sequence_number [23:53:41 CET] <philipl> install 1042 packages. weee [00:00:00 CET] --- Mon Nov 28 2016

1 0

ffmpeg.log.20161127
by burek 28 Nov '16

28 Nov '16

[01:02:12 CET] <Hello71> how do I make showspectrum go faster [01:18:49 CET] <ffmpeg529> hi, i want to record my voice for long so that whenever I talk it record my voice and whenever I stoped talking it get pause , I searched but couldn't find a good method plz help me [01:20:39 CET] <klaxa> https://ffmpeg.org/ffmpeg-filters.html#silenceremove ? [01:23:02 CET] <ffmpeg529> can u say how to use it by a simple example ? [01:23:55 CET] <ffmpeg529> is it possible to use it while i'm recording audio ? [01:25:06 CET] <klaxa> maybe? give it a try, to process a recording i would think: ffmpeg -i input.ogg -filter_complex "silenceremove=0:0:0:-1:1:-90dB" output.ogg [01:25:23 CET] <klaxa> taken from the example section below [01:26:26 CET] <ffmpeg529> ok thank you klaxa :) [02:22:00 CET] <Kadigan_KSB> ffmpeg529: what you want is a feature called voice activity detection. I'm seeing libspeexenc (Speex) having some features related to that - VAD and DTX. The first simply lowers bitrate to almost nonexistent when recording background noise. The second attempts to write only one frame when no voice activity is detected. It needs the external Speex library to encode, however. [02:22:16 CET] <Kadigan_KSB> Oh, he's gone. [03:58:53 CET] <fling> Is not lossless H.264 crop possible? [04:00:35 CET] <klaxa> not lossless? so lossy? [04:01:45 CET] <c_14> fling: not with ffmpeg [04:02:02 CET] <fling> What is so special about avchd? [04:03:48 CET] <fling> Which app will you suggest for cropping? [04:04:53 CET] <fling> How to reencode to the same codec with all the same parameters like colorspace and everything? [04:10:09 CET] <DHE> there's no guaranteed way to get the exact same settings. matching the profile and bitrate are your best hopes. [04:10:23 CET] <DHE> x264 does put encoding options metadata into streams which you might be able to pull [04:37:49 CET] <Kadigan_KSB> fling: you should generally get the same colorspace and bitness coming out as going in, unless a) the selected codec requires a change (of which you may be informed), or b) you specify a different color space outright [04:38:10 CET] <Kadigan_KSB> IIRC ffmpeg preserves as much of the original as it can, and that includes keeping the parameters unless otherwise noted/changed [04:44:17 CET] <Etienne> Hey guys, where can I find detailed specifications for the FFM live stream format? [05:39:13 CET] <mozzarella> hello [06:12:37 CET] <snacks> hey, I have some questions about looping videos: If I have a video that's the exact same thing repeated over and over, how much extra filesize does each loop take up? Also, what if the video and audio are both looped, but not synced with eachother? [06:13:46 CET] <fling> snacks: each loop takes slightly less space than the first one (depending on codec) [06:14:13 CET] <fling> snacks: works the same for video and audio. [06:15:09 CET] <snacks> what I mean is e.g. the video is a 5-second loop and the audio is a 7-second loop [06:15:52 CET] <snacks> so if the audio and video are stored together, they can't be considered a "loop" per se [06:16:14 CET] <snacks> not until the 35-second mark at least [06:20:24 CET] <snacks> also, is there a way to use `-stream_loop -1` to make both the 5-second video and 7-second audio loop on their own loops? [06:20:31 CET] <snacks> or some equivalent [06:20:41 CET] <snacks> tbh the documentation is kind of conflicting and lacking [06:21:28 CET] <furq> you probably want the loop/aloop filters [06:30:10 CET] <fling> snacks: or you could just loop your inputs [06:34:10 CET] <snacks> fling: I'm considering it, but the problem is that I want to seamlessly loop an e.g. 20 second gif and an e.g. 3m17s song, which could triple++ the filesize [06:34:34 CET] <snacks> idk though, maybe I'm just optimising prematurely [06:35:39 CET] <fling> snacks: are you about to use gif video in the output file? [06:36:32 CET] <fling> snacks: or is gif your input? [06:36:44 CET] <fling> snacks: tell me what the output actually is. [06:43:44 CET] <snacks> fling: basically, take a link like https://gifsound.com/?gif=file-9gag-lol.9cache.com/file/28ekK318Q8/ezgif-30… , wget the gif, youtube-dl the sound, then put it into a looping video like on the webpage. [06:44:05 CET] <snacks> except without the "gif and youtube video load/play at different rates" problem [06:44:36 CET] <snacks> because obviously, a .webm will play at the speed a .webm will play, it won't generally desync the audio and video [06:45:10 CET] <snacks> also, it means I don't have to worry about youtube videos being DMCA'd and losing the gifsound as a result [06:46:32 CET] <fling> snacks: so what is your output? [06:46:46 CET] <snacks> fling: A video? [06:46:58 CET] <snacks> fling: I'm not sure what question you're asking. [06:46:59 CET] <fling> snacks: a video file? Which codec? gif or not? [06:47:48 CET] <snacks> fling: I'm not particularly picky on the codec, although webm would be nice. As long as it has both the video and audio and it loops, it's good. [06:49:10 CET] <snacks> fling: I'm assuming webm is a codec. [06:49:31 CET] <fling> snacks: define it loops [06:49:37 CET] <klaxa> not quite, it's a container format, vp8 or vp9 are the codecs webm can hold [06:50:00 CET] <fling> Let me explain what I understood from your messages [06:50:30 CET] <fling> Two inputs: 1. gif video: 2. an unknown codec audio [06:50:59 CET] <fling> One output: webm with vp8/9 video and audio copied as-is [06:51:12 CET] <fling> snacks: does this look correct to you? ^ [06:51:34 CET] <fling> snacks: the note is that the gif input should be looped prior encoding, right? [06:51:39 CET] <fling> snacks: is this what you want? :D [06:54:18 CET] <snacks> fling: Sort of. I want it so that if the video is run with 'mpv --loop=inf videoname', both the audio and video loop perfectly. [06:55:03 CET] <snacks> but [06:55:49 CET] <snacks> if I can't get that, then I guess I'd go with them both being looped for a few minutes and then one of them being cut off. [06:56:36 CET] <snacks> I pretty much want it to be just like the website I linked before, except, y'know, not on the website. [06:57:17 CET] <fling> snacks: I'm not using sites much. [06:57:23 CET] <fling> snacks: are you going to loop the audio too? [06:58:44 CET] <snacks> fling: ideally, yeah. [06:59:48 CET] <c_14> how long do you want the video to be? [07:00:28 CET] <snacks> well, other than filesize problems it doesn't really matter how long it is, if it's going to be looped anyway. [07:00:47 CET] <fling> ffmpeg -f concat -safe 0 -i <(for i in {1..9001};do printf "file '%s'\n" /tmp/test/girl.gif;done) -i 09\ =B@>.mp3 -c:v vp9 -c:a opus -t 10 test.webm [07:01:14 CET] <fling> snacks: ^ this one loops /tmp/test/girl.gif 9001 times , adds 09\ =B@>.mp3 audio and encodes 10 seconds from it to test.webm [07:01:24 CET] <fling> snacks: you could also loop the audio the same way [07:01:30 CET] <c_14> snacks: ffmpeg -loop 1 -i gif -i audio -c:a copy -c:v libvpx-vp9 -shortest out.webm <- probably better [07:01:37 CET] <fling> snacks: you could set how much seconds you need to encode with -t [07:01:41 CET] <c_14> If you want to loop the audio you'll have to do that like fling wrote [07:01:53 CET] <fling> snacks: listen to c_14 , good luck! :> [07:02:01 CET] <c_14> -shortest stops after the first stream ends [07:02:05 CET] <c_14> so it'll only loop one of them [07:02:15 CET] <c_14> if you want both to loop you'll have to calculate a duration and use -t [07:02:24 CET] <snacks> wait, is that actually looping the audio and video, or is it just concatenating it with itself a bunch before merging audio and video? [07:02:47 CET] <c_14> well, concating a video a bunch of times with itself is the same as looping it [07:02:49 CET] <fling> snacks: there is no _looping_ [07:03:08 CET] <fling> snacks: imaginary looping is a magical thing. [07:03:52 CET] <snacks> fling: You know how zip bombs work? I figured video formats might have something like that. [07:04:14 CET] <fling> snacks: they might have but not really. You need to research which codec is capable of doing so. [07:04:23 CET] <snacks> then again, maybe they don't because if they had zip-bomb-like stuff, then they would have *zip-bomb* like stuff. [07:04:59 CET] <fling> snacks: no, they don't because they are using motion detect like algos intead of zip bomb algo :P [07:05:37 CET] <snacks> motion detect-like algorithms? [07:05:59 CET] <snacks> isn't the entire point of the various video formats essentially just compression? [07:06:11 CET] <fling> snacks: btw -> 4,0M girl.gif ; 119K test.webm [07:06:31 CET] <fling> snacks: girl.gif is 2 seconds and no audio but test.webm is 10 seconds and has audio [07:06:46 CET] <fling> snacks: you could lower the bitrate to get desired bombing effect [07:07:06 CET] <snacks> fling: 'desired bombing effect'? [07:07:33 CET] <fling> snacks: you want the video to appear as a zip bomb which means it should use really low bitrate. [07:08:47 CET] <fling> snacks: so the decoded video from a small file will be really huge in comparison. [07:09:07 CET] <fling> snacks: I hope you got your answer! :P [07:09:16 CET] <snacks> fling: what I mean by 'zip bomb' is that there are .zip files that can store, like, 1000TB (!!) of 'data' in a 2KB file. They can do this because essentially the zip format uses pointers internally, so they can make it repeat the same data a HUGE number of times without any real gain in filesize of the zip [07:09:57 CET] <snacks> pointers and some recursion-oriented Fun, iirc [07:10:18 CET] <fling> snacks: then you should find a codec capable doing this fun. [07:10:45 CET] <fling> snacks: x264 is good for the situation when your dupes are going one aftear another. [07:10:56 CET] <fling> snacks: but ffv1 is not for example [07:11:16 CET] <furq> x264 probably won't make much difference [07:11:18 CET] <fling> snacks: I don't know which codec is good for dupes in loops [07:11:19 CET] <snacks> is there some sort of codec database? [07:11:34 CET] <snacks> or wiki [07:11:35 CET] <fling> snacks: ffmpeg -codecs [07:12:01 CET] <furq> regardless, if you want this to play in browsers your realistic choices are x264 and vp9 [07:12:17 CET] <fling> snacks: also `man ffmpeg-codecs` [07:12:18 CET] <snacks> furq: I don't want to play it in a browser [07:12:26 CET] <furq> why else would you use webm [07:12:34 CET] <fling> lunchtime! [07:12:36 CET] Action: fling disappears [07:12:59 CET] <snacks> furq: because IIRC mp4 is patented or something? [07:13:09 CET] <furq> sure, but who cares [07:13:23 CET] <furq> if you're not distributing the files for money it doesn't matter [07:14:19 CET] <snacks> idk, it just seems useful, it's more of a vague preference than actually caring [07:14:33 CET] <snacks> avi et al are fine [07:14:59 CET] <snacks> like I said, I'm not informed enough to have any hard preferences [07:15:02 CET] <snacks> other than gif [07:15:15 CET] <snacks> ...obviously, I mean [07:15:25 CET] <snacks> AFAIK gif doesnt support sound anyway [07:15:40 CET] <furq> it doesn't and also it's generally pretty terrible [07:15:44 CET] <snacks> exactly [07:16:40 CET] <snacks> I want to avoid gif because duh, and I would much prefer something that isn't ridiculously obscure, but other than that I'm not picky [07:18:15 CET] <furq> just use x264 [07:18:49 CET] <snacks> okay, x264 it is. Why x264? [07:19:07 CET] <furq> it's efficient, widely used and fast [07:21:03 CET] <furq> ffmpeg -ignore_loop 0 -i src.gif -i src.m4a -c:v libx264 -c:a copy -shortest dest.mp4 [10:53:08 CET] <chang> is there a way to show at which date my ffmpeg executable was compiled? [11:11:51 CET] <furq> chang: https://api.github.com/repos/FFmpeg/FFmpeg/commits/46aae84 [11:12:11 CET] <furq> not quite the same but that'll show you how old your git build is [11:18:34 CET] <chang> furq: ffmpeg doesn't really seem to like "m" as a bitrate multiplier? If I juse "50m" instead of "50000k" it kinda does it's own thing with ~11000k - but it doesn't print out any warnings or errors. Is that just a bug or does m mean something different? [11:19:07 CET] <furq> which codec [11:26:26 CET] <chang> furq: libx264 [11:29:21 CET] <furq> does the status bar say "q=0.0" [11:29:33 CET] <furq> if so then the quality is effectively maxed out [11:47:42 CET] <chang> furq: Nope http://pastebin.com/s5S4EFiM [11:49:16 CET] <chang> damn pastebin destroyed the output but oh well, you can see it's about q 26 [14:57:25 CET] <DHE> chang: 'm' means milli (1/1000), 'M' means mega (1000000) [15:04:21 CET] <chang> DHE: hmmm that explains a lot. Although it doesn't explain why ffmpeg doesn't complain about 50 millibits per second [15:04:42 CET] <kerio> ^-^ [15:16:27 CET] <DHE> I don't have an answer to that... [15:33:17 CET] <fling> How to install on trisquel? [16:00:01 CET] <furq> chang: evidently libx264 just ignores -b:v 50m [16:00:10 CET] <furq> so it uses the default, which is crf 23 [16:01:48 CET] <BtbN> it will probably be rounded to 0 [16:01:54 CET] <BtbN> and 0 is the default value [16:01:58 CET] <furq> yeah that could be it [16:02:02 CET] <BtbN> At least I think it is [16:02:05 CET] <furq> -b:v 1 throws an actual error [16:02:18 CET] <JEEB> libx264 takes bit rate in kilobits per second after all [16:02:28 CET] <JEEB> while libavcodec lets you set it on bits per second level [16:02:39 CET] <furq> yeah that'll be it [16:02:53 CET] <furq> -b:v 0.5 gets ignored, -b:v 0.500001 throws an error [16:03:48 CET] <JEEB> yeah, not sure how libavcodec deals with <1 [16:04:02 CET] <JEEB> that's a whole separate can of worms :3 [16:04:06 CET] <furq> is there any point having m be milli [16:04:19 CET] <furq> i assume it's for consistency with other options but idk which [16:04:25 CET] <JEEB> for timestuff probably [16:04:34 CET] <JEEB> it's probably a generic option parsing thing [16:04:46 CET] <JEEB> although to be fully honest I have NFI [16:04:59 CET] <furq> yeah i can't think of any options where that would make sense [16:05:22 CET] <furq> the only other option i can think of which takes prefixes is -ar [16:05:53 CET] <JEEB> suffixes you mean? [16:06:13 CET] <JEEB> k and M are the two I usually use anyways [16:06:13 CET] <furq> well milli- is the prefix [16:06:24 CET] <JEEB> but it's not mXXX in the parameter? [16:06:30 CET] <furq> but it's suffixed to the value [16:06:32 CET] <furq> so i guess either works [16:07:11 CET] <furq> https://en.wikipedia.org/wiki/Metric_prefix#List_of_SI_prefixes [16:07:19 CET] <JEEB> yeah, in language it's a prefix [16:07:26 CET] <JEEB> in the options it's suffixes [16:08:06 CET] <JEEB> so when we're talking of libav* options it's probably better to talk of suffixes, at least that's what I'm doing [16:09:00 CET] <furq> suffixed prefixes [16:11:24 CET] <furq> looks like you can't use them in duration specs anyway [16:34:11 CET] <DHE> furq: I'm guessing it rounds the bitrate to 0 which means unset/default [16:34:47 CET] <furq> deja vu [16:35:02 CET] <DHE> there's a bit of option parsing that interprets SI units, and Mi if you want 1M == 1048576 [16:35:06 CET] <DHE> err, 1Mi [16:35:19 CET] <DHE> so, yeah, consistency at its finest. I guess [16:35:32 CET] <furq> yeah i just don't know why you would bother parsing m as milli [16:35:54 CET] <furq> i didn't know you could use Mi though [16:36:31 CET] <Kadigan> furq: it might happen, I mean - k and g have one meaning, but m has several... [16:36:40 CET] <furq> well yeah it does happen [16:36:46 CET] <Kadigan> I can see it treating m vs M differently. [16:36:49 CET] <furq> it does [16:36:53 CET] <furq> this is what we've been discussing [16:37:00 CET] <furq> i just don't know what option that makes sense for [16:37:15 CET] <Kadigan> I don't see the point of 'm' when it comes to things like bitrate though... [16:37:24 CET] <furq> the only options i know of which take m don't accept values <1 anyway [16:37:39 CET] <Kadigan> Yeah. You know what? [16:37:53 CET] <Kadigan> That sounds like someone wrote the SI parsing and was very happy with themselves. [16:37:54 CET] <Kadigan> :D [16:38:03 CET] <furq> i think we might have a winner [16:38:19 CET] <furq> i absolutely have code which exists for that reason [16:38:59 CET] <Kadigan> Isn't most personal code more or less "because I can"? [16:39:07 CET] <Kadigan> Private projects, I mean. [16:39:21 CET] <furq> yeah granted i don't have a team of other devs asking me what the fuck i'm shitting up the ui for [16:39:31 CET] <furq> i assume that's the calibre of language they'd use [16:40:13 CET] <Kadigan> Well, I wouldn't normally see that sort of thing as problematic, but then I assume the person who wrote it had common sense enough to not include milli. [16:40:13 CET] <Kadigan> :D [17:36:40 CET] <ehsanv> Hi, showspectrum is available in my ffmpeg, but showspectrumpic is not! why? i'm using ffmpeg for windows. [18:03:04 CET] <AssPirate> s/(d.*?y)/1/ [18:03:16 CET] <AssPirate> nvm that [18:22:47 CET] <durandal_1707> ehsanv: old ffmpeg version? [20:17:35 CET] <superware> hello, this defect https://trac.ffmpeg.org/ticket/5615 is quite old, although it's very easy to reproduce, any idea why it wasn't touched at all? :| [22:14:16 CET] <soulshok> is it possible to use timestamp from input stream, to name files with the strftime using the timestamp from the input stream when writing to -segment format? [22:15:10 CET] <SouLShocK> i.e. name files output_2016_11_27_22_14_00.ts when input stream is at 22:14:00 [22:15:24 CET] <SouLShocK> instead of using local clock [00:00:00 CET] --- Mon Nov 28 2016

1 0

ffmpeg-devel.log.20161126
by burek 27 Nov '16

27 Nov '16

[02:19:11 CET] <cone-667> ffmpeg 03Steven Liu 07master:ee24c8ad0112: avformat/flvenc: fix ticket 5976 and use old commit [02:19:12 CET] <cone-667> ffmpeg 03Steven Liu 07master:7c5478a2035e: avformat/flvdec: move set bit_rate from parse AMF OBJECT to create_stream [04:10:54 CET] <cone-667> ffmpeg 03Steven Liu 07n3.2.1:HEAD: avformat/flvdec: move set bit_rate from parse AMF OBJECT to create_stream [04:29:24 CET] <cone-667> ffmpeg 03Steven Liu 07master:af7d0ad983a1: refine avformat/flvdec set bit_rate [11:15:49 CET] <Se7en> Hello. I have a (possible) bug report to file that I asked about in the main channel but it was dead. Is anyone here to answer me? [12:30:07 CET] <ubitux> http://b.pkh.me/wtf-gimp-new-image-template.png i think we need to update libavutil/parseutils.c to add that new format [12:31:46 CET] <cbsrobot_> ubitux: but how many layers ? [12:32:05 CET] <ubitux> @_@ [13:19:08 CET] <cone-363> ffmpeg 03Hendrik Leppkes 07master:36e27c87e7f0: vc1dec: support multiple slices in frame coded images with hwaccel [13:19:08 CET] <cone-363> ffmpeg 03Hendrik Leppkes 07master:99ee8ee0930b: dxva2_vc1: support multiple slices [15:47:58 CET] <cone-363> ffmpeg 03Shivraj Patil 07release/2.8:b9ec80322b5b: avutil/mips/generic_macros_msa: rename macro variable which causes segfault for mips r6 [15:47:59 CET] <cone-363> ffmpeg 03Moritz Barsnick 07release/2.8:d609986f3976: tools: fix grammar error [15:48:00 CET] <cone-363> ffmpeg 03Moritz Barsnick 07release/2.8:bb83ff8b4192: lavc: fix typos [15:48:01 CET] <cone-363> ffmpeg 03Moritz Barsnick 07release/2.8:b480ca4dbd4b: lavfi: fix typos [15:48:02 CET] <cone-363> ffmpeg 03Moritz Barsnick 07release/2.8:d1c87a4a6fd9: cmdutils: fix typos [15:48:03 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:865e3f5553e9: avcodec/utils: Clear MMX state before returning from avcodec_default_execute*() [15:48:04 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:8328c07fb13b: avcodec/mpegvideo_enc: Clear mmx state in ff_mpv_reallocate_putbitbuffer() [15:48:05 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:b9ab4db9f935: avformat/mxfdec: Check size to avoid integer overflow in mxf_read_utf16_string() [15:48:06 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:abe16359ba80: avcodec/interplayvideo: Check side data size before use [15:48:07 CET] <cone-363> ffmpeg 03Ronald S. Bultje 07release/2.8:e25441912baf: vp9: change order of operations in adapt_prob(). [15:48:08 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:3177ea512f4b: avcodec/dvdsubdec: Fix buf_size check [15:48:09 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:fe4c6aeb9935: avcodec/dvdsubdec: Fix off by 1 error [15:48:10 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:e3f8b322793d: avcodec/8bps: Check side data size before use [15:48:11 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:41b1ec081019: avcodec/cinepak: Check side data size before use [15:48:12 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:ef32b162e81a: avcodec/idcinvideo: Check side data size before use [15:48:13 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:09411a7d5e7c: avcodec/kmvc: Check side data size before use [15:48:14 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:f39522b6e75d: avcodec/msrle: Check side data size before use [15:48:15 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:1604a2b1e6c4: avcodec/qtrle: Check side data size before use [15:48:16 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:2312d1d97965: avcodec/qpeg: Check side data size before use [15:48:17 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:147a387fba2e: avcodec/msvideo1: Check side data size before use [15:48:18 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:744f78ce0dc5: avcodec/rawdec: Check side data size before use [15:48:19 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:3213adceb2a8: avcodec/tscc: Check side data size before use [15:48:20 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:f9e76d3304b7: avcodec/sunrast: Fix input buffer pointer check [15:48:21 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:63504a2d44e5: avcodec/movtextdec: Fix potential integer overflow [15:48:22 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:b0a5794e30d6: avcodec/movtextdec: Fix tsmb_size check==0 check [15:48:23 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:ecc5bada26f2: avcodec/movtextdec: Add error message for tsmb_size check [15:48:24 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:1e86f1a64690: avcodec/ituh263dec: Avoid spending a long time in slice sync [15:48:25 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:698528207ab8: avcodec/rv40: Test remaining space in loop of get_dimension() [15:48:26 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:13c249e2b5f1: avformat/mpeg: Adjust vid probe threshold to correct mis-detection [15:48:27 CET] <cone-363> ffmpeg 03Michael Niedermayer 07release/2.8:afd0f8f7750a: Update for 2.8.9 [21:31:34 CET] <Chloe> Can we put a timeline on the removal of FFserver? the removal was announced in July, there's definitely been enough time for someone to "refractor", move to another repo, or whatever. [21:34:48 CET] <atomnuker> Chloe: yeah, let's do it like late next week, Thursday maybe [21:35:19 CET] <atomnuker> reynaldo's still busy apparently and removing ffserver will only serve to motivate anyone who cares to fix it oustide [21:35:57 CET] <Chloe> atomnuker: Thursday sounds good. Can we clarify on what exactly will be removed? I'm not entirely sure about the APIs deprecated FFserver uses [21:37:44 CET] <atomnuker> yeah, ffserver goes first, the ffm muxer demuxer will go sometime after [21:38:21 CET] <BtbN> Wasn't it basically agreed on to do it next major bump? [21:38:33 CET] <atomnuker> before [21:49:57 CET] <wm4> why "sometimes after" [21:50:10 CET] <wm4> keeping the ffm muxer makes no sense without having ffserver [21:51:27 CET] <atomnuker> to do things one step at a time [21:52:31 CET] <Chloe> wm4: it also wasn't announced, which I guess is another issue [23:39:09 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07master:ff5f4bd97654: lavf: always forward codec_whitelist in avformat_find_stream_info [00:00:00 CET] --- Sun Nov 27 2016

1 0

ffmpeg.log.20161126
by burek 27 Nov '16

27 Nov '16

[00:02:12 CET] <furq> markvandenborre: what does ffprobe -show_streams say [00:19:15 CET] <markvandenborre> furq: checking [00:23:19 CET] <markvandenborre> furq: https://gist.github.com/markvdb/eff3ab32d72dccbd42ed596b818ff8de [00:23:50 CET] <markvandenborre> (note that I probably made some really silly codec settings mistakes) [00:27:26 CET] <markvandenborre> furq: the video gets generated by https://github.com/FOSDEM/video/blob/master/software/ansible/playbooks/role… [00:28:06 CET] <markvandenborre> then from the flv coming out of the streaming, it gets reprocessed into an mp4 container with the command [00:28:55 CET] <furq> are you getting errors other than non-monotonous dts [00:29:00 CET] <furq> you can usually ignore that one iirc [00:29:21 CET] <furq> and i think unsafe filename is just ffmpeg being overzealous [00:29:29 CET] <markvandenborre> yes, seems so [00:29:35 CET] <markvandenborre> ffmpeg -y -i $path -codec copy -movflags +faststart $dirname/$basename.mp4 [00:29:50 CET] <markvandenborre> is fairly generic also [00:30:01 CET] <markvandenborre> nothing much there that could cause trouble I guess [00:30:14 CET] <furq> if the video plays back correctly you can just ignore it i think [00:30:25 CET] <markvandenborre> the problem is it does not play back correctly of course [00:31:18 CET] <markvandenborre> these are not private videos, they're CC licensed, so if anyone wants a closer look [00:31:48 CET] <markvandenborre> I could just push them somewhere publicly accessible [00:32:28 CET] <markvandenborre> the preroll is a 720p jpeg basicly [00:32:52 CET] <markvandenborre> and an example of a video as generated by our encoders is at [00:34:30 CET] <markvandenborre> http://glasno.st/fosdem/video.mp4 [00:34:54 CET] <markvandenborre> let me check the errors I get when encoding again [00:41:14 CET] <markvandenborre> furq: it seems I could use the concat protocol, even if the wiki says it is a bit obsolete [00:42:52 CET] <furq> yeah i just tried remuxing that video to ts and concat worked fine [00:43:01 CET] <furq> the demuxer, i didn't try the protocol although that should work fine too [00:43:13 CET] <furq> that's a bunch of additional steps though [00:46:33 CET] <markvandenborre> let me also upload the image file with silent audio [00:47:18 CET] <markvandenborre> http://glasno.st/fosdem/prerollsilentaudio.mp4 [00:48:28 CET] <markvandenborre> I'm trying to document stuff a bit around https://github.com/FOSDEM/video/wiki/Ffmpeg:-concatenating-preroll-and-post… [00:48:48 CET] <markvandenborre> seems like the only option would be remuxing to mpeg ts [00:49:05 CET] <markvandenborre> or do you see any other option? [00:51:06 CET] <furq> http://vpaste.net/IG2q4 [00:51:11 CET] <furq> i did something like that [00:51:25 CET] <furq> concat with codec copying has always been a bit flaky, i don't know the internals well enough to suggest anything else [00:51:30 CET] <furq> i normally just work around it when it breaks [00:52:36 CET] <markvandenborre> thx for the hints [00:52:53 CET] <furq> the concat filter is much more reliable but i guess you don't want to reencode [00:56:07 CET] <markvandenborre> furq: we have > 500 hours of talks [00:56:21 CET] <markvandenborre> and we want to have them online asap when the conference is still running [00:56:50 CET] <markvandenborre> and a few other requirements that make us really not want toe reencode indeed [00:57:20 CET] <markvandenborre> in fact, we have a perfect ffmpeg script except for avoiding the reencoding [00:58:04 CET] <markvandenborre> if we avoid the reencode, we avoid lots of complexities in other places [00:58:22 CET] <markvandenborre> so if that means an ugly hack with fifos or temporary files, so be it I guess [00:59:18 CET] <markvandenborre> I will have another look one of the coming days, so if you have any inspiration come up about ways to avoid the mp4 to ts remux, you'll know where to find me :-) [00:59:21 CET] <markvandenborre> thx [03:20:20 CET] <mundus2018> Im looking for help converting a .dsf file to .flac [03:20:42 CET] <mundus2018> the dsf has an 88200Hz bitrate [05:29:26 CET] <tomed> would upgrading ddr4 see improvement in ffmpeg [11:08:06 CET] <Se7en> Hwllo. I have a possible bug rerport to file. I am not sure though. [11:08:50 CET] <Se7en> When attempting to play a file remotely (over an ftp:// URI) on MPV I was unable to. They report this is an issue with FFmpeg as the issue is replicated with ffplay [11:08:53 CET] <Se7en> The file was an Opus [11:09:07 CET] <Se7en> The person in the MPV chatroom was able to replicate it [11:09:15 CET] <Se7en> How do I generate the debugger output? [11:10:52 CET] <Se7en> If someone is here I can directly link the file [11:13:38 CET] <Se7en> Other files are opening so it's only the opus [11:22:55 CET] <durandal_1707> Se7en: if you try directly it also happens? [11:23:00 CET] <Se7en> Yes [11:23:05 CET] <Se7en> it can be replicated in ffplay [11:23:24 CET] <Se7en> The file is stupid, but it caused me to find the error in opus [11:23:26 CET] <Se7en> ftp://joelixny.ddns.net/Moon%20Man/Misc/MoonMan%20-%20The%20Real%20MoonMan-… [11:23:54 CET] <Se7en> That stupid meme of the McDonald's moon guy singing the racist songs [11:24:00 CET] <Se7en> But it brought me to discover the problem [11:24:33 CET] <durandal_1707> you mean if you even download it? [11:25:19 CET] <durandal_1707> I'm not right on computer but you can file bug report [11:26:25 CET] <Se7en> Actually, I haven't trierd that yet. One moment [11:26:51 CET] <Se7en> Downloading the file works fine, yeah [11:26:56 CET] <Se7en> Only when accessing vorbis remotely [11:26:59 CET] <Se7en> Other file types work [14:06:42 CET] <BlackFox> I have bit of a weird question [14:06:56 CET] <BlackFox> So there's a file with raw 264 stream, but seemingly there's also audio in that file [14:07:31 CET] <BlackFox> Is there any way to see or split the actual raw 264 stream (which plays just fine) from the audio that is embedded in some sort of weird way [14:07:46 CET] <techtopia> you want to demux it? [14:08:16 CET] <techtopia> ffmpeg -i file.h264 -vn -sn -acodec copy file.wav [14:08:30 CET] <techtopia> ffmpeg -i file.h264 -an -sn -vcodec copy file.h264 [14:08:44 CET] <techtopia> first will dump audio to wav second will dump video to h264 [14:08:52 CET] <techtopia> it's unlikely that it contains audio though [14:08:53 CET] <BlackFox> Gonna try that (but so far it just seems that audio is encoded in some weird way) [14:09:00 CET] <kerio> BlackFox: who said that there's audio in there? [14:09:02 CET] <BlackFox> It does contain audio (I was puzzled myself) [14:09:05 CET] <kerio> pastebin the output of ffprobe [14:09:31 CET] <BlackFox> There is a proprietary and very badly made tool that can play these files with audio (and it plays just from a single file), but... yeah, one sec [14:09:39 CET] <DeadSix27> BlackFox: do you have a audio file wiht the same name in the same folder? [14:09:44 CET] <DeadSix27> just to get that out of the way [14:09:53 CET] <techtopia> good thought DeadSix27 [14:10:14 CET] <BlackFox> DeadSix27, definitely no audio in the same folder, it's a good sanity check though [14:10:18 CET] <DeadSix27> kk [14:10:36 CET] <DeadSix27> (some players, considering we do not knwo which you used, just play the same-named audio along a video) [14:10:46 CET] <BlackFox> I don't know which one I used myself [14:11:05 CET] <BlackFox> It's literally "player.exe" and apparently came with some obscure dashcam someone had [14:11:16 CET] <DeadSix27> but ye, paste the ffprobe output as kerio said. [14:12:03 CET] <DeadSix27> (on pastebin*) [14:12:32 CET] <BlackFox> http://pastebin.com/bWgDcVKH [14:12:56 CET] <techtopia> there is no audio [14:13:05 CET] <DeadSix27> seemingly [14:13:11 CET] <kerio> :c [14:13:20 CET] <kerio> well, it might be some weird raw format [14:13:22 CET] <BlackFox> well yes, there can't be any audio in raw h264 stream, but somehow the player manages to play it given just one file [14:13:32 CET] <kerio> idk [14:13:33 CET] <BlackFox> so it's most definitely sticking audio somewhere unconventional [14:13:34 CET] <furq> do you have an audio file with the same filename [14:13:53 CET] <furq> mpc-hc will autoplay it if you do [14:13:56 CET] <furq> maybe some other players as well [14:14:01 CET] <DeadSix27> we furq, already mentioned that [14:14:06 CET] <DeadSix27> furq, we** [14:14:06 CET] <kerio> he's not using a real player [14:14:10 CET] <furq> oh so you did [14:14:11 CET] <kerio> it's some weird dashcam format [14:14:30 CET] <DeadSix27> kerio: wow you can see that just by that? [14:14:30 CET] <BlackFox> Only this proprietary thing from china with no name plays it [14:14:46 CET] <furq> probably some godawful made-up shit then [14:14:50 CET] <kerio> DeadSix27: yes, i can see that just by the fact that he said "it's literally player.exe and came with some obscure dashcam someone had" [14:15:03 CET] <furq> there's no telling what the chinese will stuff into places it doesn't belong [14:15:04 CET] <kerio> :^) [14:15:05 CET] <DeadSix27> ohhh, didn't see that line :p [14:15:15 CET] <BlackFox> I'm going to try demux video from this [14:15:18 CET] <DeadSix27> I thought you just figured it out by the ffprobe output hah [14:15:18 CET] <BlackFox> See if the files are different [14:15:24 CET] <furq> it probably won't work with ffmpeg [14:15:28 CET] <kerio> furq: why not [14:15:29 CET] <furq> only one way to find out though [14:15:30 CET] <BlackFox> It should possibly reveal proprietary extra bytes [14:15:33 CET] <kerio> ffmpeg saw the video [14:15:36 CET] <kerio> *ffprobe [14:15:37 CET] <BlackFox> furq, ffmpeg will decode video fine [14:15:48 CET] <BlackFox> and anything else that can eat raw 264 stream will play this (without audio) [14:15:59 CET] <kerio> i bet it's chunks of h264 and chunks of some audio [14:16:12 CET] <kerio> BlackFox: does this player.exe allow seeking? [14:16:16 CET] <furq> i guess if the audio is just stuffed into NALUs then it might work [14:16:31 CET] <kerio> furq: Invalid NAL unit 8, skipping. [14:16:32 CET] <kerio> :o [14:16:39 CET] <BlackFox> kerio, I'm not sure, I'll check (probably not) [14:16:48 CET] <BlackFox> It's hard to say because these files are pretty tiny [14:16:54 CET] <BlackFox> so it might be just seeking by playing them through [14:17:03 CET] <kerio> BlackFox: any chance you can upload one somewhere? [14:17:12 CET] <BlackFox> Yes [14:17:15 CET] <furq> yeah i read the pastebin properly after saying it wouldn't work [14:17:16 CET] <BlackFox> Give me like... 4 min [14:23:29 CET] <BlackFox> Just checked, the player doesn't allow seeking, but it does. Aka if you seek, it freezes for a tiny while before it can play, so it probably just seeks through entire stream (which is expected) [14:24:42 CET] <BlackFox> https://drive.google.com/file/d/0B69uOz7lkjebaDVrRXFmQ1lQd1k that should work [14:25:28 CET] <BlackFox> bizzarely, the person who did the recording itself claims that they should have four audio channels in them [14:25:42 CET] <kerio> well, mpv refuses to play it [14:26:37 CET] <DeadSix27> mpc with lav plays it fine [14:26:53 CET] <DeadSix27> mpv doesnt either here [14:27:05 CET] <DeadSix27> however I have no audio in mpc [14:27:06 CET] <BlackFox> http://i.imgur.com/2H8ibN3.png this is what kinda video is in it, just for a sanity check [14:27:42 CET] <kerio> yeah i saw it [14:27:45 CET] <DeadSix27> BlackFox: http://i.imgur.com/fWObfgA.png [14:28:04 CET] <BlackFox> yeah, cause there can't be a proper audio stream in a raw video stream [14:28:33 CET] <kerio> is it a real container that ffmpeg doesn't understand [14:28:35 CET] <techtopia> moc and vlc won't play it [14:28:38 CET] <kerio> or is it something awfully hacky [14:28:42 CET] <techtopia> media info just sees a video stream [14:28:44 CET] <BlackFox> this is not a container for sure [14:28:46 CET] <kerio> like, the audio embedded in a raw h264 stream [14:28:52 CET] <BlackFox> this is just a raw stream with probably embedded audio [14:29:05 CET] <DeadSix27> thats odd ye, why didn't they just put audio alongside [14:29:06 CET] <BlackFox> I'm not familiar with h264 format enough to tell [14:29:11 CET] <DeadSix27> or use a proper container [14:29:18 CET] <kerio> because china [14:29:24 CET] <DeadSix27> :p [14:30:41 CET] <DeadSix27> offtopic, BlackFox, are you using a dashcam as security camera? [14:31:30 CET] <kerio> well i mean [14:31:32 CET] <kerio> why not [14:31:37 CET] <DeadSix27> i guess [14:31:57 CET] <BlackFox> Nah [14:31:58 CET] <DeadSix27> I use 3 logitech webcams as security cameras.. [14:32:10 CET] <DeadSix27> cuz cheap. [14:32:25 CET] <BlackFox> it's a dedicated device that records 4 video channel from IP or analog cameras [14:32:34 CET] <BlackFox> 4 video channels* [14:32:57 CET] <BlackFox> so in theory, the file should contain four video tracks (although only one camera was connected at this time to that device) in some sort of a bizzare container-but-not-really [14:32:59 CET] <BlackFox> but [14:33:00 CET] <DeadSix27> either way, what was your initial question and did we solve your problem? [14:33:39 CET] <BlackFox> well, the problem isn't solved (need to extract audio), but there's a backup plan [14:33:50 CET] <DeadSix27> ah, right you actually did want the audio [14:34:06 CET] <BlackFox> which is just taking literally audio out from the video recorder thing and plugging it into a line in of some computer [14:34:18 CET] <BlackFox> and then just letting it sit there for like half a day while it dumps the audio :'D [14:39:17 CET] <kerio> surely before doing that you'd just disassemble the .exe [14:39:25 CET] <BlackFox> well [14:39:35 CET] <BlackFox> no need to, just figure exports and imports of one DLL I think [14:40:07 CET] <BlackFox> the player.exe is followed by three sets of DLL's: avcodec, a bunch of h264-related DLL's (a weird bunch at a glance), plus something that is cryptically called "streamreader.dll" [14:40:28 CET] <DeadSix27> that last one sounds indeed interesting in this context [14:40:29 CET] <BlackFox> honestly, based on my experience with chinese, if I *did* manage to find out who made this player.exe, asking them for a source code would be trivial [14:41:16 CET] <BlackFox> there is no semblance of any about boxes, readme's or anything that would identify any brands or company names. Presumably I need to dig deeper into the files to find out who made it, but... it's not gonna be me sitting there for hours while the videorecorder is doing the thing [14:41:30 CET] <BlackFox> so might as well go with the backup plan right away [14:41:38 CET] <DeadSix27> googlign helped [14:41:42 CET] <kerio> that is retarded [14:41:45 CET] <DeadSix27> somewhat [14:43:59 CET] <BlackFox> this is sorta video related, so we had some chinese-made DVB transmitters/receivers and wanted to feed custom data through them (use them as sort of a SDR) [14:44:45 CET] <DeadSix27> is the player.exe called exactly that btw? [14:44:48 CET] <DeadSix27> just out of couriosity [14:45:16 CET] <BlackFox> the driver for the device was written by some non-chinese company (I guess whoever made the chip), but the actual interface part of the driver was a shoddy chinese thing [14:46:01 CET] <BlackFox> it was having lots of issues, we asked them for a newer verison, they just sent us all sourcecode to their stuff [14:46:13 CET] <BlackFox> I was not surprised at all to see the code quality [14:46:47 CET] <kerio> was it shit? [14:46:57 CET] <BlackFox> absolutely and utterly [14:47:18 CET] <BlackFox> exceptions were used as a way to return successful indications [14:49:33 CET] <BlackFox> also it had no actual error handling interface, all errors were dumped as text into msvs output window [14:49:41 CET] <BlackFox> most helpful stuff like "?????????? g_hMutex != NULL ??????????" [16:27:34 CET] <markvandenborre> hey! I'm using the -f tee command; I can succcessfully use -y -f tee "/tmp/foo.ts|/tmp/bar.ts" [16:27:48 CET] <markvandenborre> but I want the second part of the tee to be thrown at an rtmp server [16:27:57 CET] <markvandenborre> and that always seems to fail for some reason [16:29:34 CET] <Pignoufou> Hi everyone! :) [16:29:48 CET] <markvandenborre> Pignoufou: good morning [16:30:57 CET] <Pignoufou> I've got a question regarding programmatic use of ffmpeg& basically I want to use ffmpeg to extract images from a video at specific time codes& I know how to extract one image from the CLI (or several at a specified interval) but what I'd like to do now is be able to extract images at several points, not necessarily time based [16:31:54 CET] <Pignoufou> Also, what would be great would be to be able to keep the ffmpeg process open until I'm done (because I won't know the whole set of images at the beginning and I'd like to avoid wasting time with ffmpeg starting for every frame) [16:32:06 CET] <Pignoufou> So question is& is there a way to do that? [16:32:22 CET] <FishPencil> How is it that two playlists from the same bluray were encoded to very different sizes (1.6GB vs 3.1GB). The same x264 settings were used (CRF 25) [16:34:15 CET] <Mysoft> Pignoufou i think on linux you can use a mkfifo [16:34:21 CET] <Mysoft> and tell ffempg to read the fifo for the input [16:34:39 CET] <Mysoft> and so every "image" you can send as input trough that fifo [16:35:10 CET] <Mysoft> but ofcourse ffmpeg wont help you selectively choosing the frames from a different video [16:35:54 CET] <Pignoufou> That's the thing I want to use ffmpeg to extract images. Otherwise I'll just implement it restarting a process every time or something like that until I can find a better solution :) [16:36:17 CET] <Pignoufou> (I'm already using ffmpeg to encode from images I pass it through stdin) [16:37:09 CET] <Mysoft> you could probabily make it output images in blocks of some seconds [16:37:30 CET] <Mysoft> which then you can select which to fifo in on the second ffmpeg [16:37:45 CET] <Pignoufou> Yes that's an alternative I'm thinking about :) [17:11:01 CET] <neonfuz> Hey [17:11:06 CET] <neonfuz> is there a long version of the option -an? [17:13:35 CET] <techtopia> i don't think so [17:14:24 CET] <Mysoft> hu why you would want that? [17:38:30 CET] <neonfuz> trying to get retroarch to output to v4l2loopback [17:38:45 CET] <neonfuz> retroarch talks to ffmpeg through the c api, and I want to disable audio [20:20:39 CET] <Threads> i see ffmpeg loves greek women :D [21:37:07 CET] <diffuse> I've been messing around with the ffmpeg C API and looking at the filter and muxer examples. I was wondering if there was a decent examplt that would allow me to use the "segment" muxer. [21:37:56 CET] <diffuse> I'd like to make a small C program to take a large video file and split it into a bunch of smaller segments (I see the ffmpeg command line tool does this, but I can't seem to locate the actual code) [22:15:52 CET] <jason__> just use ffmpeg or call it from your program [23:08:16 CET] <DHE> diffuse: most likely you need: avformat_alloc_output_context2(avctx, NULL, "segment", "listfilename.m3u8"); and then you can specify a dictionary with your options in avformat_write_header [23:08:32 CET] <DHE> this is from a reading of the docs and not actual experience. not tried the segment muxer from the API [23:21:08 CET] <jarlath> I've found an example on stackoverflow that just copies the video but changes the audio format. I also want to just copy (passthru) the video but want to add a wav file as the audio track. How would I modify this to do that? ffmpeg -i input.avi -acodec mp3 -vcodec copy out.avi [23:32:28 CET] <DHE> ffmpeg -i videofile.mp4 -i input.wav -c:v copy -c:a [codec-for-audio] output.mp4 [23:34:38 CET] <jarlath> DHE: thank you :) [00:00:00 CET] --- Sun Nov 27 2016

1 0

ffmpeg-devel.log.20161125
by burek 26 Nov '16

26 Nov '16

[00:43:21 CET] <cone-811> ffmpeg 03Andreas Cadhalpun 07master:98b3a7979f2f: flvdec: require need_context_update when changing codec id [00:43:21 CET] <cone-811> ffmpeg 03Andreas Cadhalpun 07master:8c8f543b81aa: libopusdec: default to stereo for invalid number of channels [01:02:23 CET] <cone-811> ffmpeg 03Martin Vignali 07master:5099c541bbb9: libavcodec/exr: add support for uint32 channel decoding with pxr24 [01:02:24 CET] <cone-811> ffmpeg 03Martin Vignali 07master:c9d1f4883d87: fate/exr: add test for pxr24 with half and uint32 channel [01:25:22 CET] <cone-811> ffmpeg 03Andreas Cadhalpun 07master:2d6f46d801ba: softfloat: decrease MIN_EXP to cover full float range [02:09:23 CET] <cone-811> ffmpeg 03Michael Niedermayer 07master:08d3b9ad9120: MAINTAINERS: Add developers who have git write access but are otherwise not listed [02:09:24 CET] <cone-811> ffmpeg 03Michael Niedermayer 07master:334775f58f09: MAINTAINERS: Add Vittorio to "Developers with git write access who are currently not maintaining any specific part" [11:07:30 CET] <cone-326> ffmpeg 03Carl Eugen Hoyos 07master:e0791c5aaf1c: lavf/flvdec: Set avg_frame_rate for video streams. [14:43:00 CET] <cone-692> ffmpeg 03James Almer 07master:50b14539158b: avcodec/mpeg4audio: correctly propagate meaningful error values [19:14:29 CET] <cone-667> ffmpeg 03Philip Langdale 07master:829db8effd76: avcodec/nvenc: Remove aspect-ratio decompensation logic [21:05:59 CET] <cone-667> ffmpeg 03Andreas Cadhalpun 07master:2566ad98b015: mss2: only use error correction for matching block counts [22:14:57 CET] <cone-667> ffmpeg 03Michael Niedermayer 07release/3.2:6550d0580b07: Update for 3.2.1 [22:18:44 CET] <jamrial> nevcairiel: is the new patch ok? would like to backport it for 3.2.1 [22:22:36 CET] <nevcairiel> jamrial: an argument could probably be made for just deleting the extradata and hoping its still adts when its invalid, but its likely not important, unless a container format like mkv or mp4 encoded those with bad extradata, original sources never have any (raw or mpegts, not sure where else one gets adts) [22:22:42 CET] <nevcairiel> so lgtm [22:24:55 CET] <jamrial> nevcairiel: ok, thanks [22:26:29 CET] <cone-667> ffmpeg 03James Almer 07master:6e1902bab434: avcodec/aac_adtstoasc_bsf: validate and forward extradata if the stream is already ASC [22:26:57 CET] <jamrial> michaelni: can i backport ^ or are you in the middle of testing/packaging? [22:42:41 CET] <cone-667> ffmpeg 03Andreas Cadhalpun 07release/3.2:de031809f3a0: ffmdec: validate codec parameters [22:42:42 CET] <cone-667> ffmpeg 03Andreas Cadhalpun 07release/3.2:7d0cc12a565d: mxfdec: fix NULL pointer dereference in mxf_read_packet_old [22:42:43 CET] <cone-667> ffmpeg 03Andreas Cadhalpun 07release/3.2:d8364f4e1d0c: smacker: limit recursion depth of smacker_decode_bigtree [22:42:44 CET] <cone-667> ffmpeg 03Andreas Cadhalpun 07release/3.2:e00fec907ff8: rmdec: validate block alignment [22:42:45 CET] <cone-667> ffmpeg 03Andreas Cadhalpun 07release/3.2:9aaddbf0efd3: sbgdec: prevent NULL pointer access [22:42:46 CET] <cone-667> ffmpeg 03Andreas Cadhalpun 07release/3.2:1dc59aaf61ec: pgssubdec: only set w/h/linesize when allocating data [22:42:47 CET] <cone-667> ffmpeg 03Andreas Cadhalpun 07release/3.2:6ad27731428c: flvdec: require need_context_update when changing codec id [22:42:48 CET] <cone-667> ffmpeg 03Andreas Cadhalpun 07release/3.2:a6a2d9d1e546: libopusdec: default to stereo for invalid number of channels [22:42:49 CET] <cone-667> ffmpeg 03Andreas Cadhalpun 07release/3.2:ad8203662613: softfloat: decrease MIN_EXP to cover full float range [22:42:50 CET] <cone-667> ffmpeg 03Andreas Cadhalpun 07release/3.2:d147114b9de0: mss2: only use error correction for matching block counts [22:42:51 CET] <cone-667> ffmpeg 03Andreas Cadhalpun 07release/3.2:6f3e3cb8bacc: Update Changelog [22:48:30 CET] <jamrial> well then [22:51:33 CET] <Kuroe> 3.2.1 released and then 3.2 changed? [22:51:47 CET] <jamrial> no, it wasn't released yet [22:53:22 CET] <cone-667> ffmpeg 03James Almer 07release/3.2:c269c43a8316: avcodec/aac_adtstoasc_bsf: validate and forward extradata if the stream is already ASC [23:16:05 CET] <michaelni> jamrial, i see you already backported, but yes please backport all bugfixes you feel should be backpoted [23:18:11 CET] <jamrial> michaelni: i backported it without waiting for your answer since Andreas pretty much voided the reason i asked that in the first place with his own batch of commits [23:19:37 CET] <michaelni> jamrial, sure, np [23:53:51 CET] <cone-667> ffmpeg 03Muhammad Faiz 07master:da34e4e13238: swresample/soxr: fix invalid use of linear_interp [00:00:00 CET] --- Sat Nov 26 2016

1 0

ffmpeg.log.20161125
by burek 26 Nov '16

26 Nov '16

[00:14:37 CET] <superguest> Hi [00:17:56 CET] <Kadigan> Here's something I've always been meaning to ask: whenever there's an outdated API, an error in one of the modules or whatever that makes a dev comment pour out, I keep thinking -- "Why would I, the end-user, want to hear about AVStream.codecpar?!" [00:18:12 CET] <furq> it's to keep you on your toes [00:18:36 CET] <Kadigan> Seriously, though. Is there a flag that I can use to disable these messages? [00:18:51 CET] <furq> nothing other than -v error [00:18:52 CET] <Kadigan> (or better yet, could there be a flag I could use to ENABLE them, so default would be hiding them?) [00:18:54 CET] <furq> which is probably a bit much [00:19:25 CET] <furq> there should probably be something like -v deprecated just above -v warning [00:19:42 CET] <Kadigan> It's annoying because there's nothing informative in there for ME, you know? [00:19:56 CET] <furq> yeah that warning does nothing other than generate confusion on irc [00:20:02 CET] <Kadigan> I'm like "Ooops, did I fuxxor something up? Oh, no, it's just another one of THOSE messages..." [00:21:00 CET] <Kadigan> I mean, no, I get it - it's a message spat out by some part of code interacting with another part of code. It's just useless to me, so I find it odd to have it included in every output. [00:22:11 CET] <Kadigan> Also, this kind of thing is fairly common in the open-source world, isn't it -- deprecating interfaces, APIs and all that. I mean, Microsoft took over a decade to finally throw some wonky backsupport away - as a good example of competetive shrink-wrap. [00:30:04 CET] <c_14> Well nobody's paying us to support ancient interfaces. [00:30:11 CET] <c_14> And there's always the effort to make things "better". [01:14:40 CET] <Kadigan> "Better", I get. The issue, however, is with how "better", contrary to popular belief, is actually a -subjective- term. [01:15:29 CET] <Kadigan> Though in this case I withold further comments, as I have no idea how the API looked before and thus whether there are reasons backing the split into .codec and .codecpar. [01:15:38 CET] <furq> the issue isn't the split [01:15:57 CET] <furq> the issue is either that ffmpeg still uses the old api, or that it tells users about that fact at the default loglevel [01:16:20 CET] <Kadigan> I don't think I'm running latest, though... [01:16:28 CET] <furq> it still does it on 3.2 iirc [01:16:53 CET] <Kadigan> Well, it printing at default loglevel is definitely the issue, there I agree. [01:17:40 CET] <Kadigan> There's a number of other things I'd see gone at default, too. Like how libfdk_aac spits out an error about VBR 590 being outside the range of 1-5... that's just silly. [01:18:04 CET] <Kadigan> I'm not quite decided on which part of that mismatch is sillier. [01:18:41 CET] <furq> it'd be nice if ffmpeg just didn't show deprecation warnings from the libs at all [01:18:51 CET] <furq> it's a completely useless thing for a user to see [01:18:59 CET] <Kadigan> I don't know, man... When I build a program, I leave stuff like that in, maybe with a -v switch or something. When I build a lib though... I tend to kill that stuff for -release. [01:19:12 CET] <furq> i mean ffmpeg specifically, noto the libs [01:19:14 CET] <furq> -o [01:19:48 CET] <furq> i can imagine you'd want to avoid another set of ifdefs though [01:19:54 CET] <furq> i'm sure there are plenty already [01:19:58 CET] <Kadigan> That's assuming that the libs pump their errors/deps into a queue managed by ffmpeg, [01:20:05 CET] <Kadigan> and not just direct to screen. [01:20:11 CET] <Kadigan> Which I've seen happen. [01:25:13 CET] <furq> i'm pretty sure they don't [01:25:29 CET] <furq> well that was unclear [01:25:41 CET] <furq> i'm pretty sure the libs just print error messages directly [01:26:12 CET] <furq> so you'd need to fuck with the libs to fix this [01:59:50 CET] <Kadigan> I guess. [04:56:55 CET] <Sashmo> does anyone have a suggestion how I can get a sine generated to beep every second on the second, the same second that my clock is ticking ? this looks and sounds good, but its not timed correctly.... http://pastebin.com/xt6xkUNR [05:49:11 CET] <tomed> it takes way too long to use x264 [05:49:16 CET] <tomed> how do i make it faster [09:42:37 CET] <superguest> hi [09:45:53 CET] <kerio> waddup [10:05:20 CET] <superguest> Hey Kerio [10:06:05 CET] <superguest> https://ffmpeg.org/ffmpeg-filters.html#Text-expansion [10:11:31 CET] <superguest> it is said that 2ndArg in text=${pts\:localtime\:2ndArg} is "an offset added to the timestamp" [10:11:52 CET] <superguest> Also, " By default, YYYY-MM-DD HH:MM:SS format will be used." [10:12:31 CET] <superguest> How, and in what format, is the 2ndArg specified? [10:13:30 CET] <superguest> Say I want to offset the burn-in timecode by +1 day, how do I do so? [10:19:14 CET] <superguest> Note that sequences of the form %{...} are expanded and that 'pts' is expanded as a function that prints the timestamp of the current frame. [10:20:51 CET] <superguest> I've asked this here before, but no one responded. Considering there's 360+ ppl in here I thought I could get a quick response. [10:21:19 CET] <superguest> I guess I'll take this to video.stackexchange next. [10:21:37 CET] <furq> i assume it's either seconds or a time spec [10:23:08 CET] <superguest> furq, time spec in what format? that's the crux of my question really. [10:23:22 CET] <furq> https://ffmpeg.org/ffmpeg-utils.html#time-duration-syntax [10:26:13 CET] <superguest> furq, thanks! I'll try that ^^ [10:49:23 CET] <techtopia> when encoding to wav to ac3 with ffmpeg [10:49:32 CET] <techtopia> im loosing some of the audio channels [10:50:18 CET] <techtopia> ffmpeg -i input.wav -vn -sn -acodec ac3 -q:a 640 output.ac3 [10:50:36 CET] <techtopia> ^ doing this and lose the center channel, anyone know why? [10:54:49 CET] <techtopia> also just [10:55:11 CET] <techtopia> ffmpeg -i input.wav -acodec ac3 output.ac3 [10:55:26 CET] <techtopia> the channel with dialogue just disappears [11:03:14 CET] <ikevin> techtopia, take a look at https://trac.ffmpeg.org/wiki/AudioChannelManipulation [11:09:28 CET] <techtopia> i don't want to remove the channels [11:09:57 CET] <techtopia> i want to keep them all and just encode from 24bit pcm in a wav to ac3 at a lower bitrate [11:20:14 CET] <ikevin> techtopia, you maybe need to map channels [11:21:43 CET] <techtopia> hmm [11:25:19 CET] <kerio> but why ac3 and not opus :^) [11:26:21 CET] <techtopia> i don't mind kerio, opus would be fine if it works [11:26:46 CET] <techtopia> atm i have a 7000kbps pcm wav thats 2.9gib [11:27:00 CET] <techtopia> i just want to reduce it in size while retaining all the audio channels [11:27:33 CET] <kerio> is ffmpeg -i whatever.wav whatever.ac3 actually dropping channels? [11:27:41 CET] <kerio> like, is it saying that it's outputting in stereo [11:29:27 CET] <techtopia> no it shows as 6channels still [11:29:36 CET] <techtopia> but there is silence where there was dialogue before [11:29:45 CET] <kerio> how are you playing the file? [11:29:58 CET] <techtopia> mediaplayerclassic and vlc [11:30:10 CET] <kerio> i'm not saying both are wrong [11:30:14 CET] <kerio> but could you try mpv? [11:30:29 CET] <techtopia> okay [11:30:30 CET] <kerio> try other containers as well, like .mka [11:31:38 CET] <furq> try another encoder as well [11:31:43 CET] <furq> it might be an issue with the ac3 encoder [11:32:09 CET] <kerio> if it's 48kHz, opus! :D [11:32:51 CET] <techtopia> it's the same Keridos larger periods of silcene where dialogue used to be [11:33:06 CET] <kerio> :( [11:33:15 CET] <kerio> ffmpeg -i whatever.wav whatever.opus [11:33:25 CET] <techtopia> ok trying now [11:35:20 CET] <kerio> furq i has a question about opus [11:35:40 CET] <kerio> would a s24 audio file sound better than a s16 one [11:35:46 CET] <kerio> compressed at the same average bitrate [11:36:42 CET] <furq> assuming you think s24 wav sounds better than s16, then sure [11:37:12 CET] <kerio> i mean, do i have any reason to drop the bit depth before compressing? [11:37:17 CET] <techtopia> http://pastebin.com/baRPgxin [11:37:17 CET] <kerio> it should end up being pretty much the same, right [11:37:25 CET] <techtopia> sam4e issue in opus Kerio :( [11:37:33 CET] <kerio> techtopia: but the channels are there :( [11:37:47 CET] <techtopia> yes but the audio no longer is [11:38:33 CET] <furq> does it happen with opusenc [11:38:42 CET] <furq> or $standalone_encoder [11:39:14 CET] <ikevin> don't you have multiple languages for your dialogue? [11:40:40 CET] <techtopia> it's just english [11:48:16 CET] <techtopia> furq yes [11:48:27 CET] <techtopia> it happens with eac3to also [12:03:05 CET] <techtopia> hmm using ac3_fixed [12:03:26 CET] <techtopia> i get silence still in media player classic, but extreamly muffled voices in vlc [12:04:12 CET] <techtopia> i think it might have somthing to do with going from 7000kb/s to 660 kb/s [12:07:47 CET] <techtopia> http://i.imgur.com/DK6IdDN.jpg [12:07:53 CET] <techtopia> plays great in sourc e:( [12:19:16 CET] <techtopia> Stream #0:0: Audio: pcm_s24le ([1][0][0][0] / 0x0001), 48000 Hz, 5.1, s32 (24 bit) [12:19:29 CET] <techtopia> shouldnt it be s24 not s32? [12:38:25 CET] <kerio> techtopia: i wonder if that's the issue [13:18:08 CET] <gabrieliv> Is there any example of video decoding with the new _send/receive_packet/frame() API? [13:23:35 CET] <BtbN> ffmpeg.c, however good of an example that is [13:29:28 CET] <kerio> techtopia: have you figured out the issue? [13:29:41 CET] <kerio> maybe your samples are just all effectively divided by 256 [13:34:45 CET] <techtopia> im still working on it kerio [13:34:48 CET] <techtopia> no luck so far [14:06:07 CET] <gabrieliv> What is the desired codec if I want to decode.mpeg video into .pgm frames? [14:08:06 CET] <gabrieliv> Also, what is the right way to pass exactly one frame to the decoder? [16:45:42 CET] <Sashmo> does anyone have a suggestion how I can get a sine generated to beep every second on the second, the same second that my clock is ticking ? this looks and sounds good, but its not timed correctly.... http://pastebin.com/xt6xkUNR [17:27:49 CET] <DHE> Sashmo: you're sending this out to multicast by UDP. players will perform at least minimal buffering so getting it time-synchronized is an exercise in futility [17:30:46 CET] <kerio> DHE: gopless h264 with periodic intra refresh [17:30:48 CET] <kerio> :3 [17:32:02 CET] <DHE> nevertheless bitrate variations or just variable frame sizes will require some form of buffering on the client side, even if it's something small like 200 milliseconds. [17:32:20 CET] <DHE> intra refresh helps, but I don't think it's good enough for true CBR [17:32:51 CET] <kerio> that one blog post that's only accessible through archive.org claimed 1 frame of latency [17:33:10 CET] <Sashmo> dhe: I would like to agree with you but I dont thing thats correct. The output portion has nothing to do with the sync of the beep and the video of the time. [17:33:50 CET] <DHE> Sashmo: my point is there's buffering everywhere. even your sound card has some buffering going on [17:34:09 CET] <DHE> err, wait... [17:34:52 CET] <DHE> oh, derp... you mean the on-screen clock of the generated video... [17:35:27 CET] <DHE> I'm gonna go stand over here now [18:27:36 CET] <c_14> Sashmo: the beep_factor doesn't do what you think it does [18:27:40 CET] <c_14> It doesn't beep every second [18:27:47 CET] <c_14> It beeps a second after it last stopped beeping [18:27:58 CET] <c_14> so it'll go out of sync with the timestamp [18:28:06 CET] <Sashmo> c_14: yeah thats what I am seeing [18:28:15 CET] <Sashmo> c_14: any ideas how to sync it up? [18:28:21 CET] <Sashmo> Trying to make my own test card [18:31:10 CET] <c_14> Besides changing the code? [18:31:46 CET] <c_14> Creating the beep shouldn't be that hard, but getting it synced to the system clock is much harder. [18:32:25 CET] <c_14> maybe sine filter with frequency you want, setpts set the timestamps to RTC-RTCSTART and then aselect to select only those parts around the second changes [19:09:55 CET] <persina> Is there a difference between using the -loop argument versus the -concat? [19:15:07 CET] <markvandenborre> ah, persina , you are interested in similar things as what I am interested in, at the same time [19:16:15 CET] Action: markvandenborre is reading up on how to cleanly and efficiently prepend a preroll (title screen) and append a postroll (closing screen) to an existing video [19:21:44 CET] <durandal_1707> concat demuxer or filter [19:24:49 CET] <markvandenborre> durandal_1707: I'm reading up on that [19:27:14 CET] <markvandenborre> to generate an image (problem solved) and convert that to video for a few seconds (still looking at that) [19:27:53 CET] <markvandenborre> I can realise the separate steps, but I'm spending a bit more time than I like banging my head into the wall trying to solve it elegantly [19:27:57 CET] <markvandenborre> :-) [19:34:26 CET] <markvandenborre> durandal_1707: thx for the hint [19:35:25 CET] <markvandenborre> the tricky thing is not as much to get this to work even [19:35:45 CET] <markvandenborre> getting it to work efficiently without reencoding anything in the video part [19:35:50 CET] <markvandenborre> that is the tricky bit... [19:36:36 CET] <Billys> hello everyone! [19:36:43 CET] <Mysoft> markvandenborre yeah... when aiming for doing that [19:36:49 CET] <Mysoft> i usually save as .ts format [19:36:53 CET] <Mysoft> so concat is just binary copy [19:37:51 CET] <Mysoft> but if both contents are the same format... you can just concat them easily with the "codec copy" [19:38:17 CET] <Billys> im preim extremely noob on ffmpeg [19:38:19 CET] <Billys> and not the luxury of time to search on forum for my problem [19:38:20 CET] <Billys> is here the place to ask for help? [19:38:27 CET] <markvandenborre> Mysoft: I have an image that I want to display for a few seconds [19:38:53 CET] <markvandenborre> easy with -framerate 1/5 -i image.jpg [19:38:56 CET] <Mysoft> i think it would be better to first encode it into the same format as the video [19:39:04 CET] <markvandenborre> then use that in a filter complex [19:39:22 CET] <Mysoft> generating the N seconds and then just do the normal concat [19:39:23 CET] <markvandenborre> so that I could use -codec copy you mean? [19:39:29 CET] <Mysoft> yeah [19:39:43 CET] <markvandenborre> that is something I'm trying to avoid if at all possible [19:39:54 CET] <markvandenborre> cleaning up temporary files can get messy [19:40:09 CET] <Mysoft> well i guess the filters will work fine [19:40:29 CET] <markvandenborre> I wonder if I could have my cake and eat it [19:40:44 CET] <Mysoft> since they are in a predicted order... and if i remember right there's options for timings with that [19:41:01 CET] <Mysoft> but they would "override" the begin of the video [19:41:03 CET] <Mysoft> instead of "concat" [19:41:19 CET] <Mysoft> and that obviously requires encoding not just copy... [19:41:33 CET] <Mysoft> so [19:41:47 CET] <markvandenborre> I was hoping that I could accomplish something with filter_complex magic [19:42:11 CET] <Mysoft> then what you can do is pipe your images... [19:42:30 CET] <Mysoft> so concat the pipe input + video... [19:42:36 CET] <Mysoft> so then you don't have a temp file.... [19:42:48 CET] <Mysoft> but... that will be troublesome for the end part @_@ [19:42:56 CET] <markvandenborre> :-( [19:43:35 CET] <Mysoft> BUT [19:43:44 CET] <Mysoft> if the image is the same on begin end [19:44:07 CET] <Mysoft> the input can be infinitely repeating the same image [19:44:21 CET] <markvandenborre> a -loop 1, yes [19:44:32 CET] <Mysoft> and then you can just double the contact [19:44:47 CET] <markvandenborre> not sure I uderstand you well here [19:45:30 CET] <Mysoft> but there's another problem... the normal concat protocol [19:45:42 CET] <Mysoft> requires a .txt file with the inputs to concat... [19:46:11 CET] <Mysoft> so i think that avoiding temp files causes more problems than it solves hehe [19:46:18 CET] <markvandenborre> seems so, yes [19:46:35 CET] <Mysoft> but i guess on a batch file [19:47:04 CET] <markvandenborre> oh well, I can probably get more improvement suggestions by building the solution with temp files first [19:47:20 CET] <markvandenborre> then going from there [19:47:50 CET] <Mysoft> you probabily could get the .txt from pipe... [19:49:39 CET] <markvandenborre> Mysoft: https://gist.github.com/markvdb/b23cb2f4cc2a158e15f65ad1e390a776 [19:49:44 CET] <markvandenborre> is what we used in the past [19:49:59 CET] <markvandenborre> it made total sense at the time [19:50:15 CET] <markvandenborre> but now, video input arrives as picture in picture with a background already [19:50:32 CET] <markvandenborre> so we don't have to reencode any of the essentials anymore [19:51:17 CET] <markvandenborre> (the script was the simple standalone test version, but you get the idea I guess) [19:51:32 CET] <markvandenborre> now we don't do an overlay with the title anymore [19:51:33 CET] <Mysoft> have you read this? [19:51:33 CET] <Mysoft> https://trac.ffmpeg.org/wiki/Concatenate [19:51:37 CET] <markvandenborre> yes [19:51:42 CET] <Mysoft> at the end i think there's your magic [19:51:49 CET] Action: markvandenborre reads again [19:52:47 CET] <markvandenborre> ah, I stopped reading before at "With any vaguely-modern version of ffmpeg, the following script is made redundant by the advent the concat filter" [19:54:17 CET] <Billys> hello? [19:55:09 CET] <markvandenborre> Billys: hello [19:55:19 CET] <Billys> can i ask for help? [19:55:36 CET] <markvandenborre> Billys: better immediately ask what you would like to ask [19:55:42 CET] <Billys> http://www.tiikoni.com/tis/view/?id=414b420 [19:56:44 CET] <Billys> when i play a straming video i think on mpeg4 i get this "lines" [19:56:45 CET] <Mysoft> interlaced merging... [19:57:05 CET] <Billys> ok so i search for "interlaced merging" ? [19:57:42 CET] <Mysoft> that would work... as that is what happens there [19:57:53 CET] <Mysoft> the video is interlaced (odd lines in one frame... even lines in another) [19:58:17 CET] <Billys> there is a parameter to fix this? [19:58:53 CET] <Mysoft> you said streaming... so the source of the video is a file? [19:59:22 CET] <Mysoft> or it's a capture device? [19:59:48 CET] <Billys> basicly is from tv tuner right now [19:59:56 CET] <Mysoft> ok makes sense [19:59:59 CET] <Billys> with other player the video its ok [20:00:19 CET] <Mysoft> it may have auto-detected the interlace and applied the de-interlace filter [20:00:25 CET] <Mysoft> (the player) [20:01:05 CET] <Mysoft> so if you want to stream without the interlace then you need to reencode the vidoe while streaming with a deinterlace filter [20:01:12 CET] <Mysoft> so that the video will become progressive then :) [20:01:25 CET] <Billys> i see.. [20:01:57 CET] <Billys> so there is a command to enable that filter on ffmplay? [20:02:14 CET] <Mysoft> yes [20:02:34 CET] <Mysoft> probabily just [20:02:37 CET] <Mysoft> ffplay -deinterlace [20:02:39 CET] <Mysoft> will do the trick [20:07:28 CET] <Billys> im soooo noob.... i cant set the parameter correctly :P [20:10:44 CET] <Billys> anyway im pretty sure that i will make it work. [20:10:49 CET] <Billys> Thank You!! [20:11:12 CET] <markvandenborre> Mysoft: thank you for helping me too [20:14:54 CET] <pgorley> hi all, what are the dependencies for libavfilter? i keep getting undefined references [20:15:43 CET] <pgorley> i'm passing -lavfilter to the linker [20:22:08 CET] <Mysoft> oh... dang -deinterlace is just for ffmpeg... so ffplay requires something like "-vf yadif" [20:22:11 CET] <Mysoft> but it's too late @_@ [20:25:06 CET] <klaxa> pgorley: probably also needs other libs? pastebin your errors [20:27:00 CET] <pgorley> klaxa: it's just a bunch of undefined reference to libavfilter functions [20:28:11 CET] <klaxa> well show us what gcc/ld tells you [20:34:07 CET] <pgorley> klaxa: http://pastebin.com/CBRWPG86 [20:35:50 CET] <c_14> Can you make V=1 or something? [20:36:01 CET] <c_14> something to show the actual g++/ld calls [20:37:07 CET] <pgorley> http://pastebin.com/wFdWXqE8 [20:38:48 CET] <c_14> Are the libav*.so files in your default LDPATH ? [20:39:46 CET] <pgorley> i'd assume so, since it finds all the other libav*.so files [20:40:47 CET] <pgorley> i can confirm that libavfilter.so is located at the same place as libavcodec.so and the others that i use [20:41:22 CET] <c_14> Which is? [20:41:24 CET] <pgorley> in /usr/lib/x86_64-linux-gnu [20:44:57 CET] <klaxa> try adding -L/usr/lib/x86_64-linux-gnu? [20:45:08 CET] <klaxa> to the command that fails [20:46:51 CET] <klaxa> maybe your configure command also has something like --extra-ld-flags or you can set it via environment variables [20:46:57 CET] <pgorley> will do [20:47:02 CET] <klaxa> or add it in the makefile maybe [20:47:10 CET] <klaxa> as long as it does the right thing :P [20:52:47 CET] <pgorley> doesn't quite work, tried the env var and hardcoding it in my makefile [20:53:05 CET] <c_14> What does "quite" mean? Does it do something different? [20:53:20 CET] <pgorley> oh, sorry, no it doesn't [20:54:04 CET] <pgorley> might have something to do with the order of dependencies in the makefile [20:54:17 CET] <pgorley> does libavfilter depend on another libav*? [20:56:28 CET] <iive> it definitely depends on avutil [20:56:41 CET] <iive> it might also depend on avcodec [20:57:27 CET] <pgorley> which are both placed before avfilter in the makefile :S [21:07:56 CET] <CFS-MP3> I have a weird problem. Doing this: [21:07:58 CET] <CFS-MP3> mpeg -i Westworld.S01E01.1080p.HDTV.6CH.x265.HEVC-PSA.mkv [21:07:58 CET] <CFS-MP3> -filter_complex "fps=12,scale=416:-2:flags=lanczos,showinfo" -map v [21:07:58 CET] <CFS-MP3> -codec:v libx264 -f segment -segment_time 6 -segment_list_type m3u8 [21:07:58 CET] <CFS-MP3> -segment_list wwseg.m3u8 wwseg%05d.mp4 [21:08:07 CET] <CFS-MP3> Generates many unplayable mp4 [21:08:20 CET] <CFS-MP3> however, if I generate .ts files isntead, and then convert those to .mp4, the result plays fine [21:08:22 CET] <CFS-MP3> any idea? [21:08:57 CET] <CFS-MP3> The conversion ts -> mp4 is as simple as ffmpeg -i ${filename} -acodec copy -vcodec copy "$(basename $filename .ts).mp4" [21:28:46 CET] <persina> why does -loop take significantly longer than using -concat? [22:42:26 CET] <markvandenborre> persina: because -loop is more resource intensive? [22:42:45 CET] <markvandenborre> in some cases, concat can just copy instead of having to generate single frames? [23:02:51 CET] Action: markvandenborre is having trouble concatenating using -c copy [23:03:48 CET] <markvandenborre> I'm getting "[mp4 @ 0x56383ab4aa60] Non-monotonous DTS in output stream 0:0; previous: 197241, current: 157187; changing to 197242. This may result in incorrect timestamps in the output file. [23:03:52 CET] <markvandenborre> " [23:04:13 CET] <markvandenborre> a lot of warnings similar to that [23:05:12 CET] <Mysoft> heh i remember getting a flood of this message too [23:05:14 CET] <Mysoft> at some point [23:05:25 CET] <Mysoft> but i dont remember the cause/outcome [23:06:13 CET] <markvandenborre> and what makes me feel uncomfortable is that I get [23:06:14 CET] <markvandenborre> [concat @ 0x560cc1820ae0] Unsafe file name '/tmp/prerollsilentaudio.mp4' [23:06:39 CET] <markvandenborre> when I don't give concat the -safe 0 option [23:07:18 CET] <markvandenborre> according to ffmpeg.org, the filenames I use should be perfectly safe, like the above [23:07:26 CET] <markvandenborre> or am I missing something there too? [23:10:10 CET] <markvandenborre> Mysoft: I see that the ffmpeg generated files have an encoding date set of 1904-01-01 [23:10:52 CET] <markvandenborre> quite sure that has nothing to do with the relative timestamps, but I'm really at a loss about what is happening here [23:11:12 CET] <markvandenborre> where to investigate further what I am doing wrong [23:13:12 CET] <markvandenborre> for some reason, I see the frame rate of the resulting file is not 25 FPS like all of the incoming ones, [23:14:19 CET] <markvandenborre> but according to mediainfo, it's a variable frame rate mode, with frame rate 24.975 FPS, minimum frame rate 0.711 FPs and maximum frame rate 12800 FPS [00:00:00 CET] --- Sat Nov 26 2016

1 0